Re: [netmod] Yang mount / ysdl example use case
> On 03 Feb 2016, at 03:24, Kent Watsen wrote: > > > [Chair hat on] > > Given the number of competing/complementing drafts involved, and the general > lack of discussion on any of them, a virtual interim meeting might be an > expedient way to proceed. In fairness, we know that there has been some > discussion, but it hasn’t been picked up yet in a big way, and now Lou has an > updated draft. > > The chairs discussed maybe scheduling one for a couple weeks from now, > perhaps Thursday Feb 18 starting at 10am EST? I'm thinking Thursday at this time doesn't suit me very well, Monday till Wednesday of that week are OK. Lada > about this slot only since it worked for us for previously. Is this a good > time slot? I assume to schedule for 2 hours, with a plan to end early if > needed - makes sense? We also need to put together a proper agenda, > perhaps the following? > > 10 min: RTG DT YANG Arch team use-case summary > 20 min: draft-rtgyangdt-rtgwg-device-model > 20 min: draft-lhotka-netmod-ysdl > 20 min: draft-bjorklund-netmod-structural-mount > 50 min: general discussion or end early > > > We hope to schedule the meeting itself tomorrow or the next day, so please > respond quickly to this email if possible. > > Thanks, > Kent and Tom > > > > > On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger" on behalf of lber...@labn.net> wrote: > >> >> I thought it would be worth summarizing what we're looking for in our >> draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in case >> you missed it) with respect to the draft-lhotka-netmod-ysdl and >> draft-bjorklund-netmod-structural-mount drafts. This is just my view, so >> my co-authors may wish to chime in and correct me. >> >> I'd be interested in hearing from the authors of YSDL and >> structural-mount, or anyone else for that matter, on how they see to >> best meet these needs. >> >> Here's what I think our draft needs: >> >> 1. that there be a mechanism that allows the incorporation (or >> 'mounting') of the data model defined by one top-level module >> within another module. >> >> The implication here is that when information is instantiated >> for the parent model it is also instantiated for the >> incorporated/mounted model. In our case we expect to do this on >> list element creation. Both solutions drafts cover the path >> implications, so these are not repeated here. >> >> 2. that this mechanism allow identification of specific modules to >> be incorporated/mounted at time of module definition, i.e. that >> no additional module is needed to support 1. This doesn't >> preclude definition of such a module. >> >> 3. that this mechanism allow for a server to control (and >> identify) which modules are incorporated/mounted. (see Section >> 3 LNE in our draft for an envisioned usage.) >> >> 4. that all capabilities that exist with the mounted module are >> available e.g. RPC operations and notifications. >> >> 5. while our primary requirement is for 'mounting' of top level >> modules, mounting of submodules may also be useful. (DT not draft >> driven.) >> >> We make use of the above in sections 3 and 4 of rtgwg-device-model. We >> see having a solution as critical for the simplifications/flexibility >> represented in the -02 version of our draft vs the -03 rev. We don't >> see wither solution draft as significantly different and just hope for a >> standard solution as soon as possible. (a draft-ietf-netmod solutions >> draft on the topic by BA would be fantastic given the impact on routing >> area -- even if it had to document two variations / alternative solutions.) >> >> Again, this is just my opinion and my coauthors or others on the rtg >> area yang DT may choose to chime in. >> >> Lou >> >> >> >> ___ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] chars that require quoting
> On 03 Feb 2016, at 05:02, Andy Bierman wrote:
>
>
>
> On Tue, Feb 2, 2016 at 9:50 AM, Ladislav Lhotka wrote:
>
> > On 02 Feb 2016, at 18:25, Andy Bierman wrote:
> >
> >
> >
> > On Tue, Feb 2, 2016 at 4:04 AM, Jernej Tuljak
> > wrote:
> > Ladislav Lhotka je 2.2.2016 ob 12:25 napisal:
> > On 02 Feb 2016, at 12:16, Martin Bjorklund wrote:
> >
> > Ladislav Lhotka wrote:
> > On 02 Feb 2016, at 09:51, Jernej Tuljak wrote:
> >
> > Martin Bjorklund je 1.2.2016 ob 20:48 napisal:
> > Juergen Schoenwaelder wrote:
> > If a specification is not explicit enough, then people often implement
> > what they find implemented in other similar contexts. This means the
> > code often ends up reflecting which tools an implementor was familiar
> > with. In a shell, echo f\"oo gives you f"oo (and the same is true for
> > Tcl, which has otherwise the behavior you implemented for pyang,
> > treating " as a regular character in an unquoted string.)
> >
> > It would help to know what implementations do with identifiers like
> > f"o"o and f\"o\"o. If they do different things, then there is likely
> > some evidence that implementors arrived at different conclusions.
> > I don't mind a clarification. How about:
> >
> > OLD:
> >
> > If a string contains any space, tab, or newline characters, a
> > semicolon (";"), braces ("{" or "}"), or comment sequences ("//",
> > "/*", or "*/"), then it MUST be enclosed within double or single
> > quotes.
> >
> > NEW:
> >
> > If a string contains any space, tab, or newline characters, a
> > semicolon (";"), braces ("{" or "}"), or comment sequences ("//",
> > "/*", or "*/"), then it MUST be enclosed within double or single
> > quotes. If a string does not contain any of these characters, it
> > MAY be unquoted.
> >
> > Within an unquoted string, every character is preserved. Note that
> > this means that the backslash, single quote, and double quote
> > characters can occur in an unquoted string.
> > I don't think this can be implemented, like I did not in the linked
> > archive. It does not make clear whether these are two statements or a
> > single one:
> >
> > default ";
> > units ";
> >
> >
> > What about this:
> >
> > default ";//foo";
> > units \";
> >
> >
> > This is not the C and C++ way of doing things (possibly not even SMIng
> > way). These are the only languages mentioned in the document (Section 6).
> > It also does not promote readability and makes lexers unnecessarily complex.
> > +1
> >
> > I think the safest solution would be to disallow in unquoted strings
> > all characters that have a special meaning anywhere in YANG
> > syntax. This can hardly cause any troubles to module authors.
> > Fine with me. Something like:
> >
> > NEW:
> >
> > If a string contains any space, tab, or newline characters, a single
> > or double quote, semicolon (";"), braces ("{" or "}"), or comment
> > sequences ("//", "/*", or "*/"), then it MUST be enclosed within
> > double or single quotes. If a string does not contain any of these
> > characters, it MAY be unquoted.
> >
> > Within an unquoted string, every character is preserved. Note that
> > this means that the backslash character does not have any special
> > meaning in an unquoted string.
> > I like this.
> >
> > +1
> >
> >
> >
> > I don't understand this text.
> > The parser looks for certain tokens in specific contexts.
> >
> >
> > container A;container B;container C;
> >
> > container foo{container bar{container baz;}}
> >
> > augment /foo/bar/baz{container Z;}
> >
> > pyang and yangdump-pro handle these unquoted strings correctly.
> >
> > I think your text is supposed to mean that chars with special meanings
> > in specific contexts need to be quoted to use them as plain chars without
> > any special meaning.
> >
> > I strongly object to this new text since it tells the YANG author they
> > cannot use unquoted strings like the examples above.
>
> Why do you think there is anything in the new text to this effect? All of
> your examples remain perfectly OK. The only change compared to 6020bis-09 is
> that the newline, single- and double-quote characters cannot appear in
> unquoted argument strings.
>
>
>
> If a string contains any space, tab, or newline characters, a single
> > or double quote, semicolon (";"), braces ("{" or "}"), or comment
> > sequences ("//", "/*", or "*/"), then it MUST be enclosed within
> > double or single quotes.
>
>
> This is not true; The example above contains valid unquoted strings that
> contain a semicolon.
Huh? The text is about characters in unquoted *argument* strings. The
semicolons in your examples aren't syntactically part of an argument. This
hasn't changed: semicolons and curly braces were not permitted in an unquoted
argument already in YANG 1.0.
Lada
>
> The only strings that MUST be encoded in quotes are a single quote or double
> quote.
> All parsers will look for the closing quote and there won't be
Re: [netmod] chars that require quoting
On Tue, Feb 2, 2016 at 9:50 AM, Ladislav Lhotka wrote:
>
> > On 02 Feb 2016, at 18:25, Andy Bierman wrote:
> >
> >
> >
> > On Tue, Feb 2, 2016 at 4:04 AM, Jernej Tuljak
> wrote:
> > Ladislav Lhotka je 2.2.2016 ob 12:25 napisal:
> > On 02 Feb 2016, at 12:16, Martin Bjorklund wrote:
> >
> > Ladislav Lhotka wrote:
> > On 02 Feb 2016, at 09:51, Jernej Tuljak
> wrote:
> >
> > Martin Bjorklund je 1.2.2016 ob 20:48 napisal:
> > Juergen Schoenwaelder wrote:
> > If a specification is not explicit enough, then people often implement
> > what they find implemented in other similar contexts. This means the
> > code often ends up reflecting which tools an implementor was familiar
> > with. In a shell, echo f\"oo gives you f"oo (and the same is true for
> > Tcl, which has otherwise the behavior you implemented for pyang,
> > treating " as a regular character in an unquoted string.)
> >
> > It would help to know what implementations do with identifiers like
> > f"o"o and f\"o\"o. If they do different things, then there is likely
> > some evidence that implementors arrived at different conclusions.
> > I don't mind a clarification. How about:
> >
> > OLD:
> >
> > If a string contains any space, tab, or newline characters, a
> > semicolon (";"), braces ("{" or "}"), or comment sequences ("//",
> > "/*", or "*/"), then it MUST be enclosed within double or single
> > quotes.
> >
> > NEW:
> >
> > If a string contains any space, tab, or newline characters, a
> > semicolon (";"), braces ("{" or "}"), or comment sequences ("//",
> > "/*", or "*/"), then it MUST be enclosed within double or single
> > quotes. If a string does not contain any of these characters, it
> > MAY be unquoted.
> >
> > Within an unquoted string, every character is preserved. Note that
> > this means that the backslash, single quote, and double quote
> > characters can occur in an unquoted string.
> > I don't think this can be implemented, like I did not in the linked
> archive. It does not make clear whether these are two statements or a
> single one:
> >
> > default ";
> > units ";
> >
> >
> > What about this:
> >
> > default ";//foo";
> > units \";
> >
> >
> > This is not the C and C++ way of doing things (possibly not even SMIng
> way). These are the only languages mentioned in the document (Section 6).
> It also does not promote readability and makes lexers unnecessarily complex.
> > +1
> >
> > I think the safest solution would be to disallow in unquoted strings
> > all characters that have a special meaning anywhere in YANG
> > syntax. This can hardly cause any troubles to module authors.
> > Fine with me. Something like:
> >
> > NEW:
> >
> > If a string contains any space, tab, or newline characters, a single
> > or double quote, semicolon (";"), braces ("{" or "}"), or comment
> > sequences ("//", "/*", or "*/"), then it MUST be enclosed within
> > double or single quotes. If a string does not contain any of these
> > characters, it MAY be unquoted.
> >
> > Within an unquoted string, every character is preserved. Note that
> > this means that the backslash character does not have any special
> > meaning in an unquoted string.
> > I like this.
> >
> > +1
> >
> >
> >
> > I don't understand this text.
> > The parser looks for certain tokens in specific contexts.
> >
> >
> > container A;container B;container C;
> >
> > container foo{container bar{container baz;}}
> >
> > augment /foo/bar/baz{container Z;}
> >
> > pyang and yangdump-pro handle these unquoted strings correctly.
> >
> > I think your text is supposed to mean that chars with special meanings
> > in specific contexts need to be quoted to use them as plain chars without
> > any special meaning.
> >
> > I strongly object to this new text since it tells the YANG author they
> > cannot use unquoted strings like the examples above.
>
> Why do you think there is anything in the new text to this effect? All of
> your examples remain perfectly OK. The only change compared to 6020bis-09
> is that the newline, single- and double-quote characters cannot appear in
> unquoted argument strings.
>
>
*If a string contains* any space, tab, or newline characters, a single
> or double quote, *semicolon (";"),* braces ("{" or "}"), or comment
> sequences ("//", "/*", or "*/"), t
*hen it MUST be enclosed within> double or single quotes. *
This is not true; The example above contains valid unquoted strings that
contain a semicolon.
The only strings that MUST be encoded in quotes are a single quote or
double quote.
All parsers will look for the closing quote and there won't be one.
IMO the only next needed:
NEW:
If a string contains any single quote characters, then it MUST be
enclosed within
double quotes. If a string contains any double quote characters, then
it MUST be
enclosed within single quotes, or encoded within double quotes using an
escape
character '\', followed by the double quote character '"'.
> Lada
>
Re: [netmod] Yang mount / ysdl example use case
[Chair hat on] Given the number of competing/complementing drafts involved, and the general lack of discussion on any of them, a virtual interim meeting might be an expedient way to proceed. In fairness, we know that there has been some discussion, but it hasn’t been picked up yet in a big way, and now Lou has an updated draft. The chairs discussed maybe scheduling one for a couple weeks from now, perhaps Thursday Feb 18 starting at 10am EST? I'm thinking about this slot only since it worked for us for previously. Is this a good time slot? I assume to schedule for 2 hours, with a plan to end early if needed - makes sense? We also need to put together a proper agenda, perhaps the following? 10 min: RTG DT YANG Arch team use-case summary 20 min: draft-rtgyangdt-rtgwg-device-model 20 min: draft-lhotka-netmod-ysdl 20 min: draft-bjorklund-netmod-structural-mount 50 min: general discussion or end early We hope to schedule the meeting itself tomorrow or the next day, so please respond quickly to this email if possible. Thanks, Kent and Tom On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger" wrote: > >I thought it would be worth summarizing what we're looking for in our >draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in case >you missed it) with respect to the draft-lhotka-netmod-ysdl and >draft-bjorklund-netmod-structural-mount drafts. This is just my view, so >my co-authors may wish to chime in and correct me. > >I'd be interested in hearing from the authors of YSDL and >structural-mount, or anyone else for that matter, on how they see to >best meet these needs. > >Here's what I think our draft needs: > >1. that there be a mechanism that allows the incorporation (or > 'mounting') of the data model defined by one top-level module > within another module. > > The implication here is that when information is instantiated > for the parent model it is also instantiated for the > incorporated/mounted model. In our case we expect to do this on > list element creation. Both solutions drafts cover the path > implications, so these are not repeated here. > >2. that this mechanism allow identification of specific modules to > be incorporated/mounted at time of module definition, i.e. that > no additional module is needed to support 1. This doesn't > preclude definition of such a module. > >3. that this mechanism allow for a server to control (and > identify) which modules are incorporated/mounted. (see Section > 3 LNE in our draft for an envisioned usage.) > >4. that all capabilities that exist with the mounted module are > available e.g. RPC operations and notifications. > >5. while our primary requirement is for 'mounting' of top level > modules, mounting of submodules may also be useful. (DT not draft > driven.) > >We make use of the above in sections 3 and 4 of rtgwg-device-model. We >see having a solution as critical for the simplifications/flexibility >represented in the -02 version of our draft vs the -03 rev. We don't >see wither solution draft as significantly different and just hope for a >standard solution as soon as possible. (a draft-ietf-netmod solutions >draft on the topic by BA would be fantastic given the impact on routing >area -- even if it had to document two variations / alternative solutions.) > >Again, this is just my opinion and my coauthors or others on the rtg >area yang DT may choose to chime in. > >Lou > > > >___ >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
[netmod] Yang mount / ysdl example use case
I thought it would be worth summarizing what we're looking for in our draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version in case you missed it) with respect to the draft-lhotka-netmod-ysdl and draft-bjorklund-netmod-structural-mount drafts. This is just my view, so my co-authors may wish to chime in and correct me. I'd be interested in hearing from the authors of YSDL and structural-mount, or anyone else for that matter, on how they see to best meet these needs. Here's what I think our draft needs: 1. that there be a mechanism that allows the incorporation (or 'mounting') of the data model defined by one top-level module within another module. The implication here is that when information is instantiated for the parent model it is also instantiated for the incorporated/mounted model. In our case we expect to do this on list element creation. Both solutions drafts cover the path implications, so these are not repeated here. 2. that this mechanism allow identification of specific modules to be incorporated/mounted at time of module definition, i.e. that no additional module is needed to support 1. This doesn't preclude definition of such a module. 3. that this mechanism allow for a server to control (and identify) which modules are incorporated/mounted. (see Section 3 LNE in our draft for an envisioned usage.) 4. that all capabilities that exist with the mounted module are available e.g. RPC operations and notifications. 5. while our primary requirement is for 'mounting' of top level modules, mounting of submodules may also be useful. (DT not draft driven.) We make use of the above in sections 3 and 4 of rtgwg-device-model. We see having a solution as critical for the simplifications/flexibility represented in the -02 version of our draft vs the -03 rev. We don't see wither solution draft as significantly different and just hope for a standard solution as soon as possible. (a draft-ietf-netmod solutions draft on the topic by BA would be fantastic given the impact on routing area -- even if it had to document two variations / alternative solutions.) Again, this is just my opinion and my coauthors or others on the rtg area yang DT may choose to chime in. Lou ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] 'uses' as a sub-statement to 'choice' statement?
>This has already been discussed, see > >https://mailarchive.ietf.org/arch/search/?email_list=netmod&gbt=1&index=uF7kbBPMxIBAMUm03D3AqxaJvK4 Okay, good answer. Never mind. Thanks, Kent ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] IPR Check: draft-ietf-netmod-opstate-reqs-01
"Carl Moberg (camoberg)" wrote: > > I am not aware of any IPR. Me neither. /martin > > > On Jan 26, 2016, at 4:26 PM, Benoit Claise (bclaise) > > wrote: > > > > I'm not aware of any IPR. > > > > Regards, Benoit > >> This mail starts the IPR poll on draft-ietf-netmod-opstate-reqs-01. > >> > >> Are you aware of any IPR that applies to draft-ietf-netmod-opstate-reqs-01? > >> If so, has this IPR been disclosed in compliance with IETF IPR rules (see > >> RFCs > >> 3979, 4879, 3669 and 5378 for more details)? > >> > >> If you are listed as a document author or contributor please respond to > >> this > >> email explicitly regardless of whether or not you are aware of any > >> relevant IPR. > >> The response needs to be sent to the NETMOD WG mailing list. The document > >> will not advance to the next stage until a response has been received from > >> each > >> author and contributor. > >> > >> If you are on the NETMOD WG email list but are not listed as an author or > >> contributor, then please explicitly respond only if you are aware of any > >> IPR that > >> has not yet been disclosed in conformance with IETF rules. > >> > >> Thank you, > >> > >> Kent and Tom, NETMOD WG Chairs > >> > >> ___ > >> 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 > > ___ > 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
Re: [netmod] 'uses' as a sub-statement to 'choice' statement?
Hi,
I do not think this is a bug.
The uses-stmt has no node name, just a grouping name,
which may have a prefix.
In the example above 'ethernet' and 'optical' are forced to
be local names and be unique local names.
Andy
On Tue, Feb 2, 2016 at 9:39 AM, Kent Watsen wrote:
>
> In a model where the choice shorthand notation is being used, it is
> necessary to use longhand notation if wanting a case statement to be
> defined by the ‘uses’ statement. That is, 6020bis allows ‘uses’ as a
> sub-statement to the ‘case’ statement, but not to the ‘choice’ statement.
> As an example, this choice statement:
>
> choice interface-type {
>case ethernet {
> uses ethernet;
>}
>case optical {
> uses optical;
>}
> }
>
> Cannot use shorthand notation:
>
> choice interface-type {
>uses ethernet;
>uses optical;
> }
>
>
> This seems like a bug to me. Is it too late to fix in 6020bis as an
> issue raised by WGLC?
>
> Kent // as a contributor
>
>
>
> ___
> 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
Re: [netmod] 'uses' as a sub-statement to 'choice' statement?
> On 02 Feb 2016, at 18:39, Kent Watsen wrote:
>
>
> In a model where the choice shorthand notation is being used, it is necessary
> to use longhand notation if wanting a case statement to be defined by the
> ‘uses’ statement. That is, 6020bis allows ‘uses’ as a sub-statement to the
> ‘case’ statement, but not to the ‘choice’ statement. As an example, this
> choice statement:
>
> choice interface-type {
> case ethernet {
> uses ethernet;
> }
> case optical {
> uses optical;
> }
> }
>
> Cannot use shorthand notation:
>
> choice interface-type {
> uses ethernet;
> uses optical;
> }
>
>
> This seems like a bug to me. Is it too late to fix in 6020bis as an issue
> raised by WGLC?
This has already been discussed, see
https://mailarchive.ietf.org/arch/search/?email_list=netmod&gbt=1&index=uF7kbBPMxIBAMUm03D3AqxaJvK4
Lada
>
> Kent // as a contributor
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] I-D Action: draft-kwatsen-netmod-opstate-02.txt
Hi All, I didn’t receive the usual announcement CC-ed to the netmod list, so I’m replying to this one sent to the id-announce list instead. Anyway, this morning I posted -01 of this draft and then shortly after -02 to fix some cleanup items I only noticed after -01 was posted :ooops: Either way, this update is an overhaul to the original draft posted last September. Kent On 2/2/16, 10:30 AM, "internet-dra...@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > >Title : Operational State Enhancements for YANG, NETCONF, > and RESTCONF >Authors : Kent Watsen > Andy Bierman > Martin Bjorklund > Juergen Schoenwaelder > Filename: draft-kwatsen-netmod-opstate-02.txt > Pages : 27 > Date: 2016-02-02 > >Abstract: > This document presents enhancements to YANG, NETCONF, and RESTCONF > satisfying the requirements set forth in Terminology and Requirements > for Enhanced Handling of Operational State. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-kwatsen-netmod-opstate/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=draft-kwatsen-netmod-opstate-02 > > >Please note that it may take a couple of minutes from the time of submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >___ >I-D-Announce mailing list >i-d-annou...@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] chars that require quoting
> On 02 Feb 2016, at 18:25, Andy Bierman wrote:
>
>
>
> On Tue, Feb 2, 2016 at 4:04 AM, Jernej Tuljak
> wrote:
> Ladislav Lhotka je 2.2.2016 ob 12:25 napisal:
> On 02 Feb 2016, at 12:16, Martin Bjorklund wrote:
>
> Ladislav Lhotka wrote:
> On 02 Feb 2016, at 09:51, Jernej Tuljak wrote:
>
> Martin Bjorklund je 1.2.2016 ob 20:48 napisal:
> Juergen Schoenwaelder wrote:
> If a specification is not explicit enough, then people often implement
> what they find implemented in other similar contexts. This means the
> code often ends up reflecting which tools an implementor was familiar
> with. In a shell, echo f\"oo gives you f"oo (and the same is true for
> Tcl, which has otherwise the behavior you implemented for pyang,
> treating " as a regular character in an unquoted string.)
>
> It would help to know what implementations do with identifiers like
> f"o"o and f\"o\"o. If they do different things, then there is likely
> some evidence that implementors arrived at different conclusions.
> I don't mind a clarification. How about:
>
> OLD:
>
> If a string contains any space, tab, or newline characters, a
> semicolon (";"), braces ("{" or "}"), or comment sequences ("//",
> "/*", or "*/"), then it MUST be enclosed within double or single
> quotes.
>
> NEW:
>
> If a string contains any space, tab, or newline characters, a
> semicolon (";"), braces ("{" or "}"), or comment sequences ("//",
> "/*", or "*/"), then it MUST be enclosed within double or single
> quotes. If a string does not contain any of these characters, it
> MAY be unquoted.
>
> Within an unquoted string, every character is preserved. Note that
> this means that the backslash, single quote, and double quote
> characters can occur in an unquoted string.
> I don't think this can be implemented, like I did not in the linked archive.
> It does not make clear whether these are two statements or a single one:
>
> default ";
> units ";
>
>
> What about this:
>
> default ";//foo";
> units \";
>
>
> This is not the C and C++ way of doing things (possibly not even SMIng way).
> These are the only languages mentioned in the document (Section 6). It also
> does not promote readability and makes lexers unnecessarily complex.
> +1
>
> I think the safest solution would be to disallow in unquoted strings
> all characters that have a special meaning anywhere in YANG
> syntax. This can hardly cause any troubles to module authors.
> Fine with me. Something like:
>
> NEW:
>
> If a string contains any space, tab, or newline characters, a single
> or double quote, semicolon (";"), braces ("{" or "}"), or comment
> sequences ("//", "/*", or "*/"), then it MUST be enclosed within
> double or single quotes. If a string does not contain any of these
> characters, it MAY be unquoted.
>
> Within an unquoted string, every character is preserved. Note that
> this means that the backslash character does not have any special
> meaning in an unquoted string.
> I like this.
>
> +1
>
>
>
> I don't understand this text.
> The parser looks for certain tokens in specific contexts.
>
>
> container A;container B;container C;
>
> container foo{container bar{container baz;}}
>
> augment /foo/bar/baz{container Z;}
>
> pyang and yangdump-pro handle these unquoted strings correctly.
>
> I think your text is supposed to mean that chars with special meanings
> in specific contexts need to be quoted to use them as plain chars without
> any special meaning.
>
> I strongly object to this new text since it tells the YANG author they
> cannot use unquoted strings like the examples above.
Why do you think there is anything in the new text to this effect? All of your
examples remain perfectly OK. The only change compared to 6020bis-09 is that
the newline, single- and double-quote characters cannot appear in unquoted
argument strings.
Lada
>
>
> Andy
>
>
> It should be noted that this may be viewed as a backwards incompatible
> change, but I think it is similar to the change for escaped characters
> in double quoted string ("backwards incompatible bugfix").
> Yes, I think so.
>
> This is nothing compared to the change of the accessible tree for output.
>
> Jernej
>
>
> Thanks, Lada
>
>
>
> /martin
>
>
>
> BTW, if we wanted to be extremely liberal, I don't understand why the
> end-comment sequence "*/" is not allowed.
>
> Lada
>
> Jernej
>
> /martin
>
> ___
> 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
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listi
[netmod] 'uses' as a sub-statement to 'choice' statement?
In a model where the choice shorthand notation is being used, it is necessary
to use longhand notation if wanting a case statement to be defined by the
‘uses’ statement. That is, 6020bis allows ‘uses’ as a sub-statement to the
‘case’ statement, but not to the ‘choice’ statement. As an example, this
choice statement:
choice interface-type {
case ethernet {
uses ethernet;
}
case optical {
uses optical;
}
}
Cannot use shorthand notation:
choice interface-type {
uses ethernet;
uses optical;
}
This seems like a bug to me. Is it too late to fix in 6020bis as an issue
raised by WGLC?
Kent // as a contributor
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] chars that require quoting
On Tue, Feb 2, 2016 at 4:04 AM, Jernej Tuljak
wrote:
> Ladislav Lhotka je 2.2.2016 ob 12:25 napisal:
>
>> On 02 Feb 2016, at 12:16, Martin Bjorklund wrote:
>>>
>>> Ladislav Lhotka wrote:
>>>
On 02 Feb 2016, at 09:51, Jernej Tuljak
> wrote:
>
> Martin Bjorklund je 1.2.2016 ob 20:48 napisal:
>
>> Juergen Schoenwaelder wrote:
>>
>>> If a specification is not explicit enough, then people often
>>> implement
>>> what they find implemented in other similar contexts. This means the
>>> code often ends up reflecting which tools an implementor was familiar
>>> with. In a shell, echo f\"oo gives you f"oo (and the same is true for
>>> Tcl, which has otherwise the behavior you implemented for pyang,
>>> treating " as a regular character in an unquoted string.)
>>>
>>> It would help to know what implementations do with identifiers like
>>> f"o"o and f\"o\"o. If they do different things, then there is likely
>>> some evidence that implementors arrived at different conclusions.
>>>
>> I don't mind a clarification. How about:
>>
>> OLD:
>>
>> If a string contains any space, tab, or newline characters, a
>> semicolon (";"), braces ("{" or "}"), or comment sequences ("//",
>> "/*", or "*/"), then it MUST be enclosed within double or single
>> quotes.
>>
>> NEW:
>>
>> If a string contains any space, tab, or newline characters, a
>> semicolon (";"), braces ("{" or "}"), or comment sequences ("//",
>> "/*", or "*/"), then it MUST be enclosed within double or single
>> quotes. If a string does not contain any of these characters, it
>> MAY be unquoted.
>>
>> Within an unquoted string, every character is preserved. Note that
>> this means that the backslash, single quote, and double quote
>> characters can occur in an unquoted string.
>>
> I don't think this can be implemented, like I did not in the linked
> archive. It does not make clear whether these are two statements or a
> single one:
>
> default ";
> units ";
>
>
> What about this:
>
> default ";//foo";
> units \";
>
>
> This is not the C and C++ way of doing things (possibly not even SMIng
> way). These are the only languages mentioned in the document (Section 6).
> It also does not promote readability and makes lexers unnecessarily
> complex.
>
+1
I think the safest solution would be to disallow in unquoted strings
all characters that have a special meaning anywhere in YANG
syntax. This can hardly cause any troubles to module authors.
>>> Fine with me. Something like:
>>>
>>> NEW:
>>>
>>> If a string contains any space, tab, or newline characters, a single
>>> or double quote, semicolon (";"), braces ("{" or "}"), or comment
>>> sequences ("//", "/*", or "*/"), then it MUST be enclosed within
>>> double or single quotes. If a string does not contain any of these
>>> characters, it MAY be unquoted.
>>>
>>> Within an unquoted string, every character is preserved. Note that
>>> this means that the backslash character does not have any special
>>> meaning in an unquoted string.
>>>
>> I like this.
>>
>
> +1
>
>
>>
I don't understand this text.
The parser looks for certain tokens in specific contexts.
container A;container B;container C;
container foo{container bar{container baz;}}
augment /foo/bar/baz{container Z;}
pyang and yangdump-pro handle these unquoted strings correctly.
I think your text is supposed to mean that chars with special meanings
in specific contexts need to be quoted to use them as plain chars without
any special meaning.
I strongly object to this new text since it tells the YANG author they
cannot use unquoted strings like the examples above.
Andy
>>> It should be noted that this may be viewed as a backwards incompatible
>>> change, but I think it is similar to the change for escaped characters
>>> in double quoted string ("backwards incompatible bugfix").
>>>
>> Yes, I think so.
>>
>
> This is nothing compared to the change of the accessible tree for output.
>
> Jernej
>
>
>> Thanks, Lada
>>
>>
>>>
>>> /martin
>>>
>>>
>>>
>>> BTW, if we wanted to be extremely liberal, I don't understand why the
end-comment sequence "*/" is not allowed.
Lada
Jernej
>
> /martin
>>
>> ___
>> 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
>
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
>>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>>
>>
> __
[netmod] Last Call: (Terminology and Requirements for Enhanced Handling of Operational State) to Informational RFC
The IESG has received a request from the NETCONF Data Modeling Language WG (netmod) to consider the following document: - 'Terminology and Requirements for Enhanced Handling of Operational State' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2016-02-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document primarily regards the difference between the intended configuration and the applied configuration of a device and how intended and applied configuration relate to the operational state of a device. This document defines requirements for the applied configuration's data model and its values, as well as for enabling a client to know when a configuration has been fully applied or not, how to access operational state, and how to relate intended configuration nodes to applied configuration and derived state nodes. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/ballot/ No IPR declarations have been submitted directly on this I-D. ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] [yang-doctors] I-D Action: draft-ietf-netmod-opstate-reqs-04.txt
Dear all, I started the IETF last call process on draft-ietf-netmod-opstate-reqs-04. Regards, Benoit [Speaking as co-chair] Benoit, I believe the document is now ready for your AD review. —Tom On Jan 22, 2016:8:37 PM, at 8:37 PM, Kent Watsen wrote: [As a contributor] This update contains the following changes: 1) removed “(see term)” throughout 2) moved 2nd-half of the Asynchronous Configuration Operation term to new requirement 2-B 3) moved the Backwards Compatibility to new requirement 5 4) made some may/MAY/SHOULD/MUST changes (as discussed on list) 5) replaced map/mapping with relate/relationships Please see the diff for details. Thanks, Kent On 1/22/16, 8:29 PM, "netmod on behalf of internet-dra...@ietf.org" wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Terminology and Requirements for Enhanced Handling of Operational State Authors : Kent Watsen Thomas Nadeau Filename: draft-ietf-netmod-opstate-reqs-04.txt Pages : 6 Date: 2016-01-22 Abstract: This document primarily regards the difference between the intended configuration and the applied configuration of a device and how intended and applied configuration relate to the operational state of a device. This document defines requirements for the applied configuration's data model and its values, as well as for enabling a client to know when a configuration has been fully applied or not, how to access operational state, and how to relate intended configuration nodes to applied configuration and derived state nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-opstate-reqs-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ 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 ___ yang-doctors mailing list yang-doct...@ietf.org https://www.ietf.org/mailman/listinfo/yang-doctors ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] chars that require quoting
Ladislav Lhotka je 2.2.2016 ob 12:25 napisal:
On 02 Feb 2016, at 12:16, Martin Bjorklund wrote:
Ladislav Lhotka wrote:
On 02 Feb 2016, at 09:51, Jernej Tuljak wrote:
Martin Bjorklund je 1.2.2016 ob 20:48 napisal:
Juergen Schoenwaelder wrote:
If a specification is not explicit enough, then people often implement
what they find implemented in other similar contexts. This means the
code often ends up reflecting which tools an implementor was familiar
with. In a shell, echo f\"oo gives you f"oo (and the same is true for
Tcl, which has otherwise the behavior you implemented for pyang,
treating " as a regular character in an unquoted string.)
It would help to know what implementations do with identifiers like
f"o"o and f\"o\"o. If they do different things, then there is likely
some evidence that implementors arrived at different conclusions.
I don't mind a clarification. How about:
OLD:
If a string contains any space, tab, or newline characters, a
semicolon (";"), braces ("{" or "}"), or comment sequences ("//",
"/*", or "*/"), then it MUST be enclosed within double or single
quotes.
NEW:
If a string contains any space, tab, or newline characters, a
semicolon (";"), braces ("{" or "}"), or comment sequences ("//",
"/*", or "*/"), then it MUST be enclosed within double or single
quotes. If a string does not contain any of these characters, it
MAY be unquoted.
Within an unquoted string, every character is preserved. Note that
this means that the backslash, single quote, and double quote
characters can occur in an unquoted string.
I don't think this can be implemented, like I did not in the linked archive. It
does not make clear whether these are two statements or a single one:
default ";
units ";
What about this:
default ";//foo";
units \";
This is not the C and C++ way of doing things (possibly not even SMIng way).
These are the only languages mentioned in the document (Section 6). It also
does not promote readability and makes lexers unnecessarily complex.
+1
I think the safest solution would be to disallow in unquoted strings
all characters that have a special meaning anywhere in YANG
syntax. This can hardly cause any troubles to module authors.
Fine with me. Something like:
NEW:
If a string contains any space, tab, or newline characters, a single
or double quote, semicolon (";"), braces ("{" or "}"), or comment
sequences ("//", "/*", or "*/"), then it MUST be enclosed within
double or single quotes. If a string does not contain any of these
characters, it MAY be unquoted.
Within an unquoted string, every character is preserved. Note that
this means that the backslash character does not have any special
meaning in an unquoted string.
I like this.
+1
It should be noted that this may be viewed as a backwards incompatible
change, but I think it is similar to the change for escaped characters
in double quoted string ("backwards incompatible bugfix").
Yes, I think so.
This is nothing compared to the change of the accessible tree for output.
Jernej
Thanks, Lada
/martin
BTW, if we wanted to be extremely liberal, I don't understand why the end-comment
sequence "*/" is not allowed.
Lada
Jernej
/martin
___
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
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] minor question - YANG Document Guidelines: Imports
On 02/02/2016 11:21, Martin Bjorklund wrote: Robert Wilton wrote: On 28/01/2016 20:01, Juergen Schoenwaelder wrote: On Thu, Jan 28, 2016 at 01:57:22PM -0500, Joel M. Halpern wrote: I ran into something while reading a YANG internet-draft recently, and I wonder if a bit of advice in the YANG Document Guidelines (rfc6087bis) would be reasonable. Section 4.8 of the guidelines states that any imported modules must also have a reference in the references section. Which is good. But there is no obvious way for a human reader to relate the two. Would it be sensible to recommend in this document (I don't know if it would be 4.8 or a new section later in the document) that import statements have a comment with them either naming the internet draft / RFC they are importing from, or pointing to the reference which names it? Perhaps RFC 6087bis can give additional guidelines. The common way to get the references into the enclosing document is to include a statement before the definitions that says something like: This module imports from the defined in [RFCXYZ] and form the defined in [RFCABC]. To help readers that have the module and who do not want to bother looking up the document, including comments may help. It is kind of funny that YANG does not allow reference statements on imports... It is too late to add this to Yang 1.1? That would seem to be the cleanest solution. It seems to me that allowing "reference" under "import" (and "include") is a "safe" change, i.e., I support adding it even though it is pretty late in the process. One thing to note is that in the current grammar, "reference" and "description" are always allowed together - does it make sense to allow "description" in the import/include as well? I would say yes. I can't see that it would cause any harm, nor does it look like it would be particularly burdensome to implement. E.g. it could be a useful way of documenting if an import was only required for a slightly more obscure reason. In general it feels like documenting the YANG model using descriptions/references is probably better than comments which are likely to only be available in the YANG source file and then get stripped out during parsing. Rob /martin I was under the, possibly mistaken, assumption that various YANG tools effectively ignore/strip out the comments and hence comments are better embedded directly in the model as either reference or description statements. Rob /js ___ 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
Re: [netmod] minor question - YANG Document Guidelines: Imports
> On 02 Feb 2016, at 12:21, Martin Bjorklund wrote: > > Robert Wilton wrote: >> On 28/01/2016 20:01, Juergen Schoenwaelder wrote: >>> On Thu, Jan 28, 2016 at 01:57:22PM -0500, Joel M. Halpern wrote: I ran into something while reading a YANG internet-draft recently, and I wonder if a bit of advice in the YANG Document Guidelines (rfc6087bis) would be reasonable. Section 4.8 of the guidelines states that any imported modules must also have a reference in the references section. Which is good. But there is no obvious way for a human reader to relate the two. Would it be sensible to recommend in this document (I don't know if it would be 4.8 or a new section later in the document) that import statements have a comment with them either naming the internet draft / RFC they are importing from, or pointing to the reference which names it? >>> Perhaps RFC 6087bis can give additional guidelines. The common way to >>> get the references into the enclosing document is to include a >>> statement before the definitions that says something like: >>> >>>This module imports from the defined in >>>[RFCXYZ] and form the defined in [RFCABC]. >>> >>> To help readers that have the module and who do not want to bother >>> looking up the document, including comments may help. It is kind of >>> funny that YANG does not allow reference statements on imports... >> It is too late to add this to Yang 1.1? >> >> That would seem to be the cleanest solution. > > It seems to me that allowing "reference" under "import" (and > "include") is a "safe" change, i.e., I support adding it even though > it is pretty late in the process. > > One thing to note is that in the current grammar, "reference" and > "description" are always allowed together - does it make sense to > allow "description" in the import/include as well? IMO, yes. Lada > > > /martin > > >> >> I was under the, possibly mistaken, assumption that various YANG tools >> effectively ignore/strip out the comments and hence comments are >> better embedded directly in the model as either reference or >> description statements. >> >> Rob >> >> >>> >>> /js >>> >> >> ___ >> 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] chars that require quoting
> On 02 Feb 2016, at 12:16, Martin Bjorklund wrote:
>
> Ladislav Lhotka wrote:
>>
>>> On 02 Feb 2016, at 09:51, Jernej Tuljak wrote:
>>>
>>> Martin Bjorklund je 1.2.2016 ob 20:48 napisal:
Juergen Schoenwaelder wrote:
> If a specification is not explicit enough, then people often implement
> what they find implemented in other similar contexts. This means the
> code often ends up reflecting which tools an implementor was familiar
> with. In a shell, echo f\"oo gives you f"oo (and the same is true for
> Tcl, which has otherwise the behavior you implemented for pyang,
> treating " as a regular character in an unquoted string.)
>
> It would help to know what implementations do with identifiers like
> f"o"o and f\"o\"o. If they do different things, then there is likely
> some evidence that implementors arrived at different conclusions.
I don't mind a clarification. How about:
OLD:
If a string contains any space, tab, or newline characters, a
semicolon (";"), braces ("{" or "}"), or comment sequences ("//",
"/*", or "*/"), then it MUST be enclosed within double or single
quotes.
NEW:
If a string contains any space, tab, or newline characters, a
semicolon (";"), braces ("{" or "}"), or comment sequences ("//",
"/*", or "*/"), then it MUST be enclosed within double or single
quotes. If a string does not contain any of these characters, it
MAY be unquoted.
Within an unquoted string, every character is preserved. Note that
this means that the backslash, single quote, and double quote
characters can occur in an unquoted string.
>>>
>>> I don't think this can be implemented, like I did not in the linked
>>> archive. It does not make clear whether these are two statements or a
>>> single one:
>>>
>>> default ";
>>> units ";
>>>
>>>
>>> What about this:
>>>
>>> default ";//foo";
>>> units \";
>>>
>>>
>>> This is not the C and C++ way of doing things (possibly not even SMIng
>>> way). These are the only languages mentioned in the document (Section 6).
>>> It also does not promote readability and makes lexers unnecessarily complex.
>>
>> +1
>>
>> I think the safest solution would be to disallow in unquoted strings
>> all characters that have a special meaning anywhere in YANG
>> syntax. This can hardly cause any troubles to module authors.
>
> Fine with me. Something like:
>
> NEW:
>
> If a string contains any space, tab, or newline characters, a single
> or double quote, semicolon (";"), braces ("{" or "}"), or comment
> sequences ("//", "/*", or "*/"), then it MUST be enclosed within
> double or single quotes. If a string does not contain any of these
> characters, it MAY be unquoted.
>
> Within an unquoted string, every character is preserved. Note that
> this means that the backslash character does not have any special
> meaning in an unquoted string.
I like this.
>
>
> It should be noted that this may be viewed as a backwards incompatible
> change, but I think it is similar to the change for escaped characters
> in double quoted string ("backwards incompatible bugfix").
Yes, I think so.
Thanks, Lada
>
>
>
> /martin
>
>
>
>>
>> BTW, if we wanted to be extremely liberal, I don't understand why the
>> end-comment sequence "*/" is not allowed.
>>
>> Lada
>>
>>>
>>> Jernej
>>>
/martin
___
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
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] minor question - YANG Document Guidelines: Imports
Robert Wilton wrote: > On 28/01/2016 20:01, Juergen Schoenwaelder wrote: > > On Thu, Jan 28, 2016 at 01:57:22PM -0500, Joel M. Halpern wrote: > >> I ran into something while reading a YANG internet-draft recently, and > >> I > >> wonder if a bit of advice in the YANG Document Guidelines (rfc6087bis) > >> would be reasonable. > >> > >> Section 4.8 of the guidelines states that any imported modules must > >> also > >> have a reference in the references section. Which is good. But there > >> is no obvious way for a human reader to relate the two. > >> > >> Would it be sensible to recommend in this document (I don't know if it > >> would be 4.8 or a new section later in the document) that import > >> statements have a comment with them either naming the internet draft / > >> RFC they are importing from, or pointing to the reference which names > >> it? > >> > > Perhaps RFC 6087bis can give additional guidelines. The common way to > > get the references into the enclosing document is to include a > > statement before the definitions that says something like: > > > > This module imports from the defined in > > [RFCXYZ] and form the defined in [RFCABC]. > > > > To help readers that have the module and who do not want to bother > > looking up the document, including comments may help. It is kind of > > funny that YANG does not allow reference statements on imports... > It is too late to add this to Yang 1.1? > > That would seem to be the cleanest solution. It seems to me that allowing "reference" under "import" (and "include") is a "safe" change, i.e., I support adding it even though it is pretty late in the process. One thing to note is that in the current grammar, "reference" and "description" are always allowed together - does it make sense to allow "description" in the import/include as well? /martin > > I was under the, possibly mistaken, assumption that various YANG tools > effectively ignore/strip out the comments and hence comments are > better embedded directly in the model as either reference or > description statements. > > Rob > > > > > > /js > > > > ___ > 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
Re: [netmod] chars that require quoting
Ladislav Lhotka wrote:
>
> > On 02 Feb 2016, at 09:51, Jernej Tuljak wrote:
> >
> > Martin Bjorklund je 1.2.2016 ob 20:48 napisal:
> >> Juergen Schoenwaelder wrote:
> >>> If a specification is not explicit enough, then people often implement
> >>> what they find implemented in other similar contexts. This means the
> >>> code often ends up reflecting which tools an implementor was familiar
> >>> with. In a shell, echo f\"oo gives you f"oo (and the same is true for
> >>> Tcl, which has otherwise the behavior you implemented for pyang,
> >>> treating " as a regular character in an unquoted string.)
> >>>
> >>> It would help to know what implementations do with identifiers like
> >>> f"o"o and f\"o\"o. If they do different things, then there is likely
> >>> some evidence that implementors arrived at different conclusions.
> >> I don't mind a clarification. How about:
> >>
> >> OLD:
> >>
> >> If a string contains any space, tab, or newline characters, a
> >> semicolon (";"), braces ("{" or "}"), or comment sequences ("//",
> >> "/*", or "*/"), then it MUST be enclosed within double or single
> >> quotes.
> >>
> >> NEW:
> >>
> >> If a string contains any space, tab, or newline characters, a
> >> semicolon (";"), braces ("{" or "}"), or comment sequences ("//",
> >> "/*", or "*/"), then it MUST be enclosed within double or single
> >> quotes. If a string does not contain any of these characters, it
> >> MAY be unquoted.
> >>
> >> Within an unquoted string, every character is preserved. Note that
> >> this means that the backslash, single quote, and double quote
> >> characters can occur in an unquoted string.
> >
> > I don't think this can be implemented, like I did not in the linked
> > archive. It does not make clear whether these are two statements or a
> > single one:
> >
> > default ";
> > units ";
> >
> >
> > What about this:
> >
> > default ";//foo";
> > units \";
> >
> >
> > This is not the C and C++ way of doing things (possibly not even SMIng
> > way). These are the only languages mentioned in the document (Section 6).
> > It also does not promote readability and makes lexers unnecessarily complex.
>
> +1
>
> I think the safest solution would be to disallow in unquoted strings
> all characters that have a special meaning anywhere in YANG
> syntax. This can hardly cause any troubles to module authors.
Fine with me. Something like:
NEW:
If a string contains any space, tab, or newline characters, a single
or double quote, semicolon (";"), braces ("{" or "}"), or comment
sequences ("//", "/*", or "*/"), then it MUST be enclosed within
double or single quotes. If a string does not contain any of these
characters, it MAY be unquoted.
Within an unquoted string, every character is preserved. Note that
this means that the backslash character does not have any special
meaning in an unquoted string.
It should be noted that this may be viewed as a backwards incompatible
change, but I think it is similar to the change for escaped characters
in double quoted string ("backwards incompatible bugfix").
/martin
>
> BTW, if we wanted to be extremely liberal, I don't understand why the
> end-comment sequence "*/" is not allowed.
>
> Lada
>
> >
> > Jernej
> >
> >>
> >> /martin
> >>
> >> ___
> >> 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
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] 6087bis namespace recommendations
- Original Message -
From: "Robert Wilton"
To: "Ladislav Lhotka" ; "Andy Bierman"
;
Sent: Sunday, January 17, 2016 10:20 PM
> On 17/01/2016 09:52, Juergen Schoenwaelder wrote:
> > On Fri, Jan 15, 2016 at 03:38:00PM +, Robert Wilton wrote:
> >> Since an ID is effectively superseded by any new versions, I think
that
> >> it is useful if a module defined in an ID has a revision date that
> >> matches the published ID, and also a reference back to the ID
version
> >> that defines it. At least if someone ends up implementing that
module
> >> they can check its provenance. Both of these properties would also
be
> >> verifiable by idnits.
> >>
> > Right now, we seem in the "hey lets invent more rules mode" and
> > tomorrow I am sure we are again in the "hey the IETF is way to
> > complicated to work in" mode.
> This was the approach that I followed when posting and updating the
> drafts that I was working on, perhaps mis-understanding the statement
> "The revision statement MUST have a reference substatement. It MUST
> identify the published document that contains the module." for which I
> presumed that the "published document" also includes the version
number.
>
> > If you have a unique revision date, why is google and the like not
> > sufficient to find the matching I-D? Sure, the proposed rule itself
> > does not hurt, but an increasingly large collection of rules may
start
> > to hurt. So please, lets try to find the minimum number of rules
where
> > we have evidence that they avoid big problems.
> I'm also against having too many rules to follow, it starts to make
the
> process too laborious.
>
> My assumption is that given the relatively slow pace that standards
> models are being formally standardized that vendors/operators are
likely
> to want/need to temporarily ship with pre-standard versions of the
> models. Hence, in this case I personally feel that the additional
> clarity that is gained by explicitly referencing both date and full
> document name outweighs the slight hassle in updating it when a new
> version of the draft is posted.
I was looking at
draft-liang-rtgwg-staticrt-yang-cfg-00
which contains
"file "ietf-stati...@2015-10-16.yang"
revision 2015-10-17 {
description
"Initial revision.";
reference
" [draft-ietf-netmod-routing-cfg-16]
A YANG Data Model for Routing Management.
";
and then I looked at
draft-liang-rtgwg-staticrt-yang-cfg-01
which contains
"file "ietf-stati...@2015-10-16.yang"
.
revision 2015-10-16 {
description
"Initial revision.";
reference
" [draft-ietf-netmod-routing-cfg-16]
A YANG Data Model for Routing Management.
";
I think that this happens, and quite often. There is a gap
between getting what seems to us a good set of conventions out into an
RFC and getting those adopted, especially when there is nothing to catch
what, to us, may seem obvious flaws. Automation, by the tools team,
seems the obvious answer. The second I-D was published on 2015-12-16
which, assuming a typo, accounts for some, but not all, of the quirks.
In passing, s.4.1 has an example containing
description "Latest revision";
True, and it could have said "Current revision" or "Most recent
revision" or ...
I would change that to, say,
"Revised after comments on the use of opstate"
(or some such).
Tom Petch
>
> Rob
>
> >
> > /js
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] chars that require quoting
> On 02 Feb 2016, at 09:51, Jernej Tuljak wrote:
>
> Martin Bjorklund je 1.2.2016 ob 20:48 napisal:
>> Juergen Schoenwaelder wrote:
>>> If a specification is not explicit enough, then people often implement
>>> what they find implemented in other similar contexts. This means the
>>> code often ends up reflecting which tools an implementor was familiar
>>> with. In a shell, echo f\"oo gives you f"oo (and the same is true for
>>> Tcl, which has otherwise the behavior you implemented for pyang,
>>> treating " as a regular character in an unquoted string.)
>>>
>>> It would help to know what implementations do with identifiers like
>>> f"o"o and f\"o\"o. If they do different things, then there is likely
>>> some evidence that implementors arrived at different conclusions.
>> I don't mind a clarification. How about:
>>
>> OLD:
>>
>> If a string contains any space, tab, or newline characters, a
>> semicolon (";"), braces ("{" or "}"), or comment sequences ("//",
>> "/*", or "*/"), then it MUST be enclosed within double or single
>> quotes.
>>
>> NEW:
>>
>> If a string contains any space, tab, or newline characters, a
>> semicolon (";"), braces ("{" or "}"), or comment sequences ("//",
>> "/*", or "*/"), then it MUST be enclosed within double or single
>> quotes. If a string does not contain any of these characters, it
>> MAY be unquoted.
>>
>> Within an unquoted string, every character is preserved. Note that
>> this means that the backslash, single quote, and double quote
>> characters can occur in an unquoted string.
>
> I don't think this can be implemented, like I did not in the linked archive.
> It does not make clear whether these are two statements or a single one:
>
> default ";
> units ";
>
>
> What about this:
>
> default ";//foo";
> units \";
>
>
> This is not the C and C++ way of doing things (possibly not even SMIng way).
> These are the only languages mentioned in the document (Section 6). It also
> does not promote readability and makes lexers unnecessarily complex.
+1
I think the safest solution would be to disallow in unquoted strings all
characters that have a special meaning anywhere in YANG syntax. This can hardly
cause any troubles to module authors.
BTW, if we wanted to be extremely liberal, I don't understand why the
end-comment sequence "*/" is not allowed.
Lada
>
> Jernej
>
>>
>> /martin
>>
>> ___
>> 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
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] chars that require quoting
> On 01 Feb 2016, at 20:48, Martin Bjorklund wrote:
>
> Juergen Schoenwaelder wrote:
>> If a specification is not explicit enough, then people often implement
>> what they find implemented in other similar contexts. This means the
>> code often ends up reflecting which tools an implementor was familiar
>> with. In a shell, echo f\"oo gives you f"oo (and the same is true for
>> Tcl, which has otherwise the behavior you implemented for pyang,
>> treating " as a regular character in an unquoted string.)
>>
>> It would help to know what implementations do with identifiers like
>> f"o"o and f\"o\"o. If they do different things, then there is likely
>> some evidence that implementors arrived at different conclusions.
>
> I don't mind a clarification. How about:
>
> OLD:
>
> If a string contains any space, tab, or newline characters, a
> semicolon (";"), braces ("{" or "}"), or comment sequences ("//",
> "/*", or "*/"), then it MUST be enclosed within double or single
> quotes.
>
> NEW:
>
> If a string contains any space, tab, or newline characters, a
> semicolon (";"), braces ("{" or "}"), or comment sequences ("//",
> "/*", or "*/"), then it MUST be enclosed within double or single
> quotes. If a string does not contain any of these characters, it
> MAY be unquoted.
>
> Within an unquoted string, every character is preserved. Note that
> this means that the backslash, single quote, and double quote
> characters can occur in an unquoted string.
For the reasons that I explained earlier, I think that allowing single and
double quotes in unquoted strings is a bug. This text makes it into a feature,
so I am objecting to it.
Lada
>
>
> /martin
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] chars that require quoting
Martin Bjorklund je 1.2.2016 ob 20:48 napisal:
Juergen Schoenwaelder wrote:
If a specification is not explicit enough, then people often implement
what they find implemented in other similar contexts. This means the
code often ends up reflecting which tools an implementor was familiar
with. In a shell, echo f\"oo gives you f"oo (and the same is true for
Tcl, which has otherwise the behavior you implemented for pyang,
treating " as a regular character in an unquoted string.)
It would help to know what implementations do with identifiers like
f"o"o and f\"o\"o. If they do different things, then there is likely
some evidence that implementors arrived at different conclusions.
I don't mind a clarification. How about:
OLD:
If a string contains any space, tab, or newline characters, a
semicolon (";"), braces ("{" or "}"), or comment sequences ("//",
"/*", or "*/"), then it MUST be enclosed within double or single
quotes.
NEW:
If a string contains any space, tab, or newline characters, a
semicolon (";"), braces ("{" or "}"), or comment sequences ("//",
"/*", or "*/"), then it MUST be enclosed within double or single
quotes. If a string does not contain any of these characters, it
MAY be unquoted.
Within an unquoted string, every character is preserved. Note that
this means that the backslash, single quote, and double quote
characters can occur in an unquoted string.
I don't think this can be implemented, like I did not in the linked
archive. It does not make clear whether these are two statements or a
single one:
default ";
units ";
What about this:
default ";//foo";
units \";
This is not the C and C++ way of doing things (possibly not even SMIng
way). These are the only languages mentioned in the document (Section
6). It also does not promote readability and makes lexers unnecessarily
complex.
Jernej
/martin
___
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
Re: [netmod] Why not use xpath3.0 or xpath2.0?
Moving from xpath 1.0 to a newer version of xpath impacts certain
implementations in non-trivial ways. Note that the WG charter says:
The NETMOD Working Group will produce a maintenance release of the
core YANG specification called YANG 1.1, that is a revision of RFC
6020. The changes to RFC 6020 are restricted in the following ways:
- All compliant YANG 1.0 modules must be accepted as compliant YANG
1.1 modules.
- All known ambiguities of YANG 1.0 and all reported defects and
errata will be addressed.
- YANG 1.1 is not adding fundamentally new data modeling concepts to
the language.
- The changes of the specification will be kept to the minimum
necessary to achieve the previously stated goals.
Moving to a more powerful version of xpath is out of scope for YANG
1.1. Note that we are wrapping things up, the deadline for submitting
feature requests has long passed.
/js
On Tue, Feb 02, 2016 at 12:32:47AM +, fengchong (C) wrote:
> Hi all,
> I notice draft-ietf-netmod-rfc6020bis-09 still uses xpath1.0 as a notation
> for checking node references or dependencies.
> I don’t know why we don’t use xpath3.0 or xpath2.0? xpath3.0 is more powerful
> than xpath1.0.
> For example, xpath3.0 introduced conditional expression. It’s very useful for
> must statement.
>
> If we have a schema tree like this:
> List l {
> Key a;
> Leaf a {…}
> Leaf b {…}
> Leaf c {…}
> Leaf d {…}
> }
>
> If a= 5 and b=10 and c >20, then d must be less than 30 and greater than 15.
> If use xpath1.0, the MUST statement should be:
> Must “a != 5
> or b != 10
> or c <=20
> or (a =5 and b = 10 and c>20 and d >15 and d < 30)”
> if use xpath3.0:
> must “if (a =5 and b = 10 and c>20)
> then d>15 and d<30
> else true()”
>
> if we feel xpath3.0 is too complicated, we can specify a small set of xpath
> grammar for YANG.
>
>
> 冯冲
> 华为技术有限公司 Huawei Technologies Co., Ltd.
> [Company_logo]
>
> Phone:
> Fax:
> Mobile: 18519117316
> Email: frank.fengch...@huawei.com
> 地址：南京市软件大道101号华为南京基地 邮编：210001
> Huawei Technologies Co., Ltd.
>
> http://www.huawei.com
>
> 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
> 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
> 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from HUAWEI,
> which
> is intended only for the person or entity whose address is listed above. Any
> use of the
> information contained herein in any way (including, but not limited to, total
> or partial
> disclosure, reproduction, or dissemination) by persons other than the intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by
> phone or email immediately and delete it!
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103
