Re: [yang-doctors] Review of draft-wu-l3sm-rfc8049bis?

Lou Berger <lberger@labn.net> Thu, 05 October 2017 14:35 UTC

Return-Path: <lberger@labn.net>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBFE61321B6; Thu, 5 Oct 2017 07:35:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.778
X-Spam-Level:
X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779] autolearn=no 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 1Aqv4wKH5nqK; Thu, 5 Oct 2017 07:35:20 -0700 (PDT)
Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6EFC126DFE; Thu, 5 Oct 2017 07:35:20 -0700 (PDT)
Received: from [::1] (port=58224) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from <lberger@labn.net>) id 1e07FA-0005iw-7i; Thu, 05 Oct 2017 18:35:20 +0400
To: adrian@olddog.co.uk, 'YANG Doctors' <yang-doctors@ietf.org>
Cc: draft-wu-l3sm-rfc8049bis.all@ietf.org
References: <262fdd36-5213-f716-016a-02442c427a0a@labn.net> <013c01d33ddf$1e2ad040$5a8070c0$@olddog.co.uk> <e7149805-4ea4-ee18-1295-d4b46c624a3c@labn.net> <014901d33de1$b3728880$1a579980$@olddog.co.uk>
From: Lou Berger <lberger@labn.net>
Message-ID: <83b06781-8710-c28d-7bea-973409c27b48@labn.net>
Date: Thu, 05 Oct 2017 10:35:18 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <014901d33de1$b3728880$1a579980$@olddog.co.uk>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com
X-Authenticated-Sender: newdragon.webhostserver.biz: lberger@blabn.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/Gp1Hnm_vzFUvg8BCvf5a2tQDJAI>
Subject: Re: [yang-doctors] Review of draft-wu-l3sm-rfc8049bis?
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Oct 2017 14:35:22 -0000


On 10/5/2017 9:56 AM, Adrian Farrel wrote:
>> Thanks for the background.  We have a somewhat similar situation going
>> on right now with rfc 8022 (been out a short time, no shipping
>> implementations, *but* update motivated by need to be updated to NMDA
>> compatible form).  In that case, we're headed down a path of deprecating
>> the old modules and issuing a replacement '-2' version.  Would it make
>> sense to do a similar thing here and just rename the module (to
>> ietf-l3vpn-svc-2) and thereby conform with YANGs compatibility requirement?
> I have no strong opinion either way.
>
> Given that 8049 can't be implemented, I'm not sure that the module it specifies actually exists at all.
>
> I'm really happy to be guided by anyone who does have a strong opinion.

I don't have a strong opinion, but am concerned about the precedent it
establishes WRT how we handle other incompatible module changes.  If we
open the door on this change, what was a hard rule becomes
subjective/open to interpretation...

Lou

>
> A
>
>