Subject: [Mipshop] Confirmation of adoption of draft-melia-mipshop-mstp-solution-01 as a WG document

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 06 Dec 2007 15:37:30 -0800

Hello,

At the MIPSHOP WG meeting on December 5, there was consensus in the
room to adopt draft-melia-mipshop-mstp-solution-01 as a WG document.

This email is to confirm adopting this document as a WG document,
since all decisions taken in the face to face meeting need to be
confirmed on the mailing list. If anyone has objections or thinks
that this document still needs some work before it can be adopted
as a WG document, please send an email to the mailing list before
Dec 14th.

If you weren't at the meeting and agree with adopting this document,
please send an email supporting adopting the document.

Vijay (for the chairs)

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

---

From: Hong Cheng <[email-masked]>
Date: Wed, 12 Dec 2007 08:36:52 +0800

Dear all,

I think this document is a good start for the MIH support. However, I
would like to clarify a few things with the design:

- First of all, this should not be called a protocol design. Rather, it
is more of a framework design, as there is no new protocol defined here.

- Why the IS, ES, CS need to have different ports defined? Why can't the
transport multiplex the support of different services? Especially for
the ES and CS, why a MN needs to create two separate transport sessions
even if the peer MIHF is the same?

- If MIHF peer discovery is anyway required, as suggested in the
document using DHCP or DNS, why the document defined the fixed port
numbers for the different services? Shouldn't this also be included in
the discovery mechanism? It would allow a much more flexible deployment.
At least, it should allow those ports to be override by information from
DHCP or DNS.

- For the MIH services, the security aspect is important, especially for
the CS. This document only talks about the TLS/DTLS for the transport.
How about the other aspects, e.g. the authentication of the MIHF peer?
Shouldn't this also be covered (SR2 from the problem statement)?

cheers

Cheng Hong

---

From: Telemaco Melia <[email-masked]>
Date: Tue, 18 Dec 2007 09:58:50 +0100

HI,

Please see in line.

> is more of a framework design, as there is no new protocol defined here.
Fine. We will update this in the next version.
> even if the peer MIHF is the same?
We have been discussing the multiplexing issue quite a lot in the DT. 
The feeling was that
to keep flexibility while reducing complexity opening different sockets 
to different ports for
different services would provide the required multiplexing capability. 
Please also remember
that the MN cannot do "a priori" any assumption on the location of the 
different MoS.
> At least, it should allow those ports to be override by information from
Why the MN should not use well known ports? Why would you override 
default values?
Some meaningful deployment scenarios would help.
> Shouldn't this also be covered (SR2 from the problem statement)?
 We can work out different text for the last paragraph.

" Alternatively, generic IP layer security, such as IPSec [RFC2401] may
be used where neither transport layer security for a specific
transport is available nor server only authentication is required."

---

From: Xiaoming Fu <[email-masked]>
Date: Wed, 19 Dec 2007 10:41:55 +0100

Hi,

I am not sure how the DNS could exactly work for discovery or needs to 
be extended with a new entry type - to me DNS is hierarchical and 
refreshed with a timer. [draft-bajko-mos-dns-discovery] gives some 
suggestions but it is not clear about its deployability. Below some 

> different services would provide the required multiplexing capability. 
--> This does not seem to be clear to me...

> that the MN cannot do "a priori" any assumption on the location of the 

--> didn't follow closely recent discussions on MoS terminology, but I 
assume the completion of the discovery process will tell whether the 
peer MIHF is the same.

--> maybe I missed something, it is not clear to me why you need to 
define both UDP and TCP as transport, given TCP offers more 
network-friendly service in many network situations, and doing UDP-based 
retransmission mainly reproduces features in TCP (to add, SCTP could 
even tune the retransmission values as wish).
Xiaoming

---

From: Hong Cheng <[email-masked]>
Date: Fri, 21 Dec 2007 13:24:23 +0800

Hi Telemaco,

Thanks for your comments to the questions. However, I still have several
doubts about the draft.

Doesn't the mstp design suppose to support the MIH, i.e. the transport
of MIH protocol messages? Looking at the MIH Protocol from 802.21, it
seems that the message header really does multiplexing of the three
services, e.g. the MIH Message ID (Service ID). If there are three
different transports mandated in the mstp (for the different services),
does it mean a host with a MIHF needs to demultiplex the MIH Protocol
and send them differently (even the target is the same)?

Besides this, there are also other type of MIH Protocol messages, e.g.
Service Management. So, how would these messages be transported? And
using which port (as they don't belong to ES/CS/IS)?

Maybe the DT has already have this discussed out, but I could not found
anything in the draft offering the explanation.

A few more comments inline:

> different services would provide the required multiplexing capability.

This might seem easier with the protocol design, but as a system, it may
introduce complexity to other components. Please see the comment above.

> that the MN cannot do "a priori" any assumption on the location of the

Yes. Before the discovery, the MN should not know about it. However, the
MN needs to know about such information before the actual message
exchange, as that is required in the MIH protocol message.

> Some meaningful deployment scenarios would help.

The service provider may decide to use different ports based on its
local policy, e.g. to avoid attack on the well known ports.

> transport is available nor server only authentication is required."

This might work. However, I was also thinking about the mutual
authentication aspects of the peers, which is missing from the draft. It
does not have to be covered in the transport protocol itself, but a
mechanism has to be spelled out for interoperability purpose.

cheers

Cheng Hong