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

From: Ralph Droms <[email-masked]>
Date: Wed, 01 Jun 2005 14:56:30 -0400

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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Jun 2005 18:17:37 -0700

On May 13, 2005, at 2:35 AM, Margaret Wasserman wrote:
> 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:
>

This is a very legitimate criticism.   However, I tried to write up  
some language to address it, and I think adding this language to the  
draft is going to be controversial and is going to unnecessarily  
(that is, severely) delay the draft.   There are a couple of drafts  
waiting on this one, and I don't think it's fair to the authors to  
add a delay like this.

Also, I think any solution that we proposed is unlikely to actually  
get implemented in the near term, which is to say that it's not  
urgent.   I don't mind writing something up to tell people how they  
ought to do this, but I'm not sure anybody who matters is going to  
read it.   I am not sure what to write, in any case - an I-D or a  
standards-track draft?   For your edification, I've included the text  
I wrote below - I think you'll see why I don't want to add it to the  
3315id draft.

You could (actually, you did!) argue that this draft creates a new  
problem, because it breaks a workaround hack some people have been  
using.   This is true, but it's not a problem we can solve.  If we  
want the capability to have DHCPv4 and DHCPv6 clients interoperate in  
the way that's described in the draft, that workaround hack is going  
to be a casualty.   I tried to think of a way around it, but there  
isn't one.   If you've got a suggestion, I'd love to hear it.   The  
suggestions you brought up in your discuss aren't the kind of thing  
we could write up as a protocol, and I'm not sure I'd even want them  
in the BCP.   Sometimes we have to do stuff like that to make the  
network work, because of some non-protocol-related constraints under  
which we are forced to operate, but stuff like that doesn't belong in  
RFCs, at least in my opinion.

Really, early stages of multi-stage boot clients ought to release  
their leases before transferring control to the next boot stage, but  
nobody does this.   Releasing the lease doesn't entirely solve the  
problem, though, because it's possible that the final stage's lease  
might still be active when a reboot happens, and in this case if  
there is an address shortage, the early stages won't be able to  
acquire a lease.   So you really need the complicated solution  
described below to completely address this problem.

    We specify the behaviour here of two types of of DHCPv4 client that
    operate in a multi-stage boot process.   The first type is any
    DHCPv4 client that is not the last DHCPv4 client to operate in a
    multi-stage boot process.   There may be more than one such
    client - for example, a PXE loader may load an operating-system-
    specific boot loader (for example, the GRUB boot loader that comes
    with some versions of Linux, and the GRUB loader may then load the
    operating system).   We call both of these clients early-stage
    clients.

    The second kind of client is the one that runs in the final stage
    of the boot process - typically the DHCPv4 client included in the
    operating system that has been loaded.  We call this client the
    final-stage client.

    Early-stage clients that operate as any stage other than the  
final stage
    of a multi-stage boot process--for example, the DHCP client in a
    PXE boot loader--SHOULD provide a mechanism whereby subsequent boot
    stages can obtain the IP address acquired, the subnet mask, the
    lease time, the IP address of the DHCP server, the default
    router, and the client identifier used in acquiring the IP address.

    Early-stage clients SHOULD provide a mechanism whereby the final
    boot stage can configure the client identifier that will be used
    for subsequent reboots.

    Final-stage DHCPv4 clients SHOULD query the state of DHCP clients
    in previous stages of the boot process.   Where possible, such
    clients SHOULD use the same client identifier that the previous
    boot loader stages used.

    In cases where the identifier uses by the previous boot loader
    stages was not conformant with the requirements states in section
    4.1, and where a mechanism is present for the DHCP client to
    configure a different client identifier to use in subsequent boots,
    the final-stage DHCPv4 client SHOULD generate a new client
    identifier according to the rules presented in this section.

    The final-stage client SHOULD release the lease acquired with the
    old client identifier and acquire a new lease using the new
    identifier.  The final-stage client SHOULD configure the
    early-stage client or clients to use this new identifier.  This
    process ensures that any information and resources associated with
    the original are discarded or released by the DHCP server, and that
    no extra leases are consumed on the DHCP server.

    Final-stage DHCPv4 clients that cannot reconfigure the client
    identifier used by earlier stages but that can determine the client
    identifier that was used SHOULD establish contact with the DHCP
    server by entering the INIT-REBOOT state, re-acquiring the lease,
    and then sending a DHCPRELEASE to release the lease.   Such clients
    SHOULD then obtain a lease using the

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Jun 2005 14:45:23 -0700

I've released a new version of this document which I believe corrects  
all the issues that were raised in the IESG review.   This has  
already been through last call; I leave the question of whether it  
needs a second last call to wiser heads than mine, but if it does  
have to go through another last call, I'd propose that we restrict  
the discussion in that last call to the topics mentioned below.   The  
big question in my mind is how people feel about section 7 of the  
document.   If you have strong feelings about it, I'd appreciate  
hearing about them before the draft submission cutoff for the next  
IETF meeting in Paris.   :')

I'll summarize the changes based on the review:

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

I added a paragraph that addresses this specifically, at the end of  
section 5.

> clarification may be in order.

I was under the mistaken impression that the IANA was tracking DHCP  
hardware identifiers, but they are not.   I've changed the text in  
the IANA considerations section to "None."

> found should block publication at this stage.

There's no obvious way to fix the problem of the diffs to RFC2131 and  
2132 without actually releasing new versions of these RFCs, which is  
a horrifying thought because neither one would get through the  
current IETF review process.   So I don't see a way around this  
particular problem, which I agree is a real problem.   However, I  
asked my wife, Andrea, to read the draft over, and she helped me to  
clarify some of the more turgid bits of prose elsewhere in the  
document, so I think it's a bit more readable now.   :'}

> Discuss:

Fixed.   It turns out it also updates RFC3315 in a minor way, in the  
sense that it places a SHOULD on DHCPv6 clients that they have some  
mechanism whereby they can share their DUID with DHCPv4 clients.    
This was never said explicitly in the Applicability section of the  
previous version, so I updated the Applicability section and also  
added an Updates: header to the document.

> Comment:

Fixed, thanks!

> [...]

As Bernie Volz said in his response, and I said in another response,  
there's no obvious fix for this.   I've added a new section to the  
draft, section 7, which discusses this issue, and also updated the  
problem statement in section 2.2 to mention that this is an issue.    
Section 7 makes some recommendations for implementors of multi-stage  
network boot devices, but doesn't state any new requirements.

> and a normative reference.

Fixed, thanks.

> those are not allowed. Easy to fix, just use perenthesis instead

Also fixed.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Jun 2005 17:08:00 +0200

The clarification that I asked for is perfect, except for
a spelling error (non-complient) that I trust and hope
the RFC Editor will fix.

Thanks
    Brian

Ted Lemon wrote:
> all the issues that were raised in the IESG review.   This has  already 
> been through last call; I leave the question of whether it  needs a 
> second last call to wiser heads than mine, but if it does  have to go 
> through another last call, I'd propose that we restrict  the discussion 
> in that last call to the topics mentioned below.   The  big question in 
> my mind is how people feel about section 7 of the  document.   If you 
> have strong feelings about it, I'd appreciate  hearing about them before 
> the draft submission cutoff for the next  IETF meeting in Paris.   :')
> 
> hardware identifiers, but they are not.   I've changed the text in  the 
> IANA considerations section to "None."
> 
>> Sam Hartman:
>> Comment:
> 2132 without actually releasing new versions of these RFCs, which is  a 
> horrifying thought because neither one would get through the  current 
> IETF review process.   So I don't see a way around this  particular 
> problem, which I agree is a real problem.   However, I  asked my wife, 
> Andrea, to read the draft over, and she helped me to  clarify some of 
> the more turgid bits of prose elsewhere in the  document, so I think 
> it's a bit more readable now.   :'}
> 
>> Russ Housley:
>> Discuss:
>> [2005-05-09]
>>   The Introduction says:
>>   >
> mechanism whereby they can share their DUID with DHCPv4 clients.    This 
> was never said explicitly in the Applicability section of the  previous 
> version, so I updated the Applicability section and also  added an 
> Updates: header to the document.
> 
>> Comment:
>> [2005-05-09]
>>   Section 2.4 says:
>>   >