Subject: Re: [Enum] [IANA #197380] No IANA feedback for draft-ietf-enum-enumservices-guide-12 received

From: <[email-masked]>
Date: Fri, 3 Oct 2008 10:15:16 +0200

Hi Michelle

Thanks for your answer.

To summarize, in Ticket [IANA #171390] there are basically two open issues:

1) How should the specification look, if an IANA Registry is in XML?

2) Is the process as currently described in draft-ietf-enum-enumservices-guide-12 suitable for IANA? (We made some major changes since our talk in Dublin.)

We would appreciate your answer to these two questions by the end of this week.

cheers,
 Bernie

-----Original Message-----
From: Michelle Cotton via RT [mailto:[email-masked]]
Sent: Wednesday, October 01, 2008 8:02 PM
To: Hoeneisen Bernhard, SCS-NIT-DEV-PDI-ACE-INV; [email-masked]
Subject: [IANA #197380] No IANA feedback for draft-ietf-enum-enumservices-guide-12 received

Bernie,

I will see if it will be possible to have the XML format for enumservices ready by the end of this week.  I will let you know by Friday. As you mention in your message to the ENUM WG, if need be we can have it in the old format and we will convert the registry at a later time.

Thank you for your patience. Look for a message from me by Friday.

Michelle Cotton
IANA

On Tue Sep 30 21:19:56 2008, [email-masked] wrote:
> Dear ENUM WG
>
> In Dublin we have been asked to use the new XMLized policy for IANA
> registrations of Enumservices. According to my knowledge, there is
> neither documentation nor an example on how this is done.
>
> I have sent IANA a draft proposal containing an XML schema and asked
> for guidance on how a specification for an XML Registry should look
> like. I also stressed out the fact that the document was in WG LC.
>
> Result: So far, no answer at all :-(
>
> Does anybody have direct connections to IANA and could remind them to
> resolv the issues collected in ticket [IANA #171390] ASAP?
>
> I there is no answer from IANA by the end of this week, we'll go on
> with the old-style IANA Registry for Enumservices (i.e. forget about
> XML Registry).
> Does anybody have an issue with this approach? Any better proposals on
> how to get out of this lock?
>
> cheers,
>  Bernie
>
>

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

---

From: "Michelle Cotton via RT" <[email-masked]>
Date: Fri, 3 Oct 2008 20:47:35 +0000

Hi Bernie,

I've chatted with our XML folks helping us with the conversions. (They are
copied on this message) 
They will begin converting the current registry next week.
See more responses inline below.

> 1) How should the specification look, if an IANA Registry is in XML?

If someone writes a document to add a new registration to the enum-services
registry, it would be great if they included in their document an XML chunk that
IANA would simply cut and paste in the registry itself after the registration is
approved. The spec itself does not have to be in XML.

> 
> 2) Is the process as currently described in draft-ietf-enum-
>    enumservices-guide-12 suitable for IANA? (We made some major
>    changes since our talk in Dublin.)

I've reviewed version 12 of the document.  All seems pretty good.  I do have the
following comments:

In section 11.1.2., I understand that it is requested that IANA archive the
specification in the cases of it not being an RFC.  Will IANA need to make that
document public or just archive it for purposes of inquires and registration?

I see the use "Authors" frequently.  We mainly use the term "Requester".  

The expert review process in this document is slightly different than the one
that IANA currently uses.  For most registries, requests are sent to IANA, we
forward the request to the expert for review, after the approval IANA registers
the parameter and then notifies the requester of the completed registration.

In this case, the expert is approving the template and it appears they also have
to approve the specification after it is published?  It seems a bit fuzzy to me.
Or is this the case where the expert my assist in making the template better
before it gets finalization in a document?  If that is the case, then IANA will
have to go to the expert twice in this case?  Once for the enumservice template,
and then second to verify the specification has been published.

Tell me if I'm mistaken in my understanding of the instructions. :)

Also, for the document, having the xml chunk for the registration itself would
be very useful. We can help with providing what that should look like as we
convert the registry in the next few weeks.

> We would appreciate your answer to these two questions by the end of

I hope this helps.  Please let us know if you have any further questions.

Best regards,

Michelle
IANA

---

From: Bernie Hoeneisen <[email-masked]>
Date: Mon, 6 Oct 2008 19:34:31 +0200 (CEST)

---------- Forwarded message ----------
Date: Sun, 5 Oct 2008 19:18:34 +0200 (CEST)
From: Bernie Hoeneisen <[email-masked]>
To: Michelle Cotton via RT <[email-masked]>
Cc: IETF ENUM list <[email-masked]>, [email-masked],
     [email-masked]
Subject: Re: [IANA #171390] Revision of IANA Enumservice registry

Hi Michelle

Thanks for your timely answer. My comments inline.

On Fri, 3 Oct 2008,  Michelle Cotton via RT wrote:

--------

1)

> registry, it would be great if they included in their document an XML chunk 
> that IANA would simply cut and paste in the registry itself after the 
> registration is approved. The spec itself does not have to be in XML.

If you provide us with an example, we'd be more than happy to include an XML 
chunk to -13. (See also 5) further below)

--------

2)

> specification in the cases of it not being an RFC.  Will IANA need to make 
> that document public or just archive it for purposes of inquires and 
> registration?

As per -12, the latter applies. It is just an escrow copy, in case the 
specification is lost or it is unclear, which version applies.

It might be a good idea to address this escrow copy stuff in rfc5226bis, as DNS 
folks have the same problem...

--------

3)

> I see the use "Authors" frequently.  We mainly use the term "Requester".

Hmmm...The Author of the specification is the Requester of the registration. 
I'll have to think about.

--------

4)

> forward the request to the expert for review, after the approval IANA 
> registers the parameter and then notifies the requester of the completed 
> registration.

Do these IANA registries also use "Specification Required" as per RFC 5226?

I see your point. The document attempts to ensure both requirements: "Expert 
Review" and "Specification Required".

In other words, before IANA can add the Enumservice to the Registry, there 
needs to be a Specification according to RFC 5226. Usually this is not the case 
at the time the expert reviews the Enumservice. Expert Review might result in 
changes.

> In this case, the expert is approving the template and it appears they also 
> have to approve the specification after it is published?  It seems a bit 
> fuzzy to me.
> before it gets finalization in a document? If that is the case, then IANA 
> will have to go to the expert twice in this case?  Once for the enumservice 
> template, and then second to verify the specification has been published.

After the Experts have approved the specification it is published somewhere. 
After publication, IANA gets a request to add the Enumservice to the Registry.

No further Expert Review is needed at that point in time, but it needs to be 
ensured the published version is the same as the one approved earlier by the 
Experts (and the requirements for "Specification Required" according to RFC 
5226 are met).

I am not really happy with this part of the process, but I see no alternative 
to ensure publication according to RFC 5226. Please tell us, if you see a 
better way to acomplish the same goal.

I have a feeling, this is an issue for rfc5226bis...

-----------

5)

> Also, for the document, having the xml chunk for the registration itself 
> would be very useful. We can help with providing what that should look like 
> as we convert the registry in the next few weeks.

As the IANA template of the Enumservice registry is about to change, I 
recommend to wait.

draft-hoeneisen-enum-enumservices-transition-01 is addressing these changes for 
the existing services. If we get an example of an XML chunk, we'll publish a 
revision of the enumservices-transition I-D, which will include all existing 
registrations (including the template changes) as XML chunks.

----------

cheers,
  Bernie

---

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 10 Oct 2008 14:48:53 +0200 (CEST)

Hi Michelle

Ist is feasible to get an example XML chunk by TODAY so that we 
can work on it during the weekend? (see also below)

cheers,
  Bernie

---------- Forwarded message ----------

1)

[...]

5)

---

From: "Michelle Cotton via RT" <[email-masked]>
Date: Tue, 14 Oct 2008 15:51:46 +0000

Bernie,

The XML chunk for the new version of the registry is not quite completed yet but we are working to 
have that done.  We need some help answering some questions to help transition from the current 
registry to the revised registry.  See below.

Please let me know if I've missed something.  We've been exchanging lots of information and I want to 
make sure that I'm not missing anything.

Michelle

Here is a list of questions that must be answered before we can convert
to the new style (i.e. draft-ietf-enum-enumservices-guide):

