Locating IEEE 802.21 Mobility Services Using DNS
draft-ietf-mipshop-mos-dns-discovery-07

[Ballot discuss]
Section 3:

As the proposal is using an SRV service name of MIHIS, MIHES, MIHCS. Those do not appear in the IANA registries for either protocol names or as a service name in the port registry. These needs to be registered to avoid future conflict attempting to use SRV with the above mention names. Also if new entries are registered for the NAPTR usage, then they also need registration in the service name registry.

The only problem is that the service name registry rules are unclear and under revision. But, the registration needs to happen somehow. Ask IANA how they would prefer it.

[Ballot comment]
Dan's rather thorough review seems to have caught everything I had on my list. if you address his issues and comments I shall be OK.

But in particular,

  Note, that the regexp field in the NAPTR example above is empty.
  This document discourages the use of this field as its usage can be
  complex and error prone; and the discovery of the MIH services do
  not require the flexibility provided by this field over a static
  target present in the TARGET field. 

Needs "discourages" to be written in RFC2119 language

[Ballot comment]
1. Some terminology clarifications could improve the document. One of the issues is the notion of 'home domain' as in:

  When the MN needs to discover Mobility Services in its home domain,
  the input to the First Well Known Rule MUST be the MN's home domain,
  which is assumed to be pre-configured in the MN.

There seem to be an issue with the DNS-DIR about the notion of a "home domain", and how it fits into the DNS (where it's either an entirely alien notion or one of the suffixes in the search path, depending on how you feel about these things). We could not find a definition of "home domain" or "home network" there; neither was it in RFC 5164.  If it's defined in the IEEE 802.21 standard it would be good ti indicate this and maybe replicate the definition here.

2. The following text in section 2.2 is a little weak:

  Note, that the regexp field in the NAPTR example above is empty.
  This document discourages the use of this field as its usage can be
  complex and error prone; and the discovery of the MIH services do
  not require the flexibility provided by this field over a static
  target present in the TARGET field.

It seems that since the regexp field is previously defined to be empty  then a returned NAPTR record with a populated regexp field is not just discouraged: it's undefined, and is not an instance of a NAPTR record that conforms with the specification in this draft.  It would be a significant improvement to strengthen this, the document will be easier to understand if this is made plainer.

3. The IANA considerations says that the Protocol field of the new registry contains the name and acronym for the protocol, along with a reference to a document that describes the transport protocol; but the initial values defined in the draft don't do that. They also require name, address, email address and telephone number ofr the person performing the registration - this seems too much, probably name and email address would be enough.

4. 1. In section 2.2, "Queries are done using the service identifier "_MIHIS" for the MIH  Information Service, "_MIHES" for the MIH Event Service and "_MIHCS"  for the MIH Command Service. "  - The service identifier "_MIHIS" is different from the service identifier "MIHIS" defined in section 2.1. Do the service identifiers refered in both section 2.2 and section 2.1 mean the same thing or not? When should "MIHIS" be used and when should "_MIHIS" be used?

5. In section 2.3, "Once the server providing the desired service and the transport  protocol has been determined, the next step is to determine the IP  address and port." - Determine whose IP adress and port? The server? I suggest spelling it out.

6.  In section 2.3, "A default port  number for MIH services is requested from IANA in [ID.ietf-mipshop-mstp-solution]." - If this is true, the default port is strictly dependent on the reference [ID.ietf-mipshop-mstp-solution] and the reference should be normative rather than informative.

[Ballot discuss]
The DISCUSS and COMMENT are partly based on comments from the DNS-DIR reviewer Andrew Sullivan, from Alfred Hoenes and from OPS-DIR reviewer Tina Tsou.

1) I would like to get some confirmation about the level of involvment or review that this document received from the IEEE 802.21 community. The PROTO write-up mentions that there is no implementation and no plans for an implementation are known. Was this document distributed for review to the IEEE 802.21 Working Group, or is a consistent subset of participants in mipshop also active in the IEEE 802.21 WG?

2) Alfred Hoenes made a comment that I believe needs some consideration. He pointed out that Section 2.3 suggests a possibility of an IP address in TARGET and observed that the SRV definition in RFC 2782 defines "Target" as "The domain name of the target host."  thuse there should not be an IP address returned here.

Indeed Section 2.3 stipulates:

  If TARGET is a numeric IP address, the MN uses that IP address and
  the already chosen transport to contact the server providing the
  desired service.

while RFC 2872 defines:

Target
        The domain name of the target host.  There MUST be one or more
        address records for this name, the name MUST NOT be an alias (in
        the sense of RFC 1034 or RFC 2181).  Implementors are urged, but
        not required, to return the address record(s) in the Additional
        Data section.

If the text in 2.3 refers to the address records in the Additional Data section this needs to be clearly explained.

Also in section 2.3:

  If the result of the SRV query contains a port number, then the MN
  SHOULD contact the server at that port number. If the SRV record did
  not contain a port number then the MN SHOULD contact the server at
  the default port number of that particular service. A default port
  number for MIH services is requested from IANA in [ID.ietf-mipshop-
  mstp-solution].

However, an SRV record should always have a port number, RFC 2782 does not make the field optional.  Is the idea that the port could be "0"?
Wording adjustment seems to be needed here as well.

[Ballot discuss]
The reference to [IEEE802.21] is ambiguous. Is there a way to reference a particular document?

Is it worth discussing the impacts of attacking DHCP to affect the inputs to this protocol?

[Ballot comment]
1. Some terminology clarifications could improve the document. One of the issues is the notion of 'home domain' as in:

  When the MN needs to discover Mobility Services in its home domain,
  the input to the First Well Known Rule MUST be the MN's home domain,
  which is assumed to be pre-configured in the MN.

There seem to be an issue with the DNS-DIR about the notion of a "home domain", and how it fits into the DNS (where it's either an entirely alien notion or one of the suffixes in the search path, depending on how you feel about these things). We could not find a definition of "home domain" or "home network" there; neither was it in RFC 5164.  If it's defined in the IEEE 802.21 standard it would be good ti indicate this and maybe replicate the definition here.

2. The following text in section 2.2 is a little weak:

  Note, that the regexp field in the NAPTR example above is empty.
  This document discourages the use of this field as its usage can be
  complex and error prone; and the discovery of the MIH services do
  not require the flexibility provided by this field over a static
  target present in the TARGET field.

It seems that since the regexp field is previously defined to be empty  then a returned NAPTR record with a populated regexp field is not just discouraged: it's undefined, and is not an instance of a NAPTR record that conforms with the specification in this draft.  It would be a significant improvement to strengthen this, the document will be easier to understand if this is made plainer.

3. The IANA considerations says that the Protocol field of the new registry contains the name and acronym for the protocol, along with a reference to a document that describes the transport protocol; but the initial values defined in the draft don't do that. They also require name, address, email address and telephone number ofr the person performing the registration - this seems too much, probably name and email address would be enough.

[Ballot discuss]
The DISCUSS and COMMENT are partly based on comments from the DNS-DIR reviewer Andrew Sullivan and from Alfred Hoenes.

1) I would like to get some confirmation about the level of involvment or review that this document received from the IEEE 802.21 community. The PROTO write-up mentions that there is no implementation and no plans for an implementation are known. Was this document distributed for review to the IEEE 802.21 Working Group, or is a consistent subset of participants in mipshop also active in the IEEE 802.21 WG?

2) Alfred Hoenes made a comment that I believe needs some consideration. He pointed out that Section 2.3 suggests a possibility of an IP address in TARGET and observed that the SRV definition in RFC 2782 defines "Target" as "The domain name of the target host."  thuse there should not be an IP address returned here.

Indeed Section 2.3 stipulates:

  If TARGET is a numeric IP address, the MN uses that IP address and
  the already chosen transport to contact the server providing the
  desired service.

while RFC 2872 defines:

Target
        The domain name of the target host.  There MUST be one or more
        address records for this name, the name MUST NOT be an alias (in
        the sense of RFC 1034 or RFC 2181).  Implementors are urged, but
        not required, to return the address record(s) in the Additional
        Data section.

If the text in 2.3 refers to the address records in the Additional Data section this needs to be clearly explained.

Also in section 2.3:

  If the result of the SRV query contains a port number, then the MN
  SHOULD contact the server at that port number. If the SRV record did
  not contain a port number then the MN SHOULD contact the server at
  the default port number of that particular service. A default port
  number for MIH services is requested from IANA in [ID.ietf-mipshop-
  mstp-solution].

However, an SRV record should always have a port number, RFC 2782 does not make the field optional.  Is the idea that the port could be "0"?
Wording adjustment seems to be needed here as well.

[Ballot comment]
1. Some terminology clarifications could improve the document. One of the issues is the notion of 'home domain' as in:

  When the MN needs to discover Mobility Services in its home domain,
  the input to the First Well Known Rule MUST be the MN's home domain,
  which is assumed to be pre-configured in the MN.

There seem to be an issue with the DNS-DIR about the notion of a "home domain", and how it fits into the DNS (where it's either an entirely alien notion or one of the suffixes in the search path, depending on how you feel about these things). We could not find a definition of "home domain" or "home network" there; neither was it in RFC 5164.  If it's defined in the IEEE 802.21 standard it would be good ti indicate this and maybe replicate the definition here.

2. The following text in section 2.2 is a little weak:

  Note, that the regexp field in the NAPTR example above is empty.
  This document discourages the use of this field as its usage can be
  complex and error prone; and the discovery of the MIH services do
  not require the flexibility provided by this field over a static
  target present in the TARGET field.

It seems that since the regexp field is previously defined to be empty  then a returned NAPTR record with a populated regexp field is not just discouraged: it's undefined, and is not an instance of a NAPTR record that conforms with the specification in this draft.  It would be a significant improvement to strengthen this, the document will be easier to understand if this is made plainer.

3. The IANA considerations says that the Protocol field of the new registry contains the name and acronym for the protocol, along with a reference to a document that describes the transport protocol; but the initial values defined in the draft don't do that. They also require name, address, email address and telephone number ofr the person performing the registration - this seems too much, probably name and email address would be enough.

[Ballot discuss]
The DISCUSS and COMMENT are partly based on comments from the DNS-DIR reviewer Andrew Sullivan and from Alfred Hoenes.

1) I would like to get some confirmation about the level of involvment or review that this document received from the IEEE 802.21 community. The PROTO write-up mentions that there is no implementation and no plans for an implementation are known. Was this document distributed for review to the IEEE 802.21 Working Group, or is a consistent subset of participants in mipshop also active in the IEEE 802.21 WG?

2) Albert Hoenes made a comment that I believe needs some consideration. He pointed out that Section 2.3 suggests a possibility of an IP address in TARGET and observed that the SRV definition in RFC 2782 defines "Target" as "The domain name of the target host."  thuse there should not be an IP address returned here.

Indeed Section 2.3 stipulates:

  If TARGET is a numeric IP address, the MN uses that IP address and
  the already chosen transport to contact the server providing the
  desired service.

while RFC 2872 defines:

Target
        The domain name of the target host.  There MUST be one or more
        address records for this name, the name MUST NOT be an alias (in
        the sense of RFC 1034 or RFC 2181).  Implementors are urged, but
        not required, to return the address record(s) in the Additional
        Data section.

If the text in 2.3 refers to the address records in the Additional Data section this needs to be clearly explained.

Also in section 2.3:

  If the result of the SRV query contains a port number, then the MN
  SHOULD contact the server at that port number. If the SRV record did
  not contain a port number then the MN SHOULD contact the server at
  the default port number of that particular service. A default port
  number for MIH services is requested from IANA in [ID.ietf-mipshop-
  mstp-solution].

However, an SRV record should always have a port number, RFC 2782 does not make the field optional.  Is the idea that the port could be "0"?
Wording adjustment seems to be needed here as well.

[Ballot comment]
2. Discovering a Mobility Server

[...]

  When the MN needs to discover Mobility Services in a local (visited)
  domain, it SHOULD use DHCP as described in [ID.ietf-mipshop-mos-
  dhcp-options] to discover the IP address of the server hosting the
  desired service, and use it in SRV queries.

My understanding is that SRV lookups are using domain names (not IP addresses) as input, so some extra steps are missing here.

  In some instances, the
  discovery may result in a per protocol/application list of domain
  names which are then to be used as starting points for the
  subsequent NAPTR lookups. If neither IP address or domain name can
  be discovered with the above procedure, the MN MAY request for a
  domain search list, as described in [RFC3397] and [RFC3646], and use
  it as input to the DDDS application. 


2.2 Selecting the transport protocol

[...]

  These NAPTR [RFC3403] records provide a mapping from a domain to the
  SRV [RFC2782] record for contacting a server with the specific
  transport protocol in the NAPTR services field. The resource record
  will contain an empty regular expression and a replacement value,

Should this "will" be a "MUST"?

  which indicates the domain name where the SRV record for that
  particular transport protocol can be found. If the server supports
  multiple transport protocols, there will be multiple NAPTR records,
  each with a different service value.  As per [RFC3403], the client
  discards any records whose services fields are not applicable.

[Ballot discuss]
I have 2 issues, which are probably minor:

1). In the IANA Considerations section:

  The following values have been placed into the registry:
   
  Service Fields                    Protocol
      MIHIS+M2T                        TCP
      MIHIS+M2U                        UDP
      MIHIS+M2S                      SCTP
      MIHES+M2T                        TCP
      MIHES+M2U                        UDP
      MIHES+M2S                      SCTP
      MIHCS+M2T                        TCP
      MIHCS+M2U                        UDP
      MIHCS+M2S                      SCTP
   
  New Service Fields are to be added via Standards Action as defined
  in [RFC5226]. 
  New entries to the table that specify additional transport protocols
  for the existing Service Fields may be registered by IANA on a First
  Come First Served' basis [RFC5226].

I am confused. These 2 registration procedure seem to be in conflict.

2). I think the following reference is Normative:

  [ID.ietf-mipshop-mos-dhcp-options] DHCP Options for IEEE 802.21
      Mobility Services (MoS) Discovery, Bajko et al, May 2009, work
      in progress

IANA questions/comments:


- You didn't specify a name for your registry. Can you please
validate the name chosen or suggest the registry name you require?

- Do you need to add registrations to the S-NAPTR Application Service Tags
registry?

- Does this registry belong in an existing page, like
http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml?

Upon approval of this document, IANA will create the following
registry at
http://www.iana.org/assignments/TBD

Registry Name: Mobility NAPTR Service Fields
Registration Procedure:

New Service Fields are to be added via Standards Action as defined
in [RFC5226].
New entries to the table that specify additional transport protocols
for the existing Service Fields may be registered by IANA on a First
Come First Served' basis [RFC5226].

Initial contents of this registry will be:

Service Fields Protocol Reference
MIHIS+M2T TCP [RFC-mipshop-mos-dns-discovery-06]
MIHIS+M2U UDP [RFC-mipshop-mos-dns-discovery-06]
MIHIS+M2S SCTP [RFC-mipshop-mos-dns-discovery-06]
MIHES+M2T TCP [RFC-mipshop-mos-dns-discovery-06]
MIHES+M2U UDP [RFC-mipshop-mos-dns-discovery-06]
MIHES+M2S SCTP [RFC-mipshop-mos-dns-discovery-06]
MIHCS+M2T TCP [RFC-mipshop-mos-dns-discovery-06]
MIHCS+M2U UDP [RFC-mipshop-mos-dns-discovery-06]
MIHCS+M2S SCTP [RFC-mipshop-mos-dns-discovery-06]

We understand the above to be the only IANA Action for this document.

Reviewed the new version. Some things still need to be changed, but I'm
fine with the overall direction. Also, we still have to verify that
Patrick et al are happy with this, and resolve the issue that Vijay
raised.

A follow-up on the NAPTR issues. I had some misgivings about the way NAPTR is used here, and after a very quick discussion with some DNS experts, it seems that I have to ask this:

1) Why aren't you using S-NAPTR (RFC 3958)?

2) If you define a direct DDDS definition on top of NAPTR, you should really do everything that is required in RFC 3401 Section 4, and I don't think you are.

3) I do not understand the way that the IANA registrations have been made. Since several services may exist in the same domain, how do we ensure that MIPSHOP services and some other services do not collide? Note that with S-NAPTR this would have been easy.

I would recommend that the authors use RFC 3958 instead and change the relevant parts of the specification to switch to that, including the IANA registration.

But I have to confess that I am not at all a NAPTR expert myself. I looked at the RFCs in question for the first time few days ago. If you think what I am suggesting is wrong, please say so and we can talk about it. If you don't think you can do the above change on your own, also ask for help -- I can arrange experts that you could talk to about it.

My question to NAPTR experts:

I wonder if you could help me a bit with this: http://tools.ietf.org/html/draft-ietf-mipshop-mos-dns-discovery-03

The spec defines a very simple model for looking up "mobility servers" using NAPTR. The idea is that we'll have something like

          order pref flags  service    regexp      replacement  IN NAPTR  50  50  "s"  "IS+M2T"      ""  _IS._tcp.example.com  IN NAPTR  90  50  "s"  "IS+M2U"      ""  _IS._udp.example.com
They have a couple of service identifiers in addition to "IS", and allow transports with TCP, UDP, SCTP, and the same with TLS. The IANA considerations section says:

  The usage of NAPTR records described here requires well known values
  for the service fields for each transport supported by Mobility
  Services. The table of mappings from service field values to
  transport protocols is to be maintained by IANA.

  The following values have been placed into the registry:
    Service Fields              Protocol
    IS+M2T                        TCP
    ISs+M2T                TLSoverTCP (RFC4346)
    IS+M2U                        UDP
    ...
    New Service Fields are to be added via Standards Action as defined
  in [RFC5226].  New entries to the table, specifying additional transport protocols
  for the existing Service Fields may be requested from IANA on a
  First Come First Served' basis [RFC5226].

This smells wrong to me, and when I showed it to Olaf he also had question marks. I confess that I had not read the NAPTR RFCs before this day, and I still don't fully understand them. However, here are my issues:

- Presumably there'd have to be a registration somewhere that ensures service identifiers for different services (mobility services, FOO service, etc) do not collide. Yet I cannot find the IANA registry that does this -- is there one? I do not think no one wants to configure clients with mysubdomain1.example.com etc if we'd go with subdomains for each service. And if you hardcode the subdomain names in software, that would have the same danger of a collision as in the service identifiers.

- I did however find S-NAPTR registry, perhaps this draft should be using RFC 3958 instead?

- If all the service identifiers are in a global space I do not understand how this draft can create new namespaces under it. You allocate the ones that you allocate, future allocations are with the same rules that exist for all apps.

- Is it customary to have a separate NAPTR entry for TLS and plain service?

AD review:

I have reviewed this draft, and found a small number of issues that you should fix before moving forward. I also need to talk to some further NAPTR experts, I have concerns about the IANA registration (more on that later). But please fix these issues first.

Technical:

Change the title to include "IEEE 802.21 mobility services", per suggestions from reviewers.

>    The services relevant for the task of transport protocol selection
>    are those with NAPTR service fields with values "IS+M2X" for IS
>    service, "ES+M2X" for the ES service, "CS+M2X" for the CS service,
>    where X is a letter that corresponds to a transport protocol
>    supported by the domain.

Why are the secure versions not listed here? Perhaps you could say ".... with values "ID+M2X" for ID is the service identifier defined in the previous section and X is a ..."

> This specification defines M2U for UDP, M2T for TCP and M2S for SCTP.

I would recommend removing SCTP, because -mstp-solution does not support it. As I recall, 802.21 does not support it either, (though some references to SCTP remain in the text; maybe that has been an error).

> New Service Fields are to be added via Standards Action as defined in [RFC5226]. New entries to the table, specifying additional transport protocols for the existing Service Fields may be requested from IANA on a First Come First Served' basis [RFC5226].

IESG Approval makes more sense for this, IMO. Its a rare event, and IESG approval is actually easier for most situations than an expert review, because a draft that comes through the IETF does not need to be sent separately to an expert. And I agree with Vijay's comments on list about one table having a too complicated IANA rule. But this points relates to the NAPTR worry that I'm investigating; I need to come back on that.

Editorial:

In the abstract (or perhaps even in the title, see above), the first time you say "mobility services", I would recommend you say "IEEE 802.21 mobility services". This makes the scope of the document much clearer.

Please open the acronym "MN" in the abstract, and give the reference as "IEEE 802.21".

References: please renumber. Having reference [1] after all the others looks a bit silly. Same does [2] (an RFC) followed by [RFC4033], also an RFC.

>    Service Management" service messages, i.e., MIH registration, MIH
Missing or extra "

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

Vijay Devarapalli is the Document Shepherd for this document. I
have reviewed the document and it is ready for forwarding to the
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?

This document has had adequate reviews from the members in the MIPSHOP
WG. Reviews were also sought from the DNS directorate. Thomas Narten
responded and reviewed the document. I have no concerns about the depth
or breadth of the reviews that have been performed.

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

None.

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

No specific concerns.

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

There is WG consensus in advancing this document.

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

No.

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

No ID nits were found. The document meets all the requirements.

(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 document splits the references into normative and
informative references. There are no downward 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 IANA considerations section exists and is consistent with
the body of the document. The document requests reservations in
the appropriate IANA registries. The IANA registries that need to
be modified/created are clearly identified.

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

Does not apply.

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

This document defines application service tags that allow service
location without relying on rigid domain naming conventions, and DNS
procedures for discovering servers which provide Mobility Services.
Mobility Services are used to assist a mobile node in handover
preparation (network discovery) and handover decision (network
selection). The services addressed by this document are the Media
Independent Handover Services defined in [1].

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?

None.

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?

There are no known implementations or vendor plans to implement
the specification.

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

Document shepherd: Vijay Devarapalli
Responsible AD: Jari Arkko/Mark Townsley