Subject: Re: [Mipshop] draft-ietf-mipshop-mis-ps-01.txt

From: Telemaco Melia <[email-masked]>
Date: Tue, 05 Jun 2007 18:34:55 +0200

Folks,

Since nobody complained about the proposed text, should we assume you 
are fine with this?

telemaco

Telemaco Melia wrote:
> Daniel,
>
> If we modify the Introduction to include the following text:
>
> "The initial requirement for this protocol comes from the need to 
> provide a transport for the MIH protocol being defined by IEEE 802.21
> (specifically the IS/ES/CS components) which is not bound to any 
> specific link layer and can operate over more that one network-layer
> hop. The solution should be flexible to accommodate evolution in the
> MIH standard, and should also be applicable for other new mobility 
> signalling protocols which have similar message patterns and discovery
> and transport requirements."
>
> and explicitly mention IS,CS,ES in the definition of MoS, would that 
> address your doubts?
>
> cheers,
> telemaco
>
>
>
> Daniel Park wrote:
>> As I also mentioned several times before, I did recommend you and
>> MIPSHOP to take the original approach of MIPSHOP charter in terms of
>> 802.21 stuff into consideration. BUT, still it seems really wide
>> spreaded. not good at least to me...:-(
>>
>> http://www1.ietf.org/mail-archive/web/mipshop/current/msg02879.html
>>
>> -- Daniel Park
>>
>> On 5/16/07, Telemaco Melia <[email-masked]> wrote:
>>> Alper,
>>>
>>> I think we can summarize your concerns as follow:
>>>
>>> + Issue on the extra given context information
>>> Probably there will never be an answer making everyone happy, but 
>>> there is
>>> no point in keeping changing the scope again and again.
>>> We believe the extra given context has been revised in way to 
>>> provide the
>>> minimum amount of info required to better understand the document.
>>>
>>> + Issue on the scope of the ID beyond what's being defined in .21.
>>> We discussed this several times and the feeling was to have a doc 
>>> general
>>> enough while not conflicting with .21 requirements
>>> (this is why .21 folks reviewed the ID). In other words, we are 
>>> trying to
>>> solve the .21 problem but without doing it in a way
>>> which hardcodes unnecessary assumptions.
>>>
>>> + Issue on the statement "goal is to reuse/adapt, where possible, 
>>> existing
>>> solutions."
>>> We can update the sentence to reflect your comments.
>>> You should expect an analysis of existing solutions as part of the DT
>>> output.
>>>
>>> Comments are welcome.
>>>
>>>
>>> regards,
>>> telemaco
>>>
>>> Alper Yegin wrote:
>>>
>>>
>>> Hi Telemaco,
>>>
>>> I appreciate the effort people put into this I-D. But I believe this 
>>> I-D has
>>> some extra baggage that can cause unintended side effects. I'm 
>>> trying to
>>> raise such issues.
>>>
>>> Please see below.
>>>
>>>
>>> Alper,
>>>
>>> Please find below the view of the authors in response to your 
>>> questions.
>>>
>>> + Concern about having not relevant material in the PS doc (e.g.
>>> requirements, formats, layering..).
>>> This issue has been extensively discussed even before the adoption 
>>> of this
>>> document as WG document. (Eleanor presented this during IETF# 65 if 
>>> I recall
>>> exactly...) The conclusion was that having such information in the 
>>> document
>>> it helps in understanding the problem and it clearly identifies 
>>> mipshop's
>>> playground.
>>> I went back to some emails exchange we had in September and I found the
>>> following (Robert's email):
>>> "....However, my recollection from the meeting (and also the 
>>> minutes) was
>>> that for a number of people, a "pure" PS draft was very difficult to 
>>> absorb
>>> without
>>> the architectural context, which includes at least the .21 
>>> discussions. Also
>>> in Montreal the AR-info issues came up as another (not .21) protocol
>>> user...."
>>> Nobody ever complained about the above statement and the authors 
>>> assumed the
>>> WG was fine with this (at least up to now).
>>>
>>> Alper> That's the intent of the WG last call, right? I'm raising a 
>>> concern
>>> about this. If I'm the only one, and no one else cares, I don't 
>>> intend to be
>>> hung up on these points -- despite my strong belief on some of them.
>>>
>>> Alper> For example, how does the Section 5 and 5.1 really help, 
>>> other than
>>> prematurely setting the tone of the solution? If all we need to say 
>>> is that
>>> we need to transport some IEEE 802.21 defined payloads, we can just 
>>> say so.
>>> We shall leave the further details to the solutions.
>>>
>>>
>>>
>>>
>>> + Relation with 802.21
>>> The document has undergone several review iterations from 802.21 folks.
>>> (Yoshi triggered several times .21 experts)
>>> We received detailed comments on section 5.2 and nothing conflicting 
>>> with
>>> .21 activities was found.
>>>
>>> Alper> I didn't mean we are conflicting with .21. My question is, do we
>>> intend to go beyond transporting what's defined in .21?
>>>
>>>
>>> In the document we refer to Mobility Services as supporting 
>>> functions for
>>> media independent handovers and IS, ES, CS are  an example.
>>> Such interpretation of the Mobility Services was discussed/agreed 
>>> back to
>>> the Montreal meeting. (Cannot find the appropriate email thread)
>>>
>>> + Comment on section 4.2, 4.3 and 4.4
>>> Again, this is part of what we call architectural context necessary to
>>> explain the content of the document.
>>> And yes, you are right, the scenarios come from IEEE. Is there any 
>>> problem
>>> in having them in this document?
>>>
>>> Alper> I think it is best if we simply refer to .21 documents.
>>>
>>>
>>>
>>> + About naming
>>> ID name has been adapted to address your comment.
>>>
>>> A final remark on the statement "Much of the functionality required 
>>> for this
>>> problem is available from existing IETF protocols or combination 
>>> thereof."
>>> One of the DT's goals is to reuse/adapt, where possible, existing 
>>> solutions.
>>> Do you see the sentence harmful?
>>>
>>> Alper> I think I-D should say what you intend: "goal is to reuse/adapt,
>>> where possible, existing solutions." The authors of this I-D might 
>>> have done
>>> an analysis and achieved the documented conclusion. But unless you 
>>> share it
>>> with us in detail, it does not serve any purpose. Besides, such 
>>> assessment
>>> also does not belong to a "problem statement" document.
>>>
>>>
>>> Alper> And while we are at that, please let us know the details of your
>>> assessment. What protocols are those?
>>>
>>>
>>> Please consider that the PS doc was widely discussed in Prague and 
>>> agreed by
>>> all parties.
>>>
>>> Alper> Then we should have skipped the WG LC :-)
>>>
>>> Alper
>>>
>>>
>>>
>>>
>>> We hope the above explanation address your concerns.
>>>
>>> regards,
>>> telemaco
>>>
>>> Alper Yegin wrote:
>>> I couldn't see what changes were made in response to my feedback 
>>> (except few
>>> items) --
>>> http://www1.ietf.org/mail-archive/web/mipshop/current/msg03243.html.
>>>
>>> I'd appreciate if the authors can point out if I missed any relevant
>>> changes, or if they have some other response.
>>>
>>> Alper
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Vijay Devarapalli
>>> [mailto:[email-masked]]
>>> Sent: Thursday, May 10, 2007 12:12 AM
>>> To: [email-masked]
>>> Subject: [Mipshop] draft-ietf-mipshop-mis-ps-01.txt
>>>
>>> Hello,
>>>
>>> The revised draft is available. To all those who had comments during
>>> the WG last call, please check if your comments have been addressed.
>>>
>>> Vijay
>>>
>>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]]
>>> Sent: Wednesday, May 09, 2007 12:50 PM
>>> To: [email-masked]
>>> Cc: [email-masked]
>>> Subject: [Mipshop] I-D
>>> ACTION:draft-ietf-mipshop-mis-ps-01.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: Problem 
>>> Statement
>>>         Author(s)       : T. Melia, et al.
>>>         Filename        : draft-ietf-mipshop-mis-ps-01.txt
>>>         Pages           : 18
>>>         Date            : 2007-5-9
>>>
>>> There are on-going activities in the networking community to develop
>>>    solutions that aid in IP handover mechanisms between heterogeneous
>>>    wired and wireless access systems including, but not
>>> limited to, IEEE
>>>    802.21.  Intelligent access selection, taking into account
>>> link layer
>>>    attributes, requires the delivery of a variety of different
>>>    information types to the terminal from different sources within the
>>>    network and vice-versa.  The protocol requirements for this
>>>    signalling have both transport and security issues that must be
>>>    considered.  The signalling must not be constrained to
>>> specific link
>>>    types, so there is at least a common component to the signalling
>>>    problem which is within the scope of the IETF.  This draft
>>> presents a
>>>    problem statement for this core problem.
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-mipshop-mis-ps-01.txt
>>>
>>> To remove yourself from the I-D Announcement list, send a message to
>>> [email-masked] 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-mis-ps-01.txt".
>>>
>>> A list of Internet-Drafts directories can be found in
>>> http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>> Internet-Drafts can also be obtained by e-mail.
>>>
>>> Send a message to:
>>>         [email-masked].
>>> In the body type:
>>>         "FILE /internet-drafts/draft-ietf-mipshop-mis-ps-01.txt".
>>>
>>> NOTE:   The mail server at ietf.org can return the document in
>>>         MIME-encoded form by using the "mpack" utility.  To use this
>>>         feature, insert the command "ENCODING mime" before the "FILE"
>>>         command.  To decode the response(s), you will need "munpack" or
>>>         a MIME-compliant mail reader.  Different MIME-compliant
>>> mail readers
>>>         exhibit different behavior, especially when dealing with
>>>         "multipart" MIME messages (i.e. documents which have been split
>>>         up into multiple messages), so check your local 
>>> documentation on
>>>         how to manipulate these messages.
>>>
>>> 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://www1.ietf.org/mailman/listinfo/mipshop
>>>
>>>
>>>
>>> _______________________________________________
>>> Mipshop mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/mipshop
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Mipshop mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/mipshop
>>>
>>>
>
>
>
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: "Stefano Faccin" <[email-masked]>
Date: Tue, 5 Jun 2007 09:36:00 -0700

Tele,
I would say this seems to address quite well the concerns I have read so
far on the mailing list.
Stefano

-----Original Message-----
From: Telemaco Melia [mailto:[email-masked]] 
Sent: Friday, May 25, 2007 3:17 AM
To: Daniel Park
Cc: [email-masked]
Subject: Re: [Mipshop] draft-ietf-mipshop-mis-ps-01.txt

Daniel,

cheers,
telemaco

Daniel Park wrote:
>> We believe the extra given context has been revised in way to provide

>> the
>> some extra baggage that can cause unintended side effects. I'm trying
to
questions.
>> This issue has been extensively discussed even before the adoption of

>> this
>> document as WG document. (Eleanor presented this during IETF# 65 if I

>> recall
>> "....However, my recollection from the meeting (and also the minutes)

>> was
>> Alper> For example, how does the Section 5 and 5.1 really help, other

>> than
>> In the document we refer to Mobility Services as supporting functions

>> for
Statement
>>         up into multiple messages), so check your local documentation
on

---

From: "Stefano Faccin" <[email-masked]>
Date: Tue, 5 Jun 2007 09:37:07 -0700

Ok, good timing wrt my previous e-mail. I've seen no objections either
in a couple of weeks. I would suggest you proceed with the changes
suggested.
Stefano

-----Original Message-----
From: Telemaco Melia [mailto:[email-masked]] 
Sent: Tuesday, June 05, 2007 9:35 AM
To: [email-masked]
Subject: Re: [Mipshop] draft-ietf-mipshop-mis-ps-01.txt

Folks,

telemaco