On Tue, Sep 5, 2023 at 5:42 AM Kent Watsen <kent+i...@watsen.net> wrote:
> NETMOD WG, > > This email begins a 2-week adoption poll for: > https://datatracker.ietf.org/doc/draft-ma-netmod-immutable-flag/08 > > There is no known IPR on this draft (IPR call > <https://mailarchive.ietf.org/arch/msg/netmod/_S-cKw5jIBmDKEPBRq8KeAbNLGg/> > ). > > Please voice your support or technical objections to adoption on the list > by the end of the day (any time zone) Sep 19. > > I do not support the adoption of this draft. It does not appear there is WG consensus on a problem statement. I reject the architecture that is built upon the premise that the config=true nodes must not include any data nodes provided by the server. It is already backed into the YANG models. The 'type' leaf in RFC 8343 is a good example of the problem: "The type of the interface. When an interface entry is created, a server MAY initialize the type leaf with a valid value, e.g., if it is possible to derive the type from the name of the interface. If a client tries to set the type of an interface to a value that can never be used by the system, e.g., if the type is not supported or if the type does not match the name of the interface, the server MUST reject the request. A NETCONF server MUST reply with an rpc-error with the error-tag 'invalid-value' in this case."; Use-Cases: - dynamic defaults - system-dependent values (like if:type) In both cases, there is a subset of valid values that are not the same as the entire type range. The server can provide a correct value, or the client can guess a correct value. For simplicity, it is easier if the server provides a correct value. It would be really complex to require clients to always provide a correct value. Possible Problems: - There is no standard machine-readable mechanism to identify a configuration leaf with these properties - There is no way (besides populating NACM data rules) to indicate that the server implementation does not allow the client to know if write access to the leaf is restricted Issues with if:type: - The server MAY create a mandatory leaf. This clearly applies to <candidate> and <running> - How does the client know which server implementations will create the missing mandatory leaf, and which will not? - The if:type text does not mention that the server MAY prohibit modification of this leaf. - The mandatory=true property indicates whether the client or server can delete the leaf. There is no such indication for an optional leaf. It seems some people are arguing that data nodes like if:type should be read-only because the server MAY write it. IMO the if:type design is correct. I.e. both the server and client can provide config=true values. I am not sure a 1-size-fits-all YANG extension can replace the description-stmt for a leaf like if:type. Thank you, > Kent (as co-chair) > Andy > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
