[netmod] Review comments for module-tags-02

[Rohit R Ranade]

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.

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.

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

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

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.

With Regards,
Rohit R
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Qin Wu]

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] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

[Andy Bierman]

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


> 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 official prefixes and colon char lead people to believe the string is
structured.
Intelligent searches on sub-sfields might be purpose of such structure. Or
not I guess.


> Is the char ":" allowed in a tag?
>>
>
> Yes, why not?
>

Because it confuses people who think the colon character has special
meaning in this string



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


I think the registry details have to be there to populate the IANA
registery



>
> Thanks,
> Chris.
>
>
>>
>> Thanks,
>>
>>> Chris.
>>>
>>>
>> Andy
>>
>
>
Andy
___
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

[Alex Campbell]

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

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

[Christian Hopps]

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?


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

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

[Kent Watsen]

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_mailman_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] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)

[joel jaeggli]

On 10/16/18 14:51, 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

Thanks I think the authors will have that out shortly.

joel

> -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
> mailto:m...@tail-f.com>
> >     >> 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
> 

Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)

[Eric Rescorla]

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

-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/
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > >
> >
>  --
> > > > > > > > > DISCUSS:
> > > > > > > > >
> > > > > >
> >
>  --
> > > > > > > > >
> > > > > > > > > Rich version of this review at:
> > > > > > > > > 

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

[Adrian Farrel]

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
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
> 
> 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://www.ietf.org/mailman/listinfo/netmod

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

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

[Lou Berger]

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
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

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://www.ietf.org/mailman/listinfo/netmod

[netmod] The NETMOD WG has placed draft-kwatsen-netmod-artwork-folding in state "Candidate for WG Adoption"

[IETF Secretariat]

The NETMOD WG has placed draft-kwatsen-netmod-artwork-folding in state
Candidate for WG Adoption (entered by Lou Berger)

The document is available at
https://datatracker.ietf.org/doc/draft-kwatsen-netmod-artwork-folding/

Comment:
IPR poll started:

___
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

[Andy Bierman]

On Tue, Oct 16, 2018 at 12:42 PM, Christian Hopps  wrote:

>
> Andy Bierman  writes:
>
> On Tue, Oct 16, 2018 at 6:08 AM, Juergen Schoenwaelder <
>> j.schoenwael...@jacobs-university.de> wrote:
>>
>> On Tue, Oct 16, 2018 at 08:31:43AM -0400, Christian Hopps wrote:
>>> >
>>> > On Oct 2, 2018, at 4:30 PM, Juergen Schoenwaelder <
>>> j.schoenwael...@jacobs-university.de> wrote:
>>>
>>> > > - Standard tags defined in description statements
>>> > >
>>> > >  I do not like this. YANG has extension statements and having to
>>> > >  parse stuff out of free text description statements seems to be a
>>> > >  movement backwards.
>>> >
>>> > This is used by the human implementer of the module (i.e., they need to
>>> write code to implement the module). As such it was not intended for
>>> machine parsing.
>>> >
>>>
>>> I am personally not convinced. The whole reason why we have YANG is
>>> automation and I believe people will go and write tools to extract
>>> tags and having to extract them out of free form text looks like a
>>> step backwards.
>>>
>>>
>>
>> It is more than a step backwards.
>> There is an unexplained procedure for declaring the  module-tag
>> conformance,
>> in addition to the module-tag mappings.
>>
>> All YANG designers are supposed to learn the exact text to write (not
>> free-form at all)
>> and this draft updates 6087bis with procedures for declaring the
>> module-tags
>> in the description-stmt.
>>
>> Also, tool developers are supposed to parse the description-stmt looking
>> for the
>> module-tag definitions. But instead, tool developers are going to say "Use
>> our
>> proprietary YANG extension because we are never going to parse description
>> statements"
>>
>
> I've added the extension statement.
>

good


>
> > > - System management
>>> > >
>>> > >  What is 'system management' and a 'system management protocol'?
>>> >
>>> > These were derived from the work the RtgYangDT originally did where we
>>> were organizing everything under a single device tree. This tree concept
>>> was (rightly) abandoned to be replaced with use of tags. Examples of
>>> protocols would be Syslog, TACAC+, SNMP, Netconf, ... I've added that to
>>> the description.
>>> >
>>>
>>> I am generally not a fan of definition by example. Is SSH a 'system
>>> management protocol'?
>>>
>>>
>>
>> An example is not a definition.
>> The IETF is supposed to know the difference.
>>
>
> Do you have some suggestions for text that could replace the examples?
>
> Some of these things seem painful obvious, like do we *really* need to
> define what we mean by a routing protocol?
>
>

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)

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"?
Is the char ":" allowed in a tag?
Is "vendor" a valid tag?

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.


Thanks,
> Chris.
>

Andy
___
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]

Andy Bierman  writes:


On Tue, Oct 16, 2018 at 6:08 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:


On Tue, Oct 16, 2018 at 08:31:43AM -0400, Christian Hopps wrote:
>
> On Oct 2, 2018, at 4:30 PM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> > - Standard tags defined in description statements
> >
> >  I do not like this. YANG has extension statements and having to
> >  parse stuff out of free text description statements seems to be a
> >  movement backwards.
>
> This is used by the human implementer of the module (i.e., they need to
write code to implement the module). As such it was not intended for
machine parsing.
>

I am personally not convinced. The whole reason why we have YANG is
automation and I believe people will go and write tools to extract
tags and having to extract them out of free form text looks like a
step backwards.




It is more than a step backwards.
There is an unexplained procedure for declaring the  module-tag conformance,
in addition to the module-tag mappings.

All YANG designers are supposed to learn the exact text to write (not
free-form at all)
and this draft updates 6087bis with procedures for declaring the module-tags
in the description-stmt.

Also, tool developers are supposed to parse the description-stmt looking
for the
module-tag definitions. But instead, tool developers are going to say "Use
our
proprietary YANG extension because we are never going to parse description
statements"


I've added the extension statement.


> > - System management
> >
> >  What is 'system management' and a 'system management protocol'?
>
> These were derived from the work the RtgYangDT originally did where we
were organizing everything under a single device tree. This tree concept
was (rightly) abandoned to be replaced with use of tags. Examples of
protocols would be Syslog, TACAC+, SNMP, Netconf, ... I've added that to
the description.
>

I am generally not a fan of definition by example. Is SSH a 'system
management protocol'?




An example is not a definition.
The IETF is supposed to know the difference.


Do you have some suggestions for text that could replace the examples?

Some of these things seem painful obvious, like do we *really* need to define 
what we mean by a routing protocol?

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]

Juergen Schoenwaelder  writes:


On Tue, Oct 16, 2018 at 08:31:43AM -0400, Christian Hopps wrote:


On Oct 2, 2018, at 4:30 PM, Juergen Schoenwaelder 
 wrote:



> - Standard tags defined in description statements
>
>  I do not like this. YANG has extension statements and having to
>  parse stuff out of free text description statements seems to be a
>  movement backwards.

This is used by the human implementer of the module (i.e., they need to write 
code to implement the module). As such it was not intended for machine parsing.



I am personally not convinced. The whole reason why we have YANG is
automation and I believe people will go and write tools to extract
tags and having to extract them out of free form text looks like a
step backwards.


I've now added an "module-tag" extension statement.


> - Tag format
>
>  Apparently, the colon has a special meaning in a tag string and
>  otherwise there do not seem to be any restrictions. (Which is good,
>  I can finally put various smileys on my gear.)
>
>  Should we state explicitly somewhere that a colon has a special
>  meaning and that tag strings are structured into a sequence of
>  'taggies' separated by colons? Or is definition by example good
>  enough?

I think it's good enough. :)


I am not convinced this will work well. My understanding is that other
'hashtags' also have restrictions - whitespace and punctuation
characters are often excluded, it seems. Apparently ':' already means
something special here. Should you later need more special meanings,
you will love to have characters available that you can use. What
about tags that include whitespace or control characters? Do we really
want such tags?


I *really* want to stay away from over-specifying (over-complicating) this by imposing a 
lot of structure and rules. The text uses ":"s suggestively, but I'd rather 
remove that than start down the path of standardizing additional structure.

It probably would be useful to restrict the actual characters used in the 
string to avoid odd whitespace (e.g., tabs, newlines/carriage returns). Is 
there a standard type that just leaves these specific whitespace characters 
out? I was hesitant to just use something like yang identifier b/c I figured it 
might be useful for people to include non-ascii-like characters (umlats etc..)

Thanks,
Chris.


> - Meaning of tag masks
>
>  Do masks mean a complete string match or can I mask along the prefix
>  hierarchy, i.e., 'vendor:acme:' masks everything starting with
>  'vendor:acme:'?

Exact match, I've added text to clarify this.


OK. One obvious extension is then to have at some point in time tag
match expressions, such as 'vendor:acme:*' (assuming that * is not
a valid character for a tag, see above).

/js


___
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

[Andy Bierman]

