Hi Miguel, I expressed exactly this concern in my DISCUSS on this I-D. During the IESG telechat last Thursday, Michelle Cotton of the IANA explained that:
(1) there is agreement to try this approach for this registry (2) the RFC Editor and the IANA are in agreement here (3) proposed changes to RFC 5226 are on the way Michelle will be following up on these matters (with Bernie) so that they are clearly communicated to the IESG and all other relevant parties. I'm holding my DISCUSS until that happens. Peter On 6/21/10 12:00 AM, Miguel A. Garcia wrote: > Hi Bernie: > > Your proposal does not solve my concern. My concern is very clear: you > are changing the IANA process to make the get the green light from > experts before editing a registry, even for a document that has gone > through the regular RFC process. > > This could hint that the RFC process is flawed, and that you need to > change the IANA process to reinforce them. And I don't think IANA is > going to change their way of working just for this RFC. > > /Miguel > > On 20/06/2010 15:33, Bernie Hoeneisen wrote: >> 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 >>>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
