From j.schoenwaelder@jacobs-university.de Wed Sep 4 04:58:20 2013 Return-Path: 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 8D04921E80B7 for ; Wed, 4 Sep 2013 04:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.221 X-Spam-Level: X-Spam-Status: No, score=-103.221 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z04MznX7Jf2j for ; Wed, 4 Sep 2013 04:58:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B086A11E8176 for ; Wed, 4 Sep 2013 04:58:06 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9DC9C20C41; Wed, 4 Sep 2013 13:58:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SEMa0AgoApxX; Wed, 4 Sep 2013 13:58:05 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2BC4520C0F; Wed, 4 Sep 2013 13:58:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id ECCCE283465F; Wed, 4 Sep 2013 13:57:58 +0200 (CEST) Date: Wed, 4 Sep 2013 13:57:58 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20130904115758.GC53998@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] WG Last Call draft-ietf-netmod-ip-cfg-10 (until 2013-09-18) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 11:58:20 -0000 Hi, I hereby like to start a WG last call for the document "A YANG Data Model for IP Management": http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-10 Please indicate your support by Wednesday September 18th. We are not only interested in receiving defect reports, we are equally interested in statements of the form: "I have reviewed I-D XYZ and I found no issues" "I have implemented the data model in I-D XYZ" "I am implementing the data model in I-D XYZ" "I am considering to implement the data model in I-D XYZ" This document already had WG last calls and it subsequently went through IETF last call. Several issues were raised during IETF last call and some of them required to be explicit how we deal with the separation of configuration state and operational state. This version of the I-D is believed to address the issues that were raised. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Wed Sep 4 22:25:22 2013 Return-Path: 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 E8FBF21E80A5 for ; Wed, 4 Sep 2013 22:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.189 X-Spam-Level: X-Spam-Status: No, score=-103.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eEmNHXOVxCJ for ; Wed, 4 Sep 2013 22:25:16 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9D17121E80AD for ; Wed, 4 Sep 2013 22:25:15 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D277A20BF9; Thu, 5 Sep 2013 07:25:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8WJAHbRd-Mbe; Thu, 5 Sep 2013 07:25:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4EA3320BF5; Thu, 5 Sep 2013 07:25:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 166D42835DB5; Thu, 5 Sep 2013 07:25:08 +0200 (CEST) Date: Thu, 5 Sep 2013 07:25:08 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20130905052508.GB56548@elstar.local> Mail-Followup-To: netmod@ietf.org, Susan Hares MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Susan Hares Subject: [netmod] Susan Hares review of NETMOD documents X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 05:25:22 -0000 Hi, Susan Hares reviewed the WG documents last called before the last IETF. This is also an OPS-DIR review. Below are Susan's comments. We need to decide which ones need an action. /js ---8<---8<--- Review of the documents below: Overall comments: 1. Nice set of document that have a clear logical format. 2. Editorial only: Please pick one use for RFC's either "RFCxxxx: blah" or RFCXXX - blah". Then all to all document in all spots. Otherwise these differ irrationally. 3. technical/editorial: draft-ietf-netmod-interfaces-cfg-12 When you have "mandatory true:" versus "default true" (p. 15), is this defined in another document? If so can you put some reference to it the text. I kept wondering why is this here. 4. Technical/Editorial: draft-ietf-netmod-system-mgmt-08 When you have rpc functions, it would be nice to have them collected Into a summary page like the variables: p. 7 +ro current-datetime + ro boot-date-time? Has the following RPCs P 28 rpc set-current-datetime rpc-system-restart rpc-system-shutdown 5. Technical comment: draft-ietf-netmod-iana-if-type-07 (see RFC comment) 1st -Gather Deprecated to single comment: #1, #11, #62 Obsolete to single comment: #19, 117 This is good for long-term support by IANA and IESG. 2nd - Determine if there is a difference between deprecated and obsoleted. Question: Does DS1-MIB have a number (IEEE or IETF)? 6. Draft-ietf-netmod-iana-timezones-00 Editorial only: A little more explanation why there are Michigan--- most locations" And then specific locations may be in order in section 1. Otherwise you are simply Scribing text files without benefit. A few minutes will help the next IANA person. ---8<---8<--- /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From yihuan@cisco.com Wed Sep 4 23:24:11 2013 Return-Path: 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 C982721E8097 for ; Wed, 4 Sep 2013 23:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Lzov1NZBzcO for ; Wed, 4 Sep 2013 23:24:07 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id DF20711E811A for ; Wed, 4 Sep 2013 23:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2854; q=dns/txt; s=iport; t=1378362247; x=1379571847; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=46t3+0gGT1xMTkvtLWix3yGewumNDmMlMToxgxekrJw=; b=W3B234bCtd1vMkP3UUhRq1epf61JJMUruJ93XfmAJf4H7l730NavWYYp Sj1feDfSEqTjodlXwxBBOraf9kGdTA7XWNlj7ZJOV1vdJLIoTL+Ky0Dnk t1jLZNZARlzaP2CLiqIX/xsvKv+9YUhww5h481XJSo0qrsXOyQ6+hJcpJ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoEFAHMiKFKtJV2Y/2dsb2JhbABbgwc1SwbBRoEvFnSCJAEBAQRyBQISAQgiVhsBBgMCBA4FCAGHeQcFuiyPLzEHgx2BAAOIfZAnkDeDIIIq X-IronPort-AV: E=Sophos;i="4.90,845,1371081600"; d="scan'208";a="252832219" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 05 Sep 2013 06:24:07 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r856O6nB008603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Sep 2013 06:24:06 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.187]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Thu, 5 Sep 2013 01:24:06 -0500 From: "Lisa Huang (yihuan)" To: "netmod@ietf.org" Thread-Topic: New Version Notification for draft-huang-netmod-acl-03.txt Thread-Index: AQHOqfVPjk7DmIVwJEa9wclnhisHJpm2i5cA Date: Thu, 5 Sep 2013 06:24:06 +0000 Message-ID: <559E176269AD64429F1582D4EB94F86F021B30DD@xmb-aln-x03.cisco.com> In-Reply-To: <20130905050347.24482.56294.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.88.173] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [netmod] FW: New Version Notification for draft-huang-netmod-acl-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 06:24:11 -0000 Hi, This is a new version of Stateless Packet Filter(a.k.a. ACL) Yang model I-D. We updated the draft according to the feedback from the meeting. The change summary is as follows: 1. In IETF 86 meeting, a proposal was made to change ACL to stateless packet filter. In this version, we changed the I-D title to =B3A YANG Data Model for Stateless Packet Filter Configuration=B2 and also made corresponding changes in models, terminology, and descriptions. 2. This new version also provided explanations of relationship between Stateless Packet Filter and Access Control List. The sets of rules of Stateless Packet Filter are sometimes also referred to as "Access Control Lists" (ACL). In the draft, SPF, stateless-pf and ACL are interchangeably, as well as the terms Packet Filter Entry (PFE) and ACE. 3. A section is added to explain how to attach SPFs to interfaces. Attaching an SPF to an interface is outside the scope of this model as it depends on the specifics of the system model that is being applied. However, this I-D provides the possible general design pattern. For example, to attach an SPF to an interface as defined per the data model [if-config], the following steps can be applied: a. Introduce a new YANG module to extend the interface configuration YANG module. b. Import modules "interfaces" [if-config] (prefix: "if") and "stateless-pf" (prefix: "spf"). c. Augment list "interface" (/if:interfaces/if:interface) with a leaf-list of type "spf:spf-ref". Thanks, --Lisa (On behalf of Alex and Andy) On 9/4/13 10:03 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-huang-netmod-acl-03.txt >has been successfully submitted by Lisa Huang and posted to the >IETF repository. > >Filename: draft-huang-netmod-acl >Revision: 03 >Title: YANG Data Model for Stateless Packet Filter Configuration >Creation date: 2013-09-04 >Group: Individual Submission >Number of pages: 81 >URL: =20 >http://www.ietf.org/internet-drafts/draft-huang-netmod-acl-03.txt >Status: http://datatracker.ietf.org/doc/draft-huang-netmod-acl >Htmlized: http://tools.ietf.org/html/draft-huang-netmod-acl-03 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-huang-netmod-acl-03 > >Abstract: > A Stateless Packet Filter (SPF) determines which packets are allowed > to transit a system according to a set of rules, applying special > actions to packets as necessary. This document defines a YANG data > model for the configuration of Stateless Packet Filters on a device. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From mbj@tail-f.com Thu Sep 5 00:56:43 2013 Return-Path: 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 4C83811E8183 for ; Thu, 5 Sep 2013 00:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvGgjeY5+mPd for ; Thu, 5 Sep 2013 00:56:27 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7550D11E8124 for ; Thu, 5 Sep 2013 00:56:27 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 42E2112000BF; Thu, 5 Sep 2013 09:56:25 +0200 (CEST) Date: Thu, 05 Sep 2013 09:56:25 +0200 (CEST) Message-Id: <20130905.095625.1787068239592158231.mbj@tail-f.com> To: shares@ndzh.com, j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20130905052508.GB56548@elstar.local> References: <20130905052508.GB56548@elstar.local> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ""@tail-f.com, netmod@ietf.org Subject: Re: [netmod] Susan Hares review of NETMOD documents X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 07:56:43 -0000 Hi, Comments inline. Juergen Schoenwaelder wrote: > 2. Editorial only: > Please pick one use for RFC's either "RFCxxxx: blah" or RFCXXX - > blah". > Then all to all document in all spots. Otherwise these > differ irrationally. I found two of these in the system draft, and fixed them. Specifically: OLD: reference "RFC 3418 - Management Information Base (MIB) for the Simple Network Management Protocol (SNMP) SNMPv2-MIB.sysContact"; NEW: reference "RFC 3418: Management Information Base (MIB) for the Simple Network Management Protocol (SNMP) SNMPv2-MIB.sysContact"; Did I miss any? > 3. technical/editorial: draft-ietf-netmod-interfaces-cfg-12 > > When you have "mandatory true:" versus "default true" (p. 15), is this > defined in another document? > If so can you put some reference to it the text. I kept wondering why is > this here. "mandatory" and "default" are YANG keywords, with very precise semantics, defined in RFC 6020. > 4. Technical/Editorial: draft-ietf-netmod-system-mgmt-08 > > When you have rpc functions, it would be nice to have them collected > Into a summary page like the variables: > p. 7 +ro current-datetime > + ro boot-date-time? > > Has the following RPCs > P 28 rpc set-current-datetime > rpc-system-restart > rpc-system-shutdown Good idea, I have added such a summary listing. > 5. Technical comment: draft-ietf-netmod-iana-if-type-07 > (see RFC comment) > 1st -Gather Deprecated to single comment: #1, #11, #62 > Obsolete to single comment: #19, 117 > This is good for long-term support by IANA and IESG. I am not sure what you propose. All values are listed in the order they occur in the registry, just like in the corresponding MIB. > 2nd - Determine if there is a difference between deprecated and > obsoleted. Yes there is; YANG has the same interpration of these terms as SMIv2. > Question: Does DS1-MIB have a number (IEEE or IETF)? I am not sure what you mean? > 6. Draft-ietf-netmod-iana-timezones-00 > > Editorial only: A little more explanation why there are Michigan--- > most locations" I am not the editor of this document, but this text is copied verbatim from IANA's timezone database. > And then specific locations may be in order in section 1. Otherwise > you are simply > Scribing text files without benefit. A few minutes will help the next > IANA person. I am not sure what the suggestion is? /martin From ietfdbh@comcast.net Thu Sep 5 09:55:35 2013 Return-Path: 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 7505111E81C6 for ; Thu, 5 Sep 2013 09:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLqNoH9kgQJS for ; Thu, 5 Sep 2013 09:55:28 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id CA67D11E81C0 for ; Thu, 5 Sep 2013 09:55:27 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta04.westchester.pa.mail.comcast.net with comcast id MQGB1m00516LCl054UvRCK; Thu, 05 Sep 2013 16:55:25 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta06.westchester.pa.mail.comcast.net with comcast id MUvQ1m00h2yZEBF3SUvQDn; Thu, 05 Sep 2013 16:55:25 +0000 From: "ietfdbh" To: "'Martin Bjorklund'" , , References: <20130905052508.GB56548@elstar.local> <20130905.095625.1787068239592158231.mbj@tail-f.com> In-Reply-To: <20130905.095625.1787068239592158231.mbj@tail-f.com> Date: Thu, 5 Sep 2013 12:55:21 -0400 Message-ID: <00ea01ceaa58$b5e76d90$21b648b0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMElhjGulWIhS0V/lrxLpNVOzRT9gJ8YTHVlzeTRpA= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1378400125; bh=ztXhXLEUPyVJ5JyYnNC+Cfg52AnoAqdYTJNtobh6GY8=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=FF9mlUL2BCiN8wvAPpK8zS86Qzw6YiVHSZoVhnZLJbO65HPZnWTI8qXm26pe9BnbN 7znVO3EjcTE8qD63MPyiNok2X29F5nUbVqzpsTrQa1erSE6VIv7RleUj4y49l5Q53e LlsJLOq0hAzag8Li+obNyxigp9IizcQzi9WMsdn3Xk4U+e650U2OiuKacFnKilhX72 c5N32/S0W9DhirZs2bBFHA5m+9hBS4yI2m8lHWUGImYAFKlEq/RXXI00vUtUPiWdNz SxB9FQ8lp4THefw+zSD4iN7E1WrGN0Rq2xWbsy+15rv0i9VFkgE+UJS3ScwOW870Tk aL3Uw8gmEqVgQ== Cc: netmod@ietf.org, "'@tail-f.com'"@ietfa.amsl.com Subject: Re: [netmod] Susan Hares review of NETMOD documents X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 16:55:35 -0000 Hi Martin, I think Sue wants a reference for DS1-MIB in the g703at2mb enum. You have a reference clause in 2 of the 3 mentions of ds1-mib in the description clause, such as enum "ds1" { value 18; description "DS1-MIB"; reference "RFC 4805 - Definitions of Managed Objects for t DS1, J1, E1, DS2, and E2 Interface Types"; } but not in this one: enum "g703at2mb" { value 67; status obsolete; description "Obsolete see DS1-MIB"; } Looking at this raised a question for me: The description clause for enum "ds1" is "DS1-MIB". "DS1-MIB" is not a description of a ds1 interface. I recommend changing the description to "see DS1-MIB." David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf Of Martin Bjorklund > > > Question: Does DS1-MIB have a number (IEEE or IETF)? > > I am not sure what you mean? From mbj@tail-f.com Thu Sep 5 10:27:32 2013 Return-Path: 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 B1EF021E8167 for ; Thu, 5 Sep 2013 10:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IgI0hOfMbAh for ; Thu, 5 Sep 2013 10:27:26 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4342621E814F for ; Thu, 5 Sep 2013 10:27:17 -0700 (PDT) Received: from localhost (unknown [193.12.34.113]) by mail.tail-f.com (Postfix) with ESMTPSA id 7F5CE1200089; Thu, 5 Sep 2013 19:27:10 +0200 (CEST) Date: Thu, 05 Sep 2013 19:21:34 +0200 (CEST) Message-Id: <20130905.192134.358075968.mbj@tail-f.com> To: ietfdbh@comcast.net From: Martin Bjorklund In-Reply-To: <00ea01ceaa58$b5e76d90$21b648b0$@comcast.net> References: <20130905052508.GB56548@elstar.local> <20130905.095625.1787068239592158231.mbj@tail-f.com> <00ea01ceaa58$b5e76d90$21b648b0$@comcast.net> X-Mailer: Mew version 6.5rc2 on Emacs 24.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org, shares@ndzh.com Subject: Re: [netmod] Susan Hares review of NETMOD documents X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 17:27:32 -0000 Hi, "ietfdbh" wrote: > Hi Martin, > > I think Sue wants a reference for DS1-MIB in the g703at2mb enum. > > You have a reference clause in 2 of the 3 mentions of ds1-mib in the > description clause, such as > enum "ds1" { > value 18; > description > "DS1-MIB"; > reference > "RFC 4805 - Definitions of Managed Objects for t > DS1, J1, E1, DS2, and E2 Interface Types"; > } > > but not in this one: > enum "g703at2mb" { > value 67; > status obsolete; > description > "Obsolete see DS1-MIB"; > } > > > Looking at this raised a question for me: > The description clause for enum "ds1" is "DS1-MIB". > "DS1-MIB" is not a description of a ds1 interface. > I recommend changing the description to "see DS1-MIB." Ok. These descriptions are copied verbatim from the IANA registry, and I am not sure it is a good idea to change the text in the YANG serialization of the registry. I do think it would be good with better descriptions, but they should probably be added to the IANA registry (and then of course copied to the YANG module). /martin From j.schoenwaelder@jacobs-university.de Thu Sep 5 23:18:54 2013 Return-Path: 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 D4A3D11E814E for ; Thu, 5 Sep 2013 23:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.192 X-Spam-Level: X-Spam-Status: No, score=-103.192 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8XRuOTskOTq for ; Thu, 5 Sep 2013 23:18:50 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0A64221F9B0A for ; Thu, 5 Sep 2013 23:18:30 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6AB7420C0A; Fri, 6 Sep 2013 08:18:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Y_H4RVq5Jstd; Fri, 6 Sep 2013 08:18:29 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6136120C03; Fri, 6 Sep 2013 08:18:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E086E283826E; Fri, 6 Sep 2013 08:18:21 +0200 (CEST) Date: Fri, 6 Sep 2013 08:18:21 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20130906061821.GA59991@elstar.local> Mail-Followup-To: Susan Hares , 'Martin Bjorklund' , ietfdbh@comcast.net, netmod@ietf.org, bclaise@cisco.com References: <20130905052508.GB56548@elstar.local> <20130905.095625.1787068239592158231.mbj@tail-f.com> <00ea01ceaa58$b5e76d90$21b648b0$@comcast.net> <20130905.192134.358075968.mbj@tail-f.com> <019d01ceaa5f$a75ce0a0$f616a1e0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <019d01ceaa5f$a75ce0a0$f616a1e0$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Susan Hares review of NETMOD documents X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 06:18:55 -0000 Susan, this YANG module is a YANG serialization of the registry, which is the primary source of information. All of this will be maintained by IANA. If some data is wrong or imprecise, it really needs to fixed in the primary source, the IANA registry. In this case, I am behind Martin since this is not derivative work that will have a life on its own. /js On Thu, Sep 05, 2013 at 01:45:03PM -0400, Susan Hares wrote: > Martin: > > This is not a process message, but a technical review. > > As I have told many of my co-workers, It does not matter that you copied it. > If your name is on the RFC, you must know if it is right or wrong. > > On IANA data: > I know that during the review of your document that IANA tries to find any > past errors. IANA is careful and welcomes knowledge from the community > about errors. > > During your review, you should inform IANA of any considerations such as > errors. As a person doing OPS-DIR review, I believe that this portion of > the record is inaccurate or imprecise. > > Does "DS1-MIB" refer toDS1-MIB is: RFC 4805, RFC3895 or RFC2495 or something > else. > > An example of something else is: > Online: http://www.simpleweb.org/ietf/mibs/modules/IETF/txt/DS1-MIB > > -------------- > RFC > > DS1-MIB DEFINITIONS ::= BEGIN > > IMPORTS > MODULE-IDENTITY, OBJECT-TYPE, > NOTIFICATION-TYPE, transmission > FROM SNMPv2-SMI -- [RFC2578] > DisplayString, TimeStamp, TruthValue > FROM SNMPv2-TC -- [RFC2579] > MODULE-COMPLIANCE, OBJECT-GROUP, > NOTIFICATION-GROUP > FROM SNMPv2-CONF -- [RFC2580] > InterfaceIndex, ifIndex > FROM IF-MIB -- [RFC2863] > PerfCurrentCount, PerfIntervalCount, > PerfTotalCount > FROM PerfHist-TC-MIB; -- [RFC3593] > > ds1 MODULE-IDENTITY > LAST-UPDATED "200703050000Z" > ORGANIZATION "IETF AToM MIB Working Group" > ========== > > Please attend to this to provide a better legacy than we currently have on > these definitions. > > Sue > > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Thursday, September 05, 2013 1:22 PM > To: ietfdbh@comcast.net > Cc: shares@ndzh.com; j.schoenwaelder@jacobs-university.de; netmod@ietf.org > Subject: Re: [netmod] Susan Hares review of NETMOD documents > > Hi, > > "ietfdbh" wrote: > > Hi Martin, > > > > I think Sue wants a reference for DS1-MIB in the g703at2mb enum. > > > > You have a reference clause in 2 of the 3 mentions of ds1-mib in the > > description clause, such as > > enum "ds1" { > > value 18; > > description > > "DS1-MIB"; > > reference > > "RFC 4805 - Definitions of Managed Objects for t > > DS1, J1, E1, DS2, and E2 Interface Types"; > > } > > > > but not in this one: > > enum "g703at2mb" { > > value 67; > > status obsolete; > > description > > "Obsolete see DS1-MIB"; > > } > > > > > > Looking at this raised a question for me: > > The description clause for enum "ds1" is "DS1-MIB". > > "DS1-MIB" is not a description of a ds1 interface. > > I recommend changing the description to "see DS1-MIB." > > Ok. These descriptions are copied verbatim from the IANA registry, and I am > not sure it is a good idea to change the text in the YANG serialization of > the registry. I do think it would be good with better descriptions, but > they should probably be added to the IANA registry (and then of course > copied to the YANG module). > > > /martin > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From shares@ndzh.com Thu Sep 5 10:45:17 2013 Return-Path: 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 9D4FF11E824D for ; Thu, 5 Sep 2013 10:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.825 X-Spam-Level: X-Spam-Status: No, score=-0.825 tagged_above=-999 required=5 tests=[AWL=0.774, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8z8VesU0htdt for ; Thu, 5 Sep 2013 10:45:06 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6457711E824A for ; Thu, 5 Sep 2013 10:45:06 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Martin Bjorklund'" , References: <20130905052508.GB56548@elstar.local> <20130905.095625.1787068239592158231.mbj@tail-f.com> <00ea01ceaa58$b5e76d90$21b648b0$@comcast.net> <20130905.192134.358075968.mbj@tail-f.com> In-Reply-To: <20130905.192134.358075968.mbj@tail-f.com> Date: Thu, 5 Sep 2013 13:45:03 -0400 Message-ID: <019d01ceaa5f$a75ce0a0$f616a1e0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQMElhjGulWIhS0V/lrxLpNVOzRT9gJ8YTHVAZMTMh8CWsQ9yZcYPLzA X-Authenticated-User: skh@ndzh.com X-Mailman-Approved-At: Fri, 06 Sep 2013 01:12:19 -0700 Cc: netmod@ietf.org Subject: Re: [netmod] Susan Hares review of NETMOD documents X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 17:45:17 -0000 Martin: This is not a process message, but a technical review. As I have told many of my co-workers, It does not matter that you copied it. If your name is on the RFC, you must know if it is right or wrong. On IANA data: I know that during the review of your document that IANA tries to find any past errors. IANA is careful and welcomes knowledge from the community about errors. During your review, you should inform IANA of any considerations such as errors. As a person doing OPS-DIR review, I believe that this portion of the record is inaccurate or imprecise. Does "DS1-MIB" refer toDS1-MIB is: RFC 4805, RFC3895 or RFC2495 or something else. An example of something else is: Online: http://www.simpleweb.org/ietf/mibs/modules/IETF/txt/DS1-MIB -------------- RFC DS1-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, transmission FROM SNMPv2-SMI -- [RFC2578] DisplayString, TimeStamp, TruthValue FROM SNMPv2-TC -- [RFC2579] MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- [RFC2580] InterfaceIndex, ifIndex FROM IF-MIB -- [RFC2863] PerfCurrentCount, PerfIntervalCount, PerfTotalCount FROM PerfHist-TC-MIB; -- [RFC3593] ds1 MODULE-IDENTITY LAST-UPDATED "200703050000Z" ORGANIZATION "IETF AToM MIB Working Group" ========== Please attend to this to provide a better legacy than we currently have on these definitions. Sue -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com] Sent: Thursday, September 05, 2013 1:22 PM To: ietfdbh@comcast.net Cc: shares@ndzh.com; j.schoenwaelder@jacobs-university.de; netmod@ietf.org Subject: Re: [netmod] Susan Hares review of NETMOD documents Hi, "ietfdbh" wrote: > Hi Martin, > > I think Sue wants a reference for DS1-MIB in the g703at2mb enum. > > You have a reference clause in 2 of the 3 mentions of ds1-mib in the > description clause, such as > enum "ds1" { > value 18; > description > "DS1-MIB"; > reference > "RFC 4805 - Definitions of Managed Objects for t > DS1, J1, E1, DS2, and E2 Interface Types"; > } > > but not in this one: > enum "g703at2mb" { > value 67; > status obsolete; > description > "Obsolete see DS1-MIB"; > } > > > Looking at this raised a question for me: > The description clause for enum "ds1" is "DS1-MIB". > "DS1-MIB" is not a description of a ds1 interface. > I recommend changing the description to "see DS1-MIB." Ok. These descriptions are copied verbatim from the IANA registry, and I am not sure it is a good idea to change the text in the YANG serialization of the registry. I do think it would be good with better descriptions, but they should probably be added to the IANA registry (and then of course copied to the YANG module). /martin From ietfdbh@comcast.net Fri Sep 6 06:06:06 2013 Return-Path: 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 4C5C511E818F for ; Fri, 6 Sep 2013 06:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wEqBCxgo7UT for ; Fri, 6 Sep 2013 06:06:01 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 8377611E8145 for ; Fri, 6 Sep 2013 06:06:01 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta08.westchester.pa.mail.comcast.net with comcast id Mnti1m0041GhbT858p60m5; Fri, 06 Sep 2013 13:06:00 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta07.westchester.pa.mail.comcast.net with comcast id Mp5z1m01R2yZEBF3Tp60y6; Fri, 06 Sep 2013 13:06:00 +0000 From: "ietfdbh" To: "'Juergen Schoenwaelder'" , "'Susan Hares'" References: <20130905052508.GB56548@elstar.local> <20130905.095625.1787068239592158231.mbj@tail-f.com> <00ea01ceaa58$b5e76d90$21b648b0$@comcast.net> <20130905.192134.358075968.mbj@tail-f.com> <019d01ceaa5f$a75ce0a0$f616a1e0$@ndzh.com> <20130906061821.GA59991@elstar.local> In-Reply-To: <20130906061821.GA59991@elstar.local> Date: Fri, 6 Sep 2013 09:05:56 -0400 Message-ID: <012c01ceab01$d3b40370$7b1c0a50$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMElhjGulWIhS0V/lrxLpNVOzRT9gJ8YTHVAZMTMh8CWsQ9yQKS5cxoAPW0MwSW/UDQ0A== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1378472760; bh=CbAM2XbcbaMztq4HMumL1ZCTmin/Kc/rKPGdIbcJR70=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=eR+ipu/Ve0bgf/M0j3EqjDlvg58lnHRiKyx8RpG33hp+sT2Y9iK7+tpxOqG+CSsvA zrdAVl4EDgIOTzXaNBlDRedlgMt5e1oS3uKmbPwYNKEeBwhvqoyefus0LvrG75FyaR DxtFnUTlrsqy2HjSCh+6MFCEbt7vvWuu0SyGynicZ9UbsGPCn5WU4C5Qm6V6P0m84F GUmllh5wbV46Bq8F3WAaFN5XpsEPy6BfPztwmr8ZAoX82QeoEQFwFGMYXJrIs1tm2t DPoR+UbKiMVGvsx+Fwy3wrTzx37nkl5wW/r4ue6g2vnY4StFq9yYxm8Bb3I1Imo3lt y+5+koA961p4g== Cc: netmod@ietf.org Subject: Re: [netmod] Susan Hares review of NETMOD documents X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 13:06:06 -0000 +1 David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Friday, September 06, 2013 2:18 AM > To: Susan Hares > Cc: 'Martin Bjorklund'; ietfdbh@comcast.net; netmod@ietf.org; > bclaise@cisco.com > Subject: Re: [netmod] Susan Hares review of NETMOD documents > > Susan, > > this YANG module is a YANG serialization of the registry, which is the > primary source of information. All of this will be maintained by IANA. > If some data is wrong or imprecise, it really needs to fixed in the > primary source, the IANA registry. In this case, I am behind Martin > since this is not derivative work that will have a life on its own. > > /js > > On Thu, Sep 05, 2013 at 01:45:03PM -0400, Susan Hares wrote: > > Martin: > > > > This is not a process message, but a technical review. > > > > As I have told many of my co-workers, It does not matter that you copied > it. > > If your name is on the RFC, you must know if it is right or wrong. > > > > On IANA data: > > I know that during the review of your document that IANA tries to find any > > past errors. IANA is careful and welcomes knowledge from the community > > about errors. > > > > During your review, you should inform IANA of any considerations such as > > errors. As a person doing OPS-DIR review, I believe that this portion of > > the record is inaccurate or imprecise. > > > > Does "DS1-MIB" refer toDS1-MIB is: RFC 4805, RFC3895 or RFC2495 or > something > > else. > > > > An example of something else is: > > Online: http://www.simpleweb.org/ietf/mibs/modules/IETF/txt/DS1-MIB > > > > -------------- > > RFC > > > > DS1-MIB DEFINITIONS ::= BEGIN > > > > IMPORTS > > MODULE-IDENTITY, OBJECT-TYPE, > > NOTIFICATION-TYPE, transmission > > FROM SNMPv2-SMI -- [RFC2578] > > DisplayString, TimeStamp, TruthValue > > FROM SNMPv2-TC -- [RFC2579] > > MODULE-COMPLIANCE, OBJECT-GROUP, > > NOTIFICATION-GROUP > > FROM SNMPv2-CONF -- [RFC2580] > > InterfaceIndex, ifIndex > > FROM IF-MIB -- [RFC2863] > > PerfCurrentCount, PerfIntervalCount, > > PerfTotalCount > > FROM PerfHist-TC-MIB; -- [RFC3593] > > > > ds1 MODULE-IDENTITY > > LAST-UPDATED "200703050000Z" > > ORGANIZATION "IETF AToM MIB Working Group" > > ========== > > > > Please attend to this to provide a better legacy than we currently have on > > these definitions. > > > > Sue > > > > > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > Sent: Thursday, September 05, 2013 1:22 PM > > To: ietfdbh@comcast.net > > Cc: shares@ndzh.com; j.schoenwaelder@jacobs-university.de; > netmod@ietf.org > > Subject: Re: [netmod] Susan Hares review of NETMOD documents > > > > Hi, > > > > "ietfdbh" wrote: > > > Hi Martin, > > > > > > I think Sue wants a reference for DS1-MIB in the g703at2mb enum. > > > > > > You have a reference clause in 2 of the 3 mentions of ds1-mib in the > > > description clause, such as > > > enum "ds1" { > > > value 18; > > > description > > > "DS1-MIB"; > > > reference > > > "RFC 4805 - Definitions of Managed Objects for t > > > DS1, J1, E1, DS2, and E2 Interface Types"; > > > } > > > > > > but not in this one: > > > enum "g703at2mb" { > > > value 67; > > > status obsolete; > > > description > > > "Obsolete see DS1-MIB"; > > > } > > > > > > > > > Looking at this raised a question for me: > > > The description clause for enum "ds1" is "DS1-MIB". > > > "DS1-MIB" is not a description of a ds1 interface. > > > I recommend changing the description to "see DS1-MIB." > > > > Ok. These descriptions are copied verbatim from the IANA registry, and I > am > > not sure it is a good idea to change the text in the YANG serialization of > > the registry. I do think it would be good with better descriptions, but > > they should probably be added to the IANA registry (and then of course > > copied to the YANG module). > > > > > > /martin > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Sep 16 00:54:07 2013 Return-Path: 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 8D8B121F9AB4 for ; Mon, 16 Sep 2013 00:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.017 X-Spam-Level: X-Spam-Status: No, score=-103.017 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pm-cbM3RywV0 for ; Mon, 16 Sep 2013 00:53:57 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4E90A21F9123 for ; Mon, 16 Sep 2013 00:53:54 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB20B20BC1; Mon, 16 Sep 2013 09:53:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zZuyk29_KUbD; Mon, 16 Sep 2013 09:53:50 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3DD1720B6C; Mon, 16 Sep 2013 09:53:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4B4D12856174; Mon, 16 Sep 2013 09:53:43 +0200 (CEST) Date: Mon, 16 Sep 2013 09:53:43 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20130916075343.GC68419@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20130904115758.GC53998@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130904115758.GC53998@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [netmod] WG Last Call draft-ietf-netmod-ip-cfg-10 (until 2013-09-18) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 07:54:07 -0000 Hi, this is a gentle reminder that we have another I-D in WG last call. Even if you just looked at the diff and you think the changes are OK, please let the chairs and/or the WG know. /js On Wed, Sep 04, 2013 at 01:57:58PM +0200, Juergen Schoenwaelder wrote: > Hi, > > I hereby like to start a WG last call for the document "A YANG Data > Model for IP Management": > > http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-10 > > Please indicate your support by Wednesday September 18th. We are not > only interested in receiving defect reports, we are equally interested > in statements of the form: > > "I have reviewed I-D XYZ and I found no issues" > "I have implemented the data model in I-D XYZ" > "I am implementing the data model in I-D XYZ" > "I am considering to implement the data model in I-D XYZ" > > This document already had WG last calls and it subsequently went > through IETF last call. Several issues were raised during IETF last > call and some of them required to be explicit how we deal with the > separation of configuration state and operational state. This version > of the I-D is believed to address the issues that were raised. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Mon Sep 16 07:22:16 2013 Return-Path: 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 9735311E8273 for ; Mon, 16 Sep 2013 07:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.505 X-Spam-Level: * X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALughJq-SIez for ; Mon, 16 Sep 2013 07:22:11 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 55D7011E8250 for ; Mon, 16 Sep 2013 07:22:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 6E55354032B for ; Mon, 16 Sep 2013 16:22:04 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NR98lfTtjSR2 for ; Mon, 16 Sep 2013 16:21:58 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id DAA2654000E for ; Mon, 16 Sep 2013 16:21:57 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: netmod@ietf.org Date: Mon, 16 Sep 2013 16:21:57 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [netmod] LL review of draft-ietf-netmod-ip-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 14:22:16 -0000 Hi, I read the draft and performed various tests and validity checks with the module. Both seem to be in a good shape. The requirement on splitting configuration and state data has been adequately addressed, and I think it is a significant improvement compared to the previous revision. I have three minor comments: 1. BSD-based Unix systems print IPv6 link-local addresses with explicit zone indices in the output of "ifconfig". Although it seems redundant there, this module could perhaps enable optional zone indices with IP addresses in the interfaces-state tree (not in config!) by changing the type of the "ip" leaf to inet:ipv[46]-address. 2. More enums might be needed in the "ip-address-origin" data type. For instance, an address prefix can be obtained from an IPv6 tunnel broker. Hopefully it will be possible to update this data type in a timely manner, or otherwise identities might be a better option. 3. The example in Appendix A should also show the link-local address of the "eth0" interface in state data. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Sep 16 08:44:45 2013 Return-Path: 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 30D7511E8112 for ; Mon, 16 Sep 2013 08:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qQfm6awL+09 for ; Mon, 16 Sep 2013 08:44:40 -0700 (PDT) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id A8E7B11E8299 for ; Mon, 16 Sep 2013 08:44:36 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 3so2920452qeb.17 for ; Mon, 16 Sep 2013 08:44:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=hmftPfypPKt1TyxUi3f/R773IcVMIBjAimTGejYBByE=; b=DFaQJU6xFJ2H60Wwk3E+GbF2cRETDppJtxQkB6UkCAh/rGaZFv5F6whbk/lNSNiaah xM4B9XW0Tv7FdFVbQ6RFdJNrKrcx9ZTifFcUHCPujBJRetNuV3Ye4NNK/x5ad2FZNjp8 gddrhNYCnep9MPhS1h97l8PF9F5DgYmUVXgCjcx8Tj8bH+f5NfRfzfdt8Mefbss93Ms8 7ulyEOWkYmhU4PfyeMFX+Cfo+RCAvlr3L9+LL1vRt+1hOy0FcIdZV36QQD1XrTlEAepP 0AQg/Nr+feaT2l3500WYD1iwipiMh/o1tCLzAmDbQxYJDlF8SyLsiFoKfCZRSU+XTLX/ nleA== X-Gm-Message-State: ALoCoQmFwxeke8j1q30C8wfbaVZ0/A/vXpcJHgI2H4f+2lQWHPwcu4oHJQVDhQmdcdtKTnRQgtud MIME-Version: 1.0 X-Received: by 10.224.130.72 with SMTP id r8mr31534qas.32.1379346275707; Mon, 16 Sep 2013 08:44:35 -0700 (PDT) Received: by 10.140.29.232 with HTTP; Mon, 16 Sep 2013 08:44:35 -0700 (PDT) Date: Mon, 16 Sep 2013 08:44:35 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a1132ec70c9390304e682140a Subject: [netmod] review of draft-ietf-netmod-ip-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 15:44:45 -0000 --001a1132ec70c9390304e682140a Content-Type: text/plain; charset=ISO-8859-1 Hi, I have reviewed this draft and it seems ready for publication. I am not convinced separation of per-interface config and state is a good idea wrt/ server resources and network bandwidth. Replicating all indexing on large tables introduces synchronization issues, e.g., finding out which configured addresses or neighbors are not being used in operational state. Why is there a "mandatory true" statement on a config=false node? Is this just a cut-and-paste bug from when the config=true nodes were cloned? (augment interface-state with /ipv6/address/prefix-length). There is no explanation. Why MUST this leaf be returned in every reply? IMO mandatory-stmt should be removed here. Andy --001a1132ec70c9390304e682140a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I have reviewed this draft and it s= eems ready for publication.

I am not convinced sep= aration of per-interface config and state
is a good idea wrt/ ser= ver resources and network bandwidth.
Replicating all indexing on large tables introduces synchronization
issues, e.g., finding out which configured addresses or
n= eighbors are not being used in operational state.

Why is there a "mandatory true" statement on a config=3Dfalse nod= e?
Is this just a cut-and-paste bug from when the config=3Dtrue n= odes were cloned?
(augment interface-state with =A0/ipv6/address/= prefix-length).
There is no explanation. =A0Why MUST this leaf be returned
i= n every reply? IMO mandatory-stmt should be removed here.



Andy

--001a1132ec70c9390304e682140a-- From andy@yumaworks.com Mon Sep 16 18:15:20 2013 Return-Path: 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 B749111E828B for ; Mon, 16 Sep 2013 18:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPufnFMg7mOQ for ; Mon, 16 Sep 2013 18:15:15 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4A93711E82CA for ; Mon, 16 Sep 2013 18:15:14 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id r5so3205536qcx.9 for ; Mon, 16 Sep 2013 18:15:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Ob+71thbA78F9Aeb06dVt+bPaX/7xQX2OrDbnFLBMMA=; b=Z/w6PM+5IAtTqt73bvo7duqQC5f4mH63s4pSWETz/yxtSw4xfFNDYuylZxrrsY9o03 OEnjm0qKKZvOaHzRevhpYsxm9HLtfx6RxDGODAz0HMHdYpz7XX/YcM5eim5c9D+Qtk+r vhLz51Oa+II/aUbYzaoGTb0xscPvlMRgQGo/ku/3TKnbhKAiGp8MsWDlXS9f6jSqh5h+ e75GuUsDnh4W87efbuyZUqZ0bBOMMOZT0pg1gqGSM1K9VnkCebP8wO23iRWlhBbAH4d5 /AFLaDHqvKO2J8fLkSDB6IEkF87oSycGZsVSot47F7n1azIbB4awgz24uqo5c79vy184 HM4w== X-Gm-Message-State: ALoCoQmr1oJ9yD4tKvawln+pWLCnIDp+J2Cj4ve48XW0b6pG1KIAFs5uEj0rLK3IqaNlbfrfiA7j MIME-Version: 1.0 X-Received: by 10.49.0.234 with SMTP id 10mr11541401qeh.67.1379380509811; Mon, 16 Sep 2013 18:15:09 -0700 (PDT) Received: by 10.140.29.232 with HTTP; Mon, 16 Sep 2013 18:15:09 -0700 (PDT) In-Reply-To: <20130917010924.30052.13344.idtracker@ietfa.amsl.com> References: <20130917010924.30052.13344.idtracker@ietfa.amsl.com> Date: Mon, 16 Sep 2013 18:15:09 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=047d7b33d2e44c386e04e68a0d76 Subject: [netmod] Fwd: New Version Notification for draft-bierman-netmod-yang-conformance-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 01:15:20 -0000 --047d7b33d2e44c386e04e68a0d76 Content-Type: text/plain; charset=ISO-8859-1 Hi, I raised issues with YANG conformance mechanisms in the past but the issue was tabled until somebody proposed a solution. I would like to un-table the issue and have the NETMOD WG address the YANG conformance issues raised in the draft. thanks, Andy ---------- Forwarded message ---------- From: Date: Mon, Sep 16, 2013 at 6:09 PM Subject: New Version Notification for draft-bierman-netmod-yang-conformance-00.txt To: Andy Bierman A new version of I-D, draft-bierman-netmod-yang-conformance-00.txt has been successfully submitted by Andy Bierman and posted to the IETF repository. Filename: draft-bierman-netmod-yang-conformance Revision: 00 Title: YANG Conformance Specification Creation date: 2013-09-16 Group: Individual Submission Number of pages: 38 URL: http://www.ietf.org/internet-drafts/draft-bierman-netmod-yang-conformance-00.txt Status: http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-conformance Htmlized: http://tools.ietf.org/html/draft-bierman-netmod-yang-conformance-00 Abstract: This document describes conformance specification and advertisement mechanisms for NETCONF servers implementing YANG data model modules. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --047d7b33d2e44c386e04e68a0d76 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I raised issues with YANG conforman= ce mechanisms in the past
but the issue was tabled until somebody= proposed a solution.
I would like to un-table the issue and have= the NETMOD WG address the
YANG conformance issues raised in the draft.

