[dhcwg] Comments on draft-ren-dhc-problem-statement-of-mredhcpv6-00

"Bernie Volz (volz)" <volz@cisco.com> Tue, 22 May 2018 15:19 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABD812711D; Tue, 22 May 2018 08:19:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level:
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrI7VNmWXcJH; Tue, 22 May 2018 08:19:23 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4864D1272E1; Tue, 22 May 2018 08:19:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15373; q=dns/txt; s=iport; t=1527002363; x=1528211963; h=from:to:subject:date:message-id:mime-version; bh=lJQKHxp5zMtEAr4tCIELXr+fdJsU0nFSwjaPMxmR1ZY=; b=cLH1TANAnJhADcf9EgEascwPGukTGieK3EGXDhTTimiQQR88M5sWn4nm R7u6U+KF0k6DJ6uXim7bB2nZCHHgBw625ZhRbCZV8XqnUVLEPhHvqGaq4 cJiNmukF9wZhKNnvWHjO/2s5CJ0CuAarBh7su7uJCAtuorhwkW4fcjPrR o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C2AACfMwRb/4wNJK1dGQEBAQEBAQEBAQEBAQcBAQEBAYJNdmJ9MotvjHeDCI4/hHcUgWQLIwmGZiE0GAECAQEBAQEBAmwcDIVcXgGBACYBBAEagxyBG2QPq1OIRoIKBYg1ghOBD4doAoVqAowhjC4JAoE3jRaNBpBTAhETAYEkARw4gVJwFRqCZYIaiHWFPoIEjDEBgRcBAQ
X-IronPort-AV: E=Sophos;i="5.49,430,1520899200"; d="scan'208,217";a="118257411"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 May 2018 15:19:22 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id w4MFJMWw012080 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 22 May 2018 15:19:22 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 22 May 2018 10:19:21 -0500
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1320.000; Tue, 22 May 2018 10:19:21 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "dhcwg@ietf.org" <dhcwg@ietf.org>, "draft-ren-dhc-problem-statement-of-mredhcpv6@ietf.org" <draft-ren-dhc-problem-statement-of-mredhcpv6@ietf.org>
Thread-Topic: Comments on draft-ren-dhc-problem-statement-of-mredhcpv6-00
Thread-Index: AdPx3p/dekENYGZ8RdGAMxc7JeiGyQ==
Date: Tue, 22 May 2018 15:19:21 +0000
Message-ID: <77faa53f1e9d4b92b5d1c26055c5ef83@XCH-ALN-003.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.67.114]
Content-Type: multipart/alternative; boundary="_000_77faa53f1e9d4b92b5d1c26055c5ef83XCHALN003ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/pbUzQ-zjWFwDrNsfKs6p_28JrqY>
Subject: [dhcwg] Comments on draft-ren-dhc-problem-statement-of-mredhcpv6-00
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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>
X-List-Received-Date: Tue, 22 May 2018 15:19:26 -0000

I reviewed this individual submission draft and have some comments (as a WG member, hat off as DHC WG co-chair).

This draft is basically is a summary of what processing in DHCPv6 [servers] might want to be customizable (and how that might be done using CPNR and KEA extensions).

The title (and name of draft) are a bit odd given that it is much more generic overview and doesn't really address any specific "problem statement"?

I do have a bunch of nits (mostly because non-native English speaker issues), but I think we can forgo those for now.

The issues I found are:


  1.  There are multiple references to secure-dhcpv6 and this document is dead. I think this need to be removed as there are no plans by the WG to continue work on that document.
  2.  There is RFC2119 reference in the terminology section but I don't believe it is needed/used.
  3.  In several places "user" [requirements] is mentioned, but I think this likely should be "administrator"?
  4.  In section 3.1 for "Extended Options", the number of RFCs referenced should be reduced as everyone will get the point. Perhaps a reference to the options on the IANA page (https://www.iana.org/assignments/dhcpv6-parameters) should be used if you want to provide an indication of the number of options?
  5.  Section 4.2.2, while technically correct (all DHCPv6 options are standardized), there is a need to mention that the reason for this is that we have Vendor Option (17) that are supposed to be used for "private" purposes. This is a major hole in the work.
  6.  It would be better to reference 3315bis instead of 3315 (especially in section 5, Security Considerations). And again, in Section 5 is mention of secure dhcpv6 (sedhcpv6) which needs to be removed.
  7.  The intended status (Standards Track) is wrong; I think this is Informational.
  8.  Abstract states "and provides the possible directions to solve the problems" but I don't really see anything in the document that covers this (perhaps section 4.2.5 was to provide this)?

It isn't completely clear whether this draft is "needed". Certainly if it is Informational it doesn't hurt (and perhaps other DHCP server vendors will want to provide information to expand on what "extensions" different servers provided). But, again, I'm not sure that this information is important to highlight and might be left to the server vendor documentation?


-          Bernie