Re: path forward with RFC 3932bis

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]