Re: [netmod] https? - Regex

[William Lupton]

I think that the most relevant bits are:

[3]   piece   ::=   atom quantifier?
[9]   atom   ::=   Char | charClass | ( '(' regExp ')' )
[4]   quantifier   ::=   [?*+] | ( '{' quantity '}' )

In https? we have five pieces, of which only the last has a quantifier

So https? means h, t, t, p, optional-s

If you want the '?' to apply to more, then you need parentheses, e.g.,
(https)?.

On Wed, 7 Sept 2022 at 10:29, tom petch  wrote:

> I commented recently on a draft that said that a regex of
> https?
> would match http which I said it would not.  The author said that he had
> tested it ok so I turned to XML Schema Part 2 as referenced by RFC7950
> which tells me that
> S?   the empty string, and all strings in L(S)
> where L(S) is not explained and my set theory is too rusty to help.
>
> Can anyone confirm for me that I am wrong, and that the Author is right?
>
> Tom Petch
> ___
> 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] iana-if-type.yang has multiple revisions with the same date

[William Lupton]

I think this partly depends on the general attitude to non-ASCII
characters, e.g., are accented words tolerated, encouraged, frowned upon or
forbidden?

Are programming languages in general tolerant of smart quotes for defining
strings (I don't know but I suspect not)? If not then I don't think that
YANG should be either. But the tools could generate better error messages
if they are inadvertently used!

On Wed, 25 May 2022 at 10:01, Carsten Bormann  wrote:

> On 2022-05-25, at 10:51, William Lupton 
> wrote:
> >
> >   "Coalesced revision history entries for 2018-06-28.”;
>
> Wonderful example.  I’m wondering whether the next version of CDDL should
> simply accept typographic quotes in place of the typewriter quote…  (and,
> as the example demonstrates, any weird mix of them.)
>
> Grüße, Carsten
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] iana-if-type.yang has multiple revisions with the same date

[William Lupton]

I uploaded some more modules to the catalog yesterday and was looking into
why compilations are failing.

It turns out that iana-if-t...@2022-03-07.yang (the 'fixed' version) is
broken. Running it through pyang gives this:

% pyang iana-if-t...@2022-03-07.yang
iana-if-t...@2022-03-07.yang:56: error: unterminated statement definition
for keyword "description", looking at C

The problem is a bit earlier, in the coalesced revision statement:

  revision 2022-03-07 {
description
  "Coalesced revision history entries for 2018-06-28.”;
  }

That closing quote is a 'close curly double quote' (UTF-8 Encoding: 0xE2
0x80 0x9D). Fixing it to an ASCII double quote fixes the problem. Is there
no automatic validation of IANA modules?

% grep Coalesced iana-if-t...@2022-03-07.yang | od -ax
000   sp  sp  sp  sp  sp  sp   "   C   o   a   l   e   s   c   e   d
 2020202020204322616f656c63736465
020   sp   r   e   v   i   s   i   o   n  sp   h   i   s   t   o   r
 7220766573696f69206e69687473726f
040y  sp   e   n   t   r   i   e   s  sp   f   o   r  sp   2   0
 20796e657274656920736f6620723032
0601   8   -   0   6   -   2   8   .   *?  80  9d*   ;  nl
 3831302d2d363832*e2*2e*9d80*0a3b

076

On Tue, 8 Mar 2022 at 13:07, Rob Wilton (rwilton)  wrote:

> Hi William,
>
>
>
> IANA have published a new revision with the revision history fixed.
>
>
>
> iana-if-type YANG Module
> <https://www.iana.org/assignments/iana-if-type/iana-if-type.xhtml>
>
>
>
> Regards,
>
> Rob
>
>
>
>
>
> *From:* netmod  *On Behalf Of *Rob Wilton
> (rwilton)
> *Sent:* 04 March 2022 14:37
> *To:* William Lupton ; Benoit Claise <
> benoit.cla...@huawei.com>
> *Cc:* NetMod WG 
> *Subject:* Re: [netmod] iana-if-type.yang has multiple revisions with the
> same date
>
>
>
> Hi William,
>
>
>
> I have asked Sabrina in IANA to please publish a new revision with the
> history fixed.
>
>
>
> Regards,
>
> Rob
>
>
>
>
>
> *From:* netmod  *On Behalf Of *William Lupton
> *Sent:* 04 March 2022 10:15
> *To:* Benoit Claise 
> *Cc:* NetMod WG 
> *Subject:* Re: [netmod] iana-if-type.yang has multiple revisions with the
> same date
>
>
>
> +1 (not surprisingly). What action? And whose action?
>
>
>
> On Thu, 3 Mar 2022 at 19:24, Benoit Claise 
> wrote:
>
> +1  to Jürgen point of view.
>
>
>
> Regards, Benoit
>
> *From:*Jürgen Schönwälder 
>
> *To:*William Lupton 
>
> *Cc:*NetMod WG 
>
> *Date:*2022-03-03 20:01:06
>
> *Subject:*Re: [netmod] iana-if-type.yang has multiple revisions with the
> same date
>
>
>
> The obvious thing to do in this particular case (where there are only
> allocations of new values) is to collapse the revisions and to move
> on. Slightly better would be to ensure this does not happen again.
>
> /js
>
> On Thu, Mar 03, 2022 at 05:45:25PM +, William Lupton wrote:
> > > It is too late to do anything about this module.
> >
> > This module is republished every time a new ifType is added. Are you
> saying
> > that it would be unacceptable to collapse the duplicate revisions next
> time
> > it's updated? If so then we will live with this FOR EVER!
> >
> > >
>
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
>
> --
> Jürgen Schönwälder  Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>
>
> ___
> 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] iana-if-type.yang has multiple revisions with the same date

[William Lupton]

+1 (not surprisingly). What action? And whose action?

On Thu, 3 Mar 2022 at 19:24, Benoit Claise  wrote:

> +1  to Jürgen point of view.
>
> Regards, Benoit
>
> *From:*Jürgen Schönwälder 
> *To:*William Lupton 
> *Cc:*NetMod WG 
> *Date:*2022-03-03 20:01:06
> *Subject:*Re: [netmod] iana-if-type.yang has multiple revisions with the
> same date
>
> The obvious thing to do in this particular case (where there are only
> allocations of new values) is to collapse the revisions and to move
> on. Slightly better would be to ensure this does not happen again.
>
> /js
>
> On Thu, Mar 03, 2022 at 05:45:25PM +, William Lupton wrote:
> > > It is too late to do anything about this module.
> >
> > This module is republished every time a new ifType is added. Are you
> saying
> > that it would be unacceptable to collapse the duplicate revisions next
> time
> > it's updated? If so then we will live with this FOR EVER!
> >
> > >
>
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
>
> --
> Jürgen Schönwälder  Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>
>
> ___
> 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] iana-if-type.yang has multiple revisions with the same date

[William Lupton]

> It is too late to do anything about this module.

This module is republished every time a new ifType is added. Are you saying
that it would be unacceptable to collapse the duplicate revisions next time
it's updated? If so then we will live with this FOR EVER!

>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] iana-if-type.yang has multiple revisions with the same date

[William Lupton]

Thanks Andy. What is the next step? Should I (or someone else) email
i...@iana.org, or can we assume that the relevant IANA person will already
have seen this discussion?

On Tue, 1 Mar 2022 at 14:49, Andy Bierman  wrote:

>
> I think that this should be fixed. What's the best way to achieve this?
>>
>
> I think this issue should be resolved as well.
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] iana-if-type.yang has multiple revisions with the same date

[William Lupton]

All,

Sorry if (as is quite likely) this is a duplicate.

I noticed from
https://yangcatalog.org/private-page/BBFYANGPageCompilation.html that
there's a (long-standing?) problem in iana-if-type.yang
:
it has multiple revision statements with the same date:

  revision 2018-06-28 {
description
  "Registered ifType 294.";
  }

  revision 2018-06-28 {
description
  "Registered ifType 293.";
  }

This has presumably happened as a result of an automated update script that
doesn't check for this case (*)? From a quick scan, I didn't see anything
in RFC 7950 banning duplicate revision dates, but RFC 8407 section 4.8 says
"*If the module contents have changed, then the revision date of that new
module version MUST be updated to a date later than that of the previous
version*" and of course yangdump-pro is checking this.

I think that this should be fixed. What's the best way to achieve this?

Thanks,
William

(*) In the rare event that multiple changes are made in the same day,
perhaps the second change should be (strictly wrongly) assigned to the
following day. In theory this could cause revision dates to run far into
the future but in practice I don't think this will happen :).
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] warn: Module's revisions are not unique (2018-06-28).

[William Lupton]

I thought it might also be so as not to impose a module naming convention
on external organisations?

On Wed, 17 Mar 2021, 18:47 Andy Bierman,  wrote:

>
>
> On Wed, Mar 17, 2021 at 11:36 AM William Lupton <
> wlup...@broadband-forum.org> wrote:
>
>> Also note that the YANG catalog keys modules by (name, revision,
>> organization).
>>
>
> This 3rd key implies that some organizations have their own versions of
> YANG modules from SDOs.
> We have a bit of that only to fix known Errara in some IETF modules.
> YANG has deviations so vendors can change the modules from other
> organizations
> without hacking the original modules.
>
>
> Andy
>
>
>
>> On Wed, 17 Mar 2021 at 18:21, Andy Bierman  wrote:
>>
>>>
>>>
>>> On Wed, Mar 17, 2021 at 8:36 AM Vladimir Vassilev <
>>> vladi...@lightside-instruments.com> wrote:
>>>
>>>>
>>>> On 16/03/2021 13.36, Vladimir Vassilev wrote:
>>>> > Hei,
>>>> >
>>>> > Many drafts and RFCs are flagged with warnings by the tracker
>>>> > validation tools:
>>>> >
>>>> > ...
>>>> > yanglint SO 1.6.7: yanglint --verbose -p {tmplib} -p {rfclib} -p
>>>> > {draftlib} -p {ianalib} -p {cataloglib} {model} -i:
>>>> > warn: Module's revisions are not unique (2018-06-28).
>>>> >
>>>> > ...
>>>> >
>>>> > Does anyone know what causes this warning?
>>>>
>>>> Seems the warning is issued when iana-if-t...@2020-01-10.yang is
>>>> processed. It contains 2 revision (history) statements with identical
>>>> dates 2018-06-28.
>>>>
>>>> IMO Multiple revision statements with the same date are valid so the
>>>> tool reporting the warning has to be fixed.
>>>>
>>>>
>>>
>>> I disagree.  Our compiler has a similar warning.
>>>
>>> The YANG Library treats entries with the exact same module name and
>>> revision-date as
>>> the same module.  The protocols that currently advertise YANG module
>>> capabilities
>>> all use module name and revision-date to identify a unique module
>>> revision.
>>>
>>> A compiler warning simply means "Are you sure you meant to do this?"
>>> This is usually a cut-and-paste error.
>>>
>>>
>>>
>>>>
>>>> Vladimir
>>>>
>>>>
>>> Andy
>>>
>>>
>>>> ___
>>>> 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] warn: Module's revisions are not unique (2018-06-28).

[William Lupton]

Also note that the YANG catalog keys modules by (name, revision,
organization).

On Wed, 17 Mar 2021 at 18:21, Andy Bierman  wrote:

>
>
> On Wed, Mar 17, 2021 at 8:36 AM Vladimir Vassilev <
> vladi...@lightside-instruments.com> wrote:
>
>>
>> On 16/03/2021 13.36, Vladimir Vassilev wrote:
>> > Hei,
>> >
>> > Many drafts and RFCs are flagged with warnings by the tracker
>> > validation tools:
>> >
>> > ...
>> > yanglint SO 1.6.7: yanglint --verbose -p {tmplib} -p {rfclib} -p
>> > {draftlib} -p {ianalib} -p {cataloglib} {model} -i:
>> > warn: Module's revisions are not unique (2018-06-28).
>> >
>> > ...
>> >
>> > Does anyone know what causes this warning?
>>
>> Seems the warning is issued when iana-if-t...@2020-01-10.yang is
>> processed. It contains 2 revision (history) statements with identical
>> dates 2018-06-28.
>>
>> IMO Multiple revision statements with the same date are valid so the
>> tool reporting the warning has to be fixed.
>>
>>
>
> I disagree.  Our compiler has a similar warning.
>
> The YANG Library treats entries with the exact same module name and
> revision-date as
> the same module.  The protocols that currently advertise YANG module
> capabilities
> all use module name and revision-date to identify a unique module revision.
>
> A compiler warning simply means "Are you sure you meant to do this?"
> This is usually a cut-and-paste error.
>
>
>
>>
>> Vladimir
>>
>>
> Andy
>
>
>> ___
>> 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] Questions about how to assign default values with YANG

[William Lupton]

Thanks Lada. By my last point I just intended to illustrate that
descriptions need to be regarded as normative even if they don't use
normative language.

On Wed, 10 Mar 2021 at 15:13, Ladislav Lhotka 
wrote:

> William Lupton  writes:
>
> > Lada, all,
> >
> > Surely a description is the only way to add a normative requirement that
> > can't be expressed via YANG statements (including XPath expressions)?
> >
> > I've always assumed that it's good practice to express what you can using
> > the modeling language, and then use the description to express any
> > non-modelable requirements. Obviously there's a problem if the
> description
> > conflicts with a modeled requirement (and I think it's also good practice
> > for the description not to repeat anything that's modeled elsewhere).
> >
> > I think that RFC 7950 can be interpreted as indicating that the
> description
> > is more than just informative. I found this in Section 11, and I take
> this
> > to imply that the description defines the semantics of a definition.
>
> Even then, it is unclear what effects are permitted with this "more than
> informative". In a previous mail I refered to a standard module having a
> description that defines a (computed) default. This seems to be acceptable.
>
> But what about simulating a "when" statement for constraints that cannot
> be expressed via XPath? For example:
>
>   description
> "This leaf is only valid if the value of foo is prime.";
>
> I argued in the past that everything that cannot be expressed formally
> with YANG statements should be left outside of scope for YANG, at least in
> terms of data tree validation.
>
> >
> > A "description" statement may be added or changed without changing the
> >
> > semantics of the definition.
> >
> >
> > For example, if a description says this (this is an example from RFC
> 7950),
> > then isn't this a _normative_ semantic requirement?
> >
> > "The amount of local storage that can be used to hold syslog messages."
>
> Hmm, this seems to state semantics (meaning) of a parameter. What I am
> talking about are semantic constraints (business rules) that a valid data
> tree is required to satisfy.
>
> Lada
>
> >
> >
> > William
> >
> > On Wed, 10 Mar 2021 at 10:21, Ladislav Lhotka 
> > wrote:
> >
> >> Juergen Schoenwaelder  writes:
> >>
> >> > A client that has no clue of the annotated leaf can rightfully assume
> >> > that the default 0 applies. If another client creates this magic leaf
> >> > that changes the default to 10, then there is going to be confusion.
> >> >
> >> > A definition that says 'default 0' says the default is 0. It does not
> >> > say the default may be zero or something different depending on
> >> > whether the moon shines or other circumstances. I believe you can't
> >> > undo a default statement with a description somewhere else.
> >>
> >> The problem with descriptions is that there seems to be a general
> >> agreement that they can somehow supplement the formal YANG statements in
> >> specifying the data model. This has no support in RFC 7950 though:
> >>
> >> - section 7.21.3 only says that a description is "a human-readable
> textual
> >>   description of this definition"
> >>
> >> - section 8.1 doesn't include constraints specified in descriptions in
> the
> >>   concept of data tree validity
> >>
> >> As a result, data model constraints specified in descriptions is a grey
> >> area, and it is totally unclear how far-reaching they can possibly be.
> >>
> >> Lada
> >>
> >> >
> >> > /js
> >> >
> >> > On Wed, Mar 10, 2021 at 08:54:18AM +, Italo Busi wrote:
> >> >> Andy, Juergen,
> >> >>
> >> >> I am not sure I understand the issue with a client that does not
> >> understand the augment.
> >> >>
> >> >> When this client writes in the running DS, it will not set the bar
> >> attribute (which is also defined in the augment module) and therefore
> the
> >> default value 0 will be applied by the system, as expected by the
> client.
> >> >>
> >> >> When this client reads from the operational DS the applied
> >> configuration, provided by another client which understands the
> augment, it
> >> will see that the applied configuration for the leaf foo is 10.

Re: [netmod] Questions about how to assign default values with YANG

[William Lupton]

Lada, all,

Surely a description is the only way to add a normative requirement that
can't be expressed via YANG statements (including XPath expressions)?

I've always assumed that it's good practice to express what you can using
the modeling language, and then use the description to express any
non-modelable requirements. Obviously there's a problem if the description
conflicts with a modeled requirement (and I think it's also good practice
for the description not to repeat anything that's modeled elsewhere).

I think that RFC 7950 can be interpreted as indicating that the description
is more than just informative. I found this in Section 11, and I take this
to imply that the description defines the semantics of a definition.

A "description" statement may be added or changed without changing the

semantics of the definition.


For example, if a description says this (this is an example from RFC 7950),
then isn't this a _normative_ semantic requirement?

"The amount of local storage that can be used to hold syslog messages."


William

On Wed, 10 Mar 2021 at 10:21, Ladislav Lhotka 
wrote:

> Juergen Schoenwaelder  writes:
>
> > A client that has no clue of the annotated leaf can rightfully assume
> > that the default 0 applies. If another client creates this magic leaf
> > that changes the default to 10, then there is going to be confusion.
> >
> > A definition that says 'default 0' says the default is 0. It does not
> > say the default may be zero or something different depending on
> > whether the moon shines or other circumstances. I believe you can't
> > undo a default statement with a description somewhere else.
>
> The problem with descriptions is that there seems to be a general
> agreement that they can somehow supplement the formal YANG statements in
> specifying the data model. This has no support in RFC 7950 though:
>
> - section 7.21.3 only says that a description is "a human-readable textual
>   description of this definition"
>
> - section 8.1 doesn't include constraints specified in descriptions in the
>   concept of data tree validity
>
> As a result, data model constraints specified in descriptions is a grey
> area, and it is totally unclear how far-reaching they can possibly be.
>
> Lada
>
> >
> > /js
> >
> > On Wed, Mar 10, 2021 at 08:54:18AM +, Italo Busi wrote:
> >> Andy, Juergen,
> >>
> >> I am not sure I understand the issue with a client that does not
> understand the augment.
> >>
> >> When this client writes in the running DS, it will not set the bar
> attribute (which is also defined in the augment module) and therefore the
> default value 0 will be applied by the system, as expected by the client.
> >>
> >> When this client reads from the operational DS the applied
> configuration, provided by another client which understands the augment, it
> will see that the applied configuration for the leaf foo is 10.
> >>
> >> This is a valid applied configuration if the other client had
> explicitly configured the value 10 in the running DS.
> >>
> >> The only difference would be that when the value 10 is explicitly
> configured by the other client the origin is set to intended while when
> “implicitly” configured using the attribute bar, the origin can be set to
> system (I think it would not be correct to set the origin to default in
> this case).
> >>
> >> BTW, I agree that this is not the most elegant/clean design and that
> the best approach would be not to define any default value in the base
> model. I am just willing to understand if a work-around is possible,
> without breaking any client, to allow re-using an existing module which has
> already defined a default value.
> >>
> >> Italo
> >>
> >> From: Andy Bierman [mailto:a...@yumaworks.com]
> >> Sent: martedì 9 marzo 2021 21:12
> >> To: Juergen Schoenwaelder ;
> Italo Busi ; netmod@ietf.org
> >> Subject: Re: [netmod] Questions about how to assign default values with
> YANG
> >>
> >>
> >>
> >> On Tue, Mar 9, 2021 at 11:52 AM Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de j.schoenwael...@jacobs-university.de>> wrote:
> >> Changing the semantics of a definition via augments is bad design.
> >>
> >> A system that does not understand the augment will believe the default
> >> is 0. Since there is no way to force an existing implementation to
> >> understand a certain augmentation, different implementation will
> >> rightfully disagree on the default value in effect.
> >>
> >>
> >> deviation /ex:example/ex:foo {
> >> delete {
> >>default 0;
> >>  }
> >> }
> >>
> >> IMO it was a bad idea to say deviations MUST NOT appear in standard
> modules.
> >> Here is a use-case for it.
> >>
> >> The old-client does not know about the new dynamic default but it could
> know
> >> that the old YANG default is not being used.
> >>
> >>
> >> /js
> >>
> >> Andy
> >>
> >>
> >> On Mon, Mar 08, 2021 at 08:19:39PM +, Italo Busi wrote:
> >> > Hi Juergen,
> >> >
> >> > Thanks again for your clear explanation on this 

Re: [netmod] [Tools-discuss] reflow of YANG descriptions, and general YANG format annoyances

[William Lupton]

I ensured that I have the latest version of the Emacs YANG mode, and find
that M-q works well to wrap description strings, but...

   1. Should I expect intelligent behaviour of RET and TAB when within a
   description (or other) string? I find that (in this context) RET positions
   the cursor at the start of the line, and TAB does nothing. Ideally RET
   might position the cursor at the indentation point of the previous line, or
   one character past the opening quote if this was the first line.
   2. Wrapping (quite reasonably) can't handle cases where the author
   didn't in fact intend line breaks to be inserted. The most common cases are
   probably (a) not using a blank line as a paragraph break, (b) text was
   further indented (which often implies literal text), or (c) text started
   with * (or -, ...) and was to be interpreted as a list item.

I don't believe that RFCs 7950 and 8407 say anything about paragraph
formatting, but most NETMOD YANG does seem to adhere to the convention that
paragraphs should be separated by blank lines. Perhaps this could be made
into a stronger convention?

As for the other cases (further indentation -> literal, and */- mean list
items), of course this is getting back to the markdown discussion. I
believe that when this has come up before the discussion has died for want
of clear standards. However I do believe that it would be very useful to
define some layout conventions (or rules) that allow automated reflow and
other formatting, and personally I would take it further than just the
three points that I have mentioned! It doesn't have to be called
'markdown'...

William

On Sat, 7 Nov 2020 at 05:07, Carsten Bormann  wrote:

> On 2020-11-07, at 01:06, Michael Richardson  wrote:
> >
> > M-q reflowed a paragraph, but made it too long with 76 columns wide.
>
> Is your .emacs setting fill-column to a non-standard value?
>
> C-x f 69 RET
>
> or put
>
> // -*- fill-column: 69 -*-
>
> into the first line of your YANG file (in a comment)
> or better
>
> (add-hook 'yang-mode-hook
>   '(lambda () (set-fill-column 69)))
>
> in your .emacs.
>
> Grüße, Carsten
>
> ___
> 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] rfc6991bis: yang:percentage

[William Lupton]

except that percent doesn't really seem like a routing-specific data type!

(perhaps the "right" thing to do is to deprecate, and eventually obsolete,
the routing one and define it in a core netmod module?)

On Thu, 30 Jul 2020 at 14:59, Benoit Claise  wrote:

> On 30/07/2020 15:25, Juergen Schoenwaelder wrote:
>
> On Thu, Jul 30, 2020 at 02:58:22PM +0200, Benoit Claise wrote:
>
> On 20/07/2020 11:19, Ladislav Lhotka wrote:
>
> Juergen Schoenwaelder  
>  writes:
>
>
>- Percentages are frequently used in YANG models but usages differ a
>  lot in precision and range. It is not clear what the proper
>  generic definition of a percentage type would be and whether it is
>  worth having it.
>
>  RFC 7950 example:
>
>   typedef percent { type uint8 { range "0 .. 100"; } }
>
>  RFC 8294:
>
>   typedef percentage { type uint8 { range "0..100"; } }
>
>  I-Ds:
>   typedef percentage { type decimal64 { fraction-digits 5; } }
>   typedef percentile { type decimal64 { fraction-digits 2; } }
>
>  The yang catalogue seems to be down. :-(
>
>- Proposal: do not add a percentage type since it is trivial to
>  define a context specific percentage type that matches range and
>  precision requirements (and there is already a definition in RFC
>  8294 for those who need exactly that definition).
>
> I agree with this proposal. It is also possible to use
>
> units percent;
>
> where necessary.
>
> On the other hand, when I look at the numerous percent/percentage
> occurrences in YANG model, it doesn't hurt to define that typedef.
> https://yangcatalog.org/yang-search/ => search on "node name" and typedef
> only
> We can find 56 entries from IETF, IEEE, BBF, OC, MEF, vendors
> Most of them points to:
>
>*typedef*  percent {
>   *type*  uint8 {
>   *range*  "0 .. 100";
>
>   }
>}
>
>
> But that one is already defined in RFC 8294 in ietf-routing-types.
> Does it make sense to define it again in yang-types?
>
>
>
> My point was taht it makes sense to group typedefs in a few documents:
> RFC6991, 6991bis (hopefully published soon) and  my bad,  I forgot that
> RFC 8294 is "Common YANG *data types* for the routing area"
>
> So we're good. Thanks.
>
> Regards, Benoit
>
> /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] 6991bis: domain-name

[William Lupton]

I think that "or" is slightly better here:

"...does not support wildcards (see RFC 4592) *or* classless in-addr.arpa
delegations (see RFC 2317)"

On Wed, 24 Jul 2019 at 08:01, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Mon, Jul 22, 2019 at 06:41:42PM -0400, Ladislav Lhotka wrote:
> >
> > But these two unsupported cases only make sense in the context of DNS
> zone data.
> > I would suggest instead
> >
> > NEW:
> >
> > "The domain-name type represents a DNS domain name.  The
> >  name SHOULD be fully qualified whenever possible.
> >  This type is not intended for modeling DNS zone data, as
> >  it does not support wildcards [RFC 4592] and classless
> >  in-addr.arpa delegations [RFC 2317]."
> >
>
> Yes, this is better. I will put the following in the next revision:
>
>  "The domain-name type represents a DNS domain name.  The
>   name SHOULD be fully qualified whenever possible. This
>   type does not support wildcards (see RFC 4592) and
>   classless in-addr.arpa delegations (see RFC 2317).
>
> And I will remove the sentence you wanted to remove since the above
> more clearly explains when to use / not to use this type.
>
> /js
>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
> ___
> 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] 6021 ipv4-prefix

[William Lupton]

On Thu, 18 Apr 2019 at 09:10, Acee Lindem (acee)  wrote:

> Since the constraint on the non-masked portion of the prefix is solely in
> the description, there is nothing to prevent this and I'm sure the
> ipv4-prefix and ipv6-prefix types are being used incorrectly.
>

Is a requirement in a description any less normative than a requirement
expressed directly using YANG syntax?
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991-bis: "token" type?

[William Lupton]

Does the last pattern work? I think it matches any string with two
consecutive non-spaces, e.g. "AA  AA" ("AA" + two-spaces + "AA").

To prevent multiple spaces I think we probably need something like "([^ ]+
)*[^ ]+" (which replaces the last three patterns).

Do XML regexes support \S (not-whitespace)? If so then I think that "(\S+
)*\S+" covers everything (although also excludes FF and any other
whitespace characters if there are any).

On Thu, 18 Apr 2019 at 05:51, Kent Watsen  wrote:

>
> Many times in models I want a non-empty version of what XSD calls a
> "token":
>
> tokenA string that does not contain line feeds,
>  carriage returns, tabs, leading or trailing
>  spaces, or multiple spaces.
>
> So how about the following?
>
>   typedef token {
>   type string;
>   length "1.max"; // non-empty (some expr do this already)
>   pattern "[^\n\r\t"]+"   // no LFs, CRs, or Tabs
>   pattern "[^ ].*";   // no leading space (min-length 1?)
>   pattern ".*[^ ]";   // no trailing space(min-length 1?)
>   pattern ".*[^ ][^ ].*"  // no multiple spaces   (min-length 2?)
>   }
>
> Kent // 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] Genart last call review of draft-ietf-netmod-module-tags-06

[William Lupton]

This remark might be out of context (I haven't been following the details)
but this reference to prefixes makes me wonder whether there's any way that
registered URN namespaces could be regarded as valid prefixes.
https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

On Thu, 7 Mar 2019 at 18:28, Andy Bierman  wrote:

>
>
> On Wed, Mar 6, 2019 at 2:51 PM Christian Hopps  wrote:
>
>> Thanks for the review! Comments inline.
>>
>> > On Mar 5, 2019, at 7:26 PM, Datatracker on behalf of Elwyn Davies <
>> ietf-secretariat-re...@ietf.org> wrote:
>> >
>> > Reviewer: Elwyn Davies
>> > Review result: Almost Ready
>> >
>> 
>> > If I read correctly, the YANG definition in s4.2 REQUIRES that all tags
>> have a
>> > prefix.  For clarity, it would better if this read:
>> >All tags MUST begin with a prefix; it is intended that this prefix
>> SHOULD
>> >   [or maybe 'should'] indicate
>> >  the ownership or origination of the definition.
>>
>> The intent was to not put the MUST on users. As the final arbiters of
>> tags, users should be free to do whatever they want and not have
>> implementations or standards superfluously block them from doing so. How
>> about we carry the SHOULD into the typedef in the YANG model as well? That
>> seems reasonable to me, i.e.,
>>
>>   typedef tag {
>> type string {
>>   length "1..max";
>>   pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+';
>> }
>> description
>>   "A tag is a type 'string' value that does not include carriage
>>return, newline or tab characters. It SHOULD begin with a
>>standard prefix.";
>>
>>
>
>
> I strongly agree that a prefix SHOULD be present, not MUST be present.
> I also think the 3 standard prefixes will be insufficient over time.
> (Having every organization on the planet except IETF share the prefix
> "vendor:"
> seems a bit short-sighted)
>
>
> Andy
>
> > S2, para 1: s/yang type/YANG type/ (I think)
>> >
>> > S2.2: s/follwing/following/
>> >
>> > S3.1, para 2:
>> > OLD:
>> > If the module definition is IETF standards track, the tags MUST also be
>> Section
>> > 2.1. Thus, new modules can drive the addition of new standard tags to
>> the IANA
>> > registry, and the IANA registry can serve as a check against
>> duplication.
>> >
>> > NEW:
>> > If the module is defined in an IETF standards track document, the tags
>> MUST use
>> > the prefix defined in Section 2.1. Thus, definitions of new modules can
>> drive
>> > the addition of new standard tags to the IANA registry defined in
>> Section 7.2,
>> > and the IANA registry can serve as a check against duplication.
>> >
>> > ENDS
>> >
>> > S3.2: s/standard/IETF Standard/
>> >
>> > S3.3: It would be useful to introduce the term 'masking' used later in
>> the YANG
>> > module definition.
>>
>> How about:
>>
>> "Tags of any kind can be assigned and removed by the user using normal
>> configuration mechanisms. In order to remove a tag from the
>> operational datastore the user adds a matching =masked-tag= entry for
>> a given module."
>>
>> > S4.1: I think this usage of RFC 8340 makes it normative.
>>
>> Covered earlier (BCP).
>>
>> > S4.2, extension module-tag definition: This should contain a pointer to
>> RFC
>> > 8342 which discusses the system origin concept.
>>
>> Added.
>>
>> Thanks,
>> Chris.
>>
>> >
>> > Major issues:
>> >
>> > Minor issues:
>> >
>> > Nits/editorial comments:
>> >
>> >
>> > ___
>> > 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] I-D Action: draft-chopps-netmod-geo-location-00.txt

[William Lupton]

On Tue, 5 Mar 2019 at 14:05, Martin Bjorklund  wrote:

> Christian Hopps  wrote:
> >
> > William Lupton  writes:
> >
> > >> The intent was "ascii-printable". Would be nice if there was an easier
> > > way to specify this. :)
> > >
> > > Printable ASCII characters are ' ' (space) through '~' (tilde) so
> > > naively [
> > > -~] should work ... but perhaps that makes unacceptable assumptions
> > > -about
> > > the locale and/or character encoding? (Certainly it should be OK if we
> > > can
> > > assume UTF-8, because all printable ASCII characters retain their
> > > ASCII
> > > representations in UTF-8.)
> >
> > I think your suggestion is a good one!
>
> Not sure I get it.  What exactly is the suggestion?
>

Presumably the suggestion of using the [ -~] ("space through tilde")
closure. I forgot to include other whitespace characters (CR, LF, FF) so if
those are to be included it could be [\s!-~] ("whitespace plus exclamation
mark through tilde").
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-chopps-netmod-geo-location-00.txt

[William Lupton]

> The intent was "ascii-printable". Would be nice if there was an easier
way to specify this. :)

Printable ASCII characters are ' ' (space) through '~' (tilde) so naively [
-~] should work ... but perhaps that makes unacceptable assumptions about
the locale and/or character encoding? (Certainly it should be OK if we can
assume UTF-8, because all printable ASCII characters retain their ASCII
representations in UTF-8.)

On Mon, 4 Mar 2019 at 20:20, Christian Hopps  wrote:

>
> Martin Bjorklund  writes:
>
> > Hi,
> >
> > Just some quick comments on the YANG:
> >
> > However, it seems libxml2's regexp engine requires both "[" and "^" to
> > be escaped:
> >
> > '[-0-9a-z "#\[\]' +
> > '!$%&()*+,./:;<=>?@\\\^_`{|}~]+';
> >
> > This expression isn't wrong, but it seems to me that these characters
> > should not have to be escaped.
> >
> > The pattern allows double quote (") but not single quote (').  Is
> > that intentional?
>
> The intent was "ascii-printable". Would be nice if there was an easier way
> to specify this. :)
>
> > [a simple way to test the patterns is to have a "default" statement
> > and a YANG complier that verifies defaults]
>
> Does pyang do this?
>
> > I recommend that you rename the example module in section to
> > "example-uses-geo-location" (and change the namespace to
> > urn:example:uses-geo-location).   We should not use the "ietf"
> > namespace for examples.
>
> Will do.
>
> Thanks,
> Chris.
>
> > /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] ACL draft defines ether-type as a string

[William Lupton]

Editorial: ethertype (no hyphen) seems to be more common than ether-type (28 
versus 11 matches in the YANG catalog, plus IEEE seem to use the no-hyphen 
version).

Also (even more editorial), I don’t see the need for the rather distracting 
‘0x’ in the name, so would suggest ethertype- (yes, I realise that this 
decision is in the IEEE bailiwick).

William

> On 18 Jul 2017, at 08:21, Mahesh Jethanandani  wrote:
> 
> The issue of ether-type defined as a string was discussed with participants 
> from IEEE in IETF. It was generally agreed that since ether-types are well 
> known values, and centrally managed, that they be defined as enumerations. 
> There was some clarification sought by IEEE on which values need to be 
> published. It was suggested that ether-types that are either private or do 
> not have a protocol identified would be named as ether-type-0x where 
> 0x represents the value assigned. All the remaining ether-types will be 
> defined as enums with the well known names. 
> 
> As far as the impact of that on the ACL draft is concerned, it will be to 
> remove all local definitions for ether-type from the draft, such as the one 
> below and instead use the definition from IEEE, whenever that is done. It 
> does however put a dependency on the IEEE model.
> 
> leaf ether-type {
>   type string {
> pattern '[0-9a-fA-F]{4}';
>   }
>   description
> "The Ethernet Type (or Length) value represented
>  in the canonical order defined by IEEE 802.
>  The canonical representation uses lowercase
>  characters.
> 
>  Note: This is not the most ideal way to define
>  ether-types. Ether-types are well known types
>  and are registered with RAC in IEEE. So they
>  should well defined types with values. For now
>  this model is defining it as a string.
>  There is a note out to IEEE that needs to be
>  turned into a liaison statement asking them to
>  define all ether-types for the industry to use.";
>   reference
> "IEEE 802-2014 Clause 9.2";
> }
> reference
>   "IEEE 802: IEEE Standard for Local and Metropolitan
>Area Networks: Overview and Architecture.";
>   }

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-vallin-netmod-alarm-module status and plans

[William Lupton]

Deborah,

Sorry about this. I will work with Dave S as you recommend.

Thanks,
William

> On 26 Jun 2017, at 12:00, BRUNGARD, DEBORAH A <db3...@att.com> wrote:
> 
> As Daniele says, if the authors are interested to progress this draft, it 
> should be submitted to ccamp.
> 
> There was an earlier comment in this thread by an individual, William Lupton, 
> saying "We at the Broadband Forum (BBF) would like to reiterate our interest 
> in the draft-vallin-netmod-alarm-module draft."
> 
> William, IETF has a liaison relationship with BBF. The appropriate channel to 
> express another group's interest is via liaison or the liaison contact. I 
> checked the liaisons and I don't see any liaison from BBF on this topic. The 
> liaison contact is Dave Sinicrope (cc'd). Please work with him to provide 
> communication on behalf of BBF to IETF.
> 
> It would be most helpful if BBF could provide requirements and use scenarios 
> for their needs on this item.
> 
> Thanks,
> Deborah
> (Routing AD)
> 
>> -Original Message-
>> From: Daniele Ceccarelli [mailto:daniele.ceccare...@ericsson.com]
>> Sent: Monday, June 26, 2017 4:23 AM
>> To: Lou Berger <lber...@labn.net>; stefan vallin <ste...@wallan.se>; Vladimir
>> Vassilev <vladi...@transpacket.com>
>> Cc: ccamp-cha...@ietf.org; netmod@ietf.org; BRUNGARD, DEBORAH A
>> <db3...@att.com>
>> Subject: RE: [netmod] draft-vallin-netmod-alarm-module status and plans
>> 
>> Hi Vladimir,
>> 
>> 
>> 
>> that single email doesn't reflect the consensus of the WG. The chairs and the
>> ADs agreed that CCAMP is the right place to progress the draft.
>> 
>> 
>> 
>> BR
>> 
>> Daniele
>> 
>> 
>> 
>> -Original Message-
>> 
>> From: Lou Berger [mailto:lber...@labn.net]
>> 
>> Sent: sabato 24 giugno 2017 21:10
>> 
>> To: stefan vallin <ste...@wallan.se>; Vladimir Vassilev
>> <vladi...@transpacket.com>
>> 
>> Cc: ccamp-cha...@ietf.org; netmod@ietf.org; Deborah Brungard
>> (dbrung...@att.com) <dbrung...@att.com>
>> 
>> Subject: Re: [netmod] draft-vallin-netmod-alarm-module status and plans
>> 
>> 
>> 
>> My understanding is the same as Kent's. This document should be brought into
>> ccamp...
>> 
>> 
>> 
>> Lou
>> 
>> 
>> 
>> 
>> 
>> On June 24, 2017 1:08:35 PM stefan vallin <ste...@wallan.se> wrote:
>> 
>> 
>> 
>>> +1
>> 
>>> 
>> 
>>> Mvh stefan
>> 
>>> +46(0)705233262
>> 
>>> 
>> 
>>>> 23 juni 2017 kl. 19:14 skrev Vladimir Vassilev <vladi...@transpacket.com>:
>> 
>>>> 
>> 
>>>> Hi Kent,
>> 
>>>> 
>> 
>>>> I followed the CCAMP thread concluding with
>> 
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-
>> 2Darchive_web_ccamp_current_msg18142.html=DwIGaQ=LFYZ-
>> o9_HUMeMTSQicvjIg=-
>> ufLqOntt6LejLMTbN3QpjYHxsObxmPKRhiF3FnmoI0=irspa6NcXPKDS42mjv_
>> C-
>> 7NNeuoTFH_7mVAhII6sVtw=FBMD66P58vyohwk53lFfpIBNFx9uxGUmzN6H
>> Wpz8gm0=  and
>> 
>>>> IMO there is consensus that the draft should be move back to netmod.
>> 
>>>> 
>> 
>>>> Vladimir
>> 
>>>> 
>> 
>>>> 
>> 
>>>>> On 06/22/2017 03:02 PM, Kent Watsen wrote:
>> 
>>>>> Hi William,
>> 
>>>>> 
>> 
>>>>> Please be aware that this draft is moving to the CCAMP WG.  I don't
>> 
>>>>> think the ccamp-version of the draft has been posted yet, but it
>> 
>>>>> will be discussed in that WG (and not NETMOD) in Prague.
>> 
>>>>> 
>> 
>>>>> Regards,
>> 
>>>>> Kent
>> 
>>>>> 
>> 
>>>>> 
>> 
>>>>>> On Jun 22, 2017, at 6:25 AM, William Lupton
>> 
>>>>>> <wlup...@broadband-forum.org>
>> 
>>>>>> wrote:
>> 
>>>>>> 
>> 
>>>>>> Dear all,
>> 
>>>>>> 
>> 
>>>>>> We at the Broadband Forum (BBF) would like to reiterate our
>> 
>>>>>> interest in the draft-vallin-netmod-alarm-module draft.
>> 
>>>>>> 
>> 
>>>>>> We will also have some technical comments / suggestions (internal
>> 
>>

Re: [netmod] draft-vallin-netmod-alarm-module status and plans

[William Lupton]

Dear all,

We at the Broadband Forum (BBF) would like to reiterate our interest in the 
draft-vallin-netmod-alarm-module draft.

We will also have some technical comments / suggestions (internal discussion is 
ongoing) that we will share with NETMOD as soon as possible.

Thanks,
William

> On 31 May 2017, at 13:08, Benoit Claise  wrote:
> 
> William,
> 
> This was discussed with the authors, the NETMOD chairs, and the RTG AD 
> Deborah.
> The advice was for the authors to raise the draft in ccamp and try to 
> progress it there.
> 
> The authors updated their draft to version 2 and pinged the CCAMP mailing 
> list (https://www.ietf.org/mail-archive/web/ccamp/current/msg18124.html).
> From that email thread, it seems there is interest in the work, but where to 
> do the work is not clear.
> 
> My advice to the authors: continue progress this work and if CCAMP is not 
> interested or consider this work too generic, bring it back to NETMOD and 
> we'll follow normal WG process.
> 
> Regards, Benoit
>> All,
>> 
>> I heard from Kent that 
>> https://tools.ietf.org/html/draft-vallin-netmod-alarm-module was moving to 
>> CCAMP but I don’t see any mention of it at 
>> https://datatracker.ietf.org/wg/ccamp/documents (although it is shown as a 
>> dependency at https://datatracker.ietf.org/wg/ccamp/deps/svg). Is any more 
>> info available please?
>> 
>> Thanks,
>> William

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Inconsistent config and state ordering in ietf-hardware

[William Lupton]

All,

I just noticed something minor but inconsistent with ietf-hardware. Whereas 
ietf-system and ietf-interfaces declare config before state, ietf-hardware is 
the other way round. If there’s no particular reason for this, perhaps they 
might be swapped?

% egrep '^   ? ?container' ietf-system.yang ietf-interfaces.yang 
ietf-hardware.yang 
ietf-system.yang:container system {
ietf-system.yang:container system-state {
ietf-interfaces.yang:  container interfaces {
ietf-interfaces.yang:  container interfaces-state {
ietf-hardware.yang:  container hardware-state {
ietf-hardware.yang:  container hardware {

Thanks,
William

PS, Perhaps this is moot, given the new data stores plans?___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] draft-vallin-netmod-alarm-module status and plans

[William Lupton]

All,

I heard from Kent that 
https://tools.ietf.org/html/draft-vallin-netmod-alarm-module was moving to 
CCAMP but I don’t see any mention of it at 
https://datatracker.ietf.org/wg/ccamp/documents (although it is shown as a 
dependency at https://datatracker.ietf.org/wg/ccamp/deps/svg). Is any more info 
available please?

Thanks,
William
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00

[William Lupton]

yes/support

my https://www.ietf.org/mail-archive/web/netmod/current/msg17899.html comments 
still apply; in summary:
* support use of markdown, with the principle that descriptions (etc) remain 
readable as plain text
* support defining conventions for formally referencing enums, bits, nodes etc 
(allows validation and rendering as links)

william

> On 8 Apr 2017, at 00:24, Kent Watsen  wrote:
> 
> All,
> 
> This is start of a two-week poll on making the following draft a 
> NETMOD working group document:
> 
>  draft-lhotka-netmod-yang-markup-00
> 
> Please send email to the list indicating "yes/support" or "no/do not
> support".  If indicating no, please state your reservations with the
> document.  If yes, please also feel free to provide comments you'd 
> like to see addressed once the document is a WG document.
> 
> Thank you,
> NETMOD WG Chairs

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] BBF alarm management YANG plans

[William Lupton]

All,

I believe that we last discussed alarms (and draft-vallin-netmod-alarm-module) 
back in October when the -01 draft was published. Alarm management has once 
again come to the fore in BBF and I wanted to give NETMOD an update on our 
plans.
We wish to base our alarm management support on draft-vallin-netmod-alarm-module
We request that it be adopted as a working group draft
We will have various comments, e.g.
Providing some means of overriding alarm severities
Adjusting the alarm-history feature to include some additional nodes that we 
believe should be within its scope
Various proposals to adjust node names that we feel will better reflect their 
usage and/or increase consistency
Individual contributors will bring detailed comments directly to the NETMOD 
list.

Thanks,
William___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Comments on draft-lhotka-netmod-yang-markup-00

[William Lupton]

Lada, Rob, all,

I would support use of markdown, with the principle that descriptions (etc) 
should remain readable as plain text. Indeed many of the published NETMOD YANG 
modules have descriptions that look as though they would already render quite 
well if regarded as markdown (blank lines as paragraph separators, bulleted and 
numbered lists etc).

Note that GitHub have recently published 
https://githubengineering.com/a-formal-spec-for-github-markdown, which might be 
worth looking at or even adopting? From a quick perusal, it doesn’t seem to 
include any GH specifics (e.g for referencing issues or pull requests), which 
actually surprised me a little.

Maybe this goes too far, but I would also consider conventions allowing 
validation of references to enums, bits, nodes etc within descriptions. 
Obviously this is potentially a slippery slope and potentially (if additional 
markup is needed) a threat to readability, but also a potential gain (can be 
validated and so increases quality, can become hyperlinks when rendered, etc).

William

PS, We support this sort of thing in TR-069 data model description strings. 
Showing our age, the markup is mediawiki-like. For example:
* If the ACS sets the value of this parameter to {{enum|Requested}}, the CPE 
MUST initiate the corresponding diagnostic test. When writing, the only allowed 
values are {{enum|Requested}} and {{enum|Canceled}}…
* Identifier of the class of product for which the serial number applies.  That 
is, for a given manufacturer, this  parameter is used to identify the product 
or class of product over which the {{param|SerialNumber}} parameter is unique.

> On 17 Mar 2017, at 12:55, Ladislav Lhotka  wrote:
> 
> Hi Rob,
> 
> thank you for reading the draft.
> 
>> On 17 Mar 2017, at 13:30, Robert Wilton  wrote:
>> 
>> Hi Lada,
>> 
>> I've had a quick scan of your YANG markup extension draft and I have a few 
>> comments:
>> 
>> Allowing description, and similar descriptive statements, to use something 
>> other than text seems like it could be useful in some cases.
>> 
>> I'm not sure that allowing the statements to use any text-like media type is 
>> a good idea, this could increase the burden on tool makers if each module 
>> author chooses their own preferred format.
>> 
>> Instead, I think that it might be better to restrict it to a very small set 
>> of media types, that could be extended in future.  I would think that 
>> initially just allowing plain text and one particular flavour of markdown 
>> would be a reasonable starting point.
> 
> I agree although I am not sure that we can easily find an agreement on the 
> particular flavour. So maybe we can leave it open and let the "market" decide.
> 
>> 
>> I think that the only formats that should be allowed are those that are 
>> still readily readable as plain text, so that tools that don't want to parse 
>> the formatted text can still sensibly display the descriptive statements.  
>> I.e. I don't think that it would be helpful to allow things like text/xml 
>> since it isn't easy to read.
> 
> Sure, and the draft says:
> 
>   It is RECOMMENDED to use only media types representing "lightweight"
>   markup that is easy to read even in the unprocessed source form, such
>   as "text/markdown".
> 
>> 
>> Allowing this extension on particular descriptive statements may also be 
>> helpful.  It seems plausible that the vast majority of these statements in a 
>> module might just be written in plain text with just a few of them using 
>> more advanced formatting like markdown.
> 
> Yes, I was thinking about this. On the other hand, plain text is typically 
> compatible with any markup format, so this would probably be useful only if 
> somebody wanted to use multiple different markup formats in the same module, 
> which sounds crazy. But we can discuss it.
> 
>> 
>> Finally, I have a concern that if more structured formatting in the comments 
>> is used then would that encourage model writers to produce more verbose 
>> comments, and if so that might possibly reduce the readability of the 
>> modules.  Although, I guess ultimately one has to trust the model writers to 
>> do the right thing.
> 
> Well, this draft doesn't permit anything above what module writers can do 
> already now - the descriptions etc. have to be valid YANG strings as before. 
> The only new thing is a piece of metadata that may be helpful for some tools 
> but that can also be safely ignored.
> 
> Thanks, Lada
> 
>> 
>> Thanks,
>> Rob

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] yanglint and implemented versus imported YANG modules

[William Lupton]

Inline. Thanks, W.

> On 7 Mar 2017, at 09:49, Radek Krejčí <rkre...@cesnet.cz> wrote:
> 
> Hi,
> I think that the default approach should be to expect that, until explicitly 
> stated, the imported module is just imported, not implemented. But it is fine 
> to me to add an option to force the implemented flag on all the modules. 
> Benoit can then use the flag in his scripts.
> 
> However, I checked RFC 7950 again, and I would like to have a feedback from 
> the NETMOD group to the section 7.1.5, that states that
> "the importing module may:
> ...
>   o  use any node in the imported module's schema tree in "must",
>  "path", and "when" statements, or as the target node in "augment"
>  and "deviation" statements.”

So this was the situation in the original message, right? This warning was 
being output:
* warn: Schema node "ietf-ip:ipv4" not found 
(/ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name = 
current()]/ietf-ip:ipv4)

…not because "ietf-ip:ipv4” doesn’t exist, but because the ietf-ip module was 
imported rather than implemented.

I think you are saying that (per RFC 7950 section 7.1.5) “ietf-ip:ipv4” should 
have been found, in which case there wouldn’t have been a warning. Is that 
correct?

> I'm interested in "must" and "when". I'm not sure why it is mentioned here, 
> because, in contrast to "path", "augment" and "deviation",
> "when" and "must" contain XPath expression, so actually even not defined 
> schema node can be used in it (and this is the reason why yanglint does not 
> complain with error, but just with warning). Of course, the result is then 
> always false (ok, depending on the rest of the expression, but it simply does 
> not depend on the data presence). And this is the reason to have it at least 
> as warning, because it is usually not the original intention of the author.
> 
> Regards,
> Radek
> 
> Dne 7.3.2017 v 10:00 William Lupton napsal(a):
>> Could this be the default in the first of these two cases?
>> 
>> Usage:
>>yanglint [options] [-f { yang | yin | tree }] ...
>>Validates the YANG module in , and all its dependencies.
>> 
>>yanglint [options] [-f { xml | json }] ... ...
>>Validates the YANG modeled data in  according to the .
>> 
>>> On 6 Mar 2017, at 16:59, Robert Wilton <rwil...@cisco.com 
>>> <mailto:rwil...@cisco.com>> wrote:
>>> 
>>> Hi William,
>>> 
>>> I think that what yanglint is doing here is sane, i.e. I think that its 
>>> interpretation/split between imported vs implemented modules is supported 
>>> by the YANG RFC.
>>> 
>>> However, for validation purposes it seems that it would be useful if 
>>> yanglint had an option to assume that all imported modules are implicitly 
>>> implemented without requiring them to be explicitly specified.
>>> 
>>> Thanks,
>>> Rob
>>> 
>>> On 06/03/2017 16:44, William Lupton wrote:
>>>> All,
>>>> 
>>>> This message arose from a yang-multic...@ietf.org 
>>>> <mailto:yang-multic...@ietf.org> “draft-ietf-pim-igmp-mld-yang-02.txt: 
>>>> YANG compilation isuse” (sic) thread 
>>>> <https://www.ietf.org/mail-archive/web/yang-multicast/current/threads.html#00232>
>>>>  initiated by Benoit.
>>>> 
>>>> I thought it would be useful for NETMOD to see the part of the discussion 
>>>> that relates to implemented versus imported YANG modules.
>>>> 
>>>> 1. Benoit Claise reported this warning:
>>>>  * warn: Schema node "ietf-ip:ipv4" not found 
>>>> (/ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name
>>>>  = current()]/ietf-ip:ipv4)
>>>> 2. Radek Krejčí replied:
>>>>  * These warnings are printed because in yanglint, until explicitly 
>>>> stated, the imported modules (such as ietf-interfaces and ietf-ip), are 
>>>> supposed to be only imported, not implemented. The data nodes in imported 
>>>> schemas are not available, which is the reason of these warnings.
>>>> 3. William Lupton (that’s me!) asked / commented:
>>>>  * Why are the complaints only about ip:ipv4 (etc) and not about 
>>>> if:interfaces (etc), which are also referenced in the must statements?
>>>>  * This makes it hard for an automated tool (such as Benoit’s) because 
>>>> it needs to know which other YANG files to proce

Re: [netmod] yanglint and implemented versus imported YANG modules

[William Lupton]

Could this be the default in the first of these two cases?

Usage:
yanglint [options] [-f { yang | yin | tree }] ...
Validates the YANG module in , and all its dependencies.

yanglint [options] [-f { xml | json }] ... ...
Validates the YANG modeled data in  according to the .

> On 6 Mar 2017, at 16:59, Robert Wilton <rwil...@cisco.com> wrote:
> 
> Hi William,
> 
> I think that what yanglint is doing here is sane, i.e. I think that its 
> interpretation/split between imported vs implemented modules is supported by 
> the YANG RFC.
> 
> However, for validation purposes it seems that it would be useful if yanglint 
> had an option to assume that all imported modules are implicitly implemented 
> without requiring them to be explicitly specified.
> 
> Thanks,
> Rob
> 
> On 06/03/2017 16:44, William Lupton wrote:
>> All,
>> 
>> This message arose from a yang-multic...@ietf.org 
>> <mailto:yang-multic...@ietf.org> “draft-ietf-pim-igmp-mld-yang-02.txt: YANG 
>> compilation isuse” (sic) thread 
>> <https://www.ietf.org/mail-archive/web/yang-multicast/current/threads.html#00232>
>>  initiated by Benoit.
>> 
>> I thought it would be useful for NETMOD to see the part of the discussion 
>> that relates to implemented versus imported YANG modules.
>> Benoit Claise reported this warning:
>> warn: Schema node "ietf-ip:ipv4" not found 
>> (/ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name 
>> = current()]/ietf-ip:ipv4)
>> Radek Krejčí replied:
>> These warnings are printed because in yanglint, until explicitly stated, the 
>> imported modules (such as ietf-interfaces and ietf-ip), are supposed to be 
>> only imported, not implemented. The data nodes in imported schemas are not 
>> available, which is the reason of these warnings.
>> William Lupton (that’s me!) asked / commented:
>> Why are the complaints only about ip:ipv4 (etc) and not about if:interfaces 
>> (etc), which are also referenced in the must statements?
>> This makes it hard for an automated tool (such as Benoit’s) because it needs 
>> to know which other YANG files to process in addition to the “file of 
>> interest”.
>> Radek Krejčí replied:
>> According to RFC 7950, sec 5.6.6 (3rd paragraph) [ED: 5.6.5?], when an 
>> implemented module augments another module (ietf-interfaces), the augmented 
>> module MUST be also implemented. So libyang automatically changes the 
>> augmented module from imported to the implemented. The same rule applies 
>> also in case of referring a module in path (leafref) and by deviating a 
>> module. But it does not apply when a module data is used in must or when 
>> conditions. That's the reason why it complains just about ietf-ip and not 
>> about ietf-interfaces.
>> YANG actually does not provide a way to specify that a particular import is 
>> also expected to be implemented. Therefore, libyang needs some help with 
>> setting modules implemented - all the explicitly loaded modules are supposed 
>> to be implemented, if the module is just implicitly loaded from the search 
>> directory and user did not expressed that it is supposed to be implemented, 
>> it is kept only imported to provide groupings or type definitions
>> Benoit Claise asked (referring to my reference to automated tools):
>> Would it be possible to improve the warning (and the related test, by 
>> testing implemented instead of import), basically telling that the module 
>> itself is fine?
>> 
>> I’m interested to know that NETMOD thinks about this distinction between 
>> implemented versus imported (in the absence of any instance documents). I 
>> guess my (maybe naive) view is that if all I’m doing is checking for errors 
>> in my YANG model then I don’t care about this. If my YANG is good I want to 
>> see no warnings or errors, and if it’s bad then I want to be told this (and 
>> why).
>> 
>> Thanks,
>> William
>> 
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org <mailto:netmod@ietf.org>
>> https://www.ietf.org/mailman/listinfo/netmod 
>> <https://www.ietf.org/mailman/listinfo/netmod>
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] yanglint and implemented versus imported YANG modules

[William Lupton]

All,

This message arose from a yang-multic...@ietf.org 
<mailto:yang-multic...@ietf.org> “draft-ietf-pim-igmp-mld-yang-02.txt: YANG 
compilation isuse” (sic) thread 
<https://www.ietf.org/mail-archive/web/yang-multicast/current/threads.html#00232>
 initiated by Benoit.

I thought it would be useful for NETMOD to see the part of the discussion that 
relates to implemented versus imported YANG modules.
Benoit Claise reported this warning:
warn: Schema node "ietf-ip:ipv4" not found 
(/ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name = 
current()]/ietf-ip:ipv4)
Radek Krejčí replied:
These warnings are printed because in yanglint, until explicitly stated, the 
imported modules (such as ietf-interfaces and ietf-ip), are supposed to be only 
imported, not implemented. The data nodes in imported schemas are not 
available, which is the reason of these warnings.
William Lupton (that’s me!) asked / commented:
Why are the complaints only about ip:ipv4 (etc) and not about if:interfaces 
(etc), which are also referenced in the must statements?
This makes it hard for an automated tool (such as Benoit’s) because it needs to 
know which other YANG files to process in addition to the “file of interest”.
Radek Krejčí replied:
According to RFC 7950, sec 5.6.6 (3rd paragraph) [ED: 5.6.5?], when an 
implemented module augments another module (ietf-interfaces), the augmented 
module MUST be also implemented. So libyang automatically changes the augmented 
module from imported to the implemented. The same rule applies also in case of 
referring a module in path (leafref) and by deviating a module. But it does not 
apply when a module data is used in must or when conditions. That's the reason 
why it complains just about ietf-ip and not about ietf-interfaces.
YANG actually does not provide a way to specify that a particular import is 
also expected to be implemented. Therefore, libyang needs some help with 
setting modules implemented - all the explicitly loaded modules are supposed to 
be implemented, if the module is just implicitly loaded from the search 
directory and user did not expressed that it is supposed to be implemented, it 
is kept only imported to provide groupings or type definitions
Benoit Claise asked (referring to my reference to automated tools):
Would it be possible to improve the warning (and the related test, by testing 
implemented instead of import), basically telling that the module itself is 
fine?

I’m interested to know that NETMOD thinks about this distinction between 
implemented versus imported (in the absence of any instance documents). I guess 
my (maybe naive) view is that if all I’m doing is checking for errors in my 
YANG model then I don’t care about this. If my YANG is good I want to see no 
warnings or errors, and if it’s bad then I want to be told this (and why).

Thanks,
William___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Are multiple revisions with the same date allowed?

[William Lupton]

RFC 7950 Section 7.1.9 says that “For every published editorial change, a new 
one SHOULD be added in front of the revisions sequence so that all revisions 
are in reverse chronological order.” So I think it probably SHOULD be an error 
if the revision dates aren’t monotonically decreasing (from top to bottom) but 
having two revisions with the same date doesn't seem to be ambiguous.

The practical issue, of course, is that per RFC 7950 Section 5.2, "The name of 
the file SHOULD be of the form: module-or-submodule-name ['@' revision-date] ( 
'.yang' / '.yin’ )”, so if two revisions have the same revision date how are 
the files to be named?

Note that RFC 6087bis Section 5.8 says "However, whenever a new (i.e. changed) 
version is made available (e.g., via a new version of an Internet-Draft), the 
revision date of that new version MUST be updated to a date later than that of 
the previous version.” This is a requirement that revision dates in “available” 
versions are strictly increasing.

William

> On 30 Jan 2017, at 12:20, Robert Wilton  wrote:
> 
> Juergen,
> 
> Thanks.  This isn't something that we need - just something that I noticed 
> when reading 7950.
> 
> I was more questioning whether it should be allowed, given that a (module 
> name, revision date) pair should effectively uniquely identify a published 
> module.  Conversely, having multiple revisions with the same date doesn't 
> seem to cause any harm either - other than the ambiguity that you mention 
> that module authors would be wise to avoid anyway.
> 
> Perhaps a statement could be added to 6087bis that revision dates for a 
> module SHOULD be unique to avoid any potential ambiguity?
> 
> Rob
> 
> 
> On 30/01/2017 12:05, Juergen Schoenwaelder wrote:
>> Rob,
>> 
>> since we are talking about _published_ modules, this is going to be
>> rare. Perhaps we could have allowed an optional time specification
>> here to handle this case (since multiple revisions with the same date
>> cause ambiguity) but then in most organizations this is unlikely to
>> happen (at least this is what we assumed).
>> 
>> /js
>> 
>> On Mon, Jan 30, 2017 at 11:50:20AM +, Robert Wilton wrote:
>>> RFC 7950 doesn't state that the date associated with revision statements in
>>> a YANG module must be unique.
>>> 
>>> Hence, I presume that it is intentionally allowed to have multiple revision
>>> statements with the same date.  E.g. the following module is allowed (and
>>> passes pyang --lint):
>>> 
>>> module rev-example {
>>>   namespace
>>> "urn:example";
>>> 
>>>   prefix ex;
>>> 
>>>   organization "";
>>> 
>>>   contact "";
>>> 
>>>   description "'";
>>>   reference "IEEE 802.3-2015, unless dated explicitly";
>>> 
>>>   revision 2017-01-30 {
>>> description
>>>   "A revision description";
>>> reference "";
>>>   }
>>> 
>>>   revision 2017-01-30 {
>>> description
>>>   "A different revision with the same date";
>>> reference "";
>>>   }
>>> 
>>> }
>>> 
>>> Thanks,
>>> Rob
>>> 
>>> 
>>> ___
>>> 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] RFC 6087bis (draft 09) description-stmt

[William Lupton]

Andy, all,

RFC 6087bis nearly always says “description statement” but on one occasion it 
says "description-stmt” (when discussing its use within “feature-stmt”).

It also usually doesn’t quote “description”, but on a few (clustered?) 
occasions it does quote it.

The above remarks may apply more generally (i.e to other statements).

Thanks,
William
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-entity issue #13

[William Lupton]

So could “being writable” be associated with a feature (which might potentially 
apply to multiple such nodes)? W.

(and if so, what’s the cleanest way to achieve this? it seems that “if-feature” 
can’t be used with “config” but that it could be used by refining a grouping?)

> On 22 Dec 2016, at 05:14, Randy Presuhn  
> wrote:
> 
> Hi -
> 
> On 12/21/2016 6:56 AM, Martin Bjorklund wrote:
> ...
>> This procedure would change how serial-num currently is handled.  I
>> don't have a strong opinion on this, but I note that serial-num is
>> writable in the ENTITY-MIB.  Maybe someone can comment on why it is
>> writable in the MIB, and if this is a use case that we want to
>> support?
> 
> I *think* this is an example of what were known as "post-it note"
> objects.  Their values could be set by management action
> to accommodate implementations in which, for example, the hardware
> provided no way for software to access the information printed on an
> inventory sticker affixed to a card.
> 
> Randy
> 
> ___
> 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] RFC 7277: ip-address-origin

