Subject: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery

From: Joe Touch <[email-masked]>
Date: Mon, 13 Feb 2012 14:00:16 -0800

Hi, all,

I've reviewed this document as part of the transport area directorate's 
ongoing effort to review key IETF documents. These comments were written 
primarily for the transport area directors, but are copied to the 
document's authors for their information and to allow them to address 
any issues raised. The authors should consider this review together with 
any other last-call comments they receive. Please always CC 
[email-masked] if you reply to or forward this review.

This request was received Feb. 2, 2012.

This document describes an extension to DHCPv4 for the bulk query and 
transfer of current lease status over TCP.

The following transport issues were noted, and are significant:

UPDATES- The document updates DHCP with support for TCP, and as such 
this document seems like it should UPDATE RFC2131

PORT USE- Although DHCPv4 has an assigned TCP port, this document should 
clearly indicate that there is no other specified use of that port other 
than the bulk lease query described in this document

It should further explain why no other existing DHCP exchanges are not 
valid on the TCP port.

CONNECTION MANAGEMENT- The document describes the use of TCP connections 
for bulk transfer, but needs to be more specific about which side (relay 
client or server) closes the connection, under what circumstances, and 
with what mechanism (e.g., graceful CLOSE vs. ABORT, as per RFC 793)

sec 7.3 indicates some conditions for terminating connections; this 
section should indicate which side performs this, and by what method 
(CLOSE, ABORT)

this sec also allows connections to stay open after all pending 
transactions are complete (MAY); the rationale for this should be given, 
or the connection MUST be closed.

the same issue applies to sec 7.8 and 8 throughout; sec 8.5 is 
particularly problematic on this issue because it discusses aborting a 
request using in-band data, which may not be available if the connection 
is closed using ABORT. the state of other pending connection shsould be 
discussed too.

TIMEOUTS- Sec 6.3 defines a timeout for the TCP connection; is this 
intended to supercede any TCP timeout? or is it intended to be the min 
of the TCP timeout and the specified one?

This section should more carefully explain behavior when a connection is 
dropped and the reason - e.g., timeout, abort, close.

INTERLEAVING- sec 7.7 says that the server MUST interleave replies; 
there doesn't seem a valid reason for this requirement. clearly the 
receiver MUST tolerate interleaved replies. having the server interleave 
replies is relevant only if each request/reply has its own timeout -- 
which should be overridden if there is another response in progress 
anyway. This issue should be more clearly explained and motivated.

There were some other issues noted in this document. These comments 
appear below, and although not focused on transport issues, they 
represent significant issues that IMO should be addressed as well.

NOTE - regarding some terminology issues, I did not survey current DHCP 
RFCs for consistency, but IMO these terms should be corrected even if 
they are then inconsistent with existing specs.

Joe

-----------

Major non-transport issues:

- In many places the doc allows inaction to substitute for either 
positive or negative confirmation. IMO, this invites implementation 
errors, and should be avoided. E.g., status return codes, data source 
option missing, query-for-all-configured-IPs, etc.

- the data source option reserved codes need more detailed 
specification. if these are intended for future use, then they MUST be 
ignored by the receiver (at least). if they are to mean anything at all, 
at least one bit (typically all of them) MUST be set to zero by the 
transmitter for implementations that do not support any of the component 
fields.

further, the length of this option MUST be 1

- The protocol supports bulk transfer that is not data driven. This 
could represent a security vulnerability by exposing information that 
may not be on the data path (and thus already accessible) to a relay 
agent. This should be discussed in the security considerations section.

- Integer quantities should be referred to as "unsigned 32-bit integers" 
throughout.

- "VPN" is used throughout to refer to "private" addresses (RFC 1918); a 
VPN is not just private addressing.

- (this is a nit with all IDs, FWIW) SHOULD and SHOULD NOT are used 
throughout without context. Any time SHOULD is used instead of MUST (or 
SHOULD NOT rather than MUST NOT), it is useful to explain a viable 
exception. If no such exception exists, the rationale for selecting 
SHOULD over MUST should be included.

- It would be useful to explain why STATUS-CODE strings MUST NOT be 
null-terminated; is that a protocol violation, or are you just saying 
that NULLs are valid in these strings? the description should be clear 
that the string field describes the string length without any 
termination characters.

- start-time-of-state is expressed as an offset from base-time; this 
appears to be the only time indicated as an offset rather than as an 
absolute. That inconsistency invites implementation errors; IMO, this 
should be absolute too.

- option lengths: throughout, the doc refers to option lengths as being 
"an octet"; they are *indicated* in one octet. Some are constant (e.g., 
DCHP-STATE), some allow the contents of the octet to vary. Again, this 
is an *unsigned integer* octet.

- some of the information provided (in DHCP-STATE) goes beyond that of 
DHCP. It would be useful to motivate the need for this information in a 
bulk query, and why it is not similarly available for nodes using UDP 
(e.g., as an extension to DHCPv4, not just to the bulk transfer 
command). again, absence of state information should not indicate state. 
State should always be expressed explicitly. these states are further 
meaningless without a state diagram explaining them. if such a diagram 
is not possible (as noted at end of sec 6.2.7), then the states are 
irrelevant and the option should not be included.

- in sec 6.2.9 the term "not allowed" should be explained - are they 
reserved for future use and thus ignored? or are they "not allowed" - in 
which case the doc should indicate handling if they appear.

- sec 7.4 states that the clock skew of zero is desired; this assumes 
E2E delays under 1sec. An explanation of why this is desired should be 
given, as well as the consequences of it not.

Other non-transport issues:

- The document includes definitions and references to irrelevant 
deployment and implementation issues, notably DSLAMs, concentrators, and 
access concentrators. These should not appear formally; they should be 
used only to usefully illustrate currently intended uses.

- The doc refers to "real-time", which could imply requirements not 
supported. This should be replaced with "rapid".

- "absolute time" *indicates* (rather than contains) the number of 
seconds...

- "third party agent" should be explained, i.e., neither DHCP client nor 
DHCP server.

- "downstream" and "upstream" should be defined as both away from the 
server *and towards the client* ("away from the server" has two directions).

- sec 3 should refer to relays, and returning the entire set or 
individual bindings; there is no reason to explain the goals in terms of 
access concentrators.

- sec 3.2 appears to provide contradictory advice - caching is required, 
but should be avoided? it would be useful to resolve this inconsistency.

- sec 3.3 refers to 'fast path', but this term doesn't make sense in 
this context because fast-path is a forwarding issue. it would be useful 
to explain what you mean, and pick a different term

----

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Feb 2012 14:16:04 -0800

Hi, all,

One additional transport suggestion:

- it would be useful to include recommended configurations for TCP 
connections. Given these are multi-byte request/response exchanges, 
Nagle should be disabled, e.g.

Joe

---

From: Kim Kinnear <[email-masked]>
Date: Fri, 17 Feb 2012 15:09:17 -0500

Joe,

Thank you for your review.

My responses are indented, below...

On Feb 13, 2012, at 5:00 PM, Joe Touch wrote:

> Hi, all,
> 
> I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC [email-masked] if you reply to or forward this review.
> 
> This document describes an extension to DHCPv4 for the bulk query and transfer of current lease status over TCP.
> 
> UPDATES- The document updates DHCP with support for TCP, and as such this document seems like it should UPDATE RFC2131

	While this document clearly builds on RFC 2131, it
	doesn't actually change anything that anyone is doing
	that is currently based on RFC 2131.  My understanding of
	"updates" is that, in order to understand the first RFC
	(in this case, RFC 2131), you need to read all of the
	RFC's that "update" it.  That isn't the case here -- you
	can be very happy reading and implementing DHCPv4 by
	reading RFC 2131 and never have to know that DHCPv4 Bulk
	Leasequery exists.  In general, in the DHC WG, we seem to
	set a pretty high bar for what "udpates" another RFC.  I
	don't see that this document has met those requirements.
	But this isn't really my call.  I'll let Ralph Droms and
	the DHC WG chairs decide on this one, and I'll do
	whatever they tell me to do.

> 
> PORT USE- Although DHCPv4 has an assigned TCP port, this document should clearly indicate that there is no other specified use of that port other than the bulk lease query described in this document

	Sure.
> 
> It should further explain why no other existing DHCP exchanges are not valid on the TCP port.

	I've been taken to task by various IETF folks at
	varying levels of seniority for explaining too *much* of
	the "why".  My understanding is that this is a protocol
	specification and not a design document, and as such it
	is not only not necessary but frequently
	counter-productive to give lots of justifications for the
	decisions made when constructing the protocol.

	In this case, I can't speak for the wG at large, because
	we never proposed anything else.  The reason we didn't
	propose anything else was that we didn't want to "update"
	RFC 2131 with a new way to do DHCPv4 in general.  But
	that all kind of comes down to "because we said so".  We
	were trying to keep this draft focused.  But if I put
	words in the document which say that, someone in the WG
	would tell me to take them out.

	I have no problem motivating the "interesting" decisions
	we've made, or perhaps the contentious ones, but this one
	was a no-brainer that never even came up (to the best of
	my memory).

	Having said all of that, I'll put something in that says
	that we were trying to keep it simple.

> 
> CONNECTION MANAGEMENT- The document describes the use of TCP connections for bulk transfer, but needs to be more specific about which side (relay client or server) closes the connection, under what circumstances, and with what mechanism (e.g., graceful CLOSE vs. ABORT, as per RFC 793)

	Here is what we have now, 7.8 is for clients, 8.5 is for
	servers:

> 7.8.  Closing Connections  [Client Section]
> 
>    The requestor SHOULD close the connection after the
>    DHCPLEASEQUERYDONE message is received for the last outstanding query
>    that it has sent, if it has no more queries to send.
> 
> 8.5.  Closing Connections   [Server Section]
> 
>    The DHCPv4 server SHOULD start a timer for BULK_LQ_DATA_TIMEOUT
>    seconds for a particular connection after it sends a
>    DHCPLEASEQUERYDONE message over that connection and if there is no
>    current query outstanding for that connection.  It should clear this
>    timer if a query arrives over that connection.  If the timer expires,
>    the DHCPv4 server should close the connection.
> 
>    The server MUST close its end of the TCP connection if it encounters
>    an error sending data on the connection.  The server MUST close its
>    end of the TCP connection if it finds that it has to abort an in-
>    process request.  A server aborting an in-process request SHOULD
>    attempt to signal that to its requestors by using the QueryTerminated
>    status code in the status-code option in a DHCPLEASEQUERYDONE
>    message, including a message string indicating details of the reason
>    for the abort.   If the server detects that the requesting end of the
>    connection has been closed, the server MUST close its end of the
>    connection.

	All connections are closed with a graceful CLOSE, and not
	with an ABORT.  I'll add that to the document.

	I'm at a loss to know how to be more specific about which
	side of the connection closes the connection.  There are
	rules for the client in 7.8, and rules for the server in
	8.5.

> sec 7.3 indicates some conditions for terminating connections; this section should indicate which side performs this, and by what method (CLOSE, ABORT)

	Section 7.3 discusses in two places where the "requestor" may
	drop the connection.  The term "requestor" is used to
	indicate which "side" performs the actions.  All of
	Section 7 is about "Requestor Behavior", and the specific
	details of section 7.3 in all cases indicate that the
	instructions for dealing with the connection concern the
	"requestor" explicitly.

	I'll enhance the explanation to include that CLOSE should
	be used.

	If there is a specific set of instructions that are
	unclear, I don't see them, so it would help me if you
	could give me more detailed guidance than "Section 7.3".  
	Thanks.

> 
> this sec also allows connections to stay open after all pending transactions are complete (MAY); the rationale for this should be given, or the connection MUST be closed.

	I will add some words which clarify the reasons why you
	might want to leave the connection open after all pending
	transactions are complete.
> 
> the same issue applies to sec 7.8 and 8 throughout; sec 8.5 is particularly problematic on this issue because it discusses aborting a request using in-band data, which may not be available if the connection is closed using ABORT. the state of other pending connection shsould be discussed too.

	The in-band data is not required for proper protocol
	operation, it is valuable because it can limit the amount
	of data required when and if the connection is
	reestablished.  All connections are closed by CLOSE.  I
	assume that, in your comment, "other pending
	connection[s]" means other data flows that might exist on
	the TCP connection that is coming down.  I will add some
	words that say that those Bulk Leasequery data flows will
	also be stopped.
> 
> TIMEOUTS- Sec 6.3 defines a timeout for the TCP connection; is this intended to supercede any TCP timeout? or is it intended to be the min of the TCP timeout and the specified one?

	The BULK_LQ_DATA_TIMEOUT is completely application
	specific and essentially independent of the underlying
	connection timeout.  I will add words to that effect
	in the document.
> 
> This section should more carefully explain behavior when a connection is dropped and the reason - e.g., timeout, abort, close.
	
	The application employing Bulk Leasequery doesn't
	care about *why* the connection went away.  It
	doesn't have to know if it was abort, close, or
	timeout.  I will say that in this section.
> 
> INTERLEAVING- sec 7.7 says that the server MUST interleave replies; there doesn't seem a valid reason for this requirement. clearly the receiver MUST tolerate interleaved replies. having the server interleave replies is relevant only if each request/reply has its own timeout -- which should be overridden if there is another response in progress anyway. This issue should be more clearly explained and motivated.

	Robert Sparks offered clarification, which I like
	a lot and have already agreed to use:
> 
> 	Is the requirement you are really trying to capture "MUST
> 	NOT block sending replies on new queries until all
> 	replies for the existing query are complete."?
> 

> There were some other issues noted in this document. These comments appear below, and although not focused on transport issues, they represent significant issues that IMO should be addressed as well.
> 
> NOTE - regarding some terminology issues, I did not survey current DHCP RFCs for consistency, but IMO these terms should be corrected even if they are then inconsistent with existing specs.
> 
> Joe
> 
> -----------
> 
> - In many places the doc allows inaction to substitute for either positive or negative confirmation. IMO, this invites implementation errors, and should be avoided. E.g., status return codes, data source option missing, query-for-all-configured-IPs, etc.

	While I personally tend to agree with you on this one, I
	have clear direction from the DHC WG that this is *not*
	the approach that the WG wants to take.  Here is the
	status code text:

>    A status-code option MAY appear in the options field of a DHCPv4
>    message.  If the status-code option does not appear, it is assumed
>    that the operation was successful.  The status-code option SHOULD NOT
>    appear in a message which is successful unless there is some text
>    string that needs to be communicated to the requestor.

	This was wrangled over at some length in the DHC WG,
	and this was the way that it needed to be to pass
	last call.  I don't feel that I can change it
	at this time.
	
> 
> - the data source option reserved codes need more detailed specification. if these are intended for future use, then they MUST be ignored by the receiver (at least). if they are to mean anything at all, at least one bit (typically all of them) MUST be set to zero by the transmitter for implementations that do not support any of the component fields.
> 

	Yes, subsequent to the creation of this section,
	Amanda Baber of IANA enlightened me regarding
	the different between RESERVED and UNASSIGNED.
	These should be UNASSIGNED, and I will add words
	that say that a receiver should ignore the
	bits that are unassigned.
> 
> - The protocol supports bulk transfer that is not data driven. This could represent a security vulnerability by exposing information that may not be on the data path (and thus already accessible) to a relay agent. This should be discussed in the security considerations section.

	All data that is exposed has already been
	exposed using UDP to regular DHCP port.   But please see
	my response to Stephen Farrell (which is too long to include
	here) to see if it covers the issues about which you
	have concerns.
> 
> - Integer quantities should be referred to as "unsigned 32-bit integers" throughout.

	Good point (though some are 16 bits).  The signed-ness is not
	specified and should be.  I'll make sure that it is.
> 
> - "VPN" is used throughout to refer to "private" addresses (RFC 1918); a VPN is not just private addressing.

	Hmm.  Actually, VPN in this document does not refer to RFC 1918
	private addressing.  If this is important to you, could you
	be more specific as to your concern?
> 
> - (this is a nit with all IDs, FWIW) SHOULD and SHOULD NOT are used throughout without context. Any time SHOULD is used instead of MUST (or SHOULD NOT rather than MUST NOT), it is useful to explain a viable exception. If no such exception exists, the rationale for selecting SHOULD over MUST should be included.

	This is an interesting approach, which is new to me.  I
	can see the value in looking for viable exceptions.  I
	think justifying SHOULD and not MUST is a bit much, and
	wouldn't make it through the "keep it short and simple"
	filters that the DHC WG seems to place on DHC drafts.
	But as I said, I'll look at every SHOULD (NOT) and see if
	I can find concise examples of reasons.  But I'm
	concerned that this will greatly lengthen the draft.
> 
> - It would be useful to explain why STATUS-CODE strings MUST NOT be null-terminated; is that a protocol violation, or are you just saying that NULLs are valid in these strings? the description should be clear that the string field describes the string length without any termination characters.

	I will clarify this.  Nulls are not allowed in the strings.
	DHCP options have an unfortunate history where some
	large vendors null terminated their strings even though
	they were not supposed to, so now we always make a big
	deal out of it so it doesn't happen again.
> 
> - start-time-of-state is expressed as an offset from base-time; this appears to be the only time indicated as an offset rather than as an absolute. That inconsistency invites implementation errors; IMO, this should be absolute too.

	There are two kinds of time options here, input options
	and output options.  The input options are all absolute
	times.  The output options are all offset times from the
	base time (which by design is the only absolute time in
	the output packets).  There are several input options
	defined in this document.  The start-time-of-state is the
	only output option defined in this draft.  It is defined
	as a offset to the base time in large part because the
	*other* output options that are used in the DHCP packet
	are *also* offsets to the base time.  These options are
	not new, but are options that already exist in other
	RFC's.  So, while it looks like the state-time-of-state
	is the odd man out at first glance, it actually is an
	offset time because the *other* options with which it
	will appear are also offset times.

> 
> - option lengths: throughout, the doc refers to option lengths as being "an octet"; they are *indicated* in one octet. Some are constant (e.g., DCHP-STATE), some allow the contents of the octet to vary. Again, this is an *unsigned integer* octet.

	Yes, the size of an option is stored in
	one octet.  So, yes, the length is *indicated*
	by the value in that one octet.

	But the length may be 1 octet, it may be
	5 octets, it may vary between 8 and 10 octets.

	I don't understand your concern.  Are you	
	saying that the length should not be
	stated to be "1 octet" or "5 octets"?

	I will fix the integer to be specifically
	unsigned (as previously indicated). 
> 
> - some of the information provided (in DHCP-STATE) goes beyond that of DHCP. It would be useful to motivate the need for this information in a bulk query, and why it is not similarly available for nodes using UDP (e.g., as an extension to DHCPv4, not just to the bulk transfer command). again, absence of state information should not indicate state. State should always be expressed explicitly. these states are further meaningless without a state diagram explaining them. if such a diagram is not possible (as noted at end of sec 6.2.7), then the states are irrelevant and the option should not be included.

	The state transition diagram can certainly be drawn, but
	as it is fully connected, such a picture conveys no
	useful information.  The transitions are not themselves
	useful in any case, as the the Bulk Leasequery is a
	snapshot of information at one instant of time.  There is
	every reason to assume that as the state moves from one
	value to another that an external entity would not see
	all (or even many) of these transitions.  This is a
	snapshot of the DHCP state, and could be nothing else in
	the environment of Bulk Leasequery.

	The reason why the state transition graph is fully
	connected is due to the common practice in DHCPv4 of
	having two servers running in a failover relationship.
	There are then two state machines for the lease state,
	and at times one "leads" and the other "follows", and at
	other times the other "leads" and its partner "follows".
	So, examined individually, the state machines for each
	individual failover partner is fully connected because at
	any time it may receive an update from its partner that
	it decides to accept that will simply "set" the state to
	the value supplied by the partner.

	All of this is orthogonal to the Bulk Leasequery protocol
	-- except that we want the user of the Bulk Leasequery
	protocol to be able to make sense out of information
	supplied by each of the failover partners.  Or any
	partners running any increased availability solution.

	So, that is the reason why the dhcp-state option exists
	at all -- to allow the user of Bulk Leasequery to make
	sense out of the results of sending a Bulk Leasequery to
	two different (but cooperating) DHCPv4 servers.

	The DHC WG felt that this information was worthwhile to
	have in this document, and I agree (or we wouldn't have
	put it in).

