From nobody Wed Aug 10 16:24:22 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCE912D1A3 for ; Wed, 10 Aug 2016 16:24:20 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 uUa_RsMz4REb for ; Wed, 10 Aug 2016 16:24:19 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E9C012D0DF for ; Wed, 10 Aug 2016 16:24:19 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id 97so94706889uav.3 for ; Wed, 10 Aug 2016 16:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=t7MZvweGDnvPulBMHT4eTPOvs/AE0+WZDL88u0AZrGA=; b=YoBLunDnIXKy8w2YAVctBYYv7s7RoVW21JNva5fHcmPc6rheb1w6GVSl6S6zP95GAF qeUISnp/AIM2SiedhgYEEz85N47HrB8JSncC7yXE7QP3eolxfP0iUS35KwXYUZ87uasG aMl2yF5cCyz6cJERG8fkdEdj2Hlp+OnZS0bWZRJc9hEKeK0wJa9i2/9pThV3rSp2F+kh UuvEaDHtJ9yAgGOxyzDNCZIAOmaVMvAx56gcB1UweOY9OmVJ7rvPqF5mGFvcPDlLtGkt TRBOPjT//Y4yHtSd+Gg+LHy1mlUGbhh+Od+CohKTtzf/73tMVRdtU/lA6Qm6QPah4Vy2 dIMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=t7MZvweGDnvPulBMHT4eTPOvs/AE0+WZDL88u0AZrGA=; b=M6s7XRU9Hh0NE9mPcj89EB0sbYb00OSEDi3cUk77r5Kl+I9JJU1ZTnxoIDD3/nJPUe /7mrpGlN4BtI2L0vv3AZghAMvSp/CnW4FJWCTfw5N9r6KxgeqfFauNVgVr8czWvRRp9C W874i+YIvfZP52B4F1/UV50t4J+s+VGvTqDEl7XV//Ayi0VJ/MQy8JUCwasNDlSxDq36 OlgTCDExZOdrhnmsLRfX/irORvoZmpE6Xn0g1IbEWWhgw6va0sDr2XGYxlm0XwqTQUNd rIUXZvuqwuxqsZnggdP9ZWTzjxt3m2mkXk9Lbp1vVnkKrSWVdArLc7/RUZzi8wVpEHZr mw7A== X-Gm-Message-State: AEkoouuADWGnyi0kkJJOjeJvBGQ9jDjwHXpTRfPaRd4MnxVkqPPuhAr9QIx1byB0bA3oVZA0tyx7poVpbkPv/g== X-Received: by 10.159.40.167 with SMTP id d36mr3324280uad.55.1470871457930; Wed, 10 Aug 2016 16:24:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.198 with HTTP; Wed, 10 Aug 2016 16:24:17 -0700 (PDT) From: Andy Bierman Date: Wed, 10 Aug 2016 16:24:17 -0700 Message-ID: To: YANG Doctors Content-Type: multipart/alternative; boundary=94eb2c123794c2b6e50539bff2ce Archived-At: Subject: [yang-doctors] security boilerplate for RESTCONF X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 23:24:20 -0000 --94eb2c123794c2b6e50539bff2ce Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, The boilerplate for YANG modules SC section is for NETCONF only: 12. Security Considerations The "ietf-restconf-monitoring" YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF users to a pre- configured subset of all available NETCONF protocol operations and content. It does seem odd that the RESTCONF SC section talks about NETCONF and not RESTCONF Dale suggested this text for RESTCONF: The lowest RESTCONF layer is HTTPS, and the mandatory =C2=ADto =C2=ADimp= lement secure transport is TLS [RFC5246]. The RESTCONF protocol uses the NETCONF access control model [RFC6536], which provides the means to restrict access for particular RESTCONF users to a pre-configured subset of all available RESTCONF protocol operations and content. Any suggestions for new SC template text so NETCONF and RESTCONF are both covered? Andy --94eb2c123794c2b6e50539bff2ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The boilerplate for YANG modules SC= section is for NETCONF only:

12.=C2=A0 Secur= ity Considerations

=C2=A0 =C2=A0The "ietf-res= tconf-monitoring" YANG module defined in this memo is
=C2=A0= =C2=A0designed to be accessed via the NETCONF protocol [RFC6241].=C2=A0 Th= e
=C2=A0 =C2=A0lowest NETCONF layer is the secure transport layer= , and the
=C2=A0 =C2=A0mandatory-to-implement secure transport is= Secure Shell (SSH)
=C2=A0 =C2=A0[RFC6242].=C2=A0 The NETCONF acc= ess control model [RFC6536] provides the
=C2=A0 =C2=A0means to re= strict access for particular NETCONF users to a pre-
=C2=A0 =C2= =A0configured subset of all available NETCONF protocol operations and
=
=C2=A0 =C2=A0content.


It= does seem odd that the RESTCONF SC section talks about NETCONF
a= nd not RESTCONF


Dale suggested this= text for RESTCONF:

=C2=A0 =C2=A0The lowest R= ESTCONF layer is HTTPS, and the mandatory =C2=ADto =C2=ADimplement=C2=A0
=C2=A0 =C2=A0secure transport is TLS [RFC5246].=C2=A0 The RESTCONF = protocol uses the=C2=A0
=C2=A0 =C2=A0NETCONF access control model= [RFC6536], which provides the means to=C2=A0
=C2=A0 =C2=A0restri= ct access for particular RESTCONF users to a pre-configured=C2=A0
=C2=A0 =C2=A0subset of all available RESTCONF protocol operations and cont= ent.=C2=A0


Any suggestions fo= r new SC template text so NETCONF and RESTCONF are
both covered?<= /div>


Andy

--94eb2c123794c2b6e50539bff2ce-- From nobody Wed Aug 10 17:07:52 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642E612D130 for ; Wed, 10 Aug 2016 17:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 LXESL4vL2gKE for ; Wed, 10 Aug 2016 17:07:50 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1160E12B031 for ; Wed, 10 Aug 2016 17:07:50 -0700 (PDT) Received: by mail-pa0-x234.google.com with SMTP id fi15so20219390pac.1 for ; Wed, 10 Aug 2016 17:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MPfISDf2EoiXFWjiMvWUHqEdLET6fmkSUrhDR9Jl0q8=; b=tMiKIVu9g+yHKMRlO7cs2uFQluWXlA48kUf8nqzOHeosxaLTywT/XhFjjnvAZjJ8nq ZMGapfm+mPVZSt/fRcuNGGRuihtyqcIXy1XcVeLDcSQYfQx4DPCY2bBcplIbuxx6ZaJC /6V0smFt3rHbZH+DMR4ii9qtdXwGviczcJz//dzgZJrZQa+XKCvHROyT39bb24iQgUdp aSbKhUpFSk9WXyRerF9SPEQB7b6maPDzYIzKDRD7C5lGPYgFxSpyt7ARSxmyGsA/4nJB uAL2ceMz/0KVAXxrFiUZGt1DcDPyb33/PIwa4ZIuCLotsZbDn/KZbV3GZgzcjUyDX1Of tr9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MPfISDf2EoiXFWjiMvWUHqEdLET6fmkSUrhDR9Jl0q8=; b=j52HV2mGHwjRwtbWwggkMV3qeo1eDPonYvaLD/g3L1pxa+/piDTxJ0OGo1LzBAVVxL T7gyIAssoc/9+La65c7YMNRkYBf2pDV0F5qYy8lizGvdfeLRyKsrHKr7hnIXhksiURH5 zJTxIBSsaEM6v3ntybOfBFxlIaD7o+V0qKLLkCwMsTyOcHqSXfodMBPXMXkIaD3VieRe eHPGzbuZfyGpJUYZ+I/sw9l7ZuGgIQoO+n7til3//RQ3utFLRwKJ7DMjCyaxyNvxQ9ap +FD/ElEIKbn/Vzqu5d5DdoL35JTrvYYAG3mm0hWjA1KjBF5Zs2nwvTZrUwBFjjq6BwMu xRnw== X-Gm-Message-State: AEkoouteKQuebeBkm+gRawJuqhdo1wCxGLfRhF3InhDcIRsBJM8Gn8/CBb4meKb31VzT+w== X-Received: by 10.66.234.161 with SMTP id uf1mr11678197pac.93.1470874069558; Wed, 10 Aug 2016 17:07:49 -0700 (PDT) Received: from ?IPv6:2001:420:30d:1320:9981:20cd:7de4:9465? ([2001:420:30d:1320:9981:20cd:7de4:9465]) by smtp.gmail.com with ESMTPSA id c8sm66632652pfe.39.2016.08.10.17.07.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 10 Aug 2016 17:07:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: Date: Wed, 10 Aug 2016 17:07:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andy Bierman X-Mailer: Apple Mail (2.3124) Archived-At: Cc: YANG Doctors Subject: Re: [yang-doctors] security boilerplate for RESTCONF X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 00:07:51 -0000 Andy, > On Aug 10, 2016, at 4:24 PM, Andy Bierman wrote: >=20 > Hi, >=20 > The boilerplate for YANG modules SC section is for NETCONF only: >=20 > 12. Security Considerations >=20 > The "ietf-restconf-monitoring" YANG module defined in this memo is > designed to be accessed via the NETCONF protocol [RFC6241]. The > lowest NETCONF layer is the secure transport layer, and the > mandatory-to-implement secure transport is Secure Shell (SSH) > [RFC6242]. The NETCONF access control model [RFC6536] provides the > means to restrict access for particular NETCONF users to a pre- > configured subset of all available NETCONF protocol operations and > content. >=20 >=20 > It does seem odd that the RESTCONF SC section talks about NETCONF > and not RESTCONF >=20 >=20 > Dale suggested this text for RESTCONF: >=20 > The lowest RESTCONF layer is HTTPS, and the mandatory =C2=ADto = =C2=ADimplement=20 > secure transport is TLS [RFC5246]. The RESTCONF protocol uses the=20= > NETCONF access control model [RFC6536], which provides the means to=20= > restrict access for particular RESTCONF users to a pre-configured=20= > subset of all available RESTCONF protocol operations and content.=20= s/mandatory to implement/mandatory-to-implement/ >=20 >=20 > Any suggestions for new SC template text so NETCONF and RESTCONF are > both covered? Isn't this for RESTCONF draft? >=20 >=20 > Andy >=20 > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors Mahesh Jethanandani mjethanandani@gmail.com From nobody Wed Aug 10 17:12:02 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B910612D180 for ; Wed, 10 Aug 2016 17:11: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 Dvj6ORFSxYkB for ; Wed, 10 Aug 2016 17:11:58 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0330912D130 for ; Wed, 10 Aug 2016 17:11:58 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id 74so96158003uau.0 for ; Wed, 10 Aug 2016 17:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iYU/PkVWtznZtfK20PLEzEuujBy5fLSPTLB5eYs08jI=; b=OJHtR+pQRTFq8tPc92MRCDN1CHumRH/zJ3iKJ8NsyIhr1uixcPpa0tvxVOgvb8yHH6 UeAwxTwk1Veec3+J5rohAn/YeOMn3JVKexwVxonj+m1HEF72s4p148uSIqANg6ZqoXQq 1/9VL7Ig0iEGsdgjom9L0bQzb/4e9S7jwLzpRvgcM4fLHkR8uJ9COfm+0MYdg6iZmYBo viQE6UlwGgfM8QbeOLKeL/Zj6dGeUu6A3JtAwiikYncZj3NOJu4BRJfx/XhYTe4LSc3l nQzzVJmW3r1tnCJF7jX0Kxn7tWeTEHn7FkSm5PWj6ydYSX3x5PnV04I9BdGHWY7po+wt NPgg== 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:from:date :message-id:subject:to:cc; bh=iYU/PkVWtznZtfK20PLEzEuujBy5fLSPTLB5eYs08jI=; b=hCUIoA8gaJPvG3DrnE414JtkwtFZu7lWjyNpEVprzzDsrt8gD49iF8LQD6wBL4GHsy UlLjSCpJCjKiiNrum7SWeORT7EugbTshoOYrzWTSmYiZgbXDdrnyQi9uaneMJ4AyEXYw 3tfOKLAGU8FA9MVsY19YsPO9qP3ulVlte9WYZz7VLy9hoixg75rS5tfVs1cFzuBn3JpD 36tc5ZqaWKHgQ+DdwtgfOj+yWmhFI7PfEgr3WkKsdbDQ0O/UX3A/qWko2w+EvSwGJlMS B9Lu9NVYtdlz/s4A/GKysWMZFYWJd2VhuMw94eRIZY79R1xJXbbZJqHHn1IpTmpM/KGK oKsg== X-Gm-Message-State: AEkoouvQLRw1t67znDb22iNRZiZPKSnDXEzYcDAjbriagITXvJSfdmlujy9lTbQ/EApe7ACXe1PHAHZrf23Lag== X-Received: by 10.176.80.47 with SMTP id b44mr3375901uaa.135.1470874316979; Wed, 10 Aug 2016 17:11:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.198 with HTTP; Wed, 10 Aug 2016 17:11:56 -0700 (PDT) In-Reply-To: References: From: Andy Bierman Date: Wed, 10 Aug 2016 17:11:56 -0700 Message-ID: To: Mahesh Jethanandani Content-Type: multipart/alternative; boundary=94eb2c18f30a2c656b0539c09d7c Archived-At: Cc: YANG Doctors Subject: Re: [yang-doctors] security boilerplate for RESTCONF X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 00:12:00 -0000 --94eb2c18f30a2c656b0539c09d7c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 10, 2016 at 5:07 PM, Mahesh Jethanandani < mjethanandani@gmail.com> wrote: > Andy, > > > On Aug 10, 2016, at 4:24 PM, Andy Bierman wrote: > > > > Hi, > > > > The boilerplate for YANG modules SC section is for NETCONF only: > > > > 12. Security Considerations > > > > The "ietf-restconf-monitoring" YANG module defined in this memo is > > designed to be accessed via the NETCONF protocol [RFC6241]. The > > lowest NETCONF layer is the secure transport layer, and the > > mandatory-to-implement secure transport is Secure Shell (SSH) > > [RFC6242]. The NETCONF access control model [RFC6536] provides the > > means to restrict access for particular NETCONF users to a pre- > > configured subset of all available NETCONF protocol operations and > > content. > > > > > > It does seem odd that the RESTCONF SC section talks about NETCONF > > and not RESTCONF > > > > > > Dale suggested this text for RESTCONF: > > > > The lowest RESTCONF layer is HTTPS, and the mandatory =C2=ADto =C2= =ADimplement > > secure transport is TLS [RFC5246]. The RESTCONF protocol uses the > > NETCONF access control model [RFC6536], which provides the means to > > restrict access for particular RESTCONF users to a pre-configured > > subset of all available RESTCONF protocol operations and content. > > s/mandatory to implement/mandatory-to-implement/ > > cut-and-paste changed that. It was correct in Dale's comments > > > > > > Any suggestions for new SC template text so NETCONF and RESTCONF are > > both covered? > > Isn't this for RESTCONF draft? > > Well once RESTCONF is published then presumably each YANG module (like ietf-routing) needs boilerplate text https://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines This is the text that needs updating when RESTCONF is published. > > > > > > Andy > > > Andy > > _______________________________________________ > > yang-doctors mailing list > > yang-doctors@ietf.org > > https://www.ietf.org/mailman/listinfo/yang-doctors > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > --94eb2c18f30a2c656b0539c09d7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 10, 2016 at 5:07 PM, Mahesh Jethanandani = <mjethanand= ani@gmail.com> wrote:
Andy,

> On Aug 10, 2016, at 4:24 PM, Andy Bierman <andy@yumaworks.com> wrote:
>
> Hi,
>
> The boilerplate for YANG modules SC section is for NETCONF only:
>
> 12.=C2=A0 Security Considerations
>
>=C2=A0 =C2=A0 The "ietf-restconf-monitoring" YANG module defi= ned in this memo is
>=C2=A0 =C2=A0 designed to be accessed via the NETCONF protocol [RFC6241= ].=C2=A0 The
>=C2=A0 =C2=A0 lowest NETCONF layer is the secure transport layer, and t= he
>=C2=A0 =C2=A0 mandatory-to-implement secure transport is Secure Shell (= SSH)
>=C2=A0 =C2=A0 [RFC6242].=C2=A0 The NETCONF access control model [RFC653= 6] provides the
>=C2=A0 =C2=A0 means to restrict access for particular NETCONF users to = a pre-
>=C2=A0 =C2=A0 configured subset of all available NETCONF protocol opera= tions and
>=C2=A0 =C2=A0 content.
>
>
> It does seem odd that the RESTCONF SC section talks about NETCONF
> and not RESTCONF
>
>
> Dale suggested this text for RESTCONF:
>
>=C2=A0 =C2=A0 The lowest RESTCONF layer is HTTPS, and the mandatory =C2= =ADto =C2=ADimplement
>=C2=A0 =C2=A0 secure transport is TLS [RFC5246].=C2=A0 The RESTCONF pro= tocol uses the
>=C2=A0 =C2=A0 NETCONF access control model [RFC6536], which provides th= e means to
>=C2=A0 =C2=A0 restrict access for particular RESTCONF users to a pre-co= nfigured
>=C2=A0 =C2=A0 subset of all available RESTCONF protocol operations and = content.

s/mandatory to implement/mandatory-to-implement/


cut-and-paste changed that.=C2=A0 It w= as correct in Dale's comments

=C2=A0
>
>
> Any suggestions for new SC template text so NETCONF and RESTCONF are > both covered?

Isn't this for RESTCONF draft?



Well once RESTCONF is p= ublished then presumably each YANG module
(like ietf-routing) nee= ds boilerplate text


=

This is the text that needs updating when RESTCONF is p= ublished.

=C2=A0
>
>
> Andy
>


Andy
=C2= =A0
> _______________________________________________
> yang-doctors mailing list
> yang-doctors@ietf.org
> https://www.ietf.org/mailman/listinfo/ya= ng-doctors

Mahesh Jethanandani
mjethanandani@gmail.com




