Subject: [eppext] AD Review of draft-ietf-eppext-reg-07

From: Pete Resnick <[email-masked]>
Date: Mon, 1 Sep 2014 22:16:01 -0500

At long last, my AD Review of draft-ietf-eppext-reg-07. My apologies for 
the delay.

First, please don't worry about the length of this message. As long as 
it is, there's nothing earth shattering in here. The number of changes I 
suggest are actually pretty small, but I wanted to give you a good 
explanation of why I suggested them.

So, first an overall comment:

My understanding is that right now, caveat the initial registrations in 
section 4 (more on them in a moment), the things that go into this 
registry are being put there for "informational" purposes. That is, it's 
a place to document the way things are being done now, but not 
indicating any form of endorsement for one way over the other. However, 
my understanding of the purpose of this registry is so that the EPP 
community can, over the long term, harmonize extensions. That is, we 
want folks to register these things so that folks who are developing 
extensions might look and see, "Oh, that one does what I need; I should 
just use that one." Furthermore, over time, folks might decide, "Hey, 
these three extensions do the same thing; let's pick one way of doing 
it." If the community agrees, they can "standardize" that way of doing 
things. That will make life easier on registrars (and everyone for that 
matter) so that folks won't have to implement the same thing multiple 
different ways. I would expect that the way that would happen would be 
to create a IETF Standards Track RFC for those extensions that everyone 
agrees are "*the* way to do this thing".

So it seems to me that, while most of the things expected to be 
registered here are strictly "informational" documents (mostly outside 
of the IETF), we might want to have an extra column in the registry to 
indicate the standards status of the registry entry so that people can 
see if there is a particular item that is standard. It also seems to me 
that if a registration is an IETF Standards Track document, that should 
indicate that it has already gotten sufficient review and therefore the 
Designated Experts don't need to.

So my suggestions are to address this are:

1. In section 3.1.1, add: "If the specification for the registration is 
an IETF Standards Track document, no review is required by the 
Designated Expert."

2. In section 3.2.1:

OLD
    Registrant Name and Email Address: The case-insensitive name and
    email address of the person that is responsible for managing the
    registry entry.
NEW
    Registrant Name and Email Address: The name and email address of the
    person that is responsible for managing the registry entry. If the
    registration is of an IETF Standards Track document, this can simply
    be listed as "IESG <[email-masked]>"

