> 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. Lada > > > 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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
