A brief note, in-line. On Tue, Jul 3, 2018 at 2:18 PM, Alissa Cooper <ali...@cooperw.in> wrote:
> Alissa Cooper has entered the following ballot position for > draft-ietf-bfd-yang-16: Discuss > > 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/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > 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. Just as a point of clarification, I believe that the name of the operator at the moment is PTI, a subsidiary of ICANN (Public Technical Identifiers, pti.icann.org). "IANA" as a trademark was assigned to the IETF Trust, see Exhibit B in this document: https://trustee.ietf.org/documents/Assignment-Agreement-2016-09-30-Executed.pdf If I understand correctly, that means that the IETF Trust would have to would have to do something surprising in order to make the use of "IANA" untenable in this context. There may be good reasons outside of that to consider more descriptive names, but I am not seeing the same issue you do. Can you explain further? thanks, Ted 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? > > >
