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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> To state that somewhat differently, since we cannot effectively
> prohibit the deployment of an extension or option of which the
> IETF disapproves, the best things we can do for the Internet are
> make it as easy as possible to identify the use of the extension
> so it can be effectively quarantined and to make information
> about why we consider it a bad idea readily available.
> Ironically, both of those goals are most strongly aided by
> registering the extension and assigning an appropriate
> identifier, rather than rejecting registration requests and
> hoping the idea goes away.

Very nicely put, John. I completely agree. And to the extent we have "running
code" in this area, I believe it supports this view.

> While the situation with the Hop-by-hop proposal appears closer
> to the first group of cases than the second, it appears to me to be
> complicated by two other factors:

> ...

In the specific case of the current proposal, my view is that the reasons the
IESG gave for rejecting this proposal put us all out  on a very shakey limb,
and the added comments about the likely outcome of this work being made an IETF
work item of some sort have no limb at all underneath them.

I also have another concern here that I don't believe anyone else has
mentioned. In response to criticism of the lack of openness of the process used
to arrive at this rejection, it has been asserted that it had to be this way
due to the lack of availability of a specification for review.

As many of you no doubt know, I have long been an advocate of having freely
available specifications whenever possible. I have frequently pushed back on
IETF that involves references to outside work that isn't readily available.
These concerns have usually been dismissed with responses like: "There's no
rule against it" or "The specification is available to those who really care"
or "There's nothing we can do to improve the situation so live with it". And in
fact we have numerous specifications which depend on such references. In fact
while I was on the IESG on at least one occasion I paid $ in order to obtain
a specification I felt I needed in order to carry out proper review of
something.

After all this I find it quite curious to see the lack of a publicly available
specification used to justify the way this was handled, when in so many other
cases we simply shrugged and moved on.

Even worse, the fact of the matter is the specification is publicly available:

  http://www.packet.cc/IPv6Q-IETF-2A.htm

No googling necessary; this URL was included in the original submission
request.

Now, the request also stated that this is not the final form of the
specification that was submitted to the ITU. But it seems very unlikely that
the specification has changed sufficiently that the earlier, publicly available
draft couldn't be used for review purposes. But rather than speculate on that,
since we have the author of the proposal here, I'll just ask a direct question.
Dr. Roberts, do you believe there have been sufficient changes between the
version posted at the above URL and the ITU submission that it isn't reasonable
to decide things based on the public version? And if there have in fact been
sufficient changes, would it be possible to make a version with those changes
available for public review?

> > > Historically, we maintain registries of various protocol
> > > parameters, not to endorse them, but to prevent conflicts in
> > > the 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.

> Actually, I think it is possible to state, or restate, guiding
> principles, even if the details for those registries are
> different.  In the interest of focusing discussion, an
> Internet-Draft that attempts to do just that will be submitted
> for posting later today.

Agreed again. I'm looking forward to seeing your document.

				Ned

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]