Subject: Re: RFC 2434 term "IESG approval" (Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option)

From: [email-masked] (Scott Bradner)
Date: Wed, 29 Jun 2005 16:51:27 -0400 (EDT)

Margaret sed:
> Personally, I think that if the IETF doesn't want to give the IESG 
> the right to approve (and refuse to approve) the allocation of IP 
> options, then the IETF should update  RFC 2780.

for what it's worth (speaking as an IETFer, forment IESGer & co-author of
RFC2780) - to me its not a question of the IESG having "the right to
approve (and refuse to approve) the allocation of IP options" - its a 
question of process - specifically *how* should the IESG "refuse to
approve" an assignment - thus its not a question of changing 2780
to remove that right 

but maybe it is a question of establishing an understanding of
what process the IESG should follow (e.g. make a statement
and subject it to a process along the line of a Last-Call)

this is not that new a concept - ADs have done this in the past (see 
for example, Randy's request for input about PIBs and the process that 
was followed to see if the IETF should continue to work on CR-LDP) - 
I see no reason that the IESG could not do the same sort of thing

note that I think that any assertion that one can not do a last-call 
wiithout an ID misses the point - the point being that the IESG
should attempt to get an understanding of the IETF community's 
opinion on the IESG's conclusion - calling it a "Last-Call" is
just using a common IETF term as a way to describe a process
so that people can easily understand the concept

Scott

(also see draft-klensin-iana-reg-policy-00.txt)

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

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 29 Jun 2005 17:39:37 -0400

Hi Scott,

I agree that this would be a reasonable process, but wouldn't that be 
"IETF Consensus" (an entirely separate choice in RFC 2434 from IESG 
Approval)?

I said that I was confused...  and this is the main point that is 
confusing me.  The arguments against what the IESG has done seem, 
mostly, to be that we should have gotten IETF consensus before
making  a decision.  But, if the IESG isn't supposed to make any 
decisions without IETF consensus, then why are these two separate 
choices in RFC 2434?

Margaret

---

From: [email-masked] (Scott Bradner)
Date: Wed, 29 Jun 2005 18:03:50 -0400 (EDT)

> "IETF Consensus" (an entirely separate choice in RFC 2434 from IESG 

see RFC 2434 
      IETF Consensus - New values are assigned through the IETF
           consensus process. Specifically, new assignments are made via
           RFCs approved by the IESG.

note that IETF Consensus specifically requires an RFC approval

on the other hand "IESG Approval" specifically does not require a RFC
      IESG Approval - New assignments must be approved by the IESG, but
           there is no requirement that the request be documented in an
           RFC

so a process by which the IESG determines if the IETF community 
agrees with a decision to reject an assignment request which is
not done by ID/RFC is not the same thing as "IETF Consensus" in
RFC 2434

fwiw - saying that the IESG should check with the community should
be a simple concept to understand - but maybe I'm wrong

Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Jun 2005 00:27:21 +0200

> be a simple concept to understand - but maybe I'm wrong

It's not a hard concept. It just isn't mentioned or implied in RFC 2780.

    Brian

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 30 Jun 2005 00:43:33 +0200

Dear Scott,
RFCs are made to be adapted to needs. The question should be "what do we 
want?". I think the response is "to experiment". This means that every 
registry should include an ad-experimendam area. If the experimentation is 
OK it will permit to document the allocation of a code point without 
interrupting the experimentation. If the experimenation fails, then who 
cares? 200 mails on "IESG approval" saved each time.

The main characteristics of an experimentation should be: community 
oriented (not private), reversible, not affecting non participants 
operations, no acquired rights without community approval, limited scope in 
time and space. Documentation is of no interest until it succeeds. This 
should not be confused with a private area: private usage is to be 
protected/separated from experimentation.
jfc

---

From: Hans Kruse <[email-masked]>
Date: Wed, 29 Jun 2005 21:49:07 -0400

Margaret,

my concerns (and those of others) are a bit different I think.  Again, 
I see what happened as:

1. A non-IETF standard is being developed.
2. The standard is being reviewed by another organization.
3. The group working on the standard requests a code point from IANA

The "IESG review" is the only available process since no technical 
review is requested within the IETF (both of the other options would 
seem to imply such a review).

The IESG seems to have reacted by assuming that it had to substitute 
its judgment for the technical review which is not part of the request, 
and I think _that was wrong_.

If the IESG concluded that a technical review was needed, then _IETF 
consensus_ would be appropriate.  BUT, in this case my read is that the 
IESG should _not_ have conducted a technical review, but rather should 
have limited the review only on whether a code point was available, and 
whether a hop-by-hop option unknown to most devices would cause any 
foreseeable problems.

That last point bothers me the most;  if a standard is being developed 
within the framework of another known standards organization and on top 
of this (in this case) by a known set of engineers, should the IETF not 
focus on interoperability instead of second-guessing the outside work?  
I could see how an unknown IPv6 option header could possibly become a 
problem (although that would point to bad protocol design or 
implementation, IMHO), so interoperability should be reviewed, but 
otherwise I _cannot_ see how the _content_ of the option could harm a 
device that does not want to deal with it.

> decisions without IETF consensus, then why are these two separate 
Hans Kruse, Associate Professor
J. Warren McClure School of Communication Systems Management
Adjunct Associate Professor of Electrical Engineering and Computer
Science
Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

---

From: John C Klensin <[email-masked]>
Date: Thu, 30 Jun 2005 03:05:55 -0400

Jefsey,

Many of us await, with great interest, the appearance of an
Internet Draft from you that explains how, with a field with a
finite (and fairly small) number of bits available, once can
carry out an arbitrary number of properly-identified
experiments.  Even a discussion about how one might make an
allocation reversible --in terms of recovering or slicing up
bits that carry, well, only one bit of information-- within a
non-private network or enforce the end of an experiment so that
another could begin would be extremely interesting.

Of course, one might argue that protocols should contain,
instead of fixed-width option fields, fields of arbitrary
variable lengths, thereby eliminating the difficulties implied
above.  If that is the model you would like to propose, the
Internet Draft that explains how to do it without significantly
reducing the performance of IP would be of even more interest
(several previous proposals in that area have required faster
light, which no one has yet managed to arrange).

But, either way, please put it into an Internet Draft that we
can study and, if necessary reference and preserve, rather than
continuing with email.  The posting deadline is a week from next
Monday.

    john

--On Thursday, 30 June, 2005 00:43 +0200 "JFC (Jefsey) Morfin"
<[email-masked]> wrote:

> Dear Scott,
> RFCs are made to be adapted to needs. The question should be
> "what do we want?". I think the response is "to experiment".
> This means that every registry should include an
> ad-experimendam area. If the experimentation is OK it will
> permit to document the allocation of a code point without
> interrupting the experimentation. If the experimenation fails,
> then who cares? 200 mails on "IESG approval" saved each time.
> 
> The main characteristics of an experimentation should be:
> community oriented (not private), reversible, not affecting
> non participants operations, no acquired rights without
> community approval, limited scope in time and space.
> Documentation is of no interest until it succeeds. This should
> not be confused with a private area: private usage is to be
>> > I agree that this would be a reasonable process, but
>> > wouldn't that be "IETF Consensus" (an entirely separate
>> > choice in RFC 2434 from IESG Approval)?
> 
>

