Subject: Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option

From: Robert Elz <[email-masked]>
Date: Fri, 24 Jun 2005 14:18:25 +0700

Date:        Wed, 22 Jun 2005 11:12:53 -0400
    From:        IESG <[email-masked]>
    Message-ID:  <[email-masked]>

  | The IESG declines Dr. Roberts's request for a hop-by-hop option for
  | QOS purposes.

I have no idea whether the option is actually any good or not, nor whether
it should be approved, so don't consider this a message in support of
the option.

However, the IESG's stated reasons for declining to register the option
are utter nonsense, and cannot be allowed to remain as a precedent for
the way the IETF and IESG does business.

  | The proposal includes significant changes to the
  | Internet architecture including a new TCP congestion control
  | algorithm, new requirements for IPsec security gateways and new
  | behavior for routers.

Whether any of that is a viable proposal or not is for others to
judge (not even the IESG I'd suggest), but it makes no difference
what the answer is to that question for the actual request that
was made.

  | Adopting the changes to the Internet
  | architecture contemplated by this proposal would require review and
  | consensus within the IETF; it would be inappropriate for another
  | standards organization to modify IETF protocols as contemplated by
  | this proposal.

Yes, that's true, but what is the relevance?

  | Within the NSIS working group, the IETF is already
  | actively working on solutions to QOS and to other problems identified
  | in this specification.

That's great, and also irrelevant.

  | We believe that these efforts will lead to a
  | preferable solution to the problems identified in this proposal.

Thats optimistic.   It is a little hard to believe in anything that's
both significant and new appearing from an IETF working group this days.
But that's also irrelevant.

  | Reviewing this proposal within the IETF as an alternative to the
  | ongoing work would be a multi-year endeavor.

Then don't do that.   That isn't what was requested, as best I can tell.

  | The IESG is pessimistic that this effort would ever achieve consensus.

That's probably a more realistic assessment of the chances of any
proposed working group doing anything significant.

  | So, the IESG
  | declines the assignment request and recommends against pursuing this
  | proposal within the IETF.

All that was requested (of the IANA) as far as I can see was the assignment
of an option code.    That implies nothing about whether or not anyone should
actually support the thing.   All it does is encourage interoperability by
avoiding collisions in the option number space.   That's why the IANA 
registries exist.   They're not there so the IETF can prevent anyone from
attempting anything without getting IETF approval first.

Legitimate reasons for refusing a request would be that there's already
an option code defined that does the same job, or that the specification of
the proposed option isn't clear enough to allow anyone to actually process
the thing correctly, or ... (others like that).

An illegitimate reason for refusing such a request is "we don't like the
use you're planning to make of the option".   All that does is encourage
people to ignore the IANA registry (and IESG and IETF) and define their
own option code, and later, present it as a "already implemented in
hundreds of products" fait accomplii (sp??) which isn't in anyone's best
interests.

I's encourage Dr Roberts to commence the appeal procedures set forth in
RFC2026 as soon as possible.   If the IESG don't either reverse their
decision, or produce legitimate reasons for rejecting it, then if the IAB
is doing its job even half properly, the IESG should get totally squashed
by this one.

kre

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

---

From: Thomas Narten <[email-masked]>
Date: Fri, 24 Jun 2005 13:08:25 -0400

> the way the IETF and IESG does business.

Let me add my perspective, even though I wasn't involved in the IESG
decision at all.

RFC 2780 says:

> 5.5 IPv6 Hop-by-Hop and Destination Option Fields
> 
>    Values for the IPv6 Hop-by-Hop Options and Destination Options fields
>    are allocated using an IESG Approval, IETF Consensus or Standards
>    Action processes.

(where those terms are defined in RFC2434.)

The clear intention of the above is that assignments for HBH code
points be conditioned on IETF review (and approval). That is, a
document that gets published as an Internet Draft, gets reviewed, and
then pops out as an RFC.

The "IESG Approval" case is a bit of an escape clause, allowing for
unusual/exceptional situations where getting an RFC published isn't
appropriate or would take too long. So I view that not as a "normal"
way of getting a code point, but one where there are "extenuating
circumstances". The clear intention is the way to get a HBH code point
is to publish an Internet Draft and bring it to the IETF for proper
review.

That was never done for this document. AFAIK, this document has never
been discussed in the IPv6 WG, for instance.  (Indeed, there is no
draft for it, AFAIK.)

The right thing to do is to have this document reviewed proper in the
IETF and then let the IETF decide what it wants to do with it.

IMO, it would have been completely inappropriate for the IESG to have
approved this code point assignment. Indeed, had they done so, I am
certain that a large number of folk would have immediately screamed
that the IESG had no right to do so (i.e., had exceed its authority,
etc.), and that it should have consulted with the IETF instead.

Thomas

---

From: John Leslie <[email-masked]>
Date: Fri, 24 Jun 2005 16:03:04 -0400

Thomas Narten <[email-masked]> wrote:
>... 

   Clear to current IESG members, perhaps; clear to the general public???

> is to publish an Internet Draft and bring it to the IETF for proper

   I would be happy to see it done that way.

   But I must have missed where in the IESG email it was suggested to
Dr. Roberts that he proceed this way.

> been discussed in the IPv6 WG, for instance.  (Indeed, there is no

   It is this sort of attitude -- that people with ideas are supposed to
"just know" the procedures which IESG members would like them to follow --
which leads to loss of respect for the IESG (and, IMHO, ends up making
their job more difficult).

   How difficult would it have been to have a secretary-level support
person explain this procedure to Dr. Roberts?

   Instead, we have our "leaders" publicly criticizing the idea, when the
problem is the process which wasn't followed.

> IETF and then let the IETF decide what it wants to do with it.

   Then why don't we do that?

> etc.), and that it should have consulted with the IETF instead.

   Perhaps folks just don't know who Dr. Roberts is?

   Hint: he's the fellow who first published the ARPAnet idea, and
convinced the Department of Defense to fund Bob Kahn's work.

   Even if you believe him a senile old fool (which he is NOT), he
deserves better than this.

--
John Leslie <[email-masked]>

---

From: Robert Elz <[email-masked]>
Date: Sat, 25 Jun 2005 04:03:11 +0700

Date:        Fri, 24 Jun 2005 13:08:25 -0400
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

  | The clear intention of the above is that assignments for HBH code
  | points be conditioned on IETF review (and approval).

I'd actually say it was more requiring that options be suitably documented.
If IETF approval was required, then only "standards action" would be
permitted.   "IETF consensus" permits informational RFCs, and "IESG
approval" actually permits no documentation at all.

  | The "IESG Approval" case is a bit of an escape clause, allowing for
  | unusual/exceptional situations where getting an RFC published isn't
  | appropriate or would take too long.

Or, just perhaps, where the documentation is already published, or
is being published, by another standards body.

Note that 2780 doesn't say "IESG approval in exceptional cases", and
in fact, actually lists "IESG approval" as the first of the methods
by which option code values can be allocated.   It doesn't look to me
to just be an escape clause, but one entirely appropriate way for
options to be allocated (especially given that 2434 suggests that for
IESG approval the IESG can request documentation, that hasn't been made
by the RFC process).

  | The right thing to do is to have this document reviewed proper in the
  | IETF and then let the IETF decide what it wants to do with it.

That's fine.   You'll note that I didn't say that the option should
have been approved.   What I said was that the way the IESG approached
the issue, rejecting the request because (to paraphrase) "we are also
doing QoS work, and we like our yet to be developed method better, and
we will do everything that we can to make sure that no other proposal
gets any kind of assistance", was not the way that the IESG should be
operating.

  | IMO, it would have been completely inappropriate for the IESG to have
  | approved this code point assignment. Indeed, had they done so, I am
  | certain that a large number of folk would have immediately screamed
  | that the IESG had no right to do so (i.e., had exceed its authority,
  | etc.), and that it should have consulted with the IETF instead.

I have no problem with that - a last call to seek comments from the
IETF on the request, based upon the existing (non I-D) doc, or even
a referral to the ipv6 working group, might have been appropriate
responses.   But that isn't what the IESG did.  What they didn't do
was consult with the IETF - consulting is just as important when you
say "no" as when you say "yes".

kre

---

From: Sam Hartman <[email-masked]>
Date: Fri, 24 Jun 2005 18:07:15 -0400

The following is my personal opinion.

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

    >> The "IESG Approval" case is a bit of an escape clause, allowing
    >> for unusual/exceptional situations where getting an RFC
    >> published isn't appropriate or would take too long. So I view
    >> that not as a "normal" way of getting a code point, but one
    >> where there are "extenuating circumstances". The clear
    >> intention is the way to get a HBH code point is to publish an
    >> Internet Draft and bring it to the IETF for proper review.

    John>    I would be happy to see it done that way.

    John>    But I must have missed where in the IESG email it was
    John> suggested to Dr. Roberts that he proceed this way.

We didn't.  We let him know that if he wants to move forward he would
need to move forward this way.  If he does submit an internet draft
I'm sure we will treat it in a fair manner.  That would probably mean
asking the IPV6 working group and the NSIS working group what they
think.

However, we did not ask him to go down that route.  We think we have a
good understanding of how the IETF would react to this proposal if it
were brought to the IETF for review.

What you seme to be saying is that you would be happy if we told
Dr. Roberts to ask for review knowing full well that such a review
would be long, complicated and would probably  end up in a rejection.
Why is it wrong for us to tell him up front that asking for review is
probably going to be a waste of time?

we never said that he could not bring the proposal to the IETF.  We
recommended against it.  But we were careful to distinguish what we
declined (his request) from what we recommended against (forward
progress on this proposal)

I guess if we had not let the world know we were recommending against
this proposal it might have given a false sense of impartiality.  But
the fact is that the IESG will be asked to form a technical opinion on
the merits of the proposal if it is reviewed in the IETF.  I see it as
a good thing that we gave a heads up about the prospect of a positive
review.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 24 Jun 2005 18:41:36 -0400

I'd like to understand the process through which Dr. Roberts' request
was reviewed.  The first reference I can find to Dr. Roberts' request is
in the 2005-04-14 minutes of the IESG
(https://datatracker.ietf.org/public/view_telechat_minute.cgi?
command=view_minute&id=318  see below).  According to the rejection
announcement, the IESG reviewed the submission and determined that
"Reviewing this proposal within the IETF as an alternative to the
ongoing work would be a multi-year endeavor. The IESG is pessimistic
that this effort would ever achieve consensus."  The minutes refer to
discussion of a "management issue".  Was the entire review conducted in
the meeting on 2005-04-14, or was there additional review conducted
prior to that meeting? How, exactly, did the IESG review the submission
and how did the IESG come to its conclusion?

- Ralph

=====

                  Minutes of the IESG Teleconferences 

        INTERNET ENGINEERING STEERING GROUP (IESG)
        Minutes of the April 14, 2005 IESG Teleconference
        
        Reported by: Amy Vezza, IETF Secretariat
        
        ATTENDEES
        ---------------------------------
        Brian Carpenter / IBM
        Michelle Cotton / ICANN (IANA)
        Leslie Daigle / VeriSign (IAB)
        Bill Fenner / AT&T
        Barbara Fuller / IETF Secretariat
        Ted Hardie / Qualcomm, Inc.
        Sam Hartman / MIT
        Scott Hollenbeck / VeriSign
        Russ Housley / Vigil Security, LLC
        David Kessens / Nokia
        Allison Mankin / Shinkuro, Inc.
        Dave Meyer / Cisco/University of Oregon (IAB Liaison)
        Jon Peterson / NeuStar, Inc.
        Joyce K. Reynolds / RFC Editor
        Barbara Roseman / ICANN (IANA)
        Mark Townsley / Cisco
        Amy Vezza / IETF Secretariat
        Margaret Wasserman / Nokia
        Bert Wijnen / Lucent
        Alex Zinin / Alcatel
        
        REGRETS
        ---------------------------------
        
        Dinara Suleymanova / IETF Secretariat
        
        MINUTES
        ---------------------------------
        
        [...]
        
        NEW:
        
        o Allison Mankin to craft IESG response to the Roberts (ipv6-parameter) Request 
        for Assignments.
        
        [...]
        
        7.2 IESG Handling of General Request for Assignments (Roberts)
        (ipv6-parameter) (Allison Mankin and Michelle Cotton)
        
        The management issue was discussed. The IESG has taken the token 
        to prepare an appropriate response for Dr. Roberts. 
        Action item: Allison Mankin to craft IESG response to the Roberts 
        (ipv6-parameter) Request for Assignments.

---

From: "Steve Silverman" <[email-masked]>
Date: Fri, 24 Jun 2005 19:11:28 -0400

At a recent meeting, Dr. Roberts said that this option had been
approved as a recommendation by an ITU Study Group.  He didn't
indicate which SG or what the rec. number would be.  He said he had an
ISP that wanted to deploy this function.
If all this is true, would it not be reasonable for IANA to assign a
code to an ITU approved option to avoid incompatible codepoint use?

If IANA doesn't support ITU work, this might be construed as a reason
to move the IANA function to an ITU Study Group or another
administrative body that might be neutral with respect to the various
standards bodies.

Dr. Roberts said he had submitted this work to the IETF but it hadn't
been assigned to a WG.  He is apparently unfamiliar with IETF
procedures.

Steve Silverman

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On
> Behalf Of Ralph
> Droms
> Sent: Friday, June 24, 2005 6:42 PM
> To: IESG
> Cc: [email-masked]; IETF Announcement list
> Subject: Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option
>
>
> This message was passed through
> [email-masked], which is a sublist of
> [email-masked]. Not all messages are passed. Decisions on
> what to pass are made solely by IETF_CENSORED ML
> Administrator ([email-masked]).
>

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sat, 25 Jun 2005 03:21:32 +0200

>administrative body that might be neutral with respect to the various

Dear Brian Carpenter, Michelle Cotton, Leslie Daigle, Bill Fenner, Barbara 
Fuller, Ted Hardie, Sam Hartman, Scott Hollenbeck, Russ Housley, David 
Kessens, Allison Mankin, Dave Meyer, Jon Peterson, Joyce K. Reynolds, 
Barbara Roseman, Mark Townsley, Amy Vezza, Margaret Wasserman, Bert Wijnen, 
Alex Zinin,

What is the IANA?
- is it the 35 649 341 chars concatenation of the results of the RFC IANA 
considerations parts plus the names and numbers ICANN files?
- is it the to be urgently distributed common parameters and reference 
repository for the needs of the Global Internet Community?

Networking by essence is to share parameters. Is this some want to rule a 
IANA registrar in their business field? The days of centralised IANA (and 
power) are over: network development means that every relational space of 
exchanges needs a common clearing house for its networking. We urgently 
need to understand what it means in term of IANA policy, organisation, 
architecture. The IANA must be distributed and its policy totally reviewed. 
Consistence with ISO 11179 insured....

When the very founder of the ARPANET is refused to register a parameter 
(whatever it is, whatever the purpose, whatever the reason) what are the 
chances of one of the 800 millions common users who will also to register 
manythings.

Under the current urgent need to address the questions above, did you not 
see this is not even forcing an ITU alt-IANA, this is forcing 
balkanisation, pulverisation?

If an idea is good you will not block it in denying it a parameter 
registration.
If an idea is bad you will create it support in denying it. You will let it 
die in treating it equal.
jfc

---

From: John C Klensin <[email-masked]>
Date: Fri, 24 Jun 2005 21:43:34 -0400

--On Friday, 24 June, 2005 18:07 -0400 Sam Hartman
<[email-masked]> wrote:

>     John>    But I must have missed where in the IESG email it
> was     John> suggested to Dr. Roberts that he proceed this
> way.
> 
> 
> We didn't.  We let him know that if he wants to move forward
> he would need to move forward this way.  If he does submit an
> internet draft I'm sure we will treat it in a fair manner.
> That would probably mean asking the IPV6 working group and the
> NSIS working group what they think.
> 
> However, we did not ask him to go down that route.  We think
> we have a good understanding of how the IETF would react to
> this proposal if it were brought to the IETF for review.
>... 

Sam, I think we are in danger of asking the wrong questions here
and, in the process, causing serious damage to the Internet (and
to the IETF, which is somewhat less of a concern).  The problem
has little or nothing to do with the specific technical merits
of the Roberts proposal.

Historically, we maintain registries of various protocol
parameters, not to endorse them, but to prevent conflicts in the
meaning/ interpretation of such things.  A protocol can be
dangerous or harmful to the Internet and hence something that
should not be recommended.   If such recommendations are
sensible, sensible people will follow them.  If they are not
sensible, or we don't do a good enough job of explaining the
problems or getting the word out, or some people are just not
sensible, those people will do what they like: until we can have
the protocol police arrest those who do things on the Internet
of which the IETF does not approve, there is no stopping them.   

All of that has to do with protocols, not parameter
registrations. The key purpose of a parameter registration or
allocation is simply to avoid conflicts between different
options/ approaches, whether individual ones of them are good
ideas or not.  Our registration models were generally based on
the assumption that, if someone was going to use a particular
protocol variation, the only questions were whether they used it
with a parameter that IANA assigned and registered or, if not,
whether they would make up their own or use someone else's
(which, in the long run, amounted to the same thing), creating a
degree of hazard that differed with the particular base protocol.

Now, if the IESG decides to direct IANA to attach notes to some
parameter registrations that say, more or less "the IESG thinks
there is IETF consensus that the  protocol that is bound to this
parameter emits a bad odor and is a Seriously Bad Idea and that
you shouldn't use it, please see RFC NNNN for details", I
personally think that would be a fine idea.  But it is hugely
different from saying "no registration unless we think your idea
is a good one".

In the old days, when IANA was asked to evaluate a registration
request, there were basically only two issues on which a
registration could (and would) be rejected or returned for
clarification:

	(1) the description of the protocol that goes with a
	parameter was insufficiently clear that a system
	receiving the parameter value would be able to figure
	out what it had gotten. 
	
	(2) we had developed enough scarcity in the particular
	parameter space that it was useful to ask questions
	about whether the requested value was really necessary
	or whether the need could be met in some other way.
	Again, "necessary" didn't really translate as "good",
	although I can remember cases --and people closer to the
	IANA can probably remember far more-- in which an effort
	was made to educate the applicant about why he, she, or
	they should do something else.

I've copied Joyce Reynolds explicitly on this note in the hope
that she will be able to comment on whether my recollection of
the historical patterns is correct.

With the changes in the community in the last decade, and with
Jon's death and IANA's necessarily assuming less of an
evaluation function, we've shifted much of that evaluation
function to the IESG or people appointed by it.  That seemed
sensible to me when the trend started and still does.  But the
community has generally not consented to changing the criteria
about registration: registration is about avoiding
interoperability problems, not about good or evil.  It was, and
remains, entirely reasonable to "bounce" a protocol parameter
specification on the grounds that one could figure out what it
meant and my recollection is that a number of parameter
applications were bounced for lack of clarity (including one or
two of mine).  But that doesn't seem to be at issue here.

And, for a number of protocol registries, the scarcity problem
is a real issue.  The IESG has, for example, directed IANA to be
much more aggressive about resisting public port registrations
than was the case 15 or 20 years ago.  But resisting public port
registrations doesn't prevent anyone from launching a new
protocol, they are just pushed out into user space.

However, if the IESG believes that it is necessary to resist
parameter registrations involving IPv6  --which, again,
historically, was the only basis for rejecting a registration
other than lack of clarity or redundancy-- I suggest that we are
in serious trouble.   Parameter space scarcity is a scaling
problem: we can slow the rate at which we run out entirely, but
we can't prevent running out.  So, if, at this stage of IPv6
deployment, the IESG believes that it needs to restrict
registrations to options that the IESG thinks are "good" (or
that the IETF concludes or will conclude are "good"), then I
suggest that we need a WG, on an emergency priority basis,
looking at how to make those parameter spaces a _lot_ bigger.  

But if, instead, we are simply binding allocation of protocol
parameters to the IESG's, or even the IETF's, notions of
goodness, I think we are going to get ourselves into a lot of
trouble, possibly to the point of making ourselves irrelevant
and encouraging chaos on the Internet.   I may misunderstand
your note, but it seems to me that the reasoning you describe
heads us in exactly that direction.

     john

---

From: Robert Elz <[email-masked]>
Date: Sat, 25 Jun 2005 15:22:41 +0700

Date:        Fri, 24 Jun 2005 18:07:15 -0400
    From:        Sam Hartman <[email-masked]>
    Message-ID:  <[email-masked]>

  | What you seme to be saying is that you would be happy if we told
  | Dr. Roberts to ask for review knowing full well that such a review
  | would be long, complicated and would probably  end up in a rejection.

I think you're confused.    There neither is, nor ever was any requirement
that the actual proposed use of the option be agreed as a "good thing"
by the IETF, of for the IETF to approve the techniques that are being
proposed by Dr Roberts' group.

All that the IETF needs to decide is whether or not it is reasonable to
assign a code point in the IPv6 options number space for their needs.

This is hardly something controversial, or that should take very long.
Nor is there any good reason for such a request to be rejected, as long
as there is an option code available (IPv6 isn't exactly swamped with
header options...) and the proposed use is documented enough to be
clear to anyone who sees the option how they should process it, if their
implementation feels inclined to participate.

Whether anyone would want to bother implementing the thing, beuyond the
group that is requesting it, is immaterial.   Allocating an option doesn't
require any implementations to support it, let alone to support the
infrastructure that the option is intended to enable.

Just ask the IPv6 working group if there's an option number available,
and if there's any particular reason thatthis particular option would
do harm to IPv6.   Assuming they answer "yes, all the option numbers
aren't currently allocated" and "no, we can just ignore this option if
we see it, or drop packets containing it", (whichever option variety was
requested - I forget) then there's no good reason to encourage them to
go and assign an option code for themselves, and by doing so end up
creasting possibly conflicting uses.

Refusing code point allocations, in any registry whatever, should be
a very rare event - and mostly done only for lack of adequate documentation
(somewhere, requiring an RFC is not necessary) or because of duplication.

kre

---

From: Bob Hinden <[email-masked]>
Date: Sat, 25 Jun 2005 10:25:24 -0700

Hi,

>creasting possibly conflicting uses.

There are IPv6 option types available, but this was a request for an IPv6 
hop-by-hop option.  The IPv6 hop-by-hop options (like all IPv4 options and 
one of the reasons that IPv4 options never had much use) have a significant 
performance impact for all routers that forward packets with hop-by-hop 
options in them.  I think it is quite reasonable to not assign any new ones 
without serious IETF discussion.  I also don't have any problem with the 
bar for new IPv6 hop-by-hop options to be set very high.

I belive the IESG did the right thing in this case as it was a request for 
an IPv6 hop-by-hop option.  I did a quick review of the link at the end of 
the IESG email (i.e., Additional Info) and think that what is proposed is 
very complex and proposes to change behavior in protocols other than 
IPv6.  I am certain it would have been a big mistake to approve the request 
without a lot of discussion.

Bob

p.s. I am starting to think that including hop-by-hop options in IPv6 was a 
mistake and we should think about deprecating them.   This would be a good 
topic for the IPv6 w.g. to discuss (i.e., not on the IETF list :-) )

---

From: Robert Elz <[email-masked]>
Date: Sun, 26 Jun 2005 03:12:50 +0700

Date:        Sat, 25 Jun 2005 10:25:24 -0700
    From:        Bob Hinden <[email-masked]>
    Message-ID:  <[email-masked]>

  | There are IPv6 option types available, but this was a request for an IPv6 
  | hop-by-hop option.

I had always assumed that the option space for HBH and Dest-Options was
the same.  Perhaps I'm wrong about that, but it doesn't really matter.

  | The IPv6 hop-by-hop options (like all IPv4 options and 
  | one of the reasons that IPv4 options never had much use) have a significant 
  | performance impact for all routers that forward packets with hop-by-hop 
  | options in them.

No, that's not quite correct.   The performance impact (in v6) is for
packets with the HBH header in them.   Whether the header is filled with
a dozen NOP (pad) options, or some other option, really makes little
difference.   I guess one could optimise for packets with one (or perhaps
some other small number) of particularly likely HBH headers in them,
should such things ever become common, but even a minor variation is
going to mean slowing down processing, with no new option codes beyond
what exist today.

  | I think it is quite reasonable to not assign any new ones 
  | without serious IETF discussion.

This does absolutely no good if your concern is internet performance.
Anyone can send packets with any options in them that they like -
publically defined or not, using IANA assigned code points or not.
The options already have the number space divided into "reject packet"
and "just ignore this option" for unknown options, and options all
have a defined overall format, so skipping unrecognised ones is always
possible (at a performance cost, of course).

What's really important with option assignments is whether or not
it is possible to implement the option, should one decide to, and do
it in a way that you can reasonably hope that all users of a particular
option code are using it the same way.   Doing that means making it
(relatively) easy to register code points, not difficult.

  | I also don't have any problem with the 
  | bar for new IPv6 hop-by-hop options to be set very high.

Same point, doing this achieves nothing.    On the other hand,
it is totally reasonable to advise people against using HBH,
and explain why.   But if they are going to, they will, regardless.

We have plenty of experience with all kinds of people "making up"
allocations for values in all kinds of data fields through the
internet, and then with everyone having to work around this later,
somehow guessing which values have been taken by various implementations,
and then avoiding assigning those (doing registry "catch up") later.
Can't we learn from that experience, and avoid repeating the same
mistakes, over and over?

  | I belive the IESG did the right thing in this case as it was a request for 
  | an IPv6 hop-by-hop option.

You mean to take the decision out of your hands, and make it on your
behalf, instead of initiating the "serious IETF discussion" you suggest
above?   Really?    Recall that they didn't say "you need to discuss
this in the IETF first" what they said was "go away, proposal is junk,
no option code for it".

  | I did a quick review of the link at the end of | the IESG email

I didn't.   Precisely because it doesn't matter to me what the
quality of the proposal is, nor whether an option code should
actually be allocated to this or not.   What matters is the way
the IESG decided to deal with it.

kre

---

From: "Nicholas Staff" <[email-masked]>
Date: Sat, 25 Jun 2005 14:15:32 -0700

I've been holding off comenting on this issue because in the context of this 
mailing list my knowledge of the policies of the IETF and IANA is basically 
zero.

The thing is I think Robert is right about the tone and assumed purpose of 
this rejection.  It reads like a letter from someone playing favoritism and 
trying to discourage a competitor.  When I read it I felt like the tone was 
that of a rejection based on predjudice and was basically saying "you're not 
invited to this party".  I mean I understand not liking the proposal, but to 
say "...the IETF is already actively working on solutions to QOS...We 
believe that these efforts will lead to a preferable solution..." - I mean 
that's basically saying "we don't have an answer yet, but we feel confident 
that when we come up with an answer it will be better than yours" - that's 
at best somewhat snobbish I would think and probably not an image anyone 
wants to project to the outside world (inside voice and outside voice).

Then there's the last line, which is my personal favorite "We encourage any 
interested parties to review the ongoing work within NSIS."  Talk about 
redirecting traffic...why not "we encourage all interested parties to view 
THIS proposal in conjunction with the ongoing work within NSIS to get a 
clearer understanding of why it has been rejected."

Maybe I misread the entire tone of the rejection, but even it's actions are 
saying "go away".  If the IETF were just one possibility in a sea of 
possibilities for this proposal then fine, tell someone to go away.  The 
thing is you own this so like it or not you have to play extra fair because 
this autocracy only works as a commonwealth.

Best regards,

Nick Staff

----- Original Message ----- 
From: "Robert Elz" <[email-masked]>
To: "Bob Hinden" <[email-masked]>
Cc: <[email-masked]>; "IESG" <[email-masked]>
Sent: Saturday, June 25, 2005 1:12 PM
Subject: Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option

  | There are IPv6 option types available, but this was a request for an 
IPv6
  | hop-by-hop option.

  | The IPv6 hop-by-hop options (like all IPv4 options and
  | one of the reasons that IPv4 options never had much use) have a 
significant
  | performance impact for all routers that forward packets with hop-by-hop
  | options in them.

  | I belive the IESG did the right thing in this case as it was a request 
for
  | an IPv6 hop-by-hop option.

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 26 Jun 2005 17:50:08 +0200

Ralph,

> and how did the IESG come to its conclusion?

This took many weeks, considerable email, and several informal
discussions before the IESG was sure of its position and able to
record a conclusion in the meeting you cite. Since there was no
IETF contribution (I-D or email on a public list) this process
was indeed invisible. I would have preferred a discussion based
around an IETF draft, but we didn't have one.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 26 Jun 2005 17:44:39 +0200

Vinton G. Cerf wrote:
> I want to clarify something here. IANA is not at fault. It submits requests like this to IESG to assure that there is consistency in
> standards work. In the past there have been attempts to circumvent standards work that is under way by directly submitting requests
> to IANA for assignment. I am not aware of the present status of any IETF-related work that might consume any or all of the bits in
> question in the IPv6 header. Larry has developed a reasonable method for dealing with flow control even if the payload of the IPv6
> packet is encrypted. there may be debates about the method chosen but that doesn't seem to be the issue here. To avoid conflicts,
> Larry is reasonably asking for an assignment. 

Vint, the technical implications are considerably more complex than
avoiding conflicts. That's the point, as Sam's message tried to
clarify. Just making an assignment without thorough IETF review
of those implications would have been highly irresponsible.

If Larry wants to proceed, an I-D explaining the proposal and
how it may or may not interact with other current work in the
IETF would be a good first step.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 26 Jun 2005 17:28:21 +0200

...
>    Then why don't we do that?

There has never been an Internet-Draft or other form of IETF
contribution that would have allowed the relevant IETF WGs to
have reviewed this proposal. The request went directly to IANA on
the basis of work done outside the IETF.

    Brian

---

From: Allison Mankin <[email-masked]>
Date: Sun, 26 Jun 2005 09:28:15 -0700

Hi, John,

There are two different IETF IANA registry goals (at least):

-  maintenance of protocol parameters by the IANA for
   keeping the namespace free of conflict

-  policy for the extension of an IETF protocol, which
   is expressed by the rules governing the
   issuing of new codepoints for particular elements
   in that protocol.

In the message the IESG sent about Roberts' request,
we pointed out that the IPv6 Hop by Hop option extensibility 
is governed by a BCP, RFC 2780, which requires an IETF document
(standards track or other), or in a fallback, IESG review.
This is the action the IESG has taken.  

Your message about the the registries being largely for prevention of
conflicts and so on is true for some registries, but for many others
there's an extension policy in place too.

For many protocols, there's an RFC that states a requirements for
some or all the codepoints for an IETF docoument before IANA allocations.
You can see these requirements in the IANA pages now.  These
requirements reflect views by the developers that the protocol needed
engineered coherency, an IETF review process that would ensure architectural
considerations when the extensions are made.

(The IETF is here for engineering the protocols, after all).

John wrote:
> meaning/ interpretation of such things.  [snip...]

Note there are hundreds of registries!  One summary does not fit all.
Also, endorse is a very loaded word.  They express RFC 2434 /
BCP 26 policies.  

Allison

---

From: Ralph Droms <[email-masked]>
Date: Sun, 26 Jun 2005 12:39:36 -0400

Brian...

>     Brian

I don't understand the cause-and-effect: why would the lack of an IETF
contribution lead to an invisible process?

Dr. Roberts' original request was apparently received by IANA on
2005-03-25 and forwarded by IANA to the IESG on 2005-04-07.  Did the
IESG reach its conclusions about the request during its 2005-04-14
teleconference or at a later time?  It may be that the IESG minutes
aren't clear... 

- Ralph

---

From: Allison Mankin <[email-masked]>
Date: Sun, 26 Jun 2005 10:22:03 -0700

Ralph,

Under RFC 2780, IPv6 hop-by-hop option numbers are granted
either with an approved IETF document, or an IESG review.

IANA made the request to IESG under the last option in
RFC 2780, and the IESG did its reviewing within the IESG.
We followed the BCP process.  Note that we do not even
have clear permission to provide the document we reviewed
to the IETF.  IANA requests from other standards bodies
where there is not an i-d do not presume an available 
document.

There were several cross-area questions to the review:

  - IPSec, transport and reservation protocol technical review.
  - Review of past similar cases.
  - Implications of  the TIA standard published from same 
    Roberts draft. TIA does not currently "borrow" a codepoint, 
    but we needed to track this down.
  - Contextualization of this request to our very recent 
    discussions (May 2) with ITU about protocol extensions and 
    codepoints.

These took a bit of time.

Are you trying to construct a timeline from the minutes?
I'm afraid the IESG minutes are made from a tool-form focussed
on the documents and WG charters, and tend to have limited 
free-form information, something that really can only change if
we add a person like the IAB has in Rich Draves.

Allison

---

From: "Dr. Lawrence G. Roberts" <[email-masked]>
Date: Sat, 25 Jun 2005 12:30:44 -0700

Steve,
Thank you for your thoughts. I am not sure about the next step, but I can 
clarify some of the points that were unclear.
British Telecom submitted it to the ITU SG12 in January and we had 
unanimous approval to be included as a concept for QoS in Y-1221. Then BT 
submitted it to SG13 as a detailed proposal of a signaling protocol and it 
again had unanimous approval to go forward as the basis of a recommendation.
I submitted the IPv6 part to the TIA several years ago and in May the ITU 
version (with IPv4 and IPv6) was approved by the TIA and sent out for final 
ballot.

As to submitting a draft to the IETF, I never did since the most critical 
need was in satellites which will not work with IPv6 due to encryption (no 
spoofing possible) without this protocol. The TIA has historically worked 
on satellite protocol issues. The TIA however, did submit an earlier draft 
to the IETF as a coordination effort and it was assigned to the satellite 
group. No action has been heard of from them.

  The TIA ballot closes Tuesday so this action is perhaps at the worst 
possible time since the TIA members will see the announcement and I have 
virtually no time to respond and explain any possibility of rectifying the 
IETF action. To rectify it I must notify all TIA members of an appeal or 
other action this weekend. Otherwise it will cause the TIA to consider how 
they can proceed to provide support for IPv6 over satellites in the face of 
IETF refusal to assign a code so that they can operate IPv6 without 
conflict. This is of great importance to DoD, who have been sponsoring this 
work so that the next generation of satellites can be completed and 
launched and future field operations can be efficient and secured.
I need help as to any process that can mitigate this major conflict with 
the TIA/ITU and the IETF and I need to act now. Please send your thoughts,
Larry

---

From: "Vinton G. Cerf" <[email-masked]>
Date: Sat, 25 Jun 2005 15:42:53 -0400

Vint

Vinton Cerf, SVP Technology Strategy, MCI
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
+1 703 886 1690, +1 703 886 0047 fax
[email-masked] 

  _____  

From: Dr. Lawrence G. Roberts [mailto:[email-masked]] 
Sent: Saturday, June 25, 2005 3:31 PM
To: Steve Silverman; Ralph Droms; IESG; Vinton G. Cerf
Cc: [email-masked]; IETF Announcement list
Subject: RE: IANA Action: Assignment of an IPV6 Hop-by-hop Option

Steve,
Thank you for your thoughts. I am not sure about the next step, but I can clarify some of the points that were unclear. 
British Telecom submitted it to the ITU SG12 in January and we had unanimous approval to be included as a concept for QoS in Y-1221.
Then BT submitted it to SG13 as a detailed proposal of a signaling protocol and it again had unanimous approval to go forward as the
basis of a recommendation. 
I submitted the IPv6 part to the TIA several years ago and in May the ITU version (with IPv4 and IPv6) was approved by the TIA and
sent out for final ballot. 

As to submitting a draft to the IETF, I never did since the most critical need was in satellites which will not work with IPv6 due
to encryption (no spoofing possible) without this protocol. The TIA has historically worked on satellite protocol issues. The TIA
however, did submit an earlier draft to the IETF as a coordination effort and it was assigned to the satellite group. No action has
been heard of from them.

 The TIA ballot closes Tuesday so this action is perhaps at the worst possible time since the TIA members will see the announcement
and I have virtually no time to respond and explain any possibility of rectifying the IETF action. To rectify it I must notify all
TIA members of an appeal or other action this weekend. Otherwise it will cause the TIA to consider how they can proceed to provide
support for IPv6 over satellites in the face of IETF refusal to assign a code so that they can operate IPv6 without conflict. This
is of great importance to DoD, who have been sponsoring this work so that the next generation of satellites can be completed and
launched and future field operations can be efficient and secured. 
I need help as to any process that can mitigate this major conflict with the TIA/ITU and the IETF and I need to act now. Please send
your thoughts,
Larry

Steve Silverman

> [  <mailto:[email-masked]> mailto:[email-masked]]On
> Behalf Of Ralph
> Droms

---

From: Dave Crocker <[email-masked]>
Date: Mon, 27 Jun 2005 07:58:28 -0700

Vinton G. Cerf wrote:
> I want to clarify something here. IANA is not at fault. It submits 
> requests like this to IESG to assure that there is consistency in 
> standards work. In the past there have been attempts to circumvent 
> standards work that is under way by directly submitting requests to IANA 
> for assignment. I am not aware of the present status of any IETF-related 
> work that might consume any or all of the bits in question in the IPv6 
> header. Larry has developed a reasonable method ...

"Fault" is a strong word.

Once upon a time, IANA had enough independence of the IAB/IESG to be able to 
go against its wishes.  It did this judiciously, but it provided an important 
source of counter-balance to ensure a better degree of open exchange. Although 
the staff of IANA and its relationship to the IETF have changed, it's worth 
considering the publication veto authority that IANA has given to the IESG.

You make two points about Larry's request.  One is about the lack of related 
work in the IETF and the other is that his own work is reasonable.  As I 
understand Robert Elze's point -- with which I agree thoroughly -- the latter 
point is very nearly irrelevant, to this discussion.

What matters is the former point about lack of conflict with existing work, 
along with the possible concerns of consumption of scarce assignment space, 
and clarity of his specification.  As I understand it, neither of these is an 
issue for this situation.

In other words, the primary role of registration is managing the assignment 
space, not quality control of particular proposals.

So, back to IANA:

The history has been that IANA "checks with" the IETF, via the IESG, rather 
than gives a veto to it.

If the IESG comes back with a response that does not match the criteria it is 
supposed to comment within, then I suggest that IANA should reject the assessment.

-- 
 
   d/

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Jun 2005 17:00:22 +0200

Vint,

Vinton G. Cerf wrote:
> packet is encrypted. there may be debates about the method chosen

The debate (except that since the work hadn't been brought to the IETF,
the debate hasn't happened) is whether the proposed mechanism will interfere
with existing or other proposed mechanisms. It isn't about the option number
in itself (apart from the normal need for careful stewardship of all finite
numbering spaces).

    Brian

>    but that doesn't seem to be the issue here. To avoid conflicts,
> ------------------------------------------------------------------------
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Jun 2005 17:10:53 +0200

Ralph,

I'm not sure I understand your question. This is the IETF so
we take decisions by on line deliberation inside the IESG
just as much as any WG does, and the minutes or IESG announcements
are the public record. And this decision, and the formulation
of the response to IANA and the announcement, took a number
of weeks. We agreed apart from final wordsmithing in the May 26
meeting (agenda item 6.2).

     Brian

---

From: Barbara Roseman <[email-masked]>
Date: Mon, 27 Jun 2005 09:26:46 -0700

All,

To address some misunderstandings of IANA's role in this action, Dr. 
Roberts requested a hop-by-hop option number from section 5b in the 
following registry: http://www.iana.org/assignments/ipv6-parameters. 
Currently, the registration rule for this particular registry is IESG 
Approval, described in RFC 2780. Not all IANA registries require IESG 
approval for parameter assignment.

IANA forwarded the request to the IESG for review as required by the RFC, 
and then informed Dr. Roberts of the decision. The notification is the 
"IANA Action" referenced in the subject line. Per the RFC, IANA did not 
have a decision-making role in this request.

Regards,

-Barbara
Barbara Roseman
Operations Manager, IANA
[email-masked]

At 07:58 AM 6/27/2005 -0700, Dave Crocker wrote:

>Once upon a time, IANA had enough independence of the IAB/IESG to be able 
>to go against its wishes.  It did this judiciously, but it provided an 
>important source of counter-balance to ensure a better degree of open 
>exchange. Although the staff of IANA and its relationship to the IETF have 
>changed, it's worth considering the publication veto authority that IANA 
>has given to the IESG.
>
>You make two points about Larry's request.  One is about the lack of 
>related work in the IETF and the other is that his own work is 
>reasonable.  As I understand Robert Elze's point -- with which I agree 
>thoroughly -- the latter point is very nearly irrelevant, to this discussion.
>
>What matters is the former point about lack of conflict with existing 
>work, along with the possible concerns of consumption of scarce assignment 
>space, and clarity of his specification.  As I understand it, neither of 
>these is an issue for this situation.
>
>In other words, the primary role of registration is managing the 
>assignment space, not quality control of particular proposals.
>
>So, back to IANA:
>
>The history has been that IANA "checks with" the IETF, via the IESG, 
>rather than gives a veto to it.
>
>If the IESG comes back with a response that does not match the criteria it 
>is supposed to comment within, then I suggest that IANA should reject the 
>assessment.
>
>
>--
>   d/
>
>  Dave Crocker

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 27 Jun 2005 18:50:55 +0200

>meeting (agenda item 6.2).

Dear Brian,
what seems odd, is that during all these weeks Dr. Roberts has not been 
informed and able to come back with a definiton like "experimental private 
code points 0 to F" and document through a Draft the need to have the 
possibility of experimenting innovation?
jfc

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Jun 2005 00:11:10 +0200

Dave Crocker wrote:
>> standards work that is under way by directly submitting requests to 
>> IANA for assignment. I am not aware of the present status of any 
>> IETF-related work that might consume any or all of the bits in 
>> question in the IPv6 header. Larry has developed a reasonable method ...
> 
> 
> Once upon a time, IANA had enough independence of the IAB/IESG to be 
> able to go against its wishes.  It did this judiciously, but it provided 
> an important source of counter-balance to ensure a better degree of open 
> exchange. Although the staff of IANA and its relationship to the IETF 
> have changed, it's worth considering the publication veto authority that 
> IANA has given to the IESG.
> 
> work,

Please read again what the IESG actually wrote.

  along with the possible concerns of consumption of scarce
> assignment space, 

All numbering spaces deserve careful stewardship.

and clarity of his specification.  As I understand it,
> neither of these is an issue for this situation.
> 

That is the role of the act of registration, but the act of registration
does not occur in a vacuum. Registering a value for a particular
purpose enables that purpose, and for some critical registration
spaces we therefore have a documenttaion and approval requirement.
This is one of those spaces.

> rather than gives a veto to it.

That history changed in 2000. See RFC 2860.

> 
> If the IESG comes back with a response that does not match the criteria 
> it is supposed to comment within, then I suggest that IANA should reject 
> the assessment.

In this case, they can't. See RFC 2780 (BCP 37).

   Brian

    Brian

---

From: John C Klensin <[email-masked]>
Date: Mon, 27 Jun 2005 18:31:15 -0400

--On Monday, 27 June, 2005 17:00 +0200 Brian E Carpenter
<[email-masked]> wrote:

> in itself (apart from the normal need for careful stewardship
> of all finite numbering spaces).

But, Brian, that is not, IMO, a proper way to frame the question
as I, and a number of people going back to kre's initial note,
have been trying to suggest.   My impression from the above is
that we just have not been communicating: IESG appears to be
focused on one concern and most of the comments on the list on
anohter.  In the hope that we can get close enough to be
discussing the same topic, let me try again.

There are two, almost completely separate, issues here:

	(1) The quality and utility of the proposed mechanism
	and where it falls on a scale that runs from "greatest
	idea in computer networking ever" to "the connection of
	a single device supporting this mechanism to the public
	Internet will cause an immediate meltdown after which no
	traffic will flow again, ever".
	
	(2) Whether or not it an option number should be
	assigned to it.

Now, what you say above is that the debate is, or should be,
about the mechanism and how it relates to other work.  That is a
really important question or group of questions and the IESG
would be, IMO, negligent in its responsibilities if it did not
try to get an answer to it.  The only objection I've seen on the
list to the IESG's intervening on that matter --although I have
seen it several times and quite clearly-- is the view that the
IESG should not be taking a position, presumably on behalf of
the IETF, on the subject of protocol quality and interactions
without public consultation with the relevant WG(s) and the
community.  In addition, there have been some opinions expressed
about steps the IESG should have taken or should take now,
including sending formal liaison statements to ITU-T SG13
explaining that the nature of this mechanism is such that they
should not approve it without asking for, and getting, IETF
review and comments.

But all of that is part of the first question above.  Its only
interaction with the second question is that if, for example,
the IESG were to send such a liaison note off to SG13, or tell
the applicant that they needed to make a good-faith effort to
get together with the relevant WGs to see if the issues could be
sorted out, it would be reasonable to defer (but not reject) the
registration/ option number request until there was some
conclusion from those processes.   Obviously, if the proponents
can be persuaded to drop this idea, or to modify it sufficiently
that the IESG no longer considers it problematic, the landscape
would change.

However, what I, and at least some others, are concerned about
is the second question.   The appearance of a number in a
seven-bit option field that we've heard at least one expert
claim is sufficiently unimportant that maybe the field should be
abolished is not going to cause a serious problem for the
Internet, even if the mechanism it identifies, if used, would
cause serious, immediate, and irreversible problems.   Unless
the IESG has some mechanism for preventing the mechanism from
being deployed, it is arguably better to assign an option code
than to no do so.  Indeed, the more hostile, incompatible, and
dangerous the mechanism is seen as being, the more important it
is that it get an option code if there is a reasonably chance
that it will be deployed.

It seems to us that the IESG has confused "protocol quality"
(the first question) with "registration appropriateness" (the
second) and, in the process, gotten to the wrong answer and,
worse, done so without adequate community consultation.  And
_that_, and not the protocol quality issues themselves are what
we think the debate is about.

In an attempt to sharpen the focus on the second set of issues,
I've been working intensely over the last couple of days with a
couple of collaborators to frame an Internet Draft that would
clarify the evaluation processes of IANA registries for which
IANA depends on the IETF for direction.  It does not change any
of the category types in RFC 2434, nor does it change the review
processes and required levels of signoff in RFC 2780 and other
documents.  But it does clarify the generic criteria to be used
in making those evaluations and the separation between the above
two questions.

The first draft of the document was submitted for posting about
90 minutes ago, under the name
draft-klensin-iana-reg-policy-00.txt.  We hope it will prove
helpful to the community and to the IESG in optimizing
registration request evaluation to meet the needs of the
Internet as it is, rather than some Internet in which IETF
disapproval of an idea causes that idea to disappear.

regards,
     john

---

From: Robert Elz <[email-masked]>
Date: Tue, 28 Jun 2005 10:34:46 +0700

Date:        Mon, 27 Jun 2005 17:00:22 +0200
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | The debate (except that since the work hadn't been brought to the IETF,
  | the debate hasn't happened)

Except that it has been reported that the work was given to the IETF
(via an IETF WG) but the debate still didn't happen...

  | is whether the proposed mechanism will interfere
  | with existing or other proposed mechanisms.

This is totally irrelevant.   We're talking about an option.   Options,
by their very nature are optional.   If use of an option interferes
with some other processing that you require, then you simply don't use
the option.

How that that concept possibly be confusing?

  | It isn't about the option number in itself

Of course not, since, once given approval to do so, IANA would
actually be picking the number to be assigned, not the IESG, IETF,
or anyone else (in this particular case, sometimes for some good reason
IANA is instructed to register a particular number - that isn't what
is happening here).

  | (apart from the normal need for careful stewardship of all finite
  | numbering spaces).

Not relevant here - this particular numbering space is essentially
unused, and there's no particular reason to assume that is going
to change any time soon.    What's more, if it does, there's no reason
the number space needs to remain finite - if it ever looked likely to
(even potentially) be exhausted, developing a backwards compatible
extension mechanism would be trivial.   There's no question at all that
it can be done - the only questions are whether it needs to be (whether
the number space has any chance of being exhausted) an then which of
several possible extension methods would be best to choose.

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 28 Jun 2005 10:40:45 +0700

Date:        Mon, 27 Jun 2005 09:26:46 -0700
    From:        Barbara Roseman <[email-masked]>
    Message-ID:  <[email-masked]>

  | To address some misunderstandings of IANA's role in this action, [...]

I hadn't actually noted any.   As best I can recall, there neither has
been, nor should be, any criticism of the IANA here.

Dave suggested that perhaps IANA should just ignore the IESG's response
as being patently absurd (which it was) and assign an option code anyway.

I don't think I'd go quite that far - and I don't think many others would.
That would put IANA in an invidious position, that I don't think anyone
really wants to lumber it with, and while the vast majority of the
community might agree with an action like that in this particular case,
the next time IANA were to decide to ignore advice, the response might
not be the same.   So, I believe that IANA did, and continues to do,
everything correctly in this particular case.

The IESG, and its actions, is quite a different issue however.

kre

---

From: Scott W Brim <[email-masked]>
Date: Tue, 28 Jun 2005 12:15:33 +0800

> again had unanimous approval to go forward as the basis of a recommendation.

Larry please be straightforward.  Just because people allowed work to
go forward in each case does not mean there was unanimous approval.
In SG12 the proposed text was objected to and sent back.  There was
approval to include the "concept" as you say, but only if the text is
improved.  In SG13 there was considerable debate, and at the end the
group *allowed* exploration of the topic through development through a
new draft recommendation.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 28 Jun 2005 08:39:01 -0400

Brian - I think part of my difficulty in understanding what has
transpired is that the process was truly "invisible" and what little
written record exists is misleading.  I now infer that the initial entry
in the minutes of the IESG meeting of 2005-04-14 records that Allison
took responsibility for managing the process to reach a decision within
the IESG and for writing a response, and that the IESG then had a
discussion and approved the final response on 2005-05-26.

I understand that this process was an IESG decision and much of the
discussion took place on line.  But there appears to be no other record
about the decision than a few terse entries in the IESG minutes.
Following up on your comparison with IETF WGs, WG debates and decisions
formally take place on a public mailing list, so there is a record of
the process through which the decision was made.  In the case of this
IESG decision, the only information I have about the decision is the
announcement of the decision.

The problem for me, then, is that I was surprised by the IESG decision
and am trying to understand how the IESG reached its decision.  Now I
understand that the IESG deliberated for six weeks, from which I infer
there was consideration of both technical and procedural issues arising
from the initial request.

- Ralph

---

From: "Dr. Lawrence G. Roberts" <[email-masked]>
Date: Tue, 28 Jun 2005 04:43:13 -0700

Scott,
The discussion in SG12 was where the work should be done. The concept was 
accepted but, being a QoS group, the details were left for SG13. The 
submission to SG 13 was slightly improved, but how much was from the 
discussion I am not clear about. But thats the function of such meetings.
I listened to all the "discussion" in SG13 and it was all clarification, 
not negative arguments, even from your company.The final vote was unanimous 
to proceed to a recommendation with the submission as the basis. Your words 
try to put this in a different light, but in fact there was total agreement.
I don't see how this is misleading.
Larry

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 28 Jun 2005 10:23:47 -0400

On Tue, 2005-06-28 at 00:15, Scott W Brim wrote:
> In SG13 there was considerable debate, and at the end the

assuming, for sake of argument, that the general proposal makes
sense[1], it sounds like the details are still very much up in the air;
assigning a "final" IPv6 option codepoint might actually be
counterproductive (as early behavior might be cast in code, concrete, or
silicon and forever burden future implentations).

The current v6 spec, however, doesn't give them much room to maneuver
here.  
An IPv6 option codepoint reserved for (topologically) local experiments
would make sense (given the nature of the proposal, it is inherently
"local" to a connected set of routers supporting it).

						- Bill

[1] and only for sake of argument...

---

From: Ralph Droms <[email-masked]>
Date: Tue, 28 Jun 2005 10:50:46 -0400

Bill...

> silicon and forever burden future implentations).

I think I have a fundamental disagreement with you at this point - the
assignment of the codepoint can (and should) be separated from the
acceptance of the specification as a standard.  IANA could certainly
assign the codepoint now, independent of whether the specification is
finished.  At the time the specification is accepted as a standard, the
assignment could be updated with a reference to the specifying document.

I don't think there is any notion that assignment of a codepoint implies
that interpretation of the codepoint and implementation of any mechanism
associated with the codepoint is required by any network element that
otherwise implements IPv6.  The acceptance as a standard would provide
the impetus to implement and deploy devices that implement the
codepoint.

- Ralph

---

From: Robert Elz <[email-masked]>
Date: Tue, 28 Jun 2005 21:59:34 +0700

Date:        Tue, 28 Jun 2005 10:23:47 -0400
    From:        Bill Sommerfeld <[email-masked]>
    Message-ID:  <[email-masked]>

  | assigning a "final" IPv6 option codepoint might actually be
  | counterproductive (as early behavior might be cast in code, concrete, or
  | silicon and forever burden future implentations).

>From what I gather, I think they intend to put the code for the
option into satellites, then launch them into orbit.   Planned
upates to this probably aren't all that likely.   If the option
turns out to be a dud, future implementations will just ignore it,
treat it as any other unknown option.   Code has to handle that
already, or anyone sending a bogus (or carefully planned) packet
would be able to do all kinds of harm.

The only potential cost here is the loss of an option code value,
until such time as this option is certified extinct (assuming that
it fails of course, if it succeeds, then the option would be
in active use, and no-one would want to reclaim it).

kre

---

From: Eliot Lear <[email-masked]>
Date: Tue, 28 Jun 2005 20:13:20 +0200

Rob,

> with some other processing that you require, then you simply don't use

Let's look at an analogy that worked just as you suggest: the assignment 
of 10/8 172.16/16 and 192.168/16 in RFC 1597.  Jon Postel's decision 
absent community review (and it was absent) had a profound impact on the 
Internet architecture.  Now we can argue till the cows come home as to 
whether that impact was good or bad [I really am over it! ;-], people 
will agree that we live with the results today and will continue to do 
so for years to come.  I claimed at the time and still believe that 
Jon's actions were reckless and the IAB was wrong to not at least review 
the allocation request.

Your argument that "it's just an option" doesn't wash with me not so 
much because intervening devices will have to ignore it but quite the 
opposite.  What happens if intervening devices implement it?  Had nobody 
made use of Network 10 the debates wouldn't rage on till this day.  If 
people make use of Dr. Roberts' work where it provides some marginal 
value to some subset of the community but at the expense of the rest of 
us, what do we do then to repair the damage?

> in active use, and no-one would want to reclaim it).

I would disagree for the same reasons.  I care more about what happens 
if the thing gets used and causes a bad interaction.  I don't see us 
getting into a situation of having to implement the equivalent of the 
telnet EXOPL given that Bob is talking about deprecating hop-by-hop 
altogether.

In this case, I can't say whether or not there will be bad interactions, 
but clearly the IESG is very concerned.

Eliot

---

From: John C Klensin <[email-masked]>
Date: Tue, 28 Jun 2005 15:03:33 -0400

Eliot,

There are at least two things that are wrong with the model you 
describe below,...

	(1) The assignment of address space, and the whole
	notion of private networks with specialized space, are
	not "just options" to a protocol, regardless of whatever
	else they may be or may have been.
	
	(2) RFC 1597 was fairly extensively discussed within the
	IESG and, if I recall, on the IETF list.  Its
	substantially equivalent successor, RFC 1918, was Last
	Called in the IETF and approved as a BCP document.

Not exactly protocol options that can be ignored (or the packets 
or messages disposed of) if one doesn't want to utilize them.

Even the part you don't want to reopen (and I don't either) is 
not a consequence of the address allocation, it is the result of 
a _recommendation_ (real or imagined) by the IETF community (and 
the RIRs) that private address space be used in certain 
circumstances.  So, while I disagree that a decision to allocate 
address space in a particular way is similar to allocating an 
option number, the decision that needed careful community review 
and appropriate recommendations was the protocol --and, in the 
case you cite-- the idea of private address space.   Without the 
protocol notions, the space allocations would have had little 
effect.

      john

--On Tuesday, June 28, 2005 20:13 +0200 Eliot Lear 
<[email-masked]> wrote:

>> This is totally irrelevant.   We're talking about an option.
>> Options, by their very nature are optional.   If use of an
>> option interferes with some other processing that you
>> require, then you simply don't use the option.
>
> Let's look at an analogy that worked just as you suggest: the
> assignment of 10/8 172.16/16 and 192.168/16 in RFC 1597.  Jon
> Postel's decision absent community review (and it was absent)
> had a profound impact on the Internet architecture.  Now we
> can argue till the cows come home as to whether that impact
> was good or bad [I really am over it! ;-], people will agree
> that we live with the results today and will continue to do so
> for years to come.  I claimed at the time and still believe
> that Jon's actions were reckless and the IAB was wrong to not
> at least review the allocation request.
>
> Your argument that "it's just an option" doesn't wash with me
> not so much because intervening devices will have to ignore it
> but quite the opposite.  What happens if intervening devices
> implement it?  Had nobody made use of Network 10 the debates
> wouldn't rage on till this day.  If people make use of Dr.
> Roberts' work where it provides some marginal value to some
> subset of the community but at the expense of the rest of us,
> what do we do then to repair the damage?
>
>> The only potential cost here is the loss of an option code
>> value, until such time as this option is certified extinct
>> (assuming that it fails of course, if it succeeds, then the
>> option would be in active use, and no-one would want to
>> reclaim it).
>
> I would disagree for the same reasons.  I care more about what
> happens if the thing gets used and causes a bad interaction.
> I don't see us getting into a situation of having to implement
> the equivalent of the telnet EXOPL given that Bob is talking
> about deprecating hop-by-hop altogether.
>
> In this case, I can't say whether or not there will be bad
> interactions, but clearly the IESG is very concerned.
>
> Eliot
>

---

From: Robert Elz <[email-masked]>
Date: Wed, 29 Jun 2005 02:47:14 +0700

Date:        Tue, 28 Jun 2005 20:13:20 +0200
    From:        Eliot Lear <[email-masked]>
    Message-ID:  <[email-masked]>

  | Let's look at an analogy that worked just as you suggest: the assignment 
  | of 10/8 172.16/16 and 192.168/16 in RFC 1597.

They'e not options.   There's no question but that different parameters
(different parameter kinds) should be (able to be) treated differently.

  | Jon Postel's decision absent community review (and it was absent)

I certainly recall no discussion about the values assigned, but I do
recall plenty of discussion about the need to assign address space for
disconnected sites (which was the intention of those) to avoid everyone
using 192.9.200/24 (or any other random number they assigned themselves,
I know that the first IP number I used was 55/8 - seemed like a good choice
to me at the time!)   Whether that discussion amounted to consensus or not
I wouldn't like to say after all of this time, but it certainly occurred.

  | had a profound impact on the Internet architecture.

It probbaly did, it has (by accident, rather than design) kept the
net operating.   Withough that (and NAT really) the internet would
be dead (replaced by something else, or perhaps, nothing else).
In the early days, it certainly actied as intended, many disconnected
sites used those numbers rather than self-selected values.

  | What happens if intervening devices implement it?

And, I presume you mean, people actually send packets containing the option.
Then, either it does useful things (for someone), or it does not.   In the
former case, the option remains, and whether you, or I, like the
effects produced, someone clearly would have to.  And if they're getting
a benefit, they are going to do that, whether blessed or not, registered
or not (just consider the amount of rewriting the v4 TOS byte that happened,
long before anyone considered blessing that practice)  If it doesn't work,
or no-one likes it, then it gets disabled (the vendor who added it
gets pressure to at least make processing the option optional, and it
is disabled).

While I'd sure like the net to return to a place where it can be carefully
architected to meet good standards of purity and virtue, those days are
long gone - there are all kinds of evil things happening out there, many
of them not documented anywhere.

Much better in my opinion to at least have some idea what is happening,
so we can find ways to work around any badness that appears, than to
be faced with unknown mystery that is simply used with no explanation.

  | I don't see us 
  | getting into a situation of having to implement the equivalent of the 
  | telnet EXOPL given that Bob is talking about deprecating hop-by-hop 
  | altogether.

Bob may be talking about it, but I don't really see it happening.
That functionality is required by too many existing users (the
Router Alert option wasn't invented for no purpose at all...)

kre

---

From: Eliot Lear <[email-masked]>
Date: Tue, 28 Jun 2005 23:11:21 +0200

John,

This message is a point of information.  I'll continue the discussion in 
the other thread.

John C Klensin wrote:
> Eliot,
> 
> There are at least two things that are wrong with the model you describe 
> below,...
> 

My point is simply that there is an analogy to be drawn between the two 
in terms of ramifications.

>     Called in the IETF and approved as a BCP document.

I'm quite certain that RFC 1597 was only approved ex post facto, and 
only after Tom Kessler, Dave Crocker, Erik Fair, and I made a huge stink 
about the complete lack of review (RFC 1627).  Once the document was 
released there were very heated discussions between the IESG, the IAB, 
and, well, me.  But the record shows no discussions prior to release at 
the IESG level.

RFC 1918 was done in part due to recognition that the authors had not 
been sufficiently careful about circumscribing the use of the 
allocation, and after my appeal over the allocation had failed.

History lesson over.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Tue, 28 Jun 2005 23:21:35 +0200

Please see below:
 > Whether that discussion amounted to consensus or not

Not publicly.  Certainly there was a problem.  Indeed someone (I forget 
who) had made a request for a /8, which forced the issue.

> gets pressure to at least make processing the option optional, and it

My concern is the ground in between, where some people derive some 
benefit from it to the detriment of others because of some interaction 
introduced on the device (be it a queuing behavior that leads to 
fairness problems or what have you), where the function has gotten 
implemented and is used where perhaps it wasn't intended (say, like 
oh... network 10).

Is this architectural purity?  Perhaps.  It's really not what I would 
aim for.  I think the standard should simply be "will the thing cause 
harm?" and the judges of that standard should be the IESG and not IANA.

That's all I'm saying.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Jun 2005 01:04:34 +0200

John, I'm probably replying out of sequence, and I'll say this once
again only:

I don't believe that the IESG is entitled, under the BCP in force,
to authorise the IANA to assign a hop by hop option number to
a usage that we believe clearly needs IETF technical review.
So we don't go to question 2 until we've dealt with question 1.

     Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 28 Jun 2005 19:57:06 -0400

To whatever small degree it matters, I agree with Brian on this.

There have been many clear statements indicating that the writer believes 
that the policy in force for the allocation of these code points is 
wrong.  The policy may be right, and it may be wrong.  But that is not the 
point.
But the policy as written in the RFC requires that the IESG review the 
proposal.  Such a review clearly implies technical review, not just a check 
for document completeness.  The IESG did what the RFC tells them to do.

Yours,
Joel M. Halpern

---

From: Robert Elz <[email-masked]>
Date: Wed, 29 Jun 2005 11:13:58 +0700

Date:        Tue, 28 Jun 2005 23:21:35 +0200
    From:        Eliot Lear <[email-masked]>
    Message-ID:  <[email-masked]>

  | Not publicly.  Certainly there was a problem.  Indeed someone (I forget 
  | who) had made a request for a /8, which forced the issue.

At the time 1597 was being prepared, I was certainly just a regular
IETF member (and not all that frequent an attendee of meetings), so if
I knew anything about it, it had to be public, in at least some parts of
the IETF.   For what it is worth, which is almost zero now, at the time
I was one of those (like you) who was opposed to the thing.

  | My concern is the ground in between, where some people derive some 
  | benefit from it to the detriment of others because of some interaction 
  | introduced on the device

Of course, the net as it exists now is a constant battle between those
who are getting better service, and those who are not.   It occurs
in all kinds of ways, and certainly things change as new developments
occur which favour one group or another.   As almost everyone is
constantly attempting to improve their own situation, and meet their own
needs (for obvious reasons, and I am not even claiming that any of this
is a bad thing) that's to be expected.   Everyone simply has to cope.

  | Is this architectural purity?  Perhaps.  It's really not what I would 
  | aim for.  I think the standard should simply be "will the thing cause 
  | harm?" and the judges of that standard should be the IESG and not IANA.

My point is that it should be neither.   The community (network operators,
users, developers) all between them end up deciding which parts of the
various standards that are published (by the IETF, and others) get used,
and which do not.    We need no morality police.

But for all of that to work, the (comparatively few) places where sharing
is needed to keep things working, the sharing must be fair.   That is,
there cannot be any of "this was not developed here, and we do not like it,
so you cannot play" type mentality.

The various paramater assignments must be open to all.   All kinds of
things will be tried, by all kiinds of people, whether we like them or
not.   About all we can do to retain sanity is to make sure that we
know what is happening, and can detect it cleanly.   We certainly
have no means to stop it.

Do remember, that the IETF is not the owner or the boss of the internet.
All the IETF has any direct influence over is a set of standards
(protocols) that the Intenet (in its collective wisdom) can choose
to use, or not to use.   They can, and do, also choose to use technology
from other sources.

kre

---

From: John C Klensin <[email-masked]>
Date: Wed, 29 Jun 2005 07:44:50 -0400

> So we don't go to question 2 until we've dealt with question 1.

While we read the BCP differently, largely because of a
different understanding of the thread and definitions that led
up to it (see other notes), this seems like a perfectly
reasonable position.  I am a firm believer in IETF technical
review, even if the result of that review is either a request to
talk the submitter out of the option number request or the
attachment of an in-depth "why this is bad news" comment to the
assignment when it is made.

But, if that is the IESG's position, then the IESG should have
responded "_We_ cannot (or even 'will not') approve this type of
proposal without IETF technical review because we have doubts
about it technically.  We are not denying the request for the
long term, just indicating that, if the submitter wants the
option number, arrangements for submission to the IETF, and IETF
review, will need to occur first.  And we will, of course, keep
an open mind on the protocol quality and technical review until
we hear from the community after such a review is concluded."   

What the IESG appears to have said instead is not "IETF
technical review is needed" but something more similar to "we
have discussed this and conducted a review.  (Given our
complaints about lack of available documentation, we may have
done that review without looking at the supporting materials.)
On the basis of _our_ review, we have decided that the protocol
is defective and that there is no point asking the IETF
community because they would ultimately make the same decision."
Now, whatever I, or the community, may think of that style of
decision-making -- it has been discussed on this thread and I
won't repeat it -- _that_ takes us immediately back to question
2 because the IESG has decided, and said, that further IETF
technical review beyond the IESG's conclusions is not needed.
So, from that perspective, the review has been completed and we
only have the question of registration and identification to
discuss.

       john

---

From: Sam Hartman <[email-masked]>
Date: Wed, 29 Jun 2005 15:40:56 -0400

John, as I understand it, the IESG believed it was turning down this
specific request.  The IESG believes this option will never be
assigned through the IESG review process.  I don't think the IESG did
turn down the option of IETF consensus nor the option of standards
action.  I do not believe the IESG has the authority to decline those
avenues of option assignment for this proposal.  The IESG does have
the authority to review specific internet drafts brought to it as part
of publication.  But the IESG cannot, should not, and as far as I know
did not prevent Dr. Roberts from submitting an internet draft and
requesting publication of that draft.

(I'm not actually sure how you would go about doing the IETF consensus
review process without a draft being involved. )