Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)
draft-ietf-simple-msrp-cema-07

[Ballot discuss]

Thanks for addressing many of my discuss points. I think this
version is much clearer and only what were points #5 and #8
remain.

#5 I still don't understand how MIKEY for managing TLS-PSK
values is well-defined. The string "TLS" (still:-) does not occur
in RFC 6043.  It may be that the 3GPP docs spell this out
though - is that the case?

#8 How do MSRP endpoints figure out what authentication methods
they have in common in a way that's not attackable by an on-path
active attacker? That may be ok, but I'm afraid I'm just not
following the way this works with SDP and TLS negotiation
both in play.

[Ballot comment]
The TLS and MIKEY-TICKET references can't be informative.
Since Sean has a discuss on that (for TLS anyway) I'll just make
it a comment here.

These comments on -03 don't seem to have been addressed so
I've left them in here:

- the term "anchor" is never really explained and it'd be good to do
that.

- hard to parse this from the top of p4: "In such cases,
middleboxes, that want to anchor the MSRP connection simply modify
the SDP c/m-line address information, similar to what it does for
non-MSRP media types" who's the last "it"?

"The CEMA extension is fully backward compatible." Seems a bit of
sales-talk. And (fully;-) backwards compatible with what?

- "Middleboxes cannot be deployed in environments that require
end-to-end SDP integrity protection or SDP encryption." I bet I
could deploy a middlebox in such an environment, perhaps not very
effectively, but I could. "Cannot" cannot be correct.

[Ballot discuss]
#1 cleared

As you'll see from the points below I have some issues with how
you're using TLS. Could be that some of this is just a lack
of context on my part but I'd like to check at least.

#2  cleared

#3 cleared

#4 cleared

#5 I don't understand how MIKEY for managing TLS-PSK values is
well-defined. The string "TLS" does not occur in RFC 6043.  (I'd
just drop the MIKEY idea entirely - is anyone really gonna do that?)

#6 cleared

#7 cleared

#8 How do MSRP endpoints figure out what authentication methods
they have in common in a way that's not attackable by an on-path
active attacker? What is the list of "mechanisms" that you
mean in 7.2 (para starting with "If possible, ...")

#9 cleared

#10 cleared

[Ballot comment]

The TLS and MIKEY-TICKET references can't be informative.
Since Sean has a discuss on that I've left it as a comment
here.

These comments on -03 don't seem to have been addressed so
I've left them in here:

- the term "anchor" is never really explained and it'd be good to do
that.

- hard to parse this from the top of p4: "In such cases,
middleboxes, that want to anchor the MSRP connection simply modify
the SDP c/m-line address information, similar to what it does for
non-MSRP media types" who's the last "it"?

- "The CEMA extension is fully backward compatible." Seems a bit of
sales-talk. And (fully;-) backwards compatible with what?

- "Middleboxes cannot be deployed in environments that require
end-to-end SDP integrity protection or SDP encryption." I bet I
could deploy a middlebox in such an environment, perhaps not very
effectively, but I could. "Cannot" cannot be correct.

[Ballot discuss]
#1 cleared

As you'll see from the points below I have some issues with how
you're using TLS. Could be that some of this is just a lack
of context on my part but I'd like to check at least.

#2  cleared

#3 cleared

#4 How is the MIKEY reference not normative? 7.2 RECOMMENDS doing
either 1) TLS certs with blah (RFC 6042) or 2) MIKEY stuff. The
MIKEY RFC (RFC 6043) is informational so that's a downref.

#5 I don't understand how MIKEY for managing TLS-PSK values is
well-defined. The string "TLS" does not occur in RFC 6043.  (I'd
just drop the MIKEY idea entirely - is anyone really gonna do that?)

#6 cleared

#7 cleared

#8 How do MSRP endpoints figure out what authentication methods
they have in common in a way that's not attackable by an on-path
active attacker? What is the list of "mechanisms" that you
mean in 7.2 (para starting with "If possible, ...")

#9 cleared

#10 cleared

[Ballot discuss]
#1 cleared

As you'll see from the points below I have some issues with how
you're using TLS. Could be that some of this is just a lack
of context on my part but I'd like to check at least.

#2  cleared

#3 cleared

#4 How is the MIKEY reference not normative? 7.2 RECOMMENDS doing
either 1) TLS certs with blah (RFC 6042) or 2) MIKEY stuff. The
MIKEY RFC (RFC 6043) is informational so that's a downref.

#5 I don't understand how MIKEY for managing TLS-PSK values is
well-defined. The string "TLS" does not occur in RFC 6043.  (I'd
just drop the MIKEY idea entirely - is anyone really gonna do that?)

#6 Can you re-assure me that there are in fact implementations of
RFC 6072 and RFC 6043 (in the latter case usable for managing
TLS-PSK symmetric keys). If so, great, I'd appreciate some pointers
to those. If not, then are you really building on fiction? Wouldn't
that be a bad plan?

#7 cleared

#8 How do MSRP endpoints figure out what authentication methods
they have in common in a way that's not attackable by an on-path
active attacker? What is the list of "mechanisms" that you
mean in 7.2 (para starting with "If possible, ...")

#9 cleared

#10 cleared

[Ballot discuss]
#1 cleared

As you'll see from the points below I have some issues with how
you're using TLS. Could be that some of this is just a lack
of context on my part but I'd like to check at least.

#2  cleared

#3 cleared

#4 How is the MIKEY reference not normative? 7.2 RECOMMENDS doing
either 1) TLS certs with blah (RFC 6042) or 2) MIKEY stuff. The
MIKEY RFC (RFC 6043) is informational so that's a downref.

#5 I don't understand how MIKEY for managing TLS-PSK values is
well-defined. The string "TLS" does not occur in RFC 6043.  (I'd
just drop the MIKEY idea entirely - is anyone really gonna do that?)

#6 Can you re-assure me that there are in fact implementations of
RFC 6072 and RFC 6043 (in the latter case usable for managing
TLS-PSK symmetric keys). If so, great, I'd appreciate some pointers
to those. If not, then are you really building on fiction? Wouldn't
that be a bad plan?

#7 I don't get the trust model for "fingerprint" based
authentication for TLS. Who's including the fingerprint where and
using it to verify what self-signed cert?

#8 How do MSRP endpoints figure out what authentication methods
they have in common in a way that's not attackable by an on-path
active attacker? What is the list of "mechanisms" that you
mean in 7.2 (para starting with "If possible, ...")

#9 cleared

#10 cleared

[Ballot comment]
- the term "anchor" is never really explained and it'd be good to do
that.

- hard to parse this from the top of p4: "In such cases,
middleboxes, that want to anchor the MSRP connection simply modify
the SDP c/m-line address information, similar to what it does for
non-MSRP media types" who's the last "it"?

- "The CEMA extension is fully backward compatible." Seems a bit of
sales-talk. And (fully;-) backwards compatible with what?

- "Middleboxes cannot be deployed in environments that require
end-to-end SDP integrity protection or SDP encryption." I bet I
could deploy a middlebox in such an environment, perhaps not very
effectively, but I could. "Cannot" cannot be correct.

- In general, I'd ask you to think about describing TLS usage in section
7 from the point of view of the TLS endpoints and not based on the
various options for what a middlebox might do. I suspect that might lead to
a clearer description but hard to know unless you try.

[Ballot comment]
s1: strike lawful intercept (I see Stephen made this a discuss otherwise I would have made it one too)

s2: Fingerprint Based TLS AUthentication:
    r/self-signed TLS certificate/self-signed certificate
    r/fingerprint/fingerprint (i.e., a hash of the self-signed certificate)

s2: Name Based TLS Authethication
    r/certificate authority/certification authority
    r/SubjectAltName parameter/SubjectAltName extension

s3: r/Support of the extension is optional./
      Support of the extension is OPTIONAL.

s7.2: certificates are by definition public so I'm a little confused by the following:

  1.  TLS certificates together with support of interacting with a
      Certificate Management Service [RFC6072], to which it publishes the
      public version of its own self-signed certificate and from which it
      fetches on demand the public certificates of other endpoints.

Maybe:

  1.  TLS certificates together with support of interacting with a
      Certificate Management Service [RFC6072], to which it publishes
      its self-signed certificate and from which it
      fetches on demand the self-signed certificates of other endpoints.

s7.2: (Stephen caught this too) MIKEY-TICKET is a normative reference.

s7.2: I share the same concerns Stephen has wrt the fingerprint authentication.

s7.3: Probably worth a pointer to the SIP issues based on the following:

  Even with seemingly end-to-end media integrity, at the time of the
  publication of this document there are other vulnerabilities in MSRP,
  due to vulnerabilities in the SIP signaling.

[Ballot discuss]
s7.1: I believe the following requires a normative reference to TLS:

  For backward compability, a CEMA-enabled MSRP
  endpoint MUST implement TLS.

s7.2: What is "a common authentication mechanism" in following:

  If possible, MSRP endpoints MUST use name-based authentication.  If
  not possible, if the MSRP endpoints support a common authentication
  mechanism, they MUST use that mechanism.  If the MSRP endpoints do
  not support such common authentication mechanism, they MUST try
  fingerprint-based authentication, which will succeed if there are no
  Middleboxes present.  If that also fails, the MSRP endpoints MUST
  either:

[Ballot comment]
- the term "anchor" is never really explained and it'd be good to do
that.

- hard to parse this from the top of p4: "In such cases,
middleboxes, that want to anchor the MSRP connection simply modify
the SDP c/m-line address information, similar to what it does for
non-MSRP media types" who's the last "it"?

- "The CEMA extension is fully backward compatible." Seems a bit of
sales-talk. And (fully;-) backwards compatible with what?

- "Middleboxes cannot be deployed in environments that require
end-to-end SDP integrity protection or SDP encryption." I bet I
could deploy a middlebox in such an environment, perhaps not very
effectively, but I could. "Cannot" cannot be correct.

- In general, I'd ask you to think about describing TLS usage in section
7 from the point of view of the TLS endpoints and not based on the
various options for what a middlebox might do. I suspect that might lead to
a clearer description but hard to know unless you try.

[Ballot discuss]
#1 Lawful intercept is not a feature in this context (see rfc 2804)
I'd say just delete the phrase and you'll loose nothing.

As you'll see from the points below I have some issues with how
you're using TLS. Could be that some of this is just a lack
of context on my part but I'd like to check at least.

#2 What name is authenticated in "name based authentication"? Would
any such name (in a cert issued by a locally trusted CA) do just
fine? 

#3 2nd para of 7.2: if an MSRP endpoint can get an "incorrect
impression" about TLS in the presence of a middlebox then how does
the MSRP endpoint ever benefit from authentication?

#4 How is the MIKEY reference not normative? 7.2 RECOMMENDS doing
either 1) TLS certs with blah (RFC 6042) or 2) MIKEY stuff. The
MIKEY RFC (RFC 6043) is informational so that's a downref.

#5 I don't understand how MIKEY for managing TLS-PSK values is
well-defined. The string "TLS" does not occur in RFC 6043.  (I'd
just drop the MIKEY idea entirely - is anyone really gonna do that?)

#6 Can you re-assure me that there are in fact implementations of
RFC 6072 and RFC 6043 (in the latter case usable for managing
TLS-PSK symmetric keys). If so, great, I'd appreciate some pointers
to those. If not, then are you really building on fiction? Wouldn't
that be a bad plan?

#7 I don't get the trust model for "fingerprint" based
authentication for TLS. Who's including the fingerprint where and
using it to verify what self-signed cert?

#8 How do MSRP endpoints figure out what authentication methods
they have in common in a way that's not attackable by an on-path
active attacker? What is the list of "mechanisms" that you
mean in 7.2 (para starting with "If possible, ...")

#9 I get the impression that the 2nd last paragraph of 7.2 is
what you think people will actually do and that all the rest
of that section is window dressing. Am I wrong? If I'm right,
then why not just plainly say that and then we can discuss
it more easily?

#10 If I'm wrong about #9: On what basis can an MSRP endpoint
pick between the two choices at the end of 7.2? What code do
I write?

[Ballot comment]
The short title that appears on every page but the first needs to be changed. It's currently MRSP. CEMA or MSRP-CEMA would be better.

In section 4.2, "either or all of the criteria" is unclear. I suggest "any of the following criteria" instead.

In 4.2 and 4.3, there are notes about resolving domain names before trying to match against addresses in c or m lines in SDP. They currently say "whether there address". I suggest "whether the address" instead.

In section 4.4 when you discuss handling multiple records from DNS, it's not clear whether all the resolved addresses must match or only one in the set must match.

[Ballot discuss]
There are two paragraphs in section 7.2 (the ones starting "When an MSRP endpoint" and "If possible, MSRP endpoints") that need to be scoped to this extension. It might be enough to say CEMA-enabled MSRP endpoint everywhere you currently say MSRP endpoint, but that would likely make the text hard to read.

There's something wrong with the second paragraph and the list that follows it. It currently says "Check every authentication mechanism at your disposal. If they all fail, then based on local policy, decide whether you want to believe the failure is because there is a benign network that's trying to help you instead of a malicious party trying to hurt you." Is that what the document was actually trying to say? If so, then if you're going to allow an endpoint to make that decision (and I don't think you should since there's no way to tell that all the network elements are actually part of that benign network), why waste the time authenticating in the first place? Unless the paragraph intended something completely different, option 2 in the list should be removed.

