Locating IEEE 802.21 Mobility Services Using DNS
RFC 5679

Note: This ballot was opened for revision 07 and is now closed.

(Jari Arkko) Yes

(Lars Eggert) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Ralph Droms) No Objection

(Lisa Dusseault) No Objection

(Adrian Farrel) No Objection

Comment (2009-07-02 for -)
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

(Cullen Jennings) No Objection

Comment (2009-06-30 for -)
support Alexey IANA discuss

Alexey Melnikov (was Discuss) No Objection

(Tim Polk) No Objection

(Dan Romascanu) (was Discuss) No Objection

Comment (2009-07-02)
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.

(Robert Sparks) (was Discuss) No Objection

Comment (2009-07-01)
Support Dan's discuss on the need for clarification of "If the SRV record did not contain a port number..."

(Magnus Westerlund) (was Discuss) No Objection