--94eb2c18f30a2c656b0539c09d7c-- From nobody Wed Aug 10 18:02:33 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B31612D6B8 for ; Wed, 10 Aug 2016 18:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 610K07wxElYZ for ; Wed, 10 Aug 2016 18:02:29 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1344F12D519 for ; Wed, 10 Aug 2016 18:02:29 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id x72so20937024pfd.2 for ; Wed, 10 Aug 2016 18:02:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=iJjfNKk7Gy/zNiPuDoPAoak3QG9R68hzkzQ3rIQPQ8U=; b=UXqzqE5fXAYOswQ9dI0128tUcOzUkS9ValIpr5BF2YkLIMfchFAUQ+wrcU85/wpMsi LOYzXT1sEwceQUCqJe4+k+t9jouUtSllgVbovy/XriIJ3UMHpPLBaFPfNmmYNTgjNX4k cfq3w9EugFxq+vplkZ3gEmjbWqnHsPfRIBJLrssOZq1uqiyzg7hflEJjvZmHn2DPnf09 llZHRjAGVnCyEmGgISZ+lhUJMuSjLuOILXTOac2lVmZ2dBLmUQk1buPRVddebqVdPcID GZHVU6SfgxeUR7ZlxUUKh4V1OoA2j2UCzvz7mJ4kcAFazgWuxywytqTA/p8hCl54hKOH jFyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=iJjfNKk7Gy/zNiPuDoPAoak3QG9R68hzkzQ3rIQPQ8U=; b=UDiI3BXr5RyQbac7rKr3bp/CGg9YM+XMGAhPbvDI6NfgPSLxIcSs+Ao2XPpzbTfiSx rL/WUOx+S1Fygd6Q9h5NKuokCXXI3QkfRgKc/AaK3JvwDXh6rQbmzX/CyfuAmqiFEroC C/2ngaysAY/4k9lh1LF6OYYRZ2vERYOCX+R3/LcC+mYJBxXeAZuPY+ZqLUsbWYtdPE9Z 51JAmo8PaDCJEQYMfYJ9i/YfKTXjtnwhP5IQ03OSWmwmKdtnWb4zse0sKzXLet3fzuZ8 UgjrQmwt7mKZaF9w69deP/DjlRzjmsZe/rcPBNo2JiQnNdD3dYnM7AYXJnCVoez3cCra 1uVQ== X-Gm-Message-State: AEkoouuNeY8x+Mzj+IvLlAJwx8IkOb5yB/APkKVoJotZiM5+ng5GxOlpRTtghnBTtvO94Q== X-Received: by 10.98.74.201 with SMTP id c70mr12109412pfj.113.1470877348640; Wed, 10 Aug 2016 18:02:28 -0700 (PDT) Received: from dhcp-128-107-151-62.cisco.com (dhcp-128-107-151-62.cisco.com. [128.107.151.62]) by smtp.gmail.com with ESMTPSA id 71sm103037pfy.32.2016.08.10.18.02.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 10 Aug 2016 18:02:27 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_8780E048-9E94-4E87-ABAA-89BDB31D5F25" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: Date: Wed, 10 Aug 2016 18:02:27 -0700 Message-Id: <3FFA5B7E-4D9D-40CA-A392-696847C2099C@gmail.com> References: To: Andy Bierman X-Mailer: Apple Mail (2.3124) Archived-At: Cc: YANG Doctors Subject: Re: [yang-doctors] security boilerplate for RESTCONF X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 01:02:31 -0000 --Apple-Mail=_8780E048-9E94-4E87-ABAA-89BDB31D5F25 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 10, 2016, at 5:11 PM, Andy Bierman wrote: >=20 >=20 >=20 > On Wed, Aug 10, 2016 at 5:07 PM, Mahesh Jethanandani = > wrote: > Andy, >=20 > > On Aug 10, 2016, at 4:24 PM, Andy Bierman > wrote: > > > > Hi, > > > > The boilerplate for YANG modules SC section is for NETCONF only: > > > > 12. Security Considerations > > > > The "ietf-restconf-monitoring" YANG module defined in this memo = is > > designed to be accessed via the NETCONF protocol [RFC6241]. The > > lowest NETCONF layer is the secure transport layer, and the > > mandatory-to-implement secure transport is Secure Shell (SSH) > > [RFC6242]. The NETCONF access control model [RFC6536] provides = the > > means to restrict access for particular NETCONF users to a pre- > > configured subset of all available NETCONF protocol operations = and > > content. > > > > > > It does seem odd that the RESTCONF SC section talks about NETCONF > > and not RESTCONF > > > > > > Dale suggested this text for RESTCONF: > > > > The lowest RESTCONF layer is HTTPS, and the mandatory =C2=ADto = =C2=ADimplement > > secure transport is TLS [RFC5246]. The RESTCONF protocol uses = the > > NETCONF access control model [RFC6536], which provides the means = to > > restrict access for particular RESTCONF users to a pre-configured > > subset of all available RESTCONF protocol operations and content. >=20 > s/mandatory to implement/mandatory-to-implement/ >=20 >=20 > cut-and-paste changed that. It was correct in Dale's comments >=20 > =20 > > > > > > Any suggestions for new SC template text so NETCONF and RESTCONF are > > both covered? >=20 > Isn't this for RESTCONF draft? >=20 >=20 >=20 > Well once RESTCONF is published then presumably each YANG module > (like ietf-routing) needs boilerplate text >=20 > = https://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines = >=20 >=20 > This is the text that needs updating when RESTCONF is published. Ok. So there are two asks. One for RESTCONF which to me looks ok and one = for the boilerplate. How about this for the boilerplate? OLD The YANG module defined in this memo is designed to be accessed via the = NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure = transport layer, and the mandatory-to-implement secure transport is = Secure Shell (SSH) [RFC6242]. The NETCONF access control model [RFC6536] = provides the means to restrict access for particular NETCONF users to a = pre-configured subset of all available NETCONF protocol operations and = content. NEW The YANG module defined in this memo is designed to be accessed via the = NETCONF [RFC6241] or RESTCONF [RFCXXXX] protocol. The lowest NETCONF = layer is the secure transport layer, and mandatory-to-implement is = Secure Shell (SSH) [RFC6242], while the lowest RESTCONF layer is HTTP, = and the mandatory-to-implement secure transport is Transport Layer = Security (TLS) [RFC5246].=20 The NETCONF access control model [RFC6536] provides the means to = restrict access for particular NETCONF or RESTCONF users to a = pre-configured subset of all available NETCONF or RESTCONF protocol = operations and content. >=20 > =20 > > > > > > Andy > > >=20 >=20 > Andy > =20 > > _______________________________________________ > > yang-doctors mailing list > > yang-doctors@ietf.org > > https://www.ietf.org/mailman/listinfo/yang-doctors = >=20 > Mahesh Jethanandani > mjethanandani@gmail.com Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_8780E048-9E94-4E87-ABAA-89BDB31D5F25 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Aug 10, 2016, at 5:11 PM, Andy Bierman <andy@yumaworks.com> = wrote:



On = Wed, Aug 10, 2016 at 5:07 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
Andy,

> On Aug 10, 2016, at 4:24 PM, Andy Bierman = <andy@yumaworks.com> wrote:
>
> Hi,
>
> The = boilerplate for YANG modules SC section is for NETCONF only:
>
> 12.  Security Considerations
>
>    The = "ietf-restconf-monitoring" YANG module defined in this memo is
>    designed to be accessed via the NETCONF = protocol [RFC6241].  The
>    lowest = NETCONF layer is the secure transport layer, and the
>    mandatory-to-implement secure transport is = Secure Shell (SSH)
>    [RFC6242].  The = NETCONF access control model [RFC6536] provides the
>    means to restrict access for particular = NETCONF users to a pre-
>    configured = subset of all available NETCONF protocol operations and
>    content.
>
>
> It does seem odd that the RESTCONF SC = section talks about NETCONF
> and not RESTCONF
>
>
> Dale suggested = this text for RESTCONF:
>
>  =   The lowest RESTCONF layer is HTTPS, and the mandatory =C2=ADto = =C2=ADimplement
>    secure transport is TLS = [RFC5246].  The RESTCONF protocol uses the
>  =   NETCONF access control model [RFC6536], which provides the means = to
>    restrict access for particular = RESTCONF users to a pre-configured
>    = subset of all available RESTCONF protocol operations and content.

s/mandatory to implement/mandatory-to-implement/


cut-and-paste changed = that.  It was correct in Dale's comments

 
>
>
> Any suggestions for new SC template text so NETCONF and = RESTCONF are
> both covered?

Isn't this for RESTCONF draft?



Well once RESTCONF is = published then presumably each YANG module
(like = ietf-routing) needs boilerplate text

https://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-gu= idelines

This is the text that needs updating = when RESTCONF is published.

Ok. So there are two asks. One for RESTCONF which to me = looks ok and one for the boilerplate.

How about this for the boilerplate?

            = OLD

The YANG module defined in this memo is = designed to be accessed via the NETCONF protocol [RFC6241]. The lowest = NETCONF layer is the secure transport layer, and the = mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. = The NETCONF access control model [RFC6536] provides the means to = restrict access for particular NETCONF users to a pre-configured subset = of all available NETCONF protocol operations and content.

NEW

The YANG module defined in this memo is designed to be = accessed via the NETCONF [RFC6241] or RESTCONF [RFCXXXX] protocol. The = lowest NETCONF layer is the secure transport layer, and = mandatory-to-implement is Secure Shell (SSH) [RFC6242], while the lowest = RESTCONF layer is HTTP, and the mandatory-to-implement secure transport = is Transport Layer Security (TLS) [RFC5246]. 
The NETCONF = access control model [RFC6536] provides the means to restrict access for = particular NETCONF or RESTCONF users to a pre-configured subset of all = available NETCONF or RESTCONF protocol operations and = content.

 
>
>
> Andy
>


Andy
 
