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" <kre(_at_)munnari(_dot_)OZ(_dot_)AU>
To: "Bob Hinden" <bob(_dot_)hinden(_at_)nokia(_dot_)com>
Cc: <ietf(_at_)ietf(_dot_)org>; "IESG" <iesg(_at_)ietf(_dot_)org>
Sent: Saturday, June 25, 2005 1:12 PM
Subject: Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option
Date: Sat, 25 Jun 2005 10:25:24 -0700
From: Bob Hinden <bob(_dot_)hinden(_at_)nokia(_dot_)com>
Message-ID:
<6(_dot_)2(_dot_)1(_dot_)2(_dot_)2(_dot_)20050625093133(_dot_)027d63a0(_at_)mailhost(_dot_)iprg(_dot_)nokia(_dot_)com>
| 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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf