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

"Telemaco Melia (tmelia)" <> Mon, 14 April 2008 11:55 UTC

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id F3DA828C2CD; Mon, 14 Apr 2008 04:55:44 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0583F28C2E0 for <>; Mon, 14 Apr 2008 04:55:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.41
X-Spam-Status: No, score=-6.41 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ptrEoVCYxQMZ for <>; Mon, 14 Apr 2008 04:55:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 73CC628C2D1 for <>; Mon, 14 Apr 2008 04:55:40 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.25,655,1199660400"; d="scan'208,217";a="6201329"
Received: from ([]) by with ESMTP; 14 Apr 2008 13:56:04 +0200
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id m3EBu4s3030270; Mon, 14 Apr 2008 13:56:04 +0200
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id m3EBu4Ag014665; Mon, 14 Apr 2008 11:56:04 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Apr 2008 13:56:04 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 14 Apr 2008 13:56:53 +0200
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [MIPSHOP-MIH-DT] draft-ietf-mipshop-mstp-solution-02.txt
Thread-Index: AciYzxGREQhChYyTQXiWcXNZoqr8AABuY1KQAFV81HAAkf0T0A==
References: <><> <>
From: "Telemaco Melia (tmelia)" <>
To: "Subir Das" <>, <>, <>
X-OriginalArrivalTime: 14 Apr 2008 11:56:04.0769 (UTC) FILETIME=[846C3910:01C89E26]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14598; t=1208174164; x=1209038164; c=relaxed/simple; s=amsdkim2001; 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=R/RLHRIco1ULfMyIDqULZoy85eTAxLnmiNEptZGHIAI=; b=QVtsOn30KJ0NCTUWgdSh3/h9VWiOIB3k4HHiT5NLYowGeW5E/3PFDePz/F ECpFby103L885H/6kpvc1EBcg0lZdxL8M4aqvQTr8k8C9nE3qBoqntEUsW2o b1AoS+ov2v;
Authentication-Results: ams-dkim-2;; 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: <>, <>
Content-Type: multipart/mixed; boundary="===============0461921896=="

Your silence scares me...are you fine with the doc?


[] On Behalf Of Telemaco Melia
Sent: Friday, April 11, 2008 4:30 PM
Subject: Re: [MIPSHOP-MIH-DT] draft-ietf-mipshop-mstp-solution-02.txt

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