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

[Joel Jaeggli]

> On Oct 25, 2018, at 06:12, Christian Hopps  wrote:
> 
> Hi Joel, WG,
> 
> I published a new draft some days ago covering the specific concerns and 
> editorial changes requested during WGLC. This included the addition of an 
> extension statement which covered machine parsing of pre-defined tags which 
> was mentioned by multiple people, and is the only significant change made. I 
> would think we'd have rough consensus (at least) at this point.

Yes, I don’t think we need to belabor the edits since I think that discussion 
tailed of to a reasonable conclusion.

> 
> I do not agree that we should restrict the usefulness of this work by 
> removing the ability of the module author or the vendor/implementer to add 
> tags due to a single persons view of how they might use the technology. 
> There's nothing gained, and there's obvious loss of functionality.

I’m trying not to inject my own opinion into prejudging an outcome here. 

I do see it as significant point of contention in the working group last call. 
If I were asking for consensus on the point specifically I do not believe that 
we have arrived at a point of rough consensus yet.

> Thanks,

Thanks for getting us to this point.

Joel

> Chris.
> 
>> On Oct 25, 2018, at 3:05 AM, Joel Jaeggli  wrote:
>> 
>> This WG LC closed on the 16th. 
>> 
>> Working group last calls serve a useful forcing function even for drafts 
>> that may end up looking unready as a result due to the attention. If I am 
>> making a judgement call here based on the feedback received during this 
>> period and the prior one.
>> 
>> I will try and summarize the major concerns that  see expressed with this 
>> draft.
>> 
>> Jurgen had a significant list of comments and edits
>> 
>> https://mailarchive.ietf.org/arch/msg/netmod/qUGyGIxHJKsEXZsG6r3P7R0nirg
>> 
>> Followed up by Christian
>> 
>> One detail teased out there and in other comments bears revisting
>> 
>>Juergen
>>> 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.
>> 
>> Christian
>> 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.
>> 
>> Juergon
>> 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.
>> 
>> Andy 
>> 
>> 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.
>> 
>> Alex
>> 
>> 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)
>> 
>> Wether or not this is intended for or will be parsed by machines remains a 
>> significant unresolved concern. The actual mechanics of restricting what 
>> goes into them however seems fairly straight forward.
>> 
>> Absent consensus on the above concern this document cannot probably advance, 
>> we do have the opportunity for significant face to face discussion in the 
>> near future so using that to arrive at a conclusion would probably allow 
>> this work to progress or stop.
>> 
>> Thanks
>> Joel
>> 
>>> On Oct 2, 2018, at 13:21, 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 email to the list indicating "yes/support" or "no/do not
>>> support".  If indicating no, please state your reservations with the
>>> document.  If yes, please also feel free to provide comments you'd like
>>> to see addressed once the document is a WG document.
>>> 
>>> The prior discussion of my mistaken WG adoption call is here
>>> 
>>> commences here:
>>> 
>>> https://www.ietf.org/mail-archive/web/netmod/current/msg21290.html
>>> 
>>> In particular Andy's concerns expressed in that thread here:
>>> 
>>> https://www.ietf.org/mail-archive/web/netmod/current/msg21348.html
>>> 
>>> are probably important to tease out in considering this for last call.
>>> 
>>> so that we are clear on dates. This last call timing resets and runs
>>> from 10/2/18 - 10/16/18
>>> 
>>> Joel
>>> 
>>> ___
>>> netmod mailing 

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

[Christian Hopps]

Hi Joel, WG,

I published a new draft some days ago covering the specific concerns and 
editorial changes requested during WGLC. This included the addition of an 
extension statement which covered machine parsing of pre-defined tags which was 
mentioned by multiple people, and is the only significant change made. I would 
think we'd have rough consensus (at least) at this point.

I do not agree that we should restrict the usefulness of this work by removing 
the ability of the module author or the vendor/implementer to add tags due to a 
single persons view of how they might use the technology. There's nothing 
gained, and there's obvious loss of functionality.

Thanks,
Chris.

> On Oct 25, 2018, at 3:05 AM, Joel Jaeggli  wrote:
> 
> This WG LC closed on the 16th. 
> 
> Working group last calls serve a useful forcing function even for drafts that 
> may end up looking unready as a result due to the attention. If I am making a 
> judgement call here based on the feedback received during this period and the 
> prior one.
> 
> I will try and summarize the major concerns that  see expressed with this 
> draft.
> 
> Jurgen had a significant list of comments and edits
> 
> https://mailarchive.ietf.org/arch/msg/netmod/qUGyGIxHJKsEXZsG6r3P7R0nirg
> 
> Followed up by Christian
> 
> One detail teased out there and in other comments bears revisting
> 
> Juergen
>> 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.
> 
> Christian
> 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.
> 
> Juergon
> 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.
> 
> Andy 
> 
> 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.
> 
> Alex
> 
> 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)
> 
> Wether or not this is intended for or will be parsed by machines remains a 
> significant unresolved concern. The actual mechanics of restricting what goes 
> into them however seems fairly straight forward.
> 
> Absent consensus on the above concern this document cannot probably advance, 
> we do have the opportunity for significant face to face discussion in the 
> near future so using that to arrive at a conclusion would probably allow this 
> work to progress or stop.
> 
> Thanks
> Joel
> 
>> On Oct 2, 2018, at 13:21, 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 email to the list indicating "yes/support" or "no/do not
>> support".  If indicating no, please state your reservations with the
>> document.  If yes, please also feel free to provide comments you'd like
>> to see addressed once the document is a WG document.
>> 
>> The prior discussion of my mistaken WG adoption call is here
>> 
>> commences here:
>> 
>> https://www.ietf.org/mail-archive/web/netmod/current/msg21290.html
>> 
>> In particular Andy's concerns expressed in that thread here:
>> 
>> https://www.ietf.org/mail-archive/web/netmod/current/msg21348.html
>> 
>> are probably important to tease out in considering this for last call.
>> 
>> so that we are clear on dates. This last call timing resets and runs
>> from 10/2/18 - 10/16/18
>> 
>> Joel
>> 
>> ___
>> 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]

A router has no use for it's capability/feature/deviation advertisements 
either; module-tags are no different in this respect.

Thanks,
Chris.

Alex Campbell  writes:


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 Wo

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 jae

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

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

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

[Alex Campbell]

Do not support.

This document does not make a good case for why tags should exist.
The introduction does not explain what they are useful for, it just makes a 
comparison to #hashtags (which is something I would expect to see in an April 
1st RFC).
The initial registry values, section 8.2, also provide no insight as to the 
value of any of these tags. At best these values could be used to categorise 
modules for human browsing.

In short, I see no evidence that the standard this document attempts to define 
is actually useful.



Additional major concerns:
- the draft does not indicate who should implement the included YANG module.
- there is no automatic mechanism specified (such as an extension statement) by 
which the server can read the tags from the module (as 4.1 specifies must 
happen), therefore the implementer will have to do this manually and is likely 
to forget.
- I do not believe servers should be concerned with classifying their 
implemented YANG modules, unless there is a good reason. This seems like a 
client responsibility. How will the system work in a large network with one 
client reading data from 500 servers, each of which could have different tag 
data? Or maybe two clients with different tag data, both trying to update the 
network to hold the "correct" data.





From: netmod  on behalf of joel jaeggli 

Sent: Wednesday, 3 October 2018 9:21 a.m.
To: NETMOD Working Group
Subject: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

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 email to the list indicating "yes/support" or "no/do not
support".  If indicating no, please state your reservations with the
document.  If yes, please also feel free to provide comments you'd like
to see addressed once the document is a WG document.

The prior discussion of my mistaken WG adoption call is here

commences here:

https://www.ietf.org/mail-archive/web/netmod/current/msg21290.html

In particular Andy's concerns expressed in that thread here:

https://www.ietf.org/mail-archive/web/netmod/current/msg21348.html

are probably important to tease out in considering this for last call.

so that we are clear on dates. This last call timing resets and runs
from 10/2/18 - 10/16/18

Joel


___
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 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 email to the list indicating "yes/support" or "no/do not
> support".  If indicating no, please state your reservations with the
> document.  If yes, please also feel free to provide comments you'd like
> to see addressed once the document is a WG document.

Not ready, comments posted earlier here:

https://mailarchive.ietf.org/arch/msg/netmod/qUGyGIxHJKsEXZsG6r3P7R0nirg

/js

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

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

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

[joel jaeggli]

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 email to the list indicating "yes/support" or "no/do not
support".  If indicating no, please state your reservations with the
document.  If yes, please also feel free to provide comments you'd like
to see addressed once the document is a WG document.

The prior discussion of my mistaken WG adoption call is here

commences here:

https://www.ietf.org/mail-archive/web/netmod/current/msg21290.html

In particular Andy's concerns expressed in that thread here:

https://www.ietf.org/mail-archive/web/netmod/current/msg21348.html

are probably important to tease out in considering this for last call.

so that we are clear on dates. This last call timing resets and runs
from 10/2/18 - 10/16/18

Joel



signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod