SDP: Session Description Protocol
draft-ietf-mmusic-rfc4566bis-37

[Ballot comment]
Thank you for addressing my DISCUSS. Original COMMENT is below.

-----

Section 5.1:

Since both this document and RFC 4566 specify version 0 and this version makes semantic and syntactic changes, does that mean the protocol versioning is non-functional? Or if not, what kinds of changes would require a new version number?

Section 7:

"Use of the "k=" line poses a significant security risk, since it
  conveys session encryption keys in the clear.  SDP MUST NOT be used
  to convey keying material, unless it can be guaranteed that the
  channel over which the SDP is delivered is both private and
  authenticated.  Moreover, the "k=" line provides no way to indicate
  or negotiate cryptographic key algorithms.  As it provides for only a
  single symmetric key, rather than separate keys for confidentiality
  and integrity, its utility is severely limited.  The "k=" line MUST
  NOT be used, as discussed in Section 5.12."

It's odd to me that this text was retained from RFC 4566 as-is, except for the last sentence. I would have expected this to lead with something like 'Use of the "k=" line is obsolete due to security risk.' And then perhaps some of the rest of the text could remain by way of explanation why it was obsoleted.

Section 8.2.8:

"IANA may refer any registration to the IESG for review, and may
  request revisions to be made before a registration will be made."

This is trivially true and would be better left out, using RFC 8126 as the definitive guidance instead.

[Ballot 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

    is a numeric string such that the tuple of ,
      , , , and  forms a
      globally unique identifier for the session.  The method of  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?

[Ballot comment]
Thank you for a well written document. Below are mostly nits, but I think they will help first time implementors.

In Section 1:

electronic mail using the MIME  extensions [RFC5322]

This needs another reference for MIME. E.g. RFC 2045.

In 3.1 “media types” need a Normative reference.

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

Can you give an example of such redefinition?

In 4.3: the first mention of URI needs a Normative Reference.

In 4.5: ISO 8859-1 needs a reference.

In 5.3:

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

Does this mean that it is affected by a=charset?
Why SHOULD?
The text is 5.4 is better, if the intention is the same.

In 5.5:

“WWW clients“

URIs are used by many types of clients. Suggest dropping “WWW”.

In 6.10:

  Note that a character set specified MUST still prohibit the use of
  bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR).

This doesn’t actually say what you intended. None of the common charsets prohibit these bytes. I think you meant that when using such charsets, these characters MUST NOT be used in values.

In 6.11:

  The "sdplang" attribute value must be a single [RFC5646] language tag
  in the US-ASCII subset of UTF-8

Is “fr-ca” allowed here?
Can you point to a specific ABNF in RFC 5646?
Also, “in the US-ASCII subset of UTF-8“ is either redundant or confusing, as language tags are always in U-ASCII.

In 8.1:

  Encoding considerations:        SDP files are primarily UTF-8 format text

This is not correct use of this field. I think you should say “8bit” or “binary” here.

In 8.2.2:

  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.

I just want to confirm that an Independent Stream RFC is allowed here?

[Ballot comment]
I don't have anything to add (the other IESG evals have covered everything I wanted to say) other than to repeat the thanks for Section 10, and also to thank Zitao for the OpsDir review.

[Ballot discuss]
I’d like to escalate Alissa’s point about the k= language in Section 7 (Security Considerations).  It looks like the new Section 5.12 removes all of the historical language beyond saying it MUST NOT be used.  This approach makes sense to me.  However, the language in Section 7 could be read as conflicting with that.  Specifically:

  Use of the "k=" line poses a significant security risk, since it
  conveys session encryption keys in the clear.  SDP MUST NOT be used
  to convey keying material, unless it can be guaranteed that the
  channel over which the SDP is delivered is both private and
  authenticated.
  ...
  The "k=" line MUST
  NOT be used, as discussed in Section 5.12.

The first sentence makes a strong statement.  The first clause of the second sentence makes a more generic MUST NOT statement but the second clause seems to say that is acceptable under certain circumstances.  The third sentence reiterates that k= MUST NOT be used.  How should this be reconciled?  Is the text suggesting that conveying keying materials outside of k= is acceptable over the right kind of channel?

[Ballot comment]
(1) Per the Security Considerations (Section 7) paragraph on “software parsing the session should take a few precautions”, the discussion about software taking action is helpful.  I’d also recommend explicitly adding caution about acting on URIs (e.g., the security considerations of [RFC3986]) to this section.

(2) Section 6.7.  Typo. s/occurence/occurrence/

[Ballot discuss]
Section 8.2.8:

"In the RFC specifications that register new values for SDP "media",
  "proto", "fmt", "bwtype", "nettype", and "addrtype" parameters, the
  authors MUST include the following information for IANA to place in
  the appropriate registry:"

It doesn't look like all the fields that are listed after this text actually appear in the registries. For some of these I don't see why the information would be put into the registries (e.g., contact name, contact email address, since those appear in the RFCs themselves). I think this needs to be clarified.

[Ballot comment]
Section 5.1:

Since both this document and RFC 4566 specify version 0 and this version makes semantic and syntactic changes, does that mean the protocol versioning is non-functional? Or if not, what kinds of changes would require a new version number?

Section 7:

"Use of the "k=" line poses a significant security risk, since it
  conveys session encryption keys in the clear.  SDP MUST NOT be used
  to convey keying material, unless it can be guaranteed that the
  channel over which the SDP is delivered is both private and
  authenticated.  Moreover, the "k=" line provides no way to indicate
  or negotiate cryptographic key algorithms.  As it provides for only a
  single symmetric key, rather than separate keys for confidentiality
  and integrity, its utility is severely limited.  The "k=" line MUST
  NOT be used, as discussed in Section 5.12."

It's odd to me that this text was retained from RFC 4566 as-is, except for the last sentence. I would have expected this to lead with something like 'Use of the "k=" line is obsolete due to security risk.' And then perhaps some of the rest of the text could remain by way of explanation why it was obsoleted.

Section 8.2.8:

"IANA may refer any registration to the IESG for review, and may
  request revisions to be made before a registration will be made."

This is trivially true and would be better left out, using RFC 8126 as the definitive guidance instead.

[Ballot discuss]
I'll raise Martin's comment to DISCUSS level:

OLD
  decimal-uchar =      DIGIT
                        / POS-DIGIT DIGIT
                        / ("1" 2*(DIGIT))
                        / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT)
                        / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))
NEW
  decimal-uchar =      DIGIT
                        / POS-DIGIT DIGIT
                        / ("1" 2(DIGIT))
                        / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT)
                        / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))
END

Is there a reason NOT to make this change, or was it just overlooked?

[Ballot comment]
Hi,

I'm not an ABNF expert but it seems to me the errata 1795 (https://www.rfc-editor.org/errata/eid1795) was correct, but the proposed change has not been incorporated in the document.
I've rapidly searched for a discussion on this errata but could not find any. There might be a reason for not applying the change and in that case, sorry to raise that again, but in case this was an oversight then it might be worth capturing this now.

[Ballot comment]

Thank you all for the work put into this document. I appreciate the section 10 about the differences with RFC 4566.

== COMMENTS ==

-- Section 5 (and others) --

Any reason why using an IPv4 examples rather than an IPv6 one? After all, we are in 2019...

-- Section 5.2 --

Rather than using the relatively vague " compressed textual representation of an IP version 6 address of the machine", please refer to RFC 5952.

-- Section 5.7 (and possibly others) --

Is there any reason not to follow RFC 5952 and use lowercase for all IPv6 addresses in this document ?

== NITS ==

-- Section 3.3 --

Using "World Wide Web (WWW)" seems old fashioned to me but no problem ;-)

-- Section 4.5 --

Suggestion to add reference to the ISO character sets.


-- Section 5 --

When using IPv4 unicast addresses, please use the example ones.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-mmusic-rfc4566bis-34. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

IANA Question --> IANA understands that this document is intended to obsolete RFC4566. Are there any other places (other than what is documented in section 8.2 of the current document) that IANA should update a reference to RFC4566 with a new reference of [ RFC-to-be ]?

IANA understands that some of the actions requested in the IANA Considerations section of this document are dependent upon the approval of and completion of IANA Actions in another document: [I-D.ietf-mmusic-sdp-mux-attributes].

The IANA Functions Operator also understands that, upon approval of this document, there are fourteen actions which we must complete.

First, in the app registry on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

the existing registration for:

sdp

will be changed to have its reference changed to [ RFC-to-be ] and the template will be changed to reflect the content of Section 8.1 of the current document.

Second, also on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

the following registries will have their reference changed to [ RFC-to-be ]:

media
proto
att-field
bwtype
nettype
addrtype

IANA Question --> section 8.2 of the current document specifies that changes are to be made to "seven named SDP sub-fields originally defined in RFC4566." However, the next sentence only lists six registries. Is there a seventh that was intended to be updated in section 8.2?

IANA Question --> in several of these registries there are types registered that have RFC4566 as the reference. Should the references for these individual registrations also be changed to [ RFC-to-be ]?

IANA Question --> there are five different att-field registries on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

is the intent of Section 8.2 to change the references of all five from RFC4566 to [ RFC-to-be ]?

Third, in the media registry also on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

the following, existing registrations will have their reference changed to [ RFC-to-be ]:

audio
video
text
application
message

IANA notes that the registration for:

image

is to remain as RFC6466.

Fourth, in the proto registry also on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

the following, existing registrations will have their reference changed to [ RFC-to-be ]:

RTP/AVP
UDP

Fifth, IANA understands that there are no actions for IANA to complete in Section 8.2.3 of the current document.

Sixth, in the att-field(session level) registry also on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

the following, existing registrations will have their reference changed to [ RFC-to-be ]:

cat
keywds
tool
type
charset

Seventh, in the att-field(media level) registry also on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

the following, existing registrations will have their reference changed to [ RFC-to-be ]:

ptime
maxptime
rtpmap
orient
framerate
quality
fmtp

Eighth, in the att-field(both session and media level) registry also on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

the following, existing registrations will have their reference changed to [ RFC-to-be ]:

recvonly
sendrecv
sendonly
inactive
sdplang
lang

Ninth, in the bwtype registry also on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

the following, existing registrations will have their reference changed to [ RFC-to-be ]:

CT
AS

Tenth, in the nettype registry also on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

the following, existing registration will have its reference changed to [ RFC-to-be ]:

IN

Eleventh, in the addrtype registry also on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

the following, existing registrations will have their reference changed to [ RFC-to-be ]:

IP4
IP6

Twelveth, the enckey registry also on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

is marked as obsolete.

IANA Question --> should any of the registrations have their references changed in this registry?

Thirteenth, the nettype registry also on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

is to be reorganized with a new column as follows:

--------------------------------------------------------------------
|Type | SDP Name | Usable addrtype Values | Reference |
--------------------------------------------------------------------
|nettype | IN | IP4, IP6 | [ RFC-to-be ] |
|nettype | TN | RFC2543 | [RFC2848] |
|nettype | ATM | NSAP, GWID, E164 | [RFC3108] |
|nettype | PSTN | E164 | [RFC7195] |
--------------------------------------------------------------------

Fourteenth, the following registries, all on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

are to be combined into a single registry:

att-field (session level)
att-field (both session and media level)
att-field (media level only)
att-field (source level)
att-field (unknown level)

The new, single registry will have the following columns:

|---------------------------------------------------------------------|
|Name | Usage Level | Dependent on Charset? | Mux Category | Reference|
|---------------------------------------------------------------------|

These columns will be populated from the existing registrations in the following way:

The "Name" column will be taken from the "SDP Name" column of existing registrations.

The "Usage Level" column will be one or more of the following: session, media, source, dcsa and dcsa(subprotocol). The contents of "Usage Level" will come from the existing registration's location in the five registries being combined.

The "Dependent on Charset?" column will indicate "Yes" or "No" depending on whether the attribute value is subject to the charset attribute.

IANA Question --> Where will IANA get the information to determine whether the attribute value is subject to the charset attribute?

The "Mux Category" column MUST indicate one of the following categories: NORMAL, NOT RECOMMENDED, IDENTICAL, SUM, TRANSPORT, INHERIT, IDENTICAL-PER-PT, SPECIAL or TBD as defined by Section 15.2 of [I-D.ietf-mmusic-sdp-mux-attributes].

Finally, the "Reference" column indicates the specification(s) where the attribute is defined and is taken from the existing five registries.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-04-12):

From: The IESG
To: IETF-Announce
CC: fandreas@cisco.com, ben@nostrum.com, draft-ietf-mmusic-rfc4566bis@ietf.org, mmusic@ietf.org, mmusic-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (SDP: Session Description Protocol) to Proposed Standard


The IESG has received a request from the Multiparty Multimedia Session
Control WG (mmusic) to consider the following document: - 'SDP: Session
Description Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-04-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This memo defines the Session Description Protocol (SDP).  SDP is
  intended for describing multimedia sessions for the purposes of
  session announcement, session invitation, and other forms of
  multimedia session initiation.  This document obsoletes RFC 4566.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/ballot/


No IPR declarations have been submitted directly on this I-D.

This is my AD evaluation of draft-ietf-mmusic-rfc4566bis-32. I have several minor substantive comments, and a number of editorial comments and nits. I’d like to resolve at least the substantive comments prior to IETF last call.

Thanks!

Ben.
----------------------

*** Substantive Comments ***

