Subject: path forward with RFC 3932bis

From: Jari Arkko <[email-masked]>
Date: Sun, 13 Sep 2009 22:45:11 +0300

I'd like to draw some conclusions about the discussion that we had on 
this topic. I also believe we have a way forward.

My read of discussion is that the community is split on the mandatory 
vs. optional IESG note question. There was a good number of people on 
both sides. Both sides had rational arguments, and it seemed hard to 
dismiss either point of view.

However, a compromise position emerged during the discussion. The 
general idea is that an appeal-style safety mechanism allows a conflict 
-- if one ever appears -- to be resolved in a reasonable manner. I 
talked to the IESG about this, and we would like to propose something 
along the lines that a number of people brought up in the discussion: if 
the RFC Editor believes that an IESG note is inappropriate, they can 
indicate so, and the IESG in turn can determine whether it wants to 
appeal the editor's decision.

I believe this is a reasonable approach, it retains the independence of 
the editor, it does not create any new processes that have to be 
executed for every document, and should an inappropriate 
note/inappropriate deletion of a note ever occur, it allows the 
situation to be fixed.

However, there's obviously many details missing. I will work with Olaf 
and Russ to come up with a more specific proposal*. Once we have that 
there will be an opportunity to comment. We will also work with the IAB 
to make sure the outcome is appropriate from their perspective. Stay tuned.

Jari

*) Of course, the proposal may use already existing processes, but I 
would like to be very explicit in 3932bis about pointing to those 
processes, to leave no room for unclarity.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 19 Sep 2009 14:24:25 +1200

Hi Jari,

Here's the problem I see with draft-housley-iesg-rfc3932bis-09.
Suggesting a dialogue when there is disagreement is fine.
Allowing the IESG to consult the IETF as a whole is fine. But
then the final part of the dispute resolution procedure attempts
to undercut the editorial independence of the IRSG or of
the Independent Series Editor (which really should replace the
"RFC Editor" throughout the draft):

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

No. The IRSG or the ISE have editorial control. If they inform the
IESG that they will not include the IESG note, then it must be for
the IESG to appeal to the IAB. It's the IESG which is disagreeing with
the editorial decision.

Also, why is the appeal path to the ISOC Board, within the narrow
terms of RFC2026 section 6.5.3 "Questions of Applicable Procedure"
not mentioned? That path should always be open, I think.

That said, thanks for trying to resolve this conundrum.

   Brian

---

From: Jari Arkko <[email-masked]>
Date: Sat, 19 Sep 2009 11:34:42 +0300

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

---

From: Jari Arkko <[email-masked]>
Date: Sat, 19 Sep 2009 11:34:53 +0300

> Here's the problem I see with draft-housley-iesg-rfc3932bis-09.

You responded before I had a chance to explain what the rationale and 
options are. Sorry, but I was asleep at the time the draft came out :-) 
Please see my other mail.

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 20 Sep 2009 17:06:52 +1200

Hi Jari,
> options are. Sorry, but I was asleep at the time the draft came out :-)

I knew that this timezone must have an advantage once in a while ;-)

> Please see my other mail.

I think my comment still applies - it should be the IESG that appeals
against the Editor's final decision, not the other way round.

    Brian

---

From: Jari Arkko <[email-masked]>
Date: Mon, 21 Sep 2009 11:56:26 +0300

Brian,

> against the Editor's final decision, not the other way round.

Ok. I have no problem placing the burden on initiating the formal 
dispute resolution from the IESG side instead. For instance, if the 
current text says

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

to

"If dialogue fails to resolve IRSG or RFC Editor concerns with the 
content of a particular IESG note, the IESG can take the matter to the 
IAB for a final ruling."

Would this help resolve your concerns?

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 21 Sep 2009 12:05:58 +0300

Jim,

> 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.
>   
I think we have taken it into account, or can you describe more exactly 
what issue you are thinking of?

In my e-mail, I explained that our proposed resolution can be thought of 
as an additional process rule on top of 5620 and other relevant RFCs. 
There are alternative resolutions that can be expressed purely as 
applications of 5620, but they may have other downsides.

But the bottom line is that I think we should avoid focusing too much on 
what can be done. If the community (IETF, IAB, outside) wants a 
particular model, we should pick that and get it over with. With this in 
mind, what would you Jim like to see as the end result?

Jari

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 21 Sep 2009 17:35:56 +0100

Jari,

Aaron asked me to forward a comment I made on the IRSG list:

The text below seems to almost encourage the IESG to do an IETF last
call in the event of a dispute with the IRSG as to the content of an
IESG note. That LC should be limited to the content of the IESG note
I guess, and not to determine if the IETF have consensus on the
document as a whole.

If that's a reasonable interpretation I'd suggest changing as follows:

OLD:
   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.
NEW:
   The dialogue should not take more than six weeks.  This period of
   time allows the IESG to conduct an IETF Last Call on the content
   of the proposed IESG note (and not on the document as a whole)
   to determine community consensus if desired.

Regards,
Stephen.

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 19 Sep 2009 10:29:07 -0700

Jim

> -----Original Message-----
> From: [email-masked] [mailto:rfc-interest-
> [email-masked]] 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
> 
> _______________________________________________
> rfc-interest mailing list
> [email-masked]
> http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: John C Klensin <[email-masked]>
Date: Mon, 21 Sep 2009 11:50:07 -0400

--On Monday, September 21, 2009 11:56 +0300 Jari Arkko
<[email-masked]> wrote:

> Brian,
> 
>> I think my comment still applies - it should be the IESG that
>> appeals against the Editor's final decision, not the other
>> way round.
>>   
> 
> Ok. I have no problem placing the burden on initiating the
> formal dispute resolution from the IESG side instead. For
> instance, if the current text says
> 
> "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."
> 
> to
> 
> "If dialogue fails to resolve IRSG or RFC Editor concerns with
> the content of a particular IESG note, the IESG can take the
> matter to the IAB for a final ruling."
> 

It would certainly help resolve some of mine.

    john

---

From: Russ Housley <[email-masked]>
Date: Mon, 21 Sep 2009 13:07:45 -0400

You have captured the intent.  I'm pleased to make that change if the 
community aggress with the approach that is specified.

Russ

At 12:35 PM 9/21/2009, Stephen Farrell wrote:

>Ietf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ietf

---

From: Olaf Kolkman <[email-masked]>
Date: Mon, 21 Sep 2009 19:49:26 +0200

On Sep 21, 2009, at 7:29 PM, Jim Schaad wrote:

> Ok - the problem I have, and the reason that I asked, is that it is  
> not
> clear to me that the Independent Series Editor (ISE) is part of the  
> RFC
> Editor any more than the ISRG is going to be.  Thus it is the ISE  
> not the
> RFC Editor that will be asking for the IESG to review documents in the
> future.  The first level of negotiations would be between the ISE  
> and the
> ISEG, the second level would add the RSE and the final level would  
> be the
> IAB.

RFC Editor includes the ISE (the model defined the ISE as one of the  
components of the RFC Editor)

RFC5620:
   "Note that RFC 4844 uses the term "RFC Editor function" or "RFC
    Editor" as the collective set of responsibilities for which this  
memo
    provides a model for internal organization.  This memo introduces  
the
    term "RFC Series Editor" or "Series Editor" for one of the
    organizational components."

>
> This change from the RFC Editor processing independent submissions  
> to an ISE
> doing the same thing - with an additional layer of possible internal  
> review
> from the RSE - is not reflected in the document.

Correct. Personally I don't think that is a big issue. If the RFC  
series allowed footnotes I would add a footnote about how it would  
work out with the ISE and RSE in version 1 of the RFC Editor model ....

--Olaf

________________________________________________________

Olaf M. Kolkman                        NLnet Labs
                                        Science Park 140,
http://www.nlnetlabs.nl/               1098 XG Amsterdam

---

From: Aaron Falk <[email-masked]>
Date: Mon, 21 Sep 2009 14:22:07 -0400

Jari-

The draft says:

   The RFC Editor reviews Independent Submission Stream submissions for
   suitability for publication as RFCs.  As described in RFC 4846 [I3],
   the RFC Editor asks the IESG to review the documents for conflicts
   with the IETF standards process or work done in the IETF community.

   Similarly, documents intended for publication as part of the IRTF
   Stream are sent to the IESG for review for conflicts with the IETF
   standards process or work done in the IETF community [I2].