=
thanks,
Andy

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, Sep 16, 2013 at 6:09 PM
Subject: New Version Notification for= draft-bierman-netmod-yang-conformance-00.txt
To: Andy Bierman <andy@yumaworks.com>



A new version of I-D, draft-bierman-netmod-yang-conformance-00.txt
has been successfully submitted by Andy Bierman and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-bierman-netmod-yang-conformance
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 YANG Conformance Specification
Creation date: =A0 2013-09-16
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 38
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www= .ietf.org/internet-drafts/draft-bierman-netmod-yang-conformance-00.txt<= br> Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf= .org/doc/draft-bierman-netmod-yang-conformance
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/= draft-bierman-netmod-yang-conformance-00


Abstract:
=A0 =A0This document describes conformance specification and advertisement<= br> =A0 =A0mechanisms for NETCONF servers implementing YANG data model modules.=




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--047d7b33d2e44c386e04e68a0d76-- From mbj@tail-f.com Mon Sep 16 23:44:21 2013 Return-Path: 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 50E2011E821F for ; Mon, 16 Sep 2013 23:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5shDFqEjUoW7 for ; Mon, 16 Sep 2013 23:44:15 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8D311E8219 for ; Mon, 16 Sep 2013 23:44:15 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id C52151200434; Tue, 17 Sep 2013 08:44:12 +0200 (CEST) Date: Tue, 17 Sep 2013 08:44:12 +0200 (CEST) Message-Id: <20130917.084412.86909548561634237.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] LL review of draft-ietf-netmod-ip-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 06:44:21 -0000 Hi, Ladislav Lhotka wrote: > Hi, > > I read the draft and performed various tests and validity checks with > the module. Both seem to be in a good shape. > > The requirement on splitting configuration and state data has been > adequately addressed, and I think it is a significant improvement > compared to the previous revision. > > I have three minor comments: > > 1. BSD-based Unix systems print IPv6 link-local addresses with > explicit zone indices in the output of "ifconfig". Although it > seems redundant there, this module could perhaps enable > optional zone indices with IP addresses in the interfaces-state > tree (not in config!) by changing the type of the "ip" leaf to > inet:ipv[46]-address. It seems to me that this would be redundant, and if the purpose is to learn which zones exist and how they are mapped to interfaces, this is probably not the right place to do that. > 2. More enums might be needed in the "ip-address-origin" data > type. For instance, an address prefix can be obtained from an > IPv6 tunnel broker. Hopefully it will be possible to update > this data type in a timely manner, or otherwise identities > might be a better option. Currently, such an address would have an origin of 'other' (just like in the MIB). If more enums are needed they can be added, but they need to be implementable... > 3. The example in Appendix A should also show the link-local > address of the "eth0" interface in state data. Ok, I will add that! /martin From mbj@tail-f.com Mon Sep 16 23:47:21 2013 Return-Path: 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 8C4AD11E823C for ; Mon, 16 Sep 2013 23:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GMqLO0RNVeg for ; Mon, 16 Sep 2013 23:47:15 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8D56011E81C3 for ; Mon, 16 Sep 2013 23:47:15 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 770E81200434; Tue, 17 Sep 2013 08:47:05 +0200 (CEST) Date: Tue, 17 Sep 2013 08:47:05 +0200 (CEST) Message-Id: <20130917.084705.225236993182252744.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 06:47:21 -0000 Hi, Andy Bierman wrote: > Hi, > > I have reviewed this draft and it seems ready for publication. > > I am not convinced separation of per-interface config and state > is a good idea wrt/ server resources and network bandwidth. > Replicating all indexing on large tables introduces synchronization > issues, e.g., finding out which configured addresses or > neighbors are not being used in operational state. > > Why is there a "mandatory true" statement on a config=false node? > Is this just a cut-and-paste bug from when the config=true nodes were > cloned? > (augment interface-state with /ipv6/address/prefix-length). > There is no explanation. Why MUST this leaf be returned > in every reply? IMO mandatory-stmt should be removed here. Yes I think this is a copy-and-paste bug. The corresponding node for ipv4 is not mandatory. I will remove this statement. /martin > > > > Andy From lhotka@nic.cz Wed Sep 18 02:52:48 2013 Return-Path: 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 BE09911E821D for ; Wed, 18 Sep 2013 02:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.205 X-Spam-Level: X-Spam-Status: No, score=0.205 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNubRQtGrDCT for ; Wed, 18 Sep 2013 02:52:44 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4E66E11E81C1 for ; Wed, 18 Sep 2013 02:52:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 70FAA54032B for ; Wed, 18 Sep 2013 11:52:42 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyxfJrGTEy1P for ; Wed, 18 Sep 2013 11:52:39 +0200 (CEST) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 38FE8540010 for ; Wed, 18 Sep 2013 11:52:39 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: <20130917010924.30052.13344.idtracker@ietfa.amsl.com> User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: netmod@ietf.org Date: Wed, 18 Sep 2013 11:52:38 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] Fwd: New Version Notification for draft-bierman-netmod-yang-conformance-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 09:52:49 -0000 Hi, I think this is an important work that solves real problems. A few initial comments and questions: - What is the use for the "prefix" statement? - In the "ietf-routing-pkg" example, a device supporting both IPv4 and IPv6 would need another profile, right? - Regarding the "augment" variant of "require-conformance": Does it mean that the augmented module has to appear in another package with full conformance? - Could package advertisements be combined with the current single module advertisements? - Instead of "or" or "choice", I'd suggest to introduce statements indicating that a certain package/profile/module is incompatible with the one being defined. The rest can be achieved by defining multiple profiles. - Similarly, it is IMO not necessary to advertise alternative profiles. The server should advertise everything it supports and the client could then activate or deactivate desired parts by standard means such as presence containers or "enabled" switches. Lada Andy Bierman writes: > Hi, > > I raised issues with YANG conformance mechanisms in the past > but the issue was tabled until somebody proposed a solution. > I would like to un-table the issue and have the NETMOD WG address the > YANG conformance issues raised in the draft. > > > thanks, > Andy > > ---------- Forwarded message ---------- > From: > Date: Mon, Sep 16, 2013 at 6:09 PM > Subject: New Version Notification for > draft-bierman-netmod-yang-conformance-00.txt > To: Andy Bierman > > > > A new version of I-D, draft-bierman-netmod-yang-conformance-00.txt > has been successfully submitted by Andy Bierman and posted to the > IETF repository. > > Filename: draft-bierman-netmod-yang-conformance > Revision: 00 > Title: YANG Conformance Specification > Creation date: 2013-09-16 > Group: Individual Submission > Number of pages: 38 > URL: > http://www.ietf.org/internet-drafts/draft-bierman-netmod-yang-conformance-00.txt > Status: > http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-conformance > Htmlized: > http://tools.ietf.org/html/draft-bierman-netmod-yang-conformance-00 > > > Abstract: > This document describes conformance specification and advertisement > mechanisms for NETCONF servers implementing YANG data model modules. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jonathan@hansfords.net Wed Sep 18 05:38:07 2013 Return-Path: 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 553D311E8270 for ; Wed, 18 Sep 2013 05:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNYjzScmLIrt for ; Wed, 18 Sep 2013 05:38:02 -0700 (PDT) Received: from avasout04.plus.net (avasout04.plus.net [212.159.14.19]) by ietfa.amsl.com (Postfix) with ESMTP id 92D6811E8274 for ; Wed, 18 Sep 2013 05:38:00 -0700 (PDT) Received: from webmail.plus.net ([84.93.237.98]) by avasout04 with smtp id Scdy1m004283uBY01cdzMv; Wed, 18 Sep 2013 13:37:59 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=MqNrtQqe c=1 sm=1 tr=0 a=BJaFPv9AyABFDM2hXLRoEA==:117 a=MEK23cO9Z3nTrtfM1ievvA==:17 a=0Bzu9jTXAAAA:8 a=lxldWUwtbAkA:10 a=dYCPD3cKDi0A:10 a=nLU3T7cuX-oA:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=bSS5XIPxXqsA:10 a=48vgC7mUAAAA:8 a=xskcdSivAAAA:8 a=ZRqW5L__NB6SXVCZoYsA:9 a=I83SU0jACTB-XXeY:21 a=gCt_UlPp3zOAeiZk:21 a=QEXdDO2ut3YA:10 a=lZB815dzVvQA:10 a=ChEcuLpljosA:10 a=7QRSG0PsTcSwp9PvFtwA:9 a=U-MpDiDnUAUa_zok:21 a=dvkbAIEIUkTHaBEc:21 a=UUPdHDc_wC8rgGxk:21 a=_W_S_7VecoQA:10 X-AUTH: hansfords+us:2500 Received: from host-212-159-134-100.static.as13285.net ([212.159.134.100]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Wed, 18 Sep 2013 13:37:58 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_8661fd2a214b0eea3835261dbfa89172" Date: Wed, 18 Sep 2013 13:37:58 +0100 From: Jonathan Hansford To: Andy Bierman In-Reply-To: References: <20130917010924.30052.13344.idtracker@ietfa.amsl.com> Message-ID: <9957e6fe45c77a4d98fc54ac9bdb93e8@imap.plus.net> X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.4 X-Originating-IP: [212.159.134.100] Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: New Version Notification for draft-bierman-netmod-yang-conformance-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 12:38:24 -0000 --=_8661fd2a214b0eea3835261dbfa89172 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Hi, A few possible typo corrections (feel free to ignore as you see fit) plus a question: 1.1.3, module base: s/am/an 2.1.2, 2nd paragraph, 2nd sentence: delete 'that' 3.3, 3rd paragraph: s/insure/ensure 4.7, penultimate paragraph: s/same or before/same as or before 4.8, penultimate paragraph: s/same or after/same as or after 4.10: s/name of YANG feature/name of the YANG feature 5, 4th bullet: s/take/taken With ietf-netconf-pkg, is there a way of specifying a level of conformance for the with-defaults capability (i.e. which default-handling mode is required)? Jonathan On 2013-09-17 02:15, Andy Bierman wrote: > Hi, > I raised issues with YANG conformance mechanisms in the past > but the issue was tabled until somebody proposed a solution. > I would like to un-table the issue and have the NETMOD WG address the > YANG conformance issues raised in the draft. > > thanks, > Andy > > ---------- Forwarded message ---------- > From: > Date: Mon, Sep 16, 2013 at 6:09 PM > Subject: New Version Notification for draft-bierman-netmod-yang-conformance-00.txt > To: Andy Bierman > > A new version of I-D, draft-bierman-netmod-yang-conformance-00.txt > has been successfully submitted by Andy Bierman and posted to the > IETF repository. > > Filename: draft-bierman-netmod-yang-conformance > Revision: 00 > Title: YANG Conformance Specification > Creation date: 2013-09-16 > Group: Individual Submission > Number of pages: 38 > URL: http://www.ietf.org/internet-drafts/draft-bierman-netmod-yang-conformance-00.txt [3] > Status: http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-conformance [4] > Htmlized: http://tools.ietf.org/html/draft-bierman-netmod-yang-conformance-00 [5] > > Abstract: > This document describes conformance specification and advertisement > mechanisms for NETCONF servers implementing YANG data model modules. > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org [6]. > > The IETF Secretariat Links: ------ [1] mailto:internet-drafts@ietf.org [2] mailto:andy@yumaworks.com [3] http://www.ietf.org/internet-drafts/draft-bierman-netmod-yang-conformance-00.txt [4] http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-conformance [5] http://tools.ietf.org/html/draft-bierman-netmod-yang-conformance-00 [6] http://tools.ietf.org --=_8661fd2a214b0eea3835261dbfa89172 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi,

A few possible typo corrections (feel free to ignore as you see fit) plu= s a question:

1.1.3, module base: s/am/an

2.1.2, 2nd paragraph, 2nd sentence: delete 'that'

3.3, 3rd paragraph: s/insure/ensure

4.7, penultimate paragraph: s/same or before/same as or before

4.8, penultimate paragraph: s/same or after/same as or after

4.10: s/name of YANG feature/name of the YANG feature

5, 4th bullet: s/take/taken

With ietf-netconf-pkg, is there a way of specifying a level of conforman= ce for the with-defaults capability (i.e. which default-handling mode is re= quired)?

Jonathan

On 2013-09-17 02:15, Andy Bierman wrote:

Hi,
I raised issues with YANG conformance mechanisms in the past
but the issue was tabled until somebody proposed a solution.
I would like to un-table the issue and have the NETMOD WG address the<= /div>
YANG conformance issues raised in the draft.
thanks,
Andy

---------- Forwarded message ----------
Fro= m: <internet-drafts@ietf.org>
Da= te: Mon, Sep 16, 2013 at 6:09 PM
Subject: New Version Notification for= draft-bierman-netmod-yang-conformance-00.txt
To: Andy Bierman <andy@yumaworks.com>


A new version of I-D, draft-bierman-netmod-yang-conformance-00= =2Etxt
has been successfully submitted by Andy Bierman and posted to = the
IETF repository.

Filename:        = ;draft-bierman-netmod-yang-conformance
Revision:      =  00
Title:           YANG Conformance = Specification
Creation date:   2013-09-16
Group:   &n= bsp;       Individual Submission
Number of pages: 38 URL:             h= ttp://www.ietf.org/internet-drafts/draft-bierman-netmod-yang-conformance-00= =2Etxt
Status:          http://da= tatracker.ietf.org/doc/draft-bierman-netmod-yang-conformance
Html= ized:        http://tools.ietf.org/html/draft-bier= man-netmod-yang-conformance-00


Abstract:
 =  This document describes conformance specification and advertisement<= br />    mechanisms for NETCONF servers implementing YANG data mo= del modules.




Please note that it may take a c= ouple of minutes from the time of submission
until the htmlized versi= on and diff are available at tools.ietf= =2Eorg.

The IETF Secretariat

--=_8661fd2a214b0eea3835261dbfa89172-- From andy@yumaworks.com Wed Sep 18 08:35:17 2013 Return-Path: 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 F1FC011E823E for ; Wed, 18 Sep 2013 08:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDJ5MTY0ZVqD for ; Wed, 18 Sep 2013 08:35:12 -0700 (PDT) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7A911E8160 for ; Wed, 18 Sep 2013 08:35:12 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id j7so2983148qaq.19 for ; Wed, 18 Sep 2013 08:35:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=SsxLd84uAWWJ31C2HDYOyHHHWLs1NoszKANNUvq92bU=; b=I/Mh+sTqRVK7Y5l8Rop8uqQ6+D/bNAk8YfHPDl6tbMIBj2LlV0UDSS+R9D1kn09+sE WzybmJoYN1mr4JHgWYdZ78kVY5PQIoEG5dqUaV/JRJOcTGAmHkrdfJfjzzITMUJwE8HO 0WR1u/wzCwun8dXs9vbB/n/u04AmckCxUOKAG5QDGKgS6zgUHhwpn0uXEZeM7FQJsiZf wsZdf0ztNY37NeGSrcNX6c/hsf+YJYaEvQ/quEkuapkkd4lbAhYkhbPrCH8FqWg3QWes SgnGMAhhFYfr1c22UlNLaz4JXAYExPisNbcZ5t+XdI+aRYerO/91j3lo7m2qFajBix7n CAHg== X-Gm-Message-State: ALoCoQlWTvUPPXM3/wi8/rkjb0ME3Vb1NbUfnEL4b5pxonTnu2YBN94kVspBpDlVT0rspXmgjxgH MIME-Version: 1.0 X-Received: by 10.49.29.230 with SMTP id n6mr61223057qeh.20.1379518510721; Wed, 18 Sep 2013 08:35:10 -0700 (PDT) Received: by 10.140.26.209 with HTTP; Wed, 18 Sep 2013 08:35:10 -0700 (PDT) In-Reply-To: References: <20130917010924.30052.13344.idtracker@ietfa.amsl.com> Date: Wed, 18 Sep 2013 08:35:10 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=047d7bdc7a64cafd1f04e6aa2e35 Subject: Re: [netmod] Fwd: New Version Notification for draft-bierman-netmod-yang-conformance-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 15:35:17 -0000 --047d7bdc7a64cafd1f04e6aa2e35 Content-Type: text/plain; charset=ISO-8859-1 Hi, On Wed, Sep 18, 2013 at 2:52 AM, Ladislav Lhotka wrote: > Hi, > > I think this is an important work that solves real problems. A few initial > comments and questions: > > - What is the use for the "prefix" statement? > > none really. I guess it could be removed. It becomes the suggested prefix to use in XML encoding I suppose. The only purpose of the namespace URI is the advertisement. > - In the "ietf-routing-pkg" example, a device supporting both IPv4 and > IPv6 would need another profile, right? > > right - I will add that to the example > - Regarding the "augment" variant of "require-conformance": Does it mean > that the augmented module has to appear in another package with full > conformance? > no (!) This use-case is going to be complicated to support. The amount of mod-A needed to conform to mod-B is data-model-specific. The goal is to describe the required functionality with the tightest scope. E.g., what if mod-B augments a node that is within a feature in mod-A, not in mod-A base? Then "full compliance" to mod-A does not even help. What if mod-B adds 1 parameter to an rpc-stmt like "reboot"? Conformance to that profile does not require any monitoring or config objects from ietf-system.yang. However, you are making me think that "augment" is just another case of "ad-hoc", and not really needed at all. > - Could package advertisements be combined with the current single module > advertisements? > > Yes. The module URIs are still useful to derive the exact server schema tree. The conformance profiles just specify minimum requirements. The client still needs to know the exact modules+revisions+features actually implemented. - Instead of "or" or "choice", I'd suggest to introduce statements > indicating that a certain package/profile/module is incompatible with the > one being defined. The rest can be achieved by defining multiple profiles. > > I tried to make draft-00 simple, but I think there will be a need for choice-stmt to reduce cut-and-paste of profiles. > - Similarly, it is IMO not necessary to advertise alternative profiles. > The server should advertise everything it supports and the client could > then activate or deactivate desired parts by standard means such as > presence containers or "enabled" switches. > > The alternates do not have to be advertised, but changing profiles would reported in a netconf-capability-change notification. Lada > > Andy > Andy Bierman writes: > > > Hi, > > > > I raised issues with YANG conformance mechanisms in the past > > but the issue was tabled until somebody proposed a solution. > > I would like to un-table the issue and have the NETMOD WG address the > > YANG conformance issues raised in the draft. > > > > > > thanks, > > Andy > > > > ---------- Forwarded message ---------- > > From: > > Date: Mon, Sep 16, 2013 at 6:09 PM > > Subject: New Version Notification for > > draft-bierman-netmod-yang-conformance-00.txt > > To: Andy Bierman > > > > > > > > A new version of I-D, draft-bierman-netmod-yang-conformance-00.txt > > has been successfully submitted by Andy Bierman and posted to the > > IETF repository. > > > > Filename: draft-bierman-netmod-yang-conformance > > Revision: 00 > > Title: YANG Conformance Specification > > Creation date: 2013-09-16 > > Group: Individual Submission > > Number of pages: 38 > > URL: > > > http://www.ietf.org/internet-drafts/draft-bierman-netmod-yang-conformance-00.txt > > Status: > > http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-conformance > > Htmlized: > > http://tools.ietf.org/html/draft-bierman-netmod-yang-conformance-00 > > > > > > Abstract: > > This document describes conformance specification and advertisement > > mechanisms for NETCONF servers implementing YANG data model modules. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --047d7bdc7a64cafd1f04e6aa2e35 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,


On Wed, Sep 18, 2013 at 2:52 AM, Ladislav Lhotka <lhotka@nic.cz= > wrote:
Hi,

I think this is an important work that solves real problems. A few initial = comments and questions:

- What is the use for the "prefix" statement?


none really. =A0I guess it could be re= moved.
It becomes the suggested prefix to use in XML encoding I s= uppose.
The only purpose of the namespace URI is the <capabili= ty> advertisement.
=A0
- In the "ietf-routing-pkg" example, a device supporting both IPv= 4 and IPv6 would need another profile, right?


right - I will add that to the example=
=A0
- Regarding the "augment" variant of "require-conformance&qu= ot;: Does it mean that the augmented module has to appear in another packag= e with full conformance?

no (!)
This use-case is going to be complicated to support.
The amo= unt of mod-A needed to conform to mod-B is data-model-specific.
T= he goal is to describe the required functionality with the tightest scope.<= /div>
E.g., what if mod-B augments a node that is within a feature in mod-A,=
not in mod-A base? =A0Then "full compliance" to mod-A = does not even help.
What if mod-B adds 1 parameter to an rpc-stmt= like "reboot"? Conformance
to that profile does not require any monitoring or config objects from=
ietf-system.yang.

However, you are maki= ng me think that "augment" is just another case
of &quo= t;ad-hoc", and not really needed at all.



- Could package advertisements be combined with the current single module a= dvertisements?


Yes. The module URIs are still useful = to derive the exact server schema tree.
The conformance profiles = just specify minimum requirements. =A0The client still
needs to k= now the exact modules+revisions+features actually implemented.


- Instead of "or" or "choice", I'd suggest to intro= duce statements indicating that a certain package/profile/module is incompa= tible with the one being defined. The rest can be achieved by defining mult= iple profiles.


I tried to make draft-00 simple, but I= think there will be a need for choice-stmt
to reduce cut-and-pas= te of profiles.
=A0
- Similarly, it is IMO not necessary to advertise alternative profiles. The= server should advertise everything it supports and the client could then a= ctivate or deactivate desired parts by standard means such as presence cont= ainers or "enabled" switches.


The alternates do not have to be adver= tised, but changing profiles would reported
in a netconf-capabili= ty-change notification.


Lada


Andy

=A0
Andy Bierman <andy@yumaworks.com> writes:

