Re: TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery
Joe Touch <touch@isi.edu> Mon, 13 February 2012 22:16 UTC
Return-Path: <touch@isi.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E1821E8012; Mon, 13 Feb 2012 14:16:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.963
X-Spam-Level:
X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SeVSuJxW9t0; Mon, 13 Feb 2012 14:16:31 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3CA21E8044; Mon, 13 Feb 2012 14:16:31 -0800 (PST)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q1DMG4GT010816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 13 Feb 2012 14:16:04 -0800 (PST)
Message-ID: <4F398BA4.3010400@isi.edu>
Date: Mon, 13 Feb 2012 14:16:04 -0800
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: draft-ietf-dhc-dhcpv4-bulk-leasequery@tools.ietf.org, "tsv-ads@tools.ietf.org" <tsv-ads@tools.ietf.org>, IETF discussion list <ietf@ietf.org>, dhcwg@ietf.org
Subject: Re: TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery
References: <4F3987F0.5050000@isi.edu>
In-Reply-To: <4F3987F0.5050000@isi.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: TSV Dir <tsv-dir@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Feb 2012 22:16:32 -0000
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 On 2/13/2012 2: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 > tsv-dir@ietf.org 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 > > ---- > > >
- TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-lease… Joe Touch
- Re: TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-l… Joe Touch
- Re: TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-l… Joe Touch
- Re: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv… Joe Touch
- Re: TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-l… Ralph Droms
- Re: TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-l… Kim Kinnear
- Re: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv… Kim Kinnear
- Re: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv… Ted Lemon
- Re: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv… Jeffrey Hutzelman
- Re: TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-l… Kim Kinnear
- Re: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv… Kim Kinnear
- Re: TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-l… Joe Touch
- Re: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv… Joe Touch
- Re: TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-l… Joe Touch
- Re: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv… Joe Touch
- Re: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv… Joe Touch
- Re: [dhcwg] TSVDIR review of draft-ietf-dhc-dhcpv… Ted Lemon