Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7223bis-00

Martin Bjorklund <mbj@tail-f.com> Thu, 07 December 2017 08:01 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B051201F8; Thu, 7 Dec 2017 00:01:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 LIuGCw-G0830; Thu, 7 Dec 2017 00:01:47 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3534A126C0F; Thu, 7 Dec 2017 00:01:47 -0800 (PST)
Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 3EFFB1AE0335; Thu, 7 Dec 2017 09:01:46 +0100 (CET)
Date: Thu, 07 Dec 2017 09:00:26 +0100 (CET)
Message-Id: <20171207.090026.2261269114308135275.mbj@tail-f.com>
To: evoit@cisco.com
Cc: netmod-chairs@ietf.org, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <9ce71a856a04495fa8d11fde4cc9c845@XCH-RTP-013.cisco.com>
References: <B8F9A780D330094D99AF023C5877DABA9ACFA477@nkgeml513-mbs.china.huawei.com> <20171204.154448.2155397561484121188.mbj@tail-f.com> <9ce71a856a04495fa8d11fde4cc9c845@XCH-RTP-013.cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/2SXo8GJXltOtvm4YyaXHyEkidgc>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7223bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Dec 2017 08:01:49 -0000

Hi Eric,


"Eric Voit (evoit)" <evoit@cisco.com> wrote:
> Hi Martin,
> 
> Several comments on the YANG model within rfc7223bis.
> 
> list interface {
>         key "name";
>         description
>           "The list of interfaces on the device.  The status of an interface
>           is available in this list in the
>            operational state...
> 
> A few questions on this.
> (a) The description of the list defines behaviors of various list
> nodes which might or might not exist in different NMDA datastores.  It
> also suggests when certain elements should be populated in various
> datastores.  Is the precedence being set that datastore specific
> behaviors may be placed into descriptions?

I don't know; I guess it depends on what people think about this
style.  I think that when the mapping between config and operational
state is not 1-1 and obvious, it needs to be somehow explained in the
description - just like the old descriptions did, except that where
the old descriptions refered to different *nodes*, we now refer to
different *intantiations* of the same node.


> Is this type of
> documentation guidance something which explored in
> draft-dsdt-nmda-guidelines?

I don't think so.

> (b) Does status mean 'admin-status', 'oper-status' or both?  (I think
> 'oper-status'.)

No, it is intended to mean the status of the interface in general.

> (c) should quotes be used around status?

No, since it's not the name of a specific node.

> leaf name {,   leaf type { ....
> There are NETCONF specific behaviors in the definition of these two
> leaves.  It would be great to have this transport agnostic.

One thing to note is that this also should apply to a RESTCONF
server.  But adding that doesn't really address your point :)
However, I don't know what the correct way of handling this would be.
We could be less specific and just write that the server MUST return
an "invalid-value" error, but less specific might also be more
confusing.

> I realize
> that such a transport segmentation dissociates transport error
> handling from the nodes being handled.
> 
> leaf admin-status {...
> incorrectly marked  as config false;

See the reply from Vladimir; this is corrcect.


/martin


> 
> Thanks,
> Eric
> 
> 
> > > -----邮件原件-----
> > > 发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Kent Watsen
> > > 发送时间: 2017年11月29日 3:29
> > > 收件人: netmod@ietf.org
> > > 抄送: netmod-chairs@ietf.org
> > > 主题: [netmod] WG Last Call: draft-ietf-netmod-rfc7223bis-00
> > >
> > > All,
> > >
> > > This starts a two-week working group last call on draft-ietf-netmod-
> > rfc7223bis-00.
> > >
> > > Please recall that this update's intention is to modify the YANG
> > > module to
> > be in line with the NMDA guidelines [1].  Reviewing the diff between
> > the
> > two drafts [2] should reveal just this.
> > >
> > > The working group last call ends on December 12.
> > > Please send your comments to the netmod mailing list.
> > >
> > > Positive comments, e.g., "I've reviewed this document and believe it
> > > is
> > ready for publication", are welcome!
> > > This is useful and important, even from authors.
> > >
> > > [1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01
> > > [2]
> > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7223bis-00.tx
> > > t
> > >
> > > Thank you,
> > > Netmod Chairs
> > >
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod