|
Hi, See inline Roni From: Gen-art [mailto:gen-art-bounces@xxxxxxxx]
On Behalf Of tianxiang li Dear Roni, Thank you for providing a thorough review of this document. I have a few questions regarding the comments, please see inline. Best regards, Tianxiang 2017-01-29 17:02 GMT+08:00 Roni Even <roni.even@xxxxxxxxxxxxxxxxx>: Reviewer: Roni Even [Tianxiang] This document does not change any of the text in RFC 3633, but specifies the client and server behavior when using the "prefix-length hint", which was not explained in RFC3633. Would it be suitable to state "this document updates
RFC3633"? [Roni Even] Yes, this is what I meant and it needs to be written in the title and abstract, it will also point people looking at RFC3633 to this document
[Tianxiang] Okay, we'll add reference to RFC3315 in section 3.1 and 3.3 when mentioning Solicit and Advertise messgae. [Roni Even] OK
[Tianxiang] There is no strict requirement for the order of the two options. Would you prefer if we added a sentence to specify this? [Roni Even] I assumed this was the case but it will better to clarify
[Tianxiang] In this document, we used "MUST" for some of the client behaviors, as they are mandatory to avoid client failure and necessary if the client wanted to express its prefix-length requirement. For server behavior, we used "SHOULD" because this document specifies the desired server behavior if the server wants to consider the prefix-length hint, but the server could have its own behavioral policy (e.g. neglect the prefix-length
hint). [Roni Even] This make sense, but it will be good to clarify why it is a SHOULD using your explanation
[Tianxiang] If the server could not provide the requested prefix or prefix-length, it should provide a prefix closest to the prefix-length hint, as stated in the last sentence of section 3.2. Are you referring to what the sever should do of it simply could not provide ANY prefixes to the client? In that case, we could add a sentence at the end of the section 3.2: "If the server will not assign any prefixes to any IA_PDs in a subsequent Request from the client, the server MUST send an Advertise message to the client as described in section 11.2 of RFC 3633." [Roni Even] This sentence is what I was looking for.
[Tianxiang] Thanks for pointing that out, we'll change it to "SHOULD provide". [Roni Even] OK
[Tianxiang] This was mentioned in the last sentence of section 3.2: "If the requested prefix is not available in the server's prefix pool, and the client also included a prefix-length hint in the same IA_PD option, then the server SHOULD try to provide a prefix matching the prefix-length value, or the prefix
with the shortest length possible which is closest to the prefix-length hint value." [Roni Even] I understood from 3.2 that it should provide a shorter length prefix closer to the request maybe “or the prefix with the closest
possible length to the prefix-length hint value”
[Tianxiang] This was mentioned in the last sentence of section 3.2. [Roni Even] See above to point 7
[Tianxiang] The idea was to list all the options, and discuss their consequences. And the server could decide which option to use depending on its policy. Option 3 avoids the complexity of handling multiple delegated prefixes, despite of breaking up all connections. Option 4 allows to server to configure a valid-lifetime for the old prefix depending on actual requirements, rather than let
the old prefix expire on its own. [Roni Even] OK, still option 4 may have similar result to 3 since “a short non-zero” may be too short. Why not add a recommended value?
|