> = _______________________________________________
> yang-doctors mailing list
> yang-doctors@ietf.org
> https://www.ietf.org/mailman/listinfo/yang-doctors

Mahesh Jethanandani
mjethanandani@gmail.com

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_8780E048-9E94-4E87-ABAA-89BDB31D5F25-- From nobody Thu Aug 11 00:32:16 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0E612D0A2 for ; Thu, 11 Aug 2016 00:32:14 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbGz3uufrVls for ; Thu, 11 Aug 2016 00:32:13 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0455612D13B for ; Thu, 11 Aug 2016 00:32:10 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id D829A1CC02F0; Thu, 11 Aug 2016 09:32:23 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , YANG Doctors In-Reply-To: References: User-Agent: Notmuch/0.22.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 11 Aug 2016 09:32:09 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [yang-doctors] security boilerplate for RESTCONF X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 07:32:15 -0000 Andy Bierman writes: > Hi, > > The boilerplate for YANG modules SC section is for NETCONF only: > > 12. Security Considerations > > The "ietf-restconf-monitoring" YANG module defined in this memo is > designed to be accessed via the NETCONF protocol [RFC6241]. The > lowest NETCONF layer is the secure transport layer, and the > mandatory-to-implement secure transport is Secure Shell (SSH) > [RFC6242]. The NETCONF access control model [RFC6536] provides the > means to restrict access for particular NETCONF users to a pre- > configured subset of all available NETCONF protocol operations and > content. > > > It does seem odd that the RESTCONF SC section talks about NETCONF > and not RESTCONF > > > Dale suggested this text for RESTCONF: > > The lowest RESTCONF layer is HTTPS, and the mandatory =C2=ADto =C2=ADi= mplement > secure transport is TLS [RFC5246]. The RESTCONF protocol uses the > NETCONF access control model [RFC6536], which provides the means to > restrict access for particular RESTCONF users to a pre-configured > subset of all available RESTCONF protocol operations and content. > > > Any suggestions for new SC template text so NETCONF and RESTCONF are > both covered? I have this for the next revision of the routing draft: Configuration and state data conforming to the core routing data model (defined in this document) are designed to be accessed via a management protocol with secure transport layer, such as NETCONF [RFC6241]. The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF users to a pre- configured subset of all available NETCONF protocol operations and content. It would be great to have protocol-agnostic NACM. Lada > > > Andy > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Aug 11 09:37:22 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB73C12D7F9 for ; Thu, 11 Aug 2016 09:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 t2izCrpxkgFU for ; Thu, 11 Aug 2016 09:37:18 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D8B12D7C2 for ; Thu, 11 Aug 2016 09:37:18 -0700 (PDT) Received: by mail-pa0-x236.google.com with SMTP id ti13so243951pac.0 for ; Thu, 11 Aug 2016 09:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9vzS0fbJH66inOEJebLUgBbE9HGETz3GO5CDRL4WDGE=; b=s2CPzz09nmT/D8/no1DtkyIyT/UhE1n+/3Q6iQABZicRU+MfqRigMMQ5kh2CjoOBhE 52m+Yck58fxv5JqTPSvSbdrUqpDCvcR80cmTzDrOomO+92OlPxogFbwUTDDHOGnDP0xf qvxQ6zNMYdYTJs18XOtz3HfWaJ4EstQiirjm7fdi1yRqXNix7yeyK/mpe6B53ycrQObz p7oB7nQhoi1TGNx9c/uRRHexL/7s52QTqz856VbcyTwghPE9HEshC62HONa90jhQhiMJ WSRVU2Kangc3Y9180esYiS5whMV/0ibGMlUd+qqboMueGJ5h0Icc9fMISXYk7er+5YjK XSbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9vzS0fbJH66inOEJebLUgBbE9HGETz3GO5CDRL4WDGE=; b=Zj573xYwWPVCo189IchDS9YVAnAnqHaWiN49ExUL+RPpXdRvds7YIfKMCME98KmFNr GaPT4XJbnTVTXHAyRIOt5jU1ecKfyWitqlyrd8k/wq0hH9M4dVCzNTq0cNagcCNxU/4m P6XTUGsdcXchywqTYcE7DDxiUsv6SkO563G+HV9TTVIuLM7mmJtaiHXZL2RfYB5paMua 4V/1cjg6f8ZySNM1jpDpjnAFJSn5a2yw08tDDHqjNy26RlcM7GkM5d3R9sL+9GYqi6iK FwbUl5O9kV8wAkcwYw0j5+98Cs0cBqc6Fbr8wB7HoxpAOBg4Mt6rl5msK33KLhEdLu+X lf3g== X-Gm-Message-State: AEkoousSHQynjLp/jCOJ3EKHbqAUN+v3/6doCULqi3SkkyxkcL68XHASjZjB8Ju8PJxIFw== X-Received: by 10.66.100.230 with SMTP id fb6mr18562230pab.107.1470933437754; Thu, 11 Aug 2016 09:37:17 -0700 (PDT) Received: from sjc-mahesh-nitro6.cisco.com ([128.107.241.190]) by smtp.gmail.com with ESMTPSA id h66sm6549851pfe.58.2016.08.11.09.37.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 11 Aug 2016 09:37:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: Date: Thu, 11 Aug 2016 09:37:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9947A813-3E9E-4F59-9DDD-FC252E10161B@gmail.com> References: To: Ladislav Lhotka X-Mailer: Apple Mail (2.3124) Archived-At: Cc: YANG Doctors Subject: Re: [yang-doctors] security boilerplate for RESTCONF X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2016 16:37:20 -0000 > On Aug 11, 2016, at 12:32 AM, Ladislav Lhotka wrote: >=20 > Andy Bierman writes: >=20 >> Hi, >>=20 >> The boilerplate for YANG modules SC section is for NETCONF only: >>=20 >> 12. Security Considerations >>=20 >> The "ietf-restconf-monitoring" YANG module defined in this memo is >> designed to be accessed via the NETCONF protocol [RFC6241]. The >> lowest NETCONF layer is the secure transport layer, and the >> mandatory-to-implement secure transport is Secure Shell (SSH) >> [RFC6242]. The NETCONF access control model [RFC6536] provides the >> means to restrict access for particular NETCONF users to a pre- >> configured subset of all available NETCONF protocol operations and >> content. >>=20 >>=20 >> It does seem odd that the RESTCONF SC section talks about NETCONF >> and not RESTCONF >>=20 >>=20 >> Dale suggested this text for RESTCONF: >>=20 >> The lowest RESTCONF layer is HTTPS, and the mandatory =C2=ADto = =C2=ADimplement >> secure transport is TLS [RFC5246]. The RESTCONF protocol uses the >> NETCONF access control model [RFC6536], which provides the means to >> restrict access for particular RESTCONF users to a pre-configured >> subset of all available RESTCONF protocol operations and content. >>=20 >>=20 >> Any suggestions for new SC template text so NETCONF and RESTCONF are >> both covered? >=20 > I have this for the next revision of the routing draft: >=20 > Configuration and state data conforming to the core routing data > model (defined in this document) are designed to be accessed via a > management protocol with secure transport layer, such as NETCONF > [RFC6241]. The NETCONF access control model [RFC6536] provides the > means to restrict access for particular NETCONF users to a pre- > configured subset of all available NETCONF protocol operations and > content. >=20 > It would be great to have protocol-agnostic NACM. Could the last sentence be made protocol agnostic? Something like: The NETCONF access control model [RFC6536] provides the means to = restrict access to particular users to a preconfigured subset of all = available management protocol operations and content. >=20 > Lada >=20 >>=20 >>=20 >> Andy >> _______________________________________________ >> yang-doctors mailing list >> yang-doctors@ietf.org >> https://www.ietf.org/mailman/listinfo/yang-doctors >=20 > --=20 > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors From nobody Fri Aug 12 09:25:30 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F7C12D794 for ; Fri, 12 Aug 2016 09:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uSTGFArtCNc for ; Fri, 12 Aug 2016 09:25:28 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 C49C012D788 for ; Fri, 12 Aug 2016 09:25:27 -0700 (PDT) X-AuditID: c1b4fb3a-0618b980000009bd-bd-57adf875d538 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id EB.F6.02493.578FDA75; Fri, 12 Aug 2016 18:25:25 +0200 (CEST) Received: from [159.107.197.188] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.301.0; Fri, 12 Aug 2016 18:24:32 +0200 To: YANG Doctors , James Zhang Q , Ing-Wher Chen From: Balazs Lengyel Message-ID: <8de39d98-9b56-a517-c164-069493d12b39@ericsson.com> Date: Fri, 12 Aug 2016 18:24:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnluLIzCtJLcpLzFFi42KZGbFdUbf0x9pwg6MHbSz6dh1gdGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuo529kKvglVrD/ZxNrAuIKvi5GTQ0LARKKz6yVrFyMXh5DA ekaJCVveQjlrGSVu/bsL5ogINDFKbLk3ix2khU3ASGJq/3kWEFtYwELiwtSLrCA2r4C9xKuT z5lBbBYBVYnNWxezdTFycIgKxEis70uAKBGUODnzCVgrs4CGROucuewQtrxE89bZYK1CQPGH F/6yTmDknYWkZRaSlllIWhYwMq9iFC1OLS7OTTcy0kstykwuLs7P08tLLdnECAyeg1t+W+1g PPjc8RCjAAejEg+vwt414UKsiWXFlbmHGCU4mJVEeHd+WRsuxJuSWFmVWpQfX1Sak1p8iFGa g0VJnNf/pWK4kEB6YklqdmpqQWoRTJaJg1OqgZEr93LhnEvNvbv4w8o7A91CG2Y6dN54F35u b6GYTLbU5vqihT2KV4tnJUve+XY+RMXJ7bfRx4YTvOe2LdV5cn56Mvf97YlfvrXec2VSevjz 0gLtgNm3Vukfrd+58vKh0o3BlhGK7XsmNUp1RFh8f9d8MmVWc4zNxOTGOx0X98o0ns4Xu8ZV PU+JpTgj0VCLuag4EQD98rXZGgIAAA== Archived-At: Subject: [yang-doctors] Best way to use only part of iana-if-types.yang X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 16:25:29 -0000

