Thanks Reshad. Michelle, can you confirm this is the correct plan? Alissa
> On Jul 25, 2018, at 10:33 AM, Reshad Rahman (rrahman) <rrah...@cisco.com> > wrote: > > Hi Alissa, > > Regarding your comment below on 2.12, I looked at the 4 IANA modules @ > https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml: > iana-if-type, iana-crypt-hash, iana-routing-types and iana-hardware (from the > 4 RFCs you listed below) and they all seem to be using ICANN. I will modify > the address in draft-ietf-bfd-yang to the address below. > > Regards, > Reshad. > > Postal: ICANN > 12025 Waterfront Drive, Suite 300 > Los Angeles, CA 90094-2536 > United States of America > > > On 2018-07-19, 5:07 PM, "Alissa Cooper" <ali...@cooperw.in> wrote: > > Alissa Cooper has entered the following ballot position for > draft-ietf-bfd-yang-16: 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-bfd-yang/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Looking forward to the discussion of my original DISCUSS in NETMOD. Here > it was: > > I will apologize in advance because this document may be sort of a > casualty of > this DISCUSS. I should have raised my point below at least two years ago > if not > four years ago when the first iana-* YANG module was registered, but the > thought did not occur to me until now. > > It gives me some pause to see the name "iana" embedded in the file name, > module > name, namespace, and prefix of the module being defined in Sec. 2.12. I > realize > there is precedent here, but I question whether tying these kinds of > modules > specifically to IANA as the protocol parameter registry operator by name > puts > them on the most stable deployment footing under all possible > circumstances. I > am personally pleased as punch with the service we get from IANA, but that > doesn't mean "IANA" will always be the name of the registry operator. The > more > modules that get created with this embedding, the more of them that may > need to > change in the unlikely event that the name of the registry operator > changes. > Lots of RFCs would need to change too, but embedding the name extends the > potential problem to the modules themselves. > > It wasn't clear to me whether there is some ops-area-wide convention > around the > embedding of "iana" in the names of modules to be maintained by IANA. I > don't > see this specifically referenced in RFC 7950 or RFC 6020. So I'd like to > discuss whether a different naming convention could be established and > used in > this document and others going forward. > > --- > > COMMENT: > > Some further questions on Sec. 2.12: > > Looking back at the other RFCs that have defined YANG modules to be > maintained > by IANA (7224, 7317, 8294, 8348), they use two different postal addresses > for > ICANN. Why? Furthermore, is "ICANN" really the right contact name, or > should it > be PTI? > > > >