[William Lupton]

FYI the TR-181 “Device:2” data model (a TR-069 data model) defines a 
conceptually similar IPv6 address origin parameter (*):

—— 
Mechanism via which the IP address was assigned. Enumeration of:
AutoConfigured (Automatically generated. For example, a link-local address as 
specified by SLAAC [Section 5.3/RFC4862], a global address as specified by 
SLAAC [Section 5.5/RFC4862], or generated via CPE logic (e.g. from delegated 
prefix as specified by [RFC3633]), or from ULA /48 prefix as specified by 
[RFC4193])
DHCPv6 (Assigned by DHCPv6 [RFC3315])
IKEv2 (Assigned by IKEv2 [RFC5996])
MAP (Assigned by MAP [RFC7597], i.e. is this interface's MAP IPv6 address)
WellKnown (Specified by a standards organization, e.g. the ::1 loopback 
address, which is defined in [RFC4291])
Static (For example, present in the factory default configuration (but not 
WellKnown), created by the ACS, or created by some other management entity 
(e.g. via a GUI))
This parameter is based on ipOrigin from [RFC4293].
——

Rather than defining a “slaac” value we defined AutoConfigured to include SLAAC 
and other auto-configuration mechanisms. We also listed some other protocols 
via which the address might be assigned. We perhaps should have defined an 
“Other” value but the thinking might have been that it was better to extend the 
enumeration with other specific protocols rather than use “Other”.

This is intended for IPv6 only. We also defined an IPv4 addressing type 
parameter (**) with enumerations {DHCP, IKEv2, AutoIP, IPCP, Static}.

William

(*) 
https://www.broadband-forum.org/cwmp/tr-181-2-11-0.html#D.Device:2.Device.IP.Interface.%7Bi%7D.IPv6Address.%7Bi%7D.Origin
(**) 
https://www.broadband-forum.org/cwmp/tr-181-2-11-0.html#D.Device:2.Device.IP.Interface.%7Bi%7D.IPv4Address.%7Bi%7D.AddressingType

> On 16 Dec 2016, at 14:13, Ladislav Lhotka  wrote:
> 
> 
>> On 16 Dec 2016, at 15:05, Martin Bjorklund  wrote:
>> 
>> Ladislav Lhotka  wrote:
>>> 
 On 16 Dec 2016, at 14:39, Juergen Schoenwaelder 
  wrote:
 
 Lada,
 
 when would I use link-layer and when link-local? Perhaps all needed is
 a clarification of the description of link-layer? (Perhaps link-local
>>> 
>>> The distinction between SLAAC and link-local address is IMO also important.
>>> 
 would have been a better name but too late now...)
>>> 
>>> That's why I believe the draconian update rules in sec. 11 of RFC
>>> 7950 are seriously counterproductive (at this stage at least). We
>>> should simply fix such mistakes and omissions in a new revision of
>>> ietf-ip, because otherwise the modules will soon be full of
>>> rubbish.
>> 
>> I agree w/ Acee that the name 'link-layer' is more appropriate for the
>> *origin* of the address.
> 
> That's possible for link-local but not for SLAAC, which is an L3 mechanism.
> 
> So a fix might be:
> 
> 1. Change description of "link-layer" to include link-local addresses.
> 
> 2. Add a new enum, e.g. "slaac".
> 
> Lada
> 
>> 
>> If you manually configure a link-local address the origin would be
>> 'static'.
>> 
>> 
>> /martin
>> 
>> 
 An RFC 3927 address could also be a 'random' address. In fact, the
 169.254/16 prefix kind of hings at RFC 3927 addresses falling under
 'random'.
>>> 
>>> OK, so adding 3927 to "reference" should suffice in this case.
>>> 
>>> Lada
>>> 
 
 /js
 
 On Fri, Dec 16, 2016 at 02:33:04PM +0100, Ladislav Lhotka wrote:
> Hi,
> 
> I think that one important enum is missing in the "ip-address-origin" 
> typedef:
> 
> enum link-local {
>  description
>"Indicates a link-local address.";
>  reference
>"RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses
> RFC 4291: IP Version 6 Addressing Architecture";
> 
> Would an erratum be possible/useful?
> 
> Lada
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> ___
> 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 
>>> 
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF work depending on draft-ietf-netmod-entity-01

[William Lupton]

The current draft-ietf-netmod-entity-01 defines ietf-hardware and iana-entity 
modules. Is it intended that iana-entity will become iana-hardware? Thanks, W.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-intf-ext-yang-02.txt

[William Lupton]

Rob, all,

Please note that the ietf-interfaces-common tree doesn’t seem to match the YANG 
(at least as far as features are concerned). Also I noticed that the module 
names are reported (at least once) in the draft as interface-extensions and 
etherlike-interfaces, whereas they are now ietf-interfaces-common and 
ietf-interfaces-ethernet-like.

Thanks,
William

> On 27 Oct 2016, at 08:53, 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 of the IETF.
> 
>Title   : Common Interface Extension YANG Data Models
>Authors : Robert Wilton
>  David Ball
>  Tapraj Singh
>  Selvakumar Sivaraj
>   Filename: draft-ietf-netmod-intf-ext-yang-02.txt
>   Pages   : 25
>   Date: 2016-10-27
> 
> Abstract:
>   This document defines two YANG modules that augment the Interfaces
>   data model defined in the "YANG Data Model for Interface Management"
>   with additional configuration and operational data nodes to support
>   common lower layer interface properties, such as interface MTU.
>   These properties are common to many types of interfaces on network
>   routers and switches and are implemented by multiple network
>   equipment vendors with similar semantics, even though some of the
>   features are not formally defined in any published standard.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-netmod-intf-ext-yang-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-intf-ext-yang-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/
> 
> ___
> 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] New Version Notification for draft-vallin-netmod-alarm-module-00.txt

[William Lupton]

All,

The Broadband Forum (BBF) is definitely interested and has been working on some 
extensions to the original draft.

BBF’s main technical change is to add an “alarm-history” feature (see below for 
an indication of what it does) that sounds quite like one of Alex Campbell’s 
proposals. There are also a few other minor changes, and others may arise as a 
result of the “Straw Ballot” process mentioned below.

The problem is that BBF wants to publish its changes very soon. The changes 
will be in “Straw Ballot” (similar to WGLC) at our upcoming Q4 meeting (next 
week), which would see them published in Q1 2017. They would presumably be 
published as a BBF YANG module that happened to be very similar to the new 
Vallin draft module (it wouldn’t be possible to use augment to add the 
alarm-history feature, right?).

In an ideal world we would prefer to work with IETF to define a module that we 
could then use or augment directly, but the timescales just don’t permit that. 
One “less bad” option might be to try to feed the proposed final BBF version 
(which should be available around the end of this month) into a new IETF draft 
resulting from (a) Direct collaboration between BBF representatives and the 
draft authors, or (b) BBF-led discussion on the NETMOD list. Then BBF could use 
this new IETF draft (not ideal, but reduces the chances of future divergence).

Thanks,
William Lupton

—— indication of what the BBF alarm-history feature does (still based on 
expired vallin draft) —— 

% grep -B1 -A0 'if-feature alarm-history' ietf-alarms.yang 
  leaf max-alarm-history {
if-feature alarm-history;
--
  leaf notify-status-changes {
if-feature alarm-history;
--
  leaf cleared {
if-feature alarm-history;
--
leaf is-cleared {
  if-feature alarm-history;
--
list status-change {
  if-feature alarm-history;
--
  rpc compress {
if-feature alarm-history;
--
  rpc compress-alarms {
if-feature alarm-history;
--
  rpc purge-alarms {
if-feature alarm-history;

> On 5 Oct 2016, at 13:26, Martin Bjorklund <m...@tail-f.com> wrote:
> 
> Hi,
> 
> We have posted a new version of the alarm module.  The previous
> document was called draft-vallin-alarm-yang-module-00, this new
> version is called draft-vallin-netmod-alarm-module (hence it is also a
> -00).
> 
> This updated version incorporates comments on the previous docuement,
> and adds support for alarm shelving.
> 
> It would be good to know if people in this WG are interested in this
> work.
> 
> 
> /martin and stefan
> 
> 
> 
> 
> A new version of I-D, draft-vallin-netmod-alarm-module-00.txt
> has been successfully submitted by Martin Bjorklund and posted to the
> IETF repository.
> 
> Name: draft-vallin-netmod-alarm-module
> Revision: 00
> Title:YANG Alarm Module
> Document date:2016-10-05
> Group:Individual Submission
> Pages:58
> URL:
> https://www.ietf.org/internet-drafts/draft-vallin-netmod-alarm-module-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-vallin-netmod-alarm-module/
> Htmlized:   
> https://tools.ietf.org/html/draft-vallin-netmod-alarm-module-00
> 
> 
> Abstract:
>   This document defines a YANG module for alarm management.  It
>   includes functions for alarm list management, alarm shelving and
>   notifications to inform management systems.  There are also RPCs to
>   manage the operator state of an alarm and administrative alarm
>   procedures.  The module carefully maps to relevant alarm standards.
> 
> ___
> 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] Publication of BBF TR-355 "YANG Modules for FTTdp Management"

[William Lupton]

All,

The Broadband Forum (BBF) would like to announce that TR-355 "YANG Modules for 
FTTdp Management" has been published. The document can be downloaded at the BBF 
Technical Reports page  
and the YANG modules are available at  
and .
 
There are seven YANG modules, six that cover DSL and G.fast interface 
technologies and testing, and a seventh that defines common data types that 
will be used throughout BBF YANG modules. Please see the recent press release 

 for further details.

Thanks,
William
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[William Lupton]

Andy,

This thread started with discussion of an apparent ambiguity in the current 
text:

OLD

It is acceptable to reuse the same revision statement within unpublished 
versions (i.e., Internet-Drafts), but the revision date MUST be updated to a 
higher value each time the Internet-Draft is re-posted.

—— 

It became clear from the subsequent discussion (thanks Randy!) that the above 
text isn’t intended to mean “reuse the identical revision statement, INCLUDING 
THE REVISION DATE” but to mean “reuse the revision statement, UPDATING THE 
REVISION DATE”.

Then other people raised other points, e.g only updating the revision date if 
the YANG has changed, distinguishing between the document and the YANG 
contained therein, and distinguishing between YANG in IDs and YANG created by 
other SDOs. My proposed new text tries to address all of these:

NEW:

It is not required to keep the full revision history of draft versions (e.g., 
modules contained within Internet-Drafts). That is, within a sequence of draft 
versions, only the most recent revision need be recorded in the module. 
However, if the module has changed, the revision date of the most recent 
revision MUST be updated to a later date whenever a new version is made 
available (e.g., via a new version of an Internet-Draft).

——

I believe that this retains the original intent in a way that resolves the 
original ambiguity and addresses the other points that were raised. It it’s 
“worse”, how is it worse (apart from being longer, on which point mea culpa)?

Thanks,
William

> On 19 Aug 2016, at 15:42, Andy Bierman  wrote:
> 
> On Fri, Aug 19, 2016 at 7:13 AM, Dale R. Worley  > wrote:
> Andy Bierman > writes:
> > An Internet-Draft is NOT a means of "publishing" a specification;
> 
> As I said, that's the theory, but practice is considerably different.
> 
> Anybody that implements a work-in-progress knows they are taking a risk
> on an unstable document.  The guideline already says MUST update
> the revision date.
> 
> Not sure what more you want to guidelines document to do.
>  
> Dale
> 
> Andy
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] derived-from-or-self leads to circular import

[William Lupton]

Regardless of whether circular import is permitted, isn’t it best avoided from 
a layering point of view? In general I would think that a module should be 
importing things that (a) it needs, and (b) don’t need it. W.

> On 29 Aug 2016, at 11:34, Ladislav Lhotka  wrote:
> 
>> On 29 Aug 2016, at 09:17, Bogaert, Bart (Nokia - BE) 
>>  wrote:
>> 
>> Just taking another approach on this: why do we have the restriction on
>> circular imports?  Is this really required?  If not then this may be solved
>> in another way too (but will take some time before it gets into the YANG
>> compilers I'm afraid).
> 
> In fact, it isn't really needed. Unlike imports in programming languages such 
> as Python, import in YANG doesn't incorporate the imported module contents, 
> just gives access to objects in a foreign namespace.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[William Lupton]

Oh dear :(. What do you think about this, which is what I really care about?

— 
Regardless of the discussion about “published”, other organisations may be 
planning to use YANG modules that are currently within IDs. Obviously it’s 
vastly preferable if such IDs become RFCs before these other organisations 
publish any specifications or data models that use such draft IETF YANG, but it 
might occasionally be necessary to reference a draft model (hopefully one that 
has already been sent for AD review) in a published standard. This is why I 
would like the clarification to cover IDs (at least WG-adopted ones)!
— 

William

> On 18 Aug 2016, at 18:21, Andy Bierman <a...@yumaworks.com> wrote:
> 
> Hi,
> 
> So this is the test that is supposed to replace 5.8, para 7:
> 
>It is acceptable to reuse the same revision statement within
>unpublished versions (i.e., Internet-Drafts), but the revision date
>MUST be updated to a higher value each time the Internet-Draft is re-
>posted.
> 
> IMO the new text is worse.
> 
> I like the suggestion to define "published" and "unpublished"
> to have the semantics defined in RFC 2026.
> 
> 
> 
> Andy
> 
> On Thu, Aug 18, 2016 at 10:08 AM, William Lupton <wlup...@broadband-forum.org 
> <mailto:wlup...@broadband-forum.org>> wrote:
> Thanks. Of course I am fine with this suggestion. This gives:
> 
> NEW:
> 
> It is not required to keep the full revision history of draft versions (e.g., 
> modules contained within Internet-Drafts). That is, within a sequence of 
> draft versions, only the most recent revision need be recorded in the module. 
> However, if the module has changed, the revision date of the most recent 
> revision MUST be updated to a later date whenever a new version is made 
> available (e.g., via a new version of an Internet-Draft).
> 
> > On 18 Aug 2016, at 13:21, Ladislav Lhotka <lho...@nic.cz 
> > <mailto:lho...@nic.cz>> wrote:
> >
> > William Lupton <wlup...@broadband-forum.org 
> > <mailto:wlup...@broadband-forum.org>> writes:
> >
> >> Kent, all,
> >>
> >> OK :). I will take Lada’s update to my Monday text as a baseline and will 
> >> give my proposed new text without further ado, followed by rationale.
> >>
> >> BASELINE:
> >>
> >> It is not required to keep the revision history of unpublished versions 
> >> (e.g., Internet-Drafts). That is, within a sequence of unpublished 
> >> versions, only the most recent revision MAY be recorded in the module or 
> >> submodule. However, the revision date of the most recent revision MUST be 
> >> updated to a higher value each time a new version (e.g., of the 
> >> Internet-Draft) is posted.
> >>
> >> NEW:
> >>
> >> It is not required to keep the full revision history of draft versions
> >> (e.g., modules contained within Internet-Drafts). That is, within a
> >> sequence of draft versions, only the most recent revision need be
> >> recorded in the module. However, if the module has changed, the
> >> revision date of the most recent revision MUST be updated to a higher
> >> value whenever a new version is made available (e.g., via a new
> >> version of an Internet-Draft).
> >
> > I like this text. Perhaps "a higher value" could be replaced with "a
> > later date"?
> >
> > Lada
> >
> >>
> >> ——
> >>
> >> The main comments and suggestions on the baseline text were:
> >> Why say MAY rather than MUST? Suggestion to say “need” to avoid difficulty 
> >> with “only” and “MAY”.
> >> Should be more precise re the difference between a draft and a module 
> >> contained within a draft.
> >> Should allow or encourage the module revision date to be bumped only if 
> >> the YANG has changed (or on the containing draft becoming a standard).
> >> Discussion of “published” / “posted” etc., and their meanings in an IETF 
> >> context.
> >> Support for the principle that the text should be both general (applying 
> >> to all organisations) and specific (applying to IETF) and note that 
> >> IETF-specific text should be parenthesised.
> >> Assertion that all publicly-available “adopted” modules (whether draft or 
> >> standard) must bump revision dates if the YANG changes.
> >>
> >> Here are a few notes to forestall some of your possible comments:
> >> I didn’t mention submodules, because of the generic (Section 2.3) note 
> >> that “module” means “module or submodule” unless specificall

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[William Lupton]

Thanks. Of course I am fine with this suggestion. This gives:

NEW:

It is not required to keep the full revision history of draft versions (e.g., 
modules contained within Internet-Drafts). That is, within a sequence of draft 
versions, only the most recent revision need be recorded in the module. 
However, if the module has changed, the revision date of the most recent 
revision MUST be updated to a later date whenever a new version is made 
available (e.g., via a new version of an Internet-Draft).

> On 18 Aug 2016, at 13:21, Ladislav Lhotka <lho...@nic.cz> wrote:
> 
> William Lupton <wlup...@broadband-forum.org> writes:
> 
>> Kent, all,
>> 
>> OK :). I will take Lada’s update to my Monday text as a baseline and will 
>> give my proposed new text without further ado, followed by rationale.
>> 
>> BASELINE:
>> 
>> It is not required to keep the revision history of unpublished versions 
>> (e.g., Internet-Drafts). That is, within a sequence of unpublished versions, 
>> only the most recent revision MAY be recorded in the module or submodule. 
>> However, the revision date of the most recent revision MUST be updated to a 
>> higher value each time a new version (e.g., of the Internet-Draft) is posted.
>> 
>> NEW:
>> 
>> It is not required to keep the full revision history of draft versions
>> (e.g., modules contained within Internet-Drafts). That is, within a
>> sequence of draft versions, only the most recent revision need be
>> recorded in the module. However, if the module has changed, the
>> revision date of the most recent revision MUST be updated to a higher
>> value whenever a new version is made available (e.g., via a new
>> version of an Internet-Draft).
> 
> I like this text. Perhaps "a higher value" could be replaced with "a
> later date"?
> 
> Lada
> 
>> 
>> —— 
>> 
>> The main comments and suggestions on the baseline text were:
>> Why say MAY rather than MUST? Suggestion to say “need” to avoid difficulty 
>> with “only” and “MAY”.
>> Should be more precise re the difference between a draft and a module 
>> contained within a draft.
>> Should allow or encourage the module revision date to be bumped only if the 
>> YANG has changed (or on the containing draft becoming a standard).
>> Discussion of “published” / “posted” etc., and their meanings in an IETF 
>> context.
>> Support for the principle that the text should be both general (applying to 
>> all organisations) and specific (applying to IETF) and note that 
>> IETF-specific text should be parenthesised.
>> Assertion that all publicly-available “adopted” modules (whether draft or 
>> standard) must bump revision dates if the YANG changes.
>> 
>> Here are a few notes to forestall some of your possible comments:
>> I didn’t mention submodules, because of the generic (Section 2.3) note that 
>> “module” means “module or submodule” unless specifically discussing 
>> submodules.
>> I didn’t mention RFC publication as a special case (revision date MUST be 
>> unconditionally updated) because this paragraph is only about drafts. I 
>> assume that requirements governing modules in RFCs are already covered 
>> elsewhere.
>> I hope that I avoided IETF-emotive terms outside the parentheses, e.g I used 
>> the terms “draft” and “made available”.
>> I nearly added “statement” as in “revision date of the most recent revision 
>> statement”. I would certainly be happy with that change.
>> I don’t really like “higher value” because that makes it sounds like a 
>> numeric value. However, no-one has commented on this and I guess it’s 
>> unambiguous. So let fido sleep on.
>> 
>> Comments?
>> 
>> Thanks,
>> William
>> 
>>> On 16 Aug 2016, at 19:02, Kent Watsen <kwat...@juniper.net> wrote:
>>> 
>>> Hi William,
>>> 
>>> Do you want to take a stab on consolidating on the comments into new 
>>> proposed draft-text?  - there were two proposals put out before, and a 
>>> number of refinements since, but I’m unsure which were picked up or not.  
>>> Since you raised this issue originally, if would be helpful to get your 
>>> current take on it.
>>> 
>>> Thanks,
>>> Kent
>> ___
>> 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] RFC 6087bis guidance re use of revision statements in drafts

[William Lupton]

Kent, all,

OK :). I will take Lada’s update to my Monday text as a baseline and will give 
my proposed new text without further ado, followed by rationale.

BASELINE:

It is not required to keep the revision history of unpublished versions (e.g., 
Internet-Drafts). That is, within a sequence of unpublished versions, only the 
most recent revision MAY be recorded in the module or submodule. However, the 
revision date of the most recent revision MUST be updated to a higher value 
each time a new version (e.g., of the Internet-Draft) is posted.

NEW:

It is not required to keep the full revision history of draft versions (e.g., 
modules contained within Internet-Drafts). That is, within a sequence of draft 
versions, only the most recent revision need be recorded in the module. 
However, if the module has changed, the revision date of the most recent 
revision MUST be updated to a higher value whenever a new version is made 
available (e.g., via a new version of an Internet-Draft).

—— 

The main comments and suggestions on the baseline text were:
Why say MAY rather than MUST? Suggestion to say “need” to avoid difficulty with 
“only” and “MAY”.
Should be more precise re the difference between a draft and a module contained 
within a draft.
Should allow or encourage the module revision date to be bumped only if the 
YANG has changed (or on the containing draft becoming a standard).
Discussion of “published” / “posted” etc., and their meanings in an IETF 
context.
Support for the principle that the text should be both general (applying to all 
organisations) and specific (applying to IETF) and note that IETF-specific text 
should be parenthesised.
Assertion that all publicly-available “adopted” modules (whether draft or 
standard) must bump revision dates if the YANG changes.

Here are a few notes to forestall some of your possible comments:
I didn’t mention submodules, because of the generic (Section 2.3) note that 
“module” means “module or submodule” unless specifically discussing submodules.
I didn’t mention RFC publication as a special case (revision date MUST be 
unconditionally updated) because this paragraph is only about drafts. I assume 
that requirements governing modules in RFCs are already covered elsewhere.
I hope that I avoided IETF-emotive terms outside the parentheses, e.g I used 
the terms “draft” and “made available”.
I nearly added “statement” as in “revision date of the most recent revision 
statement”. I would certainly be happy with that change.
I don’t really like “higher value” because that makes it sounds like a numeric 
value. However, no-one has commented on this and I guess it’s unambiguous. So 
let fido sleep on.

Comments?

Thanks,
William

> On 16 Aug 2016, at 19:02, Kent Watsen  wrote:
> 
> Hi William,
> 
> Do you want to take a stab on consolidating on the comments into new proposed 
> draft-text?  - there were two proposals put out before, and a number of 
> refinements since, but I’m unsure which were picked up or not.  Since you 
> raised this issue originally, if would be helpful to get your current take on 
> it.
> 
> Thanks,
> Kent
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[William Lupton]

Kent,

A couple of your comments have suggested that you feel that the “new version is 
posted” language should be clarified in the direction (for IETF YANG) of “ID 
becomes RFC”. That’s not how I read the original or how I read most of the 
discussion, and it’s also not the clarification that I was hoping for!

Regardless of the discussion about “published”, other organisations may be 
planning to use YANG modules that are currently within IDs. Obviously it’s 
vastly preferable if such IDs become RFCs before these other organisations 
publish any specifications or data models that use such draft IETF YANG, but it 
might occasionally be necessary to reference a draft model (hopefully one that 
has already been sent for AD review) in a published standard. This is why I 
would like the clarification to cover IDs (at least WG-adopted ones)!

Thanks,
William

> On 15 Aug 2016, at 20:40, Kent Watsen <kwat...@juniper.net> wrote:
> 
> Nits:
> 
> 1. First it says “unpublished” then it says “posted”, I think it better to 
> replace the latter with “published” so the terms are consistent.
> 
> 2. “unpublished” is unclear.  At least I consider submitting an I-D to 
> datatracker as a form of publishing.  I think it might be better here to 
> refer to something like “works in progress”.
> 
> 3. Instead of saying “when a new version (of the I-D) is posted”, it would be 
> clearer to say “when a new version is posted (e.g., it becomes an RFC)”.
> 
> Kent  // as a contributor
> 
> 
> 
> 
> On 8/15/16, 3:17 PM, "netmod on behalf of Randy Presuhn" 
> <netmod-boun...@ietf.org on behalf of randy_pres...@alumni.stanford.edu> 
> wrote:
> 
>Hi -
> 
>This also works for me, but I'd replace the odd "MAY" with the word "need".
> 
>(The semantics of "only" and of "MAY" don't quite mesh.)
> 
>Randy
> 
>On 8/15/2016 4:44 AM, Ladislav Lhotka wrote:
>>> On 15 Aug 2016, at 13:31, William Lupton <wlup...@broadband-forum.org> 
>>> wrote:
>>> 
>>> Ah! Re-reading it I think that you are correct. In this spirit I propose 
>>> the change shown below. I believe that all this does is (a) generalise, and 
>>> (b) clarify. I don’t believe that it changes the intended meaning.
>>> 
>>> OLD:
>>> 
>>> It is acceptable to reuse the same revision statement within unpublished 
>>> versions (i.e., Internet-Drafts), but the revision date MUST be updated to 
>>> a higher value each time the Internet-Draft is re-posted.
>>> 
>>> NEW:
>>> 
>>> It is acceptable to reuse the same revision statement within unpublished 
>>> versions (e.g., Internet-Drafts), but the revision date (i.e., the revision 
>>> statement’s argument) MUST be updated to a higher value each time a new 
>>> version (e.g., of the Internet-Draft) is posted.
>> It seems strange to talk about reusing the revision statement and, in the 
>> same sentence, require to change its argument. What about this:
>> 
>> NEW
>> 
>> It is not required to keep the revision history of unpublished versions 
>> (e.g., Internet-Drafts). That is, within a sequence of unpublished versions, 
>> only the most recent revision MAY be recorded in the module or submodule. 
>> However, the revision date of the most recent revision MUST be updated to a 
>> higher value each time a new version (e.g., of the Internet-Draft) is posted.
>> 
>> Lada
>> 
>>> ——
>>> 
>>> Comments?
>>> 
>>>> On 11 Aug 2016, at 17:26, Randy Presuhn 
>>>> <randy_pres...@alumni.stanford.edu> wrote:
>>>> 
>>>> Hi -
>>>> 
>>>> I read the text as intended to make a distinction between the *date* 
>>>> portion and the rest
>>>> 
>>>> of the revision statement.  When a module is under development, retaining 
>>>> a history
>>>> 
>>>> of specific incremental changes isn't terribly helpful, but changing the 
>>>> date is essential
>>>> 
>>>> to helping tools decide among the versions floating around in the lab.
>>>> 
>>>> 
>>>> Randy (experimenting with mail readers, please forgive formatting 
>>>> anomalies)
>>>> 
>>>> 
>>>> On 8/11/2016 9:17 AM, William Lupton wrote:
>>>>> Thanks. e.g rather than i.e sounds good, BUT my point (sorry if that 
>>>>> wasn’t clear) is that this sentence seems to be contradictory. It says:
>>>>> 
>>>>> 1. Unpublished versions, i.e 

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[William Lupton]

Ah! Re-reading it I think that you are correct. In this spirit I propose the 
change shown below. I believe that all this does is (a) generalise, and (b) 
clarify. I don’t believe that it changes the intended meaning.

OLD:

It is acceptable to reuse the same revision statement within unpublished 
versions (i.e., Internet-Drafts), but the revision date MUST be updated to a 
higher value each time the Internet-Draft is re-posted.

NEW:

It is acceptable to reuse the same revision statement within unpublished 
versions (e.g., Internet-Drafts), but the revision date (i.e., the revision 
statement’s argument) MUST be updated to a higher value each time a new version 
(e.g., of the Internet-Draft) is posted.

——

Comments?

> On 11 Aug 2016, at 17:26, Randy Presuhn <randy_pres...@alumni.stanford.edu> 
> wrote:
> 
> Hi -
> 
> I read the text as intended to make a distinction between the *date* portion 
> and the rest
> 
> of the revision statement.  When a module is under development, retaining a 
> history
> 
> of specific incremental changes isn't terribly helpful, but changing the date 
> is essential
> 
> to helping tools decide among the versions floating around in the lab.
> 
> 
> Randy (experimenting with mail readers, please forgive formatting anomalies)
> 
> 
> On 8/11/2016 9:17 AM, William Lupton wrote:
>> Thanks. e.g rather than i.e sounds good, BUT my point (sorry if that wasn’t 
>> clear) is that this sentence seems to be contradictory. It says:
>> 
>> 1. Unpublished versions, i.e IDs, can reuse revision statements.
>> 2. IDs MUST update their revision dates each time they are re-posted.
>> 
>> My suggestion of removing the parenthesised text was to remove this 
>> contradiction. Right now I’m not clear that I can rely on revision dates in 
>> YANG modules contained within IDs.
>> 
>> William
>> 
>> PS, I think that the removal of this text removes the contradiction because 
>> in order to make sense of the sentence the reader will be forced to the 
>> conclusion that IDs are not regarded as being “unpublished”.
>> 
>>> On 11 Aug 2016, at 17:07, Randy Presuhn <randy_pres...@alumni.stanford.edu 
>>> <mailto:randy_pres...@alumni.stanford.edu>> wrote:
>>> 
>>> Hi -
>>> 
>>> The situation with Internet-Drafts is what motivated this text in the first 
>>> place, so
>>> I think it is important to retain that information.  However, it seems to 
>>> me that
>>> the "i.e." is too limiting, and should be replaced with an "e.g.".
>>> 
>>> Randy
>>> 
>>> On 8/11/2016 2:06 AM, William Lupton wrote:
>>>> All,
>>>> 
>>>> The text at the bottom of RFC 6087bis (draft 07) Section 5.8 seems unclear:
>>>> 
>>>> "It is acceptable to reuse the same revision statement within unpublished 
>>>> versions (i.e., Internet-Drafts), but the revision date MUST be updated to 
>>>> a higher value each time the Internet-Draft is re-posted”
>>>> 
>>>> Assuming that the intent is that the revision statements in YANG models 
>>>> contained within IDs must be updated whenever the models are updated,  
>>>> wouldn’t it be clearer if the parenthesised text "(i.e., Internet-Drafts)” 
>>>> was deleted?
>>>> 
>>>> Thanks,
>>>> William

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[William Lupton]

Ideally I’d like a stronger guarantee than that, e.g that all YANG modules in 
WG-adopted IDs MUST have revision dates that reflect the most recent change to 
that YANG (*). The key point is that other SDOs (such as BBF!) will often 
develop YANG modules that (during the development phase) depend on YANG modules 
from IDs, so it’s important to be able to rely on their revision dates.

(*) Or the ID publication date if you prefer, but 6087bis already says “The 
revision date does not need to be updated if the module contents do not change 
in the new document revision”. Is this intended to apply to IDs?

> On 11 Aug 2016, at 17:18, Kent Watsen <kwat...@juniper.net> wrote:
> 
> I think the issue is at the end of the sentence, my proposal:
> 
>- the Internet-Draft is re-posted.
>+ the work is published (e.g., it becomes an RFC).
> 
> That said, for IETF drafts (not other SDOs), my understanding is that the 
> revision statement’s date value SHOULD be the date that the I-D is uploaded 
> to IETF datatracker.  All my drafts are built using a Makefile that includes 
> `sed` processing instructions to set the YANG module dates to the current 
> date - and they include RFC-Editor instructions to reset the value again to 
> the date the RFC is published.
> 
> Kent   // as a contributor
> 
> 
> On 8/11/16, 5:06 AM, "netmod on behalf of William Lupton" 
> <netmod-boun...@ietf.org on behalf of wlup...@broadband-forum.org> wrote:
> 
>All,
> 
>The text at the bottom of RFC 6087bis (draft 07) Section 5.8 seems unclear:
> 
>"It is acceptable to reuse the same revision statement within unpublished 
> versions (i.e., Internet-Drafts), but the revision date MUST be updated to a 
> higher value each time the Internet-Draft is re-posted”
> 
>Assuming that the intent is that the revision statements in YANG models 
> contained within IDs must be updated whenever the models are updated,  
> wouldn’t it be clearer if the parenthesised text "(i.e., Internet-Drafts)” 
> was deleted?
> 
>Thanks,
>William
>___
>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] RFC 6087bis guidance re use of revision statements in drafts

[William Lupton]

Thanks. e.g rather than i.e sounds good, BUT my point (sorry if that wasn’t 
clear) is that this sentence seems to be contradictory. It says:
Unpublished versions, i.e IDs, can reuse revision statements.
IDs MUST update their revision dates each time they are re-posted.

My suggestion of removing the parenthesised text was to remove this 
contradiction. Right now I’m not clear that I can rely on revision dates in 
YANG modules contained within IDs.

William

PS, I think that the removal of this text removes the contradiction because in 
order to make sense of the sentence the reader will be forced to the conclusion 
that IDs are not regarded as being “unpublished”.

> On 11 Aug 2016, at 17:07, Randy Presuhn <randy_pres...@alumni.stanford.edu> 
> wrote:
> 
> Hi -
> 
> The situation with Internet-Drafts is what motivated this text in the first 
> place, so
> I think it is important to retain that information.  However, it seems to me 
> that
> the "i.e." is too limiting, and should be replaced with an "e.g.".
> 
> Randy
> 
> On 8/11/2016 2:06 AM, William Lupton wrote:
>> All,
>> 
>> The text at the bottom of RFC 6087bis (draft 07) Section 5.8 seems unclear:
>> 
>> "It is acceptable to reuse the same revision statement within unpublished 
>> versions (i.e., Internet-Drafts), but the revision date MUST be updated to a 
>> higher value each time the Internet-Draft is re-posted”
>> 
>> Assuming that the intent is that the revision statements in YANG models 
>> contained within IDs must be updated whenever the models are updated,  
>> wouldn’t it be clearer if the parenthesised text "(i.e., Internet-Drafts)” 
>> was deleted?
>> 
>> Thanks,
>> William
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> 
> ___
> 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] RFC 6087bis guidance re use of revision statements in drafts

[William Lupton]

All,

The text at the bottom of RFC 6087bis (draft 07) Section 5.8 seems unclear:

"It is acceptable to reuse the same revision statement within unpublished 
versions (i.e., Internet-Drafts), but the revision date MUST be updated to a 
higher value each time the Internet-Draft is re-posted”

Assuming that the intent is that the revision statements in YANG models 
contained within IDs must be updated whenever the models are updated,  wouldn’t 
it be clearer if the parenthesised text "(i.e., Internet-Drafts)” was deleted?

Thanks,
William
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[William Lupton]

Sorry, I was talking only about the interface _stack_ configuration. Ref RFC 
7223 Section 3.3:

While the interface layering is configured in interface-type-specific models, 
two generic state data leaf-lists, "higher-layer-if” and "lower-layer-if", 
represent a read-only view of the interface layering hierarchy.

I was just wondering whether configuration of entity relationships might be 
analogous.

> On 1 Aug 2016, at 10:42, Juergen Schoenwaelder 
> <j.schoenwael...@jacobs-university.de> wrote:
> 
> On Mon, Aug 01, 2016 at 10:13:38AM +0100, William Lupton wrote:
>> 
>> There seems to be an analogy with interfaces here. The ietf-interfaces 
>> module provides only a read-only view of the interface stack, and interface 
>> type-specific modules are expected to provide a means of configuring the 
>> stack for interfaces of that type (where necessary).
> 
> This is not correct. The ietf-interfaces modules allows you to
> configure/create interfaces, including interfaces that are not
> currently present.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[William Lupton]

Maybe configuration of the entity tree for pluggable items should be handled 
via augmentations that are specific to pluggable items?

There seems to be an analogy with interfaces here. The ietf-interfaces module 
provides only a read-only view of the interface stack, and interface 
type-specific modules are expected to provide a means of configuring the stack 
for interfaces of that type (where necessary).

William

> On 29 Jul 2016, at 15:04, Bogaert, Bart (Nokia - BE)  
> wrote:
> 
> I would like to bring this to the ietf-entity group.  Currently BBF is 
> proposing to add new RW leafs to the entity object.  This is done in the 
> context of plugable entities and hence it means that when an operator (via a 
> NC client) configures a plugable item it is required to define the entity 
> type.  For this reason additional RW attributes are needed.  Two of the new 
> leafs are class and contained-in (same as the RO class leaf). 
> -  class: we think that the class leaf needs to be mandatory but 
> adding this via an augment is not possible as we can’t add a mandatory leaf 
> via an augment.  Making class implicit for the client based on “some 
> information” exchanged between device vendors and management applications is 
> maybe not such a sound approach.
> -  contained-in: for plugable items contained-in requires to be 
> mandatory too as a plugable item can’t be “floating” in the device.  But we 
> then hit a problem for the ‘top-level’ entity which not contained in anything 
> (and ‘fooling’ the model by having it pointing to itself is not allowed).  
> Contained-in can’t be derived by the NC server: what to do if 2 entities of 
> the same class are preprovisioned (together with ports and interfaces related 
> to subscribers)?  We need to be sure that the subscribers are on the intended 
> ports.
>  
> This would mean that the ietf-entity model would require a revision to add 
> leafs for these plugable items.  What is the best way to address this?
>  
> Best regards - Vriendelijke groeten,
> Bart Bogaert
> Broadband-Access System Architect Data
> Contact number +32 3 2408310 (+32 477 673952)
>  
> NOKIA
> Copernicuslaan 50, 2018 Antwerp, Belgium
> Fortis 220-0002334-42
> VAT BE 0404 621 642 Register of Legal Entities Antwerp
> 
> <<
> This message (including any attachments) contains confidential information 
> intended for a specific individual and purpose, and is protected by law. If 
> you are not the intended recipient, you should delete this message. Any 
> disclosure, copying, or distribution of this message, or the taking of any 
> action based on it, is strictly prohibited without the prior consent of its 
> author.
> >>
>  
> ___
> 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] YANG 1.1: XML naming restriction

[William Lupton]

But the errata at https://www.w3.org/XML/xml-V10-5e-errata 
 say the following. There are also 
related changes to Section 2.6 (processing instructions) and Section 3 (logical 
structures). W.
Section 2.3 Common Syntactic Constructs 

Delete the following paragraph:

Names beginning with the string "xml", or with any string which would match 
(('X'|'x') ('M'|'m') ('L'|'l')), are reserved for standardization in this or 
future versions of this specification.

> On 1 Aug 2016, at 04:22, Andy Bierman  wrote:
> 
> 
> OK -- sorry -- must have read it wrong
> 
> 
> Andy
> 
> 
> 
> On Sun, Jul 31, 2016 at 6:57 PM, Dale R. Worley  > wrote:
> Andy Bierman > writes:
> > The YANG 1.1 ABNF says:
> >
> >;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l'))
> >identifier  = (ALPHA / "_")
> >  *(ALPHA / DIGIT / "_" / "-" / ".")
> >
> >
> > There is no explanation given why.
> > The same restriction was copied to RESTCONF, also without explanation.
> > Supposedly, XML does not allow identifiers to start with XML.
> >
> > Looks like this restriction only applies to the PITarget [17], not Name [5]
> > https://www.w3.org/TR/REC-xml/#sec-pi 
> > 
> >
> > We have been applying this restriction to element names
> > but it only applies to processing instructions.
> >
> > IMO it should be removed.
> > It confuses people when they get an error for naming a data node
> > with a string that matches.
> 
> Eh?  Looking at "Extensible Markup Lanuage (XML) 1.0 (Fifth Edition)",
> section 3.1 (http://www.w3.org/TR/xml/#sec-starttags 
> ) says that the
> element name of a start in end tag is a "Name".  Looking at section 2.3
> (http://www.w3.org/TR/xml/#sec-common-syn 
> ), I see
> 
> Names beginning with the string "xml", or with any string which
> would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for
> standardization in this or future versions of this specification.
> 
> And since Yang data node names can appear as XML element names, Yang has
> to forbid node names that start with "XML".
> 
> Dale
> 
> ___
> 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] Specifying revision date on import/include

[William Lupton]

All,

RFC 6020bis has no recommendation re use of import/include revision-date but 
makes it clear that if it’s omitted then the revision that will be used is 
undefined (I believe that pyang will  parse all the revisions that it finds and 
then use the most recent one). Perhaps that’s a recommendation by implication? 
RFC 6087bis says that the import/include revision-date SHOULD be used when 
groupings from the imported/included module/submodule are used.

In discussing this today with people at the hackathon the general opinion was 
that an omitted revision date means the latest available revision. This matches 
the pyang behaviour and (I gather) matches the behaviour of most 
implementations.

In discussion I also said that I didn’t understand why the only groupings are 
singled out for mention in RFC 6087. Why not types for example?

So should the behaviour when revision-date is omitted be specified? And does 
the recommendation for using revision-date need to be refined?

Thanks,
William

—— some musings 

On the one hand, always referencing a specific revision is good because it 
means that you know exactly what you are getting. But is it always good, 
especially (perhaps) for low-level modules such ietf-yang-types, 
ietf-inet-types and (especially?) iana-if-type? Perhaps it’s better to 
reference low-level files such as these without revision numbers and trusting 
to rigorous backwards compatibility?

RFC 6020bis is (I think) silent on whether a later revision could remove 
import/include revision dates but it’s pretty obvious that you could change 
them to later revisions, so probably this is regarded as “plumbing” that 
doesn’t need to be mentioned?
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Canonical order: linkage and meta

[William Lupton]

Thanks. That’s fine. I was just checking for opinions :). W.

> On 27 Jun 2016, at 12:03, Juergen Schoenwaelder 
> <j.schoenwael...@jacobs-university.de> wrote:
> 
> I think changing the canonical format because some people may miss the
> copyright since they have to scroll down a bit is not really worth the
> pain of having different canonical formats out there. And something
> like
> 
> // please scroll down to see the license
> 
> does seem to sovle the problem.
> 
> /js
> 
> On Mon, Jun 27, 2016 at 11:20:02AM +0100, William Lupton wrote:
>> All,
>> 
>> No-one replied to this. Fair enough, because it probably seems a rather 
>> trivial question! But I wanted to point out that a practical consequence of 
>> the description being a long way down a module is that the license text 
>> could easily be missed (assuming it’s in the top-level description, which is 
>> the usual IETF - and BBF - practice). In one BBF module (lots of includes, 
>> each of which has a revision-date and uses 3 lines), the top-level 
>> description begins at line 149 out of 204.
>> 
>> OK, we could put a comment nearer the top of the file that points the reader 
>> further down the file, or we could move the license text into a comment near 
>> the top of the file. But usual YANG practice (and I like this) seems to be 
>> to prefer to put information into YANG statements rather than into comments.
>> 
>> Thoughts?
>> 
>> Thanks,
>> William
>> 
>>> On 9 Jun 2016, at 12:30, William Lupton <wlup...@broadband-forum.org> wrote:
>>> 
>>> All,
>>> 
>>> RFC 6020bis says “The ABNF grammar [RFC5234] [RFC7405] defines the 
>>> canonical order. To improve module readability, it is RECOMMENDED that 
>>> clauses be entered in this order.”
>>> 
>>> The ABNF places linkage-stmts (import, include) before meta-stmts 
>>> (organization, contact, description, reference) but if there are a lot of 
>>> linkage statements (which will be the case in the main module if there are 
>>> a large number of submodules… as there are for some of the modules that BBF 
>>> is defining) this means that the description can be a fair way down the 
>>> module.
>>> 
>>> Would there be any support for regarding placement of the meta statements 
>>> before the linkage statements as not being a violation of canonical order? 
>>> Note (this might be inadvertent) that the ABNF actually defines 
>>> “meta-stmts” before “linkage-stmts”.
>>> 
>>> Thanks,
>>> William
>> 
>> ___
>> 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 <http://www.jacobs-university.de/>
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Canonical order: linkage and meta

[William Lupton]

All,

No-one replied to this. Fair enough, because it probably seems a rather trivial 
question! But I wanted to point out that a practical consequence of the 
description being a long way down a module is that the license text could 
easily be missed (assuming it’s in the top-level description, which is the 
usual IETF - and BBF - practice). In one BBF module (lots of includes, each of 
which has a revision-date and uses 3 lines), the top-level description begins 
at line 149 out of 204.

OK, we could put a comment nearer the top of the file that points the reader 
further down the file, or we could move the license text into a comment near 
the top of the file. But usual YANG practice (and I like this) seems to be to 
prefer to put information into YANG statements rather than into comments.

Thoughts?

Thanks,
William

> On 9 Jun 2016, at 12:30, William Lupton <wlup...@broadband-forum.org> wrote:
> 
> All,
> 
> RFC 6020bis says “The ABNF grammar [RFC5234] [RFC7405] defines the canonical 
> order. To improve module readability, it is RECOMMENDED that clauses be 
> entered in this order.”
> 
> The ABNF places linkage-stmts (import, include) before meta-stmts 
> (organization, contact, description, reference) but if there are a lot of 
> linkage statements (which will be the case in the main module if there are a 
> large number of submodules… as there are for some of the modules that BBF is 
> defining) this means that the description can be a fair way down the module.
> 
> Would there be any support for regarding placement of the meta statements 
> before the linkage statements as not being a violation of canonical order? 
> Note (this might be inadvertent) that the ABNF actually defines “meta-stmts” 
> before “linkage-stmts”.
> 
> Thanks,
> William

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] bits lexical representation

[William Lupton]

RFC 6020bis Section 9.7.2 is silent on the question of whether bit names can be 
repeated in a bits value, e.g is “uno dos dos tres” valid or invalid? Obviously 
repetition is not to be encouraged but is it forbidden? Maybe this is a case 
where the robustness principle should be applied? Thanks, William.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Canonical order: linkage and meta

[William Lupton]

All,

RFC 6020bis says “The ABNF grammar [RFC5234] [RFC7405] defines the canonical 
order. To improve module readability, it is RECOMMENDED that clauses be entered 
in this order.”

The ABNF places linkage-stmts (import, include) before meta-stmts 
(organization, contact, description, reference) but if there are a lot of 
linkage statements (which will be the case in the main module if there are a 
large number of submodules… as there are for some of the modules that BBF is 
defining) this means that the description can be a fair way down the module.

Would there be any support for regarding placement of the meta statements 
before the linkage statements as not being a violation of canonical order? Note 
(this might be inadvertent) that the ABNF actually defines “meta-stmts” before 
“linkage-stmts”.

Thanks,
William
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Replacing a YANG submodule with a module

[William Lupton]

Martin,

I think that the answer is “yes” but please could you just confirm that the 
alternatives presented here are valid? In the real world I think I would 
usually follow the second approach of retaining the submodule (including its 
groupings) but simply breaking out the definitions of the bodies of its 
groupings into groupings defined in new module(s).

Thanks,
William

> On 8 Jun 2016, at 13:38, William Lupton <wlup...@broadband-forum.org> wrote:
> 
> Thanks. So the following would be valid I assume? Or (better because it 
> doesn’t change the module/submodule interface?) the second option shown below 
> (which simply defines a new module in order to make the grouping externally 
> accessible). Cheers, W.
> 
> % cat t...@2016-06-08.yang <mailto:t...@2016-06-08.yang> 
> module test {
>   namespace "urn:bbf:yang:test";
>   prefix test;
> 
>   import mod {
> prefix mod;
> revision-date 2016-06-08;
>   }
> 
>   revision 2016-06-08 {
>   }
> 
>   grouping util {
> uses mod:util;
>   }
> 
>   uses util;
> }
> 
> Second option:
> 
> % cat t...@2016-06-09.yang <mailto:t...@2016-06-09.yang> 
> sub...@2016-06-09.yang <mailto:sub...@2016-06-09.yang> m...@2016-06-09.yang 
> <mailto:m...@2016-06-09.yang> t...@2016-06-09.tree 
> <mailto:t...@2016-06-09.tree> 
> module test {
>   namespace "urn:bbf:yang:test";
>   prefix test;
> 
>   include submod {
> revision-date 2016-06-09;
>   }
> 
>   revision 2016-06-09 {
>   }
> 
>   uses util;
> }
> submodule submod {
>   belongs-to test {
> prefix test;
>   }
> 
>   import mod {
> prefix mod;
> revision-date 2016-06-09;
>   }
> 
>   revision 2016-06-09 {
>   }
> 
>   grouping util {
> uses mod:util;
>   }
> }
> module mod {
>   namespace "urn:bbf:yang:mod";
>   prefix mod;
> 
>   revision 2016-06-09 {
>   }
> 
>   grouping util {
> container util {
> }
>   }
> }
> module: test
>+--rw util
> 
>> On 8 Jun 2016, at 12:37, Martin Bjorklund <m...@tail-f.com 
>> <mailto:m...@tail-f.com>> wrote:
>> 
>> William Lupton <wlup...@broadband-forum.org 
>> <mailto:wlup...@broadband-forum.org>> wrote:
>>> Hi,
>>> 
>>> Consider the YANG module, submodule and tree files shown
>>> below. Suppose that I regret the decision to make “submod” be a
>>> submodule and want to replace it with a module (see listings further
>>> down). This works, the tree file is identical, and pyang
>>> --check-update-from is happy, but strictly the interface has changed
>>> (the util grouping has moved from the urn:bbf:yang:test namespace to
>>> the urn:bbf:yang:mod namespace).
>> 
>> You have removed the "util" grouping from the module "test".  This is
>> not allowed according to the upgrade rules.
>> 
>> (So yes, this is a bug in pyang --check-update-from; it doesn't work
>> well with this kind of structural change)
>> 
>> 
>> /martin
>> 
>> 
>> 
>>> Is this intended to be valid (I don’t
>>> see it mentioned in RFC 6020bis Section 11)?
>>> 
>>> Thanks,
>>> William
>>> 
>>> % cat t...@2016-01-01.yang <mailto:t...@2016-01-01.yang> 
>>> sub...@2016-01-01.yang <mailto:sub...@2016-01-01.yang> t...@2016-01-01.tree 
>>> <mailto:t...@2016-01-01.tree> 
>>> module test {
>>>  namespace "urn:bbf:yang:test";
>>>  prefix test;
>>> 
>>>  include submod {
>>>revision-date 2016-01-01;
>>>  }
>>> 
>>>  revision 2016-01-01 {
>>>  }
>>> 
>>>  uses util;
>>> }
>>> submodule submod {
>>>  belongs-to test {
>>>prefix test;
>>>  }
>>> 
>>>  revision 2016-01-01 {
>>>  }
>>> 
>>>  grouping util {
>>>container util {
>>>}
>>>  }
>>> }
>>> module: test
>>>   +--rw util
>>> 
>>> Replacements with submod -> mod:
>>> 
>>> % cat t...@2016-06-08.yang <mailto:t...@2016-06-08.yang> 
>>> m...@2016-06-08.yang <mailto:m...@2016-06-08.yang> t...@2016-06-08.tree 
>>> <mailto:t...@2016-06-08.tree> 
>>> module test {
>>>  namespace "urn:bbf:yang:test";
>>>  prefix test;
>>> 
>>>  import mod {
>>>prefix mod;
>>>revision-date 2016-06-08;
>>>  }
>>> 
>>>  revision 2016-06-08 {
>>>  }
>>> 
>>>  uses mod:util;
>>> }
>>> module mod {
>>>  namespace "urn:bbf:yang:mod";
>>>  prefix mod;
>>> 
>>>  revision 2016-06-08 {
>>>  }
>>> 
>>>  grouping util {
>>>container util {
>>>}
>>>  }
>>> }
>>> module: test
>>>   +--rw util
>>> 
>>> pyang is happy:
>>> 
>>> % pyang --check-update-from=t...@2016-01-01.yang 
>>> <mailto:check-update-from=t...@2016-01-01.yang> t...@2016-06-08.yang 
>>> <mailto:t...@2016-06-08.yang>
> 
> ___
> 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] Replacing a YANG submodule with a module

[William Lupton]

Thanks. So the following would be valid I assume? Or (better because it doesn’t 
change the module/submodule interface?) the second option shown below (which 
simply defines a new module in order to make the grouping externally 
accessible). Cheers, W.

% cat t...@2016-06-08.yang 
module test {
  namespace "urn:bbf:yang:test";
  prefix test;

  import mod {
prefix mod;
revision-date 2016-06-08;
  }

  revision 2016-06-08 {
  }

  grouping util {
uses mod:util;
  }

  uses util;
}

Second option:

% cat t...@2016-06-09.yang sub...@2016-06-09.yang m...@2016-06-09.yang 
t...@2016-06-09.tree 
module test {
  namespace "urn:bbf:yang:test";
  prefix test;

  include submod {
revision-date 2016-06-09;
  }

  revision 2016-06-09 {
  }

  uses util;
}
submodule submod {
  belongs-to test {
prefix test;
  }

  import mod {
prefix mod;
revision-date 2016-06-09;
  }

  revision 2016-06-09 {
  }

  grouping util {
uses mod:util;
  }
}
module mod {
  namespace "urn:bbf:yang:mod";
  prefix mod;

  revision 2016-06-09 {
  }

  grouping util {
container util {
}
  }
}
module: test
   +--rw util

> On 8 Jun 2016, at 12:37, Martin Bjorklund <m...@tail-f.com> wrote:
> 
> William Lupton <wlup...@broadband-forum.org> wrote:
>> Hi,
>> 
>> Consider the YANG module, submodule and tree files shown
>> below. Suppose that I regret the decision to make “submod” be a
>> submodule and want to replace it with a module (see listings further
>> down). This works, the tree file is identical, and pyang
>> --check-update-from is happy, but strictly the interface has changed
>> (the util grouping has moved from the urn:bbf:yang:test namespace to
>> the urn:bbf:yang:mod namespace).
> 
> You have removed the "util" grouping from the module "test".  This is
> not allowed according to the upgrade rules.
> 
> (So yes, this is a bug in pyang --check-update-from; it doesn't work
> well with this kind of structural change)
> 
> 
> /martin
> 
> 
> 
>> Is this intended to be valid (I don’t
>> see it mentioned in RFC 6020bis Section 11)?
>> 
>> Thanks,
>> William
>> 
>> % cat t...@2016-01-01.yang sub...@2016-01-01.yang t...@2016-01-01.tree 
>> module test {
>>  namespace "urn:bbf:yang:test";
>>  prefix test;
>> 
>>  include submod {
>>revision-date 2016-01-01;
>>  }
>> 
>>  revision 2016-01-01 {
>>  }
>> 
>>  uses util;
>> }
>> submodule submod {
>>  belongs-to test {
>>prefix test;
>>  }
>> 
>>  revision 2016-01-01 {
>>  }
>> 
>>  grouping util {
>>container util {
>>}
>>  }
>> }
>> module: test
>>   +--rw util
>> 
>> Replacements with submod -> mod:
>> 
>> % cat t...@2016-06-08.yang m...@2016-06-08.yang t...@2016-06-08.tree 
>> module test {
>>  namespace "urn:bbf:yang:test";
>>  prefix test;
>> 
>>  import mod {
>>prefix mod;
>>revision-date 2016-06-08;
>>  }
>> 
>>  revision 2016-06-08 {
>>  }
>> 
>>  uses mod:util;
>> }
>> module mod {
>>  namespace "urn:bbf:yang:mod";
>>  prefix mod;
>> 
>>  revision 2016-06-08 {
>>  }
>> 
>>  grouping util {
>>container util {
>>}
>>  }
>> }
>> module: test
>>   +--rw util
>> 
>> pyang is happy:
>> 
>> % pyang --check-update-from=t...@2016-01-01.yang t...@2016-06-08.yang

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] string in when and must statement in YANG ABNF Grammar

[William Lupton]

It might also be worth noting (see 
https://github.com/mbj4668/pyang/wiki/InstanceValidation) that "DSDL schemas 
can be used with generic off-the-shelf XML tools for both syntactic and 
semantic validation of XML instance documents”. This includes validating “must” 
statements and so on. William.

> On 29 Mar 2016, at 08:22, Martin Bjorklund  wrote:
> 
> "Bogaert, Bart (Nokia - BE)"  wrote:
>> Is there a reason why the ABNF for example the when and must statement has
>> been "restricted" to when-keyword sep string optsep 
>> 
>> As "string"  can't be tokenized no errors are generated by YANG compilers if
>> this string contains an error, e.g. referred leaf does not exit due to a
>> typo.  This problem only exposes itself at run-time.  I was wondering why
>> this string was not broken down into a number of specific parts that define
>> the when statement so that these kind of errors can be trapped early in the
>> development process?   I am rather new in this so I did not follow all
>> discussions that led to the definition of YANG and hence have no idea
>> whether this was discussed and what were the reasons not to do it this way.
> 
> The arguments to the "when" and "must" statements are XPath 1.0
> expressions.  The syntax of XPath 1.0 is not defined by YANG, but by
> the XPath 1.0 spec.  This is the reason that the YANG grammar isn't
> more specific.
> 
> YANG compilers differ in their ability to detect errors in these XPath
> expressions.  Some perform more checks than others (unfortunately,
> pyang is pretty bad in this regard... (patches are always welcome:)).
> 
> [For your particular example, referencing a leaf that doesn't exist is
> not an error per se; it is perfectly valid XPath.  But it probably
> warrants a warning by the compiler.]
> 
> /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

[netmod] Broadband Forum questions about announcing capabilities

[William Lupton]

All,

BBF has a question about how to announce capabilities. This is illustrated by a 
specific example but it’s a general question. There is some overlap with past 
“Broadband Forum questions on RFC 6087bis 
” and 
“Restricting interface name maximum length and character set 
” 
threads.

Here’s the example. We have a list of profiles and we want the server to be 
able to indicate the maximum number of supported profiles. The two ways that we 
have considered doing this are:
Add a leaf that indicates the maximum number of supported profiles.
Use a deviation to indicate max-elements on the profile list.

We have got the impression from the RFCs and past discussion (cited above) that 
NETMOD’s preferred approach is the first one, and you would not approve of the 
second one. Is that correct? Any other thoughts?

Note that use of deviations in this way is not contravening RFC 6020bis’s 
“deviations MUST never be part of a published standard” because our published 
YANG will not include deviations. We would be using them only in the sense that 
they would be the recommended way for an implementation to announce its 
capabilities. Strictly (in the example given above) this is a deviation from 
the standard because an unspecified max-elements statement defaults to 
“unbounded”.

Thanks,
William Lupton___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Restricting interface name maximum length and character set

[William Lupton]

Thanks for the reply. No other BBF specs (that I am aware of) require such 
restrictions. I (personally) think that handling this as a device requirement 
is a fine solution, but we wanted to check what people thought of trying to 
define such restrictions in the YANG.

BTW, we were thinking of: maximum length (64) and restricted character set 
(ASCII 32-126).

William

> On 11 Feb 2016, at 13:55, Juergen Schoenwaelder 
> <j.schoenwael...@jacobs-university.de> wrote:
> 
> On Thu, Feb 11, 2016 at 12:22:19PM +0000, William Lupton wrote:
>> All,
>> 
>> Here in the Broadband Forum we are defining YANG modules that augment RFC 
>> 7223 ietf-interfaces. We want to limit interface name maximum length and 
>> character set but don't see a way of doing this in the YANG.
>> 
>> Can/should we do do this in the YANG, or should it just be a device-level 
>> requirement?
>> 
> 
> I wonder why you want to do this. Is it because other existing BBF
> specifications break if interfaces can have long names and use Unicode
> characters? Out of curiosity, what would be the length and character
> set restriction BBF finds a good choice?
> 
> A deviation statement describes how an implementation deviates from a
> data model. It was not the intent that an SDO defines a 'standard'
> deviation for a data model (the term 'profile' might be more
> appropriate for this).
> 
> Note that these kind of 'profiles' often do not combine well. If BBF
> says the max length is N and MEF says that max length is N with N !=
> M, then an implementor has a hard time to produce a device that
> satisfies both requirements. (All one can do is to use min(N,M) and
> then annouce a deviation to the profiles affected, all getting pretty
> ugly soon, in particular if the common native interface names may be
> longer than N and M.)
> 
> I understand that 'arbitrarily long' may sound ridiculous. But having
> an implementation announce its real limit instead of a data model or
> 'profile' imposed limit seems simpler and more robust to me.
> 
> /js
> 
> PS: On Windows, MAX_ADAPTER_NAME_LENGTH seems to be 256, on Linux
>IF_NAMESIZE seems to be 16, on FreeBSD and MacOS IF_NAMESIZE seems
>to be 16 as well (but there are likely systems derived from
>FreeBSD that use a different constant, may also be true for Linux
>- and most likely people change this constant for a reason).
> 
> -- 
> 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/>
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Restricting interface name maximum length and character set

[William Lupton]

All,

Here in the Broadband Forum we are defining YANG modules that augment RFC 7223 
ietf-interfaces. We want to limit interface name maximum length and character 
set but don't see a way of doing this in the YANG.

Can/should we do do this in the YANG, or should it just be a device-level 
requirement?

Thanks,
William

 notes 

We considered the "arbitrary-names" feature but reckoned that this applies only 
to user-controlled interfaces and therefore doesn't apply here.

We considered requiring use of a "deviate" statement to state device support 
for shorter maximum length (64) and restricted character set (ASCII 32-126) but 
we don't expect NETMOD to approve of this.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Validation question

[William Lupton]

Lada,

Thanks for drawing my attention to this section. I hadn't noticed this advice.

Perhaps corresponding things need to be said about the XML?
Always use a prefix on identity values, even if the default namespace (YANG 
module) is the module that defined the identity.
When importing a namespace (YANG module) that contains identities that are 
referenced in the XML, always use the same prefix that was used within the 
imported module.

The need for the first of the above XML-related statements wasn't illustrated 
by the YANG and XML in my first message but it's illustrated by the fragments 
shown below.

I guess the point about derived-from() and derived-from-or-self() is that, 
although they still specify the identities as strings, the strings are known to 
be identities, so prefixes can be processed (applying defaults etc)?

Finally, I think perhaps this is a separate point (because not related to 
string values), but seems to be necessary to use the same prefixes for imported 
modules as were used within those modules. For example, if (in my example) I 
change the ietf-interfaces prefix from if to ifx, validation fails with an 
"undefined namespace prefix" error.

Cheers,
William

YANG fragment:
  identity sub-type;

  identity sub-type-a {
base sub-type;
  }

  augment "/if:interfaces/if:interface" {
when "if:type = 'mymod:some-new-iftype'";

container some-new-container {
  leaf sub-type {
type identityref {
  base sub-type;
}
  }
  container sub-container {
when "../mymod:sub-type = 'mymod:sub-type-a'";
  }
}
  }

XML fragment (mymod prefix is necessary in order for XML to validate):
  http://example.com/augment;>
mymod:sub-type-a

  

> On 22 Jan 2016, at 09:32, Ladislav Lhotka <lho...@nic.cz> wrote:
> 
> Hi William,
> 
> YANG uses XPath 1.0, and so the equality tests mean *string
> equality*. That's why 6087bis recommends in sec. 5.6.4:
> 
>   XPath expressions that contain a literal value representing a YANG
>   identity SHOULD always include the declared prefix of the module
>   where the identity is defined.
> 
> In YANG 1.1, the new XPath functions derived-from() and
> derived-from-or-self() will alleviate this problem.
> 
> Lada
> 
> William Lupton <wlup...@broadband-forum.org> writes:
> 
>> All,
>> 
>> We have been experimenting with validating XML instances along the lines 
>> explained in the tutorials at 
>> http://www.yang-central.org/twiki/bin/view/Main/DSDLMappingTutorial 
>> <http://www.yang-central.org/twiki/bin/view/Main/DSDLMappingTutorial> and 
>> https://github.com/mbj4668/pyang/wiki/InstanceValidation 
>> <https://github.com/mbj4668/pyang/wiki/InstanceValidation> and we have hit a 
>> problem with identities in XPath expressions.
>> 
>> This is illustrated by the YANG module shown below, which is inspired by an 
>> example in RFC 6020bis, and the XML instance shown below the YANG. Note that:
>> The second "when" statement doesn't use a prefix on the interface type.
>> Shouldn't be a problem because the interface type is defined in the current 
>> module and so doesn't need a prefix?
>> The XML uses a prefix name of "exaug" rather than "mymod" which is used in 
>> the YANG.
>> Shouldn't be a problem because prefixes should be local?
>> 
>> Validating this instance gives the following two errors (which go away if 
>> the prefix "mymod" is used in all "when" statements and in the XML).
>> 
>> == Validating semantic constraints ...
>> --- Validity error at "/nc:data/if:interfaces/if:interface":
>>Found nodes that are valid only when "if:type = 'mymod:some-new-iftype'"
>> --- Validity error at "/nc:data/if:interfaces-state/if:interface":
>>Found nodes that are valid only when "if:type = 'some-new-iftype'"
>> 
>> Are we doing something wrong here, or is there a problem with how identities 
>> in XPath expressions are translated (per RFC 6110)? On the face of it it 
>> seems that identities are being treated as literal strings (but we haven't 
>> investigated this assertion).
>> 
>> Thanks,
>> William Lupton
>> 
>> 
>> 
>> YANG:
>> module example-augment {
>>  namespace "http://example.com/augment;;
>>  prefix mymod;
>> 
>>  import ietf-interfaces {
>>prefix if;
>>  }
>> 
>>  identity some-new-iftype {
>>base if:interface-type;
>>  }
>> 
>>  augment "/if:interfaces/if:interface" {
>>when "if:type = 'mymod:some-new-iftyp

[netmod] Validation question

[William Lupton]

All,

We have been experimenting with validating XML instances along the lines 
explained in the tutorials at 
http://www.yang-central.org/twiki/bin/view/Main/DSDLMappingTutorial 
<http://www.yang-central.org/twiki/bin/view/Main/DSDLMappingTutorial> and 
https://github.com/mbj4668/pyang/wiki/InstanceValidation 
<https://github.com/mbj4668/pyang/wiki/InstanceValidation> and we have hit a 
problem with identities in XPath expressions.

This is illustrated by the YANG module shown below, which is inspired by an 
example in RFC 6020bis, and the XML instance shown below the YANG. Note that:
The second "when" statement doesn't use a prefix on the interface type.
Shouldn't be a problem because the interface type is defined in the current 
module and so doesn't need a prefix?
The XML uses a prefix name of "exaug" rather than "mymod" which is used in the 
YANG.
Shouldn't be a problem because prefixes should be local?

Validating this instance gives the following two errors (which go away if the 
prefix "mymod" is used in all "when" statements and in the XML).

== Validating semantic constraints ...
--- Validity error at "/nc:data/if:interfaces/if:interface":
Found nodes that are valid only when "if:type = 'mymod:some-new-iftype'"
--- Validity error at "/nc:data/if:interfaces-state/if:interface":
Found nodes that are valid only when "if:type = 'some-new-iftype'"

Are we doing something wrong here, or is there a problem with how identities in 
XPath expressions are translated (per RFC 6110)? On the face of it it seems 
that identities are being treated as literal strings (but we haven't 
investigated this assertion).

Thanks,
William Lupton



YANG:
module example-augment {
  namespace "http://example.com/augment;;
  prefix mymod;
  
  import ietf-interfaces {
prefix if;
  }
  
  identity some-new-iftype {
base if:interface-type;
  }
  
  augment "/if:interfaces/if:interface" {
when "if:type = 'mymod:some-new-iftype'";

container some-new-container {
}
  }

  augment "/if:interfaces-state/if:interface" {
when "if:type = 'some-new-iftype'";

container some-new-container {
}
  }
}

XML:

http://example.com/augment;>
  

  
  
  exaug:some-new-iftype
  true
  enabled
  http://example.com/augment;>
  

  
  

  
  exaug:some-new-iftype
  up
  up
  1
  
2016-01-15T12:55:00Z
  
  http://example.com/augment;>
  

  



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Broadband Forum questions on RFC 6087bis

[William Lupton]

All,

I didn't see any follow-up to these questions / comments. Any thoughts? 

Thanks,
William

> On 11 Dec 2015, at 12:54, William Lupton <wlup...@broadband-forum.org> wrote:
> 
> All,
> 
> Here are some questions / comments from the Broadband Forum on RFC 6087bis-05.
> 
> Thanks,
> William
> 
> 
> 
> 1. Potentially confusing use of the term "prefix"
> 
> Section 5.1 (Module Naming Conventions) talks about prefixes but in this 
> context means "strings at the beginning of module names" rather than YANG 
> prefixes that are the topic of Section 5.2. This could (and did!) cause 
> confusion.
> 
> 
> 2. Rules re changing submodule names
> 
> Section 5.7 (Lifecycle Management) says that "The [...] submodule name MUST 
> NOT be changed, once the document containing the module or submodule is 
> published" but this might contradict RFC 6020 Section 11, which says "A 
> module may be split into a set of submodules, or a submodule may be 
> removed...".
> 
> More specifically, 6020 doesn't mention renaming a submodule (so presumably 
> that's not permitted), but the mention of both splitting modules into 
> submodules AND removing submodules suggests that arbitrary module/submodule 
> refactoring is permitted. And if I'm being pedantic, revision #1 could have 
> submodule A1, revision #2 could remove it, and revision #3 could reintroduce 
> it as submodule A2, so that's effectively a rename!
> 
> 
> 3. References to RPCs need also to mention actions
> 
> In most (or all?) places that RPCs are mentioned, presumably actions need to 
> be mentioned?
> 
> 
> 4. Implications of adding defaults
> 
> Section 5.12 (Reusable Type Definitions) says that "If an appropriate default 
> value can be associated with the desired semantics, then a default statement 
> SHOULD be present". Is it correct that adding a default effectively adds a 
> MANDATORY requirement for a server to support the default value for that 
> node, and therefore to support the concept modelled by the node (albeit only 
> with the default behaviour)? Whereas if there were no default then there 
> would be no requirement at all to support the concept modelled by that node? 
> If so, then adding a default seems like something that shouldn't be done 
> lightly... or am I making too much of this?
> 
> 
> 5. Guidance re YANG features
> 
> 6087 doesn't always refer to features consistently. For example Section 5.5 
> (Conditional Statements) says "If a data definition is optional, depending on 
> server support for a NETCONF protocol capability, then a YANG 'feature' 
> statement SHOULD be defined" (which seems to tie the "feature" concept to 
> NETCONF protocol capabilities), whereas Section 5.17 (Feature Definitions) 
> says "The YANG "feature" statement is used to define a label for a set of 
> optional functionality within a module". The latter description seems more in 
> keeping with the spirit of 6020, so perhaps the former text could be adjusted 
> to align with it?
> 
> 
> 6. Guidance re YANG deviations
> 
> The 6020 discussion of deviations is mostly about implementing LESS rather 
> than MORE. Obviously the deviate statement's "add" argument is described (and 
> there is an example) but there seems to be no discussion that use of deviate 
> with "add" might be a GOOD thing.
> 
> The 6087 discussion of deviations says that they can be useful for 
> documenting server capabilities but again the emphasis seems to be on 
> documenting implementing LESS rather than MORE.
> 
> The result seems to be that deviations have a bad name. If indeed there are 
> accepted good uses of deviations then it would be good if this was made 
> clearer, both in 6020 and in 6087.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] derived-from() and derived-from-or-self() arguments

