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

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