Re: [netmod] WG adoption poll draft-ietf-netmod-module-tags-02

[Martin Bjorklund]

Hi,

Andy Bierman  wrote:
> On Wed, Sep 26, 2018 at 7:40 AM joel jaeggli  wrote:
> 
> > This is start of a two week poll on making
> > draft-ietf-netmod-module-tags-02 a NetMod working group
> > document.
> >
> 
> 
> I think we did this step already.
> https://www.ietf.org/mail-archive/web/netmod/current/msg20344.html
> 
> Otherwise how would the draft be named draft-ietf-netmod?
> Maybe you mean to start a WGLC, which I also support.

Chairs, can we get a clarification on this?  Did you mean to start a
WGLC?


/martin



> 
> 
> Andy
> 
> 
> > 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.
> >
> > ___
> > 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 adoption poll draft-ietf-netmod-module-tags-02

[Andy Bierman]

On Sun, Sep 30, 2018 at 4:28 PM, Anees Shaikh  wrote:

> I'm afraid I missed the discussion of tags at recent IETF meetings where
> this may have been covered.  In my read of this draft, I'm still not sure
> what the intended use cases are (i.e., is #hashtag ubiquity really the
> primary motivation)?   What is the difference with a tag extension?
>
>

The YANG extension vs. description-stmt issue is related to how the module
author
assigns a module-tag mapping to a module.


Perhaps it's overkill to have a separate use cases draft for such a small
> model, but I think the draft really does need a section or two explaining
> why and how this is envisioned to be used, and what server implementors are
> supposed to do with it.
>


A module-tag provides a 1:N mapping so instead of specifying (e.g.) every
routing module
by name, a tag like "routing" can be used instead.

This mapping allows the tag to be stable even if the modules in the mapping
are not stable.
The mappings can change release to release or server to server.

We have implemented module tags as a new filter type, for get and
get-config operations.,
as well as a rule-type for NACM rules.

I assume the plan is that NETMOD WG would work on the data model and
NETCONF WG
would eventually do the protocol work.



> thanks.
> -- Anees
>
> On Sun, Sep 30, 2018 at 4:15 PM Andy Bierman  wrote:
>
>>
>>
>> On Sun, Sep 30, 2018 at 1:17 PM, joel jaeggli  wrote:
>>
>>> On 9/26/18 09:23, Andy Bierman wrote:
>>> >
>>> >
>>> > On Wed, Sep 26, 2018 at 9:09 AM Juergen Schoenwaelder
>>> > >> > > wrote:
>>>
>>> >
>>> > It is even worse than a step backwards.
>>> > The draft specifies a lot of details about module tag conformance
>>> > that needs to be present in the description-stmt.
>>>
>>> this seems like an important issue to square away  before we  move ahead.
>>>
>>>
>> agreed.
>>
>> Also, what does it mean to match a module-tag?
>> There is text that implies it is an opaque string and other text that
>> suggests it is a colon-separated list of terms.
>> It cannot really be both.
>>
>>
>>
>>> > The idea that tools must screen-scrape description statements goes
>>> against
>>> > everything YANG-based management is all about. YANG has extension
>>> > statements, so we don't need to put complex syntax into comments and
>>> > descriptions..
>>>
>>> and parse descriptions for meaning.
>>>
>>
>> So what the choices?
>>
>> 1) IANA
>> 2) YANG extension
>> 3) ad-hoc
>> 4) do nothing
>>
>> IMO IANA has enough to do and it only covers IETF modules anyway, so (1)
>> is out.
>> The current approach is (3).  It is slightly better than (4), but there
>> is nothing
>> preventing every module from declaring the module tags differently.
>> This does not help the YANG reader (#1 priority).
>>
>> Only a YANG extension (or real statement in YANG 2.0) supports all modules
>> in a way that is consistent for all readers.
>>
>>
>>
>>
>>>
>>> > IMO all text about module tag conformance and defining tags in
>>> > description-stmts
>>> > should be removed.  There is no explanation why a standard YANG module
>>> > would define multiple module-tags for the same module in the first
>>> place,
>>> > let alone why each different tag would have different conformance
>>> > requirements.
>>> >
>>> >
>>> >
>>> > .
>>> >
>>> > /js
>>> >
>>> >
>>> > Andy
>>> >
>>>
>>
>> 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
>>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG adoption poll draft-ietf-netmod-module-tags-02

[Andy Bierman]

On Sun, Sep 30, 2018 at 1:17 PM, joel jaeggli  wrote:

> On 9/26/18 09:23, Andy Bierman wrote:
> >
> >
> > On Wed, Sep 26, 2018 at 9:09 AM Juergen Schoenwaelder
> >  > > wrote:
>
> >
> > It is even worse than a step backwards.
> > The draft specifies a lot of details about module tag conformance
> > that needs to be present in the description-stmt.
>
> this seems like an important issue to square away  before we  move ahead.
>
>
agreed.

Also, what does it mean to match a module-tag?
There is text that implies it is an opaque string and other text that
suggests it is a colon-separated list of terms.
It cannot really be both.



> > The idea that tools must screen-scrape description statements goes
> against
> > everything YANG-based management is all about. YANG has extension
> > statements, so we don't need to put complex syntax into comments and
> > descriptions..
>
> and parse descriptions for meaning.
>

So what the choices?

1) IANA
2) YANG extension
3) ad-hoc
4) do nothing