- In the old style, registrations have a "Service Name". This is absent
in the new style. It isn't clear if this is intentional. If so, do we
remove the column or do we leave it as optional?

- I'm having trouble understanding the following instruction from
Section 11.1.3:

   Each Enumservice starts with a caption, which is composed of Type and
   Subtype, separated by a colon; e.g. if the Type is "foo" and the
   Subtype "bar", the resulting caption is "foo:bar".

Do we need to create a new column such as the following?

+---------------+--------+----------+-...
|    Caption    |  Type  | Subtype  |
+---------------+--------+----------+-...
| "ifax:mailto" | "ifax" | "mailto" |
+---------------+--------+----------+-...
|      ...      |  ...   |   ...    |

- No registration in the old style have an "Enumservice Class". This is
required in the new style. What do we do? Some ideas:
  - Go to authors of old-style registrations and ask them to define one.
  - Assuming all previous registrations belong to the same class, assign
this class.
  - Make the class optional in the schema and trust IANA editors to
provide one for new registrations. This reduces the schema's
bug-catching power.

- This note in Section 5.2 seems to contradict current IANA practices:

      Note: You MUST NOT put email addresses in the authors field of an
      IANA Registration.

Does this mean one of the following?
  - There will be no registration contact info.
  - There will be separate columns "Author" and "Registrant", the latter
containing contact info.
  - Contact info is expected to be extracted from the registration document.
  - The note should be revised.

- Some old-style registrations have no registration document.

- Some old-style registrations have no type.

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Wed, 15 Oct 2008 17:15:44 +0200

> The XML chunk for the new version of the registry is not 
> quite completed yet but we are working to 
> Please let me know if I've missed something.  We've been 
> exchanging lots of information and I want to 

Michelle,

i'm one of the co-authors of the document. Please find my responses

> remove the column or do we leave it as optional?

Please remove the column. It was never really specified, and the ENUM WG
decided to remove it - it does not have any additional value.

> Do we need to create a new column such as the following?

No, this is not needed for the registration - This was intended as a
"display headline" for the registration. The "caption" can be created
from Type and Subtype, as indicated in the text above.

> provide one for new registrations. This reduces the schema's

We are working on a draft that assigns such Class information to all
existing Enumservices - see
http://tools.ietf.org/html/draft-hoeneisen-enum-enumservices-transition-
01

>   - The note should be revised.

Contact info is expected to be expected from the registration document.
Please indicate if there are other preferences.
 
> - Some old-style registrations have no registration document.

Should be fixed by the transition draft.

> - Some old-style registrations have no type.

huh? Can you name one?
 
thanks,

Alex

---

From: Simon Perreault <[email-masked]>
Date: Wed, 15 Oct 2008 14:35:58 -0400

> from Type and Subtype, as indicated in the text above.

We understand that the Caption field will not be present in the
registry's XML source data.

Now, on the presentation side of things, I want to make sure we really
understand what's desired. We could generate the Caption column from the
XML data so that it would show on the XHTML rendering available on
IANA's website.

It's a cosmetic issue exactly like showing the double quotes around Type
and Subtype, and the single quotes around the URI Scheme. These quotes
are not present in the XML data. They are automatically added when
converting to XHTML for presentation on IANA's website.

> http://tools.ietf.org/html/draft-hoeneisen-enum-enumservices-transition-

Thanks for the pointer. We'll make the class optional in the schema
until this draft is finalized.

> Should be fixed by the transition draft.

We'll also make the registration document optional in the schema until
the transition draft is finalized.

>> - Some old-style registrations have no type.

There are two of them:

Service Name: "H323"
     URI Scheme(s): "h323:"
     Functional Specification:  See Section "3. The E2U+H323 ENUM
Service" of [RFC3762]
     Security considerations: see section "5. Security Considerations"
of [RFC3762]
     Intended usage: COMMON
     Author: Orit Levin
     [RFC3762]

Service Name: "pres"
    URI Scheme(s): "pres:"
    Functional Specification: see Section 4 of [RFC3953]
    Security considerations: see Section 6 of [RFC3953]
    Intended usage: COMMON
    Author: Jon Peterson (jon.peterson&neustar.biz)
    Any other information that the author deems interesting: See
    Section 3 of [RFC3953]
    [RFC3953]

