Subject: [Mipshop] Comments on draft-ietf-mipshop-mos-dns-discovery-00

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 09 May 2008 10:51:22 -0700

Hi Gabor,

How about also describing the simple case of the mobile node
doing a DNS lookup for the MoS service assuming the mobile
node is configured with a string like _IS_._tcp.exmaple.com.
There would be no need to use NAPTR records for this simple
case. Then we can describe how it is supposed to work with
NAPTR records.

Or do you think that is too trivial to describe?

A few minor comments on the document.

>    The MN MUST discard any service fields that identify a resolution 
>    service whose value is not "M2X", for values of X that indicate 
>    transport protocols supported by the client.  The NAPTR processing 
>    as described in RFC 2915 will result in the discovery of the most 
>    preferred transport protocol of the server that is supported by the 
>    client, as well as an SRV record for the server. 

RFC 2915 seems to have been obsoleted by RFC 3403. We should
refer to RFC 3403.

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

What is the default port number? Did we define any in another
document?

> 3. IANA considerations 
>     
>    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. New entries in the 
>    table MAY be added through the publication of standards track RFCs, 
>    as described in RFC 2434 [4]. 
>     
>    The registration in the RFC MUST include the following information: 
>     
>         Service Field: The service field being registered.  
>          
>         Protocol: The specific transport protocol associated with that 
>         service field.  This MUST include the name and acronym for the 
>         protocol, along with reference to a document that describes the 
>         transport protocol. 
>          
>         Name and Contact Information: The name, address, email address 
>         and telephone number for the person performing the 
>         registration. 
>     
>    The following values have been placed into the registry: 
>     
>    Service Fields               Protocol 
>    IS+M2T                       TCP 
>    IS+M2U                       UDP 
>    IS+M2S                       SCTP 
>    ES+M2T                       TCP 
>    ES+M2U                       UDP 
>    ES+M2S                       SCTP 
>    CS+M2T                       TCP 
>    CS+M2U                       UDP 
>    CS+M2S                       SCTP 
>     
>    Name and contact information of the person performing the 
>    registration: 
>    Gabor Bajko, email: [email-masked] 

If the values are being reserved by an RFC, then there is no need
to provide contact information. IANA would be referring to the
corresponding RFC.

BTW, do we want new values to be assigned just by a request to the
IANA? If you want anyone to be able to request for a new value from
the IANA, then you would need to say new values can be assigned by
the IANA on a "First Come First Served" basis.

Currently the first paragraph in the IANA Considerations section
says "Standards Track". That means new values can be assigned only
by Standards Track RFCs.

> 5. Normative References 

RFC 3403 is missing.

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

---

From: <[email-masked]>
Date: Mon, 19 May 2008 14:06:05 -0500

Hi Vijay,

  >-----Original Message-----
  >From: ext Vijay Devarapalli [mailto:[email-masked]] 
  >Sent: Friday, May 09, 2008 10:51 AM
  >To: Bajko Gabor (Nokia-OCTO/MtView); [email-masked]
  >Subject: Comments on draft-ietf-mipshop-mos-dns-discovery-00 
  >
  >Hi Gabor,
  >

It is actually described (implicitely) on page 4. I'll add another
paragraph saying when a NAPTR query can be skipped.

  >RFC 2915 seems to have been obsoleted by RFC 3403. We should 

Ok.

  >What is the default port number? Did we define any in 
  >another document?

I.D.draft-ietf-mipshop-mstp-solution intends to reserve default port
numbers, one tcp and one upd for each  service.

  >If the values are being reserved by an RFC, then there is no 
  >need to provide contact information. IANA would be referring 
  >to the corresponding RFC.

Ok, I'll delete the contact info. 
I'll submit a new version with the changes today.
Thanks for your review and comments.

- Gabor

  >BTW, do we want new values to be assigned just by a request 
  >to the IANA? If you want anyone to be able to request for a 
  >new value from the IANA, then you would need to say new 
  >values can be assigned by the IANA on a "First Come First 
  >Served" basis.
  >
  >Currently the first paragraph in the IANA Considerations 
  >section says "Standards Track". That means new values can be 
  >assigned only by Standards Track RFCs.
  >
  >> 5. Normative References
  >
  >RFC 3403 is missing.
  >
  >Vijay
  >

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 19 May 2008 18:38:26 -0400

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, May 19, 2008 12:06 PM
> To: Vijay Devarapalli; [email-masked]
> Subject: RE: Comments on draft-ietf-mipshop-mos-dns-discovery-00 
> 

Please do.

> numbers, one tcp and one upd for each  service.

Can you refer to that in this paragraph? When you read the above
paragraph it is not clear which default port to use.

>   >assigned only by Standards Track RFCs.

You didn't answer this question. I think we should go with "First Come
First Served". I don't see any reason to assign new values only through
standards track RFCs.

Vijay

---

From: <[email-masked]>
Date: Mon, 19 May 2008 19:41:14 -0500

Hi Vijay,

I am about to upload a new version of the document. The summary of the
changes: 

I added a new paragraph to section 2.2: " If the client implementation
is restricted 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."

Replaced RFC 2915 with RFC 3403.

Added reference to [ID.ietf-mipshop-mstp-solution] at two instances
where default port numbers are mentioned.

I removed the sentence "New entries in the table MAY be added through
the publication of standards track RFCs" and added the sentence "New
entries to the registry MAY be added by IANA on a "First Come First
Served" basis."

Deleted the contact info.

I hope I captured all comments. Thanks for the comments.

- Gabor

  >Sent: Monday, May 19, 2008 3:38 PM
  >Can you refer to that in this paragraph? When you read the 
  >above paragraph it is not clear which default port to use.
  >
  >You didn't answer this question. I think we should go with 
  >"First Come First Served". I don't see any reason to assign 
  >new values only through standards track RFCs.
  >
  >Vijay
  >

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 19 May 2008 21:28:12 -0400

>    is not necessary, but only an SRV lookup of _ES._udp.example.com."

It is not necessarily a restriction. In the most simple mode, the client
is configured with the FQDN that it needs to perform a DNS lookup for.
The FQDN could be _ES._udp.example.com for example. So the mobile node
obtains the MoS server information just based on the one lookup.

Vijay