Subject: [dhcwg] Reminder! dhc WG last call on draft-ietf-dhc-rapid-commit-opt-00

From: Ralph Droms <[email-masked]>
Date: Mon, 12 Apr 2004 11:49:21 -0400

This message is a reminder of the WG last call on "Rapid Commit Option for
DHCPv4" <draft-ietf-dhc-rapid-commit-opt-00>.  The last call will conclude
at 5PM EST on 4/15/04.

There has been only one response to the last call.  Although the document
will be revised, respond now if you have additional comments, so all of the
necessary revisions can be made at once.

- Ralph Droms

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

---

From: "Bernie Volz" <[email-masked]>
Date: Mon, 12 Apr 2004 14:15:54 -0400

FYI - The current version this draft is
draft-ietf-dhc-rapid-commit-opt-01.txt. Being one of the co-authors (and
subject to making the changes Ralph requested on 4/8), I support this
moving forward.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ralph Droms
Sent: Monday, April 12, 2004 11:49 AM
To: [email-masked]
Subject: [dhcwg] Reminder! dhc WG last call on
draft-ietf-dhc-rapid-commit-opt-00

This message is a reminder of the WG last call on "Rapid Commit Option
for DHCPv4" <draft-ietf-dhc-rapid-commit-opt-00>.  The last call will
conclude at 5PM EST on 4/15/04.

There has been only one response to the last call.  Although the
document will be revised, respond now if you have additional comments,
so all of the necessary revisions can be made at once.

- Ralph Droms

---

From: Ralph Droms <[email-masked]>
Date: Tue, 13 Apr 2004 10:02:16 -0400

Whoops.  Thanks for catching that goof, Bernie.

All - please consider this last call to be on
draft-ietf-dhc-rapid-commit-opt-01.txt.

- Ralph

---

From: "Steve Gonczi" <[email-masked]>
Date: Tue, 13 Apr 2004 15:54:52 -0400

Greetings,

I have some feedback on  draft-ietf-dhc-rapid-commit-opt-01:

1) The draft verbatim quotes a fair amount of text from RFC 2131

E.g.: Sub-sections 1..6 under Paragraph 3.1 
(BTW these sub-sections should probably be 
numbered 3.1.1 ..3.1.6)

IMHO it would be preferable to just point to RFC 2131 
where the Rapid Commit protocol works exactly as 2131, 
and focus more on the differences.

There are some drawbacks to having the common DHCP behavior 
described in 2 different documents. E.g. the 2 texts may lose
sync at one point.
Eliminating the quoted RFC 2131 text would also shorten 
the document and would make it an easier read.

2) IMHO the Rapid Commit draft needs to mandate the following:

"If a client obtains more than one addresses via Rapid Commit ack-s, 
it MUST release any such addresses if it decides 
not to use them." 

The draft does suggest some mitigating measures, under
3.2 Administrative considerations, such as:

Configuring a single Rapid Commit server, or using shorter
leases for Rapid Commit, but I believe the above would be
a cleaner solution.

cheers,

Steve Gonczi

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 13 Apr 2004 16:40:57 -0400

Hi:

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)?

Regarding issue 2, DHCPv6 doesn't mandate this (though in that case
addresses aren't scarce) and doing this begs the question of how long
does the client need to stick around listening for potential DHCPACKs
for these additional messages?

Section 3.2 is clear about when this option should be used and spells
out the issues. It is also why we say:
          A server MAY allow configuration for a different (likely 
          shorter) initial lease time for addresses assigned when Rapid 
          Commit is used to expedite reclaiming addresses not used by 
          clients.

The main point of Rapid Commit is to get the client configured as
quickly as possible. Doing a lease renewal tens of minutes later is not
as significant an issue.

We didn't include text in RFC 3315 (as best I could find and remember)
about releasing addresses in this case for DHCPv6. So, not sure it is
needed here (though again, addresses are not as scarce in v6).

- Bernie

-----Original Message-----
From: Steve Gonczi [mailto:[email-masked]] 
Sent: Tuesday, April 13, 2004 3:55 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: dhc WG last call on draft-ietf-dhc-rapid-commit-opt-01

Greetings,

There are some drawbacks to having the common DHCP behavior 
described in 2 different documents. E.g. the 2 texts may lose sync at
one point. Eliminating the quoted RFC 2131 text would also shorten 
the document and would make it an easier read.

Configuring a single Rapid Commit server, or using shorter leases for
Rapid Commit, but I believe the above would be a cleaner solution.

cheers,

Steve Gonczi

---

From: "Richard Barr Hibbs" <[email-masked]>
Date: Wed, 14 Apr 2004 09:38:16 -0700

> From: Steve Gonczi
> Sent: Tuesday, 13 April 2004 12:55
>
> I have some feedback on
...yes, Steve, we have inadvertently introduced
synchronization errors in the past by having the same action
described in two (or more) different RFCs, but Bernie may
have had in mind my current draft on procedures for updating
DHCPv4
(http://www.ietf.org/internet-drafts/draft-hibbs-dhc-changes
-00.txt) when he included the quoted text.  I personally
feel that supplying replacement text in it's entirety for
the existing text in an RFC to be updated by an I-D is a
good idea, in that a complete replacement avoids many
typographical errors when applying the new text.

--Barr

---

From: "Steve Gonczi" <[email-masked]>
Date: Wed, 14 Apr 2004 15:27:42 -0400

> is a significant issue. 

Yes, if rapid commit gets merged with 2131, the text would be entirely 
appropriate for that draft.  

Is the merging of the 2 documents intended by the WG? 

In the past, I have seen the opposite trend (i.e. breaking out 
optional features into separate drafts, like in the case of the
DHC load balancing RFC that was originally part of 
the failover draft).

I maintain that the current draft would be easier to read if it 
just described the specifics of what it does differently.

>          Commit is used to expedite reclaiming addresses not used by 

Regarding the IPv4 address leakage issue: I would prefer at least 
allowing a solution in the protocol itself, instead of mandating
deployment policy. (Which you do in 3.2)
Ideally, protocol standards would speak to the implementer community, 
not the sysadmins.

If it is impractical to solve the issue in the protocol itself
the deployment restrictions should be a SHOULD not a MUST.

Section 3.2 should consider other possibilities to deal 
with address depletion, such as using the DHC load balancing 
algo to prevent multiple responding servers.

How about:

"Since the Rapid Commit protocol provides no facilities to prevent tying up
multiple IPv4 addresses by multiple responding servers, deployments 
SHOULD prevent multiple address commitments, relying on one or more of the
following options:

a) If possible, deploy the DHC load balancing protocol, or
b) Allow a single Rapid Commit enabled server per site
c) Provide a sufficiently large IP address pool 
d) Employ sufficiently short Rapid Commit lease times

Cheers

/sG

---

From: "S. Daniel Park" <[email-masked]>
Date: Fri, 16 Apr 2004 11:38:31 +0900

Steve, thanks your valuable comments on the draft
during WGLC and kindly look my response inline.

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

> d) Employ sufficiently short Rapid Commit lease times

I think the current draft already sufficiently described (b),(c),(d).
IMO, (a) is beyond our scope because it is a supplementary
method on the DHCP body not specific Rapid Commit issue.

---

From: "Richard Barr Hibbs" <[email-masked]>
Date: Thu, 15 Apr 2004 20:38:43 -0700

I support advancing this draft.

--Barr

> From: Bernie Volz
> Sent: Monday, 12 April 2004 11:16
>