[MMUSIC] Benjamin Kaduk's No Objection on draft-ietf-mmusic-rfc4566bis-35: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-mmusic-rfc4566bis-35: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I reviewed the diff from RFC 4566 but didn't make it quite all the way
through the full document itself.  What I did find in that partial read
suggests that a full read-through by the authors may find some lingering
stale language or minor internal inconsistencies.

Another broad topic (with more comments throughout) is that an early and
clear discussion of time representation may be helpful, and arguably
does not need to refer to NTP time at all.  (This is especially so when
we refer to "NTP time format" and RFC 5905, which lists three
formats, none of which have a straightforward translation to numeric
strings without fraction part.)

Section 4

                                   SDP is primarily intended for use in
   an internetwork, although it is sufficiently general that it can
   describe multimedia conferences in other network environments.  [...]

nit(?): this verbiage ("internetwork") feels quite dated.

Section 4.1

                                                    Some media types may
   redefine this behavior, but this is NOT RECOMMENDED since it
   complicates implementations (including middleboxes that must parse
   the addresses to open Network Address Translation (NAT) or firewall
   pinholes).

(Similarly for "firewall pinholes".)

Section 4.3

The usual security considerations about (potentially) referencing remote
content would seem to apply.  Perhaps a RFC 3986 reference (or more)
would be appropriate.

Section 4.6

Perhaps we should mention here that this categorization mechanism is
deprecated/obsolete?

Section 5

   An SDP description is entirely textual.  SDP field names and
   attribute names use only the US-ASCII subset of UTF-8 [RFC3629], but
   textual fields and attribute values MAY use the full ISO 10646
   character set in UTF-8 encoding, or some other character set defined
   by the "a=charset:" attribute.  [...]

nit: here (and in Section 4.4 just above) may be the only times we
include the colon when discussing an "a=" attribute; consistency would
seem to suggest removing the colons.

                                  However, since SDP may be used in
   environments where the maximum permissible size of a session
   description is limited, the encoding is deliberately compact.  Also,
   since descriptions may be transported via very unreliable means or
   damaged by an intermediate caching server, the encoding was designed
   with strict order and formatting rules so that most errors would
   result in malformed session descriptions that could be detected
   easily and discarded.  This also allows rapid discarding of encrypted
   session descriptions for which a receiver does not have the correct
   key.

I don't really see why the "rapid discarding" property follows from the
compactness of the encoding, when the correct key for the encrypted
description is not known.

Section 5.x

It's interesting to note that while the SDP attributes (Sections 6.x)
got ABNF constructions for their values, the type descriptions here
are still presented in a somewhat informal syntax (that, e.g., relies on
implicitly stating that fields are whitespace-separated).

Section 5.2

   <sess-id>  is a numeric string such that the tuple of <username>,
      <sess-id>, <nettype>, <addrtype>, and <unicast-address> forms a
      globally unique identifier for the session.  The method of <sess-
      id> allocation is up to the creating tool, but it has been
      suggested that a Network Time Protocol (NTP) format timestamp be
      used to ensure uniqueness [RFC5905].

(et seq) There is not a single "NTP format timestamp"; RFC 5905 provides
three different formats.  If any of the three is fine, that should be
stated, and if a single distinguished one is preferred, that should also
be stated.
Furthermore, the three formats all include multiple fields and not a
rule for presenting them as a "numeric string" as described here, which
on the face of it seems to exclude fractions.  ("numeric string" does
not seem to be specifically defined by this document.)

Section 5.3

   The "s=" line MUST NOT be empty and SHOULD contain ISO 10646
   characters (but see also the "a=charset" attribute).  [...]

Is this perhaps intended to be "SHOULD only contain"?
(Similarly in following subsections.)

Section 5.9

   The first and second sub-fields of the time-field 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
   (UTC), subtract decimal 2208988800.

Looking at the time formats listed in RFC 5905, one perhaps wonders if
the values used by SDP are more appropriately described informally as
just "seconds since the Unix epoch" without specific reference to NTP
(both here and elsewhere in the document).

   NTP timestamps are elsewhere represented by 64-bit values, which wrap
   sometime in the year 2036.  [...]

I don't understand what this is referring to.  Is this perhaps the "32
bits of seconds and 32 bits of fraction" format, which suffers from the
y2038 (note '8', not '6') problem?

Section 6.2

Perhaps "this was to assist" would be more fitting, given the obsolete
nature of a=keywds.

Section 6.9

   This specifies the type of the multimedia conference.  Suggested
   values are "broadcast", "meeting", "moderated", "test", and "H332".

nit: I don't think these are "suggested" values; they are the only ones
allowed by the ABNF.

   "recvonly" should be the default for "type:broadcast" sessions,
   "type:meeting" should imply "sendrecv", and "type:moderated" should
   indicate the use of a floor control tool and that the media tools are
   started so as to mute new sites joining the multimedia conference.

There seems to be redundancy here with the "SHOULD" in Section 6.7 about
"sendrecv" being the default for non-broadcast non-H322 sessions.

Section 6.11

Is it intentional to lose the language about "order of importance" of
multiple languages?