(I don't think you need to specify "case-insensitive" above, especially 
because it doesn't make sense in some languages.)

Also add:

    Document Status: The document status ("Informational", "Standards
    Track", etc.) of the specification document. For documents that are
    not RFCs, this will always be "Informational".

So, getting back to the initial 4 registrations (RFCs 3915, 4114, 5076, 
and 5910): Each of those is currently on the Standards Track. I would 
presume that they would each go into the registry as "Document Status: 
Standards Track", presuming that they've already gotten community 
consensus that they are "*the* way to do this thing". (Otherwise, they 
probably shouldn't have been on the Standards Track in the first place, 
in which case we should probably have a discussion about what to do.)

Does all that make sense?

---

Other more minor comments:

(Overall editorial note: Generally, I find the use of the 2119 language 
in this document unnecessary. We're supposed to use those terms where 
interoperability is needed, and here they just seem a bit overdone. 
Also, I don't think that you need to say things like "'Any' or 'ANY'", 
since if you're going to allow them to be case-insensitive, "AnY" and 
"aNY" and all the other silly ones could also be used. And that said, I 
don't think you need to specify case-insensitive; it's a form that will 
be handled by humans. Just give one example, either in title case or 
upper case, and be done with it.)

3.1, first paragraph, I suggest:

NEW
    This registry uses the "Specification Required" policy described in
    RFC 5226 [RFC5226]. An English language version of the extension
    specification will appear in the registry, though non-English
    versions of the specification can also be provided.  Note that
    Section 2.1 of RFC 3735 [RFC3735] provides specific guidelines for
    documenting EPP extensions.

3.2.1:

OLD
    Specification Location: A URL [RFC3986] that describes the location
    of the specification.

I suspect that won't satisfy IANA, as they generally want a stable 
reference, though they will take a URL if need be. 5226 says:

       Specification Required - Values and their meanings must be
             documented in a permanent and readily available public
             specification [...] The intention behind
             "permanent and readily available" is that a document can
             reasonably be expected to be findable and retrievable long
             after IANA assignment of the requested value.

How about instead simply saying:

NEW
    Reference: A reference to the specification of this extension. This
    could be an RFC number or some other pointer to the document defining
    the extension.

OLD
    TLDs: A case-insensitive text string description of the top-level
    domain (or domains) for which the extension has been specified.
    "Any" or "ANY" MUST be used if the extension is not associated with a
    specific top-level domain.  Multiple TLDs SHOULD be specified as a
    list of domain names separated by commas, e.g. ".com, .net".
    Internationalized Domain Name (IDN) TLDs should be specified in
    A-label [RFC5890] format.

"A case-insensitive text string description of the top-level domain" 
seems weird. First, if we're using A-Labels, we already know they're 
case-insensitive. Second, the string *is* the domain name, isn't it? 
Finally, you should be clear to include the "." at the beginning. How 
about instead:

NEW
    TLDs: A text string containing the top-level domain name (or domains
    names), including the preceding ".", for which the extension has been
    specified (e.g., ".org"). If there are multiple TLDs, they are given
    as a list of domain names separated by commas, (e.g. ".com, .net").
    Internationalized Domain Name (IDN) TLDs should be specified in
    A-label [RFC5890] format. If the extension is not associated with a
    specific top-level domain, the case-insensitive text string "ANY" can
    be used to indicate that.

OLD
    IPR Disclosure: Either "None", "NONE", or a URL that describes the
    location of an IPR disclosure document.  Depending on the type of
    specification the IPR disclosure MAY be filed with the IETF in
    accordance with RFC 3979 [RFC3979] as updated by RFC 4879 [RFC4879].
    Non-IETF IPR disclosures MUST clearly identify the claimed
    intellectual property rights and terms of use.  "None" or "NONE"
    indicates that the extension is freely available for use with no
    claimed intellectual property rights.

That last sentence gave me heartburn. Just because nobody has made a 
disclosure does not mean something is "freely available for use with no 
claimed IPR." How about this:

NEW
    IPR Disclosure: A pointer to any IPR disclosure document(s) related
    to this extension, or "None" if there are no such disclosures.  This
    can be an IPR disclosure filed with the IETF in accordance with RFC
    3979 [RFC3979] as updated by RFC 4879 [RFC4879] if the extension is
    part of an IETF Contribution, or can be other IPR disclosures
    documents identifying the claimed intellectual property rights and
    terms of use for extensions that are not part of an IETF Contribution.

OLD
    Status: Either "Active", "ACTIVE", "Inactive", or "INACTIVE".
NEW
    Status: Either "ACTIVE" or "INACTIVE".

OLD
    Notes: Either "None", "NONE", or other text
NEW
    Notes: Either "NONE" or other text

Change 3.2.2 to agree with the above (and eliminate the MUST and MAY in 
there too).

3.2.3:

OLD
    Each registration form sent to IANA MUST contain a single record for
    incorporation into the registry.  The form will be sent via email to
<[email-masked]> by the extension registrant.  It MUST have a
    subject...
NEW
    Send each registration form to IANA with a single record for
    incorporation into the registry.  The form will be sent via email to
<[email-masked]> by the extension registrant, and will have a
    subject...

3.2.4:

OLD
    All changes to existing registry entries MUST be documented with text
    in the "Notes" field of the registration form.  Under normal
    circumstances registry entries MAY only be updated by the registrant.
    If the registrant becomes unavailable or otherwise unresponsive, the
    designated expert MAY submit a registration form to IANA to update
    the registrant information.  Entries MAY change state from "Active"...
NEW
    When submitting changes to existing registry entries, include text in
    the "Notes" field of the registration form describing the change.
    Under normal circumstances, registry entries are only be updated by
    the registrant. If the registrant becomes unavailable or otherwise
    unresponsive, the designated expert can submit a registration form to
    IANA to update the registrant information.  Entries can change state
    from "Active"...

That's it. Let me know what you think. I'll mark the document in the 
tracker as "Revised I-D Needed".

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: "Gould, James" <[email-masked]>
Date: Tue, 2 Sep 2014 12:45:24 +0000

Pete,

I have a few questions related to your suggestion in adding a new "Document Status" element.  

1. What should the value be for a document that is intended to be Standards Track?  I'm assuming that we would want to register drafts that are intended for Standards Track as they go through the process.    
2. Will this get confused with the possible values defined in RFC 2026 or should we use the values as defined in RFC 2026?  
3. Couldn't the official document status be determined by following the Specification Location in the case of an IETF document?  For those documents that are not IETF documents, then following the Specification Location would not provide a document status.  

Thanks,

Jim
  
________________________________________
From: EppExt [[email-masked]] on behalf of Pete Resnick [[email-masked]]
Sent: Monday, September 01, 2014 11:16 PM
To: [email-masked]
Subject: [eppext] AD Review of draft-ietf-eppext-reg-07

2. In section 3.2.1:

OLD

Also add:

---

NEW

3.2.1:

OLD

NEW

OLD

NEW

OLD

NEW

OLD

OLD

3.2.3:

OLD

3.2.4:

OLD

pr

_______________________________________________
EppExt mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/eppext

---

From: Pete Resnick <[email-masked]>
Date: Tue, 2 Sep 2014 09:19:47 -0500

> 1. What should the value be for a document that is intended to be Standards Track?  I'm assuming that we would want to register drafts that are intended for Standards Track as they go through the p…

This is probably pretty similar to the procedure IANA uses now for other 
registries. They already have the concept of allocating codepoints while 
the document is going through the approval process and filling in the 
data once everything is finalized. I presume they'd put in a "To be 
standards track" or "TBD" or something like during the approval process.

> 2. Will this get confused with the possible values defined in RFC 2026 or should we use the values as defined in RFC 2026?

I was only thinking in terms of "Standards Track" and "Informational", 
but I suppose "Experimental" and "Historic" might also be useful. ("BCP" 
wouldn't be useful.)

> 3. Couldn't the official document status be determined by following the Specification Location in the case of an IETF document?  For those documents that are not IETF documents, then following the…

Yes, you could discover the status just by looking up the document. I 
guess I figured it would be useful for the registry to make it obvious.

pr

---

From: "Gould, James" <[email-masked]>
Date: Tue, 2 Sep 2014 15:07:08 +0000

Pete,

Yes, having an explicit document status would be useful.  Knowing the status would be helpful to know whether or not a document may be of interest to implement, be a candidate for merging, or just be a historical record of its existence.  It may be useful to cover a few use cases to ensure that everything is covered:

1. Registering an existing RFC - I believe this is already covered and could reflect the document status as defined in RFC 2026.
2. Registering an I-D intended for Standards Track - Register with a document status like "To be standards track" or "Intended for Standards Track" 
3. Registering an I-D that falls into a Non-Standards Track ("Informational", "Experimental", "Historic" ), as defined in RFC 2026, - Register with RFC 2026 Non-Standards Track value
4. Registering a non-I-D document - Register with an RFC 2026 Non-Standards Track value
5. Merging documents to a Standards Track document ("Intended for Standards Track") - Insert new document with "Intended for Standards Track" and mark the pre-merge documents as "Historic".  
6. Document moves up Standards Track maturity - Update the document with the appropriate status and new Specification Location.  This could be handled via a new insert and updating the previous version accordingly.  If the insert and update previous version option is taken, is there any need to provide a reference back (e.g. Obsoletes)?  Doing so would pretty much replicate what is already supported in the IETF document, which I believe is unnecessary duplication.    

These are some of the use cases from the top of my head.  Are there others that are missing?

Thanks,

Jim

________________________________________
From: Pete Resnick [[email-masked]]
Sent: Tuesday, September 02, 2014 10:19 AM
To: Gould, James
Cc: [email-masked]
Subject: Re: [eppext] AD Review of draft-ietf-eppext-reg-07

pr

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 2 Sep 2014 18:43:44 +0000

> -----Original Message-----
> From: EppExt [mailto:[email-masked]] On Behalf Of Pete Resnick

It does.

> tracker as "Revised I-D Needed".

I appreciate the suggestions and I'm comfortable with all of them. I'll get a new version out next week barring any on-list disagreement.

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 8 Sep 2014 13:35:40 +0000

> At long last, my AD Review of draft-ietf-eppext-reg-07. My apologies

I just posted draft-ietf-eppext-reg-08. It incorporates all of Pete's suggestions, and one that he didn't explicitly suggest. When I removed the RFC 2119 text I was left with a first section that included only three acronyms. I removed that section and expanded the acronyms where they were first used.

Scott

---

From: Ning Kong <[email-masked]>
Date: Tue, 9 Sep 2014 14:45:55 +0800

Hi Scott,

According to the section 2.2 (Identifying Extensions) of RFC 3735, an EPP extension is uniquely identified by a Uniform Resource Identifier (URI). It seems to me the issue of identifying extensions be covered by the section 2.2.1 of draft-ietf-eppext-reg-08. It says,

I’m confused by the above definition. It seems that the identifying extensions method of draft-ietf-eppext-reg-08 doesn’t follow the RFC 3735. Either an RFC number or some other non-URI pointers may be used to identify the extensions.

BTW, I noticed that even the example form with RFC specification in draft-ietf-eppext-reg-08 doesn’t only use an RFC number as the reference.

So, IMHO, the definition of Reference in draft-ietf-eppext-reg-08 needs to be modified in order to avoid such confusion.

Cheers,
Ning

---

From: Ning Kong <[email-masked]>
Date: Tue, 9 Sep 2014 17:34:20 +0800

I reconsidered the issue I just raised. I think maybe I misunderstood the meaning of Reference in the section 2.2.1 of draft-ietf-eppext-reg-08. The Reference doesn’t mean to be used as identifying extensions, right?

If so, I wonder if the URI used as identifying an extension needs to be added as required information in section 2.2.1. IMO, URIs used to identify the extensions with non-RFC specifications especially need to be coordinated by IANA to avoid conflicts.

Cheers,
Ning

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 10 Sep 2014 16:15:01 +0000

> From: EppExt [mailto:[email-masked]] On Behalf Of Ning Kong
> Sent: Tuesday, September 09, 2014 5:34 AM
> To: Hollenbeck, Scott
> Cc: Pete Resnick; [email-masked]
> I reconsidered the issue I just raised. I think maybe I misunderstood
> the meaning of Reference in the section 2.2.1 of draft-ietf-eppext-reg-
> 08. The Reference doesn't mean to be used as identifying extensions,
> right?

Correct. It's intended to identify the document containing the specification.

> If so, I wonder if the URI used as identifying an extension needs to be
> added as required information in section 2.2.1. IMO, URIs used to
> identify the extensions with non-RFC specifications especially need to
> be coordinated by IANA to avoid conflicts.

Needs to be added? I don't think so since there's already a registry for them and assignments are already being managed by IANA. It is potentially useful information, but it can (or should) be found within the specification itself.

Scott

---

From: Ning Kong <[email-masked]>
Date: Thu, 11 Sep 2014 12:04:15 +0800

> Needs to be added? I don't think so since there's already a registry for them and assignments are already being managed by IANA. It is potentially useful information, but it can (or should) be foun…
Thanks for your clarification. It seems that several other items (e.g. Name of extension, Document Status) can also be found in the specification ;-)

On the other hand, since the specification contains useful information, the reference of it is very important. Just as Pete mentioned, IANA wants a stable reference. To be honest, I don’t think the definition of the reference in this version ensure this requirement. I’m afraid not every “some other pointer” used as reference can make sure the document can be findable and retrievable long after IANA assignment. So I think the definition of the Reference needs to be enhanced to ensure this requirement.

Anyway, I’m OK if the URI used as identifying extension is not be added as required information. But, IMO if the URIs used as identifying extensions can be directly provided by the IANA registry for EPP extensions in future, rather than included within each reference, it would be more convenient for the queriers, especially for the designers of new EPP extensions, to quickly check whether their intended URIs were allocated without needing to read every specifications of the IANA EPP extension registry or jump to another IANA registry for XML to check.

Cheers,
Ning

---

From: Pete Resnick <[email-masked]>
Date: Mon, 15 Sep 2014 10:16:13 -0500

One silly issue that I missed: I note that this document is marked as 
"Proposed Standard". My personal feeling is that creation of registries 
can simply be done as an "Informational" document, though I don't think 
it makes much difference. I can Last Call the document for Proposed 
Standard anyway and let the IESG make the call (one of the few things we 
are empowered to do independently), but I wanted to check: Does anybody 
care strongly one way or the other? If not, I'll note in the Last Call 
that the WG does not care.

pr

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 15 Sep 2014 15:25:38 +0000

> Sent: Monday, September 15, 2014 11:16 AM
> To: [email-masked]

I do not have a preference. Creation of the registry is the important thing.

Scott