Hello,

Our nodes support only some of the iana interface types. How do we indicate the correct subset. We want to create the subset on a model level and not just reject the unsupported values. The CLI is model driven and in the help it will offer  all  if-types, as indicated by the model, to the user. We cannot offer an interface type and later reject it.

- The best would be to have a deviation indicating no support for the identity. Sadly YANG does not allow that.

- We could put a "must" statement to check the identity value, but the CLI-help might not notice it
- we could create a fake iana-if-types.yang file that contains the if-types that we support, but that is ugly
- we could change the type of the identityref typed leaf by adding an additional base to it "supported-if-type" and add this base to all if-types in iana-if-types.yang that we do support. However this still leads to editing the iana-if-types.yang file.
- we could change the base of any referencing identityref to "my-supported-interface-types", but then the management system will not see this as a standard solution
- something else?


What is the preferred solution?

regards Balazs
 
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Fri Aug 12 10:03:46 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14BB12D16B for ; Fri, 12 Aug 2016 10:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 Z93JmubQSolG for ; Fri, 12 Aug 2016 10:03:42 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD1CC12D0FB for ; Fri, 12 Aug 2016 10:03:42 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id n59so51259970uan.2 for ; Fri, 12 Aug 2016 10:03:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EUWcNHdjpXRNn7JOrCiRDKwfWJc9gM4z/HCjluolaVw=; b=vu62qdmpSvEJ3B9+/hd4jrhAMg5A+QnwiumoHBrCdxJy+OyYld5hMnSb12VGG0wD4i BA6S4FVZ9H/Csdl9ao4Y4QAiDAvUzRT7j++rgVxn5x285FkfRXIn1dmh/NHq8HV7JMIp gS4IfQJQV1VAj6n71DCmRSAeNSZsptDJsZSvPjhkVUCohce8Dx0Nrn5DEUGGk7qmVyWA 2gfdLxTTPAvm4EckejrI+Us/GiJapGbM8UDf+1YToeKwdG/5H7s1skPkYwLdOzL0QRyh EruXVfD5Fh47xx22X9rUvJWxri3FiwBYS0DwnyB7xxb14vnCiCyQ+uZmKXYBHwROCU4B YFlg== 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:from:date :message-id:subject:to:cc; bh=EUWcNHdjpXRNn7JOrCiRDKwfWJc9gM4z/HCjluolaVw=; b=PiLcnsu8qMLRdjNZhTquOfEOVibKnPbodApPmU7F7F1tgKSRRWRlm2j2Kts/zjI4jS S0ebGXXER2OyRzMCHM0UkdZW32v9TQkxSt2HiAu91sk/felDmvzVKWanoKnZhn7m7G3e uRlD3uF3eRrV07BheFwXaD4c7/yJhZs2PXu1MrEJmQENl5zv6UO96f7g0y4rOqNte8em 6+j1q0phteE/Cu89ZenKvipsSzEQUqtPuk4T/MSkDbA7hfIjUwfMkpFz2mzAfqmORYg5 cvkLu87/tMEehMkD0ax+dCn60Q5wFLWsmvVOtYf5w0yuRxiYhuoo/344w0gk7U/+NTIl oHgw== X-Gm-Message-State: AEkooutd1a/9dohKSOZIUrsgiouXPk2nwCFITb+wLQy1wPJjWzbEH+mMLs+9FcBbFa4k1koSyxRLCHqUg609rQ== X-Received: by 10.31.108.156 with SMTP id j28mr8227784vki.68.1471021421770; Fri, 12 Aug 2016 10:03:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.198 with HTTP; Fri, 12 Aug 2016 10:03:41 -0700 (PDT) In-Reply-To: <8de39d98-9b56-a517-c164-069493d12b39@ericsson.com> References: <8de39d98-9b56-a517-c164-069493d12b39@ericsson.com> From: Andy Bierman Date: Fri, 12 Aug 2016 10:03:41 -0700 Message-ID: To: Balazs Lengyel Content-Type: multipart/alternative; boundary=001a1142cfc24d52250539e2dd90 Archived-At: Cc: YANG Doctors , Ing-Wher Chen , James Zhang Q Subject: Re: [yang-doctors] Best way to use only part of iana-if-types.yang X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 17:03:45 -0000 --001a1142cfc24d52250539e2dd90 Content-Type: text/plain; charset=UTF-8 Hi, This seems like a presentation layer issue that your NMS should handle. It is generic to all identityrefs, although iana-if-type is the worst-case example that happens to show up on almost every server. There have been protocol solutions proposed, which would be a much smarter approach than altering the YANG data models. Andy On Fri, Aug 12, 2016 at 9:24 AM, Balazs Lengyel wrote: > Hello, > > Our nodes support only some of the iana interface types. How do we > indicate the correct subset. We want to create the subset on a model level > and not just reject the unsupported values. The CLI is model driven and in > the help it will offer all if-types, as indicated by the model, to the > user. We cannot offer an interface type and later reject it. > > - The best would be to have a deviation indicating no support for the > identity. Sadly YANG does not allow that. > > - We could put a "must" statement to check the identity value, but the > CLI-help might not notice it > - we could create a fake iana-if-types.yang file that contains the > if-types that we support, but that is ugly > - we could change the type of the identityref typed leaf by adding an > additional base to it "supported-if-type" and add this base to all if-types > in iana-if-types.yang that we do support. However this still leads to > editing the iana-if-types.yang file. > - we could change the base of any referencing identityref to > "my-supported-interface-types", but then the management system will not > see this as a standard solution > - something else? > > What is the preferred solution? > > regards Balazs > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors > > --001a1142cfc24d52250539e2dd90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

This seems like a presentation laye= r issue that your NMS should handle.
It is generic to all identit= yrefs, although iana-if-type is the worst-case example
that happe= ns to show up on almost every server.

There have b= een protocol solutions proposed, which would be
a much smarter ap= proach than altering the YANG data models.

Andy


On Fri, Aug 12, 2016 at 9:24 AM, Balazs Lengyel &l= t;balazs.l= engyel@ericsson.com> wrote:
=20 =20 =20

Hello,

Our nodes support only some of the = iana interface types. How do we indicate the correct subset. We want to create the subset on a model level and not just reject the unsupported values. The CLI is model driven and in the help it will offer=C2=A0 all=C2=A0 if-ty= pes, as indicated by the model, to the user. We cannot offer an interface type and later reject it.

- The best would be to have a deviation indicating no support for the identity. Sadly YANG does not allow that.

- We could put a "must" statement to check the identity val= ue, but the CLI-help might not notice it
- we could create a fake iana-if-typ= es.yang file that contains the if-types that we support, but that is ugly
- we could change the type of the identityref typed leaf by adding an additional base to it "supported-if-type" and a= dd this base to all if-types in ian= a-if-types.yang that we do support. However this still leads to editing the = iana-if-types.yang file.
- we could change the base of any referencing identityref to "my-supported-interface-types"= , but then the management system will not see this as a standard solution
- something else?


What is the preferred solution?

regards Balazs
 
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com=20

_______________________________________________
yang-doctors mailing list
yang-doctors@ietf.org
https://www.ietf.org/mailman/listinfo/yang-do= ctors


--001a1142cfc24d52250539e2dd90-- From nobody Fri Aug 12 10:08:14 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94C112D805 for ; Fri, 12 Aug 2016 10:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OVZ5X6kil4d for ; Fri, 12 Aug 2016 10:08:12 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 3C7F412D80C for ; Fri, 12 Aug 2016 10:08:12 -0700 (PDT) X-AuditID: c1b4fb3a-c91fe700000009bd-13-57ae02799dc7 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id D2.2B.02493.9720EA75; Fri, 12 Aug 2016 19:08:10 +0200 (CEST) Received: from [159.107.197.188] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.301.0; Fri, 12 Aug 2016 19:08:08 +0200 To: YANG Doctors References: <8de39d98-9b56-a517-c164-069493d12b39@ericsson.com> From: Balazs Lengyel Message-ID: Date: Fri, 12 Aug 2016 19:08:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM2J7uG4V07pwgwv3RCz6dh1gdGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvaT5QXn9CpOrJVtYDwt38XIySEhYCJx5eosNhBbSGA9o0Tj otguRi4gey2jxPU/l5lAEsIC3hIr1h4AKxIR0JCY9fEoK0RRG1DR+51gRWwCRhJT+8+zgNi8 AvYSO5Y1sYPYLAKqErMarwHZHByiAjES6/sSIEoEJU7OfAJWzikQKPF/1hGwcmag+a1z5kLZ 8hLNW2czQxynIfHwwl/WCYz8s5C0z0LSMgtJywJG5lWMosWpxcW56UZGeqlFmcnFxfl5enmp JZsYgWF2cMtvqx2MB587HmIU4GBU4uFV2LsmXIg1say4MvcQowQHs5IIr8y/teFCvCmJlVWp RfnxRaU5qcWHGKU5WJTEef1fKoYLCaQnlqRmp6YWpBbBZJk4OKUaGA21cjz5U1/7B1/TFlgq FDHnS8qNKSaPq3Ne8J2a5Xjp+2z5fPUCJfM33yaYKPwQfdyxY3HX/oPbrrgK7tqWc9JykYzt 2VlLj+0zatZsc93r4bj6luDk9wf3Tv3775POEwm++tQq0fqPnV6zayY/zbx17rCG+H5FeasT Fp5FE5y7/U446Hl2ByuxFGckGmoxFxUnAgDgunJVLwIAAA== Archived-At: Subject: Re: [yang-doctors] Best way to use only part of iana-if-types.yang X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 17:08:14 -0000

Hello Andy,

I actually very much like the idea of providing a model that really states what I support.
I also like the idea of a model driven CLI (without the need to make many little presentation layer adjustments as they are costly.)

What do you mean by protocol solutions?

IMHO it is a problem that deviations don't allow you to do a number of things:

  • remove identities
  • change description statements
  • etc.

regards Balazs


On 2016-08-12 19:03, Andy Bierman wrote:
Hi,

This seems like a presentation layer issue that your NMS should handle.
It is generic to all identityrefs, although iana-if-type is the worst-case example
that happens to show up on almost every server.

There have been protocol solutions proposed, which would be
a much smarter approach than altering the YANG data models.

Andy


On Fri, Aug 12, 2016 at 9:24 AM, Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:

Hello,

Our nodes support only some of the iana interface types. How do we indicate the correct subset. We want to create the subset on a model level and not just reject the unsupported values. The CLI is model driven and in the help it will offer  all  if-types, as indicated by the model, to the user. We cannot offer an interface type and later reject it.

- The best would be to have a deviation indicating no support for the identity. Sadly YANG does not allow that.

- We could put a "must" statement to check the identity value, but the CLI-help might not notice it
- we could create a fake iana-if-types.yang file that contains the if-types that we support, but that is ugly
- we could change the type of the identityref typed leaf by adding an additional base to it "supported-if-type" and add this base to all if-types in iana-if-types.yang that we do support. However this still leads to editing the iana-if-types.yang file.
- we could change the base of any referencing identityref to "my-supported-interface-types", but then the management system will not see this as a standard solution
- something else?


What is the preferred solution?

regards Balazs
 
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com

_______________________________________________
yang-doctors mailing list
yang-doctors@ietf.org
https://www.ietf.org/mailman/listinfo/yang-doctors



-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Fri Aug 12 10:15:09 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028AD12D80A for ; Fri, 12 Aug 2016 10:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 rI5um26kvF-t for ; Fri, 12 Aug 2016 10:15:05 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EA7912D805 for ; Fri, 12 Aug 2016 10:15:05 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id k90so51915557uak.1 for ; Fri, 12 Aug 2016 10:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nR0bt8e7zq0p+cfg8bFZAeGrKCp+rnpHvptAAKeStIM=; b=RuTpEwvt+4g3OnrWSGEbVsj+zcFyiha0ndu7kD8L8XpNwrWaOg9cD5wzX5Tu7WKWTg vyyTrvNlBNU85k5nm3V9Hf5jUck5dLpyHQVONEWgC0won5HecZ2UJd/is3HS8kxLp6iU R9VFcteeQ9u8Y3xl2okKWnz+HWrpdf9TUpGYXczTaTs68jbdrQrxhRkJ0EU5MqkeBpWG ypuSW0CGngr2a2AurfqQVe+SKkmSS4fe8MQ9UnBT5HimFKQa0Gx5aGnv4/DY0x/Q0j1F NBfsCGU/kifcfvBQKpdty5YCPsVkc8OrYyGXnwDk4DSjtQhwVBJyYsFD53ADl9krOqyU RVXg== 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:from:date :message-id:subject:to:cc; bh=nR0bt8e7zq0p+cfg8bFZAeGrKCp+rnpHvptAAKeStIM=; b=nNAx2sm5+h6kOeSUTWmctJDWwR1VkTE6cvspkH84HDWExH9qINPNq5njJPI/HM40hX B44j9OXEhAYcT0Hi5Z9kkYCY7zeii8gJP6I9X1Qw5hQembiyz2YdgYM9oL8L8fve50+i FpFoN68As6IIn0hOtVfqjTHoPdf5r0arCmIQa7jEecy5b4K1BPoBfs8TjlHou5cQn7Ov XOYk1SnyaDMeZHubL7wjqlmUiMykybyfBu35BmwMUPQvlZ3AF7FPDxyQkcxKqXN8XglK YogzRCU3VeH1uLFOiCLE/Ako1GQI81JzJ8EdaXifsagb7MCW59lVFfaDmUAy2eX77QWG hoTA== X-Gm-Message-State: AEkoouuL1mGVjY0He8z76CwKOfqQySi2sd0TWEpGA8e2F+EaizPq/urv109T/vkq3pRXyh6PdUVlieq9DZ61VQ== X-Received: by 10.31.60.193 with SMTP id j184mr8296444vka.132.1471022104436; Fri, 12 Aug 2016 10:15:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.198 with HTTP; Fri, 12 Aug 2016 10:15:03 -0700 (PDT) In-Reply-To: References: <8de39d98-9b56-a517-c164-069493d12b39@ericsson.com> From: Andy Bierman Date: Fri, 12 Aug 2016 10:15:03 -0700 Message-ID: To: Balazs Lengyel Content-Type: multipart/alternative; boundary=001a11439ee6fe19ea0539e305c5 Archived-At: Cc: YANG Doctors Subject: Re: [yang-doctors] Best way to use only part of iana-if-types.yang X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 17:15:08 -0000 --001a11439ee6fe19ea0539e305c5 Content-Type: text/plain; charset=UTF-8 On Fri, Aug 12, 2016 at 10:08 AM, Balazs Lengyel < balazs.lengyel@ericsson.com> wrote: > Hello Andy, > > I actually very much like the idea of providing a model that really states > what I support. > I also like the idea of a model driven CLI (without the need to make many > little presentation layer adjustments as they are costly.) > > But the data model solution is more costly. It also doesn't work because the YANG module is supposed to represent the one and only API definition. Deviations are the only way to alter the data model to constrain instance documents. This does not really work because different instances of interface type accept different identities. > What do you mean by protocol solutions? > Martin and I both had drafts I think. You could define an RPC operation to return the allowed identities for a specific identityref data node instance. > IMHO it is a problem that deviations don't allow you to do a number of > things: > > - remove identities > - change description statements > - etc. > > regards Balazs > > Andy > On 2016-08-12 19:03, Andy Bierman wrote: > > Hi, > > This seems like a presentation layer issue that your NMS should handle. > It is generic to all identityrefs, although iana-if-type is the worst-case > example > that happens to show up on almost every server. > > There have been protocol solutions proposed, which would be > a much smarter approach than altering the YANG data models. > > Andy > > > On Fri, Aug 12, 2016 at 9:24 AM, Balazs Lengyel < > balazs.lengyel@ericsson.com> wrote: > >> Hello, >> >> Our nodes support only some of the iana interface types. How do we >> indicate the correct subset. We want to create the subset on a model level >> and not just reject the unsupported values. The CLI is model driven and in >> the help it will offer all if-types, as indicated by the model, to the >> user. We cannot offer an interface type and later reject it. >> >> - The best would be to have a deviation indicating no support for the >> identity. Sadly YANG does not allow that. >> >> - We could put a "must" statement to check the identity value, but the >> CLI-help might not notice it >> - we could create a fake iana-if-types.yang file that contains the >> if-types that we support, but that is ugly >> - we could change the type of the identityref typed leaf by adding an >> additional base to it "supported-if-type" and add this base to all if-types >> in iana-if-types.yang that we do support. However this still leads to >> editing the iana-if-types.yang file. >> - we could change the base of any referencing identityref to >> "my-supported-interface-types", but then the management system will not >> see this as a standard solution >> - something else? >> >> What is the preferred solution? >> >> regards Balazs >> >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >> >> >> _______________________________________________ >> yang-doctors mailing list >> yang-doctors@ietf.org >> https://www.ietf.org/mailman/listinfo/yang-doctors >> >> > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors > > --001a11439ee6fe19ea0539e305c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Aug 12, 2016 at 10:08 AM, Balazs Lengyel <= balazs.len= gyel@ericsson.com> wrote:
=20 =20 =20

Hello Andy,

I actually very much like the idea of providing a model that really states what I support.
I also like the idea of a model driven CLI (without the need to make many little presentation layer adjustments as they are costly.)



But the da= ta model solution is more costly.
It also doesn't work becaus= e the YANG module is supposed to represent
the one and only API d= efinition.=C2=A0 Deviations are the only way to alter
the data mo= del to constrain instance documents.
This does not really work be= cause different instances of interface type
accept different iden= tities.
=C2=A0

What do you mean by protocol solutions?


Martin and I both had drafts I= think.
You could define an RPC operation to return the allowed i= dentities
for a specific identityref data node instance.

=C2=A0

IMHO it is a problem that deviations don't allow you to do a number of things:

  • remove identities
  • change description statements
  • etc.

regards Balazs



Andy
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
On 2016-08-12 19:03, Andy Bierman wrote:
=20
Hi,

This seems like a presentation layer issue that your NMS should handle.
It is generic to all identityrefs, although iana-if-type is the worst-case example
that happens to show up on almost every server.

There have been protocol solutions proposed, which would be
a much smarter approach than altering the YANG data models.

Andy


On Fri, Aug 12, 2016 at 9:24 AM, Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:

Hello,

Our nodes support only some of the iana interface types. How do we indicate the correct subset. We want to create the subset on a model level and not just reject the unsupported values. The CLI is model driven and in the help it will offer=C2=A0 all=C2=A0 if-types, as indicated= by the model, to the user. We cannot offer an interface type and later reject it.

- The best would be to have a deviation indicating no support for the identity. Sadly YANG does not allow that.

- We could put a "must" statement to check the id= entity value, but the CLI-help might not notice it
- we could create a fake i= ana-if-types.yang file that contains the if-types that we support, but that is ugly
- we could change the type of the identityref typed leaf by adding an additional base to it "supported-if-type" and add this base to all if= -types in iana-if-types.= yang that we do support. However this still leads to editing the iana-= if-types.yang file.
- we could change the base of any referencing identityref to "my-supported-interface-types", but then t= he management system will not see this as a standard solution
- something else?


What is the preferred solution?

regards Balazs
 
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com=20

_______________________________________________
yang-doctors mailing list
yang= -doctors@ietf.org
https://www.ietf.org/mailman/list= info/yang-doctors



--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com=20

_______________________________________________
yang-doctors mailing list
yang-doctors@ietf.org
https://www.ietf.org/mailman/listinfo/yang-do= ctors


