[netmod] BCP 216, RFC 8407 on Guidelines for Authors and Reviewers of Documents Containing YANG Data Models

[rfc-editor]

A new Request for Comments is now available in online RFC libraries.

BCP 216
RFC 8407

Title:  Guidelines for Authors and Reviewers 
of Documents Containing YANG Data Models 
Author: A. Bierman
Status: Best Current Practice
Stream: IETF
Date:   October 2018
Mailbox:a...@yumaworks.com
Pages:  63
Characters: 123260
Obsoletes:  RFC 6087
See Also:   BCP 216

I-D Tag:draft-ietf-netmod-rfc6087bis-20.txt

URL:https://www.rfc-editor.org/info/rfc8407

DOI:10.17487/RFC8407

This memo provides guidelines for authors and reviewers of
specifications containing YANG modules.  Recommendations and
procedures are defined, which are intended to increase
interoperability and usability of Network Configuration Protocol
(NETCONF) and RESTCONF protocol implementations that utilize YANG
modules.  This document obsoletes RFC 6087.

This document is a product of the Network Modeling Working Group of the IETF.


BCP: This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for 
improvements. Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC

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

Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object

[Alex Campbell]

It means if the model has a node such as:


leaf some-feature {

when "../type = 'ipv4' or ../type = 'ipv6'";

type int32;

}


and a certain device doesn't supports this on IPv6, it is not possible for a 
deviation to change the condition to "../type = 'ipv4'"


Is that intentional? It seems more like an omission to me.



From: Andy Bierman 
Sent: Thursday, 18 October 2018 10:54 a.m.
To: Alex Campbell
Cc: Michael Rehder; netmod@ietf.org
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure 
presence of the mandatory object



On Wed, Oct 17, 2018 at 2:43 PM, Alex Campbell 
mailto:alex.campb...@aviatnet.com>> wrote:

> At the abstract level I do not understand how when-stmt would work 
> differently.

> IMO deviation-stmt already allows enough flexibility to rewrite the model to
> fit the implementation.

FWIW: deviation statements cannot be used to modify when statements - "when" is 
missing from the list of statements that can be added/removed/replaced..
I'm wondering if this should be considered errata.



This was intentional.
I meant that deviations can already be used to add/replace/remove constraints 
within data nodes.
It is true that there is no way to say certain constraints only apply based on 
external data.
As Robert said, I don't understand why we need that.


Andy


From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Andy Bierman mailto:a...@yumaworks.com>>
Sent: Thursday, 18 October 2018 7:21 a.m.
To: Michael Rehder
Cc: netmod@ietf.org
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure 
presence of the mandatory object



On Wed, Oct 17, 2018 at 10:56 AM, Michael Rehder 
mailto:michael.reh...@amdocs.com>> wrote:
That's exactly my point - I think that the wording is unclear in the RFC, that 
"conditional" doesn't necessarily mean the mandatory status is ignored.

BTW a Schematron rule is emitted to ensure a "mandatory true" CHOICE has at 
least one CASE present, so there already is an "existential" check built.

I'll suggest a YANG enhancement on "yang-next" for the ability to respect 
mandatory status or not by a when statement.



The when statement works as intended. The entire subtree is on or off if 
when-stmt is present.
There is a lot of relevant text in 7950 and it cannot be grouped into 1 
section, so that may make
it more complicated.

The whole point of "augment when" and "uses when" is to allow the designer to
say "this part of the model is only relevant for a subset of all possible values
in another part of the model".  In SNMP we called this SPARSE AUGMENTS
but it was just DESCRIPTION clause text, not machine-reaable.

At the abstract level I do not understand how when-stmt would work differently.
IMO deviation-stmt already allows enough flexibility to rewrite the model to
fit the implementation.



Thanks
mike

Andy

> -Original Message-
> From: Ladislav Lhotka [mailto:lho...@nic.cz]
> Sent: Wednesday, October 17, 2018 4:43 AM
> To: Michael Rehder ; Juergen Schoenwaelder
> mailto:j.schoenwael...@jacobs-university.de>>
> Cc: netmod@ietf.org
> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> ensure presence of the mandatory object
>
> Michael Rehder  writes:
>
> > I've read rfc6110 and I didn't see any mention of "WHEN" on the
> > mandatory status (section 9.1.1 Optional and Mandatory Nodes doesn't
> > list it which seems a bit odd to me).
>
> RFC 6110 was being prepared along with RFC 6020, and section 9.1.1 is closely
> related to sec. 3.1 in 6020.
>
> > The section on "WHEN" just mentions the xpath mapping, not anything
> > about changing the mandatory status of the enclosing node.
>
> If you take into account the DSDL validation procedure (Figure 2 in RFC
> 6110) then everything is IMO clear:
>
> - Mandatory nodes (as defined in sec. 9.1.1) are not wrapped in
>and thus are required during RELAX NG schema
>   validation, no matter what any "when" expression says.
>
> - Section 12.17 explains how when expressions are mapped to Schematron
>   asserts. This means that if an instance node exists in the data and a
>   when expression attached to the corresponding data node in YANG
>   evaluates to false, Schematron will report a failed assert..
>
> - Note that Schematron cannot by definition report absence of an
>   instance based on the when expression attached to its data
>   node: Schematron rules are only fired for elements that are present in
>   the instance document.
>
> >
> > I still think that the YANG RFC wording of "conditional" needs to indicate 
> > if the
> node is mandatory status is affected or not.
> > Note that rfc6060 "3.1 Mandatory Nodes" doesn't mention "WHEN" (it
> > does mention presence).
>
> Perhaps this thread is just about misunderstanding of what "when" really
> means, which is: Instances for which the 

Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

[Alex Campbell]

Hi,

> The server implements the tags (at least the predefined ones), and the use 
> cases that come to my mind at least involve clients not servers.

I assume that the server here is a network element implementing 
ietf-module-tags.

I still don't see why network elements should implement ietf-module-tags.
What benefit is gained from storing the tags on the server instead of the 
client? It seems backwards.

Have I misunderstood? I assumed that ietf-module-tags was meant to be 
implemented by network elements that are NETCONF servers - but now I see the 
document doesn't actually specify who is meant to implement the module. Your 
comment about newly installed routers supports my understanding however.

> I'm a bit confused by this. Not having to go add e.g., an "OAM" tag to 
> modules is exactly the point of pre-defined tags, but you questioned their 
> value at the top of your mail.

The problem with pre-defined tags is that they are never complete. I can always 
find a useful tag that is not pre-defined.

> Either way configuring a newly installed router is a given, I don't think 
> this is the place to solve the "forgot to add all the config to my new router 
> install" issue. :) If one is using tags in ones network then making sure the 
> newly installed router has tags configured the way you expect is no different 
> from making sure that you configured IS-IS correctly.

The reason I find this problematic is the same as above - that the router has 
no use for the tag data.
It's as if my PC were to download its keyboard mapping table from my home 
router. Then I change ISPs and have to swap the router, and suddenly my 
keyboard doesn't work correctly.
It would be much better to store the keyboard mapping table for my PC *on my 
PC* instead of adding needless external dependencies.

Alex



From: Christian Hopps 
Sent: Wednesday, 17 October 2018 9:56 p.m.
To: Alex Campbell
Cc: Christian Hopps; joel jaeggli; NETMOD Working Group
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 
10/16/18

The point is to keep this open to however the community might end up choosing 
to use it. The act of pre-defining tags doesn't disallow other tags being 
defined, in fact at this point I've sent a bunch of email defending leaving 
things as open as possible. They both can co-exist. :)

Thanks,
Chris.

> On Oct 16, 2018, at 7:32 PM, Alex Campbell  wrote:
>
> I have no issue with systems using tags to classify or organize modules, 
> however this seems to me like something that would be specific to the system 
> doing the classifying.

Sure we support this. That's what user tag configuration is there for.

> It would not be something that needs to be specified in the module itself 
> (except perhaps as freeform description text), and it certainly would not 
> need to involve the NETCONF server.
> What would a server do with module classification data? (unless it is also 
> implementing some kind of module browsing interface, in which case it might 
> be used to supply the browser with data)

The server implements the tags (at least the predefined ones), and the use 
cases that come to my mind at least involve clients not servers. I'm not saying 
there wouldn't be a server use case, but it's not as obvious to me.

And yes implementing some kind of module browsing interface (which could group 
modules by tags) is a fine example of how tags can be used.

>
> Hashtags - all types, that I'm aware of - are inherently freeform and fluid, 
> changing quickly according to the desires of users. I don't think it makes 
> sense to "hard-code" them in published RFCs or even published vendor modules 
> or firmware.
>
> Tomorrow, I might want to list all modules for management plane protocols. As 
> a network operator, should I go and update the ietf-module-tags on all of my 
> network elements? That seems silly. This should be client-side data. (And if 
> I did, what happens when I add a new router and forget to update its tag 
> data? Will that confuse the client?)

I'm a bit confused by this. Not having to go add e.g., an "OAM" tag to modules 
is exactly the point of pre-defined tags, but you questioned their value at the 
top of your mail.

Either way configuring a newly installed router is a given, I don't think this 
is the place to solve the "forgot to add all the config to my new router 
install" issue. :) If one is using tags in ones network then making sure the 
newly installed router has tags configured the way you expect is no different 
from making sure that you configured IS-IS correctly.

Thanks,
Chris.

>
> Regards, Alex
>
> 
> From: Christian Hopps 
> Sent: Wednesday, 17 October 2018 1:04 a.m.
> To: Alex Campbell
> Cc: Christian Hopps; joel jaeggli; NETMOD Working Group
> Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 
> 10/16/18
>
>>
>> On Oct 3, 2018, at 8:22 PM, Alex Campbell  wrote:
>>

Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object

[Andy Bierman]

On Wed, Oct 17, 2018 at 2:43 PM, Alex Campbell 
wrote:

> > At the abstract level I do not understand how when-stmt would work
> differently.
> > IMO deviation-stmt already allows enough flexibility to rewrite the
> model to
> > fit the implementation.
>
> FWIW: deviation statements cannot be used to modify when statements -
> "when" is missing from the list of statements that can be
> added/removed/replaced.
> I'm wondering if this should be considered errata.
>
>
>

This was intentional.
I meant that deviations can already be used to add/replace/remove
constraints within data nodes.
It is true that there is no way to say certain constraints only apply based
on external data.
As Robert said, I don't understand why we need that.


Andy

--
> *From:* netmod  on behalf of Andy Bierman <
> a...@yumaworks.com>
> *Sent:* Thursday, 18 October 2018 7:21 a.m.
> *To:* Michael Rehder
> *Cc:* netmod@ietf.org
> *Subject:* Re: [netmod] WHEN statement within mandatory objects doesn't
> ensure presence of the mandatory object
>
>
>
> On Wed, Oct 17, 2018 at 10:56 AM, Michael Rehder <
> michael.reh...@amdocs.com> wrote:
>
>> That's exactly my point - I think that the wording is unclear in the RFC,
>> that "conditional" doesn't necessarily mean the mandatory status is ignored.
>>
>> BTW a Schematron rule is emitted to ensure a "mandatory true" CHOICE has
>> at least one CASE present, so there already is an "existential" check built.
>>
>> I'll suggest a YANG enhancement on "yang-next" for the ability to respect
>> mandatory status or not by a when statement.
>>
>>
>
> The when statement works as intended. The entire subtree is on or off if
> when-stmt is present.
> There is a lot of relevant text in 7950 and it cannot be grouped into 1
> section, so that may make
> it more complicated.
>
> The whole point of "augment when" and "uses when" is to allow the designer
> to
> say "this part of the model is only relevant for a subset of all possible
> values
> in another part of the model".  In SNMP we called this SPARSE AUGMENTS
> but it was just DESCRIPTION clause text, not machine-reaable.
>
> At the abstract level I do not understand how when-stmt would work
> differently.
> IMO deviation-stmt already allows enough flexibility to rewrite the model
> to
> fit the implementation.
>
>
>
>
>> Thanks
>> mike
>>
>
> Andy
>
>
>> > -Original Message-
>> > From: Ladislav Lhotka [mailto:lho...@nic.cz]
>> > Sent: Wednesday, October 17, 2018 4:43 AM
>> > To: Michael Rehder ; Juergen Schoenwaelder
>> > 
>> > Cc: netmod@ietf.org
>> > Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
>> > ensure presence of the mandatory object
>> >
>> > Michael Rehder  writes:
>> >
>> > > I've read rfc6110 and I didn't see any mention of "WHEN" on the
>> > > mandatory status (section 9.1.1 Optional and Mandatory Nodes doesn't
>> > > list it which seems a bit odd to me).
>> >
>> > RFC 6110 was being prepared along with RFC 6020, and section 9.1.1 is
>> closely
>> > related to sec. 3.1 in 6020.
>> >
>> > > The section on "WHEN" just mentions the xpath mapping, not anything
>> > > about changing the mandatory status of the enclosing node.
>> >
>> > If you take into account the DSDL validation procedure (Figure 2 in RFC
>> > 6110) then everything is IMO clear:
>> >
>> > - Mandatory nodes (as defined in sec. 9.1.1) are not wrapped in
>> >and thus are required during RELAX NG schema
>> >   validation, no matter what any "when" expression says.
>> >
>> > - Section 12.17 explains how when expressions are mapped to Schematron
>> >   asserts. This means that if an instance node exists in the data and a
>> >   when expression attached to the corresponding data node in YANG
>> >   evaluates to false, Schematron will report a failed assert..
>> >
>> > - Note that Schematron cannot by definition report absence of an
>> >   instance based on the when expression attached to its data
>> >   node: Schematron rules are only fired for elements that are present in
>> >   the instance document.
>> >
>> > >
>> > > I still think that the YANG RFC wording of "conditional" needs to
>> indicate if the
>> > node is mandatory status is affected or not.
>> > > Note that rfc6060 "3.1 Mandatory Nodes" doesn't mention "WHEN" (it
>> > > does mention presence).
>> >
>> > Perhaps this thread is just about misunderstanding of what "when" really
>> > means, which is: Instances for which the "when" expression evaluates to
>> false
>> > must not be present.
>> >
>> > It does NOT mean that instances for which the "when" expression
>> evaluates to
>> > true must be present.
>> >
>> > Lada
>> >
>> > >
>> > > Thanks
>> > > Mike
>> > >> -Original Message-
>> > >> From: Juergen Schoenwaelder
>> > >> [mailto:j.schoenwael...@jacobs-university.de]
>> > >> Sent: Saturday, October 13, 2018 5:20 PM
>> > >> To: Michael Rehder 
>> > >> Cc: netmod@ietf.org
>> > >> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
>> > >> 

Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object

[Alex Campbell]

> At the abstract level I do not understand how when-stmt would work 
> differently.

> IMO deviation-stmt already allows enough flexibility to rewrite the model to
> fit the implementation.

FWIW: deviation statements cannot be used to modify when statements - "when" is 
missing from the list of statements that can be added/removed/replaced..
I'm wondering if this should be considered errata.



From: netmod  on behalf of Andy Bierman 

Sent: Thursday, 18 October 2018 7:21 a.m.
To: Michael Rehder
Cc: netmod@ietf.org
Subject: Re: [netmod] WHEN statement within mandatory objects doesn't ensure 
presence of the mandatory object



On Wed, Oct 17, 2018 at 10:56 AM, Michael Rehder 
mailto:michael.reh...@amdocs.com>> wrote:
That's exactly my point - I think that the wording is unclear in the RFC, that 
"conditional" doesn't necessarily mean the mandatory status is ignored.

BTW a Schematron rule is emitted to ensure a "mandatory true" CHOICE has at 
least one CASE present, so there already is an "existential" check built.

I'll suggest a YANG enhancement on "yang-next" for the ability to respect 
mandatory status or not by a when statement.



The when statement works as intended. The entire subtree is on or off if 
when-stmt is present.
There is a lot of relevant text in 7950 and it cannot be grouped into 1 
section, so that may make
it more complicated.

The whole point of "augment when" and "uses when" is to allow the designer to
say "this part of the model is only relevant for a subset of all possible values
in another part of the model".  In SNMP we called this SPARSE AUGMENTS
but it was just DESCRIPTION clause text, not machine-reaable.

At the abstract level I do not understand how when-stmt would work differently.
IMO deviation-stmt already allows enough flexibility to rewrite the model to
fit the implementation.



Thanks
mike

Andy

> -Original Message-
> From: Ladislav Lhotka [mailto:lho...@nic.cz]
> Sent: Wednesday, October 17, 2018 4:43 AM
> To: Michael Rehder ; Juergen Schoenwaelder
> mailto:j.schoenwael...@jacobs-university.de>>
> Cc: netmod@ietf.org
> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> ensure presence of the mandatory object
>
> Michael Rehder  writes:
>
> > I've read rfc6110 and I didn't see any mention of "WHEN" on the
> > mandatory status (section 9.1.1 Optional and Mandatory Nodes doesn't
> > list it which seems a bit odd to me).
>
> RFC 6110 was being prepared along with RFC 6020, and section 9.1.1 is closely
> related to sec. 3.1 in 6020.
>
> > The section on "WHEN" just mentions the xpath mapping, not anything
> > about changing the mandatory status of the enclosing node.
>
> If you take into account the DSDL validation procedure (Figure 2 in RFC
> 6110) then everything is IMO clear:
>
> - Mandatory nodes (as defined in sec. 9.1.1) are not wrapped in
>and thus are required during RELAX NG schema
>   validation, no matter what any "when" expression says.
>
> - Section 12.17 explains how when expressions are mapped to Schematron
>   asserts. This means that if an instance node exists in the data and a
>   when expression attached to the corresponding data node in YANG
>   evaluates to false, Schematron will report a failed assert..
>
> - Note that Schematron cannot by definition report absence of an
>   instance based on the when expression attached to its data
>   node: Schematron rules are only fired for elements that are present in
>   the instance document.
>
> >
> > I still think that the YANG RFC wording of "conditional" needs to indicate 
> > if the
> node is mandatory status is affected or not.
> > Note that rfc6060 "3.1 Mandatory Nodes" doesn't mention "WHEN" (it
> > does mention presence).
>
> Perhaps this thread is just about misunderstanding of what "when" really
> means, which is: Instances for which the "when" expression evaluates to false
> must not be present.
>
> It does NOT mean that instances for which the "when" expression evaluates to
> true must be present.
>
> Lada
>
> >
> > Thanks
> > Mike
> >> -Original Message-
> >> From: Juergen Schoenwaelder
> >> [mailto:j.schoenwael...@jacobs-university.de]
> >> Sent: Saturday, October 13, 2018 5:20 PM
> >> To: Michael Rehder 
> >> Cc: netmod@ietf.org
> >> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> >> ensure presence of the mandatory object
> >>
> >> On Fri, Oct 12, 2018 at 04:08:48PM +, Michael Rehder wrote:
> >>
> >> > The mandatory statement in that case is ignored (I've pointed out
> >> > the RNG and Schematron lack of enforcement).  WHEN trumps the
> >> > mandatory status (via explicit mandatory or implicit mandatory via
> >> > min-elements
> >> > 1)
> >>
> >> Has the RNG and Schematron been obtained following RFC 6110? If so,
> >> this may be a problem with RFC 6110 but not with YANG 

Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object

[Andy Bierman]

On Wed, Oct 17, 2018 at 10:56 AM, Michael Rehder 
wrote:

> That's exactly my point - I think that the wording is unclear in the RFC,
> that "conditional" doesn't necessarily mean the mandatory status is ignored.
>
> BTW a Schematron rule is emitted to ensure a "mandatory true" CHOICE has
> at least one CASE present, so there already is an "existential" check built.
>
> I'll suggest a YANG enhancement on "yang-next" for the ability to respect
> mandatory status or not by a when statement.
>
>

The when statement works as intended. The entire subtree is on or off if
when-stmt is present.
There is a lot of relevant text in 7950 and it cannot be grouped into 1
section, so that may make
it more complicated.

The whole point of "augment when" and "uses when" is to allow the designer
to
say "this part of the model is only relevant for a subset of all possible
values
in another part of the model".  In SNMP we called this SPARSE AUGMENTS
but it was just DESCRIPTION clause text, not machine-reaable.

At the abstract level I do not understand how when-stmt would work
differently.
IMO deviation-stmt already allows enough flexibility to rewrite the model to
fit the implementation.




> Thanks
> mike
>

Andy


> > -Original Message-
> > From: Ladislav Lhotka [mailto:lho...@nic.cz]
> > Sent: Wednesday, October 17, 2018 4:43 AM
> > To: Michael Rehder ; Juergen Schoenwaelder
> > 
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> > ensure presence of the mandatory object
> >
> > Michael Rehder  writes:
> >
> > > I've read rfc6110 and I didn't see any mention of "WHEN" on the
> > > mandatory status (section 9.1.1 Optional and Mandatory Nodes doesn't
> > > list it which seems a bit odd to me).
> >
> > RFC 6110 was being prepared along with RFC 6020, and section 9.1.1 is
> closely
> > related to sec. 3.1 in 6020.
> >
> > > The section on "WHEN" just mentions the xpath mapping, not anything
> > > about changing the mandatory status of the enclosing node.
> >
> > If you take into account the DSDL validation procedure (Figure 2 in RFC
> > 6110) then everything is IMO clear:
> >
> > - Mandatory nodes (as defined in sec. 9.1.1) are not wrapped in
> >and thus are required during RELAX NG schema
> >   validation, no matter what any "when" expression says.
> >
> > - Section 12.17 explains how when expressions are mapped to Schematron
> >   asserts. This means that if an instance node exists in the data and a
> >   when expression attached to the corresponding data node in YANG
> >   evaluates to false, Schematron will report a failed assert.
> >
> > - Note that Schematron cannot by definition report absence of an
> >   instance based on the when expression attached to its data
> >   node: Schematron rules are only fired for elements that are present in
> >   the instance document.
> >
> > >
> > > I still think that the YANG RFC wording of "conditional" needs to
> indicate if the
> > node is mandatory status is affected or not.
> > > Note that rfc6060 "3.1 Mandatory Nodes" doesn't mention "WHEN" (it
> > > does mention presence).
> >
> > Perhaps this thread is just about misunderstanding of what "when" really
> > means, which is: Instances for which the "when" expression evaluates to
> false
> > must not be present.
> >
> > It does NOT mean that instances for which the "when" expression
> evaluates to
> > true must be present.
> >
> > Lada
> >
> > >
> > > Thanks
> > > Mike
> > >> -Original Message-
> > >> From: Juergen Schoenwaelder
> > >> [mailto:j.schoenwael...@jacobs-university.de]
> > >> Sent: Saturday, October 13, 2018 5:20 PM
> > >> To: Michael Rehder 
> > >> Cc: netmod@ietf.org
> > >> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> > >> ensure presence of the mandatory object
> > >>
> > >> On Fri, Oct 12, 2018 at 04:08:48PM +, Michael Rehder wrote:
> > >>
> > >> > The mandatory statement in that case is ignored (I’ve pointed out
> > >> > the RNG and Schematron lack of enforcement).  WHEN trumps the
> > >> > mandatory status (via explicit mandatory or implicit mandatory via
> > >> > min-elements
> > >> > 1)
> > >>
> > >> Has the RNG and Schematron been obtained following RFC 6110? If so,
> > >> this may be a problem with RFC 6110 but not with YANG itself. There
> > >> are validators that do not use RNG or Schematron.
> > >>
> > >> /js
> > >>
> > >> --
> > >> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > >> Fax:   +49 421 200 3103 
> > > “Amdocs’ email platform is based on a third-party, worldwide,
> cloud-based
> > system. Any emails sent to Amdocs will be processed and stored using such
> > system and are accessible by third party providers of such system on a
> limited
> > basis. Your sending of emails to Amdocs evidences your consent to the
> use of
> > such system and such processing, 

Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object

[Michael Rehder]

That's exactly my point - I think that the wording is unclear in the RFC, that 
"conditional" doesn't necessarily mean the mandatory status is ignored.

BTW a Schematron rule is emitted to ensure a "mandatory true" CHOICE has at 
least one CASE present, so there already is an "existential" check built.

I'll suggest a YANG enhancement on "yang-next" for the ability to respect 
mandatory status or not by a when statement.

Thanks
mike
> -Original Message-
> From: Ladislav Lhotka [mailto:lho...@nic.cz]
> Sent: Wednesday, October 17, 2018 4:43 AM
> To: Michael Rehder ; Juergen Schoenwaelder
> 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> ensure presence of the mandatory object
> 
> Michael Rehder  writes:
> 
> > I've read rfc6110 and I didn't see any mention of "WHEN" on the
> > mandatory status (section 9.1.1 Optional and Mandatory Nodes doesn't
> > list it which seems a bit odd to me).
> 
> RFC 6110 was being prepared along with RFC 6020, and section 9.1.1 is closely
> related to sec. 3.1 in 6020.
> 
> > The section on "WHEN" just mentions the xpath mapping, not anything
> > about changing the mandatory status of the enclosing node.
> 
> If you take into account the DSDL validation procedure (Figure 2 in RFC
> 6110) then everything is IMO clear:
> 
> - Mandatory nodes (as defined in sec. 9.1.1) are not wrapped in
>and thus are required during RELAX NG schema
>   validation, no matter what any "when" expression says.
> 
> - Section 12.17 explains how when expressions are mapped to Schematron
>   asserts. This means that if an instance node exists in the data and a
>   when expression attached to the corresponding data node in YANG
>   evaluates to false, Schematron will report a failed assert.
> 
> - Note that Schematron cannot by definition report absence of an
>   instance based on the when expression attached to its data
>   node: Schematron rules are only fired for elements that are present in
>   the instance document.
> 
> >
> > I still think that the YANG RFC wording of "conditional" needs to indicate 
> > if the
> node is mandatory status is affected or not.
> > Note that rfc6060 "3.1 Mandatory Nodes" doesn't mention "WHEN" (it
> > does mention presence).
> 
> Perhaps this thread is just about misunderstanding of what "when" really
> means, which is: Instances for which the "when" expression evaluates to false
> must not be present.
> 
> It does NOT mean that instances for which the "when" expression evaluates to
> true must be present.
> 
> Lada
> 
> >
> > Thanks
> > Mike
> >> -Original Message-
> >> From: Juergen Schoenwaelder
> >> [mailto:j.schoenwael...@jacobs-university.de]
> >> Sent: Saturday, October 13, 2018 5:20 PM
> >> To: Michael Rehder 
> >> Cc: netmod@ietf.org
> >> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
> >> ensure presence of the mandatory object
> >>
> >> On Fri, Oct 12, 2018 at 04:08:48PM +, Michael Rehder wrote:
> >>
> >> > The mandatory statement in that case is ignored (I’ve pointed out
> >> > the RNG and Schematron lack of enforcement).  WHEN trumps the
> >> > mandatory status (via explicit mandatory or implicit mandatory via
> >> > min-elements
> >> > 1)
> >>
> >> Has the RNG and Schematron been obtained following RFC 6110? If so,
> >> this may be a problem with RFC 6110 but not with YANG itself. There
> >> are validators that do not use RNG or Schematron.
> >>
> >> /js
> >>
> >> --
> >> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> >> Fax:   +49 421 200 3103 
> > “Amdocs’ email platform is based on a third-party, worldwide, cloud-based
> system. Any emails sent to Amdocs will be processed and stored using such
> system and are accessible by third party providers of such system on a limited
> basis. Your sending of emails to Amdocs evidences your consent to the use of
> such system and such processing, storing and access”.
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
“Amdocs’ email platform is based on a third-party, worldwide, cloud-based 
system. Any emails sent to Amdocs will be processed and stored using such 
system and are accessible by third party providers of such system on a limited 
basis. Your sending of emails to Amdocs evidences your consent to the use of 
such system and such processing, storing and access”.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Review comments for module-tags-02

[Vladimir Vassilev]

Hi,

Adding  -state modules to all new drafts seems like unnecessary 
overhead. Even mentioning NMDA in a draft that has no logical 
relationship to NMDA also seems like unnecessary overhead.


Not a great set of alternatives. The positive thing is that vendors that 
do not have to worry about existing applications should really have no 
problem responding to the pressure.


Vladimir

On 10/17/18 4:39 PM, Christian Hopps wrote:

I'll chime in as an operator here, I do not feel there is a need to support 
non-NMDA implementations with this brand new work that won't be finished let 
alone start being used for another so many months (at best). There's nothing 
wrong with simply requiring NMDA for various modules going forward. Indeed I'd 
like more modules to require NMDA if only to add pressure to get it deployed by 
vendors.

Thanks,
Chris.


On Oct 17, 2018, at 10:23 AM, Juergen Schoenwaelder 
 wrote:

The WG needs to agree whether a -state module in the Appendix is
needed. I just commented on the proposal to add a subtree, which
violates the guidelines.

/js

On Wed, Oct 17, 2018 at 01:13:06PM +, Rohit R Ranade wrote:

Either defining a new module in an Appendix or a subtree, I am OK with either 
and both of us concur that the draft needs the changes.

-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
Sent: 17 October 2018 18:18
To: Rohit R Ranade 
Cc: Christian Hopps ; netmod@ietf.org
Subject: Re: [netmod] Review comments for module-tags-02

Obviously, this is now a slightly different statement. There are NMDA 
transition guidelines that have been discussed at length and finally been 
integated into

https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-4.23.3

This section 4.23.3 says under case (a):

   Both the NMDA and the non-NMDA modules SHOULD
   be published in the same document, with NMDA modules in the document
   main body and the non-NMDA modules in a non-normative appendix.

In other words, you do not pollute a new NMDA module with non-NMDA subtrees but 
instead you create an additional module that goes into an appendix and is only 
relevant for transition purposes. I think Rob created tools to generate such 
things. Section 4.23.3.1 also provides some guidelines for creating temporary 
non NMDA modules.

/js

On Wed, Oct 17, 2018 at 12:22:39PM +, Rohit R Ranade wrote:

If the server does not yet support NETCONF-NMDA / RESTCONF-NMDA drafts, then we 
will need this separate subtree to show the system defined tags.

-Original Message-
From: Juergen Schoenwaelder
[mailto:j.schoenwael...@jacobs-university.de]
Sent: 17 October 2018 17:22
To: Rohit R Ranade 
Cc: Christian Hopps ; netmod@ietf.org
Subject: Re: [netmod] Review comments for module-tags-02

On Wed, Oct 17, 2018 at 11:46:03AM +, Rohit R Ranade wrote:


I think we need to define a subtree for non-NMDA clients to get the
operational tags.

It is not much of a change for a _client_ to read a different datastore hence I 
do not think this is needed.

/js

--
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

--
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

--
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] Review comments for module-tags-02

[Christian Hopps]

I'll chime in as an operator here, I do not feel there is a need to support 
non-NMDA implementations with this brand new work that won't be finished let 
alone start being used for another so many months (at best). There's nothing 
wrong with simply requiring NMDA for various modules going forward. Indeed I'd 
like more modules to require NMDA if only to add pressure to get it deployed by 
vendors.

Thanks,
Chris.

> On Oct 17, 2018, at 10:23 AM, Juergen Schoenwaelder 
>  wrote:
> 
> The WG needs to agree whether a -state module in the Appendix is
> needed. I just commented on the proposal to add a subtree, which
> violates the guidelines.
> 
> /js
> 
> On Wed, Oct 17, 2018 at 01:13:06PM +, Rohit R Ranade wrote:
>> Either defining a new module in an Appendix or a subtree, I am OK with 
>> either and both of us concur that the draft needs the changes.
>> 
>> -Original Message-
>> From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
>> Sent: 17 October 2018 18:18
>> To: Rohit R Ranade 
>> Cc: Christian Hopps ; netmod@ietf.org
>> Subject: Re: [netmod] Review comments for module-tags-02
>> 
>> Obviously, this is now a slightly different statement. There are NMDA 
>> transition guidelines that have been discussed at length and finally been 
>> integated into
>> 
>> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-4.23.3
>> 
>> This section 4.23.3 says under case (a):
>> 
>>   Both the NMDA and the non-NMDA modules SHOULD
>>   be published in the same document, with NMDA modules in the document
>>   main body and the non-NMDA modules in a non-normative appendix.
>> 
>> In other words, you do not pollute a new NMDA module with non-NMDA subtrees 
>> but instead you create an additional module that goes into an appendix and 
>> is only relevant for transition purposes. I think Rob created tools to 
>> generate such things. Section 4.23.3.1 also provides some guidelines for 
>> creating temporary non NMDA modules.
>> 
>> /js
>> 
>> On Wed, Oct 17, 2018 at 12:22:39PM +, Rohit R Ranade wrote:
>>> If the server does not yet support NETCONF-NMDA / RESTCONF-NMDA drafts, 
>>> then we will need this separate subtree to show the system defined tags.
>>> 
>>> -Original Message-
>>> From: Juergen Schoenwaelder 
>>> [mailto:j.schoenwael...@jacobs-university.de]
>>> Sent: 17 October 2018 17:22
>>> To: Rohit R Ranade 
>>> Cc: Christian Hopps ; netmod@ietf.org
>>> Subject: Re: [netmod] Review comments for module-tags-02
>>> 
>>> On Wed, Oct 17, 2018 at 11:46:03AM +, Rohit R Ranade wrote:
>>> 
 I think we need to define a subtree for non-NMDA clients to get the 
 operational tags.
>>> 
>>> It is not much of a change for a _client_ to read a different datastore 
>>> hence I do not think this is needed.
>>> 
>>> /js
>>> 
>>> -- 
>>> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>>> Fax:   +49 421 200 3103 
>> 
>> -- 
>> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103 
> 
> -- 
> 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

Re: [netmod] Review comments for module-tags-02

[Juergen Schoenwaelder]

The WG needs to agree whether a -state module in the Appendix is
needed. I just commented on the proposal to add a subtree, which
violates the guidelines.

/js

On Wed, Oct 17, 2018 at 01:13:06PM +, Rohit R Ranade wrote:
> Either defining a new module in an Appendix or a subtree, I am OK with either 
> and both of us concur that the draft needs the changes.
> 
> -Original Message-
> From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
> Sent: 17 October 2018 18:18
> To: Rohit R Ranade 
> Cc: Christian Hopps ; netmod@ietf.org
> Subject: Re: [netmod] Review comments for module-tags-02
> 
> Obviously, this is now a slightly different statement. There are NMDA 
> transition guidelines that have been discussed at length and finally been 
> integated into
> 
> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-4.23.3
> 
> This section 4.23.3 says under case (a):
> 
>Both the NMDA and the non-NMDA modules SHOULD
>be published in the same document, with NMDA modules in the document
>main body and the non-NMDA modules in a non-normative appendix.
> 
> In other words, you do not pollute a new NMDA module with non-NMDA subtrees 
> but instead you create an additional module that goes into an appendix and is 
> only relevant for transition purposes. I think Rob created tools to generate 
> such things. Section 4.23.3.1 also provides some guidelines for creating 
> temporary non NMDA modules.
> 
> /js
> 
> On Wed, Oct 17, 2018 at 12:22:39PM +, Rohit R Ranade wrote:
> > If the server does not yet support NETCONF-NMDA / RESTCONF-NMDA drafts, 
> > then we will need this separate subtree to show the system defined tags.
> > 
> > -Original Message-
> > From: Juergen Schoenwaelder 
> > [mailto:j.schoenwael...@jacobs-university.de]
> > Sent: 17 October 2018 17:22
> > To: Rohit R Ranade 
> > Cc: Christian Hopps ; netmod@ietf.org
> > Subject: Re: [netmod] Review comments for module-tags-02
> > 
> > On Wed, Oct 17, 2018 at 11:46:03AM +, Rohit R Ranade wrote:
> > 
> > > I think we need to define a subtree for non-NMDA clients to get the 
> > > operational tags.
> > 
> > It is not much of a change for a _client_ to read a different datastore 
> > hence I do not think this is needed.
> > 
> > /js
> > 
> > -- 
> > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

-- 
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

Re: [netmod] Review comments for module-tags-02

[Rohit R Ranade]

Either defining a new module in an Appendix or a subtree, I am OK with either 
and both of us concur that the draft needs the changes.

-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
Sent: 17 October 2018 18:18
To: Rohit R Ranade 
Cc: Christian Hopps ; netmod@ietf.org
Subject: Re: [netmod] Review comments for module-tags-02

Obviously, this is now a slightly different statement. There are NMDA 
transition guidelines that have been discussed at length and finally been 
integated into

https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-4.23.3

This section 4.23.3 says under case (a):

   Both the NMDA and the non-NMDA modules SHOULD
   be published in the same document, with NMDA modules in the document
   main body and the non-NMDA modules in a non-normative appendix.

In other words, you do not pollute a new NMDA module with non-NMDA subtrees but 
instead you create an additional module that goes into an appendix and is only 
relevant for transition purposes. I think Rob created tools to generate such 
things. Section 4.23.3.1 also provides some guidelines for creating temporary 
non NMDA modules.

/js

On Wed, Oct 17, 2018 at 12:22:39PM +, Rohit R Ranade wrote:
> If the server does not yet support NETCONF-NMDA / RESTCONF-NMDA drafts, then 
> we will need this separate subtree to show the system defined tags.
> 
> -Original Message-
> From: Juergen Schoenwaelder 
> [mailto:j.schoenwael...@jacobs-university.de]
> Sent: 17 October 2018 17:22
> To: Rohit R Ranade 
> Cc: Christian Hopps ; netmod@ietf.org
> Subject: Re: [netmod] Review comments for module-tags-02
> 
> On Wed, Oct 17, 2018 at 11:46:03AM +, Rohit R Ranade wrote:
> 
> > I think we need to define a subtree for non-NMDA clients to get the 
> > operational tags.
> 
> It is not much of a change for a _client_ to read a different datastore hence 
> I do not think this is needed.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

-- 
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

Re: [netmod] Review comments for module-tags-02

[Juergen Schoenwaelder]

Obviously, this is now a slightly different statement. There are NMDA
transition guidelines that have been discussed at length and finally
been integated into

https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-4.23.3

This section 4.23.3 says under case (a):

   Both the NMDA and the non-NMDA modules SHOULD
   be published in the same document, with NMDA modules in the document
   main body and the non-NMDA modules in a non-normative appendix.

In other words, you do not pollute a new NMDA module with non-NMDA
subtrees but instead you create an additional module that goes into an
appendix and is only relevant for transition purposes. I think Rob
created tools to generate such things. Section 4.23.3.1 also provides
some guidelines for creating temporary non NMDA modules.

/js

On Wed, Oct 17, 2018 at 12:22:39PM +, Rohit R Ranade wrote:
> If the server does not yet support NETCONF-NMDA / RESTCONF-NMDA drafts, then 
> we will need this separate subtree to show the system defined tags.
> 
> -Original Message-
> From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
> Sent: 17 October 2018 17:22
> To: Rohit R Ranade 
> Cc: Christian Hopps ; netmod@ietf.org
> Subject: Re: [netmod] Review comments for module-tags-02
> 
> On Wed, Oct 17, 2018 at 11:46:03AM +, Rohit R Ranade wrote:
> 
> > I think we need to define a subtree for non-NMDA clients to get the 
> > operational tags.
> 
> It is not much of a change for a _client_ to read a different datastore hence 
> I do not think this is needed.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

-- 
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] I-D Action: draft-ietf-netmod-module-tags-03.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

Title   : YANG Module Tags
Authors : Christan Hopps
  Lou Berger
  Dean Bogdanovic
Filename: draft-ietf-netmod-module-tags-03.txt
Pages   : 11
Date: 2018-10-17

Abstract:
   This document provides for the association of tags with YANG modules.
   The expectation is for such tags to be used to help classify and
   organize modules.  A method for defining, reading and writing a
   modules tags is provided.  Tags may be standardized and assigned
   during module definition; assigned by implementations; or dynamically
   defined and set by users.  This document provides guidance to future
   model writers and, as such, this document updates
   [I-D.ietf-netmod-rfc6087bis].


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-module-tags-03
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-module-tags-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-03


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

Re: [netmod] Review comments for module-tags-02

[Rohit R Ranade]

If the server does not yet support NETCONF-NMDA / RESTCONF-NMDA drafts, then we 
will need this separate subtree to show the system defined tags.

-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
Sent: 17 October 2018 17:22
To: Rohit R Ranade 
Cc: Christian Hopps ; netmod@ietf.org
Subject: Re: [netmod] Review comments for module-tags-02

On Wed, Oct 17, 2018 at 11:46:03AM +, Rohit R Ranade wrote:

> I think we need to define a subtree for non-NMDA clients to get the 
> operational tags.

It is not much of a change for a _client_ to read a different datastore hence I 
do not think this is needed.

/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

Re: [netmod] Regarding IPR on draft-kwatsen-netmod-artwork-folding-08

[Benoit Claise]

No, I am not aware of any IPR related to this draft.

Regards, B.


No, I am not aware of any IPR related to this draft.

-Qin
-邮件原件-
发件人: Kent Watsen [mailto:kwat...@juniper.net]
发送时间: 2018年10月17日 5:56
收件人: adr...@olddog.co.uk; 'Lou Berger'; 'Benoit Claise'; Qin Wu; Adrian Farrel
抄送: 'NetMod WG Chairs'; 'NetMod WG'
主题: Re: [netmod] Regarding IPR on draft-kwatsen-netmod-artwork-folding-08

No, I'm not aware of any IPR that applies to this draft

Kent // as an author


-Original Message-
From: Adrian Farrel 
Reply-To: "adr...@olddog.co.uk" 
Date: Tuesday, October 16, 2018 at 5:24 PM
To: 'Lou Berger' , Kent Watsen , Benoit Claise 
, "bill...@huawei.com" , Adrian Farrel 

Cc: "netmod-cha...@ietf.org" , "netmod@ietf.org" 

Subject: RE: [netmod] Regarding IPR on draft-kwatsen-netmod-artwork-folding-08
Resent-From: 
Resent-To: , , , 

Resent-Date: Tuesday, October 16, 2018 at 5:24 PM

Hi Lou,

"No, I'm not aware of any IPR that applies to this draft"

Thanks,
Adrian


-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Lou Berger
Sent: 16 October 2018 21:26
To: Kent Watsen; Benoit Claise; bill...@huawei.com;
afar...@juniper.net
Cc: NetMod WG Chairs; NetMod WG
Subject: [netmod] Regarding IPR on
draft-kwatsen-netmod-artwork-folding-08

Authors, Contributors, WG,

As part of preparation for WG Adoption

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer
the above by responding to this email regardless of whether or not you
are aware of any relevant IPR. This document will not advance to the
next stage until a response has been received from each author and
listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS
MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not
listed as an author or contributor, we remind you of your obligations
under the IETF IPR rules which encourages you to notify the IETF if
you are aware of IPR of others on an IETF contribution, or to refrain
from participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed
above and
https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_group_iesg_trac_wiki_IntellectualProperty=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=MYa5-XNVgPocq1crLnMrOgxQzh_8-RFkD3Acsm4X484=2agdiBlSJ2yMLyrlwdw80WL5jskn_fuVgO2jffkyfFY=.

Thank you,
NetMod WG Chairs

PS Please include all listed in the headers of this message in your
response.



___
netmod mailing list
netmod@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
man_listinfo_netmod=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=MYa5-XNVgPocq1crLnMrOgxQzh_8-RFkD3Acsm4X484=iYr0TUeVJZ2xSBy9gvelUf2HiK2uP3Lh5EsoBqfoACw=




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

Re: [netmod] Review comments for module-tags-02

[Juergen Schoenwaelder]

On Wed, Oct 17, 2018 at 11:46:03AM +, Rohit R Ranade wrote:

> I think we need to define a subtree for non-NMDA clients to get the
> operational tags.

It is not much of a change for a _client_ to read a different
datastore hence I do not think this is needed.

/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

Re: [netmod] Review comments for module-tags-02

[Rohit R Ranade]

I think we need to define a subtree for non-NMDA clients to get the operational 
tags.

Reference:  https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01
"   2.  Models that require immediate support for "in use" and "system
   created" information SHOULD be structured for NMDA.  A non-NMDA
   version of these models SHOULD also be published, using either an
   existing model or a model created either by hand or with suitable
   tools that support current modeling strategies.  Both the NMDA
   and the non-NMDA modules SHOULD be published in the same
   document, with NMDA modules in the document main body and the
   non-NMDA modules in a non-normative appendix.  The use of the
   non-NMDA model will allow temporary bridging of the time period
   until NMDA implementations are available."  

-Original Message-
From: Christian Hopps [mailto:cho...@chopps.org] 
Sent: 17 October 2018 14:08
To: Rohit R Ranade 
Cc: Christian Hopps ; netmod@ietf.org
Subject: Re: [netmod] Review comments for module-tags-02



> On Oct 17, 2018, at 12:09 AM, Rohit R Ranade  wrote:
> 
> 1. In the desrciption of leaf-list tag
>   "
>   The operational view of this list will contain all
>  user-configured tags as well as any predefined tags that
>  have not been masked by the user using the masked-tag leaf
>  list below.
>   "
>   ==> So the predefined tags, should be output as  origin  in 
>  ?
>   If so, I would suggest renaming them to "default" tags.

default has this in it's definition:
 
"The default origin is only used when the configuration has not been
 provided by any other source."

The predefined tags are being added due to the module definition or by the 
vendor implementing the module, and the user would be adding to this set (not 
replacing) when they configure tags (and thus the reason for the mask). So I 
think predefined tags should have "system" origin. We can add text to the 
document to clarify this if others agree.

> 2. For "masked-tag", if the purpose is to only mask "predefined" tags, 
> why not rename as masked-default-tag or masked-predefined-tag ?
> Also if a tag say tag-1 (not predefined) is added to this list, and 
> tag-1 added to "tag", the tag-1 will still be output in , 
> which may look confusing to the user as the tag-1 will exist in both "tag" 
> and "masked-tag". Changing the "masked-tag" may help in this case.

What's the compelling reason to make this more complex? Right now, the 
predefined tags are added, the configured tags are added, and then the masks 
are applied. KISS is the goal.

> 3.  It is still not clear, what is the use-case where user wants to "mask" a 
> predefined tag..

The user is the ultimate arbiter over their network is the point. On example is 
a vendor adds a tag indicating the module belongs to a certain category of 
modules which would enable it's use in that users network, but for whatever 
reason the user does not agree.

> 4. What about already existing modules which donot define the tags, should 
> they be output in the
>   "module-tags" list ? Or better to use "min-elements" for leaf-list "tags" ?

If they have no tags, there's no reason for them to be in the list, whether 
they come before or after the publication of this document (or after a device 
implements it). However, any client software is going to need to deal with no 
module entry, and also with an entry with no tags. I think it's better to stay 
away from adding restrictions that don't add real value, but do allow for 
software to "get it wrong".

> 5. I also agree with other reviewer's comment that this document must 
> standardize what a module-tag must look like.
>   Currently it only standardizes a prefix, if the rest of the tag is not 
> standardized a client has no way to parse
>   this tag.
>   Maybe we can say that a tag will contain 3 parts, 1st part is about 
> organization, 2nd part is about the whether it is service / element, 3rd part
>   can be a sub-category of part-2.

There's a lot of prior art here in leaving this open to however people want to 
use the meta-data (see routing admin-tags, media tags, social media tags, 
etc).. The reservation of prefix space allows for future definition if that 
ends up being needed. Users are free to define whatever structure they want if 
any. This discussion in particular was carried out over routing admin tags in 
the IETF and not pre-defining structure/meaning was the end result and has 
worked out well.

Thanks,
Chris.

>  
> With Regards,
> Rohit R
> ___
> 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] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

[Martin Bjorklund]

Christian Hopps  wrote:
> 
> 
> > On Oct 16, 2018, at 7:39 PM, Andy Bierman  wrote:
> > 
> > 
> > 
> > On Tue, Oct 16, 2018 at 3:15 PM, Christian Hopps  wrote:
> > 
> > Andy Bierman  writes:
> > 
> > This draft needs to define the module-tag encoding wrt/
> >- valid characters (e.g., some subset of UTF-8)
> >- min/max length (e.g., implementation MUST support at least 64 chars
> > and can support larger)
> > 
> > I'm looking for suggestions on how to do this subset. We had intended to 
> > allow for as wide as possible content; however, I think disallowing tabs, 
> > newlines, carriage returns is more than reasonable. Has a type like this 
> > already been standardized or is there an example available somewhere?
> > 
> > I suppose yang-identifier type is too restrictive so I will agree that 
> > restricting whitespace and colon chars
> > is probably good enough 
> 
> 
> I'm going to use:
> 
>   typedef tag {
> type string {
>   pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+';

Ok.  Note that the legal characters in "string" are different in YANG
version 1 and 1.1, so this is a good reason (theoretical perhaps) to
use 1.1.

I do think that this module should be 1.1.  A number of fixes were
done in 1.1, and unless there are strong reasons not to use 1.1, you
should use it.  The string type is one example, and the effect on the
size of  in NETCONF is another.


/martin


>   length "1..max";
> }
> description
>   "A tag value is composed of a standard prefix followed
>by any string value that does not include carriage return,
>form-feed, newline or tab characters."
>   }
> 
> I left in space -- lot's of people in the non-unix world use spaces.
> 
> Thanks,
> Chris.
> ___
> 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] Review comments for module-tags-02

[Martin Bjorklund]

Christian Hopps  wrote:
> 
> 
> > On Oct 17, 2018, at 12:09 AM, Rohit R Ranade 
> > wrote:
> > 
> > 1. In the desrciption of leaf-list tag
> >   "
> >   The operational view of this list will contain all
> >  user-configured tags as well as any predefined tags that
> >  have not been masked by the user using the masked-tag leaf
> >  list below.
> >   "
> >   ==> So the predefined tags, should be output as  origin in
> >?
> >   If so, I would suggest renaming them to "default" tags.
> 
> default has this in it's definition:
>  
> "The default origin is only used when the configuration has not been
>  provided by any other source."
> 
> The predefined tags are being added due to the module definition or by
> the vendor implementing the module, and the user would be adding to
> this set (not replacing) when they configure tags (and thus the reason
> for the mask). So I think predefined tags should have "system"
> origin. We can add text to the document to clarify this if others
> agree.

I agree that the origin should be "system" for these tags.

> > 2. For "masked-tag", if the purpose is to only mask "predefined" tags,
> > why not rename
> > as masked-default-tag or masked-predefined-tag ?
> > Also if a tag say tag-1 (not predefined) is added to this list, and
> > tag-1 added to "tag", the tag-1
> > will still be output in , which may look confusing to the
> > user as the tag-1 will exist
> > in both "tag" and "masked-tag". Changing the "masked-tag" may help in
> > this case.
> 
> What's the compelling reason to make this more complex? Right now, the
> predefined tags are added, the configured tags are added, and then the
> masks are applied. KISS is the goal.

But this is not what the draft says.  The description of masked-tag
says that predefined tags are removed.

Keep it simple, but make sure the description is clear.  So maybe add
your 3 steps above to the draft, and remove the word "predefined" from
the description of masked-tag.


/martin


> > 3.  It is still not clear, what is the use-case where user wants to
> > "mask" a predefined tag..
> 
> The user is the ultimate arbiter over their network is the point. On
> example is a vendor adds a tag indicating the module belongs to a
> certain category of modules which would enable it's use in that users
> network, but for whatever reason the user does not agree.
> 
> > 4. What about already existing modules which donot define the tags,
> > should they be output in the
> >   "module-tags" list ? Or better to use "min-elements" for leaf-list
> >   "tags" ?
> 
> If they have no tags, there's no reason for them to be in the list,
> whether they come before or after the publication of this document (or
> after a device implements it). However, any client software is going
> to need to deal with no module entry, and also with an entry with no
> tags. I think it's better to stay away from adding restrictions that
> don't add real value, but do allow for software to "get it wrong".
> 
> > 5. I also agree with other reviewer's comment that this document must
> > standardize what a module-tag must look like.
> >   Currently it only standardizes a prefix, if the rest of the tag is not
> >   standardized a client has no way to parse
> >   this tag.
> >   Maybe we can say that a tag will contain 3 parts, 1st part is about
> >   organization, 2nd part is about the whether it is service / element,
> >   3rd part
> >   can be a sub-category of part-2.
> 
> There's a lot of prior art here in leaving this open to however people
> want to use the meta-data (see routing admin-tags, media tags, social
> media tags, etc).. The reservation of prefix space allows for future
> definition if that ends up being needed. Users are free to define
> whatever structure they want if any. This discussion in particular was
> carried out over routing admin tags in the IETF and not pre-defining
> structure/meaning was the end result and has worked out well.
> 
> Thanks,
> Chris.
> 
> >  
> > With Regards,
> > Rohit R
> > ___
> > 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] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

[Christian Hopps]

> On Oct 16, 2018, at 7:39 PM, Andy Bierman  wrote:
> 
> 
> 
> On Tue, Oct 16, 2018 at 3:15 PM, Christian Hopps  wrote:
> 
> Andy Bierman  writes:
> 
> This draft needs to define the module-tag encoding wrt/
>- valid characters (e.g., some subset of UTF-8)
>- min/max length (e.g., implementation MUST support at least 64 chars
> and can support larger)
> 
> I'm looking for suggestions on how to do this subset. We had intended to 
> allow for as wide as possible content; however, I think disallowing tabs, 
> newlines, carriage returns is more than reasonable. Has a type like this 
> already been standardized or is there an example available somewhere?
> 
> I suppose yang-identifier type is too restrictive so I will agree that 
> restricting whitespace and colon chars
> is probably good enough 


I'm going to use:

  typedef tag {
type string {
  pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+';
  length "1..max";
}
description
  "A tag value is composed of a standard prefix followed
   by any string value that does not include carriage return,
   form-feed, newline or tab characters."
  }

I left in space -- lot's of people in the non-unix world use spaces.

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

Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

[Christian Hopps]

> On Oct 17, 2018, at 2:47 AM, Martin Bjorklund  wrote:
> 
> Hi,
> 
> Christian Hopps  wrote:
>> 
>> Andy Bierman  writes:
>>> 
>>> This draft needs to define the module-tag encoding wrt/
>>>   - valid characters (e.g., some subset of UTF-8)
>>>   - min/max length (e.g., implementation MUST support at least 64 chars
>>> and can support larger)
>> 
>> I'm looking for suggestions on how to do this subset. We had intended
>> to allow for as wide as possible content; however, I think disallowing
>> tabs, newlines, carriage returns is more than reasonable. Has a type
>> like this already been standardized or is there an example available
>> somewhere?
>> 
>>> Section 3 (Tag Prefixes) seems to imply that all modules tags follow a
>>> structure to specify the naming authority.
>>> 
>>> According to the YANG module, the data type is a plain string, which
>>> includes lots of
>>> problematic chars and zero-length strings.
>>> 
>>> Does the string "routing" match "ietf:routing" or "vendor:routing"?
>>> How
>>> about "routing:bgp"?
>> 
>> No. Do we need to state that non-matching strings don't match?
> 
> The word "match" is imo problematic.  Use "equal" if that's what you
> mean.  But you're not actually using the word "match" in the draft, so
> that's fine.  However, I think the draft can be clarified.  See below.
> 
> In this case, it _seems_ like there's some hierarchy with tags
> like:
> 
>  ietf:routing
>  ietf:routing:rib
> 
> For example, does ietf:routing:rib imply ietf:routing?
> 
> From your last emails, it seems that the idea is that tags are really
> just strings with the only property that they can be compared for
> equality.  If this is the case, I think it can be made more clear in
> the document.  And if this is the case, I think that type "string" is
> actually fine.  If someone wants to assign the tag
> "vendor:acme: ", let them.
> 
> OTOH, if the idea is that the tags are hierarchical, and
> ietf:routing-rib implies ietf:routing, then a more specific type is
> needed, and more text.

I'm going to remove the colons (except for the one in the prefix). This has 
caused a lot of confusion. It is as you say supposed to be free-form after the 
prefix. Yes, there was an implied structure being suggested, but there was no 
intention to try and standardize this structure. In the end it comes off as 
half-baked and confusing so better to remove it.

FWIW I originally envisioned a more flat tag space anyway, so ietf:routing and 
ietf:igp. I'm not sure how we ended up suggesting hierarchy. 

Thanks,
Chris.

> 
> 
> /martin
> 
> 
> 
>> 
>>> Is the char ":" allowed in a tag?
>> 
>> Yes, why not?
>> 
>>> Is "vendor" a valid tag?
>> 
>> Again why not?
>> 
>> The only thing the draft talks about are standard prefixes. Why should
>> a standard enumerate a subset of the unbounded set of things it isn't
>> standardizing? This seems more confusing (why was X included as OK but
>> not Y) than just sticking to what it *is* standardizing.
>> 
>> Perhaps a bit of text saying more explicitly that only the prefix is
>> restricted would help though?
>> 
>>> IMO this draft does not need to define any specific module-tag content
>>> but
>>> it does need to define
>>> in precise terms how a protocol encodes a module-tag and how a
>>> module-tag
>>> match is determined.
>> 
>> We considered leaving out all the predefined tags, but conversely we
>> also thought it would be useful to establish a base set. We went with
>> the latter obviously. Perhaps it just needs to be trimmed down more?
>> 
>> Thanks,
>> Chris.
>> 
>>> 
>>> 
>>> Thanks,
 Chris.
 
>>> 
>>> 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

Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

[Christian Hopps]

The point is to keep this open to however the community might end up choosing 
to use it. The act of pre-defining tags doesn't disallow other tags being 
defined, in fact at this point I've sent a bunch of email defending leaving 
things as open as possible. They both can co-exist. :)

Thanks,
Chris.

> On Oct 16, 2018, at 7:32 PM, Alex Campbell  wrote:
> 
> I have no issue with systems using tags to classify or organize modules, 
> however this seems to me like something that would be specific to the system 
> doing the classifying.

Sure we support this. That's what user tag configuration is there for.

> It would not be something that needs to be specified in the module itself 
> (except perhaps as freeform description text), and it certainly would not 
> need to involve the NETCONF server.
> What would a server do with module classification data? (unless it is also 
> implementing some kind of module browsing interface, in which case it might 
> be used to supply the browser with data)

The server implements the tags (at least the predefined ones), and the use 
cases that come to my mind at least involve clients not servers. I'm not saying 
there wouldn't be a server use case, but it's not as obvious to me. 

And yes implementing some kind of module browsing interface (which could group 
modules by tags) is a fine example of how tags can be used.

> 
> Hashtags - all types, that I'm aware of - are inherently freeform and fluid, 
> changing quickly according to the desires of users. I don't think it makes 
> sense to "hard-code" them in published RFCs or even published vendor modules 
> or firmware.
> 
> Tomorrow, I might want to list all modules for management plane protocols. As 
> a network operator, should I go and update the ietf-module-tags on all of my 
> network elements? That seems silly. This should be client-side data. (And if 
> I did, what happens when I add a new router and forget to update its tag 
> data? Will that confuse the client?)

I'm a bit confused by this. Not having to go add e.g., an "OAM" tag to modules 
is exactly the point of pre-defined tags, but you questioned their value at the 
top of your mail.

Either way configuring a newly installed router is a given, I don't think this 
is the place to solve the "forgot to add all the config to my new router 
install" issue. :) If one is using tags in ones network then making sure the 
newly installed router has tags configured the way you expect is no different 
from making sure that you configured IS-IS correctly.

Thanks,
Chris.

> 
> Regards, Alex
> 
> 
> From: Christian Hopps 
> Sent: Wednesday, 17 October 2018 1:04 a.m.
> To: Alex Campbell
> Cc: Christian Hopps; joel jaeggli; NETMOD Working Group
> Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 
> 10/16/18
> 
>> 
>> On Oct 3, 2018, at 8:22 PM, Alex Campbell  wrote:
>> 
>> The introduction does not explain what they are useful for
> 
> The second sentence of the abstract: "The expectation is for such tags to be 
> used to help classify and organize modules." The introduction repeats this in 
> the first sentence. I'm not sure how much differently we could say "Tags are 
> useful for organizing and classifying modules". Are you asking for 
> justification on the usefulness of organizing and classifying things? I think 
> this concept is rather widely accepted.
> 
> 
>> , it just makes a comparison to #hashtags (which is something I would expect 
>> to see in an April 1st RFC).
> 
> Using tags to help organize collections of data is literally ubiquitous: 
> Movies/music/media, IP routes, and yes even social media are just a few 
> examples.  Regarding April 1st, are you are unfairly restricting your 
> perspective to only the ironic use of hashtags? Hashtags organically 
> developed as a useful and widely used way for people and groups to add 
> meta-data to their messages which then allowed other services to collect and 
> present them in useful ways. Indeed businesses and other groups use hashtags 
> for this purpose to great success. It was hardly a joke, and for many folks 
> it is immediately useful to understand what is being proposed.
> 
> Thanks,
> Chris.
> 

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

Re: [netmod] WHEN statement within mandatory objects doesn't ensure presence of the mandatory object

[Ladislav Lhotka]

Michael Rehder  writes:

> I've read rfc6110 and I didn't see any mention of "WHEN" on the
> mandatory status (section 9.1.1 Optional and Mandatory Nodes doesn't
> list it which seems a bit odd to me).

RFC 6110 was being prepared along with RFC 6020, and section 9.1.1 is
closely related to sec. 3.1 in 6020.

> The section on "WHEN" just mentions the xpath mapping, not anything
> about changing the mandatory status of the enclosing node.

If you take into account the DSDL validation procedure (Figure 2 in RFC
6110) then everything is IMO clear:

- Mandatory nodes (as defined in sec. 9.1.1) are not wrapped in
   and thus are required during RELAX NG schema
  validation, no matter what any "when" expression says.

- Section 12.17 explains how when expressions are mapped to Schematron
  asserts. This means that if an instance node exists in the data and a
  when expression attached to the corresponding data node in YANG
  evaluates to false, Schematron will report a failed assert.

- Note that Schematron cannot by definition report absence of an
  instance based on the when expression attached to its data
  node: Schematron rules are only fired for elements that are present in
  the instance document. 

>
> I still think that the YANG RFC wording of "conditional" needs to indicate if 
> the node is mandatory status is affected or not.
> Note that rfc6060 "3.1 Mandatory Nodes" doesn't mention "WHEN" (it
> does mention presence).

Perhaps this thread is just about misunderstanding of what "when" really
means, which is: Instances for which the "when" expression evaluates to
false must not be present.

It does NOT mean that instances for which the "when" expression
evaluates to true must be present.

Lada

>
> Thanks
> Mike
>> -Original Message-
>> From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
>> Sent: Saturday, October 13, 2018 5:20 PM
>> To: Michael Rehder 
>> Cc: netmod@ietf.org
>> Subject: Re: [netmod] WHEN statement within mandatory objects doesn't
>> ensure presence of the mandatory object
>> 
>> On Fri, Oct 12, 2018 at 04:08:48PM +, Michael Rehder wrote:
>> 
>> > The mandatory statement in that case is ignored (I’ve pointed out the
>> > RNG and Schematron lack of enforcement).  WHEN trumps the mandatory
>> > status (via explicit mandatory or implicit mandatory via min-elements
>> > 1)
>> 
>> Has the RNG and Schematron been obtained following RFC 6110? If so, this may
>> be a problem with RFC 6110 but not with YANG itself. There are validators 
>> that
>> do not use RNG or Schematron.
>> 
>> /js
>> 
>> --
>> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103 
> “Amdocs’ email platform is based on a third-party, worldwide, cloud-based 
> system. Any emails sent to Amdocs will be processed and stored using such 
> system and are accessible by third party providers of such system on a 
> limited basis. Your sending of emails to Amdocs evidences your consent to the 
> use of such system and such processing, storing and access”.
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] Review comments for module-tags-02

[Christian Hopps]

> On Oct 17, 2018, at 12:09 AM, Rohit R Ranade  wrote:
> 
> 1. In the desrciption of leaf-list tag
>   "
>   The operational view of this list will contain all
>  user-configured tags as well as any predefined tags that
>  have not been masked by the user using the masked-tag leaf
>  list below.
>   "
>   ==> So the predefined tags, should be output as  origin  in 
>  ?
>   If so, I would suggest renaming them to "default" tags.

default has this in it's definition:
 
"The default origin is only used when the configuration has not been
 provided by any other source."

The predefined tags are being added due to the module definition or by the 
vendor implementing the module, and the user would be adding to this set (not 
replacing) when they configure tags (and thus the reason for the mask). So I 
think predefined tags should have "system" origin. We can add text to the 
document to clarify this if others agree.

> 2. For "masked-tag", if the purpose is to only mask "predefined" tags, why 
> not rename
> as masked-default-tag or masked-predefined-tag ?
> Also if a tag say tag-1 (not predefined) is added to this list, and tag-1 
> added to "tag", the tag-1
> will still be output in , which may look confusing to the user 
> as the tag-1 will exist
> in both "tag" and "masked-tag". Changing the "masked-tag" may help in this 
> case.

What's the compelling reason to make this more complex? Right now, the 
predefined tags are added, the configured tags are added, and then the masks 
are applied. KISS is the goal.

> 3.  It is still not clear, what is the use-case where user wants to "mask" a 
> predefined tag..

The user is the ultimate arbiter over their network is the point. On example is 
a vendor adds a tag indicating the module belongs to a certain category of 
modules which would enable it's use in that users network, but for whatever 
reason the user does not agree.

> 4. What about already existing modules which donot define the tags, should 
> they be output in the
>   "module-tags" list ? Or better to use "min-elements" for leaf-list "tags" ?

If they have no tags, there's no reason for them to be in the list, whether 
they come before or after the publication of this document (or after a device 
implements it). However, any client software is going to need to deal with no 
module entry, and also with an entry with no tags. I think it's better to stay 
away from adding restrictions that don't add real value, but do allow for 
software to "get it wrong".

> 5. I also agree with other reviewer's comment that this document must 
> standardize what a module-tag must look like.
>   Currently it only standardizes a prefix, if the rest of the tag is not 
> standardized a client has no way to parse
>   this tag.
>   Maybe we can say that a tag will contain 3 parts, 1st part is about 
> organization, 2nd part is about the whether it is service / element, 3rd part
>   can be a sub-category of part-2.

There's a lot of prior art here in leaving this open to however people want to 
use the meta-data (see routing admin-tags, media tags, social media tags, 
etc).. The reservation of prefix space allows for future definition if that 
ends up being needed. Users are free to define whatever structure they want if 
any. This discussion in particular was carried out over routing admin tags in 
the IETF and not pre-defining structure/meaning was the end result and has 
worked out well.

Thanks,
Chris.

>  
> With Regards,
> Rohit R
> ___
> 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] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)

[Martin Bjorklund]

Hi,

Eric Rescorla  wrote:
> OK, after reading your explanation and the example, I think I am clearer on
> the use case and the text you propose seems appropriate. Why don't you
> provide a new ID and I'll clear my DISCUSS

Thank you!  I have fixed this and uploaded a new version
(draft-ietf-netmod-schema-mount-12).


/martin


> 
> -Ekr
> 
> 
> On Tue, Oct 16, 2018 at 9:05 AM joel jaeggli  wrote:
> 
> > On 10/16/18 06:00, Eric Rescorla wrote:
> > > I'm sorry, but I still don't think I understand the security impacts of
> > > this well enough to know if this text is OK.
> > >
> > > Can you provide a more detailed explanation of what XPath expressions
> > > can and cannot do here? Happy to discuss live either on the phone or in
> > BKK
> > I'm probably grossly simplifying the goal here, but.
> >
> > xpath statement allow for referencing another path or applying
> > constraints e.g. when / must (rfc 6020)
> >
> > the canonical example in 6020 being something like
> >
> >   container interface {
> >   leaf ifType {
> >   type enumeration {
> >   enum ethernet;
> >   enum atm;
> >   }
> >   }
> >   leaf ifMTU {
> >   type uint32;
> >   }
> >   must "ifType != 'ethernet' or " +
> >"(ifType = 'ethernet' and ifMTU = 1500)" {
> >   error-message "An ethernet MTU must be 1500";
> >   }
> >   must "ifType != 'atm' or " +
> >"(ifType = 'atm' and ifMTU <= 17966 and ifMTU >= 64)" {
> >   error-message "An atm MTU must be  64 .. 17966";
> >   }
> >
> > http://www.yang-central.org/twiki/pub/Main/YangDocuments/rfc6020.html#xpath
> >
> > Imposing constraints using nodes in mounted modules is kind of a key
> > application of schema-mount.
> >
> > > -Ekr
> > >
> > >
> > > On Tue, Oct 16, 2018 at 5:45 AM Martin Bjorklund  > > > wrote:
> > >
> > > Hi,
> > >
> > > Eric Rescorla mailto:e...@rtfm.com>> wrote:
> > > > That seems like it's going to have some pretty surprising
> > > consequences and
> > > > at minimum needs more information in the Security Considerations.
> > >
> > > Ok.  Howabout we add a paragraph to the end of the Security
> > > Considerations section:
> > >
> > >   Care must be taken when the "parent-reference" XPath expressions
> > are
> > >   constructed, since the result of the evaluation of these
> > expressions
> > >   is added to the accessible tree for any XPath expression found in
> > >   the mounted schema.
> > >
> > >
> > > /martin
> > >
> > > > On Thu, Oct 11, 2018 at 12:18 AM Martin Bjorklund  > > > wrote:
> > > >
> > > > > Eric Rescorla mailto:e...@rtfm.com>> wrote:
> > > > > > I'm sorry but I don't understand this.
> > > > > >
> > > > > > Does the externally visible behavior of any mounted module
> > > depend in any
> > > > > > way on these XPATH references
> > > > >
> > > > > Yes, but note that these XPath expressions ("parent-reference")
> > are
> > > > > read-only (config false in the YANG model).  Thus they are set
> > > by the
> > > > > implementation, and used to inform the operator about the
> > > environment
> > > > > in which other XPath expressions are evaluated.
> > > > >
> > > > >
> > > > > /martin
> > > > >
> > > > >
> > > > > >
> > > > > > -Ekr
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, Oct 10, 2018 at 6:38 AM Martin Bjorklund
> > > mailto:m...@tail-f.com>> wrote:
> > > > > >
> > > > > > > Eric Rescorla mailto:e...@rtfm.com>> wrote:
> > > > > > > > On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund
> > > mailto:m...@tail-f.com>>
> > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > Eric Rescorla mailto:e...@rtfm.com>>
> > wrote:
> > > > > > > > > > Eric Rescorla has entered the following ballot
> > > position for
> > > > > > > > > > draft-ietf-netmod-schema-mount-11: Discuss
> > > > > > > > > >
> > > > > > > > > > When responding, please keep the subject line intact
> > > and reply
> > > > > to all
> > > > > > > > > > email addresses included in the To and CC lines. (Feel
> > > free to
> > > > > cut
> > > > > > > this
> > > > > > > > > > introductory paragraph, however.)
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Please refer to
> > > > > > > > >
> > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > > > > > > > > for more information about IESG DISCUSS and COMMENT
> > > positions.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > The document, along with other ballot positions, can
> > > be found
> > > > > here:
> > > > > > > > > >
> > > https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
> > > > > > > > > >

[netmod] I-D Action: draft-ietf-netmod-schema-mount-12.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

Title   : YANG Schema Mount
Authors : Martin Bjorklund
  Ladislav Lhotka
Filename: draft-ietf-netmod-schema-mount-12.txt
Pages   : 28
Date: 2018-10-17

Abstract:
   This document defines a mechanism to add the schema trees defined by
   a set of YANG modules onto a mount point defined in the schema tree
   in some YANG module.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-12
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-schema-mount-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-schema-mount-12


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

Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

[Martin Bjorklund]

Alex Campbell  wrote:
> I have no issue with systems using tags to classify or organize
> modules, however this seems to me like something that would be
> specific to the system doing the classifying.
> It would not be something that needs to be specified in the module
> itself (except perhaps as freeform description text), and it certainly
> would not need to involve the NETCONF server.
> What would a server do with module classification data?

It would use it to populate the "/module-tags" list in the operational
state, where operators can read the tags.


/martin

> (unless it is
> also implementing some kind of module browsing interface, in which
> case it might be used to supply the browser with data)
> 
> Hashtags - all types, that I'm aware of - are inherently freeform and
> fluid, changing quickly according to the desires of users. I don't
> think it makes sense to "hard-code" them in published RFCs or even
> published vendor modules or firmware.
> 
> Tomorrow, I might want to list all modules for management plane
> protocols. As a network operator, should I go and update the
> ietf-module-tags on all of my network elements? That seems silly. This
> should be client-side data. (And if I did, what happens when I add a
> new router and forget to update its tag data? Will that confuse the
> client?)
> 
> Regards, Alex
> 
> 
> From: Christian Hopps 
> Sent: Wednesday, 17 October 2018 1:04 a.m.
> To: Alex Campbell
> Cc: Christian Hopps; joel jaeggli; NETMOD Working Group
> Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18
> - 10/16/18
> 
> >
> > On Oct 3, 2018, at 8:22 PM, Alex Campbell 
> > wrote:
> >
> > The introduction does not explain what they are useful for
> 
> The second sentence of the abstract: "The expectation is for such tags
> to be used to help classify and organize modules." The introduction
> repeats this in the first sentence. I'm not sure how much differently
> we could say "Tags are useful for organizing and classifying
> modules". Are you asking for justification on the usefulness of
> organizing and classifying things? I think this concept is rather
> widely accepted.
> 
> 
> > , it just makes a comparison to #hashtags (which is something I would
> > expect to see in an April 1st RFC).
> 
> Using tags to help organize collections of data is literally
> ubiquitous: Movies/music/media, IP routes, and yes even social media
> are just a few examples.  Regarding April 1st, are you are unfairly
> restricting your perspective to only the ironic use of hashtags?
> Hashtags organically developed as a useful and widely used way for
> people and groups to add meta-data to their messages which then
> allowed other services to collect and present them in useful
> ways. Indeed businesses and other groups use hashtags for this purpose
> to great success. It was hardly a joke, and for many folks it is
> immediately useful to understand what is being proposed.
> 
> Thanks,
> Chris.
> 
> ___
> 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] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

[Martin Bjorklund]

Hi,

Christian Hopps  wrote:
> 
> Andy Bierman  writes:
> >
> > This draft needs to define the module-tag encoding wrt/
> >- valid characters (e.g., some subset of UTF-8)
> >- min/max length (e.g., implementation MUST support at least 64 chars
> > and can support larger)
> 
> I'm looking for suggestions on how to do this subset. We had intended
> to allow for as wide as possible content; however, I think disallowing
> tabs, newlines, carriage returns is more than reasonable. Has a type
> like this already been standardized or is there an example available
> somewhere?
> 
> > Section 3 (Tag Prefixes) seems to imply that all modules tags follow a
> > structure to specify the naming authority.
> >
> > According to the YANG module, the data type is a plain string, which
> > includes lots of
> > problematic chars and zero-length strings.
> >
> > Does the string "routing" match "ietf:routing" or "vendor:routing"?
> > How
> > about "routing:bgp"?
> 
> No. Do we need to state that non-matching strings don't match?

The word "match" is imo problematic.  Use "equal" if that's what you
mean.  But you're not actually using the word "match" in the draft, so
that's fine.  However, I think the draft can be clarified.  See below.

In this case, it _seems_ like there's some hierarchy with tags
like:

  ietf:routing
  ietf:routing:rib

For example, does ietf:routing:rib imply ietf:routing?

>From your last emails, it seems that the idea is that tags are really
just strings with the only property that they can be compared for
equality.  If this is the case, I think it can be made more clear in
the document.  And if this is the case, I think that type "string" is
actually fine.  If someone wants to assign the tag
"vendor:acme: ", let them.

OTOH, if the idea is that the tags are hierarchical, and
ietf:routing-rib implies ietf:routing, then a more specific type is
needed, and more text.


/martin



> 
> > Is the char ":" allowed in a tag?
> 
> Yes, why not?
> 
> > Is "vendor" a valid tag?
> 
> Again why not?
> 
> The only thing the draft talks about are standard prefixes. Why should
> a standard enumerate a subset of the unbounded set of things it isn't
> standardizing? This seems more confusing (why was X included as OK but
> not Y) than just sticking to what it *is* standardizing.
> 
> Perhaps a bit of text saying more explicitly that only the prefix is
> restricted would help though?
> 
> > IMO this draft does not need to define any specific module-tag content
> > but
> > it does need to define
> > in precise terms how a protocol encodes a module-tag and how a
> > module-tag
> > match is determined.
> 
> We considered leaving out all the predefined tags, but conversely we
> also thought it would be useful to establish a base set. We went with
> the latter obviously. Perhaps it just needs to be trimmed down more?
> 
> Thanks,
> Chris.
> 
> >
> >
> > Thanks,
> >> Chris.
> >>
> >
> > 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