[dhcwg] RE: dhc WG last call on draft-ietf-dhc-rapid-commit-opt-01

> 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. 

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.

>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.

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

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