Re: [MIPSHOP-MIH-DT] draft-ietf-mipshop-mstp-solution-02.txt

"Telemaco Melia (tmelia)" <> Fri, 11 April 2008 14:30 UTC

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id D6A613A6E92; Fri, 11 Apr 2008 07:30:38 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 711063A6E86 for <>; Fri, 11 Apr 2008 07:30:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.334
X-Spam-Status: No, score=-6.334 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i+pqxaZAjKgt for <>; Fri, 11 Apr 2008 07:30:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7D85B28C12D for <>; Fri, 11 Apr 2008 07:30:01 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.25,642,1199660400"; d="txt'?scan'208,217";a="6051427"
Received: from ([]) by with ESMTP; 11 Apr 2008 16:29:24 +0200
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id m3BETOcR002029; Fri, 11 Apr 2008 16:29:24 +0200
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id m3BETOxu014142; Fri, 11 Apr 2008 14:29:24 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Apr 2008 16:29:24 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C89BE0.6FFD3204"
Date: Fri, 11 Apr 2008 16:30:08 +0200
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [MIPSHOP-MIH-DT] draft-ietf-mipshop-mstp-solution-02.txt
Thread-Index: AciYzxGREQhChYyTQXiWcXNZoqr8AABuY1KQAFV81HA=
References: <> <>
From: "Telemaco Melia (tmelia)" <>
To: <>, <>
X-OriginalArrivalTime: 11 Apr 2008 14:29:24.0119 (UTC) FILETIME=[706C6270:01C89BE0]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=99980; t=1207924164; x=1208788164; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:=20=22Telemaco=20Melia=20(tmelia)=22=20<tmelia@cisco. com> |Subject:=20RE=3A=20[MIPSHOP-MIH-DT]=20draft-ietf-mipshop-m stp-solution-02.txt |Sender:=20; bh=cQ+n8KfYWGVt0ks53Rt4QGTDS+yJutCEeV4et+YA7g4=; b=bANhwFD5IxlE7VDEsyDyt+uXyl0DGvCBgFhrpA1qiWtcqOGzCLS2+mny+o O/ldSaDY+Uw9/qi93tNfTODQlgozUTFvBGZHn/QTxqh+S8WPOfFoJ8moY6Nu dnt87jawPL;
Authentication-Results: ams-dkim-1;; dkim=pass ( sig from verified; );
Subject: Re: [MIPSHOP-MIH-DT] draft-ietf-mipshop-mstp-solution-02.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: MIPSHOP Media Independent Handover Design Team List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Gabor, all,
I updated the text according to your suggestions (slightly modified
though). Doc is attached.
I have been spending some time checking what would be the required
changes to delete the remark added at the end of section 5.3.
I would like to know what Vijay and Stefano think about the issue. Do
you see use cases requiring an update to the specs?
If yes, please let us know as soon as possible so we can update all the
If not then we can post version -02 and boost the discussion around the
adoption of new documents. 

From: [] 
Sent: Thursday, April 10, 2008 12:15 AM
To: Telemaco Melia (tmelia);
Subject: RE: [MIPSHOP-MIH-DT] draft-ietf-mipshop-mstp-solution-02.txt

Hi Tele,
to the comment in 5.2 lets add this note (after the previous paragraph,
ending ' ... DNS query')
When the discovery of an MoS at the visited network, using the FQDN
returned in the reverse DNS query, is not successful, the MN MAY attempt
to remove portions from the left side of the FQDN and attempt discovery
again. The process MAY be repeated iteratively until a successful

section 5.4:

modify this sentence: "If the  MN does not yet know the domain name of
the network, learning it may
   require more than one operation, as pre-configuration and DHCP
   methods can not be used."

to: "If the  MN does not yet know the domain name of the network,
learning it may
   require more than one operation, as  DHCP based discovery can not be
used and pre-configuration is not a feasible solution in case of an
arbitrary remote network."

regarding the comment in 5.3: rfc4004 does not specify how the discovery
of an MoS could be done, it doesn't have a general purpose container.
One would need to define an extension to 4004 to be able to fetch eg a
preconfigured MoS address from the AAA (it could even be part of
draft-stupar-mos-diameter-options). I would reformulate it to this:

This section assumes the use of IPv6 or MIPv6 and DHCPv6 based
   mechanisms to discover MoS services in home while the MN is in
   visited network. If similar functionalities are desired for IPv4 or
MIPv4 and DHCPv4, additional AAA and DHCPv4 extensions would be
required. Since use cases requiring these extensions were not identified
at  the time of writing this document, they were excluded from the scope
of the document.

Vijay has left azairnet and his email address doesn't work any longer.
An implicit question is if he will continue with his mipshop chair tasks
or not. It may have an impact on these documents.

- Gabor


[] On Behalf Of ext Telemaco Melia
	Sent: Monday, April 07, 2008 9:48 AM
	Subject: [MIPSHOP-MIH-DT]
	Hi guys,
	Here is the revised version. All editorial comments have been
hopefully digested.
	There are only a couple of open points, you can track them
looking for [COMMENT].
	One is for Gabor, the second one is about the use of DHCPv4 to
discover MoS in visited networks only. Your opinion is welcome.
	Please go through the document and let me know anything else

MIPSHOP-MIH-DT mailing list