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

From: "Vijay Devarapalli" <[email-masked]>
Date: Sat, 6 Sep 2008 11:37:41 -0400

I guess I never responded to this email.

 > -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, July 28, 2008 8:10 AM
> To: Vijay Devarapalli
> Subject: RE: Thomas Narten's review of 
> draft-ietf-mipshop-mos-dns-discovery
> 
> Vijay,
> 
> This was added as per your request:
>   >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.
> 
> I think I would need to remove it and maybe instead state that NAPTR
> queries are only done when the MN supports multiple transports,
> somewhere at the beginning of the document. Right?

So what would the text in the draft say if the MN only supports one
transport protocol for the mobility services? Wouldn't the result be the
same?  If the MN supports multiple transports, then it goes through with
a NAPTR query followed by a SRV query. If it supports only one
transport, it directly sends a SRV query. 

If the MN wants to discover all the possible types of SRV records, then
the NAPTR lookup is necessary. Otherwise it can directly do the SRV
lookup, right?

Anyway, its not a big deal for me, if there is always an NAPTR lookup
followed by a SRV query. It is not like you will be discovering the MoS
servers frequently.

Vijay

> - Gabor
> 
>  
> 
>   >-----Original Message-----
>   >From: ext Vijay Devarapalli [mailto:[email-masked]] 
>   >Sent: Thursday, July 24, 2008 11:54 AM
>   >To: [email-masked]
>   >Cc: Bajko Gabor (Nokia-OCTO/MtView)
>   >Subject: Thomas Narten's review of 
>   >draft-ietf-mipshop-mos-dns-discovery
>   >
>   >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

---

From: <[email-masked]>
Date: Mon, 15 Sep 2008 21:48:52 -0500

Some answers inline:

Thanks,
- gabor

  >I have some general concerns, but I'm  not sure how strong there are.
  >
  >    as "IS", "ES", or "CS", and "X" is "T" for TCP, "U" for UDP, "S"
  >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

Yes, the replacement field from the NAPTR query.

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

There are two possibilities: 
- an MN looking for a mobility service in example.com makes a NAPTR
query, then constructs the SRV query based on the service, protocol and
domain name returned in the NAPTR query
- an MN looking for a mobility service in example.com assumes, without
making a NAPTR query, that there is a mobility server hosting the
desired service, accessible using TCP, and constructs the SRV query
accordingly. If a server hosting the service on top of TCP does not
exist in example.com, an error is returned.

The hit rate in the first case is certain, while in the second case is
unpredictable. 

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
implement
  >   policies which restrict access to certain domains.  As an example,
  >   even though the SRV record for TCP is _IS._tcp.school.edu, there
  >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 text is there to avoid the case when the MN is directed to a domain
where it does not have access to.

Since we agreed in Dublin to not use DNS to discover MoS in visited
network, I can very well remove this paragraph now.

  >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:
  >
  >
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
implement
  >   policies which restrict access to certain domains.  As an example,
  >   even though the SRV record for TCP is _IS._tcp.school.edu, there
  >Don't understand/follow this. It may just need rewording. I.e.,
"which
  >domain" is being talked about?
See above.
  >   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
This was added per request of an earlier review. Yes, this field needs
to be supported by RFC3401-03 compliant implementations.

  >   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

I removed this sentence, it must be a leftover from previous revisions.

  >   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
  >Huh? Why say this? This seems unnecessary, undesirable.

Right, removed.
  
  >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.

Corrected.

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

Modified to say: "New Service Fields MAY be added through the
publication of standards track RFCs, as described in RFC 2434 [4]. New
protocols to existing Service Fields MAY be added by IANA on a 'First
Come First Served' basis.". 

Please let me know if the resolutions are acceptable. If there are no
more comments, I will post version -02 of the draft.

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

---

From: <[email-masked]>
Date: Mon, 15 Sep 2008 21:51:56 -0500

>the NAPTR lookup is necessary. Otherwise it can directly do the SRV

Well, it can, but it might not get an answer. Domain admins can use DNS
NAPTRs to direct traffic to or away from a specific server or domain,
using the pref and replacement fields. The thing is, making an SRV query
just because only one transport prot is supported for a specific service
vs a NAPTR query, is not equivalent.

- gabor

  >Sent: Saturday, September 06, 2008 8:38 AM
  >To: Bajko Gabor (Nokia-OCTO/MtView)
  >Cc: [email-masked]
  >Subject: RE: Thomas Narten's review of draft-ietf-mipshop-mos-dns-
  >discovery
  >

---

From: Thomas Narten <[email-masked]>
Date: Tue, 16 Sep 2008 16:57:17 -0400

> The hit rate in the first case is certain, while in the second case is

So why allow this? This sort of unpredictability can easily lead to
operational problems and failures.

I also take it that you are proposing no change to the document on
this point.

> network, I can very well remove this paragraph now.

OK

> to be supported by RFC3401-03 compliant implementations.

The field must be supported, yet you discourage it's use. Why not just
say must be zero to keep things simple? Is there an actual use for
this?

> Come First Served' basis.".

Better:

    New Service Fields are be added via Standards Action as defined in
    [RFC 5226]. New protocols to existing Service Fields are added
    by IANA on a First Come First Served' basis [RFC 5226].

But that said, I still don't like FCFS for "new protocols". New
protocols are very rare (today, we only have UDP, TCP and SCTP). So I
wouldn't want anyone to be able to just add one. Can't you at least
make it require IESG approval or something, to insure some basic
sanity check?

Thomas

---

From: <[email-masked]>
Date: Tue, 16 Sep 2008 19:54:57 -0500

>From: ext Thomas Narten [mailto:[email-masked]]
  >Sent: Tuesday, September 16, 2008 1:57 PM
  >Cc: [email-masked]; [email-masked]
  >Subject: Re: [Mipshop] Thomas Narten's review of
draft-ietf-mipshop-mos-
  >dns-discovery

<snip>
  
  >I also take it that you are proposing no change to the document on

I should probably remove the sentence:

" If the client implementation is configured to only use one specific
transport protocol for a service, e.g. UDP for ES, then NAPTR query is
not necessary, but only an SRV lookup of _ES._udp.example.com."

from the draft, but that would not necessarily prevent a client
implementing RFC2782&RFCs3401-03 to make an SRV query without making a
NAPTR query first.  

different
example,
  >>   >Here, it is clear that the target DNS name and configured DNS
name
  >do
different
example,
services do
  >say must be zero to keep things simple? Is there an actual use for

Regexp is an integral part of NAPTR. Mentioning it is empty in MoS
discovery cases did not seem to satisfy earlier reviewers.

  >    by IANA on a First Come First Served' basis [RFC 5226].

Ok.
Thanks,
- gabor

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 24 Sep 2008 19:48:00 -0400

Thomas Narten wrote:

>> publication of standards track RFCs, as described in RFC 2434 [4].
>> New protocols to existing Service Fields MAY be added by IANA on a
>> 'First Come First Served' basis.".
> 
> Better:
> 

Perhaps we should modify it to say "Expert Review" instead of "FCFS".

Vijay

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 24 Sep 2008 19:50:30 -0400

[email-masked] wrote:

>   >> query, then constructs the SRV query based on the
> service, protocol
> and
>   >> - an MN looking for a mobility service in example.com assumes,
>   without >> making a NAPTR query, that there is a mobility server
>   hosting the >> desired service, accessible using TCP, and constructs
> the SRV query
>   >> The hit rate in the first case is certain, while in the
> second case
> is
>   >> unpredictable.
>   >
> implementing RFC2782&RFCs3401-03 to make an SRV query without making
> a NAPTR query first. 

I don't think this should be removed. A mobile node could always do a
SRV query if it knows which mobility service it wants and which
transport protocol is being used as a default. It does not have to do
the NAPTR query first.

Vijay

---

From: Thomas Narten <[email-masked]>
Date: Thu, 25 Sep 2008 09:51:10 -0400

"Vijay Devarapalli" <[email-masked]> writes:
> > a NAPTR query first.=

> transport protocol is being used as a default. It does not have to do

I client can chose to do many things. But does it need to explicitely
be called out in the spec that this is allowed? By calling it out, you
are encouraging such behavior. Is that the intent?

Thomas

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 25 Sep 2008 15:31:00 -0700

Hi Thomas,

> are encouraging such behavior. Is that the intent?

If I were implementing this, the first question I would have is, if I 
already know that TCP is being used for IS service and the IS service is 
what I am looking for, why can't I do a SRV lookup for 
_IS._tcp.example.com? I wouldn't find an answer to this question in the 
draft. We either allow this or not allow this. Saying nothing does not 
seem like a good idea to me.

Vijay

---

From: <[email-masked]>
Date: Thu, 25 Sep 2008 17:39:21 -0500

Vijay,

  >_IS._tcp.example.com?

You can, the details of it are described in RFC2782. 

  >I wouldn't find an answer to this question in the
  >draft. 

Because you are looking at the wrong document. The document to look for
is RFC2782.

  >We either allow this or not allow this. 

We can not say DNS SRVs MUST NOT be used. That is, it can be used. The
draft does not add new functionality to RFC2782, does not update it,
does not obsolete it. Whatever is written in RFC2782, remains valid.

  >Saying nothing does not

It does to me.

- Gabor

  >Sent: Thursday, September 25, 2008 3:31 PM
  >To: Thomas Narten
  >Cc: Bajko Gabor (Nokia-OCTO/MtView); [email-masked]
draft-ietf-mipshop-mos-
  >>  > I don't think this should be removed. A mobile node could always
do
  >>  > transport protocol is being used as a default. It does not have
to

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 25 Sep 2008 15:45:40 -0700

> You can, the details of it are described in RFC2782. 

Yes, but draft-ietf-mipshop-mos-dns-discovery is saying if you are 
discovering MIH servers, you must do a NAPTR query followed by a SRV query.

> does not obsolete it. Whatever is written in RFC2782, remains valid.

Well, the paragraph that was deleted was just explaining the fact that 
you can use RFC 27823 and do a SRV lookup with the appropriate service 
field.

I don't know what we are achieving by not recognizing the fact in the draft.

Vijay

---

From: <[email-masked]>
Date: Thu, 25 Sep 2008 17:53:03 -0500

>discovering MIH servers, you must do a NAPTR query followed by a SRV

Hm. I reviewed the draft again, but I could not find this. Can you point
me out where exactly you saw it?

-gabor

  >Sent: Thursday, September 25, 2008 3:46 PM
  >Cc: [email-masked]; [email-masked]
draft-ietf-mipshop-mos-
  >>   >If I were implementing this, the first question I would have is,
if
  >I
  >>   >already know that TCP is being used for IS service and the IS
  >service
  >> is
  >>   >>  > > " If the client implementation is configured to only use
one
  >>   >specific
  >>   >>  > > transport protocol for a service, e.g. UDP for ES, then
NAPTR
  >>   >query is
  >>   >>  > > implementing RFC2782&RFCs3401-03 to make an SRV query
without
  >>   >making
  >>   >> be called out in the spec that this is allowed? By calling it
out,
  >> you
  >>   >If I were implementing this, the first question I would have is,
if
  >I
  >>   >already know that TCP is being used for IS service and the IS
  >service
  >> is
  >>   >_IS._tcp.example.com? I wouldn't find an answer to this question
in
  >> the
  >>   >draft. We either allow this or not allow this. Saying nothing
does
  >> not

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 25 Sep 2008 19:03:47 -0400

[email-masked] wrote:
>   >discovering MIH servers, you must do a NAPTR query
> followed by a SRV
>   >query.
> 

The entire draft talks about what the mobile node needs to do. It first
does a NAPTR query, gets the service name in response, and then does a
SRV query. I admit the draft does not say "the MN MUST do a NAPTR
query". But IMO, it leaves the entire procedure ambiguous.

Vijay

>   draft-ietf-mipshop-mos- >dns-discovery
>   >
>   >service >> is
>   >>   >what I am looking for, why can't I do a SRV lookup for   >>  
>   >_IS._tcp.example.com? >>
>   >> You can, the details of it are described in RFC2782.   >
>   >discovering MIH servers, you must do a NAPTR query
> followed by a SRV
>   >query.
>   >
>   >>
>   >>   >I wouldn't find an answer to this question in the   >>  
>   >draft. >>
>   >> Because you are looking at the wrong document. The
> document to look
> for
>   >> is RFC2782.
>   >>
>   >> We can not say DNS SRVs MUST NOT be used. That is, it
> can be used.
> The
>   >> draft does not add new functionality to RFC2782, does not update
>   it, >> does not obsolete it. Whatever is written in RFC2782,
>   remains valid. >
>   >Well, the paragraph that was deleted was just explaining the fact
>   that >you can use RFC 27823 and do a SRV lookup with the
>   appropriate service >field.
>   >
>   >I don't know what we are achieving by not recognizing the
> fact in the
>   >draft.
>   >
>   >Vijay
>   >
>   >>
>   >>   >Saying nothing does not
>   >>   >Subject: Re: [Mipshop] Thomas Narten's review of   >>
>   draft-ietf-mipshop-mos- >>   >dns-discovery
>   >>   >
>   >>   >Hi Thomas,
>   >>   >
>   >>   >Thomas Narten wrote:
>   >>   >>  > > I should probably remove the sentence:   >>   >>  > >
>   >>   >>  > > transport protocol for a service, e.g. UDP for ES,
>   then NAPTR >>   >query is
>   >>   >>  > > not necessary, but only an SRV lookup of   >>
>   _ES._udp.example.com." >>   >>  > >
>   >>   >>  > > from the draft, but that would not necessarily
> prevent a
>   >> client
>   without >>   >making
>   >>   >>  > I don't think this should be removed. A mobile node
>   could   >always >> do
>   >>   >a
>   >>   >>  > SRV query if it knows which mobility service it wants
>   and which >>   >>  > transport protocol is being used as a default.
> It does not
> have
>   >> to
>   >>   >do
>   >>   >>  > the NAPTR query first.
>   >>   >>
>   >>   >> I client can chose to do many things. But does it need to  
>   >> explicitely >>   >> be called out in the spec that this is
> allowed? By 
> calling it
> out,
>   >> you
>   >>   >> are encouraging such behavior. Is that the intent?   >>   >
>   >service >> is
>   does >> not

---

From: <[email-masked]>
Date: Thu, 25 Sep 2008 18:09:45 -0500

>Sent: Thursday, September 25, 2008 4:04 PM
  >Subject: RE: [Mipshop] Thomas Narten's review of
draft-ietf-mipshop-mos-
  >SRV query. 

It's an example usage.

  >I admit the draft does not say "the MN MUST do a NAPTR
  >query". 

And it was written as such intentionally.

  >But IMO, it leaves the entire procedure ambiguous.

RFCs complement each other, they do not replace each other, unless
stated otherwise. This document does not intend to update RFC2872, thus
I do not see any ambiguity.

- Gabor

  >>   >>   >>  > > I should probably remove the sentence:   >>   >>  >
>
  >>   >>   >> are encouraging such behavior. Is that the intent?   >>
>