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).
+ 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.
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?
+ 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?
Please consider that the PS doc was widely discussed in Prague and
agreed by all parties.
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:Vijay.Devarapalli <at> AzaireNet.com]
Sent: Thursday, May 10, 2007 12:12 AM
To: mipshop <at> ietf.org
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: Internet-Drafts <at> ietf.org [mailto:Internet-Drafts <at> ietf.org]
Sent: Wednesday, May 09, 2007 12:50 PM
To: i-d-announce <at> ietf.org
Cc: mipshop <at> ietf.org
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
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-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:
mailserv <at> ietf.org.
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
Mipshop <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop
_______________________________________________
Mipshop mailing list
Mipshop <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop
--
Dr. Telemaco Melia
telemaco.melia <at> netlab.nec.de
Senior Research Staff Member Tel: +49 (0) 6221 4342- 142
NEC Europe Ltd. Fax: +49 (0) 6221 4342- 155
Network Laboratories Web:
http://www.netlab.nec.de
Kurfuersten-Anlage 36
69115 Heidelberg
GERMANY
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014
RSS Feed