---

From: John C Klensin <[email-masked]>
Date: Thu, 30 Jun 2005 03:27:56 -0400

Hans,

I think this formulation is consistent with what I, and others,
have been trying to say.  I would, however, add one element.

The IESG was asked to approve a code point for work developed
elsewhere.  There is no question that they could have approved
it and approved it on the basis of the request, rather than
requiring or conducting an expert technical review (that is what
2780 quite clearly says).  Perhaps they should have done so,
perhaps not.

However, especially since the IETF maintains liaisons with at
least a subset of the other standards bodies involved, when the
IESG decided that a technical review was necessary, they should
have managed things so that one was performed.  Elements of such
a review might have included contacting the other organization
and making a review plan with them (including a document
distribution plan if appropriate), or discussions with the WGs
involved on the IETF side, or other work in the community,
presumably leading up to a Last Call or the equivalent.

Instead, the IESG chose to do its own review internally, without
consulting either the relevant WGs, or their Chairs, or the
broader community.  And that, we agree, was the wrong thing to
do.

Fwis, draft-klensin-iana-reg-policy-00.txt is an attempt to give
the community a chance to clarify and establish the type of
policy it prefers be applied in this sort of matter.

      john

--On Wednesday, 29 June, 2005 21:49 -0400 Hans Kruse
<[email-masked]> wrote:

> Margaret,
> 
> my concerns (and those of others) are a bit different I think.
> Again, I see what happened as:
> 
> The "IESG review" is the only available process since no
> technical review is requested within the IETF (both of the
> other options would seem to imply such a review).
> 
> The IESG seems to have reacted by assuming that it had to
> substitute its judgment for the technical review which is not
> part of the request, and I think _that was wrong_.
> 
> If the IESG concluded that a technical review was needed, then
> _IETF consensus_ would be appropriate.  BUT, in this case my
> read is that the IESG should _not_ have conducted a technical
> review, but rather should have limited the review only on
> whether a code point was available, and whether a hop-by-hop
> option unknown to most devices would cause any foreseeable
> problems.
> 
> That last point bothers me the most;  if a standard is being
> developed within the framework of another known standards
> organization and on top of this (in this case) by a known set
> of engineers, should the IETF not focus on interoperability
> instead of second-guessing the outside work?  I could see how
> an unknown IPv6 option header could possibly become a problem
> (although that would point to bad protocol design or
> implementation, IMHO), so interoperability should be reviewed,
> but otherwise I _cannot_ see how the _content_ of the option
> could harm a device that does not want to deal with it.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Jun 2005 17:14:49 +0200

Hans Kruse wrote:
...
> but otherwise I _cannot_ see how the _content_ of the option could harm a device that does not want to deal with it. 

If it interferes with congestion management elsewhere along the path, it can potentially damage
every other packet stream. This is a *very* complex discussion of course.

    Brian

---

From: Sam Hartman <[email-masked]>
Date: Thu, 30 Jun 2005 17:21:10 -0400

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

    John> Hans, I think this formulation is consistent with what I,
    John> and others, have been trying to say.  I would, however, add
    John> one element.
    John> However, especially since the IETF maintains liaisons with
    John> at least a subset of the other standards bodies involved,
    John> when the IESG decided that a technical review was necessary,
    John> they should have managed things so that one was performed.
    John> Elements of such a review might have included contacting the
    John> other organization and making a review plan with them
    John> (including a document distribution plan if appropriate), or
    John> discussions with the WGs involved on the IETF side, or other
    John> work in the community, presumably leading up to a Last Call
    John> or the equivalent.

John, this attitude really frustrates me.

The IETf has had a long tradition that deciding whether technical
review is required is a separate process from deciding the management
issue of whether to perform that review.

This idea has even been codified in a specific case.  RFC 3932 allows
the IESG to say that some external contribution being published
conflicts with work within the IETF and would require review within
the IETF.  However it explicitly says that making such a statement is
not a promise that such review will or should be conducted.  That
decision is made through our normal processes: RFC 2026 2418 and the
specific operating procedures of established working groups.

In fact in the RFC 3932 case, the IESG is explicitly encouraged
(perhaps required is a better term) not to engage in technical review,
only to determine whether technical review is needed.

I can cite other examples from BCPs where these two issues are
separated.  In a not identical but similar veign, our liaison
statement processes do not require us to conduct review requested by
other standards organizations; they explicitly require us to respond
to the request.  However one of the responses can be that we choose
not to conduct the review in question.

The RFc 2780 procedures are a sparse.  We'd all be happier if the
community had given us more advice on what criteria to use when
evaluating hop-by-hop option requests and on what procedures were
desirable.  But in the absence of such guidance, it is reasonable for
the IESG to adapt a similar procedure another area where we get
external contributions and requests.  The IESG quickly determined if
additional review is required and gave some reasons why that review
seemed important.

The IESG did not choose to allocate resources to that review.  You
might not like that decision, but it is a decision it is important for
the IESG to be able to make.  (It's also important that the community
be able to allocate the resources if the community disagrees with the
IESG--such disagreements are not a process failure and should be
expected to happen from time to time.)

The IESG is under significant pressure to improve the management of
the IETF.  The community believes that the IESG has management
responsibility for the timeliness ande appropriateness of the output
of the IETF.  If the IESG is going to have this responsibility it
should be given the tools to act on this responsibility.  The
community should retain the ability to override the IESG's initial
judgment because allocation of resources is in fact an area where
judgment is important and the IESG will make mistakes.

One tool the IESG needs is to be able to set the bar fairly high for
new work in the IETF that is unlikely to gain consensus.  This is
especially true when there is existing conflicting work in the IETF.
We don't value multiple protocols for doing the same thing for the
sake of having multiple protocols.  Clearly we sometimes do charter
multiple efforts to do the same thing, but we tend to require a higher
bar when that is the case.  If the IESG does not have this ability,
then it will be forced to charter work that is more likely to
ultimately fail, consuming significant resources in the process.

Committing to review any proposal that comes in from another standards
organization is not compatible with efficient management of the IETF.
There are cases where it is critical that we engage in such work, but
that is a management decision that the IESG needs to have initial
decision ability for if it is going to have responsibility for the
resulting work.

I do not feel comfortable discussing the reasoning that lead to the
particular management decision not to allocate resources to this work
item on a public list.  There are parts of any discussion of this type
that do involve politics.

However I would like to look at what options the community has in
order to disagree with this decision.  First, while the option of
appeal does exist, it seems like an inefficient option to employ and
there are better alternatives.  Someone could write an internet draft
allocating the codepoint; if they believe that we should allocate the
codepoint without technical review of the proposal, then they could
contain few details on that draft about the proposal but instead
reference the existing specification.  If they believe the technical
details are important, they could include those details; presumably
reviewing the technical details would require the support of
Dr. Robrets.  If people believe that the guidelines in RFC 2780 should
encourage the IESG to assign options whenever the use is sufficiently
specified and there is likely to be a significant deployment, then
they could propose revising RFC 2780 with those requirements.

Yes, the IESG could abuse its power in the future.  For example if it
failed to charter work for one of the previous options in the presence
of significant community support, then the IESG would be abusing its
power.  If the IESG blocked such a document with discusses that
challenged the fundamental premis of the document while there was
community support then the IESG would be abusing its power.  If the
IESG constructed unreasonable process blocks or unfairly enforced
process issues against these documents then it would be abusing its
power.  But if the IESG is going to have management responsibility, it
needs the authority to recommend against things it believes are wastes
of time.  Some times the community will disagree with those
recommendations; so long as the IESG does not block the community
that's entirely fine and will be a result of an open process.

I would like you to consider one thing with regard to the specific
proposal.  We both seem to believe it is reasonable for the IESG to
require community review.  That community review is going to require
the support of the IPV6 and NSIS/QOS communities in order to build a
rough consensus.  So far, I'm not hearing requests either from the
IPV6 or QOS communities for the opportunity to review this proposal.
If those communities don't want to support the proposal, it will
ultimately go nowhere within the IETF.  Why should we be spending
effort on the proposal without interest from the areas of the IETF
that would ultimately review it? 

--Sam

---

From: Dave Crocker <[email-masked]>
Date: Thu, 30 Jun 2005 14:54:00 -0700

> The community believes that the IESG has management
> of the IETF.  

Sam,

I think you have identified the crux of a very serious disconnect.

Wherever did you obtain the view that the community delegated this 
responsibility (and authority) to the IESG?

Over the last 3-4 years, the community has provided extensive and sustained 
expression of a desire to have the IESG assert LESS "responsibility" for the 
work that is done and to have the IESG serve as a choke point less.

How is it that the IESG has completely missed this feedback?

Initiatives come from the community, and the real work of the IETF is done by 
working groups.

The job of the IESG is to facilitate those initiatives and that work and to 
assess community rough consensus about the work.

The IESG can mentor working groups, so that they are more timely and produce 
better quality output.  It also can impede timeliness and progress, such as by 
asserting late-stage vetos by virtue of introducing new and whimiscal 
requirements.

Certainly it is essential to resolve this extreme disparity about the IESG's job.

-- 
 
   d/

ps.  Please forgive the Subject line, but I think it important to make the 
nature of the disconnect crystal clear.

  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

---

From: grenville armitage <[email-masked]>
Date: Fri, 01 Jul 2005 07:58:42 +1000

Brian E Carpenter wrote:

> Hans Kruse wrote:
> ...
> 
>> but otherwise I _cannot_ see how the _content_ of the option could 
>> harm a device that does not want to deal with it. 
> 
> 

I can see it interfering for two reasons. (a) The option codepoint clashes
with the codepoint used by another congestion management mechanism (thereby
confusing routers handling packet streams using the same codepoint differently),
or (b) IPv6 option handling is flawed in so far as an unknown option turning
up in a packet stream can totally mess with 'congestion management elsewhere
along the path'.

Scenario (a) would seem to be solved by assigned a non-conflicting option
codepoint and then hoping the competing protocol dies of irrelevance.
Scenario (b) suggests we have bigger problems. I'm honestly hoping it isn't
scenario (b), and that there's an scenario (c) I'm just not seeing.

cheers,
gja

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 30 Jun 2005 18:50:01 -0400

> scenario (b), and that there's an scenario (c) I'm just not seeing.

Have you read the spec in question?

The issue is not that the presence of an unknown option interferes with 
congestion control.  The problem is that when the endpoints _do_ implement 
the option, they can sometimes decide to disregard TCP congestion control 
procedures such as slow-start, which while implemented on an end-to-end 
basis nonetheless affect congestion control on all intervening segments.

Now, it's possible that, in the circumstances in which this spec allows 
endpoints to punt on slow-start, it is actually safe to do so without 
risking causing problems for the rest of the network.  But I haven't read 
the document in enough detail to know that, and the potential for problems 
if it is not is quite large.  I'd be much happier if any proposal along 
those lines were reviewed by the IETF (particularly, experts in IPV6, QOS, 
TCP, congestion control, etc) before being unleashed on the Internet.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: John C Klensin <[email-masked]>
Date: Thu, 30 Jun 2005 18:50:30 -0400

--On Thursday, 30 June, 2005 17:21 -0400 Sam Hartman
<[email-masked]> wrote:

>     John> Hans, I think this formulation is consistent with
> what I,     John> and others, have been trying to say.  I
> would, however, add     John> one element.
>     John> However, especially since the IETF maintains
> liaisons with     John> at least a subset of the other
> standards bodies involved,     John> when the IESG decided
> that a technical review was necessary,     John> they should
> have managed things so that one was performed.     John>
> Elements of such a review might have included contacting the
> John> (including a document distribution plan if appropriate),
> or     John> discussions with the WGs involved on the IETF
> side, or other     John> work in the community, presumably
> leading up to a Last Call     John> or the equivalent.
> 
> 