IMO IANA has enough to do and it only covers IETF modules anyway, so (1) is
out.
The current approach is (3).  It is slightly better than (4), but there is
nothing
preventing every module from declaring the module tags differently.
This does not help the YANG reader (#1 priority).

Only a YANG extension (or real statement in YANG 2.0) supports all modules
in a way that is consistent for all readers.




>
> > IMO all text about module tag conformance and defining tags in
> > description-stmts
> > should be removed.  There is no explanation why a standard YANG module
> > would define multiple module-tags for the same module in the first place,
> > let alone why each different tag would have different conformance
> > requirements.
> >
> >
> >
> > .
> >
> > /js
> >
> >
> > Andy
> >
>

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 adoption poll draft-ietf-netmod-module-tags-02

[joel jaeggli]

On 9/26/18 09:23, Andy Bierman wrote:
> 
> 
> On Wed, Sep 26, 2018 at 9:09 AM Juergen Schoenwaelder
>  > wrote:

> 
> It is even worse than a step backwards.
> The draft specifies a lot of details about module tag conformance
> that needs to be present in the description-stmt.

this seems like an important issue to square away  before we  move ahead.

> The idea that tools must screen-scrape description statements goes against
> everything YANG-based management is all about. YANG has extension
> statements, so we don't need to put complex syntax into comments and
> descriptions..

and parse descriptions for meaning.

> IMO all text about module tag conformance and defining tags in
> description-stmts
> should be removed.  There is no explanation why a standard YANG module
> would define multiple module-tags for the same module in the first place,
> let alone why each different tag would have different conformance
> requirements.
> 
>  
> 
> .
> 
> /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
> 




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

Re: [netmod] WG adoption poll draft-ietf-netmod-module-tags-02

[Andy Bierman]

On Wed, Sep 26, 2018 at 9:09 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Wed, Sep 26, 2018 at 07:55:44AM -0700, Andy Bierman wrote:
> > On Wed, Sep 26, 2018 at 7:40 AM joel jaeggli  wrote:
> >
> > > This is start of a two week poll on making
> > > draft-ietf-netmod-module-tags-02 a NetMod working group
> > > document.
> > >
> >
> >
> > I think we did this step already.
> > https://www.ietf.org/mail-archive/web/netmod/current/msg20344.html
> >
> > Otherwise how would the draft be named draft-ietf-netmod?
> > Maybe you mean to start a WGLC, which I also support.
> >
>
> While we figure out what the action is, here are a few quick review
> comments:
> 
> - 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.
>


It is even worse than a step backwards.
The draft specifies a lot of details about module tag conformance
that needs to be present in the description-stmt.

The idea that tools must screen-scrape description statements goes against
everything YANG-based management is all about. YANG has extension
statements, so we don't need to put complex syntax into comments and
descriptions.

IMO all text about module tag conformance and defining tags in
description-stmts
should be removed.  There is no explanation why a standard YANG module
would define multiple module-tags for the same module in the first place,
let alone why each different tag would have different conformance
requirements.



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

Re: [netmod] WG adoption poll draft-ietf-netmod-module-tags-02

[Juergen Schoenwaelder]

On Wed, Sep 26, 2018 at 07:55:44AM -0700, Andy Bierman wrote:
> On Wed, Sep 26, 2018 at 7:40 AM joel jaeggli  wrote:
> 
> > This is start of a two week poll on making
> > draft-ietf-netmod-module-tags-02 a NetMod working group
> > document.
> >
> 
> 
> I think we did this step already.
> https://www.ietf.org/mail-archive/web/netmod/current/msg20344.html
> 
> Otherwise how would the draft be named draft-ietf-netmod?
> Maybe you mean to start a WGLC, which I also support.
>

While we figure out what the action is, here are a few quick review
comments:

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

- Wording - suggest to remove 'types':

Tags may be IANA assigned or privately defined types.";

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

- Editorial

  s/This user/A user

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

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

- System management

  What is 'system management' and 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?

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

- 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

/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 adoption poll draft-ietf-netmod-module-tags-02

[Andy Bierman]

On Wed, Sep 26, 2018 at 7:40 AM joel jaeggli  wrote:

> This is start of a two week poll on making
> draft-ietf-netmod-module-tags-02 a NetMod working group
> document.
>


I think we did this step already.
https://www.ietf.org/mail-archive/web/netmod/current/msg20344.html

Otherwise how would the draft be named draft-ietf-netmod?
Maybe you mean to start a WGLC, which I also support.


Andy


> 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.
>
> ___
> 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 adoption poll draft-ietf-netmod-module-tags-02

[Robert Wilton]

Yes/support.

Thanks,
Rob


On 26/09/2018 15:40, joel jaeggli wrote:

This is start of a two week poll on making
draft-ietf-netmod-module-tags-02 a 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.



___
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 adoption poll draft-ietf-netmod-module-tags-02

[Acee Lindem (acee)]

Yes/support
Thanks,
Acee

On 9/26/18, 10:41 AM, "netmod on behalf of joel jaeggli" 
 wrote:

This is start of a two week poll on making
draft-ietf-netmod-module-tags-02 a 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.



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

[netmod] WG adoption poll draft-ietf-netmod-module-tags-02

[joel jaeggli]

This is start of a two week poll on making
draft-ietf-netmod-module-tags-02 a 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.



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