Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-rapid-commit-opt-02.txt

From: "Kostur, Andre" <[email-masked]>
Date: Tue, 20 Apr 2004 09:23:45 -0700

Items to note:

Section 3.1:

The first step says "The client broadcasts a DHCPDISCOVER mess on its local
physical."  Physical what?  Interface, I presume?

The second step talks about using the client identifier or chaddr plus
assigned network address as the identifier for the lease.  I believe this
puts it in conflict with RFC 2131 (which talks about using a subnet address,
not necessarily the address of the lease), and RFC 3046 which adds in the
Remote ID.  I believe that this draft should probably reference RFC 3046 on
this topic.

Come to think of it, it looks like this draft re-iterates a bunch of wording
that is already in RFC 2131 (such as:

           When allocating a new address, servers SHOULD check that the     
           offered network address is not already in use; e.g., the 
           server may probe the offered address with an ICMP Echo Request.  
           Servers SHOULD be implemented so that network administrators 
           MAY choose to disable probes of newly allocated addresses. 

).  Does this really need to be restated, or would a reference back to the
"normal" DHCP behaviour as defined in RFC 2131 be sufficient?

Section 4:

This states that a client SHOULD include this option in a discover if it's
prepared to perform the DISCOVER-ACK exchange.  Shouldn't that be a MUST
since there is that if clause at the end?

---

From: "S. Daniel Park" <[email-masked]>
Date: Wed, 21 Apr 2004 14:13:23 +0900

Thanks Kostur and see my inline comments.

>Section 3.1: 
>The first step says "The client broadcasts a DHCPDISCOVER 
>mess on its local physical."  Physical what?  Interface, I presume?

To sync current term. we wrote " physical subnet " 
I guess subnet is omitted... sorry.

>The second step talks about using the client identifier or chaddr 
>plus assigned network address as the identifier for the lease.  
>I believe this puts it in conflict with RFC 2131 (which talks about
using
>a subnet address, not necessarily the address of the lease), and 
>RFC 3046 which adds in the Remote ID.  I believe that this draft should

>probably reference RFC 3046 on this topic.

I am not sure why it occurs confliction with RFC2131.

>that is already in RFC 2131... 
>Does this really need to be restated, or would a reference back to the 

As stated, I also think it is not significant issue. I am citing
Bernie's
response as below:

I'm pretty neutral on the issue of whether or not to copy text from
2131. When we eventually revise 2131, I believe we'd incorporate this
capability (rapid commit) into the revised 2131 text so I don't think it
is a significant issue. We could remove the text for those steps where
there are no differences (such as step 4 - only) and replace it with
"see RFC 2131". But, this may just increase the confusion (or at least
complexity of following the flow)?

Thought ? or we still need to remove it ?

>prepared to perform the DISCOVER-ACK exchange.  Shouldn't that be 
>a MUST since there is that if clause at the end?

I thought MUST is too hard, but I have no hard stance to replace it
if we agree that.

- Daniel (Soohong Daniel Park)
- Mobile Platform Laboratory, SAMSUNG Electronics. 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 21 Apr 2004 22:13:29 -0400

The text in rapid-commit draft CAME from RFC 2131. It was essentially CUT
and PASTED from 2131 and then modified to include Rapid Commit related
processing. So, the text in step 2 (and 4) is exactly what is in 4 in 2131.
We moved that text into step 2 because the same processing occurs for Rapid
Commit earlier. Step 4 in 2131 says "assigned network address", nothing
about "subnet address".

And, at the start of section 3.1 in the draft we say "The following is a
revised Section 3.1 of [RFC 2131] that includes handling of the Rapid Commit
option."

We don't want to revise any other processing in RFC 2131 except for adding
the Rapid Commit processing.

Thanks for catching the missing "subnet" word in Step 1. If there are any
other editting erros we've made, please do let us know. But if you have
issues with the text in 2131, please let Barr Hibbs know about them as he's
working to capture all the corrections that are needed in 2131.

I do think the text in section 4 should use MUST as if a client WANTs to use
this and is configured to allow its use, it *MUST* send the option otherwise
it has no hope of getting the server to do Rapid Commit. So, perhaps we
should can the text in Section 4 to:

          A client MUST include this option in a DHCPDISCOVER message 
          if the client supports and intends to perform the
          DHCPDISCOVER-DHCPACK message exchange described earlier.  

Text is thanks to earlier comments by Ralph (regarding section 3 in the 01
draft).

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of S. Daniel Park
> Sent: Wednesday, April 21, 2004 1:13 AM
> To: 'Kostur, Andre'; [email-masked]
> Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-rapid-commit-opt-02.txt
> 
> 
>  
> As stated, I also think it is not significant issue. I am 
> citing Bernie's response as below:
> 
> I'm pretty neutral on the issue of whether or not to copy 
> text from 2131. When we eventually revise 2131, I believe 
> we'd incorporate this capability (rapid commit) into the 
> revised 2131 text so I don't think it is a significant issue. 
> We could remove the text for those steps where there are no 
> differences (such as step 4 - only) and replace it with "see 
> RFC 2131". But, this may just increase the confusion (or at 
> least complexity of following the flow)?
> 
> I thought MUST is too hard, but I have no hard stance to 
> replace it if we agree that.
> 
> 
>