Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT)

Mach Chen <mach.chen@huawei.com> Sun, 08 April 2018 13:20 UTC

Return-Path: <mach.chen@huawei.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4A912946D; Sun, 8 Apr 2018 06:20:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 cnqO2uEIzeC7; Sun, 8 Apr 2018 06:20:27 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 D549B127444; Sun, 8 Apr 2018 06:20:26 -0700 (PDT)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id CBADBEB8A2295; Sun, 8 Apr 2018 14:20:22 +0100 (IST)
Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sun, 8 Apr 2018 14:20:24 +0100
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.73]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0361.001; Sun, 8 Apr 2018 21:20:20 +0800
From: Mach Chen <mach.chen@huawei.com>
To: "t.petch" <ietfc@btconnect.com>, Alissa Cooper <alissa@cooperw.in>, The IESG <iesg@ietf.org>
CC: "i2rs@ietf.org" <i2rs@ietf.org>, "draft-ietf-i2rs-rib-data-model@ietf.org" <draft-ietf-i2rs-rib-data-model@ietf.org>, "i2rs-chairs@ietf.org" <i2rs-chairs@ietf.org>, "shares@ndzh.com" <shares@ndzh.com>
Thread-Topic: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT)
Thread-Index: AQHTy13moi2oBFWZPEShrejzOgw/4qP2htDAgAA/0nCAABhS0A==
Date: Sun, 08 Apr 2018 13:20:19 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2923A828A@dggeml510-mbx.china.huawei.com>
References: <152276819613.22739.3895944015063617381.idtracker@ietfa.amsl.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2923A8146@dggeml510-mbx.china.huawei.com> <00d801d3cf2e$92becf20$4001a8c0@gateway.2wire.net>
In-Reply-To: <00d801d3cf2e$92becf20$4001a8c0@gateway.2wire.net>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.194.201]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/ms-e-GR4CNnVWlFlN62GCjza35Q>
Subject: Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Apr 2018 13:20:29 -0000

Hi Tom,

> -----Original Message-----
> From: t.petch [mailto:ietfc@btconnect.com]
> Sent: Sunday, April 08, 2018 7:42 PM
> To: Mach Chen <mach.chen@huawei.com>; Alissa Cooper
> <alissa@cooperw.in>; The IESG <iesg@ietf.org>
> Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org; i2rs-chairs@ietf.org;
> shares@ndzh.com
> Subject: Re: [i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-data-
> model-10: (with COMMENT)
> 
> ---- Original Message -----
> From: "Mach Chen" <mach.chen@huawei.com>
> To: "Alissa Cooper" <alissa@cooperw.in>; "The IESG" <iesg@ietf.org>
> Cc: <i2rs@ietf.org>; <draft-ietf-i2rs-rib-data-model@ietf.org>;
> <i2rs-chairs@ietf.org>; <shares@ndzh.com>
> Sent: Sunday, April 08, 2018 9:23 AM
> 
> > Hi Alissa,
> >
> > Thanks for your comments!
> >
> > Please see my responses inline...
> >
> > > -----Original Message-----
> > > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Alissa Cooper
> > > Sent: Tuesday, April 03, 2018 11:10 PM
> > > To: The IESG <iesg@ietf.org>
> > > Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org;
> i2rs-chairs@ietf.org;
> > > shares@ndzh.com
> > > Subject: [i2rs] Alissa Cooper's No Objection on
> draft-ietf-i2rs-rib-data-model-10:
> > > (with COMMENT)
> > >
> > > Alissa Cooper has entered the following ballot position for
> > > draft-ietf-i2rs-rib-data-model-10: No Objection
> > >
> > > When responding, please keep the subject line intact and reply to
> all email
> > > addresses included in the To and CC lines. (Feel free to cut this
> introductory
> > > paragraph, however.)
> > >
> > >
> > > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > for more information about IESG DISCUSS and COMMENT positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found here:
> > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/
> > >
> > >
> > >
> >
> > ----------------------------------------------------------------------
> > > COMMENT:
> >
> > ----------------------------------------------------------------------
> > >
> > > Sec 1.2:
> > >
> > > "YANG tree diagrams provide a concise representation of a YANG
> module,
> > >    and SHOULD be included to help readers understand YANG module
> > >    structure."
> > >
> > > This document does not seem like an appropriate place to have
> normative
> > > guidance about this. And if this sentence is removed, I don't see
> the point of
> > > including Section 1.2 otherwise. This would also imply deleting the
> reference to
> > > I-D.ietf-netmod-yang-tree-diagrams.
> >
> > This results from a YANG doctor review.  I saw it also occurs in other
> published documents. I personally think it's no harm to keep it, how do you
> think?
> 
> Mach
> 
> I think that this is very odd.
> 
> YANG guidelines rfc6087bis says
> "   YANG tree diagrams provide a concise representation of a YANG
> module,
>    and SHOULD be included to help readers understand YANG module
>    structure.  Guidelines on tree diagrams can be found in Section 3 of
>    [I-D.ietf-netmod-yang-tree-diagrams].
> "
> which I think is the correct guidance in the correct place.
> 
> A quick look at the recently published RFC8343, RFC8344, RFC8345,
> RFC8346 contain no text of the kind you suggest so if it occurs in other I-D, then
> I would regard those other I-D as being in error.
> 
> If I look back at a thread from Ebben for a yang doctor review of an earlier
> version of this I-D, the text I see proposed is
> 
> "
> >    A simplified graphical representation of the data model is used in
> >    this document.  The meaning of the symbols in these diagrams is
> >    defined in [I-D.ietf-netmod-yang-tree-diagrams].
> "
> which I think is rather different.

Indeed, my fault, I just checked Ebben's suggestion, it's as above quoted. 

To Alissa:
If change to following text, is it OK for you?

"A simplified graphical representation of the data model is used in
this document.  The meaning of the symbols in these diagrams is
defined in [I-D.ietf-netmod-yang-tree-diagrams]."


Best regards,
Mach
> 
> Tom Petch
> (not a YANG doctor)
> 
> > >
> > > Sec 2.1: Again here I'm confused about the use of normative
> language. Why do
> > > you need to specify normative requirements for what this very
> document is
> > > specifying? Or are these supposed to be requirements on
> implementations?
> >
> > OK, how about this:
> >
> > "...a RIB data model needs to specify a way for an external entity to
> learn about the functional capabilities of a network device." And
> >
> > " The RIB data model needs a way to expose the nexthop chaining
> capability supported by a given network device."
> >
> > >
> > > Sec 2.5: s/causes/caused/
> >
> > Done
> >
> > The above updates will be reelected in version-11.
> >
> > Thanks,
> > Mach
> > >