§1, last paragraph: The statement that this update is limited to essential corrections is demonstrably untrue. For example, this version changes a lot of spellings from British English to US English. While that might be best for the sake of consistency, it would be hard to argue that it is _essential_.

Along the same lines, §10 does not seem to capture all material changes.

§2, “Media Description”: While true, the text here is not a definition of anything but syntax. Please add a sentence or two to say what the media description semantically represents.

- Deleted text formerly in §4.3: The removal of the “private sessions” section in its entirety deserves some explanatory text.

§5.2: "Unless an SDP extension for NAT traversal is used
(e.g., ICE [RFC8445], ICE TCP [RFC6544]), 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”

That doesn’t apply to just any NAT traversal extension does it? It seems to require extensions that have scope-resolution properties similar to those of ICE.

§5.8: "Use of the "X-" prefix is NOT RECOMMENDED: instead new (non "X-"
prefix)  names SHOULD be defined, and then MUST be registered
with IANA in the standard namespace.”

“SHOULD be defined” seems to be in tension with “MUST be registered”.

§5.13: "The "k=" line (key-field) is obsolete and MUST NOT be used.”
Should it be removed from the field order definition in §5?

§6.1: Please state what behavior is meant by “This attribute is obsoleted”. For example, MUST not send but SHOULD accept? Something different? (This pattern occurs for multiple attributes.)

§6.7.4: "Note that an RTP-based system MUST still send RTCP (if RTCP
is used), even if started inactive.”
Other similar attributes use SHOULD instead of MUST. Is the inconsistency intentional?

§7, last paragraph:
What is the impact of this on RFC 4568 (security descriptions)? That RFC seems to allow the use of “k=“ lines at a MAY level. Does this draft need to update that? But more importantly, is it worth distinguishing the case of E@E protection of keying material vs the HBH protection offered by security descriptions?

§8 and subsectionsl:

I think there needs to be more clarity about what this draft defines vs what was defined in previous versions, and what has changed. For example, language to the effect of "XXX was originally defined in RFC 4566. This document requests IANA to change the reference to “RFC-this”.”

§8.2: "The contact address for all parameters registered below is:
IETF MMUSIC working group ”
Please consider “The IETF MMUSIC working group  or its successor as designated by the IESG.”

§8.2.1: "Until that is done, applications SHOULD NOT use these
types and SHOULD NOT declare support for them in SIP capabilities
declarations (even though they exist in the registry created by
[RFC3840]).”

Should this spec update 3840?

§8.2.4.2: This section needs some guidance about the maturity of specs needed to update attributes defined in previous specs. While the registration policy is “spec required”, what happens if someone defines FOO in a standards-track RFC, and someone else wants to update it with some lower-maturity instrument?

Along the same line, is there any restriction from party B updating an attribute defined by party A without consent? That is clear for IETF stream RFCs where the IETF retains change control, but might not be clear for other specification forms.

§8.2.8: Are telephone numbers still necessary? Under GDPR rules, we should be careful about requiring data unless there is a clear need for it.

*** Editorial Comments and Nits ***

§3.3, 2nd paragraph: "Note that descriptions of multicast sessions made only via email or…”

The sentence no longer makes sense with the change from “announcement” to “description”. If you want to avoid the term “announcements”, consider something like “… descriptions of multicast sessions sent only via email…”

§4.1: "This address and port is the destination address and destination port”: Plural disagreement. (It was correct in 4566.)

§5:
- “… the end of the whole session description - whichever…”: A dash usually separates two independent clauses, much like a semicolon. That is not the cast here; a comma would be more appropriate.

- "Some lines in each description are REQUIRED and some are OPTIONAL,” : While I recognize these are unchanged from 4566, the REQUIRED and OPTIONAL terms seem like statements of fact rather than normative statements.

- "media-, or session-specific basis” : Incorrect comma usage.

- "An SDP description may contain URIs”
I'm not sure this change makes sense. Should it say ''session description”?

- "Text containing fields such as the session-name-field and
information-field”:
This is ambiguous. Are we talking about text that contains fields, or text-containing fields? From context, I assume the latter.

§5.5: "The "u=" line (uri-field) provides URI (Uniform Resource Identifier)
as used by WWW clients”
Missing article before URI

§5.7:
- "The "c=" line (connection-field) contains connection data.”
The section heading was changed from “connection data” to “connection information”. Should that change apply here, too?

- There are a number of places in this section (and maybe elsewhere) where IPv6 was changed to IP6. While I realize 4566 was inconsistent on this, wouldn’t it make more sense to change to consistently use the more conventional “IPv6”?  (Probably also true for IP4/IPv4).

- "Multiple addresses or "c=" lines MAY be specified on a per media
description basis”
4566 correctly hyphenated “per-media-description basis”. Why were the hyphens removed here?

§5.8: "A prefix "X-" is defined for  names. This is intended for
experimental purposes only.”

Please consider active voice for “is defined”, since in this case it obscures the fact that this was defined by an earlier version of the spec. Would it make sense to say that previous versions defined it, but it is now deprecated?

§5.9: "A "t=" line (time-field) initiates a time description that specifies
the start and stop times for a session.”

I don't understand what it means to "intitiate" a time description. The text from 4566 seemed more clear.

§5.13: "(Attribute scopes in addition to media- and
session- specific may also be defined”
Should “specific” be “level”?

§5.14:

- "If noncontiguous
ports are required, they must be signaled using a
separate attribute. (There is currently no attribute defined that
can accomplish this. The "a=rtcp:" defined in [RFC3605] does not
handle hierarchical encoding.)”

This is oddly stated. Is the point that, if non-contiguous ports are needed, someone will have to specify a new attribute?

- "This implies that, unlike
limited past practice, there is no implicit grouping defined by
such means and an explicit grouping framework”

This does considerably more than “imply” it. It states it explicitly. Perhaps “This means that, unlike…”?

§6.7: "At most one of recvonly/sendrecv/sendonly/inactive MAY appear at
session level”
Consider something like "occurrence of recvonly, sendrecv, sendonly, or inactive”. (Please don’t use slashes to substitute for conjunctions.)

§6.7.1: "(e.g., an RTP-based system in
recvonly mode SHOULD still send RTCP packets”
Please don’t use normative keywords in examples. Examples should never be normative.

§11: It seems a shame to completely drop the acknowledgements from 4566, since the fact that this will obsolete it means people should no longer need to read it. I recognize that those acknowledgements do not apply to _this_ draft, but one could always include a paragraph of the form of “RFC 4566 also acknowledged…"

Shepherd Write-Up.
As required by RFC 4858, this is the current template for the Document

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard – the title page indicates the intended status of “Standards Track”, which is appropriate since the document obsoletes RFC 4566, which is also Standards Track.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

This memo defines the Session Description Protocol (SDP).  SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.  This document obsoletes RFC 4566.


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

This updated version of RFC 4566 has been in in the works since late 2007, and as such it has undergone a number of revisions and improvements consistent with overall work on SDP related extensions in that timeframe. Consensus on the document is solid and there are no particular controversies related to it.



Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

The SDP protocol is widely implemented by a number of different vendors. A number of people in the MMUSIC group have contributed and commented over the years, however there is no single reviewer that merits special mention.


Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Flemming Andreasen is the Document Shepherd
Ben Campbell is the Responsible Area Director

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I have reviewed -24, and -29 through -32 in detail. As a result of these reviews, various updates have been made and the document is ready for publication at this point.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Not applicable

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No such concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Each author has confirmed

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosure

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

There is solid consensus in the WG overall.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

Not applicable

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The document has been checked for nits. The ID-Nits tool has a couple of false positives:
- RFCXXXX will be updated by the RFC Editor to refer to the assigned RFC number for this document
- The multicast IPv4 address (in the ABNF) is not an example address.
- There is no code in the document
- RFC2978 is indeed used as a reference in the document (in Section 6.10).
- E164 refers to ITU-T Recommendation E.164, which is an open external standard
- The reference to RFC 2327 is intentional


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

The document updates the existing registration of the “application/sdp” media type, and as such is subject to the procedures of RFC 6838, Section 5.5. Per RFC 6838, Section 3.1, this procedure is expected to be performed by the IESG as part of the publication process.


(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

The document normatively references draft-ietf-mmusic-ice-sip-sdp, which is currently not ready for advancements. The document is waiting for a potential update to align with recent changes to draft-ietf-rtcweb-jsep. Once this potential alignment issue has been resolved, the document is ready for publication.

The document also normatively references draft-ietf-data-channel-sdpneg, which has been submitted for publication and is currently undergoing AD review. 


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

Not applicable.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

Yes. The document will obsolete RFC 4566, which is listed on the title page, and mentioned in both the abstract and introduction.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA considerations section has been reviewed and found to comply with the above.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

Not applicable.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

I have reviewed the current version (-32) detail. ID-nits have been run on the document, and the ABNF has been verified with Bill Fenner’s ABNF parsing service.

The document is considered done. It is decided to retain it for a while, in case additional bugs are found and could be documented in this round.