Subject: [Mipshop] DT's review of the MIH PS doc

From: Telemaco Melia <[email-masked]>
Date: Thu, 22 Mar 2007 14:44:32 +0100

Hello,

Please find in the following the DT's review of the PS doc.
The DT has been considering the comments on the mailing list as
well as technical issues discussed this week. (see report on the DT progress)
We hope this addresses the concerns raised on the mailing list.

regards,
telemaco

General comments:

+ Section 4 Deployment scenarios
-----------------------------------
Current text: "The deployment scenarios are outlined in the following
sections.
   Note: while MN-to-MN signalling exchanges are theoretically possible,
   these are not currently being considered, and are out-of-scope."

Due to his nature IEEE 802.21 protocol does not forbid MN to MN
communication.
Following .21 folks suggestions (some good use cases exist) the words
after the comma have been removed.

Proposed text:"The deployment scenarios are outlined in the following
sections.
   Note: while MN-to-MN signalling exchanges are theoretically possible,
   these are not currently being considered"

+ Section 4.3
--------------
Current text:"The Proxy NN processes all layers of the protocol suite in
the same way as an ordinary EP."

Within the DT it has been identified that the NN proxy could also be a
fairly simple instance of the .21 stack with limited processing
capabilities.

Proposed text: "The Proxy NN might process all layers of the protocol
suite in the same way as an ordinary EP."

+ Section 5
------------
The title "Solution components" has created some misunderstandings.
The reason to have this section is to better frame the problem statement
in a more general context.
Figure 5 highlights where the problem originates (interaction between
the MSTP and the Mobility Services).
The DT is currently working on this problem to produce a solution
document.
Please note that Mobility Services are specified elsewhere and are not
components in scope of Mipshop.
The DT also agreed on using Mobility Service Transport Protocol (MSTP)
(as presented in the PS doc) to indicate the transport solution
We propose to change the section name to: "Mobility Service Transport
Protocol Splitting".

+Section 5.1
------------

Bullet list at the end of the section.
Upon agreement on treating the payload of the MSTP as opaque we suggest to remove the text.
MSTP does not inspect the payload and any required information will be provided by the MSTP users.

+Section 5.2
--------------
Current text:" MNs need the ability to locate nodes that support
particular mobility services in the network. "

It seems reasonable to acknowledge .21 discovery mechanisms (L2 based).
Therefore we propose the following text.
 
Proposed text:"MNs need the ability to either discover nodes that
support  certain services, or discover services provided by a certain
node.
The service discovery can be dealt with messages as defined in [1]. This
section refers to node-discovery in either scenario."

+Section 5.2 (para starting end of page 12)
--------------------------------------------

Current text: "Option 1 has a number of disadvantages associated with
it, namely that ultimately the protocol design ends up re-inventing
a lot of the functionality already available in lower layers at a higher
layer where access to information about what is going
on in the network is restricted.  For example, how will the higher layer
determine the cause of the error, if a message is
lost due to network congestion, it is pointless sending the message
again.  It also adds to the complexity of the higher
layer protocol, and makes successful deployment less certain (the
protocol will have to be trialed in a number of network
situations instead of re-using a protocol that has already been
tested)."

Since this document is a PS doc and the above text hints a possible
solution we recommend to delete the paragraph.

Current text:"MN dynamically requesting information about a service, which
         may require both MN and NN support for a particular service..."

Problem: clarify that MSTP does not discover services but nodes that support specific mobility services.

Proposed text:"MN dynamically requesting information about a node, which
         may require both MN and NN support for a particular service"

+Update references
------------------

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