An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback
draft-ietf-mmusic-media-loopback-27

[Ballot discuss]
Some of the changes were made in -26, but some weren't. Was that a conscious decision, or were those just misses?Here's what's left:

Section 3.2 paragraph 1: The first sentence still includes the unnecessary MUST, and it's now so complex that I can't make heads or tails of it. It needs rewriting. There's no also need for the second sentence; that gets taken care of in the subsequent paragraphs.

4.2, last paragraph: "MUST include" should just be "includes"

5.2, paragraph 1: "MUST follow" -> "will follow".

Also:

    If an answerer wishes to accept the loopback request it MUST
    include both the loopback role and loopback type attributes in the
    answer.

Instead:

    An answerer includes both the loopback role and loopback type
    attributes in the answer to indicate that it will accept loopback
    requests.

[Ballot discuss]
I appreciate the changes that were put into the -25 version. However, the change to 3.2 made things very confusing and didn't address the original problem, and the change for 4.2 that was agreed in email didn't get made. The items regarding section 5.2, 5.5, and 13 were never addressed addressed at all. Here are the remaining bits:

Section 3.2 paragraph 1: The first sentence still includes the unnecessary MUST, and it's now so complex that I can't make heads or tails of it. It needs rewriting. There's no also need for the second sentence; that gets taken care of in the subsequent paragraphs.

4.2, last paragraph: "MUST include" should just be "includes"

5.2, paragraph 1: "MUST follow" -> "will follow". I'd also like to see "and hence MUST NOT be used" just deleted; it doesn't add anything as far as I can tell.

    If an answerer wishes to accept the loopback request it MUST
    include both the loopback role and loopback type attributes in the
    answer.

Instead:

    An answerer includes both the loopback role and loopback type
    attributes in the answer to indicate that it will accept loopback
    requests.

Also: "MUST be loopback-mirror" -> "will be loopback-mirror"

5.5:

This entire section should be removed; it is not important to this particular document as it is a general problem for any protocol.

    Furthermore, if the mirroring entity is behind a NAT, it MUST send
    some packets to the identified address/port(s) of the peer, in
    order to open the NAT pinhole.

That MUST is completely bogus. Even if being behind a NAT always required sending packets to pinhole, the MUST is still wrong: This is not a requirement of *this* protocol; it's just stating a fact. But the fact is that being behind a NAT does *not* require pinholing: If the entity is behind a PCP server, it MUST do no such thing.

    Note that for any form of NAT traversal to function, symmetric
    RTP/RTCP [RFC4961] MUST be used.  In other words both agents MUST
    send packets from the source address and port they receive packets
    on.

Again, completely false in the case of PCP. Please remove section 5.5.

13:

    All implementations MUST at least support the rtp-pkt-loopback mode
    for loopback-type, with direct media loopback payload encoding.

I don't understand: Are you saying that there is no environment under which I might *only* implement rtp-media-loopback? Why is this a MUST?

[Ballot discuss]
[Updating my DISCUSS to reflect current version and conversations by email. Waiting for a new rev of the document to clear.]

Overall comment: This document uses the phrase "compliant to this specification" in several places, normally followed by some 2119 keyword. These uses are unnecessary, redundant, and mostly incorrect. To say, "An SDP offerer compliant to this specification MUST do X" is exactly the same as "An SDP offerer MUST do X." And in most cases, "MUST do X" is also wrong; normally, you really mean "will do X". Again, in most cases, you are defining the semantics of the protocol, not stating a protocol requirement that implementations need to be wary of. This document could use a serious scrubbing of these terms. There are some specifics below (and I certainly haven't covered all of them; I stopped looking after section 6), as well as some other comments.

3.1:
   
    An SDP offerer compliant to this specification and attempting to
    establish a media session with media loopback MUST include
    "loopback" media attributes for each individual media description
    in the offer message.  The offerer MUST look for the "loopback"
    media attributes in the media description(s) of the response from
    the answer for confirmation that the request is accepted.

By email, I suggested the following replacement for the first sentence to capture the correct intention:

  In order to establish a media session with media loopback, an SDP
  offerer MUST include "loopback" media attributes for all individual
  media descriptions in the offer.

That makes it clear what is important for an implementer to remember. Now, the second sentence is also not clear on the requirement. Are you trying to say that the offerer should consider the answer *not* confirmed if it doesn't have the "loopback" attribute in all (or any?) of the media descriptions in the response? Are these instructions for the offerer or the answerer? If the offerer, what is it that the offerer MUST do? "Looking for" the attribute doesn't seem like what you mean.

Section 3.2 paragraph 1:

My suggested replacement for this is:

  In order to accept and acknowledge an offer containing media
  descriptions with the "loopback" media attribute, an SDP answerer
  MUST include the received "loopback" media attribute in all media
  descriptions in the reply.

There's no need for the second sentence; that gets taken care of in the subsequent paragraphs.

4.2 paragraph 1: I'm pretty sure "MUST include" could just be "includes"
5.1: "MUST be used" -> "is used"
5.2, paragraph 1: "MUST follow" -> "will follow". I'd also like to see "and hence MUST NOT be used" just deleted; it doesn't add anything as far as I can tell.

    If an answerer wishes to accept the loopback request it MUST
    include both the loopback role and loopback type attributes in the
    answer.

Instead:

    An answerer includes both the loopback role and loopback type
    attributes in the answer to indicate that it will accept loopback
    requests.

Also: "MUST be loopback-mirror" -> "will be loopback-mirror"

5.5:

This entire section should be removed; it is not important to this particular document as it is a general problem for any protocol.

    Furthermore, if the mirroring entity is behind a NAT, it MUST send
    some packets to the identified address/port(s) of the peer, in
    order to open the NAT pinhole.

That MUST is completely bogus. Even if being behind a NAT always required sending packets to pinhole, the MUST is still wrong: This is not a requirement of *this* protocol; it's just stating a fact. But the fact is that being behind a NAT does *not* require pinholing: If the entity is behind a PCP server, it MUST do no such thing.

    Note that for any form of NAT traversal to function, symmetric
    RTP/RTCP [RFC4961] MUST be used.  In other words both agents MUST
    send packets from the source address and port they receive packets
    on.

Again, completely false in the case of PCP. Please remove section 5.5.

6:

    A loopback mirror that is compliant to this specification and
    accepts media with rtp-pkt-loopback loopback type MUST loopback the
    incoming RTP packets using either the encapsulated RTP payload
    format or the direct loopback RTP payload format as defined in
    Section 7 of this specification.
   
What else might a loopback mirror try to do that this paragraph is trying to prevent?

"MUST transmit all received media" -> "will transmit all received media"
"incoming media MUST be treated" -> "incoming media will be treated"

13:

    All implementations MUST at least support the rtp-pkt-loopback mode
    for loopback-type, with direct media loopback payload encoding.

I don't understand: Are you saying that there is no environment under which I might *only* implement rtp-media-loopback? Why is this a MUST?

[Ballot comment]

Thanks for addressing my discuss. As a comment, I'd have
preferred that instead of saying that the same SRTP setup
was used, you had said that the same security properties
MUST apply. (Some folks keep telling us that SRTP is not
mandatory,)

[Ballot discuss]
[The below are mostly 2119 problems. I normally would make this a Comment and simply ballot "No Objection", but there are so many of them, and their use is in ways that I think could complicate or confuse an implementation, that I'd like to "Discuss" for a bit. If the AD thinks these are best handled as a comment, I will happily change my ballot. If the AD would like me to help make all of these changes, I will leave it as a "Discuss" and discuss the changes with the authors/WG.]

Overall comment: This document uses the phrase "compliant to this specification" in several places, normally followed by some 2119 keyword. These uses are unnecessary, redundant, and mostly incorrect. To say, "An SDP offerer compliant to this specification MUST do X" is exactly the same as "An SDP offerer MUST do X." And in most cases, "MUST do X" is also wrong; normally, you really mean "will do X". Again, in most cases, you are defining the semantics of the protocol, not stating a protocol requirement that implementations need to be wary of. This document could use a serious scrubbing of these terms. There are some specifics below (and I certainly haven't covered all of them; I stopped looking after section 6), as well as some other comments.

3.1:
   
    An SDP offerer compliant to this specification and attempting to
    establish a media session with media loopback MUST include
    "loopback" media attributes for each individual media description
    in the offer message.  The offerer MUST look for the "loopback"
    media attributes in the media description(s) of the response from
    the answer for confirmation that the request is accepted.

The first sentence is a definition, not a protocol requirement. In the second sentence, the requirement to "look" is silly. Looking can't possibly be the requirement; nothing bad will happen if I don't look. Instead:

    An SDP offerer implementing media loopback includes "loopback" media
    attributes for each media description in the offer message. If the
    request is accepted, the response from answer will have "loopback"
    media attributes in the media description(s).

A similar rewrite should be done to the first paragraph of 3.2. In the second paragraph of 3.2, you can change "MUST be" to "is".

4.1: I would change "MUST be used" to "are used"
4.2 and 5.1 paragraph 1: I'm pretty sure "MUST include" could just be "includes"
5.1: "MUST be used" -> "is used"
5.2, paragraph 1: "MUST follow" -> "will follow". I'd also like to see "and hence MUST NOT be used" just deleted; it doesn't add anything as far as I can tell.

    If an answerer wishes to accept the loopback request it MUST
    include both the loopback role and loopback type attributes in the
    answer.

Instead:

    An answerer includes both the loopback role and loopback type
    attributes in the answer to indicate that it will accept loopback
    requests.

Also: "MUST be loopback-mirror" -> "will be loopback-mirror"

5.5:

This entire section should be removed; it is not important to this particular document as it is a general problem for any protocol.

    Furthermore, if the mirroring entity is behind a NAT, it MUST send
    some packets to the identified address/port(s) of the peer, in
    order to open the NAT pinhole.

That MUST is completely bogus. Even if being behind a NAT always required sending packets to pinhole, the MUST is still wrong: This is not a requirement of *this* protocol; it's just stating a fact. But the fact is that being behind a NAT does *not* require pinholing: If the entity is behind a PCP server, it MUST do no such thing.

    Note that for any form of NAT traversal to function, symmetric
    RTP/RTCP [RFC4961] MUST be used.  In other words both agents MUST
    send packets from the source address and port they receive packets
    on.

Again, completely false in the case of PCP. Please remove section 5.5.

6:

    A loopback mirror that is compliant to this specification and
    accepts media with rtp-pkt-loopback loopback type MUST loopback the
    incoming RTP packets using either the encapsulated RTP payload
    format or the direct loopback RTP payload format as defined in
    Section 7 of this specification.
   
What else might a loopback mirror try to do that this paragraph is trying to prevent?

"MUST transmit all received media" -> "will transmit all received media"
"incoming media MUST be treated" -> "incoming media will be treated"

13:

    All implementations MUST at least support the rtp-pkt-loopback mode
    for loopback-type, with direct media loopback payload encoding.

I don't understand: Are you saying that there is no environment under which I might *only* implement rtp-media-loopback? Why is this a MUST?

[Ballot comment]
I agree with Wes's comment; perhaps the Rube Goldberg aspect comes in part from the long gestation period of the document (eight years in the making), which tends to cause a lot of accumulation.

Please consider changing the title of Section 13 to "Applicability Statement" (from "Implementation Considerations"), because I believe that's what that section is (see RFC 2026, Section 3.2, end of the second paragraph).

[Ballot comment]
I support Martin's DISCUSS.

I don't have any technical issue with this document; it will basically work.  However, it does seem to be quite a bit of a Rube Goldberg solution, in that it's significantly more error-prone, less efficient, and more complex than simply having the loopback node compute and send the desired statistics back to the source.  I may be missing something huge about the motivations that's not stated clearly in the document though.

[Ballot comment]
I support Martin's DISCUSS.

I don't have any technical issue with this document; it will basically work.  However, it does seem to be quite a bit of a Rube Goldberg solution, in that it's more significantly more error-prone, less efficient, and more complex than simply having the loopback node compute and send the desired statistics back to the source.  I may be missing something huge about the motivations that's not stated clearly in the document though.

[Ballot comment]
Consider expanding the description of the attack and the defense against the attack in the second paragraph of the security considerations section. Authentication of the signalling does not prevent the attack - it just provides a way to identify the bad actor. It should also be clearer that this takes a 3pcc style call setup. Consider also suggesting that implementations terminate loopback streams that are sending packets at rates that are significantly greater than what the expected rate for what's being carried.

[Ballot discuss]

I reckon this ought be an easy one to resolve.

If the loopback media and the "forward" media can ever have
different security protection applied then that would create
potential vulnerabilities. I think that you need to say that
the same protection SHOULD or MUST be applied to both. The only
reason I can think of for a SHOULD would be if you want to use
this feature to test if your crypto stuff is the source of
problems.

Note: I'm not arguing that you SHOULD or MUST apply
any particular security, but that if you do, you need to
do the same to both streams.

[Ballot discuss]
The overall document is fine, but Section 10 about Congestion Control hit my eyes.

Section 10 says that the mirror should not perform congestion control and puts the burden for the forward and backward direction to the loopback source. At least in the second paragraph.

How does the loopback source know about congestion on the path from the mirror to the source?
The text does not say anything about it and I have trouble to see how the source can fully infer what the congestion status on the forward direction to the mirror and also on the way back is.

Further, the first paragraph and the second paragraph are contradicting each other, as the first one says that all participants SHOULD implement congestion control, but the second says that the source SHOULD, but not the mirror.

I would be fine if any, i.e., source and mirror, are bound to "SHOULD implement congestion control". This will increase the implementation effort on the mirror, but the mechanisms are anyhow there, if the loopback source is implementing it.

[Ballot comment]
I haven't finished my review yet, but I wanted to get some feedback on some initial comments while I continue:

I'm having trouble figuring out why 2119 language is being used in several places. So for example:

3.1 and 3.2 paragraph 1: I would change "MUST" to "will"
3.2 paragraph 2: I would change "MAY" to "can" and "MUST be" to "is"
4.1: I would change "MUST be used" to "are used"
4.2 and 5.1 paragraph 1: I'm pretty sure "MUST include" could just be "includes"

None of these sound like protocol interoperability requirements, but rather are just descriptive of protocol syntax and semantics. Instead of me going through and asking about all such things in the document, can you explain whether you feel the above examples are all correct as-is, and if so explain why, or alternatively can you go through the entire document and clean these things up?

I'll continue my review but make no further comments about 2119 language until I hear from you.

[Ballot comment]

  The authors report than changes are pending to handle the editorial
  comments raised in the Gen-ART Review by Meral Shirazipour on
  23-Aug-2012.  I hope the updated I-D will be posted prior to IESG
  approval of this document.

IANA has reviewed draft-ietf-mmusic-media-loopback-22 and has the following comments:

IANA has questions about the IANA actions requested in this document.

IANA understands that, upon approval of this document, there are two IANA
actions which must be completed.

First, in the att-field (media level only) registry of the Session Description
Protocol (SDP) Parameters registry located at:

www.iana.org/assignments/sdp-parameters/sdp-parameters.xml

three new media-level SDP attributes are to be registered as follows:

Type: att-field (media level only)
SDP Name: loopback
Reference: [ RFC-to-be ]

Type: att-field (media level only)
SDP Name: loopback-source
Reference: [ RFC-to-be ]

Type: att-field (media level only)
SDP Name: loopback-mirror
Reference: [ RFC-to-be ]

Second, the document requests the registration of a series of media types as
follows:

Type name: audio
Subtype name: encaprtp
in the registry located at:
http://www.iana.org/assignments/media-types/audio/index.html

Type name: video
Subtype name: encaprtp
in the registry located at:
http://www.iana.org/assignments/media-types/video/index.html

Type name: text
Subtype name: encaprtp
in the registry located at:
http://www.iana.org/assignments/media-types/text/index.html

Type name: application
Subtype name: encaprtp
in the registry located at:
http://www.iana.org/assignments/media-types/application/index.html

Type name: audio
Subtype name: rtploopback
in the registry located at:
http://www.iana.org/assignments/media-types/audio/index.html

Type name: video
Subtype name: rtploopback
in the registry located at:
http://www.iana.org/assignments/media-types/video/index.html

Type name: text
Subtype name: rtploopback
in the registry located at:
http://www.iana.org/assignments/media-types/text/index.html

Type name: application
Subtype name: rtploopback
in the registry located at:
http://www.iana.org/assignments/media-types/application/index.html

Currently the application, text, viedo and audio media type libraries are
maintained through expert review as defined in RFC 5226.

IANA Question -> has the document been reviewed by the appropriate Media
Type expert?

IANA understands that these two actions are the only ones 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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback) to Proposed Standard


The IESG has received a request from the Multiparty Multimedia Session
Control WG (mmusic) to consider the following document:
- 'An Extension to the Session Description Protocol (SDP) and Real-time
  Transport Protocol (RTP) for Media Loopback'
  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 2012-08-23. 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


    The wide deployment of Voice over IP (VoIP), Text and Video over IP
    services has introduced new challenges in managing and maintaining
    real-time voice/text/video quality, reliability, and overall
    performance.  In particular, media delivery is an area that needs
    attention.  One method of meeting these challenges is monitoring
    the media delivery performance by looping media back to the
    transmitter.  This is typically referred to as "active monitoring"
    of services.  Media loopback is especially popular in ensuring the
    quality of transport to the edge of a given VoIP, Real-time Text or
    Video over IP service.  Today in networks that deliver real-time
    media, short of running 'ping' and 'traceroute' to the edge,
    administrators are left without the necessary tools to actively
    monitor, manage, and diagnose quality issues with their service.
    The extension defined herein adds new SDP media types and
    attributes, which enable establishment of media sessions where the
    media is looped back to the transmitter. Such media sessions will
    serve as monitoring and troubleshooting tools by providing the
    means for measurement of more advanced VoIP, Real-time Text and
    Video over IP performance metrics.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mmusic-media-loopback/ballot/


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

Gonzalo did his AD review during IETF 84 and found no show-stoppers - he asked me to move this into IETF LC once the writeup was available.

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

The intended status is Proposed Standard. This is correct, since the
document defines new SDP attributes and RTP payload types, and media
types. The intended status is indicated in the title page header.

(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

This document provides extensions to the Session Description Protocol
(SDP) and the Real-time Transport Protocol (RTP) for enabling looping
of sent media. Media loopback is especially popular in ensuring the
quality of transport to the edge of a given VoIP, Real-time Text or
Video over IP service. The extension defined herein adds new SDP media
types and attributes, which enable establishment of media sessions
where the media is looped back to the transmitter. Such media sessions
will serve as monitoring and troubleshooting tools by providing the
means for measurement of more advanced VoIP, Real-time Text and Video
over IP performance metrics.

Working Group Summary

The first version of the document was available at the end of 2004.
Since that time, the working group has been discussing a number of
issues toward getting the consensus that is believed to be achieved in
version 22.

The description of a latching mechanism to traverse NATs and firewalls
was discussed and decided to be removed from the actual document in
favor of standard NAT traversal techniques such as ICE/STUN/TURN.

Document Quality

At least four implementations of this functionality are known. Four
other vendors have indicated they plan to implement it.

The document was WGLCed on version 16. Additionally, the PAYLOAD WG
also conducted a thorough review of the same 16 version. As a result of
these reviews, 34 changes were requested by, among others, Tolga
Asveren, Dan Wing, Emil Ivov, Flemming Andreasen, and Miguel A. Garcia.
These comments were subsequently introduced into versions 17 and 18. A
new WGLC was issued on version 18, bringing a new set of comments by
Flemming Andreasen, Magnus Westerlund, and Gunnar Hellstrom. These were
addressed in version 19.

At least Magnus Westerlund and Flemming Andreasen did a thorough review
of the document as part of the WGLC on version 18.

Version 18 was sent to the ietf-types mailing list for review on April
4, 2012. Bjorern Hoehrmann and Magnus Westerlund posted comments that
were addressed in version 19.

Personnel

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

Miguel A. Garcia is the Document Shepherd. Gonzalo Camarillo 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.

The Document Shepherd reviewed at least versions 16 and 18, as part of
the WGLC process. Changes introduces upto version 22 have been tracked by
the Document Shepherd. It is believed that this version of the document
is ready for publication.

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

No concerns. The document has got substantial and deep reviews throughout
its extended lifetime.

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

The document creates two new RTP payload formats for achieving the
loopback functionality. Due to this, the document has been reviewed in
the PAYLOAD WG. In particular, version 16 suffered a thorough review in
the PAYLOAD mailing list.

The registration of new media types have been reviewed by the ietf-types
experts.

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

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

There are no IPR disclosures associated to this document. Authors have
confirmed that no such IPR has

(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 has been filed so far.

(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 seems to be strong consensus on the current document by the WG,
which seems to understand and agree with it.

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

No such threat has been disclosed.

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

ID nits is reporting no warnings or errors on version 22.

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

The document has been reviewed in the ietf-types mailing list, due to the
inclusion of a new media types.

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

All the normative references are made towards published RFCs.

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

There are no downward normative references.

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

The publication of this document will not change the status of any
existing RFC.

(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 Document Shepherd has reviewed the IANA considerations section and it
is believed to be correct and in line with the body fo the document.

The document requests three new SDP attributes to be registered. The
registration follows the template in RFC 4566 for registration of new
attributes.

Additionally, the document request the registration of 8 new media types.
These registration follow the template in RFC 4288 and have been reviewed
by the ietf-types mailing list.

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

No new IANA registries are defined by this document.

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

BNF rules have been checked against the Bap ABNF parser.

WGLC starts on April 2nd, 2012
WGLC ends on April 16th, 2012

As a minimum, a new revision is expected to trim the list of authors from the first page.

Main point of discussion: whether the alternative NAT traversal mechanism (latching) proposed in the draft is generally applicable outside of the media loopback use case, and/or if we in general need an alternative to ICE for NAT traversal.