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

From: Suresh Krishnan <[email-masked]>
Date: Mon, 7 Apr 2014 00:25:03 -0400

Hi Bernie,

On 03/29/2014 10:05 AM, Bernie Volz (volz) wrote:
> (WG co-chair hat off)
>
> I do not feel the document is ready “as is”. Please see my comments at
> http://www.ietf.org/mail-archive/web/dhcwg/current/msg15362.html.

Thanks a lot for those comments. We will make the reply mandatory with 
three possible responses, and specify retransmission values. We will 
include the new text along with any other changes that result from 
comments during WGLC.

Regards
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 7 Apr 2014 00:25:43 -0400

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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dhcwg
>
>
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>