Re: [Rserpool] AD comments on draft-ietf-rserpool-enrp-17, draft-ietf-rserpool-asap-17, draft-ietf-rserpool-common-param-13

["Ong, Lyndon" <[e-mail]>]

Hi Folks,

I talked briefly with Michelle Cotton at IANA and it looks like
what we would need to do is identify any existing port reservations
in the associated protocol drafts and request in the drafts that these 
be reassigned from my name to the RFC when it comes out. 

Lyndon

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Magnus Westerlund
Sent: Monday, February 18, 2008 7:42 AM
To: Michael Tuexen
Cc: [e-mail]
Subject: Re: [Rserpool] AD comments on draft-ietf-rserpool-enrp-17,
draft-ietf-rserpool-asap-17, draft-ietf-rserpool-common-param-13

Hi,

I am expecting another updated to ASAP to handle these last comments
regarding the IANA code points.

Cheers

Magnus

Magnus Westerlund skrev:
> Michael Tuexen skrev:
>>>>>
>>>>> A2. Section 7.2: Also what is the security solution for multicast.
>>>> Not sure what the problem is... The receiver should trust the 
>>>> information in the received multicast message the same way as 
>>>> preconfigured information.
>>>> It gets an address which might or might no belong to a trustworthy 
>>>> ENRP server. Other mechanisms have t be used for authentication.
>>> Okay, then it maybe should be explicit about that the multicast 
>>> messages are not at all trustworthy. I am also worried that one 
>>> basically can inject a lot of server announcement messages and that 
>>> way push the valid servers into minority so that a client will try 
>>> all this invalid servers and never find a valid one.
>> That is possible. But using the Multicast messages is completely
optional.
>> They are not secured by IPSec or TLS so you can not  trust them...
>> So what are you expecting here? A sentence or two in the security 
>> considerations describing the above?
> 
> Yes, explaining that there is security issues here, but we are not 
> resolving them currently. And that with the exception of the DDOS 
> vector they are any resolved by the later security mechanism.
> 
> 
>>>>> A11. Section 6:
>>>>>
>>>>> ASAP well known port registration? Is this not needed as the ENRP 
>>>>> protocol will always provide the port? Is that true both for PE 
>>>>> and ENRP?
>>>> Well, only if multicast is used. In the other case, the well known 
>>>> port is used.
>>> Please include in the IANA section a listing of the well known ports

>>> that have been assigned. I also think you should include a request 
>>> to update the reference for these ports to this document.
>> I'm not sure what you want here. If you look at 
>> http://www.iana.org/assignments/port-numbers
>> and search for asap you will find:
>>
>> #                          Yoshikazu Watanabe <nabe&sm.sony.co.jp>
>> asap-tcp        3863/tcp   asap tcp port
>> asap-udp        3863/udp   asap udp port
>> #                          Lyndon Ong <lyong&ciena.com> August 2003
>> asap-sctp       3863/sctp  asap sctp
>> #                          Lyndon Ong <lyong&ciena.com> November 2005
>> asap-tcp-tls    3864/tcp   asap/tls tcp port
>> #                          Lyndon Ong <lyong&ciena.com> August 2003
>> asap-sctp-tls   3864/sctp  asap-sctp/tls
>> #                          Lyndon Ong <lyong&ciena.com> June 2006
>>
>> and for enrp
>>
>> enrp        9901/udp    enrp server channel
>> enrp-sctp    9901/sctp   enrp server channel
>> #                Lyndon Ong <lyong&ciena.com> June 2006
>> enrp-sctp-tls    9902/sctp   enrp/tls server channel
>> #                Lyndon Ong <lyong&ciena.com> June 2006
>>
>> If I look at other entries in the document I do not see references to

>> RFCs.
>>
>> So would it be enough to just list these assignments in the IANA
section?
> 
> I would propose that these registrations are transfered over to IETF 
> and having the documents actually being referenced. If you search a 
> bit you will find that some port numbers do have RFC numbers as the
reference.
> 
> So include the list of port numbers in the relevant drafts and then 
> include a request to IANA to update these registrations to point at 
> the documents. I assume Lyndon is fine with this. But he is the 
> current owner of these registrations so he probably needs to notify 
> IANA that he is fine when they actually process the request.
> 
> 
> 
>> I guess that we should also list the PPID assignments and request an 
>> update for the reference in 
>> http://www.iana.org/assignments/sctp-parameters
>>
>> SCTP Payload Protocol Identifiers                         Reference
>> --------------------------------------------------------  ---------
>>   0 - Reserved by SCTP                                    [RFC4960]
>>   1 - IUA                                                 [RFC4233]
>>   2 - M2UA                                                [RFC3331]
>>   3 - M3UA                                                [RFC4666]
>>   4 - SUA                                                 [RFC2960]
>>   5 - M2PA                                                [RFC2960]
>>   6 - V5UA                                                [RFC2960]
>>   7 - H.248                                               [H.248]
>>   8 - BICC/Q.2150.3                                         
>> [Q.1902.1][Q.2150.3]
>>   9 - TALI                                                [RFC3094]
>>  10 - DUA                                                 [RFC4129]
>>  11 - ASAP       <draft-ietf-rserpool-asap-03.txt>        [Ong]
>>  12 - ENRP       <draft-ietf-rserpool-enrp-03.txt>        [Ong]
>>  13 - H.323                                               [H.323]
>>  14 - Q.IPC/Q.2150.3                                     
>> [Q.2631.1][Q.2150.3]
>>  15 - SIMCO      <draft-kiesel-midcom-simco-sctp-00.txt>  [Kiesel]
>>  16 - DDP Segment Chunk                                   [RFC5043]
>>  17 - DDP Stream Session Control                          [RFC5043]
>>
>> Do you agree?
> 
> You shouldn't list all the PPIDs. Only request that IANA updates the 
> ones that are created by the RSERPOOL documents to point at the 
> RSERPOOL documents.
> 
> Cheers
> 
> Magnus Westerlund
> 
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM/M
> ----------------------------------------------------------------------
> Ericsson AB                | Phone [phone]
> Torshamsgatan 23           | Fax   [phone]
> S-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
> 
> 
> _______________________________________________
> rserpool mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/rserpool
> 


-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------

_______________________________________________
rserpool mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/rserpool
_______________________________________________
rserpool mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rserpool