Subject: Re: [netmod] Adrian Farrel's No Objection on draft-ietf-netmod-iana-if-type-09: (with COMMENT)

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 Jan 2014 18:03:12 +0100

Adrian,

thanks for the review - adding the NETMOD WG to the CC, responses
inline...

On Fri, Jan 03, 2014 at 05:35:38AM -0800, Adrian Farrel wrote:
> Adrian Farrel has entered the following ballot position for
> draft-ietf-netmod-iana-if-type-09: 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 http://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:
> http://datatracker.ietf.org/doc/draft-ietf-netmod-iana-if-type/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I am not a YANG expert, but have a couple of concerns about the
> way this module is handed to IANA.
> 
> ---
> 
> I think you should remove...
> 
>         This version of this YANG module is part of RFC XXXX; see
>         the RFC itself for full legal notices.";
>      // RFC Ed.: replace XXXX with actual RFC number and remove this
>      // note.
> 
> ...from the main description clause.
> 
> This is because the entire module will be lifted on to the IANA web page
> preserving this note. When updates are made to the module by IANA the
> note will be wrong, but is unlikely to be removed.
> 
> Indeed, since the normative version will in any case be the web page not
> the RFC, the note is de trop.

Yes, this should be worded differently. 
 
> Similarly...
> 
>      // RFC Ed.: update the date below with the date of RFC publication
>      // and remove this note.
>      revision 2013-12-07 {   
>        description
>          "Initial revision.";
>        reference
>          "RFC XXXX: IANA Interface Type YANG Module";
>      }
> 
> Do you expect each modification by IANA to generate a new version with
> a new date? I don't think so. I think the purpose of handing it to IANA
> is that it is a living module that can safely be extended at any time by
> IANA without sparking a new revision.

It is a living module but we expect IANA to generate a new revision
evertime the module is updated. The IANA Considerations (section 3)
are clear about this:

   When the iana-if-type YANG module is updated, a new "revision"
   statement must be added.

This is what has been done with IANA maintained MIB modules for years
and hence we are pretty sure this is workable. These revision
statements are essential for YANG / NETCONF version management to
work. Hence, I believe no action is needed here.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>