[AVT] Re: Last Call: 'RTP Payload for DTMF Digits, Telephony ones and T elephony Signals' to Proposed Standard

["Tom-PT Taylor" <[e-mail]>]

OK, I do appreciate that not progressing 2833biscas at the same time as 
the others has caused problems which must be remedied. The solution is 
perhaps to have a section in the document that describes the changes 
from RFC 2833. This and the abstract would both indicate the disposition 
of the RFC 2833 code points, in detail in the body if you wish. That 
suggests an appendix.

Sasha Vainshtein wrote:
> Hi Tom,
> 
> I do not think that  the "original intent of splitting the document" is more
> relevant than backward
> compatibility issues that would result from IMPLICITLY reclaiming lots of
> codepoints previously
> allocated in a Standards Track RFC.
> 
> "Not hearing" about other codepoints allocated in 2833 does not, IMHO, say
> much. One of the
> purposes of the IESG LC (as I understand it) is seeking feedback from beyond
> the scope of
> the WG that has adopted the draft. Nor is the space we are discussing fully
> populated
> (only about 75%); and I assume that the demand is not high (otherwise you
> would definitely
> hear about more codepoints :-) 
> 
> The base spec stands, IMHO on its own merits because it introduces new
> mechanisms
> and behaviors (or so you say in the abstract). And establishing a new
> registry is the right and 
> proper thing to do, too. 
> 
> On the other hand, I do not see how adding an explicit reference to a pair
> of WG documents 
> in different stages of progress to the IANA Considerations section of the
> base spec would nullify it. 
> You could, if you wish, add a caveat stating something like: 
> 
> "At the time when this spec is developed, the authors are aware (or,
> actually, are developing :-) 
> the following documents allocating additional codepoints in this registry"  
> 
> and proceed with briefly describing them. The references could be
> informative, but IANA could 
> act (or prepare to act)  on them once the base spec is approved.
> 
> I must repeat that I see such a reference as an absolute minimum required
> for approval of the
> base spec.
> 
> Hopefully this clarifies my position.
> 
> Regards,
>                            Sasha
> 
>> -----Original Message-----
>> From: Tom-PT Taylor [mailto:[e-mail]]
>> Sent: Tuesday, May 02, 2006 5:36 PM
>> To: Sasha Vainshtein
>> Cc: 'Magnus Westerlund'; '[e-mail]'; Israel Sasson; 
>> '[e-mail]'; '[e-mail]'; Alik 
>> Shimelmits; Tom-PT Taylor
>> Subject: Re: Last Call: 'RTP Payload for DTMF Digits, 
>> Telephony ones and T elephony Signals' to Proposed Standard
>>
>>
>> Sorry to cause you alarm, but mentioning the other documents 
>> by name in 
>> the base specification would nullify the reason for splitting the 
>> document in the first place. The whole point was to allow 
>> requests for 
>> new event code points to stand on their own merits while preserving 
>> backward compatibility to the extent to which 2833 seems to have been 
>> implemented. We dropped the whole set of telephone line signalling 
>> events, for instance, because no one spoke up for them. 
>> Nevertheless, if 
>> someone sees a need for them in the future, they are free to 
>> introduce a 
>> new draft.
>>
>> As I think about it, it might be possible to add something in the 
>> abstract, which talks about changes from RFC 2833.
>>
>> As for the current status of 2833biscas: I gave it lower priority 
>> because I was unaware of any reference to these code points 
>> outside of 
>> some PacketCable documentation. The missing piece of work is 
>> a careful 
>> review of congestion implications. Otherwise, there has been 
>> no comment 
>> on this document for nearly a year. Given your document 
>> dependency, I'd 
>> better finish my piece of the work and ask for WGLC.
>>
>> Sasha Vainshtein wrote:
>>> Hi Magnus,
>>> Thank you for a prompt and informative response.
>>>
>>> I must admit that I did not look up
>>>
>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833bisc
> as-01.txt.
>> This is because it was neither mentioned in the IESG Last Call
> announcement
>> nor referenced in the core
>> 2833bis draft.
>>
>> The 2833bisdata and 2833biscas drafts seem to fill in most of the gaps in
>> the code point space left
>> by the core draft. In particular, my concern about code points for the
> ABCD
>> signaling states is 
>> adequately addressed by the 2833biscas draft.
>>
>> The problem would not arise if the all the 2833bis drafts were treated by
>> the IESG as a single block.
>> After checking with the I-D tracker I see that this is not the case, as
> the
>> 2833biscas draft has not
>> been sent to the IESG yet. 
>>
>> I understand that adding the 2833biscas draft to the block now may be
>> problematic for the authors 
>> and/or the WG.
>>
>> As a minimum, may I suggest explicitly referencing the 2 companion drafts
> in
>> the core 2833bis 
>> document and explaining which kinds of code points are going to be
> allocated
>> there?
>> The logical place for such an explanation would be, IMHO, in the IANA
>> Considerations section,
>> so that at least the IANA people could look up these documents and mark
> the
>> code points 
>> allocated there as "reserved" once the core document has been (hopefully,
>> successfully) 
>> processed by the IESG.
>>
>> Regards,
>>                               Sasha
>>
> ...
> 
> 
> 
> 


_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt