ietf
[Top] [All Lists]

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

2005-06-29 11:50:51
Larry,

One thing that may not be immediately obvious is that if the IETF
reviews a contribution (whether it's an Internet-Draft or an email),
it automatically falls under IETF IPR rules. Alternatively, if another
SDO sends a liaison requesting IETF review of their document, we
presume that the other SDO's IPR rules apply. It's rather unclear
what IPR rules apply when an individual (e.g. you) points the IETF to
another SDO's document, absent a formal liaison.

But what the IETF does best is review I-Ds.

In other words, if you want to make progress, a repeat request
accompanied an I-D is really the best way (regardless of the
IESG's expressed pessimism).

   Brian

Dr. Lawrence G. Roberts wrote:
Ned,
The document on my packet.cc web site is certenatly close enough to the final ITU documents attached (which I sent to Brian) that there should be no trouble reviewing it for the concepts. The attached documents are the latest ITU documents and the TIA 1039 document is identical in content. The difference in them from the packet.cc document is in the addition of IPv4 which is not at issue and does not depend on an option field code assignment. Making these later ones publicly available can be considered. But it may take awhile. Meanwhile, the copies above were available to the committee since I sent them to Brian.. It is hard to convert these documents to ACII text quickly to put them in IETF format. That was done once at packet.cc and the option field is for IPv6 which is in all the documents.
Larry



At 10:43 AM 6/27/2005, Ned Freed wrote:

> 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


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf



<Prev in Thread] Current Thread [Next in Thread>