> On May 3, 2019, at 8:08 AM, tom petch <[email protected]> wrote: > > ----- Original Message ----- > From: "Mikael Abrahamsson" <[email protected]> > To: "Randy Presuhn" <[email protected]> > Cc: <[email protected]> > Sent: Thursday, May 02, 2019 12:35 PM > >> On Wed, 1 May 2019, Randy Presuhn wrote: >> >>> Hi - >>> >>> On 5/1/2019 12:46 PM, Mikael Abrahamsson wrote: >>> .... >>>> Where is the text that tells the server implementor whether to > throw an >>>> error when client commits non-zero bits, or to just throw the bits > away >>>> and store the value in the canonical format? >>> >>> Such text would be an inappropriate constraint the server's >>> internal representation. We should only specify >>> the externally-visible behaviour: that the reported value >>> will be in the canonical format. Whether an implementation >>> preserves extraneous cruft in its internal representation is >>> purely an implementation decision, and not subject to > standardization. >> >> I am talking about what goes on the wire. If the client does an >> edit-config with ipv6-prefix 2001:db8::1/64, should the server convert >> this into 2001:db8::/64 or throw an error on the edit-config > operation. >> >> Jurgen seems to say it should convert it and not throw an error, and > I'd >> like text to say that indeed, this is proper behaviour. Nobody has so > far >> been able to tell me where this text currently is, so that's why I'm >> asking for it to be added. Either this should go into an update to >> https://tools.ietf.org/html/rfc7950#section-9.1 or it should go into > each >> and every definition of types (or both of them). > > Mikael > > How about RFC791, still much quoted in all aspects of the work of the > IETF? > > " In general, an implementation must be conservative > in its sending behavior, and liberal in its receiving behavior. That > is, it must be careful to send well-formed datagrams, but must accept > any datagram that it can interpret (e.g., not object to technical > errors where the meaning is still clear)." > > We did not have MUST in those days, but had we, this would have been one > IMHO.
So, this is a good opportunity to mention what has bothered me during this discussion. Let's for a moment leave aside the "standards language" etc part, and instead consider "What's actually useful for people who try and run networks." NETCONF and YANG have the concept of validating configuration, this is very useful for users. In a previous job I incorrectly started out to use ipv4-prefix in a model where I really wanted an ipv4-address-and-prefix (i.e., an interface context). Now consider the reverse case then where the model really expects a prefix only, and the user for some reason thinks it will accept and can make use of an "address-and-prefix". The most obvious indication that the user has got this wrong is that they have host bits set. So if the server accepts the value but silently discards the host bits the error is not caught and the user and server probably have different ideas about what's going to happen. IOW, I don't think "where the meaning is still clear" applies to stripping host bits from a value, in fact I think it's more clear that stripping the host bits is actually ignoring (getting wrong) the user intent. Thanks, Chris. > > Tom Petch
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
