Hi - >From: Martin Bjorklund <[email protected]> >Sent: Aug 19, 2015 11:43 PM >To: [email protected] >Cc: [email protected] >Subject: Re: [netmod] extensions and conformance > >Randy Presuhn <[email protected]> wrote: >> Hi - >> >> >From: Martin Bjorklund <[email protected]> >> >Sent: Aug 19, 2015 10:49 AM >> >To: [email protected] >> >Cc: [email protected] >> >Subject: Re: [netmod] extensions and conformance >> ... >> >> > Juergen suggested this replacement text, which I support. Maybe it >> >> > can be improved even more. >> >> > >> >> > If a YANG parser does not support a particular extension, which >> >> > appears in a YANG module as an unknown-statement (see Section >> >> > 13), >> >> > the entire unknown-statement MAY be ignored by the parser. Note >> >> > that even in this case the semantics associated with the >> >> > extension >> >> > still apply (as if they were part of a description statement). >> ... >> >No. It means that if a server advertises module that uses some >> >extension to define some behaviour, the server supports that >> >behavior. Just as we expect a server to support the text in >> >description statements. >> >> Sorry, but that interpretation is not supported by the 2119 definition >> of MAY. > >Note that the original text says "if x then MAY y". Juergen's text >says the same. Maybe this should be rephrased...
Under the RFC 2119 definition of "MAY", "if x then MAY y" is exactly the same as saying "if x then y is OPTIONAL". It really sounds like you mean to say "if x and z then MUST y", where "z" provides sufficient wiggle to permit situations where the augmentation may be absent for some instances, such as those exhibiting other augmentations. (I'm thinking about what one might see in a system with a bunch of interefaces employing different technologies, but whose management interfaces are all derived from a single abstract class and have various medium- specific extensions.) FWIW there are is another problem with the formulation in question: it's in terms of the capabilities of a particular Yang *parser*, not the client or server in which that parser finds itself. Randy _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
