New Tones Payload Type RFC 2833

Tom-PT Taylor taylor at NORTELNETWORKS.COM
Fri May 19 14:16:17 EDT 2000

A couple of comments.  I'll snip out parts so it doesn't get too long.

At 07:17 AM 5/18/00 -0500, Tom-PT Taylor wrote:

>Thanks for your quick read.  Comments below.  I am copying the SG 16 list
>so they can comment too.  The original document Chip commented on is Osaka
> >Notification to ITU-T Study Group 16 shall be by ...
>This seems incomplete. :-)
>I would assume that notification to SG16 will be similar to that for
>Megaco  (i.e., email to the SG16 chair or to the SG16 mail list).
>Please keep in mind that SG16 has two email lists.  An official one
>from  that noone seems to use and an unofficial one hosted by
>  that is used by everybody.  [PTT]   From a technical/legal
>point of view, SG16 has two choices: the responsible Rapporteur(s) or the
>Chair.  Definitely not the list.  Anyway, it's for them to
>say. >Notification to the IETF Megaco Working Group may be by E-mail to
>its Chair,  >but is preferably by E-mail to the Working Group E-mail
>list.  Copies of all  >notifications to Megaco or from Megaco shall be
>sent to the ISOC Vice  >President of Standards, in accordance with
>procedures agreed between ISOC  >and the ITU-T.
>What are these procedures?   Please describe the procedures or provide
>a  reference.  [PTT]   I think they are described fully in Recommendation
I believe A.5 only discusses how ITU can reference IETF RFCs.  It doesn't
define communication procedures that I know of.  As long as notification to
ISOC VP-Standards is in parallel with working group notification it
shouldn't be too much of an impediment.

> >Modes Of Cooperation  >  >This agreement foresees three modes of
> cooperation: "Joint Development",  >"Formal Comment", and "Informal
> Comment".  These are defined as follows.
>    >In "Formal Comment" mode, development of the standard is the task of
> a  >single party to this agreement (the "initiating party") up to the
> point of  >formal progression of the standard.  This point is reached in
> the ITU-T when  >the document has been determined.  It is reached in the
> IETF when Working  >Group Last Call is announced.  At that point, the
> document shall be  >forwarded to the other organization(s) for
> comment.  The initiating party  >agrees to allow the other
> organization(s) sufficient time to complete a  >formal process of
> comment  [people may want this spelled out] before the  >initiating party
> completes its own process of formal review, and agrees to  >take
> the  comments of the other organization(s) into account in
> determining  >the final contents of the document concerned.  ***The
> parties to this  >agreement agree that subsequent to determination or
> commencement of Working  >Group Last Call respectively, the only changes
> permitted in the document  >will be to provide clarifications and
> corrections of errors.***
>To meet the general case, the technical comments from the non-ITU
>group  MUST be taken into account before determination to apply the
>approval  process.  The above wording is a little vague on this.  In the
>second  sentence, perhaps you should change "has been determined" to "is
>ready to  be determined."  [PTT]   I had in mind that WG Last Call is
>begun only when design seems to be stable.  Hence the proper sequence is
>determination followed by WG Last Call.  Neither should happen before all
>requirements have been understood and accounted for.  One reason for
>putting Last Call after determination is to meet a concern on the ITU-T
>side that the IETF might never converge if they weren't faced with the
>sort of finite time limits the ITU process provides.
I'm sorry they feel that way.  However, "determination" doesn't happen
until the Rapporteur (usually with consensus of the group) determines the
text is stable enough to have the approval process applied to
it.  Similarly, WG Last Call doesn't happen until the WG chair determines
the text is stable enough to start the IETF approval process.  The main
difference is that in ITU "determination" happens at a WP (not
Rapporteur's) meeting and in IETF it can happen via email.  In either case,
the Rapporteur and WG chair have to coordinate their activities.

As has occured in several cases, an I-D may go through a couple of cycles
of WG Last Call before it goes to IETF Last Call.  In my view, WG Last Call
should occur before determination.  It might be feasible that IETF Last
Call happen after determination (i.e., when the white contribution is
submitted to ITU).  there is still the issue of Resolution 1 recommending
only editorial changes (no technical changes other than errata) be made
after determination.  Theoretically, this would preclude IETF last call
from introducing any changes to the document.  As has been seen, SG16 isn't
too worried with that last concern.

In any case, the new ITU approval process will probably apply before this
agreement really takes effect.  But this agreement should be readily

>A point that came up in discussion here: final decision for "Formal
>Comment" documents should be that of the initiating party, rather than
>mutual consent. Also, is the IESG/IETF going to agree that only
>clarifications and  corrections of errors will be allowed in IETF Last
>Call and IESG  review?  The interpretation of "clarifications and
>corrections of errors."  can deviate widely between groups.  [PTT]   It
>has worked in the current cycle.  Anyway, I'm sure they'll put their own
>imprint on this before it gets put into play, so they can speak for themselves.
It depends on what you mean by the "current cycle".  I assume you mean
after Geneva.
If you can come up with a way to get to now without repeating 10/99 - 2/00
it would be good.
>If there is going to be any comment or agreement between the groups,
>the  distribution of the documentation and procedure for providing
>comments has  to be available to all the IETF.  Open availability of
>documentation should be a non-negotiable term of the  agreement.  This
>should be made clear for each mode.
>For IETF this is easy.  For ITU, this is no different than just sending
>an  email to the IETF mail list saying that they are working on a
>draft  Recommendation and if you are an ITU Sector Member you can
>comment.  [PTT]   You're right on this last.  It may be that it's not
>worth mentioning the "Informal Comment" mode.  The key point is not to
>require the ITU to make any document which refers to H.248 freely
>available -- only those which contribute to the evolution of the protocol
I think it is probably important to keep.  Perhaps you are thinking of
Notification.  In this case, the ITU SG would notify the IETF that an
overlapping topic is under discussion and those participants in IETF who
are also Sector Members could then choose to particpate in ITU (or
not).  For example, something like this would have been beneficial in
SG13's work on I.ipatm.
If SG16 wants comment, they need to provide the documentation (which they do).
BTW, SG16 is not a real problem here since they have been progressive
enough to open up their documentation to the public.  They should be a role
model for other ITU SGs in this regard.

Chip Sharp                 CTO Consulting Engineering
Cisco Systems
Reality - Love it or Leave it.

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

More information about the sg16-avd mailing list