From nils.fischbeck@adtran.com Thu Oct 22 00:14:13 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDFD1B3825 for ; Thu, 22 Oct 2015 00:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9HSNCv6Vrar for ; Thu, 22 Oct 2015 00:14:10 -0700 (PDT) Received: from s12p02o142.mxlogic.net (s12p02o142.mxlogic.net [208.65.145.65]) (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 781571B3821 for ; Thu, 22 Oct 2015 00:14:10 -0700 (PDT) Received: from unknown [76.164.174.82] (EHLO ex-hc3.corp.adtran.com) by s12p02o142.mxlogic.net(mxl_mta-8.5.0-3) over TLS secured channel with ESMTP id 1cc88265.0.17457.00-383.42974.s12p02o142.mxlogic.net (envelope-from ); Thu, 22 Oct 2015 01:14:10 -0600 (MDT) X-MXL-Hash: 56288cc222b73cab-5e11aaef3546917294d811ec169d2476e624be4c Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc3.corp.adtran.com ([fe80::3892:20fa:600f:75c6%15]) with mapi id 14.03.0248.002; Thu, 22 Oct 2015 02:14:09 -0500 From: NILS FISCHBECK To: "netconf@ietf.org" Thread-Topic: Requesting lists in a container via RestConf Thread-Index: AdEMmNq+eDeE55YGR8mKT1PQlIPvwA== Date: Thu, 22 Oct 2015 07:14:09 +0000 Message-ID: <1AD4E3EE8900414DA099DB2732403B928B8DE6C6@ex-mb1.corp.adtran.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.56.39] Content-Type: multipart/alternative; boundary="_000_1AD4E3EE8900414DA099DB2732403B928B8DE6C6exmb1corpadtran_" MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=IrwKcdPg c=1 sm=1 tr=0 a=J+LXdEUA8t8MtBPt16/Qbg==] X-AnalysisOut: [:117 a=J+LXdEUA8t8MtBPt16/Qbg==:17 a=eJNrpioGAAAA:8 a=YlVT] X-AnalysisOut: [AMxIAAAA:8 a=0Bvq39fDVXwA:10 a=xqWC_Br6kY4A:10 a=5lJygRwiO] X-AnalysisOut: [n0A:10 a=jMpmes-_O_5pGmB07foA:9 a=wPNLvfGTeEIA:10 a=yMhMjl] X-AnalysisOut: [ubAAAA:8 a=SSmOFEACAAAA:8 a=fqA4odjUtRuM7D98otMA:9 a=_62MM] X-AnalysisOut: [T7i0XuMZgPe:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC] X-AnalysisOut: [7Yk6K0A:10 a=frz4AuCg-hUA:10] X-Spam: [F=0.5794994041; CM=0.500; MH=0.579(2015102202); S=0.200(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.82] Archived-At: X-Mailman-Approved-At: Sun, 01 Nov 2015 17:05:02 -0800 Subject: [Netconf] Requesting lists in a container via RestConf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 09:09:19 -0000 --_000_1AD4E3EE8900414DA099DB2732403B928B8DE6C6exmb1corpadtran_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Suppose we have in a YANG file container jukebox { list artist { key name; leaf name {..} // other leafs } list playlist { key name; leaf name {..} // other leafs } } How can I request using RestConf all artists but not all playlists (because= there are so many)? More precise: If I request with a GET /restconf/data/example-jukebox:jukebox/artist (without any specific key) what is the result in XML and JSON and is it a valid request? Regards Nils ADTRAN GmbH, Siemensallee 1, 17489 Greifswald, GERMANY Office: +49 3834 5352 870 Cell: +49 170 632 8819 Sitz der Gesellschaft: Berlin / Registered office: Berlin Registergericht: Berlin / Commercial registry: Amtsgericht Charlottenburg, = HRB 135656 B Gesch=E4ftsf=FChrung / Managing Directors: Michael K. Foliano, James D. Wil= son, Jr., Dr. Eduard Scheiterer --_000_1AD4E3EE8900414DA099DB2732403B928B8DE6C6exmb1corpadtran_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Suppose we have in a YANG file<= o:p>

 

container jukebox {<= /span>

     &= nbsp;    list artist {

     &= nbsp;      key name;

     &= nbsp;      leaf name {..}

     &= nbsp;      // other leafs

     &= nbsp;     }

     &= nbsp;     list playlist {

     &= nbsp;      key name;

     &= nbsp;      leaf name {..}

     &= nbsp;      // other leafs

     &= nbsp;     }

}

      =  

How can I request using RestCon= f all artists but not all playlists (because there are so many)?=

More precise: If I request with= a GET

 

/restconf/data/example-jukebox:= jukebox/artist (without any specific key)

 

what is the result in XML and J= SON and is it a valid request?

 

Regards

Nils

 

ADTRAN GmbH, Siemensallee 1, 17489 Greifs= wald, GERMANY

Office: +49 3834 5352 870<= /span>

Cell: +49 170 632 8819

Sitz der Gesellschaft: Berlin / Registered office: Berli= n

Registergericht: Berlin / Commercial registry: Amtsgeric= ht Charlottenburg, HRB 135656 B

Gesch=E4ftsf=FChrung / Managing Directors: Michael K. Fo= liano, James D. Wilson, Jr., Dr. Eduard Scheiterer

 

--_000_1AD4E3EE8900414DA099DB2732403B928B8DE6C6exmb1corpadtran_-- From nobody Sun Nov 1 17:06:43 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDEA1ACCF2 for ; Sun, 1 Nov 2015 17:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TR4elBAcsy9O for ; Sun, 1 Nov 2015 17:06:39 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 C2B891ACCFD for ; Sun, 1 Nov 2015 17:06:38 -0800 (PST) Received: by lfbf136 with SMTP id f136so41089254lfb.0 for ; Sun, 01 Nov 2015 17:06:37 -0800 (PST) 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:date:message-id:subject:from:to :cc:content-type; bh=/AzrhrMqCR34ZI5w9PrDjZcxg6L7/xXV3yr5eeR/4z8=; b=x2WezYtnXo8j4gQkRkfQ7nKHM4P8iT/KlMC0gPKzD8Yyb0q+FVHPp//hbqjOlvscAh ZYOYGeT80ei9aJbhwwfzl8ox1S366nZhywjcEnrKSRRMWtuDUi6HbMP3Jg0ZIUZYD4/g QjLEFuXh4+uWzA3VI9aEQYwtm2NnnycB1ZheqIbDE4lChuRaBo6ETqelXA8qavG7o6n8 4olpfxf2qE8+o3Vb26/lByVbDbVnABgWyU9QP62Ks0qwUP43wfFklu/xlT7k8+0npYkq fH9Wyz1hnaTnfXIiuVBP2KECDub3B5FEfiwI/IXCByMcRgbtXQXNs+IwGhfUdzuSUw9U /1Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/AzrhrMqCR34ZI5w9PrDjZcxg6L7/xXV3yr5eeR/4z8=; b=mCTTMWI8DryiMDreDUKzm4cXk6b2kN+qA8nIT6PR3Z7Rqj5MKFps9dUvEFAVGmc8Ei emObws3PndV1nc6ukrtREoPPwwXuSllSJ2A2YPeBnrXAVwf0ysC0unJ+zRgmaqo6Deza ZHXfpR4LL3LwcrMwzZgp7SQfo/rcpHO9+dyBbbwlN7PXEiTXHXZWA6n9Na5f2G1yg99o hr/JM07P1j/oHOgrKHrKalAb2WpYLN0+gkyNlrZoVCjPgCAaor8UF98S/me9lVZQKx2A IllqbJ7Wa9Fe57yESrigYDLd/a9+ooGyxPEpFueMzhe/g+pp7XIadadbT4cVDKEziyt7 /+Mw== X-Gm-Message-State: ALoCoQk+FtBT+1qWs2ckUxdItVbAuY88u9MpGCOJAiMbbnJmkOeKLQFq95E9MBKQJeWvsAkCpf/j MIME-Version: 1.0 X-Received: by 10.25.145.209 with SMTP id t200mr5760458lfd.88.1446426397004; Sun, 01 Nov 2015 17:06:37 -0800 (PST) Received: by 10.112.144.106 with HTTP; Sun, 1 Nov 2015 17:06:36 -0800 (PST) In-Reply-To: <1AD4E3EE8900414DA099DB2732403B928B8DE6C6@ex-mb1.corp.adtran.com> References: <1AD4E3EE8900414DA099DB2732403B928B8DE6C6@ex-mb1.corp.adtran.com> Date: Sun, 1 Nov 2015 17:06:36 -0800 Message-ID: From: Andy Bierman To: NILS FISCHBECK Content-Type: multipart/alternative; boundary=001a114021b096740c05238463cd Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Requesting lists in a container via RestConf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 01:06:41 -0000 --001a114021b096740c05238463cd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Oct 22, 2015 at 12:14 AM, NILS FISCHBECK wrote: > Suppose we have in a YANG file > > > > container jukebox { > > list artist { > > key name; > > leaf name {..} > > // other leafs > > } > > list playlist { > > key name; > > leaf name {..} > > // other leafs > > } > > } > > > > How can I request using RestConf all artists but not all playlists > (because there are so many)? > > More precise: If I request with a GET > > > > /restconf/data/example-jukebox:jukebox/artist (without any specific key) > > > See the "fields" query parameter > what is the result in XML and JSON and is it a valid request? > > > > Regards > > Nils > > > > ADTRAN GmbH, Siemensallee 1, 17489 Greifswald, GERMANY > > Office: +49 3834 5352 870 > > Cell: +49 170 632 8819 > > Sitz der Gesellschaft: Berlin / Registered office: Berlin > > Registergericht: Berlin / Commercial registry: Amtsgericht Charlottenburg= , > HRB 135656 B > > Gesch=C3=A4ftsf=C3=BChrung / Managing Directors: Michael K. Foliano, Jame= s D. > Wilson, Jr., Dr. Eduard Scheiterer > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a114021b096740c05238463cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 22, 2015 at 12:14 AM, NILS FISCHBECK <= NILS.FISCHBE= CK@adtran.com> wrote:

Suppose we have in a YANG file<= u>

=C2=A0

container jukebox {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 list artist {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 key name;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf name {..}

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // other leafs

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 list playlist {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 key name;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf name {..}

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // other leafs

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }

}

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0

How can I request using RestCon= f all artists but not all playlists (because there are so many)?<= /u>

More precise: If I request with= a GET

=C2=A0

/restconf/data/example-jukebox:= jukebox/artist (without any specific key)

=C2=A0

<= /div>


See the "fields&q= uot; query parameter

=C2=A0

what is the result in XML and J= SON and is it a valid request?

=C2=A0

Regards

Nils

=C2=A0

ADTRAN GmbH, Siemensallee 1, 17489 Greifswald, GERMANY<= /u>

Office: +49 3834 5352 870

Cell: +49 170 632 8819

Sitz = der Gesellschaft: Berlin / Registered office: Berlin

Regis= tergericht: Berlin / Commercial registry: Amtsgericht Charlottenburg, HRB 1= 35656 B

Gesch= =C3=A4ftsf=C3=BChrung / Managing Directors: Michael K. Foliano, James D. Wi= lson, Jr., Dr. Eduard Scheiterer

=C2=A0


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


--001a114021b096740c05238463cd-- From nobody Sun Nov 1 17:44:40 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB421B40A3 for ; Sun, 1 Nov 2015 17:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.322 X-Spam-Level: * X-Spam-Status: No, score=1.322 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CN_BODY_35=0.339, CN_BODY_509=0.029, CN_BODY_832=0.004, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6dLXlKS0DyG for ; Sun, 1 Nov 2015 17:44:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CFC31B40A0 for ; Sun, 1 Nov 2015 17:44:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZQ44062; Mon, 02 Nov 2015 01:44:34 +0000 (GMT) Received: from SZXEMI401-HUB.china.huawei.com (10.82.75.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 2 Nov 2015 01:44:33 +0000 Received: from SZXEMI506-MBS.china.huawei.com ([169.254.6.125]) by SZXEMI401-HUB.china.huawei.com ([10.82.75.33]) with mapi id 14.03.0235.001; Mon, 2 Nov 2015 09:44:30 +0800 From: "fengchong (C)" To: "netconf@ietf.org" Thread-Topic: how to get the list data meet some filters via restconf Thread-Index: AdEVD+x/O7+RUNHQR0GgFRon/80Jjg== Date: Mon, 2 Nov 2015 01:44:29 +0000 Message-ID: <5756FB984666AD4BB8E1D63E2E3AA3D082735C@SZXEMI506-MBS.china.huawei.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.134.40.226] Content-Type: multipart/related; boundary="_004_5756FB984666AD4BB8E1D63E2E3AA3D082735CSZXEMI506MBSchina_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Netconf] how to get the list data meet some filters via restconf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 01:44:39 -0000 --_004_5756FB984666AD4BB8E1D63E2E3AA3D082735CSZXEMI506MBSchina_ Content-Type: multipart/alternative; boundary="_000_5756FB984666AD4BB8E1D63E2E3AA3D082735CSZXEMI506MBSchina_" --_000_5756FB984666AD4BB8E1D63E2E3AA3D082735CSZXEMI506MBSchina_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQpIaSwNCiAgWUFORyBtb2R1bGUgaXMgbGlzdCBiZWxvdzsNCiAgTGlzdCBhIHsNCktleSBuYW1l Ow0KTGVhZiBuYW1lIHsNCqGtDQp9DQoNCkxlYWYgYiB7DQogICChrQ0KfQ0KDQpMZWFmIGMgew0K ICChrQ0KfQ0KICB9DQoNCg0KICBIb3cgY2FuIEkgZ2V0IGFsbCBkYXRhIG9mIGxpc3QgYSB3aXRo IGIgPSAxID8NCg0KL3Jlc3Rjb25mL2RhdGEvZXhhbXBsZTpleGFtcGxlIC9hP2I9MQ0KDQpPUg0K L3Jlc3Rjb25mL2RhdGEvZXhhbXBsZTpleGFtcGxlIC9hP3doZXJlPaGvYj0xDQoNCkJUVzogd2hl cmUgcGFyYW1ldGVyIGlzIG5vdCBjbGVhcmx5IGRlZmluZWQgaW4NCmRyYWZ0LWlldGYtbmV0Y29u Zi1yZXN0Y29uZi1jb2xsZWN0aW9uLTAwLnR4dDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLWNvbGxlY3Rpb24tMDAudHh0Pg0Koa8NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQq367PlDQq7qs6qvLzK9dPQz965q8u+IEh1YXdl aSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuDQpbQ29tcGFueV9sb2dvXQ0KDQpQaG9uZToNCkZheDoN Ck1vYmlsZTogMTg1MTkxMTczMTYNCkVtYWlsOiBmcmFuay5mZW5nY2hvbmdAaHVhd2VpLmNvbQ0K tdjWt6O6xM++qcrQyO28/rTztcAxMDG6xbuqzqrEz76pu/m12CDTyrHgo7oyMTAwMDENCkh1YXdl aSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuDQoNCmh0dHA6Ly93d3cuaHVhd2VpLmNvbQ0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCrG+08q8/rywxuS4vbz+uqzT0Luqzqq5q8u+tcSx o8Pc0MXPoqOsvfbP3tPat6LLzbj4yc/D5rXY1rfW0MHQs/a1xLj2yMu78si61+mho737DQrWucjO us7G5Mv7yMvS1MjOus7Qzsq9yrnTw6OosPzAqLWrsrvP3tPayKuyv7vysr+31rXY0LnCtqGiuLTW xqGiu/LJoreio6mxvtPKvP7W0A0KtcTQxc+ioaPI57n7xPq07crVwcuxvtPKvP6jrMfrxPrBory0 tee7sLvy08q8/s2o1qq3orz+yMuyosm+s/2xvtPKvP6joQ0KVGhpcyBlLW1haWwgYW5kIGl0cyBh dHRhY2htZW50cyBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9tIEhVQVdFSSwg d2hpY2gNCmlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFk ZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZQ0KaW5mb3JtYXRpb24gY29udGFp bmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90 YWwgb3IgcGFydGlhbA0KZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBvciBkaXNzZW1pbmF0aW9u KSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhlIGludGVuZGVkDQpyZWNpcGllbnQocykgaXMgcHJv aGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBieQ0KcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBp dCENCg== --_000_5756FB984666AD4BB8E1D63E2E3AA3D082735CSZXEMI506MBSchina_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

 

Hi,

  YANG module is list belo= w;

  List a {

Ke= y name;

Le= af name {

= =A1=AD

}<= o:p>

 

Le= af b {

&n= bsp;  =A1=AD

}<= o:p>

 

Le= af c {

&n= bsp; =A1=AD

}<= o:p>

  }

 

 

  How can I get all data o= f list a with b =3D 1 ?

 

/restconf/data/example:example = /a?b=3D1

 

OR

/restconf/data/example:example = /a?where=3D=A1=AFb=3D1

 

BTW: where parameter is not cle= arly defined in
draft-ietf-netconf-restconf-collection-00.txt

=A1=AF

=B7= =EB=B3=E5
=BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Technologies Co., Ltd.
3D"Company_logo"

Phone:
Fax:
Mobile: 18519117316
Email: frank.fengchong@huawei.com
=B5=D8=D6=B7=A3=BA=C4=CF=BE=A9=CA=D0=C8=ED=BC=FE=B4=F3=B5=C0<= span lang=3D"EN-US">101=BA=C5=BB=AA=CE=AA=C4=CF=BE=A9=BB=F9=B5=D8 = =D3=CA=B1=E0=A3=BA210001
Huawei Technologies Co., Ltd.

http://www.huawei.com

=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA= =AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6= =CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5= =C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB
=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD= =CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2= =BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9= =B1=BE=D3=CA=BC=FE=D6=D0
=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE= =D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD= =A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
This e-mail and its attac= hments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!<= /o:p>

--_000_5756FB984666AD4BB8E1D63E2E3AA3D082735CSZXEMI506MBSchina_-- --_004_5756FB984666AD4BB8E1D63E2E3AA3D082735CSZXEMI506MBSchina_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=6737; creation-date="Mon, 02 Nov 2015 01:44:29 GMT"; modification-date="Mon, 02 Nov 2015 01:44:29 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --_004_5756FB984666AD4BB8E1D63E2E3AA3D082735CSZXEMI506MBSchina_-- From nobody Sun Nov 1 17:48:31 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF6D1B40CD for ; Sun, 1 Nov 2015 17:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.268 X-Spam-Level: X-Spam-Status: No, score=-1.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0ptCFM0zn4A for ; Sun, 1 Nov 2015 17:48:21 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 5F3711B40C8 for ; Sun, 1 Nov 2015 17:48:20 -0800 (PST) Received: by lfbn126 with SMTP id n126so55203561lfb.2 for ; Sun, 01 Nov 2015 17:48:18 -0800 (PST) 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:date:message-id:subject:from:to :cc:content-type; bh=634Nm82h1MX7bathuc0EM8MmaosZqBLGuQqZlRrAZA0=; b=ZmgyUzjCMthiryDWKLra5keg/aahp4fsT86+FbTreYyD/uQcMILRuDgIe+lqd0oVP+ IlB4sU8hary3pVwObtBElxg+3b/WqrDSEDwyaovw2kvGCyFyP1YYjSMgQtfDGixP6Bav +5geHV27EsHsqVzpGQUBd+vXZ0BTtdD+GKE4Q8U9mrqGLEx8rbb9XHFVQxDVN6Amo3vC 8kD1ZXyTNZzYiJSJFD2Yf+AGNcGfaKnEHfn8fYZ/WhkcEdbAM7PBqzBkEdiiBVEZzYky VyVUXFcY+IrhF58tr9pQLRQa+BLUhv5XusMFDwZnkBKilhnOfwoZ9V2rfMWUpv6mwOUy NwXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=634Nm82h1MX7bathuc0EM8MmaosZqBLGuQqZlRrAZA0=; b=T1ZzFyFPmBNWhj/kOpwudn3L7W4IDvhxl1Q9ca3+4NCKXPyvMaSkN1glzIXgiOShe4 i9wblUN7PfVC0DVEWKiNlao9qdE4tgqmhUftwbyD70oWPG++ujuRQNvrydJUTfOqWgQH z2UT7JS+jTsqCEbOZK/n+pkVIyH58ga+2SZ8em5E8bSC/azzvv7sBLESQ2qdsU45h0+J ZzQHfZRC3UEKpelPQkOKmZh96buetECBjF3YUUSyfT76Dk5/DbUaNxtDvT66jKOIFXbB x8swHUvuwFVNrijkxL++oGPJi2emjIFmSvgji6/IXGlAVMrLLEt5qPdT8hI/HZnLahUB 4ikg== X-Gm-Message-State: ALoCoQmrfxFU8ns7LajD4z0/r+/kjPT6TUStxA4WuFrEblvL/llF7LMXUax3n36U6jx/ezvALFuS MIME-Version: 1.0 X-Received: by 10.25.153.18 with SMTP id b18mr5923861lfe.33.1446428898427; Sun, 01 Nov 2015 17:48:18 -0800 (PST) Received: by 10.112.144.106 with HTTP; Sun, 1 Nov 2015 17:48:18 -0800 (PST) In-Reply-To: <5756FB984666AD4BB8E1D63E2E3AA3D082735C@SZXEMI506-MBS.china.huawei.com> References: <5756FB984666AD4BB8E1D63E2E3AA3D082735C@SZXEMI506-MBS.china.huawei.com> Date: Sun, 1 Nov 2015 17:48:18 -0800 Message-ID: From: Andy Bierman To: "fengchong (C)" Content-Type: multipart/related; boundary=001a114730c0af301a052384f8ab Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] how to get the list data meet some filters via restconf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 01:48:22 -0000 --001a114730c0af301a052384f8ab Content-Type: multipart/alternative; boundary=001a114730c0af3018052384f8aa --001a114730c0af3018052384f8aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 T24gU3VuLCBOb3YgMSwgMjAxNSBhdCA1OjQ0IFBNLCBmZW5nY2hvbmcgKEMpIDxmcmFuay5mZW5n Y2hvbmdAaHVhd2VpLmNvbT4NCndyb3RlOg0KDQo+DQo+DQo+IEhpLA0KPg0KPiAgIFlBTkcgbW9k dWxlIGlzIGxpc3QgYmVsb3c7DQo+DQo+ICAgTGlzdCBhIHsNCj4NCj4gS2V5IG5hbWU7DQo+DQo+ IExlYWYgbmFtZSB7DQo+DQo+IOKApg0KPg0KPiB9DQo+DQo+DQo+DQo+IExlYWYgYiB7DQo+DQo+ ICAgIOKApg0KPg0KPiB9DQo+DQo+DQo+DQo+IExlYWYgYyB7DQo+DQo+ICAg4oCmDQo+DQo+IH0N Cj4NCj4gICB9DQo+DQo+DQo+DQo+DQo+DQo+ICAgSG93IGNhbiBJIGdldCBhbGwgZGF0YSBvZiBs aXN0IGEgd2l0aCBiID0gMSA/DQo+DQo+DQo+DQo+IC9yZXN0Y29uZi9kYXRhL2V4YW1wbGU6ZXhh bXBsZSAvYT9iPTENCj4NCg0KWW91IGNhbm5vdCBkbyB0aGlzIGluIFJFU1RDT05GICh5ZXQpDQoN Cg0KPg0KPg0KPiBPUg0KPg0KPiAvcmVzdGNvbmYvZGF0YS9leGFtcGxlOmV4YW1wbGUgL2E/d2hl cmU94oCZYj0xDQo+DQo+DQo+DQo+IEJUVzogd2hlcmUgcGFyYW1ldGVyIGlzIG5vdCBjbGVhcmx5 IGRlZmluZWQgaW4NCj4gZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLWNvbGxlY3Rpb24tMDAu dHh0DQo+IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXJl c3Rjb25mLWNvbGxlY3Rpb24tMDAudHh0Pg0KPg0KDQpZZXMgLS0gdGhpcyBkcmFmdCBuZWVkcyBt b3JlIHdvcmsgdG8gYmUgY29tcGxldGVkLg0KUGxlYXNlIHNlbmQgcmV2aWV3IGNvbW1lbnRzIG9u IHRoaXMgZHJhZnQgdG8gdGhlIFdHLg0KDQoNCkFuZHkNCg0KDQo+IOKAmQ0KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4g5Yav5YayDQo+IOWNjuS4uuaKgOacr+aciemZkOWF rOWPuCBIdWF3ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLg0KPiBbaW1hZ2U6IENvbXBhbnlfbG9n b10NCj4NCj4gUGhvbmU6DQo+IEZheDoNCj4gTW9iaWxlOiAxODUxOTExNzMxNg0KPiBFbWFpbDog ZnJhbmsuZmVuZ2Nob25nQGh1YXdlaS5jb20NCj4g5Zyw5Z2A77ya5Y2X5Lqs5biC6L2v5Lu25aSn 6YGTMTAx5Y+35Y2O5Li65Y2X5Lqs5Z+65ZywIOmCrue8lu+8mjIxMDAwMQ0KPiBIdWF3ZWkgVGVj aG5vbG9naWVzIENvLiwgTHRkLg0KPg0KPiBodHRwOi8vd3d3Lmh1YXdlaS5jb20NCj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+IOacrOmCruS7tuWPiuWFtumZhOS7tuWQq+ac ieWNjuS4uuWFrOWPuOeahOS/neWvhuS/oeaBr++8jOS7hemZkOS6juWPkemAgee7meS4iumdouWc sOWdgOS4reWIl+WHuueahOS4quS6uuaIlue+pOe7hOOAguemgQ0KPiDmraLku7vkvZXlhbbku5bk urrku6Xku7vkvZXlvaLlvI/kvb/nlKjvvIjljIXmi6zkvYbkuI3pmZDkuo7lhajpg6jmiJbpg6jl iIblnLDms4TpnLLjgIHlpI3liLbjgIHmiJbmlaPlj5HvvInmnKzpgq7ku7bkuK0NCj4g55qE5L+h 5oGv44CC5aaC5p6c5oKo6ZSZ5pS25LqG5pys6YKu5Lu277yM6K+35oKo56uL5Y2z55S16K+d5oiW 6YKu5Lu26YCa55+l5Y+R5Lu25Lq65bm25Yig6Zmk5pys6YKu5Lu277yBDQo+IFRoaXMgZS1tYWls IGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJv bQ0KPiBIVUFXRUksIHdoaWNoDQo+IGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3Ig ZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLg0KPiBBbnkgdXNlIG9mIHRoZQ0K PiBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0 IG5vdCBsaW1pdGVkIHRvLA0KPiB0b3RhbCBvciBwYXJ0aWFsDQo+IGRpc2Nsb3N1cmUsIHJlcHJv ZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZQ0KPiBp bnRlbmRlZA0KPiByZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhp cyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZQ0KPiBub3RpZnkgdGhlIHNlbmRlciBieQ0KPiBwaG9u ZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0IQ0KPg0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBOZXRjb25mIG1haWxpbmcgbGlz dA0KPiBOZXRjb25mQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0Y29uZg0KPg0KPg0K --001a114730c0af3018052384f8aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Nov 1, 2015 at 5:44 PM, fengchong (C) <frank.fengchon= g@huawei.com> wrote:

=C2=A0

Hi,

=C2=A0 YANG module is list belo= w;

=C2=A0 List a {

Ke= y name;

Le= af name {

= =E2=80=A6

}<= u>

=C2=A0

Le= af b {

= =C2=A0=C2=A0 =E2=80=A6

}<= u>

=C2=A0

Le= af c {

= =C2=A0 =E2=80=A6

}<= u>

=C2=A0 }

=C2=A0

=C2=A0

=C2=A0 How can I get all data o= f list a with b =3D 1 ?

=C2=A0

/restconf/data/example:example = /a?b=3D1


You cannot = do this in RESTCONF (yet)
=C2=A0

=C2=A0

OR

/restconf/data/example:example = /a?where=3D=E2=80=99b=3D1

=C2=A0

BTW: where parameter is not cle= arly defined in
draft-ietf-netconf-restconf-collection-00.txt


Yes -- this draft needs more work to b= e completed.
Please send review comments on this draft to the WG.=


Andy
=C2=A0
=

<= /u>

=E2=80=99<= /p>

=E5=86=AF=E5=86=B2
=E5=8D=8E=E4=B8=BA=E6=8A=80=E6=9C=AF=E6=9C=89=E9=99=90=E5=85=AC=E5= =8F=B8 Huawei Technologies Co., Ltd.
3D"Company_logo"

Phone:
Fax:
Mobile: 18519117316
Email: fran= k.fengchong@huawei.com
=E5=9C=B0=E5=9D=80=EF=BC=9A=E5=8D=97=E4=BA=AC=E5= =B8=82=E8=BD=AF=E4=BB=B6=E5=A4=A7=E9=81=93101= =E5=8F=B7=E5=8D=8E=E4=B8=BA=E5=8D=97=E4=BA=AC=E5=9F=BA=E5=9C=B0 =E9=82=AE= =E7=BC=96=EF=BC=9A210001
Huawei Technologies Co., Ltd.

http://www.huawei.com

=E6=9C=AC=E9=82=AE=E4=BB=B6=E5=8F= =8A=E5=85=B6=E9=99=84=E4=BB=B6=E5=90=AB=E6=9C=89=E5=8D=8E=E4=B8=BA=E5=85=AC= =E5=8F=B8=E7=9A=84=E4=BF=9D=E5=AF=86=E4=BF=A1=E6=81=AF=EF=BC=8C=E4=BB=85=E9= =99=90=E4=BA=8E=E5=8F=91=E9=80=81=E7=BB=99=E4=B8=8A=E9=9D=A2=E5=9C=B0=E5=9D= =80=E4=B8=AD=E5=88=97=E5=87=BA=E7=9A=84=E4=B8=AA=E4=BA=BA=E6=88=96=E7=BE=A4= =E7=BB=84=E3=80=82=E7=A6=81
=E6=AD=A2=E4=BB=BB=E4=BD=95=E5=85=B6=E4=BB=96=E4=BA=BA=E4=BB=A5=E4= =BB=BB=E4=BD=95=E5=BD=A2=E5=BC=8F=E4=BD=BF=E7=94=A8=EF=BC=88=E5=8C=85=E6=8B= =AC=E4=BD=86=E4=B8=8D=E9=99=90=E4=BA=8E=E5=85=A8=E9=83=A8=E6=88=96=E9=83=A8= =E5=88=86=E5=9C=B0=E6=B3=84=E9=9C=B2=E3=80=81=E5=A4=8D=E5=88=B6=E3=80=81=E6= =88=96=E6=95=A3=E5=8F=91=EF=BC=89=E6=9C=AC=E9=82=AE=E4=BB=B6=E4=B8=AD
=E7=9A=84=E4=BF=A1=E6=81=AF=E3=80=82=E5=A6=82=E6=9E=9C=E6=82=A8=E9= =94=99=E6=94=B6=E4=BA=86=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E6=82= =A8=E7=AB=8B=E5=8D=B3=E7=94=B5=E8=AF=9D=E6=88=96=E9=82=AE=E4=BB=B6=E9=80=9A= =E7=9F=A5=E5=8F=91=E4=BB=B6=E4=BA=BA=E5=B9=B6=E5=88=A0=E9=99=A4=E6=9C=AC=E9= =82=AE=E4=BB=B6=EF=BC=81
This e-mail and its attac= hments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!


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


--001a114730c0af3018052384f8aa-- --001a114730c0af301a052384f8ab Content-Type: image/jpeg; name="image001.jpg" Content-Disposition: inline; filename="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: cd7fa02d31b20db1_0.0.1 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --001a114730c0af301a052384f8ab-- From nobody Mon Nov 2 09:16:02 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6BB1A0047 for ; Mon, 2 Nov 2015 09:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzxlqHprsMW4 for ; Mon, 2 Nov 2015 09:15:59 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 6B4111A0094 for ; Mon, 2 Nov 2015 09:15:59 -0800 (PST) Received: by lfbf136 with SMTP id f136so50603891lfb.0 for ; Mon, 02 Nov 2015 09:15:57 -0800 (PST) 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:date:message-id:subject:from:to :cc:content-type; bh=u1MTCKl+iOZRyOJdX+1v3lTRyTkbxb05RQBe0t7nGQc=; b=TVolNJ2i6Jbrjf4vsolyW+rWTG1GcyIJIYaFA5oUbWG4FiMF6Hrn/I+lhwJrkFg00a J4dqcOMCLdRTM81IlRSeO6ypqfklDbuebdFCMYagSj77h22EmPkMp9g9FkbXe4qC+AAF dmEpIGciadYLGklxLBSkoZvu/zZEvfGlXHnaj/O7NtqhgSFMGadcr/vx2lKFQ0ImNwFK GkywrHbK6eFOGt6M6TgxBhyMcePuFWmhBU6DKzjrfpS4DCo+GERkPTDA2usb4rfvqWso oLiKhIbt+LYLSDV7iAbTNMYsUQodvcLBfJXCps6VxJ52TZfYX0J5vD6uscsYoRrsL7Jl uMIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=u1MTCKl+iOZRyOJdX+1v3lTRyTkbxb05RQBe0t7nGQc=; b=WLNEsRl7AwdErvsy967cKEJivvaAXU49ropbbkBJUuzLIITxPmJwa0Jc0s1XURQWhp VNuOcX/uyr4tSmEDlz9PGOBBm0CjPkUChuRfnZA6Jkk9RiMExrK5hQmnBEsgicU8wWKV 9QXFHf9gabluY625H9iaJgv2TlQrNH+CoxMqLc6F4FzJsx5N+6BdH8vvOA/vmdzPLMIw R/cX1J+ENPejyVDx6GXl66NGp+PQrHm2iG5ewOW93LH5NFcQgu7wFHvfuxy9TlQYGBUa ZvOg5jKdCYLwMTqApEXJdqTaXGzv2jL/I7MketuLsrjC4Hz4JzSLJGTX+4k5apdXRdsG 0ccw== X-Gm-Message-State: ALoCoQnuQ2Hsvbb2FoX6p38ErmvYVv2Dawksx+D8ne2JAMYO6u1MmVoE6QDsVRNn9axMxRdkPcqn MIME-Version: 1.0 X-Received: by 10.25.143.82 with SMTP id r79mr6954506lfd.123.1446484557422; Mon, 02 Nov 2015 09:15:57 -0800 (PST) Received: by 10.112.144.106 with HTTP; Mon, 2 Nov 2015 09:15:57 -0800 (PST) In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A67220EA6@szxeml512-mbs.china.huawei.com> References: <991B70D8B4112A4699D5C00DDBBF878A67220EA6@szxeml512-mbs.china.huawei.com> Date: Mon, 2 Nov 2015 09:15:57 -0800 Message-ID: From: Andy Bierman To: Rohit R Ranade Content-Type: multipart/alternative; boundary=001a11401b1a37fdec052391eedc Archived-At: Cc: "a71831@notesmail.huawei.com" , "netconf@ietf.org" Subject: Re: [Netconf] Queries about notification in draft-ietf-netconf-restconf-07 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 17:16:01 -0000 --001a11401b1a37fdec052391eedc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Oct 30, 2015 at 10:58 PM, Rohit R Ranade wrote: > Hi All, > > > > In Section 6.3. Subscribing to Receive Notifications, > > =E2=80=9C > > The RESTCONF client can then use this URL value to start monitoring the > event stream: > > GET /streams/NETCONF HTTP/1.1 > > Host: example.com > > Accept: text/event-stream > > Cache-Control: no-cache > > Connection: keep-alive > > =E2=80=9D > > =C3=B0 This mentions about when the client can start getting the > notifications. > > > > > > Furthermore in Section 4.8.8. The "stop-time" Query Parameter, when > describing this parameter, > > =E2=80=9C > > If this parameter is not present, the notifications will continue until > the subscription is terminated. > > =E2=80=9D > > =C3=B0 This means that there is indeed a mechanism where the subscriptio= n can > be terminated. But in this draft I am not able to find the exact RESTCONF > request to be sent to stop receiving these notifications. > > > > So can you please provide the RESTCONF request that will unsubscribe the > events. > > IMO -- no Just drop the transport session and terminate the GET > > > With Regards, > > Rohit > > > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a11401b1a37fdec052391eedc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Oct 30, 2015 at 10:58 PM, Rohit R Ranade <= rohitrranade@h= uawei.com> wrote:

Hi All,<= u>

=C2=A0

In Section 6.3. Subscribing to Receive Notifications= ,

=E2=80=9C

The RESTCONF client can then use this URL value to s= tart monitoring the event stream:

GET /streams/NETCONF HTTP/1.1

Host: example.com

Accept: text/event-stream

Cache-Control: no-cache

Connection: keep-alive

=E2=80=9D

=C3=B0=C2=A0 This mentions about when the client can start g= etting the notifications.

=C2=A0

=C2=A0

Furthermore in Section 4.8.8. The "stop-time&qu= ot; Query Parameter, when describing this parameter,

=E2=80=9C

If this parameter is not present, the notifications = will continue until the subscription is terminated.

=E2=80=9D

=C3=B0=C2=A0 This means that there is indeed a mechanism whe= re the subscription can be terminated. But in this draft I am not able to f= ind the exact RESTCONF request to be sent to stop receiving these notificat= ions.

=C2=A0

So can you please provide the RESTCONF request that = will unsubscribe the events.


IMO -- no
<= div>
Just drop the transport session and terminate the GET



=C2=A0

=C2=A0

With Regards,

Rohit

=C2=A0


<= /div>

Andy
=C2=A0


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


--001a11401b1a37fdec052391eedc-- From nobody Wed Nov 4 05:26:03 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6191B2F3D; Wed, 4 Nov 2015 05:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVYUeG7nm4PW; Wed, 4 Nov 2015 05:26:00 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A79311B2F36; Wed, 4 Nov 2015 05:26:00 -0800 (PST) Received: from [147.229.12.223] (pckrejci.fit.vutbr.cz [147.229.12.223]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 3EF77ED475A; Wed, 4 Nov 2015 14:25:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1446643558; bh=OwKcjU/S9VJvArmEB/lxytxQ9WC91kQlzG0pxiToNrQ=; h=From:Subject:To:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=CmvdQwoHqKftlRjNtx12kH1Nko2duC0ZMZw5FXln237U60EhO/PK1PhwRsAWSntQE pNF8IkQ9/ZrbJO6knlOxAMlP3eIMP6llVPYss3w7SyTcsTDWqxTHZtQPDvg4b4+jMr FHlJHTZnP9qTAG4bDd9Wztlt+gsLoZ5U7XtZq6Z0= From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= X-Enigmail-Draft-Status: N1110 To: "netconf@ietf.org" , "netmod@ietf.org" Message-ID: <563A0765.9040607@cesnet.cz> Date: Wed, 4 Nov 2015 14:25:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Netconf] libyang - open source YANG library in C X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 13:26:03 -0000 Hi all, as a side effect of evolving our libnetconf library, we've developed stan= dalone libyang library for parsing and validating YANG schemas and instan= ce data. It further allows callers to work with schemas and instance data= via libyang tree structures and various functions. The library is availa= ble at github [1] under BSD license. Currently, the library is able to re= ad and validate schemas in YIN format (YANG support is under development)= and instance data in XML and JSON formats (being one the last features, = JSON parser is available only in devel branch right now). To demonstrate = features of the library, there is a simple tool called yanglint (with sim= ilar functions as pyang). Despite it currently supports only YANG 1.0, in= future we plan to add also support for 1.1. I believe that you will find it useful and I would like to ask WG chairs = to add information about libyang to the list of NETCONF/YANG implementati= ons in the NETCONF Wiki [2] [1] - https://github.com/CESNET/libyang [2] - https://trac.tools.ietf.org/wg/netconf/trac/wiki Best regards, Radek Krejci From nobody Wed Nov 4 18:25:09 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11ABF1B38ED for ; Wed, 4 Nov 2015 18:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAtIdZAKkvrv for ; Wed, 4 Nov 2015 18:25:06 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (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 82BBD1B38EB for ; Wed, 4 Nov 2015 18:25:06 -0800 (PST) Received: by padhx2 with SMTP id hx2so63196520pad.1 for ; Wed, 04 Nov 2015 18:25:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=bvovJ+QIOH2DfPsmNT2NOZZWVZ0NMOPu/71M/7Oa3qw=; b=Bqo5XraX5DtHP9t+SHRBrSXHZnW/xRt7TgcSnHUeRZlvEPckbGFl4vJiORSyvlsqH2 E9JOpJ2EUJVurd8jRnTdVod+hJpgu/jYbWgudkJfZhR0m15fEiWBhrmtF9d+BrWK1t2L 0MWwuszO4EXaGnqaiXi6wmAOrPxvVmszXkNhf9Etbo8MVgCYt5HlyuFyjee5tLW0lJwV C2XgpVCUraZFKALJZesRT6fm/YLMgJ7ZioSSXbtA1enp3JJWvOB3FbFpdgzki+8piZXe Mtgl5tqvTh9l5VXSFroEdP8eWhstFdf7HKfmL56HhwQH1nxNyhKiflgurG4XYBCaZ5Pt we+g== X-Received: by 10.68.226.105 with SMTP id rr9mr6305495pbc.29.1446690306081; Wed, 04 Nov 2015 18:25:06 -0800 (PST) Received: from ?IPv6:2001:420:c0c8:1003::289? ([2001:420:c0c8:1003::289]) by smtp.gmail.com with ESMTPSA id db8sm4491550pad.43.2015.11.04.18.25.04 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 04 Nov 2015 18:25:05 -0800 (PST) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_BBFDCDB6-B005-4442-B292-621D236030A4" Message-Id: <248F4B51-A992-4D24-B1B9-37DE8D652DA5@gmail.com> Date: Thu, 5 Nov 2015 11:06:19 +0900 To: Netconf Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [Netconf] Need note takers and jabber scribes X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 02:25:08 -0000 --Apple-Mail=_BBFDCDB6-B005-4442-B292-621D236030A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We, the chairs would appreciate two folks to be note takers and one = jabber scribe for the meeting at 1. The etherpad link is http://etherpad.tools.ietf.org:9000/p/netconf-94 = . If you decide to volunteer, I will even buy coffee :-) Mahesh & Mehmet --Apple-Mail=_BBFDCDB6-B005-4442-B292-621D236030A4 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii We, the chairs would appreciate two folks to be note takers and one jabber scribe for the meeting at 1.

The etherpad link is http://etherpad.tools.ietf.org:9000/p/netconf-94.

If you decide to volunteer, I will even buy coffee :-)

Mahesh & Mehmet



--Apple-Mail=_BBFDCDB6-B005-4442-B292-621D236030A4-- From nobody Wed Nov 4 23:54:39 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0711B3BD1; Wed, 4 Nov 2015 23:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RE1qD81fDw0; Wed, 4 Nov 2015 23:54:35 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573E21B3BD0; Wed, 4 Nov 2015 23:54:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9495; q=dns/txt; s=iport; t=1446710075; x=1447919675; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=WY5zCg27YpLt9U1d4SO4VeFyfN8rY4K3CITAq3eimCs=; b=bnwArFjALUqkoOKbaY5KJ1pjyHhj3u5XrdMcU41XXAX/283O/hgMotDV dNIAAlmqNB8rn2bp5pISNbemS23+liJWAqJcQDxNsHcNP8bCUoDsMGA6I 7zoGwvdWhcLxqVfbl9/DP/rZ3OZYSm4N01Q7aRCbFGKSPyNNQHIA9cJ6P k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ABBQA0CjtW/xjFo0hehA5wtk6FB4QGIYVxAoIAAQEBAQEBgQuENgEBAwEjSwoBBQssFgQHAgIJAwIBAgFFBg0IAQGIIggNsHeQcgEBAQEBAQEBAgEBAQEBAQEBAQEBGIZUiSgRAYM5gUMFh0SGTIg4fIQhiAaBWkiDd4MCilOIU2OCRIFPL4QSgUEBAQE X-IronPort-AV: E=Sophos; i="5.20,246,1444694400"; d="scan'208,217"; a="56265673" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 05 Nov 2015 07:54:28 +0000 Received: from [10.70.231.159] (tky-vpn-client-231-159.cisco.com [10.70.231.159]) by bgl-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tA57sRWh019242; Thu, 5 Nov 2015 07:54:27 GMT To: Netconf References: <5620C26D.7050202@cisco.com> From: Benoit Claise Message-ID: <563B0B32.4000801@cisco.com> Date: Thu, 5 Nov 2015 16:54:26 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5620C26D.7050202@cisco.com> Content-Type: multipart/alternative; boundary="------------080807020804020208000504" Archived-At: Cc: Barry Leiba , netconf-ads@ietf.org Subject: [Netconf] Consensus on draft-leiba-netmod-regpolicy-update-00 (was: Re: On the registration policy for the NETCONF Capability URNs registry) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 07:54:38 -0000 This is a multi-part message in MIME format. --------------080807020804020208000504 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, During the NETCONF meeting today, there was no objection to progressing the draft https://tools.ietf.org/html/draft-leiba-netmod-regpolicy-update-00. I would like to confirm consensus on the list with this email. The one sentence exec summary is: This document proposes that the registration policy for the NETCONF Capability URNs registry is lowered from Standards Action to IETF review, so that a document such as draft-mm-netconf-time-capability-09 can register a new entry. The plan is to progress draft-leiba-netmod-regpolicy-update-00 as AD sponsor in 2 weeks from now. Regards, Benoit > Dear all, > > https://tools.ietf.org/html/draft-leiba-netmod-regpolicy-update-00 > > This document, which updates the NETCONF Capability URNs registry > policy, requires the process defined in RFC 2026. This means that it > needs to be discussed, reviewed by the responsible AD, given an > IETF-wide last call, and reviewed and approved by the IESG. > > I hope that it can go fairly quickly, as it's a simple action. > Therefore, I propose to keep this document as an individual > submission, which I will AD sponsor. However, neither Bary nor I are > going to push this ahead against the working group's opposition. > > So it's time to speak up if you disagree with that policy change. > A final consensus call will be made during the NETCONF meeting in > Yokohama. > > Regards, Benoit (OPS AD) > >> For any who haven't followed it, we had a discussion about the >> experimental document draft-mm-netconf-time-capability, which >> registers a NETCONF capability URN. Here's my last comment on the >> point, after I cleared my DISCUSS ballot: >> >> ---------- >> The registration policy for the NETCONF Capability URNs registry is >> Standards Action, and this document, with Experimental status, does >> not meet the requirement that the registration come from a Standards >> Track RFC. This document cannot make that registration. >> >> After discussion about whether the IESG should make an exception in >> this case and allow the registration, I agree that it's the right >> thing to do for this document, so I've cleared my DISCUSS ballot on >> that point. >> >> But at the same time, it seems that the registration policy is too >> strict, and should be IETF Review, which allows the NETCONF working >> group to make the decision by getting IETF consensus on the >> registration -- there's no need to specifically require a Standards >> Track RFC. To that end, I've submitted an Internet draft, >> draft-leiba-netmod-regpolicy-update, which I ask the Network >> Operations AD to sponsor, in coordination with the NETCONF working >> group. >> ---------- >> >> I typo'ed the filename (made it "-netmod-" rather than "-netconf-"); >> sorry about that. In any case, the NETCONF working group should look >> at it and comment. It's straightforward, just changing the >> registration policy and explaining why. I don't expect there'll be >> controversy with it, but please do give it a review and comment, and >> let Benoît and Joel know if y'all think it's acceptable for one of >> them to AD-sponsor: >> https://datatracker.ietf.org/doc/draft-leiba-netmod-regpolicy-update/ >> >> Please keep me on CC for any discussion, so I'll see the messages, >> though I'll also keep an eye on the mailing list archive. >> >> Thanks, >> Barry, ART AD >> . >> > > . > --------------080807020804020208000504 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Dear all,

During the NETCONF meeting today, there was no objection to progressing the draft https://tools.ietf.org/html/draft-leiba-netmod-regpolicy-update-00.
I would like to confirm consensus on the list with this email.

The one sentence exec summary is: This document proposes that the registration policy for the NETCONF Capability URNs registry is lowered from Standards Action to IETF review, so that a document such as draft-mm-netconf-time-capability-09 can register a new entry.

The plan is to progress draft-leiba-netmod-regpolicy-update-00 as AD sponsor in 2 weeks from now.

Regards, Benoit

Dear all,

https://tools.ietf.org/html/draft-leiba-netmod-regpolicy-update-00

This document, which updates the NETCONF Capability URNs registry policy, requires the process defined in RFC 2026. This means that it needs to be discussed, reviewed by the responsible AD, given an IETF-wide last call, and reviewed and approved by the IESG.

I hope that it can go fairly quickly, as it's a simple action. Therefore, I propose to keep this document as an individual submission, which I will AD sponsor.  However, neither Bary nor I are going to push this ahead against the working group's opposition.

So it's time to speak up if you disagree with that policy change.
A final consensus call will be made during the NETCONF meeting in Yokohama.

Regards, Benoit (OPS AD)

For any who haven't followed it, we had a discussion about the
experimental document draft-mm-netconf-time-capability, which
registers a NETCONF capability URN.  Here's my last comment on the
point, after I cleared my DISCUSS ballot:

----------
The registration policy for the NETCONF Capability URNs registry is
Standards Action, and this document, with Experimental status, does
not meet the requirement that the registration come from a Standards
Track RFC.  This document cannot make that registration.

After discussion about whether the IESG should make an exception in
this case and allow the registration, I agree that it's the right
thing to do for this document, so I've cleared my DISCUSS ballot on
that point.

But at the same time, it seems that the registration policy is too
strict, and should be IETF Review, which allows the NETCONF working
group to make the decision by getting IETF consensus on the
registration -- there's no need to specifically require a Standards
Track RFC.  To that end, I've submitted an Internet draft,
draft-leiba-netmod-regpolicy-update, which I ask the Network
Operations AD to sponsor, in coordination with the NETCONF working
group.
----------

I typo'ed the filename (made it "-netmod-" rather than "-netconf-");
sorry about that.  In any case, the NETCONF working group should look
at it and comment.  It's straightforward, just changing the
registration policy and explaining why.  I don't expect there'll be
controversy with it, but please do give it a review and comment, and
let Benoît and Joel know if y'all think it's acceptable for one of
them to AD-sponsor:
https://datatracker.ietf.org/doc/draft-leiba-netmod-regpolicy-update/

Please keep me on CC for any discussion, so I'll see the messages,
though I'll also keep an eye on the mailing list archive.

Thanks,
Barry, ART AD
.


.


--------------080807020804020208000504-- From nobody Thu Nov 5 02:07:03 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12FF1A046D for ; Thu, 5 Nov 2015 02:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fA5A7q6GI8Oh for ; Thu, 5 Nov 2015 02:06:58 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (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 AD6391A8BC4 for ; Thu, 5 Nov 2015 02:06:58 -0800 (PST) Received: by pabfh17 with SMTP id fh17so83573172pab.0 for ; Thu, 05 Nov 2015 02:06:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:content-transfer-encoding:from:content-type:message-id:date :cc:to:mime-version; bh=Vk9e6jBaxI57jRH8029MF4UKX5lBwQZRLtdywQzV5II=; b=VXBtQmz3fXsEeQQDC5Pn0ENsi0piPXVPsL4N/sAkWnATXWno4vk1N8X5tXA1Gbl7zH QNHusr78OaupG7AQa4INCTd4z4YGWGRsnzp9AC2HdFhtKS6B3h7nLPoJtapjQpYJlJ8I 1Y8/p8KcdHg23ymL9U1KSHT+LvzEBCXmsBmog1hqponKllUK/+8bnOeKRfg8jm5bUmIx ucBUHpQ/xXkAVC1z/ubfFCOJgqH/mR9yPPPuRpUvpC2AM5plOreA7qxLD78bKy0ba4AL AZyxtSv5+bUOx3JVq5famLyvLOYOYzTWIksaPAaJ7QAjzcJJM57Vz1zP6OApPBrcjBDN TDpw== X-Received: by 10.68.69.35 with SMTP id b3mr8558418pbu.22.1446718018365; Thu, 05 Nov 2015 02:06:58 -0800 (PST) Received: from ?IPv6:2001:c40::3080:545b:6b69:4fb6:7aea? (t20010c4000003080545b6b694fb67aea.v6.meeting.ietf94.jp. [2001:c40:0:3080:545b:6b69:4fb6:7aea]) by smtp.gmail.com with ESMTPSA id im9sm7023264pbc.1.2015.11.05.02.06.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Nov 2015 02:06:57 -0800 (PST) Content-Transfer-Encoding: 7bit From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary=Apple-Mail-ADCEC6C5-D915-49C8-9C00-0DF2D40ECF69 X-Mailer: iPad Mail (12B466) Message-Id: <2F8BB028-A741-4068-8F4F-4BEA0DB74B81@gmail.com> Date: Thu, 5 Nov 2015 19:06:55 +0900 To: Netconf , Benoit Claise Mime-Version: 1.0 (1.0) Archived-At: Subject: [Netconf] Summary and AIs from NETCONF WG meeting X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 10:07:01 -0000 --Apple-Mail-ADCEC6C5-D915-49C8-9C00-0DF2D40ECF69 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear Benoit, NETCONF WG, =20 Below is a summary and action items from the NETCONF WG session on November 5= , 2015 in Yokohama, Japan. =20 - We had approx. 70 participants in the 2 hour NETCONF session, - We reviewed the status of the WG, - We had a discussion on 8 chartered and 2 non-chartered documents, and the I= 2RS strawman protocol. =20 - Many thanks to the note takers via Etherpad and the jabber scribe. Etherpad notes are at: http://etherpad.tools.ietf.org:9000/p/netconf-94 =20 The session agenda is available at: https://www.ietf.org/proceedings/94/agen= da/agenda-94-netconf =20 Following is a summary of the discussion and the decisions taken per show of= hands. =20 This mail is at the same time to verify the discussion result and decisions f= rom the IETF 94 NETCONF session. If there is no strong objection we will act= or implement as discussed. =20 - There is no objection to publish the process described in draft-leiba-netm= od-regpolicy-update. It=E2=80=99ll be AD sponsored. =20 - Sue Hares gave a summary on the I2RS strawman proposal. As a next step I2R= S and NETCONF co-chairs will have a call and discuss further development. =20 - draft-ietf-netconf-yang-push had good progress. The draft has a dependency= on 5277bis and needs to reference it instead of redefining some parts. Curr= ently nobody is working on 5277bis. =20 - RESTCONF Protocol, YANG Patch Media Type, YANG Module Library: The three drafts will go to WGLC together. RESTCONF has 1 open and 1 new iss= ue. No questions and comments on YANG Patch Media Type. Open issues for YANG= library need to be discussed on the mailing list. RESTCONF has a dependency= on YANG 1.1 and YANG 1.1 depends on YANG library. The plan is to finish YAN= G 1.1 by December 1st. =20 - Server Configuration Model has the big issue with key chains to address. K= ent is working together with SAAG. Conclusion that splitting into two parts i= s not helpful. This will take some time to finalize. =20 - Zero Touch Provisioning has now the support of ANIMA WG and can be finaliz= ed soon. There are diverse operators who would like to implement and use. =20 - The non-chartered draft on Restconf subscription and HTTP push presented. D= iscussion on merging with netconf-yang-push or keep it separate will continu= e. A third option is to have a 3rd draft on the common part. Document organi= zation will be discussed on the mailing list. The charter definition covers t= his work. Based on show of hands, people in the room are in favor of doing t= his work, many in favor, nobody against. Once the document organization is a= greed draft will be adopted as WG item.=20 =20 Regards,=20 Mehmet & Mahesh=20 --Apple-Mail-ADCEC6C5-D915-49C8-9C00-0DF2D40ECF69 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Dear Benoit, NETCONF WG,

 

Below is a summary and action items from th= e NETCONF WG session on November 5, 2015 in Yokohama, Ja= pan.

- We had approx. 70 participants in the 2 hour NETCONF sessi= on,

= - We reviewed the status of the WG,

- We had a discussion on 8 charte= red and 2 non-chartered documents, and the I2RS strawman protocol.=

&n= bsp;

http://etherpad.tools.ietf.org:9000/p/netconf-94

 

 

Following is a summary of the discussion and the decisions taken pe= r show of hands.

 

This= mail is at the same time to verify the discussion result and decisions from= the IETF 94 NETCONF session. If there is no strong objection we will act or imple= ment as discussed.

=  

- There i= s no objection to publish the process described in draft-leiba-netmod-regpol= icy-update. It=E2=80=99ll be AD sponsored.

 

- Sue Hares gave a summary on the I2RS strawman proposal. As a next= step I2RS and NETCONF co-chairs will have a call and discuss further develo= pment.

 

- draft-ietf-netconf-yang-= push had good progress. The draft has a dependency on 5277bis and needs to r= eference it instead of redefining some parts. Currently nobody is working on 5277b= is.

 

- RESTCONF Protocol, YANG Patch Media T= ype, YANG Module Library:

The three drafts will go to WGLC together. RESTCONF has 1 open and 1= new issue. No questions and comments on YANG Patch Media Type. Open issues f= or YANG library need to be discussed on the mailing list. RESTCONF has a dependency= on YANG 1.1 and YANG 1.1 depends on YANG library. The plan is to finish YAN= G 1.1 by December 1st.

 =

- Server Configuration Model has= the big issue with key chains to address. Kent is working together with SAA= G. Conclusion that splitting into two parts is not helpful. This will take s= ome time to finalize.

 

- Zero Tou= ch Provisioning has now the support of ANIMA WG and can be finalized soon. T= here are diverse operators who would like to implement and use.

 

- The non-chartered draft on Restconf subscrip= tion and HTTP push presented. Discussion on merging with netconf-yang-push o= r keep it separate will continue. A third option is to have a 3rd draft on t= he common part. Document organization will be discussed on the mailing list. <= /span>The charter d= efinition covers this work. Based on show of hands, people in the room are i= n favor of doing this work, many in favor, nobody against. Once the document organ= ization is agreed draft will be adopted as WG item. 

 

Regards, 
Mehmet & Mahesh 


= --Apple-Mail-ADCEC6C5-D915-49C8-9C00-0DF2D40ECF69-- From nobody Thu Nov 5 04:39:03 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4DED1B29B4 for ; Thu, 5 Nov 2015 04:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7GPgyEnw7y0 for ; Thu, 5 Nov 2015 04:39:00 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1231F1B29AF for ; Thu, 5 Nov 2015 04:39:00 -0800 (PST) Received: from localhost (dhcp-81-124.meeting.ietf94.jp [133.93.81.124]) by mail.tail-f.com (Postfix) with ESMTPSA id 507D11AE06E3; Thu, 5 Nov 2015 13:38:58 +0100 (CET) Date: Thu, 05 Nov 2015 21:38:56 +0900 (JST) Message-Id: <20151105.213856.860892441853478179.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <10624205.1443464224199.JavaMail.root@elwamui-milano.atl.sa.earthlink.net> References: <10624205.1443464224199.JavaMail.root@elwamui-milano.atl.sa.earthlink.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] restconf and namespaces and unique module names. X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 12:39:01 -0000 Hi Randy, Randy Presuhn wrote: > Hi - > > > From: Andy Bierman > > Sent: Sep 28, 2015 10:12 AM > > To: Randy Presuhn > > Cc: Netconf > > Subject: Re: [Netconf] restconf and namespaces and unique module names. > ... > > Doesn't the same situation exist in SNMP-land?The SMIv2 module uses > > import-by-name, not raw OIDs. > > Yes. It's a perfectly avoidable problem that Yang inherited from > SMI. The bug was introduced when SMI "subsetted" ASN.1 and > failed to preserve the option of referencing modules by OID. > > However, the problem is much less severe in SNMP-land, since > module names don't appear on the wire. In the very few cases > where one might be tempted to do such a thing, the module OID > is used. It *is* a problem for IMPORTS, but that's only a minor > tractable headache, since an outside-the-scope-of-standardization > mapping from module names to file names is needed anyway. > > > XML is more robust than JSON (is so many ways, but here wrt/ > > namespace).The client or server will only get the namespace > > in an XML message andthen needs to map that namespace to a > > module name. This will certainlyfail (if the wrong 'foo' is > > used) since the namespace URIs should be different. > > > > With JSON, each peer will just think the other is sending > > invalid data. > > This is in the *best* case. In the worst case, there might > be sufficient syntactic similarity between when the models > permit to allow an operation to succeed, even though the > intent/semantics understood by the endpoints could > be radically different. > > > I agree that this is a serious weakness.We rely on conventions > > where MUST is more appropriate.But in real operations, the module > > names need to be unique.If not, it will be reported as a bug to > > the vendor who createdthe duplicate module name. > > Agreed, this is essentially the case for "MUST" for uniqueness of > both enterprise and standard modules. When a "MUST" puts vendors > or operators in an untenable situation, it's time to revisit the > design assumptions of the specification. However, I'm not fully > convinced that things are so bad as to require replacement of > the naming mechanism, although that would be required to completely > eliminate all collisions. > > I'm more concerned about honesty in specification. Embracing JSON, > as you've detailed, brings more serious consequences for collisions. > The softest language I could support for module name collisions > would be something like "Use of enterprise modules with non-unique > names is NOT RECOMMENDED." But I'd still prefer a blanket "MUST be > unique", since that's the truth if things are to work correctly. When I went back to the text to do the edits, I realized that I'm not really sure that I understand what you meant. The original text is this: Developers of enterprise modules are RECOMMENDED to choose names for their modules that will have a low probability of colliding with standard or other enterprise modules, e.g., by using the enterprise or organization name as a prefix for the module name. Did you mean that we should add your proposed sentence at the end of this paragraph, or replace the text with it? I am thinking that maybe we instead can add "Within a server, all module names MUST be unique". /martin From nobody Thu Nov 5 04:54:54 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C077A1B2A10 for ; Thu, 5 Nov 2015 04:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Agqnn2Kdhk1z for ; Thu, 5 Nov 2015 04:54:50 -0800 (PST) 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 1835F1B2A05 for ; Thu, 5 Nov 2015 04:54:50 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D9BB38E5; Thu, 5 Nov 2015 13:54:48 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id k32WBUoTm8AV; Thu, 5 Nov 2015 13:54:47 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 5 Nov 2015 13:54:47 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6A2462003B; Thu, 5 Nov 2015 13:54:47 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id KQcc54QUtx3O; Thu, 5 Nov 2015 13:54:46 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B1A062004E; Thu, 5 Nov 2015 13:54:45 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A373E3878B8A; Thu, 5 Nov 2015 13:54:45 +0100 (CET) Date: Thu, 5 Nov 2015 13:54:45 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20151105125445.GA628@elstar.local> Mail-Followup-To: Martin Bjorklund , randy_presuhn@mindspring.com, netconf@ietf.org References: <10624205.1443464224199.JavaMail.root@elwamui-milano.atl.sa.earthlink.net> <20151105.213856.860892441853478179.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151105.213856.860892441853478179.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: randy_presuhn@mindspring.com, netconf@ietf.org Subject: Re: [Netconf] restconf and namespaces and unique module names. X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 12:54:54 -0000 On Thu, Nov 05, 2015 at 09:38:56PM +0900, Martin Bjorklund wrote: > Hi Randy, > > Randy Presuhn wrote: > > Hi - > > > > > From: Andy Bierman > > > Sent: Sep 28, 2015 10:12 AM > > > To: Randy Presuhn > > > Cc: Netconf > > > Subject: Re: [Netconf] restconf and namespaces and unique module names. > > ... > > > Doesn't the same situation exist in SNMP-land?The SMIv2 module uses > > > import-by-name, not raw OIDs. > > > > Yes. It's a perfectly avoidable problem that Yang inherited from > > SMI. The bug was introduced when SMI "subsetted" ASN.1 and > > failed to preserve the option of referencing modules by OID. > > > > However, the problem is much less severe in SNMP-land, since > > module names don't appear on the wire. In the very few cases > > where one might be tempted to do such a thing, the module OID > > is used. It *is* a problem for IMPORTS, but that's only a minor > > tractable headache, since an outside-the-scope-of-standardization > > mapping from module names to file names is needed anyway. > > > > > XML is more robust than JSON (is so many ways, but here wrt/ > > > namespace).The client or server will only get the namespace > > > in an XML message andthen needs to map that namespace to a > > > module name. This will certainlyfail (if the wrong 'foo' is > > > used) since the namespace URIs should be different. > > > > > > With JSON, each peer will just think the other is sending > > > invalid data. > > > > This is in the *best* case. In the worst case, there might > > be sufficient syntactic similarity between when the models > > permit to allow an operation to succeed, even though the > > intent/semantics understood by the endpoints could > > be radically different. > > > > > I agree that this is a serious weakness.We rely on conventions > > > where MUST is more appropriate.But in real operations, the module > > > names need to be unique.If not, it will be reported as a bug to > > > the vendor who createdthe duplicate module name. > > > > Agreed, this is essentially the case for "MUST" for uniqueness of > > both enterprise and standard modules. When a "MUST" puts vendors > > or operators in an untenable situation, it's time to revisit the > > design assumptions of the specification. However, I'm not fully > > convinced that things are so bad as to require replacement of > > the naming mechanism, although that would be required to completely > > eliminate all collisions. > > > > I'm more concerned about honesty in specification. Embracing JSON, > > as you've detailed, brings more serious consequences for collisions. > > The softest language I could support for module name collisions > > would be something like "Use of enterprise modules with non-unique > > names is NOT RECOMMENDED." But I'd still prefer a blanket "MUST be > > unique", since that's the truth if things are to work correctly. > > When I went back to the text to do the edits, I realized that I'm not > really sure that I understand what you meant. The original text is > this: > > Developers of enterprise modules are RECOMMENDED to choose names for > their modules that will have a low probability of colliding with > standard or other enterprise modules, e.g., by using the enterprise > or organization name as a prefix for the module name. > > Did you mean that we should add your proposed sentence at the end of > this paragraph, or replace the text with it? > > I am thinking that maybe we instead can add "Within a server, all > module names MUST be unique". There are two things here - the uniqueness requirement and a recommendation how to produce likely unique names. I think adding "Within a server, all module names MUST be unique" is important and should be done. I would also like to keep the recommendation how to produce likely unique names since this actually helps people and more importantly organization to understand what they are supposed to do. /js (as contributor) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Nov 5 05:51:31 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3531B2CAD; Thu, 5 Nov 2015 05:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.061 X-Spam-Level: X-Spam-Status: No, score=-0.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_42=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6BaOhaZ-yKQ; Thu, 5 Nov 2015 05:51:28 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 197C51B2C64; Thu, 5 Nov 2015 05:51:28 -0800 (PST) Received: from [192.168.11.215] (i223-218-131-39.s41.a014.ap.plala.or.jp [223.218.131.39]) by mail.nic.cz (Postfix) with ESMTPSA id EDF29198D4A; Thu, 5 Nov 2015 14:51:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1446731486; bh=UhIHn78t6vnC7mzZqdrTTOP4KzkLF+Xova53h9UC31U=; h=From:Date:To; b=k2Rbl94J7p0Dvly88Xe5seqTHi2IhosQ7tfrwxmw5X9UFdumn00EfJsuSSMGUB4Xa A8R968wiX+SXgSAIwlsu8Zn8Ej5NGzxT1/DgrtwKOy2amMq4cYyysOSWOl90NiBDXq byIMx2FVmKzoEg1uiOS4ZRCDS7RRKM9T3OXtscPo= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Ladislav Lhotka In-Reply-To: <563B0B32.4000801@cisco.com> Date: Thu, 5 Nov 2015 22:51:20 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <59C19652-FC97-462E-95FD-C8F22EF729A5@nic.cz> References: <5620C26D.7050202@cisco.com> <563B0B32.4000801@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.3096.5) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Barry Leiba , Netconf , netconf-ads@ietf.org Subject: Re: [Netconf] Consensus on draft-leiba-netmod-regpolicy-update-00 (was: Re: On the registration policy for the NETCONF Capability URNs registry) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 13:51:30 -0000 > On 05 Nov 2015, at 16:54, Benoit Claise wrote: >=20 > Dear all, >=20 > During the NETCONF meeting today, there was no objection to = progressing the draft = https://tools.ietf.org/html/draft-leiba-netmod-regpolicy-update-00. > I would like to confirm consensus on the list with this email. >=20 > The one sentence exec summary is: This document proposes that the = registration policy for the NETCONF Capability URNs registry is lowered = from Standards Action to IETF review, so that a document such as = draft-mm-netconf-time-capability-09 can register a new entry. >=20 > The plan is to progress draft-leiba-netmod-regpolicy-update-00 as AD = sponsor in 2 weeks from now. Support. Lada >=20 > Regards, Benoit >=20 >> Dear all,=20 >>=20 >> https://tools.ietf.org/html/draft-leiba-netmod-regpolicy-update-00=20 >>=20 >> This document, which updates the NETCONF Capability URNs registry = policy, requires the process defined in RFC 2026. This means that it = needs to be discussed, reviewed by the responsible AD, given an = IETF-wide last call, and reviewed and approved by the IESG.=20 >>=20 >> I hope that it can go fairly quickly, as it's a simple action. = Therefore, I propose to keep this document as an individual submission, = which I will AD sponsor. However, neither Bary nor I are going to push = this ahead against the working group's opposition.=20 >>=20 >> So it's time to speak up if you disagree with that policy change.=20 >> A final consensus call will be made during the NETCONF meeting in = Yokohama.=20 >>=20 >> Regards, Benoit (OPS AD)=20 >>=20 >>> For any who haven't followed it, we had a discussion about the=20 >>> experimental document draft-mm-netconf-time-capability, which=20 >>> registers a NETCONF capability URN. Here's my last comment on the=20= >>> point, after I cleared my DISCUSS ballot:=20 >>>=20 >>> ----------=20 >>> The registration policy for the NETCONF Capability URNs registry is=20= >>> Standards Action, and this document, with Experimental status, does=20= >>> not meet the requirement that the registration come from a Standards=20= >>> Track RFC. This document cannot make that registration.=20 >>>=20 >>> After discussion about whether the IESG should make an exception in=20= >>> this case and allow the registration, I agree that it's the right=20 >>> thing to do for this document, so I've cleared my DISCUSS ballot on=20= >>> that point.=20 >>>=20 >>> But at the same time, it seems that the registration policy is too=20= >>> strict, and should be IETF Review, which allows the NETCONF working=20= >>> group to make the decision by getting IETF consensus on the=20 >>> registration -- there's no need to specifically require a Standards=20= >>> Track RFC. To that end, I've submitted an Internet draft,=20 >>> draft-leiba-netmod-regpolicy-update, which I ask the Network=20 >>> Operations AD to sponsor, in coordination with the NETCONF working=20= >>> group.=20 >>> ----------=20 >>>=20 >>> I typo'ed the filename (made it "-netmod-" rather than "-netconf-");=20= >>> sorry about that. In any case, the NETCONF working group should = look=20 >>> at it and comment. It's straightforward, just changing the=20 >>> registration policy and explaining why. I don't expect there'll be=20= >>> controversy with it, but please do give it a review and comment, and=20= >>> let Beno=C3=AEt and Joel know if y'all think it's acceptable for one = of=20 >>> them to AD-sponsor:=20 >>> = https://datatracker.ietf.org/doc/draft-leiba-netmod-regpolicy-update/=20 >>>=20 >>> Please keep me on CC for any discussion, so I'll see the messages,=20= >>> though I'll also keep an eye on the mailing list archive.=20 >>>=20 >>> Thanks,=20 >>> Barry, ART AD=20 >>> .=20 >>>=20 >>=20 >> .=20 >>=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Nov 5 09:39:59 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA7D1B31A8 for ; Thu, 5 Nov 2015 09:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdkbWGSpPfpf for ; Thu, 5 Nov 2015 09:39:56 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (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 6A7361B31AF for ; Thu, 5 Nov 2015 09:39:45 -0800 (PST) Received: by lbbwb3 with SMTP id wb3so40782674lbb.1 for ; Thu, 05 Nov 2015 09:39:43 -0800 (PST) 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:date:message-id:subject:from:to :cc:content-type; bh=qxomYvojLQhXAfAneAo1+6OgQ848tYWo8IInXUlzBb8=; b=fAepTwK4FD6AiEM+WDmNE/KSQBhVvay+XKgPeJrmu9ca9tVo9kqVc/gS5TUcnrU2jl rgSTFaklUQBxVO5sHHBRGey7u1VJ4/0PUCv77QXWmLQl1G51N5F+o1J/ZmZYQSe2SVYq qvote5B4QcN7b9rCD8NFglip0Dk7mUCDTHPnU2B7kEFkkvHAkbRUBuVLHRFPas2ujw71 qKzoOTTivxLUCm1vWHsSf+XKkmdOuqMQdKjti2tLoYpw+fwuTcVrHCQ3Dp5dvqnMhLg8 0wFXUoVHmvfqcH1b8Klm+y0u5oOlzX/JKQOJrsy25Be8dV9FYp43g7tztUERULIcXIAF DeUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qxomYvojLQhXAfAneAo1+6OgQ848tYWo8IInXUlzBb8=; b=NeBlAE49bLM75NiHYGp8XCuUEc4Y1Aik9eYJZpOwZ2hug7ABJuWU/Nqo+eBecXUl62 6cntT/EUU9fT4WQ1divx8ygKX/l6P0u4rXPQ75mdP5FikH2H2OKY22mUSyInfkzU8Jlz VgBQ/uJmtueWT7boKqE/nhK78EKVOc/mciHWNdJw7j9qjhGaKLxG6LANowshLyRfW0vA JoGaixd3CR98eo1Z2jBVGY0VThbLmxwmm9UOX2O3r3emgrZXE+hxwzpP2dP3FKLCOeeZ d7Q5fpYGePpdkMyWuNk3Bf85LBa33NXvc27+zLbGxakE14asOiz4NosBZJLaHxx5DHK1 tolA== X-Gm-Message-State: ALoCoQmV1ObWyHetQbO5OqAhHrEpdspt1phwh52Yh98d5C43lrhwqk72gyf1zUbU+Z+Z/HdgVCbM MIME-Version: 1.0 X-Received: by 10.112.161.168 with SMTP id xt8mr4509750lbb.88.1446745183466; Thu, 05 Nov 2015 09:39:43 -0800 (PST) Received: by 10.112.144.106 with HTTP; Thu, 5 Nov 2015 09:39:43 -0800 (PST) In-Reply-To: <1AD4E3EE8900414DA099DB2732403B928B8F2154@ex-mb1.corp.adtran.com> References: <1AD4E3EE8900414DA099DB2732403B928B8DE6C6@ex-mb1.corp.adtran.com> <1AD4E3EE8900414DA099DB2732403B928B8F2154@ex-mb1.corp.adtran.com> Date: Thu, 5 Nov 2015 09:39:43 -0800 Message-ID: From: Andy Bierman To: NILS FISCHBECK Content-Type: multipart/alternative; boundary=001a11c3cb36bdd1860523ce9c87 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] Requesting lists in a container via RestConf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 17:39:58 -0000 --001a11c3cb36bdd1860523ce9c87 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Nov 5, 2015 at 7:06 AM, NILS FISCHBECK wrote: > In section 4.3 of the RestConf standard a GET example is given for /restc= onf/data/example-jukebox:jukebox/library/artist=3DFoo%20Fighters/album > > In this example album is a list inside the artist resource. Is this reque= st really valid and if yes, how would an XML response look like? > > > > Currently it returns in the example one structure > > > > Wasting Light > > > > But how would it look like for multiple albums? > > > In JSON, the server could just return an array of 'album'. In XML, multiple albums would be invalid. This is the reason the RESTCONF Collections draft was created. The plan in the collections draft is to return a "collection" container in both XML and JSON. I know Lada does not like adding an extra container in JSON. I prefer for the client to parse the same structure in either XML or JSON. The client would send an Accept header for application/yang.collection+{xml | json} and the target resource needs to point at a list. Then the server will return this collection container. Is the draft right in this case, was in the draft rather meant that > album=3DWasting%20Light was to be requested and requesting lists without > using the fields query is not possible? > > > I think we should change the example to add the key for album. I think this was the intent. > Regards > > Nils > > > Andy > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Montag, 2. November 2015 02:07 > *To:* NILS FISCHBECK > *Cc:* netconf@ietf.org > *Subject:* Re: [Netconf] Requesting lists in a container via RestConf > > > > > > > > On Thu, Oct 22, 2015 at 12:14 AM, NILS FISCHBECK < > NILS.FISCHBECK@adtran.com> wrote: > > Suppose we have in a YANG file > > > > container jukebox { > > list artist { > > key name; > > leaf name {..} > > // other leafs > > } > > list playlist { > > key name; > > leaf name {..} > > // other leafs > > } > > } > > > > How can I request using RestConf all artists but not all playlists > (because there are so many)? > > More precise: If I request with a GET > > > > /restconf/data/example-jukebox:jukebox/artist (without any specific key) > > > > > > > > See the "fields" query parameter > > > > > > what is the result in XML and JSON and is it a valid request? > > > > Regards > > Nils > > > > ADTRAN GmbH, Siemensallee 1, 17489 Greifswald, GERMANY > > Office: +49 3834 5352 870 > > Cell: +49 170 632 8819 > > Sitz der Gesellschaft: Berlin / Registered office: Berlin > > Registergericht: Berlin / Commercial registry: Amtsgericht Charlottenburg= , > HRB 135656 B > > Gesch=C3=A4ftsf=C3=BChrung / Managing Directors: Michael K. Foliano, Jame= s D. > Wilson, Jr., Dr. Eduard Scheiterer > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > --001a11c3cb36bdd1860523ce9c87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Nov 5, 2015 at 7:06 AM, NILS FISCHBECK <NILS.FISCHBECK= @adtran.com> wrote:
In section 4.3 of the RestConf standard a GET e=
xample is given for /restconf/data/example-jukebox:jukebox/library/artist=
=3DFoo%20Fighters/album
In this example album is a list inside the arti=
st resource. Is this request really valid and if yes, how would an XML resp=
onse look like?
=C2=A0
Currently it returns in the example one structu=
re
<album xmlns=3D"http://example.com/ns/example-=
jukebox">
=C2=A0=C2=A0=C2=A0 <name>Wasting Light<=
;/name>

</album><= /span>

But how would it look like fo= r multiple albums?

=C2=A0



In JSON, the server = could just return an array of 'album'.
In XML, multiple a= lbums would be invalid.
This is the reason the RESTCONF Collectio= ns draft was created.

The plan in the collecti= ons draft is to return a "collection" container in
both= XML and JSON.=C2=A0 I know Lada does not like adding an extra
co= ntainer in JSON.=C2=A0 I prefer for the client to parse the same structure<= /div>
in either XML or JSON.

The client would = send an Accept header for application/yang.collection+{xml | json}
and the target resource needs to point at a list. Then the server will re= turn this
collection container.


Is the draft right in this ca= se, was in the draft rather meant that album=3DWasting%20Light was to be re= quested and requesting lists without using the fields query is not possible?

=C2=A0



I think we should ch= ange the example to add the key for album.
I think this was the i= ntent.

=C2=A0

Regards<= /p>

Nils

=C2=A0


Andy

=C2= =A0
<= div>

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Montag, 2. November 2015 02:07
To: NILS FISCHBECK
Cc: netconf@ie= tf.org
Subject: Re: [Netconf] Requesting lists in a container via RestConf<= u>

=C2=A0

=C2=A0

=C2=A0

On Thu, Oct 22, 2015 at 12:14 AM, NILS FISCHBECK <= ;NILS.FISCHB= ECK@adtran.com> wrote:

Suppose we have in a YANG file<= /span>

=C2=A0

container jukebox {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 list artist {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 key name;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf name {..}

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // other leafs

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 list playlist {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 key name;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf name {..}

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // other leafs

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }

}

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0

How can I request using RestCon= f all artists but not all playlists (because there are so many)?<= /u>

More precise: If I request with= a GET

=C2=A0

/restconf/data/example-jukebox:= jukebox/artist (without any specific key)

=C2=A0

=C2=A0

=C2=A0

See the "fields" query parameter=

=C2=A0

=C2=A0

what is the result in XML and J= SON and is it a valid request?

=C2=A0

Regards

Nils

=C2=A0

ADTRAN GmbH, Siemensallee 1, 17489 Greifswald, GERMANY

Office: +49 3834 5352 870

Cell: +49 170 632 8819

Sitz der Gesellschaft: Berlin / Registered office: Berlin

Registergericht: Berlin / Commercial registry: Amtsgericht Charlottenburg= , HRB 135656 B

Gesch=C3=A4ftsf=C3=BChrung / Managing Directors: Michael K. Foliano, Jame= s D. Wilson, Jr., Dr. Eduard Scheiterer

=C2=A0


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

=C2=A0


--001a11c3cb36bdd1860523ce9c87-- From nobody Thu Nov 5 14:09:55 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38AF1B3C3E for ; Thu, 5 Nov 2015 14:09:53 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whqkz-hHW6QX for ; Thu, 5 Nov 2015 14:09:51 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id A456A1B3C4D for ; Thu, 5 Nov 2015 14:09:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=OREZKBvzZ28/wCDEkSHHpQyIoEjn3kCKTrX5ZodW3c3FrvwN6Il0u9RPBui2G+DI; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.30] (helo=mswamui-chipeau.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ZuSj3-0006nL-9s for netconf@ietf.org; Thu, 05 Nov 2015 17:09:45 -0500 Received: from 76.254.51.191 by webmail.earthlink.net with HTTP; Thu, 5 Nov 2015 17:09:43 -0500 Message-ID: <11660805.1446761384214.JavaMail.root@mswamui-chipeau.atl.sa.earthlink.net> Date: Thu, 5 Nov 2015 14:09:43 -0800 (GMT-08:00) From: Randy Presuhn To: netconf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874d3f0892ff6d3ed52a12d2d97e229a986312f1fe39dff80350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.30 Archived-At: Subject: Re: [Netconf] restconf and namespaces and unique module names. X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 22:09:53 -0000 Hi - >From: Juergen Schoenwaelder >Sent: Nov 5, 2015 4:54 AM >To: Martin Bjorklund >Cc: randy_presuhn@mindspring.com, netconf@ietf.org >Subject: Re: [Netconf] restconf and namespaces and unique module names. > >On Thu, Nov 05, 2015 at 09:38:56PM +0900, Martin Bjorklund wrote: >> Hi Randy, >> >> Randy Presuhn wrote: >> > Hi - >> > >> > > From: Andy Bierman >> > > Sent: Sep 28, 2015 10:12 AM >> > > To: Randy Presuhn >> > > Cc: Netconf >> > > Subject: Re: [Netconf] restconf and namespaces and unique module names. >> > ... >> > > Doesn't the same situation exist in SNMP-land?The SMIv2 module uses >> > > import-by-name, not raw OIDs. >> > >> > Yes. It's a perfectly avoidable problem that Yang inherited from >> > SMI. The bug was introduced when SMI "subsetted" ASN.1 and >> > failed to preserve the option of referencing modules by OID. >> > >> > However, the problem is much less severe in SNMP-land, since >> > module names don't appear on the wire. In the very few cases >> > where one might be tempted to do such a thing, the module OID >> > is used. It *is* a problem for IMPORTS, but that's only a minor >> > tractable headache, since an outside-the-scope-of-standardization >> > mapping from module names to file names is needed anyway. >> > >> > > XML is more robust than JSON (is so many ways, but here wrt/ >> > > namespace).The client or server will only get the namespace >> > > in an XML message andthen needs to map that namespace to a >> > > module name. This will certainlyfail (if the wrong 'foo' is >> > > used) since the namespace URIs should be different. >> > > >> > > With JSON, each peer will just think the other is sending >> > > invalid data. >> > >> > This is in the *best* case. In the worst case, there might >> > be sufficient syntactic similarity between when the models >> > permit to allow an operation to succeed, even though the >> > intent/semantics understood by the endpoints could >> > be radically different. >> > >> > > I agree that this is a serious weakness.We rely on conventions >> > > where MUST is more appropriate.But in real operations, the module >> > > names need to be unique.If not, it will be reported as a bug to >> > > the vendor who createdthe duplicate module name. >> > >> > Agreed, this is essentially the case for "MUST" for uniqueness of >> > both enterprise and standard modules. When a "MUST" puts vendors >> > or operators in an untenable situation, it's time to revisit the >> > design assumptions of the specification. However, I'm not fully >> > convinced that things are so bad as to require replacement of >> > the naming mechanism, although that would be required to completely >> > eliminate all collisions. >> > >> > I'm more concerned about honesty in specification. Embracing JSON, >> > as you've detailed, brings more serious consequences for collisions. >> > The softest language I could support for module name collisions >> > would be something like "Use of enterprise modules with non-unique >> > names is NOT RECOMMENDED." But I'd still prefer a blanket "MUST be >> > unique", since that's the truth if things are to work correctly. >> >> When I went back to the text to do the edits, I realized that I'm not >> really sure that I understand what you meant. The original text is >> this: >> >> Developers of enterprise modules are RECOMMENDED to choose names for >> their modules that will have a low probability of colliding with >> standard or other enterprise modules, e.g., by using the enterprise >> or organization name as a prefix for the module name. >> >> Did you mean that we should add your proposed sentence at the end of >> this paragraph, or replace the text with it? >> >> I am thinking that maybe we instead can add "Within a server, all >> module names MUST be unique". > >There are two things here - the uniqueness requirement and a >recommendation how to produce likely unique names. I think adding >"Within a server, all module names MUST be unique" is important and >should be done. I would also like to keep the recommendation how to >produce likely unique names since this actually helps people and more >importantly organization to understand what they are supposed to do. Agreed. If we're stuck with the vulnerabilities of the current approach to naming, we should at least encourage folks to do something that will probably reduce the frequency of failures. Randy From nobody Thu Nov 5 17:17:19 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720761AD324 for ; Thu, 5 Nov 2015 17:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_jSvXbvsgQn for ; Thu, 5 Nov 2015 17:17:17 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (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 386161ACEE9 for ; Thu, 5 Nov 2015 17:17:17 -0800 (PST) Received: by lbbes7 with SMTP id es7so47720210lbb.2 for ; Thu, 05 Nov 2015 17:17:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks_com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=esvcbuGfJsfUdOPGi1Owa4cxviVVwLb98giH7pQUueM=; b=jIs3QQDob/IpXLzS+SyepRXiy223dCTQeuqywNRTKot4L9D+oRl+9VaWR3LrS7MLlt 7+b39FbdSxLzkd/HMw7FjU3ORM6EbRzdVKyX+Gz7NmnCUB8WP+9f6TuB98KsZicqK9lT TJZUEUp+aIQn3qbIcEyWPPUUV+L65Lft6+GolvLuQv3vJp1vEmhea9REN99Mu34i4e4E Pv2QS1oaP9IIRtsqjaRXJ7Hy0VJLEtLniYPc+T7W8ZQVgfjsHlCVUGCgxVLD2ThlHln/ 0pHHoGTVIeuwqMegmSYb5BmHumfdSFUhjSkZZwtXsEXTHJcvJGCrDlx5tJ6spNEwvKJw 8Lwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=esvcbuGfJsfUdOPGi1Owa4cxviVVwLb98giH7pQUueM=; b=JY9y7gB0c2wDNTRSyGxS3LMRbtnVw7m4cyBleZGSRFY388dYQ8XlAKlIXhxEzsuKYK JUAug0fQfa82hCeqsixUdlR5LHswOLYXe9LridZAC8jonTrSbQJ8lpycaEtNIOrUXUco 2FPvlWXnukeHtz/Niy5pTM3Vsr4KR9aZ6oLtiZCGNAHtQEtf3L1kMIqbFWbZYhRhqLAH YGMgXfQJrcsLLpDte4/m1AXksPN66+nSSdMvyZwIS9lKc3+pcOUaqoIWNeg4qCAUoVzl XjI5oQuxehrnO+9R3GIMVAtRk2VvpPDlK9ojcVHGUXRVcrFkSZk0hEVkD/fp1hKwErUA Gkng== X-Gm-Message-State: ALoCoQkjuYavxCqJsHFSfplFhY6lGip94W7wA5M7+2MpG/hzqsvZ8yKJmcBrn3UfAGUwaLTqc03I MIME-Version: 1.0 X-Received: by 10.112.135.136 with SMTP id ps8mr5284394lbb.38.1446772635404; Thu, 05 Nov 2015 17:17:15 -0800 (PST) Received: by 10.112.144.106 with HTTP; Thu, 5 Nov 2015 17:17:15 -0800 (PST) Date: Thu, 5 Nov 2015 17:17:15 -0800 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=089e0116071201216c0523d50140 Archived-At: Subject: [Netconf] RESTCONF #31: how to stop receiving notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 01:17:18 -0000 --089e0116071201216c0523d50140 Content-Type: text/plain; charset=UTF-8 Hi, This is a new RESTCONF issue. We did not invent Server-Sent Events, we just borrowed it. The SSE spec is silent on this issue, which suggests the transport session is simply dropped. IMO we should not be inventing something new here. Whatever SSE provides for this problem should be used. Andy --089e0116071201216c0523d50140 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

This is a new RESTCONF issue.
=
We did not invent Server-Sent Events, we just borrowed it.
T= he SSE spec is silent on this issue, which suggests
the transport= session is simply dropped.

IMO we should not be i= nventing something new here.
Whatever SSE provides for this probl= em should be used.


Andy
<= br>
--089e0116071201216c0523d50140-- From nobody Thu Nov 5 17:28:23 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527C31A016B for ; Thu, 5 Nov 2015 17:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqZ6_0oAdGCw for ; Thu, 5 Nov 2015 17:28:20 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DC9A61A0161 for ; Thu, 5 Nov 2015 17:28:19 -0800 (PST) Received: from localhost (unknown [210.164.9.13]) by mail.tail-f.com (Postfix) with ESMTPSA id 4EE031AE06E3; Fri, 6 Nov 2015 02:28:18 +0100 (CET) Date: Fri, 06 Nov 2015 10:28:15 +0900 (JST) Message-Id: <20151106.102815.1648328403704873394.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF #31: how to stop receiving notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 01:28:21 -0000 Andy Bierman wrote: > Hi, > > This is a new RESTCONF issue. > We did not invent Server-Sent Events, we just borrowed it. > The SSE spec is silent on this issue, which suggests > the transport session is simply dropped. > > IMO we should not be inventing something new here. > Whatever SSE provides for this problem should be used. I agree. /martin From nobody Fri Nov 6 00:16:13 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53ACE1B3781 for ; Fri, 6 Nov 2015 00:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRgm7YLRxRtq for ; Fri, 6 Nov 2015 00:16:10 -0800 (PST) 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 66F131B377F for ; Fri, 6 Nov 2015 00:16:10 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DA56110D9; Fri, 6 Nov 2015 09:16:08 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id KthDlfTT8WQh; Fri, 6 Nov 2015 09:16:08 +0100 (CET) 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; Fri, 6 Nov 2015 09:16:08 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 243F82003B; Fri, 6 Nov 2015 09:16:08 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gNWeaPd5J-IW; Fri, 6 Nov 2015 09:16:07 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F9BA2004E; Fri, 6 Nov 2015 09:16:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A761A3879319; Fri, 6 Nov 2015 09:16:05 +0100 (CET) Date: Fri, 6 Nov 2015 09:16:03 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20151106081601.GA3443@elstar.local> Mail-Followup-To: Andy Bierman , Netconf References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF #31: how to stop receiving notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 08:16:12 -0000 On Thu, Nov 05, 2015 at 05:17:15PM -0800, Andy Bierman wrote: > Hi, > > This is a new RESTCONF issue. > We did not invent Server-Sent Events, we just borrowed it. > The SSE spec is silent on this issue, which suggests > the transport session is simply dropped. > > IMO we should not be inventing something new here. > Whatever SSE provides for this problem should be used. > Did someone talk to HTTP/2 people? Does the push mechanism of HTTP/2 provide a mechanism that can be used instead of SSE on by HTTP/2 clients/servers? /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 Sat Nov 7 15:04:21 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E63C1B2E88 for ; Thu, 5 Nov 2015 07:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUcIKKHoFxxF for ; Thu, 5 Nov 2015 07:06:33 -0800 (PST) Received: from p02c11o145.mxlogic.net (p02c11o145.mxlogic.net [208.65.144.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECACF1B2AF9 for ; Thu, 5 Nov 2015 07:06:32 -0800 (PST) Received: from unknown [76.164.174.83] (EHLO p02c11o145.mxlogic.net) by p02c11o145.mxlogic.net(mxl_mta-8.5.0-3) with ESMTP id 8707b365.2b33f9421940.138710.00-537.390147.p02c11o145.mxlogic.net (envelope-from ); Thu, 05 Nov 2015 08:06:32 -0700 (MST) X-MXL-Hash: 563b70783ad8d7c9-1d1b96d937cf9d6bbd9b30e741ba3d2bd2f9d3a3 Received: from unknown [76.164.174.83] by p02c11o145.mxlogic.net(mxl_mta-8.5.0-3) over TLS secured channel with SMTP id 5707b365.0.138547.00-319.390018.p02c11o145.mxlogic.net (envelope-from ); Thu, 05 Nov 2015 08:06:31 -0700 (MST) X-MXL-Hash: 563b707709fd1db2-1e30e892c1d1b5880dda2a3da2de322b64c8ed86 Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc2.corp.adtran.com ([fe80::a019:449b:3f62:28e5%10]) with mapi id 14.03.0248.002; Thu, 5 Nov 2015 09:06:28 -0600 From: NILS FISCHBECK To: Andy Bierman Thread-Topic: [Netconf] Requesting lists in a container via RestConf Thread-Index: AQHRFQq7+Wjz1IVkz0Gy9+gOSLnRuZ6NifTQ Date: Thu, 5 Nov 2015 15:06:27 +0000 Message-ID: <1AD4E3EE8900414DA099DB2732403B928B8F2154@ex-mb1.corp.adtran.com> References: <1AD4E3EE8900414DA099DB2732403B928B8DE6C6@ex-mb1.corp.adtran.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.56.39] Content-Type: multipart/alternative; boundary="_000_1AD4E3EE8900414DA099DB2732403B928B8F2154exmb1corpadtran_" MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=OZyMD3jY c=1 sm=1 tr=0 a=5zDNsY1we+1mvVcp/5+1jQ==] X-AnalysisOut: [:117 a=5zDNsY1we+1mvVcp/5+1jQ==:17 a=eJNrpioGAAAA:8 a=YlVT] X-AnalysisOut: [AMxIAAAA:8 a=0Bvq39fDVXwA:10 a=xqWC_Br6kY4A:10 a=qtqOOiqGO] X-AnalysisOut: [CEA:10 a=A1X0JdhQAAAA:8 a=xskcdSivAAAA:8 a=48vgC7mUAAAA:8 ] X-AnalysisOut: [a=UeG5IPtIxEfladiOjHcA:9 a=QEXdDO2ut3YA:10 a=yMhMjlubAAAA:] X-AnalysisOut: [8 a=SSmOFEACAAAA:8 a=16qhLM0OzNgJt7T2:21 a=gKO2Hq4RSVkA:10] X-AnalysisOut: [ a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10] X-Spam: [F=0.5200000000; CM=0.500; MH=0.520(2015110506); S=0.200(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.83] Archived-At: X-Mailman-Approved-At: Sat, 07 Nov 2015 15:04:21 -0800 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Requesting lists in a container via RestConf X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 15:06:35 -0000 --_000_1AD4E3EE8900414DA099DB2732403B928B8F2154exmb1corpadtran_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gc2VjdGlvbiA0LjMgb2YgdGhlIFJlc3RDb25mIHN0YW5kYXJkIGEgR0VUIGV4YW1wbGUgaXMg Z2l2ZW4gZm9yIC9yZXN0Y29uZi9kYXRhL2V4YW1wbGUtanVrZWJveDpqdWtlYm94L2xpYnJhcnkv YXJ0aXN0PUZvbyUyMEZpZ2h0ZXJzL2FsYnVtDQoNCkluIHRoaXMgZXhhbXBsZSBhbGJ1bSBpcyBh IGxpc3QgaW5zaWRlIHRoZSBhcnRpc3QgcmVzb3VyY2UuIElzIHRoaXMgcmVxdWVzdCByZWFsbHkg dmFsaWQgYW5kIGlmIHllcywgaG93IHdvdWxkIGFuIFhNTCByZXNwb25zZSBsb29rIGxpa2U/DQoN Cg0KDQpDdXJyZW50bHkgaXQgcmV0dXJucyBpbiB0aGUgZXhhbXBsZSBvbmUgc3RydWN0dXJlDQoN CjxhbGJ1bSB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL25zL2V4YW1wbGUtanVrZWJveCI+DQoN CiAgICA8bmFtZT5XYXN0aW5nIExpZ2h0PC9uYW1lPg0KPC9hbGJ1bT4NCkJ1dCBob3cgd291bGQg aXQgbG9vayBsaWtlIGZvciBtdWx0aXBsZSBhbGJ1bXM/DQoNCklzIHRoZSBkcmFmdCByaWdodCBp biB0aGlzIGNhc2UsIHdhcyBpbiB0aGUgZHJhZnQgcmF0aGVyIG1lYW50IHRoYXQgYWxidW09V2Fz dGluZyUyMExpZ2h0IHdhcyB0byBiZSByZXF1ZXN0ZWQgYW5kIHJlcXVlc3RpbmcgbGlzdHMgd2l0 aG91dCB1c2luZyB0aGUgZmllbGRzIHF1ZXJ5IGlzIG5vdCBwb3NzaWJsZT8NCg0KUmVnYXJkcw0K Tmlscw0KDQpGcm9tOiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQpT ZW50OiBNb250YWcsIDIuIE5vdmVtYmVyIDIwMTUgMDI6MDcNClRvOiBOSUxTIEZJU0NIQkVDSw0K Q2M6IG5ldGNvbmZAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gUmVxdWVzdGluZyBs aXN0cyBpbiBhIGNvbnRhaW5lciB2aWEgUmVzdENvbmYNCg0KDQoNCk9uIFRodSwgT2N0IDIyLCAy MDE1IGF0IDEyOjE0IEFNLCBOSUxTIEZJU0NIQkVDSyA8TklMUy5GSVNDSEJFQ0tAYWR0cmFuLmNv bTxtYWlsdG86TklMUy5GSVNDSEJFQ0tAYWR0cmFuLmNvbT4+IHdyb3RlOg0KU3VwcG9zZSB3ZSBo YXZlIGluIGEgWUFORyBmaWxlDQoNCmNvbnRhaW5lciBqdWtlYm94IHsNCiAgICAgICAgICBsaXN0 IGFydGlzdCB7DQogICAgICAgICAgICBrZXkgbmFtZTsNCiAgICAgICAgICAgIGxlYWYgbmFtZSB7 Li59DQogICAgICAgICAgICAvLyBvdGhlciBsZWFmcw0KICAgICAgICAgICB9DQogICAgICAgICAg IGxpc3QgcGxheWxpc3Qgew0KICAgICAgICAgICAga2V5IG5hbWU7DQogICAgICAgICAgICBsZWFm IG5hbWUgey4ufQ0KICAgICAgICAgICAgLy8gb3RoZXIgbGVhZnMNCiAgICAgICAgICAgfQ0KfQ0K DQpIb3cgY2FuIEkgcmVxdWVzdCB1c2luZyBSZXN0Q29uZiBhbGwgYXJ0aXN0cyBidXQgbm90IGFs bCBwbGF5bGlzdHMgKGJlY2F1c2UgdGhlcmUgYXJlIHNvIG1hbnkpPw0KTW9yZSBwcmVjaXNlOiBJ ZiBJIHJlcXVlc3Qgd2l0aCBhIEdFVA0KDQovcmVzdGNvbmYvZGF0YS9leGFtcGxlLWp1a2Vib3g6 anVrZWJveC9hcnRpc3QgKHdpdGhvdXQgYW55IHNwZWNpZmljIGtleSkNCg0KDQoNClNlZSB0aGUg ImZpZWxkcyIgcXVlcnkgcGFyYW1ldGVyDQoNCg0Kd2hhdCBpcyB0aGUgcmVzdWx0IGluIFhNTCBh bmQgSlNPTiBhbmQgaXMgaXQgYSB2YWxpZCByZXF1ZXN0Pw0KDQpSZWdhcmRzDQpOaWxzDQoNCkFE VFJBTiBHbWJILCBTaWVtZW5zYWxsZWUgMSwgMTc0ODkgR3JlaWZzd2FsZCwgR0VSTUFOWQ0KT2Zm aWNlOiArNDkgMzgzNCA1MzUyIDg3MA0KQ2VsbDogKzQ5IDE3MCA2MzIgODgxOQ0KU2l0eiBkZXIg R2VzZWxsc2NoYWZ0OiBCZXJsaW4gLyBSZWdpc3RlcmVkIG9mZmljZTogQmVybGluDQpSZWdpc3Rl cmdlcmljaHQ6IEJlcmxpbiAvIENvbW1lcmNpYWwgcmVnaXN0cnk6IEFtdHNnZXJpY2h0IENoYXJs b3R0ZW5idXJnLCBIUkIgMTM1NjU2IEINCkdlc2Now6RmdHNmw7xocnVuZyAvIE1hbmFnaW5nIERp cmVjdG9yczogTWljaGFlbCBLLiBGb2xpYW5vLCBKYW1lcyBELiBXaWxzb24sIEpyLiwgRHIuIEVk dWFyZCBTY2hlaXRlcmVyDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnPG1haWx0 bzpOZXRjb25mQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRjb25mDQoNCg== --_000_1AD4E3EE8900414DA099DB2732403B928B8F2154exmb1corpadtran_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 IjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpERTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQg NzAuODVwdCAyLjBjbSA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iREUiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbiBzZWN0aW9uIDQuMyBv ZiB0aGUgUmVzdENvbmYgc3RhbmRhcmQgYSBHRVQgZXhhbXBsZSBpcyBnaXZlbiBmb3IgL3Jlc3Rj b25mL2RhdGEvZXhhbXBsZS1qdWtlYm94Omp1a2Vib3gvbGlicmFyeS9hcnRpc3Q9Rm9vJTIwRmln aHRlcnMvYWxidW08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbiB0aGlzIGV4YW1wbGUg YWxidW0gaXMgYSBsaXN0IGluc2lkZSB0aGUgYXJ0aXN0IHJlc291cmNlLiBJcyB0aGlzIHJlcXVl c3QgcmVhbGx5IHZhbGlkIGFuZCBpZiB5ZXMsIGhvdyB3b3VsZCBhbiBYTUwgcmVzcG9uc2UgbG9v ayBsaWtlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkN1cnJlbnRseSBpdCByZXR1cm5zIGluIHRoZSBleGFtcGxlIG9uZSBz dHJ1Y3R1cmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7YWxidW0geG1sbnM9JnF1 b3Q7aHR0cDovL2V4YW1wbGUuY29tL25zL2V4YW1wbGUtanVrZWJveCZxdW90OyZndDs8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsgJmx0O25hbWUmZ3Q7V2Fz dGluZyBMaWdodCZsdDsvbmFtZSZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jmx0Oy9hbGJ1bSZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkJ1dCBob3cgd291bGQgaXQgbG9vayBsaWtlIGZvciBtdWx0aXBsZSBhbGJ1 bXM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklzIHRoZSBkcmFmdCByaWdo dCBpbiB0aGlzIGNhc2UsIHdhcyBpbiB0aGUgZHJhZnQgcmF0aGVyIG1lYW50IHRoYXQgYWxidW09 V2FzdGluZyUyMExpZ2h0IHdhcyB0byBiZSByZXF1ZXN0ZWQgYW5kIHJlcXVlc3RpbmcgbGlzdHMg d2l0aG91dCB1c2luZw0KIHRoZSBmaWVsZHMgcXVlcnkgaXMgbm90IHBvc3NpYmxlPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5OaWxzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBBbmR5 IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4g TW9udGFnLCAyLiBOb3ZlbWJlciAyMDE1IDAyOjA3PGJyPg0KPGI+VG86PC9iPiBOSUxTIEZJU0NI QkVDSzxicj4NCjxiPkNjOjwvYj4gbmV0Y29uZkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW05ldGNvbmZdIFJlcXVlc3RpbmcgbGlzdHMgaW4gYSBjb250YWluZXIgdmlhIFJlc3RD b25mPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBPY3QgMjIsIDIwMTUgYXQgMTI6 MTQgQU0sIE5JTFMgRklTQ0hCRUNLICZsdDs8YSBocmVmPSJtYWlsdG86TklMUy5GSVNDSEJFQ0tA YWR0cmFuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk5JTFMuRklTQ0hCRUNLQGFkdHJhbi5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+U3VwcG9zZSB3ZSBoYXZlIGluIGEgWUFORyBmaWxl PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Y29udGFpbmVyIGp1a2Vib3ggezwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsaXN0IGFy dGlzdCB7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGtleSBuYW1lOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsZWFm IG5hbWUgey4ufTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvLyBvdGhlciBsZWFmczwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGxpc3QgcGxheWxpc3Qgezwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBrZXkgbmFtZTs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBuYW1lIHsuLn08L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLy8gb3Ro ZXIgbGVhZnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPn08L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SG93IGNhbiBJIHJlcXVlc3QgdXNpbmcgUmVz dENvbmYgYWxsIGFydGlzdHMgYnV0IG5vdCBhbGwgcGxheWxpc3RzIChiZWNhdXNlIHRoZXJlIGFy ZSBzbyBtYW55KT88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIj5Nb3JlIHByZWNpc2U6IElmIEkgcmVxdWVzdCB3aXRoIGEgR0VU PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+L3Jlc3Rjb25mL2RhdGEvZXhhbXBsZS1qdWtlYm94Omp1 a2Vib3gvYXJ0aXN0ICh3aXRob3V0IGFueSBzcGVjaWZpYyBrZXkpPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U2VlIHRoZSAmcXVvdDtmaWVsZHMmcXVvdDsgcXVlcnkgcGFyYW1ldGVyPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj53aGF0IGlzIHRoZSByZXN1bHQg aW4gWE1MIGFuZCBKU09OIGFuZCBpcyBpdCBhIHZhbGlkIHJlcXVlc3Q/PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+UmVnYXJkczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPk5pbHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjojQkZCRkJGIj5BRFRSQU4gR21iSCwgU2llbWVuc2Fs bGVlIDEsIDE3NDg5IEdyZWlmc3dhbGQsIEdFUk1BTlk8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtjb2xvcjojQkZCRkJGIj5PZmZpY2U6ICYjNDM7NDkgMzgzNCA1MzUyIDg3MDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOiNCRkJGQkYiPkNlbGw6ICYjNDM7NDkg MTcwIDYzMiA4ODE5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjojQkZCRkJGIj5TaXR6IGRlciBH ZXNlbGxzY2hhZnQ6IEJlcmxpbiAvIFJlZ2lzdGVyZWQgb2ZmaWNlOiBCZXJsaW48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2NvbG9yOiNCRkJGQkYiPlJlZ2lzdGVyZ2VyaWNodDogQmVybGluIC8gQ29tbWVy Y2lhbCByZWdpc3RyeTogQW10c2dlcmljaHQgQ2hhcmxvdHRlbmJ1cmcsIEhSQiAxMzU2NTYgQjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6I0JGQkZCRiI+R2VzY2jDpGZ0c2bDvGhydW5nIC8gTWFu YWdpbmcgRGlyZWN0b3JzOiBNaWNoYWVsIEsuIEZvbGlhbm8sIEphbWVzIEQuIFdpbHNvbiwgSnIu LCBEci4gRWR1YXJkIFNjaGVpdGVyZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpOZXRjb25mIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpOZXRjb25mQGlldGYub3JnIj5OZXRjb25m QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0Y29uZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1AD4E3EE8900414DA099DB2732403B928B8F2154exmb1corpadtran_-- From nobody Sat Nov 7 15:06:49 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC551A6F65; Sat, 7 Nov 2015 15:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlYtnmq-ZH7z; Sat, 7 Nov 2015 15:06:46 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 E2C531A0368; Sat, 7 Nov 2015 15:06:46 -0800 (PST) Received: from mb-2.local (113x32x187x162.ap113.ftth.ucom.ne.jp [113.32.187.162]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id tA7N6dSE020321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 7 Nov 2015 23:06:40 GMT (envelope-from joelja@bogus.com) To: Benoit Claise , Netconf References: <5620C26D.7050202@cisco.com> <563B0B32.4000801@cisco.com> From: joel jaeggli Message-ID: <563E8400.6010103@bogus.com> Date: Sun, 8 Nov 2015 08:06:40 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Thunderbird/42.0 MIME-Version: 1.0 In-Reply-To: <563B0B32.4000801@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r3XPgpOexskA4BTQoncot2lAF6b0BMjkv" Archived-At: Cc: Barry Leiba , netconf-ads@ietf.org Subject: Re: [Netconf] Consensus on draft-leiba-netmod-regpolicy-update-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 23:06:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --r3XPgpOexskA4BTQoncot2lAF6b0BMjkv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/5/15 4:54 PM, Benoit Claise wrote: > Dear all, >=20 > During the NETCONF meeting today, there was no objection to progressing= > the draft > https://tools.ietf.org/html/draft-leiba-netmod-regpolicy-update-00. > I would like to confirm consensus on the list with this email. >=20 > The one sentence exec summary is: This document proposes that the > registration policy for the NETCONF Capability URNs registry is lowered= > from Standards Action to IETF review, so that a document such as > draft-mm-netconf-time-capability-09 > can= > register a new entry. >=20 > The plan is to progress draft-leiba-netmod-regpolicy-update-00 as AD > sponsor in 2 weeks from now. Thanks, With that I am going to allow the publication of draft-mm-netconf-time, as our exception handling has been um unexceptional. regards, joel > Regards, Benoit >=20 >> Dear all, >> >> https://tools.ietf.org/html/draft-leiba-netmod-regpolicy-update-00 >> >> This document, which updates the NETCONF Capability URNs registry >> policy, requires the process defined in RFC 2026. This means that it >> needs to be discussed, reviewed by the responsible AD, given an >> IETF-wide last call, and reviewed and approved by the IESG. >> >> I hope that it can go fairly quickly, as it's a simple action. >> Therefore, I propose to keep this document as an individual >> submission, which I will AD sponsor. However, neither Bary nor I are >> going to push this ahead against the working group's opposition. >> >> So it's time to speak up if you disagree with that policy change. >> A final consensus call will be made during the NETCONF meeting in >> Yokohama. >> >> Regards, Benoit (OPS AD) >> >>> For any who haven't followed it, we had a discussion about the >>> experimental document draft-mm-netconf-time-capability, which >>> registers a NETCONF capability URN. Here's my last comment on the >>> point, after I cleared my DISCUSS ballot: >>> >>> ---------- >>> The registration policy for the NETCONF Capability URNs registry is >>> Standards Action, and this document, with Experimental status, does >>> not meet the requirement that the registration come from a Standards >>> Track RFC. This document cannot make that registration. >>> >>> After discussion about whether the IESG should make an exception in >>> this case and allow the registration, I agree that it's the right >>> thing to do for this document, so I've cleared my DISCUSS ballot on >>> that point. >>> >>> But at the same time, it seems that the registration policy is too >>> strict, and should be IETF Review, which allows the NETCONF working >>> group to make the decision by getting IETF consensus on the >>> registration -- there's no need to specifically require a Standards >>> Track RFC. To that end, I've submitted an Internet draft, >>> draft-leiba-netmod-regpolicy-update, which I ask the Network >>> Operations AD to sponsor, in coordination with the NETCONF working >>> group. >>> ---------- >>> >>> I typo'ed the filename (made it "-netmod-" rather than "-netconf-"); >>> sorry about that. In any case, the NETCONF working group should look= >>> at it and comment. It's straightforward, just changing the >>> registration policy and explaining why. I don't expect there'll be >>> controversy with it, but please do give it a review and comment, and >>> let Beno=C3=AEt and Joel know if y'all think it's acceptable for one = of >>> them to AD-sponsor: >>> https://datatracker.ietf.org/doc/draft-leiba-netmod-regpolicy-update/= >>> >>> Please keep me on CC for any discussion, so I'll see the messages, >>> though I'll also keep an eye on the mailing list archive. >>> >>> Thanks, >>> Barry, ART AD >>> . >>> >> >> . >> >=20 --r3XPgpOexskA4BTQoncot2lAF6b0BMjkv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlY+hAAACgkQ8AA1q7Z/VrLTTwCfdLxW+gIGa5RYdhHhe5jfSLbO EyYAnjgZPPLeNMoZ5cGtoSQnAJJarO6Q =J/IA -----END PGP SIGNATURE----- --r3XPgpOexskA4BTQoncot2lAF6b0BMjkv-- From nobody Mon Nov 9 04:57:22 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAD71B2A4C for ; Mon, 9 Nov 2015 04:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvMBvX-SBa0f for ; Mon, 9 Nov 2015 04:57:19 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C6951B2A4B for ; Mon, 9 Nov 2015 04:57:18 -0800 (PST) X-AuditID: c1b4fb3a-f79136d0000071e2-a5-5640982c3285 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 3E.C7.29154.C2890465; Mon, 9 Nov 2015 13:57:17 +0100 (CET) Received: from [159.107.197.199] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.3.248.2; Mon, 9 Nov 2015 13:57:16 +0100 To: "netconf@ietf.org" From: Balazs Lengyel Message-ID: <5640982C.404@ericsson.com> Date: Mon, 9 Nov 2015 13:57:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprELMWRmVeSWpSXmKPExsUyM+Jvra7uDIcwg1kr2SymbrrN6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujNsLH7MVvGeqePbkBVMDYx9TFyMnh4SAiUT3lg4oW0ziwr31 bF2MXBxCAkcYJXru/WcGSQgJrGGU2PuxBsQWEdCUaJz1gRXEZhMwkpjaf54FxBYWkJX48XQe WD2vgLrE3bPfGUFsFgEVifnz34LViwrESLzftIoRokZQ4uTMJ2C9zAIWEjPnn2eEsOUltr+d A7VXQ+Lhhb+sExj5ZiFpmYWkZRaSlgWMzKsYRYtTi4tz042M9FKLMpOLi/Pz9PJSSzYxAkPq 4JbfVjsYDz53PMQowMGoxMO7YbZ9mBBrYllxZe4hRgkOZiUR3sPeDmFCvCmJlVWpRfnxRaU5 qcWHGKU5WJTEeZuZHoQKCaQnlqRmp6YWpBbBZJk4OKUaGDMblwdMvnjCY8bejYd1PrHYvE/3 3fXpeXGMXlHci2Dr2yvrp270y0uQVvx71s6a9VQ5v17H7aTJN2aZ925cXvLZZM4p43efZq8J kP6hsOJgdvg9FfdH7+8eq9uz7V3CnGOXuUx9shNmLnll4Px9L/+t63v+7Xy559o39uVitSxq WZcVSpgnbDdXYinOSDTUYi4qTgQAXEmf8iUCAAA= Archived-At: Subject: [Netconf] DSCP in server model X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 12:57:21 -0000 Hello, I heard some operators like to prioritize OAM traffic. So my question is: don't we need a DSCP marking in the ietf-netconf-server-model? IMHO it would be needed. regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Mon Nov 9 18:39:58 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85B51B2FEC for ; Mon, 9 Nov 2015 18:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgquDQX0RHNX for ; Mon, 9 Nov 2015 18:39:52 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0135.outbound.protection.outlook.com [65.55.169.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4C2F1B2FEB for ; Mon, 9 Nov 2015 18:39:51 -0800 (PST) Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (TLS) id 15.1.318.15; Tue, 10 Nov 2015 02:39:47 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0318.003; Tue, 10 Nov 2015 02:39:48 +0000 From: Kent Watsen To: Balazs Lengyel , "netconf@ietf.org" Thread-Topic: [Netconf] DSCP in server model Thread-Index: AQHRGu4urehKt+cp3EOPMzAjS8KVaJ6VIyIA Date: Tue, 10 Nov 2015 02:39:47 +0000 Message-ID: References: <5640982C.404@ericsson.com> In-Reply-To: <5640982C.404@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 5:nAw5JLmQ2frqXQ5+TyXETZZJ5VcB8yT0x/Wlm1bagtChT+sQX2uh8OxdZFo9kOBAuzijl4bgGL36wXedFH6kQ0ycB9or7uzQPOkph/bCMtvNlJ2A72dOE58c2LhKxl1GVqjW+nn98yB4YAezcwE6zA==; 24:L6e7T3fw+A7FqAarLlUKWDaR/7rNOWq6LI6aMk/ussWA7lKSI0ZcvvKYACLGDzqqDQ7tX+jRiZl8KDlm7RfeZbwo5D0GIkE3bXxa9UeejUU=; 20:vsSW4l/sG2Hk/q3FHZjBCVYD68AxAJLw8KIKb0qHIXYukn2fIqp7yO8yM18hzQ277GPcJiG2VX2XMa0WevdeSA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 07562C22DA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(252514010)(199003)(479174004)(164054003)(189002)(76176999)(5002640100001)(40100003)(99286002)(92566002)(86362001)(106356001)(66066001)(105586002)(19580405001)(106116001)(5001770100001)(19580395003)(83716003)(2900100001)(101416001)(2950100001)(36756003)(189998001)(122556002)(15975445007)(4001350100001)(5008740100001)(5007970100001)(5001960100002)(10400500002)(54356999)(83506001)(82746002)(50986999)(107886002)(33656002)(102836002)(5004730100002)(97736004)(2501003)(87936001)(77096005)(81156007)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <1319725A0D7B8A4BB95283C0BBF31BFB@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2015 02:39:47.7262 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444 Archived-At: Subject: Re: [Netconf] DSCP in server model X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 02:39:56 -0000 DQpIaSBCYWxhenMsDQoNClRoaXMgaXMgYW4gaW50ZXJlc3RpbmcgcXVlc3Rpb24uICAgRmlyc3Qg b2ZmLCBJIGhhdmUgdG8gc2F5IHRoYXQgSeKAmW0gdW5hd2FyZSB0aGF0IEpVTk9TIGlzIGFibGUg dG8gc2V0IERTQ1AgbWFya2luZ3MgZm9yIGVpdGhlciBhY2NlcHRlZCBjb25uZWN0aW9ucyBvciBj YWxsIGhvbWUgY29ubmVjdGlvbnMsIHdoaWNoIGdvZXMgdG8gdGhlIGltcG9ydGFuY2Ugb2YgdGhl IGlzc3VlLiAgIERvIG90aGVycyBmZWVsIHRoYXQgRFNDUCB3b3VsZCBiZSBpbXBvcnRhbnQgdG8g c3VwcG9ydD8NCg0KTmV4dCwgYXNzdW1pbmcgd2UgZ28gaGlzIHJvdXRlLCBpcyBpdCBmYWlyIHRv IHNheSB0aGF0IHdl4oCZZCBub3Qgc3VwcG9ydCBMYXllciAyIENvUy84MDIuMXAgb3IgTGF5ZXIg MyBUT1MgaGVhZGVycz8NCg0KTGFzdGx5LCB3b3VsZCBzdWNoIGEgc2V0dGluZyBvbmx5IGFmZmVj dCB0cmFmZmljIGluaXRpYXRlZCBieSB0aGUgTkMvUkMgc2VydmVyIChub3QgdGhlIGNsaWVudCk/ DQoNClRoYW5rcywNCktlbnQNCg0KDQoNCg0KDQoNCk9uIDExLzkvMTUsIDc6NTcgQU0sICJOZXRj b25mIG9uIGJlaGFsZiBvZiBCYWxhenMgTGVuZ3llbCIgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9y ZyBvbiBiZWhhbGYgb2YgYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tPiB3cm90ZToNCg0KPkhl bGxvLA0KPkkgaGVhcmQgc29tZSBvcGVyYXRvcnMgbGlrZSB0byBwcmlvcml0aXplIE9BTSB0cmFm ZmljLiBTbyBteSBxdWVzdGlvbiANCj5pczogZG9uJ3Qgd2UgbmVlZCBhIERTQ1AgbWFya2luZyBp biB0aGUgaWV0Zi1uZXRjb25mLXNlcnZlci1tb2RlbD8gSU1ITyANCj5pdCB3b3VsZCBiZSBuZWVk ZWQuDQo+cmVnYXJkcyBCYWxhenMNCj4NCj4tLSANCj5CYWxhenMgTGVuZ3llbCAgICAgICAgICAg ICAgICAgICAgICAgRXJpY3Nzb24gSHVuZ2FyeSBMdGQuDQo+U2VuaW9yIFNwZWNpYWxpc3QNCj5F Q046IDgzMSA3MzIwDQo+TW9iaWxlOiArMzYtNzAtMzMwLTc5MDkgICAgICAgICAgICAgIGVtYWls OiBCYWxhenMuTGVuZ3llbEBlcmljc3Nvbi5jb20NCj4NCj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPk5ldGNvbmYgbWFpbGluZyBsaXN0DQo+TmV0Y29u ZkBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29u Zg0K From nobody Tue Nov 10 15:07:35 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA9A1B425A for ; Tue, 10 Nov 2015 15:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kb8DFzZjD2Wv for ; Tue, 10 Nov 2015 15:07:33 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (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 2AE591B41EE for ; Tue, 10 Nov 2015 15:06:35 -0800 (PST) Received: by lbblt2 with SMTP id lt2so7364402lbb.3 for ; Tue, 10 Nov 2015 15:06:33 -0800 (PST) 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:date:message-id:subject:from:to :content-type; bh=9ppyRa/Pl2tZ5zryoieKtJ0djUXlsHMy6c0enSTDV4s=; b=F+/Ph6DzJbQqlVMC8lW+B+uM/f9u2QpxNg9HJwEwSVOdorP9Fv9YrBwtA0cmEmgWRV 05Z1VLvlMqUKqzw16SB+sv8FcIi4PpGJkTDp8N5WWJNU89LfTGDoL8avEUmtviCz+HwW B2PFbAayYGAQWk20ZbjimWQzA6aRS7PUxt3Fb37xVko2+x+UtzmO9ZtKKDrruqOk/yTV 3bBkmewOkKR/fZfZbYJwfy8nZxiI6JcAIn1jiwASebb9rRVYbhyECaZ1kvv93kKE3Qe+ A/BgmV/s5D+8bPU/h13JmhKK6J+N1NEsjX/Kffkjd5/ptSwJknYQS5bdDV5xR0up7v17 YoEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=9ppyRa/Pl2tZ5zryoieKtJ0djUXlsHMy6c0enSTDV4s=; b=J6gJt++t0humfwAaTCKGoCHaHBzRwS+Dqbbtue4qWmHFFbLQUZiPJIOnx/D2ocVGFP PXmB625DXw4P3xgOBjDwUXfr8McyNdpHKANZAkrK5GiaiGr9X88dH1vwkX3nTKiGEBdw T+AGhzXnjeevAUhwdBunPh3x2WVi/001K6X6HEJT9xSBYyelGm6DcLoolF8i+sen79qh 6eFwzCPAymw5vxmQpBOUvm8WmPysK50KEZVhtXw9C+Icl1Mv4lJ6a3vy264cXipZvv1B hGDqapRDj7pdnJrtha2KGoFNXKEGiNmrHcJFHZT84JbF7W7O3raMSK4FqxtCoqjp+YAc GCpQ== X-Gm-Message-State: ALoCoQk+iWialhEc0H4Iw/uOzQUWhqO/Wnpxy3bK4Kw50AbukBzr4N8osf0kvyfVYQTfkoDxmA1U MIME-Version: 1.0 X-Received: by 10.112.161.168 with SMTP id xt8mr3020018lbb.88.1447196793260; Tue, 10 Nov 2015 15:06:33 -0800 (PST) Received: by 10.112.144.106 with HTTP; Tue, 10 Nov 2015 15:06:33 -0800 (PST) In-Reply-To: References: Date: Tue, 10 Nov 2015 15:06:33 -0800 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=001a11c3cb36c86799052437c221 Archived-At: Subject: Re: [Netconf] RESTCONF #31: how to stop receiving notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 23:07:34 -0000 --001a11c3cb36c86799052437c221 Content-Type: text/plain; charset=UTF-8 Hi, There has been no discussion on this issue. The SSE spec does not specify any additional mechanisms to stop receiving notifications but keep the connection open. Unless there are any suggestions for extending the SSE standard, there will not be anything added to RESTCONF to address this issue. The SSE spec should be extended and modified via the W3C, not the NETCONF WG. Servers do not support any message that says 'stop receiving notifications and now just wait on this idle connection.' The advantage of using SSE is lost if NETCONF changes it. Andy On Thu, Nov 5, 2015 at 5:17 PM, Andy Bierman wrote: > Hi, > > This is a new RESTCONF issue. > We did not invent Server-Sent Events, we just borrowed it. > The SSE spec is silent on this issue, which suggests > the transport session is simply dropped. > > IMO we should not be inventing something new here. > Whatever SSE provides for this problem should be used. > > > Andy > > --001a11c3cb36c86799052437c221 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

There has been no discussion on thi= s issue.
The SSE spec does not specify any additional mechanisms<= /div>
to stop receiving notifications but keep the connection open.

Unless there are any suggestions for extending the SS= E standard,
there will not be anything added to RESTCONF to addre= ss this issue.

The SSE spec should be extended and= modified via the W3C, not the NETCONF WG.
Servers do not support= any message that says 'stop receiving notifications
and now = just wait on this idle connection.' =C2=A0The advantage of using SSE is= lost
if NETCONF changes it.


<= div>Andy


On Thu, Nov 5, 2015 at 5:17 PM, Andy Bierman <andy@yuma= works.com> wrote:
Hi,

This is a new RESTCONF issue.
We = did not invent Server-Sent Events, we just borrowed it.
The SSE s= pec is silent on this issue, which suggests
the transport session= is simply dropped.

IMO we should not be inventing= something new here.
Whatever SSE provides for this problem shoul= d be used.


Andy


--001a11c3cb36c86799052437c221-- From nobody Tue Nov 10 15:16:53 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10311B431C for ; Tue, 10 Nov 2015 15:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoIZ7wOkPJ90 for ; Tue, 10 Nov 2015 15:16:51 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 1B6981B4324 for ; Tue, 10 Nov 2015 15:16:51 -0800 (PST) Received: by lfdo63 with SMTP id o63so7256705lfd.2 for ; Tue, 10 Nov 2015 15:16:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks_com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=OH+nnJQAAQXORewKK0Kk2VU/gfxC0I+PeN6DFAVwUug=; b=JKmuOqxpx2g5LMjsKWbQMdF1vyt5rNrdTeLzTRT+HyzB+NXBVQM5MJgzZIaAGx9kQN vmDUqyiviEWo95+rqu8ARiyBi1dPkolE88RLwkVNNozA6uS/X7D0ker+02yRrT5pebf3 GV/7RyJMOFfjtz0GixbmX8lqWZWyLNdC11GOhpLCWMAzagGDfs4mRnDhm9VTDQ4bV+m8 kWhmbdOLChD1/M63qIVsXZdjcI5IHhMGrgwTiBFnmIdSxw992Qv24mk6MReJqznpmUqY V7W+bMWgE08kv5XQIRePPRHeHYsAm3cvNMIOUOqpYWoeGnZcDwCSMsH1BW6eSjVIcN/O k0nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=OH+nnJQAAQXORewKK0Kk2VU/gfxC0I+PeN6DFAVwUug=; b=A8qP+M5RHaPQ9D+/OJzpERRjvDCsiyMvvMvK5+BZ5S122+AwG+YBVGKOHAbbYY9t7T dTLYxI8IXAceSZrv/WtfTlQ8C2qeh788j+seIGKgcEF6afaL2Jcg6vG7B+iwgTRCQbnY Eqkg6ury1zQJcZoQCNvQbY5mduQV6BJ7x5RP5xlslQ2SzXuhTvotquGIH+FegLVwfRE2 NBKQAOcNdBYKdTI6U92Y1DiiQnLmLmQxNtexqg1IQJBnSixUc1p/DvUmTdv7W930T9DP QUFMD5x1MLXG1QWTk9tSHatQeLs5X3vQDlr1AzScluYTLopUAilIqs0Mw/c9QdrfuZbi eWKg== X-Gm-Message-State: ALoCoQm9Aeb38u0yJj0e2tPQm2ivIqYT9MOKRRNmUdhflZxBLL1b9H6+4i7BGXXDn+HRy8tWBEsR MIME-Version: 1.0 X-Received: by 10.25.44.15 with SMTP id s15mr2890758lfs.37.1447197409082; Tue, 10 Nov 2015 15:16:49 -0800 (PST) Received: by 10.112.144.106 with HTTP; Tue, 10 Nov 2015 15:16:49 -0800 (PST) Date: Tue, 10 Nov 2015 15:16:49 -0800 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=001a11403c5c7d1886052437e764 Archived-At: Subject: [Netconf] YANGLIB #5: how to list protocol-specific modules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 23:16:52 -0000 --001a11403c5c7d1886052437e764 Content-Type: text/plain; charset=UTF-8 Hi, This open issue needs to be resolved. https://github.com/netconf-wg/yang-library/issues/5 There are 2 solution paths that have been suggested: YLIB5-01: separate views for each protocol. Each protocol would receive only the modules that are enabled for that protocol. YLIB5-02: add leaf-list to each module entry NETCONF and RESTCONF identities can be defined right away. Other protocols can define new identities on their own. leaf-list protocol { type identityref { base yang-protocol; } } IMO both have drawbacks. The server really tries to avoid protocol-dependent code. The code that manages data does not care about protocols, just internal representations of YANG data. The leaf-list approach is a waste of bandwidth unless the YANG library is actually shared by multiple protocols within a single server instance. So please discuss this issue on the mailing list and give your preference for a solution, or suggest a new solution. Andy --001a11403c5c7d1886052437e764 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

This open issue needs to= be resolved.
https://github.com/netconf-wg/yang-library/issues/5


There are 2 solution paths that have = been suggested:

YLIB5-01: separate views for each = protocol.
Each protocol would receive only the modules that are e= nabled
for that protocol.

YLIB5-02: add = leaf-list to each module entry
NETCONF and RESTCONF identities ca= n be defined right away.
Other protocols can define new identitie= s on their own.

=C2=A0 =C2=A0leaf-list protocol {<= /div>
=C2=A0 =C2=A0 =C2=A0 type identityref {
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 base yang-protocol;
=C2=A0 =C2=A0 =C2=A0 =C2= =A0}
=C2=A0 =C2=A0}


IMO b= oth have drawbacks.
The server really tries to avoid protocol-dep= endent code.
The code that manages data does not care about proto= cols,
just internal representations of YANG data.

<= /div>
The leaf-list approach is a waste of bandwidth unless the
YANG library is actually shared by multiple protocols
within a= single server instance.

So please discuss this is= sue on the mailing list and give your preference
for a solution, = or suggest a new solution.


Andy

--001a11403c5c7d1886052437e764-- From nobody Tue Nov 10 23:51:57 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151441B33FB for ; Tue, 10 Nov 2015 23:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bblwQUX5UaGh for ; Tue, 10 Nov 2015 23:51:54 -0800 (PST) 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 1F0BF1B33F7 for ; Tue, 10 Nov 2015 23:51:54 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E18BFEBE; Wed, 11 Nov 2015 08:51:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id aE_W2FQaYAlO; Wed, 11 Nov 2015 08:51:51 +0100 (CET) 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, 11 Nov 2015 08:51:51 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CD40A2004E; Wed, 11 Nov 2015 08:51:51 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pIWrS1pOC6eX; Wed, 11 Nov 2015 08:51:51 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 708A02003B; Wed, 11 Nov 2015 08:51:50 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A4260387C99B; Wed, 11 Nov 2015 08:51:49 +0100 (CET) Date: Wed, 11 Nov 2015 08:51:49 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20151111075149.GA21614@elstar.local> Mail-Followup-To: Andy Bierman , Netconf References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf Subject: Re: [Netconf] YANGLIB #5: how to list protocol-specific modules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 07:51:56 -0000 I assume the differences mostly affects a few modules that are specific to the protocol(s) being used. As such, I would think that YLIB5-01 makes more sense since this solution does not pollute the whole module list. /js On Tue, Nov 10, 2015 at 03:16:49PM -0800, Andy Bierman wrote: > Hi, > > This open issue needs to be resolved. > https://github.com/netconf-wg/yang-library/issues/5 > > > There are 2 solution paths that have been suggested: > > YLIB5-01: separate views for each protocol. > Each protocol would receive only the modules that are enabled > for that protocol. > > YLIB5-02: add leaf-list to each module entry > NETCONF and RESTCONF identities can be defined right away. > Other protocols can define new identities on their own. > > leaf-list protocol { > type identityref { > base yang-protocol; > } > } > > > IMO both have drawbacks. > The server really tries to avoid protocol-dependent code. > The code that manages data does not care about protocols, > just internal representations of YANG data. > > The leaf-list approach is a waste of bandwidth unless the > YANG library is actually shared by multiple protocols > within a single server instance. > > So please discuss this issue on the mailing list and give your preference > for a solution, or suggest a new solution. > > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- 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 Nov 11 08:51:28 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31C91B2BFC for ; Wed, 11 Nov 2015 08:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4CSx89cqz5H for ; Wed, 11 Nov 2015 08:51:18 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0125.outbound.protection.outlook.com [65.55.169.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC12D1B2B92 for ; Wed, 11 Nov 2015 08:51:17 -0800 (PST) Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (TLS) id 15.1.318.15; Wed, 11 Nov 2015 16:51:15 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0318.003; Wed, 11 Nov 2015 16:51:15 +0000 From: Kent Watsen To: Andy Bierman , Netconf Thread-Topic: [Netconf] RESTCONF #31: how to stop receiving notifications Thread-Index: AQHRGDDk8We8G3ZsekSnMagjq1B8LZ6V6ICAgAHAVwA= Date: Wed, 11 Nov 2015 16:51:15 +0000 Message-ID: <64B9F270-2923-4E3F-AA3C-EEFD8CED8419@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 5:Wr4x7HdaQQzczdf3iJg2F9NHQfW6efxYGOSLNHCGVbfzoZPdhBhhvDrCO922wfrf5vn8qe30Mudf3+AEOFcF1HVdEAlOVoHiIdFXJR4pqUTQP/8ROGEVABxfQYrq836UMwxfBFcRpn37SxCezr96mw==; 24:Rsx983sheOkqhmk49gxv4unq9jUHnVxqBJAnkT+OUhtDrZMaB9njUq+hya4/7I8B8/upT2n685cPgWXL7vJqHIXHyiArryW6nM/uhLv/EVQ=; 20:DyUIxtavay8zQu/NhbkVQl2V/3TJvEabkjGbDDTcI07FE17liKWPAv3ZkHLh6DV3k/a6uUmMrucEnSxxIu18Kg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 0757EEBDCA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(24454002)(189002)(377454003)(40100003)(54356999)(5004730100002)(99286002)(86362001)(5008740100001)(36756003)(189998001)(87936001)(83506001)(82746002)(11100500001)(83716003)(122556002)(10400500002)(76176999)(92566002)(50986999)(66066001)(19580395003)(19580405001)(5002640100001)(5007970100001)(5001770100001)(105586002)(81156007)(4001350100001)(16236675004)(97736004)(5001960100002)(33656002)(102836002)(2950100001)(2900100001)(77096005)(106356001)(106116001)(107886002)(101416001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_64B9F27029234E3FAA3CEEFD8CED8419junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2015 16:51:15.5868 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Subject: Re: [Netconf] RESTCONF #31: how to stop receiving notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 16:51:22 -0000 --_000_64B9F27029234E3FAA3CEEFD8CED8419junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpXb3JrcyBmb3IgbWUuDQoNCkNvaW5jaWRlbnRseSwgSSBrbm93IG9mIGEgR1VJIHRlYW0gdGhh dCByZWNlbnRseSBzZWxlY3RlZCBTU0UgZm9yIGFzeW5jIG5vdGlmaWNhdGlvbi4gIEluIHNvbWUg c2xpZGVzIGRlc2NyaWJpbmcgdGhlaXIgcGxhbnMsIHRoZSBsYXN0IGxpc3RlZCAobGVhc3QgaW1w b3J0YW50IHRvIHRoZW0pIG1vdGl2YXRpbmcgZmFjdG9yIHdhcyBiZWNhdXNlIGl0IHdhcyBhbHNv IHVzZWQgYnkgUkVTVENPTkYuICAgVGhlbiwgb24gYW5vdGhlciBzbGlkZSwgdGhleSBzdGF0ZWQg dGhhdCB0aGUgR1VJIHdvdWxkIGNsb3NlIHRoZSBTU0UgY29ubmVjdGlvbiBieSBzZW5kaW5nIGEg VENQIHJlc2V0LiAgRnJvbSB0aGlzIEkgdGFrZSBpdCB0aGF0IG91ciBkb2luZyB0aGUgc2FtZSB3 b3VsZCBub3QgYmUgb3V0IG9mIHBsYWNlLg0KDQpLZW50DQoNCkZyb206IE5ldGNvbmYgPG5ldGNv bmYtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPj4gb24g YmVoYWxmIG9mIEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1 bWF3b3Jrcy5jb20+Pg0KRGF0ZTogVHVlc2RheSwgTm92ZW1iZXIgMTAsIDIwMTUgYXQgNjowNiBQ TQ0KVG86ICJuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPiIgPG5ldGNv bmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtOZXRj b25mXSBSRVNUQ09ORiAjMzE6IGhvdyB0byBzdG9wIHJlY2VpdmluZyBub3RpZmljYXRpb25zDQoN CkhpLA0KDQpUaGVyZSBoYXMgYmVlbiBubyBkaXNjdXNzaW9uIG9uIHRoaXMgaXNzdWUuDQpUaGUg U1NFIHNwZWMgZG9lcyBub3Qgc3BlY2lmeSBhbnkgYWRkaXRpb25hbCBtZWNoYW5pc21zDQp0byBz dG9wIHJlY2VpdmluZyBub3RpZmljYXRpb25zIGJ1dCBrZWVwIHRoZSBjb25uZWN0aW9uIG9wZW4u DQoNClVubGVzcyB0aGVyZSBhcmUgYW55IHN1Z2dlc3Rpb25zIGZvciBleHRlbmRpbmcgdGhlIFNT RSBzdGFuZGFyZCwNCnRoZXJlIHdpbGwgbm90IGJlIGFueXRoaW5nIGFkZGVkIHRvIFJFU1RDT05G IHRvIGFkZHJlc3MgdGhpcyBpc3N1ZS4NCg0KVGhlIFNTRSBzcGVjIHNob3VsZCBiZSBleHRlbmRl ZCBhbmQgbW9kaWZpZWQgdmlhIHRoZSBXM0MsIG5vdCB0aGUgTkVUQ09ORiBXRy4NClNlcnZlcnMg ZG8gbm90IHN1cHBvcnQgYW55IG1lc3NhZ2UgdGhhdCBzYXlzICdzdG9wIHJlY2VpdmluZyBub3Rp ZmljYXRpb25zDQphbmQgbm93IGp1c3Qgd2FpdCBvbiB0aGlzIGlkbGUgY29ubmVjdGlvbi4nICBU aGUgYWR2YW50YWdlIG9mIHVzaW5nIFNTRSBpcyBsb3N0DQppZiBORVRDT05GIGNoYW5nZXMgaXQu DQoNCg0KQW5keQ0KDQoNCk9uIFRodSwgTm92IDUsIDIwMTUgYXQgNToxNyBQTSwgQW5keSBCaWVy bWFuIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+IHdyb3Rl Og0KSGksDQoNClRoaXMgaXMgYSBuZXcgUkVTVENPTkYgaXNzdWUuDQpXZSBkaWQgbm90IGludmVu dCBTZXJ2ZXItU2VudCBFdmVudHMsIHdlIGp1c3QgYm9ycm93ZWQgaXQuDQpUaGUgU1NFIHNwZWMg aXMgc2lsZW50IG9uIHRoaXMgaXNzdWUsIHdoaWNoIHN1Z2dlc3RzDQp0aGUgdHJhbnNwb3J0IHNl c3Npb24gaXMgc2ltcGx5IGRyb3BwZWQuDQoNCklNTyB3ZSBzaG91bGQgbm90IGJlIGludmVudGlu ZyBzb21ldGhpbmcgbmV3IGhlcmUuDQpXaGF0ZXZlciBTU0UgcHJvdmlkZXMgZm9yIHRoaXMgcHJv YmxlbSBzaG91bGQgYmUgdXNlZC4NCg0KDQpBbmR5DQoNCg0K --_000_64B9F27029234E3FAA3CEEFD8CED8419junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <41DAF8F9B46213418533E98BCCCABFF0@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PldvcmtzIGZvciBtZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PkNvaW5jaWRlbnRseSwgSSBrbm93IG9mIGEgR1VJIHRlYW0gdGhhdCByZWNlbnRseSBzZWxl Y3RlZCBTU0UgZm9yIGFzeW5jIG5vdGlmaWNhdGlvbi4gJm5ic3A7SW4gc29tZSBzbGlkZXMgZGVz Y3JpYmluZyB0aGVpciBwbGFucywgdGhlIGxhc3QgbGlzdGVkIChsZWFzdCBpbXBvcnRhbnQgdG8g dGhlbSkgbW90aXZhdGluZyBmYWN0b3Igd2FzIGJlY2F1c2UgaXQgd2FzIGFsc28gdXNlZCBieSBS RVNUQ09ORi4gJm5ic3A7IFRoZW4sIG9uIGFub3RoZXIgc2xpZGUsDQogdGhleSBzdGF0ZWQgdGhh dCB0aGUgR1VJIHdvdWxkIGNsb3NlIHRoZSBTU0UgY29ubmVjdGlvbiBieSBzZW5kaW5nIGEgVENQ IHJlc2V0LiAmbmJzcDtGcm9tIHRoaXMgSSB0YWtlIGl0IHRoYXQgb3VyIGRvaW5nIHRoZSBzYW1l IHdvdWxkIG5vdCBiZSBvdXQgb2YgcGxhY2UuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5LZW50PC9kaXY+DQo8ZGl2Pg0KPGRpdiBpZD0iTUFDX09VVExPT0tfU0lHTkFUVVJFIj48L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNf Qk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6 ZToxMnB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRp dW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQ QURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRm IDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+ DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPk5ldGNvbmYgJmx0 OzxhIGhyZWY9Im1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmciPm5ldGNvbmYtYm91bmNl c0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBBbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9 Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iPmFuZHlAeXVtYXdvcmtzLmNvbTwvYT4mZ3Q7PGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UdWVzZGF5LCBO b3ZlbWJlciAxMCwgMjAxNSBhdCA2OjA2IFBNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPlRvOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmci Pm5ldGNvbmZAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBp ZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW05ldGNvbmZdIFJFU1RDT05GICMzMTog aG93IHRvIHN0b3AgcmVjZWl2aW5nIG5vdGlmaWNhdGlvbnM8YnI+DQo8L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPkhpLA0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+VGhlcmUgaGFzIGJlZW4gbm8gZGlzY3Vzc2lvbiBvbiB0aGlzIGlzc3VlLjwv ZGl2Pg0KPGRpdj5UaGUgU1NFIHNwZWMgZG9lcyBub3Qgc3BlY2lmeSBhbnkgYWRkaXRpb25hbCBt ZWNoYW5pc21zPC9kaXY+DQo8ZGl2PnRvIHN0b3AgcmVjZWl2aW5nIG5vdGlmaWNhdGlvbnMgYnV0 IGtlZXAgdGhlIGNvbm5lY3Rpb24gb3Blbi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PlVubGVzcyB0aGVyZSBhcmUgYW55IHN1Z2dlc3Rpb25zIGZvciBleHRlbmRpbmcgdGhlIFNTRSBz dGFuZGFyZCw8L2Rpdj4NCjxkaXY+dGhlcmUgd2lsbCBub3QgYmUgYW55dGhpbmcgYWRkZWQgdG8g UkVTVENPTkYgdG8gYWRkcmVzcyB0aGlzIGlzc3VlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+VGhlIFNTRSBzcGVjIHNob3VsZCBiZSBleHRlbmRlZCBhbmQgbW9kaWZpZWQgdmlhIHRo ZSBXM0MsIG5vdCB0aGUgTkVUQ09ORiBXRy48L2Rpdj4NCjxkaXY+U2VydmVycyBkbyBub3Qgc3Vw cG9ydCBhbnkgbWVzc2FnZSB0aGF0IHNheXMgJ3N0b3AgcmVjZWl2aW5nIG5vdGlmaWNhdGlvbnM8 L2Rpdj4NCjxkaXY+YW5kIG5vdyBqdXN0IHdhaXQgb24gdGhpcyBpZGxlIGNvbm5lY3Rpb24uJyAm bmJzcDtUaGUgYWR2YW50YWdlIG9mIHVzaW5nIFNTRSBpcyBsb3N0PC9kaXY+DQo8ZGl2PmlmIE5F VENPTkYgY2hhbmdlcyBpdC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5BbmR5PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFRodSwg Tm92IDUsIDIwMTUgYXQgNToxNyBQTSwgQW5keSBCaWVybWFuIDxzcGFuIGRpcj0ibHRyIj4NCiZs dDs8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIiB0YXJnZXQ9Il9ibGFuayI+YW5k eUB5dW1hd29ya3MuY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFw eCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9Imx0ciI+SGksDQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGlzIGlzIGEgbmV3IFJFU1RDT05GIGlzc3VlLjwvZGl2Pg0K PGRpdj5XZSBkaWQgbm90IGludmVudCBTZXJ2ZXItU2VudCBFdmVudHMsIHdlIGp1c3QgYm9ycm93 ZWQgaXQuPC9kaXY+DQo8ZGl2PlRoZSBTU0Ugc3BlYyBpcyBzaWxlbnQgb24gdGhpcyBpc3N1ZSwg d2hpY2ggc3VnZ2VzdHM8L2Rpdj4NCjxkaXY+dGhlIHRyYW5zcG9ydCBzZXNzaW9uIGlzIHNpbXBs eSBkcm9wcGVkLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SU1PIHdlIHNob3VsZCBu b3QgYmUgaW52ZW50aW5nIHNvbWV0aGluZyBuZXcgaGVyZS48L2Rpdj4NCjxkaXY+V2hhdGV2ZXIg U1NFIHByb3ZpZGVzIGZvciB0aGlzIHByb2JsZW0gc2hvdWxkIGJlIHVzZWQuPC9kaXY+DQo8c3Bh biBjbGFzcz0iSE9FblpiIj48Zm9udCBjb2xvcj0iIzg4ODg4OCI+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QW5keTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjwvZm9udD48L3NwYW4+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_64B9F27029234E3FAA3CEEFD8CED8419junipernet_-- From nobody Wed Nov 11 09:07:09 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7591B2D48 for ; Wed, 11 Nov 2015 09:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNw5rg7vQ0uQ for ; Wed, 11 Nov 2015 09:07:06 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0111.outbound.protection.outlook.com [65.55.169.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DFAA1B2D32 for ; Wed, 11 Nov 2015 09:07:04 -0800 (PST) Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (TLS) id 15.1.318.15; Wed, 11 Nov 2015 17:07:00 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0318.003; Wed, 11 Nov 2015 17:07:01 +0000 From: Kent Watsen To: Andy Bierman , Netconf Thread-Topic: [Netconf] YANGLIB #5: how to list protocol-specific modules Thread-Index: AQHRHA3lf+pHkCqT6UWabmA+SfZnrZ6XpYSA Date: Wed, 11 Nov 2015 17:07:00 +0000 Message-ID: <1BE42550-64A1-4063-AD20-7093F51AA351@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 5:Gx0xar6qKsuPX6WS7nJYEUdi9J2gXKVgnqGdU46Mt5YyUfblexQSTTZX31MiZHSdNbqUWaJZNP2yj7VIznRL8VEyvfgIZkYma5tolY1Qtg0Hed/dg7FBX73MC5C+QFlwcXEB2VrTMa6tq32XEAcayw==; 24:PoFC1HPwiV1Rq+/X+BzzLrC9Fg5Cq5biJlvwowPioclsdUTd7rLc9ebuHVfQWYIwdcGhSNqjKwCMWc7MeVG2XrF/eOlMDcDoyEUUUD6unn8=; 20:pSTfvaZ5YkQlS66PHbKNrR4YmDlUO91B//DKjSFYSQYy8suip09O0RjBu3lfN4uMSuEEvj67rFn/unaus4sZ+Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 0757EEBDCA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(377454003)(10400500002)(99286002)(76176999)(2950100001)(106356001)(36756003)(105586002)(5007970100001)(77096005)(102836002)(2900100001)(15975445007)(106116001)(82746002)(83506001)(83716003)(87936001)(19580395003)(54356999)(50986999)(19580405001)(86362001)(101416001)(92566002)(16236675004)(122556002)(33656002)(19617315012)(5004730100002)(40100003)(189998001)(97736004)(81156007)(5008740100001)(5001770100001)(4001350100001)(66066001)(5002640100001)(107886002)(5001960100002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_1BE4255064A14063AD207093F51AA351junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2015 17:07:01.0022 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Subject: Re: [Netconf] YANGLIB #5: how to list protocol-specific modules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 17:07:08 -0000 --_000_1BE4255064A14063AD207093F51AA351junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpJcyB0aGVyZSBhIGJldHRlciBleGFtcGxlIHRoYW4gaWV0Zi1uZXRjb25mPyAgICAtIEkgZG9u 4oCZdCB0aGluayBpZXRmLW5ldGNvbmYgaXMgYSB2YWxpZCBleGFtcGxlIGFzIGl04oCZcyBub3Qg bGlzdGVkIGluIGEgTkVUQ09ORiA8aGVsbG8+IG1lc3NhZ2UgLSBvbmx5IGl04oCZcyBuYW1lc3Bh Y2UgaXMgdXNlZCwgYnV0IHRoYXQgaXMgcXVpdGUgZGlmZmVyZW50Li4uDQoNCklmIGl04oCZcyBq dXN0IHRoaXMgb25lIGV4YW1wbGUsIHRoZW4gSSBwcmVmZXIgb3B0aW9uICMxLg0KDQpLZW50DQoN Cg0KRnJvbTogTmV0Y29uZiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRjb25m LWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3 b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBOb3Zl bWJlciAxMCwgMjAxNSBhdCA2OjE2IFBNDQpUbzogIm5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5l dGNvbmZAaWV0Zi5vcmc+IiA8bmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9y Zz4+DQpTdWJqZWN0OiBbTmV0Y29uZl0gWUFOR0xJQiAjNTogaG93IHRvIGxpc3QgcHJvdG9jb2wt c3BlY2lmaWMgbW9kdWxlcw0KDQpIaSwNCg0KVGhpcyBvcGVuIGlzc3VlIG5lZWRzIHRvIGJlIHJl c29sdmVkLg0KaHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cveWFuZy1saWJyYXJ5L2lzc3Vl cy81DQoNCg0KVGhlcmUgYXJlIDIgc29sdXRpb24gcGF0aHMgdGhhdCBoYXZlIGJlZW4gc3VnZ2Vz dGVkOg0KDQpZTElCNS0wMTogc2VwYXJhdGUgdmlld3MgZm9yIGVhY2ggcHJvdG9jb2wuDQpFYWNo IHByb3RvY29sIHdvdWxkIHJlY2VpdmUgb25seSB0aGUgbW9kdWxlcyB0aGF0IGFyZSBlbmFibGVk DQpmb3IgdGhhdCBwcm90b2NvbC4NCg0KWUxJQjUtMDI6IGFkZCBsZWFmLWxpc3QgdG8gZWFjaCBt b2R1bGUgZW50cnkNCk5FVENPTkYgYW5kIFJFU1RDT05GIGlkZW50aXRpZXMgY2FuIGJlIGRlZmlu ZWQgcmlnaHQgYXdheS4NCk90aGVyIHByb3RvY29scyBjYW4gZGVmaW5lIG5ldyBpZGVudGl0aWVz IG9uIHRoZWlyIG93bi4NCg0KICAgbGVhZi1saXN0IHByb3RvY29sIHsNCiAgICAgIHR5cGUgaWRl bnRpdHlyZWYgew0KICAgICAgICAgIGJhc2UgeWFuZy1wcm90b2NvbDsNCiAgICAgICB9DQogICB9 DQoNCg0KSU1PIGJvdGggaGF2ZSBkcmF3YmFja3MuDQpUaGUgc2VydmVyIHJlYWxseSB0cmllcyB0 byBhdm9pZCBwcm90b2NvbC1kZXBlbmRlbnQgY29kZS4NClRoZSBjb2RlIHRoYXQgbWFuYWdlcyBk YXRhIGRvZXMgbm90IGNhcmUgYWJvdXQgcHJvdG9jb2xzLA0KanVzdCBpbnRlcm5hbCByZXByZXNl bnRhdGlvbnMgb2YgWUFORyBkYXRhLg0KDQpUaGUgbGVhZi1saXN0IGFwcHJvYWNoIGlzIGEgd2Fz dGUgb2YgYmFuZHdpZHRoIHVubGVzcyB0aGUNCllBTkcgbGlicmFyeSBpcyBhY3R1YWxseSBzaGFy ZWQgYnkgbXVsdGlwbGUgcHJvdG9jb2xzDQp3aXRoaW4gYSBzaW5nbGUgc2VydmVyIGluc3RhbmNl Lg0KDQpTbyBwbGVhc2UgZGlzY3VzcyB0aGlzIGlzc3VlIG9uIHRoZSBtYWlsaW5nIGxpc3QgYW5k IGdpdmUgeW91ciBwcmVmZXJlbmNlDQpmb3IgYSBzb2x1dGlvbiwgb3Igc3VnZ2VzdCBhIG5ldyBz b2x1dGlvbi4NCg0KDQpBbmR5DQoNCg== --_000_1BE4255064A14063AD207093F51AA351junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <3ECFAEB9BF82B44CBA72BC474EE07DFE@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PklzIHRoZXJlIGEgYmV0dGVyIGV4YW1wbGUgdGhhbiBpZXRmLW5ldGNv bmY/ICZuYnNwOyAmbmJzcDstIEkgZG9u4oCZdCB0aGluayBpZXRmLW5ldGNvbmYgaXMgYSB2YWxp ZCBleGFtcGxlIGFzIGl04oCZcyBub3QgbGlzdGVkIGluIGEgTkVUQ09ORiAmbHQ7aGVsbG8mZ3Q7 IG1lc3NhZ2UgLSBvbmx5IGl04oCZcyBuYW1lc3BhY2UgaXMgdXNlZCwgYnV0IHRoYXQgaXMgcXVp dGUgZGlmZmVyZW50Li4uPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JZiBpdOKAmXMg anVzdCB0aGlzIG9uZSBleGFtcGxlLCB0aGVuIEkgcHJlZmVyIG9wdGlvbiAjMS48L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PktlbnQ8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdiBpZD0iTUFDX09VVExPT0tfU0lHTkFUVVJFIj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0OyB0ZXh0LWFsaWdu OmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxF RlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsg UEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVS LVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPk5ldGNvbmYgJmx0OzxhIGhyZWY9Im1haWx0bzpu ZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmciPm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7 IG9uIGJlaGFsZiBvZiBBbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3 b3Jrcy5jb20iPmFuZHlAeXVtYXdvcmtzLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZv bnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UdWVzZGF5LCBOb3ZlbWJlciAxMCwgMjAxNSBh dCA2OjE2IFBNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+ JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8 L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBp ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1Ympl Y3Q6IDwvc3Bhbj5bTmV0Y29uZl0gWUFOR0xJQiAjNTogaG93IHRvIGxpc3QgcHJvdG9jb2wtc3Bl Y2lmaWMgbW9kdWxlczxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2PkhpLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+VGhpcyBvcGVuIGlzc3VlIG5lZWRzIHRvIGJlIHJlc29sdmVkLjwvZGl2Pg0KPGRpdj48YSBo cmVmPSJodHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy95YW5nLWxpYnJhcnkvaXNzdWVzLzUi Pmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3lhbmctbGlicmFyeS9pc3N1ZXMvNTwvYT48 YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5U aGVyZSBhcmUgMiBzb2x1dGlvbiBwYXRocyB0aGF0IGhhdmUgYmVlbiBzdWdnZXN0ZWQ6PC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5ZTElCNS0wMTogc2VwYXJhdGUgdmlld3MgZm9yIGVh Y2ggcHJvdG9jb2wuPC9kaXY+DQo8ZGl2PkVhY2ggcHJvdG9jb2wgd291bGQgcmVjZWl2ZSBvbmx5 IHRoZSBtb2R1bGVzIHRoYXQgYXJlIGVuYWJsZWQ8L2Rpdj4NCjxkaXY+Zm9yIHRoYXQgcHJvdG9j b2wuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5ZTElCNS0wMjogYWRkIGxlYWYtbGlz dCB0byBlYWNoIG1vZHVsZSBlbnRyeTwvZGl2Pg0KPGRpdj5ORVRDT05GIGFuZCBSRVNUQ09ORiBp ZGVudGl0aWVzIGNhbiBiZSBkZWZpbmVkIHJpZ2h0IGF3YXkuPC9kaXY+DQo8ZGl2Pk90aGVyIHBy b3RvY29scyBjYW4gZGVmaW5lIG5ldyBpZGVudGl0aWVzIG9uIHRoZWlyIG93bi48L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDtsZWFmLWxpc3QgcHJvdG9jb2wgezwv ZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7ICZuYnNwOyB0eXBlIGlkZW50aXR5cmVmIHs8L2Rpdj4N CjxkaXY+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBiYXNlIHlhbmctcHJvdG9j b2w7PC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO308L2Rpdj4NCjxkaXY+ Jm5ic3A7ICZuYnNwO308L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5JTU8gYm90aCBoYXZlIGRyYXdiYWNrcy48L2Rpdj4NCjxkaXY+VGhlIHNlcnZlciBy ZWFsbHkgdHJpZXMgdG8gYXZvaWQgcHJvdG9jb2wtZGVwZW5kZW50IGNvZGUuPC9kaXY+DQo8ZGl2 PlRoZSBjb2RlIHRoYXQgbWFuYWdlcyBkYXRhIGRvZXMgbm90IGNhcmUgYWJvdXQgcHJvdG9jb2xz LDwvZGl2Pg0KPGRpdj5qdXN0IGludGVybmFsIHJlcHJlc2VudGF0aW9ucyBvZiBZQU5HIGRhdGEu PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgbGVhZi1saXN0IGFwcHJvYWNoIGlz IGEgd2FzdGUgb2YgYmFuZHdpZHRoIHVubGVzcyB0aGU8L2Rpdj4NCjxkaXY+WUFORyBsaWJyYXJ5 IGlzIGFjdHVhbGx5IHNoYXJlZCBieSBtdWx0aXBsZSBwcm90b2NvbHM8L2Rpdj4NCjxkaXY+d2l0 aGluIGEgc2luZ2xlIHNlcnZlciBpbnN0YW5jZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PlNvIHBsZWFzZSBkaXNjdXNzIHRoaXMgaXNzdWUgb24gdGhlIG1haWxpbmcgbGlzdCBhbmQg Z2l2ZSB5b3VyIHByZWZlcmVuY2U8L2Rpdj4NCjxkaXY+Zm9yIGEgc29sdXRpb24sIG9yIHN1Z2dl c3QgYSBuZXcgc29sdXRpb24uPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+QW5keTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_1BE4255064A14063AD207093F51AA351junipernet_-- From nobody Wed Nov 11 09:25:35 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844891B2D46 for ; Wed, 11 Nov 2015 09:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xi2kJEJB3bAW for ; Wed, 11 Nov 2015 09:25:33 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 695C81B2DBF for ; Wed, 11 Nov 2015 09:25:32 -0800 (PST) Received: by lffu14 with SMTP id u14so20114082lff.1 for ; Wed, 11 Nov 2015 09:25:30 -0800 (PST) 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:date:message-id:subject:from:to :cc:content-type; bh=FI+SNxUNwu1EcziRTltr8cJ/pNNyCbp2NGf9H4LCd44=; b=nOlTXCeoVksVg2t8qchN0HPen4KusKWRpUvOcK6udzG/iqg+jwhWReW53UT7XbI8Bd pDM9HBCHg7RqGgrJ/pWkiRzAfgX+BpO8J2jHtOZy7U/WnqxwN6NUenqH+rp/O/gLELEF U+Id9tGvFphZxWKPWRgEYeHhLbDE+qNJxOVv8XWpDKgF4vjK+OUJsY9JUGly9Ny+kHh1 F4zNFDZpW2lDYLH+OdmeaSeGVKz2xXGrvOcdWW1IMjaSZeHbLMWT4/idvpxNgRqSj93j AYuPqMArMspAmpRcilmjvY5XBtDBwlmYKeO1zAkw8UNzvVKqBTC04u4bAjkkCF8OTORy 6ehA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FI+SNxUNwu1EcziRTltr8cJ/pNNyCbp2NGf9H4LCd44=; b=CY8iVSzMaPkh5UVvmk6Jd2LnuqbWGTKhDRntfvgatSy2OCYXoHjbJf7RKda3KX8fHU qYdFkZaaroynpFKINXVY8lCqFCD8u6zz4XQm6R1G1/22B0yZHVMluFaJdicdC3MOssWV vKPNWqIwPPz5zzgrWKovz7IsxVXluwUQ72Ed11SIez2zWdw2y6MfYFWQ+OH9N0h5sNUO blPUTTjfSFO3FLvIRGdSotvq/DsOSDa++OkGqCGu8+pS4hn5xRoe5tjwyWFeQswv31IK PWNwjIl0KFK7diUy3CrV+hWGFESe3HFsDRVJ74Lx6v+zppbw19mLLBedR1dIZVqm7uHD /kcw== X-Gm-Message-State: ALoCoQmxTj87pUPufEHttnp1UvxhFZXXVAfLqRPAAEqTeLYFktTvsULe1uP6UpCgWHohX7ZLa04J MIME-Version: 1.0 X-Received: by 10.25.17.232 with SMTP id 101mr4893560lfr.38.1447262730521; Wed, 11 Nov 2015 09:25:30 -0800 (PST) Received: by 10.112.144.106 with HTTP; Wed, 11 Nov 2015 09:25:30 -0800 (PST) In-Reply-To: <1BE42550-64A1-4063-AD20-7093F51AA351@juniper.net> References: <1BE42550-64A1-4063-AD20-7093F51AA351@juniper.net> Date: Wed, 11 Nov 2015 09:25:30 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=001a113f993af331990524471cd6 Archived-At: Cc: Netconf Subject: Re: [Netconf] YANGLIB #5: how to list protocol-specific modules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 17:25:34 -0000 --001a113f993af331990524471cd6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Nov 11, 2015 at 9:07 AM, Kent Watsen wrote: > > Is there a better example than ietf-netconf? - I don=E2=80=99t think > ietf-netconf is a valid example as it=E2=80=99s not listed in a NETCONF <= hello> > message - only it=E2=80=99s namespace is used, but that is quite differen= t... > > If it=E2=80=99s just this one example, then I prefer option #1. > > One problem with option #1 is that it excludes static content as an implementation strategy. I cannot just have a static representation of all the YANG modules. Instead it has to be dynamically rendered or output with special code, in order to examine the protocol of the client and filter out entries based on that. Or I have a static representation for each protocol, which is kind of a waste if the difference is only 1 or 2 modules. A variant of option #2 is a hard-wired leaf (e.g. bits) with "netconf" and "restconf" defined in the first release. Kent > Andy > > > From: Netconf on behalf of Andy Bierman < > andy@yumaworks.com> > Date: Tuesday, November 10, 2015 at 6:16 PM > To: "netconf@ietf.org" > Subject: [Netconf] YANGLIB #5: how to list protocol-specific modules > > Hi, > > This open issue needs to be resolved. > https://github.com/netconf-wg/yang-library/issues/5 > > > There are 2 solution paths that have been suggested: > > YLIB5-01: separate views for each protocol. > Each protocol would receive only the modules that are enabled > for that protocol. > > YLIB5-02: add leaf-list to each module entry > NETCONF and RESTCONF identities can be defined right away. > Other protocols can define new identities on their own. > > leaf-list protocol { > type identityref { > base yang-protocol; > } > } > > > IMO both have drawbacks. > The server really tries to avoid protocol-dependent code. > The code that manages data does not care about protocols, > just internal representations of YANG data. > > The leaf-list approach is a waste of bandwidth unless the > YANG library is actually shared by multiple protocols > within a single server instance. > > So please discuss this issue on the mailing list and give your preference > for a solution, or suggest a new solution. > > > Andy > > --001a113f993af331990524471cd6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 11, 2015 at 9:07 AM, Kent Watsen <kwatsen@juniper.net> wrote:

Is there a better example than ietf-netconf? =C2=A0 =C2=A0- I don=E2= =80=99t think ietf-netconf is a valid example as it=E2=80=99s not listed in= a NETCONF <hello> message - only it=E2=80=99s namespace is used, but= that is quite different...

If it=E2=80=99s just this one example, then I prefer option #1.


One problem wit= h option #1 is that it excludes static content as an implementation strateg= y.
I cannot just have a static representation of all the YANG mod= ules.=C2=A0 Instead it has to
be dynamically rendered or output w= ith special code, in order to examine the protocol
of the client = and filter out entries based on that.

Or I have a = static representation for each protocol, which is kind of a waste if the
difference is only 1 or 2 modules.

A varia= nt of option #2 is a hard-wired leaf (e.g. bits) with "netconf" a= nd "restconf"
defined in the first release.
<= br>

Kent

Andy
= =C2=A0


From: Netconf <netconf-bounces@ietf.org&g= t; on behalf of Andy Bierman <andy@yumaworks.com>
Date: Tuesday, November 10, 2015 at= 6:16 PM
To: "netconf@ietf.org" <netconf@ietf.org>
Subject: [Netconf] YANGLIB #5: how = to list protocol-specific modules

Hi,

This open issue needs to be resolved.


There are 2 solution paths that have been suggested:

YLIB5-01: separate views for each protocol.
Each protocol would receive only the modules that are enabled
for that protocol.

YLIB5-02: add leaf-list to each module entry
NETCONF and RESTCONF identities can be defined right away.
Other protocols can define new identities on their own.

=C2=A0 =C2=A0leaf-list protocol {
=C2=A0 =C2=A0 =C2=A0 type identityref {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 base yang-protocol;
=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0}


IMO both have drawbacks.
The server really tries to avoid protocol-dependent code.
The code that manages data does not care about protocols,
just internal representations of YANG data.

The leaf-list approach is a waste of bandwidth unless the
YANG library is actually shared by multiple protocols
within a single server instance.

So please discuss this issue on the mailing list and give your prefere= nce
for a solution, or suggest a new solution.


Andy


--001a113f993af331990524471cd6-- From nobody Wed Nov 11 09:30:42 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC991B2E63 for ; Wed, 11 Nov 2015 09:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.401 X-Spam-Level: X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IXHASH_X1=1.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywI0auujyowu for ; Wed, 11 Nov 2015 09:30:39 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0749.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:749]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9641B2E5D for ; Wed, 11 Nov 2015 09:30:37 -0800 (PST) Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (TLS) id 15.1.318.15; Wed, 11 Nov 2015 17:30:17 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0318.003; Wed, 11 Nov 2015 17:30:17 +0000 From: Kent Watsen To: Netconf Thread-Topic: RC#32: what to do about ClientCertificate? Thread-Index: AQHRHKah6BRKEARIS0eoEcje6rHpYQ== Date: Wed, 11 Nov 2015 17:30:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 5:zOKvfbADtdfeSWWcE2qF0FI/QznVsDC7Z8WWkoKNyjFv51gsMd/R2zGa1w3kAHYtqjS/F7pM+N6WpA0UwpZ76fRfPUw4LPHMkrLc2DOLLp4pGuC1E97mb0rDw32wjzRfkFrITiZMSpxxUvGeOGm40A==; 24:W+fUkGrvhQ1OdUHUv3tmpkUmfDbnUxLFU5qbzPZkQu2TUox0k9GlqpL4tcATXHtP9ZfCwBAC7cV/DYoUileuPnGYCxu0d13Uuhi+8tGORQY=; 20:BhYLtqMe9GssXHXhdVNEPMwXy6tKqACC0BejZaE6AlvbQKXHvoCReCoqI4PlkFzPuctiVr1C0J1o79XmofxMbw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0757EEBDCA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(164054003)(19580395003)(105586002)(106356001)(4001350100001)(33656002)(122556002)(40100003)(106116001)(16236675004)(66066001)(92566002)(81156007)(86362001)(229853001)(10400500002)(5007970100001)(97736004)(87936001)(83506001)(5008740100001)(101416001)(99286002)(82746002)(11100500001)(54356999)(50986999)(83716003)(15975445007)(102836002)(5004730100002)(36756003)(5002640100001)(5001960100002)(110136002)(107886002)(2900100001)(77096005)(551544002)(189998001)(450100001)(5001920100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_F6BED5E5AD3346DD94040B066E320C2Djunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2015 17:30:17.3782 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Subject: [Netconf] RC#32: what to do about ClientCertificate? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 17:30:40 -0000 --_000_F6BED5E5AD3346DD94040B066E320C2Djunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpUaGlzIGlzIGZvciB0aGUgdW50cmFja2VkIGlzc3VlIEkgbWVudGlvbmVkIGF0IHRoZSBtaWM6 DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3Jlc3Rjb25mL2lzc3Vlcy8zMg0KDQpI ZXJlIGlzIHRoZSB0ZXh0IG9mIHRoZSBpc3N1ZToNCg0KPT09PT1TVEFSVD09PT09DQpTZWN0aW9u IDIuNSBsaXN0cyBDbGllbnRDZXJ0aWZpY2F0ZSBhcyBvbmUgb2YgYSBzZXQgb2YgMyBhdXRoIHNj aGVtZXMgdGhhdCBNVVNUIGJlIGltcGxlbWVudGVkLiAgQnV0IGRyYWZ0LXRob21zb24taHR0cGJp cy1jYW50LTAxIGV4cGlyZWQgYWJvdXQgMTAgbW9udGhzIGFnbywgd2l0aCBubyByZWNlbnQgZGlz Y3Vzc2lvbiBhYm91dCByZXN1cnJlY3RpbmcgaXQuDQoNClJDMzItMDE6DQoNCldvcmsgd2l0aCB0 aGUgaHR0cGJpcyBXRyB0byByZXN1cnJlY3QgdGhlIGV4cGlyZWQgZHJhZnQuICAgVGhpcyBtYXkg Y2F1c2UgdGhlIFJGQyBFZGl0b3IgdG8gaG9sZCB0aGUgZHJhZnQgbG9uZ2VyIHRoYW4gb3RoZXJ3 aXNlIG5lZWRlZC4NCg0KUkMzMi0wMjoNCg0KUmVtb3ZlIENsaWVudENlcnRpZmljYXRlIGZyb20g dGhlIGxpc3QuICAgRWZmZWN0aXZlbHkgc3RhdGluZyB0aGF0IHRoZSBzZXJ2ZXIgTVVTVCBpbXBs ZW1lbnQgYXQgbGVhc3QgQmFzaWMgb3IgRGlnZXN0LCBleGNsdWRpbmcgdGhlIHBvc3NpYmlsaXR5 IHRoYXQgaXQgY291bGQgYXZvaWQgcGFzc3dvcmQtYmFzZWQgYXV0aGVudGljYXRpb24uDQoNClJD MzItMDM6DQoNCkFzc2VydCB0aGF0IG9ubHkgY2xpZW50LWNlcnRpZmljYXRlIGJhc2VkIGF1dGgg aXMgc3VwcG9ydGVkIChsaWtlIE5FVENPTkYgb3ZlciBUTFMpLiAgIFRoaXMgd291bGQgZWZmZWN0 aXZlbHkgcmVtb3ZlIHRoZSBuZWVkIGZvciBXV1ctQXV0aGVudGljYXRlIGFsdG9nZXRoZXIuDQoN Cj09PT09U1RPUD09PT09DQoNClBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIGxpc3Qu DQoNClRoYW5rcywNCktlbnQNCg0K --_000_F6BED5E5AD3346DD94040B066E320C2Djunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PlRoaXMgaXMgZm9yIHRoZSB1bnRyYWNrZWQgaXNzdWUgSSBtZW50aW9u ZWQgYXQgdGhlIG1pYzo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjxzcGFuIGNsYXNz PSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPmh0dHBzOi8v Z2l0aHViLmNvbS9uZXRjb25mLXdnL3Jlc3Rjb25mL2lzc3Vlcy8zMjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+SGVyZSBpcyB0aGUgdGV4dCBvZiB0aGUgaXNzdWU6PC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj49PT09PVNUQVJUPT09PT08L2Rpdj4NCjxkaXY+DQo8ZGl2PlNl Y3Rpb24gMi41IGxpc3RzIENsaWVudENlcnRpZmljYXRlIGFzIG9uZSBvZiBhIHNldCBvZiAzIGF1 dGggc2NoZW1lcyB0aGF0IE1VU1QgYmUgaW1wbGVtZW50ZWQuICZuYnNwO0J1dCBkcmFmdC10aG9t c29uLWh0dHBiaXMtY2FudC0wMSBleHBpcmVkIGFib3V0IDEwIG1vbnRocyBhZ28sIHdpdGggbm8g cmVjZW50IGRpc2N1c3Npb24gYWJvdXQgcmVzdXJyZWN0aW5nIGl0LjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+UkMzMi0wMTo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pldv cmsgd2l0aCB0aGUgaHR0cGJpcyBXRyB0byByZXN1cnJlY3QgdGhlIGV4cGlyZWQgZHJhZnQuICZu YnNwOyBUaGlzIG1heSBjYXVzZSB0aGUgUkZDIEVkaXRvciB0byBob2xkIHRoZSBkcmFmdCBsb25n ZXIgdGhhbiBvdGhlcndpc2UgbmVlZGVkLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ UkMzMi0wMjo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlbW92ZSBDbGllbnRDZXJ0 aWZpY2F0ZSBmcm9tIHRoZSBsaXN0LiAmbmJzcDsgRWZmZWN0aXZlbHkgc3RhdGluZyB0aGF0IHRo ZSBzZXJ2ZXIgTVVTVCBpbXBsZW1lbnQgYXQgbGVhc3QgQmFzaWMgb3IgRGlnZXN0LCBleGNsdWRp bmcgdGhlIHBvc3NpYmlsaXR5IHRoYXQgaXQgY291bGQgYXZvaWQgcGFzc3dvcmQtYmFzZWQgYXV0 aGVudGljYXRpb24uPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SQzMyLTAzOjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QXNzZXJ0IHRoYXQgb25seSBjbGllbnQtY2VydGlm aWNhdGUgYmFzZWQgYXV0aCBpcyBzdXBwb3J0ZWQgKGxpa2UgTkVUQ09ORiBvdmVyIFRMUykuICZu YnNwOyBUaGlzIHdvdWxkIGVmZmVjdGl2ZWx5IHJlbW92ZSB0aGUgbmVlZCBmb3IgV1dXLUF1dGhl bnRpY2F0ZSBhbHRvZ2V0aGVyLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PT09PT1T VE9QPT09PT08L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Q bGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0LjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj5LZW50PC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F6BED5E5AD3346DD94040B066E320C2Djunipernet_-- From nobody Wed Nov 11 09:35:06 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1FF1B2E79 for ; Wed, 11 Nov 2015 09:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZOkNpgfqBwk for ; Wed, 11 Nov 2015 09:35:03 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2DD1B2E7A for ; Wed, 11 Nov 2015 09:35:03 -0800 (PST) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 830141AE009B; Wed, 11 Nov 2015 18:35:02 +0100 (CET) Date: Wed, 11 Nov 2015 18:35:43 +0100 (CET) Message-Id: <20151111.183543.1428883560546424512.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <1BE42550-64A1-4063-AD20-7093F51AA351@juniper.net> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] YANGLIB #5: how to list protocol-specific modules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 17:35:05 -0000 QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiBPbiBXZWQsIE5vdiAx MSwgMjAxNSBhdCA5OjA3IEFNLCBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4gd3Jv dGU6DQo+IA0KPiA+DQo+ID4gSXMgdGhlcmUgYSBiZXR0ZXIgZXhhbXBsZSB0aGFuIGlldGYtbmV0 Y29uZj8gICAgLSBJIGRvbuKAmXQgdGhpbmsNCj4gPiBpZXRmLW5ldGNvbmYgaXMgYSB2YWxpZCBl eGFtcGxlIGFzIGl04oCZcyBub3QgbGlzdGVkIGluIGEgTkVUQ09ORiA8aGVsbG8+DQo+ID4gbWVz c2FnZSAtIG9ubHkgaXTigJlzIG5hbWVzcGFjZSBpcyB1c2VkLCBidXQgdGhhdCBpcyBxdWl0ZSBk aWZmZXJlbnQuLi4NCj4gPg0KPiA+IElmIGl04oCZcyBqdXN0IHRoaXMgb25lIGV4YW1wbGUsIHRo ZW4gSSBwcmVmZXIgb3B0aW9uICMxLg0KPiA+DQo+ID4NCj4gT25lIHByb2JsZW0gd2l0aCBvcHRp b24gIzEgaXMgdGhhdCBpdCBleGNsdWRlcyBzdGF0aWMgY29udGVudCBhcyBhbg0KPiBpbXBsZW1l bnRhdGlvbiBzdHJhdGVneS4NCg0KQWdyZWVkLg0KDQo+IEkgY2Fubm90IGp1c3QgaGF2ZSBhIHN0 YXRpYyByZXByZXNlbnRhdGlvbiBvZiBhbGwgdGhlIFlBTkcgbW9kdWxlcy4NCj4gSW5zdGVhZCBp dCBoYXMgdG8NCj4gYmUgZHluYW1pY2FsbHkgcmVuZGVyZWQgb3Igb3V0cHV0IHdpdGggc3BlY2lh bCBjb2RlLCBpbiBvcmRlciB0byBleGFtaW5lDQo+IHRoZSBwcm90b2NvbA0KPiBvZiB0aGUgY2xp ZW50IGFuZCBmaWx0ZXIgb3V0IGVudHJpZXMgYmFzZWQgb24gdGhhdC4NCj4gDQo+IE9yIEkgaGF2 ZSBhIHN0YXRpYyByZXByZXNlbnRhdGlvbiBmb3IgZWFjaCBwcm90b2NvbCwgd2hpY2ggaXMga2lu ZCBvZiBhDQo+IHdhc3RlIGlmIHRoZQ0KPiBkaWZmZXJlbmNlIGlzIG9ubHkgMSBvciAyIG1vZHVs ZXMuDQo+IA0KPiBBIHZhcmlhbnQgb2Ygb3B0aW9uICMyIGlzIGEgaGFyZC13aXJlZCBsZWFmIChl LmcuIGJpdHMpIHdpdGggIm5ldGNvbmYiIGFuZA0KPiAicmVzdGNvbmYiDQo+IGRlZmluZWQgaW4g dGhlIGZpcnN0IHJlbGVhc2UuDQoNCklmIHlvdSdyZSB3b3JyaWVkIGFib3V0IHRoZSBiaXRzLW9u LXRoZS13aXJlLCBtYXliZSB3ZSBjYW4gaGF2ZSBhDQpsZWFmLWxpc3Q6DQoNCiAgIGxlYWYtbGlz dCByZXN0cmljdGVkLXByb3RvY29sIHsgLi4uIH0NCg0KYW5kIGlmIGl0IGlzIGVtcHR5IHRoZSBt b2R1bGUgYXBwbGllcyB0byBhbGwgcHJvdG9jb2xzLg0KDQoNCi9tYXJ0aW4NCg0KDQoNCj4gDQo+ IA0KPiBLZW50DQo+ID4NCj4gDQo+IEFuZHkNCj4gDQo+IA0KPiA+DQo+ID4NCj4gPiBGcm9tOiBO ZXRjb25mIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBBbmR5IEJpZXJt YW4gPA0KPiA+IGFuZHlAeXVtYXdvcmtzLmNvbT4NCj4gPiBEYXRlOiBUdWVzZGF5LCBOb3ZlbWJl ciAxMCwgMjAxNSBhdCA2OjE2IFBNDQo+ID4gVG86ICJuZXRjb25mQGlldGYub3JnIiA8bmV0Y29u ZkBpZXRmLm9yZz4NCj4gPiBTdWJqZWN0OiBbTmV0Y29uZl0gWUFOR0xJQiAjNTogaG93IHRvIGxp c3QgcHJvdG9jb2wtc3BlY2lmaWMgbW9kdWxlcw0KPiA+DQo+ID4gSGksDQo+ID4NCj4gPiBUaGlz IG9wZW4gaXNzdWUgbmVlZHMgdG8gYmUgcmVzb2x2ZWQuDQo+ID4gaHR0cHM6Ly9naXRodWIuY29t L25ldGNvbmYtd2cveWFuZy1saWJyYXJ5L2lzc3Vlcy81DQo+ID4NCj4gPg0KPiA+IFRoZXJlIGFy ZSAyIHNvbHV0aW9uIHBhdGhzIHRoYXQgaGF2ZSBiZWVuIHN1Z2dlc3RlZDoNCj4gPg0KPiA+IFlM SUI1LTAxOiBzZXBhcmF0ZSB2aWV3cyBmb3IgZWFjaCBwcm90b2NvbC4NCj4gPiBFYWNoIHByb3Rv Y29sIHdvdWxkIHJlY2VpdmUgb25seSB0aGUgbW9kdWxlcyB0aGF0IGFyZSBlbmFibGVkDQo+ID4g Zm9yIHRoYXQgcHJvdG9jb2wuDQo+ID4NCj4gPiBZTElCNS0wMjogYWRkIGxlYWYtbGlzdCB0byBl YWNoIG1vZHVsZSBlbnRyeQ0KPiA+IE5FVENPTkYgYW5kIFJFU1RDT05GIGlkZW50aXRpZXMgY2Fu IGJlIGRlZmluZWQgcmlnaHQgYXdheS4NCj4gPiBPdGhlciBwcm90b2NvbHMgY2FuIGRlZmluZSBu ZXcgaWRlbnRpdGllcyBvbiB0aGVpciBvd24uDQo+ID4NCj4gPiAgICBsZWFmLWxpc3QgcHJvdG9j b2wgew0KPiA+ICAgICAgIHR5cGUgaWRlbnRpdHlyZWYgew0KPiA+ICAgICAgICAgICBiYXNlIHlh bmctcHJvdG9jb2w7DQo+ID4gICAgICAgIH0NCj4gPiAgICB9DQo+ID4NCj4gPg0KPiA+IElNTyBi b3RoIGhhdmUgZHJhd2JhY2tzLg0KPiA+IFRoZSBzZXJ2ZXIgcmVhbGx5IHRyaWVzIHRvIGF2b2lk IHByb3RvY29sLWRlcGVuZGVudCBjb2RlLg0KPiA+IFRoZSBjb2RlIHRoYXQgbWFuYWdlcyBkYXRh IGRvZXMgbm90IGNhcmUgYWJvdXQgcHJvdG9jb2xzLA0KPiA+IGp1c3QgaW50ZXJuYWwgcmVwcmVz ZW50YXRpb25zIG9mIFlBTkcgZGF0YS4NCj4gPg0KPiA+IFRoZSBsZWFmLWxpc3QgYXBwcm9hY2gg aXMgYSB3YXN0ZSBvZiBiYW5kd2lkdGggdW5sZXNzIHRoZQ0KPiA+IFlBTkcgbGlicmFyeSBpcyBh Y3R1YWxseSBzaGFyZWQgYnkgbXVsdGlwbGUgcHJvdG9jb2xzDQo+ID4gd2l0aGluIGEgc2luZ2xl IHNlcnZlciBpbnN0YW5jZS4NCj4gPg0KPiA+IFNvIHBsZWFzZSBkaXNjdXNzIHRoaXMgaXNzdWUg b24gdGhlIG1haWxpbmcgbGlzdCBhbmQgZ2l2ZSB5b3VyIHByZWZlcmVuY2UNCj4gPiBmb3IgYSBz b2x1dGlvbiwgb3Igc3VnZ2VzdCBhIG5ldyBzb2x1dGlvbi4NCj4gPg0KPiA+DQo+ID4gQW5keQ0K PiA+DQo+ID4NCg== From nobody Wed Nov 11 09:56:19 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3351A1B30A0 for ; Wed, 11 Nov 2015 09:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSv1FNxpfejU for ; Wed, 11 Nov 2015 09:56:16 -0800 (PST) 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 22C2F1B309B for ; Wed, 11 Nov 2015 09:56:16 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E483C1260; Wed, 11 Nov 2015 18:56:14 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id sA3xogWOWlNa; Wed, 11 Nov 2015 18:56:13 +0100 (CET) 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, 11 Nov 2015 18:56:13 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C2812004E; Wed, 11 Nov 2015 18:56:13 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id eNcOEqSKAyRM; Wed, 11 Nov 2015 18:56:12 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7B27C2003B; Wed, 11 Nov 2015 18:56:12 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 720AE387D223; Wed, 11 Nov 2015 18:56:10 +0100 (CET) Date: Wed, 11 Nov 2015 18:56:09 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20151111175609.GA23644@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netconf@ietf.org References: <1BE42550-64A1-4063-AD20-7093F51AA351@juniper.net> <20151111.183543.1428883560546424512.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <20151111.183543.1428883560546424512.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] YANGLIB #5: how to list protocol-specific modules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 17:56:18 -0000 On Wed, Nov 11, 2015 at 06:35:43PM +0100, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Wed, Nov 11, 2015 at 9:07 AM, Kent Watsen wrote: > > > > > > > > Is there a better example than ietf-netconf? - I don’t think > > > ietf-netconf is a valid example as it’s not listed in a NETCONF > > > message - only it’s namespace is used, but that is quite different... > > > > > > If it’s just this one example, then I prefer option #1. > > > > > > > > One problem with option #1 is that it excludes static content as an > > implementation strategy. > > Agreed. > > > I cannot just have a static representation of all the YANG modules. > > Instead it has to > > be dynamically rendered or output with special code, in order to examine > > the protocol > > of the client and filter out entries based on that. > > > > Or I have a static representation for each protocol, which is kind of a > > waste if the > > difference is only 1 or 2 modules. > > > > A variant of option #2 is a hard-wired leaf (e.g. bits) with "netconf" and > > "restconf" > > defined in the first release. > > If you're worried about the bits-on-the-wire, maybe we can have a > leaf-list: > > leaf-list restricted-protocol { ... } > > and if it is empty the module applies to all protocols. > I guess I am more concerned about popularizing the idea that data models may be protocol interface specific by providing explicit support for this. But then, this won't stop people anyway - and we already have yang patch and we leave it somewhat open how to use it with NC. So perhaps having a leaf list and letting the market decide whether protocol specific data models are a bug or a feature is the way to go. /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 Nov 11 10:06:41 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED7C1B31D2 for ; Wed, 11 Nov 2015 10:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ma51xc3WAL4f for ; Wed, 11 Nov 2015 10:06:37 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (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 945C81B31DB for ; Wed, 11 Nov 2015 10:06:10 -0800 (PST) Received: by lbblt2 with SMTP id lt2so21394173lbb.3 for ; Wed, 11 Nov 2015 10:06:08 -0800 (PST) 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:date:message-id:subject:from:to :content-type; bh=zdPZiewqDlaViksSjRV0qYO0R4hql6j7rNjqw1TJqec=; b=UkdRcHut+OzSI/PgWY/SV52VADvCYADxRjXgGBe8a6X6rrivyTEfgFmRm3w8fGDFkG G3BO7omqw6losVTugP2touCpDqvqPj7X3dH4RiKoheGnL0TwZrINAP7STiYMS2Vghyoo fO9NR9fSDplO4huu9DSRbF+a2bbQyWRF9t94bCrbbpg2yJRm7si30v3tQ3WHw5DLXgjM P+kzlKU5Y2evf62NVYanUCopIqiRGEzX7aO4ZGfxxwJtmYnTVnOS28hFYSg541xboo3f y8RTPt2Nph/pG5Ad5txab1PHf/gshkWqbutH0zHgYVhWP0J5IzMhUCuw1dDGq1vf/JXX vnPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=zdPZiewqDlaViksSjRV0qYO0R4hql6j7rNjqw1TJqec=; b=Wa/MHQnSkOG96al30jGLJvOY9d83anmIyWR6EW7hL3xVtSkQj+D6tizEmjqv+MH0PL lZfj9g1UkaLQZ1RfJQLmVoW7KsxdSZ826I+AEoNclcgGr3yvwGLjrFPWRPpZxcL26S34 KYwSsfBai6G3ArQbNa1mT4qgnWScUY7rqPqT+072UEqdCWWfFyG64iSXoAK4W8vLGT/3 RPJK3LNYFqLWhYQbM1BS6d8E7L5Nd6dnWcVrzUDzy9RcFvfFLFctzEebPkdxCf3rXcxg q+Bpqy9jrTrdB8pxOI7rtNB2tcyVBipswJ2iWIbe81SrpqW33h3i1TaEt3XVv5F6fVzD dXvw== X-Gm-Message-State: ALoCoQn675SQNmXFxmKmZOe3U8G7Rq4Dg3xUsYL12n4xNHDPhWfLLUy1AbcoZhtnHkUO4jkmd2u+ MIME-Version: 1.0 X-Received: by 10.112.199.231 with SMTP id jn7mr4977068lbc.37.1447265168733; Wed, 11 Nov 2015 10:06:08 -0800 (PST) Received: by 10.112.144.106 with HTTP; Wed, 11 Nov 2015 10:06:08 -0800 (PST) In-Reply-To: <20151111175609.GA23644@elstar.local> References: <1BE42550-64A1-4063-AD20-7093F51AA351@juniper.net> <20151111.183543.1428883560546424512.mbj@tail-f.com> <20151111175609.GA23644@elstar.local> Date: Wed, 11 Nov 2015 10:06:08 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Martin Bjorklund , Andy Bierman , Netconf Content-Type: multipart/alternative; boundary=001a11c26696475393052447ae89 Archived-At: Subject: Re: [Netconf] YANGLIB #5: how to list protocol-specific modules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 18:06:39 -0000 --001a11c26696475393052447ae89 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Nov 11, 2015 at 9:56 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Nov 11, 2015 at 06:35:43PM +0100, Martin Bjorklund wrote: > > Andy Bierman wrote: > > > On Wed, Nov 11, 2015 at 9:07 AM, Kent Watsen > wrote: > > > > > > > > > > > Is there a better example than ietf-netconf? - I don=E2=80=99t t= hink > > > > ietf-netconf is a valid example as it=E2=80=99s not listed in a NET= CONF > > > > > message - only it=E2=80=99s namespace is used, but that is quite di= fferent... > > > > > > > > If it=E2=80=99s just this one example, then I prefer option #1. > > > > > > > > > > > One problem with option #1 is that it excludes static content as an > > > implementation strategy. > > > > Agreed. > > > > > I cannot just have a static representation of all the YANG modules. > > > Instead it has to > > > be dynamically rendered or output with special code, in order to > examine > > > the protocol > > > of the client and filter out entries based on that. > > > > > > Or I have a static representation for each protocol, which is kind of= a > > > waste if the > > > difference is only 1 or 2 modules. > > > > > > A variant of option #2 is a hard-wired leaf (e.g. bits) with "netconf= " > and > > > "restconf" > > > defined in the first release. > > > > If you're worried about the bits-on-the-wire, maybe we can have a > > leaf-list: > > > > leaf-list restricted-protocol { ... } > > > > and if it is empty the module applies to all protocols. > > > > This is a better option #2 > I guess I am more concerned about popularizing the idea that data > models may be protocol interface specific by providing explicit > support for this. But then, this won't stop people anyway - and we > already have yang patch and we leave it somewhat open how to use it > with NC. So perhaps having a leaf list and letting the market decide > whether protocol specific data models are a bug or a feature is the > way to go. > > RPC operations in ietf-netconf are very protocol-specific. I do not want to constrain vendors or cause extra complexity. Whether the YANG module has protocol-specific content or not, it is a separate decision for a vendor to support a data model in a given protocol. There may be more CLI content than NETCONF content implemented in the server. There may be more NETCONF content than RESTCONF content implemented in the server. There may be just a few modules that are supported by I2RS. > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a11c26696475393052447ae89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 11, 2015 at 9:56 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Nov 11, 2015 at 06:35:43PM +0100, Martin Bjo= rklund wrote:
> Andy Bierman <andy@yumaworks.= com> wrote:
> > On Wed, Nov 11, 2015 at 9:07 AM, Kent Watsen <kwatsen@juniper.net> wrote:
> >
> > >
> > > Is there a better example than ietf-netconf?=C2=A0 =C2=A0 - = I don=E2=80=99t think
> > > ietf-netconf is a valid example as it=E2=80=99s not listed i= n a NETCONF <hello>
> > > message - only it=E2=80=99s namespace is used, but that is q= uite different...
> > >
> > > If it=E2=80=99s just this one example, then I prefer option = #1.
> > >
> > >
> > One problem with option #1 is that it excludes static content as = an
> > implementation strategy.
>
> Agreed.
>
> > I cannot just have a static representation of all the YANG module= s.
> > Instead it has to
> > be dynamically rendered or output with special code, in order to = examine
> > the protocol
> > of the client and filter out entries based on that.
> >
> > Or I have a static representation for each protocol, which is kin= d of a
> > waste if the
> > difference is only 1 or 2 modules.
> >
> > A variant of option #2 is a hard-wired leaf (e.g. bits) with &quo= t;netconf" and
> > "restconf"
> > defined in the first release.
>
> If you're worried about the bits-on-the-wire, maybe we can have a<= br> > leaf-list:
>
>=C2=A0 =C2=A0 leaf-list restricted-protocol { ... }
>
> and if it is empty the module applies to all protocols.
>


This is a better option #2
<= br>
=C2=A0
I guess I am more concerned about popularizing the idea that data
models may be protocol interface specific by providing explicit
support for this. But then, this won't stop people anyway - and we
already have yang patch and we leave it somewhat open how to use it
with NC. So perhaps having a leaf list and letting the market decide
whether protocol specific data models are a bug or a feature is the
way to go.



RPC operations in ietf-netconf are ve= ry protocol-specific.

I do not want to constrain v= endors or cause extra complexity.
Whether the YANG module has pro= tocol-specific content or not,
it is a separate decision for a ve= ndor to support a data model in
a given protocol.

<= /div>
There may be more CLI content than NETCONF content implemented in= the server.
There may be more NETCONF content than RESTCONF cont= ent implemented
in the server.=C2=A0 There may be just a few modu= les that are supported by I2RS.

=C2=A0
/js


Andy
=C2=A0
--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--001a11c26696475393052447ae89-- From nobody Wed Nov 11 23:41:17 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658771A7D85 for ; Wed, 11 Nov 2015 23:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ocpwMjzPGv3 for ; Wed, 11 Nov 2015 23:40:47 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 890481A7003 for ; Wed, 11 Nov 2015 23:40:47 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 26BDA1CC009A; Thu, 12 Nov 2015 08:40:47 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman , Kent Watsen In-Reply-To: References: <1BE42550-64A1-4063-AD20-7093F51AA351@juniper.net> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Thu, 12 Nov 2015 08:40:50 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Netconf Subject: Re: [Netconf] YANGLIB #5: how to list protocol-specific modules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 07:41:16 -0000 Andy Bierman writes: > On Wed, Nov 11, 2015 at 9:07 AM, Kent Watsen wrote: > >> >> Is there a better example than ietf-netconf? - I don=E2=80=99t think >> ietf-netconf is a valid example as it=E2=80=99s not listed in a NETCONF = >> message - only it=E2=80=99s namespace is used, but that is quite differe= nt... >> >> If it=E2=80=99s just this one example, then I prefer option #1. >> >> > One problem with option #1 is that it excludes static content as an > implementation strategy. > I cannot just have a static representation of all the YANG modules. > Instead it has to > be dynamically rendered or output with special code, in order to examine > the protocol > of the client and filter out entries based on that. > > Or I have a static representation for each protocol, which is kind of a > waste if the > difference is only 1 or 2 modules. > > A variant of option #2 is a hard-wired leaf (e.g. bits) with "netconf" and > "restconf" > defined in the first release. I think the server can keep such a leaf internally and then take it into account when serializing the data for a particular protocol. I prefer #1. With respect to ietf-netconf, is there any reason why it needs to be listed in yang-library even for NETCONF? Lada > > > Kent >> > > Andy > > >> >> >> From: Netconf on behalf of Andy Bierman < >> andy@yumaworks.com> >> Date: Tuesday, November 10, 2015 at 6:16 PM >> To: "netconf@ietf.org" >> Subject: [Netconf] YANGLIB #5: how to list protocol-specific modules >> >> Hi, >> >> This open issue needs to be resolved. >> https://github.com/netconf-wg/yang-library/issues/5 >> >> >> There are 2 solution paths that have been suggested: >> >> YLIB5-01: separate views for each protocol. >> Each protocol would receive only the modules that are enabled >> for that protocol. >> >> YLIB5-02: add leaf-list to each module entry >> NETCONF and RESTCONF identities can be defined right away. >> Other protocols can define new identities on their own. >> >> leaf-list protocol { >> type identityref { >> base yang-protocol; >> } >> } >> >> >> IMO both have drawbacks. >> The server really tries to avoid protocol-dependent code. >> The code that manages data does not care about protocols, >> just internal representations of YANG data. >> >> The leaf-list approach is a waste of bandwidth unless the >> YANG library is actually shared by multiple protocols >> within a single server instance. >> >> So please discuss this issue on the mailing list and give your preference >> for a solution, or suggest a new solution. >> >> >> Andy >> >> > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Nov 12 00:19:31 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A7B1A9109 for ; Thu, 12 Nov 2015 00:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7QTYQOFS4NI for ; Thu, 12 Nov 2015 00:19:28 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D5131A90FD for ; Thu, 12 Nov 2015 00:19:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6993; q=dns/txt; s=iport; t=1447316367; x=1448525967; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=SuO4bxTVgjN4oG26kkj/uwAh54DNu3xp97jaLzBe4tM=; b=hK2xZ+dDFCh12iuWybZTYYy4JePr/qectFd93R66bQcV31fhsW+9zGvM +7EixwBrqhUdhFwzkxR7AeHCzeIOkBWPDvZkbbwno55yGnpkTIUKCJG3k ArffhPx7O0nHVEKJoSFqsE7DY5v3JpMNCDBbUj8UwjK6GSgsWUegt8yfj I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CsBACNSkRW/xbLJq1ehA5vvCKEDSGFb?= =?us-ascii?q?wKBfwEBAQEBAYELhDQBAQEEeBEcAwECChYECwkDAgECAQ8sAggGDQYCAQGIFQM?= =?us-ascii?q?SDb5+DYRjAQEBAQEBAQEBAQEBAQEBAQEBFwSGVIR+glOCKIQ+BZJng2GFHYJxg?= =?us-ascii?q?ySBdYkdi1WHU2OCRIFBPTSFPQEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,280,1444694400"; d="scan'208,217";a="608144391" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 12 Nov 2015 08:19:25 +0000 Received: from [10.149.0.74] (dhcp-10-149-0-74.cisco.com [10.149.0.74]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tAC8JPVv017813 for ; Thu, 12 Nov 2015 08:19:25 GMT References: <20151110161239.32754.62280.idtracker@ietfa.amsl.com> To: NETCONF From: Benoit Claise X-Forwarded-Message-Id: <20151110161239.32754.62280.idtracker@ietfa.amsl.com> Message-ID: <56444B8D.4040603@cisco.com> Date: Thu, 12 Nov 2015 09:19:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151110161239.32754.62280.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------080206040504000504040008" Archived-At: Subject: [Netconf] Fwd: Document Action: 'Time Capability in NETCONF' to Experimental RFC (draft-mm-netconf-time-capability-09.txt) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 08:19:29 -0000 This is a multi-part message in MIME format. --------------080206040504000504040008 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit FYI. Regards, Benoit -------- Forwarded Message -------- Subject: Document Action: 'Time Capability in NETCONF' to Experimental RFC (draft-mm-netconf-time-capability-09.txt) Date: Tue, 10 Nov 2015 08:12:39 -0800 From: The IESG To: IETF-Announce CC: joelja@gmail.com, The IESG , draft-mm-netconf-time-capability@ietf.org, rfc-editor@rfc-editor.org The IESG has approved the following document: - 'Time Capability in NETCONF' (draft-mm-netconf-time-capability-09.txt) as Experimental RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-mm-netconf-time-capability/ Technical Summary This document defines a capability-based extension to the Network Configuration Protocol (NETCONF) that allows time-triggered configuration and management operations. This extension allows NETCONF clients to invoke configuration updates according to scheduled times, and allows NETCONF servers to attach timestamps to the data they send to NETCONF clients. Working Group Summary The document was proposed for consideration as a netconf working-group item. Ultimately it was not adopted as such. With the blessing of the the ADs it was forwarded to the ISE, however, the requirements for allocation for the netconf registry required standards action. The decision was made to AD sponsor the draft recognizing that a number of participants in the discussion felt that the proposed capabilities had merit even the to proposal itself wasn't ready for the standards track. This required a standards action, 4 week last call and a number of solicited reviews in order to insure that we were not wildly off base. Document Quality There were some significant variance of opinion on which 6142 operations are valid for timing. One vantage point is that potentially you only care about timing get operations. Another more common view is that with the exception of a few which make no sense timing is applicable to most of the operations. The proposed set hews to the later vantage point. It is possible that experimentation will refine the use cases more succinctly. Personnel Joel Jaeggli is the sponsoring AD and Shepherd. . --------------080206040504000504040008 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit FYI.

Regards, Benoit


-------- Forwarded Message --------
Subject: Document Action: 'Time Capability in NETCONF' to Experimental RFC (draft-mm-netconf-time-capability-09.txt)
Date: Tue, 10 Nov 2015 08:12:39 -0800
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: joelja@gmail.com, The IESG <iesg@ietf.org>, draft-mm-netconf-time-capability@ietf.org, rfc-editor@rfc-editor.org 


The IESG has approved the following document:
- 'Time Capability in NETCONF'
  (draft-mm-netconf-time-capability-09.txt) as Experimental RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Joel Jaeggli.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-mm-netconf-time-capability/





Technical Summary

   This document defines a capability-based extension to the Network
   Configuration Protocol (NETCONF) that allows time-triggered
   configuration and management operations. This extension allows
   NETCONF clients to invoke configuration updates according to
   scheduled times, and allows NETCONF servers to attach timestamps to
   the data they send to NETCONF clients.

Working Group Summary

The document was proposed for consideration as a netconf working-group 
item. Ultimately it was not adopted as such. With the blessing of the the ADs
it was forwarded to the ISE, however, the requirements for allocation for the 
netconf registry required standards action. The decision was made to AD 
sponsor the draft recognizing that a number of participants in the discussion
felt that the proposed  capabilities had merit even the to proposal itself 
wasn't ready for the standards track. This required a standards action, 4 week 
last call and a number of solicited reviews in order to insure that we were not
wildly off base.

Document Quality

There were some significant variance of opinion on which 6142 operations 
are valid for timing. One vantage point is that potentially you only care about 
timing get operations. Another more common view is that with the exception
of a few which make no sense timing is applicable to most of the operations.
The proposed set hews to the later vantage point. It is possible that 
experimentation will refine the use cases more succinctly.

Personnel

Joel Jaeggli is the sponsoring AD and Shepherd.

.


--------------080206040504000504040008-- From nobody Fri Nov 13 09:18:46 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0B01B2CF9 for ; Fri, 13 Nov 2015 09:18:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kl0LDWk-GDse for ; Fri, 13 Nov 2015 09:18:42 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (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 2AD801B2CFA for ; Fri, 13 Nov 2015 09:18:42 -0800 (PST) Received: by lbbkw15 with SMTP id kw15so57685869lbb.0 for ; Fri, 13 Nov 2015 09:18:40 -0800 (PST) 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:date:message-id:subject:from:to :cc:content-type; bh=PRbb67LVT6CTbv1M9K8S2RGutbe5f2Ud+6UdxfhwLfs=; b=bdAi3Njrd5p9NT5PT1xVvg9AuGISOdZ3CzO60nOKDAhXH205ZlNTtqu5uDiu7W5sfM +fgXKO9L6o3iXU+pWCBVjXYj7FRRfsN4/Fg423j8r5pvaIt/gGmcyKxbVmcJlF5YIFgW wmeIkXwuTsGaBfthDalilSCHCl3GwFpHxi+siuf8r7HqTh078uCVedH23c8IKgt24Cdx OLM8cccFdr2GyDk0c0ub+pBsigOv7CxA4o0cvwfZKhZmsIQNzBuh9Xe1rWF/+YmRqimL Yy7E23wibwTCkwaWn/0//sFMjHFBYrax7KMXadp6MixRYUVM0UCVTQIOtD6zAvOfuuMT j/kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PRbb67LVT6CTbv1M9K8S2RGutbe5f2Ud+6UdxfhwLfs=; b=H+1ZJd/tSOU4OH775BXTSJ0Ximu98Cqz/vce08qJrelZLUgCQpJPeHehUA+o16u2Ge eDWmakGGuw7n9HPsSZPDHQ8UwQqduJyuG3aMd+2cPWC+jAPTCAA5TthRHIbt00/qsVOo 1hGuIIgMXxWk+ALSvanNfm4R6+izX39PSBr2Ew+D4/Eb5xhPiEBbMda2KTowVLmdGK5D tTUiKJMBABFcF1ig3XnxVkFynWWWLS//fq+DAb0E61DsrznBYL8vu/PsxZruxyMEZDrr Rrzd/4hsDvS0GT/czKEeFOlCPy2urX9p9jWgo5kVKwTnGJs1K4ATtX1KnL2TNM0JLw1E sX+g== X-Gm-Message-State: ALoCoQnmNcxmV6hDLXqPWStb6psrxalvMft8jV+SLLFlWnum2P9u05w1zaH3TtBBKF8TDqOCz8y9 MIME-Version: 1.0 X-Received: by 10.112.180.131 with SMTP id do3mr10878470lbc.123.1447435120219; Fri, 13 Nov 2015 09:18:40 -0800 (PST) Received: by 10.112.144.106 with HTTP; Fri, 13 Nov 2015 09:18:40 -0800 (PST) In-Reply-To: <20151111.183543.1428883560546424512.mbj@tail-f.com> References: <1BE42550-64A1-4063-AD20-7093F51AA351@juniper.net> <20151111.183543.1428883560546424512.mbj@tail-f.com> Date: Fri, 13 Nov 2015 09:18:40 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c388542d30e605246f4020 Archived-At: Cc: Netconf Subject: Re: [Netconf] YANGLIB #5: how to list protocol-specific modules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 17:18:44 -0000 --001a11c388542d30e605246f4020 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Nov 11, 2015 at 9:35 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Wed, Nov 11, 2015 at 9:07 AM, Kent Watsen > wrote: > > > > > > > > Is there a better example than ietf-netconf? - I don=E2=80=99t thi= nk > > > ietf-netconf is a valid example as it=E2=80=99s not listed in a NETCO= NF > > > message - only it=E2=80=99s namespace is used, but that is quite diff= erent... > > > > > > If it=E2=80=99s just this one example, then I prefer option #1. > > > > > > > > One problem with option #1 is that it excludes static content as an > > implementation strategy. > > Agreed. > > > I cannot just have a static representation of all the YANG modules. > > Instead it has to > > be dynamically rendered or output with special code, in order to examin= e > > the protocol > > of the client and filter out entries based on that. > > > > Or I have a static representation for each protocol, which is kind of a > > waste if the > > difference is only 1 or 2 modules. > > > > A variant of option #2 is a hard-wired leaf (e.g. bits) with "netconf" > and > > "restconf" > > defined in the first release. > > If you're worried about the bits-on-the-wire, maybe we can have a > leaf-list: > > leaf-list restricted-protocol { ... } > > and if it is empty the module applies to all protocols. > > If NETCONF and RESTCONF clients are somehow stepping on each other's data, then how is either client supposed to know the other protocol is enabled and active? A per-protocol view does not allow any real diagnostics. If there was a global leaf-list like /modules/yang-protocol leaf-list yang-protocol { type identityref { base yang-protocol; } description "Identifies a protocol that is utilizing YANG-based content, which can be found in this YANG library"; } If this object is combined with the restricted-protocol, then either client can determine which protocols are supported for each module. > /martin > > > Andy > > > > > > > Kent > > > > > > > Andy > > > > > > > > > > > > > From: Netconf on behalf of Andy Bierman < > > > andy@yumaworks.com> > > > Date: Tuesday, November 10, 2015 at 6:16 PM > > > To: "netconf@ietf.org" > > > Subject: [Netconf] YANGLIB #5: how to list protocol-specific modules > > > > > > Hi, > > > > > > This open issue needs to be resolved. > > > https://github.com/netconf-wg/yang-library/issues/5 > > > > > > > > > There are 2 solution paths that have been suggested: > > > > > > YLIB5-01: separate views for each protocol. > > > Each protocol would receive only the modules that are enabled > > > for that protocol. > > > > > > YLIB5-02: add leaf-list to each module entry > > > NETCONF and RESTCONF identities can be defined right away. > > > Other protocols can define new identities on their own. > > > > > > leaf-list protocol { > > > type identityref { > > > base yang-protocol; > > > } > > > } > > > > > > > > > IMO both have drawbacks. > > > The server really tries to avoid protocol-dependent code. > > > The code that manages data does not care about protocols, > > > just internal representations of YANG data. > > > > > > The leaf-list approach is a waste of bandwidth unless the > > > YANG library is actually shared by multiple protocols > > > within a single server instance. > > > > > > So please discuss this issue on the mailing list and give your > preference > > > for a solution, or suggest a new solution. > > > > > > > > > Andy > > > > > > > --001a11c388542d30e605246f4020 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 11, 2015 at 9:35 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Wed, Nov 11, 2015 at 9:07 AM, Kent Watsen <kwatsen@juniper.net> wrote:
>
> >
> > Is there a better example than ietf-netconf?=C2=A0 =C2=A0 - I don= =E2=80=99t think
> > ietf-netconf is a valid example as it=E2=80=99s not listed in a N= ETCONF <hello>
> > message - only it=E2=80=99s namespace is used, but that is quite = different...
> >
> > If it=E2=80=99s just this one example, then I prefer option #1. > >
> >
> One problem with option #1 is that it excludes static content as an > implementation strategy.

Agreed.

> I cannot just have a static representation of all the YANG modules. > Instead it has to
> be dynamically rendered or output with special code, in order to exami= ne
> the protocol
> of the client and filter out entries based on that.
>
> Or I have a static representation for each protocol, which is kind of = a
> waste if the
> difference is only 1 or 2 modules.
>
> A variant of option #2 is a hard-wired leaf (e.g. bits) with "net= conf" and
> "restconf"
> defined in the first release.

If you're worried about the bits-on-the-wire, maybe we can have a
leaf-list:

=C2=A0 =C2=A0leaf-list restricted-protocol { ... }

and if it is empty the module applies to all protocols.



If NETCONF and RESTCONF= clients are somehow stepping on each other's
data, then how = is either client supposed to know the other protocol
is enabled a= nd active?

A per-protocol view does not allow any = real diagnostics.

If there was a global leaf-list = like /modules/yang-protocol

=C2=A0 =C2=A0leaf-list= yang-protocol {
=C2=A0 =C2=A0 =C2=A0type identityref {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0base yang-protocol;
=C2=A0 =C2= =A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0description
=C2=A0 =C2= =A0 =C2=A0 =C2=A0"Identifies a protocol that is utilizing YANG-based c= ontent,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 which can be found in this YA= NG library";
=C2=A0 }

If this objec= t is combined with the restricted-protocol, then either client
ca= n determine which protocols are supported for each module.


/martin



Andy
=C2=A0

>
>
> Kent
> >
>
> Andy
>
>
> >
> >
> > From: Netconf <net= conf-bounces@ietf.org> on behalf of Andy Bierman <
> > andy@yumaworks.com><= br> > > Date: Tuesday, November 10, 2015 at 6:16 PM
> > To: "netconf@ietf.org" <netconf@ietf.org> > > Subject: [Netconf] YANGLIB #5: how to list protocol-specific modu= les
> >
> > Hi,
> >
> > This open issue needs to be resolved.
> > https://github.com/netconf-wg/yang-libr= ary/issues/5
> >
> >
> > There are 2 solution paths that have been suggested:
> >
> > YLIB5-01: separate views for each protocol.
> > Each protocol would receive only the modules that are enabled
> > for that protocol.
> >
> > YLIB5-02: add leaf-list to each module entry
> > NETCONF and RESTCONF identities can be defined right away.
> > Other protocols can define new identities on their own.
> >
> >=C2=A0 =C2=A0 leaf-list protocol {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0type identityref {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0base yang-protocol;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> >=C2=A0 =C2=A0 }
> >
> >
> > IMO both have drawbacks.
> > The server really tries to avoid protocol-dependent code.
> > The code that manages data does not care about protocols,
> > just internal representations of YANG data.
> >
> > The leaf-list approach is a waste of bandwidth unless the
> > YANG library is actually shared by multiple protocols
> > within a single server instance.
> >
> > So please discuss this issue on the mailing list and give your pr= eference
> > for a solution, or suggest a new solution.
> >
> >
> > Andy
> >
> >

--001a11c388542d30e605246f4020-- From nobody Tue Nov 17 10:38:29 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769EE1B330F for ; Tue, 17 Nov 2015 10:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIzVtavZ6qY1 for ; Tue, 17 Nov 2015 10:38:22 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (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 4C8291B330A for ; Tue, 17 Nov 2015 10:38:22 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.15.2/8.15.2) with ESMTPS id tAHIcKNO009604 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 17 Nov 2015 18:38:20 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id tAHIcJhO029275 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 17 Nov 2015 19:38:19 +0100 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 17 Nov 2015 19:38:19 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.30]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0248.002; Tue, 17 Nov 2015 19:38:19 +0100 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: Draft NETCONF Session Minutes for IETF 94 Thread-Index: AdEhZrfMLsd7asjXTSSDpTxShiXWXw== Date: Tue, 17 Nov 2015 18:38:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.120] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F819838D2CDEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1882 X-purgate-ID: 151667::1447785500-000027D6-E720D854/0/0 Archived-At: Subject: [Netconf] Draft NETCONF Session Minutes for IETF 94 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 18:38:27 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F819838D2CDEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, below are the draft NETCONF session minutes from IETF 94. https://www.ietf.org/proceedings/94/minutes/minutes-94-netconf Please send a note to the co-chairs by Nov 24th, if you have any change req= uest. Mehmet & Mahesh --_000_E4DE949E6CE3E34993A2FF8AE79131F819838D2CDEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,
 
below are the draft NETCONF session minutes fr= om IETF 94.
 
Please send a note to the co-chairs by Nov 24t= h, if you have any change request.
 
Mehmet & Mahesh
 
 
 
 
 --_000_E4DE949E6CE3E34993A2FF8AE79131F819838D2CDEMUMBX005nsnin_-- From nobody Thu Nov 19 17:40:25 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD1A1A1A68 for ; Thu, 19 Nov 2015 17:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiUbhwwmK0_h for ; Thu, 19 Nov 2015 17:40:22 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 50FE01A1A67 for ; Thu, 19 Nov 2015 17:40:22 -0800 (PST) Received: by lffu14 with SMTP id u14so60011155lff.1 for ; Thu, 19 Nov 2015 17:40:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=Dti2Wm4PEsM9q0Vz8Swic9rfwG2w08uzM+Hl2DtSlos=; b=wlpMwVIEyl2Qs6w0y43iP5KBAW8I+7nnYOw2h5hV6+ws+j8kYuFtWT/WQ1TDFo3piF DX+a55yxRUdrBhYV6kS3aMZv53TFveieXnS/z2OnnBKCCWiMClHvUXTiB4i8URxOvcIL oNvreBtg0tNlpzuj9r9mARDtmh3NdawsDUXvpcIpbG1dIa0/2wp6r0O0JT0YTdjMnaEp jKvORbldTBePm91N0MR1vIfjea1mROT9GAht9GHHv8v1YHKkdZJz7X5urOepQYyvI6R1 K/xX+pVd1NYbkWk2C2UMcGWyH1SkiT4sgFu+GszCbOqQjp2aaeB47ToJ6cVZ1GFg+E8O GYiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Dti2Wm4PEsM9q0Vz8Swic9rfwG2w08uzM+Hl2DtSlos=; b=gwMqkZZwShXQrt2bL5aOaF48GRCI+rhFdGKNozkcBmaKHcvxp7nhbVw9xgHQLX0Npt jTUMnK3LW9yjlVGHCN55JdJ/KoJ1M39bmQrtQi98GYyFfdnlIM8P4E0sLPASvHn78ez8 o8FK/cEBZsBQ39uq4ybQrgEIg+lYF7dC1AWPloCTXvNXhjLlRN6zwumwCEQyjq6yQCB0 S0eWALCNLFz1rejsKnuDDxSu1MF9fAmtSb7wBkyspRmB8L2/r0F48tPrELew3eBt5fpp RMpsvsUa+xy5ipj0+Mm1p5FXqbB0PJJ5KBrayr/Qa51dy5DJSHBIcHw8CyWbC6VbElec gsiA== X-Gm-Message-State: ALoCoQliNzPbz1nBAMLy230AHpYiA57Oo0KPW4jXY0lSoyZAqC2qKY7+kZ9D7/G45O4U9+V4vexN MIME-Version: 1.0 X-Received: by 10.25.218.9 with SMTP id r9mr4723868lfg.138.1447983620358; Thu, 19 Nov 2015 17:40:20 -0800 (PST) Received: by 10.112.144.106 with HTTP; Thu, 19 Nov 2015 17:40:20 -0800 (PST) Date: Thu, 19 Nov 2015 17:40:20 -0800 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=001a11402600551e630524eef532 Archived-At: Subject: [Netconf] YANGLIB #5: how to list protocol-specific modules: Solution YL5-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 01:40:23 -0000 --001a11402600551e630524eef532 Content-Type: text/plain; charset=UTF-8 Hi, The following solution is proposed for the ietf-yang-library module, to address issue #5: 1) Add to global level: typedef yang-protocol { type identityref { base yang-protocol; } } identity yang-protocol; identity netconf-1.0 { base yang-protocol; } identity netconf-1.1 { base yang-protocol; } identity restconf-1.0 { base yang-protocol; } 2) Add to container modules: leaf-list yang-protocol { type yang-protocol; description "list all protocols using the YANG library"; } 3) Add to grouping module, list module: leaf-list restricted-protocol { type yang-protocol; description "Identifies a protocol found in /modules/yang-protocol that does not support this module"; } Andy --001a11402600551e630524eef532 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The following solution is proposed = for the ietf-yang-library module,
to address issue #5:
=

1) Add to global level:

<= div>typedef yang-protocol {
=C2=A0 =C2=A0type identityref { base = yang-protocol; }
}

identity yang-protoco= l;
identity netconf-1.0 { base yang-protocol; }
identit= y netconf-1.1 { base yang-protocol; }
identity restconf-1.0 {= base yang-protocol; }


2) = Add to container modules:

=C2=A0=C2=A0<= /div>
=C2=A0 leaf-list yang-protocol {
=C2=A0 =C2=A0 =C2=A0ty= pe yang-protocol;
=C2=A0 =C2=A0 =C2=A0description "lis= t all protocols using the YANG library";
=C2=A0 }
=

3) Add to grouping module, list module:
=

=C2=A0=C2=A0
=C2=A0 leaf-list restricted-prot= ocol {
=C2=A0 =C2=A0 =C2=A0 type yang-protocol;
=C2=A0 = =C2=A0 =C2=A0 =C2=A0description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 "Identifies a protocol found in /modules/yang-protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that does not support this modul= e";
=C2=A0 }


<= br>
Andy


--001a11402600551e630524eef532-- From nobody Fri Nov 20 00:37:40 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA151B2A64 for ; Fri, 20 Nov 2015 00:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.435 X-Spam-Level: X-Spam-Status: No, score=-4.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uMowwuNivLs for ; Fri, 20 Nov 2015 00:37:37 -0800 (PST) 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 DBC951B2A5E for ; Fri, 20 Nov 2015 00:37:36 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8B2C711FA; Fri, 20 Nov 2015 09:37:35 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Int7TiOecuxh; Fri, 20 Nov 2015 09:37:34 +0100 (CET) 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; Fri, 20 Nov 2015 09:37:34 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 81E8A2004E; Fri, 20 Nov 2015 09:37:34 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id j8SEoDbeO93R; Fri, 20 Nov 2015 09:37:33 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 744412003B; Fri, 20 Nov 2015 09:37:33 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1A18538E3F91; Fri, 20 Nov 2015 09:37:31 +0100 (CET) Date: Fri, 20 Nov 2015 09:37:30 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20151120083729.GA5315@elstar.local> Mail-Followup-To: Andy Bierman , Netconf References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Netconf Subject: Re: [Netconf] YANGLIB #5: how to list protocol-specific modules: Solution YL5-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 08:37:39 -0000 On Thu, Nov 19, 2015 at 05:40:20PM -0800, Andy Bierman wrote: > Hi, > > The following solution is proposed for the ietf-yang-library module, > to address issue #5: > > > 1) Add to global level: > > typedef yang-protocol { > type identityref { base yang-protocol; } > } > > identity yang-protocol; > identity netconf-1.0 { base yang-protocol; } > identity netconf-1.1 { base yang-protocol; } > identity restconf-1.0 { base yang-protocol; } Is the idea to revise the ietf-yang-library whenever a new protocol or protocol version comes along? Or would we be better served if the list of identities is maintained by IANA? > 2) Add to container modules: > > > leaf-list yang-protocol { > type yang-protocol; > description "list all protocols using the YANG library"; > } > > 3) Add to grouping module, list module: > > > leaf-list restricted-protocol { > type yang-protocol; > description > "Identifies a protocol found in /modules/yang-protocol > that does not support this module"; > } > Not sure whether 'restricted-protocol' is a good name. This is really 'not-supported-by'. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Nov 23 04:14:47 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39071A86F0 for ; Mon, 23 Nov 2015 04:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TZLvXg1Eohp for ; Mon, 23 Nov 2015 04:14:44 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BD1EB1A7028 for ; Mon, 23 Nov 2015 04:14:44 -0800 (PST) Received: from localhost (unknown [173.38.220.62]) by mail.tail-f.com (Postfix) with ESMTPSA id 6B7EF1AE0478; Mon, 23 Nov 2015 13:14:43 +0100 (CET) Date: Mon, 23 Nov 2015 13:14:43 +0100 (CET) Message-Id: <20151123.131443.1077534028322044699.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20151120083729.GA5315@elstar.local> References: <20151120083729.GA5315@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] YANGLIB #5: how to list protocol-specific modules: Solution YL5-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 12:14:46 -0000 Juergen Schoenwaelder wrote: > On Thu, Nov 19, 2015 at 05:40:20PM -0800, Andy Bierman wrote: > > Hi, > > > > The following solution is proposed for the ietf-yang-library module, > > to address issue #5: > > > > > > 1) Add to global level: > > > > typedef yang-protocol { > > type identityref { base yang-protocol; } > > } > > > > identity yang-protocol; > > identity netconf-1.0 { base yang-protocol; } > > identity netconf-1.1 { base yang-protocol; } > > identity restconf-1.0 { base yang-protocol; } > > Is the idea to revise the ietf-yang-library whenever a new protocol or > protocol version comes along? No. > Or would we be better served if the list > of identities is maintained by IANA? Probably. OTOH, since these are identities, they can be defined in any module... > > 2) Add to container modules: > > > > > > leaf-list yang-protocol { > > type yang-protocol; > > description "list all protocols using the YANG library"; > > } > > > > 3) Add to grouping module, list module: > > > > > > leaf-list restricted-protocol { > > type yang-protocol; > > description > > "Identifies a protocol found in /modules/yang-protocol > > that does not support this module"; > > } > > > > Not sure whether 'restricted-protocol' is a good name. This is really > 'not-supported-by'. Yes. BUT maybe this solution is not the best after all. The most common operation in this module is a client that wants to get a list of all modules supported in protocol X. With the proposed design, a NETCONF client cannot construct a subtree filter to retrieve just the modules for NETCONF. An XPath filter would look like this: /modules/module[not derived-from-or-self(restricted-protocol, "ietf-yang-library", "netconf-1.1")] But XPath is optional... OTOH, it may be ok to retrieve everything, and filter in the client, since we expect most modules to be available over all protocols. [Side note: I just realized a flaw in the definition of 'derived-from'; I will bring this up on the netmod ML.] /martin From nobody Mon Nov 23 05:32:54 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B1A1B38E3; Mon, 23 Nov 2015 05:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.485 X-Spam-Level: X-Spam-Status: No, score=-14.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6svKPt9H2blV; Mon, 23 Nov 2015 05:32:50 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E8631B38E1; Mon, 23 Nov 2015 05:32:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10139; q=dns/txt; s=iport; t=1448285570; x=1449495170; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=jEhoBpX2eVjbmDSLhj1wMa358jKfMmgo3CZY/HysGyw=; b=J0jhLyl+wHVCazhjTO6IItYg0KYkwrZEu+OnrF8qr6otoVIYWdoHZgko MYztvh1EMB3NEU+nSPsDPswqD4ipa0N/tRTSIYwa+cbpWXpDo8r3WloYn Kxnf77Ha+maeiwmZDmnowOORGLRfzfgAC37sKR+rJOkmXS3bkBVYMWjWs 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQB8FFNW/xbLJq1ehA64ZIcoAQ2BZ?= =?us-ascii?q?SGFbgKBdBQBAQEBAQEBgQqENQEBAwEjSwoBBQsLIRYLAgIJAwIBAgFFBg0IAQG?= =?us-ascii?q?IIggNrhePdQEBAQEBAQEBAgEBAQEBAQEBAQEZhlSEfoQqEQGDOYFEBYdHjwmFJ?= =?us-ascii?q?IgNgVtJg3eDAopZiFUfAQFChAU9hB6BQQEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,337,1444694400"; d="scan'208,217";a="612935618" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Nov 2015 13:32:48 +0000 Received: from [10.60.67.93] (ams-bclaise-89112.cisco.com [10.60.67.93]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tANDWlbM013026; Mon, 23 Nov 2015 13:32:47 GMT To: Netconf References: <5620C26D.7050202@cisco.com> <563B0B32.4000801@cisco.com> From: Benoit Claise Message-ID: <5653157F.5070401@cisco.com> Date: Mon, 23 Nov 2015 14:32:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563B0B32.4000801@cisco.com> Content-Type: multipart/alternative; boundary="------------070602040304060103020802" Archived-At: Cc: Barry Leiba , netconf-ads@ietf.org Subject: Re: [Netconf] Consensus on draft-leiba-netmod-regpolicy-update-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 13:32:53 -0000 This is a multi-part message in MIME format. --------------070602040304060103020802 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, > Dear all, > > During the NETCONF meeting today, there was no objection to > progressing the draft > https://tools.ietf.org/html/draft-leiba-netmod-regpolicy-update-00. > I would like to confirm consensus on the list with this email. > > The one sentence exec summary is: This document proposes that the > registration policy for the NETCONF Capability URNs registry is > lowered from Standards Action to IETF review, so that a document such > as draft-mm-netconf-time-capability-09 > > can register a new entry. > > The plan is to progress draft-leiba-netmod-regpolicy-update-00 as AD > sponsor in 2 weeks from now. Which I'm doing right now. Regards, Benoit > > Regards, Benoit > >> Dear all, >> >> https://tools.ietf.org/html/draft-leiba-netmod-regpolicy-update-00 >> >> This document, which updates the NETCONF Capability URNs registry >> policy, requires the process defined in RFC 2026. This means that it >> needs to be discussed, reviewed by the responsible AD, given an >> IETF-wide last call, and reviewed and approved by the IESG. >> >> I hope that it can go fairly quickly, as it's a simple action. >> Therefore, I propose to keep this document as an individual >> submission, which I will AD sponsor. However, neither Bary nor I are >> going to push this ahead against the working group's opposition. >> >> So it's time to speak up if you disagree with that policy change. >> A final consensus call will be made during the NETCONF meeting in >> Yokohama. >> >> Regards, Benoit (OPS AD) >> >>> For any who haven't followed it, we had a discussion about the >>> experimental document draft-mm-netconf-time-capability, which >>> registers a NETCONF capability URN. Here's my last comment on the >>> point, after I cleared my DISCUSS ballot: >>> >>> ---------- >>> The registration policy for the NETCONF Capability URNs registry is >>> Standards Action, and this document, with Experimental status, does >>> not meet the requirement that the registration come from a Standards >>> Track RFC. This document cannot make that registration. >>> >>> After discussion about whether the IESG should make an exception in >>> this case and allow the registration, I agree that it's the right >>> thing to do for this document, so I've cleared my DISCUSS ballot on >>> that point. >>> >>> But at the same time, it seems that the registration policy is too >>> strict, and should be IETF Review, which allows the NETCONF working >>> group to make the decision by getting IETF consensus on the >>> registration -- there's no need to specifically require a Standards >>> Track RFC. To that end, I've submitted an Internet draft, >>> draft-leiba-netmod-regpolicy-update, which I ask the Network >>> Operations AD to sponsor, in coordination with the NETCONF working >>> group. >>> ---------- >>> >>> I typo'ed the filename (made it "-netmod-" rather than "-netconf-"); >>> sorry about that. In any case, the NETCONF working group should look >>> at it and comment. It's straightforward, just changing the >>> registration policy and explaining why. I don't expect there'll be >>> controversy with it, but please do give it a review and comment, and >>> let Benoît and Joel know if y'all think it's acceptable for one of >>> them to AD-sponsor: >>> https://datatracker.ietf.org/doc/draft-leiba-netmod-regpolicy-update/ >>> >>> Please keep me on CC for any discussion, so I'll see the messages, >>> though I'll also keep an eye on the mailing list archive. >>> >>> Thanks, >>> Barry, ART AD >>> . >>> >> >> . >> > --------------070602040304060103020802 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Dear all,

Dear all,

During the NETCONF meeting today, there was no objection to progressing the draft https://tools.ietf.org/html/draft-leiba-netmod-regpolicy-update-00.
I would like to confirm consensus on the list with this email.

The one sentence exec summary is: This document proposes that the registration policy for the NETCONF Capability URNs registry is lowered from Standards Action to IETF review, so that a document such as draft-mm-netconf-time-capability-09 can register a new entry.

The plan is to progress draft-leiba-netmod-regpolicy-update-00 as AD sponsor in 2 weeks from now.
Which I'm doing right now.

Regards, Benoit

Regards, Benoit

Dear all,

https://tools.ietf.org/html/draft-leiba-netmod-regpolicy-update-00

This document, which updates the NETCONF Capability URNs registry policy, requires the process defined in RFC 2026. This means that it needs to be discussed, reviewed by the responsible AD, given an IETF-wide last call, and reviewed and approved by the IESG.

I hope that it can go fairly quickly, as it's a simple action. Therefore, I propose to keep this document as an individual submission, which I will AD sponsor.  However, neither Bary nor I are going to push this ahead against the working group's opposition.

So it's time to speak up if you disagree with that policy change.
A final consensus call will be made during the NETCONF meeting in Yokohama.

Regards, Benoit (OPS AD)

For any who haven't followed it, we had a discussion about the
experimental document draft-mm-netconf-time-capability, which
registers a NETCONF capability URN.  Here's my last comment on the
point, after I cleared my DISCUSS ballot:

----------
The registration policy for the NETCONF Capability URNs registry is
Standards Action, and this document, with Experimental status, does
not meet the requirement that the registration come from a Standards
Track RFC.  This document cannot make that registration.

After discussion about whether the IESG should make an exception in
this case and allow the registration, I agree that it's the right
thing to do for this document, so I've cleared my DISCUSS ballot on
that point.

But at the same time, it seems that the registration policy is too
strict, and should be IETF Review, which allows the NETCONF working
group to make the decision by getting IETF consensus on the
registration -- there's no need to specifically require a Standards
Track RFC.  To that end, I've submitted an Internet draft,
draft-leiba-netmod-regpolicy-update, which I ask the Network
Operations AD to sponsor, in coordination with the NETCONF working
group.
----------

I typo'ed the filename (made it "-netmod-" rather than "-netconf-");
sorry about that.  In any case, the NETCONF working group should look
at it and comment.  It's straightforward, just changing the
registration policy and explaining why.  I don't expect there'll be
controversy with it, but please do give it a review and comment, and
let Benoît and Joel know if y'all think it's acceptable for one of
them to AD-sponsor:
https://datatracker.ietf.org/doc/draft-leiba-netmod-regpolicy-update/

Please keep me on CC for any discussion, so I'll see the messages,
though I'll also keep an eye on the mailing list archive.

Thanks,
Barry, ART AD
.


.



--------------070602040304060103020802-- From nobody Mon Nov 23 17:11:17 2015 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5AB1B2B0F; Mon, 23 Nov 2015 17:11:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151124011115.19951.95829.idtracker@ietfa.amsl.com> Date: Mon, 23 Nov 2015 17:11:15 -0800 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-call-home-12.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 01:11:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Call Home and RESTCONF Call Home Author : Kent Watsen Filename : draft-ietf-netconf-call-home-12.txt Pages : 17 Date : 2015-11-23 Abstract: This RFC presents NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client respectively. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-call-home-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-call-home-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 23 17:18:53 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82151B2B23 for ; Mon, 23 Nov 2015 17:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8g1_-7_HOad for ; Mon, 23 Nov 2015 17:18:49 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0107.outbound.protection.outlook.com [207.46.100.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C02D1B2B10 for ; Mon, 23 Nov 2015 17:18:49 -0800 (PST) Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 24 Nov 2015 01:18:47 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0331.019; Tue, 24 Nov 2015 01:18:47 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-call-home-12.txt Thread-Index: AQHRJlURMTnIT2lJoEyludvg9NUuwJ6qC6SA Date: Tue, 24 Nov 2015 01:18:47 +0000 Message-ID: References: <20151124011115.19951.95829.idtracker@ietfa.amsl.com> In-Reply-To: <20151124011115.19951.95829.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 5:nYD+Ro5G5Lw+Vpp3z+3EW6dAtuxfQLtHxNyH+xk0mriNWCxcn8fQDOkaz1NM0gu4TE2vZaLytq69SlsBsW8coPlL04s9M9NdePyrJt1tbtbO7RvfsGuZRTbkO+CApOys2v0irx0oDBKPetWQkwUBoQ==; 24:xn+sr4UwZM2js3sIwQao9e9bEuHRR6aLK3i8qrNrEVxMu+9ykghckkeGJj/El+UxBGaVbbP064q00eLKDXygj9gbTREEmQq1gdVV3LUstHk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 0770F75EA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(164054003)(189002)(24454002)(479174004)(199003)(377454003)(83506001)(15975445007)(230783001)(5001960100002)(2900100001)(77096005)(5004730100002)(3846002)(87936001)(102836003)(5002640100001)(6116002)(110136002)(83716003)(99286002)(107886002)(82746002)(66066001)(101416001)(36756003)(10400500002)(450100001)(2351001)(106356001)(19580395003)(106116001)(40100003)(586003)(105586002)(4001150100001)(54356999)(92566002)(5007970100001)(122556002)(2950100001)(33656002)(86362001)(11100500001)(2501003)(575784001)(76176999)(189998001)(5008740100001)(50986999)(97736004)(4001350100001)(81156007)(19580405001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2015 01:18:47.5288 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444 Archived-At: Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-call-home-12.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 01:18:51 -0000 DQpBbGwsDQoNClRoaXMgdXBkYXRlIGFkZHJlc3NlcyB0aGUgY29tbWVudHMgcmVjZWl2ZWQgZnJv bSB0aGUgSUVTRyByZXZpZXcgYXMgZm9sbG93czoNCg0KDQoxLiBSZXBsYWNlIOKAnGNhbiByZWZl cuKAnSB3aXRoIOKAnHJlZmVyc+KAnSAoU2ltb24gSm9zZWZzc29uKToNCmh0dHBzOi8vZ2l0aHVi LmNvbS9uZXRjb25mLXdnL2NhbGwtaG9tZS9jb21taXQvZmY4Nzc1MTE5MzMzMzhjMGVhMjk2MTcz MmJlNzhkMmU2MzJjYjEyMA0KDQoyLiBSZXBsYWNlIOKAnE1VU1QgaW1tZWRpYXRlbHkgc3RhcnTi gJ0gd2l0aCDigJxzdGFydHPigJ0gIChGcm9tIEJhcnJ5IExlaWJhLCBTdXJlc2ggS3Jpc2huYW4s IGFuZCBKYXJpIEFya2tvKToNCmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL2NhbGwtaG9t ZS9jb21taXQvZGUwNWU3ZDYzMjExNTRmMzNkMzVlMWFiZGU5OTU2YjFmOWRmM2VmYw0KDQozLiBB ZGRlZCBjb21tZW50IGZvciB0aGUgU1NIL1RMUy1jbGllbnQgRG9TIGNvbmNlcm4gIChTdGVwaGVu IEZhcnJlbGwgYW5kIEpvc2VwaCBTYWxvd2V5KQ0KaHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYt d2cvY2FsbC1ob21lL2NvbW1pdC85OWZiMDg3YTZiZjEzYWM5MGRlNWZkNWJiZTBlOWY0NGU3ZmQw MjVkIA0KDQo0LiBBZGRlZCBjb21tZW50IHJlZ2FyZGluZyB2dWxuZXJhYmlsaXR5IGluIFNTSC9U TFMgY2xpZW50cy4gKFN0ZXBoZW4gRmFycmVsbCBhbmQgSm9zZXBoIFNhbG93ZXkpDQpodHRwczov L2dpdGh1Yi5jb20vbmV0Y29uZi13Zy9jYWxsLWhvbWUvY29tbWl0LzhkMGIwNDVkN2I4ZjYzYzBj N2E0YTNlMzdjODIxODFmOTUzZGJkYTINCg0KNS4gQWRkcmVzc2VkIGNvbmNlcm4gdGhhdCBtdWx0 aXBsZSBJc3N1ZXJzIG1heSBoYXZlIG92ZXJsYXBwaW5nIHVuaXF1ZSBpZGVudGlmaWVycyAoU3Rl cGhlbiBGYXJyZWxsIGFuZCBKb3NlcGggU2Fsb3dleSkNCmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRj b25mLXdnL2NhbGwtaG9tZS9jb21taXQvMWI5ZDU0ZjVmNGI0NDFjOGM3OWQ2NWIwMzgwODBiNDAy ZTdlMGFiNA0KDQo2LiBBZGRyZXNzZWQgY29uY2VybiByZWdhcmRpbmcgcmV2b2NhdGlvbiBjaGVj a2luZyAoU3RlcGhlbiBGYXJyZWxsKQ0KaHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvY2Fs bC1ob21lL2NvbW1pdC8zODllOGFlYjNmOGZmM2FmM2MwM2ZkN2FmMjhiZmY1YjU1NWU3MzgzDQoN CjcuIEFkZGluZyBzdGF0ZW1lbnQgZW5zdXJpbmcgY2xpZW50IHNlbmRzIGNvcnJlY3QgY2xpZW50 LWF1dGggKFN0ZXBoZW4gRmFycmVsbCBhbmQgS2F0aGxlZW4gTW9yaWFydHkpDQpodHRwczovL2dp dGh1Yi5jb20vbmV0Y29uZi13Zy9jYWxsLWhvbWUvY29tbWl0L2YxZjNmYjhmM2Y1YjM5ZWExMjQx YzgxYjY1NWM4NGE2YjkzM2Y2MDgNCg0KOC4gQ2xhcmlmaWVkIGluIFM1IHRoYXQgY2xpZW50IGF1 dGggcmVnYXJkcyAidHJhbnNwb3J0IChTU0ggb3IgVExTKSBsZXZlbOKAnSBjbGllbnQgYXV0aCAo S2F0aGxlZW4gTW9yaWFydHkpDQpodHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy9jYWxsLWhv bWUvY29tbWl0LzcwOWI0ZjM1N2I1ZTRhMjUxMDUyNjQ3MjgyNzU1MjY1OWQ5M2ExNDYNCg0KOS4g UmV3b3JkZWQgUzUgdG8gbW9yZSBjbGVhcmx5IGluZGljYXRlIHRoYXQgdHJhbnNwb3J0LWxldmVs IGNsaWVudCBhdXRoIGlzIGFsd2F5cyBleGNlcHQgZm9yIGluIHNvbWUgUkVTVENPTkYgY2FzZXMg KEthdGhsZWVuIE1vcmlhcnR5KQ0KaHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvY2FsbC1o b21lL2NvbW1pdC9kNjM5OGQwMDI1ODM3NTRkZDA0MDI0YTNhMzYwNDliMmQyN2QzN2VlDQoNCjEw LiBRdWFsaWZpZWQgdGhhdCB0aGUgInNlY3VyaXR5IGFuYWx5c2lzIiBmb3IgY2FsbCBob21lIHdh cy9pcyB0aGUgcHJvY2VzcyBvZiBwdWJsaXNoaW5nIHRoZSBkcmFmdC4gKEthdGhsZWVuIE1vcmlh cnR5KQ0KaHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvY2FsbC1ob21lL2NvbW1pdC84MjBk NTRlMGRkYjE0ZmYxYzg1ODUzOTA3ZWI1MDdkMTM2YTg3NzhlDQoNCjExLiBhZGRlZCBhIHNwZWNp YWwgd2FybmluZyByZWdhcmRpbmcgQmFzaWMgYW5kIERpZ2VzdCBhdXRoIHNjaGVtZXMgICAoS2F0 aGxlZW4gTW9yaWFydHkpDQpodHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy9jYWxsLWhvbWUv Y29tbWl0LzFiZDRmN2NjYmJlZDM4YTU4Mjk0ZjEwYmExN2ZiM2UxMDFhYzJiM2MNCg0KMTIuIFJl cGxhY2UgIlRoaXMgaXMgbm8gZGlmZmVyZW50IHRoYW4gYW554oCdIHdpdGggIlRoaXMgaXMgc2lt aWxhciB0byBhbnkgb3RoZXIiICAoQmVuIENhbXBiZWxsKQ0KaHR0cHM6Ly9naXRodWIuY29tL25l dGNvbmYtd2cvY2FsbC1ob21lL2NvbW1pdC9mNmI2NzA4ODVhYjBhNzNkOTk0MGRiYWZmM2NjODAx MDYyZDU5MDZkDQoNCjEzLiBDbGFyaWZpZWQgUzEgYW5kIEMxIHdpdGggIk1VU1QgZGVmYXVsdCB0 byBJQU5BIHBvcnRz4oCdDQooQmVuIENhbXBiZWxsIGFuZCBNYXJ0aW4gU3RpZW1lcmxpbmcsIGFu ZCBTcGVuY2VyIERhd2tpbnMpDQpodHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy9jYWxsLWhv bWUvY29tbWl0L2FlMmNkZTc1MzZlMTdhNjg4NmFmM2YwNWEwODRjZDljM2I2MzI2MDkNCmh0dHBz Oi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL2NhbGwtaG9tZS9jb21taXQvY2I3ZDE0NzU4N2MwMWUy ZThhZGRkMmYzNjI3Mzk5NzNiYjY1ZDE3NA0KDQoxNC4gQWRkZWQgYW4gb3ZlcnZpZXcgZGlhZ3Jh bSAgKE1hcnRpbiBTdGllbWVybGluZykNCmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL2Nh bGwtaG9tZS9jb21taXQvZjRiZTc2YTM0OGUyNTFhNDFhNTEwMzVhMTZjZTM2N2NjZWQxYjRmMg0K DQoNCg0KVGhhbmtzLA0KDQpLZW50DQoNCg0KDQoNCg0KDQoNCg0KDQpPbiAxMS8yMy8xNSwgODox MSBQTSwgIk5ldGNvbmYgb24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPG5l dGNvbmYtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPiB3cm90ZToNCg0KPg0KPkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9t IHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4gVGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgTmV0d29yayBDb25maWd1cmF0aW9uIFdvcmtpbmcgR3JvdXAg b2YgdGhlIElFVEYuDQo+DQo+ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBORVRDT05GIENhbGwg SG9tZSBhbmQgUkVTVENPTkYgQ2FsbCBIb21lDQo+ICAgICAgICBBdXRob3IgICAgICAgICAgOiBL ZW50IFdhdHNlbg0KPglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW5ldGNvbmYtY2FsbC1o b21lLTEyLnR4dA0KPglQYWdlcyAgICAgICAgICAgOiAxNw0KPglEYXRlICAgICAgICAgICAgOiAy MDE1LTExLTIzDQo+DQo+QWJzdHJhY3Q6DQo+ICAgVGhpcyBSRkMgcHJlc2VudHMgTkVUQ09ORiBD YWxsIEhvbWUgYW5kIFJFU1RDT05GIENhbGwgSG9tZSwgd2hpY2gNCj4gICBlbmFibGUgYSBORVRD T05GIG9yIFJFU1RDT05GIHNlcnZlciB0byBpbml0aWF0ZSBhIHNlY3VyZSBjb25uZWN0aW9uDQo+ ICAgdG8gYSBORVRDT05GIG9yIFJFU1RDT05GIGNsaWVudCByZXNwZWN0aXZlbHkuDQo+DQo+DQo+ VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRjb25mLWNhbGwtaG9t ZS8NCj4NCj5UaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj5o dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLWNhbGwtaG9tZS0x Mg0KPg0KPkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoN Cj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1uZXRjb25mLWNh bGwtaG9tZS0xMg0KPg0KPg0KPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj51bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPg0K PkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoN Cj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPg0KPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+TmV0Y29uZiBtYWlsaW5nIGxpc3QN Cj5OZXRjb25mQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRjb25mDQo= From nobody Tue Nov 24 05:25:28 2015 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0421A6F03; Tue, 24 Nov 2015 05:25:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151124132526.9838.90989.idtracker@ietfa.amsl.com> Date: Tue, 24 Nov 2015 05:25:26 -0800 Archived-At: Cc: netconf-chairs@ietf.org, draft-ietf-netconf-call-home@ietf.org, netconf@ietf.org Subject: [Netconf] Stephen Farrell's No Objection on draft-ietf-netconf-call-home-12: (with COMMENT) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 13:25:26 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-netconf-call-home-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my discuss points. Just a couple of nits remain that I can see. - Typo: "SSH and clients may not be as robust" is missing a TLS I guess. -Saying "don't use Verisign" seems a bit wrong, maybe re-word that. From nobody Tue Nov 24 06:15:37 2015 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A84051A1B5A; Tue, 24 Nov 2015 06:15:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151124141535.4194.80081.idtracker@ietfa.amsl.com> Date: Tue, 24 Nov 2015 06:15:35 -0800 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-call-home-13.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 14:15:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Call Home and RESTCONF Call Home Author : Kent Watsen Filename : draft-ietf-netconf-call-home-13.txt Pages : 17 Date : 2015-11-24 Abstract: This RFC presents NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client respectively. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-call-home/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-call-home-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-call-home-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 24 06:18:51 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE781A6FEE for ; Tue, 24 Nov 2015 06:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbroE-YGo5aQ for ; Tue, 24 Nov 2015 06:18:44 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0117.outbound.protection.outlook.com [65.55.169.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 591D91A1B6F for ; Tue, 24 Nov 2015 06:18:44 -0800 (PST) Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 24 Nov 2015 14:18:41 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0331.019; Tue, 24 Nov 2015 14:18:41 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-call-home-13.txt Thread-Index: AQHRJsKYEQHUjEXaM0OZEuJ7ls8JLJ6q5LKA Date: Tue, 24 Nov 2015 14:18:41 +0000 Message-ID: <816734FF-E6C4-4926-9CED-4AC021D28756@juniper.net> References: <20151124141535.4194.80081.idtracker@ietfa.amsl.com> In-Reply-To: <20151124141535.4194.80081.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 5:h2tklCevx1KxYEO+6zvu2Jqurjn38Xqs+4ogCajIplfMJ2JnO0GJiZQZZsSBFb9jMMzyl3de424orKHOuFouD106FB6TFRGFaArvz86KUg78FcxCcG+V306y+rjZSBcI87WOUIeS4HoB3a0T5E46cQ==; 24:Z1QS+lPC9Mo3XhsGnvgrAYq72kT+GFZNVRTQ3UkiNySSr6nhgiIWBcQzwMp5VryMdxaq5hPO4BInd2mSEAE2U2GGpjgOi2vo6i8CF3Y/R2w= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 0770F75EA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(189002)(199003)(24454002)(377424004)(164054003)(479174004)(5004730100002)(189998001)(76176999)(92566002)(19580405001)(230783001)(5008740100001)(15975445007)(36756003)(2501003)(19580395003)(50986999)(3846002)(86362001)(54356999)(106356001)(106116001)(6116002)(99286002)(102836003)(11100500001)(110136002)(87936001)(66066001)(5007970100001)(105586002)(5002640100001)(5001960100002)(83716003)(2950100001)(83506001)(77096005)(586003)(40100003)(33656002)(10400500002)(4001350100001)(101416001)(97736004)(2351001)(81156007)(4001150100001)(122556002)(82746002)(2900100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <2785CA18C6A51D42A4F3D60FC0D76AE5@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2015 14:18:41.1617 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Cc: Stephen Farrell Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-call-home-13.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 14:18:49 -0000 DQpUaGlzIHVwZGF0ZSBhZGRyZXNzZXMgU3RlcGhlbuKAmXMgY29tbWVudHMgZnJvbSB0aGlzIG1v cm5pbmc6DQoNCiAgLSBGaXhlZCBhIGNvdXBsZSB0eXBvcyBhbmQgcmVtb3ZlZCB0aGUgVmVyaVNp Z24gZXhhbXBsZQ0KDQpUaGFua3MsDQpLZW50DQoNCg0KDQoNCg0KT24gMTEvMjQvMTUsIDk6MTUg QU0sICJOZXRjb25mIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxuZXRj b25mLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9y Zz4gd3JvdGU6DQoNCj4NCj5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0 aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+IFRoaXMgZHJhZnQgaXMg YSB3b3JrIGl0ZW0gb2YgdGhlIE5ldHdvcmsgQ29uZmlndXJhdGlvbiBXb3JraW5nIEdyb3VwIG9m IHRoZSBJRVRGLg0KPg0KPiAgICAgICAgVGl0bGUgICAgICAgICAgIDogTkVUQ09ORiBDYWxsIEhv bWUgYW5kIFJFU1RDT05GIENhbGwgSG9tZQ0KPiAgICAgICAgQXV0aG9yICAgICAgICAgIDogS2Vu dCBXYXRzZW4NCj4JRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1uZXRjb25mLWNhbGwtaG9t ZS0xMy50eHQNCj4JUGFnZXMgICAgICAgICAgIDogMTcNCj4JRGF0ZSAgICAgICAgICAgIDogMjAx NS0xMS0yNA0KPg0KPkFic3RyYWN0Og0KPiAgIFRoaXMgUkZDIHByZXNlbnRzIE5FVENPTkYgQ2Fs bCBIb21lIGFuZCBSRVNUQ09ORiBDYWxsIEhvbWUsIHdoaWNoDQo+ICAgZW5hYmxlIGEgTkVUQ09O RiBvciBSRVNUQ09ORiBzZXJ2ZXIgdG8gaW5pdGlhdGUgYSBzZWN1cmUgY29ubmVjdGlvbg0KPiAg IHRvIGEgTkVUQ09ORiBvciBSRVNUQ09ORiBjbGllbnQgcmVzcGVjdGl2ZWx5Lg0KPg0KPg0KPlRo ZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi1jYWxsLWhvbWUv DQo+DQo+VGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1jYWxsLWhvbWUtMTMN Cj4NCj5BIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbmV0Y29uZi1jYWxs LWhvbWUtMTMNCj4NCj4NCj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+dW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4NCj5J bnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4NCj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPk5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ TmV0Y29uZkBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bmV0Y29uZg0K From keshavkrishna88@gmail.com Mon Nov 23 07:17:58 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F96E1A87E1 for ; Mon, 23 Nov 2015 07:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Az51sXdQn6jc for ; Mon, 23 Nov 2015 07:17:57 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 8421D1A877B for ; Mon, 23 Nov 2015 07:17:57 -0800 (PST) Received: by iofh3 with SMTP id h3so190254771iof.3 for ; Mon, 23 Nov 2015 07:17:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=AKhEldFqYOj80IUgSrXz/Y3X0DIrUYaODZG+t4eAX4Y=; b=dm410hXSv9NwyniN2XnkHZ9nlhiiVtETwoaqaUanTf8rkcmuZpLEpuZsIoubCA8HgR t+cLJPiH4aip9Tn9jdGbgXZzJt5rsqS4NUYFZmSbYmQwyNlx0WdTd7HtLpw0kLmyOOzU Uy4vScHW7etTKbkTJTHS/vpglCC7LdQM3VGtkbbtCPh/KX9fqUdZ2eb0mOdx7xAJvUa/ /ngltkNaY4wKaZRIh47o0beta08Wv1CipheJ4HWSgA6ynRfFR88FMENtqeaAh7OdQtkN 1QJzVAe/qWWRBxHLNjdKFPKxgzj8wWDFzIpwd7293MT78NPgT22KPtXaNlGCVsWbGur4 4ECA== X-Received: by 10.107.10.66 with SMTP id u63mr24017617ioi.86.1448291876947; Mon, 23 Nov 2015 07:17:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.36.209 with HTTP; Mon, 23 Nov 2015 07:17:37 -0800 (PST) From: Keshava Krishna Bhat K Date: Mon, 23 Nov 2015 20:47:37 +0530 Message-ID: To: netconf@ietf.org Content-Type: multipart/alternative; boundary=001a113f93bedb4bc7052536baa4 Archived-At: X-Mailman-Approved-At: Tue, 24 Nov 2015 08:28:07 -0800 Subject: [Netconf] get/get-config with invalid filter elements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 15:22:32 -0000 --001a113f93bedb4bc7052536baa4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BHi, What should be a NC server=E2=80=99s response when a get is done with valid= and invalid filters ? For example: Now should the server reply with rpc-reply OR rpc-error (maybe unknown-namespace) ? Related question: What should be the server's response to a get-config rpc which has a state filter? Regards, Keshava. --001a113f93bedb4bc7052536baa4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BHi,
=C2=A0
=
What should be a NC server=E2=80=99s response when a get is d= one with valid and invalid filters ?

For example:
<= ;filter>
=C2=A0 <root xmlns=3D"valid:namespac= e">
=C2=A0 =C2=A0 <invalid-node xmlns=3D"= ;invalid:naespace"/> <!=E2=80=94 invalid item -->
=C2=A0 =C2=A0 &l= t;valid-level1-node/> <!=E2=80=94 valid item -->
=C2=A0 </root>=
</filter>

Now should the server reply with rpc-reply OR rpc-error (maybe unknown-= namespace) ?

Related question:
What should be the server's response to a get-config = rpc which has a state filter?

Regards,
Keshava.
--001a113f93bedb4bc7052536baa4-- From nobody Tue Nov 24 08:28:21 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247A31B2E55 for ; Mon, 23 Nov 2015 22:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttAtnD0I5e9d for ; Mon, 23 Nov 2015 22:22:47 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 564AE1A0121 for ; Mon, 23 Nov 2015 22:22:47 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 94F77180005; Mon, 23 Nov 2015 22:21:11 -0800 (PST) To: rob.enns@gmail.com, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, andy@yumaworks.com, bclaise@cisco.com, joelja@bogus.com, mjethanandani@gmail.com, mehmet.ersue@nokia.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20151124062111.94F77180005@rfc-editor.org> Date: Mon, 23 Nov 2015 22:21:11 -0800 (PST) Archived-At: X-Mailman-Approved-At: Tue, 24 Nov 2015 08:28:17 -0800 Cc: keshavkrishna88@gmail.com, netconf@ietf.org, rfc-editor@rfc-editor.org Subject: [Netconf] [Technical Errata Reported] RFC6241 (4543) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 06:22:49 -0000 The following errata report has been submitted for RFC6241, "Network Configuration Protocol (NETCONF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=4543 -------------------------------------- Type: Technical Reported by: Keshava Bhat Section: 6.1 Original Text ------------- XML subtree filtering is a mechanism that allows an application to select particular XML subtrees to include in the for a or operation. A small set of filters for inclusion, simple content exact-match, and selection is provided, which allows some useful, but also very limited, selection mechanisms. The server does not need to utilize any data-model- specific semantics during processing, allowing for simple and centralized implementation strategies. Conceptually, a subtree filter is comprised of zero or more element subtrees, which represent the filter selection criteria. At each containment level within a subtree, the set of sibling nodes is logically processed by the server to determine if its subtree and path of elements to the root are included in the filter output. Each node specified in a subtree filter represents an inclusive filter. Only associated nodes in underlying data model(s) within the specified datastore on the server are selected by the filter. A node is selected if it matches the selection criteria and hierarchy of elements given in the filter data, except that the filter absolute path name is adjusted to start from the layer below . Response messages contain only the subtrees selected by the filter. Any selection criteria that were present in the request, within a particular selected subtree, are also included in the response. Note that some elements expressed in the filter as leaf nodes will be expanded (i.e., subtrees included) in the filter output. Specific data instances are not duplicated in the response in the event that the request contains multiple filter subtree expressions that select the same data. Corrected Text -------------- XML subtree filtering is a mechanism that allows an application to select particular XML subtrees to include in the for a or operation. A small set of filters for inclusion, simple content exact-match, and selection is provided, which allows some useful, but also very limited, selection mechanisms. The server does not need to utilize any data-model- specific semantics during processing, allowing for simple and centralized implementation strategies. Conceptually, a subtree filter is comprised of zero or more element subtrees, which represent the filter selection criteria. At each containment level within a subtree, the set of sibling nodes is logically processed by the server to determine if its subtree and path of elements to the root are included in the filter output. Each node specified in a subtree filter represents an inclusive filter. Only associated nodes in underlying data model(s) within the specified datastore on the server are selected by the filter. A node is selected if it matches the selection criteria and hierarchy of elements given in the filter data, except that the filter absolute path name is adjusted to start from the layer below . Response messages contain only the subtrees selected by the filter. Any selection criteria that were present in the request, within a particular selected subtree, are also included in the response. Note that some elements expressed in the filter as leaf nodes will be expanded (i.e., subtrees included) in the filter output. Specific data instances are not duplicated in the response in the event that the request contains multiple filter subtree expressions that select the same data. Notes ----- It is not clear in the RFC what a netcofn server should do when it encounters invalid nodes in a subtree filter in case of get/get-config RPC Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6241 (draft-ietf-netconf-4741bis-10) -------------------------------------- Title : Network Configuration Protocol (NETCONF) Publication Date : June 2011 Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed. Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue Nov 24 08:28:23 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD2A1B2E64 for ; Mon, 23 Nov 2015 22:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tySbQsSgKwfS for ; Mon, 23 Nov 2015 22:26:30 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 19B1A1B2E5C for ; Mon, 23 Nov 2015 22:26:30 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 51E58180006; Mon, 23 Nov 2015 22:24:54 -0800 (PST) To: rob.enns@gmail.com, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, andy@yumaworks.com, bclaise@cisco.com, joelja@bogus.com, mjethanandani@gmail.com, mehmet.ersue@nokia.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20151124062454.51E58180006@rfc-editor.org> Date: Mon, 23 Nov 2015 22:24:54 -0800 (PST) Archived-At: X-Mailman-Approved-At: Tue, 24 Nov 2015 08:28:17 -0800 Cc: keshavkrishna88@gmail.com, netconf@ietf.org, rfc-editor@rfc-editor.org Subject: [Netconf] [Technical Errata Reported] RFC6241 (4544) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 06:26:33 -0000 The following errata report has been submitted for RFC6241, "Network Configuration Protocol (NETCONF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=4544 -------------------------------------- Type: Technical Reported by: Keshava Bhat Section: 6.1 Original Text ------------- XML subtree filtering is a mechanism that allows an application to select particular XML subtrees to include in the for a or operation. A small set of filters for inclusion, simple content exact-match, and selection is provided, which allows some useful, but also very limited, selection mechanisms. The server does not need to utilize any data-model- specific semantics during processing, allowing for simple and centralized implementation strategies. Conceptually, a subtree filter is comprised of zero or more element subtrees, which represent the filter selection criteria. At each containment level within a subtree, the set of sibling nodes is logically processed by the server to determine if its subtree and path of elements to the root are included in the filter output. Each node specified in a subtree filter represents an inclusive filter. Only associated nodes in underlying data model(s) within the specified datastore on the server are selected by the filter. A node is selected if it matches the selection criteria and hierarchy of elements given in the filter data, except that the filter absolute path name is adjusted to start from the layer below . Response messages contain only the subtrees selected by the filter. Any selection criteria that were present in the request, within a particular selected subtree, are also included in the response. Note that some elements expressed in the filter as leaf nodes will be expanded (i.e., subtrees included) in the filter output. Specific data instances are not duplicated in the response in the event that the request contains multiple filter subtree expressions that select the same data. Corrected Text -------------- XML subtree filtering is a mechanism that allows an application to select particular XML subtrees to include in the for a or operation. A small set of filters for inclusion, simple content exact-match, and selection is provided, which allows some useful, but also very limited, selection mechanisms. The server does not need to utilize any data-model- specific semantics during processing, allowing for simple and centralized implementation strategies. Conceptually, a subtree filter is comprised of zero or more element subtrees, which represent the filter selection criteria. At each containment level within a subtree, the set of sibling nodes is logically processed by the server to determine if its subtree and path of elements to the root are included in the filter output. Each node specified in a subtree filter represents an inclusive filter. Only associated nodes in underlying data model(s) within the specified datastore on the server are selected by the filter. A node is selected if it matches the selection criteria and hierarchy of elements given in the filter data, except that the filter absolute path name is adjusted to start from the layer below . Response messages contain only the subtrees selected by the filter. Any selection criteria that were present in the request, within a particular selected subtree, are also included in the response. Note that some elements expressed in the filter as leaf nodes will be expanded (i.e., subtrees included) in the filter output. Specific data instances are not duplicated in the response in the event that the request contains multiple filter subtree expressions that select the same data. When a node in the subtree filter is unknown, the server sends a as reply with \\"unknown-element\\" error-tag. In case of RPC, if the subtree filter contains a node that is not a configuration node, the server sends as reply with \\"bad-element\\" error-tag. Notes ----- It is not clear in the RFC what a netconf server should do when it encounters invalid nodes in a subtree filter in case of get/get-config RPC. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6241 (draft-ietf-netconf-4741bis-10) -------------------------------------- Title : Network Configuration Protocol (NETCONF) Publication Date : June 2011 Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed. Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue Nov 24 08:28:24 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54011A037E for ; Mon, 23 Nov 2015 23:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UTNrqeLrdT2 for ; Mon, 23 Nov 2015 23:56:34 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 988971A037B for ; Mon, 23 Nov 2015 23:56:34 -0800 (PST) Received: from localhost (unknown [173.38.220.62]) by mail.tail-f.com (Postfix) with ESMTPSA id 2A3161AE0987; Tue, 24 Nov 2015 08:56:32 +0100 (CET) Date: Tue, 24 Nov 2015 08:56:32 +0100 (CET) Message-Id: <20151124.085632.599254734752965005.mbj@tail-f.com> To: rfc-editor@rfc-editor.org From: Martin Bjorklund In-Reply-To: <20151124062454.51E58180006@rfc-editor.org> References: <20151124062454.51E58180006@rfc-editor.org> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Tue, 24 Nov 2015 08:28:07 -0800 Cc: rob.enns@gmail.com, keshavkrishna88@gmail.com, joelja@bogus.com, netconf@ietf.org Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (4544) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 07:56:36 -0000 Hi, This errata should be rejected. If an element in the filter does not match the data, the element is simply not included in the output. I think this is pretty clear from the description. Specifically, this text from section 6.3: If the entire subtree data- fragment filter (starting from the root to the innermost element specified in the filter) exactly matches a corresponding portion of the supported data model, then that node and all its children are included in the result data. /martin RFC Errata System wrote: > The following errata report has been submitted for RFC6241, > "Network Configuration Protocol (NETCONF)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=4544 > > -------------------------------------- > Type: Technical > Reported by: Keshava Bhat > > Section: 6.1 > > Original Text > ------------- > XML subtree filtering is a mechanism that allows an application to > select particular XML subtrees to include in the for a > or operation. A small set of filters for > inclusion, simple content exact-match, and selection is provided, > which allows some useful, but also very limited, selection > mechanisms. The server does not need to utilize any data-model- > specific semantics during processing, allowing for simple and > centralized implementation strategies. > > Conceptually, a subtree filter is comprised of zero or more element > subtrees, which represent the filter selection criteria. At each > containment level within a subtree, the set of sibling nodes is > logically processed by the server to determine if its subtree and > path of elements to the root are included in the filter output. > > Each node specified in a subtree filter represents an inclusive > filter. Only associated nodes in underlying data model(s) within the > specified datastore on the server are selected by the filter. A node > is selected if it matches the selection criteria and hierarchy of > elements given in the filter data, except that the filter absolute > path name is adjusted to start from the layer below . > > Response messages contain only the subtrees selected by the filter. > Any selection criteria that were present in the request, within a > particular selected subtree, are also included in the response. Note > that some elements expressed in the filter as leaf nodes will be > expanded (i.e., subtrees included) in the filter output. Specific > data instances are not duplicated in the response in the event that > the request contains multiple filter subtree expressions that select > the same data. > > Corrected Text > -------------- > XML subtree filtering is a mechanism that allows an application to > select particular XML subtrees to include in the for a > or operation. A small set of filters for > inclusion, simple content exact-match, and selection is provided, > which allows some useful, but also very limited, selection > mechanisms. The server does not need to utilize any data-model- > specific semantics during processing, allowing for simple and > centralized implementation strategies. > > Conceptually, a subtree filter is comprised of zero or more element > subtrees, which represent the filter selection criteria. At each > containment level within a subtree, the set of sibling nodes is > logically processed by the server to determine if its subtree and > path of elements to the root are included in the filter output. > > Each node specified in a subtree filter represents an inclusive > filter. Only associated nodes in underlying data model(s) within the > specified datastore on the server are selected by the filter. A node > is selected if it matches the selection criteria and hierarchy of > elements given in the filter data, except that the filter absolute > path name is adjusted to start from the layer below . > > Response messages contain only the subtrees selected by the filter. > Any selection criteria that were present in the request, within a > particular selected subtree, are also included in the response. Note > that some elements expressed in the filter as leaf nodes will be > expanded (i.e., subtrees included) in the filter output. Specific > data instances are not duplicated in the response in the event that > the request contains multiple filter subtree expressions that select > the same data. > > When a node in the subtree filter is unknown, the server sends a > as reply with \\"unknown-element\\" error-tag. In case of > RPC, if the subtree filter contains a node that is > not a configuration node, the server sends as reply > with \\"bad-element\\" error-tag. > > Notes > ----- > It is not clear in the RFC what a netconf server should do when it encounters invalid nodes in a subtree filter in case of get/get-config RPC. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6241 (draft-ietf-netconf-4741bis-10) > -------------------------------------- > Title : Network Configuration Protocol (NETCONF) > Publication Date : June 2011 > Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed. > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > From nobody Tue Nov 24 08:28:26 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D201A1AA6 for ; Tue, 24 Nov 2015 00:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffYYVE2yZdaO for ; Tue, 24 Nov 2015 00:57:59 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 767F91A1A9D for ; Tue, 24 Nov 2015 00:57:59 -0800 (PST) Received: by igl9 with SMTP id 9so68536752igl.0 for ; Tue, 24 Nov 2015 00:57:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HC4imsm96iGxBnIqcrpgF1VbSSrHO/t8ZDWYlpTLHKc=; b=jLBJBc5TBMXK1KNFNaq6O0wzR91461D7wPLTc7RRCD8Vv3fnRJdLtGWizqiG8Xr3MG LZoOPJzIEzGYpz1NI//HOceconYPn+OHl3Q1O522XKVc9eZJ6jFvJlN2i7qEeURmk6NC buvXdYbvRKJdw+VVl/5hxgXx1zowwoQ0UK1OnOT/YxUVDgj5XjJf3nVtOpcwtxa2weHn MPDt6wkgdHnMTb3MPTkhhAkT7unYIrZS3nFjAsRXx3K2HVESfZBtTLhj+SiNlxvtpj4+ gsif+wEkmD6/BKBlM9exYoClsxG57N/eIfOZUSBAAbs80uShJ3Ll9LL+J8dLCoQrUibO bxxA== X-Received: by 10.50.66.69 with SMTP id d5mr14480442igt.30.1448355478820; Tue, 24 Nov 2015 00:57:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.36.209 with HTTP; Tue, 24 Nov 2015 00:57:38 -0800 (PST) In-Reply-To: <20151124.085632.599254734752965005.mbj@tail-f.com> References: <20151124062454.51E58180006@rfc-editor.org> <20151124.085632.599254734752965005.mbj@tail-f.com> From: Keshava Krishna Bhat K Date: Tue, 24 Nov 2015 14:27:38 +0530 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11349ceed2e17b05254589f3 Archived-At: X-Mailman-Approved-At: Tue, 24 Nov 2015 08:28:07 -0800 Cc: rob.enns@gmail.com, joelja@bogus.com, netconf@ietf.org, rfc-editor@rfc-editor.org Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (4544) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 08:58:03 -0000 --001a11349ceed2e17b05254589f3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, The case i present is a filter node which is not even there in server's schema. For example: Shouldn't this be treated an error instead of a silent ignore? Regards, Keshava. On Tue, Nov 24, 2015 at 1:26 PM, Martin Bjorklund wrote: > Hi, > > This errata should be rejected. If an element in the filter does not > match the data, the element is simply not included in the output. I > think this is pretty clear from the description. Specifically, this > text from section 6.3: > > If the entire subtree data- > fragment filter (starting from the root to the innermost element > specified in the filter) exactly matches a corresponding portion of > the supported data model, then that node and all its children are > included in the result data. > > > > /martin > > > > > RFC Errata System wrote: > > The following errata report has been submitted for RFC6241, > > "Network Configuration Protocol (NETCONF)". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=3D6241&eid=3D4544 > > > > -------------------------------------- > > Type: Technical > > Reported by: Keshava Bhat > > > > Section: 6.1 > > > > Original Text > > ------------- > > XML subtree filtering is a mechanism that allows an application to > > select particular XML subtrees to include in the for a > > or operation. A small set of filters for > > inclusion, simple content exact-match, and selection is provided, > > which allows some useful, but also very limited, selection > > mechanisms. The server does not need to utilize any data-model- > > specific semantics during processing, allowing for simple and > > centralized implementation strategies. > > > > Conceptually, a subtree filter is comprised of zero or more element > > subtrees, which represent the filter selection criteria. At each > > containment level within a subtree, the set of sibling nodes is > > logically processed by the server to determine if its subtree and > > path of elements to the root are included in the filter output. > > > > Each node specified in a subtree filter represents an inclusive > > filter. Only associated nodes in underlying data model(s) within th= e > > specified datastore on the server are selected by the filter. A nod= e > > is selected if it matches the selection criteria and hierarchy of > > elements given in the filter data, except that the filter absolute > > path name is adjusted to start from the layer below . > > > > Response messages contain only the subtrees selected by the filter. > > Any selection criteria that were present in the request, within a > > particular selected subtree, are also included in the response. Not= e > > that some elements expressed in the filter as leaf nodes will be > > expanded (i.e., subtrees included) in the filter output. Specific > > data instances are not duplicated in the response in the event that > > the request contains multiple filter subtree expressions that select > > the same data. > > > > Corrected Text > > -------------- > > XML subtree filtering is a mechanism that allows an application to > > select particular XML subtrees to include in the for a > > or operation. A small set of filters for > > inclusion, simple content exact-match, and selection is provided, > > which allows some useful, but also very limited, selection > > mechanisms. The server does not need to utilize any data-model- > > specific semantics during processing, allowing for simple and > > centralized implementation strategies. > > > > Conceptually, a subtree filter is comprised of zero or more element > > subtrees, which represent the filter selection criteria. At each > > containment level within a subtree, the set of sibling nodes is > > logically processed by the server to determine if its subtree and > > path of elements to the root are included in the filter output. > > > > Each node specified in a subtree filter represents an inclusive > > filter. Only associated nodes in underlying data model(s) within th= e > > specified datastore on the server are selected by the filter. A nod= e > > is selected if it matches the selection criteria and hierarchy of > > elements given in the filter data, except that the filter absolute > > path name is adjusted to start from the layer below . > > > > Response messages contain only the subtrees selected by the filter. > > Any selection criteria that were present in the request, within a > > particular selected subtree, are also included in the response. Not= e > > that some elements expressed in the filter as leaf nodes will be > > expanded (i.e., subtrees included) in the filter output. Specific > > data instances are not duplicated in the response in the event that > > the request contains multiple filter subtree expressions that select > > the same data. > > > > When a node in the subtree filter is unknown, the server sends a > > as reply with \\"unknown-element\\" error-tag. In case o= f > > RPC, if the subtree filter contains a node that is > > not a configuration node, the server sends as reply > > with \\"bad-element\\" error-tag. > > > > Notes > > ----- > > It is not clear in the RFC what a netconf server should do when it > encounters invalid nodes in a subtree filter in case of get/get-config RP= C. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC6241 (draft-ietf-netconf-4741bis-10) > > -------------------------------------- > > Title : Network Configuration Protocol (NETCONF) > > Publication Date : June 2011 > > Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder= , > Ed., A. Bierman, Ed. > > Category : PROPOSED STANDARD > > Source : Network Configuration > > Area : Operations and Management > > Stream : IETF > > Verifying Party : IESG > > > --001a11349ceed2e17b05254589f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The case i present is a filter node which is not even there in server&#= 39;s schema.

For example:
<filter>
=C2=A0 <root xmlns=3D"valid:namespace">
=C2=A0 =C2=A0 <invalid-node xmlns=3D"invalid:name= space"/>=C2=A0 <!=E2= =80=94 invalid item -->
=C2=A0 =C2=A0 <valid-level= 1-node/> <!=E2=80=94 v= alid item -->
=C2=A0 </root>
</filter>

Shouldn't this be treated an error instead of a silent ignore?

Regards,
Keshava.

On Tue, Nov 24, 2015 at 1:26 PM, Martin Bjor= klund <mbj@tail-f.com> wrote:
Hi,

This errata should be rejected.=C2=A0 If an element in the filter does not<= br> match the data, the element is simply not included in the output.=C2=A0 I think this is pretty clear from the description.=C2=A0 Specifically, this text from section 6.3:

=C2=A0 =C2=A0If the entire subtree data-
=C2=A0 =C2=A0fragment filter (starting from the root to the innermost eleme= nt
=C2=A0 =C2=A0specified in the filter) exactly matches a corresponding porti= on of
=C2=A0 =C2=A0the supported data model, then that node and all its children = are
=C2=A0 =C2=A0included in the result data.



/martin




RFC Errata System <rfc-edit= or@rfc-editor.org> wrote:
> The following errata report has been submitted for RFC6241,
> "Network Configuration Protocol (NETCONF)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/= errata_search.php?rfc=3D6241&eid=3D4544
>
> --------------------------------------
> Type: Technical
> Reported by: Keshava Bhat <keshavkrishna88@gmail.com>
>
> Section: 6.1
>
> Original Text
> -------------
>=C2=A0 =C2=A0 XML subtree filtering is a mechanism that allows an appli= cation to
>=C2=A0 =C2=A0 select particular XML subtrees to include in the <rpc-= reply> for a
>=C2=A0 =C2=A0 <get> or <get-config> operation.=C2=A0 A smal= l set of filters for
>=C2=A0 =C2=A0 inclusion, simple content exact-match, and selection is p= rovided,
>=C2=A0 =C2=A0 which allows some useful, but also very limited, selectio= n
>=C2=A0 =C2=A0 mechanisms.=C2=A0 The server does not need to utilize any= data-model-
>=C2=A0 =C2=A0 specific semantics during processing, allowing for simple= and
>=C2=A0 =C2=A0 centralized implementation strategies.
>
>=C2=A0 =C2=A0 Conceptually, a subtree filter is comprised of zero or mo= re element
>=C2=A0 =C2=A0 subtrees, which represent the filter selection criteria.= =C2=A0 At each
>=C2=A0 =C2=A0 containment level within a subtree, the set of sibling no= des is
>=C2=A0 =C2=A0 logically processed by the server to determine if its sub= tree and
>=C2=A0 =C2=A0 path of elements to the root are included in the filter o= utput.
>
>=C2=A0 =C2=A0 Each node specified in a subtree filter represents an inc= lusive
>=C2=A0 =C2=A0 filter.=C2=A0 Only associated nodes in underlying data mo= del(s) within the
>=C2=A0 =C2=A0 specified datastore on the server are selected by the fil= ter.=C2=A0 A node
>=C2=A0 =C2=A0 is selected if it matches the selection criteria and hier= archy of
>=C2=A0 =C2=A0 elements given in the filter data, except that the filter= absolute
>=C2=A0 =C2=A0 path name is adjusted to start from the layer below <f= ilter>.
>
>=C2=A0 =C2=A0 Response messages contain only the subtrees selected by t= he filter.
>=C2=A0 =C2=A0 Any selection criteria that were present in the request, = within a
>=C2=A0 =C2=A0 particular selected subtree, are also included in the res= ponse.=C2=A0 Note
>=C2=A0 =C2=A0 that some elements expressed in the filter as leaf nodes = will be
>=C2=A0 =C2=A0 expanded (i.e., subtrees included) in the filter output.= =C2=A0 Specific
>=C2=A0 =C2=A0 data instances are not duplicated in the response in the = event that
>=C2=A0 =C2=A0 the request contains multiple filter subtree expressions = that select
>=C2=A0 =C2=A0 the same data.
>
> Corrected Text
> --------------
>=C2=A0 =C2=A0 XML subtree filtering is a mechanism that allows an appli= cation to
>=C2=A0 =C2=A0 select particular XML subtrees to include in the <rpc-= reply> for a
>=C2=A0 =C2=A0 <get> or <get-config> operation.=C2=A0 A smal= l set of filters for
>=C2=A0 =C2=A0 inclusion, simple content exact-match, and selection is p= rovided,
>=C2=A0 =C2=A0 which allows some useful, but also very limited, selectio= n
>=C2=A0 =C2=A0 mechanisms.=C2=A0 The server does not need to utilize any= data-model-
>=C2=A0 =C2=A0 specific semantics during processing, allowing for simple= and
>=C2=A0 =C2=A0 centralized implementation strategies.
>
>=C2=A0 =C2=A0 Conceptually, a subtree filter is comprised of zero or mo= re element
>=C2=A0 =C2=A0 subtrees, which represent the filter selection criteria.= =C2=A0 At each
>=C2=A0 =C2=A0 containment level within a subtree, the set of sibling no= des is
>=C2=A0 =C2=A0 logically processed by the server to determine if its sub= tree and
>=C2=A0 =C2=A0 path of elements to the root are included in the filter o= utput.
>
>=C2=A0 =C2=A0 Each node specified in a subtree filter represents an inc= lusive
>=C2=A0 =C2=A0 filter.=C2=A0 Only associated nodes in underlying data mo= del(s) within the
>=C2=A0 =C2=A0 specified datastore on the server are selected by the fil= ter.=C2=A0 A node
>=C2=A0 =C2=A0 is selected if it matches the selection criteria and hier= archy of
>=C2=A0 =C2=A0 elements given in the filter data, except that the filter= absolute
>=C2=A0 =C2=A0 path name is adjusted to start from the layer below <f= ilter>.
>
>=C2=A0 =C2=A0 Response messages contain only the subtrees selected by t= he filter.
>=C2=A0 =C2=A0 Any selection criteria that were present in the request, = within a
>=C2=A0 =C2=A0 particular selected subtree, are also included in the res= ponse.=C2=A0 Note
>=C2=A0 =C2=A0 that some elements expressed in the filter as leaf nodes = will be
>=C2=A0 =C2=A0 expanded (i.e., subtrees included) in the filter output.= =C2=A0 Specific
>=C2=A0 =C2=A0 data instances are not duplicated in the response in the = event that
>=C2=A0 =C2=A0 the request contains multiple filter subtree expressions = that select
>=C2=A0 =C2=A0 the same data.
>
>=C2=A0 =C2=A0 When a node in the subtree filter is unknown, the server = sends a
>=C2=A0 =C2=A0 <rpc-error> as reply with \\"unknown-element\\= " error-tag. In case of
>=C2=A0 =C2=A0 <get-config> RPC, if the subtree filter contains a = node that is
>=C2=A0 =C2=A0 not a configuration node, the server sends <rpc-error&= gt; as reply
>=C2=A0 =C2=A0 with \\"bad-element\\" error-tag.
>
> Notes
> -----
> It is not clear in the RFC what a netconf server should do when it enc= ounters invalid nodes in a subtree filter in case of get/get-config RPC. >
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary= , please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC6241 (draft-ietf-netconf-4741bis-10)
> --------------------------------------
> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Network = Configuration Protocol (NETCONF)
> Publication Date=C2=A0 =C2=A0 : June 2011
> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: R. Enns, Ed., M. B= jorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed.
> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD<= br> > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Network Confi= guration
> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Operatio= ns and Management
> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
>

--001a11349ceed2e17b05254589f3-- From nobody Tue Nov 24 08:28:27 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3A61A700D for ; Tue, 24 Nov 2015 01:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Am0BTP28fnCN for ; Tue, 24 Nov 2015 01:10:02 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E78AA1A874D for ; Tue, 24 Nov 2015 01:10:01 -0800 (PST) Received: from localhost (unknown [173.38.220.62]) by mail.tail-f.com (Postfix) with ESMTPSA id CF82B1AE0987; Tue, 24 Nov 2015 10:09:58 +0100 (CET) Date: Tue, 24 Nov 2015 10:09:58 +0100 (CET) Message-Id: <20151124.100958.1746336407269962987.mbj@tail-f.com> To: keshavkrishna88@gmail.com From: Martin Bjorklund In-Reply-To: References: <20151124062454.51E58180006@rfc-editor.org> <20151124.085632.599254734752965005.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: X-Mailman-Approved-At: Tue, 24 Nov 2015 08:28:13 -0800 Cc: rob.enns@gmail.com, joelja@bogus.com, netconf@ietf.org, rfc-editor@rfc-editor.org Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (4544) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 09:10:09 -0000 S2VzaGF2YSBLcmlzaG5hIEJoYXQgSyA8a2VzaGF2a3Jpc2huYTg4QGdtYWlsLmNvbT4gd3JvdGU6 DQo+IEhpLA0KPiANCj4gVGhlIGNhc2UgaSBwcmVzZW50IGlzIGEgZmlsdGVyIG5vZGUgd2hpY2gg aXMgbm90IGV2ZW4gdGhlcmUgaW4gc2VydmVyJ3MNCj4gc2NoZW1hLg0KPiANCj4gRm9yIGV4YW1w bGU6DQo+IDxmaWx0ZXI+DQo+ICAgPHJvb3QgeG1sbnM9InZhbGlkOm5hbWVzcGFjZSI+DQo+ICAg ICA8aW52YWxpZC1ub2RlIHhtbG5zPSJpbnZhbGlkOm5hbWVzcGFjZSIvPiAgPCHigJQgaW52YWxp ZCBpdGVtIC0tPg0KPiAgICAgPHZhbGlkLWxldmVsMS1ub2RlLz4gPCHigJQgdmFsaWQgaXRlbSAt LT4NCj4gICA8L3Jvb3Q+DQo+IDwvZmlsdGVyPg0KPiANCj4gU2hvdWxkbid0IHRoaXMgYmUgdHJl YXRlZCBhbiBlcnJvciBpbnN0ZWFkIG9mIGEgc2lsZW50IGlnbm9yZT8NCg0KSSB0aGluayB0aGUg dGV4dCBpcyBjbGVhciAtIGl0IHNheXMgdGhhdCBpZiB0aGUgZWxlbWVudCAiZXhhY3RseQ0KbWF0 Y2hlcyBhIGNvcnJlc3BvbmRpbmcgcG9ydGlvbiBvZiB0aGUgc3VwcG9ydGVkIGRhdGEgbW9kZWwi IGl0IGlzDQppbmNsdWRlZC4gIElmIGl0IGlzIG5vdCBldmVuIGluIHRoZSBzZXJ2ZXIncyBzY2hl bWEsIGl0IGRvZXNuJ3QgbWF0Y2gNCnRoZSAic3VwcG9ydGVkIGRhdGEgbW9kZWwiLg0KDQpYUGF0 aCBmaWx0ZXJpbmcgd29ya3MgdGhlIHNhbWUgd2F5OyBlbGVtZW50cyB0aGF0IGFyZSBub3QgcGFy dCBvZiB0aGUNCmRhdGEgbW9kZWwgc2ltcGx5IHdvbid0IG1hdGNoLCB3aXRob3V0IHByb2R1Y2lu ZyBhbiBlcnJvci4NCg0KSWYgeW91IHdhbnQgdG8gKmNoYW5nZSogdGhlIGN1cnJlbnQgYmVoYXZp b3IsIHRoZW4gdGhhdCBpcyBhDQpkaXNjdXNzaW9uIHdlIGNhbiBoYXZlLCBidXQgdGhhdCBzaG91 bGQgbm90IGJlIGRvbmUgYXMgYW4gZXJyYXRhLCBidXQNCmFzIGEgbmV3IHByb3RvY29sIHZlcnNp b24uDQoNCg0KL21hcnRpbg0KDQoNCg0KDQo+IA0KPiBSZWdhcmRzLA0KPiBLZXNoYXZhLg0KPiAN Cj4gT24gVHVlLCBOb3YgMjQsIDIwMTUgYXQgMToyNiBQTSwgTWFydGluIEJqb3JrbHVuZCA8bWJq QHRhaWwtZi5jb20+IHdyb3RlOg0KPiANCj4gPiBIaSwNCj4gPg0KPiA+IFRoaXMgZXJyYXRhIHNo b3VsZCBiZSByZWplY3RlZC4gIElmIGFuIGVsZW1lbnQgaW4gdGhlIGZpbHRlciBkb2VzIG5vdA0K PiA+IG1hdGNoIHRoZSBkYXRhLCB0aGUgZWxlbWVudCBpcyBzaW1wbHkgbm90IGluY2x1ZGVkIGlu IHRoZSBvdXRwdXQuICBJDQo+ID4gdGhpbmsgdGhpcyBpcyBwcmV0dHkgY2xlYXIgZnJvbSB0aGUg ZGVzY3JpcHRpb24uICBTcGVjaWZpY2FsbHksIHRoaXMNCj4gPiB0ZXh0IGZyb20gc2VjdGlvbiA2 LjM6DQo+ID4NCj4gPiAgICBJZiB0aGUgZW50aXJlIHN1YnRyZWUgZGF0YS0NCj4gPiAgICBmcmFn bWVudCBmaWx0ZXIgKHN0YXJ0aW5nIGZyb20gdGhlIHJvb3QgdG8gdGhlIGlubmVybW9zdCBlbGVt ZW50DQo+ID4gICAgc3BlY2lmaWVkIGluIHRoZSBmaWx0ZXIpIGV4YWN0bHkgbWF0Y2hlcyBhIGNv cnJlc3BvbmRpbmcgcG9ydGlvbiBvZg0KPiA+ICAgIHRoZSBzdXBwb3J0ZWQgZGF0YSBtb2RlbCwg dGhlbiB0aGF0IG5vZGUgYW5kIGFsbCBpdHMgY2hpbGRyZW4gYXJlDQo+ID4gICAgaW5jbHVkZWQg aW4gdGhlIHJlc3VsdCBkYXRhLg0KPiA+DQo+ID4NCj4gPg0KPiA+IC9tYXJ0aW4NCj4gPg0KPiA+ DQo+ID4NCj4gPg0KPiA+IFJGQyBFcnJhdGEgU3lzdGVtIDxyZmMtZWRpdG9yQHJmYy1lZGl0b3Iu b3JnPiB3cm90ZToNCj4gPiA+IFRoZSBmb2xsb3dpbmcgZXJyYXRhIHJlcG9ydCBoYXMgYmVlbiBz dWJtaXR0ZWQgZm9yIFJGQzYyNDEsDQo+ID4gPiAiTmV0d29yayBDb25maWd1cmF0aW9uIFByb3Rv Y29sIChORVRDT05GKSIuDQo+ID4gPg0KPiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gPiA+IFlvdSBtYXkgcmV2aWV3IHRoZSByZXBvcnQgYmVsb3cgYW5kIGF0 Og0KPiA+ID4gaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBocD9yZmM9 NjI0MSZlaWQ9NDU0NA0KPiA+ID4NCj4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+ID4gPiBUeXBlOiBUZWNobmljYWwNCj4gPiA+IFJlcG9ydGVkIGJ5OiBLZXNo YXZhIEJoYXQgPGtlc2hhdmtyaXNobmE4OEBnbWFpbC5jb20+DQo+ID4gPg0KPiA+ID4gU2VjdGlv bjogNi4xDQo+ID4gPg0KPiA+ID4gT3JpZ2luYWwgVGV4dA0KPiA+ID4gLS0tLS0tLS0tLS0tLQ0K PiA+ID4gICAgWE1MIHN1YnRyZWUgZmlsdGVyaW5nIGlzIGEgbWVjaGFuaXNtIHRoYXQgYWxsb3dz IGFuIGFwcGxpY2F0aW9uIHRvDQo+ID4gPiAgICBzZWxlY3QgcGFydGljdWxhciBYTUwgc3VidHJl ZXMgdG8gaW5jbHVkZSBpbiB0aGUgPHJwYy1yZXBseT4gZm9yIGENCj4gPiA+ICAgIDxnZXQ+IG9y IDxnZXQtY29uZmlnPiBvcGVyYXRpb24uICBBIHNtYWxsIHNldCBvZiBmaWx0ZXJzIGZvcg0KPiA+ ID4gICAgaW5jbHVzaW9uLCBzaW1wbGUgY29udGVudCBleGFjdC1tYXRjaCwgYW5kIHNlbGVjdGlv biBpcyBwcm92aWRlZCwNCj4gPiA+ICAgIHdoaWNoIGFsbG93cyBzb21lIHVzZWZ1bCwgYnV0IGFs c28gdmVyeSBsaW1pdGVkLCBzZWxlY3Rpb24NCj4gPiA+ICAgIG1lY2hhbmlzbXMuICBUaGUgc2Vy dmVyIGRvZXMgbm90IG5lZWQgdG8gdXRpbGl6ZSBhbnkgZGF0YS1tb2RlbC0NCj4gPiA+ICAgIHNw ZWNpZmljIHNlbWFudGljcyBkdXJpbmcgcHJvY2Vzc2luZywgYWxsb3dpbmcgZm9yIHNpbXBsZSBh bmQNCj4gPiA+ICAgIGNlbnRyYWxpemVkIGltcGxlbWVudGF0aW9uIHN0cmF0ZWdpZXMuDQo+ID4g Pg0KPiA+ID4gICAgQ29uY2VwdHVhbGx5LCBhIHN1YnRyZWUgZmlsdGVyIGlzIGNvbXByaXNlZCBv ZiB6ZXJvIG9yIG1vcmUgZWxlbWVudA0KPiA+ID4gICAgc3VidHJlZXMsIHdoaWNoIHJlcHJlc2Vu dCB0aGUgZmlsdGVyIHNlbGVjdGlvbiBjcml0ZXJpYS4gIEF0IGVhY2gNCj4gPiA+ICAgIGNvbnRh aW5tZW50IGxldmVsIHdpdGhpbiBhIHN1YnRyZWUsIHRoZSBzZXQgb2Ygc2libGluZyBub2RlcyBp cw0KPiA+ID4gICAgbG9naWNhbGx5IHByb2Nlc3NlZCBieSB0aGUgc2VydmVyIHRvIGRldGVybWlu ZSBpZiBpdHMgc3VidHJlZSBhbmQNCj4gPiA+ICAgIHBhdGggb2YgZWxlbWVudHMgdG8gdGhlIHJv b3QgYXJlIGluY2x1ZGVkIGluIHRoZSBmaWx0ZXIgb3V0cHV0Lg0KPiA+ID4NCj4gPiA+ICAgIEVh Y2ggbm9kZSBzcGVjaWZpZWQgaW4gYSBzdWJ0cmVlIGZpbHRlciByZXByZXNlbnRzIGFuIGluY2x1 c2l2ZQ0KPiA+ID4gICAgZmlsdGVyLiAgT25seSBhc3NvY2lhdGVkIG5vZGVzIGluIHVuZGVybHlp bmcgZGF0YSBtb2RlbChzKSB3aXRoaW4gdGhlDQo+ID4gPiAgICBzcGVjaWZpZWQgZGF0YXN0b3Jl IG9uIHRoZSBzZXJ2ZXIgYXJlIHNlbGVjdGVkIGJ5IHRoZSBmaWx0ZXIuICBBIG5vZGUNCj4gPiA+ ICAgIGlzIHNlbGVjdGVkIGlmIGl0IG1hdGNoZXMgdGhlIHNlbGVjdGlvbiBjcml0ZXJpYSBhbmQg aGllcmFyY2h5IG9mDQo+ID4gPiAgICBlbGVtZW50cyBnaXZlbiBpbiB0aGUgZmlsdGVyIGRhdGEs IGV4Y2VwdCB0aGF0IHRoZSBmaWx0ZXIgYWJzb2x1dGUNCj4gPiA+ICAgIHBhdGggbmFtZSBpcyBh ZGp1c3RlZCB0byBzdGFydCBmcm9tIHRoZSBsYXllciBiZWxvdyA8ZmlsdGVyPi4NCj4gPiA+DQo+ ID4gPiAgICBSZXNwb25zZSBtZXNzYWdlcyBjb250YWluIG9ubHkgdGhlIHN1YnRyZWVzIHNlbGVj dGVkIGJ5IHRoZSBmaWx0ZXIuDQo+ID4gPiAgICBBbnkgc2VsZWN0aW9uIGNyaXRlcmlhIHRoYXQg d2VyZSBwcmVzZW50IGluIHRoZSByZXF1ZXN0LCB3aXRoaW4gYQ0KPiA+ID4gICAgcGFydGljdWxh ciBzZWxlY3RlZCBzdWJ0cmVlLCBhcmUgYWxzbyBpbmNsdWRlZCBpbiB0aGUgcmVzcG9uc2UuICBO b3RlDQo+ID4gPiAgICB0aGF0IHNvbWUgZWxlbWVudHMgZXhwcmVzc2VkIGluIHRoZSBmaWx0ZXIg YXMgbGVhZiBub2RlcyB3aWxsIGJlDQo+ID4gPiAgICBleHBhbmRlZCAoaS5lLiwgc3VidHJlZXMg aW5jbHVkZWQpIGluIHRoZSBmaWx0ZXIgb3V0cHV0LiAgU3BlY2lmaWMNCj4gPiA+ICAgIGRhdGEg aW5zdGFuY2VzIGFyZSBub3QgZHVwbGljYXRlZCBpbiB0aGUgcmVzcG9uc2UgaW4gdGhlIGV2ZW50 IHRoYXQNCj4gPiA+ICAgIHRoZSByZXF1ZXN0IGNvbnRhaW5zIG11bHRpcGxlIGZpbHRlciBzdWJ0 cmVlIGV4cHJlc3Npb25zIHRoYXQgc2VsZWN0DQo+ID4gPiAgICB0aGUgc2FtZSBkYXRhLg0KPiA+ ID4NCj4gPiA+IENvcnJlY3RlZCBUZXh0DQo+ID4gPiAtLS0tLS0tLS0tLS0tLQ0KPiA+ID4gICAg WE1MIHN1YnRyZWUgZmlsdGVyaW5nIGlzIGEgbWVjaGFuaXNtIHRoYXQgYWxsb3dzIGFuIGFwcGxp Y2F0aW9uIHRvDQo+ID4gPiAgICBzZWxlY3QgcGFydGljdWxhciBYTUwgc3VidHJlZXMgdG8gaW5j bHVkZSBpbiB0aGUgPHJwYy1yZXBseT4gZm9yIGENCj4gPiA+ICAgIDxnZXQ+IG9yIDxnZXQtY29u ZmlnPiBvcGVyYXRpb24uICBBIHNtYWxsIHNldCBvZiBmaWx0ZXJzIGZvcg0KPiA+ID4gICAgaW5j bHVzaW9uLCBzaW1wbGUgY29udGVudCBleGFjdC1tYXRjaCwgYW5kIHNlbGVjdGlvbiBpcyBwcm92 aWRlZCwNCj4gPiA+ICAgIHdoaWNoIGFsbG93cyBzb21lIHVzZWZ1bCwgYnV0IGFsc28gdmVyeSBs aW1pdGVkLCBzZWxlY3Rpb24NCj4gPiA+ICAgIG1lY2hhbmlzbXMuICBUaGUgc2VydmVyIGRvZXMg bm90IG5lZWQgdG8gdXRpbGl6ZSBhbnkgZGF0YS1tb2RlbC0NCj4gPiA+ICAgIHNwZWNpZmljIHNl bWFudGljcyBkdXJpbmcgcHJvY2Vzc2luZywgYWxsb3dpbmcgZm9yIHNpbXBsZSBhbmQNCj4gPiA+ ICAgIGNlbnRyYWxpemVkIGltcGxlbWVudGF0aW9uIHN0cmF0ZWdpZXMuDQo+ID4gPg0KPiA+ID4g ICAgQ29uY2VwdHVhbGx5LCBhIHN1YnRyZWUgZmlsdGVyIGlzIGNvbXByaXNlZCBvZiB6ZXJvIG9y IG1vcmUgZWxlbWVudA0KPiA+ID4gICAgc3VidHJlZXMsIHdoaWNoIHJlcHJlc2VudCB0aGUgZmls dGVyIHNlbGVjdGlvbiBjcml0ZXJpYS4gIEF0IGVhY2gNCj4gPiA+ICAgIGNvbnRhaW5tZW50IGxl dmVsIHdpdGhpbiBhIHN1YnRyZWUsIHRoZSBzZXQgb2Ygc2libGluZyBub2RlcyBpcw0KPiA+ID4g ICAgbG9naWNhbGx5IHByb2Nlc3NlZCBieSB0aGUgc2VydmVyIHRvIGRldGVybWluZSBpZiBpdHMg c3VidHJlZSBhbmQNCj4gPiA+ICAgIHBhdGggb2YgZWxlbWVudHMgdG8gdGhlIHJvb3QgYXJlIGlu Y2x1ZGVkIGluIHRoZSBmaWx0ZXIgb3V0cHV0Lg0KPiA+ID4NCj4gPiA+ICAgIEVhY2ggbm9kZSBz cGVjaWZpZWQgaW4gYSBzdWJ0cmVlIGZpbHRlciByZXByZXNlbnRzIGFuIGluY2x1c2l2ZQ0KPiA+ ID4gICAgZmlsdGVyLiAgT25seSBhc3NvY2lhdGVkIG5vZGVzIGluIHVuZGVybHlpbmcgZGF0YSBt b2RlbChzKSB3aXRoaW4gdGhlDQo+ID4gPiAgICBzcGVjaWZpZWQgZGF0YXN0b3JlIG9uIHRoZSBz ZXJ2ZXIgYXJlIHNlbGVjdGVkIGJ5IHRoZSBmaWx0ZXIuICBBIG5vZGUNCj4gPiA+ICAgIGlzIHNl bGVjdGVkIGlmIGl0IG1hdGNoZXMgdGhlIHNlbGVjdGlvbiBjcml0ZXJpYSBhbmQgaGllcmFyY2h5 IG9mDQo+ID4gPiAgICBlbGVtZW50cyBnaXZlbiBpbiB0aGUgZmlsdGVyIGRhdGEsIGV4Y2VwdCB0 aGF0IHRoZSBmaWx0ZXIgYWJzb2x1dGUNCj4gPiA+ICAgIHBhdGggbmFtZSBpcyBhZGp1c3RlZCB0 byBzdGFydCBmcm9tIHRoZSBsYXllciBiZWxvdyA8ZmlsdGVyPi4NCj4gPiA+DQo+ID4gPiAgICBS ZXNwb25zZSBtZXNzYWdlcyBjb250YWluIG9ubHkgdGhlIHN1YnRyZWVzIHNlbGVjdGVkIGJ5IHRo ZSBmaWx0ZXIuDQo+ID4gPiAgICBBbnkgc2VsZWN0aW9uIGNyaXRlcmlhIHRoYXQgd2VyZSBwcmVz ZW50IGluIHRoZSByZXF1ZXN0LCB3aXRoaW4gYQ0KPiA+ID4gICAgcGFydGljdWxhciBzZWxlY3Rl ZCBzdWJ0cmVlLCBhcmUgYWxzbyBpbmNsdWRlZCBpbiB0aGUgcmVzcG9uc2UuICBOb3RlDQo+ID4g PiAgICB0aGF0IHNvbWUgZWxlbWVudHMgZXhwcmVzc2VkIGluIHRoZSBmaWx0ZXIgYXMgbGVhZiBu b2RlcyB3aWxsIGJlDQo+ID4gPiAgICBleHBhbmRlZCAoaS5lLiwgc3VidHJlZXMgaW5jbHVkZWQp IGluIHRoZSBmaWx0ZXIgb3V0cHV0LiAgU3BlY2lmaWMNCj4gPiA+ICAgIGRhdGEgaW5zdGFuY2Vz IGFyZSBub3QgZHVwbGljYXRlZCBpbiB0aGUgcmVzcG9uc2UgaW4gdGhlIGV2ZW50IHRoYXQNCj4g PiA+ICAgIHRoZSByZXF1ZXN0IGNvbnRhaW5zIG11bHRpcGxlIGZpbHRlciBzdWJ0cmVlIGV4cHJl c3Npb25zIHRoYXQgc2VsZWN0DQo+ID4gPiAgICB0aGUgc2FtZSBkYXRhLg0KPiA+ID4NCj4gPiA+ ICAgIFdoZW4gYSBub2RlIGluIHRoZSBzdWJ0cmVlIGZpbHRlciBpcyB1bmtub3duLCB0aGUgc2Vy dmVyIHNlbmRzIGENCj4gPiA+ICAgIDxycGMtZXJyb3I+IGFzIHJlcGx5IHdpdGggXFwidW5rbm93 bi1lbGVtZW50XFwiIGVycm9yLXRhZy4gSW4gY2FzZSBvZg0KPiA+ID4gICAgPGdldC1jb25maWc+ IFJQQywgaWYgdGhlIHN1YnRyZWUgZmlsdGVyIGNvbnRhaW5zIGEgbm9kZSB0aGF0IGlzDQo+ID4g PiAgICBub3QgYSBjb25maWd1cmF0aW9uIG5vZGUsIHRoZSBzZXJ2ZXIgc2VuZHMgPHJwYy1lcnJv cj4gYXMgcmVwbHkNCj4gPiA+ICAgIHdpdGggXFwiYmFkLWVsZW1lbnRcXCIgZXJyb3ItdGFnLg0K PiA+ID4NCj4gPiA+IE5vdGVzDQo+ID4gPiAtLS0tLQ0KPiA+ID4gSXQgaXMgbm90IGNsZWFyIGlu IHRoZSBSRkMgd2hhdCBhIG5ldGNvbmYgc2VydmVyIHNob3VsZCBkbyB3aGVuIGl0DQo+ID4gZW5j b3VudGVycyBpbnZhbGlkIG5vZGVzIGluIGEgc3VidHJlZSBmaWx0ZXIgaW4gY2FzZSBvZiBnZXQv Z2V0LWNvbmZpZyBSUEMuDQo+ID4gPg0KPiA+ID4gSW5zdHJ1Y3Rpb25zOg0KPiA+ID4gLS0tLS0t LS0tLS0tLQ0KPiA+ID4gVGhpcyBlcnJhdHVtIGlzIGN1cnJlbnRseSBwb3N0ZWQgYXMgIlJlcG9y dGVkIi4gSWYgbmVjZXNzYXJ5LCBwbGVhc2UNCj4gPiA+IHVzZSAiUmVwbHkgQWxsIiB0byBkaXNj dXNzIHdoZXRoZXIgaXQgc2hvdWxkIGJlIHZlcmlmaWVkIG9yDQo+ID4gPiByZWplY3RlZC4gV2hl biBhIGRlY2lzaW9uIGlzIHJlYWNoZWQsIHRoZSB2ZXJpZnlpbmcgcGFydHkgKElFU0cpDQo+ID4g PiBjYW4gbG9nIGluIHRvIGNoYW5nZSB0aGUgc3RhdHVzIGFuZCBlZGl0IHRoZSByZXBvcnQsIGlm IG5lY2Vzc2FyeS4NCj4gPiA+DQo+ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiA+ID4gUkZDNjI0MSAoZHJhZnQtaWV0Zi1uZXRjb25mLTQ3NDFiaXMtMTApDQo+ ID4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gVGl0bGUg ICAgICAgICAgICAgICA6IE5ldHdvcmsgQ29uZmlndXJhdGlvbiBQcm90b2NvbCAoTkVUQ09ORikN Cj4gPiA+IFB1YmxpY2F0aW9uIERhdGUgICAgOiBKdW5lIDIwMTENCj4gPiA+IEF1dGhvcihzKSAg ICAgICAgICAgOiBSLiBFbm5zLCBFZC4sIE0uIEJqb3JrbHVuZCwgRWQuLCBKLiBTY2hvZW53YWVs ZGVyLA0KPiA+IEVkLiwgQS4gQmllcm1hbiwgRWQuDQo+ID4gPiBDYXRlZ29yeSAgICAgICAgICAg IDogUFJPUE9TRUQgU1RBTkRBUkQNCj4gPiA+IFNvdXJjZSAgICAgICAgICAgICAgOiBOZXR3b3Jr IENvbmZpZ3VyYXRpb24NCj4gPiA+IEFyZWEgICAgICAgICAgICAgICAgOiBPcGVyYXRpb25zIGFu ZCBNYW5hZ2VtZW50DQo+ID4gPiBTdHJlYW0gICAgICAgICAgICAgIDogSUVURg0KPiA+ID4gVmVy aWZ5aW5nIFBhcnR5ICAgICA6IElFU0cNCj4gPiA+DQo+ID4NCg== From nobody Tue Nov 24 08:28:28 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4A81B2ED4 for ; Tue, 24 Nov 2015 01:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Noa_aj2SRP9r for ; Tue, 24 Nov 2015 01:55:04 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 439ED1B2ED5 for ; Tue, 24 Nov 2015 01:55:04 -0800 (PST) Received: by lfs39 with SMTP id 39so13597681lfs.3 for ; Tue, 24 Nov 2015 01:55:02 -0800 (PST) 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:date:message-id:subject:from:to :cc:content-type; bh=JRDt30Rm4T7hKYQXkoj5/ipHnmBJ7ZIc1RopbbmAkE8=; b=RqKeWRD4FdivYHUQHnjMsB7GcsCxg934RL8u6vVWs+cqvB/2EnNmb9O40OcqqOAdfi MDPa508PbHxsToEeRv4ZzTK+G8NVjwQ1KlILyl43d17WrFeQMrgGkiRwRoyAPZ2TLbyA zj4jYbYnjhNG0HQOHTAxL6Meo4pA/BOxwR85H1NaXO65TU5XwZKU239dsbliQzp6isLQ XgiFhfeIA/C1P0w0nzcUozlskNUp0Q8SOHr7dCRZHPDMyRs6/bNI159JgtoTmFaAo8cd PB1a/4hcf3eAUhKrWSsdyrewSMrjh2zM7eOUBhgjPjz2JI749xyLtOvh9npYnlJ0evGJ QQnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JRDt30Rm4T7hKYQXkoj5/ipHnmBJ7ZIc1RopbbmAkE8=; b=aPgRwofZz5mDtOmS8TAVqEotMOPPkJ6G4+IS198t0QToPLqgUdC99SGyixF0TVGXDn LDFn7D9OzzR8MwmjTAt+Ms74rQTgkQX0nfJ2QULO32NsUE+RId1IvRUbAAaA7G1Ui+l5 lMznzW1SZ+/6tCt87gY5u4jfyIsMch1lA3jBxGj1WKZxkaw1dR5FC5XYPmY+uIPAVl8s lTBA5vYuKAlHEhjd0HPUrTGK44PV5AizN06cuc4sLcuFPf7/lSacomgczP713lPUXa6f upxMOMGy7C3kLcvgsTJwcX0shfK9NQEH5QyLWk6eqG8xftkBTOfBjVgPFyyLv5rdube7 BySw== X-Gm-Message-State: ALoCoQmPZb81OusZ+/B3xr55S0bGghZUYfpUJJUpoBJGt6FQrUphzGnWxjY09ewOIgQMCvmEb00s MIME-Version: 1.0 X-Received: by 10.25.20.95 with SMTP id k92mr12898672lfi.13.1448358902293; Tue, 24 Nov 2015 01:55:02 -0800 (PST) Received: by 10.112.144.36 with HTTP; Tue, 24 Nov 2015 01:55:02 -0800 (PST) In-Reply-To: <20151124.100958.1746336407269962987.mbj@tail-f.com> References: <20151124062454.51E58180006@rfc-editor.org> <20151124.085632.599254734752965005.mbj@tail-f.com> <20151124.100958.1746336407269962987.mbj@tail-f.com> Date: Tue, 24 Nov 2015 01:55:02 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11407f22e0ffd9052546555b Archived-At: X-Mailman-Approved-At: Tue, 24 Nov 2015 08:28:15 -0800 Cc: Rob Enns , joel jaeggli , keshavkrishna88@gmail.com, Netconf , RFC Editor Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (4544) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 09:55:08 -0000 --001a11407f22e0ffd9052546555b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, The RFC behavior is correct. This errata should be rejected. It is never an error to provide a filter that does not match any nodes. Andy On Tue, Nov 24, 2015 at 1:09 AM, Martin Bjorklund wrote: > Keshava Krishna Bhat K wrote: > > Hi, > > > > The case i present is a filter node which is not even there in server's > > schema. > > > > For example: > > > > > > > > > > > > > > > > Shouldn't this be treated an error instead of a silent ignore? > > I think the text is clear - it says that if the element "exactly > matches a corresponding portion of the supported data model" it is > included. If it is not even in the server's schema, it doesn't match > the "supported data model". > > XPath filtering works the same way; elements that are not part of the > data model simply won't match, without producing an error. > > If you want to *change* the current behavior, then that is a > discussion we can have, but that should not be done as an errata, but > as a new protocol version. > > > /martin > > > > > > > > Regards, > > Keshava. > > > > On Tue, Nov 24, 2015 at 1:26 PM, Martin Bjorklund > wrote: > > > > > Hi, > > > > > > This errata should be rejected. If an element in the filter does not > > > match the data, the element is simply not included in the output. I > > > think this is pretty clear from the description. Specifically, this > > > text from section 6.3: > > > > > > If the entire subtree data- > > > fragment filter (starting from the root to the innermost element > > > specified in the filter) exactly matches a corresponding portion o= f > > > the supported data model, then that node and all its children are > > > included in the result data. > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > RFC Errata System wrote: > > > > The following errata report has been submitted for RFC6241, > > > > "Network Configuration Protocol (NETCONF)". > > > > > > > > -------------------------------------- > > > > You may review the report below and at: > > > > http://www.rfc-editor.org/errata_search.php?rfc=3D6241&eid=3D4544 > > > > > > > > -------------------------------------- > > > > Type: Technical > > > > Reported by: Keshava Bhat > > > > > > > > Section: 6.1 > > > > > > > > Original Text > > > > ------------- > > > > XML subtree filtering is a mechanism that allows an application = to > > > > select particular XML subtrees to include in the for= a > > > > or operation. A small set of filters for > > > > inclusion, simple content exact-match, and selection is provided= , > > > > which allows some useful, but also very limited, selection > > > > mechanisms. The server does not need to utilize any data-model- > > > > specific semantics during processing, allowing for simple and > > > > centralized implementation strategies. > > > > > > > > Conceptually, a subtree filter is comprised of zero or more > element > > > > subtrees, which represent the filter selection criteria. At eac= h > > > > containment level within a subtree, the set of sibling nodes is > > > > logically processed by the server to determine if its subtree an= d > > > > path of elements to the root are included in the filter output. > > > > > > > > Each node specified in a subtree filter represents an inclusive > > > > filter. Only associated nodes in underlying data model(s) withi= n > the > > > > specified datastore on the server are selected by the filter. A > node > > > > is selected if it matches the selection criteria and hierarchy o= f > > > > elements given in the filter data, except that the filter absolu= te > > > > path name is adjusted to start from the layer below . > > > > > > > > Response messages contain only the subtrees selected by the > filter. > > > > Any selection criteria that were present in the request, within = a > > > > particular selected subtree, are also included in the response. > Note > > > > that some elements expressed in the filter as leaf nodes will be > > > > expanded (i.e., subtrees included) in the filter output. Specif= ic > > > > data instances are not duplicated in the response in the event > that > > > > the request contains multiple filter subtree expressions that > select > > > > the same data. > > > > > > > > Corrected Text > > > > -------------- > > > > XML subtree filtering is a mechanism that allows an application = to > > > > select particular XML subtrees to include in the for= a > > > > or operation. A small set of filters for > > > > inclusion, simple content exact-match, and selection is provided= , > > > > which allows some useful, but also very limited, selection > > > > mechanisms. The server does not need to utilize any data-model- > > > > specific semantics during processing, allowing for simple and > > > > centralized implementation strategies. > > > > > > > > Conceptually, a subtree filter is comprised of zero or more > element > > > > subtrees, which represent the filter selection criteria. At eac= h > > > > containment level within a subtree, the set of sibling nodes is > > > > logically processed by the server to determine if its subtree an= d > > > > path of elements to the root are included in the filter output. > > > > > > > > Each node specified in a subtree filter represents an inclusive > > > > filter. Only associated nodes in underlying data model(s) withi= n > the > > > > specified datastore on the server are selected by the filter. A > node > > > > is selected if it matches the selection criteria and hierarchy o= f > > > > elements given in the filter data, except that the filter absolu= te > > > > path name is adjusted to start from the layer below . > > > > > > > > Response messages contain only the subtrees selected by the > filter. > > > > Any selection criteria that were present in the request, within = a > > > > particular selected subtree, are also included in the response. > Note > > > > that some elements expressed in the filter as leaf nodes will be > > > > expanded (i.e., subtrees included) in the filter output. Specif= ic > > > > data instances are not duplicated in the response in the event > that > > > > the request contains multiple filter subtree expressions that > select > > > > the same data. > > > > > > > > When a node in the subtree filter is unknown, the server sends a > > > > as reply with \\"unknown-element\\" error-tag. In > case of > > > > RPC, if the subtree filter contains a node that is > > > > not a configuration node, the server sends as reply > > > > with \\"bad-element\\" error-tag. > > > > > > > > Notes > > > > ----- > > > > It is not clear in the RFC what a netconf server should do when it > > > encounters invalid nodes in a subtree filter in case of get/get-confi= g > RPC. > > > > > > > > Instructions: > > > > ------------- > > > > This erratum is currently posted as "Reported". If necessary, pleas= e > > > > use "Reply All" to discuss whether it should be verified or > > > > rejected. When a decision is reached, the verifying party (IESG) > > > > can log in to change the status and edit the report, if necessary. > > > > > > > > -------------------------------------- > > > > RFC6241 (draft-ietf-netconf-4741bis-10) > > > > -------------------------------------- > > > > Title : Network Configuration Protocol (NETCONF) > > > > Publication Date : June 2011 > > > > Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. > Schoenwaelder, > > > Ed., A. Bierman, Ed. > > > > Category : PROPOSED STANDARD > > > > Source : Network Configuration > > > > Area : Operations and Management > > > > Stream : IETF > > > > Verifying Party : IESG > > > > > > > > --001a11407f22e0ffd9052546555b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The RFC behavior is correct.
<= div>This errata should be rejected.
It is never an error to provi= de a filter that does not match any nodes.


Andy



On Tue, Nov 24, 2015 at 1:09 AM, Marti= n Bjorklund <mbj@tail-f.com> wrote:
Keshava Krishna Bhat K <keshavkrishna88@gmail.com> wrote:
> Hi,
>
> The case i present is a filter node which is not even there in server&= #39;s
> schema.
>
> For example:
> <filter>
>=C2=A0 =C2=A0<root xmlns=3D"valid:namespace">
>=C2=A0 =C2=A0 =C2=A0<invalid-node xmlns=3D"invalid:namespace&qu= ot;/>=C2=A0 <!=E2=80=94 invalid item -->
>=C2=A0 =C2=A0 =C2=A0<valid-level1-node/> <!=E2=80=94 valid ite= m -->
>=C2=A0 =C2=A0</root>
> </filter>
>
> Shouldn't this be treated an error instead of a silent ignore?

I think the text is clear - it says that if the element "exactly
matches a corresponding portion of the supported data model" it is
included.=C2=A0 If it is not even in the server's schema, it doesn'= t match
the "supported data model".

XPath filtering works the same way; elements that are not part of the
data model simply won't match, without producing an error.

If you want to *change* the current behavior, then that is a
discussion we can have, but that should not be done as an errata, but
as a new protocol version.


/martin




>
> Regards,
> Keshava.
>
> On Tue, Nov 24, 2015 at 1:26 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Hi,
> >
> > This errata should be rejected.=C2=A0 If an element in the filter= does not
> > match the data, the element is simply not included in the output.= =C2=A0 I
> > think this is pretty clear from the description.=C2=A0 Specifical= ly, this
> > text from section 6.3:
> >
> >=C2=A0 =C2=A0 If the entire subtree data-
> >=C2=A0 =C2=A0 fragment filter (starting from the root to the inner= most element
> >=C2=A0 =C2=A0 specified in the filter) exactly matches a correspon= ding portion of
> >=C2=A0 =C2=A0 the supported data model, then that node and all its= children are
> >=C2=A0 =C2=A0 included in the result data.
> >
> >
> >
> > /martin
> >
> >
> >
> >
> > RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> > > The following errata report has been submitted for RFC6241,<= br> > > > "Network Configuration Protocol (NETCONF)".
> > >
> > > --------------------------------------
> > > You may review the report below and at:
> > > http://www.rfc= -editor.org/errata_search.php?rfc=3D6241&eid=3D4544
> > >
> > > --------------------------------------
> > > Type: Technical
> > > Reported by: Keshava Bhat <keshavkrishna88@gmail.com>
> > >
> > > Section: 6.1
> > >
> > > Original Text
> > > -------------
> > >=C2=A0 =C2=A0 XML subtree filtering is a mechanism that allow= s an application to
> > >=C2=A0 =C2=A0 select particular XML subtrees to include in th= e <rpc-reply> for a
> > >=C2=A0 =C2=A0 <get> or <get-config> operation.=C2= =A0 A small set of filters for
> > >=C2=A0 =C2=A0 inclusion, simple content exact-match, and sele= ction is provided,
> > >=C2=A0 =C2=A0 which allows some useful, but also very limited= , selection
> > >=C2=A0 =C2=A0 mechanisms.=C2=A0 The server does not need to u= tilize any data-model-
> > >=C2=A0 =C2=A0 specific semantics during processing, allowing = for simple and
> > >=C2=A0 =C2=A0 centralized implementation strategies.
> > >
> > >=C2=A0 =C2=A0 Conceptually, a subtree filter is comprised of = zero or more element
> > >=C2=A0 =C2=A0 subtrees, which represent the filter selection = criteria.=C2=A0 At each
> > >=C2=A0 =C2=A0 containment level within a subtree, the set of = sibling nodes is
> > >=C2=A0 =C2=A0 logically processed by the server to determine = if its subtree and
> > >=C2=A0 =C2=A0 path of elements to the root are included in th= e filter output.
> > >
> > >=C2=A0 =C2=A0 Each node specified in a subtree filter represe= nts an inclusive
> > >=C2=A0 =C2=A0 filter.=C2=A0 Only associated nodes in underlyi= ng data model(s) within the
> > >=C2=A0 =C2=A0 specified datastore on the server are selected = by the filter.=C2=A0 A node
> > >=C2=A0 =C2=A0 is selected if it matches the selection criteri= a and hierarchy of
> > >=C2=A0 =C2=A0 elements given in the filter data, except that = the filter absolute
> > >=C2=A0 =C2=A0 path name is adjusted to start from the layer b= elow <filter>.
> > >
> > >=C2=A0 =C2=A0 Response messages contain only the subtrees sel= ected by the filter.
> > >=C2=A0 =C2=A0 Any selection criteria that were present in the= request, within a
> > >=C2=A0 =C2=A0 particular selected subtree, are also included = in the response.=C2=A0 Note
> > >=C2=A0 =C2=A0 that some elements expressed in the filter as l= eaf nodes will be
> > >=C2=A0 =C2=A0 expanded (i.e., subtrees included) in the filte= r output.=C2=A0 Specific
> > >=C2=A0 =C2=A0 data instances are not duplicated in the respon= se in the event that
> > >=C2=A0 =C2=A0 the request contains multiple filter subtree ex= pressions that select
> > >=C2=A0 =C2=A0 the same data.
> > >
> > > Corrected Text
> > > --------------
> > >=C2=A0 =C2=A0 XML subtree filtering is a mechanism that allow= s an application to
> > >=C2=A0 =C2=A0 select particular XML subtrees to include in th= e <rpc-reply> for a
> > >=C2=A0 =C2=A0 <get> or <get-config> operation.=C2= =A0 A small set of filters for
> > >=C2=A0 =C2=A0 inclusion, simple content exact-match, and sele= ction is provided,
> > >=C2=A0 =C2=A0 which allows some useful, but also very limited= , selection
> > >=C2=A0 =C2=A0 mechanisms.=C2=A0 The server does not need to u= tilize any data-model-
> > >=C2=A0 =C2=A0 specific semantics during processing, allowing = for simple and
> > >=C2=A0 =C2=A0 centralized implementation strategies.
> > >
> > >=C2=A0 =C2=A0 Conceptually, a subtree filter is comprised of = zero or more element
> > >=C2=A0 =C2=A0 subtrees, which represent the filter selection = criteria.=C2=A0 At each
> > >=C2=A0 =C2=A0 containment level within a subtree, the set of = sibling nodes is
> > >=C2=A0 =C2=A0 logically processed by the server to determine = if its subtree and
> > >=C2=A0 =C2=A0 path of elements to the root are included in th= e filter output.
> > >
> > >=C2=A0 =C2=A0 Each node specified in a subtree filter represe= nts an inclusive
> > >=C2=A0 =C2=A0 filter.=C2=A0 Only associated nodes in underlyi= ng data model(s) within the
> > >=C2=A0 =C2=A0 specified datastore on the server are selected = by the filter.=C2=A0 A node
> > >=C2=A0 =C2=A0 is selected if it matches the selection criteri= a and hierarchy of
> > >=C2=A0 =C2=A0 elements given in the filter data, except that = the filter absolute
> > >=C2=A0 =C2=A0 path name is adjusted to start from the layer b= elow <filter>.
> > >
> > >=C2=A0 =C2=A0 Response messages contain only the subtrees sel= ected by the filter.
> > >=C2=A0 =C2=A0 Any selection criteria that were present in the= request, within a
> > >=C2=A0 =C2=A0 particular selected subtree, are also included = in the response.=C2=A0 Note
> > >=C2=A0 =C2=A0 that some elements expressed in the filter as l= eaf nodes will be
> > >=C2=A0 =C2=A0 expanded (i.e., subtrees included) in the filte= r output.=C2=A0 Specific
> > >=C2=A0 =C2=A0 data instances are not duplicated in the respon= se in the event that
> > >=C2=A0 =C2=A0 the request contains multiple filter subtree ex= pressions that select
> > >=C2=A0 =C2=A0 the same data.
> > >
> > >=C2=A0 =C2=A0 When a node in the subtree filter is unknown, t= he server sends a
> > >=C2=A0 =C2=A0 <rpc-error> as reply with \\"unknown= -element\\" error-tag. In case of
> > >=C2=A0 =C2=A0 <get-config> RPC, if the subtree filter c= ontains a node that is
> > >=C2=A0 =C2=A0 not a configuration node, the server sends <= rpc-error> as reply
> > >=C2=A0 =C2=A0 with \\"bad-element\\" error-tag.
> > >
> > > Notes
> > > -----
> > > It is not clear in the RFC what a netconf server should do w= hen it
> > encounters invalid nodes in a subtree filter in case of get/get-c= onfig RPC.
> > >
> > > Instructions:
> > > -------------
> > > This erratum is currently posted as "Reported". If= necessary, please
> > > use "Reply All" to discuss whether it should be ve= rified or
> > > rejected. When a decision is reached, the verifying party (I= ESG)
> > > can log in to change the status and edit the report, if nece= ssary.
> > >
> > > --------------------------------------
> > > RFC6241 (draft-ietf-netconf-4741bis-10)
> > > --------------------------------------
> > > Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : Network Configuration Protocol (NETCONF)
> > > Publication Date=C2=A0 =C2=A0 : June 2011
> > > Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: R. Enns,= Ed., M. Bjorklund, Ed., J. Schoenwaelder,
> > Ed., A. Bierman, Ed.
> > > Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED= STANDARD
> > > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Net= work Configuration
> > > Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = : Operations and Management
> > > Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IET= F
> > > Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
> > >
> >

--001a11407f22e0ffd9052546555b-- From nobody Tue Nov 24 08:32:06 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842F51A8AE1 for ; Tue, 24 Nov 2015 08:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QpmlEOXT2OL for ; Tue, 24 Nov 2015 08:32:04 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 F0FA31A8768 for ; Tue, 24 Nov 2015 08:31:55 -0800 (PST) Received: by lfs39 with SMTP id 39so26463217lfs.3 for ; Tue, 24 Nov 2015 08:31:54 -0800 (PST) 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:date:message-id:subject:from:to :cc:content-type; bh=VtLOrPcZnlpyYfUyrXDuVRVJs/5YgZvezqlhqHylGX4=; b=lPXM0ZWmbZmMP2utOWQIIWLkveKLHV1kMP7+8eb54rSasgU2txKThCYzxu8+Bfd2HR CdB7nMqn8xz3aImdxbXlRdzRs3l7TtYx7YeTd8TG9eolPiKKPMldIuSfULegyaZre//s /eShE6I6rzxDa7kKBD0W4/2+YNzkaJXHnp64/oTuTgSa6h3lZh8BabsaeYs2vthwxQs4 e3q1eVdbOniCVNbYo8rfhxi32dHLmVoR8q1FgmfdLuRgtCOXs6lvegA7081mg8r/0HJo NluvrzWPVJp+o7WJ+NalnOa/81+naEmZk08OyNhUkcFn23Bt+Wv2sdu7WeAg/Xek9blt hnxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VtLOrPcZnlpyYfUyrXDuVRVJs/5YgZvezqlhqHylGX4=; b=A0noQES2fX7kHRKmskP3NgEue1Cqx8KgE4qJrHRK0AeeJH3R1nx81udQ0n+iE/63bE e2vDoKhoAGsYkL7MzrfcOmntHYFvG1fqr1nNEPDlNKhYEMnv2sZVh9g6PYf5l/x0zohU JEjjtVfs8IFBcNGwxKgtFDcOkEW45ewCb0j8oIz+fp6nV2K6H2jTG+vsUpSc1bFSF+Wg iQnnisSgN9rd9zLffNlCk0jeKJZ698fD3FPQRn/rEFCwAilOLCxTEjs0ddqoyKWrmvxJ b5eAMIXOOlP70YR9ZzL43D95O4qRVjE7Gz8a/WOGKYMwtzYTkhAwp11HhwHqZfjHRWh/ oDIw== X-Gm-Message-State: ALoCoQkr9pSX/P5ZHBQfoS+VYuB8YrlnUnfKsia8XZOzXFVep4S/F6uWWm5meHFUjFriNsRFqlWc MIME-Version: 1.0 X-Received: by 10.25.88.67 with SMTP id m64mr13987993lfb.23.1448382713089; Tue, 24 Nov 2015 08:31:53 -0800 (PST) Received: by 10.112.144.36 with HTTP; Tue, 24 Nov 2015 08:31:53 -0800 (PST) In-Reply-To: References: Date: Tue, 24 Nov 2015 08:31:53 -0800 Message-ID: From: Andy Bierman To: Keshava Krishna Bhat K Content-Type: multipart/alternative; boundary=001a1141a07c1cdc9905254be1c3 Archived-At: Cc: Netconf Subject: Re: [Netconf] get/get-config with invalid filter elements X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2015 16:32:05 -0000 --001a1141a07c1cdc9905254be1c3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Nov 23, 2015 at 7:17 AM, Keshava Krishna Bhat K < keshavkrishna88@gmail.com> wrote: > =E2=80=8BHi, > > What should be a NC server=E2=80=99s response when a get is done with val= id and > invalid filters ? > > For example: > > > > > > > > Why does it have to be invalid? It sould just be ietf-interfaces, but the server does not have that module loaded. > Now should the server reply with rpc-reply OR rpc-error (maybe > unknown-namespace) ? > > It just returns . That is all that matched in the filter. > Related question: > What should be the server's response to a get-config rpc which has a stat= e > filter? > > It will not match the filter so it is not returned. I think the RFC is clear that selection nodes that do not match do not result in an . > Regards, > Keshava. > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a1141a07c1cdc9905254be1c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 23, 2015 at 7:17 AM, Keshava Krishna Bhat K <kesha= vkrishna88@gmail.com> wrote:
=E2=80=8BHi,
=C2=A0
What should be a NC server=E2=80=99s response when a get= is done with valid and invalid filters ?

For example:
<filter>
= =C2=A0 <root xmlns= =3D"valid:namespace">
=C2=A0 =C2=A0 <invalid-node xmlns=3D"= invalid:naespace"/> &l= t;!=E2=80=94 invalid item -->
=C2=A0 =C2=A0 <valid-level1-node/> <!=E2=80=94 valid item -->
=C2=A0= </root>
</filter>



Why does it have to be invalid?=C2=A0 It sould just = be ietf-interfaces, but the
server does not have that module load= ed.
=C2=A0
<= div>
=
Now should the se= rver reply with rpc-reply OR rpc-error (maybe unknown-namespace) ?



It just ret= urns <root />.=C2=A0 That is all that matched in the filter.

=C2=A0
Related questi= on:
W= hat should be the server's response to a get-config rpc which has a sta= te filter?



It will not match the filter so it is not returned.

<= /div>
I think the RFC is clear that selection nodes that do not match d= o
not result in an <rpc-error>.

=C2=A0
<= /div>
Regards,
Keshava.


Andy
=C2=A0

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


--001a1141a07c1cdc9905254be1c3-- From nobody Mon Nov 30 12:10:10 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376081B2E0D for ; Mon, 30 Nov 2015 11:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWhxqDy2r1Ww for ; Mon, 30 Nov 2015 11:46:54 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id 87F901B2BDD for ; Mon, 30 Nov 2015 11:46:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 56EF71E5A2C; Mon, 30 Nov 2015 11:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ex5RNshMleDD; Mon, 30 Nov 2015 11:46:22 -0800 (PST) Received: from [10.0.1.16] (static-100-36-193-218.washdc.fios.verizon.net [100.36.193.218]) by c8a.amsl.com (Postfix) with ESMTPA id 39FB11E5A2A; Mon, 30 Nov 2015 11:46:21 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Megan Ferguson In-Reply-To: <20151124062111.94F77180005@rfc-editor.org> Date: Mon, 30 Nov 2015 14:46:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151124062111.94F77180005@rfc-editor.org> To: keshavkrishna88@gmail.com X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Mon, 30 Nov 2015 12:10:09 -0800 Cc: rob.enns@gmail.com, joel jaeggli , netconf@ietf.org, RFC System Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (4543) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 19:46:56 -0000 Greetings, Please note that we have removed this report (EID 4543); EID 4544 = addresses the same text by the same submitter. For future reference: as noted on https://www.rfc-editor.org/errata.php, = to correct an existing erratum, please send a request to = rfc-editor@rfc-editor.org (rather than submitting a new report). Thank you. RFC Editor/mf On Nov 24, 2015, at 1:21 AM, RFC Errata System = wrote: > The following errata report has been submitted for RFC6241, > "Network Configuration Protocol (NETCONF)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6241&eid=3D4543 >=20 > -------------------------------------- > Type: Technical > Reported by: Keshava Bhat >=20 > Section: 6.1 >=20 > Original Text > ------------- > XML subtree filtering is a mechanism that allows an application to > select particular XML subtrees to include in the for a > or operation. A small set of filters for > inclusion, simple content exact-match, and selection is provided, > which allows some useful, but also very limited, selection > mechanisms. The server does not need to utilize any data-model- > specific semantics during processing, allowing for simple and > centralized implementation strategies. >=20 > Conceptually, a subtree filter is comprised of zero or more element > subtrees, which represent the filter selection criteria. At each > containment level within a subtree, the set of sibling nodes is > logically processed by the server to determine if its subtree and > path of elements to the root are included in the filter output. >=20 > Each node specified in a subtree filter represents an inclusive > filter. Only associated nodes in underlying data model(s) within = the > specified datastore on the server are selected by the filter. A = node > is selected if it matches the selection criteria and hierarchy of > elements given in the filter data, except that the filter absolute > path name is adjusted to start from the layer below . >=20 > Response messages contain only the subtrees selected by the filter. > Any selection criteria that were present in the request, within a > particular selected subtree, are also included in the response. = Note > that some elements expressed in the filter as leaf nodes will be > expanded (i.e., subtrees included) in the filter output. Specific > data instances are not duplicated in the response in the event that > the request contains multiple filter subtree expressions that select > the same data. >=20 > Corrected Text > -------------- > XML subtree filtering is a mechanism that allows an application to > select particular XML subtrees to include in the for a > or operation. A small set of filters for > inclusion, simple content exact-match, and selection is provided, > which allows some useful, but also very limited, selection > mechanisms. The server does not need to utilize any data-model- > specific semantics during processing, allowing for simple and > centralized implementation strategies. >=20 > Conceptually, a subtree filter is comprised of zero or more element > subtrees, which represent the filter selection criteria. At each > containment level within a subtree, the set of sibling nodes is > logically processed by the server to determine if its subtree and > path of elements to the root are included in the filter output. >=20 > Each node specified in a subtree filter represents an inclusive > filter. Only associated nodes in underlying data model(s) within = the > specified datastore on the server are selected by the filter. A = node > is selected if it matches the selection criteria and hierarchy of > elements given in the filter data, except that the filter absolute > path name is adjusted to start from the layer below . >=20 > Response messages contain only the subtrees selected by the filter. > Any selection criteria that were present in the request, within a > particular selected subtree, are also included in the response. = Note > that some elements expressed in the filter as leaf nodes will be > expanded (i.e., subtrees included) in the filter output. Specific > data instances are not duplicated in the response in the event that > the request contains multiple filter subtree expressions that select > the same data. >=20 > Notes > ----- > It is not clear in the RFC what a netcofn server should do when it = encounters invalid nodes in a subtree filter in case of get/get-config = RPC >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6241 (draft-ietf-netconf-4741bis-10) > -------------------------------------- > Title : Network Configuration Protocol (NETCONF) > Publication Date : June 2011 > Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. = Schoenwaelder, Ed., A. Bierman, Ed. > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG >=20 From nobody Mon Nov 30 16:32:01 2015 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8D81B3461; Mon, 30 Nov 2015 16:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBWqqmkQKgMP; Mon, 30 Nov 2015 16:31:57 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE7D1B345E; Mon, 30 Nov 2015 16:31:57 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 3D2F3180004; Mon, 30 Nov 2015 16:30:18 -0800 (PST) To: keshavkrishna88@gmail.com, rob.enns@gmail.com, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, andy@yumaworks.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20151201003018.3D2F3180004@rfc-editor.org> Date: Mon, 30 Nov 2015 16:30:18 -0800 (PST) Archived-At: Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, netconf@ietf.org Subject: [Netconf] [Errata Rejected] RFC6241 (4544) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 00:31:59 -0000 The following errata report has been rejected for RFC6241, "Network Configuration Protocol (NETCONF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=4544 -------------------------------------- Status: Rejected Type: Technical Reported by: Keshava Bhat Date Reported: 2015-11-24 Rejected by: Benoit Claise (IESG) Section: 6.1 Original Text ------------- XML subtree filtering is a mechanism that allows an application to select particular XML subtrees to include in the for a or operation. A small set of filters for inclusion, simple content exact-match, and selection is provided, which allows some useful, but also very limited, selection mechanisms. The server does not need to utilize any data-model- specific semantics during processing, allowing for simple and centralized implementation strategies. Conceptually, a subtree filter is comprised of zero or more element subtrees, which represent the filter selection criteria. At each containment level within a subtree, the set of sibling nodes is logically processed by the server to determine if its subtree and path of elements to the root are included in the filter output. Each node specified in a subtree filter represents an inclusive filter. Only associated nodes in underlying data model(s) within the specified datastore on the server are selected by the filter. A node is selected if it matches the selection criteria and hierarchy of elements given in the filter data, except that the filter absolute path name is adjusted to start from the layer below . Response messages contain only the subtrees selected by the filter. Any selection criteria that were present in the request, within a particular selected subtree, are also included in the response. Note that some elements expressed in the filter as leaf nodes will be expanded (i.e., subtrees included) in the filter output. Specific data instances are not duplicated in the response in the event that the request contains multiple filter subtree expressions that select the same data. Corrected Text -------------- XML subtree filtering is a mechanism that allows an application to select particular XML subtrees to include in the for a or operation. A small set of filters for inclusion, simple content exact-match, and selection is provided, which allows some useful, but also very limited, selection mechanisms. The server does not need to utilize any data-model- specific semantics during processing, allowing for simple and centralized implementation strategies. Conceptually, a subtree filter is comprised of zero or more element subtrees, which represent the filter selection criteria. At each containment level within a subtree, the set of sibling nodes is logically processed by the server to determine if its subtree and path of elements to the root are included in the filter output. Each node specified in a subtree filter represents an inclusive filter. Only associated nodes in underlying data model(s) within the specified datastore on the server are selected by the filter. A node is selected if it matches the selection criteria and hierarchy of elements given in the filter data, except that the filter absolute path name is adjusted to start from the layer below . Response messages contain only the subtrees selected by the filter. Any selection criteria that were present in the request, within a particular selected subtree, are also included in the response. Note that some elements expressed in the filter as leaf nodes will be expanded (i.e., subtrees included) in the filter output. Specific data instances are not duplicated in the response in the event that the request contains multiple filter subtree expressions that select the same data. When a node in the subtree filter is unknown, the server sends a as reply with \\\\\\\\\\\\\\\\"unknown-element\\\\\\\\\\\\\\\\" error-tag. In case of RPC, if the subtree filter contains a node that is not a configuration node, the server sends as reply with \\\\\\\\\\\\\\\\"bad-element \\\\\\\\\\\\\\\\" error-tag. Notes ----- It is not clear in the RFC what a netconf server should do when it encounters invalid nodes in a subtree filter in case of get/get-config RPC. --VERIFIER NOTES-- I think the text is clear - it says that if the element \"exactly matches a corresponding portion of the supported data model\" it is included. If it is not even in the server\'s schema, it doesn\'t match the \"supported data model\". XPath filtering works the same way; elements that are not part of the data model simply won\'t match, without producing an error. -------------------------------------- RFC6241 (draft-ietf-netconf-4741bis-10) -------------------------------------- Title : Network Configuration Protocol (NETCONF) Publication Date : June 2011 Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed. Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG