> 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