[Ballot comment]
Section 3:
  "Support of the extension is optional."

Do you mean "OPTIONAL"?

  "MSRP endpoints that
  support CEMA are required to use RFC 4975 behavior in cases where
  they detect that the CEMA extension cannot be enabled."
 
Do you mean "REQUIRED"?

Section 4.1:

  In the following cases, where there is a Middlebox in the network,
  the CEMA extension cannot be used...

Do you mean "MUST NOT be used"?

Section 4.2:

  When the offerer receives an SDP answer, if the MSRP media
  description of the SDP answer does not contain an SDP 'msrp-cema'
  attribute, the offerer MUST check the criteria below.  If either or
  all of the criteria is met, the offerer MUST fallback to RFC 4975
  behavior, by sending a new SDP offer according to the procedures in
  RFC 4975 and RFC 4976.

This is mostly editorial, but since it involves 2119 language, I think it's worth fixing: The first MUST is redundant. If the offerer MUST do things based on the criteria, there is no need to say that you MUST check the criteria. (Also, "either" is the wrong word when there are more than two criteria. You meant "any".) Instead maybe:

  The offerer MUST fallback to RFC 4975 behavior, by sending a new
  SDP offer according to the procedures in RFC 4975 and RFC 4976, if
  it receives an SDP answer whose description does not contain an SDP
  'msrp-cema' attribute, any of the following criteria are met:
 
  [1...
    2...
    3...]
 
  The new offer MUST NOT contain an SDP 'msrp-cema' attribute.

[Ballot comment]
It seems to me that the security considerations are somewhat underspecified, and I find the concept of a TLS B2BUA unsatisfying, but I will let folks from the security area comment on those aspects of the specification.

[Ballot discuss]
Overall this is a fine document. I have a few topics I'd like to chat about.

1. Why isn't the text about RFC 5952 comparison normative? Mandating a single comparison rule will improve the odds of interoperable implementations.

2. This is a rather strong statement: "Middleboxes cannot be deployed in environments that require end-to-end SDP integrity protection or SDP encryption." The introduction states that "[t]hese middleboxes anchor and control media, perform tasks such as NAT traversal, performance monitoring, lawful intercept, address domain bridging, interconnect Service Layer Agreement (SLA) policy enforcement, and so on." Do *all* of those behaviors prohibit end-to-end SDP integrity protection and SDP encryption"?

3. The actual procedures used in Fingerprint Based TLS Authentication and Name Based TLS Authentication are unspecified here, and no pointer is provided to other specifications that define these procedures. In the absence of a clear definition, how will these forms of authentication be performed?

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)) to Proposed Standard


The IESG has received a request from the SIP for Instant Messaging and
Presence Leveraging Extensions WG (simple) to consider the following
document:
- 'Connection Establishment for Media Anchoring (CEMA) for the Message
  Session Relay Protocol (MSRP)'
  as a 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 2011-11-17. 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 document defines a Message Session Relay Protocol (MSRP)
  extension, Connection Establishment for Media Anchoring (CEMA).
  Support of the extension is optional.  The extension allows
  middleboxes to anchor the MSRP connection, without the need for
  middleboxes to modify the MSRP messages, and thus also enables a
  secure end-to-end MSRP communication in networks where such
  middleboxes are deployed.  The document also defines a Session
  Description Protocol (SDP) attribute, 'msrp-cema', that MSRP
  endpoints use to indicate support of the CEMA extension.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-simple-msrp-cema/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-simple-msrp-cema/


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

PROTO writeup for
http://tools.ietf.org/id/draft-ietf-simple-msrp-cema-03.txt: "Connection
Establishment for Media Anchoring (CEMA) for the Message Session Relay
Protocol (MSRP)"


  (1.a)  Who is the Document Shepherd for this document?  Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

The document shepherd for this document is Hisham Khartabil.

The document has been reviewed and is ready for forwarding to IESG for
publication.


  (1.b)  Has the document had adequate review both from key WG members
        and from key non-WG members?  Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

The document has quite a bit of review in the SIMPLE work group. While it
replaced draft-ietf-simple-msrp-sessmatch which had quite a bit of
controversy in the working group, this draft had more general agreement.
Miguel Garcia performed an SDP expert review in his capacity as an MMUSIC
chair.

The Document Shepherd does not have concerns about the depth or breadth of
the reviews.


  (1.c)  Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization, or XML?

The document should undergo the usual Gen-ART and secdir reviews. But
otherwise the Document Shepherd does not have concerns over the level and
breadth of review for this document.


  (1.d)  Does the Document Shepherd have any specific concerns or
        issues 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.  Has an IPR disclosure related to this document
        been filed?  If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

The IESG should be aware that this draft assumes and non-normatively
recommends certain behaviors for middleboxes that anchor both signaling and
media. Such middlebox behavior is common, but not standardized. This concern
was brought up in the working group, but the consensus was that if a
middlebox deviates from the described behaviors, the resulting damage is no
worse than it would be if this draft was not supported.


  (1.e)  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?

The goal of the draft that this one replaced
(draft-ietf-simple-msrp-sessmatch) was controversial in the SIMPLE work
group. The authors of RFC4975 and 4976 initially objected to the
modification of the protocol to make it more friendly to non-standardized
middleboxes such as SBCs. However, those objections were generally secondary
to security related objections that the older draft interfered with some TLS
use cases. The working group has a consensus that the security issues do not
apply to the current draft.

In summary, draft-ietf-simple-msrp-cema-03 still extends the MSRP protocol
to make it more friendly to middleboxes such as SBCs. The work group
believes it does no incremental harm when compared with the case of using
MSRP as defined in RFC4975 in the presence of such middleboxes--which would
either result in communication failure, or the failure to anchor media at
the middlebox.


  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarize the areas of conflict in
        separate email messages to the Responsible Area Director.  (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

Nobody has threatened an appeal or otherwise indicated extreme discontent
with draft-ietf-simple-msrp-cema-03.


  (1.g)  Has the Document Shepherd personally verified that the
        document satisfies all ID nits?  (See
        http://www.ietf.org/ID-Checklist.html and
        http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
        not enough; this check needs to be thorough.  Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type, and URI type reviews?  If the document
        does not already indicate its intended status at the top of
        the first page, please indicate the intended status here.


The Document Shepherd believes that the document contains all needed
information.


  (1.h)  Has the document split its references into normative and
        informative?  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
        strategy for their completion?  Are there normative references
        that are downward references, as described in [RFC3967]?  If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

The draft contains both normative and informative references. There are no
downwards references.


  (1.i)  Has the Document Shepherd verified that the document's IANA
        Considerations section exists and is consistent with the body
        of the document?  If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries?  Are the IANA registries clearly identified?  If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations?  Does it suggest a
        reasonable name for the new registry?  See [RFC2434].  If the
        document describes an Expert Review process, has the Document
        Shepherd conferred with the Responsible Area Director so that
        the IESG can appoint the needed Expert during IESG Evaluation?

The Document Shepherd believes that the IANA Consideration contains the
appropriate information, and is consistent with the rest of the document.


  (1.j)  Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

The only snippet is:

  attribute          /= msrp-cema-attr
  ;attribute defined in RFC 4566
  msrp-cema-attr    = "msrp-cema"


This has not been validated in an automated checker. One would have to
import the entire RFC4566 definition to make sense of it.

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

RFC4976 describes how to use MSRP over special purpose MSRP relays, in order
to traverse NATs and firewalls, and to allow network policy enforcement.
However, many networks use other middleboxes for this purpose for other
SIP-signaled media, and would like to use the same middleboxes for MSRP.
This draft describes an extension to MSRP to make it easier for them to do
so.


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

[Note that this section is identical to the response to section (1.e)

The goal of the draft that this one replaced
(draft-ietf-simple-msrp-sessmatch) was controversial in the SIMPLE work
group. The authors of RFC4975 and 4976 initially objected to the
modification of the protocol to make it more friendly to non-standardized
middleboxes such as SBCs. However, those objections were generally secondary
to security related objections that the older draft interfered with some TLS
use cases. The working group has a consensus that the security issues do not
apply to the current draft.

In summary, draft-ietf-simple-msrp-cema-03 still extends the MSRP protocol
to make it more friendly to middleboxes such as SBCs. The work group
believes it does no incremental harm when compared with the case of using
MSRP as defined in RFC4975 in the presence of such middleboxes--which would
either result in communication failure, or the failure to anchor media at
the middlebox.


        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?

Multiple participants have implemented or indicated an intent to implement
it.

        Personnel
            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director?  If the document requires IANA
            experts(s), insert 'The IANA Expert(s) for the registries
            in this document are .'

The document shepherd for this document is Hisham Khartabil.

The responsible Area Director is Gonzalo Camarillo.

The IANA Expert(s) for the registries in this document are .