Re: [dhcwg] IESG Review Comments on draft-ietf-dhc-3315id-for-v4-04.txt

I don't believe there was any followup discussion in response to
Margaret's post about issues raised by the IESG regarding draft-ietf-
dhc-3315id-for-v4-04.txt.  Please review and comment so we can resolve
the IESG issues and publish this document...

- Ralph

On Fri, 2005-05-13 at 05:35 -0400, Margaret Wasserman wrote:
> Hi All,
> 
> The IESG reviewed draft-ietf-dhc-3315id-for-v4-04.txt on our telechat 
> yesterday.  There were several comments on the document, included 
> below.  Issues marked "discuss" are blocking issues that need to be 
> resolved before the document will be approved for publication. 
> Non-blocking comments, marked "comment", should also be considered by 
> the WG and authors, but approval is not blocked pending their 
> resolution.
> 
> Some of these issues are fairly straight forward to address, but the 
> issue raised by Brian Carpenter and the long set of comments from 
> David Kessens will probably warrant WG discussion.
> 
> Thanks,
> Margaret
> 
> Brian Carpenter:
> Discuss:
> [2005-05-12] I expected to find some words stating what happens when 
> a client following this spec meets a server that doesn't, or vice 
> versa. Are these failure scenarios or is there implicit backwards 
> compatibility? This really isn't obvious and should probably be added 
> to the applicability section.
> 
> Ted Hardie:
> Comment:
> [2005-05-10] The document's IANA considerations says:
> 
> This document deprecates all 'client
>    identifier' type codes other than 255, and thus there is no need
>    for the IANA to track additional possible values for the type field
>    of the 'client identifier' option.
> 
> I got a bit confused about whether any values registered in this:
> http://www.iana.org/assignments/bootp-dhcp-parameters
> 
> are deprecated, or this only deprecates further registration.  A
> clarification may be in order.
> 
> Sam Hartman:
> Comment:
> [2005-05-08] I didn't find this document particularly clear it seemed harder to
> follow than it should be.  I think that's probably because it is a set
> of diffs to other behavior and has too many references to stand on its
> own.  However I did eventually follow it and I don't think anything I
> found should block publication at this stage.
> 
> Russ Housley:
> Discuss:
> [2005-05-09]
>    The Introduction says:
>    >
>    > This supersedes the behaviour specified in RFC2131 and RFC2132.
>    >
>    The header and the abstract need to indicate that this document
>    updates RFC 2131 and RFC 2132.
> 
> Comment:
> [2005-05-09]
>    Section 2.4 says:
>    >
>    > Like the client identifier format recommended by RFC2131, this
>    > suffers from the problems previously described in (2) and (3).
>    >
>    Section numbers are needed to refer to the previous problems.
> 
> David Kessens:
> Discuss:
> [2005-05-12] I received the following comment from the OPS 
> directorate. I understand from the comment that the issue might have 
> been discussed in the past. I would appreciate if you could 
> reconsider this issue:
> 
> How is a server expected to handle the case where a single computer first
> chooses to identify itself with a client identifier, and then later chooses
> not to supply an identifier at all?  This is never clearly explained in
> any section of RFC2131/2132, so there are three possible interpretations:
> 
> A) Treat them as two separate, discrete clients.
> 
> B) Synthesize a client identifier out of the CHADDR field - thus treating
>    clients who identify themselves with their ethernet MAC address as the
>    same client which didn't identify themself, on the same MAC address.
> 
> C) 'Slide' identities between the two clients.  In essence, the lack of a
>    client-identifier is like an "ANY" tag - any lease which was allocated
>    to a client using that CHADDR contents is fair game, and vice versa...
>    any lease which did not have a client identifier but had the same CHADDR
>    is fair game.
> 
> It might seem that the worst such different interpretations might cause
> is redundant address allocations - something that gets solved by itself
> when addresses expire.  It's true that this happens, and it's highly
> undesirable by DHCP server administrators, especially in the case where
> clients are limited to a certain number of leases (due to contractual
> levels of service).
> 
> There exists a "Windows for Embedded Devices" whose product name escapes
> me right at this moment.  Consider then the following reference case:
> 
> 1) PXE boots and obtains an IP address and configuration via DHCP - it is
>    told to download the Windows boot image.
> 
>          - A server now has a lease allocated to this MAC address in its
>            database, as allocated to a client that did not supply a client
>            identifier.
> 
> 2) Execution is passed to the Windows boot image - the system already has
>    an IP address, configured by PXE, but Windows wants to query the DHCP
>    server with more, vendor-specific, options added to the 'Options Request
>    List' to get extra configuration state the original PXE client did not
>    know it needed to know.
> 
>          - The Windows boot image sends a DISCOVER message with the address
>            as obtained by PXE in a 'Requested Address' option, and a client
>            identifier whose contents match the CHADDR field.
> 
>          - A server as implimenting interpretation A (above) allocates a new
>            address for the client, since the Windows client did supply a
>            client identifier, and this is interpreted as meaning it is a
>            seperate, distinct client from the former.
> 
>          - The Windows boot image, running within PXE, is unable to alter the
>            network configuration, and instead of REQUESTing the lease it was
>            just offered, continues to resend DISCOVER messages.
> 
> 3) The system ultimately times out and reboots itself - goto 1).
> 
> 
> This actually represents an insidious compatibility problem, and I
> submit it stems from poor definition of the client identifier option
> in RFC2131/2132.
> 
> Now, this draft has fine goals - the DHCPv6 Node Identifier that is being
> duplicated here is the right way to go about client identifiers, and it will
> serve useful purposes.  Not only for the dual-stack purposes of being able
> to detect what specific clients (as identified by their DUID's) are using
> both ipv4 and ipv6 addresses, but also for things like Dynamic DNS, and for
> unusual client configurations (clients having more than one interface - since
> the server can peek into the client-identifier it can see that a client has
> multiple interfaces active within a given broadcast domain - you may want
> to allocate the same address, different addresses, or even different
> addresses in different subnets within that broadcast domain).
> 
> Since the old identifiers were 'completely opaque', it's also a reverse
> compatible approach - servers that treat the client identifier as an
> opaque field will work acceptably well under all imaginable circumstances
> when clients supply identifiers in this draft's suggested formats.
> 
> These are all good things, and we need this draft to reach RFC at some
> point.
> 
> But I think we have learned from the past that not defining a "MUST"
> behaviour for this case - where a client presents itself at different
> times with a mixture of identities - produces incompatibilities due to
> differing interpretations.
> Producing a new format of the client identifier option, and not at least
> describing this problem much less addressing it, seems to be "not learning
> from our own mistakes."
> 
> Understand that the problem is magnified in this draft -
> 
> In the old RFC2131/2132 world, we could (as I described above) just
> synthesize a client-identiifer out of the ethernet MAC address and address
> 99.9% of the problematic cases.
> 
> But in this draft, we have defined a whole new encoding for the client
> identifier that has never appeared elsewhere and cannot be synthesized by
> the DHCP server from any other DHCP packet contents.
> 
> The only option I believe systems administrators will employ to avoid
> deployment problems with products conforming to this draft as delivered
> by products that don't (PXE), is to disable their server's implementation
> of client identifiers entirely.
> 
> Which is not at all what we want.
> 
> So it's a good draft, with good contents, features that we need, but also
> with what I think is a serious potential problem that I think should be
> addressed at least as it applies to this draft, if not in general.
> 
> Bert Wijnen:
> Discuss:
> [2005-05-12] I see RFC2119 luanguage (keywords SHOULD and such) 
> without a citation
> and a normative reference.
> 
> Comment:
> [2005-05-12] Mmm... I see citations in the abstract. My understanding is that
> those are not allowed. Easy to fix, just use perenthesis instead
> of square brackets.
> 
> _______________________________________________
> 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