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

Michael Tuexen skrev:
> 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?
> 

Yes, I think that should work. But I would appreciate if you send the
DCCP WG a notice about this as soon as you have all the text.

Cheers

Magnus

> 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
>>
> 
> 


-- 

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]
----------------------------------------------------------------------