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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf