From: "Bernie Volz" <volz@cisco.com>
To: "'S. Daniel Park'" <soohong.park@samsung.com>,
 "'Kostur, Andre'" <akostur@incognito.com>, <dhcwg@ietf.org>
Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-rapid-commit-opt-02.txt
Date: Wed, 21 Apr 2004 22:13:29 -0400
Organization: Cisco
Message-ID: <000a01c4280f$67482ba0$6b01a8c0@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <012601c4275f$5ecee410$67cadba8@LocalHost>
Importance: Normal
Content-Transfer-Encoding: quoted-printable
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

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=20
          if the client supports and intends to perform the
          DHCPDISCOVER-DHCPACK message exchange described earlier. =20

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=20
> 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
>=20
>=20
> =20
> Thanks Kostur and see my inline comments.
>=20
> >Section 3.1:
> >The first step says "The client broadcasts a DHCPDISCOVER=20
> >mess on its local physical."  Physical what?  Interface, I presume?
>=20
> To sync current term. we wrote " physical subnet "=20
> I guess subnet is omitted... sorry.
>=20
> >The second step talks about using the client identifier or chaddr
> >plus assigned network address as the identifier for the lease. =20
> >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=20
> draft should
>=20
> >probably reference RFC 3046 on this topic.
>=20
> I am not sure why it occurs confliction with RFC2131.
>=20
> >Come to think of it, it looks like this draft re-iterates a bunch of
> wording=20
> >that is already in RFC 2131...
> >Does this really need to be restated, or would a reference=20
> back to the=20
> >"normal" DHCP behaviour as defined in RFC 2131 be sufficient?
>=20
> As stated, I also think it is not significant issue. I am=20
> citing Bernie's response as below:
>=20
> I'm pretty neutral on the issue of whether or not to copy=20
> text from 2131. When we eventually revise 2131, I believe=20
> we'd incorporate this capability (rapid commit) into the=20
> revised 2131 text so I don't think it is a significant issue.=20
> We could remove the text for those steps where there are no=20
> differences (such as step 4 - only) and replace it with "see=20
> RFC 2131". But, this may just increase the confusion (or at=20
> least complexity of following the flow)?
>=20
> Thought ? or we still need to remove it ?
>=20
> >Section 4:
> >This states that a client SHOULD include this option in a discover if
> it's=20
> >prepared to perform the DISCOVER-ACK exchange.  Shouldn't that be
> >a MUST since there is that if clause at the end?
>=20
> I thought MUST is too hard, but I have no hard stance to=20
> replace it if we agree that.
>=20
>=20
>=20
> - Daniel (Soohong Daniel Park)
> - Mobile Platform Laboratory, SAMSUNG Electronics.=20
>=20
>=20
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>=20


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg