[MMUSIC] 4566bis open issues (from Flemming's review)

["Ali C. Begen" <[e-mail]>]

All,

The latest and greatest 4566bis draft is here:
https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-25

There are some issues raised by Flemming in his chair review, and I would like to get the list’s opinion on these.

Thanks.
-acbegen


1) Section 5.7:

   A session description MUST contain either at least one "c=" line in
   each media description or a single "c=" line at the session level.
   It MAY contain a single session-level "c=" line and additional "c="
   line(s) per media description, in which case the per-media values
   override the session-level settings for the respective media.

Comment: Multiple c= lines is only allowed for multicast, right? Can we clarify that here? 

   The slash notation for multiple addresses described above MUST NOT be
   used for IP unicast addresses.

Comment: And hence you also cannot specify more than one c= line for a unicast stream, right ?

2) Section 5.8:

   The <bandwidth> is interpreted as kilobits per second by default.

Comment: What about lower layer overhead? RFC 3550 Section 6.2 specifies that we include UDP and IP overhead, etc. but not link layer. I believe this is consistent with (old) discussions on the MMUSIC mailing list as well and think it would be useful to clarity that here.

3) Section 5.9:

   The first and second sub-fields give the start and stop times,
   respectively, for the session.  These values are the decimal
   representation of Network Time Protocol (NTP) time values in seconds
   since 1900 [RFC5905].  To convert these values to UNIX time, subtract
   decimal 2208988800.

Comment: What is the time zone ? RFC 5905 suggests it's UTC (which makes sense), however the subsequent discussion in the "time zone" adjustment field seems to (logically) contradict that, so I'm confused.

4) Section 6.4 and 6.5:

   Syntax:
         ptime-value = non-zero-int-or-real
         maxptime-value = non-zero-int-or-real

Comment: I always thought they were integeres. The text below doesn't make it clear one way or the other, which it needs to.

5) Section 6.15:

   This attribute allows parameters that are specific to a particular
   format to be conveyed in a way that SDP does not have to understand
   them.  The format must be one of the formats specified for the media.
   Format-specific parameters may be any set of parameters required to
   be conveyed by SDP and given unchanged to the media tool that will
   use this format.  At most one instance of this attribute is allowed
   for each format.

Comment: Should we say something about the general convention being a semi-colon separate list of format parameters, as shown in the example ?

6) Section 7:

   One transport that can be used to distribute session descriptions is
   the SAP.  SAP provides both encryption and authentication mechanisms,
   but due to the nature of session announcements it is likely that
   there are many occasions where the originator of a session
   announcement cannot be authenticated because the originator is
   previously unknown to the receiver of the announcement and because no
   common public key infrastructure is available.

Comment: Does SAP provide integrity protection as well?

7) Section 8.2.2:

   The "proto" field describes the transport protocol used.  This SHOULD
   reference a standards-track protocol RFC.  This memo registers three
   values: "RTP/AVP" is a reference to [RFC3550] used under the RTP
   Profile for Audio and Video Conferences with Minimal Control
   [RFC3551] running over UDP/IP, "RTP/SAVP" is a reference to the
   Secure Real-time Transport Protocol [RFC3711], and "udp" indicates an
   unspecified protocol over UDP.

Comment: Why is the existing registration to RFC3711 not used (i.e. leave out here) ?

   New transport protocols SHOULD be registered with IANA.
   Registrations MUST reference an RFC describing the protocol. Such an
   RFC MAY be Experimental or Informational, although it is preferable
   that it be Standards Track.  Registrations MUST also define the rules
   by which their "fmt" namespace is managed (see below).

Comment: We have an existing registration for udptl which references T.38. It should actually reference RFC 7345 (seems like an IANA mistake, so maybe make a note of that).

8) Section 8.2.3:

Comment: Where are these registrations to be done? The IANA instructions and actual location of the corresponding registries are unclear.

9) Section 8.2.5:

   IANA has registered the bandwidth specifiers "CT" and "AS" with
   definitions as in Section 5.8 of this memo (these definitions update
   those in [RFC4566]).

Comment: The current IANA registration points to RFC4566 and mux-attributes, yet here it says the definition in 4566bis is what matters. Something needs to change here.