Confirmation of adoption of draft-melia-mipshop-mstp-solution-01 as a WG document

Hello,

At the MIPSHOP WG meeting on December 5, there was consensus in the
room to adopt draft-melia-mipshop-mstp-solution-01 as a WG document.

This email is to confirm adopting this document as a WG document,
since all decisions taken in the face to face meeting need to be
confirmed on the mailing list. If anyone has objections or thinks
that this document still needs some work before it can be adopted
as a WG document, please send an email to the mailing list before
Dec 14th.

If you weren't at the meeting and agree with adopting this document,
please send an email supporting adopting the document.

Vijay (for the chairs)

Re: help with submitting my draft

I have never Word to write internet drafts, so can't help you there.
The final draft should be in the text form. Anything other than that
will be rejected by the secretariat.

xml2rfc (http://xml.resource.org/) is a good tool for writing
internet drafts.

Vijay

zfaqeer <at> hotmail.com wrote:
> Hello,
> 
> I have written as Internet Draft  based on the prescribed 2-Word-v2.0.template.dot template and hence
the resulting document was a word document.
> After submitting it, although I missed a deadline, i received an email that i should send it as TXT file.
> When i try to save my word document to TXT, i lose all the formating and the TXT file does not even contain the
Header and Footer information.
> Can you please guide me as to in which format shall I write my ID and which template shall i use?
> How can i preserve the formatting and header and footer in a text file? should i be using Notepad?
>  
> I would appreciate your help and assistance and guidance
>  
> Looking forward to a positive reply
>  
> Best Regards
>  
> Zarrar 
> _________________________________________________________________
> Connect and share in new ways with Windows Live.
> http://www.windowslive.com/connect.html?ocid=TXT_TAGLM_Wave2_newways_112007

CALL FOR PAPERS: 50th International Symposium ELMAR-2008

  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          50th International Symposium ELMAR-2008
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  

           10-13 September 2008, Zadar, Croatia

           Submission deadline: March 03, 2008

              http://www.elmar-zadar.org/

  
           CALL FOR PAPERS AND SPECIAL SESSIONS

  
  TECHNICAL CO-SPONSORS

  IEEE Region 8
  EURASIP - European Assoc. Signal, Speech and Image Processing
  IEEE Croatia Section
  IEEE Croatia Section Chapter of the Signal Processing Society
  IEEE Croatia Section Joint Chapter of the AP/MTT Societies

  
  TOPICS

  --> Image and Video Processing 
  --> Multimedia Communications 
  --> Speech and Audio Processing 
  --> Wireless Commununications 

adoption of draft-melia-mipshop-mstp-solution-01 as a WG document

I agree with the decision on 5 December to adopt this I.D. as a WG document.

David

--

-- 
**********************************************

David W. Griffith, Ph.D.
Advanced Network Technologies Division
National Institute of Standards and Technology
100 Bureau Drive, Stop 8920
Gaithersburg, MD 20899-8920

Phone:  (301) 975-3512
Fax:    (301) 975-6238
e-mail: david.griffith <at> nist.gov

**********************************************

Re: Confirmation of adoption of draft-melia-mipshop-mstp-solution-01 as a WG document

Dear all,

I think this document is a good start for the MIH support. However, I
would like to clarify a few things with the design:

- First of all, this should not be called a protocol design. Rather, it
is more of a framework design, as there is no new protocol defined here.

- Why the IS, ES, CS need to have different ports defined? Why can't the
transport multiplex the support of different services? Especially for
the ES and CS, why a MN needs to create two separate transport sessions
even if the peer MIHF is the same?

- If MIHF peer discovery is anyway required, as suggested in the
document using DHCP or DNS, why the document defined the fixed port
numbers for the different services? Shouldn't this also be included in
the discovery mechanism? It would allow a much more flexible deployment.
At least, it should allow those ports to be override by information from
DHCP or DNS.

- For the MIH services, the security aspect is important, especially for
the CS. This document only talks about the TLS/DTLS for the transport.
How about the other aspects, e.g. the authentication of the MIHF peer?
Shouldn't this also be covered (SR2 from the problem statement)?

cheers

Cheng Hong

Vijay Devarapalli wrote:

I-D Action:draft-ietf-mipshop-mstp-solution-00.txt

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           : Mobility Services Transport Protocol Design
	Author(s)       : T. Melia, et al.
	Filename        : draft-ietf-mipshop-mstp-solution-00.txt
	Pages           : 30
	Date            : 2007-12-17

This document describes a design solution for the IEEE 802.21 Media
Independent Handover (MIH) protocol that addresses identified issues
associated with the transport of MIH messages.  The document
describes mechanisms for mobility service (MoS) discovery and
transport layer mechanisms for the reliable delivery of MIH messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mipshop-mstp-solution-00.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-mipshop-mstp-solution-00.txt".

Re: Confirmation of adoption of draft-melia-mipshop-mstp-solution-01 as a WG document

HI,

Please see in line.

Hong Cheng ha scritto:
> Dear all,
>
> I think this document is a good start for the MIH support. However, I
> would like to clarify a few things with the design:
>
> - First of all, this should not be called a protocol design. Rather, it
> is more of a framework design, as there is no new protocol defined here.
>   
Fine. We will update this in the next version.
> - Why the IS, ES, CS need to have different ports defined? Why can't the
> transport multiplex the support of different services? Especially for
> the ES and CS, why a MN needs to create two separate transport sessions
> even if the peer MIHF is the same?
>   
We have been discussing the multiplexing issue quite a lot in the DT. 
The feeling was that
to keep flexibility while reducing complexity opening different sockets 
to different ports for
different services would provide the required multiplexing capability. 
Please also remember
that the MN cannot do "a priori" any assumption on the location of the 
different MoS.
> - If MIHF peer discovery is anyway required, as suggested in the
> document using DHCP or DNS, why the document defined the fixed port
> numbers for the different services? Shouldn't this also be included in

Re: Confirmation of adoption of draft-melia-mipshop-mstp-solution-01 as a WG document

Hi,

I am not sure how the DNS could exactly work for discovery or needs to 
be extended with a new entry type - to me DNS is hierarchical and 
refreshed with a timer. [draft-bajko-mos-dns-discovery] gives some 
suggestions but it is not clear about its deployability. Below some 
additional comments to your previous discussions:

> Hong Cheng ha scritto:
>> Dear all,
>>
>> I think this document is a good start for the MIH support. However, I
>> would like to clarify a few things with the design:
>>
>> - First of all, this should not be called a protocol design. Rather, it
>> is more of a framework design, as there is no new protocol defined here.
>>   
> Fine. We will update this in the next version.
>> - Why the IS, ES, CS need to have different ports defined? Why can't the
>> transport multiplex the support of different services? Especially for
>> the ES and CS, why a MN needs to create two separate transport sessions
>> even if the peer MIHF is the same?
>>   
> We have been discussing the multiplexing issue quite a lot in the DT. 
> The feeling was that
> to keep flexibility while reducing complexity opening different sockets 
> to different ports for
> different services would provide the required multiplexing capability. 
--> This does not seem to be clear to me...

Re: Confirmation of adoption of draft-melia-mipshop-mstp-solution-01 as a WG document

Hi Telemaco,

Thanks for your comments to the questions. However, I still have several
doubts about the draft.

Doesn't the mstp design suppose to support the MIH, i.e. the transport
of MIH protocol messages? Looking at the MIH Protocol from 802.21, it
seems that the message header really does multiplexing of the three
services, e.g. the MIH Message ID (Service ID). If there are three
different transports mandated in the mstp (for the different services),
does it mean a host with a MIHF needs to demultiplex the MIH Protocol
and send them differently (even the target is the same)?

Besides this, there are also other type of MIH Protocol messages, e.g.
Service Management. So, how would these messages be transported? And
using which port (as they don't belong to ES/CS/IS)?

Maybe the DT has already have this discussed out, but I could not found
anything in the draft offering the explanation.

A few more comments inline:

Telemaco Melia wrote:
> HI,
> 
> Please see in line.
> 
> Hong Cheng ha scritto:
>> Dear all,
>>

IETF 70 MIPSHOP WG minutes

Hello folks,

Here are the draft minutes for the MIPSHOP meeting at IETF 70. Thanks to 
Fan Zhao and Juan Carlos Zuniga for taking the notes.

Please let us know if there are any corrections.

Vijay

IETF 70 MIPSHOP WG Meeting Minutes 
----------------------------------
Note takers: Fan Zhao and Juan Carlos Zuniga

0. Agenda review

1. WG status and I-Ds update

   draft-ietf-mipshop-fmipv6-rfc4068bis-04
     FMIPv6 got extensive reviews from the IESG. Comments have been 
     addressed.

   draft-ietf-mipshop-4140bis-01
     Submitted to the IESG.

   draft-ietf-mipshop-handover-key-03
     In the RFC editor queue.

   AAA-based handover key
     No document, need to take a decision on what to standardize.