[RTG-DIR] RtgDir review: draft-wu-l3sm-rfc8049bis-07

Lou Berger <lberger@labn.net> Fri, 13 October 2017 13:51 UTC

Return-Path: <lberger@labn.net>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA903132CE7 for <rtg-dir@ietfa.amsl.com>; Fri, 13 Oct 2017 06:51:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level:
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 VTdizHlRnB_S for <rtg-dir@ietfa.amsl.com>; Fri, 13 Oct 2017 06:51:10 -0700 (PDT)
Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (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 861ED133053 for <rtg-dir@ietf.org>; Fri, 13 Oct 2017 06:51:10 -0700 (PDT)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id 57A231AB0B9 for <rtg-dir@ietf.org>; Fri, 13 Oct 2017 07:51:09 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id M1r51w00Z2SSUrH011r8r4; Fri, 13 Oct 2017 07:51:09 -0600
X-Authority-Analysis: v=2.2 cv=K4VSJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=02M-m0pO-4AA:10 a=48vgC7mUAAAA:8 a=P5jReJ_0Coog3EcWgxwA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:Cc:To:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=37OYZNm2/iJ5MqB6D8FzDynkA9oXUwwf+ybqCeRlmvg=; b=R4XvmgUM5XAP+Cy6J5Q2cwXOQ0 GFpDwidxl7PgLd0HEN1lJvS6jVTHgA162MkWMhcd01fsg1QNlxcvaEyDdMjZlQcKBd5SY0FaTGC+u LtjKF0FvPFq38nizdQFXjU2dx;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:60540 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <lberger@labn.net>) id 1e30Mj-001yNR-BX; Fri, 13 Oct 2017 07:51:05 -0600
To: "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Cc: rtg-dir@ietf.org, draft-wu-l3sm-rfc8049bis.all@ietf.org
From: Lou Berger <lberger@labn.net>
Message-ID: <28df7f72-e9c5-07b0-e615-344783c0750f@labn.net>
Date: Fri, 13 Oct 2017 09:51:04 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.86.101
X-Exim-ID: 1e30Mj-001yNR-BX
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:60540
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/RYpZtedtXl4VImISZe0u8iHJmww>
Subject: [RTG-DIR] RtgDir review: draft-wu-l3sm-rfc8049bis-07
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Oct 2017 13:51:13 -0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-wu-l3sm-rfc8049bis-07
Reviewer: Lou Berger
Review Date: Oct 13 2017
IETF LC End Date: date-if-known
Intended Status: Standards Track

Summary:

I have some major concerns about this document that I think should be
resolved before publication.

Comments:

This document is intended to provide a technical correction to the
syntactic flaws of the ietf-l3vpn-svc yang module defined in RFC 8049.
The changes are straightforward and have been cleared by the YANG Doctor
team with the one exception as discussed below.

Major Issues:

>From a strict reading of this document and the YANG Language definition
(RFC6020 or RFC7950) this document violates the MUST clauses in
https://tools.ietf.org/html/rfc7950#section-11 insofar as that
rfc8049bis has several definitions that are not compatible with those
defined in rfc8049 for the ietf-l3vpn-svc yang module, yet the bis does
not follow the requirement of RFC7950 to change the module
name/identifier. In discussion on the netmod WG list, the point has been
raised that this is acceptable as the module defined in rfc8049 should
never have been published in the first place as it is syntactically broken.

So there is a choice to be made, i.e., to either:

(a) publish this document as is and note a special exception to the
requirement of RFC7950 (an IETF consensus document), or

(b) update/change the module identifier in this document to conform with
RFC7950.

I think who makes this decision is an IETF process call and I deffer to
the IESG on this matter.

Lou
(as RtgDir reviewer, who also happens to co-chair the WG that has
technical responsibility for rfc7950.)