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

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

A new version addressing all your comments has
been submitted and is available at
http://www.ietf.org/internet-drafts/draft-ietf-rserpool-common-param-14.txt

Best regards
Michael

On Oct 16, 2007, at 6:37 PM, Magnus Westerlund wrote:

>
> COMMON:
>
> C1. Page 6: There is a editors note that should be removed.
Done.
>
>
> 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.
>
>
> 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.
>
>
> 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.
>
>
> C5. Section 3.6: "   The enforcement rules and handling procedures of
> all the policies are defined in Section xxxxx in ASAP [3]."
>
> This is only one of several occurances of "xxxxx" or "????" where  
> there
> should be a section number from the other specs. Please look through  
> all
> the documents for this type.
>
> See also Section 3.9, Server ID
> Section 3.12: last paragraph
Done.
>
>
> 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.
>
>
> C7. Section 3.9:
>
> Multicast flag: In what direction that this flag apply? For the sender
> or the receiver?
Removed.
>
>
> C8. Section 3.10, Figure 16:
>
> I would call this first a figure with the TLV and then the Cause Code
> value to cause code list for a "Table". It is a bit confusing.
Done. This was a consequence of a wrong usage of the .xml tool....
>
>
> C9. Section 3.10.2: Can multiple be unrecognized parameter TLVs be
> included in this?
No. Just use multiple error causes. A text clarification has been added.
>
>
> 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.
>
>
> -- 
>
> 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
>