IANA Interface Type YANG Module
RFC 7224
Yes
No Objection
Note: This ballot was opened for revision 09 and is now closed.
(Benoît Claise; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
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 steering group member) No Objection
Nothing to add to Adrian's questions.
(Brian Haberman; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) (was Discuss, No Objection) No Objection
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 steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
(Stewart Bryant; former steering group member) (was Discuss) No Objection
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 steering group member) No Objection