Subject: [dhcwg] Changes in draft-ietf-dhc-dhcpinform-clarify-05

From: "David W. Hankins" <[email-masked]>
Date: Fri, 9 Jul 2010 21:58:26 -0700

Pursuant to the on-mike and then off-list discussion with Kim, I have
done my best to reintroduce the Subnet Selection Option into the
draft.

This becomes an open question to the WG including Kim; is the placement
of the interrogation of the Subnet Selection Option correct?  Right
now it is placed first, because that is the order applied to the
option when it is used when the client normally supplies it.  It's the
best place I can think of.

However, the Relay Agent Information Link Selection Sub-Option is
normally used before the Subnet Selection Option is used (the Relay
Agent option normally takes precedence), so this now reverses that
behavior specifically for DHCPINFORM, which feels strange.

The only alternative I can see involves reordering the entire 'relevant
IPv4 address' priority list to also place 'giaddr' earlier - but this
seems strange since 'ciaddr' will be used to direct replies.  If the
server gives valid configuration for 'giaddr' and directs the reply to
'ciaddr'...and it's actually received...is this correct behavior?

I have a second open question to the WG at large, which is on the
behaviour I have described for selecting a return address.  'ciaddr'
is preferred if nonzero even if 'giaddr' is nonzero.  This means we
will reply to the client directly even when a relay agent is involved.
I believe this is defined in RFC 2131 and I believe there are reasons
why it must be this way (zeroed 'yiaddr' is not defined in relay agent
behavior), but it has been questioned; is that right?

Are there any existing implementations in attendance that direct
replies to DHCPINFORM to the 'giaddr' field contents ahead of any
'ciaddr' field contents?

Note that ISC DHCP (since before my time) directs replies to 'ciaddr'
before 'giaddr'.  So if there are conflicting implementations here we
may want to make some effort to determine which behavior we prefer,
or to document potential problems.

To start with, if we could get a quick informal survey of
implementations I would be much obliged.  Please check your code. :)
If there are no conflicting implementations, there is nothing to
change.

----- Forwarded message from IETF I-D Submission Tool <[email-masked]> -----

Date: Fri,  9 Jul 2010 21:41:51 -0700 (PDT)
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
Subject: New Version Notification for
	draft-ietf-dhc-dhcpinform-clarify-05

A new version of I-D, draft-ietf-dhc-dhcpinform-clarify-05.txt has been successfully submitted by David Hankins and posted to the IETF repository.

Filename:	 draft-ietf-dhc-dhcpinform-clarify
Revision:	 05
Title:		 Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications
Creation_date:	 2010-07-09
WG ID:		 dhc
Number_of_pages: 9

Abstract:
The DHCPINFORM message within the DHCPv4 protocol has in operation
diverged incompatibly from the current defined standard.  This
document seeks to provide clarification of actual behaviour and
guidance for some situations that were previously omitted.

The IETF Secretariat.

----- End forwarded message -----

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 9 Jul 2010 22:03:13 -0700

Oh, the other change to the draft is the removal of my 'rfc 2131
quotes' section, which I was using as a crib sheet while editing the
document.  Because it was a cut and paste dump, it was formatted badly
and was confusing to readers, so I have commented it out.  It was
never intended to survive the process.