Subject: [Enum] enum services registry question

From: Edward Lewis <[email-masked]>
Date: Fri, 4 Jan 2008 10:55:46 -0500

On http://www.iana.org/assignments/enum-services, most/some/recent 
entries lack an explicit reference to an RFC for the definition.  All 
have some reference, the early ones (pre-RFC 4002) IANA (or someone) 
put in an RFC tag at the end of the registration record but in the 
later ones the reference is more oblique, such as this:

# Enumservice Name: "XMPP"
#    Enumservice Type: "xmpp"
#    Enumservice Subtype: n/a
#    URI Schemes: "xmpp"
#    Functional Specification:
#       This Enumservice indicates that the resource identified is an XMPP
#       entity.
#    Security Considerations: see Section 6 of [RFC4979]
#    Intended Usage: COMMON
#    Author: (don't want to make it seem I'm picking on just this entry ;))

The only reference to an RFC here and in others is in the Security 
Considerations.

I'd suggest that registrants make an explicit statement in the 
functional specification area indicating the RFC (number available 
when published of course) with the full specification.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 4 Jan 2008 20:39:41 +0100 (CET)

Hi Ed

On Fri, 4 Jan 2008, Edward Lewis wrote:

> [...]

Intersting catch. We can take this into consideration for the updated IANA 
Enumservices registration template.

> I'd suggest that registrants make an explicit statement in the functional 
> specification area indicating the RFC (number available when published of 
> course) with the full specification.

There will be additional fun to figure out, how this will work with 
the new regime (as decided in Vancouver), where an RFC will no longer be 
required for registering an Enumservice...

cheers,
  Bernie

---

From: Edward Lewis <[email-masked]>
Date: Fri, 4 Jan 2008 14:50:15 -0500

At 20:39 +0100 1/4/08, Bernie Hoeneisen wrote:

>There will be additional fun to figure out, how this will work with the new
>regime (as decided in Vancouver), where an RFC will no longer be required
>for registering an Enumservice...

Heh, well, I'd settle for any kind of reference for the enumservices 
*and* the URI schemes!

Consider this a lesson learned from IANA registrations of DNS 
parameters.  We have some RR types 
(http://www.iana.org/assignments/dns-parameters) defined only by a 
human - a name and an email address.  It takes a good bit of googling 
to find any notes stuffed in other, non-IETF, corners of the 
net-universe to find the specifications.  Even having sent fixes to 
IANA hasn't (completely) rectified the problem of missing documents 
and broken references.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Bernie Hoeneisen <[email-masked]>
Date: Mon, 7 Jan 2008 11:27:37 +0100 (CET)

Hi Ed,

http://tools.ietf.org/id/draft-narten-iana-considerations-rfc2434bis-08.txt
gives some guidance in this (section 4.1.):

  Specification required - Values and their meaning must be
    documented in an RFC or other permanent and readily
    available public specification, in sufficient detail so
    that interoperability between independent implementations
    is possible. When used, Specification Required also implies
    usage of a Designated Expert, who will review the public
    specification and evaluate whether it is sufficiently clear
    to allow interoperable implementations. The intention
    behind "permanent and readily available" is that a document
    can be reasonably be expected to easily be found long after
    IANA assignment of the requested value. Publication of an
    RFC is the ideal means of achieving this requirement. [...]

The term "permanent and readily available public specification" states the 
intension, but I think it is a bit vague, when it comes to what qualifies 
to this term. Furthermore it does not say much about the change management 
of such a specification.

To be on the safe side, I guess we should ensure that a copy of the 
specification (as reviewed by expert) is always maintained at IANA, 
unless there is an RFC (that can be simply referenced).

On the other hand, this looks like an issue to be solved on rfc2434bis 
level. (I therefore have CC:ed the authors of rfc2434bis to this email.)

Propsosal:

  Unless there is some better solution proposed, I'll put a section
  "reference" to the new IANA template in
  draft-ietf-enum-enumservices-guide.
  There can be either a reference to the RFC or an IANA internal reference
  to the version of the specification after approval by the experts.

Makes sense?

cheers,
  Bernie

PS: It would be quite a bit easier, if we decided on "RFC required" 
instead...;-)

On Fri, 4 Jan 2008, Edward Lewis wrote:

> Heh, well, I'd settle for any kind of reference for the enumservices *and* 
> the URI schemes!
>
> Consider this a lesson learned from IANA registrations of DNS parameters.  We 
> have some RR types (http://www.iana.org/assignments/dns-parameters) defined 
> only by a human - a name and an email address.  It takes a good bit of 
> googling to find any notes stuffed in other, non-IETF, corners of the 
> net-universe to find the specifications.  Even having sent fixes to IANA 
> hasn't (completely) rectified the problem of missing documents and broken 
> references.
> --

---

From: Bernie Hoeneisen <[email-masked]>
Date: Mon, 7 Jan 2008 11:27:37 +0100 (CET)

Hi Ed,

Propsosal:

Makes sense?

cheers,
  Bernie

---

From: Edward Lewis <[email-masked]>
Date: Mon, 7 Jan 2008 08:54:18 -0500

At 11:27 +0100 1/7/08, Bernie Hoeneisen wrote:

>The term "permanent and readily available public specification" states
>the intension, but I think it is a bit vague, when it comes to what
>qualifies to this term. Furthermore it does not say much about the change
>management of such a specification.
>

This is the specific situation I have run into.  There is a DNS RR 
type - as far as I know no one uses - called ATMA.  It was developed 
and then documented by the ATM Forum. The document was available on 
the ATM Forum's website.

The ATM Forum ceased operations quite a while ago and became part of, 
hmmm, some other organization whose name now escapes me.  Within the 
last year I exchanged email with members there but after being 
promised a response to a question about getting the document 
published under the name of the IETF the "line went dead."

So today we have an entry in the DNS RR type registry that has no 
reliable definition.  I haven't gotten permission from the successor 
organization to copy the document into the RFCs.  IANA is not 
equipped to archive documents so they can't just arrange to host the 
document - two issues, one is the mechanics and the other is the 
intellectual property.  We are also stuck without the ability to 
obsolete the registration because no one is willing to declare it 
dead without knowing who is using it.

So far what I've described is just a paperwork and bookkeeping 
migraine headache.  The reason I ever started to look into this was 
when I was asked to write DNSSEC code separate from any other 
implementation (in the 90's) and tried to research DNS from the 
specifications and not "what would BIND do?"  When asked if my code 
handled "all the types" I wanted to be sure of the answer.

If you were to build an implementation from scratch, that's when it matters.

(I realize I'm not throwing out a solution.  This is a reflection of 
my experience in DNS and why I stopped to make the comment.)

>level. (I therefore have CC:ed the authors of rfc2434bis to this email.)

Do you have a URL for that document?

>  to the version of the specification after approval by the experts.

The issue is the "IANA internal reference" as I mentioned before.

>PS: It would be quite a bit easier, if we decided on "RFC required"

It certainly would be easier, but that means the RFC-Editor and IETF 
are creating a monopoly on what goes into IANA.  I believe that is 
undesired by the powers that be.  (I think the same was said in the 
DNS group talking about their IANA instructions "bis" document.)

---

From: Edward Lewis <[email-masked]>
Date: Mon, 7 Jan 2008 14:09:45 -0500

At 19:27 +0100 1/7/08, Bernie Hoeneisen wrote:

>(BTW: This URL was already in my last email....)

And yet somehow I missed it.  Maybe I slept through reading the start 
of the message. ;)

>I don't think it is impossible to convince IANA to maintain such a document
>base. However, this certainly needs to be discussed with IANA and the
>authors of rfc2434bis.

We will see, that other document I talked about will be a test case (for me).

>I do not see a monopoly issue here. AFAIK everybody can publish an
>informational RFC as an individual submission and I do not see a valid
>reason for the RFC editor to object an Enumservice registration document.
>Or do I miss anything here?

Not everyone is willing to brave the slings and arrows of the IETF process.

---

From: Bernie Hoeneisen <[email-masked]>
Date: Mon, 7 Jan 2008 19:27:40 +0100 (CET)

Hi Ed,

> The issue is the "IANA internal reference" as I mentioned before.

I don't think it is impossible to convince IANA to maintain such a 
document base. However, this certainly needs to be discussed with IANA 
and the authors of rfc2434bis.

> It certainly would be easier, but that means the RFC-Editor and IETF are 
> creating a monopoly on what goes into IANA.  I believe that is undesired by 
> the powers that be.  (I think the same was said in the DNS group talking 
> about their IANA instructions "bis" document.)

cheers,
  Bernie

---

From: Edward Lewis <[email-masked]>
Date: Mon, 7 Jan 2008 16:16:06 -0500

(If you want to skip my embellishment of the DNS case, here's the 
last paragraph, which relates back to ENUM.)

The goal is to be able to look at IANA for parameters and then find 
definitions of each via resolvable references.  For ENUM, a reference 
to an RFC (if that is the vehicle) ought to be explicit.  If it is 
another document, a fully fledged reference (not just a URL) is 
helpful.  And if it matters over the long haul, there should be 
someone making sure the registrations are up to date.

At 15:49 -0500 1/7/08, Thomas Narten wrote:
>And we should only do this if we are worried that a
>particular document is important and might "go away" at some point in
>the future. Is the document in question of this type?

In the situation I have described, the document has not been 
changing, is not in danger of being retired, and has been and 
continues to be publicly available.  The problem has been that the 
entry in the IANA registry has never pointed to the document nor has 
the entry been tracking the transfer of the document from one 
organization to another.

It's not the document, it's the static nature of the registration 
that is the issue.

The desire to have IANA only refer to RFCs lies in the shared fates 
of the IETF and IANA.  If one goes down, the other certainly will 
know about it.  Other organizations are capable of accomplishing what 
the IETF does (specifically here putting documents in public spaces 
for perpetuity) but there may or may not be enough cross-activity to 
maintain the registration.

I should add, specific to my case, it's not a matter of the URL 
changing.  The IANA registration doesn't even have the title of the 
document, only the personal name of the author and the email address 
I suppose the request came in on.  I had to track the document down 
by googling his name to find current employment, topic, etc., etc., 
and then maintain this searching over the years of while trying to 
get IANA to retain the information.  Even now, IANA still doesn't 
publish any more than the person's name and a defunct email address - 
despite my sending them notes on this.

Sorry to go on - this isn't an ENUM issue, but it is my experience 
with protocol parameter registries when the rules are not tight 
enough.  What would fix the case I am drawing upon is either 
mirroring all needed documents, maintaining liveness on all 
references (and at least have titles!), and or the ability to mark a 
registration as "historic" if there is no published reference 
publicly available.  (Really, I don't hold grudges or anything - I 
just don't want to see the same problem pop up with ENUM.)

BTW, the same DNS RR registry has other problematic registration 
references in which the issue isn't cross-organization. There are a 
few that are defined by retired internet drafts retrievable from 
those who maintain such things on their own.

The goal is to be able to look at IANA for parameters and then find 
definitions of each via resolvable references.  For ENUM, a reference 
to an RFC (if that is the vehicle) ought to be explicit.  If it is 
another document, a fully fledged reference (not just a URL) is 
helpful.  And if it matters over the long haul, there should be 
someone making sure the registrations are up to date.

---

From: Thomas Narten <[email-masked]>
Date: Mon, 07 Jan 2008 15:49:09 -0500

>     RFC is the ideal means of achieving this requirement. [...]

FWIW: the next version of this document expands on the above by
adding:

	     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.
             Publication of an RFC is an ideal means of achieving this
             requirement, but Specification Required is intended to also
             cover the case of a document published outside of the RFC
             path. For RFC publication, the normal RFC review process is
             expected to provide the necessary review for
             interoperability, though the Designated Expert may be a
             particularly well-qualified person to perform such a
             review.

> to this term. Furthermore it does not say much about the change management 

Correct. We can't know in advance which documents (that have already
been pubished somehow) meet the test, so some common sense is
needed. If a document is already published somewhere, and it is clear
that the publication is permanent, there is really no need to also
have a copy available elsewhere. It would be OK to do so, but it
should not be required.

> unless there is an RFC (that can be simply referenced).

I'm not opposed to this, but I also think we need to remember that the
IETF is not the only ogranization capable of publishing documents
"permanently". And we should only do this if we are worried that a
particular document is important and might "go away" at some point in
the future. Is the document in question of this type?

Thomas

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 08 Jan 2008 08:11:25 +0100

> the future. Is the document in question of this type?
I think there are 2 failure modes we're trying to guard against here:

1) Being totally unable to find the specification underlying a
codepoint. In these Google-infested times, that's rarely going to be a
problem.

2) Having 2 people holding incompatible versions of the specification
both claiming that "THIS is the specification that was registered". In
that case, any stable identifier (ISBN number, standards organization +
document serial number, author + spec name + date....) will do to
adjudicate the case.

So I think the stability of the identifier is critical. Having a copy of
the document is also nice.

                   Harald

---

From: Bernie Hoeneisen <[email-masked]>
Date: Tue, 8 Jan 2008 10:25:14 +0100 (CET)

Hi Harald

Thanks for the excellent summary.

However, it covers just the cases, when there is already a problem. I'd 
rather like to see _avoiding_ such problems or confusions in the first 
place. Thus, I'd prefer to make it _clear_ from the beginning, which 
specification applies. This leads to an URL pointing to a stable place of 
the spec. A stable place is certainly fullfilled in the RFC case. Also 
many other (standards) organizations have such means. But there are always 
cases, where maintaining a copy of the spec locally is more than just a 
nice-to-have. IMHO the best place for this would be IANA. To be on the 
safe side, IANA maintaining a copy of every spec related to a IANA 
codepoint looks like a good idea to me.

cheers,
  Bernie

---

From: Edward Lewis <[email-masked]>
Date: Tue, 8 Jan 2008 09:50:16 -0500

Thanks Harald, for the summary.  I hadn't thought of your second 
point, but that is true, without a clearly defined reference if there 
are two purported definitions it may not be clear which is the 
legitimate one.

I was told, by a librarian-type person, some years ago that URLs are 
not really good references.  They are good ways to locate something 
but there are too many variable in the resolution of a URL to make it 
ever considered stable.  I've been biased by that claim against ever 
saying that a URL is sufficient.

Does IANA archive documents now?  I certainly would like that but I 
don't know if it is within the scope of the contracted-role they have.

In any case, the enumservices registry ought to have references that 
are traceable as well as pointers to available copies of the 
documents.

At 10:25 +0100 1/8/08, Bernie Hoeneisen wrote:
>However, it covers just the cases, when there is already a problem. 
>I'd rather like to see _avoiding_ such problems or confusions in the 
>first place. Thus, I'd prefer to make it _clear_ from the beginning, 
>which specification applies. This leads to an URL pointing to a 
>stable place of the spec. A stable place is certainly fullfilled in 
>the RFC case. Also many other (standards) organizations have such 
>means. But there are always cases, where maintaining a copy of the 
>spec locally is more than just a nice-to-have. IMHO the best place 
>for this would be IANA. To be on the safe side, IANA maintaining a 
>copy of every spec related to a IANA codepoint looks like a good 
>idea to me.
>
>cheers,
>  Bernie
>

---

From: Bernie Hoeneisen <[email-masked]>
Date: Tue, 15 Jan 2008 14:24:43 +0100 (CET)

Dear ENUM list,

Below a summary on the issue and the options to go forward with 
the enumservices-guide I-D concerning external references.

   Please send your options until the end of this week to this list,
   so that we can go on with the enumservices-guide I-D!

As a consequence of the "specification required" decision, there needs to 
be a means to ensure permanent storage of the specification, if not RFC.

Options:

1) Leave the issue totally to the narten I-D and IANA.
Don't deal with it in enumservices-guide I-D.

2) In case the specification is not published as RFC, instruct IANA to 
store a copy of the specification as rewiewed by expert.
(Results in either reference to RFC or IANA internal reference.)
Require such a reference in the IANA template for Enumservice 
registrations.

3) Add an exact (external) reference to specification in the IANA template 
for Enumservice registrations. Leave the rest to the narten I-D.

In case no other opinion is stated to the list until the end of this week, 
I'll take it as ENUM WG consensus and move on with option 3).

Questions? Comments? Opinions?

cheers,
  Bernie

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 15 Jan 2008 14:40:16 +0100

Bernie Hoeneisen wrote:
> 3) Add an exact (external) reference to specification in the IANA 
> template for Enumservice registrations. Leave the rest to the narten I-D.
>
>
> In case no other opinion is stated to the list until the end of this 
> week, I'll take it as ENUM WG consensus and move on with option 3).
3).

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 15 Jan 2008 15:10:38 +0100

On 15 jan 2008, at 14.40, Harald Alvestrand wrote:

>> In case no other opinion is stated to the list until the end of  
>> this week, I'll take it as ENUM WG consensus and move on with  
>> option 3).
> 3).

As a wg participant, yes I also think (3) is best.

    paf

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Jan 2008 10:24:30 -0500

>template for Enumservice registrations. Leave the rest to the narten I-D.

Number 3.

>Questions? Comments? Opinions?

I would add this: if the document is not an RFC then IANA will hold 
in escrow a copy of the document.  Not republish it, but have a copy 
available in case the document is no longer accessible via other 
means.

This is the path we will take for the DNS document I wrote about.

If the document is static, that's sufficient.  If the document is 
still alive, then IANA ought to hold in escrow the latest copy.  (How 
IANA is alerted to get a new copy I'm not saying now.)

---

From: Bernie Hoeneisen <[email-masked]>
Date: Tue, 15 Jan 2008 17:02:01 +0100 (CET)

Hi Ed, Thomas, Harald et al.

Interesting approach IANA to hold an escrow copy.

I would suggest, that this should go to
draft-narten-iana-considerations-rfc2434bis
as it is an issue that applies to all cases with "specification required".

What do the authors of rfc2434bis (Thomas, Harald) think about?

cheers,
  Bernie

On Tue, 15 Jan 2008, Edward Lewis wrote:

> I would add this: if the document is not an RFC then IANA will hold in escrow 
> a copy of the document.  Not republish it, but have a copy available in case 
> the document is no longer accessible via other means.
>
> If the document is static, that's sufficient.  If the document is still 
> alive, then IANA ought to hold in escrow the latest copy.  (How IANA is 
> alerted to get a new copy I'm not saying now.)

---

From: Bernie Hoeneisen <[email-masked]>
Date: Mon, 21 Jan 2008 13:05:10 +0100 (CET)

Dear ENUM WG

We can declare consensus on option numer 3).

Still open issue:
Will 'draft-narten-iana-considerations-rfc2434bis' deal with the escrow 
copy stuff, or do we need to handle this in enumservices-guide (as well as 
e.g. Ed in the DNS extensions document and so on)?

cheers,
  Bernie

On Tue, 15 Jan 2008, Bernie Hoeneisen wrote:

>> I would add this: if the document is not an RFC then IANA will hold in 
>> escrow a copy of the document.  Not republish it, but have a copy available 
>> in case the document is no longer accessible via other means.
>>