> 
> - in sec 6.2.9 the term "not allowed" should be explained - are they reserved for future use and thus ignored? or are they "not allowed" - in which case the doc should indicate handling if they appear.

	Ah, good catch.  The "not allowed" will become UNASSIGNED,
	based on my conversation with Amanda Baber of IANA.
	I will add words that suggest that they should be
	ignored.

	The point of this table is, actually, not how to
	handle them (that is the up to the vpn-option draft/RFC),
	but rather to define a single new value.
> 
> - sec 7.4 states that the clock skew of zero is desired; this assumes E2E delays under 1sec. An explanation of why this is desired should be given, as well as the consequences of it not.

	I have given specific instructions on how to handle non-zero
	clock skews.  There are no "consequences".  You code it
	so that it works with non-zero clock skew.  Period.

	It is desired because it is less confusing to humans.

> - The document includes definitions and references to irrelevant deployment and implementation issues, notably DSLAMs, concentrators, and access concentrators. These should not appear formally; they should be used only to usefully illustrate currently intended uses.

	These appear in the text in order to give 
	the otherwise abstract design goals some concrete
	examples.   We already removed a lot of the design
	goals, are you suggesting that they all be removed?

> 
> - The doc refers to "real-time", which could imply requirements not supported. This should be replaced with "rapid".

	I'll fix this.
> 
> - "absolute time" *indicates* (rather than contains) the number of seconds...

	I'll fix this.
> 
> - "third party agent" should be explained, i.e., neither DHCP client nor DHCP server.

	I will fix this.
> 
> - "downstream" and "upstream" should be defined as both away from the server *and towards the client* ("away from the server" has two directions).

	Sure, I'll add these words.
> 
> - sec 3 should refer to relays, and returning the entire set or individual bindings; there is no reason to explain the goals in terms of access concentrators.

	I don't know about this.  I could certainly change it,
	but is this really important to you?  There was quite a
	bit of negotiation in the WG about these examples.  I
	don't want to restart that discussion and have it all
	over again.  Does this really matter that much to you?

> 
> - sec 3.2 appears to provide contradictory advice - caching is required, but should be avoided? it would be useful to resolve this inconsistency.

	Use of Bulk Leasequery is designed to help you avoid
	caching.
> 
> - sec 3.3 refers to 'fast path', but this term doesn't make sense in this context because fast-path is a forwarding issue. it would be useful to explain what you mean, and pick a different term

	Yes, it is a forwarding issue, and many devices
	will not forward unless they know that they are forwarding
	to a device that has received a valid DHCPv4 address.
	The point (well, one point) of Bulk Leasequery is to
	allow these forwarders to gather data so that they
	can make the correct decision in the fast path.

------------

	Regards -- Kim

---

From: Kim Kinnear <[email-masked]>
Date: Fri, 17 Feb 2012 15:22:00 -0500

On Feb 13, 2012, at 5:16 PM, Joe Touch wrote:

> - it would be useful to include recommended configurations for TCP connections. Given these are multi-byte request/response exchanges, Nagle should be disabled, e.g.

	One of the co-authors had this to
	say:
> 
>   A bone headed implementation (either client or server) might send
>   bits and pieces of a message (for example, it would be easy for
>   an implementation to send the 2 bytes for the length of the
>   message in one request and then the message in a second). This is
>   exactly what you want the TCP protections for. So, I think we
>   should be silent on this issue.  I also can't see how there is
>   any harm in leaving it enabled (even in a 'clean'
>   implementation).
> 

	I tend to agree with him -- I don't see that this 	
	is going to cause a problem if we don't disable
	it.  But maybe I'm missing something.  Is there
	an important problem if we don't specify this one
	way or another?

	Thanks -- Kim

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

---

From: Ralph Droms <[email-masked]>
Date: Sat, 18 Feb 2012 07:39:23 -0500

Joe, Kim...

On Feb 17, 2012, at 5:47 PM 2/17/12, Joe Touch wrote:

> Hi, Kim,
> 
> First, thank you for your detailed response to my quite lengthy review.
> 
> Some further clarifications and confirmations appear below.
> 
> Joe
> 
> On 2/17/2012 12:09 PM, Kim Kinnear wrote:
>> 
>> Joe,
>> 
>> > I've reviewed this document as part of the transport area
>>> directorate's ongoing effort to review key IETF documents. These
>>> comments were written primarily for the transport area directors,
>>> but are copied to the document's authors for their information and
>>> to allow them to address any issues raised. The authors should
>>> consider this review together with any other last-call comments
>>> they receive. Please always CC [email-masked] if you reply to or
>>> forward this review.
>>> 
>>> This document describes an extension to DHCPv4 for the bulk query
>>> andtransfer of current lease status over TCP.
>>> 
>>> UPDATES- The document updates DHCP with support for TCP, and as
>>> suchthis document seems like it should UPDATE RFC2131
>> 
> Agreed. FWIW, my "bar" for that is whether implementing DHCPv4 as per RFC 2131 is changed by this doc. If DHCP fundamentally starts requiring TCP port support, then this doc then changes the spec as described in 2131 IMO.

Joe - I don't see that this document fundamentally requires TCP port support for DHCP operation as described in RFC 2131.  This document describes a protocol that is closely related to but independent of RFC 2131, and a server based on RFC 2131 can perform all the DHCP functions in RFC 2131 without considering this document.  So, I can see your point but I disagree that this document updates RFC 2131.

> Here are the reasons I think it DOES modify DHCP:
> 
> 	- Sec 10 requests option codes that extend the tables defined
> 	in the original RFC
> 
> I couldn't locate a recommendation on whether DHCP servers MAY implement this extension, SHOULD, or MUST (did I miss it? if not, it should be added). Regardless, that too would be a reason for this as an update to 2131. It's only NOT an update if this service is independent, IMO, and it doesn't read that way to me.

There are other RFCs that add new, independent functions to DHCP without making changes to RFC 2131 (e.g., RFC 4388), which are not listed as updating RFC 2131.

- Ralph

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Feb 2012 14:47:24 -0800

Hi, Kim,

Joe

> 	whatever they tell me to do.

Agreed. FWIW, my "bar" for that is whether implementing DHCPv4 as per 
RFC 2131 is changed by this doc. If DHCP fundamentally starts requiring 
TCP port support, then this doc then changes the spec as described in 
2131 IMO.

I couldn't locate a recommendation on whether DHCP servers MAY implement 
this extension, SHOULD, or MUST (did I miss it? if not, it should be 
added). Regardless, that too would be a reason for this as an update to 
2131. It's only NOT an update if this service is independent, IMO, and 
it doesn't read that way to me.

>> PORT USE- Although DHCPv4 has an assigned TCP port, this document
>> should clearly indicate that there is no other specified use of that
>>. port other than the bulk lease query described in this document
>
> 	Sure.
>>

