RE: [MIPSHOP-MIH-DT] Current status

Sam Xia <xiazhongqi@huawei.com> Tue, 04 September 2007 09:49 UTC

Return-path: <mipshop-mih-dt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISV1q-0007Ky-W0; Tue, 04 Sep 2007 05:49:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISV1p-0007Ks-H5 for mipshop-mih-dt@ietf.org; Tue, 04 Sep 2007 05:49:01 -0400
Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISV1n-0003Tb-6k for mipshop-mih-dt@ietf.org; Tue, 04 Sep 2007 05:49:01 -0400
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNU00G4S8K8BJ@szxga03-in.huawei.com> for mipshop-mih-dt@ietf.org; Tue, 04 Sep 2007 17:48:08 +0800 (CST)
Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JNU005EQ8K7U3@szxga03-in.huawei.com> for mipshop-mih-dt@ietf.org; Tue, 04 Sep 2007 17:48:08 +0800 (CST)
Received: from x49105 ([10.111.12.54]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JNU003PG8K304@szxml03-in.huawei.com> for mipshop-mih-dt@ietf.org; Tue, 04 Sep 2007 17:48:07 +0800 (CST)
Date: Tue, 04 Sep 2007 17:48:00 +0800
From: Sam Xia <xiazhongqi@huawei.com>
Subject: RE: [MIPSHOP-MIH-DT] Current status
In-reply-to: <46D6E642.1030703@netlab.nec.de>
To: 'Telemaco Melia' <telemaco.melia@netlab.nec.de>
Message-id: <000901c7eed8$aeaae350$360c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Thread-index: AcfrHPhBU4RzHkSdSPGNBiMmvGhJAgDrbceg
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813
Cc: mipshop-mih-dt@ietf.org
X-BeenThere: mipshop-mih-dt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: MIPSHOP Media Independent Handover Design Team List <mipshop-mih-dt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt>, <mailto:mipshop-mih-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www1.ietf.org/mailman/private/mipshop-mih-dt>
List-Post: <mailto:mipshop-mih-dt@ietf.org>
List-Help: <mailto:mipshop-mih-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt>, <mailto:mipshop-mih-dt-request@ietf.org?subject=subscribe>
Errors-To: mipshop-mih-dt-bounces@ietf.org

hi all,
Today's meeting is too late for me in Beijing.  I am glad that we have made
progress now than before.  For this initial verison, i have some comments.

1: General comments:
Except the discovery parts that seems like a solution, the other part look
more like architecture/suggestion, not like a detailed solution. I am sure
that there should be a distance to pushing this draft to become a working
group draft. we have to make more progress.

2: Technical  omments on the detailed text:

2.1: about the scenarios:
we have introduced four kinds of scenarios.  Is is possible that there
exists scenario mixture-output  from listed four scenarios?

2.2 about "section 4: solution overview"

we have good input from Gabor about discovery. But we have nothing about
transport protocol, rough description about architecture. we have to get
more valuable input.

2.3 about discovery mechnism using DHCP
since we support 4 kinds of different scenarios using DHCP discovery
mechnism, it is very possible that it is mobile node who designates which
MoSx will be used.  I suggest that we could add a DHCP option to express its
preference of MoSx in DHCP discovery/request messages.

2.4 about "draft-bajko-DHCP-discovery"
I have checked DHCP code space. It seems that we have no enough code value
to support 3 kinds MIH Service(IS, ES, CS).  My suggestion is that we could
converge 3 kinds of different codes (codes for is, es,cs) into one code that
is just mih code. and then we could design sub option to describe
information for IS, ES, CS.

2.5 about "section 6: MIH transport"
First, thanks Carlos for his input. 

>From the text,  I draw a conclusion that only one tranasport protocol can be
used for MIH message transport at the same time. Right?
As a good and flexible solution, we should provide means to let user select
and swith transport procol.
Could you tell me what the interface between MSTP and its user(MIHF) should
look like as well as corresponging interface attribute?  As a solution, I
think that we should prescribe the Server Access Point(primitive).

2.6 about  "section 8: Security Considerations"
Sorry, subir. It is not a good input.

Firstly, we should take into considerations security issues between MN and
MIH service provider.  not just security issue between MN and DNS server or
DHCP server. These issues are not introduced by MIH trasnport protocol. We
should focus on issue we have introduced when we are designing a new
protocol. right?

Secondly, this section does not discuss the security requirements, just
mentions making reference to PS document.  It is not good.

Thirdly,  this section does not discuss the security solution. 

Fourth, this section dees not discuss how to authenticate, replay
protect....

3: Question

If the WG adopts the solution draft, what about Gabor's two new drafts?


 Best Regards, Sam Xia 

> -----Original Message-----
> From: Telemaco Melia [mailto:telemaco.melia@netlab.nec.de] 
> Sent: Thursday, August 30, 2007 11:46 PM
> To: mipshop-mih-dt@ietf.org
> Subject: [MIPSHOP-MIH-DT] Current status
> 
> Dear all,
> 
> I have been reading the input Gabor provided with the IDs 
> draft-bajko-mos-dhcp-options-00 and draft-bajko-mos-dns-discovery-00.
> Thanks Gabor for the work. Here my comments:
> 
> o draft-bajko-mos-dhcp-options-00
> -1 terminology section should be aligned with the PS doc
> -2 introduction section: I do not think it is required, I 
> would prefer to refer to the solution doc and move the text 
> there if you want.
> -3 discussion on co-located MoS: move it to the solution 
> document when we talk about the transport
> 
> o draft-bajko-mos-dns-discovery-00
> - same as before for 1 and 2
> - refer to the solution document when you discuss on the 
> selection of the transport
> 
> During the nect AC we should then discuss the open points 
> noted in the draft.
> I also would like to receive from Nada an update of the 
> current status and see what text we can included in the first 
> version of the document.
> 
> As for the time of the AC I would propose to have it at 14:00 
> CET on Tuesday September 4th.
> Would  be fine with everybody?
> 
> Please le me know
> 
> Telemaco
> 



_______________________________________________
MIPSHOP-MIH-DT mailing list
MIPSHOP-MIH-DT@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt