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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf