Subject: Re: S stands for Steering [Re: Should the IESG rule or not?]

From: "Ken Carlberg" <[email-masked]>
Date: Fri, 1 Jul 2005 01:02:29 -0400

> From: Brian E Carpenter 
>
> 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.

My view is that your impression of the reaction is incorrect.  in
taking the position that respondents can be classified as either: 
a) being satisfied with the IESG *decision*, b) dissatisfied or 
uncomfortable with the decision, or c) could not be clearly 
determined by the content of their response, I came up with the 
following list.

Dissatisfied         Satisfied               Other
------------         ---------               -----
Robert Elz           Thomas Narten	        Barbara Roseman
John Leslie	         Sam Hartman            Yakov Rekhter
Ken Carlberg         Bob Hinden             Scott Brim
Ralph Droms	         Brian Carpenter        Spencer Dawkins
Steve Silverman      Allison Mankin	        Thomas Hruska
Jefsey Morfin        Harald Alvestrand      Randy Presuhn
John Klensin         Keith Moore            Scott Bradner
Nick Staff	         Bill Sommerfeld
Lawrence Roberts	   Eliot Lear
Vint Cerf	         Joel Halpern
Dave Crocker         Margaret Wasserman
Ned Freed	         Jeffrey Hutzelman
Grenville Armitage
Hans Kruse

I listed names so that people could object to my interpretation,
and I'm sure I made a mistake or two.  But at best, it seems the
reaction is split, and not to be viewed as objections coming from
simply a few but persistant people.

-ken

ps, I hope your vacation is going well :)

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

---

From: Scott W Brim <[email-masked]>
Date: Fri, 01 Jul 2005 14:11:47 +0800

> determined by the content of their response, I came up with the 

You can add me to the "satisfied" column.  The IESG is asked to take
positions and to lead (despite what a few think).  That's risky -- no
matter what they do they get criticism from somewhere.  Maybe they
didn't *phrase* the announcement perfectly, but the decision is
correct.  Something like this must have a serious, long-term IETF
review.  We need to take the overall design of the Internet into
account and not just be administrators.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 01 Jul 2005 09:24:29 +0300

>account and not just be administrators.
Count me in too. The IESG might have been more polite
in their answer, but yes, "IESG Review" in an IANA
considerations text means just that, and its not the same
as "FCFS".

--Jari

---

From: Pekka Savola <[email-masked]>
Date: Fri, 1 Jul 2005 09:36:30 +0300 (EEST)

> account and not just be administrators.

FWIW, I haven't said anything on the thread but I'm largely satisfied 
with the IESG action, though I can understand the arguments why 
documenting the proposed use could be useful.

However, I believe there is a significant difference between "proposed 
use" and "actual use".  I'm hoping that most of the people who come 
asking for these code points, but don't get one, will change their 
designs (so a code point is not needed) or engage in a dialogue 
(instead just picking a code point and getting it implemented).  I'd 
certainly hope that mainstream vendors wouldn't just add 
unregistered/rejected codepoints in their products, and if the use is 
restricted to a minor vendor or a very specific environment, I doubt 
many care too much one way or the other.

If we want to enable any kind of protocol to get any kind of code 
point (instead of just stealing one), I'd think it might make sense to 
split a few codepoints from the registries to be allocated using a 
more relaxed process (RFC3692/BCP82 may or may not be a partial 
solution here), so that the vendors could more easily just ignore 
those options.

However, I think an important benefit of a sufficiently strict 
allocation procedure is that those people who have a genuine desire to 
design a protocol that's at least halfway sensible need to initiate 
the community in a technical dialogue.  In the process maybe the 
community is swayed, or the protocol designer sees that a different 
approach may be much better.  We can always hope so.

No matter what we do, there are always going to be people who try to 
push their own protocols, not caring to hear any feedback or input, 
and the process (for the most cherished IANA resources) should be 
strict enough to limit the damage those could inflict.

Or maybe there is a need for a short document explaining that if you 
want to build FOO protocol, it might make good sense to design it 
using TCP/UDP and FCFS assignments, instead of using more scarce or 
more tightly controlled resources, especially if you have a tight 
market DL and/or don't want to engage in a technical dialogue in the 
IETF..

In the particular case of hop-by-hop options, maybe the best approach 
could be to assign a couple of experimental code points per RFC3692. 
If folks want to deploy (in small scale) or test their ideas, they 
could always use those codepoints, and everyone else could put code in 
their products to ignore them.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Robert Elz <[email-masked]>
Date: Fri, 01 Jul 2005 15:20:52 +0700

Date:        Fri, 01 Jul 2005 14:11:47 +0800
    From:        Scott W Brim <[email-masked]>
    Message-ID:  <[email-masked]>

Scot,

  | Something like this must have a serious, long-term IETF review.
  | We need to take the overall design of the Internet into
  | account and not just be administrators.

How do you propose we enforce that?   In more common circumstances
the way that happens is that the IETF refuses to publish a proposal,
which is generally effective, as what most people (seem to) want is
an RFC number that can use as a badge on their product.

Here, no-one, as best I can tell, ever wanted an RFC number.   There
has been some opinion recently (from what I can tell, I certainly have not
read all of the messages) that they really should want an RFC number.

Nonsense.

While the IETF makes standards for use on the internet, and with the
internet protocols, nothing gives it the exclusive right to make such
standards, or to invent internet protocols.

Anyone can do that.   W3C certainly does that.   So can anyone else.

When they do it, they don't automatically get an RFC number to bandy about,
which many might see as a disadvantage, but if they don't need that, then
they just go ahead.

Whether anyone, and if there is anyone who they are that, uses the protocol
that's been designed is the ultimate judge of it, not whether or not it has
IETF blessing, or anyone else's blessing, or an RFC number.

The other tool we (pretend to) have is to refuse to allocate numbers in
the parameter registries, where a number is needed to make a protocol
work.   We can certainly do that.   But what effect do you expect that
will have?   That is, what would you do, if you were denied a parameter
registration for your protocol?

Or, to make that query more specific, cisco designed (long ago) a
routing protocol (igrp, now eigrp), which I assume needs a port number,
or an IP protocol number, or a multicast address, or something like that.

What do you think would have happened, had the IETF (or IANA) replied
to a request for that parameter to be allcoated with a response like:

  "Sorry, routing protocols are fundamental to the operation of the network,
   we will not allocate a parameter for your protocol unless you have it
   reviewed in the IETF, and the community agrees that your protocol is
   a good one,  What's more, we are already doing work defining routing
   protocols, we don't believe that yours has any chance of success, so
   please go away and don't come back."

Really, what would have happened?   Do you really believe that cisco
would simply have dropped igrp and said "oh well, we lost" or something?

I certainly don't, and I cannot think of any reason why they should have,
nor why Dr Roberts' group should in this case.

Allocating a number for yourself is trivial.   If you can't get one
assigned, then you self-assign.   Anyone would.   If you don't care
about the RFC number badge, then denying a paramater registration is
about as effective in actually preventing the protocol being used as
being flogged with (wet) spagetti would be (probably less so)...

Do you, or does anyone, really believe that we're better off with
data on the network, whose purpose we don't understand, for which
we have no idea what it is about, or how to find out more information
about it, than not having such data?

That's what the IANA registry is really all about - it is to make sure
that information about what exists is available, and we can discover
what is there, and manage to avoid conflicting with it.  Attempting to
use it as an enforcement tool is highly counter-productive.

kre

---

From: Robert Elz <[email-masked]>
Date: Fri, 01 Jul 2005 15:50:19 +0700

Date:        Fri, 1 Jul 2005 09:36:30 +0300 (EEST)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  | though I can understand the arguments why 
  | documenting the proposed use could be useful.

I believe it is documented (though I haven't read the documentation
and see no need to do that).   What it isn't, is documented as an RFC
(or even an I-D).   Whether the documentation is adequate or not
is a reasonable question to ask, and is the question the IESG should
have investigated.

  | I'm hoping that most of the people who come 
  | asking for these code points, but don't get one, will change their 
  | designs (so a code point is not needed) or engage in a dialogue 
  | (instead just picking a code point and getting it implemented).

And why would you expect that to be the case?   Some might be
persuaded by arguments that show a better alternative, a very
few might be persuaded by arguments that say "that's no good"
without suggesting anything better, or at least demonstrating
a problem (in the IETF we tend to tell people who make those kind
of arguments to go away).   Others?

  | I'd certainly hope that mainstream vendors wouldn't just add 
  | unregistered/rejected codepoints in their products,

Personally I'd expect that decision to be based upon how many $'s
they expect implementing the option/feature to be able to make for
them, compared to the costs of doing it.

If you believe that vendors have never implemented features in advance
of IETF approval, or even discussion, you're deluding yourself.
(Just consider what happened to the IPv4 TOS byte, and how that
was actually done).

  | and if the use is 
  | restricted to a minor vendor or a very specific environment, I doubt 
  | many care too much one way or the other.

Here, I absolutely disagree.   Features that start out being restricted
to specific environments have a tendency to escape into wider uses.

In this, I think I am in agreement with those who agree with the IESG's
action, because they have looked at the protocol, don't like what they
see, and are afraid of it (or perhaps something similar in the future)
escaping into the network and doing harm.

I certainly agree that is possible.   Where we disagree, is that I cannot
see (as apparently you can't either, though you "hope") that it is
possible to prevent this by refusing parameter registrations.

I prefer to know what is there, to be able to identify it, and to locate
the identifying documentation or responsible person.   Others seem to
prefer to pretend that if it isn't registered in the IANA registry, then
it cannot possibly exist (the ostrich syndrome).

  | If we want to enable any kind of protocol to get any kind of code 
  | point (instead of just stealing one), I'd think it might make sense to 
  | split a few codepoints from the registries to be allocated using a 
  | more relaxed process

No, that kind of thing has been tried in the past, and it simply does
not work.   The "experimental" code points, if they succeed, get
embedded into products, and cease being experimental.   And that happens
before anyone realises, and well after the point where it would be
practical to move to a different number.

  | No matter what we do, there are always going to be people who try to 
  | push their own protocols, not caring to hear any feedback or input, 
  | and the process (for the most cherished IANA resources) should be 
  | strict enough to limit the damage those could inflict.

Exactly.   This is the point.   Do we push them underground, or do
we be honest with ourselves, recognise that this is going to happen,
and at least allow it to happen in a way where the harm to the rest of
us is minimised?   We can't stop this, but we can at least observe it.

  | Or maybe there is a need for a short document explaining that if you 
  | want to build FOO protocol, it might make good sense to design it 
  | using TCP/UDP and FCFS assignments, instead of using more scarce or 
  | more tightly controlled resources, especially if you have a tight 
  | market DL and/or don't want to engage in a technical dialogue in the 
  | IETF..

That may be true, but couldn't possibly help here.   From what I have
seen, the proponents of the protocol in question are convinced that the
only way for it to work is by using hop by hop options.   That is, they
are expecting that everything above the IP layer is going to be (and
must be) encrypted, and they need to send information that the routers
along the path can examine.

That they cannot do by embedding anything in UDP or TCP - then all of
the data would be hidden from the routers.

Or at least, that is my understanding (purely from the e-mail on this
topic that I have read, not all of it public).   [I have no idea what
data they need the routers to see, or why.]

  | In the particular case of hop-by-hop options, maybe the best approach 
  | could be to assign a couple of experimental code points per RFC3692. 
  | If folks want to deploy (in small scale) or test their ideas, they 
  | could always use those codepoints,

As above, it would solve the immediate problem, they'd have a code point,
which is all they need, but (if what they're doing works) it isn't going
to stay experimental very long, and the code point is never going to get
altered after it has been used.

  | and everyone else could put code in their products to ignore them.

No-one needs to do that (in response to this request).   If your IPv6
doesn't already ignore unknown options (or drop the packet, depending
upon the value of the unknown option) it is seriously broken.

There is no case here of something being developed which would cause
everyone (or for that matter, anyone) to be required to upgrade anything
(other than to correct latent bugs that may be exposed).

kre

---

From: Robert Elz <[email-masked]>
Date: Fri, 01 Jul 2005 16:02:57 +0700

Apologies for missing the second 't' in your name in the message
I sent to the list - I must have been asleep...

kre

---

From: David Hopwood <[email-masked]>
Date: Fri, 01 Jul 2005 10:56:48 +0100

> account and not just be administrators.

Add me to the "satisfied" column as well.

Much of the objection expressed on this list seems to have been not to
the decision itself, but that the way the decision was expressed by the
IESG appeared to preempt what the result of an IETF consensus process
would be. My opinion on this is that:

  - the IESG is entitled to hold positions about the suitability of
    particular proposals, and to express those positions publically and
    forcefully. They should not be prevented or discouraged from doing
    so by politics.

  - if there are substantive objections to the grounds on which the IESG
    approved or did not approve a request in any particular case, that is
    what the appeals process is for.

  - expressing the position that Dr. Robert's proposal would be unlikely
    to reach IETF consensus *as part of the decision not to approve the request*
    was arguably unwise.

Some people appear to want to use this case as a stepping-off point for a
campaign to liberalise the policies for allocation of code points in all or
most code spaces. This would effectively result in the prior decisions of
working groups and others as to what level of review is required in any
particular code space to be altered, without consulting those groups.

The idea that in general, allocating code points based only on availability
of documentation and not technical review must be harmless as long as
extension/option mechanisms are designed correctly, is dangerously naive.
As several posters have pointed out, the problem here is with extensions/
options that *are* implemented, not those that are ignored. A policy of
(essentially) rubber-stamping code point allocations would, in practice,
lead to more options with a marginal or poor usefulness/complexity trade-off,
that would nevertheless have to be implemented to ensure interoperability.

If the description of what IESG Approval should involve is unclear, then
that option, and that option only, should be clarified in an update to
RFC 2434. There are no grounds for any radical rethink of allocation
policies in general.

-- 
David Hopwood <[email-masked]>

---

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 1 Jul 2005 10:51:59 -0400

> determined by the content of their response, I came up with the 

You can add me into the "Satisified" column".  Note that sampling
messages posted to [email-masked] on this list will almost certainly be
biased, since it is the people who are disasstified which are likely
going to be the ones complaining aobut it.

						- Ted

---

From: "Nicholas Staff" <[email-masked]>
Date: Fri, 1 Jul 2005 08:22:50 -0700

I agree that no noise usually means agreement, but once a counterpoint has
been raised I don't know how to tell which side the silent people are
agreeing with.

I'm not saying I see all angles to this but it seems like Robert really has
some strong logic behind him - If assigning the registration doesn't give
anything that could have been taken without it then all we are ensuring by
giving the assignment is documentation on record, an easy way to ignore the
implementation (by reference of the assigned number), and an avoidance of
future conflicts with options we might find of much more import.  I don't
see the benefit of flying blind only because I don't know how that helps us
achieve the goal of preventing this implementation.  If that could be
explained then I would change my tune.

Best regards,

Nick Staff

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Theodore Ts'o
Sent: Friday, July 01, 2005 7:52 AM
To: Ken Carlberg
Cc: [email-masked]
Subject: Re: S stands for Steering [Re: Should the IESG rule or not?]

On Fri, Jul 01, 2005 at 01:02:29AM -0400, Ken Carlberg wrote:
> uncomfortable with the decision, or c) could not be clearly determined 
> by the content of their response, I came up with the following list.

You can add me into the "Satisified" column".  Note that sampling messages
posted to [email-masked] on this list will almost certainly be biased, since
it is the people who are disasstified which are likely going to be the ones
complaining aobut it.

						- Ted

---

From: John C Klensin <[email-masked]>
Date: Fri, 01 Jul 2005 13:55:39 -0400

Brian,

Let me add three observations to Ken's rather interesting 
tabulation (without having read all of the traffic since then -- 
if someone else has said this, I apologize)...

--On Friday, July 01, 2005 1:02 AM -0400 Ken Carlberg 
<[email-masked]> wrote:

>> From: Brian E Carpenter
>>
>> 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
> My view is that your impression of the reaction is incorrect.
> in taking the position that respondents can be classified as
> either:  a) being satisfied with the IESG *decision*, b)
> dissatisfied or  uncomfortable with the decision, or c) could
> not be clearly  determined by the content of their response, I
> came up with the  following list.
>
> I listed names so that people could object to my
> interpretation, and I'm sure I made a mistake or two.  But at
> best, it seems the reaction is split, and not to be viewed as
> objections coming from simply a few but persistant people.

(i) Of the people in the left-hand column, there are at least a 
few who believe either that the proposed protocol is a dubious 
idea or even that the registration request should, in the last 
analysis, be rejected.  Their objection is to the process the 
IESG followed, the assumptions about authority the IESG made in 
following it, and/or the way in which the IESG explained its 
decision.   In that regard, there may be some overlap with some 
members of the "other" group: some of the "other" group might 
reasonable be classified with the "dissatisfied" or vice versa. 
Certainly few of the "others" are completely happy at this point.

(ii) It is interesting to note that there are present or former 
ADs in all three groups, but that, of the 12 people in the 
"satisfied" group, fully half are current, or immediately past, 
ADs.  By contrast, there are zero people in either of the other 
two lists who are now ADs or who have served as ADs since March 
2003.  One could probably interpret that factoid in several 
ways, but one cannot help but notice that, if one excluded IESG 
members defending either a recent IESG action or general IESG 
perceptions of its role from the second group, it would be the 
shortest of the three lists.

(iii) By my rough and subjective count (I, too, am supposedly on 
vacation and hence suffering from impeded connectivity), the 
"few people" making a "large number of postings" are distributed 
among the first two groups, with neither group having a monopoly 
on that particular distinction.

       john

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 01 Jul 2005 23:07:47 +0200

The list of "satisfied" is of ne real interest. The list of "disatistied" 
seem important enough to say there is no consensus.

---

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 1 Jul 2005 19:43:42 -0400

> seem important enough to say there is no consensus.

No IETF consensus is required to accept or deny a registration for the
registry in question under the current rules; instead IESG approval is
required instead.

And if there is no consensus, then there is also no consensus to
change RFC 2780, under which auspices the IESG acted....

						- Ted

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sat, 02 Jul 2005 16:41:07 +0200

>registry in question under the current rules; instead IESG approval is

Agreed. But the question is now "does IETF think IESG was right". There is 
no consensus. We should therefore stop arguing on HPH and get a more 
peacefull and general debate. I prefer the "we have a generic problem" 
approach to "you are dumb stupid to have (not) adopted that, because of RFC 
n1 to nx". ...

>change RFC 2780, under which auspices the IESG acted....

It seems it is a second problem which could be addressed after the general one.
all the best.
jfc