> Hi,
>
> I raised issues with YANG conformance mechanisms in the past
> but the issue was tabled until somebody proposed a solution.
> I would like to un-table the issue and have the NETMOD WG address the<= br> > YANG conformance issues raised in the draft.
>
>
> thanks,
> Andy
>
> ---------- Forwarded message ----------
> From: <internet-drafts@= ietf.org>
> Date: Mon, Sep 16, 2013 at 6:09 PM
> Subject: New Version Notification for
> draft-bierman-netmod-yang-conformance-00.txt
> To: Andy Bierman <andy@yumawo= rks.com>
>
>
>
> A new version of I-D, draft-bierman-netmod-yang-conformance-00.txt
> has been successfully submitted by Andy Bierman and posted to the
> IETF repository.
>
> Filename: =A0 =A0 =A0 =A0draft-bierman-netmod-yang-conformance
> Revision: =A0 =A0 =A0 =A000
> Title: =A0 =A0 =A0 =A0 =A0 YANG Conformance Specification
> Creation date: =A0 2013-09-16
> Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
> Number of pages: 38
> URL:
> http://www.ietf.org/internet-draft= s/draft-bierman-netmod-yang-conformance-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-bierman= -netmod-yang-conformance
> Htmlized:
> http://tools.ietf.org/html/draft-bierman-netmod= -yang-conformance-00
>
>
> Abstract:
> =A0 =A0This document describes conformance specification and advertise= ment
> =A0 =A0mechanisms for NETCONF servers implementing YANG data model mod= ules.
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--047d7bdc7a64cafd1f04e6aa2e35-- From lhotka@nic.cz Wed Sep 18 09:09:25 2013 Return-Path: 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 662A611E8273 for ; Wed, 18 Sep 2013 09:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[AWL=1.102, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oo7fXerUinXr for ; Wed, 18 Sep 2013 09:09:21 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D059B11E8124 for ; Wed, 18 Sep 2013 09:09:20 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 6EA3213F681; Wed, 18 Sep 2013 18:09:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1379520558; bh=k8ba4eTMz7MlqHTeO0UNlGQu7UIpWjCKWgvlmhjw5Sg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=fAYlwEhz8zbjurVNvKrEGjZkoD78QCeg5duIteQVWC+31CaBLu8RrUsBZIapqwdm9 oYbi5hwx2kqv0QUrf85/nfXV5yHp5nzfalF/TBNdJemCUNh2EgN7UVE6kLV5+InF7T 8lgGw3s8MLa7kse/GeiFLoqeiGCcgxMK/IBzNwCg= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 18 Sep 2013 18:09:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <29677E9A-CE36-4FF6-A0F0-7972087668D2@nic.cz> References: <20130917010924.30052.13344.idtracker@ietfa.amsl.com> To: Andy Bierman X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" Subject: Re: [netmod] Fwd: New Version Notification for draft-bierman-netmod-yang-conformance-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 16:09:25 -0000 On Sep 18, 2013, at 5:35 PM, Andy Bierman wrote: > - Regarding the "augment" variant of "require-conformance": Does it = mean that the augmented module has to appear in another package with = full conformance? >=20 > no (!) > This use-case is going to be complicated to support. > The amount of mod-A needed to conform to mod-B is data-model-specific. > The goal is to describe the required functionality with the tightest = scope. > E.g., what if mod-B augments a node that is within a feature in mod-A, > not in mod-A base? Then "full compliance" to mod-A does not even = help. > What if mod-B adds 1 parameter to an rpc-stmt like "reboot"? = Conformance > to that profile does not require any monitoring or config objects from > ietf-system.yang. Hmm=85 So, if mod-B augments node X in mod-A, what is the server = actually required to implement? X and all its enclosing containers? What = if the enclosing containers have other mandatory nodes? Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Wed Sep 18 09:09:56 2013 Return-Path: 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 4415411E8256 for ; Wed, 18 Sep 2013 09:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSllmGPhMNGY for ; Wed, 18 Sep 2013 09:09:52 -0700 (PDT) Received: from mail-qe0-f41.google.com (mail-qe0-f41.google.com [209.85.128.41]) by ietfa.amsl.com (Postfix) with ESMTP id A511B11E8126 for ; Wed, 18 Sep 2013 09:09:49 -0700 (PDT) Received: by mail-qe0-f41.google.com with SMTP id 1so449728qee.0 for ; Wed, 18 Sep 2013 09:09:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=noS5+KyeIOheYqhIIflw/Q0Rh8Bbc3Az00GmlbIAlWI=; b=TTvLIAvOKuySMy8BEQQ+m/HO18v1WV/TM7gfmEiTbE1gIatGcPdeYRE9chCR9xrSNx 59Nl98OZttIcTu/5F3f/6La1LOXwCN5zkvzXc34vRk27qGJ0+qwy0pzaLhigmADorqMT M/+aZ5vJbigp081OFfIhN9kvf+7lPCp5xOz3L6Kxut6QanCZ1v8MlKCpqyAyXDSicJWP AY/8nRnN7e7H67UQA3q7bSYedx4J5Wnf3/pYqVB8dZgPOImZlQPYpyNN41RJVp3QEGBc VxbxpEcWzD8gO8ZGcqFffx7V4ypHAv9N+RJBHlWtCUQMvWIAS/hLLmjEpeJkYXJH8NtO acuw== X-Gm-Message-State: ALoCoQmelv3HZsn+M8nmipn+i3wmY89xbu7dELZiF+pARkrX4uyqLkrBctzBqCMl8oBNcf1GaUOd MIME-Version: 1.0 X-Received: by 10.224.14.82 with SMTP id f18mr15361052qaa.58.1379520588970; Wed, 18 Sep 2013 09:09:48 -0700 (PDT) Received: by 10.140.26.209 with HTTP; Wed, 18 Sep 2013 09:09:48 -0700 (PDT) In-Reply-To: <9957e6fe45c77a4d98fc54ac9bdb93e8@imap.plus.net> References: <20130917010924.30052.13344.idtracker@ietfa.amsl.com> <9957e6fe45c77a4d98fc54ac9bdb93e8@imap.plus.net> Date: Wed, 18 Sep 2013 09:09:48 -0700 Message-ID: From: Andy Bierman To: Jonathan Hansford Content-Type: multipart/alternative; boundary=047d7bdc80f8aa981204e6aaaaa1 Cc: "netmod@ietf.org" Subject: Re: [netmod] Fwd: New Version Notification for draft-bierman-netmod-yang-conformance-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 16:09:56 -0000 --047d7bdc80f8aa981204e6aaaaa1 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 18, 2013 at 5:37 AM, Jonathan Hansford wrote: > ** > > Hi, > > A few possible typo corrections (feel free to ignore as you see fit) plus > a question: > > 1.1.3, module base: s/am/an > > 2.1.2, 2nd paragraph, 2nd sentence: delete 'that' > > 3.3, 3rd paragraph: s/insure/ensure > > 4.7, penultimate paragraph: s/same or before/same as or before > > 4.8, penultimate paragraph: s/same or after/same as or after > > 4.10: s/name of YANG feature/name of the YANG feature > > 5, 4th bullet: s/take/taken > thanks -- I will fix these in -01 > With ietf-netconf-pkg, is there a way of specifying a level of conformance > for the with-defaults capability (i.e. which default-handling mode is > required)? > I thought of that,, and left it out of -00 to keep it simpler. There is no "require-parameter" sub-statement for "require-capability". Something like that may be needed. > Jonathan > Andy > On 2013-09-17 02:15, Andy Bierman wrote: > > Hi, > I raised issues with YANG conformance mechanisms in the past > but the issue was tabled until somebody proposed a solution. > I would like to un-table the issue and have the NETMOD WG address the > YANG conformance issues raised in the draft. > thanks, > Andy > > ---------- Forwarded message ---------- > From: > Date: Mon, Sep 16, 2013 at 6:09 PM > Subject: New Version Notification for > draft-bierman-netmod-yang-conformance-00.txt > To: Andy Bierman > > > > A new version of I-D, draft-bierman-netmod-yang-conformance-00.txt > has been successfully submitted by Andy Bierman and posted to the > IETF repository. > > Filename: draft-bierman-netmod-yang-conformance > Revision: 00 > Title: YANG Conformance Specification > Creation date: 2013-09-16 > Group: Individual Submission > Number of pages: 38 > URL: > http://www.ietf.org/internet-drafts/draft-bierman-netmod-yang-conformance-00.txt > Status: > http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-conformance > Htmlized: > http://tools.ietf.org/html/draft-bierman-netmod-yang-conformance-00 > > > Abstract: > This document describes conformance specification and advertisement > mechanisms for NETCONF servers implementing YANG data model modules. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > --047d7bdc80f8aa981204e6aaaaa1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Sep 18, 2013 at 5:37 AM, Jonathan Hansford <Jonathan@= hansfords.net> wrote:

Hi,

A few possible typo corrections (feel free to ignore as you see fit) plu= s a question:

1.1.3, module base: s/am/an

2.1.2, 2nd paragraph, 2nd sentence: delete 'that'

3.3, 3rd paragraph: s/insure/ensure

4.7, penultimate paragraph: s/same or before/same as or before

4.8, penultimate paragraph: s/same or after/same as or after

4.10: s/name of YANG feature/name of the YANG feature

5, 4th bullet: s/take/taken


th= anks -- I will fix these in -01
=A0

With ietf-netconf-pkg, is there a way of specifying a level of conforman= ce for the with-defaults capability (i.e. which default-handling mode is re= quired)?


I thought of that,, and = left it out of -00 to keep it simpler.
There is no "require-parameter" sub-statement for "requ= ire-capability".
Something like that may be needed.
=A0

Jonathan


Andy
=A0

On 2013-09-17 02:15, Andy Bierman wrote:

Hi,
I raised issues with YANG conformance mechanisms in the past
but the issue was tabled until somebody proposed a solution.
I would like to un-table the issue and have the NETMOD WG address the<= /div>
YANG conformance issues raised in the draft.
thanks,
Andy

---------- Forwarded message ----------
From:= <internet-drafts@ietf.org>=
Date: Mon, Sep 16, 2013 at 6:09 PM
Subject: New Version Notification fo= r draft-bierman-netmod-yang-conformance-00.txt
To: Andy Bierman <andy@yumaworks.com&= gt;



A new version of I-D, draft-bierman-netmod-yang-conformance-00= .txt
has been successfully submitted by Andy Bierman and posted to the<= br> IETF repository.

Filename: =A0 =A0 =A0 =A0draft-bierman-netmod-= yang-conformance
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 YANG Conformanc= e Specification
Creation date: =A0 2013-09-16
Group: =A0 =A0 =A0 = =A0 =A0 Individual Submission
Number of pages: 38
URL: =A0 =A0 =A0 = =A0 =A0 =A0 http://www.ietf.org/interne= t-drafts/draft-bierman-netmod-yang-conformance-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.iet= f.org/doc/draft-bierman-netmod-yang-conformance
Htmlized: =A0 =A0 = =A0 =A0http://tools.ietf.org/html/draft-bierman-netm= od-yang-conformance-00


Abstract:
=A0 =A0This document describes conformance specifica= tion and advertisement
=A0 =A0mechanisms for NETCONF servers implementi= ng YANG data model modules.




Please note that it may tak= e a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secreta= riat


--047d7bdc80f8aa981204e6aaaaa1-- From andy@yumaworks.com Wed Sep 18 09:15:17 2013 Return-Path: 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 99E8411E8124 for ; Wed, 18 Sep 2013 09:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.796 X-Spam-Level: X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kaNcP3Wv-oA for ; Wed, 18 Sep 2013 09:15:12 -0700 (PDT) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) by ietfa.amsl.com (Postfix) with ESMTP id 8063E11E8285 for ; Wed, 18 Sep 2013 09:15:10 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id v2so4641976qcr.34 for ; Wed, 18 Sep 2013 09:15:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4JMuOo6A/jiNWdzm63CSW6XLbwLlh7s9AlppeICPEJI=; b=crLsF/buL17r8VTybXrE+SsdKIeKjdUA/ecPVeS+n9eWhwI02pYMST72ovqPBXgOBJ 3tDGpD1p7SJdU4TAl02hHHQ94BoP/Jyiz+IgEQhzKuHQjVhxF4X2C1AtA9A9DayhxxxZ YhO9CD+mCF0eXQNy9i3e3z+uJapE4MUD21JmfUS10UtNxAn0vNOKhTSnZUP279SZf9w9 gvotPoxxkldqG/fzB6opqmHS1fUDM2f5Y63b+Ej8GUXcEgNSRw9Lu4/oewCeXn2j+TAr jCfm8Meog7Mn02DHfQkYW3UlMwdnYYkGVd+2m5RzWw1hF1gUFqVOFnU57g/yqzZC1Dt5 LcSA== X-Gm-Message-State: ALoCoQnfe261aMUSykyGU50x7QnOXXpXN2LFZb/ZGjLzocju7TxzR89UL6JPfkH4c1HQk62NRKHK MIME-Version: 1.0 X-Received: by 10.224.80.134 with SMTP id t6mr15831420qak.48.1379520909875; Wed, 18 Sep 2013 09:15:09 -0700 (PDT) Received: by 10.140.26.209 with HTTP; Wed, 18 Sep 2013 09:15:09 -0700 (PDT) In-Reply-To: <29677E9A-CE36-4FF6-A0F0-7972087668D2@nic.cz> References: <20130917010924.30052.13344.idtracker@ietfa.amsl.com> <29677E9A-CE36-4FF6-A0F0-7972087668D2@nic.cz> Date: Wed, 18 Sep 2013 09:15:09 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1132e232cb298d04e6aabda6 Cc: "netmod@ietf.org" Subject: Re: [netmod] Fwd: New Version Notification for draft-bierman-netmod-yang-conformance-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 16:15:17 -0000 --001a1132e232cb298d04e6aabda6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Sep 18, 2013 at 9:09 AM, Ladislav Lhotka wrote: > > On Sep 18, 2013, at 5:35 PM, Andy Bierman wrote: > > > - Regarding the "augment" variant of "require-conformance": Does it mea= n > that the augmented module has to appear in another package with full > conformance? > > > > no (!) > > This use-case is going to be complicated to support. > > The amount of mod-A needed to conform to mod-B is data-model-specific. > > The goal is to describe the required functionality with the tightest > scope. > > E.g., what if mod-B augments a node that is within a feature in mod-A, > > not in mod-A base? Then "full compliance" to mod-A does not even help. > > What if mod-B adds 1 parameter to an rpc-stmt like "reboot"? Conformanc= e > > to that profile does not require any monitoring or config objects from > > ietf-system.yang. > > Hmm=85 So, if mod-B augments node X in mod-A, what is the server actually > required to implement? X and all its enclosing containers? What if the > enclosing containers have other mandatory nodes? > > The server would have to implement the parent nodes of the augmented node correctly. YANG validation requirements are 1 thing. Conformance profile requirements are another. > Lada > > Andy > > --001a1132e232cb298d04e6aabda6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Wed, Sep 18, 2013 at 9:09 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On Sep 18, 2013, at 5:35 PM, Andy Bierman <andy@yumaworks.com> wrote:

> - Regarding the "augment" variant of "require-conforman= ce": Does it mean that the augmented module has to appear in another p= ackage with full conformance?
>
> no (!)
> This use-case is going to be complicated to support.
> The amount of mod-A needed to conform to mod-B is data-model-specific.=
> The goal is to describe the required functionality with the tightest s= cope.
> E.g., what if mod-B augments a node that is within a feature in mod-A,=
> not in mod-A base? =A0Then "full compliance" to mod-A does n= ot even help.
> What if mod-B adds 1 parameter to an rpc-stmt like "reboot"?= Conformance
> to that profile does not require any monitoring or config objects from=
> ietf-system.yang.

Hmm=85 So, if mod-B augments node X in mod-A, what is the server actually r= equired to implement? X and all its enclosing containers? What if the enclo= sing containers have other mandatory nodes?


The server would have to implement the= parent nodes of the augmented
node correctly. YANG validation re= quirements are 1 thing. =A0Conformance
profile requirements are a= nother.
=A0
Lada


Andy




--001a1132e232cb298d04e6aabda6-- From andy@yumaworks.com Wed Sep 18 12:45:36 2013 Return-Path: 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 AAFA611E8121 for ; Wed, 18 Sep 2013 12:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.826 X-Spam-Level: X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZK4tisnO+BW for ; Wed, 18 Sep 2013 12:45:31 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2853F11E8135 for ; Wed, 18 Sep 2013 12:45:25 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id c3so4859669qcv.4 for ; Wed, 18 Sep 2013 12:45:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=uKpYmKNTyYjQLbobrFqr1cCv0D5zFgn4SN4vKYWdx2Y=; b=QGVpP+Rrd+WDrhUbnBXIXVdhB9IJ0QKcyfWtJqgX3TJMyGcIoajvu8GRakBjSm8OOt LOFGrWXPxiRpVWz00TSlULntptRwtBxkCU3yNEqNOal8/LJelNXAB475xZZLOJAlBeN8 9SvE0za16kHSdoI9yOWWLgrr6JI0yA5YUSlmiWOK0QkL54CTRIlfjeCNxiSv3MYxBLd5 9i0eyMv9H7IXOROQoKva/2GixUdtlD/g2Nanl23hoDMkgC8Q5TpgWzVzlyY8blqY9lJl LYAeb/VGbA8qq3IsHEQX9cRK1alR8ur2tX2nEtAz+iyDoMeI/iYjygjfVTWPzzyumXR2 +37Q== X-Gm-Message-State: ALoCoQml6ej16V++Y/ISfMtTNlRErPF4y9E3TcPnmcYlP9i4/vU249TQW6g5o7SBHinMbYXbXnW6 MIME-Version: 1.0 X-Received: by 10.229.251.201 with SMTP id mt9mr5903452qcb.26.1379533521220; Wed, 18 Sep 2013 12:45:21 -0700 (PDT) Received: by 10.140.26.209 with HTTP; Wed, 18 Sep 2013 12:45:21 -0700 (PDT) In-Reply-To: <20130918194309.18627.34853.idtracker@ietfa.amsl.com> References: <20130918194309.18627.34853.idtracker@ietfa.amsl.com> Date: Wed, 18 Sep 2013 12:45:21 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a1134a8e27d08a904e6adadd4 Subject: [netmod] Fwd: I-D Action: draft-bierman-netmod-yang-conformance-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 19:45:36 -0000 --001a1134a8e27d08a904e6adadd4 Content-Type: text/plain; charset=ISO-8859-1 FYI, I updated the YANG conformance draft based on comments from Lada and Jonathan. Andy ---------- Forwarded message ---------- From: Date: Wed, Sep 18, 2013 at 12:43 PM Subject: I-D Action: draft-bierman-netmod-yang-conformance-01.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : YANG Conformance Specification Author(s) : Andy Bierman Filename : draft-bierman-netmod-yang-conformance-01.txt Pages : 39 Date : 2013-09-18 Abstract: This document describes conformance specification and advertisement mechanisms for NETCONF servers implementing YANG data model modules. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bierman-netmod-yang-conformance There's also a htmlized version available at: http://tools.ietf.org/html/draft-bierman-netmod-yang-conformance-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-bierman-netmod-yang-conformance-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --001a1134a8e27d08a904e6adadd4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
FYI,

I updated the YANG conformance= draft based on comments from
Lada and Jonathan.

Andy


---------- Forwa= rded message ----------
From: <internet-drafts@ietf.org>
= Date: Wed, Sep 18, 2013 at 12:43 PM
Subject: I-D Action: draft-bierman-n= etmod-yang-conformance-01.txt
To: i-d-announce@ietf.org
<= br>

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : YANG Conformance Specification<= br> =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Andy Bierman
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-bierman-netmod-yang-conform= ance-01.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 39
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-09-18

Abstract:
=A0 =A0This document describes conformance specification and advertisement<= br> =A0 =A0mechanisms for NETCONF servers implementing YANG data model modules.=


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bierman-ne= tmod-yang-conformance

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bierman-netmod-yang= -conformance-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-bie= rman-netmod-yang-conformance-01


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--001a1134a8e27d08a904e6adadd4-- From alex@cisco.com Sun Sep 22 02:10:09 2013 Return-Path: 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 589C021F9F0E for ; Sun, 22 Sep 2013 02:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fp-LFW5kKt3r for ; Sun, 22 Sep 2013 02:10:04 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 957AA21F9EF2 for ; Sun, 22 Sep 2013 02:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2866; q=dns/txt; s=iport; t=1379840992; x=1381050592; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=gUzxCAMUDe6ZSJFA7CgQ1uvgsHwxs31GlMO5JDnSnd8=; b=knxuoA2/t3IeYhmzrFNCLT3xHKRLW3EfuZIqsXjPLGf+JAxEP3e1vqir vTqI9/RGvy5CDy0s5z9K/mWA8YJ0PoFwUfp/PBE6qtSJoJPtAiUJkxqWH to8CjcxCWrYcZE7v+HRFNOsBthNJDb2qAs5P+XPjCLt9y+HQ83XqJXl/r U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAEGzPlKtJXG+/2dsb2JhbABZgwc4TAaDKb4GF3wWdIIlAQEBBCMRRQwGARkEAQEDAgYdAwIEMBQBCAkBBAENBQgBh3wHBad9kXKBKY4LMQ2CYzWBAAOZK5BIgySCKg X-IronPort-AV: E=Sophos;i="4.90,955,1371081600"; d="scan'208";a="262950006" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 22 Sep 2013 09:09:52 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8M99puB014636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 Sep 2013 09:09:51 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.100]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Sun, 22 Sep 2013 04:09:51 -0500 From: "Alexander Clemm (alex)" To: "netmod@ietf.org" , "Juergen Schoenwaelder (j.schoenwaelder@jacobs-university.de)" , "David Kessens (david.kessens@gmail.com)" Thread-Topic: New version of netmod mount draft Thread-Index: Ac63cplYNP9M0Q9XTh+/klUryyHyxg== Date: Sun, 22 Sep 2013 09:09:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.251.241] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [netmod] New version of netmod mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 09:10:09 -0000 SGVsbG8sDQoNCkp1c3QgYXMgYW4gRllJLCB3ZSBoYXZlIGp1c3QgcG9zdGVkIGEgbmV3IHJldmlz aW9uIG9mIGRyYWZ0LWNsZW1tLW5ldG1vZC1tb3VudC4gIFRoZSByZXZpc2lvbnMgYXJlIG1pbm9y IGluIG5hdHVyZSBhbmQgY29udGFpbiBmb3IgdGhlIG1vc3QgcGFydCBhZGRpdGlvbmFsIGNsYXJp ZmljYXRpb25zIGFyb3VuZCB0aGUgY29uY2VwdCBvZiBhdHRhY2hpbmcgZGF0YSBmcm9tIHJlbW90 ZSBkYXRhIHN0b3JlcyBpbnRvIGEgbG9jYWwgZGF0YSBzdG9yZXMgYW5kIHJlZ2FyZGluZyBob3cg dGhlIG1vdW50IHBvaW50cyB3aWxsIGJlIG1hbmFnZWQuICBXZSBob3BlIHRvIGhhdmUgYSB0aW1l IHNsb3QgaW4gVmFuY291dmVyIGZvciBhIGJyaWVmIHByZXNlbnRhdGlvbiBhbmQgZGlzY3Vzc2lv bi4gIA0KDQpLaW5kIHJlZ2FyZHMNCi0tLSBBbGV4LCBKYW4sIEVyaWMNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBTdW5kYXksIFNlcHRlbWJlciAyMiwgMjAx MyAyOjAxIEFNDQpUbzogQWxleGFuZGVyIENsZW1tIChhbGV4KTsgRXJpYyBWb2l0IChldm9pdCk7 IEphbiBNZWR2ZWQgKGptZWR2ZWQpOyBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpDQpTdWJqZWN0OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWNsZW1tLW5ldG1vZC1tb3VudC0wMS50 eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtY2xlbW0tbmV0bW9kLW1vdW50LTAx LnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEFsZXhhbmRlciBDbGVtbSBh bmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtY2xl bW0tbmV0bW9kLW1vdW50DQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBNb3VudGluZyBZQU5HLURl ZmluZWQgSW5mb3JtYXRpb24gZnJvbSBSZW1vdGUgRGF0YXN0b3Jlcw0KQ3JlYXRpb24gZGF0ZToJ IDIwMTMtMDktMjINCkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBh Z2VzOiAyOQ0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1jbGVtbS1uZXRtb2QtbW91bnQtMDEudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY2xlbW0tbmV0bW9kLW1vdW50DQpI dG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNsZW1tLW5l dG1vZC1tb3VudC0wMQ0KRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1jbGVtbS1uZXRtb2QtbW91bnQtMDENCg0KQWJzdHJhY3Q6DQogICBUaGlz IGRvY3VtZW50IGludHJvZHVjZXMgYSBuZXcgY2FwYWJpbGl0eSB0aGF0IGFsbG93cyBZQU5HIGRh dGFzdG9yZXMNCiAgIHRvIHJlZmVyZW5jZSBhbmQgaW5jb3Jwb3JhdGUgaW5mb3JtYXRpb24gZnJv bSByZW1vdGUgZGF0YXN0b3Jlcy4NCiAgIFRoaXMgaXMgYWNjb21wbGlzaGVkIHVzaW5nIGEgbmV3 IFlBTkcgZGF0YSBtb2RlbCB0aGF0IGFsbG93cyB0bw0KICAgZGVmaW5lIGFuZCBtYW5hZ2UgZGF0 YXN0b3JlIG1vdW50IHBvaW50cyB0aGF0IHJlZmVyZW5jZSBkYXRhIG5vZGVzIGluDQogICByZW1v dGUgZGF0YXN0b3Jlcy4gIFRoZSBkYXRhIG1vZGVsIGluY2x1ZGVzIGEgc2V0IG9mIFlBTkcgZXh0 ZW5zaW9ucw0KICAgZm9yIHRoZSBwdXJwb3NlcyBvZiBkZWNsYXJpbmcgc3VjaCBtb3VudCBwb2lu dHMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9u IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9v bHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From lhotka@nic.cz Mon Sep 23 08:33:29 2013 Return-Path: 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 31E4821F938E for ; Mon, 23 Sep 2013 08:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.264 X-Spam-Level: X-Spam-Status: No, score=-1.264 tagged_above=-999 required=5 tests=[AWL=0.735, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLQ-QPTK1P7c for ; Mon, 23 Sep 2013 08:33:28 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 32E7F21F9385 for ; Mon, 23 Sep 2013 08:33:27 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 7966413F9F1 for ; Mon, 23 Sep 2013 17:33:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1379950406; bh=eV4XUgpEW7pPO7ZKv+5H03TudwQ+iV9JWKk7efrqisc=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: References:To:Message-Id:Mime-Version; b=eyCM+SdmBiMn4sL/dsmtC9nGdn7cQtrvz6oRT++o/uHYGsCxH/902kj1WvAp9hCcZ ZNyfigmBblZtfuPkKLHTE8sIf3Gm9SmIi6dGALZuxQdDE1dhAX1Qt6r1f3vxPwZzMI ytenBBrsVBq9txLdyvL1VNVxZgNK8Q+CpaTmPUDI= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Sep 2013 17:33:26 +0200 References: <20130923152837.32168.80619.idtracker@ietfa.amsl.com> To: netmod@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Subject: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-json-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 15:33:29 -0000 Hi, this revision of JSON mapping document clarifies several issues, mainly = based on Andy's feedback. Several new examples appear in the text, and = appendix A contains a complete translation of the reply from = appendix D of draft-ietf-netmod-interfaces-cfg-12. Lada Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-lhotka-netmod-yang-json-02.txt > Date: September 23, 2013 5:28:37 PM GMT+02:00 > To: Ladislav Lhotka >=20 >=20 > A new version of I-D, draft-lhotka-netmod-yang-json-02.txt > has been successfully submitted by Ladislav Lhotka and posted to the > IETF repository. >=20 > Filename: draft-lhotka-netmod-yang-json > Revision: 02 > Title: Modeling JSON Text with YANG > Creation date: 2013-09-23 > Group: Individual Submission > Number of pages: 19 > URL: = http://www.ietf.org/internet-drafts/draft-lhotka-netmod-yang-json-02.txt > Status: = http://datatracker.ietf.org/doc/draft-lhotka-netmod-yang-json > Htmlized: = http://tools.ietf.org/html/draft-lhotka-netmod-yang-json-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-lhotka-netmod-yang-json-02 >=20 > Abstract: > This document defines rules for presenting configuration and > operational state data defined using YANG as JSON text. It does so > by specifying a procedure for translating the subset of YANG- > compatible XML documents to JSON text, and vice versa. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From bertietf@bwijnen.net Tue Sep 24 02:43:24 2013 Return-Path: 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 93C4421F9E46 for ; Tue, 24 Sep 2013 02:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulVWXvdZBI9Q for ; Tue, 24 Sep 2013 02:43:18 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 4C85921E8053 for ; Tue, 24 Sep 2013 02:43:18 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VOP9E-00012U-8K for netmod@ietf.org; Tue, 24 Sep 2013 11:43:16 +0200 Received: from kitten.ripe.net ([193.0.1.240] helo=[IPv6:::1]) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1VOP9E-0000ap-5z for netmod@ietf.org; Tue, 24 Sep 2013 11:43:12 +0200 Message-ID: <52415EAB.3070406@bwijnen.net> Date: Tue, 24 Sep 2013 11:43:07 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20130924 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4498da6135c01cc581e26f067268a03ab Subject: Re: [netmod] Review request: WG Last Call draft-ietf-netmod-ip-cfg-10 (until 2013-09-18)] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 09:43:24 -0000 Sorry for being late. I have re-reviewed draft-ietf-netmod-ip-cfg-10.txt and I think it is in good shape and ready for publication as standards track RFC. Bert Wijnen