From nobody Tue Mar 1 02:00:49 2016 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 436621B3C7D for ; Tue, 1 Mar 2016 02:00:47 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_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 pVcN6SyDJkOV for ; Tue, 1 Mar 2016 02:00:45 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0773.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::773]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEAAE1B3CAC for ; Tue, 1 Mar 2016 02:00:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mj6n3K7X+5Wbvr7weCXD+ewOOIbERss1H9hm1zqImFc=; b=GfFjRWuWtwmwoFk1I3oR+kIT2f8jKEY8/wUvJW+jbZFBR6wKL6DIjMj7CANEeMg1tVW3DzhyX9PZ60a2ROAyxoo2NyyHwsmtxqbX4RV6XJPu6kQK83UtYaCBlOY5IYZH0nCUCd9O517Urt60pl0T/qKTCUqEPB17GcTz4sfqAig= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.167.153.133) by HE1PR07MB1627.eurprd07.prod.outlook.com (10.166.124.23) with Microsoft SMTP Server (TLS) id 15.1.415.20; Tue, 1 Mar 2016 10:00:20 +0000 Message-ID: <01ec01d173a0$a4b768e0$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , 'Netconf' References: <4A95BA014132FF49AE685FAB4B9F17F657DE8236@dfweml701-chm> Date: Tue, 1 Mar 2016 09:56:24 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.167.153.133] X-ClientProxiedBy: AM3PR02CA0027.eurprd02.prod.outlook.com (10.242.240.27) To HE1PR07MB1627.eurprd07.prod.outlook.com (25.166.124.23) X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1627; 2:7AuCyrj/3S1hapTzYFuoLig+qtxraV66WAqXONRMX/U1z3MwuF66uQdf53xtAjTEin4fHxrlOSJnMzf5qcQ9oQAB+k7s3Alyar4H3hh73VakBfIRDzklT0+kxWkelORPJMPvHftydisJdsvMVccGPw==; 3:Q5nUFPrqiKcEC57W3EXDVV9ukUOyVPTQlHKHzFlDa/jYR/r4O4fDz2BXaLpuLdyTNtIhdZBt/qxIKI2QfdNm7iObeCwGTiDRzn+NYJcxoJdcL3ogkNWCye4PO5IyrCn9; 25:8LYMEnkaJD5+cI+OegtQDGylcz7ppEPFyWDf8rBlZb/8SdV1sEzwWeFDgI1yQS7Y1kN1sPKDuBOVv0Z43uDISRimffJ0qSO4F9LYXibQcKXFuqDzk36Q/NAlvSGlPZo2OwefdgN0sEPHcYRymL60DJDAvHNTKNen0gkmnFqiO7u7h26pw92BtyU9DTwY8z9t06zVNKcGryLo+TG8khfMCFrPPyfQdkIZryi1e9NMwIB7xhRgyXJ1lew66oOQfeOBk6o2ndMfggM6obJDWPczo6u6CbE7A5JOhvZ/CNjoD+sZ6oeeU6FbsrU+bvn1i5e4vJA0oacjI0thiHwvN5rShw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR07MB1627; X-MS-Office365-Filtering-Correlation-Id: 57b34627-1e2e-4847-23cd-08d341b84cef X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:HE1PR07MB1627; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1627; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1627; 4:QHNiDiCEsFVmQzZzjPeb4RHId5lNQzmkj7EEQIFeAvFfI8qgaplTqCoj2WahfqI31cNaqDujHaXBlCS0y9VwT8r1LRLJ2cSI+zmUbqpZl0W0IO7o08dPk/uoQLvTzIKDz+ZgS2ug3vh5L3QU3YWe1rUNsPGr+d0VgWI0n1ktjaj+kngfLJaKxT971qTqvuWG7xCXWsasWFt66An0/6y8eAKfGqB2ATStVEC2suJ55O3Rz89WGFWMtoTrARaKe9Q1RANGZ+D5ZMtn11SO/NUYAaqJzTYRwd9PpxkdF9KEcyWQc7EjFI5ASEx6iDpxfKk6ZD06Bmz42Dl1JepNSOsmGFuNrsNJl69m+BvSZsyB/FE1Tf6kW5mxAycQzeiKBUEI X-Forefront-PRVS: 086831DFB4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(84392002)(81686999)(3846002)(230700001)(586003)(50986999)(76176999)(3480700003)(5820100001)(23676002)(5001770100001)(107886002)(50226001)(2906002)(189998001)(5001960100003)(44736004)(122386002)(15395725005)(1096002)(40100003)(6116002)(50466002)(81816999)(33646002)(61296003)(62236002)(42186005)(5004730100002)(19580395003)(44716002)(92566002)(47776003)(5008740100001)(66066001)(14496001)(229853001)(77096005)(86362001)(116806002)(15975445007)(81156008)(74416001)(7059030)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1627; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIxNjI3OzIzOkpTYlV5dkE2Ti8wNWI3QkRCL2tWQW1RSU4r?= =?utf-8?B?SEZ0TUcvNWIrSWplQm9HUUhXNko5Y3NEaVB5NkhmWlFsb3I5aWRPcENZOVRF?= =?utf-8?B?VFZlcE5FVHZhTTY5Q0syM2pWU1VGcFo0Znc5Rm1nbWpjSXVsM1hRU1M2SWVp?= =?utf-8?B?Zmwrb0d5ZTZFcDdxakdWaFExOFErWm1iTU5YTDdjQ28wL1Rxb2QzVGkvb1lM?= =?utf-8?B?ZDdnVGdWbldqblZwenNjL2l6MWpjVWdYbUZSOFdLTzdrMXI2RldQNm1FUHQ3?= =?utf-8?B?N2k5dUlBUEtRckxIZllEWDVwaThsNXE3KzdxRXIyTmtoa002N2pUWGxrMisy?= =?utf-8?B?eE9NcllpYkVRSzNLcGpxM0tsakpMWFlCVVhZYlliRFdMOHRrV0NOYmR4UXZ2?= =?utf-8?B?NWs3SStZdVZiaWJJaldwcHBLSlNSZ2FwS085NnFPWUp6WWVjWGpsOHV4MXpN?= =?utf-8?B?eUduS2p4ZmhFZ3ArZTB1ak5DbjBETDdwUC95Ky9idWFRUTcxMXhXdzF5WFlu?= =?utf-8?B?SEpQY09VSStpb1BPbC9wYm1yMWQxcnBmSHZxWktCd0FQSmVwZmk3L0Y0ODA3?= =?utf-8?B?c0djRCsybGVReXZVMlc0dENsVU1hZ3lKMWpBWTBQaFpCK2J5ckdKckNtSlpH?= =?utf-8?B?NkZtMUNNZG5BOWpUMXY3R1JhbGt3OXV6Wm9Gc1NUZk1pQVhheDlEaEQ0Y0RR?= =?utf-8?B?V1Z2QjFJNGxQRWVQeEE3d3pKSW13U2tab25LSTNaTjRISHhvdG8yUW1SM0tP?= =?utf-8?B?QkRtKzBWYWp2Y0U5V3lhRVF5dmVSZHY3QWZ4V3FlL1dYbmFtV21VbWZsT3RB?= =?utf-8?B?OVd6b1RSVjkxeklLcEVJV0pQeXkxSUh1Z2c4dUs3aXhzWXE1SG82ZkgrNm9M?= =?utf-8?B?TjVSQ1pmKytmOHA3T2Y3WncyaURoSU5ZUjJURkZJVnRLUzhiMDNzY1V1MUVR?= =?utf-8?B?NU13RkJBbEwzLzhKdk5saE1mTVUvdXkvNGJjQXpiNmVoK1BROGw4UlkwYlJ1?= =?utf-8?B?UFNFc2cxbmhnRVZVSVJ0cVpOM0RtR0EzWEdkbjVGQTJ5ZVpFU2xNUUJOd0ZS?= =?utf-8?B?OXRVQUNtR3hGZ0JKTXIram5ZL1RGOGttWnpYb2VaZVpsbGdrMmN6TlAraUoy?= =?utf-8?B?UDdQZ29LWG1GNnZFc1ViTVJCK0toVm9mMUN4Q3F6NEp4aUR4QUFjakhBd0Zo?= =?utf-8?B?VzlPSjVRci9hbUJrY1Jud2VPN0ZkeTVlM0d6bjMwOEQyOXBXZHlPd3BqM2JE?= =?utf-8?B?S3ptWERUYzdiOUdzYm04cURENTEyUkY1MGJkcUJwVURPdWZ6bmRaaW9pYUZR?= =?utf-8?B?TXFickxpdnllbml5QjVSYmJvNHhHelRoMElhVDFIUDVEdmtpcURmbWRsMWpL?= =?utf-8?B?Uk5CUFRidmdUMnJPWnFzcXIxV2VWSVVuUjFXWWJLbE15WGNMRGV4RnVQWFFZ?= =?utf-8?B?OFRkR0xZS0hpUnp5eXo5MmtEQURCVUJwc3B4VTgvM1pRRzRwU05tRE9tOXN4?= =?utf-8?B?YWx1TzFWejJyd1V0WVFweGJ3SDJjZ1ZzZlRQcUZuR2Q2RURuelY1VWNXb1lI?= =?utf-8?B?UXFlbVE0ZDdvTHI0L0ErbGgxcE5TWWRJbnV5RXp5U0dSU3NLV20yTit5anU4?= =?utf-8?B?RC81VzdNeFBvSS9hV2FRSDRvUldRcU1VTUc0dHZlaDN0WCtZN1kybUdoWmti?= =?utf-8?Q?tOuG90SdzpMyOr1c14=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1627; 5:AiRjNZfxTiQdQhK1MYKvPIeyxi9py2i0Z0XH8aU8oCBaFOHDdoMp3IKXw2hh2ZiviG8wb/5pfEfmIcE7yoFxoJShikBJR6i7Ma08Y65hHLD7uAOD6n+gkdXaA7yoYMtF/MQRF8H6Z7XjtWuPJUIt+A==; 24:ndAlOZqAoKb/sSZno36XbEXMjKVbtagxRGI5QuWPMyxcKcKl2Iqm5jtpdDhDeylLm5jBcOHVy+WQ6mpC6y2knHLIy6TQLF9z3eLl7NruVf4= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Mar 2016 10:00:20.7556 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1627 Archived-At: Subject: [Netconf] netconf-restconf Action 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 Mar 2016 10:00:47 -0000 I would like to know what an action looks like in restconf and JSON. What would be the equivalent of, from rfc6020bis, apache-1 2014-07-29T13:42:00Z 2014-07-29T13:42:12Z Tom Petch From nobody Tue Mar 1 02:02:38 2016 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 650FE1B3C85 for ; Tue, 1 Mar 2016 02:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, 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 qeKQOUZ3lq5H for ; Tue, 1 Mar 2016 02:02:28 -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 794851B3CCE for ; Tue, 1 Mar 2016 02:02:27 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFE17756; Tue, 01 Mar 2016 10:02:24 +0000 (GMT) Received: from SZXEML426-HUB.china.huawei.com (10.82.67.181) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Mar 2016 10:02:23 +0000 Received: from szxeml561-mbs.china.huawei.com ([169.254.6.28]) by szxeml426-hub.china.huawei.com ([10.82.67.181]) with mapi id 14.03.0235.001; Tue, 1 Mar 2016 18:00:38 +0800 From: Rohit pobbathi To: netconf Thread-Topic: Query regarding "list" subelement XML Mapping rule Thread-Index: AdFzoTQl7Z69vIZETp258A4BeSmfag== Date: Tue, 1 Mar 2016 10:00:38 +0000 Message-ID: <2730B0D5F3302249A30EBF0DAE96D4CB44C004AD@SZXEML561-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.210.230] Content-Type: multipart/alternative; boundary="_000_2730B0D5F3302249A30EBF0DAE96D4CB44C004ADSZXEML561MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.56D568B1.0090, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.6.28, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 10e8e5a97d0ec1d317102afdf423807a Archived-At: Subject: [Netconf] Query regarding "list" subelement XML Mapping rule 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 Mar 2016 10:02:36 -0000 --_000_2730B0D5F3302249A30EBF0DAE96D4CB44C004ADSZXEML561MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have a query regarding "list" subelement XML Mapping rules - RFC 6020 Sec= tion 7.8.5. For clarity, I am using the "example-jukebox" YANG model (from RESTCONF dra= ft). +--rw jukebox! +--rw library | +--rw artist* [name] | | +--rw name string | | +--rw album* [name] | | +--rw name string | | +--rw genre? identityref | | +--rw year? uint16 | | +--rw admin | | | +--rw label? string | | | +--rw catalogue-number? string | | +--rw song* [name] | | +--rw name string | | +--rw location string | | +--rw format? string | | +--rw length? uint32 | +--ro artist-count? uint32 | +--ro album-count? uint32 | +--ro song-count? uint32 Request from Client to Server: Foo Fighters Wasting Light =3D=3D=3D=3D=3D=3D> Request select= ion node order The selection nodes in above request are not in the same order as defined i= n the YANG model for "jukebox" module's "album" list. I assume this is allowed as per the RFC 6020 section 7.8.5's below paragrap= h: The rest of the list's child nodes are encoded as subelements to the list element, after the keys. If the list defines RPC input or output parameters, the subelements are encoded in the same order as they are defined within the "list" statement. Otherwise, the subelements are encoded in any order. Please confirm if the above request's selection nodes order is valid = ? Response from Server to Client: Foo Fighters Wasting Light example-jukebox:alternative 2011 Wasting Light MP3 286 Rope MP3 259 For the above request, is it fine for the Server to encode the response wit= h list subelement order as per the defined YANG model ? OR Should the response follow the REQUEST's list subelement order ? Regards, Rohit P --_000_2730B0D5F3302249A30EBF0DAE96D4CB44C004ADSZXEML561MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have a query regarding "list" subelement= XML Mapping rules - RFC 6020 Section 7.8.5.

 

For clarity, I am using the "example-jukebox&qu= ot; YANG model (from RESTCONF draft).

   +--rw jukebox!

      +--rw library

      |  +--rw art= ist* [name]

      |  |  += --rw name     string

      |  |  += --rw album* [name]

      |  |  =    +--rw name     string

      |  |  =    +--rw genre?   identityref

      |  |  =    +--rw year?    uint16

      |  |  =    +--rw admin

      |  |  =    |  +--rw label?      &n= bsp;       string

      |  |  =    |  +--rw catalogue-number?   string

      |  |  =    +--rw song* [name]

      |  |  =       +--rw name     =    string

      |  |  =       +--rw location    string<= o:p>

      |  |  =       +--rw format?     st= ring

      |  |  =       +--rw length?     ui= nt32

      |  +--ro art= ist-count?   uint32

      |  +--ro alb= um-count?    uint32

      |  +--ro son= g-count?     uint32

 

Request from Client to Server:

     <rpc message-id=3D"= 101" xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">

       <get>

         <= ;filter type=3D"subtree">

        &nbs= p;  <jukebox xmlns=3D"http://example.com/ns/example-jukebox">

        &nbs= p;    <library>

        &nbs= p;      <artist>

        &nbs= p;        <name>Foo Fighters</n= ame>

        &nbs= p;        <album>

        &nbs= p;          <name>Wastin= g Light</name>

    &n= bsp;            = ;  <song/>         =       =3D=3D=3D=3D=3D=3D> Request selection nod= e order

    &n= bsp;            = ;  <year/>

    &n= bsp;            = ;  <genre>

        &nbs= p;        </album>

        &nbs= p;      </artist>

        &nbs= p;    </library>

        &nbs= p;  </jukebox>

         <= ;/filter>

       </get>

     </rpc>  &nb= sp;  

 

The selection nodes in above request are not in t= he same order as defined in the YANG model for “jukebox” module= ’s “album” list.

 

I assume this is allowed as per the RFC 6020 sect= ion 7.8.5’s below paragraph:

   The rest of t= he list's child nodes are encoded as subelements to the

   list element,= after the keys.  If the list defines RPC input or

   output parameters, the subelements are = encoded in the same order as

   they are defined within the "list&= quot; statement.  Otherwise, the

   subelements a= re encoded in any order.

 

Please confirm if the above <get> request&#= 8217;s selection nodes order is valid ?

 

Response from Server to Client:

     <rpc-reply message-id=3D= "101" xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"= >

       <data>

         <= ;jukebox xmlns:t=3D"= http://example.com/ns/example-jukebox">

        &nbs= p;  <library>

        &nbs= p;    <artist>

        &nbs= p;      <name>Foo Fighters</name>=

        &nbs= p;      <album>

        &nbs= p;        <name>Wasting Light</= name>

    &n= bsp;            <= genre>example-jukebox:alternative</genre>

    &n= bsp;            <= year>2011</year>

    &n= bsp;            <= song>

    &n= bsp;            = ;  <name>Wasting Light</name>

    &n= bsp;            = ;  <format>MP3</format>

    &n= bsp;            = ;  <length>286</length>      = ;            

    &n= bsp;            = ;</song>

    &n= bsp;            <= song>

    &n= bsp;            = ;  <name>Rope</name>

    &n= bsp;            = ;  <format>MP3</format>

    &n= bsp;            = ;  <length>259</length>      = ;            

    &n= bsp;            = ;</song>          &= nbsp;     

        &nbs= p;      </album>

        &nbs= p;    </artist>

        &nbs= p;  </library>

         <= ;/jukebox>

       </data>

     </rpc-reply> &nb= sp;  

 

For the above request, is it fine for the Server = to encode the response with list subelement order as per the defined YANG m= odel ?

OR

Should the response follow the REQUEST’s li= st subelement order ?

 

Regards,

Rohit P

 

--_000_2730B0D5F3302249A30EBF0DAE96D4CB44C004ADSZXEML561MBSchi_-- From nobody Tue Mar 1 07:34:00 2016 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 876041B2D6D for ; Tue, 1 Mar 2016 07:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.506 X-Spam-Level: X-Spam-Status: No, score=-14.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, 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 nVa07A4Gh99q for ; Tue, 1 Mar 2016 07:33:53 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F005E1B2D63 for ; Tue, 1 Mar 2016 07:33:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7566; q=dns/txt; s=iport; t=1456846433; x=1458056033; h=from:to:cc:subject:date:message-id:mime-version; bh=7J5lRtjagTTfHN9y1M0v5VMWVu2MkhDNKylujOfPNGc=; b=PcYk6lb4Ao+11kbJCZHk4paOcjIzz7uPRmToTuwtY118wppkBbP1mFzh YiPRL44cwbA8GGvMR3UVbZky7cilz2R5CfjA8Z7I0U2V2ZcBgPK2eegXb zRGoaYUs2/a2FehK1aiH4m/2ld/abYyVJEc/tD99GFyPSi5SIU0cDMIYk o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAgAjttVW/4cNJK1egm5MUnO6LgENg?= =?us-ascii?q?WaGE4FLOBQBAQEBAQEBZBwLhEQELUwSAW0TJgEEDg2IF8AJAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEWkzsFlw4BE41Hjn2OSwEeAQFCg2SILX4BAQE?= X-IronPort-AV: E=Sophos;i="5.22,523,1449532800"; d="scan'208,217";a="244406982" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Mar 2016 15:33:52 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u21FXptP026767 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 1 Mar 2016 15:33:51 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 1 Mar 2016 09:33:50 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1104.009; Tue, 1 Mar 2016 09:33:50 -0600 From: "Maros Marsalek -X (mmarsale - PANTHEON TECHNOLOGIES at Cisco)" To: "netconf@ietf.org" Thread-Topic: Netconf, none operation and non-presence containers Thread-Index: AdFzz7m8JjrF2l7bTBCaKawIVSebJA== Date: Tue, 1 Mar 2016 15:33:50 +0000 Message-ID: <31c6e4048a9f40438f17e2902cd5874d@XCH-ALN-018.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.80.61] Content-Type: multipart/alternative; boundary="_000_31c6e4048a9f40438f17e2902cd5874dXCHALN018ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Tony Tkacik -X \(ttkacik - PANTHEON TECHNOLOGIES at Cisco\)" Subject: [Netconf] Netconf, none operation and non-presence containers 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 Mar 2016 15:33:58 -0000 --_000_31c6e4048a9f40438f17e2902cd5874dXCHALN018ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello netconf group, We've run into following situation with NETCONF and we would like to know y= our opinion on what's the correct behavior here: Model (root non-presence container with nested list) : container mapping-nodes { list mapping-node{ key "id"; leaf id { type string; } } } Netconf edit-config RPC (replacing mapping-node entry with none operation f= or mapping-nodes container, in an empty data store): ... none node1-put And the question here is: Whether the edit should fail or not ? The problem is that mapping-nodes container does not exist and in edit-conf= ig rpc, there's "none" operation associated to it. Our first assumption was that the resulting data structure should be invali= d due to missing root container and rpc should fail. However, the container is non-presence (exists only for organizing the hier= archy of data nodes), which means that it may be created/deleted as child n= odes appear/disappear. In which case, the operation doesn't have to fail and can create mapping-no= des container even if "none" operation is associated with it. Regards, Maros --_000_31c6e4048a9f40438f17e2902cd5874dXCHALN018ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello netconf group,

 

We’ve run into following situation with NETCON= F and we would like to know your opinion on what’s the correct behavi= or here:

 

Model (root non-presence container with nested list)= :

 

container mapping-nodes {

    list mapping-node{

        key "= ;id";

        leaf id {=

        &nbs= p;   type string;

        }

    }

}

 

Netconf edit-config RPC (replacing mapping-node entr= y with none operation for mapping-nodes container, in an empty data store):=

 

    <edit-config>

        …

        <defau= lt-operation>none</default-operation>

        <confi= g>

        &nbs= p;   <mapping-nodes xmlns=3D"urn:opendaylight:mdsal:mappi= ng:test">

        &nbs= p;       <mapping-node xmlns:a=3D"urn= :ietf:params:xml:ns:netconf:base:1.0" a:operation=3D"replace"= ;>

        &nbs= p;           <id>no= de1-put</id>

        &nbs= p;       </mapping-node>

        &nbs= p;   </mapping-nodes>

        </conf= ig>

    </edit-config>

 

And the question here is: Whether the edit should fa= il or not ?

The problem is that mapping-nodes container does not= exist and in edit-config rpc, there’s “none” operation a= ssociated to it.

Our first assumption was that the resulting data str= ucture should be invalid due to missing root container and rpc should fail.=

However, the container is non-presence (exists only = for organizing the hierarchy of data nodes), which means that it may be cre= ated/deleted as child nodes appear/disappear.

In which case, the operation doesn’t have to f= ail and can create mapping-nodes container even if “none” opera= tion is associated with it.

 

Regards,

Maros

--_000_31c6e4048a9f40438f17e2902cd5874dXCHALN018ciscocom_-- From nobody Tue Mar 1 08:28:46 2016 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 E66041B2E87 for ; Tue, 1 Mar 2016 08:28:45 -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 rbhHypw0XZmS for ; Tue, 1 Mar 2016 08:28:44 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 D90A51B2E86 for ; Tue, 1 Mar 2016 08:28:42 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id v124so23882957lff.0 for ; Tue, 01 Mar 2016 08:28:42 -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; bh=HIQT5nSRkr3xbRpVnTFkNwCKsxgc4jNgDKomfSBWYIA=; b=YgMVUYFLhBOApU7+ou3fWg3sk5JGDY7zw3dsOZ9a3wAzlpOnQVlEHFYtQ9hQqBkn+g Ukbjiq7kwX+BejxF0MOcDqJoglGqAvIkX1kS542Nhy8gpzZXlDtk6mDtbn2/W7il46NC Doo+RbaNHjsrj5Lxwenrnv+1AYDvY/GVCHm5ORrTWzR8Z4nkIGLI6L9vh9wFgH8z+zBv hsQSoPAkAqDGdfJxA/t5iPruv0cs2PXaxDCKC2awgVCSiDLnbEK1ZJO6WpPO1vJp6XwK TrCYYhzw/aft4Uhx29/I7xEdKImnWD4dcIrlleTYlv3hjr200IK2uG2EzpK30F7SNC0q aC9w== 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; bh=HIQT5nSRkr3xbRpVnTFkNwCKsxgc4jNgDKomfSBWYIA=; b=mooQtLgU9NnKu9hy/gBU95fM58qtP849eVkAFuSdK1KGUdT4LuVQFfUd2tZTgnuTYJ KiGmsLBiut5aG+ON/Fm459giv3s4sXOFWxPcooCWiIiniSke9ZMXB634ZHI+IZaieglC e/VWhym8JPgxJ/50Ak5bDX6U4XLk3sUu8iSOwWJf1rQBjDdCU1C9psD7FdgjYRZ5ll5X 4ZcUsYOIyJCbKebGRvik1c3puoaH+TX/39y076qYqA9XN2P9NQEaw9Cu794xnKyfluWr xnpefZHWJqaCIuF0E9oIfGSWUalwqyCIpQA7XXxtrqbeHh69GUOuInp0SQ+MwjddoLAO Zgng== X-Gm-Message-State: AD7BkJKIdqcCaDhmCWgLVcafuYQLlXvZJgzHb74UEuhAzvgNlMwNnGzr4khaR7HmxTP/M9Co+cTnWqjqBWAQDA== MIME-Version: 1.0 X-Received: by 10.25.77.13 with SMTP id a13mr9046203lfb.62.1456849720478; Tue, 01 Mar 2016 08:28:40 -0800 (PST) Received: by 10.112.110.68 with HTTP; Tue, 1 Mar 2016 08:28:40 -0800 (PST) In-Reply-To: <31c6e4048a9f40438f17e2902cd5874d@XCH-ALN-018.cisco.com> References: <31c6e4048a9f40438f17e2902cd5874d@XCH-ALN-018.cisco.com> Date: Tue, 1 Mar 2016 08:28:40 -0800 Message-ID: From: Andy Bierman To: "Maros Marsalek -X (mmarsale - PANTHEON TECHNOLOGIES at Cisco)" Content-Type: multipart/alternative; boundary=001a114046aa14aef7052cff42cd Archived-At: Cc: "Tony Tkacik -X \(ttkacik - PANTHEON TECHNOLOGIES at Cisco\)" , "netconf@ietf.org" Subject: Re: [Netconf] Netconf, none operation and non-presence containers 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 Mar 2016 16:28:46 -0000 --001a114046aa14aef7052cff42cd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 1, 2016 at 7:33 AM, Maros Marsalek -X (mmarsale - PANTHEON TECHNOLOGIES at Cisco) wrote: > Hello netconf group, > > > > We=E2=80=99ve run into following situation with NETCONF and we would like= to know > your opinion on what=E2=80=99s the correct behavior here: > > > > Model (root non-presence container with nested list) : > > > > container mapping-nodes { > > list mapping-node{ > > key "id"; > > leaf id { > > type string; > > } > > } > > } > > > > Netconf edit-config RPC (replacing mapping-node entry with none operation > for mapping-nodes container, in an empty data store): > > > > > > =E2=80=A6 > > none > > > > > > xmlns:a=3D"urn:ietf:params:xml:ns:netconf:base:1.0" a:operation=3D"replac= e"> > > node1-put > > > > > > > > > > > > And the question here is: Whether the edit should fail or not ? > > The problem is that mapping-nodes container does not exist and in > edit-config rpc, there=E2=80=99s =E2=80=9Cnone=E2=80=9D operation associa= ted to it. > > Our first assumption was that the resulting data structure should be > invalid due to missing root container and rpc should fail. > > However, the container is non-presence (exists only for organizing the > hierarchy of data nodes), which means that it may be created/deleted as > child nodes appear/disappear. > > In which case, the operation doesn=E2=80=99t have to fail and can create > mapping-nodes container even if =E2=80=9Cnone=E2=80=9D operation is assoc= iated with it. > The edit should fail. NETCONF has no requirement that operation=3Dnone will create missing NP-containers. I can only find text that says operation=3Dnone means the server will not alter these nodes. > > > Regards, > > Maros > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a114046aa14aef7052cff42cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 1, 2016 at 7:33 AM, Maros Marsalek -X (mmarsale - PANTHEON = TECHNOLOGIES at Cisco) <mmarsale@cisco.com> wrote:

Hello netconf group,

=C2=A0

We=E2=80=99ve run into following situation with NETC= ONF and we would like to know your opinion on what=E2=80=99s the correct be= havior here:

=C2=A0

Model (root non-presence container with nested list)= :

=C2=A0

container mapping-nodes {

=C2=A0=C2=A0=C2=A0 list mapping-node{<= /p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 key "= ;id";

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf id {=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 type string;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<= u>

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

}

=C2=A0

Netconf edit-config RPC (replacing mapping-node entr= y with none operation for mapping-nodes container, in an empty data store):=

=C2=A0

=C2=A0=C2=A0=C2=A0 <edit-config>=

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

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <defau= lt-operation>none</default-operation>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <confi= g>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 <mapping-nodes xmlns=3D"urn:opendaylight:mdsal:mapp= ing:test">

=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 <mapping-node xmlns:a=3D"ur= n:ietf:params:xml:ns:netconf:base:1.0" a:operation=3D"replace&quo= t;>

=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 <id>n= ode1-put</id>

=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</mapping-node>=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 </mapping-nodes>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </conf= ig>

=C2=A0=C2=A0=C2=A0 </edit-config>

=C2=A0

And the question here is: Whether the edit should fa= il or not ?

The problem is that mapping-nodes container does not= exist and in edit-config rpc, there=E2=80=99s =E2=80=9Cnone=E2=80=9D opera= tion associated to it.

Our first assumption was that the resulting data str= ucture should be invalid due to missing root container and rpc should fail.=

However, the container is non-presence (exists only = for organizing the hierarchy of data nodes), which means that it may be cre= ated/deleted as child nodes appear/disappear.

In which case, the operation doesn=E2=80=99t have to= fail and can create mapping-nodes container even if =E2=80=9Cnone=E2=80=9D= operation is associated with it.



The edit should fail.

NETCON= F has no requirement that operation=3Dnone will create missing NP-container= s.
I can only find text that says operation=3Dnone means the serv= er will not alter these nodes.

=C2=A0

=C2=A0

Regards,

Maros



Andy
=C2=A0
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf


--001a114046aa14aef7052cff42cd-- From nobody Tue Mar 1 08:56:36 2016 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 C850F1B2FBB for ; Tue, 1 Mar 2016 08:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, 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 ogLUHL07btc6 for ; Tue, 1 Mar 2016 08:56:33 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D39C1B2F7B for ; Tue, 1 Mar 2016 08:55:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2439; q=dns/txt; s=iport; t=1456851325; x=1458060925; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=P7gwBWTUCAv6vEhtAtbx6hvkKlBwlesVBOyD9OlIG9Y=; b=KwiQG+IiF397iebM+cD1W7S0buia9gv4ZrQsWQc5AaTTEDHWGCiBWohQ MaSA54XrXxc5pnrcT2xuaVthmkA6az6YvYzWoHVurx72M/0u0C1V3REn0 xMeJjeacJAWhvW5mW+x8wMyLuI2IpMH+G4BsaZqNR6atHZWjdNKUjGf4e Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAgC8yNVW/5hdJa1egzpSbQa6LgENg?= =?us-ascii?q?WYXCoUoSgKBSzgUAQEBAQEBAWQnhEEBAQEEAQEBNzQXBAIBCBUBDxEQIQYLJQI?= =?us-ascii?q?EARIIiAIDEg67QA2EQQEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhhKEOoI6hjUFl?= =?us-ascii?q?w4Bi22BbYFnh2mFLYcIh0MBHgEBQoNkaodDfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,523,1449532800"; d="scan'208";a="76520425" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Mar 2016 16:55:24 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u21GtOLi024724 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Mar 2016 16:55:24 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 1 Mar 2016 10:55:23 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.009; Tue, 1 Mar 2016 10:55:23 -0600 From: "Eric Voit (evoit)" To: "t.petch" , Mahesh Jethanandani , NETCONF Thread-Topic: [Netconf] One or three drafts? Thread-Index: AQHRcXqMvpVS9r8sUESYF00ZpTigLZ9DMfWA Date: Tue, 1 Mar 2016 16:55:23 +0000 Message-ID: <03529de044bc4ebe8dcdc950b494c59b@XCH-ALN-013.cisco.com> References: <00a701d17179$f46e35e0$4001a8c0@gateway.2wire.net> In-Reply-To: <00a701d17179$f46e35e0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.252.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] One or three drafts? 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 Mar 2016 16:56:35 -0000 Hi Tom, In the end, the number of drafts is not a huge issue for us. To date, we h= ave segmented drafts so as to: (a) Maximize transport independence.=20 (b) Reduce technology options within any one draft. (We don't want things = overly complex so that operators can't easily refer to desired subset.) (c) Maximize alignment with any in-flight RFC5277bis spec =20 At the next IETF, we would be happy to make a proposal for functionality se= gmentation across the following elements: =20 Subscription Configuration=20 - Static (& Multiple Receivers) - Dynamic (& Parameter Negotiation) - Subscription QoS & Prioritized Push - Filter (RFC6241, RFC5277, other) Transport (Netconf, Restconf, HTTP2, other?) RFC5277bis (new and/or augmented RPCs) Based on whatever discussion follows, we will take WG guidance on appropria= te draft segmentation. Eric > -----Original Message----- > From: Netconf, February 27, 2016 11:14 AM >=20 > ---- Original Message ----- > From: "Mahesh Jethanandani" > To: "NETCONF" > Sent: Saturday, February 27, 2016 1:21 AM >=20 > > I am following up on the discussion in IETF 94 on the question of > whether we need one or three drafts for YANG push. One draft would mean a > merge of NETCONF and RESTCONF YANG push draft, while three drafts would > be a common draft, the second one for NETCONF specific part and the third= for > the RESTCONF specific part. There was no preference for just two drafts -= one > for NETCONF and one for RESTCONF with common parts either duplicated or > referenced. The vote in the room seemed to indicate a tie for 1 or 3 draf= ts with > no apparent winner. > > > > The authors indicated a preference to keep them as separate drafts, > but others in the room seemed to indicate that other drafts, like call ho= me and > zero touch are doing it as a single draft. > > > > Can we have a discussion of whether folks would prefer to read and > follow YANG push as three separate drafts or would they prefer to see the= m > merged? >=20 > I don't know, can we have a discussion:-) >=20 > Well, assuming we can, I am for a merge into one I-D. >=20 > Tom Petch >=20 > > Thanks. > > > > Mahesh & Mehmet. > > >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Mar 3 02:20:01 2016 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 F0A8C1B40A9 for ; Thu, 3 Mar 2016 02:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_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 5al8CwzML1c4 for ; Thu, 3 Mar 2016 02:19:54 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0775.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::775]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4D41B40AA for ; Thu, 3 Mar 2016 02:19:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CGw7SCE4RrJxqjrfYMFACLeBw184eUxSbqYXUYVVQXk=; b=QA2CD0ieYJH7C45Bv2WK4z1x0ydLPNHdBvX8XWQrgcdoJcyd9vjStvfRTcVRsio4RIxzHdA80nqDrE1bMwoPcBkHQ+ADEPi4GCE/NLbZCrh0xek4RMjetcODxsgGUWvuhoxLT0FHmzdui8w3a/P7w7bQWHJjD5gjf0UB4xuAsR4= Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.167.153.133) by AM4PR07MB1618.eurprd07.prod.outlook.com (10.166.132.148) with Microsoft SMTP Server (TLS) id 15.1.415.20; Thu, 3 Mar 2016 10:19:33 +0000 Message-ID: <021e01d17535$a70b30e0$4001a8c0@gateway.2wire.net> From: t.petch To: "Eric Voit (evoit)" , Mahesh Jethanandani , NETCONF References: <00a701d17179$f46e35e0$4001a8c0@gateway.2wire.net> <03529de044bc4ebe8dcdc950b494c59b@XCH-ALN-013.cisco.com> Date: Thu, 3 Mar 2016 10:05:07 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.167.153.133] X-ClientProxiedBy: AM4PR02CA0009.eurprd02.prod.outlook.com (25.165.239.147) To AM4PR07MB1618.eurprd07.prod.outlook.com (25.166.132.148) X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB1618; 2:d6gDiYZ8GmfaPWIBZItW3jO9lXxGK5mPuh6fLAmf8u7IQeQnBx7T/mmoA21Xb+iaKyaLYQD6647kLsqWCKcdFuSbeoXhhvw6QW2r/0RPti/ajdMip1DsODps5Co9lBBFbjhNprS+WJtlCrybHBVCug==; 3:P/l2ZK9C2rE8oNCd470hWBDBYXM2Xb9aDg/MqlOluPX4rfur7yM40iOEB0z/RBRsk1IE9bwU3eRZeHr/HsP8LrWx77nE8Od+fjEKtXl1u652PnB55YbSN+Okr1mmCtaS; 25:ayhA0ioQ9hrGM6BsB8Rf5esFwwcH6CmmA95YwJ1WY9WCABa4fvjBPyrN6sH48eEZtOd4vRPJFIIh7J+zAuAEDPOqHdbvSy+uOmp/id8yKs/Wwp7sv9rsQILuqjOCbhjpSuMH9migxJbPtkk7xTBwk84T3RWKr4CjEc5N0J1tRl6Gpzqzonn4iOlJEY1IkQZYfaTY8M2k4SmhsoJ7I/PMm/AXqcCHix6ygg1xEbyooGNvtL2LY3FMPKPfB4sn0tAy9zc+ub2zaFuAkcaacfXWJXn/08qMDeP65LpzWU2ReekerEXgvWYx9iwrrA3IwAextyoh0CNsU1b539f/CLmXxg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR07MB1618; X-MS-Office365-Filtering-Correlation-Id: 47a45c75-63b4-48c7-67da-08d3434d50ad X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(95692535739014)(178726229863574); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AM4PR07MB1618; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1618; X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB1618; 4:7hSGln2Olc3k7/KRz95yJlan9b59GqbbGNT2r0iF52T6nCLfNpQGJEDbqd+t8IMwXsQVRFj9JCXAv8p5D4JrZmWv0bYyrVBhbflE1DsCWNAv8frnqnxFJctw4L4xDXZIkc3n12p1CkkBtBn7S4P4shLNo5tWIm+5l8IOF5iZDo0oVEsxY8E80te9IsaKsx+VUuiZY5QobmyzCObQ+gXbOb8h+K7x1ds98RNEARgP/3CpgVqVJVeZ1k4QoAU+r9GSxYiZmYM4EDNsmClTmd2KsTtflmv0V6QmWZCa+dd6i0Vv1gSDdG/6lbfe/SpKgEGeo7vu0pQs1rWzS7u4uZcUvRrGk5b4jbAK9GBx+h9J7Wshkha95lh19duviX9DJtJhMZjBD5i0gV7VEe5IbWYRXn1EWeaCIn7lfr0p7N25a14w+9JoPZKgSiadHBRkUc0UUeEg+BW0secKr65dssP0Jg== X-Forefront-PRVS: 0870212862 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(377454003)(13464003)(51444003)(92566002)(116806002)(66066001)(61296003)(19580405001)(19580395003)(14496001)(42186005)(107886002)(77096005)(87976001)(189998001)(44736004)(50226001)(1556002)(15975445007)(47776003)(62236002)(33646002)(44716002)(1096002)(50466002)(6116002)(3846002)(23756003)(76176999)(5001770100001)(586003)(40100003)(5001960100004)(86362001)(1456003)(122386002)(50986999)(5004730100002)(230700001)(561944003)(81816999)(84392002)(5008740100001)(81686999)(2906002)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1618; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AM4PR07MB1618; 23:vhQxwTmASr3jx8D17qJlPuHOWHHbd/K05Sgqpy0?= =?iso-8859-1?Q?Ipnf0WEN87o1eGlFmZq3opEHdmptW2nDWKPKEMGN/N7tbSTS7SophRXEnf?= =?iso-8859-1?Q?T4cov6HrMsW9g7QWV2Ls3Px5+7la0liO+xoIZAu6rpb6S1ZrykbiNLBMRJ?= =?iso-8859-1?Q?C2RKWQRWts2hPjLOVZKuZtzIKTsmDvCNCLm10Aaq2ISc9myixby8yL1F3S?= =?iso-8859-1?Q?ljHV4rDq8u6S1A+jT2geDjewUEI7U8cboKGHfQmczd+Z2zLUXxPa5UO5GJ?= =?iso-8859-1?Q?V19f7TNTYvoO1J0wojl7x0uSDNPf3c+f4Nvtw1T+TS9Q1sWTQMq95SL/hg?= =?iso-8859-1?Q?6qQTmuFBr/I53yQl0kjTouAwV7LKHzh2FP8gt/MieFFORO0BcRtoJ4M6+H?= =?iso-8859-1?Q?nujkIiQnAgxS0kai8uZKsrfdUWqMgYeMD+vefhN0QK4D72vjqhZEqp/9Dy?= =?iso-8859-1?Q?M1HFRpDqDgoCvJonjDIyDpq1nLgt6QMo0GAp5O89e55XNO94iqyI7j/S+G?= =?iso-8859-1?Q?iQ63qXVROUYmTP3kGW2zV7gOGUNGLersaHLWj+/0X108jhJ1uYUw52EblP?= =?iso-8859-1?Q?EnZaBL5kLHwb3fzO6E3gVMakQ1PfBukMJruHPsh4rfkKdyWxAqZgSOOIDs?= =?iso-8859-1?Q?D0/lLNSXu+I6LDhFNM9oq/EF2Z6k23KgGRblSbwZ1tlmh3+7rtxbIlB2aX?= =?iso-8859-1?Q?bd3HqsUjDX7CQHFgpxuQQQjbcLUKl97AuSCZgZJL4inySoyOI7dmcuZWbQ?= =?iso-8859-1?Q?+oyx3XBaArHR5WhviI/KxwoEIR7otyiM45CweiaSnsPkgK0EJRBvcHHivA?= =?iso-8859-1?Q?9+eNo2C//1dgJ2M62jvNLEnVQZq/BbWXi1Q06dPF5FA+42LB9GGvk9mp3y?= =?iso-8859-1?Q?YNgRJZgma6Wk7F4Ee9DEF5PFxcH9UUxmbLrAwhnRnhTCyXS79Nclg+/5zp?= =?iso-8859-1?Q?/xtuifq+EDPeDTRp/o1LyCg5Y1/rlWZjRvoyiGAkBUPNv1nWFnT9F4ABB9?= =?iso-8859-1?Q?WwaZ991KpuOSTCinfvjkbnRcs3/PkO3jYWpn0AxsDydj4tVg+xmQIWH3mZ?= =?iso-8859-1?Q?KFURAAxlf0sFNm8uWy3N3e4fHL8Ag++/Cl6qJJMSbUWOXVovW97Gs/Wx62?= =?iso-8859-1?Q?hTE5lYhrNwJ+jT7zTij+mu7ADcpGgxVKDqj8trA4sJRAPkWHd67k0S56JB?= =?iso-8859-1?Q?lNhfoEqDJ64gfcBrRZ/P7rtCTU1jIOOt9xq/3PohWQxRDQ0+/9p3/lB20B?= =?iso-8859-1?Q?9JS9JVRXclSUzR1BY9yOr6exBa6inB+kOKYgAVR1Qr5LQITGZba3WRwm85?= =?iso-8859-1?Q?0wpO2kqkFYTkB9AWdBhpwtl0FkKBVNq2Xw7Y8RHF7lYIQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB1618; 5:hHBzI9GkFlytraPYBSMfRbiKJ/UnXrPRiXHYcy2zJfqsBT4zCs3GL9nQOVAhB7OREEGomJYlfCaRvop+sY9uALUw2MNHTllQ87KgDyEgWbNlGzoch/AYTi+q+wg2ThdFygYpFghLfL08djTqPM78BA==; 24:Clspytb7dTH3Chwis43Ze4H8XjrzNZfEyTevEYA1HbJYWIL9W03WjEkGbiW79E1nKlcRKrTGRIOUHtet+78kO3YdrDKFi8iovFDzXrB1Toc= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Mar 2016 10:19:33.2737 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1618 Archived-At: Subject: Re: [Netconf] One or three drafts? 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, 03 Mar 2016 10:20:00 -0000 ----- Original Message ----- From: "Eric Voit (evoit)" To: "t.petch" ; "Mahesh Jethanandani" ; "NETCONF" Sent: Tuesday, March 01, 2016 4:55 PM Hi Tom, In the end, the number of drafts is not a huge issue for us. To date, we have segmented drafts so as to: (a) Maximize transport independence. (b) Reduce technology options within any one draft. (We don't want things overly complex so that operators can't easily refer to desired subset.) (c) Maximize alignment with any in-flight RFC5277bis spec At the next IETF, we would be happy to make a proposal for functionality segmentation across the following elements: Subscription Configuration - Static (& Multiple Receivers) - Dynamic (& Parameter Negotiation) - Subscription QoS & Prioritized Push - Filter (RFC6241, RFC5277, other) Transport (Netconf, Restconf, HTTP2, other?) RFC5277bis (new and/or augmented RPCs) Based on whatever discussion follows, we will take WG guidance on appropriate draft segmentation. As an editor of an I-D, I much prefer multiple drafts so that I can have my own self-contained world and do not have to liaise with people I do not know over a slow and unreliable communication medium, like e-mail:-) As a consumer of I-Ds, I want everything together in one place so I do not have to shuffle multiple documents (feasible with paper on desk, a potential nightmare on screens) and chase cross references, terms defined elsewhere etc. The only caveat is that when an I-D gets too big, which YANG did years ago, then it becomes unusable and should be split. 'push' may be approaching that state but I think not. Some splits are more sensible that others. I think that layered stacks was one of the great inventions of IT and so would bundle applications together and split them from transport, from the transport-like security, and so on. Tom Petch Eric > -----Original Message----- > From: Netconf, February 27, 2016 11:14 AM > > ---- Original Message ----- > From: "Mahesh Jethanandani" > To: "NETCONF" > Sent: Saturday, February 27, 2016 1:21 AM > > > I am following up on the discussion in IETF 94 on the question of > whether we need one or three drafts for YANG push. One draft would mean a > merge of NETCONF and RESTCONF YANG push draft, while three drafts would > be a common draft, the second one for NETCONF specific part and the third for > the RESTCONF specific part. There was no preference for just two drafts - one > for NETCONF and one for RESTCONF with common parts either duplicated or > referenced. The vote in the room seemed to indicate a tie for 1 or 3 drafts with > no apparent winner. > > > > The authors indicated a preference to keep them as separate drafts, > but others in the room seemed to indicate that other drafts, like call home and > zero touch are doing it as a single draft. > > > > Can we have a discussion of whether folks would prefer to read and > follow YANG push as three separate drafts or would they prefer to see them > merged? > > I don't know, can we have a discussion:-) > > Well, assuming we can, I am for a merge into one I-D. > > Tom Petch > > > Thanks. > > > > Mahesh & Mehmet. > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Mar 3 07:13:42 2016 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 AEE171AD356 for ; Thu, 3 Mar 2016 07:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.506 X-Spam-Level: X-Spam-Status: No, score=-14.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, 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 ibv33HMxJoZK for ; Thu, 3 Mar 2016 07:13:38 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1E61AD35B for ; Thu, 3 Mar 2016 07:13:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25418; q=dns/txt; s=iport; t=1457018016; x=1458227616; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OSuZWrmkpfyHzise/3KMw/vboNbKivpIZPNl0XO+5eY=; b=L2fGoZH4s34DYHah5sgnMigFbl4eJQTJGIHBmOvF1yqRf9948b1WAfYj ZiuSj0ANmElGzXWQuQmr38i6Qb/PjNIhlMdnQ07/GTf4sgJ8nBzrxaj8l Y2AncGMDNvZGS8M7rMwq7GcLbJ9ZzYWwy7dyxunWSRcQMgtxDc4ZTYRvb 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAgCiU9hW/5FdJa1dgm5MUm0GuiYBD?= =?us-ascii?q?YFoFwEJhSRKAhyBDzgUAQEBAQEBAWQnhEEBAQEEAQEBIApBCxACAQYCEQQBASg?= =?us-ascii?q?DAgICHQgLFAkIAQEEDgUIiBkOkSmdF48vAQEBAQEBAQEBAQEBAQEBAQEBAQEBF?= =?us-ascii?q?YpUhCBFCYJKgToFkneEJQEThUaIAoIyjEyOTAEPDwEBQoNkagEBiCJ+AQEB?= X-IronPort-AV: E=Sophos; i="5.22,532,1449532800"; d="scan'208,217"; a="77015221" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Mar 2016 15:13:35 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u23FDZdO017755 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Mar 2016 15:13:35 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 3 Mar 2016 09:13:34 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1104.009; Thu, 3 Mar 2016 09:13:34 -0600 From: "Maros Marsalek -X (mmarsale - PANTHEON TECHNOLOGIES at Cisco)" To: Andy Bierman Thread-Topic: [Netconf] Netconf, none operation and non-presence containers Thread-Index: AdFzz7m8JjrF2l7bTBCaKawIVSebJAAOfqgAAEuLfjA= Date: Thu, 3 Mar 2016 15:13:34 +0000 Message-ID: <50000fdde017413f93a87fd7f4d6f30e@XCH-ALN-018.cisco.com> References: <31c6e4048a9f40438f17e2902cd5874d@XCH-ALN-018.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.200.165] Content-Type: multipart/alternative; boundary="_000_50000fdde017413f93a87fd7f4d6f30eXCHALN018ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Tony Tkacik -X \(ttkacik - PANTHEON TECHNOLOGIES at Cisco\)" , "netconf@ietf.org" Subject: Re: [Netconf] Netconf, none operation and non-presence containers 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, 03 Mar 2016 15:13:40 -0000 --_000_50000fdde017413f93a87fd7f4d6f30eXCHALN018ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGV5IEFuZHksDQoNClRoaXMgbm90ZSBhdCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NjAyMCNzZWN0aW9uLTcuNS44IGlzIGludGVyZXN0aW5nOg0KDQrigJxJZiBhIGNvbnRhaW5lciBk b2VzIG5vdCBoYXZlIGEgInByZXNlbmNlIiBzdGF0ZW1lbnQgYW5kIHRoZSBsYXN0DQogICBjaGls ZCBub2RlIGlzIGRlbGV0ZWQsIHRoZSBORVRDT05GIHNlcnZlciBNQVkgZGVsZXRlIHRoZSBjb250 YWluZXIu4oCdDQoNCk1lYW5pbmcgdGhhdCB0aGUgTkVUQ09ORiBzZXJ2ZXIgbWF5IGNvbnRyb2wg bGlmZWN5Y2xlIG9mIG5vbi1wcmVzZW5jZSBjb250YWluZXJzIChpbiB0ZXJtcyBvZiBkZWxldGUg YXQgbGVhc3QpLg0KDQpCdXQgb24gdGhlIG90aGVyIGhhbmQsIE5FVENPTkYgUkZDIGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzYyNDEjc2VjdGlvbi03LjIgaXMgc2F5aW5nOg0KDQrigJxJ ZiB0aGUgY29uZmlndXJhdGlvbiBpbiB0aGUgPGNvbmZpZz4gcGFyYW1ldGVyIGNvbnRhaW5zIGRh dGEgZm9yIHdoaWNoIHRoZXJlIGlzIG5vdCBhDQogICAgICAgICAgICBjb3JyZXNwb25kaW5nIGxl dmVsIGluIHRoZSB0YXJnZXQgZGF0YXN0b3JlLCBhbiA8cnBjLWVycm9yPiBpcyByZXR1cm5lZOKA puKAnQ0KDQpXaXRoIHRoaXMgY29tYmluYXRpb24gd2UgbWlnaHQgZW5kIHVwIGluIGEgc2l0dWF0 aW9uIHdoZXJlIHNlcnZlciBkZWxldGVzIGFuIGVtcHR5LCBub24tcHJlc2VuY2UsIHBhcmVudCBj b250YWluZXIgYXQgb25lIHBvaW50IGFuZCB1c2VyIHRyaWVzIHRvIGNyZWF0ZSBvbmUgb2YgaXRz IGNoaWxkIG5vZGVzIHdpdGgg4oCcbm9uZeKAnSBvcGVyYXRpb24gYXNzaWduZWQgdG8gdGhlIHBh cmVudCwgbm9uLXByZXNlbmNlIGNvbnRhaW5lci4gUmVxdWVzdCB3b3VsZCBmYWlsIGJlY2F1c2Ug dGhlIG5vbi1wcmVzZW5jZSBjb250YWluZXIgd2FzIGRlbGV0ZWQgc2lsZW50bHkgaW4gdGhlIGJh Y2tncm91bmQsIGJ1dCB0aGUgdXNlciBoYXMgbm8gd2F5IG9mIGtub3dpbmcuIE1lYW5pbmcgdGhh dCB0aGUgYmVoYXZpb3IgZm9yIG5vbi1wcmVzZW5jZSBjb250YWluZXJzIG1pZ2h0IGJlIGFzeW1t ZXRyaWMgYW5kIGNvbmZ1c2luZyBpbiB0ZXJtcyBvZiBhdXRvIGNyZWF0ZS9kZWxldGUuIFRoYXTi gJlzIHdoeSB3ZSB0aGluayBORVRDT05GIHNlcnZlciBzaG91bGQgYmUgYWJsZSB0byBhdXRvLWNy ZWF0ZSBub24tcHJlc2VuY2UgY29udGFpbmVycyBldmVuIHdpdGgg4oCcbm9uZeKAnSBvcGVyYXRp b24gYXNzaWduZWQgdG8gaXQsIGhvd2V2ZXIgdGhlIHNwZWNzIGFyZSBub3QgY2xlYXIgaW4gdGhp cyBjYXNlLg0KDQpSZWdhcmRzLA0KTWFyb3MNCg0KRnJvbTogQW5keSBCaWVybWFuIFttYWlsdG86 YW5keUB5dW1hd29ya3MuY29tXQ0KU2VudDogVHVlc2RheSwgTWFyY2ggMDEsIDIwMTYgNToyOSBQ TQ0KVG86IE1hcm9zIE1hcnNhbGVrIC1YIChtbWFyc2FsZSAtIFBBTlRIRU9OIFRFQ0hOT0xPR0lF UyBhdCBDaXNjbykgPG1tYXJzYWxlQGNpc2NvLmNvbT4NCkNjOiBuZXRjb25mQGlldGYub3JnOyBU b255IFRrYWNpayAtWCAodHRrYWNpayAtIFBBTlRIRU9OIFRFQ0hOT0xPR0lFUyBhdCBDaXNjbykg PHR0a2FjaWtAY2lzY28uY29tPg0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBOZXRjb25mLCBub25l IG9wZXJhdGlvbiBhbmQgbm9uLXByZXNlbmNlIGNvbnRhaW5lcnMNCg0KDQoNCk9uIFR1ZSwgTWFy IDEsIDIwMTYgYXQgNzozMyBBTSwgTWFyb3MgTWFyc2FsZWsgLVggKG1tYXJzYWxlIC0gUEFOVEhF T04gVEVDSE5PTE9HSUVTIGF0IENpc2NvKSA8bW1hcnNhbGVAY2lzY28uY29tPG1haWx0bzptbWFy c2FsZUBjaXNjby5jb20+PiB3cm90ZToNCkhlbGxvIG5ldGNvbmYgZ3JvdXAsDQoNCldl4oCZdmUg cnVuIGludG8gZm9sbG93aW5nIHNpdHVhdGlvbiB3aXRoIE5FVENPTkYgYW5kIHdlIHdvdWxkIGxp a2UgdG8ga25vdyB5b3VyIG9waW5pb24gb24gd2hhdOKAmXMgdGhlIGNvcnJlY3QgYmVoYXZpb3Ig aGVyZToNCg0KTW9kZWwgKHJvb3Qgbm9uLXByZXNlbmNlIGNvbnRhaW5lciB3aXRoIG5lc3RlZCBs aXN0KSA6DQoNCmNvbnRhaW5lciBtYXBwaW5nLW5vZGVzIHsNCiAgICBsaXN0IG1hcHBpbmctbm9k ZXsNCiAgICAgICAga2V5ICJpZCI7DQogICAgICAgIGxlYWYgaWQgew0KICAgICAgICAgICAgdHlw ZSBzdHJpbmc7DQogICAgICAgIH0NCiAgICB9DQp9DQoNCk5ldGNvbmYgZWRpdC1jb25maWcgUlBD IChyZXBsYWNpbmcgbWFwcGluZy1ub2RlIGVudHJ5IHdpdGggbm9uZSBvcGVyYXRpb24gZm9yIG1h cHBpbmctbm9kZXMgY29udGFpbmVyLCBpbiBhbiBlbXB0eSBkYXRhIHN0b3JlKToNCg0KICAgIDxl ZGl0LWNvbmZpZz4NCiAgICAgICAg4oCmDQogICAgICAgIDxkZWZhdWx0LW9wZXJhdGlvbj5ub25l PC9kZWZhdWx0LW9wZXJhdGlvbj4NCiAgICAgICAgPGNvbmZpZz4NCiAgICAgICAgICAgIDxtYXBw aW5nLW5vZGVzIHhtbG5zPSJ1cm46b3BlbmRheWxpZ2h0Om1kc2FsOm1hcHBpbmc6dGVzdCI+DQog ICAgICAgICAgICAgICAgPG1hcHBpbmctbm9kZSB4bWxuczphPSJ1cm46aWV0ZjpwYXJhbXM6eG1s Om5zOm5ldGNvbmY6YmFzZToxLjAiIGE6b3BlcmF0aW9uPSJyZXBsYWNlIj4NCiAgICAgICAgICAg ICAgICAgICAgPGlkPm5vZGUxLXB1dDwvaWQ+DQogICAgICAgICAgICAgICAgPC9tYXBwaW5nLW5v ZGU+DQogICAgICAgICAgICA8L21hcHBpbmctbm9kZXM+DQogICAgICAgIDwvY29uZmlnPg0KICAg IDwvZWRpdC1jb25maWc+DQoNCkFuZCB0aGUgcXVlc3Rpb24gaGVyZSBpczogV2hldGhlciB0aGUg ZWRpdCBzaG91bGQgZmFpbCBvciBub3QgPw0KVGhlIHByb2JsZW0gaXMgdGhhdCBtYXBwaW5nLW5v ZGVzIGNvbnRhaW5lciBkb2VzIG5vdCBleGlzdCBhbmQgaW4gZWRpdC1jb25maWcgcnBjLCB0aGVy ZeKAmXMg4oCcbm9uZeKAnSBvcGVyYXRpb24gYXNzb2NpYXRlZCB0byBpdC4NCk91ciBmaXJzdCBh c3N1bXB0aW9uIHdhcyB0aGF0IHRoZSByZXN1bHRpbmcgZGF0YSBzdHJ1Y3R1cmUgc2hvdWxkIGJl IGludmFsaWQgZHVlIHRvIG1pc3Npbmcgcm9vdCBjb250YWluZXIgYW5kIHJwYyBzaG91bGQgZmFp bC4NCkhvd2V2ZXIsIHRoZSBjb250YWluZXIgaXMgbm9uLXByZXNlbmNlIChleGlzdHMgb25seSBm b3Igb3JnYW5pemluZyB0aGUgaGllcmFyY2h5IG9mIGRhdGEgbm9kZXMpLCB3aGljaCBtZWFucyB0 aGF0IGl0IG1heSBiZSBjcmVhdGVkL2RlbGV0ZWQgYXMgY2hpbGQgbm9kZXMgYXBwZWFyL2Rpc2Fw cGVhci4NCkluIHdoaWNoIGNhc2UsIHRoZSBvcGVyYXRpb24gZG9lc27igJl0IGhhdmUgdG8gZmFp bCBhbmQgY2FuIGNyZWF0ZSBtYXBwaW5nLW5vZGVzIGNvbnRhaW5lciBldmVuIGlmIOKAnG5vbmXi gJ0gb3BlcmF0aW9uIGlzIGFzc29jaWF0ZWQgd2l0aCBpdC4NCg0KDQpUaGUgZWRpdCBzaG91bGQg ZmFpbC4NCg0KTkVUQ09ORiBoYXMgbm8gcmVxdWlyZW1lbnQgdGhhdCBvcGVyYXRpb249bm9uZSB3 aWxsIGNyZWF0ZSBtaXNzaW5nIE5QLWNvbnRhaW5lcnMuDQpJIGNhbiBvbmx5IGZpbmQgdGV4dCB0 aGF0IHNheXMgb3BlcmF0aW9uPW5vbmUgbWVhbnMgdGhlIHNlcnZlciB3aWxsIG5vdCBhbHRlciB0 aGVzZSBub2Rlcy4NCg0KDQoNClJlZ2FyZHMsDQpNYXJvcw0KDQoNCkFuZHkNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYgbWFpbGluZyBs aXN0DQpOZXRjb25mQGlldGYub3JnPG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoNCg== --_000_50000fdde017413f93a87fd7f4d6f30eXCHALN018ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGV5IEFu ZHksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGlzIG5vdGUg YXQNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MDIwI3NlY3Rpb24t Ny41LjgiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MDIwI3NlY3Rpb24tNy41Ljg8 L2E+IGlzIGludGVyZXN0aW5nOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+4oCcSWYgYSBjb250YWluZXIgZG9lcyBub3QgaGF2ZSBhICZxdW90O3ByZXNlbmNlJnF1 b3Q7IHN0YXRlbWVudCBhbmQgdGhlIGxhc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 IGNoaWxkIG5vZGUgaXMgZGVsZXRlZCwgdGhlIE5FVENPTkYgc2VydmVyIE1BWSBkZWxldGUgdGhl IGNvbnRhaW5lci7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi Pk1lYW5pbmcgdGhhdCB0aGUgTkVUQ09ORiBzZXJ2ZXIgbWF5IGNvbnRyb2wgbGlmZWN5Y2xlIG9m IG5vbi1wcmVzZW5jZSBjb250YWluZXJzIChpbiB0ZXJtcyBvZiBkZWxldGUgYXQgbGVhc3QpLg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CdXQgb24gdGhlIG90 aGVyIGhhbmQsIE5FVENPTkYgUkZDDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM2MjQxI3NlY3Rpb24tNy4yIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MjQx I3NlY3Rpb24tNy4yPC9hPiBpcyBzYXlpbmc6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj7igJxJZiB0aGUgY29uZmlndXJhdGlvbiBpbiB0aGUgJmx0O2NvbmZpZyZn dDsgcGFyYW1ldGVyIGNvbnRhaW5zIGRhdGEgZm9yIHdoaWNoIHRoZXJlIGlzIG5vdCBhPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb3JyZXNwb25kaW5nIGxldmVsIGluIHRoZSB0YXJnZXQg ZGF0YXN0b3JlLCBhbiAmbHQ7cnBjLWVycm9yJmd0OyBpcyByZXR1cm5lZOKApuKAnTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2l0aCB0aGlzIGNvbWJpbmF0aW9u IHdlIG1pZ2h0IGVuZCB1cCBpbiBhIHNpdHVhdGlvbiB3aGVyZSBzZXJ2ZXIgZGVsZXRlcyBhbiBl bXB0eSwgbm9uLXByZXNlbmNlLCBwYXJlbnQgY29udGFpbmVyIGF0IG9uZSBwb2ludCBhbmQgdXNl ciB0cmllcyB0byBjcmVhdGUgb25lIG9mDQogaXRzIGNoaWxkIG5vZGVzIHdpdGgg4oCcbm9uZeKA nSBvcGVyYXRpb24gYXNzaWduZWQgdG8gdGhlIHBhcmVudCwgbm9uLXByZXNlbmNlIGNvbnRhaW5l ci4gUmVxdWVzdCB3b3VsZCBmYWlsIGJlY2F1c2UgdGhlIG5vbi1wcmVzZW5jZSBjb250YWluZXIg d2FzIGRlbGV0ZWQgc2lsZW50bHkgaW4gdGhlIGJhY2tncm91bmQsIGJ1dCB0aGUgdXNlciBoYXMg bm8gd2F5IG9mIGtub3dpbmcuIE1lYW5pbmcgdGhhdCB0aGUgYmVoYXZpb3IgZm9yIG5vbi1wcmVz ZW5jZQ0KIGNvbnRhaW5lcnMgbWlnaHQgYmUgYXN5bW1ldHJpYyBhbmQgY29uZnVzaW5nIGluIHRl cm1zIG9mIGF1dG8gY3JlYXRlL2RlbGV0ZS4gVGhhdOKAmXMgd2h5IHdlIHRoaW5rIE5FVENPTkYg c2VydmVyIHNob3VsZCBiZSBhYmxlIHRvIGF1dG8tY3JlYXRlIG5vbi1wcmVzZW5jZSBjb250YWlu ZXJzIGV2ZW4gd2l0aCDigJxub25l4oCdIG9wZXJhdGlvbiBhc3NpZ25lZCB0byBpdCwgaG93ZXZl ciB0aGUgc3BlY3MgYXJlIG5vdCBjbGVhciBpbiB0aGlzIGNhc2UuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5NYXJv czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5jb21dDQo8YnI+ DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWFyY2ggMDEsIDIwMTYgNToyOSBQTTxicj4NCjxiPlRv OjwvYj4gTWFyb3MgTWFyc2FsZWsgLVggKG1tYXJzYWxlIC0gUEFOVEhFT04gVEVDSE5PTE9HSUVT IGF0IENpc2NvKSAmbHQ7bW1hcnNhbGVAY2lzY28uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gbmV0 Y29uZkBpZXRmLm9yZzsgVG9ueSBUa2FjaWsgLVggKHR0a2FjaWsgLSBQQU5USEVPTiBURUNITk9M T0dJRVMgYXQgQ2lzY28pICZsdDt0dGthY2lrQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtOZXRjb25mXSBOZXRjb25mLCBub25lIG9wZXJhdGlvbiBhbmQgbm9uLXByZXNl bmNlIGNvbnRhaW5lcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE1hciAxLCAy MDE2IGF0IDc6MzMgQU0sIE1hcm9zIE1hcnNhbGVrIC1YIChtbWFyc2FsZSAtIFBBTlRIRU9OIFRF Q0hOT0xPR0lFUyBhdCBDaXNjbykgJmx0OzxhIGhyZWY9Im1haWx0bzptbWFyc2FsZUBjaXNjby5j b20iIHRhcmdldD0iX2JsYW5rIj5tbWFyc2FsZUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhlbGxvIG5ldGNvbmYg Z3JvdXAsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XZeKAmXZlIHJ1biBpbnRvIGZvbGxv d2luZyBzaXR1YXRpb24gd2l0aCBORVRDT05GIGFuZCB3ZSB3b3VsZCBsaWtlIHRvIGtub3cgeW91 ciBvcGluaW9uIG9uIHdoYXTigJlzIHRoZSBjb3JyZWN0IGJlaGF2aW9yIGhlcmU6PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5Nb2RlbCAocm9vdCBub24tcHJlc2VuY2UgY29udGFpbmVyIHdp dGggbmVzdGVkIGxpc3QpIDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmNvbnRhaW5lciBt YXBwaW5nLW5vZGVzIHs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IGxpc3QgbWFwcGluZy1ub2RlezxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsga2V5ICZxdW90O2lkJnF1b3Q7OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBpZCB7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBlIHN0 cmluZzs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+fTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TmV0Y29uZiBl ZGl0LWNvbmZpZyBSUEMgKHJlcGxhY2luZyBtYXBwaW5nLW5vZGUgZW50cnkgd2l0aCBub25lIG9w ZXJhdGlvbiBmb3IgbWFwcGluZy1ub2RlcyBjb250YWluZXIsIGluIGFuIGVtcHR5IGRhdGEgc3Rv cmUpOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtl ZGl0LWNvbmZpZyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKApjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmx0O2RlZmF1bHQtb3BlcmF0aW9uJmd0O25vbmUmbHQ7L2RlZmF1bHQtb3Bl cmF0aW9uJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2NvbmZpZyZndDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDttYXBwaW5nLW5v ZGVzIHhtbG5zPSZxdW90O3VybjpvcGVuZGF5bGlnaHQ6bWRzYWw6bWFwcGluZzp0ZXN0JnF1b3Q7 Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O21hcHBpbmctbm9kZSB4bWxuczphPSZxdW90O3Vybjpp ZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCZxdW90OyBhOm9wZXJhdGlvbj0mcXVv dDtyZXBsYWNlJnF1b3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmx0O2lkJmd0O25vZGUxLXB1dCZsdDsvaWQmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7L21h cHBpbmctbm9kZSZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZsdDsvbWFwcGluZy1ub2RlcyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZs dDsvY29uZmlnJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDsmbmJzcDsmbmJzcDsgJmx0Oy9lZGl0LWNvbmZpZyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkFuZCB0aGUgcXVlc3Rpb24gaGVyZSBpczogV2hldGhlciB0aGUgZWRpdCBzaG91bGQg ZmFpbCBvciBub3QgPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUg cHJvYmxlbSBpcyB0aGF0IG1hcHBpbmctbm9kZXMgY29udGFpbmVyIGRvZXMgbm90IGV4aXN0IGFu ZCBpbiBlZGl0LWNvbmZpZyBycGMsIHRoZXJl4oCZcyDigJxub25l4oCdIG9wZXJhdGlvbiBhc3Nv Y2lhdGVkIHRvIGl0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PdXIg Zmlyc3QgYXNzdW1wdGlvbiB3YXMgdGhhdCB0aGUgcmVzdWx0aW5nIGRhdGEgc3RydWN0dXJlIHNo b3VsZCBiZSBpbnZhbGlkIGR1ZSB0byBtaXNzaW5nIHJvb3QgY29udGFpbmVyIGFuZCBycGMgc2hv dWxkIGZhaWwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhvd2V2ZXIs IHRoZSBjb250YWluZXIgaXMgbm9uLXByZXNlbmNlIChleGlzdHMgb25seSBmb3Igb3JnYW5pemlu ZyB0aGUgaGllcmFyY2h5IG9mIGRhdGEgbm9kZXMpLCB3aGljaCBtZWFucyB0aGF0IGl0IG1heSBi ZSBjcmVhdGVkL2RlbGV0ZWQgYXMgY2hpbGQgbm9kZXMgYXBwZWFyL2Rpc2FwcGVhci48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW4gd2hpY2ggY2FzZSwgdGhlIG9wZXJh dGlvbiBkb2VzbuKAmXQgaGF2ZSB0byBmYWlsIGFuZCBjYW4gY3JlYXRlIG1hcHBpbmctbm9kZXMg Y29udGFpbmVyIGV2ZW4gaWYg4oCcbm9uZeKAnSBvcGVyYXRpb24gaXMgYXNzb2NpYXRlZCB3aXRo IGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGVkaXQgc2hvdWxkIGZhaWwuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5FVENPTkYgaGFz IG5vIHJlcXVpcmVtZW50IHRoYXQgb3BlcmF0aW9uPW5vbmUgd2lsbCBjcmVhdGUgbWlzc2luZyBO UC1jb250YWluZXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBjYW4gb25seSBmaW5kIHRleHQgdGhhdCBzYXlzIG9wZXJhdGlvbj1ub25lIG1l YW5zIHRoZSBzZXJ2ZXIgd2lsbCBub3QgYWx0ZXIgdGhlc2Ugbm9kZXMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TWFyb3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpOZXRjb25m IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpOZXRjb25mQGlldGYub3JnIj5OZXRj b25mQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0Y29uZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_50000fdde017413f93a87fd7f4d6f30eXCHALN018ciscocom_-- From nobody Thu Mar 3 18:02:12 2016 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 158471A0366 for ; Thu, 3 Mar 2016 18:02:10 -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 H-C3evY65C49 for ; Thu, 3 Mar 2016 18:02:08 -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 510191A0191 for ; Thu, 3 Mar 2016 18:02:07 -0800 (PST) Received: by mail-lb0-x233.google.com with SMTP id x1so45080983lbj.3 for ; Thu, 03 Mar 2016 18:02:07 -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; bh=G2ECqykjtDOvGIFeQgEPC/5cjfJYl2sUEeARoTu2c54=; b=LZkxHMV/NoMcUvny39GSvsxVf4ilWyj6WTxCwWHHXoMFVHNWtWYwBG4dp0FHKB941j 1CUC2+nnCxldpFDakHCXiR56QUK/2KbQm3yNtG3LTmaRdUQISJTqPHiv/IVdXg5BBtvy swrxvdVza43Nd3PXeEncky0dzxlIaUAiwEyoZalbCr/SpDIskhuZz3MmuAZJonE9FBeR ETb4O0Jj3iaDyL2j31DITbEGmyJqbYrJ9YZ15dsUtF8T3eN3IBc85cbfju5vjfUlmX9z pOqP71sHcyRKU8zVA+4HYAgiYy+QkouTv84uoK4YgSLJXyKWJ9NCrXdBuXD8oHDrszQf WenA== 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; bh=G2ECqykjtDOvGIFeQgEPC/5cjfJYl2sUEeARoTu2c54=; b=Q+rs4gEkcix2jW8NVWATdsY87b1YZm8DizFs0BkyfVTgNGfCiikqcN1E+V1OiuJtZF ukahHIxU3srAB5Zzfb4sovM4eKHprRelmM0Ufx3fFU/O8PYuLYSxP9ZEiQWOQKRQuTQd niexddp9RlMSCzC5J2XRRSBHhOmEkZymz17rCjQhOVJovdZ+qdwUjG0b4s06LhXeIkEW U8qhReEEtGGGsQEPPLAi50n7rE79baEKqzhN1TRCxwE2Srsxd2cbw7dIpvu6zHGaj+VR p2F8K3K6WHKGFHwdU4xcXqnoPiymPh3AXQqwa4KkfFr7yZVW+GcIRcMeY5IvHf9/tAVr byfw== X-Gm-Message-State: AD7BkJJHLB9bznSzG2jxIyKCGESoS0sXlW7NWO4e1aw7KweT2rW6Zlk/81Dw6sZTShJNIbyQf2z2PoZuLfafug== MIME-Version: 1.0 X-Received: by 10.25.149.68 with SMTP id x65mr2209707lfd.138.1457056925536; Thu, 03 Mar 2016 18:02:05 -0800 (PST) Received: by 10.112.110.68 with HTTP; Thu, 3 Mar 2016 18:02:05 -0800 (PST) In-Reply-To: <50000fdde017413f93a87fd7f4d6f30e@XCH-ALN-018.cisco.com> References: <31c6e4048a9f40438f17e2902cd5874d@XCH-ALN-018.cisco.com> <50000fdde017413f93a87fd7f4d6f30e@XCH-ALN-018.cisco.com> Date: Thu, 3 Mar 2016 18:02:05 -0800 Message-ID: From: Andy Bierman To: "Maros Marsalek -X (mmarsale - PANTHEON TECHNOLOGIES at Cisco)" Content-Type: multipart/alternative; boundary=001a1140388276f334052d2f801a Archived-At: Cc: "Tony Tkacik -X \(ttkacik - PANTHEON TECHNOLOGIES at Cisco\)" , "netconf@ietf.org" Subject: Re: [Netconf] Netconf, none operation and non-presence containers 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, 04 Mar 2016 02:02:10 -0000 --001a1140388276f334052d2f801a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 3, 2016 at 7:13 AM, Maros Marsalek -X (mmarsale - PANTHEON TECHNOLOGIES at Cisco) wrote: > Hey Andy, > > > > This note at https://tools.ietf.org/html/rfc6020#section-7.5.8 is > interesting: > > > > =E2=80=9CIf a container does not have a "presence" statement and the last > > child node is deleted, the NETCONF server MAY delete the container.=E2= =80=9D > > > > Meaning that the NETCONF server may control lifecycle of non-presence > containers (in terms of delete at least). > > > > But on the other hand, NETCONF RFC > http://tools.ietf.org/html/rfc6241#section-7.2 is saying: > > > > =E2=80=9CIf the configuration in the parameter contains data for= which > there is not a > > corresponding level in the target datastore, an i= s > returned=E2=80=A6=E2=80=9D > > > > With this combination we might end up in a situation where server deletes > an empty, non-presence, parent container at one point and user tries to > create one of its child nodes with =E2=80=9Cnone=E2=80=9D operation assig= ned to the parent, > non-presence container. Request would fail because the non-presence > container was deleted silently in the background, but the user has no way > of knowing. Meaning that the behavior for non-presence containers might b= e > asymmetric and confusing in terms of auto create/delete. That=E2=80=99s w= hy we > think NETCONF server should be able to auto-create non-presence container= s > even with =E2=80=9Cnone=E2=80=9D operation assigned to it, however the sp= ecs are not clear > in this case. > > > I never said the server cannot add data nodes to a datastore. The server is not required to do that, meaning the client cannot count on it. YANG 1.1 fixes the XPath inconsistencies. I suggest using "merge" instead of "create". > Regards, > > Maros > Andy > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Tuesday, March 01, 2016 5:29 PM > *To:* Maros Marsalek -X (mmarsale - PANTHEON TECHNOLOGIES at Cisco) < > mmarsale@cisco.com> > *Cc:* netconf@ietf.org; Tony Tkacik -X (ttkacik - PANTHEON TECHNOLOGIES > at Cisco) > *Subject:* Re: [Netconf] Netconf, none operation and non-presence > containers > > > > > > > > On Tue, Mar 1, 2016 at 7:33 AM, Maros Marsalek -X (mmarsale - PANTHEON > TECHNOLOGIES at Cisco) wrote: > > Hello netconf group, > > > > We=E2=80=99ve run into following situation with NETCONF and we would like= to know > your opinion on what=E2=80=99s the correct behavior here: > > > > Model (root non-presence container with nested list) : > > > > container mapping-nodes { > > list mapping-node{ > > key "id"; > > leaf id { > > type string; > > } > > } > > } > > > > Netconf edit-config RPC (replacing mapping-node entry with none operation > for mapping-nodes container, in an empty data store): > > > > > > =E2=80=A6 > > none > > > > > > xmlns:a=3D"urn:ietf:params:xml:ns:netconf:base:1.0" a:operation=3D"replac= e"> > > node1-put > > > > > > > > > > > > And the question here is: Whether the edit should fail or not ? > > The problem is that mapping-nodes container does not exist and in > edit-config rpc, there=E2=80=99s =E2=80=9Cnone=E2=80=9D operation associa= ted to it. > > Our first assumption was that the resulting data structure should be > invalid due to missing root container and rpc should fail. > > However, the container is non-presence (exists only for organizing the > hierarchy of data nodes), which means that it may be created/deleted as > child nodes appear/disappear. > > In which case, the operation doesn=E2=80=99t have to fail and can create > mapping-nodes container even if =E2=80=9Cnone=E2=80=9D operation is assoc= iated with it. > > > > > > The edit should fail. > > > > NETCONF has no requirement that operation=3Dnone will create missing > NP-containers. > > I can only find text that says operation=3Dnone means the server will not > alter these nodes. > > > > > > > > Regards, > > Maros > > > > > > Andy > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > --001a1140388276f334052d2f801a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 3, 2016 at 7:13 AM, Maros Marsalek -X (mmarsale - PANTHEON = TECHNOLOGIES at Cisco) <mmarsale@cisco.com> wrote:

Hey Andy,

=C2=A0

This note at https://tools.ietf.org/html/rfc6020#section-7.5.8 is interesting:<= u>

=C2=A0

=E2=80=9CIf a container does not have= a "presence" statement and the last

=C2=A0=C2=A0 child node is deleted, t= he NETCONF server MAY delete the container.=E2=80=9D

=C2=A0

Meaning that the NETCONF server may c= ontrol lifecycle of non-presence containers (in terms of delete at least).

=C2=A0

But on the other hand, NETCONF RFC http://tools.ietf.org/html/rfc6241#section-7.2 is saying:

=C2=A0

=E2=80=9CIf the configuration in the = <config> parameter contains data for which there is not a

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 corresponding level in the target datastore,= an <rpc-error> is returned=E2=80=A6=E2=80=9D

=C2=A0

With this combination we might end up= in a situation where server deletes an empty, non-presence, parent contain= er at one point and user tries to create one of its child nodes with =E2=80=9Cnone=E2=80=9D operation assigned to the pare= nt, non-presence container. Request would fail because the non-presence con= tainer was deleted silently in the background, but the user has no way of k= nowing. Meaning that the behavior for non-presence containers might be asymmetric and confusing in terms of auto create/delet= e. That=E2=80=99s why we think NETCONF server should be able to auto-create= non-presence containers even with =E2=80=9Cnone=E2=80=9D operation assigne= d to it, however the specs are not clear in this case.=

=C2=A0

<= /blockquote>


I never said the server cann= ot add data nodes to a datastore.
The server is not required to d= o that, meaning the client cannot count on it.

YAN= G 1.1 fixes the XPath inconsistencies.=C2=A0 I suggest using "merge&qu= ot;
instead of "create".=C2=A0

=C2=A0

Regards,

Maros



Andy
=C2=A0

=C2=A0

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Tuesday, March 01, 2016 5:29 PM
To: Maros Marsalek -X (mmarsale - PANTHEON TECHNOLOGIES at Cisco) &l= t;mmarsale@cisco.co= m>
Cc: netconf@ie= tf.org; Tony Tkacik -X (ttkacik - PANTHEON TECHNOLOGIES at Cisco) <<= a href=3D"mailto:ttkacik@cisco.com" target=3D"_blank">ttkacik@cisco.com= >
Subject: Re: [Netconf] Netconf, none operation and non-presence cont= ainers

=C2=A0

=C2=A0

=C2=A0

On Tue, Mar 1, 2016 at 7:33 AM, Maros Marsalek -X (m= marsale - PANTHEON TECHNOLOGIES at Cisco) <mmarsale@cisco.com> wrote:<= /p>

Hello netconf group,

=C2=A0

We=E2=80=99ve run into following situation with NETC= ONF and we would like to know your opinion on what=E2=80=99s the correct be= havior here:

=C2=A0

Model (root non-presence container with nested list)= :

=C2=A0

container mapping-nodes {

=C2=A0=C2=A0=C2=A0 list mapping-node{<= /p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 key "= ;id";

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf id {=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 type string;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<= u>

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

}

=C2=A0

Netconf edit-config RPC (replacing mapping-node entr= y with none operation for mapping-nodes container, in an empty data store):=

=C2=A0

=C2=A0=C2=A0=C2=A0 <edit-config>=

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

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <defau= lt-operation>none</default-operation>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <confi= g>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 <mapping-nodes xmlns=3D"urn:opendaylight:mdsal:mapp= ing:test">

=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 <mapping-node xmlns:a=3D"ur= n:ietf:params:xml:ns:netconf:base:1.0" a:operation=3D"replace&quo= t;>

=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 <id>n= ode1-put</id>

=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</mapping-node>=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 </mapping-nodes>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </conf= ig>

=C2=A0=C2=A0=C2=A0 </edit-config>

=C2=A0

And the question here is: Whether the edit should fa= il or not ?

The problem is that mapping-nodes container does not= exist and in edit-config rpc, there=E2=80=99s =E2=80=9Cnone=E2=80=9D opera= tion associated to it.

Our first assumption was that the resulting data str= ucture should be invalid due to missing root container and rpc should fail.=

However, the container is non-presence (exists only = for organizing the hierarchy of data nodes), which means that it may be cre= ated/deleted as child nodes appear/disappear.

In which case, the operation doesn=E2=80=99t have to= fail and can create mapping-nodes container even if =E2=80=9Cnone=E2=80=9D= operation is associated with it.

=C2=A0

=C2=A0

The edit should fail.

=C2=A0

NETCONF has no requirement that operation=3Dnone wil= l create missing NP-containers.

I can only find text that says operation=3Dnone mean= s the server will not alter these nodes.

=C2=A0

=C2=A0

=C2=A0

Regards,

Maros

=C2=A0

=C2=A0

Andy

=C2=A0

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

=C2=A0


--001a1140388276f334052d2f801a-- From nobody Thu Mar 3 18:17:52 2016 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 913461B2DC3 for ; Thu, 3 Mar 2016 18:17:51 -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 VvvNpKw9UG3h for ; Thu, 3 Mar 2016 18:17:49 -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 2FE2F1B2D5D for ; Thu, 3 Mar 2016 18:17:49 -0800 (PST) Received: by mail-lb0-x232.google.com with SMTP id x1so45373875lbj.3 for ; Thu, 03 Mar 2016 18:17:49 -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; bh=3OHj+bUjsiAHZRAyhGW90YPewYNBhBvNxW5b99V7KqY=; b=k3HCjH5zj2gz5eA1M1SwULKFt0ngb9El2svzUNuzdZnuk6i8rbxmWStB11Z0sDIJHg F+FhB78qjJRF++Lkm17q3EkkbGY2LY71j4X3MErsjBBYPpYgtJr8YMpcQy8v5VgVz/Yl gwKsCCDoyNurOQ02nTDH1nXAe9DpPfoozzbvoIhJfSgOBCrcri5VH2BF+pvV0QnaplS5 S6zL/5dz6qiIXL81z7Q9v2ujlOxCenzRxCTgdCStqBQ+vQA6JpOcFRN6n9FbATBoliso /+RbK4AGbKqSVcYAQzS2U9KrqbY84ymqIDp7Thk7zhHPb9jjTlS9mVHyzrp1+GKZFiPw cgbQ== 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; bh=3OHj+bUjsiAHZRAyhGW90YPewYNBhBvNxW5b99V7KqY=; b=mle0iHQZoEybxNqI2amVEp2qzJ50UxK6FuGE/epzK0fCpKyR36hCIEYkgSTu4VkfLz pgjuL7EPAA4g0butiCXaYAz6JfULnRlw/9S/1p6HyPzk22GMPBYtdeTRUPYfPVK2Likt rGdn5ybF8ANy+wC44PFhkk8MfvEI2vOI3hPE3FP0auLouXbECR42eI4M/r8REvGXfheK msWcE84qwCMAkSCapOsN9yahizM+A8gBlgECjFKoa1oQYO+sh03Y9CDZwOaHBPhwOvIJ WwlPx00m1XaLbpk8tMAWHFhEKLmfWVThxCCoVyb+P02WLOvpqJvyjS52aLc5UnNl0H9O /Ubg== X-Gm-Message-State: AD7BkJLKe3LyqmLBk3FZw+TbhZrZ4Ec985dFjJOYdGpNnZPVV06V/CZ4YBq+IASxDfrejP6yw8scqsr5/g4QpQ== MIME-Version: 1.0 X-Received: by 10.25.39.146 with SMTP id n140mr2143154lfn.23.1457057867454; Thu, 03 Mar 2016 18:17:47 -0800 (PST) Received: by 10.112.110.68 with HTTP; Thu, 3 Mar 2016 18:17:47 -0800 (PST) In-Reply-To: <03529de044bc4ebe8dcdc950b494c59b@XCH-ALN-013.cisco.com> References: <00a701d17179$f46e35e0$4001a8c0@gateway.2wire.net> <03529de044bc4ebe8dcdc950b494c59b@XCH-ALN-013.cisco.com> Date: Thu, 3 Mar 2016 18:17:47 -0800 Message-ID: From: Andy Bierman To: "Eric Voit (evoit)" Content-Type: multipart/alternative; boundary=001a114111a49b70a2052d2fb8d5 Archived-At: Cc: NETCONF Subject: Re: [Netconf] One or three drafts? 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, 04 Mar 2016 02:17:51 -0000 --001a114111a49b70a2052d2fb8d5 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 1, 2016 at 8:55 AM, Eric Voit (evoit) wrote: > Hi Tom, > > In the end, the number of drafts is not a huge issue for us. To date, we > have segmented drafts so as to: > > (a) Maximize transport independence. > > (b) Reduce technology options within any one draft. (We don't want things > overly complex so that operators can't easily refer to desired subset.) > > (c) Maximize alignment with any in-flight RFC5277bis spec > > At the next IETF, we would be happy to make a proposal for functionality > segmentation across the following elements: > > Subscription Configuration > - Static (& Multiple Receivers) > - Dynamic (& Parameter Negotiation) > - Subscription QoS & Prioritized Push > - Filter (RFC6241, RFC5277, other) > If you mean each of these sub-topics is part of 1 RFC then OK. IMO YANG features should make these all optional. > Transport (Netconf, Restconf, HTTP2, other?) > I agree Transport should be a separate RFC. Will there be a mandatory-to-implement transport? (IMO, no) other? might be RESTCONF over CoAP, or perhaps using NETCONF like SNMP (with configured listeners) and sending notifications in XML over DTLS/UDP. RFC5277bis (new and/or augmented RPCs) > > Agree it is time to update this RFC NETCONF notifications are deployed and being used, so I hope the update will not disturb any running code. This is easily done by defining new RPCs and even new standard streams. There is little point in updating this RFC unless all deficiencies and new features can be considered by the WG. > Based on whatever discussion follows, we will take WG guidance on > appropriate draft segmentation. > > Eric > Andy > > > -----Original Message----- > > From: Netconf, February 27, 2016 11:14 AM > > > > ---- Original Message ----- > > From: "Mahesh Jethanandani" > > To: "NETCONF" > > Sent: Saturday, February 27, 2016 1:21 AM > > > > > I am following up on the discussion in IETF 94 on the question of > > whether we need one or three drafts for YANG push. One draft would mean a > > merge of NETCONF and RESTCONF YANG push draft, while three drafts would > > be a common draft, the second one for NETCONF specific part and the > third for > > the RESTCONF specific part. There was no preference for just two drafts > - one > > for NETCONF and one for RESTCONF with common parts either duplicated or > > referenced. The vote in the room seemed to indicate a tie for 1 or 3 > drafts with > > no apparent winner. > > > > > > The authors indicated a preference to keep them as separate drafts, > > but others in the room seemed to indicate that other drafts, like call > home and > > zero touch are doing it as a single draft. > > > > > > Can we have a discussion of whether folks would prefer to read and > > follow YANG push as three separate drafts or would they prefer to see > them > > merged? > > > > I don't know, can we have a discussion:-) > > > > Well, assuming we can, I am for a merge into one I-D. > > > > Tom Petch > > > > > Thanks. > > > > > > Mahesh & Mehmet. > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a114111a49b70a2052d2fb8d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 1, 2016 at 8:55 AM, Eric Voit (evoit) <= ;evoit@cisco.com&g= t; wrote:
Hi Tom,

In the end, the number of drafts is not a huge issue for us.=C2=A0 To date,= we have segmented drafts so as to:

(a) Maximize transport independence.

(b) Reduce technology options within any one draft.=C2=A0 (We don't wan= t things overly complex so that operators can't easily refer to desired= =C2=A0 subset.)

(c) Maximize alignment with any in-flight RFC5277bis spec

At the next IETF, we would be happy to make a proposal for functionality se= gmentation across the following elements:

Subscription Configuration
=C2=A0- Static=C2=A0 (& Multiple Receivers)
=C2=A0- Dynamic (& Parameter Negotiation)
=C2=A0- Subscription QoS & Prioritized Push
=C2=A0- Filter (RFC6241, RFC5277, other)

If you mean each of these sub-topics is part of 1 RFC then OK.
= IMO YANG features should make these all optional.

= =C2=A0
Transport (Netconf, Restconf, HTTP2, other?)

I agree Transport should be a separate RFC.
Will there be a= mandatory-to-implement transport?
(IMO, no)

=
other? might be RESTCONF over CoAP,
or perhaps using NETCONF= like SNMP (with configured
listeners) and sending notifications = in XML over DTLS/UDP.


RFC5277bis (new and/or augmented RPCs)


Agree it is time to update this RFC

NETCONF notifications are deployed and being used, s= o I hope
the update will not disturb any running code. This is ea= sily done
by defining new RPCs and even new standard streams.

There is little point in updating this RFC unless all= deficiencies and new
features can be considered by the WG.
=

=C2=A0
Based on whatever discussion follows, we will take WG guidance on appropria= te draft segmentation.

Eric


Andy

=
=C2=A0

> -----Original Message-----
> From: Netconf, February 27, 2016 11:14 AM
>
> ---- Original Message -----
> From: "Mahesh Jethanandani" <mjethanandani@gmail.com>
> To: "NETCONF" <netcon= f@ietf.org>
> Sent: Saturday, February 27, 2016 1:21 AM
>
> > I am following up on the discussion in IETF 94 on the question of=
> whether we need one or three drafts for YANG push. One draft would mea= n a
> merge of NETCONF and RESTCONF YANG push draft, while three drafts woul= d
> be a common draft, the second one for NETCONF specific part and the th= ird for
> the RESTCONF specific part. There was no preference for just two draft= s - one
> for NETCONF and one for RESTCONF with common parts either duplicated o= r
> referenced. The vote in the room seemed to indicate a tie for 1 or 3 d= rafts with
> no apparent winner.
> >
> > The authors indicated a preference to keep them as separate draft= s,
> but others in the room seemed to indicate that other drafts, like call= home and
> zero touch are doing it as a single draft.
> >
> > Can we have a discussion of whether folks would prefer to read an= d
> follow YANG push as three separate drafts or would they prefer to see = them
> merged?
>
> I don't know, can we have a discussion:-)
>
> Well, assuming we can, I am for a merge into one I-D.
>
> Tom Petch
>
> > Thanks.
> >
> > Mahesh & Mehmet.
> >
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf<= br>
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--001a114111a49b70a2052d2fb8d5-- From nobody Thu Mar 3 18:45:54 2016 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 D6D911A884E for ; Thu, 3 Mar 2016 18:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 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, J_CHICKENPOX_15=0.6, 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 nSnPvQ49qP6X for ; Thu, 3 Mar 2016 18:45:51 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::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 0D6C01B2A99 for ; Thu, 3 Mar 2016 18:45:51 -0800 (PST) Received: by mail-lb0-x22e.google.com with SMTP id bc4so45854643lbc.2 for ; Thu, 03 Mar 2016 18:45:50 -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; bh=NN8AhMQJOuui6LNnlD8IDaJPoDk1vhIBXdQlXfR+wYY=; b=ag7z3P92VXwlQbU3IQVOIkEmT5clZMlmd195I9VmKaKljHPubRS1F5NOi8bjk2iXbP njobKo4naG1yJtTW9TEtvoiq9+SKGbjg89Qt/DspI90rZ8a9gYqr08eJOz+N9PDTUhUm yfn34cNXAGEu6RT1hiYu9DSWl1s6jbLjvBWUKU2hgkjHGq3jQNPSEQ4hgmS8yAWw0c+q 2qFocUhemrznO4cJw5MhBpivadUkXxCiN6wnSo9hy43nkdfM2hCZ2L6YO4Nb1vVfPTO0 pNU654u0D9Z1N2z+jeyVmOoed+GGKiq50iZX3mcSny6dt0MtojhQfYVHfPiH0e3e58QJ +Iwg== 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; bh=NN8AhMQJOuui6LNnlD8IDaJPoDk1vhIBXdQlXfR+wYY=; b=SdQScQmfU96U08JGSZLapn+tdf7ozVFE73OA/+fqShMwXAERafvcYJulWMX1NBns3u YNb4cw3D5rCF+cNPcBDPYlZKd2AV8pRhh1FVNiMdgFHhuChnQc9kLjhP/PNqL2tUBtAV vpzxH1oaUAYdm2bGPHQocPw2qVcWpVWQHavSfMONJhNV1hr3Az5ruZ5LGJY7mA5uP1Fq pYo4+SIiVs7txsxwUteMJCSbI8XgYSS5BP9TytMgtl+eY25orDE8q+hyb1sBwOwpCEDw mgoPluvCVt+Gcg0B+IS3ysElFPvMIUypfahO7DQTJbG3DVjnw7X3xw77ycD8OoXBomjw WPFQ== X-Gm-Message-State: AD7BkJI6sE2zU22PPasiqPa6g8rfx0QlHQ2oohFPQJM6PNFBu6ch+V5Kn4oQLlPD+S6gFV/kveqXpjNiOe416w== MIME-Version: 1.0 X-Received: by 10.25.85.145 with SMTP id j139mr2246716lfb.131.1457059549229; Thu, 03 Mar 2016 18:45:49 -0800 (PST) Received: by 10.112.110.68 with HTTP; Thu, 3 Mar 2016 18:45:48 -0800 (PST) In-Reply-To: <01ec01d173a0$a4b768e0$4001a8c0@gateway.2wire.net> References: <4A95BA014132FF49AE685FAB4B9F17F657DE8236@dfweml701-chm> <01ec01d173a0$a4b768e0$4001a8c0@gateway.2wire.net> Date: Thu, 3 Mar 2016 18:45:48 -0800 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=001a11405936d94e13052d301cdc Archived-At: Cc: Netconf Subject: Re: [Netconf] netconf-restconf Action 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, 04 Mar 2016 02:45:53 -0000 --001a11405936d94e13052d301cdc Content-Type: text/plain; charset=UTF-8 On Tue, Mar 1, 2016 at 1:56 AM, t.petch wrote: > I would like to know what an action looks like in restconf and JSON. > What would be the equivalent of, from rfc6020bis, > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > apache-1 > > 2014-07-29T13:42:00Z > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > 2014-07-29T13:42:12Z > > > > I put examples in the next RESTCONF draft for XML and JSON. I am assuming the module-name is server-farm. POST /restconf/data/server-farm:server=apache-1/reset HTTP/1.1 Host: example.com Content-Type: application/yang.action+json { "server-farm:reset" : { "reset-at" : "2014-07-29T13:42:00Z" } } HTTP/1.1 200 OK Date: Mon, 25 Apr 2012 11:10:30 GMT Server: example-server Content-Type: application/yang.action+json { "server-farm:reset" : { "reset-finished-at" : "2014-07-29T13:42:12Z" } } Tom Petch > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11405936d94e13052d301cdc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 1, 2016 at 1:56 AM, t.petch <ietfc@btconnect.com&g= t; wrote:
I would like to know what an action lo= oks like in restconf and JSON.
What would be the equivalent of, from rfc6020bis,

=C2=A0 =C2=A0 =C2=A0<rpc message-id=3D"101"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:ietf:params:xml:ns:net= conf:base:1.0">
=C2=A0 =C2=A0 =C2=A0 =C2=A0<action xmlns=3D"urn:ietf:params:xml:ns:= yang:1">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<server xmlns=3D"http://exam= ple.net/server-farm">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>apache-1</name><= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<reset>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<reset-at>2014-07-29T= 13:42:00Z</reset-at>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</reset>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</server>
=C2=A0 =C2=A0 =C2=A0 =C2=A0</action>
=C2=A0 =C2=A0 =C2=A0</rpc>

=C2=A0 =C2=A0 =C2=A0<rpc-reply message-id=3D"101"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:i= etf:params:xml:ns:netconf:base:1.0">
=C2=A0 =C2=A0 =C2=A0 =C2=A0<reset-finished-at xmlns=3D"http://= example.net/server-farm">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02014-07-29T13:42:12Z
=C2=A0 =C2=A0 =C2=A0 =C2=A0</reset-finished-at>
=C2=A0 =C2=A0 =C2=A0</rpc-reply>



I put examples in the n= ext RESTCONF draft for XML and JSON.

I am assuming= the module-name is server-farm.




=C2=A0 =C2=A0POST /restconf= /data/server-farm:server=3Dapache-1/reset HTTP/1.1
=C2=A0 =C2=A0H= ost: example.com
=C2=A0 =C2=A0= Content-Type: application/yang.action+json

=C2=A0 = =C2=A0{ "server-farm:reset" : {
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 "reset-at" : "2014-07-29T13:42:00Z"
= =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0}



=C2=A0 =C2=A0HTTP/1.1 200 OK
=C2=A0 =C2=A0Date: Mon, 25 Apr 2012 11:10:30 GMT
=C2=A0 =C2=A0S= erver: example-server
=C2=A0 =C2=A0Content-Type: application/yang= .action+json

=C2=A0 =C2=A0{
=C2=A0 =C2= =A0 =C2=A0 "server-farm:reset" : {
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0"reset-finished-at" : "2014-07-29T13:42:12Z&qu= ot;
=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0}



Tom Petch


Andy
=C2=A0

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

--001a11405936d94e13052d301cdc-- From nobody Fri Mar 4 04:53:02 2016 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 57E321B37E6 for ; Fri, 4 Mar 2016 04:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNR0mdtc52QE for ; Fri, 4 Mar 2016 04:52:58 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 341AA1B36A2 for ; Fri, 4 Mar 2016 04:52:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20624; q=dns/txt; s=iport; t=1457095978; x=1458305578; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3LmrYfaXCFt76qFUaoSk+eAE5GrG4dEr5lciPSMcTPQ=; b=V1ZS0V7pN7QReUplSJNFTtm2BOa3eYHMYD5wvDzaEWPHfT0u0uFkCzGU SSoV0gdcm+aQfyOL+mQfWh0oi4ZGAYT3Sc+Adjq1RYHZKzDLu2d7Rofcf kJXTawjcHeGRI8RXUxLtulcRH+teTkpgJ/uMmMjHrIVjbuthg5pDhcSqn U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQCGhNlW/4YNJK1dgm5MUm0GujIBD?= =?us-ascii?q?YFpFwEJhSRKAhyBFjgUAQEBAQEBAWQnhEEBAQEEAQEBIApBCwwEAgEIFQEPGgM?= =?us-ascii?q?CAgIfBgsUEQIEDgUIiAUDEg6uIYo8DYQ0AQEBAQEBAQEBAQEBAQEBAQEBAQEBE?= =?us-ascii?q?QSGF4Q8gjyCAwcJFwmCSoE6BZchAYtygW6BaYdphS6Fd4ETh0cBHgEBQoNkaog?= =?us-ascii?q?kfgEBAQ?= X-IronPort-AV: E=Sophos; i="5.22,535,1449532800"; d="scan'208,217"; a="83028005" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Mar 2016 12:52:57 +0000 Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u24Cqvta032214 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Mar 2016 12:52:57 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 4 Mar 2016 06:52:56 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.009; Fri, 4 Mar 2016 06:52:56 -0600 From: "Eric Voit (evoit)" To: Andy Bierman Thread-Topic: [Netconf] One or three drafts? Thread-Index: AQHRcXqMvpVS9r8sUESYF00ZpTigLZ9DMfWAgAXHwYCAAEr6IA== Date: Fri, 4 Mar 2016 12:52:56 +0000 Message-ID: <2a7ad5befaaf45e8855a7e5ef5a2c353@XCH-ALN-013.cisco.com> References: <00a701d17179$f46e35e0$4001a8c0@gateway.2wire.net> <03529de044bc4ebe8dcdc950b494c59b@XCH-ALN-013.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.235] Content-Type: multipart/alternative; boundary="_000_2a7ad5befaaf45e8855a7e5ef5a2c353XCHALN013ciscocom_" MIME-Version: 1.0 Archived-At: Cc: NETCONF Subject: Re: [Netconf] One or three drafts? 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, 04 Mar 2016 12:53:00 -0000 --_000_2a7ad5befaaf45e8855a7e5ef5a2c353XCHALN013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogQW5keSBCaWVybWFuLCBNYXJjaCAwMywgMjAxNiA5OjE4IFBNDQoNCk9uIFR1ZSwgTWFy IDEsIDIwMTYgYXQgODo1NSBBTSwgRXJpYyBWb2l0IChldm9pdCkgPGV2b2l0QGNpc2NvLmNvbTxt YWlsdG86ZXZvaXRAY2lzY28uY29tPj4gd3JvdGU6DQpIaSBUb20sDQoNCkluIHRoZSBlbmQsIHRo ZSBudW1iZXIgb2YgZHJhZnRzIGlzIG5vdCBhIGh1Z2UgaXNzdWUgZm9yIHVzLiAgVG8gZGF0ZSwg d2UgaGF2ZSBzZWdtZW50ZWQgZHJhZnRzIHNvIGFzIHRvOg0KDQooYSkgTWF4aW1pemUgdHJhbnNw b3J0IGluZGVwZW5kZW5jZS4NCg0KKGIpIFJlZHVjZSB0ZWNobm9sb2d5IG9wdGlvbnMgd2l0aGlu IGFueSBvbmUgZHJhZnQuICAoV2UgZG9uJ3Qgd2FudCB0aGluZ3Mgb3Zlcmx5IGNvbXBsZXggc28g dGhhdCBvcGVyYXRvcnMgY2FuJ3QgZWFzaWx5IHJlZmVyIHRvIGRlc2lyZWQgIHN1YnNldC4pDQoN CihjKSBNYXhpbWl6ZSBhbGlnbm1lbnQgd2l0aCBhbnkgaW4tZmxpZ2h0IFJGQzUyNzdiaXMgc3Bl Yw0KDQpBdCB0aGUgbmV4dCBJRVRGLCB3ZSB3b3VsZCBiZSBoYXBweSB0byBtYWtlIGEgcHJvcG9z YWwgZm9yIGZ1bmN0aW9uYWxpdHkgc2VnbWVudGF0aW9uIGFjcm9zcyB0aGUgZm9sbG93aW5nIGVs ZW1lbnRzOg0KDQpTdWJzY3JpcHRpb24gQ29uZmlndXJhdGlvbg0KIC0gU3RhdGljICAoJiBNdWx0 aXBsZSBSZWNlaXZlcnMpDQogLSBEeW5hbWljICgmIFBhcmFtZXRlciBOZWdvdGlhdGlvbikNCiAt IFN1YnNjcmlwdGlvbiBRb1MgJiBQcmlvcml0aXplZCBQdXNoDQogLSBGaWx0ZXIgKFJGQzYyNDEs IFJGQzUyNzcsIG90aGVyKQ0KDQpJZiB5b3UgbWVhbiBlYWNoIG9mIHRoZXNlIHN1Yi10b3BpY3Mg aXMgcGFydCBvZiAxIFJGQyB0aGVuIE9LLg0KSU1PIFlBTkcgZmVhdHVyZXMgc2hvdWxkIG1ha2Ug dGhlc2UgYWxsIG9wdGlvbmFsLg0KDQo8RXJpYz4gWWVzLCB0aGlzIGlzIHdoYXQgd2Ugd2VyZSB0 aGlua2luZy4NCg0KDQpUcmFuc3BvcnQgKE5ldGNvbmYsIFJlc3Rjb25mLCBIVFRQMiwgb3RoZXI/ KQ0KDQpJIGFncmVlIFRyYW5zcG9ydCBzaG91bGQgYmUgYSBzZXBhcmF0ZSBSRkMuDQpXaWxsIHRo ZXJlIGJlIGEgbWFuZGF0b3J5LXRvLWltcGxlbWVudCB0cmFuc3BvcnQ/DQooSU1PLCBubykNCg0K PEVyaWM+IFllcywgdGhpcyB3b3VsZCBiZSBvdXIgcHJlZmVyZW5jZSBhcyB3ZWxsLg0KDQpvdGhl cj8gbWlnaHQgYmUgUkVTVENPTkYgb3ZlciBDb0FQLA0Kb3IgcGVyaGFwcyB1c2luZyBORVRDT05G IGxpa2UgU05NUCAod2l0aCBjb25maWd1cmVkDQpsaXN0ZW5lcnMpIGFuZCBzZW5kaW5nIG5vdGlm aWNhdGlvbnMgaW4gWE1MIG92ZXIgRFRMUy9VRFAuDQoNCjxFcmljPiBPbiDigJhvdGhlcuKAmSwg d2Ugd2VyZSB0aGlua2luZyBhYm91dCBJUEZJWCBhcyBhbiBleGFtcGxlIGFzIHdlbGwgYXQgc29t ZSBwb2ludC4gICBOZXcgZHJhZnRzIGNvdWxkIGNvbWUgZm9yIG5ldyBvcHRpb25zLg0KDQoNClJG QzUyNzdiaXMgKG5ldyBhbmQvb3IgYXVnbWVudGVkIFJQQ3MpDQoNCkFncmVlIGl0IGlzIHRpbWUg dG8gdXBkYXRlIHRoaXMgUkZDDQoNCk5FVENPTkYgbm90aWZpY2F0aW9ucyBhcmUgZGVwbG95ZWQg YW5kIGJlaW5nIHVzZWQsIHNvIEkgaG9wZQ0KdGhlIHVwZGF0ZSB3aWxsIG5vdCBkaXN0dXJiIGFu eSBydW5uaW5nIGNvZGUuIFRoaXMgaXMgZWFzaWx5IGRvbmUNCmJ5IGRlZmluaW5nIG5ldyBSUENz IGFuZCBldmVuIG5ldyBzdGFuZGFyZCBzdHJlYW1zLg0KDQpUaGVyZSBpcyBsaXR0bGUgcG9pbnQg aW4gdXBkYXRpbmcgdGhpcyBSRkMgdW5sZXNzIGFsbCBkZWZpY2llbmNpZXMgYW5kIG5ldw0KZmVh dHVyZXMgY2FuIGJlIGNvbnNpZGVyZWQgYnkgdGhlIFdHLg0KDQo8RXJpYz4gQWdyZWUgd2l0aCBu ZXcgUlBDcyBhbmQgbmV3IHN0YW5kYXJkIHN0cmVhbXMuICAgTG9vayBmb3IgYSBzdHJhd21hbiBi ZWZvcmUgdGhlIElFVEYgY3V0LW9mZiBkYXRlLiAgV2UgYXJlIGhvcGluZyB0byBzZWUgb3RoZXIg cHJvcG9zYWxzIGFzIHdlbGwgc28gdGhhdCB3ZSBjYW4gaGF2ZSBtb3JlIGV5ZXMgb24gdGhlIHBy b2JsZW0uDQoNCkVyaWMNCg0KDQpCYXNlZCBvbiB3aGF0ZXZlciBkaXNjdXNzaW9uIGZvbGxvd3Ms IHdlIHdpbGwgdGFrZSBXRyBndWlkYW5jZSBvbiBhcHByb3ByaWF0ZSBkcmFmdCBzZWdtZW50YXRp b24uDQoNCkVyaWMNCg0KDQpBbmR5DQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IE5ldGNvbmYsIEZlYnJ1YXJ5IDI3LCAyMDE2IDExOjE0IEFNDQo+DQo+IC0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiBGcm9tOiAiTWFoZXNoIEpldGhhbmFuZGFuaSIgPG1q ZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4+DQo+ IFRvOiAiTkVUQ09ORiIgPG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+ Pg0KPiBTZW50OiBTYXR1cmRheSwgRmVicnVhcnkgMjcsIDIwMTYgMToyMSBBTQ0KPg0KPiA+IEkg YW0gZm9sbG93aW5nIHVwIG9uIHRoZSBkaXNjdXNzaW9uIGluIElFVEYgOTQgb24gdGhlIHF1ZXN0 aW9uIG9mDQo+IHdoZXRoZXIgd2UgbmVlZCBvbmUgb3IgdGhyZWUgZHJhZnRzIGZvciBZQU5HIHB1 c2guIE9uZSBkcmFmdCB3b3VsZCBtZWFuIGENCj4gbWVyZ2Ugb2YgTkVUQ09ORiBhbmQgUkVTVENP TkYgWUFORyBwdXNoIGRyYWZ0LCB3aGlsZSB0aHJlZSBkcmFmdHMgd291bGQNCj4gYmUgYSBjb21t b24gZHJhZnQsIHRoZSBzZWNvbmQgb25lIGZvciBORVRDT05GIHNwZWNpZmljIHBhcnQgYW5kIHRo ZSB0aGlyZCBmb3INCj4gdGhlIFJFU1RDT05GIHNwZWNpZmljIHBhcnQuIFRoZXJlIHdhcyBubyBw cmVmZXJlbmNlIGZvciBqdXN0IHR3byBkcmFmdHMgLSBvbmUNCj4gZm9yIE5FVENPTkYgYW5kIG9u ZSBmb3IgUkVTVENPTkYgd2l0aCBjb21tb24gcGFydHMgZWl0aGVyIGR1cGxpY2F0ZWQgb3INCj4g cmVmZXJlbmNlZC4gVGhlIHZvdGUgaW4gdGhlIHJvb20gc2VlbWVkIHRvIGluZGljYXRlIGEgdGll IGZvciAxIG9yIDMgZHJhZnRzIHdpdGgNCj4gbm8gYXBwYXJlbnQgd2lubmVyLg0KPiA+DQo+ID4g VGhlIGF1dGhvcnMgaW5kaWNhdGVkIGEgcHJlZmVyZW5jZSB0byBrZWVwIHRoZW0gYXMgc2VwYXJh dGUgZHJhZnRzLA0KPiBidXQgb3RoZXJzIGluIHRoZSByb29tIHNlZW1lZCB0byBpbmRpY2F0ZSB0 aGF0IG90aGVyIGRyYWZ0cywgbGlrZSBjYWxsIGhvbWUgYW5kDQo+IHplcm8gdG91Y2ggYXJlIGRv aW5nIGl0IGFzIGEgc2luZ2xlIGRyYWZ0Lg0KPiA+DQo+ID4gQ2FuIHdlIGhhdmUgYSBkaXNjdXNz aW9uIG9mIHdoZXRoZXIgZm9sa3Mgd291bGQgcHJlZmVyIHRvIHJlYWQgYW5kDQo+IGZvbGxvdyBZ QU5HIHB1c2ggYXMgdGhyZWUgc2VwYXJhdGUgZHJhZnRzIG9yIHdvdWxkIHRoZXkgcHJlZmVyIHRv IHNlZSB0aGVtDQo+IG1lcmdlZD8NCj4NCj4gSSBkb24ndCBrbm93LCBjYW4gd2UgaGF2ZSBhIGRp c2N1c3Npb246LSkNCj4NCj4gV2VsbCwgYXNzdW1pbmcgd2UgY2FuLCBJIGFtIGZvciBhIG1lcmdl IGludG8gb25lIEktRC4NCj4NCj4gVG9tIFBldGNoDQo+DQo+ID4gVGhhbmtzLg0KPiA+DQo+ID4g TWFoZXNoICYgTWVobWV0Lg0KPiA+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+IE5ldGNvbmZAaWV0 Zi5vcmc8bWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KTmV0Y29uZiBtYWlsaW5nIGxpc3QNCk5ldGNvbmZAaWV0Zi5vcmc8 bWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldGNvbmYNCg0K --_000_2a7ad5befaaf45e8855a7e5ef5a2c353XCHALN013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBBbmR5IEJpZXJtYW4sIE1hcmNoIDAzLCAyMDE2IDk6MTggUE08 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBNYXIgMSwgMjAxNiBh dCA4OjU1IEFNLCBFcmljIFZvaXQgKGV2b2l0KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmV2b2l0QGNp c2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmV2b2l0QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgVG9tLDxicj4NCjxicj4NCklu IHRoZSBlbmQsIHRoZSBudW1iZXIgb2YgZHJhZnRzIGlzIG5vdCBhIGh1Z2UgaXNzdWUgZm9yIHVz LiZuYnNwOyBUbyBkYXRlLCB3ZSBoYXZlIHNlZ21lbnRlZCBkcmFmdHMgc28gYXMgdG86PGJyPg0K PGJyPg0KKGEpIE1heGltaXplIHRyYW5zcG9ydCBpbmRlcGVuZGVuY2UuPGJyPg0KPGJyPg0KKGIp IFJlZHVjZSB0ZWNobm9sb2d5IG9wdGlvbnMgd2l0aGluIGFueSBvbmUgZHJhZnQuJm5ic3A7IChX ZSBkb24ndCB3YW50IHRoaW5ncyBvdmVybHkgY29tcGxleCBzbyB0aGF0IG9wZXJhdG9ycyBjYW4n dCBlYXNpbHkgcmVmZXIgdG8gZGVzaXJlZCZuYnNwOyBzdWJzZXQuKTxicj4NCjxicj4NCihjKSBN YXhpbWl6ZSBhbGlnbm1lbnQgd2l0aCBhbnkgaW4tZmxpZ2h0IFJGQzUyNzdiaXMgc3BlYzxicj4N Cjxicj4NCkF0IHRoZSBuZXh0IElFVEYsIHdlIHdvdWxkIGJlIGhhcHB5IHRvIG1ha2UgYSBwcm9w b3NhbCBmb3IgZnVuY3Rpb25hbGl0eSBzZWdtZW50YXRpb24gYWNyb3NzIHRoZSBmb2xsb3dpbmcg ZWxlbWVudHM6PGJyPg0KPGJyPg0KU3Vic2NyaXB0aW9uIENvbmZpZ3VyYXRpb248YnI+DQombmJz cDstIFN0YXRpYyZuYnNwOyAoJmFtcDsgTXVsdGlwbGUgUmVjZWl2ZXJzKTxicj4NCiZuYnNwOy0g RHluYW1pYyAoJmFtcDsgUGFyYW1ldGVyIE5lZ290aWF0aW9uKTxicj4NCiZuYnNwOy0gU3Vic2Ny aXB0aW9uIFFvUyAmYW1wOyBQcmlvcml0aXplZCBQdXNoPGJyPg0KJm5ic3A7LSBGaWx0ZXIgKFJG QzYyNDEsIFJGQzUyNzcsIG90aGVyKTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SWYgeW91IG1lYW4gZWFjaCBvZiB0aGVzZSBzdWItdG9waWNzIGlzIHBhcnQg b2YgMSBSRkMgdGhlbiBPSy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPklNTyBZQU5HIGZlYXR1cmVzIHNob3VsZCBtYWtlIHRoZXNlIGFsbCBvcHRp b25hbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jmx0O0VyaWMmZ3Q7IFllcywgdGhpcyBpcyB3aGF0IHdlIHdlcmUgdGhpbmtpbmcu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VHJhbnNwb3J0 IChOZXRjb25mLCBSZXN0Y29uZiwgSFRUUDIsIG90aGVyPyk8bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUgVHJhbnNwb3J0 IHNob3VsZCBiZSBhIHNlcGFyYXRlIFJGQy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldpbGwgdGhlcmUgYmUgYSBtYW5kYXRvcnktdG8taW1wbGVt ZW50IHRyYW5zcG9ydD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPihJTU8sIG5vKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7RXJpYyZndDsgWWVzLCB0aGlzIHdvdWxkIGJlIG91 ciBwcmVmZXJlbmNlIGFzIHdlbGwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5vdGhlcj8gbWlnaHQgYmUgUkVTVENPTkYgb3ZlciBD b0FQLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ b3IgcGVyaGFwcyB1c2luZyBORVRDT05GIGxpa2UgU05NUCAod2l0aCBjb25maWd1cmVkPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5saXN0ZW5lcnMp IGFuZCBzZW5kaW5nIG5vdGlmaWNhdGlvbnMgaW4gWE1MIG92ZXIgRFRMUy9VRFAuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZsdDtF cmljJmd0OyBPbiDigJhvdGhlcuKAmSwgd2Ugd2VyZSB0aGlua2luZyBhYm91dCBJUEZJWCBhcyBh biBleGFtcGxlIGFzIHdlbGwgYXQgc29tZSBwb2ludC4mbmJzcDsmbmJzcDsgTmV3IGRyYWZ0cyBj b3VsZCBjb21lIGZvciBuZXcgb3B0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlJGQzUyNzdiaXMg KG5ldyBhbmQvb3IgYXVnbWVudGVkIFJQQ3MpPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ3JlZSBpdCBpcyB0aW1lIHRvIHVwZGF0 ZSB0aGlzIFJGQzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5ORVRDT05GIG5vdGlmaWNhdGlvbnMgYXJlIGRlcGxveWVkIGFuZCBiZWluZyB1c2Vk LCBzbyBJIGhvcGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPnRoZSB1cGRhdGUgd2lsbCBub3QgZGlzdHVyYiBhbnkgcnVubmluZyBjb2RlLiBUaGlz IGlzIGVhc2lseSBkb25lPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5ieSBkZWZpbmluZyBuZXcgUlBDcyBhbmQgZXZlbiBuZXcgc3RhbmRhcmQgc3Ry ZWFtcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhlcmUgaXMgbGl0dGxlIHBvaW50IGluIHVwZGF0aW5nIHRoaXMgUkZDIHVubGVzcyBhbGwg ZGVmaWNpZW5jaWVzIGFuZCBuZXc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPmZlYXR1cmVzIGNhbiBiZSBjb25zaWRlcmVkIGJ5IHRoZSBXRy48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jmx0O0VyaWMmZ3Q7IEFncmVlIHdpdGggbmV3IFJQQ3MgYW5kIG5ldyBzdGFuZGFyZCBzdHJlYW1z LiZuYnNwOyZuYnNwOyBMb29rIGZvciBhIHN0cmF3bWFuIGJlZm9yZSB0aGUgSUVURiBjdXQtb2Zm IGRhdGUuJm5ic3A7IFdlIGFyZSBob3BpbmcgdG8gc2VlIG90aGVyIHByb3Bvc2FscyBhcyB3ZWxs IHNvIHRoYXQNCiB3ZSBjYW4gaGF2ZSBtb3JlIGV5ZXMgb24gdGhlIHByb2JsZW0uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5FcmljPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkJhc2VkIG9uIHdoYXRldmVyIGRpc2N1c3Npb24gZm9sbG93cywg d2Ugd2lsbCB0YWtlIFdHIGd1aWRhbmNlIG9uIGFwcHJvcHJpYXRlIGRyYWZ0IHNlZ21lbnRhdGlv bi48YnI+DQo8YnI+DQpFcmljPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQomZ3Q7IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBOZXRjb25mLCBGZWJydWFyeSAyNywgMjAx NiAxMToxNCBBTTxicj4NCiZndDs8YnI+DQomZ3Q7IC0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t LTxicj4NCiZndDsgRnJvbTogJnF1b3Q7TWFoZXNoIEpldGhhbmFuZGFuaSZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIj5tamV0aGFuYW5kYW5pQGdtYWls LmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyBUbzogJnF1b3Q7TkVUQ09ORiZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4N CiZndDsgU2VudDogU2F0dXJkYXksIEZlYnJ1YXJ5IDI3LCAyMDE2IDE6MjEgQU08YnI+DQomZ3Q7 PGJyPg0KJmd0OyAmZ3Q7IEkgYW0gZm9sbG93aW5nIHVwIG9uIHRoZSBkaXNjdXNzaW9uIGluIElF VEYgOTQgb24gdGhlIHF1ZXN0aW9uIG9mPGJyPg0KJmd0OyB3aGV0aGVyIHdlIG5lZWQgb25lIG9y IHRocmVlIGRyYWZ0cyBmb3IgWUFORyBwdXNoLiBPbmUgZHJhZnQgd291bGQgbWVhbiBhPGJyPg0K Jmd0OyBtZXJnZSBvZiBORVRDT05GIGFuZCBSRVNUQ09ORiBZQU5HIHB1c2ggZHJhZnQsIHdoaWxl IHRocmVlIGRyYWZ0cyB3b3VsZDxicj4NCiZndDsgYmUgYSBjb21tb24gZHJhZnQsIHRoZSBzZWNv bmQgb25lIGZvciBORVRDT05GIHNwZWNpZmljIHBhcnQgYW5kIHRoZSB0aGlyZCBmb3I8YnI+DQom Z3Q7IHRoZSBSRVNUQ09ORiBzcGVjaWZpYyBwYXJ0LiBUaGVyZSB3YXMgbm8gcHJlZmVyZW5jZSBm b3IganVzdCB0d28gZHJhZnRzIC0gb25lPGJyPg0KJmd0OyBmb3IgTkVUQ09ORiBhbmQgb25lIGZv ciBSRVNUQ09ORiB3aXRoIGNvbW1vbiBwYXJ0cyBlaXRoZXIgZHVwbGljYXRlZCBvcjxicj4NCiZn dDsgcmVmZXJlbmNlZC4gVGhlIHZvdGUgaW4gdGhlIHJvb20gc2VlbWVkIHRvIGluZGljYXRlIGEg dGllIGZvciAxIG9yIDMgZHJhZnRzIHdpdGg8YnI+DQomZ3Q7IG5vIGFwcGFyZW50IHdpbm5lci48 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhlIGF1dGhvcnMgaW5kaWNhdGVkIGEgcHJl ZmVyZW5jZSB0byBrZWVwIHRoZW0gYXMgc2VwYXJhdGUgZHJhZnRzLDxicj4NCiZndDsgYnV0IG90 aGVycyBpbiB0aGUgcm9vbSBzZWVtZWQgdG8gaW5kaWNhdGUgdGhhdCBvdGhlciBkcmFmdHMsIGxp a2UgY2FsbCBob21lIGFuZDxicj4NCiZndDsgemVybyB0b3VjaCBhcmUgZG9pbmcgaXQgYXMgYSBz aW5nbGUgZHJhZnQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IENhbiB3ZSBoYXZlIGEg ZGlzY3Vzc2lvbiBvZiB3aGV0aGVyIGZvbGtzIHdvdWxkIHByZWZlciB0byByZWFkIGFuZDxicj4N CiZndDsgZm9sbG93IFlBTkcgcHVzaCBhcyB0aHJlZSBzZXBhcmF0ZSBkcmFmdHMgb3Igd291bGQg dGhleSBwcmVmZXIgdG8gc2VlIHRoZW08YnI+DQomZ3Q7IG1lcmdlZD88YnI+DQomZ3Q7PGJyPg0K Jmd0OyBJIGRvbid0IGtub3csIGNhbiB3ZSBoYXZlIGEgZGlzY3Vzc2lvbjotKTxicj4NCiZndDs8 YnI+DQomZ3Q7IFdlbGwsIGFzc3VtaW5nIHdlIGNhbiwgSSBhbSBmb3IgYSBtZXJnZSBpbnRvIG9u ZSBJLUQuPGJyPg0KJmd0Ozxicj4NCiZndDsgVG9tIFBldGNoPGJyPg0KJmd0Ozxicj4NCiZndDsg Jmd0OyBUaGFua3MuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE1haGVzaCAmYW1wOyBN ZWhtZXQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IE5ldGNvbmYgbWFpbGlu ZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9yZyI+TmV0Y29u ZkBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0Y29uZiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk5ldGNvbmYgbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciPk5ldGNvbmZAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRjb25mIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRjb25mPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2a7ad5befaaf45e8855a7e5ef5a2c353XCHALN013ciscocom_-- From nobody Fri Mar 4 06:16:32 2016 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 C19B21A01D8 for ; Fri, 4 Mar 2016 06:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.901 X-Spam-Level: X-Spam-Status: No, score=-13.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DO8bxzkoxYhq for ; Fri, 4 Mar 2016 06:16:15 -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 4BFF41A01F6 for ; Fri, 4 Mar 2016 06:16:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7247; q=dns/txt; s=iport; t=1457100975; x=1458310575; h=to:from:subject:message-id:date:mime-version; bh=wHhtRmHpFQcizjrwehMHnt10mBbKAUlzLdMkOY/a5DE=; b=WB1bQ+uIG/0D81QHK1bzGnMZm3b/7CQgYEt1KUm8zWtrfIV65XSpr5Oy XgsLB4GP0cOxYFJP6THcrHn0mNaBmnR3uG85MrXXyJxDdyaO8fO2AYgbM n+u3anprTLAMvVFC2vsn9l7xA5KKYfzaZTI+tLjwK4hlR3krkbwsp0OU0 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQBMl9lW/xbLJq1dgm6BHrslAQ2Ba?= =?us-ascii?q?YYPgW0UAQEBAQEBAWQcC4RrVTANFgsCCwMCAQIBSw0IAQGIHp5yj12OfAEBAQc?= =?us-ascii?q?BAQEBHIYXhDyDfiM4gmCBOgWXIY1oiSiFUY5SHgEBQoNkPIlQAQEB?= X-IronPort-AV: E=Sophos;i="5.22,535,1449532800"; d="scan'208,217";a="633094101" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Mar 2016 14:16:13 +0000 Received: from [10.63.23.98] (dhcp-ensft1-uk-vla370-10-63-23-98.cisco.com [10.63.23.98]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u24EGDhl025241 for ; Fri, 4 Mar 2016 14:16:13 GMT To: "netconf@ietf.org" From: Robert Wilton Message-ID: <56D998AD.8040703@cisco.com> Date: Fri, 4 Mar 2016 14:16:13 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------060305080400000003030503" Archived-At: Subject: [Netconf] restconf-09 comments 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, 04 Mar 2016 14:16:22 -0000 This is a multi-part message in MIME format. --------------060305080400000003030503 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I appreciate that this is a while after the last call, but when reading restconf-09, I had a few minor comments (which may have already been pointed out by others previously). 1. Regarding "4.8.1. The "content" Query Parameter": The default value is determined by the "config" statement value of the requested data nodes. If the "config" value is "false", then the default for the "content" parameter is "nonconfig". If "config" is "true" then the default for the "content" parameter is "config". I was surprised so see that the default value wasn't just "all", - "all" felt like a more obvious default choice, i.e. don't filter the result unless explicitly asked to. - it means the behaviour is consistent whether a GET request is made on the top-level datastore URI or any child node underneath the root. - it is easier to document/explain/understand (and possibly implement). - It is the same regardless for nonconfig anyway, so would only affect the default behaviour for config nodes anyway. 2. The "D.1.1. Retrieve the Top-level API Resource" example looked slightly wrong to me. from the RESTCONF module definition in section 8 I would expect the data and operations container to be empty JSON objects. OLD: The server might respond as follows: HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 17:01:00 GMT Server: example-server Content-Type: application/yang.api+json { "ietf-restconf:restconf": { *"data" : [ null ], "operations" : [ null ]* } } NEW: The server might respond as follows: HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 17:01:00 GMT Server: example-server Content-Type: application/yang.api+json { "ietf-restconf:restconf": { *"data" : { }, "operations" : { }* } } 3. In "D.1.3. Retrieve The Server Capability Information", the example is XML rather than JSON. OLD: In this example the client is retrieving the capability information from the server in*JSON *format, and the server supports all the RESTCONF query parameters, plus one vendor parameter: NEW: In this example the client is retrieving the capability information from the server in*XML *format, and the server supports all the RESTCONF query parameters, plus one vendor parameter: Rob --------------060305080400000003030503 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi,

I appreciate that this is a while after the last call, but when reading restconf-09, I had a few minor comments (which may have already been pointed out by others previously).

1. Regarding "4.8.1.  The "content" Query Parameter":
   The default value is determined by the "config" statement value of
   the requested data nodes.  If the "config" value is "false", then the
   default for the "content" parameter is "nonconfig".  If "config" is
   "true" then the default for the "content" parameter is "config".

I was surprised so see that the default value wasn't just "all",
 - "all" felt like a more obvious default choice, i.e. don't filter the result unless explicitly asked to.
 - it means the behaviour is consistent whether a GET request is made on the top-level datastore URI or any child node underneath the root.
 - it is easier to document/explain/understand (and possibly implement).
 - It is the same regardless for nonconfig anyway, so would only affect the default behaviour for config nodes anyway.


2. The "D.1.1.  Retrieve the Top-level API Resource" example looked slightly wrong to me.  from the  RESTCONF module definition in section 8 I would expect the data and operations container to be empty JSON objects.

OLD:
   The server might respond as follows:

      HTTP/1.1 200 OK
      Date: Mon, 23 Apr 2012 17:01:00 GMT
      Server: example-server
      Content-Type: application/yang.api+json

      {
        "ietf-restconf:restconf": {
          "data" : [ null ],
          "operations" : [ null ]
        }
      }
 
NEW:
   The server might respond as follows:

      HTTP/1.1 200 OK
      Date: Mon, 23 Apr 2012 17:01:00 GMT
      Server: example-server
      Content-Type: application/yang.api+json

      {
        "ietf-restconf:restconf": {
          "data" : { },
          "operations" : { }
        }
      }

3. In "D.1.3.  Retrieve The Server Capability Information", the example is XML rather than JSON.

OLD:
   In this example the client is retrieving the capability information
   from the server in JSON format, and the server supports all the
   RESTCONF query parameters, plus one vendor parameter:

NEW:
   In this example the client is retrieving the capability information
   from the server in XML format, and the server supports all the
   RESTCONF query parameters, plus one vendor parameter:


Rob

--------------060305080400000003030503-- From nobody Fri Mar 4 07:29:50 2016 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 BB99B1A1B7F for ; Fri, 4 Mar 2016 07:29:49 -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 N-QpVDIKtJ4z for ; Fri, 4 Mar 2016 07:29:48 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::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 848041A1B74 for ; Fri, 4 Mar 2016 07:29:47 -0800 (PST) Received: by mail-lb0-x229.google.com with SMTP id bc4so64941033lbc.2 for ; Fri, 04 Mar 2016 07:29:47 -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; bh=SySANSmvnqOeMr7ZLiqHW79a6kCOWLNFIBWG3XprzcQ=; b=lr0Z/4Bj2htynYPvZEnYHCqlbQUJGJX70blgW9+y/RnFzwohNYvPR2WzaIdvePAbRM SBr7TIY+C4dWk5GL5dZAWGwZRdLSIgAZOOuqm7CuohuC0Od1l5n4KaOFTjz0xXqnKPrM ABD3ON/9QUlOz5mIIWH0vtg+pP4zHQYlG/WoxhEcaMQhrYGkFB6Te7c9LS9ShDaRPDT5 guBDDXxAwcXM7xnBMtuwY4v0UFYh7XH9MTjD8fECVjde+LUWbx0lMo5XzfCn6HdE7rYL 5Pp5mUmJJ3RPR/CukEnoYoYE/OdOYpOJ97iZ8Inj7SPw1et5BMcuwodIxQ5NaY69yt/C wSWA== 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; bh=SySANSmvnqOeMr7ZLiqHW79a6kCOWLNFIBWG3XprzcQ=; b=H5Tt8muaZYQcm23UEWMgh891pnMWtH1oRgvhnjl7pA/jFsolVZd1huDiUvyzj3d6mG tSq9IZfLlaVOjvG1iUr4FD8tZvQ60hGE7gT9KcA4segDGRscMMSeQSE3gZxvY19w+ouw PoxRk08WeNPXvCO9UAxosXp4CQ2yc7hM2GJeyEj8YgtIV4UaNsA7dtlji6BJEkHOPUFg nHz+OhZijoyd6ez8R2warywIt5xutuVMwsuL3e+IL5DdspNHJJjV67q+3N6SrsGpvEuy xVQ5T2lNs6KQoFobdvGbZb9/waJFFxSd5gU5tiaNG7yJqHZW9e33SPWggVWa0Q02ti2k /ECA== X-Gm-Message-State: AD7BkJJgpeloYc22DDTAFB312Gbtb7Mz76wy5CUXv1mU3xPYRydJZ6QbiAFljFHF6PLtABGucuF5cGlpr42E/g== MIME-Version: 1.0 X-Received: by 10.25.77.13 with SMTP id a13mr3665164lfb.62.1457105385706; Fri, 04 Mar 2016 07:29:45 -0800 (PST) Received: by 10.112.110.68 with HTTP; Fri, 4 Mar 2016 07:29:45 -0800 (PST) In-Reply-To: <56D998AD.8040703@cisco.com> References: <56D998AD.8040703@cisco.com> Date: Fri, 4 Mar 2016 07:29:45 -0800 Message-ID: From: Andy Bierman To: Robert Wilton Content-Type: multipart/alternative; boundary=001a114046aaea7012052d3ac858 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] restconf-09 comments 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, 04 Mar 2016 15:29:49 -0000 --001a114046aaea7012052d3ac858 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 4, 2016 at 6:16 AM, Robert Wilton wrote: > Hi, > > I appreciate that this is a while after the last call, but when reading > restconf-09, I had a few minor comments (which may have already been > pointed out by others previously). > > 1. Regarding "4.8.1. The "content" Query Parameter": > > The default value is determined by the "config" statement value of > the requested data nodes. If the "config" value is "false", then the > default for the "content" parameter is "nonconfig". If "config" is > "true" then the default for the "content" parameter is "config". > > > I was surprised so see that the default value wasn't just "all", > - "all" felt like a more obvious default choice, i.e. don't filter the > result unless explicitly asked to. > - it means the behaviour is consistent whether a GET request is made on > the top-level datastore URI or any child node underneath the root. > - it is easier to document/explain/understand (and possibly implement). > - It is the same regardless for nonconfig anyway, so would only affect > the default behaviour for config nodes anyway. > > The default will be 'all' if the target resource is the datastore itself. > > 2. The "D.1.1. Retrieve the Top-level API Resource" example looked > slightly wrong to me. from the RESTCONF module definition in section 8 I > would expect the data and operations container to be empty JSON objects. > > OLD: > > The server might respond as follows: > > HTTP/1.1 200 OK > Date: Mon, 23 Apr 2012 17:01:00 GMT > Server: example-server > Content-Type: application/yang.api+json > > { > "ietf-restconf:restconf": {* "data" : [ null ], > "operations" : [ null ]* > } > } > > > NEW: > > The server might respond as follows: > > HTTP/1.1 200 OK > Date: Mon, 23 Apr 2012 17:01:00 GMT > Server: example-server > Content-Type: application/yang.api+json > > { > "ietf-restconf:restconf": {* "data" : { }, > "operations" : { }* > } > } > > I think the text says the API resource is returned which includes these 2 child nodes, also application/yang.api > > 3. In "D.1.3. Retrieve The Server Capability Information", the example is > XML rather than JSON. > > OLD: > > In this example the client is retrieving the capability information > from the server in *JSON *format, and the server supports all the > RESTCONF query parameters, plus one vendor parameter: > > NEW: > In this example the client is retrieving the capability information > from the server in *XML *format, and the server supports all the > RESTCONF query parameters, plus one vendor parameter: > > > OK > > Rob > > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a114046aaea7012052d3ac858 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 4, 2016 at 6:16 AM, Robert Wilton <rwilton@cisco.com&g= t; wrote:
=20 =20 =20
Hi,

I appreciate that this is a while after the last call, but when reading restconf-09, I had a few minor comments (which may have already been pointed out by others previously).

1. Regarding "4.8.1.=C2=A0 The "content" Query Parameter= ":
   The default value is determined by the &=
quot;config" statement value of
   the requested data nodes.  If the "config" value is "fals=
e", then the
   default for the "content" parameter is "nonconfig". =
 If "config" is
   "true" then the default for the "content" parameter =
is "config".

I was surprised so see that the default value wasn't just "all= ",
=C2=A0- "all" felt like a more obvious default choice, i.e. d= on't filter the result unless explicitly asked to.
=C2=A0- it means the behaviour is consistent whether a GET request is made on the top-level datastore URI or any child node underneath the root.
=C2=A0- it is easier to document/explain/understand (and possibly implement).
=C2=A0- It is the same regardless for nonconfig anyway, so would only affect the default behaviour for config nodes anyway.



The default w= ill be 'all' if the target resource is the datastore itself.
<= div>
=C2=A0

2. The "D.1.1.=C2=A0 Retrieve the Top-level API Resource" exa= mple looked slightly wrong to me.=C2=A0 from the=C2=A0 RESTCONF module definition i= n section 8 I would expect the data and operations container to be empty JSON objects.

OLD:
   The server might respond as follows:

      HTTP/1.1 200 OK
      Date: Mon, 23 Apr 2012 17:01:00 GMT
      Server: example-server
      Content-Type: application/yang.api+json

      {
        "ietf-restconf:restconf": {
          "data" : [ null ],
          "operations" : [ null ]
        }
      }
=C2=A0
NEW:
   The server might respond as follows:

      HTTP/1.1 200 OK
      Date: Mon, 23 Apr 2012 17:01:00 GMT
      Server: example-server
      Content-Type: application/yang.api+json

      {
        "ietf-restconf:restconf": {
          "data" : { },
          "operations" : { }
        }
      }


I think = the text says the API resource is returned which includes these
2= child nodes, also application/yang.api

=C2=A0

3. In "D.1.3.=C2=A0 Retrieve The Server Capability Information&quo= t;, the example is XML rather than JSON.

OLD:
   In this example the client is retrieving=
 the capability information
   from the server in JSON format, and the server supports all the
   RESTCONF query parameters, plus one vendor parameter:

NEW:
   In this example the client is retrieving the capability information
   from the server in XML format, and the server supports all the
   RESTCONF query parameters, plus one vendor parameter:


OK
=C2=A0

Rob


Andy
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

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


--001a114046aaea7012052d3ac858-- From nobody Fri Mar 4 09:10:30 2016 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 E4B6D1A1B30 for ; Fri, 4 Mar 2016 09:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.901 X-Spam-Level: X-Spam-Status: No, score=-13.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWCu-2OWGmzY for ; Fri, 4 Mar 2016 09:10:25 -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 F2BF01A1A90 for ; Fri, 4 Mar 2016 09:10:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14211; q=dns/txt; s=iport; t=1457111425; x=1458321025; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=Nm0uV2xPu//1DHm7urxFctLJaqclJcgjh9/BUK8EYX0=; b=Xo7blopN34eTWnFlbRJK/oQgm4FkEX1DsLS15Zi/ciW8x3j5B5PVTFYO ALH5jsp8J56leyUz81A+p3VGYbML10as4BeO8n/dta0y32ODhtKQWHNtV jDwb+CANJlw8w1cvzUIGLAzUHw8a6nNGZEzVgxZG19ktObVvuNbBj7uzj s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvBAACwdlW/xbLJq1dgm6BHm28MRcBC?= =?us-ascii?q?YUkSgKCAwEBAQEBAWUnhEEBAQEDAQEBASBLCxALFAQJHgMCAg8CFh8RBg0GAgE?= =?us-ascii?q?BiBYIDq8IjwsBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYXhDyDfiM4DQmCSoE6B?= =?us-ascii?q?ZchhV6ICokohVGOUmKDZTwuiS4BAQE?= X-IronPort-AV: E=Sophos;i="5.22,536,1449532800"; d="scan'208,217";a="635934254" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Mar 2016 17:10:23 +0000 Received: from [10.63.23.98] (dhcp-ensft1-uk-vla370-10-63-23-98.cisco.com [10.63.23.98]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u24HAMqZ007283; Fri, 4 Mar 2016 17:10:22 GMT To: Andy Bierman References: <56D998AD.8040703@cisco.com> From: Robert Wilton Message-ID: <56D9C17E.90004@cisco.com> Date: Fri, 4 Mar 2016 17:10:22 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040906010100090300040109" Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] restconf-09 comments 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, 04 Mar 2016 17:10:28 -0000 This is a multi-part message in MIME format. --------------040906010100090300040109 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Andy, On 04/03/2016 15:29, Andy Bierman wrote: > > > On Fri, Mar 4, 2016 at 6:16 AM, Robert Wilton > wrote: > > Hi, > > I appreciate that this is a while after the last call, but when > reading restconf-09, I had a few minor comments (which may have > already been pointed out by others previously). > > 1. Regarding "4.8.1. The "content" Query Parameter": > > The default value is determined by the "config" statement value of > the requested data nodes. If the "config" value is "false", then the > default for the "content" parameter is "nonconfig". If "config" is > "true" then the default for the "content" parameter is "config". > > > I was surprised so see that the default value wasn't just "all", > - "all" felt like a more obvious default choice, i.e. don't > filter the result unless explicitly asked to. > - it means the behaviour is consistent whether a GET request is > made on the top-level datastore URI or any child node underneath > the root. > - it is easier to document/explain/understand (and possibly > implement). > - It is the same regardless for nonconfig anyway, so would only > affect the default behaviour for config nodes anyway. > > > > The default will be 'all' if the target resource is the datastore itself. Yes. As above, that is one of the reasons why I think that it would be better if the default is "all" for any nodes within the datastore itself as well. It makes it more consistent. > > > 2. The "D.1.1. Retrieve the Top-level API Resource" example > looked slightly wrong to me. from the RESTCONF module definition > in section 8 I would expect the data and operations container to > be empty JSON objects. > > OLD: > > The server might respond as follows: > > HTTP/1.1 200 OK > Date: Mon, 23 Apr 2012 17:01:00 GMT > Server: example-server > Content-Type: application/yang.api+json > > { > "ietf-restconf:restconf": { > *"data" : [ null ], "operations" : [ null ]* > } > } > > > NEW: > > The server might respond as follows: > > HTTP/1.1 200 OK > Date: Mon, 23 Apr 2012 17:01:00 GMT > Server: example-server > Content-Type: application/yang.api+json > > { > "ietf-restconf:restconf": { > *"data" : { }, "operations" : { }* > } > } > > > > I think the text says the API resource is returned which includes these > 2 child nodes, also application/yang.api Section 3.3. API Resource states: The "application/yang.api" restconf-media-type extension in the "ietf-restconf" module defined inSection 8 is used to specify the structure and syntax of the conceptual child resources within the API resource. Section 8 gives a YANG module that has data and operations as containers. I can't obviously see any text which states that these two containers should be represented as two leaves of type empty instead of a JSON interpretation of the YANG module definition. So I still believe that either the textual description or the example needs to be fixed. Thanks, Rob > > > 3. In "D.1.3. Retrieve The Server Capability Information", the > example is XML rather than JSON. > > OLD: > > In this example the client is retrieving the capability information > from the server in*JSON *format, and the server supports all the > RESTCONF query parameters, plus one vendor parameter: > > NEW: > In this example the client is retrieving the capability information > from the server in*XML *format, and the server supports all the > RESTCONF query parameters, plus one vendor parameter: > > > > OK > > > Rob > > > Andy > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --------------040906010100090300040109 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Andy,

On 04/03/2016 15:29, Andy Bierman wrote:


On Fri, Mar 4, 2016 at 6:16 AM, Robert Wilton <rwilton@cisco.com> wrote:
Hi,

I appreciate that this is a while after the last call, but when reading restconf-09, I had a few minor comments (which may have already been pointed out by others previously).

1. Regarding "4.8.1.  The "content" Query Parameter":
   The default value is determined by the "config" statement value of
   the requested data nodes.  If the "config" value is "false", then the
   default for the "content" parameter is "nonconfig".  If "config" is
   "true" then the default for the "content" parameter is "config".

I was surprised so see that the default value wasn't just "all",
 - "all" felt like a more obvious default choice, i.e. don't filter the result unless explicitly asked to.
 - it means the behaviour is consistent whether a GET request is made on the top-level datastore URI or any child node underneath the root.
 - it is easier to document/explain/understand (and possibly implement).
 - It is the same regardless for nonconfig anyway, so would only affect the default behaviour for config nodes anyway.



The default will be 'all' if the target resource is the datastore itself.
Yes.  As above, that is one of the reasons why I think that it would be better if the default is "all" for any nodes within the datastore itself as well.  It makes it more consistent.



 

2. The "D.1.1.  Retrieve the Top-level API Resource" example looked slightly wrong to me.  from the  RESTCONF module definition in section 8 I would expect the data and operations container to be empty JSON objects.

OLD:
   The server might respond as follows:

      HTTP/1.1 200 OK
      Date: Mon, 23 Apr 2012 17:01:00 GMT
      Server: example-server
      Content-Type: application/yang.api+json

      {
        "ietf-restconf:restconf": {
          "data" : [ null ],
          "operations" : [ null ]
        }
      }
 
NEW:
   The server might respond as follows:

      HTTP/1.1 200 OK
      Date: Mon, 23 Apr 2012 17:01:00 GMT
      Server: example-server
      Content-Type: application/yang.api+json

      {
        "ietf-restconf:restconf": {
          "data" : { },
          "operations" : { }
        }
      }


I think the text says the API resource is returned which includes these
2 child nodes, also application/yang.api
Section 3.3.  API Resource states:
   The "application/yang.api" restconf-media-type extension in the
   "ietf-restconf" module defined in Section 8 is used to specify the
   structure and syntax of the conceptual child resources within the API
   resource.

Section 8 gives a YANG module that has data and operations as containers.  I can't obviously see any text which states that these two containers should be represented as two leaves of type empty instead of a JSON interpretation of the YANG module definition.  So I still believe that either the textual description or the example needs to be fixed.

Thanks,
Rob



 

3. In "D.1.3.  Retrieve The Server Capability Information", the example is XML rather than JSON.

OLD:
   In this example the client is retrieving the capability information
   from the server in JSON format, and the server supports all the
   RESTCONF query parameters, plus one vendor parameter:

NEW:
   In this example the client is retrieving the capability information
   from the server in XML format, and the server supports all the
   RESTCONF query parameters, plus one vendor parameter:


OK
 

Rob


Andy
 

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



--------------040906010100090300040109-- From nobody Fri Mar 4 10:43:21 2016 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 273021A8762 for ; Fri, 4 Mar 2016 10:43:20 -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 jOFyaUNU-3d2 for ; Fri, 4 Mar 2016 10:43:18 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (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 023D51A8768 for ; Fri, 4 Mar 2016 10:43:15 -0800 (PST) Received: by mail-lb0-x230.google.com with SMTP id k15so71230384lbg.0 for ; Fri, 04 Mar 2016 10:43:14 -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; bh=aSxcNZtIm5uJ1HlRDpMtUE6b2y90Pvy45n5lQWtuTUI=; b=oa5Yz/d3S5QAIiaT7x/sTvZB4YR4F4JX6xQBWu/mbObY/cm/UZJ62gG0U8Xr7Pde8q ZmK1K06jEuoPDeCCn/wkcqVBKkCMrHV7mvQErNKffhHpHHYiD6bkmaxFTcwVoRPl7AVM TVqRPIZ4yTPX9ZUQDbonVZjfMb7PuanSRYeFAxyjsuhva7ooNW3+LaIAjH9o4ZD68RWN c1g3L6syZJpZutXv9MKvVfwbKOXEMPcf3wiA9jfGbb06DLEIZDWD6wuAbH86Rku4oyUI +KhrQI9jeF4nBenvpsq7WHUFSRo3+FpIrakSGdkBLq5ghNcFJwKMNRfRho9p03AIb8n+ L63g== 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; bh=aSxcNZtIm5uJ1HlRDpMtUE6b2y90Pvy45n5lQWtuTUI=; b=MwLJk4kbkjE0Lq8BUBI52e+kvVvmTtfTUddr2GnFvnj9tVUOxkAgbIDvgAizTMlOPU elIGZMEEA2sVtGBf0H87jDfkGTF5053Xpa4rksjnzW0p7Hw4S7bQQSEwBvgrHZojNUEK CVi1ekKueGVQMUBixkftSmwF4P3GpveB08+9/C+hyckMbY8TCH9/+3o4BUaEJQyUQYXn GxtGHiWKfAsED1oGSrboRBJZ+ySEdiPxhKnEC4T4hqdFX1X4ibnV2ji8S4XygFHuBEvp KMcxsgPUouZp9ROEcGKSDqD5myM+0TCXk4CGo+jEPm216wVf1VhQMuTvngZQsYTGIX9a Nhpw== X-Gm-Message-State: AD7BkJIFkMQZJge1itrgWyJGsTxAKPu0mUZ4LBMlQrw8aqD7rUFjIvkcf24/cBE/CyUosgjTgpI2yTqgGcuMuQ== MIME-Version: 1.0 X-Received: by 10.112.171.163 with SMTP id av3mr3600726lbc.145.1457116993216; Fri, 04 Mar 2016 10:43:13 -0800 (PST) Received: by 10.112.110.68 with HTTP; Fri, 4 Mar 2016 10:43:13 -0800 (PST) In-Reply-To: <56D9C17E.90004@cisco.com> References: <56D998AD.8040703@cisco.com> <56D9C17E.90004@cisco.com> Date: Fri, 4 Mar 2016 10:43:13 -0800 Message-ID: From: Andy Bierman To: Robert Wilton Content-Type: multipart/alternative; boundary=001a11c36b36c6fbc6052d3d7c22 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] restconf-09 comments 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, 04 Mar 2016 18:43:20 -0000 --001a11c36b36c6fbc6052d3d7c22 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 4, 2016 at 9:10 AM, Robert Wilton wrote: > Hi Andy, > > On 04/03/2016 15:29, Andy Bierman wrote: > > > > On Fri, Mar 4, 2016 at 6:16 AM, Robert Wilton wrote: > >> Hi, >> >> I appreciate that this is a while after the last call, but when reading >> restconf-09, I had a few minor comments (which may have already been >> pointed out by others previously). >> >> 1. Regarding "4.8.1. The "content" Query Parameter": >> >> The default value is determined by the "config" statement value of >> the requested data nodes. If the "config" value is "false", then the >> default for the "content" parameter is "nonconfig". If "config" is >> "true" then the default for the "content" parameter is "config". >> >> >> I was surprised so see that the default value wasn't just "all", >> - "all" felt like a more obvious default choice, i.e. don't filter the >> result unless explicitly asked to. >> - it means the behaviour is consistent whether a GET request is made on >> the top-level datastore URI or any child node underneath the root. >> - it is easier to document/explain/understand (and possibly implement). >> - It is the same regardless for nonconfig anyway, so would only affect >> the default behaviour for config nodes anyway. >> >> > > The default will be 'all' if the target resource is the datastore itself. > > Yes. As above, that is one of the reasons why I think that it would be > better if the default is "all" for any nodes within the datastore itself as > well. It makes it more consistent. > > > Is there is WG consensus to make this change? What do others think? OLD: (text cited above in 4.8.1) NEW: The default value is 'all'. This means that in order to do a "get-config" the content=config parameter always has to be used. The current solution is optimized for configuration data nodes. > > >> >> 2. The "D.1.1. Retrieve the Top-level API Resource" example looked >> slightly wrong to me. from the RESTCONF module definition in section 8 I >> would expect the data and operations container to be empty JSON objects. >> >> OLD: >> >> The server might respond as follows: >> >> HTTP/1.1 200 OK >> Date: Mon, 23 Apr 2012 17:01:00 GMT >> Server: example-server >> Content-Type: application/yang.api+json >> >> { >> "ietf-restconf:restconf": {* "data" : [ null ], >> "operations" : [ null ]* >> } >> } >> >> >> NEW: >> >> The server might respond as follows: >> >> HTTP/1.1 200 OK >> Date: Mon, 23 Apr 2012 17:01:00 GMT >> Server: example-server >> Content-Type: application/yang.api+json >> >> { >> "ietf-restconf:restconf": {* "data" : { }, >> "operations" : { }* >> } >> } >> >> > > I think the text says the API resource is returned which includes these > 2 child nodes, also application/yang.api > > Section 3.3. API Resource states: > > The "application/yang.api" restconf-media-type extension in the > "ietf-restconf" module defined in Section 8 is used to specify the > structure and syntax of the conceptual child resources within the API > resource. > > > Section 8 gives a YANG module that has data and operations as containers. > I can't obviously see any text which states that these two containers > should be represented as two leaves of type empty instead of a JSON > interpretation of the YANG module definition. So I still believe that > either the textual description or the example needs to be fixed. > > OK -- I will try to fix the module definition > Thanks, > Rob > > > Andy > > > >> >> 3. In "D.1.3. Retrieve The Server Capability Information", the example >> is XML rather than JSON. >> >> OLD: >> >> In this example the client is retrieving the capability information >> from the server in *JSON *format, and the server supports all the >> RESTCONF query parameters, plus one vendor parameter: >> >> NEW: >> In this example the client is retrieving the capability information >> from the server in *XML *format, and the server supports all the >> RESTCONF query parameters, plus one vendor parameter: >> >> >> > OK > > >> >> Rob >> >> > Andy > > >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> > > --001a11c36b36c6fbc6052d3d7c22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 4, 2016 at 9:10 AM, Robert Wilton <rwilton@cisco.com&g= t; wrote:
=20 =20 =20
Hi Andy,

On 04/03/2016 15:29, Andy Bierman wrote:
=20


On Fri, Mar 4, 2016 at 6:16 AM, Robert Wilton <rwilton@cisco.com> wrote:
Hi,

I appreciate that this is a while after the last call, but when reading restconf-09, I had a few minor comments (which may have already been pointed out by others previously).

1. Regarding "4.8.1.=C2=A0 The "content" Que= ry Parameter":
   The default value is determi=
ned by the "config" statement value of
   the requested data nodes.  If the "config" value is "fals=
e", then the
   default for the "content" parameter is "nonconfig". =
 If "config" is
   "true" then the default for the "content" parameter =
is "config".

I was surprised so see that the default value wasn't just "all",
=C2=A0- "all" felt like a more obvious default ch= oice, i.e. don't filter the result unless explicitly asked to.
=C2=A0- it means the behaviour is consistent whether a GET request is made on the top-level datastore URI or any child node underneath the root.
=C2=A0- it is easier to document/explain/understand (and possibly implement).
=C2=A0- It is the same regardless for nonconfig anyway, so would only affect the default behaviour for config nodes anyway.



The default will be 'all' if the target resource i= s the datastore itself.
Yes.=C2=A0 As above, that is one of the reasons why I think that it wou= ld be better if the default is "all" for any nodes within the da= tastore itself as well.=C2=A0 It makes it more consistent.




Is there is W= G consensus to make this change?
What do others think?
=
OLD: =C2=A0(text cited above in 4.8.1)

<= div>NEW: The default value is 'all'.


<= /div>
This means that in order to do a "get-config" the conte= nt=3Dconfig parameter always has to be used.
The current solution= is optimized for configuration data nodes.



=C2=A0

2. The "D.1.1.=C2=A0 Retrieve the Top-level API Resour= ce" example looked slightly wrong to me.=C2=A0 from the=C2=A0 R= ESTCONF module definition in section 8 I would expect the data and operations container to be empty JSON objects.

OLD:
   The server might respond as =
follows:

      HTTP/1.1 200 OK
      Date: Mon, 23 Apr 2012 17:01:00 GMT
      Server: example-server
      Content-Type: application/yang.api+json

      {
        "ietf-restconf:restconf": {
          "data" : [ null ],
          "operations" : [ null ]
        }
      }
=C2=A0
NEW:
   The server might respond as =
follows:

      HTTP/1.1 200 OK
      Date: Mon, 23 Apr 2012 17:01:00 GMT
      Server: example-server
      Content-Type: application/yang.api+json

      {
        "ietf-restconf:restconf": {
          "data" : { },
          "operations" : { }
        }
      }


I think the text says the API resource is returned which includes these
2 child nodes, also application/yang.api
Section 3.3.=C2=A0 API Resource states:
   The "application/yang.api" res=
tconf-media-type extension in the
   "ietf-restconf" module defined in Sect=
ion 8 is used to specify the
   structure and syntax of the conceptual child resources within the API
   resource.

Section 8 gives a YANG module that has data and operations as containers.=C2=A0 I can't obviously see any text which states that = these two containers should be represented as two leaves of type empty instead of a JSON interpretation of the YANG module definition.=C2=A0 S= o I still believe that either the textual description or the example needs to be fixed.



OK -- I will = try to fix the module definition


= =C2=A0
Thanks,
Rob




Andy
=C2=A0

=C2=A0

3. In "D.1.3.=C2=A0 Retrieve The Server Capability Information", the example is XML rather than JSON.

OLD:
   In this example the client i=
s retrieving the capability information
   from the server in JSON format, and the server supports all the
   RESTCONF query parameters, plus one vendor parameter:

NEW:
   In this example the client is retrieving the capability information
   from the server in XML format, and the server supports all the
   RESTCONF query parameters, plus one vendor parameter:


OK
=C2=A0

Rob


Andy
=C2=A0

_______________________________________________
Netconf mailing list
Netconf= @ietf.org
https://www.ietf.org/mailman/listinfo/net= conf




--001a11c36b36c6fbc6052d3d7c22-- From nobody Sun Mar 6 19:22:19 2016 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 15B961A8711 for ; Sun, 6 Mar 2016 19:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKJAPkCByCDq for ; Sun, 6 Mar 2016 19:22:16 -0800 (PST) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 C01B31A870F for ; Sun, 6 Mar 2016 19:22:16 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id 129so27149218pfw.1 for ; Sun, 06 Mar 2016 19:22:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:message-id:date:to:mime-version; bh=qP9D2ywCXevJftMxZQxpeMUiuIUqfKeOiP/4J3zdYGY=; b=cL7bLocOlVtuYgBcjk02jTE3RT54gT0Q75bjoi2wRQlUlADT5xTlw3ZL+yCaz/WTPb fkY/tDzzvO9CXmN84JkYK+5pGXyt70lGnD0JzUkM5a5dPs9v92jYDO9YI1c/bK6opPRm oBxJTvIs7qbt0gTL2Zfddj1vF54BvB7/oxJFzDTFo8Bwq3+pIigClrIjY59azUdH9lwa +SjPBOuk0WA9udWdKCJnYCZXvLkfdI3CDz7+pZBhyyRU1sW1siVWMoQsYV1tPMUDPKhb AdlSMegUWNiwvMzsyGBsCxrsbF/0zDMwpvMIj1H34iaO0BvfdZ84GVqsDyY34qKkwlqe PNXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=qP9D2ywCXevJftMxZQxpeMUiuIUqfKeOiP/4J3zdYGY=; b=BuhxPJvw0uMJemOO9kI7HOf6pDYwrqqDArcZgLEqG1Cl5RwEtmHYjreYUf2s1wQDgt l82jwrcjDLdGd/or4zYpQ4Bl7dYRSMkGcADjzxH8WtgaU7G8i6W8m1jhni7nSAHSmpJ/ g/SZMHUGYUw/eFFTro8W7hv4xrLuC85w9iLemQ8xhMiD12nCbwZYCCFDED7zP4RsLm8B B1Bwxo/lVgw/feWUoQd1AJrwtjNnwpYYtFPbxabaxU4hPbYLBb2l7dsvFSDGu1OBPzUR V8LtgSocOZWobXpqg3VXRtm9PlmDlG/Bkd3qIPGyOAdfoV0WnA5y9CtMsztpAqt97faC LwWQ== X-Gm-Message-State: AD7BkJLj/TLslmQnw1p64XkZ8+7/+ibBHMfoenLA1m8lEfYLDfYm8LYDSSmZdmxQjKucWQ== X-Received: by 10.98.68.73 with SMTP id r70mr30688932pfa.136.1457320936272; Sun, 06 Mar 2016 19:22:16 -0800 (PST) Received: from mahesh-m-62at.attlocal.net ([2602:306:cf77:df90:18b:7027:3819:276d]) by smtp.gmail.com with ESMTPSA id 27sm20364456pfo.58.2016.03.06.19.22.15 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 06 Mar 2016 19:22:15 -0800 (PST) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_CDDB2184-25F1-4074-8D92-646839261CA8" Message-Id: Date: Sun, 6 Mar 2016 19:22:13 -0800 To: NETCONF Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [Netconf] Agenda Request 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, 07 Mar 2016 03:22:18 -0000 --Apple-Mail=_CDDB2184-25F1-4074-8D92-646839261CA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It is that time again where we ask if you want to present in the NETCONF = session at IETF 95. Please indicate Topic: Length: Presenter: in your request for the slot.=20 All this assumes that you have published/updated a draft on the mailing = list and have garnered some discussion around it. If not, there is still = time to do that before the meeting. Cheers. Mahesh & Mehmet --Apple-Mail=_CDDB2184-25F1-4074-8D92-646839261CA8 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
It is that time again where we ask if you want to present in the NETCONF session at IETF 95.

Please indicate

Topic:
Length:
Presenter:

in your request for the slot. 

All this assumes that you have published/updated a draft on the mailing list and have garnered some discussion around it. If not, there is still time to do that before the meeting.

Cheers.

Mahesh & Mehmet




--Apple-Mail=_CDDB2184-25F1-4074-8D92-646839261CA8-- From nobody Mon Mar 7 05:52:15 2016 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 95DC41B4163 for ; Mon, 7 Mar 2016 05:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-z3V5zJ8unp for ; Mon, 7 Mar 2016 05:52:13 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CC781B4165 for ; Mon, 7 Mar 2016 05:52:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1320; q=dns/txt; s=iport; t=1457358733; x=1458568333; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=OtSnC+KTeD3Is1FN/8VRW8SRCbdgAP/PlKI3pImuZ2Y=; b=EtCgmSarIQL+Oy/KsS9XyatMOoLTjaVB9IJwMUTUc0C+l35DIu+baItY ekx/nFb3fdm01tIyYdePAWXeuH64rNG8QsPWCvXQvNxwxRdHxIlInps8S B/HA/5dYGuVB+VSES8qs9jXll/1enetWRBxv/bVCfaXuNipiyhQZVIFf5 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D8AQBpht1W/5FdJa1dgzpSbQa6OgENg?= =?us-ascii?q?WmGDwKBJzgUAQEBAQEBAWQnhEEBAQEEbhsCAQgOAwQBASgHMhQJCAIEARIIiBq?= =?us-ascii?q?/OAEBAQEBAQEBAQEBAQEBAQEBAQEBARWGF4Q9iHQFh1uGDYUShDABjWWBaoREi?= =?us-ascii?q?FNpjWsBHgEBQoNkaog/fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,551,1449532800"; d="scan'208";a="246467323" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2016 13:52:12 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u27DqCJm029182 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Mar 2016 13:52:12 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 7 Mar 2016 07:52:11 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.009; Mon, 7 Mar 2016 07:52:11 -0600 From: "Eric Voit (evoit)" To: Mahesh Jethanandani , NETCONF Thread-Topic: [Netconf] Agenda Request Thread-Index: AQHReCCYDTDiL7Cf8US+FMSdmOZDp59N+WeA Date: Mon, 7 Mar 2016 13:52:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.235] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] Agenda Request 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, 07 Mar 2016 13:52:14 -0000 Hi Mahesh & Mehmet, Below are the two topics we were hoping present . Topics: (1) Yang Subscriptions - draft-ietf-netconf-yang-push=20 - WG draft revisions - IETF hackathon demo results: yang-push interworking with OpenDayli= ght=20 - draft-voit-netconf-restconf-yang-push - New draft this week: shrunk to cover just Restconf & HTTP transpor= ts - Discussion: do we have the desired WG division for these drafts? (2) RFC5277bis=20 - Proposal coming into WG before submission cut-off date Length:=20 (1) Yang Subscriptions - 20 min (2) RFC5277bis - 10 min Presenter:=20 - Eric Voit (on behalf of the authors) Thanks, Eric, Alex, Alberto, Ambika, Einar ------------------- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh Jethana= ndani Sent: Sunday, March 06, 2016 10:22 PM To: NETCONF Subject: [Netconf] Agenda Request It is that time again where we ask if you want to present in the NETCONF se= ssion at IETF 95. Please indicate Topic: Length: Presenter: in your request for the slot.=A0 All this assumes that you have published/updated a draft on the mailing lis= t and have garnered some discussion around it. If not, there is still time = to do that before the meeting. Cheers. Mahesh & Mehmet From nobody Mon Mar 7 06:32:43 2016 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 B9EBC1B4148 for ; Mon, 7 Mar 2016 06:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfsMnWQwRcaz for ; Mon, 7 Mar 2016 06:32:40 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E421B419C for ; Mon, 7 Mar 2016 06:32:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3963; q=dns/txt; s=iport; t=1457361159; x=1458570759; h=from:to:subject:date:message-id:mime-version; bh=VYX1vAtOYupglEnoZ5MxGIYVIELs+DRBab/iO64BY4Q=; b=W55iQfFgQdNMDrKU/X/+Jg+0nZtxCGsZZzT+XQ/VxRISEYY4Whk2qdfA JZ2RWcB4aucB13mGomVzTdidf53OOlf6UUFS1PEGjKsps2VWw3YAZo6ZZ 5M3IXD2v/Bzyk/AB+ejW2k2qpu4TEiriWDfhEEK/lSagaiy7K4YMjv29Y g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AQBpkN1W/4UNJK1cgm5MUm0GuCeCE?= =?us-ascii?q?wENgWkhhW6BKjgUAQEBAQEBAWQcC4RILV4BDCBUJgEEEwiIGg6gP55WAQEBAQE?= =?us-ascii?q?BBAEBAQEBAQEBFASGF4kkhA0FlyoBhWKIA48BjlQBHgEBQoNkaog/fgEBAQ?= X-IronPort-AV: E=Sophos; i="5.22,551,1449532800"; d="scan'208,217"; a="78466144" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Mar 2016 14:32:39 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u27EWdx1014253 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 7 Mar 2016 14:32:39 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 7 Mar 2016 08:32:38 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.009; Mon, 7 Mar 2016 08:32:38 -0600 From: "Eric Voit (evoit)" To: "netconf@ietf.org" Thread-Topic: YANG Subscriptions @ IETF 95 Hackathon Thread-Index: AdF4fh60A3JTmAKSSvSrJtuGkOCEtg== Date: Mon, 7 Mar 2016 14:32:38 +0000 Message-ID: <02c95201b1ca4701a6b18e57f0ec1ece@XCH-ALN-013.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.56.235] Content-Type: multipart/alternative; boundary="_000_02c95201b1ca4701a6b18e57f0ec1eceXCHALN013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] YANG Subscriptions @ IETF 95 Hackathon 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, 07 Mar 2016 14:32:41 -0000 --_000_02c95201b1ca4701a6b18e57f0ec1eceXCHALN013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OpenDaylight's latest release has a YANG PubSub client: https://wiki.opendaylight.org/view/YANG_PUBSUB:_Beryllium_User_Guide This allows a OpenDaylight to subscribe to existing YANG models as per draf= t-ietf-netconf-yang-push I am hoping to extend these capabilities in the IETF 95 Hackathon https://www.ietf.org/registration/MeetingWiki/wiki/95hackathon If anyone wants to join in, or if anyone wants to know more, let me know. Eric Eric Voit Principal Engineer evoit@cisco.com --_000_02c95201b1ca4701a6b18e57f0ec1eceXCHALN013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

OpenDaylight’s latest release has a YANG PubSu= b client:

https://wiki.opendaylight.org/view/YANG_PUBSUB= :_Beryllium_User_Guide

 

This allows a OpenDaylight to subscribe to existing = YANG models as per draft-ietf-netconf-yang-push

 

I am hoping to extend these capabilities in the IETF= 95 Hackathon

https://www.ietf.org/registration/MeetingWiki/wiki/9= 5hackathon

 

If anyone wants to join in, or if anyone wants to kn= ow more, let me know.

 

Eric

 

Eric V= oit

Princi= pal Engineer

evoit@= cisco.com

 

--_000_02c95201b1ca4701a6b18e57f0ec1eceXCHALN013ciscocom_-- From nobody Tue Mar 8 04:34:07 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D4412D695 for ; Tue, 8 Mar 2016 04:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPjoekaaebHi for ; Tue, 8 Mar 2016 04:34:05 -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 1FA6012D684 for ; Tue, 8 Mar 2016 04:34:05 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:28bc:9327:f9f1:f16f] (unknown [IPv6:2001:718:1a02:1:28bc:9327:f9f1:f16f]) by mail.nic.cz (Postfix) with ESMTPSA id 59216180316 for ; Tue, 8 Mar 2016 13:34:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1457440443; bh=aXKdQQrDZMS/9Xps9qZPy6zOBbcmvPovAjM7GZtCrcM=; h=From:Date:To; b=OgQty8d3WSDs0HqsoTiTe8W6w3fws+C14d6Y0fV+qZBfgdV+boH4VxD2+vbdZoHYg cnPoF2xzEmWa/UGYkC5nBRdrtz213IQ/bKQMEbK3w/3ZTFWzn4473//fnthyEMeog8 jlvtmm93nNd8Yd31AAku2iRu+dj8RODuW+2jJcHc= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <86BDAE09-9879-4497-A9A2-17E1B776A36F@nic.cz> Date: Tue, 8 Mar 2016 13:34:03 +0100 To: NETCONF WG Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Subject: [Netconf] RESTCONF 'api-path' production X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 12:34:06 -0000 Hi, if I am not missing something, the 'api-path' production in sec. 3.5.1.1 = of draft-ietf-netconf-restconf-09 doesn't permit a list to be at the top = of data hierarchy, which is possible. OLD api-path =3D "/" | ("/" api-identifier 0*("/" (api-identifier | list-instance ))) NEW api-path =3D "/" | 1*("/" (api-identifier | list-instance ))) Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Mar 8 06:22:18 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8717012D71B for ; Tue, 8 Mar 2016 06:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4ScUQ3_uvkz for ; Tue, 8 Mar 2016 06:22:14 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178CA12D6FF for ; Tue, 8 Mar 2016 06:22:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25826; q=dns/txt; s=iport; t=1457446933; x=1458656533; h=from:subject:to:message-id:date:mime-version; bh=zziChCUv80eZgMnmIXUWUT5UH4f3TRUe95B1kg4/PcU=; b=ahmFZxbpB3MHMIjIBFEePAQS5Nv3s8ZrwQZPG3svwUFQIz78hV9D0lTj QVaXvBSagu418hhhTNsOhV3LU0pdTgK4aeTu8Dc4HMagFATxfBUeMb9E5 U4Wlkxo3JFAL8vscNvBKp6yUDJbAgxlmbL3BsbA5iMmin9qOnbRqiGeyd 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQDi3t5W/xbLJq1cgm6BHm26TAENg?= =?us-ascii?q?WkhhW6BdxQBAQEBAQEBZBwLhGtVPRYBCgILAwIBAgFLDQgBAYggDp8Yj12PLAE?= =?us-ascii?q?BAQcBAQEBAQEWBIYXiGQCQ4JTgToFlyqBI4RAiAuBZIREgwKFUY5WHgEBQoIDG?= =?us-ascii?q?RSBNDwuAYhEgToBAQE?= X-IronPort-AV: E=Sophos;i="5.22,556,1449532800"; d="scan'208,217";a="669801422" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Mar 2016 14:22:10 +0000 Received: from [10.63.23.98] (dhcp-ensft1-uk-vla370-10-63-23-98.cisco.com [10.63.23.98]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u28EMAUc018540 for ; Tue, 8 Mar 2016 14:22:10 GMT From: Robert Wilton To: "netconf@ietf.org" Message-ID: <56DEE009.2070208@cisco.com> Date: Tue, 8 Mar 2016 14:22:01 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------010705040105060500050407" Archived-At: Subject: [Netconf] More restconf-09 comments/questions (edit collision detection and error handling) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 14:22:16 -0000 This is a multi-part message in MIME format. --------------010705040105060500050407 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I've a few more review comments/questions on restconf-09 as I've studied it a bit more closely over the last couple of days, particularly concerning edit collision detection and error handling. 1. General question: It looks like all the requests target resources without a trailing slash. Should the draft specify what behaviour is expected if the server receives a request with a trailing slash (e.g. probably redirect back to the version of the resource without a trailing slash). Personally, I think that not specifying this is probably fine - but thought it might be worth raising in case it hadn't been considered. 2. Section 3.4 Datastore Resource: Old: Configuration edit transaction management and configuration persistence are handled by the server and not controlled by the client. A datastore resource can only be written directly with the *PATCH *method. Each RESTCONF edit of a datastore resource is saved to non-volatile storage by the server. The last paragraph states that a datastore resource can only be written directly with the PATCH method. But section 4.4 indicates that POST is also allowed. Does this text need to be changed to allow for PATCH or POST? E.g new: Configuration edit transaction management and configuration persistence are handled by the server and not controlled by the client. A datastore resource can only be written directly with the *PATCH **or POST* methods. Each RESTCONF edit of a datastore resource is saved to non-volatile storage by the server. 3. Section 3.4.1 Edit Collision Detection (applies equally to the Timestamp and Entity tag): 3.4.1.1. Timestamp The last change time is maintained and the "Last-Modified" ([RFC7232], Section 2.2 ) header is returned in the response for a retrieval request. The "If-Unmodified-Since" header can be used in edit operation requests to cause the server to reject the request if the resource has been modified since the specified timestamp. The server MUST maintain a last-modified timestamp for the top-level {+restconf}/data resource and SHOULD maintain last-modified timestamps for descendant resources. For all resources, the server MUST return the "Last-Modified" header when the resource is retrieved with the GET or HEAD methods. If the server does not maintain a timestamp for a resource, it MUST return the timestamp of the resource's ancestor, a process that may recurse up to the top-level {+restconf}/data resource. Only changes to configuration data resources within the datastore affect the timestamp. i) Do the timestamp and entity tag appear to apply to both config and non config resources, or is it just config resources? ii) If it is just config resources then please can sections 3.4.1.1 and 3.4.1.2 be updated to make this clear. iii) If it both config and non config resources, then it is unclear to me what the exact semantics for non config resources are expected to be? (Based on the description in section 3.5 - I can elaborate if needs be) 4. Section 3.5 Data Resource. To be consistent with 3.4.1.1 and 3.4.1.2, I think that the MAY should change to SHOULD: I.e. old: For configuration data resources, the server*MAY *maintain a last- modified timestamp for the resource, and return the "Last-Modified" header when it is retrieved with the GET or HEAD methods. ... new: For configuration data resources, the server*SHOULD *maintain a last- modified timestamp for the resource, and return the "Last-Modified" header when it is retrieved with the GET or HEAD methods. ... Likewise for entity tag: old: For configuration data resources, the server*MAY *maintain a resource entity tag for the resource, and return the "ETag" header when it is retrieved as the target resource with the GET or HEAD methods. new: For configuration data resources, the server*SHOULD *maintain a resource entity tag for the resource, and return the "ETag" header when it is retrieved as the target resource with the GET or HEAD methods. 5. Section 3.5 Data Resource, last paragraph. I didn't understand what the last paragraph means, or what it relevance is: The resource definition version for a data resource is identified by the revision date of the YANG module containing the YANG definition for the data resource. 6. Section 4.1. OPTIONS: The OPTIONS method is sent by the client to discover which methods are supported by the server for a specific resource (e.g., GET, POST, DELETE, etc.). The server SHOULD implement this method, however the same information could be extracted from the YANG modules and the RESTCONF protocol specification. What body text (if any) should be returned for OPTIONS requests? If body text is returned then what media type should it use? E.g. RFC 7231, section 4.3.7 "options" indicates that the body might contain a human readable description. 7. Section 4.3 GET, first paragraph: The GET method is sent by the client to retrieve data and meta-data for a resource. It is supported for all resource types, except operation resources. The request MUST contain a request URI that contains at least the entry point. It isn't clear to me what the last sentence is trying to say - I'm not sure exactly what is meant by "entry point". 8. Section 5.1 last but one paragraph. Should the "MUST" be changed to "can"? old: When new resources are created by the client, a "Location" header is returned, which identifies the path of the newly created resource. The client*MUST *use this exact path identifier to access the resource once it has been created. new: When new resources are created by the client, a "Location" header is returned, which identifies the path of the newly created resource. The client*can *use this exact path identifier to access the resource once it has been created. 9. Section 7.1 Error Response message: When an error occurs for a request message on a*data *resource or an operation resource, and a "4xx" class of status codes (except for status code "403 Forbidden"), then the server SHOULD send a response message-body containing the information described by the "errors" container definition within the YANG moduleSection 8 . The Content- Type of this response message MUST be application/yang.errors (see example below). The client*MAY *specify the desired encoding for error messages by specifying the appropriate media-type in the Accept header.*If no error media is specified, then the media type of the request message is used. If there is no request message the server* MUST select "application/yang.errors+xml" or "application/yang.errors+json", depending on server preference. All of the examples in this document, except for the one below, assume that XML encoding will be returned if there is an error. i) The beginning of the error paragraph makes the description conditional on the request message being on a data resource. Should this cover other resource types as well, or otherwise what is the error handling strategy for other resource types? ii) Should the last sentence of the first paragraph be "Type of this response message MUST be a subtype of application/yang.errors (see example below). "? iii) Would it be wise to indicate that the client SHOULD specify desired encoding for error messages? iv) The second paragraph states "If no error media is specified, then the media type of the request message is used. " but this directly conflicts with "The Content- Type of this response message MUST be application/yang.errors (see example below). " v) "If there is no request message the server ..." - I would think that there must always be a request message. In summary, what about this text instead: When an error occurs for a request message on an*api, data,****datastore, or operation resource*, and a "4xx" class of status codes (except for status code "403 Forbidden"), then the server SHOULD send a response message-body containing the information described by the "errors" container definition within the YANG moduleSection 8 . The Content-Type of this response message MUST be*a subtype* of application/yang.errors (see example below). The client*SHOULD *specify the desired encoding for error messages by specifying the appropriate media-type in the Accept header.*If no error media-type is specified, then the server SHOULD choose an****error media-type encoding (XML or JSON) that is consistent to what would have**been used if the request succeeded. If the client did not specify**any particular media type in the Accept header then the server* MUST select "application/yang.errors+xml" or "application/yang.errors+json", depending on server preference. All of the examples in this document, except for the one below, assume that XML encoding will be returned if there is an error. Thanks, Rob --------------010705040105060500050407 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi,

I've a few more review comments/questions on restconf-09 as I've studied it a bit more closely over the last couple of days, particularly concerning edit collision detection and error handling.


1. General question:  It looks like all the requests target resources without a trailing slash. Should the draft specify what behaviour is expected if the server receives a request with a trailing slash (e.g. probably redirect back to the version of the resource without a trailing slash).  Personally, I think that not specifying this is probably fine - but thought it might be worth raising in case it hadn't been considered.


2. Section 3.4 Datastore Resource:
Old:
   Configuration edit transaction management and configuration
   persistence are handled by the server and not controlled by the
   client.  A datastore resource can only be written directly with the
   PATCH method.  Each RESTCONF edit of a datastore resource is saved to
   non-volatile storage by the server.

The last paragraph states that a datastore resource can only be written directly with the PATCH method.  But section 4.4 indicates that POST is also allowed.  Does this text need to be changed to allow for PATCH or POST?

E.g new: 
   Configuration edit transaction management and configuration
   persistence are handled by the server and not controlled by the
   client.  A datastore resource can only be written directly with the
   PATCH or POST methods.  Each RESTCONF edit of a datastore resource is
   saved to non-volatile storage by the server.


3. Section 3.4.1 Edit Collision Detection (applies equally to the Timestamp and Entity tag):
3.4.1.1.  Timestamp
   The last change time is maintained and the "Last-Modified"
   ([RFC7232], Section 2.2) header is returned in the response for a
   retrieval request.  The "If-Unmodified-Since" header can be used in
   edit operation requests to cause the server to reject the request if
   the resource has been modified since the specified timestamp.

   The server MUST maintain a last-modified timestamp for the top-level
   {+restconf}/data resource and SHOULD maintain last-modified
   timestamps for descendant resources.  For all resources, the server
   MUST return the "Last-Modified" header when the resource is retrieved
   with the GET or HEAD methods.  If the server does not maintain a
   timestamp for a resource, it MUST return the timestamp of the
   resource's ancestor, a process that may recurse up to the top-level
   {+restconf}/data resource.  Only changes to configuration data
   resources within the datastore affect the timestamp.

 i) Do the timestamp and entity tag appear to apply to both config and non config resources, or is it just config resources?
 ii) If it is just config resources then please can sections 3.4.1.1 and 3.4.1.2 be updated to make this clear.
 iii) If it both config and non config resources, then it is unclear to me what the exact semantics for non config resources are expected to be?  (Based on the description in section 3.5 - I can elaborate if needs be)


4. Section 3.5 Data Resource.
To be consistent with 3.4.1.1 and 3.4.1.2, I think that the MAY should change to SHOULD:

I.e. old:
   For configuration data resources, the server MAY maintain a last-
   modified timestamp for the resource, and return the "Last-Modified"
   header when it is retrieved with the GET or HEAD methods. ...
new: 
   For configuration data resources, the server SHOULD maintain a last-
   modified timestamp for the resource, and return the "Last-Modified"
   header when it is retrieved with the GET or HEAD methods. ...

Likewise for entity tag:
old:
   For configuration data resources, the server MAY maintain a resource
   entity tag for the resource, and return the "ETag" header when it is
   retrieved as the target resource with the GET or HEAD methods.

new:
   For configuration data resources, the server SHOULD maintain a resource
   entity tag for the resource, and return the "ETag" header when it is
   retrieved as the target resource with the GET or HEAD methods.


5. Section 3.5 Data Resource, last paragraph.
I didn't understand what the last paragraph means, or what it relevance is:
   The resource definition version for a data resource is identified by
   the revision date of the YANG module containing the YANG definition
   for the data resource.


6. Section 4.1. OPTIONS:
   The OPTIONS method is sent by the client to discover which methods
   are supported by the server for a specific resource (e.g., GET, POST,
   DELETE, etc.).

   The server SHOULD implement this method, however the same information
   could be extracted from the YANG modules and the RESTCONF protocol
   specification.


What body text (if any) should be returned for OPTIONS requests?  If body text is returned then what media type should it use?

E.g. RFC 7231, section 4.3.7 "options" indicates that the body might contain a human readable description.


7. Section 4.3 GET, first paragraph:
   The GET method is sent by the client to retrieve data and meta-data
   for a resource.  It is supported for all resource types, except
   operation resources.  The request MUST contain a request URI that
   contains at least the entry point.
It isn't clear to me what the last sentence is trying to say - I'm not sure exactly what is meant by "entry point".


8. Section 5.1 last but one paragraph.  Should the "MUST" be changed to "can"?

old:
   When new resources are created by the client, a "Location" header is
   returned, which identifies the path of the newly created resource.
   The client MUST use this exact path identifier to access the resource
   once it has been created.

new:
   When new resources are created by the client, a "Location" header is
   returned, which identifies the path of the newly created resource.
   The client can use this exact path identifier to access the resource
   once it has been created.


9. Section 7.1 Error Response message:
   When an error occurs for a request message on a data resource or an
   operation resource, and a "4xx" class of status codes (except for
   status code "403 Forbidden"), then the server SHOULD send a response
   message-body containing the information described by the "errors"
   container definition within the YANG module Section 8.  The Content-
   Type of this response message MUST be application/yang.errors (see
   example below).

   The client MAY specify the desired encoding for error messages by
   specifying the appropriate media-type in the Accept header.  If no
   error media is specified, then the media type of the request message
   is used.  If there is no request message the server MUST select
   "application/yang.errors+xml" or "application/yang.errors+json",
   depending on server preference.  All of the examples in this
   document, except for the one below, assume that XML encoding will be
   returned if there is an error.

i) The beginning of the error paragraph makes the description conditional on the request message being on a data resource.  Should this cover other resource types as well, or otherwise what is the error handling strategy for other resource types?
ii) Should the last sentence of the first paragraph be "Type of this response message MUST be a subtype of application/yang.errors (see example below). "?
iii) Would it be wise to indicate that the client SHOULD specify desired encoding for error messages?
iv) The second paragraph states "If no error media is specified, then the media type of the request message is used. " but this directly conflicts with "The Content- Type of this response message MUST be application/yang.errors (see example below). "
v) "If there is no request message the server ..." - I would think that there must always be a request message.

In summary, what about this text instead:
   When an error occurs for a request message on an api, data,
   datastore, or operation resource, and a "4xx" class of status
   codes (except for status code "403 Forbidden"), then the server
   SHOULD send a response message-body containing the information
   described by the "errors" container definition within the YANG
   module Section 8.  The Content-Type of this response message MUST
   be a subtype of application/yang.errors (see example below).

   The client SHOULD specify the desired encoding for error messages by
   specifying the appropriate media-type in the Accept header.  If no
   error media-type is specified, then the server SHOULD choose an
   error media-type encoding (XML or JSON) that is consistent to what
   would have been used if the request succeeded.  If the client did not
   specify any particular media type in the Accept header then the server MUST
   select "application/yang.errors+xml" or "application/yang.errors+json",
   depending on server preference.  All of the examples in this
   document, except for the one below, assume that XML encoding will be
   returned if there is an error.

Thanks,
Rob
--------------010705040105060500050407-- From nobody Tue Mar 8 06:37:19 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9797F12D6BC for ; Tue, 8 Mar 2016 06:37:18 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_BAg_EVnqAs for ; Tue, 8 Mar 2016 06:37:16 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3674912D587 for ; Tue, 8 Mar 2016 06:37:16 -0800 (PST) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id A7EFC1AE0144; Tue, 8 Mar 2016 15:37:14 +0100 (CET) Date: Tue, 08 Mar 2016 15:37:14 +0100 (CET) Message-Id: <20160308.153714.985891161709063674.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <56D9C17E.90004@cisco.com> 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-09 comments X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 14:37:18 -0000 Andy Bierman wrote: > On Fri, Mar 4, 2016 at 9:10 AM, Robert Wilton wrote: > > > Hi Andy, > > > > On 04/03/2016 15:29, Andy Bierman wrote: > > > > > > > > On Fri, Mar 4, 2016 at 6:16 AM, Robert Wilton wrote: > > > >> Hi, > >> > >> I appreciate that this is a while after the last call, but when reading > >> restconf-09, I had a few minor comments (which may have already been > >> pointed out by others previously). > >> > >> 1. Regarding "4.8.1. The "content" Query Parameter": > >> > >> The default value is determined by the "config" statement value of > >> the requested data nodes. If the "config" value is "false", then the > >> default for the "content" parameter is "nonconfig". If "config" is > >> "true" then the default for the "content" parameter is "config". > >> > >> > >> I was surprised so see that the default value wasn't just "all", > >> - "all" felt like a more obvious default choice, i.e. don't filter the > >> result unless explicitly asked to. > >> - it means the behaviour is consistent whether a GET request is made on > >> the top-level datastore URI or any child node underneath the root. > >> - it is easier to document/explain/understand (and possibly implement). > >> - It is the same regardless for nonconfig anyway, so would only affect > >> the default behaviour for config nodes anyway. > >> > >> > > > > The default will be 'all' if the target resource is the datastore itself. > > > > Yes. As above, that is one of the reasons why I think that it would be > > better if the default is "all" for any nodes within the datastore itself as > > well. It makes it more consistent. > > > > > > > > Is there is WG consensus to make this change? > What do others think? > > OLD: (text cited above in 4.8.1) > > NEW: The default value is 'all'. > > > This means that in order to do a "get-config" the content=config parameter > always has to be used. > The current solution is optimized for configuration data nodes. I think I agree with Rob that it would be more consistent to use 'all' as the default value. If we wanted to optimize for config, we should probably have used 'config' as the default also for the datastore resource. /martin > > > > > > > > >> > >> 2. The "D.1.1. Retrieve the Top-level API Resource" example looked > >> slightly wrong to me. from the RESTCONF module definition in section 8 I > >> would expect the data and operations container to be empty JSON objects. > >> > >> OLD: > >> > >> The server might respond as follows: > >> > >> HTTP/1.1 200 OK > >> Date: Mon, 23 Apr 2012 17:01:00 GMT > >> Server: example-server > >> Content-Type: application/yang.api+json > >> > >> { > >> "ietf-restconf:restconf": {* "data" : [ null ], > >> "operations" : [ null ]* > >> } > >> } > >> > >> > >> NEW: > >> > >> The server might respond as follows: > >> > >> HTTP/1.1 200 OK > >> Date: Mon, 23 Apr 2012 17:01:00 GMT > >> Server: example-server > >> Content-Type: application/yang.api+json > >> > >> { > >> "ietf-restconf:restconf": {* "data" : { }, > >> "operations" : { }* > >> } > >> } > >> > >> > > > > I think the text says the API resource is returned which includes these > > 2 child nodes, also application/yang.api > > > > Section 3.3. API Resource states: > > > > The "application/yang.api" restconf-media-type extension in the > > "ietf-restconf" module defined in Section 8 is used to specify the > > structure and syntax of the conceptual child resources within the API > > resource. > > > > > > Section 8 gives a YANG module that has data and operations as containers. > > I can't obviously see any text which states that these two containers > > should be represented as two leaves of type empty instead of a JSON > > interpretation of the YANG module definition. So I still believe that > > either the textual description or the example needs to be fixed. > > > > > > OK -- I will try to fix the module definition > > > > > > Thanks, > > Rob > > > > > > > > Andy > > > > > > > > > >> > >> 3. In "D.1.3. Retrieve The Server Capability Information", the example > >> is XML rather than JSON. > >> > >> OLD: > >> > >> In this example the client is retrieving the capability information > >> from the server in *JSON *format, and the server supports all the > >> RESTCONF query parameters, plus one vendor parameter: > >> > >> NEW: > >> In this example the client is retrieving the capability information > >> from the server in *XML *format, and the server supports all the > >> RESTCONF query parameters, plus one vendor parameter: > >> > >> > >> > > OK > > > > > >> > >> Rob > >> > >> > > Andy > > > > > >> > >> _______________________________________________ > >> Netconf mailing list > >> Netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > >> > >> > > > > From nobody Tue Mar 8 08:18:23 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295BA12D579 for ; Tue, 8 Mar 2016 08:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAn97CEV2ULC for ; Tue, 8 Mar 2016 08:18:19 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::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 F0BF512D798 for ; Tue, 8 Mar 2016 08:18:18 -0800 (PST) Received: by mail-lb0-x234.google.com with SMTP id x1so25281627lbj.3 for ; Tue, 08 Mar 2016 08:18: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; bh=y/0mvxrXeoaDH8I3eTOEBo5397/UuTCEeIP/1E02ukQ=; b=MbtFV2pvUpRxDzlnqplqdeX989hOXsuOFFlJatF82BoqQRpVKwCpRqAHbIehcGKn4j u6TlvpWHVfc/QC8WuYEuboZ77XchY5q4UYvSotxE6c+k+Pn236OHlpbhvS++YgPuj7xz 4vHx4F1gsgMt0gfJpYytnl8y8rDDcA6CbU6NbxPk3pq0/EPqb44kdFYBXTpVijQxmYWU Nt5WaFSylWVDHSl7aiDpdz3lCdjRGPXoU6rF4J2BXFCHItCWbE3GpHGd4TFHBL/uYsNA 3HtoCkHRtp6R5bTSL2SkX31p9XivGPiEXS/q5bKkqwQyBFXaW0XMCnssAWOlYKNScN8m XQuw== 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; bh=y/0mvxrXeoaDH8I3eTOEBo5397/UuTCEeIP/1E02ukQ=; b=QAKliTg+yUYN00YkyxQox34hLCqUlAUYPYexiWw40xjZFCfw2PC+Axr8gMjRmvXxUO /rBSV5SP5C58QRJIgQcV591snGctrDNhzMlkB0azISGXoUjRop4ciWGSdZKTdYAzkdmx lRBMwkYdFMvk0rAIyDBpTAuXYFYfePk8EdjOmaELqBQqShesVKkB298oRMtyn/ZztfPj rcZYlkYPUb4pqTRDe0Ctv+TVH7mh3ZTsNvEwBtG5X/0V5wQoSWOHiJnIBCbdZhaaYCgk rE4xsVLsbdtaFD3bGOdhJWiGchuNU4jku25zgnDF9GaqmibhOs8Pol8sYKbGKSvbI4dR eUVg== X-Gm-Message-State: AD7BkJLltBkV6q6SakkRdw5Yp0NDVUkFXHihNHrkR4oWNdkCK1zsY6GVhL9w/HNQpxuoEZwx4iUpyUcNdUz+fg== MIME-Version: 1.0 X-Received: by 10.25.30.73 with SMTP id e70mr10112128lfe.13.1457453897160; Tue, 08 Mar 2016 08:18:17 -0800 (PST) Received: by 10.112.132.65 with HTTP; Tue, 8 Mar 2016 08:18:16 -0800 (PST) In-Reply-To: <20160308.153714.985891161709063674.mbj@tail-f.com> References: <56D9C17E.90004@cisco.com> <20160308.153714.985891161709063674.mbj@tail-f.com> Date: Tue, 8 Mar 2016 08:18:16 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11402758d13167052d8bedc0 Archived-At: Cc: Netconf Subject: Re: [Netconf] restconf-09 comments X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 16:18:22 -0000 --001a11402758d13167052d8bedc0 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 8, 2016 at 6:37 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Fri, Mar 4, 2016 at 9:10 AM, Robert Wilton wrote: > > > > > Hi Andy, > > > > > > On 04/03/2016 15:29, Andy Bierman wrote: > > > > > > > > > > > > On Fri, Mar 4, 2016 at 6:16 AM, Robert Wilton > wrote: > > > > > >> Hi, > > >> > > >> I appreciate that this is a while after the last call, but when > reading > > >> restconf-09, I had a few minor comments (which may have already been > > >> pointed out by others previously). > > >> > > >> 1. Regarding "4.8.1. The "content" Query Parameter": > > >> > > >> The default value is determined by the "config" statement value of > > >> the requested data nodes. If the "config" value is "false", then > the > > >> default for the "content" parameter is "nonconfig". If "config" is > > >> "true" then the default for the "content" parameter is "config". > > >> > > >> > > >> I was surprised so see that the default value wasn't just "all", > > >> - "all" felt like a more obvious default choice, i.e. don't filter > the > > >> result unless explicitly asked to. > > >> - it means the behaviour is consistent whether a GET request is made > on > > >> the top-level datastore URI or any child node underneath the root. > > >> - it is easier to document/explain/understand (and possibly > implement). > > >> - It is the same regardless for nonconfig anyway, so would only > affect > > >> the default behaviour for config nodes anyway. > > >> > > >> > > > > > > The default will be 'all' if the target resource is the datastore > itself. > > > > > > Yes. As above, that is one of the reasons why I think that it would be > > > better if the default is "all" for any nodes within the datastore > itself as > > > well. It makes it more consistent. > > > > > > > > > > > > > Is there is WG consensus to make this change? > > What do others think? > > > > OLD: (text cited above in 4.8.1) > > > > NEW: The default value is 'all'. > > > > > > This means that in order to do a "get-config" the content=config > parameter > > always has to be used. > > The current solution is optimized for configuration data nodes. > > I think I agree with Rob that it would be more consistent to use 'all' > as the default value. If we wanted to optimize for config, we should > probably have used 'config' as the default also for the datastore > resource. > > OK with me -- this solves the problem where "fields" contains nonconfig nodes. > > /martin > > Andy > > > > > > > > > > > > > > > >> > > >> 2. The "D.1.1. Retrieve the Top-level API Resource" example looked > > >> slightly wrong to me. from the RESTCONF module definition in > section 8 I > > >> would expect the data and operations container to be empty JSON > objects. > > >> > > >> OLD: > > >> > > >> The server might respond as follows: > > >> > > >> HTTP/1.1 200 OK > > >> Date: Mon, 23 Apr 2012 17:01:00 GMT > > >> Server: example-server > > >> Content-Type: application/yang.api+json > > >> > > >> { > > >> "ietf-restconf:restconf": {* "data" : [ null ], > > >> "operations" : [ null ]* > > >> } > > >> } > > >> > > >> > > >> NEW: > > >> > > >> The server might respond as follows: > > >> > > >> HTTP/1.1 200 OK > > >> Date: Mon, 23 Apr 2012 17:01:00 GMT > > >> Server: example-server > > >> Content-Type: application/yang.api+json > > >> > > >> { > > >> "ietf-restconf:restconf": {* "data" : { }, > > >> "operations" : { }* > > >> } > > >> } > > >> > > >> > > > > > > I think the text says the API resource is returned which includes these > > > 2 child nodes, also application/yang.api > > > > > > Section 3.3. API Resource states: > > > > > > The "application/yang.api" restconf-media-type extension in the > > > "ietf-restconf" module defined in Section 8 < > https://tools.ietf.org/html/draft-ietf-netconf-restconf-09#section-8> is > used to specify the > > > structure and syntax of the conceptual child resources within the > API > > > resource. > > > > > > > > > Section 8 gives a YANG module that has data and operations as > containers. > > > I can't obviously see any text which states that these two containers > > > should be represented as two leaves of type empty instead of a JSON > > > interpretation of the YANG module definition. So I still believe that > > > either the textual description or the example needs to be fixed. > > > > > > > > > > OK -- I will try to fix the module definition > > > > > > > > > > > Thanks, > > > Rob > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > >> > > >> 3. In "D.1.3. Retrieve The Server Capability Information", the > example > > >> is XML rather than JSON. > > >> > > >> OLD: > > >> > > >> In this example the client is retrieving the capability information > > >> from the server in *JSON *format, and the server supports all the > > >> RESTCONF query parameters, plus one vendor parameter: > > >> > > >> NEW: > > >> In this example the client is retrieving the capability information > > >> from the server in *XML *format, and the server supports all the > > >> RESTCONF query parameters, plus one vendor parameter: > > >> > > >> > > >> > > > OK > > > > > > > > >> > > >> Rob > > >> > > >> > > > Andy > > > > > > > > >> > > >> _______________________________________________ > > >> Netconf mailing list > > >> Netconf@ietf.org > > >> https://www.ietf.org/mailman/listinfo/netconf > > >> > > >> > > > > > > > --001a11402758d13167052d8bedc0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 8, 2016 at 6:37 AM, Martin Bjorklund <= mbj@tail-f.com><= /span> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Fri, Mar 4, 2016 at 9:10 AM, Robert Wilton <rwilton@cisco.com> wrote:
>
> > Hi Andy,
> >
> > On 04/03/2016 15:29, Andy Bierman wrote:
> >
> >
> >
> > On Fri, Mar 4, 2016 at 6:16 AM, Robert Wilton <rwilton@cisco.com> wrote:
> >
> >> Hi,
> >>
> >> I appreciate that this is a while after the last call, but wh= en reading
> >> restconf-09, I had a few minor comments (which may have alrea= dy been
> >> pointed out by others previously).
> >>
> >> 1. Regarding "4.8.1.=C2=A0 The "content" Query= Parameter":
> >>
> >>=C2=A0 =C2=A0 The default value is determined by the "con= fig" statement value of
> >>=C2=A0 =C2=A0 the requested data nodes.=C2=A0 If the "con= fig" value is "false", then the
> >>=C2=A0 =C2=A0 default for the "content" parameter is= "nonconfig".=C2=A0 If "config" is
> >>=C2=A0 =C2=A0 "true" then the default for the "= content" parameter is "config".
> >>
> >>
> >> I was surprised so see that the default value wasn't just= "all",
> >>=C2=A0 - "all" felt like a more obvious default choi= ce, i.e. don't filter the
> >> result unless explicitly asked to.
> >>=C2=A0 - it means the behaviour is consistent whether a GET re= quest is made on
> >> the top-level datastore URI or any child node underneath the = root.
> >>=C2=A0 - it is easier to document/explain/understand (and poss= ibly implement).
> >>=C2=A0 - It is the same regardless for nonconfig anyway, so wo= uld only affect
> >> the default behaviour for config nodes anyway.
> >>
> >>
> >
> > The default will be 'all' if the target resource is the d= atastore itself.
> >
> > Yes.=C2=A0 As above, that is one of the reasons why I think that = it would be
> > better if the default is "all" for any nodes within the= datastore itself as
> > well.=C2=A0 It makes it more consistent.
> >
> >
> >
>
> Is there is WG consensus to make this change?
> What do others think?
>
> OLD:=C2=A0 (text cited above in 4.8.1)
>
> NEW: The default value is 'all'.
>
>
> This means that in order to do a "get-config" the content=3D= config parameter
> always has to be used.
> The current solution is optimized for configuration data nodes.

I think I agree with Rob that it would be more consistent to use 'all&#= 39;
as the default value.=C2=A0 If we wanted to optimize for config, we should<= br> probably have used 'config' as the default also for the datastore resource.


OK with me -- this solves the problem = where "fields" contains nonconfig nodes.

=C2=A0

/martin


Andy
=C2=A0

>
>
>
> >
> >
> >>
> >> 2. The "D.1.1.=C2=A0 Retrieve the Top-level API Resource= " example looked
> >> slightly wrong to me.=C2=A0 from the=C2=A0 RESTCONF module de= finition in section 8 I
> >> would expect the data and operations container to be empty JS= ON objects.
> >>
> >> OLD:
> >>
> >>=C2=A0 =C2=A0 The server might respond as follows:
> >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0HTTP/1.1 200 OK
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date: Mon, 23 Apr 2012 17:01:00 GMT=
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0Server: example-server
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0Content-Type: application/yang.api+= json
> >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0{
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"ietf-restconf:restconf= ": {*=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "data" : [ null ], > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"operations"= ; : [ null ]*
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >>
> >>
> >> NEW:
> >>
> >>=C2=A0 =C2=A0 The server might respond as follows:
> >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0HTTP/1.1 200 OK
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date: Mon, 23 Apr 2012 17:01:00 GMT=
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0Server: example-server
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0Content-Type: application/yang.api+= json
> >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0{
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"ietf-restconf:restconf= ": {*=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "data" : { },
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"operations"= ; : { }*
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
> >>
> >>
> >
> > I think the text says the API resource is returned which includes= these
> > 2 child nodes, also application/yang.api
> >
> > Section 3.3.=C2=A0 API Resource states:
> >
> >=C2=A0 =C2=A0 The "application/yang.api" restconf-media-= type extension in the
> >=C2=A0 =C2=A0 "ietf-restconf" module defined in Section = 8 <https://tools.ietf.org/htm= l/draft-ietf-netconf-restconf-09#section-8> is used to specify the > >=C2=A0 =C2=A0 structure and syntax of the conceptual child resourc= es within the API
> >=C2=A0 =C2=A0 resource.
> >
> >
> > Section 8 gives a YANG module that has data and operations as con= tainers.
> > I can't obviously see any text which states that these two co= ntainers
> > should be represented as two leaves of type empty instead of a JS= ON
> > interpretation of the YANG module definition.=C2=A0 So I still be= lieve that
> > either the textual description or the example needs to be fixed.<= br> > >
> >
>
> OK -- I will try to fix the module definition
>
>
>
>
> > Thanks,
> > Rob
> >
> >
> >
>
> Andy
>
>
> >
> >
> >
> >>
> >> 3. In "D.1.3.=C2=A0 Retrieve The Server Capability Infor= mation", the example
> >> is XML rather than JSON.
> >>
> >> OLD:
> >>
> >>=C2=A0 =C2=A0 In this example the client is retrieving the cap= ability information
> >>=C2=A0 =C2=A0 from the server in *JSON *format, and the server= supports all the
> >>=C2=A0 =C2=A0 RESTCONF query parameters, plus one vendor param= eter:
> >>
> >> NEW:
> >>=C2=A0 =C2=A0 In this example the client is retrieving the cap= ability information
> >>=C2=A0 =C2=A0 from the server in *XML *format, and the server = supports all the
> >>=C2=A0 =C2=A0 RESTCONF query parameters, plus one vendor param= eter:
> >>
> >>
> >>
> > OK
> >
> >
> >>
> >> Rob
> >>
> >>
> > Andy
> >
> >
> >>
> >> _______________________________________________
> >> Netconf mailing list
> >> Netconf@ietf.org
> >> https://www.ietf.org/mailman/listinfo/net= conf
> >>
> >>
> >
> >

--001a11402758d13167052d8bedc0-- From nobody Wed Mar 9 14:39:18 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B89612D6C6 for ; Wed, 9 Mar 2016 14:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzvaEO4A9sf1 for ; Wed, 9 Mar 2016 14:39:13 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::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 5ED8B12D7AE for ; Wed, 9 Mar 2016 14:38:38 -0800 (PST) Received: by mail-lb0-x234.google.com with SMTP id k15so87949843lbg.0 for ; Wed, 09 Mar 2016 14:38:38 -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; bh=YRshJemvC/gNnPrPmeJJ4wRNTtbWg5gPq6B23riSf80=; b=BjUp+FQ/CFCJH37uDk9Aw1tryA955KRO9zzNgqsGn5xJQo4hjVyqtJSFPXKmhCLeXA izFHXYTIZZO/9wOv09HogjdmsNVAN8IMzTja6Qmh9pjCdrBwMKUXVnoiAOP++rfr1+0T wnfQCZ2XCdHK0XUnH+Ra5W5VHsJLyXomIZmLvrGZBCOs3BqZv+wsdpGO5x9mOoHtZjvN 66A/Tx9AHMacUFX4odjchLMK0PZMd0RuywvtvwSt0kaUvh3FA0QgIRW7US8qBlBtoQ99 PnlMk2VaALpzhZ8gE5WVoX690mWmUiST9Gdt9sbyZ9K3fqvonGsInxI/1Kbxs3kHoqX4 95yw== 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; bh=YRshJemvC/gNnPrPmeJJ4wRNTtbWg5gPq6B23riSf80=; b=J6UwLXzkfFO2WUIu8VU1UZhmfIOqZVsXjoZyhyjnC8lBuilSq+038uf9l97xnAIess 9LQKnKi/+KivwdhDHg8Uu9GGHvXlMZzGBhX891NpDUYaJwQ3YoymMWx1hsUrgQxjpmdQ H7qnNgKVvjlotYGj1N3hhYbi0Fn0nfYCtFMOhp7eXukWIdQBI0eLtvwkcYIHChKld03b +GyuxLDqp8EpICWmkymJg1HRpUQaeY3POt1PrsogErUH4VEeK3HIcuYRFcLafs+p6Sdv WvOSQ8PWHv50avPmWi0m6Fpa6AUtEkV5vCvhk10GcdUZRuGCayDpc4ezGTZrm4oKaiMF Uldg== X-Gm-Message-State: AD7BkJK1RBeuzX3tWiGboCLLu89pP+TgSfd9XRjrZynjII7e+fiKPHkIG8MaB8AR179q0L3U6YuNTsN6jp7GVQ== MIME-Version: 1.0 X-Received: by 10.25.158.72 with SMTP id h69mr74406lfe.8.1457563116593; Wed, 09 Mar 2016 14:38:36 -0800 (PST) Received: by 10.112.132.65 with HTTP; Wed, 9 Mar 2016 14:38:35 -0800 (PST) In-Reply-To: <56D998AD.8040703@cisco.com> References: <56D998AD.8040703@cisco.com> Date: Wed, 9 Mar 2016 14:38:35 -0800 Message-ID: From: Andy Bierman To: Robert Wilton Content-Type: multipart/alternative; boundary=001a11401b3ccd7d39052da55b05 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] restconf-09 comments X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 22:39:16 -0000 --001a11401b3ccd7d39052da55b05 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 4, 2016 at 6:16 AM, Robert Wilton wrote: > Hi, > > I appreciate that this is a while after the last call, but when reading > restconf-09, I had a few minor comments (which may have already been > pointed out by others previously). > > 1. Regarding "4.8.1. The "content" Query Parameter": > > The default value is determined by the "config" statement value of > the requested data nodes. If the "config" value is "false", then the > default for the "content" parameter is "nonconfig". If "config" is > "true" then the default for the "content" parameter is "config". > > > I was surprised so see that the default value wasn't just "all", > - "all" felt like a more obvious default choice, i.e. don't filter the > result unless explicitly asked to. > - it means the behaviour is consistent whether a GET request is made on > the top-level datastore URI or any child node underneath the root. > - it is easier to document/explain/understand (and possibly implement). > - It is the same regardless for nonconfig anyway, so would only affect > the default behaviour for config nodes anyway. > > Added issue 53, now in edit state (changed default to "all") https://github.com/netconf-wg/restconf/issues/53 > > 2. The "D.1.1. Retrieve the Top-level API Resource" example looked > slightly wrong to me. from the RESTCONF module definition in section 8 I > would expect the data and operations container to be empty JSON objects. > > OLD: > > The server might respond as follows: > > HTTP/1.1 200 OK > Date: Mon, 23 Apr 2012 17:01:00 GMT > Server: example-server > Content-Type: application/yang.api+json > > { > "ietf-restconf:restconf": {* "data" : [ null ], > "operations" : [ null ]* > } > } > > > NEW: > > The server might respond as follows: > > HTTP/1.1 200 OK > Date: Mon, 23 Apr 2012 17:01:00 GMT > Server: example-server > Content-Type: application/yang.api+json > > { > "ietf-restconf:restconf": {* "data" : { }, > "operations" : { }* > } > } > > > Added new issue 54, still open; need to check the JSON draft https://github.com/netconf-wg/restconf/issues/54 > 3. In "D.1.3. Retrieve The Server Capability Information", the example is > XML rather than JSON. > > OLD: > > In this example the client is retrieving the capability information > from the server in *JSON *format, and the server supports all the > RESTCONF query parameters, plus one vendor parameter: > > NEW: > In this example the client is retrieving the capability information > from the server in *XML *format, and the server supports all the > RESTCONF query parameters, plus one vendor parameter: > > > > Fixed > Rob > > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a11401b3ccd7d39052da55b05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 4, 2016 at 6:16 AM, Robert Wilton <rwilton@cisco.com&g= t; wrote:
=20 =20 =20
Hi,

I appreciate that this is a while after the last call, but when reading restconf-09, I had a few minor comments (which may have already been pointed out by others previously).

1. Regarding "4.8.1.=C2=A0 The "content" Query Parameter= ":
   The default value is determined by the &=
quot;config" statement value of
   the requested data nodes.  If the "config" value is "fals=
e", then the
   default for the "content" parameter is "nonconfig". =
 If "config" is
   "true" then the default for the "content" parameter =
is "config".

I was surprised so see that the default value wasn't just "all= ",
=C2=A0- "all" felt like a more obvious default choice, i.e. d= on't filter the result unless explicitly asked to.
=C2=A0- it means the behaviour is consistent whether a GET request is made on the top-level datastore URI or any child node underneath the root.
=C2=A0- it is easier to document/explain/understand (and possibly implement).
=C2=A0- It is the same regardless for nonconfig anyway, so would only affect the default behaviour for config nodes anyway.


Added issue 53, now in edit = state (changed default to "all")


=C2=A0

2. The "D.1.1.=C2=A0 Retrieve the Top-level API Resource" exa= mple looked slightly wrong to me.=C2=A0 from the=C2=A0 RESTCONF module definition i= n section 8 I would expect the data and operations container to be empty JSON objects.

OLD:
   The server might respond as follows:

      HTTP/1.1 200 OK
      Date: Mon, 23 Apr 2012 17:01:00 GMT
      Server: example-server
      Content-Type: application/yang.api+json

      {
        "ietf-restconf:restconf": {
          "data" : [ null ],
          "operations" : [ null ]
        }
      }
=C2=A0
NEW:
   The server might respond as follows:

      HTTP/1.1 200 OK
      Date: Mon, 23 Apr 2012 17:01:00 GMT
      Server: example-server
      Content-Type: application/yang.api+json

      {
        "ietf-restconf:restconf": {
          "data" : { },
          "operations" : { }
        }
      }


Added new issue 54, still op= en; need to check the JSON draft

=C2=A0
3. In "D.1.3.=C2=A0 Retrieve The Server Capability Information&quo= t;, the example is XML rather than JSON.

OLD:
   In this example the client is retrieving=
 the capability information
   from the server in JSON format, and the server supports all the
   RESTCONF query parameters, plus one vendor parameter:

NEW:
   In this example the client is retrieving the capability information
   from the server in XML format, and the server supports all the
   RESTCONF query parameters, plus one vendor parameter:




Fixed


=C2=A0
Rob



Andy
=C2=A0

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


--001a11401b3ccd7d39052da55b05-- From nobody Thu Mar 10 02:03:51 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E427D12D641 for ; Thu, 10 Mar 2016 02:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCyq-JM-Rn01 for ; Thu, 10 Mar 2016 02:03:48 -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 C0C1012D634 for ; Thu, 10 Mar 2016 02:03:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5850; q=dns/txt; s=iport; t=1457604227; x=1458813827; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=FE47Tl8SFP5op20Vyopfa2mXTVlQkPX1YblFf3+5JIk=; b=IK0NpPxOaZNfgzIcyufHENDl0+XRllG/mnv/ygA6HOvVscbyiZH2+3TI Vf6VR4G+lLd8IsFEvzPn8fF7PaaePgzP13ifIwOqYwL+B/Vop3KLLDwCW 9WcfIBY8s33Vejj5riW4sl+7Ng8eiyarbVt7MUzDM/q0sPSp6Ychz9FTX Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CsBADvReFW/xbLJq1egnKBHm28VyGFb?= =?us-ascii?q?gKCBwEBAQEBAWUnhEIBAQQjVQEQCxQECRYIAwICCQMCAQIBNBEGDQYCAQGIIA6?= =?us-ascii?q?ta48lAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGGIRCg38jOBaCSoE6BZc8hWqID?= =?us-ascii?q?okthVKOamKDZDwuiVMBAQE?= X-IronPort-AV: E=Sophos;i="5.24,315,1454976000"; d="scan'208,217";a="636140346" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Mar 2016 10:03:46 +0000 Received: from [10.63.23.98] (dhcp-ensft1-uk-vla370-10-63-23-98.cisco.com [10.63.23.98]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u2AA3jKI030766; Thu, 10 Mar 2016 10:03:45 GMT To: Andy Bierman References: <56D998AD.8040703@cisco.com> From: Robert Wilton Message-ID: <56E14681.4010101@cisco.com> Date: Thu, 10 Mar 2016 10:03:45 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------080704010701010607010903" Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] restconf-09 comments X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 10:03:50 -0000 This is a multi-part message in MIME format. --------------080704010701010607010903 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 09/03/2016 22:38, Andy Bierman wrote: > > > On Fri, Mar 4, 2016 at 6:16 AM, Robert Wilton > wrote: > > > 2. The "D.1.1. Retrieve the Top-level API Resource" example > looked slightly wrong to me. from the RESTCONF module definition > in section 8 I would expect the data and operations container to > be empty JSON objects. > > OLD: > > The server might respond as follows: > > HTTP/1.1 200 OK > Date: Mon, 23 Apr 2012 17:01:00 GMT > Server: example-server > Content-Type: application/yang.api+json > > { > "ietf-restconf:restconf": { > *"data" : [ null ], "operations" : [ null ]* > } > } > > > NEW: > > The server might respond as follows: > > HTTP/1.1 200 OK > Date: Mon, 23 Apr 2012 17:01:00 GMT > Server: example-server > Content-Type: application/yang.api+json > > { > "ietf-restconf:restconf": { > *"data" : { }, "operations" : { }* > } > } > > > > Added new issue 54, still open; need to check the JSON draft > https://github.com/netconf-wg/restconf/issues/54 From my reading of the JSON encoding rules: The "OLD" example is effectively representing data and operations as leaves of type empty. The "NEW" example is representing them as empty containers. I have no preference over which is more appropriate, just that the specification and example should match up. If it doesn't matter which is used then I would say that fixing the example as above is easier that changing/fixing the description of the RESTCONF module definition in section 8. Rob --------------080704010701010607010903 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 09/03/2016 22:38, Andy Bierman wrote:


On Fri, Mar 4, 2016 at 6:16 AM, Robert Wilton <rwilton@cisco.com> wrote:


2. The "D.1.1.  Retrieve the Top-level API Resource" example looked slightly wrong to me.  from the  RESTCONF module definition in section 8 I would expect the data and operations container to be empty JSON objects.

OLD:
   The server might respond as follows:

      HTTP/1.1 200 OK
      Date: Mon, 23 Apr 2012 17:01:00 GMT
      Server: example-server
      Content-Type: application/yang.api+json

      {
        "ietf-restconf:restconf": {
          "data" : [ null ],
          "operations" : [ null ]
        }
      }
 
NEW:
   The server might respond as follows:

      HTTP/1.1 200 OK
      Date: Mon, 23 Apr 2012 17:01:00 GMT
      Server: example-server
      Content-Type: application/yang.api+json

      {
        "ietf-restconf:restconf": {
          "data" : { },
          "operations" : { }
        }
      }


Added new issue 54, still open; need to check the JSON draft

From my reading of the JSON encoding rules:
The "OLD" example is effectively representing data and operations as leaves of type empty.
The "NEW" example is representing them as empty containers.

I have no preference over which is more appropriate, just that the specification and example should match up.  If it doesn't matter which is used then I would say that fixing the example as above is easier that changing/fixing the description of the RESTCONF module definition in section 8.

Rob

--------------080704010701010607010903-- From nobody Thu Mar 10 10:16:50 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8061012DB78 for ; Thu, 10 Mar 2016 10:16:48 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgpUWCPesYpc for ; Thu, 10 Mar 2016 10:16:45 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0781.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::781]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8112B12DB65 for ; Thu, 10 Mar 2016 10:16:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eYaYzftBlDG2lq1bP5hikSKlc0jV7tol1rYPAVwrRBg=; b=AoYYax490+JzvdczEw4nunsateD2p1575F6obtInDqQJ3jnaU7Awzt+HHbui5UBG4Z3ONeofJO8ZhdBMLIGesP1xR0OyDSw/QqnYEjxMSAujXt59sDHnxb+sVthJiF7p1eDoAimZGpjPGmYbQgd7NrWnTXq0PcjqI9pA0e8hoNM= Authentication-Results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.167.153.133) by DB5PR07MB1622.eurprd07.prod.outlook.com (10.166.12.149) with Microsoft SMTP Server (TLS) id 15.1.434.11; Thu, 10 Mar 2016 18:16:27 +0000 Message-ID: <011001d17af8$6903f480$4001a8c0@gateway.2wire.net> From: t.petch To: Andy Bierman References: <4A95BA014132FF49AE685FAB4B9F17F657DE8236@dfweml701-chm><01ec01d173a0$a4b768e0$4001a8c0@gateway.2wire.net> Date: Thu, 10 Mar 2016 18:12:06 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.167.153.133] X-ClientProxiedBy: AM3PR02CA0055.eurprd02.prod.outlook.com (25.163.180.23) To DB5PR07MB1622.eurprd07.prod.outlook.com (25.166.12.149) X-MS-Office365-Filtering-Correlation-Id: c4d663b5-7bd0-40c5-5414-08d34910194c X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 2:ipuz4eBsQ9UeQ3DEpKTmzISDIdJm9wNRgmLGJh3YIUnH8O/j2sQwZJXo5qPyAvLIG/M5PzVnvADvyKHi7/nC4kAFhlOBfOUf/ow7iccmoHRGptTappawboaKIX5nT4IprtuZpFCNswh4lZeuTepU2EYWXw1LnmGICoYVBlEajMmjSSz/KFxo2E0er5G4ovyJ; 3:nOiONWt62TMNEQEvo4fF+5I5hH13x3mHCM6EpQyV2SVIVHsKAFH/BrQy5dlYIbRcasPT8gDlVbjsUhwlr9tKIbcVJ3jZJ0Hv09areyRz0E7ATPYRMDsT+fDfqumz54M/; 25:k8OdBOkfpw0s0ZK05J3r1CUpZWmcxzd2Zwn/Zi7GzK4sZdRR6OhXIu1fo8rxogXfwDpfRfg1ovSxLYyXeZxtOWAomnyg/QdcJfhS5g0ecQzbSwBzMW/mluhlPp+0NJ1flH/SOeS2RDETzUTPhbt3cUaTXjA589dTFu7jUM8wjrp/Q+2uj6i9YAF0S37YGAmV0w8YOlMCVCsAMHYtfz//7R9fOKJOUNS+akIBS5zExEus8+3RCpAdyU8BZb/wWO2M9lJ0imudf1BLQyXO3ivZbzKbtXX4PqwZdTTP2JQBuH1Rlb5TLTAgzGFQT1wmXDLVzhXeZw43pYgUgO6aFoi+Tg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR07MB1622; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(178726229863574); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:DB5PR07MB1622; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1622; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 4:igCoKRTJhG68XKhnEkI8tj1N+1QTx2WWZ1hIPFGZmR3VGAf68+oiLa6FUwgYTv9A6eNXGVtizguClV1ID7CoNaJDPi+5Lig0Kcb3fiMUR4+zy2pKgbLYP8ANECYHmreM32z2lpiCJ86LTh8dIxGiZa2elX/mOq1LcLg3vxjkq3EqTqiuOpurk/T6jkGJ1lebYHJQBe0fmyxS3+ff8fQz8gVJEw08atrF+lb0TTM6qXhMuImHWODbbcW/nsclojIbbucSVWIhO0fiPLxJ4fZe48aWnfb3veNpmr8lj6VfEHJ1Rd5od00M0TOwSINqnP194wzKRE5IXOHibg45VNtgAfVxXTyjZYcg61LB7+1e1eTKlePi10DDHyAYx/QQWwhztZ8gweYHbuavIFiNrlbhx962LEdFDsbakwS46h8bF37+2w68oR/G9aPbEAeV4W7qaP7fGVgRnzTj8ukfYxLa5w== X-Forefront-PRVS: 08770259B4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(24454002)(377454003)(13464003)(86362001)(81166005)(19580405001)(19580395003)(42186005)(50226001)(77096005)(1556002)(5004730100002)(61296003)(15975445007)(2906002)(23676002)(5008740100001)(92566002)(84392002)(3846002)(4326007)(6116002)(230700001)(586003)(66066001)(50466002)(15395725005)(81686999)(76176999)(81816999)(50986999)(1096002)(33646002)(189998001)(93886004)(62236002)(44716002)(110136002)(14496001)(47776003)(7059030)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1622; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjVQUjA3TUIxNjIyOzIzOmMxcFJGY25tZUF3WVZEYW4rV2pSN2xiSndp?= =?utf-8?B?eEtBYzlockxYdmxXV1VVUVorRGl0RzJ1WllWWmtzNVA2TTBnWFdxUFN5Rm10?= =?utf-8?B?amRlajlzNmVNaXpaVDhvOEluQ1BHY1Z2L0RyUzYrbzJtcjNmR1lscjF4Skhr?= =?utf-8?B?cjVjbzI2KzJ0TXEvd1dkRWdaLzNyZ01BaXF2eS9Mbkh2UGFUcGp5YTd2RmhH?= =?utf-8?B?ajVwendpR2p6SllyK2xVQ1FGYlN1V2VzRUNDOEI3ZTQ5Mkw3MEVBcmkzRVRL?= =?utf-8?B?OHpxZ1dLaTRkV293c3pRRUJaZEFUVklYOE5oUHh3bG5WQ1FUOWw1bmhscXAw?= =?utf-8?B?dWNTeWxOdmFiVzhBc1pBSlp2WjBRejlOZkd6TE5Ca1pIVlBXUnFCbXNBNzVZ?= =?utf-8?B?VjFINW8yZFdUM0ZjTUpEVlRCTHpwTVpOUGYzcTkxVzRYNlhoamcwVWtaSy9x?= =?utf-8?B?bVZ5dEdaa2N5T0NtcGFQYURNYTY5ZVk5bkJMSFBmNGdvejJNZG1wODBoOUZ6?= =?utf-8?B?UjlFMFNKU1o4RW9ydFlOMjlETXJaZkJkWVVVMnFoRjVXL0p0TmdzR1E3ZkdL?= =?utf-8?B?UjFNTVZrMUlEdWFzSjZCUFBTczd2cFNLYXE4eEQ2bE9JelF4VG1TeFVNMVhm?= =?utf-8?B?MGtvWnIwUWdPNm5UZUQ5YUlPaVRFYWx3VWNKbStjd2FzRU1MMzBUNDNVWUNa?= =?utf-8?B?bzI4MDJ5R3ZXdnVHV0xMR0p5cE9HTWF6MUZmYXdvZTZrRVo4dWQ5UU5rWlBB?= =?utf-8?B?dzZQQkNyM1pvN21VQk1qcENqTnR6NElrK1pLMVN5TmswM1ErQVlkK1o5dGs0?= =?utf-8?B?c2FHL1lrYnpJME9kSVhvRWp6UmVIYUJkZzdWVmUwcHNvbmFKNmJrWUpSV3lt?= =?utf-8?B?ZVpBTmFTVERoVHZacmttcGdaZGMzVkZMVzMxMzl1QTlaQk02c2VvQXJFOHVG?= =?utf-8?B?ZE5vWUZ3Y0NOdlEzRitZaTljaG03TmhCR2Q3SGtyczk1elM0UXNPT1M0Yklk?= =?utf-8?B?clBWS2gvZnNZaTRhd01jOUUvTGNQRjVlR0dNazV2U2l0a3Nnd3JaWWptRDc3?= =?utf-8?B?Q1VvVnJVVmJESmVsa0NabEc4NVhDSmlTS3hNN2FzK1RlS1F3MFpleFBDSzVv?= =?utf-8?B?WUJKQ2dZejZnbHJOWlE1SFk1L1JHdXRpVm53ZGRXZUp5bjlsT1MwR1diWXAx?= =?utf-8?B?cHNnWE11YUtjKzhqMXlMcWF4QzlxSnYyeVB5cytKMHJJVlVuUUxjSExBS0Uz?= =?utf-8?B?ZExnbHhiSWxHYzhNM2I5S1MvN0FraWcyYjRyWFFYZEZXdE5aQmo2ZTRLOEpS?= =?utf-8?B?YUNPRDRmSUYva29hQ29MYWVLZENld0d6SVJ4WWhwUVNQVXlLTHZPWmhYbG44?= =?utf-8?B?V0xka3NHVDdkT2RoZW9mM0VOR1V3Q0MwNURoL2lCcnVZL1dSek8xYy9PcXFP?= =?utf-8?B?OGJOb21KejlLSzRFVHJ6VlZJUnB5NmNVdzV3dXZGeEZVVjF1OWhVNEk2K1I4?= =?utf-8?Q?ZmT+0ZZCXtIPpQcyIK9N+bc1cPmOL65qYhENgwv1TfRyPh?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 5:QqCZzEKBATNRczMloTeSbOvBk7+9Ansg0br8yv22QbcgBaNuidukzAjy/9wRHWOqqSptc/AuhESokZaQg18iLvdmieHFoOiMCbv8aK2wyhvBuHN45OaiaL8JpIrPpfLlETLMTB+qc3+WJNuCBSu6eA==; 24:EWvS49Jt8eTLk3xdKwRjzzG7c0gaiTcHLZ3kIF5JvsB55f/ktyo3f+kP75jUTmk2H/8eR8nGJicIjQvkDcBd7g5XVD/lJElIxEWVPwdRBEE= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2016 18:16:27.9452 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1622 Archived-At: Cc: Netconf Subject: Re: [Netconf] netconf-restconf Action X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 18:16:48 -0000 Andy Thanks for this; I am getting there but struggle to match what you have given with the partial example in restconf-09 where it has HTTP/1.1 200 OK ... { "example-ops:output" : { "reboot-time" : 30, "message" : "Going down for system maintenance", "language" : "en-US" } } i.e the I-D has included an 'output' node but has omitted the name of the action itself, namely 'example-ops:get-reboot-info ', whereas you have done the opposite. I was expecting both. Thoughts? Tom Petch ----- Original Message ----- From: "Andy Bierman" To: "t.petch" Cc: "Kent Watsen" ; "Netconf" Sent: Friday, March 04, 2016 2:45 AM Subject: Re: [Netconf] netconf-restconf Action > On Tue, Mar 1, 2016 at 1:56 AM, t.petch wrote: > > > I would like to know what an action looks like in restconf and JSON. > > What would be the equivalent of, from rfc6020bis, > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > apache-1 > > > > 2014-07-29T13:42:00Z > > > > > > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > 2014-07-29T13:42:12Z > > > > > > > > > > I put examples in the next RESTCONF draft for XML and JSON. > > I am assuming the module-name is server-farm. > > POST /restconf/data/server-farm:server=apache-1/reset HTTP/1.1 > Host: example.com > Content-Type: application/yang.action+json > > { "server-farm:reset" : { > "reset-at" : "2014-07-29T13:42:00Z" > } > } > > > HTTP/1.1 200 OK > Date: Mon, 25 Apr 2012 11:10:30 GMT > Server: example-server > Content-Type: application/yang.action+json > > { > "server-farm:reset" : { > "reset-finished-at" : "2014-07-29T13:42:12Z" > } > } > > Tom Petch > > > > Andy From nobody Thu Mar 10 10:23:19 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E75B12DB96 for ; Thu, 10 Mar 2016 10:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZP-YkByRa7tu for ; Thu, 10 Mar 2016 10:23:16 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD50912DB91 for ; Thu, 10 Mar 2016 10:23:15 -0800 (PST) Received: by mail-lb0-x231.google.com with SMTP id xr8so119196201lbb.1 for ; Thu, 10 Mar 2016 10:23:15 -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; bh=X355SuLHUJSoXJzVFAvFh1D/VCLe449xpvwLgqYtoMY=; b=p7JmTn44FZnrgJaCxof9tzgBiFtrhD9njbODKRq4H2zi0OQgxG79zxcJ/qAzv33om1 VFksWiMn/QdD1SdQlryLJyhFrNA7v9pYoPz3UXMJhGmGiR+NOuh2DVoElnBnPCQOf+kI hTU+HGScoOsl/a/hAuT6d9vMW35L1j2+vD67za9xUzKVlj9V5N2XlpfRMcsAdZWJ18tv yMyLBWrwiHkj3Q5H37S5dchlicbYrm3iF76+EnjGY725SkQ8HRP/DzIqJ5IOSLRsJxOJ PuktEAzOlMb0CV9+MKsmJJsck2ImNatF1r0f1qRgUvhybG8SrHfqojd5XeS2Wzc7umPd 3exw== 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; bh=X355SuLHUJSoXJzVFAvFh1D/VCLe449xpvwLgqYtoMY=; b=YLQ/iWavgRiBJBi8UpuvtczhCCQcv67KYxWIfYApz5/rNjGEVBHVLTHDKbKuoq7arc fsvCKPQTRnO0LzilfRQZL1Qn7WGPVfoctj3MSulzEuJha/8Vjy8igbnleJWLAqcbbkXl y76lY9L6qzOWbnJuTxH74hDN2MLrTafaDq53M66+AtPCYcs48ljSaV2VC9UzeBSeOlq5 jr5m3Mz8tBjuse7TVR2EDf4RcchX0Nn95pBTod31QWSQfiJrMOpNFo+RTl6ONxJS4Wgc gyQveIo22stNqxlApdKLTiHjXOW+FLTuPY+x/xeVRe/eDrUl2QYVA8c6/1QfB3IVr+Zh Uv0w== X-Gm-Message-State: AD7BkJLWdQSYNaM+/6nolauTf2u1Q25XqQY25FdrQPJ7jtwTXzSGmDVZ8+qXNkoSZ1+AmSoqAmBdDQWCyjtmag== MIME-Version: 1.0 X-Received: by 10.25.158.72 with SMTP id h69mr1865256lfe.8.1457634193917; Thu, 10 Mar 2016 10:23:13 -0800 (PST) Received: by 10.112.132.65 with HTTP; Thu, 10 Mar 2016 10:23:13 -0800 (PST) In-Reply-To: <011001d17af8$6903f480$4001a8c0@gateway.2wire.net> References: <4A95BA014132FF49AE685FAB4B9F17F657DE8236@dfweml701-chm> <01ec01d173a0$a4b768e0$4001a8c0@gateway.2wire.net> <011001d17af8$6903f480$4001a8c0@gateway.2wire.net> Date: Thu, 10 Mar 2016 10:23:13 -0800 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=001a11401b3c5765b0052db5e8d3 Archived-At: Cc: Netconf Subject: Re: [Netconf] netconf-restconf Action X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 18:23:18 -0000 --001a11401b3c5765b0052db5e8d3 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 10, 2016 at 10:12 AM, t.petch wrote: > Andy > > Thanks for this; I am getting there but struggle to match what you have > given with the partial example in restconf-09 where it has > > HTTP/1.1 200 OK > ... > { > "example-ops:output" : { > "reboot-time" : 30, > "message" : "Going down for system maintenance", > "language" : "en-US" > } > } > > i.e the I-D has included an 'output' node but has omitted the name of > the action itself, namely 'example-ops:get-reboot-info ', whereas you > have done the opposite. I was expecting both. > > Thoughts? > > This is being changed in RESTCONF-10 It matches the way YANG 1.1 encodes action input and output, except there is no need to include the ancestor nodes since they were in the request target resource URI > Tom Petch > Andy > > ----- Original Message ----- > From: "Andy Bierman" > To: "t.petch" > Cc: "Kent Watsen" ; "Netconf" > Sent: Friday, March 04, 2016 2:45 AM > Subject: Re: [Netconf] netconf-restconf Action > > > > On Tue, Mar 1, 2016 at 1:56 AM, t.petch wrote: > > > > > I would like to know what an action looks like in restconf and JSON. > > > What would be the equivalent of, from rfc6020bis, > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > apache-1 > > > > > > 2014-07-29T13:42:00Z > > > > > > > > > > > > > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > 2014-07-29T13:42:12Z > > > > > > > > > > > > > > > > I put examples in the next RESTCONF draft for XML and JSON. > > > > I am assuming the module-name is server-farm. > > > > POST /restconf/data/server-farm:server=apache-1/reset HTTP/1.1 > > Host: example.com > > Content-Type: application/yang.action+json > > > > { "server-farm:reset" : { > > "reset-at" : "2014-07-29T13:42:00Z" > > } > > } > > > > > > HTTP/1.1 200 OK > > Date: Mon, 25 Apr 2012 11:10:30 GMT > > Server: example-server > > Content-Type: application/yang.action+json > > > > { > > "server-farm:reset" : { > > "reset-finished-at" : "2014-07-29T13:42:12Z" > > } > > } > > > > Tom Petch > > > > > > > Andy > > --001a11401b3c5765b0052db5e8d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 10, 2016 at 10:12 AM, t.petch <ietfc@btconnect.com&g= t; wrote:
Andy

Thanks for this;=C2=A0 I am getting there but struggle to match what you ha= ve
given with the partial example in restconf-09 where it has

=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 200 OK
=C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "example-ops:output" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "reboot-time" : 30,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "message" : "Going down f= or system maintenance",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "language" : "en-US"=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 }

i.e the I-D has included an 'output' node but has omitted the name = of
the action itself, namely 'example-ops:get-reboot-info ', whereas y= ou
have done the opposite.=C2=A0 I was expecting both.

Thoughts?


This is being changed in RESTCONF-10
It matches the way YANG 1.1 encodes action input and output, excep= t
there is no need to include the ancestor nodes
since = they were in the request target resource URI

=C2= =A0
Tom Petch

Andy
=C2=A0

----- Original Message -----
From: "Andy Bierman" <an= dy@yumaworks.com>
To: "t.petch" <ietfc@bt= connect.com>
Cc: "Kent Watsen" <kwat= sen@juniper.net>; "Netconf" <netconf@ietf.org>
Sent: Friday, March 04, 2016 2:45 AM
Subject: Re: [Netconf] netconf-restconf Action


> On Tue, Mar 1, 2016 at 1:56 AM, t.petch <ietfc@btconnect.com> wrote:
>
> > I would like to know what an action looks like in restconf and JS= ON.
> > What would be the equivalent of, from rfc6020bis,
> >
> >=C2=A0 =C2=A0 =C2=A0 <rpc message-id=3D"101"
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns=3D"urn:ietf:pa= rams:xml:ns:netconf:base:1.0">
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 <action xmlns=3D"urn:ietf:para= ms:xml:ns:yang:1">
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <server xmlns=3D"h= ttp://example.net/server-farm">
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>apache-1<= /name>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <reset>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <reset-at>2= 014-07-29T13:42:00Z</reset-at>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </reset>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </server>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 </action>
> >=C2=A0 =C2=A0 =C2=A0 </rpc>
> >
> >=C2=A0 =C2=A0 =C2=A0 <rpc-reply message-id=3D"101" > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmln= s=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 <reset-finished-at xmlns=3D"http://example.net/server-farm">
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2014-07-29T13:42:12Z
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 </reset-finished-at>
> >=C2=A0 =C2=A0 =C2=A0 </rpc-reply>
> >
> >
>
> I put examples in the next RESTCONF draft for XML and JSON.
>
> I am assuming the module-name is server-farm.
>
>=C2=A0 =C2=A0 POST /restconf/data/server-farm:server=3Dapache-1/reset H= TTP/1.1
>=C2=A0 =C2=A0 Host: example.com
>=C2=A0 =C2=A0 Content-Type: application/yang.action+json
>
>=C2=A0 =C2=A0 { "server-farm:reset" : {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"reset-at" : "2014-07-= 29T13:42:00Z"
>=C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 }
>
>
>=C2=A0 =C2=A0 HTTP/1.1 200 OK
>=C2=A0 =C2=A0 Date: Mon, 25 Apr 2012 11:10:30 GMT
>=C2=A0 =C2=A0 Server: example-server
>=C2=A0 =C2=A0 Content-Type: application/yang.action+json
>
>=C2=A0 =C2=A0 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"server-farm:reset" : {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "reset-finished-at" : &quo= t;2014-07-29T13:42:12Z"
>=C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 }
>
> Tom Petch
> >
>
> Andy


--001a11401b3c5765b0052db5e8d3-- From nobody Thu Mar 10 19:09:09 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85CF212DDB9 for ; Thu, 10 Mar 2016 19:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwmKnz6pHfOg for ; Thu, 10 Mar 2016 19:09:06 -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 72CAB12D9E7 for ; Thu, 10 Mar 2016 19:09:05 -0800 (PST) Received: by mail-lb0-x22d.google.com with SMTP id x1so138447271lbj.3 for ; Thu, 10 Mar 2016 19:09:05 -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; bh=bgmaiBs6B5x8bQ7lIG5e6WnhDZVRWsapnXu9zrd5+w0=; b=E//dOryaoCMRzlO82ywOTJeBHSyA+PIGDZ/4XPBJZJ6LwXPyKLLniA8jLDPTKJ9ycU oyfPgocAshbLUESTTXN372pNRAJ77lhN3lIjRSO0FIebhID5k00Gio3SGXOq/LyBzpqd I2wYjvgJJaDRuB89RTyB8s8F4TT1G24Dzgkv4RVugNduyIe47cEPGLj5UmDaPBinKHiy ZzaKpCSYXrR0T07ePW81nBbYWCjrUletn4lOkWetIsfSRsY10Idy/HlRaGqRPF/+GZXx 4stv+jBJICCRI4a6gN/F8ZEHBwds6zy7aLQKrIItfJkt/sew9t0vdDEMOXMO7VJps8F9 JWYg== 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; bh=bgmaiBs6B5x8bQ7lIG5e6WnhDZVRWsapnXu9zrd5+w0=; b=YC+CrPBmgwUn/BccA2fQsYY1tioIy/T2eNrrhklafmN+m1WKdQa7F+05vfl4quYKQZ Fy6vl8XgIiFyddH5Hc/DGkkypK0Q8NgxPqjldHAE8gV2zOGfcJv0NryKTqKJEq4ycxJu +RVRj0kBzYewubyFbXGpzj9/SU9EadAa21o5XAvrGYl7IoXEzUScilvGzTIxumzxTNW/ jeqg/VlAlRBw7OijEcG7+p/HfnetUMVFufdSueIV2NISF201x0s2ytaeqVwqSYO9HyzZ KCIztVB6Cyy8Db1Px2VKwRNQ7j3Q7tE/dQQglUVcUprrxLaFeFNNIUII12q+XWjJKEPO bnzg== X-Gm-Message-State: AD7BkJIX7Ey3QhY+E/0YrD3EPFaSGD2mlHLL74ARGAzxMXPrbY0is89D50WxfckWBYRhqXT4OKcfGBgtS25GmQ== MIME-Version: 1.0 X-Received: by 10.112.164.97 with SMTP id yp1mr2337307lbb.30.1457665743576; Thu, 10 Mar 2016 19:09:03 -0800 (PST) Received: by 10.112.132.65 with HTTP; Thu, 10 Mar 2016 19:09:03 -0800 (PST) In-Reply-To: <011001d17af8$6903f480$4001a8c0@gateway.2wire.net> References: <4A95BA014132FF49AE685FAB4B9F17F657DE8236@dfweml701-chm> <01ec01d173a0$a4b768e0$4001a8c0@gateway.2wire.net> <011001d17af8$6903f480$4001a8c0@gateway.2wire.net> Date: Thu, 10 Mar 2016 19:09:03 -0800 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=001a11c33c98d8fff3052dbd4011 Archived-At: Cc: Netconf Subject: Re: [Netconf] netconf-restconf Action X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 03:09:08 -0000 --001a11c33c98d8fff3052dbd4011 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 10, 2016 at 10:12 AM, t.petch wrote: > Andy > > Thanks for this; I am getting there but struggle to match what you have > given with the partial example in restconf-09 where it has > > HTTP/1.1 200 OK > ... > { > "example-ops:output" : { > "reboot-time" : 30, > "message" : "Going down for system maintenance", > "language" : "en-US" > } > } > > i.e the I-D has included an 'output' node but has omitted the name of > the action itself, namely 'example-ops:get-reboot-info ', whereas you > have done the opposite. I was expecting both. > > Thoughts? > > I am changing it to be the same as an rpc-stmt. I realized that no NETCONF and RESTCONF responses identify the exact rpc-stmt or action-stmt to use to parse the "output" element. The paired request message must be known to the parser. (yuch) So this will be consistently flawed as well ;-) Tom Petch > Andy > > ----- Original Message ----- > From: "Andy Bierman" > To: "t.petch" > Cc: "Kent Watsen" ; "Netconf" > Sent: Friday, March 04, 2016 2:45 AM > Subject: Re: [Netconf] netconf-restconf Action > > > > On Tue, Mar 1, 2016 at 1:56 AM, t.petch wrote: > > > > > I would like to know what an action looks like in restconf and JSON. > > > What would be the equivalent of, from rfc6020bis, > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > apache-1 > > > > > > 2014-07-29T13:42:00Z > > > > > > > > > > > > > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > 2014-07-29T13:42:12Z > > > > > > > > > > > > > > > > I put examples in the next RESTCONF draft for XML and JSON. > > > > I am assuming the module-name is server-farm. > > > > POST /restconf/data/server-farm:server=apache-1/reset HTTP/1.1 > > Host: example.com > > Content-Type: application/yang.action+json > > > > { "server-farm:reset" : { > > "reset-at" : "2014-07-29T13:42:00Z" > > } > > } > > > > > > HTTP/1.1 200 OK > > Date: Mon, 25 Apr 2012 11:10:30 GMT > > Server: example-server > > Content-Type: application/yang.action+json > > > > { > > "server-farm:reset" : { > > "reset-finished-at" : "2014-07-29T13:42:12Z" > > } > > } > > > > Tom Petch > > > > > > > Andy > > --001a11c33c98d8fff3052dbd4011 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 10, 2016 at 10:12 AM, t.petch <ietfc@btconnect.com&g= t; wrote:
Andy

Thanks for this;=C2=A0 I am getting there but struggle to match what you ha= ve
given with the partial example in restconf-09 where it has

=C2=A0 =C2=A0 =C2=A0 HTTP/1.1 200 OK
=C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "example-ops:output" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "reboot-time" : 30,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "message" : "Going down f= or system maintenance",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "language" : "en-US"=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 }

i.e the I-D has included an 'output' node but has omitted the name = of
the action itself, namely 'example-ops:get-reboot-info ', whereas y= ou
have done the opposite.=C2=A0 I was expecting both.

Thoughts?



I am changing it to be = the same as an rpc-stmt.
I realized that no NETCONF and RESTCONF = responses identify
the exact rpc-stmt or action-stmt to use to pa= rse the "output" element.
The paired request message mu= st be known to the parser. (yuch)
So this will be consistently fl= awed as well ;-)


Tom Petch


Andy
=C2=A0

----- Original Message -----
From: "Andy Bierman" <an= dy@yumaworks.com>
To: "t.petch" <ietfc@bt= connect.com>
Cc: "Kent Watsen" <kwat= sen@juniper.net>; "Netconf" <netconf@ietf.org>
Sent: Friday, March 04, 2016 2:45 AM
Subject: Re: [Netconf] netconf-restconf Action


> On Tue, Mar 1, 2016 at 1:56 AM, t.petch <ietfc@btconnect.com> wrote:
>
> > I would like to know what an action looks like in restconf and JS= ON.
> > What would be the equivalent of, from rfc6020bis,
> >
> >=C2=A0 =C2=A0 =C2=A0 <rpc message-id=3D"101"
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns=3D"urn:ietf:pa= rams:xml:ns:netconf:base:1.0">
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 <action xmlns=3D"urn:ietf:para= ms:xml:ns:yang:1">
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <server xmlns=3D"h= ttp://example.net/server-farm">
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>apache-1<= /name>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <reset>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <reset-at>2= 014-07-29T13:42:00Z</reset-at>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </reset>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </server>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 </action>
> >=C2=A0 =C2=A0 =C2=A0 </rpc>
> >
> >=C2=A0 =C2=A0 =C2=A0 <rpc-reply message-id=3D"101" > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmln= s=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 <reset-finished-at xmlns=3D"http://example.net/server-farm">
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2014-07-29T13:42:12Z
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 </reset-finished-at>
> >=C2=A0 =C2=A0 =C2=A0 </rpc-reply>
> >
> >
>
> I put examples in the next RESTCONF draft for XML and JSON.
>
> I am assuming the module-name is server-farm.
>
>=C2=A0 =C2=A0 POST /restconf/data/server-farm:server=3Dapache-1/reset H= TTP/1.1
>=C2=A0 =C2=A0 Host: example.com
>=C2=A0 =C2=A0 Content-Type: application/yang.action+json
>
>=C2=A0 =C2=A0 { "server-farm:reset" : {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"reset-at" : "2014-07-= 29T13:42:00Z"
>=C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 }
>
>
>=C2=A0 =C2=A0 HTTP/1.1 200 OK
>=C2=A0 =C2=A0 Date: Mon, 25 Apr 2012 11:10:30 GMT
>=C2=A0 =C2=A0 Server: example-server
>=C2=A0 =C2=A0 Content-Type: application/yang.action+json
>
>=C2=A0 =C2=A0 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"server-farm:reset" : {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "reset-finished-at" : &quo= t;2014-07-29T13:42:12Z"
>=C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 }
>
> Tom Petch
> >
>
> Andy


--001a11c33c98d8fff3052dbd4011-- From nobody Fri Mar 11 15:06:22 2016 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 B627A12DD81; Fri, 11 Mar 2016 15:05:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230529.15028.80752.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:29 -0800 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] netconf - Requested session has been scheduled for IETF 95 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 23:05:30 -0000 Dear Mahesh Jethanandani, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. netconf Session 1 (2:00:00) Thursday, Afternoon Session I 1400-1600 Room Name: Buen Ayre B size: 125 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Network Configuration Area Name: Operations and Management Area Session Requester: Mahesh Jethanandani Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 120 Conflicts to Avoid: First Priority: netmod opsarea opsawg Second Priority: i2nsf anima sfc i2rs nmrg lmap radext dime Third Priority: apparea core tsvarea intarea v6ops 6tisch 6lo tls sacm sdnrg lwig Special Requests: Please schedule session on Thursday. Friday is NOT possible for Netconf. Please avoid a conflict with vnfrg. (added i2nsf as a conflict per Benoit) --------------------------------------------------------- From nobody Mon Mar 14 03:26:21 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCEA12D55E for ; Mon, 14 Mar 2016 03:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crWRfWDiLxim for ; Mon, 14 Mar 2016 03:26:16 -0700 (PDT) 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 28ACE12D521 for ; Mon, 14 Mar 2016 03:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32081; q=dns/txt; s=iport; t=1457951175; x=1459160775; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=3py0aaD4VYwMhTyzQWm44TyxRSDY6QUgsXwquwiGHo4=; b=KfWNIoyYF//5btscfUtjpnAS6diwoBHCRarsotmCqyQKVD6G83BvOF/q Qe1aIIbs7QtLVx3VF5ufxyNyhyk/UaFWlP/l9JFkQHaBmOFQAthsfJ/QN ctuM04DTwahWO0/HcPcDRSx9/3QmqR6YzNSy6gWd0af72GmSuBSPE5aOx c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CxBABWkeZW/xbLJq1dgnqBHm28LAMXA?= =?us-ascii?q?QmFIkoCgXIBAQEBAQFlHAuEQgEBBAEBARdUChELGAkWAQ4JAwIBAgEVMAYNBgI?= =?us-ascii?q?BAYggDrpQAQEBAQEBAQMBAQEBAQEBAQETBIYYhEKEIgKEUAWXS4VugnKFIIFlh?= =?us-ascii?q?EmDA4VUjn1iggMZFIE0PC4BiSiBOgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,335,1454976000"; d="scan'208,217";a="636235530" 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/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Mar 2016 10:26:12 +0000 Received: from [10.63.23.98] (dhcp-ensft1-uk-vla370-10-63-23-98.cisco.com [10.63.23.98]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u2EAQBE0004360 for ; Mon, 14 Mar 2016 10:26:12 GMT To: "netconf@ietf.org" References: <56DEE009.2070208@cisco.com> From: Robert Wilton Message-ID: <56E691C2.8060601@cisco.com> Date: Mon, 14 Mar 2016 10:26:10 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56DEE009.2070208@cisco.com> Content-Type: multipart/alternative; boundary="------------030209080302060806060501" Archived-At: Subject: Re: [Netconf] More restconf-09 comments/questions (edit collision detection and error handling) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 10:26:20 -0000 This is a multi-part message in MIME format. --------------030209080302060806060501 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit To add to the question/comments below, I have some more questions/comments on query parameter handling: These questions related to section 4.8: Query Parameters 1. Are query parameters and paths case sensitive? I would guess so. The draft doesn't make any explicit mention of this, but perhaps this is covered by the HTTP 1.1 draft. 2. Should an unexpected query parameter cause an error or should it just be ignored? For some (but not all) of the query parameters in sections 4.8.1 through 4.8.9 it indicates that an explicit error should be returned if the query parameter is used for an unsupported resource type, but section 4.8 allows vendor specific query parameters to also be defined. Should these also cause errors if they are not known? 3. Both the depth and fields query parameters (4.8.2 & 4.8.3) indicate that they apply to the API resource (3.3), but I wasn't sure that they served any purpose since my reading of the draft is that the api resource is just the top level and effectively fixed. I.e. it doesn't return any data from the datastore or the operations, and they need to be explicitly queried separately if required. 4. Minor nit. It might be helpful if the options were listed in the same order as they are listed in the table in section 4.8. E.g. this would mean that the section on filter would need to move up above the section on insert. 5. Section 4.8.2: The "depth" Query Parameter The last but one paragraph reads: "By default, the server will include all sub-resources within a retrieved resource, which have the same resource type as the requested resource. Only one level of sub-resources with a different media type than the target resource will be returned." I'm not quite sure what the purpose of this paragraph is. Would this mean that that a GET request on /restconf/data is only expected the first layer of children nodes? 6. Section 8: "error-info". Should the type be anydata rather than the deprecated anyxml? Rob On 08/03/2016 14:22, Robert Wilton wrote: > Hi, > > I've a few more review comments/questions on restconf-09 as I've > studied it a bit more closely over the last couple of days, > particularly concerning edit collision detection and error handling. > > > 1. General question: It looks like all the requests target resources > without a trailing slash. Should the draft specify what behaviour is > expected if the server receives a request with a trailing slash (e.g. > probably redirect back to the version of the resource without a > trailing slash). Personally, I think that not specifying this is > probably fine - but thought it might be worth raising in case it > hadn't been considered. > > > 2. Section 3.4 Datastore Resource: > Old: > Configuration edit transaction management and configuration > persistence are handled by the server and not controlled by the > client. A datastore resource can only be written directly with the > *PATCH *method. Each RESTCONF edit of a datastore resource is saved to > non-volatile storage by the server. > > The last paragraph states that a datastore resource can only be > written directly with the PATCH method. But section 4.4 indicates > that POST is also allowed. Does this text need to be changed to allow > for PATCH or POST? > > E.g new: > Configuration edit transaction management and configuration > persistence are handled by the server and not controlled by the > client. A datastore resource can only be written directly with the > *PATCH **or POST* methods. Each RESTCONF edit of a datastore resource is > saved to non-volatile storage by the server. > > > 3. Section 3.4.1 Edit Collision Detection (applies equally to the > Timestamp and Entity tag): > 3.4.1.1. Timestamp > The last change time is maintained and the "Last-Modified" > ([RFC7232], Section 2.2 ) header is returned in the response for a > retrieval request. The "If-Unmodified-Since" header can be used in > edit operation requests to cause the server to reject the request if > the resource has been modified since the specified timestamp. > > The server MUST maintain a last-modified timestamp for the top-level > {+restconf}/data resource and SHOULD maintain last-modified > timestamps for descendant resources. For all resources, the server > MUST return the "Last-Modified" header when the resource is retrieved > with the GET or HEAD methods. If the server does not maintain a > timestamp for a resource, it MUST return the timestamp of the > resource's ancestor, a process that may recurse up to the top-level > {+restconf}/data resource. Only changes to configuration data > resources within the datastore affect the timestamp. > > i) Do the timestamp and entity tag appear to apply to both config and > non config resources, or is it just config resources? > ii) If it is just config resources then please can sections 3.4.1.1 > and 3.4.1.2 be updated to make this clear. > iii) If it both config and non config resources, then it is unclear > to me what the exact semantics for non config resources are expected > to be? (Based on the description in section 3.5 - I can elaborate if > needs be) > > > 4. Section 3.5 Data Resource. > To be consistent with 3.4.1.1 and 3.4.1.2, I think that the MAY should > change to SHOULD: > > I.e. old: > For configuration data resources, the server*MAY *maintain a last- > modified timestamp for the resource, and return the "Last-Modified" > header when it is retrieved with the GET or HEAD methods. ... > > > new: > For configuration data resources, the server*SHOULD *maintain a last- > modified timestamp for the resource, and return the "Last-Modified" > header when it is retrieved with the GET or HEAD methods. ... > > Likewise for entity tag: > old: > For configuration data resources, the server*MAY *maintain a resource > entity tag for the resource, and return the "ETag" header when it is > retrieved as the target resource with the GET or HEAD methods. > > new: > For configuration data resources, the server*SHOULD *maintain a resource > entity tag for the resource, and return the "ETag" header when it is > retrieved as the target resource with the GET or HEAD methods. > > > 5. Section 3.5 Data Resource, last paragraph. > I didn't understand what the last paragraph means, or what it > relevance is: > The resource definition version for a data resource is identified by > the revision date of the YANG module containing the YANG definition > for the data resource. > > > 6. Section 4.1. OPTIONS: > The OPTIONS method is sent by the client to discover which methods > are supported by the server for a specific resource (e.g., GET, POST, > DELETE, etc.). > > The server SHOULD implement this method, however the same information > could be extracted from the YANG modules and the RESTCONF protocol > specification. > > > What body text (if any) should be returned for OPTIONS requests? If > body text is returned then what media type should it use? > > E.g. RFC 7231, section 4.3.7 "options" indicates that the body might > contain a human readable description. > > > 7. Section 4.3 GET, first paragraph: > The GET method is sent by the client to retrieve data and meta-data > for a resource. It is supported for all resource types, except > operation resources. The request MUST contain a request URI that > contains at least the entry point. > > > It isn't clear to me what the last sentence is trying to say - I'm not > sure exactly what is meant by "entry point". > > > 8. Section 5.1 last but one paragraph. Should the "MUST" be changed > to "can"? > > old: > When new resources are created by the client, a "Location" header is > returned, which identifies the path of the newly created resource. > The client*MUST *use this exact path identifier to access the resource > once it has been created. > > new: > When new resources are created by the client, a "Location" header is > returned, which identifies the path of the newly created resource. > The client*can *use this exact path identifier to access the resource > once it has been created. > > > 9. Section 7.1 Error Response message: > When an error occurs for a request message on a*data *resource or an > operation resource, and a "4xx" class of status codes (except for > status code "403 Forbidden"), then the server SHOULD send a response > message-body containing the information described by the "errors" > container definition within the YANG moduleSection 8 > . The Content- > Type of this response message MUST be application/yang.errors (see > example below). > > The client*MAY *specify the desired encoding for error messages by > specifying the appropriate media-type in the Accept header.*If no error media is specified, then the media type of the request > message is used. If there is no request message the server* MUST select > "application/yang.errors+xml" or "application/yang.errors+json", > depending on server preference. All of the examples in this > document, except for the one below, assume that XML encoding will be > returned if there is an error. > > i) The beginning of the error paragraph makes the description > conditional on the request message being on a data resource. Should > this cover other resource types as well, or otherwise what is the > error handling strategy for other resource types? > ii) Should the last sentence of the first paragraph be "Type of this > response message MUST be a subtype of application/yang.errors (see > example below). "? > iii) Would it be wise to indicate that the client SHOULD specify > desired encoding for error messages? > iv) The second paragraph states "If no error media is specified, then > the media type of the request message is used. " but this directly > conflicts with "The Content- Type of this response message MUST be > application/yang.errors (see example below). " > v) "If there is no request message the server ..." - I would think > that there must always be a request message. > > In summary, what about this text instead: > When an error occurs for a request message on an*api, data,****datastore, or operation resource*, and a "4xx" class of status > codes (except for status code "403 Forbidden"), then the server > SHOULD send a response message-body containing the information > described by the "errors" container definition within the YANG > moduleSection 8 > . The Content-Type of this response message MUST > be*a subtype* of application/yang.errors (see example below). > > The client*SHOULD *specify the desired encoding for error messages by > specifying the appropriate media-type in the Accept header.*If no error media-type is specified, then the server SHOULD choose an****error media-type encoding (XML or JSON) that is consistent to what > would have**been used if the request succeeded. If the client did not specify**any particular media type in the Accept header then the server* MUST > select "application/yang.errors+xml" or "application/yang.errors+json", > depending on server preference. All of the examples in this > document, except for the one below, assume that XML encoding will be > returned if there is an error. > > Thanks, > Rob > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------030209080302060806060501 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit To add to the question/comments below, I have some more questions/comments on query parameter handling:

These questions related to section 4.8: Query Parameters
1. Are query parameters and paths case sensitive?  I would guess so.  The draft doesn't make any explicit mention of this, but perhaps this is covered by the HTTP 1.1 draft.

2. Should an unexpected query parameter cause an error or should it just be ignored?  For some (but not all) of the query parameters in sections 4.8.1 through 4.8.9 it indicates that an explicit error should be returned if the query parameter is used for an unsupported resource type, but section 4.8 allows vendor specific query parameters to also be defined.  Should these also cause errors if they are not known?

3. Both the depth and fields query parameters (4.8.2 & 4.8.3) indicate that they apply to the API resource (3.3), but I wasn't sure that they served any purpose since my reading of the draft is that the api resource is just the top level and effectively fixed.  I.e. it doesn't return any data from the datastore or the operations, and they need to be explicitly queried separately if required.

4. Minor nit.  It might be helpful if the options were listed in the same order as they are listed in the table in section 4.8.  E.g. this would mean that the section on filter would need to move up above the section on insert.

5. Section 4.8.2: The "depth" Query Parameter
The last but one paragraph reads:
   "By default, the server will include all sub-resources within a
   retrieved resource, which have the same resource type as the
   requested resource.  Only one level of sub-resources with a different
   media type than the target resource will be returned."

I'm not quite sure what the purpose of this paragraph is.  Would this mean that that a GET request on /restconf/data is only expected the first layer of children nodes?

6. Section 8: "error-info". Should the type be anydata rather than the deprecated anyxml?

Rob


On 08/03/2016 14:22, Robert Wilton wrote:
Hi,

I've a few more review comments/questions on restconf-09 as I've studied it a bit more closely over the last couple of days, particularly concerning edit collision detection and error handling.


1. General question:  It looks like all the requests target resources without a trailing slash. Should the draft specify what behaviour is expected if the server receives a request with a trailing slash (e.g. probably redirect back to the version of the resource without a trailing slash).  Personally, I think that not specifying this is probably fine - but thought it might be worth raising in case it hadn't been considered.


2. Section 3.4 Datastore Resource:
Old:
   Configuration edit transaction management and configuration
   persistence are handled by the server and not controlled by the
   client.  A datastore resource can only be written directly with the
   PATCH method.  Each RESTCONF edit of a datastore resource is saved to
   non-volatile storage by the server.

The last paragraph states that a datastore resource can only be written directly with the PATCH method.  But section 4.4 indicates that POST is also allowed.  Does this text need to be changed to allow for PATCH or POST?

E.g new: 
   Configuration edit transaction management and configuration
   persistence are handled by the server and not controlled by the
   client.  A datastore resource can only be written directly with the
   PATCH or POST methods.  Each RESTCONF edit of a datastore resource is
   saved to non-volatile storage by the server.


3. Section 3.4.1 Edit Collision Detection (applies equally to the Timestamp and Entity tag):
3.4.1.1.  Timestamp
   The last change time is maintained and the "Last-Modified"
   ([RFC7232], Section 2.2) header is returned in the response for a
   retrieval request.  The "If-Unmodified-Since" header can be used in
   edit operation requests to cause the server to reject the request if
   the resource has been modified since the specified timestamp.

   The server MUST maintain a last-modified timestamp for the top-level
   {+restconf}/data resource and SHOULD maintain last-modified
   timestamps for descendant resources.  For all resources, the server
   MUST return the "Last-Modified" header when the resource is retrieved
   with the GET or HEAD methods.  If the server does not maintain a
   timestamp for a resource, it MUST return the timestamp of the
   resource's ancestor, a process that may recurse up to the top-level
   {+restconf}/data resource.  Only changes to configuration data
   resources within the datastore affect the timestamp.

 i) Do the timestamp and entity tag appear to apply to both config and non config resources, or is it just config resources?
 ii) If it is just config resources then please can sections 3.4.1.1 and 3.4.1.2 be updated to make this clear.
 iii) If it both config and non config resources, then it is unclear to me what the exact semantics for non config resources are expected to be?  (Based on the description in section 3.5 - I can elaborate if needs be)


4. Section 3.5 Data Resource.
To be consistent with 3.4.1.1 and 3.4.1.2, I think that the MAY should change to SHOULD:

I.e. old:
   For configuration data resources, the server MAY maintain a last-
   modified timestamp for the resource, and return the "Last-Modified"
   header when it is retrieved with the GET or HEAD methods. ...
new: 
   For configuration data resources, the server SHOULD maintain a last-
   modified timestamp for the resource, and return the "Last-Modified"
   header when it is retrieved with the GET or HEAD methods. ...

Likewise for entity tag:
old:
   For configuration data resources, the server MAY maintain a resource
   entity tag for the resource, and return the "ETag" header when it is
   retrieved as the target resource with the GET or HEAD methods.

new:
   For configuration data resources, the server SHOULD maintain a resource
   entity tag for the resource, and return the "ETag" header when it is
   retrieved as the target resource with the GET or HEAD methods.


5. Section 3.5 Data Resource, last paragraph.
I didn't understand what the last paragraph means, or what it relevance is:
   The resource definition version for a data resource is identified by
   the revision date of the YANG module containing the YANG definition
   for the data resource.


6. Section 4.1. OPTIONS:
   The OPTIONS method is sent by the client to discover which methods
   are supported by the server for a specific resource (e.g., GET, POST,
   DELETE, etc.).

   The server SHOULD implement this method, however the same information
   could be extracted from the YANG modules and the RESTCONF protocol
   specification.


What body text (if any) should be returned for OPTIONS requests?  If body text is returned then what media type should it use?

E.g. RFC 7231, section 4.3.7 "options" indicates that the body might contain a human readable description.


7. Section 4.3 GET, first paragraph:
   The GET method is sent by the client to retrieve data and meta-data
   for a resource.  It is supported for all resource types, except
   operation resources.  The request MUST contain a request URI that
   contains at least the entry point.
It isn't clear to me what the last sentence is trying to say - I'm not sure exactly what is meant by "entry point".


8. Section 5.1 last but one paragraph.  Should the "MUST" be changed to "can"?

old:
   When new resources are created by the client, a "Location" header is
   returned, which identifies the path of the newly created resource.
   The client MUST use this exact path identifier to access the resource
   once it has been created.

new:
   When new resources are created by the client, a "Location" header is
   returned, which identifies the path of the newly created resource.
   The client can use this exact path identifier to access the resource
   once it has been created.


9. Section 7.1 Error Response message:
   When an error occurs for a request message on a data resource or an
   operation resource, and a "4xx" class of status codes (except for
   status code "403 Forbidden"), then the server SHOULD send a response
   message-body containing the information described by the "errors"
   container definition within the YANG module Section 8.  The Content-
   Type of this response message MUST be application/yang.errors (see
   example below).

   The client MAY specify the desired encoding for error messages by
   specifying the appropriate media-type in the Accept header.  If no
   error media is specified, then the media type of the request message
   is used.  If there is no request message the server MUST select
   "application/yang.errors+xml" or "application/yang.errors+json",
   depending on server preference.  All of the examples in this
   document, except for the one below, assume that XML encoding will be
   returned if there is an error.

i) The beginning of the error paragraph makes the description conditional on the request message being on a data resource.  Should this cover other resource types as well, or otherwise what is the error handling strategy for other resource types?
ii) Should the last sentence of the first paragraph be "Type of this response message MUST be a subtype of application/yang.errors (see example below). "?
iii) Would it be wise to indicate that the client SHOULD specify desired encoding for error messages?
iv) The second paragraph states "If no error media is specified, then the media type of the request message is used. " but this directly conflicts with "The Content- Type of this response message MUST be application/yang.errors (see example below). "
v) "If there is no request message the server ..." - I would think that there must always be a request message.

In summary, what about this text instead:
   When an error occurs for a request message on an api, data,
   datastore, or operation resource, and a "4xx" class of status
   codes (except for status code "403 Forbidden"), then the server
   SHOULD send a response message-body containing the information
   described by the "errors" container definition within the YANG
   module Section 8.  The Content-Type of this response message MUST
   be a subtype of application/yang.errors (see example below).

   The client SHOULD specify the desired encoding for error messages by
   specifying the appropriate media-type in the Accept header.  If no
   error media-type is specified, then the server SHOULD choose an
   error media-type encoding (XML or JSON) that is consistent to what
   would have been used if the request succeeded.  If the client did not
   specify any particular media type in the Accept header then the server MUST
   select "application/yang.errors+xml" or "application/yang.errors+json",
   depending on server preference.  All of the examples in this
   document, except for the one below, assume that XML encoding will be
   returned if there is an error.

Thanks,
Rob


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

--------------030209080302060806060501-- From nobody Mon Mar 14 12:51:57 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0284B12D6AE for ; Mon, 14 Mar 2016 12:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.929 X-Spam-Level: X-Spam-Status: No, score=-12.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yP875hvo53ly for ; Mon, 14 Mar 2016 12:51:54 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F11DA12D50C for ; Mon, 14 Mar 2016 12:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7359; q=dns/txt; s=iport; t=1457985113; x=1459194713; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=VJxIp6cUG9Pv8ByKTBAcShwHNeE0GfTLa8zna36dZWY=; b=Q8N2ow9WUL8zmB8F79D83wDMxzJF3NwLAjp6QTP+bckISn9ADxcpyIuL heRGNdg/MrclFJ3v/gK7OG0NnDVC3OEDq0u0+Pzr4oSN18OCoGcwpXhGs 5LRh70/5TVT4sVn+QVZScKJ2ZouaNHotZx6Biup2zQfBg2InVl22fJp9R g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A4AgAsFedW/4oNJK1dUYJ1Um26NgENg?= =?us-ascii?q?XAXAQmFbAKBMjgUAQEBAQEBAWQnhEEBAQEEAQEBSyoRHAMBAgoDEwQLCQMCAQI?= =?us-ascii?q?BFQoVBwIIBg0GAgEBEAcCBIgDDrt+AQEBAQEBBAEBAQEBAQEBGIYYhEKBN4JiQ?= =?us-ascii?q?YQaBZdLhW6IEoFlh0yFVIYIiHUeAQFCghAggTU7LgGJMIEyAQEB?= X-IronPort-AV: E=Sophos;i="5.24,337,1454976000"; d="scan'208,217";a="249128387" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Mar 2016 19:51:52 +0000 Received: from [10.82.234.89] (rtp-vpn5-599.cisco.com [10.82.234.89]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u2EJppqv000311 for ; Mon, 14 Mar 2016 19:51:52 GMT References: <20160224223349.D89CE180013@rfc-editor.org> To: NETCONF From: Benoit Claise X-Forwarded-Message-Id: <20160224223349.D89CE180013@rfc-editor.org> Message-ID: <56E6DF5D.7030606@cisco.com> Date: Mon, 14 Mar 2016 16:57:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160224223349.D89CE180013@rfc-editor.org> Content-Type: multipart/alternative; boundary="------------090502030602080608070504" Archived-At: Subject: [Netconf] Fwd: BCP 203, RFC 7803 on Changing the Registration Policy for the NETCONF Capability URNs Registry X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 19:51:56 -0000 This is a multi-part message in MIME format. --------------090502030602080608070504 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Regards, B. -------- Forwarded Message -------- Subject: BCP 203, RFC 7803 on Changing the Registration Policy for the NETCONF Capability URNs Registry Date: Wed, 24 Feb 2016 14:33:49 -0800 (PST) From: rfc-editor@rfc-editor.org Reply-To: ietf@ietf.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: drafts-update-ref@iana.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. BCP 203 RFC 7803 Title: Changing the Registration Policy for the NETCONF Capability URNs Registry Author: B. Leiba Status: Best Current Practice Stream: IETF Date: February 2016 Mailbox: barryleiba@computer.org Pages: 3 Characters: 5133 Updates: RFC 6241 See Also: BCP 203 I-D Tag: draft-leiba-netmod-regpolicy-update-02.txt URL: https://www.rfc-editor.org/info/rfc7803 DOI: http://dx.doi.org/10.17487/RFC7803 The registration policy for the "Network Configuration Protocol (NETCONF) Capability URNs" registry, set up by RFC 6241, has turned out to be unnecessarily strict. This document changes that registration policy to "IETF Review", allowing registrations from certain well-reviewed Experimental RFCs, in addition to Standards Track RFCs. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC . --------------090502030602080608070504 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Regards, B.


-------- Forwarded Message --------
Subject: BCP 203, RFC 7803 on Changing the Registration Policy for the NETCONF Capability URNs Registry
Date: Wed, 24 Feb 2016 14:33:49 -0800 (PST)
From: rfc-editor@rfc-editor.org
Reply-To: ietf@ietf.org
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
CC: drafts-update-ref@iana.org, rfc-editor@rfc-editor.org 


A new Request for Comments is now available in online RFC libraries.

        BCP 203        
        RFC 7803

        Title:      Changing the Registration Policy for 
                    the NETCONF Capability URNs Registry 
        Author:     B. Leiba
        Status:     Best Current Practice
        Stream:     IETF
        Date:       February 2016
        Mailbox:    barryleiba@computer.org
        Pages:      3
        Characters: 5133
        Updates:    RFC 6241
        See Also:   BCP 203

        I-D Tag:    draft-leiba-netmod-regpolicy-update-02.txt

        URL:        https://www.rfc-editor.org/info/rfc7803

        DOI:        http://dx.doi.org/10.17487/RFC7803

The registration policy for the "Network Configuration Protocol
(NETCONF) Capability URNs" registry, set up by RFC 6241, has turned
out to be unnecessarily strict.  This document changes that
registration policy to "IETF Review", allowing registrations from
certain well-reviewed Experimental RFCs, in addition to Standards
Track RFCs.


BCP: This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for 
improvements. Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC

.


--------------090502030602080608070504-- From nobody Wed Mar 16 11:40:01 2016 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 A116712D624; Wed, 16 Mar 2016 11:39:58 -0700 (PDT) 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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160316183958.3890.2714.idtracker@ietfa.amsl.com> Date: Wed, 16 Mar 2016 11:39:58 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 18:39:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration of the IETF. Title : Zero Touch Provisioning for NETCONF or RESTCONF based Management Authors : Kent Watsen Mikael Abrahamsson Filename : draft-ietf-netconf-zerotouch-05.txt Pages : 69 Date : 2016-03-16 Abstract: This draft presents a secure technique for establishing a NETCONF or RESTCONF connection between a newly deployed device, configured with just its factory default settings, and its deployment specific network management system (NMS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-zerotouch-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 16 12:05:33 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D0712D59F for ; Wed, 16 Mar 2016 12:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZscbfXPtr_6j for ; Wed, 16 Mar 2016 12:05:30 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0145.outbound.protection.outlook.com [65.55.169.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A06BD12D59D for ; Wed, 16 Mar 2016 12:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gECsq4hmI6oqIxcOMCBjDW8OuOjtEkwzH8GXqIasCjg=; b=WbgLghsotGI7sr/ziaSECMQuOo6J5f47aG6bYwgfX45l3FfNz52FuGSHibHuLEc5hvXpU+rGS9qsqHUKrVkgETBmWK6Ysew3IRDP/2Ac52S5CfnqWQN1yd3Rtwbkc3Bh2WWN+L2iU6G3BpSWdwgTtTkjcc25y10O2KkbOlrBX5I= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1452.namprd05.prod.outlook.com (10.160.149.13) with Microsoft SMTP Server (TLS) id 15.1.434.16; Wed, 16 Mar 2016 19:05:27 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0434.016; Wed, 16 Mar 2016 19:05:27 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-05.txt Thread-Index: AQHRf7NKmpiprDVPDUWwEBnTS1nQuZ9cKyQA Date: Wed, 16 Mar 2016 19:05:27 +0000 Message-ID: <7C8EF296-4B26-408F-8D9A-90FA383B16D4@juniper.net> References: <20160316183958.3890.2714.idtracker@ietfa.amsl.com> In-Reply-To: <20160316183958.3890.2714.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.160212 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: 3404990b-1b37-4b49-077b-08d34dcdefdf x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1452; 5:yIjE6/qnqRGWGmk50KaeJm89Tz3MaBVMY9MQKU+JZOTIFFufQC0hdOp5Ypgx4154AmgXlRmlltp5Qgdz9jmPYRRQkpPww0xbm6zuT2jvXr6eqnk5cuq0v6DKFM55TkHzmNvZ+8wTlKpWK7hT078Y9w==; 24:bYthfwv9pzEV5WzaOtzeIJMno1wNizfBhhGjgZYdRGplVGxuFEoBwizAqQKarQGgm6mnyEIpLy8ULMcjkDZTdCGh0ZyfhY4ffXc/yZADD4Q= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1452; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:CY1PR0501MB1452; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1452; x-forefront-prvs: 08831F51DC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(377424004)(24454002)(54534003)(479174004)(377454003)(6116002)(2351001)(82746002)(586003)(4001350100001)(99286002)(11100500001)(2900100001)(83506001)(450100001)(83716003)(5640700001)(1220700001)(102836003)(1096002)(66066001)(230783001)(86362001)(81166005)(92566002)(87936001)(54356999)(76176999)(106116001)(5008740100001)(36756003)(10400500002)(3660700001)(3280700002)(50986999)(3846002)(2906002)(33656002)(2501003)(5002640100001)(15975445007)(5004730100002)(19580405001)(77096005)(1730700002)(19580395003)(122556002)(189998001)(2950100001)(107886002)(110136002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1452; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <3066AC3138BFB24D83180A30E0D1F938@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2016 19:05:27.6596 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1452 Archived-At: Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 19:05:32 -0000 DQpUaGlzIHVwZGF0ZSByZWZsZWN0cyByZXZpZXdzIGZyb20gTWF4IFByaXRpa2luIGFuZCBNaWth ZWwgQWJyYWhhbXNzb24uDQoNCkZyb20gdGhlIGNoYW5nZSBsb2c6DQoNCiogU2VtaS1tYWpvciB1 cGRhdGUsIHJlZmFjdG9yaW5nIHRoZSBkb2N1bWVudCBpbnRvIG1vcmUgbG9naWNhbCBwYXJ0cw0K KiBDcmVhdGVkIG5ldyBzZWN0aW9uIGZvciBpbmZvcm1hdGlvbiB0eXBlcw0KKiBBZGRlZCBzdXBw b3J0IGZvciBETlMgc2VydmVycw0KKiBOb3cgYWxsb3dzIHByb3Zpc2lvbmFsIFRMUyBjb25uZWN0 aW9ucw0KKiBCb290c3RyYXBwaW5nIGRhdGEgbm93IHN1cHBvcnRzIHNjcmlwdHMNCiogRGV2aWNl IERldGFpbHMgc2VjdGlvbiBvdmVyaGF1bGVkDQoqIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGV4 cGFuZGVkDQoqIEZpbGxlZCBpbiBlbnVtZXJhdGlvbnMgZm9yIG5vdGlmaWNhdGlvbiB0eXBlcw0K DQoNCg0KTm90ZTogdGhlIGRpZmYyIG91dHB1dCBpcyBub3QgcmVuZGVyaW5nIGNvcnJlY3RseSBm b3IgbWUsIHBsZWFzZSB1c2UgZGlmZjEgaW5zdGVhZDogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9y ZmNkaWZmP2RpZmZ0eXBlPS0taHdkaWZmJnVybDI9ZHJhZnQtaWV0Zi1uZXRjb25mLXplcm90b3Vj aC0wNS50eHQNCg0KVGhhbmtzLA0KS2VudA0KDQoNCg0KDQoNCk9uIDMvMTYvMTYsIDI6MzkgUE0s ICJOZXRjb25mIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxuZXRjb25m LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4g d3JvdGU6DQoNCj4NCj5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUg b24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+VGhpcyBkcmFmdCBpcyBhIHdv cmsgaXRlbSBvZiB0aGUgTmV0d29yayBDb25maWd1cmF0aW9uIG9mIHRoZSBJRVRGLg0KPg0KPiAg ICAgICAgVGl0bGUgICAgICAgICAgIDogWmVybyBUb3VjaCBQcm92aXNpb25pbmcgZm9yIE5FVENP TkYgb3IgUkVTVENPTkYgYmFzZWQgTWFuYWdlbWVudA0KPiAgICAgICAgQXV0aG9ycyAgICAgICAg IDogS2VudCBXYXRzZW4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgIE1pa2FlbCBBYnJhaGFt c3Nvbg0KPglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW5ldGNvbmYtemVyb3RvdWNoLTA1 LnR4dA0KPglQYWdlcyAgICAgICAgICAgOiA2OQ0KPglEYXRlICAgICAgICAgICAgOiAyMDE2LTAz LTE2DQo+DQo+QWJzdHJhY3Q6DQo+ICAgVGhpcyBkcmFmdCBwcmVzZW50cyBhIHNlY3VyZSB0ZWNo bmlxdWUgZm9yIGVzdGFibGlzaGluZyBhIE5FVENPTkYgb3INCj4gICBSRVNUQ09ORiBjb25uZWN0 aW9uIGJldHdlZW4gYSBuZXdseSBkZXBsb3llZCBkZXZpY2UsIGNvbmZpZ3VyZWQgd2l0aA0KPiAg IGp1c3QgaXRzIGZhY3RvcnkgZGVmYXVsdCBzZXR0aW5ncywgYW5kIGl0cyBkZXBsb3ltZW50IHNw ZWNpZmljDQo+ICAgbmV0d29yayBtYW5hZ2VtZW50IHN5c3RlbSAoTk1TKS4NCj4NCj4NCj5UaGUg SUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldGNvbmYtemVyb3RvdWNoLw0K Pg0KPlRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtemVyb3RvdWNoLTA1DQo+ DQo+QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPmh0 dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW5ldGNvbmYtemVyb3Rv dWNoLTA1DQo+DQo+DQo+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPnVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+DQo+SW50 ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPmZ0 cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+DQo+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5OZXRjb25mIG1haWxpbmcgbGlzdA0KPk5l dGNvbmZAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dGNvbmYNCg== From nobody Wed Mar 16 12:25:50 2016 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 2E77412DAE2; Wed, 16 Mar 2016 12:25:41 -0700 (PDT) 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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160316192541.32419.92067.idtracker@ietfa.amsl.com> Date: Wed, 16 Mar 2016 12:25:41 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-restconf-10.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 19:25:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration of the IETF. Title : RESTCONF Protocol Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netconf-restconf-10.txt Pages : 116 Date : 2016-03-16 Abstract: This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-restconf-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 16 12:27:57 2016 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 8E6A012DAEA; Wed, 16 Mar 2016 12:27:53 -0700 (PDT) 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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160316192753.32345.65074.idtracker@ietfa.amsl.com> Date: Wed, 16 Mar 2016 12:27:53 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-patch-08.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 19:27:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration of the IETF. Title : YANG Patch Media Type Authors : Andy Bierman Martin Bjorklund Kent Watsen Filename : draft-ietf-netconf-yang-patch-08.txt Pages : 31 Date : 2016-03-16 Abstract: This document describes a method for applying patches to configuration datastores using data defined with the YANG data modeling language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-patch/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-patch-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 16 13:54:21 2016 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 21AD612D558; Wed, 16 Mar 2016 13:54:19 -0700 (PDT) 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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160316205419.25043.28982.idtracker@ietfa.amsl.com> Date: Wed, 16 Mar 2016 13:54:19 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 20:54:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration of the IETF. Title : Zero Touch Provisioning for NETCONF or RESTCONF based Management Authors : Kent Watsen Mikael Abrahamsson Filename : draft-ietf-netconf-zerotouch-06.txt Pages : 70 Date : 2016-03-16 Abstract: This draft presents a secure technique for establishing a NETCONF or RESTCONF connection between a newly deployed device, configured with just its factory default settings, and its deployment specific network management system (NMS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-zerotouch-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 16 13:56:21 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95BF12D558 for ; Wed, 16 Mar 2016 13:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugPDPjHtOpix for ; Wed, 16 Mar 2016 13:56:17 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0114.outbound.protection.outlook.com [65.55.169.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6F9912D5B9 for ; Wed, 16 Mar 2016 13:56:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zm1jw70vlQBqjQDHUYtvCPSttlH5H7AbjOGqtGRBSn4=; b=gOKQV9DxVNWsitBTXwx/biUrVZ6cg8CAu8bEklJaJt64tzd/LW9/deNsKiHwIymThdvSxfdvxmXaw84JNWm5YR+y7X/8U1qXdD+BipmHDdQ70oiiwtF6zbnxp2ACrp8UvZQEVvjnSIP69cRGoMSCeqrENqsufZGw8DzwuH7RPco= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1452.namprd05.prod.outlook.com (10.160.149.13) with Microsoft SMTP Server (TLS) id 15.1.434.16; Wed, 16 Mar 2016 20:56:15 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0434.016; Wed, 16 Mar 2016 20:56:15 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-06.txt Thread-Index: AQHRf8YFj64QmSUWskeruFA0OQHrn59cSfMA Date: Wed, 16 Mar 2016 20:56:15 +0000 Message-ID: <215FC55A-8619-4EF3-A5DD-5DC5B7A43529@juniper.net> References: <20160316205419.25043.28982.idtracker@ietfa.amsl.com> In-Reply-To: <20160316205419.25043.28982.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.160212 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: 1f398e60-d6b4-47f5-9e0f-08d34ddd6a28 x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1452; 5:A6/S131AeCJo4Y074kfo+rr23LV4uf697IZTJ1v6lOqGD7XjS/KVqQZ2wktTs1ydTMV+Ql5bymZyncC7p63pmtdZxEGNSZ73qDjaLTB7AkDxo52NRIRCRrVWtnrfUqIcZ4zdqG81EPv8RJYdB5g0JQ==; 24:XqKCVpjJAHnlOudVVhbpyDaT+yAvzK5KzL4C7wTcoyi5MfibJgceibgk1P9JJ0odEbFxoL6zmP/zRhj/pCOrClHaaKqxgcAMoE+yTyzq0LQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1452; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:CY1PR0501MB1452; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1452; x-forefront-prvs: 08831F51DC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(479174004)(164054003)(377424004)(3846002)(2906002)(2501003)(33656002)(50986999)(3280700002)(15975445007)(3660700001)(5002640100001)(54356999)(87936001)(76176999)(5008740100001)(106116001)(10400500002)(36756003)(19580395003)(122556002)(189998001)(2950100001)(110136002)(107886002)(5004730100002)(19580405001)(1730700002)(77096005)(11100500001)(99286002)(4001350100001)(450100001)(83506001)(2900100001)(82746002)(586003)(6116002)(2351001)(86362001)(230783001)(66066001)(1096002)(92566002)(81166005)(5640700001)(83716003)(1220700001)(102836003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1452; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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: 16 Mar 2016 20:56:15.2592 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1452 Archived-At: Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 20:56:20 -0000 DQpTb3JyeSBmb3IgdGhlIG5vaXNlLCBidXQ6DQoNCiAgQ2hhbmdlIGxvZzoNCg0KICAgICogTWlu b3IgdXBkYXRlDQogICAgKiBBZGRlZCBhIGJ1bmNoIG9mIHJlZmVyZW5jZXMNCiAgICAqIEFkZGVk IG5ldyBzZWN0aW9uIE90aGVyIENvbnNpZGVyYXRpb25zDQoNClRoYW5rcywNCktlbnQNCg0KDQoN Cg0KDQoNCk9uIDMvMTYvMTYsIDQ6NTQgUE0sICJOZXRjb25mIG9uIGJlaGFsZiBvZiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmciIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9m IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQoNCj4NCj5BIE5ldyBJbnRlcm5ldC1E cmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0 b3JpZXMuDQo+VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTmV0d29yayBDb25maWd1 cmF0aW9uIG9mIHRoZSBJRVRGLg0KPg0KPiAgICAgICAgVGl0bGUgICAgICAgICAgIDogWmVybyBU b3VjaCBQcm92aXNpb25pbmcgZm9yIE5FVENPTkYgb3IgUkVTVENPTkYgYmFzZWQgTWFuYWdlbWVu dA0KPiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogS2VudCBXYXRzZW4NCj4gICAgICAgICAgICAg ICAgICAgICAgICAgIE1pa2FlbCBBYnJhaGFtc3Nvbg0KPglGaWxlbmFtZSAgICAgICAgOiBkcmFm dC1pZXRmLW5ldGNvbmYtemVyb3RvdWNoLTA2LnR4dA0KPglQYWdlcyAgICAgICAgICAgOiA3MA0K PglEYXRlICAgICAgICAgICAgOiAyMDE2LTAzLTE2DQo+DQo+QWJzdHJhY3Q6DQo+ICAgVGhpcyBk cmFmdCBwcmVzZW50cyBhIHNlY3VyZSB0ZWNobmlxdWUgZm9yIGVzdGFibGlzaGluZyBhIE5FVENP TkYgb3INCj4gICBSRVNUQ09ORiBjb25uZWN0aW9uIGJldHdlZW4gYSBuZXdseSBkZXBsb3llZCBk ZXZpY2UsIGNvbmZpZ3VyZWQgd2l0aA0KPiAgIGp1c3QgaXRzIGZhY3RvcnkgZGVmYXVsdCBzZXR0 aW5ncywgYW5kIGl0cyBkZXBsb3ltZW50IHNwZWNpZmljDQo+ICAgbmV0d29yayBtYW5hZ2VtZW50 IHN5c3RlbSAoTk1TKS4NCj4NCj4NCj5UaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBm b3IgdGhpcyBkcmFmdCBpczoNCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLW5ldGNvbmYtemVyb3RvdWNoLw0KPg0KPlRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZl cnNpb24gYXZhaWxhYmxlIGF0Og0KPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW5ldGNvbmYtemVyb3RvdWNoLTA2DQo+DQo+QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZl cnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1pZXRmLW5ldGNvbmYtemVyb3RvdWNoLTA2DQo+DQo+DQo+UGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbg0KPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuDQo+DQo+SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJs ZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj5OZXRjb25mIG1haWxpbmcgbGlzdA0KPk5ldGNvbmZAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg== From nobody Wed Mar 16 15:45:56 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C358312D568 for ; Wed, 16 Mar 2016 15:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwokSxOUwFvO for ; Wed, 16 Mar 2016 15:45:52 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (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 A41A212D69D for ; Wed, 16 Mar 2016 15:45:49 -0700 (PDT) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u2GMfmxp028780 for ; Wed, 16 Mar 2016 18:45:43 -0400 Received: from vawvcgsie2k1301.ciena.com (lin1-118-36-35.ciena.com [63.118.36.35]) by mx0b-00103a01.pphosted.com with ESMTP id 21mg7j7nfc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 16 Mar 2016 18:45:43 -0400 Received: from VAWVMDMAIL01.ciena.com (10.4.156.37) by VAWVCGSIE2K1301.ciena.com (10.4.62.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 16 Mar 2016 18:45:43 -0400 Received: from ONWVEXCHHT02.ciena.com (10.128.6.17) by VAWVMDMAIL01.ciena.com (10.4.156.37) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 16 Mar 2016 18:45:42 -0400 Received: from ONWVEXCHMB03.ciena.com ([::1]) by ONWVEXCHHT02.ciena.com ([::1]) with mapi; Wed, 16 Mar 2016 18:45:42 -0400 From: "Larsson, Gustav" To: "netconf@ietf.org" Date: Wed, 16 Mar 2016 18:45:40 -0400 Thread-Topic: deviation that changes config true to false: deviate add or replace? Thread-Index: AdF/053/yueP5tBtR6uogTbt3XKUlA== Message-ID: <23FD825DF7C2A6489CA3B5077FB1DC8603B2F21765@ONWVEXCHMB03.ciena.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_23FD825DF7C2A6489CA3B5077FB1DC8603B2F21765ONWVEXCHMB03c_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-16_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1603160309 Archived-At: Subject: [Netconf] deviation that changes config true to false: deviate add or replace? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 22:45:54 -0000 --_000_23FD825DF7C2A6489CA3B5077FB1DC8603B2F21765ONWVEXCHMB03c_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, When a node defaults to config true and a deviation changes it to config fa= lse, should "deviate add" or "deviate replace" be used? Some YANG implement= ations allow either, some allow only "deviate replace". Perhaps some allow = only "deviate add" but we have not yet seen that. Consider these definitions: container x { leaf y { type string; } } deviation /x/y { deviate replace { <-- Should this be add or replace? config false; } } Section 7.18.3.2 of RFC 6020 says: The argument "add" adds properties to the target node. The properties to add are identified by substatements to the "deviate" statement. If a property can only appear once, the property MUST NOT exist in the target node. The argument "replace" replaces properties of the target node. The properties to replace are identified by substatements to the "deviate" statement. The properties to replace MUST exist in the target node. /x/y is config true by default even though config is not explictly given. S= ection 7.19.1 of RFC 6020 is not clear about whether config is considered t= o exist when defaulted. If config is considered to exist, then "deviate replace" is correct. Otherw= ise, "deviate add" is correct. Technically, RFC 6020 allows only one or the= other but not both in this case, but perhaps a robust implementation shoul= d accept both. YANG file authors need to pick one or the other, so clear guidance would be= helpful. Thanks, Gustav --_000_23FD825DF7C2A6489CA3B5077FB1DC8603B2F21765ONWVEXCHMB03c_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

When a = node defaults to config true and a deviation changes it to config false, sh= ould "deviate add" or "deviate replace" be used? Some Y= ANG implementations allow either, some allow only "deviate replace&quo= t;. Perhaps some allow only "deviate add" but we have not yet see= n that.

 

Consider these definitions:

 

  container x {

=

    leaf y {

      type string;

    }

 = }

 

  deviation /x/y {

  = ;  deviate replace {     <--  Should this = be add or replace?

   &nb= sp;  config false;

  &nbs= p; }

  }

 

Section 7.18.3.2 of RFC = 6020 says:

 

   The argument "add" adds properties to t= he target node.  The

   p= roperties to add are identified by substatements to the "deviate"=

   statement.  If a prop= erty can only appear once, the property MUST NOT

   exist in the target node.

 

   The argument= "replace" replaces properties of the target node.  The=

   properties to replace are ident= ified by substatements to the

 &nbs= p; "deviate" statement.  The properties to replace MUST exis= t in the

   target node.<= /o:p>

 

/x/= y is config true by default even though config is not explictly given. Sect= ion 7.19.1 of RFC 6020 is not clear about whether config is considered to e= xist when defaulted.

 

If config is considered to exist, then "deviate= replace" is correct. Otherwise, "deviate add" is correct. T= echnically, RFC 6020 allows only one or the other but not both in this case= , but perhaps a robust implementation should accept both.

 

YANG file autho= rs need to pick one or the other, so clear guidance would be helpful.<= /o:p>

 

Tha= nks,

Gustav

 

= --_000_23FD825DF7C2A6489CA3B5077FB1DC8603B2F21765ONWVEXCHMB03c_-- From nobody Wed Mar 16 19:06:37 2016 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 F2A8C12D815; Wed, 16 Mar 2016 19:06:32 -0700 (PDT) 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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160317020632.10113.67404.idtracker@ietfa.amsl.com> Date: Wed, 16 Mar 2016 19:06:32 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-server-model-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 02:06:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration of the IETF. Title : NETCONF Server and RESTCONF Server Configuration Models Authors : Kent Watsen Juergen Schoenwaelder Filename : draft-ietf-netconf-server-model-09.txt Pages : 74 Date : 2016-03-16 Abstract: This draft defines a NETCONF server configuration data model and a RESTCONF server configuration data model. These data models enable configuration of the NETCONF and RESTCONF services themselves, including which transports are supported, what ports the servers listen on, call-home parameters, client authentication, and related parameters. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. Please note that no other RFC Editor instructions are specified anywhere else in this document. This document contains references to other drafts in progress, both in the Normative References section, as well as in body text throughout. Please update the following references to reflect their final RFC assignments: o draft-ietf-netconf-restconf o draft-ietf-netconf-call-home o draft-ietf-rtgwg-yang-key-chain Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "VVVV" --> the assigned RFC value for this draft o "XXXX" --> the assigned RFC value for draft-ietf-netconf-restconf o "YYYY" --> the assigned RFC value for draft-ietf-netconf-call-home Artwork in this document contains placeholder values for ports pending IANA assignment from "draft-ietf-netconf-call-home". Please apply the following replacements: o "7777" --> the assigned port value for "netconf-ch-ssh" o "8888" --> the assigned port value for "netconf-ch-tls" o "9999" --> the assigned port value for "restconf-ch-tls" Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2016-03-16" --> the publication date of this draft The following two Appendix sections are to be removed prior to publication: o Appendix A. Change Log o Appendix B. Open Issues Artwork in the document contains a temporary YANG containers that need to be removed. o The "listening-ssh-server" container listed at the end of the artwork in Section 4.2.3 needs to be removed. Please remove the ten lines starting with "container listening-ssh-server {" and ending with "}". o The "listening-tls-server" container listed at the end of the artwork in Section 4.3.3 needs to be removed. Please remove the ten lines starting with "container listening-tls-server {" and ending with "}". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-server-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-server-model-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-server-model-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 16 19:11:05 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFAA212DB01 for ; Wed, 16 Mar 2016 19:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3E2J9vA7bvR for ; Wed, 16 Mar 2016 19:11:00 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0139.outbound.protection.outlook.com [65.55.169.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 821A612DAF1 for ; Wed, 16 Mar 2016 19:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8flPx9rpFYma9OplN6dxXsys9TZ68mzX9yDHpkujzw4=; b=IhhFfDXxBh3aNl8gl9dIBfUiRoaXGFz78HhN6KOYkvHoEe7VRY25EUXtdzQ10FofE+EU/BhqriiUr2tXlM1qH1HxWhZhrY0iDbjWDSk6tV5Xra3+M7YKf98bhYUcwhB8x3LixdHDOaiRbtsdPrvwbKsyGN27LX6+khpQ1NwwHVU= 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.434.16; Thu, 17 Mar 2016 02:10:59 +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.0434.019; Thu, 17 Mar 2016 02:10:58 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-server-model-09.txt Thread-Index: AQHRf/GyMwerlIfXHUaEbUkK7ZbwHJ9coYsA Date: Thu, 17 Mar 2016 02:10:58 +0000 Message-ID: References: <20160317020632.10113.67404.idtracker@ietfa.amsl.com> In-Reply-To: <20160317020632.10113.67404.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.160212 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: 60d44fc4-309a-46bf-7999-08d34e09618a x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 5:Ne1X3wE6C76IUk7vWlHex1ZviJSYfa/AQ1+wQyhaKCZo+ch408Ca3T+N737ghvkKWqE74wJf4sE0CV8hNxHTFTsfkMLnKfVTYiA29kvy156kQzmuRnSUf0UYHVkKM/WjXxqaW/n2fmXs/ZaIMP96pA==; 24:5aT+e34aM4jI47G8L5ut3bXKqlHqdIx5KmEgoQ8UoyMWbFQtpUxcRkRHJUQqgX/T1sUZZbbkXRtHlxZ1wEz9mmwXK90hYL/3qIpK/oOSa08= 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)(8121501046)(3002001)(10201501046); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 0884AAA693 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(479174004)(164054003)(377424004)(377454003)(230783001)(87936001)(2906002)(19580405001)(19580395003)(5004730100002)(2351001)(2501003)(122556002)(5008740100001)(1096002)(6116002)(1220700001)(107886002)(110136002)(92566002)(102836003)(3846002)(586003)(450100001)(82746002)(106116001)(86362001)(66066001)(15975445007)(77096005)(10400500002)(81166005)(36756003)(2950100001)(2900100001)(3280700002)(3660700001)(1730700002)(189998001)(76176999)(54356999)(5640700001)(83716003)(33656002)(50986999)(5002640100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <42DC76E2C9ECF94C8A33BA7D2082AB84@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2016 02:10:58.6571 (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] I-D Action: draft-ietf-netconf-server-model-09.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 02:11:03 -0000 DQpDaGFuZ2UgTG9nOg0KDQoqIFJlbmFtZWQgaWV0Zi1rZXljaGFpbiB0byBpZXRmLXN5c3RlbS1r ZXljaGFpbiB0byBkaXNhbWJpZ3VhdGUNCiAgRnJvbSB0aGUgcm91dGluZyBhcmVhIHdvcmtpbmcg Z3JvdXAncyBrZXljaGFpbiBtb2RlbCAodGhleSANCiAgU2ltaWxhcmx5IHJlbmFtZWQgdGhlaXIg bW9kZWwgZnJvbSBpZXRmLWtleS1jaGFpbiB0byANCiAgaWV0Zi1yb3V0aW5nLWtleS1jaGFpbiku DQoqIEFkZGVkIGFuIGFjdGlvbiBzdGF0ZW1lbnQgdG8gaWV0Zi1zeXN0ZW0ta2V5Y2hhaW4gdG8g bG9hZCBhDQogIHByaXZhdGUga2V5Lg0KKiBBZGRlZCBhIG5vdGlmaWNhdGlvbiBzdGF0ZW1lbnQg dG8gaWV0Zi1zeXN0ZW0ta2V5Y2hhaW4gdG8NCiAgTm90aWZ5IHdoZW4gYSBjZXJ0aWZpY2F0ZSBp cyBuZWFyaW5nIGV4cGlyYXRpb24gYW5kIGJleW9uZC4NCiogQ29udmVydGVkIGFsbCBiaW5hcnkg dHlwZXMgdG8gdXNlIEFTTi4xIERFUiBlbmNvZGluZy4NCiogQWRkZWQgYSBEZXNpZ24gQ29uc2lk ZXJhdGlvbnMgc2VjdGlvbi4NCiogRmlsbGVkIGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9u cyBzZWN0aW9uLg0KKiBSZW1vdmVkIHRoZSBPdGhlciBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLg0K KiBFeHRlbmRlZCB0aGUgRWRpdG9yaWFsIE5vdGUgc2VjdGlvbi4NCiogQWRkZWQgbWFueSBOb3Jt YXRpdmUgYW5kIEluZm9ybWF0aXZlIHJlZmVyZW5jZXMuDQoNClRoYW5rcywNCg0KS2VudA0KDQoN Cg0KDQoNCk9uIDMvMTYvMTYsIDEwOjA2IFBNLCAiTmV0Y29uZiBvbiBiZWhhbGYgb2YgaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBv ZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQo+DQo+QSBOZXcgSW50ZXJuZXQt RHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVj dG9yaWVzLg0KPlRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE5ldHdvcmsgQ29uZmln dXJhdGlvbiBvZiB0aGUgSUVURi4NCj4NCj4gICAgICAgIFRpdGxlICAgICAgICAgICA6IE5FVENP TkYgU2VydmVyIGFuZCBSRVNUQ09ORiBTZXJ2ZXIgQ29uZmlndXJhdGlvbiBNb2RlbHMNCj4gICAg ICAgIEF1dGhvcnMgICAgICAgICA6IEtlbnQgV2F0c2VuDQo+ICAgICAgICAgICAgICAgICAgICAg ICAgICBKdWVyZ2VuIFNjaG9lbndhZWxkZXINCj4JRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0 Zi1uZXRjb25mLXNlcnZlci1tb2RlbC0wOS50eHQNCj4JUGFnZXMgICAgICAgICAgIDogNzQNCj4J RGF0ZSAgICAgICAgICAgIDogMjAxNi0wMy0xNg0KPg0KPkFic3RyYWN0Og0KPiAgIFRoaXMgZHJh ZnQgZGVmaW5lcyBhIE5FVENPTkYgc2VydmVyIGNvbmZpZ3VyYXRpb24gZGF0YSBtb2RlbCBhbmQg YQ0KPiAgIFJFU1RDT05GIHNlcnZlciBjb25maWd1cmF0aW9uIGRhdGEgbW9kZWwuICBUaGVzZSBk YXRhIG1vZGVscyBlbmFibGUNCj4gICBjb25maWd1cmF0aW9uIG9mIHRoZSBORVRDT05GIGFuZCBS RVNUQ09ORiBzZXJ2aWNlcyB0aGVtc2VsdmVzLA0KPiAgIGluY2x1ZGluZyB3aGljaCB0cmFuc3Bv cnRzIGFyZSBzdXBwb3J0ZWQsIHdoYXQgcG9ydHMgdGhlIHNlcnZlcnMNCj4gICBsaXN0ZW4gb24s IGNhbGwtaG9tZSBwYXJhbWV0ZXJzLCBjbGllbnQgYXV0aGVudGljYXRpb24sIGFuZCByZWxhdGVk DQo+ICAgcGFyYW1ldGVycy4NCj4NCj5FZGl0b3JpYWwgTm90ZSAoVG8gYmUgcmVtb3ZlZCBieSBS RkMgRWRpdG9yKQ0KPg0KPiAgIFRoaXMgZHJhZnQgY29udGFpbnMgbWFueSBwbGFjZWhvbGRlciB2 YWx1ZXMgdGhhdCBuZWVkIHRvIGJlIHJlcGxhY2VkDQo+ICAgd2l0aCBmaW5hbGl6ZWQgdmFsdWVz IGF0IHRoZSB0aW1lIG9mIHB1YmxpY2F0aW9uLiAgVGhpcyBub3RlDQo+ICAgc3VtbWFyaXplcyBh bGwgb2YgdGhlIHN1YnN0aXR1dGlvbnMgdGhhdCBhcmUgbmVlZGVkLiAgUGxlYXNlIG5vdGUNCj4g ICB0aGF0IG5vIG90aGVyIFJGQyBFZGl0b3IgaW5zdHJ1Y3Rpb25zIGFyZSBzcGVjaWZpZWQgYW55 d2hlcmUgZWxzZSBpbg0KPiAgIHRoaXMgZG9jdW1lbnQuDQo+DQo+ICAgVGhpcyBkb2N1bWVudCBj b250YWlucyByZWZlcmVuY2VzIHRvIG90aGVyIGRyYWZ0cyBpbiBwcm9ncmVzcywgYm90aA0KPiAg IGluIHRoZSBOb3JtYXRpdmUgUmVmZXJlbmNlcyBzZWN0aW9uLCBhcyB3ZWxsIGFzIGluIGJvZHkg dGV4dA0KPiAgIHRocm91Z2hvdXQuICBQbGVhc2UgdXBkYXRlIHRoZSBmb2xsb3dpbmcgcmVmZXJl bmNlcyB0byByZWZsZWN0IHRoZWlyDQo+ICAgZmluYWwgUkZDIGFzc2lnbm1lbnRzOg0KPg0KPiAg IG8gIGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZg0KPg0KPiAgIG8gIGRyYWZ0LWlldGYtbmV0 Y29uZi1jYWxsLWhvbWUNCj4NCj4gICBvICBkcmFmdC1pZXRmLXJ0Z3dnLXlhbmcta2V5LWNoYWlu DQo+DQo+ICAgQXJ0d29yayBpbiB0aGlzIGRvY3VtZW50IGNvbnRhaW5zIHNob3J0aGFuZCByZWZl cmVuY2VzIHRvIGRyYWZ0cyBpbg0KPiAgIHByb2dyZXNzLiAgUGxlYXNlIGFwcGx5IHRoZSBmb2xs b3dpbmcgcmVwbGFjZW1lbnRzOg0KPg0KPiAgIG8gICJWVlZWIiAtLT4gdGhlIGFzc2lnbmVkIFJG QyB2YWx1ZSBmb3IgdGhpcyBkcmFmdA0KPg0KPiAgIG8gICJYWFhYIiAtLT4gdGhlIGFzc2lnbmVk IFJGQyB2YWx1ZSBmb3IgZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mDQo+DQo+ICAgbyAgIllZ WVkiIC0tPiB0aGUgYXNzaWduZWQgUkZDIHZhbHVlIGZvciBkcmFmdC1pZXRmLW5ldGNvbmYtY2Fs bC1ob21lDQo+ICAgQXJ0d29yayBpbiB0aGlzIGRvY3VtZW50IGNvbnRhaW5zIHBsYWNlaG9sZGVy IHZhbHVlcyBmb3IgcG9ydHMNCj4gICBwZW5kaW5nIElBTkEgYXNzaWdubWVudCBmcm9tICJkcmFm dC1pZXRmLW5ldGNvbmYtY2FsbC1ob21lIi4gIFBsZWFzZQ0KPiAgIGFwcGx5IHRoZSBmb2xsb3dp bmcgcmVwbGFjZW1lbnRzOg0KPg0KPiAgIG8gICI3Nzc3IiAtLT4gdGhlIGFzc2lnbmVkIHBvcnQg dmFsdWUgZm9yICJuZXRjb25mLWNoLXNzaCINCj4NCj4gICBvICAiODg4OCIgLS0+IHRoZSBhc3Np Z25lZCBwb3J0IHZhbHVlIGZvciAibmV0Y29uZi1jaC10bHMiDQo+DQo+ICAgbyAgIjk5OTkiIC0t PiB0aGUgYXNzaWduZWQgcG9ydCB2YWx1ZSBmb3IgInJlc3Rjb25mLWNoLXRscyINCj4NCj4gICBB cnR3b3JrIGluIHRoaXMgZG9jdW1lbnQgY29udGFpbnMgcGxhY2Vob2xkZXIgdmFsdWVzIGZvciB0 aGUgZGF0ZSBvZg0KPiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZHJhZnQuICBQbGVhc2UgYXBwbHkg dGhlIGZvbGxvd2luZyByZXBsYWNlbWVudDoNCj4NCj4gICBvICAiMjAxNi0wMy0xNiIgLS0+IHRo ZSBwdWJsaWNhdGlvbiBkYXRlIG9mIHRoaXMgZHJhZnQNCj4NCj4gICBUaGUgZm9sbG93aW5nIHR3 byBBcHBlbmRpeCBzZWN0aW9ucyBhcmUgdG8gYmUgcmVtb3ZlZCBwcmlvciB0bw0KPiAgIHB1Ymxp Y2F0aW9uOg0KPg0KPiAgIG8gIEFwcGVuZGl4IEEuICBDaGFuZ2UgTG9nDQo+DQo+ICAgbyAgQXBw ZW5kaXggQi4gIE9wZW4gSXNzdWVzDQo+DQo+ICAgQXJ0d29yayBpbiB0aGUgZG9jdW1lbnQgY29u dGFpbnMgYSB0ZW1wb3JhcnkgWUFORyBjb250YWluZXJzIHRoYXQNCj4gICBuZWVkIHRvIGJlIHJl bW92ZWQuDQo+DQo+ICAgbyAgVGhlICJsaXN0ZW5pbmctc3NoLXNlcnZlciIgY29udGFpbmVyIGxp c3RlZCBhdCB0aGUgZW5kIG9mIHRoZQ0KPiAgICAgIGFydHdvcmsgaW4gU2VjdGlvbiA0LjIuMyBu ZWVkcyB0byBiZSByZW1vdmVkLiAgUGxlYXNlIHJlbW92ZSB0aGUNCj4gICAgICB0ZW4gbGluZXMg c3RhcnRpbmcgd2l0aCAiY29udGFpbmVyIGxpc3RlbmluZy1zc2gtc2VydmVyIHsiIGFuZA0KPiAg ICAgIGVuZGluZyB3aXRoICJ9Ii4NCj4NCj4gICBvICBUaGUgImxpc3RlbmluZy10bHMtc2VydmVy IiBjb250YWluZXIgbGlzdGVkIGF0IHRoZSBlbmQgb2YgdGhlDQo+ICAgICAgYXJ0d29yayBpbiBT ZWN0aW9uIDQuMy4zIG5lZWRzIHRvIGJlIHJlbW92ZWQuICBQbGVhc2UgcmVtb3ZlIHRoZQ0KPiAg ICAgIHRlbiBsaW5lcyBzdGFydGluZyB3aXRoICJjb250YWluZXIgbGlzdGVuaW5nLXRscy1zZXJ2 ZXIgeyIgYW5kDQo+ICAgICAgZW5kaW5nIHdpdGggIn0iLg0KPg0KPg0KPlRoZSBJRVRGIGRhdGF0 cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi1zZXJ2ZXItbW9kZWwvDQo+DQo+VGhl cmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1zZXJ2ZXItbW9kZWwtMDkNCj4NCj5B IGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbmV0Y29uZi1zZXJ2ZXItbW9k ZWwtMDkNCj4NCj4NCj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+dW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4NCj5JbnRl cm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ZnRw Oi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4NCj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPk5ldGNvbmYgbWFpbGluZyBsaXN0DQo+TmV0 Y29uZkBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 Y29uZg0K From nobody Wed Mar 16 19:38:06 2016 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 020B212D962; Wed, 16 Mar 2016 19:38:04 -0700 (PDT) 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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160317023804.17078.72577.idtracker@ietfa.amsl.com> Date: Wed, 16 Mar 2016 19:38:04 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 02:38:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration of the IETF. Title : Zero Touch Provisioning for NETCONF or RESTCONF based Management Authors : Kent Watsen Mikael Abrahamsson Filename : draft-ietf-netconf-zerotouch-07.txt Pages : 72 Date : 2016-03-16 Abstract: This draft presents a secure technique for establishing a NETCONF or RESTCONF connection between a newly deployed device, configured with just its factory default settings, and its deployment specific network management system (NMS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-zerotouch-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 16 19:41:15 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4A212D7B4 for ; Wed, 16 Mar 2016 19:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvKolHuvd373 for ; Wed, 16 Mar 2016 19:41:11 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0791.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:791]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5033C12D81C for ; Wed, 16 Mar 2016 19:41:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/zL6bxo+hf2jFc+vMSzqfdK2brLvoJiL5+tFy4S8hAE=; b=AiaYmXnkonZKcoNl9aONsJuYDhmMNtK+etcle6tZWoVE7DQtzqdN9AO/wZzjujWBSkIUbza68fKYiNt2EQDhIBlSskytday/1LTso7C+Oge49fci79jbxpinlvAH9b2aqXDtgJD8gKyobB3Yp2VYsTpsex3n42Y5JkoPeNjw0BU= 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.434.16; Thu, 17 Mar 2016 02:40:53 +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.0434.019; Thu, 17 Mar 2016 02:40:53 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-07.txt Thread-Index: AQHRf/YLJkEtF8vNS0SCHo2pw77vGJ9cqd0A Date: Thu, 17 Mar 2016 02:40:53 +0000 Message-ID: References: <20160317023804.17078.72577.idtracker@ietfa.amsl.com> In-Reply-To: <20160317023804.17078.72577.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.160212 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: 0f81b05b-c274-436c-053a-08d34e0d8f5d x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 5:cmpE2lNlcsgbkA1FKgo8hSB2XT/zWt7VaJ8XpnI+LGVZC6LfqAKzAwspMbxpFDsKErae9ybrW6tva2V71CLWrq/hfrFRROwVxigka74RkhfYkY7IvJarT00hPg7TQoy5qf4EVvFZcg2xtJhptt24DA==; 24:4UWh+CWIIBW4SqyWA/CI9nmAjPCeq8tsxlD0vXO9mZLRkgM0+JAxaIqDRwgtsTC4cuiFRoTGojsk8BxBPYBHVnMgko+qlPzMqMYC4MPhk1E= 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)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0884AAA693 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(377424004)(377454003)(24454002)(164054003)(43544003)(36756003)(5008740100001)(10400500002)(50986999)(54356999)(76176999)(230783001)(33656002)(1220700001)(2906002)(586003)(189998001)(19580405001)(15975445007)(3846002)(92566002)(3660700001)(2900100001)(2950100001)(77096005)(82746002)(19580395003)(2501003)(87936001)(1096002)(110136002)(6116002)(1730700002)(107886002)(3280700002)(102836003)(2351001)(5640700001)(122556002)(5004730100002)(5002640100001)(66066001)(11100500001)(81166005)(450100001)(83716003)(86362001)(106116001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <83194398FF8FDD41A3B08B3327D0469E@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2016 02:40:53.5370 (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: Re: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-07.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 02:41:13 -0000 DQpTb3JyeSBhYm91dCB1cGRhdGluZyB0aGlzIGRvY3VtZW50IHlldCBhZ2FpbiB0b2RheSwgYnV0 IHdoZW4gSSB3YXMgd29ya2luZyBvbiB0aGUgc2VydmVyLW1vZGVsIGRyYWZ0LCBJIHJlYWxpemVk IHRoYXQgSSBoYWQgZm9yZ290dGVuIHRvIHRha2UgY2FyZSBvZiBhIGNvdXBsZSB0aGluZ3M6DQoN CiAgIENoYW5nZSBMb2c6DQogICBvICBNaW5vciB1cGRhdGUNCiAgIG8gIEFkZGVkIGFuIEVkaXRv cmlhbCBOb3RlIHNlY3Rpb24gZm9yIFJGQyBFZGl0b3IuDQogICBvICBVcGRhdGVkIHRoZSBJQU5B IENvbnNpZGVyYXRpb25zIHNlY3Rpb24uDQoNClRoYW5rcywNCg0KS2VudA0KDQoNCg0KT24gMy8x Ni8xNiwgMTA6MzggUE0sICJOZXRjb25mIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmciIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQoNCj4NCj5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFp bGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+VGhp cyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTmV0d29yayBDb25maWd1cmF0aW9uIG9mIHRo ZSBJRVRGLg0KPg0KPiAgICAgICAgVGl0bGUgICAgICAgICAgIDogWmVybyBUb3VjaCBQcm92aXNp b25pbmcgZm9yIE5FVENPTkYgb3IgUkVTVENPTkYgYmFzZWQgTWFuYWdlbWVudA0KPiAgICAgICAg QXV0aG9ycyAgICAgICAgIDogS2VudCBXYXRzZW4NCj4gICAgICAgICAgICAgICAgICAgICAgICAg IE1pa2FlbCBBYnJhaGFtc3Nvbg0KPglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW5ldGNv bmYtemVyb3RvdWNoLTA3LnR4dA0KPglQYWdlcyAgICAgICAgICAgOiA3Mg0KPglEYXRlICAgICAg ICAgICAgOiAyMDE2LTAzLTE2DQo+DQo+QWJzdHJhY3Q6DQo+ICAgVGhpcyBkcmFmdCBwcmVzZW50 cyBhIHNlY3VyZSB0ZWNobmlxdWUgZm9yIGVzdGFibGlzaGluZyBhIE5FVENPTkYgb3INCj4gICBS RVNUQ09ORiBjb25uZWN0aW9uIGJldHdlZW4gYSBuZXdseSBkZXBsb3llZCBkZXZpY2UsIGNvbmZp Z3VyZWQgd2l0aA0KPiAgIGp1c3QgaXRzIGZhY3RvcnkgZGVmYXVsdCBzZXR0aW5ncywgYW5kIGl0 cyBkZXBsb3ltZW50IHNwZWNpZmljDQo+ICAgbmV0d29yayBtYW5hZ2VtZW50IHN5c3RlbSAoTk1T KS4NCj4NCj4NCj5UaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFm dCBpczoNCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldGNv bmYtemVyb3RvdWNoLw0KPg0KPlRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxh YmxlIGF0Og0KPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYt emVyb3RvdWNoLTA3DQo+DQo+QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZh aWxhYmxlIGF0Og0KPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRm LW5ldGNvbmYtemVyb3RvdWNoLTA3DQo+DQo+DQo+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPnVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0 Zi5vcmcuDQo+DQo+SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1v dXMgRlRQIGF0Og0KPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+DQo+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5OZXRjb25mIG1h aWxpbmcgbGlzdA0KPk5ldGNvbmZAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmYNCg== From nobody Thu Mar 17 00:14:22 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7BF12DBB4 for ; Thu, 17 Mar 2016 00:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9btZ8yekht7 for ; Thu, 17 Mar 2016 00:14:19 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C967A12D66D for ; Thu, 17 Mar 2016 00:14:18 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 230C31AE041A; Thu, 17 Mar 2016 08:14:17 +0100 (CET) Date: Thu, 17 Mar 2016 08:14:19 +0100 (CET) Message-Id: <20160317.081419.272881337479200532.mbj@tail-f.com> To: glarsson@ciena.com From: Martin Bjorklund In-Reply-To: <23FD825DF7C2A6489CA3B5077FB1DC8603B2F21765@ONWVEXCHMB03.ciena.com> References: <23FD825DF7C2A6489CA3B5077FB1DC8603B2F21765@ONWVEXCHMB03.ciena.com> 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] deviation that changes config true to false: deviate add or replace? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 07:14:20 -0000 Hi, Could you resend this email to netmod@ietf.org - that's where YANG-specific issues are discussed. /martin "Larsson, Gustav" wrote: > Hello, > > When a node defaults to config true and a deviation changes it to config false, should "deviate add" or "deviate replace" be used? Some YANG implementations allow either, some allow only "deviate replace". Perhaps some allow only "deviate add" but we have not yet seen that. > > Consider these definitions: > > container x { > leaf y { > type string; > } > } > > deviation /x/y { > deviate replace { <-- Should this be add or replace? > config false; > } > } > > Section 7.18.3.2 of RFC 6020 says: > > The argument "add" adds properties to the target node. The > properties to add are identified by substatements to the "deviate" > statement. If a property can only appear once, the property MUST NOT > exist in the target node. > > The argument "replace" replaces properties of the target node. The > properties to replace are identified by substatements to the > "deviate" statement. The properties to replace MUST exist in the > target node. > > /x/y is config true by default even though config is not explictly given. Section 7.19.1 of RFC 6020 is not clear about whether config is considered to exist when defaulted. > > If config is considered to exist, then "deviate replace" is correct. Otherwise, "deviate add" is correct. Technically, RFC 6020 allows only one or the other but not both in this case, but perhaps a robust implementation should accept both. > > YANG file authors need to pick one or the other, so clear guidance would be helpful. > > Thanks, > Gustav > From nobody Fri Mar 18 04:14:35 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9264112D5A4 for ; Fri, 18 Mar 2016 04:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tvSe22scFan for ; Fri, 18 Mar 2016 04:14:33 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D29CF12D681 for ; Fri, 18 Mar 2016 04:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=852; q=dns/txt; s=iport; t=1458299673; x=1459509273; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=Sif+IzAvTRSLmrms3LyJkVF8TOTgP+45EfKmZVw21aM=; b=KDqP6Qent6dcvbJG58Cgdz6kDkwt9Lzpzynbqa9emasol2IEpqh44O5V 7y7ZJY8OzOv3jTNb+wW4YWXoJyVEbM9MuMeiCH5JT13Hm2i2EY7dpW6rW jb3HUkOMcbvdXPAS/04yVKiii6YXoPRm2KPszwqJIPquwC/eUmgcWPXO+ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBABV4utW/xbLJq1evROEDIgKAQEBA?= =?us-ascii?q?QEBZRwLhGsVQDYCBRYLAgsDAgECAUsNCAEBiCOhc49dj14BAQgCHnyFIowAglY?= =?us-ascii?q?BBJdWjgSBZYRKgwQjhTGPBWKDZTyLEQEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,354,1454976000"; d="scan'208";a="634553302" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Mar 2016 11:14:31 +0000 Received: from [10.63.23.98] (dhcp-ensft1-uk-vla370-10-63-23-98.cisco.com [10.63.23.98]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u2IBEULT015913 for ; Fri, 18 Mar 2016 11:14:31 GMT To: "netconf@ietf.org" From: Robert Wilton Message-ID: <56EBE316.6050307@cisco.com> Date: Fri, 18 Mar 2016 11:14:30 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Netconf] NACM data node path rules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 11:14:34 -0000 Hi, Having read the NACM RFC there were a few points that weren't clear to me, and hence I was hoping that someone would be able to clarify please: 1. Does a data node path based rule automatically apply to all descendant children nodes? I presume yes, but the standard doesn't seem to be explicit on this. 2. if the data node path based rules do apply to descendant children nodes then are you allowed to have a less restrictive path based rule on a child node? E.g. one rule that disallows read access to /interfaces, but preceded by a rule that explicitly allows read access to /interfaces/interface/enabled. 3. Likewise, I presume that the default-deny-write and default-deny-all extensions apply to all descendant children nodes. Is that right? I guess that they wouldn't make much sense otherwise. Thanks, Rob From nobody Fri Mar 18 09:44:32 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52DA812D92C for ; Fri, 18 Mar 2016 09:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DhMQV-lEYrY for ; Fri, 18 Mar 2016 09:44:29 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::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 DDEB412D61A for ; Fri, 18 Mar 2016 09:44:28 -0700 (PDT) Received: by mail-lb0-x22e.google.com with SMTP id oe12so92334765lbc.0 for ; Fri, 18 Mar 2016 09:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=R2pKNpO5AnTbal49bGG7K8yX85W+muXkgEA3ibzgzgc=; b=Z6dPrYx2DBVC+ZaXQhuPpyiMcg9jPc7BR7HngdEgHbnzkAhe2LA6Ivxjq8tVB62Ai1 pCEciYJy7q9DwpzrHW6blgqj5DyXw2N/NyCs5RDlECLF2gY1+aljpgvvkG322qgFJoWu DMJxfffYnjIaxDsn1P63Q4ZnP2UyqR5o3yC0/FxjDpQCiQJM5X5BPc2wQN5Vf6cOGNui Bb3m31IqWsblsGH5q4j/YEejS7IqiF3Pi1CdSrooHskUJVFP0705HYQa0oLLa6qofK1L ZYxrIItI7yGfUwm+OEpDBNbetMvgSwYgj3g1kQ8xxUe0j3dU7NF9XmxVr8LFl8Cr/nLQ 3z1w== 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; bh=R2pKNpO5AnTbal49bGG7K8yX85W+muXkgEA3ibzgzgc=; b=QSlSwCMyP9Jzt4jipjUJYt6Y2t/mobBrC6pKeMYZ8FcfHIFmvEJV++uKaAh4oxOj0T poK5IwvMumGUuTTc5SX932qSCSMtHVRdhOiuYA5JDMjrLi6YnMudRgL7L3FxjRqnI3PU 8H8RdwszQHcBUbNnvle6BUYUaTRCD+N7bKmyBjKgDpysjidiIgyb0AUIhcfX7jddwlUs VjfgwkYRAYTlS/IwuNHrUvTvzRrA7q3vC5RJgIvEppH4sASzdI+3Nv5kQBjfE41XIKON VTk6NPun+45gORFox2rtQndE482lYi/c13Ouvir54YkrzamF98vYznnSdv+tVGC3R+jl 09mQ== X-Gm-Message-State: AD7BkJJzC49WgzdzQ9m0yyag3FwHyibXUkSSej2tkYKte/IhLyi0UOmF1xVflAQG3Mx4g091pegMw0wcKBfXJQ== MIME-Version: 1.0 X-Received: by 10.112.156.6 with SMTP id wa6mr6216971lbb.66.1458319467150; Fri, 18 Mar 2016 09:44:27 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Fri, 18 Mar 2016 09:44:27 -0700 (PDT) In-Reply-To: <56EBE316.6050307@cisco.com> References: <56EBE316.6050307@cisco.com> Date: Fri, 18 Mar 2016 09:44:27 -0700 Message-ID: From: Andy Bierman To: Robert Wilton Content-Type: multipart/alternative; boundary=089e01161bf4cf17e6052e5575f5 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] NACM data node path rules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 16:44:31 -0000 --089e01161bf4cf17e6052e5575f5 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 18, 2016 at 4:14 AM, Robert Wilton wrote: > Hi, > > Having read the NACM RFC there were a few points that weren't clear to me, > and hence I was hoping that someone would be able to clarify please: > > 1. Does a data node path based rule automatically apply to all descendant > children nodes? > I presume yes, but the standard doesn't seem to be explicit on this. > > It applies to the entire subtree (unless another rule gives access to the subtree -- this applies to write access. It will be clear in the rfc6536bis draft we are working on. In NETCONF all data access is from the root down, but not true in RESTCONF. > 2. if the data node path based rules do apply to descendant children nodes > then are you allowed to have a less restrictive path based rule on a child > node? E.g. one rule that disallows read access to /interfaces, but > preceded by a rule that explicitly allows read access to > /interfaces/interface/enabled. > you can have less restrictive rules, similar to files permissions (/home is owned by root, but /home/joe is owned by joe). NETCONF supports this mode by using default-operation=none. > 3. Likewise, I presume that the default-deny-write and default-deny-all > extensions apply to all descendant children nodes. Is that right? I guess > that they wouldn't make much sense otherwise. > These rules need to apply to the whole subtree. If a rule exists that allows access then the default-deny-* does not apply. > > Thanks, > Rob > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --089e01161bf4cf17e6052e5575f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 18, 2016 at 4:14 AM, Robert Wilton <rwilton@cisco.com&= gt; wrote:
Hi,

Having read the NACM RFC there were a few points that weren't clear to = me, and hence I was hoping that someone would be able to clarify please:
1. Does a data node path based rule automatically apply to all descendant c= hildren nodes?
I presume yes, but the standard doesn't seem to be explicit on this.

It applies to the entire subtree (unle= ss another rule gives access
to the subtree -- this applies to wr= ite access.

It will be clear in the rfc6536bis dra= ft we are working on.
In NETCONF all data access is from the root= down, but not
true in RESTCONF.

=C2=A0<= /div>
2. if the data node path based rules do apply to descendant children nodes = then are you allowed to have a less restrictive path based rule on a child = node?=C2=A0 E.g. one rule that disallows read access to /interfaces, but pr= eceded by a rule that explicitly allows read access to /interfaces/interfac= e/enabled.


you can have = less restrictive rules, similar to files permissions
(/home is ow= ned by root, but /home/joe is owned by joe).
NETCONF supports thi= s mode by using default-operation=3Dnone.

=C2=A0

=C2=A0
3. Likewise, I presume that the default-deny-write and default-deny-all ext= ensions apply to all descendant children nodes. Is that right?=C2=A0 I gues= s that they wouldn't make much sense otherwise.
These rules need to apply to the whole subtree.
If a= rule exists that allows access then the default-deny-* does not apply.

=C2=A0

Thanks,
Rob


Andy
=C2= =A0

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

--089e01161bf4cf17e6052e5575f5-- From nobody Fri Mar 18 12:10:22 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13DB12D6D5 for ; Fri, 18 Mar 2016 12:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07uUvZMJ3p11 for ; Fri, 18 Mar 2016 12:10:16 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D565212D505 for ; Fri, 18 Mar 2016 12:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8123; q=dns/txt; s=iport; t=1458328216; x=1459537816; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=fb3nNk4DBdKzC3PhrwY2ZQfhgYDl7VnwKpu6kHh0xD8=; b=jT4WTeLldGTGgfrfqv/Fon1X3kqCLfJXCoHcXbR2oHeorVLrg1nW9in8 FgOznLAZsRJRy/vTCh/nL2vV1sQZvhZNOlJGeM/nc/m3aZ1Jyu9aCFFZd w0lp7iRXzoZl+lJNxOXJHFzjophvM1LxHkB4lSMP1/WGNDKAthvP9Yu4p o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKBAAOUuxW/xbLJq1ehBdytS6GaxcBC?= =?us-ascii?q?YUiSgKBfAEBAQEBAWUnhEIBAQQBAQEgSwoBEAsYCRYIAwICCQMCAQIBFR8RBg0?= =?us-ascii?q?GAgEBiCMOsTaPRQEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhh6ERIc8glYFkwSEU?= =?us-ascii?q?44EgWWESoMEI4UxjwZig2U8LopjAQEB?= X-IronPort-AV: E=Sophos;i="5.24,356,1454976000"; d="scan'208,217";a="634565657" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Mar 2016 19:10:13 +0000 Received: from [10.61.104.182] (dhcp-10-61-104-182.cisco.com [10.61.104.182]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u2IJADXt009039; Fri, 18 Mar 2016 19:10:13 GMT To: Andy Bierman References: <56EBE316.6050307@cisco.com> From: Robert Wilton Message-ID: <56EC5295.7070000@cisco.com> Date: Fri, 18 Mar 2016 19:10:13 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------020406060305030508080309" Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] NACM data node path rules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 19:10:22 -0000 This is a multi-part message in MIME format. --------------020406060305030508080309 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Andy, Thanks for the comments, one further clarification please: In your example (/home is owned by root, but /home/joe is owned by joe), if for user "joe" the read access for /home was disallowed (so he couldn't see which other users are present in the system), but read access for /home/joe was permitted, then would a RESTCONF GET request by joe on "/home/joe" return his data? Thanks, Rob On 18/03/2016 16:44, Andy Bierman wrote: > > > On Fri, Mar 18, 2016 at 4:14 AM, Robert Wilton > wrote: > > Hi, > > Having read the NACM RFC there were a few points that weren't > clear to me, and hence I was hoping that someone would be able to > clarify please: > > 1. Does a data node path based rule automatically apply to all > descendant children nodes? > I presume yes, but the standard doesn't seem to be explicit on this. > > > It applies to the entire subtree (unless another rule gives access > to the subtree -- this applies to write access. > > It will be clear in the rfc6536bis draft we are working on. > In NETCONF all data access is from the root down, but not > true in RESTCONF. > > 2. if the data node path based rules do apply to descendant > children nodes then are you allowed to have a less restrictive > path based rule on a child node? E.g. one rule that disallows > read access to /interfaces, but preceded by a rule that explicitly > allows read access to /interfaces/interface/enabled. > > > > you can have less restrictive rules, similar to files permissions > (/home is owned by root, but /home/joe is owned by joe). > NETCONF supports this mode by using default-operation=none. > > > 3. Likewise, I presume that the default-deny-write and > default-deny-all extensions apply to all descendant children > nodes. Is that right? I guess that they wouldn't make much sense > otherwise. > > > These rules need to apply to the whole subtree. > If a rule exists that allows access then the default-deny-* does not > apply. > > > Thanks, > Rob > > > > Andy > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --------------020406060305030508080309 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Andy,

Thanks for the comments, one further clarification please:

In your example (/home is owned by root, but /home/joe is owned by joe), if for user "joe"  the read access for /home was disallowed (so he couldn't see which other users are present in the system), but read access for /home/joe was permitted, then would a RESTCONF GET request by joe on "/home/joe" return his data?

Thanks,
Rob


On 18/03/2016 16:44, Andy Bierman wrote:


On Fri, Mar 18, 2016 at 4:14 AM, Robert Wilton <rwilton@cisco.com> wrote:
Hi,

Having read the NACM RFC there were a few points that weren't clear to me, and hence I was hoping that someone would be able to clarify please:

1. Does a data node path based rule automatically apply to all descendant children nodes?
I presume yes, but the standard doesn't seem to be explicit on this.


It applies to the entire subtree (unless another rule gives access
to the subtree -- this applies to write access.

It will be clear in the rfc6536bis draft we are working on.
In NETCONF all data access is from the root down, but not
true in RESTCONF.

 
2. if the data node path based rules do apply to descendant children nodes then are you allowed to have a less restrictive path based rule on a child node?  E.g. one rule that disallows read access to /interfaces, but preceded by a rule that explicitly allows read access to /interfaces/interface/enabled.


you can have less restrictive rules, similar to files permissions
(/home is owned by root, but /home/joe is owned by joe).
NETCONF supports this mode by using default-operation=none.

 

 
3. Likewise, I presume that the default-deny-write and default-deny-all extensions apply to all descendant children nodes. Is that right?  I guess that they wouldn't make much sense otherwise.

These rules need to apply to the whole subtree.
If a rule exists that allows access then the default-deny-* does not apply.

 

Thanks,
Rob


Andy
 

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


--------------020406060305030508080309-- From nobody Fri Mar 18 12:44:05 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4248212D61D for ; Fri, 18 Mar 2016 12:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9F0qVhtBelp for ; Fri, 18 Mar 2016 12:44:02 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::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 6935912D5A5 for ; Fri, 18 Mar 2016 12:44:01 -0700 (PDT) Received: by mail-lb0-x234.google.com with SMTP id bc4so94992407lbc.2 for ; Fri, 18 Mar 2016 12:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=GeeymCfK+Fp2AvYJ8fw02XYnsqefydPI6EwBKsVHby8=; b=XKBWeAA+vWX6cC+xd0x32LMMBkyvZuKR1vTkVvGOKQXebXFbYb/x5D0M8W0oas0C5s buQa5oqHy7hb3KmoRrF6Uew6mbqv2+vv85VDfgziq2HX6iLkTubxMt8TiquNjrr/en0g U1lbz72QnIqj0G/pdMklwHW1YRPYbDup0Ylao9aGHItqhD45GkYy/BaHzaOiVDxqG+OI ncmn/5jH/+PPQwJmszl+bmSW3fy89eWpd4khF/F7yk1Zpe34t/sUwDnPX4I4sbo+EeFn BbFi3LeXK1hsqntb3iFF7h2ZsgMX0x3WULdlUV+IbU/YJPkOzLSoPKvxGIple17NvUqF BU9w== 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; bh=GeeymCfK+Fp2AvYJ8fw02XYnsqefydPI6EwBKsVHby8=; b=KTAQBbtL7F145YiTyaodTAeoRBs67mGad38TbcAIeNVyNCtQfAB+AZB1549KPTVwHM dj4BB/PPphm0MdT6AgeuP5fQ1TQamHPmprWtjs7SkJoy9iVhXIKoRWLv6L8xkSRQokr+ R8oe+jQkX8b5jZTlmsrjTdlFlSxItckpN+Q/2Sm+UbQFqhKX9J4EwgDz/JMDV2FDHin8 i3D2E9dj9F2RZgaTujJOHLORJYqhNngS9Vd7kTOavHb/UK3BmI4WJJ6wWfjjR9BE6MFj oxT3PyMQx0pw5X8drgpuhg813SGnEb+jDyzNSudMXHhFu9UT0jn2yCOvn3yUoe2qDhxi FrMA== X-Gm-Message-State: AD7BkJJ15joix1tSKozFt9Gi48VmQ82GF9CLIrYmE8mdnA+DdGBWkNwDHHufqiqJnvGg5Y95SSZ5H041m1Ml3g== MIME-Version: 1.0 X-Received: by 10.112.171.163 with SMTP id av3mr6484835lbc.145.1458330239678; Fri, 18 Mar 2016 12:43:59 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Fri, 18 Mar 2016 12:43:59 -0700 (PDT) In-Reply-To: <56EC5295.7070000@cisco.com> References: <56EBE316.6050307@cisco.com> <56EC5295.7070000@cisco.com> Date: Fri, 18 Mar 2016 12:43:59 -0700 Message-ID: From: Andy Bierman To: Robert Wilton Content-Type: multipart/alternative; boundary=001a11c36b36e6d03b052e57f793 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] NACM data node path rules X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 19:44:04 -0000 --001a11c36b36e6d03b052e57f793 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 18, 2016 at 12:10 PM, Robert Wilton wrote: > Hi Andy, > > Thanks for the comments, one further clarification please: > > In your example (/home is owned by root, but /home/joe is owned by joe), > if for user "joe" the read access for /home was disallowed (so he couldn't > see which other users are present in the system), but read access for > /home/joe was permitted, then would a RESTCONF GET request by joe on > "/home/joe" return his data? > > IMO this should work in RESTCONF. The RFC does not support RESTCONF so this is speculation about the WG consensus in the future. > Thanks, > Rob > Andy > > > On 18/03/2016 16:44, Andy Bierman wrote: > > > > On Fri, Mar 18, 2016 at 4:14 AM, Robert Wilton wrote: > >> Hi, >> >> Having read the NACM RFC there were a few points that weren't clear to >> me, and hence I was hoping that someone would be able to clarify please: >> >> 1. Does a data node path based rule automatically apply to all descendant >> children nodes? >> I presume yes, but the standard doesn't seem to be explicit on this. >> >> > It applies to the entire subtree (unless another rule gives access > to the subtree -- this applies to write access. > > It will be clear in the rfc6536bis draft we are working on. > In NETCONF all data access is from the root down, but not > true in RESTCONF. > > > >> 2. if the data node path based rules do apply to descendant children >> nodes then are you allowed to have a less restrictive path based rule on a >> child node? E.g. one rule that disallows read access to /interfaces, but >> preceded by a rule that explicitly allows read access to >> /interfaces/interface/enabled. >> > > > you can have less restrictive rules, similar to files permissions > (/home is owned by root, but /home/joe is owned by joe). > NETCONF supports this mode by using default-operation=none. > > > > > >> 3. Likewise, I presume that the default-deny-write and default-deny-all >> extensions apply to all descendant children nodes. Is that right? I guess >> that they wouldn't make much sense otherwise. >> > > These rules need to apply to the whole subtree. > If a rule exists that allows access then the default-deny-* does not apply. > > > >> >> Thanks, >> Rob >> > > > Andy > > >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > > > --001a11c36b36e6d03b052e57f793 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 18, 2016 at 12:10 PM, Robert Wilton <<= a href=3D"mailto:rwilton@cisco.com" target=3D"_blank">rwilton@cisco.com= > wrote:
=20 =20 =20
Hi Andy,

Thanks for the comments, one further clarification please:

In your example (/home is owned by root, but /home/joe is owned by joe), if for user "joe"=C2=A0 the read access for /home was d= isallowed (so he couldn't see which other users are present in the system), but read access for /home/joe was permitted, then would a RESTCONF GET request by joe on "/home/joe" return his data?


IMO this should work in REST= CONF.
The RFC does not support RESTCONF so this is speculation
about the WG consensus in the future.

=C2= =A0
Thanks,
Rob

Andy
=C2=A0


On 18/03/2016 16:44, Andy Bierman wrote:
=20


On Fri, Mar 18, 2016 at 4:14 AM, Robert Wilton <rwilton@cisco.com> wrote:
Hi,

Having read the NACM RFC there were a few points that weren't clear to me, and hence I was hoping that someone would be able to clarify please:

1. Does a data node path based rule automatically apply to all descendant children nodes?
I presume yes, but the standard doesn't seem to be explicit on this.


It applies to the entire subtree (unless another rule gives access
to the subtree -- this applies to write access.

It will be clear in the rfc6536bis draft we are working on.
In NETCONF all data access is from the root down, but not
true in RESTCONF.

=C2=A0
2. if the data node path based rules do apply to descendant children nodes then are you allowed to have a less restrictive path based rule on a child node?=C2=A0 E.g. one rule that disallows read access to /interfaces, but preceded by a rule that explicitly allows read access to /interfaces/interface/enabled.


you can have less restrictive rules, similar to files permissions
(/home is owned by root, but /home/joe is owned by joe).
NETCONF supports this mode by using default-operation=3Dnone.

=C2=A0

=C2=A0
3. Likewise, I presume that the default-deny-write and default-deny-all extensions apply to all descendant children nodes. Is that right?=C2=A0 I guess that they wouldn= 't make much sense otherwise.

These rules need to apply to the whole subtree.
If a rule exists that allows access then the default-deny-* does not apply.

=C2=A0

Thanks,
Rob


Andy
=C2=A0

_______________________________________________
Netconf mailing list
Netconf= @ietf.org
https://www.ietf.org/mailman/listinfo/net= conf



--001a11c36b36e6d03b052e57f793-- From nobody Sun Mar 20 12:02:54 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FEB12D5B0 for ; Sun, 20 Mar 2016 12:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAyKV8jdA72v for ; Sun, 20 Mar 2016 12:02:50 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 7CE1112D506 for ; Sun, 20 Mar 2016 12:02:50 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id v130so68645258lfd.2 for ; Sun, 20 Mar 2016 12:02:50 -0700 (PDT) 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; bh=1MA6dmvtfhk7x0+Qz2rEp0XbF4GL2MsMMIVm/kKQYQg=; b=yc41+UXt1dQEZX5j8uP/WvyfX/nztokDFH2BuT83bopCMQ2RncIVUzJX8FeGkRoYmV 5yOgLVYOOXbIz+dT9+/PQcYauUGt89ug2VQ0ckqVCK3h1OwnODPG89K5m0YRMUSIHgyj lLcGT5J0/NGwWUWxzr6GpmJWpJ/3Nwx9AP/kZEUVBuH1f7egTlWj3sZ1tfsskl7KnZYa LQKOacn7zfLc+p8JGs7UtR/FfjATYcDut9wrE2OusxeiOyIr8qKumR82/9Q0Da5EMsZS pArhkCOZJpLugBJtnj1e+Ml2wcLI7KVtkbkKF4S8VBl08/wBsf+qKL1H21k6GMYGXFHQ JUdw== 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; bh=1MA6dmvtfhk7x0+Qz2rEp0XbF4GL2MsMMIVm/kKQYQg=; b=QbSp77PCd1BmyhT3por1G3BoCs7u48ylzeFvWdnCm/DhVnfc8qDkCAmo2sPXhBis1O A8JwVQ833/dKlP7xkTfvkKGYwF1cQi+BsuHp3XOcINQEQXY9pYFrtKNnn17amEJ7dn1A u1UZq5F3rTqcdo9/uOanx41BH+4p/WmEo4K8yJJzZ8mryrYbddGO/CrBhbowJviY653b sV6QAnNeOXokmLwm9Dshcnjpma5ngvJDmQ+T5dQL/1LdHWwL2fgMuAe2Cl0ZaqkjXnlX z1d3JFAv3wOgBN/oguEXh0KHNHadeNMe+D0SJ3k5+TcwvBefazRgBh19pvyO1+ZN5jdi yF1A== X-Gm-Message-State: AD7BkJIE3cllEsVjq0NaHKKpT64EqoW7sYVl/enbbe/JWQrQ9lDXtz9Xd4c8Wdd3AlkhY+pbh2d7zMbjNpBzyw== MIME-Version: 1.0 X-Received: by 10.25.30.73 with SMTP id e70mr9618028lfe.13.1458500568649; Sun, 20 Mar 2016 12:02:48 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Sun, 20 Mar 2016 12:02:48 -0700 (PDT) Date: Sun, 20 Mar 2016 12:02:48 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=001a114027584cadf9052e7fa09e Archived-At: Subject: [Netconf] RESTCONF-10 draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 19:02:52 -0000 --001a114027584cadf9052e7fa09e Content-Type: text/plain; charset=UTF-8 Hi, Please review the latest version of the RESTCONF protocol: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ There have been many updates based on the extensive list of review comments: https://tools.ietf.org/html/draft-ietf-netconf-restconf-10#appendix-A.1 This draft addresses all open issues found on github: https://github.com/netconf-wg/restconf/issues Not all requested edits were made. Please review the github issue tracker for details about the editing process. thanks, Andy --001a114027584cadf9052e7fa09e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please review the latest version of= the RESTCONF protocol:

There have been many u= pdates based on the extensive list
of review comments:
=

This draft addresses = all open issues found on github:

Not all requested edits were made. Please rev= iew the
github issue tracker for details about the editing proces= s.


thanks,
Andy

--001a114027584cadf9052e7fa09e-- From nobody Sun Mar 20 12:07:50 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF5912D78B for ; Sun, 20 Mar 2016 12:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFi5Ml7Gf_tZ for ; Sun, 20 Mar 2016 12:07:48 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::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 B374F12D77E for ; Sun, 20 Mar 2016 12:07:47 -0700 (PDT) Received: by mail-lb0-x22e.google.com with SMTP id bc4so115736006lbc.2 for ; Sun, 20 Mar 2016 12:07:47 -0700 (PDT) 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; bh=Sa22DRMBCWKmmMspze62xYDQSuAugz62mE2TJkAzY0M=; b=EaCLJuxmogEw6N7W/VzcpNataGgWX11AdNmHFuSCUtrsUBHBCQ87JxnWi6TJOgf9c7 mygMGAUaxQ15Us27VvYkkQ4oUopSyKtkN0ElJjx6k7ENy/1G6uiC0w/883qMl8yNA0ny /pLJqjM2z7M+YxyFwSroiR2RpA3OqUDLODteZpG8EUwVYh22Hn3lsayGpUbWaFWxhqbM EqQ/2H4sWIo/aw8RvzgM1Ms/Z0nxwxHfdvio6w3lsx9zbwkqyeW/ZAw9llep5FOLFJju EXrKqpZXEuYibKITLoMzxCES45bRFjiig2ormORUhaZPyjNuWaSmLxWhZ5thK1WXlFHa C1Rw== 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; bh=Sa22DRMBCWKmmMspze62xYDQSuAugz62mE2TJkAzY0M=; b=AQLneyzepRpMEcXWHztoKSyscMSxY+1YiHQr1sER6wGlmIAAWN//056UcFlYMCMtC6 gvKYD7JACR7laiefOYnhAnLwNPO4Ux/j0cK6xSeezoE8wuoGO6cft4fwmyd8GgPSiGcq 3JvqLRwxceySW3m0Svchyo4HpAXdTNOijxpSkdV4/qThUiqT9DdY3qFJrNi0WdJNgTiF LP4gXHJqQkoN8VoO3U27o+QMvLQIHP/ZK1ZX/hjcHZI0esm/Vny2AIgZfYylcO8mpbUR DQsmXfmHTd4XyJTiMoAtNHWpZx34d9XT6wWorHj58d5q9p2T5pjczlZnyUyTt6GYjvFI xdSw== X-Gm-Message-State: AD7BkJKQSbuDTEoFF3cMB6EKrohIo+rvkPVcietIPdV+YaGXY5sDJzx8/n6fHu2Lhi0hOSMDyxvJWBJj6YL3VA== MIME-Version: 1.0 X-Received: by 10.112.147.101 with SMTP id tj5mr7629165lbb.119.1458500865893; Sun, 20 Mar 2016 12:07:45 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Sun, 20 Mar 2016 12:07:45 -0700 (PDT) Date: Sun, 20 Mar 2016 12:07:45 -0700 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=047d7b3a8bd20466f6052e7fb23f Archived-At: Subject: [Netconf] YANG Patch -08 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 19:07:49 -0000 --047d7b3a8bd20466f6052e7fb23f Content-Type: text/plain; charset=UTF-8 Hi, Please review the latest version of the YANG Patch Media Type: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-patch/ There have been some updates based on the review comments: https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-08#appendix-B.1 This draft addresses all open issues found on github: https://github.com/netconf-wg/yang-patch/issues thanks, Andy --047d7b3a8bd20466f6052e7fb23f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please review the latest version of= the YANG Patch Media Type:

There have bee= n some updates based on the review comments:


This draft addresses all open issues foun= d on github:
<= br>


thanks,
Andy

--047d7b3a8bd20466f6052e7fb23f-- From nobody Mon Mar 21 03:36:01 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF3B12D54C for ; Mon, 21 Mar 2016 03:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjFQZl5XaMX8 for ; Mon, 21 Mar 2016 03:35:58 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 395CB12D653 for ; Mon, 21 Mar 2016 03:35:58 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 7B8341CC00C3 for ; Mon, 21 Mar 2016 11:36:04 +0100 (CET) From: Ladislav Lhotka To: Netconf User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 21 Mar 2016 11:35:54 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [Netconf] RESTCONF examples X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 10:36:00 -0000 Hi, I am confused by this example in draft-ietf-netconf-restconf-10, appendix D.3.4: POST /restconf/data/example-jukebox:jukebox/ playlist=Foo-One?insert=first HTTP/1.1 Host: example.com Content-Type: application/yang.data+json { "example-jukebox:song" : { "index" : 1, "id" : "/example-jukebox:jukebox/library/ artist=Foo%20Fighters/album=Wasting%20Light/song=Rope" } } The text says "..., a new first entry in the "Foo-One" playlist is being created." It seems to me that in fact a new first entry of the "song" list inside the "Foo-One" playlist is supposed to be created. And then the request should IMO be POST /restconf/data/example-jukebox:jukebox/ playlist=Foo-One/song?insert=first HTTP/1.1 Host: example.com Content-Type: application/yang.data+json { "index" : 1, "id" : "/example-jukebox:jukebox/library/ artist=Foo%20Fighters/album=Wasting%20Light/song=Rope" } That is, the client is posting to the "song" resource, namely creating its new first entry whose content is specified in the body. Am I missing something? Thanks, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Mar 21 04:30:32 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C2912D728 for ; Mon, 21 Mar 2016 04:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRSWCRa2JQ-t for ; Mon, 21 Mar 2016 04:30:28 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (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 DF13812D554 for ; Mon, 21 Mar 2016 04:30:27 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.15.2/8.15.2) with ESMTPS id u2LBUPE8013355 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Mar 2016 11:30:25 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id u2LBUOKZ027856 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Mar 2016 12:30:24 +0100 Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.279.2; Mon, 21 Mar 2016 12:30:23 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.154]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0279.002; Mon, 21 Mar 2016 12:30:23 +0100 From: "Ersue, Mehmet (Nokia - DE/Munich)" To: EXT Andy Bierman , Netconf Thread-Topic: [Netconf] RESTCONF-10 draft Thread-Index: AQHRgtsfVf2wKDoe9EeIjuDWWh8lwZ9jwXYQ Date: Mon, 21 Mar 2016 11:30:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.121] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81CB863FEDEMUMBX005nsnin_" 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: 10366 X-purgate-ID: 151667::1458559825-000079EB-9249D2BC/0/0 Archived-At: Subject: Re: [Netconf] RESTCONF-10 draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 11:30:31 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F81CB863FEDEMUMBX005nsnin_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBORVRDT05GIFdHLA0KDQpmaXJzdCBvZiBhbGwgTWFueSBUaGFua3MgdG8gQW5keSwgTWFy dGluIGFuZCBLZW50IGZvciBhZGRyZXNzaW5nIHRoZSBudW1lcm91cyBXR0xDIGNvbW1lbnRzLg0K DQpSRVNUQ09ORiBpcyBhIG1ham9yIE5FVENPTkYgZG9jdW1lbnQgZ29pbmcgdG8gYmUgcHVibGlz aGVkIHNvb24uDQoNCkkgd291bGQgbGlrZSB0byBhc2sgYWxsIHRvIHJldmlldyBhbmQgdmVyaWZ5 IHRoZSBjaGFuZ2VzIG1hZGUgaW4gdGhlIGRvY3VtZW50Lg0KSWYgdGhlcmUgaXMgYW55dGhpbmcg bWlzc2luZyBvciBpbnN1ZmZpY2llbnRseSBhZGRyZXNzZWQsIHBsZWFzZSBzZW5kIHlvdXIgY29t bWVudHMgdG8gTkVUQ09ORiBNTCBhdCB0aGUgbGF0ZXN0IGJ5IE1hcmNoIDMxLCAyMDE2IEVPQiBQ RFQuDQoNCk91ciBhaW0gaXMgdG8gZ28gdG8gQUQgYW5kIElFU0cgcmV2aWV3IGFmdGVyIHRoYXQu DQoNCkJSLA0KTWVobWV0DQoNCkZyb206IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFWFQgQW5keSBCaWVybWFuDQpTZW50OiBTdW5kYXksIE1h cmNoIDIwLCAyMDE2IDg6MDMgUE0NClRvOiBOZXRjb25mIDxuZXRjb25mQGlldGYub3JnPg0KU3Vi amVjdDogW05ldGNvbmZdIFJFU1RDT05GLTEwIGRyYWZ0DQoNCkhpLA0KDQpQbGVhc2UgcmV2aWV3 IHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgUkVTVENPTkYgcHJvdG9jb2w6DQpodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYvDQoNClRo ZXJlIGhhdmUgYmVlbiBtYW55IHVwZGF0ZXMgYmFzZWQgb24gdGhlIGV4dGVuc2l2ZSBsaXN0DQpv ZiByZXZpZXcgY29tbWVudHM6DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW5ldGNvbmYtcmVzdGNvbmYtMTAjYXBwZW5kaXgtQS4xDQoNClRoaXMgZHJhZnQgYWRkcmVz c2VzIGFsbCBvcGVuIGlzc3VlcyBmb3VuZCBvbiBnaXRodWI6DQpodHRwczovL2dpdGh1Yi5jb20v bmV0Y29uZi13Zy9yZXN0Y29uZi9pc3N1ZXMNCg0KTm90IGFsbCByZXF1ZXN0ZWQgZWRpdHMgd2Vy ZSBtYWRlLiBQbGVhc2UgcmV2aWV3IHRoZQ0KZ2l0aHViIGlzc3VlIHRyYWNrZXIgZm9yIGRldGFp bHMgYWJvdXQgdGhlIGVkaXRpbmcgcHJvY2Vzcy4NCg0KDQp0aGFua3MsDQpBbmR5DQoNCg== --_000_E4DE949E6CE3E34993A2FF8AE79131F81CB863FEDEMUMBX005nsnin_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMDAwMDk5Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250 LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMDk5Ij5EZWFy IE5FVENPTkYgV0csPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMDk5Ij5m aXJzdCBvZiBhbGwgTWFueSBUaGFua3MgdG8gQW5keSwgTWFydGluIGFuZCBLZW50IGZvciBhZGRy ZXNzaW5nIHRoZSBudW1lcm91cyBXR0xDIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMDk5Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzAwMDA5OSI+UkVTVENPTkYgaXMgYSBtYWpvciBORVRDT05GIGRvY3VtZW50 IGdvaW5nIHRvIGJlIHB1Ymxpc2hlZCBzb29uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMDk5Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzAwMDA5OSI+SSB3b3VsZCBsaWtlIHRvIGFzayBhbGwgdG8gcmV2aWV3IGFuZCB2ZXJp ZnkgdGhlIGNoYW5nZXMgbWFkZSBpbiB0aGUgZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwOTkiPklm IHRoZXJlIGlzIGFueXRoaW5nIG1pc3Npbmcgb3IgaW5zdWZmaWNpZW50bHkgYWRkcmVzc2VkLCBw bGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIE5FVENPTkYgTUwgYXQgdGhlIGxhdGVzdCBieSBN YXJjaCAzMSwgMjAxNiBFT0IgUERULjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMDk5Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzAwMDA5OSI+T3VyIGFpbSBpcyB0byBnbyB0byBBRCBhbmQgSUVTRyByZXZpZXcgYWZ0ZXIgdGhh dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzAwMDA5OSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAwMENDIj5C UiwNCjxicj4NCk1laG1ldCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE5ldGNvbmYgW21h aWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVYVCBB bmR5IEJpZXJtYW48YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBNYXJjaCAyMCwgMjAxNiA4OjAz IFBNPGJyPg0KPGI+VG86PC9iPiBOZXRjb25mICZsdDtuZXRjb25mQGlldGYub3JnJmd0Ozxicj4N CjxiPlN1YmplY3Q6PC9iPiBbTmV0Y29uZl0gUkVTVENPTkYtMTAgZHJhZnQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSByZXZpZXcgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRo ZSBSRVNUQ09ORiBwcm90b2NvbDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi88L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGhhdmUgYmVlbiBtYW55 IHVwZGF0ZXMgYmFzZWQgb24gdGhlIGV4dGVuc2l2ZSBsaXN0PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5vZiByZXZpZXcgY29tbWVudHM6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYt MTAjYXBwZW5kaXgtQS4xIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1u ZXRjb25mLXJlc3Rjb25mLTEwI2FwcGVuZGl4LUEuMTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBkcmFmdCBhZGRyZXNzZXMgYWxs IG9wZW4gaXNzdWVzIGZvdW5kIG9uIGdpdGh1Yjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9uZXRj b25mLXdnL3Jlc3Rjb25mL2lzc3VlcyI+aHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvcmVz dGNvbmYvaXNzdWVzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Ob3QgYWxsIHJlcXVlc3RlZCBlZGl0cyB3ZXJlIG1hZGUuIFBsZWFzZSBy ZXZpZXcgdGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5naXRodWIgaXNzdWUgdHJhY2tlciBmb3IgZGV0YWlscyBhYm91dCB0aGUgZWRpdGluZyBw cm9jZXNzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPnRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_E4DE949E6CE3E34993A2FF8AE79131F81CB863FEDEMUMBX005nsnin_-- From nobody Mon Mar 21 11:49:56 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A488C12D868 for ; Mon, 21 Mar 2016 11:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vx0uKd70RGCV for ; Mon, 21 Mar 2016 11:49:41 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E606912D861 for ; Mon, 21 Mar 2016 11:49:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2778; q=dns/txt; s=iport; t=1458586180; x=1459795780; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=722AWLaxyJMUTOXFUs31XXBhvgGaPmQfS3IMD5I/844=; b=eirzzVvmHS6Xwq1YcuPa4PfYwlPtQC6fB4R6RUoNU+F6jtxinV1EEqaU 4k5z+6bkCpxOQO1AsV9dYuhHso2h/+VqeneVo8767UUFlP24T5aW4lisw HTBp/CN6RKc0P6koEGA6tAyXgw3Yz9tftVC74dU1747LG+JiLCduT+7fc s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAgAFQfBW/49dJa1egzRTcga6HwENg?= =?us-ascii?q?XAXCoUiSgKBLTgUAQEBAQEBAWQnhEEBAQEEAQEBNzQbAgEIEQQBAQ4RCQcnCxQ?= =?us-ascii?q?JCAIEARKIJw6+dAEBAQEBAQEBAQEBAQEBAQEBAQEBAREEimKEJIVuBYdgj3cBh?= =?us-ascii?q?XCIE4FlhEqIWGqOGwEeAQFCg2VqiFojGn4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,373,1454976000"; d="scan'208";a="251802272" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Mar 2016 18:49:39 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u2LIndiQ028188 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Mar 2016 18:49:39 GMT Received: from xch-rtp-003.cisco.com (64.101.220.143) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 21 Mar 2016 14:49:39 -0400 Received: from xch-rtp-003.cisco.com ([64.101.220.143]) by XCH-RTP-003.cisco.com ([64.101.220.143]) with mapi id 15.00.1104.009; Mon, 21 Mar 2016 14:49:38 -0400 From: "Alberto Gonzalez Prieto (albertgo)" To: "Eric Voit (evoit)" , Mahesh Jethanandani , NETCONF Thread-Topic: [Netconf] Agenda Request Thread-Index: AQHReCCXnxWOt0Dw+0uIkww9TXgdy59OZWuAgBZC+IA= Date: Mon, 21 Mar 2016 18:49:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.204.182] Content-Type: text/plain; charset="us-ascii" Content-ID: <127FB477158F7649AA455B8EEC812C73@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] Agenda Request X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 18:49:42 -0000 X-List-Received-Date: Mon, 21 Mar 2016 18:49:42 -0000 Hello, Our proposal for RFC5277-bis has been submitted (https://datatracker.ietf.org/doc/draft-gonzalez-netconf-5277bis) You can find an high-level summary of the draft below. We would like to present it in the NETCONF session at IETF 95. Length: 10 minutes Presenter: Eric Voit Thanks, Alberto, Alex, Eric, Einar, and Ambika This draft targets charter item #6 of the NETCONF WG. It enhances RFC 5277, addressing limitations identified during the design of draft-ietf-netconf-yang-push-01 and draft-voit-netconf-restconf-yang-push-02 Goals of charter item #6, (all of them addressed in the draft): - Ability to delete subscriptions without closing the client session. - Ability to modify existing subscriptions. - Ability to have multiple subscriptions on a client session. - Do not affect older clients. - Convert data models in RFC 5277 into YANG. The draft also includes the following features: - Subscription negotiation. - Static subscriptions. (i.e., configuration-driven susbcription) - Subscription suspension and termination by server. - Support for multiple encodings (e.g., json). On 3/7/16, 2:52 PM, "Netconf on behalf of Eric Voit (evoit)" wrote: >Hi Mahesh & Mehmet, > >Below are the two topics we were hoping present . > >Topics: >(1) Yang Subscriptions > - draft-ietf-netconf-yang-push > - WG draft revisions > - IETF hackathon demo results: yang-push interworking with >OpenDaylight=20 > - draft-voit-netconf-restconf-yang-push > - New draft this week: shrunk to cover just Restconf & HTTP >transports > - Discussion: do we have the desired WG division for these drafts? > >(2) RFC5277bis=20 > - Proposal coming into WG before submission cut-off date > >Length:=20 >(1) Yang Subscriptions - 20 min >(2) RFC5277bis - 10 min > >Presenter:=20 > - Eric Voit (on behalf of the authors) > >Thanks, >Eric, Alex, Alberto, Ambika, Einar > >------------------- >From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh >Jethanandani >Sent: Sunday, March 06, 2016 10:22 PM >To: NETCONF >Subject: [Netconf] Agenda Request > >It is that time again where we ask if you want to present in the NETCONF >session at IETF 95. > >Please indicate > >Topic: >Length: >Presenter: > >in your request for the slot. > >All this assumes that you have published/updated a draft on the mailing >list and have garnered some discussion around it. If not, there is still >time to do that before the meeting. > >Cheers. > >Mahesh & Mehmet > > > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Mar 21 16:26:31 2016 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 4FE8612D170; Mon, 21 Mar 2016 16:26:28 -0700 (PDT) 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.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321232628.12255.54147.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 16:26:28 -0700 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-push-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 23:26:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration of the IETF. Title : Subscribing to YANG datastore push updates Authors : Alexander Clemm Alberto Gonzalez Prieto Eric Voit Ambika Prasad Tripathy Einar Nilsen-Nygaard Filename : draft-ietf-netconf-yang-push-02.txt Pages : 65 Date : 2016-03-21 Abstract: This document defines a subscription and push mechanism for YANG datastores. This mechanism allows client applications to request updates from a YANG datastore, which are then pushed by the server to a receiver per a subscription policy, without requiring additional client requests. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-yang-push-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-push-02 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 Mar 22 00:58:27 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBC512D672 for ; Tue, 22 Mar 2016 00:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxSAmAdgafl4 for ; Tue, 22 Mar 2016 00:58:21 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BD25912D541 for ; Tue, 22 Mar 2016 00:48:38 -0700 (PDT) Received: from localhost (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id 31B5E1AE028F; Tue, 22 Mar 2016 08:48:37 +0100 (CET) Date: Tue, 22 Mar 2016 08:48:41 +0100 (CET) Message-Id: <20160322.084841.1381513591842449169.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] RESTCONF examples X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 07:58:26 -0000 Ladislav Lhotka wrote: > Hi, > > I am confused by this example in draft-ietf-netconf-restconf-10, > appendix D.3.4: > > POST /restconf/data/example-jukebox:jukebox/ > playlist=Foo-One?insert=first HTTP/1.1 > Host: example.com > Content-Type: application/yang.data+json > > { > "example-jukebox:song" : { > "index" : 1, > "id" : "/example-jukebox:jukebox/library/ > artist=Foo%20Fighters/album=Wasting%20Light/song=Rope" > } > } > > The text says "..., a new first entry in the "Foo-One" playlist is being > created." > > It seems to me that in fact a new first entry of the "song" list inside > the "Foo-One" playlist is supposed to be created. You are right: OLD: In this example, a new first entry in the "Foo-One" playlist is being created. NEW: In this example, a new first song entry in the "Foo-One" playlist is being created. > And then the request > should IMO be > > POST /restconf/data/example-jukebox:jukebox/ > playlist=Foo-One/song?insert=first HTTP/1.1 > Host: example.com > Content-Type: application/yang.data+json > > { > "index" : 1, > "id" : "/example-jukebox:jukebox/library/ > artist=Foo%20Fighters/album=Wasting%20Light/song=Rope" > } > > That is, the client is posting to the "song" resource No, there is no "song" resource, since all data resources are YANG data nodes. /martin >, namely creating > its new first entry whose content is specified in the body. > > Am I missing something? > > Thanks, Lada > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Tue Mar 22 01:37:07 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5042612D7BE for ; Tue, 22 Mar 2016 01:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5mZrCHrWAD9 for ; Tue, 22 Mar 2016 01:37:01 -0700 (PDT) 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 79E0812D784 for ; Tue, 22 Mar 2016 01:37:00 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:b0ca:cea3:dd8b:f5c0] (unknown [IPv6:2001:718:1a02:1:b0ca:cea3:dd8b:f5c0]) by mail.nic.cz (Postfix) with ESMTPSA id 000CD1819F0; Tue, 22 Mar 2016 09:36:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1458635819; bh=LRvp8I0FsAr7dKsL+N1TBvTi5Yw9EtxS7737n/QA0y8=; h=From:Date:To; b=BDOfDfBuT8QhMdYoQwYdtt+mfCok83um90cdlx2mJ8feo5cCGcHkBxiMxqJ4jDNKJ R99IoQbTY3AUgvXE0YBuXB6mCdNR7uXhzoE2zaiGmpRzPpz8jYHUgnpvtQF/QZqBSX X/xacpWViGuKRRwTQH22F4Q+cbYW/K+orSLjVDx0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160322.084841.1381513591842449169.mbj@tail-f.com> Date: Tue, 22 Mar 2016 09:36:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160322.084841.1381513591842449169.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF examples X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 08:37:04 -0000 > On 22 Mar 2016, at 08:48, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >> Hi, >>=20 >> I am confused by this example in draft-ietf-netconf-restconf-10, >> appendix D.3.4: >>=20 >> POST /restconf/data/example-jukebox:jukebox/ >> playlist=3DFoo-One?insert=3Dfirst HTTP/1.1 >> Host: example.com >> Content-Type: application/yang.data+json >>=20 >> { >> "example-jukebox:song" : { >> "index" : 1, >> "id" : "/example-jukebox:jukebox/library/ >> artist=3DFoo%20Fighters/album=3DWasting%20Light/song=3DRo= pe" >> } >> } >>=20 >> The text says "..., a new first entry in the "Foo-One" playlist is = being >> created." >>=20 >> It seems to me that in fact a new first entry of the "song" list = inside >> the "Foo-One" playlist is supposed to be created. >=20 > You are right: >=20 > OLD: >=20 > In this example, a new first entry in the "Foo-One" playlist > is being created. >=20 > NEW: >=20 > In this example, a new first song entry in the "Foo-One" playlist > is being created. >=20 >=20 >> And then the request >> should IMO be >>=20 >> POST /restconf/data/example-jukebox:jukebox/ >> playlist=3DFoo-One/song?insert=3Dfirst HTTP/1.1 >> Host: example.com >> Content-Type: application/yang.data+json >>=20 >> { >> "index" : 1, >> "id" : "/example-jukebox:jukebox/library/ >> artist=3DFoo%20Fighters/album=3DWasting%20Light/song=3DRope" >> } >>=20 >> That is, the client is posting to the "song" resource >=20 > No, there is no "song" resource, since all data resources are YANG > data nodes. Are you saying that the user-ordered "song" list is *not* a YANG data = node? Also, the body { "example-jukebox:song" : { "index" : 1, "id" : "/example-jukebox:jukebox/library/ artist=3DFoo%20Fighters/album=3DWasting%20Light/song=3DRope= " } } is counter-intuitive, to say the least, because it looks like "song" is = a container, which it isn't. Lada >=20 >=20 > /martin >=20 >=20 >> , namely creating >> its new first entry whose content is specified in the body. >>=20 >> Am I missing something? >>=20 >> Thanks, Lada >>=20 >> --=20 >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=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 Tue Mar 22 06:10:43 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F9C12D78A for ; Tue, 22 Mar 2016 06:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6MGW5jQ1s7T for ; Tue, 22 Mar 2016 06:10:37 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6B61F12D75F for ; Tue, 22 Mar 2016 06:10:36 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 738721CC0052; Tue, 22 Mar 2016 14:10:44 +0100 (CET) From: Ladislav Lhotka To: Martin =?utf-8?Q?Bj=C3=B6rklund?= In-Reply-To: References: <20160322.084841.1381513591842449169.mbj@tail-f.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 22 Mar 2016 14:10:33 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF examples X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 13:10:42 -0000 Hi, I checked the book RESTful Web Services by Richardson & Ruby, and they illustrate a recommended design of resources with the following example: | Operation | HTTP action | |----------------+------------------| | List the users | GET /users | | Create a user | POST /users | | View a user | GET /users/52 | | Modify a user | PUT /users/52 | | Delete a user | DELETE /users/52 | I think RESTCONF should follow the same pattern because this is what developers are used to. The logic of some examples in the RESTCONF spec - namely what's a resource and what's its value - isn't very clear to me. Lada Ladislav Lhotka writes: >> On 22 Mar 2016, at 08:48, Martin Bjorklund wrote: >> >> Ladislav Lhotka wrote: >>> Hi, >>> >>> I am confused by this example in draft-ietf-netconf-restconf-10, >>> appendix D.3.4: >>> >>> POST /restconf/data/example-jukebox:jukebox/ >>> playlist=Foo-One?insert=first HTTP/1.1 >>> Host: example.com >>> Content-Type: application/yang.data+json >>> >>> { >>> "example-jukebox:song" : { >>> "index" : 1, >>> "id" : "/example-jukebox:jukebox/library/ >>> artist=Foo%20Fighters/album=Wasting%20Light/song=Rope" >>> } >>> } >>> >>> The text says "..., a new first entry in the "Foo-One" playlist is being >>> created." >>> >>> It seems to me that in fact a new first entry of the "song" list inside >>> the "Foo-One" playlist is supposed to be created. >> >> You are right: >> >> OLD: >> >> In this example, a new first entry in the "Foo-One" playlist >> is being created. >> >> NEW: >> >> In this example, a new first song entry in the "Foo-One" playlist >> is being created. >> >> >>> And then the request >>> should IMO be >>> >>> POST /restconf/data/example-jukebox:jukebox/ >>> playlist=Foo-One/song?insert=first HTTP/1.1 >>> Host: example.com >>> Content-Type: application/yang.data+json >>> >>> { >>> "index" : 1, >>> "id" : "/example-jukebox:jukebox/library/ >>> artist=Foo%20Fighters/album=Wasting%20Light/song=Rope" >>> } >>> >>> That is, the client is posting to the "song" resource >> >> No, there is no "song" resource, since all data resources are YANG >> data nodes. > > Are you saying that the user-ordered "song" list is *not* a YANG data node? > > Also, the body > > { > "example-jukebox:song" : { > "index" : 1, > "id" : "/example-jukebox:jukebox/library/ > artist=Foo%20Fighters/album=Wasting%20Light/song=Rope" > } > } > > is counter-intuitive, to say the least, because it looks like "song" is a container, which it isn't. > > Lada > >> >> >> /martin >> >> >>> , namely creating >>> its new first entry whose content is specified in the body. >>> >>> Am I missing something? >>> >>> Thanks, Lada >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Mar 22 07:17:15 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2971212D82C for ; Tue, 22 Mar 2016 07:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpHdmX8aWBpz for ; Tue, 22 Mar 2016 07:17:12 -0700 (PDT) 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 03EDC12D81C for ; Tue, 22 Mar 2016 07:16:52 -0700 (PDT) Received: by mail-lb0-x233.google.com with SMTP id oe12so164149416lbc.0 for ; Tue, 22 Mar 2016 07:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Thvn86s8lFSWoe4uTCKL7B0xG+w+jzPJWoo5siTMMeU=; b=SqoGCSh8pVbYaq3NtAzy8Ox/qbNdbSkEbgrpzEewxL60LGaqUBHYhwIjCfW7jc5yRE 7lUrb/X90UtnAN6ItoSklq7GXH+1wEw8lMaBSoZxfmNHchEPSmhrsNKG1EFKboDaMEj/ AQXVsvb7M784omDgOMgiTfTKegHTGx683zIy6qkJHpxSvVxH/Zw624hBmDe2F5oMUx21 FvfFlLnsSaGtQVBn26ZsUPWjAU3PUphbv8vbgLdh88VZEsYROCCcC+IvARyxCXzdesjE c6Zk4tdHItwYJ5egVn/7VBK6i0QTLw1xczl7Ue4EHpm7nZFx5DjuNU0IeQRiaLkNFFBk 7VXg== 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; bh=Thvn86s8lFSWoe4uTCKL7B0xG+w+jzPJWoo5siTMMeU=; b=Q1woQpeg8O+r8DaL5E2xhRCVHOMzU1NT9tsB7XaQ9x3YiCrE/nVJO02ycyl/qRq3s0 CxZS9XPR4qSPUi8HAlNPkTtt8IYT4nrbedTopZEATiW9X3ubV6JuluEYfd/DMYZpzj/7 TEiVN/Lhyu86kKNqs72MPjwvxKjtFz/lFeP/dg/fHq+p2sStS7mP8cXjS97RHT3ijyEX JpUrvrtnhy4fB1riwc6/3q+JrRFwIotAdeIXMO+F1yPlF9lTZ58vzwcmUJUZqw8CLhpg MEirCi8Sy8CDh3/LVTuVUj3pz1S80WHOIp5bFV5SKqZiF+t8aSFMz7pvCDeGzmxUHvT/ z8og== X-Gm-Message-State: AD7BkJLtfKfqVobgV7LufhumYqYE6uSYjS34ECcR9xuQqHa5tasADIqZ7ZPm3ZaZ/eEmoQ3Jq4JgKi37FmrvCw== MIME-Version: 1.0 X-Received: by 10.25.149.68 with SMTP id x65mr13307037lfd.138.1458656209848; Tue, 22 Mar 2016 07:16:49 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Tue, 22 Mar 2016 07:16:49 -0700 (PDT) In-Reply-To: References: <20160322.084841.1381513591842449169.mbj@tail-f.com> Date: Tue, 22 Mar 2016 07:16:49 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a114038823ce37f052ea3dd05 Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF examples X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 14:17:14 -0000 --001a114038823ce37f052ea3dd05 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 22, 2016 at 6:10 AM, Ladislav Lhotka wrote: > Hi, > > I checked the book RESTful Web Services by Richardson & Ruby, and they > illustrate a recommended design of resources with the following example: > > | Operation | HTTP action | > |----------------+------------------| > | List the users | GET /users | > | Create a user | POST /users | > | View a user | GET /users/52 | > | Modify a user | PUT /users/52 | > | Delete a user | DELETE /users/52 | > > > I think RESTCONF should follow the same pattern because this is what > developers are used to. The logic of some examples in the RESTCONF spec > - namely what's a resource and what's its value - isn't very clear to > me. > This is what we have except lists are encoded in 1 segment instead of list key values in their own segment. Please provide OLD and NEW text fragments that you think need to be changed > > Lada > Andy > > Ladislav Lhotka writes: > > >> On 22 Mar 2016, at 08:48, Martin Bjorklund wrote: > >> > >> Ladislav Lhotka wrote: > >>> Hi, > >>> > >>> I am confused by this example in draft-ietf-netconf-restconf-10, > >>> appendix D.3.4: > >>> > >>> POST /restconf/data/example-jukebox:jukebox/ > >>> playlist=Foo-One?insert=first HTTP/1.1 > >>> Host: example.com > >>> Content-Type: application/yang.data+json > >>> > >>> { > >>> "example-jukebox:song" : { > >>> "index" : 1, > >>> "id" : "/example-jukebox:jukebox/library/ > >>> artist=Foo%20Fighters/album=Wasting%20Light/song=Rope" > >>> } > >>> } > >>> > >>> The text says "..., a new first entry in the "Foo-One" playlist is > being > >>> created." > >>> > >>> It seems to me that in fact a new first entry of the "song" list inside > >>> the "Foo-One" playlist is supposed to be created. > >> > >> You are right: > >> > >> OLD: > >> > >> In this example, a new first entry in the "Foo-One" playlist > >> is being created. > >> > >> NEW: > >> > >> In this example, a new first song entry in the "Foo-One" playlist > >> is being created. > >> > >> > >>> And then the request > >>> should IMO be > >>> > >>> POST /restconf/data/example-jukebox:jukebox/ > >>> playlist=Foo-One/song?insert=first HTTP/1.1 > >>> Host: example.com > >>> Content-Type: application/yang.data+json > >>> > >>> { > >>> "index" : 1, > >>> "id" : "/example-jukebox:jukebox/library/ > >>> artist=Foo%20Fighters/album=Wasting%20Light/song=Rope" > >>> } > >>> > >>> That is, the client is posting to the "song" resource > >> > >> No, there is no "song" resource, since all data resources are YANG > >> data nodes. > > > > Are you saying that the user-ordered "song" list is *not* a YANG data > node? > > > > Also, the body > > > > { > > "example-jukebox:song" : { > > "index" : 1, > > "id" : "/example-jukebox:jukebox/library/ > > artist=Foo%20Fighters/album=Wasting%20Light/song=Rope" > > } > > } > > > > is counter-intuitive, to say the least, because it looks like "song" is > a container, which it isn't. > > > > Lada > > > >> > >> > >> /martin > >> > >> > >>> , namely creating > >>> its new first entry whose content is specified in the body. > >>> > >>> Am I missing something? > >>> > >>> Thanks, Lada > >>> > >>> -- > >>> Ladislav Lhotka, CZ.NIC Labs > >>> PGP Key ID: E74E8C0C > >>> > >>> _______________________________________________ > >>> Netconf mailing list > >>> Netconf@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netconf > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a114038823ce37f052ea3dd05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 22, 2016 at 6:10 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:
Hi,

I checked the book RESTful Web Services by Richardson & Ruby, and they<= br> illustrate a recommended design of resources with the following example:
| Operation=C2=A0 =C2=A0 =C2=A0 | HTTP action=C2=A0 =C2=A0 =C2=A0 |
|----------------+------------------|
| List the users | GET /users=C2=A0 =C2=A0 =C2=A0 =C2=A0|
| Create a user=C2=A0 | POST /users=C2=A0 =C2=A0 =C2=A0 |
| View a user=C2=A0 =C2=A0 | GET /users/52=C2=A0 =C2=A0 |
| Modify a user=C2=A0 | PUT /users/52=C2=A0 =C2=A0 |
| Delete a user=C2=A0 | DELETE /users/52 |



=C2=A0
I think RESTCONF should follow the same pattern because this is what
developers are used to. The logic of some examples in the RESTCONF spec
- namely what's a resource and what's its value - isn't very cl= ear to
me.


This is what we have= except lists are encoded in 1 segment instead
of list key values= in their own segment.

Please provide OLD and NEW = text fragments that you think need to be changed

<= br>
=C2=A0

Lada


Andy
=C2= =A0

Ladislav Lhotka <lhotka@nic.cz> = writes:

>> On 22 Mar 2016, at 08:48, Martin Bjorklund <mbj@tail-f.com> wrote:
>>
>> Ladislav Lhotka <lhotka@nic.cz= > wrote:
>>> Hi,
>>>
>>> I am confused by this example in draft-ietf-netconf-restconf-1= 0,
>>> appendix D.3.4:
>>>
>>>=C2=A0 =C2=A0 =C2=A0 POST /restconf/data/example-jukebox:jukebo= x/
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 playlist=3DFoo-One?insert=3D= first HTTP/1.1
>>>=C2=A0 =C2=A0 =C2=A0 Host: example.com
>>>=C2=A0 =C2=A0 =C2=A0 Content-Type: application/yang.data+json >>>
>>>=C2=A0 =C2=A0 =C2=A0 {
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 "example-jukebox:song" : = {
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"index" : 1,=
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"id" : "= ;/example-jukebox:jukebox/library/
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0artist= =3DFoo%20Fighters/album=3DWasting%20Light/song=3DRope"
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>>>=C2=A0 =C2=A0 =C2=A0 }
>>>
>>> The text says "..., a new first entry in the "Foo-On= e" playlist is being
>>> created."
>>>
>>> It seems to me that in fact a new first entry of the "son= g" list inside
>>> the "Foo-One" playlist is supposed to be created. >>
>> You are right:
>>
>> OLD:
>>
>>=C2=A0 In this example, a new first entry in the "Foo-One"= ; playlist
>>=C2=A0 is being created.
>>
>> NEW:
>>
>>=C2=A0 In this example, a new first song entry in the "Foo-One= " playlist
>>=C2=A0 is being created.
>>
>>
>>> And then the request
>>> should IMO be
>>>
>>>=C2=A0 =C2=A0 =C2=A0 POST /restconf/data/example-jukebox:jukebo= x/
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 playlist=3DFoo-One/song?inse= rt=3Dfirst HTTP/1.1
>>>=C2=A0 =C2=A0 =C2=A0 Host: example.com
>>>=C2=A0 =C2=A0 =C2=A0 Content-Type: application/yang.data+json >>>
>>>=C2=A0 =C2=A0 =C2=A0 {
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 "index" : 1,
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 "id" : "/example-juk= ebox:jukebox/library/
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 artist=3DFoo%20Fighters/albu= m=3DWasting%20Light/song=3DRope"
>>>=C2=A0 =C2=A0 =C2=A0 }
>>>
>>> That is, the client is posting to the "song" resourc= e
>>
>> No, there is no "song" resource, since all data resource= s are YANG
>> data nodes.
>
> Are you saying that the user-ordered "song" list is *not* a = YANG data node?
>
> Also, the body
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"example-jukebox:song" : {<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "index" : 1,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "id" : "/examp= le-jukebox:jukebox/library/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 artist=3DFoo%20= Fighters/album=3DWasting%20Light/song=3DRope"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>
> is counter-intuitive, to say the least, because it looks like "so= ng" is a container, which it isn't.
>
> Lada
>
>>
>>
>> /martin
>>
>>
>>> , namely creating
>>> its new first entry whose content is specified in the body. >>>
>>> Am I missing something?
>>>
>>> Thanks, Lada
>>>
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/net= conf
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf<= br>
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

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

--001a114038823ce37f052ea3dd05-- From nobody Tue Mar 22 07:26:51 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A1512D8D7 for ; Tue, 22 Mar 2016 07:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nBmZkFHne7q for ; Tue, 22 Mar 2016 07:26:47 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 484DB12D922 for ; Tue, 22 Mar 2016 07:26:46 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id A03A81CC0052; Tue, 22 Mar 2016 15:26:54 +0100 (CET) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <20160322.084841.1381513591842449169.mbj@tail-f.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 22 Mar 2016 15:26:43 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF examples X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 14:26:50 -0000 Andy Bierman writes: > On Tue, Mar 22, 2016 at 6:10 AM, Ladislav Lhotka wrote: > >> Hi, >> >> I checked the book RESTful Web Services by Richardson & Ruby, and they >> illustrate a recommended design of resources with the following example: >> >> | Operation | HTTP action | >> |----------------+------------------| >> | List the users | GET /users | >> | Create a user | POST /users | >> | View a user | GET /users/52 | >> | Modify a user | PUT /users/52 | >> | Delete a user | DELETE /users/52 | >> >> > > > >> I think RESTCONF should follow the same pattern because this is what >> developers are used to. The logic of some examples in the RESTCONF spec >> - namely what's a resource and what's its value - isn't very clear to >> me. >> > > > This is what we have except lists are encoded in 1 segment instead > of list key values in their own segment. > > Please provide OLD and NEW text fragments that you think need to be > changed I did it already, without the OLD and NEW labels, so here it is again: --------------------------------------------------------------------- OLD POST /restconf/data/example-jukebox:jukebox/ playlist=Foo-One?insert=first HTTP/1.1 Host: example.com Content-Type: application/yang.data+json { "example-jukebox:song" : { "index" : 1, "id" : "/example-jukebox:jukebox/library/ artist=Foo%20Fighters/album=Wasting%20Light/song=Rope" } } NEW POST /restconf/data/example-jukebox:jukebox/ playlist=Foo-One/song?insert=first HTTP/1.1 Host: example.com Content-Type: application/yang.data+json { "index" : 1, "id" : "/example-jukebox:jukebox/library/ artist=Foo%20Fighters/album=Wasting%20Light/song=Rope" } --------------------------------------------------------------------- If we agree that this example adds an entry to the "song" list, then IMO "song" needs to appear in the Request-URI. Lada > > > > >> >> Lada >> > > > Andy > > >> >> Ladislav Lhotka writes: >> >> >> On 22 Mar 2016, at 08:48, Martin Bjorklund wrote: >> >> >> >> Ladislav Lhotka wrote: >> >>> Hi, >> >>> >> >>> I am confused by this example in draft-ietf-netconf-restconf-10, >> >>> appendix D.3.4: >> >>> >> >>> POST /restconf/data/example-jukebox:jukebox/ >> >>> playlist=Foo-One?insert=first HTTP/1.1 >> >>> Host: example.com >> >>> Content-Type: application/yang.data+json >> >>> >> >>> { >> >>> "example-jukebox:song" : { >> >>> "index" : 1, >> >>> "id" : "/example-jukebox:jukebox/library/ >> >>> artist=Foo%20Fighters/album=Wasting%20Light/song=Rope" >> >>> } >> >>> } >> >>> >> >>> The text says "..., a new first entry in the "Foo-One" playlist is >> being >> >>> created." >> >>> >> >>> It seems to me that in fact a new first entry of the "song" list inside >> >>> the "Foo-One" playlist is supposed to be created. >> >> >> >> You are right: >> >> >> >> OLD: >> >> >> >> In this example, a new first entry in the "Foo-One" playlist >> >> is being created. >> >> >> >> NEW: >> >> >> >> In this example, a new first song entry in the "Foo-One" playlist >> >> is being created. >> >> >> >> >> >>> And then the request >> >>> should IMO be >> >>> >> >>> POST /restconf/data/example-jukebox:jukebox/ >> >>> playlist=Foo-One/song?insert=first HTTP/1.1 >> >>> Host: example.com >> >>> Content-Type: application/yang.data+json >> >>> >> >>> { >> >>> "index" : 1, >> >>> "id" : "/example-jukebox:jukebox/library/ >> >>> artist=Foo%20Fighters/album=Wasting%20Light/song=Rope" >> >>> } >> >>> >> >>> That is, the client is posting to the "song" resource >> >> >> >> No, there is no "song" resource, since all data resources are YANG >> >> data nodes. >> > >> > Are you saying that the user-ordered "song" list is *not* a YANG data >> node? >> > >> > Also, the body >> > >> > { >> > "example-jukebox:song" : { >> > "index" : 1, >> > "id" : "/example-jukebox:jukebox/library/ >> > artist=Foo%20Fighters/album=Wasting%20Light/song=Rope" >> > } >> > } >> > >> > is counter-intuitive, to say the least, because it looks like "song" is >> a container, which it isn't. >> > >> > Lada >> > >> >> >> >> >> >> /martin >> >> >> >> >> >>> , namely creating >> >>> its new first entry whose content is specified in the body. >> >>> >> >>> Am I missing something? >> >>> >> >>> Thanks, Lada >> >>> >> >>> -- >> >>> Ladislav Lhotka, CZ.NIC Labs >> >>> PGP Key ID: E74E8C0C >> >>> >> >>> _______________________________________________ >> >>> Netconf mailing list >> >>> Netconf@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/netconf >> > >> > -- >> > Ladislav Lhotka, CZ.NIC Labs >> > PGP Key ID: E74E8C0C >> > >> > >> > >> > >> > _______________________________________________ >> > Netconf mailing list >> > Netconf@ietf.org >> > https://www.ietf.org/mailman/listinfo/netconf >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Mar 22 08:11:33 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C10512D831 for ; Tue, 22 Mar 2016 08:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CS3kn90uSFad for ; Tue, 22 Mar 2016 08:11:29 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::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 53D3412D5E7 for ; Tue, 22 Mar 2016 08:11:28 -0700 (PDT) Received: by mail-lb0-x236.google.com with SMTP id k12so166121227lbb.1 for ; Tue, 22 Mar 2016 08:11:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=lzOjVEPrzbWJxUHsyIA5ELehX9FSPWSYot36BqtzAYU=; b=mZJeLbcsEnqLEXY3zue57xIAlDTSFcvGaPZdLc+D2GKKH/muweLRcE/QjXuVBhTy7b 3LQ3eYIxNG0GO/+R4cJgcHOy1kTG8NHLuJGCuQhHZRNBG8sbmeSxkkV/3+T+hHgFeZBn LZqRwbWPx8zMZg/s9QYf2jgrrGu41xisq0fQcCQJfbpeZ07l2XINaKZuLKO3mgnVYgoZ /43BOY8XJWKAyaZkZVF2ONGXURISWFzukREjdoMXy76tWlonAG6s+MmUaGSQBw9KXXDl b2fchpBKz33lpSavYSV/mnf84nigKaeoCOO8AzFhJrjbp073vKvKci2iVTiETxVevMGE 1EUQ== 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; bh=lzOjVEPrzbWJxUHsyIA5ELehX9FSPWSYot36BqtzAYU=; b=YAAABL1GlkuQqOHOoPlT7YJ4BayE3rj3RxD2hk6JbIsxSNxAy6q/ve7sDgx+aJh/EP olLcpjTTXCzMp6xZYWhG1h1NMUp/ea5V2gaBnh/vWKdLy0b9Fxl/U3aN/NlHwSrqU9B5 5tYMLkoJeokT81zmB2NXYnZyopbj6iuSXnP2AUawdmApUSBtXH03CJ4N3idPLJa4HGjx Xhtfwmkg5koxXkKJfjLq/4Zx1ugPRGDQHUAQW0dGolxFYx5e+WsQ/jViLsMRdUHYqu9X 48sOaySxAYWIUd8chh8mXKuX9MhyDhuw1naumyNfjIyitf8UMqZFcQSg+ofF9NY4HFgU reTw== X-Gm-Message-State: AD7BkJKRmaE10c42MuQDVZNMBQ3D/Zkq0bz4rHqc/EV7mtu8XjcmIrb+zVTec0ku4DYc/V6VHTEOMvQlC2US5A== MIME-Version: 1.0 X-Received: by 10.112.171.163 with SMTP id av3mr13318913lbc.145.1458659486370; Tue, 22 Mar 2016 08:11:26 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Tue, 22 Mar 2016 08:11:26 -0700 (PDT) In-Reply-To: References: <20160322.084841.1381513591842449169.mbj@tail-f.com> Date: Tue, 22 Mar 2016 08:11:26 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c36b3688e2eb052ea4a025 Archived-At: Cc: Netconf Subject: Re: [Netconf] RESTCONF examples X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 15:11:31 -0000 --001a11c36b3688e2eb052ea4a025 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 22, 2016 at 7:26 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > On Tue, Mar 22, 2016 at 6:10 AM, Ladislav Lhotka wrote: > > > >> Hi, > >> > >> I checked the book RESTful Web Services by Richardson & Ruby, and they > >> illustrate a recommended design of resources with the following example: > >> > >> | Operation | HTTP action | > >> |----------------+------------------| > >> | List the users | GET /users | > >> | Create a user | POST /users | > >> | View a user | GET /users/52 | > >> | Modify a user | PUT /users/52 | > >> | Delete a user | DELETE /users/52 | > >> > >> > > > > > > > >> I think RESTCONF should follow the same pattern because this is what > >> developers are used to. The logic of some examples in the RESTCONF spec > >> - namely what's a resource and what's its value - isn't very clear to > >> me. > >> > > > > > > This is what we have except lists are encoded in 1 segment instead > > of list key values in their own segment. > > > > Please provide OLD and NEW text fragments that you think need to be > > changed > > I did it already, without the OLD and NEW labels, so here it is again: > > --------------------------------------------------------------------- > OLD > > POST /restconf/data/example-jukebox:jukebox/ > playlist=Foo-One?insert=first HTTP/1.1 > Host: example.com > Content-Type: application/yang.data+json > > { > "example-jukebox:song" : { > "index" : 1, > "id" : "/example-jukebox:jukebox/library/ > artist=Foo%20Fighters/album=Wasting%20Light/song=Rope" > } > } > > NEW > > POST /restconf/data/example-jukebox:jukebox/ > playlist=Foo-One/song?insert=first HTTP/1.1 > Host: example.com > Content-Type: application/yang.data+json > > { > "index" : 1, > "id" : "/example-jukebox:jukebox/library/ > artist=Foo%20Fighters/album=Wasting%20Light/song=Rope" > } > --------------------------------------------------------------------- > > If we agree that this example adds an entry to the "song" list, then IMO > "song" needs to appear in the Request-URI. > > This is not how RESTCONF has been defined from the start. The parent of the new song is used in POST URI because the song does not exist yet. The parent album MUST exist already. If PUT is used to create the song resource, then the URI points to the song resource instance. Lada > Andy > > > > > > > > > > >> > >> Lada > >> > > > > > > Andy > > > > > >> > >> Ladislav Lhotka writes: > >> > >> >> On 22 Mar 2016, at 08:48, Martin Bjorklund wrote: > >> >> > >> >> Ladislav Lhotka wrote: > >> >>> Hi, > >> >>> > >> >>> I am confused by this example in draft-ietf-netconf-restconf-10, > >> >>> appendix D.3.4: > >> >>> > >> >>> POST /restconf/data/example-jukebox:jukebox/ > >> >>> playlist=Foo-One?insert=first HTTP/1.1 > >> >>> Host: example.com > >> >>> Content-Type: application/yang.data+json > >> >>> > >> >>> { > >> >>> "example-jukebox:song" : { > >> >>> "index" : 1, > >> >>> "id" : "/example-jukebox:jukebox/library/ > >> >>> artist=Foo%20Fighters/album=Wasting%20Light/song=Rope" > >> >>> } > >> >>> } > >> >>> > >> >>> The text says "..., a new first entry in the "Foo-One" playlist is > >> being > >> >>> created." > >> >>> > >> >>> It seems to me that in fact a new first entry of the "song" list > inside > >> >>> the "Foo-One" playlist is supposed to be created. > >> >> > >> >> You are right: > >> >> > >> >> OLD: > >> >> > >> >> In this example, a new first entry in the "Foo-One" playlist > >> >> is being created. > >> >> > >> >> NEW: > >> >> > >> >> In this example, a new first song entry in the "Foo-One" playlist > >> >> is being created. > >> >> > >> >> > >> >>> And then the request > >> >>> should IMO be > >> >>> > >> >>> POST /restconf/data/example-jukebox:jukebox/ > >> >>> playlist=Foo-One/song?insert=first HTTP/1.1 > >> >>> Host: example.com > >> >>> Content-Type: application/yang.data+json > >> >>> > >> >>> { > >> >>> "index" : 1, > >> >>> "id" : "/example-jukebox:jukebox/library/ > >> >>> artist=Foo%20Fighters/album=Wasting%20Light/song=Rope" > >> >>> } > >> >>> > >> >>> That is, the client is posting to the "song" resource > >> >> > >> >> No, there is no "song" resource, since all data resources are YANG > >> >> data nodes. > >> > > >> > Are you saying that the user-ordered "song" list is *not* a YANG data > >> node? > >> > > >> > Also, the body > >> > > >> > { > >> > "example-jukebox:song" : { > >> > "index" : 1, > >> > "id" : "/example-jukebox:jukebox/library/ > >> > artist=Foo%20Fighters/album=Wasting%20Light/song=Rope" > >> > } > >> > } > >> > > >> > is counter-intuitive, to say the least, because it looks like "song" > is > >> a container, which it isn't. > >> > > >> > Lada > >> > > >> >> > >> >> > >> >> /martin > >> >> > >> >> > >> >>> , namely creating > >> >>> its new first entry whose content is specified in the body. > >> >>> > >> >>> Am I missing something? > >> >>> > >> >>> Thanks, Lada > >> >>> > >> >>> -- > >> >>> Ladislav Lhotka, CZ.NIC Labs > >> >>> PGP Key ID: E74E8C0C > >> >>> > >> >>> _______________________________________________ > >> >>> Netconf mailing list > >> >>> Netconf@ietf.org > >> >>> https://www.ietf.org/mailman/listinfo/netconf > >> > > >> > -- > >> > Ladislav Lhotka, CZ.NIC Labs > >> > PGP Key ID: E74E8C0C > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > Netconf mailing list > >> > Netconf@ietf.org > >> > https://www.ietf.org/mailman/listinfo/netconf > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> > >> _______________________________________________ > >> Netconf mailing list > >> Netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > >> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > --001a11c36b3688e2eb052ea4a025 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 22, 2016 at 7:26 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:
Andy Bierman <andy@yumaworks.com> writes:

> On Tue, Mar 22, 2016 at 6:10 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
>> Hi,
>>
>> I checked the book RESTful Web Services by Richardson & Ruby, = and they
>> illustrate a recommended design of resources with the following ex= ample:
>>
>> | Operation=C2=A0 =C2=A0 =C2=A0 | HTTP action=C2=A0 =C2=A0 =C2=A0 = |
>> |----------------+------------------|
>> | List the users | GET /users=C2=A0 =C2=A0 =C2=A0 =C2=A0|
>> | Create a user=C2=A0 | POST /users=C2=A0 =C2=A0 =C2=A0 |
>> | View a user=C2=A0 =C2=A0 | GET /users/52=C2=A0 =C2=A0 |
>> | Modify a user=C2=A0 | PUT /users/52=C2=A0 =C2=A0 |
>> | Delete a user=C2=A0 | DELETE /users/52 |
>>
>>
>
>
>
>> I think RESTCONF should follow the same pattern because this is wh= at
>> developers are used to. The logic of some examples in the RESTCONF= spec
>> - namely what's a resource and what's its value - isn'= t very clear to
>> me.
>>
>
>
> This is what we have except lists are encoded in 1 segment instead
> of list key values in their own segment.
>
> Please provide OLD and NEW text fragments that you think need to be > changed

I did it already, without the OLD and NEW labels, so here it is again:

---------------------------------------------------------------------
OLD

=C2=A0 =C2=A0 =C2=A0 POST /restconf/data/example-jukebox:jukebox/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 playlist=3DFoo-One?insert=3Dfirst HTTP/1= .1
=C2=A0 =C2=A0 =C2=A0 Host: example.com
=C2=A0 =C2=A0 =C2=A0 Content-Type: application/yang.data+json

=C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "example-jukebox:song" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"index" : 1,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"id" : "/example-ju= kebox:jukebox/library/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0artist=3DFoo%20Fight= ers/album=3DWasting%20Light/song=3DRope"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 }

NEW

=C2=A0 =C2=A0 =C2=A0 POST /restconf/data/example-jukebox:jukebox/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 playlist=3DFoo-One/song?insert=3Dfirst H= TTP/1.1
=C2=A0 =C2=A0 =C2=A0 Host: example.com
=C2=A0 =C2=A0 =C2=A0 Content-Type: application/yang.data+json

=C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "index" : 1,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "id" : "/example-jukebox:jukebox= /library/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 artist=3DFoo%20Fighters/album=3DWasting%= 20Light/song=3DRope"
=C2=A0 =C2=A0 =C2=A0 }
---------------------------------------------------------------------

If we agree that this example adds an entry to the "song" list, t= hen IMO
"song" needs to appear in the Request-URI.



This is not how RESTCON= F has been defined from the start.
The parent of the new song is = used in POST URI because
the song does not exist yet. =C2=A0 The = parent album MUST exist already.

If PUT is used to= create the song resource, then the URI points to the song resource
instance.





Lada


Andy
=C2= =A0

>
>
>
>
>>
>> Lada
>>
>
>
> Andy
>
>
>>
>> Ladislav Lhotka <lhotka@nic.cz= > writes:
>>
>> >> On 22 Mar 2016, at 08:48, Martin Bjorklund <mbj@tail-f.com> wrote:
>> >>
>> >> Ladislav Lhotka <lhot= ka@nic.cz> wrote:
>> >>> Hi,
>> >>>
>> >>> I am confused by this example in draft-ietf-netconf-r= estconf-10,
>> >>> appendix D.3.4:
>> >>>
>> >>>=C2=A0 =C2=A0 =C2=A0 POST /restconf/data/example-jukeb= ox:jukebox/
>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 playlist=3DFoo-One?= insert=3Dfirst HTTP/1.1
>> >>>=C2=A0 =C2=A0 =C2=A0 Host: example.com
>> >>>=C2=A0 =C2=A0 =C2=A0 Content-Type: application/yang.da= ta+json
>> >>>
>> >>>=C2=A0 =C2=A0 =C2=A0 {
>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 "example-jukebox:song= " : {
>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"index&q= uot; : 1,
>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"id"= ; : "/example-jukebox:jukebox/library/
>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0artist=3DFoo%20Fighters/album=3DWasting%20Light/song=3DRope"
>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>> >>>=C2=A0 =C2=A0 =C2=A0 }
>> >>>
>> >>> The text says "..., a new first entry in the &qu= ot;Foo-One" playlist is
>> being
>> >>> created."
>> >>>
>> >>> It seems to me that in fact a new first entry of the = "song" list inside
>> >>> the "Foo-One" playlist is supposed to be cr= eated.
>> >>
>> >> You are right:
>> >>
>> >> OLD:
>> >>
>> >>=C2=A0 In this example, a new first entry in the "Foo= -One" playlist
>> >>=C2=A0 is being created.
>> >>
>> >> NEW:
>> >>
>> >>=C2=A0 In this example, a new first song entry in the &quo= t;Foo-One" playlist
>> >>=C2=A0 is being created.
>> >>
>> >>
>> >>> And then the request
>> >>> should IMO be
>> >>>
>> >>>=C2=A0 =C2=A0 =C2=A0 POST /restconf/data/example-jukeb= ox:jukebox/
>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 playlist=3DFoo-One/= song?insert=3Dfirst HTTP/1.1
>> >>>=C2=A0 =C2=A0 =C2=A0 Host: example.com
>> >>>=C2=A0 =C2=A0 =C2=A0 Content-Type: application/yang.da= ta+json
>> >>>
>> >>>=C2=A0 =C2=A0 =C2=A0 {
>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 "index" : 1,
>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 "id" : "/ex= ample-jukebox:jukebox/library/
>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 artist=3DFoo%20Figh= ters/album=3DWasting%20Light/song=3DRope"
>> >>>=C2=A0 =C2=A0 =C2=A0 }
>> >>>
>> >>> That is, the client is posting to the "song"= ; resource
>> >>
>> >> No, there is no "song" resource, since all data= resources are YANG
>> >> data nodes.
>> >
>> > Are you saying that the user-ordered "song" list is= *not* a YANG data
>> node?
>> >
>> > Also, the body
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0{
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"example-jukebox:song&q= uot; : {
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "index" : = 1,
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "id" : &qu= ot;/example-jukebox:jukebox/library/
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 artist= =3DFoo%20Fighters/album=3DWasting%20Light/song=3DRope"
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>> >
>> > is counter-intuitive, to say the least, because it looks like= "song" is
>> a container, which it isn't.
>> >
>> > Lada
>> >
>> >>
>> >>
>> >> /martin
>> >>
>> >>
>> >>> , namely creating
>> >>> its new first entry whose content is specified in the= body.
>> >>>
>> >>> Am I missing something?
>> >>>
>> >>> Thanks, Lada
>> >>>
>> >>> --
>> >>> Ladislav Lhotka, CZ.NIC Labs
>> >>> PGP Key ID: E74E8C0C
>> >>>
>> >>> _______________________________________________
>> >>> Netconf mailing list
>> >>> Netconf@ietf.org<= /a>
>> >>> https://www.ietf.org/mailman/list= info/netconf
>> >
>> > --
>> > Ladislav Lhotka, CZ.NIC Labs
>> > PGP Key ID: E74E8C0C
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Netconf mailing list
>> > Netconf@ietf.org
>> > https://www.ietf.org/mailman/listinfo/net= conf
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf<= /a>
>>

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

--001a11c36b3688e2eb052ea4a025-- From nobody Tue Mar 22 11:10:58 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0111E12D116 for ; Tue, 22 Mar 2016 11:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LThcRTzsQNeG for ; Tue, 22 Mar 2016 11:10:54 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C5ED12D0EC for ; Tue, 22 Mar 2016 11:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27037; q=dns/txt; s=iport; t=1458670253; x=1459879853; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=6dzy6oxrx+Wlo7RnMp1uqk/tYbpO+hZ4kR6VDNQO1Kk=; b=RpclA8mTfWKkUrudU9UdMEq4ddtyFDGWult3JA7rrFZqvLX9UfNeMCDD Rec0Apt6X953n1sT9ktKwIeiwPiQEeeCbPKgz54ZqkZ1JuAeh1kGmWsuF pNgLW4bQ/iM5bGYVXJfXNTts5dZ8xRvnIlXiAtilJeYXbwjcuUVAr2aiX s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQAQDZifFW/xbLJq1egmeBH3q6RwENg?= =?us-ascii?q?XAXAQmFIkoCggMUAQEBAQEBAWQnhEIBAQQBAQFrChELGAkWAQ4JAwIBAgEVMAY?= =?us-ascii?q?BDAYCAQGIIw7BIwEBAQEBAQEBAgEBAQEBAQEBAQEBEQSGHoREhCRFhSkFl1eFc?= =?us-ascii?q?YJyhSGBZYRMgwSEOYEbjwceAQFCg2U8LgGKBQEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,378,1454976000"; d="scan'208,217";a="676225348" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Mar 2016 18:10:50 +0000 Received: from [10.63.23.100] (dhcp-ensft1-uk-vla370-10-63-23-100.cisco.com [10.63.23.100]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u2MIAoGg001455; Tue, 22 Mar 2016 18:10:50 GMT To: Andy Bierman , Netconf References: From: Robert Wilton Message-ID: <56F18AAA.6050507@cisco.com> Date: Tue, 22 Mar 2016 18:10:50 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040305030206030709000200" Archived-At: Subject: Re: [Netconf] RESTCONF-10 draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 18:10:57 -0000 This is a multi-part message in MIME format. --------------040305030206030709000200 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Andy, Kent, Martin, I think that you have addresses some of my recent comments on 09, but not all of them. I've reproduced what I think are my outstanding review comments here which I think also apply to -10; The first 6 questions related to section 4.8: Query Parameters: 1. Are query parameters and paths case sensitive? I would guess so. The draft doesn't make any explicit mention of this, does it need to? 2. Should an unexpected query parameter cause an error or should it just be ignored? For some (but not all) of the query parameters in sections 4.8.1 through 4.8.9 it indicates that an explicit error should be returned if the query parameter is used for an resource type on which it isn't supported, but section 4.8 allows vendor specific query parameters to also be defined. I think that interop might be easier if unknown query parameters are just ignored. 3. Both the depth and fields query parameters (4.8.2 & 4.8.3) indicate that they apply to the API resource (3.3), but I wasn't sure that they served any purpose since my reading of the draft is that the api resource is just the top level and effectively fixed. I.e. it doesn't return any data from the datastore or the operations, and they need to be explicitly queried separately if required. Proposed fix: 4.8.2 & 4.8.3 Old: This parameter is only allowed for GET methods on*API,* datastore, and data resources. A "400 Bad Request" status-line is returned if it used for other methods or resource types. 4.8.2 & 4.8.3 New: This parameter is only allowed for GET methods on datastore, and data resources. A "400 Bad Request" status-line is returned if it used for other methods or resource types. 4. Minor nit. It might be helpful if the options were listed in the same order as they are listed in the table in section 4.8. E.g. this would mean that the section on "filter" would need to move up above the section on "insert". 5. Section 4.8.2: The "depth" Query Parameter The last but one paragraph reads: "By default, the server will include all sub-resources within a retrieved resource,*which have the same resource type as the requested resource. Only one level of sub-resources with a different media type than the target resource will be returned.*" I'm not convinced that this paragraph is correct, e.g. for a GET request on /restconf/data. By default I would expect it to return all levels of child nodes (which have a different resource type) rather than just the first layer of children. If the depth parameter is changed to not apply to the API resource, then could this paragraph just be changed to: New: "By default, the server will include all sub-resources within a retrieved resource." 6. Section 8: "error-info". Should the type be anydata rather than the deprecated anyxml? Old: *anyxml *error-info { description "This*anyxml *value MUST represent a container with zero or more data nodes representing additional error information."; } New: anydata error-info { description "This anydata value MUST represent a container with zero or more data nodes representing additional error information."; } These remaining questions are those that I raised previously (eliding those which have been addressed in -10): 7. Section 3.4.1 Edit Collision Detection: In -10, this has been updated to make it clear that it only applies to configuration resources which is now internally consistent. However, it feels like the timestamp is potentially be a bit inaccurate for a REST like interface. It is probably too late to raise this now, but I was wondering whether the server shouldn't also track operational resources using parallel timestamps/etags? Whether the config or operational timestamp/etag is returned would depend on which node had been queried and the "content" GET query parameter: - If the content query was for "config" only then the config resources timestamp/etag would be returned. - if the content query was for "nonconfig" then the operational resources timestamp/etag would be returned. - If the content query was for "all" then the latest of the config/operational resource timestamp would be returned and a combined config/operational etag could be returned. In addition, the config and operational timestamps and etags could be returned using separate HTTP headers. 8. Section 3.5 Data Resource, last paragraph: The resource definition version for a data resource is identified by the revision date of the YANG module containing the YANG definition for the data resource. I don't understand the purpose of this last paragraph means, or what its relevance is. I suggest that either "resource definition version" is defined in 1.1.4 Terms, or this paragraph is deleted. 9. Section 4.1. OPTIONS: The OPTIONS method is sent by the client to discover which methods are supported by the server for a specific resource (e.g., GET, POST, DELETE, etc.). The server SHOULD implement this method, however the same information could be extracted from the YANG modules and the RESTCONF protocol specification. I suggest adding the sentence: The server SHOULD NOT include any body text for the OPTIONS method. 10. Section 7.1 Error Response message: When an error occurs for a request message on a*data* resource or an *operation *resource, and a "4xx" class of status codes will be returned (except for status code "403 Forbidden"), then the server SHOULD send a response message-body containing the information described by the "errors" container definition within the YANG module Section 8 . The Content-Type of this response message*MUST be application/yang.errors* (see example below). The client*MAY *specify the desired encoding for error messages by specifying the appropriate media-type in the Accept header.*If no error media is specified, then the media type of the request message SHOULD be used, or the server MAY choose any supported message encoding format.* If there is no request message the server MUST select "application/yang.errors+xml" or "application/ yang.errors+json", depending on server preference. All of the examples in this document, except for the one below, assume that XML encoding will be returned if there is an error. i) The beginning of the error paragraph makes the description conditional on the request message being on a data resource. Should this cover other resource types as well, or otherwise what is the error handling strategy for other resource types? ii) Should the last sentence of the first paragraph be "The Content-Type of this response message MUST be a subtype of application/yang.errors (see example below). "? iii) Would it be wise to indicate that the client SHOULD specify desired encoding for error messages? iv) The second paragraph states "If no error media is specified, then the media type of the request message is used. " but this directly conflicts with "The Content- Type of this response message MUST be application/yang.errors (see example below). " v) "If there is no request message the server ..." - I would think that there must always be a request message. In summary, what about this text instead: When an error occurs for a request message on an*api, data,****datastore, or operation* resource, and a "4xx" class of status codes will be returned (except for status code "403 Forbidden"), then the server SHOULD send a response message-body containing the information described by the "errors" container definition within the YANG module Section 8 . The Content-Type of this response message*MUST**be a subtype of**application/yang.errors* (see example below). The client*SHOULD *specify the desired encoding for error messages by specifying the appropriate media-type in the Accept header.*If no error media is specified, then the server SHOULD choose the error media****type with the clients preferred encoding, or otherwise the server MAY****choose any supported message encoding format. *If there is no request message the server MUST select "application/yang.errors+xml" or "application/ yang.errors+json", depending on server preference. All of the examples in this document, except for the one below, assume that XML encoding will be returned if there is an error. Thanks, Rob On 20/03/2016 19:02, Andy Bierman wrote: > Hi, > > Please review the latest version of the RESTCONF protocol: > https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ > > There have been many updates based on the extensive list > of review comments: > > https://tools.ietf.org/html/draft-ietf-netconf-restconf-10#appendix-A.1 > > This draft addresses all open issues found on github: > https://github.com/netconf-wg/restconf/issues > > Not all requested edits were made. Please review the > github issue tracker for details about the editing process. > > > thanks, > Andy > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------040305030206030709000200 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Andy, Kent, Martin,

I think that you have addresses some of my recent comments on 09, but not all of them.

I've reproduced what I think are my outstanding review comments here which I think also apply to -10;


The first 6 questions related to section 4.8: Query Parameters:
1. Are query parameters and paths case sensitive?  I would guess so.  The draft doesn't make any explicit mention of this, does it need to?


2. Should an unexpected query parameter cause an error or should it just be ignored?  For some (but not all) of the query parameters in sections 4.8.1 through 4.8.9 it indicates that an explicit error should be returned if the query parameter is used for an resource type on which it isn't supported, but section 4.8 allows vendor specific query parameters to also be defined.  I think that interop might be easier if unknown query parameters are just ignored.


3. Both the depth and fields query parameters (4.8.2 & 4.8.3) indicate that they apply to the API resource (3.3), but I wasn't sure that they served any purpose since my reading of the draft is that the api resource is just the top level and effectively fixed.  I.e. it doesn't return any data from the datastore or the operations, and they need to be explicitly queried separately if required.  Proposed fix:

4.8.2 & 4.8.3 Old:
   This parameter is only allowed for GET methods on API, datastore, and
   data resources.  A "400 Bad Request" status-line is returned if it
   used for other methods or resource types.

4.8.2 & 4.8.3 New:
   This parameter is only allowed for GET methods on datastore, and
   data resources.  A "400 Bad Request" status-line is returned if it
   used for other methods or resource types.



4. Minor nit.  It might be helpful if the options were listed in the same order as they are listed in the table in section 4.8.  E.g. this would mean that the section on "filter" would need to move up above the section on "insert".


5. Section 4.8.2: The "depth" Query Parameter
The last but one paragraph reads:
   "By default, the server will include all sub-resources within a
   retrieved resource, which have the same resource type as the
   requested resource.  Only one level of sub-resources with a different
   media type than the target resource will be returned."

I'm not convinced that this paragraph is correct, e.g. for a GET request on /restconf/data.  By default I would expect it to return all levels of child nodes (which have a different resource type) rather than just the first layer of children.

If the depth parameter is changed to not apply to the API resource, then could this paragraph just be changed to:

New:
   "By default, the server will include all sub-resources within a
   retrieved resource."



6. Section 8: "error-info". Should the type be anydata rather than the deprecated anyxml?

Old:
           anyxml error-info {
              description
                "This anyxml value MUST represent a container with
                zero or more data nodes representing additional
                error information.";
           }
New:
           anydata error-info {
              description
                "This anydata value MUST represent a container with
                zero or more data nodes representing additional
                error information.";
           }




These remaining questions are those that I raised previously (eliding those which have been addressed in -10):


7. Section 3.4.1 Edit Collision Detection:
In -10, this has been updated to make it clear that it only applies to configuration resources which is now internally consistent.

However, it feels like the timestamp is potentially be a bit inaccurate for a REST like interface.

It is probably too late to raise this now, but I was wondering whether the server shouldn't also track operational resources using parallel timestamps/etags?  Whether the config or operational timestamp/etag is returned would depend on which node had been queried and the "content" GET query parameter:
 - If the content query was for "config" only then the config resources timestamp/etag would be returned.
 - if the content query was for "nonconfig" then the operational resources timestamp/etag would be returned.
 - If the content query was for "all" then the latest of the config/operational resource timestamp would be returned and a combined config/operational etag could be returned.  In addition, the config and operational timestamps and etags could be returned using separate HTTP headers.



8. Section 3.5 Data Resource, last paragraph:
   The resource definition version for a data resource is identified by
   the revision date of the YANG module containing the YANG definition
   for the data resource.

I don't understand the purpose of this last paragraph means, or what its relevance is.  I suggest that either "resource definition version" is defined in 1.1.4 Terms, or this paragraph is deleted.

    

    

    9. Section 4.1. OPTIONS:

    
   The OPTIONS method is sent by the client to discover which methods
   are supported by the server for a specific resource (e.g., GET, POST,
   DELETE, etc.).

   The server SHOULD implement this method, however the same information
   could be extracted from the YANG modules and the RESTCONF protocol
   specification.

    

    I suggest adding the sentence:

    
   The server SHOULD NOT include any body text for the OPTIONS method.


    

    

    10. Section 7.1 Error Response message:

    
   When an error occurs for a request message on a data resource or an
   operation resource, and a "4xx" class of status codes will be
   returned (except for status code "403 Forbidden"), then the server
   SHOULD send a response message-body containing the information
   described by the "errors" container definition within the YANG module
   Section 8.  The Content-Type of this response message MUST be
   application/yang.errors (see example below).

   The client MAY specify the desired encoding for error messages by
   specifying the appropriate media-type in the Accept header.  If no
   error media is specified, then the media type of the request message
   SHOULD be used, or the server MAY choose any supported message
   encoding format.  If there is no request message the server MUST
   select "application/yang.errors+xml" or "application/
   yang.errors+json", depending on server preference.  All of the
   examples in this document, except for the one below, assume that XML
   encoding will be returned if there is an error.

    

    i) The beginning of the error paragraph makes the description
    conditional on the request message being on a data resource.  Should
    this cover other resource types as well, or otherwise what is the
    error handling strategy for other resource types?

    ii) Should the last sentence of the first paragraph be "The
    Content-Type of this response message MUST be a subtype of
    application/yang.errors (see example below). "?

    iii) Would it be wise to indicate that the client SHOULD specify
    desired encoding for error messages?

    iv) The second paragraph states "If no error media is specified,
    then the media type of the request message is used. " but this
    directly conflicts with "The Content- Type of this response message
    MUST be application/yang.errors (see example below). "

    v) "If there is no request message the server ..." - I would think
    that there must always be a request message.

    

    In summary, what about this text instead:

    
   When an error occurs for a request message on an api, data,
   datastore, or operation resource, and a "4xx" class of status codes will be
   returned (except for status code "403 Forbidden"), then the server
   SHOULD send a response message-body containing the information
   described by the "errors" container definition within the YANG module
   Section 8.  The Content-Type of this response message MUST be a subtype of
   application/yang.errors (see example below).

   The client SHOULD specify the desired encoding for error messages by
   specifying the appropriate media-type in the Accept header.  If no
   error media is specified, then the server SHOULD choose the error media
   type with the clients preferred encoding, or otherwise the server MAY
   choose any supported message encoding format. If there is no request message
   the server MUST select "application/yang.errors+xml" or "application/
   yang.errors+json", depending on server preference.  All of the
   examples in this document, except for the one below, assume that XML
   encoding will be returned if there is an error.

    

    Thanks,

    Rob

    

    

    
On 20/03/2016 19:02, Andy Bierman
      wrote:

    

    

      
      
Hi,
        


        

        
Please review the latest version of the RESTCONF protocol:

        
        


        

        
There have been many updates based on the extensive list

        
of review comments:

        


        

        
        


        

        
This draft addresses all open issues found on github:

        
        


        

        
Not all requested edits were made. Please review the

        
github issue tracker for details about the editing process.

        


        

        


        

        
thanks,

        
Andy

        


        

      

      

      

      

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


    

    

  


--------------040305030206030709000200--


From nobody Tue Mar 22 13:54:19 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81DEC12D8EF for ; Tue, 22 Mar 2016 13:54:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level: 
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdYPQk2a4Dnc for ; Tue, 22 Mar 2016 13:54:16 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC34C12D656 for ; Tue, 22 Mar 2016 13:54:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2738; q=dns/txt; s=iport; t=1458680055; x=1459889655; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=81r6gTVJmNW1eifTHwCFoi3BcbZR42iYVLw6ZmH+qCA=; b=NNo4R3ZbnZGnC8RcYcNSrSNjntooiYiMNZhoqaDAbJ1X1CH32BEnVyRo V93nK8Rk7QosdZOhAyFkP7e0+zNV7dUchcmn7mopcqqxbKxMV0OTkfbeE YuFL/mhkrVDRMZW86h18Bti8yMFTVPKkc5gCKrtERjYDrkoUwgLD65lnZ U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AjAgCHsPFW/4ENJK1egzNTega6QwENg?= =?us-ascii?q?XAXCoUiSgKBTzgUAQEBAQEBAWQnhEEBAQEEAQEBNzQXBgEZBAEBDhEJLgsUCQk?= =?us-ascii?q?BBBMIiB8OoBWgTAEBAQEBAQQBAQEBAQEBAQEBFopihCSFbgWXVwGFcIgMgWxNg?= =?us-ascii?q?3+IVgKPBgEeAQFCg2VqiQh+AQEB?=
X-IronPort-AV: E=Sophos;i="5.24,379,1454976000"; d="scan'208";a="85587741"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Mar 2016 20:54:14 +0000
Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u2MKsE3O019386 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 22 Mar 2016 20:54:14 GMT
Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 22 Mar 2016 16:54:14 -0400
Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Tue, 22 Mar 2016 16:54:13 -0400
From: "Alexander Clemm (alex)" 
To: Netconf 
Thread-Topic: New revision of YANG-Push
Thread-Index: AdGEfNW7DkQOo6sHT9u+Xw2YlDgqYg==
Date: Tue, 22 Mar 2016 20:54:13 +0000
Message-ID: <3158d52b000745e2b10fb77184d4497f@XCH-RTP-001.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.154.163.59]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [Netconf] FYI: New revision of YANG-Push
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Mar 2016 20:54:17 -0000

Hi,

we have posted a new revision of the YANG-Push draft yesterday. =20

We have made only a set of minor updates compared to the prior revision:
- We have renamed the "create-subscription" to "establish-subscription".  T=
his facilitates distinguishing RFC 5277's "create-subscription" RPC with th=
e establishment of a subscription to YANG updates.  It will also facilitate=
 alignment with the RFC 5277bis draft that was posted separately.=20
- We have added a depiction of the publisher's subscription state model. =20
- We introduced an additional grouping for subscription QoS with parameters=
 that allow to control certain QoS aspects of push updates, e.g. establish =
subscription priorities and, for configured subscriptions, control the DSCP=
 field. =20

Kind regards
--- Alex (on behalf of the coauthors)

-----Original Message-----
From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of internet-draft=
s@ietf.org
Sent: Monday, March 21, 2016 4:26 PM
To: i-d-announce@ietf.org
Cc: netconf@ietf.org
Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-push-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
This draft is a work item of the Network Configuration of the IETF.

        Title           : Subscribing to YANG datastore push updates
        Authors         : Alexander Clemm
                          Alberto Gonzalez Prieto
                          Eric Voit
                          Ambika Prasad Tripathy
                          Einar Nilsen-Nygaard
	Filename        : draft-ietf-netconf-yang-push-02.txt
	Pages           : 65
	Date            : 2016-03-21

Abstract:
   This document defines a subscription and push mechanism for YANG
   datastores.  This mechanism allows client applications to request
   updates from a YANG datastore, which are then pushed by the server to
   a receiver per a subscription policy, without requiring additional
   client requests.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netconf-yang-push-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-yang-push-02


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

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

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


From nobody Tue Mar 22 14:18:51 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9FE12DA07 for ; Tue, 22 Mar 2016 14:18:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7yU5LU5gv2p for ; Tue, 22 Mar 2016 14:18:49 -0700 (PDT)
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 6041D12DA0D for ; Tue, 22 Mar 2016 14:18:48 -0700 (PDT)
Received: by mail-lf0-x22e.google.com with SMTP id d192so5897397lfg.2 for ; Tue, 22 Mar 2016 14:18:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=E9MgcIlOjWumXokojRjnv5PU9kQfudAdALU0VFctfI4=; b=rxcrXw694qZ7Y+OUSDioNem8fxGMT0IOtO/B2pvCRKl+hLtwbnSZHvhQPEMe0XkCw0 UxHSHmuMeQvgA+za2Esafd/Zyj5KVu3zBZ949rlxtQWuMGVIJ7QbxDtsSJSjevhESQY0 vCIAguZmlICmUEzEfKGD8fNo93zFllI0MUvXojeBMZhN37VzvtJN/+VRYYHaQdjWO65D xYgtp43umFREo/wItgy39YlOuJz5PRfpuiw73vACFUpOaQwKEQKaD0ePvbbAjgjUgXOZ lXhvZBbzmoq6u899uplCTAFicscFa9TVusjgb9S9IQctlImWtVQhnfOkl5yNjMFbaY7F URbA==
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; bh=E9MgcIlOjWumXokojRjnv5PU9kQfudAdALU0VFctfI4=; b=JB8znrifX4Jywst505LD7bHlUBnIy/fMUzupIyLGTPHl9ArWqI9WPDu4y/F/CBWRaT iy0HdvPpMcHM354ve8sSscH624r+raV/XawCZWhCQAH17ct73/cYn0uXS6aEHTL9q8dH bC63ClEAKqne1cllTDP0Kdg6wR8CuVXwECnL/Ke860VhNs5Y/RHO+luXKHdLGNx5l/c2 2Vz2XxtLE/3V+0JvaiC0SchDldUCrjSNzqndF/jkp7VkMDZ/PTMFBQF8CAS/9byEx2rZ g0Cm8K/Vo/SPZyK7SECY+xExdICyp/SBe4awinBhq6wXm3zPnPjO8GbmIIpak9tb5SsL KnIQ==
X-Gm-Message-State: AD7BkJIOjBBP8aZDIhjuq8Kptj0mEJhrgHtQgeRwm/XtWZmF+T73AGvAS6cjmWRP1LZYFii8/Tn1TjsCfibr+A==
MIME-Version: 1.0
X-Received: by 10.25.27.200 with SMTP id b191mr15031025lfb.8.1458681526584; Tue, 22 Mar 2016 14:18:46 -0700 (PDT)
Received: by 10.112.135.97 with HTTP; Tue, 22 Mar 2016 14:18:46 -0700 (PDT)
In-Reply-To: 
References:   
Date: Tue, 22 Mar 2016 14:18:46 -0700
Message-ID: 
From: Andy Bierman 
To: "Alberto Gonzalez Prieto (albertgo)" 
Content-Type: multipart/alternative; boundary=001a11402c483b9bd6052ea9c242
Archived-At: 
Cc: NETCONF 
Subject: Re: [Netconf] Agenda Request
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Mar 2016 21:18:51 -0000

--001a11402c483b9bd6052ea9c242
Content-Type: text/plain; charset=UTF-8

Hi,


I don't know how much agreement there is on requirements or solution.

IMO, this draft should not be called RFC5277bis

 - all mechanisms from RFC 5277 have been removed
 - all RFC 5277 authors have been removed

IMO, the new work should not obsolete RFC 5277, as stated in the draft.
The existing notifications work as intended and there are several
independent
implementations.

This new draft is radically different and much more complex to implement on
the client and server than RFC 5277.



Andy


On Mon, Mar 21, 2016 at 11:49 AM, Alberto Gonzalez Prieto (albertgo) <
albertgo@cisco.com> wrote:

> Hello,
>
> Our proposal for RFC5277-bis has been submitted
> (https://datatracker.ietf.org/doc/draft-gonzalez-netconf-5277bis)
> You can find an high-level summary of the draft below.
> We would like to present it in the NETCONF session at IETF 95.
>
> Length: 10 minutes
> Presenter: Eric Voit
>
>
> Thanks,
>
> Alberto, Alex, Eric, Einar, and Ambika
>
>
>
> This draft targets charter item #6 of the NETCONF WG.
> It enhances RFC 5277, addressing limitations identified during the design
> of draft-ietf-netconf-yang-push-01 and
> draft-voit-netconf-restconf-yang-push-02
>
> Goals of charter item #6, (all of them addressed in the draft):
> - Ability to delete subscriptions without closing the client session.
> - Ability to modify existing subscriptions.
> - Ability to have multiple subscriptions on a client session.
> - Do not affect older clients.
> - Convert data models in RFC 5277 into YANG.
>
> The draft also includes the following features:
> - Subscription negotiation.
> - Static subscriptions. (i.e., configuration-driven susbcription)
> - Subscription suspension and termination by server.
> - Support for multiple encodings (e.g., json).
>
>
>
>
>
> On 3/7/16, 2:52 PM, "Netconf on behalf of Eric Voit (evoit)"
>  wrote:
>
> >Hi Mahesh & Mehmet,
> >
> >Below are the two topics we were hoping present .
> >
> >Topics:
> >(1) Yang Subscriptions
> >  -  draft-ietf-netconf-yang-push
> >       - WG draft revisions
> >       - IETF hackathon demo results: yang-push interworking with
> >OpenDaylight
> >  -  draft-voit-netconf-restconf-yang-push
> >       - New draft this week: shrunk to cover just Restconf & HTTP
> >transports
> >  -  Discussion:  do we have the desired WG division for these drafts?
> >
> >(2) RFC5277bis
> >  - Proposal coming into WG before submission cut-off date
> >
> >Length:
> >(1) Yang Subscriptions - 20 min
> >(2) RFC5277bis - 10 min
> >
> >Presenter:
> >  -  Eric Voit (on behalf of the authors)
> >
> >Thanks,
> >Eric, Alex, Alberto, Ambika, Einar
> >
> >-------------------
> >From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh
> >Jethanandani
> >Sent: Sunday, March 06, 2016 10:22 PM
> >To: NETCONF
> >Subject: [Netconf] Agenda Request
> >
> >It is that time again where we ask if you want to present in the NETCONF
> >session at IETF 95.
> >
> >Please indicate
> >
> >Topic:
> >Length:
> >Presenter:
> >
> >in your request for the slot.
> >
> >All this assumes that you have published/updated a draft on the mailing
> >list and have garnered some discussion around it. If not, there is still
> >time to do that before the meeting.
> >
> >Cheers.
> >
> >Mahesh & Mehmet
> >
> >
> >
> >_______________________________________________
> >Netconf mailing list
> >Netconf@ietf.org
> >https://www.ietf.org/mailman/listinfo/netconf
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

--001a11402c483b9bd6052ea9c242
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,


I don't know how=
 much agreement there is on requirements or solution.

<=
div>IMO, this draft should not be called RFC5277bis

=C2=A0- all mechanisms from RFC 5277 have been removed
=C2=A0- =
all RFC 5277 authors have been removed

IMO, the ne=
w work should not obsolete RFC 5277, as stated in the draft.
The =
existing notifications work as intended and there are several independent
implementations.

This new draft is radica=
lly different and much more complex to implement on
the client an=
d server than RFC 5277.=C2=A0



<=
/div>
Andy


On Mon, Mar 21, 2016 at 11:49 AM, Alberto Gonzalez P=
rieto (albertgo) <albertgo@cisco.com> wrote:
Hello,



Our proposal for RFC5277-bis has been submitted

(https://datatracker.ietf.org/doc/dra=
ft-gonzalez-netconf-5277bis)

You can find an high-level summary of the draft below.

We would like to present it in the NETCONF session at IETF 95.



Length: 10 minutes

Presenter: Eric Voit





Thanks,



Alberto, Alex, Eric, Einar, and Ambika







This draft targets charter item #6 of the NETCONF WG.

It enhances RFC 5277, addressing limitations identified during the design
of draft-ietf-netconf-yang-push-01 and

draft-voit-netconf-restconf-yang-push-02



Goals of charter item #6, (all of them addressed in the draft):

- Ability to delete subscriptions without closing the client session.

- Ability to modify existing subscriptions.

- Ability to have multiple subscriptions on a client session.

- Do not affect older clients.

- Convert data models in RFC 5277 into YANG.



The draft also includes the following features:

- Subscription negotiation.

- Static subscriptions. (i.e., configuration-driven susbcription)

- Subscription suspension and termination by server.

- Support for multiple encodings (e.g., json).











On 3/7/16, 2:52 PM, "Netconf on behalf of Eric Voit (evoit)"

<netconf-bounces@ietf.org on behalf of evoit@cisco.com> w=
rote:



>Hi Mahesh & Mehmet,

>

>Below are the two topics we were hoping present .

>

>Topics:

>(1) Yang Subscriptions

>=C2=A0 -=C2=A0 draft-ietf-netconf-yang-push

>=C2=A0 =C2=A0 =C2=A0 =C2=A0- WG draft revisions

>=C2=A0 =C2=A0 =C2=A0 =C2=A0- IETF hackathon demo results: yang-push int=
erworking with

>OpenDaylight

>=C2=A0 -=C2=A0 draft-voit-netconf-restconf-yang-push

>=C2=A0 =C2=A0 =C2=A0 =C2=A0- New draft this week: shrunk to cover just =
Restconf & HTTP

>transports

>=C2=A0 -=C2=A0 Discussion:=C2=A0 do we have the desired WG division for=
 these drafts?

>

>(2) RFC5277bis

>=C2=A0 - Proposal coming into WG before submission cut-off date

>

>Length:

>(1) Yang Subscriptions - 20 min

>(2) RFC5277bis - 10 min

>

>Presenter:

>=C2=A0 -=C2=A0 Eric Voit (on behalf of the authors)

>

>Thanks,

>Eric, Alex, Alberto, Ambika, Einar

>

>-------------------

>From: Netconf [mailto:netco=
nf-bounces@ietf.org] On Behalf Of Mahesh

>Jethanandani

>Sent: Sunday, March 06, 2016 10:22 PM

>To: NETCONF

>Subject: [Netconf] Agenda Request

>

>It is that time again where we ask if you want to present in the NETCON=
F

>session at IETF 95.

>

>Please indicate

>

>Topic:

>Length:

>Presenter:

>

>in your request for the slot.

>

>All this assumes that you have published/updated a draft on the mailing=


>list and have garnered some discussion around it. If not, there is stil=
l

>time to do that before the meeting.

>

>Cheers.

>

>Mahesh & Mehmet

>

>

>

>_______________________________________________

>Netconf mailing list

>Netconf@ietf.org

>https://www.ietf.org/mailman/listinfo/netconf


_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf





--001a11402c483b9bd6052ea9c242--


From nobody Tue Mar 22 19:13:11 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3665212D5E1 for ; Tue, 22 Mar 2016 19:13:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K14Z950M5OwW for ; Tue, 22 Mar 2016 19:13:08 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABFEF12D5B9 for ; Tue, 22 Mar 2016 19:13:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16476; q=dns/txt; s=iport; t=1458699187; x=1459908787; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NtzFbZSWT+HaJb1WVl5E+6794qI1J1p7rATyBuDCTs8=; b=i+zb5RshQ/NO6FngH0btYQUVMv8DiZ1ma/MlCEvlF2FGf+wB9F6ictVl 5OcijQkEj0YKNkQQq1FD60gp99UUnq77jbCYEWdGiy179TXqiiKzVyfvS QQMjmj0IcLkIr5pCq4QupwBfKV/oXeRvTjlwlNd27cDaDEspTIBnk0zpb U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A+AgB9+vFW/5ldJa1egmdMU3oGrxuGY?= =?us-ascii?q?IRuAQ2BcBcBCYUiSgKBTDgUAQEBAQEBAWQnhEEBAQEEAQEBawsQAgEIEQMBAQE?= =?us-ascii?q?OGgchBgsUCQgCBA4FG4d3AxIOvA4NhHEBAQEBAQEBAQEBAQEBAQEBAQEBAQERB?= =?us-ascii?q?Ipigj6BZjgNhSkFh2CLJIQjMQGFcIYegXWBZoRMiFhqhkiHVAEeAQFCg2VqiEs?= =?us-ascii?q?jGn4BAQE?=
X-IronPort-AV: E=Sophos;i="5.24,380,1454976000";  d="scan'208,217";a="252676456"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Mar 2016 02:13:06 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u2N2D6v7016232 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 23 Mar 2016 02:13:06 GMT
Received: from xch-rtp-003.cisco.com (64.101.220.143) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 22 Mar 2016 22:13:05 -0400
Received: from xch-rtp-003.cisco.com ([64.101.220.143]) by XCH-RTP-003.cisco.com ([64.101.220.143]) with mapi id 15.00.1104.009; Tue, 22 Mar 2016 22:13:05 -0400
From: "Alberto Gonzalez Prieto (albertgo)" 
To: Andy Bierman 
Thread-Topic: [Netconf] Agenda Request
Thread-Index: AQHReCCXnxWOt0Dw+0uIkww9TXgdy59OZWuAgBZC+ICAAatAAIAAYwOA
Date: Wed, 23 Mar 2016 02:13:05 +0000
Message-ID: 
References:    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.1.160122
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.252.9]
Content-Type: multipart/alternative; boundary="_000_D317B4036A7D7albertgociscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: NETCONF 
Subject: Re: [Netconf] Agenda Request
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Mar 2016 02:13:10 -0000

--_000_D317B4036A7D7albertgociscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks Andy,

The draft targets charter item #6. I include it below for convenience.

One of the goals in the item is to not affect older clients I.e., backwards=
 compatibility.
To achieve this, we have kept the mechanisms in 5277. E.g., the create-subs=
cription RPC.
If a mechanism in 5277 is not in the draft it is an unintended omission.

I agree that the complete set of features in the draft is more complex than=
 those in 5277.
Some features are explicitly stated in the charter item (e.g., multiple sub=
scriptions over a session).
Others, like static subscription, are not mandatory in the yang with the ne=
w features.
What is mandatory and what is optional is open to discussion.
A server implementation may only advertise the capabilities corresponding t=
o 5277.

On the point your bring about the authors, I am not familiar with it. Guida=
nce from the chairs would be appreciated.

Thanks,

Alberto



6. Enhance RFC 5277 with the ability to delete subscriptions without
closing the client session, to modify existing subscriptions, and to
have multiple subscriptions on a established client session. These
changes should not affect older clients that do not support these
particular subscription requirements. The RPCs and the data models in
RFC 5277 should be converted to YANG.


From: Andy Bierman >
Date: Tuesday, March 22, 2016 at 10:18 PM
To: Alberto Gonzalez Prieto >
Cc: "Eric Voit (evoit)" >, Mahesh J=
ethanandani >, NETC=
ONF >
Subject: Re: [Netconf] Agenda Request

Hi,


I don't know how much agreement there is on requirements or solution.

IMO, this draft should not be called RFC5277bis

 - all mechanisms from RFC 5277 have been removed
 - all RFC 5277 authors have been removed

IMO, the new work should not obsolete RFC 5277, as stated in the draft.
The existing notifications work as intended and there are several independe=
nt
implementations.

This new draft is radically different and much more complex to implement on
the client and server than RFC 5277.



Andy


On Mon, Mar 21, 2016 at 11:49 AM, Alberto Gonzalez Prieto (albertgo) > wrote:
Hello,

Our proposal for RFC5277-bis has been submitted
(https://datatracker.ietf.org/doc/draft-gonzalez-netconf-5277bis)
You can find an high-level summary of the draft below.
We would like to present it in the NETCONF session at IETF 95.

Length: 10 minutes
Presenter: Eric Voit


Thanks,

Alberto, Alex, Eric, Einar, and Ambika



This draft targets charter item #6 of the NETCONF WG.
It enhances RFC 5277, addressing limitations identified during the design
of draft-ietf-netconf-yang-push-01 and
draft-voit-netconf-restconf-yang-push-02

Goals of charter item #6, (all of them addressed in the draft):
- Ability to delete subscriptions without closing the client session.
- Ability to modify existing subscriptions.
- Ability to have multiple subscriptions on a client session.
- Do not affect older clients.
- Convert data models in RFC 5277 into YANG.

The draft also includes the following features:
- Subscription negotiation.
- Static subscriptions. (i.e., configuration-driven susbcription)
- Subscription suspension and termination by server.
- Support for multiple encodings (e.g., json).





On 3/7/16, 2:52 PM, "Netconf on behalf of Eric Voit (evoit)"
 on behalf of evo=
it@cisco.com> wrote:

>Hi Mahesh & Mehmet,
>
>Below are the two topics we were hoping present .
>
>Topics:
>(1) Yang Subscriptions
>  -  draft-ietf-netconf-yang-push
>       - WG draft revisions
>       - IETF hackathon demo results: yang-push interworking with
>OpenDaylight
>  -  draft-voit-netconf-restconf-yang-push
>       - New draft this week: shrunk to cover just Restconf & HTTP
>transports
>  -  Discussion:  do we have the desired WG division for these drafts?
>
>(2) RFC5277bis
>  - Proposal coming into WG before submission cut-off date
>
>Length:
>(1) Yang Subscriptions - 20 min
>(2) RFC5277bis - 10 min
>
>Presenter:
>  -  Eric Voit (on behalf of the authors)
>
>Thanks,
>Eric, Alex, Alberto, Ambika, Einar
>
>-------------------
>From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh
>Jethanandani
>Sent: Sunday, March 06, 2016 10:22 PM
>To: NETCONF
>Subject: [Netconf] Agenda Request
>
>It is that time again where we ask if you want to present in the NETCONF
>session at IETF 95.
>
>Please indicate
>
>Topic:
>Length:
>Presenter:
>
>in your request for the slot.
>
>All this assumes that you have published/updated a draft on the mailing
>list and have garnered some discussion around it. If not, there is still
>time to do that before the meeting.
>
>Cheers.
>
>Mahesh & Mehmet
>
>
>
>_______________________________________________
>Netconf mailing list
>Netconf@ietf.org
>https://www.ietf.org/mailman/listinfo/netconf

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


--_000_D317B4036A7D7albertgociscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <173DBB6BDDADF840BADF844EB99383F6@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Thanks Andy,







The draft targets charter item #6. I include it below for convenience.=








One of the goals in the item is to not affect older clients I.e., back=
wards compatibility.


To achieve this, we have kept the mechanisms in 5277. E.g., the create=
-subscription RPC.


If a mechanism in 5277 is not in the draft it is an unintended omissio=
n.







I agree that the complete set of features in the draft is more complex=
 than those in 5277.


Some features are explicitly stated in the charter item (e.g., multipl=
e subscriptions over a session). 


Others, like static subscription, are not mandatory in the yang with t=
he new features.


What is mandatory and what is optional is open to discussion.


A server implementation may only advertise the capabilities correspond=
ing to 5277.







On the point your bring about the authors, I am not familiar with it. =
Guidance from the chairs would be appreciated.







Thanks,







Alberto

















6. Enhance RFC 5277 with the ability to delete sub=
scriptions without 

closing the client session, to modify existing subscrip=
tions, and to 

have multiple subscriptions on a established client ses=
sion. These 

changes should not affect older clients that do not sup=
port these 

particular subscription requirements. The RPCs and the =
data models in 

RFC 5277 should be converted to YANG.














From: Andy Bierman <andy@yumaworks.com>

Date: Tuesday, March 22, 2016 at 10=
:18 PM

To: Alberto Gonzalez Prieto <albertgo@cisco.com>

Cc: "Eric Voit (evoit)" &=
lt;evoit@cisco.com>, Mahesh Jetha=
nandani <mjethanandani@gmail.=
com>, NETCONF <netconf@ietf.o=
rg>

Subject: Re: [Netconf] Agenda Reque=
st













Hi,











I don't know how much agreement there is on requirements or solution.<=
/div>






IMO, this draft should not be called RFC5277bis







 - all mechanisms from RFC 5277 have been removed


 - all RFC 5277 authors have been removed







IMO, the new work should not obsolete RFC 5277, as stated in the draft=
.


The existing notifications work as intended and there are several inde=
pendent


implementations.







This new draft is radically different and much more complex to impleme=
nt on


the client and server than RFC 5277. 

















Andy












On Mon, Mar 21, 2016 at 11:49 AM, Alberto Gonzal=
ez Prieto (albertgo)
<albertgo@cisco.com> wrote:



Hello,



Our proposal for RFC5277-bis has been submitted

(https://datatracker.ietf.org/doc/dra=
ft-gonzalez-netconf-5277bis)

You can find an high-level summary of the draft below.

We would like to present it in the NETCONF session at IETF 95.



Length: 10 minutes

Presenter: Eric Voit





Thanks,



Alberto, Alex, Eric, Einar, and Ambika







This draft targets charter item #6 of the NETCONF WG.

It enhances RFC 5277, addressing limitations identified during the design
of draft-ietf-netconf-yang-push-01 and

draft-voit-netconf-restconf-yang-push-02



Goals of charter item #6, (all of them addressed in the draft):

- Ability to delete subscriptions without closing the client session.

- Ability to modify existing subscriptions.

- Ability to have multiple subscriptions on a client session.

- Do not affect older clients.

- Convert data models in RFC 5277 into YANG.



The draft also includes the following features:

- Subscription negotiation.

- Static subscriptions. (i.e., configuration-driven susbcription)

- Subscription suspension and termination by server.

- Support for multiple encodings (e.g., json).











On 3/7/16, 2:52 PM, "Netconf on behalf of Eric Voit (evoit)"

<netconf-bounces@ietf.org on behalf of
evoit@cisco.com> wrote:



>Hi Mahesh & Mehmet,

>

>Below are the two topics we were hoping present .

>

>Topics:

>(1) Yang Subscriptions

>  -  draft-ietf-netconf-yang-push

>       - WG draft revisions

>       - IETF hackathon demo results: yang-push int=
erworking with

>OpenDaylight

>  -  draft-voit-netconf-restconf-yang-push

>       - New draft this week: shrunk to cover just =
Restconf & HTTP

>transports

>  -  Discussion:  do we have the desired WG division for=
 these drafts?

>

>(2) RFC5277bis

>  - Proposal coming into WG before submission cut-off date

>

>Length:

>(1) Yang Subscriptions - 20 min

>(2) RFC5277bis - 10 min

>

>Presenter:

>  -  Eric Voit (on behalf of the authors)

>

>Thanks,

>Eric, Alex, Alberto, Ambika, Einar

>

>-------------------

>From: Netconf [mailto:netco=
nf-bounces@ietf.org] On Behalf Of Mahesh

>Jethanandani

>Sent: Sunday, March 06, 2016 10:22 PM

>To: NETCONF

>Subject: [Netconf] Agenda Request

>

>It is that time again where we ask if you want to present in the NETCON=
F

>session at IETF 95.

>

>Please indicate

>

>Topic:

>Length:

>Presenter:

>

>in your request for the slot.

>

>All this assumes that you have published/updated a draft on the mailing=


>list and have garnered some discussion around it. If not, there is stil=
l

>time to do that before the meeting.

>

>Cheers.

>

>Mahesh & Mehmet

>

>

>

>_______________________________________________

>Netconf mailing list

>Netconf@ietf.org

>https://www.ietf.org/mailman/listinfo/netconf


_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf





















--_000_D317B4036A7D7albertgociscocom_--


From nobody Tue Mar 22 19:43:59 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6332012D104 for ; Tue, 22 Mar 2016 19:43:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTTh1ocA4qgZ for ; Tue, 22 Mar 2016 19:43:55 -0700 (PDT)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 CA09A12D0ED for ; Tue, 22 Mar 2016 19:43:53 -0700 (PDT)
Received: by mail-lf0-x233.google.com with SMTP id e196so1566110lfg.1 for ; Tue, 22 Mar 2016 19:43:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=sWfRDi0UgA3E0MlY4KZvwuEepvUb19b0N8lgCFKtZR8=; b=KdmqKAUKmlORasjepjFAhAYYhCIKDFx/6e/K+Fl9vERIvNOqrvtCqqfwgYf7qK0VXf yYwLUZVe3fBhXpF3Yi8O/+An0RQtm0l8svhLOHqP8jw/cjg00UXbAMDYrVGoyl3nl7uC HFHEpo5D9LSSaA2cfMugSrwPfB17hTEiE7bbUlrSeY5RbZz372xPz1JllpbvRGdga1T6 aLQmDLACE8BaJh9K3GD/bjAxDr5zEvWULefoHNq0XeqUpb0GOBvXKaFkQyCKP1LKfow6 Qly9Ao0+tBW9+06MYzIXQXrzklOOfSK/kbR6kv33ZhEQwu+AkRX+mr6tZ43LUGJ0LFkZ Xx1w==
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; bh=sWfRDi0UgA3E0MlY4KZvwuEepvUb19b0N8lgCFKtZR8=; b=b7xpK1BuJhnvT3tVxhMax4j+5ANJsOH55PcD/v69ptRw/gsNfIsBPcjDi9XQGnjj2x w8HNXiKB6Js8jYRYonj3IOQHc5V6+yleUc/n3JGU8X8D40ot+RYacu1znH4eARiALwRi C+sWY/gwUbFR+Gzovs5XnyfZVMJjWr6AVFdLDrwyBhLFgw5fsNarsYxio3nDGaKSqJBf wDSP6l6IYEsAD04ohyCeoFLqc2zyhO1OrDKm2NROB0+Z9mBXC++G/TD0iLZ5XT5njTCj JlnDD6k1R/fC5mWqeivAnfuujAWnDqIZBKClWqGWSoWkS0/I9tlLvklLbw7J8HjEPGpw En6w==
X-Gm-Message-State: AD7BkJKTdwccbo531WEYRbV1fWMK5+TrYQ2Aen27fpsiuuR3jDVDHcMHI0HTErXwyi9A/JGJt/1dF4EhnPyZUA==
MIME-Version: 1.0
X-Received: by 10.25.27.200 with SMTP id b191mr187167lfb.8.1458701031997; Tue, 22 Mar 2016 19:43:51 -0700 (PDT)
Received: by 10.112.135.97 with HTTP; Tue, 22 Mar 2016 19:43:51 -0700 (PDT)
In-Reply-To: 
References:     
Date: Tue, 22 Mar 2016 19:43:51 -0700
Message-ID: 
From: Andy Bierman 
To: "Alberto Gonzalez Prieto (albertgo)" 
Content-Type: multipart/alternative; boundary=001a11402c48d897ae052eae4c52
Archived-At: 
Cc: NETCONF 
Subject: Re: [Netconf] Agenda Request
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Mar 2016 02:43:58 -0000

--001a11402c48d897ae052eae4c52
Content-Type: text/plain; charset=UTF-8

Hi,

    These changes should not affect older clients that do not support these
    particular subscription requirements.

So you are claiming that an RFC 5277 client will work with this draft, even
though the namespaces
are changed?  The :interleave capability has been completely removed.

IMO this new work should be decoupled since it appears to be intended
for platforms with extensive resources.
I don't see protocol definitions for a new type of notification delivery,
just a new "receivers" table.  Is interoperability expected without
a protocol definition?

I don't see any text about replayComplete except you augmented the
notification with a subscription-id. The entire replay buffer has been
removed.
Perhaps your intent is to extend RFC 5277 instead of replacing it?


Andy


On Tue, Mar 22, 2016 at 7:13 PM, Alberto Gonzalez Prieto (albertgo) <
albertgo@cisco.com> wrote:

> Thanks Andy,
>
> The draft targets charter item #6. I include it below for convenience.
>
> One of the goals in the item is to not affect older clients I.e.,
> backwards compatibility.
> To achieve this, we have kept the mechanisms in 5277. E.g., the
> create-subscription RPC.
> If a mechanism in 5277 is not in the draft it is an unintended omission.
>
> I agree that the complete set of features in the draft is more complex
> than those in 5277.
> Some features are explicitly stated in the charter item (e.g., multiple
> subscriptions over a session).
> Others, like static subscription, are not mandatory in the yang with the
> new features.
> What is mandatory and what is optional is open to discussion.
> A server implementation may only advertise the capabilities corresponding
> to 5277.
>
> On the point your bring about the authors, I am not familiar with it.
> Guidance from the chairs would be appreciated.
>
> Thanks,
>
> Alberto
>
>
>
> 6. Enhance RFC 5277 with the ability to delete subscriptions without
> closing the client session, to modify existing subscriptions, and to
> have multiple subscriptions on a established client session. These
> changes should not affect older clients that do not support these
> particular subscription requirements. The RPCs and the data models in
> RFC 5277 should be converted to YANG.
>
>
> From: Andy Bierman 
> Date: Tuesday, March 22, 2016 at 10:18 PM
> To: Alberto Gonzalez Prieto 
> Cc: "Eric Voit (evoit)" , Mahesh Jethanandani <
> mjethanandani@gmail.com>, NETCONF 
> Subject: Re: [Netconf] Agenda Request
>
> Hi,
>
>
> I don't know how much agreement there is on requirements or solution.
>
> IMO, this draft should not be called RFC5277bis
>
>  - all mechanisms from RFC 5277 have been removed
>  - all RFC 5277 authors have been removed
>
> IMO, the new work should not obsolete RFC 5277, as stated in the draft.
> The existing notifications work as intended and there are several
> independent
> implementations.
>
> This new draft is radically different and much more complex to implement on
> the client and server than RFC 5277.
>
>
>
> Andy
>
>
> On Mon, Mar 21, 2016 at 11:49 AM, Alberto Gonzalez Prieto (albertgo) <
> albertgo@cisco.com> wrote:
>
>> Hello,
>>
>> Our proposal for RFC5277-bis has been submitted
>> (https://datatracker.ietf.org/doc/draft-gonzalez-netconf-5277bis)
>> You can find an high-level summary of the draft below.
>> We would like to present it in the NETCONF session at IETF 95.
>>
>> Length: 10 minutes
>> Presenter: Eric Voit
>>
>>
>> Thanks,
>>
>> Alberto, Alex, Eric, Einar, and Ambika
>>
>>
>>
>> This draft targets charter item #6 of the NETCONF WG.
>> It enhances RFC 5277, addressing limitations identified during the design
>> of draft-ietf-netconf-yang-push-01 and
>> draft-voit-netconf-restconf-yang-push-02
>>
>> Goals of charter item #6, (all of them addressed in the draft):
>> - Ability to delete subscriptions without closing the client session.
>> - Ability to modify existing subscriptions.
>> - Ability to have multiple subscriptions on a client session.
>> - Do not affect older clients.
>> - Convert data models in RFC 5277 into YANG.
>>
>> The draft also includes the following features:
>> - Subscription negotiation.
>> - Static subscriptions. (i.e., configuration-driven susbcription)
>> - Subscription suspension and termination by server.
>> - Support for multiple encodings (e.g., json).
>>
>>
>>
>>
>>
>> On 3/7/16, 2:52 PM, "Netconf on behalf of Eric Voit (evoit)"
>>  wrote:
>>
>> >Hi Mahesh & Mehmet,
>> >
>> >Below are the two topics we were hoping present .
>> >
>> >Topics:
>> >(1) Yang Subscriptions
>> >  -  draft-ietf-netconf-yang-push
>> >       - WG draft revisions
>> >       - IETF hackathon demo results: yang-push interworking with
>> >OpenDaylight
>> >  -  draft-voit-netconf-restconf-yang-push
>> >       - New draft this week: shrunk to cover just Restconf & HTTP
>> >transports
>> >  -  Discussion:  do we have the desired WG division for these drafts?
>> >
>> >(2) RFC5277bis
>> >  - Proposal coming into WG before submission cut-off date
>> >
>> >Length:
>> >(1) Yang Subscriptions - 20 min
>> >(2) RFC5277bis - 10 min
>> >
>> >Presenter:
>> >  -  Eric Voit (on behalf of the authors)
>> >
>> >Thanks,
>> >Eric, Alex, Alberto, Ambika, Einar
>> >
>> >-------------------
>> >From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh
>> >Jethanandani
>> >Sent: Sunday, March 06, 2016 10:22 PM
>> >To: NETCONF
>> >Subject: [Netconf] Agenda Request
>> >
>> >It is that time again where we ask if you want to present in the NETCONF
>> >session at IETF 95.
>> >
>> >Please indicate
>> >
>> >Topic:
>> >Length:
>> >Presenter:
>> >
>> >in your request for the slot.
>> >
>> >All this assumes that you have published/updated a draft on the mailing
>> >list and have garnered some discussion around it. If not, there is still
>> >time to do that before the meeting.
>> >
>> >Cheers.
>> >
>> >Mahesh & Mehmet
>> >
>> >
>> >
>> >_______________________________________________
>> >Netconf mailing list
>> >Netconf@ietf.org
>> >https://www.ietf.org/mailman/listinfo/netconf
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>
>
>

--001a11402c48d897ae052eae4c52
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

=C2=A0 =C2=A0 These=C2=A0=C2=A0 =C2=A0 parti=
cular subscription requirements.

So you are claiming that an RFC 52=
77 client will work with this draft, even though the namespaces
a=
re changed?=C2=A0 The :interleave capability has been completely removed.

IMO this new work should be decoupled since it appe=
ars to be intended
for platforms with extensive resources.=C2=A0<=
/div>
I don't see protocol definitions for a new type of notificati=
on delivery,
just a new "receivers" table.=C2=A0 Is int=
eroperability expected without
a protocol definition?
<=
br>
I don't see any text about replayComplete except you augm=
ented the
notification with a subscription-id. The entire replay =
buffer has been removed.
Perhaps your intent is to extend RFC 527=
7 instead of replacing it?


Andy


On Tue, Mar 22, 2016 at 7:13 PM, Alberto Gonzalez Prieto (=
albertgo) <albertgo@cisco.com> wrote:







Thanks Andy,







The draft targets charter item #6. I include it below for convenience.=








One of the goals in the item is to not affect older clients I.e., back=
wards compatibility.


To achieve this, we have kept the mechanisms in 5277. E.g., the create=
-subscription RPC.


If a mechanism in 5277 is not in the draft it is an unintended omissio=
n.







I agree that the complete set of features in the draft is more complex=
 than those in 5277.


Some features are explicitly stated in the charter item (e.g., multipl=
e subscriptions over a session).=C2=A0


Others, like static subscription, are not mandatory in the yang with t=
he new features.


What is mandatory and what is optional is open to discussion.


A server implementation may only advertise the capabilities correspond=
ing to 5277.







On the point your bring about the authors, I am not familiar with it. =
Guidance from the chairs would be appreciated.







Thanks,







Alberto

















6. Enhance RFC 5277 with the ability to delete subs=
criptions without=C2=A0

closing the client session, to modify existing subscript=
ions, and to=C2=A0

have multiple subscriptions on a established client sess=
ion. These=C2=A0

changes should not affect older clients that do not supp=
ort these=C2=A0

particular subscription requirements. The RPCs and the d=
ata models in=C2=A0

RFC 5277 should be converted to YANG.














From: Andy Bierman <andy@yumaworks.com>

Date: Tuesday, March 22, 2016 at 10=
:18 PM

To: Alberto Gonzalez Prieto <albertgo@cisco.com=
>

Cc: "Eric Voit (evoit)" &=
lt;evoit@cisco.com=
>, Mahesh Jethanandani <mjethanandani@gmail.com>, NETCONF <netconf@ietf.org>

Subject: Re: [Netconf] Agenda Reque=
st













Hi,











I don't know how much agreement there is on requirements or soluti=
on.







IMO, this draft should not be called RFC5277bis







=C2=A0- all mechanisms from RFC 5277 have been removed


=C2=A0- all RFC 5277 authors have been removed







IMO, the new work should not obsolete RFC 5277, as stated in the draft=
.


The existing notifications work as intended and there are several inde=
pendent


implementations.







This new draft is radically different and much more complex to impleme=
nt on


the client and server than RFC 5277.=C2=A0

















Andy












On Mon, Mar 21, 2016 at 11:49 AM, Alberto Gonzal=
ez Prieto (albertgo)
<albertgo@cisco.com> wrote:



Hello,



Our proposal for RFC5277-bis has been submitted

(https://datatracker.ietf.org/doc/dra=
ft-gonzalez-netconf-5277bis)

You can find an high-level summary of the draft below.

We would like to present it in the NETCONF session at IETF 95.



Length: 10 minutes

Presenter: Eric Voit





Thanks,



Alberto, Alex, Eric, Einar, and Ambika







This draft targets charter item #6 of the NETCONF WG.

It enhances RFC 5277, addressing limitations identified during the design
of draft-ietf-netconf-yang-push-01 and

draft-voit-netconf-restconf-yang-push-02



Goals of charter item #6, (all of them addressed in the draft):

- Ability to delete subscriptions without closing the client session.

- Ability to modify existing subscriptions.

- Ability to have multiple subscriptions on a client session.

- Do not affect older clients.

- Convert data models in RFC 5277 into YANG.



The draft also includes the following features:

- Subscription negotiation.

- Static subscriptions. (i.e., configuration-driven susbcription)

- Subscription suspension and termination by server.

- Support for multiple encodings (e.g., json).











On 3/7/16, 2:52 PM, "Netconf on behalf of Eric Voit (evoit)"

<netconf-b=
ounces@ietf.org on behalf of
evoit@cisco.com>=
; wrote:



>Hi Mahesh & Mehmet,

>

>Below are the two topics we were hoping present .

>

>Topics:

>(1) Yang Subscriptions

>=C2=A0 -=C2=A0 draft-ietf-netconf-yang-push

>=C2=A0 =C2=A0 =C2=A0 =C2=A0- WG draft revisions

>=C2=A0 =C2=A0 =C2=A0 =C2=A0- IETF hackathon demo results: yang-push int=
erworking with

>OpenDaylight

>=C2=A0 -=C2=A0 draft-voit-netconf-restconf-yang-push

>=C2=A0 =C2=A0 =C2=A0 =C2=A0- New draft this week: shrunk to cover just =
Restconf & HTTP

>transports

>=C2=A0 -=C2=A0 Discussion:=C2=A0 do we have the desired WG division for=
 these drafts?

>

>(2) RFC5277bis

>=C2=A0 - Proposal coming into WG before submission cut-off date

>

>Length:

>(1) Yang Subscriptions - 20 min

>(2) RFC5277bis - 10 min

>

>Presenter:

>=C2=A0 -=C2=A0 Eric Voit (on behalf of the authors)

>

>Thanks,

>Eric, Alex, Alberto, Ambika, Einar

>

>-------------------

>From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh

>Jethanandani

>Sent: Sunday, March 06, 2016 10:22 PM

>To: NETCONF

>Subject: [Netconf] Agenda Request

>

>It is that time again where we ask if you want to present in the NETCON=
F

>session at IETF 95.

>

>Please indicate

>

>Topic:

>Length:

>Presenter:

>

>in your request for the slot.

>

>All this assumes that you have published/updated a draft on the mailing=


>list and have garnered some discussion around it. If not, there is stil=
l

>time to do that before the meeting.

>

>Cheers.

>

>Mahesh & Mehmet

>

>

>

>_______________________________________________

>Netconf mailing list

>Netconf@ietf.org<=
/a>

>https://www.ietf.org/mailman/listinfo/netconf


_______________________________________________

Netconf mailing list

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

























--001a11402c48d897ae052eae4c52--


From nobody Tue Mar 22 20:42:08 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A1912D783 for ; Tue, 22 Mar 2016 20:42:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNNrcTzJ31eY for ; Tue, 22 Mar 2016 20:42:04 -0700 (PDT)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 B20A012D17B for ; Tue, 22 Mar 2016 20:42:03 -0700 (PDT)
Received: by mail-lf0-x22d.google.com with SMTP id e196so2143106lfg.1 for ; Tue, 22 Mar 2016 20:42:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=K7J48koOvWVXvIbJEa3j65jIhxB/3FoAtpmKM+vnnrc=; b=dzsKspSKAVzC9fNXhIR1pSbiJub7akXbaDYnED36fxOpgtph4FuCiOh1/ERtLXUWYC uscMJKT0nsDzIot/7dChGjwsbHFzA8h5lnNthXRn3OTsq65KLQfVmOUblk+JMw4DQT9f Csq/Ca9G7tEm4042ixc1x6a6EolyTA0flpZO3S9YRmxFRdRHXZCDs841uEYIjDt7A4Ha gpmflk60RbL/GxuB4dER+Sv0Z4Sdw6aa11DAU3ApBN1NqGqQ2N5mgqdeDJ3O/DO+y2Nb uHAStkP41oYKkG4mFpxtlI3t8seQUBNwJoFuM2sb15zm9LSvABb1dTxY4nySKu4MNiZV B0oQ==
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; bh=K7J48koOvWVXvIbJEa3j65jIhxB/3FoAtpmKM+vnnrc=; b=QFAIKCpy0L/8SIpK8IbR1dcby03mBiarpLuay7CuiJQonilEE11IjwsxRr/ihBBEpj Q3rzeBO7p5GehMdWBg1vtpYrKRDATe0nix+J81Im86wyEmFYR/J+/nvJsVzILVnU++RX dkkyKf4kkDYmGCkxt4M590fikJlnfh6e97bETaQ+ANuo8FutZtEUuCrOcow27NI0yWtk GZDWutquQnId/lm6ATlAtSKTyrMXocY4+qZKsLiiF2oCHlv9lvhjAuYVr3d1i79Eptuh 13O1VLxYEs0SDWO7xPzZFoP8Rb7fIW7tNLzEMJ5HGsFPp/gQy6FbpYDmRSsNYjJymZR3 3hzQ==
X-Gm-Message-State: AD7BkJLo1kWlrPaAZ920rhiCD238+paOsa6bzTBjC5oRYtsAnd0EtyTjuND+GxLgPtxaDAIIufIlAB1Z6XVr8g==
MIME-Version: 1.0
X-Received: by 10.25.85.145 with SMTP id j139mr215984lfb.131.1458704521784; Tue, 22 Mar 2016 20:42:01 -0700 (PDT)
Received: by 10.112.135.97 with HTTP; Tue, 22 Mar 2016 20:42:01 -0700 (PDT)
In-Reply-To: 
References:     
Date: Tue, 22 Mar 2016 20:42:01 -0700
Message-ID: 
From: Andy Bierman 
To: "Alberto Gonzalez Prieto (albertgo)" 
Content-Type: multipart/alternative; boundary=001a11405936da8715052eaf1c5f
Archived-At: 
Cc: NETCONF 
Subject: Re: [Netconf] Agenda Request
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Mar 2016 03:42:06 -0000

--001a11405936da8715052eaf1c5f
Content-Type: text/plain; charset=UTF-8

Hi,

I do not want to give the impression I am against this work.
We will probably implement it.

IMO the best way not to break 5277 implementations or
confuse people is to just extend 5277 with a new RFC
with new operations and new monitoring data.

Here are examples of modules I wrote about 6 years ago
that provide YANG versions of the XSDs in RFC 5277:

http://www.netconfcentral.org/modulereport/nc-notifications
http://www.netconfcentral.org/modulereport/notifications

I think the correct namespaces have to be used to match the XSDs.


Andy



On Tue, Mar 22, 2016 at 7:13 PM, Alberto Gonzalez Prieto (albertgo) <
albertgo@cisco.com> wrote:

> Thanks Andy,
>
> The draft targets charter item #6. I include it below for convenience.
>
> One of the goals in the item is to not affect older clients I.e.,
> backwards compatibility.
> To achieve this, we have kept the mechanisms in 5277. E.g., the
> create-subscription RPC.
> If a mechanism in 5277 is not in the draft it is an unintended omission.
>
> I agree that the complete set of features in the draft is more complex
> than those in 5277.
> Some features are explicitly stated in the charter item (e.g., multiple
> subscriptions over a session).
> Others, like static subscription, are not mandatory in the yang with the
> new features.
> What is mandatory and what is optional is open to discussion.
> A server implementation may only advertise the capabilities corresponding
> to 5277.
>
> On the point your bring about the authors, I am not familiar with it.
> Guidance from the chairs would be appreciated.
>
> Thanks,
>
> Alberto
>
>
>
> 6. Enhance RFC 5277 with the ability to delete subscriptions without
> closing the client session, to modify existing subscriptions, and to
> have multiple subscriptions on a established client session. These
> changes should not affect older clients that do not support these
> particular subscription requirements. The RPCs and the data models in
> RFC 5277 should be converted to YANG.
>
>
> From: Andy Bierman 
> Date: Tuesday, March 22, 2016 at 10:18 PM
> To: Alberto Gonzalez Prieto 
> Cc: "Eric Voit (evoit)" , Mahesh Jethanandani <
> mjethanandani@gmail.com>, NETCONF 
> Subject: Re: [Netconf] Agenda Request
>
> Hi,
>
>
> I don't know how much agreement there is on requirements or solution.
>
> IMO, this draft should not be called RFC5277bis
>
>  - all mechanisms from RFC 5277 have been removed
>  - all RFC 5277 authors have been removed
>
> IMO, the new work should not obsolete RFC 5277, as stated in the draft.
> The existing notifications work as intended and there are several
> independent
> implementations.
>
> This new draft is radically different and much more complex to implement on
> the client and server than RFC 5277.
>
>
>
> Andy
>
>
> On Mon, Mar 21, 2016 at 11:49 AM, Alberto Gonzalez Prieto (albertgo) <
> albertgo@cisco.com> wrote:
>
>> Hello,
>>
>> Our proposal for RFC5277-bis has been submitted
>> (https://datatracker.ietf.org/doc/draft-gonzalez-netconf-5277bis)
>> You can find an high-level summary of the draft below.
>> We would like to present it in the NETCONF session at IETF 95.
>>
>> Length: 10 minutes
>> Presenter: Eric Voit
>>
>>
>> Thanks,
>>
>> Alberto, Alex, Eric, Einar, and Ambika
>>
>>
>>
>> This draft targets charter item #6 of the NETCONF WG.
>> It enhances RFC 5277, addressing limitations identified during the design
>> of draft-ietf-netconf-yang-push-01 and
>> draft-voit-netconf-restconf-yang-push-02
>>
>> Goals of charter item #6, (all of them addressed in the draft):
>> - Ability to delete subscriptions without closing the client session.
>> - Ability to modify existing subscriptions.
>> - Ability to have multiple subscriptions on a client session.
>> - Do not affect older clients.
>> - Convert data models in RFC 5277 into YANG.
>>
>> The draft also includes the following features:
>> - Subscription negotiation.
>> - Static subscriptions. (i.e., configuration-driven susbcription)
>> - Subscription suspension and termination by server.
>> - Support for multiple encodings (e.g., json).
>>
>>
>>
>>
>>
>> On 3/7/16, 2:52 PM, "Netconf on behalf of Eric Voit (evoit)"
>>  wrote:
>>
>> >Hi Mahesh & Mehmet,
>> >
>> >Below are the two topics we were hoping present .
>> >
>> >Topics:
>> >(1) Yang Subscriptions
>> >  -  draft-ietf-netconf-yang-push
>> >       - WG draft revisions
>> >       - IETF hackathon demo results: yang-push interworking with
>> >OpenDaylight
>> >  -  draft-voit-netconf-restconf-yang-push
>> >       - New draft this week: shrunk to cover just Restconf & HTTP
>> >transports
>> >  -  Discussion:  do we have the desired WG division for these drafts?
>> >
>> >(2) RFC5277bis
>> >  - Proposal coming into WG before submission cut-off date
>> >
>> >Length:
>> >(1) Yang Subscriptions - 20 min
>> >(2) RFC5277bis - 10 min
>> >
>> >Presenter:
>> >  -  Eric Voit (on behalf of the authors)
>> >
>> >Thanks,
>> >Eric, Alex, Alberto, Ambika, Einar
>> >
>> >-------------------
>> >From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh
>> >Jethanandani
>> >Sent: Sunday, March 06, 2016 10:22 PM
>> >To: NETCONF
>> >Subject: [Netconf] Agenda Request
>> >
>> >It is that time again where we ask if you want to present in the NETCONF
>> >session at IETF 95.
>> >
>> >Please indicate
>> >
>> >Topic:
>> >Length:
>> >Presenter:
>> >
>> >in your request for the slot.
>> >
>> >All this assumes that you have published/updated a draft on the mailing
>> >list and have garnered some discussion around it. If not, there is still
>> >time to do that before the meeting.
>> >
>> >Cheers.
>> >
>> >Mahesh & Mehmet
>> >
>> >
>> >
>> >_______________________________________________
>> >Netconf mailing list
>> >Netconf@ietf.org
>> >https://www.ietf.org/mailman/listinfo/netconf
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>
>
>

--001a11405936da8715052eaf1c5f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

I do not want to give the impressio=
n I am against this work.
We will probably implement it.

IMO the best way not to break 5277 implementations or
confuse people is to just extend 5277 with a new RFC
with n=
ew operations and new monitoring data.

Here are ex=
amples of modules I wrote about 6 years ago
that provide YANG ver=
sions of the XSDs in RFC 5277:


I think the correct namespaces have to be used to match th=
e XSDs.


Andy


=

On Tue, Mar 22, 2016 at 7:13 PM, Alberto Gon=
zalez Prieto (albertgo) <albertgo@cisco.com> wrote:







Thanks Andy,







The draft targets charter item #6. I include it below for convenience.=








One of the goals in the item is to not affect older clients I.e., back=
wards compatibility.


To achieve this, we have kept the mechanisms in 5277. E.g., the create=
-subscription RPC.


If a mechanism in 5277 is not in the draft it is an unintended omissio=
n.







I agree that the complete set of features in the draft is more complex=
 than those in 5277.


Some features are explicitly stated in the charter item (e.g., multipl=
e subscriptions over a session).=C2=A0


Others, like static subscription, are not mandatory in the yang with t=
he new features.


What is mandatory and what is optional is open to discussion.


A server implementation may only advertise the capabilities correspond=
ing to 5277.







On the point your bring about the authors, I am not familiar with it. =
Guidance from the chairs would be appreciated.







Thanks,







Alberto

















6. Enhance RFC 5277 with the ability to delete subs=
criptions without=C2=A0

closing the client session, to modify existing subscript=
ions, and to=C2=A0

have multiple subscriptions on a established client sess=
ion. These=C2=A0

changes should not affect older clients that do not supp=
ort these=C2=A0

particular subscription requirements. The RPCs and the d=
ata models in=C2=A0

RFC 5277 should be converted to YANG.














From: Andy Bierman <andy@yumaworks.com>

Date: Tuesday, March 22, 2016 at 10=
:18 PM

To: Alberto Gonzalez Prieto <albertgo@cisco.com=
>

Cc: "Eric Voit (evoit)" &=
lt;evoit@cisco.com=
>, Mahesh Jethanandani <mjethanandani@gmail.com>, NETCONF <netconf@ietf.org>

Subject: Re: [Netconf] Agenda Reque=
st













Hi,











I don't know how much agreement there is on requirements or soluti=
on.







IMO, this draft should not be called RFC5277bis







=C2=A0- all mechanisms from RFC 5277 have been removed


=C2=A0- all RFC 5277 authors have been removed







IMO, the new work should not obsolete RFC 5277, as stated in the draft=
.


The existing notifications work as intended and there are several inde=
pendent


implementations.







This new draft is radically different and much more complex to impleme=
nt on


the client and server than RFC 5277.=C2=A0

















Andy












On Mon, Mar 21, 2016 at 11:49 AM, Alberto Gonzal=
ez Prieto (albertgo)
<albertgo@cisco.com> wrote:



Hello,



Our proposal for RFC5277-bis has been submitted

(https://datatracker.ietf.org/doc/dra=
ft-gonzalez-netconf-5277bis)

You can find an high-level summary of the draft below.

We would like to present it in the NETCONF session at IETF 95.



Length: 10 minutes

Presenter: Eric Voit





Thanks,



Alberto, Alex, Eric, Einar, and Ambika







This draft targets charter item #6 of the NETCONF WG.

It enhances RFC 5277, addressing limitations identified during the design
of draft-ietf-netconf-yang-push-01 and

draft-voit-netconf-restconf-yang-push-02



Goals of charter item #6, (all of them addressed in the draft):

- Ability to delete subscriptions without closing the client session.

- Ability to modify existing subscriptions.

- Ability to have multiple subscriptions on a client session.

- Do not affect older clients.

- Convert data models in RFC 5277 into YANG.



The draft also includes the following features:

- Subscription negotiation.

- Static subscriptions. (i.e., configuration-driven susbcription)

- Subscription suspension and termination by server.

- Support for multiple encodings (e.g., json).











On 3/7/16, 2:52 PM, "Netconf on behalf of Eric Voit (evoit)"

<netconf-b=
ounces@ietf.org on behalf of
evoit@cisco.com>=
; wrote:



>Hi Mahesh & Mehmet,

>

>Below are the two topics we were hoping present .

>

>Topics:

>(1) Yang Subscriptions

>=C2=A0 -=C2=A0 draft-ietf-netconf-yang-push

>=C2=A0 =C2=A0 =C2=A0 =C2=A0- WG draft revisions

>=C2=A0 =C2=A0 =C2=A0 =C2=A0- IETF hackathon demo results: yang-push int=
erworking with

>OpenDaylight

>=C2=A0 -=C2=A0 draft-voit-netconf-restconf-yang-push

>=C2=A0 =C2=A0 =C2=A0 =C2=A0- New draft this week: shrunk to cover just =
Restconf & HTTP

>transports

>=C2=A0 -=C2=A0 Discussion:=C2=A0 do we have the desired WG division for=
 these drafts?

>

>(2) RFC5277bis

>=C2=A0 - Proposal coming into WG before submission cut-off date

>

>Length:

>(1) Yang Subscriptions - 20 min

>(2) RFC5277bis - 10 min

>

>Presenter:

>=C2=A0 -=C2=A0 Eric Voit (on behalf of the authors)

>

>Thanks,

>Eric, Alex, Alberto, Ambika, Einar

>

>-------------------

>From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh

>Jethanandani

>Sent: Sunday, March 06, 2016 10:22 PM

>To: NETCONF

>Subject: [Netconf] Agenda Request

>

>It is that time again where we ask if you want to present in the NETCON=
F

>session at IETF 95.

>

>Please indicate

>

>Topic:

>Length:

>Presenter:

>

>in your request for the slot.

>

>All this assumes that you have published/updated a draft on the mailing=


>list and have garnered some discussion around it. If not, there is stil=
l

>time to do that before the meeting.

>

>Cheers.

>

>Mahesh & Mehmet

>

>

>

>_______________________________________________

>Netconf mailing list

>Netconf@ietf.org<=
/a>

>https://www.ietf.org/mailman/listinfo/netconf


_______________________________________________

Netconf mailing list

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

























--001a11405936da8715052eaf1c5f--


From nobody Wed Mar 23 02:31:13 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA7A12DBA8 for ; Wed, 23 Mar 2016 02:31:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaBl-A2X4uyN for ; Wed, 23 Mar 2016 02:31:09 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C031C12DBA7 for ; Wed, 23 Mar 2016 02:31:08 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 824971CC006C; Wed, 23 Mar 2016 10:31:17 +0100 (CET)
From: Ladislav Lhotka 
To: Andy Bierman 
In-Reply-To: 
References:  <20160322.084841.1381513591842449169.mbj@tail-f.com>     
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Wed, 23 Mar 2016 10:31:06 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] RESTCONF examples
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Mar 2016 09:31:12 -0000

Andy Bierman  writes:

> On Tue, Mar 22, 2016 at 7:26 AM, Ladislav Lhotka  wrote:
>
>> Andy Bierman  writes:
>>
>> > On Tue, Mar 22, 2016 at 6:10 AM, Ladislav Lhotka  wrote:
>> >
>> >> Hi,
>> >>
>> >> I checked the book RESTful Web Services by Richardson & Ruby, and they
>> >> illustrate a recommended design of resources with the following example:
>> >>
>> >> | Operation      | HTTP action      |
>> >> |----------------+------------------|
>> >> | List the users | GET /users       |
>> >> | Create a user  | POST /users      |
>> >> | View a user    | GET /users/52    |
>> >> | Modify a user  | PUT /users/52    |
>> >> | Delete a user  | DELETE /users/52 |
>> >>
>> >>
>> >
>> >
>> >
>> >> I think RESTCONF should follow the same pattern because this is what
>> >> developers are used to. The logic of some examples in the RESTCONF spec
>> >> - namely what's a resource and what's its value - isn't very clear to
>> >> me.
>> >>
>> >
>> >
>> > This is what we have except lists are encoded in 1 segment instead
>> > of list key values in their own segment.
>> >
>> > Please provide OLD and NEW text fragments that you think need to be
>> > changed
>>
>> I did it already, without the OLD and NEW labels, so here it is again:
>>
>> ---------------------------------------------------------------------
>> OLD
>>
>>       POST /restconf/data/example-jukebox:jukebox/
>>           playlist=Foo-One?insert=first HTTP/1.1
>>       Host: example.com
>>       Content-Type: application/yang.data+json
>>
>>       {
>>         "example-jukebox:song" : {
>>            "index" : 1,
>>            "id" : "/example-jukebox:jukebox/library/
>>                artist=Foo%20Fighters/album=Wasting%20Light/song=Rope"
>>          }
>>       }
>>
>> NEW
>>
>>       POST /restconf/data/example-jukebox:jukebox/
>>           playlist=Foo-One/song?insert=first HTTP/1.1
>>       Host: example.com
>>       Content-Type: application/yang.data+json
>>
>>       {
>>         "index" : 1,
>>         "id" : "/example-jukebox:jukebox/library/
>>           artist=Foo%20Fighters/album=Wasting%20Light/song=Rope"
>>       }
>> ---------------------------------------------------------------------
>>
>> If we agree that this example adds an entry to the "song" list, then IMO
>> "song" needs to appear in the Request-URI.
>>
>>
>
> This is not how RESTCONF has been defined from the start.

Let's see. The Request-URI in the OLD version is

/restconf/data/example-jukebox:jukebox/playlist=Foo-One?insert=first

According to sec. 1.1.4, the target resource is the "Foo-One" entry of
the "playlist" list. Correct?

Then sec. 4.8.4 says:

   [The "insert" query parameter] is also only supported if the target
   resource is a data resource, and that data represents a YANG list or
   leaf-list that is ordered by the user.

To me, this means that the example is incorrect because the target
resource is *not* a list ordered-by user.

Lada

> The parent of the new song is used in POST URI because
> the song does not exist yet.   The parent album MUST exist already.
>
> If PUT is used to create the song resource, then the URI points to the song
> resource
> instance.
>
>
>
>
>
> Lada
>>
>
>
> Andy
>
>
>>
>> >
>> >
>> >
>> >
>> >>
>> >> Lada
>> >>
>> >
>> >
>> > Andy
>> >
>> >
>> >>
>> >> Ladislav Lhotka  writes:
>> >>
>> >> >> On 22 Mar 2016, at 08:48, Martin Bjorklund  wrote:
>> >> >>
>> >> >> Ladislav Lhotka  wrote:
>> >> >>> Hi,
>> >> >>>
>> >> >>> I am confused by this example in draft-ietf-netconf-restconf-10,
>> >> >>> appendix D.3.4:
>> >> >>>
>> >> >>>      POST /restconf/data/example-jukebox:jukebox/
>> >> >>>          playlist=Foo-One?insert=first HTTP/1.1
>> >> >>>      Host: example.com
>> >> >>>      Content-Type: application/yang.data+json
>> >> >>>
>> >> >>>      {
>> >> >>>        "example-jukebox:song" : {
>> >> >>>           "index" : 1,
>> >> >>>           "id" : "/example-jukebox:jukebox/library/
>> >> >>>               artist=Foo%20Fighters/album=Wasting%20Light/song=Rope"
>> >> >>>         }
>> >> >>>      }
>> >> >>>
>> >> >>> The text says "..., a new first entry in the "Foo-One" playlist is
>> >> being
>> >> >>> created."
>> >> >>>
>> >> >>> It seems to me that in fact a new first entry of the "song" list
>> inside
>> >> >>> the "Foo-One" playlist is supposed to be created.
>> >> >>
>> >> >> You are right:
>> >> >>
>> >> >> OLD:
>> >> >>
>> >> >>  In this example, a new first entry in the "Foo-One" playlist
>> >> >>  is being created.
>> >> >>
>> >> >> NEW:
>> >> >>
>> >> >>  In this example, a new first song entry in the "Foo-One" playlist
>> >> >>  is being created.
>> >> >>
>> >> >>
>> >> >>> And then the request
>> >> >>> should IMO be
>> >> >>>
>> >> >>>      POST /restconf/data/example-jukebox:jukebox/
>> >> >>>          playlist=Foo-One/song?insert=first HTTP/1.1
>> >> >>>      Host: example.com
>> >> >>>      Content-Type: application/yang.data+json
>> >> >>>
>> >> >>>      {
>> >> >>>        "index" : 1,
>> >> >>>        "id" : "/example-jukebox:jukebox/library/
>> >> >>>          artist=Foo%20Fighters/album=Wasting%20Light/song=Rope"
>> >> >>>      }
>> >> >>>
>> >> >>> That is, the client is posting to the "song" resource
>> >> >>
>> >> >> No, there is no "song" resource, since all data resources are YANG
>> >> >> data nodes.
>> >> >
>> >> > Are you saying that the user-ordered "song" list is *not* a YANG data
>> >> node?
>> >> >
>> >> > Also, the body
>> >> >
>> >> >       {
>> >> >         "example-jukebox:song" : {
>> >> >            "index" : 1,
>> >> >            "id" : "/example-jukebox:jukebox/library/
>> >> >                artist=Foo%20Fighters/album=Wasting%20Light/song=Rope"
>> >> >          }
>> >> >       }
>> >> >
>> >> > is counter-intuitive, to say the least, because it looks like "song"
>> is
>> >> a container, which it isn't.
>> >> >
>> >> > Lada
>> >> >
>> >> >>
>> >> >>
>> >> >> /martin
>> >> >>
>> >> >>
>> >> >>> , namely creating
>> >> >>> its new first entry whose content is specified in the body.
>> >> >>>
>> >> >>> Am I missing something?
>> >> >>>
>> >> >>> Thanks, Lada
>> >> >>>
>> >> >>> --
>> >> >>> Ladislav Lhotka, CZ.NIC Labs
>> >> >>> PGP Key ID: E74E8C0C
>> >> >>>
>> >> >>> _______________________________________________
>> >> >>> Netconf mailing list
>> >> >>> Netconf@ietf.org
>> >> >>> https://www.ietf.org/mailman/listinfo/netconf
>> >> >
>> >> > --
>> >> > Ladislav Lhotka, CZ.NIC Labs
>> >> > PGP Key ID: E74E8C0C
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Netconf mailing list
>> >> > Netconf@ietf.org
>> >> > https://www.ietf.org/mailman/listinfo/netconf
>> >>
>> >> --
>> >> Ladislav Lhotka, CZ.NIC Labs
>> >> PGP Key ID: E74E8C0C
>> >>
>> >> _______________________________________________
>> >> Netconf mailing list
>> >> Netconf@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/netconf
>> >>
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>

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


From nobody Wed Mar 23 13:55:49 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124F412D90D for ; Wed, 23 Mar 2016 13:55:49 -0700 (PDT)
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 autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFg4uKrskxza for ; Wed, 23 Mar 2016 13:55:47 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CE78012D908 for ; Wed, 23 Mar 2016 13:55:46 -0700 (PDT)
Received: from localhost (h-53-58.a165.priv.bahnhof.se [46.59.53.58]) by mail.tail-f.com (Postfix) with ESMTPSA id 4F7251AE0385; Wed, 23 Mar 2016 21:55:45 +0100 (CET)
Date: Wed, 23 Mar 2016 21:55:44 +0100 (CET)
Message-Id: <20160323.215544.166438758609320904.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References:   
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] RESTCONF examples
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Mar 2016 20:55:49 -0000

Ladislav Lhotka  wrote:
> Andy Bierman  writes:
> 
> > On Tue, Mar 22, 2016 at 7:26 AM, Ladislav Lhotka  wrote:
> >
> >> Andy Bierman  writes:
> >>
> >> > On Tue, Mar 22, 2016 at 6:10 AM, Ladislav Lhotka  wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> I checked the book RESTful Web Services by Richardson & Ruby, and they
> >> >> illustrate a recommended design of resources with the following example:
> >> >>
> >> >> | Operation      | HTTP action      |
> >> >> |----------------+------------------|
> >> >> | List the users | GET /users       |
> >> >> | Create a user  | POST /users      |
> >> >> | View a user    | GET /users/52    |
> >> >> | Modify a user  | PUT /users/52    |
> >> >> | Delete a user  | DELETE /users/52 |
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> >> I think RESTCONF should follow the same pattern because this is what
> >> >> developers are used to. The logic of some examples in the RESTCONF spec
> >> >> - namely what's a resource and what's its value - isn't very clear to
> >> >> me.
> >> >>
> >> >
> >> >
> >> > This is what we have except lists are encoded in 1 segment instead
> >> > of list key values in their own segment.
> >> >
> >> > Please provide OLD and NEW text fragments that you think need to be
> >> > changed
> >>
> >> I did it already, without the OLD and NEW labels, so here it is again:
> >>
> >> ---------------------------------------------------------------------
> >> OLD
> >>
> >>       POST /restconf/data/example-jukebox:jukebox/
> >>           playlist=Foo-One?insert=first HTTP/1.1
> >>       Host: example.com
> >>       Content-Type: application/yang.data+json
> >>
> >>       {
> >>         "example-jukebox:song" : {
> >>            "index" : 1,
> >>            "id" : "/example-jukebox:jukebox/library/
> >>                artist=Foo%20Fighters/album=Wasting%20Light/song=Rope"
> >>          }
> >>       }
> >>
> >> NEW
> >>
> >>       POST /restconf/data/example-jukebox:jukebox/
> >>           playlist=Foo-One/song?insert=first HTTP/1.1
> >>       Host: example.com
> >>       Content-Type: application/yang.data+json
> >>
> >>       {
> >>         "index" : 1,
> >>         "id" : "/example-jukebox:jukebox/library/
> >>           artist=Foo%20Fighters/album=Wasting%20Light/song=Rope"
> >>       }
> >> ---------------------------------------------------------------------
> >>
> >> If we agree that this example adds an entry to the "song" list, then IMO
> >> "song" needs to appear in the Request-URI.
> >>
> >>
> >
> > This is not how RESTCONF has been defined from the start.
> 
> Let's see. The Request-URI in the OLD version is
> 
> /restconf/data/example-jukebox:jukebox/playlist=Foo-One?insert=first
> 
> According to sec. 1.1.4, the target resource is the "Foo-One" entry of
> the "playlist" list. Correct?
> 
> Then sec. 4.8.4 says:
> 
>    [The "insert" query parameter] is also only supported if the target
>    resource is a data resource, and that data represents a YANG list or
>    leaf-list that is ordered by the user.
> 
> To me, this means that the example is incorrect because the target
> resource is *not* a list ordered-by user.

I think the quoted text is wrong.  For PUT, "insert" is only valid
if the target resource is an obu list.  For POST, "insert" is only
valid if the child resource is an obu list.


/martin


From nobody Wed Mar 23 17:49:37 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39D612D1D4 for ; Wed, 23 Mar 2016 17:49:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level: 
X-Spam-Status: No, score=-14.53 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXpP1deGqRSW for ; Wed, 23 Mar 2016 17:49:33 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59ED012DA0F for ; Wed, 23 Mar 2016 17:49:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23232; q=dns/txt; s=iport; t=1458780573; x=1459990173; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kKU881nuSMxMXZcliT5IsFpCbaF5M3ztY5T2wWEwh+o=; b=fgvqcOSKGQ/n+Te1nrDJixGIlU/cclXamNZbOddoeWio/ymCnAxvfasl pENhnGSqnPSu0S4qn6XXOjoTOdAGvfCxHmD1as1qyixjzu9pRiievb0ST bL1NV6toJv9W9jX5SmAIJzwCP/1qZt/MkBcbJtDiPUS3/fLpC06pXwUrb Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAgBIOPNW/4ENJK1egmdMU3oGrwuLT?= =?us-ascii?q?gENgXAXAQmFIkoCgUM4FAEBAQEBAQFkJ4RBAQEBBAEBAWsLEAIBCBEDAQEBDho?= =?us-ascii?q?HIQYLFAkIAgQOBRuHdwMSDrwSDYR6AQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSKY?= =?us-ascii?q?oI+gWY4DYUpBYdgiySEJTEBhXCGHoF1gWaETIhYaoZIh1QBHgEBQoNlaohQAh4?= =?us-ascii?q?DBBZ+AQEB?=
X-IronPort-AV: E=Sophos;i="5.24,383,1454976000";  d="scan'208,217";a="252858789"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Mar 2016 00:49:31 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u2O0nVwV028296 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 24 Mar 2016 00:49:31 GMT
Received: from xch-rtp-003.cisco.com (64.101.220.143) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 23 Mar 2016 20:49:31 -0400
Received: from xch-rtp-003.cisco.com ([64.101.220.143]) by XCH-RTP-003.cisco.com ([64.101.220.143]) with mapi id 15.00.1104.009; Wed, 23 Mar 2016 20:49:31 -0400
From: "Alberto Gonzalez Prieto (albertgo)" 
To: Andy Bierman 
Thread-Topic: [Netconf] Agenda Request
Thread-Index: AQHReCCXnxWOt0Dw+0uIkww9TXgdy59OZWuAgBZC+ICAAatAAIAAYwOA///30YCAAYMtgA==
Date: Thu, 24 Mar 2016 00:49:31 +0000
Message-ID: 
References:      
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.1.160122
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.167.72]
Content-Type: multipart/alternative; boundary="_000_D318F0DD6ABA5albertgociscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: NETCONF 
Subject: Re: [Netconf] Agenda Request
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Mar 2016 00:49:35 -0000

--_000_D318F0DD6ABA5albertgociscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Thanks for your input Andy,

The goal is not to affect older clients. Anything that departs from that wi=
ll be addressed.
You point at two items. The situation is different in those two cases:
- namespaces. The ones in the examples are the ones in RFC5277. In the yang=
 models, we added a TODO note because to pass the pyang =97ietf validation,=
 we could not use the correct namespace. This is in our TODO list.
- interleave capability. This is an unintended omission. Added to our TODO =
list. Thanks!

On the receivers. You are correct. That is work-in-progress. I will add to =
the draft a list of work-in-progress items to facilitate the discussion.

On the replay.  Section 2.11.1 is about replayComplete.  The replay log is =
mentioned in 2.5.1 and in the yang. This can be better presented. I will re=
visit it.


Thanks,

Alberto

From: Andy Bierman >
Date: Wednesday, March 23, 2016 at 3:43 AM
To: Alberto Gonzalez Prieto >
Cc: "Eric Voit (evoit)" >, Mahesh J=
ethanandani >, NETC=
ONF >
Subject: Re: [Netconf] Agenda Request

Hi,

    These changes should not affect older clients that do not support these
    particular subscription requirements.

So you are claiming that an RFC 5277 client will work with this draft, even=
 though the namespaces
are changed?  The :interleave capability has been completely removed.

IMO this new work should be decoupled since it appears to be intended
for platforms with extensive resources.
I don't see protocol definitions for a new type of notification delivery,
just a new "receivers" table.  Is interoperability expected without
a protocol definition?

I don't see any text about replayComplete except you augmented the
notification with a subscription-id. The entire replay buffer has been remo=
ved.
Perhaps your intent is to extend RFC 5277 instead of replacing it?


Andy


On Tue, Mar 22, 2016 at 7:13 PM, Alberto Gonzalez Prieto (albertgo) > wrote:
Thanks Andy,

The draft targets charter item #6. I include it below for convenience.

One of the goals in the item is to not affect older clients I.e., backwards=
 compatibility.
To achieve this, we have kept the mechanisms in 5277. E.g., the create-subs=
cription RPC.
If a mechanism in 5277 is not in the draft it is an unintended omission.

I agree that the complete set of features in the draft is more complex than=
 those in 5277.
Some features are explicitly stated in the charter item (e.g., multiple sub=
scriptions over a session).
Others, like static subscription, are not mandatory in the yang with the ne=
w features.
What is mandatory and what is optional is open to discussion.
A server implementation may only advertise the capabilities corresponding t=
o 5277.

On the point your bring about the authors, I am not familiar with it. Guida=
nce from the chairs would be appreciated.

Thanks,

Alberto



6. Enhance RFC 5277 with the ability to delete subscriptions without
closing the client session, to modify existing subscriptions, and to
have multiple subscriptions on a established client session. These
changes should not affect older clients that do not support these
particular subscription requirements. The RPCs and the data models in
RFC 5277 should be converted to YANG.


From: Andy Bierman >
Date: Tuesday, March 22, 2016 at 10:18 PM
To: Alberto Gonzalez Prieto >
Cc: "Eric Voit (evoit)" >, Mahesh J=
ethanandani >, NETC=
ONF >
Subject: Re: [Netconf] Agenda Request

Hi,


I don't know how much agreement there is on requirements or solution.

IMO, this draft should not be called RFC5277bis

 - all mechanisms from RFC 5277 have been removed
 - all RFC 5277 authors have been removed

IMO, the new work should not obsolete RFC 5277, as stated in the draft.
The existing notifications work as intended and there are several independe=
nt
implementations.

This new draft is radically different and much more complex to implement on
the client and server than RFC 5277.



Andy


On Mon, Mar 21, 2016 at 11:49 AM, Alberto Gonzalez Prieto (albertgo) > wrote:
Hello,

Our proposal for RFC5277-bis has been submitted
(https://datatracker.ietf.org/doc/draft-gonzalez-netconf-5277bis)
You can find an high-level summary of the draft below.
We would like to present it in the NETCONF session at IETF 95.

Length: 10 minutes
Presenter: Eric Voit


Thanks,

Alberto, Alex, Eric, Einar, and Ambika



This draft targets charter item #6 of the NETCONF WG.
It enhances RFC 5277, addressing limitations identified during the design
of draft-ietf-netconf-yang-push-01 and
draft-voit-netconf-restconf-yang-push-02

Goals of charter item #6, (all of them addressed in the draft):
- Ability to delete subscriptions without closing the client session.
- Ability to modify existing subscriptions.
- Ability to have multiple subscriptions on a client session.
- Do not affect older clients.
- Convert data models in RFC 5277 into YANG.

The draft also includes the following features:
- Subscription negotiation.
- Static subscriptions. (i.e., configuration-driven susbcription)
- Subscription suspension and termination by server.
- Support for multiple encodings (e.g., json).





On 3/7/16, 2:52 PM, "Netconf on behalf of Eric Voit (evoit)"
 on behalf of evo=
it@cisco.com> wrote:

>Hi Mahesh & Mehmet,
>
>Below are the two topics we were hoping present .
>
>Topics:
>(1) Yang Subscriptions
>  -  draft-ietf-netconf-yang-push
>       - WG draft revisions
>       - IETF hackathon demo results: yang-push interworking with
>OpenDaylight
>  -  draft-voit-netconf-restconf-yang-push
>       - New draft this week: shrunk to cover just Restconf & HTTP
>transports
>  -  Discussion:  do we have the desired WG division for these drafts?
>
>(2) RFC5277bis
>  - Proposal coming into WG before submission cut-off date
>
>Length:
>(1) Yang Subscriptions - 20 min
>(2) RFC5277bis - 10 min
>
>Presenter:
>  -  Eric Voit (on behalf of the authors)
>
>Thanks,
>Eric, Alex, Alberto, Ambika, Einar
>
>-------------------
>From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh
>Jethanandani
>Sent: Sunday, March 06, 2016 10:22 PM
>To: NETCONF
>Subject: [Netconf] Agenda Request
>
>It is that time again where we ask if you want to present in the NETCONF
>session at IETF 95.
>
>Please indicate
>
>Topic:
>Length:
>Presenter:
>
>in your request for the slot.
>
>All this assumes that you have published/updated a draft on the mailing
>list and have garnered some discussion around it. If not, there is still
>time to do that before the meeting.
>
>Cheers.
>
>Mahesh & Mehmet
>
>
>
>_______________________________________________
>Netconf mailing list
>Netconf@ietf.org
>https://www.ietf.org/mailman/listinfo/netconf

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



--_000_D318F0DD6ABA5albertgociscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <4A2AACDC451E1D4FBE73D841E0BBD228@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Thanks for your input Andy,







The goal is not to affect older clients. Anything that departs from th=
at will be addressed.


You point at two items. The situation is different in those two cases:=



- namespaces. The ones in the examples are the ones in RFC5277. In the=
 yang models, we added a TODO note because to pass the pyang =97ietf valida=
tion, we could not use the correct namespace. This is in our TODO list.

- interleave capability. This is an unintended omission. Added to our =
TODO list. Thanks!







On the receivers. You are correct. That is work-in-progress. I will ad=
d to the draft a list of work-in-progress items to facilitate the discussio=
n.







On the replay.  Section 2.11.1 is about replayComplete.  The=
 replay log is mentioned in 2.5.1 and in the yang. This can be better prese=
nted. I will revisit it.












Thanks,







Alberto









From: Andy Bierman <andy@yumaworks.com>

Date: Wednesday, March 23, 2016 at =
3:43 AM

To: Alberto Gonzalez Prieto <albertgo@cisco.com>

Cc: "Eric Voit (evoit)" &=
lt;evoit@cisco.com>, Mahesh Jetha=
nandani <mjethanandani@gmail.=
com>, NETCONF <netconf@ietf.o=
rg>

Subject: Re: [Netconf] Agenda Reque=
st













Hi,






    These changes should not affect
 older clients that do not support these 


    particular subscription=
 requirements.









So you are claiming that an RFC 5277 client will work with this draft,=
 even though the namespaces


are changed?  The :interleave capability has been completely remo=
ved.







IMO this new work should be decoupled since it appears to be intended<=
/div>

for platforms with extensive resources. 


I don't see protocol definitions for a new type of notification delive=
ry,


just a new "receivers" table.  Is interoperability expe=
cted without


a protocol definition?







I don't see any text about replayComplete except you augmented the

notification with a subscription-id. The entire replay buffer has been=
 removed.


Perhaps your intent is to extend RFC 5277 instead of replacing it?











Andy
















On Tue, Mar 22, 2016 at 7:13 PM, Alberto Gonzale=
z Prieto (albertgo)
<albertgo@cisco.com> wrote:






Thanks Andy,







The draft targets charter item #6. I include it below for convenience.=








One of the goals in the item is to not affect older clients I.e., back=
wards compatibility.


To achieve this, we have kept the mechanisms in 5277. E.g., the create=
-subscription RPC.


If a mechanism in 5277 is not in the draft it is an unintended omissio=
n.







I agree that the complete set of features in the draft is more complex=
 than those in 5277.


Some features are explicitly stated in the charter item (e.g., multipl=
e subscriptions over a session). 


Others, like static subscription, are not mandatory in the yang with t=
he new features.


What is mandatory and what is optional is open to discussion.


A server implementation may only advertise the capabilities correspond=
ing to 5277.







On the point your bring about the authors, I am not familiar with it. =
Guidance from the chairs would be appreciated.







Thanks,







Alberto

















6. Enhance RFC 5277 with the ability to delete sub=
scriptions without 

closing the client session, to modify existing subscrip=
tions, and to 

have multiple subscriptions on a established client ses=
sion. These 

changes should not affect older clients that do not sup=
port these 

particular subscription requirements. The RPCs and the =
data models in 

RFC 5277 should be converted to YANG.














From: Andy Bierman <andy@yumaworks.com>

Date: Tuesday, March 22, 2016 at 10=
:18 PM

To: Alberto Gonzalez Prieto <albertgo@cisco.com=
>

Cc: "Eric Voit (evoit)" &=
lt;evoit@cisco.com=
>, Mahesh Jethanandani <mjethanandani@gmail.com>, NETCONF <netconf@ietf.org>

Subject: Re: [Netconf] Agenda Reque=
st













Hi,











I don't know how much agreement there is on requirements or solution.<=
/div>






IMO, this draft should not be called RFC5277bis







 - all mechanisms from RFC 5277 have been removed


 - all RFC 5277 authors have been removed







IMO, the new work should not obsolete RFC 5277, as stated in the draft=
.


The existing notifications work as intended and there are several inde=
pendent


implementations.







This new draft is radically different and much more complex to impleme=
nt on


the client and server than RFC 5277. 

















Andy












On Mon, Mar 21, 2016 at 11:49 AM, Alberto Gonzal=
ez Prieto (albertgo)
<albertgo@cisco.com> wrote:



Hello,



Our proposal for RFC5277-bis has been submitted

(https://datatracker.ietf.org/doc/dra=
ft-gonzalez-netconf-5277bis)

You can find an high-level summary of the draft below.

We would like to present it in the NETCONF session at IETF 95.



Length: 10 minutes

Presenter: Eric Voit





Thanks,



Alberto, Alex, Eric, Einar, and Ambika







This draft targets charter item #6 of the NETCONF WG.

It enhances RFC 5277, addressing limitations identified during the design
of draft-ietf-netconf-yang-push-01 and

draft-voit-netconf-restconf-yang-push-02



Goals of charter item #6, (all of them addressed in the draft):

- Ability to delete subscriptions without closing the client session.

- Ability to modify existing subscriptions.

- Ability to have multiple subscriptions on a client session.

- Do not affect older clients.

- Convert data models in RFC 5277 into YANG.



The draft also includes the following features:

- Subscription negotiation.

- Static subscriptions. (i.e., configuration-driven susbcription)

- Subscription suspension and termination by server.

- Support for multiple encodings (e.g., json).











On 3/7/16, 2:52 PM, "Netconf on behalf of Eric Voit (evoit)"

<netconf-b=
ounces@ietf.org on behalf of
evoit@cisco.com>=
; wrote:



>Hi Mahesh & Mehmet,

>

>Below are the two topics we were hoping present .

>

>Topics:

>(1) Yang Subscriptions

>  -  draft-ietf-netconf-yang-push

>       - WG draft revisions

>       - IETF hackathon demo results: yang-push int=
erworking with

>OpenDaylight

>  -  draft-voit-netconf-restconf-yang-push

>       - New draft this week: shrunk to cover just =
Restconf & HTTP

>transports

>  -  Discussion:  do we have the desired WG division for=
 these drafts?

>

>(2) RFC5277bis

>  - Proposal coming into WG before submission cut-off date

>

>Length:

>(1) Yang Subscriptions - 20 min

>(2) RFC5277bis - 10 min

>

>Presenter:

>  -  Eric Voit (on behalf of the authors)

>

>Thanks,

>Eric, Alex, Alberto, Ambika, Einar

>

>-------------------

>From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh

>Jethanandani

>Sent: Sunday, March 06, 2016 10:22 PM

>To: NETCONF

>Subject: [Netconf] Agenda Request

>

>It is that time again where we ask if you want to present in the NETCON=
F

>session at IETF 95.

>

>Please indicate

>

>Topic:

>Length:

>Presenter:

>

>in your request for the slot.

>

>All this assumes that you have published/updated a draft on the mailing=


>list and have garnered some discussion around it. If not, there is stil=
l

>time to do that before the meeting.

>

>Cheers.

>

>Mahesh & Mehmet

>

>

>

>_______________________________________________

>Netconf mailing list

>Netconf@ietf.org<=
/a>

>https://www.ietf.org/mailman/listinfo/netconf


_______________________________________________

Netconf mailing list

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







































--_000_D318F0DD6ABA5albertgociscocom_--


From nobody Wed Mar 23 18:31:17 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAD412D5E5; Wed, 23 Mar 2016 18:31:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hv9laVdj07_P; Wed, 23 Mar 2016 18:31:14 -0700 (PDT)
Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (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 31D8112DA6C; Wed, 23 Mar 2016 18:31:13 -0700 (PDT)
Received: by mail-pa0-x22b.google.com with SMTP id td3so8928671pab.2; Wed, 23 Mar 2016 18:31:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:subject:date:message-id:cc:to:mime-version; bh=4Uv6LBBqfEp3eu43w2lqMhJBWQiU8DpHOo6KTr0qA0I=; b=HhZ+zWnXUAgfXyKXVB8/EAnTngwfuR9XlWpR9sBVWjdLN/qkQjZg10bhoFuCYXHEWJ N/TNsugBT3KCgUgDrAye9GZ8L48H2EaxhqYbFWxvctfaObk/P0SCdf3dq1L3rM7GoQY5 V14bxiC/O+9pPNRj3IWo2dthoOFOMwqP/68Qj1u8qKGjYYUECEdRujTDUvetPGJjBkti YqTHqBJdl3y0gSEI18SilJctdR74J5vAnB4rZ9Fi9Qa9DRNMVUminAEmlHOlFHRqKPXf d34PGq+GteR+N6OSBxe6/CHorC6nFt605sZBb08vnKFvtTkCmjny5e1U+mVTFTYKVNt3 KvUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:message-id:cc:to:mime-version; bh=4Uv6LBBqfEp3eu43w2lqMhJBWQiU8DpHOo6KTr0qA0I=; b=krrhCL4/GPLtmsq1H0HOgwr53FFYIZOZRb14rxQ9Ymn3tTnnEayoi7TYel8KS33QB8 qVw0+SnT4xEGr+9BvMyBv3FcMU6HtTZbdlkgbwQYs4hwO0gKO4cb32smnvb9MoGAbhlX L7ERUoyRBMcTkJRHflokxO8gW/EsGBaQMMKrT0SBZ1+37YkxGyn5HOYFYMNnCa7tk4tn ysSTMXN3DZCRzd3waD2SrUNP9HvuvrKbPdxCN6R8KZybuFd5a0qKOv5gPeuS3zoOTpl0 xifilorazoUuxNk+TaoTLBtamRpscnG14rMdm32oeeyza3mtEGrPapAZYfBO/CwC+s6v EWSw==
X-Gm-Message-State: AD7BkJJ2rsF5zp1dUIXBI3cbAFbcEKuj4Y2x5bITZhlqAxrCeuVf8CsZ1pvsHoXoKViDYw==
X-Received: by 10.66.220.66 with SMTP id pu2mr8707297pac.115.1458783072589; Wed, 23 Mar 2016 18:31:12 -0700 (PDT)
Received: from ?IPv6:2001:420:c0c8:1002::1ea? ([2001:420:c0c8:1002::1ea]) by smtp.gmail.com with ESMTPSA id g28sm6873818pfd.25.2016.03.23.18.31.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 23 Mar 2016 18:31:11 -0700 (PDT)
From: Mahesh Jethanandani 
Content-Type: multipart/alternative; boundary="Apple-Mail=_9D84D05D-ECC7-4DA8-938B-95942F5B8E8B"
Date: Wed, 23 Mar 2016 18:31:07 -0700
Message-Id: <59CD0F82-FAE9-41BD-921D-0590A4378345@gmail.com>
To: draft-ietf-netconf-yang-library@ietf.org, draft-ietf-netconf-yang-patch@ietf.org, draft-ietf-netconf-restconf@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: NETCONF 
Subject: [Netconf] IPR on draft-ietf-netconf-yang-library, draft-ietf-netconf-yang-patch and draft-ietf-netconf-restconf
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Mar 2016 01:31:16 -0000

--Apple-Mail=_9D84D05D-ECC7-4DA8-938B-95942F5B8E8B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Authors, Contributors, Working Group,

In preparation of sending the above documents for consideration of an =
RFC (text generously borrowed from NETMOD WG chairs)

Are you aware of any IPR that applies to above stated drafts?

Please state:

"No, I'm not aware of any IPR that applies to these drafts"
or
"Yes, I'm aware of IPR that applies to this drafts"

If so, has this IPR been disclosed in compliance with IETF IPR rules =
(see RFCs 3979, 4879, 3669 and 5378 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think =
appropriate.

If you are listed as a document author or contributor please answer the =
above by responding to this email regardless of whether or not you are =
aware of any relevant IPR. This document will not advance to the next =
stage until a response has been received from each author and listed =
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty =
.

Mahesh & Mehmet.






--Apple-Mail=_9D84D05D-ECC7-4DA8-938B-95942F5B8E8B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Authors, Contributors, Working Group,

In preparation of sending the above =
documents for consideration of an RFC (text generously borrowed from =
NETMOD WG chairs)

Are you aware of any IPR that applies to above stated =
drafts?

Please =
state:

"No, =
I'm not aware of any IPR that applies to these drafts"
or"Yes, I'm aware of IPR that applies to this drafts"

If so, has this IPR been disclosed in =
compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 =
for more details)?

If yes to the above, =
please state either:

"Yes, the IPR has been =
disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you =
think appropriate.

If you are listed =
as a document author or contributor please answer the above by =
responding to this email regardless of whether or not you are aware =
of any relevant IPR. This document will not advance to the =
next stage until a response has been received from each author and =
listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS =
MESSAGE'S
TO LINES.

If you =
are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your =
obligations under
the IETF IPR rules which encourages you =
to notify the IETF if you are
aware of IPR of others on an =
IETF contribution, or to refrain from
participating in any =
contribution or discussion related to your
undisclosed =
IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualPro=
perty.



Mahesh & Mehmet.








=

--Apple-Mail=_9D84D05D-ECC7-4DA8-938B-95942F5B8E8B--


From nobody Wed Mar 23 23:49:29 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90CF012D53B; Wed, 23 Mar 2016 23:49:27 -0700 (PDT)
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 autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pYPOC8YP5YK; Wed, 23 Mar 2016 23:49:25 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8F19F12D1A8; Wed, 23 Mar 2016 23:49:25 -0700 (PDT)
Received: from localhost (h-53-58.a165.priv.bahnhof.se [46.59.53.58]) by mail.tail-f.com (Postfix) with ESMTPSA id B89791AE0308; Thu, 24 Mar 2016 07:49:23 +0100 (CET)
Date: Thu, 24 Mar 2016 07:49:23 +0100 (CET)
Message-Id: <20160324.074923.411071060129245423.mbj@tail-f.com>
To: mjethanandani@gmail.com
From: Martin Bjorklund 
In-Reply-To: <59CD0F82-FAE9-41BD-921D-0590A4378345@gmail.com>
References: <59CD0F82-FAE9-41BD-921D-0590A4378345@gmail.com>
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: draft-ietf-netconf-yang-patch@ietf.org, draft-ietf-netconf-yang-library@ietf.org, netconf@ietf.org, draft-ietf-netconf-restconf@ietf.org
Subject: Re: [Netconf] IPR on draft-ietf-netconf-yang-library, draft-ietf-netconf-yang-patch and draft-ietf-netconf-restconf
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Mar 2016 06:49:28 -0000

Mahesh Jethanandani  wrote:
> Authors, Contributors, Working Group,
> 
> In preparation of sending the above documents for consideration of an RFC (text generously borrowed from NETMOD WG chairs)
> 
> Are you aware of any IPR that applies to above stated drafts?

No, I'm not aware of any IPR that applies to these drafts


/martin


> 
> Please state:
> 
> "No, I'm not aware of any IPR that applies to these drafts"
> or
> "Yes, I'm aware of IPR that applies to this drafts"
> 
> If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)?
> 
> If yes to the above, please state either:
> 
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
> 
> If you answer no, please provide any additional details you think appropriate.
> 
> If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
> 
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under
> the IETF IPR rules which encourages you to notify the IETF if you are
> aware of IPR of others on an IETF contribution, or to refrain from
> participating in any contribution or discussion related to your
> undisclosed IPR. For more information, please see the RFCs listed above
> and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty .
> 
> Mahesh & Mehmet.
> 
> 
> 
> 
> 


From nobody Thu Mar 24 02:22:39 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6C012D1AD; Thu, 24 Mar 2016 02:22:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level: 
X-Spam-Status: No, score=-14.53 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVR9EM-zbhJf; Thu, 24 Mar 2016 02:22:36 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B173112D11B; Thu, 24 Mar 2016 02:22:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1780; q=dns/txt; s=iport; t=1458811356; x=1460020956; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=qbQjVqZ43qpZsP+558TX8pVucswtd6Ze0lhGn7zLHjc=; b=T3/HTsusDF+S4bF2NK+D7xIGNU2J0A3Q+wnm8JJPC30UKN9mR7UNWf/N qkwj/mPFAByft8BOWzyiXrUQItgLFqtG5fvKs/zhWPXeGW7L9I1CAfk8c uuQa+ZymtYHEpLpN/vmgCs66FkqASue77TTmEt+FZ2zpj/rtmFchl1g79 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQCLsPNW/xbLJq1eumWEbgENgXCGD?= =?us-ascii?q?QKBahQBAQEBAQEBZCeEOAoBAQR4ARALAwEKCgkWBAsJAwIBAgFFBgEMCAEBiCP?= =?us-ascii?q?BIgEBAQEBAQEBAQEBAQEBAQEBAQEBARWGHoREihIBBJdejgSJN4VUjwkeAQFCg?= =?us-ascii?q?jCBNTyKBAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.24,384,1454976000";  d="scan'208,217";a="676253767"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Mar 2016 09:22:33 +0000
Received: from [10.63.23.100] (dhcp-ensft1-uk-vla370-10-63-23-100.cisco.com [10.63.23.100]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u2O9MX28003938; Thu, 24 Mar 2016 09:22:33 GMT
To: Mahesh Jethanandani , draft-ietf-netconf-yang-library@ietf.org, draft-ietf-netconf-yang-patch@ietf.org, draft-ietf-netconf-restconf@ietf.org
References: <59CD0F82-FAE9-41BD-921D-0590A4378345@gmail.com>
From: Robert Wilton 
Message-ID: <56F3B1D9.5080107@cisco.com>
Date: Thu, 24 Mar 2016 09:22:33 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <59CD0F82-FAE9-41BD-921D-0590A4378345@gmail.com>
Content-Type: multipart/alternative; boundary="------------090000030700090700080509"
Archived-At: 
Cc: NETCONF 
Subject: Re: [Netconf] IPR on draft-ietf-netconf-yang-library, draft-ietf-netconf-yang-patch and draft-ietf-netconf-restconf
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Mar 2016 09:22:38 -0000

This is a multi-part message in MIME format.
--------------090000030700090700080509
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit



On 24/03/2016 01:31, Mahesh Jethanandani wrote:
> Authors, Contributors, Working Group,
>
> In preparation of sending the above documents for consideration of an 
> RFC (text generously borrowed from NETMOD WG chairs)
>
> Are you aware of any IPR that applies to above stated drafts?

No, I'm not aware of any IPR that applies to these drafts.

Thanks,
Rob


--------------090000030700090700080509
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    

    
On 24/03/2016 01:31, Mahesh
      Jethanandani wrote:

    

    

      
      Authors, Contributors, Working Group,
      


      

      
In preparation of sending the above documents for
        consideration of an RFC (text generously borrowed from NETMOD WG
        chairs)

      


      

      
Are you aware of any IPR that applies to above
        stated drafts?

    

    

    No, I'm not aware of any IPR that applies to these drafts.

    

    Thanks,

    Rob

    

  


--------------090000030700090700080509--


From nobody Thu Mar 24 04:29:13 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3642212D6DE; Thu, 24 Mar 2016 04:29:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfkUrlvMZe6i; Thu, 24 Mar 2016 04:29:08 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0113.outbound.protection.outlook.com [207.46.100.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C469012D198; Thu, 24 Mar 2016 04:29:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=30HRbPGxomdZoUzFxkW7FO7PRXnHLTfW325fKtu0PuA=; b=P91fCxY4J2Ds+8UxG2UnbzBUPA2ugOTOW7dfx9cuVTJMDy7at3nhbRFaVxAGB6t0jmYWwQznMoa2je5viHAAjdoiyZ3uw9HFI7wmpPzPW/Q+lztuAWhhHHFkPQNqZgBTQB3aDfihXcOTgY3vrUtqk+s1aAjQ9sNOnaa4KguPJ6s=
Received: from DM2PR0501MB1455.namprd05.prod.outlook.com (10.161.224.152) by DM2PR0501MB1456.namprd05.prod.outlook.com (10.161.224.153) with Microsoft SMTP Server (TLS) id 15.1.443.12; Thu, 24 Mar 2016 11:29:08 +0000
Received: from DM2PR0501MB1455.namprd05.prod.outlook.com ([10.161.224.152]) by DM2PR0501MB1455.namprd05.prod.outlook.com ([10.161.224.152]) with mapi id 15.01.0443.015; Thu, 24 Mar 2016 11:29:07 +0000
From: Kent Watsen 
To: Mahesh Jethanandani 
Thread-Topic: IPR on draft-ietf-netconf-yang-library, draft-ietf-netconf-yang-patch and draft-ietf-netconf-restconf
Thread-Index: AQHRhWzdtgDR4XKTFU+X+/cRLaf1aJ9odejq
Date: Thu, 24 Mar 2016 11:29:07 +0000
Message-ID: <7C70F2DB-DADD-4CF0-8369-FF012D38D0E8@juniper.net>
References: <59CD0F82-FAE9-41BD-921D-0590A4378345@gmail.com>
In-Reply-To: <59CD0F82-FAE9-41BD-921D-0590A4378345@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [199.76.14.70]
x-ms-office365-filtering-correlation-id: 938204a6-7853-47fc-d230-08d353d78391
x-microsoft-exchange-diagnostics: 1; DM2PR0501MB1456; 5:zb9V6Mdbt4dQYMILh7qY+NWtBiOWzbv5gPGSpUZR/sbB5ZtvJ0KhKjysUVyxVrpP+WmDGiECE6erEoGFSDCdfchVx4Hhh5z6r83zejEjmNknDgGxednwMLYMAGs9CqIPdzeoY28fcA/iS2Gp+BfJIw==; 24:1oDOkPWaHzKQLyb8f4RcV+p0NKCKbdfg9LYT2VVD+P3vtGD9V6WdMEhK7+pBAQXc9UUBLjZOr/qi/GbOviWDR7Hw1MD5EYXqcVWQwG8OjOY=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1456;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:DM2PR0501MB1456; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1456; 
x-forefront-prvs: 0891BC3F3D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(164054003)(24454002)(3280700002)(81166005)(4326007)(5004730100002)(54356999)(110136002)(1096002)(189998001)(66066001)(1220700001)(2906002)(92566002)(83716003)(3660700001)(76176999)(122556002)(50986999)(19617315012)(3846002)(102836003)(10400500002)(36756003)(15975445007)(106116001)(19580395003)(6116002)(19580405001)(586003)(82746002)(1411001)(2900100001)(2950100001)(230783001)(5002640100001)(33656002)(87936001)(99286002)(86362001)(77096005)(16236675004)(5008740100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1456; H:DM2PR0501MB1455.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_7C70F2DBDADD4CF08369FF012D38D0E8junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2016 11:29:07.7630 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1456
Archived-At: 
Cc: "draft-ietf-netconf-yang-patch@ietf.org" , "draft-ietf-netconf-yang-library@ietf.org" , NETCONF , "draft-ietf-netconf-restconf@ietf.org" 
Subject: Re: [Netconf] IPR on draft-ietf-netconf-yang-library, draft-ietf-netconf-yang-patch and draft-ietf-netconf-restconf
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Mar 2016 11:29:11 -0000

--_000_7C70F2DBDADD4CF08369FF012D38D0E8junipernet_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


No, I'm not aware of any IPR that applies to these drafts.

Thanks,
Kent

On Mar 23, 2016, at 9:31 PM, Mahesh Jethanandani > wrote:

Authors, Contributors, Working Group,

In preparation of sending the above documents for consideration of an RFC (=
text generously borrowed from NETMOD WG chairs)

Are you aware of any IPR that applies to above stated drafts?

Please state:

"No, I'm not aware of any IPR that applies to these drafts"
or
"Yes, I'm aware of IPR that applies to this drafts"

If so, has this IPR been disclosed in compliance with IETF IPR rules (see R=
FCs 3979, 4879, 3669 and 5378 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think appropria=
te.

If you are listed as a document author or contributor please answer the abo=
ve by responding to this email regardless of whether or not you are aware o=
f any relevant IPR. This document will not advance to the next stage until =
a response has been received from each author and listed contributor. NOTE:=
 THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Mahesh & Mehmet.






--_000_7C70F2DBDADD4CF08369FF012D38D0E8junipernet_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable












No, I'm not aware of any IPR that applies to these drafts.&nb=
sp;








Thanks,

Kent






On Mar 23, 2016, at 9:31 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:








Authors, Contributors, Working Group,






In preparation of sending the above documents for considera=
tion of an RFC (text generously borrowed from NETMOD WG chairs)







Are you aware of any IPR that applies to above stated draft=
s?







Please state:







"No, I'm not aware of any IPR that applies to these dr=
afts"

or

"Yes, I'm aware of IPR that applies to this drafts"



If so, has this IPR been disclosed in compliance with IETF IPR rules (=
see RFCs 3979, 4879, 3669 and 5378 for more details)?



If yes to the above, please state either:



"Yes, the IPR has been disclosed in compliance with IETF IPR rules&quo=
t;

or

"No, the IPR has not been disclosed"



If you answer no, please provide any additional details you think appr=
opriate.



If you are listed as a document author or contributor please answer the&nbs=
p;above by responding to this email regardless of whether or not you are&nb=
sp;aware of any relevant IPR. This document will not advance to the next&nb=
sp;stage until a response has been received from
 each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU =
LISTED IN THIS MESSAGE'S

TO LINES.



If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under

the IETF IPR rules which encourages you to notify the IETF if you are

aware of IPR of others on an IETF contribution, or to refrain from

participating in any contribution or discussion related to your

undisclosed IPR. For more information, please see the RFCs listed above

and

http://trac.tools.ietf.org/group/iesg/trac/wiki/Intellectu=
alProperty.











Mahesh & Mehmet.





























--_000_7C70F2DBDADD4CF08369FF012D38D0E8junipernet_--


From nobody Thu Mar 24 04:44:09 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A676912DA9E for ; Thu, 24 Mar 2016 04:44:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFIZvgm0Crbm for ; Thu, 24 Mar 2016 04:44:06 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 191A612DA99 for ; Thu, 24 Mar 2016 04:44:06 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 67FC21CC035D; Thu, 24 Mar 2016 12:44:04 +0100 (CET)
From: Ladislav Lhotka 
To: Martin Bjorklund 
In-Reply-To: <20160323.215544.166438758609320904.mbj@tail-f.com>
References:    <20160323.215544.166438758609320904.mbj@tail-f.com>
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Thu, 24 Mar 2016 12:44:03 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] RESTCONF examples
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Mar 2016 11:44:08 -0000

Martin Bjorklund  writes:

> Ladislav Lhotka  wrote:
>> Andy Bierman  writes:
>> 
>> > On Tue, Mar 22, 2016 at 7:26 AM, Ladislav Lhotka  wrote:
>> >
>> >> Andy Bierman  writes:
>> >>
>> >> > On Tue, Mar 22, 2016 at 6:10 AM, Ladislav Lhotka  wrote:
>> >> >
>> >> >> Hi,
>> >> >>
>> >> >> I checked the book RESTful Web Services by Richardson & Ruby, and they
>> >> >> illustrate a recommended design of resources with the following example:
>> >> >>
>> >> >> | Operation      | HTTP action      |
>> >> >> |----------------+------------------|
>> >> >> | List the users | GET /users       |
>> >> >> | Create a user  | POST /users      |
>> >> >> | View a user    | GET /users/52    |
>> >> >> | Modify a user  | PUT /users/52    |
>> >> >> | Delete a user  | DELETE /users/52 |
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> >> I think RESTCONF should follow the same pattern because this is what
>> >> >> developers are used to. The logic of some examples in the RESTCONF spec
>> >> >> - namely what's a resource and what's its value - isn't very clear to
>> >> >> me.
>> >> >>
>> >> >
>> >> >
>> >> > This is what we have except lists are encoded in 1 segment instead
>> >> > of list key values in their own segment.
>> >> >
>> >> > Please provide OLD and NEW text fragments that you think need to be
>> >> > changed
>> >>
>> >> I did it already, without the OLD and NEW labels, so here it is again:
>> >>
>> >> ---------------------------------------------------------------------
>> >> OLD
>> >>
>> >>       POST /restconf/data/example-jukebox:jukebox/
>> >>           playlist=Foo-One?insert=first HTTP/1.1
>> >>       Host: example.com
>> >>       Content-Type: application/yang.data+json
>> >>
>> >>       {
>> >>         "example-jukebox:song" : {
>> >>            "index" : 1,
>> >>            "id" : "/example-jukebox:jukebox/library/
>> >>                artist=Foo%20Fighters/album=Wasting%20Light/song=Rope"
>> >>          }
>> >>       }
>> >>
>> >> NEW
>> >>
>> >>       POST /restconf/data/example-jukebox:jukebox/
>> >>           playlist=Foo-One/song?insert=first HTTP/1.1
>> >>       Host: example.com
>> >>       Content-Type: application/yang.data+json
>> >>
>> >>       {
>> >>         "index" : 1,
>> >>         "id" : "/example-jukebox:jukebox/library/
>> >>           artist=Foo%20Fighters/album=Wasting%20Light/song=Rope"
>> >>       }
>> >> ---------------------------------------------------------------------
>> >>
>> >> If we agree that this example adds an entry to the "song" list, then IMO
>> >> "song" needs to appear in the Request-URI.
>> >>
>> >>
>> >
>> > This is not how RESTCONF has been defined from the start.
>> 
>> Let's see. The Request-URI in the OLD version is
>> 
>> /restconf/data/example-jukebox:jukebox/playlist=Foo-One?insert=first
>> 
>> According to sec. 1.1.4, the target resource is the "Foo-One" entry of
>> the "playlist" list. Correct?
>> 
>> Then sec. 4.8.4 says:
>> 
>>    [The "insert" query parameter] is also only supported if the target
>>    resource is a data resource, and that data represents a YANG list or
>>    leaf-list that is ordered by the user.
>> 
>> To me, this means that the example is incorrect because the target
>> resource is *not* a list ordered-by user.
>
> I think the quoted text is wrong.  For PUT, "insert" is only valid
> if the target resource is an obu list.  For POST, "insert" is only
> valid if the child resource is an obu list.

Yes, the POST part explains the example. An alternative would be to keep
the text and update the example(s), as I suggested.

I am also wondering about the use of "insert" with PUT - it seems to
violate the HTTP spec. RFC 7231: "The PUT method requests that the state
of the target resource be created or replaced with the state defined by
the representation enclosed in the request message payload." This IMO
means that PUT should be used only for creating/replacing a whole list
or leaf-list.

Also, RFC 7231 states that PUT is idempotent, but is it satisfied in our
case? What happens if the same PUT request with the "insert" query
parameter is used twice?

Lada

>
>
> /martin

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


From nobody Thu Mar 24 06:27:22 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6E312D1C9 for ; Thu, 24 Mar 2016 06:27:21 -0700 (PDT)
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 autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fIBI3HvqZHk for ; Thu, 24 Mar 2016 06:27:20 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C764312D14F for ; Thu, 24 Mar 2016 06:27:19 -0700 (PDT)
Received: from localhost (h-53-58.a165.priv.bahnhof.se [46.59.53.58]) by mail.tail-f.com (Postfix) with ESMTPSA id 370B91AE035B; Thu, 24 Mar 2016 14:27:18 +0100 (CET)
Date: Thu, 24 Mar 2016 14:27:17 +0100 (CET)
Message-Id: <20160324.142717.1147677482681127155.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References:  <20160323.215544.166438758609320904.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=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] RESTCONF examples
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Mar 2016 13:27:21 -0000

Ladislav Lhotka  wrote:
> Martin Bjorklund  writes:
> 
> > Ladislav Lhotka  wrote:
> >> Andy Bierman  writes:
> >> 
> >> > On Tue, Mar 22, 2016 at 7:26 AM, Ladislav Lhotka  wrote:
> >> >
> >> >> Andy Bierman  writes:
> >> >>
> >> >> > On Tue, Mar 22, 2016 at 6:10 AM, Ladislav Lhotka  wrote:
> >> >> >
> >> >> >> Hi,
> >> >> >>
> >> >> >> I checked the book RESTful Web Services by Richardson & Ruby, and they
> >> >> >> illustrate a recommended design of resources with the following example:
> >> >> >>
> >> >> >> | Operation      | HTTP action      |
> >> >> >> |----------------+------------------|
> >> >> >> | List the users | GET /users       |
> >> >> >> | Create a user  | POST /users      |
> >> >> >> | View a user    | GET /users/52    |
> >> >> >> | Modify a user  | PUT /users/52    |
> >> >> >> | Delete a user  | DELETE /users/52 |
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> >> I think RESTCONF should follow the same pattern because this is what
> >> >> >> developers are used to. The logic of some examples in the RESTCONF spec
> >> >> >> - namely what's a resource and what's its value - isn't very clear to
> >> >> >> me.
> >> >> >>
> >> >> >
> >> >> >
> >> >> > This is what we have except lists are encoded in 1 segment instead
> >> >> > of list key values in their own segment.
> >> >> >
> >> >> > Please provide OLD and NEW text fragments that you think need to be
> >> >> > changed
> >> >>
> >> >> I did it already, without the OLD and NEW labels, so here it is again:
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> OLD
> >> >>
> >> >>       POST /restconf/data/example-jukebox:jukebox/
> >> >>           playlist=Foo-One?insert=first HTTP/1.1
> >> >>       Host: example.com
> >> >>       Content-Type: application/yang.data+json
> >> >>
> >> >>       {
> >> >>         "example-jukebox:song" : {
> >> >>            "index" : 1,
> >> >>            "id" : "/example-jukebox:jukebox/library/
> >> >>                artist=Foo%20Fighters/album=Wasting%20Light/song=Rope"
> >> >>          }
> >> >>       }
> >> >>
> >> >> NEW
> >> >>
> >> >>       POST /restconf/data/example-jukebox:jukebox/
> >> >>           playlist=Foo-One/song?insert=first HTTP/1.1
> >> >>       Host: example.com
> >> >>       Content-Type: application/yang.data+json
> >> >>
> >> >>       {
> >> >>         "index" : 1,
> >> >>         "id" : "/example-jukebox:jukebox/library/
> >> >>           artist=Foo%20Fighters/album=Wasting%20Light/song=Rope"
> >> >>       }
> >> >> ---------------------------------------------------------------------
> >> >>
> >> >> If we agree that this example adds an entry to the "song" list, then IMO
> >> >> "song" needs to appear in the Request-URI.
> >> >>
> >> >>
> >> >
> >> > This is not how RESTCONF has been defined from the start.
> >> 
> >> Let's see. The Request-URI in the OLD version is
> >> 
> >> /restconf/data/example-jukebox:jukebox/playlist=Foo-One?insert=first
> >> 
> >> According to sec. 1.1.4, the target resource is the "Foo-One" entry of
> >> the "playlist" list. Correct?
> >> 
> >> Then sec. 4.8.4 says:
> >> 
> >>    [The "insert" query parameter] is also only supported if the target
> >>    resource is a data resource, and that data represents a YANG list or
> >>    leaf-list that is ordered by the user.
> >> 
> >> To me, this means that the example is incorrect because the target
> >> resource is *not* a list ordered-by user.
> >
> > I think the quoted text is wrong.  For PUT, "insert" is only valid
> > if the target resource is an obu list.  For POST, "insert" is only
> > valid if the child resource is an obu list.
> 
> Yes, the POST part explains the example. An alternative would be to keep
> the text and update the example(s), as I suggested.

You cannot just update the example.  We'd have to rework lots of text,
e.g. we'd no longer map yang data node instances to resources; we'd
have to come up with an encoding for the result of doing GET on such a
URI.

> I am also wondering about the use of "insert" with PUT - it seems to
> violate the HTTP spec. RFC 7231: "The PUT method requests that the state
> of the target resource be created or replaced with the state defined by
> the representation enclosed in the request message payload." This IMO
> means that PUT should be used only for creating/replacing a whole list
> or leaf-list.

There is no resource for the "entire list".  Each list entry is its
own resource.

> Also, RFC 7231 states that PUT is idempotent, but is it satisfied in our
> case? What happens if the same PUT request with the "insert" query
> parameter is used twice?

I think it should be ok.


/martin


From nobody Thu Mar 24 07:16:11 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F048212DB4E for ; Thu, 24 Mar 2016 07:16:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level: 
X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yR3U9Wzjp39b for ; Thu, 24 Mar 2016 07:16:08 -0700 (PDT)
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 EB79E12DB97 for ; Thu, 24 Mar 2016 07:07:59 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:45db:ad9a:f9e0:d864] (unknown [IPv6:2001:718:1a02:1:45db:ad9a:f9e0:d864]) by mail.nic.cz (Postfix) with ESMTPSA id 9C170186A65; Thu, 24 Mar 2016 15:07:58 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1458828478; bh=LuD2leukdx9MYyl8rowbd+DHdo9FekVJQltVwqbgPXc=; h=From:Date:To; b=iLaJTDjrYhrmDVoFWlcLxcRANCeGfEV+MHMAKS+U21prO+w06XsYGicPXpVsI6KVz MsVITzvnwsV1afUYPAPqtErAF3We9InJ0DKoxEumScI6JLda//4tuOkQZPxQ5QLQxV egZ10RQwHhHjmWiuOiyWnOcFQ4yZIR+zMXNA+nc0=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <20160324.142717.1147677482681127155.mbj@tail-f.com>
Date: Thu, 24 Mar 2016 15:07:59 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8CCC0BE3-73CB-4B98-843E-13878567E999@nic.cz>
References:  <20160323.215544.166438758609320904.mbj@tail-f.com>  <20160324.142717.1147677482681127155.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] RESTCONF examples
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Mar 2016 14:16:11 -0000

> On 24 Mar 2016, at 14:27, Martin Bjorklund  wrote:
>=20
> Ladislav Lhotka  wrote:
>> Martin Bjorklund  writes:
>>=20
>>> Ladislav Lhotka  wrote:
>>>> Andy Bierman  writes:
>>>>=20
>>>>> On Tue, Mar 22, 2016 at 7:26 AM, Ladislav Lhotka  =
wrote:
>>>>>=20
>>>>>> Andy Bierman  writes:
>>>>>>=20
>>>>>>> On Tue, Mar 22, 2016 at 6:10 AM, Ladislav Lhotka  =
wrote:
>>>>>>>=20
>>>>>>>> Hi,
>>>>>>>>=20
>>>>>>>> I checked the book RESTful Web Services by Richardson & Ruby, =
and they
>>>>>>>> illustrate a recommended design of resources with the following =
example:
>>>>>>>>=20
>>>>>>>> | Operation      | HTTP action      |
>>>>>>>> |----------------+------------------|
>>>>>>>> | List the users | GET /users       |
>>>>>>>> | Create a user  | POST /users      |
>>>>>>>> | View a user    | GET /users/52    |
>>>>>>>> | Modify a user  | PUT /users/52    |
>>>>>>>> | Delete a user  | DELETE /users/52 |
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>> I think RESTCONF should follow the same pattern because this is =
what
>>>>>>>> developers are used to. The logic of some examples in the =
RESTCONF spec
>>>>>>>> - namely what's a resource and what's its value - isn't very =
clear to
>>>>>>>> me.
>>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> This is what we have except lists are encoded in 1 segment =
instead
>>>>>>> of list key values in their own segment.
>>>>>>>=20
>>>>>>> Please provide OLD and NEW text fragments that you think need to =
be
>>>>>>> changed
>>>>>>=20
>>>>>> I did it already, without the OLD and NEW labels, so here it is =
again:
>>>>>>=20
>>>>>> =
---------------------------------------------------------------------
>>>>>> OLD
>>>>>>=20
>>>>>>      POST /restconf/data/example-jukebox:jukebox/
>>>>>>          playlist=3DFoo-One?insert=3Dfirst HTTP/1.1
>>>>>>      Host: example.com
>>>>>>      Content-Type: application/yang.data+json
>>>>>>=20
>>>>>>      {
>>>>>>        "example-jukebox:song" : {
>>>>>>           "index" : 1,
>>>>>>           "id" : "/example-jukebox:jukebox/library/
>>>>>>               =
artist=3DFoo%20Fighters/album=3DWasting%20Light/song=3DRope"
>>>>>>         }
>>>>>>      }
>>>>>>=20
>>>>>> NEW
>>>>>>=20
>>>>>>      POST /restconf/data/example-jukebox:jukebox/
>>>>>>          playlist=3DFoo-One/song?insert=3Dfirst HTTP/1.1
>>>>>>      Host: example.com
>>>>>>      Content-Type: application/yang.data+json
>>>>>>=20
>>>>>>      {
>>>>>>        "index" : 1,
>>>>>>        "id" : "/example-jukebox:jukebox/library/
>>>>>>          artist=3DFoo%20Fighters/album=3DWasting%20Light/song=3DRop=
e"
>>>>>>      }
>>>>>> =
---------------------------------------------------------------------
>>>>>>=20
>>>>>> If we agree that this example adds an entry to the "song" list, =
then IMO
>>>>>> "song" needs to appear in the Request-URI.
>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>> This is not how RESTCONF has been defined from the start.
>>>>=20
>>>> Let's see. The Request-URI in the OLD version is
>>>>=20
>>>> =
/restconf/data/example-jukebox:jukebox/playlist=3DFoo-One?insert=3Dfirst
>>>>=20
>>>> According to sec. 1.1.4, the target resource is the "Foo-One" entry =
of
>>>> the "playlist" list. Correct?
>>>>=20
>>>> Then sec. 4.8.4 says:
>>>>=20
>>>>   [The "insert" query parameter] is also only supported if the =
target
>>>>   resource is a data resource, and that data represents a YANG list =
or
>>>>   leaf-list that is ordered by the user.
>>>>=20
>>>> To me, this means that the example is incorrect because the target
>>>> resource is *not* a list ordered-by user.
>>>=20
>>> I think the quoted text is wrong.  For PUT, "insert" is only valid
>>> if the target resource is an obu list.  For POST, "insert" is only
>>> valid if the child resource is an obu list.
>>=20
>> Yes, the POST part explains the example. An alternative would be to =
keep
>> the text and update the example(s), as I suggested.
>=20
> You cannot just update the example.  We'd have to rework lots of text,
> e.g. we'd no longer map yang data node instances to resources; we'd
> have to come up with an encoding for the result of doing GET on such a
> URI.

OK. This is easy to do for JSON encoding but I agree XML encoding would =
need some extra containers or something.

>=20
>> I am also wondering about the use of "insert" with PUT - it seems to
>> violate the HTTP spec. RFC 7231: "The PUT method requests that the =
state
>> of the target resource be created or replaced with the state defined =
by
>> the representation enclosed in the request message payload." This IMO
>> means that PUT should be used only for creating/replacing a whole =
list
>> or leaf-list.
>=20
> There is no resource for the "entire list".  Each list entry is its
> own resource.

Your new text says otherwise: 'For PUT, "insert" is only valid if the =
target resource is an obu list.' If it is so, then the semantics of PUT =
require that the content of the target resource be replaced with the =
payload. RESTCONF's PUT with "insert" modifies the target resource, and =
such tasks should IMO be done with POST. Let's see if APPS folks have =
any comments during the IETF LC.

>=20
>> Also, RFC 7231 states that PUT is idempotent, but is it satisfied in =
our
>> case? What happens if the same PUT request with the "insert" query
>> parameter is used twice?
>=20
> I think it should be ok.

Do you mean that the second PUT should be silently ignored? Is it what =
existing implementations do?

Lada

>=20
>=20
> /martin

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





From nobody Thu Mar 24 07:41:43 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E1012DD48 for ; Thu, 24 Mar 2016 07:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level: 
X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Guf-GL-ADVeQ for ; Thu, 24 Mar 2016 07:41:36 -0700 (PDT)
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 50A8112DD2E for ; Thu, 24 Mar 2016 07:29:01 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:4957:2cf2:d267:16a] (unknown [IPv6:2001:718:1a02:1:4957:2cf2:d267:16a]) by mail.nic.cz (Postfix) with ESMTPSA id 059321830EA for ; Thu, 24 Mar 2016 15:29:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1458829740; bh=+Run/je+9CEiW92b0nJcVXlPDC92Kc7oj+RlQcxQMHk=; h=To:From:Date; b=QutbmXBsDLisnwNna1F+8Ort8EfBtNLrNDuBUDiRTN+s2PHhpdk6ECYw7Sy+dlJRO Vj2mWuZttxrzTO/vDQqOksn1HajG/tPzhtvWQXoHBMfOyLepWSwXJ5AvLa2P9W8NQF oGpZ0e0nGoGFPqWRBOYPJj9Y12Wh+/A0ST28af/s=
To: netconf@ietf.org
References:  <20160323.215544.166438758609320904.mbj@tail-f.com>  <20160324.142717.1147677482681127155.mbj@tail-f.com>
From: =?UTF-8?B?UGF2ZWwgxaBww61yZWs=?= 
Message-ID: <56F3F92B.1020305@nic.cz>
Date: Thu, 24 Mar 2016 15:26:51 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <20160324.142717.1147677482681127155.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [Netconf] RESTCONF examples
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Mar 2016 14:41:42 -0000

Dne 24.3.2016 v 14:27 Martin Bjorklund napsal(a):
> Ladislav Lhotka  wrote:
>> Martin Bjorklund  writes:
>>
>>> Ladislav Lhotka  wrote:
>>>> Andy Bierman  writes:
>>>>
>>>>> On Tue, Mar 22, 2016 at 7:26 AM, Ladislav Lhotka  wrote:
>>>>>
>>>>>> Andy Bierman  writes:
>>>>>>
>>>>>>> On Tue, Mar 22, 2016 at 6:10 AM, Ladislav Lhotka  wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I checked the book RESTful Web Services by Richardson & Ruby, and they
>>>>>>>> illustrate a recommended design of resources with the following example:
>>>>>>>>
>>>>>>>> | Operation      | HTTP action      |
>>>>>>>> |----------------+------------------|
>>>>>>>> | List the users | GET /users       |
>>>>>>>> | Create a user  | POST /users      |
>>>>>>>> | View a user    | GET /users/52    |
>>>>>>>> | Modify a user  | PUT /users/52    |
>>>>>>>> | Delete a user  | DELETE /users/52 |
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> I think RESTCONF should follow the same pattern because this is what
>>>>>>>> developers are used to. The logic of some examples in the RESTCONF spec
>>>>>>>> - namely what's a resource and what's its value - isn't very clear to
>>>>>>>> me.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This is what we have except lists are encoded in 1 segment instead
>>>>>>> of list key values in their own segment.
>>>>>>>
>>>>>>> Please provide OLD and NEW text fragments that you think need to be
>>>>>>> changed
>>>>>>
>>>>>> I did it already, without the OLD and NEW labels, so here it is again:
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> OLD
>>>>>>
>>>>>>        POST /restconf/data/example-jukebox:jukebox/
>>>>>>            playlist=Foo-One?insert=first HTTP/1.1
>>>>>>        Host: example.com
>>>>>>        Content-Type: application/yang.data+json
>>>>>>
>>>>>>        {
>>>>>>          "example-jukebox:song" : {
>>>>>>             "index" : 1,
>>>>>>             "id" : "/example-jukebox:jukebox/library/
>>>>>>                 artist=Foo%20Fighters/album=Wasting%20Light/song=Rope"
>>>>>>           }
>>>>>>        }
>>>>>>
>>>>>> NEW
>>>>>>
>>>>>>        POST /restconf/data/example-jukebox:jukebox/
>>>>>>            playlist=Foo-One/song?insert=first HTTP/1.1
>>>>>>        Host: example.com
>>>>>>        Content-Type: application/yang.data+json
>>>>>>
>>>>>>        {
>>>>>>          "index" : 1,
>>>>>>          "id" : "/example-jukebox:jukebox/library/
>>>>>>            artist=Foo%20Fighters/album=Wasting%20Light/song=Rope"
>>>>>>        }
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> If we agree that this example adds an entry to the "song" list, then IMO
>>>>>> "song" needs to appear in the Request-URI.
>>>>>>
>>>>>>
>>>>>
>>>>> This is not how RESTCONF has been defined from the start.
>>>>
>>>> Let's see. The Request-URI in the OLD version is
>>>>
>>>> /restconf/data/example-jukebox:jukebox/playlist=Foo-One?insert=first
>>>>
>>>> According to sec. 1.1.4, the target resource is the "Foo-One" entry of
>>>> the "playlist" list. Correct?
>>>>
>>>> Then sec. 4.8.4 says:
>>>>
>>>>     [The "insert" query parameter] is also only supported if the target
>>>>     resource is a data resource, and that data represents a YANG list or
>>>>     leaf-list that is ordered by the user.
>>>>
>>>> To me, this means that the example is incorrect because the target
>>>> resource is *not* a list ordered-by user.
>>>
>>> I think the quoted text is wrong.  For PUT, "insert" is only valid
>>> if the target resource is an obu list.  For POST, "insert" is only
>>> valid if the child resource is an obu list.
>>
>> Yes, the POST part explains the example. An alternative would be to keep
>> the text and update the example(s), as I suggested.
>
> You cannot just update the example.  We'd have to rework lots of text,
> e.g. we'd no longer map yang data node instances to resources; we'd
> have to come up with an encoding for the result of doing GET on such a
> URI.
>
>> I am also wondering about the use of "insert" with PUT - it seems to
>> violate the HTTP spec. RFC 7231: "The PUT method requests that the state
>> of the target resource be created or replaced with the state defined by
>> the representation enclosed in the request message payload." This IMO
>> means that PUT should be used only for creating/replacing a whole list
>> or leaf-list.
>
> There is no resource for the "entire list".  Each list entry is its
> own resource.

So if I understand correctly, it's not possible to retrieve an entire 
list with single GET request? As we are discussing the "jukebox" 
example, I can easily imagine that a user would like to retrieve all 
songs in particular playlist. It's really ineffective to retrieve them 
one by one, because playlist can contain thousands of songs. In this 
case, is the only way to request the parent "playlist" entry and 
manually separate the unneeded fluff like "name" and "description" leaves?

>
>> Also, RFC 7231 states that PUT is idempotent, but is it satisfied in our
>> case? What happens if the same PUT request with the "insert" query
>> parameter is used twice?
>
> I think it should be ok.
>
>
> /martin
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>


From nobody Thu Mar 24 07:57:43 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF9B12DD44 for ; Thu, 24 Mar 2016 07:57:41 -0700 (PDT)
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 autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JwVYvCTdYUJ for ; Thu, 24 Mar 2016 07:57:39 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7738812DDE4 for ; Thu, 24 Mar 2016 07:44:49 -0700 (PDT)
Received: from localhost (h-53-58.a165.priv.bahnhof.se [46.59.53.58]) by mail.tail-f.com (Postfix) with ESMTPSA id 4D5471AE0308; Thu, 24 Mar 2016 15:44:48 +0100 (CET)
Date: Thu, 24 Mar 2016 15:44:47 +0100 (CET)
Message-Id: <20160324.154447.1684158898406097169.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <8CCC0BE3-73CB-4B98-843E-13878567E999@nic.cz>
References:  <20160324.142717.1147677482681127155.mbj@tail-f.com> <8CCC0BE3-73CB-4B98-843E-13878567E999@nic.cz>
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 examples
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Mar 2016 14:57:41 -0000

Ladislav Lhotka  wrote:
> 
> > On 24 Mar 2016, at 14:27, Martin Bjorklund  wrote:
> > 
> > Ladislav Lhotka  wrote:
> >> Martin Bjorklund  writes:
> >> 
> >>> Ladislav Lhotka  wrote:
> >>>> Andy Bierman  writes:
> >>>> 
> >>>>> On Tue, Mar 22, 2016 at 7:26 AM, Ladislav Lhotka 
> >>>>> wrote:
> >>>>> 
> >>>>>> Andy Bierman  writes:
> >>>>>> 
> >>>>>>> On Tue, Mar 22, 2016 at 6:10 AM, Ladislav Lhotka 
> >>>>>>> wrote:
> >>>>>>> 
> >>>>>>>> Hi,
> >>>>>>>> 
> >>>>>>>> I checked the book RESTful Web Services by Richardson & Ruby, and they
> >>>>>>>> illustrate a recommended design of resources with the following
> >>>>>>>> example:
> >>>>>>>> 
> >>>>>>>> | Operation      | HTTP action      |
> >>>>>>>> |----------------+------------------|
> >>>>>>>> | List the users | GET /users       |
> >>>>>>>> | Create a user  | POST /users      |
> >>>>>>>> | View a user    | GET /users/52    |
> >>>>>>>> | Modify a user  | PUT /users/52    |
> >>>>>>>> | Delete a user  | DELETE /users/52 |
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>> 
> >>>>>>> 
> >>>>>>> 
> >>>>>>>> I think RESTCONF should follow the same pattern because this is what
> >>>>>>>> developers are used to. The logic of some examples in the RESTCONF
> >>>>>>>> spec
> >>>>>>>> - namely what's a resource and what's its value - isn't very clear to
> >>>>>>>> me.
> >>>>>>>> 
> >>>>>>> 
> >>>>>>> 
> >>>>>>> This is what we have except lists are encoded in 1 segment instead
> >>>>>>> of list key values in their own segment.
> >>>>>>> 
> >>>>>>> Please provide OLD and NEW text fragments that you think need to be
> >>>>>>> changed
> >>>>>> 
> >>>>>> I did it already, without the OLD and NEW labels, so here it is again:
> >>>>>> 
> >>>>>> ---------------------------------------------------------------------
> >>>>>> OLD
> >>>>>> 
> >>>>>>      POST /restconf/data/example-jukebox:jukebox/
> >>>>>>          playlist=Foo-One?insert=first HTTP/1.1
> >>>>>>      Host: example.com
> >>>>>>      Content-Type: application/yang.data+json
> >>>>>> 
> >>>>>>      {
> >>>>>>        "example-jukebox:song" : {
> >>>>>>           "index" : 1,
> >>>>>>           "id" : "/example-jukebox:jukebox/library/
> >>>>>>               artist=Foo%20Fighters/album=Wasting%20Light/song=Rope"
> >>>>>>         }
> >>>>>>      }
> >>>>>> 
> >>>>>> NEW
> >>>>>> 
> >>>>>>      POST /restconf/data/example-jukebox:jukebox/
> >>>>>>          playlist=Foo-One/song?insert=first HTTP/1.1
> >>>>>>      Host: example.com
> >>>>>>      Content-Type: application/yang.data+json
> >>>>>> 
> >>>>>>      {
> >>>>>>        "index" : 1,
> >>>>>>        "id" : "/example-jukebox:jukebox/library/
> >>>>>>          artist=Foo%20Fighters/album=Wasting%20Light/song=Rope"
> >>>>>>      }
> >>>>>> ---------------------------------------------------------------------
> >>>>>> 
> >>>>>> If we agree that this example adds an entry to the "song" list, then
> >>>>>> IMO
> >>>>>> "song" needs to appear in the Request-URI.
> >>>>>> 
> >>>>>> 
> >>>>> 
> >>>>> This is not how RESTCONF has been defined from the start.
> >>>> 
> >>>> Let's see. The Request-URI in the OLD version is
> >>>> 
> >>>> /restconf/data/example-jukebox:jukebox/playlist=Foo-One?insert=first
> >>>> 
> >>>> According to sec. 1.1.4, the target resource is the "Foo-One" entry of
> >>>> the "playlist" list. Correct?
> >>>> 
> >>>> Then sec. 4.8.4 says:
> >>>> 
> >>>>   [The "insert" query parameter] is also only supported if the target
> >>>>   resource is a data resource, and that data represents a YANG list or
> >>>>   leaf-list that is ordered by the user.
> >>>> 
> >>>> To me, this means that the example is incorrect because the target
> >>>> resource is *not* a list ordered-by user.
> >>> 
> >>> I think the quoted text is wrong.  For PUT, "insert" is only valid
> >>> if the target resource is an obu list.  For POST, "insert" is only
> >>> valid if the child resource is an obu list.
> >> 
> >> Yes, the POST part explains the example. An alternative would be to
> >> keep
> >> the text and update the example(s), as I suggested.
> > 
> > You cannot just update the example.  We'd have to rework lots of text,
> > e.g. we'd no longer map yang data node instances to resources; we'd
> > have to come up with an encoding for the result of doing GET on such a
> > URI.
> 
> OK. This is easy to do for JSON encoding but I agree XML encoding
> would need some extra containers or something.
> 
> > 
> >> I am also wondering about the use of "insert" with PUT - it seems to
> >> violate the HTTP spec. RFC 7231: "The PUT method requests that the
> >> state
> >> of the target resource be created or replaced with the state defined
> >> by
> >> the representation enclosed in the request message payload." This IMO
> >> means that PUT should be used only for creating/replacing a whole list
> >> or leaf-list.
> > 
> > There is no resource for the "entire list".  Each list entry is its
> > own resource.
> 
> Your new text says otherwise: 'For PUT, "insert" is only valid if the
> target resource is an obu list.'

s/list/list entry/

> If it is so, then the semantics of
> PUT require that the content of the target resource be replaced with
> the payload. RESTCONF's PUT with "insert" modifies the target
> resource, and such tasks should IMO be done with POST. Let's see if
> APPS folks have any comments during the IETF LC.
> 
> > 
> >> Also, RFC 7231 states that PUT is idempotent, but is it satisfied in
> >> our
> >> case? What happens if the same PUT request with the "insert" query
> >> parameter is used twice?
> > 
> > I think it should be ok.
> 
> Do you mean that the second PUT should be silently ignored? Is it what
> existing implementations do?

The second PUT replaces the existing one (with exactly the same data).


/martin


> 
> Lada
> 
> > 
> > 
> > /martin
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 


From nobody Thu Mar 24 08:01:25 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1033E12DBC4 for ; Thu, 24 Mar 2016 08:01:23 -0700 (PDT)
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 autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTWv6iIbYwEo for ; Thu, 24 Mar 2016 08:01:20 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D13BB12DE01 for ; Thu, 24 Mar 2016 07:48:21 -0700 (PDT)
Received: from localhost (h-53-58.a165.priv.bahnhof.se [46.59.53.58]) by mail.tail-f.com (Postfix) with ESMTPSA id 1B8E71AE0308; Thu, 24 Mar 2016 15:48:21 +0100 (CET)
Date: Thu, 24 Mar 2016 15:48:20 +0100 (CET)
Message-Id: <20160324.154820.541392410297371914.mbj@tail-f.com>
To: pavel.spirek@nic.cz
From: Martin Bjorklund 
In-Reply-To: <56F3F92B.1020305@nic.cz>
References:  <20160324.142717.1147677482681127155.mbj@tail-f.com> <56F3F92B.1020305@nic.cz>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] RESTCONF examples
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Mar 2016 15:01:24 -0000

Pavel =A6p=EDrek  wrote:
> =

> =

> Dne 24.3.2016 v 14:27 Martin Bjorklund napsal(a):
> > Ladislav Lhotka  wrote:
> >> Martin Bjorklund  writes:
> >>
> >>> Ladislav Lhotka  wrote:
> >>>> Andy Bierman  writes:
> >>>>
> >>>>> On Tue, Mar 22, 2016 at 7:26 AM, Ladislav Lhotka 
> >>>>> wrote:
> >>>>>
> >>>>>> Andy Bierman  writes:
> >>>>>>
> >>>>>>> On Tue, Mar 22, 2016 at 6:10 AM, Ladislav Lhotka 
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> I checked the book RESTful Web Services by Richardson & Ruby=
, and they
> >>>>>>>> illustrate a recommended design of resources with the follow=
ing
> >>>>>>>> example:
> >>>>>>>>
> >>>>>>>> | Operation      | HTTP action      |
> >>>>>>>> |----------------+------------------|
> >>>>>>>> | List the users | GET /users       |
> >>>>>>>> | Create a user  | POST /users      |
> >>>>>>>> | View a user    | GET /users/52    |
> >>>>>>>> | Modify a user  | PUT /users/52    |
> >>>>>>>> | Delete a user  | DELETE /users/52 |
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> I think RESTCONF should follow the same pattern because this=
 is what
> >>>>>>>> developers are used to. The logic of some examples in the RE=
STCONF
> >>>>>>>> spec
> >>>>>>>> - namely what's a resource and what's its value - isn't very=
 clear to
> >>>>>>>> me.
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> This is what we have except lists are encoded in 1 segment in=
stead
> >>>>>>> of list key values in their own segment.
> >>>>>>>
> >>>>>>> Please provide OLD and NEW text fragments that you think need=
 to be
> >>>>>>> changed
> >>>>>>
> >>>>>> I did it already, without the OLD and NEW labels, so here it i=
s again:
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------=

> >>>>>> OLD
> >>>>>>
> >>>>>>        POST /restconf/data/example-jukebox:jukebox/
> >>>>>>            playlist=3DFoo-One?insert=3Dfirst HTTP/1.1
> >>>>>>        Host: example.com
> >>>>>>        Content-Type: application/yang.data+json
> >>>>>>
> >>>>>>        {
> >>>>>>          "example-jukebox:song" : {
> >>>>>>             "index" : 1,
> >>>>>>             "id" : "/example-jukebox:jukebox/library/
> >>>>>>                 artist=3DFoo%20Fighters/album=3DWasting%20Ligh=
t/song=3DRope"
> >>>>>>           }
> >>>>>>        }
> >>>>>>
> >>>>>> NEW
> >>>>>>
> >>>>>>        POST /restconf/data/example-jukebox:jukebox/
> >>>>>>            playlist=3DFoo-One/song?insert=3Dfirst HTTP/1.1
> >>>>>>        Host: example.com
> >>>>>>        Content-Type: application/yang.data+json
> >>>>>>
> >>>>>>        {
> >>>>>>          "index" : 1,
> >>>>>>          "id" : "/example-jukebox:jukebox/library/
> >>>>>>            artist=3DFoo%20Fighters/album=3DWasting%20Light/son=
g=3DRope"
> >>>>>>        }
> >>>>>> --------------------------------------------------------------=
-------
> >>>>>>
> >>>>>> If we agree that this example adds an entry to the "song" list=
, then
> >>>>>> IMO
> >>>>>> "song" needs to appear in the Request-URI.
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> This is not how RESTCONF has been defined from the start.
> >>>>
> >>>> Let's see. The Request-URI in the OLD version is
> >>>>
> >>>> /restconf/data/example-jukebox:jukebox/playlist=3DFoo-One?insert=
=3Dfirst
> >>>>
> >>>> According to sec. 1.1.4, the target resource is the "Foo-One" en=
try of
> >>>> the "playlist" list. Correct?
> >>>>
> >>>> Then sec. 4.8.4 says:
> >>>>
> >>>>     [The "insert" query parameter] is also only supported if the=
 target
> >>>>     resource is a data resource, and that data represents a YANG=
 list or
> >>>>     leaf-list that is ordered by the user.
> >>>>
> >>>> To me, this means that the example is incorrect because the targ=
et
> >>>> resource is *not* a list ordered-by user.
> >>>
> >>> I think the quoted text is wrong.  For PUT, "insert" is only vali=
d
> >>> if the target resource is an obu list.  For POST, "insert" is onl=
y
> >>> valid if the child resource is an obu list.
> >>
> >> Yes, the POST part explains the example. An alternative would be t=
o
> >> keep
> >> the text and update the example(s), as I suggested.
> >
> > You cannot just update the example.  We'd have to rework lots of te=
xt,
> > e.g. we'd no longer map yang data node instances to resources; we'd=

> > have to come up with an encoding for the result of doing GET on suc=
h a
> > URI.
> >
> >> I am also wondering about the use of "insert" with PUT - it seems =
to
> >> violate the HTTP spec. RFC 7231: "The PUT method requests that the=

> >> state
> >> of the target resource be created or replaced with the state defin=
ed
> >> by
> >> the representation enclosed in the request message payload." This =
IMO
> >> means that PUT should be used only for creating/replacing a whole =
list
> >> or leaf-list.
> >
> > There is no resource for the "entire list".  Each list entry is its=

> > own resource.
> =

> So if I understand correctly, it's not possible to retrieve an entire=

> list with single GET request? As we are discussing the "jukebox"
> example, I can easily imagine that a user would like to retrieve all
> songs in particular playlist. It's really ineffective to retrieve the=
m
> one by one, because playlist can contain thousands of songs.

Agreed.  This is why we had 'collections' earlier; they got punted to
a separate document.  That work needs to continue once the base is
done.

> In this
> case, is the only way to request the parent "playlist" entry and
> manually separate the unneeded fluff like "name" and "description"
> leaves?

You can use the 'fields' parameter:

    GET .../playlist=3DFoo-One?fields=3Dsong


/martin


From nobody Thu Mar 24 08:40:42 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0019B12DCF8 for ; Thu, 24 Mar 2016 08:40:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level: 
X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIApjRfU06zT for ; Thu, 24 Mar 2016 08:40:38 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 828F312DD0D for ; Thu, 24 Mar 2016 08:26:24 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:45db:ad9a:f9e0:d864] (unknown [IPv6:2001:718:1a02:1:45db:ad9a:f9e0:d864]) by mail.nic.cz (Postfix) with ESMTPSA id 213CC189235; Thu, 24 Mar 2016 16:26:23 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1458833183; bh=2/JswP5IwdBs7cmYJJgFC7bAOHiPq6VAE29mZw73t1g=; h=From:Date:To; b=r69T9d1zXyC4iVZsK0i4J0+g+x2lINXG66n5V8XypytClGwZW3TkG/voH10w7BiB2 jRZrk3SyE0YAev2QCkFC4GV7g5JUltaifZS4il71hEkxqTnkDgBUhJpvFAFVo+lgi0 1+faXGnxWt1gvvZ93Ezk3pSELqcGbKUH+qvP+Xck=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <20160324.154447.1684158898406097169.mbj@tail-f.com>
Date: Thu, 24 Mar 2016 16:26:24 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <53E9DDD4-1FD2-49DA-A94B-C09D3DDC03F3@nic.cz>
References:  <20160324.142717.1147677482681127155.mbj@tail-f.com> <8CCC0BE3-73CB-4B98-843E-13878567E999@nic.cz> <20160324.154447.1684158898406097169.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] RESTCONF examples
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Mar 2016 15:40:41 -0000

> On 24 Mar 2016, at 15:44, Martin Bjorklund  wrote:
>=20
> Ladislav Lhotka  wrote:
>>=20
>>> On 24 Mar 2016, at 14:27, Martin Bjorklund  wrote:
>>>=20
>>> Ladislav Lhotka  wrote:
>>>> Martin Bjorklund  writes:
>>>>=20
>>>>> Ladislav Lhotka  wrote:
>>>>>> Andy Bierman  writes:
>>>>>>=20
>>>>>>> On Tue, Mar 22, 2016 at 7:26 AM, Ladislav Lhotka 
>>>>>>> wrote:
>>>>>>>=20
>>>>>>>> Andy Bierman  writes:
>>>>>>>>=20
>>>>>>>>> On Tue, Mar 22, 2016 at 6:10 AM, Ladislav Lhotka =

>>>>>>>>> wrote:
>>>>>>>>>=20
>>>>>>>>>> Hi,
>>>>>>>>>>=20
>>>>>>>>>> I checked the book RESTful Web Services by Richardson & Ruby, =
and they
>>>>>>>>>> illustrate a recommended design of resources with the =
following
>>>>>>>>>> example:
>>>>>>>>>>=20
>>>>>>>>>> | Operation      | HTTP action      |
>>>>>>>>>> |----------------+------------------|
>>>>>>>>>> | List the users | GET /users       |
>>>>>>>>>> | Create a user  | POST /users      |
>>>>>>>>>> | View a user    | GET /users/52    |
>>>>>>>>>> | Modify a user  | PUT /users/52    |
>>>>>>>>>> | Delete a user  | DELETE /users/52 |
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>> I think RESTCONF should follow the same pattern because this =
is what
>>>>>>>>>> developers are used to. The logic of some examples in the =
RESTCONF
>>>>>>>>>> spec
>>>>>>>>>> - namely what's a resource and what's its value - isn't very =
clear to
>>>>>>>>>> me.
>>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> This is what we have except lists are encoded in 1 segment =
instead
>>>>>>>>> of list key values in their own segment.
>>>>>>>>>=20
>>>>>>>>> Please provide OLD and NEW text fragments that you think need =
to be
>>>>>>>>> changed
>>>>>>>>=20
>>>>>>>> I did it already, without the OLD and NEW labels, so here it is =
again:
>>>>>>>>=20
>>>>>>>> =
---------------------------------------------------------------------
>>>>>>>> OLD
>>>>>>>>=20
>>>>>>>>     POST /restconf/data/example-jukebox:jukebox/
>>>>>>>>         playlist=3DFoo-One?insert=3Dfirst HTTP/1.1
>>>>>>>>     Host: example.com
>>>>>>>>     Content-Type: application/yang.data+json
>>>>>>>>=20
>>>>>>>>     {
>>>>>>>>       "example-jukebox:song" : {
>>>>>>>>          "index" : 1,
>>>>>>>>          "id" : "/example-jukebox:jukebox/library/
>>>>>>>>              =
artist=3DFoo%20Fighters/album=3DWasting%20Light/song=3DRope"
>>>>>>>>        }
>>>>>>>>     }
>>>>>>>>=20
>>>>>>>> NEW
>>>>>>>>=20
>>>>>>>>     POST /restconf/data/example-jukebox:jukebox/
>>>>>>>>         playlist=3DFoo-One/song?insert=3Dfirst HTTP/1.1
>>>>>>>>     Host: example.com
>>>>>>>>     Content-Type: application/yang.data+json
>>>>>>>>=20
>>>>>>>>     {
>>>>>>>>       "index" : 1,
>>>>>>>>       "id" : "/example-jukebox:jukebox/library/
>>>>>>>>         artist=3DFoo%20Fighters/album=3DWasting%20Light/song=3DRo=
pe"
>>>>>>>>     }
>>>>>>>> =
---------------------------------------------------------------------
>>>>>>>>=20
>>>>>>>> If we agree that this example adds an entry to the "song" list, =
then
>>>>>>>> IMO
>>>>>>>> "song" needs to appear in the Request-URI.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>=20
>>>>>>> This is not how RESTCONF has been defined from the start.
>>>>>>=20
>>>>>> Let's see. The Request-URI in the OLD version is
>>>>>>=20
>>>>>> =
/restconf/data/example-jukebox:jukebox/playlist=3DFoo-One?insert=3Dfirst
>>>>>>=20
>>>>>> According to sec. 1.1.4, the target resource is the "Foo-One" =
entry of
>>>>>> the "playlist" list. Correct?
>>>>>>=20
>>>>>> Then sec. 4.8.4 says:
>>>>>>=20
>>>>>>  [The "insert" query parameter] is also only supported if the =
target
>>>>>>  resource is a data resource, and that data represents a YANG =
list or
>>>>>>  leaf-list that is ordered by the user.
>>>>>>=20
>>>>>> To me, this means that the example is incorrect because the =
target
>>>>>> resource is *not* a list ordered-by user.
>>>>>=20
>>>>> I think the quoted text is wrong.  For PUT, "insert" is only valid
>>>>> if the target resource is an obu list.  For POST, "insert" is only
>>>>> valid if the child resource is an obu list.
>>>>=20
>>>> Yes, the POST part explains the example. An alternative would be to
>>>> keep
>>>> the text and update the example(s), as I suggested.
>>>=20
>>> You cannot just update the example.  We'd have to rework lots of =
text,
>>> e.g. we'd no longer map yang data node instances to resources; we'd
>>> have to come up with an encoding for the result of doing GET on such =
a
>>> URI.
>>=20
>> OK. This is easy to do for JSON encoding but I agree XML encoding
>> would need some extra containers or something.
>>=20
>>>=20
>>>> I am also wondering about the use of "insert" with PUT - it seems =
to
>>>> violate the HTTP spec. RFC 7231: "The PUT method requests that the
>>>> state
>>>> of the target resource be created or replaced with the state =
defined
>>>> by
>>>> the representation enclosed in the request message payload." This =
IMO
>>>> means that PUT should be used only for creating/replacing a whole =
list
>>>> or leaf-list.
>>>=20
>>> There is no resource for the "entire list".  Each list entry is its
>>> own resource.
>>=20
>> Your new text says otherwise: 'For PUT, "insert" is only valid if the
>> target resource is an obu list.'
>=20
> s/list/list entry/

So, if I understand you correctly, the two possible requests for =
inserting an entry as the new head of the "Foo-One" playlist's "song" =
list are

POST =
/restconf/data/example-jukebox:jukebox/playlist=3DFoo-One?insert=3Dfirst =
HTTP/1.1

and

PUT =
/restconf/data/example-jukebox:jukebox/playlist=3DFoo-One/song=3D2?insert=3D=
first HTTP/1.1

Both are pretty weird, IMO, given that we are adding an entry to the =
"song" list.

>=20
>> If it is so, then the semantics of
>> PUT require that the content of the target resource be replaced with
>> the payload. RESTCONF's PUT with "insert" modifies the target
>> resource, and such tasks should IMO be done with POST. Let's see if
>> APPS folks have any comments during the IETF LC.
>>=20
>>>=20
>>>> Also, RFC 7231 states that PUT is idempotent, but is it satisfied =
in
>>>> our
>>>> case? What happens if the same PUT request with the "insert" query
>>>> parameter is used twice?
>>>=20
>>> I think it should be ok.
>>=20
>> Do you mean that the second PUT should be silently ignored? Is it =
what
>> existing implementations do?
>=20
> The second PUT replaces the existing one (with exactly the same data).

But after the first insert we have a new head of the list, so doing =
insert=3Dfirst again may be interpreted as an attempt to put the same =
entry to the head of the list for the second time.

I am sorry we are arriving so late with these comments, but the =
ambiguities in the spec pop up only now that we are implementing it =
ourselves.

Lada

>=20
>=20
> /martin
>=20
>=20
>>=20
>> Lada
>>=20
>>>=20
>>>=20
>>> /martin
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

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





From nobody Thu Mar 24 09:26:04 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1B012D618 for ; Thu, 24 Mar 2016 09:26:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfwweTMdQBJv for ; Thu, 24 Mar 2016 09:25:57 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::759]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0732212D1CF for ; Thu, 24 Mar 2016 09:21:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HXYvzwJVAQDbrWzx0itXVFGg38eINueRHJh0UCNH9VI=; b=fVaZIApkNzRM+qgPMC9swdKpp4Jr6STxwcCCY6R5t9rjYrnaO9BCKnRjzBbqL6fzlbDZ46qQaeLfTqFcMvpteJQbJMD6PfX1kBD9eaKxn7SFnhzDiNewRoeHUJsX6EpTkgzMkpuuRjeJjc7/r8VbHJ06KyLw1f9OH5Gs1ezn4AA=
Authentication-Results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=btconnect.com;
Received: from pc6 (81.132.199.159) by HE1PR07MB1625.eurprd07.prod.outlook.com (10.166.124.21) with Microsoft SMTP Server (TLS) id 15.1.443.7; Thu, 24 Mar 2016 16:21:14 +0000
Message-ID: <011f01d185e8$d337a040$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Andy Bierman , Netconf 
References: 
Date: Thu, 24 Mar 2016 16:18:23 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [81.132.199.159]
X-ClientProxiedBy: DB3PR08CA0033.eurprd08.prod.outlook.com (25.161.51.171) To HE1PR07MB1625.eurprd07.prod.outlook.com (25.166.124.21)
X-MS-Office365-Filtering-Correlation-Id: 541b2023-35b8-4629-a2b2-08d3540052a4
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1625; 2:etF8B/08yikbWV8WJ+PjLszGA9ue3ausBLElE5P9gUr2bSCYuuXEzG2VfJD5bb9PeXXrJg1dcc1L2pUD0L7Y8Qr35ygKiW6OWJ0qc8Hacs5qmqugxsV2ZiCkBtBqDfDRk9wV9+blmUKsyBfyBUkEuHHlI3gaUaJsyB7/F58077us7bNvdV3vieiyjeZK1wzE; 3:t0o0v7SE2UUwfnkEx5mrR03q2/VZ6EiZHkjb63IakUnQniYyex9yR0/QoZuww7hxSzb72HUTs5b/S3NTDWcDIDZ841a6AsaTJYM+T6NukC3CwcMghff9f3mcdgo/OgAb
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR07MB1625;
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1625; 25:Bai8cPiJryMaUTQ1XeOMi6qk0s6ghqTNs6Alr6aFJT4Jz9NNZ/gJ43fs3Nv+oZZ+urFId58Y0WdIGF5IP50c4gmfTVcUrvNjQyHD8n9WrAGLnXgW8PgVRHXiGi7DT6hz/wUw2NqABbEhhNaz1vpMN70rmxUXXXqNLb2N6dSFYYjkiHR0Z/bh1y5sjqVU5qu0jUTyJdOUwcDh6e8BxCOTbaTwqUuLFIpEO6febUSaeXrIo8z7uDYvDy7Ua8NTLKWrazSkatjpYp/Z2O0HyhtyVTcFCOd/ywXub1f3oc/CHunvZRmHoZ5mdbtUMgb+Itmht+/4nHrJknIvbsbPJ2zL9E8+4Xty0WiWILmtWix0Y79FZE0qzctNB9S64sierguJyEo1CY/UpPD65uRPXniAp4h1GNA5qQh9qeBs+s9LgLYXtFR4njI1/feh4IR5aML8Rzb59mp8Rt3InR+guf6mTEnAT5nZV7dz02BTyS+gKyNUXMK2FGT2EsnTl7wS+varcW9NOW67PmRAqJn9AFHS9qmc5FRZjsrXJMH2FMyfqO2U3n4iGBJVX0pA4s35J9DgFTA5BQZqRm/I0zws5ngpVCXFxALgbB3mH3sNrOsUIJKX8j/hOqNWxUVWb6yr+A1eGspSIwp1vV1lJ/ezZTfvMSAfBRXl81VeBIFc1uqkzPWCvlX8V68tmJvzX81Tbkbn
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:HE1PR07MB1625; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1625; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1625; 4:XakNKgHqpfg5L6W/+kjQ4HD8qF8uL9XCC0QDs202J4hzYwXNkqK/ducsyb84SsIjlF3KVx9NjpzjVK7Ob/01ewUUBHiRDl/68G4+xS5Kxlr8A8jGZN5CrIFLQctn2C1fV8I4SHtnKoQYgvu/pOsSgUqr7+NxUI45FX15NWULXSkOmke9DCyJQ2V1rUlAls4xw2u7kUogD7WSGPdM7jxB1W4ea0r0TR8jTNKxa32QxmZFSwvmB5ZyByJjFw6RXDdxO+qoUxk959oG+MPK9ao5xrGexdBI6dfiiFYd7ReeH1gSeiBgEhg6IeJzLYR5taHEYi20o5rbfN8VVTOLAphQ0vuLTdAJr9i45k95ts8g5GpWjJe03cXlswFFWSKTLRXJ
X-Forefront-PRVS: 0891BC3F3D
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(377454003)(13464003)(66066001)(5004730100002)(14496001)(50226001)(44736004)(47776003)(3846002)(92566002)(44716002)(42186005)(19580395003)(50986999)(81816999)(19580405001)(50466002)(5008740100001)(116806002)(76176999)(229853001)(81686999)(86362001)(1096002)(15975445007)(77096005)(84392002)(33646002)(230700001)(586003)(6116002)(5001770100001)(61296003)(2906002)(107886002)(23676002)(189998001)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1625; H:pc6; FPR:; SPF:None; MLV:sfv;  LANG:en; 
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIxNjI1OzIzOmZwMHdCT1pDZ3FXeVFqWVJMM012TnpGUE5l?= =?utf-8?B?WFpDSVZidGpjVDRkc0NrN1dKaE1nQmZXWjFXM3ZlUUczVXRoWHRsc3lSYklK?= =?utf-8?B?SHJZN0RSVldVbGkwZkhCMVdxMXdFK1U1SXZXVUFWUUF2VzQ4V0xGUXE4bDE2?= =?utf-8?B?Ly9KMVpxNVVPcTFhY0U5SmU0eHV3bjV3eXFmZUE3ckdGVlZyWGVvcFBHQ1Uw?= =?utf-8?B?VmU1b2JyUFlvWnpDNncvUVltbFJuRUd4bDNDanlrTFNFbksyd3lVSytBd2xI?= =?utf-8?B?R1EyaWZwVys4QXBGMWFMY0I3MGpqOXVFK0JsbG83cmplZUZyT1EyK2N1d2NQ?= =?utf-8?B?anJKdnkrTE5HY1JmbXlzTmVld2J2OW8xbnRDMERmNmIvUzVaQzljN0o1MDVS?= =?utf-8?B?blhXSzNpZlhEOG9vK09ISFBoQ0hhT1FMVVpmZmxBOXlVTlU1YWQweXVQUith?= =?utf-8?B?cDFLNDdlSDdFSmt1aVhkbEdYT2xnLzlsaHBYRmg4N0liaW5MYjRPUHVlQllz?= =?utf-8?B?TzJMcWpwZVR1NG9uVTFGaHIvMG1sNklsdUp4aEdzdWxLOEd6MmJ3L3FiQ1Rj?= =?utf-8?B?ckFReGE3aHBxMk81ZGRSOHpJUk5NNHhtMVVzMnI1TkF5Z3cweCsxTGpBcXFi?= =?utf-8?B?M0VWSEJaUGFIaHg5S2pWeTVDMVYyQmNoSEFOVUp1SkVaTG9ncXhEcTY3cHdi?= =?utf-8?B?WE5NN2duVE93cHorMStwcHhhaTFrQmswR1RnQUtOemllbDA2VGp3d0ZhN1lW?= =?utf-8?B?UlFrS1dPVUdPNFlhRE5JRnBoWFdmc28wS2s0alAxUGVWSVk5ME1FZ3haT0Zo?= =?utf-8?B?TjRleU1jc3ZEb29tVTNwT1hjNkZpbVFKSG4rUzQ4ckQ2bHVFSURGNDBmYmxu?= =?utf-8?B?ZVpwUXN0VTFHeGx3K3Y3aDJzK1FvNENCYTFSL2ZuMXgzdUt6M0hTOFRQQ2NK?= =?utf-8?B?SlVPdllITkNIZjRMZ0U4NWlvRVlseWdneGw1TjJkaFJmN1RxRm15VmYrZjZN?= =?utf-8?B?dWxkRUZhMmI4ZTV4elZZb2Z5Qzg3NmdzclQybUdhUG0waGJlaTJsUFdqblNr?= =?utf-8?B?cDJVWU5BY0tweFc3VGtwVExXSkMyMEdqTHdrZzAwTmxJb3ZDN0VWTncyYitl?= =?utf-8?B?ZElRVXVjUldWR1A3QTl3VE02MkdBQlhCQWZqYTBrbDVJQUNDOThBSHlydzdk?= =?utf-8?B?VXRKT25SOC9tMFhJeklDbHBRbm85UW9iN2dmZThOWEluSmhaTXdGM3oybWhF?= =?utf-8?B?TlV2VHlNd0RIYTg1WlhXR1lJVFA1S1ZLZjh2SDFpcDJ2MzhWRWtncFpOMWMz?= =?utf-8?B?SnZNWEE4Vi9uVGlJNW93NllFQlFIUzRtWVN4cFBwckMyQXdyVXo2bmlRZ0NZ?= =?utf-8?B?MkFCQndYSnMvRUFCa1oyYm51S3ZKVnkwamlOUk5vc3lvei9qcEtONlF1Rndi?= =?utf-8?B?L042QWRsMG02eXBseWl5VDJoSlc2bnpad2JRUlZuUU9nK3p3QkRrMGNQL25r?= =?utf-8?Q?Rt3j9n8NBXSVG1GREyYbUAE0k=3D?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1625; 5:Mdnq2JgJ/IXFupQv3GQUpJ5CGaGw2yHMX4UtGZGN8pD5YLWWBzgkqpG2O9RJhntOE+qSznGnt2LJotqGdol2epm0bFmfxoaSLSvJsCuKDvfKvbwYHrcy5/KKCilBOjDWeK8cUepqpYpC7NIzwD/WaQ==; 24:Rf0BQMlYWb9T5T6Njw/fLm4Vrtfl5KWUErCKe96J4KUF8R/BIm7ZLt6cPavV9wRaOOBH+R1POgnPHZ3vIj1bNCINO9r0PZElbaOV3Pdss4I=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Mar 2016 16:21:14.9032 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1625
Archived-At: 
Subject: [Netconf]  RESTCONF-10 draft clarifications
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Mar 2016 16:26:00 -0000

It's BIG (which means I include comments up to the end of section 3 now
and hope to send the rest next week; questions of clarity, mostly).

I do like section 1, much more to my taste.

- 'state data is defined in 1.1.1, operational data is not defined.  The
former is used twice, that latter six times - I would rather 'state
data' were used throughout.  (I do see it as a persistent source of
confusion as others come to use NETCONF).

- s1.2 it might be better to give a REST reference [rest-dissertation]
where REST first appears.

-s1.4 "   If the device supports :startup, the device automatically
copies the "
sounds like a MUST

- s2.2 "The exclusive use the X.509v3 based certificates is consistent
with "
 use of?

- s2.3
"MUST use X.509 certificate path validation"
 and
"MUST also be considered valid if it matches a locally configured
certificate fingerprint"
seem contradictory to me; suggest something along the lines of

"MUST
 - either use X.509 certificate path validation
   [RFC5280] to verify the integrity of the RESTCONF server's TLS
   certificate
- or match the presented X.509 certificate with a locally configured
certificate fingerprints"

- s.2.5
"If the RESTCONF client is not authorized to access a resource, the
server MUST send an HTTP response with "401 Unauthorized"
cf s.4.3
"If the user is not authorized to read the target resource, an error
response containing a "403 Forbidden" "
seems contradictory

- s3.1 Can there be more than one restconf link relation?  I am not
thinking of the future postulated above with a version 2, but more of
SNMP with multiple MIBs under different community.

- s3.4
"Each RESTCONF edit of a datastore resource is saved to non-volatile
storage by the server. "
Is this a MUST?

- s3.5
"If not maintained, then the resource timestamp for the datastore MUST
be used instead."
I am unclear what the timestamp is being used for.

"This timestamp is only affected by configuration data resources, and
   MUST NOT be updated for changes to non-configuration data."

Which timestamp?  resource timestamp for the datastore?  Since it is a
new paragraph, I am unclear.


"If not maintained, then the resource entity tag  for the datastore MUST
be used instead.

This entity tag is only affected by configuration data resources, and
MUST NOT be updated for changes to non-configuration data"

Same pair of questions

- s3.5.2
"If a leaf or leaf-list is missing from the configuration ..."

"and the leaf has not been given a value yet, .. "

Do these mean that it has not been configured?  If so, I would find it
clearer if it said 'configured'; if not, I am unclear of the nuance.

- s3.6

"If the "input" section contains mandatory parameters, then a
message-body MUST be sent by the client."

6020bis says
"   If a leaf in the input tree has a "mandatory" statement with the
   value "true", the leaf MUST be present in an RPC invocation.
which I think more precise.  Suggest something like

"   If a leaf in the input tree has a "mandatory" statement with the
    value "true", the leaf MUST be present in an RPC invocation and
    a message-body MUST be sent by the client."

- should a similar statement be present for output?  I see no difference
between input and output in this regard.

s3.6.1
"      POST /restconf/data/example-action:interfaces/interface=eth0 ..."
"      { "example-action:input" : { ..."

module name is 'example-actions'

s3.6.2
"   The server might respond:

      HTTP/1.1 200 OK
      Date: Mon, 25 Apr 2012 11:10:30 GMT
      Server: example-server
      Content-Type: application/yang.operation+json
      {   "example-actions:output" : {
          "last-reset" : "2015-10-10T02:14:11Z"     }    } "

How does the client marry the output to the request? Should the rest of
the path be there?
  interfaces/interface=eth0/get-last-reset-time

Tom Petch


----- Original Message -----
From: "Andy Bierman" 
To: "Netconf" 
Sent: Sunday, March 20, 2016 7:02 PM

> Hi,
>
> Please review the latest version of the RESTCONF protocol:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/
>
> There have been many updates based on the extensive list
> of review comments:
>
>
https://tools.ietf.org/html/draft-ietf-netconf-restconf-10#appendix-A.1
>
> This draft addresses all open issues found on github:
> https://github.com/netconf-wg/restconf/issues
>
> Not all requested edits were made. Please review the
> github issue tracker for details about the editing process.
>
>
> thanks,
> Andy
>


From nobody Thu Mar 24 11:47:33 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE65A12D7E3 for ; Thu, 24 Mar 2016 11:47:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rV7DrrKtFuev for ; Thu, 24 Mar 2016 11:47:29 -0700 (PDT)
Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::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 5E46A12D1EB for ; Thu, 24 Mar 2016 11:47:29 -0700 (PDT)
Received: by mail-lb0-x235.google.com with SMTP id bc4so36796429lbc.2 for ; Thu, 24 Mar 2016 11:47:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=okYPMxyzHytS6cAwaUzcYQ/jd26VPbu9YpPxmFpFNG0=; b=LYOh31isJfe+dgub2I30YTtBu2WiKQdtHstfLyAliz6VibX9v7jSluxQmr/delGyeN 3RpOJIWjqXPypxcgPOTMcLBVNW3tQ900vIUAHPaL2d9OuVW6pkP9nAhY5RxaB1McJwl5 4MinJc21UN49e7A+180n+qegasnkPdaSDJ4jZ5cRwvFo1uC4KOtJR3NapJQDXWtOPjHb gZdrp9H3ocLFkLlh8/vtcpQf/OMhlj8qdH9OT0Aq5wqs9VQMNchf8fj1xeI/8VrqS4In gxabXnj+iNc1QnF3JLcytZQPFqlheSZi8BZu8NN5dZwbcQSSqRXUU4DksCJPlHCqktmc 7iCQ==
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; bh=okYPMxyzHytS6cAwaUzcYQ/jd26VPbu9YpPxmFpFNG0=; b=Gdm28LJkBGA1jrgkSSbn0utrZ0DWtm+mDYR33d081ftZd4ElsWlxgZuVWd0JcxLspi SFfW96QYv+PfVC5QQ7v4JcVR3+/PvaGgxUmiV+O9NTo+b2LoM+xf4OQh70rB0rmtVlhy FkBrH8Um3dc+Z1yjMVtCqVy5wwTHkcjxmDtlxtlqOl7csDkCIzV00WkV+TbhjKj7azhk heOybuYr51nkLqn7Fo1I9K7grrw8/204M2IRcTMubZ3rS4U2sVJBW8lVtv0dCLAOHSrT RYleaxBe+KPcWM1HMyisbQfsFoQ2Y8d9EGJpmKgWGw+b7pODKawop/qYLWLAfk4uA2/q +LgQ==
X-Gm-Message-State: AD7BkJJy3i2739AklBB8Bg8qho/DwGYXmza+HYzbOp0d7uwKPLl+GTPUgWaUWEQe7FTsVldp1rNDaoUoIkTMZQ==
MIME-Version: 1.0
X-Received: by 10.112.29.4 with SMTP id f4mr4123566lbh.92.1458845247339; Thu, 24 Mar 2016 11:47:27 -0700 (PDT)
Received: by 10.112.159.197 with HTTP; Thu, 24 Mar 2016 11:47:27 -0700 (PDT)
In-Reply-To: <59CD0F82-FAE9-41BD-921D-0590A4378345@gmail.com>
References: <59CD0F82-FAE9-41BD-921D-0590A4378345@gmail.com>
Date: Thu, 24 Mar 2016 11:47:27 -0700
Message-ID: 
From: Andy Bierman 
To: Mahesh Jethanandani 
Content-Type: multipart/alternative; boundary=001a1133f752c01342052ecfe085
Archived-At: 
Cc: draft-ietf-netconf-yang-patch@ietf.org, draft-ietf-netconf-yang-library@ietf.org, NETCONF , draft-ietf-netconf-restconf@ietf.org
Subject: Re: [Netconf] IPR on draft-ietf-netconf-yang-library, draft-ietf-netconf-yang-patch and draft-ietf-netconf-restconf
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Mar 2016 18:47:32 -0000

--001a1133f752c01342052ecfe085
Content-Type: text/plain; charset=UTF-8

Hi,

"No, I'm not aware of any IPR that applies to these drafts"


Andy


On Wed, Mar 23, 2016 at 6:31 PM, Mahesh Jethanandani <
mjethanandani@gmail.com> wrote:

> Authors, Contributors, Working Group,
>
> In preparation of sending the above documents for consideration of an RFC
> (text generously borrowed from NETMOD WG chairs)
>
> Are you aware of any IPR that applies to above stated drafts?
>
> Please state:
>
> "No, I'm not aware of any IPR that applies to these drafts"
> or
> "Yes, I'm aware of IPR that applies to this drafts"
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules (see
> RFCs 3979, 4879, 3669 and 5378 for more details)?
>
> If yes to the above, please state either:
>
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
>
> If you answer no, please provide any additional details you
> think appropriate.
>
> If you are listed as a document author or contributor please answer
> the above by responding to this email regardless of whether or not you
> are aware of any relevant IPR. This document will not advance to the
> next stage until a response has been received from each author and
> listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS
> MESSAGE'S
> TO LINES.
>
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under
> the IETF IPR rules which encourages you to notify the IETF if you are
> aware of IPR of others on an IETF contribution, or to refrain from
> participating in any contribution or discussion related to your
> undisclosed IPR. For more information, please see the RFCs listed above
> and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
>
> Mahesh & Mehmet.
>
>
>
>
>
>

--001a1133f752c01342052ecfe085
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

&q=
uot;No, I'm not aware of any IPR that applies to these drafts"


Andy


On =
Wed, Mar 23, 2016 at 6:31 PM, Mahesh Jethanandani <mjethanandani@gma=
il.com> wrote:
Authors, Contributors, Working Group,

In preparation of sending the above documents for consideration of =
an RFC (text generously borrowed from NETMOD WG chairs)

Are you aware of any IPR that applies to above stated drafts?

Please state:

"No, I'm =
not aware of any IPR that applies to these drafts"
or
"Yes,=
 I'm aware of IPR that applies to this drafts"

If so, has t=
his IPR been disclosed in compliance with IETF IPR rules=C2=A0(see RFCs 397=
9, 4879, 3669 and 5378 for more details)?

If yes to the above, pleas=
e state either:

"Yes, the IPR has been disclosed in compliance =
with IETF IPR rules"
or
"No, the IPR has not been disclosed=
"

If you answer no, please provide any additional details you t=
hink=C2=A0appropriate.

If you are listed as a document author or con=
tributor please answer the=C2=A0above by responding to this email regardles=
s of whether or not you are=C2=A0aware of any relevant IPR. This document w=
ill not advance to the next=C2=A0stage until a response has been received f=
rom each author and listed=C2=A0contributor. NOTE: THIS APPLIES TO ALL OF Y=
OU LISTED IN THIS MESSAGE'S
TO LINES.

If you are on the WG em=
ail list or attend WG meetings but are not listed
as an author or contri=
butor, we remind you of your obligations under
the IETF IPR rules which =
encourages you to notify the IETF if you are
aware of IPR of others on a=
n IETF contribution, or to refrain from
participating in any contributio=
n or discussion related to your
undisclosed IPR. For more information, p=
lease see the RFCs listed above
and
http://tr=
ac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
=



Mahesh & Mehmet.

<=
/div>









--001a1133f752c01342052ecfe085--


From nobody Fri Mar 25 11:32:12 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E782912D18B for ; Fri, 25 Mar 2016 11:32:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAgoHz30rJUa for ; Fri, 25 Mar 2016 11:32:09 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 7279012D1E0 for ; Fri, 25 Mar 2016 11:32:09 -0700 (PDT)
Received: by mail-oi0-x232.google.com with SMTP id n80so10671907oig.1 for ; Fri, 25 Mar 2016 11:32:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:subject:message-id:date:to:mime-version; bh=f7JaZQOn6CZPu/bVEr6UfmQeXNAxam8vRDLYC3OBR7A=; b=L0ntnapktyTnFOpfIPwaduE52uTi/lh3W1J37n1W5DiV4UF8EBXQrsAx3q22qZTN/K vuTUkUYMaNHMaIcToskiQPnATyQj9/lI3hUI6WdfTE8u94LF0l/yQL1+dPx1S4YholaR g/NQ3Fvrir4XdOa5Iw+KumSpbDrWodA2HUEOI65KLbO5XKjOZx5FbTa0HxU/4e/DC987 Na0OYbWHXAmEFlQzVSIuz0eQwLgifIWb1bNBpMEmIWd0prHwxeCWYNQn8boo8QysoEOF +HmyGNmOBYdu9EErFasYyLH41nUjRfJoASqmpe0aDoa3Q+XkzlYYKnsKipPwQkDY1Zge bp9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=f7JaZQOn6CZPu/bVEr6UfmQeXNAxam8vRDLYC3OBR7A=; b=P3x2aymxHe08SXmWKMnwuVNdKuP/sJjTCvBHBs/464EhxBGt3/vy4nm9c3a8/jMTvn IzEu0THT2ofW3d0adf79HsEmLQ2RMX5gaDmGGGzO6huJ5u+VRdDpUggG2P/nNla2bbZF JypUvCnGWj+Z7ltSsmOR/JOG0PnyTeDRN2BZsTsS5NbOFnmzuzmL5Wy2mRioCBECjydg sBFA4hsFnhxEmWspIHGHu72w5wCxSwm/12LhzWiWVdHnWaTv2N6a2GSOrtqSClx4HjCn PZ2BcKMrs2HaRfAJ2hF4R7cEecvfubERWyFeg/I7BjxBOHgc+d7nLlX3/tt6y+iditjx PCeA==
X-Gm-Message-State: AD7BkJKCn9kpwfabIrpxMv/lMpr1cnHXCqbTD7aug6G+Xla091qCkH6nRGLrRg+T/SvAHQ==
X-Received: by 10.157.11.200 with SMTP id 66mr7908969oth.45.1458930728873; Fri, 25 Mar 2016 11:32:08 -0700 (PDT)
Received: from ?IPv6:2602:306:cf77:df90:e920:cd2f:16f1:ac2d? ([2602:306:cf77:df90:e920:cd2f:16f1:ac2d]) by smtp.gmail.com with ESMTPSA id ed8sm1521435obb.19.2016.03.25.11.32.07 for  (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 25 Mar 2016 11:32:08 -0700 (PDT)
From: Mahesh Jethanandani 
Content-Type: multipart/alternative; boundary="Apple-Mail=_F23A254A-15EC-4A47-8560-B6B8707D0FEE"
Message-Id: 
Date: Fri, 25 Mar 2016 11:32:06 -0700
To: NETCONF 
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Subject: [Netconf] Draft agenda posted
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Mar 2016 18:32:11 -0000

--Apple-Mail=_F23A254A-15EC-4A47-8560-B6B8707D0FEE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

A draft agenda has been posted at the following site.

https://datatracker.ietf.org/meeting/95/agenda/netconf/ =


Presenters, please make sure you have been identified (correctly) for =
the presentation. Please send your slides. If the final version is not =
ready, a draft version will do.

Thanks.

Mahesh & Mehmet






--Apple-Mail=_F23A254A-15EC-4A47-8560-B6B8707D0FEE
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii


A draft agenda has been posted at the following site.

https://datatracker.ietf.org/meeting/95/agenda/netconf/

Presenters, please make sure you have been identified (correctly) for the presentation. Please send your slides. If the final version is not ready, a draft version will do.

Thanks.



Mahesh & Mehmet









--Apple-Mail=_F23A254A-15EC-4A47-8560-B6B8707D0FEE--


From nobody Fri Mar 25 18:17:15 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0745912D0E5 for ; Fri, 25 Mar 2016 18:17:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGEGCG_BXTSH for ; Fri, 25 Mar 2016 18:17:12 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0748.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::748]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2E8E12D0AE for ; Fri, 25 Mar 2016 18:17:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UZ4q+u1l0LJSXKEpYdGS9e3GppEWCY5qE/c8D/LR6t8=; b=jWaVPtou3z3a80dRUlIoDOmUUeVTnRiVI71zfGVorg/kuU3WUqtU1jNudbyfbOBSjVBtNQjHcQEsF1i2pJaJw19NsaeujEi6EvKlMykrRFE2uIe1Zi0NceyyR1MfTjJ/nsIcz2BA4ZalOAqUZZHri9vvDhXhnuj5pAbFvRSqyrQ=
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1452.namprd05.prod.outlook.com (10.160.149.13) with Microsoft SMTP Server (TLS) id 15.1.434.16; Sat, 26 Mar 2016 01:16:55 +0000
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0434.023; Sat, 26 Mar 2016 01:16:55 +0000
From: Kent Watsen 
To: Mahesh Jethanandani , NETCONF 
Thread-Topic: [Netconf] Draft agenda posted
Thread-Index: AQHRhsSnacdP77EYIkutK5EZbK6sm59qqcMA
Date: Sat, 26 Mar 2016 01:16:54 +0000
Message-ID: 
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.160212
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.12]
x-ms-office365-filtering-correlation-id: a84f7e80-4390-4cdc-97c5-08d3551451db
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1452; 5:F1+CO7XdznAQJHi689l8rzSiAg3sqRx/aysukjnp5k0JPH0NVDH4E5Ow8MJHpFS0hcSOF8mVuVWzp8R7gfqqPaTrLJDxEj4rRNjL5WFbzqG9zA5jY1pYJaJ3uflF3f7ah9puyNCcVbOAO1z7c2DxEg==; 24:7LdgOIocx45a/3yrGUG+tyc0rNtQDTrtaF1XQxtHcl3Mr6tju7TLMDCPL1X+EiNhqHlyYVOZqeLJ015l7rUcYHfpjENrPoLPtsYAItlkJRA=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1452;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:CY1PR0501MB1452; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1452; 
x-forefront-prvs: 0893636978
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(164054003)(33656002)(5008740100001)(11100500001)(3280700002)(5001770100001)(66066001)(19617315012)(586003)(99286002)(1220700001)(83506001)(81166005)(5002640100001)(107886002)(82746002)(3660700001)(189998001)(19580395003)(4001350100001)(36756003)(19580405001)(83716003)(2906002)(2900100001)(86362001)(10400500002)(87936001)(5004730100002)(2950100001)(122556002)(77096005)(15975445007)(54356999)(92566002)(50986999)(76176999)(1096002)(106116001)(6116002)(3846002)(102836003)(16236675004)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1452; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_F5934F3FCE6141F2BDDB551B4638D296junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2016 01:16:54.9643 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1452
Archived-At: 
Subject: Re: [Netconf] Draft agenda posted
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Mar 2016 01:17:14 -0000

--_000_F5934F3FCE6141F2BDDB551B4638D296junipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQpTb21lIENvbW1lbnRzOg0KDQotIHRoZSB0aXRsZSBmb3IgZHJhZnQtaWV0Zi1uZXRjb25mLXNl
cnZlci1tb2RlbCBpczoNCg0KIk5FVENPTkYgU2VydmVyIGFuZCBSRVNUQ09ORiBTZXJ2ZXIgQ29u
ZmlndXJhdGlvbiBNb2RlbHPigJ0NCg0KDQogIC0gdGhlIHRpdGxlIGZvciBkcmFmdC1pZXRmLW5l
dGNvbmYtemVyb3RvdWNoIGlzOg0KDQoiWmVybyBUb3VjaCBQcm92aXNpb25pbmcgZm9yIE5FVENP
TkYgb3IgUkVTVENPTkYgYmFzZWQgTWFuYWdlbWVudOKAnQ0KDQoNCiAgLSAzMCBtaW51dGVzIGZv
ciB0aGUgdHdvIHByZXNvcyBzZWVtcyBtb3JlIHRoYW4gZW5vdWdoLg0KDQoNClRoYW5rcywNCktl
bnQNCg0KDQpGcm9tOiBOZXRjb25mIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5l
dGNvbmYtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBNYWhlc2ggSmV0aGFuYW5kYW5p
IDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+
Pg0KRGF0ZTogRnJpZGF5LCBNYXJjaCAyNSwgMjAxNiBhdCAyOjMyIFBNDQpUbzogIm5ldGNvbmZA
aWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+IiA8bmV0Y29uZkBpZXRmLm9yZzxtYWls
dG86bmV0Y29uZkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbTmV0Y29uZl0gRHJhZnQgYWdlbmRhIHBv
c3RlZA0KDQpBIGRyYWZ0IGFnZW5kYSBoYXMgYmVlbiBwb3N0ZWQgYXQgdGhlIGZvbGxvd2luZyBz
aXRlLg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvOTUvYWdlbmRhL25l
dGNvbmYvDQoNClByZXNlbnRlcnMsIHBsZWFzZSBtYWtlIHN1cmUgeW91IGhhdmUgYmVlbiBpZGVu
dGlmaWVkIChjb3JyZWN0bHkpIGZvciB0aGUgcHJlc2VudGF0aW9uLiBQbGVhc2Ugc2VuZCB5b3Vy
IHNsaWRlcy4gSWYgdGhlIGZpbmFsIHZlcnNpb24gaXMgbm90IHJlYWR5LCBhIGRyYWZ0IHZlcnNp
b24gd2lsbCBkby4NCg0KVGhhbmtzLg0KDQpNYWhlc2ggJiBNZWhtZXQNCg0KDQoNCg0KDQo=

--_000_F5934F3FCE6141F2BDDB551B4638D296junipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: <8590569A47860E40855FEB8980C62463@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8
ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu
cy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNv
bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250
LXNpemU6IDE0cHg7Ij4NClNvbWUgQ29tbWVudHM6PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjog
cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXpl
OiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7
IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxk
aXY+PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPi0gdGhlIHRpdGxlIGZvciA8
L3NwYW4+PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPmRyYWZ0LWlldGYtbmV0
Y29uZi1zZXJ2ZXItbW9kZWwgaXM6PC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0id2hp
dGUtc3BhY2U6IHByZS13cmFwOyI+PGJyPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u
dC1mYW1pbHk6IENhbGlicmk7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNh
bnMtc2VyaWY7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPjxzcGFuIGNsYXNzPSJBcHBsZS10YWIt
c3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOiBwcmU7Ij48L3NwYW4+JnF1b3Q7PC9zcGFuPjxmb250
IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOiBwcmUt
d3JhcDsiPk5FVENPTkYgU2VydmVyDQogYW5kIFJFU1RDT05GIFNlcnZlciBDb25maWd1cmF0aW9u
IE1vZGVsc+KAnTwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmks
c2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPjxicj4NCjwv
c3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxl
PSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg
Zm9udC1zaXplOiAxNHB4OyI+DQombmJzcDsgLSB0aGUgdGl0bGUgZm9yJm5ic3A7PHNwYW4gc3R5
bGU9IndoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPmRyYWZ0LWlldGYtbmV0Y29uZi16ZXJvdG91Y2gg
aXM6PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1m
YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPHNwYW4gc3R5
bGU9IndoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPjxicj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNw
YW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z
LXNlcmlmOyBmb250LXNpemU6IDE0cHg7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPjxzcGFuIGNs
YXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPiZxdW90
Ozwvc3Bhbj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJ3aGl0
ZS1zcGFjZTogcHJlLXdyYXA7Ij5aZXJvIFRvdWNoDQogUHJvdmlzaW9uaW5nIGZvciBORVRDT05G
IG9yIFJFU1RDT05GIGJhc2VkIE1hbmFnZW1lbnTigJ08L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRp
dj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFj
ZTogcHJlLXdyYXA7Ij48YnI+DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29s
b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQt
c2l6ZTogMTRweDsiPg0KPHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPjxicj4N
Cjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt
aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCiZuYnNwOyAtIDMw
IG1pbnV0ZXMgZm9yIHRoZSB0d28gcHJlc29zIHNlZW1zIG1vcmUgdGhhbiBlbm91Z2guPC9kaXY+
DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwg
c2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9
ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBm
b250LXNpemU6IDE0cHg7Ij4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05BVFVSRSI+PC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDAp
OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8
YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5
OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NClRoYW5rcyw8L2Rpdj4N
CjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz
YW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCktlbnQ8L2Rpdj4NCjxkaXYgc3R5bGU9ImNv
bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250
LXNpemU6IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAw
LCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsi
Pg0KPGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iIHN0eWxlPSJj
b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9u
dC1zaXplOiAxNHB4OyI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNp
emU6MTJwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVk
aXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsg
UEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRk
ZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQi
Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5OZXRjb25mICZs
dDs8YSBocmVmPSJtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIj5uZXRjb25mLWJvdW5j
ZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgTWFoZXNoIEpldGhhbmFuZGFuaSAmbHQ7
PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIj5tamV0aGFuYW5kYW5pQGdt
YWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6
IDwvc3Bhbj5GcmlkYXksIE1hcmNoIDI1LCAyMDE2IGF0IDI6MzIgUE08YnI+DQo8c3BhbiBzdHls
ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86bmV0
Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1h
aWx0bzpuZXRjb25mQGlldGYub3JnIj5uZXRjb25mQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3Bh
biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPltOZXRjb25mXSBEcmFm
dCBhZ2VuZGEgcG9zdGVkPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNl
OyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2
IGNsYXNzPSIiPkEgZHJhZnQgYWdlbmRhIGhhcyBiZWVuIHBvc3RlZCBhdCB0aGUgZm9sbG93aW5n
IHNpdGUuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGEgaHJl
Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzk1L2FnZW5kYS9uZXRjb25m
LyIgY2xhc3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzk1L2FnZW5k
YS9uZXRjb25mLzwvYT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2
IGNsYXNzPSIiPlByZXNlbnRlcnMsIHBsZWFzZSBtYWtlIHN1cmUgeW91IGhhdmUgYmVlbiBpZGVu
dGlmaWVkIChjb3JyZWN0bHkpIGZvciB0aGUgcHJlc2VudGF0aW9uLiBQbGVhc2Ugc2VuZCB5b3Vy
IHNsaWRlcy4gSWYgdGhlIGZpbmFsIHZlcnNpb24gaXMgbm90IHJlYWR5LCBhIGRyYWZ0IHZlcnNp
b24gd2lsbCBkby48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8
ZGl2IGNsYXNzPSIiPlRoYW5rcy48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz
cz0iIj4NCjxkaXYgYXBwbGUtY29udGVudC1lZGl0ZWQ9InRydWUiIGNsYXNzPSIiPg0KPGRpdiBz
dHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFu
czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm
b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu
ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWst
d29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVy
LXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDAp
OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy
dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu
b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv
a2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTog
c3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4N
CjxkaXYgY2xhc3M9IiI+TWFoZXNoICZhbXA7IE1laG1ldDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48
YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5n
ZS1uZXdsaW5lIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5l
Ij4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8L2Rpdj4NCjxiciBj
bGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPC9ib2R5
Pg0KPC9odG1sPg0K

--_000_F5934F3FCE6141F2BDDB551B4638D296junipernet_--


From nobody Sat Mar 26 05:30:45 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6ABE12D1AE; Sat, 26 Mar 2016 05:30:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHdrtzpOK_Ey; Sat, 26 Mar 2016 05:30:41 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0091.outbound.protection.outlook.com [104.47.2.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EF4B12D16F; Sat, 26 Mar 2016 05:30:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/QL6ydmvgwH2opFBOBzyPNO/aGDyxG7fX2Jx8g5oiMU=; b=NGxFoz+NOXtv2JTSnUMIUHbAqiAzD9q6dQ9GAcGPlnl0v9aonGIjDIJcXTzwicEaXbC7x9PtDMn7iZbIialdzQIqfZRD//7JfNGfXhf85S0nLCwBhTqfAW0FUDyQA3/BlhMC2AJDtFvgpivbtNX4rcwhPpRhzi36geKyeyb5PH8=
Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=btconnect.com;
Received: from pc6 (81.132.199.159) by HE1PR07MB1625.eurprd07.prod.outlook.com (10.166.124.21) with Microsoft SMTP Server (TLS) id 15.1.443.7; Sat, 26 Mar 2016 12:30:36 +0000
Message-ID: <024101d1875a$ee089000$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Mahesh Jethanandani 
References: <59CD0F82-FAE9-41BD-921D-0590A4378345@gmail.com> <7C70F2DB-DADD-4CF0-8369-FF012D38D0E8@juniper.net>
Date: Sat, 26 Mar 2016 12:27:37 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [81.132.199.159]
X-ClientProxiedBy: DB4PR05CA0002.eurprd05.prod.outlook.com (25.160.40.12) To HE1PR07MB1625.eurprd07.prod.outlook.com (25.166.124.21)
X-MS-Office365-Filtering-Correlation-Id: ab76a0de-784e-4422-6369-08d355726f78
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1625; 2:Ye47+WqofQjS/BDXasvHCXL8asXb5sU1kjxaUGhWojdpiUQ0r22flvds+cMY2FpJJn9wHC0kKohcwRQmXRO+a10q+y7L5VHj5D3VtZ7aFqbWK2iz/U7crM3AkdZB7q4hcy+TgsdPWVvKaSMaoQnXr4yI+oxd/wtn6JoWVF2c+Q/PQc6bze+ZLb96yktDVDaI; 3:QVmFK67vL8roq2jWuI/bahlbqALG5U8krk9U7KuMTJUwhNxOZFmyQMhpLu6lyrMvLwBQ75vNNa1E/Q/SN3YGXKUxErpOmnc8CdC9p8FewNiN4F+WvUbVfteis8FW/ft/
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR07MB1625;
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1625; 25:buaDw6NFv1IcofZvf852xUsR0+kxf6wEc+IfAumN/VkKR8/Q/miRvx2i9DnGFsYnYj3rBUkjgdHjqT45KfCcoRB3M7fyL/wr8J7Cp+laIdubZZmME8rFvFSC32tysWieLuASwyYrtLi3YwmX7iJ4tZYd39qHElIjtdGPs75n1x/UA2un7lx7xpOLVK5PpqXYHqr/oqGcAbrQUiNLvSTvIjt4xDzQivH6WHSByFkHkVUlI0s45kJMLvnqF+NzTElb6EeInnLaB3+1rJaw8han+ITeaTJYwQS0mUu9RaT+A+o7bDlv16kE+cUKc84/gomkgwJh7jszsefWXbeDfOEBd5wSytoNm/jFTGB0NxYABv+pQ+mBuJnK956nm1hWUi1669vq8SM8BCUtMyMDgvs94Wh0XzJmMf8yje0wBRUwnZywZa1K9lunlIEOrWHV+lphv0h3+Qqyj6uiPJy3zqcyOwR+AwqCOz3vbMuLHD3ex6wKNe/JBIqDlK2ZXALcf21PQ27qt4byGyjcEt3M3nm4Jn5T7ZcKQN2U9jeGbcAcn5lUP7dk2/a7MV5zgaDa/LwTEQkqe6cnqHYqE+Al6RtxJe9BYYosSibzFRJjGmV2nOSgzpC0fKQcthfQTMsn8A04ZbZDanv3+aICtPW+Y5Xnj/ATfd4Ogius7Z86263Yy+k=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:HE1PR07MB1625; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1625; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1625; 4:1eaxS+xp6jeHIiWD7shhw822qy0h0jmSZvp3A1IZUBpRo9pU2Y0at8EiDvD7ho8C3wkk1VEjVY8hFAoDea2Vh6gx1fx+bXGrpBeGkvzqIh0QRbaTKuc5HZjlA2L3Oea1gd6vlhkJhrpMfB4dNFehsxIjwrVwMP5th4VULWtEB3P68QMZ9XTvI+RAEy8pLr6tmPJ7n82z72CHDzdec21MV9Eh0XegDBAVb23zwIuwDSxQYMSZO8fvntpMN3mbMonTeMSZd1Hco8y/cF47QJ+eKdd1u1dJ1K+C6QelpU9qiVGd/m+ww/FGJu++rts0T6jptXtDU+CLlB2dcOwFH/R7lLDSd0knTfhfubXE9ZXivbrAfN49DyEV17X+cItpQICI
X-Forefront-PRVS: 0893636978
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(54094003)(377454003)(24454002)(42186005)(61296003)(4326007)(2906002)(76176999)(586003)(81816999)(81686999)(92566002)(6116002)(3846002)(23756003)(33646002)(5004730100002)(230700001)(1096002)(15975445007)(77096005)(5008740100001)(110136002)(50466002)(86362001)(66066001)(81166005)(230783001)(50986999)(50226001)(19580395003)(189998001)(19580405001)(44716002)(62236002)(47776003)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1625; H:pc6; FPR:; SPF:None; MLV:sfv;  LANG:en; 
X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR07MB1625; 23:1d78C9eFkJM1g4hOprDk8OCuwWcY22yeKk3mlj+?= =?iso-8859-1?Q?q9vT46I0uBz3X15CTtmjknR+aRPPvLTqLaeqoWMEVqOHFxf01HCYXbQf+A?= =?iso-8859-1?Q?G+A7xoMG2Qs2mteFC1lHlVMHUTI3OXX9Gag/i+VeNH3fFGFYAFPPcDwn5W?= =?iso-8859-1?Q?KqmViaa+WZRTTY/vnkKo1nJh4q9sIxZr9j9D3ONKa4gQXaxQw4bm1BG8QF?= =?iso-8859-1?Q?WVPPZjZ9GurCeaNkUMHCVd8QjJNBnFDBtOUqWs+Vdin3LE1reZvbQ6Cv8A?= =?iso-8859-1?Q?o+GLrAaEYgEkV7Ve5rHP3qcA0gJehD6B3i9RVH1D59XmtV2V2eDJWJbWRX?= =?iso-8859-1?Q?Cq1SlmBbY95Qd8wCXTCxvY0DmpP4G4jVUIXUcliE2LGx0I8ft7thl7kGbd?= =?iso-8859-1?Q?a/QWM7PFfFpsKO4wUFeT3elslJ0fuyu0PNmPzpMGNj8l5gkiCtTFWtV4V5?= =?iso-8859-1?Q?Ilwg9zxi0PFhWUK57aveOMXnNWaCksToexK1zlDEx/scEbxKYJNEKUZQ9S?= =?iso-8859-1?Q?Aekb4IQ1/f9kejtJRoqqpdndDzuK5SsopNojn4HN4wSSIn5/6mw9pAVT+j?= =?iso-8859-1?Q?NpdQVt3ivn4yiDKTyv5rkz0c4OpQwn9fwZrkx3/BQAvGtvgwkMygjDchRX?= =?iso-8859-1?Q?0vQd0uUewlcdMd/KX1g9LE49c5khDih3iOQQywO5wHQWTi1tmAuT/8LY24?= =?iso-8859-1?Q?hzQJMxifuiCKU33A0JeyomGGFrVJPxVtTR9eXla8+l3y8mqSkxMo8PnhoC?= =?iso-8859-1?Q?n5Ecgp6lKp3ooheAaauchYVSS5DXT3MF+LJN4i+zwLqxoF2+rdC4c0kLYC?= =?iso-8859-1?Q?MOelhhm6UvplPLzsAB/bXDbLFswBbHy6r75s6rD1oORLdlU/BbLFu7Yyuu?= =?iso-8859-1?Q?Dr/S80Li70cKkBnUPldY7I8uKYYkxFCHUr20ud92NRxRAwsW5U+xAT6u+v?= =?iso-8859-1?Q?xT4VZ1K/xRm0F3C3WhZer6BNtmLFhXl0oxEnDwoDpGUFZwJy3l5kAPb706?= =?iso-8859-1?Q?srvvE0I5abeSSHNHENImByiPvpIKGkBBkHqGENu/UAA0cf8O0XTsbDxMa+?= =?iso-8859-1?Q?DXDejvTFL7IoClgEXo9/Q=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1625; 5:vSIbX6xfyC20gi0i8vMIv8bNFqJ0bntg7GzOdZm2A0zLl6WsRxnWEMqUvzA8SP8qeF8ko7FvTYW+yJej0FZehw4jKGIKgu5uk/uk+YqVsygIp+uipEkrdjYy9Sf8JzkolxjWVaCv5S+QjdnY9plWCQ==; 24:3V78apd8luosglVmgmo9L1DiHzEBfpYkGLFGU+GE2otZXWz00ugwhnHlZAjHeNrQA5Jx7uGqlE28175u7oaDZ6JY6QGcZIgg4+BxaXsWAOs=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Mar 2016 12:30:36.8383 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1625
Archived-At: 
Cc: draft-ietf-netconf-yang-patch@ietf.org, draft-ietf-netconf-yang-library@ietf.org, NETCONF , draft-ietf-netconf-restconf@ietf.org
Subject: Re: [Netconf] IPR on draft-ietf-netconf-yang-library, draft-ietf-netconf-yang-patch and draft-ietf-netconf-restconf
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Mar 2016 12:30:43 -0000

No, I'm not aware of any IPR that applies to these drafts.

I wondered if this applied to me and indeed it does, as I am listed as a
contributor to netconf-restconf, along with 14 others; I suspect that
most of those 14 will not respond to this e-mail without a further
prompt but am willing to be pleasantly surprised.  I note that the other
two drafts do not list contributors to anything like the same extent; I
wonder if this new approach will lead to a reduction in the number of
people listed as contributors - which would be a shame, but then chasing
down 14 additional responses has its own costs.

In passing, this e-mail references, below, all those listed in the to:
line.  In the e-mail as I received it, this was just the I-D related
lists:-)

Tom Petch

On Mar 23, 2016, at 9:31 PM, Mahesh Jethanandani
> wrote:

Authors, Contributors, Working Group,

In preparation of sending the above documents for consideration of an
RFC (text generously borrowed from NETMOD WG chairs)

Are you aware of any IPR that applies to above stated drafts?

Please state:

"No, I'm not aware of any IPR that applies to these drafts"
or
"Yes, I'm aware of IPR that applies to this drafts"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Mahesh & Mehmet.








------------------------------------------------------------------------
--------


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


From nobody Sat Mar 26 05:56:46 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789AF12D198; Sat, 26 Mar 2016 05:56:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level: 
X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqqB0V_psBwX; Sat, 26 Mar 2016 05:56:43 -0700 (PDT)
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 12E6A12D5AB; Sat, 26 Mar 2016 05:56:42 -0700 (PDT)
Received: from [IPv6:2a01:5e0:29:ffff:89a8:b337:4df4:b8bd] (unknown [IPv6:2a01:5e0:29:ffff:89a8:b337:4df4:b8bd]) by mail.nic.cz (Postfix) with ESMTPSA id 863B0180153; Sat, 26 Mar 2016 13:56:40 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1458997000; bh=2mgnL615j9uopt5eJNVYEMBYkZPoPjJ36WzHa5Xg0BQ=; h=From:Date:To; b=ByRpKWXlRjXtq4h282ml6fP60m/AKDiX0UWr9hhD6cGpKMOe2N24tAoYLCRYh/Lht 3A5ubRnSGOnCEUqNIM5thYNT7+kmCNnscerSvm16jnaBLBBD5dYMYCZPws0OJnIeUT y1KvpsOKXo9niT/sbouHJVyNsmnlpPY0Dw6+STsA=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <59CD0F82-FAE9-41BD-921D-0590A4378345@gmail.com>
Date: Sat, 26 Mar 2016 13:56:40 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <59CD0F82-FAE9-41BD-921D-0590A4378345@gmail.com>
To: Mahesh Jethanandani 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: draft-ietf-netconf-yang-patch@ietf.org, draft-ietf-netconf-yang-library@ietf.org, Netconf , draft-ietf-netconf-restconf@ietf.org
Subject: Re: [Netconf] IPR on draft-ietf-netconf-yang-library, draft-ietf-netconf-yang-patch and draft-ietf-netconf-restconf
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Mar 2016 12:56:45 -0000

No, I'm not aware of any IPR that applies to these drafts.

Lada

> On 24 Mar 2016, at 02:31, Mahesh Jethanandani =
 wrote:
>=20
> Authors, Contributors, Working Group,
>=20
> In preparation of sending the above documents for consideration of an =
RFC (text generously borrowed from NETMOD WG chairs)
>=20
> Are you aware of any IPR that applies to above stated drafts?
>=20
> Please state:
>=20
> "No, I'm not aware of any IPR that applies to these drafts"
> or
> "Yes, I'm aware of IPR that applies to this drafts"
>=20
> If so, has this IPR been disclosed in compliance with IETF IPR rules =
(see RFCs 3979, 4879, 3669 and 5378 for more details)?
>=20
> If yes to the above, please state either:
>=20
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
>=20
> If you answer no, please provide any additional details you think =
appropriate.
>=20
> If you are listed as a document author or contributor please answer =
the above by responding to this email regardless of whether or not you =
are aware of any relevant IPR. This document will not advance to the =
next stage until a response has been received from each author and =
listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS =
MESSAGE'S
> TO LINES.
>=20
> If you are on the WG email list or attend WG meetings but are not =
listed
> as an author or contributor, we remind you of your obligations under
> the IETF IPR rules which encourages you to notify the IETF if you are
> aware of IPR of others on an IETF contribution, or to refrain from
> participating in any contribution or discussion related to your
> undisclosed IPR. For more information, please see the RFCs listed =
above
> and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
>=20
> Mahesh & Mehmet.
>=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 Tue Mar 29 13:02:39 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A072C12E332 for ; Tue, 29 Mar 2016 13:02:37 -0700 (PDT)
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 autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id po5vZ-pJ6_4V for ; Tue, 29 Mar 2016 13:02:35 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC0A12E1E9 for ; Tue, 29 Mar 2016 12:25:58 -0700 (PDT)
Received: from localhost (h-53-58.a165.priv.bahnhof.se [46.59.53.58]) by mail.tail-f.com (Postfix) with ESMTPSA id C861E1AE0144 for ; Tue, 29 Mar 2016 21:25:56 +0200 (CEST)
Date: Tue, 29 Mar 2016 21:25:56 +0200 (CEST)
Message-Id: <20160329.212556.1290892363387952983.mbj@tail-f.com>
To: netconf@ietf.org
From: Martin Bjorklund 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Netconf] mbj review of draft-ietf-netconf-restconf-server-model-09
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2016 20:02:37 -0000

Hi,

Here is my review of draft-ietf-netconf-restconf-server-model-09.

o  Section 3

  The picture should s///g


o  Section 4

  It would be usefule with a reference to the term IDevID in this
  document.


o  Section 4.1

  OLD:

   o  A configurable list of lists of trust anchor certificates.  This
      enables the server to have use-specific trust anchors.  For

  NEW:

   o  A configurable list of trust anchor certificates.  This
      enables the server to have use-specific trust anchors.  For

  ... but what does "use-specific" mean?


o  Section 4.1

  The text says:

   o  An RPC to request the server to load a new private key.

  When I first read this, I didn't understand what this meant.  See
  more below.


o  Section 4.1

  I think the "semi-configurable" design has some issues.  You have
  defined some actions that actually modifies the configuration of the
  system.  It is not clear which config datastore is modified.
  Presumably running.  Interactions with locking and access control
  are not described.  Also, the resulting configuration is not
  complete - i.e., you cannot do  to save/restore a
  backup.  This is fine, since you really don't want to expose the
  private keys in the config backup.  But some discussion is needed
  around this subject.  What happens if I generate a private key with
  your action, backup that config and then restore it?  What happens
  with config that has references to such a key?

  One way to avoid that the actions modify the configuration could be
  to move them into the private-key list.  One drawback is that two
  operations are needed in order to create a (usable) key - first
  create the config in running, then call the action.

  Another option might be to model the keys as config false data.
  This also solves the problem that some keys (in TPM for example)
  are not deletable.


o  Section 4.1.3

  OLD:

  import ietf-yang-types {     // RFC 6991
    prefix yang;
  }

  NEW:

  import ietf-yang-types {
    prefix yang;
    reference "RFC 6991: Common YANG Data Types";
  }

  (same for the other modules)


o  Section 4.1.3

  I think the "algorithms" typedef should be called "algorithm".  But
  actually, it should probably have a more descriptive name
  "algorithm" is rather generic...

  Also, this is an fixed enumeration.  Section 5 says: 

    In additional
    algorithms are needed, they MAY be augmented in by another module,

  [note: s/In/If/]

  You can't really augment in additional enums.  You'd have to augment
  an additional leaf of some other type.

  What happens to the "algorithm" leaf when I load a key with your
  action?  Will other algorithms be rejected?

  If you keep the enums, a reference statement for each enum would be
  useful.


o  Section 4.2.1

  I was confused by the containers that the RFC editor are supposed to
  remove.  Then I realized they exist due to a deficiency in pyang...
  So I fixed pyang; you can now pass --tree-print-groupings (only in
  1.1 branch).

  I don't have a solution for the long leafrefs though.  But in any
  case, I think the current long lines make the tree picture very
  difficult to grasp.  It would be better to manually tweak the output
  before posting the next draft - unless we can come up with some
  clever way to handle this in pyang.


o  Section 4.2.3

  You have a leaf:

            leaf certificate {
              if-feature ssh-x509-certs;
              type leafref {
                path "/kc:keychain/kc:private-keys/kc:private-key/"
                     + "kc:certificate-chains/kc:certificate-chain/"
                     + "kc:certificate";
              }

   This is a leafref that will actually contain the entire binary
   certificate.  This may be a bit awkward...  Unless you really meant
   kc:name as the last part of the path?  In either case, the
   description statement probably needs an update.

   Also, the path crosses two lists, which in general means that that
   the leafref may refer to multiple leafs.  But in this case it might
   be ok. 


o  Section 4.2.3

      leaf address {
        type inet:ip-address;
        description
         "The IP address of the interface to listen on. The SSH
          server will listen on all interfaces if no value is
          specified.";
      }

  What about "0.0.0.0" and "::"?  So a missing 'address' leaf should
  mean any ipv4 and ipv6 address on all interfaces?

      leaf port {
        type inet:port-number;
        mandatory true;  // will a default augmented in work?
        description
         "The local port number on this interface the SSH server
          listens on.";
      }

  I suggest you remove the mandatory statement, and then use refine to
  set the default port when the grouping is used; OR use refine to set
  mandatory true if no reasonable default exists.


o  Section 4.4.1

  You have:

       +--rw listen {(ssh-listen or tls-listen)}?

  Hmm, the design allows for other protocols than ssl and tls (just
  augment new cases).  But this if-feature statement essentially
  REQUIRE an implementation to _also_ support ssh or tls.  Is that
  intentional?


o  Section 5

  ietf-system-keychain vs. ietf-routing-key-chain

  Is it "keychain" or "key-chain"?


o  General remark.

  Unless it is too much of a burden, I think it would make sense to
  move the generic tls and ssh grouping models (and keychain) into a
  separate draft.   It might also be useful with corresponding
  groupings for ssh/tls clients (which you almost already have).



/martin


From nobody Tue Mar 29 14:12:59 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A28012D1DE for ; Tue, 29 Mar 2016 14:12:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xauXn635PM6I for ; Tue, 29 Mar 2016 14:12:56 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0794.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:794]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D73E12DB9E for ; Tue, 29 Mar 2016 13:47:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yszQ8bzTePtyUs2X5IUZjbFByRBfuxH7uoMrHCjI2RM=; b=ekkiO8JQyaQ/7gOHAdCEaMGGKCfxbfOfsOWjoZpnANM/GlQ3jlPQviBoe4Xqh+mHS0wfDLIb+u4i6t0JExofBxctWngpKgZl4PUK0Sk+jpTClFgeRcCfTy2x52Hciu2RJnWYyg2MgCzjShLglZE2wjDA6MeYd7jmWamTdGoJi4o=
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.447.15; Tue, 29 Mar 2016 20:47:05 +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.0447.023; Tue, 29 Mar 2016 20:47:05 +0000
From: Kent Watsen 
To: Martin Bjorklund , "netconf@ietf.org" 
Thread-Topic: [Netconf] mbj review of draft-ietf-netconf-restconf-server-model-09
Thread-Index: AQHRifX44uk/iivOuEmrTCpBJDXsvZ9woVIA
Date: Tue, 29 Mar 2016 20:47:05 +0000
Message-ID: 
References: <20160329.212556.1290892363387952983.mbj@tail-f.com>
In-Reply-To: <20160329.212556.1290892363387952983.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.160212
authentication-results: tail-f.com; dkim=none (message not signed) header.d=none;tail-f.com; dmarc=none action=none header.from=juniper.net;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.13]
x-ms-office365-filtering-correlation-id: 6fd4c816-9f83-482c-c8c7-08d3581349d0
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 5:lnyDzbzMKPA60D7ctCFPwxWRsUaov/5yxCcKzlyrufT7scznKeeXfo+csok8QNv9Ie7Cc48VlFs4VfsOV5Md/0ejpzuK3x/SSiGu/8YYAYeBSWDDTAo/z4WFuiIY9GmC2iiBu4vLAI0T19sW2iSgqg==; 24:z3GqNawm46I/IhrcLXH7gYQn9c4jAQG7khcvqh2pZMmvesZlvrBeU/1lCcZhweLvsReEjQqtHfDp5ExH4OXKx/vnwZ4AzYO/xVauB/4ONiM=
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)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; 
x-forefront-prvs: 0896BFCE6C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(3280700002)(86362001)(189998001)(83716003)(5002640100001)(102836003)(3846002)(6116002)(87936001)(83506001)(586003)(77096005)(11100500001)(5004730100002)(3660700001)(10400500002)(230783001)(2906002)(2501003)(106116001)(107886002)(99286002)(33656002)(66066001)(5008740100001)(36756003)(54356999)(2900100001)(19580395003)(19580405001)(4001350100001)(76176999)(2950100001)(50986999)(122556002)(82746002)(5001770100001)(92566002)(1220700001)(81166005)(1096002)(15975445007); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
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: 29 Mar 2016 20:47:05.4476 (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] mbj review of draft-ietf-netconf-restconf-server-model-09
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2016 21:12:58 -0000

DQpIaSBNYXJ0aW4sDQoNClRoYW5rcyBmb3IgeW91ciBzcGVlZHkgcmV2aWV3LiAgQSBxdWljayBy
ZWFkIHRocm91Z2ggeW91ciBjb21tZW50cywgSSBnZXQgdGhlIGltcHJlc3Npb24gdGhhdCB5b3Xi
gJlyZSBnZW5lcmFsbHkgaGFwcHkgYW5kLCB3aXRoIGV4Y2VwdGlvbiBvZiB0aGUgc3BsaXR0aW5n
IHRvIGRyYWZ0IGludG8gcGFydHMgKHdoaWNoIEkgcGxhbiB0byByYWlzZSBhcyBhbiBvcGVuIGlz
c3VlIG5leHQgd2VlayksIGl0IHNlZW1zIG1vc3RseSBmaXQtYW5kLWZpbmlzaCwgZm9yIHdoaWNo
IEnigJltIGdyYXRlZnVsLg0KDQpCVFcsIHRoZSByb3V0aW5nIG1vZHVsZeKAmXMgbmFtZSBpcyAi
aWV0Zi1yb3V0aW5nLWtleS1jaGFpbiIgLSBJIGRvbuKAmXQga25vdyB3aHkgdGhleSBkaWRu4oCZ
dCBjaG9vc2UgImlldGYtcm91dGluZy1rZXljaGFpbuKAnSwgYnV0IHRoYXTigJlzIHdoYXQgdGhl
eSBkaWQuDQoNCkkgd2lsbCBmb2xsb3ctdXAgd2l0aCBtb3JlIHNwZWNpZmljIHJlc3BvbnNlcyBs
YXRlci4NCg0KVGhhbmtzIGFnYWluLA0KS2VudA0KDQoNCg0KDQpPbiAzLzI5LzE2LCAzOjI1IFBN
LCAiTmV0Y29uZiBvbiBiZWhhbGYgb2YgTWFydGluIEJqb3JrbHVuZCIgPG5ldGNvbmYtYm91bmNl
c0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbWJqQHRhaWwtZi5jb20+IHdyb3RlOg0KDQo+SGksDQo+
DQo+SGVyZSBpcyBteSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLXNlcnZl
ci1tb2RlbC0wOS4NCj4NCj5vICBTZWN0aW9uIDMNCj4NCj4gIFRoZSBwaWN0dXJlIHNob3VsZCBz
LzxhdWdtZW50cz4vPHVzZXM+L2cNCj4NCj4NCj5vICBTZWN0aW9uIDQNCj4NCj4gIEl0IHdvdWxk
IGJlIHVzZWZ1bGUgd2l0aCBhIHJlZmVyZW5jZSB0byB0aGUgdGVybSBJRGV2SUQgaW4gdGhpcw0K
PiAgZG9jdW1lbnQuDQo+DQo+DQo+byAgU2VjdGlvbiA0LjENCj4NCj4gIE9MRDoNCj4NCj4gICBv
ICBBIGNvbmZpZ3VyYWJsZSBsaXN0IG9mIGxpc3RzIG9mIHRydXN0IGFuY2hvciBjZXJ0aWZpY2F0
ZXMuICBUaGlzDQo+ICAgICAgZW5hYmxlcyB0aGUgc2VydmVyIHRvIGhhdmUgdXNlLXNwZWNpZmlj
IHRydXN0IGFuY2hvcnMuICBGb3INCj4NCj4gIE5FVzoNCj4NCj4gICBvICBBIGNvbmZpZ3VyYWJs
ZSBsaXN0IG9mIHRydXN0IGFuY2hvciBjZXJ0aWZpY2F0ZXMuICBUaGlzDQo+ICAgICAgZW5hYmxl
cyB0aGUgc2VydmVyIHRvIGhhdmUgdXNlLXNwZWNpZmljIHRydXN0IGFuY2hvcnMuICBGb3INCj4N
Cj4gIC4uLiBidXQgd2hhdCBkb2VzICJ1c2Utc3BlY2lmaWMiIG1lYW4/DQo+DQo+DQo+byAgU2Vj
dGlvbiA0LjENCj4NCj4gIFRoZSB0ZXh0IHNheXM6DQo+DQo+ICAgbyAgQW4gUlBDIHRvIHJlcXVl
c3QgdGhlIHNlcnZlciB0byBsb2FkIGEgbmV3IHByaXZhdGUga2V5Lg0KPg0KPiAgV2hlbiBJIGZp
cnN0IHJlYWQgdGhpcywgSSBkaWRuJ3QgdW5kZXJzdGFuZCB3aGF0IHRoaXMgbWVhbnQuICBTZWUN
Cj4gIG1vcmUgYmVsb3cuDQo+DQo+DQo+byAgU2VjdGlvbiA0LjENCj4NCj4gIEkgdGhpbmsgdGhl
ICJzZW1pLWNvbmZpZ3VyYWJsZSIgZGVzaWduIGhhcyBzb21lIGlzc3Vlcy4gIFlvdSBoYXZlDQo+
ICBkZWZpbmVkIHNvbWUgYWN0aW9ucyB0aGF0IGFjdHVhbGx5IG1vZGlmaWVzIHRoZSBjb25maWd1
cmF0aW9uIG9mIHRoZQ0KPiAgc3lzdGVtLiAgSXQgaXMgbm90IGNsZWFyIHdoaWNoIGNvbmZpZyBk
YXRhc3RvcmUgaXMgbW9kaWZpZWQuDQo+ICBQcmVzdW1hYmx5IHJ1bm5pbmcuICBJbnRlcmFjdGlv
bnMgd2l0aCBsb2NraW5nIGFuZCBhY2Nlc3MgY29udHJvbA0KPiAgYXJlIG5vdCBkZXNjcmliZWQu
ICBBbHNvLCB0aGUgcmVzdWx0aW5nIGNvbmZpZ3VyYXRpb24gaXMgbm90DQo+ICBjb21wbGV0ZSAt
IGkuZS4sIHlvdSBjYW5ub3QgZG8gPGNvcHktY29uZmlnPiB0byBzYXZlL3Jlc3RvcmUgYQ0KPiAg
YmFja3VwLiAgVGhpcyBpcyBmaW5lLCBzaW5jZSB5b3UgcmVhbGx5IGRvbid0IHdhbnQgdG8gZXhw
b3NlIHRoZQ0KPiAgcHJpdmF0ZSBrZXlzIGluIHRoZSBjb25maWcgYmFja3VwLiAgQnV0IHNvbWUg
ZGlzY3Vzc2lvbiBpcyBuZWVkZWQNCj4gIGFyb3VuZCB0aGlzIHN1YmplY3QuICBXaGF0IGhhcHBl
bnMgaWYgSSBnZW5lcmF0ZSBhIHByaXZhdGUga2V5IHdpdGgNCj4gIHlvdXIgYWN0aW9uLCBiYWNr
dXAgdGhhdCBjb25maWcgYW5kIHRoZW4gcmVzdG9yZSBpdD8gIFdoYXQgaGFwcGVucw0KPiAgd2l0
aCBjb25maWcgdGhhdCBoYXMgcmVmZXJlbmNlcyB0byBzdWNoIGEga2V5Pw0KPg0KPiAgT25lIHdh
eSB0byBhdm9pZCB0aGF0IHRoZSBhY3Rpb25zIG1vZGlmeSB0aGUgY29uZmlndXJhdGlvbiBjb3Vs
ZCBiZQ0KPiAgdG8gbW92ZSB0aGVtIGludG8gdGhlIHByaXZhdGUta2V5IGxpc3QuICBPbmUgZHJh
d2JhY2sgaXMgdGhhdCB0d28NCj4gIG9wZXJhdGlvbnMgYXJlIG5lZWRlZCBpbiBvcmRlciB0byBj
cmVhdGUgYSAodXNhYmxlKSBrZXkgLSBmaXJzdA0KPiAgY3JlYXRlIHRoZSBjb25maWcgaW4gcnVu
bmluZywgdGhlbiBjYWxsIHRoZSBhY3Rpb24uDQo+DQo+ICBBbm90aGVyIG9wdGlvbiBtaWdodCBi
ZSB0byBtb2RlbCB0aGUga2V5cyBhcyBjb25maWcgZmFsc2UgZGF0YS4NCj4gIFRoaXMgYWxzbyBz
b2x2ZXMgdGhlIHByb2JsZW0gdGhhdCBzb21lIGtleXMgKGluIFRQTSBmb3IgZXhhbXBsZSkNCj4g
IGFyZSBub3QgZGVsZXRhYmxlLg0KPg0KPg0KPm8gIFNlY3Rpb24gNC4xLjMNCj4NCj4gIE9MRDoN
Cj4NCj4gIGltcG9ydCBpZXRmLXlhbmctdHlwZXMgeyAgICAgLy8gUkZDIDY5OTENCj4gICAgcHJl
Zml4IHlhbmc7DQo+ICB9DQo+DQo+ICBORVc6DQo+DQo+ICBpbXBvcnQgaWV0Zi15YW5nLXR5cGVz
IHsNCj4gICAgcHJlZml4IHlhbmc7DQo+ICAgIHJlZmVyZW5jZSAiUkZDIDY5OTE6IENvbW1vbiBZ
QU5HIERhdGEgVHlwZXMiOw0KPiAgfQ0KPg0KPiAgKHNhbWUgZm9yIHRoZSBvdGhlciBtb2R1bGVz
KQ0KPg0KPg0KPm8gIFNlY3Rpb24gNC4xLjMNCj4NCj4gIEkgdGhpbmsgdGhlICJhbGdvcml0aG1z
IiB0eXBlZGVmIHNob3VsZCBiZSBjYWxsZWQgImFsZ29yaXRobSIuICBCdXQNCj4gIGFjdHVhbGx5
LCBpdCBzaG91bGQgcHJvYmFibHkgaGF2ZSBhIG1vcmUgZGVzY3JpcHRpdmUgbmFtZQ0KPiAgImFs
Z29yaXRobSIgaXMgcmF0aGVyIGdlbmVyaWMuLi4NCj4NCj4gIEFsc28sIHRoaXMgaXMgYW4gZml4
ZWQgZW51bWVyYXRpb24uICBTZWN0aW9uIDUgc2F5czogDQo+DQo+ICAgIEluIGFkZGl0aW9uYWwN
Cj4gICAgYWxnb3JpdGhtcyBhcmUgbmVlZGVkLCB0aGV5IE1BWSBiZSBhdWdtZW50ZWQgaW4gYnkg
YW5vdGhlciBtb2R1bGUsDQo+DQo+ICBbbm90ZTogcy9Jbi9JZi9dDQo+DQo+ICBZb3UgY2FuJ3Qg
cmVhbGx5IGF1Z21lbnQgaW4gYWRkaXRpb25hbCBlbnVtcy4gIFlvdSdkIGhhdmUgdG8gYXVnbWVu
dA0KPiAgYW4gYWRkaXRpb25hbCBsZWFmIG9mIHNvbWUgb3RoZXIgdHlwZS4NCj4NCj4gIFdoYXQg
aGFwcGVucyB0byB0aGUgImFsZ29yaXRobSIgbGVhZiB3aGVuIEkgbG9hZCBhIGtleSB3aXRoIHlv
dXINCj4gIGFjdGlvbj8gIFdpbGwgb3RoZXIgYWxnb3JpdGhtcyBiZSByZWplY3RlZD8NCj4NCj4g
IElmIHlvdSBrZWVwIHRoZSBlbnVtcywgYSByZWZlcmVuY2Ugc3RhdGVtZW50IGZvciBlYWNoIGVu
dW0gd291bGQgYmUNCj4gIHVzZWZ1bC4NCj4NCj4NCj5vICBTZWN0aW9uIDQuMi4xDQo+DQo+ICBJ
IHdhcyBjb25mdXNlZCBieSB0aGUgY29udGFpbmVycyB0aGF0IHRoZSBSRkMgZWRpdG9yIGFyZSBz
dXBwb3NlZCB0bw0KPiAgcmVtb3ZlLiAgVGhlbiBJIHJlYWxpemVkIHRoZXkgZXhpc3QgZHVlIHRv
IGEgZGVmaWNpZW5jeSBpbiBweWFuZy4uLg0KPiAgU28gSSBmaXhlZCBweWFuZzsgeW91IGNhbiBu
b3cgcGFzcyAtLXRyZWUtcHJpbnQtZ3JvdXBpbmdzIChvbmx5IGluDQo+ICAxLjEgYnJhbmNoKS4N
Cj4NCj4gIEkgZG9uJ3QgaGF2ZSBhIHNvbHV0aW9uIGZvciB0aGUgbG9uZyBsZWFmcmVmcyB0aG91
Z2guICBCdXQgaW4gYW55DQo+ICBjYXNlLCBJIHRoaW5rIHRoZSBjdXJyZW50IGxvbmcgbGluZXMg
bWFrZSB0aGUgdHJlZSBwaWN0dXJlIHZlcnkNCj4gIGRpZmZpY3VsdCB0byBncmFzcC4gIEl0IHdv
dWxkIGJlIGJldHRlciB0byBtYW51YWxseSB0d2VhayB0aGUgb3V0cHV0DQo+ICBiZWZvcmUgcG9z
dGluZyB0aGUgbmV4dCBkcmFmdCAtIHVubGVzcyB3ZSBjYW4gY29tZSB1cCB3aXRoIHNvbWUNCj4g
IGNsZXZlciB3YXkgdG8gaGFuZGxlIHRoaXMgaW4gcHlhbmcuDQo+DQo+DQo+byAgU2VjdGlvbiA0
LjIuMw0KPg0KPiAgWW91IGhhdmUgYSBsZWFmOg0KPg0KPiAgICAgICAgICAgIGxlYWYgY2VydGlm
aWNhdGUgew0KPiAgICAgICAgICAgICAgaWYtZmVhdHVyZSBzc2gteDUwOS1jZXJ0czsNCj4gICAg
ICAgICAgICAgIHR5cGUgbGVhZnJlZiB7DQo+ICAgICAgICAgICAgICAgIHBhdGggIi9rYzprZXlj
aGFpbi9rYzpwcml2YXRlLWtleXMva2M6cHJpdmF0ZS1rZXkvIg0KPiAgICAgICAgICAgICAgICAg
ICAgICsgImtjOmNlcnRpZmljYXRlLWNoYWlucy9rYzpjZXJ0aWZpY2F0ZS1jaGFpbi8iDQo+ICAg
ICAgICAgICAgICAgICAgICAgKyAia2M6Y2VydGlmaWNhdGUiOw0KPiAgICAgICAgICAgICAgfQ0K
Pg0KPiAgIFRoaXMgaXMgYSBsZWFmcmVmIHRoYXQgd2lsbCBhY3R1YWxseSBjb250YWluIHRoZSBl
bnRpcmUgYmluYXJ5DQo+ICAgY2VydGlmaWNhdGUuICBUaGlzIG1heSBiZSBhIGJpdCBhd2t3YXJk
Li4uICBVbmxlc3MgeW91IHJlYWxseSBtZWFudA0KPiAgIGtjOm5hbWUgYXMgdGhlIGxhc3QgcGFy
dCBvZiB0aGUgcGF0aD8gIEluIGVpdGhlciBjYXNlLCB0aGUNCj4gICBkZXNjcmlwdGlvbiBzdGF0
ZW1lbnQgcHJvYmFibHkgbmVlZHMgYW4gdXBkYXRlLg0KPg0KPiAgIEFsc28sIHRoZSBwYXRoIGNy
b3NzZXMgdHdvIGxpc3RzLCB3aGljaCBpbiBnZW5lcmFsIG1lYW5zIHRoYXQgdGhhdA0KPiAgIHRo
ZSBsZWFmcmVmIG1heSByZWZlciB0byBtdWx0aXBsZSBsZWFmcy4gIEJ1dCBpbiB0aGlzIGNhc2Ug
aXQgbWlnaHQNCj4gICBiZSBvay4gDQo+DQo+DQo+byAgU2VjdGlvbiA0LjIuMw0KPg0KPiAgICAg
IGxlYWYgYWRkcmVzcyB7DQo+ICAgICAgICB0eXBlIGluZXQ6aXAtYWRkcmVzczsNCj4gICAgICAg
IGRlc2NyaXB0aW9uDQo+ICAgICAgICAgIlRoZSBJUCBhZGRyZXNzIG9mIHRoZSBpbnRlcmZhY2Ug
dG8gbGlzdGVuIG9uLiBUaGUgU1NIDQo+ICAgICAgICAgIHNlcnZlciB3aWxsIGxpc3RlbiBvbiBh
bGwgaW50ZXJmYWNlcyBpZiBubyB2YWx1ZSBpcw0KPiAgICAgICAgICBzcGVjaWZpZWQuIjsNCj4g
ICAgICB9DQo+DQo+ICBXaGF0IGFib3V0ICIwLjAuMC4wIiBhbmQgIjo6Ij8gIFNvIGEgbWlzc2lu
ZyAnYWRkcmVzcycgbGVhZiBzaG91bGQNCj4gIG1lYW4gYW55IGlwdjQgYW5kIGlwdjYgYWRkcmVz
cyBvbiBhbGwgaW50ZXJmYWNlcz8NCj4NCj4gICAgICBsZWFmIHBvcnQgew0KPiAgICAgICAgdHlw
ZSBpbmV0OnBvcnQtbnVtYmVyOw0KPiAgICAgICAgbWFuZGF0b3J5IHRydWU7ICAvLyB3aWxsIGEg
ZGVmYXVsdCBhdWdtZW50ZWQgaW4gd29yaz8NCj4gICAgICAgIGRlc2NyaXB0aW9uDQo+ICAgICAg
ICAgIlRoZSBsb2NhbCBwb3J0IG51bWJlciBvbiB0aGlzIGludGVyZmFjZSB0aGUgU1NIIHNlcnZl
cg0KPiAgICAgICAgICBsaXN0ZW5zIG9uLiI7DQo+ICAgICAgfQ0KPg0KPiAgSSBzdWdnZXN0IHlv
dSByZW1vdmUgdGhlIG1hbmRhdG9yeSBzdGF0ZW1lbnQsIGFuZCB0aGVuIHVzZSByZWZpbmUgdG8N
Cj4gIHNldCB0aGUgZGVmYXVsdCBwb3J0IHdoZW4gdGhlIGdyb3VwaW5nIGlzIHVzZWQ7IE9SIHVz
ZSByZWZpbmUgdG8gc2V0DQo+ICBtYW5kYXRvcnkgdHJ1ZSBpZiBubyByZWFzb25hYmxlIGRlZmF1
bHQgZXhpc3RzLg0KPg0KPg0KPm8gIFNlY3Rpb24gNC40LjENCj4NCj4gIFlvdSBoYXZlOg0KPg0K
PiAgICAgICArLS1ydyBsaXN0ZW4geyhzc2gtbGlzdGVuIG9yIHRscy1saXN0ZW4pfT8NCj4NCj4g
IEhtbSwgdGhlIGRlc2lnbiBhbGxvd3MgZm9yIG90aGVyIHByb3RvY29scyB0aGFuIHNzbCBhbmQg
dGxzIChqdXN0DQo+ICBhdWdtZW50IG5ldyBjYXNlcykuICBCdXQgdGhpcyBpZi1mZWF0dXJlIHN0
YXRlbWVudCBlc3NlbnRpYWxseQ0KPiAgUkVRVUlSRSBhbiBpbXBsZW1lbnRhdGlvbiB0byBfYWxz
b18gc3VwcG9ydCBzc2ggb3IgdGxzLiAgSXMgdGhhdA0KPiAgaW50ZW50aW9uYWw/DQo+DQo+DQo+
byAgU2VjdGlvbiA1DQo+DQo+ICBpZXRmLXN5c3RlbS1rZXljaGFpbiB2cy4gaWV0Zi1yb3V0aW5n
LWtleS1jaGFpbg0KPg0KPiAgSXMgaXQgImtleWNoYWluIiBvciAia2V5LWNoYWluIj8NCj4NCj4N
Cj5vICBHZW5lcmFsIHJlbWFyay4NCj4NCj4gIFVubGVzcyBpdCBpcyB0b28gbXVjaCBvZiBhIGJ1
cmRlbiwgSSB0aGluayBpdCB3b3VsZCBtYWtlIHNlbnNlIHRvDQo+ICBtb3ZlIHRoZSBnZW5lcmlj
IHRscyBhbmQgc3NoIGdyb3VwaW5nIG1vZGVscyAoYW5kIGtleWNoYWluKSBpbnRvIGENCj4gIHNl
cGFyYXRlIGRyYWZ0LiAgIEl0IG1pZ2h0IGFsc28gYmUgdXNlZnVsIHdpdGggY29ycmVzcG9uZGlu
Zw0KPiAgZ3JvdXBpbmdzIGZvciBzc2gvdGxzIGNsaWVudHMgKHdoaWNoIHlvdSBhbG1vc3QgYWxy
ZWFkeSBoYXZlKS4NCj4NCj4NCj4NCj4vbWFydGluDQo+DQo+X19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCj5OZXRjb25mIG1haWxpbmcgbGlzdA0KPk5ldGNv
bmZAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNv
bmYNCg==


From nobody Wed Mar 30 03:39:37 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A46612D10D for ; Wed, 30 Mar 2016 03:39:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.464
X-Spam-Level: *
X-Spam-Status: No, score=1.464 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yq3YydFJp9lT for ; Wed, 30 Mar 2016 03:39:34 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0106.outbound.protection.outlook.com [104.47.2.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B7C712D507 for ; Wed, 30 Mar 2016 03:39:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TOjstE6YP7JzRzTz1rQfm/L1K5lTKVlnBfs5JYQs2RY=; b=DNdsNPTAam0IdKaqLA4nYtrZw/nbNOPwvqPKATmavaTCkaR9tiPwJMkU1g9+QDbuAAF8dZ1sixHwKddcUJmk+FlQXYWIlIwFTRKFQMV7Xy6zt7uD0i7y4MxKRQi+Y4mIn+PSno3mKJccahxwhbTSfNG5/lR3MdxAEdwhPcds2As=
Authentication-Results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=btconnect.com;
Received: from pc6 (81.132.199.159) by DB5PR07MB1622.eurprd07.prod.outlook.com (10.166.12.149) with Microsoft SMTP Server (TLS) id 15.1.453.11; Wed, 30 Mar 2016 10:39:31 +0000
Message-ID: <002001d18a70$0e7b8000$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Andy Bierman , Netconf 
Date: Wed, 30 Mar 2016 11:36:37 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [81.132.199.159]
X-ClientProxiedBy: DB4PR06CA0024.eurprd06.prod.outlook.com (10.160.40.152) To DB5PR07MB1622.eurprd07.prod.outlook.com (10.166.12.149)
X-MS-Office365-Filtering-Correlation-Id: 01779214-51e2-40e1-0995-08d3588793ff
X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 2:OYGl+5vXGodPErIr400V1ejwewzBHJGXS3LEJNu3kaKQzfgTHpnOcsLRHugVTfZlbL8rGiAa8XRZSGWoY9RWMvLlVftK+hT5HEU3l8gaIUDotB6rCNLHd2fqCZVK5lTC160Cw+RBqrVvmJDnzr8j9yxBpxw1aBROtGBN0+NZQkYSTRSD+gmSTyMUbGWPuYwE; 3:KBTITEx3OTIJWVvxvXqHqmziZ2Tx7ZsOFZpAHAuZUw9Yrp7EZ4fbNJFSfx2hsOmAAEGiNKGeyWTnw1YpHZINcmOR3oXOtuUtgNwZIXChJsCzLTbeDtIm450ohul7urUs; 25:4/xeFggxEaKc6w+iqb3RAOQs973b5H4aTiMU8W4QsPRJonWrP3YPbF1rNmpLKe/0b7OtNF0OQva2oyWuTASbrbwtYmHtyMjpT/nB52GgdnXqN7H9utR6vKUbyKSJAayzmjuEKgrJ8+byG9ZwWc7e8FUC87BMgLFoSWIrg5t6CfzHrtuMTAKW4lzh4V1qpdFQoYTuyk9CI7u7d+pKGOEHlf2gpNY3QR791lYkGGE9oimKNo71Ce21rw8DDOJHwCESablgN+okvt9qCDznuEopZ10WZ446rnqsETEN3Fb/oZSkZ06FhffraXcUPwbP+/voFryffyunq6JdwLSAA3Ytcv8Q5r0PPybu80RU5tV+uiQ=
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR07MB1622;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DB5PR07MB1622; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1622; 
X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 4:vmXDdPrEaj70EQJdI/dzX5nnoOaQtEu6KXR+dxXKcUQCLIQhmjZTz+lyunfv7wHaL/b/uWcdKlXGVCesoGi2usRHYHQB+hlnbWOBgBfiguiasbKfHpWipS4jaf1xAWPbeV+ajBXMZiFB7KtHwmkZCBLnl6mOj2WBE88HYVyasaQnXcb1hNy31MER8PfTOjY9AztNTi5aHkqrscY4s5puprMvMclrzj4T3ZXphQfbSBNGuWpYd1fsErt+mfE9qTQaHLR8+E/SKckEVyI8CgeAkjWFod/odu9at8lhBFREXllTG882qI5vAmXzQ7F0cKfIr8cs+PcM4OjfW3pY9EvcDZNYYtwNXkK/vBF+94udy0AjAoppc5q0N+ppzgIYxI89
X-Forefront-PRVS: 08978A8F5C
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(13464003)(377454003)(5820100001)(5001770100001)(81816999)(230700001)(107886002)(3846002)(50986999)(81166005)(586003)(6116002)(189998001)(81686999)(23676002)(1556002)(42186005)(1096002)(66066001)(5004730100002)(2906002)(61296003)(84392002)(44716002)(33646002)(19580405001)(86362001)(5008740100001)(92566002)(47776003)(19580395003)(77096005)(50466002)(50226001)(62236002)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1622; H:pc6; FPR:; SPF:None; MLV:sfv;  LANG:en; 
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjVQUjA3TUIxNjIyOzIzOnlFeU80bkhqTGVHUWdCMnYxZmdtTGpEU1Az?= =?utf-8?B?eGNDOUI0bjJRaXBMbTlMU3NzV24xaWdEbDZMelJ5ajZHVWVld285ckpTOU50?= =?utf-8?B?dmh3ZU1iMXdSNUNBSEpSTFl2MmsvSXhkZ0hBYmpiRUVuQ21pRm1YTDllVnlI?= =?utf-8?B?L3pyQ1ZJeXpxQVJ5L2w0a3poUnNwbXcvcFBBY2NtQmJubFJONWxoU1JnT1dB?= =?utf-8?B?dGlSZjdocVAvZk9VaXFibUZRTFFyaXN0Z3R1VmNkSUEyNjFJSXl0ZVNmSzJK?= =?utf-8?B?ZHVrZEY1bzJ6RGtsQlZQZFNPamZrVmc0bnVsK3J0RVhxcGtiWStHZkhnMVQv?= =?utf-8?B?QW1LVDVOL0c1OW9YY25BeS9BRXlGalR6Mm5hdHRGY0MvMGpPb2ZNSVVadzU2?= =?utf-8?B?MCtsdTNJQk5oSGQ5bHI2NzF2cXdDYUdmeFNnZmpUcFNwMlFhSU1JSWFQcW5a?= =?utf-8?B?bldPN09zYkpPMmlZMUJVZFJLYXlDd3dPanpIdllPUUN4QmFlT3NuTTFXTzZE?= =?utf-8?B?OHprNEJuT0Y2TW5pY2s5alJSckI5S3ozckdLYytMamVKTDFJVmRYS3BRZUp0?= =?utf-8?B?UTErU2I0aVRnMEtVeGxSb2FwbW0vL3JOTkpwNi80T1p0K090SE80LzdGUUVp?= =?utf-8?B?Y2ptRnF0TTdPblZQMTdXb1cvSzJZR3R5SW56TExZd2d5eUgzK1lqNW5DZGl2?= =?utf-8?B?dWtZWngzYm1leUNQcTViMVo5bnN0SWxWTnRrSXQwa2lKZVQ3cmRiTUtkOTNQ?= =?utf-8?B?bkcxaGMrTVdrNFprYUVWWEM2Q1o5WjNqTXVHMHFzZTNSQlV6YVQzZjV0K09v?= =?utf-8?B?cm5RQUhuZWNsWDdUY0lNa2dFUkF1VDlvUUlpRnFiWkY3V0IyUWJQZkdLcnl5?= =?utf-8?B?UkJ4cDg0VTdzWmJQY2JvWDhyWVRsa3A3Wk02dUxmNnhzaVBYQjJQVmtsT3Rw?= =?utf-8?B?cVpibXpaR01CbHlHZUU5b0Z0QnhrUlM1OTNnTWEwazNFZmxKNXdkMXdka2VQ?= =?utf-8?B?cCswK2xiclU5aVJQS3IzRnpVY0FmeEVmb1dFbWF6bE1adWdjUlJNK0FaUk1w?= =?utf-8?B?Y09hV1hCUVNsSzFkc2dwL2NWdzZjUlNuZzgrc0pzbGdPWmhhTXRESmlBSXNh?= =?utf-8?B?QmJ1aGwvN1ZiVlBvQTM4TUNWQXViTWplRVB1TzNOOHZpTFpUeDZqaVZ0d3pv?= =?utf-8?B?UDlld2JPRTRwcEJyeHhEU0hXcTFXMWhwRXlWVFpIdi8zZ05iY2EydVFxdERZ?= =?utf-8?B?NDRDKytBbk12eTI2eGVyUFMwOVFvTEpBOXJzUVFDK3kzemVQLzdjR3FNVS9J?= =?utf-8?B?SG5VR1VnODMxd3RHbFp0SGhUdkFCa2l2OFJ3MWNNK2F3ZTgvM0d3N1FFdmp2?= =?utf-8?B?RS8rS282M0E3dndxK25PdDhWLzJjcmZFYXhBNFp3PT0=?=
X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 5:NqELmHqt0IuxpM0UQ7IwyRGqeH40DlWa/dgz2M9f5rH5VCuIjO6vtmTphEyZxDXqMU8EWxPh6C6pesPJq1ndCHoHzcPfZK1A3XYlYs26RjioblHJVHDVu+PWlbl+9Wp2e8ylP0cGqZCn6X1l5GqMzQ==; 24:DYrJ9B1ULgU7Fulm7WjuV2cV31g+gog4oJJUxLD5brtnnC9Q166sQFxvpfxlNth1NXPY3vrM6Bw7ELhhAL43Zt4fqtuiVBzAfnhiI6sF9dA=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Mar 2016 10:39:31.4915 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1622
Archived-At: 
Subject: Re: [Netconf] RESTCONF-10 draft clarifications
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Mar 2016 10:39:36 -0000

Some minor comments on s.4

s4.5
 /MUST not/MUST NOT/

s.1.1.3 ' ordered-by user '
s.4.4.1 '  "ordered-by" user'
s.4.8    ' user-ordered  '
s.4.8.4 ' user-ordered '
           ' ordered by the user.  '
s4.8.5  ' user ordered '
           ' ordered by the  user.  '

I think these are all the same in which case I would prefer a single
term; the defined one is probably best

s 4.4
' If the server implements  any YANG module that contains a
configuration data node that is   "ordered-by" user, then the "insert"
and "point" query parameters MUST be supported.  If not, then these
parameters not applicable. '

seems at odds with s.4.8.4

'  The "insert" query parameter MUST be supported by the server. '

likewise for "point" in s.4.8.5

Tom Petch


----- Original Message -----
From: "t.petch" 
To: "Andy Bierman" ; "Netconf" 
Sent: Thursday, March 24, 2016 5:18 PM
Subject: [Netconf] RESTCONF-10 draft clarifications


From nobody Thu Mar 31 19:25:22 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397E812D106 for ; Thu, 31 Mar 2016 19:25:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7EfULRRkwLS for ; Thu, 31 Mar 2016 19:25:18 -0700 (PDT)
Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::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 BF6FF12D1B8 for ; Thu, 31 Mar 2016 19:25:16 -0700 (PDT)
Received: by mail-lb0-x22a.google.com with SMTP id vo2so63464390lbb.1 for ; Thu, 31 Mar 2016 19:25:16 -0700 (PDT)
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; bh=j7FPrsnK/QoGJ01lt0srJfbprObphxXEgC8mWfY09Eg=; b=BLw28x+dHG5roWU8Lq6Iab4eQkvNe/uz9ty5xJw7ExVNBhslfGLHJODv521PzXBok8 o+J4bscTs4Xa00p3tL4iM2QAPuQPtg7zgZ/9Yt4q+H/LVzxSLzMBlv6LnonUsKjVxrcA 18QHMFVLmQSih/D4DSHzWI7pSSfHY0bg4Rauvw7SrFUl6N26l1g1VrmoWoMwrc30DVhq ojum5TRLketJi7S+aeHewy360CZY23fAAIKKmH5q+1ZShJgwHzVwRJv2EXzK8yEo/BFg CQ2FD1Patd7c09e6KiHpJyILPZAsoQRtqSITV7hg490VcOissay7P1ET0oWvF+js0Ya/ 3XSw==
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; bh=j7FPrsnK/QoGJ01lt0srJfbprObphxXEgC8mWfY09Eg=; b=hHkB4SyaG8a80TpNUpYZBoQ3k/W83RXkVjJUtEQq/ZuqmyVQ7Sfwf/c4TGjrj51zQf 80zrsCUiso13vHGK4nwnj9b0a0ZJW87XGPdwijZ6BdenXCr/9BzvTXzLYzVXN9xVrpZW xxYJCOTypx9l5a59JxJ6sMjGFyzxO1Pt19zntt3q2mCmCWLl3rQHABhHyUu1iW7Ui6F/ ZX0J0hvTgafUl7v5aXD+euVyWrZEIx+imkMNq4Y1t/oMeDerUWkr64b6YY8wDp6Bxtnn r66091FfNAmprQTI0DjeK/oT0on5J9NAmUYA32Gbj7x/l8mNRoK3WY2Gizb2rAqNjT9M O/jw==
X-Gm-Message-State: AD7BkJJOGXEE6OKRlIhzDgzosEo76uaYyHhspTF30fEgashOxaZMgVFL5OpWe1i01GNkb9yuTfltlOZ8emitdA==
MIME-Version: 1.0
X-Received: by 10.112.147.101 with SMTP id tj5mr1242948lbb.119.1459477514753;  Thu, 31 Mar 2016 19:25:14 -0700 (PDT)
Received: by 10.112.135.97 with HTTP; Thu, 31 Mar 2016 19:25:14 -0700 (PDT)
Date: Thu, 31 Mar 2016 19:25:14 -0700
Message-ID: 
From: Andy Bierman 
To: Netconf , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7b3a8bd2d32ca8052f631641
Archived-At: 
Subject: [Netconf] yangcli-pro now free
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Apr 2016 02:25:19 -0000

--047d7b3a8bd2d32ca8052f631641
Content-Type: text/plain; charset=UTF-8

Hi,

The yangcli-pro NETCONF client program is now free to use
in binary form.  It is supported on MacOSX and various Linux platforms.


Info:
https://www.yumaworks.com/yangcli-pro/


Files:
https://www.yumaworks.com/pub/



Andy

--047d7b3a8bd2d32ca8052f631641
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

The yangcli-pro NETCONF client prog=
ram is now free to use
in binary form.=C2=A0 It is supported on M=
acOSX and various Linux platforms.


=
Info:


Andy



--047d7b3a8bd2d32ca8052f631641--