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

[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

 

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”

 

 

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

[Roni Even] OK

 

 

Nits/editorial comments: