H.323 Annex O

Scott Bradner sob at HARVARD.EDU
Wed May 31 08:45:35 EDT 2000

some notes on Chip's message at ">>"

Scott (ISOC VP-Standards)


At 09:59 AM 5/30/00 -0400, Roy, Radhika R, ALARC wrote:
>There are also no mechanisms in the ITU-T SG16 to accept the contributions
>for the companies that can afford to communicate via emails only. I guess
>that the best way is to have the RFC from the IETF that will have all inputs
>from all companies that invented the interworking solution. The SG16 can
>then have the RFC for their use to make a formal standard (with more
>additions if needed).

It is true that SG16 still operates mainly on the basis of written
contributions to meetings and not on mail lists like IETF WG.  It is also
true that non-ITU members have a hard time participating in ITU SG
work.  Even if a company is an ITU member, attending all the meetings
around the world is a travel burden on small companies (even big
companies). However, an IETF WG can submit a written contribution to SG16
via existing mechanisms. Usually, this is initiated via consensus of the WG
and/or by WG chair via the ISOC VP - Standards.  Of course, it requires
someone to represent that contribution at the SG16 meetings.  The SG16
Rapporteurs have been very open in the past to inviting non-ITU member
experts to Rapporteur Meetings to further the work.  The SG16 mail list has
been one of the more active SG mail lists in actually discussing technical
issues.  And SG16's working documents are available for review as well (at
least from Rapporteur's Meetings).  It will be nice if ITU could codify
some of these examples at WTSA.
>> in addition working group chairs can request that individuals be
>> appopinted formal ISOC (IETF) representives to ITU-T meetings
>> by the ISOC VP-standards working with the IAB (teh ISOC is an ITU-T
>> member)

I understand the desire to do the work in one place.  It is also true that
SG16 can reference an IETF RFC in its recommendations.  However, if it is
an informational RFC, it can't be a normative reference in ITU.
>> nor should it be since an RFC with informational status carries no
>> implication of IETF review, support or approval

>If you think that any improvements need to be done in the solutions proposed
>in the contributions of the IETF (please see the references provided in my
>email), please submit the proposal in the IETF. We can then use the
>Informational RFC as an input for a formal standard in the SG16. In this
>way, we can get the best the both worlds having a "single common standard
>for SIP-H.323 Interworking".

Remember an ITU Recommendation cannot make a normative reference to an
Informational RFC.
If there is no new protocol work being done, the H.323-SIP interworking
could conceivably become a BCP (Best Current Practice) some day.

>The key is that the SG16 cannot use the interworking solution that has been
>"invented" by the other companies or institutions without their consent and
>participation. I personally feel very strongly that the SG16 cannot not
>"invent" a NEW interworking solution of its own that will NOT include the
>solutions proposed by others in the IETF.

The ITU can incorporate by (normative or non-normative) reference to any
RFC.  The IETF has an IPR policy that isn't too different from ITU (I don't
think).  Current A.5 procedures require that IETF provide a written
agreement to allow normative references to an RFC (I don't remember ever
seeing one of these, but there may be a blanket agreement).  There are
proposals to drop this requirement in the next version of A.5.
>> the ISOC gave a blanket approval years ago

Any IPR contained in IETF RFCs are covered by IETF IPR policy.  It is true
that a company that has declared IPR in an IETF RFC may not know it is
being referenced in ITU and therefore may not submit an IPR statement to
ITU.  Therefore the IPR would only be covered by the IETF IPR statement
(this brings up interesting legal questions, but I'll leave that up to the
lawyers.).  This should only be a real problem if the invention were
included in the ITU Recommendation by some means other than reference.

So the bottom line is that there are mechanisms to share work in ITU and
IETF even without all the formal mechanisms worked out between Megaco and
Q.14.  However, if the work is going to be cooperative, such an agreement
is probably desirable.
>> specifically - the process worked out for megaco is described in A.5
>> but it is listes as the least desirable way to work together - it is
>> far cleaner for one organization to take respoinsibility for publishing
>> the document (with input from the other) and the other organization
>> create a simple document that points to the offical document

For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

More information about the sg16-avd mailing list