Return-Path: 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 99483132C3F; Sat, 14 Oct 2017 00:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 EvO3IusuQzZN; Sat, 14 Oct 2017 00:05:36 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0124132D41; Sat, 14 Oct 2017 00:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10598; q=dns/txt; s=iport; t=1507964733; x=1509174333; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=v6SoQyExDud2d48zA3M2E8VdjxjSdh+OjSJS8Xcuwc4=; b=cW1+kw3/4+6Rqt4gRiPb6FoykGPyEBdu7JSZFBPcIZD2YgaeibjZHyTo m+dGKvy6TlAhGLdq+esuvr6LO0yj0kwxB2XXxsggyJUxQMf0V8yk5dhn7 BkMm69QnYmt1g94lCKj5ZxKyloEYs85L1SgWnr3ds/ZfMucbjnCIGjQOA 0=; X-IronPort-AV: E=Sophos;i="5.43,374,1503360000"; d="scan'208,217";a="658075488" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Oct 2017 07:05:31 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v9E75Ux2029025; Sat, 14 Oct 2017 07:05:31 GMT To: Lou Berger , "rtg-ads@tools.ietf.org" Cc: rtg-dir@ietf.org, draft-wu-l3sm-rfc8049bis.all@ietf.org, Benoit Claise References: <28df7f72-e9c5-07b0-e615-344783c0750f@labn.net> From: Benoit Claise Message-ID: <1b25bc58-bddd-b8c3-aa19-6ac957741ff6@cisco.com> Date: Sat, 14 Oct 2017 09:05:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <28df7f72-e9c5-07b0-e615-344783c0750f@labn.net> Content-Type: multipart/alternative; boundary="------------8FD80B625C9699E9E35EFB7D" Content-Language: en-US Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Oct 2017 07:05:38 -0000 This is a multi-part message in MIME format. --------------8FD80B625C9699E9E35EFB7D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Lou, Thanks for initiating this discussion on the YANG doctors and on the NETMOD mailing list. The authors have produced v7 to address this comment. I replied to the IETF LC message on this very specific topic, giving one week for feedback. I can't point you to the archive, as my message awaits moderator approval (not sure why). So here a cut/paste: Dear all, Based on the feedback received, the authors produced version 7. I would like to highlight those two changes (the only two changes btw). In the abstract: This document obsoletesRFC 8049 to replace the unimplementable module in that RFC with a new module with the same name that is not backward compatible. The changes are a series of small fixes to the YANG module, and some clarifications to the text. In section 1: The YANG module described in [RFC8049 ] cannot be implemented because of issues around the use of XPATH. This document obsoletes [RFC8049 ] by creating a new module with the same name that is not backward compatible (in the sense described in YANG 1.1 [RFC7950 ]). The changes (listed in full inSection 1.4 ) are small in scope, but include fixes to the module to make it possible to implement. Changes are highlighted here: https://tools.ietf.org/rfcdiff?url2=draft-wu-l3sm-rfc8049bis-07.txt Since RFC8049 is not implementable and therefore not implemented, keeping the same YANG module name seems about right. I'll collect feedback for a week. Note that this draft is on the IESG telechat on Oct 26th. Regards, Benoit If a follow up is required, I propose that we use a single public email thread: the ietf@ietf.org Regards, Benoit > 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.) > > . > --------------8FD80B625C9699E9E35EFB7D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Lou,

Thanks for initiating this discussion on the YANG doctors and on the NETMOD mailing list.
The authors have produced v7 to address this comment.
I replied to the IETF LC message on this very specific topic, giving one week for feedback.
I can't point you to the archive, as my message awaits moderator approval (not sure why).
So here a cut/paste:
Dear all,

Based on the feedback received, the authors produced version 7.
I would like to highlight those two changes (the only two changes btw).
In the abstract:
   This document obsoletes RFC 8049 to replace the unimplementable
   module in that RFC with a new module with the same name that is not
   backward compatible.  The changes are a series of small fixes to the
   YANG module, and some clarifications to the text.
In section 1: 
   The YANG module described in [RFC8049] cannot be implemented because
   of issues around the use of XPATH.  This document obsoletes [RFC8049]
   by creating a new module with the same name that is not backward
   compatible (in the sense described in YANG 1.1 [RFC7950]).  The
   changes (listed in full in Section 1.4) are small in scope, but
   include fixes to the module to make it possible to implement.
Changes are highlighted here: https://tools.ietf.org/rfcdiff?url2=draft-wu-l3sm-rfc8049bis-07.txt
Since RFC8049 is not implementable and therefore not implemented, keeping the same YANG module name seems about right.
I'll collect feedback for a week. Note that this draft is on the IESG telechat on Oct 26th.

Regards, Benoit

If a follow up is required, I propose that we use a single public email thread: the ietf@ietf.org

Regards, Benoit
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.)

.

--------------8FD80B625C9699E9E35EFB7D--