[Gen-art] Gen-ART Review of draft-ietf-mmusic-sdp-new-25.txt

I was selected as General Area Review Team reviewer for this specification 
(for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Summary:

This specification is very close to ready for publication as Proposed 
Standard. Jon asked that we have mercy on this specification, but I found it 
very readable and clear in most cases. I have some suggested edits (see 
below) and tried to propose text in most cases. The biggest single nit I 
noticed was an emphasis on SAP as "commonly"/"frequently" used to distribute 
SDP - this seemed to "age" the specification.
BTW, idnits 1.82 reports "No nits found."Spencer

1.  Introduction

   This memo updates RFC 2327 [6] in the light of implementation
   experience, and adds a small number of new features.  Section 10
   outlines the changes introduced in this memo.

Spencer - (1) doesn't this specification actually replace 2327? and 3266?
(2) I'm not sure what our current practice is, but I don't mind seeing
information like this in the Abstract, as well as in the Introduction.

3.  Examples of SDP Usage

3.1  Multicast Session Announcement

   One protocol commonly used to implement such a distributed directory
   is the Session Announcement Protocol, SAP [14].  SDP provides the
   recommended session description format for such session
   announcements.

Spencer - I understand the historical context here, but I'm not sure
"commonly" is a good description, given the current state of multicast
distribution in today's internet. I may simply be reacting with slight
suprise that SAP is described before SIP and RTSP - today's implementors and
users are much more likely to use SDP in these contexts, I think.

3.4  Email and the World Wide Web

   Note that announcements of multicast sessions made only via email or
   the World Wide Web (WWW) do not have the property that the receiver
   of a session announcement can necessarily receive the session because
   the multicast sessions may be restricted in scope, and access to the
   WWW server or reception of email is possible outside this scope.
   Session announcements made using SAP do not suffer this mismatch.

Spencer - sigh. I'd strike the last sentence (see previous comments).

4.  Requirements and Recommendations

   The purpose of SDP is to convey information about media streams in
   multimedia sessions to allow the recipients of a session description
   to participate in the session.  SDP is primarily intended for use in
   an internetwork, although it is sufficiently general that it can
   describe conferences in other network environments.  Media streams
   can be many-to-many.  The times during which the session is active
   need not be continuous.

Spencer - the last sentence of this paragraph wasn't clear to me. "Sessions
may have start and stop times, so media streams need not be continuous"?

4.1  Media and Transport Information

   The semantics of this address and port depend on the media and
   transport protocol defined.  By default, this SHOULD be the remote
   address and remote port to which data is sent.  Some media types MAY
   redefine this behaviour, but this is NOT RECOMMENDED.

Spencer - This MAY seems like an emphasis MAY, not a 2119 MAY. Is it
possible to add a phrase that says "NOT RECOMMENDED because ...", so that
other protocol designers understand your concerns about this behaviour?

4.2  Timing Information

   This timing information is globally consistent, irrespective of local
   time zone or daylight saving time.

Spencer - later in the specification, you explain that timing information is
measured as NTP standard seconds since 1900. It might be nice to include
that explanation here.

4.3  Private Sessions

   It is possible to create both public sessions and private sessions.
   SDP itself does not distinguish between these: private sessions are
   typically conveyed by encrypting the session description during
   distribution.  The details of how encryption is performed are
   dependent on the mechanism used to convey SDP: mechanisms are
   currently defined for SDP transported using SAP [14] and SIP [15],
   others may be defined in future.

Spencer - are the colons after these and after SDP really semi-colons? (Or
have I tripped over British English usage; if so, my apologies!)

4.5  Categorisation

   When many session descriptions are being distributed by SAP, or any
   other advertisement mechanism, it may be desirable to filter session
   announcements that are of interest from those that are not.  SDP
   supports a categorisation mechanism for sessions that is capable of
   being automated.

Spencer - could you add a forward pointer to this mechanism here? I think
it's just "(See Section 6)"

5.  SDP Specification

   Text fields such as the session name and information are octet
   strings which may contain any octet with the exceptions of 0x00
   (Nul), 0x0a (ASCII newline) and 0x0d (ASCII carriage return).  The
   sequence CRLF (0x0d0a) is used to end a record, although parsers
   SHOULD be tolerant and also accept records terminated with a single
   newline character.  If the "a=charset" attribute is not present,
   these octet strings MUST be interpreted as containing ISO-10646
   characters in UTF-8 encoding (the presence of the "a=charset"
   attribute MAY force some fields to be interpreted differently).

Spencer - again, this MAY seems emphatic, not 2119.

5.2  Origin ("o=")

   <unicast-address> is the address of the machine from which the
      session was created.  For an address type of IP4, this is either
      the fully-qualified domain name of the machine, or the dotted-
      decimal representation of the IP version 4 address of the machine.
      For an address type of IP6, this is either the fully-qualified
      domain name of the machine, or the compressed textual
      representation of the IP version 6 address of the machine.  For
      both IP4 and IP6, the fully-qualified domain name is the form that
      SHOULD be given unless this is unavailable, in which case the
      globally unique address MAY be substituted.  A local IP address
      MUST NOT be used in any context where the SDP description might
      leave the scope in which the address is meaningful.

Spencer - sigh. And since applications may use SDP descriptions in referrals
across addressing domains, it's not obvious how this MUST NOT actually
applies. Could it be a bit more explicit? "be included in an
application-level referral that might leave the scope"?

   For privacy reasons, it is sometimes desirable to obfuscate the
   username and IP address of the session originator.  If this is a
   concern, an arbitrary <username> and private <unicast-address> MAY be
   chosen to populate the "o=" field, provided these are selected in a
   manner that does not affect the global uniqueness of the field.

Spencer - does this actually get used in the wild? If so, fine, but I'm
wondering about sending SDP that one might, or might not, be able to
believe... it would be a late specification change, but using something like
private@example.com (after RFC 2606) would be more obviously private... (and
I note that the SIP working group has just noticed that "anonymous" is an
English-language string, and is also trying to figure out how THEY say
"anonymous" in an international Internet, so please don't think I'm picking
on SDP here :-)

5.9  Timing ("t=")

   Permanent sessions may be shown to the user as never being active
   unless there are associated repeat times which state precisely when
   the session will be active.  In general, permanent sessions SHOULD
   NOT be created for any session expected to have a duration of less
   than 2 months, and should be discouraged for sessions expected to
   have a duration of less than 6 months.

Spencer - I'm having 2119 problems here - how is "SHOULD NOT" different from
"discouraged from"?

5.10  Repeat Times ("r=")

   To make description more compact, times may also be given in units of
   days, hours or minutes.  The syntax for these is a number immediately
   followed by a single case-sensitive character.  Fractional units are
   not allowed - a smaller unit should be used instead.  The following
   unit specification characters are allowed:

      d - days (86400 seconds)
      h - hours (3600 seconds)
      m - minutes (60 seconds)
      s - seconds (allowed for completeness but NOT RECOMMENDED)

Spencer - I am guessing that you are saying "NOT RECOMMENDED because the
default is in seconds anyway", but I'm having to guess why "NOT
RECOMMENDED".

5.12  Encryption Keys ("k=")

      k=uri:<URI to obtain key>
         A Universal Resource Identifier is included in the key field.
         The URI refers to the data containing the key, and may require
         additional authentication before the key can be returned.  When
         a request is made to the given URI, the reply should specify
         the encoding for the key.  The URI is often a secure HTTP URI,
         although this is not required.

Spencer - Do you really mean "secure HTTP"
(ftp://ftp.rfc-editor.org/in-notes/rfc2660.txt), or do you mean
SSL/TLS-protected HTTP ("https:")?

   The key field MUST NOT be used unless it can be guaranteed that the
   SDP is conveyed over a secure and trusted channel.  An example of
   such a channel might be SDP embedded inside an S/MIME message or a
   TLS-protected HTTP session.  It is important to ensure that the
   secure channel is with the party that is authorised to join the
   session, not an intermediary: if a caching proxy server is used, it
   is important to ensure that the proxy is either trusted or unable to
   access the SDP.  Definition of appropriate security measures is
   beyond the scope of this specification, and should be defined by the
   users of SDP.

Spencer - the last sentence of this paragraph seems confused between
protocol security and operational security policy ...

5.14  Media Descriptions ("m=")

      3.  If two media sessions have the same transport address, they
          SHOULD operate under the same RTP profile.  The sessions MAY
          use two different RTP profiles only if those profiles are
          specifically designed to be compatible.

Spencer - is there any registry of what's compatible, or is this something
that users just have to figure out?

6.  SDP Attributes

   The following attributes are defined.  Since application writers may
   add new attributes as they are required, this list is not exhaustive.
   Registration procedures for new attributes are defined in Section
   8.2.4.

      a=cat:<category>

         This attribute gives the dot-separated hierarchical category
         of the session.  This is to enable a receiver to filter
         unwanted sessions by category.  It is a session-level
         attribute, and is not dependent on charset.

      a=keywds:<keywords>

         Like the cat attribute, this is to assist identifying wanted
         sessions at the receiver.  This allows a receiver to select
         interesting session based on keywords describing the purpose
         of the session.  It is a session-level attribute.  It is a
         charset dependent attribute, meaning that its value should be
         interpreted in the charset specified for the session
         description if one is specified, or by default in ISO
         10646/UTF-8.

Spencer - I am guessing that there is no registry of allowed values for cat
and keywds(the sender can use any character string, and receivers will
figure out what the values are and whether they are interested intuitively),
but I am guessing. Whether I guessed right or not, it might be nice to say
this explicitly.

7.  Security Considerations

   SDP is frequently used with the Session Initiation Protocol [15]
   using the offer/answer model [17] to agree parameters for unicast
   sessions.  When used in this manner, the security considerations of
   those protocols apply.

Spencer - s/agree/agree on/

   SDP is a session description format that describes multimedia
   sessions.  A session description SHOULD NOT be trusted unless it has
   been obtained by an authenticated transport protocol from a trusted
   source.  Many different transport protocols may be used to distribute
   session description, and the nature of the authentication will differ
   from transport to transport.

Spencer - I'm not sure what "trusted" means here - if I got an SDP
description using unauthenticated RTSP, I would probably USE it (if the
session was interesting), and isn't that the kind of "trust" relationship
one has with a session description? Is the point something like "SHOULD NOT
be trusted beyond the trust relationship a host has for the transport
protocol used to deliver the session description. Many different ..."? The
second paragraph down gives good guidance, I'm just trying to be consistent
here and two paragraphs down.

   One transport that will frequently be used to distribute session
   descriptions is the Session Announcement Protocol (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 they are previously unknown to the receiver of
   the announcement and because no common public key infrastructure is
   available.

Spencer - SAP used "frequently" in 2006 (by the time this
specification is announced)...

   Session descriptions may be parsed at intermediate systems such as
   firewalls for the purposes of opening a hole in the firewall to allow
   participation in multimedia sessions.  This SHOULD NOT be done unless
   the SDP is conveyed in a manner that allows proper authentication and
   authorization checks to ensure that firewall holes are only opened in
   accordance with applicable security policy.  SDP by itself does not
   include sufficient information to enable these checks: they depend on
   the encapsulating protocol (e.g.  SIP or RTSP).

Spencer - sigh... The Internet must have been really nice, ten years ago...
:-(  but anyway - we don't normally give standards-track guidance for
firewall operation, do we? I thought BEHAVE had them explicitly out of
scope... 

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art