That is surprising because, with one exception, I don't see
where we disagree.

> The IETf has had a long tradition that deciding whether
> technical review is required is a separate process from
> deciding the management issue of whether to perform that
> review.

Huh?  In the critical edge cases, that would permit the IESG to
kill an idea by saying:

	(i) That idea/request/documentcannot go forward without
	technical review
	
	(ii) We refuse to authorize or manage such a review,
	therefore it will not occur and the idea or document is
	dead.

While, presumably, that combination of actions could be
appealed, it would put us into a position in which we would be
managing by appeal.  And that can't be a good idea.

> This idea has even been codified in a specific case.  RFC 3932
> allows the IESG to say that some external contribution being
> published conflicts with work within the IETF and would
> require review within the IETF.  However it explicitly says
> that making such a statement is not a promise that such review
> will or should be conducted.  That decision is made through
> our normal processes: RFC 2026 2418 and the specific operating
> procedures of established working groups.

But RFC 3932 applies to one specific case -- consideration of
documents submitted by individuals (or groups of individuals) to
the RFC Editor.   The expectation, at least when I read the
document on Last Call, was that the IESG might well say "well,
this  document conflicts with work being done in the FOOBAR WG,
and that author should take it there and see if it gets any
traction".  Certainly that is consistent with what you say
above.  But note that WGs don't last forever, or at least are
not supposed to.  Sooner or later, FOOBAR will presumably either
emit the document with which the submission conflicts.  If the
author then comes back and says "I want to publish this as a
dissenting opinion", there is no longer a conflict, and the IESG
can ask (and I would assume the RFC Editor would require) that
the document be published with some clear disclaimer text that
indicates that the standards-track path lies elsewhere.

What I don't think the IESG is ethically permitted to do, even
under the provisions of 3932, is say "it conflicts with work
being done now in the IETF or that might be done in the future,
so it can't be published, but we won't identify the work or
facilitate a review".   Probably the IESG could read 3932 to
permit that, but I would assume that the RFC Editor might ignore
such feedback (which might set off a crisis).   And I would
assume that, if it happened with any frequency or relative to
something important, the community would move to clarify 3932 to
eliminate that possibility.

> (perhaps required is a better term) not to engage in technical
> review, only to determine whether technical review is needed.

It seems to me that the key text in 3932 is

		In March 2004, the IESG decided to make a major change
		in this review model.  The new review model will have
		the IESG take responsibility ONLY for checking for
		conflicts between the work of the IETF and the documents
		submitted; soliciting technical review is deemed to be
		the responsibility of the RFC Editor.

That doesn't give the IESG even the authority to say "this needs
technical review" at all.   All the IESG can do is say
"conflicts with work in the IETF"... or not.

The list in section 3 is not quite consistent with the above,
but it is very close.   In particular, we have:

		  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.

Note also the subsequent section...

		Redirection to the full IESG review path is not a
		guarantee that the IESG will accept the work item, or
		even that the IESG will give it any particular priority;
		it is a guarantee that the IESG will consider the
		document.

which I think is what you are referring to above.  This path is
optional for the author, the IESG does guarantee to consider the
document, and the action considering it is, presumably,
appealable if necessary.

> statement processes do not require us to conduct review
> requested by other standards organizations; they explicitly
> require us to respond to the request.  However one of the
> responses can be that we choose not to conduct the review in
> question.

Absolutely.  But, if you do not choose to conduct or manage a
review, the other body would presumably feel justified in doing
whatever it pleases, assuming that the IETF has no input of
substance.  The IETF, and still less the IESG, can't both
control external behavior and refuse to comment substantively on
it. 

> The RFc 2780 procedures are a sparse.  We'd all be happier if
> the community had given us more advice on what criteria to use
> when evaluating hop-by-hop option requests and on what
> procedures were desirable.  But in the absence of such
> guidance, it is reasonable for the IESG to adapt a similar
> procedure another area where we get external contributions and
> requests.  The IESG quickly determined if additional review is
> required and gave some reasons why that review seemed
> important.

And then proceeded to indicate, albeit in quite convoluted
language, that it thought such review was pointless.  That is
where we are having a disagreement.  I believe, and various
other writers believe, that can, and should, approve these "IESG
approval" registration requests when they seem reasonable.
Conversely, we do not believe that the IESG should be able to
block a registration without at least some minimal level of
community review and consensus.  If I correctly understand your
comments and those of others, the IESG disagrees and believes
that the community has given it the authority, nay the
responsibility, to block registrations when it finds the
protocols inappropriate for any reason.

So, ok, we disagree.  That should not be a problem once we
understand what we are disagreeing about.  The normal IETF way
to deal with such a disagreement is to write a draft clarifying
the rules (one way or the other), discuss it in the community,
and see which interpretation gets consensus.  When we get
through that process, presumably there will be no further
ambiguity or differences in interpretation.   I don't see that
as a problem; I see it as progress.   And it was exactly for
that purpose that Vint, Scott, and I wrote and posted
draft-klensin-iana-reg-policy-00.txt.

