IANA Interface Type YANG Module
draft-ietf-netmod-iana-if-type-10
Yes
(Benoît Claise)
No Objection
(Brian Haberman)
(Gonzalo Camarillo)
(Jari Arkko)
(Martin Stiemerling)
(Pete Resnick)
(Sean Turner)
(Spencer Dawkins)
(Stephen Farrell)
(Ted Lemon)
Note: This ballot was opened for revision 09 and is now closed.
Benoît Claise Former IESG member
Yes
Yes
(for -09)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2014-01-03 for -09)
Unknown
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.
Barry Leiba Former IESG member
No Objection
No Objection
(2014-01-05 for -09)
Unknown
Nothing to add to Adrian's questions.
Brian Haberman Former IESG member
No Objection
No Objection
(for -09)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -09)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -09)
Unknown
Joel Jaeggli Former IESG member
(was Discuss, No Objection)
No Objection
No Objection
(2014-01-15)
Unknown
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
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -09)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -09)
Unknown
Sean Turner Former IESG member
No Objection
No Objection
(for -09)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -09)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(for -09)
Unknown
Stewart Bryant Former IESG member
(was Discuss)
No Objection
No Objection
(2014-01-08 for -09)
Unknown
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?
Ted Lemon Former IESG member
No Objection
No Objection
(for -09)
Unknown