RE: Last Call: <draft-wu-l3sm-rfc8049bis-04.txt> (YANG Data Model for L3VPN Service Delivery) to Proposed Standard

"Adrian Farrel" <adrian@olddog.co.uk> Thu, 19 October 2017 21:18 UTC

Return-Path: <adrian@olddog.co.uk>
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 7FEFF1342D6 for <ietf@ietfa.amsl.com>; Thu, 19 Oct 2017 14:18:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
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 mJlzXWh5JoE5 for <ietf@ietfa.amsl.com>; Thu, 19 Oct 2017 14:18:35 -0700 (PDT)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F9BD132CE7 for <ietf@ietf.org>; Thu, 19 Oct 2017 14:18:34 -0700 (PDT)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v9JLIVQf023384; Thu, 19 Oct 2017 22:18:32 +0100
Received: from 950129200 (105.76.115.87.dyn.plus.net [87.115.76.105]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v9JLIUuJ023376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Oct 2017 22:18:31 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Randy Presuhn' <randy_presuhn@alumni.stanford.edu>, 'IETF Mailing List' <ietf@ietf.org>
References: <150531137507.30405.6179845967838123305.idtracker@ietfa.amsl.com> <3d65a756-fe9b-19de-fd94-40f4618d729b@cisco.com> <c6efd2ae-5f5d-1699-89fe-0d2f28b71cdb@alumni.stanford.edu> <46f1be77-03ab-61b7-b64c-aa05739d0985@cisco.com> <49df01e3-fd3e-4dd6-d9b9-f39c45985f9a@alumni.stanford.edu>
In-Reply-To: <49df01e3-fd3e-4dd6-d9b9-f39c45985f9a@alumni.stanford.edu>
Subject: RE: Last Call: <draft-wu-l3sm-rfc8049bis-04.txt> (YANG Data Model for L3VPN Service Delivery) to Proposed Standard
Date: Thu, 19 Oct 2017 22:18:26 +0100
Message-ID: <02cc01d3491f$cdead750$69c085f0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQG4Hkqaj8O4I9Lkb56MnmyzByFPBQKjVJkOAW8H8xYCgfpdFQIn2GIkotwfOTA=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23406.003
X-TM-AS-Result: No--18.911-10.0-31-10
X-imss-scan-details: No--18.911-10.0-31-10
X-TMASE-MatchedRID: gzVbiXtWD9tfsB4HYR80ZggKAWhuC2ojb6bRSg4rpzshvFjBsLEZNNWn xkl6EP77JHKdWMcAL6zfrd9voQGByXMNAEm7TgJattAWxuM5sl6+1Vx7rDn4rxxUkJPe1WBq4Hw 516InYmoklruqFH0P8ltn3RgiTQk0XoZZdCbQG2EuLk8NfSpYekGtrAxy5ENO2oLGTNKlb9cFd1 iUNHCH3rTc/MrZqG8w3PjutuJYeLagOjV7cDlnVfHkpkyUphL9Ud7Bjfo+5jQ2KlZKA26Mke3Uy RVe0P6o7+ykLzh4xSgPwNHPMArzOVK0cGugJ8GukRs1fAcYNHGMs7LXcKBvj/HSsb509cZ3aUXs 6FguVy2OUCZ1nQPqAXgSjgfHMfh/dYq+JDDD9d6iI3xhOar5y7/I3arxTrviZRtAsE9GXyQRE7n Tx2i6XVD3U31Zcw/LGTTyAO0CdS6i/tFCJuYlIa91/YHX0i1l0w14HFJQjaO7+NPPxj+R6ggwT+ O9hx+i585VzGMOFzABi3kqJOK62QtuKBGekqUpPjKoPgsq7cA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/D5TbqnXtIXJAdCrB8DMAX6ze9U0>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 19 Oct 2017 21:18:37 -0000

You make a good point Randy, but I wonder where it takes us.

As you note, it has always been the case that people could make implementations that claim to be conformant to a spec, but which are not. Whether the divergences are deliberate (to make vendor-specific variants, or to fix specification bugs) or accidental (implementation bugs) doesn't change the fact. The same is true of whether the variance is done in good or bad faith.

We cannot (even using Warren's Internet Police badge) stop any of that from happening.

What we can do is keep our specification heritage clean. That means that if an implementation is truly conformant to the specification it claims to conform to, then there must be no "on the wire" confusion with an implementation that is truly conformant to another of our specifications.

That argument would go your way if it was possible to have a functional implementation of 8049. But sadly it isn't. Any implementation claiming conformance with 8049 (whether in good faith or not) is not actually conformant.

Adrian


> -----Original Message-----
> From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Randy Presuhn
> Sent: 19 October 2017 21:24
> To: IETF Mailing List
> Subject: Re: Last Call: <draft-wu-l3sm-rfc8049bis-04.txt> (YANG Data Model for
> L3VPN Service Delivery) to Proposed Standard
> 
> Hi -
> 
> On 10/19/2017 3:46 AM, Benoit Claise wrote:
> > Hi Randy,
> >> Hi -
> >>
> >> On 10/13/2017 11:55 PM, Benoit Claise wrote:
> >> ...
> >>> Since RFC8049 is not implementable and therefore not implemented,
> >>
> >> That's rather a leap of faith.  The fact that spec is badly broken
> >> and probably should not have been published in the first place isn't
> >> of itself going to stop someone from using it as the basis for an
> >> implementation of *something*.
> > Quoting Jan Lindblad, as YANG doctor:
> > "The 8049 YANG model had broken XPATH expressions, so a compliant
> > implementation was impossible."
> 
> The infeasibility of "compliant" implementation does not preclude
> good-faith implementations of *something* using that module name.
> We've seen that happen with other "broken" RFCs in the SNMP world, and
> I see no reason why things will be any different in the YANG world.
> 
> If the WG is truly confident that no one had any intention of
> implementing RFC 8049 (how else could it have been published without
> the error being discovered?) and it has seen no uptake since
> publication, then I agree it's a non-issue, though one might
> wonder why the work was undertaken in the first place.
> 
> Randy