I'm concerned about the phrase "or work done in the IETF community." 
Unbound it can cover much, much more than IETF standards work.  In fact,
one could make the case that it covers the IRTF (since much IRTF work is
done in the standards community.  I don't believe IESG review should
cover conflicts in the IRTF (or IAB or IETF Trust or ISOC or with other
Independent Submissions authors...)  The IESG's authority in this
paragraphs derives from RFC2026 which is pretty clear:

   To ensure that the non-standards track Experimental and Informational
   designations are not misused to circumvent the Internet Standards
   Process, the IESG and the RFC Editor have agreed that the RFC Editor
   will refer to the IESG any document submitted for Experimental or
   Informational publication which, in the opinion of the RFC Editor,
   may be related to work being done, or expected to be done, within the
   IETF community.

I'd like to see the phrase in question removed or perhaps clarified (say
to include planned standards work or some such).

--aaron

-- 
Aaron Falk
Chair
Internet Research Task Force
http://www.irtf.org

---

From: SM <[email-masked]>
Date: Mon, 21 Sep 2009 15:16:19 -0700

Hi Jari,
>compromise. A week ago I promised that we would come up with a specific

[snip]

>that this model allows the independence of the RFC Editor to be retained.

I assume that you would like this model to fit within the RFC Editor 
Model.  I don't expect any serious problem as to whether RFC Editor 
should be read as RSE or ISE.  Section 5 of RFC 4846 discusses about 
the formal IESG review:

   "The RFC Editor or the author may request that the IAB review the
    IESG's request to delay or not publish the document and request that
    the IAB provide an additional opinion.  Such a request will be made
    public via the RFC Editor Web site.  As with the IESG review itself,
    the IAB's opinion, if any, will be advisory.  And, as with author
    requests for an IAB technical review (see Section 4.5), the IAB is
    not obligated to perform this type of review and may decline the
    request."

The above emphasizes that the IESG review and the IAB's opinion is 
advisory.  Your text recommends making a IAB review which is binding.

>compromise, because the two party model may not satisfy those who felt

If I understood the last discussion about this draft, the compromise 
was to provide the IESG enough time to ask for an opinion/review from 
the IAB.  And now the IESG is asking for more than that.

>to choose this model, the last paragraph would read as follows:

Section 4 of the draft favors informal dialogue.  That's good.  If 
don't want the RFC Editor to be able to decide on its own, you are 
turning the role into one of copy editing.  The Independent Series 
Editor (ISE) is an individual with "good standing in the technical 
community, in and beyond the IETF".  I'm not saying that the IETF or 
the IESG should not question the decisions of the ISE.  If the 
opinion of the IESG and the IAB does not weigh as much in the ISE's 
decision, it is unlikely that the ISE has a good standing in the IETF 
community.

For what it is worth, RFC 4722 was obsoleted by RFC 5022.  The IESG 
requested the RFC Editor to publish a new RFC because of the missing IESG Note.

Regards,
-sm

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Sep 2009 16:29:43 +1200

> Would this help resolve your concerns?

Yes, thanks. It may seem like a tiny point, but I think it's an issue
of principle.

     Brian

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 22 Sep 2009 18:37:08 +0200

> to include planned standards work or some such).
That phrase was also present in RFC 3932, and, as you note, in RFC 2026.
I'm concerned that in our eagerness to make the perfect document, we 
might be making too many changes, especially at what's hopefully a late 
stage in the process of getting that revised.

If I remember rightly (but vaguely) from the writing of 3932, the phrase 
was kept that way because we didn't want to be unable to speak about a 
document just because the WG wasn't chartered yet, or the work was 
processed through independent submissions to the IESG, or any of the 
other multitude of ways work gets done in the IETF without invoking 
excessive procedural overhead.

That said, the IESG notes in 3932 were tailored for conflict with WGs 
specifically - it was also the desire of the IESG-at-the-time that the 
note to the RFC Editor needed to *identify* the work it conflicted with, 
not just a vague "there's work in this area".

                        Harald

                         Harald

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 21 Sep 2009 10:29:20 -0700

Ok - the problem I have, and the reason that I asked, is that it is not
clear to me that the Independent Series Editor (ISE) is part of the RFC
Editor any more than the ISRG is going to be.  Thus it is the ISE not the
RFC Editor that will be asking for the IESG to review documents in the
future.  The first level of negotiations would be between the ISE and the
ISEG, the second level would add the RSE and the final level would be the
IAB.

This change from the RFC Editor processing independent submissions to an ISE
doing the same thing - with an additional layer of possible internal review
from the RSE - is not reflected in the document.

Jim

> From: Jari Arkko [mailto:[email-masked]]
> Sent: Monday, September 21, 2009 2:06 AM
> To: Jim Schaad
> Cc: 'IETF Discussion'; 'RFC Interest'; 'IAB'; 'Olaf M. Kolkman';
> 'Harald Tveit Alvestrand'; 'Russ Housley'

---

From: John C Klensin <[email-masked]>
Date: Tue, 22 Sep 2009 13:25:23 -0400

--On Tuesday, September 22, 2009 18:37 +0200 Harald Alvestrand
<[email-masked]> wrote:

>...
>> I'd like to see the phrase in question removed or perhaps
>> clarified (say to include planned standards work or some
>> such).
> I'm concerned that in our eagerness to make the perfect
> document, we might be making too many changes, especially at
> what's hopefully a late stage in the process of getting that
> revised.

Yes.  But, as Aaron points out, the phrase as written is wrong.
And bringing these wrong phrases forward then gets us into
arguments about precedent, i.e., "that must be exactly what was
intended because it has occurred in multiple documents over a
long time".   IMO, that means it is time to fix it.

> If I remember rightly (but vaguely) from the writing of 3932,
> the phrase was kept that way because we didn't want to be
> unable to speak about a document just because the WG wasn't
> chartered yet, or the work was processed through independent
> submissions to the IESG, or any of the other multitude of ways
> work gets done in the IETF without invoking excessive
> procedural overhead.

Quite reasonable.  But one could say "or work under development
in the IETF" or equivalent without invoking the
ever-controversial "IETF community".

> That said, the IESG notes in 3932 were tailored for conflict
> with WGs specifically - it was also the desire of the
> IESG-at-the-time that the note to the RFC Editor needed to
> *identify* the work it conflicted with, not just a vague
> "there's work in this area".

And the latter has gotten somewhat lost along the line, along
with the concept that those statements were general guidance
about what was intended, not literal text to be invoked as
incantations.

   john

---

From: Jari Arkko <[email-masked]>
Date: Wed, 23 Sep 2009 08:02:45 +0300

Aaron,

This morning I reviewed the IETF web pages, the Tao, the IRTF web pages, 
and Wikipedia entries on these two organizations. The way this material 
portrays the IETF and the IRTF, I'm having little trouble seeing a 
problem with the phrase "... with the IETF standards process or work 
done in the IETF community". I do agree with you that it should not 
cover IRTF work. In particular, the IESG should not check for conflict 
with a research group when doing an 3932bis check for a document. It is, 
however, a feature that we cover more IETF work than just the pure 
standards work.

> done in the standards community.

Now I do not follow you. My perception is not that the IRTF work is done 
in the standards community. Unless, of course, you simply refer to the 
collection of IETF and IRTF meeting participants as the "IETF 
community". Or if you think of the many people who do both 
standardization and research work. In my opinion, the IRTF and IETF are 
still distinct entities, despite mixed participation. I think the 
definition of the IETF and the IRTF is quite clear.

> I don't believe IESG review should
> Independent Submissions authors...)

I agree, but I do not believe the words in the document imply this.

I came up with some ways of changing the text, e.g., just saying "work 
done in the IETF" and dropping the word "community". However, is not 
clear to me that any other words couldn't be misunderstood in the 
similar manner. In addition, if we dropped the word community, would 
this mean that a BOF that is about to be chartered as an official 
working group would not count as an IETF activity yet?

Jari

---

From: John C Klensin <[email-masked]>
Date: Wed, 23 Sep 2009 08:05:12 -0400

--On Wednesday, September 23, 2009 08:02 +0300 Jari Arkko
<[email-masked]> wrote:

>...
> I came up with some ways of changing the text, e.g., just
> saying "work done in the IETF" and dropping the word
> "community". However, is not clear to me that any other words
> couldn't be misunderstood in the similar manner. In addition,
> if we dropped the word community, would this mean that a BOF
> that is about to be chartered as an official working group
> would not count as an IETF activity yet?

For better or worse, a group that is putting together a BOF
under current rules -- applications, posting of draft agendas
and sometimes even charters, etc.-- represents considerable work
"done in the IETF.  One that is about to be chartered is even
further along.   The problem area, wrt either the IRTF or
Independent Submissions, is when someone has sort of started
thinking that it might be a good idea for the IETF to do some
work in the area... someday.   That isn't "work in the IETF"
because no real work has been done and the text doesn't say
"speculation about possible work in the IETF".

Expanding to "the IETF community" might bring in the
speculations, organizations that use IETF documents but are not
the IETF itself, etc.

There is obviously still a gray area there, but I'm inclined to
trust the IESG's discretion -- and the problem resolution
procedure-- rather than trying to nail down every boundary case.

   john