Subject: Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC

From: John C Klensin <[email-masked]>
Date: Wed, 07 Feb 2007 18:02:12 -0500

Hi.

I will get to substance in a separate note, and hope others will
also.  In the interim, two procedural remarks...

(1) This document and draft-klensin-rfc-independent-05.txt
describe two pieces of the "how a document that does not
originate in a WG may be reviewed and published" space.  Each
contains some text that suggests that some documents are better
handled via the other path. The IAB has made a request for input
on the "independent" document and now we have a Last Call on
this one.  

As editor of the "rfc-independent" document, I am awaiting
instructions from the IAB as to what, if anything, to do next,
but suspect that the recommendation below would be better
applied to -06 rather than -05 of that document.

I strongly encourage members of the community to review the two
documents side by side to ensure that everyone is satisfied that
they are consistent and that any questions about the overall
non-WG submission space is adequately covered by one or the
other of them.

I also ask, and hope others will join me in asking, that the
IESG and IAB take explicit responsibility for coordinating and
ensuring consistency between these two documents (and, if
necessary, with draft-iab-rfc-editor).  If they are not
consistent enough that actions based on them are predictable, I
fear we can look forward to some difficulties.  It might even be
useful for the two groups to coordinate titles sufficiently that
someone looking for information will easily understand that the
two describe somewhat parallel paths and ways in which those
paths may or may not be alternatives to each other.

(2) This document is not the product of a working group or of
extended open discussion in the community.  Version -00 was
posted around the time of the San Diego meeting and received
very little public discussion.  The current version was posted
at the beginning of this month; there has been little discussion
of it either (at least on public lists -- as the
Acknowledgements suggest, I've had some input into it via
private discussions).  The document does not even indicate a
mailing list on which it can be discussed.  One presumes that
comments could have been sent to the IESG by those who happened
to read the I-Ds, but that is a one-way communications path.  

If the IESG intends this document to merely represent the
particular procedures they intend to follow within the range of
alternatives over which they believe they have discretion, then
it should probably be published as an ION, not an Informational
RFC.  If they intend it to be definitive information for the
community, especially information that they expect to reference
as to why something is or is not possible or whether procedures
are being followed, a two-week Last Call is, IMO, inappropriate
and inconsistent with the spirit of the provisions in RFC 2026.

    john

--On Wednesday, 07 February, 2007 10:20 -0500 The IESG
<[email-masked]> wrote:

> The IESG has received a request from the Internet Engineering
> Steering  Group (iesg) to consider the following document:
> 
> - 'Guidance on Area Director Sponsoring of Documents '
>    <draft-iesg-sponsoring-guidelines-01.txt> as an
> Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action.  Please send
> substantive comments to the [email-masked] mailing lists by
> 2007-02-21. Exceptionally,  comments may be sent to
> [email-masked] instead. In either case, please  retain the
> beginning of the Subject line to allow automated sorting.

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

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 08 Feb 2007 01:25:51 +0100

John C Klensin wrote:

> it should probably be published as an ION

Not publishing it at all is an alternative.  It would send an
unmistakable message to wannabe-authors, that they should use the
"independent" path, unless they're a friend of a friend of an AD.

Frank

---

From: Jari Arkko <[email-masked]>
Date: Thu, 08 Feb 2007 03:33:10 -0500

Frank,
> Not publishing it at all is an alternative.
And this is what we should do, if the community feels that
way. However ...
> It would send an
I personally feel fairly strongly that the individual
submission option is very useful for the IETF community --
along with the usual WG submissions and the independent
submissions via the RFC Editor. The reasons are described
in the draft, but relate to situations where non-WG proposals
are useful to the IETF community and require IETF and IESG
review.

By the way, the draft explicitly states that being friends with
an AD is NOT a reason for a draft to be sponsored. From what
I can see this is also the process that we follow. If not, please
complain!

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 08 Feb 2007 03:34:02 -0500

Thanks for your note John. Let me also emphasize the need for
these two drafts to be synchronized. Last calling draft-iesg
at this time was made in part because we wanted to get the
two in sync. I think we are more or less in sync but the
remaining input should come from the community.

As for the list to use for discussion -- sending mail to the
iesg list only would indeed be one way. The discussion list
we are on right now seems more suited, no?

Thanks again for raising these questions.

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Feb 2007 10:12:37 +0100

> "independent" path, unless they're a friend of a friend of an AD.

That is a complete mischaracterization. The intent in publishing
this (and doing so in parallel with draft-klensin-rfc-independent)
is to make it much clearer to authors when they should choose one
path and when they should choose another.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Feb 2007 10:09:50 +0100

John,

> non-WG submission space is adequately covered by one or the

Exactly right. These documents (and draft-iab-rfc-editor) need
to interlock and that is why they are open for review at the same
time.

> paths may or may not be alternatives to each other.

That is the intention; and we can indeed look at the titles
in that light.

> to read the I-Ds, but that is a one-way communications path.  

Well, the Last Call message suggested this list. And with one rather
small difference, the draft only attempts to describe current practice.
[The difference is that it calls for a publication request to be sent
to a single AD and not to the IESG as a whole.]
> RFC. 

We discussed this and reached the opposite conclusion, mainly
because of the point you raise above: consistency with two
other documents that will definitely be RFCs. But it was a
close decision.

> If they intend it to be definitive information for the

If we believed it modified or did violence to 2026, it would need to
be a BCP itself with a whole other style of review. But since its
intent is much milder, a normal LC seemed enough.

     Brian

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Feb 2007 07:16:52 -0500

> we are on right now seems more suited, no?

Sure.  But my point in that area was obviously not clear.  Prior
to the announcement of the Last Call, there was no indication to
the community that this document should be considered and
discussed, much less where.  There is no working group charter,
no history of open discussion, and so on.   And _that_ calls for
a four-week Last Call, not two weeks.

regards,
    john

---

From: Jari Arkko <[email-masked]>
Date: Thu, 08 Feb 2007 14:57:48 +0200

John,
> discussed, much less where.
Right. We weren't ready for a very wide discussion with
the earlier revision, it had too many obvious problems.
I hope the right discussion forum is now clear.
> There is no working group charter,
But its Informational. My read of RFC 2026 says that
the 4 week case applies to Standards Track only.

In any case, if it turns out that we get too little feedback
or there's significant controversy, I'm sure Brian will consider
what that means for successful end of the last call...

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Feb 2007 13:49:55 +0100

John,

> a four-week Last Call, not two weeks.

The rules require a 4 week last call for non-WG standards actions,
which this isn't, so the tracker automatically generated a 2 week
last call. But I assure you that discussion will not be truncated
arbitrarily as a result (i.e. I do not intend to rush this onto
the IESG agenda for Feb. 22).

     Brian

---

From: [email-masked] (Scott O. Bradner)
Date: Thu, 8 Feb 2007 08:05:11 -0500 (EST)

> the 4 week case applies to Standards Track only.

rfc 2026 says what must be done in some cases - it does not say what
can not be done in the cases it does not cover - specifically, RFC 2026
in no way would block a 4-week last call for an informational RFC
- note that RFC 2026 does not require any last call for informationals

fwiw - I agree with John - this doc warents a longer last call because
it does impact how part of the IETF process will work and the draft
did not get vetted in a normal working group process

Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Feb 2007 14:15:51 +0100

> did not get vetted in a normal working group process

As I said, this won't be rushed through. Let's see if there are any
comments of substance though.

     Brian

---

From: Sam Hartman <[email-masked]>
Date: Thu, 08 Feb 2007 10:19:29 -0500

>>>>> "John" == John C Klensin <[email-masked]> writes:

    John> --On Thursday, 08 February, 2007 03:34 -0500 Jari Arkko
    John> <[email-masked]> wrote:

    >> these two drafts to be synchronized. Last calling draft-iesg at
    >> this time was made in part because we wanted to get the two in
    >> sync. I think we are more or less in sync but the remaining
    >> input should come from the community.
    >> 
    >> iesg list only would indeed be one way. The discussion list we
    >> are on right now seems more suited, no?

    John> Sure.  But my point in that area was obviously not clear.
    John> Prior to the announcement of the Last Call, there was no

That sort of depends on  what's going on here.

Is Jari's draft an internal procedure of the IESG sent out for
community review because the IESG believes it has an obligation to
seek input on its procedures and to document them?
If so, then a two week last call seems fine?

Alternatively, is this an IETF community process document that will
bind the IESG in the future unless it is updated by the community?  If
so, then it should be a BCP and a four week last call.

My understanding was that RFC 2026 was normative here (although it
says basically nothing) and that the IESG was documenting its
procedures.

If the community believes that this topic is important enough that it
should be a community decision not an IESG decision, that seems
entirely fine to me.  But then this should not be an informational
document.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 08 Feb 2007 18:50:38 +0100

Jari Arkko wrote:

> please complain!

That was the complaint, the draft is from an IESG POV, and it
explains how to deal with confused authors claiming that a
single bit is enough to count to three or similar cases.

But it doesn't address the POV of authors who want to get an
evaluation of their I-D.  The first step is clear, figure out
the area, if that's unclear ask the General AD.

After that if the area has a "catchall crackpot WG" try to
get a review there, at some point in time ask the Chair(s)
to adopt the I-D.  Is that still correct ?

If the area has no catchall crackpot WG try to get reviews
on a related IETF or "other" list, at some point in time ask
one of the ADs.  

If that AD agrees to support it there will be a Last Call
or not - depending on the intended status, or the decision
of that AD to "last call" it anyway.

But what if the AD doesn't like it ?  Not all drafts try to
introduce ternary bits.  Apparently ADs are forced to vote
[Yes] (at least initially) if they "sponsor" a document.

What if they don't like it, but the authors still insist on
an evaluation ?  Can they appeal then ?  What if the AD 
does not like it personally, but admits that it's not as 
bad as the famous ternary bits ?

Frank

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Feb 2007 13:27:58 -0500

--On Thursday, 08 February, 2007 10:19 -0500 Sam Hartman
<[email-masked]> wrote:

>    John> Sure.  But my point in that area was obviously not
> clear.     John> Prior to the announcement of the Last Call,
> there was no
> 
> community review because the IESG believes it has an
> obligation to seek input on its procedures and to document
> them?
> Alternatively, is this an IETF community process document that
> will bind the IESG in the future unless it is updated by the
> community?  If so, then it should be a BCP and a four week
> last call.
> 
> My understanding was that RFC 2026 was normative here
> (although it says basically nothing) and that the IESG was
> documenting its procedures.
> 
> If the community believes that this topic is important enough
> that it should be a community decision not an IESG decision,
> that seems entirely fine to me.  But then this should not be
> an informational document.

Sam, I think we pretty much agree, and that is why my initial
note wasn't much more aggressive.  But it raises the issue that
others have raised:  if this meets the criteria for "IETF
documenting its procedures" and, as you have described it above,
"informational", then why not publish it as an ION given that
series was designed for just those sorts of things?    Please
take that as a question, not a position, but it is a very
serious one.

More generally, and independent of this particular document, it
seems to me that, with IONs in the mix, publishing something
that is informational about IESG procedures requires some
explanation.  Procedural BCPs do not, IONs do not, but
informational documents of this variety have now become sort of
an odd case.  And, IMO, if something that could reasonably be
published as an ION is proposed for publication as an Info RFC
instead, then that ought to imply a decision that serious
community discussion is in order, not just comments on a
collection of IESG decisions.

Put differently, I think the existence of IONs implicitly raises
the bar on Info publication of procedural docs, especially ones
that are just IESG statements of IESG procedures.

I think that is essentially the same question that Spencer and
others have raised.

      john

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 08 Feb 2007 13:01:58 -0600

Hi, Sam,

I agree with your note.

FWIW, and speaking only for the confused on the list,

- I understand why something should be a BCP (community consensus for a 
process that doesn't change every year or so),

- I understand why something should be an ION (IESG consensus with 
appropriate input from the community for a procedure that is likely to 
change from time to time), and

- I'm lost about why we would continue to publish Informational process RFCs 
(ignoring any existing pipeline of process documents remaining to be 
published as RFCs).

Spencer

From: "Sam Hartman" <[email-masked]>

---

From: Jari Arkko <[email-masked]>
Date: Fri, 09 Feb 2007 01:19:11 +0200

Hi Frank,
> single bit is enough to count to three or similar cases.

I would be happy to sponsor a ternary bit draft, but
only on April 1 :-)

