Re: Alissa Cooper's No Objection on draft-ietf-bfd-yang-16: (with COMMENT)

[Alissa Cooper <[e-mail]>]

Thanks Reshad. Michelle, can you confirm this is the correct plan?

Alissa

> On Jul 25, 2018, at 10:33 AM, Reshad Rahman (rrahman) <[e-mail]> 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" <[e-mail]> 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?
> 
> 
> 
>