Re: [dhcwg] WGLC for draft-ietf-dhc-addr-registration-04 - respond by April 13, 2014

[Suresh Krishnan <[e-mail]>]

Hi Marcin,
   Thanks a lot for your comments. We will get back to you with proposed 
text changes in the next couple of days.

Regards
Suresh

On 04/01/2014 02:26 AM, Marcin Siodelski wrote:
> I have read the document and I think it is not ready yet.
>
> A couple of comments/questions....
>
> I wonder how this would work with multiple DHCP servers receiving
> registration requests from a single client? Apparently, there may be a
> form of race condition that they will both try to add or remove the
> mapping from the DNS. One of them could wait and query DNS to see
> whether the particular mapping is in DNS and do not update - which would
> mean that the other one has updated DNS. But, that would require some
> form of back-off mechanism. So, is this assumed in this document that
> there is only one DHCP server performing registration function and
> multiple registering servers are out of scope? I would be fine with
> that, as long as it is mentioned in the document.
>
> Section 5.1.
>
> The
>     DHCPv6 ADDR-REGISTRATION-REQUEST message MUST contain exactly one
>     IA_NA option and exactly one FQDN option
>
> Why is this limited to exactly one IA_NA option? IIRC, RFC4704 allows updates for multiple bindings. A fragment from RFC4704:
>
>
>     The Client FQDN option MUST only appear in a message's options field
>     and applies to all addresses for all IA_NA bindings in the
>     transaction.
>
> If there is a good reason for such limitation, it would be useful to explain why only one IA_NA option is allowed. Especially, that one IA_NA may contain multiple addresses anyway.
>
> Also. section 5.3 seems to be a little contradicting to this:
>
>
>   For each IA in the ADDR-REGISTRATION-REQUEST
>     message for which the server does not succeed in registering, the
>     server adds an IA option using the IAID from the ADDR-REGISTRATION-
>     REQUEST message, and includes a Status Code option with the value
>     RegistrationDenied (TBA3) in the IA option.  No other options are
>     included in the IA option.
>
> If you only allow one IA_NA, then why do you have to perform "for each".
> Perhaps server should discard the packet with multiple IA_NAs?
>
> IMHO, server should allow multiple IA_NAs, unless there is a good reason
> not to. But, that should be explained.
>
> Section 4.
> What does the server do if IA_NA or FQDN is missing? This section only
> talks about discarding the message that contains server id.
>
> Section 5.3.
>
> In the "normal" exchange with DHCPv6, client MUST include ORO to request
> that server returns Client FQDN. By returning the FQDN option, server
> may indicate whether or not it performs DNS updates for the client. It
> may also send its notion of the FQDN. For example: a client may send
> partial FQDN and rely on the server to generate one. There are no such
> considerations in the draft. In particular, it is not said whether
> client MUST or MUST NOT put ORO in the ADDR-REGISTRATION-REQUEST. Also,
> the server's response is optional (which is wrong in my opinion) and so
> the server's notion of FQDN is not communicated back to the client. Is
> this the intent? From the draft it is unclear in what circumstances the
> server will send back RegistrationDenied? Does it include the case when
> client sends FQDN that DHCP server doesn't like (e.g. partial), and
> instead of generating FQDN for the client (and sending it back in the
> FQDN option), server would send RegistrationDenied?
>
> Sorry for a bit long and blurry comment here, but in section 5. you
> mention about "reusing" FQDN option from RFC4704 and I am not sure how
> much of RFC4704 (and existing logic for processing FQDN) you intend to
> reuse in the addr-registration.
>
> Marcin
>
> On 29/03/14 15:04, Bernie Volz (volz) wrote:
>>
>> Folks, the authors of draft-ietf-dhc-addr-registration
>> (http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-04)
>>
>> feel it's ready for work group last call. Please review this draft and
>> indicate whether or not you feel it is ready to be published.
>>
>> At the time of this writing, there is no IPR reported against this draft.
>>
>> Tomek and I will evaluate consensus after April 13, 2014.
>>
>> Thanks,
>>
>> Bernie & Tomek
>>
>>
>>
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg
>
>
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>