Re: [dhcwg] Alvaro Retana's Discuss on draft-ietf-dhc-dynamic-shared-v4allocation-07: (with DISCUSS)

Ted Lemon <Ted.Lemon@nominum.com> Thu, 28 May 2015 03:44 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8FF1A1BB0; Wed, 27 May 2015 20:44:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 mr2eWufMaHa7; Wed, 27 May 2015 20:44:58 -0700 (PDT)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F7FA1A1BA7; Wed, 27 May 2015 20:44:58 -0700 (PDT)
Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 3E2DDDA0085; Thu, 28 May 2015 03:44:58 +0000 (UTC)
Received: from mbx-03.WIN.NOMINUM.COM ([169.254.4.52]) by CAS-04.WIN.NOMINUM.COM ([64.89.235.67]) with mapi id 14.03.0224.002; Wed, 27 May 2015 20:44:58 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Qi Sun <sunqi.csnet.thu@gmail.com>, Alvaro Retana <aretana@cisco.com>
Thread-Topic: [dhcwg] Alvaro Retana's Discuss on draft-ietf-dhc-dynamic-shared-v4allocation-07: (with DISCUSS)
Thread-Index: AQHQmPYFxTJ0B4xBYEeC1Q8Q6yfa1Z2QvZ3M
Date: Thu, 28 May 2015 03:44:57 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B6307979CE9F4@mbx-03.WIN.NOMINUM.COM>
References: <20150528024746.13386.20261.idtracker@ietfa.amsl.com>, <AD3660D9-330B-45A0-9B39-C8C6DEDB31AA@gmail.com>
In-Reply-To: <AD3660D9-330B-45A0-9B39-C8C6DEDB31AA@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [71.233.43.215]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/CQSkiBBTparGqxTYK26eNduLAV0>
Cc: "draft-ietf-dhc-dynamic-shared-v4allocation.ad@ietf.org" <draft-ietf-dhc-dynamic-shared-v4allocation.ad@ietf.org>, "Bernie Volz (volz)" <volz@cisco.com>, "dhc-chairs@ietf.org" <dhc-chairs@ietf.org>, "draft-ietf-dhc-dynamic-shared-v4allocation@ietf.org" <draft-ietf-dhc-dynamic-shared-v4allocation@ietf.org>, The IESG <iesg@ietf.org>, "dhcwg@ietf.org WG" <dhcwg@ietf.org>, "draft-ietf-dhc-dynamic-shared-v4allocation.shepherd@ietf.org" <draft-ietf-dhc-dynamic-shared-v4allocation.shepherd@ietf.org>
Subject: Re: [dhcwg] Alvaro Retana's Discuss on draft-ietf-dhc-dynamic-shared-v4allocation-07: (with DISCUSS)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 28 May 2015 03:44:59 -0000

On May 28, 2015, at 10:47 AM, Alvaro Retana <aretana@cisco.com> wrote:
> Section 2 (Applicability Statement) says that “this extension is only
> suitable for specific architectures based on the Address plus Port model
> (A+P) [RFC6346]”, which I take to mean that the components of the
> solution in RFC6346 must be present (PRR, for example).  In fact, if the
> functionality described in RFC6346 is not present, then the forwarding
> won’t work as standard destination-based protocols may not deliver the
> packets to the right place.  I think that RFC6346 should be a Normative
> Reference, which then results in a DOWNREF to an Experimental RFC.
>
> IOW, if the functionality in RFC6346 is needed (which I think it is),
> then the status of this document should not be Standards Track.

Actually, the text you quote does not say that this extension is only suitable for use with RFC 6346, but rather that it is only suitable for use with architectures _based_ on 6346.   Several of these have been defined, and were approved by the IETF on the standards track, and indeed the first two normative references in this document refer to two such documents.   So I don't think you've identified a problem, unless I'm missing something here.   As a general rule what it means for something to be a normative reference is that you couldn't implement the document making the reference without reading the normative reference.   That would clearly not be the case for RFC 6346 with respect to the shared-v4allocation draft.

That said, it might be cleaner for this text to refer to the lw4over6 and map-t documents; I think the reason it does is to leave the door open for other documents based on 6346 other than those two.   However, I really don't think that this change is DISCUSS-worthy!   :)