[IANA #171390] FW: Revision of IANA Enumservice registry

On Fri Oct 17 12:18:01 2008, [email protected] wrote:
> Hi Michelle
> 
> Thanks your the help with the XML stuff. (Alex, my co-author, will
> track
> the XML issue for the time being.)

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


> 
> 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
> 

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



> 
> On Mon, 5 Oct 2008, Bernie Hoeneisen wrote:
> >
> >On Fri, 3 Oct 2008,  Michelle Cotton via RT 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.
> >
> > 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.
> >> 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.
> >
> > 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...
>