Re: [dhcwg] [Gen-art] Review of draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05

[tianxiang li <[e-mail]>]

Hi Roni,

Thank you for the response, please see inline.

Cheers,
Tianxiang

2017-02-01 15:02 GMT+08:00 Roni Even <[e-mail]>:

> Hi,
>
> See inline
>
> Roni
>
>
>
> *From:* Gen-art [mailto:[e-mail]] *On Behalf Of *tianxiang
> li
> *Sent:* יום ג 31 ינואר 2017 17:59
> *To:* Roni Even
> *Cc:* dhcwg; [e-mail]; [e-mail];
> [e-mail]
> *Subject:* Re: [Gen-art] Review of draft-ietf-dhc-dhcpv6-prefix-l
> ength-hint-issue-05
>
>
>
> 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 <[e-mail]>:
>
> Reviewer: Roni Even
> Review result: Almost Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-05
> Reviewer: Roni Even
> Review Date: 2017-01-29
> IETF LC End Date: 2017-02-09
> IESG Telechat date: 2017-02-16
>
> Summary: This draft is almost ready for publication as a standard
> track RFC.
>
>
> Major issues:
>
> Minor issues:
>
> 1.      I think that this document updates RFC3633 and it should be
> mentioned in the title and abstract
>
>
>
> [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*
>
>
>
[Tianxiang2] Okay, we could add a sentence in the end of the abstract
saying "This document updates RFC3633".

For the title, we followed a similar name with RFC7550 which updated
RFC3315 and RFC3633. It was titled "Issues and Recommendations with
Multiple Stateful DHCPv6 Options". Do you have some recommendations on how
to change the document title?

> 2.      In section 3.1 reference RFC3315 for solicit message and 3.3 for
> advertise messge
>
>
>
> [Tianxiang] Okay, we'll add reference to RFC3315 in section 3.1 and 3.3
> when mentioning Solicit and Advertise messgae.
>
> *[Roni Even] OK*
>
>
>
> 3.      In section 3.1 solution last paragraph is the order of the two
> IAPREFIX options important?
>
>
>
> [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*
>
>
>
> 4.      In section 3.2 solution why are you suing SHOULD and not MUST in
> all recommendations?
>
>
>
> [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*
>
>
>
> 5.      In section 3.2 solution, what should the server do if cannot
> provide any of the requests
>
>
>
> [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.*
>
>
>
> 6.      In section 3.2 solution last paragraph “SHOULD try to provide” and
> in the first paragraph “SHOULD provide” should be the same in both.
>
>
>
> [Tianxiang] Thanks for pointing that out, we'll change it to "SHOULD
> provide".
>
>
>
> *[Roni Even] OK*
>
>
>
> 7.      In section 3.4 “If the client decided to use  the prefix provided
> by the server despite being longer than the  prefix-length hint” yet I
> did not see in section 3.2 that the server can provide a longer
> prefix.
>
>
>
> [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”
>
>
>
[Tianxiang2] The original sentence was a bit confusing, perhaps we could
change it like this:

OLD: "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."

NEW:"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 provide a prefix matching the prefix-length hint, or
a prefix which is length is shorter and as close as possible to the
prefix-length hint. If the server could not provide a prefix which length
is shorter or equal to the prefix-length hint, the server SHOULD provide
the prefix which length is longer and as close as possible to the
prefix-length hint."

8.      In section 3.5 solution the document use “as close as possible” and
> section 3.2 only talk about smaller.
>
>
>
> [Tianxiang] This was mentioned in the last sentence of section 3.2.
>
> *[Roni Even] See above to point 7*
>
>
>
> 9.     In section 3.5 solution why offer options 3 and 4. The draft
> says that option 3 will break client connections and 4 talks about “a
> short non-zero valid-lifetime” which may cause the  client to lose
> connection if "too short for the client" since “short” is not an exact
> value
>
>
>
> [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?*
>
>
>
[Tianxiang2] Agree, as this may vary for different services, we could
change the text to say "a specific valid-lifetime depending on the actual
requirement".


>
>
>
> Nits/editorial comments:
>
>
>
>