Subject: [MIPSHOP-MIH-DT] DT's comments to the PS doc

From: "Telemaco Melia" <[email-masked]>
Date: Wed, 21 Mar 2007 16:17:20 +0100

Hi all,

As agreed yesterday evening and further discussed this morning please find in the following
the summary of the most relevant issue to be addressed (from a DT point of view).
I intentionally skipped the list of minor comments being mostly editorial comments.
The plan is to send the review on the mipshop mailing list if WG chairs agree.

Yesterday evening we also discussed what should be the correct procedure to follow
and here are some question we hope the WG chairs could clarify.
- Should the DT's review be considered input to the WGLC and update the doc after WGLC is concluded?
- Would be ok to present tomorrow (during the DT slot) a summary of the review?
About the second point, even if it would be possible, we are a bit concerned since the discussion could easily diverge from the current focus (DT presentation).

Comments are welcome.

cheers,
tele

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.2
--------------
Current text:" MNs need the ability to locate nodes that support  particular mobility services in the network. "

It seems reasonable to align .21 discovery mechanisms (L2 based) with MSTP discovery mechanisms. 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.

_______________________________________________
MIPSHOP-MIH-DT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt

---

From: Subir Das <[email-masked]>
Date: Wed, 21 Mar 2007 11:44:35 -0400

Tele,
Thanks for putting all the issues together. It is getting better.
I have few suggestion for  Sections 5.1 and 5.2. IMO, we
can clean few things there too. Are all issues relevant to us? 
Also at the beginning we say that information exchange is not
our focus but in Section 5, we describe the requirements for
information exchange. 

Thanks,
-Subir

---

From: <[email-masked]>
Date: Wed, 21 Mar 2007 10:51:56 -0500

Thanks for all the good work. I have no specific comments related to the
PS draft. One general comment is to use the same terminology between the
PS and design draft (if not already).

Regards,
Srini 

-----Original Message-----
From: ext Telemaco Melia [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2007 10:17 AM
To: [email-masked]
Subject: [MIPSHOP-MIH-DT] DT's comments to the PS doc

Hi all,

As agreed yesterday evening and further discussed this morning please
find in the following the summary of the most relevant issue to be
addressed (from a DT point of view).
I intentionally skipped the list of minor comments being mostly
editorial comments.
The plan is to send the review on the mipshop mailing list if WG chairs
agree.

Yesterday evening we also discussed what should be the correct procedure
to follow and here are some question we hope the WG chairs could
clarify.
- Should the DT's review be considered input to the WGLC and update the
doc after WGLC is concluded?
- Would be ok to present tomorrow (during the DT slot) a summary of the
review?
About the second point, even if it would be possible, we are a bit
concerned since the discussion could easily diverge from the current
focus (DT presentation).

Comments are welcome.

cheers,
tele

General comments:

Current text: "The deployment scenarios are outlined in the following
sections.

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.2
--------------
Current text:" MNs need the ability to locate nodes that support
particular mobility services in the network. "

It seems reasonable to align .21 discovery mechanisms (L2 based) with
MSTP discovery mechanisms. 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."

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.

---

From: "Robert Hancock" <[email-masked]>
Date: Thu, 22 Mar 2007 01:16:53 +0100

hi all, 

a general comment near the start and a specific comment on 5.2:

> From: Telemaco Melia [mailto:[email-masked]] 
> Sent: 21 March 2007 16:17
> As agreed yesterday evening and further discussed this 
> morning please find in the following the summary of the most 
> relevant issue to be addressed (from a DT point of view).
> Yesterday evening we also discussed what should be the 
> correct procedure to follow and here are some question we 
> hope the WG chairs could clarify.

i cannot see why there should be a problem with this.

> About the second point, even if it would be possible, we are 
> a bit concerned since the discussion could easily diverge 
> from the current focus (DT presentation).
> 
> Comments are welcome.
> 
> cheers,
> tele
> 
> 
> General comments:
> 
> Following .21 folks suggestions (some good use cases exist) 
> the words after the comma have been removed.
> 
> 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 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).
> 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.2
> --------------
> Current text:" MNs need the ability to locate nodes that 
> support  particular mobility services in the network. "
> 
> It seems reasonable to align .21 discovery mechanisms (L2 
> based) with MSTP discovery mechanisms. Therefore we propose 
> the following text.

See earlier mails on the term 'discovery' (!) I don't think we
are proposing a general alignment; for example, the L2
specific parts of the .21 discovery mechanism are non-alignable
with our work; suggest to change 3 words below:

>  
> 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 
  ^^^^^^^^^^^^^^^^^^^^^
Discovery of capability details for specific nodes

r.

> in [1]. This section refers to node-discovery in either scenario."
> 
> 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 
> Since this document is a PS doc and the above text hints a 
> possible solution we recommend to delete the paragraph.
>

---

From: <[email-masked]>
Date: Thu, 22 Mar 2007 17:20:45 -0500

Hi all,

I have been reviewing the PS Document, and wanted to submit
some comments to the mailing list, with my DT-hat off, if
people think that is OK.  Or would people want me to run
it by the DT first?

John 

>From: ext Robert Hancock [mailto:[email-masked]] 
>Sent: 21 March, 2007 17:17
>Subject: RE: [MIPSHOP-MIH-DT] DT's comments to the PS doc
>
>hi all, 
>
>morning please 
>> Yesterday evening we also discussed what should be the correct 
>> procedure to follow and here are some question we hope the WG chairs 
>> could clarify.
>also be a 
>protocol 
>Protocol (MSTP) 
>> propose to change the section name to:
>> based) with MSTP discovery mechanisms. Therefore we propose the 
>> following text.
>
>specific parts of the .21 discovery mechanism are 
>non-alignable with our work; suggest to change 3 words below:
>
>>  
>associated with 
>> 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)."
>>

---

From: "Robert Hancock" <[email-masked]>
Date: Fri, 23 Mar 2007 10:03:25 +0100

john,

this was actually commented in the session. we tried to clarify that
that DT's comments on the PS have no special status, they just reduce
the traffic a little. and we sent them that way to reassure that 
group that the DT was finding the PS document useful (which seemed
to be unclear from some of the other last call questions).

so anyone can send additional comments any time. (if they turn into
design issues for us it would be good to flag them up as well.)

robert h.

> From: [email-masked] [mailto:[email-masked]] 
> Sent: 22 March 2007 23:21
> people think that is OK.  Or would people want me to run it 
> by the DT first?
> 
> John 
> 
> >> - Should the DT's review be considered input to the WGLC 
> and update 
> >> the doc after WGLC is concluded?
> >
> >> - Would be ok to present tomorrow (during the DT slot) a 
> summary of 
> >> the review?
> >See earlier mails on the term 'discovery' (!) I don't think we are 
> >proposing a general alignment; for example, the L2 specific parts of 
> >the .21 discovery mechanism are non-alignable with our work; 
> suggest to 
> >change 3 words below:
> >
> >>  
> possible

---

From: <[email-masked]>
Date: Fri, 23 Mar 2007 07:54:38 -0500

OK, then I will do my review.

thanks,
John 

>Sent: 23 March, 2007 02:03
>this was actually commented in the session. we tried to 
>clarify that that DT's comments on the PS have no special 
>status, they just reduce the traffic a little. and we sent 
>them that way to reassure that group that the DT was finding 
>the PS document useful (which seemed to be unclear from some 
>of the other last call questions).
>
>so anyone can send additional comments any time. (if they turn 
>into design issues for us it would be good to flag them up as well.)
>
>robert h.
>
>> I have been reviewing the PS Document, and wanted to submit some 
>> comments to the mailing list, with my DT-hat off, if people 
>think that 
>> is OK.  Or would people want me to run it by the DT first?
>> 
>> John
>>