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

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: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On 
> Behalf Of S. Daniel Park
> Sent: Wednesday, April 21, 2004 1:13 AM
> To: 'Kostur, Andre'; dhcwg@ietf.org
> Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-rapid-commit-opt-02.txt
> 
> 
>  
> 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.
> 
> >Come to think of it, it looks like this draft re-iterates a bunch of
> wording 
> >that is already in RFC 2131...
> >Does this really need to be restated, or would a reference 
> back to the 
> >"normal" DHCP behaviour as defined in RFC 2131 be sufficient?
> 
> 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 ?
> 
> >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?
> 
> 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
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg