IANA Interface Type YANG Module
draft-ietf-netmod-iana-if-type-10

Note: This ballot was opened for revision 09 and is now closed.

(Benoît Claise) Yes

(Jari Arkko) No Objection

(Stewart Bryant) (was Discuss) No Objection

Comment (2014-01-08 for -09)
No email
send info
Following discussions with Benoit on the Discuss text included below for reference, I think the matter is in hand and I entrust it to his resolution.

I have a short question for Benoit, which I am sure will be
simply resolved.

IANA is requested to add this new Note to the "ifType definitions"
   registry:

     When this registry is modified, the YANG module iana-if-type
     must be updated as defined in RFC XXXX.

Please can you help me understand the logistics here. If
I go to IANA with a request for the new-foo interface, what takes
place to cause the YANG module update?

(Gonzalo Camarillo) No Objection

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

Comment (2014-01-03 for -09)
No email
send info
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.

---

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.

(Stephen Farrell) No Objection

(Brian Haberman) No Objection

(Joel Jaeggli) (was Discuss, No Objection) No Objection

Comment (2014-01-15)
No email
send info
was: 

dicuss held on behalf of iana

Hello all,

The current version (-10) looks fine.   Indeed, the numerical value is no
longer presented in the YANG module anymore in recent versions.  Please
check with Joel if he can clear his Discuss.

Also, we will not make any changes to the name and description of the
value 273 in the "ifType definitions" registry at this time.

Btw, just an observation of the "ifType definitions" registry.  If a new
ifType value is later requested, it will update the following registries
in addition to the "ifType definitions" registry:

The transmission number values
(http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-
7)
IANAifType-MIB (http://www.iana.org/assignments/ianaiftype-mib)
The 'new' iana-if-type YANG module (TBD)


Thanks,
~pl

Barry Leiba No Objection

Comment (2014-01-05 for -09)
No email
send info
Nothing to add to Adrian's questions.

(Ted Lemon) No Objection

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection