From nobody Tue Jul 1 13:11:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D001B28A6 for ; Tue, 1 Jul 2014 13:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHR12SdwuV-b for ; Tue, 1 Jul 2014 13:11:28 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DF231B28AE for ; Tue, 1 Jul 2014 13:11:28 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id v10so8014105qac.18 for ; Tue, 01 Jul 2014 13:11:27 -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=h/WMJ7iGJPltr13Crvoj9Iu68kFNxpf77KYC2KPBx9o=; b=eG/GVRwZkeZKMtNmfOgEUTHX62MdjLBGrZShpIlnhmmYufXyTn0NdYEHcZJmhRJmrC rykg2muMD/dwxB/xbJumAnwEvdJYs1aMOXBLQTv97ZmkzqTnYglwj+AJRoeRVspkBVuK YcmVsK5mwPQ8AWQ2mc8eThh44tfHQmDbjMbCiJv62bQi9HHnwob9dTXv6vekozjSO1ab e2dlq84VaA/xkbuijTmqgbQhhajkse0/+uMnwbiz7Q5KFhvmFyA5OuAGtV5d02Psu3Vi xjCL8sfxV2HcqpyxuCvoKCNpfssIYFcbKL1fRXdpCSs/cFYeVmz9jOkXWT3J/wO4tY7Y DIow== X-Gm-Message-State: ALoCoQkhk7oJL4/4b6a9pEPWii7dW1i6FC83d9UjwblssarbFk40f3x2HkMrWUoLdkGQIjheJrII MIME-Version: 1.0 X-Received: by 10.140.101.115 with SMTP id t106mr18770038qge.91.1404245487441; Tue, 01 Jul 2014 13:11:27 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Tue, 1 Jul 2014 13:11:27 -0700 (PDT) Date: Tue, 1 Jul 2014 13:11:27 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1721e74edea04fd2761a0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/snu6WPZx9Kqm1ZbdsN-GCMNRbkI Subject: [netmod] YANG 1.1 Issue: error-app-tag collisions (real example) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 20:11:37 -0000 --001a11c1721e74edea04fd2761a0 Content-Type: text/plain; charset=ISO-8859-1 Hi, We have known for years that the error-app-tag leaf is not that useful because standard values override vendor values (and clients can't tell them apart anyway). Now modules like ietf-routing are defining error-app-tag values in description statements (contributing to the completely ad-hoc registry of arbitrary strings). Not sure if this is already reported, but RFC 6020 and 6022 both define a 'data-not-unique' error-app-tag. The one in 6020 is for a unique-stmt failure and requires an error-info node pointing at the non-unique leaf. The 6022 version is for a request without a element (and there are multiple revisions on the server. No is returned in this version. RFC 6020, sec. 13.1: If a NETCONF operation would result in configuration data where a unique constraint is invalidated, the following error is returned: error-tag: operation-failed error-app-tag: data-not-unique error-info: : Contains an instance identifier that points to a leaf that invalidates the unique constraint. This element is present once for each non-unique leaf. The element is in the YANG namespace ("urn:ietf:params:xml:ns:yang:1"). RFC 6022, sec. 5: rpc get-schema { description "This operation is used to retrieve a schema from the NETCONF server. Positive Response: The NETCONF server returns the requested schema. Negative Response: If requested schema does not exist, the is 'invalid-value'. If more than one schema matches the requested parameters, the is 'operation-failed', and is 'data-not-unique'."; The flat list of strings is so fragile, we can't even keep track of our own standard values. Not to mention the fact that every time we add a new ad-hoc standard error-app-tag, it could be colliding with a vendor value that is already deployed. IMO this part of NETCONF/YANG is significantly broken and needs to be fixed or completely removed. Andy --001a11c1721e74edea04fd2761a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

We have known for years that the er= ror-app-tag leaf is not
that useful because standard values overr= ide vendor values
(and clients can't tell them apart anyway).=

Now modules like ietf-routing are defining error-app-ta= g values
in description statements (contributing to the completel= y ad-hoc
registry of arbitrary strings).

Not sure if this is already reported, but RFC 6020 and 6022 both
=
define a 'data-not-unique' error-app-tag. =A0The one in 6020 i= s for
a unique-stmt failure and requires an error-info node point= ing at
the non-unique leaf. =A0The 6022 version is for a <get-schema> r= equest
without a <revision> element (and there are multiple= revisions
on the server. =A0No <error-info> is returned in= this version.

RFC 6020, sec. 13.1:
   If a NETCONF operation=
 would result in configuration data where a
   unique constraint is invalidated, the following error is returned:

     error-tag:      operation-failed
     error-app-tag:  data-not-unique
     error-info:     <non-unique>: Contains an instance identifier th=
at
                     points to a leaf that invalidates the unique
                     constraint. This element is present once for each
                     non-unique leaf.

                     The <non-unique> element is in the YANG
                     namespace ("urn:ietf:params:xml:ns:yang:1").

RFC 6022, sec. 5:

= 
 =
 rpc get-schema {
    description
      "This operation is used to retrieve a schema from the
       NETCONF server.

       Positive Response:
         The NETCONF server returns the requested schema.

       Negative Response:
         If requested schema does not exist, the <error-tag> is
         'invalid-value'.

         If more than one schema matches the requested parameters, the
         <error-tag> is 'operation-failed', and <error-app=
-tag> is
         'data-not-unique'.";

The fla= t list of strings is so fragile, we can't even keep track of our
own standard values. =A0Not to mention the fact that every time we add=
a new ad-hoc standard error-app-tag, it could be colliding with = a vendor
value that is already deployed.

IMO this part of NETCONF/YANG is significantly broken and needs
t= o be fixed or completely removed.


<= br>
Andy




--001a11c1721e74edea04fd2761a0-- From nobody Tue Jul 1 13:25:44 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1EDC1A037F for ; Tue, 1 Jul 2014 13:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azDB6MHUcOkc for ; Tue, 1 Jul 2014 13:25:40 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4F03F1A02F2 for ; Tue, 1 Jul 2014 13:25:39 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 171BA128048A; Tue, 1 Jul 2014 22:22:40 +0200 (CEST) Date: Tue, 01 Jul 2014 22:25:37 +0200 (CEST) Message-Id: <20140701.222537.14190146.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/dIRz5n5Jr__PjEuM-ICA1Azv-K0 Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 Issue: error-app-tag collisions (real example) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 20:25:42 -0000 Andy Bierman wrote: > Hi, > > We have known for years that the error-app-tag leaf is not > that useful because standard values override vendor values > (and clients can't tell them apart anyway). > > Now modules like ietf-routing are defining error-app-tag values > in description statements (contributing to the completely ad-hoc > registry of arbitrary strings). > > Not sure if this is already reported, but RFC 6020 and 6022 both > define a 'data-not-unique' error-app-tag. The one in 6020 is for > a unique-stmt failure and requires an error-info node pointing at > the non-unique leaf. The 6022 version is for a request > without a element (and there are multiple revisions > on the server. No is returned in this version. I don't think this is a problem in this case. These error-app-tags are returned for different operations, so there is no conflict. > RFC 6020, sec. 13.1: > > If a NETCONF operation would result in configuration data where a > unique constraint is invalidated, the following error is returned: > > error-tag: operation-failed > error-app-tag: data-not-unique > error-info: : Contains an instance identifier that > points to a leaf that invalidates the unique > constraint. This element is present once for each > non-unique leaf. > > The element is in the YANG > namespace ("urn:ietf:params:xml:ns:yang:1"). > > > RFC 6022, sec. 5: > > rpc get-schema { > description > "This operation is used to retrieve a schema from the > NETCONF server. > > Positive Response: > The NETCONF server returns the requested schema. > > Negative Response: > If requested schema does not exist, the is > 'invalid-value'. > > If more than one schema matches the requested parameters, the > is 'operation-failed', and is > 'data-not-unique'."; > > > The flat list of strings is so fragile, we can't even keep track of our > own standard values. Not to mention the fact that every time we add > a new ad-hoc standard error-app-tag, it could be colliding with a vendor > value that is already deployed. > > IMO this part of NETCONF/YANG is significantly broken and needs > to be fixed or completely removed. I don't think this is a pure YANG issue, but a NETCONF/XML issue. I suggested a long time ago that this should be encoded as a QName in NETCONF. This would require a new version of the protocol though :( RESTCONF can use QName in XML and : in JSON. /martin From nobody Tue Jul 1 13:44:23 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938DD1A03AE for ; Tue, 1 Jul 2014 13:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTWIZC5HOspP for ; Tue, 1 Jul 2014 13:44:21 -0700 (PDT) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 373A31A014E for ; Tue, 1 Jul 2014 13:44:21 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id q108so3835123qgd.21 for ; Tue, 01 Jul 2014 13:44:20 -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=AkyrIJikGHMlGmb4XJNOpNQ1t6MMhdot4U82wKlHz5s=; b=etwh8QBw5klCbzLXW4r8V7lXhpvG/Z9xGxlZDNpu/P8//aVVuO/nyFkjPjkQpr/Jbw 9HzJ1kbd8wY+QaYSGt2Bf4pe/PHlFuKSisY6xeumaYOfJFtCv80HWfC83UtC3C33YhGg KQog/gb4kTIw2/DWkNSMcIuVXbVMk2XrEeibY7h1Nh7rGcgg/n9quE92smmT6ZyZDn6d k5BIhe7WmzsMxDRAOYdok9o+cLVKFpPi2MOUJuroMyu1+FYkAr3IHj8ujFnn7INdGfz9 Kql8uaWtWL2XyUGM5J4oJJDMwlXjgzhY2dVxyFJlC7Hg8eUfTTmOrrFMQDP93X5XC1Dw KUVQ== X-Gm-Message-State: ALoCoQkBWLI6EdNbUxFjIMOwlhU/jiiCQ8mAaElSiXaWOTi+RGVBZXcLLdwO5pN07LTUeTZirS4V MIME-Version: 1.0 X-Received: by 10.140.101.115 with SMTP id t106mr19014632qge.91.1404247460069; Tue, 01 Jul 2014 13:44:20 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Tue, 1 Jul 2014 13:44:20 -0700 (PDT) In-Reply-To: <20140701.222537.14190146.mbj@tail-f.com> References: <20140701.222537.14190146.mbj@tail-f.com> Date: Tue, 1 Jul 2014 13:44:20 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c1721e091af804fd27d7f4 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hATlyx4GX1bY6xkXQyCidnYhr0c Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 Issue: error-app-tag collisions (real example) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 20:44:22 -0000 --001a11c1721e091af804fd27d7f4 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 1, 2014 at 1:25 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > We have known for years that the error-app-tag leaf is not > > that useful because standard values override vendor values > > (and clients can't tell them apart anyway). > > > > Now modules like ietf-routing are defining error-app-tag values > > in description statements (contributing to the completely ad-hoc > > registry of arbitrary strings). > > > > Not sure if this is already reported, but RFC 6020 and 6022 both > > define a 'data-not-unique' error-app-tag. The one in 6020 is for > > a unique-stmt failure and requires an error-info node pointing at > > the non-unique leaf. The 6022 version is for a request > > without a element (and there are multiple revisions > > on the server. No is returned in this version. > > I don't think this is a problem in this case. These error-app-tags > are returned for different operations, so there is no conflict. > > It is bad precedent and IMO sloppy design. These values should not be per-operation. For example, a tool validating the would need to know the in order to generate or suppress a missing error. > > RFC 6020, sec. 13.1: > > > > If a NETCONF operation would result in configuration data where a > > unique constraint is invalidated, the following error is returned: > > > > error-tag: operation-failed > > error-app-tag: data-not-unique > > error-info: : Contains an instance identifier that > > points to a leaf that invalidates the unique > > constraint. This element is present once for each > > non-unique leaf. > > > > The element is in the YANG > > namespace ("urn:ietf:params:xml:ns:yang:1"). > > > > > > RFC 6022, sec. 5: > > > > rpc get-schema { > > description > > "This operation is used to retrieve a schema from the > > NETCONF server. > > > > Positive Response: > > The NETCONF server returns the requested schema. > > > > Negative Response: > > If requested schema does not exist, the is > > 'invalid-value'. > > > > If more than one schema matches the requested parameters, the > > is 'operation-failed', and is > > 'data-not-unique'."; > > > > > > The flat list of strings is so fragile, we can't even keep track of our > > own standard values. Not to mention the fact that every time we add > > a new ad-hoc standard error-app-tag, it could be colliding with a vendor > > value that is already deployed. > > > > IMO this part of NETCONF/YANG is significantly broken and needs > > to be fixed or completely removed. > > I don't think this is a pure YANG issue, but a NETCONF/XML issue. I > suggested a long time ago that this should be encoded as a QName in > NETCONF. This would require a new version of the protocol though :( > This field in the protocol is broken. 2 years from now, it will still be broken. Perhaps the error-message and error-app-tag statements could be allowed as child statements of data-def-stmts, but that is not part of YANG 1.1. E.g.: error-tag-stmt below. rpc route-count { description "Return the current number of routes in a RIB."; input { leaf rib-name { type rib-state-ref; mandatory "true"; description "Name of the RIB. If the RIB with name equal to the value of this parameter doesn't exist, then this operation SHALL fail with error-tag 'data-missing' and error-app-tag 'rib-not-found'."; error-tag data-missing { error-app-tag rib-not-found; } } } > RESTCONF can use QName in XML and : in > JSON. > Yes -- this is how it should work. IMO leaf-list instead of leaf as well. > > > /martin > Andy --001a11c1721e091af804fd27d7f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Jul 1, 2014 at 1:25 PM, Martin Bjorklund = <mbj@tail-f.com&= gt; wrote:
Andy Bierman <and= y@yumaworks.com> wrote:
> Hi,
>
> We have known for years that the error-app-tag leaf is not
> that useful because standard values override vendor values
> (and clients can't tell them apart anyway).
>
> Now modules like ietf-routing are defining error-app-tag values
> in description statements (contributing to the completely ad-hoc
> registry of arbitrary strings).
>
> Not sure if this is already reported, but RFC 6020 and 6022 both
> define a 'data-not-unique' error-app-tag. =A0The one in 6020 i= s for
> a unique-stmt failure and requires an error-info node pointing at
> the non-unique leaf. =A0The 6022 version is for a <get-schema> r= equest
> without a <revision> element (and there are multiple revisions > on the server. =A0No <error-info> is returned in this version.
I don't think this is a problem in this case. =A0These error-app-tags are returned for different operations, so there is no conflict.


It is bad precedent and IMO sloppy des= ign.
These values should not be per-operation.
For exam= ple, a tool validating the <rpc-reply> would need to know the <rpc= >
in order to generate or suppress a missing <non-unique> error.

=A0
> RFC 6020, sec. 13.1:
>
> =A0 =A0If a NETCONF operation would result in configuration data where= a
> =A0 =A0unique constraint is invalidated, the following error is return= ed:
>
> =A0 =A0 =A0error-tag: =A0 =A0 =A0operation-failed
> =A0 =A0 =A0error-app-tag: =A0data-not-unique
> =A0 =A0 =A0error-info: =A0 =A0 <non-unique>: Contains an instanc= e identifier that
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0points to a leaf that inval= idates the unique
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0constraint. This element is= present once for each
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0non-unique leaf.
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The <non-unique> elem= ent is in the YANG
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0namespace ("urn:ietf:p= arams:xml:ns:yang:1").
>
>
> RFC 6022, sec. 5:
>
> =A0 rpc get-schema {
> =A0 =A0 description
> =A0 =A0 =A0 "This operation is used to retrieve a schema from the=
> =A0 =A0 =A0 =A0NETCONF server.
>
> =A0 =A0 =A0 =A0Positive Response:
> =A0 =A0 =A0 =A0 =A0The NETCONF server returns the requested schema. >
> =A0 =A0 =A0 =A0Negative Response:
> =A0 =A0 =A0 =A0 =A0If requested schema does not exist, the <error-t= ag> is
> =A0 =A0 =A0 =A0 =A0'invalid-value'.
>
> =A0 =A0 =A0 =A0 =A0If more than one schema matches the requested param= eters, the
> =A0 =A0 =A0 =A0 =A0<error-tag> is 'operation-failed', an= d <error-app-tag> is
> =A0 =A0 =A0 =A0 =A0'data-not-unique'.";
>
>
> The flat list of strings is so fragile, we can't even keep track o= f our
> own standard values. =A0Not to mention the fact that every time we add=
> a new ad-hoc standard error-app-tag, it could be colliding with a vend= or
> value that is already deployed.
>
> IMO this part of NETCONF/YANG is significantly broken and needs
> to be fixed or completely removed.

I don't think this is a pure YANG issue, but a NETCONF/XML issue. =A0I<= br> suggested a long time ago that this should be encoded as a QName in
NETCONF. =A0This would require a new version of the protocol though :(
<= /blockquote>

This field in the protocol is broken. =A02 = years from now, it will still be broken.
Perhaps the error-messag= e and error-app-tag statements could be allowed
as child statements of data-def-stmts, but that is not part of YANG 1.= 1.
E.g.: error-tag-stmt below.

 rpc route=
-count {
    description
      "Return the current number of routes in a RIB.";
    input {
      leaf rib-name {
        type rib-state-ref;
        mandatory "true";
        description
          "Name of the RIB.

           If the RIB with name equal to the value of this parameter
           doesn't exist, then this operation SHALL fail with
           error-tag 'data-missing' and error-app-tag
           'rib-not-found'.";
         error-tag data-miss=
ing {
           error-app-tag rib-not-found;
         }
      }
    }




RESTCONF can use QName in XML and <modulename>:<error-app-tag> = in
JSON.

Yes -- this is how it should work= . IMO leaf-list instead of leaf as well.
=A0


/martin

Andy<= /div>

--001a11c1721e091af804fd27d7f4-- From nobody Wed Jul 2 02:51:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90861B28E1; Wed, 2 Jul 2014 02:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.817 X-Spam-Level: X-Spam-Status: No, score=-2.817 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LONGWORDS=2.035, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWOQ30BCb4uc; Wed, 2 Jul 2014 02:51:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 876881B27E5; Wed, 2 Jul 2014 02:51:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJM38296; Wed, 02 Jul 2014 09:51:35 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 2 Jul 2014 10:51:34 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.24]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Wed, 2 Jul 2014 17:51:26 +0800 From: "Liubing (Leo)" To: Netconf , "netmod@ietf.org" Thread-Topic: Multiple instances configuration issues-//FW: New Version Notification for draft-liu-netconf-multi-instances-00.txt Thread-Index: AQHPldswcHtSPLODJEKU9E5gnW6XrQ== Date: Wed, 2 Jul 2014 09:51:26 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8ED5BF@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/367VKKg936Tz3iW325m_AmzQx4o Cc: Zhengguangying , Yangang Subject: [netmod] Multiple instances configuration issues-//FW: New Version Notification for draft-liu-netconf-multi-instances-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 09:51:39 -0000 SGkgYWxsIGluIE5ldGNvbmYgJiBOZXRtb2QsDQoNCkluIGxhc3QgTmV0Y29uZiBtZWV0aW5nIGlu IExvbmRvbiwgbXkgY29sbGVhZ3VlIEd1YW5neWluZyBaaGVuZyByYWlzZWQgYSBxdWVzdGlvbiBh dCB0aGUgbWlrZSBhYm91dCBob3cgdG8gZGlzdGluZ3Vpc2ggbXVsdGlwbGUgVlJGcyB3aGVuIHVz aW5nIE5FVENPTkYgdG8gY29uZmlndXJlIGEgZGV2aWNlLg0KQW5kIHRoZW4gaW4gdGhlIG1haWxp bmcgbGlzdCwgRGF2aWQgTGFtcGFydGVyIGxlZCBhIHZlcnkgZ29vZCBkaXNjdXNzaW9uIG9mIHRo ZSBwcm9ibGVtLiANCg0KQXMgZGlzY3Vzc2VkIGluIHRoZSBtYWlsaW5nIGxpc3QsIGl0IGlzIG5v dCBvbmx5IHJlZ2FyZGluZyB0byBWUkYsIHJhdGhlciwgaXQgaXMgcXVpdGUgYSBnZW5lcmFsIGlz c3VlLiANClNvIHdlIHdyb3RlIGEgZHJhZnQgdG8gdHJ5IHRvIG1ha2UgYSBjb21wcmVoZW5zaXZl IGRpc2N1c3Npb24gb2YgdGhlIGlzc3VlLiBUaGUgZHJhZnQgYW5hbHl6ZXMgdGhlIG1hbmFnZW1l bnQgcmVxdWlyZW1lbnRzIGZvciBtdWx0aXBsZSBpbnN0YW5jZXMgbGlrZSBWUkYsIGFuZCBwb2lu dGVkIG91dCBzb21lIGdhcHMgaW4gY3VycmVudCBORVRDT05GIHByb3RvY29sIGFuZCBZQU5HIG1v ZGVscy4gQXQgbGFzdCwgdGhlIGRyYWZ0IGJyaWVmbHkgZGlzY3VzcyBzb21lIHBvc3NpYmxlIHNv bHV0aW9ucyB0byBmaWxsIHRoZSBnYXBzLg0KDQpQbGVhc2UgcmV2aWV3IHRoZSBkcmFmdCBhbmQg Y29tbWVudC4NCk1hbnkgdGhhbmtzIQ0KDQpCZXN0IHJlZ2FyZHMsDQpCaW5nDQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMDIs IDIwMTQgNDo0OCBQTQ0KVG86IExpdWJpbmcgKExlbyk7IExpdWJpbmcgKExlbyk7IFlhbmdhbmc7 IFlhbmdhbmcNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGl1 LW5ldGNvbmYtbXVsdGktaW5zdGFuY2VzLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1saXUtbmV0Y29uZi1tdWx0aS1pbnN0YW5jZXMtMDAudHh0DQpoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEJpbmcgTGl1IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVw b3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWxpdS1uZXRjb25mLW11bHRpLWluc3RhbmNlcw0KUmV2 aXNpb246CTAwDQpUaXRsZToJCU11bHRpLUluc3RhbmNlcyBDb25maWd1cmF0aW9uIElzc3VlIGlu IE5FVENPTkYNCkRvY3VtZW50IGRhdGU6CTIwMTQtMDctMDINCkdyb3VwOgkJSW5kaXZpZHVhbCBT dWJtaXNzaW9uDQpQYWdlczoJCTEwDQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGl1LW5ldGNvbmYtbXVsdGktaW5zdGFuY2VzLTAwLnR4 dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWxpdS1uZXRjb25mLW11bHRpLWluc3RhbmNlcy8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saXUtbmV0Y29uZi1tdWx0aS1pbnN0YW5jZXMtMDANCg0K DQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgcHV0cyB0b2dldGhlciB0aGUgTkVUQ09ORiBp c3N1ZXMgb2YgY29uZmlndXJpbmcNCiAgIG11bHRpcGxlIGluc3RhbmNlcyBpbmNsdWRpbmcgY29u ZmlndXJpbmcgbXVsdGlwbGUgbmV0d29yayBlbGVtZW50DQogICBpbnN0YW5jZXMgYW5kIG11bHRp cGxlIHNlcnZpY2UgaW5zdGFuY2VzLiBUaGUgbWFpbiBwcm9ibGVtIGlzIGhvdyB0bw0KICAgY29u ZmlndXJlIHRoZSBtdWx0aXBsZSBpbnN0YW5jZXMgaW4gb25lIE5FVENPTkYgY2hhbm5lbC4NCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRh a2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Wed Jul 2 05:13:55 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85C71B2901 for ; Wed, 2 Jul 2014 05:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoKXy6AazM0B for ; Wed, 2 Jul 2014 05:13:50 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB7DC1B28F9 for ; Wed, 2 Jul 2014 05:13:49 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B71D36B9 for ; Wed, 2 Jul 2014 14:13:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id S2iEoDdBTUbg for ; Wed, 2 Jul 2014 14:13:36 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 2 Jul 2014 14:13:47 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C76620055 for ; Wed, 2 Jul 2014 14:13:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UwM3Ke1u5bFB; Wed, 2 Jul 2014 14:13:47 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7850520053; Wed, 2 Jul 2014 14:13:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A83C22D9FB03; Wed, 2 Jul 2014 14:13:46 +0200 (CEST) Date: Wed, 2 Jul 2014 14:13:46 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140702121346.GA38596@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/u-QoxAUHHiP8rpvFpp4D-TmB9mU Subject: [netmod] virtual interim meeting reminder X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jul 2014 12:13:51 -0000 Hi, this is a short reminder that we have a virtual interim meeting later today (4pm-6pm central european time zone). You will find the webex details here: http://www.ietf.org/mail-archive/web/ietf-announce/current/msg12811.html /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jul 2 09:51:54 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31CBA1B29A4 for ; Wed, 2 Jul 2014 09:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_45=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPi3wKPKUGtv for ; Wed, 2 Jul 2014 09:51:50 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D81951B29A3 for ; Wed, 2 Jul 2014 09:51:49 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 705D953 for ; Wed, 2 Jul 2014 18:51:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 0rB7esSEhMWT for ; Wed, 2 Jul 2014 18:51:34 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 2 Jul 2014 18:51:46 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0EE0720054 for ; Wed, 2 Jul 2014 18:51:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FRhZDh1BF0Ft; Wed, 2 Jul 2014 18:51:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7237E20053; Wed, 2 Jul 2014 18:51:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E7E3C2DA0207; Wed, 2 Jul 2014 18:51:43 +0200 (CEST) Date: Wed, 2 Jul 2014 18:51:42 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140702165142.GA39163@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OyD8PwAduU0t2w598przHgigWd8 Subject: [netmod] draft minutes of the 2014-07-02 virtual interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jul 2014 16:51:53 -0000 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, attached please find the draft minutes of the 2014-07-02 virtual interim meeting. Note that a final version needs to be submitted within 10 days - so please send any corrections of the minutes by Wednesday July 9th. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="netmod-2014-07-02-minutes.txt" ============================================================= NETCONF Data Modeling Language WG (netmod) 3rd YANG 1.1 Virtual Interim Wednesday, July 2nd, 2014, 16:00-16:00 CEST Minutes Juergen Schoenwaelder ============================================================= * Participants - JS = Juergen Schoenwaelder - AB = Andy Bierman - LL = Lada Lotka - MB = Martin Bjorklund - BC = Benoit Claise - PO = Peyman Owladi - PH = Peter van Horne * Summary During the meeting, the issues Y07, Y09, Y10, Y11, Y12, Y13, Y14, Y16, and Y18 were discussed. For each issue, either a strawman proposal has been found or concrete action items have been assigned. We will continue with two more virtual interim meetings before the face-to-face meeting in Toronto. * Y07: do not allow when or if-feature on keys AB: Says the solution is wrong, if-feature / when should not be more specific than the parent. AB: Is there not text somewhere else in RFC 6020? PO: The leafs condition should at least be as restrictive as the parent context. PO: A statement that says something about the parent is irritating. AB: What if I put if-feature bar on the parent? MB: That is OK. LL: What must be avoided are lists where keys are (partially) undefined. MB: Make them illegal if the condition is different from the parent. Proposal: Adopt Y07-01 with a clarification about the condition. * Y09: introduce optional keys Action: MB will write up a solution proposal. * Y10: allow restrictions on enumerations MB: I think we should do what SMIv2 allows. AB: What prevents the second typedef from redefining enum a? MB: Redefining the value would not be legal. LL: What about having a different statement to define the set of allowed enums to prevent overwrite issues? MB: Not sure this helps since you can do pretty much all of this with strings and pattern, see the first example. AB: What happens if foo has a default b? MB: That would be illegal. LL: I prefer a different syntax. Action: LL to write down another syntax proposal and MB to expant Y10-01. PO: What about restrictions on unions? MB: Currently not allowed, should they be allowed? JS: Unclear whether common programming languages allow something like this. MB: An implementation issue. JS: But people might simply not expect this to be available. MB: Lets discuss this later, this is a separate issue. * Y11: allow if-feature on enums MB: This avoid having choices with an empty container. AB: This is somewhat different since this usage of if-feature is not related to data tree nodes directly but instead applies to the value space of types. PO: If you have if-feature for enumerations, would you also want to have them for identities? MB: Likely yes. AB: I like this since it allows an NMS to restrict values shown to a user based on the announced features. Proposal: Adopt Y11-01 with the extension to allow if-feature also for bits and identities. * Y12: initialized-by system JS: Does initialized-by system mean may be initialized-by system? And initialized-by user means must be initialized-by user? MB: No, it is more boolean. MB: This is not a default, the server generates a suitable value. PO: What about ports that change the MTU when sub-interfaces are configured? MB: YANG does not support dynamic defaults in that way. AB: What about processing an edit-config with multiple list entries, some with explicit values, some without? MB: The server would have to figure this out. JS: The server can be smart to figure out suitable values for a given commit or be dumb and return an error (similar to an edit-config with conflicting uids). LL: Should probably have a different syntax, initialized-by user is misleading, perhaps system-initialized true|false. It is really system-initialized-if-missing. LL: Only valid for leaf? MB: I think also leaf-list, for consistency. PO: May be a bit related to mandatory, default is likely illegal with initialized-by system, need to write more complete text. Proposal: Adopt Y12-01 but think about a better syntax. Applies to leaf and leaf-lists. MB to create concrete text. * Y13: allow multiple inheritance for identities AB: I am not see the example - the example only defines two regular identities. LL: Not sure I wrote the example. AB: What do I get by having multiple bases to an identity? PO: Interfaces are good examples. LL: It is good to use identityref with multiple bases. JS: How do you maintain the identity derivation graph if things are added over time? LL: This is only useful if we have suitable xpath functions. JS: Can someone write a complete example that shows how this solves interface type issues? Action: LL to write a more complete example. * Y14: clarify the string value for identities when used in must/when MB: I think Y14-01 is already used in the routing model. LL: Need for this drops once we have xpath functions. MB: We still need to define this. Proposal: Adopt Y14-01. * Y16: module advertisement optimization AB: Not sure this is a YANG issue alone. MB: YANG module advertisement is defined in RFC 6020. AB: This does not work because there is no version number. If the client could say here is what I have cached, then this could be made to work. MB: If we only suppress YANG 1.1 modules? JS: Is the info in RFC 6022 (Y16-02) complete? MB: Not sure, we implement /netconf-state/capabilities as what was in the hello. PO: I am leaning towards Y16-02. MB: RFC 6022 talks about NETCONF capabilities. Does it also contain the data models? AB: Right now, the hello contains all modules. But this should actually be subject to access control. AB: I am in favor of Y16-02 since it allows to hide loaded modules. JS: How does this work in RESTCONF? Action: MB to look at the details whether Y16-02 can be made to work. * Y18: fix "when" expression context node problem LL: I do not like the solution proposal. The result may depends on the order. LL: My proposal would be to treat when equivalent to must. MB: But this is backwards incompatible. MB: I do not understand the problem you see. LL: You need to at least specify what happens if there are circular dependencies. MB: Seems like a theoretical corner case. PO: Perhaps even leaving this implementation specific? AB: There are other when issues, e.g. the order in which expressions are evaluated and it gets work if when expressions interact. MB: How likely is this going to be a problem? Action: LL to write up an example in which situations Y18-01 is problematic. --4Ckj6UjgE2iN1+kY-- From nobody Wed Jul 2 11:35:51 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9DB1A0127 for ; Wed, 2 Jul 2014 11:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.057 X-Spam-Level: X-Spam-Status: No, score=0.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, LONGWORDS=2.035, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ks6C9bwjF5tz for ; Wed, 2 Jul 2014 11:35:46 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A00121B29F2 for ; Wed, 2 Jul 2014 11:35:46 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id o8so10286661qcw.17 for ; Wed, 02 Jul 2014 11:35:45 -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=ECoFw332mhs8FXkQViVU/VWiA62zH6KW/MDa5aNzDOc=; b=BUwsG0NGRZ3/0zlvM6+1oKAZmYBsE9xuFPQAIqHkvvOLqV5z0TDxkySt/4m9n3Qar0 7eocLIOjdwUvg6NRaKXObFu6REG439aJvgAtV9QEpSc99QHoPyQV/N9rg5MkDhuKHw12 ndqQuvFbIe3ZZd+Ydjk7KJAaJjIxfw39OtR5p30sPHNpF+QNhRx5n7qlk8bOfZGYziMo PEphV3GBJd3o6Y+AhSQZtWmbT+GKzKRXd7pX2xm7xRL/Gwod47iqYVAWWbXgE7IWsdDy y7SmjXF3sYou+z2yXlzymYnKX/bwM3CpLKbdqYm8/Tbsfflr9tuqsWIfRErKka3Y4MZr iOhw== X-Gm-Message-State: ALoCoQm0Qf7cekldzx5a/psNyE/Ql+uk4QBHIaMfrKS/aSugU6YbnvwuecHqwtA/3RzbzYrg93PB MIME-Version: 1.0 X-Received: by 10.224.20.10 with SMTP id d10mr85244944qab.16.1404326145638; Wed, 02 Jul 2014 11:35:45 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Wed, 2 Jul 2014 11:35:45 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8ED5BF@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8ED5BF@nkgeml506-mbx.china.huawei.com> Date: Wed, 2 Jul 2014 11:35:45 -0700 Message-ID: From: Andy Bierman To: "Liubing (Leo)" Content-Type: multipart/alternative; boundary=001a11c1c2ae0f6ab904fd3a29b9 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/szr0qYgCPClw2YWcbbWSByX6b8A Cc: Zhengguangying , Netconf , "netmod@ietf.org" , Yangang Subject: Re: [netmod] [Netconf] Multiple instances configuration issues-//FW: New Version Notification for draft-liu-netconf-multi-instances-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 18:35:48 -0000 --001a11c1c2ae0f6ab904fd3a29b9 Content-Type: text/plain; charset=ISO-8859-1 Hi, I read your draft and it I can see use-cases for a context-ID. I prefer to think of named virtual hosts in Apache2, rather than SNMP contexts. I don't think your solution is fully specified, but it is a good start. I think the following solution could easily work, which is just a refinement of your solution in sec. 4.1. 1) define a 'server-id' XML attribute 2) define a NETCONF 'virtual-server' capability indicating the server supports the 'server-id' attribute 3) the server is already required to accept all attributes in the start tag and return them in the start tag. (So sending the server-id attribute is safe in all cases). 4) If the server supports the capability, then it must check for the server-id attribute in each and use the correct virtual server or else return an error if it is an unknown server-id. I don't really understand Gap-2 and Gap-3 so I am not addressing that. It looks like it might overlap the "YANG mount" draft (draft-clemm-netmod-mount-01). IMO that is a completely different problem -- configuration of a mid-level-manager. Andy On Wed, Jul 2, 2014 at 2:51 AM, Liubing (Leo) wrote: > Hi all in Netconf & Netmod, > > In last Netconf meeting in London, my colleague Guangying Zheng raised a > question at the mike about how to distinguish multiple VRFs when using > NETCONF to configure a device. > And then in the mailing list, David Lamparter led a very good discussion > of the problem. > > As discussed in the mailing list, it is not only regarding to VRF, rather, > it is quite a general issue. > So we wrote a draft to try to make a comprehensive discussion of the > issue. The draft analyzes the management requirements for multiple > instances like VRF, and pointed out some gaps in current NETCONF protocol > and YANG models. At last, the draft briefly discuss some possible solutions > to fill the gaps. > > Please review the draft and comment. > Many thanks! > > Best regards, > Bing > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, July 02, 2014 4:48 PM > To: Liubing (Leo); Liubing (Leo); Yangang; Yangang > Subject: New Version Notification for > draft-liu-netconf-multi-instances-00.txt > > > A new version of I-D, draft-liu-netconf-multi-instances-00.txt > has been successfully submitted by Bing Liu and posted to the IETF > repository. > > Name: draft-liu-netconf-multi-instances > Revision: 00 > Title: Multi-Instances Configuration Issue in NETCONF > Document date: 2014-07-02 > Group: Individual Submission > Pages: 10 > URL: > http://www.ietf.org/internet-drafts/draft-liu-netconf-multi-instances-00.txt > Status: > https://datatracker.ietf.org/doc/draft-liu-netconf-multi-instances/ > Htmlized: > http://tools.ietf.org/html/draft-liu-netconf-multi-instances-00 > > > Abstract: > This document puts together the NETCONF issues of configuring > multiple instances including configuring multiple network element > instances and multiple service instances. The main problem is how to > configure the multiple instances in one NETCONF channel. > > > > > 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 > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11c1c2ae0f6ab904fd3a29b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I read your draft and it I can see = use-cases for a context-ID.
I prefer to think of named virtual ho= sts in Apache2, rather than
SNMP contexts.

I don't think your solution is fully specified, but it is a good start.=
I think the following solution could easily work, which is just = a
refinement of your solution in sec. 4.1.

=A01) define a 'server-id' XML attribute
<= div>=A02) define a NETCONF 'virtual-server' capability indicating t= he server supports the 'server-id' attribute
=A03) the se= rver is already required to accept all attributes in the <rpc> start = tag and return
=A0 =A0 =A0them in the <rpc-reply> start tag. (So sending the se= rver-id attribute is safe in all cases).
=A04) If the server supp= orts the capability, then it must check for the server-id attribute in each= <rpc>
=A0 =A0 =A0and use the correct virtual server or else return an error = if it is an unknown server-id.

I don't really = understand Gap-2 and Gap-3 so I am not addressing that. =A0It looks like
it might overlap the "YANG mount" draft (draft-clemm-netmod-mount= -01).
IMO that is a completely different problem -- configuration= of a mid-level-manager.


Andy





On Wed, Jul 2, 2014 at 2:51 AM, Liubin= g (Leo) <leo.liubing@huawei.com> wrote:
Hi all in Netconf & Netmod,

In last Netconf meeting in London, my colleague Guangying Zheng raised a qu= estion at the mike about how to distinguish multiple VRFs when using NETCON= F to configure a device.
And then in the mailing list, David Lamparter led a very good discussion of= the problem.

As discussed in the mailing list, it is not only regarding to VRF, rather, = it is quite a general issue.
So we wrote a draft to try to make a comprehensive discussion of the issue.= The draft analyzes the management requirements for multiple instances like= VRF, and pointed out some gaps in current NETCONF protocol and YANG models= . At last, the draft briefly discuss some possible solutions to fill the ga= ps.

Please review the draft and comment.
Many thanks!

Best regards,
Bing


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Wednesday, July 02, 2014 4:48 PM
To: Liubing (Leo); Liubing (Leo); Yangang; Yangang
Subject: New Version Notification for draft-liu-netconf-multi-instances-00.= txt


A new version of I-D, draft-liu-netconf-multi-instances-00.txt
has been successfully submitted by Bing Liu and posted to the IETF reposito= ry.

Name: =A0 =A0 =A0 =A0 =A0 draft-liu-netconf-multi-instances
Revision: =A0 =A0 =A0 00
Title: =A0 =A0 =A0 =A0 =A0Multi-Instances Configuration Issue in NETCONF Document date: =A02014-07-02
Group: =A0 =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0 =A0 =A010
URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf= .org/internet-drafts/draft-liu-netconf-multi-instances-00.txt
Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org= /doc/draft-liu-netconf-multi-instances/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-l= iu-netconf-multi-instances-00


Abstract:
=A0 =A0This document puts together the NETCONF issues of configuring
=A0 =A0multiple instances including configuring multiple network element =A0 =A0instances and multiple service instances. The main problem is how to=
=A0 =A0configure the multiple instances in one NETCONF channel.




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

_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf

--001a11c1c2ae0f6ab904fd3a29b9-- From nobody Thu Jul 3 04:10:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2CCE1B286B for ; Thu, 3 Jul 2014 04:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.151 X-Spam-Level: X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4_hi-W62Jii for ; Thu, 3 Jul 2014 04:10:41 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 007EF1B2883 for ; Thu, 3 Jul 2014 04:10:40 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id s63BAcCg012925 for ; Thu, 3 Jul 2014 13:10:38 +0200 Message-ID: <53B53A2C.7010607@mg-soft.com> Date: Thu, 03 Jul 2014 13:10:36 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yD_S6zbGiEzgMEHCN5SkYLdgND4 Subject: [netmod] YANG XPath usage guidelines (6087bis) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 11:10:44 -0000 Hi, some questions about YANG XPath expressions in general and as observed by 6087bis [1]. Does it make sense to use the 'id(object)' and 'lang(string)' XPath functions in YANG XPath expressions? They both imply existence of XML attributes, which cannot be modeled in pure YANG. Shouldn't RFC6087bis include a guideline for those in Section 4.5.? Is there a case where the mentioned XPath functions could be used? 'local-name(node-set?)', 'namespace-uri(node-set?)', 'name(node-set?)', 'string(object?)' and 'number(object?)' are all directly reliant on document order when the argument evaluates to a node-set with size > 1 and may therefore return different results for different implementations, like the case with 'position' and 'last'. Other functions may also be indirectly reliant on document order when they are supplied with a node-set argument which then needs to be converted into a string or a number as if by calling 'string(object?)' or 'number(object?)' respectively [2]. Shouldn't this also be mentioned in the guidelines, since some other cases are? Axes 'preceding-sibling' and 'following-sibling' should not be used unless dealing with user ordered lists or leaf-lists and I agree with 6087bis, however document order may not be relevant when using those two axes (uniqueness checks). There's an example in ietf-routing module [3]: not(/routing/ribs/rib[name=current()/preceding-sibling::connected-rib/rib-name and address-family=/routing/ribs/rib[name=current()/rib-name]/address-family]) where current() evaluates to a non-user ordered list instance. Shouldn't this also be mentioned in the guidelines as an acceptable corner case, like it is for 'preceding' and 'following'? 6087bis specifies: XPath expressions for 'when' statements MUST NOT reference the context node or any descendant nodes of the context node. yet ietf-ipv4-unicast-routing [3] clearly does so, with it's conditional augments of rpc methods, where it references 'rt:address-family' which is a descendant of the initial context node (augmentation target or nearest data node ancestor). Shouldn't conditional augmentation be an exception to this paragraph? 6087bis specifies: Data nodes that use the 'int64' and 'uint64' built-in type SHOULD NOT be used within numeric expressions. There are boundary conditions in which the translation from the YANG 64-bit type to an XPath number can cause incorrect results. Specifically, an XPath 'double' precision floating point number cannot represent very large positive or negative 64-bit numbers because it only provides a total precision of 53 bits. The 'int64' and 'uint64' data types MAY be used in numeric expressions if the value can be represented with no more than 53 bits of precision. In XPath specification [4], term "numeric expressions" refers to additive (+, -), multiplicative (*, mod, div) or unary expressions (sign) and does not include relational or equality expressions, so comparisons of int64 and uint64 data nodes do not seem to be discouraged by the current text. Was this intentional? Shouldn't all such numeric conversions be avoided? Ladislav once mentioned [5] that YANG XPath is able to "break out of module containment" with an expression like /*[local-name()='foo'] which is quite dangerous and IMO deserves mention in the guidelines. It should be clear that an expression is only able to reference names defined within the scope of a module, right? Or was "breaking out of module containment" intended as a feature of RFC6020 (seems more like a bug to me)? Completely unrelated modules should not cause unwanted side effects when implemented together. [1] http://tools.ietf.org/html/draft-bierman-netmod-rfc6087bis-00#section-4.5 [2] http://www.w3.org/TR/1999/REC-xpath-19991116/#section-Function-Calls [3] http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-15 [4] http://www.w3.org/TR/1999/REC-xpath-19991116/#numbers [5] http://www.ietf.org/mail-archive/web/netmod/current/msg09623.html Jernej From nobody Thu Jul 3 04:58:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BEB1B28FA; Thu, 3 Jul 2014 04:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aj3j1pe-DULn; Thu, 3 Jul 2014 04:58:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 282B81A0A74; Thu, 3 Jul 2014 04:58:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140703115837.26792.90471.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 04:58:37 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/NFUpIbiZF4JLrv5fyX3FAS0z15E Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 11:58:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) Author : Martin Bjorklund Filename : draft-ietf-netmod-rfc6020bis-00.txt Pages : 170 Date : 2014-07-03 Abstract: YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. This document obsoletes RFC 6020. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-00 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/ From nobody Thu Jul 3 06:50:51 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672F81B29F7 for ; Thu, 3 Jul 2014 06:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o41Oy7kTl8jY for ; Thu, 3 Jul 2014 06:50:36 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74AF81B29F0 for ; Thu, 3 Jul 2014 06:50:35 -0700 (PDT) X-AuditID: c1b4fb25-f79da6d000004ad3-e5-53b55fa9d845 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D0.27.19155.9AF55B35; Thu, 3 Jul 2014 15:50:33 +0200 (CEST) Received: from [159.107.197.183] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.174.1; Thu, 3 Jul 2014 15:50:33 +0200 Message-ID: <53B55FA8.8090501@ericsson.com> Date: Thu, 3 Jul 2014 15:50:32 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "netmod@ietf.org >> \"netmod@ietf.org\"" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGJMWRmVeSWpSXmKPExsUyM+Jvje7K+K3BBvP2mljMv9jI6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujCeHm1kK7gpVdHy+zt7A+I+vi5GTQ0LAROLQi4tMELaYxIV7 69m6GLk4hASOMko0buiFctYwSlxYOp2li5GDg1dAW+JlWzGIySKgIvFgnjJIL5uAkcTU/vMs ILaoQJTEnUv9rCA2r4CgxMmZT8DiIgJ2EqcudbKD2MICEhJ9LxaD7WUWsJW4MOc6C4QtL7H9 7RxmEFtIQEPi4YW/rBMY+WYhGTULScssJC0LGJlXMYoWpxYn5aYbGeulFmUmFxfn5+nlpZZs YgQG1MEtv1V3MF5+43iIUYCDUYmHd4HHlmAh1sSy4srcQ4zSHCxK4rwLz80LFhJITyxJzU5N LUgtii8qzUktPsTIxMEp1cCYeWnhq5sH3+w92STJ3vP66mMmvd7FGuX9QQYJzG0vcm6LcnL+ 6X/5we1WujJr6sr4O0FXH0raPmjuc445OOfG0cQXP5f2Fe6q03krWGkz7/PFxZXHGe315jmX Ppp/WlT2177HP3z8W2/6L9bfZ2fI/zQ5ct+nOVmRfJv596tPbbjg9N1s2zw1JZbijERDLeai 4kQADM0LDwkCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/pNlNz7h9aP2_4NLYSiKw_CJq_zE Subject: [netmod] New YANG issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 13:50:42 -0000 Hello, Ericsson decided that we would need 3 additions to the list of issues for YANG 1.1. I am really sorry for bringing up issues this late, but after the internal decision that Ericsson should become more active around Netconf (which I hope is a gain for the Netconf community), the following issues became really important for us. 1) Non-Unique leaf-list: YANG shall allow leaf-lists whose members are not unique. They are needed in a number of cases especially for user-ordered lists, where the position is stable and carries a meaning. 2) Recursive containment: Allow groupings to "use" themselves themselves directly or indirectly. It is needed e.g. for modeling Hierarchical QOS (Que-in-Que), HW Equipment information (replaceable-unit in replaceable-unit) or representing a file system (directories in directories). All these cases are modeled naturally as a containment hierarchy even if they could be handled using a reference list. Besides being more intuitive models with recursive containment have one distinct advantage over reference based solutions. If recursive containment is used it is easy to point out exactly which Que/ Replaceable unit/Directory is addressed. For the exact understanding of the item it is needed to know where it is placed in a hierarchy, e.g an instance-identifier type address would contain its position in the containment hierarchy. If we use a flat list of items and use references to indicate how they are related, which item "contains" which, then the instance identifier will not tell you the position in the hierarchy. 3) Actions: YANG model defined rpc operations that are connected to a specific resource in the data-model. Actions are something Ericsson and Tail-f has been using for a long time and "nearly" got into YANG 1.0 at that time. They are similar, but better then the YANG rpc construct, because they are connected to managed objects e.g. lists, so you can have the same action (e.g. restart) on multiple points in your data model. Also actions are scoped: only visible on the managed object where they are actually needed. With YANG RPCs it is easy to and up in one huge list of RPCs visible everywhere. regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Thu Jul 3 07:48:54 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1E11B2AC6 for ; Thu, 3 Jul 2014 07:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sB94UsfMfzAZ for ; Thu, 3 Jul 2014 07:48:48 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25A6D1B2B0E for ; Thu, 3 Jul 2014 07:47:39 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id v10so267074qac.18 for ; Thu, 03 Jul 2014 07:47:38 -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=mi5GxRZexdrSmBsumDKdE+uYixPc0NkJpxHKzmMrNAI=; b=WnuoOH0pqzOgz4pVtBiFzDzLqp1MmwhE/zh7u6RUTp1kyGkExxJDTwQSqJyORemoUw 3o1CkKggj5x3U3hLAnucDDqFY73KmISYBXKOH2CrVD/UgJ43Op7InP24jEPDCYZki1gp qTsBgdsj9K75E0J/w8wudVh+xzyUVS0TShWfpwVBaYfqSFzdql8YBziGqWb4sO4gE6Jw 1X4SY8db1HzS6M9CtJDeo5ad0n41qFhFJPNBEEqruPC6CAAl9OWaN1x1p9tAr3xwr1ML NqYpDASPBQuLH0Umrp6WQP4lDuiuTQmnSADH83hQiRImb7Gy3eKbXXqBLPg05xCNfhS9 RATA== X-Gm-Message-State: ALoCoQkh9KSNdCMoM/YzzG6sBoIDm/n/OBBrlJgQsAgznPKqLkJvvvbb5yhLLFHrcTiIMBeNAM9G MIME-Version: 1.0 X-Received: by 10.140.102.12 with SMTP id v12mr7851077qge.94.1404398858257; Thu, 03 Jul 2014 07:47:38 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Thu, 3 Jul 2014 07:47:38 -0700 (PDT) In-Reply-To: <53B55FA8.8090501@ericsson.com> References: <53B55FA8.8090501@ericsson.com> Date: Thu, 3 Jul 2014 07:47:38 -0700 Message-ID: From: Andy Bierman To: Balazs Lengyel Content-Type: multipart/alternative; boundary=001a1134f15211db4a04fd4b17a1 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4YbTtIKusozIY7FZNzOAhxZSyvA Cc: "netmod@ietf.org >> netmod@ietf.org" Subject: Re: [netmod] New YANG issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 14:48:53 -0000 --001a1134f15211db4a04fd4b17a1 Content-Type: text/plain; charset=ISO-8859-1 Hi, IMO we cannot keep adding on new features to YANG 1.1, especially features that have been discussed and rejected many times already. Your list might be OK for YANG 2.0 features On Thu, Jul 3, 2014 at 6:50 AM, Balazs Lengyel wrote: > Hello, > Ericsson decided that we would need 3 additions to the list of issues for > YANG 1.1. I am really sorry for bringing up issues this late, but after the > internal decision that Ericsson should become more active around Netconf > (which I hope is a gain for the Netconf community), the following issues > became really important for us. > > 1) Non-Unique leaf-list: YANG shall allow leaf-lists whose members are not > unique. > They are needed in a number of cases especially for user-ordered lists, > where the position is stable and carries a meaning. > > YANG insert "before" and "after" attributes and delete/remove operations would not work correctly. 2) Recursive containment: Allow groupings to "use" themselves themselves > directly or indirectly. > It is needed e.g. for modeling Hierarchical QOS (Que-in-Que), HW > Equipment information (replaceable-unit in replaceable-unit) or > representing a file system (directories in directories). All these cases > are modeled naturally as a containment hierarchy even if they could be > handled using a reference list. > Besides being more intuitive models with recursive containment have one > distinct advantage over reference based solutions. If recursive containment > is used it is easy to point out exactly which Que/ Replaceable > unit/Directory is addressed. For the exact understanding of the item it is > needed to know where it is placed in a hierarchy, e.g an > instance-identifier type address would contain its position in the > containment hierarchy. If we use a flat list of items and use references to > indicate how they are related, which item "contains" which, then the > instance identifier will not tell you the position in the hierarchy. > Some mechanism to tell the compiler that the expansion is conceptual is needed so the schema tree is not infinitely deep. A "uses-loop" has no stop condition. > 3) Actions: YANG model defined rpc operations that are connected to a > specific resource in the data-model. > Actions are something Ericsson and Tail-f has been using for a long time > and "nearly" got into YANG 1.0 at that time. They are similar, but better > then the YANG rpc construct, because they are connected to managed objects > e.g. lists, so you can have the same action (e.g. restart) on multiple > points in your data model. Also actions are scoped: only visible on the > managed object where they are actually needed. With YANG RPCs it is easy to > and up in one huge list of RPCs visible everywhere. > > You could also just add an instance-identifier leaf to the rpc. Don't you have to do that anyway? How does placing an "action" inside the data tree translate to a NETCONF request? You add the i-i for the data node right? regards Balazs Andy > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1134f15211db4a04fd4b17a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

IMO we cannot keep adding on new fe= atures to YANG 1.1, especially
features that have been discussed = and rejected many times already.
Your list might be OK for YANG 2= .0 features


On Thu, = Jul 3, 2014 at 6:50 AM, Balazs Lengyel <balazs.lengyel@ericsson.= com> wrote:
Hello,
Ericsson decided that we would need 3 additions to the list of issues for Y= ANG 1.1. I am really sorry for bringing up issues this late, but after the = internal decision that Ericsson should become more active around Netconf (w= hich I hope is a gain for the Netconf community), the following issues beca= me really important for us.

1) Non-Unique leaf-list: YANG shall allow leaf-lists whose members are not = unique.
They are needed in a number of cases especially for user-ordered lists, whe= re the position is stable and =A0carries a meaning.


YANG insert "before" and &qu= ot;after" attributes and delete/remove operations would not work corre= ctly.

2) Recursive containment: Allow groupings to "use" themselves the= mselves directly or indirectly.
It is needed =A0e.g. for modeling Hierarchical QOS (Que-in-Que), HW Equipme= nt information (replaceable-unit in replaceable-unit) or representing a fil= e system (directories in directories). All these cases are modeled naturall= y as a containment hierarchy even if they could be handled using a referenc= e list.
Besides being more intuitive models with recursive containment have one dis= tinct advantage over reference based solutions. If recursive containment is= used it is easy to point out exactly which Que/ Replaceable unit/Directory= is addressed. For the exact understanding of the item it is needed to know= where it is placed in a hierarchy, e.g an instance-identifier type address= would contain its position in the containment hierarchy. If we use a flat = list of items and use references to indicate how they are related, which it= em "contains" which, then the instance identifier will not tell y= ou the position in the hierarchy.

Some mechanism to tell the compiler that t= he expansion is conceptual is needed
so the schema tree is not in= finitely deep. =A0A "uses-loop" has no stop condition.




3) Actions: YANG model defined rpc operations that are connected to a speci= fic resource in the data-model.
Actions are something Ericsson and Tail-f has been using for a long time an= d "nearly" got into YANG 1.0 at that time. They are similar, but = better then the YANG rpc construct, because they are connected to managed o= bjects e.g. lists, so you can have the same action (e.g. restart) on multip= le points in your data model. Also actions are scoped: only visible on the = managed object where they are actually needed. With YANG RPCs it is easy to= and up in one huge list of RPCs visible everywhere.



You could also just add= an instance-identifier leaf to the <restart> rpc.
Don'= t you have to do that anyway? =A0How does placing an "action" ins= ide
the data tree translate to a NETCONF <rpc> request? You add the = i-i
for the data node right?

regards Balazs


Andy
=A0


--
Balazs Lengyel =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ericsson Hungary= Ltd.
Mobile: +36-70-330-7909 =A0 =A0 =A0 =A0 =A0 =A0 =A0email: Balazs.Lengyel@ericsson.com=

_______________________________________________
netmod mailing list
netmod@ietf.org = https://www.ietf.org/mailman/listinfo/netmod

--001a1134f15211db4a04fd4b17a1-- From nobody Thu Jul 3 08:21:59 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640E71A004B for ; Thu, 3 Jul 2014 08:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3uLGUYNwPAm for ; Thu, 3 Jul 2014 08:21:55 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B8921A01A5 for ; Thu, 3 Jul 2014 08:21:55 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D953C72D for ; Thu, 3 Jul 2014 17:21:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id v9P8ygwI5F-B for ; Thu, 3 Jul 2014 17:21:36 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Thu, 3 Jul 2014 17:21:53 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3FD2E2002C for ; Thu, 3 Jul 2014 17:21:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id R8_ccmUTBWMo; Thu, 3 Jul 2014 17:21:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 859DE20017; Thu, 3 Jul 2014 17:21:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AB1AF2DA126A; Thu, 3 Jul 2014 17:21:51 +0200 (CEST) Date: Thu, 3 Jul 2014 17:21:51 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140703152150.GB41677@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/MYZh2t4Qv1TK-EKHSY7UT-haOsw Subject: [netmod] json or i-json - this is my question X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jul 2014 15:21:57 -0000 Hi, can someone (Lada) explain how http://tools.ietf.org/html/draft-ietf-netmod-yang-json-00 relates to http://tools.ietf.org/html/draft-ietf-json-i-json-02 and whether any changes are necessary to conform to the i-json restricted profile of json? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Jul 3 09:07:11 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F4E1A0356 for ; Thu, 3 Jul 2014 09:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STE7ffOkjd0E for ; Thu, 3 Jul 2014 09:07:07 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id F23C31A0330 for ; Thu, 3 Jul 2014 09:07:06 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id AAFBF12806AF for ; Thu, 3 Jul 2014 18:03:59 +0200 (CEST) Date: Thu, 03 Jul 2014 18:07:05 +0200 (CEST) Message-Id: <20140703.180705.279723088.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Thu_Jul__3_18_07_05_2014_895)--" Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/tJrwH_R9ddtLzx5jkOX81oKoQpA Subject: [netmod] Fw: I-D Action: draft-ietf-netmod-rfc6020bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 16:07:09 -0000 ----Next_Part(Thu_Jul__3_18_07_05_2014_895)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, This initial -00 draft is RFC 6020 + applied errata + introduction of yang-version 1.1. As soon as we start to close issues, I will update the draft and clearly mark which issues each revision address. With the introduction of yang-version 1.1, the question is if this spec should obsolete RFC 6020, or just leave it as it is. For comparison, SMIv1 is not obsoleted by SMIv2. /martin ----Next_Part(Thu_Jul__3_18_07_05_2014_895)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on serenity.tail-f.com X-Spam-Level: X-Spam-Status: No, score=-104.8 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RP_MATCHES_RCVD,SPF_PASS,T_DKIM_INVALID, USER_IN_WHITELIST autolearn=ham autolearn_force=no version=3.4.0 X-Original-To: mbj@tail-f.com Delivered-To: mbj@tail-f.com Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) by mail.tail-f.com (Postfix) with ESMTPS id 99B5B1280052; Thu, 3 Jul 2014 13:56:03 +0200 (CEST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7511B290E; Thu, 3 Jul 2014 04:58:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1404388723; bh=s129mV7JmqKFyOmmQNfQ5tyXMXaNcBhCKde2DoeSoGU=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=tK4hwMNXcmfNVKXfLmlTZgNljTxD+35X+Ls09zycTZL6TZlOvVbABqI2jBDVvNZMM Gj6ZJIPYFyt8jA7tO4YeutxIVbh2Ii9LS9ImtzE4LoiEj4i9U0x5SdMNN38tFjpW2R 7GEIe01Ix72MMBQ0Lr0VttXSpYSq3VM309mYo9H4= X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BEB1B28FA; Thu, 3 Jul 2014 04:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aj3j1pe-DULn; Thu, 3 Jul 2014 04:58:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 282B81A0A74; Thu, 3 Jul 2014 04:58:37 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140703115837.26792.90471.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 04:58:37 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/NFUpIbiZF4JLrv5fyX3FAS0z15E Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: netmod-bounces@ietf.org Sender: "netmod" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 int cnt prob spamicity histogram 0.00 108 0.017409 0.016582 ################################################ 0.10 6 0.111159 0.022433 ### 0.20 0 0.000000 0.022433 0.30 0 0.000000 0.022433 0.40 0 0.000000 0.022433 0.50 0 0.000000 0.022433 0.60 0 0.000000 0.022433 0.70 0 0.000000 0.022433 0.80 0 0.000000 0.022433 0.90 0 0.000000 0.022433 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) Author : Martin Bjorklund Filename : draft-ietf-netmod-rfc6020bis-00.txt Pages : 170 Date : 2014-07-03 Abstract: YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. This document obsoletes RFC 6020. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-00 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/ _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ----Next_Part(Thu_Jul__3_18_07_05_2014_895)---- From nobody Thu Jul 3 09:19:07 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0511B295F for ; Thu, 3 Jul 2014 09:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjgCPZZVRwhP for ; Thu, 3 Jul 2014 09:18:58 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B37B1B2908 for ; Thu, 3 Jul 2014 09:18:58 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 154E3773; Thu, 3 Jul 2014 18:18:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id uz2G2ykdyMCA; Thu, 3 Jul 2014 18:18:39 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 3 Jul 2014 18:18:56 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 89F7720017; Thu, 3 Jul 2014 18:18:56 +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 PCxN-5t1Uatj; Thu, 3 Jul 2014 18:18:55 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 856842002F; Thu, 3 Jul 2014 18:18:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D761C2DA13FE; Thu, 3 Jul 2014 18:18:54 +0200 (CEST) Date: Thu, 3 Jul 2014 18:18:54 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140703161852.GA41925@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20140703.180705.279723088.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140703.180705.279723088.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/YRLjZigUFG5M4QheksolC73PfGg Cc: netmod@ietf.org Subject: Re: [netmod] Fw: I-D Action: draft-ietf-netmod-rfc6020bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jul 2014 16:19:02 -0000 On Thu, Jul 03, 2014 at 06:07:05PM +0200, Martin Bjorklund wrote: > > With the introduction of yang-version 1.1, the question is if this > spec should obsolete RFC 6020, or just leave it as it is. For > comparison, SMIv1 is not obsoleted by SMIv2. > Note that an SMIv1 module is not a valid SMIv2 module and that a manual update by a human is required to turn an SMIv1 module into an SMIv2 module. Given the constraints for YANG 1.1 spelled out in the WG charter, I think we are facing a different situation. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Jul 3 09:28:46 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F001B2B19 for ; Thu, 3 Jul 2014 09:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zl2006uzEUuR for ; Thu, 3 Jul 2014 09:28:42 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 443131B2945 for ; Thu, 3 Jul 2014 09:28:42 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 208D312806AF; Thu, 3 Jul 2014 18:25:35 +0200 (CEST) Date: Thu, 03 Jul 2014 18:28:40 +0200 (CEST) Message-Id: <20140703.182840.516866736.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140703161852.GA41925@elstar.local> References: <20140703.180705.279723088.mbj@tail-f.com> <20140703161852.GA41925@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fHdK9ZKRSwXY_dr-k-P4ysi0u2s Cc: netmod@ietf.org Subject: Re: [netmod] Fw: I-D Action: draft-ietf-netmod-rfc6020bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 16:28:43 -0000 Juergen Schoenwaelder wrote: > On Thu, Jul 03, 2014 at 06:07:05PM +0200, Martin Bjorklund wrote: > > > > With the introduction of yang-version 1.1, the question is if this > > spec should obsolete RFC 6020, or just leave it as it is. For > > comparison, SMIv1 is not obsoleted by SMIv2. > > > > Note that an SMIv1 module is not a valid SMIv2 module and that a > manual update by a human is required to turn an SMIv1 module into an > SMIv2 module. Given the constraints for YANG 1.1 spelled out in the WG > charter, I think we are facing a different situation. A valid YANG 1 module is NOT a valid YANG 1.1 module - but all you have to do is change add/change the yang-version statement. (and maybe fix some bug...) If we want to accept a module with yang-version 1, or no yang-version statement, we have to change the grammar to accept yang-version 1 and 1.1, and also, I think, spell out the rules for version 1, at least if we obsolete 6020. /martin From nobody Thu Jul 3 10:28:56 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29BF1B2B57 for ; Thu, 3 Jul 2014 10:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEze002CzljQ for ; Thu, 3 Jul 2014 10:28:48 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F23B71B2B55 for ; Thu, 3 Jul 2014 10:28:47 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id C4EAD13F960; Thu, 3 Jul 2014 19:28:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1404408524; bh=AGIdMWEe5dUo4HSEKkWdN2QTjy7e4EjFh9QubOPp40Q=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=RBMoEIqBRzj0VJRHchbU/gh1CFUKyjlLr7cPoYK6Hy5hhQKBupe950UO9W5A/JdfS SYozELinLtY5KxpRc7OB5pywBKDtGvyquSKp9nE7lM0WxFq5o2ab8ZbNVyH6DPhcCO LCMW/gIpIXwzUDPzGCGsZPWG+MqkRBkNfH14jO58= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ladislav Lhotka In-Reply-To: <20140703152150.GB41677@elstar.local> Date: Thu, 3 Jul 2014 19:28:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0B238E16-62E4-4F50-A9DD-1AEDDAA415C3@nic.cz> References: <20140703152150.GB41677@elstar.local> To: =?iso-8859-1?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.2) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_Bo9V88cEdhnaxGibrod63soFTU Cc: netmod@ietf.org Subject: Re: [netmod] json or i-json - this is my question X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 17:28:50 -0000 On 03 Jul 2014, at 17:21, Juergen Schoenwaelder = wrote: > Hi, >=20 > can someone (Lada) explain how=20 >=20 > http://tools.ietf.org/html/draft-ietf-netmod-yang-json-00 >=20 > relates to >=20 > http://tools.ietf.org/html/draft-ietf-json-i-json-02 >=20 > and whether any changes are necessary to conform to the i-json > restricted profile of json? JSON documents resulting from the mapping in yang-json-00 conform to = I-JSON spec, including the RECOMMENDED parts - I only have slight doubts = about sections 2.1 (text about unpaired surrogates), and 2.2 (because I = think sender of NETCONF data exprects a receiver of an uint64 leaf to be = able to treat it as an exact value). Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jul 3 10:54:04 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1F91A0552 for ; Thu, 3 Jul 2014 10:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Cu_Eh8epBp2 for ; Thu, 3 Jul 2014 10:54:01 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3239F1A0300 for ; Thu, 3 Jul 2014 10:54:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 92C45540744 for ; Thu, 3 Jul 2014 19:53:58 +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 N8AAOKS3vu1D for ; Thu, 3 Jul 2014 19:53:54 +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 B5D57540447 for ; Thu, 3 Jul 2014 19:53:54 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Thu, 03 Jul 2014 19:53:53 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/THvl9Vw3tZDa80wTQsVllHhrJ5I Subject: [netmod] updates to issue list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 17:54:03 -0000 Hi, I committed the following changes to the YANG 1.1 issue list: - alternative solution Y10-02 - example showing that solution Y18-01 doesn't work reliably. I am copying the example here so that we can discuss it: leaf A { when "../B = 1"; mandatory true; ... } leaf B { when "../C = 2"; type uint8; default 1; } leaf C { type uint8; } Now, if an instance document (repository) doesn't contain A and B but C is present with the value of 2, then 1. If the server starts with checking node A, then B is not present, so mandatory statement doesn't apply => the document is valid. 2. But if the server starts with checking node B, then its "when" expression is true, the default applies and the "when" expression for A becomes true => the document is invalid. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jul 3 14:03:15 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3173A1A0350 for ; Thu, 3 Jul 2014 14:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5igJOSqb-aFD for ; Thu, 3 Jul 2014 14:03:08 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 296241A0240 for ; Thu, 3 Jul 2014 14:03:08 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 004A0128097A; Thu, 3 Jul 2014 22:59:59 +0200 (CEST) Date: Thu, 03 Jul 2014 23:03:06 +0200 (CEST) Message-Id: <20140703.230306.388363984.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/KdAaLWivz8anokQQsjjgeb0lAuc Cc: netmod@ietf.org Subject: Re: [netmod] updates to issue list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 21:03:12 -0000 Ladislav Lhotka wrote: > Hi, > > I committed the following changes to the YANG 1.1 issue list: > > - alternative solution Y10-02 > > - example showing that solution Y18-01 doesn't work reliably. > > I am copying the example here so that we can discuss it: > > leaf A { > when "../B = 1"; > mandatory true; > ... > } > leaf B { > when "../C = 2"; > type uint8; > default 1; > } > leaf C { > type uint8; > } > > Now, if an instance document (repository) doesn't contain A and B > but C is present with the value of 2, then > > 1. If the server starts with checking node A, then B is not present, so > mandatory statement doesn't apply => the document is valid. > 2. But if the server starts with checking node B, then its "when" > expression is true, the default applies and the "when" > expression for A becomes true => the document is invalid. Three comments: 1. This has nothing to do with the context node problem. You get the same "problem" if you use absolute paths to the leafs: leaf A { when "/B = 1"; ... } leaf B { when "/C = 1"; } 2. We have already agreed that it is possible to write stupid models. For example it is legal to write: leaf X { mandatory true; must "1 = 2"; } which leads to a situation where anything you try to configure is illegal. 3. Andy has pointed out several times how 'when' evaluation is tricky to implement. In the example above, you cannot simply pick an order and evaluate the when expressions in that order. You have to follow the dependencies. So, the interpretation is: since C is 2, leaf B's default value is in effect, and thus leaf A's mandatory statement applies, and the instance document is invalid (since A was not present). /martin From nobody Thu Jul 3 17:14:14 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E67D1B2B94 for ; Thu, 3 Jul 2014 17:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Liq0-lGjyYbF for ; Thu, 3 Jul 2014 17:14:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 040681B2B91 for ; Thu, 3 Jul 2014 17:14:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGT80365; Fri, 04 Jul 2014 00:14:10 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Jul 2014 01:14:08 +0100 Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.247]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Fri, 4 Jul 2014 08:13:59 +0800 From: Zhengguangying To: "netmod@ietf.org" Thread-Topic: New Version Notification for draft-zheng-netmod-integrate-operations-00.txt Thread-Index: Ac+XHNnmXAm3bbW4QPyICK0DJdqxpw== Date: Fri, 4 Jul 2014 00:13:58 +0000 Message-ID: <381D7D55085B1E4D8B581BD652E1E14058C5B646@nkgeml504-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.33.139] Content-Type: multipart/alternative; boundary="_000_381D7D55085B1E4D8B581BD652E1E14058C5B646nkgeml504mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fDtH6W0_7J8zIdtsem-NE2Cu91Q Cc: Yangang Subject: [netmod] FW: New Version Notification for draft-zheng-netmod-integrate-operations-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 00:14:14 -0000 --_000_381D7D55085B1E4D8B581BD652E1E14058C5B646nkgeml504mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsIGluIE5ldG1vZCAsDQoNCiAgICBJbiBzb21lIGRhdGFzdG9yZSBvcGVyYXRpb24gc2Nl bmFyaW9zLCB0aGUgb3BlcmF0aW9ucyB0cmlnZ2VyZWQgZnJvbSB0aGUgIE5FVENPTkYgY2xpZW50 IG1pZ2h0IGJlIGEgc2V0IG9mIGNvbWJpbmVkIG9wZXJhdGlvbnMgb3IgYSBjb21wbGV4IHNpbmds ZSBvcGVyYXRpb24gd2l0aGluIHRoZSBORVRDT05GIGFnZW50LCB3aGljaCBtYXkgY2hhbmdlIHRo ZSBkYXRhc3RvcmVzLiBBbmQgIHNvbWV0aW1lcyB0aGUgZGF0YXN0b3JlIGNoYW5nZSBtaWdodCBu b3QgYmUgZnJvbSBjbGllbnQgYnV0IGZyb20gdGhlIGFnZW50IGl0c2VsZi4gVGhlc2Ugb3BlcmF0 aW9ucyBuZWVkIHRvIG1hbmlwdWxhdGUgdGhlIGRhdGEgaW4gcnVubmluZyBkYXRhc3RvcmUgb3Ig Y2FuZGlkYXRlIGRhdGFzdG9yZSwgYW5kIHRodXMgdGhleSBuZWVkIHRoZSA8ZWRpdC1jb25maWc+ IGNhcGFiaWxpdHkgYSB3ZWxsIGFzIGEgdW5pZmllZCBhdXRob3JpemF0aW9uIHN5c3RlbSB0byBj b250cm9sIHRoZSBpbmZsdWVuY2UgdG8gdGhlIGRhdGEgICBzdG9yZXMgY2F1c2VkIGJ5IHRoZW0u DQogIFNvIHdlIHdyb3RlIGEgZHJhZnQgdG8gdHJ5IHRvIG1ha2UgYSAgZGlzY3Vzc2lvbiBvZiB0 aGUgaXNzdWUuIFRoZSBkcmFmdCBhbmFseXplcyB0aGUgc2NlbmFyaW8gYW5kIHJlcXVpcm1lbnRz IGZvciBtb2RlbCBvcGVyYXRpb25zLCBhbmQgYnJpZWZseSBkaXNjdXNzIHNvbWUgcG9zc2libGUg c29sdXRpb25zIHRvIHNhdGlzZnkgdGhlIHJlcXVpcm1lbnRzLg0KUGxlYXNlIHJldmlldyB0aGUg ZHJhZnQgYW5kIGNvbW1lbnQuDQpNYW55IHRoYW5rcyENCkJlc3QgcmVnYXJkcywNClpoZW5nDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IGludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZyBbaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0Kt6LLzcqxvOQ6IDIw MTTE6jfUwjLI1SAxNzo1NA0KytW8/sjLOiBKaXhpYW9mZW5nIChTdGV2ZW4pOyBaaGVuZ2d1YW5n eWluZzsgSml4aWFvZmVuZyAoU3RldmVuKTsgWmhlbmdndWFuZ3lpbmcNCtb3zOI6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtemhlbmctbmV0bW9kLWludGVncmF0ZS1vcGVyYXRp b25zLTAwLnR4dA0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtemhlbmctbmV0bW9kLWlu dGVncmF0ZS1vcGVyYXRpb25zLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBHdWFuZ3lpbmcgWmhlbmcgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4N Cg0KTmFtZTogICAgICAgICAgIGRyYWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3JhdGUtb3BlcmF0aW9u cw0KUmV2aXNpb246ICAgICAgIDAwDQpUaXRsZTogICAgICAgICAgSW50ZWdyYXRpbmcgT3BlcmF0 aW9ucyBpbiBZQU5HIE1vZGVscw0KRG9jdW1lbnQgZGF0ZTogIDIwMTQtMDctMDINCkdyb3VwOiAg ICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICAxMQ0KVVJMOiAg ICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXpoZW5n LW5ldG1vZC1pbnRlZ3JhdGUtb3BlcmF0aW9ucy0wMC50eHQNClN0YXR1czogICAgICAgICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGVuZy1uZXRtb2QtaW50ZWdyYXRl LW9wZXJhdGlvbnMvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtemhlbmctbmV0bW9kLWludGVncmF0ZS1vcGVyYXRpb25zLTAwDQoNCg0KQWJzdHJhY3Q6 DQogICBUaGlzIGRvY3VtZW50IGludHJvZHVjZXMgYW4gZXh0ZW5zaW9uIHRvIFlBTkcuIFRoZSBl eHRlbnNpb24gYWxsb3dzDQogICBvcGVyYXRpb24gbWV0aG9kcyB0byBiZSBkaXJlY3RseSBpbnRl Z3JhdGVkIGluIFlBTkcgbW9kZWxzLg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K --_000_381D7D55085B1E4D8B581BD652E1E14058C5B646nkgeml504mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi all in Netmod ,

    In some datastore operation scenarios, the operations tr= iggered from the  NETCONF client might be a set of combined operations= or a complex single operation within the NETCONF agent, which may change t= he datastores. And  sometimes the datastore change might not be from client but from the agent itself. These operations need to man= ipulate the data in running datastore or candidate datastore, and thus they= need the <edit-config> capability a well as a unified authorization = system to control the influence to the data   stores caused by them.
  So we wrote a draft to try to make a  discussion of the issue. = The draft analyzes the scenario and requirments for model operations, and b= riefly discuss some possible solutions to satisfy the requirments.
Please review the draft and comment.
Many thanks!
Best regards,
Zheng
________________________________________
=B7=A2=BC=FE=C8=CB: internet-drafts@ietf.org [internet-drafts@ietf.org]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA7=D4=C22=C8=D5 17:54
=CA=D5=BC=FE=C8=CB: Jixiaofeng (Steven); Zhengguangying; Jixiaofeng (Steven= ); Zhengguangying
=D6=F7=CC=E2: New Version Notification for draft-zheng-netmod-integrate-ope= rations-00.txt

A new version of I-D, draft-zheng-netmod-integrate-operations-00.txt
has been successfully submitted by Guangying Zheng and posted to the
IETF repository.

Name:           draft-zhe= ng-netmod-integrate-operations
Revision:       00
Title:          Integrating Op= erations in YANG Models
Document date:  2014-07-02
Group:          Individual Sub= mission
Pages:          11
URL:            http://www.ietf.org/internet-drafts/draft-zheng-netmod-integrate-operations= -00.txt
Status:         https://datatracker.ietf.org/doc/draft-zheng-netmod-integrate-operations/
Htmlized:       http://tools.ietf.org/html/draft-zheng-netmod-integrate-operations-00

Abstract:
   This document introduces an extension to YANG. The extension a= llows
   operation methods to be directly integrated in YANG models.



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
--_000_381D7D55085B1E4D8B581BD652E1E14058C5B646nkgeml504mbxchi_-- From nobody Thu Jul 3 20:07:24 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD61E1B2B2E for ; Thu, 3 Jul 2014 20:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wphLbaUyOYDp for ; Thu, 3 Jul 2014 20:07:20 -0700 (PDT) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA8771B2A61 for ; Thu, 3 Jul 2014 20:07:19 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id r5so1010196qcx.22 for ; Thu, 03 Jul 2014 20:07:19 -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=DltpzZZKtTaXlZKA3C/+8bMKy6sOJsljwVIalhK/7Hc=; b=G7NBm69Qao+beKS0UtFl6bwdAr9UiEsXeQy7JSRvUAp/2/MAB8vYkxW6GhV0ebY+7i FbfSdxJyay0RW7y/QXfr2JY3b+U0D7UycW6ljL8ig68d1emxAVJ8MOElPFYwGDiS4Z4r ufkVo2yvMAO9z/g/OKvjYs4ONeNjlYharThNLfdbi05b9fyfuS/T7GQQsjq9+i18axZO b5L7A54rUmAgXczP3s97pmSNgcgV5gUjzsqyERRivW1uv/2hZ4Z1sMbR187V5MS3DLsd BZIGSLfIRXxJjdMoqhmuy8Wq2lo7BPan5jp/8ACHIcF9zSYIFhSErBopoTukjYgSkYRe p6+A== X-Gm-Message-State: ALoCoQlCImBcRK9WUABWEfP3f6l5wGm3e937P7FsLOc9GOKVAx2e9T103MwuxHpfShmnDjH1rD6V MIME-Version: 1.0 X-Received: by 10.224.124.74 with SMTP id t10mr14268856qar.78.1404443238733; Thu, 03 Jul 2014 20:07:18 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Thu, 3 Jul 2014 20:07:18 -0700 (PDT) In-Reply-To: <53B55FA8.8090501@ericsson.com> References: <53B55FA8.8090501@ericsson.com> Date: Thu, 3 Jul 2014 20:07:18 -0700 Message-ID: From: Andy Bierman To: Balazs Lengyel Content-Type: multipart/alternative; boundary=001a11c295125a2d5304fd556c22 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/oCOVUDQCWnvOxAHaoTITL_H3v9I Cc: "netmod@ietf.org >> netmod@ietf.org" Subject: Re: [netmod] New YANG issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 03:07:22 -0000 --001a11c295125a2d5304fd556c22 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 3, 2014 at 6:50 AM, Balazs Lengyel wrote: > Hello, > Ericsson decided that we would need 3 additions to the list of issues for > YANG 1.1. I am really sorry for bringing up issues this late, but after the > internal decision that Ericsson should become more active around Netconf > (which I hope is a gain for the Netconf community), the following issues > became really important for us. > > 1) Non-Unique leaf-list: YANG shall allow leaf-lists whose members are not > unique. > They are needed in a number of cases especially for user-ordered lists, > where the position is stable and carries a meaning. > > I actually like this one, but I think this is a more general problem which has been raised before, but should be reconsidered. Perhaps YANG 1.1 should allow user-ordered lists and leaf-lists to be keyed by the sibling order, and not require any keys. That would solve your problem. It actually shows up in the example-jukebox "playlist" in RESTCONF. This is a list instead of a leaf-list just so a dummy key can be defined, just so duplicates can be allowed in the playlist. YANG 1.0: list song { key index; ordered-by user; description "Example nested configuration data resource"; leaf index { // not really needed type uint32; description "An arbitrary integer index for this playlist song."; // <<<<< Yuch!!! } leaf id { type rc:data-resource-identifier; mandatory true; description "Song identifier. Must identify an instance of /jukebox/library/artist/album/song/name."; } } Maybe YANG 1.1: leaf-list song { ordered-by user; type rc:data-resource-identifier; description "Song identifier. Must identify an instance of /jukebox/library/artist/album/song/name."; } IMO this is a lot cleaner (You are right Balazs) There would need to be a way in NETCONF to insert and delete by position instead of keys or leaf-list value. (e.g add position="N" attribute in YANG 1.1 to go with the "insert" and nc:operation="delete" attributes). > regards Balazs Andy --001a11c295125a2d5304fd556c22 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Jul 3, 2014 at 6:50 AM, Balazs Lengyel &l= t;balazs.l= engyel@ericsson.com> wrote:
Hello,
Ericsson decided that we would need 3 additions to the list of issues for Y= ANG 1.1. I am really sorry for bringing up issues this late, but after the = internal decision that Ericsson should become more active around Netconf (w= hich I hope is a gain for the Netconf community), the following issues beca= me really important for us.

1) Non-Unique leaf-list: YANG shall allow leaf-lists whose members are not = unique.
They are needed in a number of cases especially for user-ordered lists, whe= re the position is stable and =A0carries a meaning.


I actually like this one, but I think = this is a more general problem
which has been raised before, but = should be reconsidered.

Perhaps YANG 1.1 should al= low user-ordered lists and leaf-lists to be keyed by
the sibling order, and not require any keys. =A0That would solve your = problem.
It actually shows up in the example-jukebox "playli= st" in RESTCONF.
This is a list instead of a leaf-list just = so a dummy key can be defined,
just so duplicates can be allowed in the playlist.


YANG 1.0:

=A0 =A0 =A0 = =A0list song {
=A0 =A0 =A0 =A0 =A0key index;
=A0 =A0 = =A0 =A0 =A0ordered-by user;

=A0 =A0 =A0 =A0 =A0description
=A0 =A0 =A0 = =A0 =A0 =A0"Example nested configuration data resource";

=A0 =A0 =A0 =A0 =A0leaf index { =A0 =A0// not really neede= d
=A0 =A0 =A0 =A0 =A0 =A0type uint32;
=A0 =A0 =A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0 =A0 = =A0"An arbitrary integer index for this playlist song."; =A0 // = =A0<<<<< Yuch!!!
=A0 =A0 =A0 =A0 =A0}
= =A0 =A0 =A0 =A0 =A0leaf id {
=A0 =A0 =A0 =A0 =A0 =A0type rc:data-= resource-identifier;
=A0 =A0 =A0 =A0 =A0 =A0mandatory true;
=A0 =A0 =A0 =A0 =A0 = =A0description
=A0 =A0 =A0 =A0 =A0 =A0 =A0"Song identifier. = Must identify an instance of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 /jukebox= /library/artist/album/song/name.";
=A0 =A0 =A0 =A0 =A0}
=A0 =A0 =A0 =A0}

<= div>
Maybe YANG 1.1:


=
=A0 =A0 =A0 =A0leaf-list song {
=A0 =A0 =A0 =A0 =A0 ordered-= by user;=A0
=A0 =A0 =A0 =A0 =A0 type rc:data-resource-identifier;=
=A0 =A0 =A0 =A0 =A0 description
=A0 =A0 =A0 =A0 =A0 =A0 =A0&= quot;Song identifier. Must identify an instance of
=A0 =A0 =A0 = =A0 =A0 =A0 =A0 /jukebox/library/artist/album/song/name.";
= =A0 =A0 =A0 =A0}

IMO this is a lot cleaner (You are right Balazs)

T= here would need to be a way in NETCONF to insert and delete by position ins= tead of keys
or leaf-list value. (e.g add position=3D"N"= ; attribute in YANG 1.1 to go with the "insert"
and nc:operation=3D"delete" attributes).



=A0
regards Balazs



Andy

--001a11c295125a2d5304fd556c22-- From nobody Thu Jul 3 23:37:00 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1921B2BF3 for ; Thu, 3 Jul 2014 23:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-2IwcG8HsY3 for ; Thu, 3 Jul 2014 23:36:55 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8263A1B2BB6 for ; Thu, 3 Jul 2014 23:36:54 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 1ECD713F960; Fri, 4 Jul 2014 08:36:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1404455812; bh=r4OW//1ICJ8P0pThjt1d+4lSnNpxKNG7rGK28zNZEJs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=pIA34w78/4t0NgpExRnrORpjLB4GCc5WrkvH2+UiXAXmMq0CCOHkt7ZI+1BeVgPy3 9cQG6ARDxrAS1V6kwTw/98YwXP6HARBRT2jwRbxw4vpWZns36tgT76MWJM+6WTah6e bGOxQDSMBVDi2ampYSrKmpB37Frw8nN8I0hJ2bVI= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ladislav Lhotka In-Reply-To: <20140703.230306.388363984.mbj@tail-f.com> Date: Fri, 4 Jul 2014 08:36:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140703.230306.388363984.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1878.2) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/KQRCJfcwBCq2m94ryq1pXpOlpXo Cc: netmod@ietf.org Subject: Re: [netmod] updates to issue list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 06:36:57 -0000 On 03 Jul 2014, at 23:03, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Hi, >>=20 >> I committed the following changes to the YANG 1.1 issue list: >>=20 >> - alternative solution Y10-02 >>=20 >> - example showing that solution Y18-01 doesn't work reliably. >>=20 >> I am copying the example here so that we can discuss it: >>=20 >> leaf A { >> when "../B =3D 1"; >> mandatory true; >> ... >> } >> leaf B { >> when "../C =3D 2"; >> type uint8; >> default 1; >> } >> leaf C { >> type uint8; >> } >>=20 >> Now, if an instance document (repository) doesn't contain A and B >> but C is present with the value of 2, then >>=20 >> 1. If the server starts with checking node A, then B is not = present, so >> mandatory statement doesn't apply =3D> the document is valid.=20 >> 2. But if the server starts with checking node B, then its "when" >> expression is true, the default applies and the "when" >> expression for A becomes true =3D> the document is invalid.=20 >=20 > Three comments: >=20 > 1. This has nothing to do with the context node problem. You get the Of course it does. The context nodes are always A and B, no matter what = the expression is. And if the context node is missing, the XPath = expression is ill-defined. > same "problem" if you use absolute paths to the leafs: >=20 > leaf A { > when "/B =3D 1"; > ... > } > leaf B { > when "/C =3D 1"; > } >=20 Yes, same problem. Note, however, that with =93must=94 instead of =93when=94= everything is fine. >=20 > 2. We have already agreed that it is possible to write stupid > models. For example it is legal to write: >=20 > leaf X { > mandatory true; > must "1 =3D 2"; > } >=20 > which leads to a situation where anything you try to configure is > illegal. First, this example is different because its result is deterministic - = every implementation must classify any document containing X as invalid. Second, a chain of =93when=94 dependencies is far less stupid than this = example - and the nodes can be in different modules. =20 >=20 >=20 > 3. Andy has pointed out several times how 'when' evaluation is > tricky to implement. Yes, because the document schema depends on the particular document = being validated. I think =93when=94 is really useful only on augments. Otherwise, =93must=94= semantics works mostly fine, except the case of =93when=94 being = attached to a mandatory node.=20 >=20 > In the example above, you cannot simply pick an order and evaluate > the when expressions in that order. You have to follow the > dependencies. So, the interpretation is: since C is 2, leaf B's > default value is in effect, and thus leaf A's mandatory statement > applies, and the instance document is invalid (since A was not > present). So the solution to Y18 should describe the procedure in more detail. I do agree though that circular dependencies of =93when=94 expressions = should not normally happen (should be banned in the spec). Lada >=20 >=20 >=20 > /martin >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jul 4 05:44:05 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982FB1B28B4; Fri, 4 Jul 2014 05:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.816 X-Spam-Level: X-Spam-Status: No, score=-2.816 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LONGWORDS=2.035, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yn26XWVig9P0; Fri, 4 Jul 2014 05:43:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8055A1B28B5; Fri, 4 Jul 2014 05:43:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGU33172; Fri, 04 Jul 2014 12:43:50 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Jul 2014 13:43:49 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.24]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 4 Jul 2014 20:43:38 +0800 From: "Liubing (Leo)" To: Andy Bierman Thread-Topic: [Netconf] Multiple instances configuration issues-//FW: New Version Notification for draft-liu-netconf-multi-instances-00.txt Thread-Index: AQHPldswcHtSPLODJEKU9E5gnW6XrZuMlwyAgAEfORA= Date: Fri, 4 Jul 2014 12:43:37 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8F0652@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8ED5BF@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8F0652nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/MnWqAwu7DGRQyZ1C7jBKnVrdlj8 Cc: Zhengguangying , Netconf , "netmod@ietf.org" , Yangang Subject: Re: [netmod] [Netconf] Multiple instances configuration issues-//FW: New Version Notification for draft-liu-netconf-multi-instances-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 12:43:59 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8F0652nkgeml506mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andy, Thanks for your comments. Please see replies inline. From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Thursday, July 03, 2014 2:36 AM To: Liubing (Leo) Cc: Netconf; netmod@ietf.org; Zhengguangying; Yanga= ng Subject: Re: [Netconf] Multiple instances configuration issues-//FW: New Ve= rsion Notification for draft-liu-netconf-multi-instances-00.txt Hi, I read your draft and it I can see use-cases for a context-ID. I prefer to think of named virtual hosts in Apache2, rather than SNMP contexts. [Bing] May I ask the specific reasons that you don't prefer SNMP context? We also had some concern that since context doesn't specify the content, it= may have problem on standardization. But we just thought it could be a fam= iliar concept to the network management people. I don't think your solution is fully specified, but it is a good start. [Bing] Yes, the solution part of the document is mostly a hint for further = discussion. At this stage, we'd like to hear more opinions on the problem/g= ap analysis part. I think the following solution could easily work, which is just a refinement of your solution in sec. 4.1. 1) define a 'server-id' XML attribute 2) define a NETCONF 'virtual-server' capability indicating the server supp= orts the 'server-id' attribute 3) the server is already required to accept all attributes in the st= art tag and return them in the start tag. (So sending the server-id attribute= is safe in all cases). 4) If the server supports the capability, then it must check for the serve= r-id attribute in each and use the correct virtual server or else return an error if it is an= unknown server-id. [Bing] We thought your proposal is also a good solution. If we go this way, then there might be a problem that is a single "server-i= d" sufficient to identify the targeted instance? Since LS and VS might co-e= xist in one device, thus one LS might contain multiple VSes. Then there com= es a hierarchy of the server-id. Maybe we need a comprehensive structure to= well express the hierarchical id? I don't really understand Gap-2 and Gap-3 so I am not addressing that. It = looks like it might overlap the "YANG mount" draft (draft-clemm-netmod-mount-01). IMO that is a completely different problem -- configuration of a mid-level-= manager. [Bing] Gap-2 and Gap-3 are indeed regarding to YANG rather than NETCONF. Le= t me explain them with some examples. Req-2/Gap-2: a YANG model itself needs to support multiple instances, for e= xample: - the routing model (draft-ietf-netmod-routing-cfg) clearly defines = "routing instance" to support VRF instances - the OSPF model (draft-yeung-netmod-ospf) defines "ospf:ospf-af [vr= f-name afi safi]" to support multiple OSPF engines (instances). Say, if an existing model doesn't support multiple instances, and in the fu= ture for some reason we need to manage them as multiple instances. How do w= e extend the existing model? Req-3a/Gap-3a: Configuring a service under another E.g., the above mentioned OSPF module is defined under the routing instance= (VRF) defined in routing model through augment: augment "/rt:routing/rt:routing-instance/rt:routing-protocols/" + "rt:routing-protocol" { list ospf-router { ... Then, we could configure the OSPF under the routing data model, there is no= problem/gap with this example. However, consider another example: if we're= going to write a new model, say, L3VPN, can we just re-use the whole routi= ng model also through augment? (Just to confirm, I'm not sure whether YANG = is able to do this or not. If YANG is already be able to do it, then maybe = we should remove the gap.) Req-3b/Gap-3b: a YANG model needs to be aware of the other's multiple insta= nces E.g., when the above mentioned OSPF model defines "ospf:ospf-af [vrf-name a= fi safi]" to support multiple OSPF engines (instances), it means the OSPF m= odel be aware of the VRF multiple instances, and there is an implication th= at the OSPF instance is binding to the VRF instance. This kind of awareness= /binding might face the scalability issue. Say, if something like VRF comes= out in the future, how does current OSPF model to support that new kind of= instance? For "YANG mount" draft, my personal understanding is that it is a container= to collect different modules in other location together in one place. Whil= e the above gaps are more regarding to relationships between different mode= ls. I think they have different scopes. Best regards, Bing On Wed, Jul 2, 2014 at 2:51 AM, Liubing (Leo) > wrote: Hi all in Netconf & Netmod, In last Netconf meeting in London, my colleague Guangying Zheng raised a qu= estion at the mike about how to distinguish multiple VRFs when using NETCON= F to configure a device. And then in the mailing list, David Lamparter led a very good discussion of= the problem. As discussed in the mailing list, it is not only regarding to VRF, rather, = it is quite a general issue. So we wrote a draft to try to make a comprehensive discussion of the issue.= The draft analyzes the management requirements for multiple instances like= VRF, and pointed out some gaps in current NETCONF protocol and YANG models= . At last, the draft briefly discuss some possible solutions to fill the ga= ps. Please review the draft and comment. Many thanks! Best regards, Bing -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Wednesday, July 02, 2014 4:48 PM To: Liubing (Leo); Liubing (Leo); Yangang; Yangang Subject: New Version Notification for draft-liu-netconf-multi-instances-00.= txt A new version of I-D, draft-liu-netconf-multi-instances-00.txt has been successfully submitted by Bing Liu and posted to the IETF reposito= ry. Name: draft-liu-netconf-multi-instances Revision: 00 Title: Multi-Instances Configuration Issue in NETCONF Document date: 2014-07-02 Group: Individual Submission Pages: 10 URL: http://www.ietf.org/internet-drafts/draft-liu-netconf-multi= -instances-00.txt Status: https://datatracker.ietf.org/doc/draft-liu-netconf-multi-in= stances/ Htmlized: http://tools.ietf.org/html/draft-liu-netconf-multi-instance= s-00 Abstract: This document puts together the NETCONF issues of configuring multiple instances including configuring multiple network element instances and multiple service instances. The main problem is how to configure the multiple instances in one NETCONF channel. 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8F0652nkgeml506mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andy,

 = ;

Thanks for= your comments. Please see replies inline.

 = ;

From: Andy Bierman [m= ailto:andy@yumaworks.com]
Sent: Thursday, July 03, 2014 2:36 AM
To: Liubing (Leo)
Cc: Netconf; netmod@ietf.org;= Zhengguangying; Yangang
Subject: Re: [Netconf] Multiple instances configuration issues-//FW:= New Version Notification for draft-liu-netconf-multi-instances-00.txt=

 

Hi,

 

I read your draft and it I can = see use-cases for a context-ID.

I prefer to think of named virt= ual hosts in Apache2, rather than

SNMP contexts.

[Bing] May= I ask the specific reasons that you don’t prefer SNMP context?

We also ha= d some concern that since context doesn’t specify the content, it may= have problem on standardization. But we just thought it could be a familiar concept to the network management people.

 

I don't think your solution is = fully specified, but it is a good start.

[Bing] Yes= , the solution part of the document is mostly a hint for further discussion= . At this stage, we’d like to hear more opinions on the problem/gap analysis part.

 = ;

I think the following solution = could easily work, which is just a

refinement of your solution in = sec. 4.1.

 

 1) define a 'server-id' X= ML attribute

 2) define a NETCONF 'virt= ual-server' capability indicating the server supports the 'server-id' attri= bute

 3) the server is already = required to accept all attributes in the <rpc> start tag and return

     them in the= <rpc-reply> start tag. (So sending the server-id attribute is safe i= n all cases).

 4) If the server supports= the capability, then it must check for the server-id attribute in each <= ;rpc>

     and use the= correct virtual server or else return an error if it is an unknown server-= id.

 = ;

[Bing] We = thought your proposal is also a good solution.

If we go t= his way, then there might be a problem that is a single “server-id= 221; sufficient to identify the targeted instance? Since LS and VS might co-exist in one device, thus one LS might contain multiple VSes. Then ther= e comes a hierarchy of the server-id. Maybe we need a comprehensive structu= re to well express the hierarchical id?

 

I don't really understand Gap-2= and Gap-3 so I am not addressing that.  It looks like

it might overlap the "YANG= mount" draft (draft-clemm-netmod-mount-01).

IMO that is a completely differ= ent problem -- configuration of a mid-level-manager.

&n= bsp;

[Bing] Gap= -2 and Gap-3 are indeed regarding to YANG rather than NETCONF. Let me expla= in them with some examples.

 = ;

Req-2/Gap-= 2: a YANG model itself needs to support multiple instances, for example:

-th= e routing model (draft-ietf-netmod-routing-cfg) clearly defines “rout= ing instance” to support VRF instances

-th= e OSPF model (draft-yeung-netmod-ospf) defines “ospf:ospf-af [vrf-nam= e afi safi]” to support multiple OSPF engines (instances).=

Say, if an= existing model doesn’t support multiple instances, and in the future= for some reason we need to manage them as multiple instances. How do we extend the existing model?

 = ;

Req-3a/Gap= -3a: Configuring a service under another

E.g., the = above mentioned OSPF module is defined under the routing instance (VRF) def= ined in routing model through augment:  

augment "/rt:routing/rt:routing-instance/rt:routing-= protocols/"

         + &q= uot;rt:routing-protocol" {

 &nbs= p;   list ospf-router {

 &nbs= p;   ...

Then, we c= ould configure the OSPF under the routing data model, there is no problem/g= ap with this example. However, consider another example: if we’re going to write a new model, say, L3VPN, can we just re-use the= whole routing model also through augment? (Just to confirm, I’m not = sure whether YANG is able to do this or not. If YANG is already be able to = do it, then maybe we should remove the gap.)

 = ;

Req-3b/Gap= -3b: a YANG model needs to be aware of the other’s multiple instances=

E.g., when= the above mentioned OSPF model defines “ospf:ospf-af [vrf-name afi s= afi]” to support multiple OSPF engines (instances), it means the OSPF model be aware of the VRF multiple instances, and there is an implica= tion that the OSPF instance is binding to the VRF instance. This kind of aw= areness/binding might face the scalability issue. Say, if something like VR= F comes out in the future, how does current OSPF model to support that new kind of instance?

 = ;

For "= YANG mount" draft, my personal understanding is that it is a container= to collect different modules in other location together in one place. While the above gaps are more regarding to relationships between different= models. I think they have different scopes.

 = ;

Best regar= ds,

Bing<= /o:p>

 = ;

 = ;

 = ;

 

On Wed, Jul 2, 2014 at 2:51 AM,= Liubing (Leo) <leo.liubing@huawei.com> wrote:

Hi all in Netconf & Netmod,=

In last Netconf meeting in London, my colleague Guangying Zheng raised a qu= estion at the mike about how to distinguish multiple VRFs when using NETCON= F to configure a device.
And then in the mailing list, David Lamparter led a very good discussion of= the problem.

As discussed in the mailing list, it is not only regarding to VRF, rather, = it is quite a general issue.
So we wrote a draft to try to make a comprehensive discussion of the issue.= The draft analyzes the management requirements for multiple instances like= VRF, and pointed out some gaps in current NETCONF protocol and YANG models= . At last, the draft briefly discuss some possible solutions to fill the gaps.

Please review the draft and comment.
Many thanks!

Best regards,
Bing


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Wednesday, July 02, 2014 4:48 PM
To: Liubing (Leo); Liubing (Leo); Yangang; Yangang
Subject: New Version Notification for draft-liu-netconf-multi-instances-00.= txt


A new version of I-D, draft-liu-netconf-multi-instances-00.txt
has been successfully submitted by Bing Liu and posted to the IETF reposito= ry.

Name:           draft-liu-netconf-multi-instances<= br> Revision:       00
Title:          Multi-Instances Configuration Issu= e in NETCONF
Document date:  2014-07-02
Group:          Individual Submission
Pages:          10
URL:            http://www.ietf.org/internet-drafts/draft-liu-netconf-multi-instances-00= .txt
Status:         https://datatracker.ietf.org/doc/draft-liu-netconf-multi-instances/
Htmlized:       http://tools.ietf.org/html/draft-liu-netconf-multi-instances-00


Abstract:
   This document puts together the NETCONF issues of configuring<= br>    multiple instances including configuring multiple network elem= ent
   instances and multiple service instances. The main problem is = how to
   configure the multiple instances in one NETCONF channel.




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

_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf

 

--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8F0652nkgeml506mbxchi_-- From nobody Fri Jul 4 06:52:44 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA891B2971 for ; Fri, 4 Jul 2014 06:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 385tRDBf-xxi for ; Fri, 4 Jul 2014 06:52:40 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7728C1B296D for ; Fri, 4 Jul 2014 06:52:40 -0700 (PDT) Received: from [192.168.1.118] (static-72-71-250-37.cncdnh.fast04.myfairpoint.net [72.71.250.37]) by lucidvision.com (Postfix) with ESMTP id 0E89B280DC46 for ; Fri, 4 Jul 2014 09:52:40 -0400 (EDT) From: "Thomas D. Nadeau" Content-Type: multipart/signed; boundary="Apple-Mail=_489146DB-1D0D-4660-A2CE-1D9EDF088A92"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Fri, 4 Jul 2014 09:52:39 -0400 References: <20140703203944.25295.49227.idtracker@ietfa.amsl.com> To: netmod@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/8-qu6LdzWlrUnyGoBNXFQsub-kw Subject: [netmod] Fwd: xml2rfc v2 transition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 13:52:42 -0000 --Apple-Mail=_489146DB-1D0D-4660-A2CE-1D9EDF088A92 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii fyi Begin forwarded message: > From: RFC Series Editor > Subject: xml2rfc v2 transition > Date: July 3, 2014 at 4:39:44 PM EDT > To: IETF Announcement List > Cc: rfc-interest@rfc-editor.org > Reply-To: ietf@ietf.org >=20 > As a reminder to the community, the RFC Editor is transitioning = completely > to xml2rfc v2 for processing XML source for drafts this month. If = your XML=20 > file does not parse using xml2rfc v2, it may be returned to you with a=20= > request to update the XML. Since we do appreciate receiving XML = source for=20 > the drafts which are approved for publication, we encourage those who = are=20 > still working with a tool-chain based on xml2rfc v1 (the TCL releases) = to > transition to v2 (the Python releases). The xml2rfc v2 processor is = more=20 > strict about handling non-wellformed or invalid XML. Please see > for more detail regarding strict handling of = XML. >=20 > The RFC Editor will continue to accept XML source for Internet-Drafts = created > using v1 that were approved for publication by 30 June 2014. >=20 > Authors may also continue to submit documents in nroff or txt if an = XML=20 > source is not available. >=20 > The original announcement is available here: > = = >=20 > If you have questions about xml2rfc v2, please send them to the = xml2rfc > mailing list . >=20 > Heather Flanagan, RFC Series Editor >=20 >=20 --Apple-Mail=_489146DB-1D0D-4660-A2CE-1D9EDF088A92 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTtrGnAAoJEPcO+I7eiUJZ+jUP/Rp9VHLLRx2b2WWAURevUtjR lMqIAXdtNeb3oH5uin6a3H6tkcU/P0tOj4o5Zefb1PTDDJLZqCaCOqeH4klE/6it mJf/68usgynLQtny42vOnfn0L/jcPpveHIrxgJWAKMU45aertK1fRULK3la2VOK1 FSqYY8brBKYQOZ0HDUYB9DwYdOCwhzZx3cDdT/mvfHUhwg3i9DyKjkhfn36/EZE0 MHxbvNv3AO7dsVTlGB+SpkF8gM2BHbthzSczRfi6pzGwUUHGrQnX8iRZAvEQb8Ly kycamJHBeM0R4mehDR8GiN0z5hCUmmjcmX7NDf+Lw84ZDdzSYsSheTAspdPD2pUK 6l0vY1CiwEYfjwCj0bY+e8dROmWvrBGvE5XhY1Ov0cC59Qg5ZIGwIIQ6TcaN7lgO hqKT91tQ91pF1J41VG5Gr90nAOQPQEWUBjik9q3zroGUOMYWUoSQrYm/B/GLdpaM /3ozWjTvu23m/cjLX5atI0UGd+stc737KbvOQHwgRKdFN2e6ZaTBcrVPy0npF/9s VLroXC3ccZANC1E/BsUBQ+1NmddgvKRtiFJ+2CYPb8j2yR7MjfS4hXt8wIk1UGuv pWaIQGwc54vEf5wea3XlK6aO3Ve8NtpLW3JhdzZe1NFQWrKlJRTiGz8csZV3fnzj VjmLAp+RZBkJRVyN0TX4 =2oy7 -----END PGP SIGNATURE----- --Apple-Mail=_489146DB-1D0D-4660-A2CE-1D9EDF088A92-- From nobody Fri Jul 4 08:47:28 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBBA1A0180 for ; Fri, 4 Jul 2014 08:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.757 X-Spam-Level: X-Spam-Status: No, score=0.757 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, LONGWORDS=2.035, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FApIZ_CSl2um for ; Fri, 4 Jul 2014 08:47:12 -0700 (PDT) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF301A01EA for ; Fri, 4 Jul 2014 08:47:12 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id i50so1634907qgf.0 for ; Fri, 04 Jul 2014 08:47:11 -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=yCOzqi6zIqi88Z/LAVQ0eSZyvWff7Fx3RH3+vTW9Km4=; b=lvEi+oFau5Nplnf2Bl87XRwTxqKXY8sBPW1vPGB7xPeTP+y+xqJ5rHfNgMwcBJtFcg 14ECaCRdg1lNqhEsZ0sEK+OyJTLGmF2Jw0uI3dky08axSTAzShEuH0j2pgWXxhySe5q7 pwcI/jUMzS7Y5E2HWzLCgSlwsy7p4kxPqV9DwfiQocdVh84X8qrUOhGYYZoMy1/v4/5u ftqT/jNbfRZD3wlhdLzskXma0QBzjRTpSt5eyBvm89pkjSp5mnEG6efglxR4f+SVZB1N MpUMKsSK1yKXTrw/rI/yqGQ0OhBX7DGKWQCne1u3j7MwER+G8rYpEpZWVWnUn6BXUVEU NOyg== X-Gm-Message-State: ALoCoQlA93QahwifLDHhshxFtep9uXnrFYpB/cUI3ZEu/yQMLZrxa7btMGtZITaNby4a1KMMU44z MIME-Version: 1.0 X-Received: by 10.140.101.115 with SMTP id t106mr18595588qge.91.1404488831329; Fri, 04 Jul 2014 08:47:11 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Fri, 4 Jul 2014 08:47:11 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8F0652@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8ED5BF@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F0652@nkgeml506-mbx.china.huawei.com> Date: Fri, 4 Jul 2014 08:47:11 -0700 Message-ID: From: Andy Bierman To: "Liubing (Leo)" Content-Type: multipart/alternative; boundary=001a11c1721ee2011004fd60092c Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OGXdnV2vheYgIeKdAMb6ZnEnixY Cc: Zhengguangying , Netconf , "netmod@ietf.org" , Yangang Subject: Re: [netmod] [Netconf] Multiple instances configuration issues-//FW: New Version Notification for draft-liu-netconf-multi-instances-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 15:47:16 -0000 --001a11c1721ee2011004fd60092c Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 4, 2014 at 5:43 AM, Liubing (Leo) wrote: > Hi Andy, > > > > Thanks for your comments. Please see replies inline. > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com ] > *Sent:* Thursday, July 03, 2014 2:36 AM > *To:* Liubing (Leo) > *Cc:* Netconf; netmod@ietf.org; Zhengguangying; Yangang > *Subject:* Re: [Netconf] Multiple instances configuration issues-//FW: > New Version Notification for draft-liu-netconf-multi-instances-00.txt > > > > Hi, > > > > I read your draft and it I can see use-cases for a context-ID. > > I prefer to think of named virtual hosts in Apache2, rather than > > SNMP contexts. > > [Bing] May I ask the specific reasons that you don't prefer SNMP context? > > We also had some concern that since context doesn't specify the content, > it may have problem on standardization. But we just thought it could be a > familiar concept to the network management people. > > > I think SNMP Context has been misused. IMO it is better to have an explicit index in a data structure schema, rather than add an INDEX on the side using the context-ID. > I don't think your solution is fully specified, but it is a good start. > > [Bing] Yes, the solution part of the document is mostly a hint for further > discussion. At this stage, we'd like to hear more opinions on the > problem/gap analysis part. > > > > I think the following solution could easily work, which is just a > > refinement of your solution in sec. 4.1. > > > > 1) define a 'server-id' XML attribute > > 2) define a NETCONF 'virtual-server' capability indicating the server > supports the 'server-id' attribute > > 3) the server is already required to accept all attributes in the > start tag and return > > them in the start tag. (So sending the server-id > attribute is safe in all cases). > > 4) If the server supports the capability, then it must check for the > server-id attribute in each > > and use the correct virtual server or else return an error if it is > an unknown server-id. > > > > [Bing] We thought your proposal is also a good solution. > > If we go this way, then there might be a problem that is a single > "server-id" sufficient to identify the targeted instance? Since LS and VS > might co-exist in one device, thus one LS might contain multiple VSes. Then > there comes a hierarchy of the server-id. Maybe we need a comprehensive > structure to well express the hierarchical id? > > > But you had a single context-id. How is that any different? Named virtual hosts are useful in Apache2 because allocating an IP address to each WEB server is not always possible. Each virtual server is its own instance and content is independent across virtual servers. Each HTTP request is routed from the real server to the correct virtual server, based on the hostname in the URL. A hierarchy would have to be based on content, and in that case, a data modeling solution is needed, not nested virtual servers. > I don't really understand Gap-2 and Gap-3 so I am not addressing that. > It looks like > > it might overlap the "YANG mount" draft (draft-clemm-netmod-mount-01). > > IMO that is a completely different problem -- configuration of a > mid-level-manager. > > > > [Bing] Gap-2 and Gap-3 are indeed regarding to YANG rather than NETCONF. > Let me explain them with some examples. > > > > Req-2/Gap-2: a YANG model itself needs to support multiple instances, for > example: > > - the routing model (draft-ietf-netmod-routing-cfg) clearly > defines "routing instance" to support VRF instances > > - the OSPF model (draft-yeung-netmod-ospf) defines "ospf:ospf-af > [vrf-name afi safi]" to support multiple OSPF engines (instances). > > Say, if an existing model doesn't support multiple instances, and in the > future for some reason we need to manage them as multiple instances. How do > we extend the existing model? > Republish the model with the new key. > > > Req-3a/Gap-3a: Configuring a service under another > > E.g., the above mentioned OSPF module is defined under the routing > instance (VRF) defined in routing model through augment: > > augment "/rt:routing/rt:routing-instance/rt:routing-protocols/" > > + "rt:routing-protocol" { > > list ospf-router { > > ... > > Then, we could configure the OSPF under the routing data model, there is > no problem/gap with this example. However, consider another example: if > we're going to write a new model, say, L3VPN, can we just re-use the whole > routing model also through augment? (Just to confirm, I'm not sure whether > YANG is able to do this or not. If YANG is already be able to do it, then > maybe we should remove the gap.) > > > > Req-3b/Gap-3b: a YANG model needs to be aware of the other's multiple > instances > > E.g., when the above mentioned OSPF model defines "ospf:ospf-af [vrf-name > afi safi]" to support multiple OSPF engines (instances), it means the OSPF > model be aware of the VRF multiple instances, and there is an implication > that the OSPF instance is binding to the VRF instance. This kind of > awareness/binding might face the scalability issue. Say, if something like > VRF comes out in the future, how does current OSPF model to support that > new kind of instance? > > > > For "YANG mount" draft, my personal understanding is that it is a > container to collect different modules in other location together in one > place. While the above gaps are more regarding to relationships between > different models. I think they have different scopes. > > > > Best regards, > > Bing > > > > > Andy > > > > > On Wed, Jul 2, 2014 at 2:51 AM, Liubing (Leo) > wrote: > > Hi all in Netconf & Netmod, > > In last Netconf meeting in London, my colleague Guangying Zheng raised a > question at the mike about how to distinguish multiple VRFs when using > NETCONF to configure a device. > And then in the mailing list, David Lamparter led a very good discussion > of the problem. > > As discussed in the mailing list, it is not only regarding to VRF, rather, > it is quite a general issue. > So we wrote a draft to try to make a comprehensive discussion of the > issue. The draft analyzes the management requirements for multiple > instances like VRF, and pointed out some gaps in current NETCONF protocol > and YANG models. At last, the draft briefly discuss some possible solutions > to fill the gaps. > > Please review the draft and comment. > Many thanks! > > Best regards, > Bing > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, July 02, 2014 4:48 PM > To: Liubing (Leo); Liubing (Leo); Yangang; Yangang > Subject: New Version Notification for > draft-liu-netconf-multi-instances-00.txt > > > A new version of I-D, draft-liu-netconf-multi-instances-00.txt > has been successfully submitted by Bing Liu and posted to the IETF > repository. > > Name: draft-liu-netconf-multi-instances > Revision: 00 > Title: Multi-Instances Configuration Issue in NETCONF > Document date: 2014-07-02 > Group: Individual Submission > Pages: 10 > URL: > http://www.ietf.org/internet-drafts/draft-liu-netconf-multi-instances-00.txt > Status: > https://datatracker.ietf.org/doc/draft-liu-netconf-multi-instances/ > Htmlized: > http://tools.ietf.org/html/draft-liu-netconf-multi-instances-00 > > > Abstract: > This document puts together the NETCONF issues of configuring > multiple instances including configuring multiple network element > instances and multiple service instances. The main problem is how to > configure the multiple instances in one NETCONF channel. > > > > > 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 > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > --001a11c1721ee2011004fd60092c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Jul 4, 2014 at 5:43 AM, Liubing (Leo) <= ;leo.liubing@hu= awei.com> wrote:

Hi Andy,

&nb= sp;

Thanks for= your comments. Please see replies inline.

&nb= sp;

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Thursday, July 03, 2014 2:36 AM
To: Liubing (Leo)
Cc: Netconf; ne= tmod@ietf.org; Zhengguangying; Yangang
Subject: Re: [Netconf] Multiple instances configuration issues-//FW:= New Version Notification for draft-liu-netconf-multi-instances-00.txt

 

Hi,

 

I read your draft and it I can = see use-cases for a context-ID.

I prefer to think of named virt= ual hosts in Apache2, rather than

SNMP contexts.

[Bing] May= I ask the specific reasons that you don’t prefer SNMP context?

We also ha= d some concern that since context doesn’t specify the content, it may= have problem on standardization. But we just thought it could be a familiar concept to the network management people.<= /p>

 

<= /div>


I th= ink SNMP Context has been misused.  IMO it is better to have an
<= div>explicit index in a data structure schema, rather than add an INDEX on = the side
using the context-ID.

 

I don't think your solution= is fully specified, but it is a good start.

[Bing] Yes= , the solution part of the document is mostly a hint for further discussion= . At this stage, we’d like to hear more opinions on the problem/gap analysis part.

&nb= sp;

I think the following solution = could easily work, which is just a

refinement of your solution in = sec. 4.1.

 

 1) define a 'server-i= d' XML attribute

 2) define a NETCONF '= virtual-server' capability indicating the server supports the 'serv= er-id' attribute

 3) the server is already = required to accept all attributes in the <rpc> start tag and return

     them in the= <rpc-reply> start tag. (So sending the server-id attribute is safe i= n all cases).

 4) If the server supports= the capability, then it must check for the server-id attribute in each <= ;rpc>

     and use the= correct virtual server or else return an error if it is an unknown server-= id.

&nb= sp;

[Bing] We = thought your proposal is also a good solution.

If we go t= his way, then there might be a problem that is a single “server-id&rd= quo; sufficient to identify the targeted instance? Since LS and VS might co-exist in one device, thus one LS might contain multiple VSes. Then ther= e comes a hierarchy of the server-id. Maybe we need a comprehensive structu= re to well express the hierarchical id?

 

<= /div>


But = you had a single context-id.  How is that any different?
Named virtual hosts are useful in Apache2 because allocating an IP address = to
each WEB server is not always possible.  Each virtual ser= ver is its own instance and
content is independent across virtual= servers.  Each HTTP request is routed from the
real server to the correct virtual server, based on the hostname in th= e URL.

A hierarchy would have to be based on conte= nt, and in that case,
a data modeling solution is needed, not nes= ted virtual servers.



 
<= div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4= .0pt">

I don't really understand G= ap-2 and Gap-3 so I am not addressing that.  It looks like

it might overlap the "YANG= mount" draft (draft-clemm-netmod-mount-01).

IMO that is a completely differ= ent problem -- configuration of a mid-level-manager.

=  

[Bing] Gap= -2 and Gap-3 are indeed regarding to YANG rather than NETCONF. Let me expla= in them with some examples.

&nb= sp;

Req-2/Gap-= 2: a YANG model itself needs to support multiple instances, for example:=

-      &nb= sp; the r= outing model (draft-ietf-netmod-routing-cfg) clearly defines “routing= instance” to support VRF instances

-      &nb= sp; the O= SPF model (draft-yeung-netmod-ospf) defines “ospf:ospf-af [vrf-name a= fi safi]” to support multiple OSPF engines (instances).=

Say, if an= existing model doesn’t support multiple instances, and in the future= for some reason we need to manage them as multiple instances. How do we extend the existing model?

<= /blockquote>

Republish the model with the new key.
=
 

&nb= sp;

Req-3a/Gap= -3a: Configuring a service under another

E.g., the = above mentioned OSPF module is defined under the routing instance (VRF) def= ined in routing model through augment:  

augment "/rt:routing/rt:routing-instance/rt:routing-= protocols/"

         + "= rt:routing-protocol" {

 &nbs= p;   list ospf-router {

 &nbs= p;   ...

Then, we c= ould configure the OSPF under the routing data model, there is no problem/g= ap with this example. However, consider another example: if we’re going to write a new model, say, L3VPN, can we just re-use the= whole routing model also through augment? (Just to confirm, I’m not = sure whether YANG is able to do this or not. If YANG is already be able to = do it, then maybe we should remove the gap.)

&nb= sp;

Req-3b/Gap= -3b: a YANG model needs to be aware of the other’s multiple instances=

E.g., when= the above mentioned OSPF model defines “ospf:ospf-af [vrf-name afi s= afi]” to support multiple OSPF engines (instances), it means the OSPF model be aware of the VRF multiple instances, and there is an implica= tion that the OSPF instance is binding to the VRF instance. This kind of aw= areness/binding might face the scalability issue. Say, if something like VR= F comes out in the future, how does current OSPF model to support that new kind of instance?

&nb= sp;

For "= YANG mount" draft, my personal understanding is that it is a container= to collect different modules in other location together in one place. While the above gaps are more regarding to relationships between different= models. I think they have different scopes.

&nb= sp;

Best regar= ds,

Bing

&nb= sp;

&nb= sp;


Andy
 

=

&nb= sp;

 

On Wed, Jul 2, 2014 at 2:51 AM,= Liubing (Leo) <leo.liubing@huawei.com> wrote:

Hi all in Netconf & Netmod,=

In last Netconf meeting in London, my colleague Guangying Zheng raised a qu= estion at the mike about how to distinguish multiple VRFs when using NETCON= F to configure a device.
And then in the mailing list, David Lamparter led a very good discussion of= the problem.

As discussed in the mailing list, it is not only regarding to VRF, rather, = it is quite a general issue.
So we wrote a draft to try to make a comprehensive discussion of the issue.= The draft analyzes the management requirements for multiple instances like= VRF, and pointed out some gaps in current NETCONF protocol and YANG models= . At last, the draft briefly discuss some possible solutions to fill the gaps.

Please review the draft and comment.
Many thanks!

Best regards,
Bing


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Wednesday, July 02, 2014 4:48 PM
To: Liubing (Leo); Liubing (Leo); Yangang; Yangang
Subject: New Version Notification for draft-liu-netconf-multi-instances-00.= txt


A new version of I-D, draft-liu-netconf-multi-instances-00.txt
has been successfully submitted by Bing Liu and posted to the IETF reposito= ry.

Name:           draft-liu-netconf-multi-instances<= br> Revision:       00
Title:          Multi-Instances Configuration Issu= e in NETCONF
Document date:  2014-07-02
Group:          Individual Submission
Pages:          10
URL:            http://www.ietf.org/internet-drafts/draft-liu-netconf-multi-instances-00= .txt
Status:         https://datatracker.ietf.org/doc/draft-liu-netconf-multi-instances/
Htmlized:       http://tools.ietf.org/html/draft-liu-netconf-multi-instances-00


Abstract:
   This document puts together the NETCONF issues of configuring<= br>    multiple instances including configuring multiple network elem= ent
   instances and multiple service instances. The main problem is = how to
   configure the multiple instances in one NETCONF channel.




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

_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf

 


--001a11c1721ee2011004fd60092c-- From nobody Fri Jul 4 10:08:51 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8D71B2B15 for ; Fri, 4 Jul 2014 10:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCm4E3W2Zj56 for ; Fri, 4 Jul 2014 10:08:49 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58C401B280F for ; Fri, 4 Jul 2014 10:08:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2817; q=dns/txt; s=iport; t=1404493729; x=1405703329; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=vdWTpQGfTnUAqexIjydPRAOFc+MCKloKa69ZAgn7pGo=; b=WLj277o87qkg9RwSBBX1rVcV6NNMduMyFWxtus8oLmx1v1FkN9ORmHtt rha1rD8YT+Bq1OIZmm3upjaUahU5D5kXGHsjQUVAKcNGyM6RhxUrJNGxp +/w6Ie+2HTIU5ylviS5z8m9IcLIg7tJ4RkpRobBLCV/iWtwyqLp/2tt5l 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAIjetlOtJA2K/2dsb2JhbABQCoJqJIEfDcYrAYELFnWEBQEEOisUEgEqFEImAQQODYg6AcpbF45GKzGDNIEWBa8Cg0OCMA X-IronPort-AV: E=Sophos;i="5.01,602,1400025600"; d="scan'208";a="58373222" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-3.cisco.com with ESMTP; 04 Jul 2014 17:08:48 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s64H8mSk026471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 4 Jul 2014 17:08:48 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 12:08:48 -0500 From: "Nobo Akiya (nobo)" To: "Tissa Senevirathne (tsenevir)" Thread-Topic: Comments on draft-tissa-netmod-oam-01 Thread-Index: Ac+XqFYxYsJYmgtCT72I7Nhf1mmspQ== Date: Fri, 4 Jul 2014 17:08:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/AcGzLSiE5ql8VgUqYo93g6OCJtc Cc: "netmod@ietf.org" Subject: [netmod] Comments on draft-tissa-netmod-oam-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 17:08:50 -0000 Hi Tissa, authors, First of all, intent of this document seems widely beneficial. I am interes= ted to see how and In what form this document will progress. Please find below few comments I have on the draft-tissa-netmod-oam-01, fro= m a quick look at the document. Comment #1: Section 6 [snip] typedef CCM-Interval { default "interval-1min"; type enumeration { enum "interval-invalid" { value 0; } ... enum "interval-10min" { value 7; } } ... } [snip] When considering all OAM tools out there, defining a hard coded set of inte= rvals (via enum) may not be a good idea. BFD implementations (SW/HW) spring= s to my mind immediately. For HW based BFD, BFD WG is working on an informa= tional document for recommended set of intervals: draft-ietf-bfd-intervals.= However, intervals outside of that set can still be implemented by vendors= for HW based BFD. SW based BFD, obviously, has much more flexibility in th= e range of intervals to use. A better approach may be to change above from = enum to identify ref (or something else) which can be augmented. Comment #2: Section 6 [snip] typedef ecmp-choices { type enumeration { enum "ecmp-use-platform-hash" { value 0; } enum "ecmp-use-round-robin" { value 1; } } } [snip] leaf ecmp-choice { config true; type ecmp-choices; description "0 means use the specified interface 1 means use round robin"; } [snip] Above two seems a bit conflicting for the value of zero(0). Former states t= hat zero(0) indicates usage of platform hash but the latter indicates that = specific interface is used (i.e. not hashed?). Thinking about this, I belie= ve "ecmp-choices" is overloaded. You actually want to be able to describe 3= different things here. 1. Configuring a specific load balancing technique on a system (ex: EL, rou= nd-robin or something else). 2. Describing the output behavior on the OAM instance (ex: out to specific = interface vs. load balanced). 3. Describe the setting on the path discovery OAM instance (ex: LSP tree tr= ace using multipath 2, 4, 8, 9, 10). Perhaps a different object for each may be a good idea. (2) can be an enum = but it'll be beneficial to be able for various OAM tools to augment (1) and= (3). Comment #3: Section 6 [snip] typedef oam-counter32 { type yang:zero-based-counter32; description "defines 32 bit counter for OAM"; } [snip] No 64 bit counter? Thanks! -Nobo From nobody Mon Jul 7 00:45:50 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBFE1B2793; Mon, 7 Jul 2014 00:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.816 X-Spam-Level: X-Spam-Status: No, score=-2.816 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LONGWORDS=2.035, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JLgVWlI4er0; Mon, 7 Jul 2014 00:45:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C48D51A8BB3; Mon, 7 Jul 2014 00:45:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJR87830; Mon, 07 Jul 2014 07:45:38 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 7 Jul 2014 08:45:00 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.24]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Mon, 7 Jul 2014 15:44:48 +0800 From: "Liubing (Leo)" To: Andy Bierman Thread-Topic: [Netconf] Multiple instances configuration issues-//FW: New Version Notification for draft-liu-netconf-multi-instances-00.txt Thread-Index: AQHPldswcHtSPLODJEKU9E5gnW6XrZuMlwyAgAEfORCAAdZYgIAEmsjA Date: Mon, 7 Jul 2014 07:44:48 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8F12D1@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8ED5BF@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F0652@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8F12D1nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/iNuJ6DX98tLw7Go_ATdDWwwP3q8 Cc: Zhengguangying , Netconf , "netmod@ietf.org" , Yangang Subject: Re: [netmod] [Netconf] Multiple instances configuration issues-//FW: New Version Notification for draft-liu-netconf-multi-instances-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 07:45:45 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8F12D1nkgeml506mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andy, Hi, I read your draft and it I can see use-cases for a context-ID. I prefer to think of named virtual hosts in Apache2, rather than SNMP contexts. [Bing] May I ask the specific reasons that you don't prefer SNMP context? We also had some concern that since context doesn't specify the content, it= may have problem on standardization. But we just thought it could be a fam= iliar concept to the network management people. I think SNMP Context has been misused. IMO it is better to have an explicit index in a data structure schema, rather than add an INDEX on the = side using the context-ID. [Bing] I see your point. An explicit data structure schema might be better = for standardization. We'll consider your approach at the solution discussio= n stage. I don't think your solution is fully specified, but it is a good start. [Bing] Yes, the solution part of the document is mostly a hint for further = discussion. At this stage, we'd like to hear more opinions on the problem/g= ap analysis part. I think the following solution could easily work, which is just a refinement of your solution in sec. 4.1. 1) define a 'server-id' XML attribute 2) define a NETCONF 'virtual-server' capability indicating the server supp= orts the 'server-id' attribute 3) the server is already required to accept all attributes in the st= art tag and return them in the start tag. (So sending the server-id attribute= is safe in all cases). 4) If the server supports the capability, then it must check for the serve= r-id attribute in each and use the correct virtual server or else return an error if it is an= unknown server-id. [Bing] We thought your proposal is also a good solution. If we go this way, then there might be a problem that is a single "server-i= d" sufficient to identify the targeted instance? Since LS and VS might co-e= xist in one device, thus one LS might contain multiple VSes. Then there com= es a hierarchy of the server-id. Maybe we need a comprehensive structure to= well express the hierarchical id? But you had a single context-id. How is that any different? [Bing] Context doesn't specify the content, so it could be coded to implici= tly express the hierarchical id. Nevertheless, I was not arguing context is better on this issue. I was just= thinking, if we follow the way of explicitly specifying the "server-id" at= tribute, then maybe the attribute itself needs to support hierarchy express= of the targeted instance. Named virtual hosts are useful in Apache2 because allocating an IP address = to each WEB server is not always possible. Each virtual server is its own ins= tance and content is independent across virtual servers. Each HTTP request is routed= from the real server to the correct virtual server, based on the hostname in the URL= . A hierarchy would have to be based on content, and in that case, a data modeling solution is needed, not nested virtual servers. [Bing] This is the HTTP Server case. Considering a complicated router, whi= ch is divided into several Logical Systems, and each Logical System contain= several Virtual Systems doing different routing tasks. Then a single hostn= ame is not sufficient enough to represent the VS, there needs to be a hiera= rchical expression such as "LS_name.VS_name". I don't really understand Gap-2 and Gap-3 so I am not addressing that. It = looks like it might overlap the "YANG mount" draft (draft-clemm-netmod-mount-01). IMO that is a completely different problem -- configuration of a mid-level-= manager. [Bing] Gap-2 and Gap-3 are indeed regarding to YANG rather than NETCONF. Le= t me explain them with some examples. Req-2/Gap-2: a YANG model itself needs to support multiple instances, for e= xample: - the routing model (draft-ietf-netmod-routing-cfg) clearly defines = "routing instance" to support VRF instances - the OSPF model (draft-yeung-netmod-ospf) defines "ospf:ospf-af [vr= f-name afi safi]" to support multiple OSPF engines (instances). Say, if an existing model doesn't support multiple instances, and in the fu= ture for some reason we need to manage them as multiple instances. How do w= e extend the existing model? Republish the model with the new key. [Bing] This is certainly an approach. We including this as a gap is to see whether there could be a more scalable= solution, such as Section 4.2 "Common Service Container". Best regards, Bing Req-3a/Gap-3a: Configuring a service under another E.g., the above mentioned OSPF module is defined under the routing instance= (VRF) defined in routing model through augment: augment "/rt:routing/rt:routing-instance/rt:routing-protocols/" + "rt:routing-protocol" { list ospf-router { ... Then, we could configure the OSPF under the routing data model, there is no= problem/gap with this example. However, consider another example: if we're= going to write a new model, say, L3VPN, can we just re-use the whole routi= ng model also through augment? (Just to confirm, I'm not sure whether YANG = is able to do this or not. If YANG is already be able to do it, then maybe = we should remove the gap.) Req-3b/Gap-3b: a YANG model needs to be aware of the other's multiple insta= nces E.g., when the above mentioned OSPF model defines "ospf:ospf-af [vrf-name a= fi safi]" to support multiple OSPF engines (instances), it means the OSPF m= odel be aware of the VRF multiple instances, and there is an implication th= at the OSPF instance is binding to the VRF instance. This kind of awareness= /binding might face the scalability issue. Say, if something like VRF comes= out in the future, how does current OSPF model to support that new kind of= instance? For "YANG mount" draft, my personal understanding is that it is a container= to collect different modules in other location together in one place. Whil= e the above gaps are more regarding to relationships between different mode= ls. I think they have different scopes. Best regards, Bing Andy On Wed, Jul 2, 2014 at 2:51 AM, Liubing (Leo) > wrote: Hi all in Netconf & Netmod, In last Netconf meeting in London, my colleague Guangying Zheng raised a qu= estion at the mike about how to distinguish multiple VRFs when using NETCON= F to configure a device. And then in the mailing list, David Lamparter led a very good discussion of= the problem. As discussed in the mailing list, it is not only regarding to VRF, rather, = it is quite a general issue. So we wrote a draft to try to make a comprehensive discussion of the issue.= The draft analyzes the management requirements for multiple instances like= VRF, and pointed out some gaps in current NETCONF protocol and YANG models= . At last, the draft briefly discuss some possible solutions to fill the ga= ps. Please review the draft and comment. Many thanks! Best regards, Bing -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Wednesday, July 02, 2014 4:48 PM To: Liubing (Leo); Liubing (Leo); Yangang; Yangang Subject: New Version Notification for draft-liu-netconf-multi-instances-00.= txt A new version of I-D, draft-liu-netconf-multi-instances-00.txt has been successfully submitted by Bing Liu and posted to the IETF reposito= ry. Name: draft-liu-netconf-multi-instances Revision: 00 Title: Multi-Instances Configuration Issue in NETCONF Document date: 2014-07-02 Group: Individual Submission Pages: 10 URL: http://www.ietf.org/internet-drafts/draft-liu-netconf-multi= -instances-00.txt Status: https://datatracker.ietf.org/doc/draft-liu-netconf-multi-in= stances/ Htmlized: http://tools.ietf.org/html/draft-liu-netconf-multi-instance= s-00 Abstract: This document puts together the NETCONF issues of configuring multiple instances including configuring multiple network element instances and multiple service instances. The main problem is how to configure the multiple instances in one NETCONF channel. 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8F12D1nkgeml506mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andy,

 = ;

Hi,

 

I read your draft and it I can see use-cases = for a context-ID.

I prefer to think of named virtual hosts in A= pache2, rather than

SNMP contexts.

[Bing] May I ask the spe= cific reasons that you don’t prefer SNMP context?

We also had some concern= that since context doesn’t specify the content, it may have problem on standardization. But we just thought it could be a familiar con= cept to the network management people.

 

 

I think SNMP Context has been m= isused.  IMO it is better to have an

explicit index in a data struct= ure schema, rather than add an INDEX on the side

using the context-ID.

[Bing] = I see your point. An explicit data structure schema might be better for sta= ndardization. We’ll consider your approach at the solution discussion= stage.

 

I don't think your solution is fully specifie= d, but it is a good start.

[Bing] Yes, the solution= part of the document is mostly a hint for further discussion. At this stage, we’d like to hear more opinions on the problem/gap an= alysis part.

 

I think the following solution could easily w= ork, which is just a

refinement of your solution in sec. 4.1.=

 

 1) define a 'server-id' XML attribute

 2) define a NETCONF 'virtual-server' ca= pability indicating the server supports the 'server-id' attribute

 3) the server is already required to ac= cept all attributes in the <rpc> start tag and return

     them in the <rpc-reply= > start tag. (So sending the server-id attribute is safe in all cases).<= o:p>

 4) If the server supports the capabilit= y, then it must check for the server-id attribute in each <rpc><= /o:p>

     and use the correct virtu= al server or else return an error if it is an unknown server-id.=

 

[Bing] We thought your p= roposal is also a good solution.

If we go this way, then = there might be a problem that is a single “server-id” sufficien= t to identify the targeted instance? Since LS and VS might co-exist in one d= evice, thus one LS might contain multiple VSes. Then there comes a hierarch= y of the server-id. Maybe we need a comprehensive structure to well express= the hierarchical id?

 

 

 

But you had a single context-id= .  How is that any different?

[Bing] = Context doesn't specify the content, so it could be coded to implicitly exp= ress the hierarchical id.

Neverth= eless, I was not arguing context is better on this issue. I was just thinki= ng, if we follow the way of explicitly specifying the “server-id̶= 1; attribute, then maybe the attribute itself needs to support hierarchy express of the targeted instance.  

 

Named virtual hosts are useful = in Apache2 because allocating an IP address to

each WEB server is not always p= ossible.  Each virtual server is its own instance and

content is independent across v= irtual servers.  Each HTTP request is routed from the

real server to the correct virt= ual server, based on the hostname in the URL.

 

A hierarchy would have to be ba= sed on content, and in that case,

a data modeling solution is nee= ded, not nested virtual servers.

[Bing] = This is the HTTP Server case.  Considering a complicated router, which= is divided into several Logical Systems, and each Logical System contain s= everal Virtual Systems doing different routing tasks. Then a single hostname is not sufficient enough to represent the VS= , there needs to be a hierarchical expression such as “LS_name.VS_nam= e”.

 

 

 

I don't really understand Gap-2 and Gap-3 so = I am not addressing that.  It looks like

it might overlap the "YANG mount" d= raft (draft-clemm-netmod-mount-01).

IMO that is a completely different problem --= configuration of a mid-level-manager.

 

[Bing] Gap-2 and Gap-3 a= re indeed regarding to YANG rather than NETCONF. Let me explain them with some examples.

 

Req-2/Gap-2: a YANG mode= l itself needs to support multiple instances, for example:

-=  &= nbsp;      the routing model (draft-i= etf-netmod-routing-cfg) clearly defines “routing instance” to s= upport VRF instances

-=  &= nbsp;      the OSPF model (draft-yeun= g-netmod-ospf) defines “ospf:ospf-af [vrf-name afi safi]” to su= pport multiple OSPF engines (instances).

Say, if an existing mode= l doesn’t support multiple instances, and in the future for some reason we need to manage them as multiple instances. How do we extend= the existing model?

 

Republish the model with the ne= w key.

[Bing] = This is certainly an approach.

We incl= uding this as a gap is to see whether there could be a more scalable soluti= on, such as Section 4.2 “Common Service Container”.<= /span>

 = ;

Best re= gards,

Bing

 

Req-3a/Gap-3a: Configuri= ng a service under another

E.g., the above mentione= d OSPF module is defined under the routing instance (VRF) defined in routing model through augment:  <= /o:p>

augment "/rt:routing/rt:rout= ing-instance/rt:routing-protocols/"

     &nb= sp;   + "rt:routing-protocol" {

    = list ospf-router {

    = ...

Then, we could configure= the OSPF under the routing data model, there is no problem/gap with this example. However, consider another example: if we’re going= to write a new model, say, L3VPN, can we just re-use the whole routing mod= el also through augment? (Just to confirm, I’m not sure whether YANG = is able to do this or not. If YANG is already be able to do it, then maybe we should remove the gap.)

 

Req-3b/Gap-3b: a YANG mo= del needs to be aware of the other’s multiple instances

E.g., when the above men= tioned OSPF model defines “ospf:ospf-af [vrf-name afi safi]” to support multiple OSPF engines (instances), it means the OSPF model be a= ware of the VRF multiple instances, and there is an implication that the OS= PF instance is binding to the VRF instance. This kind of awareness/binding = might face the scalability issue. Say, if something like VRF comes out in the future, how does current OSPF = model to support that new kind of instance?

 

For "YANG mount&quo= t; draft, my personal understanding is that it is a container to collect different modules in other location together in one place. While the above= gaps are more regarding to relationships between different models. I think= they have different scopes.<= /p>

 

Best regards,

Bing

 

 

 

Andy

 

 

 

On Wed, Jul 2, 2014 at 2:51 AM, Liubing (Leo)= <leo.liubin= g@huawei.com> wrote:

Hi all in Netconf & Netmod,

In last Netconf meeting in London, my colleague Guangying Zheng raised a qu= estion at the mike about how to distinguish multiple VRFs when using NETCON= F to configure a device.
And then in the mailing list, David Lamparter led a very good discussion of= the problem.

As discussed in the mailing list, it is not only regarding to VRF, rather, = it is quite a general issue.
So we wrote a draft to try to make a comprehensive discussion of the issue.= The draft analyzes the management requirements for multiple instances like= VRF, and pointed out some gaps in current NETCONF protocol and YANG models= . At last, the draft briefly discuss some possible solutions to fill the gaps.

Please review the draft and comment.
Many thanks!

Best regards,
Bing


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Wednesday, July 02, 2014 4:48 PM
To: Liubing (Leo); Liubing (Leo); Yangang; Yangang
Subject: New Version Notification for draft-liu-netconf-multi-instances-00.= txt


A new version of I-D, draft-liu-netconf-multi-instances-00.txt
has been successfully submitted by Bing Liu and posted to the IETF reposito= ry.

Name:           draft-liu-netconf-multi-instances<= br> Revision:       00
Title:          Multi-Instances Configuration Issu= e in NETCONF
Document date:  2014-07-02
Group:          Individual Submission
Pages:          10
URL:            http://www.ietf.org/internet-drafts/draft-liu-netconf-multi-instances-00= .txt
Status:         https://datatracker.ietf.org/doc/draft-liu-netconf-multi-instances/
Htmlized:       http://tools.ietf.org/html/draft-liu-netconf-multi-instances-00


Abstract:
   This document puts together the NETCONF issues of configuring<= br>    multiple instances including configuring multiple network elem= ent
   instances and multiple service instances. The main problem is = how to
   configure the multiple instances in one NETCONF channel.




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

_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf

 

 

--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8F12D1nkgeml506mbxchi_-- From nobody Mon Jul 7 02:11:07 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624001B27F0 for ; Mon, 7 Jul 2014 02:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PM1g_tSPW2cV for ; Mon, 7 Jul 2014 02:11:00 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39FC51A00FD for ; Mon, 7 Jul 2014 02:11:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id C2C1A540143; Mon, 7 Jul 2014 11:10:57 +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 Wxn4zlwb2OHm; Mon, 7 Jul 2014 11:10:52 +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 59DA3540138; Mon, 7 Jul 2014 11:10:52 +0200 (CEST) From: Ladislav Lhotka To: Jernej Tuljak , NETMOD Working Group In-Reply-To: <53B53A2C.7010607@mg-soft.com> References: <53B53A2C.7010607@mg-soft.com> User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Mon, 07 Jul 2014 11:10:51 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/W43Ecwwjlc9PfebCnLDSUiH_PtE Subject: Re: [netmod] YANG XPath usage guidelines (6087bis) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 09:11:06 -0000 Jernej Tuljak writes: > Hi, > > some questions about YANG XPath expressions in general and as observed > by 6087bis [1]. > > Does it make sense to use the 'id(object)' and 'lang(string)' XPath > functions in YANG XPath expressions? They both imply existence of XML > attributes, which cannot be modeled in pure YANG. Shouldn't RFC6087bis > include a guideline for those in Section 4.5.? Is there a case where the > mentioned XPath functions could be used? Now that there are several proposals for standardizing (global) attributes for use with YANG data, it might actually be useful to refer to attributes in XPath expressions. One use case could be: "Nodes X and Y can both be present only if at least one of them is tagged as inactive". But in order to be able to do this, one needs to be able to include an attribute's namespace in the context of the XPath expression - this is another case where the "attribute" statement (issue Y33) would be useful. > > 'local-name(node-set?)', 'namespace-uri(node-set?)', 'name(node-set?)', > 'string(object?)' and 'number(object?)' are all directly reliant on > document order when the argument evaluates to a node-set with size > 1 > and may therefore return different results for different > implementations, like the case with 'position' and 'last'. Other > functions may also be indirectly reliant on document order when they are > supplied with a node-set argument which then needs to be converted into > a string or a number as if by calling 'string(object?)' or > 'number(object?)' respectively [2]. Shouldn't this also be mentioned in > the guidelines, since some other cases are? > > Axes 'preceding-sibling' and 'following-sibling' should not be used > unless dealing with user ordered lists or leaf-lists and I agree with > 6087bis, however document order may not be relevant when using those two > axes (uniqueness checks). There's an example in ietf-routing module [3]: > not(/routing/ribs/rib[name=current()/preceding-sibling::connected-rib/rib-name > and > address-family=/routing/ribs/rib[name=current()/rib-name]/address-family]) > where current() evaluates to a non-user ordered list instance. Shouldn't > this also be mentioned in the guidelines as an acceptable corner case, > like it is for 'preceding' and 'following'? I think the following text in 6087bis should be extended to cover "preceding-sibling" and "following-sibling" as well: "The 'preceding' and 'following' axes MAY be used if document order is not relevant to the outcome of the expression (e.g., check for global uniqueness of a parameter value)." > > 6087bis specifies: > > XPath expressions for 'when' statements MUST NOT reference the > context node or any descendant nodes of the context node. > > yet ietf-ipv4-unicast-routing [3] clearly does so, with it's > conditional The example in sec. 3.3 of RFC 7223 does it, too. > augments of rpc methods, where it references 'rt:address-family' which > is a descendant of the initial context node (augmentation target or > nearest data node ancestor). Shouldn't conditional augmentation be an > exception to this paragraph? Yes. In fact, many of the concerns regarding "when" (see e.g. issue Y18) don't apply if it is used under "augment" because the result of "when" evaluation doesn't affect the context node. > > 6087bis specifies: > > Data nodes that use the 'int64' and 'uint64' built-in type SHOULD NOT > be used within numeric expressions. There are boundary conditions in > which the translation from the YANG 64-bit type to an XPath number > can cause incorrect results. Specifically, an XPath 'double' > precision floating point number cannot represent very large positive > or negative 64-bit numbers because it only provides a total precision > of 53 bits. The 'int64' and 'uint64' data types MAY be used in > numeric expressions if the value can be represented with no more than > 53 bits of precision. > > In XPath specification [4], term "numeric expressions" refers to > additive (+, -), multiplicative (*, mod, div) or unary expressions > (sign) and does not include relational or equality expressions, so > comparisons of int64 and uint64 data nodes do not seem to be discouraged > by the current text. Was this intentional? Shouldn't all such numeric > conversions be avoided? > > Ladislav once mentioned [5] that YANG XPath is able to "break out of > module containment" with an expression like > /*[local-name()='foo'] > which is quite dangerous and IMO deserves mention in the guidelines. It > should be clear that an expression is only able to reference names > defined within the scope of a module, right? Or was "breaking out of > module containment" intended as a feature of RFC6020 (seems more like a > bug to me)? Completely unrelated modules should not cause unwanted side > effects when implemented together. +1 Lada > > [1] > http://tools.ietf.org/html/draft-bierman-netmod-rfc6087bis-00#section-4.5 > [2] http://www.w3.org/TR/1999/REC-xpath-19991116/#section-Function-Calls > [3] http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-15 > [4] http://www.w3.org/TR/1999/REC-xpath-19991116/#numbers > [5] http://www.ietf.org/mail-archive/web/netmod/current/msg09623.html > > Jernej > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jul 7 02:17:51 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB1A1B27EA for ; Mon, 7 Jul 2014 02:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qH3Nj34f9p76 for ; Mon, 7 Jul 2014 02:17:47 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0DBB1A00FD for ; Mon, 7 Jul 2014 02:17:47 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 69AEF740; Mon, 7 Jul 2014 11:17:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id RQYnPsGdf5Ec; Mon, 7 Jul 2014 11:17:43 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 7 Jul 2014 11:17:45 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BB4AF20017; Mon, 7 Jul 2014 11:17:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id M5_k6eTUKo4Z; Mon, 7 Jul 2014 11:17:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C9A8B2002C; Mon, 7 Jul 2014 11:17:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A99392DBE3F6; Mon, 7 Jul 2014 11:17:43 +0200 (CEST) Date: Mon, 7 Jul 2014 11:17:41 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140707091741.GA2560@elstar.local> Mail-Followup-To: Ladislav Lhotka , Jernej Tuljak , NETMOD Working Group References: <53B53A2C.7010607@mg-soft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/n2fG3b_aqUKmOSPHHvRpZIvFgdM Cc: NETMOD Working Group Subject: Re: [netmod] YANG XPath usage guidelines (6087bis) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jul 2014 09:17:49 -0000 On Mon, Jul 07, 2014 at 11:10:51AM +0200, Ladislav Lhotka wrote: > Jernej Tuljak writes: > > > Hi, > > > > some questions about YANG XPath expressions in general and as observed > > by 6087bis [1]. > > > > Does it make sense to use the 'id(object)' and 'lang(string)' XPath > > functions in YANG XPath expressions? They both imply existence of XML > > attributes, which cannot be modeled in pure YANG. Shouldn't RFC6087bis > > include a guideline for those in Section 4.5.? Is there a case where the > > mentioned XPath functions could be used? > > Now that there are several proposals for standardizing (global) > attributes for use with YANG data, it might actually be useful to refer > to attributes in XPath expressions. One use case could be: "Nodes X and > Y can both be present only if at least one of them is tagged as > inactive". > > But in order to be able to do this, one needs to be able to include an > attribute's namespace in the context of the XPath expression - this is > another case where the "attribute" statement (issue Y33) would be useful. > I am not sure we have agreement to make attributes first class citizens and in any case we should think carefully before stepping on what might turn out to be a rather slippery road. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jul 7 02:24:23 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25CF41B27F0 for ; Mon, 7 Jul 2014 02:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LW71boq06IPX for ; Mon, 7 Jul 2014 02:24:21 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06E1A1A00FD for ; Mon, 7 Jul 2014 02:24:21 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 485E8140858; Mon, 7 Jul 2014 11:24:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1404725059; bh=zIIC6PWUTPzO0N8wegEW0caIKZpsffdlP/nnFuo+eWM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ZrML37xoVubsghNgbQPrp0zXBK58zz+itWgSA8jdNwTvB3mic4zbG8tseHwv2Mn4Y Dm2MmMXGo7gapijf06b2kXO7EoByFCaQyoYOjOHFENSp+MvXFuItWCXdpEVlLJROVR EoI2rXbplDHylZc8VnLUwGXnjMkE3KSruoqFgmiM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ladislav Lhotka In-Reply-To: <20140707091741.GA2560@elstar.local> Date: Mon, 7 Jul 2014 11:24:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53B53A2C.7010607@mg-soft.com> <20140707091741.GA2560@elstar.local> To: =?iso-8859-1?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.2) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/bwx7JmPXXgP4lGKzJbzIXwKjv2Y Cc: NETMOD Working Group Subject: Re: [netmod] YANG XPath usage guidelines (6087bis) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 09:24:22 -0000 On 07 Jul 2014, at 11:17, Juergen Schoenwaelder = wrote: > On Mon, Jul 07, 2014 at 11:10:51AM +0200, Ladislav Lhotka wrote: >> Jernej Tuljak writes: >>=20 >>> Hi, >>>=20 >>> some questions about YANG XPath expressions in general and as = observed=20 >>> by 6087bis [1]. >>>=20 >>> Does it make sense to use the 'id(object)' and 'lang(string)' XPath=20= >>> functions in YANG XPath expressions? They both imply existence of = XML=20 >>> attributes, which cannot be modeled in pure YANG. Shouldn't = RFC6087bis=20 >>> include a guideline for those in Section 4.5.? Is there a case where = the=20 >>> mentioned XPath functions could be used? >>=20 >> Now that there are several proposals for standardizing (global) >> attributes for use with YANG data, it might actually be useful to = refer >> to attributes in XPath expressions. One use case could be: "Nodes X = and >> Y can both be present only if at least one of them is tagged as >> inactive". >>=20 >> But in order to be able to do this, one needs to be able to include = an >> attribute's namespace in the context of the XPath expression - this = is >> another case where the "attribute" statement (issue Y33) would be = useful. >>=20 >=20 > I am not sure we have agreement to make attributes first class > citizens and in any case we should think carefully before stepping on > what might turn out to be a rather slippery road. Sure, my comment was just a side note about one aspect related to = attributes, should they ever be introduced - even if they are not = first-class citizens. Lada=20 >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jul 7 04:41:41 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CF11B281F for ; Mon, 7 Jul 2014 04:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpSTnWDE-Uij for ; Mon, 7 Jul 2014 04:41:36 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E1F21B27FA for ; Mon, 7 Jul 2014 04:41:35 -0700 (PDT) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id s67BfXd1012770; Mon, 7 Jul 2014 13:41:33 +0200 Message-ID: <53BA876C.6030908@mg-soft.com> Date: Mon, 07 Jul 2014 13:41:32 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ladislav Lhotka References: <53B53A2C.7010607@mg-soft.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/IuitDc__63PWPh7EyKdti2e_zT4 Cc: NETMOD Working Group Subject: Re: [netmod] YANG XPath usage guidelines (6087bis) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 11:41:39 -0000 Dne 7.7.2014 11:10, piše Ladislav Lhotka: > Jernej Tuljak writes: > >> Hi, >> >> some questions about YANG XPath expressions in general and as observed >> by 6087bis [1]. >> >> Does it make sense to use the 'id(object)' and 'lang(string)' XPath >> functions in YANG XPath expressions? They both imply existence of XML >> attributes, which cannot be modeled in pure YANG. Shouldn't RFC6087bis >> include a guideline for those in Section 4.5.? Is there a case where the >> mentioned XPath functions could be used? > Now that there are several proposals for standardizing (global) > attributes for use with YANG data, it might actually be useful to refer > to attributes in XPath expressions. One use case could be: "Nodes X and > Y can both be present only if at least one of them is tagged as > inactive". > > But in order to be able to do this, one needs to be able to include an > attribute's namespace in the context of the XPath expression - this is > another case where the "attribute" statement (issue Y33) would be useful. Perhaps, but the functions I mentioned are quite specific about what attributes they require in order to be implemented. Do you see any use cases that utilize 'id' and 'lang' in the context of NETCONF/YANG? The first requires a DTD, if the XPath spec is to be strictly followed, and the second requires 'xml:lang' attributes - note that YANG does not support definition of identifiers that start with 'xml', so even if you had an "attribute" statement in YANG this would still require an extension, unless an attribute statement could specify it's own namespace and prefix (:D). I realize that XPath is only used as a notation in YANG, but the semantics of an arbitrary expression still need to be well specified. ------ Function: boolean lang(string) The lang function returns true or false depending on whether the language of the context node as specified by xml:lang attributes is the same as or is a sublanguage of the language specified by the argument string. The language of the context node is determined by the value of the xml:lang attribute on the context node, or, if the context node has no xml:lang attribute, by the value of the xml:lang attribute on the nearest ancestor of the context node that has an xml:lang attribute. If there is no such attribute, then lang returns false. If there is such an attribute, then lang returns true if the attribute value is equal to the argument ignoring case, or if there is some suffix starting with - such that the attribute value is equal to the argument ignoring that suffix of the attribute value and ignoring case. For example, lang("en") would return true if the context node is any of these five elements:
Function: node-set id(object) The id function selects elements by their unique ID (see [5.2.1 Unique IDs]). When the argument to id is of type node-set, then the result is the union of the result of applying id to the string-value of each of the nodes in the argument node-set. When the argument to id is of any other type, the argument is converted to a string as if by a call to the string function; the string is split into a whitespace-separated list of tokens (whitespace is any sequence of characters matching the production S); the result is a node-set containing the elements in the same document as the context node that have a unique ID equal to any of the tokens in the list. * id("foo") selects the element with unique ID foo * id("foo")/child::para[position()=5] selects the fifth para child of the element with unique ID foo 5.2.1 Unique IDs An element node may have a unique identifier (ID). This is the value of the attribute that is declared in the DTD as type ID. No two elements in a document may have the same unique ID. If an XML processor reports two elements in a document as having the same unique ID (which is possible only if the document is invalid) then the second element in document order must be treated as not having a unique ID. NOTE: If a document does not have a DTD, then no element in the document will have a unique ID. ------ > >> 'local-name(node-set?)', 'namespace-uri(node-set?)', 'name(node-set?)', >> 'string(object?)' and 'number(object?)' are all directly reliant on >> document order when the argument evaluates to a node-set with size > 1 >> and may therefore return different results for different >> implementations, like the case with 'position' and 'last'. Other >> functions may also be indirectly reliant on document order when they are >> supplied with a node-set argument which then needs to be converted into >> a string or a number as if by calling 'string(object?)' or >> 'number(object?)' respectively [2]. Shouldn't this also be mentioned in >> the guidelines, since some other cases are? >> >> Axes 'preceding-sibling' and 'following-sibling' should not be used >> unless dealing with user ordered lists or leaf-lists and I agree with >> 6087bis, however document order may not be relevant when using those two >> axes (uniqueness checks). There's an example in ietf-routing module [3]: >> not(/routing/ribs/rib[name=current()/preceding-sibling::connected-rib/rib-name >> and >> address-family=/routing/ribs/rib[name=current()/rib-name]/address-family]) >> where current() evaluates to a non-user ordered list instance. Shouldn't >> this also be mentioned in the guidelines as an acceptable corner case, >> like it is for 'preceding' and 'following'? > I think the following text in 6087bis should be extended to cover > "preceding-sibling" and "following-sibling" as well: > > "The 'preceding' and 'following' axes MAY be used if document order is > not relevant to the outcome of the expression (e.g., check for global > uniqueness of a parameter value)." I agree. Jernej >> 6087bis specifies: >> >> XPath expressions for 'when' statements MUST NOT reference the >> context node or any descendant nodes of the context node. >> >> yet ietf-ipv4-unicast-routing [3] clearly does so, with it's >> conditional > The example in sec. 3.3 of RFC 7223 does it, too. > >> augments of rpc methods, where it references 'rt:address-family' which >> is a descendant of the initial context node (augmentation target or >> nearest data node ancestor). Shouldn't conditional augmentation be an >> exception to this paragraph? > Yes. In fact, many of the concerns regarding "when" (see e.g. issue Y18) > don't apply if it is used under "augment" because the result of "when" > evaluation doesn't affect the context node. > >> 6087bis specifies: >> >> Data nodes that use the 'int64' and 'uint64' built-in type SHOULD NOT >> be used within numeric expressions. There are boundary conditions in >> which the translation from the YANG 64-bit type to an XPath number >> can cause incorrect results. Specifically, an XPath 'double' >> precision floating point number cannot represent very large positive >> or negative 64-bit numbers because it only provides a total precision >> of 53 bits. The 'int64' and 'uint64' data types MAY be used in >> numeric expressions if the value can be represented with no more than >> 53 bits of precision. >> >> In XPath specification [4], term "numeric expressions" refers to >> additive (+, -), multiplicative (*, mod, div) or unary expressions >> (sign) and does not include relational or equality expressions, so >> comparisons of int64 and uint64 data nodes do not seem to be discouraged >> by the current text. Was this intentional? Shouldn't all such numeric >> conversions be avoided? >> >> Ladislav once mentioned [5] that YANG XPath is able to "break out of >> module containment" with an expression like >> /*[local-name()='foo'] >> which is quite dangerous and IMO deserves mention in the guidelines. It >> should be clear that an expression is only able to reference names >> defined within the scope of a module, right? Or was "breaking out of >> module containment" intended as a feature of RFC6020 (seems more like a >> bug to me)? Completely unrelated modules should not cause unwanted side >> effects when implemented together. > +1 > > Lada > >> [1] >> http://tools.ietf.org/html/draft-bierman-netmod-rfc6087bis-00#section-4.5 >> [2] http://www.w3.org/TR/1999/REC-xpath-19991116/#section-Function-Calls >> [3] http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-15 >> [4] http://www.w3.org/TR/1999/REC-xpath-19991116/#numbers >> [5] http://www.ietf.org/mail-archive/web/netmod/current/msg09623.html >> >> Jernej >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Jul 7 04:46:00 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B491B282A for ; Mon, 7 Jul 2014 04:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_34=0.6, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ny8-TV2Wx3l for ; Mon, 7 Jul 2014 04:45:55 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93D11B2820 for ; Mon, 7 Jul 2014 04:45:54 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 2607413F9FA; Mon, 7 Jul 2014 13:45:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1404733552; bh=ahJs0m7z7eYw4tFxbA5AtFpQq4RrivW2BcFh+H+c7gQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=TOmWfwaHOyEKIifCa7USSbtylSUK5ZIyu0/bve+ROByA+/MkHkXoUV/m87BS6qOxJ hRh0y8srv6hA+G14DDoREM5H7EFfMMbMDMZcAJgwiemnV5ntCUoNHw4gKPbrxweJOr e9zwTqpcZCJDNDqAdp4wXpIJePPWj7/RlvBmGpKc= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ladislav Lhotka In-Reply-To: <53BA876C.6030908@mg-soft.com> Date: Mon, 7 Jul 2014 13:45:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53B53A2C.7010607@mg-soft.com> <53BA876C.6030908@mg-soft.com> To: Jernej Tuljak X-Mailer: Apple Mail (2.1878.2) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/PhA2Q9LjVDmybjTm0b-fPJrLxiw Cc: NETMOD Working Group Subject: Re: [netmod] YANG XPath usage guidelines (6087bis) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 11:45:57 -0000 On 07 Jul 2014, at 13:41, Jernej Tuljak = wrote: > Dne 7.7.2014 11:10, pi=9Ae Ladislav Lhotka: >> Jernej Tuljak writes: >>=20 >>> Hi, >>>=20 >>> some questions about YANG XPath expressions in general and as = observed >>> by 6087bis [1]. >>>=20 >>> Does it make sense to use the 'id(object)' and 'lang(string)' XPath >>> functions in YANG XPath expressions? They both imply existence of = XML >>> attributes, which cannot be modeled in pure YANG. Shouldn't = RFC6087bis >>> include a guideline for those in Section 4.5.? Is there a case where = the >>> mentioned XPath functions could be used? >> Now that there are several proposals for standardizing (global) >> attributes for use with YANG data, it might actually be useful to = refer >> to attributes in XPath expressions. One use case could be: "Nodes X = and >> Y can both be present only if at least one of them is tagged as >> inactive". >>=20 >> But in order to be able to do this, one needs to be able to include = an >> attribute's namespace in the context of the XPath expression - this = is >> another case where the "attribute" statement (issue Y33) would be = useful. >=20 > Perhaps, but the functions I mentioned are quite specific about what = attributes they require in order to be implemented. Do you see any use = cases that utilize 'id' and 'lang' in the context of NETCONF/YANG? The No, I was talking about attributes in general. Lada > first requires a DTD, if the XPath spec is to be strictly followed, = and the second requires 'xml:lang' attributes - note that YANG does not = support definition of identifiers that start with 'xml', so even if you = had an "attribute" statement in YANG this would still require an = extension, unless an attribute statement could specify it's own = namespace and prefix (:D). I realize that XPath is only used as a = notation in YANG, but the semantics of an arbitrary expression still = need to be well specified. >=20 > ------ > Function: boolean lang(string) >=20 > The lang function returns true or false depending on whether the = language of the context node as specified by xml:lang attributes is the = same as or is a sublanguage of the language specified by the argument = string. The language of the context node is determined by the value of = the xml:lang attribute on the context node, or, if the context node has = no xml:lang attribute, by the value of the xml:lang attribute on the = nearest ancestor of the context node that has an xml:lang attribute. If = there is no such attribute, then lang returns false. If there is such an = attribute, then lang returns true if the attribute value is equal to the = argument ignoring case, or if there is some suffix starting with - such = that the attribute value is equal to the argument ignoring that suffix = of the attribute value and ignoring case. For example, lang("en") would = return true if the context node is any of these five elements: >=20 > >
> > >=20 > Function: node-set id(object) >=20 > The id function selects elements by their unique ID (see [5.2.1 Unique = IDs]). When the argument to id is of type node-set, then the result is = the union of the result of applying id to the string-value of each of = the nodes in the argument node-set. When the argument to id is of any = other type, the argument is converted to a string as if by a call to the = string function; the string is split into a whitespace-separated list of = tokens (whitespace is any sequence of characters matching the production = S); the result is a node-set containing the elements in the same = document as the context node that have a unique ID equal to any of the = tokens in the list. >=20 > * id("foo") selects the element with unique ID foo >=20 > * id("foo")/child::para[position()=3D5] selects the fifth para child = of the element with unique ID foo >=20 > 5.2.1 Unique IDs >=20 > An element node may have a unique identifier (ID). This is the value = of the attribute that is declared in the DTD as type ID. No two elements = in a document may have the same unique ID. If an XML processor reports = two elements in a document as having the same unique ID (which is = possible only if the document is invalid) then the second element in = document order must be treated as not having a unique ID. >=20 > NOTE: If a document does not have a DTD, then no element in the = document will have a unique ID. > ------ >=20 >> =20 >>> 'local-name(node-set?)', 'namespace-uri(node-set?)', = 'name(node-set?)', >>> 'string(object?)' and 'number(object?)' are all directly reliant on >>> document order when the argument evaluates to a node-set with size > = 1 >>> and may therefore return different results for different >>> implementations, like the case with 'position' and 'last'. Other >>> functions may also be indirectly reliant on document order when they = are >>> supplied with a node-set argument which then needs to be converted = into >>> a string or a number as if by calling 'string(object?)' or >>> 'number(object?)' respectively [2]. Shouldn't this also be mentioned = in >>> the guidelines, since some other cases are? >>>=20 >>> Axes 'preceding-sibling' and 'following-sibling' should not be used >>> unless dealing with user ordered lists or leaf-lists and I agree = with >>> 6087bis, however document order may not be relevant when using those = two >>> axes (uniqueness checks). There's an example in ietf-routing module = [3]: >>> = not(/routing/ribs/rib[name=3Dcurrent()/preceding-sibling::connected-rib/ri= b-name >>> and >>> = address-family=3D/routing/ribs/rib[name=3Dcurrent()/rib-name]/address-fami= ly]) >>> where current() evaluates to a non-user ordered list instance. = Shouldn't >>> this also be mentioned in the guidelines as an acceptable corner = case, >>> like it is for 'preceding' and 'following'? >> I think the following text in 6087bis should be extended to cover >> "preceding-sibling" and "following-sibling" as well: >>=20 >> "The 'preceding' and 'following' axes MAY be used if document order = is >> not relevant to the outcome of the expression (e.g., check for global >> uniqueness of a parameter value)." >=20 > I agree. >=20 > Jernej >=20 >>> 6087bis specifies: >>>=20 >>> XPath expressions for 'when' statements MUST NOT reference the >>> context node or any descendant nodes of the context node. >>>=20 >>> yet ietf-ipv4-unicast-routing [3] clearly does so, with it's >>> conditional >> The example in sec. 3.3 of RFC 7223 does it, too. >> =20 >>> augments of rpc methods, where it references 'rt:address-family' = which >>> is a descendant of the initial context node (augmentation target or >>> nearest data node ancestor). Shouldn't conditional augmentation be = an >>> exception to this paragraph? >> Yes. In fact, many of the concerns regarding "when" (see e.g. issue = Y18) >> don't apply if it is used under "augment" because the result of = "when" >> evaluation doesn't affect the context node. >>=20 >>> 6087bis specifies: >>>=20 >>> Data nodes that use the 'int64' and 'uint64' built-in type = SHOULD NOT >>> be used within numeric expressions. There are boundary = conditions in >>> which the translation from the YANG 64-bit type to an XPath = number >>> can cause incorrect results. Specifically, an XPath 'double' >>> precision floating point number cannot represent very large = positive >>> or negative 64-bit numbers because it only provides a total = precision >>> of 53 bits. The 'int64' and 'uint64' data types MAY be used in >>> numeric expressions if the value can be represented with no more = than >>> 53 bits of precision. >>>=20 >>> In XPath specification [4], term "numeric expressions" refers to >>> additive (+, -), multiplicative (*, mod, div) or unary expressions >>> (sign) and does not include relational or equality expressions, so >>> comparisons of int64 and uint64 data nodes do not seem to be = discouraged >>> by the current text. Was this intentional? Shouldn't all such = numeric >>> conversions be avoided? >>>=20 >>> Ladislav once mentioned [5] that YANG XPath is able to "break out of >>> module containment" with an expression like >>> /*[local-name()=3D'foo'] >>> which is quite dangerous and IMO deserves mention in the guidelines. = It >>> should be clear that an expression is only able to reference names >>> defined within the scope of a module, right? Or was "breaking out of >>> module containment" intended as a feature of RFC6020 (seems more = like a >>> bug to me)? Completely unrelated modules should not cause unwanted = side >>> effects when implemented together. >> +1 >>=20 >> Lada >>=20 >>> [1] >>> = http://tools.ietf.org/html/draft-bierman-netmod-rfc6087bis-00#section-4.5 >>> [2] = http://www.w3.org/TR/1999/REC-xpath-19991116/#section-Function-Calls >>> [3] http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-15 >>> [4] http://www.w3.org/TR/1999/REC-xpath-19991116/#numbers >>> [5] = http://www.ietf.org/mail-archive/web/netmod/current/msg09623.html >>>=20 >>> Jernej >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jul 7 08:16:25 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40991A0166 for ; Mon, 7 Jul 2014 08:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOwv3qHCK4GC for ; Mon, 7 Jul 2014 08:16:17 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECED01A02F8 for ; Mon, 7 Jul 2014 08:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3734; q=dns/txt; s=iport; t=1404746176; x=1405955776; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BOqj3gZA2W0d1wc2iyMXlN7aUZl+KnW/auPl1Znc6SU=; b=Aum9e+UC9bOYTNNhTF7n34blMcd9hgyp0ksGX2DQMnfjel8G8Ah/9vIB cvvJygVqTMx1xJP+ENtFL4W/QHFpuOPk+OAFKKmMtNX7/eU4ZdsaHnkpb dSR+ZfN3u3y1qCpI+5+PTue+llTL9aVw9BfEidnRs3/E0e5QAef5XR7Ec o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAFy4ulOtJV2Q/2dsb2JhbABQCoMOgR8NxjwBgRYWdYQDAQEBBDorFAwEAgEIEQQBAQsUEDIdCAEBBA4FCIg6yhQXiWWEYSsxBwaDJ4EWAQSvAoNDgjA X-IronPort-AV: E=Sophos;i="5.01,618,1400025600"; d="scan'208";a="58843053" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-7.cisco.com with ESMTP; 07 Jul 2014 15:16:16 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s67FGGni005421 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 7 Jul 2014 15:16:16 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.36]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 10:16:15 -0500 From: "Tissa Senevirathne (tsenevir)" To: "Nobo Akiya (nobo)" Thread-Topic: Comments on draft-tissa-netmod-oam-01 Thread-Index: Ac+XqFYxYsJYmgtCT72I7Nhf1mmspQCTJ3dQ Date: Mon, 7 Jul 2014 15:16:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.119.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/B5YHA8y6oKatLxBz6QvLh09ObjU Cc: "netmod@ietf.org" Subject: Re: [netmod] Comments on draft-tissa-netmod-oam-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 15:16:23 -0000 Hi Nobo Thanks for the comments, please see in-line -----Original Message----- From: Nobo Akiya (nobo)=20 Sent: Friday, July 04, 2014 10:09 AM To: Tissa Senevirathne (tsenevir) Cc: netmod@ietf.org Subject: Comments on draft-tissa-netmod-oam-01 Hi Tissa, authors, First of all, intent of this document seems widely beneficial. I am interes= ted to see how and In what form this document will progress. Please find below few comments I have on the draft-tissa-netmod-oam-01, fro= m a quick look at the document. Comment #1: Section 6 [snip] typedef CCM-Interval { default "interval-1min"; type enumeration { enum "interval-invalid" { value 0; } ... enum "interval-10min" { value 7; } } ... } [snip] When considering all OAM tools out there, defining a hard coded set of inte= rvals (via enum) may not be a good idea. BFD implementations (SW/HW) spring= s to my mind immediately. For HW based BFD, BFD WG is working on an informa= tional document for recommended set of intervals: draft-ietf-bfd-intervals.= However, intervals outside of that set can still be implemented by vendors= for HW based BFD. SW based BFD, obviously, has much more flexibility in th= e range of intervals to use. A better approach may be to change above from = enum to identify ref (or something else) which can be augmented. [Answer] good point shall update in the next revision Comment #2: Section 6 [snip] typedef ecmp-choices { type enumeration { enum "ecmp-use-platform-hash" { value 0; } enum "ecmp-use-round-robin" { value 1; } } } [snip] leaf ecmp-choice { config true; type ecmp-choices; description "0 means use the specified interface 1 means use round robin"; } [snip] Above two seems a bit conflicting for the value of zero(0). Former states t= hat zero(0) indicates usage of platform hash but the latter indicates that = specific interface is used (i.e. not hashed?). Thinking about this, I belie= ve "ecmp-choices" is overloaded. You actually want to be able to describe 3= different things here. 1. Configuring a specific load balancing technique on a system (ex: EL, rou= nd-robin or something else). 2. Describing the output behavior on the OAM instance (ex: out to specific = interface vs. load balanced). 3. Describe the setting on the path discovery OAM instance (ex: LSP tree tr= ace using multipath 2, 4, 8, 9, 10). Perhaps a different object for each may be a good idea. (2) can be an enum = but it'll be beneficial to be able for various OAM tools to augment (1) and= (3). [Answer] agree on #1 and #2, let me think how to best bring that in into t= he next revisions. #3 is part of flow-entropy discovery, which is independe= nt of how it is treated. Way it is done is to have each of the technology t= o have its specific way of ECMP discovery, which is more like an RPC comman= d. In the base YANG model, use can populate the flow entropy why XML imterf= ace and #1 and #2 will dictates the behavior. Comment #3: Section 6 [snip] typedef oam-counter32 { type yang:zero-based-counter32; description "defines 32 bit counter for OAM"; } [snip] No 64 bit counter? [Answer] most counters in CFM are 32 bit hence taken this. But we can exten= d to 64 bit very easily. We can consider for next revision making the count= ers 64 bit. Thanks! -Nobo From nobody Mon Jul 7 08:28:55 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3726C1A0166 for ; Mon, 7 Jul 2014 08:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_PK3oWslD7q for ; Mon, 7 Jul 2014 08:28:53 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 077421A0104 for ; Mon, 7 Jul 2014 08:28:53 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 788F210E0; Mon, 7 Jul 2014 17:28:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Nxmj6ut7SMIA; Mon, 7 Jul 2014 17:28:47 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 7 Jul 2014 17:28:50 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D747C2002F; Mon, 7 Jul 2014 17:28:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id op55_138Flh7; Mon, 7 Jul 2014 17:28: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 2828D2002C; Mon, 7 Jul 2014 17:28:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 75C132DD1CB2; Mon, 7 Jul 2014 17:28:49 +0200 (CEST) Date: Mon, 7 Jul 2014 17:28:49 +0200 From: Juergen Schoenwaelder To: "Tissa Senevirathne (tsenevir)" Message-ID: <20140707152849.GA81954@elstar.local> Mail-Followup-To: "Tissa Senevirathne (tsenevir)" , "Nobo Akiya (nobo)" , "netmod@ietf.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ZdCZ_CcUCAns2_0TKDSBCkF_drQ Cc: "netmod@ietf.org" Subject: Re: [netmod] Comments on draft-tissa-netmod-oam-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jul 2014 15:28:54 -0000 On Mon, Jul 07, 2014 at 03:16:15PM +0000, Tissa Senevirathne (tsenevir) wrote: > Comment #3: Section 6 > > [snip] > typedef oam-counter32 { > type yang:zero-based-counter32; > description > "defines 32 bit counter for OAM"; > } > [snip] > > No 64 bit counter? > > [Answer] most counters in CFM are 32 bit hence taken this. But we can extend to 64 bit very easily. We can consider for next revision making the counters 64 bit. > But what is the value of this typedef? Why introduce oam-counter32 if it is exactly yang:zero-based-counter32? /js PS: It has been good practice to consider roll-over time while deciding whether between 32-bit and 64-bit counters. Making all counter 64-bit may be as wrong as making all counters 32-bit. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jul 7 08:32:52 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C97801A0416 for ; Mon, 7 Jul 2014 08:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAfK3EqT7mWf for ; Mon, 7 Jul 2014 08:32:48 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 630CD1A0415 for ; Mon, 7 Jul 2014 08:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1544; q=dns/txt; s=iport; t=1404747166; x=1405956766; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GarmCLPt10U2M88pdTIFosaCm1tat1MUL5XAX3saVp4=; b=mcma9Xd4hgicEI5Wi8ADuU6ZTN4RChISGwbWh3uEy5qrytH0FEefA5hm BLQzEx9Be+tWrw2D4j2ZLhfhhTVZCL67JTdpu3tJf/vUVNwuRHRpSGQpE dDpa6Zsw7hlhyCm4JPpSKL1205BVXpgqo4yfJB1dM5sraHmc7SepSV5fX Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAAW9ulOtJA2J/2dsb2JhbABXA4MOUlrGPAGBFxZ1hAMBAQEEOj8MAgICAQgOAgEEAQEBChQJBxsXFAkIAQEEDgUIiDrKFxcEjm0hEAcGC4McgRYFrwKDQ4Iw X-IronPort-AV: E=Sophos;i="5.01,618,1400025600"; d="scan'208";a="58838091" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP; 07 Jul 2014 15:32:46 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s67FWjUx002376 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jul 2014 15:32:45 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.36]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 10:32:45 -0500 From: "Tissa Senevirathne (tsenevir)" To: Juergen Schoenwaelder Thread-Topic: [netmod] Comments on draft-tissa-netmod-oam-01 Thread-Index: Ac+XqFYxYsJYmgtCT72I7Nhf1mmspQCTJ3dQAAtGw4AACnIhoA== Date: Mon, 7 Jul 2014 15:32:44 +0000 Message-ID: References: <20140707152849.GA81954@elstar.local> In-Reply-To: <20140707152849.GA81954@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.119.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kge5_jVQk1fAmn0YQxum6VlciAA Cc: "netmod@ietf.org" Subject: Re: [netmod] Comments on draft-tissa-netmod-oam-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 15:32:50 -0000 See in line -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, July 07, 2014 8:29 AM To: Tissa Senevirathne (tsenevir) Cc: Nobo Akiya (nobo); netmod@ietf.org Subject: Re: [netmod] Comments on draft-tissa-netmod-oam-01 On Mon, Jul 07, 2014 at 03:16:15PM +0000, Tissa Senevirathne (tsenevir) wro= te: > Comment #3: Section 6 >=20 > [snip] > typedef oam-counter32 { > type yang:zero-based-counter32; > description > "defines 32 bit counter for OAM"; > } > [snip] >=20 > No 64 bit counter? >=20 > [Answer] most counters in CFM are 32 bit hence taken this. But we can ext= end to 64 bit very easily. We can consider for next revision making the cou= nters 64 bit. >=20 But what is the value of this typedef? Why introduce oam-counter32 if it is= exactly yang:zero-based-counter32? [answer] this is was done for pragmatic reasons, that is in future if we h= ave to change the counter definition then no need to change many places, ju= st the generic typedef. Just like it is happening now. /js PS: It has been good practice to consider roll-over time while deciding whether between 32-bit and 64-bit counters. Making all counter 64-bit may be as wrong as making all counters 32-bit. --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jul 7 12:57:55 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F171B28AB for ; Mon, 7 Jul 2014 12:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOoaVPX7ZOO8 for ; Mon, 7 Jul 2014 12:56:51 -0700 (PDT) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.228]) by ietfa.amsl.com (Postfix) with ESMTP id BDA2A1B289C for ; Mon, 7 Jul 2014 12:56:51 -0700 (PDT) Received: from [65.190.6.125] ([65.190.6.125:49128] helo=[10.0.1.6]) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 79/B8-20336-28BFAB35; Mon, 07 Jul 2014 19:56:51 +0000 From: Acee Lindem Content-Type: multipart/alternative; boundary="Apple-Mail=_42A09A2B-0BAB-4F4C-8CE1-98D07A0D4D70" Date: Mon, 7 Jul 2014 15:56:49 -0400 Message-Id: <1C413D11-4390-4027-8635-A88D215689C5@lindem.com> To: Ladislav Lhotka , netmod@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Kkfi9fuy8GGKaPaogqUQynGYhTo X-Mailman-Approved-At: Mon, 07 Jul 2014 12:57:54 -0700 Cc: rtg-dir@ietf.org Subject: [netmod] Routing Directorate Comments on draft-ietf-netmod-routing-cfg-15 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 19:56:53 -0000 --Apple-Mail=_42A09A2B-0BAB-4F4C-8CE1-98D07A0D4D70 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello, =20 I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing = Directorate, please see = http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir =20 Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. =20 Document: draft-ietf-netmod-routing-cfg-15 Reviewer: Acee Lindem Review Date: July 8th, 2014 IETF LC End Date: TBD=20 Intended Status: Proposed Standard=20 Summary: There some issues with the model in the document that need to = be addressed prior to publication of this draft.=20 Fundamental Question: Going forward, how will this YANG data model = relate to the I2RS RIB information model proposed in = draft-ietf-i2rs-rib-info-model-03.txt?=20 Major Issues: =20 Section 4 & 5.4: These sections appear to restrict a routing = protocol instance to exactly one RIB for each address family that the = routing protocol instance supports. RFC 4915, et al, support a single = routing protocol instance which may populate multiple RIBs per address = family.=20 Section 7: What are the backup next-hops? I guess these are = IP-FRR next-hops that are installed by the same source protocol as the = primaries? If so, do you have to restrict the forwarding paradigm to not = use any backup next-hops as long as primary next-hops are accessible? = This would imply that forwarding plane would need to do a fast rehash of = the primaries and only use after all primaries are expired. There are = other lower overhead forwarding paradigms in use.=20 Missing: There is no concept of administrative distance (Cisco, et = al) or route preference (gated and Juniper). In my opinion, this is very = important since it determine which route is active when the same route = is available from multiple protocols.=20 =20 Missing: How does one get the best route for a given protocol = (which is not necessarily the active route)? Should each protocol have a = local RIB as part of its model? I notice that this is not included in = the RIP example in Appendix C. Would that need to be part of the run = state for the protocol?=20 Minor issues:=20 Section 9: Should there be checking to assure the router = advertisement mtu does not exceed the ipv6 MTU from RFC 7277?=20 Questions: I guess the list routing protocol instances is independent in = routing-protocols is independent of definition of the routing protocol = itself? Or, would it be expected that the YANG model for the routing = protocol itself would be here? If the former, wouldn=92t this = configuration be better grouped with the routing protocol themselves?=20 In section 9, the placement of the router advertisement = configuration seems rather arbitrary and I would have expected it to be = grouped with the other interface configuration in RFC 7277. I guess = placement here is the consensus of the netmod WG.=20 Thanks, Acee=20 =20= --Apple-Mail=_42A09A2B-0BAB-4F4C-8CE1-98D07A0D4D70 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hello,
 
I have been selected as = the Routing Directorate reviewer for this draft. The Routing Directorate = seeks to review all routing or routing-related drafts as they pass = through IETF last call and IESG review, and sometimes on special = request. The purpose of the review is to provide assistance to the = Routing ADs. For more information about the Routing Directorate, please = see http://trac.= tools.ietf.org/area/rtg/trac/wiki/RtgDir
 
Although these comments = are primarily for the use of the Routing ADs, it would be helpful if you = could consider them along with any other IETF Last Call comments that = you receive, and strive to resolve them through discussion or by = updating the draft.
 
Document: draft-ietf-netmod-routing-cfg-15
Reviewer: Acee = Lindem
Review = Date: July 8th, 2014
IETF LC End Date: TBD 
Intended Status: Proposed = Standard 

Summary: There some issues with the model in the document that = need to be addressed prior to publication of this draft. 

Fundamental Question: = Going forward, how will this YANG data model relate to the I2RS RIB = information model proposed in = draft-ietf-i2rs-rib-info-model-03.txt? 

Major Issues: =  

       Section 4 & 5.4:  These = sections appear to restrict a routing protocol instance to exactly one = RIB for each address family that the routing protocol instance supports. = RFC 4915, et al, support a single routing protocol instance which may = populate multiple RIBs per address family. 

      =  Section 7: What are the backup next-hops? I guess these are IP-FRR = next-hops that are installed by the same source protocol as the = primaries? If so, do you have to restrict the forwarding paradigm to not = use any backup next-hops as long as primary next-hops are accessible? = This would imply that forwarding plane would need to do a fast rehash of = the primaries and only use after all primaries are expired. There are = other lower overhead forwarding paradigms in use. 

      = Missing: There is no concept of administrative distance (Cisco, et al) = or route preference (gated and Juniper). In my opinion, this is very = important since it determine which route is active when the same route = is available from multiple protocols. 
      =                
      = Missing: How does one get the best route for a given protocol (which is = not necessarily the active route)? Should each protocol have a local RIB = as part of its model? I notice that this is not included in the RIP = example in Appendix C. Would that need to be part of the run state for = the protocol? 

Minor issues: 

     Section 9: Should there be = checking to assure the router advertisement mtu does not exceed the ipv6 = MTU from RFC 7277? 


Questions:
        I guess the list routing = protocol instances is independent in routing-protocols is independent of = definition of the routing protocol itself? Or, would it be expected that = the YANG model for the routing protocol itself would be here? If the = former, wouldn=92t this configuration be better grouped with the routing = protocol themselves? 

       In section 9, the placement = of the router advertisement configuration seems rather arbitrary and I = would have expected it to be grouped with the other interface = configuration in RFC 7277. I guess placement here is the consensus of = the netmod WG. 


Thanks,
Acee 

                 =   
= --Apple-Mail=_42A09A2B-0BAB-4F4C-8CE1-98D07A0D4D70-- From nobody Mon Jul 7 16:26:23 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC801B2988 for ; Mon, 7 Jul 2014 16:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NeqU9dKq2m_F for ; Mon, 7 Jul 2014 16:26:20 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A4911B2983 for ; Mon, 7 Jul 2014 16:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3362; q=dns/txt; s=iport; t=1404775580; x=1405985180; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QyM5RxZvTQv4x/rdxGXTMfXZXZcCpsfM+aZaClSqrmw=; b=CjH2zjkh1Lb2il/bSdP9pC8SlbU+iat6K6xykcsk7cMKEQvFlAWXjX3b s8JIIsGcm3zRVmVOW06UmwdL2cGl21PTbjfsUMQ1x7XUYYl9VxSLUSxc2 x0zBL0m4bVuwA3ADhvCVIpeCQvECWOLvbwN5LEeEe293Wq6Xjd5ElOcSu M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAK0ru1OtJA2I/2dsb2JhbABZgmokgR8NxkEBgRcWdYQDAQEBAwE6KxQFCwIBCCIUEDIlAQEEDg2IMggByVcXjnExB4MtgRYFrwKDQ4Iw X-IronPort-AV: E=Sophos;i="5.01,621,1400025600"; d="scan'208";a="338332771" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-5.cisco.com with ESMTP; 07 Jul 2014 23:26:19 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s67NQJne008260 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 7 Jul 2014 23:26:19 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 18:26:19 -0500 From: "Nobo Akiya (nobo)" To: "Tissa Senevirathne (tsenevir)" Thread-Topic: Comments on draft-tissa-netmod-oam-01 Thread-Index: Ac+XqFYxYsJYmgtCT72I7Nhf1mmspQCTJ3dQABCzHIA= Date: Mon, 7 Jul 2014 23:26:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ezfSVb6Hp1OX5tGucLpGdIku38g Cc: "netmod@ietf.org" Subject: Re: [netmod] Comments on draft-tissa-netmod-oam-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 23:26:21 -0000 Hi Tissa, Juergen, > Comment #2: Section 6 >=20 > [snip] > typedef ecmp-choices { > type enumeration { > enum "ecmp-use-platform-hash" { > value 0; > } > enum "ecmp-use-round-robin" { > value 1; > } > } > } > [snip] > leaf ecmp-choice { > config true; > type ecmp-choices; > description > "0 means use the specified interface > 1 means use round robin"; > } > [snip] >=20 > Above two seems a bit conflicting for the value of zero(0). Former states > that zero(0) indicates usage of platform hash but the latter indicates th= at > specific interface is used (i.e. not hashed?). Thinking about this, I bel= ieve > "ecmp-choices" is overloaded. You actually want to be able to describe 3 > different things here. >=20 > 1. Configuring a specific load balancing technique on a system (ex: EL, > round-robin or something else). > 2. Describing the output behavior on the OAM instance (ex: out to specifi= c > interface vs. load balanced). > 3. Describe the setting on the path discovery OAM instance (ex: LSP tree > trace using multipath 2, 4, 8, 9, 10). >=20 > Perhaps a different object for each may be a good idea. (2) can be an enu= m > but it'll be beneficial to be able for various OAM tools to augment (1) a= nd (3). > [Answer] agree on #1 and #2, let me think how to best bring that in into= the > next revisions. As for #2, the two choices, specific interface (pre-routed/pre-switched) an= d load balanced (switched/routed), should suffice. As for #1, this is a tricky one as we lack standards on the most of the loa= d balancing techniques that employed on various products. There are some co= mmon load balancing techniques that can be listed (ex: n-tuple, round-robin= , Entropy Label, etc), but would that suffice for this need? Exactly, what = do we want to be able to do this #1? > #3 is part of flow-entropy discovery, which is independent of > how it is treated. Way it is done is to have each of the technology to ha= ve its > specific way of ECMP discovery, which is more like an RPC command. In the > base YANG model, use can populate the flow entropy why XML imterface > and #1 and #2 will dictates the behavior. Agree, each technology being able to describe this separately will be good. > Comment #3: Section 6 >=20 > [snip] > typedef oam-counter32 { > type yang:zero-based-counter32; > description > "defines 32 bit counter for OAM"; > } > [snip] >=20 > No 64 bit counter? >=20 > [Answer] most counters in CFM are 32 bit hence taken this. But we can > extend to 64 bit very easily. We can consider for next revision making th= e > counters 64 bit. >=20 [from Juergen] > PS: It has been good practice to consider roll-over time while > deciding whether between 32-bit and 64-bit counters. Making all > counter 64-bit may be as wrong as making all counters 32-bit. Good point. Sending or receiving an OAM packet every 3.3 millisecond will c= ause 32 bit counter to wrap in 164 days (23 weeks and few days), we will de= finitely need a bigger counter for some OAM. Thanks! -Nobo From nobody Tue Jul 8 03:35:09 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908DD1B27F6; Tue, 8 Jul 2014 03:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4e4Zh7yCDdb; Tue, 8 Jul 2014 03:35:01 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B02C1B2A65; Tue, 8 Jul 2014 03:35:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id E0BF75407DB; Tue, 8 Jul 2014 12:34:58 +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 yXTxkEk-bV1B; Tue, 8 Jul 2014 12:34:54 +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 9DE5F540138; Tue, 8 Jul 2014 12:34:53 +0200 (CEST) From: Ladislav Lhotka To: Acee Lindem , netmod@ietf.org In-Reply-To: <1C413D11-4390-4027-8635-A88D215689C5@lindem.com> References: <1C413D11-4390-4027-8635-A88D215689C5@lindem.com> User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 08 Jul 2014 12:34:53 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5hX3IL7bUYkjkTyyHOXdQFw1yhQ Cc: rtg-dir@ietf.org Subject: Re: [netmod] Routing Directorate Comments on draft-ietf-netmod-routing-cfg-15 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 10:35:04 -0000 Hi Acee, thank you for the review, my comments are inline. Acee Lindem writes: > Hello, >=20=20 > I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related draf= ts as they pass through IETF last call and IESG review, and sometimes on sp= ecial request. The purpose of the review is to provide assistance to the Ro= uting ADs. For more information about the Routing Directorate, please see h= ttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >=20=20 > Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF Last = Call comments that you receive, and strive to resolve them through discussi= on or by updating the draft. >=20=20 > Document: draft-ietf-netmod-routing-cfg-15 > Reviewer: Acee Lindem > Review Date: July 8th, 2014 > IETF LC End Date: TBD=20 > Intended Status: Proposed Standard=20 > > Summary: There some issues with the model in the document that need to be= addressed prior to publication of this draft.=20 > > Fundamental Question: Going forward, how will this YANG data model > relate to the I2RS RIB information model proposed in > draft-ietf-i2rs-rib-info-model-03.txt? After IETF 87, the relevant parts of two models were compared, and this resulted in several changes and additions in the NETMOD model. Since then, the I2RS model underwent some changes but the only parameter that needs to be included in the NETMOD model is route-preference. Other parameters such as ENABLE_IP_RPF_CHECK or nexthop chains can be added later via augmentation. On the other hand, one of the results of the alignment with I2RS RIB info model, was the addition of the "id" key to every single route. In the discussion with I2RS folks, I raised objections against this unique "id" because it could mean considerable bookkeeping for a RIB containing ~200K routes, but we eventually agreed to add it to the NETMOD model. Later, several people repeated my concerns, and I think this "id" should be removed from the NETMOD model.=20=20=20 =20 > > Major Issues:=20=20 > > Section 4 & 5.4: These sections appear to restrict a routing > protocol instance to exactly one RIB for each address family > that the routing protocol instance supports. RFC 4915, et al, > support a single routing protocol instance which may populate > multiple RIBs per address family. This issue was brought up in a recent discussion with people working on data models for OSPF and ISIS, and the rough consensus is that this restriction should be lifted. By default, routes from a routing protocol instance will be installed in all connected RIBs of the corresponding address family (subject to operator-defined route filters), but data models for particular protocols can state other rules how connected RIBs are populated, e.g. using MT-ID.=20=20=20=20 =20 > > Section 7: What are the backup next-hops? I guess these are > IP-FRR next-hops that are installed by the same source protocol > as the primaries? If so, do you have to restrict the forwarding > paradigm to not use any backup next-hops as long as primary > next-hops are accessible? This would imply that forwarding > plane would need to do a fast rehash of the primaries and only > use after all primaries are expired. There are other lower > overhead forwarding paradigms in use. In this case we only followed suit of the I2RS RIB info model, see sections 2.4.2 and 7.2.4 (protection lists) in draft-ietf-i2rs-rib-info-model-03. > > Missing: There is no concept of administrative distance (Cisco, > et al) or route preference (gated and Juniper). In my opinion, > this is very important since it determine which route is active > when the same route is available from multiple protocols. Yes, route-preference will be added, see above. =20 >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 > Missing: How does one get the best route for a given protocol > (which is not necessarily the active route)? Should each > protocol have a local RIB as part of its model? I notice that > this is not included in the RIP example in Appendix C. Would > that need to be part of the run state for the protocol? Yes, data models for each routing protocol should include necessary protocol-internal data structures as state data - for example BGP RIB or link-state database. =20 > > Minor issues:=20 > > Section 9: Should there be checking to assure the router > advertisement mtu does not exceed the ipv6 MTU from RFC 7277? Yes, the description of the "link-mtu" leaf should mention this constraint. It cannot be done using the "must" statement though because the "ip:mtu" leaf is optional and the ietf-ip module defines no default for it (the default depends on interface type). =20 > > > Questions: > I guess the list routing protocol instances is independent in > routing-protocols is independent of definition of the routing > protocol itself? Or, would it be expected that the YANG model > for the routing protocol itself would be here? If the former, > wouldn=E2=80=99t this configuration be better grouped with the ro= uting > protocol themselves? I am not sure I understand the question but data models for individual routing protocols will be defined in separate YANG modules and will augment the "routing-protocol" list, both in configuration and state data. So, configuration parameters for a routing protocol will eventually appear under "routing-protocol" but will be defined separately. =20 > > In section 9, the placement of the router advertisement > configuration seems rather arbitrary and I would have expected > it to be grouped with the other interface configuration in RFC > 7277. I guess placement here is the consensus of the netmod WG. The advertisements should be sent only by routers, so I think it is appropriate to have it as a part of router interfaces' config and state data. Quite often (even at IETF meetings) we can see misconfigured hosts sending these advertisements. Thanks, Lada > > > Thanks, > Acee=20 > >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jul 8 05:07:38 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5D21B2A74; Tue, 8 Jul 2014 05:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvoSnrG_vdKh; Tue, 8 Jul 2014 05:07:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68741B280E; Tue, 8 Jul 2014 05:07:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJT19379; Tue, 08 Jul 2014 12:07:08 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 8 Jul 2014 13:07:06 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Tue, 8 Jul 2014 20:07:03 +0800 From: Qin Wu To: "Tissa Senevirathne (tsenevir)" , "time@ietf.org" Thread-Topic: YANG models for OAM Thread-Index: Ac+E3qlMyPi638vnRGmjYh75Wx+edAATLCxAA6JRP1ABuzlT8A== Date: Tue, 8 Jul 2014 12:07:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA84580501nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/EUiAx8eNf_zQpPOdXbxj6X-JVb0 Cc: "l2vpn@ietf.org" , "opsawg@ietf.org" , "nvo3@ietf.org" , "netmod@ietf.org" , "trill@ietf.org" Subject: Re: [netmod] YANG models for OAM X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 12:07:13 -0000 --_000_B8F9A780D330094D99AF023C5877DABA84580501nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIFRpc3NhOg0KVGhlcmUgYXJlIG1hbnkgb3B0aW9ucyBmb3IgU0ZDIE9BTSwgQkZEIGV4dGVu c2lvbiwgR2VuZXJpYyBIZWFkZXIgZXh0ZW5zaW9uLCBHZW5lcmljIFRMViBleHRlbnNpb24uDQpV bmxpa2Ugb3RoZXIgZXhpc3RpbmcgT0FNIHByb3RvY29scywgbWVjaGFuaXNtcyBhbmQgdG9vbHMs IFNGQyBuZWVkIHRvIGFkZHJlc3MgT0FNIGZvciB0aGUgdGVjaG5vbG9neSB0aGF0IGlzIGFib3Zl IGxheWVyIDMuDQpTRkMgaGF2ZW6hr3QgZGV2ZWxvcGVkIE9BTSBwcm90b2NvbCB5ZXQgYXQgdGhl IHRvcCBvZiBsYXllciAzLg0KDQpCZWZvcmUgdGhleSBkZXZlbG9waW5nIE9BTSBwcm90b2NvbCwg dGhleSBuZWVkIHRvIGZpZ3VyZSBvdXQgd2hldGhlciB0aGV5IG5lZWQgdG8gZGV2ZWxvcCB0ZWNo bm9sb2d5IGRlcGVuZGVudCBPQU0gcHJvdG9jb2wsDQpPciB0ZWNobm9sb2d5IGluZGVwZW5kZW50 IE9BTSBwcm90b2NvbCBzaW5jZSBTRkMgT0FNIGFuZCBPdmVybGF5IE9BTSBzaGFyZSBhIGxvdCBv ZiBzaW1pbGFyaXRpZXMoZS5nLiwgYm90aCBjYW4gdXNlIG92ZXJsYXkgdGVjaG5vbG9neSB0byBz dGl0Y2ggYSBzZXQgb2Ygb3ZlcmxheSBub2RlIG9yIHNlcnZpY2Ugbm9kZSB0byBmb3JtIHRoZSBl bmQgdG8gZW5kIHBhdGgpLiBXaHkgbm90IGJ1aWxkIG9uZSBwcm90b2NvbCB0byBzdXBwb3J0IGJv dGg/DQoNClRoYXShr3Mgd2h5IHdlIGJyaW5nIHVwIHRyYW5zcG9ydCBpbmRlcGVuZGVudCBPQU0g Y292ZXJpbmcgdmFyaW91cyBoZXRlcm9nZW5lb3VzIG5ldHdvcmsgdGVjaG5vbG9naWVzIGFuZCBw cm9wb3NlIHRvIGNvbnNvbGlkYXRlIE9BTSBpbiBib3RoDQpNYW5hZ2VtZW50IHBsYW5lIGFuZCBk YXRhIHBsYW5lLg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd3ctb3BzYXdnLW11 bHRpLWxheWVyLW9hbS0wMg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQta2luZy1v cHNhd2ctdGltZS1tdWx0aS1sYXllci1vYW0tdXNlLWNhc2UtMDEudHh0DQoNClJlZ2FyZGluZyBm bG93LWVudHJvcHksIHdoeSBub3QgcmV1c2UgZW50cm9weSBtZWNoYW5pc21zIGluIHRoZSBleGlz dGluZyB1bmRlcmx5aW5nIHRyYW5zcG9ydC4gSG93IGlzIGZsb3cgZW50cm9weSBkaWZmZXJlbnQg ZnJvbSBFQ01QIGNob2ljZSB5b3UgcHJvcG9zZWQgaW4gdGhlIGRyYWZ0Lg0KSWYgbXkgdW5kZXJz dGFuZGluZyBpcyBjb3JyZWN0LCBJRUVFIDgwMi4xYWcgb25seSBzdXBwb3J0IEVxdWFsIENvc3Qg VHJlZSAoRUNUKSBtZWNoYW5pc20gaW5zdGVhZCBvZiBFQ01QLCBJRUVFODAyLjFRYnAgc3VwcG9y dCBFQ01QLA0KQXJlIHlvdSBwcm9wb3NpbmcgdG8gY29tYmluZSBFQ1Qgc3VwcG9ydGVkIGJ5IElF RUUgODAyLjFhZyB3aXRoIEVDTVAgc3VwcG9ydGVkIGJ5IElFRUUgODAyLjFRYnAgYW5kIHVzZSB0 aGVtIHRvZ2V0aGVyIGF0IHRoZSBzYW1lIHRpbWUgaW4gdGhlIHNhbWUgbmV0d29yaz8NCg0KQWxz byBCRkQgYW5kIElFRUUgODAyLjFhZyBDRk0gc2hhcmUgYSBsb3Qgb2YgY29tbW9uYWxpdHksIGUu Zy4sIENDTS1pbnRlcnZhbCwgQkZEIGludGVydmFsLiBJZiB3ZSBpbnRlZ3JhdGUgdGhlbSB0b2dl dGhlciwgd2UgcmVhbGx5IG5lZWQgdG8gdGhpbmsgYWJvdXQgaG93IHRvIGludGVncmF0ZSB0aGVt IHRvZ2V0aGVyIGluIHRoZSBtYW5hZ2VtZW50IHBsYW5lLiBJcyB0aGVyZSBhbnkgY29tbW9uIGNv bXBvbmVudCB3ZSBjYW4gZGVmaW5lIGZvciBib3RoPyBIb3cgd2UgZGVmaW5lIHRoZXNlIGNvbXBv bmVudCBhbmQgbWFrZSB0aGVtIG1vcmUgZXh0ZW5zaWJsZS4NCg0KUmVnYXJkcyENCi1RaW4NCrei vP7IyzogVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikgW21haWx0bzp0c2VuZXZpckBjaXNj by5jb21dDQq3osvNyrG85DogMjAxNMTqNtTCMzDI1SAwOjIwDQrK1bz+yMs6IFFpbiBXdTsgdGlt ZUBpZXRmLm9yZw0Ks63LzTogbmV0bW9kQGlldGYub3JnOyBudm8zQGlldGYub3JnOyB0cmlsbEBp ZXRmLm9yZzsgbDJ2cG5AaWV0Zi5vcmc7IG9wc2F3Z0BpZXRmLm9yZw0K1vfM4jogUkU6IFlBTkcg bW9kZWxzIGZvciBPQU0NCg0KSGkgUWluDQoNClRoZXJlIGFyZSBzZXZlcmFsIHdheSB0aGlzIGlz IGFwcGxpY2FibGUgdG8gU0ZDDQoNCg0KMS4gICAgICAgU0ZDIGlzIHVuZGVybGF5ZXIgaW5kZXBl bmRlbnQgLCB3aGljaCBtZWFucyBpdCBjYW4gaGF2ZSBhbGwgc29ydHMgb2YgZW5jYXAgdHlwZXMg dW5kZXJuZWF0aCwgdGhlIG1vZGVsIHByZXNlbnRlZCBpbiB0aXNzYS1uZXRtb2Qtb2FtLCBhZGRy ZXNzIGV4YWN0bHkgdGhhdCBpc3N1ZS4gSW5zdGVhZCBvZiByZS1pbnZlbnRpbmcgYW5kIHJlLWlt cGxlbWVudGluZyB2YXJpb3VzIGRpZmZlcmVudCBPQU0gdGhlIGRyYWZ0IHByb3Bvc2UgdG8gaW50 ZWdyYXRlIHRoZW0gYXQgdGhlIG1hbmFnZW1lbnQgbGF5ZXIuDQoNCjIuICAgICAgIEluIHRoaXMg ZHJhZnQgd2UgZGVmaW5lIGEgZmxvdy1lbnRyb3B5IGFzIGFuIG9wYXF1ZSBlbGVtZW50IHRoYXQg ZWFjaCBvZiB0aGUgdGVjaG5vbG9neSB0eXBlIGNhbiBzcGVjaWZ5IGFuZCBpbmNsdWRlLiBJZiB3 ZSBsb29rIGF0IGRyYWZ0LXF1aW5uLXNmYy1uc2gtMDIudHh0LCBpdCBkZWZpbmUgYSBibG9jayB0 aGF0IHNwZWNpZmllcyBTRkMuIFNGQyB2ZXJzaW9uIG9mIFlBTkcgIGNhbiBzcGVjaWZ5IHRoaXMg YXMgcGFydCBvZiBpdHMgZmxvdyBlbnRyb3B5LiBUaGUgYmVhdXR5IGlzIHRoYXQgaXQgaXMgYWxs IHVwIHRvIHRoZSB0ZWNobm9sb2d5IHRvIHNwZWNpZnkgdGhhdCAoc2l6ZSBhbmQgc2hhcGUgaXMg dGVjaG5vbG9neSBkZXBlbmRlbnQpIGFuZCBiYXNlIG1vZGVsIGlzIHN0aWxsIGludGFjdC4NCg0K V2l0aCB0aGUgYWJvdmUgaW4gbWluZCAsIGNhbiB5b3UgcGxlYXNlIHJldmlldyBkcmFmdC10aXNz YS1uZXRtb2Qtb2FtIGFuZCBzZWUgaXQgaXMgZmxleGlibGUgYW5kIGV4dGVuc2libGUgZW5vdWdo IHRvIGZvciB0aGUgcHVycG9zZS4gSWYgdGhpbmdzIGFyZSBtaXNzaW5nIHdlIGNhbiBhZGQgYW5k IGV4dGVuZC4NCg0KSSBoYXZlIHJlcXVlc3RlZCBuZXRtb2QgV0cgY2hhaXJzIGZvciBhIHByZXNl bnRhdGlvbiBzbG90IGZvciBmdXJ0aGVyIGRpc2N1c3Npb24gb2YgdGhlIGRyYWZ0Lg0KDQpGcm9t OiBRaW4gV3UgW21haWx0bzpiaWxsLnd1QGh1YXdlaS5jb21dDQpTZW50OiBUdWVzZGF5LCBKdW5l IDEwLCAyMDE0IDk6MjIgUE0NClRvOiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKTsgdGlt ZUBpZXRmLm9yZzxtYWlsdG86dGltZUBpZXRmLm9yZz4NCkNjOiBuZXRtb2RAaWV0Zi5vcmc8bWFp bHRvOm5ldG1vZEBpZXRmLm9yZz47IG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+ OyB0cmlsbEBpZXRmLm9yZzxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+OyBsMnZwbkBpZXRmLm9yZzxt YWlsdG86bDJ2cG5AaWV0Zi5vcmc+OyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRm Lm9yZz4NClN1YmplY3Q6IFJFOiBZQU5HIG1vZGVscyBmb3IgT0FNDQoNCkhpLCBUaXNzYToNClRo YW5rcyBmb3IgaW5pdGlhdGluZyBkaXNjdXNzaW9uIG9uIHRoaXMgdG9waWMuDQpVbmlmaWVkIE9B TSBmb3IgbXVsdGktTGF5ZXIgbmV0d29yayBpcyBhIGdvb2QgaWRlYSB0byBtZS4NCmRyYWZ0LXd3 LW9wc2F3Zy1tdWx0aS1sYXllci1vYW0tMDAgd2UgcHJvcG9zZWQgaW4gb3BzYXdnIGxhaWQgb3V0 IHRoZSBhbiBpbml0aWFsIGRlc2NyaXB0aW9uIG9mIHRoZSBwcm9ibGVtLg0KVGhlIHF1ZXN0aW9u IHRvIGRyYWZ0LXRpc3NhLW5ldG1vZC1vYW0gaXMNCkkgYW0gd29uZGVyaW5nIGhvdyB0aGlzIGdl bmVyaWMgWWFuZyBNb2RlbCBjYW4gYmUgYXBwbGllZCB0byBTRkMgZW52aXJvbm1lbnQ/DQpIb3cg ZG8geW91IHN1cHBvcnQgdGhlIGNhc2Ugd2hlcmUgdHdvIGVuZHBvaW50cyBzdXBwb3J0IGRpZmZl cmVudCBsYXllciBPQU0gb3IgZG9lc26hr3Qgc3VwcG9ydCBhbnkgT0FNIGF0IHRoYXQgbGF5ZXIu DQoNCkJUVzogSSBoYXZlIGNjoa9lZCB0aW1lIG1haWxpbmcgbGlzdCBzaW5jZSBJIGJlbGlldmUg dGhpcyBtYWlsaW5nIGxpc3QgaXMgcHVycG9zZWQgdG8gbG9vayBmb3IgZ2VuZXJpYyBhbmQgaW50 ZWdyYXRlZCBPQU0gY292ZXJpbmcgdmFyaW91cyBoZXRlcm9nZW5lb3VzIG5ldHdvcmtpbmcgdGVj aG5vbG9naWVzLg0KUmVnYXJkcyENCi1RaW4NCreivP7IyzogbmV0bW9kIFttYWlsdG86bmV0bW9k LWJvdW5jZXNAaWV0Zi5vcmddILT6se0gVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikNCrei y83KsbzkOiAyMDE0xOo21MIxMcjVIDM6MDMNCsrVvP7IyzogbmV0bW9kQGlldGYub3JnPG1haWx0 bzpuZXRtb2RAaWV0Zi5vcmc+OyBudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPjsg dHJpbGxAaWV0Zi5vcmc8bWFpbHRvOnRyaWxsQGlldGYub3JnPjsgbDJ2cG5AaWV0Zi5vcmc8bWFp bHRvOmwydnBuQGlldGYub3JnPjsgb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5v cmc+DQrW98ziOiBbbmV0bW9kXSBZQU5HIG1vZGVscyBmb3IgT0FNDQoNCkFsbA0KDQpXZSBoYXZl IHB1Ymxpc2hlZCBZQU5HIG1vZGVsIGZvciBPQU0uICMxIGRyYWZ0IGJlbG93IHBsYWNlIHRoZSBn ZW5lcmljIGZyYW1ld29yayBmb3IgT0FNLCB0aGF0IGNhbiBiZSBhdWdtZW50ZWQgZm9yIGRpZmZl cmVudCB0ZWNobm9sb2dpZXMuICMyIGFuZCAjMyBhcmUgYXBwbGljYXRpb24gb2YgdGhlIGNvbmNl cHQgdG8gTlZPMyBhbmQgVFJJTEwsDQoNCg0KMS4gICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC10aXNzYS1uZXRtb2Qtb2FtLw0KDQoyLiAgICAgICBodHRwOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRpc3NhLW52bzMteWFuZy1vYW0vDQoNCjMuICAg ICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGlzc2EtdHJpbGwteWFu Zy1vYW0vDQoNClBsZWFzZSByZXZpZXcgYW5kIHNoYXJlIHlvdXIgY29tbWVudHMNCg0KVGhhbmtz DQpUaXNzYQ0KDQoNCg== --_000_B8F9A780D330094D99AF023C5877DABA84580501nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Tissa:

There are many options for SFC OAM, BFD extension, Generic Header= extension, Generic TLV extension.

Unlike other existing OAM protocols, mechanisms and tools, SFC ne= ed to address OAM for the technology that is above layer 3.

SFC haven=A1=AFt developed OAM protocol yet at the top of layer 3= .

 

Before they developing OAM protocol, they need to figure out whet= her they need to develop technology dependent OAM protocol,

Or technology independent OAM protocol since SFC OAM and Overlay = OAM share a lot of similarities(e.g., both can use overlay technology to st= itch a set of overlay node or service node to form the end to end path). Why not build one protocol to support b= oth?

 

That=A1=AFs why we bring up transport independent OAM covering va= rious heterogeneous network technologies and propose to consolidate OAM in = both

Management plane and data plane.

http://tools.ietf.org/html/draft= -ww-opsawg-multi-layer-oam-02

http://tools= .ietf.org/html/draft-king-opsawg-time-multi-layer-oam-use-case-01.txt

 

Regarding flow-entropy, why not reuse entropy mechanisms in the e= xisting underlying transport. How is flow entropy different from ECMP choic= e you proposed in the draft.

If my understanding is correct, IEEE 802.1ag only support Equal C= ost Tree (ECT) mechanism instead of ECMP, IEEE802.1Qbp support ECMP,

Are you proposing to combine ECT supported by IEEE 802.1ag with E= CMP supported by IEEE 802.1Qbp and use them together at the same time in th= e same network?

 

Also BFD and IEEE 802.1ag CFM share a lot of commonality, e.g., C= CM-interval, BFD interval. If we integrate them together, we really need to= think about how to integrate them together in the management plane. Is there any common component we can define for b= oth? How we define these component and make them more extensible.

 

Regards!

-Qin

=B7=A2=BC=FE=C8=CB: Tissa S= enevirathne (tsenevir) [mailto:tsenevir@cisco.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C230=C8=D5 0:20
=CA=D5=BC=FE=C8=CB: Qin Wu; time@ietf.org
=B3=AD=CB=CD: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; opsawg@ie= tf.org
=D6=F7=CC=E2: RE: YANG models for OAM

 

Hi Qin<= o:p>

&n= bsp;

There a= re several way this is applicable to SFC

&n= bsp;

= 1.       SFC is underlayer independent , which means it can have all sorts of encap= types underneath, the model presented in tissa-netmod-oam, address exactly= that issue. Instead of re-inventing and re-implementing various different OAM the draft propose to integrate t= hem at the management layer.

= 2.       In this draft we define a flow-entropy as an opaque element that each of t= he technology type can specify and include. If we look at draft-quinn-sfc-n= sh-02.txt, it define a block that specifies SFC. SFC version of YANG  can specify this as part of its flow entrop= y. The beauty is that it is all up to the technology to specify that (size = and shape is technology dependent) and base model is still intact.

&n= bsp;

With th= e above in mind , can you please review draft-tissa-netmod-oam and see it i= s flexible and extensible enough to for the purpose. If things are missing = we can add and extend.

&n= bsp;

I have = requested netmod WG chairs for a presentation slot for further discussion o= f the draft.  

&n= bsp;

From: Qin Wu [mailto:= bill.wu@huawei.com]
Sent: Tuesday, June 10, 2014 9:22 PM
To: Tissa Senevirathne (tsenevir); = time@ietf.org
Cc: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; opsawg@ietf.org<= br> Subject: RE: YANG models for OAM

 

Hi, Tissa:

Thanks for initiating discussion on this topic.=

Unified OAM for multi-Layer network is a good idea to me.

draft-ww-opsawg-multi-layer-oam-00 we proposed in opsawg laid out= the an initial description of the problem.

The question to draft-= tissa-netmod-oam is

I am wondering how this generic Yang Model can be applied to SFC = environment?

How do you support the case where two endpoints support different= layer OAM or doesn=A1=AFt support any OAM at that layer.=

 

BTW: I have cc=A1=AFed time mailing list since I believe this mai= ling list is purposed to look for generic and integrated OAM covering vario= us heterogeneous networking technologies.

Regards!

-Qin

=B7=A2=BC=FE=C8=CB: netmod = [mailto:netmod-bounces@ietf.org<= /a>] =B4=FA= =B1=ED Tissa Senevirathne (tsenevir)
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C211=C8=D5 3:03
=CA=D5=BC=FE=C8=CB: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; <= a href=3D"mailto:opsawg@ietf.org"> opsawg@ietf.org
=D6=F7=CC=E2: [netmod] YANG models for OAM

 

All

 

We have published YANG model fo= r OAM. #1 draft below place the generic framework for OAM, that can be augm= ented for different technologies. #2 and #3 are application of the concept = to NVO3 and TRILL,

 

1. &nbs= p;     http://datatracker.ietf.org/do= c/draft-tissa-netmod-oam/

2. &nbs= p;     http://datatracker.ietf.org= /doc/draft-tissa-nvo3-yang-oam/

3. &nbs= p;     http://datatracker.ietf.or= g/doc/draft-tissa-trill-yang-oam/

 

Please review and share your co= mments

 

Thanks

Tissa

 

 

--_000_B8F9A780D330094D99AF023C5877DABA84580501nkgeml501mbschi_-- From nobody Tue Jul 8 06:10:00 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAB91B283B; Tue, 8 Jul 2014 06:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2_igRDB-1F2; Tue, 8 Jul 2014 06:09:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09DEE1B2833; Tue, 8 Jul 2014 06:09:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGX42963; Tue, 08 Jul 2014 13:09:53 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 8 Jul 2014 14:09:52 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Tue, 8 Jul 2014 21:09:47 +0800 From: Qin Wu To: "Nobo Akiya (nobo)" , "Tissa Senevirathne (tsenevir)" Thread-Topic: Comments on draft-tissa-netmod-oam-01 Thread-Index: Ac+XqFYxYsJYmgtCT72I7Nhf1mmspQDA2Oqg Date: Tue, 8 Jul 2014 13:09:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/PGUi18Do7uhnD0AUenIb5BhkFJM Cc: "time@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Comments on draft-tissa-netmod-oam-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 13:09:57 -0000 U29ycnkgdG8gY2hpbWUgaW4uDQpTZWUgc29tZSBjb21tZW50cyBpbmxpbmUgYmVsb3cuDQotLS0t LdPKvP7Urbz+LS0tLS0NCj63orz+yMs6IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGll dGYub3JnXSC0+rHtIE5vYm8gQWtpeWEgKG5vYm8pDQo+t6LLzcqxvOQ6IDIwMTTE6jfUwjXI1SAx OjA5DQo+ytW8/sjLOiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKQ0KPrOty806IG5ldG1v ZEBpZXRmLm9yZw0KPtb3zOI6IFtuZXRtb2RdIENvbW1lbnRzIG9uIGRyYWZ0LXRpc3NhLW5ldG1v ZC1vYW0tMDENCg0KPkhpIFRpc3NhLCBhdXRob3JzLA0KDQo+Rmlyc3Qgb2YgYWxsLCBpbnRlbnQg b2YgdGhpcyBkb2N1bWVudCBzZWVtcyB3aWRlbHkgYmVuZWZpY2lhbC4gSSBhbSBpbnRlcmVzdGVk IHRvIHNlZSBob3cgYW5kIEluIHdoYXQgZm9ybSB0aGlzIGRvY3VtZW50IHdpbGwgcHJvZ3Jlc3Mu DQoNCj5QbGVhc2UgZmluZCBiZWxvdyBmZXcgY29tbWVudHMgSSBoYXZlIG9uIHRoZSBkcmFmdC10 aXNzYS1uZXRtb2Qtb2FtLTAxLCBmcm9tIGEgcXVpY2sgbG9vayBhdCB0aGUgZG9jdW1lbnQuDQoN Cg0KPkNvbW1lbnQgIzE6IFNlY3Rpb24gNg0KDQo+IFtzbmlwXQ0KPiAgICAgdHlwZWRlZiBDQ00t SW50ZXJ2YWwgew0KPiAgICAgICBkZWZhdWx0ICJpbnRlcnZhbC0xbWluIjsNCj4gICAgICAgdHlw ZSBlbnVtZXJhdGlvbiB7DQo+ICAgICAgICAgZW51bSAiaW50ZXJ2YWwtaW52YWxpZCIgew0KPiAg ICAgICAgICAgdmFsdWUgMDsNCj4gICAgICAgICB9DQogICAgICAgICAuLi4NCj4gICAgICAgICBl bnVtICJpbnRlcnZhbC0xMG1pbiIgew0KPiAgICAgICAgICAgdmFsdWUgNzsNCj4gICAgICAgICB9 DQo+ICAgICAgfQ0KICAgICAgIC4uLg0KPiAgICAgfQ0KPiBbc25pcF0NCg0KPldoZW4gY29uc2lk ZXJpbmcgYWxsIE9BTSB0b29scyBvdXQgdGhlcmUsIGRlZmluaW5nIGEgaGFyZCBjb2RlZCBzZXQg b2YgaW50ZXJ2YWxzICh2aWEgZW51bSkgbWF5IG5vdCBiZSBhIGdvb2QgaWRlYS4gQkZEIGltcGxl bWVudGF0aW9ucyAoU1cvSFcpIHNwcmluZ3MgdG8gbXkgbWluZCBpbW1lZGlhdGVseS4gRm9yIEhX IA0KPmJhc2VkIEJGRCwgQkZEIFdHIGlzIHdvcmtpbmcgb24gYW4gaW5mb3JtYXRpb25hbCBkb2N1 bWVudCBmb3IgcmVjb21tZW5kZWQgc2V0IG9mIGludGVydmFsczogZHJhZnQtaWV0Zi1iZmQtaW50 ZXJ2YWxzLiBIb3dldmVyLCBpbnRlcnZhbHMgb3V0c2lkZSBvZiB0aGF0IHNldCBjYW4gc3RpbGwg YmUgaW1wbGVtZW50ZWQgYnkgDQo+dmVuZG9ycyBmb3IgSFcgYmFzZWQgQkZELiBTVyBiYXNlZCBC RkQsIG9idmlvdXNseSwgaGFzIG11Y2ggbW9yZSBmbGV4aWJpbGl0eSBpbiB0aGUgcmFuZ2Ugb2Yg aW50ZXJ2YWxzIHRvIHVzZS4gQSBiZXR0ZXIgYXBwcm9hY2ggbWF5IGJlIHRvIGNoYW5nZSBhYm92 ZSBmcm9tIGVudW0gdG8gaWRlbnRpZnkgcmVmIChvcg0KPnNvbWV0aGluZyBlbHNlKSB3aGljaCBj YW4gYmUgYXVnbWVudGVkLg0KDQoNCj5Db21tZW50ICMyOiBTZWN0aW9uIDYNCg0KPiBbc25pcF0N Cj4gICAgIHR5cGVkZWYgZWNtcC1jaG9pY2VzIHsNCj4gICAgICAgdHlwZSBlbnVtZXJhdGlvbiB7 DQo+ICAgICAgICAgZW51bSAiZWNtcC11c2UtcGxhdGZvcm0taGFzaCIgew0KPiAgICAgICAgICAg dmFsdWUgMDsNCj4gICAgICAgICB9DQo+ICAgICAgICAgZW51bSAiZWNtcC11c2Utcm91bmQtcm9i aW4iIHsNCj4gICAgICAgICAgIHZhbHVlIDE7DQo+ICAgICAgICAgfQ0KPiAgICAgICB9DQo+ICAg ICB9DQo+IFtzbmlwXQ0KPiAgICAgICAgICAgICAgICAgbGVhZiBlY21wLWNob2ljZSB7DQo+ICAg ICAgICAgICAgICAgICAgIGNvbmZpZyB0cnVlOw0KPiAgICAgICAgICAgICAgICAgICB0eXBlIGVj bXAtY2hvaWNlczsNCj4gICAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24NCj4gICAgICAgICAg ICAgICAgICAgICAiMCBtZWFucyB1c2UgdGhlIHNwZWNpZmllZCBpbnRlcmZhY2UNCj4gICAgICAg ICAgICAgICAgICAgICAgMSBtZWFucyB1c2Ugcm91bmQgcm9iaW4iOw0KPiAgICAgICAgICAgICAg ICAgfQ0KPiBbc25pcF0NCg0KPkFib3ZlIHR3byBzZWVtcyBhIGJpdCBjb25mbGljdGluZyBmb3Ig dGhlIHZhbHVlIG9mIHplcm8oMCkuIEZvcm1lciBzdGF0ZXMgdGhhdCB6ZXJvKDApIGluZGljYXRl cyB1c2FnZSBvZiBwbGF0Zm9ybSBoYXNoIGJ1dCB0aGUgbGF0dGVyIGluZGljYXRlcyB0aGF0IHNw ZWNpZmljIGludGVyZmFjZSBpcyB1c2VkIChpLmUuIG5vdCBoYXNoZWQ/KS4gPlRoaW5raW5nIGFi b3V0IHRoaXMsIEkgYmVsaWV2ZSAiZWNtcC1jaG9pY2VzIiBpcyBvdmVybG9hZGVkLiBZb3UgYWN0 dWFsbHkgd2FudCB0byBiZSBhYmxlIHRvIGRlc2NyaWJlIDMgZGlmZmVyZW50IHRoaW5ncyBoZXJl Lg0KDQo+MS4gQ29uZmlndXJpbmcgYSBzcGVjaWZpYyBsb2FkIGJhbGFuY2luZyB0ZWNobmlxdWUg b24gYSBzeXN0ZW0gKGV4OiBFTCwgcm91bmQtcm9iaW4gb3Igc29tZXRoaW5nIGVsc2UpLg0KDQpb UWluXTogYXJlIHlvdSBwcm9wb3NpbmcgdG8gcmVwbGFjZSBlY21wLXVzZS1wbGF0Zm9ybS1oYXNo IHdpdGggRUwgYW5kIGhhdmUgdGhlIGZvbGxvd2luZyBjaGFuZ2UgdG8gZWNtcC1jaG9pY2VzIHR5 cGRlZg0KTkVXIFRFWFQ6DQoiDQogICAgIHR5cGVkZWYgZWNtcC1jaG9pY2VzIHsNCiAgICAgICB0 eXBlIGVudW1lcmF0aW9uIHsNCiAgICAgICAgIGVudW0gIkVudHJvcHkgTGFibGUiIHsNCiAgICAg ICAgICAgdmFsdWUgMDsNCiAgICAgICAgIH0NCiAgICAgICAgIGVudW0gImVjbXAtdXNlLXJvdW5k LXJvYmluIiB7DQogICAgICAgICAgIHZhbHVlIDE7DQogICAgICAgICB9DQogICAgICAgfQ0KICAg ICB9DQoiDQpIb3dldmVyIGRyYWZ0LXRpc3NhIGFsc28gaGFzIGZsb3ctZW50cm9weSBncm91cGlu ZyB0byBiZSBkZWZpbmVkDQoiDQogICAgIGdyb3VwaW5nIGZsb3ctZW50cm9weSB7DQogICAgICAg ZGVzY3JpcHRpb24NCiAgICAgICAgICJkZWZpbmVzIHRoZSBncm91cGluZyBzdGF0ZW1lbnQgZm9y IGZsb3ctZW50cm9weSI7DQogICAgICAgY2hvaWNlIGZsb3ctZW50cm9weSB7DQogICAgICAgICBj YXNlIGZsb3ctZW50cm9weS1udWxsOw0KICAgICAgIH0NCiAgICAgfQ0KIg0KV2hpY2ggbWFrZSBt ZSBkaWZmaWN1bHQgdG8gdW5kZXJzdGFuZCBob3cgZmxvdy1lbnRyb3B5IGdyb3VwaW5nIGlzIHJl bGF0ZWQgdG8gZWNtcC1jaG9pY2VzDQoNCj4yLiBEZXNjcmliaW5nIHRoZSBvdXRwdXQgYmVoYXZp b3Igb24gdGhlIE9BTSBpbnN0YW5jZSAoZXg6IG91dCB0byBzcGVjaWZpYyBpbnRlcmZhY2UgdnMu IGxvYWQgYmFsYW5jZWQpLg0KDQpbUWluXTogSSBhbSB3b25kZXJpbmcgd2h5IG5vdCBjb25zaWRl ciBpbnB1dCBiZWhhdmlvciBvciBpbnB1dCBrZXkgdG8gbG9hZCBiYWxhbmNpbmcgdGVjaG5pcXVl Lg0KDQo+My4gRGVzY3JpYmUgdGhlIHNldHRpbmcgb24gdGhlIHBhdGggZGlzY292ZXJ5IE9BTSBp bnN0YW5jZSAoZXg6IExTUCB0cmVlIHRyYWNlIHVzaW5nIG11bHRpcGF0aCAyLCA0LCA4LCA5LCAx MCkuDQoNCltRaW5dOiBJcyB0aGlzIHNldHRpbmcgb24gcGF0aCBkaXNjb3ZlcnkgT0FNIGluc3Rh bmNlIGNvbW1vbiBzZXR0aW5nPyBPciBkaWZmZXJlbnQgT0FNIHRvb2wgaGF2ZSBkaWZmZXJlbnQg c2V0dGluZyBmb3IgcGF0aCBkaXNjb3ZlcnkgbWVjaGFuaXNtLg0KT3IgeW91IGFyZSBqdXN0IHRh bGtpbmcgYWJvdXQgZGlmZmVyZW50IHBhdGggaGF2ZSBkaWZmZXJlbnQgc2V0dGluZz8NCkkgYW0g dHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhpcy4NCg0KPlBlcmhhcHMgYSBkaWZmZXJlbnQgb2JqZWN0 IGZvciBlYWNoIG1heSBiZSBhIGdvb2QgaWRlYS4gKDIpIGNhbiBiZSBhbiBlbnVtIA0KDQo+YnV0 IGl0J2xsIGJlIGJlbmVmaWNpYWwgdG8gYmUgYWJsZSBmb3IgdmFyaW91cyBPQU0gdG9vbHMgdG8g YXVnbWVudCAoMSkgYW5kICgzKS4NCg0KW1Fpbl06IEkgdGVuZCB0byBhZ3JlZSB3aXRoIHRoaXMu DQoNCg== From nobody Tue Jul 8 07:48:11 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9669E1B27B8; Tue, 8 Jul 2014 07:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.701 X-Spam-Level: X-Spam-Status: No, score=-12.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYJXTFhfQFjo; Tue, 8 Jul 2014 07:48:02 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E8F81A00F6; Tue, 8 Jul 2014 07:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33809; q=dns/txt; s=iport; t=1404830882; x=1406040482; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wLLnbtwHFbNeNu8dAqZU3DU1LBL/llCAAIZiu3LDLp0=; b=DNJRx3PeHQAnf5xOBERyaC9J4Hga7Fat1wcP/Bp04Hy4tZ4v8Nb2Mc0F hY5D1WAMIPrL0SgVyUWwzigw45y5KJ36XCRGJ+bzrVDmwcMatgjL3IoHk vkwo7Y+12e4WsFF98+N49G42BjcT4bfqBNvipnjmdK+Fe0JYrUSh6N2Bw s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIHAMEDvFOtJV2a/2dsb2JhbABZgkdHUlqCb6wojhGBYIc/ARl8FnWEAwEBAQQtQQsQAgEGAg4DBAEBCxYBBgUCAjAUCQgBAQQBDQUIiDoNk1ScIQiZNxePERYbBgGCczqBFgWcPpJEg0NsgUQ X-IronPort-AV: E=Sophos; i="5.01,625,1400025600"; d="scan'208,217"; a="59153805" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP; 08 Jul 2014 14:48:01 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s68Em0P1009340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jul 2014 14:48:00 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.36]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 09:48:00 -0500 From: "Tissa Senevirathne (tsenevir)" To: Qin Wu , "time@ietf.org" Thread-Topic: YANG models for OAM Thread-Index: Ac+E3qlMyPi638vnRGmjYh75Wx+edAATLCxAA6JRP1ABuzlT8AAF7c9Q Date: Tue, 8 Jul 2014 14:47:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.119.34] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562EEC5C77xmbrcdx08ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/oyAMum3UdQV16dMb-CKjK0ySR-Q Cc: "l2vpn@ietf.org" , "opsawg@ietf.org" , "nvo3@ietf.org" , "netmod@ietf.org" , "trill@ietf.org" Subject: Re: [netmod] YANG models for OAM X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 14:48:05 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE193562EEC5C77xmbrcdx08ciscoc_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgUWluDQoNCk1heSBiZSBhIHBvaW50IGlzIG1pc3NlZCBoZXJlLg0KDQoNCjEuICAgICAgVGhv dWdodCBTRkMgY2FuIGdvIHVwIGFuZCBkb3duIG9uIGxheWVycywgd2hhdCBjb250cm9scyB0aGF0 IGJlaGF2aW9yID8gSXOhr250IGl0IHRoZSBTZXJ2aWNlIGhlYWRlciA/DQoNCjIuICAgICAgSXMg dGhlIE9BTSBjb21lcyBkb3duIHRvIGZhdWx0IGlzb2xhdGlvbiwgdmVyaWZpY2F0aW9uICwgbW9u aXRvcmluZyBldGMgZm9yIHRoZSBzcGVjaWZpZWQgU0ggPw0KDQpMaWtlIGRpc2N1c3NlZCBiZWZv cmUgKG1hbnkgdGltZXMpIGV4YWN0IGVuLWNhcCBpcyBsZXNzIGltcG9ydGFudCB3aGF0IGlzIGlt cG9ydGFudCBpcyB0byBoYXZlIGEgbW9kZWwgdGhhdCBkZWZpbmUgT0FNIGZyYW1ld29yayBhbmQg c2NvcGUuIENGTSB0byBteSBvcGluaW9uIGRvIGFuIGV4Y2VsbGVudCBqb2IgaW4gZGVmaW5pbmcg d2hhdCBpcyBuZWVkZWQuIEhlbmNlIHRoZSBjaG9pY2Ugb2YgYSBzaW1pbGFyIG1vZGVsIGZvciB0 aGUgWUFORyBNb2RlbC4NCg0KWW91IGhhdmUgbm90ZWQgQkZEIGFuZCBDRk0gYXJlIHNpbWlsYXIg YmVjYXVzZSB0aGV5IGhhdmUgc2ltaWxhciBzZXQgb2YgdGltZXJzLiBUaGF0IGlzIGEgd3Jvbmcg Y29tcGFyaXNvbi4gSGF2ZSBzaW1pbGFyIHNldCBvZiB0aW1lcnMgZG9lcyBub3QgbWFrZSB0d28g cHJvdG9jb2xzIHRoZSBzYW1lLiBXaGF0IG1ha2VzIHRoZW0gaXMgd2hhdCBmcmFtZXdvcmsgdGhl eSBmb2xsb3dzLiAgV2UgaGF2ZSB1c2VkIGtleSB3b3JkIENGTSBoZXJlIGxvb3NlbHkuIFRob3Vn aCB3ZSBib3Jyb3cgbG90cyBvZiBjb25jZXB0cyBmb3JtIENGTSB0aGVyZSBhcmUgdGhpbmdzIHRo YXQgbmVlZGVkIHRvIGJlIHJldmlzaXRlZC4NCg0KSSBoYXZlIHJlcXVlc3RlZCBwcmVzZW50YXRp b24gc2xvdHMgaW4gbnZvMyBhbmQgTkVUTU9EIHdvcmtpbmcgZ3JvdXBzIGFuZCB3aWxsIGJlIGdv aW5nIHRocm91Z2ggaW4gZGV0YWlscyBob3cgZWFjaCBvbmUgb2YgdGhlIHRlY2hub2xvZ2llcyBt YXAgdG8gWUFORyBtb2RlbCBwcmVzZW50ZWQgaGVyZS4NCg0KRnJvbTogUWluIFd1IFttYWlsdG86 YmlsbC53dUBodWF3ZWkuY29tXQ0KU2VudDogVHVlc2RheSwgSnVseSAwOCwgMjAxNCA1OjA3IEFN DQpUbzogVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcik7IHRpbWVAaWV0Zi5vcmcNCkNjOiBu ZXRtb2RAaWV0Zi5vcmc7IG52bzNAaWV0Zi5vcmc7IHRyaWxsQGlldGYub3JnOyBsMnZwbkBpZXRm Lm9yZzsgb3BzYXdnQGlldGYub3JnDQpTdWJqZWN0OiBSRTogWUFORyBtb2RlbHMgZm9yIE9BTQ0K DQpIaSwgVGlzc2E6DQpUaGVyZSBhcmUgbWFueSBvcHRpb25zIGZvciBTRkMgT0FNLCBCRkQgZXh0 ZW5zaW9uLCBHZW5lcmljIEhlYWRlciBleHRlbnNpb24sIEdlbmVyaWMgVExWIGV4dGVuc2lvbi4N ClVubGlrZSBvdGhlciBleGlzdGluZyBPQU0gcHJvdG9jb2xzLCBtZWNoYW5pc21zIGFuZCB0b29s cywgU0ZDIG5lZWQgdG8gYWRkcmVzcyBPQU0gZm9yIHRoZSB0ZWNobm9sb2d5IHRoYXQgaXMgYWJv dmUgbGF5ZXIgMy4NClNGQyBoYXZlbqGvdCBkZXZlbG9wZWQgT0FNIHByb3RvY29sIHlldCBhdCB0 aGUgdG9wIG9mIGxheWVyIDMuDQoNCkJlZm9yZSB0aGV5IGRldmVsb3BpbmcgT0FNIHByb3RvY29s LCB0aGV5IG5lZWQgdG8gZmlndXJlIG91dCB3aGV0aGVyIHRoZXkgbmVlZCB0byBkZXZlbG9wIHRl Y2hub2xvZ3kgZGVwZW5kZW50IE9BTSBwcm90b2NvbCwNCk9yIHRlY2hub2xvZ3kgaW5kZXBlbmRl bnQgT0FNIHByb3RvY29sIHNpbmNlIFNGQyBPQU0gYW5kIE92ZXJsYXkgT0FNIHNoYXJlIGEgbG90 IG9mIHNpbWlsYXJpdGllcyhlLmcuLCBib3RoIGNhbiB1c2Ugb3ZlcmxheSB0ZWNobm9sb2d5IHRv IHN0aXRjaCBhIHNldCBvZiBvdmVybGF5IG5vZGUgb3Igc2VydmljZSBub2RlIHRvIGZvcm0gdGhl IGVuZCB0byBlbmQgcGF0aCkuIFdoeSBub3QgYnVpbGQgb25lIHByb3RvY29sIHRvIHN1cHBvcnQg Ym90aD8NCg0KVGhhdKGvcyB3aHkgd2UgYnJpbmcgdXAgdHJhbnNwb3J0IGluZGVwZW5kZW50IE9B TSBjb3ZlcmluZyB2YXJpb3VzIGhldGVyb2dlbmVvdXMgbmV0d29yayB0ZWNobm9sb2dpZXMgYW5k IHByb3Bvc2UgdG8gY29uc29saWRhdGUgT0FNIGluIGJvdGgNCk1hbmFnZW1lbnQgcGxhbmUgYW5k IGRhdGEgcGxhbmUuDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13dy1vcHNhd2ct bXVsdGktbGF5ZXItb2FtLTAyDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1raW5n LW9wc2F3Zy10aW1lLW11bHRpLWxheWVyLW9hbS11c2UtY2FzZS0wMS50eHQNCg0KUmVnYXJkaW5n IGZsb3ctZW50cm9weSwgd2h5IG5vdCByZXVzZSBlbnRyb3B5IG1lY2hhbmlzbXMgaW4gdGhlIGV4 aXN0aW5nIHVuZGVybHlpbmcgdHJhbnNwb3J0LiBIb3cgaXMgZmxvdyBlbnRyb3B5IGRpZmZlcmVu dCBmcm9tIEVDTVAgY2hvaWNlIHlvdSBwcm9wb3NlZCBpbiB0aGUgZHJhZnQuDQpJZiBteSB1bmRl cnN0YW5kaW5nIGlzIGNvcnJlY3QsIElFRUUgODAyLjFhZyBvbmx5IHN1cHBvcnQgRXF1YWwgQ29z dCBUcmVlIChFQ1QpIG1lY2hhbmlzbSBpbnN0ZWFkIG9mIEVDTVAsIElFRUU4MDIuMVFicCBzdXBw b3J0IEVDTVAsDQpBcmUgeW91IHByb3Bvc2luZyB0byBjb21iaW5lIEVDVCBzdXBwb3J0ZWQgYnkg SUVFRSA4MDIuMWFnIHdpdGggRUNNUCBzdXBwb3J0ZWQgYnkgSUVFRSA4MDIuMVFicCBhbmQgdXNl IHRoZW0gdG9nZXRoZXIgYXQgdGhlIHNhbWUgdGltZSBpbiB0aGUgc2FtZSBuZXR3b3JrPw0KDQpB bHNvIEJGRCBhbmQgSUVFRSA4MDIuMWFnIENGTSBzaGFyZSBhIGxvdCBvZiBjb21tb25hbGl0eSwg ZS5nLiwgQ0NNLWludGVydmFsLCBCRkQgaW50ZXJ2YWwuIElmIHdlIGludGVncmF0ZSB0aGVtIHRv Z2V0aGVyLCB3ZSByZWFsbHkgbmVlZCB0byB0aGluayBhYm91dCBob3cgdG8gaW50ZWdyYXRlIHRo ZW0gdG9nZXRoZXIgaW4gdGhlIG1hbmFnZW1lbnQgcGxhbmUuIElzIHRoZXJlIGFueSBjb21tb24g Y29tcG9uZW50IHdlIGNhbiBkZWZpbmUgZm9yIGJvdGg/IEhvdyB3ZSBkZWZpbmUgdGhlc2UgY29t cG9uZW50IGFuZCBtYWtlIHRoZW0gbW9yZSBleHRlbnNpYmxlLg0KDQpSZWdhcmRzIQ0KLVFpbg0K t6K8/sjLOiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSBbbWFpbHRvOnRzZW5ldmlyQGNp c2NvLmNvbV0NCreiy83KsbzkOiAyMDE0xOo21MIzMMjVIDA6MjANCsrVvP7IyzogUWluIFd1OyB0 aW1lQGlldGYub3JnPG1haWx0bzp0aW1lQGlldGYub3JnPg0Ks63LzTogbmV0bW9kQGlldGYub3Jn PG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+OyBudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYu b3JnPjsgdHJpbGxAaWV0Zi5vcmc8bWFpbHRvOnRyaWxsQGlldGYub3JnPjsgbDJ2cG5AaWV0Zi5v cmc8bWFpbHRvOmwydnBuQGlldGYub3JnPjsgb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dA aWV0Zi5vcmc+DQrW98ziOiBSRTogWUFORyBtb2RlbHMgZm9yIE9BTQ0KDQpIaSBRaW4NCg0KVGhl cmUgYXJlIHNldmVyYWwgd2F5IHRoaXMgaXMgYXBwbGljYWJsZSB0byBTRkMNCg0KDQoxLiAgICAg IFNGQyBpcyB1bmRlcmxheWVyIGluZGVwZW5kZW50ICwgd2hpY2ggbWVhbnMgaXQgY2FuIGhhdmUg YWxsIHNvcnRzIG9mIGVuY2FwIHR5cGVzIHVuZGVybmVhdGgsIHRoZSBtb2RlbCBwcmVzZW50ZWQg aW4gdGlzc2EtbmV0bW9kLW9hbSwgYWRkcmVzcyBleGFjdGx5IHRoYXQgaXNzdWUuIEluc3RlYWQg b2YgcmUtaW52ZW50aW5nIGFuZCByZS1pbXBsZW1lbnRpbmcgdmFyaW91cyBkaWZmZXJlbnQgT0FN IHRoZSBkcmFmdCBwcm9wb3NlIHRvIGludGVncmF0ZSB0aGVtIGF0IHRoZSBtYW5hZ2VtZW50IGxh eWVyLg0KDQoyLiAgICAgIEluIHRoaXMgZHJhZnQgd2UgZGVmaW5lIGEgZmxvdy1lbnRyb3B5IGFz IGFuIG9wYXF1ZSBlbGVtZW50IHRoYXQgZWFjaCBvZiB0aGUgdGVjaG5vbG9neSB0eXBlIGNhbiBz cGVjaWZ5IGFuZCBpbmNsdWRlLiBJZiB3ZSBsb29rIGF0IGRyYWZ0LXF1aW5uLXNmYy1uc2gtMDIu dHh0LCBpdCBkZWZpbmUgYSBibG9jayB0aGF0IHNwZWNpZmllcyBTRkMuIFNGQyB2ZXJzaW9uIG9m IFlBTkcgIGNhbiBzcGVjaWZ5IHRoaXMgYXMgcGFydCBvZiBpdHMgZmxvdyBlbnRyb3B5LiBUaGUg YmVhdXR5IGlzIHRoYXQgaXQgaXMgYWxsIHVwIHRvIHRoZSB0ZWNobm9sb2d5IHRvIHNwZWNpZnkg dGhhdCAoc2l6ZSBhbmQgc2hhcGUgaXMgdGVjaG5vbG9neSBkZXBlbmRlbnQpIGFuZCBiYXNlIG1v ZGVsIGlzIHN0aWxsIGludGFjdC4NCg0KV2l0aCB0aGUgYWJvdmUgaW4gbWluZCAsIGNhbiB5b3Ug cGxlYXNlIHJldmlldyBkcmFmdC10aXNzYS1uZXRtb2Qtb2FtIGFuZCBzZWUgaXQgaXMgZmxleGli bGUgYW5kIGV4dGVuc2libGUgZW5vdWdoIHRvIGZvciB0aGUgcHVycG9zZS4gSWYgdGhpbmdzIGFy ZSBtaXNzaW5nIHdlIGNhbiBhZGQgYW5kIGV4dGVuZC4NCg0KSSBoYXZlIHJlcXVlc3RlZCBuZXRt b2QgV0cgY2hhaXJzIGZvciBhIHByZXNlbnRhdGlvbiBzbG90IGZvciBmdXJ0aGVyIGRpc2N1c3Np b24gb2YgdGhlIGRyYWZ0Lg0KDQpGcm9tOiBRaW4gV3UgW21haWx0bzpiaWxsLnd1QGh1YXdlaS5j b21dDQpTZW50OiBUdWVzZGF5LCBKdW5lIDEwLCAyMDE0IDk6MjIgUE0NClRvOiBUaXNzYSBTZW5l dmlyYXRobmUgKHRzZW5ldmlyKTsgdGltZUBpZXRmLm9yZzxtYWlsdG86dGltZUBpZXRmLm9yZz4N CkNjOiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz47IG52bzNAaWV0Zi5v cmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+OyB0cmlsbEBpZXRmLm9yZzxtYWlsdG86dHJpbGxAaWV0 Zi5vcmc+OyBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+OyBvcHNhd2dAaWV0 Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBZQU5HIG1vZGVscyBm b3IgT0FNDQoNCkhpLCBUaXNzYToNClRoYW5rcyBmb3IgaW5pdGlhdGluZyBkaXNjdXNzaW9uIG9u IHRoaXMgdG9waWMuDQpVbmlmaWVkIE9BTSBmb3IgbXVsdGktTGF5ZXIgbmV0d29yayBpcyBhIGdv b2QgaWRlYSB0byBtZS4NCmRyYWZ0LXd3LW9wc2F3Zy1tdWx0aS1sYXllci1vYW0tMDAgd2UgcHJv cG9zZWQgaW4gb3BzYXdnIGxhaWQgb3V0IHRoZSBhbiBpbml0aWFsIGRlc2NyaXB0aW9uIG9mIHRo ZSBwcm9ibGVtLg0KVGhlIHF1ZXN0aW9uIHRvIGRyYWZ0LXRpc3NhLW5ldG1vZC1vYW0gaXMNCkkg YW0gd29uZGVyaW5nIGhvdyB0aGlzIGdlbmVyaWMgWWFuZyBNb2RlbCBjYW4gYmUgYXBwbGllZCB0 byBTRkMgZW52aXJvbm1lbnQ/DQpIb3cgZG8geW91IHN1cHBvcnQgdGhlIGNhc2Ugd2hlcmUgdHdv IGVuZHBvaW50cyBzdXBwb3J0IGRpZmZlcmVudCBsYXllciBPQU0gb3IgZG9lc26hr3Qgc3VwcG9y dCBhbnkgT0FNIGF0IHRoYXQgbGF5ZXIuDQoNCkJUVzogSSBoYXZlIGNjoa9lZCB0aW1lIG1haWxp bmcgbGlzdCBzaW5jZSBJIGJlbGlldmUgdGhpcyBtYWlsaW5nIGxpc3QgaXMgcHVycG9zZWQgdG8g bG9vayBmb3IgZ2VuZXJpYyBhbmQgaW50ZWdyYXRlZCBPQU0gY292ZXJpbmcgdmFyaW91cyBoZXRl cm9nZW5lb3VzIG5ldHdvcmtpbmcgdGVjaG5vbG9naWVzLg0KUmVnYXJkcyENCi1RaW4NCreivP7I yzogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gVGlzc2EgU2Vu ZXZpcmF0aG5lICh0c2VuZXZpcikNCreiy83KsbzkOiAyMDE0xOo21MIxMcjVIDM6MDMNCsrVvP7I yzogbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+OyBudm8zQGlldGYub3Jn PG1haWx0bzpudm8zQGlldGYub3JnPjsgdHJpbGxAaWV0Zi5vcmc8bWFpbHRvOnRyaWxsQGlldGYu b3JnPjsgbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPjsgb3BzYXdnQGlldGYu b3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+DQrW98ziOiBbbmV0bW9kXSBZQU5HIG1vZGVscyBm b3IgT0FNDQoNCkFsbA0KDQpXZSBoYXZlIHB1Ymxpc2hlZCBZQU5HIG1vZGVsIGZvciBPQU0uICMx IGRyYWZ0IGJlbG93IHBsYWNlIHRoZSBnZW5lcmljIGZyYW1ld29yayBmb3IgT0FNLCB0aGF0IGNh biBiZSBhdWdtZW50ZWQgZm9yIGRpZmZlcmVudCB0ZWNobm9sb2dpZXMuICMyIGFuZCAjMyBhcmUg YXBwbGljYXRpb24gb2YgdGhlIGNvbmNlcHQgdG8gTlZPMyBhbmQgVFJJTEwsDQoNCg0KMS4gICAg ICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRpc3NhLW5ldG1vZC1vYW0v DQoNCjIuICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10aXNzYS1u dm8zLXlhbmctb2FtLw0KDQozLiAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtdGlzc2EtdHJpbGwteWFuZy1vYW0vDQoNClBsZWFzZSByZXZpZXcgYW5kIHNoYXJlIHlv dXIgY29tbWVudHMNCg0KVGhhbmtzDQpUaXNzYQ0KDQoNCg== --_000_FBEA3E19AA24F847BA3AE74E2FE193562EEC5C77xmbrcdx08ciscoc_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Qin

 

May be a point is miss= ed here.

 

1.&n= bsp;     Thought SFC ca= n go up and down on layers, what controls that behavior ? Is=A1=AFnt it the= Service header ?

2.&n= bsp;     Is the OAM com= es down to fault isolation, verification , monitoring etc for the specified= SH ?

 

Like discussed before = (many times) exact en-cap is less important what is important is to have a = model that define OAM framework and scope. CFM to my opinion do an excellen= t job in defining what is needed. Hence the choice of a similar model for the YANG Model.

 

You have noted BFD and= CFM are similar because they have similar set of timers. That is a wrong c= omparison. Have similar set of timers does not make two protocols the same.= What makes them is what framework they follows.  We have used key word CFM here loosely. Though we borrow lo= ts of concepts form CFM there are things that needed to be revisited.<= /o:p>

 

I have requested prese= ntation slots in nvo3 and NETMOD working groups and will be going through i= n details how each one of the technologies map to YANG model presented here= .

 

From: Qin Wu [= mailto:bill.wu@huawei.com]
Sent: Tuesday, July 08, 2014 5:07 AM
To: Tissa Senevirathne (tsenevir); time@ietf.org
Cc: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; = opsawg@ietf.org
Subject: RE: YANG models for OAM

 

Hi, T= issa:

There= are many options for SFC OAM, BFD extension, Generic Header extension, Gen= eric TLV extension.

Unlik= e other existing OAM protocols, mechanisms and tools, SFC need to address O= AM for the technology that is above layer 3.

SFC h= aven=A1=AFt developed OAM protocol yet at the top of layer 3.

=  

Befor= e they developing OAM protocol, they need to figure out whether they need t= o develop technology dependent OAM protocol,

Or te= chnology independent OAM protocol since SFC OAM and Overlay OAM share a lot= of similarities(e.g., both can use overlay technology to stitch a set of o= verlay node or service node to form the end to end path). Why not build one protocol to support both?

=  

That= =A1=AFs why we bring up transport independent OAM covering various heteroge= neous network technologies and propose to consolidate OAM in both

Manag= ement plane and data plane.

http://tools.ietf.org/html/draft-ww-opsawg-multi-laye= r-oam-02

http://tools.ietf.org/html/draft-= king-opsawg-time-multi-layer-oam-use-case-01.txt

=  

Regar= ding flow-entropy, why not reuse entropy mechanisms in the existing underly= ing transport. How is flow entropy different from ECMP choice you proposed = in the draft.

If my= understanding is correct, IEEE 802.1ag only support Equal Cost Tree (ECT) = mechanism instead of ECMP, IEEE802.1Qbp support ECMP,

Are y= ou proposing to combine ECT supported by IEEE 802.1ag with ECMP supported b= y IEEE 802.1Qbp and use them together at the same time in the same network?=

=  

Also = BFD and IEEE 802.1ag CFM share a lot of commonality, e.g., CCM-interval, BF= D interval. If we integrate them together, we really need to think about ho= w to integrate them together in the management plane. Is there any common component we can define for both? Ho= w we define these component and make them more extensible.

=  

Regar= ds!

-Qin<= o:p>

=B7=A2=BC=FE=C8=CB: Tissa Senevirathne (tsenevir) [mailto:tsenevir@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C230=C8=D5 0:20
=CA=D5=BC=FE=C8=CB: Qin Wu; time@ietf.org
=B3=AD=CB=CD: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; <= a href=3D"mailto:opsawg@ietf.org"> opsawg@ietf.org
=D6=F7=CC=E2: RE: YANG models for OAM

 

Hi Qin

 

There are several way = this is applicable to SFC

 

1.&n= bsp;     SFC is underla= yer independent , which means it can have all sorts of encap types undernea= th, the model presented in tissa-netmod-oam, address exactly that issue. In= stead of re-inventing and re-implementing various different OAM the draft propose to integrate them at the managemen= t layer.

2.&n= bsp;     In this draft = we define a flow-entropy as an opaque element that each of the technology t= ype can specify and include. If we look at draft-quinn-sfc-nsh-02.txt, it d= efine a block that specifies SFC. SFC version of YANG  can specify this as part of its flow entropy. Th= e beauty is that it is all up to the technology to specify that (size and s= hape is technology dependent) and base model is still intact.

 

With the above in mind= , can you please review draft-tissa-netmod-oam and see it is flexible and = extensible enough to for the purpose. If things are missing we can add and = extend.

 

I have requested netmo= d WG chairs for a presentation slot for further discussion of the draft. &n= bsp;

 

From: Qin Wu [= mailto:bill.wu@huawei.com]
Sent: Tuesday, June 10, 2014 9:22 PM
To: Tissa Senevirathne (tsenevir); = time@ietf.org
Cc: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; opsawg@ietf.org<= br> Subject: RE: YANG models for OAM

 

Hi, T= issa:

Thank= s for initiating discussion on this topic.

Unifi= ed OAM for multi-Layer network is a good idea to me.

draft= -ww-opsawg-multi-layer-oam-00 we proposed in opsawg laid out the an initial= description of the problem.

The q= uestion to draft-tissa-netmod-oam is

I am = wondering how this generic Yang Model can be applied to SFC environment?

How d= o you support the case where two endpoints support different layer OAM or d= oesn=A1=AFt support any OAM at that layer.

=  

BTW: = I have cc=A1=AFed time mailing list since I believe this mailing list is pu= rposed to look for generic and integrated OAM covering various heterogeneou= s networking technologies.

Regar= ds!

-Qin<= o:p>

=B7=A2=BC=FE=C8=CB: netmod [mailto:= netmod-bounces@ietf.org] =B4=FA=B1=ED Tissa Senevirathne (tsenevi= r)
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C211=C8=D5 3:03
=CA=D5=BC=FE=C8=CB: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; <= a href=3D"mailto:opsawg@ietf.org"> opsawg@ietf.org
=D6=F7=CC=E2: [netmod] YANG models for O= AM

 

All

 

We have published YANG model for OAM. #1 draft below= place the generic framework for OAM, that can be augmented for different t= echnologies. #2 and #3 are application of the concept to NVO3 and TRILL,

 

1.      http://datatracker.ietf.org/doc/draft-tissa-netmod-oam/

2.      http://datatracker.ietf.org/doc/draft-tissa-nvo3-yang-o= am/

3.      http://datatracker.ietf.org/doc/draft-tissa-trill-yang= -oam/

 

Please review and share your comments

 

Thanks

Tissa

 

 

--_000_FBEA3E19AA24F847BA3AE74E2FE193562EEC5C77xmbrcdx08ciscoc_-- From nobody Tue Jul 8 07:53:16 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA5B1B2AEB; Tue, 8 Jul 2014 07:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.701 X-Spam-Level: X-Spam-Status: No, score=-12.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCUIGNfKrphP; Tue, 8 Jul 2014 07:52:59 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09F6C1B2AF3; Tue, 8 Jul 2014 07:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35716; q=dns/txt; s=iport; t=1404831180; x=1406040780; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JQ3eooMUAp6BTMN8ivm7l0C04NjTlzwDsOxXD2Q9uuU=; b=dfqfyVwvJixGOSAqRBQUQOtvc0+bQsOAN32HVuJ3bVtO1w3FjFuu3sKJ m4+tBFfLIoj24D9B/pEkChJQYLDsBi9XlwHGAfzXvSO+m1LkhY1ICy4u8 j3lzar86zybygHyOF9IbB69NYFzdXi1GsV/43dbiMJuyOBPSYgDXdtkN2 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIHAGUFvFOtJA2M/2dsb2JhbABZgkdHUlqCb6wojhGBYIc/ARl8FnWEAwEBAQQtQQsQAgEGAg4DBAEBCxYBBgUCAjAUCQgBAQQBDQUIiDoNk1acIQiZNxePERYbBgGCczqBFgWcPpJEg0NsgUQ X-IronPort-AV: E=Sophos;i="5.01,625,1400025600"; d="scan'208,217";a="335402635" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP; 08 Jul 2014 14:52:59 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s68EqwEV022467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jul 2014 14:52:58 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.36]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 09:52:57 -0500 From: "Tissa Senevirathne (tsenevir)" To: Qin Wu , "time@ietf.org" Thread-Topic: YANG models for OAM Thread-Index: Ac+E3qlMyPi638vnRGmjYh75Wx+edAATLCxAA6JRP1ABuzlT8AAF7c9QAACxHpA= Date: Tue, 8 Jul 2014 14:52:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.119.34] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562EEC5C98xmbrcdx08ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/WZJxMHjGF4XWRfLDsmbxQ_TM2hA Cc: "l2vpn@ietf.org" , "netmod@ietf.org" , "sfc@ietf.org" , "nvo3@ietf.org" , "trill@ietf.org" , "opsawg@ietf.org" Subject: Re: [netmod] YANG models for OAM X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 14:53:06 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE193562EEC5C98xmbrcdx08ciscoc_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 K1NGQyB3b3JraW5nIGdyb3VwLg0KDQpGcm9tOiBudm8zIFttYWlsdG86bnZvMy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcikNClNlbnQ6 IFR1ZXNkYXksIEp1bHkgMDgsIDIwMTQgNzo0OCBBTQ0KVG86IFFpbiBXdTsgdGltZUBpZXRmLm9y Zw0KQ2M6IGwydnBuQGlldGYub3JnOyBvcHNhd2dAaWV0Zi5vcmc7IG52bzNAaWV0Zi5vcmc7IG5l dG1vZEBpZXRmLm9yZzsgdHJpbGxAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbnZvM10gWUFORyBt b2RlbHMgZm9yIE9BTQ0KDQpIaSBRaW4NCg0KTWF5IGJlIGEgcG9pbnQgaXMgbWlzc2VkIGhlcmUu DQoNCg0KMS4gICAgICBUaG91Z2h0IFNGQyBjYW4gZ28gdXAgYW5kIGRvd24gb24gbGF5ZXJzLCB3 aGF0IGNvbnRyb2xzIHRoYXQgYmVoYXZpb3IgPyBJc6GvbnQgaXQgdGhlIFNlcnZpY2UgaGVhZGVy ID8NCg0KMi4gICAgICBJcyB0aGUgT0FNIGNvbWVzIGRvd24gdG8gZmF1bHQgaXNvbGF0aW9uLCB2 ZXJpZmljYXRpb24gLCBtb25pdG9yaW5nIGV0YyBmb3IgdGhlIHNwZWNpZmllZCBTSCA/DQoNCkxp a2UgZGlzY3Vzc2VkIGJlZm9yZSAobWFueSB0aW1lcykgZXhhY3QgZW4tY2FwIGlzIGxlc3MgaW1w b3J0YW50IHdoYXQgaXMgaW1wb3J0YW50IGlzIHRvIGhhdmUgYSBtb2RlbCB0aGF0IGRlZmluZSBP QU0gZnJhbWV3b3JrIGFuZCBzY29wZS4gQ0ZNIHRvIG15IG9waW5pb24gZG8gYW4gZXhjZWxsZW50 IGpvYiBpbiBkZWZpbmluZyB3aGF0IGlzIG5lZWRlZC4gSGVuY2UgdGhlIGNob2ljZSBvZiBhIHNp bWlsYXIgbW9kZWwgZm9yIHRoZSBZQU5HIE1vZGVsLg0KDQpZb3UgaGF2ZSBub3RlZCBCRkQgYW5k IENGTSBhcmUgc2ltaWxhciBiZWNhdXNlIHRoZXkgaGF2ZSBzaW1pbGFyIHNldCBvZiB0aW1lcnMu IFRoYXQgaXMgYSB3cm9uZyBjb21wYXJpc29uLiBIYXZlIHNpbWlsYXIgc2V0IG9mIHRpbWVycyBk b2VzIG5vdCBtYWtlIHR3byBwcm90b2NvbHMgdGhlIHNhbWUuIFdoYXQgbWFrZXMgdGhlbSBpcyB3 aGF0IGZyYW1ld29yayB0aGV5IGZvbGxvd3MuICBXZSBoYXZlIHVzZWQga2V5IHdvcmQgQ0ZNIGhl cmUgbG9vc2VseS4gVGhvdWdoIHdlIGJvcnJvdyBsb3RzIG9mIGNvbmNlcHRzIGZvcm0gQ0ZNIHRo ZXJlIGFyZSB0aGluZ3MgdGhhdCBuZWVkZWQgdG8gYmUgcmV2aXNpdGVkLg0KDQpJIGhhdmUgcmVx dWVzdGVkIHByZXNlbnRhdGlvbiBzbG90cyBpbiBudm8zIGFuZCBORVRNT0Qgd29ya2luZyBncm91 cHMgYW5kIHdpbGwgYmUgZ29pbmcgdGhyb3VnaCBpbiBkZXRhaWxzIGhvdyBlYWNoIG9uZSBvZiB0 aGUgdGVjaG5vbG9naWVzIG1hcCB0byBZQU5HIG1vZGVsIHByZXNlbnRlZCBoZXJlLg0KDQpGcm9t OiBRaW4gV3UgW21haWx0bzpiaWxsLnd1QGh1YXdlaS5jb21dDQpTZW50OiBUdWVzZGF5LCBKdWx5 IDA4LCAyMDE0IDU6MDcgQU0NClRvOiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKTsgdGlt ZUBpZXRmLm9yZzxtYWlsdG86dGltZUBpZXRmLm9yZz4NCkNjOiBuZXRtb2RAaWV0Zi5vcmc8bWFp bHRvOm5ldG1vZEBpZXRmLm9yZz47IG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+ OyB0cmlsbEBpZXRmLm9yZzxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+OyBsMnZwbkBpZXRmLm9yZzxt YWlsdG86bDJ2cG5AaWV0Zi5vcmc+OyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRm Lm9yZz4NClN1YmplY3Q6IFJFOiBZQU5HIG1vZGVscyBmb3IgT0FNDQoNCkhpLCBUaXNzYToNClRo ZXJlIGFyZSBtYW55IG9wdGlvbnMgZm9yIFNGQyBPQU0sIEJGRCBleHRlbnNpb24sIEdlbmVyaWMg SGVhZGVyIGV4dGVuc2lvbiwgR2VuZXJpYyBUTFYgZXh0ZW5zaW9uLg0KVW5saWtlIG90aGVyIGV4 aXN0aW5nIE9BTSBwcm90b2NvbHMsIG1lY2hhbmlzbXMgYW5kIHRvb2xzLCBTRkMgbmVlZCB0byBh ZGRyZXNzIE9BTSBmb3IgdGhlIHRlY2hub2xvZ3kgdGhhdCBpcyBhYm92ZSBsYXllciAzLg0KU0ZD IGhhdmVuoa90IGRldmVsb3BlZCBPQU0gcHJvdG9jb2wgeWV0IGF0IHRoZSB0b3Agb2YgbGF5ZXIg My4NCg0KQmVmb3JlIHRoZXkgZGV2ZWxvcGluZyBPQU0gcHJvdG9jb2wsIHRoZXkgbmVlZCB0byBm aWd1cmUgb3V0IHdoZXRoZXIgdGhleSBuZWVkIHRvIGRldmVsb3AgdGVjaG5vbG9neSBkZXBlbmRl bnQgT0FNIHByb3RvY29sLA0KT3IgdGVjaG5vbG9neSBpbmRlcGVuZGVudCBPQU0gcHJvdG9jb2wg c2luY2UgU0ZDIE9BTSBhbmQgT3ZlcmxheSBPQU0gc2hhcmUgYSBsb3Qgb2Ygc2ltaWxhcml0aWVz KGUuZy4sIGJvdGggY2FuIHVzZSBvdmVybGF5IHRlY2hub2xvZ3kgdG8gc3RpdGNoIGEgc2V0IG9m IG92ZXJsYXkgbm9kZSBvciBzZXJ2aWNlIG5vZGUgdG8gZm9ybSB0aGUgZW5kIHRvIGVuZCBwYXRo KS4gV2h5IG5vdCBidWlsZCBvbmUgcHJvdG9jb2wgdG8gc3VwcG9ydCBib3RoPw0KDQpUaGF0oa9z IHdoeSB3ZSBicmluZyB1cCB0cmFuc3BvcnQgaW5kZXBlbmRlbnQgT0FNIGNvdmVyaW5nIHZhcmlv dXMgaGV0ZXJvZ2VuZW91cyBuZXR3b3JrIHRlY2hub2xvZ2llcyBhbmQgcHJvcG9zZSB0byBjb25z b2xpZGF0ZSBPQU0gaW4gYm90aA0KTWFuYWdlbWVudCBwbGFuZSBhbmQgZGF0YSBwbGFuZS4NCmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd3LW9wc2F3Zy1tdWx0aS1sYXllci1vYW0t MDINCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWtpbmctb3BzYXdnLXRpbWUtbXVs dGktbGF5ZXItb2FtLXVzZS1jYXNlLTAxLnR4dA0KDQpSZWdhcmRpbmcgZmxvdy1lbnRyb3B5LCB3 aHkgbm90IHJldXNlIGVudHJvcHkgbWVjaGFuaXNtcyBpbiB0aGUgZXhpc3RpbmcgdW5kZXJseWlu ZyB0cmFuc3BvcnQuIEhvdyBpcyBmbG93IGVudHJvcHkgZGlmZmVyZW50IGZyb20gRUNNUCBjaG9p Y2UgeW91IHByb3Bvc2VkIGluIHRoZSBkcmFmdC4NCklmIG15IHVuZGVyc3RhbmRpbmcgaXMgY29y cmVjdCwgSUVFRSA4MDIuMWFnIG9ubHkgc3VwcG9ydCBFcXVhbCBDb3N0IFRyZWUgKEVDVCkgbWVj aGFuaXNtIGluc3RlYWQgb2YgRUNNUCwgSUVFRTgwMi4xUWJwIHN1cHBvcnQgRUNNUCwNCkFyZSB5 b3UgcHJvcG9zaW5nIHRvIGNvbWJpbmUgRUNUIHN1cHBvcnRlZCBieSBJRUVFIDgwMi4xYWcgd2l0 aCBFQ01QIHN1cHBvcnRlZCBieSBJRUVFIDgwMi4xUWJwIGFuZCB1c2UgdGhlbSB0b2dldGhlciBh dCB0aGUgc2FtZSB0aW1lIGluIHRoZSBzYW1lIG5ldHdvcms/DQoNCkFsc28gQkZEIGFuZCBJRUVF IDgwMi4xYWcgQ0ZNIHNoYXJlIGEgbG90IG9mIGNvbW1vbmFsaXR5LCBlLmcuLCBDQ00taW50ZXJ2 YWwsIEJGRCBpbnRlcnZhbC4gSWYgd2UgaW50ZWdyYXRlIHRoZW0gdG9nZXRoZXIsIHdlIHJlYWxs eSBuZWVkIHRvIHRoaW5rIGFib3V0IGhvdyB0byBpbnRlZ3JhdGUgdGhlbSB0b2dldGhlciBpbiB0 aGUgbWFuYWdlbWVudCBwbGFuZS4gSXMgdGhlcmUgYW55IGNvbW1vbiBjb21wb25lbnQgd2UgY2Fu IGRlZmluZSBmb3IgYm90aD8gSG93IHdlIGRlZmluZSB0aGVzZSBjb21wb25lbnQgYW5kIG1ha2Ug dGhlbSBtb3JlIGV4dGVuc2libGUuDQoNClJlZ2FyZHMhDQotUWluDQq3orz+yMs6IFRpc3NhIFNl bmV2aXJhdGhuZSAodHNlbmV2aXIpIFttYWlsdG86dHNlbmV2aXJAY2lzY28uY29tXQ0Kt6LLzcqx vOQ6IDIwMTTE6jbUwjMwyNUgMDoyMA0KytW8/sjLOiBRaW4gV3U7IHRpbWVAaWV0Zi5vcmc8bWFp bHRvOnRpbWVAaWV0Zi5vcmc+DQqzrcvNOiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBp ZXRmLm9yZz47IG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+OyB0cmlsbEBpZXRm Lm9yZzxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+OyBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5A aWV0Zi5vcmc+OyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz4NCtb3zOI6 IFJFOiBZQU5HIG1vZGVscyBmb3IgT0FNDQoNCkhpIFFpbg0KDQpUaGVyZSBhcmUgc2V2ZXJhbCB3 YXkgdGhpcyBpcyBhcHBsaWNhYmxlIHRvIFNGQw0KDQoNCjEuICAgICAgU0ZDIGlzIHVuZGVybGF5 ZXIgaW5kZXBlbmRlbnQgLCB3aGljaCBtZWFucyBpdCBjYW4gaGF2ZSBhbGwgc29ydHMgb2YgZW5j YXAgdHlwZXMgdW5kZXJuZWF0aCwgdGhlIG1vZGVsIHByZXNlbnRlZCBpbiB0aXNzYS1uZXRtb2Qt b2FtLCBhZGRyZXNzIGV4YWN0bHkgdGhhdCBpc3N1ZS4gSW5zdGVhZCBvZiByZS1pbnZlbnRpbmcg YW5kIHJlLWltcGxlbWVudGluZyB2YXJpb3VzIGRpZmZlcmVudCBPQU0gdGhlIGRyYWZ0IHByb3Bv c2UgdG8gaW50ZWdyYXRlIHRoZW0gYXQgdGhlIG1hbmFnZW1lbnQgbGF5ZXIuDQoNCjIuICAgICAg SW4gdGhpcyBkcmFmdCB3ZSBkZWZpbmUgYSBmbG93LWVudHJvcHkgYXMgYW4gb3BhcXVlIGVsZW1l bnQgdGhhdCBlYWNoIG9mIHRoZSB0ZWNobm9sb2d5IHR5cGUgY2FuIHNwZWNpZnkgYW5kIGluY2x1 ZGUuIElmIHdlIGxvb2sgYXQgZHJhZnQtcXVpbm4tc2ZjLW5zaC0wMi50eHQsIGl0IGRlZmluZSBh IGJsb2NrIHRoYXQgc3BlY2lmaWVzIFNGQy4gU0ZDIHZlcnNpb24gb2YgWUFORyAgY2FuIHNwZWNp ZnkgdGhpcyBhcyBwYXJ0IG9mIGl0cyBmbG93IGVudHJvcHkuIFRoZSBiZWF1dHkgaXMgdGhhdCBp dCBpcyBhbGwgdXAgdG8gdGhlIHRlY2hub2xvZ3kgdG8gc3BlY2lmeSB0aGF0IChzaXplIGFuZCBz aGFwZSBpcyB0ZWNobm9sb2d5IGRlcGVuZGVudCkgYW5kIGJhc2UgbW9kZWwgaXMgc3RpbGwgaW50 YWN0Lg0KDQpXaXRoIHRoZSBhYm92ZSBpbiBtaW5kICwgY2FuIHlvdSBwbGVhc2UgcmV2aWV3IGRy YWZ0LXRpc3NhLW5ldG1vZC1vYW0gYW5kIHNlZSBpdCBpcyBmbGV4aWJsZSBhbmQgZXh0ZW5zaWJs ZSBlbm91Z2ggdG8gZm9yIHRoZSBwdXJwb3NlLiBJZiB0aGluZ3MgYXJlIG1pc3Npbmcgd2UgY2Fu IGFkZCBhbmQgZXh0ZW5kLg0KDQpJIGhhdmUgcmVxdWVzdGVkIG5ldG1vZCBXRyBjaGFpcnMgZm9y IGEgcHJlc2VudGF0aW9uIHNsb3QgZm9yIGZ1cnRoZXIgZGlzY3Vzc2lvbiBvZiB0aGUgZHJhZnQu DQoNCkZyb206IFFpbiBXdSBbbWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbV0NClNlbnQ6IFR1ZXNk YXksIEp1bmUgMTAsIDIwMTQgOToyMiBQTQ0KVG86IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2 aXIpOyB0aW1lQGlldGYub3JnPG1haWx0bzp0aW1lQGlldGYub3JnPg0KQ2M6IG5ldG1vZEBpZXRm Lm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPjsgbnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0Bp ZXRmLm9yZz47IHRyaWxsQGlldGYub3JnPG1haWx0bzp0cmlsbEBpZXRmLm9yZz47IGwydnBuQGll dGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz47IG9wc2F3Z0BpZXRmLm9yZzxtYWlsdG86b3Bz YXdnQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFlBTkcgbW9kZWxzIGZvciBPQU0NCg0KSGksIFRp c3NhOg0KVGhhbmtzIGZvciBpbml0aWF0aW5nIGRpc2N1c3Npb24gb24gdGhpcyB0b3BpYy4NClVu aWZpZWQgT0FNIGZvciBtdWx0aS1MYXllciBuZXR3b3JrIGlzIGEgZ29vZCBpZGVhIHRvIG1lLg0K ZHJhZnQtd3ctb3BzYXdnLW11bHRpLWxheWVyLW9hbS0wMCB3ZSBwcm9wb3NlZCBpbiBvcHNhd2cg bGFpZCBvdXQgdGhlIGFuIGluaXRpYWwgZGVzY3JpcHRpb24gb2YgdGhlIHByb2JsZW0uDQpUaGUg cXVlc3Rpb24gdG8gZHJhZnQtdGlzc2EtbmV0bW9kLW9hbSBpcw0KSSBhbSB3b25kZXJpbmcgaG93 IHRoaXMgZ2VuZXJpYyBZYW5nIE1vZGVsIGNhbiBiZSBhcHBsaWVkIHRvIFNGQyBlbnZpcm9ubWVu dD8NCkhvdyBkbyB5b3Ugc3VwcG9ydCB0aGUgY2FzZSB3aGVyZSB0d28gZW5kcG9pbnRzIHN1cHBv cnQgZGlmZmVyZW50IGxheWVyIE9BTSBvciBkb2VzbqGvdCBzdXBwb3J0IGFueSBPQU0gYXQgdGhh dCBsYXllci4NCg0KQlRXOiBJIGhhdmUgY2Ohr2VkIHRpbWUgbWFpbGluZyBsaXN0IHNpbmNlIEkg YmVsaWV2ZSB0aGlzIG1haWxpbmcgbGlzdCBpcyBwdXJwb3NlZCB0byBsb29rIGZvciBnZW5lcmlj IGFuZCBpbnRlZ3JhdGVkIE9BTSBjb3ZlcmluZyB2YXJpb3VzIGhldGVyb2dlbmVvdXMgbmV0d29y a2luZyB0ZWNobm9sb2dpZXMuDQpSZWdhcmRzIQ0KLVFpbg0Kt6K8/sjLOiBuZXRtb2QgW21haWx0 bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5l dmlyKQ0Kt6LLzcqxvOQ6IDIwMTTE6jbUwjExyNUgMzowMw0KytW8/sjLOiBuZXRtb2RAaWV0Zi5v cmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz47IG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0 Zi5vcmc+OyB0cmlsbEBpZXRmLm9yZzxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+OyBsMnZwbkBpZXRm Lm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+OyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3 Z0BpZXRmLm9yZz4NCtb3zOI6IFtuZXRtb2RdIFlBTkcgbW9kZWxzIGZvciBPQU0NCg0KQWxsDQoN CldlIGhhdmUgcHVibGlzaGVkIFlBTkcgbW9kZWwgZm9yIE9BTS4gIzEgZHJhZnQgYmVsb3cgcGxh Y2UgdGhlIGdlbmVyaWMgZnJhbWV3b3JrIGZvciBPQU0sIHRoYXQgY2FuIGJlIGF1Z21lbnRlZCBm b3IgZGlmZmVyZW50IHRlY2hub2xvZ2llcy4gIzIgYW5kICMzIGFyZSBhcHBsaWNhdGlvbiBvZiB0 aGUgY29uY2VwdCB0byBOVk8zIGFuZCBUUklMTCwNCg0KDQoxLiAgICAgIGh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGlzc2EtbmV0bW9kLW9hbS8NCg0KMi4gICAgICBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRpc3NhLW52bzMteWFuZy1vYW0vDQoN CjMuICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10aXNzYS10cmls bC15YW5nLW9hbS8NCg0KUGxlYXNlIHJldmlldyBhbmQgc2hhcmUgeW91ciBjb21tZW50cw0KDQpU aGFua3MNClRpc3NhDQoNCg0K --_000_FBEA3E19AA24F847BA3AE74E2FE193562EEC5C98xmbrcdx08ciscoc_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

+SFC working group= .

 

From: nvo3 [ma= ilto:nvo3-bounces@ietf.org] On Behalf Of Tissa Senevirathne (tsenevir)
Sent: Tuesday, July 08, 2014 7:48 AM
To: Qin Wu; time@ietf.org
Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org;= trill@ietf.org
Subject: Re: [nvo3] YANG models for OAM

 

Hi Qin

 

May be a point is miss= ed here.

 

1.&n= bsp;     Thought SFC ca= n go up and down on layers, what controls that behavior ? Is=A1=AFnt it the= Service header ?

2.&n= bsp;     Is the OAM com= es down to fault isolation, verification , monitoring etc for the specified= SH ?

 

Like discussed before = (many times) exact en-cap is less important what is important is to have a = model that define OAM framework and scope. CFM to my opinion do an excellen= t job in defining what is needed. Hence the choice of a similar model for the YANG Model.

 

You have noted BFD and= CFM are similar because they have similar set of timers. That is a wrong c= omparison. Have similar set of timers does not make two protocols the same.= What makes them is what framework they follows.  We have used key word CFM here loosely. Though we borrow lo= ts of concepts form CFM there are things that needed to be revisited.<= /o:p>

 

I have requested prese= ntation slots in nvo3 and NETMOD working groups and will be going through i= n details how each one of the technologies map to YANG model presented here= .

 

From: Qin Wu [= mailto:bill.wu@huawei.com]
Sent: Tuesday, July 08, 2014 5:07 AM
To: Tissa Senevirathne (tsenevir); = time@ietf.org
Cc: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; opsawg@ietf.org<= br> Subject: RE: YANG models for OAM

 

Hi, T= issa:

There= are many options for SFC OAM, BFD extension, Generic Header extension, Gen= eric TLV extension.

Unlik= e other existing OAM protocols, mechanisms and tools, SFC need to address O= AM for the technology that is above layer 3.

SFC h= aven=A1=AFt developed OAM protocol yet at the top of layer 3.

=  

Befor= e they developing OAM protocol, they need to figure out whether they need t= o develop technology dependent OAM protocol,

Or te= chnology independent OAM protocol since SFC OAM and Overlay OAM share a lot= of similarities(e.g., both can use overlay technology to stitch a set of o= verlay node or service node to form the end to end path). Why not build one protocol to support both?

=  

That= =A1=AFs why we bring up transport independent OAM covering various heteroge= neous network technologies and propose to consolidate OAM in both

Manag= ement plane and data plane.

http://tools.ietf.org/html/draft-ww-opsawg-multi-laye= r-oam-02

http://tools.ietf.org/html/draft-= king-opsawg-time-multi-layer-oam-use-case-01.txt

=  

Regar= ding flow-entropy, why not reuse entropy mechanisms in the existing underly= ing transport. How is flow entropy different from ECMP choice you proposed = in the draft.

If my= understanding is correct, IEEE 802.1ag only support Equal Cost Tree (ECT) = mechanism instead of ECMP, IEEE802.1Qbp support ECMP,

Are y= ou proposing to combine ECT supported by IEEE 802.1ag with ECMP supported b= y IEEE 802.1Qbp and use them together at the same time in the same network?=

=  

Also = BFD and IEEE 802.1ag CFM share a lot of commonality, e.g., CCM-interval, BF= D interval. If we integrate them together, we really need to think about ho= w to integrate them together in the management plane. Is there any common component we can define for both? Ho= w we define these component and make them more extensible.

=  

Regar= ds!

-Qin<= o:p>

=B7=A2=BC=FE=C8=CB: Tissa Senevirathne (tsenevir) [mailto:tsenevir@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C230=C8=D5 0:20
=CA=D5=BC=FE=C8=CB: Qin Wu; time@ietf.org
=B3=AD=CB=CD: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; <= a href=3D"mailto:opsawg@ietf.org"> opsawg@ietf.org
=D6=F7=CC=E2: RE: YANG models for OAM

 

Hi Qin

 

There are several way = this is applicable to SFC

 

1.&n= bsp;     SFC is underla= yer independent , which means it can have all sorts of encap types undernea= th, the model presented in tissa-netmod-oam, address exactly that issue. In= stead of re-inventing and re-implementing various different OAM the draft propose to integrate them at the managemen= t layer.

2.&n= bsp;     In this draft = we define a flow-entropy as an opaque element that each of the technology t= ype can specify and include. If we look at draft-quinn-sfc-nsh-02.txt, it d= efine a block that specifies SFC. SFC version of YANG  can specify this as part of its flow entropy. Th= e beauty is that it is all up to the technology to specify that (size and s= hape is technology dependent) and base model is still intact.

 

With the above in mind= , can you please review draft-tissa-netmod-oam and see it is flexible and = extensible enough to for the purpose. If things are missing we can add and = extend.

 

I have requested netmo= d WG chairs for a presentation slot for further discussion of the draft. &n= bsp;

 

From: Qin Wu [= mailto:bill.wu@huawei.com]
Sent: Tuesday, June 10, 2014 9:22 PM
To: Tissa Senevirathne (tsenevir); = time@ietf.org
Cc: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; opsawg@ietf.org<= br> Subject: RE: YANG models for OAM

 

Hi, T= issa:

Thank= s for initiating discussion on this topic.

Unifi= ed OAM for multi-Layer network is a good idea to me.

draft= -ww-opsawg-multi-layer-oam-00 we proposed in opsawg laid out the an initial= description of the problem.

The q= uestion to draft-tissa-netmod-oam is

I am = wondering how this generic Yang Model can be applied to SFC environment?

How d= o you support the case where two endpoints support different layer OAM or d= oesn=A1=AFt support any OAM at that layer.

=  

BTW: = I have cc=A1=AFed time mailing list since I believe this mailing list is pu= rposed to look for generic and integrated OAM covering various heterogeneou= s networking technologies.

Regar= ds!

-Qin<= o:p>

=B7=A2=BC=FE=C8=CB: netmod [mailto:= netmod-bounces@ietf.org] =B4=FA=B1=ED Tissa Senevirathne (tsenevi= r)
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C211=C8=D5 3:03
=CA=D5=BC=FE=C8=CB: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; <= a href=3D"mailto:opsawg@ietf.org"> opsawg@ietf.org
=D6=F7=CC=E2: [netmod] YANG models for O= AM

 

All

 

We have published YANG model for OAM. #1 draft below= place the generic framework for OAM, that can be augmented for different t= echnologies. #2 and #3 are application of the concept to NVO3 and TRILL,

 

1.      http://datatracker.ietf.org/doc/draft-tissa-netmod-oam/

2.      http://datatracker.ietf.org/doc/draft-tissa-nvo3-yang-o= am/

3.      http://datatracker.ietf.org/doc/draft-tissa-trill-yang= -oam/

 

Please review and share your comments

 

Thanks

Tissa

 

 

--_000_FBEA3E19AA24F847BA3AE74E2FE193562EEC5C98xmbrcdx08ciscoc_-- From nobody Tue Jul 8 07:54:44 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D791B2AEB for ; Tue, 8 Jul 2014 07:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQFFU5Av9jYu for ; Tue, 8 Jul 2014 07:54:38 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5E061B2AF8 for ; Tue, 8 Jul 2014 07:54:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id CC0DB5407DB; Tue, 8 Jul 2014 16:54:31 +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 Uz2CxIZwNj1R; Tue, 8 Jul 2014 16:54:27 +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 401EE540138; Tue, 8 Jul 2014 16:54:25 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Balazs Lengyel In-Reply-To: References: <53B55FA8.8090501@ericsson.com> User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 08 Jul 2014 16:54:25 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/QQro_mEwxa9RIecLTeyvkvnEyJ0 Cc: "netmod@ietf.org >> netmod@ietf.org" Subject: Re: [netmod] New YANG issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 14:54:41 -0000 Andy Bierman writes: > On Thu, Jul 3, 2014 at 6:50 AM, Balazs Lengyel > wrote: > >> Hello, >> Ericsson decided that we would need 3 additions to the list of issues for >> YANG 1.1. I am really sorry for bringing up issues this late, but after the >> internal decision that Ericsson should become more active around Netconf >> (which I hope is a gain for the Netconf community), the following issues >> became really important for us. >> >> 1) Non-Unique leaf-list: YANG shall allow leaf-lists whose members are not >> unique. >> They are needed in a number of cases especially for user-ordered lists, >> where the position is stable and carries a meaning. >> >> > I actually like this one, but I think this is a more general problem > which has been raised before, but should be reconsidered. > > Perhaps YANG 1.1 should allow user-ordered lists and leaf-lists to be keyed > by > the sibling order, and not require any keys. That would solve your problem. > It actually shows up in the example-jukebox "playlist" in RESTCONF. > This is a list instead of a leaf-list just so a dummy key can be defined, > just so duplicates can be allowed in the playlist. > > > YANG 1.0: > > list song { > key index; > ordered-by user; > > description > "Example nested configuration data resource"; > > leaf index { // not really needed > type uint32; > description > "An arbitrary integer index for this playlist song."; // > <<<<< Yuch!!! > } > leaf id { > type rc:data-resource-identifier; > mandatory true; > description > "Song identifier. Must identify an instance of > /jukebox/library/artist/album/song/name."; > } > } > > > Maybe YANG 1.1: > > > leaf-list song { > ordered-by user; > type rc:data-resource-identifier; > description > "Song identifier. Must identify an instance of > /jukebox/library/artist/album/song/name."; > } > > IMO this is a lot cleaner (You are right Balazs) Yes, I'd support this. There are other use cases such as AS-Path that may contain the same AS number repeatedly. > > There would need to be a way in NETCONF to insert and delete by position > instead of keys > or leaf-list value. (e.g add position="N" attribute in YANG 1.1 to go with > the "insert" > and nc:operation="delete" attributes). Maybe it's time to move this from YANG to NETCONF spec where it really belongs? Lada > > > > > >> regards Balazs > > > > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jul 8 08:26:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097CD1A007E for ; Tue, 8 Jul 2014 08:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_TOOL=2.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwxnyI-4yIcU for ; Tue, 8 Jul 2014 08:26:24 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4EE21B2B1A for ; Tue, 8 Jul 2014 08:26:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 70F315407DB; Tue, 8 Jul 2014 17:26:21 +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 67KXKmacLydN; Tue, 8 Jul 2014 17:26:13 +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 1E64F540138; Tue, 8 Jul 2014 17:26:12 +0200 (CEST) From: Ladislav Lhotka To: "Lisa Huang \(yihuan\)" , "Dana Blair \(dblair\)" , "netmod\@ietf.org" In-Reply-To: References: User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 08 Jul 2014 17:26:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/EPvH4HbSdIH_bxsV9jbc0r4uABk Subject: Re: [netmod] FW: New Version Notification for draft-bogdanovic-netmod-acl-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 15:26:26 -0000 Hi, I think a data model for route filters will be badly needed before long, and since route filters are based on the same ACL model, perhaps it would be useful to generalize this draft to include route filters as well. Lada "Lisa Huang (yihuan)" writes: > The document contains a base ACL model that could be flexibly extended or > adapted by different vendors. It is with cross-company support. We will be > presenting this work at the netmod WG meeting. > > We wish to acknowledge the helpful contributions, comments, and > suggestions from Alex Clem and Andy Bierman on ACL model, who also > co-authored draft-huang-netmod-acl. > > Thanks, > > Lisa > > On 6/26/14 11:54 AM, "Dana Blair (dblair)" wrote: > >>FYI and comments =C5=A0 >> >>Here is an initial draft proposal for a YANG model for an Access Control >>List. >> >> >>I need to clarify Cisco's position on this proposal for an Access Control >>List yang model since >>there was an expired draft, draft-huang-netmod-acl-03.txt, which had Cisco >>authorship. >> >>Cisco's position is to support this new draft, >>draft-bogdanovic-netmod-acl-model-01.txt, >>and not support the expired draft, draft-huang-netmod-acl-03.txt. >> >>Changes from version 00 to 01 of draft-bogdanovic-netmod-acl-model. >>1. Complete the list of authors >>2. Add grouping timerange >>3. Fix the XML example >>4. Remove some terms from "Definitions and Acronyms" which were not used. >> >>thanks, >>Dana >> >> >>On 6/26/14 12:49 PM, "internet-drafts@ietf.org" >>wrote: >> >>> >>>A new version of I-D, draft-bogdanovic-netmod-acl-model-01.txt >>>has been successfully submitted by Dean Bogdanovic and posted to the >>>IETF repository. >>> >>>Name: draft-bogdanovic-netmod-acl-model >>>Revision: 01 >>>Title: ACL YANG model >>>Document date: 2014-06-26 >>>Group: Individual Submission >>>Pages: 17 >>>URL:=20=20=20=20=20=20=20=20=20=20=20=20 >>>http://www.ietf.org/internet-drafts/draft-bogdanovic-netmod-acl-model-01. >>>t >>>xt >>>Status:=20=20=20=20=20=20=20=20=20 >>>https://datatracker.ietf.org/doc/draft-bogdanovic-netmod-acl-model/ >>>Htmlized:=20=20=20=20=20=20=20 >>>http://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-01 >>>Diff:=20=20=20=20=20=20=20=20=20=20=20 >>>http://www.ietf.org/rfcdiff?url2=3Ddraft-bogdanovic-netmod-acl-model-01 >>> >>>Abstract: >>> This document describes information and data model of Access Control >>> List (ACL) basic building blocks. >>> >>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 >>>=20=20=20=20=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. >>> >>>The IETF Secretariat >>> >> >>_______________________________________________ >>netmod mailing list >>netmod@ietf.org >>https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jul 8 08:50:30 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F11C1B2B2B for ; Tue, 8 Jul 2014 08:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.852 X-Spam-Level: X-Spam-Status: No, score=-12.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWqAcgxCulHG for ; Tue, 8 Jul 2014 08:50:14 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58BD01B2B31 for ; Tue, 8 Jul 2014 08:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3362; q=dns/txt; s=iport; t=1404834605; x=1406044205; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=X9cc7MoT3OWr+/q2UFjT+UQILbfoIdOlQNkWjbs69pE=; b=IqduaaEF4M9Da3NYOtbpyG0Ihn1JJha+o758h1qVAAInF88msHMU19sL oFZh/SUCdDFhRftJAqLgsXC3OfmrhdrcILj2DYYq6maxT+vzAfavl7Ei+ 1kV5Cv0v/dHimjEh0FaYe+2AoupAAmm9tzag6Bzr02tufnkTRbtndMtUW 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4JAEYSvFOtJA2J/2dsb2JhbABZgw5SUwe+fgqGbFMBgRYWdYQDAQEBBAEBAWsJFAEIGFULHAkCBAESCYg5CAXJRRePSYRDBZp2gUiSRIIBgUKCMA X-IronPort-AV: E=Sophos;i="5.01,625,1400025600"; d="scan'208";a="59167037" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP; 08 Jul 2014 15:50:04 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s68Fo41w019858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jul 2014 15:50:04 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.47]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 10:50:04 -0500 From: "Dana Blair (dblair)" To: Ladislav Lhotka , "Lisa Huang (yihuan)" , "netmod@ietf.org" Thread-Topic: [netmod] FW: New Version Notification for draft-bogdanovic-netmod-acl-model-01.txt Thread-Index: AQHPkWBDQELkwxkwnEy2FEpwoi+4qJuDzroAgAC9AwCAEic5gP//xDyA Date: Tue, 8 Jul 2014 15:50:02 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.135.16.30] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <54794A9517FA2A40A530429CC673E499@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/9d3Nc3ProFC6a55UxjYB5vgoBD0 Subject: Re: [netmod] FW: New Version Notification for draft-bogdanovic-netmod-acl-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 15:50:25 -0000 Can you provide a route filters example ? We'll take a look. Dana On 7/8/14 11:26 AM, "Ladislav Lhotka" wrote: >Hi, > >I think a data model for route filters will be badly needed before long, >and since route filters are based on the same ACL model, perhaps it >would be useful to generalize this draft to include route filters as >well. > >Lada > >"Lisa Huang (yihuan)" writes: > >> The document contains a base ACL model that could be flexibly extended >>or >> adapted by different vendors. It is with cross-company support. We will >>be >> presenting this work at the netmod WG meeting. >> >> We wish to acknowledge the helpful contributions, comments, and >> suggestions from Alex Clem and Andy Bierman on ACL model, who also >> co-authored draft-huang-netmod-acl. >> >> Thanks, >> >> Lisa >> >> On 6/26/14 11:54 AM, "Dana Blair (dblair)" wrote: >> >>>FYI and comments =A9 >>> >>>Here is an initial draft proposal for a YANG model for an Access Control >>>List. >>> >>> >>>I need to clarify Cisco's position on this proposal for an Access >>>Control >>>List yang model since >>>there was an expired draft, draft-huang-netmod-acl-03.txt, which had >>>Cisco >>>authorship. >>> >>>Cisco's position is to support this new draft, >>>draft-bogdanovic-netmod-acl-model-01.txt, >>>and not support the expired draft, draft-huang-netmod-acl-03.txt. >>> >>>Changes from version 00 to 01 of draft-bogdanovic-netmod-acl-model. >>>1. Complete the list of authors >>>2. Add grouping timerange >>>3. Fix the XML example >>>4. Remove some terms from "Definitions and Acronyms" which were not >>>used. >>> >>>thanks, >>>Dana >>> >>> >>>On 6/26/14 12:49 PM, "internet-drafts@ietf.org" >>> >>>wrote: >>> >>>> >>>>A new version of I-D, draft-bogdanovic-netmod-acl-model-01.txt >>>>has been successfully submitted by Dean Bogdanovic and posted to the >>>>IETF repository. >>>> >>>>Name: draft-bogdanovic-netmod-acl-model >>>>Revision: 01 >>>>Title: ACL YANG model >>>>Document date: 2014-06-26 >>>>Group: Individual Submission >>>>Pages: 17 >>>>URL: =20 >>>>http://www.ietf.org/internet-drafts/draft-bogdanovic-netmod-acl-model-0 >>>>1. >>>>t >>>>xt >>>>Status: =20 >>>>https://datatracker.ietf.org/doc/draft-bogdanovic-netmod-acl-model/ >>>>Htmlized: =20 >>>>http://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-01 >>>>Diff: =20 >>>>http://www.ietf.org/rfcdiff?url2=3Ddraft-bogdanovic-netmod-acl-model-01 >>>> >>>>Abstract: >>>> This document describes information and data model of Access Control >>>> List (ACL) basic building blocks. >>>> >>>> =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 >>>> >>> >>>_______________________________________________ >>>netmod mailing list >>>netmod@ietf.org >>>https://www.ietf.org/mailman/listinfo/netmod >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > >--=20 >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: E74E8C0C From nobody Tue Jul 8 09:14:50 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C921B2B8A for ; Tue, 8 Jul 2014 09:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.998 X-Spam-Level: X-Spam-Status: No, score=0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MANGLED_TOOL=2.3, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTZBP_wcwB-n for ; Tue, 8 Jul 2014 09:14:47 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAFFA1B2B95 for ; Tue, 8 Jul 2014 09:14:43 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 18EFB13FB6B; Tue, 8 Jul 2014 18:14:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1404836082; bh=IOgmm1Q7zR6+0VulpdWkvXlgIhIwAE3CB0aQKGJMgsQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=HKlxpP6SWLHXVLni2phYyEHlGuORD6Wa1giD1eH6BuzUuuFR7Wzn3+yNuIoV+a7LC hFSUmpuLJfewRGjxXf1ohFfQmPjbWhyZJQxLDtzzVohz5QaZS9MAuzqr3s3Jv90Pyk lF4nmEYcuqFqi2CAaDKj7EIu2qQnquOpcU2bO+i0= Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 8 Jul 2014 18:14:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Dana Blair (dblair)" X-Mailer: Apple Mail (2.1878.2) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/B8umu0snuyd6Ng9ytwalx51hA8M Cc: "netmod@ietf.org" Subject: Re: [netmod] FW: New Version Notification for draft-bogdanovic-netmod-acl-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 16:14:49 -0000 On 08 Jul 2014, at 17:50, Dana Blair (dblair) wrote: > Can you provide a route filters example ? We'll take a look. Cisco IOS: = http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_pi/command/iri-cr= -book/iri-cr-a1.html#wp2791314648 Junos: = https://www.juniper.net/techpubs/en_US/junos14.1/topics/usage-guidelines/p= olicy-configuring-route-lists-for-use-in-routing-policy-match-conditions.h= tml BIRD: http://bird.network.cz/?get_doc&f=3Dbird-5.html Lada >=20 > Dana >=20 > On 7/8/14 11:26 AM, "Ladislav Lhotka" wrote: >=20 >> Hi, >>=20 >> I think a data model for route filters will be badly needed before = long, >> and since route filters are based on the same ACL model, perhaps it >> would be useful to generalize this draft to include route filters as >> well. >>=20 >> Lada >>=20 >> "Lisa Huang (yihuan)" writes: >>=20 >>> The document contains a base ACL model that could be flexibly = extended >>> or >>> adapted by different vendors. It is with cross-company support. We = will >>> be >>> presenting this work at the netmod WG meeting. >>>=20 >>> We wish to acknowledge the helpful contributions, comments, and >>> suggestions from Alex Clem and Andy Bierman on ACL model, who also >>> co-authored draft-huang-netmod-acl. >>>=20 >>> Thanks, >>>=20 >>> Lisa >>>=20 >>> On 6/26/14 11:54 AM, "Dana Blair (dblair)" wrote: >>>=20 >>>> FYI and comments =A9 >>>>=20 >>>> Here is an initial draft proposal for a YANG model for an Access = Control >>>> List. >>>>=20 >>>>=20 >>>> I need to clarify Cisco's position on this proposal for an Access >>>> Control >>>> List yang model since >>>> there was an expired draft, draft-huang-netmod-acl-03.txt, which = had >>>> Cisco >>>> authorship. >>>>=20 >>>> Cisco's position is to support this new draft, >>>> draft-bogdanovic-netmod-acl-model-01.txt, >>>> and not support the expired draft, draft-huang-netmod-acl-03.txt. >>>>=20 >>>> Changes from version 00 to 01 of draft-bogdanovic-netmod-acl-model. >>>> 1. Complete the list of authors >>>> 2. Add grouping timerange >>>> 3. Fix the XML example >>>> 4. Remove some terms from "Definitions and Acronyms" which were = not >>>> used. >>>>=20 >>>> thanks, >>>> Dana >>>>=20 >>>>=20 >>>> On 6/26/14 12:49 PM, "internet-drafts@ietf.org" >>>> >>>> wrote: >>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-bogdanovic-netmod-acl-model-01.txt >>>>> has been successfully submitted by Dean Bogdanovic and posted to = the >>>>> IETF repository. >>>>>=20 >>>>> Name: draft-bogdanovic-netmod-acl-model >>>>> Revision: 01 >>>>> Title: ACL YANG model >>>>> Document date: 2014-06-26 >>>>> Group: Individual Submission >>>>> Pages: 17 >>>>> URL: =20 >>>>> = http://www.ietf.org/internet-drafts/draft-bogdanovic-netmod-acl-model-0 >>>>> 1. >>>>> t >>>>> xt >>>>> Status: =20 >>>>> = https://datatracker.ietf.org/doc/draft-bogdanovic-netmod-acl-model/ >>>>> Htmlized: =20 >>>>> http://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-01 >>>>> Diff: =20 >>>>> = http://www.ietf.org/rfcdiff?url2=3Ddraft-bogdanovic-netmod-acl-model-01 >>>>>=20 >>>>> Abstract: >>>>> This document describes information and data model of Access = Control >>>>> List (ACL) basic building blocks. >>>>>=20 >>>>>=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 >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> --=20 >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jul 8 09:25:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12C61B2B33 for ; Tue, 8 Jul 2014 09:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.302 X-Spam-Level: X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzCxGqXwmked for ; Tue, 8 Jul 2014 09:25:31 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D61691A0354 for ; Tue, 8 Jul 2014 09:25:30 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB421.namprd05.prod.outlook.com (10.141.58.139) with Microsoft SMTP Server (TLS) id 15.0.980.8; Tue, 8 Jul 2014 16:25:29 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.209]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.209]) with mapi id 15.00.0974.002; Tue, 8 Jul 2014 16:25:29 +0000 From: Dean Bogdanovic To: "Dana Blair (dblair)" Thread-Topic: [netmod] New Version Notification for draft-bogdanovic-netmod-acl-model-01.txt Thread-Index: AQHPmsk7Sovos6WR1Emg5oDkpiyJxg== Date: Tue, 8 Jul 2014 16:25:28 +0000 Message-ID: <4E32A3D9-ABBD-4C70-99B9-F89F37A2D317@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0266491E90 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(164054003)(479174003)(377454003)(377424004)(24454002)(69234005)(51704005)(199002)(87936001)(106356001)(2656002)(36756003)(31966008)(79102001)(104166001)(20776003)(62966002)(77156001)(15202345003)(80022001)(4396001)(86362001)(21056001)(575784001)(81542001)(74502001)(110136001)(64706001)(33656002)(76176999)(99396002)(81342001)(19580405001)(83072002)(87286001)(92566001)(50986999)(74662001)(92726001)(19580395003)(107046002)(89996001)(561944003)(76482001)(85852003)(101416001)(95666004)(15975445006)(77982001)(50226001)(46102001)(83322001)(93916002)(106116001)(99286002)(105586002)(77096002)(85306003)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB421; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-2" Content-ID: <87819C19D7827147A643EE28EBC7012F@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/HE86LAN7e8s50Sc3_V7QIIoWkfM Cc: "netmod@ietf.org" Subject: Re: [netmod] New Version Notification for draft-bogdanovic-netmod-acl-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 16:25:32 -0000 Dana, The route filters have the same structure as firewall filters. There can be= multiple ACEs in one ACL. Each ACE has match condition followed by action. example for Juniper policy-statement hosts-only { term1 { from { route-filter 10.0.0.0/16 upto /31 reject; } then accept; } } So we can use the same containers match and action, but have to add new ace= -type route-filter in the match container. See which match statements are c= ommon between vendors and which would go into vendor specific module. Dean On Jul 8, 2014, at 11:50 AM, Dana Blair (dblair) wrote: > Can you provide a route filters example ? We'll take a look. >=20 > Dana >=20 > On 7/8/14 11:26 AM, "Ladislav Lhotka" wrote: >=20 >> Hi, >>=20 >> I think a data model for route filters will be badly needed before long, >> and since route filters are based on the same ACL model, perhaps it >> would be useful to generalize this draft to include route filters as >> well. >>=20 >> Lada >>=20 >> "Lisa Huang (yihuan)" writes: >>=20 >>> The document contains a base ACL model that could be flexibly extended >>> or >>> adapted by different vendors. It is with cross-company support. We will >>> be >>> presenting this work at the netmod WG meeting. >>>=20 >>> We wish to acknowledge the helpful contributions, comments, and >>> suggestions from Alex Clem and Andy Bierman on ACL model, who also >>> co-authored draft-huang-netmod-acl. >>>=20 >>> Thanks, >>>=20 >>> Lisa >>>=20 >>> On 6/26/14 11:54 AM, "Dana Blair (dblair)" wrote: >>>=20 >>>> FYI and comments =A9 >>>>=20 >>>> Here is an initial draft proposal for a YANG model for an Access Contr= ol >>>> List. >>>>=20 >>>>=20 >>>> I need to clarify Cisco's position on this proposal for an Access >>>> Control >>>> List yang model since >>>> there was an expired draft, draft-huang-netmod-acl-03.txt, which had >>>> Cisco >>>> authorship. >>>>=20 >>>> Cisco's position is to support this new draft, >>>> draft-bogdanovic-netmod-acl-model-01.txt, >>>> and not support the expired draft, draft-huang-netmod-acl-03.txt. >>>>=20 >>>> Changes from version 00 to 01 of draft-bogdanovic-netmod-acl-model. >>>> 1. Complete the list of authors >>>> 2. Add grouping timerange >>>> 3. Fix the XML example >>>> 4. Remove some terms from "Definitions and Acronyms" which were not >>>> used. >>>>=20 >>>> thanks, >>>> Dana >>>>=20 >>>>=20 >>>> On 6/26/14 12:49 PM, "internet-drafts@ietf.org" >>>> >>>> wrote: >>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-bogdanovic-netmod-acl-model-01.txt >>>>> has been successfully submitted by Dean Bogdanovic and posted to the >>>>> IETF repository. >>>>>=20 >>>>> Name: draft-bogdanovic-netmod-acl-model >>>>> Revision: 01 >>>>> Title: ACL YANG model >>>>> Document date: 2014-06-26 >>>>> Group: Individual Submission >>>>> Pages: 17 >>>>> URL: =20 >>>>> http://www.ietf.org/internet-drafts/draft-bogdanovic-netmod-acl-model= -0 >>>>> 1. >>>>> t >>>>> xt >>>>> Status: =20 >>>>> https://datatracker.ietf.org/doc/draft-bogdanovic-netmod-acl-model/ >>>>> Htmlized: =20 >>>>> http://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-01 >>>>> Diff: =20 >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-bogdanovic-netmod-acl-model-= 01 >>>>>=20 >>>>> Abstract: >>>>> This document describes information and data model of Access Control >>>>> List (ACL) basic building blocks. >>>>>=20 >>>>>=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 >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> --=20 >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Jul 8 09:36:46 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5740C1B2B73 for ; Tue, 8 Jul 2014 09:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.998 X-Spam-Level: X-Spam-Status: No, score=0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MANGLED_TOOL=2.3, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKsAg7hTpHDF for ; Tue, 8 Jul 2014 09:36:43 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0304C1A0394 for ; Tue, 8 Jul 2014 09:36:43 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 4D69E13FB6B; Tue, 8 Jul 2014 18:36:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1404837401; bh=YN5sA+vg/P4Lm9KY/3sam/KZQiaILNJblTfw2uW6dAY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=L4ppVP2QgT0xL6kRrEpjTzBm2zZElOHNIkrn821TsP6TMOqpxUQwJzhHpD6a5seV7 bnnEFPvUU20b7FfhpLl8+isW1OZueR7bmyNt1nLK1Z1JPKvo5A/T4Man/+u0KotEI/ SU2FqRSBmpaViJqha9WJ5hW66/tBn5fkWpGcUSUo= Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ladislav Lhotka In-Reply-To: <4E32A3D9-ABBD-4C70-99B9-F89F37A2D317@juniper.net> Date: Tue, 8 Jul 2014 18:36:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E32A3D9-ABBD-4C70-99B9-F89F37A2D317@juniper.net> To: Dean Bogdanovic X-Mailer: Apple Mail (2.1878.2) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/NuFVWxO4AXSZyWKXY9_gCPwwm14 Cc: "Dana Blair \(dblair\)" , "netmod@ietf.org" Subject: Re: [netmod] New Version Notification for draft-bogdanovic-netmod-acl-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 16:36:44 -0000 Hi Dean, On 08 Jul 2014, at 18:25, Dean Bogdanovic wrote: > Dana, >=20 > The route filters have the same structure as firewall filters. There = can be multiple ACEs in one ACL. Each ACE has match condition followed = by action. >=20 > example for Juniper >=20 > policy-statement hosts-only { > term1 { > from { > route-filter 10.0.0.0/16 upto /31 reject; > } > then accept; > } > } >=20 > So we can use the same containers match and action, but have to add = new ace-type route-filter in the match container. See which match = statements are common between vendors and which would go into vendor = specific module. Exactly. In terms of YANG module structure, one module should define = only the ACL-ACE framework, and other modules should augment it with = specific match conditions and action types. Thanks, Lada >=20 > Dean >=20 > On Jul 8, 2014, at 11:50 AM, Dana Blair (dblair) = wrote: >=20 >> Can you provide a route filters example ? We'll take a look. >>=20 >> Dana >>=20 >> On 7/8/14 11:26 AM, "Ladislav Lhotka" wrote: >>=20 >>> Hi, >>>=20 >>> I think a data model for route filters will be badly needed before = long, >>> and since route filters are based on the same ACL model, perhaps it >>> would be useful to generalize this draft to include route filters as >>> well. >>>=20 >>> Lada >>>=20 >>> "Lisa Huang (yihuan)" writes: >>>=20 >>>> The document contains a base ACL model that could be flexibly = extended >>>> or >>>> adapted by different vendors. It is with cross-company support. We = will >>>> be >>>> presenting this work at the netmod WG meeting. >>>>=20 >>>> We wish to acknowledge the helpful contributions, comments, and >>>> suggestions from Alex Clem and Andy Bierman on ACL model, who also >>>> co-authored draft-huang-netmod-acl. >>>>=20 >>>> Thanks, >>>>=20 >>>> Lisa >>>>=20 >>>> On 6/26/14 11:54 AM, "Dana Blair (dblair)" = wrote: >>>>=20 >>>>> FYI and comments =A9 >>>>>=20 >>>>> Here is an initial draft proposal for a YANG model for an Access = Control >>>>> List. >>>>>=20 >>>>>=20 >>>>> I need to clarify Cisco's position on this proposal for an Access >>>>> Control >>>>> List yang model since >>>>> there was an expired draft, draft-huang-netmod-acl-03.txt, which = had >>>>> Cisco >>>>> authorship. >>>>>=20 >>>>> Cisco's position is to support this new draft, >>>>> draft-bogdanovic-netmod-acl-model-01.txt, >>>>> and not support the expired draft, draft-huang-netmod-acl-03.txt. >>>>>=20 >>>>> Changes from version 00 to 01 of = draft-bogdanovic-netmod-acl-model. >>>>> 1. Complete the list of authors >>>>> 2. Add grouping timerange >>>>> 3. Fix the XML example >>>>> 4. Remove some terms from "Definitions and Acronyms" which were = not >>>>> used. >>>>>=20 >>>>> thanks, >>>>> Dana >>>>>=20 >>>>>=20 >>>>> On 6/26/14 12:49 PM, "internet-drafts@ietf.org" >>>>> >>>>> wrote: >>>>>=20 >>>>>>=20 >>>>>> A new version of I-D, draft-bogdanovic-netmod-acl-model-01.txt >>>>>> has been successfully submitted by Dean Bogdanovic and posted to = the >>>>>> IETF repository. >>>>>>=20 >>>>>> Name: draft-bogdanovic-netmod-acl-model >>>>>> Revision: 01 >>>>>> Title: ACL YANG model >>>>>> Document date: 2014-06-26 >>>>>> Group: Individual Submission >>>>>> Pages: 17 >>>>>> URL: =20 >>>>>> = http://www.ietf.org/internet-drafts/draft-bogdanovic-netmod-acl-model-0 >>>>>> 1. >>>>>> t >>>>>> xt >>>>>> Status: =20 >>>>>> = https://datatracker.ietf.org/doc/draft-bogdanovic-netmod-acl-model/ >>>>>> Htmlized: =20 >>>>>> http://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-01 >>>>>> Diff: =20 >>>>>> = http://www.ietf.org/rfcdiff?url2=3Ddraft-bogdanovic-netmod-acl-model-01 >>>>>>=20 >>>>>> Abstract: >>>>>> This document describes information and data model of Access = Control >>>>>> List (ACL) basic building blocks. >>>>>>=20 >>>>>>=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 >>>>>=20 >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>> --=20 >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jul 8 14:02:12 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CB61A007B for ; Tue, 8 Jul 2014 14:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4EklJYOEZaC for ; Tue, 8 Jul 2014 14:02:05 -0700 (PDT) Received: from cdptpa-oedge-vip.email.rr.com (cdptpa-outbound-snat.email.rr.com [107.14.166.227]) by ietfa.amsl.com (Postfix) with ESMTP id B39121A0077 for ; Tue, 8 Jul 2014 14:02:05 -0700 (PDT) Received: from [65.190.6.125] ([65.190.6.125:34131] helo=[10.0.1.6]) by cdptpa-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 72/B9-20336-C4C5CB35; Tue, 08 Jul 2014 21:02:05 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Acee Lindem In-Reply-To: Date: Tue, 8 Jul 2014 17:02:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1C413D11-4390-4027-8635-A88D215689C5@lindem.com> To: Ladislav Lhotka X-Mailer: Apple Mail (2.1878.6) X-RR-Connecting-IP: 107.14.168.130:25 X-Cloudmark-Score: 0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/wY4r7xaTm8lQyOUKC0IajyWkEKA Cc: rtg-dir@ietf.org, netmod@ietf.org Subject: Re: [netmod] Routing Directorate Comments on draft-ietf-netmod-routing-cfg-15 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 21:02:08 -0000 Hi Lada,=20 Thanks for your responses. It seems that you will publish a new revision = that covers most of my comments. I will await that update and review. = With respect to only supporting the forwarding model where none of the = backup paths are used until all the primaries are unavailable, I will = discuss the with a few more people and get back to you.=20 Thanks, Acee=20 On Jul 8, 2014, at 6:34 AM, Ladislav Lhotka wrote: > Hi Acee, >=20 > thank you for the review, my comments are inline. >=20 > Acee Lindem writes: >=20 >> Hello, >>=20 >> I have been selected as the Routing Directorate reviewer for this = draft. The Routing Directorate seeks to review all routing or = routing-related drafts as they pass through IETF last call and IESG = review, and sometimes on special request. The purpose of the review is = to provide assistance to the Routing ADs. For more information about the = Routing Directorate, please see = http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >>=20 >> Although these comments are primarily for the use of the Routing ADs, = it would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. >>=20 >> Document: draft-ietf-netmod-routing-cfg-15 >> Reviewer: Acee Lindem >> Review Date: July 8th, 2014 >> IETF LC End Date: TBD=20 >> Intended Status: Proposed Standard=20 >>=20 >> Summary: There some issues with the model in the document that need = to be addressed prior to publication of this draft.=20 >>=20 >> Fundamental Question: Going forward, how will this YANG data model >> relate to the I2RS RIB information model proposed in >> draft-ietf-i2rs-rib-info-model-03.txt? >=20 > After IETF 87, the relevant parts of two models were compared, and = this > resulted in several changes and additions in the NETMOD model. Since > then, the I2RS model underwent some changes but the only parameter = that > needs to be included in the NETMOD model is route-preference. Other > parameters such as ENABLE_IP_RPF_CHECK or nexthop chains can be added > later via augmentation. >=20 > On the other hand, one of the results of the alignment with I2RS RIB > info model, was the addition of the "id" key to every single route. In > the discussion with I2RS folks, I raised objections against this = unique > "id" because it could mean considerable bookkeeping for a RIB = containing > ~200K routes, but we eventually agreed to add it to the NETMOD > model. Later, several people repeated my concerns, and I think this = "id" > should be removed from the NETMOD model. =20 >=20 >>=20 >> Major Issues: =20 >>=20 >> Section 4 & 5.4: These sections appear to restrict a routing >> protocol instance to exactly one RIB for each address family >> that the routing protocol instance supports. RFC 4915, et al, >> support a single routing protocol instance which may populate >> multiple RIBs per address family. >=20 > This issue was brought up in a recent discussion with people working = on > data models for OSPF and ISIS, and the rough consensus is that this > restriction should be lifted. By default, routes from a routing = protocol > instance will be installed in all connected RIBs of the corresponding > address family (subject to operator-defined route filters), but data > models for particular protocols can state other rules how connected = RIBs > are populated, e.g. using MT-ID. =20 >=20 >>=20 >> Section 7: What are the backup next-hops? I guess these are >> IP-FRR next-hops that are installed by the same source protocol >> as the primaries? If so, do you have to restrict the forwarding >> paradigm to not use any backup next-hops as long as primary >> next-hops are accessible? This would imply that forwarding >> plane would need to do a fast rehash of the primaries and only >> use after all primaries are expired. There are other lower >> overhead forwarding paradigms in use. >=20 > In this case we only followed suit of the I2RS RIB info model, see > sections 2.4.2 and 7.2.4 (protection lists) in > draft-ietf-i2rs-rib-info-model-03. >=20 >>=20 >> Missing: There is no concept of administrative distance (Cisco, >> et al) or route preference (gated and Juniper). In my opinion, >> this is very important since it determine which route is active >> when the same route is available from multiple protocols. >=20 > Yes, route-preference will be added, see above. >=20 >>=20 >> Missing: How does one get the best route for a given protocol >> (which is not necessarily the active route)? Should each >> protocol have a local RIB as part of its model? I notice that >> this is not included in the RIP example in Appendix C. Would >> that need to be part of the run state for the protocol? >=20 > Yes, data models for each routing protocol should include necessary > protocol-internal data structures as state data - for example BGP RIB = or > link-state database. >=20 >>=20 >> Minor issues:=20 >>=20 >> Section 9: Should there be checking to assure the router >> advertisement mtu does not exceed the ipv6 MTU from RFC 7277? >=20 >=20 > Yes, the description of the "link-mtu" leaf should mention this > constraint. It cannot be done using the "must" statement though = because > the "ip:mtu" leaf is optional and the ietf-ip module defines no = default > for it (the default depends on interface type). >=20 >>=20 >>=20 >> Questions: >> I guess the list routing protocol instances is independent in >> routing-protocols is independent of definition of the routing >> protocol itself? Or, would it be expected that the YANG model >> for the routing protocol itself would be here? If the former, >> wouldn=92t this configuration be better grouped with the = routing >> protocol themselves? >=20 > I am not sure I understand the question but data models for individual > routing protocols will be defined in separate YANG modules and will > augment the "routing-protocol" list, both in configuration and state > data. So, configuration parameters for a routing protocol will > eventually appear under "routing-protocol" but will be defined > separately. >=20 >>=20 >> In section 9, the placement of the router advertisement >> configuration seems rather arbitrary and I would have expected >> it to be grouped with the other interface configuration in RFC >> 7277. I guess placement here is the consensus of the netmod WG. >=20 > The advertisements should be sent only by routers, so I think it is > appropriate to have it as a part of router interfaces' config and = state > data. Quite often (even at IETF meetings) we can see misconfigured = hosts > sending these advertisements. >=20 > Thanks, Lada >=20 >>=20 >>=20 >> Thanks, >> Acee=20 >>=20 >>=20 >=20 > --=20 > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C From nobody Tue Jul 8 18:28:21 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E381A01E8; Tue, 8 Jul 2014 18:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_91=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6U2Jd5AeAQnb; Tue, 8 Jul 2014 18:28:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67EC01A01E5; Tue, 8 Jul 2014 18:28:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJT65169; Wed, 09 Jul 2014 01:27:58 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 9 Jul 2014 02:27:55 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Wed, 9 Jul 2014 09:27:52 +0800 From: Qin Wu To: "Tissa Senevirathne (tsenevir)" , "time@ietf.org" Thread-Topic: YANG models for OAM Thread-Index: Ac+E3qlMyPi638vnRGmjYh75Wx+edAATLCxAA6JRP1ABuzlT8AAF7c9QABY9lIA= Date: Wed, 9 Jul 2014 01:27:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA8458087Dnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/lpQ49Ph_yKDEE3nM_ge2mexGZCM Cc: "l2vpn@ietf.org" , "netmod@ietf.org" , "'sfc@ietf.org'" , "nvo3@ietf.org" , "trill@ietf.org" , "opsawg@ietf.org" Subject: Re: [netmod] YANG models for OAM X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 01:28:11 -0000 --_000_B8F9A780D330094D99AF023C5877DABA8458087Dnkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIFRpc3NhOg0KSSBkb26hr3QgdGhpbmsgdGhlIGlkZWEgeW91IHByb3Bvc2VkIGhhdmUgYW55 IGluY29uc2lzdGVuY3kgd2l0aCB3aGF0IHdlIGFyZSBwcm9wb3NpbmcgaW4gZHJhZnQtd3ctb3Bz YXdnLW11bHRpLWxheWVyLW9hbS0wMi4gQnV0IGxvb2tzIGxpa2Ugd2UgYXJlIGRlYmF0aW5nIHNv bWV0aGluZyw6KQ0KWW91IGFuZCB1cyBhcmUgYm90aCBsb29raW5nIGZvciBPQU0gY29uc29saWRh dGlvbiBpbiB0aGUgbWFuYWdlbWVudCwgaW4gYWRkaXRpb24sIHdlIGFyZSBsb29raW5nIGZvciBP QU0gY29uc29saWRhdGlvbiBpbiB0aGUgZGF0YSBwbGFuZS4NClBsZWFzZSBzZWUgbXkgcmVwbHkg aW5saW5lIGJlbG93Lg0KDQpSZWdhcmRzIQ0KLVFpbg0Kt6K8/sjLOiBUaXNzYSBTZW5ldmlyYXRo bmUgKHRzZW5ldmlyKSBbbWFpbHRvOnRzZW5ldmlyQGNpc2NvLmNvbV0NCreiy83KsbzkOiAyMDE0 xOo31MI4yNUgMjI6NDgNCsrVvP7IyzogUWluIFd1OyB0aW1lQGlldGYub3JnDQqzrcvNOiBuZXRt b2RAaWV0Zi5vcmc7IG52bzNAaWV0Zi5vcmc7IHRyaWxsQGlldGYub3JnOyBsMnZwbkBpZXRmLm9y Zzsgb3BzYXdnQGlldGYub3JnDQrW98ziOiBSRTogWUFORyBtb2RlbHMgZm9yIE9BTQ0KDQpIaSBR aW4NCg0KTWF5IGJlIGEgcG9pbnQgaXMgbWlzc2VkIGhlcmUuDQoNCg0KMS4gICAgICAgVGhvdWdo dCBTRkMgY2FuIGdvIHVwIGFuZCBkb3duIG9uIGxheWVycywgd2hhdCBjb250cm9scyB0aGF0IGJl aGF2aW9yID8gSXOhr250IGl0IHRoZSBTZXJ2aWNlIGhlYWRlciA/DQpbUWluXTogSXQgaXMgcG9z c2libGUsIGJ1dCB3aG8gY29udHJvbCB0aGF0IGJlaGF2aW9yLCBpdCBpcyB0aGUgbWFuYWdlbWVu dCBwbGFuZSwgdGhlIG1hbmFnZW1lbnQgcGxhbmUgbmVlZCB0byBpbnRlcmFjdCB3aXRoIGRpZmZl cmVudCBsYXllciBPQU0gaW4gdGhlIGRhdGEgcGxhbmUgb3INCk1hbmFnZW1lbnQgcGxhbmUgbmVl ZCB0byBpbnRlcmFjdCB3aXRoIE9BTSBwcm90b2NvbCB0aGF0IGlzIGRlZmluZWQgZm9yIFNGQyBh dCB0aGUgdG9wIG9mIGxheWVyIDMuDQoNCg0KMi4gICAgICAgSXMgdGhlIE9BTSBjb21lcyBkb3du IHRvIGZhdWx0IGlzb2xhdGlvbiwgdmVyaWZpY2F0aW9uICwgbW9uaXRvcmluZyBldGMgZm9yIHRo ZSBzcGVjaWZpZWQgU0ggPw0KW1Fpbl06IE5vdCBjbGVhciB3aGV0aGVyIFNIIGlzIHRoZSBvbmx5 IGFwcHJvYWNoLiBPQU0gaW5mb3JtYXRpb24gY2FuIGJlIHB1dCBpbnRvIEJERiBwcm90b2NvbCBv ciBHZW5lcmljIFRMViBhcyB3ZWxsLg0KDQpMaWtlIGRpc2N1c3NlZCBiZWZvcmUgKG1hbnkgdGlt ZXMpIGV4YWN0IGVuLWNhcCBpcyBsZXNzIGltcG9ydGFudCB3aGF0IGlzIGltcG9ydGFudCBpcyB0 byBoYXZlIGEgbW9kZWwgdGhhdCBkZWZpbmUgT0FNIGZyYW1ld29yayBhbmQgc2NvcGUuIENGTSB0 byBteSBvcGluaW9uIGRvIGFuIGV4Y2VsbGVudCBqb2IgaW4gZGVmaW5pbmcgd2hhdCBpcyBuZWVk ZWQuIEhlbmNlIHRoZSBjaG9pY2Ugb2YgYSBzaW1pbGFyIG1vZGVsIGZvciB0aGUgWUFORyBNb2Rl bC4NCg0KW1Fpbl06IFdlIGFyZSBvbiB0aGUgc2FtZSBwYWdlLCBidXQgaXNuoa90IG1vcmUgc3Ry YWlnaHRmb3J3YXJkIGFuZCByZWFzb25hYmxlIHRvIGRlZmluZSBHZW5lcmljIE9BTSBmcmFtZXdv cmsgc2VwYXJhdGVkIGZyb20gWWFuZyBEYXRhIG1vZGVsIGZvciBHZW5lcmljIE9BTS4NClRoYXSh r3Mgd2hhdCB3ZSBsaWtlIHRvIHByb3Bvc2UgaW4gdGhlIGRyYWZ0LXd3LW9wc2F3Zy1tdWx0aS1s YXllci1vYW0tMDIuIERldmVsb3Bpbmcgc2VwYXJhdGUgQXJjaGl0ZWN0dXJlIGFuZCBGcmFtZXdv cmsgZnJvbSBUcmFuc3BvcnQgSW5kZXBlbmRlbnQgT0FNIFByb2JsZW0gc3RhdGVtZW50IGRyYWZ0 Lg0KR2VuZXJpYyBPQU0gZnJhbWV3b3JrIHNob3VsZCBhbHNvIGFsbG93IG1vcmUgaW50ZXJhY3Rp b24gYmV0d2VlbiBkYXRhIHBsYW5lIGFuZCBtYW5hZ2VtZW50IHBsYW5lIGFuZCBtb3JlIGludGVy d29ya2luZyBiZXR3ZWVuIGRpZmZlcmVudCBsYXllciBPQU0gcHJvdG9jb2wuDQoNCllvdSBoYXZl IG5vdGVkIEJGRCBhbmQgQ0ZNIGFyZSBzaW1pbGFyIGJlY2F1c2UgdGhleSBoYXZlIHNpbWlsYXIg c2V0IG9mIHRpbWVycy4gVGhhdCBpcyBhIHdyb25nIGNvbXBhcmlzb24uIEhhdmUgc2ltaWxhciBz ZXQgb2YgdGltZXJzIGRvZXMgbm90IG1ha2UgdHdvIHByb3RvY29scyB0aGUgc2FtZS4NCg0KW1Fp bl06IFRoYXShr3Mgbm90IHdoYXQgd2UgYXJlIHByb3Bvc2luZywgd2UgaG9wZSBpbiB0aGUgbWFu YWdlbWVudCBwbGFuZSB0aGVyZSBpcyBzb21lIGNvbW1vbiBjb21wb25lbnRzIG9yIGVsZW1lbnRz IHRoYXQgY2FuIGJlIHVzZWQgYnkgbm90IG9ubHkgQkZELCBidXQgYWxzbyBDRk0uDQoNCldoYXQg bWFrZXMgdGhlbSBpcyB3aGF0IGZyYW1ld29yayB0aGV5IGZvbGxvd3MuICBXZSBoYXZlIHVzZWQg a2V5IHdvcmQgQ0ZNIGhlcmUgbG9vc2VseS4gVGhvdWdoIHdlIGJvcnJvdyBsb3RzIG9mIGNvbmNl cHRzIGZvcm0gQ0ZNIHRoZXJlIGFyZSB0aGluZ3MgdGhhdCBuZWVkZWQgdG8gYmUgcmV2aXNpdGVk Lg0KDQpJIGhhdmUgcmVxdWVzdGVkIHByZXNlbnRhdGlvbiBzbG90cyBpbiBudm8zIGFuZCBORVRN T0Qgd29ya2luZyBncm91cHMgYW5kIHdpbGwgYmUgZ29pbmcgdGhyb3VnaCBpbiBkZXRhaWxzIGhv dyBlYWNoIG9uZSBvZiB0aGUgdGVjaG5vbG9naWVzIG1hcCB0byBZQU5HIG1vZGVsIHByZXNlbnRl ZCBoZXJlLg0KDQpbUWluXTogVGhhdCB3b3VsZCBiZSBhIHZlcnkgZ29vZCBzdXJ2ZXksIGluIG15 IG9waW5pb24sIGJlZm9yZSBnb2luZyB0aGVyZSwgaXNuoa90IG1vcmUgbmljZSB0byBoYXZlIGEg Z2FwIGFuYWx5c2lzIGRvY3VtZW50IHRvDQphIC5JZGVudGlmeSB0ZWNobm9sb2d5IGRlcGVuZGVu dCBhbmQgaW5kZXBlbmRlbnQgY29tcG9uZW50DQpiLiAgYW5hbHl6ZSBhbmQgdW5kZXJzdGFuZCB0 aGUgZGlmZmVyZW50IG1vdGl2YXRpb25zIGFuZCBvcHBvcnR1bml0aWVzIGZvciBvcHRpbWlzYXRp b24gb2YgT0FNIGluIGRpZmZlcmVudCB0ZWNobm9sb2d5IG5ldHdvcmtzLA0KYW5kIHRoZSB0cmFk ZS1vZmZzIGJldHdlZW4gdGhvc2Ugb3B0aW1pc2F0aW9ucyBhbmQgdGhlIG92ZXJhbGwgYWR2YW50 YWdlIG9mIGEgZ2VuZXJpYyBPQU0gbWVjaGFuaXNtLg0KDQpGcm9tOiBRaW4gV3UgW21haWx0bzpi aWxsLnd1QGh1YXdlaS5jb21dDQpTZW50OiBUdWVzZGF5LCBKdWx5IDA4LCAyMDE0IDU6MDcgQU0N ClRvOiBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKTsgdGltZUBpZXRmLm9yZzxtYWlsdG86 dGltZUBpZXRmLm9yZz4NCkNjOiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9y Zz47IG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+OyB0cmlsbEBpZXRmLm9yZzxt YWlsdG86dHJpbGxAaWV0Zi5vcmc+OyBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5v cmc+OyBvcHNhd2dAaWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz4NClN1YmplY3Q6IFJF OiBZQU5HIG1vZGVscyBmb3IgT0FNDQoNCkhpLCBUaXNzYToNClRoZXJlIGFyZSBtYW55IG9wdGlv bnMgZm9yIFNGQyBPQU0sIEJGRCBleHRlbnNpb24sIEdlbmVyaWMgSGVhZGVyIGV4dGVuc2lvbiwg R2VuZXJpYyBUTFYgZXh0ZW5zaW9uLg0KVW5saWtlIG90aGVyIGV4aXN0aW5nIE9BTSBwcm90b2Nv bHMsIG1lY2hhbmlzbXMgYW5kIHRvb2xzLCBTRkMgbmVlZCB0byBhZGRyZXNzIE9BTSBmb3IgdGhl IHRlY2hub2xvZ3kgdGhhdCBpcyBhYm92ZSBsYXllciAzLg0KU0ZDIGhhdmVuoa90IGRldmVsb3Bl ZCBPQU0gcHJvdG9jb2wgeWV0IGF0IHRoZSB0b3Agb2YgbGF5ZXIgMy4NCg0KQmVmb3JlIHRoZXkg ZGV2ZWxvcGluZyBPQU0gcHJvdG9jb2wsIHRoZXkgbmVlZCB0byBmaWd1cmUgb3V0IHdoZXRoZXIg dGhleSBuZWVkIHRvIGRldmVsb3AgdGVjaG5vbG9neSBkZXBlbmRlbnQgT0FNIHByb3RvY29sLA0K T3IgdGVjaG5vbG9neSBpbmRlcGVuZGVudCBPQU0gcHJvdG9jb2wgc2luY2UgU0ZDIE9BTSBhbmQg T3ZlcmxheSBPQU0gc2hhcmUgYSBsb3Qgb2Ygc2ltaWxhcml0aWVzKGUuZy4sIGJvdGggY2FuIHVz ZSBvdmVybGF5IHRlY2hub2xvZ3kgdG8gc3RpdGNoIGEgc2V0IG9mIG92ZXJsYXkgbm9kZSBvciBz ZXJ2aWNlIG5vZGUgdG8gZm9ybSB0aGUgZW5kIHRvIGVuZCBwYXRoKS4gV2h5IG5vdCBidWlsZCBv bmUgcHJvdG9jb2wgdG8gc3VwcG9ydCBib3RoPw0KDQpUaGF0oa9zIHdoeSB3ZSBicmluZyB1cCB0 cmFuc3BvcnQgaW5kZXBlbmRlbnQgT0FNIGNvdmVyaW5nIHZhcmlvdXMgaGV0ZXJvZ2VuZW91cyBu ZXR3b3JrIHRlY2hub2xvZ2llcyBhbmQgcHJvcG9zZSB0byBjb25zb2xpZGF0ZSBPQU0gaW4gYm90 aA0KTWFuYWdlbWVudCBwbGFuZSBhbmQgZGF0YSBwbGFuZS4NCmh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXd3LW9wc2F3Zy1tdWx0aS1sYXllci1vYW0tMDINCmh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWtpbmctb3BzYXdnLXRpbWUtbXVsdGktbGF5ZXItb2FtLXVzZS1j YXNlLTAxLnR4dA0KDQpSZWdhcmRpbmcgZmxvdy1lbnRyb3B5LCB3aHkgbm90IHJldXNlIGVudHJv cHkgbWVjaGFuaXNtcyBpbiB0aGUgZXhpc3RpbmcgdW5kZXJseWluZyB0cmFuc3BvcnQuIEhvdyBp cyBmbG93IGVudHJvcHkgZGlmZmVyZW50IGZyb20gRUNNUCBjaG9pY2UgeW91IHByb3Bvc2VkIGlu IHRoZSBkcmFmdC4NCklmIG15IHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdCwgSUVFRSA4MDIuMWFn IG9ubHkgc3VwcG9ydCBFcXVhbCBDb3N0IFRyZWUgKEVDVCkgbWVjaGFuaXNtIGluc3RlYWQgb2Yg RUNNUCwgSUVFRTgwMi4xUWJwIHN1cHBvcnQgRUNNUCwNCkFyZSB5b3UgcHJvcG9zaW5nIHRvIGNv bWJpbmUgRUNUIHN1cHBvcnRlZCBieSBJRUVFIDgwMi4xYWcgd2l0aCBFQ01QIHN1cHBvcnRlZCBi eSBJRUVFIDgwMi4xUWJwIGFuZCB1c2UgdGhlbSB0b2dldGhlciBhdCB0aGUgc2FtZSB0aW1lIGlu IHRoZSBzYW1lIG5ldHdvcms/DQoNCkFsc28gQkZEIGFuZCBJRUVFIDgwMi4xYWcgQ0ZNIHNoYXJl IGEgbG90IG9mIGNvbW1vbmFsaXR5LCBlLmcuLCBDQ00taW50ZXJ2YWwsIEJGRCBpbnRlcnZhbC4g SWYgd2UgaW50ZWdyYXRlIHRoZW0gdG9nZXRoZXIsIHdlIHJlYWxseSBuZWVkIHRvIHRoaW5rIGFi b3V0IGhvdyB0byBpbnRlZ3JhdGUgdGhlbSB0b2dldGhlciBpbiB0aGUgbWFuYWdlbWVudCBwbGFu ZS4gSXMgdGhlcmUgYW55IGNvbW1vbiBjb21wb25lbnQgd2UgY2FuIGRlZmluZSBmb3IgYm90aD8g SG93IHdlIGRlZmluZSB0aGVzZSBjb21wb25lbnQgYW5kIG1ha2UgdGhlbSBtb3JlIGV4dGVuc2li bGUuDQoNClJlZ2FyZHMhDQotUWluDQq3orz+yMs6IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2 aXIpIFttYWlsdG86dHNlbmV2aXJAY2lzY28uY29tXQ0Kt6LLzcqxvOQ6IDIwMTTE6jbUwjMwyNUg MDoyMA0KytW8/sjLOiBRaW4gV3U7IHRpbWVAaWV0Zi5vcmc8bWFpbHRvOnRpbWVAaWV0Zi5vcmc+ DQqzrcvNOiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz47IG52bzNAaWV0 Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+OyB0cmlsbEBpZXRmLm9yZzxtYWlsdG86dHJpbGxA aWV0Zi5vcmc+OyBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+OyBvcHNhd2dA aWV0Zi5vcmc8bWFpbHRvOm9wc2F3Z0BpZXRmLm9yZz4NCtb3zOI6IFJFOiBZQU5HIG1vZGVscyBm b3IgT0FNDQoNCkhpIFFpbg0KDQpUaGVyZSBhcmUgc2V2ZXJhbCB3YXkgdGhpcyBpcyBhcHBsaWNh YmxlIHRvIFNGQw0KDQoNCjEuICAgICAgIFNGQyBpcyB1bmRlcmxheWVyIGluZGVwZW5kZW50ICwg d2hpY2ggbWVhbnMgaXQgY2FuIGhhdmUgYWxsIHNvcnRzIG9mIGVuY2FwIHR5cGVzIHVuZGVybmVh dGgsIHRoZSBtb2RlbCBwcmVzZW50ZWQgaW4gdGlzc2EtbmV0bW9kLW9hbSwgYWRkcmVzcyBleGFj dGx5IHRoYXQgaXNzdWUuIEluc3RlYWQgb2YgcmUtaW52ZW50aW5nIGFuZCByZS1pbXBsZW1lbnRp bmcgdmFyaW91cyBkaWZmZXJlbnQgT0FNIHRoZSBkcmFmdCBwcm9wb3NlIHRvIGludGVncmF0ZSB0 aGVtIGF0IHRoZSBtYW5hZ2VtZW50IGxheWVyLg0KDQoyLiAgICAgICBJbiB0aGlzIGRyYWZ0IHdl IGRlZmluZSBhIGZsb3ctZW50cm9weSBhcyBhbiBvcGFxdWUgZWxlbWVudCB0aGF0IGVhY2ggb2Yg dGhlIHRlY2hub2xvZ3kgdHlwZSBjYW4gc3BlY2lmeSBhbmQgaW5jbHVkZS4gSWYgd2UgbG9vayBh dCBkcmFmdC1xdWlubi1zZmMtbnNoLTAyLnR4dCwgaXQgZGVmaW5lIGEgYmxvY2sgdGhhdCBzcGVj aWZpZXMgU0ZDLiBTRkMgdmVyc2lvbiBvZiBZQU5HICBjYW4gc3BlY2lmeSB0aGlzIGFzIHBhcnQg b2YgaXRzIGZsb3cgZW50cm9weS4gVGhlIGJlYXV0eSBpcyB0aGF0IGl0IGlzIGFsbCB1cCB0byB0 aGUgdGVjaG5vbG9neSB0byBzcGVjaWZ5IHRoYXQgKHNpemUgYW5kIHNoYXBlIGlzIHRlY2hub2xv Z3kgZGVwZW5kZW50KSBhbmQgYmFzZSBtb2RlbCBpcyBzdGlsbCBpbnRhY3QuDQoNCldpdGggdGhl IGFib3ZlIGluIG1pbmQgLCBjYW4geW91IHBsZWFzZSByZXZpZXcgZHJhZnQtdGlzc2EtbmV0bW9k LW9hbSBhbmQgc2VlIGl0IGlzIGZsZXhpYmxlIGFuZCBleHRlbnNpYmxlIGVub3VnaCB0byBmb3Ig dGhlIHB1cnBvc2UuIElmIHRoaW5ncyBhcmUgbWlzc2luZyB3ZSBjYW4gYWRkIGFuZCBleHRlbmQu DQoNCkkgaGF2ZSByZXF1ZXN0ZWQgbmV0bW9kIFdHIGNoYWlycyBmb3IgYSBwcmVzZW50YXRpb24g c2xvdCBmb3IgZnVydGhlciBkaXNjdXNzaW9uIG9mIHRoZSBkcmFmdC4NCg0KRnJvbTogUWluIFd1 IFttYWlsdG86YmlsbC53dUBodWF3ZWkuY29tXQ0KU2VudDogVHVlc2RheSwgSnVuZSAxMCwgMjAx NCA5OjIyIFBNDQpUbzogVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZpcik7IHRpbWVAaWV0Zi5v cmc8bWFpbHRvOnRpbWVAaWV0Zi5vcmc+DQpDYzogbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRt b2RAaWV0Zi5vcmc+OyBudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPjsgdHJpbGxA aWV0Zi5vcmc8bWFpbHRvOnRyaWxsQGlldGYub3JnPjsgbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwy dnBuQGlldGYub3JnPjsgb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSRTogWUFORyBtb2RlbHMgZm9yIE9BTQ0KDQpIaSwgVGlzc2E6DQpUaGFua3MgZm9y IGluaXRpYXRpbmcgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGljLg0KVW5pZmllZCBPQU0gZm9yIG11 bHRpLUxheWVyIG5ldHdvcmsgaXMgYSBnb29kIGlkZWEgdG8gbWUuDQpkcmFmdC13dy1vcHNhd2ct bXVsdGktbGF5ZXItb2FtLTAwIHdlIHByb3Bvc2VkIGluIG9wc2F3ZyBsYWlkIG91dCB0aGUgYW4g aW5pdGlhbCBkZXNjcmlwdGlvbiBvZiB0aGUgcHJvYmxlbS4NClRoZSBxdWVzdGlvbiB0byBkcmFm dC10aXNzYS1uZXRtb2Qtb2FtIGlzDQpJIGFtIHdvbmRlcmluZyBob3cgdGhpcyBnZW5lcmljIFlh bmcgTW9kZWwgY2FuIGJlIGFwcGxpZWQgdG8gU0ZDIGVudmlyb25tZW50Pw0KSG93IGRvIHlvdSBz dXBwb3J0IHRoZSBjYXNlIHdoZXJlIHR3byBlbmRwb2ludHMgc3VwcG9ydCBkaWZmZXJlbnQgbGF5 ZXIgT0FNIG9yIGRvZXNuoa90IHN1cHBvcnQgYW55IE9BTSBhdCB0aGF0IGxheWVyLg0KDQpCVFc6 IEkgaGF2ZSBjY6GvZWQgdGltZSBtYWlsaW5nIGxpc3Qgc2luY2UgSSBiZWxpZXZlIHRoaXMgbWFp bGluZyBsaXN0IGlzIHB1cnBvc2VkIHRvIGxvb2sgZm9yIGdlbmVyaWMgYW5kIGludGVncmF0ZWQg T0FNIGNvdmVyaW5nIHZhcmlvdXMgaGV0ZXJvZ2VuZW91cyBuZXR3b3JraW5nIHRlY2hub2xvZ2ll cy4NClJlZ2FyZHMhDQotUWluDQq3orz+yMs6IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2Vz QGlldGYub3JnXSC0+rHtIFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpDQq3osvNyrG85Dog MjAxNMTqNtTCMTHI1SAzOjAzDQrK1bz+yMs6IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9k QGlldGYub3JnPjsgbnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz47IHRyaWxsQGll dGYub3JnPG1haWx0bzp0cmlsbEBpZXRmLm9yZz47IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZw bkBpZXRmLm9yZz47IG9wc2F3Z0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPg0K1vfM 4jogW25ldG1vZF0gWUFORyBtb2RlbHMgZm9yIE9BTQ0KDQpBbGwNCg0KV2UgaGF2ZSBwdWJsaXNo ZWQgWUFORyBtb2RlbCBmb3IgT0FNLiAjMSBkcmFmdCBiZWxvdyBwbGFjZSB0aGUgZ2VuZXJpYyBm cmFtZXdvcmsgZm9yIE9BTSwgdGhhdCBjYW4gYmUgYXVnbWVudGVkIGZvciBkaWZmZXJlbnQgdGVj aG5vbG9naWVzLiAjMiBhbmQgIzMgYXJlIGFwcGxpY2F0aW9uIG9mIHRoZSBjb25jZXB0IHRvIE5W TzMgYW5kIFRSSUxMLA0KDQoNCjEuICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtdGlzc2EtbmV0bW9kLW9hbS8NCg0KMi4gICAgICAgaHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC10aXNzYS1udm8zLXlhbmctb2FtLw0KDQozLiAgICAgICBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRpc3NhLXRyaWxsLXlhbmctb2FtLw0K DQpQbGVhc2UgcmV2aWV3IGFuZCBzaGFyZSB5b3VyIGNvbW1lbnRzDQoNClRoYW5rcw0KVGlzc2EN Cg0KDQo= --_000_B8F9A780D330094D99AF023C5877DABA8458087Dnkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Tissa:

I don=A1=AFt think the idea you proposed have any inconsistency w= ith what we are proposing in draft-ww-opsawg-multi-layer-oam-02. But looks = like we are debating something,J

You and us are both looking for OAM consolidation in the manageme= nt, in addition, we are looking for OAM consolidation in the data plane.

Please see my reply inline below.

 

Regards!

-Qin

=B7=A2=BC=FE=C8=CB: Tissa S= enevirathne (tsenevir) [mailto:tsenevir@cisco.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA7=D4=C28=C8=D5 22:48
=CA=D5=BC=FE=C8=CB: Qin Wu; time@ietf.org
=B3=AD=CB=CD: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; opsawg@ie= tf.org
=D6=F7=CC=E2: RE: YANG models for OAM

 

Hi Qin<= o:p>

&n= bsp;

May be = a point is missed here.

&n= bsp;

= 1.       Thought SFC can go up and down on layers, what controls that behavior ? Is= =A1=AFnt it the Service header ?

[Qin]: It is possible, but who control that behavior, it is the m= anagement plane, the management plane need to interact with different layer= OAM in the data plane or

Management plane need to interact with OAM protocol that is defin= ed for SFC at the top of layer 3.

 

= 2.       Is the OAM comes down to fault isolation, verification , monitoring etc fo= r the specified SH ?

[Qin]: = Not clear whether SH is the only approach. OAM information can be put into = BDF protocol or Generic TLV as well.

 

Like di= scussed before (many times) exact en-cap is less important what is importan= t is to have a model that define OAM framework and scope. CFM to my opinion= do an excellent job in defining what is needed. Hence the choice of a similar model for the YANG Model.

 

[Qin]: We are on the same page, but isn=A1=AFt more straightforwa= rd and reasonable to define Generic OAM framework separated from Yang Data = model for Generic OAM.

That=A1=AFs what we like to propose in the draft-ww-opsawg-multi-= layer-oam-02. Developing separate Architecture and Framework from Transport= Independent OAM Problem statement draft.

Generic OAM framework should also allow more interaction between = data plane and management plane and more interworking between different lay= er OAM protocol.

&n= bsp;

You hav= e noted BFD and CFM are similar because they have similar set of timers. Th= at is a wrong comparison. Have similar set of timers does not make two prot= ocols the same.

 

[Qin]: That=A1=AFs not what we are proposing, we hope in the mana= gement plane there is some common components or elements that can be used b= y not only BFD, but also CFM.

 

What ma= kes them is what framework they follows.  We have used key word CFM he= re loosely. Though we borrow lots of concepts form CFM there are things tha= t needed to be revisited.

&n= bsp;

I have = requested presentation slots in nvo3 and NETMOD working groups and will be = going through in details how each one of the technologies map to YANG model= presented here.

 

[Qin]: That would be a very good survey, in my opinion, before go= ing there, isn=A1=AFt more nice to have a gap analysis document to

a .Identify technology dependent and independent component

b.  analyze and understand the different motivations and opp= ortunities for optimisation of OAM in different technology networks,

and the trade-offs between those optimisations and the overall ad= vantage of a generic OAM mechanism.

&n= bsp;

From: Qin Wu [mailto:= bill.wu@huawei.com]
Sent: Tuesday, July 08, 2014 5:07 AM
To: Tissa Senevirathne (tsenevir); = time@ietf.org
Cc: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; opsawg@ietf.org<= br> Subject: RE: YANG models for OAM

 

Hi, Tissa:

There are many options for SFC OAM, BFD extension, Generic Header= extension, Generic TLV extension.

Unlike other existing OAM protocols, mechanisms and tools, SFC ne= ed to address OAM for the technology that is above layer 3.

SFC haven=A1=AFt developed OAM protocol yet at the top of layer 3= .

 

Before they developing OAM protocol, they need to figure out whet= her they need to develop technology dependent OAM protocol,

Or technology independent OAM protocol since SFC OAM and Overlay = OAM share a lot of similarities(e.g., both can use overlay technology to st= itch a set of overlay node or service node to form the end to end path). Why not build one protocol to support b= oth?

 

That=A1=AFs why we bring up transport independent OAM covering va= rious heterogeneous network technologies and propose to consolidate OAM in = both

Management plane and data plane.

http://tools.ietf.org/html/draft= -ww-opsawg-multi-layer-oam-02

http://tools= .ietf.org/html/draft-king-opsawg-time-multi-layer-oam-use-case-01.txt

 

Regarding flow-entropy, why not reuse entropy mechanisms in the e= xisting underlying transport. How is flow entropy different from ECMP choic= e you proposed in the draft.

If my understanding is correct, IEEE 802.1ag only support Equal C= ost Tree (ECT) mechanism instead of ECMP, IEEE802.1Qbp support ECMP,

Are you proposing to combine ECT supported by IEEE 802.1ag with E= CMP supported by IEEE 802.1Qbp and use them together at the same time in th= e same network?

 

Also BFD and IEEE 802.1ag CFM share a lot of commonality, e.g., C= CM-interval, BFD interval. If we integrate them together, we really need to= think about how to integrate them together in the management plane. Is there any common component we can define for b= oth? How we define these component and make them more extensible.

 

Regards!

-Qin

=B7=A2=BC=FE=C8=CB: Tissa S= enevirathne (tsenevir) [mailto:tsenev= ir@cisco.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C230=C8=D5 0:20
=CA=D5=BC=FE=C8=CB: Qin Wu; time@ietf.org
=B3=AD=CB=CD: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; <= a href=3D"mailto:opsawg@ietf.org"> opsawg@ietf.org
=D6=F7=CC=E2: RE: YANG models for OAM

 

Hi Qin<= o:p>

&n= bsp;

There a= re several way this is applicable to SFC

&n= bsp;

= 1.       SFC is underlayer independent , which means it can have all sorts of encap= types underneath, the model presented in tissa-netmod-oam, address exactly= that issue. Instead of re-inventing and re-implementing various different OAM the draft propose to integrate t= hem at the management layer.

= 2.       In this draft we define a flow-entropy as an opaque element that each of t= he technology type can specify and include. If we look at draft-quinn-sfc-n= sh-02.txt, it define a block that specifies SFC. SFC version of YANG  can specify this as part of its flow entrop= y. The beauty is that it is all up to the technology to specify that (size = and shape is technology dependent) and base model is still intact.

&n= bsp;

With th= e above in mind , can you please review draft-tissa-netmod-oam and see it i= s flexible and extensible enough to for the purpose. If things are missing = we can add and extend.

&n= bsp;

I have = requested netmod WG chairs for a presentation slot for further discussion o= f the draft.  

&n= bsp;

From: Qin Wu [mailto:= bill.wu@huawei.com]
Sent: Tuesday, June 10, 2014 9:22 PM
To: Tissa Senevirathne (tsenevir); = time@ietf.org
Cc: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; opsawg@ietf.org<= br> Subject: RE: YANG models for OAM

 

Hi, Tissa:

Thanks for initiating discussion on this topic.=

Unified OAM for multi-Layer network is a good idea to me.

draft-ww-opsawg-multi-layer-oam-00 we proposed in opsawg laid out= the an initial description of the problem.

The question to draft-= tissa-netmod-oam is

I am wondering how this generic Yang Model can be applied to SFC = environment?

How do you support the case where two endpoints support different= layer OAM or doesn=A1=AFt support any OAM at that layer.=

 

BTW: I have cc=A1=AFed time mailing list since I believe this mai= ling list is purposed to look for generic and integrated OAM covering vario= us heterogeneous networking technologies.

Regards!

-Qin

=B7=A2=BC=FE=C8=CB: netmod = [mailto:netmod-bounces@ietf.org<= /a>] =B4=FA= =B1=ED Tissa Senevirathne (tsenevir)
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA6=D4=C211=C8=D5 3:03
=CA=D5=BC=FE=C8=CB: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; <= a href=3D"mailto:opsawg@ietf.org"> opsawg@ietf.org
=D6=F7=CC=E2: [netmod] YANG models for OAM

 

All

 

We have published YANG model fo= r OAM. #1 draft below place the generic framework for OAM, that can be augm= ented for different technologies. #2 and #3 are application of the concept = to NVO3 and TRILL,

 

1. &nbs= p;     http://datatracker.ietf.org/do= c/draft-tissa-netmod-oam/

2. &nbs= p;     http://datatracker.ietf.org= /doc/draft-tissa-nvo3-yang-oam/

3. &nbs= p;     http://datatracker.ietf.or= g/doc/draft-tissa-trill-yang-oam/

 

Please review and share your co= mments

 

Thanks

Tissa

 

 

--_000_B8F9A780D330094D99AF023C5877DABA8458087Dnkgeml501mbschi_-- From nobody Tue Jul 8 23:13:17 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987D61A0353 for ; Tue, 8 Jul 2014 23:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEB-fnyrf3kM for ; Tue, 8 Jul 2014 23:13:12 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E141D1A0358 for ; Tue, 8 Jul 2014 23:13:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 510CB540726; Wed, 9 Jul 2014 08:13:09 +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 GdYP+wjRew3f; Wed, 9 Jul 2014 08:13:03 +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 9A6155403EC; Wed, 9 Jul 2014 08:13:02 +0200 (CEST) From: Ladislav Lhotka To: Acee Lindem In-Reply-To: References: <1C413D11-4390-4027-8635-A88D215689C5@lindem.com> User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Wed, 09 Jul 2014 08:13:01 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yczCFNXHwEYSkwTOHEwdF9omj0M Cc: netmod@ietf.org Subject: Re: [netmod] Routing Directorate Comments on draft-ietf-netmod-routing-cfg-15 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 06:13:15 -0000 Acee Lindem writes: > Hi Lada, Thanks for your responses. It seems that you will publish a > new revision that covers most of my comments.I will await that update Yes. Thanks, Lada > and review. With respect to only supporting the forwarding model where > none of the backup paths are used until all the primaries are > unavailable, I will discuss the with a few more people and get back to > you. Thanks, Acee > > On Jul 8, 2014, at 6:34 AM, Ladislav Lhotka wrote: > >> Hi Acee, >>=20 >> thank you for the review, my comments are inline. >>=20 >> Acee Lindem writes: >>=20 >>> Hello, >>>=20 >>> I have been selected as the Routing Directorate reviewer for this draft= . The Routing Directorate seeks to review all routing or routing-related dr= afts as they pass through IETF last call and IESG review, and sometimes on = special request. The purpose of the review is to provide assistance to the = Routing ADs. For more information about the Routing Directorate, please see= http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >>>=20 >>> Although these comments are primarily for the use of the Routing ADs, i= t would be helpful if you could consider them along with any other IETF Las= t Call comments that you receive, and strive to resolve them through discus= sion or by updating the draft. >>>=20 >>> Document: draft-ietf-netmod-routing-cfg-15 >>> Reviewer: Acee Lindem >>> Review Date: July 8th, 2014 >>> IETF LC End Date: TBD=20 >>> Intended Status: Proposed Standard=20 >>>=20 >>> Summary: There some issues with the model in the document that need to = be addressed prior to publication of this draft.=20 >>>=20 >>> Fundamental Question: Going forward, how will this YANG data model >>> relate to the I2RS RIB information model proposed in >>> draft-ietf-i2rs-rib-info-model-03.txt? >>=20 >> After IETF 87, the relevant parts of two models were compared, and this >> resulted in several changes and additions in the NETMOD model. Since >> then, the I2RS model underwent some changes but the only parameter that >> needs to be included in the NETMOD model is route-preference. Other >> parameters such as ENABLE_IP_RPF_CHECK or nexthop chains can be added >> later via augmentation. >>=20 >> On the other hand, one of the results of the alignment with I2RS RIB >> info model, was the addition of the "id" key to every single route. In >> the discussion with I2RS folks, I raised objections against this unique >> "id" because it could mean considerable bookkeeping for a RIB containing >> ~200K routes, but we eventually agreed to add it to the NETMOD >> model. Later, several people repeated my concerns, and I think this "id" >> should be removed from the NETMOD model.=20=20=20 >>=20 >>>=20 >>> Major Issues:=20=20 >>>=20 >>> Section 4 & 5.4: These sections appear to restrict a routing >>> protocol instance to exactly one RIB for each address family >>> that the routing protocol instance supports. RFC 4915, et al, >>> support a single routing protocol instance which may populate >>> multiple RIBs per address family. >>=20 >> This issue was brought up in a recent discussion with people working on >> data models for OSPF and ISIS, and the rough consensus is that this >> restriction should be lifted. By default, routes from a routing protocol >> instance will be installed in all connected RIBs of the corresponding >> address family (subject to operator-defined route filters), but data >> models for particular protocols can state other rules how connected RIBs >> are populated, e.g. using MT-ID.=20=20=20=20 >>=20 >>>=20 >>> Section 7: What are the backup next-hops? I guess these are >>> IP-FRR next-hops that are installed by the same source protocol >>> as the primaries? If so, do you have to restrict the forwarding >>> paradigm to not use any backup next-hops as long as primary >>> next-hops are accessible? This would imply that forwarding >>> plane would need to do a fast rehash of the primaries and only >>> use after all primaries are expired. There are other lower >>> overhead forwarding paradigms in use. >>=20 >> In this case we only followed suit of the I2RS RIB info model, see >> sections 2.4.2 and 7.2.4 (protection lists) in >> draft-ietf-i2rs-rib-info-model-03. >>=20 >>>=20 >>> Missing: There is no concept of administrative distance (Cisco, >>> et al) or route preference (gated and Juniper). In my opinion, >>> this is very important since it determine which route is active >>> when the same route is available from multiple protocols. >>=20 >> Yes, route-preference will be added, see above. >>=20 >>>=20 >>> Missing: How does one get the best route for a given protocol >>> (which is not necessarily the active route)? Should each >>> protocol have a local RIB as part of its model? I notice that >>> this is not included in the RIP example in Appendix C. Would >>> that need to be part of the run state for the protocol? >>=20 >> Yes, data models for each routing protocol should include necessary >> protocol-internal data structures as state data - for example BGP RIB or >> link-state database. >>=20 >>>=20 >>> Minor issues:=20 >>>=20 >>> Section 9: Should there be checking to assure the router >>> advertisement mtu does not exceed the ipv6 MTU from RFC 7277? >>=20 >>=20 >> Yes, the description of the "link-mtu" leaf should mention this >> constraint. It cannot be done using the "must" statement though because >> the "ip:mtu" leaf is optional and the ietf-ip module defines no default >> for it (the default depends on interface type). >>=20 >>>=20 >>>=20 >>> Questions: >>> I guess the list routing protocol instances is independent in >>> routing-protocols is independent of definition of the routing >>> protocol itself? Or, would it be expected that the YANG model >>> for the routing protocol itself would be here? If the former, >>> wouldn=E2=80=99t this configuration be better grouped with the r= outing >>> protocol themselves? >>=20 >> I am not sure I understand the question but data models for individual >> routing protocols will be defined in separate YANG modules and will >> augment the "routing-protocol" list, both in configuration and state >> data. So, configuration parameters for a routing protocol will >> eventually appear under "routing-protocol" but will be defined >> separately. >>=20 >>>=20 >>> In section 9, the placement of the router advertisement >>> configuration seems rather arbitrary and I would have expected >>> it to be grouped with the other interface configuration in RFC >>> 7277. I guess placement here is the consensus of the netmod WG. >>=20 >> The advertisements should be sent only by routers, so I think it is >> appropriate to have it as a part of router interfaces' config and state >> data. Quite often (even at IETF meetings) we can see misconfigured hosts >> sending these advertisements. >>=20 >> Thanks, Lada >>=20 >>>=20 >>>=20 >>> Thanks, >>> Acee=20 >>>=20 >>>=20 >>=20 >> --=20 >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C > --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 9 02:14:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE251A01DD; Wed, 9 Jul 2014 02:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.901 X-Spam-Level: X-Spam-Status: No, score=-92.901 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_92=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UubMbSycsZBW; Wed, 9 Jul 2014 02:14:06 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id CAB7A1A0012; Wed, 9 Jul 2014 02:14:05 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 97388127CAD5; Wed, 9 Jul 2014 17:13:51 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s699DqTT000587; Wed, 9 Jul 2014 17:13:52 +0800 (GMT-8) (envelope-from dai.xianxian@zte.com.cn) In-Reply-To: <381D7D55085B1E4D8B581BD652E1E14058C5B646@nkgeml504-mbx.china.huawei.com> References: <381D7D55085B1E4D8B581BD652E1E14058C5B646@nkgeml504-mbx.china.huawei.com> To: Zhengguangying MIME-Version: 1.0 X-KeepSent: 2BD912D9:DA4F85FD-48257D10:00328126; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: dai.xianxian@zte.com.cn Date: Wed, 9 Jul 2014 17:13:48 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-07-09 17:13:48, Serialize complete at 2014-07-09 17:13:48 Content-Type: multipart/alternative; boundary="=_alternative 003245C948257D10_=" X-MAIL: mse01.zte.com.cn s699DqTT000587 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/nsXx-IP6OPzwMMN1TAjEx_IUmFI Cc: netmod , "netmod@ietf.org" , Yangang Subject: [netmod] =?gb2312?b?tPC4tDogIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp?= =?gb2312?b?b24gZm9yIGRyYWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3JhdGUtb3BlcmF0aW9u?= =?gb2312?b?cy0wMC50eHQ=?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 09:14:08 -0000 This is a multipart message in MIME format. --=_alternative 003245C948257D10_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 IEhpIFpoZW5nZ3Vhbmd5aW5nLA0KDQogICAgICAgIEFmdGVyIHJlYWRpbmcgdGhlIGRyYWZ0LCBJ IGhhdmUgc29tZSBkb3VidHMsY2FuIHlvdSBhbnN3ZXIgdGhlbT8NCg0KICAgICAgICAxLkluIG15 IG9waW5pb24sIG1ldGhvZCBkZWZpbmVzIG1ldGhvZCByYXRoZXIgdGhhbiBkYXRhLklmIHRoZSAN CnNhbXBsZSBzdWNjZWVkcywgdXNlciBnZXRzICJhcnBMaXN0IiBkYXRhIGJ5IDxnZXQtY29uZmln PiBvcGVyYXRpb24sIA0KICAgICAgICB0aGUgcmVzcG9uZGluZyBtZXNzYWdlIGRpc3BsYXkgYm90 aCB0aGUgc3RhdGljIGRhdGEgYW5kIHRoZSBuZXcgDQpkYXRhKGR5bmFtaWMgZGF0YSkuSXMgaXQg cmlnaHQ/IERvZXMgaXQgbmVlZCB0byBjb21taXQ/DQogICAgICAgIEFmdGVyIHRoYXQsaWYgdXNl ciBlZGl0cyB0aGUgbmV3ICJhcnBMaXN0IiBkYXRhIGJ5IDxlZGl0LWNvbmZpZz4gDQpvcGVyYXRp b24saXMgdGhlIGR5bmFtaWMgZGF0YSBiZSBlZGl0ZWQgYXQgdGhlIHNhbWUgdGltZT8NCiAgICAg ICAgSWYgdGhlIGR5bmFtaWMgZGF0YSBpcyBkZWxldGVkIGZvciBzb21lIHJlYXNvbiwgdGhlIG5l dyAiYXJwTGlzdCIgDQpkYXRhIHN0aWxsIGV4aXN0Pw0KDQogICAgICAgIDIuQ2FuIHlvdSBkZXNj cmliZSB0aGUgYXR0cmlidXRlIGluZm9ybWF0aW9uIG9mIHRoZSBtZXRob2Q/DQogICAgICAgIERv ZXMgdGhlIG1ldGhvZCBzdXBwb3J0ICJvdXRwdXQiIHN0YXRlbWVudD8gDQogICAgICAgIElzIHRo ZSBjb25maWcgc3RhdGVtZW50IG9mIG5vZGUgbWVhbmluZ2xlc3M/DQoNCiAgICAgICBJIHRoaW5r IGl0IGlzIGJldHRlciBhbmQgY2xlYXJlciB0byBkZWZpbmUgdGhlIG1ldGhvZCBieSB1c2luZyAN CllBTkcuIA0KDQoNCkJlc3QgcmVnYXJkcyENCg0KDQoNCg0KDQoNClpoZW5nZ3Vhbmd5aW5nIDx6 aGVuZ2d1YW5neWluZ0BodWF3ZWkuY29tPiANCreivP7IyzogICJuZXRtb2QiIDxuZXRtb2QtYm91 bmNlc0BpZXRmLm9yZz4NCjIwMTQtMDctMDQgMDg6MTMNCg0KytW8/sjLDQoibmV0bW9kQGlldGYu b3JnIiA8bmV0bW9kQGlldGYub3JnPiwgDQqzrcvNDQpZYW5nYW5nIDx5YW5nYW5nQGh1YXdlaS5j b20+DQrW98ziDQpbbmV0bW9kXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciANCmRy YWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3JhdGUtb3BlcmF0aW9ucy0wMC50eHQNCg0KDQoNCg0KDQoN CkhpIGFsbCBpbiBOZXRtb2QgLA0KDQogICAgSW4gc29tZSBkYXRhc3RvcmUgb3BlcmF0aW9uIHNj ZW5hcmlvcywgdGhlIG9wZXJhdGlvbnMgdHJpZ2dlcmVkIGZyb20gDQp0aGUgIE5FVENPTkYgY2xp ZW50IG1pZ2h0IGJlIGEgc2V0IG9mIGNvbWJpbmVkIG9wZXJhdGlvbnMgb3IgYSBjb21wbGV4IA0K c2luZ2xlIG9wZXJhdGlvbiB3aXRoaW4gdGhlIE5FVENPTkYgYWdlbnQsIHdoaWNoIG1heSBjaGFu Z2UgdGhlIA0KZGF0YXN0b3Jlcy4gQW5kICBzb21ldGltZXMgdGhlIGRhdGFzdG9yZSBjaGFuZ2Ug bWlnaHQgbm90IGJlIGZyb20gY2xpZW50IA0KYnV0IGZyb20gdGhlIGFnZW50IGl0c2VsZi4gVGhl c2Ugb3BlcmF0aW9ucyBuZWVkIHRvIG1hbmlwdWxhdGUgdGhlIGRhdGEgaW4gDQpydW5uaW5nIGRh dGFzdG9yZSBvciBjYW5kaWRhdGUgZGF0YXN0b3JlLCBhbmQgdGh1cyB0aGV5IG5lZWQgdGhlIA0K PGVkaXQtY29uZmlnPiBjYXBhYmlsaXR5IGEgd2VsbCBhcyBhIHVuaWZpZWQgYXV0aG9yaXphdGlv biBzeXN0ZW0gdG8gDQpjb250cm9sIHRoZSBpbmZsdWVuY2UgdG8gdGhlIGRhdGEgICBzdG9yZXMg Y2F1c2VkIGJ5IHRoZW0uDQogIFNvIHdlIHdyb3RlIGEgZHJhZnQgdG8gdHJ5IHRvIG1ha2UgYSAg ZGlzY3Vzc2lvbiBvZiB0aGUgaXNzdWUuIFRoZSBkcmFmdCANCmFuYWx5emVzIHRoZSBzY2VuYXJp byBhbmQgcmVxdWlybWVudHMgZm9yIG1vZGVsIG9wZXJhdGlvbnMsIGFuZCBicmllZmx5IA0KZGlz Y3VzcyBzb21lIHBvc3NpYmxlIHNvbHV0aW9ucyB0byBzYXRpc2Z5IHRoZSByZXF1aXJtZW50cy4N ClBsZWFzZSByZXZpZXcgdGhlIGRyYWZ0IGFuZCBjb21tZW50Lg0KTWFueSB0aGFua3MhDQpCZXN0 IHJlZ2FyZHMsDQpaaGVuZw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kt6K8/sjLOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW2ludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZ10NCreiy83KsbzkOiAyMDE0xOo31MIyyNUgMTc6NTQNCsrVvP7IyzogSml4aWFvZmVuZyAo U3RldmVuKTsgWmhlbmdndWFuZ3lpbmc7IEppeGlhb2ZlbmcgKFN0ZXZlbik7IA0KWmhlbmdndWFu Z3lpbmcNCtb3zOI6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQpkcmFmdC16aGVuZy1u ZXRtb2QtaW50ZWdyYXRlLW9wZXJhdGlvbnMtMDAudHh0DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC16aGVuZy1uZXRtb2QtaW50ZWdyYXRlLW9wZXJhdGlvbnMtMDAudHh0DQpoYXMgYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEd1YW5neWluZyBaaGVuZyBhbmQgcG9zdGVkIHRv IHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgZHJhZnQtemhlbmctbmV0 bW9kLWludGVncmF0ZS1vcGVyYXRpb25zDQpSZXZpc2lvbjogICAgICAgMDANClRpdGxlOiAgICAg ICAgICBJbnRlZ3JhdGluZyBPcGVyYXRpb25zIGluIFlBTkcgTW9kZWxzDQpEb2N1bWVudCBkYXRl OiAgMjAxNC0wNy0wMg0KR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFn ZXM6ICAgICAgICAgIDExDQpVUkw6ICAgICAgICAgICAgDQpodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC16aGVuZy1uZXRtb2QtaW50ZWdyYXRlLW9wZXJhdGlvbnMtMDAu dHh0DQoNClN0YXR1czogICAgICAgICANCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3JhdGUtb3BlcmF0aW9ucy8NCkh0bWxpemVkOiAgICAg ICANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3Jh dGUtb3BlcmF0aW9ucy0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBpbnRyb2R1 Y2VzIGFuIGV4dGVuc2lvbiB0byBZQU5HLiBUaGUgZXh0ZW5zaW9uIGFsbG93cw0KICAgb3BlcmF0 aW9uIG1ldGhvZHMgdG8gYmUgZGlyZWN0bHkgaW50ZWdyYXRlZCBpbiBZQU5HIG1vZGVscy4NCg0K DQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2YgDQpzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNy ZXRhcmlhdF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpu ZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBO b3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0 dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVu dGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNz ZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9z dXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9y IHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQu ICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUg aXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg== --=_alternative 003245C948257D10_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwO0hpIFpoZW5nZ3Vhbmd5aW5nLDwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IEFmdGVyDQpyZWFkaW5nIHRoZSBkcmFmdCwgSSBoYXZlIHNvbWUg ZG91YnRzLGNhbiB5b3UgYW5zd2VyIHRoZW0/PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMS5Jbg0KbXkg b3BpbmlvbiwgbWV0aG9kIGRlZmluZXMgbWV0aG9kIHJhdGhlciB0aGFuIGRhdGEuSWYgdGhlIHNh bXBsZSBzdWNjZWVkcywNCnVzZXIgZ2V0cyAmcXVvdDthcnBMaXN0JnF1b3Q7IGRhdGEgYnkgJmx0 O2dldC1jb25maWcmZ3Q7IG9wZXJhdGlvbiwgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlDQpyZXNwb25kaW5n IG1lc3NhZ2UgZGlzcGxheSBib3RoIHRoZSBzdGF0aWMgZGF0YSBhbmQgdGhlIG5ldyBkYXRhKGR5 bmFtaWMNCmRhdGEpLklzIGl0IHJpZ2h0PyBEb2VzIGl0IG5lZWQgdG8gY29tbWl0PzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IEFmdGVyDQp0aGF0LGlmIHVzZXIgZWRpdHMgdGhlIG5ldyAmcXVvdDthcnBMaXN0JnF1 b3Q7IGRhdGEgYnkgJmx0O2VkaXQtY29uZmlnJmd0Ow0Kb3BlcmF0aW9uLGlzIHRoZSBkeW5hbWlj IGRhdGEgYmUgZWRpdGVkIGF0IHRoZSBzYW1lIHRpbWU/PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSWYNCnRoZSBk eW5hbWljIGRhdGEgaXMgZGVsZXRlZCBmb3Igc29tZSByZWFzb24sIHRoZSBuZXcgJnF1b3Q7YXJw TGlzdCZxdW90Ow0KZGF0YSBzdGlsbCBleGlzdD88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAyLkNhbg0K eW91IGRlc2NyaWJlIHRoZSBhdHRyaWJ1dGUgaW5mb3JtYXRpb24gb2YgdGhlIG1ldGhvZD88L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBEb2VzDQp0aGUgbWV0aG9kIHN1cHBvcnQgJnF1b3Q7b3V0cHV0JnF1b3Q7IHN0 YXRlbWVudD8gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSXMNCnRoZSBjb25maWcgc3RhdGVtZW50IG9mIG5vZGUg bWVhbmluZ2xlc3M/PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJIHRoaW5rIGl0DQppcyBiZXR0ZXIgYW5k IGNsZWFyZXIgdG8gZGVmaW5lIHRoZSBtZXRob2QgYnkgdXNpbmcgWUFORy4gPGJyPg0KPGJyPg0K PGJyPg0KQmVzdCByZWdhcmRzITxicj4NCjxicj4NCjxicj4NCjwvZm9udD4NCjxicj4NCjxicj4N Cjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzYl Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5aaGVuZ2d1YW5neWluZyAmbHQ7emhl bmdndWFuZ3lpbmdAaHVhd2VpLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7JnF1b3Q7bmV0bW9kJnF1b3Q7DQombHQ7 bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPjIwMTQtMDctMDQgMDg6MTM8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRh YmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7bmV0bW9kQGlldGYub3JnJnF1b3Q7 ICZsdDtuZXRtb2RAaWV0Zi5vcmcmZ3Q7LA0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5ZYW5nYW5nICZs dDt5YW5nYW5nQGh1YXdlaS5jb20mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8 ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250 PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bbmV0bW9kXSBGVzog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uDQpmb3IgZHJhZnQtemhlbmctbmV0bW9kLWludGVncmF0 ZS1vcGVyYXRpb25zLTAwLnR4dDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPkhpIGFsbCBpbiBOZXRtb2QgLDxicj4NCjxi cj4NCiAmbmJzcDsgJm5ic3A7SW4gc29tZSBkYXRhc3RvcmUgb3BlcmF0aW9uIHNjZW5hcmlvcywg dGhlIG9wZXJhdGlvbnMgdHJpZ2dlcmVkDQpmcm9tIHRoZSAmbmJzcDtORVRDT05GIGNsaWVudCBt aWdodCBiZSBhIHNldCBvZiBjb21iaW5lZCBvcGVyYXRpb25zIG9yDQphIGNvbXBsZXggc2luZ2xl IG9wZXJhdGlvbiB3aXRoaW4gdGhlIE5FVENPTkYgYWdlbnQsIHdoaWNoIG1heSBjaGFuZ2UgdGhl DQpkYXRhc3RvcmVzLiBBbmQgJm5ic3A7c29tZXRpbWVzIHRoZSBkYXRhc3RvcmUgY2hhbmdlIG1p Z2h0IG5vdCBiZSBmcm9tDQpjbGllbnQgYnV0IGZyb20gdGhlIGFnZW50IGl0c2VsZi4gVGhlc2Ug b3BlcmF0aW9ucyBuZWVkIHRvIG1hbmlwdWxhdGUgdGhlDQpkYXRhIGluIHJ1bm5pbmcgZGF0YXN0 b3JlIG9yIGNhbmRpZGF0ZSBkYXRhc3RvcmUsIGFuZCB0aHVzIHRoZXkgbmVlZCB0aGUNCiZsdDtl ZGl0LWNvbmZpZyZndDsgY2FwYWJpbGl0eSBhIHdlbGwgYXMgYSB1bmlmaWVkIGF1dGhvcml6YXRp b24gc3lzdGVtDQp0byBjb250cm9sIHRoZSBpbmZsdWVuY2UgdG8gdGhlIGRhdGEgJm5ic3A7IHN0 b3JlcyBjYXVzZWQgYnkgdGhlbS48YnI+DQogJm5ic3A7U28gd2Ugd3JvdGUgYSBkcmFmdCB0byB0 cnkgdG8gbWFrZSBhICZuYnNwO2Rpc2N1c3Npb24gb2YgdGhlIGlzc3VlLg0KVGhlIGRyYWZ0IGFu YWx5emVzIHRoZSBzY2VuYXJpbyBhbmQgcmVxdWlybWVudHMgZm9yIG1vZGVsIG9wZXJhdGlvbnMs IGFuZA0KYnJpZWZseSBkaXNjdXNzIHNvbWUgcG9zc2libGUgc29sdXRpb25zIHRvIHNhdGlzZnkg dGhlIHJlcXVpcm1lbnRzLjxicj4NClBsZWFzZSByZXZpZXcgdGhlIGRyYWZ0IGFuZCBjb21tZW50 Ljxicj4NCk1hbnkgdGhhbmtzITxicj4NCkJlc3QgcmVnYXJkcyw8YnI+DQpaaGVuZzxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQq3orz+yMs6IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyBbaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXTxicj4NCreiy83K sbzkOiAyMDE0xOo31MIyyNUgMTc6NTQ8YnI+DQrK1bz+yMs6IEppeGlhb2ZlbmcgKFN0ZXZlbik7 IFpoZW5nZ3Vhbmd5aW5nOyBKaXhpYW9mZW5nIChTdGV2ZW4pOyBaaGVuZ2d1YW5neWluZzxicj4N Ctb3zOI6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtemhlbmctbmV0bW9kLWlu dGVncmF0ZS1vcGVyYXRpb25zLTAwLnR4dDxicj4NCjxicj4NCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC16aGVuZy1uZXRtb2QtaW50ZWdyYXRlLW9wZXJhdGlvbnMtMDAudHh0PGJyPg0KaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBHdWFuZ3lpbmcgWmhlbmcgYW5kIHBvc3Rl ZCB0byB0aGU8YnI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkcmFmdC16aGVuZy1uZXRtb2QtaW50ZWdyYXRlLW9w ZXJhdGlvbnM8YnI+DQpSZXZpc2lvbjogJm5ic3A7ICZuYnNwOyAmbmJzcDsgMDA8YnI+DQpUaXRs ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0ludGVncmF0aW5nIE9wZXJhdGlv bnMgaW4gWUFORw0KTW9kZWxzPGJyPg0KRG9jdW1lbnQgZGF0ZTogJm5ic3A7MjAxNC0wNy0wMjxi cj4NCkdyb3VwOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW5kaXZpZHVhbCBT dWJtaXNzaW9uPGJyPg0KUGFnZXM6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsx MTxicj4NClVSTDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L2Zv bnQ+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtemhl bmctbmV0bW9kLWludGVncmF0ZS1vcGVyYXRpb25zLTAwLnR4dCIgdGFyZ2V0PV9ibGFuaz48Zm9u dCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1Pmh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3JhdGUtb3BlcmF0aW9ucy0w MC50eHQ8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48YnI+DQpTdGF0 dXM6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L2ZvbnQ+PGEgaHJlZj0iaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhlbmctbmV0bW9kLWludGVncmF0ZS1vcGVy YXRpb25zLyIgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhv bWEiPjx1Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpoZW5nLW5ldG1v ZC1pbnRlZ3JhdGUtb3BlcmF0aW9ucy88L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0i VGFob21hIj48YnI+DQpIdG1saXplZDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgPC9mb250PjxhIGhy ZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3Jh dGUtb3BlcmF0aW9ucy0wMCIgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBm YWNlPSJUYWhvbWEiPjx1Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoZW5nLW5l dG1vZC1pbnRlZ3JhdGUtb3BlcmF0aW9ucy0wMDwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBm YWNlPSJUYWhvbWEiPjxicj4NCjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiAmbmJzcDsgVGhp cyBkb2N1bWVudCBpbnRyb2R1Y2VzIGFuIGV4dGVuc2lvbiB0byBZQU5HLiBUaGUgZXh0ZW5zaW9u IGFsbG93czxicj4NCiAmbmJzcDsgb3BlcmF0aW9uIG1ldGhvZHMgdG8gYmUgZGlyZWN0bHkgaW50 ZWdyYXRlZCBpbiBZQU5HIG1vZGVscy48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZiBzdWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNy ZXRhcmlhdDwvZm9udD48dHQ+PGZvbnQgc2l6ZT0yPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCm5ldG1v ZEBpZXRmLm9yZzxicj4NCjwvZm9udD48L3R0PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRtb2Q+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6 ZT0yPjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0KDQo8YnI+PHByZT48Zm9udCBjb2xvcj0iYmx1 ZSI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNv bnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJl d2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3Ig dGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFu IGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJp YnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0 ZWx5Lg0KDQo8L2ZvbnQ+PC9wcmU+PGJyPg0K --=_alternative 003245C948257D10_=-- From nobody Wed Jul 9 03:28:39 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4AC41A03E6 for ; Wed, 9 Jul 2014 03:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6md1VtqebX8g for ; Wed, 9 Jul 2014 03:28:34 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 898F61A03DA for ; Wed, 9 Jul 2014 03:28:34 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 51F671107 for ; Wed, 9 Jul 2014 12:28:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id bBNl4AK0kiCK for ; Wed, 9 Jul 2014 12:28:21 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 9 Jul 2014 12:28:32 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D571A2002C for ; Wed, 9 Jul 2014 12:28:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0vmACQrTusju; Wed, 9 Jul 2014 12:28:32 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DAFF420017; Wed, 9 Jul 2014 12:28:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0A4732DD399B; Wed, 9 Jul 2014 12:28:30 +0200 (CEST) Date: Wed, 9 Jul 2014 12:28:30 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140709102830.GA86928@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/i15w7x4T4zAhDIicgeGwklYUVrs Subject: [netmod] virtual interim meeting reminder X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jul 2014 10:28:39 -0000 Hi, this is a short reminder that we have a virtual interim meeting later today (4pm-6pm central european time zone). You will find the webex details here: http://www.ietf.org/mail-archive/web/ietf-announce/current/msg12811.html /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jul 9 07:11:17 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF0A1A0AA1 for ; Wed, 9 Jul 2014 07:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.852 X-Spam-Level: X-Spam-Status: No, score=-12.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJHJktPNVuVI for ; Wed, 9 Jul 2014 07:11:06 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 275A01A0A9E for ; Wed, 9 Jul 2014 07:11:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4772; q=dns/txt; s=iport; t=1404915069; x=1406124669; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=MYmDIvnkdyaeOPuq6Fwrbr2aCqQqD5wR4936wsDI6XQ=; b=hEalRSDx59ySmaLpxhwpAsbZu7km6H+N3lZKbO5b2iqmTEGsfvgvWjiL VsjyYqqK7RG5ZDEPVpYKNAMJqqLxe4q5wzCfPRPQOgTQ/AOgCCMSpvmIp RJQ1M3WNzfqtYZXGLMRt9pD4vcsATC+1jVD69HVpAVmZgYz9BCJscDJ6n Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8IAAhNvVOtJV2Z/2dsb2JhbABZgw5SUwe/FAiGblMBgQ8WdYQDAQEBBAEBAWsJAhIBCBhVCyUCBA4FCYg5CAXIZRePDzMHhEMFmnaBSJJEggGBQoIw X-IronPort-AV: E=Sophos;i="5.01,631,1400025600"; d="scan'208";a="59453512" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP; 09 Jul 2014 14:11:08 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s69EB5xp030623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jul 2014 14:11:05 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.47]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Wed, 9 Jul 2014 09:11:04 -0500 From: "Dana Blair (dblair)" To: Dean Bogdanovic Thread-Topic: [netmod] New Version Notification for draft-bogdanovic-netmod-acl-model-01.txt Thread-Index: AQHPmslCJ8m/7hHLbEyUnz1SXiwoFpuX2wyA Date: Wed, 9 Jul 2014 14:11:04 +0000 Message-ID: In-Reply-To: <4E32A3D9-ABBD-4C70-99B9-F89F37A2D317@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.21.92.213] Content-Type: text/plain; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/K01-oJ3Tg7pmBsk5F4yrxQ_1cfU Cc: "netmod@ietf.org" Subject: Re: [netmod] New Version Notification for draft-bogdanovic-netmod-acl-model-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 14:11:14 -0000 On 7/8/14 12:25 PM, "Dean Bogdanovic" wrote: >Dana, > >The route filters have the same structure as firewall filters. There can >be multiple ACEs in one ACL. Each ACE has match condition followed by >action. > >example for Juniper > >policy-statement hosts-only { > term1 { > from { > route-filter 10.0.0.0/16 upto /31 reject; > } > then accept; > } >} > >So we can use the same containers match and action, but have to add new >ace-type route-filter in the match container. See which match statements >are common between vendors and which would go into vendor specific module. OK. Makes sense. So the next step is to a yang augmentation which defines the route-filter. thanks, Dana > >Dean > >On Jul 8, 2014, at 11:50 AM, Dana Blair (dblair) wrote: > >> Can you provide a route filters example ? We'll take a look. >>=20 >> Dana >>=20 >> On 7/8/14 11:26 AM, "Ladislav Lhotka" wrote: >>=20 >>> Hi, >>>=20 >>> I think a data model for route filters will be badly needed before >>>long, >>> and since route filters are based on the same ACL model, perhaps it >>> would be useful to generalize this draft to include route filters as >>> well. >>>=20 >>> Lada >>>=20 >>> "Lisa Huang (yihuan)" writes: >>>=20 >>>> The document contains a base ACL model that could be flexibly extended >>>> or >>>> adapted by different vendors. It is with cross-company support. We >>>>will >>>> be >>>> presenting this work at the netmod WG meeting. >>>>=20 >>>> We wish to acknowledge the helpful contributions, comments, and >>>> suggestions from Alex Clem and Andy Bierman on ACL model, who also >>>> co-authored draft-huang-netmod-acl. >>>>=20 >>>> Thanks, >>>>=20 >>>> Lisa >>>>=20 >>>> On 6/26/14 11:54 AM, "Dana Blair (dblair)" wrote: >>>>=20 >>>>> FYI and comments =A9 >>>>>=20 >>>>> Here is an initial draft proposal for a YANG model for an Access >>>>>Control >>>>> List. >>>>>=20 >>>>>=20 >>>>> I need to clarify Cisco's position on this proposal for an Access >>>>> Control >>>>> List yang model since >>>>> there was an expired draft, draft-huang-netmod-acl-03.txt, which had >>>>> Cisco >>>>> authorship. >>>>>=20 >>>>> Cisco's position is to support this new draft, >>>>> draft-bogdanovic-netmod-acl-model-01.txt, >>>>> and not support the expired draft, draft-huang-netmod-acl-03.txt. >>>>>=20 >>>>> Changes from version 00 to 01 of draft-bogdanovic-netmod-acl-model. >>>>> 1. Complete the list of authors >>>>> 2. Add grouping timerange >>>>> 3. Fix the XML example >>>>> 4. Remove some terms from "Definitions and Acronyms" which were not >>>>> used. >>>>>=20 >>>>> thanks, >>>>> Dana >>>>>=20 >>>>>=20 >>>>> On 6/26/14 12:49 PM, "internet-drafts@ietf.org" >>>>> >>>>> wrote: >>>>>=20 >>>>>>=20 >>>>>> A new version of I-D, draft-bogdanovic-netmod-acl-model-01.txt >>>>>> has been successfully submitted by Dean Bogdanovic and posted to the >>>>>> IETF repository. >>>>>>=20 >>>>>> Name: draft-bogdanovic-netmod-acl-model >>>>>> Revision: 01 >>>>>> Title: ACL YANG model >>>>>> Document date: 2014-06-26 >>>>>> Group: Individual Submission >>>>>> Pages: 17 >>>>>> URL: =20 >>>>>>=20 >>>>>>http://www.ietf.org/internet-drafts/draft-bogdanovic-netmod-acl-model >>>>>>-0 >>>>>> 1. >>>>>> t >>>>>> xt >>>>>> Status: =20 >>>>>> https://datatracker.ietf.org/doc/draft-bogdanovic-netmod-acl-model/ >>>>>> Htmlized: =20 >>>>>> http://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-01 >>>>>> Diff: =20 >>>>>>=20 >>>>>>http://www.ietf.org/rfcdiff?url2=3Ddraft-bogdanovic-netmod-acl-model-= 01 >>>>>>=20 >>>>>> Abstract: >>>>>> This document describes information and data model of Access >>>>>>Control >>>>>> List (ACL) basic building blocks. >>>>>>=20 >>>>>>=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 >>>>>=20 >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>> --=20 >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > From nobody Wed Jul 9 18:47:42 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96CB11A0126; Wed, 9 Jul 2014 18:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x94eTwe7luX9; Wed, 9 Jul 2014 18:47:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A7BF1A010C; Wed, 9 Jul 2014 18:47:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJU63353; Thu, 10 Jul 2014 01:47:35 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Jul 2014 02:47:34 +0100 Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.247]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 10 Jul 2014 09:47:25 +0800 From: Zhengguangying To: "i2rs@ietf.org" , "netmod@ietf.org" Thread-Topic: One draft to discuss YANG resource-specific methods, please review the draft and comment, thanks Thread-Index: Ac+bKHuW63GrXPwWRbahm67F7UBljg== Date: Thu, 10 Jul 2014 01:47:24 +0000 Message-ID: <381D7D55085B1E4D8B581BD652E1E14058C5BF0C@nkgeml504-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.33.139] Content-Type: multipart/alternative; boundary="_000_381D7D55085B1E4D8B581BD652E1E14058C5BF0Cnkgeml504mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/CNAUAXtGNefuf85OTL2-DhxddBQ Cc: Yangang Subject: [netmod] One draft to discuss YANG resource-specific methods, please review the draft and comment, thanks X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 01:47:38 -0000 --_000_381D7D55085B1E4D8B581BD652E1E14058C5BF0Cnkgeml504mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIGFsbCBJMlJTIGFuZCBuZXRtb2QNCg0KDQoNCiAgICAgSW4gbGFzdCBJMlJTIG1lZXRpbmcg aW4gTG9uZG9uLCBJbiBNci4gQW5keSBCaWVybWFuJ3MgdG9waWMgb2YgIkdhcCBBbmFseXNpcyBv ZiBZQU5HIGZvciBJMlJTIiwgd2UgZGljdXNzZWQgb25lIGlzc3VlIHRoYXQgIFlBTkcgZG9lcyBu b3QgaGF2ZSByZXNvdXJjZS1zcGVjaWZpYyBub3RpZmljYXRpb25zIGFuZCBtZXRob2RzLg0KDQoN Cg0KICAgICBOb3csIEkgIHdyb3RlIGEgZHJhZnQgdG8gdHJ5IHRvIG1ha2UgYSBjb21wcmVoZW5z aXZlIGRpc2N1c3Npb24gb2YgdGhpcyB1c2UtY2FzZS4gVGhlIGRyYWZ0IGFuYWx5emVzIHNvbWUg cmVhbCBzY2VuYXJpb3MgYW5kIHJlcXVpcmVtZW50cyBmb3Igb2JqZWN0IG1ldGhvZHMuIEF0IGxh c3QsIHRoZSBkcmFmdCBicmllZmx5IGRpc2N1c3Mgc29tZSBwb3NzaWJsZSBzb2x1dGlvbnMgdG8g c2F0aXNmeSB0aGUgcmVxdWlybWVudHMuDQoNCg0KDQogICAgIFBsZWFzZSByZXZpZXcgdGhlIGRy YWZ0IGFuZCBjb21tZW50Lg0KDQoNCg0KICAgIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtemhlbmctbmV0bW9kLWludGVncmF0ZS1vcGVyYXRpb25zLTAwLnR4dA0KDQoNCj4+QSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3JhdGUtb3BlcmF0aW9u cy0wMC50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBHdWFuZ3lpbmcgWmhl bmcgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQo+Pk5hbWU6ICAgICAgICAg ICBkcmFmdC16aGVuZy1uZXRtb2QtaW50ZWdyYXRlLW9wZXJhdGlvbnMNCj4+UmV2aXNpb246ICAg ICAgIDAwDQo+PlRpdGxlOiAgICAgICAgICBJbnRlZ3JhdGluZyBPcGVyYXRpb25zIGluIFlBTkcg TW9kZWxzDQo+PkRvY3VtZW50IGRhdGU6ICAyMDE0LTA3LTAyDQo+Pkdyb3VwOiAgICAgICAgICBJ bmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4+UGFnZXM6ICAgICAgICAgIDExDQo+PlVSTDogICAgICAg ICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16aGVuZy1uZXRt b2QtaW50ZWdyYXRlLW9wZXJhdGlvbnMtMDAudHh0DQo+PlN0YXR1czogICAgICAgICBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGVuZy1uZXRtb2QtaW50ZWdyYXRlLW9w ZXJhdGlvbnMvDQo+Pkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC16aGVuZy1uZXRtb2QtaW50ZWdyYXRlLW9wZXJhdGlvbnMtMDANCg0KPj5BYnN0cmFjdDoN CiAgID4+VGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIGFuIGV4dGVuc2lvbiB0byBZQU5HLiBUaGUg ZXh0ZW5zaW9uIGFsbG93cw0KICAgPj5vcGVyYXRpb24gbWV0aG9kcyB0byBiZSBkaXJlY3RseSBp bnRlZ3JhdGVkIGluIFlBTkcgbW9kZWxzLg0KDQpSZWdhcmRzJnRoYW5rcyENCg0KDQoNClpoZW5n DQoNCg0K --_000_381D7D55085B1E4D8B581BD652E1E14058C5BF0Cnkgeml504mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, all I2RS and netmod

 

     In last I2RS meeting in London, In Mr. Andy Bie= rman's topic of "Gap Analysis of YANG for I2RS", we dicussed one = issue that  YANG does not have resource-specific notifications and met= hods.

 

     Now, I  wrote a draft to try to make a com= prehensive discussion of this use-case. The draft analyzes some real scenar= ios and requirements for object methods. At last, the draft briefly discuss= some possible solutions to satisfy the requirments.

 

     Please review the draft and comment.

 

    New Version Notification for draft-zheng-netmod-integ= rate-operations-00.txt

>>A new version of I-D, draft-zheng-netmod-integrate-operations-00= .txt has been successfully submitted by Guangying Zheng and posted to the I= ETF repository.

>>Name:           d= raft-zheng-netmod-integrate-operations
>>Revision:       00
>>Title:          Integr= ating Operations in YANG Models
>>Document date:  2014-07-02
>>Group:          Indivi= dual Submission
>>Pages:          11
>>URL:          &nb= sp; http://www.ietf.org/internet-drafts/draft-zheng-netmod-integrate-operations= -00.txt
>>Status:         https://datatracker.ietf.org/doc/draft-zheng-netmod-integrate-operations/
>>Htmlized:       http://tools.ietf.org/html/draft-zheng-netmod-integrate-operations-00
>>Abstract:
   >>This document introduces an extension to YANG. The ext= ension allows
   >>operation methods to be directly integrated in YANG mo= dels.


Regards&thanks!

 

Zheng

 

--_000_381D7D55085B1E4D8B581BD652E1E14058C5BF0Cnkgeml504mbxchi_-- From nobody Wed Jul 9 23:10:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540EC1B2797; Wed, 9 Jul 2014 23:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.299 X-Spam-Level: **** X-Spam-Status: No, score=4.299 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_92=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htX1gGp9SsMU; Wed, 9 Jul 2014 23:10:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F25B51B2795; Wed, 9 Jul 2014 23:10:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGY93839; Thu, 10 Jul 2014 06:10:26 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Jul 2014 07:10:24 +0100 Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.247]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Thu, 10 Jul 2014 14:10:14 +0800 From: Zhengguangying To: "dai.xianxian@zte.com.cn" Thread-Topic: [netmod] FW: New Version Notification for draft-zheng-netmod-integrate-operations-00.txt Thread-Index: Ac+XHNnmXAm3bbW4QPyICK0DJdqxpwD9i9oAADyXRic= Date: Thu, 10 Jul 2014 06:10:13 +0000 Message-ID: <381D7D55085B1E4D8B581BD652E1E14058C5BF3B@nkgeml504-mbx.china.huawei.com> References: <381D7D55085B1E4D8B581BD652E1E14058C5B646@nkgeml504-mbx.china.huawei.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.33.139] Content-Type: multipart/alternative; boundary="_000_381D7D55085B1E4D8B581BD652E1E14058C5BF3Bnkgeml504mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/tVwudkvpS8Pns3XzLSXVnt1Epv8 Cc: netmod , "netmod@ietf.org" , Yangang Subject: [netmod] =?gb2312?b?tPC4tDogIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp?= =?gb2312?b?b24gZm9yIGRyYWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3JhdGUtb3BlcmF0aW9u?= =?gb2312?b?cy0wMC50eHQ=?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 06:10:31 -0000 --_000_381D7D55085B1E4D8B581BD652E1E14058C5BF3Bnkgeml504mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIERhaXhpYW54aWFuDQoNCiAgICAgICBUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMgZmly c3RseS4gSSB0cnkgdG8gYW5zd2VyIHlvdXIgY29tbWVudHMgaGVyZSwgcGxlYXNlIGNoZWNrIG15 IGRvdWJ0LCB0aGFua3MuDQoNCiAgICAgICAgPj4xLkluIG15IG9waW5pb24sIG1ldGhvZCBkZWZp bmVzIG1ldGhvZCByYXRoZXIgdGhhbiBkYXRhLklmIHRoZSBzYW1wbGUgc3VjY2VlZHMsIHVzZXIg Z2V0cyAiYXJwTGlzdCIgZGF0YSBieSA8Z2V0LWNvbmZpZz4gb3BlcmF0aW9uLA0KICAgICAgICB0 aGUgcmVzcG9uZGluZyBtZXNzYWdlIGRpc3BsYXkgYm90aCB0aGUgc3RhdGljIGRhdGEgYW5kIHRo ZSBuZXcgZGF0YShkeW5hbWljIGRhdGEpLklzIGl0IHJpZ2h0PyBEb2VzIGl0IG5lZWQgdG8gY29t bWl0Pw0KDQogICAgICAgIFpoZW5nOiBSaWdodCwgaWYgc3VjY2VlZCwgdGhlIGR5bmFtaWMgZGF0 YSB3aWxsIGJlY29tZSBjb25maWd1cmF0aW9uIGRhdGEgYW5kIGl0IHdpbGwgaW4gdGhlICA8Z2V0 LWNvbmZpZz4gUlBDIHJlcGx5IGRhdGEuDQogICAgICAgICAgICAgICBJZiBkZWZpbmUgbmV3IG5v bi1zdGFuZGFyZCBSUEMsIGRvIHlvdSB0aGluayBpdCBuZWVkIGEgc3BlcmF0ZSBjb21taXQgb3Bl cmF0aW9uIG9yIGNvbW1pdCBpdCBpbnRlcm5hbGx5IGNvbWJpbmUgd2l0aCB0aGUgbmV3IGRlZmlu ZWQgUlBDPw0KDQoNCiAgICAgICAgPj5BZnRlciB0aGF0LGlmIHVzZXIgZWRpdHMgdGhlIG5ldyAi YXJwTGlzdCIgZGF0YSBieSA8ZWRpdC1jb25maWc+IG9wZXJhdGlvbixpcyB0aGUgZHluYW1pYyBk YXRhIGJlIGVkaXRlZCBhdCB0aGUgc2FtZSB0aW1lPw0KICAgICAgICBJZiB0aGUgZHluYW1pYyBk YXRhIGlzIGRlbGV0ZWQgZm9yIHNvbWUgcmVhc29uLCB0aGUgbmV3ICJhcnBMaXN0IiBkYXRhIHN0 aWxsIGV4aXN0Pw0KICAgICAgICBaaGVuZzogQWZ0ZXIgY29udmVydCB0aGUgZHluYW1pYyBkYXRh IHRvIGNvbmZpZ3VyYXRpb24gZGF0YSwgdGhlIG9yaWduYWwgZHluYW1pYyBkYXRhIHdpbGwgYmUg ZGVsZXRlZC4NCg0KDQogICAgICAgID4+Mi5DYW4geW91IGRlc2NyaWJlIHRoZSBhdHRyaWJ1dGUg aW5mb3JtYXRpb24gb2YgdGhlIG1ldGhvZD8NCiAgICAgICAgRG9lcyB0aGUgbWV0aG9kIHN1cHBv cnQgIm91dHB1dCIgc3RhdGVtZW50Pw0KICAgICAgICBJcyB0aGUgY29uZmlnIHN0YXRlbWVudCBv ZiBub2RlIG1lYW5pbmdsZXNzPw0KICAgICAgICBaaGVuZ6O6SW4gdGhpcyB2ZXJzaW9uIGRyYWZ0 IHdlIHdhbnQgdG8gZGVzY3JpYmUgdGhlIHByb2JsZW1zIGl0c2VsZiwgYW5kIHRyeSB0byBkaXNj dXNzIGl0IGluIHRoZSBXRyBhbmQgbWFrZSBpdCBjbGVhci4gVGhlIGRldGFpbCBkZXNpZ24gd2ls bCBkZXNjcmliZSBpbiB0aGUgbmV4dCB2ZXJzaW9uLg0KDQoNCg0KUmVnYXJkcyZUaGFua3MNCg0K WmhlbmcNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogZGFpLnhp YW54aWFuQHp0ZS5jb20uY24gW2RhaS54aWFueGlhbkB6dGUuY29tLmNuXQ0Kt6LLzcqxvOQ6IDIw MTTE6jfUwjnI1SAxNzoxMw0KytW8/sjLOiBaaGVuZ2d1YW5neWluZw0Ks63LzTogbmV0bW9kQGll dGYub3JnOyBuZXRtb2Q7IFlhbmdhbmcNCtb3zOI6ILTwuLQ6IFtuZXRtb2RdIEZXOiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3JhdGUtb3BlcmF0 aW9ucy0wMC50eHQNCg0KIEhpIFpoZW5nZ3Vhbmd5aW5nLA0KDQogICAgICAgIEFmdGVyIHJlYWRp bmcgdGhlIGRyYWZ0LCBJIGhhdmUgc29tZSBkb3VidHMsY2FuIHlvdSBhbnN3ZXIgdGhlbT8NCg0K ICAgICAgICAxLkluIG15IG9waW5pb24sIG1ldGhvZCBkZWZpbmVzIG1ldGhvZCByYXRoZXIgdGhh biBkYXRhLklmIHRoZSBzYW1wbGUgc3VjY2VlZHMsIHVzZXIgZ2V0cyAiYXJwTGlzdCIgZGF0YSBi eSA8Z2V0LWNvbmZpZz4gb3BlcmF0aW9uLA0KICAgICAgICB0aGUgcmVzcG9uZGluZyBtZXNzYWdl IGRpc3BsYXkgYm90aCB0aGUgc3RhdGljIGRhdGEgYW5kIHRoZSBuZXcgZGF0YShkeW5hbWljIGRh dGEpLklzIGl0IHJpZ2h0PyBEb2VzIGl0IG5lZWQgdG8gY29tbWl0Pw0KICAgICAgICBBZnRlciB0 aGF0LGlmIHVzZXIgZWRpdHMgdGhlIG5ldyAiYXJwTGlzdCIgZGF0YSBieSA8ZWRpdC1jb25maWc+ IG9wZXJhdGlvbixpcyB0aGUgZHluYW1pYyBkYXRhIGJlIGVkaXRlZCBhdCB0aGUgc2FtZSB0aW1l Pw0KICAgICAgICBJZiB0aGUgZHluYW1pYyBkYXRhIGlzIGRlbGV0ZWQgZm9yIHNvbWUgcmVhc29u LCB0aGUgbmV3ICJhcnBMaXN0IiBkYXRhIHN0aWxsIGV4aXN0Pw0KDQogICAgICAgIDIuQ2FuIHlv dSBkZXNjcmliZSB0aGUgYXR0cmlidXRlIGluZm9ybWF0aW9uIG9mIHRoZSBtZXRob2Q/DQogICAg ICAgIERvZXMgdGhlIG1ldGhvZCBzdXBwb3J0ICJvdXRwdXQiIHN0YXRlbWVudD8NCiAgICAgICAg SXMgdGhlIGNvbmZpZyBzdGF0ZW1lbnQgb2Ygbm9kZSBtZWFuaW5nbGVzcz8NCg0KICAgICAgIEkg dGhpbmsgaXQgaXMgYmV0dGVyIGFuZCBjbGVhcmVyIHRvIGRlZmluZSB0aGUgbWV0aG9kIGJ5IHVz aW5nIFlBTkcuDQoNCg0KQmVzdCByZWdhcmRzIQ0KDQoNCg0KDQoNClpoZW5nZ3Vhbmd5aW5nIDx6 aGVuZ2d1YW5neWluZ0BodWF3ZWkuY29tPg0Kt6K8/sjLOiAgIm5ldG1vZCIgPG5ldG1vZC1ib3Vu Y2VzQGlldGYub3JnPg0KDQoyMDE0LTA3LTA0IDA4OjEzDQoNCg0KytW8/sjLDQogICAgICAgICJu ZXRtb2RAaWV0Zi5vcmciIDxuZXRtb2RAaWV0Zi5vcmc+LA0Ks63LzQ0KICAgICAgICBZYW5nYW5n IDx5YW5nYW5nQGh1YXdlaS5jb20+DQrW98ziDQogICAgICAgIFtuZXRtb2RdIEZXOiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3JhdGUtb3BlcmF0 aW9ucy0wMC50eHQNCg0KDQoNCg0KDQoNCg0KSGkgYWxsIGluIE5ldG1vZCAsDQoNCiAgIEluIHNv bWUgZGF0YXN0b3JlIG9wZXJhdGlvbiBzY2VuYXJpb3MsIHRoZSBvcGVyYXRpb25zIHRyaWdnZXJl ZCBmcm9tIHRoZSAgTkVUQ09ORiBjbGllbnQgbWlnaHQgYmUgYSBzZXQgb2YgY29tYmluZWQgb3Bl cmF0aW9ucyBvciBhIGNvbXBsZXggc2luZ2xlIG9wZXJhdGlvbiB3aXRoaW4gdGhlIE5FVENPTkYg YWdlbnQsIHdoaWNoIG1heSBjaGFuZ2UgdGhlIGRhdGFzdG9yZXMuIEFuZCAgc29tZXRpbWVzIHRo ZSBkYXRhc3RvcmUgY2hhbmdlIG1pZ2h0IG5vdCBiZSBmcm9tIGNsaWVudCBidXQgZnJvbSB0aGUg YWdlbnQgaXRzZWxmLiBUaGVzZSBvcGVyYXRpb25zIG5lZWQgdG8gbWFuaXB1bGF0ZSB0aGUgZGF0 YSBpbiBydW5uaW5nIGRhdGFzdG9yZSBvciBjYW5kaWRhdGUgZGF0YXN0b3JlLCBhbmQgdGh1cyB0 aGV5IG5lZWQgdGhlIDxlZGl0LWNvbmZpZz4gY2FwYWJpbGl0eSBhIHdlbGwgYXMgYSB1bmlmaWVk IGF1dGhvcml6YXRpb24gc3lzdGVtIHRvIGNvbnRyb2wgdGhlIGluZmx1ZW5jZSB0byB0aGUgZGF0 YSAgIHN0b3JlcyBjYXVzZWQgYnkgdGhlbS4NCiBTbyB3ZSB3cm90ZSBhIGRyYWZ0IHRvIHRyeSB0 byBtYWtlIGEgIGRpc2N1c3Npb24gb2YgdGhlIGlzc3VlLiBUaGUgZHJhZnQgYW5hbHl6ZXMgdGhl IHNjZW5hcmlvIGFuZCByZXF1aXJtZW50cyBmb3IgbW9kZWwgb3BlcmF0aW9ucywgYW5kIGJyaWVm bHkgZGlzY3VzcyBzb21lIHBvc3NpYmxlIHNvbHV0aW9ucyB0byBzYXRpc2Z5IHRoZSByZXF1aXJt ZW50cy4NClBsZWFzZSByZXZpZXcgdGhlIGRyYWZ0IGFuZCBjb21tZW50Lg0KTWFueSB0aGFua3Mh DQpCZXN0IHJlZ2FyZHMsDQpaaGVuZw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0Kt6K8/sjLOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW2ludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10NCreiy83KsbzkOiAyMDE0xOo31MIyyNUgMTc6NTQNCsrVvP7IyzogSml4aWFv ZmVuZyAoU3RldmVuKTsgWmhlbmdndWFuZ3lpbmc7IEppeGlhb2ZlbmcgKFN0ZXZlbik7IFpoZW5n Z3Vhbmd5aW5nDQrW98ziOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXpoZW5n LW5ldG1vZC1pbnRlZ3JhdGUtb3BlcmF0aW9ucy0wMC50eHQNCg0KQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3JhdGUtb3BlcmF0aW9ucy0wMC50eHQNCmhhcyBi ZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgR3Vhbmd5aW5nIFpoZW5nIGFuZCBwb3N0ZWQg dG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC16aGVuZy1u ZXRtb2QtaW50ZWdyYXRlLW9wZXJhdGlvbnMNClJldmlzaW9uOiAgICAgICAwMA0KVGl0bGU6ICAg ICAgICAgIEludGVncmF0aW5nIE9wZXJhdGlvbnMgaW4gWUFORyBNb2RlbHMNCkRvY3VtZW50IGRh dGU6ICAyMDE0LTA3LTAyDQpHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQ YWdlczogICAgICAgICAgMTENClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC16aGVuZy1uZXRtb2QtaW50ZWdyYXRlLW9wZXJhdGlvbnMtMDAu dHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtemhlbmctbmV0bW9kLWludGVncmF0ZS1vcGVyYXRpb25zLw0KSHRtbGl6ZWQ6ICAgICAgIGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3JhdGUtb3Bl cmF0aW9ucy0wMA0KDQoNCkFic3RyYWN0Og0KICBUaGlzIGRvY3VtZW50IGludHJvZHVjZXMgYW4g ZXh0ZW5zaW9uIHRvIFlBTkcuIFRoZSBleHRlbnNpb24gYWxsb3dzDQogIG9wZXJhdGlvbiBtZXRo b2RzIHRvIGJlIGRpcmVjdGx5IGludGVncmF0ZWQgaW4gWUFORyBtb2RlbHMuDQoNCg0KDQoNClBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy ZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWls aW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRtb2QNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6 IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1l bnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBh bmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocyku ICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCBy ZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBv ZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5k IG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg0KDQoNCg== --_000_381D7D55085B1E4D8B581BD652E1E14058C5BF3Bnkgeml504mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Daixianxian
  
       Thank you for your comments firstly. I= try to answer your comments here, please check my doubt, thanks.

        >>1.In my opinion, meth= od defines method rather than data.If the sample succeeds, user gets "= arpList" data by <get-config> operation,
        the responding message display b= oth the static data and the new data(dynamic data).Is it right? Does it nee= d to commit?
       
        Zheng: Right, if succeed, the dy= namic data will become configuration data and it will in the  <get-= config> RPC reply data.
            &nb= sp;  If define new non-standard RPC, do you think it need a sperate co= mmit operation or commit it internally combine with the new defined RPC?             &nb= sp; 
       
        >>After that,if user edits= the new "arpList" data by <edit-config> operation,is the d= ynamic data be edited at the same time?
        If the dynamic data is deleted f= or some reason, the new "arpList" data still exist?
        Zheng: After convert the dynamic= data to configuration data, the orignal dynamic data will be deleted.
       

        >>2.Can you describe th= e attribute information of the method?
        Does the method support "ou= tput" statement?
        Is the config statement of node = meaningless?
        Zheng=A3=BAIn this version draft= we want to describe the problems itself, and try to discuss it in the WG a= nd make it clear. The detail design will describe in the next version.

 

Regards&Thanks

Zheng

=B7=A2=BC=FE=C8=CB: dai.xianxian@zte.com.cn= [dai.xianxian@zte.com.cn]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA7=D4=C29=C8=D5 17:13
=CA=D5=BC=FE=C8=CB: Zhengguangying
=B3=AD=CB=CD: netmod@ietf.org; netmod; Yangang
=D6=F7=CC=E2: =B4=F0=B8=B4: [netmod] FW: New Version Notification fo= r draft-zheng-netmod-integrate-operations-00.txt

 Hi Zhengguangying, <= br>
        After read= ing the draft, I have some doubts,can you answer them?

        1.In my op= inion, method defines method rather than data.If the sample succeeds, user = gets "arpList" data by <get-config> operation,
        the respon= ding message display both the static data and the new data(dynamic data).Is= it right? Does it need to commit?
        After that= ,if user edits the new "arpList" data by <edit-config> oper= ation,is the dynamic data be edited at the same time?
        If the dyn= amic data is deleted for some reason, the new "arpList" data stil= l exist?

        2.Can you = describe the attribute information of the method?
        Does the m= ethod support "output" statement?
        Is the con= fig statement of node meaningless?

       I think it = is better and clearer to define the method by using YANG.


Best regards!





Zhengguangying &l= t;zhengguangying@huawei.com>
=B7=A2=BC=FE=C8=CB:  "netmod= " <netmod-bounces@ietf.org>

2014-07-04 08:13

=CA=D5=BC=FE=C8= =CB
 "netmod@ietf.org" <ne= tmod@ietf.org>,
=B3=AD=CB=CD
 Yangang <yangang@huawei.com>=
=D6=F7=CC=E2
 [netmod] FW: New Version Notificat= ion for draft-zheng-netmod-integrate-operations-00.txt





Hi all in Netmod ,

   In some datastore operation scenarios, the operations triggere= d from the  NETCONF client might be a set of combined operations or a = complex single operation within the NETCONF agent, which may change the dat= astores. And  sometimes the datastore change might not be from client but from the agent itself. These operations need to man= ipulate the data in running datastore or candidate datastore, and thus they= need the <edit-config> capability a well as a unified authorization = system to control the influence to the data   stores caused by them.
 So we wrote a draft to try to make a  discussion of the issue. T= he draft analyzes the scenario and requirments for model operations, and br= iefly discuss some possible solutions to satisfy the requirments.
Please review the draft and comment.
Many thanks!
Best regards,
Zheng
________________________________________
=B7=A2=BC=FE=C8=CB: internet-drafts@ietf.org [internet-drafts@ietf.org]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA7=D4=C22=C8=D5 17:54
=CA=D5=BC=FE=C8=CB: Jixiaofeng (Steven); Zhengguangying; Jixiaofeng (Steven= ); Zhengguangying
=D6=F7=CC=E2: New Version Notification for draft-zheng-netmod-integrate-ope= rations-00.txt

A new version of I-D, draft-zheng-netmod-integrate-operations-00.txt
has been successfully submitted by Guangying Zheng and posted to the
IETF repository.

Name:           draft-zheng-netmod-integrate-opera= tions
Revision:       00
Title:          Integrating Operations in YANG Mod= els
Document date:  2014-07-02
Group:          Individual Submission
Pages:          11
URL:            http://w= ww.ietf.org/internet-drafts/draft-zheng-netmod-integrate-operations-00.txt<= /u>
Status:         https://datatracker.ietf.or= g/doc/draft-zheng-netmod-integrate-operations/
Htmlized:       http://tools.ietf.org/html/draft-zh= eng-netmod-integrate-operations-00


Abstract:
  This document introduces an extension to YANG. The extension allows<= br>   operation methods to be directly integrated in YANG models.




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___________________________= ____________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netm= od



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (an=
d any attachment transmitted herewith) is privileged and confidential and i=
s intended for the exclusive use of the addressee(s).  If you are not an in=
tended recipient, any disclosure, reproduction, distribution or other disse=
mination or use of the information contained is strictly prohibited.  If yo=
u have received this mail in error, please delete it and notify us immediat=
ely.

--_000_381D7D55085B1E4D8B581BD652E1E14058C5BF3Bnkgeml504mbxchi_-- From nobody Thu Jul 10 01:01:46 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632961A0397; Thu, 10 Jul 2014 01:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.1 X-Spam-Level: X-Spam-Status: No, score=-92.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_92=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djYhgVSErbyf; Thu, 10 Jul 2014 01:01:30 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id AD2401A0371; Thu, 10 Jul 2014 01:01:27 -0700 (PDT) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 75E55125CFCE; Thu, 10 Jul 2014 16:01:11 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s6A814PV056875; Thu, 10 Jul 2014 16:01:05 +0800 (GMT-8) (envelope-from dai.xianxian@zte.com.cn) In-Reply-To: <381D7D55085B1E4D8B581BD652E1E14058C5BF3B@nkgeml504-mbx.china.huawei.com> References: <381D7D55085B1E4D8B581BD652E1E14058C5B646@nkgeml504-mbx.china.huawei.com>, <381D7D55085B1E4D8B581BD652E1E14058C5BF3B@nkgeml504-mbx.china.huawei.com> To: Zhengguangying MIME-Version: 1.0 X-KeepSent: F706F20A:F16C9F6E-48257D11:002BDD0C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: dai.xianxian@zte.com.cn Date: Thu, 10 Jul 2014 16:01:00 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-07-10 16:00:59, Serialize complete at 2014-07-10 16:00:59 Content-Type: multipart/alternative; boundary="=_alternative 002B9B9848257D11_=" X-MAIL: mse02.zte.com.cn s6A814PV056875 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/tVTVhVUJr5nabBvyXEDQvfiVWH0 Cc: netmod , "netmod@ietf.org" , Yangang Subject: [netmod] =?gb2312?b?tPC4tDogIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp?= =?gb2312?b?b24gZm9yIGRyYWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3JhdGUtb3BlcmF0aW9u?= =?gb2312?b?cy0wMC50eHQ=?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 08:01:36 -0000 This is a multipart message in MIME format. --=_alternative 002B9B9848257D11_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgWmhlbmdndWFuZ3lpbmcsIA0KDQogICAgICAgIEkgdGhpbmsgSSBoYXZlIHVuZGVyc3RhbmQg eW91ciBkZXNpZ24gY29uY2VwdC4gVGhhbmsgeW91Lg0KDQogICAgICAgIEEgc3VnZ2VzdGlvbjog YXMgbWV0aG9kIGlzIGRlZmluZWQgaW4gbW9kdWxlIHN0YXRlbWVudCwgdXNlcnMgY2FuIA0Kb25s eSBjb252ZXJ0IGR5bmFtaWMgZGF0YSBtb2R1bGUgYnkgbW9kdWxlLg0KIA0KICAgICAgICBNYXli ZSB5b3UgY2FuIGRlZmluZSBhbiBuZXcgb3BlcmF0aW9uIHRvIGFjY29tcGxpc2ggYWxsIHRoZSAN CmR5bmFtaWMgZGF0YSBiZWNvbWluZyBjb25maWd1cmF0aW9uIGRhdGEsDQogICAgICAgIGxpa2Ug ImNvcHkgY29uZmlnIiBvcGVyYXRpb24/DQoNCg0KQmVzdCByZWdhcmRzIQ0KDQoNCg0KDQpaaGVu Z2d1YW5neWluZyA8emhlbmdndWFuZ3lpbmdAaHVhd2VpLmNvbT4gDQoyMDE0LTA3LTEwIDE0OjEw DQoNCsrVvP7Iyw0KImRhaS54aWFueGlhbkB6dGUuY29tLmNuIiA8ZGFpLnhpYW54aWFuQHp0ZS5j b20uY24+LCANCrOty80NCiJuZXRtb2RAaWV0Zi5vcmciIDxuZXRtb2RAaWV0Zi5vcmc+LCBuZXRt b2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPiwgDQpZYW5nYW5nIDx5YW5nYW5nQGh1YXdlaS5j b20+DQrW98ziDQq08Li0OiBbbmV0bW9kXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciANCmRyYWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3JhdGUtb3BlcmF0aW9ucy0wMC50eHQNCg0KDQoN Cg0KDQoNCkhpLCBEYWl4aWFueGlhbg0KIA0KICAgICAgIFRoYW5rIHlvdSBmb3IgeW91ciBjb21t ZW50cyBmaXJzdGx5LiBJIHRyeSB0byBhbnN3ZXIgeW91ciBjb21tZW50cyANCmhlcmUsIHBsZWFz ZSBjaGVjayBteSBkb3VidCwgdGhhbmtzLg0KICAgICAgICA+PjEuSW4gbXkgb3BpbmlvbiwgbWV0 aG9kIGRlZmluZXMgbWV0aG9kIHJhdGhlciB0aGFuIGRhdGEuSWYgdGhlIA0Kc2FtcGxlIHN1Y2Nl ZWRzLCB1c2VyIGdldHMgImFycExpc3QiIGRhdGEgYnkgPGdldC1jb25maWc+IG9wZXJhdGlvbiwg DQogICAgICAgIHRoZSByZXNwb25kaW5nIG1lc3NhZ2UgZGlzcGxheSBib3RoIHRoZSBzdGF0aWMg ZGF0YSBhbmQgdGhlIG5ldyANCmRhdGEoZHluYW1pYyBkYXRhKS5JcyBpdCByaWdodD8gRG9lcyBp dCBuZWVkIHRvIGNvbW1pdD8gDQogDQogICAgICAgIFpoZW5nOiBSaWdodCwgaWYgc3VjY2VlZCwg dGhlIGR5bmFtaWMgZGF0YSB3aWxsIGJlY29tZSANCmNvbmZpZ3VyYXRpb24gZGF0YSBhbmQgaXQg d2lsbCBpbiB0aGUgIDxnZXQtY29uZmlnPiBSUEMgcmVwbHkgZGF0YS4gDQogICAgICAgICAgICAg ICBJZiBkZWZpbmUgbmV3IG5vbi1zdGFuZGFyZCBSUEMsIGRvIHlvdSB0aGluayBpdCBuZWVkIGEg DQpzcGVyYXRlIGNvbW1pdCBvcGVyYXRpb24gb3IgY29tbWl0IGl0IGludGVybmFsbHkgY29tYmlu ZSB3aXRoIHRoZSBuZXcgDQpkZWZpbmVkIFJQQz8NCiANCiANCiAgICAgICAgPj5BZnRlciB0aGF0 LGlmIHVzZXIgZWRpdHMgdGhlIG5ldyAiYXJwTGlzdCIgZGF0YSBieSA8ZWRpdC1jb25maWc+IA0K b3BlcmF0aW9uLGlzIHRoZSBkeW5hbWljIGRhdGEgYmUgZWRpdGVkIGF0IHRoZSBzYW1lIHRpbWU/ IA0KICAgICAgICBJZiB0aGUgZHluYW1pYyBkYXRhIGlzIGRlbGV0ZWQgZm9yIHNvbWUgcmVhc29u LCB0aGUgbmV3ICJhcnBMaXN0IiANCmRhdGEgc3RpbGwgZXhpc3Q/IA0KICAgICAgICBaaGVuZzog QWZ0ZXIgY29udmVydCB0aGUgZHluYW1pYyBkYXRhIHRvIGNvbmZpZ3VyYXRpb24gZGF0YSwgdGhl IA0Kb3JpZ25hbCBkeW5hbWljIGRhdGEgd2lsbCBiZSBkZWxldGVkLg0KIA0KICAgICAgICA+PjIu Q2FuIHlvdSBkZXNjcmliZSB0aGUgYXR0cmlidXRlIGluZm9ybWF0aW9uIG9mIHRoZSBtZXRob2Q/ IA0KICAgICAgICBEb2VzIHRoZSBtZXRob2Qgc3VwcG9ydCAib3V0cHV0IiBzdGF0ZW1lbnQ/IA0K ICAgICAgICBJcyB0aGUgY29uZmlnIHN0YXRlbWVudCBvZiBub2RlIG1lYW5pbmdsZXNzPw0KICAg ICAgICBaaGVuZ6O6SW4gdGhpcyB2ZXJzaW9uIGRyYWZ0IHdlIHdhbnQgdG8gZGVzY3JpYmUgdGhl IHByb2JsZW1zIA0KaXRzZWxmLCBhbmQgdHJ5IHRvIGRpc2N1c3MgaXQgaW4gdGhlIFdHIGFuZCBt YWtlIGl0IGNsZWFyLiBUaGUgZGV0YWlsIA0KZGVzaWduIHdpbGwgZGVzY3JpYmUgaW4gdGhlIG5l eHQgdmVyc2lvbi4NCiANClJlZ2FyZHMmVGhhbmtzDQpaaGVuZw0KDQq3orz+yMs6IGRhaS54aWFu eGlhbkB6dGUuY29tLmNuIFtkYWkueGlhbnhpYW5AenRlLmNvbS5jbl0NCreiy83KsbzkOiAyMDE0 xOo31MI5yNUgMTc6MTMNCsrVvP7IyzogWmhlbmdndWFuZ3lpbmcNCrOty806IG5ldG1vZEBpZXRm Lm9yZzsgbmV0bW9kOyBZYW5nYW5nDQrW98ziOiC08Li0OiBbbmV0bW9kXSBGVzogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciANCmRyYWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3JhdGUtb3BlcmF0 aW9ucy0wMC50eHQNCg0KIEhpIFpoZW5nZ3Vhbmd5aW5nLCANCg0KICAgICAgICBBZnRlciByZWFk aW5nIHRoZSBkcmFmdCwgSSBoYXZlIHNvbWUgZG91YnRzLGNhbiB5b3UgYW5zd2VyIHRoZW0/IA0K DQogICAgICAgIDEuSW4gbXkgb3BpbmlvbiwgbWV0aG9kIGRlZmluZXMgbWV0aG9kIHJhdGhlciB0 aGFuIGRhdGEuSWYgdGhlIA0Kc2FtcGxlIHN1Y2NlZWRzLCB1c2VyIGdldHMgImFycExpc3QiIGRh dGEgYnkgPGdldC1jb25maWc+IG9wZXJhdGlvbiwgDQogICAgICAgIHRoZSByZXNwb25kaW5nIG1l c3NhZ2UgZGlzcGxheSBib3RoIHRoZSBzdGF0aWMgZGF0YSBhbmQgdGhlIG5ldyANCmRhdGEoZHlu YW1pYyBkYXRhKS5JcyBpdCByaWdodD8gRG9lcyBpdCBuZWVkIHRvIGNvbW1pdD8gDQogICAgICAg IEFmdGVyIHRoYXQsaWYgdXNlciBlZGl0cyB0aGUgbmV3ICJhcnBMaXN0IiBkYXRhIGJ5IDxlZGl0 LWNvbmZpZz4gDQpvcGVyYXRpb24saXMgdGhlIGR5bmFtaWMgZGF0YSBiZSBlZGl0ZWQgYXQgdGhl IHNhbWUgdGltZT8gDQogICAgICAgIElmIHRoZSBkeW5hbWljIGRhdGEgaXMgZGVsZXRlZCBmb3Ig c29tZSByZWFzb24sIHRoZSBuZXcgImFycExpc3QiIA0KZGF0YSBzdGlsbCBleGlzdD8gDQoNCiAg ICAgICAgMi5DYW4geW91IGRlc2NyaWJlIHRoZSBhdHRyaWJ1dGUgaW5mb3JtYXRpb24gb2YgdGhl IG1ldGhvZD8gDQogICAgICAgIERvZXMgdGhlIG1ldGhvZCBzdXBwb3J0ICJvdXRwdXQiIHN0YXRl bWVudD8gDQogICAgICAgIElzIHRoZSBjb25maWcgc3RhdGVtZW50IG9mIG5vZGUgbWVhbmluZ2xl c3M/IA0KDQogICAgICAgSSB0aGluayBpdCBpcyBiZXR0ZXIgYW5kIGNsZWFyZXIgdG8gZGVmaW5l IHRoZSBtZXRob2QgYnkgdXNpbmcgDQpZQU5HLiANCg0KDQpCZXN0IHJlZ2FyZHMhDQoNCg0KDQoN Cg0KWmhlbmdndWFuZ3lpbmcgPHpoZW5nZ3Vhbmd5aW5nQGh1YXdlaS5jb20+IA0Kt6K8/sjLOiAg Im5ldG1vZCIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPiANCjIwMTQtMDctMDQgMDg6MTMgDQoN Cg0KytW8/sjLDQoibmV0bW9kQGlldGYub3JnIiA8bmV0bW9kQGlldGYub3JnPiwgDQqzrcvNDQpZ YW5nYW5nIDx5YW5nYW5nQGh1YXdlaS5jb20+IA0K1vfM4g0KW25ldG1vZF0gRlc6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgDQpkcmFmdC16aGVuZy1uZXRtb2QtaW50ZWdyYXRlLW9wZXJh dGlvbnMtMDAudHh0DQoNCg0KDQoNCg0KDQoNCg0KSGkgYWxsIGluIE5ldG1vZCAsDQoNCiAgIElu IHNvbWUgZGF0YXN0b3JlIG9wZXJhdGlvbiBzY2VuYXJpb3MsIHRoZSBvcGVyYXRpb25zIHRyaWdn ZXJlZCBmcm9tIA0KdGhlICBORVRDT05GIGNsaWVudCBtaWdodCBiZSBhIHNldCBvZiBjb21iaW5l ZCBvcGVyYXRpb25zIG9yIGEgY29tcGxleCANCnNpbmdsZSBvcGVyYXRpb24gd2l0aGluIHRoZSBO RVRDT05GIGFnZW50LCB3aGljaCBtYXkgY2hhbmdlIHRoZSANCmRhdGFzdG9yZXMuIEFuZCAgc29t ZXRpbWVzIHRoZSBkYXRhc3RvcmUgY2hhbmdlIG1pZ2h0IG5vdCBiZSBmcm9tIGNsaWVudCANCmJ1 dCBmcm9tIHRoZSBhZ2VudCBpdHNlbGYuIFRoZXNlIG9wZXJhdGlvbnMgbmVlZCB0byBtYW5pcHVs YXRlIHRoZSBkYXRhIGluIA0KcnVubmluZyBkYXRhc3RvcmUgb3IgY2FuZGlkYXRlIGRhdGFzdG9y ZSwgYW5kIHRodXMgdGhleSBuZWVkIHRoZSANCjxlZGl0LWNvbmZpZz4gY2FwYWJpbGl0eSBhIHdl bGwgYXMgYSB1bmlmaWVkIGF1dGhvcml6YXRpb24gc3lzdGVtIHRvIA0KY29udHJvbCB0aGUgaW5m bHVlbmNlIHRvIHRoZSBkYXRhICAgc3RvcmVzIGNhdXNlZCBieSB0aGVtLg0KIFNvIHdlIHdyb3Rl IGEgZHJhZnQgdG8gdHJ5IHRvIG1ha2UgYSAgZGlzY3Vzc2lvbiBvZiB0aGUgaXNzdWUuIFRoZSBk cmFmdCANCmFuYWx5emVzIHRoZSBzY2VuYXJpbyBhbmQgcmVxdWlybWVudHMgZm9yIG1vZGVsIG9w ZXJhdGlvbnMsIGFuZCBicmllZmx5IA0KZGlzY3VzcyBzb21lIHBvc3NpYmxlIHNvbHV0aW9ucyB0 byBzYXRpc2Z5IHRoZSByZXF1aXJtZW50cy4NClBsZWFzZSByZXZpZXcgdGhlIGRyYWZ0IGFuZCBj b21tZW50Lg0KTWFueSB0aGFua3MhDQpCZXN0IHJlZ2FyZHMsDQpaaGVuZw0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW2ludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCreiy83KsbzkOiAyMDE0xOo31MIyyNUg MTc6NTQNCsrVvP7IyzogSml4aWFvZmVuZyAoU3RldmVuKTsgWmhlbmdndWFuZ3lpbmc7IEppeGlh b2ZlbmcgKFN0ZXZlbik7IA0KWmhlbmdndWFuZ3lpbmcNCtb3zOI6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgDQpkcmFmdC16aGVuZy1uZXRtb2QtaW50ZWdyYXRlLW9wZXJhdGlvbnMtMDAu dHh0DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC16aGVuZy1uZXRtb2QtaW50ZWdyYXRl LW9wZXJhdGlvbnMtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEd1 YW5neWluZyBaaGVuZyBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1l OiAgICAgICAgICAgZHJhZnQtemhlbmctbmV0bW9kLWludGVncmF0ZS1vcGVyYXRpb25zDQpSZXZp c2lvbjogICAgICAgMDANClRpdGxlOiAgICAgICAgICBJbnRlZ3JhdGluZyBPcGVyYXRpb25zIGlu IFlBTkcgTW9kZWxzDQpEb2N1bWVudCBkYXRlOiAgMjAxNC0wNy0wMg0KR3JvdXA6ICAgICAgICAg IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAgIDExDQpVUkw6ICAgICAgICAg ICAgDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16aGVuZy1uZXRt b2QtaW50ZWdyYXRlLW9wZXJhdGlvbnMtMDAudHh0DQoNClN0YXR1czogICAgICAgICANCmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3JhdGUt b3BlcmF0aW9ucy8NCkh0bWxpemVkOiAgICAgICANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3JhdGUtb3BlcmF0aW9ucy0wMA0KDQoNCkFic3RyYWN0 Og0KICBUaGlzIGRvY3VtZW50IGludHJvZHVjZXMgYW4gZXh0ZW5zaW9uIHRvIFlBTkcuIFRoZSBl eHRlbnNpb24gYWxsb3dzDQogIG9wZXJhdGlvbiBtZXRob2RzIHRvIGJlIGRpcmVjdGx5IGludGVn cmF0ZWQgaW4gWUFORyBtb2RlbHMuDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRh a2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIA0Kc3VibWlzc2lvbg0KdW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p ZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXRfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQoNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gdGhpcyBtYWlsIA0KKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0 aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIA0KYW5kIGlzIGludGVuZGVkIGZvciB0 aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgDQph biBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3Ry aWJ1dGlvbiBvciBvdGhlciANCmRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gDQpJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyANCmlt bWVkaWF0ZWx5Lg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0 cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBp cyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElm IHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJv ZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90 aWZ5IHVzIGltbWVkaWF0ZWx5Lg0K --=_alternative 002B9B9848257D11_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFpoZW5nZ3Vhbmd5aW5nLCA8YnI+DQo8 YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SSB0aGluayBJIGhhdmUgdW5kZXJzdGFu ZCB5b3VyIGRlc2lnbg0KY29uY2VwdC4gVGhhbmsgeW91LjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEEN CnN1Z2dlc3Rpb246IGFzIG1ldGhvZCBpcyBkZWZpbmVkIGluIG1vZHVsZSBzdGF0ZW1lbnQsIHVz ZXJzIGNhbiBvbmx5IGNvbnZlcnQNCmR5bmFtaWMgZGF0YSBtb2R1bGUgYnkgbW9kdWxlLjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE1heWJlDQp5b3UgY2FuIGRlZmluZSBhbiBuZXcgb3Bl cmF0aW9uIHRvIGFjY29tcGxpc2ggYWxsIHRoZSBkeW5hbWljIGRhdGEgYmVjb21pbmcNCmNvbmZp Z3VyYXRpb24gZGF0YSw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBsaWtlDQomcXVvdDtjb3B5IGNvbmZpZyZxdW90 OyBvcGVyYXRpb24/PGJyPg0KPGJyPg0KPGJyPg0KQmVzdCByZWdhcmRzITwvZm9udD4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQgd2lkdGg9MzYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5aaGVuZ2d1YW5n eWluZyAmbHQ7emhlbmdndWFuZ3lpbmdAaHVhd2VpLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxNC0wNy0xMCAxNDoxMDwvZm9udD4NCjx0 ZCB3aWR0aD02MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtkYWku eGlhbnhpYW5AenRlLmNvbS5jbiZxdW90Ow0KJmx0O2RhaS54aWFueGlhbkB6dGUuY29tLmNuJmd0 OywgPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtuZXRtb2RAaWV0Zi5vcmcmcXVvdDsgJmx0O25l dG1vZEBpZXRmLm9yZyZndDssDQpuZXRtb2QgJmx0O25ldG1vZC1ib3VuY2VzQGlldGYub3JnJmd0 OywgWWFuZ2FuZyAmbHQ7eWFuZ2FuZ0BodWF3ZWkuY29tJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ tPC4tDogW25ldG1vZF0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbg0KZm9yIGRyYWZ0LXpo ZW5nLW5ldG1vZC1pbnRlZ3JhdGUtb3BlcmF0aW9ucy0wMC50eHQ8L2ZvbnQ+PC90YWJsZT4NCjxi cj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90 YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5IaSwgRGFp eGlhbnhpYW48YnI+DQogJm5ic3A7IDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGFuayB5 b3UgZm9yIHlvdXIgY29tbWVudHMgZmlyc3RseS4gSSB0cnkgdG8gYW5zd2VyDQp5b3VyIGNvbW1l bnRzIGhlcmUsIHBsZWFzZSBjaGVjayBteSBkb3VidCwgdGhhbmtzLjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iVGFob21hIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZn dDsxLkluDQpteSBvcGluaW9uLCBtZXRob2QgZGVmaW5lcyBtZXRob2QgcmF0aGVyIHRoYW4gZGF0 YS5JZiB0aGUgc2FtcGxlIHN1Y2NlZWRzLA0KdXNlciBnZXRzICZxdW90O2FycExpc3QmcXVvdDsg ZGF0YSBieSAmbHQ7Z2V0LWNvbmZpZyZndDsgb3BlcmF0aW9uLCA8YnI+DQogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7dGhlIHJlc3BvbmRpbmcgbWVzc2FnZSBkaXNwbGF5IGJvdGggdGhlIHN0 YXRpYw0KZGF0YSBhbmQgdGhlIG5ldyBkYXRhKGR5bmFtaWMgZGF0YSkuSXMgaXQgcmlnaHQ/IERv ZXMgaXQgbmVlZCB0byBjb21taXQ/DQo8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1poZW5nOiBSaWdodCwgaWYgc3VjY2Vl ZCwgdGhlIGR5bmFtaWMgZGF0YQ0Kd2lsbCBiZWNvbWUgY29uZmlndXJhdGlvbiBkYXRhIGFuZCBp dCB3aWxsIGluIHRoZSAmbmJzcDsmbHQ7Z2V0LWNvbmZpZyZndDsNClJQQyByZXBseSBkYXRhLiA8 YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IElm IGRlZmluZSBuZXcgbm9uLXN0YW5kYXJkDQpSUEMsIGRvIHlvdSB0aGluayBpdCBuZWVkIGEgc3Bl cmF0ZSBjb21taXQgb3BlcmF0aW9uIG9yIGNvbW1pdCBpdCBpbnRlcm5hbGx5DQpjb21iaW5lIHdp dGggdGhlIG5ldyBkZWZpbmVkIFJQQz88YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8 YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZndDtBZnRlciB0aGF0LGlmIHVz ZXIgZWRpdHMgdGhlIG5ldyAmcXVvdDthcnBMaXN0JnF1b3Q7DQpkYXRhIGJ5ICZsdDtlZGl0LWNv bmZpZyZndDsgb3BlcmF0aW9uLGlzIHRoZSBkeW5hbWljIGRhdGEgYmUgZWRpdGVkIGF0DQp0aGUg c2FtZSB0aW1lPyA8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SWYgdGhlIGR5bmFt aWMgZGF0YSBpcyBkZWxldGVkIGZvciBzb21lIHJlYXNvbiwNCnRoZSBuZXcgJnF1b3Q7YXJwTGlz dCZxdW90OyBkYXRhIHN0aWxsIGV4aXN0PyA8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Wmhlbmc6IEFmdGVyIGNvbnZlcnQgdGhlIGR5bmFtaWMgZGF0YSB0byBjb25maWd1cmF0aW9u DQpkYXRhLCB0aGUgb3JpZ25hbCBkeW5hbWljIGRhdGEgd2lsbCBiZSBkZWxldGVkLjxicj4NCiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IlRhaG9tYSI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmZ3Q7Mi5DYW4NCnlvdSBk ZXNjcmliZSB0aGUgYXR0cmlidXRlIGluZm9ybWF0aW9uIG9mIHRoZSBtZXRob2Q/IDxicj4NCiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtEb2VzIHRoZSBtZXRob2Qgc3VwcG9ydCAmcXVvdDtv dXRwdXQmcXVvdDsNCnN0YXRlbWVudD8gPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O0lzIHRoZSBjb25maWcgc3RhdGVtZW50IG9mIG5vZGUgbWVhbmluZ2xlc3M/PGJyPg0KICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO1poZW5no7pJbiB0aGlzIHZlcnNpb24gZHJhZnQgd2Ugd2Fu dCB0byBkZXNjcmliZQ0KdGhlIHByb2JsZW1zIGl0c2VsZiwgYW5kIHRyeSB0byBkaXNjdXNzIGl0 IGluIHRoZSBXRyBhbmQgbWFrZSBpdCBjbGVhci4NClRoZSBkZXRhaWwgZGVzaWduIHdpbGwgZGVz Y3JpYmUgaW4gdGhlIG5leHQgdmVyc2lvbi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IlRhaG9tYSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPlJl Z2FyZHMmYW1wO1RoYW5rczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5a aGVuZzwvZm9udD4NCjxwPg0KPGhyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxi PreivP7Iyzo8L2I+IGRhaS54aWFueGlhbkB6dGUuY29tLmNuDQpbZGFpLnhpYW54aWFuQHp0ZS5j b20uY25dPGI+PGJyPg0Kt6LLzcqxvOQ6PC9iPiAyMDE0xOo31MI5yNUgMTc6MTM8Yj48YnI+DQrK 1bz+yMs6PC9iPiBaaGVuZ2d1YW5neWluZzxiPjxicj4NCrOty806PC9iPiBuZXRtb2RAaWV0Zi5v cmc7IG5ldG1vZDsgWWFuZ2FuZzxiPjxicj4NCtb3zOI6PC9iPiC08Li0OiBbbmV0bW9kXSBGVzog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC16aGVuZy1uZXRtb2QtaW50ZWdyYXRl LW9wZXJhdGlvbnMtMDAudHh0PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJSb21hbiI+PGJyPg0K PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDtIaSBaaGVu Z2d1YW5neWluZyw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlJvbWFuIj4NCjxicj4NCjwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO0FmdGVyIHJlYWRpbmcgdGhlIGRyYWZ0LCBJIGhhdmUgc29tZSBkb3VidHMsY2Fu DQp5b3UgYW5zd2VyIHRoZW0/PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJSb21hbiI+IDxicj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOzEuSW4gbXkgb3BpbmlvbiwgbWV0aG9kIGRlZmluZXMgbWV0aG9kIHJh dGhlcg0KdGhhbiBkYXRhLklmIHRoZSBzYW1wbGUgc3VjY2VlZHMsIHVzZXIgZ2V0cyAmcXVvdDth cnBMaXN0JnF1b3Q7IGRhdGEgYnkNCiZsdDtnZXQtY29uZmlnJmd0OyBvcGVyYXRpb24sIDxicj4N CiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGUgcmVzcG9uZGluZyBtZXNzYWdlIGRpc3Bs YXkgYm90aCB0aGUgc3RhdGljDQpkYXRhIGFuZCB0aGUgbmV3IGRhdGEoZHluYW1pYyBkYXRhKS5J cyBpdCByaWdodD8gRG9lcyBpdCBuZWVkIHRvIGNvbW1pdD88L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9IlJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0K ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0FmdGVyIHRoYXQsaWYgdXNlciBlZGl0cyB0aGUg bmV3ICZxdW90O2FycExpc3QmcXVvdDsNCmRhdGEgYnkgJmx0O2VkaXQtY29uZmlnJmd0OyBvcGVy YXRpb24saXMgdGhlIGR5bmFtaWMgZGF0YSBiZSBlZGl0ZWQgYXQNCnRoZSBzYW1lIHRpbWU/PC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJSb21hbiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lmIHRoZSBkeW5h bWljIGRhdGEgaXMgZGVsZXRlZCBmb3Igc29tZSByZWFzb24sDQp0aGUgbmV3ICZxdW90O2FycExp c3QmcXVvdDsgZGF0YSBzdGlsbCBleGlzdD88L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlJvbWFu Ij4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzIuQ2FuIHlvdSBkZXNjcmliZSB0aGUgYXR0cmlidXRl IGluZm9ybWF0aW9uDQpvZiB0aGUgbWV0aG9kPzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iUm9t YW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtEb2VzIHRoZSBtZXRob2Qgc3VwcG9ydCAmcXVvdDtvdXRwdXQm cXVvdDsNCnN0YXRlbWVudD8gPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lzIHRo ZSBjb25maWcgc3RhdGVtZW50IG9mIG5vZGUgbWVhbmluZ2xlc3M/PC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJSb21hbiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJIHRoaW5rIGl0IGlzIGJldHRlciBhbmQg Y2xlYXJlciB0byBkZWZpbmUgdGhlIG1ldGhvZA0KYnkgdXNpbmcgWUFORy4gPGJyPg0KPGJyPg0K PGJyPg0KQmVzdCByZWdhcmRzITxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i Um9tYW4iPjxicj4NCjxicj4NCjxicj4NCjwvZm9udD4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzQlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij48Yj5aaGVuZ2d1YW5neWluZyAmbHQ7emhlbmdndWFuZ3lpbmdAaHVhd2VpLmNvbSZndDs8L2I+ DQo8YnI+DQq3orz+yMs6ICZuYnNwOyZxdW90O25ldG1vZCZxdW90OyAmbHQ7bmV0bW9kLWJvdW5j ZXNAaWV0Zi5vcmcmZ3Q7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxNC0wNy0wNCAwODox MzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dGQgd2lk dGg9NjUlPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3 aWR0aD02JT4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZCB3aWR0aD05MyU+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPiZxdW90O25ldG1vZEBpZXRmLm9yZyZxdW90Ow0KJmx0O25ldG1vZEBpZXRmLm9y ZyZndDssIDwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+WWFuZ2FuZyAmbHQ7eWFuZ2FuZ0BodWF3ZWkuY29t Jmd0OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPltuZXRtb2RdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24NCmZvciBkcmFmdC16 aGVuZy1uZXRtb2QtaW50ZWdyYXRlLW9wZXJhdGlvbnMtMDAudHh0PC9mb250PjwvdGFibGU+DQo8 YnI+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0K PGJyPjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlJvbWFuIj48YnI+DQo8YnI+DQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGJyPg0KSGkgYWxsIGluIE5ldG1vZCAs PGJyPg0KPGJyPg0KICZuYnNwOyBJbiBzb21lIGRhdGFzdG9yZSBvcGVyYXRpb24gc2NlbmFyaW9z LCB0aGUgb3BlcmF0aW9ucyB0cmlnZ2VyZWQNCmZyb20gdGhlICZuYnNwO05FVENPTkYgY2xpZW50 IG1pZ2h0IGJlIGEgc2V0IG9mIGNvbWJpbmVkIG9wZXJhdGlvbnMgb3INCmEgY29tcGxleCBzaW5n bGUgb3BlcmF0aW9uIHdpdGhpbiB0aGUgTkVUQ09ORiBhZ2VudCwgd2hpY2ggbWF5IGNoYW5nZSB0 aGUNCmRhdGFzdG9yZXMuIEFuZCAmbmJzcDtzb21ldGltZXMgdGhlIGRhdGFzdG9yZSBjaGFuZ2Ug bWlnaHQgbm90IGJlIGZyb20NCmNsaWVudCBidXQgZnJvbSB0aGUgYWdlbnQgaXRzZWxmLiBUaGVz ZSBvcGVyYXRpb25zIG5lZWQgdG8gbWFuaXB1bGF0ZSB0aGUNCmRhdGEgaW4gcnVubmluZyBkYXRh c3RvcmUgb3IgY2FuZGlkYXRlIGRhdGFzdG9yZSwgYW5kIHRodXMgdGhleSBuZWVkIHRoZQ0KJmx0 O2VkaXQtY29uZmlnJmd0OyBjYXBhYmlsaXR5IGEgd2VsbCBhcyBhIHVuaWZpZWQgYXV0aG9yaXph dGlvbiBzeXN0ZW0NCnRvIGNvbnRyb2wgdGhlIGluZmx1ZW5jZSB0byB0aGUgZGF0YSAmbmJzcDsg c3RvcmVzIGNhdXNlZCBieSB0aGVtLjxicj4NCiBTbyB3ZSB3cm90ZSBhIGRyYWZ0IHRvIHRyeSB0 byBtYWtlIGEgJm5ic3A7ZGlzY3Vzc2lvbiBvZiB0aGUgaXNzdWUuIFRoZQ0KZHJhZnQgYW5hbHl6 ZXMgdGhlIHNjZW5hcmlvIGFuZCByZXF1aXJtZW50cyBmb3IgbW9kZWwgb3BlcmF0aW9ucywgYW5k IGJyaWVmbHkNCmRpc2N1c3Mgc29tZSBwb3NzaWJsZSBzb2x1dGlvbnMgdG8gc2F0aXNmeSB0aGUg cmVxdWlybWVudHMuPGJyPg0KUGxlYXNlIHJldmlldyB0aGUgZHJhZnQgYW5kIGNvbW1lbnQuPGJy Pg0KTWFueSB0aGFua3MhPGJyPg0KQmVzdCByZWdhcmRzLDxicj4NClpoZW5nPGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCreivP7IyzogaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnIFtpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddPGJyPg0Kt6LLzcqxvOQ6 IDIwMTTE6jfUwjLI1SAxNzo1NDxicj4NCsrVvP7IyzogSml4aWFvZmVuZyAoU3RldmVuKTsgWmhl bmdndWFuZ3lpbmc7IEppeGlhb2ZlbmcgKFN0ZXZlbik7IFpoZW5nZ3Vhbmd5aW5nPGJyPg0K1vfM 4jogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC16aGVuZy1uZXRtb2QtaW50ZWdy YXRlLW9wZXJhdGlvbnMtMDAudHh0PGJyPg0KPGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3JhdGUtb3BlcmF0aW9ucy0wMC50eHQ8YnI+DQpoYXMgYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEd1YW5neWluZyBaaGVuZyBhbmQgcG9zdGVkIHRv IHRoZTxicj4NCklFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRyYWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3JhdGUtb3BlcmF0 aW9uczxicj4NClJldmlzaW9uOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAwMDxicj4NClRpdGxlOiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW50ZWdyYXRpbmcgT3BlcmF0aW9ucyBp biBZQU5HDQpNb2RlbHM8YnI+DQpEb2N1bWVudCBkYXRlOiAmbmJzcDsyMDE0LTA3LTAyPGJyPg0K R3JvdXA6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJbmRpdmlkdWFsIFN1Ym1p c3Npb248YnI+DQpQYWdlczogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzExPGJy Pg0KVVJMOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvZm9udD48 YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16aGVuZy1u ZXRtb2QtaW50ZWdyYXRlLW9wZXJhdGlvbnMtMDAudHh0IiB0YXJnZXQ9X2JsYW5rPjxmb250IHNp emU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtemhlbmctbmV0bW9kLWludGVncmF0ZS1vcGVyYXRpb25zLTAwLnR4 dDwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxicj4NClN0YXR1czog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvZm9udD48YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGVuZy1uZXRtb2QtaW50ZWdyYXRlLW9wZXJhdGlv bnMvIiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+ PHU+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhlbmctbmV0bW9kLWlu dGVncmF0ZS1vcGVyYXRpb25zLzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhv bWEiPjxicj4NCkh0bWxpemVkOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L2ZvbnQ+PGEgaHJlZj0i aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhlbmctbmV0bW9kLWludGVncmF0ZS1v cGVyYXRpb25zLTAwIiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9 IlRhaG9tYSI+PHU+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhlbmctbmV0bW9k LWludGVncmF0ZS1vcGVyYXRpb25zLTAwPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9 IlRhaG9tYSI+PGJyPg0KPGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KICZuYnNwO1RoaXMgZG9j dW1lbnQgaW50cm9kdWNlcyBhbiBleHRlbnNpb24gdG8gWUFORy4gVGhlIGV4dGVuc2lvbiBhbGxv d3M8YnI+DQogJm5ic3A7b3BlcmF0aW9uIG1ldGhvZHMgdG8gYmUgZGlyZWN0bHkgaW50ZWdyYXRl ZCBpbiBZQU5HIG1vZGVscy48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2Ugbm90 ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBz dWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNyZXRhcmlh dDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iUm9tYW4iPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCm5l dG1vZEBpZXRmLm9yZzwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJSb21hbiI+ PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bW9kIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFj ZT0iUm9tYW4iPjx1Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9k PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9IlJvbWFuIj48YnI+DQo8YnI+DQo8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iUm9tYW4iPjxicj4NCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0K WlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIG1haWwNCihhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgp IGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbA0KYW5kIGlzIGludGVuZGVkIGZvciB0aGUg ZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAmbmJzcDtJZiB5b3UNCmFyZSBub3Qg YW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0 cmlidXRpb24NCm9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaXMgc3RyaWN0bHkNCnByb2hpYml0ZWQuICZuYnNwO0lmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZQ0KaXQgYW5kIG5vdGlmeSB1 cyBpbW1lZGlhdGVseS48YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQoNCjxicj48cHJl Pjxmb250IGNvbG9yPSJibHVlIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBU aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50 IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5k IGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAg SWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVw cm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2Yg dGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBu b3RpZnkgdXMgaW1tZWRpYXRlbHkuDQoNCjwvZm9udD48L3ByZT48YnI+DQo= --=_alternative 002B9B9848257D11_=-- From nobody Thu Jul 10 01:02:22 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E701A0371; Thu, 10 Jul 2014 01:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.1 X-Spam-Level: X-Spam-Status: No, score=-92.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_92=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KV0YzZ4Wx_O; Thu, 10 Jul 2014 01:02:17 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 726401B27A5; Thu, 10 Jul 2014 01:02:16 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 65D0B125CFD9; Thu, 10 Jul 2014 16:02:03 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id A1C8E733D94; Thu, 10 Jul 2014 16:02:02 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s6A81svE058496; Thu, 10 Jul 2014 16:01:54 +0800 (GMT-8) (envelope-from dai.xianxian@zte.com.cn) In-Reply-To: <381D7D55085B1E4D8B581BD652E1E14058C5BF3B@nkgeml504-mbx.china.huawei.com> References: <381D7D55085B1E4D8B581BD652E1E14058C5B646@nkgeml504-mbx.china.huawei.com>, <381D7D55085B1E4D8B581BD652E1E14058C5BF3B@nkgeml504-mbx.china.huawei.com> MIME-Version: 1.0 To: Zhengguangying X-KeepSent: F706F20A:F16C9F6E-48257D11:002BDD0C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: dai.xianxian@zte.com.cn Date: Thu, 10 Jul 2014 16:01:47 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-07-10 16:01:47, Serialize complete at 2014-07-10 16:01:47 Content-Type: multipart/alternative; boundary="=_alternative 002BAE0E48257D11_=" X-MAIL: mse01.zte.com.cn s6A81svE058496 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1KLwDHfb0zyxJVsDeRvDUyyiJdU Cc: netmod , "netmod@ietf.org" , Yangang Subject: [netmod] =?gb2312?b?tPC4tDogIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp?= =?gb2312?b?b24gZm9yIGRyYWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3JhdGUtb3BlcmF0aW9u?= =?gb2312?b?cy0wMC50eHQ=?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 08:02:19 -0000 This is a multipart message in MIME format. --=_alternative 002BAE0E48257D11_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgWmhlbmdndWFuZ3lpbmcsIA0KDQogICAgICAgIEkgdGhpbmsgSSBoYXZlIHVuZGVyc3RhbmQg eW91ciBkZXNpZ24gY29uY2VwdC4gVGhhbmsgeW91Lg0KDQogICAgICAgIEEgc3VnZ2VzdGlvbjog YXMgbWV0aG9kIGlzIGRlZmluZWQgaW4gbW9kdWxlIHN0YXRlbWVudCwgdXNlcnMgY2FuIA0Kb25s eSBjb252ZXJ0IGR5bmFtaWMgZGF0YSBtb2R1bGUgYnkgbW9kdWxlLg0KIA0KICAgICAgICBNYXli ZSB5b3UgY2FuIGRlZmluZSBhbiBuZXcgb3BlcmF0aW9uIHRvIGFjY29tcGxpc2ggYWxsIHRoZSAN CmR5bmFtaWMgZGF0YSBiZWNvbWluZyBjb25maWd1cmF0aW9uIGRhdGEsDQogICAgICAgIGxpa2Ug ImNvcHkgY29uZmlnIiBvcGVyYXRpb24/DQoNCg0KQmVzdCByZWdhcmRzIQ0KDQoNCg0KDQpaaGVu Z2d1YW5neWluZyA8emhlbmdndWFuZ3lpbmdAaHVhd2VpLmNvbT4gDQoyMDE0LTA3LTEwIDE0OjEw DQoNCsrVvP7Iyw0KImRhaS54aWFueGlhbkB6dGUuY29tLmNuIiA8ZGFpLnhpYW54aWFuQHp0ZS5j b20uY24+LCANCrOty80NCiJuZXRtb2RAaWV0Zi5vcmciIDxuZXRtb2RAaWV0Zi5vcmc+LCBuZXRt b2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPiwgDQpZYW5nYW5nIDx5YW5nYW5nQGh1YXdlaS5j b20+DQrW98ziDQq08Li0OiBbbmV0bW9kXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciANCmRyYWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3JhdGUtb3BlcmF0aW9ucy0wMC50eHQNCg0KDQoN Cg0KDQoNCkhpLCBEYWl4aWFueGlhbg0KIA0KICAgICAgIFRoYW5rIHlvdSBmb3IgeW91ciBjb21t ZW50cyBmaXJzdGx5LiBJIHRyeSB0byBhbnN3ZXIgeW91ciBjb21tZW50cyANCmhlcmUsIHBsZWFz ZSBjaGVjayBteSBkb3VidCwgdGhhbmtzLg0KICAgICAgICA+PjEuSW4gbXkgb3BpbmlvbiwgbWV0 aG9kIGRlZmluZXMgbWV0aG9kIHJhdGhlciB0aGFuIGRhdGEuSWYgdGhlIA0Kc2FtcGxlIHN1Y2Nl ZWRzLCB1c2VyIGdldHMgImFycExpc3QiIGRhdGEgYnkgPGdldC1jb25maWc+IG9wZXJhdGlvbiwg DQogICAgICAgIHRoZSByZXNwb25kaW5nIG1lc3NhZ2UgZGlzcGxheSBib3RoIHRoZSBzdGF0aWMg ZGF0YSBhbmQgdGhlIG5ldyANCmRhdGEoZHluYW1pYyBkYXRhKS5JcyBpdCByaWdodD8gRG9lcyBp dCBuZWVkIHRvIGNvbW1pdD8gDQogDQogICAgICAgIFpoZW5nOiBSaWdodCwgaWYgc3VjY2VlZCwg dGhlIGR5bmFtaWMgZGF0YSB3aWxsIGJlY29tZSANCmNvbmZpZ3VyYXRpb24gZGF0YSBhbmQgaXQg d2lsbCBpbiB0aGUgIDxnZXQtY29uZmlnPiBSUEMgcmVwbHkgZGF0YS4gDQogICAgICAgICAgICAg ICBJZiBkZWZpbmUgbmV3IG5vbi1zdGFuZGFyZCBSUEMsIGRvIHlvdSB0aGluayBpdCBuZWVkIGEg DQpzcGVyYXRlIGNvbW1pdCBvcGVyYXRpb24gb3IgY29tbWl0IGl0IGludGVybmFsbHkgY29tYmlu ZSB3aXRoIHRoZSBuZXcgDQpkZWZpbmVkIFJQQz8NCiANCiANCiAgICAgICAgPj5BZnRlciB0aGF0 LGlmIHVzZXIgZWRpdHMgdGhlIG5ldyAiYXJwTGlzdCIgZGF0YSBieSA8ZWRpdC1jb25maWc+IA0K b3BlcmF0aW9uLGlzIHRoZSBkeW5hbWljIGRhdGEgYmUgZWRpdGVkIGF0IHRoZSBzYW1lIHRpbWU/ IA0KICAgICAgICBJZiB0aGUgZHluYW1pYyBkYXRhIGlzIGRlbGV0ZWQgZm9yIHNvbWUgcmVhc29u LCB0aGUgbmV3ICJhcnBMaXN0IiANCmRhdGEgc3RpbGwgZXhpc3Q/IA0KICAgICAgICBaaGVuZzog QWZ0ZXIgY29udmVydCB0aGUgZHluYW1pYyBkYXRhIHRvIGNvbmZpZ3VyYXRpb24gZGF0YSwgdGhl IA0Kb3JpZ25hbCBkeW5hbWljIGRhdGEgd2lsbCBiZSBkZWxldGVkLg0KIA0KICAgICAgICA+PjIu Q2FuIHlvdSBkZXNjcmliZSB0aGUgYXR0cmlidXRlIGluZm9ybWF0aW9uIG9mIHRoZSBtZXRob2Q/ IA0KICAgICAgICBEb2VzIHRoZSBtZXRob2Qgc3VwcG9ydCAib3V0cHV0IiBzdGF0ZW1lbnQ/IA0K ICAgICAgICBJcyB0aGUgY29uZmlnIHN0YXRlbWVudCBvZiBub2RlIG1lYW5pbmdsZXNzPw0KICAg ICAgICBaaGVuZ6O6SW4gdGhpcyB2ZXJzaW9uIGRyYWZ0IHdlIHdhbnQgdG8gZGVzY3JpYmUgdGhl IHByb2JsZW1zIA0KaXRzZWxmLCBhbmQgdHJ5IHRvIGRpc2N1c3MgaXQgaW4gdGhlIFdHIGFuZCBt YWtlIGl0IGNsZWFyLiBUaGUgZGV0YWlsIA0KZGVzaWduIHdpbGwgZGVzY3JpYmUgaW4gdGhlIG5l eHQgdmVyc2lvbi4NCiANClJlZ2FyZHMmVGhhbmtzDQpaaGVuZw0KDQq3orz+yMs6IGRhaS54aWFu eGlhbkB6dGUuY29tLmNuIFtkYWkueGlhbnhpYW5AenRlLmNvbS5jbl0NCreiy83KsbzkOiAyMDE0 xOo31MI5yNUgMTc6MTMNCsrVvP7IyzogWmhlbmdndWFuZ3lpbmcNCrOty806IG5ldG1vZEBpZXRm Lm9yZzsgbmV0bW9kOyBZYW5nYW5nDQrW98ziOiC08Li0OiBbbmV0bW9kXSBGVzogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciANCmRyYWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3JhdGUtb3BlcmF0 aW9ucy0wMC50eHQNCg0KIEhpIFpoZW5nZ3Vhbmd5aW5nLCANCg0KICAgICAgICBBZnRlciByZWFk aW5nIHRoZSBkcmFmdCwgSSBoYXZlIHNvbWUgZG91YnRzLGNhbiB5b3UgYW5zd2VyIHRoZW0/IA0K DQogICAgICAgIDEuSW4gbXkgb3BpbmlvbiwgbWV0aG9kIGRlZmluZXMgbWV0aG9kIHJhdGhlciB0 aGFuIGRhdGEuSWYgdGhlIA0Kc2FtcGxlIHN1Y2NlZWRzLCB1c2VyIGdldHMgImFycExpc3QiIGRh dGEgYnkgPGdldC1jb25maWc+IG9wZXJhdGlvbiwgDQogICAgICAgIHRoZSByZXNwb25kaW5nIG1l c3NhZ2UgZGlzcGxheSBib3RoIHRoZSBzdGF0aWMgZGF0YSBhbmQgdGhlIG5ldyANCmRhdGEoZHlu YW1pYyBkYXRhKS5JcyBpdCByaWdodD8gRG9lcyBpdCBuZWVkIHRvIGNvbW1pdD8gDQogICAgICAg IEFmdGVyIHRoYXQsaWYgdXNlciBlZGl0cyB0aGUgbmV3ICJhcnBMaXN0IiBkYXRhIGJ5IDxlZGl0 LWNvbmZpZz4gDQpvcGVyYXRpb24saXMgdGhlIGR5bmFtaWMgZGF0YSBiZSBlZGl0ZWQgYXQgdGhl IHNhbWUgdGltZT8gDQogICAgICAgIElmIHRoZSBkeW5hbWljIGRhdGEgaXMgZGVsZXRlZCBmb3Ig c29tZSByZWFzb24sIHRoZSBuZXcgImFycExpc3QiIA0KZGF0YSBzdGlsbCBleGlzdD8gDQoNCiAg ICAgICAgMi5DYW4geW91IGRlc2NyaWJlIHRoZSBhdHRyaWJ1dGUgaW5mb3JtYXRpb24gb2YgdGhl IG1ldGhvZD8gDQogICAgICAgIERvZXMgdGhlIG1ldGhvZCBzdXBwb3J0ICJvdXRwdXQiIHN0YXRl bWVudD8gDQogICAgICAgIElzIHRoZSBjb25maWcgc3RhdGVtZW50IG9mIG5vZGUgbWVhbmluZ2xl c3M/IA0KDQogICAgICAgSSB0aGluayBpdCBpcyBiZXR0ZXIgYW5kIGNsZWFyZXIgdG8gZGVmaW5l IHRoZSBtZXRob2QgYnkgdXNpbmcgDQpZQU5HLiANCg0KDQpCZXN0IHJlZ2FyZHMhDQoNCg0KDQoN Cg0KWmhlbmdndWFuZ3lpbmcgPHpoZW5nZ3Vhbmd5aW5nQGh1YXdlaS5jb20+IA0Kt6K8/sjLOiAg Im5ldG1vZCIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPiANCjIwMTQtMDctMDQgMDg6MTMgDQoN Cg0KytW8/sjLDQoibmV0bW9kQGlldGYub3JnIiA8bmV0bW9kQGlldGYub3JnPiwgDQqzrcvNDQpZ YW5nYW5nIDx5YW5nYW5nQGh1YXdlaS5jb20+IA0K1vfM4g0KW25ldG1vZF0gRlc6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgDQpkcmFmdC16aGVuZy1uZXRtb2QtaW50ZWdyYXRlLW9wZXJh dGlvbnMtMDAudHh0DQoNCg0KDQoNCg0KDQoNCg0KSGkgYWxsIGluIE5ldG1vZCAsDQoNCiAgIElu IHNvbWUgZGF0YXN0b3JlIG9wZXJhdGlvbiBzY2VuYXJpb3MsIHRoZSBvcGVyYXRpb25zIHRyaWdn ZXJlZCBmcm9tIA0KdGhlICBORVRDT05GIGNsaWVudCBtaWdodCBiZSBhIHNldCBvZiBjb21iaW5l ZCBvcGVyYXRpb25zIG9yIGEgY29tcGxleCANCnNpbmdsZSBvcGVyYXRpb24gd2l0aGluIHRoZSBO RVRDT05GIGFnZW50LCB3aGljaCBtYXkgY2hhbmdlIHRoZSANCmRhdGFzdG9yZXMuIEFuZCAgc29t ZXRpbWVzIHRoZSBkYXRhc3RvcmUgY2hhbmdlIG1pZ2h0IG5vdCBiZSBmcm9tIGNsaWVudCANCmJ1 dCBmcm9tIHRoZSBhZ2VudCBpdHNlbGYuIFRoZXNlIG9wZXJhdGlvbnMgbmVlZCB0byBtYW5pcHVs YXRlIHRoZSBkYXRhIGluIA0KcnVubmluZyBkYXRhc3RvcmUgb3IgY2FuZGlkYXRlIGRhdGFzdG9y ZSwgYW5kIHRodXMgdGhleSBuZWVkIHRoZSANCjxlZGl0LWNvbmZpZz4gY2FwYWJpbGl0eSBhIHdl bGwgYXMgYSB1bmlmaWVkIGF1dGhvcml6YXRpb24gc3lzdGVtIHRvIA0KY29udHJvbCB0aGUgaW5m bHVlbmNlIHRvIHRoZSBkYXRhICAgc3RvcmVzIGNhdXNlZCBieSB0aGVtLg0KIFNvIHdlIHdyb3Rl IGEgZHJhZnQgdG8gdHJ5IHRvIG1ha2UgYSAgZGlzY3Vzc2lvbiBvZiB0aGUgaXNzdWUuIFRoZSBk cmFmdCANCmFuYWx5emVzIHRoZSBzY2VuYXJpbyBhbmQgcmVxdWlybWVudHMgZm9yIG1vZGVsIG9w ZXJhdGlvbnMsIGFuZCBicmllZmx5IA0KZGlzY3VzcyBzb21lIHBvc3NpYmxlIHNvbHV0aW9ucyB0 byBzYXRpc2Z5IHRoZSByZXF1aXJtZW50cy4NClBsZWFzZSByZXZpZXcgdGhlIGRyYWZ0IGFuZCBj b21tZW50Lg0KTWFueSB0aGFua3MhDQpCZXN0IHJlZ2FyZHMsDQpaaGVuZw0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW2ludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCreiy83KsbzkOiAyMDE0xOo31MIyyNUg MTc6NTQNCsrVvP7IyzogSml4aWFvZmVuZyAoU3RldmVuKTsgWmhlbmdndWFuZ3lpbmc7IEppeGlh b2ZlbmcgKFN0ZXZlbik7IA0KWmhlbmdndWFuZ3lpbmcNCtb3zOI6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgDQpkcmFmdC16aGVuZy1uZXRtb2QtaW50ZWdyYXRlLW9wZXJhdGlvbnMtMDAu dHh0DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC16aGVuZy1uZXRtb2QtaW50ZWdyYXRl LW9wZXJhdGlvbnMtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEd1 YW5neWluZyBaaGVuZyBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1l OiAgICAgICAgICAgZHJhZnQtemhlbmctbmV0bW9kLWludGVncmF0ZS1vcGVyYXRpb25zDQpSZXZp c2lvbjogICAgICAgMDANClRpdGxlOiAgICAgICAgICBJbnRlZ3JhdGluZyBPcGVyYXRpb25zIGlu IFlBTkcgTW9kZWxzDQpEb2N1bWVudCBkYXRlOiAgMjAxNC0wNy0wMg0KR3JvdXA6ICAgICAgICAg IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAgIDExDQpVUkw6ICAgICAgICAg ICAgDQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16aGVuZy1uZXRt b2QtaW50ZWdyYXRlLW9wZXJhdGlvbnMtMDAudHh0DQoNClN0YXR1czogICAgICAgICANCmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3JhdGUt b3BlcmF0aW9ucy8NCkh0bWxpemVkOiAgICAgICANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3JhdGUtb3BlcmF0aW9ucy0wMA0KDQoNCkFic3RyYWN0 Og0KICBUaGlzIGRvY3VtZW50IGludHJvZHVjZXMgYW4gZXh0ZW5zaW9uIHRvIFlBTkcuIFRoZSBl eHRlbnNpb24gYWxsb3dzDQogIG9wZXJhdGlvbiBtZXRob2RzIHRvIGJlIGRpcmVjdGx5IGludGVn cmF0ZWQgaW4gWUFORyBtb2RlbHMuDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRh a2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIA0Kc3VibWlzc2lvbg0KdW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p ZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXRfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQoNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gdGhpcyBtYWlsIA0KKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0 aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIA0KYW5kIGlzIGludGVuZGVkIGZvciB0 aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgDQph biBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3Ry aWJ1dGlvbiBvciBvdGhlciANCmRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gDQpJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyANCmlt bWVkaWF0ZWx5Lg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0 cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBp cyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElm IHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJv ZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90 aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQg dHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQg aXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJ ZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXBy b2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0 aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5v dGlmeSB1cyBpbW1lZGlhdGVseS4NCg== --=_alternative 002BAE0E48257D11_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFpoZW5nZ3Vhbmd5aW5nLCA8YnI+DQo8 YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SSB0aGluayBJIGhhdmUgdW5kZXJzdGFu ZCB5b3VyIGRlc2lnbg0KY29uY2VwdC4gVGhhbmsgeW91LjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEEN CnN1Z2dlc3Rpb246IGFzIG1ldGhvZCBpcyBkZWZpbmVkIGluIG1vZHVsZSBzdGF0ZW1lbnQsIHVz ZXJzIGNhbiBvbmx5IGNvbnZlcnQNCmR5bmFtaWMgZGF0YSBtb2R1bGUgYnkgbW9kdWxlLjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE1heWJlDQp5b3UgY2FuIGRlZmluZSBhbiBuZXcgb3Bl cmF0aW9uIHRvIGFjY29tcGxpc2ggYWxsIHRoZSBkeW5hbWljIGRhdGEgYmVjb21pbmcNCmNvbmZp Z3VyYXRpb24gZGF0YSw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBsaWtlDQomcXVvdDtjb3B5IGNvbmZpZyZxdW90 OyBvcGVyYXRpb24/PGJyPg0KPGJyPg0KPGJyPg0KQmVzdCByZWdhcmRzITwvZm9udD4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQgd2lkdGg9MzYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5aaGVuZ2d1YW5n eWluZyAmbHQ7emhlbmdndWFuZ3lpbmdAaHVhd2VpLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxNC0wNy0xMCAxNDoxMDwvZm9udD4NCjx0 ZCB3aWR0aD02MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtkYWku eGlhbnhpYW5AenRlLmNvbS5jbiZxdW90Ow0KJmx0O2RhaS54aWFueGlhbkB6dGUuY29tLmNuJmd0 OywgPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtuZXRtb2RAaWV0Zi5vcmcmcXVvdDsgJmx0O25l dG1vZEBpZXRmLm9yZyZndDssDQpuZXRtb2QgJmx0O25ldG1vZC1ib3VuY2VzQGlldGYub3JnJmd0 OywgWWFuZ2FuZyAmbHQ7eWFuZ2FuZ0BodWF3ZWkuY29tJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ tPC4tDogW25ldG1vZF0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbg0KZm9yIGRyYWZ0LXpo ZW5nLW5ldG1vZC1pbnRlZ3JhdGUtb3BlcmF0aW9ucy0wMC50eHQ8L2ZvbnQ+PC90YWJsZT4NCjxi cj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90 YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5IaSwgRGFp eGlhbnhpYW48YnI+DQogJm5ic3A7IDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGFuayB5 b3UgZm9yIHlvdXIgY29tbWVudHMgZmlyc3RseS4gSSB0cnkgdG8gYW5zd2VyDQp5b3VyIGNvbW1l bnRzIGhlcmUsIHBsZWFzZSBjaGVjayBteSBkb3VidCwgdGhhbmtzLjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iVGFob21hIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZn dDsxLkluDQpteSBvcGluaW9uLCBtZXRob2QgZGVmaW5lcyBtZXRob2QgcmF0aGVyIHRoYW4gZGF0 YS5JZiB0aGUgc2FtcGxlIHN1Y2NlZWRzLA0KdXNlciBnZXRzICZxdW90O2FycExpc3QmcXVvdDsg ZGF0YSBieSAmbHQ7Z2V0LWNvbmZpZyZndDsgb3BlcmF0aW9uLCA8YnI+DQogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7dGhlIHJlc3BvbmRpbmcgbWVzc2FnZSBkaXNwbGF5IGJvdGggdGhlIHN0 YXRpYw0KZGF0YSBhbmQgdGhlIG5ldyBkYXRhKGR5bmFtaWMgZGF0YSkuSXMgaXQgcmlnaHQ/IERv ZXMgaXQgbmVlZCB0byBjb21taXQ/DQo8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1poZW5nOiBSaWdodCwgaWYgc3VjY2Vl ZCwgdGhlIGR5bmFtaWMgZGF0YQ0Kd2lsbCBiZWNvbWUgY29uZmlndXJhdGlvbiBkYXRhIGFuZCBp dCB3aWxsIGluIHRoZSAmbmJzcDsmbHQ7Z2V0LWNvbmZpZyZndDsNClJQQyByZXBseSBkYXRhLiA8 YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IElm IGRlZmluZSBuZXcgbm9uLXN0YW5kYXJkDQpSUEMsIGRvIHlvdSB0aGluayBpdCBuZWVkIGEgc3Bl cmF0ZSBjb21taXQgb3BlcmF0aW9uIG9yIGNvbW1pdCBpdCBpbnRlcm5hbGx5DQpjb21iaW5lIHdp dGggdGhlIG5ldyBkZWZpbmVkIFJQQz88YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8 YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZndDtBZnRlciB0aGF0LGlmIHVz ZXIgZWRpdHMgdGhlIG5ldyAmcXVvdDthcnBMaXN0JnF1b3Q7DQpkYXRhIGJ5ICZsdDtlZGl0LWNv bmZpZyZndDsgb3BlcmF0aW9uLGlzIHRoZSBkeW5hbWljIGRhdGEgYmUgZWRpdGVkIGF0DQp0aGUg c2FtZSB0aW1lPyA8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SWYgdGhlIGR5bmFt aWMgZGF0YSBpcyBkZWxldGVkIGZvciBzb21lIHJlYXNvbiwNCnRoZSBuZXcgJnF1b3Q7YXJwTGlz dCZxdW90OyBkYXRhIHN0aWxsIGV4aXN0PyA8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Wmhlbmc6IEFmdGVyIGNvbnZlcnQgdGhlIGR5bmFtaWMgZGF0YSB0byBjb25maWd1cmF0aW9u DQpkYXRhLCB0aGUgb3JpZ25hbCBkeW5hbWljIGRhdGEgd2lsbCBiZSBkZWxldGVkLjxicj4NCiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IlRhaG9tYSI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmZ3Q7Mi5DYW4NCnlvdSBk ZXNjcmliZSB0aGUgYXR0cmlidXRlIGluZm9ybWF0aW9uIG9mIHRoZSBtZXRob2Q/IDxicj4NCiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtEb2VzIHRoZSBtZXRob2Qgc3VwcG9ydCAmcXVvdDtv dXRwdXQmcXVvdDsNCnN0YXRlbWVudD8gPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O0lzIHRoZSBjb25maWcgc3RhdGVtZW50IG9mIG5vZGUgbWVhbmluZ2xlc3M/PGJyPg0KICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO1poZW5no7pJbiB0aGlzIHZlcnNpb24gZHJhZnQgd2Ugd2Fu dCB0byBkZXNjcmliZQ0KdGhlIHByb2JsZW1zIGl0c2VsZiwgYW5kIHRyeSB0byBkaXNjdXNzIGl0 IGluIHRoZSBXRyBhbmQgbWFrZSBpdCBjbGVhci4NClRoZSBkZXRhaWwgZGVzaWduIHdpbGwgZGVz Y3JpYmUgaW4gdGhlIG5leHQgdmVyc2lvbi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IlRhaG9tYSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPlJl Z2FyZHMmYW1wO1RoYW5rczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5a aGVuZzwvZm9udD4NCjxwPg0KPGhyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxi PreivP7Iyzo8L2I+IGRhaS54aWFueGlhbkB6dGUuY29tLmNuDQpbZGFpLnhpYW54aWFuQHp0ZS5j b20uY25dPGI+PGJyPg0Kt6LLzcqxvOQ6PC9iPiAyMDE0xOo31MI5yNUgMTc6MTM8Yj48YnI+DQrK 1bz+yMs6PC9iPiBaaGVuZ2d1YW5neWluZzxiPjxicj4NCrOty806PC9iPiBuZXRtb2RAaWV0Zi5v cmc7IG5ldG1vZDsgWWFuZ2FuZzxiPjxicj4NCtb3zOI6PC9iPiC08Li0OiBbbmV0bW9kXSBGVzog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC16aGVuZy1uZXRtb2QtaW50ZWdyYXRl LW9wZXJhdGlvbnMtMDAudHh0PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJSb21hbiI+PGJyPg0K PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDtIaSBaaGVu Z2d1YW5neWluZyw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlJvbWFuIj4NCjxicj4NCjwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO0FmdGVyIHJlYWRpbmcgdGhlIGRyYWZ0LCBJIGhhdmUgc29tZSBkb3VidHMsY2Fu DQp5b3UgYW5zd2VyIHRoZW0/PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJSb21hbiI+IDxicj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOzEuSW4gbXkgb3BpbmlvbiwgbWV0aG9kIGRlZmluZXMgbWV0aG9kIHJh dGhlcg0KdGhhbiBkYXRhLklmIHRoZSBzYW1wbGUgc3VjY2VlZHMsIHVzZXIgZ2V0cyAmcXVvdDth cnBMaXN0JnF1b3Q7IGRhdGEgYnkNCiZsdDtnZXQtY29uZmlnJmd0OyBvcGVyYXRpb24sIDxicj4N CiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGUgcmVzcG9uZGluZyBtZXNzYWdlIGRpc3Bs YXkgYm90aCB0aGUgc3RhdGljDQpkYXRhIGFuZCB0aGUgbmV3IGRhdGEoZHluYW1pYyBkYXRhKS5J cyBpdCByaWdodD8gRG9lcyBpdCBuZWVkIHRvIGNvbW1pdD88L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9IlJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0K ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0FmdGVyIHRoYXQsaWYgdXNlciBlZGl0cyB0aGUg bmV3ICZxdW90O2FycExpc3QmcXVvdDsNCmRhdGEgYnkgJmx0O2VkaXQtY29uZmlnJmd0OyBvcGVy YXRpb24saXMgdGhlIGR5bmFtaWMgZGF0YSBiZSBlZGl0ZWQgYXQNCnRoZSBzYW1lIHRpbWU/PC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJSb21hbiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lmIHRoZSBkeW5h bWljIGRhdGEgaXMgZGVsZXRlZCBmb3Igc29tZSByZWFzb24sDQp0aGUgbmV3ICZxdW90O2FycExp c3QmcXVvdDsgZGF0YSBzdGlsbCBleGlzdD88L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlJvbWFu Ij4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzIuQ2FuIHlvdSBkZXNjcmliZSB0aGUgYXR0cmlidXRl IGluZm9ybWF0aW9uDQpvZiB0aGUgbWV0aG9kPzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iUm9t YW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtEb2VzIHRoZSBtZXRob2Qgc3VwcG9ydCAmcXVvdDtvdXRwdXQm cXVvdDsNCnN0YXRlbWVudD8gPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lzIHRo ZSBjb25maWcgc3RhdGVtZW50IG9mIG5vZGUgbWVhbmluZ2xlc3M/PC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJSb21hbiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJIHRoaW5rIGl0IGlzIGJldHRlciBhbmQg Y2xlYXJlciB0byBkZWZpbmUgdGhlIG1ldGhvZA0KYnkgdXNpbmcgWUFORy4gPGJyPg0KPGJyPg0K PGJyPg0KQmVzdCByZWdhcmRzITxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i Um9tYW4iPjxicj4NCjxicj4NCjxicj4NCjwvZm9udD4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzQlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij48Yj5aaGVuZ2d1YW5neWluZyAmbHQ7emhlbmdndWFuZ3lpbmdAaHVhd2VpLmNvbSZndDs8L2I+ DQo8YnI+DQq3orz+yMs6ICZuYnNwOyZxdW90O25ldG1vZCZxdW90OyAmbHQ7bmV0bW9kLWJvdW5j ZXNAaWV0Zi5vcmcmZ3Q7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxNC0wNy0wNCAwODox MzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dGQgd2lk dGg9NjUlPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3 aWR0aD02JT4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZCB3aWR0aD05MyU+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPiZxdW90O25ldG1vZEBpZXRmLm9yZyZxdW90Ow0KJmx0O25ldG1vZEBpZXRmLm9y ZyZndDssIDwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+WWFuZ2FuZyAmbHQ7eWFuZ2FuZ0BodWF3ZWkuY29t Jmd0OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPltuZXRtb2RdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24NCmZvciBkcmFmdC16 aGVuZy1uZXRtb2QtaW50ZWdyYXRlLW9wZXJhdGlvbnMtMDAudHh0PC9mb250PjwvdGFibGU+DQo8 YnI+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0K PGJyPjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlJvbWFuIj48YnI+DQo8YnI+DQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGJyPg0KSGkgYWxsIGluIE5ldG1vZCAs PGJyPg0KPGJyPg0KICZuYnNwOyBJbiBzb21lIGRhdGFzdG9yZSBvcGVyYXRpb24gc2NlbmFyaW9z LCB0aGUgb3BlcmF0aW9ucyB0cmlnZ2VyZWQNCmZyb20gdGhlICZuYnNwO05FVENPTkYgY2xpZW50 IG1pZ2h0IGJlIGEgc2V0IG9mIGNvbWJpbmVkIG9wZXJhdGlvbnMgb3INCmEgY29tcGxleCBzaW5n bGUgb3BlcmF0aW9uIHdpdGhpbiB0aGUgTkVUQ09ORiBhZ2VudCwgd2hpY2ggbWF5IGNoYW5nZSB0 aGUNCmRhdGFzdG9yZXMuIEFuZCAmbmJzcDtzb21ldGltZXMgdGhlIGRhdGFzdG9yZSBjaGFuZ2Ug bWlnaHQgbm90IGJlIGZyb20NCmNsaWVudCBidXQgZnJvbSB0aGUgYWdlbnQgaXRzZWxmLiBUaGVz ZSBvcGVyYXRpb25zIG5lZWQgdG8gbWFuaXB1bGF0ZSB0aGUNCmRhdGEgaW4gcnVubmluZyBkYXRh c3RvcmUgb3IgY2FuZGlkYXRlIGRhdGFzdG9yZSwgYW5kIHRodXMgdGhleSBuZWVkIHRoZQ0KJmx0 O2VkaXQtY29uZmlnJmd0OyBjYXBhYmlsaXR5IGEgd2VsbCBhcyBhIHVuaWZpZWQgYXV0aG9yaXph dGlvbiBzeXN0ZW0NCnRvIGNvbnRyb2wgdGhlIGluZmx1ZW5jZSB0byB0aGUgZGF0YSAmbmJzcDsg c3RvcmVzIGNhdXNlZCBieSB0aGVtLjxicj4NCiBTbyB3ZSB3cm90ZSBhIGRyYWZ0IHRvIHRyeSB0 byBtYWtlIGEgJm5ic3A7ZGlzY3Vzc2lvbiBvZiB0aGUgaXNzdWUuIFRoZQ0KZHJhZnQgYW5hbHl6 ZXMgdGhlIHNjZW5hcmlvIGFuZCByZXF1aXJtZW50cyBmb3IgbW9kZWwgb3BlcmF0aW9ucywgYW5k IGJyaWVmbHkNCmRpc2N1c3Mgc29tZSBwb3NzaWJsZSBzb2x1dGlvbnMgdG8gc2F0aXNmeSB0aGUg cmVxdWlybWVudHMuPGJyPg0KUGxlYXNlIHJldmlldyB0aGUgZHJhZnQgYW5kIGNvbW1lbnQuPGJy Pg0KTWFueSB0aGFua3MhPGJyPg0KQmVzdCByZWdhcmRzLDxicj4NClpoZW5nPGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCreivP7IyzogaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnIFtpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddPGJyPg0Kt6LLzcqxvOQ6 IDIwMTTE6jfUwjLI1SAxNzo1NDxicj4NCsrVvP7IyzogSml4aWFvZmVuZyAoU3RldmVuKTsgWmhl bmdndWFuZ3lpbmc7IEppeGlhb2ZlbmcgKFN0ZXZlbik7IFpoZW5nZ3Vhbmd5aW5nPGJyPg0K1vfM 4jogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC16aGVuZy1uZXRtb2QtaW50ZWdy YXRlLW9wZXJhdGlvbnMtMDAudHh0PGJyPg0KPGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3JhdGUtb3BlcmF0aW9ucy0wMC50eHQ8YnI+DQpoYXMgYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEd1YW5neWluZyBaaGVuZyBhbmQgcG9zdGVkIHRv IHRoZTxicj4NCklFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRyYWZ0LXpoZW5nLW5ldG1vZC1pbnRlZ3JhdGUtb3BlcmF0 aW9uczxicj4NClJldmlzaW9uOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAwMDxicj4NClRpdGxlOiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW50ZWdyYXRpbmcgT3BlcmF0aW9ucyBp biBZQU5HDQpNb2RlbHM8YnI+DQpEb2N1bWVudCBkYXRlOiAmbmJzcDsyMDE0LTA3LTAyPGJyPg0K R3JvdXA6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJbmRpdmlkdWFsIFN1Ym1p c3Npb248YnI+DQpQYWdlczogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzExPGJy Pg0KVVJMOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvZm9udD48 YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16aGVuZy1u ZXRtb2QtaW50ZWdyYXRlLW9wZXJhdGlvbnMtMDAudHh0IiB0YXJnZXQ9X2JsYW5rPjxmb250IHNp emU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtemhlbmctbmV0bW9kLWludGVncmF0ZS1vcGVyYXRpb25zLTAwLnR4 dDwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxicj4NClN0YXR1czog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvZm9udD48YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGVuZy1uZXRtb2QtaW50ZWdyYXRlLW9wZXJhdGlv bnMvIiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+ PHU+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhlbmctbmV0bW9kLWlu dGVncmF0ZS1vcGVyYXRpb25zLzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhv bWEiPjxicj4NCkh0bWxpemVkOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L2ZvbnQ+PGEgaHJlZj0i aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhlbmctbmV0bW9kLWludGVncmF0ZS1v cGVyYXRpb25zLTAwIiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9 IlRhaG9tYSI+PHU+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhlbmctbmV0bW9k LWludGVncmF0ZS1vcGVyYXRpb25zLTAwPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9 IlRhaG9tYSI+PGJyPg0KPGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KICZuYnNwO1RoaXMgZG9j dW1lbnQgaW50cm9kdWNlcyBhbiBleHRlbnNpb24gdG8gWUFORy4gVGhlIGV4dGVuc2lvbiBhbGxv d3M8YnI+DQogJm5ic3A7b3BlcmF0aW9uIG1ldGhvZHMgdG8gYmUgZGlyZWN0bHkgaW50ZWdyYXRl ZCBpbiBZQU5HIG1vZGVscy48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2Ugbm90 ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBz dWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNyZXRhcmlh dDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iUm9tYW4iPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCm5l dG1vZEBpZXRmLm9yZzwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJSb21hbiI+ PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0bW9kIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFj ZT0iUm9tYW4iPjx1Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9k PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9IlJvbWFuIj48YnI+DQo8YnI+DQo8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iUm9tYW4iPjxicj4NCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0K WlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIG1haWwNCihhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgp IGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbA0KYW5kIGlzIGludGVuZGVkIGZvciB0aGUg ZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAmbmJzcDtJZiB5b3UNCmFyZSBub3Qg YW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0 cmlidXRpb24NCm9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaXMgc3RyaWN0bHkNCnByb2hpYml0ZWQuICZuYnNwO0lmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZQ0KaXQgYW5kIG5vdGlmeSB1 cyBpbW1lZGlhdGVseS48YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQoNCjxicj48cHJl Pjxmb250IGNvbG9yPSJibHVlIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBU aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50 IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5k IGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAg SWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVw cm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2Yg dGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBu b3RpZnkgdXMgaW1tZWRpYXRlbHkuDQoNCjwvZm9udD48L3ByZT48YnI+DQoNCjxicj48cHJlPjxm b250IGNvbG9yPSJibHVlIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRy YW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlz IGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYg eW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9k dWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3Rp ZnkgdXMgaW1tZWRpYXRlbHkuDQoNCjwvZm9udD48L3ByZT48YnI+DQo= --=_alternative 002BAE0E48257D11_=-- From nobody Thu Jul 10 06:17:08 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280C21B289E; Thu, 10 Jul 2014 06:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.363 X-Spam-Level: X-Spam-Status: No, score=-112.363 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uflrtYMWvBLe; Thu, 10 Jul 2014 06:17:03 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C5C51A01CA; Thu, 10 Jul 2014 06:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7402; q=dns/txt; s=iport; t=1404998226; x=1406207826; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tjQ8yhYXe5FDUsjno/cUyQUZLfOi+1T67af9okBpeww=; b=Cv6IlNcGtb9k2vuKSa/5cd/bhEWkAo38ncM6nRMbr5mY8uPAmaG0fP7v pInR9YM8hDb4/K4O34iQM7WmmVf8mpSlja5mq+TahV3VvaQMh4fI4wS7j rGSOlYbYoCDoDltHt1uk66F2tVzGhbvFRtSf3pkd2eHW+5D8xTSNO899U s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FADORvlOtJA2E/2dsb2JhbABPCoJqJIEsgm/DfwEZchZ1hAMBAQEENDEUDAQCAQYCDgMEAQEFBh0FAgIwFAkIAQEEAQ0FCIg6AZIynCEImRgXgSiNQCsxBwaCbTqBFgEErxWDQ4Iw X-IronPort-AV: E=Sophos;i="5.01,637,1400025600"; d="scan'208";a="59762749" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP; 10 Jul 2014 13:17:06 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6ADH2LI007090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Jul 2014 13:17:02 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Thu, 10 Jul 2014 08:17:01 -0500 From: "Nobo Akiya (nobo)" To: Qin Wu , "Tissa Senevirathne (tsenevir)" Thread-Topic: Comments on draft-tissa-netmod-oam-01 Thread-Index: Ac+XqFYxYsJYmgtCT72I7Nhf1mmspQDA2OqgAGTQxQA= Date: Thu, 10 Jul 2014 13:17:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/F7ryFycWiEa1GS9KIBij_JGBiXM Cc: "time@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Comments on draft-tissa-netmod-oam-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 13:17:05 -0000 SGkgUWluLA0KDQpQbGVhc2Ugc2VlIGluLWxpbmUgd2l0aCBbTk9CT10uDQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUWluIFd1IFttYWlsdG86YmlsbC53dUBodWF3ZWku Y29tXQ0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDA4LCAyMDE0IDk6MTAgQU0NCj4gVG86IE5vYm8g QWtpeWEgKG5vYm8pOyBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKQ0KPiBDYzogbmV0bW9k QGlldGYub3JnOyB0aW1lQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBDb21tZW50cyBvbiBkcmFm dC10aXNzYS1uZXRtb2Qtb2FtLTAxDQo+IA0KPiBTb3JyeSB0byBjaGltZSBpbi4NCj4gU2VlIHNv bWUgY29tbWVudHMgaW5saW5lIGJlbG93Lg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPreivP7I yzogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gTm9ibyBBa2l5 YQ0KPiAobm9ibykNCj4gPreiy83KsbzkOiAyMDE0xOo31MI1yNUgMTowOQ0KPiA+ytW8/sjLOiBU aXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKQ0KPiA+s63LzTogbmV0bW9kQGlldGYub3JnDQo+ ID7W98ziOiBbbmV0bW9kXSBDb21tZW50cyBvbiBkcmFmdC10aXNzYS1uZXRtb2Qtb2FtLTAxDQo+ IA0KPiA+SGkgVGlzc2EsIGF1dGhvcnMsDQo+IA0KPiA+Rmlyc3Qgb2YgYWxsLCBpbnRlbnQgb2Yg dGhpcyBkb2N1bWVudCBzZWVtcyB3aWRlbHkgYmVuZWZpY2lhbC4gSSBhbQ0KPiBpbnRlcmVzdGVk IHRvIHNlZSBob3cgYW5kIEluIHdoYXQgZm9ybSB0aGlzIGRvY3VtZW50IHdpbGwgcHJvZ3Jlc3Mu DQo+IA0KPiA+UGxlYXNlIGZpbmQgYmVsb3cgZmV3IGNvbW1lbnRzIEkgaGF2ZSBvbiB0aGUgZHJh ZnQtdGlzc2EtbmV0bW9kLW9hbS0wMSwNCj4gZnJvbSBhIHF1aWNrIGxvb2sgYXQgdGhlIGRvY3Vt ZW50Lg0KPiANCj4gDQo+ID5Db21tZW50ICMxOiBTZWN0aW9uIDYNCj4gDQo+ID4gW3NuaXBdDQo+ ID4gICAgIHR5cGVkZWYgQ0NNLUludGVydmFsIHsNCj4gPiAgICAgICBkZWZhdWx0ICJpbnRlcnZh bC0xbWluIjsNCj4gPiAgICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCj4gPiAgICAgICAgIGVudW0g ImludGVydmFsLWludmFsaWQiIHsNCj4gPiAgICAgICAgICAgdmFsdWUgMDsNCj4gPiAgICAgICAg IH0NCj4gICAgICAgICAgLi4uDQo+ID4gICAgICAgICBlbnVtICJpbnRlcnZhbC0xMG1pbiIgew0K PiA+ICAgICAgICAgICB2YWx1ZSA3Ow0KPiA+ICAgICAgICAgfQ0KPiA+ICAgICAgfQ0KPiAgICAg ICAgLi4uDQo+ID4gICAgIH0NCj4gPiBbc25pcF0NCj4gDQo+ID5XaGVuIGNvbnNpZGVyaW5nIGFs bCBPQU0gdG9vbHMgb3V0IHRoZXJlLCBkZWZpbmluZyBhIGhhcmQgY29kZWQgc2V0IG9mDQo+ID5p bnRlcnZhbHMgKHZpYSBlbnVtKSBtYXkgbm90IGJlIGEgZ29vZCBpZGVhLiBCRkQgaW1wbGVtZW50 YXRpb25zDQo+ID4oU1cvSFcpIHNwcmluZ3MgdG8gbXkgbWluZCBpbW1lZGlhdGVseS4gRm9yIEhX IGJhc2VkIEJGRCwgQkZEIFdHIGlzDQo+ID53b3JraW5nIG9uIGFuIGluZm9ybWF0aW9uYWwgZG9j dW1lbnQgZm9yIHJlY29tbWVuZGVkIHNldCBvZiBpbnRlcnZhbHM6DQo+IGRyYWZ0LWlldGYtYmZk LWludGVydmFscy4gSG93ZXZlciwgaW50ZXJ2YWxzIG91dHNpZGUgb2YgdGhhdCBzZXQgY2FuIHN0 aWxsIGJlDQo+IGltcGxlbWVudGVkIGJ5IHZlbmRvcnMgZm9yIEhXIGJhc2VkIEJGRC4gU1cgYmFz ZWQgQkZELCBvYnZpb3VzbHksIGhhcw0KPiBtdWNoIG1vcmUgZmxleGliaWxpdHkgaW4gdGhlIHJh bmdlIG9mIGludGVydmFscyB0byB1c2UuIEEgYmV0dGVyIGFwcHJvYWNoDQo+IG1heSBiZSB0byBj aGFuZ2UgYWJvdmUgZnJvbSBlbnVtIHRvIGlkZW50aWZ5IHJlZiAob3Igc29tZXRoaW5nIGVsc2Up DQo+IHdoaWNoIGNhbiBiZSBhdWdtZW50ZWQuDQo+IA0KPiANCj4gPkNvbW1lbnQgIzI6IFNlY3Rp b24gNg0KPiANCj4gPiBbc25pcF0NCj4gPiAgICAgdHlwZWRlZiBlY21wLWNob2ljZXMgew0KPiA+ ICAgICAgIHR5cGUgZW51bWVyYXRpb24gew0KPiA+ICAgICAgICAgZW51bSAiZWNtcC11c2UtcGxh dGZvcm0taGFzaCIgew0KPiA+ICAgICAgICAgICB2YWx1ZSAwOw0KPiA+ICAgICAgICAgfQ0KPiA+ ICAgICAgICAgZW51bSAiZWNtcC11c2Utcm91bmQtcm9iaW4iIHsNCj4gPiAgICAgICAgICAgdmFs dWUgMTsNCj4gPiAgICAgICAgIH0NCj4gPiAgICAgICB9DQo+ID4gICAgIH0NCj4gPiBbc25pcF0N Cj4gPiAgICAgICAgICAgICAgICAgbGVhZiBlY21wLWNob2ljZSB7DQo+ID4gICAgICAgICAgICAg ICAgICAgY29uZmlnIHRydWU7DQo+ID4gICAgICAgICAgICAgICAgICAgdHlwZSBlY21wLWNob2lj ZXM7DQo+ID4gICAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24NCj4gPiAgICAgICAgICAgICAg ICAgICAgICIwIG1lYW5zIHVzZSB0aGUgc3BlY2lmaWVkIGludGVyZmFjZQ0KPiA+ICAgICAgICAg ICAgICAgICAgICAgIDEgbWVhbnMgdXNlIHJvdW5kIHJvYmluIjsNCj4gPiAgICAgICAgICAgICAg ICAgfQ0KPiA+IFtzbmlwXQ0KPiANCj4gPkFib3ZlIHR3byBzZWVtcyBhIGJpdCBjb25mbGljdGlu ZyBmb3IgdGhlIHZhbHVlIG9mIHplcm8oMCkuIEZvcm1lciBzdGF0ZXMNCj4gdGhhdCB6ZXJvKDAp IGluZGljYXRlcyB1c2FnZSBvZiBwbGF0Zm9ybSBoYXNoIGJ1dCB0aGUgbGF0dGVyIGluZGljYXRl cyB0aGF0DQo+IHNwZWNpZmljIGludGVyZmFjZSBpcyB1c2VkIChpLmUuIG5vdCBoYXNoZWQ/KS4g PlRoaW5raW5nIGFib3V0IHRoaXMsIEkgYmVsaWV2ZQ0KPiAiZWNtcC1jaG9pY2VzIiBpcyBvdmVy bG9hZGVkLiBZb3UgYWN0dWFsbHkgd2FudCB0byBiZSBhYmxlIHRvIGRlc2NyaWJlIDMNCj4gZGlm ZmVyZW50IHRoaW5ncyBoZXJlLg0KPiANCj4gPjEuIENvbmZpZ3VyaW5nIGEgc3BlY2lmaWMgbG9h ZCBiYWxhbmNpbmcgdGVjaG5pcXVlIG9uIGEgc3lzdGVtIChleDogRUwsDQo+IHJvdW5kLXJvYmlu IG9yIHNvbWV0aGluZyBlbHNlKS4NCj4gDQo+IFtRaW5dOiBhcmUgeW91IHByb3Bvc2luZyB0byBy ZXBsYWNlIGVjbXAtdXNlLXBsYXRmb3JtLWhhc2ggd2l0aCBFTCBhbmQNCj4gaGF2ZSB0aGUgZm9s bG93aW5nIGNoYW5nZSB0byBlY21wLWNob2ljZXMgdHlwZGVmIE5FVyBURVhUOg0KDQpbTk9CT10g V2Ugc2hvdWxkIHByb2JhYmx5IHRha2UgYSBzdGVwIGJhY2ssIGFuZCBkZWNpZGUgaWYgY29uZmln dXJpbmcgbG9hZCBiYWxhbmNpbmcgYmVoYXZpb3JzIG9uIHN5c3RlbXMgaXMgc29tZXRoaW5nIHRo YXQgYmVsb25ncyB3aXRoaW4gZHJhZnQtdGlzc2EtbmV0bW9kLW9hbSBvciBub3QuDQoNCj4gIg0K PiAgICAgIHR5cGVkZWYgZWNtcC1jaG9pY2VzIHsNCj4gICAgICAgIHR5cGUgZW51bWVyYXRpb24g ew0KPiAgICAgICAgICBlbnVtICJFbnRyb3B5IExhYmxlIiB7DQo+ICAgICAgICAgICAgdmFsdWUg MDsNCj4gICAgICAgICAgfQ0KPiAgICAgICAgICBlbnVtICJlY21wLXVzZS1yb3VuZC1yb2JpbiIg ew0KPiAgICAgICAgICAgIHZhbHVlIDE7DQo+ICAgICAgICAgIH0NCj4gICAgICAgIH0NCj4gICAg ICB9DQo+ICINCj4gSG93ZXZlciBkcmFmdC10aXNzYSBhbHNvIGhhcyBmbG93LWVudHJvcHkgZ3Jv dXBpbmcgdG8gYmUgZGVmaW5lZCAiDQo+ICAgICAgZ3JvdXBpbmcgZmxvdy1lbnRyb3B5IHsNCj4g ICAgICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgICAgICJkZWZpbmVzIHRoZSBncm91cGluZyBzdGF0 ZW1lbnQgZm9yIGZsb3ctZW50cm9weSI7DQo+ICAgICAgICBjaG9pY2UgZmxvdy1lbnRyb3B5IHsN Cj4gICAgICAgICAgY2FzZSBmbG93LWVudHJvcHktbnVsbDsNCj4gICAgICAgIH0NCj4gICAgICB9 DQo+ICINCj4gV2hpY2ggbWFrZSBtZSBkaWZmaWN1bHQgdG8gdW5kZXJzdGFuZCBob3cgZmxvdy1l bnRyb3B5IGdyb3VwaW5nIGlzDQo+IHJlbGF0ZWQgdG8gZWNtcC1jaG9pY2VzDQo+IA0KPiA+Mi4g RGVzY3JpYmluZyB0aGUgb3V0cHV0IGJlaGF2aW9yIG9uIHRoZSBPQU0gaW5zdGFuY2UgKGV4OiBv dXQgdG8gc3BlY2lmaWMNCj4gaW50ZXJmYWNlIHZzLiBsb2FkIGJhbGFuY2VkKS4NCj4gDQo+IFtR aW5dOiBJIGFtIHdvbmRlcmluZyB3aHkgbm90IGNvbnNpZGVyIGlucHV0IGJlaGF2aW9yIG9yIGlu cHV0IGtleSB0byBsb2FkDQo+IGJhbGFuY2luZyB0ZWNobmlxdWUuDQoNCltOT0JPXSBUaGUgZ29h bCBoZXJlIGlzIHRvIGRlc2NyaWJlIGhvdyBPQU0gcGFja2V0cyBhcmUgc2VudCBmcm9tIHRoZSBz eXN0ZW0sIHNvIGl0J3Mgbm90IHRoYXQgaW5wdXQgYmVoYXZpb3IgYnV0IGl0J3MgdGhlIG91dHB1 dCBiZWhhdmlvciB0aGF0IHdlIG5lZWQgdG8gZGVzY3JpYmUuIEFkZGl0aW9uYWxseSwgaWYgdGhl IE9BTSBwYWNrZXQgaXMgdG8gZ2V0IGxvYWQgYmFsYW5jZWQgb3V0IGZyb20gdGhlIHN5c3RlbSwg dGhlbiB0aGUgZmllbGRzIGZyb20gdGhlIHBhY2tldCBjb250ZW50cyBzaG91bGQgYmUgdXNlZCBm b3IgbG9hZCBiYWxhbmNpbmcsIGFuZCBub3QgYSBzZXBhcmF0ZSBpbnB1dCBrZXkuIFdlIHdpbGwg bmVlZCB0byBzZXQgY2VydGFpbiBmaWVsZHMgb2YgdGhlIE9BTSBwYWNrZXRzIChleDogRUwgdmFs dWUsIElQIGFkZHJlc3MsIHBvcnQpLCBzbyBpZiB5b3UgbWVhbnQgImlucHV0IGtleSIgdG8gc2V0 IHRob3NlIGZpZWxkcywgdGhlbiBJIGFncmVlLg0KDQo+IA0KPiA+My4gRGVzY3JpYmUgdGhlIHNl dHRpbmcgb24gdGhlIHBhdGggZGlzY292ZXJ5IE9BTSBpbnN0YW5jZSAoZXg6IExTUCB0cmVlDQo+ IHRyYWNlIHVzaW5nIG11bHRpcGF0aCAyLCA0LCA4LCA5LCAxMCkuDQo+IA0KPiBbUWluXTogSXMg dGhpcyBzZXR0aW5nIG9uIHBhdGggZGlzY292ZXJ5IE9BTSBpbnN0YW5jZSBjb21tb24gc2V0dGlu Zz8gT3INCj4gZGlmZmVyZW50IE9BTSB0b29sIGhhdmUgZGlmZmVyZW50IHNldHRpbmcgZm9yIHBh dGggZGlzY292ZXJ5IG1lY2hhbmlzbS4NCj4gT3IgeW91IGFyZSBqdXN0IHRhbGtpbmcgYWJvdXQg ZGlmZmVyZW50IHBhdGggaGF2ZSBkaWZmZXJlbnQgc2V0dGluZz8NCj4gSSBhbSB0cnlpbmcgdG8g dW5kZXJzdGFuZCB0aGlzLg0KDQpbTk9CT10gUHJvYmFibHkgYm90aC4gQXQgbGVhc3Qgd2l0aCBS RkM0Mzc5LCBpdCBpcyBvbmUgbWVjaGFuaXNtIGJ1dCBhbGxvd3MgbXVsdGlwbGUgcGF0aCBkaXNj b3ZlcnkgdGVjaG5pcXVlcyB3aXRoaW4gaXQuDQoNCj4gDQo+ID5QZXJoYXBzIGEgZGlmZmVyZW50 IG9iamVjdCBmb3IgZWFjaCBtYXkgYmUgYSBnb29kIGlkZWEuICgyKSBjYW4gYmUgYW4NCj4gPmVu dW0NCj4gDQo+ID5idXQgaXQnbGwgYmUgYmVuZWZpY2lhbCB0byBiZSBhYmxlIGZvciB2YXJpb3Vz IE9BTSB0b29scyB0byBhdWdtZW50ICgxKSBhbmQNCj4gKDMpLg0KPiANCj4gW1Fpbl06IEkgdGVu ZCB0byBhZ3JlZSB3aXRoIHRoaXMuDQoNCjopDQoNClRoYW5rcyENCg0KLU5vYm8NCg== From nobody Thu Jul 10 06:26:46 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34F21B28F1; Thu, 10 Jul 2014 06:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dm_vIAjDNKfs; Thu, 10 Jul 2014 06:26:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B1BE1B28F8; Thu, 10 Jul 2014 06:26:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGZ40168; Thu, 10 Jul 2014 13:26:40 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 10 Jul 2014 14:26:39 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Thu, 10 Jul 2014 21:26:33 +0800 From: Qin Wu To: "Nobo Akiya (nobo)" , "Tissa Senevirathne (tsenevir)" Thread-Topic: Comments on draft-tissa-netmod-oam-01 Thread-Index: Ac+XqFYxYsJYmgtCT72I7Nhf1mmspQDA2OqgAGTQxQAAAM+AMA== Date: Thu, 10 Jul 2014 13:26:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/I6xz7FSWy9Z5wTbX-qgGK7jaBKw Cc: "time@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] Comments on draft-tissa-netmod-oam-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 13:26:45 -0000 LS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IE5vYm8gQWtpeWEgKG5vYm8pIFttYWlsdG86bm9i b0BjaXNjby5jb21dIA0Kt6LLzcqxvOQ6IDIwMTTE6jfUwjEwyNUgMjE6MTcNCsrVvP7IyzogUWlu IFd1OyBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKQ0Ks63LzTogbmV0bW9kQGlldGYub3Jn OyB0aW1lQGlldGYub3JnDQrW98ziOiBSRTogQ29tbWVudHMgb24gZHJhZnQtdGlzc2EtbmV0bW9k LW9hbS0wMQ0KDQpIaSBRaW4sDQoNClBsZWFzZSBzZWUgaW4tbGluZSB3aXRoIFtOT0JPXS4NCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBRaW4gV3UgW21haWx0bzpiaWxs Lnd1QGh1YXdlaS5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMDgsIDIwMTQgOToxMCBBTQ0K PiBUbzogTm9ibyBBa2l5YSAobm9ibyk7IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpDQo+ IENjOiBuZXRtb2RAaWV0Zi5vcmc7IHRpbWVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IENvbW1l bnRzIG9uIGRyYWZ0LXRpc3NhLW5ldG1vZC1vYW0tMDENCj4gDQo+IFNvcnJ5IHRvIGNoaW1lIGlu Lg0KPiBTZWUgc29tZSBjb21tZW50cyBpbmxpbmUgYmVsb3cuDQo+IC0tLS0t08q8/tStvP4tLS0t LQ0KPiA+t6K8/sjLOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gtPqx 7SBOb2JvIEFraXlhDQo+IChub2JvKQ0KPiA+t6LLzcqxvOQ6IDIwMTTE6jfUwjXI1SAxOjA5DQo+ ID7K1bz+yMs6IFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpDQo+ID6zrcvNOiBuZXRtb2RA aWV0Zi5vcmcNCj4gPtb3zOI6IFtuZXRtb2RdIENvbW1lbnRzIG9uIGRyYWZ0LXRpc3NhLW5ldG1v ZC1vYW0tMDENCj4gDQo+ID5IaSBUaXNzYSwgYXV0aG9ycywNCj4gDQo+ID5GaXJzdCBvZiBhbGws IGludGVudCBvZiB0aGlzIGRvY3VtZW50IHNlZW1zIHdpZGVseSBiZW5lZmljaWFsLiBJIGFtDQo+ IGludGVyZXN0ZWQgdG8gc2VlIGhvdyBhbmQgSW4gd2hhdCBmb3JtIHRoaXMgZG9jdW1lbnQgd2ls bCBwcm9ncmVzcy4NCj4gDQo+ID5QbGVhc2UgZmluZCBiZWxvdyBmZXcgY29tbWVudHMgSSBoYXZl IG9uIHRoZSANCj4gPmRyYWZ0LXRpc3NhLW5ldG1vZC1vYW0tMDEsDQo+IGZyb20gYSBxdWljayBs b29rIGF0IHRoZSBkb2N1bWVudC4NCj4gDQo+IA0KPiA+Q29tbWVudCAjMTogU2VjdGlvbiA2DQo+ IA0KPiA+IFtzbmlwXQ0KPiA+ICAgICB0eXBlZGVmIENDTS1JbnRlcnZhbCB7DQo+ID4gICAgICAg ZGVmYXVsdCAiaW50ZXJ2YWwtMW1pbiI7DQo+ID4gICAgICAgdHlwZSBlbnVtZXJhdGlvbiB7DQo+ ID4gICAgICAgICBlbnVtICJpbnRlcnZhbC1pbnZhbGlkIiB7DQo+ID4gICAgICAgICAgIHZhbHVl IDA7DQo+ID4gICAgICAgICB9DQo+ICAgICAgICAgIC4uLg0KPiA+ICAgICAgICAgZW51bSAiaW50 ZXJ2YWwtMTBtaW4iIHsNCj4gPiAgICAgICAgICAgdmFsdWUgNzsNCj4gPiAgICAgICAgIH0NCj4g PiAgICAgIH0NCj4gICAgICAgIC4uLg0KPiA+ICAgICB9DQo+ID4gW3NuaXBdDQo+IA0KPiA+V2hl biBjb25zaWRlcmluZyBhbGwgT0FNIHRvb2xzIG91dCB0aGVyZSwgZGVmaW5pbmcgYSBoYXJkIGNv ZGVkIHNldCANCj4gPm9mIGludGVydmFscyAodmlhIGVudW0pIG1heSBub3QgYmUgYSBnb29kIGlk ZWEuIEJGRCBpbXBsZW1lbnRhdGlvbnMNCj4gPihTVy9IVykgc3ByaW5ncyB0byBteSBtaW5kIGlt bWVkaWF0ZWx5LiBGb3IgSFcgYmFzZWQgQkZELCBCRkQgV0cgaXMgDQo+ID53b3JraW5nIG9uIGFu IGluZm9ybWF0aW9uYWwgZG9jdW1lbnQgZm9yIHJlY29tbWVuZGVkIHNldCBvZiBpbnRlcnZhbHM6 DQo+IGRyYWZ0LWlldGYtYmZkLWludGVydmFscy4gSG93ZXZlciwgaW50ZXJ2YWxzIG91dHNpZGUg b2YgdGhhdCBzZXQgY2FuIA0KPiBzdGlsbCBiZSBpbXBsZW1lbnRlZCBieSB2ZW5kb3JzIGZvciBI VyBiYXNlZCBCRkQuIFNXIGJhc2VkIEJGRCwgDQo+IG9idmlvdXNseSwgaGFzIG11Y2ggbW9yZSBm bGV4aWJpbGl0eSBpbiB0aGUgcmFuZ2Ugb2YgaW50ZXJ2YWxzIHRvIHVzZS4gDQo+IEEgYmV0dGVy IGFwcHJvYWNoIG1heSBiZSB0byBjaGFuZ2UgYWJvdmUgZnJvbSBlbnVtIHRvIGlkZW50aWZ5IHJl ZiAob3IgDQo+IHNvbWV0aGluZyBlbHNlKSB3aGljaCBjYW4gYmUgYXVnbWVudGVkLg0KPiANCj4g DQo+ID5Db21tZW50ICMyOiBTZWN0aW9uIDYNCj4gDQo+ID4gW3NuaXBdDQo+ID4gICAgIHR5cGVk ZWYgZWNtcC1jaG9pY2VzIHsNCj4gPiAgICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCj4gPiAgICAg ICAgIGVudW0gImVjbXAtdXNlLXBsYXRmb3JtLWhhc2giIHsNCj4gPiAgICAgICAgICAgdmFsdWUg MDsNCj4gPiAgICAgICAgIH0NCj4gPiAgICAgICAgIGVudW0gImVjbXAtdXNlLXJvdW5kLXJvYmlu IiB7DQo+ID4gICAgICAgICAgIHZhbHVlIDE7DQo+ID4gICAgICAgICB9DQo+ID4gICAgICAgfQ0K PiA+ICAgICB9DQo+ID4gW3NuaXBdDQo+ID4gICAgICAgICAgICAgICAgIGxlYWYgZWNtcC1jaG9p Y2Ugew0KPiA+ICAgICAgICAgICAgICAgICAgIGNvbmZpZyB0cnVlOw0KPiA+ICAgICAgICAgICAg ICAgICAgIHR5cGUgZWNtcC1jaG9pY2VzOw0KPiA+ICAgICAgICAgICAgICAgICAgIGRlc2NyaXB0 aW9uDQo+ID4gICAgICAgICAgICAgICAgICAgICAiMCBtZWFucyB1c2UgdGhlIHNwZWNpZmllZCBp bnRlcmZhY2UNCj4gPiAgICAgICAgICAgICAgICAgICAgICAxIG1lYW5zIHVzZSByb3VuZCByb2Jp biI7DQo+ID4gICAgICAgICAgICAgICAgIH0NCj4gPiBbc25pcF0NCj4gDQo+ID5BYm92ZSB0d28g c2VlbXMgYSBiaXQgY29uZmxpY3RpbmcgZm9yIHRoZSB2YWx1ZSBvZiB6ZXJvKDApLiBGb3JtZXIg DQo+ID5zdGF0ZXMNCj4gdGhhdCB6ZXJvKDApIGluZGljYXRlcyB1c2FnZSBvZiBwbGF0Zm9ybSBo YXNoIGJ1dCB0aGUgbGF0dGVyIGluZGljYXRlcyANCj4gdGhhdCBzcGVjaWZpYyBpbnRlcmZhY2Ug aXMgdXNlZCAoaS5lLiBub3QgaGFzaGVkPykuID5UaGlua2luZyBhYm91dCANCj4gdGhpcywgSSBi ZWxpZXZlICJlY21wLWNob2ljZXMiIGlzIG92ZXJsb2FkZWQuIFlvdSBhY3R1YWxseSB3YW50IHRv IGJlIA0KPiBhYmxlIHRvIGRlc2NyaWJlIDMgZGlmZmVyZW50IHRoaW5ncyBoZXJlLg0KPiANCj4g PjEuIENvbmZpZ3VyaW5nIGEgc3BlY2lmaWMgbG9hZCBiYWxhbmNpbmcgdGVjaG5pcXVlIG9uIGEg c3lzdGVtIChleDogDQo+ID5FTCwNCj4gcm91bmQtcm9iaW4gb3Igc29tZXRoaW5nIGVsc2UpLg0K PiANCj4gW1Fpbl06IGFyZSB5b3UgcHJvcG9zaW5nIHRvIHJlcGxhY2UgZWNtcC11c2UtcGxhdGZv cm0taGFzaCB3aXRoIEVMIGFuZCANCj4gaGF2ZSB0aGUgZm9sbG93aW5nIGNoYW5nZSB0byBlY21w LWNob2ljZXMgdHlwZGVmIE5FVyBURVhUOg0KDQpbTk9CT10gV2Ugc2hvdWxkIHByb2JhYmx5IHRh a2UgYSBzdGVwIGJhY2ssIGFuZCBkZWNpZGUgaWYgY29uZmlndXJpbmcgbG9hZCBiYWxhbmNpbmcg YmVoYXZpb3JzIG9uIHN5c3RlbXMgaXMgc29tZXRoaW5nIHRoYXQgYmVsb25ncyB3aXRoaW4gZHJh ZnQtdGlzc2EtbmV0bW9kLW9hbSBvciBub3QuDQoNCltRaW5dOiBNYWtlIHNlbnNlIHRvIG1lLg0K DQo+ICINCj4gICAgICB0eXBlZGVmIGVjbXAtY2hvaWNlcyB7DQo+ICAgICAgICB0eXBlIGVudW1l cmF0aW9uIHsNCj4gICAgICAgICAgZW51bSAiRW50cm9weSBMYWJsZSIgew0KPiAgICAgICAgICAg IHZhbHVlIDA7DQo+ICAgICAgICAgIH0NCj4gICAgICAgICAgZW51bSAiZWNtcC11c2Utcm91bmQt cm9iaW4iIHsNCj4gICAgICAgICAgICB2YWx1ZSAxOw0KPiAgICAgICAgICB9DQo+ICAgICAgICB9 DQo+ICAgICAgfQ0KPiAiDQo+IEhvd2V2ZXIgZHJhZnQtdGlzc2EgYWxzbyBoYXMgZmxvdy1lbnRy b3B5IGdyb3VwaW5nIHRvIGJlIGRlZmluZWQgIg0KPiAgICAgIGdyb3VwaW5nIGZsb3ctZW50cm9w eSB7DQo+ICAgICAgICBkZXNjcmlwdGlvbg0KPiAgICAgICAgICAiZGVmaW5lcyB0aGUgZ3JvdXBp bmcgc3RhdGVtZW50IGZvciBmbG93LWVudHJvcHkiOw0KPiAgICAgICAgY2hvaWNlIGZsb3ctZW50 cm9weSB7DQo+ICAgICAgICAgIGNhc2UgZmxvdy1lbnRyb3B5LW51bGw7DQo+ICAgICAgICB9DQo+ ICAgICAgfQ0KPiAiDQo+IFdoaWNoIG1ha2UgbWUgZGlmZmljdWx0IHRvIHVuZGVyc3RhbmQgaG93 IGZsb3ctZW50cm9weSBncm91cGluZyBpcyANCj4gcmVsYXRlZCB0byBlY21wLWNob2ljZXMNCj4g DQo+ID4yLiBEZXNjcmliaW5nIHRoZSBvdXRwdXQgYmVoYXZpb3Igb24gdGhlIE9BTSBpbnN0YW5j ZSAoZXg6IG91dCB0byANCj4gPnNwZWNpZmljDQo+IGludGVyZmFjZSB2cy4gbG9hZCBiYWxhbmNl ZCkuDQo+IA0KPiBbUWluXTogSSBhbSB3b25kZXJpbmcgd2h5IG5vdCBjb25zaWRlciBpbnB1dCBi ZWhhdmlvciBvciBpbnB1dCBrZXkgdG8gDQo+IGxvYWQgYmFsYW5jaW5nIHRlY2huaXF1ZS4NCg0K W05PQk9dIFRoZSBnb2FsIGhlcmUgaXMgdG8gZGVzY3JpYmUgaG93IE9BTSBwYWNrZXRzIGFyZSBz ZW50IGZyb20gdGhlIHN5c3RlbSwgc28gaXQncyBub3QgdGhhdCBpbnB1dCBiZWhhdmlvciBidXQg aXQncyB0aGUgb3V0cHV0IGJlaGF2aW9yIHRoYXQgd2UgbmVlZCB0byBkZXNjcmliZS4gQWRkaXRp b25hbGx5LCBpZiB0aGUgT0FNIHBhY2tldCBpcyB0byBnZXQgbG9hZCBiYWxhbmNlZCBvdXQgZnJv bSB0aGUgc3lzdGVtLCB0aGVuIHRoZSBmaWVsZHMgZnJvbSB0aGUgcGFja2V0IGNvbnRlbnRzIHNo b3VsZCBiZSB1c2VkIGZvciBsb2FkIGJhbGFuY2luZywgYW5kIG5vdCBhIHNlcGFyYXRlIGlucHV0 IGtleS4gV2Ugd2lsbCBuZWVkIHRvIHNldCBjZXJ0YWluIGZpZWxkcyBvZiB0aGUgT0FNIHBhY2tl dHMgKGV4OiBFTCB2YWx1ZSwgSVAgYWRkcmVzcywgcG9ydCksIHNvIGlmIHlvdSBtZWFudCAiaW5w dXQga2V5IiB0byBzZXQgdGhvc2UgZmllbGRzLCB0aGVuIEkgYWdyZWUuDQoNCltRaW5dOiBZZXMs IEkgbWVhbnMgdGhvc2UgZmllbGRzLiBUaGFua3MgZm9yIHlvdXIgY2xlYXIgY2xhcmlmaWNhdGlv bi4NCg== From nobody Fri Jul 11 06:25:02 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCF41A0422; Fri, 11 Jul 2014 06:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.654 X-Spam-Level: X-Spam-Status: No, score=-0.654 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugXhZserVGbK; Fri, 11 Jul 2014 06:24:43 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3531A01AD; Fri, 11 Jul 2014 06:24:43 -0700 (PDT) Received: from [10.1.10.10] (c-71-234-142-79.hsd1.nh.comcast.net [71.234.142.79]) by lucidvision.com (Postfix) with ESMTP id 9259C281BD2D; Fri, 11 Jul 2014 09:24:36 -0400 (EDT) From: "Thomas D. Nadeau" Content-Type: multipart/signed; boundary="Apple-Mail=_36983A22-3CD0-4E88-8FA3-47FAD22673B0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Fri, 11 Jul 2014 09:24:33 -0400 Message-Id: <7ED1154E-58CF-4658-BC10-DB2893D40A70@lucidvision.com> To: YANG Doctors , netmod@ietf.org, "" , controller-dev Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-e2aZFhVIxr5acxPfKUOyJxFsII Subject: [netmod] Sunday Yang Tutorial, Advice and Mini-hackfest Session X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 13:24:52 -0000 --Apple-Mail=_36983A22-3CD0-4E88-8FA3-47FAD22673B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Benoit, Juergen and I wanted to send out the preliminary agenda = for the upcoming=20 Sunday session as we hacked this out this morning.=20 Comments/suggestions on are welcome. --Tom Sunday Yang Tutorial, Advice and Mini-hackfest Session * Introduction and expectations setting [Tom/Benoit] = 5 min Tutorials = 80 min * pyang tutorial [Lada] = 60 min * ODL yang-tools Tutorial [Jan Medved] = 20 min * Break Modeling Advice [Mini Yang Hackathon] [Yang Doctors] = TBD * Organize break-outs [Tom] * Break-out into small teams to hack individual [Yang = Doctors/Attendees]=20 (existing or new) models. Get advice=20 on those models from Yang Doctors. * Break-out session overall advice/observations [Yang Doctors] Summarize common themes from =09 session. =20 Conclusion = 30 min * Conclusions/Feedback - Please give feedback to Tom/Benoit after the meeting=20= or via email before you leave. * Yang Doctors please meet to collect advice and guidelines=20 given during session.=20 --Apple-Mail=_36983A22-3CD0-4E88-8FA3-47FAD22673B0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTv+WRAAoJEPcO+I7eiUJZihMQAL92UyTC+fLtXfu3oE7WNr1q bazqN0kF+ogL2vggcd9BTnkhlCcN89FVFXvacqz64WzsNsRz4PrsCAv8lIRiQeT4 8lkaA67JH4wBLRpp+qKCnyGTb5UMnxIfAYM5YpIfyZ6EJxwC6Qp9++mD6t/nUux+ rCguUUc5SibF1CFucZdr8HVn1ZQUIm9P+qL55bQOtRyAcnCxCeAEzsFZq2qhpm1h kdsN5UCj8ZHbu4WxGhr+y9I4wdVTeBfRaMzSsszbmbLrfgjDmDKP6h/tgSAe0hQ/ 5HW34RXO2WcC4nr3NSa0Ry+/u8rWsViB8e5DtpFtCRcaLVRjiihbiXJFaHyugxZn NfDgCyNlItkr+2WNDQhMU7wIut6AN4BB4GEsjYskv/mI+tYVKU8JUhzkm0BrrDKN Qlqfdy0vXHjftdUM1iDqiDax/Uheb+kBSK+qE9dC8dbrnSSWjVgXldF0q2gPLHW5 t6BBweQ8jb4HYVyslKK+uH9WqQ6Gnwd68Rodvrb46tdGJAjZYLemGw88XaN6j3Bs 11li9x0Ls7skVX4deluZE2zxfg1/9E7vZXwnG0SFpeKZdJUdxcbejWEcc/eLq+j1 VrdYfxW5/DhOskD6nOALGOwfc7TvH+KT/eTJ21zXyrQofeXxv66ZIvy7Suhrkj+Q 5LGwIfzRxtiq2vPusIOd =bEh9 -----END PGP SIGNATURE----- --Apple-Mail=_36983A22-3CD0-4E88-8FA3-47FAD22673B0-- From nobody Fri Jul 11 06:59:48 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68841B2AFD for ; Fri, 11 Jul 2014 06:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9bjwcg60HCW for ; Fri, 11 Jul 2014 06:59:41 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08BD1B2AFE for ; Fri, 11 Jul 2014 06:59:40 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 275A81145 for ; Fri, 11 Jul 2014 15:59:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id zRXfxnTn7H0W for ; Fri, 11 Jul 2014 15:59:36 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Fri, 11 Jul 2014 15:59:38 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8D3A82002C for ; Fri, 11 Jul 2014 15:59:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IEtGYlvlRSAN; Fri, 11 Jul 2014 15:59:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E42C420017; Fri, 11 Jul 2014 15:59:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C0C212DD5ECC; Fri, 11 Jul 2014 15:59:37 +0200 (CEST) Date: Fri, 11 Jul 2014 15:59:37 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140711135937.GA92947@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hYfB0wwgJPc0o3IHTPBFHdaYTSE Subject: [netmod] draft agenda for the toronto meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jul 2014 13:59:44 -0000 Hi, I have posted a draft agenda for the upcoming meeting in Toronto: http://www.ietf.org/proceedings/90/agenda/agenda-90-netmod /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Jul 15 04:55:17 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4BA1B286E for ; Tue, 15 Jul 2014 04:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpTMBSCKh0Po for ; Tue, 15 Jul 2014 04:55:14 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 299A41B286D for ; Tue, 15 Jul 2014 04:55:14 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E59C6110A for ; Tue, 15 Jul 2014 13:55:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Axf4e0vTLtxU for ; Tue, 15 Jul 2014 13:55:05 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 15 Jul 2014 13:55:12 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 21D7E2002C for ; Tue, 15 Jul 2014 13:55:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zygRQgHGyodA; Tue, 15 Jul 2014 13:55:11 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3500F20017; Tue, 15 Jul 2014 13:55:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 238D62DD83EF; Tue, 15 Jul 2014 13:55:11 +0200 (CEST) Date: Tue, 15 Jul 2014 13:55:11 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140715115511.GA534@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/9C7SVlyL5iu-UtNN16bVKwTnIdo Subject: [netmod] comments on draft-ietf-netmod-yang-json-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 15 Jul 2014 11:55:16 -0000 I have reviewed draft-ietf-netmod-yang-json-00.txt and I have a couple of questions. * Relationship to : - Lada, you once said that the JSON mapping leads to an I-JSON message. I note that I-JSON puts constraints on say object member names (section 2.1). Do we have the same constraints in YANG? - There is a recommendation (section 2.3) to encode large integers (e.g. 64-bit integer values) as JSON string values. - What about the other recommendations, e.g. base64 vs. base64url? Would it make sense to add a section to explain the relationship of the JSON mapping of YANG to I-JSON messages? * Numbers RFC 7159 makes me believe numbers are always treated as floating point numbers in JSON and hence there are precision limits. Note that RFC 7159 says: Note that when such software is used, numbers that are integers and are in the range [-(2**53)+1, (2**53)-1] are interoperable in the sense that implementations will agree exactly on their numeric values. So how does this work with out 64-bit integer types? And should there be a discussion of YANG's decimal64 type? Can JSON parsers always be expected to treat them nicely? * Namespaces Is the module qualified notation a common convention or could it be that JSON people eventually pick a different solution for dealing with namespaces? * IANA The question should be answered, one way or the other. * Security Considerations An empty sections considerations section is not good. * Updates [IF-CFG] became [RFC 7223] /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Jul 15 04:59:15 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1927A1A03AC for ; Tue, 15 Jul 2014 04:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTTQpRWn9TWG for ; Tue, 15 Jul 2014 04:59:14 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEA4A1B286C for ; Tue, 15 Jul 2014 04:59:13 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B25D11138 for ; Tue, 15 Jul 2014 13:59:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 8sHKId7BhCaQ for ; Tue, 15 Jul 2014 13:59:04 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 15 Jul 2014 13:59:12 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 21C1F2002C for ; Tue, 15 Jul 2014 13:59:12 +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 9VJyGMyv_8VV; Tue, 15 Jul 2014 13:59:11 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2FE9820017; Tue, 15 Jul 2014 13:59:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1D6462DD8423; Tue, 15 Jul 2014 13:59:11 +0200 (CEST) Date: Tue, 15 Jul 2014 13:59:11 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140715115911.GA598@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/o6Lsxbzx4AJgw8qRhV0MEEONArI Subject: [netmod] no virtual interim meeting on 2014-07-16 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 15 Jul 2014 11:59:15 -0000 Hi, there will be no virtual interim meeting 2014-07-16 (tomorrow) since several contributors are on vacation or busy with IETF/IEEE meeting preparations. Hope to see many of you next Monday in Toronto. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Jul 15 05:19:53 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB2A1B2873 for ; Tue, 15 Jul 2014 05:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WK3OI26Vfl9w for ; Tue, 15 Jul 2014 05:19:50 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 400391A038C for ; Tue, 15 Jul 2014 05:19:50 -0700 (PDT) Received: from [10.1.10.10] (c-71-234-142-79.hsd1.nh.comcast.net [71.234.142.79]) by lucidvision.com (Postfix) with ESMTP id 5CF3E282182C; Tue, 15 Jul 2014 08:19:49 -0400 (EDT) From: "Thomas D. Nadeau" Content-Type: multipart/signed; boundary="Apple-Mail=_4C8C20FD-7AF8-4C44-8DD3-6C574FDFBF35"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Tue, 15 Jul 2014 08:19:45 -0400 Message-Id: To: netmod@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fKCeR9xPP5y0ZvQLQ_HRqgjryPE Cc: netmod-chairs@tools.ietf.org Subject: [netmod] netmod agenda X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 12:19:51 -0000 --Apple-Mail=_4C8C20FD-7AF8-4C44-8DD3-6C574FDFBF35 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The netmod agenda is online now here: http://www.ietf.org/proceedings/90/agenda/agenda-90-netmod Presenters please send Juergen and myself your slides by no = later than Sunday afternoon.=20 Cheers, Tom/Juergen --Apple-Mail=_4C8C20FD-7AF8-4C44-8DD3-6C574FDFBF35 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTxRxhAAoJEPcO+I7eiUJZnC0P/3pZRLGJACXyjAKJIhKop+f5 Q+brNOtGBg7vC/kmfHZRWyf7fYxqCCSDYRG8qxxqUwJdE1Sa5rIEH6qiiHSMXsa7 Hxa4MSo+xfEt2LHRJqRvLYEqzVi7kzUcoNoRMkGyDJUSNdARvlsZxavWQ/xxGa1i 2MIb+ZxTkhjzwzCwAp80EoiTW/BJU4foXG807WCiYCax2PAbXSuPaUQsV6yro5OH OM2y5E+n94EaX4uqjKbx8Y2lx4zhvnt/Qx+HX78e7fZD1G6QJ4+ZHWJFVq6z+oP1 J9Vr0kXKf9Ac2HCbOI3+mrJzWLD+1avfA2fhbLBTEptN5uA7xAtxVqrZuBBfya2c q8huIwzhUir5S1E/kOT+7wnvaWEz6hmy0QZQmVLgRzy/e08M4j6FFN14Q/CKqA59 HIp2aY/CEl23pWnsgLzU6lDnOntB+U78RypRmRIOdmuyV6gYEDtY3+7merUx/G7t L1HKJt4Ux5Z+6us+JuiqlNRsMmdsgXRNKFYCXUPF7trrkS8+kgcK0TzjgFPTrJ4c 4HJOm3W3H97XnzEFxSG3GOJsQ2WzlTyRPeRBGmR2QKZD/SIl0HodMhUymLyXxeCU 9oYl8uP+538iKMrQWOVFp8y+IcSl9vooyHwiCcDKnYxRXxz7VVHe2/ZYcUk+chgW /fS2RnSekg2stcB0vavn =ZoqJ -----END PGP SIGNATURE----- --Apple-Mail=_4C8C20FD-7AF8-4C44-8DD3-6C574FDFBF35-- From nobody Thu Jul 17 02:30:39 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA971A01C8 for ; Thu, 17 Jul 2014 02:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xryPK8waj784 for ; Thu, 17 Jul 2014 02:30:36 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C935A1A01A9 for ; Thu, 17 Jul 2014 02:30:34 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E34DA1200 for ; Thu, 17 Jul 2014 11:30:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id UkH6a3B5g2X9 for ; Thu, 17 Jul 2014 11:30:15 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Thu, 17 Jul 2014 11:30:31 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0175A2002C for ; Thu, 17 Jul 2014 11:30:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id GbbVr8Uwstah; Thu, 17 Jul 2014 11:30:30 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E250020017; Thu, 17 Jul 2014 11:30:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 433082DD947D; Thu, 17 Jul 2014 11:30:30 +0200 (CEST) Date: Thu, 17 Jul 2014 11:30:30 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140717093030.GB4716@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OKW6EaWh0ADYze4pkIiXOQMJf4s Subject: [netmod] toronto meeting preparation - data model submissions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jul 2014 09:30:37 -0000 Hi, we have a number of new data model submissions on the agenda of the upcoming meeting in Toronto. To have a meaningful discussion, please try to take a look at the documents before the meeting. And if questions pop up, send them to the list - no need to wait for the meeting. The documents are: http://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-01 http://tools.ietf.org/html/draft-wildes-netmod-syslog-model-01 http://tools.ietf.org/html/draft-tissa-netmod-oam-01 http://tools.ietf.org/html/draft-dharini-netmod-g-698-2-yang-00 http://tools.ietf.org/html/draft-zheng-netmod-integrate-operations-00 http://tools.ietf.org/html/draft-yang-netmod-location-00 /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mailto.viswanath@gmail.com Thu Jul 17 03:27:40 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA831A03FE for ; Thu, 17 Jul 2014 03:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F93KsrOp1P0G for ; Thu, 17 Jul 2014 03:27:38 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 314011A059F for ; Thu, 17 Jul 2014 03:27:38 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hi2so7799092wib.4 for ; Thu, 17 Jul 2014 03:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=KR6pj5eFZwIa32MeDsWxmQ4zZ3cz3fEjK+vgK2AN96A=; b=kMYDuT5FMZVVfmQ0bDrGGRANTV4Iu9oymsGyuTbmpq7RlXGUAbKeHfCZ1LqFqnsTZZ f/iz9OIwmX/qasN6VX9mB2QI/xk4nBv7FEuJ281Bd8cmQIi9SmP78ihJ3zzaYeswckFb ioqMy14YBAsu7Q26rzDU1jb//ieaXA9xxBpevQ2VC0lyRp7rapopCUHvtUOoeZu70Lkw c/SxbX9NfRhUGMVj+8K425YDvRWe/qubBEPO0tsOBI9uh/SsxVtZVwCFkMHUJsx8TUjI y/5Yt6rRA/oHzOUw23BZaEvInDftvxXlC+f+umQEazklvGVlrT+kSptLy84bryoafHhB el0w== MIME-Version: 1.0 X-Received: by 10.180.101.98 with SMTP id ff2mr21008802wib.13.1405592850620; Thu, 17 Jul 2014 03:27:30 -0700 (PDT) Received: by 10.194.87.131 with HTTP; Thu, 17 Jul 2014 03:27:30 -0700 (PDT) Date: Thu, 17 Jul 2014 15:57:30 +0530 Message-ID: From: Viswanath Reddy To: zhengguangying Content-Type: multipart/alternative; boundary=f46d041826229026dc04fe611675 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/F4Aib0Lq5PWYrgNiL9uzCp4IvUU X-Mailman-Approved-At: Thu, 17 Jul 2014 03:59:21 -0700 Cc: netmod@ietf.org Subject: [netmod] Regarding draft-zheng-netmod-integrate-operations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 10:28:48 -0000 --f46d041826229026dc04fe611675 Content-Type: text/plain; charset=UTF-8 Hi Guangying Zheng, Greetings to you! I've come across this NETMOD draft proposed by you and Mr. X. Ji. The proposal looks very promising in terms of extending the base methods or operations in YANG models. *A few queries / suggestions:* 1) When it comes to committing / converting dynamic ARP entries to static / configuration ARP entries; Generally not all entries need to be committed and a selective set may need to be done. How do we do in that case? 2) You may provide more examples as the content looks pretty abstract. 3) How about error handling for the extended "method" operations? *A few comments on the grammatical content.* Section 3: "a well as" needs to be replaced with "as well as". Section 3.1: learn needs to be replaced with learnt. Section 3.3: You may want to replace "build-in " "built-in ". Scenario 3: "needs maintaining operations" can be replaced with "needs maintenance operations". Regards, Viswanath --f46d041826229026dc04fe611675 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Guangying Zheng,
=C2=A0
Greeti= ngs to you!
=C2=A0
I've come across this NETMOD dra= ft proposed by you and Mr. X. Ji. The proposal looks very promising in term= s of extending the base methods or operations in YANG models.
=C2=A0
A few queries / suggestions:
=C2=A0=C2=A0=C2=A0 1) When it comes to committing / converting dynamic A= RP entries to static / configuration ARP entries; Generally not all entries= need to be committed and a selective set may need to be done. How do we do= in that case?
=C2=A0=C2=A0=C2=A0 2) You may provide more examples as the content loo= ks pretty abstract.
=C2=A0=C2=A0=C2=A0 3) How about error handlin= g for the extended "method" operations?
=C2=A0
A few comments on the grammatical content.
=C2=A0=C2=A0=C2=A0 Section 3: "a well as" needs to be replac= ed with "as well as".
=C2=A0=C2=A0=C2=A0 Section 3.1: l= earn needs to be replaced with learnt.
=C2=A0=C2=A0=C2=A0 Section= 3.3: You may want to replace "build-in " "built-in ".<= /div>
=C2=A0=C2=A0=C2=A0 Scenario 3: "needs maintaining operations"= ; can be replaced with "needs maintenance operations".
= =C2=A0
Regards,
Viswanath
--f46d041826229026dc04fe611675-- From nobody Thu Jul 17 06:43:15 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459DD1A0B12 for ; Thu, 17 Jul 2014 06:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hsLku5ier26 for ; Thu, 17 Jul 2014 06:43:11 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B23CC1A0B04 for ; Thu, 17 Jul 2014 06:43:11 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB421.namprd05.prod.outlook.com (10.141.58.139) with Microsoft SMTP Server (TLS) id 15.0.985.8; Thu, 17 Jul 2014 13:43:09 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.19]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.19]) with mapi id 15.00.0985.008; Thu, 17 Jul 2014 13:43:09 +0000 From: Dean Bogdanovic To: "netmod@ietf.org" Thread-Topic: Comments to draft-wildes-netmod-syslog-model-01 Thread-Index: AQHPocULEfHFrtoFh06g0p0kb6Awmg== Date: Thu, 17 Jul 2014 13:43:09 +0000 Message-ID: <86A137DA-DF84-4910-9978-0A643D01C74D@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(50226001)(87286001)(99396002)(107886001)(99286002)(95666004)(4396001)(105586002)(229853001)(62966002)(85852003)(92726001)(558084003)(107046002)(79102001)(86362001)(2351001)(83716003)(77982001)(2656002)(93916002)(88136002)(87936001)(83322001)(77156001)(110136001)(20776003)(33656002)(76482001)(85306003)(31966008)(74502001)(74662001)(81342001)(104166001)(77096002)(106116001)(50986999)(82746002)(36756003)(57306001)(101416001)(92566001)(83072002)(80022001)(64706001)(106356001)(89996001)(81542001)(46102001)(66066001)(21056001)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB421; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/GC70bYEfIbVVltmdE9klq6BjdvM Subject: [netmod] Comments to draft-wildes-netmod-syslog-model-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 13:43:13 -0000 Hi, Pretty clean and straight forward draft. Have one question. Why is the user= scope limited to terminal logging only? Why not for file logging too, so t= hat permissions can be set who can access the created syslog file. thx Dean From nobody Thu Jul 17 08:13:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB401B27B7 for ; Thu, 17 Jul 2014 08:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQAPtWtW1kTB for ; Thu, 17 Jul 2014 08:13:24 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9ABF1A0079 for ; Thu, 17 Jul 2014 08:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1118; q=dns/txt; s=iport; t=1405609990; x=1406819590; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=RWvsPKSChWUjcGczLz2E2ahq+cigV72SI/ZLx3vq9T0=; b=Kgo8ofvw6Dcht8d+Yulx7D1LjmH6lPDt58oGR/medwSMeBDYYiaPjKtl yGGR2TuPYMrbydv5rCQyj76jSJWhSPHuqbUffvvJFmxjsefj5oHpBhFTn RQj9C8N6sJxbhK7R+oExfwFM9uNqMSEgByLMJsjRWx/SJ4T2GpJGnW57i Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAFTnx1OtJV2b/2dsb2JhbABZgmokUlcEw0YKhm+BWRZ2hAQBAQQBAQFrHQEIbQsnBAESiEIBDMYkEwSOc4UlBYoqkHWULINEbIEDQg X-IronPort-AV: E=Sophos;i="5.01,678,1400025600"; d="scan'208";a="340719764" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 17 Jul 2014 15:13:09 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6HFD9dH004041 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Jul 2014 15:13:09 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Thu, 17 Jul 2014 10:13:08 -0500 From: "Clyde Wildes (cwildes)" To: Dean Bogdanovic , "netmod@ietf.org" Thread-Topic: [netmod] Comments to draft-wildes-netmod-syslog-model-01 Thread-Index: AQHPodGd2DiE26EFB02ewm8MxouDPg== Date: Thu, 17 Jul 2014 15:13:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.157.242] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <91C563929439D640A981E6B8AECF0CFE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/BXPqp_MHgBhp3InGsWtiZFNV-3E Subject: Re: [netmod] Comments to draft-wildes-netmod-syslog-model-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 15:13:25 -0000 Dean, Thanks for your review. The user scope choice is defined as distribution of log messages to specific users or all users. It is a qualification for the ability to distribute log messages to terminals. Some vendor OSs' only support distribution of log messages to all terminals, thus the all-users case. Other vendors support distribution to specific users (or to all users using a wildcard =B3*=B2 specification) - the per-user case. None of the fives OSs=B9 that were examined have permission based syslog configuration. I would look to AAA authorization for specification of which users can look at log files. Thanks, Clyde On 7/17/14, 6:43 AM, "Dean Bogdanovic" wrote: >Hi, > >Pretty clean and straight forward draft. Have one question. Why is the >user scope limited to terminal logging only? Why not for file logging >too, so that permissions can be set who can access the created syslog >file. > >thx > >Dean > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Jul 17 19:03:44 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A031A03B4 for ; Thu, 17 Jul 2014 19:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.749 X-Spam-Level: * X-Spam-Status: No, score=1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nj4KbNcyyNQb for ; Thu, 17 Jul 2014 19:03:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CC0B1A01BA for ; Thu, 17 Jul 2014 19:03:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKF01968; Fri, 18 Jul 2014 02:03:39 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Jul 2014 03:03:39 +0100 Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.247]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Fri, 18 Jul 2014 10:03:29 +0800 From: Zhengguangying To: Viswanath Reddy Thread-Topic: Regarding draft-zheng-netmod-integrate-operations Thread-Index: AQHPoaqhv6XbcYcafEaBF1InOc3+OZulEYKy Date: Fri, 18 Jul 2014 02:03:29 +0000 Message-ID: <381D7D55085B1E4D8B581BD652E1E14058C5C6CC@nkgeml504-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.33.139] Content-Type: multipart/alternative; boundary="_000_381D7D55085B1E4D8B581BD652E1E14058C5C6CCnkgeml504mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/clZ-JdsQbsQn7KMot2AIgeLVFLI Cc: "netmod@ietf.org" , Yangang Subject: [netmod] =?gb2312?b?tPC4tDogUmVnYXJkaW5nIGRyYWZ0LXpoZW5nLW5ldG1v?= =?gb2312?b?ZC1pbnRlZ3JhdGUtb3BlcmF0aW9ucw==?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 02:03:43 -0000 --_000_381D7D55085B1E4D8B581BD652E1E14058C5C6CCnkgeml504mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgVmlzd2FuYXRoLA0KDQoNCg0KICAgIFRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50cyBmaXJz dGx5LCBwbGVhc2UgY2hlY2sgbXkgYW5zd2VyLg0KDQoNCg0KPj5BIGZldyBxdWVyaWVzIC8gc3Vn Z2VzdGlvbnM6DQogICAgPj4xKSBXaGVuIGl0IGNvbWVzIHRvIGNvbW1pdHRpbmcgLyBjb252ZXJ0 aW5nIGR5bmFtaWMgQVJQIGVudHJpZXMgdG8gc3RhdGljIC8gY29uZmlndXJhdGlvbiBBUlAgZW50 cmllczsgR2VuZXJhbGx5IG5vdCBhbGwgZW50cmllcyBuZWVkIHRvIGJlIGNvbW1pdHRlZCBhbmQg YSBzZWxlY3RpdmUgc2V0IG1heSBuZWVkIHRvIGJlIGRvbmUuIEhvdyBkbyB3ZSBkbyBpbiB0aGF0 IGNhc2U/DQpBbnN3ZXI6ICAgRm9yIHRoaXMgY2FzZSwgdGhlIGEgc2VsZWN0aXZlIHNldCB3aWxs IGRlZmluZSBhcyBpbnB1dCBwYXJhbWV0ZXJzLg0KICAgID4+MikgWW91IG1heSBwcm92aWRlIG1v cmUgZXhhbXBsZXMgYXMgdGhlIGNvbnRlbnQgbG9va3MgcHJldHR5IGFic3RyYWN0Lg0KICAgID4+ MykgSG93IGFib3V0IGVycm9yIGhhbmRsaW5nIGZvciB0aGUgZXh0ZW5kZWQgIm1ldGhvZCIgb3Bl cmF0aW9ucz8NCkFuc3dlcjogdGhlc2UgdHdvIHN1Z2dlc3Rpb25zIHdpbGwgY29uY2VybiBpbiB0 aGUgbmV4dCB2ZXJzaW9uIGRyYWZ0J3Mgc29sdXRpb24gZGV0YWlsIHNlY3Rpb24uDQoNCj4+QSBm ZXcgY29tbWVudHMgb24gdGhlIGdyYW1tYXRpY2FsIGNvbnRlbnQuDQogICAgPj5TZWN0aW9uIDM6 ICJhIHdlbGwgYXMiIG5lZWRzIHRvIGJlIHJlcGxhY2VkIHdpdGggImFzIHdlbGwgYXMiLg0KICAg ID4+U2VjdGlvbiAzLjE6IGxlYXJuIG5lZWRzIHRvIGJlIHJlcGxhY2VkIHdpdGggbGVhcm50Lg0K ICAgPj4gU2VjdGlvbiAzLjM6IFlvdSBtYXkgd2FudCB0byByZXBsYWNlICJidWlsZC1pbiAiICJi dWlsdC1pbiAiLg0KICAgPj4gU2NlbmFyaW8gMzogIm5lZWRzIG1haW50YWluaW5nIG9wZXJhdGlv bnMiIGNhbiBiZSByZXBsYWNlZCB3aXRoICJuZWVkcyBtYWludGVuYW5jZSBvcGVyYXRpb25zIi4N CkFuc3dlcjogc29ycnkgZm9yIHNvIG1hbnkgZ3JhbW1hdGljYWwgZXJyb3JzLCB0aGVzZSB3aWxs IGJlIHVwZGF0ZWQgaW4gdGhlIG5leHQgZHJhZnQgdmVyc2lvbi4NCg0KICBUaGFuayB5b3UgYSBh Z2FpbiBmb3IgeW91ciBjb21tZW50cyBhbnMgc3VnZ2VzdGlvbnMuIElmIGFueSBvdGhlciBjb21t ZW50cyBwbGVhc2UgbGV0IG1lIGtvbncuDQoNClJlZ2FyZHMmVGhhbmtzDQpaaGVuZw0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogVmlzd2FuYXRoIFJlZGR5IFttYWls dG8udmlzd2FuYXRoQGdtYWlsLmNvbV0NCreiy83KsbzkOiAyMDE0xOo31MIxN8jVIDE4OjI3DQrK 1bz+yMs6IFpoZW5nZ3Vhbmd5aW5nDQqzrcvNOiBuZXRtb2RAaWV0Zi5vcmcNCtb3zOI6IFJlZ2Fy ZGluZyBkcmFmdC16aGVuZy1uZXRtb2QtaW50ZWdyYXRlLW9wZXJhdGlvbnMNCg0KSGkgR3Vhbmd5 aW5nIFpoZW5nLA0KDQpHcmVldGluZ3MgdG8geW91IQ0KDQpJJ3ZlIGNvbWUgYWNyb3NzIHRoaXMg TkVUTU9EIGRyYWZ0IHByb3Bvc2VkIGJ5IHlvdSBhbmQgTXIuIFguIEppLiBUaGUgcHJvcG9zYWwg bG9va3MgdmVyeSBwcm9taXNpbmcgaW4gdGVybXMgb2YgZXh0ZW5kaW5nIHRoZSBiYXNlIG1ldGhv ZHMgb3Igb3BlcmF0aW9ucyBpbiBZQU5HIG1vZGVscy4NCg0KQSBmZXcgcXVlcmllcyAvIHN1Z2dl c3Rpb25zOg0KICAgIDEpIFdoZW4gaXQgY29tZXMgdG8gY29tbWl0dGluZyAvIGNvbnZlcnRpbmcg ZHluYW1pYyBBUlAgZW50cmllcyB0byBzdGF0aWMgLyBjb25maWd1cmF0aW9uIEFSUCBlbnRyaWVz OyBHZW5lcmFsbHkgbm90IGFsbCBlbnRyaWVzIG5lZWQgdG8gYmUgY29tbWl0dGVkIGFuZCBhIHNl bGVjdGl2ZSBzZXQgbWF5IG5lZWQgdG8gYmUgZG9uZS4gSG93IGRvIHdlIGRvIGluIHRoYXQgY2Fz ZT8NCiAgICAyKSBZb3UgbWF5IHByb3ZpZGUgbW9yZSBleGFtcGxlcyBhcyB0aGUgY29udGVudCBs b29rcyBwcmV0dHkgYWJzdHJhY3QuDQogICAgMykgSG93IGFib3V0IGVycm9yIGhhbmRsaW5nIGZv ciB0aGUgZXh0ZW5kZWQgIm1ldGhvZCIgb3BlcmF0aW9ucz8NCg0KQSBmZXcgY29tbWVudHMgb24g dGhlIGdyYW1tYXRpY2FsIGNvbnRlbnQuDQogICAgU2VjdGlvbiAzOiAiYSB3ZWxsIGFzIiBuZWVk cyB0byBiZSByZXBsYWNlZCB3aXRoICJhcyB3ZWxsIGFzIi4NCiAgICBTZWN0aW9uIDMuMTogbGVh cm4gbmVlZHMgdG8gYmUgcmVwbGFjZWQgd2l0aCBsZWFybnQuDQogICAgU2VjdGlvbiAzLjM6IFlv dSBtYXkgd2FudCB0byByZXBsYWNlICJidWlsZC1pbiAiICJidWlsdC1pbiAiLg0KICAgIFNjZW5h cmlvIDM6ICJuZWVkcyBtYWludGFpbmluZyBvcGVyYXRpb25zIiBjYW4gYmUgcmVwbGFjZWQgd2l0 aCAibmVlZHMgbWFpbnRlbmFuY2Ugb3BlcmF0aW9ucyIuDQoNClJlZ2FyZHMsDQpWaXN3YW5hdGgN Cg== --_000_381D7D55085B1E4D8B581BD652E1E14058C5C6CCnkgeml504mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Viswanath,

 

    Thank you for your comments firstly, please check my = answer.

 

>>A few queries / suggestions:
    >>1) When it comes to committing / converting= dynamic ARP entries to static / configuration ARP entries; Generally not a= ll entries need to be committed and a selective set may need to be done. Ho= w do we do in that case?
Answer:   For this case, the a selective set will define as = input parameters.
    >>2) You may provide more examples as the con= tent looks pretty abstract.
    >>3) How about error handling for the extende= d "method" operations?
Answer: these two suggestions will concern in the next version draft's= solution detail section.
 
>>A few comments on the grammatical content.
    >>Section 3: "a well as" needs to b= e replaced with "as well as".
    >>Section 3.1: learn needs to be replaced wit= h learnt.
   >> Section 3.3: You may want to replace "= build-in " "built-in ".
   >> Scenario 3: "needs maintaining operati= ons" can be replaced with "needs maintenance operations".
Answer: sorry for so many grammatical errors, these will be updated in= the next draft version.
 
  Thank you a again for your comments ans suggestions. If any oth= er comments please let me konw.
 
Regards&Thanks
Zheng
=B7=A2=BC=FE=C8=CB: Viswanath Reddy [mailt= o.viswanath@gmail.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA7=D4=C217=C8=D5 18:27
=CA=D5=BC=FE=C8=CB: Zhengguangying
=B3=AD=CB=CD: netmod@ietf.org
=D6=F7=CC=E2: Regarding draft-zheng-netmod-integrate-operations

Hi Guangying Zheng,
 
Greetings to you!
 
I've come across this NETMOD draft proposed by you and Mr. X. Ji. The = proposal looks very promising in terms of extending the base methods or ope= rations in YANG models.
 
A few queries / suggestions:
    1) When it comes to committing / converting dynamic= ARP entries to static / configuration ARP entries; Generally not all entri= es need to be committed and a selective set may need to be done. How do we = do in that case?
    2) You may provide more examples as the content loo= ks pretty abstract.
    3) How about error handling for the extended "= method" operations?
 
A few comments on the grammatical content.
    Section 3: "a well as" needs to be replac= ed with "as well as".
    Section 3.1: learn needs to be replaced with learnt= .
    Section 3.3: You may want to replace "build-in= " "built-in ".
    Scenario 3: "needs maintaining operations"= ; can be replaced with "needs maintenance operations".
 
Regards,
Viswanath
--_000_381D7D55085B1E4D8B581BD652E1E14058C5C6CCnkgeml504mbxchi_-- From nobody Sun Jul 20 07:13:13 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62BA1B2B4E for ; Sun, 20 Jul 2014 07:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZ4rGgJMycVb for ; Sun, 20 Jul 2014 07:13:09 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 347041B280B for ; Sun, 20 Jul 2014 07:13:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 71735540749; Sun, 20 Jul 2014 16:13:05 +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 9eglibHlTw0n; Sun, 20 Jul 2014 16:13:01 +0200 (CEST) Received: from localhost (dhcp-8cc7.meeting.ietf.org [31.133.140.199]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id B1D125406BA; Sun, 20 Jul 2014 16:13:00 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , netmod@ietf.org In-Reply-To: <20140715115511.GA534@elstar.local> References: <20140715115511.GA534@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Sun, 20 Jul 2014 10:12:55 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LPoHZcrYytb_msCJ0aaAJOEydDY Subject: Re: [netmod] comments on draft-ietf-netmod-yang-json-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 14:13:12 -0000 Hi Juergen, thanks for reviewing the draft. Juergen Schoenwaelder writes: > I have reviewed draft-ietf-netmod-yang-json-00.txt and I have a couple > of questions. > > * Relationship to : > > - Lada, you once said that the JSON mapping leads to an I-JSON > message. I note that I-JSON puts constraints on say object member > names (section 2.1). Do we have the same constraints in YANG? Yes, a member name in our case can be: - YANG identifier - pair of colon-separated YANG identifiers (explicit namespace) Names of metadata objects also include "@". > > - There is a recommendation (section 2.3) to encode large integers > (e.g. 64-bit integer values) as JSON string values. It is an option to encode int64 and uint64 as strings, although it would be awkward. > > - What about the other recommendations, e.g. base64 vs. base64url? IMO, in this case we should stick to base64 because this is what YANG prescribes for the "binary" type. I don't think we need URL-safe encoding. > > Would it make sense to add a section to explain the relationship of > the JSON mapping of YANG to I-JSON messages? Yes, although I don't know whether it is a good idea to use it as a normative reference. > > * Numbers > > RFC 7159 makes me believe numbers are always treated as floating > point numbers in JSON and hence there are precision limits. Note > that RFC 7159 says: > > Note that when such software is used, numbers that are integers and > are in the range [-(2**53)+1, (2**53)-1] are interoperable in the > sense that implementations will agree exactly on their numeric > values. I-JSON spec even says that the sender MUST NOT expect the receiver to treat an integer outside that range as an exact value. > > So how does this work with out 64-bit integer types? For such large values it doesn't, I am afraid. > > And should there be a discussion of YANG's decimal64 type? Can JSON > parsers always be expected to treat them nicely? Probably not, it is the same problem. However, I wonder whether large decimal64 values can be safely processed even if they are passed in XML - most likely they will end up as double precision numbers anyway. > > * Namespaces > > Is the module qualified notation a common convention or could it be > that JSON people eventually pick a different solution for dealing > with namespaces? There is no standard solution. Expired I-D http://tools.ietf.org/html/draft-saintandre-json-namespaces-00 proposed to use James Clark's notation, {URI}local-name, e.g. {urn:ietf:params:xml:ns:yang:iana-if-type}interface We are lucky that we can avoid the URI-prefix duality by using the module name. And using colon as the separator is natural because it is not allowed in identifiers. > > * IANA > > The question should be answered, one way or the other. RESTCONF spec registers the application/yang.data media type. I actually think it would be more appropriate to bundle the registration with the specification of the data format because the format can be used in different protocols. So maybe the best place is 6020bis? > > * Security Considerations > > An empty sections considerations section is not good. > > * Updates > > [IF-CFG] became [RFC 7223] Yes, I will write Security Considerations and update references in the next revision. Thanks, Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Jul 20 11:18:17 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E652B1B2927 for ; Sun, 20 Jul 2014 11:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7uWDJgBJ1OS for ; Sun, 20 Jul 2014 11:17:51 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCBD71A0AB5 for ; Sun, 20 Jul 2014 11:17:50 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 20EE7E7C; Sun, 20 Jul 2014 20:17:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id GFU8sM7pOcwK; Sun, 20 Jul 2014 20:17:40 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 20 Jul 2014 20:17:47 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E34B62002C; Sun, 20 Jul 2014 20:17:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xtrSJyu-RwDf; Sun, 20 Jul 2014 20:17:46 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 16D0720017; Sun, 20 Jul 2014 20:17:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7E1172DDE23B; Sun, 20 Jul 2014 20:17:45 +0200 (CEST) Date: Sun, 20 Jul 2014 20:17:44 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140720181744.GA6423@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <20140715115511.GA534@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-1IfNUUG_oNM2RtCoWKrAvG0xyk Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-ietf-netmod-yang-json-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 20 Jul 2014 18:17:53 -0000 On Sun, Jul 20, 2014 at 10:12:55AM -0400, Ladislav Lhotka wrote: > > * Relationship to : > > > > - Lada, you once said that the JSON mapping leads to an I-JSON > > message. I note that I-JSON puts constraints on say object member > > names (section 2.1). Do we have the same constraints in YANG? > > Yes, a member name in our case can be: > - YANG identifier > - pair of colon-separated YANG identifiers (explicit namespace) OK, makes sense. > Names of metadata objects also include "@". > > > > > - There is a recommendation (section 2.3) to encode large integers > > (e.g. 64-bit integer values) as JSON string values. > > It is an option to encode int64 and uint64 as strings, although it would > be awkward. According to RFC 7158, numbers in JSON seem to be considered to be floating point numbers by typical applications and there is specific advice on the precision that can be achieved in such situations: Note that when such software is used, numbers that are integers and are in the range [-(2**53)+1, (2**53)-1] are interoperable in the sense that implementations will agree exactly on their numeric values. I think we need to discuss this issue somewhere in the document. Even if we go with a plain representation of large integral numbers, there probably needs to be a warning somewhere. (I just checked json-c and it seems to represent numbers as json_type_double.) > > - What about the other recommendations, e.g. base64 vs. base64url? > > IMO, in this case we should stick to base64 because this is what YANG > prescribes for the "binary" type. I don't think we need URL-safe > encoding. I must admit that I do not really understand the story behind base64url but the i-json document RECOMMENDs its usage. > > Would it make sense to add a section to explain the relationship of > > the JSON mapping of YANG to I-JSON messages? > > Yes, although I don't know whether it is a good idea to use it as a > normative reference. I guess the question is how long I-JSON remains a moving target? The charter says IETF last call in June 2014. ;-) > > * Numbers > > > > RFC 7159 makes me believe numbers are always treated as floating > > point numbers in JSON and hence there are precision limits. Note > > that RFC 7159 says: > > > > Note that when such software is used, numbers that are integers and > > are in the range [-(2**53)+1, (2**53)-1] are interoperable in the > > sense that implementations will agree exactly on their numeric > > values. > > I-JSON spec even says that the sender MUST NOT expect the receiver to treat > an integer outside that range as an exact value. > > > So how does this work with out 64-bit integer types? > > For such large values it doesn't, I am afraid. > > > And should there be a discussion of YANG's decimal64 type? Can JSON > > parsers always be expected to treat them nicely? > > Probably not, it is the same problem. However, I wonder whether large > decimal64 values can be safely processed even if they are passed in XML > - most likely they will end up as double precision numbers anyway. A proper implementation needs to process fixed point data as fixed point data. That said, I think we need to look how we deal with the differences of the number spaces. (This reminds me when Java SNMP API's came along and due to a lack of unsigned numbers, things we simply mapped to the larger numeric type and for 64-bit numbers the "solution" was to simply drop a bit. I think we should do better.) > > * IANA > > > > The question should be answered, one way or the other. > > RESTCONF spec registers the application/yang.data media type. I actually > think it would be more appropriate to bundle the registration with the > specification of the data format because the format can be used in > different protocols. So maybe the best place is 6020bis? Lets keep things focussed on the JSON document. So you are saying there is nothing to do. Then I suggest to write this down. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sun Jul 20 15:31:56 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249721B2A28 for ; Sun, 20 Jul 2014 15:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAR6RZTsXjGm for ; Sun, 20 Jul 2014 15:31:53 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 462541B27BC for ; Sun, 20 Jul 2014 15:31:53 -0700 (PDT) Received: from [172.16.50.248] (unknown [206.47.221.210]) by mail.nic.cz (Postfix) with ESMTPSA id F2170140C9A; Mon, 21 Jul 2014 00:31:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1405895511; bh=apLFQapz44MR39p/W8vVUBdjIslN9rlCixvIEumLamU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=c0LEpNjbS2yfpzTZ2w0L55ayZXMe7GX832uHWpp4LwyuxQgqH0u2VJYvNBvvCg9DT VrR3d6GWVnQv+AoDXeWIclBfeHinpcAFRdin1lttJPwJ3+EcyfuQibGALTpgNEYlwl zVhaA3VCQ4CPq0psqMC22yXLrN8mhgLLT7fsPg24= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140720181744.GA6423@elstar.local> Date: Sun, 20 Jul 2014 18:31:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140715115511.GA534@elstar.local> <20140720181744.GA6423@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/rkoe7PlI3Ic1g_nTxUYiXEjddkI Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-ietf-netmod-yang-json-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 22:31:55 -0000 On 20 Jul 2014, at 14:17, Juergen Schoenwaelder = wrote: >>>=20 >>> - There is a recommendation (section 2.3) to encode large integers >>> (e.g. 64-bit integer values) as JSON string values. >>=20 >> It is an option to encode int64 and uint64 as strings, although it = would >> be awkward. >=20 > According to RFC 7158, numbers in JSON seem to be considered to be > floating point numbers by typical applications and there is specific > advice on the precision that can be achieved in such situations: >=20 > Note that when such software is used, numbers that are integers and > are in the range [-(2**53)+1, (2**53)-1] are interoperable in the > sense that implementations will agree exactly on their numeric > values. >=20 > I think we need to discuss this issue somewhere in the document. Even I agree, and we also have to decide whether the mapping needs to be = changed. I assume there isn=92t much excitement about representing = numbers as strings. > if we go with a plain representation of large integral numbers, there > probably needs to be a warning somewhere. (I just checked json-c and > it seems to represent numbers as json_type_double.) >=20 >>> - What about the other recommendations, e.g. base64 vs. base64url? >>=20 >> IMO, in this case we should stick to base64 because this is what YANG >> prescribes for the "binary" type. I don't think we need URL-safe >> encoding. >=20 > I must admit that I do not really understand the story behind > base64url but the i-json document RECOMMENDs its usage. I will probably ask in the JSON mailing list. >=20 >>> Would it make sense to add a section to explain the relationship of >>> the JSON mapping of YANG to I-JSON messages? >>=20 >> Yes, although I don't know whether it is a good idea to use it as a >> normative reference. >=20 > I guess the question is how long I-JSON remains a moving target? The > charter says IETF last call in June 2014. ;-) Yes, that's why I am a bit reluctant to put it there.=20 >=20 >>> * Numbers >>>=20 >>> RFC 7159 makes me believe numbers are always treated as floating >>> point numbers in JSON and hence there are precision limits. Note >>> that RFC 7159 says: >>>=20 >>> Note that when such software is used, numbers that are integers = and >>> are in the range [-(2**53)+1, (2**53)-1] are interoperable in the >>> sense that implementations will agree exactly on their numeric >>> values. >>=20 >> I-JSON spec even says that the sender MUST NOT expect the receiver to = treat >> an integer outside that range as an exact value. >>=20 >>> So how does this work with out 64-bit integer types? >>=20 >> For such large values it doesn't, I am afraid. >>=20 >>> And should there be a discussion of YANG's decimal64 type? Can JSON >>> parsers always be expected to treat them nicely? >>=20 >> Probably not, it is the same problem. However, I wonder whether large >> decimal64 values can be safely processed even if they are passed in = XML >> - most likely they will end up as double precision numbers anyway. >=20 > A proper implementation needs to process fixed point data as fixed > point data. That said, I think we need to look how we deal with the The problem is that decimal number isn't usually available as a built-in = type. > differences of the number spaces. (This reminds me when Java SNMP > API's came along and due to a lack of unsigned numbers, things we > simply mapped to the larger numeric type and for 64-bit numbers the > "solution" was to simply drop a bit. I think we should do better.) Yes. We have the advantage that the exact type is known, so there should = be no excuse. On the other hand, developers want to use existing JSON = parsers. =20 >=20 >>> * IANA >>>=20 >>> The question should be answered, one way or the other. >>=20 >> RESTCONF spec registers the application/yang.data media type. I = actually >> think it would be more appropriate to bundle the registration with = the >> specification of the data format because the format can be used in >> different protocols. So maybe the best place is 6020bis? >=20 > Lets keep things focussed on the JSON document. So you are saying = there > is nothing to do. Then I suggest to write this down. OK. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Jul 20 15:45:31 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACB61B2A35 for ; Sun, 20 Jul 2014 15:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzLkvqtDZYOQ for ; Sun, 20 Jul 2014 15:45:27 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49031B2A2C for ; Sun, 20 Jul 2014 15:45:26 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7A23872D; Mon, 21 Jul 2014 00:45:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 2Gl_QUw4MFj4; Mon, 21 Jul 2014 00:45:16 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 21 Jul 2014 00:45:24 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BB1FE2002C; Mon, 21 Jul 2014 00:45:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dKJHWJ-nnLAa; Mon, 21 Jul 2014 00:45:24 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B408320017; Mon, 21 Jul 2014 00:45:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F22682DDE53F; Mon, 21 Jul 2014 00:45:22 +0200 (CEST) Date: Mon, 21 Jul 2014 00:45:22 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140720224522.GA7194@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <20140715115511.GA534@elstar.local> <20140720181744.GA6423@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/vTL44lYizjJ8IVxOYovQwhxddCo Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-ietf-netmod-yang-json-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 20 Jul 2014 22:45:28 -0000 On Sun, Jul 20, 2014 at 06:31:48PM -0400, Ladislav Lhotka wrote: > > >> Probably not, it is the same problem. However, I wonder whether large > >> decimal64 values can be safely processed even if they are passed in XML > >> - most likely they will end up as double precision numbers anyway. > > > > A proper implementation needs to process fixed point data as fixed > > point data. That said, I think we need to look how we deal with the > > The problem is that decimal number isn't usually available as a built-in type. > Yes, but an implementation can do the right thing if we provide the opportunity to do the right thing. If the JSON parser already messes up the numbers, the implementation has lost. Or are you saying to do the right thing, implementations can't use a stock JSON parsers? That would also be somewhat disappointing... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jul 21 07:53:01 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5181A014B for ; Mon, 21 Jul 2014 07:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfJQvJ0ABWcI for ; Mon, 21 Jul 2014 07:52:58 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id D00EB1A0039 for ; Mon, 21 Jul 2014 07:52:57 -0700 (PDT) Received: from [192.168.1.121] (static-72-71-250-37.cncdnh.fast04.myfairpoint.net [72.71.250.37]) by lucidvision.com (Postfix) with ESMTP id 700B4282B8FD for ; Mon, 21 Jul 2014 10:52:57 -0400 (EDT) From: "Thomas D. Nadeau" Content-Type: multipart/signed; boundary="Apple-Mail=_781F48AA-4B23-4017-886F-52D257BFCE3D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: Date: Mon, 21 Jul 2014 10:52:56 -0400 To: netmod@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/F-ZSRSZUg0z--6bmvVbXE-Tn-AM Subject: [netmod] Lada's question on github repo X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:52:59 -0000 --Apple-Mail=_781F48AA-4B23-4017-886F-52D257BFCE3D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii RE: your objection to initial commits, I think we can address = that easily by allowing the person who commits an initial file to be the = initial committer, and then that person manages commits going forward. = Longer term we probably wanted this model anyways so that this would = scale. As the project progresses, they can add additional committers = (or deleted stale ones). --Tom --Apple-Mail=_781F48AA-4B23-4017-886F-52D257BFCE3D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTzSlIAAoJEPcO+I7eiUJZhSoP/2zheuIenhh8dz4DI44nOsU+ SSBuAtxUgzd06PuNaUdzXu8n9xT55pXu/R0b3qs6lXDDHKiDSuI2jhj2HuxnovOi qUY63r5KdT4KOnoZXIm+ssrRaxw1O6TcpaZWVJrp1WQtqdoDihypbL6JPO9jwYNQ hnyIpJ2GLkByJu9i8Pi3cNSZqtpZ02R7ZVmvyFW6kzNF9ZRH8klCEZLyKUPP48b6 5sR02KvF9Nw4oV5bg1iaSO8uT5eLUI0R1tzx6FPiHIHJ4G+GYFb4Vrdc803O4UCU AMPIqnUTvGi7OoncMmEGCEsATGCEnZz6hAzKMs6eyWok+SjUstxhYTtsDH+wnQeb O4VEy5kisQczVTkPMMieICG50bG2PcjUogQs+luqdVKUFmizmrRy467u6ewS3TyQ Qdl/ZZGPFaU2c2xbspXFNh2rFnIid0h8G8pnAi7gCd4pqaAf4pit8ArURB3EFdIu 4LCUnXlLDOybZ8UwDCFJujG5JQ6NcbpK2UM2Op1uirlvhxsxSp5g0kekkca6o4Qg we2uU5nM3ddaVd/dcVtjK5UJuBX9ZAk4Nrrb2iqI9LsahZKJmuH/Vl1rJPecZgpA P6TyKgPFBKqvhZhdO3BB94hMOLajWB7FlHrGRCG71s0Rw/qlQ35dS9kHXGjmvtmO O08ne5gRdYQgxVr68VlE =7mqi -----END PGP SIGNATURE----- --Apple-Mail=_781F48AA-4B23-4017-886F-52D257BFCE3D-- From nobody Mon Jul 21 08:09:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DBE1A0172 for ; Mon, 21 Jul 2014 08:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-zRVia_ygXz for ; Mon, 21 Jul 2014 08:09:15 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0189.outbound.protection.outlook.com [207.46.163.189]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F33521A0235 for ; Mon, 21 Jul 2014 08:09:11 -0700 (PDT) Received: from CO1PR05MB427.namprd05.prod.outlook.com (10.141.74.12) by CO1PR05MB427.namprd05.prod.outlook.com (10.141.74.12) with Microsoft SMTP Server (TLS) id 15.0.990.7; Mon, 21 Jul 2014 15:09:02 +0000 Received: from CO1PR05MB427.namprd05.prod.outlook.com ([169.254.14.38]) by CO1PR05MB427.namprd05.prod.outlook.com ([169.254.14.38]) with mapi id 15.00.0990.007; Mon, 21 Jul 2014 15:09:02 +0000 From: Dean Bogdanovic To: "Thomas D. Nadeau" Thread-Topic: [netmod] Lada's question on github repo Thread-Index: AQHPpPN7PmOYdBEzI0OQXbPXLeu1LZuqoYGf Date: Mon, 21 Jul 2014 15:09:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.228.204.129] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0279B3DD0D x-forefront-antispam-report: SFV:NSPM; SFS:(979002)(6009001)(199002)(189002)(51704005)(24454002)(76482001)(83716003)(77982001)(64706001)(83322001)(50986999)(74502001)(106356001)(4396001)(106116001)(36756003)(74662001)(105586002)(101416001)(54356999)(21056001)(99286002)(99396002)(95666004)(19580395003)(19580405001)(76176999)(31966008)(79102001)(15975445006)(66066001)(20776003)(77096002)(86362001)(107046002)(2656002)(46102001)(83072002)(81342001)(85852003)(33656002)(110136001)(87936001)(85306003)(81542001)(82746002)(80022001)(92566001)(92726001)(104396001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB427; H:CO1PR05MB427.namprd05.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/gbPJq6K6hx7PXBcwsJyL6EubnWk Cc: "netmod@ietf.org" Subject: Re: [netmod] Lada's question on github repo X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 15:09:23 -0000 I'm in full support to such model. Dana B, Kiran S, Lisa H and I used that = model for ACL draft and worked without a problem.=20 Dean > On Jul 21, 2014, at 10:53, "Thomas D. Nadeau" w= rote: >=20 >=20 >=20 > RE: your objection to initial commits, I think we can address that eas= ily by allowing the person who commits an initial file to be the initial co= mmitter, and then that person manages commits going forward. Longer term w= e probably wanted this model anyways so that this would scale. As the proj= ect progresses, they can add additional committers (or deleted stale ones). >=20 > --Tom >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Jul 21 09:55:04 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905DB1A005F for ; Mon, 21 Jul 2014 09:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxPP2SG818sY for ; Mon, 21 Jul 2014 09:55:02 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1889A1A00CD for ; Mon, 21 Jul 2014 09:55:02 -0700 (PDT) Received: from dhcp-a243.meeting.ietf.org (dhcp-a243.meeting.ietf.org [31.133.162.67]) by mail.nic.cz (Postfix) with ESMTPSA id 3A2B313FCB9 for ; Mon, 21 Jul 2014 18:54:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1405961700; bh=cLz9xEECseTwmEr8rMT0bqza/nL4j1RE9XqJ9tmawts=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Message-Id: Date:To:Mime-Version; b=yGTpX4c8bZ9ssZ1OC7TMiSLqeHj/n3+RLaqa3ri7xcjKYO55tV1oH7l690AKJxYh7 EMK3v+tn8Imvh+xuXgclhStHsPrEDFI/GGTRA0ivicjGSRRZu6833bt/rE6MVpMa+W CWtYHDif121yEHTk2MIzM4f/AunUk196q/i7XXqA= From: Ladislav Lhotka Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <6E0D9C6F-AFB6-4325-B1BE-BD8DD48E5A82@nic.cz> Date: Mon, 21 Jul 2014 12:54:56 -0400 To: NETMOD Working Group Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/T9hqS2c_rqcPeoly_WY5SK1IuZk Subject: [netmod] tutorial slides X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 16:55:03 -0000 Hi, my presentation from yesterday=92s YANG Advice and Editing Session is = available here: = https://gitlab.labs.nic.cz/labs/yang-tools/blob/master/presentations/pyang= .pdf Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jul 21 10:01:23 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A01B1A0064 for ; Mon, 21 Jul 2014 10:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ELCG1MgDuiH for ; Mon, 21 Jul 2014 10:01:18 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id CD5701A002D for ; Mon, 21 Jul 2014 10:01:18 -0700 (PDT) Received: from [10.106.242.215] (mobile-198-228-205-188.mycingular.net [198.228.205.188]) by lucidvision.com (Postfix) with ESMTP id 962A3282BD52; Mon, 21 Jul 2014 13:01:17 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Thomas Nadeau X-Mailer: iPhone Mail (11D257) In-Reply-To: <6E0D9C6F-AFB6-4325-B1BE-BD8DD48E5A82@nic.cz> Date: Mon, 21 Jul 2014 13:01:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6E0D9C6F-AFB6-4325-B1BE-BD8DD48E5A82@nic.cz> To: Ladislav Lhotka Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2WoUaDqRE7Gy3ba3i8M5N2C4KwQ Cc: NETMOD Working Group Subject: Re: [netmod] tutorial slides X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 17:01:22 -0000 Thanks again for doing the presentation ! > On Jul 21, 2014, at 12:54 PM, Ladislav Lhotka wrote: >=20 > Hi, >=20 > my presentation from yesterday=E2=80=99s YANG Advice and Editing Session i= s available here: >=20 > https://gitlab.labs.nic.cz/labs/yang-tools/blob/master/presentations/pyang= .pdf >=20 > Lada >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From nobody Mon Jul 21 11:33:53 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD8E1A0350 for ; Mon, 21 Jul 2014 11:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCo9mN9F0GWr for ; Mon, 21 Jul 2014 11:33:51 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F06A1A036F for ; Mon, 21 Jul 2014 11:33:51 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id z60so5753802qgd.19 for ; Mon, 21 Jul 2014 11:33:50 -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=pKgQYFrwaQn9ognhpB3a5pqTVdMMTrF77J8gec3Uxcc=; b=OKC5uZcz1qkfnm8Y93Ht7EkopD9LYalOSxVQ5i1Kl39RL5xTwZCXgOAdymPewQAGiE 8cRTIuw3owW0LYRO/RVG3TUR+7OGf7mPTpvHMezIxgO8qofbPDDtBaTEJpItxCraz3WW 8JYgm045OXfn60R5BgWjWotqt7qPU2ccwfgZqRk6FcGDtoBufDcAmVMhydUBKMJjKRsD 43i9JptmSPSn99GJ5IBdThZ5fGrLQvfpZB63Hy+2hZi3nNbeNBm7kzVA488MBdf1rfsy 4IZre2Zj1lkTcKpPQKrBbmo2RnnI7msxjAoMf0L07jHiGclr+ypPcQ8lGqi8ebEa2Veg 6erQ== X-Gm-Message-State: ALoCoQlQHL/BOdbOi2T6gSnS5RkEeSZXLvpUXrdxpH4IXc98qFHUhUMrsytGZ575cR7/Oek+pitK MIME-Version: 1.0 X-Received: by 10.140.94.138 with SMTP id g10mr41417391qge.90.1405967630321; Mon, 21 Jul 2014 11:33:50 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Mon, 21 Jul 2014 11:33:50 -0700 (PDT) Date: Mon, 21 Jul 2014 11:33:50 -0700 Message-ID: From: Andy Bierman To: Netconf , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a113a4eda2c4e6104feb85949 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/MM-BKMCHZemDs2_Sd5c90YwWx_g Subject: [netmod] NETCONF/YANG tutorial for SNMP Developers X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 18:33:52 -0000 --001a113a4eda2c4e6104feb85949 Content-Type: text/plain; charset=ISO-8859-1 FYI, There is a new NETCONF tutorial available online in case people want to learn more about NETCONF/YANG. It assumes a little SNMP knowledge but should be readable even if you don't know about SNMP or SMIv2. http://dld.netconfcentral.org/doc/ncorg_netconf_yang_tutorial.pdf Andy --001a113a4eda2c4e6104feb85949 Content-Type: text/html; charset=ISO-8859-1
FYI,

There is a new NETCONF tutorial available online in case
people want to learn more about NETCONF/YANG.
It assumes a little SNMP knowledge but should be readable
even if you don't know about SNMP or SMIv2.





Andy


--001a113a4eda2c4e6104feb85949-- From nobody Mon Jul 21 13:45:32 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3E31A043D for ; Mon, 21 Jul 2014 13:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwtQkExkHX-k for ; Mon, 21 Jul 2014 13:45:29 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D42D61A0328 for ; Mon, 21 Jul 2014 13:45:28 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4AAFBA89; Mon, 21 Jul 2014 22:45:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 55JnyWifTKru; Mon, 21 Jul 2014 22:45:22 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 21 Jul 2014 22:45:26 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7E2CB2002C; Mon, 21 Jul 2014 22:45:26 +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 536Ay15SZEX6; Mon, 21 Jul 2014 22:45:25 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9E4CF20017; Mon, 21 Jul 2014 22:45:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C73E92DDF15E; Mon, 21 Jul 2014 22:45:23 +0200 (CEST) Date: Mon, 21 Jul 2014 22:45:23 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20140721204523.GA9966@elstar.local> Mail-Followup-To: Randy Presuhn , Benoit Claise , NETMOD Working Group References: <14507864.1402339265349.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14507864.1402339265349.JavaMail.root@mswamui-cedar.atl.sa.earthlink.net> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/0tceFXiKfEfX1yuVPwt-W08yQww Cc: NETMOD Working Group Subject: Re: [netmod] AD review: draft-ietf-netmod-snmp-cfg-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jul 2014 20:45:30 -0000 On Mon, Jun 09, 2014 at 11:41:05AM -0700, Randy Presuhn wrote: > Hi - > > >From: Juergen Schoenwaelder > >Sent: Jun 7, 2014 12:02 AM > >To: Benoit Claise > >Cc: draft-ietf-netmod-snmp-cfg@tools.ietf.org, NETMOD Working Group > >Subject: Re: [netmod] AD review: draft-ietf-netmod-snmp-cfg-05 > ... > >Concerning "designed to": The data model has been designed to cover > >everything that the SNMP configuration models describe. It allows an > >implementation that supports both configuration via NETCONF and > >configuration via SNMP. The details are discussed in section 3.2. > > When SNMP is used to change the value of an > instance of vacmGroupName in the vacmSecurityToGroupTable, > some side-effects will need to happen in the netconf datastores, > due to the decision to model the information differently. > I know this has come up before, but it's unclear to me what > needs to happen on the netconf server side in a couple > of specific cases: > > (1) If the vacmGroupName has a value that hasn't been seen before, > a "group" obviously needs to be created as a side-effect in > netconf land. What's less obvious is what happens to the > old "group" in the case where no other entries in the > vacmSecurityToGroupTable still have that particular value > for vacmGroupName. Is it to be automagically deleted > because the security-model's min-elements constrainted > would otherwise be violated? We previously removed the min-elements from the 'member' list and as such it is not necessary to remove the group until all references to it have been removed. The min-elements of the 'security-model' only applies if an instance exists in the 'member' list, which seems to be consistent with the way VACM works. > (2) Likewise, when the value of the StorageType of an entry > in vacmSecurityToGroupTable is modified from nonVolatile > to volatile, does similar "garbage collection" have > to happen as a side-effect? An implementation may do garbage collection if no nonVolatile references to a group exist anymore. > (3) When the entry in vacmSecurityToGroupTable is volatile, > and some (but not all) of the corresponding vacmAccessTable > entries are nonVolatile, what happens in the netconf datastores? In this case the configuration datastore would only store the group without any members. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jul 21 13:48:32 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4F51A0328 for ; Mon, 21 Jul 2014 13:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzRWyx9esilr for ; Mon, 21 Jul 2014 13:48:29 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B09921A0070 for ; Mon, 21 Jul 2014 13:48:28 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7293AEB2; Mon, 21 Jul 2014 22:48:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id gGYkj4UhpPmp; Mon, 21 Jul 2014 22:48:22 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 21 Jul 2014 22:48:26 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 88A942002C; Mon, 21 Jul 2014 22:48:26 +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 tX82ExF1P16J; Mon, 21 Jul 2014 22:48:24 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1F01420017; Mon, 21 Jul 2014 22:48:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 12E0B2DDF1A0; Mon, 21 Jul 2014 22:48:24 +0200 (CEST) Date: Mon, 21 Jul 2014 22:48:24 +0200 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20140721204824.GA10157@elstar.local> Mail-Followup-To: Benoit Claise , NETMOD Working Group , draft-ietf-netmod-snmp-cfg@tools.ietf.org References: <538D7EF7.4030202@cisco.com> <538DF48C.6030605@cisco.com> <20140607070213.GA21144@elstar.local> <53A04683.3040308@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53A04683.3040308@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7UgRtrans5PvcDAmCNhbFSqrziI Cc: draft-ietf-netmod-snmp-cfg@tools.ietf.org, NETMOD Working Group Subject: Re: [netmod] AD review: draft-ietf-netmod-snmp-cfg-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jul 2014 20:48:31 -0000 On Tue, Jun 17, 2014 at 03:45:39PM +0200, Benoit Claise wrote: > >>My feedback: > >>- > >> > >> The configuration data model in particular_targets_SNMP deployments > >> where SNMP runs in read-only mode and NETCONF is used to configure > >> the SNMP agent. Nevertheless, the data model has been_designed_to > >> allow implementations that support write access both via SNMP and > >> NETCONF in order to interwork with SNMP-managed management > >> applications manipulating SNMP agent configuration using SNMP. > >> > >> The YANG data model focuses on configuration. > >> > >>I don't understand what you mean by "targets" or "designed to" > >>So you made some tradeoffs in the design? Is this the way we should > >>understand this? > >>If which one? > >I think "in particular targets" should be read as in "will likely be > >primarily used in". Or to say it in other words: If a deployment uses > >SNMP to configure SNMP agents, then this data model may be of limited > >value. > I didn't read this way the first time. Maybe it's only me... > > > >Concerning "designed to": The data model has been designed to cover > >everything that the SNMP configuration models describe. It allows an > >implementation that supports both configuration via NETCONF and > >configuration via SNMP. The details are discussed in section 3.2. > I didn't read this way the first time. Your new wording makes it clearer > to me. > Again, maybe it's just me... We tried to improve the text. Please check the next version of the I-D. > >>- At the beginning of VACM and SNMP, we faced one issue. Someone with a > >>read-only community string could query the read-write community string. > >> > >> > >>Router#sh run | i snmp > >> > >>snmp-server engineID local 000000090200009092827820 > >> > >>snmp-server group v1group v1 read includeeverything > >> > >>snmp-server view includeeverything internet included > >> > >>snmp-server community _claise _RW > >> > >>snmp-server user _public _v1group v1 > >> > >>... > >> > >>"snmpwalk -v 1 _public _internet.6.3.16 | grep _claise_"... you > >>would be surprised > >> > >>Basically, the trick is that we need a default view on VACM. > >>I see http://tools.ietf.org/html/rfc3415#section-7.4 > >>Do we need something specific in this draft to stress that issue? > >I do not think that this document is the place to discuss how default > >VACM rules should look like. This should go into a separate document > >because this is not specific to the YANG data model but rather > >specific to VACM. > Yes, this is specific to VACM, but having an extra document just for > this might be an overkill. > Adding one sentence in the Security Considerations would be make IMO. We have added some additional text and we also tagged the community such that NACM by default denies access. The other editorial issues have been dealt with as well. There should be an announcement of the new I-D shortly. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jul 21 14:16:20 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1A51A04BA for ; Mon, 21 Jul 2014 14:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPNMNSuN6zmG for ; Mon, 21 Jul 2014 14:16:17 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6CED1A03F6 for ; Mon, 21 Jul 2014 14:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1091; q=dns/txt; s=iport; t=1405977378; x=1407186978; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=woTp4E7KCaM6ZI8r118sjtZX6IQSBxh3if8Ew8cFr7U=; b=RDRW/+BmsI6Tb2DOwqZWExY+ma87IL3T8YhBeimqW31/km7eng3x9GZz fXjvaGPcSbqJGn3bA5L08XmjFMoTrUGtBHUzPBcstrEoqP0P7bbrr944A ZQOsfAe2jq/sNsPRDpETkQ61gV4UiRc5/FAams/3R0V2AW06WSi/dAFaE 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAAKCzVOtJA2B/2dsb2JhbABZgmokUlcExnyHQ4EhFnaECAJ5EgGBACcEDg6IOQEMvxcXj0uETQWKK5B6gU2SYoNEbAGBRA X-IronPort-AV: E=Sophos;i="5.01,704,1400025600"; d="scan'208";a="62808512" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP; 21 Jul 2014 21:16:17 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6LLGHle022892 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Jul 2014 21:16:17 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Mon, 21 Jul 2014 16:16:16 -0500 From: "Clyde Wildes (cwildes)" To: "netmod@ietf.org" Thread-Topic: Syslog YANG Model Presentation Thread-Index: AQHPpSkC2ZiRgh9DtUicY+pcm0HXCA== Date: Mon, 21 Jul 2014 21:16:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.116.153] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/KoVfy_SlnH1moPYabvCZXd2eAEA Cc: Kiran Agrahara Sreenivasa Subject: [netmod] Syslog YANG Model Presentation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 21:16:19 -0000 Hi, Please check out the Syslog YANG Model presentation that I was unable to give this morning due to time constraints at: http://tools.ietf.org/agenda/90/slides/slides-90-netmod-6.pdf My narrative is that in a relatively short time Kiran Koushshik (Brocade) and I were able to collaborate on a Syslog YANG model that covers common Syslog configuration for Brocade=B9s OS, Cisco IOS/XE, Cisco IOS/XR, Cisco/NXOS, and Juniper=B9s JunOS. The model consists of a group suppressio= n leaf, and four distributions leaves for: console, file, remote server, and terminal/user. The model was designed to be augmented for OS specific features, and the model has been implemented on Cisco=B9s NXOS with an augmentation model for OS specific features. We attended the YANG Drs=B9 session on Sunday and received valuable feedback from Bert Wijnen, from RIPE. Thanks Bert! The latest draft of the proposed Syslog YANG Model RFC is at: http://www.ietf.org/internet-drafts/draft-wildes-netmod-syslog-model-02.txt Your review and comments would be appreciated. Thanks, Clyde From nobody Mon Jul 21 14:23:31 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C3D1A0452 for ; Mon, 21 Jul 2014 14:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKMDdg0upJCE for ; Mon, 21 Jul 2014 14:23:29 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBEC91A03E5 for ; Mon, 21 Jul 2014 14:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3844; q=dns/txt; s=iport; t=1405977809; x=1407187409; h=from:to:subject:date:message-id:mime-version; bh=k+/7sxmN2xSR/0rxGZ9T0GtoKA0hVEDdA1yfmspal6Q=; b=jWlwP9qARyzH7pLjoxS9khQdcPgl8YSyAGM1JllD1FLqOGLoSk7oML3j Tk7stcFgewnE28D/gCo6ZjgA4ufdGJu8CGaZLAqaIWetuPtJYPgaEbuox 1ekSGvyCpzFVqgk3bx1Tpq6UJaxPUu0hyZ97A6edTqQ+7JiGFubkW8R/8 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAFiEzVOtJV2b/2dsb2JhbABZgkdHUlvOPwGBIBZ2hAUBBC1eAQweVh8HAQQbiDqYcqY4F48ag2aBGAWOQ6ERg0SCMQ X-IronPort-AV: E=Sophos; i="5.01,704,1400025600"; d="scan'208,217"; a="62754247" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP; 21 Jul 2014 21:23:23 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6LLNNSo005416 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Jul 2014 21:23:23 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.152]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Mon, 21 Jul 2014 16:23:22 -0500 From: "Tissa Senevirathne (tsenevir)" To: "netmod@ietf.org" Thread-Topic: presentations of other drafts Thread-Index: Ac+lKfzukBqJ/cWAQUOUWtSpzXyz1g== Date: Mon, 21 Jul 2014 21:23:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.64.116] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562EECEFF2xmbrcdx08ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/90DgI99I0puEp0vZywZsaW3VDoM Subject: [netmod] presentations of other drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 21:23:30 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE193562EECEFF2xmbrcdx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG chairs I am pleased that WG has opened up the charter for new YANG models. However= , the way time was managed today for new drafts was not the best, to say th= e least. If the WG is serious of encouraging new YANG models to go through netmod WG= , my suggestion is WG to allocate portion of the meeting say 20 mins for ne= w YANG models and WG chairs to manage that time effectively and efficiently= . Allocating 5 mins to a draft is actually meaningless. That time would take = someone to walk up to the mic and pin the microphone and say good morning. = Allocating sizable chunk to new work carve out the time needed for new work= . My 2 bits. Thanks Tissa --_000_FBEA3E19AA24F847BA3AE74E2FE193562EECEFF2xmbrcdx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear WG chairs

 

I am pleased that WG has opened up the charter for n= ew YANG models. However, the way time was managed today for new drafts was = not the best, to say the least.

 

If the WG is serious of encouraging new YANG models = to go through netmod WG, my suggestion is WG to allocate portion of the mee= ting say 20 mins for new YANG models and WG chairs to manage that time effe= ctively and efficiently.

 

Allocating 5 mins to a draft is actually meaningless= . That time would take someone to walk up to the mic and pin the microphone= and say good morning. Allocating sizable chunk to new work carve out the t= ime needed for new work.

 

My 2 bits.

 

Thanks

Tissa

--_000_FBEA3E19AA24F847BA3AE74E2FE193562EECEFF2xmbrcdx08ciscoc_-- From nobody Mon Jul 21 14:38:34 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734651A08F8 for ; Mon, 21 Jul 2014 14:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIacLhUO-w6x for ; Mon, 21 Jul 2014 14:38:30 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AF711A063C for ; Mon, 21 Jul 2014 14:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15192; q=dns/txt; s=iport; t=1405978712; x=1407188312; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=9Nfe56txrZdvpfAsnaNHLF0MB0BRvTFMP5G/RlGU9pc=; b=eXQP0i1R44jeNE6gfUR2hDSOUW+3YG1DZq++BAp5b57d3W2ufpE2sFwW ApZoZmktR6sgCOMgolXdGh80lsIWbbEi/8vmjD0oBVs6gGf9e781L5AJw 4qT8t9Xk53AfxzzozGjJs0v+Iam639NVUmPthqREklJGOKT+gwMX8r+Rb M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuoWAAmIzVOtJA2H/2dsb2JhbABZgkdHUlcEhBDBCYFXAQuGcFMBgSAWdoQEAQEEAQEBawkUAQg/LgsUCAkCBAESCYg5Db8jF49HC4RGBY5DjGKBTZJiggKBQmwBgUQ X-IronPort-AV: E=Sophos;i="5.01,704,1400025600"; d="scan'208,217";a="341779438" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-8.cisco.com with ESMTP; 21 Jul 2014 21:38:31 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6LLcTtY012771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Jul 2014 21:38:29 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Mon, 21 Jul 2014 16:38:29 -0500 From: "Lisa Huang (yihuan)" To: "Clyde Wildes (cwildes)" , "netmod@ietf.org" Thread-Topic: [netmod] FW: New Version Notification for draft-wildes-netmod-syslog-model-00.txt Thread-Index: AQHPkZMp5tIX3Csi/kmACQV2dQR/PZuD8rAAgCdTI4A= Date: Mon, 21 Jul 2014 21:38:29 +0000 Message-ID: In-Reply-To: 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.82.238.99] Content-Type: multipart/alternative; boundary="_000_CFF2F6BC39C53yihuanciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/VX8xPiwTzixBzl9ChzCGPKJoq24 Subject: Re: [netmod] FW: New Version Notification for draft-wildes-netmod-syslog-model-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 21:38:32 -0000 --_000_CFF2F6BC39C53yihuanciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Clyde, Here are my initial comments: 1. leaf file-name { type string; mandatory true; description "This leaf specifies the name of the log file."; } This file-name leaf doesn't reflect what is in the system. What is the reas= on that uri is not use? 2. In leaf destination { type string; description "The leaf uniquely specifies the address of the remote host. One of the following must be specified: an ipv4 address, an ipv6 address, or a host name."; } type string for destination doesn't reflect the actual destination. Type un= ion allows to model the type with host and ip-address. 3. In leaf source-interface { type string; description "This leaf sets the source interface for the remote Syslog server. Either the interface name or the interface IP address can be specified."; } it has a similar case to #2. String is too wide to reference an interface. 4. syslogtypes:kern syslogtypes:critical syslogtypes:auth syslogtypes:error This xml example should be around the facility and sever= ity as the following. syslogtypes:kern syslogtypes:critical syslogtypes:auth syslogtypes:error 5. choice logging-scope { description "This choice describes the option to specify all facilities or a specific facility."; case all-facilities { description "This case specifies all facilities."; leaf logging-severity { type syslogtypes:Severity; description "This leaf specifies the severity of Syslog messages for all facilities."; } } This choice is repeated in multiple different place. For readability and ma= intainability, it would be a good case to use augment and add new case stat= ement when needed. Thanks, Lisa On 6/26/14 5:06 PM, "Clyde Wildes (cwildes)" > wrote: FYI and comments... Here is an initial draft proposal for a YANG model for Syslog. Thanks, Clyde On 6/26/14, 4:05 PM, "internet-drafts@ietf.org" > wrote: A new version of I-D, draft-wildes-netmod-syslog-model-00.txt has been successfully submitted by Kiran Koushik Agrahara and posted to the IETF repository. Name: draft-wildes-netmod-syslog-model Revision: 00 Title: SYSLOG YANG model Document date: 2014-06-26 Group: Individual Submission Pages: 19 URL: http://www.ietf.org/internet-drafts/draft-wildes-netmod-syslog-model-00.tx t Status: https://datatracker.ietf.org/doc/draft-wildes-netmod-syslog-model/ Htmlized: http://tools.ietf.org/html/draft-wildes-netmod-syslog-model-00 Abstract: This document describes a data model for Syslog protocol which is used to convey event notification messages. 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 --_000_CFF2F6BC39C53yihuanciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <15A6430C01AF3E4AB919B2D5FE47BC8A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Clyde,

Here are my initial comments:

1. leaf file-name {
        type string;
        mandatory true;
        description
          "This leaf specifies the name of the log file.";

      }
This file-name leaf doesn't reflect wh= at is in the system. What is the reason that uri is not use?

2. In
leaf destination {
type string;
description
"The leaf uniquely specifies the address of the remote host. One =
of the following must be specified: an ipv4 address, an ipv6
address, or a host name.";
}

type string for destination doesn't reflect the actual destination. Ty= pe union allows to model the type with host and ip-address.

3. In
leaf source-interface {
type string;
description
"This leaf sets the source interface for the remote
Syslog server. Either the interface name or the
interface IP address can be specified.";
}

it has a similar case to #2. String is= too wide to reference an interface.

4. 

<global-logging>
<facility>syslogtypes:kern</facility>
<severity>syslogtypes:critical</severity>
<facility>syslogtypes:auth</facility>
<severity>syslogtypes:error</severity>
</global-logging>

This xml example should be <logging-severity/>around the fac= ility and severity as the following.

<global-logging>
 <logging-s= everity><facility>syslogtypes:kern</facility>
<severity>syslogtypes:critical</severity></logging-severity>
<logging-severity><facility>= ;syslogtypes:auth</facility>
<severity>syslogtypes:error</= severity></logging-severity>
</global-logging>


5. 
choice logging-scope {
              description
                "This choice describes the option to specify all=20
                 facilities or a specific facility.";
              case all-facilities {
                description
                  "This case specifies all facilities.";
                leaf logging-severity {
                  type syslogtypes:Severity;
                  description
                    "This leaf specifies the severity of Syslog=20
                     messages for all facilities.";
                }
              }

This choice is repeated in multiple different =
place. For readability and maintainability, it would be a good case to use =
augment and add new case statement when needed.

Thanks,
Lisa

On 6/26/14 5:06 PM, "Clyde Wildes= (cwildes)" <cwildes@cisco.com= > wrote:

FYI and comments...

Here is an initial draft proposal for a YANG model for Syslog.

Thanks,

Clyde

wrote:


A new version of I-D, draft-wildes-netmod-syslog-model-00.txt
has been successfully submitted by Kiran Koushik Agrahara and posted t= o
the
IETF repository.

Name: = draft-wilde= s-netmod-syslog-model
Revision: 00
Title: SYSLOG YAN= G model
Document date: 2014-06-26
Group: Individual= Submission
Pages: 19
URL:           =  
t
Status:        
Htmlized:      
http://tools.ietf.org/html/draft-wildes-netmod-syslog-model-00


Abstract:
   This document describes a data model for Syslog
   protocol which is used to convey event notification messa= ges.

           &nbs= p;      
        


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

--_000_CFF2F6BC39C53yihuanciscocom_-- From nobody Mon Jul 21 19:08:17 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7CB1A02ED for ; Mon, 21 Jul 2014 19:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4xHhTzKs-QF for ; Mon, 21 Jul 2014 19:08:14 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 649B81A02E4 for ; Mon, 21 Jul 2014 19:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=417; q=dns/txt; s=iport; t=1405994895; x=1407204495; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=jArX18QXIxZAGWlrhXRFgV3qnoImHOiYmvw57T9aS8w=; b=FynnW6Kj1rQI+dlPRzl+NzWGTmiWp/aV1fuPZCeNQwp1ZfgjlTwbRFcD V0SB0YoarH/+pIgq/73BvRC+G8WMqRbqUeb9jUJCyDXNm8XAK/VVzc4PK HRB/jlwx7GMR7R8n6begKpgJdTw4kvoV1NKXrp/qZbIuWnOgvlPhaF5Ah I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8NANzGzVOtJA2F/2dsb2JhbABZgw5SWMZ1hzsBCQGBFhZ2hAQBAQQyAQVAEQshFg8JAwIBAgFFEwgBAYg+Db5QF4wsgyYWhDABBJslgU2FSI0ag2Ah X-IronPort-AV: E=Sophos;i="5.01,706,1400025600"; d="scan'208";a="341828516" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP; 22 Jul 2014 02:08:14 +0000 Received: from [10.82.219.128] (rtp-vpn3-892.cisco.com [10.82.219.128]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s6M28CDn022774 for ; Tue, 22 Jul 2014 02:08:12 GMT Message-ID: <53CDC78B.5010404@cisco.com> Date: Mon, 21 Jul 2014 22:08:11 -0400 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: netmod@ietf.org References: <20140527150408.GB4621@elstar.jacobs.jacobs-university.de> In-Reply-To: <20140527150408.GB4621@elstar.jacobs.jacobs-university.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/zKhM1Zi1ltkHEaBmeA1CFlpwx_w Subject: Re: [netmod] request for publications: A YANG Data Model for Routing Management X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 02:08:16 -0000 Jürgen, Based on the discussion today, this draft goes back to the WG, and the new status is "AD Watching" Regards, Benoit > Benoit, > > attached please find the document writeup for the routing document. > > http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-15 > > The netmod wg would hereby like to ask the IESG to consider this > document for publication as proposed standard. > > /js > From nobody Tue Jul 22 06:34:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78691B27DF for ; Tue, 22 Jul 2014 06:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_44=0.6, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyLdCDhedGld for ; Tue, 22 Jul 2014 06:34:41 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42FA91B27DA for ; Tue, 22 Jul 2014 06:34:41 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B39A6101A; Tue, 22 Jul 2014 15:34:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 7TrRu_mS77ON; Tue, 22 Jul 2014 15:34:30 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 22 Jul 2014 15:34:37 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9017320017; Tue, 22 Jul 2014 15:34:37 +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 iHFLcxIRMM67; Tue, 22 Jul 2014 15:34:36 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E48020031; Tue, 22 Jul 2014 15:34:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 839742DDF7C4; Tue, 22 Jul 2014 15:34:36 +0200 (CEST) Date: Tue, 22 Jul 2014 15:34:36 +0200 From: Juergen Schoenwaelder To: "Lisa Huang (yihuan)" Message-ID: <20140722133436.GC11781@elstar.local> Mail-Followup-To: "Lisa Huang (yihuan)" , "Clyde Wildes (cwildes)" , "netmod@ietf.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/x9c9ld8LK6T1EutZCNIpwHUhkJ0 Cc: "netmod@ietf.org" Subject: Re: [netmod] FW: New Version Notification for draft-wildes-netmod-syslog-model-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 22 Jul 2014 13:34:43 -0000 On Mon, Jul 21, 2014 at 09:38:29PM +0000, Lisa Huang (yihuan) wrote: > 2. In > leaf destination { > type string; > description > "The leaf uniquely specifies the address of the remote host. One > of the following must be specified: an ipv4 address, an ipv6 > address, or a host name."; > } > > type string for destination doesn't reflect the actual destination. Type union allows to model the type with host and ip-address. This should probably be inet:host [RFC6991] or something like that. And there should most likely be a port number. And the key should not be the destination IP address. > 3. In > leaf source-interface { > type string; > description > "This leaf sets the source interface for the remote > Syslog server. Either the interface name or the > interface IP address can be specified."; > } > > it has a similar case to #2. String is too wide to reference an interface. Yes, I agree. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Jul 22 08:06:11 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800751A02D0 for ; Tue, 22 Jul 2014 08:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZJL9Yv6uVjU for ; Tue, 22 Jul 2014 08:06:00 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7755D1B2886 for ; Tue, 22 Jul 2014 08:06:00 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 191941110; Tue, 22 Jul 2014 17:05:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 4EqTAncFsdlz; Tue, 22 Jul 2014 17:05:51 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 22 Jul 2014 17:05:58 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6D7092002C; Tue, 22 Jul 2014 17:05:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FxCLXwwEbGF7; Tue, 22 Jul 2014 17:05:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3048020017; Tue, 22 Jul 2014 17:05:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D77A92DDF962; Tue, 22 Jul 2014 17:05:55 +0200 (CEST) Date: Tue, 22 Jul 2014 17:05:55 +0200 From: Juergen Schoenwaelder To: "Clyde Wildes (cwildes)" Message-ID: <20140722150553.GB12083@elstar.local> Mail-Followup-To: "Clyde Wildes (cwildes)" , "netmod@ietf.org" , Kiran Agrahara Sreenivasa References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/77BMlJhblxjuSQy99XYKAw-AbPE Cc: Kiran Agrahara Sreenivasa , "netmod@ietf.org" Subject: Re: [netmod] Syslog YANG Model Presentation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 22 Jul 2014 15:06:02 -0000 On Mon, Jul 21, 2014 at 09:16:16PM +0000, Clyde Wildes (cwildes) wrote: > > The latest draft of the proposed Syslog YANG Model RFC is at: > http://www.ietf.org/internet-drafts/draft-wildes-netmod-syslog-model-02.txt > The traditional Unix syslog daemons usually understand configuration rules like this: *.=info;*.=notice;*.=warn;\ auth,authpriv.none;\ cron,daemon.none;\ mail,news.none -/var/log/messages That is, you have rules with multiple selectors that lead to a certain action. Note also the various wildcards above. You seem to model this backwards, that is the action first followed by the selectors - why? I think using the terminology of 'selectors' and 'actions' is quite common in Unix syslog land - perhaps this should be adopted instead of 'Message Distributors' and related terms. It seems some syslog implementations (e.g. rsyslog) have a more general concept of a filter and selectors (matching facility/severity) and just one of several ways to filter. /js PS: I think you should also refer to the standards-track version of SYSLOG (RFC 5424) in the references and perhaps filters should also be able to operate on structured content. PS: I do not really understand 'global logging'. PS: A configuration model should probably also include ways to configure on which endpoints the syslog 'daemon' is receiving input. PS: The reference in the revision statement is usually used to refer to the document defining that specific revision of the data model. PS: For the example, simple show the config instance not the NETCONF exchange. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Jul 22 10:44:55 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28171A01B0 for ; Tue, 22 Jul 2014 10:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQSexK7Z3MJT for ; Tue, 22 Jul 2014 10:44:52 -0700 (PDT) Received: from bgl-iport-4.cisco.com (bgl-iport-4.cisco.com [72.163.197.28]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D82C81A0064 for ; Tue, 22 Jul 2014 10:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1825; q=dns/txt; s=iport; t=1406051092; x=1407260692; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=QmSYpYrR/5lqyzpD6r/04EXWiJfKkjh4sXpLkrqgWD0=; b=fFvpKw+La8LkIlx/8rELNq+X/JrvF+EJsUAqhFnxjhzg/tOwMvK7TvW8 2wrinW93Z1Mc1wcdW/R5yak2X2Rmd18R5Cei0qnRkJbB3COM34Bc60fgC RGLxUZC5mao1HURV5bXsh2Crj/dbErkgeYL9ckYhNAz1bWvDWJEgt0pip 8=; X-IronPort-AV: E=Sophos;i="5.01,711,1400025600"; d="scan'208";a="12661243" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-4.cisco.com with ESMTP; 22 Jul 2014 17:44:49 +0000 Received: from [10.21.81.253] (sjc-vpn4-509.cisco.com [10.21.81.253]) by bgl-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6MHijYq005075; Tue, 22 Jul 2014 17:44:46 GMT Message-ID: <53CEA093.2070000@cisco.com> Date: Tue, 22 Jul 2014 13:34:11 -0400 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Clyde Wildes (cwildes)" , "netmod@ietf.org" , Kiran Agrahara Sreenivasa References: <20140722150553.GB12083@elstar.local> In-Reply-To: <20140722150553.GB12083@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qJBzLgL8kJpVf-KfAEXiSzSrLFA Subject: Re: [netmod] Syslog YANG Model Presentation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 17:44:54 -0000 On 22/07/2014 11:05, Juergen Schoenwaelder wrote: > On Mon, Jul 21, 2014 at 09:16:16PM +0000, Clyde Wildes (cwildes) wrote: >> The latest draft of the proposed Syslog YANG Model RFC is at: >> http://www.ietf.org/internet-drafts/draft-wildes-netmod-syslog-model-02.txt >> > The traditional Unix syslog daemons usually understand configuration > rules like this: > > *.=info;*.=notice;*.=warn;\ > auth,authpriv.none;\ > cron,daemon.none;\ > mail,news.none -/var/log/messages > > That is, you have rules with multiple selectors that lead to a certain > action. Note also the various wildcards above. You seem to model this > backwards, that is the action first followed by the selectors - why? > I think using the terminology of 'selectors' and 'actions' is quite > common in Unix syslog land - perhaps this should be adopted instead of > 'Message Distributors' and related terms. It seems some syslog > implementations (e.g. rsyslog) have a more general concept of a filter > and selectors (matching facility/severity) and just one of several > ways to filter. > > /js > > PS: I think you should also refer to the standards-track version of > SYSLOG (RFC 5424) in the references and perhaps filters should > also be able to operate on structured content. Is RFC 5424 actually deployed? Regards, Benoit > > PS: I do not really understand 'global logging'. > > PS: A configuration model should probably also include ways to > configure on which endpoints the syslog 'daemon' is receiving > input. > > PS: The reference in the revision statement is usually used to refer > to the document defining that specific revision of the data model. > > PS: For the example, simple show the config instance not the NETCONF > exchange. > From nobody Tue Jul 22 10:46:19 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523411A01B0 for ; Tue, 22 Jul 2014 10:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CH6aTHJ1Y5E8 for ; Tue, 22 Jul 2014 10:46:15 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D314D1A0064 for ; Tue, 22 Jul 2014 10:46:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6419; q=dns/txt; s=iport; t=1406051175; x=1407260775; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=W8zsoTn1sOju70yeOSWvlYP2eX0zLQ12d8PILOJM0og=; b=d+qA8o01I4xVr/dZx8EI2XE+s+ZEINiMLCAGmC0LhqQ04rtw88BCFbEh eU8zJ2k+muffyzL+/VQscV/Y++m1045WvMfqOEXdWpAXlbUp6FHhOAKDM 2en0M9rJZlVBp+ezU9KP8C3aFsHQI4Q/FWEhRJVZyqz+i+rD0SZa7wXXF s=; X-IronPort-AV: E=Sophos; i="5.01,711,1400025600"; d="scan'208,217"; a="43127636" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 22 Jul 2014 17:46:12 +0000 Received: from [10.21.81.253] (sjc-vpn4-509.cisco.com [10.21.81.253]) by bgl-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6MHk6SD022371; Tue, 22 Jul 2014 17:46:08 GMT Message-ID: <53CEA08E.80002@cisco.com> Date: Tue, 22 Jul 2014 13:34:06 -0400 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Tissa Senevirathne (tsenevir)" , "netmod@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080103010602010002020509" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/O85abyOzF0i4kN73xQnRDf0idys Subject: Re: [netmod] presentations of other drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 17:46:18 -0000 This is a multi-part message in MIME format. --------------080103010602010002020509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tissa, Having many YANG models is a good problem to have IMO. This implies that YANG (and NETCONF) has been going in the right direction the last couple of years. I'm sorry that the YANG data models have not been presented, but the WG should focus on the WG documents first. Now, not being able to present the drafts must not prevent you and the community to work on the drafts on the different mailings (whether NETMOD or not). Finally, let's not forget that the YANG doctors reviewed some of the documents during the Sunday session * YANG Model for Access Control Lists 11:00 [ 5 min] * YANG Model for SYSLOG 11:05 [ 5 min] * YANG Model for OAM 11:10 [ 5 min] * YANG Model for WDM Interfaces 11:15 [ 5 min] Let me discuss with the chairs on what we can do better next time. Regards, Benoit (OPS AD) > > Dear WG chairs > > I am pleased that WG has opened up the charter for new YANG models. > However, the way time was managed today for new drafts was not the > best, to say the least. > > If the WG is serious of encouraging new YANG models to go through > netmod WG, my suggestion is WG to allocate portion of the meeting say > 20 mins for new YANG models and WG chairs to manage that time > effectively and efficiently. > > Allocating 5 mins to a draft is actually meaningless. That time would > take someone to walk up to the mic and pin the microphone and say good > morning. Allocating sizable chunk to new work carve out the time > needed for new work. > > My 2 bits. > > Thanks > > Tissa > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------080103010602010002020509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Tissa,

Having many YANG models is a good problem to have IMO. This implies that YANG (and NETCONF) has been going in the right direction the last couple of years.

I'm sorry that the YANG data models have not been presented, but the WG should focus on the WG documents first. Now, not being able to present the drafts must not prevent you and the community to work on the drafts on the different mailings (whether NETMOD or not).

Finally, let's not forget that the YANG doctors reviewed some of the documents during the Sunday session
* YANG Model for Access Control Lists		11:00	[ 5 min]
* YANG Model for SYSLOG				11:05	[ 5 min]
* YANG Model for OAM				11:10	[ 5 min]
* YANG Model for WDM Interfaces			11:15	[ 5 min]
Let me discuss with the chairs on what we can do better next time.

Regards, Benoit (OPS AD)

Dear WG chairs

 

I am pleased that WG has opened up the charter for new YANG models. However, the way time was managed today for new drafts was not the best, to say the least.

 

If the WG is serious of encouraging new YANG models to go through netmod WG, my suggestion is WG to allocate portion of the meeting say 20 mins for new YANG models and WG chairs to manage that time effectively and efficiently.

 

Allocating 5 mins to a draft is actually meaningless. That time would take someone to walk up to the mic and pin the microphone and say good morning. Allocating sizable chunk to new work carve out the time needed for new work.

 

My 2 bits.

 

Thanks

Tissa



_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--------------080103010602010002020509-- From nobody Tue Jul 22 10:48:17 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94911A0162 for ; Tue, 22 Jul 2014 10:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.901 X-Spam-Level: X-Spam-Status: No, score=-13.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxOjGXn-ACEG for ; Tue, 22 Jul 2014 10:48:11 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B001A00F2 for ; Tue, 22 Jul 2014 10:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18857; q=dns/txt; s=iport; t=1406051291; x=1407260891; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=5tZ7pUEl2Te2qhqWmHRZnnxw+b9uwNIDG0sAfUyFmJU=; b=Ef+3p3dcWrQw/S6QUnYV0rasyStaxb5il9y+jt/WtMHugRg6hfLOlR6D 51oqaz3bNj24wP1WjPdJd6t0A4iBQ9qgVlae1VyXZ37y15x/h8rY0PRrS apluAQd5HWCc0mK0um9I9X/bpiW8szs0djNOlCm71Pdoifuj9mmfONBVg E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkfAO6izlOtJV2Y/2dsb2JhbABYgkcjJFJXBIQQwSSBVwELhnBTAYETFnaEAwEBAQQBAQFrCRICAQgRAwECKAcnCxQIAQgCBAESCYg5AQy/bxePOg0LhEYFjkWMYoFNkmaCAoFEbAGBRA X-IronPort-AV: E=Sophos;i="5.01,711,1400025600"; d="scan'208,217";a="342025407" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 22 Jul 2014 17:48:10 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6MHmAEc000747 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 22 Jul 2014 17:48:10 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Tue, 22 Jul 2014 12:48:09 -0500 From: "Clyde Wildes (cwildes)" To: "Lisa Huang (yihuan)" , "netmod@ietf.org" Thread-Topic: [netmod] FW: New Version Notification for draft-wildes-netmod-syslog-model-00.txt Thread-Index: AQHPkZMp5tIX3Csi/kmACQV2dQR/PZuD8rAAgCdTI4CAAVIGgA== Date: Tue, 22 Jul 2014 17:48:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.67.171] Content-Type: multipart/alternative; boundary="_000_CFF414DB8B658cwildesciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yXcwpLrLqKWhsUipT37yegFotRk Subject: Re: [netmod] FW: New Version Notification for draft-wildes-netmod-syslog-model-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 17:48:14 -0000 --_000_CFF414DB8B658cwildesciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Lisa, Thanks for your review comments. My responses are inline=85 From: "Lisa Huang (yihuan)" > Date: Monday, July 21, 2014 at 5:38 PM To: Clyde Wildes >, "netmod@iet= f.org" > Subject: Re: [netmod] FW: New Version Notification for draft-wildes-netmod-= syslog-model-00.txt Clyde, Here are my initial comments: 1. leaf file-name { type string; mandatory true; description "This leaf specifies the name of the log file."; } This file-name leaf doesn't reflect what is in the system. What is the reas= on that uri is not use? [clyde] I will change the type to inet:uri in a later revision. 2. In leaf destination { type string; description "The leaf uniquely specifies the address of the remote host. One of the following must be specified: an ipv4 address, an ipv6 address, or a host name."; } type string for destination doesn't reflect the actual destination. Type un= ion allows to model the type with host and ip-address. [clyde] I will change the type to inet:host in a later revision. 3. In leaf source-interface { type string; description "This leaf sets the source interface for the remote Syslog server. Either the interface name or the interface IP address can be specified."; } it has a similar case to #2. String is too wide to reference an interface. [clyde] I will change the type to if:interface-ref in a later revision. 4. syslogtypes:kern syslogtypes:critical syslogtypes:auth syslogtypes:error This xml example should be around the facility and sever= ity as the following. syslogtypes:kern syslogtypes:critical syslogtypes:auth syslogtypes:error [clyde] I will update the example to reflect the latest model in a later re= vision. 5. choice logging-scope { description "This choice describes the option to specify all facilities or a specific facility."; case all-facilities { description "This case specifies all facilities."; leaf logging-severity { type syslogtypes:Severity; description "This leaf specifies the severity of Syslog messages for all facilities."; } } This choice is repeated in multiple different place. For readability and ma= intainability, it would be a good case to use augment and add new case stat= ement when needed. [clyde] I agree that this can be simplified and will do so in a later revis= ion. Thanks, Clyde Thanks, Lisa On 6/26/14 5:06 PM, "Clyde Wildes (cwildes)" > wrote: FYI and comments... Here is an initial draft proposal for a YANG model for Syslog. Thanks, Clyde On 6/26/14, 4:05 PM, "internet-drafts@ietf.org" > wrote: A new version of I-D, draft-wildes-netmod-syslog-model-00.txt has been successfully submitted by Kiran Koushik Agrahara and posted to the IETF repository. Name: draft-wildes-netmod-syslog-model Revision: 00 Title: SYSLOG YANG model Document date: 2014-06-26 Group: Individual Submission Pages: 19 URL: http://www.ietf.org/internet-drafts/draft-wildes-netmod-syslog-model-00.tx t Status: https://datatracker.ietf.org/doc/draft-wildes-netmod-syslog-model/ Htmlized: http://tools.ietf.org/html/draft-wildes-netmod-syslog-model-00 Abstract: This document describes a data model for Syslog protocol which is used to convey event notification messages. 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 --_000_CFF414DB8B658cwildesciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Lisa,

Thanks for your review comments.

My responses are inline=85

From: "Lisa Huang (yihuan)&quo= t; <yihuan@cisco.com>
Date: Monday, July 21, 2014 at 5:38= PM
To: Clyde Wildes <cwildes@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] FW: New Versi= on Notification for draft-wildes-netmod-syslog-model-00.txt

Clyde,

Here are my initial comments:

1. leaf file-name {
        type string;
        mandatory true;
        description
          "This leaf specifies the name of the log file.";

      }
This file-name leaf doesn't reflect wh= at is in the system. What is the reason that uri is not use?

[clyde] I will change the type to inet:uri in a later revision.

2. In
leaf destination {
type string;
description
"The leaf uniquely specifies the address of the remote host. One =
of the following must be specified: an ipv4 address, an ipv6
address, or a host name.";
}

type string for destination doesn't reflect the actual destination. Ty= pe union allows to model the type with host and ip-address.

[clyde] I will change the type to inet:host in a later revision.

3. In
leaf source-interface {
type string;
description
"This leaf sets the source interface for the remote
Syslog server. Either the interface name or the
interface IP address can be specified.";
}

it has a similar case to #2. String is= too wide to reference an interface.

[clyde] I will change the type to if:interface-ref in a later revision= .

4. 

<global-logging>
<facility>syslogtypes:kern</facility>
<severity>syslogtypes:critical</severity>
<facility>syslogtypes:auth</facility>
<severity>syslogtypes:error</severity>
</global-logging>

This xml example should be <logging-severity/>around the fac= ility and severity as the following.

<global-logging>
 <logging-s= everity><facility>syslogtypes:kern</facility>
<severity>syslogtypes:critical</severity></logging-severity>
<logging-severity><facility>= ;syslogtypes:auth</facility>
<severity>syslogtypes:error</= severity></logging-severity>
</global-logging>

[clyde] I will update the example to reflect the latest model in a lat= er revision.

5. 
choice logging-scope {
              description
                "This choice describes the option to specify all=20
                 facilities or a specific facility.";
              case all-facilities {
                description
                  "This case specifies all facilities.";
                leaf logging-severity {
                  type syslogtypes:Severity;
                  description
                    "This leaf specifies the severity of Syslog=20
                     messages for all facilities.";
                }
              }

This choice is repeated in multiple different =
place. For readability and maintainability, it would be a good case to use =
augment and add new case statement when needed.
[clyde] I agree that this can be simplified and will do so in a later = revision.

Thanks,
Clyde

Thanks,
Lisa

On 6/26/14 5:06 PM, "Clyde Wildes= (cwildes)" <cwildes@cisco.com= > wrote:

FYI and comments...

Here is an initial draft proposal for a YANG model for Syslog.

Thanks,

Clyde

wrote:


A new version of I-D, draft-wildes-netmod-syslog-model-00.txt
has been successfully submitted by Kiran Koushik Agrahara and posted t= o
the
IETF repository.

Name: = draft-wilde= s-netmod-syslog-model
Revision: 00
Title: SYSLOG YAN= G model
Document date: 2014-06-26
Group: Individual= Submission
Pages: 19
URL:           =  
t
Status:        
Htmlized:      
http://tools.ietf.org/html/draft-wildes-netmod-syslog-model-00


Abstract:
   This document describes a data model for Syslog
   protocol which is used to convey event notification messa= ges.

           &nbs= p;      
        


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

 --_000_CFF414DB8B658cwildesciscocom_-- From nobody Tue Jul 22 10:57:38 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9081A0143 for ; Tue, 22 Jul 2014 10:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.902 X-Spam-Level: X-Spam-Status: No, score=-13.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L49G6Z4e597h for ; Tue, 22 Jul 2014 10:57:35 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E31C81A000B for ; Tue, 22 Jul 2014 10:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1574; q=dns/txt; s=iport; t=1406051855; x=1407261455; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6NoBk6pFjyxwEDm+GT0JkrMD+8lJi8ONxNMRcIfJ9Xs=; b=lARX80TeWdDEXTDUCJk6Hg2/Zgrwyr4sKksDEDuIwLcUJ3hsCm54otyv 7+sL9n2EcRWBE3GvMmc5y0SN5ADqNp3Wq/4R5C4Pjy4Yer5A4g7hg4kUq NDun2icPK8+CKXnwAJaSi1UOVSPw2V5hiHxKjQiyystnuwpEfv4p43Hco o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFAAqlzlOtJA2H/2dsb2JhbABVA4JqJFJXBMcRh0kBgRMWdoQDAQEBBDo9Ag4CAgEIDgIIHhAbFxwJAgQBDQWIQgG/fBcEjzcQBxGENQWORYxilDOCAoFEbIFF X-IronPort-AV: E=Sophos;i="5.01,711,1400025600"; d="scan'208";a="63083582" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-2.cisco.com with ESMTP; 22 Jul 2014 17:57:34 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6MHvYmS032333 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jul 2014 17:57:34 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Tue, 22 Jul 2014 12:57:33 -0500 From: "Clyde Wildes (cwildes)" To: Juergen Schoenwaelder , "Lisa Huang (yihuan)" Thread-Topic: [netmod] FW: New Version Notification for draft-wildes-netmod-syslog-model-00.txt Thread-Index: AQHPkZMp5tIX3Csi/kmACQV2dQR/PZuD8rAAgCdTI4CAAU4zAIAABnUA Date: Tue, 22 Jul 2014 17:57:33 +0000 Message-ID: References: <20140722133436.GC11781@elstar.local> In-Reply-To: <20140722133436.GC11781@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.67.171] Content-Type: text/plain; charset="us-ascii" Content-ID: <9C59BCE424CEF34998F8C882986D70FB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/GC0vBMTfcAs21dlFTMzaDCPFyuI Cc: "netmod@ietf.org" Subject: Re: [netmod] FW: New Version Notification for draft-wildes-netmod-syslog-model-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 17:57:37 -0000 Jeurgen, Thanks for your review. I will adopt inet:host for the destination type in a later revision of the model. I will adopt a union of if:interface-ref and inet:ip-address for the source-interface type in a later revision of the model. Thanks, Clyde On 7/22/14, 9:34 AM, "Juergen Schoenwaelder" wrote: >On Mon, Jul 21, 2014 at 09:38:29PM +0000, Lisa Huang (yihuan) wrote: >=20 >> 2. In >> leaf destination { >> type string; >> description >> "The leaf uniquely specifies the address of the remote host. One >> of the following must be specified: an ipv4 address, an ipv6 >> address, or a host name."; >> } >>=20 >> type string for destination doesn't reflect the actual destination. >>Type union allows to model the type with host and ip-address. > >This should probably be inet:host [RFC6991] or something like that. >And there should most likely be a port number. And the key should not >be the destination IP address. >=20 >> 3. In >> leaf source-interface { >> type string; >> description >> "This leaf sets the source interface for the remote >> Syslog server. Either the interface name or the >> interface IP address can be specified."; >> } >>=20 >> it has a similar case to #2. String is too wide to reference an >>interface. > >Yes, I agree. > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 From nobody Tue Jul 22 11:03:58 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17BDD1B2B0E for ; Tue, 22 Jul 2014 11:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuPJbOV3jEgs for ; Tue, 22 Jul 2014 11:03:55 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 828CE1B2A7C for ; Tue, 22 Jul 2014 11:03:55 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 06F92110F; Tue, 22 Jul 2014 20:03:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id DY2lSWj_S4uo; Tue, 22 Jul 2014 20:03:45 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 22 Jul 2014 20:03:53 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0376F2002C; Tue, 22 Jul 2014 20:03:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nSGB4uxYDvdt; Tue, 22 Jul 2014 20:03:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3180E20017; Tue, 22 Jul 2014 20:03:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 170862DDFDED; Tue, 22 Jul 2014 20:03:50 +0200 (CEST) Date: Tue, 22 Jul 2014 20:03:50 +0200 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20140722180348.GD12709@elstar.local> Mail-Followup-To: Benoit Claise , "Clyde Wildes (cwildes)" , "netmod@ietf.org" , Kiran Agrahara Sreenivasa References: <20140722150553.GB12083@elstar.local> <53CEA093.2070000@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53CEA093.2070000@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/D1RrYwFA97xIV9hIhPh-fOfAswk Cc: Kiran Agrahara Sreenivasa , "netmod@ietf.org" Subject: Re: [netmod] Syslog YANG Model Presentation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 22 Jul 2014 18:03:57 -0000 On Tue, Jul 22, 2014 at 01:34:11PM -0400, Benoit Claise wrote: > Is RFC 5424 actually deployed? Are you suggesting that we write a configuration data model for a non standards-track SYSLOG protocol even though there is a standards-track SYSLOG protocol? I think Debian system come with rsyslog these days (and I think the same is true for Ubuntu). As far as I can tell, rsyslog supports RFC 5424 and if this is correct, RFC 5424 got at least 'fielded'. I can't say how much structured data is used (if that is your question). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Jul 22 11:30:37 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2957C1A0AA9 for ; Tue, 22 Jul 2014 11:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74uAdSFTlQWh for ; Tue, 22 Jul 2014 11:30:29 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 704911B2B94 for ; Tue, 22 Jul 2014 11:30:28 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 68BCF716; Tue, 22 Jul 2014 20:30:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id MHROfFx4b3yB; Tue, 22 Jul 2014 20:30:18 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 22 Jul 2014 20:30:26 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 487DE20017; Tue, 22 Jul 2014 20:30:26 +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 HB2fq5Rkka_k; Tue, 22 Jul 2014 20:30:24 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BDCC32002C; Tue, 22 Jul 2014 20:30:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 103982DDFE89; Tue, 22 Jul 2014 20:30:22 +0200 (CEST) Date: Tue, 22 Jul 2014 20:30:22 +0200 From: Juergen Schoenwaelder To: "Clyde Wildes (cwildes)" Message-ID: <20140722183022.GA12921@elstar.local> Mail-Followup-To: "Clyde Wildes (cwildes)" , "Lisa Huang (yihuan)" , "netmod@ietf.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/H4ad1HxRpJisWSlAJ1IUakt_dcs Cc: "netmod@ietf.org" Subject: Re: [netmod] FW: New Version Notification for draft-wildes-netmod-syslog-model-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 22 Jul 2014 18:30:36 -0000 On Tue, Jul 22, 2014 at 05:48:09PM +0000, Clyde Wildes (cwildes) wrote: > > Here are my initial comments: > > > 1. leaf file-name { > type string; > mandatory true; > description > "This leaf specifies the name of the log file."; > > > } > > This file-name leaf doesn't reflect what is in the system. What is the reason that uri is not use? > > [clyde] I will change the type to inet:uri in a later revision. > I assume that the idea is to _append_ to a log file. How does an append work for the various possible URI schemes? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Jul 22 11:49:04 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831561B2BDD for ; Tue, 22 Jul 2014 11:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mipNIf-nivZR for ; Tue, 22 Jul 2014 11:49:02 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AF861B2BE0 for ; Tue, 22 Jul 2014 11:49:00 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 13E4510AF for ; Tue, 22 Jul 2014 20:48:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ovd1u0ocZ_IC for ; Tue, 22 Jul 2014 20:48:49 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 22 Jul 2014 20:48:57 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E1D752002C for ; Tue, 22 Jul 2014 20:48:57 +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 H8IE62fYr2ay; Tue, 22 Jul 2014 20:48:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D706120017; Tue, 22 Jul 2014 20:48:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 237182DDFF4B; Tue, 22 Jul 2014 20:48:55 +0200 (CEST) Date: Tue, 22 Jul 2014 20:48:54 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140722184854.GA13074@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/02hgr5iz0z-su6dPq1xkvcbSvog Subject: [netmod] draft minutes of the 2014-07-09 virtual interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 22 Jul 2014 18:49:03 -0000 --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, attached please find the draft minutes of the 2014-07-09 virtual interim meeting. Please send any corrections of the minutes by Friday July 25th. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="netmod-2014-07-09-minutes.txt" o============================================================= NETCONF Data Modeling Language WG (netmod) 3rd YANG 1.1 Virtual Interim Wednesday, July 9th, 2014, 16:00-18:00 CEST Minutes Juergen Schoenwaelder ============================================================= * Participants - JS = Juergen Schoenwaelder - AZ = Alex Zhdankin - AB = Andy Bierman - LL = Lada Lotka - PO = Peyman Owladi - PH = Peter van Horne - AN = Anonymous - TN = Tom Nadeau * Summary * Y20: new set of built-in XPath functions Proposal: MB to copy the functions he proposed to RFC 6020bis as a starting point and then we review and discuss changes. * Y23: support negative patterns as string restrictions AB prefers solution #2, LL and PO as well. Proposal: Adopt Y23-02. * Y25: make enum numbering purely informative and optional LL and JS prefer Y25-01, AB likes it as well since the number is nowhere used in NETCONF. Proposal: Adopt Y25-01. * Y26: allow mandatory nodes in augment AB: It is too restrictive the way it is, allowing all mandatory nodes is too much. PO: We then need to enumerate the cases where mandatory nodes would be OK. PO: You are not allowed to use it in cases that break backwards compatibility? AN: That is what we want, but hard to implement. I think we need to start enumerating cases where it is OK and cases where not. AN: Augmentation may include mandatory nodes but it can't make something in a pre-existing container have additional mandatory nodes. LL: There can be containers designed to be augmented, e.g. for different address families. AN: Sounds like an abstract class concept where you can only instantiate concrete classes. LL: Yes. We have this with an 'abstract' routing entry. AB: But you break an old implementation, no? LL: We have this in the routing data model. If we could express that this needs an address specific module to work, we could handle this properly. JS: But this is on the container level, if we were to tag containers as incomplete, we would have machine readable information to take a decision whether an augment with mandatory nodes is allowed. AN: I think LL is really talking about a new issue. AB: ODL has designs with empty containers that are filled from the outside and these trigger wrong warnings. Conclusion: There is agreement that the current text is overly restrictive. The proposal is to add general guiding rules that backwards compatibility needs to be maintained. Lets see whether someone can write more concrete rules when mandatory nodes in augment are allowed. * Y27: allow mandatory nodes in an updated module PO: How does this relate to Y26? AB: In Y26 the version number does not change. LL: But the server now announces a new module. AB: Clients do not have to check whether any other modules augment mandatory nodes into a given module. AB: In Y26, the client does not any indication that the module changed. TN: We are mounting devices into some parts of the tree. And some devices may have different versions of modules. PH: We also use modules in various projects. TN: Allow with specific rules and caveats. PH: This is a case where and old client accessing a new revision will find his request invalid. PH: Deprecate and obsolete allows a reasonable deprecation path. PH: With this proposal, you break old clients immediately. JS: This is not how RFC 6020 section 10 first paragraph says it works. JS: It seems Y27-01 breaks the second sentence of section 10 of RFC 6020. PO: Should we instead discuss that obsolete should have additional text that this should not be mis-used to break compatibility? Some discussion about versioning not fully captured. PO: Should we have guidelines how to go from current to deprecated to obsolete in RFC 6087bis? Conclusion: The strawman proposal is to reject this issue, AB to check what the feature issue is about, possible action to add guidelines how to go from current to deprecated to obsolete in RFC 6087bis. * Y28 support default values in leaf-lists AB: I prefer Y28-01. JS: But this has problems since we would have to introduce a syntax that works for all possible values. PO: It seems Y28-02 works out of the box. LL: I think we should go with Y28-02. PO: This is slightly different from other defaults for implementations threat treat internally each leaf-list value as a separate object. AB: You can add to a set of values of a leaf-list using a NETCONF merge and hence leaf-lists are rather different and we can't simply extend default in this way. AB: We should do this somehow but it requires some work since leaf-lists are really different from leafs here. AB: Right now all we do is putting text into description statements. PO: If someone comes along and explicitly configures 830, then the value is not a default anymore. Conclusion: AB will look at the necessary text what it means to modify leaf-list values. Perhaps there is a need to have a different keyword since the behavior is rather different here. * Y29 allow choice as a short-hand case Strawman is to adopt the proposed solution. * Y30 allow leafref in union LL: Does this require that the instance referred to exists? AB: You check whether it exists, if not, you go on to the next option in the union. PO: The existence of a certain leaf determines to which type a union value resolves. This makes it different from other types in a union. AB: This might make differences if you make multiple updates in an edit-config. PO: But this is the same for other types in a union. Clearly Y30 and Y31 are interrelated. We did run out of time and we will continue in Toronto. We will skip next week's meeting since LL is also on vacation and IETF preparations also need to be made by several people. --HcAYCG3uE/tztfnV-- From nobody Tue Jul 22 11:53:48 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28FF1B2BEA for ; Tue, 22 Jul 2014 11:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMAfzwgFfdGV for ; Tue, 22 Jul 2014 11:53:45 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA4D81B2BE9 for ; Tue, 22 Jul 2014 11:53:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 2BA945408BB; Tue, 22 Jul 2014 20:53: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 bYir6a5zvaGr; Tue, 22 Jul 2014 20:53:28 +0200 (CEST) Received: from localhost (dhcp-a7b1.meeting.ietf.org [31.133.167.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 5838354075C; Tue, 22 Jul 2014 20:53:26 +0200 (CEST) From: Ladislav Lhotka To: "Thomas D. Nadeau" , netmod@ietf.org In-Reply-To: References: User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 22 Jul 2014 14:53:23 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qw3gF42B0EPxEpy7ek8_DPC5enc Subject: Re: [netmod] Lada's question on github repo X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:53:47 -0000 "Thomas D. Nadeau" writes: > RE: your objection to initial commits, I think we can address > that easily by allowing the person who commits an initial file > to be the initial committer, and then that person manages > commits going forward. Longer term we probably wanted this > model anyways so that this would scale. As the project > progresses, they can add additional committers (or deleted stale > ones). OK, so what are we supposed to do in order to be able to push the IS-IS module into the repo and get the necessary permissions? Also, is it possible to have the I-D source there as well so that it can be developed in sync with the module? Lada > > --Tom > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jul 22 12:16:36 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA871A0350 for ; Tue, 22 Jul 2014 12:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7PYP28SgqrH for ; Tue, 22 Jul 2014 12:16:31 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB3121A0035 for ; Tue, 22 Jul 2014 12:16:30 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id m5so125551qaj.7 for ; Tue, 22 Jul 2014 12:16:30 -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=G96L3kyFzWKiqGIPzraduLsqJRrmikbQLcSFwh5t1WA=; b=ZTLwTVpuxuOZHoUPq9C3z+bT1E6oM4Ce2X6+MfOEMorgjFdyyuXtBigvfDvjxi6KHk UCkvBfANLkgEQ1ldR+e6FP1DFfJ5mFanJRVwo+biFj8VQBZyk8ze8zyHwKc/oYnK4wOy APblB5jv0q36t4E9XaC9KVTM15YvRBauv9gOv7L+agZvlRkf1u/1n98zitJ1u5ORpAQ+ uituQYO+hUZDMKMfdaZiFIamwjUKyDGadSgwhqqrdqDPJ47fBiAbTjl83Lotcy4nGC7x m7qxUpaECiUkPepya3vPrnCJ5TmiR7000b/KUM/N/9f3EVxB5AQqxBhYj+7GxbIrXIaQ sikA== X-Gm-Message-State: ALoCoQnyC3/BshI+cWeIMxQmgzlHuv2QQmk1VIDFN6+TIE8myeCxvlYoXAI+ilf7XTcGy0nUlNCm MIME-Version: 1.0 X-Received: by 10.140.94.138 with SMTP id g10mr10702283qge.90.1406056589960; Tue, 22 Jul 2014 12:16:29 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Tue, 22 Jul 2014 12:16:29 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Jul 2014 12:16:29 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a113a4eda94993b04fecd0f1f Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/vBf4WTNuZOeO8DPFRAEih7cdLD8 Cc: "netmod@ietf.org" Subject: Re: [netmod] Lada's question on github repo X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:16:35 -0000 --001a113a4eda94993b04fecd0f1f Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 22, 2014 at 11:53 AM, Ladislav Lhotka wrote: > "Thomas D. Nadeau" writes: > > > RE: your objection to initial commits, I think we can address > > that easily by allowing the person who commits an initial file > > to be the initial committer, and then that person manages > > commits going forward. Longer term we probably wanted this > > model anyways so that this would scale. As the project > > progresses, they can add additional committers (or deleted stale > > ones). > > OK, so what are we supposed to do in order to be able to push the IS-IS > module into > the repo and get the necessary permissions? > > Also, is it possible to have the I-D source there as well so that it can be > developed in sync with the module? > How about if we have an offline meeting this week to discuss how the git repo should be organized and how new contributors can be added to the project with commit rights? An issue was raised in I2RS about using github vs. just a git repo somewhere. IMO, github offers great reports and external tool integration, but it does require that each user have a (free) github account. > Lada Andy > > > > --Tom > > > > > > _______________________________________________ > > 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 > --001a113a4eda94993b04fecd0f1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Jul 22, 2014 at 11:53 AM, Ladislav Lhotka <lhotka@nic.cz&g= t; wrote:
"Thomas D. Nadeau" <tnadeau@lucidvision.com> writes:

> =A0 =A0 =A0 RE: your objection to initial commits, I think we can addr= ess
> =A0 =A0 =A0 that easily by allowing the person who commits an initial = file
> =A0 =A0 =A0 to be the initial committer, and then that person manages<= br> > =A0 =A0 =A0 commits going forward. =A0Longer term we probably wanted t= his
> =A0 =A0 =A0 model anyways so that this would scale. =A0As the project<= br> > =A0 =A0 =A0 progresses, they can add additional committers (or deleted= stale
> =A0 =A0 =A0 ones).

OK, so what are we supposed to do in order to be able to push the IS-IS mod= ule into
the repo and get the necessary permissions?

Also, is it possible to have the I-D source there as well so that it can be=
developed in sync with the module?

How = about if we have an offline meeting this week to discuss how the git repo s= hould
be organized and how new contributors can be added to the p= roject with commit rights?

An issue was raised in I2RS about using github vs. just= a git repo somewhere.
IMO, github offers great reports and exter= nal tool integration, but it does require
that each user have a (= free) github account.




Lada=A0

Andy


>
> =A0 =A0 =A0 --Tom
>
>
> _______________________________________________
> 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

--001a113a4eda94993b04fecd0f1f-- From nobody Tue Jul 22 12:19:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5FE31A0B00 for ; Tue, 22 Jul 2014 12:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcMOrEMprVl9 for ; Tue, 22 Jul 2014 12:19:47 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 94EB21A0364 for ; Tue, 22 Jul 2014 12:19:47 -0700 (PDT) Received: from [192.168.1.121] (static-72-71-250-37.cncdnh.fast04.myfairpoint.net [72.71.250.37]) by lucidvision.com (Postfix) with ESMTP id 2E12C282E377; Tue, 22 Jul 2014 15:19:47 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_4E81DC38-13C8-4FC5-8A6D-C76086ED4935"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Tue, 22 Jul 2014 15:19:46 -0400 Message-Id: <0E72B813-26A0-431C-BA77-2420254DECB4@lucidvision.com> References: To: Ladislav Lhotka X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/v5hT7ea8FfIu2rQDFczHh9NsIdo Cc: netmod@ietf.org Subject: Re: [netmod] Lada's question on github repo X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:19:49 -0000 --Apple-Mail=_4E81DC38-13C8-4FC5-8A6D-C76086ED4935 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > "Thomas D. Nadeau" writes: >=20 >> RE: your objection to initial commits, I think we can address >> that easily by allowing the person who commits an initial file >> to be the initial committer, and then that person manages >> commits going forward. Longer term we probably wanted this >> model anyways so that this would scale. As the project >> progresses, they can add additional committers (or deleted stale >> ones). >=20 > OK, so what are we supposed to do in order to be able to push the = IS-IS module into > the repo and get the necessary permissions? We need to relax the create permissions. I'll look into it this = week. > Also, is it possible to have the I-D source there as well so that it = can be > developed in sync with the module? That I am not sure. You need to check with IETF rules for that. = There are some pretty clear rules WRT re-publication of I-Ds/RFCs (you = need explicit permission from the ID Editor). At least that was the case = last time I checked. --Tom >=20 > Lada >=20 >>=20 >> --Tom >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > --=20 > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 --Apple-Mail=_4E81DC38-13C8-4FC5-8A6D-C76086ED4935 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTzrlSAAoJEPcO+I7eiUJZDMwP/3ujK+6tOr+id/cL3xT1ruj0 cHGZZY5LTg7Qkj3Ria3SBnAUcTO0MkmPflKrszNcjwJ6kczc4IT0Y2Xl02qJnDVo JLpcyfVYWrNmCeH7l9zfnYh4vTB1Tw5gGTBe42XrfkHmcFcRVIeMvR8CmsKIUNyG 1xqf5lrx0zi44PXx1VUH7m+BwZXokTTVksMTApCktC+e7geKLAa1FUdScuSij8qq 8EMuCobq+r2l5yF4go5zQilXdwUyh3rbQkcCE5dSsYMB6aFewSBvqIBF+DcxcIUu 43UOGOXdVW00hrQD/sIS6dZPbfZAjAH+vC9FL4Kj9U5X8hbbcvlU6qTlSuRtc4nT oqaAl5nEHDv9cAx/1s5W4ImOW6HOoMEW3s7nTCZTuHKhZScWVZ7C8H5ZlI+Izkn9 +3XizNHVlZ4GUbfiPAw3uH0Q0ttAlqLQ65ikqPmfu6ytBrzP+8Osrem1+YYC2yAd ULOWIry/S2QTcxZ7rAsEsOF90Bn4OgIZ4YUDmdlc8zdvcbN9wusiOBL+8VyeSCVD ncitaBmLYmkfUnfNkUV5D+vFowZRli4gDFiyh6SWM00bTVQjEoTJlwKnajA4YofW ORwQISVLgg8+F9QszK50Wr2ylhXmgMuLM691ZXRrRF56AmVKYAXrvy1olPgri8Xt gxPt6UIBsKn2snqCp8te =H4Jb -----END PGP SIGNATURE----- --Apple-Mail=_4E81DC38-13C8-4FC5-8A6D-C76086ED4935-- From nobody Tue Jul 22 12:22:17 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2081B1A038E for ; Tue, 22 Jul 2014 12:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5eATsqOu-fU for ; Tue, 22 Jul 2014 12:22:14 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 501DF1A00E6 for ; Tue, 22 Jul 2014 12:22:14 -0700 (PDT) Received: from [192.168.1.121] (static-72-71-250-37.cncdnh.fast04.myfairpoint.net [72.71.250.37]) by lucidvision.com (Postfix) with ESMTP id DAAB4282E3A7; Tue, 22 Jul 2014 15:22:13 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_39A650D2-5DED-4911-8149-B2C0B72CAE1E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Tue, 22 Jul 2014 15:22:12 -0400 Message-Id: References: To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4cruGDEh-_RsED2N02w2-6hO9ss Cc: "netmod@ietf.org" Subject: Re: [netmod] Lada's question on github repo X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:22:16 -0000 --Apple-Mail=_39A650D2-5DED-4911-8149-B2C0B72CAE1E Content-Type: multipart/alternative; boundary="Apple-Mail=_65B1B7CC-94AA-46A6-A661-BF47BE6B16DA" --Apple-Mail=_65B1B7CC-94AA-46A6-A661-BF47BE6B16DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jul 22, 2014:3:16 PM, at 3:16 PM, Andy Bierman = wrote: >=20 >=20 >=20 > On Tue, Jul 22, 2014 at 11:53 AM, Ladislav Lhotka = wrote: > "Thomas D. Nadeau" writes: >=20 > > RE: your objection to initial commits, I think we can address > > that easily by allowing the person who commits an initial file > > to be the initial committer, and then that person manages > > commits going forward. Longer term we probably wanted this > > model anyways so that this would scale. As the project > > progresses, they can add additional committers (or deleted = stale > > ones). >=20 > OK, so what are we supposed to do in order to be able to push the = IS-IS module into > the repo and get the necessary permissions? >=20 > Also, is it possible to have the I-D source there as well so that it = can be > developed in sync with the module? >=20 > How about if we have an offline meeting this week to discuss how the = git repo should > be organized and how new contributors can be added to the project with = commit rights? good idea. How about Wednesday morning, 9AM-10AM EST? > An issue was raised in I2RS about using github vs. just a git repo = somewhere. > IMO, github offers great reports and external tool integration, but it = does require > that each user have a (free) github account. I agree. But in modern software engineering times, if you do not = have a github account, its a liability (career wise) if you ask me. *) --Tom >=20 >=20 >=20 >=20 > Lada=20 >=20 > Andy >=20 >=20 > > > > --Tom > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 --Apple-Mail=_65B1B7CC-94AA-46A6-A661-BF47BE6B16DA Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Jul 22, 2014:3:16 PM, at 3:16 PM, Andy Bierman <andy@yumaworks.com> wrote:




On Tue, Jul 22, 2014 at 11:53 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
"Thomas D. Nadeau" <tnadeau@lucidvision.com> writes:

>       RE: your objection to initial commits, I think we can address
>       that easily by allowing the person who commits an initial file
>       to be the initial committer, and then that person manages
>       commits going forward.  Longer term we probably wanted this
>       model anyways so that this would scale.  As the project
>       progresses, they can add additional committers (or deleted stale
>       ones).

OK, so what are we supposed to do in order to be able to push the IS-IS module into
the repo and get the necessary permissions?

Also, is it possible to have the I-D source there as well so that it can be
developed in sync with the module?

How about if we have an offline meeting this week to discuss how the git repo should
be organized and how new contributors can be added to the project with commit rights?

good idea.   How about Wednesday morning, 9AM-10AM EST?

An issue was raised in I2RS about using github vs. just a git repo somewhere.
IMO, github offers great reports and external tool integration, but it does require
that each user have a (free) github account.

I agree. But in modern software engineering times, if you do not have a github account, its a liability (career wise) if you ask me. *)

--Tom







Lada 

Andy


>
>       --Tom
>
>
> _______________________________________________
> 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


--Apple-Mail=_65B1B7CC-94AA-46A6-A661-BF47BE6B16DA-- --Apple-Mail=_39A650D2-5DED-4911-8149-B2C0B72CAE1E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTzrnkAAoJEPcO+I7eiUJZETQQAKdjCkLAk+rBtofOoKhIGSf4 On+qYqyZsEKFCa7o+xeo9ONV1o016i7FBgX+DCGuIqDCPNLBQwmr2zsMqCnlmaQu sNQuqcko2a5feQk5wQjOyjFyF4aQLlQFcz8uUt6NfmKpVJG9cSvMzhzja5EmLOHM DIdOQMRHVszrkdrLNGqNSmZvDgcAXpA6QL6hAgVZKuB6/yYaZmTFla7fNQOxzfAP bTuQf2IuXzgKW1XiH+2hHqDB09d8tbFZNX+6y70Y6IHaFX2/aSor1upKJZgrVnJ4 9zp1Ya4MX7dq/uX9oQFLL5Yrc77MyYnpxyZBbHXwdmNgBXhB4HxlfaNGuUEj8MgT l4gG7tLqnbrWjMKqQ+rxIRde2VoUOwjDi8dgmDHPKn8Iihadu1JQZG+HFzjFsoN9 1T1iHXDzkIt4EelugfDR6uWHYErMrGqwc1gJ6PORDScxgMgzq3g3eDxXtTMMyhqx heyW96nreBX5towRbhkJNH054/I4XVLC95zzsio3g6krmHHs4C1FbhvF/zIBl9vv j0ZpJ9Z08eHEGFjGzX6h+R/bKf46rba7i6nm+2/urLK323VbFVVvNvfth+MIA4+3 iXuFDxi9PnJ9q5tNY0NKjJK9SR42a5rUB1O3n+EB2KdSdfefxzYyYwjOBjvHrL1z 4Agwt0yNpvZ7NjwIIEXI =Vyn1 -----END PGP SIGNATURE----- --Apple-Mail=_39A650D2-5DED-4911-8149-B2C0B72CAE1E-- From nobody Tue Jul 22 12:23:36 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5C51B2A7B for ; Tue, 22 Jul 2014 12:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pjk-IP2BRA7z for ; Tue, 22 Jul 2014 12:23:30 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A065F1B29D7 for ; Tue, 22 Jul 2014 12:23:30 -0700 (PDT) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:bde4:55ef:e6bd:392c]) by mail.nic.cz (Postfix) with ESMTPSA id 4948714006C; Tue, 22 Jul 2014 21:23:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1406057009; bh=rucdhKt6kqI4oFuAPhfawSQEQx7OnI+vgWjsAMM97/g=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=E9k1BTIbMcaN84Et7Qq4IGunEwsS9FLnoVP8lnOoVOB3OhQQCSgY4f2w7erNpHiA5 WV3mFnXrcVvwBuK2kvH0Msm7Zc5mAorUxE79DivhrgR2qHnlF/KRjncyNees0bvnje V3pw8ppFrqjpWPPw7hgx32EQtc5kkJKPxgz4pHyE= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 22 Jul 2014 15:23:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/CGT9Hq89qDEgHZ7utIcoIkwfLas Cc: "netmod@ietf.org" Subject: Re: [netmod] Lada's question on github repo X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:23:32 -0000 On 22 Jul 2014, at 15:16, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Jul 22, 2014 at 11:53 AM, Ladislav Lhotka = wrote: > "Thomas D. Nadeau" writes: >=20 > > RE: your objection to initial commits, I think we can address > > that easily by allowing the person who commits an initial file > > to be the initial committer, and then that person manages > > commits going forward. Longer term we probably wanted this > > model anyways so that this would scale. As the project > > progresses, they can add additional committers (or deleted = stale > > ones). >=20 > OK, so what are we supposed to do in order to be able to push the = IS-IS module into > the repo and get the necessary permissions? >=20 > Also, is it possible to have the I-D source there as well so that it = can be > developed in sync with the module? >=20 > How about if we have an offline meeting this week to discuss how the = git repo should > be organized and how new contributors can be added to the project with = commit rights? +1 >=20 > An issue was raised in I2RS about using github vs. just a git repo = somewhere. > IMO, github offers great reports and external tool integration, but it = does require > that each user have a (free) github account. This is IMO not a big hurdle. Lada >=20 >=20 >=20 >=20 > Lada=20 >=20 > Andy >=20 >=20 > > > > --Tom > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jul 22 12:25:42 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408B21B2A93 for ; Tue, 22 Jul 2014 12:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaKehgh-1vRF for ; Tue, 22 Jul 2014 12:25:37 -0700 (PDT) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED0201B29B0 for ; Tue, 22 Jul 2014 12:25:36 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id i50so153336qgf.35 for ; Tue, 22 Jul 2014 12:25:36 -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=11lkVgx3vrapNMnZ+w73i57LP+H+iLo+APUS62rvmkA=; b=AFOiwQhuwn7JTBELux4MFI+ft9IqBOHqmVaHm+Au4HKtqP+04qa7ohr/DySxoqLzNn VgEIuTPLVN7yxx63rgYM4H4tcdGl5b8HHoMKPc4XtUylgLkskwO+DCP7WtyWxslU7gIg Edvj8IITjsDsfPXBOIDvm93jGJJ/hwT0zQJOuoxFWLM2f2TNXCA7wgfw+pHbXB9HnWUN ameKXylaBpo6xhckPtKL51NhyN/h3IzTWPL1CYffBPxCNkRsHxKj5CICKU7FaMphKXqM Le5Bju03RedQzVe4Itpm5m/faJHBOdsxfJN+6uv4+7bOGG7ZWYOF+r4nmHItbkSDUKmL asIw== X-Gm-Message-State: ALoCoQmnjj8uQtIeoZjvAd3SC3fUbqYpvrkFr3e6SlZIzd+uTKIP8Sx+McAyxfNHAbeyxkozjR4t MIME-Version: 1.0 X-Received: by 10.140.85.101 with SMTP id m92mr55225995qgd.26.1406057136010; Tue, 22 Jul 2014 12:25:36 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Tue, 22 Jul 2014 12:25:35 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Jul 2014 12:25:35 -0700 Message-ID: From: Andy Bierman To: "Thomas D. Nadeau" Content-Type: multipart/alternative; boundary=001a11c155ea2093ea04fecd301a Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/nLfnb_H9KwmSb7OJBC-uIm0vBH8 Cc: "netmod@ietf.org" Subject: Re: [netmod] Lada's question on github repo X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:25:39 -0000 --001a11c155ea2093ea04fecd301a Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 22, 2014 at 12:22 PM, Thomas D. Nadeau wrote: > > On Jul 22, 2014:3:16 PM, at 3:16 PM, Andy Bierman > wrote: > > > > > On Tue, Jul 22, 2014 at 11:53 AM, Ladislav Lhotka wrote: > >> "Thomas D. Nadeau" writes: >> >> > RE: your objection to initial commits, I think we can address >> > that easily by allowing the person who commits an initial file >> > to be the initial committer, and then that person manages >> > commits going forward. Longer term we probably wanted this >> > model anyways so that this would scale. As the project >> > progresses, they can add additional committers (or deleted stale >> > ones). >> >> OK, so what are we supposed to do in order to be able to push the IS-IS >> module into >> the repo and get the necessary permissions? >> >> Also, is it possible to have the I-D source there as well so that it can >> be >> developed in sync with the module? >> > > How about if we have an offline meeting this week to discuss how the git > repo should > be organized and how new contributors can be added to the project with > commit rights? > > > good idea. How about Wednesday morning, 9AM-10AM EST? > > opsawg and sfc meet at that time, so I am busy. > An issue was raised in I2RS about using github vs. just a git repo > somewhere. > IMO, github offers great reports and external tool integration, but it > does require > that each user have a (free) github account. > > > I agree. But in modern software engineering times, if you do not have a > github account, its a liability (career wise) if you ask me. *) > > Agree. I should point out that a github account is only needed for write access. There is public read access. > --Tom > > Andy > > > > >> Lada > > > Andy > > >> > >> > --Tom >> > >> > >> > _______________________________________________ >> > 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 >> > > > --001a11c155ea2093ea04fecd301a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Jul 22, 2014 at 12:22 PM, Thomas D. Nadeau <tnadeau@= lucidvision.com> wrote:

On Jul 22, 2014:3:16 PM, at 3:16 PM, Andy Bierman <andy@yumaworks.com> wrote:<= /div>



On Tue, Jul 22, 2014 at 11:53 AM, Lad= islav Lhotka <lhotka@nic.cz> wrote:
"Thomas D. Nadeau" <tnadeau@lucidvision.com> writes:

> =A0 =A0 =A0 RE: your objection to initial commits, I think we can addr= ess
> =A0 =A0 =A0 that easily by allowing the person who commits an initial = file
> =A0 =A0 =A0 to be the initial committer, and then that person manages<= br> > =A0 =A0 =A0 commits going forward. =A0Longer term we probably wanted t= his
> =A0 =A0 =A0 model anyways so that this would scale. =A0As the project<= br> > =A0 =A0 =A0 progresses, they can add additional committers (or deleted= stale
> =A0 =A0 =A0 ones).

OK, so what are we supposed to do in order to be able to push the IS-IS mod= ule into
the repo and get the necessary permissions?

Also, is it possible to have the I-D source there as well so that it can be=
developed in sync with the module?


good idea. =A0 How about Wednesday morning, 9AM-10AM EST?


=A0
An issue was raised in I2RS about using github vs. just a git repo som= ewhere.
IMO, github offers great reports and external tool integr= ation, but it does require
that each user have a (free) github ac= count.

I agree. But in modern software engineering times, if = you do not have a github account, its a liability (career wise) if you ask = me. *)


Agree. I should= point out that a github account is only needed for write access.
There is public read access.

--Tom



Andy
=A0


--001a11c155ea2093ea04fecd301a-- From nobody Tue Jul 22 12:27:09 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85251A0386 for ; Tue, 22 Jul 2014 12:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXWVkU19wiZq for ; Tue, 22 Jul 2014 12:27:04 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AB8B1A004E for ; Tue, 22 Jul 2014 12:27:04 -0700 (PDT) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:bde4:55ef:e6bd:392c]) by mail.nic.cz (Postfix) with ESMTPSA id F3A1613FCD8; Tue, 22 Jul 2014 21:27:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1406057222; bh=XWjAF58rWONZs/+6rhJRmLnIREbhD/oLkJu8cwDJadU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=VYOeO3qKbDNOl9APM7+8Cwvo6zWrLQFTPcvE0Bj7G868Af+Fh0MWXxf7j6Pvlx99Q 7ZG+RhACIA7QVnhEQ4uCXcJf3bdPJylsDVw8ekXIwT5GS83a1z6lWJ+gP5UWbrysB+ 7mmXkzln/SVOyn61eu68NaDZW2vrgvnux06A80og= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 22 Jul 2014 15:27:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <49735D21-9D92-48FB-93B9-DBF6E2404898@nic.cz> References: To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ehKJ1KWeI1Ot0Tnv__2Ck95IKN0 Cc: "netmod@ietf.org" Subject: Re: [netmod] Lada's question on github repo X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:27:06 -0000 On 22 Jul 2014, at 15:25, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Jul 22, 2014 at 12:22 PM, Thomas D. Nadeau = wrote: >=20 > On Jul 22, 2014:3:16 PM, at 3:16 PM, Andy Bierman = wrote: >=20 >>=20 >>=20 >>=20 >> On Tue, Jul 22, 2014 at 11:53 AM, Ladislav Lhotka = wrote: >> "Thomas D. Nadeau" writes: >>=20 >> > RE: your objection to initial commits, I think we can address >> > that easily by allowing the person who commits an initial = file >> > to be the initial committer, and then that person manages >> > commits going forward. Longer term we probably wanted this >> > model anyways so that this would scale. As the project >> > progresses, they can add additional committers (or deleted = stale >> > ones). >>=20 >> OK, so what are we supposed to do in order to be able to push the = IS-IS module into >> the repo and get the necessary permissions? >>=20 >> Also, is it possible to have the I-D source there as well so that it = can be >> developed in sync with the module? >>=20 >> How about if we have an offline meeting this week to discuss how the = git repo should >> be organized and how new contributors can be added to the project = with commit rights? >=20 > good idea. How about Wednesday morning, 9AM-10AM EST? >=20 >=20 > opsawg and sfc meet at that time, so I am busy. I also have a meeting at that time. Lada > =20 >> An issue was raised in I2RS about using github vs. just a git repo = somewhere. >> IMO, github offers great reports and external tool integration, but = it does require >> that each user have a (free) github account. >=20 > I agree. But in modern software engineering times, if you do not = have a github account, its a liability (career wise) if you ask me. *) >=20 >=20 > Agree. I should point out that a github account is only needed for = write access. > There is public read access. >=20 > =20 > --Tom >=20 >=20 >=20 > Andy > =20 >>=20 >>=20 >>=20 >>=20 >> Lada=20 >>=20 >> Andy >>=20 >>=20 >> > >> > --Tom >> > >> > >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >>=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jul 22 12:28:12 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970361B2849 for ; Tue, 22 Jul 2014 12:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzMG1JWbaOYK for ; Tue, 22 Jul 2014 12:28:03 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 788821A0309 for ; Tue, 22 Jul 2014 12:28:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7127; q=dns/txt; s=iport; t=1406057283; x=1407266883; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=1FAJasGzTPRb9h5b5HjlXG7hgzLKCG/NsU0iN/r1UxE=; b=AbTnsVeRDrkBDHAMo2CQIreqCfaIR+6s9RG1CfpFDrT5m7AEv3ebYW24 qJ7MTKUgL2Mx/vWqjyOjXMrjp0uOdXPDY1rDLoirFLaVISKpxCQgC4KWH wsorc2/RzQTlQLuihsRTpJrnJgvRfS44oKp8r1Rx4n14BwkOpgJiemvG+ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8FACS6zlOtJA2E/2dsb2JhbABYgkdHUlcExwsBCYZyUwGBExZ2hAMBAQEDAQEBAWsLBQ0BCBEDAQIWEi4LFAkIAgQBDQWIOggNv2sTBI86DQQHCoQ8BZcJhB6UM4NGbIFF X-IronPort-AV: E=Sophos; i="5.01,711,1400025600"; d="scan'208,217"; a="63112839" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-8.cisco.com with ESMTP; 22 Jul 2014 19:28:03 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6MJS2Ha030755 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jul 2014 19:28:02 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Tue, 22 Jul 2014 14:28:02 -0500 From: "Lisa Huang (yihuan)" To: Andy Bierman , Ladislav Lhotka Thread-Topic: [netmod] Lada's question on github repo Thread-Index: AQHPpPOI489o27qdLECw8E7u7F9O9pusxleAgAAGdID//8ArgA== Date: Tue, 22 Jul 2014 19:28:01 +0000 Message-ID: In-Reply-To: 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.82.239.136] Content-Type: multipart/alternative; boundary="_000_CFF433333ADD1yihuanciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/mL5ordkA02G2g3vx1QNFBeA09PE Cc: "netmod@ietf.org" Subject: Re: [netmod] Lada's question on github repo X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:28:05 -0000 --_000_CFF433333ADD1yihuanciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andy, Check-out doesn't requires github account but commit requires an account. Thanks, Lisa From: Andy Bierman > Date: Tuesday, July 22, 2014 12:16 PM To: Ladislav Lhotka > Cc: "netmod@ietf.org" > Subject: Re: [netmod] Lada's question on github repo On Tue, Jul 22, 2014 at 11:53 AM, Ladislav Lhotka > wrote: "Thomas D. Nadeau" = > writes: > RE: your objection to initial commits, I think we can address > that easily by allowing the person who commits an initial file > to be the initial committer, and then that person manages > commits going forward. Longer term we probably wanted this > model anyways so that this would scale. As the project > progresses, they can add additional committers (or deleted stale > ones). OK, so what are we supposed to do in order to be able to push the IS-IS mod= ule into the repo and get the necessary permissions? Also, is it possible to have the I-D source there as well so that it can be developed in sync with the module? How about if we have an offline meeting this week to discuss how the git re= po should be organized and how new contributors can be added to the project with comm= it rights? An issue was raised in I2RS about using github vs. just a git repo somewher= e. IMO, github offers great reports and external tool integration, but it does= require that each user have a (free) github account. Lada Andy > > --Tom > > > _______________________________________________ > 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 --_000_CFF433333ADD1yihuanciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Andy,

Check-out doesn't requires github account but commit requires an accou= nt.

Thanks,

Lisa

From: Andy Bierman <andy@yumaworks.com>
Date: Tuesday, July 22, 2014 12:16 = PM
To: Ladislav Lhotka <lhotka@nic.cz>
Cc: "netmod@ietf.org" <= netmod@ietf.org>
Subject: Re: [netmod] Lada's questi= on on github repo




On Tue, Jul 22, 2014 at 11:53 AM, Ladislav Lhotk= a <lhotka@nic.cz>= ; wrote:
"Thomas D. Nadeau" <tnadeau@lucidvision.com> writes:

>       RE: your objection to initial commits, I think we= can address
>       that easily by allowing the person who commits an= initial file
>       to be the initial committer, and then that person= manages
>       commits going forward.  Longer term we proba= bly wanted this
>       model anyways so that this would scale.  As = the project
>       progresses, they can add additional committers (o= r deleted stale
>       ones).

OK, so what are we supposed to do in order to be able to push the IS-IS mod= ule into
the repo and get the necessary permissions?

Also, is it possible to have the I-D source there as well so that it can be=
developed in sync with the module?

How about if we have an offline meeting this week to discuss how the g= it repo should
be organized and how new contributors can be added to the project with= commit rights?

An issue was raised in I2RS about using github vs. just a git repo som= ewhere.
IMO, github offers great reports and external tool integration, but it= does require
that each user have a (free) github account.




Lada 

Andy


>
>       --Tom
>
>
> _______________________________________________
> 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

 --_000_CFF433333ADD1yihuanciscocom_-- From nobody Tue Jul 22 12:28:32 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6584A1B2B77 for ; Tue, 22 Jul 2014 12:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfJ2v7GTvXEu for ; Tue, 22 Jul 2014 12:28:28 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 47DC71A02FE for ; Tue, 22 Jul 2014 12:28:28 -0700 (PDT) Received: from [192.168.1.121] (static-72-71-250-37.cncdnh.fast04.myfairpoint.net [72.71.250.37]) by lucidvision.com (Postfix) with ESMTP id CC131282E3F1; Tue, 22 Jul 2014 15:28:27 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_189555C3-E002-4439-81B0-A6F6AE5335DD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Tue, 22 Jul 2014 15:28:27 -0400 Message-Id: <015A1F50-EE31-4DCF-856E-DA0FDF8D1F2B@lucidvision.com> References: To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/0cV79DfFbqjZ_WLHgFUna-KLARw Cc: "netmod@ietf.org" Subject: Re: [netmod] Lada's question on github repo X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:28:30 -0000 --Apple-Mail=_189555C3-E002-4439-81B0-A6F6AE5335DD Content-Type: multipart/alternative; boundary="Apple-Mail=_F2357464-434B-41EC-9F91-01E3F259440F" --Apple-Mail=_F2357464-434B-41EC-9F91-01E3F259440F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jul 22, 2014:3:25 PM, at 3:25 PM, Andy Bierman = wrote: >=20 >=20 >=20 > On Tue, Jul 22, 2014 at 12:22 PM, Thomas D. Nadeau = wrote: >=20 > On Jul 22, 2014:3:16 PM, at 3:16 PM, Andy Bierman = wrote: >=20 >>=20 >>=20 >>=20 >> On Tue, Jul 22, 2014 at 11:53 AM, Ladislav Lhotka = wrote: >> "Thomas D. Nadeau" writes: >>=20 >> > RE: your objection to initial commits, I think we can address >> > that easily by allowing the person who commits an initial = file >> > to be the initial committer, and then that person manages >> > commits going forward. Longer term we probably wanted this >> > model anyways so that this would scale. As the project >> > progresses, they can add additional committers (or deleted = stale >> > ones). >>=20 >> OK, so what are we supposed to do in order to be able to push the = IS-IS module into >> the repo and get the necessary permissions? >>=20 >> Also, is it possible to have the I-D source there as well so that it = can be >> developed in sync with the module? >>=20 >> How about if we have an offline meeting this week to discuss how the = git repo should >> be organized and how new contributors can be added to the project = with commit rights? >=20 > good idea. How about Wednesday morning, 9AM-10AM EST? Wednesday 2:30-3:30 EST? > opsawg and sfc meet at that time, so I am busy. > =20 >> An issue was raised in I2RS about using github vs. just a git repo = somewhere. >> IMO, github offers great reports and external tool integration, but = it does require >> that each user have a (free) github account. >=20 > I agree. But in modern software engineering times, if you do not = have a github account, its a liability (career wise) if you ask me. *) >=20 >=20 > Agree. I should point out that a github account is only needed for = write access. > There is public read access. Yes. But I think you need an account if you want to set up SSH = keys even for read. --Tom >=20 > =20 > --Tom >=20 >=20 >=20 > Andy > =20 >>=20 >>=20 >>=20 >>=20 >> Lada=20 >>=20 >> Andy >>=20 >>=20 >> > >> > --Tom >> > >> > >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >>=20 >=20 >=20 --Apple-Mail=_F2357464-434B-41EC-9F91-01E3F259440F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Jul 22, 2014:3:25 PM, at 3:25 PM, Andy Bierman <andy@yumaworks.com> wrote:




On Tue, Jul 22, 2014 at 12:22 PM, Thomas D. Nadeau <tnadeau@lucidvision.com> wrote:

On Jul 22, 2014:3:16 PM, at 3:16 PM, Andy Bierman <andy@yumaworks.com> wrote:




On Tue, Jul 22, 2014 at 11:53 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
"Thomas D. Nadeau" <tnadeau@lucidvision.com> writes:

>       RE: your objection to initial commits, I think we can address
>       that easily by allowing the person who commits an initial file
>       to be the initial committer, and then that person manages
>       commits going forward.  Longer term we probably wanted this
>       model anyways so that this would scale.  As the project
>       progresses, they can add additional committers (or deleted stale
>       ones).

OK, so what are we supposed to do in order to be able to push the IS-IS module into
the repo and get the necessary permissions?

Also, is it possible to have the I-D source there as well so that it can be
developed in sync with the module?

How about if we have an offline meeting this week to discuss how the git repo should
be organized and how new contributors can be added to the project with commit rights?

good idea.   How about Wednesday morning, 9AM-10AM EST?


Wednesday 2:30-3:30 EST?

opsawg and sfc meet at that time, so I am busy.
 
An issue was raised in I2RS about using github vs. just a git repo somewhere.
IMO, github offers great reports and external tool integration, but it does require
that each user have a (free) github account.

I agree. But in modern software engineering times, if you do not have a github account, its a liability (career wise) if you ask me. *)


Agree. I should point out that a github account is only needed for write access.
There is public read access.

Yes. But I think you need an account if you want to set up SSH keys even for read.

--Tom



 
--Tom



Andy
 




Lada 

Andy


>
>       --Tom
>
>
> _______________________________________________
> 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




--Apple-Mail=_F2357464-434B-41EC-9F91-01E3F259440F-- --Apple-Mail=_189555C3-E002-4439-81B0-A6F6AE5335DD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTzrtbAAoJEPcO+I7eiUJZ2zYQAItMopO09f+BF6/vYWBw2cH7 zGj6z9SyzhESaQC2zpUbSPbAvFnc4QUBdvMinNPPg+MDJiH+m9MbAiZzLbJnr4PX zW6Aj4Bb83KZcYdJnsGuXg9GITw1zq6e50kT3Vik6BqnnzmysMBjiEsO+zoPoFgI v1BlepG6wZLKS0a4zXRxiIraXLKsN8ivZz3RcfFIoVajMv5s9bPUtnQA2Ln/6NXt O/1buOZtJdEd2E4tBJxsXggZvGrre38TMcJwvAQJol3p7py2CnxN30iuoE01n4gN XyyR0xIxDY9BjG9HqZ+ZDvhW9Ct/5V3baKxbSFdXGCqf/rYQRVG1oApl6ZLyeteD 4v6zRkAo1+PgRoVv+osd/UHqXPfjQGkTQycUkruynRaV+G12RV5U3ndqf7nxClwp DuFscIWpWbgYaRR8husXjEs0KmbLc9hDyanSEDzAOfvMRoa6/nog0w8MPqjE+nbh 8I0cFNXFt2jtZkM34tDBWXhvM+vhcYNjVr2ih+QvPll5zJRb+GoIBf6ZH3ejStnh ai0JqlNZCerZFbuDyQhqOrwLJyfq9cT2L4CR//uiMK63KT3TH+cIIoJSgpmTaCYh 8huSMdk79/sev9KMxPc2Qk8toWeeu7kEJDV6f3rsbgjLdDnY+apkMKf0S7GEBgru IpyfGVRiZ2LWcTh6Qb+u =rHLD -----END PGP SIGNATURE----- --Apple-Mail=_189555C3-E002-4439-81B0-A6F6AE5335DD-- From nobody Tue Jul 22 12:30:06 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669611B2BA3 for ; Tue, 22 Jul 2014 12:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnQiPAmZP-3n for ; Tue, 22 Jul 2014 12:29:58 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 077261B2B95 for ; Tue, 22 Jul 2014 12:29:58 -0700 (PDT) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:bde4:55ef:e6bd:392c]) by mail.nic.cz (Postfix) with ESMTPSA id DB5CC13FCD8; Tue, 22 Jul 2014 21:29:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1406057396; bh=/i8fHnl2OYs8dqrD1/xVMDAPBKOZxVho00nwgykkW94=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=kPg7JeC2IIET3EEaogEaAbwTwICzQMxuNkHr9L+wi6YmGOw9UHdtYbrB54roHQUn1 aorhKf/y0rPATaAo0x5jmogUbVs1CJ3zZ0ok/p4ZkKJS0+HFOb/WHoPMl2DkZjn48l mmflWhiQoa2R/fm8oYr2fs1N4yJ804imYThrQvxc= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <015A1F50-EE31-4DCF-856E-DA0FDF8D1F2B@lucidvision.com> Date: Tue, 22 Jul 2014 15:29:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <015A1F50-EE31-4DCF-856E-DA0FDF8D1F2B@lucidvision.com> To: Thomas Nadeau X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/YjwA5hoxJ0Meai5vzv7rX30Fylk Cc: "netmod@ietf.org" Subject: Re: [netmod] Lada's question on github repo X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:29:59 -0000 On 22 Jul 2014, at 15:28, Thomas D. Nadeau = wrote: >=20 > On Jul 22, 2014:3:25 PM, at 3:25 PM, Andy Bierman = wrote: >=20 >>=20 >>=20 >>=20 >> On Tue, Jul 22, 2014 at 12:22 PM, Thomas D. Nadeau = wrote: >>=20 >> On Jul 22, 2014:3:16 PM, at 3:16 PM, Andy Bierman = wrote: >>=20 >>>=20 >>>=20 >>>=20 >>> On Tue, Jul 22, 2014 at 11:53 AM, Ladislav Lhotka = wrote: >>> "Thomas D. Nadeau" writes: >>>=20 >>> > RE: your objection to initial commits, I think we can = address >>> > that easily by allowing the person who commits an initial = file >>> > to be the initial committer, and then that person manages >>> > commits going forward. Longer term we probably wanted this >>> > model anyways so that this would scale. As the project >>> > progresses, they can add additional committers (or deleted = stale >>> > ones). >>>=20 >>> OK, so what are we supposed to do in order to be able to push the = IS-IS module into >>> the repo and get the necessary permissions? >>>=20 >>> Also, is it possible to have the I-D source there as well so that it = can be >>> developed in sync with the module? >>>=20 >>> How about if we have an offline meeting this week to discuss how the = git repo should >>> be organized and how new contributors can be added to the project = with commit rights? >>=20 >> good idea. How about Wednesday morning, 9AM-10AM EST? >=20 >=20 > Wednesday 2:30-3:30 EST? Works for me. Lada >=20 >> opsawg and sfc meet at that time, so I am busy. >> =20 >>> An issue was raised in I2RS about using github vs. just a git repo = somewhere. >>> IMO, github offers great reports and external tool integration, but = it does require >>> that each user have a (free) github account. >>=20 >> I agree. But in modern software engineering times, if you do not = have a github account, its a liability (career wise) if you ask me. *) >>=20 >>=20 >> Agree. I should point out that a github account is only needed for = write access. >> There is public read access. >=20 > Yes. But I think you need an account if you want to set up SSH = keys even for read. >=20 > --Tom >=20 >=20 >>=20 >> =20 >> --Tom >>=20 >>=20 >>=20 >> Andy >> =20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Lada=20 >>>=20 >>> Andy >>>=20 >>>=20 >>> > >>> > --Tom >>> > >>> > >>> > _______________________________________________ >>> > netmod mailing list >>> > netmod@ietf.org >>> > https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jul 22 13:55:58 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCAC1B2C00 for ; Tue, 22 Jul 2014 13:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaunUEEBbfWP for ; Tue, 22 Jul 2014 13:55:55 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF37D1A0365 for ; Tue, 22 Jul 2014 13:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1728; q=dns/txt; s=iport; t=1406062555; x=1407272155; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8jPuJ67NlqmG425e9+aoJIUSui6BHj5jyWrLkbpWSk8=; b=F2FYG7HqLO8kXzNSshaEtHvEjCDgdePTznGwtH6lMibfydoiESmgR/Kk Xy1PPWP+pYN0OljgfiDJToid0wfFm6c6cJ5tJALR0ED6+BN0GgqI3MF62 KBYZtR0p7Un9gNXJzqRVIdQJqRrL5ojvszB2atef8pr01aV9H3rg3967F 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYFAPvOzlOtJV2Q/2dsb2JhbABWA4JqJFJXBMcah0kBgRMWdoQDAQEBBHcCDgICAQgOAgguGxccCQIEDgWIQgHABRcEjzcQBxGENQWKLZB6lDOCAoFEbIFF X-IronPort-AV: E=Sophos;i="5.01,712,1400025600"; d="scan'208";a="63141134" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP; 22 Jul 2014 20:55:54 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s6MKtspZ021704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jul 2014 20:55:54 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 22 Jul 2014 15:55:54 -0500 From: "Clyde Wildes (cwildes)" To: Juergen Schoenwaelder Thread-Topic: [netmod] FW: New Version Notification for draft-wildes-netmod-syslog-model-00.txt Thread-Index: AQHPkZMp5tIX3Csi/kmACQV2dQR/PZuD8rAAgCdTI4CAAVIGgIAATtAA///lpoA= Date: Tue, 22 Jul 2014 20:55:54 +0000 Message-ID: References: <20140722183022.GA12921@elstar.local> In-Reply-To: <20140722183022.GA12921@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.67.171] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/YhZ-hUw8vptkHIbyvjWyoPDJlww Cc: "netmod@ietf.org" Subject: Re: [netmod] FW: New Version Notification for draft-wildes-netmod-syslog-model-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 20:55:57 -0000 Juergen, I should have qualified my response to indicate that the only URI scheme that will be supported for file-logging is =B3file:=B2. Other distribution actions are supported by other leaves. Regarding file append: some implementations support a maximum size feature that indicates when the syslog file will wrap with new messages written over the oldest entry. Other implementations support an archive feature that indicates when the syslog file should be renamed and a new file started (time based or size based), along with the maximum number of archived files to save. We left these two features out of this model for simplicity knowing that they could be added through augmentation if needed for a particular implementation. Thanks, Clyde On 7/22/14, 2:30 PM, "Juergen Schoenwaelder" wrote: >On Tue, Jul 22, 2014 at 05:48:09PM +0000, Clyde Wildes (cwildes) wrote: >>=20 >> Here are my initial comments: >>=20 >>=20 >> 1. leaf file-name { >> type string; >> mandatory true; >> description >> "This leaf specifies the name of the log file."; >>=20 >>=20 >> } >>=20 >> This file-name leaf doesn't reflect what is in the system. What is the >>reason that uri is not use? >>=20 >> [clyde] I will change the type to inet:uri in a later revision. >>=20 > >I assume that the idea is to _append_ to a log file. How does an >append work for the various possible URI schemes? > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 From nobody Tue Jul 22 14:14:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F08B1A0149 for ; Tue, 22 Jul 2014 14:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5gF8aPp3Fxo for ; Tue, 22 Jul 2014 14:14:23 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435BA1B2833 for ; Tue, 22 Jul 2014 14:14:23 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A8D5FE7C; Tue, 22 Jul 2014 23:14:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id xG07Ha43yuYQ; Tue, 22 Jul 2014 23:14:12 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 22 Jul 2014 23:14:20 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BFA6E2002C; Tue, 22 Jul 2014 23:14:20 +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 05970RzpEKET; Tue, 22 Jul 2014 23:14:20 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7DA5E20017; Tue, 22 Jul 2014 23:14:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 91D402DE01A6; Tue, 22 Jul 2014 23:14:18 +0200 (CEST) Date: Tue, 22 Jul 2014 23:14:17 +0200 From: Juergen Schoenwaelder To: "Clyde Wildes (cwildes)" Message-ID: <20140722211417.GA13447@elstar.local> Mail-Followup-To: "Clyde Wildes (cwildes)" , "Lisa Huang (yihuan)" , "netmod@ietf.org" References: <20140722183022.GA12921@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/3YAkFToCzfEPSG6HGrs4YvWQqPA Cc: "netmod@ietf.org" Subject: Re: [netmod] FW: New Version Notification for draft-wildes-netmod-syslog-model-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 22 Jul 2014 21:14:25 -0000 On Tue, Jul 22, 2014 at 08:55:54PM +0000, Clyde Wildes (cwildes) wrote: > Juergen, > > I should have qualified my response to indicate that the only URI scheme > that will be supported for file-logging is ³file:². Other distribution > actions are supported by other leaves. > OK. Although the value of using inet:uri may be limited if the only URI scheme supported is file: - well maybe this is meant to cover future extensions? But if the action is really 'file', then I am not sure a URI is required. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Jul 22 14:27:37 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84CAF1A03C1 for ; Tue, 22 Jul 2014 14:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dh6Qp5SZKe6N for ; Tue, 22 Jul 2014 14:27:35 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7B751A0322 for ; Tue, 22 Jul 2014 14:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1254; q=dns/txt; s=iport; t=1406064454; x=1407274054; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=+oTLwkH8iOUVER6jGGRnmNq92kx3EUgjFRF+HKm0rDg=; b=Qy/YOWOVH2t9yQg7FA0Qev0BK2G0JKZb1XyxHqd3YfvMNgOcGAFcZww/ a6j9adhWKJfxhpfT76HvKn6xiWMY+otH5tH7TTus2EgRiUvMN3dYgM9vU l1fYnR7tOWkLizdp2qUmgcvMbrZwH2kikhcK4SW6VyvTofTMYSmGz3nMA Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgFAAbWzlOtJV2Y/2dsb2JhbABWA4MOUlcEgnTEK4dJARl6FnaEAwEBAQQ0QwIOBAEIDgIIBCgEGRccCQIEAQ0FiEKMXJwhBpZ+FwSBIo1NJRgLEAcRgmGBVAEEmyeUM4ICgURsgQNC X-IronPort-AV: E=Sophos;i="5.01,712,1400025600"; d="scan'208";a="63138033" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP; 22 Jul 2014 21:27:34 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6MLRYmV024311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jul 2014 21:27:34 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Tue, 22 Jul 2014 16:27:33 -0500 From: "Lisa Huang (yihuan)" To: Juergen Schoenwaelder , "Clyde Wildes (cwildes)" Thread-Topic: [netmod] FW: New Version Notification for draft-wildes-netmod-syslog-model-00.txt Thread-Index: AQHPkZMp5tIX3Csi/kmACQV2dQR/PZuD8rAAgCdTI4CAAVIGgIAATtAA///lpoCAAEgmgP//wKYA Date: Tue, 22 Jul 2014 21:27:33 +0000 Message-ID: In-Reply-To: <20140722211417.GA13447@elstar.local> 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.82.239.136] Content-Type: text/plain; charset="euc-kr" Content-ID: <2FEEA4BD6BD69E4C9322B84A7B232004@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/nKzIlEgZrWu-jJQFKdhMLWQ1zkI Cc: "netmod@ietf.org" Subject: Re: [netmod] FW: New Version Notification for draft-wildes-netmod-syslog-model-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 21:27:36 -0000 QWdyZWUuIElmIGp1c3QgZm9yIGZpbGUsIFVSSSBjb3VsZCBicmluZyBtaXMtdW5kZXJzdGFuZGlu Zy4NCg0KT24gNy8yMi8xNCA1OjE0IFBNLCAiSnVlcmdlbiBTY2hvZW53YWVsZGVyIg0KPGouc2No b2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQoNCj5PbiBUdWUsIEp1bCAy MiwgMjAxNCBhdCAwODo1NTo1NFBNICswMDAwLCBDbHlkZSBXaWxkZXMgKGN3aWxkZXMpIHdyb3Rl Og0KPj4gSnVlcmdlbiwNCj4+IA0KPj4gSSBzaG91bGQgaGF2ZSBxdWFsaWZpZWQgbXkgcmVzcG9u c2UgdG8gaW5kaWNhdGUgdGhhdCB0aGUgb25seSBVUkkgc2NoZW1lDQo+PiB0aGF0IHdpbGwgYmUg c3VwcG9ydGVkIGZvciBmaWxlLWxvZ2dpbmcgaXMgqfhmaWxlOqn3LiBPdGhlciBkaXN0cmlidXRp b24NCj4+IGFjdGlvbnMgYXJlIHN1cHBvcnRlZCBieSBvdGhlciBsZWF2ZXMuDQo+PiANCj4NCj5P Sy4gQWx0aG91Z2ggdGhlIHZhbHVlIG9mIHVzaW5nIGluZXQ6dXJpIG1heSBiZSBsaW1pdGVkIGlm IHRoZSBvbmx5DQo+VVJJIHNjaGVtZSBzdXBwb3J0ZWQgaXMgZmlsZTogLSB3ZWxsIG1heWJlIHRo aXMgaXMgbWVhbnQgdG8gY292ZXINCj5mdXR1cmUgZXh0ZW5zaW9ucz8gQnV0IGlmIHRoZSBhY3Rp b24gaXMgcmVhbGx5ICdmaWxlJywgdGhlbiBJIGFtIG5vdA0KPnN1cmUgYSBVUkkgaXMgcmVxdWly ZWQuDQo+DQo+L2pzDQo+DQo+LS0gDQo+SnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBK YWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj5QaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAg ICAgICAgIENhbXB1cyBSaW5nIDEsIDI4NzU5IEJyZW1lbiwgR2VybWFueQ0KPkZheDogICArNDkg NDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0K DQo= From nobody Tue Jul 22 14:37:14 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DB51B2C61 for ; Tue, 22 Jul 2014 14:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.052 X-Spam-Level: X-Spam-Status: No, score=-12.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqrB7b8Q14Y2 for ; Tue, 22 Jul 2014 14:36:54 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E3F31B2C70 for ; Tue, 22 Jul 2014 14:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1606; q=dns/txt; s=iport; t=1406064999; x=1407274599; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wSXVOiwcNgxECkWDYwreGQem+n54Fi6CuivBVEZ16wA=; b=Jbe9GgyH6EVOKkM0s3lc8YmxQBwkVx0rJCpJ9d5OuksTgR3ihIJbwAik 5hnRE+W29hqDOBiZ3xDuAWyY2j+MN14EDW0Rb5xEV92xZDEb9SPN0CNDw wJV1bSB8vGq2i2B38sKfWoecFwedffLUtQwm8g7vhWd9VuR+1dJz3Ix3h M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkFAJzYzlOtJA2I/2dsb2JhbABWA4JqJFJXBIJ0xCuHSQEZehZ2hAMBAQEENEMCDgICAQYCDgIIBCgCAhkXHAkCBA4FiEIBjFucIQaWfBcEgSKNTSUYCxAHEYJhgVQBBJsnlDOCAoFEbIEDQg X-IronPort-AV: E=Sophos;i="5.01,712,1400025600"; d="scan'208";a="63148478" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP; 22 Jul 2014 21:36:38 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6MLacn9018303 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jul 2014 21:36:38 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Tue, 22 Jul 2014 16:36:38 -0500 From: "Clyde Wildes (cwildes)" To: Juergen Schoenwaelder Thread-Topic: [netmod] FW: New Version Notification for draft-wildes-netmod-syslog-model-00.txt Thread-Index: AQHPkZMp5tIX3Csi/kmACQV2dQR/PZuD8rAAgCdTI4CAAVIGgIAATtAA///lpoCAAEgmgP//wzyA Date: Tue, 22 Jul 2014 21:36:38 +0000 Message-ID: References: <20140722183022.GA12921@elstar.local> <20140722211417.GA13447@elstar.local> In-Reply-To: <20140722211417.GA13447@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.67.171] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Mu3pAa4BDwrgTmyEtOEZLURdoiI Cc: "netmod@ietf.org" Subject: Re: [netmod] FW: New Version Notification for draft-wildes-netmod-syslog-model-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 21:36:58 -0000 SnVlcmdlbiwNCg0KSSB0aGluayB0aGF0IHRoZXJlIGlzIGJlbmVmaXQgdG8gdXNlIGluZXQ6dXJp IGV2ZW4gdGhvdWdoIGl0IGlzIHdpbGwgYmUNCnJlc3RyaWN0ZWQgdG8gdGhlIKGwZmlsZTqhsSBz Y2hlbWUgYmVjYXVzZSBpdCBpcyBtb3JlIHNwZWNpZmljLiBGcm9tIHRoZSBSRkMNCjYwMjEgVVJJ IGRlc2NyaXB0aW9uICJPYmplY3RzIHVzaW5nIHRoZSB1cmkgdHlwZSBNVVNUIGJlIGluIFVTLUFT Q0lJDQplbmNvZGluZywgYW5kIE1VU1QgYmUgbm9ybWFsaXplZCBhcyBkZXNjcmliZWQgYnkgUkZD IDM5ODahpqGxLg0KDQpUaGFua3MsDQoNCkNseWRlDQoNCk9uIDcvMjIvMTQsIDU6MTQgUE0sICJK dWVyZ2VuIFNjaG9lbndhZWxkZXIiDQo8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5 LmRlPiB3cm90ZToNCg0KPk9uIFR1ZSwgSnVsIDIyLCAyMDE0IGF0IDA4OjU1OjU0UE0gKzAwMDAs IENseWRlIFdpbGRlcyAoY3dpbGRlcykgd3JvdGU6DQo+PiBKdWVyZ2VuLA0KPj4gDQo+PiBJIHNo b3VsZCBoYXZlIHF1YWxpZmllZCBteSByZXNwb25zZSB0byBpbmRpY2F0ZSB0aGF0IHRoZSBvbmx5 IFVSSSBzY2hlbWUNCj4+IHRoYXQgd2lsbCBiZSBzdXBwb3J0ZWQgZm9yIGZpbGUtbG9nZ2luZyBp cyCp+GZpbGU6qfcuIE90aGVyIGRpc3RyaWJ1dGlvbg0KPj4gYWN0aW9ucyBhcmUgc3VwcG9ydGVk IGJ5IG90aGVyIGxlYXZlcy4NCj4+IA0KPg0KPk9LLiBBbHRob3VnaCB0aGUgdmFsdWUgb2YgdXNp bmcgaW5ldDp1cmkgbWF5IGJlIGxpbWl0ZWQgaWYgdGhlIG9ubHkNCj5VUkkgc2NoZW1lIHN1cHBv cnRlZCBpcyBmaWxlOiAtIHdlbGwgbWF5YmUgdGhpcyBpcyBtZWFudCB0byBjb3Zlcg0KPmZ1dHVy ZSBleHRlbnNpb25zPyBCdXQgaWYgdGhlIGFjdGlvbiBpcyByZWFsbHkgJ2ZpbGUnLCB0aGVuIEkg YW0gbm90DQo+c3VyZSBhIFVSSSBpcyByZXF1aXJlZC4NCj4NCj4vanMNCj4NCj4tLSANCj5KdWVy Z2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21i SA0KPlBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSwgMjg3NTkg QnJlbWVuLCBHZXJtYW55DQo+RmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cDov L3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQoNCg== From nobody Tue Jul 22 15:23:11 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FFE1B28E1 for ; Tue, 22 Jul 2014 15:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KK7UOpT1ORvI for ; Tue, 22 Jul 2014 15:23:07 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A3761B28D3 for ; Tue, 22 Jul 2014 15:23:07 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 58E5DED4; Wed, 23 Jul 2014 00:23:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id XA-IiR8wHopO; Wed, 23 Jul 2014 00:22:56 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 23 Jul 2014 00:23:05 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C07BC2002C; Wed, 23 Jul 2014 00:23:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gAGmm2vtOAF2; Wed, 23 Jul 2014 00:23: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 B02A120017; Wed, 23 Jul 2014 00:23:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7BFB72DE0213; Wed, 23 Jul 2014 00:23:04 +0200 (CEST) Date: Wed, 23 Jul 2014 00:23:04 +0200 From: Juergen Schoenwaelder To: "Clyde Wildes (cwildes)" Message-ID: <20140722222304.GA13570@elstar.local> Mail-Followup-To: "Clyde Wildes (cwildes)" , "Lisa Huang (yihuan)" , "netmod@ietf.org" References: <20140722183022.GA12921@elstar.local> <20140722211417.GA13447@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Y28Q2ckRBWkJavUXy9gTSplZJWc Cc: "netmod@ietf.org" Subject: Re: [netmod] FW: New Version Notification for draft-wildes-netmod-syslog-model-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 22 Jul 2014 22:23:08 -0000 On Tue, Jul 22, 2014 at 09:36:38PM +0000, Clyde Wildes (cwildes) wrote: > Juergen, > > I think that there is benefit to use inet:uri even though it is will be > restricted to the “file:†scheme because it is more specific. From the RFC > 6021 URI description "Objects using the uri type MUST be in US-ASCII > encoding, and MUST be normalized as described by RFC 3986…â€. > I see. The question, though, is whether the URI imposed encoding rules are a feature given that NETCONF handles UTF-8 just fine. I guess I would like URIs more for extensibility reasons (but then it was said that this action is limited to local files). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Jul 22 15:40:36 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81FE1A039D for ; Tue, 22 Jul 2014 15:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKCHFgnxAffb for ; Tue, 22 Jul 2014 15:40:34 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795811A02A5 for ; Tue, 22 Jul 2014 15:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1313; q=dns/txt; s=iport; t=1406068835; x=1407278435; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=SJcKC8eR6EZyM9u6KDFeGOc8iGhK+36WHTbYcZWTqhA=; b=dKcrzI/jSM9ll+Ef+X8G0VE8Vqo7iD4syhJKfdZOf+imjQWsXGsTIsAi c0QxiV1ZKq3B/Yt/1xhF43RgceaCE2LJslkCYjoCPFpLcCtm2uYrViRgv qEWWCnrZ0aaBYQv+wKnnOag8fVrvdO3TMbOJnBulQE+lpdXRXMJ++bbD3 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAF3nzlOtJA2F/2dsb2JhbABWA4MOUlcExyCHSQGBEhZ2hAMBAQEEdwIOBAEIDgIISRccCQIEAQ0FiELAKxcEjm8BJCMQBxGENQEEmyeUM4ICgURsgQMBHyI X-IronPort-AV: E=Sophos;i="5.01,713,1400025600"; d="scan'208";a="341877176" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-1.cisco.com with ESMTP; 22 Jul 2014 22:40:33 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s6MMeWq2009785 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jul 2014 22:40:32 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Tue, 22 Jul 2014 17:40:32 -0500 From: "Lisa Huang (yihuan)" To: Juergen Schoenwaelder , "Clyde Wildes (cwildes)" Thread-Topic: [netmod] FW: New Version Notification for draft-wildes-netmod-syslog-model-00.txt Thread-Index: AQHPkZMp5tIX3Csi/kmACQV2dQR/PZuD8rAAgCdTI4CAAVIGgIAATtAA///lpoCAAEgmgP//wzyAgABP/AD//8HRAA== Date: Tue, 22 Jul 2014 22:40:31 +0000 Message-ID: In-Reply-To: <20140722222304.GA13570@elstar.local> 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.82.239.136] Content-Type: text/plain; charset="Windows-1252" Content-ID: <3E3A628DDF59644AB5C664B24C06D6BD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/boCq08KXQlaW1TlF5ift-rz1JRs Cc: "netmod@ietf.org" Subject: Re: [netmod] FW: New Version Notification for draft-wildes-netmod-syslog-model-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 22:40:35 -0000 If just meant to use file uri, Which way would makes more sense? 1. Using uri with pattern regex/description to limit to local file uri. 2. Using string with pattern regex/description to limit to local file uri. If just file uri, would you recommend to use uri with patten to limit to file uri or string=20 On 7/22/14 6:23 PM, "Juergen Schoenwaelder" wrote: >On Tue, Jul 22, 2014 at 09:36:38PM +0000, Clyde Wildes (cwildes) wrote: >> Juergen, >>=20 >> I think that there is benefit to use inet:uri even though it is will be >> restricted to the =B3file:=B2 scheme because it is more specific. From t= he >>RFC >> 6021 URI description "Objects using the uri type MUST be in US-ASCII >> encoding, and MUST be normalized as described by RFC 3986=8A=B2. >>=20 > >I see. The question, though, is whether the URI imposed encoding rules >are a feature given that NETCONF handles UTF-8 just fine. I guess I >would like URIs more for extensibility reasons (but then it was said >that this action is limited to local files). > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 From nobody Tue Jul 22 15:49:34 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099EF1A07A1; Tue, 22 Jul 2014 15:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dss34LfTw6fF; Tue, 22 Jul 2014 15:49:27 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675941A0646; Tue, 22 Jul 2014 15:49:27 -0700 (PDT) Received: from BN1PR05MB154.namprd05.prod.outlook.com (10.255.205.19) by BN1PR05MB059.namprd05.prod.outlook.com (10.255.202.149) with Microsoft SMTP Server (TLS) id 15.0.990.7; Tue, 22 Jul 2014 22:49:25 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB154.namprd05.prod.outlook.com (10.255.205.19) with Microsoft SMTP Server (TLS) id 15.0.990.7; Tue, 22 Jul 2014 22:49:25 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.39]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.39]) with mapi id 15.00.0995.014; Tue, 22 Jul 2014 22:49:25 +0000 From: Dean Bogdanovic To: "" , "netmod@ietf.org" Thread-Topic: i2rs requirements draft Thread-Index: AQHPpf8u0Mc/JKhi6k20vGS/ckMDww== Date: Tue, 22 Jul 2014 22:49:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02801ACE41 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(86362001)(93916002)(92726001)(110136001)(558084003)(101416001)(50226001)(87286001)(89996001)(88136002)(77156001)(92566001)(31966008)(36756003)(83322001)(107046002)(229853001)(85852003)(77982001)(106116001)(50986999)(95666004)(105586002)(77096002)(2656002)(62966002)(74502001)(104166001)(79102001)(57306001)(85306003)(76482001)(46102001)(20776003)(4396001)(81542001)(99286002)(64706001)(74662001)(83072002)(87936001)(81342001)(66066001)(106356001)(21056001)(33656002)(80022001)(99396002)(104396001)(491001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB154; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <4E30BB54711FA44186E81D1898995043@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/l-L9YnOxSIatUHWayNwooF_PFrA Cc: Jeff Haas Subject: [netmod] i2rs requirements draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 22:49:29 -0000 Just to follow up from the meeting. I'm volunteering to write up i2rs requi= rements to NETCONF WG, essentially RESTCONF/NETCONF part. Would need a co a= uthor for the NETMOD WG part. Dean From nobody Tue Jul 22 19:47:19 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7D91A027C for ; Tue, 22 Jul 2014 19:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIAoLwRZ700B for ; Tue, 22 Jul 2014 19:47:16 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28E761A0217 for ; Tue, 22 Jul 2014 19:47:16 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E6E8F731; Wed, 23 Jul 2014 04:47:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id BSnOc_D6on-r; Wed, 23 Jul 2014 04:47:04 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 23 Jul 2014 04:47:14 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1E17D2002C; Wed, 23 Jul 2014 04:47:14 +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 AlTsHi5E63s3; Wed, 23 Jul 2014 04:47:13 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EDB4F20017; Wed, 23 Jul 2014 04:47:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 28B5E2DE0401; Wed, 23 Jul 2014 04:47:11 +0200 (CEST) Date: Wed, 23 Jul 2014 04:47:11 +0200 From: Juergen Schoenwaelder To: "Lisa Huang (yihuan)" Message-ID: <20140723024711.GA14166@elstar.local> Mail-Followup-To: "Lisa Huang (yihuan)" , "Clyde Wildes (cwildes)" , "netmod@ietf.org" References: <20140722222304.GA13570@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/P5u_S9AKrlMovr_USlLgCMczgc0 Cc: "netmod@ietf.org" Subject: Re: [netmod] FW: New Version Notification for draft-wildes-netmod-syslog-model-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jul 2014 02:47:17 -0000 On Tue, Jul 22, 2014 at 10:40:31PM +0000, Lisa Huang (yihuan) wrote: > If just meant to use file uri, Which way would makes more sense? > > 1. Using uri with pattern regex/description to limit to local file uri. > 2. Using string with pattern regex/description to limit to local file uri. > > If just file uri, would you recommend to use uri with patten to limit to > file uri or string If it is a URI, you really want to use inet:uri since otherwise you have to repeat text that is already in the inet:uri description. While a pattern can be used to restrict the uri schemes, this is probably not what I would do since this does not allow to ever support additional schemes should that be necessary. I would probably instead write in the description clause that only file: URI schemes must be supported and I would perhaps detail which error is returned in case of an attempt to configure a scheme not supported. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Jul 22 21:22:43 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768CC1A0302 for ; Tue, 22 Jul 2014 21:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.065 X-Spam-Level: X-Spam-Status: No, score=-0.065 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C299Xas-TSEk for ; Tue, 22 Jul 2014 21:22:35 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D882A1A0301 for ; Tue, 22 Jul 2014 21:22:34 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A4419102D for ; Wed, 23 Jul 2014 06:22:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id KKEQOGPszoBU for ; Wed, 23 Jul 2014 06:22:22 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 23 Jul 2014 06:22:32 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9FBF02002C for ; Wed, 23 Jul 2014 06:22:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1P0BPObG3n1D; Wed, 23 Jul 2014 06:22:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8BCB120017; Wed, 23 Jul 2014 06:22:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5B49F2DE0580; Wed, 23 Jul 2014 06:22:31 +0200 (CEST) Date: Wed, 23 Jul 2014 06:22:30 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140723042230.GA14747@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/QavF0xWKdHBlJ3EVoeqP0AI7IqQ Subject: Re: [netmod] I-D Action: draft-schoenw-netmod-yang-pattern-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jul 2014 04:22:39 -0000 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, a while ago, I thought it might be useful to collect and document some design patterns while we learn how to use YANG best. This I-D is really just a start at the moment. But perhaps we find more recurring pattern that are worthwhile to document. Suggestions for additional pattern to cover are welcome as well as review and improvements for the pattern already covered. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --Q68bSM7Ycu6FN28Q Content-Type: message/rfc822 Content-Disposition: inline Received: from hermes.jacobs-university.de (212.201.44.23) by SHUBCAS04.jacobs.jacobs-university.de (10.70.0.128) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 23 Jul 2014 06:01:21 +0200 Received: from atlas2.jacobs-university.de (atlas2a.jacobs-university.de [212.201.44.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "atlas2.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id B8E7220017 for ; Wed, 23 Jul 2014 06:01:21 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by atlas2.jacobs-university.de (Postfix) with ESMTP id 33C6A6B7 for ; Wed, 23 Jul 2014 06:01:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-100 required=6.2 tests=[BAYES_00=-1.5, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Authentication-Results: demetrius4.jacobs-university.de (amavisd-new); dkim=pass (1024-bit key) header.d=ietf.org Received: from atlas2b.jacobs-university.de ([212.201.44.15]) by localhost (demetrius4.jacobs-university.de [212.201.44.49]) (amavisd-new, port 10030) with ESMTP id sXfJ88QzxjGj for ; Wed, 23 Jul 2014 06:01:20 +0200 (CEST) X-JacobsISPWhiteListed: No X-policyd-weight: using cached result; rate:hard: -6.1 Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by atlas2b.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 23 Jul 2014 06:01:20 +0200 (CEST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6671A0A90; Tue, 22 Jul 2014 21:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1406088056; bh=4/sTW2KPtF47RXZ/uBUTNfjcwQDnik2822l80E4GN1w=; h=MIME-Version:From:To:Subject:Message-ID:Date:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=TjNY/9dTRDC3JVq3wuCpx+ojKM01RvBWJ517NLuvwBA1FmhR27nEyfc9VuSN9DMYd CNX9A4f2k+k8YnANYV23QEqeuN58uNNRby/qRKLwZTgWFyj7RbndnWSlK5tNFgw1uH BtcNPbmcykYhwKdllK4mBy69sfUAQHif9E9SJzBc= X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6EBD1A037B for ; Tue, 22 Jul 2014 21:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTPBi1gcmd_A for ; Tue, 22 Jul 2014 21:00:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F120A1A0348 for ; Tue, 22 Jul 2014 21:00:51 -0700 (PDT) From: To: Subject: I-D Action: draft-schoenw-netmod-yang-pattern-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140723040051.14508.86029.idtracker@ietfa.amsl.com> Date: Tue, 22 Jul 2014 21:00:51 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/i-d-announce/RNOOK9QEbnirMh9h_zAiqj1Umfg X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.15 Reply-To: List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: i-d-announce-bounces@ietf.org Sender: I-D-Announce Return-Path: i-d-announce-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: SHUBCAS04.jacobs.jacobs-university.de X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 MIME-Version: 1.0 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Collection of YANG Design Patterns Authors : Juergen Schoenwaelder Martin Bjorklund Filename : draft-schoenw-netmod-yang-pattern-00.txt Pages : 11 Date : 2014-07-22 Abstract: YANG is a data modeling language used to model configuration and state data, remote procedure calls and notifications. This memo documents a number of YANG design patterns. These design patterns aim at providing general reusable solutions to commonly occurring problems in the design of YANG data models. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-schoenw-netmod-yang-pattern/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-schoenw-netmod-yang-pattern-00 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 --Q68bSM7Ycu6FN28Q-- From nobody Tue Jul 22 21:52:17 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72FFF1B2831 for ; Tue, 22 Jul 2014 21:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcFILccRFTOV for ; Tue, 22 Jul 2014 21:52:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 377F71B28A4 for ; Tue, 22 Jul 2014 21:52:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140723045213.32121.96011.idtracker@ietfa.amsl.com> Date: Tue, 22 Jul 2014 21:52:13 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/KzRKw56pwWQLPveXB97OQjUwUbE Subject: [netmod] Milestones changed for netmod WG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 04:52:15 -0000 Changed milestone "Submit first working group draft of YANG 1.1", resolved as "Done", added draft-ietf-netmod-rfc6020bis to milestone. URL: http://datatracker.ietf.org/wg/netmod/charter/ From nobody Tue Jul 22 21:53:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678211B289E for ; Tue, 22 Jul 2014 21:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSo9YlRFMFKQ for ; Tue, 22 Jul 2014 21:53:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4D61B28A6 for ; Tue, 22 Jul 2014 21:53:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140723045326.32698.65084.idtracker@ietfa.amsl.com> Date: Tue, 22 Jul 2014 21:53:26 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/MUXZJnA2s_Ttv-gXMTW8iJWyHsM Subject: [netmod] Milestones changed for netmod WG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 04:53:28 -0000 Changed milestone "Submit first working group draft of YANG guidelines update", resolved as "Done", added draft-ietf-netmod-rfc6087bis to milestone. URL: http://datatracker.ietf.org/wg/netmod/charter/ From nobody Wed Jul 23 03:59:54 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1AEF1A0453; Wed, 23 Jul 2014 03:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRgU8qznzjCX; Wed, 23 Jul 2014 03:59:46 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCB861A0422; Wed, 23 Jul 2014 03:59:45 -0700 (PDT) Received: from [172.16.50.248] (unknown [206.47.221.210]) by mail.nic.cz (Postfix) with ESMTPSA id 9BA6214006C; Wed, 23 Jul 2014 12:59:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1406113184; bh=72ocPqDkoQfCUcRxQhoX08i+SIzKy13PRpMxC0c7RFg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ZJVEq0KtI9AxbmQRUysZq5A3aNTJlpDYNJv3QSMG7k9EjyjUjtWiuQio4UxCIrfoi 8wPNIswPc5wWOzsNOQdQnD3AAu7Ua8IQNaQSHYQaLNoY/wpyP1sfdukGlMCOIDWevb JVW1XzD55ykS7HQreI51QGanOeSwyPD1Zj0khrRY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 23 Jul 2014 06:59:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <49778DBA-3D86-4DF6-A304-4EE94CF1DBB1@nic.cz> References: To: Dean Bogdanovic X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/JFIhH6Y0DEP9covdENBdgBAvgk8 Cc: Jeff Haas , Netconf , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] i2rs requirements draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 10:59:49 -0000 Hi Dean, I can do that. Lada On 22 Jul 2014, at 18:49, Dean Bogdanovic wrote: > Just to follow up from the meeting. I'm volunteering to write up i2rs = requirements to NETCONF WG, essentially RESTCONF/NETCONF part. Would = need a co author for the NETMOD WG part. >=20 > Dean >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 23 07:27:42 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D7E1B27D4; Wed, 23 Jul 2014 07:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZSW5k2kPjuF; Wed, 23 Jul 2014 07:27:39 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 95E1D1B27CA; Wed, 23 Jul 2014 07:27:39 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 5F2DDC1FA; Wed, 23 Jul 2014 10:27:39 -0400 (EDT) Date: Wed, 23 Jul 2014 10:27:39 -0400 From: Jeffrey Haas To: Ladislav Lhotka Message-ID: <20140723142739.GD4653@pfrc> References: <49778DBA-3D86-4DF6-A304-4EE94CF1DBB1@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49778DBA-3D86-4DF6-A304-4EE94CF1DBB1@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4eDr1MA6-IMhicjmE55oP5y7IVs Cc: Jeff Haas , "netmod@ietf.org" , Netconf Subject: Re: [netmod] [Netconf] i2rs requirements draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 14:27:40 -0000 Thanks for the support! Ed and I will be in contact soon. -- Jeff On Wed, Jul 23, 2014 at 06:59:10AM -0400, Ladislav Lhotka wrote: > Hi Dean, > > I can do that. > > Lada > > On 22 Jul 2014, at 18:49, Dean Bogdanovic wrote: > > > Just to follow up from the meeting. I'm volunteering to write up i2rs requirements to NETCONF WG, essentially RESTCONF/NETCONF part. Would need a co author for the NETMOD WG part. > > > > Dean > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Jul 23 07:42:14 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCC71A052E; Wed, 23 Jul 2014 07:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSPkACbbVai6; Wed, 23 Jul 2014 07:42:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C1B1A0107; Wed, 23 Jul 2014 07:42:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140723144200.23732.52250.idtracker@ietfa.amsl.com> Date: Wed, 23 Jul 2014 07:42:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/zeaWFIsFEerVTfrWgig5eyTamJc Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-snmp-cfg-06.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 14:42:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : A YANG Data Model for SNMP Configuration Authors : Martin Bjorklund Juergen Schoenwaelder Filename : draft-ietf-netmod-snmp-cfg-06.txt Pages : 80 Date : 2014-07-23 Abstract: This document defines a collection of YANG definitions for configuring SNMP engines. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-snmp-cfg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-snmp-cfg-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-snmp-cfg-06 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/ From nobody Wed Jul 23 11:09:16 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6B51A0ABD for ; Wed, 23 Jul 2014 11:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZjmJr2V0tsR for ; Wed, 23 Jul 2014 11:09:09 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8721A0AC7 for ; Wed, 23 Jul 2014 11:09:09 -0700 (PDT) X-AuditID: c1b4fb30-f79da6d000006b80-97-53cffa43a267 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FA.D2.27520.34AFFC35; Wed, 23 Jul 2014 20:09:07 +0200 (CEST) Received: from ESESSMB103.ericsson.se ([169.254.3.143]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0174.001; Wed, 23 Jul 2014 20:09:06 +0200 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: "netmod@ietf.org" Thread-Topic: Issue Y36: associate a notification with a data node Thread-Index: Ac+mg6mM7xFT6+1YQna90h/wt1aQxAAHNpRw Date: Wed, 23 Jul 2014 18:09:06 +0000 Message-ID: <971D4B790EC8B846BE223DD23AF72FF11EB7AE32@ESESSMB103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_971D4B790EC8B846BE223DD23AF72FF11EB7AE32ESESSMB103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvja7zr/PBBt1PlS3mX2xkdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxr3Xk9gL9ntXTP3cw9jAeNGhi5GTQ0LAROL2jd2MELaYxIV7 69m6GLk4hASOMko8XbmLGcJZwihxcdFEdpAqNgFXiWOfvrOA2CIC6hIzd4J0cHIIC9hK/L/3 nBEi7iRx7e49IJsDyDaSOLbKHyTMIqAqce78ZmYQm1fAV+J+ywuwkYxAi7+fWsMEYjMLiEvc ejKfCeIgAYkle84zQ9iiEi8f/2OFsJUkVmy/xAhRny/xaeYudoiZghInZz5hmcAoNAvJqFlI ymYhKYOI60ncmDqFDcLWlli28DUzhK0rMePfIRZk8QWM7KsYRYtTi5Ny042M9FKLMpOLi/Pz 9PJSSzYxAmPi4JbfBjsYXz53PMQowMGoxMP7cP/5YCHWxLLiytxDjNIcLErivAvPzQsWEkhP LEnNTk0tSC2KLyrNSS0+xMjEwSnVwOjBxffBe7d+GfPbrwrZwcwv/t86x3HksntFsfU5KSaH HB0F69v72+psl4hPiXq4+WCzr5jqcc2TSX0JtkcPXPHOCOtk8/VVO9N08N0ugQP3py/MvV4c ITen5nDjfdnZTy/arlmlxlcmWfb1yO3tP5h9b6RPv2JS/lXM7oPGpU27JWa8YZWz9VNiKc5I NNRiLipOBABT17bqagIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7W-7Fr2957fQ0KCFqVOEbG-QkXM Subject: [netmod] Issue Y36: associate a notification with a data node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 18:09:12 -0000 --_000_971D4B790EC8B846BE223DD23AF72FF11EB7AE32ESESSMB103erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Ericsson would need this topic, but as someone has already raised: why just= notifications, associating RPCs with data nodes would be even more importa= nt. We see a number of reasons for this association: 1) Access control: If RPCs and Notifications are associated to data no= des, it is enough to configure access control for the data node. Today, the= operator needs to configure access control for the data nodes and after th= at separately for each RPC/notification again. Also understanding which act= ion/rpc is carrying what data, thus how sensitive it is, which group should= have access to it is not trivial. The operator has to read and understand = all rpcs/notifications one by one. If the rpc/notification is generic (can = relate to different parts of the data model), it cannot be access controlle= d properly at all. The amount of work needed by the operator for configurin= g access control is critical, if they have more work they have more room fo= r mistakes, less likely to get it done properly. 2) It is a natural way of thinking to associate notifications/rpcs wit= h data items. If I want to reload a backup, I will look for the reload rpc = in the backup branch of my model, not elsewhere. 3) If we want RPCs with the same name (e.g. restart node, restart inte= rface gracefully) but different parameters that cannot be done nicely today= . 4) For most of us YANG drives the CLI besides Netconf. In the CLI at t= he root of the model all rpcs will be available for the CLI user. So if the= user calls help he will get a list of all rpcs. With more and more data mo= dels defined this results in dozens potentially hundreds of rpcs being list= ed. Unusable. If rpcs would be connected to the data nodes, then only a sma= ll number of relevant rpcs would be listed. 5) All our(Ericsson's) internal model writers use and want rpcs connec= ted to the data nodes. AFAIK at least 3 separate implementations already use this feature. The sam= e issue nearly made it into YANG 1.0, it was only dropped of because time p= ressure. So for these reasons we need rpcs/notifications connected to data nodes. Regards Balazs --_000_971D4B790EC8B846BE223DD23AF72FF11EB7AE32ESESSMB103erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

Ericsson would need this topic, but as someone has a= lready raised: why just notifications, associating RPCs with data nodes wou= ld be even more important.

We see a number of reasons for this association:

 

1)      Access control: If RPCs and Notifications are assoc= iated to data nodes, it is enough to configure access control for the data = node. Today, the operator needs to configure access control for the data no= des and after that separately for each RPC/notification again. Also understanding which action/rpc is carryi= ng what data, thus how sensitive it is, which group should have access to i= t is not trivial. The operator has to read and understand all rpcs/notifica= tions one by one. If the rpc/notification is generic (can relate to different parts of the data model), it cannot be= access controlled properly at all. The amount of work needed by the operat= or for configuring access control is critical, if they have more work they = have more room for mistakes, less likely to get it done properly.

2)      It is a natural way of thinking to associate notifi= cations/rpcs with data items. If I want to reload a backup, I will look for= the reload rpc in the backup branch of my model, not elsewhere.=

3)      If we want RPCs with the same name (e.g. restart no= de, restart interface gracefully) but different parameters that cannot be d= one nicely today.

4)      For most of us YANG drives the CLI besides Netconf.= In the CLI at the root of the model all rpcs will be available for the CLI= user. So if the user calls help he will get a list of all rpcs. With more = and more data models defined this results in dozens potentially hundreds of rpcs being listed. Unusable. If = rpcs would be connected to the data nodes, then only a small number of rele= vant rpcs would be listed.

5)      All our(Ericsson’s) internal model writers us= e and want rpcs connected to the data nodes.

 

AFAIK at least 3 separate implementations already us= e this feature. The same issue nearly made it= into YANG 1.0, it was only dropped of because time pressure.

 

So for these reasons we need rpcs/notifications conn= ected to data nodes.

Regards Balazs

--_000_971D4B790EC8B846BE223DD23AF72FF11EB7AE32ESESSMB103erics_-- From nobody Wed Jul 23 11:09:17 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37AA41A0ABD for ; Wed, 23 Jul 2014 11:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J_m0Z_r4wI5Y for ; Wed, 23 Jul 2014 11:09:11 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53D251A0AE4 for ; Wed, 23 Jul 2014 11:09:10 -0700 (PDT) X-AuditID: c1b4fb3a-f79a36d000000ffa-02-53cffa4410f7 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 79.DD.04090.44AFFC35; Wed, 23 Jul 2014 20:09:08 +0200 (CEST) Received: from ESESSMB103.ericsson.se ([169.254.3.143]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0174.001; Wed, 23 Jul 2014 20:09:08 +0200 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: "netmod@ietf.org" Thread-Topic: Issue Y36: associate a notification with a data node Thread-Index: Ac+mg6mM7xFT6+1YQna90h/wt1aQxAAHUm1A Date: Wed, 23 Jul 2014 18:09:07 +0000 Message-ID: <971D4B790EC8B846BE223DD23AF72FF11EB7AE39@ESESSMB103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_971D4B790EC8B846BE223DD23AF72FF11EB7AE39ESESSMB103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvja7Lr/PBBvt+KVrMv9jI6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMaDc1gL/ntWTPjzm6mBcad9FyMnh4SAicS1x32sELaYxIV7 69m6GLk4hASOMkosv9bIAuEsYZSYcP86G0gVm4CrxLFP31lAbBEBdYmZO9eDxYUFbCX+33vO CBF3krh29x6UbSTxacUv9i5GDg4WAVWJ65+DQcK8Ar4S/2+sZgaxGYEWfz+1hgnEZhYQl7j1 ZD4TxEECEkv2nGeGsEUlXj7+B3WoksSK7ZcYIerzJab/+8IEMVNQ4uTMJywTGIVmIRk1C0nZ LCRlEHE9iRtTp7BB2NoSyxa+ZoawdSVm/DvEgiy+gJF9FaNocWpxcW66kZFealFmcnFxfp5e XmrJJkZgTBzc8ttqB+PB546HGAU4GJV4eB/sPx8sxJpYVlyZe4hRmoNFSZx34bl5wUIC6Ykl qdmpqQWpRfFFpTmpxYcYmTg4pRoYM29zB6WoN4fcq5h1/vWp0srkldqbdLMn7rypX/9/8fTm tywnTD6yq/cyTczlOPJ+6kQLsfOMj4X2lHc5lT1MF/j6wdb8ULnUobMOPhe6pD8Wzg32XHzM 3p4jysxkH3+6gNK2GJtPpbxGOpPdRDi5vc4aGoZsS2Mqfn12qmAvh1BMtRDPve9KLMUZiYZa zEXFiQAhn3ENagIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/uqYTnus9wUrbRY0ydJC2sNekjmo Subject: [netmod] Issue Y36: associate a notification with a data node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 18:09:13 -0000 --_000_971D4B790EC8B846BE223DD23AF72FF11EB7AE39ESESSMB103erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Ericsson would need this topic, but as someone has already raised: why just= notifications, associating RPCs with data nodes would be even more importa= nt. We see a number of reasons for this association: 1) Access control: If RPCs and Notifications are associated to data no= des, it is enough to configure access control for the data node. Today, the= operator needs to configure access control for the data nodes and after th= at separately for each RPC/notification again. Also understanding which act= ion/rpc is carrying what data, thus how sensitive it is, which group should= have access to it is not trivial. The operator has to read and understand = all rpcs/notifications one by one. If the rpc/notification is generic (can = relate to different parts of the data model), it cannot be access controlle= d properly at all. The amount of work needed by the operator for configurin= g access control is critical, if they have more work they have more room fo= r mistakes, less likely to get it done properly. 2) It is a natural way of thinking to associate notifications/rpcs wit= h data items. If I want to reload a backup, I will look for the reload rpc = in the backup branch of my model, not elsewhere. 3) If we want RPCs with the same name (e.g. restart node, restart inte= rface gracefully) but different parameters that cannot be done nicely today= . 4) For most of us YANG drives the CLI besides Netconf. In the CLI at t= he root of the model all rpcs will be available for the CLI user. So if the= user calls help he will get a list of all rpcs. With more and more data mo= dels defined this results in dozens potentially hundreds of rpcs being list= ed. Unusable. If rpcs would be connected to the data nodes, then only a sma= ll number of relevant rpcs would be listed. 5) All our(Ericsson's) internal model writers use and want rpcs connec= ted to the data nodes. AFAIK at least 3 separate implementations already use this feature. So for these reasons we need rpcs/notifications connected to data nodes. Regards Balazs --_000_971D4B790EC8B846BE223DD23AF72FF11EB7AE39ESESSMB103erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

Ericsson would need this topic, but as someone has a= lready raised: why just notifications, associating RPCs with data nodes wou= ld be even more important.

We see a number of reasons for this association:

 

1)      Access control: If RPCs and Notifications are assoc= iated to data nodes, it is enough to configure access control for the data = node. Today, the operator needs to configure access control for the data no= des and after that separately for each RPC/notification again. Also understanding which action/rpc is carryi= ng what data, thus how sensitive it is, which group should have access to i= t is not trivial. The operator has to read and understand all rpcs/notifica= tions one by one. If the rpc/notification is generic (can relate to different parts of the data model), it cannot be= access controlled properly at all. The amount of work needed by the operat= or for configuring access control is critical, if they have more work they = have more room for mistakes, less likely to get it done properly.

2)      It is a natural way of thinking to associate notifi= cations/rpcs with data items. If I want to reload a backup, I will look for= the reload rpc in the backup branch of my model, not elsewhere.=

3)      If we want RPCs with the same name (e.g. restart no= de, restart interface gracefully) but different parameters that cannot be d= one nicely today.

4)      For most of us YANG drives the CLI besides Netconf.= In the CLI at the root of the model all rpcs will be available for the CLI= user. So if the user calls help he will get a list of all rpcs. With more = and more data models defined this results in dozens potentially hundreds of rpcs being listed. Unusable. If = rpcs would be connected to the data nodes, then only a small number of rele= vant rpcs would be listed.

5)      All our(Ericsson’s) internal model writers us= e and want rpcs connected to the data nodes.

 

AFAIK at least 3 separate implementations already us= e this feature.

 

So for these reasons we need rpcs/notifications conn= ected to data nodes.

Regards Balazs

--_000_971D4B790EC8B846BE223DD23AF72FF11EB7AE39ESESSMB103erics_-- From nobody Wed Jul 23 11:40:05 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C761A034B for ; Wed, 23 Jul 2014 11:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-6PjREI9w5Y for ; Wed, 23 Jul 2014 11:40:02 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08E871A0460 for ; Wed, 23 Jul 2014 11:40:02 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C13A611FC; Wed, 23 Jul 2014 20:40:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id CXQXcnZK27vD; Wed, 23 Jul 2014 20:39:47 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 23 Jul 2014 20:40:00 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E8112002C; Wed, 23 Jul 2014 20:40:00 +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 P0r89QK1zBFk; Wed, 23 Jul 2014 20:39:58 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 340B320017; Wed, 23 Jul 2014 20:39:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1F9842DF793A; Wed, 23 Jul 2014 20:39:58 +0200 (CEST) Date: Wed, 23 Jul 2014 20:39:58 +0200 From: Juergen Schoenwaelder To: =?iso-8859-1?Q?Bal=E1zs?= Lengyel Message-ID: <20140723183958.GB41350@elstar.local> Mail-Followup-To: =?iso-8859-1?Q?Bal=E1zs?= Lengyel , "netmod@ietf.org" References: <971D4B790EC8B846BE223DD23AF72FF11EB7AE39@ESESSMB103.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <971D4B790EC8B846BE223DD23AF72FF11EB7AE39@ESESSMB103.ericsson.se> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/WyAv6toWC9iaLjpnvCnB5OKICkU Cc: "netmod@ietf.org" Subject: Re: [netmod] Issue Y36: associate a notification with a data node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jul 2014 18:40:04 -0000 On Wed, Jul 23, 2014 at 06:09:07PM +0000, Balázs Lengyel wrote: > 1) Access control: If RPCs and Notifications are associated to data nodes, it is enough to configure access control for the data node. Today, the operator needs to configure access control for the data nodes and after that separately for each RPC/notification again. Also understanding which action/rpc is carrying what data, thus how sensitive it is, which group should have access to it is not trivial. The operator has to read and understand all rpcs/notifications one by one. If the rpc/notification is generic (can relate to different parts of the data model), it cannot be access controlled properly at all. The amount of work needed by the operator for configuring access control is critical, if they have more work they have more room for mistakes, less likely to get it done properly. > While I see your point, perhaps we need to study at how NACM today works. Figure 2 in RFC 6536 seems to indicate that RPC access control actually goes through write data node access control (but it seems to bypass read data node access control, which surprises me). You have, however, a point for RPCs that affect an underlying resource but not any of the data nodes directly. But then I am not sure NACM would without any changes actually apply the data node access control to an execute permission of an RPC associated with a data node. I guess I need Andy or Martin to help me understand whether associating RPC and Notifications with data nodes actually gives you what you are looking for or whether this also needs changes/clarifications to RFC 6536. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jul 23 11:40:21 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C654A1B29A7 for ; Wed, 23 Jul 2014 11:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siH9g5gEogSM for ; Wed, 23 Jul 2014 11:40:14 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D6291A034B for ; Wed, 23 Jul 2014 11:40:13 -0700 (PDT) Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BY2PR05MB550.namprd05.prod.outlook.com (10.141.220.151) with Microsoft SMTP Server (TLS) id 15.0.990.7; Wed, 23 Jul 2014 18:40:11 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.129]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.149]) with mapi id 15.00.0990.007; Wed, 23 Jul 2014 18:40:10 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Ladislav Lhotka , Kireeti Kompella , "netmod@ietf.org" Thread-Topic: About "Route ID" as key for route entries in RIBs Thread-Index: Ac+mpRSqQ5bfK7aSQnCY7CX4/0ka1A== Date: Wed, 23 Jul 2014 18:40:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028166BF91 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(31966008)(64706001)(92566001)(106356001)(85852003)(66066001)(558084003)(74502001)(20776003)(86362001)(80022001)(76482001)(2656002)(81342001)(99286002)(21056001)(87936001)(105586002)(74316001)(46102001)(83322001)(81542001)(77096002)(99396002)(4396001)(79102001)(50986999)(83072002)(229853001)(77982001)(107046002)(1941001)(76576001)(101416001)(85306003)(54356999)(33646002)(95666004)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB550; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/aP8TkOjMvn-hG7m_VbEbjOUKXDM Cc: Jeff Haas Subject: [netmod] About "Route ID" as key for route entries in RIBs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 18:40:18 -0000 Lada, For the issue of whether we should have a "Route ID" as the key, Kireeti an= d I chatted more about the use case he had in mind. We agreed that the netm= od-routing-cfg spec does not need to accommodate that use case, and the dat= a model does not need an ID as key for routes. Thanks. Jeffrey From nobody Wed Jul 23 11:59:06 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6898D1A01F4 for ; Wed, 23 Jul 2014 11:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gX8W_j8Z3GoO for ; Wed, 23 Jul 2014 11:59:01 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4A08F1A0162 for ; Wed, 23 Jul 2014 11:59:01 -0700 (PDT) Received: from localhost (dhcp-97f7.meeting.ietf.org [31.133.151.247]) by mail.tail-f.com (Postfix) with ESMTPSA id 103D8128096A; Wed, 23 Jul 2014 20:54:21 +0200 (CEST) Date: Wed, 23 Jul 2014 14:58:58 -0400 (EDT) Message-Id: <20140723.145858.173037388.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140723183958.GB41350@elstar.local> References: <971D4B790EC8B846BE223DD23AF72FF11EB7AE39@ESESSMB103.ericsson.se> <20140723183958.GB41350@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/drzBiNh8k92oIx9j8fidXDN-Vas Cc: netmod@ietf.org Subject: Re: [netmod] Issue Y36: associate a notification with a data node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 18:59:05 -0000 Juergen Schoenwaelder wrote: > On Wed, Jul 23, 2014 at 06:09:07PM +0000, Bal=E1zs Lengyel wrote: > = > > 1) Access control: If RPCs and Notifications are associated to data= > > nodes, it is enough to configure access control for the data > > node. Today, the operator needs to configure access control for the= > > data nodes and after that separately for each RPC/notification > > again. Also understanding which action/rpc is carrying what data, t= hus > > how sensitive it is, which group should have access to it is not > > trivial. The operator has to read and understand all > > rpcs/notifications one by one. If the rpc/notification is generic (= can > > relate to different parts of the data model), it cannot be access > > controlled properly at all. The amount of work needed by the operat= or > > for configuring access control is critical, if they have more work > > they have more room for mistakes, less likely to get it done proper= ly. > > = > = > While I see your point, perhaps we need to study at how NACM today > works. Figure 2 in RFC 6536 seems to indicate that RPC access control= > actually goes through write data node access control (but it seems to= > bypass read data node access control, which surprises me). You have, > however, a point for RPCs that affect an underlying resource but not > any of the data nodes directly. But then I am not sure NACM would > without any changes actually apply the data node access control to an= > execute permission of an RPC associated with a data node. > = > I guess I need Andy or Martin to help me understand whether > associating RPC and Notifications with data nodes actually gives you > what you are looking for or whether this also needs > changes/clarifications to RFC 6536. In NACM, you can have a rule that looks like this: xx /system/authentication/user[name=3D$USER] exec accept (this would give a user access to any inline operations available for a user, maybe 'generate-ssh-keys') So while the NACM procedure defined in RFC 6536 doesn't spell out how to handle inline operations (not surpringsly...) the data model supports them. I support Balazs in this; I think especially inline operations (a.k.a. actions) have proven to be very useful. We support them in our software, and a majority of our customers use them. /martin From nobody Wed Jul 23 12:07:34 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56DC1B27BC for ; Wed, 23 Jul 2014 12:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUitgsutAbGQ for ; Wed, 23 Jul 2014 12:07:31 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7CCA1A0296 for ; Wed, 23 Jul 2014 12:07:30 -0700 (PDT) X-AuditID: c1b4fb30-f79da6d000006b80-d2-53d007f039d9 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 55.26.27520.0F700D35; Wed, 23 Jul 2014 21:07:28 +0200 (CEST) Received: from ESESSMB103.ericsson.se ([169.254.3.143]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0174.001; Wed, 23 Jul 2014 21:07:28 +0200 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: Juergen Schoenwaelder Thread-Topic: [netmod] Issue Y36: associate a notification with a data node Thread-Index: Ac+mg6mM7xFT6+1YQna90h/wt1aQxAAHUm1A///nlAD//94WcA== Date: Wed, 23 Jul 2014 19:07:28 +0000 Message-ID: <971D4B790EC8B846BE223DD23AF72FF11EB7AE76@ESESSMB103.ericsson.se> References: <971D4B790EC8B846BE223DD23AF72FF11EB7AE39@ESESSMB103.ericsson.se> <20140723183958.GB41350@elstar.local> In-Reply-To: <20140723183958.GB41350@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvje4H9gvBBq/eWlhc3fiT0WL+xUZW ByaPJUt+MnlsOOAZwBTFZZOSmpNZllqkb5fAlbFnxS7WggVCFQufT2ZpYDzP18XIySEhYCJx /WwXE4QtJnHh3nq2LkYuDiGBo4wSDTfb2SGcJYwSrfvvsINUsQm4Shz79J0FxBYRcJDo39bN BmIzC6hL3Dn1GMwWFvCSeLHhNTtEjbfEm6PzgeIcQLaTxLyPuSBhFgFViRlTTrCDhHkFfCXa 9tiDhIUESiXWL5vBCGJzChhJ/GqfDraJEei276fWMEFsEpe49WQ+1M0CEkv2nGeGsEUlXj7+ xwphK0ksuv0Zql5P4sbUKVBXakssW/garJ5XQFDi5MwnLBMYxWYhGTsLScssJC2zkLQsYGRZ xShanFqclJtuZKSXWpSZXFycn6eXl1qyiREYOwe3/DbYwfjyueMhRgEORiUe3of7zwcLsSaW FVfmHmKU5mBREuddeG5esJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGBsv92vGRKnusTrLO ZdectP2uTx8Lx03FxapZwqeEpn3fmlumEr717rHQcqVZOw72KVpLHotJ/HZQ68AMhZvRwh3u S/eHSradqPm3dG5GxpqzRnb+XTEzZxkZHn6V6vdOmr2+/SXLGt2FJ1ieCYQz5e1vT19d/m6C 5CxWUdF3G+89/xd1bu8vJZbijERDLeai4kQAmQvXCH4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Ht87HcUILiMZtYQH6MjI5stsxNk Cc: "netmod@ietf.org" Subject: Re: [netmod] Issue Y36: associate a notification with a data node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 19:07:32 -0000 Hello Juergen, I am looking for multiple things, access control being one of them., but IM= HO the others are also very important. Regards Balazs -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Wednesday, 23 July, 2014 14:40 To: Bal=E1zs Lengyel Cc: netmod@ietf.org Subject: Re: [netmod] Issue Y36: associate a notification with a data node On Wed, Jul 23, 2014 at 06:09:07PM +0000, Bal=E1zs Lengyel wrote: =20 > 1) Access control: If RPCs and Notifications are associated to data = nodes, it is enough to configure access control for the data node. Today, t= he operator needs to configure access control for the data nodes and after = that separately for each RPC/notification again. Also understanding which a= ction/rpc is carrying what data, thus how sensitive it is, which group shou= ld have access to it is not trivial. The operator has to read and understan= d all rpcs/notifications one by one. If the rpc/notification is generic (ca= n relate to different parts of the data model), it cannot be access control= led properly at all. The amount of work needed by the operator for configur= ing access control is critical, if they have more work they have more room = for mistakes, less likely to get it done properly. >=20 While I see your point, perhaps we need to study at how NACM today works. F= igure 2 in RFC 6536 seems to indicate that RPC access control actually goes= through write data node access control (but it seems to bypass read data n= ode access control, which surprises me). You have, however, a point for RPC= s that affect an underlying resource but not any of the data nodes directly= . But then I am not sure NACM would without any changes actually apply the = data node access control to an execute permission of an RPC associated with= a data node. I guess I need Andy or Martin to help me understand whether associating RPC= and Notifications with data nodes actually gives you what you are looking = for or whether this also needs changes/clarifications to RFC 6536. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jul 23 12:16:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114B11A0AA9 for ; Wed, 23 Jul 2014 12:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhCL1xLW6LJo for ; Wed, 23 Jul 2014 12:16:24 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F02791A0336 for ; Wed, 23 Jul 2014 12:16:23 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BA86EF76; Wed, 23 Jul 2014 21:16:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id usC4ADVfFgdx; Wed, 23 Jul 2014 21:16:09 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 23 Jul 2014 21:16:22 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 06CF12002C; Wed, 23 Jul 2014 21:16:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SxbILyI0f-nE; Wed, 23 Jul 2014 21:16:21 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0D2920017; Wed, 23 Jul 2014 21:16:20 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D09A12DF7A50; Wed, 23 Jul 2014 21:16:19 +0200 (CEST) Date: Wed, 23 Jul 2014 21:16:19 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140723191618.GA41509@elstar.local> Mail-Followup-To: Martin Bjorklund , balazs.lengyel@ericsson.com, netmod@ietf.org References: <971D4B790EC8B846BE223DD23AF72FF11EB7AE39@ESESSMB103.ericsson.se> <20140723183958.GB41350@elstar.local> <20140723.145858.173037388.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140723.145858.173037388.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/V_Ojrsn87jKqAFyygKW3EKlHZDA Cc: netmod@ietf.org Subject: Re: [netmod] Issue Y36: associate a notification with a data node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jul 2014 19:16:25 -0000 On Wed, Jul 23, 2014 at 02:58:58PM -0400, Martin Bjorklund wrote: > > In NACM, you can have a rule that looks like this: > > > xx > /system/authentication/user[name=$USER] > exec > accept > > > (this would give a user access to any inline operations available for > a user, maybe 'generate-ssh-keys') > > So while the NACM procedure defined in RFC 6536 doesn't spell out how > to handle inline operations (not surpringsly...) the data model > supports them. > > I support Balazs in this; I think especially inline operations > (a.k.a. actions) have proven to be very useful. We support them in > our software, and a majority of our customers use them. > Lets see what has happened. We discussed Y36 on 2014-06-04. Below is the excerpt from the minutes. A call was made on the mailing list on Fri, 27 Jun 2014 and nobody objected against the proposal to move this to DEAD. Why do we reconsider this now? What makes this a YANG 1.1 issue now? /js * Y36 associate a notification with a data node MB says that he did not have customers asking for this but Tail-f has something similar called actions (inlined rpcs). If we do this, it makes sense to add inline RPCs as well. AZ sees a use case. PO sees value in notification source properties attached to leafs. PO says that this is essentially about associating a notification with a resource object. MB says this is a nice to have feature because you can do without. Sounds more like a YANG 2.0 issue. AB agrees that this is an optimization, perhaps this can also be dealt with by certain design patterns. JS suggests that one could also think about guidelines on how to structure notifications to make resource identification easier. Proposal: Reject this issue. May be considered for YANG 2.0. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jul 23 12:17:11 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63CE11A0336 for ; Wed, 23 Jul 2014 12:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8W-qA7YgtWaP for ; Wed, 23 Jul 2014 12:17:08 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FD601A01E8 for ; Wed, 23 Jul 2014 12:17:08 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DB7E475C; Wed, 23 Jul 2014 21:17:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id f7zggNlbDOEX; Wed, 23 Jul 2014 21:16:53 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 23 Jul 2014 21:17:06 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1E9722002F; Wed, 23 Jul 2014 21:17:06 +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 eTY0jCxRwMMt; Wed, 23 Jul 2014 21:17:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 90C332002C; Wed, 23 Jul 2014 21:17:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8A4792DF7A66; Wed, 23 Jul 2014 21:17:04 +0200 (CEST) Date: Wed, 23 Jul 2014 21:17:04 +0200 From: Juergen Schoenwaelder To: =?iso-8859-1?Q?Bal=E1zs?= Lengyel Message-ID: <20140723191704.GB41509@elstar.local> Mail-Followup-To: =?iso-8859-1?Q?Bal=E1zs?= Lengyel , "netmod@ietf.org" References: <971D4B790EC8B846BE223DD23AF72FF11EB7AE39@ESESSMB103.ericsson.se> <20140723183958.GB41350@elstar.local> <971D4B790EC8B846BE223DD23AF72FF11EB7AE76@ESESSMB103.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <971D4B790EC8B846BE223DD23AF72FF11EB7AE76@ESESSMB103.ericsson.se> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/3VQQnkPX0UjYJBtfRzJMP33NOhQ Cc: "netmod@ietf.org" Subject: Re: [netmod] Issue Y36: associate a notification with a data node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jul 2014 19:17:09 -0000 I do understand that. /js On Wed, Jul 23, 2014 at 07:07:28PM +0000, Balázs Lengyel wrote: > Hello Juergen, > I am looking for multiple things, access control being one of them., but IMHO the others are also very important. > > Regards Balazs > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, 23 July, 2014 14:40 > To: Balázs Lengyel > Cc: netmod@ietf.org > Subject: Re: [netmod] Issue Y36: associate a notification with a data node > > On Wed, Jul 23, 2014 at 06:09:07PM +0000, Balázs Lengyel wrote: > > > 1) Access control: If RPCs and Notifications are associated to data nodes, it is enough to configure access control for the data node. Today, the operator needs to configure access control for the data nodes and after that separately for each RPC/notification again. Also understanding which action/rpc is carrying what data, thus how sensitive it is, which group should have access to it is not trivial. The operator has to read and understand all rpcs/notifications one by one. If the rpc/notification is generic (can relate to different parts of the data model), it cannot be access controlled properly at all. The amount of work needed by the operator for configuring access control is critical, if they have more work they have more room for mistakes, less likely to get it done properly. > > > > While I see your point, perhaps we need to study at how NACM today works. Figure 2 in RFC 6536 seems to indicate that RPC access control actually goes through write data node access control (but it seems to bypass read data node access control, which surprises me). You have, however, a point for RPCs that affect an underlying resource but not any of the data nodes directly. But then I am not sure NACM would without any changes actually apply the data node access control to an execute permission of an RPC associated with a data node. > > I guess I need Andy or Martin to help me understand whether associating RPC and Notifications with data nodes actually gives you what you are looking for or whether this also needs changes/clarifications to RFC 6536. > > /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 nobody Wed Jul 23 12:24:07 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41721B2B50 for ; Wed, 23 Jul 2014 12:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0i8N5gMAIwnS for ; Wed, 23 Jul 2014 12:24:03 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8ABC1B2AC9 for ; Wed, 23 Jul 2014 12:24:03 -0700 (PDT) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:1990:9c89:b7b9:dbe4]) by mail.nic.cz (Postfix) with ESMTPSA id BB86E13F997; Wed, 23 Jul 2014 21:24:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1406143442; bh=xWpBmZi3LO7DCi0lVjElKIc+J7MJBJSDgW/bF8mGMms=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hN1s0gIM0QqmZ2JcDO96+Yq6Nb66LXAT4MwFy9RRwQ9Gkp3Qocuc1I1jYU4tTgwWx 7Tq3IoDTOjcfFugLCQk1genkuuWEc3hO0CNcMihPYfFPkFgsFjGNtkbuYTSpGWA48J +GCQJ+QeKbq78q3efTqlyShiDZIgXVZwA7vavSIk= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 23 Jul 2014 15:23:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9FB65338-5428-45E6-8571-B7312827068B@nic.cz> References: To: "Jeffrey (Zhaohui) Zhang" X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/dSc1PH7ROjd1sUGkLNAQNkjYqAY Cc: Kireeti Kompella , Jeff Haas , "netmod@ietf.org" Subject: Re: [netmod] About "Route ID" as key for route entries in RIBs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 19:24:04 -0000 On 23 Jul 2014, at 14:40, Jeffrey (Zhaohui) Zhang = wrote: > Lada, >=20 > For the issue of whether we should have a "Route ID" as the key, = Kireeti and I chatted more about the use case he had in mind. We agreed = that the netmod-routing-cfg spec does not need to accommodate that use = case, and the data model does not need an ID as key for routes. OK, good, so let=92s remove it. Lada >=20 > Thanks. > Jeffrey -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 23 12:33:11 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B0F1B2C52 for ; Wed, 23 Jul 2014 12:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SK5D0OLHiWHT for ; Wed, 23 Jul 2014 12:33:08 -0700 (PDT) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07B221A033A for ; Wed, 23 Jul 2014 12:33:07 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id q108so2014902qgd.23 for ; Wed, 23 Jul 2014 12:33:07 -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=DIVKevDoOFH7COnescxC//OJqpLEX7mopLlYgynziGk=; b=lJxbMxu0LCauK9VISU284oBXOke0YyPEgHtu/zOpkdWetzbPDkRav5ZtCqN1RwFF0u lsRQ8bJUyz7lzxGIBA0mx6PiNcQUt6FaIL/+SwJ1VT4AqVgl/vcjjUW4QCtGCQf83RdE QcfjtmbsZgdXNOx7xYzmW+Znt0dOLZ+eyWHX/i+rCwRiTGN0OTkJsrAAoDPEymlr7Xqc vrCJ6b2L/t8zWE+vwlK2BPtF3aESHHIh7xzzLnC22JJEn0EtfnziNyhMxyzGtDzlJN/b 5LvjDrWjquFiu8a8sM+6/7+P1A7bhodE0mG9CYnrZA57wCHZ9XvPt/yRB1xVQZjQygPX syCQ== X-Gm-Message-State: ALoCoQkWG4Fe0J4ZqLGGv8JaZF64Rn4eRRdge2QBUywi+HSWxH3p5e7ZNsfwOjtBVLboIhfg5rtv MIME-Version: 1.0 X-Received: by 10.224.20.200 with SMTP id g8mr5768838qab.88.1406143987218; Wed, 23 Jul 2014 12:33:07 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Wed, 23 Jul 2014 12:33:07 -0700 (PDT) In-Reply-To: <20140723.145858.173037388.mbj@tail-f.com> References: <971D4B790EC8B846BE223DD23AF72FF11EB7AE39@ESESSMB103.ericsson.se> <20140723183958.GB41350@elstar.local> <20140723.145858.173037388.mbj@tail-f.com> Date: Wed, 23 Jul 2014 12:33:07 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c2a3b0dc954a04fee16895 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/sfwUwmnJvyxxyUcP_ybP0wtUK-0 Cc: "netmod@ietf.org" Subject: Re: [netmod] Issue Y36: associate a notification with a data node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 19:33:10 -0000 --001a11c2a3b0dc954a04fee16895 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I think the NACM issues could be considered technical reasons to add this new feature. The important aspect to me is how intuitive the YANG constructs are to users. I like the idea of class-specific actions and events. We don't have classes though, so I need to see more details about how the nested actions and notification events are mapped to NETCONF and RESTCONF. How do these actions get invoked? How do actions and notifications identify the object node and instance? What happens if I have a top-level rpc called plus a lot of node-specific actions called ? How do they relate to each other (in the model and in operation)? Since we don't have classes, but we have groupings, then how can these actions and events be used and refined from a grouping? I think it would be worthwhile to see a solution proposal in writing before ruling this out of YANG 1.1. Andy On Wed, Jul 23, 2014 at 11:58 AM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Wed, Jul 23, 2014 at 06:09:07PM +0000, Bal=E1zs Lengyel wrote: > > > > > 1) Access control: If RPCs and Notifications are associated to data > > > nodes, it is enough to configure access control for the data > > > node. Today, the operator needs to configure access control for the > > > data nodes and after that separately for each RPC/notification > > > again. Also understanding which action/rpc is carrying what data, thu= s > > > how sensitive it is, which group should have access to it is not > > > trivial. The operator has to read and understand all > > > rpcs/notifications one by one. If the rpc/notification is generic (ca= n > > > relate to different parts of the data model), it cannot be access > > > controlled properly at all. The amount of work needed by the operator > > > for configuring access control is critical, if they have more work > > > they have more room for mistakes, less likely to get it done properly= . > > > > > > > While I see your point, perhaps we need to study at how NACM today > > works. Figure 2 in RFC 6536 seems to indicate that RPC access control > > actually goes through write data node access control (but it seems to > > bypass read data node access control, which surprises me). You have, > > however, a point for RPCs that affect an underlying resource but not > > any of the data nodes directly. But then I am not sure NACM would > > without any changes actually apply the data node access control to an > > execute permission of an RPC associated with a data node. > > > > I guess I need Andy or Martin to help me understand whether > > associating RPC and Notifications with data nodes actually gives you > > what you are looking for or whether this also needs > > changes/clarifications to RFC 6536. > > In NACM, you can have a rule that looks like this: > > > xx > /system/authentication/user[name=3D$USER] > exec > accept > > > (this would give a user access to any inline operations available for > a user, maybe 'generate-ssh-keys') > > So while the NACM procedure defined in RFC 6536 doesn't spell out how > to handle inline operations (not surpringsly...) the data model > supports them. > > I support Balazs in this; I think especially inline operations > (a.k.a. actions) have proven to be very useful. We support them in > our software, and a majority of our customers use them. > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c2a3b0dc954a04fee16895 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I think the NACM issues could be co= nsidered technical reasons to add this new feature.
The important= aspect to me is how intuitive the YANG constructs are to users.

I like the idea of class-specific actions and events.
<= div>We don't have classes though, so I need to see more details
about how the nested actions and notification events are mapped
to NETCONF and RESTCONF. =A0How do these actions get invoked?
How do actions and notifications identify the object node and instance?
What happens if I have a top-level rpc called <reset> plus a= lot of
node-specific actions called <reset>? How do they relate to each= other
(in the model and in operation)?

= Since we don't have classes, but we have groupings, then how can these<= /div>
actions and events be used and refined from a grouping?=A0
<= br>
I think it would be worthwhile to see a solution proposal in = writing before
ruling this out of YANG 1.1.


Andy


On Wed, Jul 23, 2014 at 11:58 A= M, Martin Bjorklund <mbj@tail-f.com> wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<= /a>> wrote:
> On Wed, Jul 23, 2014 at 06:09:07PM +0000, Bal=E1zs Lengyel wrote:
>
> > 1) Access control: If RPCs and Notifications are associated to da= ta
> > nodes, it is enough to configure access control for the data
> > node. Today, the operator needs to configure access control for t= he
> > data nodes and after that separately for each RPC/notification > > again. Also understanding which action/rpc is carrying what data,= thus
> > how sensitive it is, which group should have access to it is not<= br> > > trivial. The operator has to read and understand all
> > rpcs/notifications one by one. If the rpc/notification is generic= (can
> > relate to different parts of the data model), it cannot be access=
> > controlled properly at all. The amount of work needed by the oper= ator
> > for configuring access control is critical, if they have more wor= k
> > they have more room for mistakes, less likely to get it done prop= erly.
> >
>
> While I see your point, perhaps we need to study at how NACM today
> works. Figure 2 in RFC 6536 seems to indicate that RPC access control<= br> > actually goes through write data node access control (but it seems to<= br> > bypass read data node access control, which surprises me). You have, > however, a point for RPCs that affect an underlying resource but not > any of the data nodes directly. But then I am not sure NACM would
> without any changes actually apply the data node access control to an<= br> > execute permission of an RPC associated with a data node.
>
> I guess I need Andy or Martin to help me understand whether
> associating RPC and Notifications with data nodes actually gives you > what you are looking for or whether this also needs
> changes/clarifications to RFC 6536.

In NACM, you can have a rule that looks like this:

=A0 <rule>
=A0 =A0 <name>xx</name>
=A0 =A0 <path>/system/authentication/user[name=3D$USER]</path><= br> =A0 =A0 <access-operations>exec</access-operations>
=A0 =A0 <action>accept</accept>
=A0 </rule>

(this would give a user access to any inline operations available for
a user, maybe 'generate-ssh-keys')

So while the NACM procedure defined in RFC 6536 doesn't spell out how to handle inline operations (not surpringsly...) the data model
supports them.

I support Balazs in this; I think especially inline operations
(a.k.a. actions) have proven to be very useful. =A0We support them in
our software, and a majority of our customers use them.


/martin

_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--001a11c2a3b0dc954a04fee16895-- From nobody Wed Jul 23 13:40:20 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6299F1B2A1E for ; Wed, 23 Jul 2014 13:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kClXv3Eh0tj3 for ; Wed, 23 Jul 2014 13:40:17 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59F11B29EB for ; Wed, 23 Jul 2014 13:40:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5339; q=dns/txt; s=iport; t=1406148014; x=1407357614; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ZHBka4ESyLmuC6J9XPH2vLA6g7Zd4Kq3bc2MahFDIqw=; b=OnkifmgHZnTzgxrJKYx19t3BzzOLaYcBsqCAwdAiQ3DJKrE814qYZqPT pqmtUg1GWgfewMIi5L3nT8RSjz7PVdlHeIVeo6yNqi0RV/UMcfHhYnmuR YxO8PhKF8Pdy+D+YhmXJgwYnWTHEBGOukH9LSPVy6Yjdi/0NXfVRxIqtN 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiILAEUc0FOtJV2c/2dsb2JhbABQBgOCaiRSVwEDx2mHQwGBCxZ2hAQBAQR5DgICAQgOAgguGxclAgQOBQkRiCgBDMAaFwSObAoBARwjEAcRhDUFjkWMaIFSkm6DSGwBgQs5 X-IronPort-AV: E=Sophos;i="5.01,719,1400025600"; d="scan'208";a="342309174" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 23 Jul 2014 20:40:13 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s6NKeCdw029803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 20:40:12 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Wed, 23 Jul 2014 15:40:12 -0500 From: "Clyde Wildes (cwildes)" To: Juergen Schoenwaelder Thread-Topic: [netmod] Syslog YANG Model Presentation Thread-Index: AQHPpSkC2ZiRgh9DtUicY+pcm0HXCJushl6AgAGsuQA= Date: Wed, 23 Jul 2014 20:40:11 +0000 Message-ID: References: <20140722150553.GB12083@elstar.local> In-Reply-To: <20140722150553.GB12083@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.97.159] Content-Type: text/plain; charset="Windows-1252" Content-ID: <43CC924219F26D47A235D4FE54EE94EE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/X_eMtKLsOoTrr50c3pk40bhE6-U Cc: Kiran Agrahara Sreenivasa , "netmod@ietf.org" Subject: Re: [netmod] Syslog YANG Model Presentation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 20:40:19 -0000 Juergen, Thanks for your review. My answers are inline as [clyde]... On 7/22/14, 11:05 AM, "Juergen Schoenwaelder" wrote: >On Mon, Jul 21, 2014 at 09:16:16PM +0000, Clyde Wildes (cwildes) wrote: >>=20 >> The latest draft of the proposed Syslog YANG Model RFC is at: >>=20 >>http://www.ietf.org/internet-drafts/draft-wildes-netmod-syslog-model-02.t >>xt >>=20 > >The traditional Unix syslog daemons usually understand configuration >rules like this: > >*.=3Dinfo;*.=3Dnotice;*.=3Dwarn;\ > auth,authpriv.none;\ > cron,daemon.none;\ > mail,news.none -/var/log/messages > >That is, you have rules with multiple selectors that lead to a certain >action. Note also the various wildcards above. You seem to model this >backwards, that is the action first followed by the selectors - why? >I think using the terminology of 'selectors' and 'actions' is quite >common in Unix syslog land - perhaps this should be adopted instead of >'Message Distributors' and related terms. It seems some syslog >implementations (e.g. rsyslog) have a more general concept of a filter >and selectors (matching facility/severity) and just one of several >ways to filter. > >/js [clyde] We examined five vendor OSs=B9 syslog configuration when we developed this draft (Brocade, Cisco IOS/XR Cisco IOS/XR, Cisco NXOS, and Juniper JunOS). We did not consider Unix syslog configuration. In hindsight we should have and will support it in a future version. Some vendors support multiple selectors for a specific action and that is included in this draft. Treating actions as high level leaves in the model makes it easier to augment an action IMHO. Items missing from this draft that are Unix like are: 1. the mark facility - the current model does not support the =B3mark" facility which is a Linux method where messages generated by syslogd itself that contain only a timestamp and the string =B3=8BMARK-" are select= ed when the =B3mark" facility is specified. If needed this could be added by augmenting the syslog-facility identity in ietf-syslog-types.yang. 2. priority support - the current model does not support: - the * specification for all priorities (although specifying =B3debug" means the same thing since specification for priority mean any message with priority less than or equal to the specified priority is passed and debug is the highest number of 7), - the =3D specification for a specific priority, or !=3D for any priorit= y but the specified priority. 3. evaluation of multiple selectors - although we allow multiple facility/priority selectors for an action we do not follow the linux rule that says that when an action contains multiple selectors, they are evaluated from left to right (first to last); The UNIX pattern is that you list general selectors first, followed by more specific selectors because once a selector pattern is met, no further selectors are processed for that action. > >PS: I think you should also refer to the standards-track version of > SYSLOG (RFC 5424) in the references and perhaps filters should > also be able to operate on structured content. [clyde] I agree that RFC 5424 should be referenced and will include this in a future revision. Only one vendor has implemented delivery of structured syslog messages and so we left this for augmentation. We also left message filtering by message text pattern matching for augmentation. > >PS: I do not really understand 'global logging'. [clyde] Some vendors include an extra log message suppression mechanism that is logically before the selectors/actions mechanism. We called this mechanism =B3global-logging=B2. It is listed as a feature for those vendors that support it and it is described in the RFC document. > >PS: A configuration model should probably also include ways to > configure on which endpoints the syslog 'daemon' is receiving > input. [clyde] This model does not include syslogd daemon listener configuration (the daemon listens for syslog messages on port 514 on all interfaces if the =B3-r=B2 switch is included on the syslogd command line). I am thinking that syslog daemon configuration should be a separate model since this model is concerned with syslog message distribution. For reference here is the FreeBSD syslogd man page which shows the many syslogd daemon options: http://www.freebsd.org/cgi/man.cgi?query=3Dsyslogd&sektion=3D8 > >PS: The reference in the revision statement is usually used to refer > to the document defining that specific revision of the data model. > >PS: For the example, simple show the config instance not the NETCONF > exchange. [clyde] Please explain. Should the reference for revision 02 be to: http://tools.ietf.org/html/draft-wildes-netmod-syslog-model-02 The current revision 03 contents are: revision 2014-06-10 { description "Initial revision."; reference "This model references RFC 5424 - The Syslog Protocol."; } Thanks, Clyde > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 From nobody Wed Jul 23 15:03:41 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E211B27BD for ; Wed, 23 Jul 2014 15:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSy_IIuygjqq for ; Wed, 23 Jul 2014 15:03:38 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82F71B2911 for ; Wed, 23 Jul 2014 15:03:37 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 54F68715; Thu, 24 Jul 2014 00:03:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id oU8Z7vWkXTEY; Thu, 24 Jul 2014 00:03:21 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 24 Jul 2014 00:03:35 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 780192002C; Thu, 24 Jul 2014 00:03:35 +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 rPX5LOkoHE6e; Thu, 24 Jul 2014 00:03:34 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AFD3020017; Thu, 24 Jul 2014 00:03:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5867F2DF7D34; Thu, 24 Jul 2014 00:03:33 +0200 (CEST) Date: Thu, 24 Jul 2014 00:03:33 +0200 From: Juergen Schoenwaelder To: "Clyde Wildes (cwildes)" Message-ID: <20140723220333.GC41955@elstar.local> Mail-Followup-To: "Clyde Wildes (cwildes)" , "netmod@ietf.org" , Kiran Agrahara Sreenivasa References: <20140722150553.GB12083@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LEdVsTwoPcXWBkmFixSEO0vUwyw Cc: Kiran Agrahara Sreenivasa , "netmod@ietf.org" Subject: Re: [netmod] Syslog YANG Model Presentation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jul 2014 22:03:40 -0000 On Wed, Jul 23, 2014 at 08:40:11PM +0000, Clyde Wildes (cwildes) wrote: > > > >PS: I do not really understand 'global logging'. > > [clyde] Some vendors include an extra log message suppression mechanism > that is logically before the selectors/actions mechanism. We called this > mechanism ³global-logging². It is listed as a feature for those vendors > that support it and it is described in the RFC document. If this is a global filter, it should probably have a name that makes this clearer. But then, the I-D also says: feature global-logging { description "This feature represents the ability to adjust log message severity per logging facility on the global level."; } This says 'adjust severity' which is again different from suppression or filtering. The data model uses the facility-logging grouping, which then again reads as a filter. In other words, it seems like messages not passing 'global-logging' will be dropped. If this is the intention, please make sure this is clearly described. > >PS: A configuration model should probably also include ways to > > configure on which endpoints the syslog 'daemon' is receiving > > input. > > [clyde] This model does not include syslogd daemon listener configuration > (the daemon listens for syslog messages on port 514 on all interfaces if > the ³-r² switch is included on the syslogd command line). I am thinking > that syslog daemon configuration should be a separate model since this > model is concerned with syslog message distribution. For reference here is > the FreeBSD syslogd man page which shows the many syslogd daemon options: > http://www.freebsd.org/cgi/man.cgi?query=syslogd&sektion=8 Listener configuration could be left out or it could be made a feature; most open source syslog daemons can listen for incoming messages. > >PS: The reference in the revision statement is usually used to refer > > to the document defining that specific revision of the data model. > > > >PS: For the example, simple show the config instance not the NETCONF > > exchange. > > [clyde] Please explain. Should the reference for revision 02 be to: > http://tools.ietf.org/html/draft-wildes-netmod-syslog-model-02 > > The current revision 03 contents are: > > revision 2014-06-10 { > description > "Initial revision."; > reference > "This model references RFC 5424 - The Syslog Protocol."; > } > The idea is to refer to the document defining the YANG module, e.g.: // RFC Ed.: update the date below with the date of RFC publication // and remove this note. revision 2014-06-10 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for SYSLOG"; } This way, someone who has the YANG module can easily find the RFC defining it. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jul 23 15:38:09 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE901B2936 for ; Wed, 23 Jul 2014 15:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwFSsnICFtpx for ; Wed, 23 Jul 2014 15:38:07 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44A041B28CE for ; Wed, 23 Jul 2014 15:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4866; q=dns/txt; s=iport; t=1406155087; x=1407364687; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4HSUcBuNXW6gSfX6ViJXRAWBryJQJJ8HouqrJint0FU=; b=h8y6CfUtezKk9gxpdRiTic8Cam+x5q5h9WgP9HM1WbHH0+sBIanQ3K2j DgZYuYFHG0qE3AVvaRY4qy/RZ++phBTN50apHWQF+oXZ0YbLa7UYMYZN/ 77yVdpfT1ddk9aDGTVCH+PAzNjh1fz/cmeyLy4NA3q9hIbjsyqyPQ9x4Y w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUIAGQ40FOtJA2D/2dsb2JhbABWA4JqJFJXAQOCdMY7h0UBGXIWdoQEAQEENEUOAgIBCA4CCAQoAgIZFyUCBA4FCYg5AQyMQZwhBpdiFwSBIo1yGAsQBxGCYYFUBZstgVKSboNIbAGBRA X-IronPort-AV: E=Sophos;i="5.01,720,1400025600"; d="scan'208";a="63487921" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-3.cisco.com with ESMTP; 23 Jul 2014 22:38:06 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6NMc536025284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 22:38:05 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Wed, 23 Jul 2014 17:38:05 -0500 From: "Clyde Wildes (cwildes)" To: Juergen Schoenwaelder Thread-Topic: [netmod] Syslog YANG Model Presentation Thread-Index: AQHPpSkC2ZiRgh9DtUicY+pcm0HXCJushl6AgAGsuQCAAFpLgP//xqeA Date: Wed, 23 Jul 2014 22:38:05 +0000 Message-ID: References: <20140722150553.GB12083@elstar.local> <20140723220333.GC41955@elstar.local> In-Reply-To: <20140723220333.GC41955@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.97.159] Content-Type: text/plain; charset="euc-kr" Content-ID: <462259C3D1B5DF4BA36BB084C268213B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/mYWUwI4u5VGm_ZivNL0M07ZGPQY Cc: Kiran Agrahara Sreenivasa , "netmod@ietf.org" Subject: Re: [netmod] Syslog YANG Model Presentation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 22:38:08 -0000 SnVlcmdlbiwNCg0KV2Ugd2lsbCB1cGRhdGUgdGhlIGRlc2NyaXB0aW9uIGZvciBnbG9iYWwtbG9n Z2luZyB0byBiZSBjbGVhci4NCg0KV2Ugd2lsbCBjb25zaWRlciBhZGRpbmcgc3lzbG9nIGxpc3Rl bmVyIGNvbmZpZ3VyYXRpb24gYXMgYSBmZWF0dXJlLg0KDQpXZSB3aWxsIHVwZGF0ZSB0aGUgcmVm ZXJlbmNlIHNlY3Rpb24gaW4gdGhlIG1vZGVsIGFzIHlvdSBkZXNjcmliZWQuDQoNClRoYW5rcywN Cg0KQ2x5ZGUNCg0KDQpPbiA3LzIzLzE0LCA2OjAzIFBNLCAiSnVlcmdlbiBTY2hvZW53YWVsZGVy Ig0KPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQoNCj5PbiBX ZWQsIEp1bCAyMywgMjAxNCBhdCAwODo0MDoxMVBNICswMDAwLCBDbHlkZSBXaWxkZXMgKGN3aWxk ZXMpIHdyb3RlOg0KPj4gPg0KPj4gPlBTOiBJIGRvIG5vdCByZWFsbHkgdW5kZXJzdGFuZCAnZ2xv YmFsIGxvZ2dpbmcnLg0KPj4gDQo+PiBbY2x5ZGVdIFNvbWUgdmVuZG9ycyBpbmNsdWRlIGFuIGV4 dHJhIGxvZyBtZXNzYWdlIHN1cHByZXNzaW9uIG1lY2hhbmlzbQ0KPj4gdGhhdCBpcyBsb2dpY2Fs bHkgYmVmb3JlIHRoZSBzZWxlY3RvcnMvYWN0aW9ucyBtZWNoYW5pc20uIFdlIGNhbGxlZCB0aGlz DQo+PiBtZWNoYW5pc20gqfhnbG9iYWwtbG9nZ2luZ6n3LiBJdCBpcyBsaXN0ZWQgYXMgYSBmZWF0 dXJlIGZvciB0aG9zZSB2ZW5kb3JzDQo+PiB0aGF0IHN1cHBvcnQgaXQgYW5kIGl0IGlzIGRlc2Ny aWJlZCBpbiB0aGUgUkZDIGRvY3VtZW50Lg0KPg0KPklmIHRoaXMgaXMgYSBnbG9iYWwgZmlsdGVy LCBpdCBzaG91bGQgcHJvYmFibHkgaGF2ZSBhIG5hbWUgdGhhdCBtYWtlcw0KPnRoaXMgY2xlYXJl ci4gQnV0IHRoZW4sIHRoZSBJLUQgYWxzbyBzYXlzOg0KPg0KPiAgZmVhdHVyZSBnbG9iYWwtbG9n Z2luZyB7DQo+ICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgIlRoaXMgZmVhdHVyZSByZXByZXNlbnRz IHRoZSBhYmlsaXR5IHRvIGFkanVzdA0KPiAgICAgICBsb2cgbWVzc2FnZSBzZXZlcml0eSBwZXIg bG9nZ2luZyBmYWNpbGl0eSBvbiB0aGUNCj4gICAgICAgZ2xvYmFsIGxldmVsLiI7DQo+ICB9DQo+ DQo+VGhpcyBzYXlzICdhZGp1c3Qgc2V2ZXJpdHknIHdoaWNoIGlzIGFnYWluIGRpZmZlcmVudCBm cm9tIHN1cHByZXNzaW9uDQo+b3IgZmlsdGVyaW5nLiBUaGUgZGF0YSBtb2RlbCB1c2VzIHRoZSBm YWNpbGl0eS1sb2dnaW5nIGdyb3VwaW5nLCB3aGljaA0KPnRoZW4gYWdhaW4gcmVhZHMgYXMgYSBm aWx0ZXIuIEluIG90aGVyIHdvcmRzLCBpdCBzZWVtcyBsaWtlIG1lc3NhZ2VzDQo+bm90IHBhc3Np bmcgJ2dsb2JhbC1sb2dnaW5nJyB3aWxsIGJlIGRyb3BwZWQuIElmIHRoaXMgaXMgdGhlDQo+aW50 ZW50aW9uLCBwbGVhc2UgbWFrZSBzdXJlIHRoaXMgaXMgY2xlYXJseSBkZXNjcmliZWQuDQo+DQo+ PiA+UFM6IEEgY29uZmlndXJhdGlvbiBtb2RlbCBzaG91bGQgcHJvYmFibHkgYWxzbyBpbmNsdWRl IHdheXMgdG8NCj4+ID4gICAgY29uZmlndXJlIG9uIHdoaWNoIGVuZHBvaW50cyB0aGUgc3lzbG9n ICdkYWVtb24nIGlzIHJlY2VpdmluZw0KPj4gPiAgICBpbnB1dC4NCj4+IA0KPj4gW2NseWRlXSBU aGlzIG1vZGVsIGRvZXMgbm90IGluY2x1ZGUgc3lzbG9nZCBkYWVtb24gbGlzdGVuZXINCj4+Y29u ZmlndXJhdGlvbg0KPj4gKHRoZSBkYWVtb24gbGlzdGVucyBmb3Igc3lzbG9nIG1lc3NhZ2VzIG9u IHBvcnQgNTE0IG9uIGFsbCBpbnRlcmZhY2VzIGlmDQo+PiB0aGUgqfgtcqn3IHN3aXRjaCBpcyBp bmNsdWRlZCBvbiB0aGUgc3lzbG9nZCBjb21tYW5kIGxpbmUpLiBJIGFtIHRoaW5raW5nDQo+PiB0 aGF0IHN5c2xvZyBkYWVtb24gY29uZmlndXJhdGlvbiBzaG91bGQgYmUgYSBzZXBhcmF0ZSBtb2Rl bCBzaW5jZSB0aGlzDQo+PiBtb2RlbCBpcyBjb25jZXJuZWQgd2l0aCBzeXNsb2cgbWVzc2FnZSBk aXN0cmlidXRpb24uIEZvciByZWZlcmVuY2UgaGVyZQ0KPj5pcw0KPj4gdGhlIEZyZWVCU0Qgc3lz bG9nZCBtYW4gcGFnZSB3aGljaCBzaG93cyB0aGUgbWFueSBzeXNsb2dkIGRhZW1vbg0KPj5vcHRp b25zOg0KPj4gaHR0cDovL3d3dy5mcmVlYnNkLm9yZy9jZ2kvbWFuLmNnaT9xdWVyeT1zeXNsb2dk JnNla3Rpb249OA0KPg0KPkxpc3RlbmVyIGNvbmZpZ3VyYXRpb24gY291bGQgYmUgbGVmdCBvdXQg b3IgaXQgY291bGQgYmUgbWFkZSBhDQo+ZmVhdHVyZTsgbW9zdCBvcGVuIHNvdXJjZSBzeXNsb2cg ZGFlbW9ucyBjYW4gbGlzdGVuIGZvciBpbmNvbWluZw0KPm1lc3NhZ2VzLg0KPg0KPj4gPlBTOiBU aGUgcmVmZXJlbmNlIGluIHRoZSByZXZpc2lvbiBzdGF0ZW1lbnQgaXMgdXN1YWxseSB1c2VkIHRv IHJlZmVyDQo+PiA+ICAgIHRvIHRoZSBkb2N1bWVudCBkZWZpbmluZyB0aGF0IHNwZWNpZmljIHJl dmlzaW9uIG9mIHRoZSBkYXRhIG1vZGVsLg0KPj4gPg0KPj4gPlBTOiBGb3IgdGhlIGV4YW1wbGUs IHNpbXBsZSBzaG93IHRoZSBjb25maWcgaW5zdGFuY2Ugbm90IHRoZSBORVRDT05GDQo+PiA+ICAg IGV4Y2hhbmdlLg0KPj4gDQo+PiBbY2x5ZGVdIFBsZWFzZSBleHBsYWluLiBTaG91bGQgdGhlIHJl ZmVyZW5jZSBmb3IgcmV2aXNpb24gMDIgYmUgdG86DQo+PiAgICAgICAgIGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXdpbGRlcy1uZXRtb2Qtc3lzbG9nLW1vZGVsLTAyDQo+PiANCj4+ IFRoZSBjdXJyZW50IHJldmlzaW9uIDAzIGNvbnRlbnRzIGFyZToNCj4+IA0KPj4gIHJldmlzaW9u IDIwMTQtMDYtMTAgew0KPj4gICAgZGVzY3JpcHRpb24NCj4+ICAgICAgIkluaXRpYWwgcmV2aXNp b24uIjsNCj4+ICAgIHJlZmVyZW5jZQ0KPj4gICAgICAiVGhpcyBtb2RlbCByZWZlcmVuY2VzIFJG QyA1NDI0IC0gVGhlIFN5c2xvZyBQcm90b2NvbC4iOw0KPj4gICB9DQo+PiANCj4NCj5UaGUgaWRl YSBpcyB0byByZWZlciB0byB0aGUgZG9jdW1lbnQgZGVmaW5pbmcgdGhlIFlBTkcgbW9kdWxlLCBl LmcuOg0KPg0KPiAgICAgLy8gUkZDIEVkLjogdXBkYXRlIHRoZSBkYXRlIGJlbG93IHdpdGggdGhl IGRhdGUgb2YgUkZDIHB1YmxpY2F0aW9uDQo+ICAgICAvLyBhbmQgcmVtb3ZlIHRoaXMgbm90ZS4N Cj4gICAgIHJldmlzaW9uIDIwMTQtMDYtMTAgew0KPiAgICAgICBkZXNjcmlwdGlvbg0KPiAgICAg ICAgICJJbml0aWFsIHJldmlzaW9uLiI7DQo+ICAgICAgIHJlZmVyZW5jZQ0KPiAgICAgICAgICJS RkMgWFhYWDogQSBZQU5HIERhdGEgTW9kZWwgZm9yIFNZU0xPRyI7DQo+ICAgICB9DQo+DQo+VGhp cyB3YXksIHNvbWVvbmUgd2hvIGhhcyB0aGUgWUFORyBtb2R1bGUgY2FuIGVhc2lseSBmaW5kIHRo ZSBSRkMNCj5kZWZpbmluZyBpdC4NCj4NCj4vanMNCj4NCj4tLSANCj5KdWVyZ2VuIFNjaG9lbndh ZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPlBob25lOiAr NDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSwgMjg3NTkgQnJlbWVuLCBHZXJt YW55DQo+RmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cDovL3d3dy5qYWNvYnMt dW5pdmVyc2l0eS5kZS8+DQoNCg== From nobody Thu Jul 24 06:32:51 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242041A02F4 for ; Thu, 24 Jul 2014 06:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFH9klRlUBVj for ; Thu, 24 Jul 2014 06:32:47 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A8F1A0345 for ; Thu, 24 Jul 2014 06:32:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10177; q=dns/txt; s=iport; t=1406208767; x=1407418367; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=Q5Y6SwK1kXICo3lDleNxCeO8CPvGD1+c/ey95RmrERw=; b=O5z04dmU+pFF81j2P4FxGo7ElJJSPKpOe4qhifx7dgP8OQW2Mp2fJVFE MRXlyQGUkqJO+lt0ue09XsZ0TnRQxqDkHdljYQyfHVtOR3vPe93gsCLtx +Yz+p5TPGXzFYqSLjfJouG5XavFnEE7JwB01D5jFB01Fy6jse4os7U7Gm M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAKcK0VOtJA2H/2dsb2JhbABZgkdHUlcEySkBCYZyUwGBCxZ3hAMBAQEEAQEBKkEdAQgRAwECKC4LFAkIAQEEARIJC4guDcA6F4l+gxCBZkYXAYRGBY5IjGuUQoNIbIEEQQ X-IronPort-AV: E=Sophos; i="5.01,724,1400025600"; d="scan'208,217"; a="63666420" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-5.cisco.com with ESMTP; 24 Jul 2014 13:32:46 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6ODWkT9004386 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Jul 2014 13:32:46 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Thu, 24 Jul 2014 08:32:46 -0500 From: "Lisa Huang (yihuan)" To: "Benoit Claise (bclaise)" , "Tissa Senevirathne (tsenevir)" , "netmod@ietf.org" Thread-Topic: [netmod] presentations of other drafts Thread-Index: Ac+lKfzukBqJ/cWAQUOUWtSpzXyz1gA0w7YAAFPFdAA= Date: Thu, 24 Jul 2014 13:32:44 +0000 Message-ID: In-Reply-To: <53CEA08E.80002@cisco.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.82.209.97] Content-Type: multipart/alternative; boundary="_000_CFF67E053B66Ayihuanciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ZALUdFQAHhL1Sh92InhG1-YlANY Subject: Re: [netmod] presentations of other drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 13:32:49 -0000 --_000_CFF67E053B66Ayihuanciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The Sunday session helped. It would be nice that the WG agenda could indica= te open mic time as well. When the open mic time limit reached, If there a= re still more people interested in that draft, names could be recorded to f= orm a small group discussion afterwards. From: "Benoit Claise (bclaise)" > Date: Tuesday, July 22, 2014 10:34 AM To: "Tissa Senevirathne (tsenevir)" >, "netmod@ietf.org" > Subject: Re: [netmod] presentations of other drafts Tissa, Having many YANG models is a good problem to have IMO. This implies that YA= NG (and NETCONF) has been going in the right direction the last couple of y= ears. I'm sorry that the YANG data models have not been presented, but the WG sho= uld focus on the WG documents first. Now, not being able to present the dra= fts must not prevent you and the community to work on the drafts on the dif= ferent mailings (whether NETMOD or not). Finally, let's not forget that the YANG doctors reviewed some of the docume= nts during the Sunday session * YANG Model for Access Control Lists 11:00 [ 5 min] * YANG Model for SYSLOG 11:05 [ 5 min] * YANG Model for OAM 11:10 [ 5 min] * YANG Model for WDM Interfaces 11:15 [ 5 min] Let me discuss with the chairs on what we can do better next time. Regards, Benoit (OPS AD) Dear WG chairs I am pleased that WG has opened up the charter for new YANG models. However= , the way time was managed today for new drafts was not the best, to say th= e least. If the WG is serious of encouraging new YANG models to go through netmod WG= , my suggestion is WG to allocate portion of the meeting say 20 mins for ne= w YANG models and WG chairs to manage that time effectively and efficiently= . Allocating 5 mins to a draft is actually meaningless. That time would take = someone to walk up to the mic and pin the microphone and say good morning. = Allocating sizable chunk to new work carve out the time needed for new work= . My 2 bits. Thanks Tissa _______________________________________________ netmod mailing list netmod@ietf.orghttps://www.ietf.org/mailman/listinf= o/netmod --_000_CFF67E053B66Ayihuanciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
The Sunday session helped. It would be nice that the WG agenda could indicate open mic time as well.  When t= he open mic time limit reached, If there are still more people interested i= n that draft, names could be recorded to form a small group discussion afte= rwards. 

From: "Benoit Claise (bclaise)= " <bclaise@cisco.com> Date: Tuesday, July 22, 2014 10:34 = AM
To: "Tissa Senevirathne (tsene= vir)" <tsenevir@cisco.com= >, "netmod@ietf.org" &l= t;netmod@ietf.org>
Subject: Re: [netmod] presentations= of other drafts

Tissa,

Having many YANG models is a good problem to have IMO. This implies that YA= NG (and NETCONF) has been going in the right direction the last couple of y= ears.

I'm sorry that the YANG data models have not been presented, but the WG sho= uld focus on the WG documents first. Now, not being able to present the dra= fts must not prevent you and the community to work on the drafts on the dif= ferent mailings (whether NETMOD or not).

Finally, let's not forget that the YANG doctors reviewed some of the docume= nts during the Sunday session
* YANG Model for Access Control Lists		11:00	[ 5 min]
* YANG Model for SYSLOG				11:05	[ 5 min]
* YANG Model for OAM				11:10	[ 5 min]
* YANG Model for WDM Interfaces			11:15	[ 5 min]
Let me discuss with the chairs on what we can do better next time.

Regards, Benoit (OPS AD)

Dear WG chairs

 

I am pleased that WG has opened up the charter for n= ew YANG models. However, the way time was managed today for new drafts was = not the best, to say the least.

 

If the WG is serious of encouraging new YANG models = to go through netmod WG, my suggestion is WG to allocate portion of the mee= ting say 20 mins for new YANG models and WG chairs to manage that time effe= ctively and efficiently.

 

Allocating 5 mins to a draft is actually meaningless= . That time would take someone to walk up to the mic and pin the microphone= and say good morning. Allocating sizable chunk to new work carve out the t= ime needed for new work.

 

My 2 bits.

 

Thanks

Tissa



_______________________________________________
netmod mailing list
netmo=
d@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod

 --_000_CFF67E053B66Ayihuanciscocom_-- From nobody Thu Jul 24 10:24:09 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815B71A0ACE for ; Thu, 24 Jul 2014 10:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NhQSw8z5ZAO for ; Thu, 24 Jul 2014 10:24:06 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 972A21A0B07 for ; Thu, 24 Jul 2014 10:23:05 -0700 (PDT) Received: from [192.168.1.67] (static-72-71-250-37.cncdnh.fast04.myfairpoint.net [72.71.250.37]) by lucidvision.com (Postfix) with ESMTP id D5A542832079; Thu, 24 Jul 2014 13:23:04 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_FF634E02-D714-4A46-A4FB-4CA3BDEA9464"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Thomas D. Nadeau In-Reply-To: Date: Thu, 24 Jul 2014 13:22:49 -0400 Message-Id: References: To: "Lisa Huang (yihuan)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/il3PNtigxmqfQ9GQeulVEgkJjSo Cc: "netmod@ietf.org" Subject: Re: [netmod] presentations of other drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 17:24:08 -0000 --Apple-Mail=_FF634E02-D714-4A46-A4FB-4CA3BDEA9464 Content-Type: multipart/alternative; boundary="Apple-Mail=_04108563-10CB-4CA3-BD4F-30154A24E1E1" --Apple-Mail=_04108563-10CB-4CA3-BD4F-30154A24E1E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi guys, Thanks for the enthusiasm around building Yang models. To address your points there are several options here. As we = all well know if you've been to more than 1 IETF meeting, WG meetings = are probably not the best forum to work on things like editing drafts. = For this reason, we will encourage and help guide this work outside of = the official meetings much as was done with the recent "experiments". = This work can be done outside of the IETF meeting or impromptu meetings = during the IETF week. We will also be hosting additional Yangathons = both at the next IETF meeting, and elsewhere (TBD) where people can = gather (virtually or in person) to build models. For example, I am = going to try to put one together around the ODL Dev Con in late = September in San Jose, CA.=20 --Tom On Jul 24, 2014:9:32 AM, at 9:32 AM, Lisa Huang (yihuan) = wrote: > The Sunday session helped. It would be nice that the WG agenda could = indicate open mic time as well. When the open mic time limit reached, = If there are still more people interested in that draft, names could be = recorded to form a small group discussion afterwards.=20 >=20 > From: "Benoit Claise (bclaise)" > Date: Tuesday, July 22, 2014 10:34 AM > To: "Tissa Senevirathne (tsenevir)" , = "netmod@ietf.org" > Subject: Re: [netmod] presentations of other drafts >=20 > Tissa, >=20 > Having many YANG models is a good problem to have IMO. This implies = that YANG (and NETCONF) has been going in the right direction the last = couple of years. >=20 > I'm sorry that the YANG data models have not been presented, but the = WG should focus on the WG documents first. Now, not being able to = present the drafts must not prevent you and the community to work on the = drafts on the different mailings (whether NETMOD or not). >=20 > Finally, let's not forget that the YANG doctors reviewed some of the = documents during the Sunday session > * YANG Model for Access Control Lists 11:00 [ 5 min] > * YANG Model for SYSLOG 11:05 [ 5 min] > * YANG Model for OAM 11:10 [ 5 min] > * YANG Model for WDM Interfaces 11:15 [ 5 min] > Let me discuss with the chairs on what we can do better next time. >=20 > Regards, Benoit (OPS AD) >> Dear WG chairs >> =20 >> I am pleased that WG has opened up the charter for new YANG models. = However, the way time was managed today for new drafts was not the best, = to say the least. >> =20 >> If the WG is serious of encouraging new YANG models to go through = netmod WG, my suggestion is WG to allocate portion of the meeting say 20 = mins for new YANG models and WG chairs to manage that time effectively = and efficiently. >> =20 >> Allocating 5 mins to a draft is actually meaningless. That time would = take someone to walk up to the mic and pin the microphone and say good = morning. Allocating sizable chunk to new work carve out the time needed = for new work. >> =20 >> My 2 bits. >> =20 >> Thanks >> Tissa >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_04108563-10CB-4CA3-BD4F-30154A24E1E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Hi = guys,

Thanks for the enthusiasm around = building Yang models.

To address your points there are = several options here.  As we all well know if you've been to more = than 1 IETF meeting, WG meetings are probably not the best forum to work = on things like editing drafts.  For this reason, we will encourage = and help guide this work outside of the official meetings much as was = done with the recent "experiments".  This work can be done outside = of the IETF meeting or impromptu meetings during the IETF week.  We = will also be hosting additional Yangathons both at the next IETF = meeting, and elsewhere (TBD)  where people can gather (virtually or = in person) to build models.   For example, I am going to try to put = one together around the ODL Dev Con in late September in San Jose, = CA. 

= --Tom




The Sunday session helped. = It would be nice that the WG = agenda could indicate open mic time as well.  When the open mic = time limit reached, If there are still more people interested in that = draft, names could be recorded to form a small group discussion = afterwards. 

From: "Benoit Claise = (bclaise)" <bclaise@cisco.com>
Date: Tuesday, July 22, = 2014 10:34 AM
To: "Tissa Senevirathne = (tsenevir)" <tsenevir@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] = presentations of other drafts

Tissa,

Having many YANG models is a = good problem to have IMO. This implies that YANG (and NETCONF) has been = going in the right direction the last couple of years.

I'm sorry = that the YANG data models have not been presented, but the WG should = focus on the WG documents first. Now, not being able to present the = drafts must not prevent you and the community to work on the drafts on = the different mailings (whether NETMOD or not).

Finally, let's = not forget that the YANG doctors reviewed some of the documents during = the Sunday session
* YANG Model for Access Control Lists		=
11:00	[ 5 min]
* YANG Model for SYSLOG				11:05	[ 5 min]
* YANG Model for OAM				11:10	[ 5 min]
* YANG Model for WDM Interfaces			11:15	[ 5 min]
Let me discuss with the chairs on what we can do better next = time.

Regards, Benoit (OPS AD)
Dear WG chairs
 
I am = pleased that WG has opened up the charter for new YANG models. However, = the way time was managed today for new drafts was not the best, to say = the least.
 
If the WG = is serious of encouraging new YANG models to go through netmod WG, my = suggestion is WG to allocate portion of the meeting say 20 mins for new = YANG models and WG chairs to manage that time effectively and = efficiently.
 
Allocating = 5 mins to a draft is actually meaningless. That time would take someone = to walk up to the mic and pin the microphone and say good morning. = Allocating sizable chunk to new work carve out the time needed for new = work.
 
My 2 bits.
 
Thanks
Tissa


_______________________________________________
netmod mailing list
netmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod

______________________________________________= _
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

= --Apple-Mail=_04108563-10CB-4CA3-BD4F-30154A24E1E1-- --Apple-Mail=_FF634E02-D714-4A46-A4FB-4CA3BDEA9464 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT0UDqAAoJEPcO+I7eiUJZwZoP/2LUvU4UQYywDGtfND+SfzVe 62GOrrz1tHnehcDHZOflNm/TzUQXxMpCMRiCvuL+ipOmC+FjIggQiJAijak+jTic 2a4ZxwBA7pnDvIGYAEcHs0TRbI74BePqCeDuVCEUMl/nFA8bOVN02cKHmEqGw5BS UX/cWcVde8dXPgrAxBlfFBQl/tac7CFeL00BpNqgPV8IRCeucYqTwyeDQfomU16T jx7uANUFBkG0rf4Mxg5x0GVA6IUc/vvvSgBgIHYkJIeDMxvQGT1IimwRBM8+55aA ouRuZIZCyNkxUeKi8MFbVXP7j9xe3HYh2wYyIdWRY2/6BZnWIOBASYp8H3YBE4Ia zpbOLs1ewbn2HJXgzDt3lRM8Fllp6Y6Rq8vLp4awxfK9sLIDzxQIF2a9EF4jhgp0 rBXD5d6HoVEuJhUu1zb5XlyW+1dH9mb5lXkniHRi16xoM1C98IS29exeSvRKPnPm E3FXbwiDF/ouQtOiZbNiv4H01EVUeAuXPdp0oLz8asg8yFYHtUWULO3bVIuPrDiL ahvwGVk+zguQo8rLdPRncCflPH06H7F7dOglf6Lj3TOFJemLQI23bmCGVXJrYHLl 5l9s7XB/FvIzYUFvqHrtj+gm9Vpa7/Lkq3viqCXHjOBU90yIo23zEbly7NzEB85m RMtkwuT056jjbYWZyllz =2syT -----END PGP SIGNATURE----- --Apple-Mail=_FF634E02-D714-4A46-A4FB-4CA3BDEA9464-- From nobody Sat Jul 26 01:38:44 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E971A0072; Sat, 26 Jul 2014 01:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eY0QjJ85hwOe; Sat, 26 Jul 2014 01:38:40 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8921A0059; Sat, 26 Jul 2014 01:38:40 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D877A1153; Sat, 26 Jul 2014 10:38:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 21DRL-1TnY4o; Sat, 26 Jul 2014 10:38:12 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 26 Jul 2014 10:38:37 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B7AD22002C; Sat, 26 Jul 2014 10:38:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3r0cj_tjeh8g; Sat, 26 Jul 2014 10:38:36 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A60E20017; Sat, 26 Jul 2014 10:38:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3AB242DF9DEF; Sat, 26 Jul 2014 10:38:34 +0200 (CEST) Date: Sat, 26 Jul 2014 10:38:34 +0200 From: Juergen Schoenwaelder To: proceedings@ietf.org Message-ID: <20140726083834.GA50638@elstar.local> Mail-Followup-To: proceedings@ietf.org, netmod@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/EBLySKhnc4np76iYTtdMJ_znJko Cc: netmod@ietf.org Subject: [netmod] minutes of the NETMOD 2014-07-09 virtual interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 26 Jul 2014 08:38:42 -0000 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, attached please find the minutes of the NETMOD virtual interim meeting that took place on 2014-07-09. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="netmod-2014-07-09-minutes.txt" o============================================================= NETCONF Data Modeling Language WG (netmod) 3rd YANG 1.1 Virtual Interim Wednesday, July 9th, 2014, 16:00-18:00 CEST Minutes Juergen Schoenwaelder ============================================================= * Participants - JS = Juergen Schoenwaelder - AZ = Alex Zhdankin - AB = Andy Bierman - LL = Lada Lotka - PO = Peyman Owladi - PH = Peter van Horne - AN = Anonymous - TN = Tom Nadeau * Summary * Y20: new set of built-in XPath functions Proposal: MB to copy the functions he proposed to RFC 6020bis as a starting point and then we review and discuss changes. * Y23: support negative patterns as string restrictions AB prefers solution #2, LL and PO as well. Proposal: Adopt Y23-02. * Y25: make enum numbering purely informative and optional LL and JS prefer Y25-01, AB likes it as well since the number is nowhere used in NETCONF. Proposal: Adopt Y25-01. * Y26: allow mandatory nodes in augment AB: It is too restrictive the way it is, allowing all mandatory nodes is too much. PO: We then need to enumerate the cases where mandatory nodes would be OK. PO: You are not allowed to use it in cases that break backwards compatibility? AN: That is what we want, but hard to implement. I think we need to start enumerating cases where it is OK and cases where not. AN: Augmentation may include mandatory nodes but it can't make something in a pre-existing container have additional mandatory nodes. LL: There can be containers designed to be augmented, e.g. for different address families. AN: Sounds like an abstract class concept where you can only instantiate concrete classes. LL: Yes. We have this with an 'abstract' routing entry. AB: But you break an old implementation, no? LL: We have this in the routing data model. If we could express that this needs an address specific module to work, we could handle this properly. JS: But this is on the container level, if we were to tag containers as incomplete, we would have machine readable information to take a decision whether an augment with mandatory nodes is allowed. AN: I think LL is really talking about a new issue. AB: ODL has designs with empty containers that are filled from the outside and these trigger wrong warnings. Conclusion: There is agreement that the current text is overly restrictive. The proposal is to add general guiding rules that backwards compatibility needs to be maintained. Lets see whether someone can write more concrete rules when mandatory nodes in augment are allowed. * Y27: allow mandatory nodes in an updated module PO: How does this relate to Y26? AB: In Y26 the version number does not change. LL: But the server now announces a new module. AB: Clients do not have to check whether any other modules augment mandatory nodes into a given module. AB: In Y26, the client does not any indication that the module changed. TN: We are mounting devices into some parts of the tree. And some devices may have different versions of modules. PH: We also use modules in various projects. TN: Allow with specific rules and caveats. PH: This is a case where and old client accessing a new revision will find his request invalid. PH: Deprecate and obsolete allows a reasonable deprecation path. PH: With this proposal, you break old clients immediately. JS: This is not how RFC 6020 section 10 first paragraph says it works. JS: It seems Y27-01 breaks the second sentence of section 10 of RFC 6020. PO: Should we instead discuss that obsolete should have additional text that this should not be mis-used to break compatibility? Some discussion about versioning not fully captured. PO: Should we have guidelines how to go from current to deprecated to obsolete in RFC 6087bis? Conclusion: The strawman proposal is to reject this issue, AB to check what the feature issue is about, possible action to add guidelines how to go from current to deprecated to obsolete in RFC 6087bis. * Y28 support default values in leaf-lists AB: I prefer Y28-01. JS: But this has problems since we would have to introduce a syntax that works for all possible values. PO: It seems Y28-02 works out of the box. LL: I think we should go with Y28-02. PO: This is slightly different from other defaults for implementations threat treat internally each leaf-list value as a separate object. AB: You can add to a set of values of a leaf-list using a NETCONF merge and hence leaf-lists are rather different and we can't simply extend default in this way. AB: We should do this somehow but it requires some work since leaf-lists are really different from leafs here. AB: Right now all we do is putting text into description statements. PO: If someone comes along and explicitly configures 830, then the value is not a default anymore. Conclusion: AB will look at the necessary text what it means to modify leaf-list values. Perhaps there is a need to have a different keyword since the behavior is rather different here. * Y29 allow choice as a short-hand case Strawman is to adopt the proposed solution. * Y30 allow leafref in union LL: Does this require that the instance referred to exists? AB: You check whether it exists, if not, you go on to the next option in the union. PO: The existence of a certain leaf determines to which type a union value resolves. This makes it different from other types in a union. AB: This might make differences if you make multiple updates in an edit-config. PO: But this is the same for other types in a union. Clearly Y30 and Y31 are interrelated. We did run out of time and we will continue in Toronto. We will skip next week's meeting since LL is also on vacation and IETF preparations also need to be made by several people. --17pEHd4RhPHOinZp-- From nobody Sat Jul 26 20:23:07 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF2B1A003A for ; Sat, 26 Jul 2014 20:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAl3WG5PAG0T for ; Sat, 26 Jul 2014 20:23:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 116811A0046 for ; Sat, 26 Jul 2014 20:23:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140727032305.21217.28094.idtracker@ietfa.amsl.com> Date: Sat, 26 Jul 2014 20:23:05 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/wXTZxO1JcU_gVcpqAbIFQQyJSio Subject: [netmod] Milestones changed for netmod WG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2014 03:23:06 -0000 Changed milestone "Submit first working group draft of YANG guidelines update", set state to active from review, accepting new milestone. Changed milestone "Submit YANG guidelines update to the IESG", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/netmod/charter/ From nobody Mon Jul 28 02:09:00 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283E11A0330 for ; Mon, 28 Jul 2014 02:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-FdjGNWnofh for ; Mon, 28 Jul 2014 02:08:53 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 726511A031F for ; Mon, 28 Jul 2014 02:08:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id E3F635406C1 for ; Mon, 28 Jul 2014 11:08:50 +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 awYEQzJYvEMn for ; Mon, 28 Jul 2014 11:08:45 +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 A55CC54014A for ; Mon, 28 Jul 2014 11:08:45 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Mon, 28 Jul 2014 11:08:43 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-8oBlGpCSn-IbULnQkurcdBng-E Subject: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 09:08:59 -0000 Hi, as I mentioned in Toronto, the mapping of XML attributes to JSON cannot represent namespaces of attributes, which is IMO a serious deficiency. Now, since YANG 1.1 issue Y33 (add "attribute" statement) was shot DEAD, we need to find another way for attribute namespace encoding. Peter Saint-Andre once proposed a generic method in the expired draft http://tools.ietf.org/html/draft-saintandre-json-namespaces-00 For example, true would be mapped as follows: "flag": true, "@flag": { "{http://example.com}foo": "a" } This is of course not very nice as namespace URIs will often be longer than in this example. Any other suggestions? Thanks, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jul 28 02:55:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57D31A0382 for ; Mon, 28 Jul 2014 02:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUnnBjYYszon for ; Mon, 28 Jul 2014 02:55:07 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 426DB1A0377 for ; Mon, 28 Jul 2014 02:55:06 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B76CE93; Mon, 28 Jul 2014 11:55:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id pbKkrFQ_lM1D; Mon, 28 Jul 2014 11:55:02 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 28 Jul 2014 11:55:03 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B91D20036; Mon, 28 Jul 2014 11:55:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id eqE3stvVOBPe; Mon, 28 Jul 2014 11:55:02 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 29F192002F; Mon, 28 Jul 2014 11:55:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E611B2DFC8E6; Mon, 28 Jul 2014 11:55:01 +0200 (CEST) Date: Mon, 28 Jul 2014 11:55:01 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140728095501.GB55180@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_V9E3-fBPgV46bBIG5rLeK31U60 Cc: netmod@ietf.org Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jul 2014 09:55:09 -0000 On Mon, Jul 28, 2014 at 11:08:43AM +0200, Ladislav Lhotka wrote: > Hi, > > as I mentioned in Toronto, the mapping of XML attributes to JSON cannot > represent namespaces of attributes, which is IMO a serious deficiency. > > Now, since YANG 1.1 issue Y33 (add "attribute" statement) was shot DEAD, > we need to find another way for attribute namespace encoding. What has the JSON encoding of namespaces for attributes todo with Y33? Why can we not make the namespace encoding we have for leafs make work for attributes as well? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jul 28 03:27:41 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742521A03A1 for ; Mon, 28 Jul 2014 03:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhOfz0MkS4vR for ; Mon, 28 Jul 2014 03:27:38 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 796E31A0397 for ; Mon, 28 Jul 2014 03:27:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id AF7B35406C1; Mon, 28 Jul 2014 12:27:36 +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 HNd5UFc7taLr; Mon, 28 Jul 2014 12:27:32 +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 3BD26540192; Mon, 28 Jul 2014 12:27:32 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20140728095501.GB55180@elstar.local> References: <20140728095501.GB55180@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Mon, 28 Jul 2014 12:27:29 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yZ3apKhnA2_WGjOu1Tdew6ixr7w Cc: netmod@ietf.org Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 10:27:40 -0000 Juergen Schoenwaelder writes: > On Mon, Jul 28, 2014 at 11:08:43AM +0200, Ladislav Lhotka wrote: >> Hi, >> >> as I mentioned in Toronto, the mapping of XML attributes to JSON cannot >> represent namespaces of attributes, which is IMO a serious deficiency. >> >> Now, since YANG 1.1 issue Y33 (add "attribute" statement) was shot DEAD, >> we need to find another way for attribute namespace encoding. > > What has the JSON encoding of namespaces for attributes todo with Y33? > Why can we not make the namespace encoding we have for leafs make work > for attributes as well? Y33 proposed the top-level "attribute" statement for defining *global* attributes. Such a definition would make an association between the attribute and YANG module, and then, indeed, we could use the same namespace encoding as for other data nodes. For example, with module exattr { namespace "http://example.com"; prefix "ex"; attribute foo { description "..."; type string; } } my example would become "flag": true, "@flag": { "exattr:foo": "a" } Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jul 28 03:47:11 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7111A03D2 for ; Mon, 28 Jul 2014 03:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liCa3-z0hS3F for ; Mon, 28 Jul 2014 03:47:07 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98A5C1A0108 for ; Mon, 28 Jul 2014 03:47:07 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id e89so8326334qgf.31 for ; Mon, 28 Jul 2014 03:47:06 -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=L4+WAizUG7fjE6sisXaPeZQ3W/VT5W8ceLCimvBlPAo=; b=lzD7rJvZyIiIF6vpm7AtY2qMaS2qc/E+ITBFbP459KZ2d7p7io6K8nSrX8dkglmE+M R9uu3EWQclXq06JkrKTJNg299pYv18PCPmdyeh3JEOk1VuHF5HxNyenCQRX09c6S1kNF GRSXIsgBOupWDVz5qieq1fC5KAKIHG5TWeRVAbui8Pd5rJIzdnU6gcJTj//6nzAkKVtD F57lKhsRm6Q1xjFGbwoDWxFKYQP8hzEKf9/Onh6pj4Goh/9uXrbyKmzDJGmpHjEkE9Ob 28xNsoMzLpyxwww0+UI7wRrtYywRVVW+ZV3D7rJScPK0S8sNWPP918QL+sji5QxMBgoe N8+g== X-Gm-Message-State: ALoCoQk4LqUflrv6IuAGKEdNCcv0drYbp/MoXNgPfEItUKLPvkJvptBs1o3OMSwTzFlqJgg5Y6vO MIME-Version: 1.0 X-Received: by 10.224.122.83 with SMTP id k19mr57201146qar.78.1406544426673; Mon, 28 Jul 2014 03:47:06 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Mon, 28 Jul 2014 03:47:06 -0700 (PDT) In-Reply-To: References: <20140728095501.GB55180@elstar.local> Date: Mon, 28 Jul 2014 03:47:06 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7bf0c346e9e16204ff3ea41a Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/MLjXaxLFBKWjdcZLlMzUAobqKNA Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 10:47:09 -0000 --047d7bf0c346e9e16204ff3ea41a Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 28, 2014 at 3:27 AM, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > On Mon, Jul 28, 2014 at 11:08:43AM +0200, Ladislav Lhotka wrote: > >> Hi, > >> > >> as I mentioned in Toronto, the mapping of XML attributes to JSON cannot > >> represent namespaces of attributes, which is IMO a serious deficiency. > >> > >> Now, since YANG 1.1 issue Y33 (add "attribute" statement) was shot DEAD, > >> we need to find another way for attribute namespace encoding. > > > > What has the JSON encoding of namespaces for attributes todo with Y33? > > Why can we not make the namespace encoding we have for leafs make work > > for attributes as well? > > Y33 proposed the top-level "attribute" statement for defining *global* > attributes. Such a definition would make an association between the > attribute and YANG module, and then, indeed, we could use the same > namespace encoding as for other data nodes. For example, with > > module exattr { > namespace "http://example.com"; > prefix "ex"; > attribute foo { > description "..."; > type string; > } > } > > my example would become > > "flag": true, > "@flag": { > "exattr:foo": "a" > } > > The definition of any attribute used within RESTCONF needs to pick a string that will be used as the module name. The YANG to JSON mapping can simply say that a module name is assigned to an attribute somehow. The module name and attribute semantics do not need to be defined in YANG. Lada > > > > > /js > Andy > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --047d7bf0c346e9e16204ff3ea41a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jul 28, 2014 at 3:27 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<= /a>> writes:

> On Mon, Jul 28, 2014 at 11:08:43AM +0200, Ladislav Lhotka wrote:
>> Hi,
>>
>> as I mentioned in Toronto, the mapping of XML attributes to JSON c= annot
>> represent namespaces of attributes, which is IMO a serious deficie= ncy.
>>
>> Now, since YANG 1.1 issue Y33 (add "attribute" statement= ) was shot DEAD,
>> we need to find another way for attribute namespace encoding.
>
> What has the JSON encoding of namespaces for attributes todo with Y33?=
> Why can we not make the namespace encoding we have for leafs make work=
> for attributes as well?

Y33 proposed the top-level "attribute" statement for defining *gl= obal*
attributes. Such a definition would make an association between the
attribute and YANG module, and then, indeed, we could use the same
namespace encoding as for other data nodes. For example, with

module exattr {
=A0 =A0 namespace "ht= tp://example.com";
=A0 =A0 prefix "ex";
=A0 =A0 attribute foo {
=A0 =A0 =A0 =A0 description "...";
=A0 =A0 =A0 =A0 type string;
=A0 =A0 }
}

my example would become

"flag": true,
"@flag": {
=A0 "exattr:foo": "a"
}


The definition of any attribute used w= ithin RESTCONF needs to pick a
string that will be used as the mo= dule name. =A0

The YANG to JSON mapping can simply= say that a module name is
assigned to an attribute somehow. =A0The module name and attribute
semantics do not need to be defined in YANG.


Lada

>
> /js

Andy

= =A0
>
> --
> Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGm= bH
> Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, G= ermany
> Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/= >

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--047d7bf0c346e9e16204ff3ea41a-- From nobody Mon Jul 28 05:06:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F061A03EF for ; Mon, 28 Jul 2014 05:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gJqSesTF4fd for ; Mon, 28 Jul 2014 05:06:39 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99A881A02B9 for ; Mon, 28 Jul 2014 05:06:38 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id A743B140075; Mon, 28 Jul 2014 14:06:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1406549196; bh=/nmUNDnQav66AbbqTbuAIrFxZDcJE4D6DiT4fHClP8M=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=GAIbkkzwkxyK6FaAOi1CpY7RndXHzAbb1g4nL0q+wBfuCJj5mstqQoyxYod3vHoQW GariiDLw9t0ZXbT1zxiun3KrPd3g6WIv6+l914gH8H/oU+3pvHS0OL+n7OUCVNUAEp zHAg1CwzN0Gp2E16b5GA0mUY+tuSk4G4i5DyfQ9Y= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 28 Jul 2014 14:06:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140728095501.GB55180@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/QoTiwsumQFmJVL9PzjHnvlDDvZs Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 12:06:44 -0000 On 28 Jul 2014, at 12:47, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Jul 28, 2014 at 3:27 AM, Ladislav Lhotka = wrote: > Juergen Schoenwaelder writes: >=20 > > On Mon, Jul 28, 2014 at 11:08:43AM +0200, Ladislav Lhotka wrote: > >> Hi, > >> > >> as I mentioned in Toronto, the mapping of XML attributes to JSON = cannot > >> represent namespaces of attributes, which is IMO a serious = deficiency. > >> > >> Now, since YANG 1.1 issue Y33 (add "attribute" statement) was shot = DEAD, > >> we need to find another way for attribute namespace encoding. > > > > What has the JSON encoding of namespaces for attributes todo with = Y33? > > Why can we not make the namespace encoding we have for leafs make = work > > for attributes as well? >=20 > Y33 proposed the top-level "attribute" statement for defining *global* > attributes. Such a definition would make an association between the > attribute and YANG module, and then, indeed, we could use the same > namespace encoding as for other data nodes. For example, with >=20 > module exattr { > namespace "http://example.com"; > prefix "ex"; > attribute foo { > description "..."; > type string; > } > } >=20 > my example would become >=20 > "flag": true, > "@flag": { > "exattr:foo": "a" > } >=20 >=20 > The definition of any attribute used within RESTCONF needs to pick a > string that will be used as the module name. =20 >=20 > The YANG to JSON mapping can simply say that a module name is > assigned to an attribute somehow. The module name and attribute > semantics do not need to be defined in YANG. But then, IMO, the cleanest way is to make this explicit by using the = =93attribute=94 statement which - assigns the attribute to a module, - also assigns the namespace URI and recommended prefix for XML = encoding, - defines a datatype for the attribute, which may occasionally be = useful. I=92d like to emphasize that Y33 was only about global attributes, i.e. = it doesn=92t attempt to make attributes into regular data nodes, so the = following would NOT be possible: leaf flag { attribute foo {=85} =85 } Lada >=20 >=20 > Lada >=20 > > > > /js >=20 > Andy >=20 > =20 > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jul 28 05:13:40 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9661A0162 for ; Mon, 28 Jul 2014 05:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWOdXyY-9SaE for ; Mon, 28 Jul 2014 05:13:32 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D3F11A040B for ; Mon, 28 Jul 2014 05:13:32 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DC058AC2; Mon, 28 Jul 2014 14:13:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id GHDLKNQuf4pS; Mon, 28 Jul 2014 14:13:30 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 28 Jul 2014 14:13:30 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4A5DD2002C; Mon, 28 Jul 2014 14:13:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id uW0tsrS7_d6p; Mon, 28 Jul 2014 14:13: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 3D71F20017; Mon, 28 Jul 2014 14:13:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7C8BB2DFCAE0; Mon, 28 Jul 2014 14:13:28 +0200 (CEST) Date: Mon, 28 Jul 2014 14:13:28 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140728121328.GA55631@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <20140728095501.GB55180@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/0MiAq_BQ1EEMVnMHZpmY0mLilBI Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jul 2014 12:13:37 -0000 On Mon, Jul 28, 2014 at 02:06:30PM +0200, Ladislav Lhotka wrote: > > But then, IMO, the cleanest way is to make this explicit by using the “attribute†statement which > > - assigns the attribute to a module, > - also assigns the namespace URI and recommended prefix for XML encoding, > - defines a datatype for the attribute, which may occasionally be useful. > > I’d like to emphasize that Y33 was only about global attributes, i.e. it doesn’t attempt to make attributes into regular data nodes, so the following would NOT be possible: > > leaf flag { > attribute foo {…} > … > } I can counter argue that easily: If we do not do Y33, then there are no attributes and hence there is no need to encode them in JSON. Move the whole attribute encoding text into a non-normative appendix and we are done. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jul 28 05:19:54 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B150D1A03CB for ; Mon, 28 Jul 2014 05:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBbWGllBxdSm for ; Mon, 28 Jul 2014 05:19:51 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C81541A0172 for ; Mon, 28 Jul 2014 05:19:50 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 0FF15140075; Mon, 28 Jul 2014 14:19:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1406549989; bh=Vc0JXyVAiCgVHw4IEJ9QRApiYltKedSsSaFDSkgWvmY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=c2nSphCWQk0uGdbkW5LYSBR0K8g5HtFgnGbEmn3rxdIGsZdKm/aoB9u2L1UTWMMtf NL6zg4lLBX0nOAFrT+UgICsf9eO6mIiVg3LHntHXJZ04Opu0mcUukFd0axyHJnVNQc BJ4wln5Bde15MeU6kqcK7h/QDeLqVX71HDP1s8Aw= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140728121328.GA55631@elstar.local> Date: Mon, 28 Jul 2014 14:19:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1D814F6F-AC4B-4E27-AF5B-12156E3ABAF4@nic.cz> References: <20140728095501.GB55180@elstar.local> <20140728121328.GA55631@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/r86urdU5MvtlLWQy8BO7K__d97s Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 12:19:51 -0000 On 28 Jul 2014, at 14:13, Juergen Schoenwaelder = wrote: > On Mon, Jul 28, 2014 at 02:06:30PM +0200, Ladislav Lhotka wrote: >>=20 >=20 >> But then, IMO, the cleanest way is to make this explicit by using the = =93attribute=94 statement which >>=20 >> - assigns the attribute to a module, >> - also assigns the namespace URI and recommended prefix for XML = encoding, >> - defines a datatype for the attribute, which may occasionally be = useful. >>=20 >> I=92d like to emphasize that Y33 was only about global attributes, = i.e. it doesn=92t attempt to make attributes into regular data nodes, so = the following would NOT be possible: >>=20 >> leaf flag { >> attribute foo {=85} >> =85 >> } >=20 > I can counter argue that easily: If we do not do Y33, then there are > no attributes and hence there is no need to encode them in JSON. Move > the whole attribute encoding text into a non-normative appendix and we > are done. Well, it needn=92t be there at all because YANG doesn=92t model = attributes. Normative or not, without means for representing an = attribute=92s namespace it doesn=92t make sense to have it there. Lada=20 >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jul 28 05:33:12 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F4B1A01F6 for ; Mon, 28 Jul 2014 05:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICDN5qZ-H1FN for ; Mon, 28 Jul 2014 05:33:08 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8FCC1A0174 for ; Mon, 28 Jul 2014 05:33:07 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id s7so7623910qap.9 for ; Mon, 28 Jul 2014 05:33:07 -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=W1FVhHajvIRKKoAHpX40f4xb2u5ZGGL06PsGQLFpU6M=; b=QfhJx93dlaqnIi8qMgK+GH51qvxls2h455F+48jGZc1KqDHK/O3dMHomOrqGV8YYsD AYCYQ25fVxGb+N5neZMluE3LpSrtCJn1CYCwsBlLB3jHWCd00U6aVFEGUt1uHqBc9lJ2 zXkaGfiPxmtf4fWXMdgoGMZxxtnFU6TNwNGvrkvzvw9StcIZVvIsCqTdAdlEimTKKbOM TsIyzSYNurb5RxTYEiJse2QOshULHRlQQcTzxiXfwWuPrjNB5yBY5/dIKMQv8/EFP+g4 cg+J2wc/1LVlZydxzK0b3ofqWfCT5OGrt+4Cj3Hm9JiJoTDE4XIAzPDvI9ZLB1OtV8Rr 5UtA== X-Gm-Message-State: ALoCoQnSIGR3kRkCabFgWa5LTG7yM6LwX9NtwksjiCofdkJUlqow7JBtEG86ptmzTBhj1uehWLCi MIME-Version: 1.0 X-Received: by 10.224.127.74 with SMTP id f10mr7906938qas.100.1406550786960; Mon, 28 Jul 2014 05:33:06 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Mon, 28 Jul 2014 05:33:06 -0700 (PDT) In-Reply-To: <20140728121328.GA55631@elstar.local> References: <20140728095501.GB55180@elstar.local> <20140728121328.GA55631@elstar.local> Date: Mon, 28 Jul 2014 05:33:06 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2cc180411aa04ff402031 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/UGTdV3HitBXA7LjAXpqdR2nuOfA Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 12:33:10 -0000 --001a11c2cc180411aa04ff402031 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 28, 2014 at 5:13 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Jul 28, 2014 at 02:06:30PM +0200, Ladislav Lhotka wrote: > > > > > But then, IMO, the cleanest way is to make this explicit by using the > "attribute" statement which > > > > - assigns the attribute to a module, > > - also assigns the namespace URI and recommended prefix for XML encoding, > > - defines a datatype for the attribute, which may occasionally be useful. > > > > I'd like to emphasize that Y33 was only about global attributes, i.e. it > doesn't attempt to make attributes into regular data nodes, so the > following would NOT be possible: > > > > leaf flag { > > attribute foo {...} > > ... > > } > > I can counter argue that easily: If we do not do Y33, then there are > no attributes and hence there is no need to encode them in JSON. Move > the whole attribute encoding text into a non-normative appendix and we > are done. > > Several people want to support attributes in the RESTCONF protocol messages. Martin came up with a solution that works and we already agreed to use it in RESTCONF. I agree there does not need to be a YANG definition for the attributes used in RESTCONF protocol messages. The attribute definition could be in an XSD. The description annotation can specify the string to use for the module name, for encoding as a qualified attribute in RESTCONF. (The YANG insert attributes are just defined in text, not even an XSD). There is no need to define any attributes at all in YANG data model content. It we do that, then it will be abused. I want to support protocol layer attributes like with-defaults (report-all-tagged) or conditional enablement (enabled). The protocol spec should define protocol attributes, not the data modeling language. I have said before many times -- a mapping from YANG to JSON is somewhat useless because we don't sent JSON across the wire. We send protocol messages encoded in JSON. We need a mapping that allows entire protocol messages to be encoded, not just the YANG content layer. Andy /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --001a11c2cc180411aa04ff402031 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jul 28, 2014 at 5:13 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Jul 28, 2014 at 02:06:30PM +0200, La= dislav Lhotka wrote:
>

> But then, IMO, the cleanest way is to make this explicit by using the = “attribute” statement which
>
> - assigns the attribute to a module,
> - also assigns the namespace URI and recommended prefix for XML encodi= ng,
> - defines a datatype for the attribute, which may occasionally be usef= ul.
>
> I’d like to emphasize that Y33 was only about global attributes,= i.e. it doesn’t attempt to make attributes into regular data nodes, = so the following would NOT be possible:
>
> leaf flag {
>     attribute foo {…}
>     …
> }

I can counter argue that easily: If we do not do Y33, then there are
no attributes and hence there is no need to encode them in JSON. Move
the whole attribute encoding text into a non-normative appendix and we
are done.


Several people want to support attributes in the RES= TCONF protocol messages.
Martin came up with a solution that work= s and we already agreed to use it
in RESTCONF.

I agree there does not need to b= e a YANG definition for the attributes
used in RESTCONF protocol = messages.  The attribute definition could
be in an XSD. The = description annotation can specify the string to use
for the module name, for encoding as a qualified attribute in RESTCONF= .
(The YANG insert attributes are just defined in text, not even = an XSD).

There is no need to define any attributes= at all in YANG data model content.
It we do that, then it will be abused.  I want to support protoco= l layer attributes like
with-defaults (report-all-tagged) or cond= itional enablement (enabled).
The protocol spec should define pro= tocol attributes, not the data modeling language.

I have said before many times -- a mapping from YANG to= JSON is somewhat
useless because we don't sent JSON across t= he wire. We send protocol messages
encoded in JSON.  We need= a mapping that allows entire protocol messages to be encoded,
not just the YANG content layer.



Andy






/js

--
Juergen Schoenwaelder           Jacobs University = Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Br= emen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-universi= ty.de/>

--001a11c2cc180411aa04ff402031-- From nobody Mon Jul 28 05:36:38 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E257A1A01F6 for ; Mon, 28 Jul 2014 05:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ym30UEsIkSfO for ; Mon, 28 Jul 2014 05:36:36 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1AD1A0180 for ; Mon, 28 Jul 2014 05:36:35 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6255AFD0; Mon, 28 Jul 2014 14:36:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 80WYr5Wd817t; Mon, 28 Jul 2014 14:36:33 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 28 Jul 2014 14:36:33 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9CA2420017; Mon, 28 Jul 2014 14:36:33 +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 sxyT3uC7ldz6; Mon, 28 Jul 2014 14:36:32 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 207A42002F; Mon, 28 Jul 2014 14:36:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 579F82DFCB68; Mon, 28 Jul 2014 14:36:31 +0200 (CEST) Date: Mon, 28 Jul 2014 14:36:30 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140728123630.GB55631@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <20140728095501.GB55180@elstar.local> <20140728121328.GA55631@elstar.local> <1D814F6F-AC4B-4E27-AF5B-12156E3ABAF4@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1D814F6F-AC4B-4E27-AF5B-12156E3ABAF4@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/p334MWw-h_NFBdqok4_pxrKd3Ec Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jul 2014 12:36:37 -0000 On Mon, Jul 28, 2014 at 02:19:44PM +0200, Ladislav Lhotka wrote: > > On 28 Jul 2014, at 14:13, Juergen Schoenwaelder wrote: > > > I can counter argue that easily: If we do not do Y33, then there are > > no attributes and hence there is no need to encode them in JSON. Move > > the whole attribute encoding text into a non-normative appendix and we > > are done. > > Well, it needn’t be there at all because YANG doesn’t model attributes. Normative or not, without means for representing an attribute’s namespace it doesn’t make sense to have it there. > Yes. We can remove the text completely. That said, I got told that implementations sometimes use attributes and hence it might be useful to have agreement on some convention to support that. Checking the RESTCONF specification, I find this in Section 3.5: The RESTCONF protocol needs to retrieve the same meta-data that is used in the NETCONF protocol. Information about default leafs, last- modified timestamps, etc. are commonly used to annotate representations of the datastore contents. This meta-data is not defined in the YANG schema because it applies to the datastore, and is common across all data nodes. This information is encoded as attributes in XML. JSON encoding of meta-data is defined in [I-D.lhotka-netmod-json]. Checking RFC 6241, I find: error-message: Contains a string suitable for human display that describes the error condition. This element will not be present if no appropriate message is provided for a particular error condition. This element SHOULD include an "xml:lang" attribute as defined in [W3C.REC-xml-20001006] and discussed in [RFC3470]. Checking the RESTCONF specification, it seems the error-message becomes part of an ietf-restconf:errors object. Does it carry the xml:lang attribute forward? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jul 28 05:46:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72791A0197 for ; Mon, 28 Jul 2014 05:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1_xghMTA5_y for ; Mon, 28 Jul 2014 05:46:43 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C55CC1A0193 for ; Mon, 28 Jul 2014 05:46:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 915E11108 for ; Mon, 28 Jul 2014 14:46:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id rcHBry-7mSek for ; Mon, 28 Jul 2014 14:46:40 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 28 Jul 2014 14:46:41 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id EED7A2002C for ; Mon, 28 Jul 2014 14:46:40 +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 O_KgNI6M-GCa; Mon, 28 Jul 2014 14:46:40 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 737B420017; Mon, 28 Jul 2014 14:46:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 40A4D2DFCBE7; Mon, 28 Jul 2014 14:46:38 +0200 (CEST) Date: Mon, 28 Jul 2014 14:46:37 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140728124636.GA55746@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/KTVbeWdlzs-Lp4Mmweoxb75m5AY Subject: [netmod] yang 1.1 face-to-face interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jul 2014 12:46:44 -0000 Hi, during the WG meeting last week, a number of people indicated an interest to hold a face-to-face interim meeting in order to work on the more difficult issues of the YANG 1.1 revision (issues related to conformance, issues related to the separation of configuration datastore(s) and operational state). Below is a doodle poll for face-to-face interim meeting in mid September. The idea is to meet for at least two full days. Hence, this will either be Wed/Thu or Thu/Fri or if we go for more than two full days, it will be Wed/Thu/Fri (perhaps closing at lunch time so people can get a flight home). The location would be US east cost, Newark / New York area. http://doodle.com/7eptxb7mggtdhwmc Please indicate your availability. We need to act soon since a face-to-face interim needs to be announced at least four weeks before the event and they require AD approval. Please will out the doodle as soon as possible (ideally by July 30th) so that we have an indication whether the proposed time and location could work. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jul 28 05:49:01 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E121A0197 for ; Mon, 28 Jul 2014 05:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2qjtxkhv6kd for ; Mon, 28 Jul 2014 05:48:54 -0700 (PDT) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F33BF1A0185 for ; Mon, 28 Jul 2014 05:48:53 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id i13so7782171qae.34 for ; Mon, 28 Jul 2014 05:48:53 -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=PL6uJsVNMIKsw6y9eGjHlok0PH3ag98HwTW9qPNyVKY=; b=EGBPf5c/QbkNXNZup/X5epw4ChRT+LV0sliLgBxEiWKzTdDux81EPoUvmpOs+uksTP /rWE7IqZja7MiFy66qjaHc9PRzb1EyAveCjIXexDELJMk8uC6052pGCVXna9MMlCuuRO 7E9Yo1LQ3dHnToHCHgzzZ6AnWFp089fxWUtLmlC/UbHzdUWil51jNqqW4pkO4WrNea38 6Lr0Ul4UDggmiQpOzrSBnAiQez01hYx/5cthoEJULS33e7d+i8+oaqw5RoGjZtb6w7yg rmYwYqE0efABYmmcKp6v/MVvnpe/5napzEKwSoGByo9ZnnZf9VyilLkZ2G8kIhkVZE0C 0u8w== X-Gm-Message-State: ALoCoQnwOrfjq45hJ6kmRyncaVNbZLX2zHwNZ11GzqRKcTZRDPDCBWJk9IkeFXEpn0Yw6Tf3BgJ3 MIME-Version: 1.0 X-Received: by 10.224.112.1 with SMTP id u1mr57318318qap.7.1406551733131; Mon, 28 Jul 2014 05:48:53 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Mon, 28 Jul 2014 05:48:53 -0700 (PDT) In-Reply-To: <20140728123630.GB55631@elstar.local> References: <20140728095501.GB55180@elstar.local> <20140728121328.GA55631@elstar.local> <1D814F6F-AC4B-4E27-AF5B-12156E3ABAF4@nic.cz> <20140728123630.GB55631@elstar.local> Date: Mon, 28 Jul 2014 05:48:53 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=047d7b673a4e697bbe04ff4058dd Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/PFJd-sJaVB_qiZ3l_9pD9mhkM2I Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 12:48:56 -0000 --047d7b673a4e697bbe04ff4058dd Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 28, 2014 at 5:36 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Jul 28, 2014 at 02:19:44PM +0200, Ladislav Lhotka wrote: > > > > On 28 Jul 2014, at 14:13, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > > > I can counter argue that easily: If we do not do Y33, then there are > > > no attributes and hence there is no need to encode them in JSON. Move > > > the whole attribute encoding text into a non-normative appendix and we > > > are done. > > > > Well, it needn't be there at all because YANG doesn't model attributes. > Normative or not, without means for representing an attribute's namespace > it doesn't make sense to have it there. > > > > Yes. We can remove the text completely. That said, I got told that > implementations sometimes use attributes and hence it might be useful > to have agreement on some convention to support that. > > Checking the RESTCONF specification, I find this in Section 3.5: > > The RESTCONF protocol needs to retrieve the same meta-data that is > used in the NETCONF protocol. Information about default leafs, last- > modified timestamps, etc. are commonly used to annotate > representations of the datastore contents. This meta-data is not > defined in the YANG schema because it applies to the datastore, and > is common across all data nodes. > > This information is encoded as attributes in XML. JSON encoding of > meta-data is defined in [I-D.lhotka-netmod-json]. > > Checking RFC 6241, I find: > > error-message: Contains a string suitable for human display that > describes the error condition. This element will not be present > if no appropriate message is provided for a particular error > condition. This element SHOULD include an "xml:lang" attribute as > defined in [W3C.REC-xml-20001006] and discussed in [RFC3470]. > > Checking the RESTCONF specification, it seems the error-message > becomes part of an ietf-restconf:errors object. Does it carry the > xml:lang attribute forward? > > I think this could be considered an open issue because Lada did not want to include it (but I do). I know the name has "xml" in it, and so does "anyxml". NETCONF does not allowed XML mixed mode content. RESTCONF needs the same disclaimer. In NETCONF-EX there is an "encoding" capability excahnge. Somebody might even be crazy enough to encode NETCONF in JSON, just to cut the msg size in half. (But NETCONF is only for giant routers, so why do that! :-) /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --047d7b673a4e697bbe04ff4058dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jul 28, 2014 at 5:36 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Jul 28, 2014 at 02:19:44PM +0200, La= dislav Lhotka wrote:
>
> On 28 Jul 2014, at 14:13, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<= /a>> wrote:
>
> > I can counter argue that easily: If we do not do Y33, then there = are
> > no attributes and hence there is no need to encode them in JSON. = Move
> > the whole attribute encoding text into a non-normative appendix a= nd we
> > are done.
>
> Well, it needn’t be there at all because YANG doesn’t mode= l attributes. Normative or not, without means for representing an attribute= ’s namespace it doesn’t make sense to have it there.
>

Yes. We can remove the text completely. That said, I got told that
implementations sometimes use attributes and hence it might be useful
to have agreement on some convention to support that.

Checking the RESTCONF specification, I find this in Section 3.5:

   The RESTCONF protocol needs to retrieve the same meta-data tha= t is
   used in the NETCONF protocol.  Information about default = leafs, last-
   modified timestamps, etc. are commonly used to annotate
   representations of the datastore contents.  This meta-dat= a is not
   defined in the YANG schema because it applies to the datastore= , and
   is common across all data nodes.

   This information is encoded as attributes in XML.  JSON e= ncoding of
   meta-data is defined in [I-D.lhotka-netmod-json].

Checking RFC 6241, I find:

   error-message:  Contains a string suitable for human disp= lay that
      describes the error condition.  This element will= not be present
      if no appropriate message is provided for a particular= error
      condition.  This element SHOULD include an "= xml:lang" attribute as
      defined in [W3C.REC-xml-20001006] and discussed in [RF= C3470].

Checking the RESTCONF specification, it seems the error-message
becomes part of an ietf-restconf:errors object. Does it carry the
xml:lang attribute forward?


I think this could be considered an open issue becau= se Lada did not
want to include it (but I do).  I know the n= ame has "xml" in it, and
so does "anyxml".  NETCONF does not allowed XML mixed m= ode
content. RESTCONF needs the same disclaimer.

--047d7b673a4e697bbe04ff4058dd-- From nobody Mon Jul 28 06:10:42 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E365D1A04A7 for ; Mon, 28 Jul 2014 06:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYAj1t-p7zWj for ; Mon, 28 Jul 2014 06:10:37 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7857C1A0059 for ; Mon, 28 Jul 2014 06:10:37 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 76695140075; Mon, 28 Jul 2014 15:10:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1406553033; bh=kWfZdWN50EHvXSxNlsopWOgHYZLA+AX+d6PYyn5/NHw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Nm31JLiUu+TMWe7InO0e4AJYzjrCmT1l7ceLPula3F+bzxrUn0U62No022tpk5Ygt in7S9txA7l+edr2Zh0WKuGDTVqMR14ph2FOjmJMsEenWAvFrX7gY4dWGFc17VFwWDl A66n/M927TNwSUoPrmp1oFQdXI7OVT6h48TyozNY= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 28 Jul 2014 15:10:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5392C525-EB34-4E8A-BB39-B1464E4DE4C9@nic.cz> References: <20140728095501.GB55180@elstar.local> <20140728121328.GA55631@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/HES5zAZL396pK1Ua29JC8mlzt0s Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 13:10:40 -0000 On 28 Jul 2014, at 14:33, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Jul 28, 2014 at 5:13 AM, Juergen Schoenwaelder = wrote: > On Mon, Jul 28, 2014 at 02:06:30PM +0200, Ladislav Lhotka wrote: > > >=20 > > But then, IMO, the cleanest way is to make this explicit by using = the =93attribute=94 statement which > > > > - assigns the attribute to a module, > > - also assigns the namespace URI and recommended prefix for XML = encoding, > > - defines a datatype for the attribute, which may occasionally be = useful. > > > > I=92d like to emphasize that Y33 was only about global attributes, = i.e. it doesn=92t attempt to make attributes into regular data nodes, so = the following would NOT be possible: > > > > leaf flag { > > attribute foo {=85} > > =85 > > } >=20 > I can counter argue that easily: If we do not do Y33, then there are > no attributes and hence there is no need to encode them in JSON. Move > the whole attribute encoding text into a non-normative appendix and we > are done. >=20 >=20 > Several people want to support attributes in the RESTCONF protocol = messages. > Martin came up with a solution that works and we already agreed to use = it > in RESTCONF. This doesn=92t necessarily mean it has to be part of = draft-ietf-netmod-yang-json. >=20 > I agree there does not need to be a YANG definition for the attributes > used in RESTCONF protocol messages. The attribute definition could > be in an XSD. The description annotation can specify the string to use > for the module name, for encoding as a qualified attribute in = RESTCONF. To serve this purpose for standard attributes such as =93active=94 , the = module name should be registered with IANA, and I am not sure it was = intended to allow for registrations of non-existing modules. If so, then = I am fine with that. > (The YANG insert attributes are just defined in text, not even an = XSD). >=20 > There is no need to define any attributes at all in YANG data model = content. > It we do that, then it will be abused. I want to support protocol = layer attributes like > with-defaults (report-all-tagged) or conditional enablement (enabled). > The protocol spec should define protocol attributes, not the data = modeling language. OK, so then the protocol can also specify their ad hoc encoding in JSON. = I=92ve been saying this all the time but you and Martin insisted on = having the generic attribute mapping in the yang-json I-D. I should have = resisted. :-) >=20 > I have said before many times -- a mapping from YANG to JSON is = somewhat > useless because we don't sent JSON across the wire. We send protocol = messages > encoded in JSON. We need a mapping that allows entire protocol = messages to be encoded, > not just the YANG content layer. In fact, YANG only defines the schema and constraints for datastores, = where RPCs and notifications can be considered special types of = datastores. It is only for historical reasons that RFC 6020 also includes = specification for the encoding of NETCONF messages. RESTCONF (or I2RS or = whatever) protocol messages are not included there and, consequently, = every new protocol has to specify how the datastore contents and their = fragments are mapped to various protocol messages, be it XML or JSON. I = think this is fully appropriate. In fact, if we want to make YANG 1.1 = less NETCONF-centric, the NETCONF-specific parts should be put into a = separate document. Lada >=20 >=20 >=20 > Andy >=20 >=20 >=20 >=20 >=20 >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jul 28 06:32:27 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9958F1A01D5 for ; Mon, 28 Jul 2014 06:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOorPJY7p7JZ for ; Mon, 28 Jul 2014 06:32:22 -0700 (PDT) Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF761A01AC for ; Mon, 28 Jul 2014 06:32:21 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id z60so8531364qgd.41 for ; Mon, 28 Jul 2014 06:32:20 -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=gr/j8xPUwHRQ/T70BB61P4NZpRssEwgQkiGcu5H8XXY=; b=V6s++1eU3rl+zHEIY+I3EBtJDm1Abtc5tbNsgrkBoMZyK4s3UWUsPnnb7CHmLCZpJy gMcCDHTkg799uXsUSluc5SQgSO7OkCsP6REaVKnC6r1jZKuA6rYbRc7wRNl+unHUPr2C 5+1e36HIx+thFANhIOS/Q450IFoil/jD2+sYmGtKweJRQ0fpA+8nFQmmtf12+e4BX+ZU qXvMAV0jfyF/XBaGewz99QVLcDQnd7WOxAi1hWPoYaYzI+tvULqntXBPNLJ1O8lAfZYB Qnod18/e9qYWDu/nPAtt9m0IENg8FULm1AHa5zrhwBtfLuXGuSDS9ileWLnksagX1Gfi LGow== X-Gm-Message-State: ALoCoQk4cK2UMXUjkRT56evDkDRCwhwi4w4lzwAzZ1UE4LUnQ/TccFSqyGgDdQ1GN0tzsRfPnTle MIME-Version: 1.0 X-Received: by 10.224.127.74 with SMTP id f10mr8492629qas.100.1406554340735; Mon, 28 Jul 2014 06:32:20 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Mon, 28 Jul 2014 06:32:20 -0700 (PDT) In-Reply-To: <5392C525-EB34-4E8A-BB39-B1464E4DE4C9@nic.cz> References: <20140728095501.GB55180@elstar.local> <20140728121328.GA55631@elstar.local> <5392C525-EB34-4E8A-BB39-B1464E4DE4C9@nic.cz> Date: Mon, 28 Jul 2014 06:32:20 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c2cc18d65c9f04ff40f347 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ICOwNFSyHCAvMQUL3ul0x_xLTVA Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 13:32:25 -0000 --001a11c2cc18d65c9f04ff40f347 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 28, 2014 at 6:10 AM, Ladislav Lhotka wrote: > > On 28 Jul 2014, at 14:33, Andy Bierman wrote: > > > > > > > > > On Mon, Jul 28, 2014 at 5:13 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > On Mon, Jul 28, 2014 at 02:06:30PM +0200, Ladislav Lhotka wrote: > > > > > > > > But then, IMO, the cleanest way is to make this explicit by using the > "attribute" statement which > > > > > > - assigns the attribute to a module, > > > - also assigns the namespace URI and recommended prefix for XML > encoding, > > > - defines a datatype for the attribute, which may occasionally be > useful. > > > > > > I'd like to emphasize that Y33 was only about global attributes, i.e. > it doesn't attempt to make attributes into regular data nodes, so the > following would NOT be possible: > > > > > > leaf flag { > > > attribute foo {...} > > > ... > > > } > > > > I can counter argue that easily: If we do not do Y33, then there are > > no attributes and hence there is no need to encode them in JSON. Move > > the whole attribute encoding text into a non-normative appendix and we > > are done. > > > > > > Several people want to support attributes in the RESTCONF protocol > messages. > > Martin came up with a solution that works and we already agreed to use it > > in RESTCONF. > > This doesn't necessarily mean it has to be part of > draft-ietf-netmod-yang-json. > > It was in the RESTCONF draft, and then we agreed to move it to the JSON draft. I guess we really need an issue tracker ASAP because we keep debating the same issues over and over. > > > > I agree there does not need to be a YANG definition for the attributes > > used in RESTCONF protocol messages. The attribute definition could > > be in an XSD. The description annotation can specify the string to use > > for the module name, for encoding as a qualified attribute in RESTCONF. > > To serve this purpose for standard attributes such as "active" , the > module name should be registered with IANA, and I am not sure it was > intended to allow for registrations of non-existing modules. If so, then I > am fine with that. > > The YANG attributes (insert, value, key) are in YANG XML namespace (URI in sec. 5.3.1). This is not a YANG module namespace. > (The YANG insert attributes are just defined in text, not even an XSD). > > > > There is no need to define any attributes at all in YANG data model > content. > > It we do that, then it will be abused. I want to support protocol layer > attributes like > > with-defaults (report-all-tagged) or conditional enablement (enabled). > > The protocol spec should define protocol attributes, not the data > modeling language. > > OK, so then the protocol can also specify their ad hoc encoding in JSON. > I've been saying this all the time but you and Martin insisted on having > the generic attribute mapping in the yang-json I-D. I should have resisted. > :-) > The WG already decided to move this text from RESTCONF to the JSON draft. So what new arguments are you presenting that justify re-opening this issue? > > > > > I have said before many times -- a mapping from YANG to JSON is somewhat > > useless because we don't sent JSON across the wire. We send protocol > messages > > encoded in JSON. We need a mapping that allows entire protocol messages > to be encoded, > > not just the YANG content layer. > > In fact, YANG only defines the schema and constraints for datastores, > where RPCs and notifications can be considered special types of datastores. > > IMO there is no such architectural purity here. The intent is to support an RPC message model and event notification messages. > It is only for historical reasons that RFC 6020 also includes > specification for the encoding of NETCONF messages. RESTCONF (or I2RS or > whatever) protocol messages are not included there and, consequently, every > new protocol has to specify how the datastore contents and their fragments > are mapped to various protocol messages, be it XML or JSON. I think this is > fully appropriate. In fact, if we want to make YANG 1.1 less > NETCONF-centric, the NETCONF-specific parts should be put into a separate > document. > > Lada > > > > > > > > > Andy > > > Andy > > > > > > > > > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11c2cc18d65c9f04ff40f347 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jul 28, 2014 at 6:10 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On 28 Jul 2014, at 14:33, Andy Bierman <andy@yumaworks.com> wrote:

>
>
>
> On Mon, Jul 28, 2014 at 5:13 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-univers= ity.de> wrote:
> On Mon, Jul 28, 2014 at 02:06:30PM +0200, Ladislav Lhotka wrote:
> >
>
> > But then, IMO, the cleanest way is to make this explicit by using= the “attribute” statement which
> >
> > - assigns the attribute to a module,
> > - also assigns the namespace URI and recommended prefix for XML e= ncoding,
> > - defines a datatype for the attribute, which may occasionally be= useful.
> >
> > I’d like to emphasize that Y33 was only about global attrib= utes, i.e. it doesn’t attempt to make attributes into regular data no= des, so the following would NOT be possible:
> >
> > leaf flag {
> >     attribute foo {…}
> >     …
> > }
>
> I can counter argue that easily: If we do not do Y33, then there are > no attributes and hence there is no need to encode them in JSON. Move<= br> > the whole attribute encoding text into a non-normative appendix and we=
> are done.
>
>
> Several people want to support attributes in the RESTCONF protocol mes= sages.
> Martin came up with a solution that works and we already agreed to use= it
> in RESTCONF.

This doesn’t necessarily mean it has to be part of draft-ietf-netmod-= yang-json.


It was in the RESTCONF draft, and then= we agreed to move it to the JSON draft.
I guess we really need a= n issue tracker ASAP because we keep debating the
same issues ove= r and over.


 
>
> I agree there does not need to be a YANG definition for the attributes=
> used in RESTCONF protocol messages.  The attribute definition cou= ld
> be in an XSD. The description annotation can specify the string to use=
> for the module name, for encoding as a qualified attribute in RESTCONF= .

To serve this purpose for standard attributes such as “active” = , the module name should be registered with IANA, and I am not sure it was = intended to allow for registrations of non-existing modules. If so, then I = am fine with that.


The YANG attributes (insert, value, ke= y) are in YANG XML namespace
(URI in sec. 5.3.1). This is not a Y= ANG module namespace.


> (The YANG insert attributes are just defined in text, not even an XSD)= .
>
> There is no need to define any attributes at all in YANG data model co= ntent.
> It we do that, then it will be abused.  I want to support protoco= l layer attributes like
> with-defaults (report-all-tagged) or conditional enablement (enabled).=
> The protocol spec should define protocol attributes, not the data mode= ling language.

OK, so then the protocol can also specify their ad hoc encoding in JSON. I&= rsquo;ve been saying this all the time but you and Martin insisted on havin= g the generic attribute mapping in the yang-json I-D. I should have resiste= d. :-)


The WG already decided to m= ove this text from RESTCONF to the JSON draft.
So what new argume= nts are you presenting that justify re-opening this issue?
 =

>
> I have said before many times -- a mapping from YANG to JSON is somewh= at
> useless because we don't sent JSON across the wire. We send protoc= ol messages
> encoded in JSON.  We need a mapping that allows entire protocol m= essages to be encoded,
> not just the YANG content layer.

In fact, YANG only defines the schema and constraints for datastores, where= RPCs and notifications can be considered special types of datastores.


IMO there is no such architectural pur= ity here.
The intent is to support an RPC message model and event= notification messages.
 
>
>
>
>
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs Univer= sity Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 287= 59 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-u= niversity.de/>
>

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--001a11c2cc18d65c9f04ff40f347-- From nobody Mon Jul 28 07:17:30 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48EDB1A0452 for ; Mon, 28 Jul 2014 07:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elflIcpjHqrK for ; Mon, 28 Jul 2014 07:17:26 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29EBB1A03F5 for ; Mon, 28 Jul 2014 07:17:25 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 4AB3913FCD8; Mon, 28 Jul 2014 16:17:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1406557043; bh=0Qr+dnhGosuWM8ZjrHk/PmP3iOK4CYpJbOb21vLFnaE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=YMkPxcfxxiIg6RkmUzJ0QqAY5rlCoZeEEjcqO+r2S8ziRwWZM4TFida/2v/5nwNjD So1FliiQDbhXEuLBMkq4rhbSynnIpfJg4zjkh0rNha2J3DjsRrddS5giXPU7UAXSXl BxgeG6QJYWYOa07hMu4RSA4grRtbhpAhYNtPMsfM= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 28 Jul 2014 16:17:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140728095501.GB55180@elstar.local> <20140728121328.GA55631@elstar.local> <5392C525-EB34-4E8A-BB39-B1464E4DE4C9@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/reNk4AzagScuwsTJa7pDfgP4lAE Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 14:17:28 -0000 On 28 Jul 2014, at 15:32, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Jul 28, 2014 at 6:10 AM, Ladislav Lhotka = wrote: >=20 > On 28 Jul 2014, at 14:33, Andy Bierman wrote: >=20 > > > > > > > > On Mon, Jul 28, 2014 at 5:13 AM, Juergen Schoenwaelder = wrote: > > On Mon, Jul 28, 2014 at 02:06:30PM +0200, Ladislav Lhotka wrote: > > > > > > > > But then, IMO, the cleanest way is to make this explicit by using = the =93attribute=94 statement which > > > > > > - assigns the attribute to a module, > > > - also assigns the namespace URI and recommended prefix for XML = encoding, > > > - defines a datatype for the attribute, which may occasionally be = useful. > > > > > > I=92d like to emphasize that Y33 was only about global attributes, = i.e. it doesn=92t attempt to make attributes into regular data nodes, so = the following would NOT be possible: > > > > > > leaf flag { > > > attribute foo {=85} > > > =85 > > > } > > > > I can counter argue that easily: If we do not do Y33, then there are > > no attributes and hence there is no need to encode them in JSON. = Move > > the whole attribute encoding text into a non-normative appendix and = we > > are done. > > > > > > Several people want to support attributes in the RESTCONF protocol = messages. > > Martin came up with a solution that works and we already agreed to = use it > > in RESTCONF. >=20 > This doesn=92t necessarily mean it has to be part of = draft-ietf-netmod-yang-json. >=20 >=20 > It was in the RESTCONF draft, and then we agreed to move it to the = JSON draft. > I guess we really need an issue tracker ASAP because we keep debating = the > same issues over and over. >=20 >=20 > =20 > > > > I agree there does not need to be a YANG definition for the = attributes > > used in RESTCONF protocol messages. The attribute definition could > > be in an XSD. The description annotation can specify the string to = use > > for the module name, for encoding as a qualified attribute in = RESTCONF. >=20 > To serve this purpose for standard attributes such as =93active=94 , = the module name should be registered with IANA, and I am not sure it was = intended to allow for registrations of non-existing modules. If so, then = I am fine with that. >=20 >=20 > The YANG attributes (insert, value, key) are in YANG XML namespace > (URI in sec. 5.3.1). This is not a YANG module namespace. >=20 How does RESTCONF encode these attributes in JSON? >=20 > > (The YANG insert attributes are just defined in text, not even an = XSD). > > > > There is no need to define any attributes at all in YANG data model = content. > > It we do that, then it will be abused. I want to support protocol = layer attributes like > > with-defaults (report-all-tagged) or conditional enablement = (enabled). > > The protocol spec should define protocol attributes, not the data = modeling language. >=20 > OK, so then the protocol can also specify their ad hoc encoding in = JSON. I=92ve been saying this all the time but you and Martin insisted = on having the generic attribute mapping in the yang-json I-D. I should = have resisted. :-) >=20 >=20 > The WG already decided to move this text from RESTCONF to the JSON = draft. I haven=92t seen any evidence of this being a WG decision. That=92s why = the first question in my presentation in Toronto was Is this draft an appropriate place for defining metadata encoding in = JSON? and I didn=92t notice any consensus about this in the room. In the = relevant thread http://www.ietf.org/mail-archive/web/netmod/current/msg09338.html only you and Martin wanted to have the mapping in the yang-json draft = but Martin also said = (http://www.ietf.org/mail-archive/web/netmod/current/msg09350.html): Maybe the original JSON mapping idea is the only one that works; = i.e., map pure YANG data to JSON. No meta data. A protocol that needs = meta data should not use JSON; use XML instead. > So what new arguments are you presenting that justify re-opening this = issue? The lack of namespace mapping. Lada > =20 >=20 > > > > I have said before many times -- a mapping from YANG to JSON is = somewhat > > useless because we don't sent JSON across the wire. We send protocol = messages > > encoded in JSON. We need a mapping that allows entire protocol = messages to be encoded, > > not just the YANG content layer. >=20 > In fact, YANG only defines the schema and constraints for datastores, = where RPCs and notifications can be considered special types of = datastores. >=20 >=20 > IMO there is no such architectural purity here. > The intent is to support an RPC message model and event notification = messages. > =20 > It is only for historical reasons that RFC 6020 also includes = specification for the encoding of NETCONF messages. RESTCONF (or I2RS or = whatever) protocol messages are not included there and, consequently, = every new protocol has to specify how the datastore contents and their = fragments are mapped to various protocol messages, be it XML or JSON. I = think this is fully appropriate. In fact, if we want to make YANG 1.1 = less NETCONF-centric, the NETCONF-specific parts should be put into a = separate document. >=20 > Lada >=20 > > > > > > > > Andy > > >=20 >=20 > Andy > =20 > > > > > > > > > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jul 28 07:54:52 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27651B2856 for ; Mon, 28 Jul 2014 07:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyqlckdKTW9f for ; Mon, 28 Jul 2014 07:54:46 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F78D1B285B for ; Mon, 28 Jul 2014 07:54:46 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id dc16so8005012qab.36 for ; Mon, 28 Jul 2014 07:54:45 -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=2qCuyrwvpEiRZPkiNFp7GI8vNXRlURSoLWoSQEIjDXQ=; b=CBQhzCvASsAI6ZLWMBXqPLkk91w2Y6lV+xqfZO1xn8FpnFVpBgb/I1dHBPtnbc3ReD ZW7sKhqY9ne4tt4MkK2atX/BBUZCnDfuK1m0CzolHVcZvygPeldVHKE3p+lv8LMIT4HI 7Bhpar1xCX7LGcmTzZPzBErE8yYPE9xyFaAzJeSo5vHlnYfezlOYkmfvyTybrH7Jjwrq Yvn511kMWFYu+w7CFfuJlM2qUMbrADDE5kKrz2qe+cM83rBb3vI6peDyzQtt7OK+kWdv TIp6LKm2Nm2GAFKhpLLaU1cJpcQdepvemfM0cdvYkbPXZIiuQd8iGQNz8XDXPcz5ucm+ goXg== X-Gm-Message-State: ALoCoQk/C+t0a70kGXCrRqF+owbYqP5VdYR8Tez+/y6ur/kkfXu2mhJq0hAsDtsD4Mkskh048eMy MIME-Version: 1.0 X-Received: by 10.140.85.101 with SMTP id m92mr62524963qgd.26.1406559285682; Mon, 28 Jul 2014 07:54:45 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Mon, 28 Jul 2014 07:54:45 -0700 (PDT) In-Reply-To: References: <20140728095501.GB55180@elstar.local> <20140728121328.GA55631@elstar.local> <5392C525-EB34-4E8A-BB39-B1464E4DE4C9@nic.cz> Date: Mon, 28 Jul 2014 07:54:45 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c155ea94abc104ff421a3a Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/bcNqf8Maak6uTboo39X9U_D7GHg Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 14:54:50 -0000 --001a11c155ea94abc104ff421a3a Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 28, 2014 at 7:17 AM, Ladislav Lhotka wrote: > > On 28 Jul 2014, at 15:32, Andy Bierman wrote: > > > > > > > > > On Mon, Jul 28, 2014 at 6:10 AM, Ladislav Lhotka wrote: > > > > On 28 Jul 2014, at 14:33, Andy Bierman wrote: > > > > > > > > > > > > > > On Mon, Jul 28, 2014 at 5:13 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Mon, Jul 28, 2014 at 02:06:30PM +0200, Ladislav Lhotka wrote: > > > > > > > > > > > But then, IMO, the cleanest way is to make this explicit by using > the "attribute" statement which > > > > > > > > - assigns the attribute to a module, > > > > - also assigns the namespace URI and recommended prefix for XML > encoding, > > > > - defines a datatype for the attribute, which may occasionally be > useful. > > > > > > > > I'd like to emphasize that Y33 was only about global attributes, > i.e. it doesn't attempt to make attributes into regular data nodes, so the > following would NOT be possible: > > > > > > > > leaf flag { > > > > attribute foo {...} > > > > ... > > > > } > > > > > > I can counter argue that easily: If we do not do Y33, then there are > > > no attributes and hence there is no need to encode them in JSON. Move > > > the whole attribute encoding text into a non-normative appendix and we > > > are done. > > > > > > > > > Several people want to support attributes in the RESTCONF protocol > messages. > > > Martin came up with a solution that works and we already agreed to use > it > > > in RESTCONF. > > > > This doesn't necessarily mean it has to be part of > draft-ietf-netmod-yang-json. > > > So if it was moved to a different document, that would be OK? Vendors will implement the standard if there is one. If not, the features vendors need will get implemented anyway, but proprietary schemes. > > > > It was in the RESTCONF draft, and then we agreed to move it to the JSON > draft. > > I guess we really need an issue tracker ASAP because we keep debating the > > same issues over and over. > > > > > > > > > > > > I agree there does not need to be a YANG definition for the attributes > > > used in RESTCONF protocol messages. The attribute definition could > > > be in an XSD. The description annotation can specify the string to use > > > for the module name, for encoding as a qualified attribute in RESTCONF. > > > > To serve this purpose for standard attributes such as "active" , the > module name should be registered with IANA, and I am not sure it was > intended to allow for registrations of non-existing modules. If so, then I > am fine with that. > > > The protocol spec that defines the datastore meta-data will define it so it works with that protocol. > > > > The YANG attributes (insert, value, key) are in YANG XML namespace > > (URI in sec. 5.3.1). This is not a YANG module namespace. > > > > How does RESTCONF encode these attributes in JSON? > > They are query parameters in the URL or YANG Patch is used instead > > > > > (The YANG insert attributes are just defined in text, not even an XSD). > > > > > > There is no need to define any attributes at all in YANG data model > content. > > > It we do that, then it will be abused. I want to support protocol > layer attributes like > > > with-defaults (report-all-tagged) or conditional enablement (enabled). > > > The protocol spec should define protocol attributes, not the data > modeling language. > > > > OK, so then the protocol can also specify their ad hoc encoding in JSON. > I've been saying this all the time but you and Martin insisted on having > the generic attribute mapping in the yang-json I-D. I should have resisted. > :-) > > > > > > The WG already decided to move this text from RESTCONF to the JSON draft. > > I haven't seen any evidence of this being a WG decision. That's why the > first question in my presentation in Toronto was > > Is this draft an appropriate place for defining metadata encoding in > JSON? > > and I didn't notice any consensus about this in the room. In the relevant > thread > > http://www.ietf.org/mail-archive/web/netmod/current/msg09338.html > > only you and Martin wanted to have the mapping in the yang-json draft but > Martin also said ( > http://www.ietf.org/mail-archive/web/netmod/current/msg09350.html): > > Maybe the original JSON mapping idea is the only one that works; > i.e., > map pure YANG data to JSON. No meta data. A protocol that needs > meta > data should not use JSON; use XML instead. > > > > So what new arguments are you presenting that justify re-opening this > issue? > > The lack of namespace mapping. > > The RFC that defines any protocol attributes for RESTCONF can define a YANG module if they want, so there is a module name to specify in the ad-hoc or XSD text. RFC 6020bis can easily register a standard module name that goes with the YANG XML namespace if the insert attributes ever need to be supported (and there is desire to make sure YANG is not XML-specific). Your draft just needs to say that the field contains a YANG module name. > Lada > > Andy > > > > > > > > > > I have said before many times -- a mapping from YANG to JSON is > somewhat > > > useless because we don't sent JSON across the wire. We send protocol > messages > > > encoded in JSON. We need a mapping that allows entire protocol > messages to be encoded, > > > not just the YANG content layer. > > > > In fact, YANG only defines the schema and constraints for datastores, > where RPCs and notifications can be considered special types of datastores. > > > > > > IMO there is no such architectural purity here. > > The intent is to support an RPC message model and event notification > messages. > > > > It is only for historical reasons that RFC 6020 also includes > specification for the encoding of NETCONF messages. RESTCONF (or I2RS or > whatever) protocol messages are not included there and, consequently, every > new protocol has to specify how the datastore contents and their fragments > are mapped to various protocol messages, be it XML or JSON. I think this is > fully appropriate. In fact, if we want to make YANG 1.1 less > NETCONF-centric, the NETCONF-specific parts should be put into a separate > document. > > > > Lada > > > > > > > > > > > > > > Andy > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > > Fax: +49 421 200 3103 > > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11c155ea94abc104ff421a3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jul 28, 2014 at 7:17 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On 28 Jul 2014, at 15:32, Andy Bierman <andy@yumaworks.com> wrote:

>
>
>
> On Mon, Jul 28, 2014 at 6:10 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> On 28 Jul 2014, at 14:33, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> >
> > On Mon, Jul 28, 2014 at 5:13 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-un= iversity.de> wrote:
> > On Mon, Jul 28, 2014 at 02:06:30PM +0200, Ladislav Lhotka wrote:<= br> > > >
> >
> > > But then, IMO, the cleanest way is to make this explicit by = using the “attribute” statement which
> > >
> > > - assigns the attribute to a module,
> > > - also assigns the namespace URI and recommended prefix for = XML encoding,
> > > - defines a datatype for the attribute, which may occasional= ly be useful.
> > >
> > > I’d like to emphasize that Y33 was only about global a= ttributes, i.e. it doesn’t attempt to make attributes into regular da= ta nodes, so the following would NOT be possible:
> > >
> > > leaf flag {
> > >     attribute foo {…}
> > >     …
> > > }
> >
> > I can counter argue that easily: If we do not do Y33, then there = are
> > no attributes and hence there is no need to encode them in JSON. = Move
> > the whole attribute encoding text into a non-normative appendix a= nd we
> > are done.
> >
> >
> > Several people want to support attributes in the RESTCONF protoco= l messages.
> > Martin came up with a solution that works and we already agreed t= o use it
> > in RESTCONF.
>
> This doesn’t necessarily mean it has to be part of draft-ietf-ne= tmod-yang-json.
>


So if it was moved = to a different document, that would be OK?
Vendors will implement= the standard if there is one.  If not,
the features vendors= need will get implemented anyway,
but proprietary schemes.

 
>
> It was in the RESTCONF draft, and then we agreed to move it to the JSO= N draft.
> I guess we really need an issue tracker ASAP because we keep debating = the
> same issues over and over.
>
>
>
> >
> > I agree there does not need to be a YANG definition for the attri= butes
> > used in RESTCONF protocol messages.  The attribute definitio= n could
> > be in an XSD. The description annotation can specify the string t= o use
> > for the module name, for encoding as a qualified attribute in RES= TCONF.
>
> To serve this purpose for standard attributes such as “active&rd= quo; , the module name should be registered with IANA, and I am not sure it= was intended to allow for registrations of non-existing modules. If so, th= en I am fine with that.
>

The protocol spec that defines the= datastore meta-data will define it so
it works with that protoco= l.

 
>
> The YANG attributes (insert, value, key) are in YANG XML namespace
> (URI in sec. 5.3.1). This is not a YANG module namespace.
>

How does RESTCONF encode these attributes in JSON?


They are query parameters in the URL o= r YANG Patch is used instead
 
>
> > (The YANG insert attributes are just defined in text, not even an= XSD).
> >
> > There is no need to define any attributes at all in YANG data mod= el content.
> > It we do that, then it will be abused.  I want to support pr= otocol layer attributes like
> > with-defaults (report-all-tagged) or conditional enablement (enab= led).
> > The protocol spec should define protocol attributes, not the data= modeling language.
>
> OK, so then the protocol can also specify their ad hoc encoding in JSO= N. I’ve been saying this all the time but you and Martin insisted on = having the generic attribute mapping in the yang-json I-D. I should have re= sisted. :-)
>
>
> The WG already decided to move this text from RESTCONF to the JSON dra= ft.

I haven’t seen any evidence of this being a WG decision. That’s= why the first question in my presentation in Toronto was

   Is this draft an appropriate place for defining metadata encod= ing in JSON?

and I didn’t notice any consensus about this in the room. In the rele= vant thread

http://www.ietf.org/mail-archive/web/netmod/current/ms= g09338.html

only you and Martin wanted to have the mapping in the yang-json draft but M= artin also said (http://www.ietf.org/mail-archive/web/= netmod/current/msg09350.html):

       Maybe the original JSON mapping idea is the only= one that works; i.e.,
       map pure YANG data to JSON.  No meta data. =  A protocol that needs meta
       data should not use JSON; use XML instead.


> So what new arguments are you presenting that justify re-opening this = issue?

The lack of namespace mapping.


The RFC that defines any protocol attr= ibutes for RESTCONF can define a YANG module
if they want, so the= re is a module name to specify in the ad-hoc or XSD text. 
<= br>
RFC 6020bis can easily register a standard module name
that goes with the YANG XML namespace if the insert attributes
e= ver need to be supported (and there is desire to make sure YANG
is not XML-specific).  Your draft just needs to say
that the= field contains a YANG module name.


 
Lada



Andy
 
>
>
> >
> > I have said before many times -- a mapping from YANG to JSON is s= omewhat
> > useless because we don't sent JSON across the wire. We send p= rotocol messages
> > encoded in JSON.  We need a mapping that allows entire proto= col messages to be encoded,
> > not just the YANG content layer.
>
> In fact, YANG only defines the schema and constraints for datastores, = where RPCs and notifications can be considered special types of datastores.=
>
>
> IMO there is no such architectural purity here.
> The intent is to support an RPC message model and event notification m= essages.
>
> It is only for historical reasons that RFC 6020 also includes specific= ation for the encoding of NETCONF messages. RESTCONF (or I2RS or whatever) = protocol messages are not included there and, consequently, every new proto= col has to specify how the datastore contents and their fragments are mappe= d to various protocol messages, be it XML or JSON. I think this is fully ap= propriate. In fact, if we want to make YANG 1.1 less NETCONF-centric, the N= ETCONF-specific parts should be put into a separate document.
>
> Lada
>
> >
> >
> >
> > Andy
> >
>
>
> Andy
>
> >
> >
> >
> >
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder           Jacobs U= niversity Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1= , 28759 Bremen, Germany
> > Fax:   +49 421 200 3103         <http://www.jacob= s-university.de/>
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--001a11c155ea94abc104ff421a3a-- From nobody Mon Jul 28 08:32:12 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A951B2892 for ; Mon, 28 Jul 2014 08:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2hp0Zdj3quh for ; Mon, 28 Jul 2014 08:32:07 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BF8D1B2890 for ; Mon, 28 Jul 2014 08:32:07 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 6CEB913F697; Mon, 28 Jul 2014 17:32:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1406561525; bh=fmvAChxA2gxu6mBVGy49YVlO/cmksWgKiaKPtacuxiw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=OEVXQJ4OYcYEl4VCFpBwV5b3uu+I5Q0LhczcdTjXdMMOGCl3PvpK9kn8WXxrkKSf+ lyq1dT78VLlOLknXSMz4d/z48F7iGih0Wv4NR5Rtwzvl8cZBoBWA2E3exZwV2CIKT3 P16n0LVLn5oXHi+6aTP3lt7++MoYcUaiVNybsdD4= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 28 Jul 2014 17:31:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140728095501.GB55180@elstar.local> <20140728121328.GA55631@elstar.local> <5392C525-EB34-4E8A-BB39-B1464E4DE4C9@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/TKQiy5mYBvxEvn9C5hW6PZdQBC8 Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 15:32:09 -0000 On 28 Jul 2014, at 16:54, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Jul 28, 2014 at 7:17 AM, Ladislav Lhotka = wrote: >=20 > On 28 Jul 2014, at 15:32, Andy Bierman wrote: >=20 > > > > > > > > On Mon, Jul 28, 2014 at 6:10 AM, Ladislav Lhotka = wrote: > > > > On 28 Jul 2014, at 14:33, Andy Bierman wrote: > > > > > > > > > > > > > > On Mon, Jul 28, 2014 at 5:13 AM, Juergen Schoenwaelder = wrote: > > > On Mon, Jul 28, 2014 at 02:06:30PM +0200, Ladislav Lhotka wrote: > > > > > > > > > > > But then, IMO, the cleanest way is to make this explicit by = using the =93attribute=94 statement which > > > > > > > > - assigns the attribute to a module, > > > > - also assigns the namespace URI and recommended prefix for XML = encoding, > > > > - defines a datatype for the attribute, which may occasionally = be useful. > > > > > > > > I=92d like to emphasize that Y33 was only about global = attributes, i.e. it doesn=92t attempt to make attributes into regular = data nodes, so the following would NOT be possible: > > > > > > > > leaf flag { > > > > attribute foo {=85} > > > > =85 > > > > } > > > > > > I can counter argue that easily: If we do not do Y33, then there = are > > > no attributes and hence there is no need to encode them in JSON. = Move > > > the whole attribute encoding text into a non-normative appendix = and we > > > are done. > > > > > > > > > Several people want to support attributes in the RESTCONF protocol = messages. > > > Martin came up with a solution that works and we already agreed to = use it > > > in RESTCONF. > > > > This doesn=92t necessarily mean it has to be part of = draft-ietf-netmod-yang-json. > > >=20 >=20 > So if it was moved to a different document, that would be OK? > Vendors will implement the standard if there is one. If not, > the features vendors need will get implemented anyway, > but proprietary schemes. As far as the yang-json draft is concerned, this would be OK. Attributes = aren=92t YANG data nodes. >=20 > > > > ... > > The WG already decided to move this text from RESTCONF to the JSON = draft. >=20 > I haven=92t seen any evidence of this being a WG decision. That=92s = why the first question in my presentation in Toronto was >=20 > Is this draft an appropriate place for defining metadata encoding = in JSON? >=20 > and I didn=92t notice any consensus about this in the room. In the = relevant thread >=20 > http://www.ietf.org/mail-archive/web/netmod/current/msg09338.html >=20 > only you and Martin wanted to have the mapping in the yang-json draft = but Martin also said = (http://www.ietf.org/mail-archive/web/netmod/current/msg09350.html): >=20 > Maybe the original JSON mapping idea is the only one that = works; i.e., > map pure YANG data to JSON. No meta data. A protocol that = needs meta > data should not use JSON; use XML instead. >=20 >=20 > > So what new arguments are you presenting that justify re-opening = this issue? >=20 > The lack of namespace mapping. >=20 >=20 > The RFC that defines any protocol attributes for RESTCONF can define a = YANG module > if they want, so there is a module name to specify in the ad-hoc or = XSD text.=20 >=20 > RFC 6020bis can easily register a standard module name > that goes with the YANG XML namespace if the insert attributes > ever need to be supported (and there is desire to make sure YANG > is not XML-specific). Your draft just needs to say > that the field contains a YANG module name. It should also specify how the association between an attribute and a = module is established, if the module says nothing about it, or even = doesn=92t exist at all. How do you find out which attributes are = associated with a given module? Can anybody add a new attribute to an = existing module at any time?=20 I really fail to see how a module-top-level =93attribute=94 statement = could possibly encourage misuse of attributes, I=92d say it=92s rather = the opposite. Having an explicit attribute definition with a description = and subject to revision rules of YANG modules etc. is IMO much better = than implicit and hand-waving associations. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jul 28 12:38:13 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC1C1A0B0C; Mon, 28 Jul 2014 12:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iayTYxFXOAjf; Mon, 28 Jul 2014 12:38:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BBACD1A03E8; Mon, 28 Jul 2014 12:38:10 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140728193810.14813.27118.idtracker@ietfa.amsl.com> Date: Mon, 28 Jul 2014 12:38:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/X_hZGmw3tq5AJoVaYcUMXMbS1Oo Cc: netmod@ietf.org Subject: [netmod] Last Call: (A YANG Data Model for SNMP Configuration) to Proposed Standard X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 19:38:12 -0000 The IESG has received a request from the NETCONF Data Modeling Language WG (netmod) to consider the following document: - 'A YANG Data Model for SNMP Configuration' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-08-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a collection of YANG definitions for configuring SNMP engines. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netmod-snmp-cfg/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netmod-snmp-cfg/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Jul 29 05:49:39 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C761A03EF for ; Tue, 29 Jul 2014 05:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtFfHNUpx_T2 for ; Tue, 29 Jul 2014 05:49:34 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0826C1A03F7 for ; Tue, 29 Jul 2014 05:49:34 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9F34A1038; Tue, 29 Jul 2014 14:49:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id n64JeeS45tT4; Tue, 29 Jul 2014 14:49:26 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 29 Jul 2014 14:49:31 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B94D2002C; Tue, 29 Jul 2014 14:49:31 +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 eEEbec_Q0Ulo; Tue, 29 Jul 2014 14:49: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 9EDA520017; Tue, 29 Jul 2014 14:49:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 920422DFDE8D; Tue, 29 Jul 2014 14:49:26 +0200 (CEST) Date: Tue, 29 Jul 2014 14:49:26 +0200 From: Juergen Schoenwaelder To: draft-bogdanovic-netmod-acl-model@tools.ietf.org Message-ID: <20140729124925.GC58615@elstar.local> Mail-Followup-To: draft-bogdanovic-netmod-acl-model@tools.ietf.org, netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/j6aoL2DveUTSWbOAi6yD4HDJczQ Cc: netmod@ietf.org Subject: [netmod] review of draft-bogdanovic-netmod-acl-model-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 29 Jul 2014 12:49:36 -0000 Hi, during the Sunday session before IETF 90, I got nominated to be the Yang Doctor for draft-bogdanovic-netmod-acl-model-01. And as a consequence, I have done a review of this I-D and since this was submitted as a contribution to the IETF, I thought I post the review right here. Note that many comments are not really Yang Doctors concerns but once I review a document, I often end up reviewing the whole thing. /js - If this document is supposed to be standards-track, then the intended status should not be "Informational". - The title should be more descriptive. Following recent YANG RFCs, perhaps something like "A YANG Data Model for Network Access Control List (ACL) Management". - I am not sure you define an information model and a data model. I think you define just a data model and hence you may want to update the abstract. And I am not sure what 'basic building blocks' means, perhaps expand on the approach taken (i.e. that it is a basic structure designed to be augmented). - The first paragraph on the introduction has singular/plural mismatches. - Run idnits and fix lines that are too long and split the references into normative and informative references and update any outdated references. - Section 2: s/that model can be/that the model can be/ s/Actions/actions/ s/that augmented/that can be augmented/ - Section 3: You say that a access control list containers an ordered set of rules. Why do you choose the term "Access Control Entry" instead of simply "Access Control Rule"? What is a _group of_ match and action criteria? Why is a prefix length meta data? I mean, how do you determine the source prefix length? According to a lookup in the local forwarding table(s)? Is this strictly speaking meta data or more precisely data derived from packet headers? s/daufault/default/ - Section 3.1: You can't write 'imports module "packet-headers" into the match container'. While you claim it is easy to reuse definitions of say IPFIX [RFC5101], I am not sure I see the details how this would work. Better work out the details and then leave the judgment whether it is easy or not to the reader. s/is example/is an example/ You may want to consider to describe the standard models in section 3 and to discuss proprietary extensions in a separate section or even an appendix to make it very clear which text is normative and which is not. - Section 4.1. s/Access/access/ Make sure the YANG module passes pyang --ietf checks. Also note that the description of the revision statement should refer to the document defining the data model. Note that the prefix does not have to carry 'ietf-'. (As you will see, shorter identifiers make path expressions shorter and much more readable.) Look at some other published data models to see how people usually format YANG data models. It wonder why access-list is a container, that is this is a singleton. In Linux, I can have multiple tables and multiple chains that contain multiple rules. And if this is a singleton, why do I need acl-name? Perhaps this was supposed to be a list keyed by acl-name? There is ongoing debate whether operational state mixed with config data is good or bad design. While I believe acl-oper-data is meant to be operational state, it is not marked as config false either. And note that the common terminology is operational state and not operational data. I do not know what a target in the leaf-list of targets are. The type just says string, which is a bit too open ended I guess. And it seems this is really configuration and not operational state, hence this might be misplaced? It seems the matching is rather limited per rule. This may be fine but seems at odd with a previous statement "Each ACE has a group of match criteria and a group of action criteria." It seems a rule (oops ACE) has a single simple match against header files and metadata and a single action it can trigger, no? The counters in ace-oper-data should at least be config false. - Section 4.2: The module needs to get a proper name that starts with ietf- and make sure things compile using pyang --ietf. Since the packet fields definitions may be reused, do not prefix them with acl- - in fact those prefixes are not really needed in YANG since you prefix identifiers when use them. Perhaps think about a shorter prefix than 'packet-fields'? Some fields need more description. Is it useful to represent the protocol by number? Should the ip-header-fields not include the ipv4/ipv6 header fields (e.g. in a choice)? Right now, the user of the definitions has to create and maintain the choice. I also note that the fields are called ...-address but the type is really a prefix. So the idea is that you match an address taken from the packet header against a prefix. I guess this (though perhaps obvious to us) should be explained in the missing description statements. [Note that the type for source-ipv6-address is ...-address - I guess this is a typo.] You should explain how address masking is supposed to work just to be clear everybody does the same thing. What about VLANs? Out of scope? What is the purpose of the absolute container of the timerange definition? There is no other timerange defined. The description of 'active' is somewhat confusing. While the Internet ages, we see interesting layerings coming along. (I do not want to mention WebRTC.) How does your framework apply to tunnels etc? I assume all this applies only to the outer headers and I can't say filter IP in IP encapsulated traffic with it. That is fine but supposed I need to, can I extend this easily? A bigger question I have is how the 'packet-header' module (needs a better name) is being maintained. Is this cast into stone via an RFC and then RFC update rules apply? Or is this to be maintained by IANA with a careful review process? And if changes are made, how does a client figure out which set of filters an implementation supports? Do we need to define suitable features? Are features sufficient - what happens if I add say flow-label to the IP header fields? Should things perhaps be split into several modules, one for Ethernet header matching, one for IP header matching, one for transport header matching to make updates and maintenance easier? - Section 4.3: I do not understand the 'range' enum of the match-simple-payload-protocol-value grouping. - Several citations are duplicated in the text, such as [RFC6241] [RFC6241]. - Section 4.4 should use IP addresses reserved for examples and not just 1.1.1.1 and 2.2.2.2. I am also not sure that showing some random proprietary CLI is a good way of describing an example in an I-D - simple remove Figure 1. In Figure 2, I would remove all the edit-config noise and focus only on the config data. That said, I am not sure what is nor am I convinced you got the namespaces right. Make sure you validate your examples against the data model. (See the pyang tutorial on how to do that.) - Section 5 probably needs to be expanded. Linux has tables, chains, and rules and it would be nice to document how things actually map to the concepts in the propose data model. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Jul 29 06:41:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC721B2873 for ; Tue, 29 Jul 2014 06:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ogb_ivZ44TK2 for ; Tue, 29 Jul 2014 06:41:00 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BF031AC0D1 for ; Tue, 29 Jul 2014 06:41:00 -0700 (PDT) X-AuditID: c1b4fb3a-f79a36d000000ffa-6d-53d7a469e140 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F3.2B.04090.964A7D35; Tue, 29 Jul 2014 15:40:58 +0200 (CEST) Received: from [159.107.198.99] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.174.1; Tue, 29 Jul 2014 15:40:57 +0200 Message-ID: <53D7A469.3080906@ericsson.com> Date: Tue, 29 Jul 2014 15:40:57 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Martin Bjorklund , References: <971D4B790EC8B846BE223DD23AF72FF11EB7AE39@ESESSMB103.ericsson.se> <20140723183958.GB41350@elstar.local> <20140723.145858.173037388.mbj@tail-f.com> <20140723191618.GA41509@elstar.local> In-Reply-To: <20140723191618.GA41509@elstar.local> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+JvjW7WkuvBBgcvMlp0dz9jt5h/sZHV gcljyZKfTB4bfy1mCWCK4rJJSc3JLEst0rdL4MpovjaTqeCSeMXprS8ZGxgnCnUxcnJICJhI zHn8gwXCFpO4cG89WxcjF4eQwFFGiS2H3kA5axgl9mxbyAxSxSugLTFpRT87iM0ioCrRe/UZ K4jNJmAkMbX/PNgkUYEoiTuX+lkh6gUlTs58AhTn4BARsJA4u9YFJCwsECzx/c9RVoj5Rxgl Hk1ZDzaTE2jO3mdTwOYwC9hKXJhzHcqWl9j+dg7YDUICGhIPL/xlncAoMAvJillIWmYhaVnA yLyKUbQ4tbg4N93ISC+1KDO5uDg/Ty8vtWQTIzAwD275bbWD8eBzx0OMAhyMSjy8D45fCxZi TSwrrsw9xCjNwaIkzrvw3LxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYyz/IVmPfO/Pi1L Rff7gehv6+54VrkcMnqxMymjRZ7xRkVGVlej1ErFpWlxU+uVuefdMt6lpvfGUPg3i5qs3qY4 jRXrNXboyy1c1zf545IjKZaMl983S8w71yrxRqY9OeXKTmtWV+7dCWw31+jMXcwfZrFh+/ZT M7rEyvsanpWwqyyfffTJrmNKLMUZiYZazEXFiQCYCS8ZLQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/USKFsnAAJ8JAWoCi5dKxsNTYYZ0 Subject: Re: [netmod] Issue Y36: associate RPCs AND notification with a data node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 13:41:02 -0000 Helo Juergen, We should declare this issue alive because IETF is about rough consensus and running code: - Rough consensus: Major players (Martin, Andy :-) ) and myself for Ericsson indicated strong interest and support (at least for connecting RPCs, a.k.a. actions, to data nodes). That is at least a begining for a consensus. - Running code: Tail-f, Ericsson, and probably Huawei already has implementations of actions. I have a reasonable proposal, which I will publish hopefully this week, but want to check with Martin first. Also, actions are similar in many ways to RPCs so IMHO they are not a major new feature, no need to wait for a major YANG version: 2.0. regards Balazs On 2014-07-23 21:16, Juergen Schoenwaelder wrote: > On Wed, Jul 23, 2014 at 02:58:58PM -0400, Martin Bjorklund wrote: >> In NACM, you can have a rule that looks like this: >> >> >> xx >> /system/authentication/user[name=$USER] >> exec >> accept >> >> >> (this would give a user access to any inline operations available for >> a user, maybe 'generate-ssh-keys') >> >> So while the NACM procedure defined in RFC 6536 doesn't spell out how >> to handle inline operations (not surpringsly...) the data model >> supports them. >> >> I support Balazs in this; I think especially inline operations >> (a.k.a. actions) have proven to be very useful. We support them in >> our software, and a majority of our customers use them. >> > Lets see what has happened. We discussed Y36 on 2014-06-04. Below is > the excerpt from the minutes. A call was made on the mailing list on > Fri, 27 Jun 2014 and nobody objected against the proposal to move this > to DEAD. > > Why do we reconsider this now? What makes this a YANG 1.1 issue now? > > /js > > * Y36 associate a notification with a data node > > MB says that he did not have customers asking for this but Tail-f > has something similar called actions (inlined rpcs). If we do this, > it makes sense to add inline RPCs as well. > > AZ sees a use case. > > PO sees value in notification source properties attached to leafs. > > PO says that this is essentially about associating a notification > with a resource object. > > MB says this is a nice to have feature because you can do > without. Sounds more like a YANG 2.0 issue. > > AB agrees that this is an optimization, perhaps this can also be > dealt with by certain design patterns. > > JS suggests that one could also think about guidelines on how to > structure notifications to make resource identification easier. > > Proposal: Reject this issue. May be considered for YANG 2.0. > -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Tue Jul 29 06:58:43 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA4301B28CF for ; Tue, 29 Jul 2014 06:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7klZ5WjEsHcI for ; Tue, 29 Jul 2014 06:58:37 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25DEC1B2884 for ; Tue, 29 Jul 2014 06:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8221; q=dns/txt; s=iport; t=1406642317; x=1407851917; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ePLzGNk295eV0EoB5V8vDv+ug60FF37cI4DigO6bECM=; b=XLOm19GCN0yRiWx7RoNWLOulgXBSzp1iSupJkA0OpyP+U9Dlqf4mFpoc E7ypgQYLFGH6GqKU+LLkdT5uIiON/th3jqKsVumGx72NL5P+zp177OD8h nO63DkT8zKyWgm2vigz2LL7osf9SwBDbCFmelW451MDGHP8KhDkaNPjer A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYEADqo11OtJssW/2dsb2JhbABWA4NgV8tmAQmGeFMBgSR3hAMBAQEEAQEBawoBDAICCxABAwECChYPCQMCAQIBCQwoCAYNAQUCAQGIPg2/ExcEjQWCMgEQBwYDCIQ5BZcqhCKBUoVMjTCDSzsvAQE X-IronPort-AV: E=Sophos;i="5.01,757,1400025600"; d="scan'208,217";a="125755695" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 29 Jul 2014 13:58:35 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6TDwYOQ005354; Tue, 29 Jul 2014 13:58:35 GMT Message-ID: <53D7A88A.9050405@cisco.com> Date: Tue, 29 Jul 2014 15:58:34 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "i2rs-chairs@tools.ietf.org" References: <20140728124636.GA55746@elstar.local> <53D7A701.4020705@cisco.com> In-Reply-To: <53D7A701.4020705@cisco.com> Content-Type: multipart/alternative; boundary="------------060508000304040405090400" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LC81McNTdaiNwVFu4-WF1q98YJ4 Cc: "netmod-chairs@tools.ietf.org" , NETMOD Working Group , "rtg-ads@tools.ietf.org" Subject: Re: [netmod] Fwd: yang 1.1 face-to-face interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 13:58:40 -0000 This is a multi-part message in MIME format. --------------060508000304040405090400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [Forgot to include the NEMOD WG. Sorry] Regards, Benoit > I2RS chairs, > > During the last IETF, you came to the NETMOD/NETCONF/Sunday YANG > Advice and Editing Session, requesting some specific improvements to > YANG and/or NETCONF. Thanks for being proactive. > > As you can see below, we will holding an interim YANG 1.1 interim > meeting, working on the list of issues documented at > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ > > Could I2RS please write a draft on the problem statement and specific > NETCONF/YANG requirements discussed verbally during the meeting. > We want to evaluate if your YANG requirements are correctly addressed > by our list of issues. > > As you can see from the interim meeting dates, we try to move > fast(er), therefore there are also some implications for you in term > of deadlines :-) > > Regards, Benoit > > > -------- Original Message -------- > Subject: [netmod] yang 1.1 face-to-face interim meeting > Date: Mon, 28 Jul 2014 14:46:37 +0200 > From: Juergen Schoenwaelder > Reply-To: Juergen Schoenwaelder > To: > > > > Hi, > > during the WG meeting last week, a number of people indicated an > interest to hold a face-to-face interim meeting in order to work on > the more difficult issues of the YANG 1.1 revision (issues related to > conformance, issues related to the separation of configuration > datastore(s) and operational state). > > Below is a doodle poll for face-to-face interim meeting in mid > September. The idea is to meet for at least two full days. Hence, this > will either be Wed/Thu or Thu/Fri or if we go for more than two full > days, it will be Wed/Thu/Fri (perhaps closing at lunch time so people > can get a flight home). The location would be US east cost, Newark / > New York area. > > http://doodle.com/7eptxb7mggtdhwmc > > Please indicate your availability. We need to act soon since a > face-to-face interim needs to be announced at least four weeks before > the event and they require AD approval. > > Please will out the doodle as soon as possible (ideally by July 30th) > so that we have an indication whether the proposed time and location > could work. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > --------------060508000304040405090400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
[Forgot to include the NEMOD WG. Sorry]

Regards, Benoit
I2RS chairs,

During the last IETF, you came to the NETMOD/NETCONF/Sunday YANG Advice and Editing Session, requesting some specific improvements to YANG and/or NETCONF. Thanks for being proactive.

As you can see below, we will holding an interim YANG 1.1 interim meeting, working on the list of issues documented at http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/

Could I2RS please write a draft on the problem statement and specific NETCONF/YANG requirements discussed verbally during the meeting.
We want to evaluate if your YANG requirements are correctly addressed by our list of issues.

As you can see from the interim meeting dates, we try to move fast(er), therefore there are also some implications for you in term of deadlines :-)

Regards, Benoit


-------- Original Message --------
Subject: [netmod] yang 1.1 face-to-face interim meeting
Date: Mon, 28 Jul 2014 14:46:37 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: <netmod@ietf.org> 


Hi,

during the WG meeting last week, a number of people indicated an
interest to hold a face-to-face interim meeting in order to work on
the more difficult issues of the YANG 1.1 revision (issues related to
conformance, issues related to the separation of configuration
datastore(s) and operational state).

Below is a doodle poll for face-to-face interim meeting in mid
September. The idea is to meet for at least two full days. Hence, this
will either be Wed/Thu or Thu/Fri or if we go for more than two full
days, it will be Wed/Thu/Fri (perhaps closing at lunch time so people
can get a flight home). The location would be US east cost, Newark /
New York area.

  http://doodle.com/7eptxb7mggtdhwmc

Please indicate your availability. We need to act soon since a
face-to-face interim needs to be announced at least four weeks before
the event and they require AD approval.

Please will out the doodle as soon as possible (ideally by July 30th)
so that we have an indication whether the proposed time and location
could work.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



--------------060508000304040405090400-- From nobody Wed Jul 30 03:56:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57E31A0305 for ; Wed, 30 Jul 2014 03:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZXeY4iyLuMe for ; Wed, 30 Jul 2014 03:56:07 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27DA11A02FF for ; Wed, 30 Jul 2014 03:56:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id B52B954075D; Wed, 30 Jul 2014 12:56: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 jStWnXf7PjvO; Wed, 30 Jul 2014 12:56:00 +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 0AB895400E9; Wed, 30 Jul 2014 12:55:59 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <20140728095501.GB55180@elstar.local> <20140728121328.GA55631@elstar.local> <5392C525-EB34-4E8A-BB39-B1464E4DE4C9@nic.cz> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Wed, 30 Jul 2014 12:55:55 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/YnJSfS78ZjRfW1GHcG8HJkGSx4E Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 10:56:08 -0000 Andy Bierman writes: > > RFC 6020bis can easily register a standard module name > that goes with the YANG XML namespace if the insert attributes > ever need to be supported (and there is desire to make sure YANG > is not XML-specific). Your draft just needs to say > that the field contains a YANG module name. > I do agree that using a module name as the namespace identifier is the best option, but I need to figure out how the assignment of an attribute to a module is supposed to work. Let's say RFC XXXX defines a few attributes, and this RFC also registers a module name "foo-attributes". My questions: 1. Will the module foo-attributes exist or not? 2. What if RFC XXXX is updated by YYYY, some new attributes are added, or the semantics of the existing ones are changed? If the server advertises the foo-attributes module, how can the client know whether it means the XXXX or YYYY version? 3. Could an independent RFC define new attributes and state they also belong to foo-attributes? Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 30 04:08:38 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747FC1A033C for ; Wed, 30 Jul 2014 04:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XahKDBmeWpaY for ; Wed, 30 Jul 2014 04:08:35 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA211A0305 for ; Wed, 30 Jul 2014 04:08:33 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 16CBCABB; Wed, 30 Jul 2014 13:08:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id nnL9Tfxu8K4r; Wed, 30 Jul 2014 13:08:29 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 30 Jul 2014 13:08:31 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 272072002C; Wed, 30 Jul 2014 13:08:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BhWR07IvTXAA; Wed, 30 Jul 2014 13:08:30 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 41C1120017; Wed, 30 Jul 2014 13:08:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 129A32DFF183; Wed, 30 Jul 2014 13:08:28 +0200 (CEST) Date: Wed, 30 Jul 2014 13:08:28 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140730110826.GE61382@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <20140728121328.GA55631@elstar.local> <5392C525-EB34-4E8A-BB39-B1464E4DE4C9@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Q0zQz1JRQupyhuFBT_WJRVlPpzM Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jul 2014 11:08:36 -0000 On Wed, Jul 30, 2014 at 12:55:55PM +0200, Ladislav Lhotka wrote: > Andy Bierman writes: > > > > RFC 6020bis can easily register a standard module name > > that goes with the YANG XML namespace if the insert attributes > > ever need to be supported (and there is desire to make sure YANG > > is not XML-specific). Your draft just needs to say > > that the field contains a YANG module name. > > > > I do agree that using a module name as the namespace identifier is the > best option, but I need to figure out how the assignment of an attribute > to a module is supposed to work. > > Let's say RFC XXXX defines a few attributes, and this RFC also registers > a module name "foo-attributes". My questions: > > 1. Will the module foo-attributes exist or not? > > 2. What if RFC XXXX is updated by YYYY, some new attributes are added, > or the semantics of the existing ones are changed? If the server > advertises the foo-attributes module, how can the client know whether > it means the XXXX or YYYY version? > > 3. Could an independent RFC define new attributes and state they also > belong to foo-attributes? > I am not sure that module names are the best choice - at least they make conversions between XML representation and JSON representation more difficult since you need to know how to make the namespace identifiers. That said, I do think that for the JSON mapping document, it is enough to say how things are encoded. I think it is not the job of the document to define the whole process around attributes. I do understand that this makes the solution somewhat incomplete but it allows us to finish this document now and to move forward. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jul 30 04:12:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C72F1A02FF for ; Wed, 30 Jul 2014 04:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwCjTEE06j1D for ; Wed, 30 Jul 2014 04:12:17 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D7F81A0305 for ; Wed, 30 Jul 2014 04:12:17 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 16BD810A7; Wed, 30 Jul 2014 13:12:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id yqN3VT9330Nu; Wed, 30 Jul 2014 13:12:13 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 30 Jul 2014 13:12:15 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 493F42002C; Wed, 30 Jul 2014 13:12:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ZDNXPZ-8sVPp; Wed, 30 Jul 2014 13:12: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 42D6F20017; Wed, 30 Jul 2014 13:12:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1A4A22DFF1B8; Wed, 30 Jul 2014 13:12:13 +0200 (CEST) Date: Wed, 30 Jul 2014 13:12:12 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" Message-ID: <20140730111212.GF61382@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <20140728121328.GA55631@elstar.local> <5392C525-EB34-4E8A-BB39-B1464E4DE4C9@nic.cz> <20140730110826.GE61382@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140730110826.GE61382@elstar.local> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/E_KdpDSL8JcOfMw-dyxqXqEEZ-Q Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jul 2014 11:12:24 -0000 On Wed, Jul 30, 2014 at 01:08:28PM +0200, Juergen Schoenwaelder wrote: > On Wed, Jul 30, 2014 at 12:55:55PM +0200, Ladislav Lhotka wrote: > > Andy Bierman writes: > > > > > > RFC 6020bis can easily register a standard module name > > > that goes with the YANG XML namespace if the insert attributes > > > ever need to be supported (and there is desire to make sure YANG > > > is not XML-specific). Your draft just needs to say > > > that the field contains a YANG module name. > > > > > > > I do agree that using a module name as the namespace identifier is the > > best option, but I need to figure out how the assignment of an attribute > > to a module is supposed to work. > > > > Let's say RFC XXXX defines a few attributes, and this RFC also registers > > a module name "foo-attributes". My questions: > > > > 1. Will the module foo-attributes exist or not? > > > > 2. What if RFC XXXX is updated by YYYY, some new attributes are added, > > or the semantics of the existing ones are changed? If the server > > advertises the foo-attributes module, how can the client know whether > > it means the XXXX or YYYY version? > > > > 3. Could an independent RFC define new attributes and state they also > > belong to foo-attributes? > > > > I am not sure that module names are the best choice - at least they > make conversions between XML representation and JSON representation > more difficult since you need to know how to make the namespace > identifiers. Perhaps the document should actually discuss this somewhere and be explicit that transformations need to be aware of the data models to work correctly. Having this clearly documented might help. (I personally think it would have been really really nicer if this is not required but surely the encoding requires to know what the YANG data types are of the leafs.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jul 30 05:19:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330761A0009 for ; Wed, 30 Jul 2014 05:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73wV9ngA-2sx for ; Wed, 30 Jul 2014 05:19:45 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3EC51A000A for ; Wed, 30 Jul 2014 05:19:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=538; q=dns/txt; s=iport; t=1406722785; x=1407932385; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Ddixeg3QzxjXlR+0aikoYE0X5rvxU6ReGmr+zLeMnig=; b=WNYPo4ImoL7X71N36u7W9h9XvlXYAJTKYvOnQhv070HVhTe7rDabCs7X LBVZ6ekczOqT1oHYkndSHvuGp0aD79taKTbh7z9iB4gHYVsuxybqdeFRj fBjnH0v42X/wAgfoagqw0LqNXmcfBKePX2X8piZsziNpUIQ1OxNIzxvae M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAEzi2FOtJA2D/2dsb2JhbABZgmokgS3UExZ3hAo6UQE+QicEiFUBmQ6nDxeUHQWbZJRTg0mCMQ X-IronPort-AV: E=Sophos;i="5.01,764,1400025600"; d="scan'208";a="65147973" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP; 30 Jul 2014 12:19:44 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6UCJi7N017665 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 30 Jul 2014 12:19:44 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Wed, 30 Jul 2014 07:19:43 -0500 From: "Clyde Wildes (cwildes)" To: "netmod@ietf.org" Thread-Topic: NetConf Operational Model Question Thread-Index: AQHPq/CK5tKdZoAdeEKa71z/Ezy0QA== Date: Wed, 30 Jul 2014 12:19:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.27.7.178] Content-Type: text/plain; charset="us-ascii" Content-ID: <364F205EC995BF488F362477DA4BD0CD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/8DIA-zRfzWXAddHIEUmEiiyXmYg Subject: [netmod] NetConf Operational Model Question X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 12:19:47 -0000 Hi, Some operational data reflects data in the running config. Examples from IETF models: - the IETF routing model duplicates most leafs but not all - routing-instance, rib-name, rib address-family, rib recipient-ribs, route-filter. - the ietf-interfaces model duplicates some leafs but not all - name, type. Under what conditions is it acceptable or desirable to model data that is available as part of the running config as operational data? Looking at the existing models I could not see a pattern. Thanks, Clyde From nobody Wed Jul 30 05:31:41 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A981A0012 for ; Wed, 30 Jul 2014 05:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8kyn2vdYbPB for ; Wed, 30 Jul 2014 05:31:38 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11B001A0010 for ; Wed, 30 Jul 2014 05:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=896; q=dns/txt; s=iport; t=1406723498; x=1407933098; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=FbGtLmJf69/xgTO5MJHV16wp4Em8YrWJi6C2GjcsDTg=; b=fHebNR7wTS3omiX8xC8skSxH+/+6g8OjtbHvAyDvL92zMCZl4hSK/SNZ S1OowwliVGQjsO/1tmFFImI+w1We0fby7i41tfQUmODqv8SI3TyODCp4a 0wUTA2Q51xdiEvohTPhch8q4D+B7bHw7YcXrSFxNRrWhGS+yxwsVmtmO3 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFALjk2FOtJA2F/2dsb2JhbABZgw5SVwTLLgqGeIFjFneEBAEBBAEBAWsdAQhtCycEARKIQg3AERMElB0FikWRH5RTg0lsgUU X-IronPort-AV: E=Sophos;i="5.01,764,1400025600"; d="scan'208";a="65097733" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP; 30 Jul 2014 12:31:37 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s6UCVbtE010506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 30 Jul 2014 12:31:37 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.248]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Wed, 30 Jul 2014 07:31:37 -0500 From: "Patrick Gili (pgili)" To: "Clyde Wildes (cwildes)" , "netmod@ietf.org" Thread-Topic: [netmod] NetConf Operational Model Question Thread-Index: AQHPq/I0EwNi7Y8o3kiLtZ7LHjj1eg== Date: Wed, 30 Jul 2014 12:31:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.86.253.129] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0AC70D2DA9779647AF66AAAC4FF47089@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LFkcc4MT28p3JA0opfMQ-Iqe1eA Subject: Re: [netmod] NetConf Operational Model Question X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 12:31:39 -0000 Clyde, This doesn=B9t make sense. Read section 5.1 of RFC 6241 to better understand why I think so. -Patrick On 7/30/14, 8:19 AM, "Clyde Wildes (cwildes)" wrote: >Hi, > >Some operational data reflects data in the running config. Examples from >IETF models: >- the IETF routing model duplicates most leafs but not all - >routing-instance, rib-name, rib address-family, rib recipient-ribs, >route-filter. >- the ietf-interfaces model duplicates some leafs but not all - name, >type. > >Under what conditions is it acceptable or desirable to model data that is >available as part of the running config as operational data? > >Looking at the existing models I could not see a pattern. > >Thanks, > >Clyde > > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Jul 30 05:50:42 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB91B1A0030 for ; Wed, 30 Jul 2014 05:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EezLeYoNjSsp for ; Wed, 30 Jul 2014 05:50:37 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6809A1A002B for ; Wed, 30 Jul 2014 05:50:37 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 1F01A13F64E; Wed, 30 Jul 2014 14:50:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1406724635; bh=27/ARkwSszJKPTN26Zr82vKeSfK477nJrKdnIdyZXIY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hIrVus3fCcKIq0FKodVqLK9UtICwF4mMNb/B8XkY97xxMBHacL/JEYwYfV5/jcGxl 5VoEex3x0RaZXtAZvPewz7wcc96fcmF0CKF0q0dUqoeTKBEeJfblHkvOCsoCO+MBkB pf4L8DVIAXKAwuKyZFISSKwrDkKuoBtLVgH/Ib94= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140730110826.GE61382@elstar.local> Date: Wed, 30 Jul 2014 14:50:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140728121328.GA55631@elstar.local> <5392C525-EB34-4E8A-BB39-B1464E4DE4C9@nic.cz> <20140730110826.GE61382@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/S_nCcEQrzAec4aZL-T1Ca5NQgpw Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 12:50:39 -0000 On 30 Jul 2014, at 13:08, Juergen Schoenwaelder = wrote: > On Wed, Jul 30, 2014 at 12:55:55PM +0200, Ladislav Lhotka wrote: >> Andy Bierman writes: >>>=20 >>> RFC 6020bis can easily register a standard module name >>> that goes with the YANG XML namespace if the insert attributes >>> ever need to be supported (and there is desire to make sure YANG >>> is not XML-specific). Your draft just needs to say >>> that the field contains a YANG module name. >>>=20 >>=20 >> I do agree that using a module name as the namespace identifier is = the >> best option, but I need to figure out how the assignment of an = attribute >> to a module is supposed to work. >>=20 >> Let's say RFC XXXX defines a few attributes, and this RFC also = registers >> a module name "foo-attributes". My questions: >>=20 >> 1. Will the module foo-attributes exist or not? >>=20 >> 2. What if RFC XXXX is updated by YYYY, some new attributes are = added, >> or the semantics of the existing ones are changed? If the server >> advertises the foo-attributes module, how can the client know = whether >> it means the XXXX or YYYY version? >>=20 >> 3. Could an independent RFC define new attributes and state they also >> belong to foo-attributes? >>=20 >=20 > I am not sure that module names are the best choice - at least they Well, the alternatives (i.e. either using full URI as a part of = attribute name or mimicking somehow the XML prefix-URI mapping) are = really anti-JSON, and they would also be confusing in the context of the = YANG-JSON mapping. > make conversions between XML representation and JSON representation > more difficult since you need to know how to make the namespace > identifiers. This is already done for YANG data nodes anyway. >=20 > That said, I do think that for the JSON mapping document, it is enough > to say how things are encoded. I think it is not the job of the > document to define the whole process around attributes. I do Saying that the namespace identifier is a module name without giving any = guidelines about how to choose this module would be rather weird and = won=92t help implementors. > understand that this makes the solution somewhat incomplete but it > allows us to finish this document now and to move forward. That is my priority, too. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 30 05:53:53 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04B71A0020 for ; Wed, 30 Jul 2014 05:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTvlKQPu_AXA for ; Wed, 30 Jul 2014 05:53:48 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C172A1A001E for ; Wed, 30 Jul 2014 05:53:48 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5533B731; Wed, 30 Jul 2014 14:53:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id W2RD3nZLO3Sd; Wed, 30 Jul 2014 14:53:44 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 30 Jul 2014 14:53:46 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A07092002C; Wed, 30 Jul 2014 14:53:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Sv0l0pY_ZsG5; Wed, 30 Jul 2014 14:53:46 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B987220017; Wed, 30 Jul 2014 14:53:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 033882DFF3FB; Wed, 30 Jul 2014 14:53:44 +0200 (CEST) Date: Wed, 30 Jul 2014 14:53:44 +0200 From: Juergen Schoenwaelder To: "Clyde Wildes (cwildes)" Message-ID: <20140730125344.GA61698@elstar.local> Mail-Followup-To: "Clyde Wildes (cwildes)" , "netmod@ietf.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yF7TE6dBteAhfqdBXOeeLvK1w0Q Cc: "netmod@ietf.org" Subject: Re: [netmod] NetConf Operational Model Question X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jul 2014 12:53:52 -0000 On Wed, Jul 30, 2014 at 12:19:42PM +0000, Clyde Wildes (cwildes) wrote: > Hi, > > Some operational data reflects data in the running config. Examples from > IETF models: > - the IETF routing model duplicates most leafs but not all - > routing-instance, rib-name, rib address-family, rib recipient-ribs, > route-filter. > - the ietf-interfaces model duplicates some leafs but not all - name, type. > > Under what conditions is it acceptable or desirable to model data that is > available as part of the running config as operational data? There is some discussion in section 4.3 of RFC 6244 but this RFC also predates some of the newer datamodels. In short, whenever there is a chance that what operationally is used may be different from what is configured, then it makes sense to clearly separate operational state from configuration state. Example: You have a set of configured static routes. But in addition, you have routes picked up from a routing protocol. So what is operationally being used is likely different from what you have configured. The same can be true for certain properties of network interfaces. Note that the operational state often is similar but not identical to operational state. An interface supporting 'simplex' and 'duplex' operation can often be configured to be in 'auto' mode while it operationally ends up in being in either 'simplex' or 'duplex' mode. You can configure to be 'up' but it might be operationally 'down' (e.g. the cable was not plugged in). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jul 30 06:03:02 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D221A0021 for ; Wed, 30 Jul 2014 06:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLWRnH68qg5y for ; Wed, 30 Jul 2014 06:02:55 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F2C1A0025 for ; Wed, 30 Jul 2014 06:02:55 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id C92D113F64E; Wed, 30 Jul 2014 15:02:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1406725374; bh=yQLgUHqtbP57BhbCuRDEK72zjUz1T2Ggn2QdrqzmKzs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qIdUKgy8HqoGZ3IHqLurCWcjmVudXyyat+WMRNgab2I15KKLq/tx43yUo1A+3CJ4U NTJuOoGo/8ixZj2G/AVFF6lXqaM72SC6OaOMrSOoeahm20l9Seeh1o937waIySs1Xo OxERx+S56Zptu3CEdDSnRVZKilhUw+M6i6hU5G2o= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140730111212.GF61382@elstar.local> Date: Wed, 30 Jul 2014 15:02:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2111DCCB-FA5D-42F8-B045-508821A8E1B7@nic.cz> References: <20140728121328.GA55631@elstar.local> <5392C525-EB34-4E8A-BB39-B1464E4DE4C9@nic.cz> <20140730110826.GE61382@elstar.local> <20140730111212.GF61382@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/mK3-2jig6dnmOgDbt6WpOzpbUY8 Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 13:03:00 -0000 On 30 Jul 2014, at 13:12, Juergen Schoenwaelder = wrote: > On Wed, Jul 30, 2014 at 01:08:28PM +0200, Juergen Schoenwaelder wrote: >> On Wed, Jul 30, 2014 at 12:55:55PM +0200, Ladislav Lhotka wrote: >>> Andy Bierman writes: >>>>=20 >>>> RFC 6020bis can easily register a standard module name >>>> that goes with the YANG XML namespace if the insert attributes >>>> ever need to be supported (and there is desire to make sure YANG >>>> is not XML-specific). Your draft just needs to say >>>> that the field contains a YANG module name. >>>>=20 >>>=20 >>> I do agree that using a module name as the namespace identifier is = the >>> best option, but I need to figure out how the assignment of an = attribute >>> to a module is supposed to work. >>>=20 >>> Let's say RFC XXXX defines a few attributes, and this RFC also = registers >>> a module name "foo-attributes". My questions: >>>=20 >>> 1. Will the module foo-attributes exist or not? >>>=20 >>> 2. What if RFC XXXX is updated by YYYY, some new attributes are = added, >>> or the semantics of the existing ones are changed? If the server >>> advertises the foo-attributes module, how can the client know = whether >>> it means the XXXX or YYYY version? >>>=20 >>> 3. Could an independent RFC define new attributes and state they = also >>> belong to foo-attributes? >>>=20 >>=20 >> I am not sure that module names are the best choice - at least they >> make conversions between XML representation and JSON representation >> more difficult since you need to know how to make the namespace >> identifiers. >=20 > Perhaps the document should actually discuss this somewhere and be > explicit that transformations need to be aware of the data models to > work correctly. Having this clearly documented might help. (I Sec. 1 in draft-ietf-netmod-yang-json-00 says: 1. The translation is driven by a concrete YANG data model and uses information about data types to achieve better results than generic XML-JSON translation procedures. This should also mention the namespace-to-module-name mapping. > personally think it would have been really really nicer if this is not > required but surely the encoding requires to know what the YANG data > types are of the leafs.) Pyang=92s jsonxsl plugin demonstrates that the schema-aware translation = can be effectively automated. The prefix-URI mapping that=92s used in = XML proved to be problematic. =20 Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 30 06:04:23 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C4B1A0021 for ; Wed, 30 Jul 2014 06:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Neyfotqr7FXi for ; Wed, 30 Jul 2014 06:04:20 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F6481A0020 for ; Wed, 30 Jul 2014 06:04:20 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 40790703; Wed, 30 Jul 2014 15:04:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 7RbAdlrHNSel; Wed, 30 Jul 2014 15:04:16 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 30 Jul 2014 15:04:18 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 046932002C; Wed, 30 Jul 2014 15:04:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Owr6h9o6S4u7; Wed, 30 Jul 2014 15:04:17 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8ED6D20017; Wed, 30 Jul 2014 15:04:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 514502DFF43E; Wed, 30 Jul 2014 15:04:14 +0200 (CEST) Date: Wed, 30 Jul 2014 15:04:14 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140730130412.GB61698@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <20140728121328.GA55631@elstar.local> <5392C525-EB34-4E8A-BB39-B1464E4DE4C9@nic.cz> <20140730110826.GE61382@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/T4jTRuVvNf-CoGfYxxhPU9z4OZw Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jul 2014 13:04:22 -0000 On Wed, Jul 30, 2014 at 02:50:27PM +0200, Ladislav Lhotka wrote: > > Well, the alternatives (i.e. either using full URI as a part of attribute name or mimicking somehow the XML prefix-URI mapping) are really anti-JSON, and they would also be confusing in the context of the YANG-JSON mapping. > Not sure what defines anti-JSON, i.e. why using a namespace URI would violate something that a module name does not violate. > > make conversions between XML representation and JSON representation > > more difficult since you need to know how to make the namespace > > identifiers. > > This is already done for YANG data nodes anyway. > Yes, I understand that. Even if we make this assumption, I think it would be good to spell this out explicitely right upfront so that people know that a translation without knowledge of data models was not a goal of the design. I am sure people will try to do this and we better make sure everybody understands upfront that this won't work. > > That said, I do think that for the JSON mapping document, it is enough > > to say how things are encoded. I think it is not the job of the > > document to define the whole process around attributes. I do > > Saying that the namespace identifier is a module name without giving any guidelines about how to choose this module would be rather weird and won’t help implementors. > I have been told implementors already do some of this and this is why we should worry about attribute encoding. Now you are saying this does not help implementors. Sounds like a contradiction? I think you are looking for interoperability of attributes. Well, as long as we have no mechanism to really define them, they are by definition non-interoperable. So why then define their encoding? Well, it gives us at least an interoperable way to communicate attributes, which may be better than non-interoperable solutions to encode attributes. > > understand that this makes the solution somewhat incomplete but it > > allows us to finish this document now and to move forward. > > That is my priority, too. Good. So what speaks against saying that if attribute names clash and if attributes are scoped by a module name, then the encoding is XYZ? This allows future specifications to define further rules as needed. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jul 30 06:11:54 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0CE11A0027 for ; Wed, 30 Jul 2014 06:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpDtgXsHHmaW for ; Wed, 30 Jul 2014 06:11:48 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9801A0020 for ; Wed, 30 Jul 2014 06:11:47 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 845751103; Wed, 30 Jul 2014 15:11:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id BWYLr0GejeHG; Wed, 30 Jul 2014 15:11:44 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 30 Jul 2014 15:11:45 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DA6E220034; Wed, 30 Jul 2014 15:11:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XutxYQ0MdUyr; Wed, 30 Jul 2014 15:11:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D75AB2002C; Wed, 30 Jul 2014 15:11:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E6D102DFF472; Wed, 30 Jul 2014 15:11:43 +0200 (CEST) Date: Wed, 30 Jul 2014 15:11:43 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140730131142.GC61698@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <20140728121328.GA55631@elstar.local> <5392C525-EB34-4E8A-BB39-B1464E4DE4C9@nic.cz> <20140730110826.GE61382@elstar.local> <20140730111212.GF61382@elstar.local> <2111DCCB-FA5D-42F8-B045-508821A8E1B7@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2111DCCB-FA5D-42F8-B045-508821A8E1B7@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ZWe2P2kOcwsJqjtrijc4sFEcXSE Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jul 2014 13:11:53 -0000 On Wed, Jul 30, 2014 at 03:02:47PM +0200, Ladislav Lhotka wrote: > > Pyang’s jsonxsl plugin demonstrates that the schema-aware translation can be effectively automated. The prefix-URI mapping that’s used in XML proved to be problematic. > This was not my concern. Think about a gateway translating between NETCONF (XML encoding) and RESTCONF (JSON encoding). This gateway now needs to know all data models for the data passing through the gateway. So the problem is making sure you always have the schema, not the schema-aware translation. I know your answer will be you can always grab the schema as long as you do online translation. So here is another example: Think about a tool that is storing data in one of the presentations (say XML) and then the data is processed by a tool that likes to have the data in a different representation (say JSON). Now you need to track the schema for each stored data set to be able to do the conversion. Again, it is fine with me if the WG agrees this is just how it is. I just want to make sure this is well understood and clearly documented. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jul 30 07:01:54 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09531A005D; Wed, 30 Jul 2014 07:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTZcsWcgx-ZJ; Wed, 30 Jul 2014 07:01:47 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.197]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC781A004E; Wed, 30 Jul 2014 07:01:46 -0700 (PDT) Received: from [216.82.242.131:29153] by server-5.bemta-8.messagelabs.com id C4/5D-05345-ACAF8D35; Wed, 30 Jul 2014 14:01:46 +0000 X-Env-Sender: eric.osborne@level3.com X-Msg-Ref: server-16.tower-76.messagelabs.com!1406728905!41343245!1 X-Originating-IP: [209.245.18.37] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26728 invoked from network); 30 Jul 2014 14:01:45 -0000 Received: from bge23000.messagelabs1.prod.broomfield1.level3.net (HELO messagelabs1.level3.com) (209.245.18.37) by server-16.tower-76.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Jul 2014 14:01:45 -0000 Received: from USIDCWVEHT02.corp.global.level3.com (usidcwveht02.corp.global.level3.com [10.1.142.32]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "USIDCWVEHT02", Issuer "USIDCWVEHT02" (not verified)) by messagelabs1.level3.com (Postfix) with ESMTPS id ECB341FB56; Wed, 30 Jul 2014 14:01:44 +0000 (GMT) Received: from USADCWVEHT01.corp.global.level3.com (10.2.36.141) by USIDCWVEHT02.corp.global.level3.com (10.1.142.32) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 30 Jul 2014 08:01:44 -0600 Received: from USIDCWVEMBX08.corp.global.level3.com ([fe80::20f7:9e5b:2efa:2ad8]) by usadcwveht01.corp.global.level3.com ([::1]) with mapi id 14.03.0158.001; Wed, 30 Jul 2014 10:01:43 -0400 From: "Osborne, Eric" To: "netmod@ietf.org" Thread-Topic: Recommendations on model reuse? Thread-Index: Ac+r/Yw2RNO/mxVzRiaFITB9JotUTQ== Date: Wed, 30 Jul 2014 14:01:43 +0000 Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACDF036D5@USIDCWVEMBX08.corp.global.level3.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.196.205] Content-Type: multipart/alternative; boundary="_000_63CB93BC589C1B4BAFDB41A0A19B7ACDF036D5USIDCWVEMBX08corp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/X5aCSSUm3b1MSXxPhp8pRi1jF3k Cc: "isis-wg@ietf.org" , "Jeffrey \(Zhaohui\) Zhang \(zzhang@juniper.net\)" , "Wunan \(Eric\)" , Chris Bowers , Hannes Gredler Subject: [netmod] Recommendations on model reuse? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 14:01:52 -0000 --_000_63CB93BC589C1B4BAFDB41A0A19B7ACDF036D5USIDCWVEMBX08corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Netmod folks- There's a discussion on the isis list that boils down to how much YANG mod= el reuse we shoot for. In brief: - MPLS-TE is implemented in both OSPF and ISIS - The TE parts of OSPF and ISIS are identical, but OSPF and ISIS t= hemselves are quite different - There was apparently some hallway conversation in Toronto that s= uggested that we should write two different TE models, one for OSPF and one= for ISIS, and keep those two in constant sync rather than write a common T= E model that augmented both OSPF and ISIS. I wasn't a party to the hallway conversation, so I don't know what issues w= ere raised to justify this split. And the people who had it are not dummie= s, so I'm willing to believe there was a non-ridiculous reason for this dec= ision. In the long run, though, it seems like a bad idea. I don't want to= end up with a huge flat space which contains all models, with no reuse bec= ause people found it easier to roll their own with minute differences. Are there any guiding principles we can look to for direction? I hoped rfc= 6087 would have had something like this, but it seems to be concerned with = the production of individual models and not with the interaction between mo= dels and guidelines around overall structure. If there are no guiding principles anywhere, would it be useful to have a d= ocument that gave general guidelines around model reuse? Naively I think i= t might just be three lines long and say "you SHOULD reuse existing models = wherever possible rather than reinventing your own, and if you don't reuse = you MUST have a section in your document that says why you didn't reuse wha= t already existed". Of course, it may end up being significantly longer a= nd more complex than that. eric --_000_63CB93BC589C1B4BAFDB41A0A19B7ACDF036D5USIDCWVEMBX08corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Netmod folks-

 

 There’s a discussion on the isis list th= at boils down to how much YANG model reuse we shoot for.  In brief:

 

-     &= nbsp;    MPLS-TE is implemented in both OSPF and ISIS

-     &= nbsp;    The TE parts of OSPF and ISIS are identical, but OS= PF and ISIS themselves are quite different

-     &= nbsp;    There was apparently some hallway conversation in T= oronto that suggested that we should write two different TE models, one for= OSPF and one for ISIS, and keep those two in constant sync rather than wri= te a common TE model that augmented both OSPF and ISIS.

 

I wasn’t a party to the hallway conversation, = so I don’t know what issues were raised to justify this split.  = And the people who had it are not dummies, so I’m willing to believe = there was a non-ridiculous reason for this decision.  In the long run, though, it seems like a bad idea.  I don’t want t= o end up with a huge flat space which contains all models, with no reuse be= cause people found it easier to roll their own with minute differences.

 

Are there any guiding principles we can look to for = direction?  I hoped rfc6087 would have had something like this, but it= seems to be concerned with the production of individual models and not wit= h the interaction between models and guidelines around overall structure. 

 

If there are no guiding principles anywhere, would i= t be useful to have a document that gave general guidelines around model re= use?  Naively I think it might just be three lines long and say “= ;you SHOULD reuse existing models wherever possible rather than reinventing your own, and if you don’t reuse you MUST ha= ve a section in your document that says why you didn’t reuse what alr= eady existed”.   Of course, it may end up being significant= ly longer and more complex than that.

 

 

 

 

eric

 

 

--_000_63CB93BC589C1B4BAFDB41A0A19B7ACDF036D5USIDCWVEMBX08corp_-- From nobody Wed Jul 30 07:08:16 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA4A1A0060 for ; Wed, 30 Jul 2014 07:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2afysQsH9Ic for ; Wed, 30 Jul 2014 07:08:10 -0700 (PDT) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D57A1A005D for ; Wed, 30 Jul 2014 07:08:10 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id w8so1330236qac.30 for ; Wed, 30 Jul 2014 07:08: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=JUG7IaAWMFZdRtqevp7NPcKLxOZNfFiQ+cHlQJXUoeM=; b=V3zL745lK+3+mvZ/jiobYvtK7t0YfjSDfXe834c1zQogHhdZ3fcK45WovdCMhgqqKv Yj9uHF/f4NaFJ6jUKwVANcfXlcTUF4ZAnCv0FobGpUn1TA1gCVTWS5dFvZwCKBDNQw5d yMhe0IeiP1ddB4oHE7tvLdRYbFtGgueQXurmAWxuhMqKaV0CDUlmTQghAYvnpShKIkp6 Sz6l/XpmDVEtM+mwUoWR30Q60WIjdsn17VdBvOMaK2O/8tyrWmqFSIOa9oelVq5OUYFE GuSB0vMPbiNfxxGg/Y88sqHVguam+xApdfGg+PvKP5WbSshqYrenbhtEX4I5Gzhv502W 1ZXQ== X-Gm-Message-State: ALoCoQkS+p8yxBZIK/G5cOSBCNYXnWL98bd2U8GoibpAazyf8LsV1ZFSxrR6GpZklh+O5371cbj+ MIME-Version: 1.0 X-Received: by 10.224.28.133 with SMTP id m5mr7289868qac.16.1406729289644; Wed, 30 Jul 2014 07:08:09 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Wed, 30 Jul 2014 07:08:09 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Jul 2014 07:08:09 -0700 Message-ID: From: Andy Bierman To: "Patrick Gili (pgili)" Content-Type: multipart/alternative; boundary=001a11c1db709ad55504ff69af22 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/M9oHeIFItaH8L5EzWVOdsKuTv80 Cc: "netmod@ietf.org" Subject: Re: [netmod] NetConf Operational Model Question X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 14:08:12 -0000 --001a11c1db709ad55504ff69af22 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 30, 2014 at 5:31 AM, Patrick Gili (pgili) wrote: > Clyde, > > This doesn=B9t make sense. Read section 5.1 of RFC 6241 to better > understand why I think so. > > The running configuration contains only the config=3Dtrue subset of all YANG data nodes. IMO, the only reason to replicate the configuration structure (non-terminals, keys) in operational state (like ietf-interfaces) is because the state can exist independently of the configuration. Most of the time, this is a bad idea and doesn't really make sense. - Can the data structure being modeled exist on its own as state without any config? If yes then dual data structures are needed. - e.g., What does it mean if an interface is reported as state but does not exist in the configuration? (I sure don't know) - How many of the leafs (properties) of the configured data structure can be changed by means other than configuration edits? If none or very few= , then duplicating the data as config and state is not needed. - Does the operator need to know the operational state values that are overriding specific configured values? What breaks if the operator thinks the configured value is in use but it is a different value? -Patrick > Andy > > On 7/30/14, 8:19 AM, "Clyde Wildes (cwildes)" wrote: > > >Hi, > > > >Some operational data reflects data in the running config. Examples from > >IETF models: > >- the IETF routing model duplicates most leafs but not all - > >routing-instance, rib-name, rib address-family, rib recipient-ribs, > >route-filter. > >- the ietf-interfaces model duplicates some leafs but not all - name, > >type. > > > >Under what conditions is it acceptable or desirable to model data that i= s > >available as part of the running config as operational data? > > > >Looking at the existing models I could not see a pattern. > > > >Thanks, > > > >Clyde > > > > > >_______________________________________________ > >netmod mailing list > >netmod@ietf.org > >https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c1db709ad55504ff69af22 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 30, 2014 at 5:31 AM, Patrick Gili (pgili) <pgili@cisco.c= om> wrote:
Clyde,

This doesn=B9t make sense. =A0Read section 5.1 of RFC 6241 to better
understand why I think so.


The running configuration contains onl= y the config=3Dtrue subset of all
YANG data nodes.

=
IMO, the only reason to replicate the configuration structure (n= on-terminals, keys)
in operational state (like ietf-interfaces) is because the state can e= xist independently
of the configuration. =A0Most of the time, thi= s is a bad idea and doesn't really make sense.

=A0 - Can the data structure being modeled exist on its own as state withou= t any config?
=A0 =A0 If yes then dual data structures are needed= .

=A0 - e.g., What does it mean if an interface is= reported as state but does not
=A0 =A0 exist in the configuration? =A0(I sure don't know)

=A0 - How many of the leafs (properties) of the configure= d data structure can
=A0 =A0 be changed by means other than confi= guration edits? If none or very few,
=A0 =A0 then duplicating the data as config and state is not needed.

=A0- Does the operator need to know the operational= state values that are overriding
=A0 =A0specific configured valu= es? What breaks if the operator thinks the configured
=A0 =A0value is in use but it is a different value?

=A0=A0

-Patrick


Andy
= =A0

On 7/30/14, 8:19 AM, "Clyde Wildes (cwildes)" <cwildes@cisco.com> wrote:

>Hi,
>
>Some operational data reflects data in the running config. Examples fro= m
>IETF models:
>- the IETF routing model duplicates most leafs but not all -
>routing-instance, rib-name, rib address-family, rib recipient-ribs,
>route-filter.
>- the ietf-interfaces model duplicates some leafs but not all - name, >type.
>
>Under what conditions is it acceptable or desirable to model data that = is
>available as part of the running config as operational data?
>
>Looking at the existing models I could not see a pattern.
>
>Thanks,
>
>Clyde
>
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--001a11c1db709ad55504ff69af22-- From nobody Wed Jul 30 07:15:53 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090FB1A00AF; Wed, 30 Jul 2014 07:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxLoNN1mpI3j; Wed, 30 Jul 2014 07:15:39 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D157B1A00AD; Wed, 30 Jul 2014 07:15:38 -0700 (PDT) Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BLUPR05MB291.namprd05.prod.outlook.com (10.141.23.26) with Microsoft SMTP Server (TLS) id 15.0.995.14; Wed, 30 Jul 2014 14:15:36 +0000 Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.202]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.202]) with mapi id 15.00.0995.014; Wed, 30 Jul 2014 14:15:35 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "Osborne, Eric" , "netmod@ietf.org" Thread-Topic: Recommendations on model reuse? Thread-Index: Ac+r/Yw2RNO/mxVzRiaFITB9JotUTQAAkxcA Date: Wed, 30 Jul 2014 14:15:34 +0000 Message-ID: References: <63CB93BC589C1B4BAFDB41A0A19B7ACDF036D5@USIDCWVEMBX08.corp.global.level3.com> In-Reply-To: <63CB93BC589C1B4BAFDB41A0A19B7ACDF036D5@USIDCWVEMBX08.corp.global.level3.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0288CD37D9 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(189002)(199002)(105586002)(85306003)(101416001)(83322001)(87936001)(15202345003)(76576001)(19580395003)(76482001)(85852003)(83072002)(2656002)(99286002)(19625215002)(106356001)(92566001)(95666004)(79102001)(4396001)(77096002)(46102001)(19300405004)(77982001)(80022001)(74316001)(15975445006)(81342001)(99396002)(16236675004)(31966008)(74662001)(54356999)(66066001)(64706001)(76176999)(50986999)(19580405001)(21056001)(20776003)(86362001)(107046002)(74502001)(81542001)(33646002)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB291; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_a35782eaca1e409298b7db15ccfe8ea4BY2PR05MB079namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/KhtIf_M5u8w6b6d_bRIN-N_W7s0 Cc: "isis-wg@ietf.org" , "Wunan \(Eric\)" , Chris Bowers , Hannes Gredler Subject: Re: [netmod] Recommendations on model reuse? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 14:15:47 -0000 --_000_a35782eaca1e409298b7db15ccfe8ea4BY2PR05MB079namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eric, I don't think that hallway conversation rejected the idea of common TE mode= l. Please see my reply on ISIS mailing list (perhaps it is waiting for mode= rator to post it - just realized that I was no on the ISIS list - I'll forw= ard to you). Jeffrey From: Osborne, Eric [mailto:eric.osborne@level3.com] Sent: Wednesday, July 30, 2014 10:02 AM To: netmod@ietf.org Cc: isis-wg@ietf.org; Chris Bowers; Alia Atlas; Derek Man-Kit Yeung (myeung= ) (myeung@cisco.com); Jeffrey (Zhaohui) Zhang; Hannes Gredler; Wunan (Eric) Subject: Recommendations on model reuse? Netmod folks- There's a discussion on the isis list that boils down to how much YANG mod= el reuse we shoot for. In brief: - MPLS-TE is implemented in both OSPF and ISIS - The TE parts of OSPF and ISIS are identical, but OSPF and ISIS t= hemselves are quite different - There was apparently some hallway conversation in Toronto that s= uggested that we should write two different TE models, one for OSPF and one= for ISIS, and keep those two in constant sync rather than write a common T= E model that augmented both OSPF and ISIS. I wasn't a party to the hallway conversation, so I don't know what issues w= ere raised to justify this split. And the people who had it are not dummie= s, so I'm willing to believe there was a non-ridiculous reason for this dec= ision. In the long run, though, it seems like a bad idea. I don't want to= end up with a huge flat space which contains all models, with no reuse bec= ause people found it easier to roll their own with minute differences. Are there any guiding principles we can look to for direction? I hoped rfc= 6087 would have had something like this, but it seems to be concerned with = the production of individual models and not with the interaction between mo= dels and guidelines around overall structure. If there are no guiding principles anywhere, would it be useful to have a d= ocument that gave general guidelines around model reuse? Naively I think i= t might just be three lines long and say "you SHOULD reuse existing models = wherever possible rather than reinventing your own, and if you don't reuse = you MUST have a section in your document that says why you didn't reuse wha= t already existed". Of course, it may end up being significantly longer a= nd more complex than that. eric --_000_a35782eaca1e409298b7db15ccfe8ea4BY2PR05MB079namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Eric,

 

I don’t think th= at hallway conversation rejected the idea of common TE model. Please see my= reply on ISIS mailing list (perhaps it is waiting for moderator to post it= – just realized that I was no on the ISIS list – I’ll forward to you).

 

Jeffrey

 

From: Osborne, Eric [mailto:eric.osborne@leve= l3.com]
Sent: Wednesday, July 30, 2014 10:02 AM
To: netmod@ietf.org
Cc: isis-wg@ietf.org; Chris Bowers; Alia Atlas; Derek Man-Kit Yeung = (myeung) (myeung@cisco.com); Jeffrey (Zhaohui) Zhang; Hannes Gredler; Wunan= (Eric)
Subject: Recommendations on model reuse?

 

Netmod folks-

 

 There’s a discussion on the isis list th= at boils down to how much YANG model reuse we shoot for.  In brief:

 

-     &= nbsp;    MPLS-TE is implemented in both OSPF and ISIS

-     &= nbsp;    The TE parts of OSPF and ISIS are identical, but OS= PF and ISIS themselves are quite different

-     &= nbsp;    There was apparently some hallway conversation in T= oronto that suggested that we should write two different TE models, one for= OSPF and one for ISIS, and keep those two in constant sync rather than wri= te a common TE model that augmented both OSPF and ISIS.

 

I wasn’t a party to the hallway conversation, = so I don’t know what issues were raised to justify this split.  = And the people who had it are not dummies, so I’m willing to believe = there was a non-ridiculous reason for this decision.  In the long run, though, it seems like a bad idea.  I don’t want t= o end up with a huge flat space which contains all models, with no reuse be= cause people found it easier to roll their own with minute differences.

 

Are there any guiding principles we can look to for = direction?  I hoped rfc6087 would have had something like this, but it= seems to be concerned with the production of individual models and not wit= h the interaction between models and guidelines around overall structure. 

 

If there are no guiding principles anywhere, would i= t be useful to have a document that gave general guidelines around model re= use?  Naively I think it might just be three lines long and say “= ;you SHOULD reuse existing models wherever possible rather than reinventing your own, and if you don’t reuse you MUST ha= ve a section in your document that says why you didn’t reuse what alr= eady existed”.   Of course, it may end up being significant= ly longer and more complex than that.

 

 

 

 

eric

 

 

--_000_a35782eaca1e409298b7db15ccfe8ea4BY2PR05MB079namprd05pro_-- From nobody Wed Jul 30 07:30:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7731A00B0; Wed, 30 Jul 2014 07:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D769iitaVJn2; Wed, 30 Jul 2014 07:29:52 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.5]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C281A1A0039; Wed, 30 Jul 2014 07:29:52 -0700 (PDT) Received: from [216.82.250.99:63762] by server-5.bemta-12.messagelabs.com id AE/81-17483-06109D35; Wed, 30 Jul 2014 14:29:52 +0000 X-Env-Sender: eric.osborne@level3.com X-Msg-Ref: server-16.tower-126.messagelabs.com!1406730591!14629276!1 X-Originating-IP: [209.245.18.38] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15690 invoked from network); 30 Jul 2014 14:29:51 -0000 Received: from unknown.level3.net (HELO messagelabs2.level3.com) (209.245.18.38) by server-16.tower-126.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Jul 2014 14:29:51 -0000 Received: from USIDCWVEHT01.corp.global.level3.com (usidcwveht01.corp.global.level3.com [10.1.142.31]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "USIDCWVEHT01", Issuer "USIDCWVEHT01" (not verified)) by messagelabs2.level3.com (Postfix) with ESMTPS id 1D6582BBBC; Wed, 30 Jul 2014 14:29:51 +0000 (GMT) Received: from USIDCWVEMBX08.corp.global.level3.com ([fe80::20f7:9e5b:2efa:2ad8]) by USIDCWVEHT01.corp.global.level3.com ([::1]) with mapi id 14.03.0158.001; Wed, 30 Jul 2014 08:29:50 -0600 From: "Osborne, Eric" To: "Jeffrey (Zhaohui) Zhang" , "netmod@ietf.org" Thread-Topic: Recommendations on model reuse? Thread-Index: Ac+r/Yw2RNO/mxVzRiaFITB9JotUTQAAkxcAAACmziA= Date: Wed, 30 Jul 2014 14:29:50 +0000 Message-ID: <63CB93BC589C1B4BAFDB41A0A19B7ACDF0382D@USIDCWVEMBX08.corp.global.level3.com> References: <63CB93BC589C1B4BAFDB41A0A19B7ACDF036D5@USIDCWVEMBX08.corp.global.level3.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.196.205] Content-Type: multipart/alternative; boundary="_000_63CB93BC589C1B4BAFDB41A0A19B7ACDF0382DUSIDCWVEMBX08corp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/FKqUFX96N-dCEvgk8yXNCq4IAR0 Cc: "isis-wg@ietf.org" , "Wunan \(Eric\)" , Chris Bowers , Hannes Gredler Subject: Re: [netmod] Recommendations on model reuse? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 14:29:56 -0000 --_000_63CB93BC589C1B4BAFDB41A0A19B7ACDF0382DUSIDCWVEMBX08corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cool, thanks. For the record (since I didn't see it on the isis list) Jeffrey's reply was= : We did not talk explicitly about TE stuffs but more general parameters that= are common to both IGP and that may be part of a superset IGP model. I'm still open to have something hierarchical or using augmentations for co= mmon parameters but we need to agree on the scope. I agree with this. I'm also OK with developing three flat models in parallel (ISIS, OSPF, BGP-= LS) as part of exploring what we can and cannot share. I don't want to giv= e the impression that we need to write a half-dozen documents around framew= ork and structure before we actually do Real Work. I just want to make sur= e that the end product has as much reuse as possible. eric From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Wednesday, July 30, 2014 10:16 AM To: Osborne, Eric; netmod@ietf.org Cc: isis-wg@ietf.org; Chris Bowers; Alia Atlas; Derek Man-Kit Yeung (myeung= ) (myeung@cisco.com); Hannes Gredler; Wunan (Eric) Subject: RE: Recommendations on model reuse? Eric, I don't think that hallway conversation rejected the idea of common TE mode= l. Please see my reply on ISIS mailing list (perhaps it is waiting for mode= rator to post it - just realized that I was no on the ISIS list - I'll forw= ard to you). Jeffrey From: Osborne, Eric [mailto:eric.osborne@level3.com] Sent: Wednesday, July 30, 2014 10:02 AM To: netmod@ietf.org Cc: isis-wg@ietf.org; Chris Bowers; Alia Atlas; De= rek Man-Kit Yeung (myeung) (myeung@cisco.com); Jef= frey (Zhaohui) Zhang; Hannes Gredler; Wunan (Eric) Subject: Recommendations on model reuse? Netmod folks- There's a discussion on the isis list that boils down to how much YANG mod= el reuse we shoot for. In brief: - MPLS-TE is implemented in both OSPF and ISIS - The TE parts of OSPF and ISIS are identical, but OSPF and ISIS t= hemselves are quite different - There was apparently some hallway conversation in Toronto that s= uggested that we should write two different TE models, one for OSPF and one= for ISIS, and keep those two in constant sync rather than write a common T= E model that augmented both OSPF and ISIS. I wasn't a party to the hallway conversation, so I don't know what issues w= ere raised to justify this split. And the people who had it are not dummie= s, so I'm willing to believe there was a non-ridiculous reason for this dec= ision. In the long run, though, it seems like a bad idea. I don't want to= end up with a huge flat space which contains all models, with no reuse bec= ause people found it easier to roll their own with minute differences. Are there any guiding principles we can look to for direction? I hoped rfc= 6087 would have had something like this, but it seems to be concerned with = the production of individual models and not with the interaction between mo= dels and guidelines around overall structure. If there are no guiding principles anywhere, would it be useful to have a d= ocument that gave general guidelines around model reuse? Naively I think i= t might just be three lines long and say "you SHOULD reuse existing models = wherever possible rather than reinventing your own, and if you don't reuse = you MUST have a section in your document that says why you didn't reuse wha= t already existed". Of course, it may end up being significantly longer a= nd more complex than that. eric --_000_63CB93BC589C1B4BAFDB41A0A19B7ACDF0382DUSIDCWVEMBX08corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Cool, thanks.

For the record (since = I didn’t see it on the isis list) Jeffrey’s reply was:

 

We did not talk explic= itly about TE stuffs but more general parameters that are common to both IG= P and that may be part of a superset IGP model.

 

I’m still open to have something hierarchical or using au= gmentations for common parameters but we need to agree on the scope.

 

 

I agree with this.&nbs= p;

I’m also OK with= developing three flat models in parallel (ISIS, OSPF, BGP-LS) as part of e= xploring what we can and cannot share.  I don’t want to give the= impression that we need to write a half-dozen documents around framework and structure before we actually do Real Work.  I ju= st want to make sure that the end product has as much reuse as possible.

 

 

 

 

eric=

 

From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@= juniper.net]
Sent: Wednesday, July 30, 2014 10:16 AM
To: Osborne, Eric; netmod@ietf.org
Cc: isis-wg@ietf.org; Chris Bowers; Alia Atlas; Derek Man-Kit Yeung = (myeung) (myeung@cisco.com); Hannes Gredler; Wunan (Eric)
Subject: RE: Recommendations on model reuse?

 

Eric,

 

I don’t think th= at hallway conversation rejected the idea of common TE model. Please see my= reply on ISIS mailing list (perhaps it is waiting for moderator to post it= – just realized that I was no on the ISIS list – I’ll forward to you).

 

Jeffrey

 

From: Osborne, Eric [mailto:eric.osborne@level3.com]
Sent: Wednesday, July 30, 2014 10:02 AM
To: netmod@ietf.org
Cc: isis-wg@ietf.org; Chris = Bowers; Alia Atlas; Derek Man-Kit Yeung (myeung) (myeung@cisco.com); Jeffrey (Zhaohui) Zhang; Hannes Gredler; = Wunan (Eric)
Subject: Recommendations on model reuse?

 

Netmod folks-

 

 There’s a discussion on the isis list th= at boils down to how much YANG model reuse we shoot for.  In brief:

 

-     &= nbsp;    MPLS-TE is implemented in both OSPF and ISIS

-     &= nbsp;    The TE parts of OSPF and ISIS are identical, but OS= PF and ISIS themselves are quite different

-     &= nbsp;    There was apparently some hallway conversation in T= oronto that suggested that we should write two different TE models, one for= OSPF and one for ISIS, and keep those two in constant sync rather than wri= te a common TE model that augmented both OSPF and ISIS.

 

I wasn’t a party to the hallway conversation, = so I don’t know what issues were raised to justify this split.  = And the people who had it are not dummies, so I’m willing to believe = there was a non-ridiculous reason for this decision.  In the long run, though, it seems like a bad idea.  I don’t want t= o end up with a huge flat space which contains all models, with no reuse be= cause people found it easier to roll their own with minute differences.

 

Are there any guiding principles we can look to for = direction?  I hoped rfc6087 would have had something like this, but it= seems to be concerned with the production of individual models and not wit= h the interaction between models and guidelines around overall structure. 

 

If there are no guiding principles anywhere, would i= t be useful to have a document that gave general guidelines around model re= use?  Naively I think it might just be three lines long and say “= ;you SHOULD reuse existing models wherever possible rather than reinventing your own, and if you don’t reuse you MUST ha= ve a section in your document that says why you didn’t reuse what alr= eady existed”.   Of course, it may end up being significant= ly longer and more complex than that.

 

 

 

 

eric

 

 

--_000_63CB93BC589C1B4BAFDB41A0A19B7ACDF0382DUSIDCWVEMBX08corp_-- From nobody Wed Jul 30 07:59:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6DA91A0180 for ; Wed, 30 Jul 2014 07:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdkxnKDOjqh8 for ; Wed, 30 Jul 2014 07:58:57 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9271A017F for ; Wed, 30 Jul 2014 07:58:57 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id EB6E8C193; Wed, 30 Jul 2014 10:58:56 -0400 (EDT) Date: Wed, 30 Jul 2014 10:58:56 -0400 From: Jeffrey Haas To: Benoit Claise Message-ID: <20140730145856.GL29365@pfrc> References: <20140722150553.GB12083@elstar.local> <53CEA093.2070000@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53CEA093.2070000@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/M6awtOA5tPCkc6WgtI13KkRXFBE Cc: Kiran Agrahara Sreenivasa , "netmod@ietf.org" Subject: Re: [netmod] Syslog YANG Model Presentation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 14:58:58 -0000 Benoit, On Tue, Jul 22, 2014 at 01:34:11PM -0400, Benoit Claise wrote: > >PS: I think you should also refer to the standards-track version of > > SYSLOG (RFC 5424) in the references and perhaps filters should > > also be able to operate on structured content. > Is RFC 5424 actually deployed? Juniper has supported it for years. -- Jeff From nobody Wed Jul 30 08:23:16 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251441A005C for ; Wed, 30 Jul 2014 08:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhVlGISPCyGL for ; Wed, 30 Jul 2014 08:23:09 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05E531A020A for ; Wed, 30 Jul 2014 08:21:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3055; q=dns/txt; s=iport; t=1406733720; x=1407943320; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=sgJylycUQoycgjhenWRpFlJTJk8OjusRq33h7QVZ1p4=; b=nGDW1FNLOR/Er49t+6kWXLvevdA9QN6VuKV3n9aUamA4zdtUBSJvTWys QlSj/YkP7MpdSCc1ov7OOWAtNply48NkvrtzQ06QJGL9Wh53TeKcVmUcN f/K7VpzAv4MgZX48ThVOgQrUApKkWkWbBjFZmqkzmgJjtev6D9MlAPlSp U=; X-IronPort-AV: E=Sophos;i="5.01,764,1400025600"; d="scan'208,217";a="126877562" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 30 Jul 2014 15:21:57 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6UFLv5X012386; Wed, 30 Jul 2014 15:21:57 GMT Message-ID: <53D90D95.5090001@cisco.com> Date: Wed, 30 Jul 2014 17:21:57 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jeffrey Haas References: <20140722150553.GB12083@elstar.local> <53CEA093.2070000@cisco.com> <20140730145856.GL29365@pfrc> In-Reply-To: <20140730145856.GL29365@pfrc> Content-Type: multipart/alternative; boundary="------------080204010600040104000302" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/KOdz9G1JfQU9V4OqHxP5m9psW7M Cc: lonvick@gmail.com, Kiran Agrahara Sreenivasa , "netmod@ietf.org" , rgerhards@hq.adiscon.com Subject: Re: [netmod] Syslog YANG Model Presentation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 15:23:13 -0000 This is a multi-part message in MIME format. --------------080204010600040104000302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jeff, Thanks. So I guess we need to support RFC 5424, RFC 5425, and RFC 5426 configuration in the YANG model, right? You use only vendor specific STRUCTURED-DATA? Because I don't see many in theIANA registry , and http://tools.ietf.org/html/rfc5424#section-9.2 requests IANA registration. If my memory serves me well (I copied a couple of old timers), the STRUCTURED-DATA goal was to standardize the syslog message content in the industry, but that did not happen. Regards, Benoit > Benoit, > > On Tue, Jul 22, 2014 at 01:34:11PM -0400, Benoit Claise wrote: >>> PS: I think you should also refer to the standards-track version of >>> SYSLOG (RFC 5424) in the references and perhaps filters should >>> also be able to operate on structured content. >> Is RFC 5424 actually deployed? > Juniper has supported it for years. > > -- Jeff > . > --------------080204010600040104000302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Jeff,

Thanks.
So I guess we need to support RFC 5424, RFC 5425, and RFC 5426 configuration in the YANG model, right?
You use only vendor specific STRUCTURED-DATA? Because I don't see many in the IANA registry, and http://tools.ietf.org/html/rfc5424#section-9.2 requests IANA registration.

If my memory serves me well (I copied a couple of old timers), the STRUCTURED-DATA goal was to standardize the syslog message content in the industry, but that did not happen.

Regards, Benoit
Benoit,

On Tue, Jul 22, 2014 at 01:34:11PM -0400, Benoit Claise wrote:

PS: I think you should also refer to the standards-track version of
    SYSLOG (RFC 5424) in the references and perhaps filters should
    also be able to operate on structured content.

Is RFC 5424 actually deployed?

Juniper has supported it for years.

-- Jeff
.

--------------080204010600040104000302-- From nobody Wed Jul 30 08:32:44 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919821A01E7 for ; Wed, 30 Jul 2014 08:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pia7L3gzsWks for ; Wed, 30 Jul 2014 08:32:36 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDE81A01FA for ; Wed, 30 Jul 2014 08:31:08 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 0B03EC415; Wed, 30 Jul 2014 11:31:08 -0400 (EDT) Date: Wed, 30 Jul 2014 11:31:07 -0400 From: Jeffrey Haas To: Benoit Claise Message-ID: <20140730153107.GN29365@pfrc> References: <20140722150553.GB12083@elstar.local> <53CEA093.2070000@cisco.com> <20140730145856.GL29365@pfrc> <53D90D95.5090001@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53D90D95.5090001@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/GFQv6l2n4G0NPsZUVti353kyEfg Cc: lonvick@gmail.com, Kiran Agrahara Sreenivasa , "netmod@ietf.org" , rgerhards@hq.adiscon.com Subject: Re: [netmod] Syslog YANG Model Presentation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 15:32:38 -0000 Benoit, On Wed, Jul 30, 2014 at 05:21:57PM +0200, Benoit Claise wrote: > So I guess we need to support RFC 5424, RFC 5425, and RFC 5426 > configuration in the YANG model, right? Digging through my work archives, I appear to be speaking over-broadly. We have support for the structured syslog, but don't seem to have TLS support. > You use only vendor specific STRUCTURED-DATA? Because I don't see > many in theIANA registry , > and http://tools.ietf.org/html/rfc5424#section-9.2 requests IANA > registration. Correct, vendor specific. > If my memory serves me well (I copied a couple of old timers), the > STRUCTURED-DATA goal was to standardize the syslog message content > in the industry, but that did not happen. One of the bits of discussion in I2RS was "use RFC 5424" as part of the traceability requirements. I tend to agree that it isn't widely deployed and not heavily used when it is deployed. If I were an operator that was wanting to consume this state rather than a vendor adding more logging, I'd prefer that it be something a bit more nicely structured in an easy to parse sense. The 5424 extensions get about 90% of the way there. The last 10% would provide for actual nested data rather than simple key-value mappings. That, however, is a topic for another list. -- Jeff From nobody Wed Jul 30 08:53:53 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFD51A01AE for ; Wed, 30 Jul 2014 08:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1a_iCCsesvny for ; Wed, 30 Jul 2014 08:53:43 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFCEB1A00DA for ; Wed, 30 Jul 2014 08:53:42 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 19E4913F6A6; Wed, 30 Jul 2014 17:53:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1406735620; bh=+AwRnPzYtacviXodcS+Wxgj+HvevHGZq9fJil6TxULA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=B4t+apm1YG13QG4mvPlsJql84eYjM0Lx+60tt8WZd9z1i6OOTkVemZaOPpIqU9Au7 2wlX7jdR/n/trO8lULg7wQxQDWPpYJFqInymNr4Ed1sDQUXFZll26r38R86mstbzCe jG9JGK1Pl5qz0L5Fq9OcDVE7GVVnD9rtmnD30XmA= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140730130412.GB61698@elstar.local> Date: Wed, 30 Jul 2014 17:53:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140728121328.GA55631@elstar.local> <5392C525-EB34-4E8A-BB39-B1464E4DE4C9@nic.cz> <20140730110826.GE61382@elstar.local> <20140730130412.GB61698@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Vjaddc9XkQKPCkTyBh-GSmGLsyM Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 15:53:45 -0000 On 30 Jul 2014, at 15:04, Juergen Schoenwaelder = wrote: > On Wed, Jul 30, 2014 at 02:50:27PM +0200, Ladislav Lhotka wrote: >>=20 >> Well, the alternatives (i.e. either using full URI as a part of = attribute name or mimicking somehow the XML prefix-URI mapping) are = really anti-JSON, and they would also be confusing in the context of the = YANG-JSON mapping. >>=20 >=20 > Not sure what defines anti-JSON, i.e. why using a namespace URI would > violate something that a module name does not violate. The URIs we use for YANG modules are 40-50 characters long and they = would have to be used with every occurrence of such an attribute. = However, if there was consensus on doing it this way, I won=92t object. =93Backporting=94 the heavyweight XML features to JSON really begs the = question of why to use JSON instead of XML in the first place. >=20 >>> make conversions between XML representation and JSON representation >>> more difficult since you need to know how to make the namespace >>> identifiers. >>=20 >> This is already done for YANG data nodes anyway. >>=20 >=20 > Yes, I understand that. Even if we make this assumption, I think it > would be good to spell this out explicitely right upfront so that > people know that a translation without knowledge of data models was > not a goal of the design. I am sure people will try to do this and we > better make sure everybody understands upfront that this won't work. I think it is quite clearly said in the introduction. >=20 >>> That said, I do think that for the JSON mapping document, it is = enough >>> to say how things are encoded. I think it is not the job of the >>> document to define the whole process around attributes. I do >>=20 >> Saying that the namespace identifier is a module name without giving = any guidelines about how to choose this module would be rather weird and = won=92t help implementors. >>=20 >=20 > I have been told implementors already do some of this and this is why Unfortunately, RESTCONF I-D gives no concrete information about encoding = and namespace of metadata that are =93commonly used=94. > we should worry about attribute encoding. Now you are saying this does > not help implementors. Sounds like a contradiction? I think you are > looking for interoperability of attributes. Well, as long as we have Most XML attributes carry no namespace because they are tightly bound to = their parent elements in the schema. YANG doesn=92t have this kind of = attributes though. On the other hand, global attributes that can be attached anywhere, such = as xml:lang, are almost always defined with a namespace, and presumably = it will also be the case with attributes defined in the future for use = with YANG data. I don=92t think that simply dropping the namespace = information is a good idea. > no mechanism to really define them, they are by definition > non-interoperable. So why then define their encoding? Well, it gives > us at least an interoperable way to communicate attributes, which may > be better than non-interoperable solutions to encode attributes. >=20 >>> understand that this makes the solution somewhat incomplete but it >>> allows us to finish this document now and to move forward. >>=20 >> That is my priority, too. >=20 > Good. So what speaks against saying that if attribute names clash and > if attributes are scoped by a module name, then the encoding is XYZ? I thought YANG 1.1 was a good opportunity to decide about how to do this = scoping, provided that standard attributes are really needed. Lada > This allows future specifications to define further rules as needed. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 30 09:02:34 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8841A024E for ; Wed, 30 Jul 2014 09:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDqIttSM6xMg for ; Wed, 30 Jul 2014 09:02:30 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E8161A00DD for ; Wed, 30 Jul 2014 09:02:30 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 6F0B013F64E; Wed, 30 Jul 2014 18:02:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1406736148; bh=ewhsWjiibkgWRACYQhESwCHHBO+L44h76efKsjhawWg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ryKGZgyiKLYH5XwdGbGWrinobsybINXkzITpRksHOFL+BB/chWmtOXF4S8iNbkQ/0 rPgqhIjBf5k4PzDzKOTSEtp9sG8VEFSpM2nJHU1lEB8hxtnq2cKnipejQDa5UHk96T vADpvPKPOY95i4MMcXnZqJ8Q2AuUNXDeA+PXZoSk= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140730125344.GA61698@elstar.local> Date: Wed, 30 Jul 2014 18:02:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6A005E99-9AF5-45F0-87AC-365CCBFE1440@nic.cz> References: <20140730125344.GA61698@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/13P73-xvIBDR9kjWgaa4cBgka-I Cc: "netmod@ietf.org" Subject: Re: [netmod] NetConf Operational Model Question X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 16:02:31 -0000 On 30 Jul 2014, at 14:53, Juergen Schoenwaelder = wrote: > On Wed, Jul 30, 2014 at 12:19:42PM +0000, Clyde Wildes (cwildes) = wrote: >> Hi, >>=20 >> Some operational data reflects data in the running config. Examples = from >> IETF models: >> - the IETF routing model duplicates most leafs but not all - >> routing-instance, rib-name, rib address-family, rib recipient-ribs, >> route-filter. >> - the ietf-interfaces model duplicates some leafs but not all - name, = type. >>=20 >> Under what conditions is it acceptable or desirable to model data = that is >> available as part of the running config as operational data? >=20 > There is some discussion in section 4.3 of RFC 6244 but this RFC also > predates some of the newer datamodels. In short, whenever there is a > chance that what operationally is used may be different from what is > configured, then it makes sense to clearly separate operational state > from configuration state. Example: You have a set of configured static > routes. But in addition, you have routes picked up from a routing > protocol. So what is operationally being used is likely different from > what you have configured. The same can be true for certain properties > of network interfaces. Static routes are actually an example where the configuration doesn=92t = exactly mirror state data: static routes only exist configuration. In = operational state, these routes appear in RIBs, together with routes = from routing protocols. Lada >=20 > Note that the operational state often is similar but not identical to > operational state. An interface supporting 'simplex' and 'duplex' > operation can often be configured to be in 'auto' mode while it > operationally ends up in being in either 'simplex' or 'duplex' mode. > You can configure to be 'up' but it might be operationally 'down' > (e.g. the cable was not plugged in). >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 30 09:29:19 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5CA61A02E3 for ; Wed, 30 Jul 2014 09:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.052 X-Spam-Level: X-Spam-Status: No, score=-0.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_64=0.6, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ooHDzUo2tdz for ; Wed, 30 Jul 2014 09:29:16 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1E961A02E8 for ; Wed, 30 Jul 2014 09:29:06 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 1554213F64E; Wed, 30 Jul 2014 18:29:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1406737745; bh=22BXPgEfMUmAVoTOxN1+frSoR39ofzlw/di61W2zMyY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=PSBzoO2bNfAPkOxHfJjmdofbO0ZO3xXc5O6kBh1kMRqBfgkhRpNr8nQ+BklYD4IKi QtX1WqDLNRVX4DamFmm9EiajQ0vjgbwfthEQphMbN2fjmedpnu8Z+L/K4HdSnjrU++ f1qcsOcUdyK6f5z4Woy0mcZfeGWo2fgGStTkEByI= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 30 Jul 2014 18:28:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3BC2A86B-C657-43F4-8908-B188D9D3674B@nic.cz> References: To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/gZHl0-1J_Ewv2jr7Xv86ylid6uQ Cc: "netmod@ietf.org" Subject: Re: [netmod] NetConf Operational Model Question X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 16:29:17 -0000 On 30 Jul 2014, at 16:08, Andy Bierman wrote: >=20 >=20 >=20 > On Wed, Jul 30, 2014 at 5:31 AM, Patrick Gili (pgili) = wrote: > Clyde, >=20 > This doesn=B9t make sense. Read section 5.1 of RFC 6241 to better > understand why I think so. >=20 >=20 > The running configuration contains only the config=3Dtrue subset of = all > YANG data nodes. >=20 > IMO, the only reason to replicate the configuration structure = (non-terminals, keys) > in operational state (like ietf-interfaces) is because the state can = exist independently > of the configuration. Most of the time, this is a bad idea and = doesn't really make sense. I don=92t agree. This is what I read in sec. 3 of RFC 3535: 2. It is necessary to make a clear distinction between configuration data, data that describes operational state and statistics. Some devices make it very hard to determine which parameters were administratively configured and which were obtained via other mechanisms such as routing protocols. 3. It is required to be able to fetch separately configuration data, operational state data, and statistics from devices, and to be able to compare these between devices. See also sec. 3 in http://tools.ietf.org/html/draft-tp-i2rs-yang-00 >=20 > - Can the data structure being modeled exist on its own as state = without any config? > If yes then dual data structures are needed. >=20 > - e.g., What does it mean if an interface is reported as state but = does not > exist in the configuration? (I sure don't know) If you boot a Linux box, interfaces like =93eth0=94 appear before you = get a chance to configure anything (we call it system-controlled = interfaces) >=20 > - How many of the leafs (properties) of the configured data = structure can > be changed by means other than configuration edits? If none or = very few, > then duplicating the data as config and state is not needed. Pretty much everything on systems that aren=92t stricty NETCONF-centric. = A generic operating system doesn=92t give a damn about NETCONF.=20 >=20 > - Does the operator need to know the operational state values that = are overriding > specific configured values? What breaks if the operator thinks the = configured > value is in use but it is a different value? For example, it is usually useful to know the IP address the system is = really using on an interface. Lada >=20 > =20 >=20 > -Patrick >=20 >=20 > Andy > =20 >=20 > On 7/30/14, 8:19 AM, "Clyde Wildes (cwildes)" = wrote: >=20 > >Hi, > > > >Some operational data reflects data in the running config. Examples = from > >IETF models: > >- the IETF routing model duplicates most leafs but not all - > >routing-instance, rib-name, rib address-family, rib recipient-ribs, > >route-filter. > >- the ietf-interfaces model duplicates some leafs but not all - name, > >type. > > > >Under what conditions is it acceptable or desirable to model data = that is > >available as part of the running config as operational data? > > > >Looking at the existing models I could not see a pattern. > > > >Thanks, > > > >Clyde > > > > > >_______________________________________________ > >netmod mailing list > >netmod@ietf.org > >https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 30 09:41:30 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43671A01FF for ; Wed, 30 Jul 2014 09:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ph5NrEsJgdJz for ; Wed, 30 Jul 2014 09:41:25 -0700 (PDT) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A93081A01A8 for ; Wed, 30 Jul 2014 09:41:25 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id q108so1894802qgd.23 for ; Wed, 30 Jul 2014 09:41:24 -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=HLXAdOWqhJNkoxd0K8EkvUvsivcMBpKUCQrJVp/3Oyo=; b=TfU7SArnmKx5a/lNpwGwXLVesn91W1EJ4CFNmtdhljq7R3A06Hyw+YkSTn0O87td8J fu/wH9Lpp3pdSBnNuDMLOFy+SjveAAJLqE9jFg3G/A99rl1vfBWlGYZvfQW+Xh15KHxv 6kvWn3Ny+YG1tmkgx8wpnIviI9+FqxK2YUxko4G159sqYH449l0Uvg5lqnNQpsrsmnf+ CSIefmvvUwCnX0LvmmaXBwv2kz1kGeWfZqNhQwM4wG/5rckfQVNyCXh8wPnxPmffHBtB qg9TF4do7jwmsz3yGZAgFUqH1LXITrjG1hTMqDhTu7KLBYtOzAN6Bo1WVUtzn6IW27KU zLhg== X-Gm-Message-State: ALoCoQnazckyBa1fg3EQnxmSiLhdCsTdARiRvZZyvNpqWjsc7ox6KR2giqAJb+sHzjYzko9xCxbt MIME-Version: 1.0 X-Received: by 10.229.191.2 with SMTP id dk2mr8716065qcb.8.1406738484842; Wed, 30 Jul 2014 09:41:24 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Wed, 30 Jul 2014 09:41:24 -0700 (PDT) In-Reply-To: <3BC2A86B-C657-43F4-8908-B188D9D3674B@nic.cz> References: <3BC2A86B-C657-43F4-8908-B188D9D3674B@nic.cz> Date: Wed, 30 Jul 2014 09:41:24 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1133979eae6c6804ff6bd3a6 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/jeR4yJDUFQ77zHPa6TuBwID2f5U Cc: "netmod@ietf.org" Subject: Re: [netmod] NetConf Operational Model Question X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 16:41:29 -0000 --001a1133979eae6c6804ff6bd3a6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 30, 2014 at 9:28 AM, Ladislav Lhotka wrote: > > On 30 Jul 2014, at 16:08, Andy Bierman wrote: > > > > > > > > > On Wed, Jul 30, 2014 at 5:31 AM, Patrick Gili (pgili) > wrote: > > Clyde, > > > > This doesn=B9t make sense. Read section 5.1 of RFC 6241 to better > > understand why I think so. > > > > > > The running configuration contains only the config=3Dtrue subset of all > > YANG data nodes. > > > > IMO, the only reason to replicate the configuration structure > (non-terminals, keys) > > in operational state (like ietf-interfaces) is because the state can > exist independently > > of the configuration. Most of the time, this is a bad idea and doesn't > really make sense. > > I don't agree. This is what I read in sec. 3 of RFC 3535: > > 2. It is necessary to make a clear distinction between configuration > data, data that describes operational state and statistics. Some > devices make it very hard to determine which parameters were > administratively configured and which were obtained via other > mechanisms such as routing protocols. > > That's why we have a separate operation. It makes it very easy to prune out all the state data. The tree abstraction is just an API. The XML is just a representation. A server implementation is free to organize data any way it wants. YANG supports many ways to organize data any way that seems right for a particular data model. IMO it is a waste of time to force one way or another. Perhaps the YANG Patterns draft will make the design choices easier to understand. 3. It is required to be able to fetch separately configuration data, > operational state data, and statistics from devices, and to be > able to compare these between devices. > So? We have . Anybody can write an RPC that retrieves only state (see in NETCONF-EX). Any offline tool can also separate data for comparison, based on the value of the config-stmt. > > See also sec. 3 in > > http://tools.ietf.org/html/draft-tp-i2rs-yang-00 > > > > > - Can the data structure being modeled exist on its own as state > without any config? > > If yes then dual data structures are needed. > > > > - e.g., What does it mean if an interface is reported as state but > does not > > exist in the configuration? (I sure don't know) > > If you boot a Linux box, interfaces like "eth0" appear before you get a > chance to configure anything (we call it system-controlled interfaces) > So an implementation would populate on interface-state, and nothing in interface? So an admin (or even root) can never change anything on 'eth0'? So is there is an entry for 'eth0' in the interface list? > > > > > - How many of the leafs (properties) of the configured data structure > can > > be changed by means other than configuration edits? If none or very > few, > > then duplicating the data as config and state is not needed. > > Pretty much everything on systems that aren't stricty NETCONF-centric. A > generic operating system doesn't give a damn about NETCONF huh? Servers are implemented so that any protocol that changes config are supposed to reflect the config changes in NETCONF. It cost memory to duplicate trees for no good reason. These are design choices the YANG model authos need to consider. YANG doesn't care which design you use. > . > > > > > - Does the operator need to know the operational state values that are > overriding > > specific configured values? What breaks if the operator thinks the > configured > > value is in use but it is a different value? > > For example, it is usually useful to know the IP address the system is > really using on an interface. > I am just trying to provide some questions designers should consider instead of blindly copying one module or another. > > Lada > > Andy > > > > > > > > -Patrick > > > > > > Andy > > > > > > On 7/30/14, 8:19 AM, "Clyde Wildes (cwildes)" wrote= : > > > > >Hi, > > > > > >Some operational data reflects data in the running config. Examples fr= om > > >IETF models: > > >- the IETF routing model duplicates most leafs but not all - > > >routing-instance, rib-name, rib address-family, rib recipient-ribs, > > >route-filter. > > >- the ietf-interfaces model duplicates some leafs but not all - name, > > >type. > > > > > >Under what conditions is it acceptable or desirable to model data that > is > > >available as part of the running config as operational data? > > > > > >Looking at the existing models I could not see a pattern. > > > > > >Thanks, > > > > > >Clyde > > > > > > > > >_______________________________________________ > > >netmod mailing list > > >netmod@ietf.org > > >https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a1133979eae6c6804ff6bd3a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 30, 2014 at 9:28 AM, Ladislav Lhotka = <lhotka@nic.cz>= ; wrote:

On 30 Jul 2014, at 16:08, Andy Bierman <andy@yumaworks.com> wrote:

>
>
>
> On Wed, Jul 30, 2014 at 5:31 AM, Patrick Gili (pgili) <pgili@cisco.com> wrote:
> Clyde,
>
> This doesn=B9t make sense.  Read section 5.1 of RFC 6241 to bette= r
> understand why I think so.
>
>
> The running configuration contains only the config=3Dtrue subset of al= l
> YANG data nodes.
>
> IMO, the only reason to replicate the configuration structure (non-ter= minals, keys)
> in operational state (like ietf-interfaces) is because the state can e= xist independently
> of the configuration.  Most of the time, this is a bad idea and d= oesn't really make sense.

I don’t agree. This is what I read in sec. 3 of RFC 3535:

   2.  It is necessary to make a clear distinction between c= onfiguration
       data, data that describes operational state and = statistics.  Some
       devices make it very hard to determine which par= ameters were
       administratively configured and which were obtai= ned via other
       mechanisms such as routing protocols.


That's why we have a separate <= get-config> operation.
It makes it very easy to prune out all = the state data.

The tree abstraction is just an AP= I. The XML is just a representation.
A server implementation is free to organize data any way it wants.

YANG supports many ways to organize data any way that= seems right
for a particular data model.  IMO it is a waste= of time to force one
way or another.  Perhaps the YANG Patterns draft will make the
design choices easier to understand.


<= /div>

   3.  It is required to be able to fetch separately configu= ration data,
       operational state data, and statistics from devi= ces, and to be
       able to compare these between devices.

So? We have <get-config>.
Anybod= y can write an RPC that retrieves only state (see <get2> in NETCONF-E= X).


Any offline tool can also separate data for compa= rison, based on the
value of the config-stmt.

 

See also sec. 3 in

http://tools.ietf.org/html/draft-tp-i2rs-yang-00

>
>   - Can the data structure being modeled exist on its own as stat= e without any config?
>     If yes then dual data structures are needed.
>
>   - e.g., What does it mean if an interface is reported as state = but does not
>     exist in the configuration?  (I sure don't know= )

If you boot a Linux box, interfaces like “eth0” appear before y= ou get a chance to configure anything (we call it system-controlled interfa= ces)

So an implementation would populat= e on interface-state, and nothing
in interface? So an admin (or even root) can never
change an= ything on 'eth0'?  So is there is an entry
for '= eth0' in the interface list?

 

>
>   - How many of the leafs (properties) of the configured data str= ucture can
>     be changed by means other than configuration edits? If n= one or very few,
>     then duplicating the data as config and state is not nee= ded.

Pretty much everything on systems that aren’t stricty NETCONF-centric= . A generic operating system doesn’t give a damn about NETCONF


huh?  Servers are implemented= so that any protocol that changes config are
supposed to reflect the config changes in NETCONF.

It cost memory to duplicate trees for no good reason.
These= are design choices the YANG model authos need to
consider.  = ;YANG doesn't care which design you use.
 
.

>
>  - Does the operator need to know the operational state values th= at are overriding
>    specific configured values? What breaks if the operator t= hinks the configured
>    value is in use but it is a different value?

For example, it is usually useful to know the IP address the system is real= ly using on an interface.

I am just try= ing to provide some questions designers should consider instead of blindly<= /div>
copying one module or another.

 

Lada



Andy
 
>
>
>
> -Patrick
>
>
> Andy
>
>
> On 7/30/14, 8:19 AM, "Clyde Wildes (cwildes)" <cwildes@cisco.com> wrote:
>
> >Hi,
> >
> >Some operational data reflects data in the running config. Example= s from
> >IETF models:
> >- the IETF routing model duplicates most leafs but not all -
> >routing-instance, rib-name, rib address-family, rib recipient-ribs= ,
> >route-filter.
> >- the ietf-interfaces model duplicates some leafs but not all - na= me,
> >type.
> >
> >Under what conditions is it acceptable or desirable to model data = that is
> >available as part of the running config as operational data?
> >
> >Looking at the existing models I could not see a pattern.
> >
> >Thanks,
> >
> >Clyde
> >
> >
> >_______________________________________________
> >netmod mailing list
> >netmod@ietf.org
> >https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--001a1133979eae6c6804ff6bd3a6-- From nobody Wed Jul 30 10:57:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666A81A02BC for ; Wed, 30 Jul 2014 10:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.052 X-Spam-Level: X-Spam-Status: No, score=-0.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_64=0.6, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZMUpc0_7p3v for ; Wed, 30 Jul 2014 10:57:04 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49A791A029D for ; Wed, 30 Jul 2014 10:57:04 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 34CC213F64E; Wed, 30 Jul 2014 19:57:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1406743022; bh=tlYzcerqdgQFFOjXXGWFZmifCGomfkeAjC+9DOU55Fg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=OhVCIeCk6JMze/0Twa4YDjSESYNGBLsX4mj9szpevy37w1+WdvO77gaDNAWJpSzq5 eAZ8rjxntZwZgXd2U/HGNMJRbpCy+denvrsfcNuWWxCIMfVheLDFboDhqX0xLVGpD/ IdbO5uTkyBZHhg7Nf0jo2mJwDgX7ISLv3LrCtOFI= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 30 Jul 2014 19:56:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3BC2A86B-C657-43F4-8908-B188D9D3674B@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/rC_pW-aAnqocHATUFUc_aBUXvW8 Cc: "netmod@ietf.org" Subject: Re: [netmod] NetConf Operational Model Question X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 17:57:06 -0000 On 30 Jul 2014, at 18:41, Andy Bierman wrote: >=20 >=20 >=20 > On Wed, Jul 30, 2014 at 9:28 AM, Ladislav Lhotka = wrote: >=20 > On 30 Jul 2014, at 16:08, Andy Bierman wrote: >=20 > > > > > > > > On Wed, Jul 30, 2014 at 5:31 AM, Patrick Gili (pgili) = wrote: > > Clyde, > > > > This doesn=B9t make sense. Read section 5.1 of RFC 6241 to better > > understand why I think so. > > > > > > The running configuration contains only the config=3Dtrue subset of = all > > YANG data nodes. > > > > IMO, the only reason to replicate the configuration structure = (non-terminals, keys) > > in operational state (like ietf-interfaces) is because the state can = exist independently > > of the configuration. Most of the time, this is a bad idea and = doesn't really make sense. >=20 > I don=92t agree. This is what I read in sec. 3 of RFC 3535: >=20 > 2. It is necessary to make a clear distinction between = configuration > data, data that describes operational state and statistics. = Some > devices make it very hard to determine which parameters were > administratively configured and which were obtained via other > mechanisms such as routing protocols. >=20 >=20 > That's why we have a separate operation. > It makes it very easy to prune out all the state data. >=20 > The tree abstraction is just an API. The XML is just a representation. > A server implementation is free to organize data any way it wants. It is not about data organization but rather about the ability "to = determine which parameters were administratively configured and which = were obtained via other mechanisms such as routing protocols.=94 >=20 > YANG supports many ways to organize data any way that seems right > for a particular data model. IMO it is a waste of time to force one > way or another. Perhaps the YANG Patterns draft will make the > design choices easier to understand. >=20 >=20 >=20 > 3. It is required to be able to fetch separately configuration = data, > operational state data, and statistics from devices, and to be > able to compare these between devices. >=20 > So? We have . > Anybody can write an RPC that retrieves only state (see in = NETCONF-EX). Not if state data are buried inside configuration and a particular = instance has no configuration (yet).=20 >=20 >=20 > Any offline tool can also separate data for comparison, based on the > value of the config-stmt. >=20 > =20 >=20 > See also sec. 3 in >=20 > http://tools.ietf.org/html/draft-tp-i2rs-yang-00 >=20 > > > > - Can the data structure being modeled exist on its own as state = without any config? > > If yes then dual data structures are needed. > > > > - e.g., What does it mean if an interface is reported as state but = does not > > exist in the configuration? (I sure don't know) >=20 > If you boot a Linux box, interfaces like =93eth0=94 appear before you = get a chance to configure anything (we call it system-controlled = interfaces) >=20 > So an implementation would populate on interface-state, and nothing > in interface? So an admin (or even root) can never > change anything on 'eth0'? So is there is an entry > for 'eth0' in the interface list? >=20 Please read about system-controlled interfaces in RFC 7223. > =20 >=20 > > > > - How many of the leafs (properties) of the configured data = structure can > > be changed by means other than configuration edits? If none or = very few, > > then duplicating the data as config and state is not needed. >=20 > Pretty much everything on systems that aren=92t stricty = NETCONF-centric. A generic operating system doesn=92t give a damn about = NETCONF >=20 >=20 > huh? Servers are implemented so that any protocol that changes config = are > supposed to reflect the config changes in NETCONF. Which servers? Do you think =93ifconfig" or =93ip=94 behave this way? = What if something changes in operational state and the config datastore = is locked? Lada >=20 > It cost memory to duplicate trees for no good reason. > These are design choices the YANG model authos need to > consider. YANG doesn't care which design you use. > =20 > . >=20 > > > > - Does the operator need to know the operational state values that = are overriding > > specific configured values? What breaks if the operator thinks = the configured > > value is in use but it is a different value? >=20 > For example, it is usually useful to know the IP address the system is = really using on an interface. >=20 > I am just trying to provide some questions designers should consider = instead of blindly > copying one module or another. >=20 > =20 >=20 > Lada >=20 >=20 >=20 > Andy > =20 > > > > > > > > -Patrick > > > > > > Andy > > > > > > On 7/30/14, 8:19 AM, "Clyde Wildes (cwildes)" = wrote: > > > > >Hi, > > > > > >Some operational data reflects data in the running config. Examples = from > > >IETF models: > > >- the IETF routing model duplicates most leafs but not all - > > >routing-instance, rib-name, rib address-family, rib recipient-ribs, > > >route-filter. > > >- the ietf-interfaces model duplicates some leafs but not all - = name, > > >type. > > > > > >Under what conditions is it acceptable or desirable to model data = that is > > >available as part of the running config as operational data? > > > > > >Looking at the existing models I could not see a pattern. > > > > > >Thanks, > > > > > >Clyde > > > > > > > > >_______________________________________________ > > >netmod mailing list > > >netmod@ietf.org > > >https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 30 11:17:31 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006C91A030E for ; Wed, 30 Jul 2014 11:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QWeBDG2gGns for ; Wed, 30 Jul 2014 11:17:24 -0700 (PDT) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D9741A02FA for ; Wed, 30 Jul 2014 11:17:23 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id i50so2262405qgf.34 for ; Wed, 30 Jul 2014 11:17:22 -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=s0VCh+J9KI/nSVAH8gPwunZq19bEQkgNveMfYcEip3M=; b=F/EFGdYBbBMuvRQwquGeMtgtubzPGO50GKwFRyN2ZlhDJIbgRXz7a1hwcxSd8ac791 aTBytNTHuJWWVfFMEFoSJVtt2RajquRyOEY2xVcq1Y8UbSyvP51ZwJR0S0f3UjevioKk VIe6wxoujK88C3nWcMwOtDZ5rYAVwlTlBT9lQugEyOtlJnC7V+4wL7BppmeA6ZRrBN+n vbB4YGx8dAQDWcoHfMfgwHQK+KdljW6xB98J/yZC6buH/2bdBn+OGp1Tjo/I82GsLurb J5gXgwCGEdXgQkYmDFMqm7tQotn1CHBp9gDft9laxx8iQxF/7WaZacnxwOaq/WyGqldw xbxA== X-Gm-Message-State: ALoCoQkOsGgWQboO0Jg3N3vqXjR/L/U85DM6A571M5oH0B070nPgQFbT0ViObQzJPTnkjf1/GVCk MIME-Version: 1.0 X-Received: by 10.224.112.1 with SMTP id u1mr9327173qap.7.1406744242564; Wed, 30 Jul 2014 11:17:22 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Wed, 30 Jul 2014 11:17:22 -0700 (PDT) In-Reply-To: References: <3BC2A86B-C657-43F4-8908-B188D9D3674B@nic.cz> Date: Wed, 30 Jul 2014 11:17:22 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7b673a4ede4c7f04ff6d2ab6 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/U3kf1uUmAflGIjTrQSjgabtd65c Cc: "netmod@ietf.org" Subject: Re: [netmod] NetConf Operational Model Question X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 18:17:29 -0000 --047d7b673a4ede4c7f04ff6d2ab6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 30, 2014 at 10:56 AM, Ladislav Lhotka wrote: > > On 30 Jul 2014, at 18:41, Andy Bierman wrote: > > > > > > > > > On Wed, Jul 30, 2014 at 9:28 AM, Ladislav Lhotka wrote: > > > > On 30 Jul 2014, at 16:08, Andy Bierman wrote: > > > > > > > > > > > > > > On Wed, Jul 30, 2014 at 5:31 AM, Patrick Gili (pgili) > wrote: > > > Clyde, > > > > > > This doesn=B9t make sense. Read section 5.1 of RFC 6241 to better > > > understand why I think so. > > > > > > > > > The running configuration contains only the config=3Dtrue subset of a= ll > > > YANG data nodes. > > > > > > IMO, the only reason to replicate the configuration structure > (non-terminals, keys) > > > in operational state (like ietf-interfaces) is because the state can > exist independently > > > of the configuration. Most of the time, this is a bad idea and > doesn't really make sense. > > > > I don't agree. This is what I read in sec. 3 of RFC 3535: > > > > 2. It is necessary to make a clear distinction between configuratio= n > > data, data that describes operational state and statistics. Som= e > > devices make it very hard to determine which parameters were > > administratively configured and which were obtained via other > > mechanisms such as routing protocols. > > > > > > That's why we have a separate operation. > > It makes it very easy to prune out all the state data. > > > > The tree abstraction is just an API. The XML is just a representation. > > A server implementation is free to organize data any way it wants. > > It is not about data organization but rather about the ability "to > determine which parameters were administratively configured and which wer= e > obtained via other mechanisms such as routing protocols." > You can do that with YANG. Separate the config and non-config in different modules if you want. What is your point? Every data model will have different requirements and design considerations. You pointed out a couple that you prefer to keep as separate trees. That doesn't mean every YANG model will need to do that. E.g. -- If I want to maintain counters associated with some config (ACL rule hits, RMON host table counters) then adding config=3Dfalse under the config for some collection works great= . > > > > YANG supports many ways to organize data any way that seems right > > for a particular data model. IMO it is a waste of time to force one > > way or another. Perhaps the YANG Patterns draft will make the > > design choices easier to understand. > > > > > > > > 3. It is required to be able to fetch separately configuration data= , > > operational state data, and statistics from devices, and to be > > able to compare these between devices. > > > > So? We have . > > Anybody can write an RPC that retrieves only state (see in > NETCONF-EX). > > Not if state data are buried inside configuration and a particular > instance has no configuration (yet). > Yes, we already went over this -- if the state can exist independent of the config then it cannot be under the config. Then the YANG designer will not do that because this data model needs separate config and state. Andy > > > > > > > Any offline tool can also separate data for comparison, based on the > > value of the config-stmt. > > > > > > > > See also sec. 3 in > > > > http://tools.ietf.org/html/draft-tp-i2rs-yang-00 > > > > > > > > - Can the data structure being modeled exist on its own as state > without any config? > > > If yes then dual data structures are needed. > > > > > > - e.g., What does it mean if an interface is reported as state but > does not > > > exist in the configuration? (I sure don't know) > > > > If you boot a Linux box, interfaces like "eth0" appear before you get a > chance to configure anything (we call it system-controlled interfaces) > > > > So an implementation would populate on interface-state, and nothing > > in interface? So an admin (or even root) can never > > change anything on 'eth0'? So is there is an entry > > for 'eth0' in the interface list? > > > > Please read about system-controlled interfaces in RFC 7223. > > I did. Just because 1 module is designed this way doesn't mean every module should be the same. You want to have some magic state that is editable by the client, and comes back after a reboot? I prefer to think of it as server-created config. Our server supports this sort of write limitation on a config=3Dtrue node. > > > > > > > > > > - How many of the leafs (properties) of the configured data > structure can > > > be changed by means other than configuration edits? If none or > very few, > > > then duplicating the data as config and state is not needed. > > > > Pretty much everything on systems that aren't stricty NETCONF-centric. = A > generic operating system doesn't give a damn about NETCONF > > > > > > huh? Servers are implemented so that any protocol that changes config > are > > supposed to reflect the config changes in NETCONF. > > Which servers? Do you think "ifconfig" or "ip" behave this way? What if > something changes in operational state and the config datastore is locked= ? > If somebody writes a NETCONF server they are responsible to make it work correctly. Not the IETF's problem to design an open API on Linux to support NETCONF. > > Lada > > Andy > > > > It cost memory to duplicate trees for no good reason. > > These are design choices the YANG model authos need to > > consider. YANG doesn't care which design you use. > > > > . > > > > > > > > - Does the operator need to know the operational state values that > are overriding > > > specific configured values? What breaks if the operator thinks the > configured > > > value is in use but it is a different value? > > > > For example, it is usually useful to know the IP address the system is > really using on an interface. > > > > I am just trying to provide some questions designers should consider > instead of blindly > > copying one module or another. > > > > > > > > Lada > > > > > > > > Andy > > > > > > > > > > > > > > -Patrick > > > > > > > > > Andy > > > > > > > > > On 7/30/14, 8:19 AM, "Clyde Wildes (cwildes)" > wrote: > > > > > > >Hi, > > > > > > > >Some operational data reflects data in the running config. Examples > from > > > >IETF models: > > > >- the IETF routing model duplicates most leafs but not all - > > > >routing-instance, rib-name, rib address-family, rib recipient-ribs, > > > >route-filter. > > > >- the ietf-interfaces model duplicates some leafs but not all - name= , > > > >type. > > > > > > > >Under what conditions is it acceptable or desirable to model data > that is > > > >available as part of the running config as operational data? > > > > > > > >Looking at the existing models I could not see a pattern. > > > > > > > >Thanks, > > > > > > > >Clyde > > > > > > > > > > > >_______________________________________________ > > > >netmod mailing list > > > >netmod@ietf.org > > > >https://www.ietf.org/mailman/listinfo/netmod > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --047d7b673a4ede4c7f04ff6d2ab6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 30, 2014 at 10:56 AM, Ladislav Lhotka <lhotka@nic.cz&g= t; wrote:

On 30 Jul 2014, at 18:41, Andy Bierman <andy@yumaworks.com> wrote:

>
>
>
> On Wed, Jul 30, 2014 at 9:28 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> On 30 Jul 2014, at 16:08, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> >
> > On Wed, Jul 30, 2014 at 5:31 AM, Patrick Gili (pgili) <pgili@cisco.com> wrote:
> > Clyde,
> >
> > This doesn=B9t make sense.  Read section 5.1 of RFC 6241 to = better
> > understand why I think so.
> >
> >
> > The running configuration contains only the config=3Dtrue subset = of all
> > YANG data nodes.
> >
> > IMO, the only reason to replicate the configuration structure (no= n-terminals, keys)
> > in operational state (like ietf-interfaces) is because the state = can exist independently
> > of the configuration.  Most of the time, this is a bad idea = and doesn't really make sense.
>
> I don’t agree. This is what I read in sec. 3 of RFC 3535:
>
>    2.  It is necessary to make a clear distinction betw= een configuration
>        data, data that describes operational state= and statistics.  Some
>        devices make it very hard to determine whic= h parameters were
>        administratively configured and which were = obtained via other
>        mechanisms such as routing protocols.
>
>
> That's why we have a separate <get-config> operation.
> It makes it very easy to prune out all the state data.
>
> The tree abstraction is just an API. The XML is just a representation.=
> A server implementation is free to organize data any way it wants.

It is not about data organization but rather about the ability "to det= ermine which parameters were administratively configured and which were obt= ained via other mechanisms such as routing protocols.”


You can do that with YANG.
Sep= arate the config and non-config in different modules if you want.
What is your point? Every data model will have different requirements
and design considerations.  You pointed out a couple that you pre= fer to
keep as separate trees.  That doesn't mean every = YANG model
will need to do that.  E.g. -- If I want to maint= ain counters associated
with some config (ACL rule hits, RMON host table counters)
t= hen adding config=3Dfalse under the config for some collection works great.=


>
> YANG supports many ways to organize data any way that seems right
> for a particular data model.  IMO it is a waste of time to force = one
> way or another.  Perhaps the YANG Patterns draft will make the > design choices easier to understand.
>
>
>
>    3.  It is required to be able to fetch separately co= nfiguration data,
>        operational state data, and statistics from= devices, and to be
>        able to compare these between devices.
>
> So? We have <get-config>.
> Anybody can write an RPC that retrieves only state (see <get2> i= n NETCONF-EX).

Not if state data are buried inside configuration and a particular instance= has no configuration (yet).


=
Yes, we already went over this -- if the state can exist independent o= f the config
then it cannot be under the config. Then the YANG designer will not do= that
because this data model needs separate config and state.


Andy
 

>
>
> Any offline tool can also separate data for comparison, based on the > value of the config-stmt.
>
>
>
> See also sec. 3 in
>
> http://tools.ietf.org/html/draft-tp-i2rs-yang-00
>
> >
> >   - Can the data structure being modeled exist on its own as= state without any config?
> >     If yes then dual data structures are needed.
> >
> >   - e.g., What does it mean if an interface is reported as s= tate but does not
> >     exist in the configuration?  (I sure don't= know)
>
> If you boot a Linux box, interfaces like “eth0” appear bef= ore you get a chance to configure anything (we call it system-controlled in= terfaces)
>
> So an implementation would populate on interface-state, and nothing > in interface? So an admin (or even root) can never
> change anything on 'eth0'?  So is there is an entry
> for 'eth0' in the interface list?
>

Please read about system-controlled interfaces in RFC 7223.



I did. Just because 1 m= odule is designed this way doesn't mean
every module should b= e the same.  You want to have some magic state
that is edita= ble by the client, and comes back after a reboot?
I prefer to think of it as server-created config. Our server supports<= /div>
this sort of write limitation on a config=3Dtrue node.
=


 
>
>
> >
> >   - How many of the leafs (properties) of the configured dat= a structure can
> >     be changed by means other than configuration edits?= If none or very few,
> >     then duplicating the data as config and state is no= t needed.
>
> Pretty much everything on systems that aren’t stricty NETCONF-ce= ntric. A generic operating system doesn’t give a damn about NETCONF >
>
> huh?  Servers are implemented so that any protocol that changes c= onfig are
> supposed to reflect the config changes in NETCONF.

Which servers? Do you think “ifconfig" or “ip” behav= e this way? What if something changes in operational state and the config d= atastore is locked?

If somebody writes = a NETCONF server they are responsible to make it work correctly.
Not the IETF's problem to design an open API on Linux to support N= ETCONF.
 

Lada


Andy
 
>
> It cost memory to duplicate trees for no good reason.
> These are design choices the YANG model authos need to
> consider.  YANG doesn't care which design you use.
>
> .
>
> >
> >  - Does the operator need to know the operational state valu= es that are overriding
> >    specific configured values? What breaks if the opera= tor thinks the configured
> >    value is in use but it is a different value?
>
> For example, it is usually useful to know the IP address the system is= really using on an interface.
>
> I am just trying to provide some questions designers should consider i= nstead of blindly
> copying one module or another.
>
>
>
> Lada
>
>
>
> Andy
>
> >
> >
> >
> > -Patrick
> >
> >
> > Andy
> >
> >
> > On 7/30/14, 8:19 AM, "Clyde Wildes (cwildes)" <cwildes@cisco.com> wrote:
> >
> > >Hi,
> > >
> > >Some operational data reflects data in the running config. Ex= amples from
> > >IETF models:
> > >- the IETF routing model duplicates most leafs but not all -<= br> > > >routing-instance, rib-name, rib address-family, rib recipient= -ribs,
> > >route-filter.
> > >- the ietf-interfaces model duplicates some leafs but not all= - name,
> > >type.
> > >
> > >Under what conditions is it acceptable or desirable to model = data that is
> > >available as part of the running config as operational data?<= br> > > >
> > >Looking at the existing models I could not see a pattern.
> > >
> > >Thanks,
> > >
> > >Clyde
> > >
> > >
> > >_______________________________________________
> > >netmod mailing list
> > >netmod@ietf.org
> > >https://www.ietf.org/mailman/listinfo/netmod
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--047d7b673a4ede4c7f04ff6d2ab6-- From nobody Wed Jul 30 12:16:32 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253E41A03F9 for ; Wed, 30 Jul 2014 12:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOO81LC_mCHV for ; Wed, 30 Jul 2014 12:16:28 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C47E31A006C for ; Wed, 30 Jul 2014 12:16:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9381; q=dns/txt; s=iport; t=1406747787; x=1407957387; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Y+zI6nTq5/jblWra3hHethO/3I1igAwdlhf+qho7eEE=; b=hHst2ODRjNx2cbtgZ2ffHnX9/+rGsMp0+kF+Ehufcj4EWBMrj/21EXRT 78Xk0dQjXmbaR2IsEZCcBXpRXQg7U/K30ck5dJb8JfO2xFwovPGVSKqjo seaNJ0COeP5EOFWHFct1KNMcQf7cnmyojXvLBctUr9tVfvHNK3p9sehqa 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAIlD2VOtJA2B/2dsb2JhbABWA4MOUlcEyweHTwGBEBZ3hAQBAQMBOi4RDgQBCA4CJisXJQIEAQ0FiDoIwEQXBI5mCgcBQBAHEYQ5BZtklFODSWyBAwIHFwYc X-IronPort-AV: E=Sophos;i="5.01,766,1400025600"; d="scan'208";a="65251234" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP; 30 Jul 2014 19:16:26 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6UJGQsd002327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Jul 2014 19:16:26 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.216]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Wed, 30 Jul 2014 14:16:26 -0500 From: "Lisa Huang (yihuan)" To: Juergen Schoenwaelder , "draft-bogdanovic-netmod-acl-model@tools.ietf.org" Thread-Topic: review of draft-bogdanovic-netmod-acl-model-01 Thread-Index: AQHPqyuRLBbv1WyyfUmrH8r+jyfEQpu43aMA Date: Wed, 30 Jul 2014 19:16:25 +0000 Message-ID: In-Reply-To: <20140729124925.GC58615@elstar.local> 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.154.204.66] Content-Type: text/plain; charset="us-ascii" Content-ID: <25F2174AEE388D4CB7EB882E209CAA43@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/WYXlDRNgrmxtDNLy4uTWUbjf1zE Cc: "netmod@ietf.org" Subject: Re: [netmod] review of draft-bogdanovic-netmod-acl-model-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 19:16:31 -0000 Juergen, Thanks for the comments. We just learned to run pyang --ietf during Saturday session and update the model in git repository. Will definite update the draft and correct the syntaxes in the future. You raised a lot of good points in the email. I responded some of them in line. More can be discussed on Thursday meeting. Thanks, Lisa On 7/29/14 5:49 AM, "Juergen Schoenwaelder" wrote: >Hi, > >during the Sunday session before IETF 90, I got nominated to be the >Yang Doctor for draft-bogdanovic-netmod-acl-model-01. And as a >consequence, I have done a review of this I-D and since this was >submitted as a contribution to the IETF, I thought I post the review >right here. Note that many comments are not really Yang Doctors >concerns but once I review a document, I often end up reviewing the >whole thing. > >/js > >- If this document is supposed to be standards-track, then the > intended status should not be "Informational". Will change to "Standards Track" > >- The title should be more descriptive. Following recent YANG RFCs, > perhaps something like "A YANG Data Model for Network Access Control > List (ACL) Management". Will make the title more specific > >- I am not sure you define an information model and a data model. I > think you define just a data model and hence you may want to update > the abstract. And I am not sure what 'basic building blocks' means, > perhaps expand on the approach taken (i.e. that it is a basic > structure designed to be augmented). Let's discuss this on Thursday meeting. > >- The first paragraph on the introduction has singular/plural > mismatches. Will correct the grammar error. > >- Run idnits and fix lines that are too long and split the references > into normative and informative references and update any outdated > references. Will correct this. > >- Section 2: > > s/that model can be/that the model can be/ > s/Actions/actions/ > s/that augmented/that can be augmented/ Will correct these. > >- Section 3: You say that a access control list containers an ordered > set of rules. Why do you choose the term "Access Control Entry" > instead of simply "Access Control Rule"? >What is a _group of_ match > and action criteria? Why is a prefix length meta data? I mean, how > do you determine the source prefix length? According to a lookup in > the local forwarding table(s)? Is this strictly speaking meta data > or more precisely data derived from packet headers? > > s/daufault/default/ Will correct this. > >- Section 3.1: You can't write 'imports module "packet-headers" into > the match container'. While you claim it is easy to reuse > definitions of say IPFIX [RFC5101], I am not sure I see the details > how this would work. Better work out the details and then leave the > judgment whether it is easy or not to the reader. > > s/is example/is an example/ Will correct these. > > You may want to consider to describe the standard models in section > 3 and to discuss proprietary extensions in a separate section or > even an appendix to make it very clear which text is normative and > which is not. > >- Section 4.1. > > s/Access/access/ > > Make sure the YANG module passes pyang --ietf checks. Also note that > the description of the revision statement should refer to the > document defining the data model. Note that the prefix does not have > to carry 'ietf-'. (As you will see, shorter identifiers make path > expressions shorter and much more readable.) Look at some other > published data models to see how people usually format YANG data > models. Thanks for pointing out. We had an update modle in git repository on the model based on pyang --ietf check but have not update the draft yet. Will update it in the future draft. > > It wonder why access-list is a container, that is this is a > singleton. In Linux, I can have multiple tables and multiple chains > that contain multiple rules. And if this is a singleton, why do > I need acl-name? Perhaps this was supposed to be a list keyed by > acl-name? Let's discuss in the review meeting > > There is ongoing debate whether operational state mixed with config > data is good or bad design. While I believe acl-oper-data is meant > to be operational state, it is not marked as config false either. > And note that the common terminology is operational state and not > operational data. > > I do not know what a target in the leaf-list of targets are. The > type just says string, which is a bit too open ended I guess. And > it seems this is really configuration and not operational state, > hence this might be misplaced? The model need to be updated to make target as config false. We had a lot of discussion about what should be the right type. We compared string vs interface-ref vs instance-identifier. Since ACL can apply to interfaces, or used as classifier in qos and service chaining. There is no common type between its target. We can discuss more in the meeting. > > It seems the matching is rather limited per rule. This may be fine > but seems at odd with a previous statement "Each ACE has a group of > match criteria and a group of action criteria." It seems a rule > (oops ACE) has a single simple match against header files and > metadata and a single action it can trigger, no? > > The counters in ace-oper-data should at least be config false. > >- Section 4.2: > > The module needs to get a proper name that starts with ietf- and > make sure things compile using pyang --ietf. Will update the draft with the updated module. > > Since the packet fields definitions may be reused, do not prefix > them with acl- - in fact those prefixes are not really needed in > YANG since you prefix identifiers when use them. Perhaps think about > a shorter prefix than 'packet-fields'? > > Some fields need more description. Is it useful to represent the > protocol by number? > > Should the ip-header-fields not include the ipv4/ipv6 header fields > (e.g. in a choice)? Right now, the user of the definitions has to > create and maintain the choice. I also note that the fields are > called ...-address but the type is really a prefix. So the idea is > that you match an address taken from the packet header against a > prefix. I guess this (though perhaps obvious to us) should be > explained in the missing description statements. [Note that the type > for source-ipv6-address is ...-address - I guess this is a typo.] > > You should explain how address masking is supposed to work just to > be clear everybody does the same thing. What about VLANs? Out of > scope? > > What is the purpose of the absolute container of the timerange > definition? There is no other timerange defined. The description > of 'active' is somewhat confusing. > > While the Internet ages, we see interesting layerings coming > along. (I do not want to mention WebRTC.) How does your framework > apply to tunnels etc? I assume all this applies only to the outer > headers and I can't say filter IP in IP encapsulated traffic with > it. That is fine but supposed I need to, can I extend this easily? > > A bigger question I have is how the 'packet-header' module (needs a > better name) is being maintained. Is this cast into stone via an RFC > and then RFC update rules apply? Or is this to be maintained by IANA > with a careful review process? And if changes are made, how does a > client figure out which set of filters an implementation supports? > Do we need to define suitable features? Are features sufficient - > what happens if I add say flow-label to the IP header fields? > > Should things perhaps be split into several modules, one for > Ethernet header matching, one for IP header matching, one for > transport header matching to make updates and maintenance easier? > >- Section 4.3: I do not understand the 'range' enum of the > match-simple-payload-protocol-value grouping. > >- Several citations are duplicated in the text, such as [RFC6241] > [RFC6241]. > >- Section 4.4 should use IP addresses reserved for examples and not > just 1.1.1.1 and 2.2.2.2. I am also not sure that showing some > random proprietary CLI is a good way of describing an example in an > I-D - simple remove Figure 1. In Figure 2, I would remove all the > edit-config noise and focus only on the config data. That said, I am > not sure what is nor am I convinced you got the namespaces > right. Make sure you validate your examples against the data model. > (See the pyang tutorial on how to do that.) > >- Section 5 probably needs to be expanded. Linux has tables, chains, > and rules and it would be nice to document how things actually map > to the concepts in the propose data model. Agree. We actually planned to present these questions in the IETF conference to find out what are the cases that audience would like to see. If these are general interests, we would add them. > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 From nobody Wed Jul 30 22:05:16 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A991A0197 for ; Wed, 30 Jul 2014 22:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_65=0.6, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yObdj30bx-yr for ; Wed, 30 Jul 2014 22:05:12 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 363AC1A0113 for ; Wed, 30 Jul 2014 22:05:12 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9BA8C11D9; Thu, 31 Jul 2014 07:05:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id j9nGqgI9Ec0T; Thu, 31 Jul 2014 07:05:09 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 31 Jul 2014 07:05:10 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E303220039; Thu, 31 Jul 2014 07:05:09 +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 lie4mCrC_F3i; Thu, 31 Jul 2014 07:05:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CDAC620038; Thu, 31 Jul 2014 07:05:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CAAB42DFFC94; Thu, 31 Jul 2014 07:05:06 +0200 (CEST) Date: Thu, 31 Jul 2014 07:05:05 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20140731050504.GB63208@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , "netmod@ietf.org" References: <3BC2A86B-C657-43F4-8908-B188D9D3674B@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/CxefU93Ei67Qq1mKcsUM-TUrgBE Cc: "netmod@ietf.org" Subject: Re: [netmod] NetConf Operational Model Question X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2014 05:05:15 -0000 On Wed, Jul 30, 2014 at 11:17:22AM -0700, Andy Bierman wrote: > [...] If I want to maintain counters associated with some config > (ACL rule hits, RMON host table counters) then adding config=false > under the config for some collection works great. Are the counters associated with the configuration or with the function that was configured? I think the later is the way I look at things. The question then becomes whether the function can exist without explicit configuration. For ACLs, you might say this is true. However, if I look at things like the Port Control Protocol (PCP), I am not sure anymore this assumption is generally true. Operationally it would be kind of odd to be able to get counters for configured ACL rules but not for dynamically injected ACL rules created by PCP and the like. The number of situations in which a function can only exist with explicit configuration may actually be rather small since there is a tendency to start with explicit configuration for new network functions and over time to complement things with specific control protocols. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jul 30 22:27:40 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8980D1A0035 for ; Wed, 30 Jul 2014 22:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIJZ-TdrWFnn for ; Wed, 30 Jul 2014 22:27:34 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D1CF1A0197 for ; Wed, 30 Jul 2014 22:27:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id A724D540726; Thu, 31 Jul 2014 07:27:31 +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 UC5kLN5qY9b5; Thu, 31 Jul 2014 07:27:25 +0200 (CEST) Received: from localhost (cst-prg-79-252.cust.vodafone.cz [46.135.79.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 4D1685402DC; Thu, 31 Jul 2014 07:27:21 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <3BC2A86B-C657-43F4-8908-B188D9D3674B@nic.cz> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Thu, 31 Jul 2014 07:27:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7H4l6SL0cVjbsbGzKSnxfrtsmIw Cc: "netmod@ietf.org" Subject: Re: [netmod] NetConf Operational Model Question X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 05:27:37 -0000 Andy Bierman writes: > On Wed, Jul 30, 2014 at 10:56 AM, Ladislav Lhotka wrote: > >> >> On 30 Jul 2014, at 18:41, Andy Bierman wrote: >> >> > >> > >> > >> > On Wed, Jul 30, 2014 at 9:28 AM, Ladislav Lhotka wrote: >> > >> > On 30 Jul 2014, at 16:08, Andy Bierman wrote: >> > >> > > >> > > >> > > >> > > On Wed, Jul 30, 2014 at 5:31 AM, Patrick Gili (pgili) >> wrote: >> > > Clyde, >> > > >> > > This doesn=C2=B9t make sense. Read section 5.1 of RFC 6241 to better >> > > understand why I think so. >> > > >> > > >> > > The running configuration contains only the config=3Dtrue subset of = all >> > > YANG data nodes. >> > > >> > > IMO, the only reason to replicate the configuration structure >> (non-terminals, keys) >> > > in operational state (like ietf-interfaces) is because the state can >> exist independently >> > > of the configuration. Most of the time, this is a bad idea and >> doesn't really make sense. >> > >> > I don't agree. This is what I read in sec. 3 of RFC 3535: >> > >> > 2. It is necessary to make a clear distinction between configurati= on >> > data, data that describes operational state and statistics. So= me >> > devices make it very hard to determine which parameters were >> > administratively configured and which were obtained via other >> > mechanisms such as routing protocols. >> > >> > >> > That's why we have a separate operation. >> > It makes it very easy to prune out all the state data. >> > >> > The tree abstraction is just an API. The XML is just a representation. >> > A server implementation is free to organize data any way it wants. >> >> It is not about data organization but rather about the ability "to >> determine which parameters were administratively configured and which we= re >> obtained via other mechanisms such as routing protocols." >> > > > You can do that with YANG. > Separate the config and non-config in different modules if you want. > What is your point? Every data model will have different requirements > and design considerations. You pointed out a couple that you prefer to > keep as separate trees. That doesn't mean every YANG model > will need to do that. E.g. -- If I want to maintain counters > associated Of course, but you wrote "Most of the time, [duplicate config and state trees] is a bad idea and doesn't really make sense. I just disagree with this statement. > with some config (ACL rule hits, RMON host table counters) > then adding config=3Dfalse under the config for some collection works gre= at. > > >> > >> > YANG supports many ways to organize data any way that seems right >> > for a particular data model. IMO it is a waste of time to force one >> > way or another. Perhaps the YANG Patterns draft will make the >> > design choices easier to understand. >> > >> > >> > >> > 3. It is required to be able to fetch separately configuration dat= a, >> > operational state data, and statistics from devices, and to be >> > able to compare these between devices. >> > >> > So? We have . >> > Anybody can write an RPC that retrieves only state (see in >> NETCONF-EX). >> >> Not if state data are buried inside configuration and a particular >> instance has no configuration (yet). >> > > > Yes, we already went over this -- if the state can exist independent of t= he > config > then it cannot be under the config. Then the YANG designer will not do th= at > because this data model needs separate config and state. > IMO, state data inside configuration is a dubious practice violating the items 2 and 3 that I cited from RFC 3535. > >> >> > >> > >> > Any offline tool can also separate data for comparison, based on the >> > value of the config-stmt. >> > >> > >> > >> > See also sec. 3 in >> > >> > http://tools.ietf.org/html/draft-tp-i2rs-yang-00 >> > >> > > >> > > - Can the data structure being modeled exist on its own as state >> without any config? >> > > If yes then dual data structures are needed. >> > > >> > > - e.g., What does it mean if an interface is reported as state but >> does not >> > > exist in the configuration? (I sure don't know) >> > >> > If you boot a Linux box, interfaces like "eth0" appear before you get a >> chance to configure anything (we call it system-controlled interfaces) >> > >> > So an implementation would populate on interface-state, and nothing >> > in interface? So an admin (or even root) can never >> > change anything on 'eth0'? So is there is an entry >> > for 'eth0' in the interface list? >> > >> >> Please read about system-controlled interfaces in RFC 7223. >> >> > > I did. Just because 1 module is designed this way doesn't mean > every module should be the same. You want to have some magic state > that is editable by the client, and comes back after a reboot? No magic involved, what comes up after reboot as operational state just reflects hardware configuration. > I prefer to think of it as server-created config. Our server supports > this sort of write limitation on a config=3Dtrue node. > > > > > >> > >> > >> > > >> > > - How many of the leafs (properties) of the configured data >> structure can >> > > be changed by means other than configuration edits? If none or >> very few, >> > > then duplicating the data as config and state is not needed. >> > >> > Pretty much everything on systems that aren't stricty NETCONF-centric.= A >> generic operating system doesn't give a damn about NETCONF >> > >> > >> > huh? Servers are implemented so that any protocol that changes config >> are >> > supposed to reflect the config changes in NETCONF. >> >> Which servers? Do you think "ifconfig" or "ip" behave this way? What if >> something changes in operational state and the config datastore is locke= d? >> > > If somebody writes a NETCONF server they are responsible to make it work > correctly. The server behaviour you describe is just wishful thinking with no support in RFC 6241. I'd rather think about (NETCONF) configuration as something being completely under control of NETCONF client(s), and it's not the server's business to tinker with it. Lada > Not the IETF's problem to design an open API on Linux to support NETCONF. > > >> >> Lada >> >> > Andy > > >> > >> > It cost memory to duplicate trees for no good reason. >> > These are design choices the YANG model authos need to >> > consider. YANG doesn't care which design you use. >> > >> > . >> > >> > > >> > > - Does the operator need to know the operational state values that >> are overriding >> > > specific configured values? What breaks if the operator thinks the >> configured >> > > value is in use but it is a different value? >> > >> > For example, it is usually useful to know the IP address the system is >> really using on an interface. >> > >> > I am just trying to provide some questions designers should consider >> instead of blindly >> > copying one module or another. >> > >> > >> > >> > Lada >> > >> > >> > >> > Andy >> > >> > > >> > > >> > > >> > > -Patrick >> > > >> > > >> > > Andy >> > > >> > > >> > > On 7/30/14, 8:19 AM, "Clyde Wildes (cwildes)" >> wrote: >> > > >> > > >Hi, >> > > > >> > > >Some operational data reflects data in the running config. Examples >> from >> > > >IETF models: >> > > >- the IETF routing model duplicates most leafs but not all - >> > > >routing-instance, rib-name, rib address-family, rib recipient-ribs, >> > > >route-filter. >> > > >- the ietf-interfaces model duplicates some leafs but not all - nam= e, >> > > >type. >> > > > >> > > >Under what conditions is it acceptable or desirable to model data >> that is >> > > >available as part of the running config as operational data? >> > > > >> > > >Looking at the existing models I could not see a pattern. >> > > > >> > > >Thanks, >> > > > >> > > >Clyde >> > > > >> > > > >> > > >_______________________________________________ >> > > >netmod mailing list >> > > >netmod@ietf.org >> > > >https://www.ietf.org/mailman/listinfo/netmod >> > > >> > > _______________________________________________ >> > > netmod mailing list >> > > netmod@ietf.org >> > > https://www.ietf.org/mailman/listinfo/netmod >> > > >> > > _______________________________________________ >> > > netmod mailing list >> > > netmod@ietf.org >> > > https://www.ietf.org/mailman/listinfo/netmod >> > >> > -- >> > Ladislav Lhotka, CZ.NIC Labs >> > PGP Key ID: E74E8C0C >> > >> > >> > >> > >> > >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 30 22:52:09 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D6E1A0251 for ; Wed, 30 Jul 2014 22:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmJUTzW5-O7B for ; Wed, 30 Jul 2014 22:52:06 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657951A0197 for ; Wed, 30 Jul 2014 22:52:06 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2E431105D; Thu, 31 Jul 2014 07:52:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Heu3T--k1Ifa; Thu, 31 Jul 2014 07:52:03 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 31 Jul 2014 07:52:04 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4233220034; Thu, 31 Jul 2014 07:52:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id aJsFbTg0mHf7; Thu, 31 Jul 2014 07:52:03 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4E79D20017; Thu, 31 Jul 2014 07:52:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 66A612DFFD35; Thu, 31 Jul 2014 07:52:02 +0200 (CEST) Date: Thu, 31 Jul 2014 07:52:01 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140731055201.GC63208@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <5392C525-EB34-4E8A-BB39-B1464E4DE4C9@nic.cz> <20140730110826.GE61382@elstar.local> <20140730130412.GB61698@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/i6Dw0roWwPiiIaNQtNB-dw4USMI Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2014 05:52:07 -0000 On Wed, Jul 30, 2014 at 05:53:30PM +0200, Ladislav Lhotka wrote: > > >>> understand that this makes the solution somewhat incomplete but it > >>> allows us to finish this document now and to move forward. > >> > >> That is my priority, too. > > > > Good. So what speaks against saying that if attribute names clash and > > if attributes are scoped by a module name, then the encoding is XYZ? > > I thought YANG 1.1 was a good opportunity to decide about how to do this scoping, provided that standard attributes are really needed. > Lets keep the discussion focused on the JSON document. Are you OK with the proposal to add text that attribute names may be scoped? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jul 30 23:19:48 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6BC1A0251 for ; Wed, 30 Jul 2014 23:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFnQu5kPBrT2 for ; Wed, 30 Jul 2014 23:19:44 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13D131A0062 for ; Wed, 30 Jul 2014 23:19:44 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D3EFA11F8; Thu, 31 Jul 2014 08:19:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Ckt7H71GnJxn; Thu, 31 Jul 2014 08:19:41 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 31 Jul 2014 08:19:41 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id BC0AF2002C; Thu, 31 Jul 2014 08:19:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qsF_Kfv-aLb7; Thu, 31 Jul 2014 08:19:41 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6A5E020017; Thu, 31 Jul 2014 08:19:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A8C9B2DFFD8A; Thu, 31 Jul 2014 08:19:39 +0200 (CEST) Date: Thu, 31 Jul 2014 08:19:39 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140731061937.GA63422@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <5392C525-EB34-4E8A-BB39-B1464E4DE4C9@nic.cz> <20140730110826.GE61382@elstar.local> <20140730130412.GB61698@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cPwBIBrwDPg__dkz2ySzveV0FfM Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2014 06:19:45 -0000 On Wed, Jul 30, 2014 at 05:53:30PM +0200, Ladislav Lhotka wrote: > > > > > Yes, I understand that. Even if we make this assumption, I think it > > would be good to spell this out explicitely right upfront so that > > people know that a translation without knowledge of data models was > > not a goal of the design. I am sure people will try to do this and we > > better make sure everybody understands upfront that this won't work. > > I think it is quite clearly said in the introduction. > I do not think so. The text says: 1. The translation is driven by a concrete YANG data model and uses information about data types to achieve better results than generic XML-JSON translation procedures. 3. XML namespaces specified in the data model are mapped to namespaces of JSON objects. However, explicit namespace identifiers are rarely needed in JSON text. Item 1. is about types and item 3. does not clearly say that URIs (XML namespaces) are mapped to JSON qualified names that use module names and that this mapping requires knowledge of the YANG module name to URI relationship. Another nit: The namespace identifier MUST be used for local names that are ambiguous, i.e., whenever the data model permits a sibling data node with the same local name. Otherwise, the namespace identifier is OPTIONAL. YANG 'permits' sibling data nodes with the same local name almost everywhere through augments. Perhaps you wanted to say "... whenever sibling data nodes exist that have the same local name." I am also not sure the rules are clear in situations like this: module a { container top { container a { leaf name; leaf value; } } } module b { import a; augment '/a:top' { container a { leaf name; } } } I assume name does not require qualification in the following, correct? { "top": { "b:a": { "name": "foo"; } } } I assume this is illegal (even though it is not ambiguous)? { "top": { "a": { "b:name": "foo"; } } } But then this would be legal, no? I mean a box not implementing module b would generate this. { "top": { "a": { "name": "foo"; } } } /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Jul 31 01:49:15 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C67D1A04B9 for ; Thu, 31 Jul 2014 01:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K94C9fcTcBQt for ; Thu, 31 Jul 2014 01:49:11 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 770B41A0439 for ; Thu, 31 Jul 2014 01:49:11 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:3c58:1f22:7a5a:4b43] (unknown [IPv6:2001:1488:fffe:6:3c58:1f22:7a5a:4b43]) by mail.nic.cz (Postfix) with ESMTPSA id D4D3913FA01; Thu, 31 Jul 2014 10:49:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1406796550; bh=4kGnQkyBx/qo9pzcChagHJ4qz8P+va32BsLpFOWegQ4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nqscAurUAo5el1HCu//49Yyev1bKJSHIfy1I8SZT4kZRDnLYNigCrSvTdqeelHVvI rajvgZsxyo6bpDlXKLfbmoaK8VmVDT+l1Wv+ln7be6+peCgZmBwgjDGvx2JX2Y2Oy9 sp3YNOCN4iFqwf0FVsM4SWGxfdsi0WtyBoVR1p5U= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140731055201.GC63208@elstar.local> Date: Thu, 31 Jul 2014 10:49:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5BA7630E-B06F-47B5-9ACD-92D9A3512864@nic.cz> References: <5392C525-EB34-4E8A-BB39-B1464E4DE4C9@nic.cz> <20140730110826.GE61382@elstar.local> <20140730130412.GB61698@elstar.local> <20140731055201.GC63208@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Z3T4VUdsyXtsknacXhsz3IxzBUo Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 08:49:13 -0000 On 31 Jul 2014, at 07:52, Juergen Schoenwaelder = wrote: > On Wed, Jul 30, 2014 at 05:53:30PM +0200, Ladislav Lhotka wrote: >>=20 >>>>> understand that this makes the solution somewhat incomplete but it >>>>> allows us to finish this document now and to move forward. >>>>=20 >>>> That is my priority, too. >>>=20 >>> Good. So what speaks against saying that if attribute names clash = and >>> if attributes are scoped by a module name, then the encoding is XYZ? >>=20 >> I thought YANG 1.1 was a good opportunity to decide about how to do = this scoping, provided that standard attributes are really needed. >>=20 >=20 > Lets keep the discussion focused on the JSON document. Are you OK with > the proposal to add text that attribute names may be scoped? Yes, if there is no other choice. It is unclear what =93scoped=94 means. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jul 31 02:22:50 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4981A0456 for ; Thu, 31 Jul 2014 02:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAiZVCyQB-sC for ; Thu, 31 Jul 2014 02:22:46 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C3F1A063C for ; Thu, 31 Jul 2014 02:22:45 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:3c58:1f22:7a5a:4b43] (unknown [IPv6:2001:1488:fffe:6:3c58:1f22:7a5a:4b43]) by mail.nic.cz (Postfix) with ESMTPSA id 7D06913F7AE; Thu, 31 Jul 2014 11:22:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1406798563; bh=4ZwieEerqH3ss87tZMo/Ohc9jVKvKhhsseVoGLsnn44=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=H2x79M4dMnvzms2/GdwDA+MQVfPCExF99MPcDaaAXHCyg6fGKktlVpcFMvEipDrNV qSYQAHWIssghBWPgmkEf3599rAangOfcvIkYJ3K+QriQ9n+r3Fp7bBEgJP0xnQd+zd Ts/mfSW8OUMCMfcpe8e28b8nCB4MauF6P8vSTMxA= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140731061937.GA63422@elstar.local> Date: Thu, 31 Jul 2014 11:22:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4CB987CF-756D-4ABB-8017-C49F1379EB45@nic.cz> References: <5392C525-EB34-4E8A-BB39-B1464E4DE4C9@nic.cz> <20140730110826.GE61382@elstar.local> <20140730130412.GB61698@elstar.local> <20140731061937.GA63422@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/VTDIA_kTOeMUdnU5RctVUoEAyhE Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 09:22:48 -0000 On 31 Jul 2014, at 08:19, Juergen Schoenwaelder = wrote: > On Wed, Jul 30, 2014 at 05:53:30PM +0200, Ladislav Lhotka wrote: >>=20 >>>=20 >>> Yes, I understand that. Even if we make this assumption, I think it >>> would be good to spell this out explicitely right upfront so that >>> people know that a translation without knowledge of data models was >>> not a goal of the design. I am sure people will try to do this and = we >>> better make sure everybody understands upfront that this won't work. >>=20 >> I think it is quite clearly said in the introduction. >>=20 >=20 > I do not think so. The text says: >=20 > 1. The translation is driven by a concrete YANG data model and uses > information about data types to achieve better results than > generic XML-JSON translation procedures. >=20 > 3. XML namespaces specified in the data model are mapped to > namespaces of JSON objects. However, explicit namespace > identifiers are rarely needed in JSON text. >=20 > Item 1. is about types and item 3. does not clearly say that URIs (XML > namespaces) are mapped to JSON qualified names that use module names > and that this mapping requires knowledge of the YANG module name to > URI relationship. Yes, the text needs improvement but even now there can be little doubt = that the translation requires knowledge of the data model. I will make = sure it is absolutely clear. >=20 > Another nit: >=20 > The namespace identifier MUST be used for local names that are > ambiguous, i.e., whenever the data model permits a sibling data node > with the same local name. Otherwise, the namespace identifier is > OPTIONAL. >=20 > YANG 'permits' sibling data nodes with the same local name almost > everywhere through augments. Perhaps you wanted to say "... whenever > sibling data nodes exist that have the same local name." I am also not I think the current formulation is correct, it means in other words =93=85= whenever the schema permits a sibling data node with the same local = name." > sure the rules are clear in situations like this: >=20 > module a { > container top { > container a { > leaf name; > leaf value; > } > } > } >=20 > module b { > import a; > augment '/a:top' { > container a { > leaf name; > } > } > } >=20 > I assume name does not require qualification in the following, > correct? Correct, the two =93name=94 leafs are not siblings in the data model = (their parent nodes are not the same). >=20 > { > "top": { > "b:a": { > "name": "foo"; > } > } > } >=20 > I assume this is illegal (even though it is not ambiguous)? Yes, it is illegal - the =93a=94 containers are ambiguous in the sense = of the paragraph you cited. >=20 > { > "top": { > "a": { > "b:name": "foo"; > } > } > } >=20 > But then this would be legal, no? I mean a box not implementing module > b would generate this. Yes, in this case its data model consists only of module =93a=94 and = there is no ambiguity. =20 >=20 > { > "top": { > "a": { > "name": "foo"; > } > } > } Do you think the text should be changed/expanded or more examples added? Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jul 31 03:18:55 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D641A02C2 for ; Thu, 31 Jul 2014 03:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xLWqpxfeF7O for ; Thu, 31 Jul 2014 03:18:49 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D33D1A03AE for ; Thu, 31 Jul 2014 03:18:49 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 186051229; Thu, 31 Jul 2014 12:18:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id bfbyuG7hIL2R; Thu, 31 Jul 2014 12:18:46 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 31 Jul 2014 12:18:47 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6FF7E2002F; Thu, 31 Jul 2014 12:18:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nD6NEkAMBQYY; Thu, 31 Jul 2014 12:18:46 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B6F9E20017; Thu, 31 Jul 2014 12:18:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A2F3D2E002DD; Thu, 31 Jul 2014 12:18:45 +0200 (CEST) Date: Thu, 31 Jul 2014 12:18:45 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140731101845.GA64089@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <20140730110826.GE61382@elstar.local> <20140730130412.GB61698@elstar.local> <20140731061937.GA63422@elstar.local> <4CB987CF-756D-4ABB-8017-C49F1379EB45@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4CB987CF-756D-4ABB-8017-C49F1379EB45@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Jo6r2cLhRliftxFNlqRuDa68JeU Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2014 10:18:53 -0000 On Thu, Jul 31, 2014 at 11:22:40AM +0200, Ladislav Lhotka wrote: > > > Another nit: > > > > The namespace identifier MUST be used for local names that are > > ambiguous, i.e., whenever the data model permits a sibling data node > > with the same local name. Otherwise, the namespace identifier is > > OPTIONAL. > > > > YANG 'permits' sibling data nodes with the same local name almost > > everywhere through augments. Perhaps you wanted to say "... whenever > > sibling data nodes exist that have the same local name." I am also not > > I think the current formulation is correct, it means in other words > “… whenever the schema permits a sibling data node with the same > local name." I still think the text is somewhat confusing. In the example I posted, module a does not know about any sibling data node with the same local name, still it permits such a node to be defined in a different module. The ambiguity is perhaps coming from "the data model" and "permits". > Do you think the text should be changed/expanded or more examples > added? Either could work. Writing the text is likely more difficult than writing the examples but the best would be good text accompanied with examples. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Jul 31 03:24:53 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481231A02C2 for ; Thu, 31 Jul 2014 03:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaDRnq4fb8Zg for ; Thu, 31 Jul 2014 03:24:49 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 891691A0302 for ; Thu, 31 Jul 2014 03:24:49 -0700 (PDT) Received: from ladislavs-air-2.labs.office.nic.cz (unknown [172.20.6.88]) by mail.nic.cz (Postfix) with ESMTPSA id 6210813F6A6; Thu, 31 Jul 2014 12:24:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1406802287; bh=Z2uzN8Ra+5kqfL6Z4tSMv/r72+0Uc5OUiaDc4jq8Hbo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=SADKbpt5dv7TGVUs2Fy2ZunFZ+RndrB0h2FpJALbyHBEee+52fzFEjKZwGsg4jIYw OG/Rft1+O3ojrt8pLY1mMLS523XppRBf11M9fWb9iL5QLp6pN7g0zQ7tfguuE4+VyT lcDMoYQQiVNB96YT/VNtTePs9EyyRQORDUAQkKNE= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140731101845.GA64089@elstar.local> Date: Thu, 31 Jul 2014 12:24:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9B4CF345-B8C3-4BF8-B597-7EAF03E203A7@nic.cz> References: <20140730110826.GE61382@elstar.local> <20140730130412.GB61698@elstar.local> <20140731061937.GA63422@elstar.local> <4CB987CF-756D-4ABB-8017-C49F1379EB45@nic.cz> <20140731101845.GA64089@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/KKuSwAnRlMvzJO2AKTM5kqvzvxw Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 10:24:51 -0000 On 31 Jul 2014, at 12:18, Juergen Schoenwaelder = wrote: > On Thu, Jul 31, 2014 at 11:22:40AM +0200, Ladislav Lhotka wrote: >>=20 >>> Another nit: >>>=20 >>> The namespace identifier MUST be used for local names that are >>> ambiguous, i.e., whenever the data model permits a sibling data = node >>> with the same local name. Otherwise, the namespace identifier is >>> OPTIONAL. >>>=20 >>> YANG 'permits' sibling data nodes with the same local name almost >>> everywhere through augments. Perhaps you wanted to say "... whenever >>> sibling data nodes exist that have the same local name." I am also = not >>=20 >> I think the current formulation is correct, it means in other words >> =93=85 whenever the schema permits a sibling data node with the same >> local name." >=20 > I still think the text is somewhat confusing. In the example I posted, > module a does not know about any sibling data node with the same local > name, still it permits such a node to be defined in a different > module. The ambiguity is perhaps coming from "the data model" and > "permits=94. Would =93the data model defines=94 be better? >=20 >> Do you think the text should be changed/expanded or more examples >> added? >=20 > Either could work. Writing the text is likely more difficult than > writing the examples but the best would be good text accompanied=20 > with examples. ;-) OK, will try. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jul 31 05:21:07 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF371ABB90 for ; Thu, 31 Jul 2014 05:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxTlDfekxGN4 for ; Thu, 31 Jul 2014 05:20:52 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 406521ABB2E for ; Thu, 31 Jul 2014 05:20:52 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D1A7B112A; Thu, 31 Jul 2014 14:20:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id eO_ckwMFzZfm; Thu, 31 Jul 2014 14:20:48 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 31 Jul 2014 14:20:50 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 37DDA2002C; Thu, 31 Jul 2014 14:20:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wVx4QrGlFVle; Thu, 31 Jul 2014 14:20:49 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E904420017; Thu, 31 Jul 2014 14:20:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D40A92E00566; Thu, 31 Jul 2014 14:20:48 +0200 (CEST) Date: Thu, 31 Jul 2014 14:20:48 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140731122048.GB64359@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <20140730110826.GE61382@elstar.local> <20140730130412.GB61698@elstar.local> <20140731061937.GA63422@elstar.local> <4CB987CF-756D-4ABB-8017-C49F1379EB45@nic.cz> <20140731101845.GA64089@elstar.local> <9B4CF345-B8C3-4BF8-B597-7EAF03E203A7@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9B4CF345-B8C3-4BF8-B597-7EAF03E203A7@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5WEsY_J7eRSxWvIah8Xd4Hu6FeE Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2014 12:20:57 -0000 On Thu, Jul 31, 2014 at 12:24:46PM +0200, Ladislav Lhotka wrote: > > On 31 Jul 2014, at 12:18, Juergen Schoenwaelder wrote: > > > On Thu, Jul 31, 2014 at 11:22:40AM +0200, Ladislav Lhotka wrote: > >> > >>> Another nit: > >>> > >>> The namespace identifier MUST be used for local names that are > >>> ambiguous, i.e., whenever the data model permits a sibling data node > >>> with the same local name. Otherwise, the namespace identifier is > >>> OPTIONAL. > >>> > >>> YANG 'permits' sibling data nodes with the same local name almost > >>> everywhere through augments. Perhaps you wanted to say "... whenever > >>> sibling data nodes exist that have the same local name." I am also not > >> > >> I think the current formulation is correct, it means in other words > >> “… whenever the schema permits a sibling data node with the same > >> local name." > > > > I still think the text is somewhat confusing. In the example I posted, > > module a does not know about any sibling data node with the same local > > name, still it permits such a node to be defined in a different > > module. The ambiguity is perhaps coming from "the data model" and > > "permitsâ€. > > Would “the data model defines†be better? Yes. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Jul 31 05:22:07 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E109D1ABC74 for ; Thu, 31 Jul 2014 05:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ov61H1M2wAK1 for ; Thu, 31 Jul 2014 05:22:03 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 613881ABB90 for ; Thu, 31 Jul 2014 05:22:03 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2C26A122C; Thu, 31 Jul 2014 14:22:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 3RbTyGLndeTL; Thu, 31 Jul 2014 14:21:59 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 31 Jul 2014 14:22:01 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7D71C2002C; Thu, 31 Jul 2014 14:22:01 +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 Mys6VzXrKQS0; Thu, 31 Jul 2014 14:22:01 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B6CAD20017; Thu, 31 Jul 2014 14:22:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A7E202E00594; Thu, 31 Jul 2014 14:22:00 +0200 (CEST) Date: Thu, 31 Jul 2014 14:22:00 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140731122200.GC64359@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <20140730110826.GE61382@elstar.local> <20140730130412.GB61698@elstar.local> <20140731055201.GC63208@elstar.local> <5BA7630E-B06F-47B5-9ACD-92D9A3512864@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5BA7630E-B06F-47B5-9ACD-92D9A3512864@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/PYNeG4_mAdpNtvMxOqzOz92EVQI Cc: "netmod@ietf.org" Subject: Re: [netmod] metadata in JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2014 12:22:05 -0000 On Thu, Jul 31, 2014 at 10:49:07AM +0200, Ladislav Lhotka wrote: > > On 31 Jul 2014, at 07:52, Juergen Schoenwaelder wrote: > > > On Wed, Jul 30, 2014 at 05:53:30PM +0200, Ladislav Lhotka wrote: > >> > >>>>> understand that this makes the solution somewhat incomplete but it > >>>>> allows us to finish this document now and to move forward. > >>>> > >>>> That is my priority, too. > >>> > >>> Good. So what speaks against saying that if attribute names clash and > >>> if attributes are scoped by a module name, then the encoding is XYZ? > >> > >> I thought YANG 1.1 was a good opportunity to decide about how to do this scoping, provided that standard attributes are really needed. > >> > > > > Lets keep the discussion focused on the JSON document. Are you OK with > > the proposal to add text that attribute names may be scoped? > > Yes, if there is no other choice. It is unclear what “scoped†means. > Scoped by a namespace, such as 'namespace:identifier'. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Jul 31 06:19:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7621B27CD for ; Thu, 31 Jul 2014 06:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70gqIRg2HcaB for ; Thu, 31 Jul 2014 06:19:06 -0700 (PDT) Received: from mx0b-00176a03.pphosted.com (mx0b-00176a03.pphosted.com [67.231.157.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 853AA1A0023 for ; Thu, 31 Jul 2014 06:19:06 -0700 (PDT) Received: from pps.filterd (m0048204.ppops.net [127.0.0.1]) by m0048204.ppops.net-00176a03. (8.14.7/8.14.7) with SMTP id s6VDI739040536 for ; Thu, 31 Jul 2014 09:19:05 -0400 Received: from alpmlip11.e2k.ad.ge.com ([12.43.191.1]) by m0048204.ppops.net-00176a03. with ESMTP id 1nfntm8844-1 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 31 Jul 2014 09:19:05 -0400 Received: from unknown (HELO ALPMBHT03.e2k.ad.ge.com) ([3.159.19.196]) by alpmlip11.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 31 Jul 2014 09:08:17 -0400 Received: from CINURAPD08.e2k.ad.ge.com (3.159.212.120) by ALPMBHT03.e2k.ad.ge.com (3.159.19.196) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 31 Jul 2014 09:19:04 -0400 Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.210]) by CINURAPD08.e2k.ad.ge.com ([169.254.10.176]) with mapi id 14.03.0195.001; Thu, 31 Jul 2014 09:19:04 -0400 From: "Lange, Jeffrey K (GE Energy Management)" To: Benoit Claise , Jeffrey Haas Thread-Topic: [netmod] Syslog YANG Model Presentation Thread-Index: AQHPpSkC2ZiRgh9DtUicY+pcm0HXCJusdZuAgAApbICADGdHAIAABm6AgAEs7wA= Date: Thu, 31 Jul 2014 13:19:04 +0000 Message-ID: References: <20140722150553.GB12083@elstar.local> <53CEA093.2070000@cisco.com> <20140730145856.GL29365@pfrc> <53D90D95.5090001@cisco.com> In-Reply-To: <53D90D95.5090001@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [3.159.212.180] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-07-31_04:2014-07-30,2014-07-31,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407310164 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2XRcRfj0NMAxmMEBHjc5DDzphR8 Cc: "lonvick@gmail.com" , Kiran Agrahara Sreenivasa , "rgerhards@hq.adiscon.com" , "netmod@ietf.org" Subject: Re: [netmod] Syslog YANG Model Presentation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 13:19:09 -0000 Benoit, We (GE MDS) support 5424/5425/5426 structured messages on our products (w= ith vendor specific structured-data). -Jeff Lange From: Benoit Claise > Date: Wednesday, July 30, 2014 at 11:21 AM To: Jeffrey Haas > Cc: "lonvick@gmail.com" >, Kiran Agrahara Sreenivasa >, "netmod@ietf.org" >, "rgerhards@hq.adiscon.com" > Subject: Re: [netmod] Syslog YANG Model Presentation Jeff, Thanks. So I guess we need to support RFC 5424, RFC 5425, and RFC 5426 configuratio= n in the YANG model, right? You use only vendor specific STRUCTURED-DATA? Because I don't see many in t= he IANA registry, and http://tools.ietf.org/html/rfc542= 4#section-9.2 requests IANA registration. If my memory serves me well (I copied a couple of old timers), the STRUCTUR= ED-DATA goal was to standardize the syslog message content in the industry,= but that did not happen. Regards, Benoit Benoit, On Tue, Jul 22, 2014 at 01:34:11PM -0400, Benoit Claise wrote: PS: I think you should also refer to the standards-track version of SYSLOG (RFC 5424) in the references and perhaps filters should also be able to operate on structured content. Is RFC 5424 actually deployed? Juniper has supported it for years. -- Jeff . From nobody Thu Jul 31 06:51:59 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA46B1B2819 for ; Thu, 31 Jul 2014 06:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoI5_mT3LHZL for ; Thu, 31 Jul 2014 06:51:54 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A2C11B2811 for ; Thu, 31 Jul 2014 06:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13022; q=dns/txt; s=iport; t=1406814710; x=1408024310; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=knVIwVBwgAnLr2b/EQr6aNtMema0JoUytHSfq3uIV8k=; b=FLmqBYisfxUBim/O9Z9tI3tVYRCaSWIwjUE7o5csBlBc+QwT+Z8+MUYZ Twtk19L32c38jfG6LSHdDY5eCzDV8zaH77q70w+zHLUemO4ZWK6sPhOD5 pq2mbtTUXQcINSGOwrODJaW7pdEL/fz12Asidzh6u3e7fvlzxGc75uFlD 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUJAJVJ2lOtJV2R/2dsb2JhbABWA4MOUlcBA8suh0kBgQYWd4QEAQEDAXIHBQkEAQgOAlEXJQIEAQ0FCQuIJggNvDkXBI5wSBAHEYQ5BY5ljH+UU4NJbAGBAgIeBhw X-IronPort-AV: E=Sophos;i="5.01,772,1400025600"; d="scan'208";a="344111516" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-7.cisco.com with ESMTP; 31 Jul 2014 13:51:49 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6VDpn2J002008 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jul 2014 13:51:49 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.47]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Thu, 31 Jul 2014 08:51:48 -0500 From: "Dana Blair (dblair)" To: Juergen Schoenwaelder , "draft-bogdanovic-netmod-acl-model@tools.ietf.org" Thread-Topic: review of draft-bogdanovic-netmod-acl-model-01 Thread-Index: AQHPqyuRY5J02Ba27E6LGhbNADy5Spu6R6IA Date: Thu, 31 Jul 2014 13:51:48 +0000 Message-ID: In-Reply-To: <20140729124925.GC58615@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.21.93.238] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fKhImRKh_eYFYhq2ZJcILp14rcI Cc: "netmod@ietf.org" Subject: Re: [netmod] review of draft-bogdanovic-netmod-acl-model-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 13:51:58 -0000 Thanks for your thorough review. On 7/29/14 8:49 AM, "Juergen Schoenwaelder" wrote: >Hi, > >during the Sunday session before IETF 90, I got nominated to be the >Yang Doctor for draft-bogdanovic-netmod-acl-model-01. And as a >consequence, I have done a review of this I-D and since this was >submitted as a contribution to the IETF, I thought I post the review >right here. Note that many comments are not really Yang Doctors >concerns but once I review a document, I often end up reviewing the >whole thing. > >/js > >- If this document is supposed to be standards-track, then the > intended status should not be "Informational". We'll fix this. > >- The title should be more descriptive. Following recent YANG RFCs, > perhaps something like "A YANG Data Model for Network Access Control > List (ACL) Management". OK. > >- I am not sure you define an information model and a data model. I > think you define just a data model and hence you may want to update > the abstract. And I am not sure what 'basic building blocks' means, > perhaps expand on the approach taken (i.e. that it is a basic > structure designed to be augmented). > >- The first paragraph on the introduction has singular/plural > mismatches. > >- Run idnits and fix lines that are too long and split the references > into normative and informative references and update any outdated > references. Thanks. We'll update the voe. > >- Section 2: > > s/that model can be/that the model can be/ > s/Actions/actions/ > s/that augmented/that can be augmented/ > >- Section 3: You say that a access control list containers an ordered > set of rules. Why do you choose the term "Access Control Entry" > instead of simply "Access Control Rule"? What is a _group of_ match I'm open to the term "rule", but historically the rules in a access control list are called entries. This goes way back. We'll discuss and see if other comments on this come in. > and action criteria? Why is a prefix length meta data? I mean, how Each "rules" in the access-list, and in fact other kinds of policy on router,=20 contain a set of match criteria for matching packets, and a set of actions which are executed when a rule is matched. > do you determine the source prefix length? According to a lookup in > the local forwarding table(s)? Is this strictly speaking meta data > or more precisely data derived from packet headers? According to our definition of packet metadata, packet metadata is information relevant to the packet matching but is not in the actual packet header. There is no mask or prefix length in the packet header. So in this strict sense, prefix length is metadata. However, it might be good to relax the metadata definition for this case. > > s/daufault/default/ > >- Section 3.1: You can't write 'imports module "packet-headers" into > the match container'. While you claim it is easy to reuse > definitions of say IPFIX [RFC5101], I am not sure I see the details > how this would work. Better work out the details and then leave the > judgment whether it is easy or not to the reader. > > s/is example/is an example/ > > You may want to consider to describe the standard models in section > 3 and to discuss proprietary extensions in a separate section or > even an appendix to make it very clear which text is normative and > which is not. > >- Section 4.1. > > s/Access/access/ > > Make sure the YANG module passes pyang --ietf checks. Also note that Good point. We learned that on the YANG workshop on Sunday. I sent out a new version of the model to the authors which resolves the --ietf checks. Next version of the draft will have this fixed. > the description of the revision statement should refer to the > document defining the data model. Note that the prefix does not have > to carry 'ietf-'. (As you will see, shorter identifiers make path > expressions shorter and much more readable.) Look at some other > published data models to see how people usually format YANG data > models. Thx. Good advice. I guess since these names directly translate into XML text and/or API calls, keeping them concise is good. > > It wonder why access-list is a container, that is this is a > singleton. In Linux, I can have multiple tables and multiple chains > that contain multiple rules. And if this is a singleton, why do > I need acl-name? Perhaps this was supposed to be a list keyed by > acl-name? Looks like the YANG list is not only defining a list of things, but also a shared name space between them. Is that right ? There are lists of access-lists but there are many types. IPv4, Ipv6, L2, IPv4 and IPv6 rules in the same access-list. We need to explore if each needs its own list (namespace), or they have a common name space. This will dictate how the model defines the lists. > > There is ongoing debate whether operational state mixed with config > data is good or bad design. While I believe acl-oper-data is meant It'll be interesting to see how that turns out. I've seen both ways of expressing. I don't have a strong opinion either way. I do believe including config and operational state in the model allows easier understanding/correlation between the two. > to be operational state, it is not marked as config false either. Will be fixed in the next version. > And note that the common terminology is operational state and not > operational data. > > I do not know what a target in the leaf-list of targets are. The > type just says string, which is a bit too open ended I guess. And > it seems this is really configuration and not operational state, > hence this might be misplaced? Access-lists are applied to things. We call these targets. Most familiar is access-list are applied to interfaces with a direction (input or output or both). But access-lists can also be applied to routing protocols policies, routing directly (policy routing which is a kind of static route for things beyond just destination prefix matching), =8A There are other proprietary targets within each vendor. We're still trying to think about whether to include targets in the model or where/how to specify them. This is an open item. The operational state should include a list of targets than an access-list has been applied to, in addition to some way to actually configure an access-list on a target. > > It seems the matching is rather limited per rule. This may be fine > but seems at odd with a previous statement "Each ACE has a group of > match criteria and a group of action criteria." It seems a rule > (oops ACE) has a single simple match against header files and > metadata and a single action it can trigger, no? The intention is that each "rule" would all multiple match criteria (dst, prefix, dscp, port number, =8A) and multiple actions. Regarding the actions, the 2 standard actions are permit or deny but there are others like log and many vendor proprietary actions. If you look at the newco example, it should show how to augment the model with an action. As the community here presents augmentations we can consider including them in the standard model. > > The counters in ace-oper-data should at least be config false. Will be fixed. > >- Section 4.2: > > The module needs to get a proper name that starts with ietf- and > make sure things compile using pyang --ietf. > > Since the packet fields definitions may be reused, do not prefix > them with acl- - in fact those prefixes are not really needed in > YANG since you prefix identifiers when use them. Perhaps think about > a shorter prefix than 'packet-fields'? Agreed, same as above. > > Some fields need more description. Is it useful to represent the > protocol by number? So this a long historical problem. Some protocols have well known names and name should be used, others are not well known so numbers are used. Ideally, there would be separate yang module that contains the protocol to name relationship standardized by IANA. http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml#pro tocol-numbers-1 This would be very useful and prevent confusion. As numbers are assigned, the model/draft is updated to reflect the standard assignments. Our more and other models could reference it. =20 > > Should the ip-header-fields not include the ipv4/ipv6 header fields > (e.g. in a choice)? Right now, the user of the definitions has to Possible, but we need to be careful that the model does not allow a user to configure an IPv4 source and IPv6 destination in the same rule. > create and maintain the choice. I also note that the fields are > called ...-address but the type is really a prefix. So the idea is > that you match an address taken from the packet header against a > prefix. I guess this (though perhaps obvious to us) should be > explained in the missing description statements. [Note that the type > for source-ipv6-address is ...-address - I guess this is a typo.] Will work on this. The --ietf option forces descriptions here. > > You should explain how address masking is supposed to work just to > be clear everybody does the same thing. What about VLANs? Out of > scope? We can include VLAN header in eth-header-fields. > > What is the purpose of the absolute container of the timerange > definition? There is no other timerange defined. The description > of 'active' is somewhat confusing. > > While the Internet ages, we see interesting layerings coming > along. (I do not want to mention WebRTC.) How does your framework > apply to tunnels etc? I assume all this applies only to the outer > headers and I can't say filter IP in IP encapsulated traffic with > it. That is fine but supposed I need to, can I extend this easily? This is definitiely an interesting area to explore, and would reveal how flexible/extensible the model is. I've seen very explict match criteria which assumes only 2 IP headers (single tunnel encapsulation). However we address this in the model, it should allow an arbitrary number of header L2 and L3 encapsulations. Something to think about. > > A bigger question I have is how the 'packet-header' module (needs a > better name) is being maintained. Is this cast into stone via an RFC > and then RFC update rules apply? Or is this to be maintained by IANA > with a careful review process? And if changes are made, how does a > client figure out which set of filters an implementation supports? > Do we need to define suitable features? Are features sufficient - > what happens if I add say flow-label to the IP header fields? I personally (not necessarily all authors), would prefer that there be a seperate model/draft which defines the standard IP and Ethernet Header fields. Then this could be used by many models. If there was a standard model for the IP header, and the acl rule references, and a vendor chose not to implement matching on some field, how could an augmentation exclude this. I'm not sure feature is useful here, because the number of features might proliferate rapidly. > > Should things perhaps be split into several modules, one for > Ethernet header matching, one for IP header matching, one for > transport header matching to make updates and maintenance easier? Seperate and managed according to RFC definitions and IANA would be better IMO. > >- Section 4.3: I do not understand the 'range' enum of the > match-simple-payload-protocol-value grouping. > >- Several citations are duplicated in the text, such as [RFC6241] > [RFC6241]. > >- Section 4.4 should use IP addresses reserved for examples and not > just 1.1.1.1 and 2.2.2.2. I am also not sure that showing some > random proprietary CLI is a good way of describing an example in an > I-D - simple remove Figure 1. In Figure 2, I would remove all the > edit-config noise and focus only on the config data. That said, I am > not sure what is nor am I convinced you got the namespaces > right. Make sure you validate your examples against the data model. > (See the pyang tutorial on how to do that.) > >- Section 5 probably needs to be expanded. Linux has tables, chains, > and rules and it would be nice to document how things actually map > to the concepts in the propose data model. Authors will review these, and comment or make updates in the next version. Again, thanks for your thorough review. thanks, Dana > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 From nobody Thu Jul 31 09:03:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57B51A00D5; Thu, 31 Jul 2014 09:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.151 X-Spam-Level: X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Dvl8I3Y63-z; Thu, 31 Jul 2014 09:03:43 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC28D1A00B5; Thu, 31 Jul 2014 09:03:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A54C5129D; Thu, 31 Jul 2014 18:03:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id NM2cjJT2xdrq; Thu, 31 Jul 2014 18:03:38 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 31 Jul 2014 18:03:41 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A5C02002F; Thu, 31 Jul 2014 18:03:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id hekA4KnseWp6; Thu, 31 Jul 2014 18:03:40 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0B74920017; Thu, 31 Jul 2014 18:03:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 23AFE2E00C11; Thu, 31 Jul 2014 18:03:37 +0200 (CEST) Date: Thu, 31 Jul 2014 18:03:36 +0200 From: Juergen Schoenwaelder To: iesg-secretary@ietf.org, Benoit Claise Message-ID: <20140731160335.GA65079@elstar.local> Mail-Followup-To: iesg-secretary@ietf.org, Benoit Claise , netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Re_ug1opefZDKnVQNV-KHeQepY4 Cc: netmod@ietf.org Subject: [netmod] NETMOD WG Interim Meeting, September 17-18, 2014 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2014 16:03:46 -0000 The IETF NETMOD WG will hold an Interim Meeting on September 17-18, 2014. The meeting will take place at One Penn Plaza, 9th Floor New York, NY 10119 USA. The agenda of the meeting is to work on YANG 1.1 open issues and in particular on - issues related to YANG 1.1 conformance; - issues related to YANG 1.1 datastores and I2RS support; - any remaining open YANG 1.1 issues. If you'd like to attend, please register by sending an email to the NETMOD WG chairs. The meeting details with further information about the participants and meeting logistics will be maintained in the SVN of the NETMOD working group http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ and also posted on the NETMOD mailing list. A preliminary list of participants is on the following Doodle poll: http://doodle.com/7eptxb7mggtdhwmc /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Jul 31 09:06:24 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5D51A0117; Thu, 31 Jul 2014 09:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPdWmGKGn2SH; Thu, 31 Jul 2014 09:06:22 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1017B1A00FF; Thu, 31 Jul 2014 09:06:22 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CDCF06D7; Thu, 31 Jul 2014 18:06:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id dYBmtQrg0gnA; Thu, 31 Jul 2014 18:06:17 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 31 Jul 2014 18:06:20 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4426A2002C; Thu, 31 Jul 2014 18:06:20 +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 nr0Mo27alAhr; Thu, 31 Jul 2014 18:06:19 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4A8A820017; Thu, 31 Jul 2014 18:06:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6522B2E00C47; Thu, 31 Jul 2014 18:06:17 +0200 (CEST) Date: Thu, 31 Jul 2014 18:06:16 +0200 From: Juergen Schoenwaelder To: iesg-secretary@ietf.org Message-ID: <20140731160616.GB65079@elstar.local> Mail-Followup-To: iesg-secretary@ietf.org, netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Q_FIwwWZnO2KWTQV2dT84xUN82U Cc: netmod@ietf.org Subject: [netmod] NETMOD WG Virtual Interim Meetings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2014 16:06:23 -0000 The NETMOD WG will hold a series of weekly virtual interim meetings. The meetings will take place on Wednesdays between 16:00 and 18:00 CEST. The first meeting will be on Wednesday 2014-08-27. The agenda is to iterate over the YANG 1.1 issues list with the goal to close open issues until there are none left open. The virtual interim meetings will continue weekly until either all issues have been closed or 2014-10-22 has passed (the last Wednesday before the I-D cutoff for IETF 91). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Jul 31 12:33:15 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D62D1A008B; Thu, 31 Jul 2014 12:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKQ5YVvvhLkX; Thu, 31 Jul 2014 12:33:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 011121A0084; Thu, 31 Jul 2014 12:33:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140731193311.24685.49820.idtracker@ietfa.amsl.com> Date: Thu, 31 Jul 2014 12:33:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2aBCOmw0r87_lVLFElOhNrypJes Cc: netmod@ietf.org Subject: [netmod] NETMOD WG Virtual Interim Meetings beginning 2014-08-27 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 19:33:13 -0000 The NETMOD WG will hold a series of weekly virtual interim meetings. The meetings will take place on Wednesdays between 16:00 and 18:00 CEST. The first meeting will be on Wednesday 2014-08-27. The agenda is to iterate over the YANG 1.1 issues list with the goal to close open issues until there are none left open. The virtual interim meetings will continue weekly until either all issues have been closed or 2014-10-22 has passed (the last Wednesday before the I-D cutoff for IETF 91). From lonvick@gmail.com Thu Jul 31 11:36:16 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5A51A0271 for ; Thu, 31 Jul 2014 11:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIfdI9XkPLcP for ; Thu, 31 Jul 2014 11:36:14 -0700 (PDT) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 389A71A0164 for ; Thu, 31 Jul 2014 11:36:14 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id hq11so4946801vcb.30 for ; Thu, 31 Jul 2014 11:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HFM9y9HxPjsCycxi0z2qAlqIMmIcNanOHyUGqBGiQBs=; b=Ay/TIQSIX9QpURUYW5zHiXnJ1QqNxQir290ZJ9EpqgqR9rxZwJ2rcM7612dXs5ABFW 90Lcv90u4Jq0isrSkRBJJZlX7H9JsbaMFOhVcVAdIzubjoYRUC4xAXvFM/H9n6j59ThD 9fOdbZaDIOWw7tVzyeq0gYtnmVqA07ODdveNGRFz/2fkAWWPHuVEKDjlEdJ3x0Megmxq 65VrSS4YiA/zmX/m76cxaIAOayKE0InwMntLp3ZbCywwuZlNm/7ljj9tNi/Dz0Qk1wVG SJXEThV7XtmyJ8O32AgRsLbed+aemMavSOw15tr24qgoZf6ylMZxr0ETaPnzvb6ih5jB /g3Q== MIME-Version: 1.0 X-Received: by 10.220.195.67 with SMTP id eb3mr49189vcb.30.1406831773256; Thu, 31 Jul 2014 11:36:13 -0700 (PDT) Received: by 10.52.231.5 with HTTP; Thu, 31 Jul 2014 11:36:13 -0700 (PDT) In-Reply-To: References: <20140722150553.GB12083@elstar.local> <53CEA093.2070000@cisco.com> <20140730145856.GL29365@pfrc> <53D90D95.5090001@cisco.com> Date: Thu, 31 Jul 2014 11:36:13 -0700 Message-ID: From: Chris Lonvick To: "Lange, Jeffrey K (GE Energy Management)" Content-Type: multipart/alternative; boundary=089e0158b0a81a946704ff818ca5 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/BhIu1_-WzlSkrX0Gw20bs3_YRGo X-Mailman-Approved-At: Thu, 31 Jul 2014 13:13:55 -0700 Cc: Kiran Agrahara Sreenivasa , "rgerhards@hq.adiscon.com" , "netmod@ietf.org" Subject: Re: [netmod] Syslog YANG Model Presentation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 20:06:54 -0000 --089e0158b0a81a946704ff818ca5 Content-Type: text/plain; charset=UTF-8 Hi, The very brief background: - the syslog WG was chartered under the Security Area to secure the protocol - the BEEP work never took off so we rechartered and found that we needed to make changes to the protocol itself - in making the changes, Rainer Gerhards proposed structured data and the WG liked that - 5424 makes use of structured data but there are few implementations that strictly adhere to the changes made to the packet header On the other hand, everyone likes structured data and I've seen it used in many places. As far as I know, there have been no efforts to standardize structured data but people are using it in many places because it is very versatile and efficient, and it gets the job done. :-) I've been working (off and on and hopefully more 'on' soon) on an ID that explains how non-standardized messages have been conveyed in IETF-documented protocols. It will need a couple of more revisions before it's ready for consideration for publication but you may get some ideas from it. https://datatracker.ietf.org/doc/draft-lonvick-private-tax/?include_text=1 Best regards, Chris On Thu, Jul 31, 2014 at 6:19 AM, Lange, Jeffrey K (GE Energy Management) < jeffrey.K.lange@ge.com> wrote: > Benoit, > We (GE MDS) support 5424/5425/5426 structured messages on our products > (with vendor specific structured-data). > > -Jeff Lange > > > > From: Benoit Claise > > Date: Wednesday, July 30, 2014 at 11:21 AM > To: Jeffrey Haas > > Cc: "lonvick@gmail.com" >, Kiran Agrahara Sreenivasa > >, "netmod@ietf.org > " >, " > rgerhards@hq.adiscon.com" < > rgerhards@hq.adiscon.com> > Subject: Re: [netmod] Syslog YANG Model Presentation > > Jeff, > > Thanks. > So I guess we need to support RFC 5424, RFC 5425, and RFC 5426 > configuration in the YANG model, right? > You use only vendor specific STRUCTURED-DATA? Because I don't see many in > the IANA registry< > http://www.iana.org/assignments/syslog-parameters/syslog-parameters.xhtml#syslog-parameters-4>, > and http://tools.ietf.org/html/rfc5424#section-9.2 requests IANA > registration. > > If my memory serves me well (I copied a couple of old timers), the > STRUCTURED-DATA goal was to standardize the syslog message content in the > industry, but that did not happen. > > Regards, Benoit > > Benoit, > > On Tue, Jul 22, 2014 at 01:34:11PM -0400, Benoit Claise wrote: > > > PS: I think you should also refer to the standards-track version of > SYSLOG (RFC 5424) in the references and perhaps filters should > also be able to operate on structured content. > > > Is RFC 5424 actually deployed? > > > Juniper has supported it for years. > > -- Jeff > . > > > > --089e0158b0a81a946704ff818ca5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
The very brief background:
- the syslog WG was chartered under the Security Area to secure the proto= col
- the BEEP work never took off so we rechartered and found th= at we needed to make changes to the protocol itself
- in making the changes, Rainer Gerhards proposed structured data and = the WG liked that
- 5424 makes use of structured data but there a= re few implementations that strictly adhere to the changes made to the pack= et header

On the other hand, everyone likes structured data and I= 've seen it used in many places. =C2=A0As far as I know, there have bee= n no efforts to standardize structured data but people are using it in many= places because it is very versatile and efficient, and it gets the job don= e. =C2=A0:-)

I've been working (off and on and hopefully more &#= 39;on' soon) on an ID that explains how non-standardized messages have = been conveyed in IETF-documented protocols. =C2=A0It will need a couple of = more revisions before it's ready for consideration for publication but = you may get some ideas from it.

Best regards,=
Chris


On Thu, Jul 3= 1, 2014 at 6:19 AM, Lange, Jeffrey K (GE Energy Management) <jeffrey.= K.lange@ge.com> wrote:
Benoit,
=C2=A0 We (GE MDS) support 5424/5425/5426 structured messages on our produc= ts (with vendor specific structured-data).

-Jeff Lange



From: Benoit Claise <bclaise@cisco.= com<mailto:bclaise@cisco.com>>
Date: Wednesday, July 30, 2014 at 11:21 AM
To: Jeffrey Haas <jhaas@pfrc.org&l= t;mailto:jhaas@pfrc.org>>
Cc: "lonvick@gmail.com<mai= lto:lonvick@gmail.com>" &l= t;lonvick@gmail.com<mailto:lonvick@gmail.com>>, Kiran Agrah= ara Sreenivasa <kkoushik@Brocade.com<mailto:kkoushik@Brocade.com>>, "netmod@ietf.org<mailto:netmod@ietf.org>" <n= etmod@ietf.org<mailto:netmod@ietf= .org>>, "rgerhar= ds@hq.adiscon.com<mailto:rgerhards@hq.adiscon.com>" <rgerhards@hq.adiscon.com<mailto:rgerhards@hq.adiscon.com>>
Subject: Re: [netmod] Syslog YANG Model Presentation

Jeff,

Thanks.
So I guess we need to support RFC 5424, RFC 5425, and RFC 5426 configuratio= n in the YANG model, right?
You use only vendor specific STRUCTURED-DATA? Because I don't see many = in the IANA registry<ht= tp://www.iana.org/assignments/syslog-parameters/syslog-parameters.xhtml#sys= log-parameters-4>, and http://tools.ietf.org/html/rfc5424#section-= 9.2 requests IANA registration.

If my memory serves me well (I copied a couple of old timers), the STRUCTUR= ED-DATA goal was to standardize the syslog message content in the industry,= but that did not happen.

Regards, Benoit

Benoit,

On Tue, Jul 22, 2014 at 01:34:11PM -0400, Benoit Claise wrote:


PS: I think you should also refer to the standards-track version of
=C2=A0 =C2=A0 SYSLOG (RFC 5424) in the references and perhaps filters shoul= d
=C2=A0 =C2=A0 also be able to operate on structured content.


Is RFC 5424 actually deployed?


Juniper has supported it for years.

-- Jeff
.




--089e0158b0a81a946704ff818ca5-- From nobody Thu Jul 31 16:49:11 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFC91A0080; Thu, 31 Jul 2014 16:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDh5YZej6E02; Thu, 31 Jul 2014 16:49:06 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BB171A0301; Thu, 31 Jul 2014 16:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19801; q=dns/txt; s=iport; t=1406850544; x=1408060144; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Svw2C60Lw80f7gy7vE3gbzXzQZOfSehj3k6z268wzis=; b=ccyoKFSB6y6+ZdMKxvTKU9KZXMh2zjvSVtaVheLKkYFEphcCksdRttAj 64DQrHzpVyNim+CRbohcg+uwfT4pwhoWFokXx5WXJt6B67sLu+gIhWtqa kdDWk5qHX7CksEGILxNgNpTqno4os0OGXjqrXxIWy6RTPMJ4s3uOG31cS I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0IAEPV2lOtJV2T/2dsb2JhbABbgkdGUlcEsw+YOIFYAQuHSQGBCBZ3hAMBAQEEAQEBKjoHCxACAQgRBAEBCxYHByEGCxQJCAEBBAENBQiIJgMRDcQDDYcPF40fgVUnLQQGAYMvgRwFmW2DWYxfhiWDSWwBgQJC X-IronPort-AV: E=Sophos;i="5.01,775,1400025600"; d="scan'208,217";a="344292690" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-6.cisco.com with ESMTP; 31 Jul 2014 23:49:03 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s6VNn3Ia024256 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jul 2014 23:49:03 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.152]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Thu, 31 Jul 2014 18:49:03 -0500 From: "Tissa Senevirathne (tsenevir)" To: "O'Connor, Don" , Tissa Senevirathne , Greg Mirsky Thread-Topic: [nvo3] YANG models for OAM Thread-Index: Ac+E3qlMyPi638vnRGmjYh75Wx+edAoWIbcAAAE6agAACU5iwAAR6gcA Date: Thu, 31 Jul 2014 23:49:03 +0000 Message-ID: References: <1406847186.16320.YahooMailNeo@web162805.mail.bf1.yahoo.com> <7DFA7869D33BD44A9A84BA24AD75BDE6D9E4645D@RCHEXMBP1.fnc.net.local> In-Reply-To: <7DFA7869D33BD44A9A84BA24AD75BDE6D9E4645D@RCHEXMBP1.fnc.net.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.71.119] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562EEE0F1Bxmbrcdx08ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/rWjzn4eLAe4oCRMuuT62cOw3LFY Cc: "l2vpn@ietf.org" , "opsawg@ietf.org" , "nvo3@ietf.org" , "netmod@ietf.org" , "trill@ietf.org" Subject: Re: [netmod] [nvo3] YANG models for OAM X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 23:49:08 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE193562EEE0F1Bxmbrcdx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Don I am aware of that, but this is different, MEF YANG model is specifically f= or Ethernet and structure does not allow to bring different addressing sche= mes other than MAC address. Additionally the proposed standard allow to add= flow entropies and facilitate nested OAM between different technologies. Y= ou may have to read in to the details to see the actual differences. From: O'Connor, Don [mailto:don.oconnor@us.fujitsu.com] Sent: Thursday, July 31, 2014 4:32 PM To: Tissa Senevirathne; Greg Mirsky; Tissa Senevirathne (tsenevir) Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@= ietf.org Subject: RE: [nvo3] YANG models for OAM Tissa, Greg, all Metro Ethernet Forum has already standardized Yang Modules for Ethernet Ser= vice OAM Performance Monitoring and Fault Management. Please see MEF 38 and= 39 http://metroethernetforum.org/carrier-ethernet/technical-specifications Regards Don From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Tissa Senevirathne Sent: Thursday, July 31, 2014 5:53 PM To: Greg Mirsky; Tissa Senevirathne (tsenevir) Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@ietf.org Subject: Re: [nvo3] YANG models for OAM Greg Yes it is, generic YANG model steup the base framework. It can be extended = to add tools as well as other elements as well technology deviations. Alarm= s etc either be part of this document will be a separate document that spec= ifies them. That is the reason we have designed the model as modular as pos= sible and extensible as possible. Please let us know if any of the parts are not extensible or not modular en= ough. Thanks Tissa On Thursday, July 31, 2014 3:17 PM, Greg Mirsky > wrote: Hi Tissa, authors, et. al, I've read documents and would like to clarify scope of these documents. OAM= is not limited to ping and traceroute functions. It even not limited to co= ntinuity check. And in connectionless networks there would not be connectiv= ity verification. And the performance measurement is the big part of OAM as= well as protection coordination, defect alarms, and etc. Hence my question= , is it in plans of the authors to address all of OAM in respective documen= ts? Regards, Greg On Tue, Jun 10, 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) > wrote: All We have published YANG model for OAM. #1 draft below place the generic fram= ework for OAM, that can be augmented for different technologies. #2 and #3 = are application of the concept to NVO3 and TRILL, 1. http://datatracker.ietf.org/doc/draft-tissa-netmod-oam/ 2. http://datatracker.ietf.org/doc/draft-tissa-nvo3-yang-oam/ 3. http://datatracker.ietf.org/doc/draft-tissa-trill-yang-oam/ Please review and share your comments Thanks Tissa _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 --_000_FBEA3E19AA24F847BA3AE74E2FE193562EEE0F1Bxmbrcdx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Don


I am aware of that, but this is different, MEF YANG model is specifically f= or Ethernet and structure does not allow to bring different addressing sche= mes other than MAC address. Additionally the proposed standard allow to add= flow entropies and facilitate nested OAM between different technologies. You may have to read in to the details= to see the actual differences.

 <= /p>

From: O'Connor= , Don [mailto:don.oconnor@us.fujitsu.com]
Sent: Thursday, July 31, 2014 4:32 PM
To: Tissa Senevirathne; Greg Mirsky; Tissa Senevirathne (tsenevir) Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org;= trill@ietf.org
Subject: RE: [nvo3] YANG models for OAM

 

Tissa, Greg, all=

 

Metro Ethernet Forum has al= ready standardized Yang Modules for Ethernet Service OAM Performance Monito= ring and Fault Management. Please see MEF 38 and 39

 

http://metroethern= etforum.org/carrier-ethernet/technical-specifications=

 

Regards

 

Don

 

From: L2vpn [<= a href=3D"mailto:l2vpn-bounces@ietf.org">mailto:l2vpn-bounces@ietf.org] On Behalf Of Tissa Senevirathne
Sent: Thursday, July 31, 2014 5:53 PM
To: Greg Mirsky; Tissa Senevirathne (tsenevir)
Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@ietf.org Subject: Re: [nvo3] YANG models for OAM

 

Greg=

 

Yes it is, generic YANG model steup the ba= se framework. It can be extended to add tools as well as other elements as = well technology deviations. Alarms etc either be part of this document will be a separate document that specifies them. That is the= reason we have designed the model as modular as possible and extensible as= possible.

 

Please let us know if any of the parts are= not extensible or not modular enough.

 

Thanks

Tissa

 

On= Thursday, July 31, 2014 3:17 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:<= /o:p>

 

Hi Tissa, autho= rs, et. al,

I've read documents and would like to clarify scope of these document= s. OAM is not limited to ping and traceroute functions. It even not limited to continuity check. And in connectionless networks there= would not be connectivity verification. And the performance measurement is= the big part of OAM as well as protection coordination, defect alarms, and= etc. Hence my question, is it in plans of the authors to address all of OAM in respective documents?

Regards,

Greg=

 

On Tue, Jun 10,= 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) <tsenevir@cisco.com> wrote:

All<= /span>

 

We have publish= ed YANG model for OAM. #1 draft below place the generic framework for OAM, = that can be augmented for different technologies. #2 and #3 are application of the concept to NVO3 and TRILL,

 

 

Please review a= nd share your comments

 

Thanks

Tissa

 

 


_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3

 

 

--_000_FBEA3E19AA24F847BA3AE74E2FE193562EEE0F1Bxmbrcdx08ciscoc_-- From nobody Thu Jul 31 18:06:40 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7C91A0356; Thu, 31 Jul 2014 18:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6o6sUPwW5te; Thu, 31 Jul 2014 18:06:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D9D11A0350; Thu, 31 Jul 2014 18:06:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHU38814; Fri, 01 Aug 2014 01:06:25 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 1 Aug 2014 02:06:23 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Fri, 1 Aug 2014 09:06:17 +0800 From: Qin Wu To: "O'Connor, Don" , Tissa Senevirathne , Greg Mirsky , "Tissa Senevirathne (tsenevir)" Thread-Topic: [nvo3] YANG models for OAM Thread-Index: AQHPrRhFwrWBIAFeCEWqLpizz9QBWJu67tEA Date: Fri, 1 Aug 2014 01:06:16 +0000 Message-ID: References: <1406847186.16320.YahooMailNeo@web162805.mail.bf1.yahoo.com> <7DFA7869D33BD44A9A84BA24AD75BDE6D9E4645D@RCHEXMBP1.fnc.net.local> In-Reply-To: <7DFA7869D33BD44A9A84BA24AD75BDE6D9E4645D@RCHEXMBP1.fnc.net.local> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA8458DB09nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/23IdlAZFsdNpNXOmZB0VoK4nnzA Cc: "l2vpn@ietf.org" , "opsawg@ietf.org" , "nvo3@ietf.org" , "netmod@ietf.org" , "trill@ietf.org" Subject: Re: [netmod] [nvo3] YANG models for OAM X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 01:06:33 -0000 --_000_B8F9A780D330094D99AF023C5877DABA8458DB09nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSB0aGluayBNRUYgbW9yZSBsb29rIGF0IFlhbmcgZGF0YSBtb2R1bGUgZm9yIFkuMTczMSwgSXQg aXMgRXRoZXJuZXQgdGVjaG5vbG9neSBzcGVjaWZpYyBZYW5nIERhdGEgbW9kZWwuDQoNClJlZ2Fy ZHMhDQotUWluDQq3orz+yMs6IE9QU0FXRyBbbWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3Jn XSC0+rHtIE8nQ29ubm9yLCBEb24NCreiy83KsbzkOiAyMDE0xOo41MIxyNUgNzozMg0KytW8/sjL OiBUaXNzYSBTZW5ldmlyYXRobmU7IEdyZWcgTWlyc2t5OyBUaXNzYSBTZW5ldmlyYXRobmUgKHRz ZW5ldmlyKQ0Ks63LzTogbDJ2cG5AaWV0Zi5vcmc7IG9wc2F3Z0BpZXRmLm9yZzsgbnZvM0BpZXRm Lm9yZzsgbmV0bW9kQGlldGYub3JnOyB0cmlsbEBpZXRmLm9yZw0K1vfM4jogUmU6IFtPUFNBV0dd IFtudm8zXSBZQU5HIG1vZGVscyBmb3IgT0FNDQoNClRpc3NhLCBHcmVnLCBhbGwNCg0KTWV0cm8g RXRoZXJuZXQgRm9ydW0gaGFzIGFscmVhZHkgc3RhbmRhcmRpemVkIFlhbmcgTW9kdWxlcyBmb3Ig RXRoZXJuZXQgU2VydmljZSBPQU0gUGVyZm9ybWFuY2UgTW9uaXRvcmluZyBhbmQgRmF1bHQgTWFu YWdlbWVudC4gUGxlYXNlIHNlZSBNRUYgMzggYW5kIDM5DQoNCmh0dHA6Ly9tZXRyb2V0aGVybmV0 Zm9ydW0ub3JnL2NhcnJpZXItZXRoZXJuZXQvdGVjaG5pY2FsLXNwZWNpZmljYXRpb25zDQoNClJl Z2FyZHMNCg0KRG9uDQoNCkZyb206IEwydnBuIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIFRpc3NhIFNlbmV2aXJhdGhuZQ0KU2VudDogVGh1cnNkYXksIEp1bHkg MzEsIDIwMTQgNTo1MyBQTQ0KVG86IEdyZWcgTWlyc2t5OyBUaXNzYSBTZW5ldmlyYXRobmUgKHRz ZW5ldmlyKQ0KQ2M6IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz47IG9wc2F3 Z0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPjsgbnZvM0BpZXRmLm9yZzxtYWlsdG86 bnZvM0BpZXRmLm9yZz47IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPjsg dHJpbGxAaWV0Zi5vcmc8bWFpbHRvOnRyaWxsQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtudm8z XSBZQU5HIG1vZGVscyBmb3IgT0FNDQoNCkdyZWcNCg0KWWVzIGl0IGlzLCBnZW5lcmljIFlBTkcg bW9kZWwgc3RldXAgdGhlIGJhc2UgZnJhbWV3b3JrLiBJdCBjYW4gYmUgZXh0ZW5kZWQgdG8gYWRk IHRvb2xzIGFzIHdlbGwgYXMgb3RoZXIgZWxlbWVudHMgYXMgd2VsbCB0ZWNobm9sb2d5IGRldmlh dGlvbnMuIEFsYXJtcyBldGMgZWl0aGVyIGJlIHBhcnQgb2YgdGhpcyBkb2N1bWVudCB3aWxsIGJl IGEgc2VwYXJhdGUgZG9jdW1lbnQgdGhhdCBzcGVjaWZpZXMgdGhlbS4gVGhhdCBpcyB0aGUgcmVh c29uIHdlIGhhdmUgZGVzaWduZWQgdGhlIG1vZGVsIGFzIG1vZHVsYXIgYXMgcG9zc2libGUgYW5k IGV4dGVuc2libGUgYXMgcG9zc2libGUuDQoNClBsZWFzZSBsZXQgdXMga25vdyBpZiBhbnkgb2Yg dGhlIHBhcnRzIGFyZSBub3QgZXh0ZW5zaWJsZSBvciBub3QgbW9kdWxhciBlbm91Z2guDQoNClRo YW5rcw0KVGlzc2ENCg0KT24gVGh1cnNkYXksIEp1bHkgMzEsIDIwMTQgMzoxNyBQTSwgR3JlZyBN aXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29t Pj4gd3JvdGU6DQoNCkhpIFRpc3NhLCBhdXRob3JzLCBldC4gYWwsDQpJJ3ZlIHJlYWQgZG9jdW1l bnRzIGFuZCB3b3VsZCBsaWtlIHRvIGNsYXJpZnkgc2NvcGUgb2YgdGhlc2UgZG9jdW1lbnRzLiBP QU0gaXMgbm90IGxpbWl0ZWQgdG8gcGluZyBhbmQgdHJhY2Vyb3V0ZSBmdW5jdGlvbnMuIEl0IGV2 ZW4gbm90IGxpbWl0ZWQgdG8gY29udGludWl0eSBjaGVjay4gQW5kIGluIGNvbm5lY3Rpb25sZXNz IG5ldHdvcmtzIHRoZXJlIHdvdWxkIG5vdCBiZSBjb25uZWN0aXZpdHkgdmVyaWZpY2F0aW9uLiBB bmQgdGhlIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IGlzIHRoZSBiaWcgcGFydCBvZiBPQU0gYXMg d2VsbCBhcyBwcm90ZWN0aW9uIGNvb3JkaW5hdGlvbiwgZGVmZWN0IGFsYXJtcywgYW5kIGV0Yy4g SGVuY2UgbXkgcXVlc3Rpb24sIGlzIGl0IGluIHBsYW5zIG9mIHRoZSBhdXRob3JzIHRvIGFkZHJl c3MgYWxsIG9mIE9BTSBpbiByZXNwZWN0aXZlIGRvY3VtZW50cz8NClJlZ2FyZHMsDQpHcmVnDQoN Ck9uIFR1ZSwgSnVuIDEwLCAyMDE0IGF0IDEyOjAzIFBNLCBUaXNzYSBTZW5ldmlyYXRobmUgKHRz ZW5ldmlyKSA8dHNlbmV2aXJAY2lzY28uY29tPG1haWx0bzp0c2VuZXZpckBjaXNjby5jb20+PiB3 cm90ZToNCkFsbA0KDQpXZSBoYXZlIHB1Ymxpc2hlZCBZQU5HIG1vZGVsIGZvciBPQU0uICMxIGRy YWZ0IGJlbG93IHBsYWNlIHRoZSBnZW5lcmljIGZyYW1ld29yayBmb3IgT0FNLCB0aGF0IGNhbiBi ZSBhdWdtZW50ZWQgZm9yIGRpZmZlcmVudCB0ZWNobm9sb2dpZXMuICMyIGFuZCAjMyBhcmUgYXBw bGljYXRpb24gb2YgdGhlIGNvbmNlcHQgdG8gTlZPMyBhbmQgVFJJTEwsDQoNCjEuICAgICAgaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10aXNzYS1uZXRtb2Qtb2FtLw0KMi4g ICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRpc3NhLW52bzMteWFu Zy1vYW0vDQozLiAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGlz c2EtdHJpbGwteWFuZy1vYW0vDQoNClBsZWFzZSByZXZpZXcgYW5kIHNoYXJlIHlvdXIgY29tbWVu dHMNCg0KVGhhbmtzDQpUaXNzYQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCm52bzMgbWFpbGluZyBsaXN0DQpudm8zQGlldGYub3JnPG1haWx0 bzpudm8zQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u dm8zDQoNCg0K --_000_B8F9A780D330094D99AF023C5877DABA8458DB09nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

I think ME= F more look at Yang data module for Y.1731, It is Ethernet technology speci= fic Yang Data model.

 = ;

Regards!

-Qin<= /o:p>

=B7=A2=BC=FE=C8=CB: OPSAWG [mailto:opsawg= -bounces@ietf.org] =B4=FA=B1=ED = O'Connor, Don
=B7=A2=CB=CD= =CA=B1=BC=E4: 2014=C4=EA8=D4=C2<= span lang=3D"EN-US">1=C8=D5 7:32
=CA=D5=BC=FE=C8=CB: Tissa Senevirathne; Greg Mirsky; Tissa Senevirathne (tsenevir)
=B3=AD=CB=CD: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@ie= tf.org
=D6=F7=CC=E2: Re: [OPSAWG] [nvo3] YANG models for OAM

 

Tissa, Greg,= all

 <= /o:p>

Metro Ethern= et Forum has already standardized Yang Modules for Ethernet Service OAM Per= formance Monitoring and Fault Management. Please see MEF 38 and 39

 <= /o:p>

htt= p://metroethernetforum.org/carrier-ethernet/technical-specifications

 <= /o:p>

Regards=

 <= /o:p>

Don

 <= /o:p>

From: L2vpn [mail= to:l2vpn-bounces@ietf.org] On Behalf Of Tissa Senevirathne
Sent: Thursday, July 31, 2014 5:53 PM
To: Greg Mirsky; Tissa Senevirathne (tsenevir)
Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@ietf.org Subject: Re: [nvo3] YANG models for OAM

 

= Greg

 

Yes it is, generic YANG mod= el steup the base framework. It can be extended to add tools as well as oth= er elements as well technology deviations. Alarms etc either be part of this document will be a separate document that specifies them. = That is the reason we have designed the model as modular as possible and ex= tensible as possible.

 

Please let us know if any o= f the parts are not extensible or not modular enough.

 

Thanks

Tissa

 

On Thursday, July 31, 2014 3:17 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:<= span lang=3D"EN-US" style=3D"font-family:"Helvetica","sans-s= erif";color:black">

 

= Hi Tissa, authors, et. al,

I've read documents and would like to clarify scope of= these documents. OAM is not limited to ping and traceroute functions. It even not limited to continuity check. And in connectionless = networks there would not be connectivity verification. And the performance = measurement is the big part of OAM as well as protection coordination, defe= ct alarms, and etc. Hence my question, is it in plans of the authors to address all of OAM in respective document= s?

= Regards,

= Greg

 

= On Tue, Jun 10, 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) <tsenevir@cisco.com> wrote:

= All

=  

= We have published YANG model for OAM. #1 draft below place the generic fram= ework for OAM, that can be augmented for different technologies. #2 and #3 are application of the concept to NVO3 and TRILL,

=  

=  

= Please review and share your comments

=  

= Thanks

= Tissa

=  

=  


_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3

=  

 

--_000_B8F9A780D330094D99AF023C5877DABA8458DB09nkgeml501mbschi_-- From nobody Thu Jul 31 18:11:39 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6048A1A034F; Thu, 31 Jul 2014 18:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jss1tgYigvRg; Thu, 31 Jul 2014 18:11:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B57FE1A02BC; Thu, 31 Jul 2014 18:11:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHU39017; Fri, 01 Aug 2014 01:11:17 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 1 Aug 2014 02:11:14 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Fri, 1 Aug 2014 09:11:11 +0800 From: Qin Wu To: "Tissa Senevirathne (tsenevir)" , "O'Connor, Don" , Tissa Senevirathne , Greg Mirsky Thread-Topic: [nvo3] YANG models for OAM Thread-Index: AQHPrRhFwrWBIAFeCEWqLpizz9QBWJu6U7eAgACcEoA= Date: Fri, 1 Aug 2014 01:11:09 +0000 Message-ID: References: <1406847186.16320.YahooMailNeo@web162805.mail.bf1.yahoo.com> <7DFA7869D33BD44A9A84BA24AD75BDE6D9E4645D@RCHEXMBP1.fnc.net.local> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA8458DB1Dnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6HQEKYHNSSG_iUB73MlSpp39egM Cc: "l2vpn@ietf.org" , "opsawg@ietf.org" , "nvo3@ietf.org" , "netmod@ietf.org" , "trill@ietf.org" Subject: Re: [netmod] [nvo3] YANG models for OAM X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 01:11:26 -0000 --_000_B8F9A780D330094D99AF023C5877DABA8458DB1Dnkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RXhhY3RseSwgZGlmZmVyZW50IGxheWVyIG1heSBoYXZlIGRpZmZlcmVudCBhZGRyZXNzaW5nIHNj aGVtZXMuIEJ1dCBJIGFtIHdvbmRlcmluZyB3aGljaCBsYXllciB0aGUgZmxvdyBlbnRyb3BpZXMg YXJlIGFwcGxpZWQ/IEwyLCBMMywgTVBMUyBsYXllcj8NCg0Kt6K8/sjLOiBuZXRtb2QgW21haWx0 bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5l dmlyKQ0Kt6LLzcqxvOQ6IDIwMTTE6jjUwjHI1SA3OjQ5DQrK1bz+yMs6IE8nQ29ubm9yLCBEb247 IFRpc3NhIFNlbmV2aXJhdGhuZTsgR3JlZyBNaXJza3kNCrOty806IGwydnBuQGlldGYub3JnOyBv cHNhd2dAaWV0Zi5vcmc7IG52bzNAaWV0Zi5vcmc7IG5ldG1vZEBpZXRmLm9yZzsgdHJpbGxAaWV0 Zi5vcmcNCtb3zOI6IFJlOiBbbmV0bW9kXSBbbnZvM10gWUFORyBtb2RlbHMgZm9yIE9BTQ0KDQpE b24NCg0KSSBhbSBhd2FyZSBvZiB0aGF0LCBidXQgdGhpcyBpcyBkaWZmZXJlbnQsIE1FRiBZQU5H IG1vZGVsIGlzIHNwZWNpZmljYWxseSBmb3IgRXRoZXJuZXQgYW5kIHN0cnVjdHVyZSBkb2VzIG5v dCBhbGxvdyB0byBicmluZyBkaWZmZXJlbnQgYWRkcmVzc2luZyBzY2hlbWVzIG90aGVyIHRoYW4g TUFDIGFkZHJlc3MuIEFkZGl0aW9uYWxseSB0aGUgcHJvcG9zZWQgc3RhbmRhcmQgYWxsb3cgdG8g YWRkIGZsb3cgZW50cm9waWVzIGFuZCBmYWNpbGl0YXRlIG5lc3RlZCBPQU0gYmV0d2VlbiBkaWZm ZXJlbnQgdGVjaG5vbG9naWVzLiBZb3UgbWF5IGhhdmUgdG8gcmVhZCBpbiB0byB0aGUgZGV0YWls cyB0byBzZWUgdGhlIGFjdHVhbCBkaWZmZXJlbmNlcy4NCg0KRnJvbTogTydDb25ub3IsIERvbiBb bWFpbHRvOmRvbi5vY29ubm9yQHVzLmZ1aml0c3UuY29tXQ0KU2VudDogVGh1cnNkYXksIEp1bHkg MzEsIDIwMTQgNDozMiBQTQ0KVG86IFRpc3NhIFNlbmV2aXJhdGhuZTsgR3JlZyBNaXJza3k7IFRp c3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpDQpDYzogbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwy dnBuQGlldGYub3JnPjsgb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+OyBu dm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPjsgbmV0bW9kQGlldGYub3JnPG1haWx0 bzpuZXRtb2RAaWV0Zi5vcmc+OyB0cmlsbEBpZXRmLm9yZzxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSRTogW252bzNdIFlBTkcgbW9kZWxzIGZvciBPQU0NCg0KVGlzc2EsIEdyZWcs IGFsbA0KDQpNZXRybyBFdGhlcm5ldCBGb3J1bSBoYXMgYWxyZWFkeSBzdGFuZGFyZGl6ZWQgWWFu ZyBNb2R1bGVzIGZvciBFdGhlcm5ldCBTZXJ2aWNlIE9BTSBQZXJmb3JtYW5jZSBNb25pdG9yaW5n IGFuZCBGYXVsdCBNYW5hZ2VtZW50LiBQbGVhc2Ugc2VlIE1FRiAzOCBhbmQgMzkNCg0KaHR0cDov L21ldHJvZXRoZXJuZXRmb3J1bS5vcmcvY2Fycmllci1ldGhlcm5ldC90ZWNobmljYWwtc3BlY2lm aWNhdGlvbnMNCg0KUmVnYXJkcw0KDQpEb24NCg0KRnJvbTogTDJ2cG4gW21haWx0bzpsMnZwbi1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGlzc2EgU2VuZXZpcmF0aG5lDQpTZW50OiBU aHVyc2RheSwgSnVseSAzMSwgMjAxNCA1OjUzIFBNDQpUbzogR3JlZyBNaXJza3k7IFRpc3NhIFNl bmV2aXJhdGhuZSAodHNlbmV2aXIpDQpDYzogbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGll dGYub3JnPjsgb3BzYXdnQGlldGYub3JnPG1haWx0bzpvcHNhd2dAaWV0Zi5vcmc+OyBudm8zQGll dGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPjsgbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRt b2RAaWV0Zi5vcmc+OyB0cmlsbEBpZXRmLm9yZzxtYWlsdG86dHJpbGxAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW252bzNdIFlBTkcgbW9kZWxzIGZvciBPQU0NCg0KR3JlZw0KDQpZZXMgaXQgaXMs IGdlbmVyaWMgWUFORyBtb2RlbCBzdGV1cCB0aGUgYmFzZSBmcmFtZXdvcmsuIEl0IGNhbiBiZSBl eHRlbmRlZCB0byBhZGQgdG9vbHMgYXMgd2VsbCBhcyBvdGhlciBlbGVtZW50cyBhcyB3ZWxsIHRl Y2hub2xvZ3kgZGV2aWF0aW9ucy4gQWxhcm1zIGV0YyBlaXRoZXIgYmUgcGFydCBvZiB0aGlzIGRv Y3VtZW50IHdpbGwgYmUgYSBzZXBhcmF0ZSBkb2N1bWVudCB0aGF0IHNwZWNpZmllcyB0aGVtLiBU aGF0IGlzIHRoZSByZWFzb24gd2UgaGF2ZSBkZXNpZ25lZCB0aGUgbW9kZWwgYXMgbW9kdWxhciBh cyBwb3NzaWJsZSBhbmQgZXh0ZW5zaWJsZSBhcyBwb3NzaWJsZS4NCg0KUGxlYXNlIGxldCB1cyBr bm93IGlmIGFueSBvZiB0aGUgcGFydHMgYXJlIG5vdCBleHRlbnNpYmxlIG9yIG5vdCBtb2R1bGFy IGVub3VnaC4NCg0KVGhhbmtzDQpUaXNzYQ0KDQpPbiBUaHVyc2RheSwgSnVseSAzMSwgMjAxNCAz OjE3IFBNLCBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPG1haWx0bzpncmVnaW1p cnNreUBnbWFpbC5jb20+PiB3cm90ZToNCg0KSGkgVGlzc2EsIGF1dGhvcnMsIGV0LiBhbCwNCkkn dmUgcmVhZCBkb2N1bWVudHMgYW5kIHdvdWxkIGxpa2UgdG8gY2xhcmlmeSBzY29wZSBvZiB0aGVz ZSBkb2N1bWVudHMuIE9BTSBpcyBub3QgbGltaXRlZCB0byBwaW5nIGFuZCB0cmFjZXJvdXRlIGZ1 bmN0aW9ucy4gSXQgZXZlbiBub3QgbGltaXRlZCB0byBjb250aW51aXR5IGNoZWNrLiBBbmQgaW4g Y29ubmVjdGlvbmxlc3MgbmV0d29ya3MgdGhlcmUgd291bGQgbm90IGJlIGNvbm5lY3Rpdml0eSB2 ZXJpZmljYXRpb24uIEFuZCB0aGUgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgaXMgdGhlIGJpZyBw YXJ0IG9mIE9BTSBhcyB3ZWxsIGFzIHByb3RlY3Rpb24gY29vcmRpbmF0aW9uLCBkZWZlY3QgYWxh cm1zLCBhbmQgZXRjLiBIZW5jZSBteSBxdWVzdGlvbiwgaXMgaXQgaW4gcGxhbnMgb2YgdGhlIGF1 dGhvcnMgdG8gYWRkcmVzcyBhbGwgb2YgT0FNIGluIHJlc3BlY3RpdmUgZG9jdW1lbnRzPw0KUmVn YXJkcywNCkdyZWcNCg0KT24gVHVlLCBKdW4gMTAsIDIwMTQgYXQgMTI6MDMgUE0sIFRpc3NhIFNl bmV2aXJhdGhuZSAodHNlbmV2aXIpIDx0c2VuZXZpckBjaXNjby5jb208bWFpbHRvOnRzZW5ldmly QGNpc2NvLmNvbT4+IHdyb3RlOg0KQWxsDQoNCldlIGhhdmUgcHVibGlzaGVkIFlBTkcgbW9kZWwg Zm9yIE9BTS4gIzEgZHJhZnQgYmVsb3cgcGxhY2UgdGhlIGdlbmVyaWMgZnJhbWV3b3JrIGZvciBP QU0sIHRoYXQgY2FuIGJlIGF1Z21lbnRlZCBmb3IgZGlmZmVyZW50IHRlY2hub2xvZ2llcy4gIzIg YW5kICMzIGFyZSBhcHBsaWNhdGlvbiBvZiB0aGUgY29uY2VwdCB0byBOVk8zIGFuZCBUUklMTCwN Cg0KMS4gICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRpc3NhLW5l dG1vZC1vYW0vDQoyLiAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt dGlzc2EtbnZvMy15YW5nLW9hbS8NCjMuICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC10aXNzYS10cmlsbC15YW5nLW9hbS8NCg0KUGxlYXNlIHJldmlldyBhbmQgc2hh cmUgeW91ciBjb21tZW50cw0KDQpUaGFua3MNClRpc3NhDQoNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbnZvMyBtYWlsaW5nIGxpc3QNCm52bzNA aWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL252bzMNCg0KDQo= --_000_B8F9A780D330094D99AF023C5877DABA8458DB1Dnkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Exactly, d= ifferent layer may have different addressing schemes. But I am wondering wh= ich layer the flow entropies are applied? L2, L3, MPLS layer?

 = ;

=B7=A2=BC=FE=C8=CB: netmod = [mailto:netmod-bounces@ietf.org] =B4=FA= =B1=ED Tissa Senevirathne (tsenevir)
=B7=A2= =CB=CD=CA=B1=BC=E4: 2014=C4=EA8=D4=C21=C8=D5 7:49
=CA=D5=BC=FE=C8=CB: O'Connor, Don; Tissa Senevirathne; Greg Mirsky
=B3=AD=CB=CD: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@ie= tf.org
=D6=F7=CC=E2: Re: [netmod] [nvo3] YANG models for OAM

 

Don


I am aware of that, but this is different, MEF YANG model is specifically f= or Ethernet and structure does not allow to bring different addressing sche= mes other than MAC address. Additionally the proposed standard allow to add= flow entropies and facilitate nested OAM between different technologies. You may have to read in to the details= to see the actual differences.

 = ;

From: O'Connor, Don [mailto:don.oconnor@us.fujitsu.com]
Sent: Thursday, July 31, 2014 4:32 PM
To: Tissa Senevirathne; Greg Mirsky; Tissa Senevirathne (tsenevir) Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@ietf.org Subject: RE: [nvo3] YANG models for OAM

 

Tissa, Greg,= all

 <= /o:p>

Metro Ethern= et Forum has already standardized Yang Modules for Ethernet Service OAM Per= formance Monitoring and Fault Management. Please see MEF 38 and 39

 <= /o:p>

htt= p://metroethernetforum.org/carrier-ethernet/technical-specifications

 <= /o:p>

Regards=

 <= /o:p>

Don

 <= /o:p>

From: L2vpn [mail= to:l2vpn-bounces@ietf.org] On Behalf Of Tissa Senevirathne
Sent: Thursday, July 31, 2014 5:53 PM
To: Greg Mirsky; Tissa Senevirathne (tsenevir)
Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@ietf.org Subject: Re: [nvo3] YANG models for OAM

 

= Greg

 

Yes it is, generic YANG mod= el steup the base framework. It can be extended to add tools as well as oth= er elements as well technology deviations. Alarms etc either be part of this document will be a separate document that specifies them. = That is the reason we have designed the model as modular as possible and ex= tensible as possible.

 

Please let us know if any o= f the parts are not extensible or not modular enough.

 

Thanks

Tissa

 

On Thursday, July 31, 2014 3:17 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:<= span lang=3D"EN-US" style=3D"font-family:"Helvetica","sans-s= erif";color:black">

 

= Hi Tissa, authors, et. al,

I've read documents and would like to clarify scope of= these documents. OAM is not limited to ping and traceroute functions. It even not limited to continuity check. And in connectionless = networks there would not be connectivity verification. And the performance = measurement is the big part of OAM as well as protection coordination, defe= ct alarms, and etc. Hence my question, is it in plans of the authors to address all of OAM in respective document= s?

= Regards,

= Greg

 

= On Tue, Jun 10, 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) <tsenevir@cisco.com> wrote:

= All

=  

= We have published YANG model for OAM. #1 draft below place the generic fram= ework for OAM, that can be augmented for different technologies. #2 and #3 are application of the concept to NVO3 and TRILL,

=  

=  

= Please review and share your comments

=  

= Thanks

= Tissa

=  

=  


_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3

=  

 

--_000_B8F9A780D330094D99AF023C5877DABA8458DB1Dnkgeml501mbschi_-- From nobody Thu Jul 31 21:41:39 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB71C1A0252 for ; Thu, 31 Jul 2014 15:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnpMv-sGNnjF for ; Thu, 31 Jul 2014 15:53:10 -0700 (PDT) Received: from nm32-vm1.bullet.mail.bf1.yahoo.com (nm32-vm1.bullet.mail.bf1.yahoo.com [72.30.239.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB2021A02CF for ; Thu, 31 Jul 2014 15:53:07 -0700 (PDT) Received: from [98.139.215.143] by nm32.bullet.mail.bf1.yahoo.com with NNFMP; 31 Jul 2014 22:53:06 -0000 Received: from [98.139.212.242] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 31 Jul 2014 22:53:06 -0000 Received: from [127.0.0.1] by omp1051.mail.bf1.yahoo.com with NNFMP; 31 Jul 2014 22:53:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 879791.57621.bm@omp1051.mail.bf1.yahoo.com Received: (qmail 2918 invoked by uid 60001); 31 Jul 2014 22:53:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1406847186; bh=2H6dJ5BaLFvqE3inU22MBh6xOhrh7BYMts/VU8TaC8k=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=gDzR+nBlZ7Il2+twehv0B7qJq7Ha46ih5GWQwTWN5vi6EFMJzSke0dXC1KmMrFem+EEWCbT10vDyyIONhot9babqkD74bk9gtdXxoZj+AoaWFIUu1uHHbEsW9D1FZwnEOkC4wiY0z0y3oooj9PIfn37W3wfpmxB2mLnBvkSJuHs= X-YMail-OSG: Togtu6oVM1lk4cN7TJp.BXnI_ocJOxdRLOTlaB43553DjrE xepQsyqD9a.6g31SpuvgJDe9Vqyy3I2zAPciJqffONbV3eFBf9bar5G.bAhA Cy5CzfCT_WEusHxHmyM4U8iexcVFq_1j0hsQUzIMFI_.8ATCtV8IjvvZ7g1u 9Oj5S8S7H6gwWawv3UukzXLdDLrKSH85Gc4d5KukBvWV4u19VBT9zhJHqL29 hFQM3pnN69axRiFNySKp5mNn8FsZjYpp4gdiWpKv1uHvf_SiKqHei3deDqTs cMSRkJoS3Hvg2P2iYs6ijuC6NiX.CPf_M9dLyZHpS.vzTdzf9g98tpvOBeSn 0.CFosuqyHKTCSJE0bjB8Vm.nPAjG97Lxtgvon1p.H6WMO28Jj9KTNuVcUEl 5ThXHi0__J5.5zXUmUtmDeauSwdAG7fC0QwaVZBI9xXYzGrw6RWtXnEe_bbC q0_4dlTY38TenOKY5Gf4MOdngIIGCXgGsLJlyO2Jt2siZP.CjkC8Y0wqY04M bGjwrYelmRO7I0Pu.Zdq2ql04GsQGc_atEw_Q5u9kmVpzUALVQm6xYjRIA23 cWNY- Received: from [98.207.41.145] by web162805.mail.bf1.yahoo.com via HTTP; Thu, 31 Jul 2014 15:53:06 PDT X-Rocket-MIMEInfo: 002.001, R3JlZwoKWWVzIGl0IGlzLCBnZW5lcmljIFlBTkcgbW9kZWwgc3RldXAgdGhlIGJhc2UgZnJhbWV3b3JrLiBJdCBjYW4gYmUgZXh0ZW5kZWQgdG8gYWRkIHRvb2xzIGFzIHdlbGwgYXMgb3RoZXIgZWxlbWVudHMgYXMgd2VsbCB0ZWNobm9sb2d5IGRldmlhdGlvbnMuIEFsYXJtcyBldGMgZWl0aGVyIGJlIHBhcnQgb2YgdGhpcyBkb2N1bWVudCB3aWxsIGJlIGEgc2VwYXJhdGUgZG9jdW1lbnQgdGhhdCBzcGVjaWZpZXMgdGhlbS4gVGhhdCBpcyB0aGUgcmVhc29uIHdlIGhhdmUgZGVzaWduZWQgdGhlIG1vZGVsIGEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.198.689 References: Message-ID: <1406847186.16320.YahooMailNeo@web162805.mail.bf1.yahoo.com> Date: Thu, 31 Jul 2014 15:53:06 -0700 From: Tissa Senevirathne To: Greg Mirsky , "Tissa Senevirathne \(tsenevir\)" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1735733242-2146564396-1406847186=:16320" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/01AVFWUCwDXZhL1BRmNofb1KcEo X-Mailman-Approved-At: Thu, 31 Jul 2014 21:41:37 -0700 Cc: "l2vpn@ietf.org" , "opsawg@ietf.org" , "nvo3@ietf.org" , "netmod@ietf.org" , "trill@ietf.org" Subject: Re: [netmod] [nvo3] YANG models for OAM X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Tissa Senevirathne List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 22:53:12 -0000 --1735733242-2146564396-1406847186=:16320 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Greg=0A=0AYes it is, generic YANG model steup the base framework. It can be= extended to add tools as well as other elements as well technology deviati= ons. Alarms etc either be part of this document will be a separate document= that specifies them. That is the reason we have designed the model as modu= lar as possible and extensible as possible.=0A=0APlease let us know if any = of the parts are not extensible or not modular enough.=0A=0AThanks=0ATissa= =0A=0A=0AOn Thursday, July 31, 2014 3:17 PM, Greg Mirsky wrote:=0A =0A=0A=0AHi Tissa, authors, et. al,=0AI've read documents a= nd would like to clarify scope of these documents. OAM is not limited to pi= ng and traceroute functions. It even not limited to continuity check. And i= n connectionless networks there would not be connectivity verification. And= the performance measurement is the big part of OAM as well as protection c= oordination, defect alarms, and etc. Hence my question, is it in plans of t= he authors to address all of OAM in respective documents?=0A=0ARegards,=0AG= reg=0A=0A=0A=0A=0AOn Tue, Jun 10, 2014 at 12:03 PM, Tissa Senevirathne (tse= nevir) wrote:=0A=0AAll=0A>=A0=0A>We have published YAN= G model for OAM. #1 draft below place the generic framework for OAM, that c= an be augmented for different technologies. #2 and #3 are application of th= e concept to NVO3 and TRILL,=0A>=A0=0A>1.=A0=A0=A0=A0=A0 http://datatracker= .ietf.org/doc/draft-tissa-netmod-oam/=0A>2.=A0=A0=A0=A0=A0 http://datatrack= er.ietf.org/doc/draft-tissa-nvo3-yang-oam/=0A>3.=A0=A0=A0=A0=A0 http://data= tracker.ietf.org/doc/draft-tissa-trill-yang-oam/=0A>=A0=0A>Please review an= d share your comments=0A>=A0=0A>Thanks=0A>Tissa=0A>=A0=0A>=A0=0A>__________= _____________________________________=0A>nvo3 mailing list=0A>nvo3@ietf.org= =0A>https://www.ietf.org/mailman/listinfo/nvo3=0A>=0A> --1735733242-2146564396-1406847186=:16320 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Greg

Yes it is, generic YANG model steup the base framework. It c= an be extended to add tools as well as other elements as well technology de= viations. Alarms etc either be part of this document will be a separate doc= ument that specifies them. That is the reason we have designed the model as= modular as possible and extensible as possible.

Please let us know if any of the parts are not ext= ensible or not modular enough.

Thanks
Tissa


On Thursday, July 31, 2014 3:17 PM, Greg Mirsky <= gregimirsky@gmail.com> wrote:


Hi Tissa, authors, et. al,
I've read document= s and would like to clarify scope of these documents. OAM is not limited to= ping and traceroute functions. It even not limited to continuity check. An= d in connectionless networks there would not be connectivity verification. And the performance= measurement is the big part of OAM as well as protection coordination, def= ect alarms, and etc. Hence my question, is it in plans of the authors to ad= dress all of OAM in respective documents?
=0A
Regards,
Greg
=


On Tue, Jun 10, 2014 at 12:03 PM= , Tissa Senevirathne (tsenevir) <tsenevir@cisco.com> wrote:
=0A
=0A=0A=0A=0A= =0A=0A
=0A
=0A
All<= u>
=0A
 
=0A
We have published YANG = model for OAM. #1 draft below place the generic framework for OAM, that can= be augmented for different technologies. #2 and #3 are application of the = concept to NVO3 and TRILL,
=0A=0A
 
=0A=0A
2.     =0Ahttp://datatracker.ietf.org/doc= /draft-tissa-nvo3-yang-oam/
=0A
3.<= span style=3D"font:7.0pt;">     =0A<= u>http://datatracker.iet= f.org/doc/draft-tissa-trill-yang-oam/
=0A
 
=0A
Please review and share your comments=0A
 
=0AThanks
=0A
Tissa
=0A
 
=0A
 
=0A
=0A
=0A=0A
_______________________________________________
=0Anvo3 mailing list
=0Anvo3@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/nvo3
=0A


--1735733242-2146564396-1406847186=:16320-- From nobody Thu Jul 31 21:42:05 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC10B1A02E6; Thu, 31 Jul 2014 16:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F001upx_crwl; Thu, 31 Jul 2014 16:32:01 -0700 (PDT) Received: from fncnmp04.fnc.fujitsu.com (fncnmp04.fnc.fujitsu.com [168.127.0.57]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83D2C1A02F3; Thu, 31 Jul 2014 16:32:00 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.01,775,1400043600"; d="scan'208,217"; a="54299128" Received: from rchexhcp2.fnc.net.local ([168.127.134.76]) by fncnmp02.fnc.fujitsu.com with ESMTP/TLS/AES128-SHA; 31 Jul 2014 18:32:00 -0500 Received: from RCHEXMBP1.fnc.net.local ([169.254.2.63]) by RCHEXHCP2.fnc.net.local ([168.127.134.76]) with mapi id 14.03.0181.006; Thu, 31 Jul 2014 18:31:59 -0500 From: "O'Connor, Don" To: Tissa Senevirathne , Greg Mirsky , "Tissa Senevirathne (tsenevir)" Thread-Topic: [nvo3] YANG models for OAM Thread-Index: Ac+E3qlMyPi638vnRGmjYh75Wx+edAoWIbcAAAE6agAACU5iwA== Date: Thu, 31 Jul 2014 23:31:58 +0000 Message-ID: <7DFA7869D33BD44A9A84BA24AD75BDE6D9E4645D@RCHEXMBP1.fnc.net.local> References: <1406847186.16320.YahooMailNeo@web162805.mail.bf1.yahoo.com> In-Reply-To: <1406847186.16320.YahooMailNeo@web162805.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [168.127.136.253] x-tm-as-product-ver: SMEX-10.2.0.3176-7.500.1018-20852.003 x-tm-as-result: No--48.025700-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_7DFA7869D33BD44A9A84BA24AD75BDE6D9E4645DRCHEXMBP1fncnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/GBHLO4MnN_UA69GXaUjT741DrR0 X-Mailman-Approved-At: Thu, 31 Jul 2014 21:42:04 -0700 Cc: "l2vpn@ietf.org" , "opsawg@ietf.org" , "nvo3@ietf.org" , "netmod@ietf.org" , "trill@ietf.org" Subject: Re: [netmod] [nvo3] YANG models for OAM X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 23:32:04 -0000 --_000_7DFA7869D33BD44A9A84BA24AD75BDE6D9E4645DRCHEXMBP1fncnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tissa, Greg, all Metro Ethernet Forum has already standardized Yang Modules for Ethernet Ser= vice OAM Performance Monitoring and Fault Management. Please see MEF 38 and= 39 http://metroethernetforum.org/carrier-ethernet/technical-specifications Regards Don From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Tissa Senevirathne Sent: Thursday, July 31, 2014 5:53 PM To: Greg Mirsky; Tissa Senevirathne (tsenevir) Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@= ietf.org Subject: Re: [nvo3] YANG models for OAM Greg Yes it is, generic YANG model steup the base framework. It can be extended = to add tools as well as other elements as well technology deviations. Alarm= s etc either be part of this document will be a separate document that spec= ifies them. That is the reason we have designed the model as modular as pos= sible and extensible as possible. Please let us know if any of the parts are not extensible or not modular en= ough. Thanks Tissa On Thursday, July 31, 2014 3:17 PM, Greg Mirsky > wrote: Hi Tissa, authors, et. al, I've read documents and would like to clarify scope of these documents. OAM= is not limited to ping and traceroute functions. It even not limited to co= ntinuity check. And in connectionless networks there would not be connectiv= ity verification. And the performance measurement is the big part of OAM as= well as protection coordination, defect alarms, and etc. Hence my question= , is it in plans of the authors to address all of OAM in respective documen= ts? Regards, Greg On Tue, Jun 10, 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) > wrote: All We have published YANG model for OAM. #1 draft below place the generic fram= ework for OAM, that can be augmented for different technologies. #2 and #3 = are application of the concept to NVO3 and TRILL, 1. http://datatracker.ietf.org/doc/draft-tissa-netmod-oam/ 2. http://datatracker.ietf.org/doc/draft-tissa-nvo3-yang-oam/ 3. http://datatracker.ietf.org/doc/draft-tissa-trill-yang-oam/ Please review and share your comments Thanks Tissa _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 --_000_7DFA7869D33BD44A9A84BA24AD75BDE6D9E4645DRCHEXMBP1fncnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tissa, Greg, all=

 

Metro Ethernet Forum has al= ready standardized Yang Modules for Ethernet Service OAM Performance Monito= ring and Fault Management. Please see MEF 38 and 39

 

http://metroethern= etforum.org/carrier-ethernet/technical-specifications=

 

Regards

 

Don

 

From: L2vpn [m= ailto:l2vpn-bounces@ietf.org] On Behalf Of Tissa Senevirathne
Sent: Thursday, July 31, 2014 5:53 PM
To: Greg Mirsky; Tissa Senevirathne (tsenevir)
Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org;= trill@ietf.org
Subject: Re: [nvo3] YANG models for OAM

 

Greg=

 

Yes it is, generic YANG model steup the ba= se framework. It can be extended to add tools as well as other elements as = well technology deviations. Alarms etc either be part of this document will be a separate document that specifies them. That is the= reason we have designed the model as modular as possible and extensible as= possible.

 

Please let us know if any of the parts are= not extensible or not modular enough.

 

Thanks

Tissa

 

On= Thursday, July 31, 2014 3:17 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:<= /o:p>

 

Hi Tissa, autho= rs, et. al,

I've read documents and would like to clarify scope of these document= s. OAM is not limited to ping and traceroute functions. It even not limited to continuity check. And in connectionless networks there= would not be connectivity verification. And the performance measurement is= the big part of OAM as well as protection coordination, defect alarms, and= etc. Hence my question, is it in plans of the authors to address all of OAM in respective documents?

Regards,

Greg=

 

On Tue, Jun 10,= 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) <tsenevir@cisco.com> wrote:

All<= /span>

 

We have publish= ed YANG model for OAM. #1 draft below place the generic framework for OAM, = that can be augmented for different technologies. #2 and #3 are application of the concept to NVO3 and TRILL,

 

 

Please review a= nd share your comments

 

Thanks

Tissa

 

 


_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3

 

 

--_000_7DFA7869D33BD44A9A84BA24AD75BDE6D9E4645DRCHEXMBP1fncnet_-- From nobody Thu Jul 31 21:42:43 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6AE01A01E1; Thu, 31 Jul 2014 15:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twuKli6O3K7p; Thu, 31 Jul 2014 15:17:58 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF92E1A01D2; Thu, 31 Jul 2014 15:17:57 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id le20so5412078vcb.28 for ; Thu, 31 Jul 2014 15:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IR78cfynVZAXP+vHYRyIQ5elqW+9YwQC2wbK9LLFfKI=; b=nAZrVsFekhJLF74K3LBaneJTAVQOYGUthL5SAgjp6OsZ3/Fgtfq8wGMyyxNZSzNy+V vhBeVTup78KF3XqIW/C5qOh8BPnkMlRqWRTTDKcAxjJV1o2vfsNKBRJeRI1v6sC7mDY+ qgpZd4fy+06jjeEERo8bpdAplH4HcHA5igNgoQXR25vtuTAmFAN97HTIm5RmlEKM6t4t lsVJwspkxLJTuG2J3h/mLwlTM/CwQLkYLvkeR58zUyMhDs1leulnx/dAdRPtri5aGWqh 08p7Lr+q5Be1wlAgLEc/GISHgKY12Mml8O6fWB1k3DUqA3DdZkxyOqO4xJSbqkgD9bYL SXBA== MIME-Version: 1.0 X-Received: by 10.52.232.200 with SMTP id tq8mr1332451vdc.32.1406845076842; Thu, 31 Jul 2014 15:17:56 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Thu, 31 Jul 2014 15:17:56 -0700 (PDT) In-Reply-To: References: Date: Thu, 31 Jul 2014 15:17:56 -0700 Message-ID: From: Greg Mirsky To: "Tissa Senevirathne (tsenevir)" Content-Type: multipart/alternative; boundary=089e0122f5fa0f2f1a04ff84a517 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6LkGg_llZtl849HNjQ2g8r7EN4s X-Mailman-Approved-At: Thu, 31 Jul 2014 21:42:41 -0700 Cc: "l2vpn@ietf.org" , "opsawg@ietf.org" , "nvo3@ietf.org" , "netmod@ietf.org" , "trill@ietf.org" Subject: Re: [netmod] [nvo3] YANG models for OAM X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 22:18:02 -0000 --089e0122f5fa0f2f1a04ff84a517 Content-Type: text/plain; charset=UTF-8 Hi Tissa, authors, et. al, I've read documents and would like to clarify scope of these documents. OAM is not limited to ping and traceroute functions. It even not limited to continuity check. And in connectionless networks there would not be connectivity verification. And the performance measurement is the big part of OAM as well as protection coordination, defect alarms, and etc. Hence my question, is it in plans of the authors to address all of OAM in respective documents? Regards, Greg On Tue, Jun 10, 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) < tsenevir@cisco.com> wrote: > All > > > > We have published YANG model for OAM. #1 draft below place the generic > framework for OAM, that can be augmented for different technologies. #2 and > #3 are application of the concept to NVO3 and TRILL, > > > > 1. http://datatracker.ietf.org/doc/draft-tissa-netmod-oam/ > > 2. http://datatracker.ietf.org/doc/draft-tissa-nvo3-yang-oam/ > > 3. http://datatracker.ietf.org/doc/draft-tissa-trill-yang-oam/ > > > > Please review and share your comments > > > > Thanks > > Tissa > > > > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > --089e0122f5fa0f2f1a04ff84a517 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tissa, authors, et. al,
I'v= e read documents and would like to clarify scope of these documents. OAM is= not limited to ping and traceroute functions. It even not limited to conti= nuity check. And in connectionless networks there would not be connectivity= verification. And the performance measurement is the big part of OAM as we= ll as protection coordination, defect alarms, and etc. Hence my question, i= s it in plans of the authors to address all of OAM in respective documents?=

Regards,
Greg

On Tue, Jun 10, 2014 at 12:03 PM, Tissa Senevi= rathne (tsenevir) <tsenevir@cisco.com> wrote:

All

=C2=A0

We have published YANG model for OAM. #1 draft below= place the generic framework for OAM, that can be augmented for different t= echnologies. #2 and #3 are application of the concept to NVO3 and TRILL,=

=C2=A0

1.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://datatracker.ietf.org/doc/draft-tissa= -netmod-oam/

2.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://datatracker.ietf.org/doc/draft-ti= ssa-nvo3-yang-oam/

3.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://datatracker.ietf.org/doc/draft-t= issa-trill-yang-oam/

=C2=A0

Please review and share your comments<= /p>

=C2=A0

Thanks

Tissa

=C2=A0

=C2=A0


_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3


--089e0122f5fa0f2f1a04ff84a517-- From nobody Thu Jul 31 21:42:44 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7EA1A0301; Thu, 31 Jul 2014 16:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ae6ZX4jkrm7a; Thu, 31 Jul 2014 16:48:38 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69A051A0080; Thu, 31 Jul 2014 16:48:37 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id hy4so5583197vcb.13 for ; Thu, 31 Jul 2014 16:48:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sge4oNtRxrM8fZ+UfI5apucWM0vTaalAtmc/COBoa1k=; b=U5HLBDUknIvggfeW5Ff1XgKL3tsyanxURJ84l/E4SNdt5xscksiRIbAqrfc186l4PN 6FcJJtDek73yeXpwnWjmdAhcLOWr93dV9GxkK7h7/eW5cVAJiA7lJYrvCvymbW7u/K82 NLPal+hxgDyeSk1pjmigh9w7x95qW06u+T0URGbJzJi0c+AtLvI7z8KOVnjYGmVBGBqJ uYnsR5HBaNGp8VszbhkQjl1Rf9sj0df5sgJESMGUzJfus+EddKbTcrqbQMEJ1+bH5Ma6 5jJeXfRTRqvTJ/VFefYj3m/PJRSD6xLzHBI3mtXRaJdzr5B0bPpotlFyqtRRwTbeSzri S6hA== MIME-Version: 1.0 X-Received: by 10.52.232.200 with SMTP id tq8mr1747682vdc.32.1406850516525; Thu, 31 Jul 2014 16:48:36 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Thu, 31 Jul 2014 16:48:36 -0700 (PDT) In-Reply-To: <7DFA7869D33BD44A9A84BA24AD75BDE6D9E4645D@RCHEXMBP1.fnc.net.local> References: <1406847186.16320.YahooMailNeo@web162805.mail.bf1.yahoo.com> <7DFA7869D33BD44A9A84BA24AD75BDE6D9E4645D@RCHEXMBP1.fnc.net.local> Date: Thu, 31 Jul 2014 16:48:36 -0700 Message-ID: From: Greg Mirsky To: "O'Connor, Don" Content-Type: multipart/alternative; boundary=089e0122f5fa4a297104ff85e9c4 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-58oVIuKQOPciJ6h8weXiBVW7RI X-Mailman-Approved-At: Thu, 31 Jul 2014 21:42:41 -0700 Cc: "l2vpn@ietf.org" , "netmod@ietf.org" , "nvo3@ietf.org" , "trill@ietf.org" , Tissa Senevirathne , "opsawg@ietf.org" Subject: Re: [netmod] [nvo3] YANG models for OAM X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 23:48:40 -0000 --089e0122f5fa4a297104ff85e9c4 Content-Type: text/plain; charset=UTF-8 Hi Don, thank you for the reference. And I'd point that ITU SG15 is working on standardizing "generic protocol-neutral management information model" for transport network, including OAM. Hence my question, What is the scope of these documents? Regards, Greg On Thu, Jul 31, 2014 at 4:31 PM, O'Connor, Don wrote: > Tissa, Greg, all > > > > Metro Ethernet Forum has already standardized Yang Modules for Ethernet > Service OAM Performance Monitoring and Fault Management. Please see MEF 38 > and 39 > > > > http://metroethernetforum.org/carrier-ethernet/technical-specifications > > > > Regards > > > > Don > > > > *From:* L2vpn [mailto:l2vpn-bounces@ietf.org] *On Behalf Of *Tissa > Senevirathne > *Sent:* Thursday, July 31, 2014 5:53 PM > *To:* Greg Mirsky; Tissa Senevirathne (tsenevir) > > *Cc:* l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; > trill@ietf.org > *Subject:* Re: [nvo3] YANG models for OAM > > > > Greg > > > > Yes it is, generic YANG model steup the base framework. It can be extended > to add tools as well as other elements as well technology deviations. > Alarms etc either be part of this document will be a separate document that > specifies them. That is the reason we have designed the model as modular as > possible and extensible as possible. > > > > Please let us know if any of the parts are not extensible or not modular > enough. > > > > Thanks > > Tissa > > > > On Thursday, July 31, 2014 3:17 PM, Greg Mirsky > wrote: > > > > Hi Tissa, authors, et. al, > > I've read documents and would like to clarify scope of these documents. > OAM is not limited to ping and traceroute functions. It even not limited to > continuity check. And in connectionless networks there would not be > connectivity verification. And the performance measurement is the big part > of OAM as well as protection coordination, defect alarms, and etc. Hence my > question, is it in plans of the authors to address all of OAM in respective > documents? > > Regards, > > Greg > > > > On Tue, Jun 10, 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) < > tsenevir@cisco.com> wrote: > > All > > > > We have published YANG model for OAM. #1 draft below place the generic > framework for OAM, that can be augmented for different technologies. #2 and > #3 are application of the concept to NVO3 and TRILL, > > > > 1. http://datatracker.ietf.org/doc/draft-tissa-netmod-oam/ > > 2. http://datatracker.ietf.org/doc/draft-tissa-nvo3-yang-oam/ > > 3. http://datatracker.ietf.org/doc/draft-tissa-trill-yang-oam/ > > > > Please review and share your comments > > > > Thanks > > Tissa > > > > > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > --089e0122f5fa4a297104ff85e9c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Don,
thank you for the referenc= e. And I'd point that ITU SG15 is working on standardizing "generic protocol-neutral management informatio= n model" for transport network, including OAM. Hence my question, What= is the scope of these documents?

Regards,
Greg

On Thu, Jul 31, 2014 at 4:31 PM, O'Connor,= Don <don.oconnor@us.fujitsu.com> wrote:

Tissa, Greg, all<= /u>

=C2=A0=

Metro Ethernet Forum has al= ready standardized Yang Modules for Ethernet Service OAM Performance Monito= ring and Fault Management. Please see MEF 38 and 39

=C2=A0=

= http://metroethernetforum.org/carrier-ethernet/technical-specifications=

=C2=A0=

Regards

=C2=A0=

Don

=C2=A0=

From: L2vpn [m= ailto:l2vpn-bou= nces@ietf.org] On Behalf Of Tissa Senevirathne
Sent: Thursday, July 31, 2014 5:53 PM
To: Greg Mirsky; Tissa Senevirathne (tsenevir)


Cc: l2vpn@ietf.o= rg; opsawg@ietf.or= g; nvo3@ietf.org= ; netmod@ietf.org;= trill@ietf.org
Subject: Re: [nvo3] YANG models for OAM

=C2=A0

Greg<= /u>

=C2=A0

Yes it is, generic YANG model steup the ba= se framework. It can be extended to add tools as well as other elements as = well technology deviations. Alarms etc either be part of this document will be a separate document that specifies them. That is the= reason we have designed the model as modular as possible and extensible as= possible.

=C2=A0

Please let us know if any of the parts are= not extensible or not modular enough.

=C2=A0

Thanks

Tissa

=C2=A0

On= Thursday, July 31, 2014 3:17 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:

=C2=A0

Hi Tissa, autho= rs, et. al,

I've read documents and would like to clarify scope of these docu= ments. OAM is not limited to ping and traceroute functions. It even not limited to continuity check. And in connectionless networks there= would not be connectivity verification. And the performance measurement is= the big part of OAM as well as protection coordination, defect alarms, and= etc. Hence my question, is it in plans of the authors to address all of OAM in respective documents?=

Regards,=

Greg<= /u>

=C2=A0

On Tue, Jun 10,= 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) <tsenevir@cisco.com> wrote:<= u>

All

=C2=A0

We have publish= ed YANG model for OAM. #1 draft below place the generic framework for OAM, = that can be augmented for different technologies. #2 and #3 are application of the concept to NVO3 and TRILL,

=C2=A0

=C2=A0

Please review a= nd share your comments

=C2=A0

Thanks

Tissa=

=C2=A0

=C2=A0


_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3

=C2=A0

=C2=A0


--089e0122f5fa4a297104ff85e9c4-- From nobody Thu Jul 31 21:42:46 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9021A0358; Thu, 31 Jul 2014 18:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id loqNCqhYCug8; Thu, 31 Jul 2014 18:42:28 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 821701A035F; Thu, 31 Jul 2014 18:42:27 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hy4so5522852vcb.22 for ; Thu, 31 Jul 2014 18:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lRR2kV8rhMHbMTe93Q6AG6IuR2LmqzC8cOYPUx5AKQc=; b=hF/leVOF2JZIQz9gMQDIHAFVyXRlKsj7dtogxSaXiH8Vl1aOChuRBvThe5DQWutmpW xysigIINz547WS0FDfwOnBgetYTPiwJMO4QagpFKmusDHz1GIBflOqsN1eex9pg6yk8P +Y905XCt3bP8tjo3parBP/WUxQ3sSgt/7u2cSvpV9cdwY2lyClxGgVJipM4UV6RU7hFY h+GflgNnYPdst5l6YmCIwqh3k2xJepj5jMMl7dmHNYm4trwxHNcAg8YxpOlv73LUO4Xy G0j8Tpb0M/F99u6Tp+VCHRWoGdOAKmWd14Y6Egp4EOigi98izBScmb9fuLYjvR27Bq/5 zCcA== MIME-Version: 1.0 X-Received: by 10.220.116.196 with SMTP id n4mr2752633vcq.6.1406857346700; Thu, 31 Jul 2014 18:42:26 -0700 (PDT) Received: by 10.220.15.136 with HTTP; Thu, 31 Jul 2014 18:42:26 -0700 (PDT) In-Reply-To: <1406847186.16320.YahooMailNeo@web162805.mail.bf1.yahoo.com> References: <1406847186.16320.YahooMailNeo@web162805.mail.bf1.yahoo.com> Date: Thu, 31 Jul 2014 18:42:26 -0700 Message-ID: From: Greg Mirsky To: Tissa Senevirathne Content-Type: multipart/alternative; boundary=047d7b34354c665c7504ff87809e Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Wsx1rqUqD4IPOPReXhymtNEaHGg X-Mailman-Approved-At: Thu, 31 Jul 2014 21:42:41 -0700 Cc: "l2vpn@ietf.org" , "netmod@ietf.org" , "nvo3@ietf.org" , "trill@ietf.org" , "opsawg@ietf.org" Subject: Re: [netmod] [nvo3] YANG models for OAM X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 01:42:30 -0000 --047d7b34354c665c7504ff87809e Content-Type: text/plain; charset=UTF-8 Hi Tissa, I feel that clear definition of the scope of work is important. From reading the documents, my impression, is that on-demand OAM tools that support detection and localization of Loss of Continuity defect are in scope while the rest of OAM is for further study. I think that it would benefit the documents and discussion if scope be firmly set. Regards, Greg On Thu, Jul 31, 2014 at 3:53 PM, Tissa Senevirathne < tissasenevirathne@yahoo.com> wrote: > Greg > > Yes it is, generic YANG model steup the base framework. It can be extended > to add tools as well as other elements as well technology deviations. > Alarms etc either be part of this document will be a separate document that > specifies them. That is the reason we have designed the model as modular as > possible and extensible as possible. > > Please let us know if any of the parts are not extensible or not modular > enough. > > Thanks > Tissa > > > On Thursday, July 31, 2014 3:17 PM, Greg Mirsky > wrote: > > > Hi Tissa, authors, et. al, > I've read documents and would like to clarify scope of these documents. > OAM is not limited to ping and traceroute functions. It even not limited to > continuity check. And in connectionless networks there would not be > connectivity verification. And the performance measurement is the big part > of OAM as well as protection coordination, defect alarms, and etc. Hence my > question, is it in plans of the authors to address all of OAM in respective > documents? > > Regards, > Greg > > > On Tue, Jun 10, 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) < > tsenevir@cisco.com> wrote: > > All > > We have published YANG model for OAM. #1 draft below place the generic > framework for OAM, that can be augmented for different technologies. #2 and > #3 are application of the concept to NVO3 and TRILL, > > 1. http://datatracker.ietf.org/doc/draft-tissa-netmod-oam/ > 2. http://datatracker.ietf.org/doc/draft-tissa-nvo3-yang-oam/ > 3. http://datatracker.ietf.org/doc/draft-tissa-trill-yang-oam/ > > Please review and share your comments > > Thanks > Tissa > > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > --047d7b34354c665c7504ff87809e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tissa,
I feel that clear defini= tion of the scope of work is important. From reading the documents, my impr= ession, is that on-demand OAM tools that support detection and localization= of Loss of Continuity defect are in scope while the rest of OAM is for fur= ther study. I think that it would benefit the documents and discussion if s= cope be firmly set.

Regards,
Greg

On Thu, Jul 31, 2014 at 3:53 PM, Tissa Senevir= athne <tissasenevirathne@yahoo.com> wrote:
Greg

= Yes it is, generic YANG model steup the base framework. It can be extended = to add tools as well as other elements as well technology deviations. Alarm= s etc either be part of this document will be a separate document that spec= ifies them. That is the reason we have designed the model as modular as pos= sible and extensible as possible.

Please let us know if any of the parts are not extensible or not modular en= ough.

Thanks
Tissa


On Thursday, July 31, 2014 3:17 PM, Greg Mirsky <= ;gregimirsky@gma= il.com> wrote:


Hi= Tissa, authors, et. al,
I've read documents an= d would like to clarify scope of these documents. OAM is not limited to pin= g and traceroute functions. It even not limited to continuity check. And in= connectionless networks there would not be connectivity verification. And the performance= measurement is the big part of OAM as well as protection coordination, def= ect alarms, and etc. Hence my question, is it in plans of the authors to ad= dress all of OAM in respective documents?

Regards,
Greg


On Tue, Jun 10,= 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) <tsenevir@cisco.com> wrote:
All
=C2=A0
We have published YANG model for OAM. #1 draft below place the generic= framework for OAM, that can be augmented for different technologies. #2 an= d #3 are application of the concept to NVO3 and TRILL,
=C2=A0
3.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 http://= datatracker.ietf.org/doc/draft-tissa-trill-yang-oam/
=C2=A0
Please review and share your comments
=C2=A0
Thanks
=
Tissa
=C2=A0
=C2=A0

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3


=

=

--047d7b34354c665c7504ff87809e--