> the area, if that's unclear ask the General AD.

Right.

> on a related IETF or "other" list, at some point in time ask

Right. But the draft says relatively little about this,
because there are different situations. Some areas
have a general purpose area working group with
chairs and an ability to produce documents just like
any other WG. Other areas (like INT) have only a
discussion forum that is not intended for detailed
protocol development. In the latter case the ADs
are likely to get more individual submission
proposals.

And the authors may not even be the active parties. ADs
may and sometimes do solicit specifications for some
purpose, such as fixing a bug or updating an aging
crypto algorithm.

> of that AD to "last call" it anyway.

Right.

> bad as the famous ternary bits ?

As with regular WG submissions, the document has to pass
the responsible AD's review. Otherwise it goes back to the
WG or the authors. ADs can always decline to sponsor a given
document, based on usefulness to the community, expertise,
etc. There is no guarantee that all suggestions will be
taken on.

Appeals procedures apply just like they do for other
contributions.

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 09 Feb 2007 11:10:39 +0100

> - I'm lost about why we would continue to publish Informational process 
> RFCs (ignoring any existing pipeline of process documents remaining to 
> be published as RFCs).

To me the argument for making this one an RFC is mainly that it
fits together with the two other drafts mentioned previously,
which pretty clearly need to be RFCs. But it wouldn't give me
any heartburn if the community consensus is to make it an ION.

     Brian

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 09 Feb 2007 17:04:18 +0100

Jari Arkko wrote:

> I would be happy to sponsor a ternary bit draft, but only on
> April 1 :-)

"IETF replaces 'bits' by 'tits', film@11", it could be a case
where April 1st is no good excuse.

What I don't like in your draft is the (apparent) personal veto
right for the AD.  Authors (hopefully) have an idea about their
topic, but they don't need to be procedural experts.  They don't
need to know what an "area" is, if it has a catchall WG or not,
and who the area directors are if it has no such WG.

They decide when their memo is ready to be published as RFC, and
what follows should be a simple procedure:  Send a "publication
request" to the IESG (maybe to a public list), get a responsible
AD, work it out.  The IESG or AD could tell them that the memo
belongs to an existing WG, that it's not in a shape to waste the
time for an IESG evaluation with it, and maybe that it's anyway
hopeless.

It's okay if there are shortcuts for authors knowing precisely
which area and AD they want, but generally authors shouldn't need 
to know this.  

If the IESG refuses to pick a responsible AD for a memo the author
should have a right to appeal.  With some chance authors would see
that their appeal will be decided by the same group who refused to
deal with their text in the first place, and don't try this.  But
maybe they want this situation on public record, because then the
"community" can check what's going on - "oh, Leibniz didn't speak
Chinese and erroneously stated there are only 64 trigrams for six
bits" or whatever the problem might be.

 [catchall WGs in some areas] 
> the draft says relatively little about this, because there are 
> different situations. Some areas have a general purpose area 
> working group with chairs and an ability to produce documents
> just like any other WG.

I certainly didn't know this before I read your I-D, it could be a
good idea.  Or not, depending on the catchall WG, if they refuse
to consider anything NIH.

> As with regular WG submissions, the document has to pass the 
> responsible AD's review. Otherwise it goes back to the WG or
> the authors.

That's apparently a side effect of the "must vote YES" rule.  One
part of it is clear, don't waste the time of the complete IESG if
the memo isn't in a shape for serious considerations.  But it's
a bad rule if the AD "only" doesn't like the memo, while others
could think it's okay.

With your draft you'd introduce a third point of failure - before
potential post Last Call "RFC editor note" or "AUTH48" mutilations
of a draft - a single AD can veto and kill anything as it pleases
him or her.

Ask another AD ?  Your draft tries to block that escape hatch.
Try "independent" ?  John's draft tries to block that too.  Last
solution, authors should start with "independent" if they're not
interested in arbitrary AD decisions.  If they try "individual" 
they'd be doomed if that fails.

Frank

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 09 Feb 2007 17:44:12 +0100

Frank,

> They decide when their memo is ready to be published as RFC,

No, that is not their decision. They decide that they would
*like* the document to be published as an RFC. And frankly if
someone's understanding of the IETF is such that they can't
even decide which Area is likely to be appropriate, I have to
wonder why they think they are ready to publish via the IETF.

> and
> AD, work it out. 

That doesn't actually work. Sending a message to a group of
very people is roughly like sending it to /dev/null. That's
exactly why we want to change this.

> The IESG or AD could tell them that the memo

Disagree, see above.
> should have a right to appeal.

Actually, the way we interpret RFC 2026, there is always a right
to appeal, whatever we write in this document.

> With some chance authors would see
> deal with their text in the first place, and don't try this.

That's why there is a 2nd level of appeal.

> But

Sure, a public record is good.

> to consider anything NIH.

That's why we also have Independent Submission, I think.

> a bad rule if the AD "only" doesn't like the memo, while others

True, if the NomCom appoints bad ADs...

> of a draft - a single AD can veto and kill anything as it pleases

No, the draft introduces nothing new at that stage - it's only
the very first step that is changed from what's been done for
many years.

> Ask another AD ?  Your draft tries to block that escape hatch.

Perhaps for ternary arithmetic, but not for something that
really belongs to another Area.

> Try "independent" ?  John's draft tries to block that too.

No

>  Last

No, in fact a common reply from an AD might be to recommend
independent submission if the work is interesting but really
outside IETF scope.

     Brian

---

From: "Tom.Petch" <[email-masked]>
Date: Fri, 9 Feb 2007 17:59:55 +0100

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: "Frank Ellermann" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, February 08, 2007 10:12 AM
Subject: Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area
Director Sponsoring of Documents) to Informational RFC

Brian

I agree that that should be the objective but I do not think that the four
documents (*) collectively achieve it.

The impression created, exaggerating slightly, is that WG submissions matter,
individual submissions we have to put up with and independent submissions we
would rather not mention.

There should be one document that is the starting point for those considering
the RFC and IETF processes, one that gives an even-handed treatment of the
available routes to varying outcomes, and this is not it.  The nearest is
draft-klensin-rfc-independent-05.txt and that is where I would point anyone.  We
may then want separate process documents helping people down their chosen path
and draft-iesg-sponsoring-guidelines (assuming that it is accurate, I am not
well placed to judge) would fulfil that secondary role.

Nor is this new.  I have been active here for over five years (and yes I read
the website and Tao before starting) but it was only in 2005 that I realised
that 'independent' and 'individual' were two different things, and it is John
Klensin that I have to thank for making me aware of it.  Nothing the IAB or IESG
had produced in the previous five years had brought out the distinction.
Likewise, it took several years to understand that the phrase 'RFC Editor'
carries overtones way beyond the task of editing something on its way to being
an RFC.  Nothing wrong with giving the phrase a special meaning, but it should
be explained in more places.

Tom Petch

(*) on reflection, I think that there are more like 14 documents in this problem
space.

---

From: Leslie Daigle <[email-masked]>
Date: Fri, 09 Feb 2007 13:20:04 -0500

Well, when the question (ION v. informational) came up
within the IESG's discussion of the document, this
is what I offered:

> On the ION v. RFC question -- I think this is *really*
> teetering on the edge!  I've copied below the
> relevant section of draft-iab-rfc-editor-03.  On
> the one hand, this document very clearly does not
> change the outcome of publish/don't publish decisions
> by the IESG (approvals).  From that perspective, I think
> it describes a process and could reasonably be an
> ION if the IESG so desires.
> 
> On the other hand, however, it does provide guidance and
> opinions about how proposed documents should be handled
> in individual or independent streams.  Put another way:
> it's normative for the "individual" part of the
> IETF stream of RFCs.  From that perspective, it should
> be published as an informational RFC as part of the
> suite of RFCs that provide the definition of the RFC
> series. 

In brief:  if it's just IESG process within stated
boundaries of IETF-stream documents, it can be an ION.
If it affects the substance of what fits in that stream,
I believe it fits under the umbrella of draft-iab-rfc-editor.

Per the latter document, the IAB gets a say in determining
community consensus when it comes to changing RFC series
documents.  The IAB isn't about to monitor IESG process
pages (IONs); it'd have to be an RFC.

So -- which is it?

(I'm updating draft-iab-rfc-editor now, as it has finished
its 4-weeks call for input; I'd like to know if I'm
referencing an RFC-to-be or not :-) ).

Leslie.

P.S.:  Again, copying the relevant bit from
draft-iab-rfc-editor-03:

 From draft-iab-rfc-editor-03:

 > 5.1.  RFC Approval Processes
 >
 >    Processes for approval of documents (or requirements) for each stream
 >    are defined by the community that defines the stream.  The IAB is
 >    charged with the role of verifying that appropriate community input
 >    has been sought and that the changes are consistent with the RFC
 >    Series mission and this overall framework.
 >
 >    The RFC Editor is expected to publish all documents passed to it
 >    after appropriate review and approval in one of the identified
 >    streams.
 >
 > 5.1.1.  IETF Document Stream
 >
 >    The IETF document stream includes IETF WG documents as well as
 >    "individual submissions" sponsored by an IESG area director.  Any
 >    document being published as part of the IETF standards process must
 >    follow this stream -- no other stream can approve Standards track or
 >    Best Current Practice (BCP) RFCs.
 >
 >    Approval of documents in the IETF stream is defined by
 >
 >    o  the IETF standards process (RFC2026, [3], and its successors).
 >
 >
 >
 >
 >
 > Daigle & Internet Architecture Board  Expires July 15, 2007    [Page 14]
 >
 > Internet-Draft           draft-iab-rfc-editor-03            January 2007
 >
 >
 >    o  the IESG process for sponsoring individual submissions (RFC XXXX,
 >       [9]).
 >
 >    Changes to the approval process for this stream are made by updating
 >    the IETF standards process documents.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 09 Feb 2007 13:29:16 -0500

Personally I've been convinced that this document definitely should
not be an informational RFC.

It should either be an ion or a bcp at the community's choice based on
how much review they want when the IESG decides to change things.

It doesn't make sense to me for the IETF to publish informational
documents about the RFC stream that are normative.  It makes sense I
understand why the IAB does so, and that's the best mechanism we have
for that purpose today.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 09 Feb 2007 21:13:02 +0200

Hi Tom,
> available routes to varying outcomes,

Right. If you are thinking in terms of an educational
document, I'm not sure sure we have one yet. But
draft-iab-rfc-editor describes the different RFC streams
(IETF, IRTF, independent, ...) and points to related
process documents, see its Section  5.

> and this is not it. 

Indeed, and it is not meant to be.

> The nearest is

Having separate process documents for each path is the
plan. Draft-iesg-sponsoring is intended to fulfill the secondary role.
Draft-klensin-rfc-independent also has a secondary role, talking
about the independent submissions.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 09 Feb 2007 21:57:58 +0200

Frank,

> and who the area directors are if it has no such WG.

The draft says that if you do not know which AD to contact
you can talk to the Gen AD first. But any AD or even a fellow
IETFer would surely be glad to help with such matters, and
guide people towards the right WG / Area / AD.

In any case, at the end of the day there is going to be someone
who has to decide whether a particular proposal fits the purpose
of the WG, the IETF or the RFC series. This someone can be the
people in the WG, the sponsoring AD, the RFC Editor depending
on what kind of a submission we are talking about, but there
is always someone. And as Brian noted, if this someone misuses
their power for personal reasons or some other reason, we
have an appeals process. I'm not sure there's fundamentally
any other way to handle this. And for IETF documents, that
someone is just handling the beginning of the process and
the proposal has to go through more review from the
community.

Jari

---

From: John C Klensin <[email-masked]>
Date: Fri, 09 Feb 2007 17:06:26 -0500

--On Friday, 09 February, 2007 13:20 -0500 Leslie Daigle
<[email-masked]> wrote:

>...

Leslie, 

I really don't care.  I can see some advantages to having
draft-iab-rfc-editor and the other two published as sequential
RFCs and am sort of leaning that way.  If it isn't, then
draft-iab-rfc-editor is going to need to send people off looking
for IONs, which seems mildly uncomfortable.  

If you go that route I would suggest that Jari put some words
into "sponsoring-guidelines" that make it an _initial_ procedure
under the new RFC Ed structure of draft-iab-rfc-editor.  Those
words should make it clear that the IESG can revise by ION:  I'd
hate to see the publication of this thing as an RFC (to make the
iab-rfc-... package coherent) force the IESG to make new RFCs to
tune its internal rules and procedures, especially since history
tells us that the most likely outcome of _that_ is ignored rules.

I'm sympathetic to Sam's comment about BCPs and _firmly_ believe
that it should apply in general.   This, however, is an odd
enough case that it might justify an exception.  As usual, I
don't believe that procedural notions, especially semi-informal
ones, should prevent us from doing the right thing.  Another
option of course would be for the IAB to cut a deal with the
IESG to publish all three of these as BCPs but without the IESG
messing with the contents of what are really IAB documents.
Probably that could be done by the IESG delegating
consensus-determination for the two draft-iab- pieces to the IAB
and agreeing, in advance, to accept the IAB's decision.
Something like that would actually make a lot of sense to me.

My major objection was to the two-week Last Call.   I think, as
a matter of taste, openness, and precedent, that any document
which is headed for RFC publication at the request of the IESG,
regardless of category, should get a four-week Last Call
(announced as a four-week Last Call, not two weeks and maybe
extended) unless it emerges from a formally open process with
clear opportunities for community input and discussion on every
posted version, such as from a WG.    This is not about what the
IESG is required to do --protocol-lawyering 2026 is, IMO, really
not interesting and could easily lead to appeals that reach the
ISOC Board-- but about what it should do.

      john

---

From: John C Klensin <[email-masked]>
Date: Fri, 09 Feb 2007 17:30:33 -0500

A couple of comments, with the understanding that Brian and are
in substantial agreement about all of this and complete
agreement about the things I've left out.

--On Friday, 09 February, 2007 17:44 +0100 Brian E Carpenter
<[email-masked]> wrote:

>...
>> That's apparently a side effect of the "must vote YES" rule.
>> One part of it is clear, don't waste the time of the complete
>> IESG if the memo isn't in a shape for serious considerations.
>> But it's a bad rule if the AD "only" doesn't like the memo,
>> while others could think it's okay.
> 

IMO, it is also why we have a recall procedure, no matter how
hard it is to invoke.   There is, IMO, a difference between an
AD who periodically exerts bad judgment (even if there is
community consensus that the judgment is bad) and an AD who
becomes abusive.  If a single AD does not like a document, but
the rest of the IESG is happy with it, there are always ways to
work that out (and I note that there are two ADs in every area
now) and appeals as a backup.  If an AD is so opposed as to
become abusive, despite generally IESG agreement that the
document is ok, then I would guess that that particular AD's
opposition will rarely be an isolated case of difficult behavior
and the broader problem becomes worth solving.

> really belongs to another Area.

Or, presumably, that could be handled by anther AD in the same
area.  If the nomcom has done a competent job, and both ADs in
an area are opposed to a document, then either the doc author
has a problem or...

>> Try "independent" ?  John's draft tries to block that too.

No.  We shall see what that draft says when the IAB gets
finished with it, but the restrictions there very much have to
do with not having failed IETF documents bounced over without
some critical work.   Individual submissions are not IETF
documents in that sense, so there should really be no issue.  

As a piece of free and very general advice, and speaking
personally (not for the RFC Editor or the Ed Board), if I tried
to take a document, individually, to some AD and got hard
pushback, I'd assume that pushback would reappear when the RFC
Editor sent the document over for RFC 3932 review.  And then,
before taking the document in under "independent", I'd advise
editing/ revising it to make it as IESG-proof as possible.  That
would involve making sure it didn't sound like a standards-track
protocol spec, didn't ask for IANA actions, and, if the reason
for the AD rejection was because the document was critical of an
IETF decision or direction, it was clearly written as a balanced
critical analysis rather than a proposal that someone could
point to and say "evil".

       john

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 9 Feb 2007 17:38:21 -0500

On Fri, 09 Feb 2007 21:57:58 +0200

> the proposal has to go through more review from the

Right.  The IETF is not a general-purpose publishing house for
networking documents.  

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 10 Feb 2007 01:07:13 +0100

Jari Arkko wrote:

> And as Brian noted, if this someone misuses their power for
> personal reasons or some other reason, we have an appeals
> process. I'm not sure there's fundamentally any other way
> to handle this.

Nor me.  Forcing them to either vote "Yes" for a document they
don't really like, or refuse an IESG evaluation, that could be
a dilemma for the AD.  And finding an AD where that situation
is unlikely could be an difficult for authors - if they know
this potential dilemma.

 [Brian also mentioned:]
| in fact a common reply from an AD might be to recommend
| independent submission if the work is interesting but really
| outside IETF scope. 

Maybe the draft should say so at the end of the 4th paragraph
in chapter 3, where it talks about BoFs and WGs.  Or at the
end of chapter 5.  I don't like this draft, "send publication
request to secretariat" is more attractive than spamming ADs.

Frank

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 11 Feb 2007 12:13:11 +0100

Frank

On 2007-02-10 01:07, Frank Ellermann wrote:

> ...  I don't like this draft, "send publication

You probably need to understand what happens when someone
does that. The Secretariat simply forwards the note to the
IESG. After a while, the IESG Chair will (with luck) have
handled everything that looks urgent, and will take a glance
at draft-smith-my-new-idea and make an uninformed guess that it
fits the smurf Area. (So far, elapsed time is a couple of weeks
wait plus 3 minutes attention.) The IESG Chair will send a note
to one or both smurf ADs saying "Can you have a look at this?".
And then the process proposed by draft-iesg-sponsoring-guidelines
actually starts - probably with another wait until one of
those ADs has handled everything that looks urgent.

It makes a lot more sense, IMHO, for the author to decide
that her work fits the smurf Area and write directly to the
ADs. In either case, the first real step is for those ADs
to look at the draft and respond to the author.

     Brian

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 11 Feb 2007 18:28:45 +0100

Brian E Carpenter wrote:

>> "send publication request to secretariat" is more attractive
>> than spamming ADs.
 
> does that.

Yes, I haven't tested it yet.

> The Secretariat simply forwards the note to the IESG.

Don't they also set the "pubreq" bit in the I-D tracker ?

> After a while, the IESG Chair will (with luck) have handled
> everything that looks urgent, and will take a glance at
> draft-smith-my-new-idea and make an uninformed guess that it
> fits the smurf Area.

Doesn't sound good, I thought it would hit a "tracker exception"
or something after a while (if nobody feels like looking at it).

> The IESG Chair will send a note to one or both smurf ADs 
> saying "Can you have a look at this?".

The Chair could appoint...
http://www1.tools.ietf.org/group/iesg/trac/wiki/IesgWhips 
...for stuff stuck in procedural corners.  Getting the "pubreq"
flag is important, it won't go away unless the author gives up,
or it's transformed to "do not publish" / "RFC published".

> then the process proposed by draft-iesg-sponsoring-guidelines

But without the "AD shopping" mentioned in the draft, what I
called "AD spamming":  One of the two ADs has to do something
visible in the I-D tracker, like enter "revised ID needed" or
start a last call.  Or note it as "dead", or if that's allowed
maybe "demote" it to "AD is watching" - when the authors agree.

So far I thought that authors create this "pubreq" flag, for 
individual I-Ds, or otherwise the WG Chairs representing some
consensus of their WG.

With the proposed procedure it's apparently the IESG creating
any "pubreq" flag, and you can block this important step in a
rather obscure (= invisible in the tracker) procedure, roughly
reflecting "nobody feels like caring about the I-D".

Frank

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Feb 2007 12:05:47 +0100

Frank,

> Don't they also set the "pubreq" bit in the I-D tracker ?

Very possibly, but that is just a progress tracking issue.
I agree we need a progress tracking mechanism, but that
isn't the underlying point here, which IMHO is to get the
author in discussion with the appropriate AD.

     Brian