ietf
[Top] [All Lists]

Moving forward with the option (Was: Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option)

2005-07-02 22:21:24

Hi Margaret,

And thanks for posting constructive suggestions for moving
forward on this issue!

What you say below makes sense. However, it occurs to me that
there's also another possibility which has perhaps more commonly
been used when IETF works together with other standards bodies,
and has generally worked well. I wonder if that process could be
used, and whether it would have a better chance of succeeding.
I don't know the details of the technical suggestion here, but it
seems that there's some controversy about it. If that controversy
remains even after providing more information, we may have a
problem, and at that time its not between Dr. Roberts and the
IETF, its between ITU and the IETF.

But there could be another way. For instance, when 3GPP or IEEE
requests something from the IETF, its most of the time in the form of
a request for a function, say an ability of the SIP protocol to support
particular types of calls. Now, requests like that typically happen
fairly early on in the process, the other SDO has certainly already
internally agreed that they need the function and they may even
have some ideas about how to implement it in terms of protocols.
And they can send an official letter to the IETF stating that they
need the function. But they have not finalized their specifications
or given them the stamp of approval yet. This is actually important,
as we will see below.

Typically, the implementation ideas have been submitted to the IETF
and are documented in the form of Internet Drafts.
In some cases, if the function is complicated enough, even its
requirements are documented as Internet Drafts.

This is where the IETF process kicks in. These requirements for
functions are submitted to the usual WG process, and discussed.
In many cases the IETF can see requirements for different scenarios
and functions, and can combine them into one generally useful
function. And the implementation ideas sometimes change during
the process too, even drastically. But that's alright for everyone
involved. At the end RFCs become published and the other SDO's
specifications can point to them and get their final stamp of
approval.

One problem with this process is that it can take some time.
Some speed-ups have been used, often it helps throughout
the process simply if everyone (editors, chairs, ads, reviewers etc)
knows some other SDO has a deadline on this document. Many
SDOs can also accept a pointer to a draft to their specifications,
as long as that draft has been approved by the IESG, which eliminates
the RFC Editor wait. Nevertheless, the cases that I've seen range
from a couple of months to several years of IETF processing time.

--Jari

Margaret Wasserman wrote:


Hi Larry,

At 12:30 PM -0700 6/25/05, Dr. Lawrence G. Roberts wrote:

I need help as to any process that can mitigate this major conflict with the TIA/ITU and the IETF and I >need to act now. Please send your thoughts,


I was looking back over this thread, and I just happened to notice this paragraph. I am sorry that I missed it the first time.

It is my personal opinion (not discussed with the IESG or others) that the most sensible way for you to proceed towards getting this codepoint assignment would be to seek the assignment through "IETF Consensus". There is no guarantee that this path would be successful, but I believe that it is the most likely to succeed.

To do this, you would start by writing an Internet-Draft. The goal would be to get this I-D published as an Information RFC that allocates the code point and explains the purpose of the allocation.

IMO, this I-D would not have to include the specification of the hop-by-hop option itself; it could simply refer to a stable, publicly available reference for that option (presumably the ITU or TIA standard that specifies it). You would need to include an IPR statement, a reference to the ITU or TIA standard, and an IANA Considerations section that requests the allocation. You might wish to include some other text explaining how this option relates to existing IETF and ITU standards, etc.

You would need to get this document published as an RFC through the IETF consensus process, which means that it would need to be sponsored by an AD. Once the I-D is in the I-D archives, you could send a message to the IESG requesting publication, and we could decide which AD is the most appropriate one to shepherd this document in the IETF.

There are several open questions (in my mind, at least) about this allocation, and I think that you would need to address them in the process:

- Is there a stable, publicly-available document that describes this option? I know that you have e-mailed documents as attachments and sent URLs to a private web site, but I am still not clear on whether there is a stable ITU or TIA specification for this option and, if so, whether it is readily available to the public. In fact, I am not even sure if I have the right to disseminate the information that you have send to the IESG.

If there is a stable, publicly available reference for this document, could you send a pointer? If not, could you please clarify the status and availability of the document?

- What, if any, IPR issues are there surrounding this document? Would any sort of license be required for someone to implement this hop-by-hop option? If so, have the terms of that license been publicly stated? This would need to be clarified as part of writing the I-D indicated above.

- What, if any, official status does this option have in the ITU or TIA at this time? I know that it is under consideration in one or more study groups, but I am not under the impression that it has been approved by the ITU yet, is that correct? I do not anticipate that the IETF would be willing to allocate this codepoint until the corresponding specification has been fully approved within the ITU or TIA, just as we do not allocate codepoints for IETF specifications until they are approved for RFC publication.

One thing that I think would resolve this concern is if the ITU were to send an official request (through the appropriate liaisons) clarifying the status of this document and requesting the allocation. It would be best if this request came after an I-D is available (as described above) and could refer to it. This is not strictly required by our process, but would quickly put to rest any concerns about whether this specification really has been approved within the ITU.

In my opinion, following the steps above would resolve many of the open questions regarding this allocation and would give the IETF enough information to make a consensus-based decision. I don't know what that decision would be, but I would be happy to provide any advice or help you might need in order to effectively ask the question.



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



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