Re: [MMUSIC] draft-ietf-mmusic-sdp-mux-attributes-06 review

[Ari Keränen <[e-mail]>]

Hi Suhas,

That's better, thanks!

There might be a word missing though. I'd suggest, e.g.:
s/and thus carried/and are thus carried/


Cheers,
Ari

On 16/01/15 05:05, Suhas Nandakumar wrote:
> Thanks Ari for the review. Regarding the abstract, please let me know if
> the below introductory paragraph captures what is needed.
>
> "The Session Description Protocol (SDP) provides mechanisms to
>         describe attributes of multimedia sessions and of individual media
>         streams (e.g., Real-time Transport Protocol (RTP) sessions) within a
>         multimedia session. Typically media associated with individual
>         media descriptions ("m=" lines) represent separate RTP Sessions
>         and thus carried over individual underlying transport layer flows.
>         For scenarios
>         where SDP is used to negotiate the usage of single 5-tuple for
>         sending and receiving media associated with multiple media
> descriptions, it is required to understand the semantic implications of
> the  attributes associated with the RTP Media Streams multiplexed over a
>         single underlying transport layer flow"
>
> Thanks
> Suhas
>
>
> On Wed, Jan 14, 2015 at 5:25 AM, Ari Keränen <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Hi Suhas,
>
>     I have couple of more comments on the latest draft's bundle references.
>
>     The Bundle draft is currently listed as Informative reference, but
>     considering how Bundle is referenced and used in this document, I
>     think it should be a Normative reference instead.
>
>     Also, in general the Abstract should not contain references (unless
>     they are completely defined within the Abstract; see [1] for
>     details), so I would suggest replacing the Bundle draft reference in
>     the Abstract with some more general text about the Bundling feature.
>
>     Finally, I noticed that the latest version has many of the MUSTs and
>     MAYs changed to (non-RFC2119) lower case versions. What was the
>     reason for this? For some I see why, e.g., in "This may or may not
>     work [...]", but for some, e.g. "multiplexing must not be performed
>     even in this alternate scenario" RFC2119 language seems more
>     appropriate.
>
>
>     Cheers,
>     Ari
>
>     [1] http://www.ietf.org/ietf-ftp/__1id-guidelines.txt
>     <http://www.ietf.org/ietf-ftp/1id-guidelines.txt>
>
>