Subject: [Mipshop] Thomas Narten's review of draft-ietf-mipshop-mos-dns-discovery

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 24 Jul 2008 14:53:42 -0400

FYI 

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Thursday, July 24, 2008 11:48 AM

I have some general concerns, but I'm  not sure how strong there are.

First, my understanding is that the  overall algorithm is:

1) MN somehow knows (e.g., via DHCP) which domain it wants mobility
   info from. Let's call it target.example.com.

2) The MN does a NAPTR query for target.example.com.

2a) A NAPTR RR response contains a service name of the form
    <service>+X, where <service> is a defined mobility service such
    as "IS", "ES", or "CS", and "X" is "T" for TCP, "U" for UDP, "S"
    for SCTP, etc. (For example "CS+T")

2b) MN decides which service/transport it wants to use from the list
    of returned NAPTR RRs

2c) From the chosen NAPTR RR, MN uses the target DNS name as the DNS
    name where the service is located. (e.g., the target might be
    _ES._tcp.target.example.com)

2d) MN generates SRV query using name in 2c).

2e) Contact server(s) based on SRV response.

The above is all straightforward, and I don't see any issue right
off. But what I don't quite like is that there are a bunch of
exceptions and the above steps can be skipped. This may lead to
operational problems.

E.g., if the MN only supports (say UDP) for accessing a mobility
service, it (per the spec) simply skips the NAPTR query and goes to
2d), using target.example.com as the domain name and then prepending
(say) _ES._udp to it.

There is no requirement that the NAPTR RR in 2c) above has to be
target.example.com. It could be foo.bar.com. So now there is the
chance for inconistencies in behavior, with different NMs getting
different behavior (i.e, those that query for NAPTR and those that
skip the step).

Also, there is a rule:

   It is not necessary for the domain suffixes in the NAPTR replacement 
   field to match the domain of the original query (i.e., example.com 
   above).  However, a domain MUST maintain SRV records for the domain 
   of the original query, even if the NAPTR record is in a different 
   domain, as the access network the MN is attached to might implement 
   policies which restrict access to certain domains.  As an example, 
   even though the SRV record for TCP is _IS._tcp.school.edu, there 
   MUST also be an SRV record at _IS._tcp.example.com.

Here, it is clear that the target DNS name and configured DNS name do
not have to be same. Yet, it is stated that some MN's will ignore such
names, so both names have to be maintained.  This to me seems like a
recipe for confusion and operational problems. Is this sort of
inconcistency really needed to be supported by the protocol?

Maybe the better way to describe this algorithm is to make the case
for when NAPTR should be used at all. Why is it needed if the NM can
chose to skip that step?

more detaild comments:

   It is not necessary for the domain suffixes in the NAPTR replacement 
   field to match the domain of the original query (i.e., example.com 
   above).  However, a domain MUST maintain SRV records for the domain 
   of the original query, even if the NAPTR record is in a different 
   domain, as the access network the MN is attached to might implement 
   policies which restrict access to certain domains.  As an example, 
   even though the SRV record for TCP is _IS._tcp.school.edu, there 
   MUST also be an SRV record at _IS._tcp.example.com. 

Don't understand/follow this. It may just need rewording. I.e., "which
domain" is being talked about?

   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. 

Sounds weak. Is it allowed? MUST clients support this field?

   If no SRV records are found, the client SHOULD use TCP to contact a 
   server which hosts an IS service and UDP to contact a server which 
   hosts an ES and/or CS service.  

Which server name, exactly?

   If the MN knows the IP address of the server, it may contact the 
   server using the default port number for that service. Default port 
   numbers for IS, ES and CS services are requested from IANA in 
   [ID.ietf-mipshop-mstp-solution].    

Huh? Why say this? This seems unnecessary, undesirable.

The transition to Section 2.3 seems out of place. Shouldn't this just
be a continuation of the previous section for the case where a NAPTR
RR exists? If so, why not include it there? Perhaps the separate
subsection should be for when there is no NAPTR RR. That is presumably
a standalone action.

   If the TARGET was not a numeric IP address, then the MN performs an 
   A or AAAA record lookup of the domain name. The result will be a 

Don't just say "or" here. Correct process is to do a lookup "for A
and/or AAAA records as appropriate" or some such.

   New entries to the registry MAY be added by IANA on a "First Come 
   First Served" basis. 

Seems like a least some superficial review be done. Not much review,
but more than FCFS, IMO. For starters, one doesn't expect many of
these to ever be assigned, since they are for transport protocols.

Thomas

_______________________________________________
Mipshop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mipshop