Poll: external references in Enumservice Registrations (was: enum services registry question)

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




On Mon, 7 Jan 2008, Thomas Narten wrote:

> Bernie Hoeneisen <[email protected]> writes:
>
>> 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. [...]
>
> 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.
>
>
>> 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.
>
> 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.
>
>> 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).
>
> 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
>
> _______________________________________________
> enum mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/enum
>