> The IESG did not choose to allocate resources to that review.
> You might not like that decision, but it is a decision it is
> important for the IESG to be able to make.  (It's also
> important that the community be able to allocate the resources
> if the community disagrees with the IESG--such disagreements
> are not a process failure and should be expected to happen
> from time to time.)

We agree.

> The IESG is under significant pressure to improve the
> management of the IETF.  The community believes that the IESG
> has management responsibility for the timeliness ande
> appropriateness of the output of the IETF.  If the IESG is
> going to have this responsibility it should be given the tools
> to act on this responsibility.  The community should retain
> the ability to override the IESG's initial judgment because
> allocation of resources is in fact an area where judgment is
> important and the IESG will make mistakes.

Ok.
 
> One tool the IESG needs is to be able to set the bar fairly
> high for new work in the IETF that is unlikely to gain
> consensus.  This is especially true when there is existing
> conflicting work in the IETF. We don't value multiple
> protocols for doing the same thing for the sake of having
> multiple protocols.  Clearly we sometimes do charter multiple
> efforts to do the same thing, but we tend to require a higher
> bar when that is the case.  If the IESG does not have this
> ability, then it will be forced to charter work that is more
> likely to ultimately fail, consuming significant resources in
> the process.

No one is trying to 'force' the IESG to do anything.  Several of
the options that have been explicitly floated involve "post an
I-D, take it into the relevant WG, and see if your I-D gets
traction, either as a substitute for whatever than WG is doing
or as something that can inform the WG's work and provide a new
perspective".   Presumably the IESG would not try to block such
an effort.

But the key issue here has nothing to do with the "it needs
technical review and we don't want to allocate the resources"
path down which we seem, again, to be going.  The question is
"if party X intended to allocate protocol Y on the Internet,
with or without IETF approval, and has the resources,
implementations, and support to do so, is it appropriate that
the IETF ignore that effort or should we, instead, try to devise
some mechanism for recognizing their method so it can be
prevented from interfering with other things".   

Some of us consider the "the try to ignore it" path to be naive
and dangerous, especially if its advocates assume that ignoring
it will cause it to go away.   There is at least one, well-known
and well-established, technical method for preventing conflicts
between options that are mutually unknown.   That method is to
assign both appropriate codes so that receiving systems can
accept one, the other, or neither without fear of ambiguity.
That particular mechanism of using registrations and options
doesn't need technical review; we have years of successful
experience with it.  If the IESG wants to propose an alternative
for community review, that would be fine too, but such an
alternative would require technical review.

Put differently, I think the IETF has a moral obligation to
either accept registrations of methods and options that are
technically plausible (to determine that, we could use the
traditional tests of operational implementations and passing
laugh tests, neither of which are "technical review" or to
propose some alternative.  "We don't like it so you don't get
it" is both impolite and almost certainly ineffective.   Whether
it is worth doing the other work or the registration should be
accepted by default is a subject on which I hope that IESG would
have an opinion which it would express clearly to the community.

> Committing to review any proposal that comes in from another
> standards organization is not compatible with efficient
> management of the IETF. There are cases where it is critical
> that we engage in such work, but that is a management decision
> that the IESG needs to have initial decision ability for if it
> is going to have responsibility for the resulting work.

Concur, as long is that word "initial" is clearly understood.
And as long as it is understood that the other standards body is
likely to consider it reasonable to do whatever it wants to do
if the IETF declines to comment on or interact with its plans.
That, in fact, creates a problem of management and priorities.
And, again, I would hope and expect the IESG to have opinions on
the subject and to share those opinions with the community.

> I do not feel comfortable discussing the reasoning that lead
> to the particular management decision not to allocate
> resources to this work item on a public list.  There are parts
> of any discussion of this type that do involve politics.

ok.  please see below.

> However I would like to look at what options the community has
> in order to disagree with this decision.  First, while the
> option of appeal does exist, it seems like an inefficient
> option to employ and there are better alternatives.

Yes.  However, I would suggest that an appeal, focusing not on
failure to grant the codepoint but on the IESG's declining to
tell the community why it made the decision, might be in order
and appropriate.

>  Someone
> could write an internet draft allocating the codepoint; if
> they believe that we should allocate the codepoint without
> technical review of the proposal, then they could contain few
> details on that draft about the proposal but instead reference
> the existing specification.

That would be reasonable except for the fact that the IESG has
appeared to send a clear message that the response to such an
I-D would be the statement that it needed technical review and,
presumably, that the IESG was not willing to try to seek or
allocate resources to get it done.   That would take us back
around the loop we are in now, but with an action that would be
more easily appealed.  I don't think either of us want to see
management by appeal.

>  If they believe the technical
> details are important, they could include those details;
> presumably reviewing the technical details would require the
> support of Dr. Robrets.  

> If people believe that the guidelines
> in RFC 2780 should encourage the IESG to assign options
> whenever the use is sufficiently specified and there is likely
> to be a significant deployment, then they could propose
> revising RFC 2780 with those requirements.

Which is, in essence, what draft-klensin-iana-reg-policy-00.txt
proposes to do, although in a slightly different style and with
more flexibility than the way you state the issue above.  The
interesting question is what will happen with that document.
There are people who agree with it.  There are people who
disagree with it.  Sooner or later, that balance will need to be
resolved via a Last Call.   And the process by which the IESG
handles the Last Call request will be interesting in the extreme.

> Yes, the IESG could abuse its power in the future.  For
> example if it failed to charter work for one of the previous
> options in the presence of significant community support, then
> the IESG would be abusing its power.  If the IESG blocked such
> a document with discusses that challenged the fundamental
> premis of the document while there was community support then
> the IESG would be abusing its power.  If the IESG constructed
> unreasonable process blocks or unfairly enforced process
> issues against these documents then it would be abusing its
> power.  But if the IESG is going to have management
> responsibility, it needs the authority to recommend against
> things it believes are wastes of time.  Some times the
> community will disagree with those recommendations; so long as
> the IESG does not block the community that's entirely fine and
> will be a result of an open process.

We are in complete agreement here.  And I notice that you use
the term "recommend", which appears to me to be rather different
from the decision made in this particular case.

> I would like you to consider one thing with regard to the
> specific proposal.  We both seem to believe it is reasonable
> for the IESG to require community review.  That community
> review is going to require the support of the IPV6 and
> NSIS/QOS communities in order to build a rough consensus.  So
> far, I'm not hearing requests either from the IPV6 or QOS
> communities for the opportunity to review this proposal. If
> those communities don't want to support the proposal, it will
> ultimately go nowhere within the IETF.  Why should we be
> spending effort on the proposal without interest from the
> areas of the IETF that would ultimately review it? 

Again, and I would again refer you to the Internet Draft, I
believe we need an affirmative reason to reject a registration
request.  "No one cares about this option within the IETF" is a
good reason to not recommend the protocol, or put energy into
evaluating it, but it is not a sufficient reason to reject the
registration.   If we are going to start rejecting registrations
we need, IMO, either an alternative or enough of a technical
review to push back strongly on the protocol itself.   It is a
completely rational decision to decide to not do that work but,
again, unless we have a way to stop deployment of the protocol,
I think we have no alternative but to register it to protect
everyone else.  And, as I have said elsewhere, the more odious
the IESG and/or the community consider the protocol to be, the
more important it is that it be registered, somehow.

regards,
    john

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 30 Jun 2005 21:12:07 -0400

> "conflicts with work in the IETF"... or not.

Except that depending on context, "conflicts with work in the IETF" could 
be something that could be resolved through IETF review or participation in 
the already-ongoing work, or it could be something that cannot be 
reconciled.  The text you quoted doesn't prevent the IESG from 
distinguishing between these cases or suggesting that the author bring the 
document to the IETF for review; what it does do is prevent the IESG from 
spending time reviewing documents and finding reviewers for documents which 
haven't been through any part of the IETF process.

Note that I would consider it entirely reasonable for the IESG to say that 
something "conflicts with work in the IETF" on the grounds that its 
deployment would break the Internet, since preserving the stability of the 
Internet is a fundamental part of _all_ IETF work.

> control external behavior and refuse to comment substantively on

I don't think it is reasonable for the IETF to tell another SDO "That space 
belongs to us, so you shouldn't do any work there, but we don't feel like 
doing any either, so it should just be ignored".

I do think it is reasonable for the IETF (or the IESG) to tell another SDO 
"That space belongs to us, and we have active work there.  The work you 
propose conflicts such that we would not charter it within the IETF, and we 
don't believe you should do it either."  Whether such a statement can be 
expected to have the desired effect would depend a lot on the nature of the 
proposed work, the nature of the liason relationship involved, how much the 
other SDO already had invested in the proposal, etc.

And of course, I think it is reasonable (though unfortunate) for the IESG 
to say "We really think that should be reviewed within the IETF, but don't 
have the resources to do such a review right now.  We wish you would wait 
until we do, but will understand if your timeline doesn't allow that." 
This should be uncommon in practice, as I believe the IETF typically 
fast-tracks things when doing so allows us to meet another SDO's schedule 
on joint work.

> protocols inappropriate for any reason.

I don't think that is the case here.  The IESG is not blocking the 
registration; it is simply declining to allow it without community review 
and consensus.  Yes, the IESG has indicated that it does not believe the 
registration should be made at all, but if the community disagrees, then an 
attempt to register via the "IETF Consensus" path should succeed.

Now, I the situation might be somewhat different if "IESG Approval" were 
the only available choice.  But even in that case, I don't think there's a 
problem, because my interpretation of RFC2434 has always been that 
"Standards Action" and "IETF Consensus" are strictly higher bars, and that 
anything that passed them could be automatically assumed to also meet the 
lower bar of "IESG Approval".

> draft-klensin-iana-reg-policy-00.txt.

You must have mentioned this document 4 or 5 times in the last few days.
I really should get around to reading it already.  Apparently other people 
should, too, since I've seen no comments at all...

> more easily appealed.  I don't think either of us want to see

I'd hope that if someone wrote up such a document and took it to the 
appropriate working groups, that it would get some review.  I would hope 
that if there were support in those WG's to spend time on this, that the 
responsible AD(s) would not try to block that.

But, I also think the IESG's advice is at least partly accurate.  Reviewing 
something of this size and complexity in the IETF is likely to take quite 
some time.  It would likely result in changes, some incompatible, and some 
parts might be scrapped altogether.  I'm not in a position to evaluate the 
argument that it would probably not gain community consensus, and I'm 
beginning to believe the IESG should not have said that -- not because of 
whether it's true or not, and not because of the resulting controversy, but 
because of the chilling effect created.

> handles the Last Call request will be interesting in the extreme.

I don't expect it to be all that interesting.  But then, the handling of 
process-related things has been a bit controversial itself, lately.

-- Jeff

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Jul 2005 03:25:25 +0200

Dave,

I'm supposed to be on vacation so this will be brief, but I don't think
that your assertion about what "the community" has said is backed up
by postings from a sufficient number of people to be a community view.
Most people in the community haven't posted one way or the other. I
haven't counted, but in the recent discussions about the hop by hop
option, I've seen a number of messages agreeing with the IESG's
decision, contrasted with a large number of critical postings from just
a few people.

As I said in the plenary in Minneapolis, my goal is for the IESG to be
able to *steer*. Not to rule. Steering means finding the narrow line
between too far to the left and too far to the right. It also means
being decisive, and it means listening to the community as a whole,
not just to individuals who post a lot of mail.

We'll discuss this in plenary at the next IETF.

    Brian

Dave Crocker wrote:
> Over the last 3-4 years, the community has provided extensive and 
> sustained expression of a desire to have the IESG assert LESS 
> "responsibility" for the work that is done and to have the IESG serve as 
> a choke point less.
> 
> Initiatives come from the community, and the real work of the IETF is 
> done by working groups.
> 
> The job of the IESG is to facilitate those initiatives and that work and 
> to assess community rough consensus about the work.
> 
> The IESG can mentor working groups, so that they are more timely and 
> produce better quality output.  It also can impede timeliness and 
> progress, such as by asserting late-stage vetos by virtue of introducing 
> new and whimiscal requirements.
>

---

From: Robert Elz <[email-masked]>
Date: Fri, 01 Jul 2005 10:55:40 +0700

Date:        Fri, 01 Jul 2005 03:25:25 +0200
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | As I said in the plenary in Minneapolis, my goal is for the IESG to be
  | able to *steer*. Not to rule. Steering means finding the narrow line
  | between too far to the left and too far to the right.

Also remember that the IESG, including the "steering" existed long before
the IESG got to approve almost anything.   Steering relates to managing the
progress of the working groups, or that's where it came from.  The IESG
is intended to drive (or steer) the working groups so that overall progress
is made.

  | It also means
  | being decisive, and it means listening to the community as a whole,
  | not just to individuals who post a lot of mail.

That's true.   But when there is a diversity of opinion, you cannot
assume that everyone who says nothing is agreeing with you.   They're
just as likely agreeing with those opposed to you, but have nothing
new to add.   In general it is best to assume that the split of those
who say nothing is generally the same as those who do comment.  If
everyone (or almost everyone) who comments is in general agreement, it
is fair to assume that those who don't comment agree.   If there's a
bit debate among a group of people, the reasonable conclusion is that
the same debate would exist among everyone else.   If there's one or two
people opposed to many others, you can generally assume that most of those
who don't comment will agree with the majority who do.

  | We'll discuss this in plenary at the next IETF.

That's fine.   But do remember it is the mailing list(s) that make
the decisions, not the meetings.

Also remember that "no consensus" in an issue like this, really needs to
mean "no authority" - if you cannot get at least most of the community to
agree with the IESG position, then the IESG cannot just claim the
authority and say "there is no consensus that we should not have it".

kre

ps: while I am sure that you want to believe that you have general
community support, that isn't the way I see it - rather, most of the
support I've seen for the IESG position looks to be coming from current
or former IESG members, whereas the opposition looks to be from
everywhere, including former IESG/IAB members, and people who have
never been in a "management" role.