Subject: Re: I-D ACTION:draft-housley-iesg-rfc3932bis-10.txt

From: Dave CROCKER <[email-masked]>
Date: Wed, 18 Nov 2009 06:09:41 +0900

(This note seems to offer a useful point of departure, in this thread, so I 
thought I'd resurrect it, for replying.  /d)

Jari Arkko wrote:
> Dave,
> 
>> The first assumption is that there is a real problem to solve here.
> 
> I think there is a real problem, and that is the need to modernize the 
> headers and boilerplates so that they are more reasonable for each 
> stream. This includes things like getting rid of derogatory IESG notes, 
> which none of us likes.

I, too, think that there is a very useful bit of modification to the RFC title 
page that would resolve concerns about reader confusion.  The current draft for 
headers and boilerplates defines a Source header, to indicate which stream the 
document came out of.

    <http://tools.ietf.org/html/draft-iab-streams-headers-boilerplates-08>

>    <document source>  This describes the area where the work originates.
>       Historically, all RFCs were labeled Network Working Group.
>       "Network Working Group" refers to the original version of today's
>       IETF when people from the original set of ARPANET sites and
>       whomever else was interested -- the meetings were open -- got
>       together to discuss, design and document proposed protocols
>       [RFC0003].  Here, we obsolete the term "Network Working Group" in
>       order to indicate the originating stream.

It currently requires that the reader already know what the possible choice are. 
  Since most readers won't know, it's not clear to me how much utility this will 
have.

So instead of a field that simply lists only the actual source, I suggest a 
header that defines its full context, by listing all choices and bracketing the 
one that applies.

Hence:

      Source:   [[ IETF  ]]  IRTF  IAB  Independent

versus, for example:

      Source:   IETF  IRTF  IAB  [[ Independent ]]

If a reader misses the meaning of this header, why would anyone think that they 
will better understand any other text that is inserted?

> Of course, headers and boilerplates changes need to be accompanied by 
> the corresponding change in 3932. THAT is the reason for the 3932bis 
> draft.

Giving the IAB authority to override the RFC Editor's decision is more than 
clarity of labeling.

  The trouble is, of course the final 3932bis needs to take the
> opinions of the community into account (and be acceptable to the 

Excellent idea.  To justify making a change in the independence of the RFC 
Editor, where is the IETF consensus?  Absent that community consensus, of 
course, the status quo is maintained.

Hmmm.  Here's an uncomfortable legal question for us to consider:

      Why is IETF consensus sufficient?

      Since the RFC Editor has always been independent of the IETF, per se, what 
gives the IETF the authority to declare changes to the RFC Editor's operation?

> approving bodies). This is why we have discussed all the changes. I do 
> not see a lot of other options than the compromise position if 
> completing 3932bis and the rest of the system of changes is the goal.

In a private exchange that Russ was conducting over the last few weeks, I 
suggested a mediation model, with the IAB reviewing the RFC Editor's decision, 
but only authorized to make a recommendation, rather than mandating the change. 
  He reported that others he was talking with insisted on the current 
"arbitration" model that mandates change.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Tue, 17 Nov 2009 16:47:44 -0500

--On Wednesday, November 18, 2009 06:09 +0900 Dave CROCKER
<[email-masked]> wrote:

>...
>> approving bodies). This is why we have discussed all the
>> changes. I do  not see a lot of other options than the
>> compromise position if  completing 3932bis and the rest of
>> the system of changes is the goal.
> 
> In a private exchange that Russ was conducting over the last
> few weeks, I suggested a mediation model, with the IAB
> reviewing the RFC Editor's decision, but only authorized to
> make a recommendation, rather than mandating the change.   He
> reported that others he was talking with insisted on the
> current "arbitration" model that mandates change.

Dave,

While I agree with you in principle, I suggest that the current
text is reasonable, if only because the IAB always has the right
to say to the RFC Editor (either ISE or RSE) "do what we tell
you or you will be fired".   I would expect the IAB to exercise
that particular authority only after everything else has failed
and it is clear to almost everyone that things are out of
control, but that is not a question for 3932bis.    As the text
now reads, the IAB can be asked to conduct a review, but can
decline to do so (consistent with RFC 4846 and nothing new).
And, if the IAB conducts such a review, it can instruct the RFC
Editor has to how to proceed, but can also decide to not do that
and simply provide advice (the latter is, again, consistent with
4846).

I wish that that IESG (or some few of its members; I don't know)
were not insisting on even that much, but there seem to be
nothing that can be done about it without the loss of much more
time (remember that Independent Submission publications have
been blocked for many months by the side-effects of this
situation). But, in its present form, it seems relatively
harmless in practice and it would be good to get on with this
and unlock the Independent Stream publications.

Just my opinion, of course.

    john

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 17 Nov 2009 17:15:13 -0500

Dear colleagues,

On Tue, Nov 17, 2009 at 04:47:44PM -0500, John C Klensin wrote:

> situation).

All of the to-ing and fro-ing about this document has finally made me
sit up and read it.  I have the impression from the archives that at
least some people are concerned about the dispute resolution
mechanism; there seems to be a suggestion about that it impinges on
the traditional freedoms of the RFC Editor.

I haven't made up my mind about that, but I am curious why the section
is being included anyway.  The first two sentences of Section 4 all
but say that this is a problem that has never happened.  The only
motivation the document supplies is that there could be a dispute, and
that it'd be nice to have a way of solving the dispute if it were
needed.  There's no mechanism at all in RFC 3932, as I read it.

My experience of this sort of formalism leads me to believe that, when
there is no formal mechanism, everyone is forced to act in good faith
to hammer out a compromise; whereas once there's a well-established
set of rules in place to handle disagreements, there's very little
incentive to avoid cranking up that machinery for even very small
disputes.  (Social pressure doesn't work, because the retort is always
that this is what the mechanism is for.)

So I'd find it really useful to know what problem this dispute
resolution mechanism is actually supposed to solve.  I also wonder
whether those in favour of the mechanism have worked through the
potential workload that would result from high-frequency application
of this mechanism, and whether IESG or IAB (or both) members have the
time to invest in such an eventuality.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Nov 2009 12:54:35 +1300

On 2009-11-18 11:15, Andrew Sullivan wrote:

> resolution mechanism is actually supposed to solve.

Since we're (presumably) trying to write rules that will
work when common sense has failed, it seems prudent to have
a clear path for disputes of an unknown nature.

   Brian

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 18 Nov 2009 09:28:11 -0500

> a clear path for disputes of an unknown nature.

I get the sentiment, and I think it comes from a noble impulse, but I
think it's a temptation that should be avoided.

If we get to the point where the IESG, the RFC Editor, and the IAB
can't among them work out a sensible compromise (because common sense
has failed), then we have much bigger problems than getting things
published on the Independent Submissions track.

Maybe I watched too much _Brazil_ on the weekend, but this all seems
to me to be the sort of arrangement that can only lead to harm.  Given
the number of iterations the draft has been through, and the volume of
mail it has attracted, I expect the current form is likely as close to
good as it will get (since we still have a fail safe: the IAB can put
a pox on all the houses).  But I don't believe solving a problem we
don't actually have is a good idea.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: John Levine <[email-masked]>
Date: 18 Nov 2009 15:53:39 -0000

>published on the Independent Submissions track.

+1

We're software and network guys (and gals, of course) which means that
we delight in identifying and dealing with edge cases to try and cover
every possibility.  In human affairs, though, no matter how many cases
you try to anticipate, down at the bottom of the list of alternatives
you always end with

    else die();

If we get anywhere near that point, I see little reason to think that
the parties involved, who would by then have been arguing for months
if not years, would be inclined to follow any procedure at all.  For
better or worse, the IETF only works because the people involved are
more or less reasonable, and nothing we could write down would change
that.

R's,
John

PS: Note that this principle applies to any process we might design,
not just this one.

---

From: [email-masked]
Date: Wed, 18 Nov 2009 07:17:22 -0800 (PST)

> think it's a temptation that should be avoided.

Agreed.

> don't actually have is a good idea.

Exactly my thinking on the matter.

				Ned