Hi Miguel / Russ
I have added "(conditionally)" to mitigate the risk of confusion:
In case changes between the (conditionally) approved and the
to be published version are substantial, IANA MAY reject
the request after consulting the experts.
Does this change together with the explanations I gave last week (see
below) address your concerns?
cheers,
Bernie
On Wed, 16 Jun 2010, Bernie Hoeneisen wrote:
Hi Miguel
On Wed, 16 Jun 2010, Miguel A. Garcia wrote:
- Section 11.6.1 discusses the process of registering Enumservices through
the publication of an RFC. I don't understand the purpose of the second
paragraph, which chances the process to IANA. The text reads:
IANA MUST only add Enumservices to the Registry, if the experts have
approved the corresponding Enumservice Specification as to be
published. IANA SHOULD attempt to resolve possible conflicts arising
from this together with the experts. In case changes between the
approved and the to be published version are substantial, IANA MAY
reject the request after consulting the experts.
My problem is related to the process. If a document has gone through the
RFC publication process, I expect that experts have inspected the document
and approved the Specification prior to publication as an RFC, as part of a
regular RFC process. This process may differ between standard track RFCs
and individual submissions, but in any case, experts are involved in the
RFC publication process, and the RFC will not be published if experts voice
against the document. Or when do the authors expect that an Internet-Draft
could be published without expert review?
So, I think that for RFCs, IANA does not need to do anything different from
what they are doing today.
Before the document goes to the IETF process, the experts will review it.
Afterwards, it is not guaranteed that the experts remain in the process. If
there are no changes until the document arrives ar IANA, no problem. If there
are changes, IANA needs somebody to have a look at the latest version.
We added this sentence to ensure the experts have a chance to verify possible
changes are fine in any case.
Note: Not too long time ago, there was a case where major flaws got
introduced as a result of the IESG processing. We noticed this during auth48
and it was rather painful to handle this case.
I hope this addresses you concerns.
cheers,
Bernie
--
http://ucom.ch/
Tech Consulting for Internet Standardization
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
