[dhcwg] [dhc] #14: Response to WG last call on draft-ietf-dhc-subnet-alloc
"dhc issue tracker" <trac@tools.ietf.org> Tue, 07 October 2008 19:26 UTC
Return-Path: <dhcwg-bounces@ietf.org>
X-Original-To: dhcwg-archive@megatron.ietf.org
Delivered-To: ietfarch-dhcwg-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F308A3A6A97; Tue, 7 Oct 2008 12:26:32 -0700 (PDT)
X-Original-To: dhcwg@core3.amsl.com
Delivered-To: dhcwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96C0C3A6A89 for <dhcwg@core3.amsl.com>; Tue, 7 Oct 2008 12:26:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BAgX4KPRWpe for <dhcwg@core3.amsl.com>; Tue, 7 Oct 2008 12:26:30 -0700 (PDT)
Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [194.146.105.14]) by core3.amsl.com (Postfix) with ESMTP id 3D2743A6A1E for <dhcwg@ietf.org>; Tue, 7 Oct 2008 12:26:30 -0700 (PDT)
Received: from localhost ([127.0.0.1]:53798 helo=merlot.tools.ietf.org) by merlot.tools.ietf.org with esmtp (Exim 4.69) (envelope-from <trac@tools.ietf.org>) id 1KnIBz-00086k-RC; Tue, 07 Oct 2008 21:25:59 +0200
MIME-Version: 1.0
From: dhc issue tracker <trac@tools.ietf.org>
X-Trac-Version: 0.11.1
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.1, by Edgewall Software
To: rdroms@cisco.com
X-Trac-Project: dhc
Date: Tue, 07 Oct 2008 19:25:59 -0000
X-URL: http://tools.ietf.org/wg/dhc/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dhc/trac/ticket/14
Message-ID: <057.ba22aec0b929c1999210ae210cb1ccdf@tools.ietf.org>
X-Trac-Ticket-ID: 14
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: rdroms@cisco.com, dhcwg@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false
Cc: dhcwg@ietf.org
Subject: [dhcwg] [dhc] #14: Response to WG last call on draft-ietf-dhc-subnet-alloc
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.9
Reply-To: dhcwg@ietf.org
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
#14: Response to WG last call on draft-ietf-dhc-subnet-alloc ------------------------------+--------------------------------------------- Reporter: rdroms@cisco.com | Owner: Bernie Volz Type: defect | Status: new Priority: major | Milestone: Component: subnet-alloc | Version: Severity: In WG Last Call | Keywords: ------------------------------+--------------------------------------------- I support this document moving forward, but (oh what a surprise?) I have some nits: - All of the option drawings need to indent the bits count lines by 1: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Len | Flags | Suboptions ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Should be: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Len | Flags | Suboptions ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - In section 3 (and actually all option format sections), I think the text about the (sub) option length excluding the code and len fields is unncessary as that is the norm for DHCP options. It may also be worth identifying the length of the options (minimum or fixed). For example, section 3.1's suboption always has a length of 2? For the section 3 flags field, shouldn't it specify that unused flag bits must be zero (in this case, the entire field MUST be 0). - In section 3.1 (other than the len issue mentioned above), the text uses "P" whereas the suboption diagram and field definitions use "Prefix". There are multiple references to P or "P" field. Also, as there can be multiple instances of this suboption, I think there should be a caution that instances of this suboption MUST NOT be concentated. I don't think the RFC 3396 applies to suboptions, but it can't hurt to make this very clear. For the case where the "i" flag is "1", can this only be used in DHCPDISCOVER? And, in that case, I think there is only a DHCPOFFER response (no subsequence DHCPREQUEST/DHCPACK sequence would follow). Perhaps that should be stated? Or, did I misunderstand this? - In section 3.2.1, as all flags have descriptions for what the "set" ('1') and "clear" ('0') values, shouldn't that be the case for the 'd' flag? - In section 4.2, 1st paragraph: including the Subnet-Information suboption in order to specify the subnet(s) which it is willing to allocate to the Client in order to fill the request(s). Should "fill" be "fulfill"? - In section 5.1, 2nd paragraph, it uses "w.r.t."? Why not just say "as described above in the Subnet-Information suboption format section (3.2)"? In the 3rd paragraph, "Ususable" is used ... This should be "Unusable". - In section 5.4, I think "This message effectively immediately times out the Client's lease(s) for the allocated subnet(s)." is not really correct. The DHCPFORCERENEW is supposed to cause the client to renew, but it can't "time out the lease(s)". That may be the RESULT of the DHCPREQUEST to renew the leases, but the DHCPFORCERENEW does not cause that by itself. (And, in fact the 2nd paragraph makes that clear when describing the DHCPNAK that may be returned for the DHCPREQUEST). The examples in section 8 are nice - for complex option definitions (as this is), they are extremely useful. Again, I support this moving forward and none of the above are "major" issues - just nits to improve the document. - Bernie -- Ticket URL: <http://trac.tools.ietf.org/wg/dhc/trac/ticket/14> dhc <http://tools.ietf.org/wg/dhc/> _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] [dhc] #14: Response to WG last call on dr… dhc issue tracker
- Re: [dhcwg] [dhc] #14: Response to WG last call o… dhc issue tracker
- Re: [dhcwg] [dhc] #14: Response to WG last call o… dhc issue tracker
- Re: [dhcwg] [dhc] #14: Response to WG last call o… dhc issue tracker