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

[Colin Perkins <[e-mail]>]

> On 20 Feb 2018, at 15:25, Ali C. Begen <[e-mail]> wrote:
> 
> 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.

That matches my understanding.

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

They’re NTP timestamps. If I understand correctly, NTP is tied to UTC.

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

They’re MIME media type parameters, and therefore my definition semicolon separated. If that’s not clear, we should specify it.

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

Yes.

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

For RTP, they don’t need to be registered since the fmt value is the RTP payload type (see also RFC 3555).

For udp, you register the MIME media type following RFC 4288.

For anything else, you do as specified in the RFC that defines that “proto” value. 

This seems clearly specified.

> 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.
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic



-- 
Colin Perkins
https://csperkins.org/