IETF Logo Mail Archive

Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07

otroan@employees.org Tue, 07 March 2017 21:42 UTC

Return-Path: <otroan@employees.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACB91294D6 for <ipv6@ietfa.amsl.com>; Tue, 7 Mar 2017 13:42:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org
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 Q1ULUuOt-GCz for <ipv6@ietfa.amsl.com>; Tue, 7 Mar 2017 13:41:59 -0800 (PST)
Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id D22E21204D9 for <ipv6@ietf.org>; Tue, 7 Mar 2017 13:41:59 -0800 (PST)
Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 07 Mar 2017 21:41:59 +0000
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 8235ED788D; Tue, 7 Mar 2017 13:41:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=qwqkyPXxKGPiFYTC0G+wx0xesrk=; b= U5e3HIMZ08StrXRUpiS5yQKktX3R84tkA+iZZzKMquX+9tyD0isorIHrE3u0vRbJ KX3UEdG5xMiV+N0VsArGjmUzlIuNQCU/t0ZMCqDzEsIlnXceN0wpB0r9JSH0v5fy jtSy7gaR8Cexw8bqEAil6vLcgJZAHTR1Qix3vCvPE7k=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=X8xBE2W7UjjyKthPAZdpJPp NhnKXvRPw5q0S80a6hJrBE5M5k2v7cQh1wnoSUP1RJjbBrnPBoetMVcL10SAVgZS Utdk4AmXfwd4kRfQJ93HSMpPKJhqejdNvXKKAzoLHAkIdyHKkGSNZCIc8Y1gHouk it2MyN2JIDyjeeCltIzE=
Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 0D7D1D788A; Tue, 7 Mar 2017 13:41:59 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 48148977D8DC; Tue, 7 Mar 2017 22:41:56 +0100 (CET)
From: otroan@employees.org
Message-Id: <36251EE1-309C-44B5-BEAE-591889492547@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_E60C85FE-301D-4898-9F58-B9BDC9FA8233"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07
Date: Tue, 07 Mar 2017 22:41:55 +0100
In-Reply-To: <ED8E5513-A522-4D37-A0A2-0960CF3E5394@google.com>
To: james woodyatt <jhw@google.com>
References: <CAN-Dau17q_BrUuzfvB1mLDt6p5UxYikphWaHpa8VQ2L-3kx-DA@mail.gmail.com> <a484b60f9d9b4fcea24dc320c550da2c@XCH15-06-11.nw.nos.boeing.com> <ee764408573b4db4b22e58c4ea5f289c@XCH15-06-11.nw.nos.boeing.com> <2c0ab33b-abbe-caf1-6147-0c583d7f5d61@gmail.com> <CAN-Dau0bSPiubeDOFeJAg6H0wP0ZNDS514eedmJtkOqHTXWOOw@mail.gmail.com> <D6D5B476-7F21-4F49-A81D-C2A11C30ADEC@google.com> <453e5b4160514907bc1bb822770e0cac@XCH15-06-11.nw.nos.boeing.com> <ABE47051-FBFC-460F-89B0-FFD451410F7B@google.com> <m1cjviu-0000EYC@stereo.hq.phicoh.net> <5BC57F0E-50FD-4452-853F-A08291C91EB1@google.com> <m1ck5mu-0000GaC@stereo.hq.phicoh.net> <5B4AFF50-8CA9-4134-8CE2-A383DB5F8BF5@google.com> <m1ckxfo-0000IMC@stereo.hq.phicoh.net> <225F639E-27C1-4408-BC2B-26500929049B@google.com> <CAOSSMjUR203+hYFBrFBrj9Xkjux3o7fYNd4y9kNyxwpLxF11ew@mail.gmail.com> <6D825351-7F43-4540-89AB-48DC2B5E92E3@google.com> <CAOSSMjUP6m-L1iNhE=BxHW+7hvt4YsZgxxtVn+qmgEVS9HeStA@mail.gmail.com> <3EC22050-D159-488D-A354-E46F04764E25@google.com> <CAOSSMjW_fPz3RdPyK=e-EyvyW4GawFAr3zcGLkBzDcR8Ws2MUw@mail.gmail.com> <90292C5E-013D-4B7C-B496-8A88C7285CD7@google.com> <CAOSSMjXf1ah6nrAorf+mpnOxXBpHg6difgCo4mQ6rPVZoU8CSw@mail.gmail.com> <7FAD8D2B-B50E-44C5-AAA3-0C91621D9D54@google.com> <CAOSSMjX4Rq969cTuAU+sqWmW7Rh2-nxjd1vpSkeAevVZTed1HA@mail.gmail.com> <ED8E5513-A522-4D37-A0A2-0960CF3E5394@google.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/l7Ou3H1xCQJjHNwchr1ZqaI4_84>
Cc: 6man WG <ipv6@ietf.org>, 神明達哉 <jinmei@wide.ad.jp>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Mar 2017 21:42:01 -0000

> On 7 Mar 2017, at 22:22, james woodyatt <jhw@google.com> wrote:
> 
> In summary, there is a deficit of RFC 2119 keyword language here, and we have to make the case that the standards texts make a sufficiently strong implicit case rather than an explicit normative requirement.
> 
> As explained above, it sure looks to me like a very fair reading of the implicit requirements language is that LwIP is within the limits of RFC 4291, RFC 4861 and RFC 4862 when it choose the option of ignoring PIO elements with invalid prefix length for IID on the underlying link type.
> 
> Yes, the USGv6 and IPv6 Ready Logo tests are well within their rights to apply additional requirements beyond the IETF standards, but it seems like a strict interpretation of the standards allow for LwIP to claim conformance.
> 
> How can we counter this argument?

We're not writing law, we're specifying what it takes to have implementations of a specification interoperate.

That implementation would fail to interoperate.

Cheers,
Ole

v2.23.0 | Report a Bug | By Email