Re: [Fecframe] Pete Resnick's Discuss on draft-ietf-fecframe-rtp-raptor-05: (withDISCUSS and COMMENT)

[Thomas Stockhammer <[e-mail]>]

Dave, Pete,

I have uploaded a new version.

http://www.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-raptor-07.txt

Inline how the comments had been addressed:

> In section 10.3, please consider explaining when you would not follow
> "SHOULD be sent in a separate RTP session" - give guidance on when a
> single
> session is appropriate. Likewise, why is using CNAME to associate the
> sessions
> only a MAY? Unless there are strong reasons to define and use an
> alternative
> mechanism, this would be better off as a MUST.

[T] This has been changed as follows:
"If the repair RTP session is sent in a separate RTP session the two sessions MUST be associated using RTCP CNAME."

The association of repair and source RTP session is not part of the RTCP usage, so this recommendation is removed.
The choice of whether running this in the same session of in separate session is really deployment specific. 
However, if they are in different sessions, then for association the usage of the same RTCP CNAME is mandated.


> and update the document to not use RFC2119 langauge in the template
> section.

[T] This addresses the DISCUSS from Pete. The new text does not include any RFC2119 language.
"The default value of this parameter (when it does not appear explicitly) is 'A'."

Please let me know if this covers all the remaining concerns.

Thanks

Thomas

> 
> Once we hear from avtcore, you can cut a new revision.
> 
> thanks,
> dbh
> 
> 
>> -----Original Message-----
>> From: David Harrington [mailto:[e-mail]] 
>> Sent: Monday, December 05, 2011 10:49 PM
>> To: 'Thomas Stockhammer'
>> Cc: [e-mail]
>> Subject: RE: Pete Resnick's Discuss on 
>> draft-ietf-fecframe-rtp-raptor-05: (withDISCUSS and COMMENT)
>> 
>> Hi,
>> 
>> Please change the text in the template sections to not use RFC2119
>> language. 
>> Pete suggests:
>> "The default value of this parameter (when it does not appear
>> explicitly) is 'A'."
>> I think that is sufficiently clear.
>> 
>> You can make sure the text elsewhere shows this "A" default is a
>> normative requirement, using rfc2119 language.
>> 
>> Please publish another revision with this fix, so we can move
> forward.
>> 
>> I have asked Robert to check the current revision and clear if he is
>> satisfied; you might want to wait a couple days to see if he wants
> any
>> further changes made.
>> 
>> Thanks,
>> David Harrington
>> Director, IETF Transport Area
>> [e-mail] (preferred for ietf)
>> [e-mail]
>> [phone] (cell)
>> 
>>> -----Original Message-----
>>> From: Thomas Stockhammer [mailto:[e-mail]] 
>>> Sent: Monday, November 28, 2011 1:12 AM
>>> To: Pete Resnick
>>> Cc: [e-mail]; 
>>> [e-mail]; David Harrington; 'The IESG'
>>> Subject: Re: Pete Resnick's Discuss on 
>>> draft-ietf-fecframe-rtp-raptor-05: (withDISCUSS and COMMENT)
>>> 
>>> Pete,
>>> 
>>> inline comments on the comments resolution …
>>> 
>>>>>>>> Specific problems:
>>>>>>>> 
>>>>>>>> Section 3: "MAY" is not appropriate here. You're not
> defining
>>>>>>>> a protocol option; you're saying that repair packets can be
>>>>>>>> generated.
>>>>>>>> 
>>>>> [T] To avoid the may here it says now:
>>>>> "The Raptor and RaptorQ codes are efficient block-based 
>>> fountain codes, meaning that from any group of source packets 
>>> (or 'source block') an one can generate an arbitrary number 
>>> of repair packets."
>>>>> 
>>>> 
>>>> Works for me (though there seems to be a typo in 
>>> 
>>> [T] Thanks! Typo fixed!
>>> 
>>>> 
>>>>>> I must say that, try though I might, I can't understand 
>>> how an implementer might choose to decide that a marker bit 
>>> of 0 means last packet and 1 means otherwise. That one sounds 
>>> like a definition of the bit, not anything that can be an 
>>> implementation choice that requires a 2119 requirement.
>>>>>> 
>>>>> [T] I understand the comment from Pete that this may also 
>>> be interpreted as a definition. But still it is expected that 
>>> the bit is set accordingly and the implementation can write 
>>> code to identify the last packet in the source block and set 
>>> the marker bit to 1. So I would prefer to stick with the SHALL
> here.
>>>>> 
>>>> 
>>>> I still disagree, but it sounds like I'm "in the rough" 
>>> part of the consensus. :-)
>>> 
>>> [T] See other discussion, I am still trying to understand the 
>>> exact issue.
>>> 
>>>>> I don't think you can use this payload format for anything 
>>> different than Raptor and RaptorQ, at least this is not 
>>> considered. It is also the case that different media codecs 
>>> generally each defines different payload formats unless the 
>>> payload formats are generic. I would assume the same applies 
>>> here and this is mostly because we know that it works with 
>>> Raptor and RaptorQ, but we do not know if it works with 
>>> anything different.
>>>>> 
>>>>> I left the second "SHALL" because this is what an 
>>> implementor is expected to do.  To create an RTP payload that 
>>> contains FEC Repair Payloads.
>>>>> 
>>>> 
>>>> (*Shrug*) I don't think it's necessary.
>>> 
>>> [T] Still not sure what would be the appropriate text then? 
>>> Is it not mandated that the implementor implements the 
>>> normative parts of the two docs?
>>> 
>>> Thomas
>>> 
>>> ---
>>> Dr. Thomas Stockhammer (CEO) || [e-mail] || phone 
>>> [phone] || cell [phone] || 
>>> http://www.nomor-research.com
>>> Nomor Research GmbH  -  Sitz der Gesellschaft: München - 
>>> Registergericht: München, HRB 165856 – Umsatzsteuer-ID: 
>>> DE238047637 - Geschäftsführer: Dr. Thomas Stockhammer, Dr. 
>>> Ingo Viering.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 

---
Dr. Thomas Stockhammer (CEO) || [e-mail] || phone [phone] || cell [phone] || http://www.nomor-research.com
Nomor Research GmbH  -  Sitz der Gesellschaft: München - Registergericht: München, HRB 165856 – Umsatzsteuer-ID: DE238047637 - Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering.