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
Mipshop ietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop
|