--001a11439ee6fe19ea0539e305c5-- From nobody Wed Aug 17 02:59:33 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2D112D5B1 for ; Wed, 17 Aug 2016 02:59:31 -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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJFC0RwnutkW for ; Wed, 17 Aug 2016 02:59:29 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16EF12D589 for ; Wed, 17 Aug 2016 02:59:29 -0700 (PDT) Received: from Macintosh-4.fritz.box ([83.163.239.181]) by smtp-cloud6.xs4all.net with ESMTP id Y9zS1t0023vXPcr019zTym; Wed, 17 Aug 2016 11:59:27 +0200 To: YANG Doctors From: "Bert Wijnen (IETF)" Message-ID: <33d398f1-a61a-99b2-9d7f-cfceebeb93ec@bwijnen.net> Date: Wed, 17 Aug 2016 11:59:26 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [yang-doctors] defining new RPCs. X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 09:59:31 -0000 Do we have an opinion on the suitability of defining (many) new RPCs? My personal thinking was that one can define new RPCs indeed, but that we wouldprefer that not too many be defined? Opinions? Bert From nobody Wed Aug 17 03:18:12 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC2E12D142 for ; Wed, 17 Aug 2016 03:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2-XjMXf4ZZx for ; Wed, 17 Aug 2016 03:18:10 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id EF1F812D5B8 for ; Wed, 17 Aug 2016 03:18:08 -0700 (PDT) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 5BC281AE0285; Wed, 17 Aug 2016 12:18:02 +0200 (CEST) Date: Wed, 17 Aug 2016 12:17:08 +0200 (CEST) Message-Id: <20160817.121708.1378977556547599455.mbj@tail-f.com> To: bwietf@bwijnen.net From: Martin Bjorklund In-Reply-To: <33d398f1-a61a-99b2-9d7f-cfceebeb93ec@bwijnen.net> References: <33d398f1-a61a-99b2-9d7f-cfceebeb93ec@bwijnen.net> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: yang-doctors@ietf.org Subject: Re: [yang-doctors] defining new RPCs. X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 10:18:11 -0000 "Bert Wijnen (IETF)" wrote: > Do we have an opinion on the suitability of > defining (many) new RPCs? > > > My personal thinking was that one can define new RPCs indeed, > but that we wouldprefer that not too many be defined? > > Opinions? I think it depends what the RPC does. Sometimes we see RPCs on the form 'create-foo' or 'modify-foo' which modify the config. Such RPCs should not be allowed b/c we already have generic RPCs for this (edit-config etc). Also, often people tend to forget that there are multiple datastores when they define such RPCs... Another example is RPCs on the type 'get-foo'. These should also in most cases be avoided, since we already have the generic 'get' operation for NETCONF anf GET for RESTCONF. I suspect that if you see a module with many RPCs, quite a few of them fall into the categories above, and might not be needed. /martin From nobody Wed Aug 17 03:19:33 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F00C12D5FD for ; Wed, 17 Aug 2016 03:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id be7C-SixtaDZ for ; Wed, 17 Aug 2016 03:19: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 A412712D5CB for ; Wed, 17 Aug 2016 03:19:29 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D8ADCF9A; Wed, 17 Aug 2016 12:19:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id TorNLy7qRaJq; Wed, 17 Aug 2016 12:19:24 +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, 17 Aug 2016 12:19:26 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7C322200A3; Wed, 17 Aug 2016 12:19:26 +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 GbaYLHNyjXKZ; Wed, 17 Aug 2016 12:19: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 8779D2009D; Wed, 17 Aug 2016 12:19:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 790C03C2181C; Wed, 17 Aug 2016 12:19:24 +0200 (CEST) Date: Wed, 17 Aug 2016 12:19:23 +0200 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20160817101923.GA2397@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , YANG Doctors References: <33d398f1-a61a-99b2-9d7f-cfceebeb93ec@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33d398f1-a61a-99b2-9d7f-cfceebeb93ec@bwijnen.net> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: YANG Doctors Subject: Re: [yang-doctors] defining new RPCs. X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 10:19:31 -0000 On Wed, Aug 17, 2016 at 11:59:26AM +0200, Bert Wijnen (IETF) wrote: > Do we have an opinion on the suitability of > defining (many) new RPCs? > > > My personal thinking was that one can define new RPCs indeed, > but that we wouldprefer that not too many be defined? > > Opinions? > In my view, the main guideline is that newly defined RPCs should not overlap with what can already be achieved with the basic protocol primitives we have. /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 Aug 17 03:29:58 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40AC12D60F for ; Wed, 17 Aug 2016 03:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RY0dxXGfd7Dy for ; Wed, 17 Aug 2016 03:29:55 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAA412D600 for ; Wed, 17 Aug 2016 03:29:55 -0700 (PDT) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 9E8171AE0285; Wed, 17 Aug 2016 12:29:54 +0200 (CEST) Date: Wed, 17 Aug 2016 12:29:01 +0200 (CEST) Message-Id: <20160817.122901.1956688968615598710.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160721113127.GA54084@elstar.local> References: <20160721113127.GA54084@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: yang-doctors@ietf.org Subject: Re: [yang-doctors] faq: where can I find good yang tutorials? X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 10:29:57 -0000 Juergen Schoenwaelder wrote: > I am interested to add a list of _good_ tutorials on the wikipedia > page and hence my question. I guess such a list should also be in the > FAQ (very high up). I know about the IETF 94 NETCONF and YANG > tutorials. Anything else there worth mentioning? See the first three (at least) in: http://www.yang-central.org/twiki/bin/view/Main/YangDocuments /martin From nobody Wed Aug 17 03:53:03 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7807F12B03D for ; Wed, 17 Aug 2016 03:53:02 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 UdahsY6XpFDa for ; Wed, 17 Aug 2016 03:53:00 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0120.outbound.protection.outlook.com [104.47.2.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6CA912B014 for ; Wed, 17 Aug 2016 03:52:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=s6C80acfmVM3LC+riYDN0vsKkOv8ACitQp0I2MSMyXI=; b=la7D4H0x5RH5hljbW3ifofaaW8R4wGf0btNhmrDs7lIyFQuK24/qC3FdJ5FhlBNRXwfc6kP0s4O16wUkcDgSfVeiNy9nVF7CwcAYhl7zvu6SAK5viZzxQqckyCW6S8dRThf+xzvhmnrb+gAKcNd/GACn4BPGNp/Yn3I8dvUejSM= Received: from HE1PR0701MB2859.eurprd07.prod.outlook.com (10.168.91.149) by HE1PR0701MB2857.eurprd07.prod.outlook.com (10.168.91.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Wed, 17 Aug 2016 10:52:56 +0000 Received: from HE1PR0701MB2859.eurprd07.prod.outlook.com ([10.168.91.149]) by HE1PR0701MB2859.eurprd07.prod.outlook.com ([10.168.91.149]) with mapi id 15.01.0549.027; Wed, 17 Aug 2016 10:52:56 +0000 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: Martin Bjorklund , "j.schoenwaelder@jacobs-university.de" Thread-Topic: [yang-doctors] faq: where can I find good yang tutorials? Thread-Index: AQHR+HJPS2LjZQIWKUGHraDbnJ3vhaBM+fUQ Date: Wed, 17 Aug 2016 10:52:56 +0000 Message-ID: References: <20160721113127.GA54084@elstar.local> <20160817.122901.1956688968615598710.mbj@tail-f.com> In-Reply-To: <20160817.122901.1956688968615598710.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mehmet.ersue@nokia.com; x-originating-ip: [131.228.32.164] x-ms-office365-filtering-correlation-id: 19770054-449c-4c38-6f6b-08d3c68ca595 x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2857; 6:cbVx2Yxb9WYNt1RvaP8xBKCs9dz75/nl3yRKkx3nZuYQg9Xr1msvfq0Sx3MVHeKEkFrBK2nus2tzQDvqWJu2HuMd2wowuuGRXJNGTTOuAGaWyCDR18YPPZU/sOlu6FrXqXUdE8gE0TKWPtDw4epzxYMr+MozifblKePpy0mpoPwLhjQAzmhtiu6v3uAX6t26lFxy+BHxARyR+KxL0fer6fbajmjUn9WihsOflokn1LkE9kvnRSV52uuC/IQpx6kFX90Ll3PYkQple2IpDV4QoDelYuV1oH5E7IuSKZCfctTavgYgm1lXZRbGHdXDBvLjwR6P9oyLTO9vi8y2AhQ6hA==; 5:pT+exVmf0qF1Nc4jJpecFYASp24Ns1CqlIU1PNzVvwiuIu1ILQSbyhfSRu6uKy6hFF8AfSxRB6I8bVw0NDrVOR2MoJ5voWbbxjTw5mTjlnetLqkh1SJKZWNEEHC7SFmplN9QiwMWecKkQ3yTssDKlg==; 24:9VM0wQcc0JdK8jbjivG7ialTrSWOWoPXMnFuOeUIICn4NeK4nX3ThtENLzSXt+f4VCiuLpKl9FYfiGNYeRLdlJty+xRNxccTnpbeZhlnWkQ=; 7:7ICM2LJcMhmZ6JcYZqciEcz1CwEvqqtAQhw1X2y9Qm8KICoH7USuJMYQSZauAf2Y8zP16OwkYAGjfvx1Kmp+5yHTJBhG5VaXJ/mvhKSl7PvvYCcqsB4Sux7UUFPOS8aGL9ziMYJlzbW6RCb+G2n4BNmdztTtqUkJzjC48z0S8HTggMIefV374WCfTgDWv7f3HcFH+OMZ7LF4+PNuMEM3p6MN7LOrbPg/13tmmVZ3vwzhHCZqO4QA2Of4iyE4uJqV x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0701MB2857; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:HE1PR0701MB2857; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2857; x-forefront-prvs: 0037FD6480 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(189002)(199003)(377454003)(24454002)(81156014)(15975445007)(19580395003)(7696003)(92566002)(33656002)(66066001)(19580405001)(2900100001)(10400500002)(122556002)(81166006)(50986999)(7736002)(3280700002)(2501003)(189998001)(7846002)(305945005)(9686002)(5001770100001)(586003)(86362001)(105586002)(77096005)(3846002)(74316002)(101416001)(2950100001)(1720100001)(68736007)(8676002)(76176999)(3660700001)(2906002)(97736004)(6116002)(54356999)(87936001)(106116001)(102836003)(4326007)(76576001)(5002640100001)(106356001)(11100500001)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2857; H:HE1PR0701MB2859.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2016 10:52:56.2835 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2857 Archived-At: Cc: "yang-doctors@ietf.org" Subject: Re: [yang-doctors] faq: where can I find good yang tutorials? X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 10:53:02 -0000 IETF tutorials are already in the first entry of the FAQ page. PLMK what should be added. Cheers,=20 Mehmet=20 -----Original Message----- From: yang-doctors [mailto:yang-doctors-bounces@ietf.org] On Behalf Of Mart= in Bjorklund Sent: Wednesday, August 17, 2016 12:29 PM To: j.schoenwaelder@jacobs-university.de Cc: yang-doctors@ietf.org Subject: Re: [yang-doctors] faq: where can I find good yang tutorials? Juergen Schoenwaelder wrote: > I am interested to add a list of _good_ tutorials on the wikipedia > page and hence my question. I guess such a list should also be in the > FAQ (very high up). I know about the IETF 94 NETCONF and YANG > tutorials. Anything else there worth mentioning? See the first three (at least) in: http://www.yang-central.org/twiki/bin/view/Main/YangDocuments /martin _______________________________________________ yang-doctors mailing list yang-doctors@ietf.org https://www.ietf.org/mailman/listinfo/yang-doctors From nobody Tue Aug 23 05:47:44 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E3312B017; Tue, 23 Aug 2016 05:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qtNfMFhx79o; Tue, 23 Aug 2016 05:47:41 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CC55212B008; Tue, 23 Aug 2016 05:47:37 -0700 (PDT) Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id EBBA11AE035C; Tue, 23 Aug 2016 14:47:30 +0200 (CEST) Date: Tue, 23 Aug 2016 14:46:36 +0200 (CEST) Message-Id: <20160823.144636.1796310931546236457.mbj@tail-f.com> To: draft-ietf-lmap-yang.all@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: yang-doctors@ietf.org Subject: [yang-doctors] YANG doctor review of draft-ietf-lmap-yang-05 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 12:47:42 -0000 Hi, I am the assigned YANG doctor for this document. I have reviewed this document from a pure YANG standpoint. I have not checked that the YANG model matches the information model etc. As expected, this model is in good shape. Here are my comments: o The typedef glob-pattern use \ in a double qouted string. Specifically, it uses the characters \\ which actually expand to a single '\'. Also in YANG 1.1 the sequences \* and \? are illegal. I suggest this text is re-written to avoid backslahses, or that a single quote string is used. o The device-id is of type inet:uri. I see that this is specified in the information model as well. But why is it a URI? As an operator, which URI should I choose? o lmap/agent/device-id's description says: The device-id identifies a property of the device running the measurement agent. Should this be s/a property of//? Otherwise, which property is being referred to? o lmap-state/agent/device-id is marked as 'mandatory true', but its description says that is optional. o lmap/agent/controller-timeout says that "an event is raised". What kind of event? Which protocol? [later] Ok, reading the events subtree, I see that there is an event 'controller-lost' there. Presumably the text refers to this event. If so, this text could maybe be clarified. o In /lmap/events/event/event-type there are a couple of cases that are leaf empty, and these leafs are marked as 'mandatory true': case immediate { leaf immediate { type empty; mandatory true; ... } } I was going to write that this is confusing, but in fact it is pretty clever! No action required! o Should the choice /lmap/events/event/event-type be marked as 'mandatory true'? Otherwise, what happens if no event-type is configured? o The descriptions in several nodes in /lmap/events/event/event-type/calendar are a bit confusing: leaf-list month { type lmap:month-or-all; min-elements 1; description "A month at which this calendar timing will trigger. The wildcard means all months."; The description says "_A_ month", but the node is a leaf-list. Maybe change to "A set of months". (same for other nodes in this case as well) o /lmap/tasks/task/program is optional (and marked as nacm:default-deny-write). What happens if this leaf is not set? o Are /lmap-state/agent/{hardware,firmware} different than /system-state/platform/{machine,os-release/os-version} in ietf-system? o So the MA is supposed to invoke RPCs on a controller. Is this described somewhere? Are the details left to implementations? /martin From nobody Wed Aug 31 08:20:40 2016 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7D012D1C0 for ; Wed, 31 Aug 2016 08:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.07 X-Spam-Level: X-Spam-Status: No, score=-15.07 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ZMthWXpVzBk8 for ; Wed, 31 Aug 2016 08:20:37 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B7F512DB83 for ; Wed, 31 Aug 2016 07:53:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=395; q=dns/txt; s=iport; t=1472655182; x=1473864782; h=from:to:cc:subject:message-id:date:mime-version: content-transfer-encoding; bh=rzxDA7X8Cen3EBBPA3BmtK0YcQvb8MtRJ2YLAvUDLuY=; b=YyXiuVIiKTUEibD0+iz3A9ygt73AHfrd0KMOCcmt2GDNe9C7M69ZOQzD f/tAGbFRRCfOPdJhYwOJx4TLofD5RmNYlQmKtv/DTXeIiVG/8Tf9ky6ZA LjMItPuGomCNdDTCXfr9Q74th62NS4faXLV5+hxS9LYV8sePHgWGU13Ow M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CWDgDn7sZX/xbLJq1dg00BAQEBAXUqU?= =?us-ascii?q?oNHtmAkhW8BCYIGEQECAQEBAQEBAV4nQRCEOhVBNQImAl8NCAEBiEIOrmCPJQE?= =?us-ascii?q?BAQEBBQIBJIEFhSqBeIcIgw+CWgEEmVCPMIFXARWEXYMRhFiBJIh8h0U0IIQxO?= =?us-ascii?q?jQBgjmCBoIsAQEB?= X-IronPort-AV: E=Sophos;i="5.30,262,1470700800"; d="scan'208";a="687259707" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2016 14:53:00 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u7VEr06L015176; Wed, 31 Aug 2016 14:53:00 GMT From: Benoit Claise To: YANG Doctors Message-ID: <09592ae4-78a7-96b3-da82-cfe6fd7fe1b3@cisco.com> Date: Wed, 31 Aug 2016 16:53:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Per Hedeland , 'Lou Berger' Subject: [yang-doctors] claise.be: new confdc version X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 15:20:39 -0000 Dear all, I upgraded to the latest confdc version to produce http://www.claise.be/IETFYANGPageCompilation.html Several issues have been fixed: - error: unexpected keyword 'reference' - two "internal error" occurences - error: unexpected keyword 'must' Please check your YANG modules on http://www.claise.be/IETFYANGPageCompilation.html for the latest report. Regards, Benoit