Thanks. In this case, it's important to suggest why others should not 
add conventional DHCP query support to the TCP port.

>> CONNECTION MANAGEMENT- The document describes the use of TCP
>> connections for bulk transfer, but needs to be more specific about which
>> side (relay client or server) closes the connection, under what
>> circumstances, and with what mechanism (e.g., graceful CLOSE vs. ABORT,
>> as per RFC 793)
>

Under what conditions is it useful to not close at this time, and if so, 
when/why is it eventually closed?

In this case it's also useful to explain what "no more queries to send" 
means - are clients encouraged to keep the connection open in case there 
are more to send, or do you expect that the client knows when it opens 
the connection whether it has more to send - and if so, shouldn't it 
have already sent them?

>>     current query outstanding for that connection.  It should clear this

Is this a SHOULD?

And should the timer be cleared or restarted?

Under what conditions is it useful to not close at this time, and if so, 
when/why is it closed?

>>     the DHCPv4 server should close the connection.

Is this a SHOULD, as well?

Again, under what conditions is it useful to not close at this time, and 
if so, when/why is it closed?

>>     connection has been closed, the server MUST close its end of the

OK. I found it a bit confusing to have this in separate places, but I 
viewed this from the transport perspective. This is fine.

> 	rules for the client in 7.8, and rules for the server in

Somewhere you should state that the protocol exchange typically involves 
the client closing the connection, and that the server closes only under 
exceptions.

>> section should indicate which side performs this, and by what
>> method(CLOSE, ABORT)
>

It's probably sufficient to replace "requestor" with "client" to be 
consistent. However, this section then supercedes the description in 7.8 
and 8.5 above - i.e., you are handling exceptions on the client side as 
well.

I.e., 7.8 needs to include the exception cases listed in 7.3, or they 
should just be moved there.

>>> transactions are complete (MAY); the rationale for this should be
>>> given, or the connection MUST be closed.
>

FWIW, again this contradicts 7.8 which says the client SHOULD close 
after the response is received if it has no more queries to send.

This says "MAY" leave open. That's not the complement to SHOULD close.

> 	words that say that those Bulk Leasequery data flows will

OK.

>> TIMEOUTS- Sec 6.3 defines a timeout for the TCP connection; is
>> this intended to supercede any TCP timeout? or is it intended to be
>> the min of the TCP timeout and the specified one?
>

OK.

>> This section should more carefully explain behavior when a
>> connection is dropped and the reason - e.g., timeout, abort,
>> close.
> 	

Hmm. I would think that this information would be passed up to the 
application.

> 	a lot and have already agreed to use:

I didn't see that; can you send that to [email-masked] and me?

>> There were some other issues noted in this document. These
>> comments appear below, and although not focused on transport
>> issues, they represent significant issues that IMO should be
>> addressed as well.
>>
>> NOTE - regarding some terminology issues, I did not survey current
>> DHCP RFCs for consistency, but IMO these terms should be corrected
>> even if they are then inconsistent with existing specs.
>> Joe
>>
>> -----------
>>

AOK. I'll go down on the record as noting this as a bad idea that 
invites erroneous implementations, and the IESG can decide what it wants 
to recommend.

> 	bits that are unassigned.

Good.

>>
>> - The protocol supports bulk transfer that is not data driven.
>> This could represent a security vulnerability by exposing
>> information that may not be on the data path (and thus already
>> accessible) to a relay agent. This should be discussed in the
>> security considerations section.
>

Again, I didn't see it; please send a copy to [email-masked]

> 	specified and should be.  I'll make sure that it is.

AOK.

> 	be more specific as to your concern?

OK. I don't understand how it's being used, but if it's consistent with 
the rest of DHCP, that's fine.

However, I got thrown off by your use of 10.x.x.x.

There are appropriate addresses to use as examples in RFCs - see RFC 
5737, and please change this example accordingly.

>> - (this is a nit with all IDs, FWIW) SHOULD and SHOULD NOT are
>> used throughout without context. Any time SHOULD is used instead of
>> MUST (or SHOULD NOT rather than MUST NOT), it is useful to explain
>> a viable exception. If no such exception exists, the rationale for
>> selecting SHOULD over MUST should be included.
>

I would argue that any SHOULD that cannot be justified ought to be 
converted to a MUST ;-) That still keeps it short.

>> - It would be useful to explain why STATUS-CODE strings MUST NOT
>> be null-terminated; is that a protocol violation, or are you just
>> saying that NULLs are valid in these strings? the description
>> should be clear that the string field describes the string length
>> without any termination characters.
>

Good.

>> - start-time-of-state is expressed as an offset from base-time;
>> this appears to be the only time indicated as an offset rather than
>> as an absolute. That inconsistency invites implementation errors;
>> IMO, this should be absolute too.
>
> 	the output packets).

That'd be very useful to explain this way. Is this typical for DHCP? 
It's quite confusing IMO.

 >       ...There are several input options
>> - option lengths: throughout, the doc refers to option lengths as
>> being "an octet"; they are *indicated* in one octet. Some are constant
>> (e.g., DCHP-STATE), some allow the contents of the octet to vary. Again,
>> this is an *unsigned integer* octet.
>

The length should be "indicated in 1 octet". I'm just suggesting a 
change to the way it's described. When you say "the length is an octet", 
that is ambiguous and can mean that the length value is 1, not just that 
this value is stored in one octet.

>> - some of the information provided (in DHCP-STATE) goes beyond
>> that of DHCP. It would be useful to motivate the need for this
>> information in a bulk query, and why it is not similarly available
>> for nodes using UDP (e.g., as an extension to DHCPv4, not just to
>> the bulk transfer command). again, absence of state information
>> should not indicate state. State should always be expressed
>> explicitly. these states are further meaningless without a state
>> diagram explaining them. if such a diagram is not possible (as
>> noted at end of sec 6.2.7), then the states are irrelevant and the
>> option should not be included.
>
> 	useful information.

It's sufficient to indicate this then.

 >	... The transitions are not themselves

Using the failover case as a justification would be helpful.

> > - in sec 6.2.9 the term "not allowed" should be explained - are
>> they reserved for future use and thus ignored? or are they "not
>> allowed" - in which case the doc should indicate handling if they
>> appear.
>

AOK.

>> - sec 7.4 states that the clock skew of zero is desired; this
>> assumes E2E delays under 1sec. An explanation of why this is
>> desired should be given, as well as the consequences of it not.
>

I would argue that this then irrelevant, and there should be no 
statement about a skew of zero being preferred, since it could drive 
implementations that way unnecessarily.

> 	goals, are you suggesting that they all be removed?

Actually, yes, except as examples in the intro/motivation. Elsewhere 
they are IMO distracting.

> 	Sure, I'll add these words.

AOK to all above.

> 	over again.  Does this really matter that much to you?

The examples should focus on client/server/relay terminology. If other 
example terms are used, they should be parenthetical examples:

	relay (e.g., at a concentrator)

The point is that this is relevant without the concentrator. A 
concentrator is just one current example of where a relay exists, not 
the only one.

> 	Use of Bulk Leasequery is designed to help you avoid

OK - it'd be useful to be clear on that in sec 3.2.

> 	can make the correct decision in the fast path.

Per-IP validation of that sort of permission isn't a fast-path decision. 
Fast-path involves forwarding and policy decisions (which are not 
typically /32 decisions).

It would be useful to say this information is useful so such routers can 
make the appropriate decision, but the path (fast or slow) is irrelevant 
IMO.

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Feb 2012 22:49:36 -0800

Hi, Kim,

>>    any harm in leaving it enabled (even in a 'clean'

The harm is that Nagle will then eat into your own specifications (in 
this document) for minimums for timeouts.

This is exactly where a protocol document should be specific - 
interactions between the transport and other layers (and is one of the 
key reasons for transport directorate review).

Joe

---

From: Ted Lemon <[email-masked]>
Date: Sat, 18 Feb 2012 15:29:41 +0000

On Feb 17, 2012, at 5:47 PM, Joe Touch wrote:
Thanks. In this case, it's important to suggest why others should not add conventional DHCP query support to the TCP port.

The idea of doing DHCP stateful autoconfiguration over TCP is nonsensical: DHCP clients start out with no IP address, so it is not possible for them to do TCP.

The reason for sharing option codes is to avoid confusion: since existing DHCPLEASEQUERY option codes come out of the same namespace as DHCP options, if we were to propose that options in this documentation come out of a different namespace, we would have to declare that new namespace, which would have some options and option codes in common with the existing namespace.   This doesn't add value.

Historically, we have never said that when an option code is added, that updates RFC2131 (really, it would make more sense to say it updated RFC2132 if we were to go there, since RFC2132 is the document that describes DHCP options).   So it would be surprising and unconventional if this document were said to update either RFC2131 or RFC2132 simply because it defined one or more new option codes.

---

From: Kim Kinnear <[email-masked]>
Date: Thu, 23 Feb 2012 13:57:51 -0500

Joe,

There were two things that I referenced in response to your initial
review that you hadn't seen.  More details on those below:

--------------------------------------------

>> 	replies for the existing query are complete."?

	I wasn't clear here -- the entire result of our
	discussion was captured in the text above.

	Note that a server does not *have* to support multiple
	queries on the same connection.  If, however, a server
	chooses to do so, then the following discussion is
	operative:

	Based on my discussion with Robert Sparks, the sentence:

	  "A server that is processing multiple queries
	  simultaneously MUST interleave replies to the multiple
	  queries within the stream of reply messages it sends."

	will be replaced by the sentence:

	  "The server MUST NOT block sending replies on new
	  queries until all replies for the existing query are
	  complete."

-------------------------------------------------

> Again, I didn't see it; please send a copy to [email-masked]

	There are two related posts that I will include here
	in order to keep this discussion in some kind of order.

	Here are the words that I proposed to Stephen which
	he accepted:

  There are two specific issues regarding Bulk Leasequery
  security that deserve explicit mention.  The first is
  preventing information that Bulk Leasequery can provide from
  reaching clients who are not authorized to receive such
  information.  The second is ensuring that authorized clients of
  the Bulk Leasequery capability receive accurate information
  from the Server (and that this information is not disrupted in
  transit).

  To prevent information leakage to unauthorized clients Servers
  SHOULD restrict Bulk Leasequery connections and
  DHCPBULKLEASEQUERY messages to certain requestors, either
  through explicit configuration of the Server itself or by
  employing external network elements to provide such
  restrictions.  In particular, the typical DHCPv4 client SHOULD
  NOT be allowed to receive a response to a Bulk Leasequery
  request, and some technique MUST exist to allow prevention of
  such access in any environment where Bulk Leasequery is
  deployed.

  Connections not from permitted requestors SHOULD be closed
  immediately, to avoid server connection resource exhaustion or
  alternatively, simply not be allowed to reach the server at
  all.  Servers SHOULD have the capability to restrict certain
  requestors to certain query types.  Servers MAY reply to
  queries that are not permitted with the DHCPLEASEQUERYDONE
  message with a status-code option status of NotAllowed, or MAY
  simply close the connection.

  To prevent disruption and malicious corruption of Bulk
  Leasequery data flows between the server and authorized clients
  these data flows SHOULD transit only secured networks.   These
  data flows are typically infrastructure oriented, and there is
  usually no reason to have them flowing over networks where such
  attacks are likely.  In the rare cases where these data flows
  might need to be sent through unsecured networks, they MUST
  sent over connections secured through means external to the
  DHCPv4/DHCPv6 server and its client(s) (e.g., through VPN's).

	Here is Ted Lemon's reply to Stephen's suggestion about
	using SSH/TLS to secure the data flows of DHCPv4
	Bulk Leasequery:

From Ted Lemon, Feb 22 2012, 10:37:12 EST:

The main reason why TLS wasn't included is that there is zero
chance of anyone using it.   In practice this protocol is useful
only in a very specific sort of application: communications
between the core of an ISP network and the edge of the ISP
network.   Encrypting everything would be quite expensive; the
value of the data that would be acquired in an attack is low; the
risk that there could be an attacker that would do this is low,
since it would require physical access.   Furthermore, if someone
does break in, they can just collect this data with a sniffer.

Given these considerations, the additional verbiage and testing
required for TLS support seemed unnecessary and potentially
damaging, since untested code is vulnerable code.   The working
group did actually consider requesting that the authors add TLS
to the document, but concluded that it was not worthwhile.

-----------------------------

	Regards -- Kim

---

From: Kim Kinnear <[email-masked]>
Date: Thu, 23 Feb 2012 17:00:01 -0500

Joe,

I've edited the the email trail to try to concentrate on
the remaining open issues.  I've also removed the two
issues that were included in the email I sent you an hour
or so ago, since I expect that they will be covered in
continuations of that thread.

To summarize, there are 3 issues remaining that are
not included below:

1. The NAGLE issue you raised, which has its own thread.

2. The two issues:

	a) Interleaving

	b) Possible security vulnerability if data
	is available that wasn't already in the data
	path.

3. The ? issues remaining, below.  I think that
the number could be 0, but probably not.

Regards -- Kim

On Feb 17, 2012, at 5:47 PM, Joe Touch wrote:

> Under what conditions is it useful to not close at this time, and if so, when/why is it eventually closed?
> 
> In this case it's also useful to explain what "no more queries to send" means - are clients encouraged to keep the connection open in case there are more to send, or do you expect that the client knows when it opens the connection whether it has more to send - and if so, shouldn't it have already sent them?

	These are not uninteresting questions, but they are over
	the line from protocol specification and into
	implementation in my view.  I can certainly imagine that
	the requestor has multiple queries to send but has chosen
	to send them serially instead of in parallel (on the same
	connection or on different connections).  That would be
	way that the requestor might know that it had more
	queries to send.  It might have a queue of them.

	I will add this to the document:

	"If a requestor doesn't know if it has more queries to
	send or not, then it SHOULD close the connection."

