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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Roni,

Thank you for comments, we'll add the changes to the document in our next updated version.
Please see inline. 

Cheers,
Tianxiang

2017-02-02 14:42 GMT+08:00 Roni Even <roni.even@xxxxxxxxxx>:

Hi,

I will leave only the items that needed my response

 

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

 

[Roni Even] I have no problem with this text since it will also work with the rest of the document but is it what was really meant

 

[Tianxiang3] This was the intended meaning of the original sentence, if the server could not honor the hint, it should provide a prefix closest to the hint, the client could then decide whether to accept or neglect this prefix.
 

Also a nit

 

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

 

to

 

“or a prefix whose length is shorter and as close as possible to the prefix-length hint. If the server could not provide a prefix with a shorter or equal length  to the prefix-length hint, the server SHOULD provide a prefix whose length is longer and as close as possible to the prefix-length hint”


[Tianxiang3] Thanks for the suggestion, we will edit this sentence accordingly. 

 



Nits/editorial comments:

 

 



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]