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

[Xiaoming Fu <[e-mail]>]

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 
additional comments to your previous discussions:

> Hong Cheng ha scritto:
>> 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.
>>   
> Fine. We will update this in the next version.
>> - 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?
>>   
> 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. 
--> This does not seem to be clear to me...

> Please also remember
> that the MN cannot do "a priori" any assumption on the location of the 
> different MoS.

--> 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
>> - 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.
>>   
> Why the MN should not use well known ports? Why would you override 
> default values?
> Some meaningful deployment scenarios would help.
>> - 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)?
>>   
> 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."
> 
> 
>> cheers
>>
>> Cheng Hong
>>
>>
>>
>>
>>



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