-- 
Please try Numb, a STUN/TURN server implementation.
Free access at http://numb.viagenie.ca/.
_______________________________________________
enum mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/enum

---

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 17 Oct 2008 14:18:02 +0200 (CEST)

Hi Michelle

Thanks your the help with the XML stuff. (Alex, my co-author, will track 
the XML issue for the time being.)

There is one more question I'd like get your opinion on: You expressed, 
that the process specified in draft-ietf-enum-enumservices-guide-12 is new 
to IANA. (Below you can find the background information on why I've 
proposed it that way.)

Is the process as specified in draft-ietf-enum-enumservices-guide-12 fine 
with you? Or do you have an idea on how to make it simpler, still meeting 
the requirements?

Could you provide us with an answer by today?

cheers,
  Bernie

On Mon, 5 Oct 2008, Bernie Hoeneisen wrote:
>> The expert review process in this document is slightly different than the 
>> one that IANA currently uses.  For most registries, requests are sent to 
>> IANA, we forward the request to the expert for review, after the approval 
>> IANA registers the parameter and then notifies the requester of the 
>> completed registration.
>
> needs to be a Specification according to RFC 5226. Usually this is not the 
> case at the time the expert reviews the Enumservice. Expert Review might 
> result in changes.
>
>> Or is this the case where the expert my assist in making the template 
>> better before it gets finalization in a document? If that is the case, then 
>> IANA will have to go to the expert twice in this case?  Once for the 
>> enumservice template, and then second to verify the specification has been 
>> published.
>

---

From: "Michelle Cotton via RT" <[email-masked]>
Date: Fri, 17 Oct 2008 21:11:56 +0000

> the XML issue for the time being.)

Great, we look forward to finishing that up with Alex.

> Could you provide us with an answer by today?

Bernie, I have reviewed the IANA Considerations section in version 12 of the
document once more.  Most everything does seem ok.
I do have a couple comments.

I still feel the review described here does not exactly follow what is described
in RFC5226, so it might be worth stating that it follows RFC 5226 with some
additional procedures.

When a registration is first reviewed by an expert and then is approved.  IANA
will notify the author (requester).  At that time, it seems that the
registration is then put "on hold" waiting for the publication of the
specification. When IANA has these requests in our ticketing system, is it
sufficient to put this request as "waiting on the requester" as IANA waits to be
informed the spec has been published? Is there a time limit of how long IANA
waits?  This means IANA will have a ticket open for a long time in our queue.

Also.  For section 11.2, does IANA really need to make the xml2rfc template
public or is having it in this document enough?  Also, will you be adding the
"chunk" for the registry when it is finalized for future registrations?

Hope this review helps.

Michelle Cotton
IANA

---

From: Bernie Hoeneisen <[email-masked]>
Date: Mon, 20 Oct 2008 01:39:26 +0200 (CEST)

Michelle,

Thanks for your fast feedback.

I have changed the document to make it more clear, i.e. I made a 
difference between RFC specs and other specs. RFC specs follow the normal 
IETF procedures, non-RFC specs are handled slightly different (as outlined 
below).

The XML2RFC template is no longer part of the document, so no worries 
here.

The only comment I have not addressed (yet) is the time limit. Does 
this really have to be specified? If yes, what would be good figure?

cheers,
  Bernie

---

From: "Michelle Cotton via RT" <[email-masked]>
Date: Mon, 20 Oct 2008 20:57:18 +0000

Hello Bernie,

Will there be a version 13 to look at?  I just checked and didn't see one.
I didn't see any response to how IANA will categorize the request's stages as
far as our tracking goes so hopefully what I outlined below as ok (as far as
waiting on requester).

For the time limit, it is a bit hard...
So if the documentation is going to be in the form of an RFC, maybe the ticket
should just be closed after the registration is approved by the expert, as the
addition of the service name would follow the normal RFC publication process and
be part of the approval.  The only thing is that the expert would need to review
it as part of the approval.

For the other types of documentation, it really depends on how long other types
of documents take to get published.

We could just resolve the request after the expert approves the template. Then
open a new request when the documentation has been published and then have the
expert do the second review then.

What are your thoughts?

Thanks,

Michelle