[MMUSIC] zrtp-hash (was Re: AD Evaluation of draft-ietf-mmusic-sdp-mux-attributes-12)

["Ben Campbell" <[e-mail]>]

Hi,

As promised, here's more on my concern about zrtp-hash in 
draft-ietf-mmusic-sdp-mux-attributes:

I think you need to describe the assumptions about what it means to 
multiplex zrtp. Am I correct to assume that the draft assumes that there 
is only one zrtp session in a transport flow, with a single zrtp 
handshake? And that all of the bundled m=lines represent media that is 
part of that zrtp association? (That is, you never mux distinct zrtp 
associations, or zrtp and dtls-srtp?)

If the answer is yes, then "transport" seems to make sense.

But is zrtp demuxing really well defined enough to keep this out of the 
"NOT RECOMMENDED" category? I'm not sure it meets the bundle requirement 
for a public spec on how to demux it. One might infer that from two 
public specs (zrtp and 5764), but IIUC, the guidance proposed in 
draft-ietf-avtcore-rfc5764-mux-fixes would cause a zrtp messages to be 
dropped, since its first byte would not match any of the demux rules. 
Or, if zrtp-hash is allowed, does mux-fixes need to change?

What am I missing?

Thanks!

Ben.


On 20 May 2016, at 18:07, Ben Campbell wrote:

> Apologies for my slow response. The last month has been a perfect 
> storm of productivity killers. I'm digging out of the backlog now. 
> Comments inline, with sections that appear resolved removed.
>
> There is one issue (zrtp-hash) where I will start a separate thread 
> shortly.
>
> Thanks!
>
> Ben.
>
> On 20 Apr 2016, at 1:00, Suhas Nandakumar wrote:
>
>> Hello Ben
>>
>>  Sorry for the delay in responding. Many thanks for the detailed 
>> review.
>>
>>  Please find my responses inline (marked by [Suhas]).
>>
>> Cheers
>> Suhas
>>
>> On Fri, Feb 19, 2016 at 2:28 PM, Ben Campbell <[e-mail]> 
>> wrote:
>>
>>> Hi,
>>>
>>> Here is my AD evaluation of draft-ietf-mmusic-sdp-mux-attributes-12. 
>>> I
>>> would like at least the substantive
>>> section to be discussed before going to IETF last call.
>>>
>>> Thanks!
>>>
>>> Ben.
>>>
>>> ----------
>>>
>>> # Substantive #
>>>
>>> - This is very long and detailed. Are the authors and chairs 
>>> comfortable
>>> that all sections have had sufficient review?
>>>
>>> -4.0: It would be helpful to add a paragraph describing how these 
>>> semantic
>>> groupings map to the categories.
>>>
>>
>> [Suhas] The semantic groupings were added as a informal reference and 
>> they
>> don't really interact with the categories as such.
>
> So I have to wonder why we have the groupings. But I guess at this 
> point in the process, it's not worth changing that.
>
>>
>> Does the following rephrasing work
>>
>> *"Attributes in an SDP session description can be defined at the
>> **session-level
>> or  media-level or  source-level. Informally, there are various 
>> semantic
>> grouping for these attributes. One such grouping could be as noted 
>> below:*
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *   o  Attributes related to media content such as media type, 
>> encoding
>>      schemes, payload types.   o  Attributes specifying media 
>> transport
>> characteristics like RTP/RTP      Control Protocol (RTCP) port 
>> numbers,
>> network addresses, QOS.   o  Metadata description attributes 
>> capturing
>> session timing and      origin information.   o  Attributes 
>> establishing
>> relationships between media descriptions      such as grouping 
>> framework
>> [RFC5888 <https://tools.ietf.org/html/rfc5888>]The proposed framework
>> defines categories for the SDP attributes under multiplexing and 
>> assigns
>> each SDP attribute to an appropriate multiplexing category.*
>>
>> *Since the multiplexing categories defined in this specification are
>> independent of any informal semantic grouping of the SDP attributes, 
>> the
>> categorizations assigned against each attribute  MUST be considered 
>> as
>> normative assignments under multiplexing. "*
>
> All fine, except the last sentence is pretty meta--it uses normative 
> language to talk about normative language ("MUST be considered 
> normative"). I'm not entirely sure what you intend there, but how 
> about something to the effect of "... the categorizations assigned 
> against each attribute are normative."
>
>>
>>
>>
>>> -4.2: I recommend choosing a category name that is not a 2119 
>>> keyword.
>>>   Maybe something like "not mux-able" or "unsafe"?
>>>
>>
>> [Suhas]
>>
>> Initially that category was called "BAD" as in
>>
>> https://datatracker.ietf.org/doc/draft-nandakumar-mmusic-sdp-mux-attributes/01/
>>
>> However we ended upon NOT RECOMMENDED since “BAD” was a bad 
>> choice :-)
>>
>> Either of the following options seems fine to me
>>
>>    1.
>>
>>    NOT-RECOMMENDED [ we use hyphen separated multi word format in 
>> other
>>    category names]
>>    2. UNSAFE
>
> I lean towards unsafe. OTOH, NOT-RECOMMENDED makes sense if you intend 
> the category name to mean "NOT RECOMMENDED" in the 2119 sense.
>
>>
>>
>>
>>
>>>
>>> -4.3: Please don't use a 2119 keyword as part of the definition
>>> of a category. This creates sort of a circular dependency; that is
>>> attributes are in this category because they MUST be identical; but 
>>> they
>>> MUST be identical because they are in this category. I suggest 
>>> describing
>>> the category descriptively, and adding a separate sentence to say
>>> "Attributes
>>> in the IDENTICAL category MUST be identical across all media 
>>> descriptions."
>>>
>>
>>
>> [Suhas]. I have removed the usage of word identical from the 
>> definition as
>> below. Please let me know if this works.
>>
>>
>> Category: IDENTICAL
>>
>> Attributes  and their associated values (if present) in the IDENTICAL
>> category MUST be repeated across all the media descriptions under
>> multiplexing.
>>
>
> Okay.
>
> [...]
>
>>
>>
>>
>>> -5.8 and 5.9:
>>>     The last paragraph of 5.8 seems redundant with section 5.9.
>>>
>>> -5.8, last paragraph:
>>>
>>>     "Hence multiplexing MUST NOT be performed even in this
>>>     alternate scenario." seems to contradict the category selection 
>>> of
>>>     "NOT RECOMMENDED" (but see previous comment about not using 2119
>>>     keywords in a category title.)
>>>
>>>
>> [Suhas] The idea here is to not perform multiplexing and hence the 
>> category
>> of NOT RECOMMENDED assigned. I can update this once we finalize on 
>> the
>> right naming for "NOT RECOMMENDED"
>
> This argues for the "UNSAFE" name, since the actual normative guidance 
> is stronger than "NOT RECOMMENDED". (Unless you want a "MUST NOT" name 
> :-)  )
>
>>
>>
>>
>>> -5.24, last paragraph: "it is recommended to consult the
>>>   document defining the attribute."
>>>
>>>   I assume one should _always_ refer to the specification of
>>>   an SDP attribute before trying to mux it. But that doc is
>>>   not going to explain muxing issues, is it?
>>>
>>>
>> [Suhas]
>>
>> Since cparmin/cparmax can define numerical values/ranges
>>
>> for any of b= or a= attributes (identified via cpar), there is no 
>> easy way
>> to assign a multiplexing category unless one knows what cpar is being
>>
>> used and the assignned numerical values to each of cparmin/cparmax 
>> mean.
>> Thus the category SPECIAL has been assigned as a recommendation for 
>> the
>> implementor to consult the spec that defines a particular usage of 
>> cpar,
>> cparmin and cparmax combination to really see what’s going on.
>>
>> This is very similar to extmap or RTCP Application feedback message 
>> type
>>
>> How about following rephrasing
>>
>>
>> *"The attributes (a=cparmin and a=cparmax) define minimum and maximum
>> numerical values associated with the attributes described in a=cpar. 
>> Since
>> a cpar attribute can either define*
>>
>> *“b=” attribute or any “a=” attribute,  the multiplexing 
>> category *
>>
>> *depends on actual attribute being encapsulated and the implications 
>> of the
>> numerical values assigned. Hence it is recommended to consult the
>> specification defining the the attributes (cparmin/cparmax) to 
>> further
>> analyze their behavior under multiplexing."*
>
> That works for me.
>
>>
>>
>>
>>> -5.26:
>>>   -"Support of this extension is OPTIONAL."
>>>   Please don't use 2119 keywords to describe existing requirements
>>>   from other docs, unless in direct quotes.
>>>
>>>
>>
>> [Suhas] This sentence is taken directly from RFC6714. (
>> https://tools.ietf.org/html/rfc6714)
>
> Sure, but it's not attributed as a quote. I suggest something to the 
> effect of "This is an optional extension according to [RFC6714]", " 
> [RFC6714] states that this extension is 'OPTIONAL'",  or even the 
> exact same language as currently in the draft, but without the 
> capitalized OPTIONAL.
>
> [...]
>
>>
>>
>>
>>> - 5.39:
>>>   I’m not a zrtp expert, but it seems like it might
>>>   be more complicated than this. Section 8 of 6189 says
>>>   “The a=zrtp-hash attribute  can only be included in the
>>>   SDP at the media level since Hello messages sent in
>>>   different media streams will have unique hashes.”
>>>   I wonder if this shouldn't be “identical”?
>>>
>>>
>> [Suhas] The category TRANSPORT is the appropriate assignment. This 
>> spec
>> assigns category for these attributes over the multiplexed transport.
>>
>> So, if we have 3 m= lines each with one zrtp-hash and all bundled.
>>
>> The zrtp-hash selected must correspond to the m=line that is selected 
>> for
>> BUNDLE once the O/A negotiation completes. Thus the category 
>> TRANSPORT.
>>
>>
>
> I _think_ you are right, but there may be an interaction here that can 
> break things I will think about that more, and respond to this issue 
> is a separate thread.
>
>>
>>
>>
>>>
>>> -5.45:
>>>   6193 is an ISE stream RFC. Does anyone actually use
>>>   in a context where muxing matters?
>>>
>>
>> [Suhas] . I doubt it. Do you recommend as NOT-RECOMMENDED instead.
>
> That seems reasonable, unless  you know of good reasons otherwise.
>
>>>
>>> -15.1:
>>>   - Is there no need for a spec for any newly registered categories?
>>>   - 2nd to last paragraph: "This seems vague for a MUST. Do you 
>>> expect
>>>     the registration of a new category to change the categories
>>>     already assigned to existing SDP parameters? Is it possible
>>>     that a new category only applies to some new SDP parameters?"
>>>
>>
>> [Suhas] The following 2 paragraphs are supposed to mean that new
>> multiplexing categories require new registrations via a spec and
>> applicability of the new category to new SDP attributes and possibly
>> existing SDP attributes ( if the new category makes more sense). What 
>> would
>> be a better framing to capture the intent ?
>>
>> "*Further entries can be registered on a first-come first-serve 
>> basis. Each
>> registration needs to indicate the multiplexing category value to be 
>> added
>> to the "Multiplexing Categories" subregistry as defined in this 
>> section.*
>>
>> *Such a registration MUST also indicate the applicability of the 
>> newly
>> defined multiplexing category value to various subregistries defined 
>> at
>> "Session Description Protocol (SDP) Parameters".*
>
> That works for me.
>
>>
>>
>>>   - Last paragraph: 4566 procedures apply to what? The text just 
>>> said
>>>     new categories are first-come-first server. I don’t think
>>>     4566 set policies for how to change mux categories.
>>>
>>
>> [Suhas] Agreed. I prefer removing this line altogether. Please let me 
>> know
>>
>
> I agree.
>
>>>
>>> -15.2.1:
>>>   How do you expect the table to look after adding this RFC to the
>>>   references? Will this RFC be added to the entries in the MUX
>>>   column?
>>>
>>
>> [Suhas] The plan was to add the reference to this RFC in the 
>> "Reference
>> Column"
>
> Okay.
>
> [...]
>
>
>>
>>>
>>>
>>> # Editorial #
>>>
>>
>>> - The abstract is more detailed than needed. The point is to 
>>> describe the
>>> purpose of the draft. The second paragraph pretty much accomplishes 
>>> that.
>>>
>>>
>> [Suhas] How do this rephrase look
>>
>> “The purpose of this specification is to provide a framework for 
>> analyzing
>> the multiplexing characteristics of SDP attributes when SDP is used 
>> to
>> negotiate the usage of single 5-tuple for sending and receiving media
>> associated with multiple media descriptions,. This specification also
>> categorizes the existing SDP attributes based on the framework 
>> described
>> herein.”
>>
>
> That works for me.
>
> [...]
>
>>
>>
>>>
>>> -5 and subsections: Is there any method to the ordering? They aren't
>>>    in RFC order. It might make sense to group by the nature of the
>>>    attributes, but if that is the case here it's not explained.
>>>
>>>
>> [Suhas] These are not ordered as of today. I can order the 5.X 
>> subsections
>> by RFC order, if needed.
>
> Unordered is also okay. I was just wondering if there was a logic that 
> should be mentioned.
>
>
> [...]
>
>>
>>
>>>
>>> -5.13, table:
>>>   "Specific RTP extension document MUST be referred"
>>>
>>>
>> [Suhas] The idea was to mean that , one should refer to the 
>> specification
>> that defines a specific RTP extension in order to understand the
>> multiplexing behavior.
>>
>> Would the following rephrasing help instead
>>
>> "Refer to the document defining specific RTP Extension"
>>
>>
>
> Yes, thanks.
>
>>
>>>   I don’t understand what that means. If you mean to
>>>    say “refer to specific document”, that shouldn’t use MUST.
>>>
>>> -5.22, table: "document needs to be referred" (several repetitions)
>>>   I'm not sure what this means. Should it say "Refer to the
>>>   specific document"?
>>>
>>>
>> Similarly as above, would this reprhasing help
>>
>> "Refer to the document defining specific FEC Scheme
>>
>>
>
> Similarly as above, Yes, thanks. :-)
>
>>
>>>
>>> -6.3: "not clearly defined offer/answer usage"
>>>   I'm not sure what is meant here. (Also, why is this not TBD or NOT
>>>   RECOMMENDED?)
>>>
>>
>> [Suhas] Since RFC3890 b=TIAS is not defined keeping O/A in mind, 
>> either the
>> BUNDLE spec or this spec cannot define its mux behavior. This is due 
>> to
>> applicability of these specs under SD{ O/A usages alone.
>>
>> I can rephrase the above as
>> "not defined under SDP Offer/Answer usage"
>
> WFM, thanks.
>
> [...]