Re: Alissa Cooper's Discuss on draft-ietf-bfd-yang-16: (with DISCUSS and COMMENT)

[Martin Vigoureux <[e-mail]>]

Hello Alissa,

thanks for your review.
I'm fine with discussing this but wonder if we should tie it to this draft.
I would prefer that we collectively discuss that and once we reach a 
decision we start applying it.

Thanks
-m

Le 2018-07-03 à 23:18, Alissa Cooper a écrit :
> 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. 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?
> 
> 
>