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

Hi Magnus,

is changing the DCCP parameter to

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Type = 0x3             |      Length = variable        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         DCCP port             |          (reserved)           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      DCCP service code                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                     IPv4 or IPv6 Address                      :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

what you want?

Best regards
Michael

On Nov 20, 2007, at 4:29 PM, Magnus Westerlund wrote:

> Thanks,
>
> I have removed everything that seems clear to me.
>
> Michael Tuexen skrev:
>> Hi Magnus,
>>
>> here are the comments to your comments regarding
>> draft-ietf-rserpool-common-param-13.txt
>>
>> My comments are based on a telephone conference between
>> the authors.
>>
>> I have removed the other text from the mail...
>>
>>>
>>>
>>> C2. Section 3.3: Is it a SCTP limitation that there needs to be  
>>> the same
>>> port on all the interfaces or this a limitation created in this
>>> document? Will not this be problematic to get the same port over all
>>> interfaces?
>> I would not call it a limitation of SCTP, but an SCTP endpoint has
>> one or more IP-addresses (it can be a mixture of IPv4 and IPv6
>> addresses) and one single port number. This feature is not related
>> to RSerPool and the message format is correct.
>
> Okay, that it is correct is the only thing I needed to know.
>
>>>
>>>
>>> C3. Section 3.3, 3.4, 3.5: Probably a question for the utilizing
>>> protocols. Are it is possible to have multiple transport  
>>> parameters of
>>> the same type, for example to provide both IPv4 and IPv6 addresses?
>> If you want to provide a service on multiple IP addresses and the
>> same port number, just use multiple transport parameters. This  
>> decision
>> was made a long time ago and provides no limitation.
>
> Ok.
>
>>>
>>>
>>> C4. Any considerations for UDP-Lite or DCCP transport parameters?
>> Thanks for the reminder... I have added transport parameters for
>> UDP-Lite and DCCP. I think we we re just not aware of these protocols
>> when we wrote the initial version of the ID.
>
> I have looked at the new transport parameters. I think you will need  
> to
> add a DCCP Service Code field also.
>
>
>>>
>>> C6. Section 3.8: Registration life: I am missing a time reference  
>>> here.
>>>> From when does the time count? Wouldn't it be better with a NTP  
>>>> time or
>>> something else? The current construct clearly requires a receiver  
>>> to at
>>> least take a clock time and then save arrival time or combine the  
>>> two
>>> into an expiration time for the entry.
>> Yes, the receiver needs to compute the time, it is just a relative
>> duration.
>> There is no problem with this, since any endpoint has to run timers  
>> and so
>> on which also include durations.
>>
>> However, if the duration is very short and the message transfer delay
>> large,
>> your system will not work as expected, but that is true for a lot of
>> systems
>> when used in a way they are not engineered for.
>
> Okay.
>
>
>>>
>>>
>>> C10. Section 6. I am missing a security analysis bringing up any  
>>> issues
>>> in the parameters themselves.
>> I do not see any security issue by message formats. Each receiver has
>> to do input validation, but that it clear and there is nothing  
>> special
>> with the messages defined here.
>>>
>
> Sure
>
> So the only thing that still needs fixing seems to be the service code
> for DCCP.
>
> Cheers
>
> Magnus Westerlund
>
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM/M
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email protected]
> ----------------------------------------------------------------------
>
>
> _______________________________________________
> rserpool mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rserpool
>