[William Lupton]

Thanks all.

> On 11 Dec 2015, at 09:50, Jernej Tuljak  wrote:
> 
> Ladislav Lhotka je 11.12.2015 ob 9:55 napisal:
>> 
>> A code that evaluating these functions needs to know a lot about the 
>> underlying YANG data model anyway, so I think it is no problem to resolve 
>> arbitrary QNames. I am thus in favour of William's proposal.

I like the idea of just thinking of it as a QName. This also suggests a general 
principle that any future functions that needed to refer to types, identities 
etc would use QNames?

> If there are no existing functions that take a prefixed string literal, why 
> not simply replace the module name argument with a prefix string? I don't see 
> why a module name needs to be used here at all either - in fact, it seems to 
> be promoting the idea of breaking out of module containment using XPath 
> instead of discouraging it - you should not be able to refer to an identity 
> if it is not defined within an imported or the enclosing module.

I assume that "module name" always meant "prefix" because otherwise how would 
one deal with namespaces and revisions? Using a QName clarifies that it's a 
prefix.

William
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Broadband Forum questions on RFC 6087bis

[William Lupton]

All,

Here are some questions / comments from the Broadband Forum on RFC 6087bis-05.

Thanks,
William



1. Potentially confusing use of the term "prefix"

Section 5.1 (Module Naming Conventions) talks about prefixes but in this 
context means "strings at the beginning of module names" rather than YANG 
prefixes that are the topic of Section 5.2. This could (and did!) cause 
confusion.


2. Rules re changing submodule names

Section 5.7 (Lifecycle Management) says that "The [...] submodule name MUST NOT 
be changed, once the document containing the module or submodule is published" 
but this might contradict RFC 6020 Section 11, which says "A module may be 
split into a set of submodules, or a submodule may be removed...".

More specifically, 6020 doesn't mention renaming a submodule (so presumably 
that's not permitted), but the mention of both splitting modules into 
submodules AND removing submodules suggests that arbitrary module/submodule 
refactoring is permitted. And if I'm being pedantic, revision #1 could have 
submodule A1, revision #2 could remove it, and revision #3 could reintroduce it 
as submodule A2, so that's effectively a rename!


3. References to RPCs need also to mention actions

In most (or all?) places that RPCs are mentioned, presumably actions need to be 
mentioned?


4. Implications of adding defaults

Section 5.12 (Reusable Type Definitions) says that "If an appropriate default 
value can be associated with the desired semantics, then a default statement 
SHOULD be present". Is it correct that adding a default effectively adds a 
MANDATORY requirement for a server to support the default value for that node, 
and therefore to support the concept modelled by the node (albeit only with the 
default behaviour)? Whereas if there were no default then there would be no 
requirement at all to support the concept modelled by that node? If so, then 
adding a default seems like something that shouldn't be done lightly... or am I 
making too much of this?


5. Guidance re YANG features

6087 doesn't always refer to features consistently. For example Section 5.5 
(Conditional Statements) says "If a data definition is optional, depending on 
server support for a NETCONF protocol capability, then a YANG 'feature' 
statement SHOULD be defined" (which seems to tie the "feature" concept to 
NETCONF protocol capabilities), whereas Section 5.17 (Feature Definitions) says 
"The YANG "feature" statement is used to define a label for a set of optional 
functionality within a module". The latter description seems more in keeping 
with the spirit of 6020, so perhaps the former text could be adjusted to align 
with it?


6. Guidance re YANG deviations

The 6020 discussion of deviations is mostly about implementing LESS rather than 
MORE. Obviously the deviate statement's "add" argument is described (and there 
is an example) but there seems to be no discussion that use of deviate with 
"add" might be a GOOD thing.

The 6087 discussion of deviations says that they can be useful for documenting 
server capabilities but again the emphasis seems to be on documenting 
implementing LESS rather than MORE.

The result seems to be that deviations have a bad name. If indeed there are 
accepted good uses of deviations then it would be good if this was made 
clearer, both in 6020 and in 6087.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Broadband Forum questions on RFC 6020bis

[William Lupton]

Thanks for the clarifications. A few follow-ups below. Cheers, W.

>> a. Extending a "when" statement so it is true for a wider set of
>> conditions (example: realising that an RFC 7223 interface object
>> applies to additional interface types).
> 
> This is allowed by:
> 
>  o  A "when" statement may be removed or its constraint relaxed.

OK. I see this for "must" but not for "when"; in 08 I can find only one 
instance of "relax".

>> c. Converting a leaf node to a choice (with no change to default
>> behaviour).
> 
> This is not allowed, but maybe it should.  I.e., it should be ok to
> wrap a node that is not a mandatory node (see terminology) in a choice
> (+ case).

OK. Maybe this already happened but perhaps it would be worth checking whether 
there are any other cases that could/should be included (given that the list is 
exhaustive)?

> A container cannot be mandatory.

OK! I should have phrased it more loosely. But you answered the basic question, 
which was whether listing the submodules is REQUIRED. Yes it is.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Broadband Forum intention of using ietf-entity YANG module

[William Lupton]

All,

The Broadband Forum would like to use the ietf-entity YANG module (currently 
draft-entitydt-netmod-entity) for equipment management but we are a bit 
concerned about its draft status and its dependence on YANG 1.1. Any advice or 
reassurance?

Thanks,
William
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] derived-from() and derived-from-or-self() arguments

[William Lupton]

Martin,

Thanks for the reply and sorry for my delay in following up. Maybe I'm 
misunderstanding your point, but surely any node-set argument can be a prefixed 
string, e.g I found this example in a NETMOD "Y26 again, sorry" thread.

  augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" {
when "derived-from-or-self(../dnsz:type,'iana-dns-parameters',"
   + "'TLSA')";

Arguably YANG authors might find it more natural always to use prefixed strings 
such as 'iana-dns-parameters:TLSA' when referring to a namespace-qualified 
entity?

William

PS, The current definitions perhaps need to be tightened up wrt module-name 
(MUST be valid prefix) and identity-name (MUST NOT be qualified)?

> On 16 Nov 2015, at 19:51, Martin Bjorklund <m...@tail-f.com> wrote:
> 
> Hi,
> 
> William Lupton <w...@cantab.net> wrote:
>> Hi,
>> 
>> I'm sure there's an obvious reason for this, but could someone explain why
>> these functions need a separate module-name argument rather than just using
>> that module's prefix on the identity-name argument?
> 
> The only reason is that there are no existing functions that take a
> prefixed string as an argument.  I think it would be possible to
> change these functions to take just two arguments, but I am not sure
> it is worth it?
> 
> /martin
> 
>> For example, I saw derived-from(x, "ex-module", "foo") in a recent message
>> but (assuming that "ex" is the prefix for "ex-module") will this always be
>> the same as derived-from(x, "ex:foo")?
>> 
>> Thanks,
>> William

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Modelling ports that can support multiple physical layer standards

[William Lupton]

All,

We would much appreciate comments and suggestions on the question posed below.

Thanks,
William Lupton
(Software Architect, Broadband Forum)



In the Broadband Forum we need to model a port that can support several 
physical layer standards, but only one at a time. An initial handshake 
mechanism determines which of these standards will actually be used. We have 
been trying to decide how best to model this according to the letter and spirit 
of RFCs 6020, 6087, 7223 etc.

Consider a port, a handshake mechanism "color-selector" and two physical layer 
standards "green" and "red". Each of these is modelled via a YANG module of the 
same name ("port" probably uses the ietf-entity module). Here are the 
approaches that we have considered:

 Option 1 "direct augment" 

color-selector, green and red all directly augment /if:interfaces/if:interface. 
An instance of each of them is associated with the port. See part of the tree 
here (YANG on request).

module: ietf-interfaces
   +--rw interfaces
   |  +--rw interface* [name]
   | +--rw namestring
   | +--rw description?string
   | +--rw typeidentityref
   | +--rw enabled?boolean
   | +--rw link-up-down-trap-enable?   enumeration {if-mib}?
   | +--rw color-sel:line
   | +--rw green:line
   | +--rw red:line

Note that this means that each port needs three separate interface objects. For 
each additional possible supported physical layer standard, an additional 
interface object would be needed.

 Option 2 "indirect augment" 

An additional if-multicolor module directly augments 
/if:interfaces/if:interface. An instance of if-multicolor is associated with 
the port. if-multicolor has a supported-type leaf-list that indicates the 
physical layer standards that are supported by the port (green and red in this 
case). color-selector, green and red are similar to before but this time they 
augment /if:interfaces/if:interface/multi:line, and the green and red "when" 
(existence) criteria are tied to if-multicolor's supported-type leaf-list 
rather than to their own type leaf. See part of the tree here (YANG on request).

module: ietf-interfaces
   +--rw interfaces
   |  +--rw interface* [name]
   | +--rw namestring
   | +--rw description?string
   | +--rw typeidentityref
   | +--rw enabled?boolean
   | +--rw link-up-down-trap-enable?   enumeration {if-mib}?
   | +--rw multi:line
   |+--rw multi:supported-type*   identityref
   |+--rw color-sel:line
   |+--rw green:line
   |+--rw red:line

The nice thing about this approach is that it models the port in a way that is 
close to how it actually _is_. Each port needs only a single interface that's 
directly associated with the handshake mechanism and the supported physical 
layer standards.

A possible disadvantage of this approach is that it is a bit less well aligned 
with RFC 7223, e.g there is only one interface-level enable/disable that has to 
be "shared" by color-selector, green and red.___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Modelling ports that can support multiple physical layer standards

[William Lupton]

Rob, Thanks! Please see inline. Cheers, William.

> On 11 Nov 2015, at 10:49, Robert Wilton <rwil...@cisco.com> wrote:
> 
> Hi William,
> 
> I'm not that familiar with Broadband physical layer standards, but I have an 
> interest in figuring out some of the physical layer and interface layer 
> relationships in YANG.
> 
> There are a couple of things that are not clear to me from your email, so I 
> have two questions:
> 
> 1) Am I right to presume that the "type" of the port is fixed, and can't be 
> changed by the handshake mechanism?

I'd say "no" in the sense that the port is initially a color-selector port, and 
then (after the colour selection) will be either a green port or a red port. 
These are all types (interface types).

> 2) I don't quite understand your last sentence regarding only one 
> interface-level enable/disable leaf.  I would have thought that this would be 
> a benefit.  Please can you elaborate.

In the second case (indirect augment), a single multi:line interface is 
associated with the port, so the standard "enabled" leaf node (administrative 
enable/disable) will apply to the the multi:line interface. This means that 
there is no way (should you wish it) to individually disable green or red. This 
would require addition of such controls at the green and red level.

> There is possibly a third way to model this, which is to have an augmentation 
> of a choice statement, i.e.:
> 1. Your base model would define a choice statement representing the 
> physical-layer 'color'.
> 2. Each physical layer 'color' would be a separate augmentation of the choice 
> statement.
> 
> Using this design ensures that the model can only ever have a single 
> physical-layer at a given time, and yet still makes it clear which 
> physical-layer is in use and also allows for different configuration nodes 
> for each color.
> 
> I've used this structure for modelling layer 2 encapsulation in the IDs that 
> I've put forward:
> E.g. see "choice encaps-type" in draft-wilton-netmod-intf-ext-yang-01 for the 
> base model, and two instances of 
> 'augment 
> "/if:interfaces/if:interface/if-cmn:encapsulation/if-cmn:encaps-type"'
> in draft-wilton-netmod-intf-vlan-yang-01 for two example augmentation cover a 
> basic VLAN layer 2 encapsulation, and a more flexible layer 2 encapsulation.  
> Other layer 2 encapsulations could also be defined for PPP, cHDLC, FR, ATM, 
> etc in separate drafts.
> 
> Perhaps this choice + augmentation design would also work well in your case?

Thanks! I'll take a look at those drafts. Would this approach allow green and 
red config to exist simultaneously on an interface? I think we'd want to be 
able to do that. Perhaps the choice approach might be used only in the state 
tree?

> Thanks,
> Rob
> 
> On 11/11/2015 09:28, William Lupton wrote:
>> All,
>> 
>> We would much appreciate comments and suggestions on the question posed 
>> below.
>> 
>> Thanks,
>> William Lupton
>> (Software Architect, Broadband Forum)
>> 
>> 
>> 
>> In the Broadband Forum we need to model a port that can support several 
>> physical layer standards, but only one at a time. An initial handshake 
>> mechanism determines which of these standards will actually be used. We have 
>> been trying to decide how best to model this according to the letter and 
>> spirit of RFCs 6020, 6087, 7223 etc.
>> 
>> Consider a port, a handshake mechanism "color-selector" and two physical 
>> layer standards "green" and "red". Each of these is modelled via a YANG 
>> module of the same name ("port" probably uses the ietf-entity module). Here 
>> are the approaches that we have considered:
>> 
>>  Option 1 "direct augment" 
>> 
>> color-selector, green and red all directly augment 
>> /if:interfaces/if:interface. An instance of each of them is associated with 
>> the port. See part of the tree here (YANG on request).
>> 
>> module: ietf-interfaces
>>+--rw interfaces
>>|  +--rw interface* [name]
>>| +--rw namestring
>>| +--rw description?string
>>| +--rw typeidentityref
>>| +--rw enabled?boolean
>>| +--rw link-up-down-trap-enable?   enumeration {if-mib}?
>>| +--rw color-sel:line
>>| +--rw green:line
>>| +--rw red:line
>> 
>> Note that this means that each port needs three separate interface objects. 
>> For each additional possible supported physical layer standard, an

[netmod] derived-from() and derived-from-or-self() arguments

[William Lupton]

Hi,

I'm sure there's an obvious reason for this, but could someone explain why
these functions need a separate module-name argument rather than just using
that module's prefix on the identity-name argument?

For example, I saw derived-from(x, "ex-module", "foo") in a recent message
but (assuming that "ex" is the prefix for "ex-module") will this always be
the same as derived-from(x, "ex:foo")?

Thanks,
William
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] not a non-presence container

[William Lupton]

I like that approach. Thanks, W.

On 15 October 2015 at 16:50, Jonathan Hansford <jonat...@hansfords.net>
wrote:

> How about “closest ancestor node in the schema tree (excluding
> non-presence containers)”?
>
>
>
> Jonathan
>
>
>
>
>
>
> *From: *Martin Bjorklund
> *Sent: *15 October 2015 13:39
> *To: *jonat...@hansfords.net
> *Cc: *w...@cantab.net;netmod@ietf.org
>
> *Subject: *Re: [netmod] not a non-presence container
>
>
>
>
>
> Jonathan Hansford <jonat...@hansfords.net> wrote:
>
> > If that misinterpretation has already happened for (at least) one
>
> > individual, would it be worth adding the clarification and remove the
>
> > ambiguity?
>
>
>
> Sure.  The words "not a non-presence container" occurs a couple of
>
> times throughout the document.
>
>
>
> Would it be correct to write "not a non-presence-container"?
>
>
>
>
>
> /martin
>
>
>
>
>
>
>
> >
>
> > Jonathan
>
> >
>
> >
>
> >
>
> > From: William Lupton
>
> > Sent: 14 October 2015 23:28
>
> > To: Martin Bjorklund
>
> > Cc: netmod@ietf.org
>
> > Subject: Re: [netmod] not a non-presence container
>
> >
>
> >
>
> > Thanks. I see now. As you will have realised, I parsed "not a
>
> > non-presence container" as "(not a non-presence) container" (WRONG)
>
> > rather than "not a (non-presence container)" (RIGHT). Cheers, W.
>
> >
>
> > On 14 October 2015 at 20:41, Martin Bjorklund <m...@tail-f.com> wrote:
>
> > William Lupton <w...@cantab.net> wrote:
>
> > > All,
>
> > >
>
> > > Both RFC 6020 and the bis draft use the term "not a non-presence
>
> > > container", sometimes with a reference to section 7.5.1.
>
> > >
>
> > > Does this term mean the same as "presence container"?
>
> >
>
> > No.  A list (for example) is not a non-presence container.
>
> >
>
> > > If so, I think it
>
> > > would be easier (on the reader!) to say that instead. If not, I think
>
> > > that
>
> > > the term warrants a mention in section 7.5.1.
>
> >
>
> > The term is "non-presence container", and it is explained in 7.5.1.
>
> >
>
> >
>
> > /martin
>
> >
>
> >
>
> >
>
>
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] not a non-presence container

[William Lupton]

All,

Both RFC 6020 and the bis draft use the term "not a non-presence
container", sometimes with a reference to section 7.5.1.

Does this term mean the same as "presence container"? If so, I think it
would be easier (on the reader!) to say that instead. If not, I think that
the term warrants a mention in section 7.5.1.

Comments?

Thanks,
William Lupton
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod