Subject: Re: [INDEP] Issues in draft-klensin-rfc-independent-02.txt

From: Bob Braden <[email-masked]>
Date: Mon, 12 Jun 2006 10:04:29 -0700 (PDT)

John,

You wrote:

  *> 
  *> I am glad you chose the term "construct an example", because
  *> this sort of case, in reality, never happens.  The RFC Editor
  *> and the Editorial Board, at least the current group of people,
  *> have been exceptionally sensitive to this sort of issue.  The
  *> general practice has been that, if even a hint of such a
  *> situation occurs, the relevant AD is asked, informally, for an
  *> opinion even before other issues are addressed that would lead
  *> to a formal request for IESG review.  If the answer comes back
  *> "of course this is an end run" or "yes, that would conflict with
  *> an option that already exists", the author is told that either a
  *> clearly non-conflicting draft is needed or the document must be
  *> processed via the IESG, but the conflicting draft is dead as far
  *> as the independent submission process is concerned.

Unfortunately, this procedure does not work very well in practice.  ADs
are overworked with inband demands, so they often do not get around to
responding to such OOB queries.

  *> 
  *> I also note that there has historically been some coordination
  *> between the RFC Editor with regard to any use of a potentially
  *> allocated option and the IANA and IANA databases.

Huh? The RFC Editor and the IANA necessarily coordinate very closely as
all times, so such a conflict would certainly be caught before publication.
However, the earlier the better, presumably.

Bob Braden

  *> identification of such a conflict would rapidly send the author
  *> back to the drawing board.
  *> 
  *> So, at least in my experience, while the formal IESG review is a
  *> useful additional safeguard, the odds of the IESG saying "DNP"
  *> with that sort of explanation and the RFC Editor deciding to
  *> publish with a disclaimer are close enough to zero to be
  *> irrelevant.   
  *> 

_______________________________________________
INDEPENDENT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/independent

---

From: John C Klensin <[email-masked]>
Date: Mon, 12 Jun 2006 14:32:33 -0400

--On Monday, 12 June, 2006 10:04 -0700 Bob Braden
<[email-masked]> wrote:

> John,
> 
> You wrote:
> 
>   *> 
>   *> I am glad you chose the term "construct an example",
> because   *> this sort of case, in reality, never happens.
> The RFC Editor   *> and the Editorial Board, at least the
> current group of people,   *> have been exceptionally
> sensitive to this sort of issue.  The   *> general practice
> has been that, if even a hint of such a   *> situation occurs,
> the relevant AD is asked, informally, for an   *> opinion even
> before other issues are addressed that would lead   *> to a
> formal request for IESG review.  If the answer comes back   *>
> "of course this is an end run" or "yes, that would conflict
> with   *> an option that already exists", the author is told
> that either a   *> clearly non-conflicting draft is needed or
> the document must be   *> processed via the IESG, but the
> conflicting draft is dead as far   *> as the independent
> submission process is concerned.
 
> Unfortunately, this procedure does not work very well in
> practice.  ADs are overworked with inband demands, so they
> often do not get around to responding to such OOB queries.

That, it seems to me, is an IESG problem, not an RFC Editor
problem.  If ADs are failing to respond to such queries in ways
that cause more work for the RFC Editor, and then causes work
for the IESG (all ADs together), that is, IMO, a poor set of
decisions about priorities.  But it is not a problem in the
independent review model in any event.

>   *> I also note that there has historically been some
> coordination   *> between the RFC Editor with regard to any
> use of a potentially   *> allocated option and the IANA and
> IANA databases.
> 
> Huh? The RFC Editor and the IANA necessarily coordinate very
> closely as all times, so such a conflict would certainly be
> caught before publication. However, the earlier the better,
> presumably.

Certainly the earlier the better.  And I, and presumably at
least some of the other members of the community, didn't know
exactly what the current state of coordination is, so I wrote me
note conservatively and didn't include a coordination step in
the I-D.  If one should be added to the latter, please tell us
where.

     john

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Jun 2006 11:05:18 +0200

Just to be clear: I am deeply convinced that the RFC Editor
team, and the reviewers, really do strive to avoid such
cases reaching the stage of RFC 3932 review; it's clear
that it's intended as a backstop. And certainly I could have
constructed a better example.

I think the issue that I raised relative to John's draft
was that today the IESG acts as that backstop, and John
seems to be asking for formal IETF Consensus instead,
which is a change I find unnecessary.

     Brian

---

From: John C Klensin <[email-masked]>
Date: Wed, 14 Jun 2006 05:22:25 -0400

> which is a change I find unnecessary.

Not my intention.  I think formal IETF Consensus should be
necessary in two, and only two, cases:

(1) The IESG issues a "do not publish, ever" request, which
Harald believes 3932 makes impossible.

(2) The IESG decides to attach (or request that the RFC Editor
attach) a note to a document that (a) is in the name of the IETF
and (b) implies that the document or the proposals it makes, are
incompetent.  Note that this case does not apply if the only
disclaimer note that is attached says "not an IETF document" or
"not the result of IETF processing".  

The difference from 3932 in the latter case isn't the decision
process or process-flow results, it is in the text of the
attached note.   I believe that such notes should be factual and
that the IESG almost never (this case included) gets to speak
for the IETF without asking the IETF.  So...

	* Inserting a note that says "not the result of IETF
	processing", or "not produced by the IETF", or anything
	equivalent, requires only an IESG decision.  Indeed, the
	RFC Editor might start inserting that note
	spontaneously, which would save the IESG some seconds.
	
	* Inserting a note that says "the IETF thinks this is
	bad" or "the IETF doesn't like this" or "the user should
	exert extraordinary caution because who know what nut
	made this up without any review at all" --or anything
	similar-- should require IETF consensus that those
	statements are true, or at least reflect an educated and
	thoughtful community position.

Again, if the document isn't clear enough about that
distinction, I would welcome suggested text.

     john

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Jun 2006 14:41:00 +0200

OK, John, then I did misread your intent. Thanks for the clarification.

I think perhaps there needs to be clear distinction in your text
between the standard response defined by RFC 3932 and any additional
responses such as you fear. I'm not sure I can suggest words
but that is where my confusion lay.

(That is a separate issue from objections to the RFC 3932 standard
response - obviously it would be valid for someone to propose
an amendment to that for community review.)

    Brian

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 14 Jun 2006 09:41:21 -0700

>Harald believes 3932 makes impossible.

If you think that RFC 3932 makes a "do not publish, ever" request 
possible, the RFC needs to be revised. The following, from "3. 
Detailed Description of IESG Review", seems completely clear:

    The IESG may return five different responses, any of which may be
    accompanied by an IESG note to be put on the document if the RFC
    Editor wishes to publish.

    1. The IESG has not found any conflict between this document and IETF
       work.

    2. The IESG thinks that this work is related to IETF work done in WG
       <X>, but this does not prevent publishing.

    3. The IESG thinks that publication is harmful to the IETF work done
       in WG <X> and recommends not publishing the document at this time.

    4. The IESG thinks that this document violates IETF procedures for
       <X> and should therefore not be published without IETF review and
       IESG approval.

    5. The IESG thinks that this document extends an IETF protocol in a
       way that requires IETF review and should therefore not be
       published without IETF review and IESG approval.

--Paul Hoffman, Director
--VPN Consortium

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Jun 2006 13:36:49 +0200

I will point out that "DNP, ever" might well be what the IESG *wishes*
to say even in the case of response #1. What happens in practice in
such a case is that the IESG gives response #1, but people will send along
their negative reviews as FYI. It's then in the hands of the RFC Editor
what happens next, which I think is as it should be.

    Brian

Paul Hoffman wrote:
> possible, the RFC needs to be revised. The following, from "3. Detailed 
> Description of IESG Review", seems completely clear:
>

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 23 Jun 2006 17:18:19 +0200

> but that is where my confusion lay.

For me the first paragraph of the appendix, after being tainted by  
this discussion,  makes this point. For somebody who reads this  
without having gone through this list some more concrete text may be  
needed. Would substituting the last sentence
"The author of this document believes that the principle should be:"  
by "The guiding principles for determining and indicating the status  
of an independent submission with respect to IETF work should be"

(This word-crafting is not my speciality :-()

> an amendment to that for community review.)

I'd say that the actual modification of standard responses from 3932  
should not be part of this discussion. This document currently only  
describes the guiding principles for that future work.

I am still trying to get my finger behind what the remaining open  
issues are w.r.t.  draft-klensin-rfc-independent-02.txt. I think that  
most of the issues that were raised were questions for clarifications  
of 3932 that IMHO were clarified by participants. In other words  
there was very little that leads to actual text changes.

I hope that I am not blatantly disregarding issues in my reread of  
the archive.

With the final cut-off being the 26th we do not have a lot of time to  
converge to a new version of the draft before the IETF :-(.

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: John C Klensin <[email-masked]>
Date: Fri, 23 Jun 2006 12:23:07 -0400

--On Friday, 23 June, 2006 17:18 +0200 "Olaf M. Kolkman"
<[email-masked]> wrote:

>> I think perhaps there needs to be clear distinction in your
>> text between the standard response defined by RFC 3932 and
>> any additional responses such as you fear. I'm not sure I can
>> suggest words but that is where my confusion lay.
>... 
> With the final cut-off being the 26th we do not have a lot of
> time to  converge to a new version of the draft before the
> IETF :-(.

Unfortunately, I'm spending most of the next 36 hours en route
to a meeting.  Even if agreement as to what should be done were
reached within the next hour (and I agree with you that I've
seen very little that requires textual changes), the odds that I
could get a revision completed and submitted before the Monday
deadline are just about zero.   If someone else would like to
take on that revision job while preserving the general spirit of
the existing document, I'd be happy to supply source... but,
unless the request arrives before I head for the airport, the
earliest likely time for a response will be late Saturday
afternoon or evening.

     john