> On 13 Oct 2015, at 18:53, Andy Bierman <[email protected]> wrote: > > > > On Tue, Oct 13, 2015 at 9:42 AM, Ladislav Lhotka <[email protected]> wrote: > > > On 13 Oct 2015, at 18:19, Andy Bierman <[email protected]> wrote: > > > > > > > > On Tue, Oct 13, 2015 at 5:40 AM, Ladislav Lhotka <[email protected]> wrote: > > > > > On 13 Oct 2015, at 12:42, Juergen Schoenwaelder > > > <[email protected]> wrote: > > > > > > On Tue, Oct 13, 2015 at 12:30:58PM +0200, Ladislav Lhotka wrote: > > >> > > >>> On 13 Oct 2015, at 12:19, Juergen Schoenwaelder > > >>> <[email protected]> wrote: > > >>> > > >>> On Tue, Oct 13, 2015 at 11:45:30AM +0200, Ladislav Lhotka wrote: > > >>>> David Reid <[email protected]> writes: > > >>>> > > >>>>> section 6.3.1 states: > > >>>>> > > >>>>> If a YANG compiler does not support a particular extension, which > > >>>>> appears in a YANG module as an unknown-statement (see Section 14), > > >>>>> the entire unknown-statement MAY be ignored by the compiler. > > >>>>> > > >>>>> If a YANG parser does not support a particular extension, which > > >>>>> appears in a YANG module as an unknown-statement (see Section 14), > > >>>>> the entire unknown-statement MAY be ignored by the parser. Note > > >>>> > > >>>> Implications of this statement are still not clear to me. Let's say > > >>>> some > > >>>> protocol introduces an extension that is critical for that > > >>>> protocol. Does the above sentence mean that an implementation of that > > >>>> protocol MAY ignore the extension if it happens to use a parser that > > >>>> doesn't support it? > > >>>> > > >>>> Lada > > >>>> > > >>>>> that even in this case the semantics associated with the extension > > >>>>> still apply (as if they were part of a description statement). > > >>>>> > > >>> > > >>> Did you read the following sentence: > > >>> > > >>> [...] Note that > > >>> even in this case the semantics associated with the extension still > > >>> apply (as if they were part of a description statement). > > >> > > >> Well, if the parser ignores the extension statement, then the > > >> application has no way to find out that the extension is present to be > > >> able to apply its semantics. > > >> > > > > > > Description statements have always to be taken into account. > > > > This is a different thing. Such a description would be a substatement to > > the "extension" (built-in) statement that defines the extension. In order > > to apply the semantics in appropriate places, an application must see where > > the extension statement is actually *used*. This is only possible if the > > underlying parser provides this information. > > > > > > > >>> I think it answers your question with a 'no'. > > >> > > >> Specifying behaviour of a YANG parser using 2119 keywords YANG parser > > >> doesn't make much sense to me, because it all depends on the purpose of > > >> the application that uses the parser. > > >> > > > > > > I do not get your point. The text says a parser may skip over an > > > extension it does not know how to process and it says the semantics > > > still apply as if they were part of a description statement. What > > > is the problem with this? > > > > If a protocol requires an extension to be honoured, then there is no excuse > > for the parser to ignore it. But the sentence I am objecting to says "MAY > > ignore" without any qualification. > > > > > > I do not want to change YANG wrt/ MAY skip over. > > We have been over this many times. > > > > Conformance to YANG for the extension: NONE > > This includes syntax and semantics. It makes no sense at all (Lada is > > right) > > to say the extension semantics apply. They only apply if the tool supports > > the extension. Conformance to the extension is a different matter. > > > > A generic YANG tool that is NOT claiming conformance to a particular > > external language statement can completely ignore that statement. > > Right, but this is something very different! The current formulation in > 6020bis (a parser MAY ignore) effectively undermines the possibility to > specify strict conformance rules wrt a certain extension in other documents. > > > > Good. > > IMO external statements are not part of YANG. > > External statements should not be used in a way that requires > interoperability between 2 or more entities. It should be completely > out of scope wrt/ YANG conformance.
If YANG conformance means "Is this a valid YANG data model or not?", then I think there is no ambiguity in 6020bis. IMO, the question is whether management protocols or other applications using YANG may define extensions with specific conformance rules, such as "Any implementation of protocol X MUST support extension Y." Other software that doesn't implement protocol X is then free to ignore extension Y, of course. The YANG spec should IMO say that conformance wrt extensions is out of scope. Lada > > I strongly object to changing this part of YANG. > It is critical that conformance to YANG does not include any > external statement semantics at all. > > A server MUST be able to parse all the tokens in a YANG module. > That is all that is required for external statements. Since YANG extensions > MUST NOT alter the syntax and semantics of real > YANG statements, a tool that only supports the official YANG language > statements can safely ignore all external statements.. > > > > > Lada > > > Andy > > > > > > > Lada > > > > > > Andy > > > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
