Subject: [Mipshop] I-D ACTION:draft-ietf-mipshop-mos-dns-discovery-02.txt

From: [email-masked]
Date: Mon, 22 Sep 2008 13:30:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Mobility for IP: Performance, Signaling and Handoff Optimization Working Group of the IETF.

	Title		: Locating Mobility Servers using DNS
	Author(s)	: G. Bajko
	Filename	: draft-ietf-mipshop-mos-dns-discovery-02.txt
	Pages		: 8
	Date		: 2008-9-22
	
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 an MN 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].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mipshop-mos-dns-discovery-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Mipshop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mipshop

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 24 Sep 2008 20:08:04 -0400

Hi Gabor,

A few comments. 

There is typo in section 1. The first line mainly...

   Service Management" service messages, i.e., MIH registration, MIH 
   capability discovery and MIH event subscription messages, are 
   considered as ES and CS when transporting MIH messages over L3 
   transport. 

I would like the following text to be put back

   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.

I still think it should be possible for the mobile node to do a SRV
query without the NAPTR query if it knows what service it wants and also
knows which protocol will be used.

The IANA considerations section needs a fix. The service field "IS+M2T"
already implies that TCP is being used for the IS service. We are NOT
defining two registries, one for the service names and one for the
transport protocols. So the following text does not make sense.
    
   New Service Fields are to be added via Standards Action as defined 
   in [RFC5226]. New protocols to existing Service Fields are added by 
   IANA on a First Come First Served' basis [RFC5226]. 

We are creating just one registry. Each entry we define in this registry
already says what the service and the transport protocol are. Assuming
we go with Expert Review [RFC5226], I suggest modify the above paragraph
to

   New Service Fields can be added by IANA through Expert Review
[RFC5226].

Thomas Narten had concerns with FCFS, which I think are addressed by the
above sentence.

Vijay

[email-masked] wrote:
> directories. This draft is a work item of the Mobility for IP:
> Performance, Signaling and Handoff Optimization Working Group
> of the IETF.
> 
Pages		: 8

---

From: <[email-masked]>
Date: Thu, 25 Sep 2008 12:12:30 -0500

Inline:

  >-----Original Message-----
  >From: ext Vijay Devarapalli [mailto:[email-masked]]
  >Sent: Wednesday, September 24, 2008 5:08 PM
  >To: Bajko Gabor (Nokia-OCTO/MtView)
  >Cc: [email-masked]
  >Subject: RE: [Mipshop] I-D
ACTION:draft-ietf-mipshop-mos-dns-discovery-
  >02.txt

Ok

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

Can you respond to Thomas's mail on this issue?

  >knows which protocol will be used.

As Thomas stated: "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?"

And that is NOT the intent in this document.

  >we go with Expert Review [RFC5226], I suggest modify the above
paragraph

The intent is to say that a new entry like "IS+M2D" (IS over DCCP) can
be created without the need for an RFC. But an entry like "BANANA+M2T"
(BANANA over TCP) would need an RFC describing the BANANA service
aspects.

-  Gabor

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 25 Sep 2008 13:41:39 -0400

[email-masked] wrote:

>   >The IANA considerations section needs a fix. The service field
>   "IS+M2T" >already implies that TCP is being used for the IS service.
> We are NOT
>   >transport protocols. So the following text does not make sense.   >
>   >   in [RFC5226]. New protocols to existing Service Fields are
>   added by >   IANA on a First Come First Served' basis [RFC5226].   >
>   >We are creating just one registry. Each entry we define in this
>   registry >already says what the service and the transport protocol
>   are. Assuming >we go with Expert Review [RFC5226], I suggest modify
>   the above paragraph >to
> 

Understood. But this would be difficult for IANA to enforce since we are
just creating one registry. We typically says "Standards Action" or
"FCFS" for the new registry we are creating. This document requires IANA
to distinguish between a request for adding a new service and a request
for adding a new service field so that an existing service can be
carried over a new transport protocol. I don't know if IANA can do this.

Lets keep the text as is for now then. But we should check with IANA now
itself. 

Vijay