On Tue, Oct 16, 2018 at 6:08 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Tue, Oct 16, 2018 at 08:31:43AM -0400, Christian Hopps wrote:
> >
> > On Oct 2, 2018, at 4:30 PM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
>
> > > - Standard tags defined in description statements
> > >
> > >  I do not like this. YANG has extension statements and having to
> > >  parse stuff out of free text description statements seems to be a
> > >  movement backwards.
> >
> > This is used by the human implementer of the module (i.e., they need to
> write code to implement the module). As such it was not intended for
> machine parsing.
> >
>
> I am personally not convinced. The whole reason why we have YANG is
> automation and I believe people will go and write tools to extract
> tags and having to extract them out of free form text looks like a
> step backwards.
>


It is more than a step backwards.
There is an unexplained procedure for declaring the  module-tag conformance,
in addition to the module-tag mappings.

All YANG designers are supposed to learn the exact text to write (not
free-form at all)
and this draft updates 6087bis with procedures for declaring the module-tags
in the description-stmt.

Also, tool developers are supposed to parse the description-stmt looking
for the
module-tag definitions. But instead, tool developers are going to say "Use
our
proprietary YANG extension because we are never going to parse description
statements"


> > > - System management
> > >
> > >  What is 'system management' and a 'system management protocol'?
> >
> > These were derived from the work the RtgYangDT originally did where we
> were organizing everything under a single device tree. This tree concept
> was (rightly) abandoned to be replaced with use of tags. Examples of
> protocols would be Syslog, TACAC+, SNMP, Netconf, ... I've added that to
> the description.
> >
>
> I am generally not a fan of definition by example. Is SSH a 'system
> management protocol'?
>


An example is not a definition.
The IETF is supposed to know the difference.



>
> > > - Tag format
> > >
> > >  Apparently, the colon has a special meaning in a tag string and
> > >  otherwise there do not seem to be any restrictions. (Which is good,
> > >  I can finally put various smileys on my gear.)
> > >
> > >  Should we state explicitly somewhere that a colon has a special
> > >  meaning and that tag strings are structured into a sequence of
> > >  'taggies' separated by colons? Or is definition by example good
> > >  enough?
> >
> > I think it's good enough. :)
>
> I am not convinced this will work well. My understanding is that other
> 'hashtags' also have restrictions - whitespace and punctuation
> characters are often excluded, it seems. Apparently ':' already means
> something special here. Should you later need more special meanings,
> you will love to have characters available that you can use. What
> about tags that include whitespace or control characters? Do we really
> want such tags?
>


Section 3 defines prefixes for different types of module tags
There is no actual definition of a module tag.
Is it UTF-8 encoding? US-ASCII? Is it structured such that a pattern could
be defined?
Is every protocol draft that uses module-tags somehow going to define their
own version?

I don't see how this draft provides enough interoperability to be useful.


> > > - Meaning of tag masks
> > >
> > >  Do masks mean a complete string match or can I mask along the prefix
> > >  hierarchy, i.e., 'vendor:acme:' masks everything starting with
> > >  'vendor:acme:'?
> >
> > Exact match, I've added text to clarify this.
>
> OK. One obvious extension is then to have at some point in time tag
> match expressions, such as 'vendor:acme:*' (assuming that * is not
> a valid character for a tag, see above).
>
> /js
>
>

Andy


> --
> 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] mbj's WGLC review of module-tags-02

[Christian Hopps]

Martin Bjorklund  writes:


Hi,

Here are my (mostly editorial) WGLC comments on
draft-ietf-netmod-module-tags-02:


o  add boilerplate reference to RFC 8340


Done.


o  2

  Use 8174 boilerplate


Done.


o  4.1

A module definition SHOULD indicate a set of tags to be automatically
added by the module implementer.

  I think statement doesn't belong here, but rather to section 7
  (which also has this statement already)


When I remove that sentence the paragraph doesn't really read well. I have 
slightly modified the text to adapt to use of a module-tag extension statement 
though.



  And how are the tags supposed to be "automatically added"?


In their code presumably. :)


  As I have written in previous discussions, and others as well, I
  think that you should define a YANG extension that can be used to
  define the tags, instead of relying on description statements.  Is
  there a reason why you think an extension statement wouldn't work?


It just all seemed overly complex for indicating something that a human has to 
add by hand anyway (in their code). I will add this as it seems to be a 
sticking point that multiple people have requested as you indicate.


o  4.1


  OLD:

   If the module definition will be
   standard the tags MUST also be standard tags (Section 3.1).

  NEW:

   If the module definition will be
   IETF standards track, the tags MUST also be IETF standard tags
   (Section 3.1).


Done.


o  4.3

Implementations MUST ensure that a modules tag list is consistent
across any location from which the list is accessible.  So if a user
adds a tag through configuration that tag should also be seen when
using any augmentation that exposes the modules tag list.

  I don't understand the last sentence.  What kind of augmentation do
  you mean?


Mentioned this in another reply, this is left-over text for when we had exposed 
the module tags in mulitiple places (i.e., a read-only list through augmenting 
yang library). I've removed the text as it's now confusing.


o  5.1

  OLD:

The tree associated with the tags module is:

  NEW:

The tree associated with the "ietf-module-tags" module is:


Done.


o  5.1

  I know this has been discussed before, and Juergen wanted plural
  names, but I propose the following structure:

   +--rw module-tags
  +--rw module* [name]
 +--rw name  yang:yang-identifier
 +--rw tag*  string
 +--rw masked-tag*   string


  I prefer a container an the top level over a list.  Also with the
  list called "module", the key can be called just "name".  And
  leaf-lists (and lists) usually have names in singular.


Ok I've adopted this.


o  5.2

 I think the YANG version should be 1.1.


But nothing in this module requires 1.1 features, so why restrict its use to 
1.1 only?


 Add the standard boilerplate to the YANG module.


Done.


o  5.2 leaf name

"The YANG module or submodule name.";

  Do we really want to attach tags to submodules, or should the tags
  only be visisble for the module?


Modules, I've changed the text.



o  5.2  type for tag

leaf-list tag {
type string;

  Can I use *any* string as a tag?  No limitations at all?  Is ":"
  special in a tag?


The only thing special in the tag is the prefix. The document is suggestive in it's use of 
secondary ":"s; however, I see no reason to "over-specify" (i.e., 
over-complicate) this.


o  5.2

  The module should be consistently formatted wrt whitespaces.

  (e.g., you can try pyang --keep-comments -f yang)


Done.


o  6

  s/yang/YANG/


Done.


o  6 and 3.3

  When I read 3.3 I thought that the word "local" seemed odd, and was
  going to suggest "user" instead.  It seems 8199 also uses
  standard/vendor/user.  So, I suggest we change "local tags" to "user
  tags".


Prior art, OK, Done.


o  7.1

   The module writer may use existing standard tags, or use new tags
   defined in the model definition, as appropriate.  New tags should be
   assigned in the IANA registry defined below, see Section 8.2 below.

  Hmm, once the "new" tags are defined, they are IETF standard tags,
  right?  So this text should really be:

   The module writer must use only IETF standard tags

  and also write that if new tags are needed, they MUST be
  registered.


The intention was that the module author could use non-standardized tags if the 
module itself was not standardized.  The text now reads:

   The module writer may use existing standard tags, or use new
   tags defined in the model definition, as appropriate. For
   standardized modules new tags MUST be assigned in the IANA
   registry defined below, see 
   below.


o  8.2

  Remove the Editor's note.


Done.



o  8.2

  Why have both ietf:rfc8199:service and ietf:network-service?


They are different. A network-service is something like a DHCP server. I've 
added examples (NTP server, DHCP server, DNS server) to the description.


o  

Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)

[joel jaeggli]

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/
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > >
> --
> > > > > > > > DISCUSS:
> > > > > > > >
> > > > >
> --
> > > > > > > >
> > > > > > > > Rich version of this review at:
> > > > > > > > https://mozphab-ietf.devsvcdev.mozaws.net/D3506
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > DETAIL
> > > > > > > > S 4.
> > > > > > > > >
> > > > > > > > >      It is worth emphasizing that the nodes specified in
> > > > > > > > >      "parent-reference" leaf-list are available in
> the mounted
> > > > > schema
> > > > > > > only
> > > > > > > > >      for XPath evaluations.  In particular, they
> cannot be
> > > accessed
> > > > > > > there
>   

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

[Robert Wilton]

Hi Mike,


On 16/10/2018 16:34, Michael Rehder wrote:


Ok, so it is there in the RFC, just somewhat separated (in my view) 
from the definition of “when”.


I still am somewhat surprised by this implementation.

Far more often the I see a need to enforce the presence of a variant.

I'm sorry, but I still haven't seen you provide any concrete example in 
YANG where this is useful.


Early in the thread you provided an example with static/dynamic IP 
addresses, and wrote 'There is no way in the IPAddresses list to enforce 
that there is at least one IP Address when the assignment method is 
"Static".'.  But as I replied previously, for YANG at least, this 
statement is wrong since your YANG achieves exactly that constraint!


Specifically, if you have a server that implements the YANG module that 
you provided and a client attempted to configure it via NETCONF or 
RESTCONF then the server would enforce that either the assignment is 
DHCP or at least one static IP address is provided, otherwise the config 
change would be rejected.


I think that your issue may be more with how the YANG is translated via 
the methods in RFC 6110 (which I am not familiar with), but that doesn't 
mean that there is a problem with the YANG definition itself.  Allowing 
mandatory/min-elements/max-elements to have precedence over 'when' 
doesn't make much sense to me, I'm missing a concrete example where it 
seems that this would be useful, certainly your IP address example does 
not require it.


Thanks,
Rob



Thanks

Mike

*From:*Robert Wilton [mailto:rwil...@cisco.com]
*Sent:* Tuesday, October 16, 2018 9:42 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


Hi Mike,

On 16/10/2018 14:26, Michael Rehder wrote:

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

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

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

By YANG RFC do you mean RFC 6020/7950?

Section 8.1 of RFC 7950 states the following constraints apply on 
valid data trees:


    o  There MUST be no nodes tagged with "when" present if the "when"
   condition evaluates to "false" in the data tree.
    o  The "mandatory" constraint is enforced for leafs and choices,
   unless the node or any of its ancestors has a "when" condition or
   "if-feature" expression that evaluates to "false".
    o  The "min-elements" and "max-elements" constraints are enforced for
   lists and leaf-lists, unless the node or any of its ancestors has
   a "when" condition or "if-feature" expression that evaluates to
   "false".
These rules indicate that "when" trumps "mandatory", "min-elements" and 
"max-elements".
Thanks,
Rob
  


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 

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

[Michael Rehder]

Ok, so it is there in the RFC, just somewhat separated (in my view) from the 
definition of “when”.

I still am somewhat surprised by this implementation.
Far more often the I see a need to enforce the presence of a variant.

Thanks
Mike

From: Robert Wilton [mailto:rwil...@cisco.com]
Sent: Tuesday, October 16, 2018 9:42 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


Hi Mike,

On 16/10/2018 14:26, Michael Rehder wrote:

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

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



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).
By YANG RFC do you mean RFC 6020/7950?

Section 8.1 of RFC 7950 states the following constraints apply on valid data 
trees:

   o  There MUST be no nodes tagged with "when" present if the "when"

  condition evaluates to "false" in the data tree.



   o  The "mandatory" constraint is enforced for leafs and choices,

  unless the node or any of its ancestors has a "when" condition or

  "if-feature" expression that evaluates to "false".



   o  The "min-elements" and "max-elements" constraints are enforced for

  lists and leaf-lists, unless the node or any of its ancestors has

  a "when" condition or "if-feature" expression that evaluates to

  "false".



These rules indicate that "when" trumps "mandatory", "min-elements" and 
"max-elements".



Thanks,

Rob









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

“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

[netmod] mbj's WGLC review of module-tags-02

[Martin Bjorklund]

Hi,

Here are my (mostly editorial) WGLC comments on
draft-ietf-netmod-module-tags-02:


o  add boilerplate reference to RFC 8340

o  2

  Use 8174 boilerplate


o  4.1

A module definition SHOULD indicate a set of tags to be automatically
added by the module implementer.

  I think statement doesn't belong here, but rather to section 7
  (which also has this statement already)

  And how are the tags supposed to be "automatically added"?

  As I have written in previous discussions, and others as well, I
  think that you should define a YANG extension that can be used to
  define the tags, instead of relying on description statements.  Is
  there a reason why you think an extension statement wouldn't work?

o  4.1


  OLD:

   If the module definition will be
   standard the tags MUST also be standard tags (Section 3.1).

  NEW:

   If the module definition will be
   IETF standards track, the tags MUST also be IETF standard tags
   (Section 3.1).


o  4.3

Implementations MUST ensure that a modules tag list is consistent
across any location from which the list is accessible.  So if a user
adds a tag through configuration that tag should also be seen when
using any augmentation that exposes the modules tag list.

  I don't understand the last sentence.  What kind of augmentation do
  you mean?



o  5.1

  OLD:

The tree associated with the tags module is:

  NEW:

The tree associated with the "ietf-module-tags" module is:


o  5.1

  I know this has been discussed before, and Juergen wanted plural
  names, but I propose the following structure:

   +--rw module-tags
  +--rw module* [name]
 +--rw name  yang:yang-identifier
 +--rw tag*  string
 +--rw masked-tag*   string


  I prefer a container an the top level over a list.  Also with the
  list called "module", the key can be called just "name".  And
  leaf-lists (and lists) usually have names in singular.


o  5.2

 I think the YANG version should be 1.1.

 Add the standard boilerplate to the YANG module.


o  5.2 leaf name

"The YANG module or submodule name.";

  Do we really want to attach tags to submodules, or should the tags
  only be visisble for the module?


o  5.2  type for tag

leaf-list tag {
type string;

  Can I use *any* string as a tag?  No limitations at all?  Is ":"
  special in a tag?


o  5.2

  The module should be consistently formatted wrt whitespaces.

  (e.g., you can try pyang --keep-comments -f yang)


o  6

  s/yang/YANG/


o  6 and 3.3

  When I read 3.3 I thought that the word "local" seemed odd, and was
  going to suggest "user" instead.  It seems 8199 also uses
  standard/vendor/user.  So, I suggest we change "local tags" to "user
  tags".


o  7.1

   The module writer may use existing standard tags, or use new tags
   defined in the model definition, as appropriate.  New tags should be
   assigned in the IANA registry defined below, see Section 8.2 below.

  Hmm, once the "new" tags are defined, they are IETF standard tags,
  right?  So this text should really be:

   The module writer must use only IETF standard tags

  and also write that if new tags are needed, they MUST be
  registered.


o  8.2

  Remove the Editor's note.


o  8.2

  Why have both ietf:rfc8199:service and ietf:network-service?


o  References

  You need to add RFC 7950 as a normative ref since you define a YANG
  module.



/martin

___
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

[Robert Wilton]

Hi Mike,


On 16/10/2018 14:26, Michael Rehder wrote:

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).
The section on "WHEN" just mentions the xpath mapping, not anything about 
changing the mandatory status of the enclosing node.

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

By YANG RFC do you mean RFC 6020/7950?

Section 8.1 of RFC 7950 states the following constraints apply on valid 
data trees:


   o  There MUST be no nodes tagged with "when" present if the "when"
  condition evaluates to "false" in the data tree.

   o  The "mandatory" constraint is enforced for leafs and choices,
  unless the node or any of its ancestors has a "when" condition or
  "if-feature" expression that evaluates to "false".

   o  The "min-elements" and "max-elements" constraints are enforced for
  lists and leaf-lists, unless the node or any of its ancestors has
  a "when" condition or "if-feature" expression that evaluates to
  "false".

These rules indicate that "when" trumps "mandatory", "min-elements" and 
"max-elements".

Thanks,
Rob
 



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


___
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

[Michael Rehder]

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).
The section on "WHEN" just mentions the xpath mapping, not anything about 
changing the mandatory status of the enclosing node.

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

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

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

[Juergen Schoenwaelder]

On Tue, Oct 16, 2018 at 08:31:43AM -0400, Christian Hopps wrote:
> 
> On Oct 2, 2018, at 4:30 PM, Juergen Schoenwaelder 
>  wrote:

> > - Standard tags defined in description statements
> > 
> >  I do not like this. YANG has extension statements and having to
> >  parse stuff out of free text description statements seems to be a
> >  movement backwards.
> 
> This is used by the human implementer of the module (i.e., they need to write 
> code to implement the module). As such it was not intended for machine 
> parsing.
>

I am personally not convinced. The whole reason why we have YANG is
automation and I believe people will go and write tools to extract
tags and having to extract them out of free form text looks like a
step backwards.

> > - System management
> > 
> >  What is 'system management' and a 'system management protocol'?
> 
> These were derived from the work the RtgYangDT originally did where we were 
> organizing everything under a single device tree. This tree concept was 
> (rightly) abandoned to be replaced with use of tags. Examples of protocols 
> would be Syslog, TACAC+, SNMP, Netconf, ... I've added that to the 
> description.
>

I am generally not a fan of definition by example. Is SSH a 'system
management protocol'?

> > - Tag format
> > 
> >  Apparently, the colon has a special meaning in a tag string and
> >  otherwise there do not seem to be any restrictions. (Which is good,
> >  I can finally put various smileys on my gear.)
> > 
> >  Should we state explicitly somewhere that a colon has a special
> >  meaning and that tag strings are structured into a sequence of
> >  'taggies' separated by colons? Or is definition by example good
> >  enough?
> 
> I think it's good enough. :)

I am not convinced this will work well. My understanding is that other
'hashtags' also have restrictions - whitespace and punctuation
characters are often excluded, it seems. Apparently ':' already means
something special here. Should you later need more special meanings,
you will love to have characters available that you can use. What
about tags that include whitespace or control characters? Do we really
want such tags?

> > - Meaning of tag masks
> > 
> >  Do masks mean a complete string match or can I mask along the prefix
> >  hierarchy, i.e., 'vendor:acme:' masks everything starting with
> >  'vendor:acme:'?
> 
> Exact match, I've added text to clarify this.

OK. One obvious extension is then to have at some point in time tag
match expressions, such as 'vendor:acme:*' (assuming that * is not
a valid character for a tag, see above).

/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] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)

[Eric Rescorla]

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

-Ekr


On Tue, Oct 16, 2018 at 5:45 AM Martin Bjorklund  wrote:

> Hi,
>
> Eric Rescorla  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  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 
> wrote:
> > > >
> > > > > Eric Rescorla  wrote:
> > > > > > On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund  >
> > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > Eric Rescorla  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/
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > >
> --
> > > > > > > > DISCUSS:
> > > > > > > >
> > > > >
> --
> > > > > > > >
> > > > > > > > Rich version of this review at:
> > > > > > > > https://mozphab-ietf.devsvcdev.mozaws.net/D3506
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > DETAIL
> > > > > > > > S 4.
> > > > > > > > >
> > > > > > > > >  It is worth emphasizing that the nodes specified in
> > > > > > > > >  "parent-reference" leaf-list are available in the
> mounted
> > > > > schema
> > > > > > > only
> > > > > > > > >  for XPath evaluations.  In particular, they cannot be
> > > accessed
> > > > > > > there
> > > > > > > > >  via network management protocols such as NETCONF
> > > [RFC6241] or
> > > > > > > > >  RESTCONF [RFC8040].
> > > > > > > >
> > > > > > > > What are the security implications of this XPath reference
> > > outside
> > > > > the
> > > > > > > > mount jail? Specifically, how does it interact with the
> access
> > > > > control
> > > > > > > > for the enclosing module.
> > > > > > >
> > > > > > > There is no such interaction, since access control comes into
> play
> > > > > > > when some external entity accesses the data through some
> management
> > > > > > > protocol, and the nodes from the "parent-reference" expressions
> > > cannot
> > > > > > > be accessed via management protocols.
> > > > > > >
> > > > > > > The last sentence of the quoted paragraph was supposed to make
> this
> > > > > > > clear, but it seems we might need some additional explanation?
> > > > > > >
> > > > > >
> > > > > > Yes, I think so. I guess I'm not clear on what the XPath
> expressions
> > > are
> > > > > > for if they
> > > > > > can't be accessed via the management protocols. How can they be
> used?
> > > > >
> > > > > These are XPath expressions defined in the YANG models themselves,
> > > > > such as "must" expressions or "leafrefs".   The description of
> > > > > "parent-reference" refer to them as:
> > > > >
> > > > >[...] XPath
> > > > >expressions whose context nodes are defined in the
> > > > >mounted schema
> > > > >
> > > > >
> > > > >
> > > > > /martin
> > > > >
> > >
>

Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)

[Martin Bjorklund]

Hi,

Eric Rescorla  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  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  wrote:
> > >
> > > > Eric Rescorla  wrote:
> > > > > On Wed, Oct 10, 2018 at 5:32 AM Martin Bjorklund 
> > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Eric Rescorla  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/
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > --
> > > > > > > DISCUSS:
> > > > > > >
> > > > --
> > > > > > >
> > > > > > > Rich version of this review at:
> > > > > > > https://mozphab-ietf.devsvcdev.mozaws.net/D3506
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > DETAIL
> > > > > > > S 4.
> > > > > > > >
> > > > > > > >  It is worth emphasizing that the nodes specified in
> > > > > > > >  "parent-reference" leaf-list are available in the mounted
> > > > schema
> > > > > > only
> > > > > > > >  for XPath evaluations.  In particular, they cannot be
> > accessed
> > > > > > there
> > > > > > > >  via network management protocols such as NETCONF
> > [RFC6241] or
> > > > > > > >  RESTCONF [RFC8040].
> > > > > > >
> > > > > > > What are the security implications of this XPath reference
> > outside
> > > > the
> > > > > > > mount jail? Specifically, how does it interact with the access
> > > > control
> > > > > > > for the enclosing module.
> > > > > >
> > > > > > There is no such interaction, since access control comes into play
> > > > > > when some external entity accesses the data through some management
> > > > > > protocol, and the nodes from the "parent-reference" expressions
> > cannot
> > > > > > be accessed via management protocols.
> > > > > >
> > > > > > The last sentence of the quoted paragraph was supposed to make this
> > > > > > clear, but it seems we might need some additional explanation?
> > > > > >
> > > > >
> > > > > Yes, I think so. I guess I'm not clear on what the XPath expressions
> > are
> > > > > for if they
> > > > > can't be accessed via the management protocols. How can they be used?
> > > >
> > > > These are XPath expressions defined in the YANG models themselves,
> > > > such as "must" expressions or "leafrefs".   The description of
> > > > "parent-reference" refer to them as:
> > > >
> > > >[...] XPath
> > > >expressions whose context nodes are defined in the
> > > >mounted schema
> > > >
> > > >
> > > >
> > > > /martin
> > > >
> >

___
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 2, 2018, at 4:30 PM, Juergen Schoenwaelder 
 wrote:
> Not ready, comments posted earlier here:
> 
> https://mailarchive.ietf.org/arch/msg/netmod/qUGyGIxHJKsEXZsG6r3P7R0nirg


Hi Re-quoting to keep the discussion on this thread.

> - What does this mean? In particular the second sentence makes me wonder.
> 
>   Implementations MUST ensure that a modules tag list is consistent
>   across any location from which the list is accessible.  So if a user
>   adds a tag through configuration that tag should also be seen when
>   using any augmentation that exposes the modules tag list.

This text exists b/c originally the module tags list was being proposed to be 
accessible in 2 places, with a read-only version in a yang library 
augmentation. The WG decided that this read-only augmentation was not useful so 
we removed. It.  I'll remove this text as it's now more confusing than useful 
apparently. :)

> - Wording - suggest to remove 'types':
> 
>Tags may be IANA assigned or privately defined types.";

Done.

> - Leaf names:
> 
>   module: ietf-module-tags
>   +--rw module-tags* [name]
>  +--rw name  yang:yang-identifier
>  +--rw tag*  string
>  +--rw masked-tag*   string
> 
>   Name seems to refer to a module but this is not clear until you
>   read the description. I understand that in RFC 7895 and its bis we
>   also just use 'name' but I would find things easier to understand
>   if we would have this:
> 
>   module: ietf-module-tags
>   +--rw module-tags* [module]
>  +--rw moduleyang:yang-identifier
>  +--rw tags* string
>  +--rw masked-tags*  string
> 
>   Note that I also used plural for the leaf-lists.
> 
>   In the description, I would also say "A list of tags associated
>   with..."  instead of "A tag associated with...".

I'll change it to module-name, and pluralize "tag" to "tags".

> 
> - Editorial
> 
>  s/This user/A user

Done

> - Adding and masking the same tag
> 
>  What happens if config adds a tag and masks the same tag? Is the
>  masking taking priority in this case, i.e., you first all all tags
>  and then you filter those that are masked?

The mask takes precedence. I'll add text to clarify this.

> - Standard tags defined in description statements
> 
>  I do not like this. YANG has extension statements and having to
>  parse stuff out of free text description statements seems to be a
>  movement backwards.

This is used by the human implementer of the module (i.e., they need to write 
code to implement the module). As such it was not intended for machine parsing.

> - System management
> 
>  What is 'system management' and a 'system management protocol'?

These were derived from the work the RtgYangDT originally did where we were 
organizing everything under a single device tree. This tree concept was 
(rightly) abandoned to be replaced with use of tags. Examples of protocols 
would be Syslog, TACAC+, SNMP, Netconf, ... I've added that to the description.
 
> - Tag format
> 
>  Apparently, the colon has a special meaning in a tag string and
>  otherwise there do not seem to be any restrictions. (Which is good,
>  I can finally put various smileys on my gear.)
> 
>  Should we state explicitly somewhere that a colon has a special
>  meaning and that tag strings are structured into a sequence of
>  'taggies' separated by colons? Or is definition by example good
>  enough?

I think it's good enough. :)

> - Meaning of tag masks
> 
>  Do masks mean a complete string match or can I mask along the prefix
>  hierarchy, i.e., 'vendor:acme:' masks everything starting with
>  'vendor:acme:'?

Exact match, I've added text to clarify this.

> 
> - Retrieval of the final list of tags
> 
>  Once I have configured tags and masks, how do I obtain the resulting
>  tag list? Do I have to calculate this locally? Or will the final
>  list be found in the operational state datastore (i.e., the applied
>  config

No need to calculate locally, and yes the final list is found in operational 
state datastore.

The description of the "tags" list includes the following text:

 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.";

Thanks,
Chris.

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





> On Oct 2, 2018, at 4:30 PM, Juergen Schoenwaelder 
>  wrote:
> 
> On Tue, Oct 02, 2018 at 01:21:04PM -0700, joel jaeggli wrote:
>> This is start of a two week working group last-call for
>> draft-ietf-netmod-module-tags-02 a current netmod working group
>> document.
>> 
>> You may review at:
>> https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02
>> 
>> Please send 

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

[Christian Hopps]

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