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

From: Alissa Cooper <[email-masked]>
Date: Tue, 03 Jul 2018 14:18:35 -0700

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?

---

From: Ted Hardie <[email-masked]>
Date: Tue, 3 Jul 2018 15:06:39 -0700

A brief note, in-line.

On Tue, Jul 3, 2018 at 2:18 PM, Alissa Cooper <[email-masked]> wrote:

> 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

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 4 Jul 2018 18:33:16 +0200

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

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 5 Jul 2018 08:29:56 -0400

> On Jul 3, 2018, at 6:06 PM, Ted Hardie <[email-masked]> wrote:
> 
> A brief note, in-line.
> 
> On Tue, Jul 3, 2018 at 2:18 PM, Alissa Cooper <[email-masked] <mailto:[email-masked]>> wrote:
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/ <https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/>
> 
> 
> 
> 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 <http://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 <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?

My point is that if the name is meant to signify “module that will be updated automatically when an existing registry is updated” it should have a name that describes that rather than “iana-.” If the operator of said registry is no longer named “iana” at some point in the future (or even now, as you point out), whether to change module names would probably depend on the level of confusion associated with having a misnomer. But even if existing “iana”-named modules don’t change, I’d rather not see more modules minted with such names going forward.

Alissa

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 10 Jul 2018 19:34:18 -0400

> decision we start applying it.

It's also worth noting that some form of meta-syntactic name would be needed
for these sorts of contexts as well.  As noted elsewhere, IANA is a name
currently under IETF control.  Additionally, "IANA maintained" has long
tradition for these sorts of registries, certainly back to the MIB days.
You may wish to seek history on this matter from prior OPS chairs in that
context.

My suggestion is that this discuss be cleared and perhaps raise this during
the wgchairs session.

-- Jeff