Re: [RTG-DIR] Routing Directorate review of draft-ietf-rtgwg-ni-model-02

Lou Berger <lberger@labn.net> Sat, 29 April 2017 14:45 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 F0D8B1294F4 for <rtg-dir@ietfa.amsl.com>; Sat, 29 Apr 2017 07:45:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=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 IbmPi8M7MZ-0 for <rtg-dir@ietfa.amsl.com>; Sat, 29 Apr 2017 07:45:07 -0700 (PDT)
Received: from gproxy8.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 C710E126B6E for <rtg-dir@ietf.org>; Sat, 29 Apr 2017 07:44:50 -0700 (PDT)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id AB8311AB0D5 for <rtg-dir@ietf.org>; Sat, 29 Apr 2017 08:44:48 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id EEkk1v00R2SSUrH01EkndU; Sat, 29 Apr 2017 08:44:48 -0600
X-Authority-Analysis: v=2.2 cv=Ibz3YSia c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=AzvcPWV-tVgA:10 a=48vgC7mUAAAA:8 a=L35N5iEh9iDEk8KDZvMA: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:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=qybVsJO03rxB1XJvQxF8c9T7KVhEoh00ytwIwW+TbqU=; b=Wg2nSRidEOotoppil5XMcwwMLS ZoRLGIdu9O3/Td576oSGyrTfVC0vJGSLr7B+62bg2sGtAvYKNJ7KuYH30H5Iin3dULh0Ut+hDNI46 INOCU0vzewook2y/RVrlrQf1r;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:56054 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 1d4Tc2-0005bT-GK; Sat, 29 Apr 2017 08:44:44 -0600
To: "John G. Scudder" <jgs@juniper.net>, draft-ietf-rtgwg-ni-model@ietf.org
References: <B6095AC5-A3FD-450A-BBD3-FB88FD04800F@juniper.net>
Cc: rtg-dir@ietf.org, rtgwg-chairs@ietf.org, rtgwg@ietf.org
From: Lou Berger <lberger@labn.net>
Message-ID: <4298c8ad-d44e-6f37-b321-4bf62b6eb145@labn.net>
Date: Sat, 29 Apr 2017 10:44:31 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <B6095AC5-A3FD-450A-BBD3-FB88FD04800F@juniper.net>
Content-Type: text/plain; charset="UTF-8"
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.84.20
X-Exim-ID: 1d4Tc2-0005bT-GK
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:56054
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/YwHU28fy09HdM-GvMYN1L5lQnUg>
Subject: Re: [RTG-DIR] Routing Directorate review of draft-ietf-rtgwg-ni-model-02
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: Sat, 29 Apr 2017 14:45:09 -0000

Thanks for the review!  We'll address your (much appreciated!)  comments
as part of our next planned update which will also include:

- update to next rev of schema mount (which gates this works)

- more informational text / examples

Thanks,

Lou


On 4/28/2017 4:23 PM, John G. Scudder wrote:
> Hi All,
>  
> I have been selected to do a routing directorate aQA review of this draft.
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ni-model/
>  
> The QA review is described (https://trac.ietf.org/trac/rtg/wiki/RtgDirDocQa) as:
>
> "The WG Draft Quality Assurance process exists to provide cross-WG and expert review early in the IETF process after a WG has adopted a WG draft or while the WG is deciding to adopt a draft. Since a WG adopts a draft as a good starting point for the work, providing early excellent review of such drafts allows for good technical discussion and the ability to enhance the WG draft to solve identified issues. The earlier in the process that substantial issues (technical or editorial) are resolved, the more quickly and smoothly a WG draft is likely to proceed."
>  
> For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Document: draft-ietf-rtgwg-ni-model-02.txt 
> Reviewer: John Scudder
> Review Date: April 28, 2017
>
> Summary: 
>
> I found the document easy to follow, clear and almost painless to read, thank you.
>
> Note that my level of Yang expertise is pretty low, so you should be looking elsewhere for a critique of anything other than the grossest Yang-specific aspects of the document. (I found the schema-mount example in section 3.2 particularly opaque.)
>
>
> Comments and Questions:
>
> 1. There's a significant amount of duplication of explanatory and background text between this document and draft-ietf-rtgwg-lne-model-01. In reading it, I tried to consider whether it would be OK to cut out some of the text explaining what an LNE is, but on the whole I think it's better left in -- the document would have been more difficult to read without having that context in-line. However, it does lead to the question, is there some good reason the two documents are separate, instead of a single document? The duplication between them suggests there's at least some motivation to refactor them into one. (I realize there may be many reasons to keep them separate, including "seriously, John? The cost/benefit just isn't there", but I had to ask.)
>
> 2. The abstract is almost a copy of the abstract for draft-ietf-rtgwg-lne-model-01. Comments in #1 above notwithstanding, I do think brevity is the soul of wit when it comes to an abstract, so I suggest removing the LNE definition here, and just define the stuff *this* doc is about. (Similar suggestion applies to the companion doc's abstract.)
>
> 3. It seems to me the "TBD" for network-instance-policy represents a significant open issue and deserves to be included in your open issues list (section 1.1). Other TBDs sprinkled throughout don't seem to rise to this level, but of course do represent open issues.
>
> 4. Speaking of network instance policy, although since it's left TBD there's not much to be said, the examples you give (RTs, RDs, VNIs, VPLS neighbors) mostly don't seem like what I think of as "policy". I suppose it's one of the most overloaded terms in our industry, so maybe someone else does think of it that way, but this choice of terminology was a speed bump for my understanding of the doc.
>
> 5. The example given in section 3.2 doesn't seem to follow the same pattern as the one given in section 3. I'm too much of a Yang neophyte to know if there might be some Yang feature in play that makes this make sense, but on the face of it the example in section 3 seems to tell me I'm supposed to bind a network-instance-name to a specific instance of an interface (so, if:interfaces/if:interface), whereas what I see in 3.2 is a network-instance-name at the if:interfaces level -- which doesn't make a lot of intuitive sense, either.
>
>
> Minor Issues and Nits:
>
> 6. I've edited various minor suggestions into a copy of draft-ietf-rtgwg-ni-model-02.txt and attached it, you can look at them using your diff tool of choice.
>
> 7. This sentence isn't quite right:
>
>    Network instance policies are used to control how NI information is
>    represented at the device level, VRF routing policies, and VRF/VSI
>    identifiers.
>
> Without knowing your intent I'm not able to offer you a rewrite. Possibly it would be enough to reorder the items in your list, to put the big compound one at the end, as in "Network instance policies are used to control VRF routing policies, VRF/VSI identifiers, and how NI information is represented at the device level"? 
>
> 8. This sentence no verb:
>
>                       For layer 3,
>                       this consistent with the routing-instance
>                       definition in ietf-routing
>
> Again, without knowing your intent I can't offer a rewrite. Maybe the verb "to be" is what you want?
>
>
>
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg