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

["Reshad Rahman (rrahman)" <[e-mail]>]

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?