Re: [netmod] IANA registries

2019-10-17 Thread Kent Watsen
All,

>> That's a bit odd.  But perhaps it can be solved by actually not
>> filling in all values in this module, but rather make it a template
>> and instruct IANA to fill it in with the contents of the registry at
>> the time of publication.
> 
> OK, so the module template in the RFC couldn't be used at all - this might
> indeed help.

This is an interesting proposal indeed, and one that may help with the 
crypto-types "algorithm" discussion as well.

Having IANA be able to automatically publish revisions for select module is 
something that has been discussed in the past, partially in NETCONF wrt 
crypto-types, to eliminate the need for expensive RFC cycles, for updates that 
needed as a reaction to other RFCs being published, which should also have the 
effect of shortening the time it takes for those updates to be made.

AFAIK, no such relationship with IANA exists currently anywhere within the 
IETF.  To move this idea forward, the chairs need to discuss with the AD.  It 
might aid that discussion if there were an example template module...anyone 
want to a stab at one?   

Should there be an I-D that lays out the framework for the agreement with IANA, 
or would each draft (e.g., crypto-types) lay it out just for itself?  Actually, 
this sounds like what might come out of the discussion with the AD, but 
thoughts now are welcome to.

Kent // as co-chair___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


[netmod] Barry Leiba's No Objection on draft-ietf-netmod-yang-data-ext-04: (with COMMENT)

2019-10-17 Thread Barry Leiba via Datatracker
Barry Leiba has entered the following ballot position for
draft-ietf-netmod-yang-data-ext-04: No Objection

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-yang-data-ext/



--
COMMENT:
--

A fine extension.  Just three editorial nits:

-- Section 1 —

   There is no
   assumption that a YANG data structure can only be used as a top-level
   abstraction, instead of nested within some other data structure.

It’s a little odd to use “instead of” after “there is no assumption”; I can’t
explain it fully, but it feels odd to this native English speaker.  I suggest
this:

NEW
   There is no
   assumption that a YANG data structure can only be used as a top-level
   abstraction, and it may also be nested within some other data structure.
END

   similar to the existing YANG "augment" statement.

Make it “similarly”.

— Section 1.1.1 —

   The following terms are defined in the Network Management Datastore
   Architecture (NMDA) [RFC8342].  and are not redefined here:

The period after the citation should be a comma.


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