Is there a reason that RFC 5620 (RFC Editor Model Version 1) has not been taken into account while doing this update? It would seem that this could change some of the processes from what they are today. Jim > -----Original Message----- > From: rfc-interest-bounces@xxxxxxxxxxxxxx [mailto:rfc-interest- > bounces@xxxxxxxxxxxxxx] On Behalf Of Jari Arkko > Sent: Saturday, September 19, 2009 1:35 AM > To: IETF Discussion; RFC Interest; IAB > Cc: Olaf M. Kolkman; Harald Tveit Alvestrand; Russ Housley > Subject: Re: [rfc-i] path forward with RFC 3932bis > > As you may recall, my conclusion of the discussion was that while > opinions were split, a dispute resolution model emerged as a potential > compromise. A week ago I promised that we would come up with a specific > proposal. Russ, Olaf, Harald and myself have now worked on this. In the > process we have realized that the devil is in the details, but we do > have a proposal that we believe addresses the various interests in an > acceptable manner. The full updated draft is at > http://tools.ietf.org/html/draft-housley-iesg-rfc3932bis-09 but the > important part is copied here for your convenience: > > Experience has shown that the IESG and the RFC Editor have worked > well together regarding publication recommendations and IESG notes. > Where questions have arisen, they have been quickly resolved when > all > parties become aware of the concerns. However, should a dispute > ever > arise, a third party can assist with resolution. Therefore, this > dispute procedure has an informal dialogue phase followed by a > formal > arbitration phase if the matter remains unresolved. > > If the IRSG or the RFC Editor has concerns with the content of a > particular IESG note, then they should contact the IESG with a clear > and concise description of the concern. Alternate content may be > suggested. Informal dialogue is desired. At the end of the > dialogue, the IESG can reaffirm the original IESG note, provide an > alternate IESG note, or withdraw the note altogether. > > The dialogue should not take more than six weeks. This period of > time allows the IESG to conduct an IETF Last Call to determine > community consensus if desired. > > If dialogue fails to resolve IRSG or RFC Editor concerns with the > content of a particular IESG note, then they can take the matter to > the IAB for a final ruling. The IAB review will occur according to > procedures of the IAB's own choosing. The IAB can direct the > inclusion of the IESG note or withdraw the note altogether. Unlike > the IAB reviews specified in RFC 4846 [I3], in this situation, the > IAB decision is binding, not advisory. > > The rationale for choosing this model is first of all the fact that > normal discussion should be given an opportunity, and only if that > fails > should the dispute resolution be invoked. We have chosen a model where > a > third party, the IAB, helps resolve the conflict. We believe the use of > a third party is a necessary part of the compromise. We also believe > that this model allows the independence of the RFC Editor to be > retained. > > An alternative that we considered during discussion was a two-party > model where the RFC Editor still made the final determination about the > requested note, but was required to ask for an IAB opinion before > ignoring the request. We are not sure if this model would work as a > compromise, because the two party model may not satisfy those who felt > that the RFC Editor should not be able to decide on this on its own. > However, the alternative does raise the bar for ignoring a request for > an IESG note. An advantage of the alternative model is that it can be > described purely as an application of the rules in RFC 4846. If we were > to choose this model, the last paragraph would read as follows: > > If dialogue fails to resolve IRSG or RFC Editor concerns with the > content of a particular IESG note, then they are required to acquire > an opinion from the IAB. The IAB can direct the inclusion of the > IESG note or withdraw the note altogether. As specified in RFC 4846, > IAB's opinion will be advisory. > > In any case, the decision on what to do rests again with the community. > We are asking the IETF community, the RFC Interest list, and the IAB to > think about our proposal and provide feedback and/or alternative > suggestions. I will wait for this feedback from the IETF until October > 1st. Given that this matter concerns the boundary between the IETF and > RFC Editor operation, I will also ask the IAB to make a decision on > whether they are comfortable with the model going forward. > > Jari Arkko > > _______________________________________________ > rfc-interest mailing list > rfc-interest@xxxxxxxxxxxxxx > http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf