[MMUSIC] AD Evaluation of draft-ietf-mmusic-sdp-mux-attributes-12

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

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.

-4.2: I recommend choosing a category name that is not a 2119 keyword.
   Maybe something like "not mux-able" or "unsafe"?

-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."

-4.6:
  >"This in turn MAY place constraints on what constitutes a valid
    configuration from
    a multiplexing point of view, e.g. because some attributes MUST be
    IDENTICAL (see Section 14 for further details)."

    It seems like it would make sense to state that last sentence
    more strongly. Does it make sense to say something along the lines
    of "inherited attributes MUST be coherent."?

-4.9: "For the purposes of implementations it is
    advised to consider "NOT RECOMMENDED" as the category when
    multiplexing these attributes."

    So why not have them in the NOT RECOMMENDED category, with
    an explanation that they have not been sufficiently analyzed?
    Or if you want to keep a separate category, you can say something
    like :"Attributes in the TBD category SHOULD NOT be multiplexed."

-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.)

-5.14
   Do you really expect to see such an "early mechanism" be
   multiplexed?

-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?

-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.

   -Note: As stated, this is untrue. MSRP has the built in ability
   to share multiple sessions across the same transport connection.
   But I think your point is that there is no specification about
   how to demux MSRP from among _other_ protocols.

   The MUST in the last sentence does not seem appropriate. You can't
   really create a 2119 level requirement for people to do work in
   the future. I suggest s/"MUST be revisited"/"could be revisited"

-5.28: Same comments as for 5.26.

- 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”?

-5.40:
   I'm surprised that the comedia attributes are not "transport"

-5.42:
   See previous comments about MUST level requirements for
   doing future work. (I think this recurs for some or all TBD
   sections.)

-5.45:
   6193 is an ISE stream RFC. Does anyone actually use
   in a context where muxing matters?

- 5.57:
   See comments from 5.26

-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?"
   - 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.

-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?

-16:
   - Do the assumptions for things like “fingerprint” and the zrtp
     hash not have security considerations since they force multiple
     media streams to share the same security associations?
     (Maybe that is covered by bundle?)
   - 2nd paragraph: There are more than one srtp keying mechanism—is
     this assumed true for all of them?



# Editorial #

- xml2rfc reports some outdated references. Are those intentional?

- The abstract is more detailed than needed. The point is to describe 
the
purpose of the draft. The second paragraph pretty much accomplishes 
that.

- Please include table numbers.

- 1:
   - First paragraph:
   s/"This would for e.g."/This would, for example,"
   s/"has made necessary to understand"/"has made it necessary to 
understand"
   - 2nd paragraph:
   "Generic future-proof framework" - This seems excessive--can we just 
call
   it a framework?

-3:
     - 1st paragraph, first sentence: Convoluted sentence. Can it be
     simplified?

-4:
     - first and second bullet example lists are each missing "and".

-4.2, first paragraph: Sentence fragment. (same for several category
   descriptions.)

-4.4, first sentence: Spurious comma.

-4.6, last paragraph: "In the above example, the category IDENTICAL is
    inherited for the cpar encapsulated rtcp-mux attribute."

    "For" doesn't seem like the right proposition. Is the category
    inherited "from" the cpar? "by" the cpar?

-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.

-5.4, note: "... due to inability in meeting
    the right resource reservations requested."

    I can't parse that clause. Does it mean "inability to meet the
    resource reservation request"? "Inability to determine the correct
    resource reservation request"?

-5.8, last paragraph:
   - "None of this is standardized yet and it wouldn’t work
   as explained. "

   Does this mean that it has been explained why it wouldn't work?
   Or do you mean the way it is explained wouldn't work?

-5.9:
   -s/"[RFC6773] document specifies"/"[RFC6773] specifies"
   - last paragraph: s/"can or cannot"/"may or may not"

-5.13, table:
   "Specific RTP extension document MUST be referred"

   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"?

-5.27, table: If the "MUST be globally unique" requirement refers to
   and existing requirment from 4583, please avoid 2119 language.

-5.55: "... to be referred ..."
   I suggest "Refer to...."

-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?)

-14.2.1, last paragraph:
   Do I understand this correctly to mean that the answerer can
   always fall back to a “common-to-all” config even if the offerer
   offered additional independent configs?

-14.3:
   s/"...extends capability..."/"...extends the capability..."

-14.3.1: "which MUST be followed here as well."
   If bundle-negotiation already requires identical pt values,
   isn’t this MUST redundant to that one?

14.3.2:
   I suspect that first MAY is a statement of fact, not a new
   requirement.

-15, paragraph starting with "The IANA is requested to...":
   This sentence seems to belong with the next paragraph.