>>>    current query outstanding for that connection.  It should clear this

	Yes, I'll change it.
> And should the timer be cleared or restarted?

	I was thinking of them as the same thing, but restarted
	is probably better language.  I'll change it.
> 
> Under what conditions is it useful to not close at this time, and if so, when/why is it closed?

	All of these SHOULDs derive from the fundamental SHOULD
	about starting a timer.  You don't *have* to have a timer
	to implement this protocol.  You SHOULD use a timer, but
	you don't *have* to.  I can imagine other ways to dealing
	with closing dead connections which don't involve timers.
	No, I really don't want to put them into the document.
	But the initial SHOULD says that if you don't use a
	timer, you can still say that you implement this
	capability.
> Is this a SHOULD, as well?

	Yes, thanks, I'll change it.
> 
> Again, under what conditions is it useful to not close at this time, and if so, when/why is it closed?

	Again, this is a SHOULD because you don't even have to
	have a timer.  But even if you have a timer, you don't
	have to close it when the timer goes off.  You might want
	to be "smarter" about something, or use some external
	information not represented here to make what you
	consider a better decision.  The SHOULD allows you to do
	that without causing you to wonder if you really support
	the document.

> OK. I found it a bit confusing to have this in separate places, but I viewed this from the transport perspective. This is fine.
> 
> Somewhere you should state that the protocol exchange typically involves the client closing the connection, and that the server closes only under exceptions.

	Ok.  I'll do that.
> It's probably sufficient to replace "requestor" with "client" to be consistent.

	Requestor is the entity sending in the DHCPv4 Bulk Leasequery.
	Client is the entity that has a DHCPv4 address and whose
	information shows up in the data part of the DHCPv4 Bulk
	Leasequery requests.  Client would not be consistent.

> However, this section then supercedes the description in 7.8 and 8.5 above - i.e., you are handling exceptions on the client side as well.

	I will enhance section 7.8 to indicate that requestors
	have to handle exception conditions and their intended
	actions.
> 
> I.e., 7.8 needs to include the exception cases listed in 7.3, or they should just be moved there.

	Yes.
> FWIW, again this contradicts 7.8 which says the client SHOULD close after the response is received if it has no more queries to send.

	The rationale is that you might know from information not
	part of this document that you had more queries to send
	soon, even though you don't have them now.
> This says "MAY" leave open. That's not the complement to SHOULD close.

	We don't really care if you keep it open or not.  Really.
	If you think that you will be happier, keep it open.  If
	you think it is simpler to close it (as I do), then close
	it.  Different people (different authors even!) have different
	ideas about how they would structure the code for this.  That's
	ok.  The point about all of this open/closed/multiple-operations
	stuff it to leave it up to the implementor.  Period.  We are
	not trying to tell them exactly how to implement this.   We
	are trying to focus on the protocol aspects, and leave understood.

> Hmm. I would think that this information would be passed up to the application.

	It might, but we don't care.  Do you think we should?
	If the connection is gone, it is gone.  I don't think
	I care which syscall caused it.
> OK. I don't understand how it's being used, but if it's consistent with the rest of DHCP, that's fine.
> 
> There are appropriate addresses to use as examples in RFCs - see RFC 5737, and please change this example accordingly.

	I will replace the reference to 10.x.x.x with a reference
	to RFC 1918 addresses.  Which is the point that I was trying
	to make, not about some example address.
> That'd be very useful to explain this way. Is this typical for DHCP? It's quite confusing IMO.

	DHCP times are traditionally in duration from "now", to not have
	to deal with clock skew issues (other than ongoing drift/skew).

	We introduced the base-time to work with that, and we kept
	the query times in absolute time.  I'll add words to explain
	that.
> The length should be "indicated in 1 octet". I'm just suggesting a change to the way it's described. When you say "the length is an octet", that is ambiguous and can mean that the length value is 1, not just that this value is stored in one octet.

	Ok, I'll fix that.
> Using the failover case as a justification would be helpful.

	Failover isn't an IETF standard, and so we try to step
	carefully around it possible existence.  I don't think
	I could get this document through back through the DHC WG
	if I mentioned failover, so I don't think this is going
	to work.
> I would argue that this then irrelevant, and there should be no statement about a skew of zero being preferred, since it could drive implementations that way unnecessarily.

	I believe that the other reason we like zero skew is 
	that it tends to expose fewer bugs in people's code,
	so keeping the admonishment that it is a better 
	answer seems to add some value.
> Actually, yes, except as examples in the intro/motivation. Elsewhere they are IMO distracting.

	DSLAM, concentrator, and access concentrator appear only
	in Section 3, Design Goals -- which is precisely the intro/motivation
	for this document.  They don't appear (at least to my text search
	engine) elsewhere.  So I think we have done what you want.
> The examples should focus on client/server/relay terminology. If other example terms are used, they should be parenthetical examples:
> 
> The point is that this is relevant without the concentrator. A concentrator is just one current example of where a relay exists, not the only one.

	True, and I will say that.   There was too much discussion
	of these examples to remove them, but while they are
	important to the process of getting through the DHC WG
	review, they are not of significant importance technically.

	So, I will add a sentence discussing the fact that a 
	concentrator is just an example.
> OK - it'd be useful to be clear on that in sec 3.2.

	I will say that in Section 3.2.
> Per-IP validation of that sort of permission isn't a fast-path decision. Fast-path involves forwarding and policy decisions (which are not typically /32 decisions).
> 
> It would be useful to say this information is useful so such routers can make the appropriate decision, but the path (fast or slow) is irrelevant IMO.

        Yes, fast-path is a forwarding issue, and I believe
	the intent of this section was to mention that the
	information returned by Leasequery is useful when
	deciding to forward a packet -- and that Bulk Leasequery
	gives you the information you need to decide to forward
	or not in advance of seeing the packet (when it is too
	late to deal with it in the fast path).

	I am not convinced that this should be changed.

	Regards -- Kim

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 23 Feb 2012 17:28:07 -0500

> 	are trying to focus on the protocol aspects, and leave understood.

That's not what SHOULD means.  An RFC2119 SHOULD is very strong; if the
spec doesn't care what an implementation does, don't use SHOULD.

-- Jeff

---

From: Joe Touch <[email-masked]>
Date: Fri, 24 Feb 2012 16:08:33 -0800

Hi, Kim,

> On Feb 17, 2012, at 5:47 PM, Joe Touch wrote:

Thanks for the clarification.

> 	  queries until all replies for the existing query are

That's awkward. I know you intend this to mean "replies to new queries 
MUST NOT block on the current response", but it also reads as implying 
"the server MUST not block on the current response, but can block after 
that".

Perhaps "the server MUST NOT allow any one response to block other 
pending responses; where multiple responses are pending, they MUST be 
interleaved (round-robin per-request? round-robin weighted by response 
length? other?)."

> chance of anyone using it.

IMO, that's an insufficient reason; the Internet is rife with protocols 
that nobody would look at - until they did ;-)

> ...In practice this protocol is useful
> network.

Either:
	a) if this is true, then the protocol needs a mechanism
	to *enforce* its use *only* in this sort of environment
or
	b) IMO, it *will* be used elsewhere, and such use should
	be anticipated in its design

I favor the latter approach, but either one is a path forward.

Joe

>... Encrypting everything would be quite expensive; the

---

From: Joe Touch <[email-masked]>
Date: Fri, 24 Feb 2012 16:28:39 -0800

Hi, Kim,

On 2/23/2012 2:00 PM, Kim Kinnear wrote:
> 	implementation in my view.

While I agree, were that true then the doc would not have *any* advice 
on what to do in these cases. I'm suggesting that the advice should be 
consistent. Omitting it all would be fine too.

>       I can certainly imagine that

That works.

> 	is probably better language.  I'll change it.

AOK. "Cleared" could mean that there is no longer a timer running.

> 	timer, you can still say that you implement this

IMO, you're using SHOULD above in non-2119 ways. SHOULD implies there's 
a significant issue with either the protocol or implementation that has 
exceptions. You're just saying "implementations will save resources by 
using a timer and conserving the open connections". IMO, if that's the 
goal, then it'd be preferable to make the recommendation that way, 
rather than using 2119 language.

> 	that without causing you to wonder if you really support

Again, this is good reason to reword the timer issue as "try to conserve 
connections; try to reuse them for multiple requests from the same 
relay, and try to close them as soon as all pending queries are 
complete; the method for doing so is left to the implementer".

Otherwise IMO you'll have people deriving correctness from whether the 
connection stays open or not.

> 	Requestor is the entity sending in the DHCPv4 Bulk Leasequery.

Then you mean relay?

> 	Leasequery requests.  Client would not be consistent.

AOK. (see above; then use "relay" here).

AOK.

> 	soon, even though you don't have them now.

See discussion above about rewording this all to "conserve resources 
where possible", rather than making specific recommendations as to how 
to do so.

> 	are trying to focus on the protocol aspects, and leave understood.

Yet further rationale to reword as above.

> 	I care which syscall caused it

I think that this info should be passed up to the app, as per RFC 1122.

I do think that apps would do different things - log the error 
differently at least, or retry in some cases but not others.

AOK.

AOK.

> 	if I mentioned failover, so I don't think this is going

FWIW, I don't think that creating this level of detail about state 
feedback achieves the goal; it codifies support for a non-standard 
mechanism.

IMO, that issue deserves some light, not a shadowy corner. I'll leave it 
to the WG to decide, though - this isn't a transport issue.

> 	answer seems to add some value.

That's a good reason to avoid the admonishment, IMO. If the code breaks, 
it should break early and often. "Expecting" a particular skew 
encourages bad programming IMO.

> 	engine) elsewhere.  So I think we have done what you want.

Design goals is Sec 3; the intro is Sec 1. I'm saying using this 
terminology in the intro (sec 1) is fine, but in the design goals (sec 
3) is distracting.

AOK.

> 	I will say that in Section 3.2.

AOK

> 	late to deal with it in the fast path).

The issue is that fast-path contrasts to slow-path. Filtering is always 
fast-path where supported in the hardware, and slow-path where not.

The point of the bulk leasequery is to allow forwarders to filter. 
*where* they filter is irrelevant, and not made slower or faster solely 
by whether the bulk leasequery is there. "fast path" isn't relevant to 
the issue.

---

From: Joe Touch <[email-masked]>
Date: Fri, 24 Feb 2012 16:32:57 -0800

Hi, Ralph,

On 2/18/2012 4:39 AM, Ralph Droms wrote:
>> Agreed. FWIW, my "bar" for that is whether implementing DHCPv4 as
>> per RFC 2131 is changed by this doc. If DHCP fundamentally starts
>> requiring TCP port support, then this doc then changes the spec as
>> described in 2131 IMO.
>
> Joe - I don't see that this document fundamentally requires TCP port
> support for DHCP operation as described in RFC 2131. This document
> describes a protocol that is closely related to but independent of RFC
> 2131, and a server based on RFC 2131 can perform all the DHCP functions
> in RFC 2131 without considering this document. So, I can see your point
> but I disagree that this document updates RFC 2131.

Fair enough, but then I'll put on my IANA hat and note that this then is
no longer the complementary TCP protocol to DHCP. By your argument, it's
a new service, and should have a separate TCP port and service name.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 24 Feb 2012 16:39:56 -0800

Hi, Ted,

On 2/18/2012 7:29 AM, Ted Lemon wrote:
> The idea of doing DHCP stateful autoconfiguration over TCP is
> nonsensical: DHCP clients start out with no IP address, so it is not
> possible for them to do TCP.

That's true for the initial request, but not for lease renewal.

> The reason for sharing option codes is to avoid confusion: since
> existing DHCPLEASEQUERY option codes come out of the same namespace as
> DHCP options,

Which doesn't need to happen if this is a completely different service...

> if we were to propose that options in this documentation
> come out of a different namespace, we would have to declare that new
> namespace, which would have some options and option codes in common with
> the existing namespace. This doesn't add value.

It avoids misrepresenting this as related.

> Historically, we have never said that when an option code is added, that
> updates RFC2131 (really, it would make more sense to say it updated
> RFC2132 if we were to go there, since RFC2132 is the document that
> describes DHCP options).

Fair enough - 2132.

> So it would be surprising and unconventional if
> this document were said to update either RFC2131 or RFC2132 simply
> because it defined one or more new option codes.

OK, so although I disagree that this is the correct procedure, if it's 
typical for DHCP then that's reasonable.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Sat, 25 Feb 2012 03:35:04 +0000

On Feb 24, 2012, at 7:39 PM, Joe Touch <[email-masked]<mailto:[email-masked]>> wrote:
OK, so although I disagree that this is the correct procedure, if it's typical for DHCP then that's reasonable.

So just to be clear here, it seems that you are withdrawing your request that we create a new IANA registry and to say that this document updates RFC2131 or RFC2132, right?

---

From: Joe Touch <[email-masked]>
Date: Fri, 24 Feb 2012 22:00:53 -0800

On 2/24/2012 7:35 PM, Ted Lemon wrote:
> So just to be clear here, it seems that you are withdrawing your request
> that we create a new IANA registry and to say that this document updates
> RFC2131 or RFC2132, right?

I made an observation and a suggestion about those issues. They are not 
transport issues, so I consider them individual position only, and defer 
to the WG on how to proceed.

Joe