From nobody Tue Sep 1 06:33:12 2020 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 D05183A07F2 for ; Tue, 1 Sep 2020 06:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 zNf3UsxVysOe for ; Tue, 1 Sep 2020 06:33:08 -0700 (PDT) Received: from mail.swisscom.com (mailout110.swisscom.com [138.188.166.110]) (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 A260F3A07E3 for ; Tue, 1 Sep 2020 06:33:06 -0700 (PDT) Received: by mail.swisscom.com; Tue, 1 Sep 2020 15:32:49 +0200 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_116867_249589249.1598967169237" X-Mailer: Totemo_TrustMail_(Notification) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CA6+6JZ7H+g6jgffMdZDV2nMidD57IoWRADflVhz2eieFbhwgWxpansj76Dl4z7cdwGYobr537f4POh08YgvDi/rhPgVg8TLNabdkYZ7OLec5WNx6ZZU5AwcI9nde4cO4d4GKPcngNOfL3JDe5kCpMST/VC5kl7eIMcpn7z8ov6cHA+83BgfbjWadjpXjY9cqUSNWXacoJjZMQLmVByMbO+ad5qQ4OsB++lAuGeoq0pzr2WVtTERePXzqWCk+ZSL0CeqqQKcYQwkzYBAWZhvWGK50wVEeEIPvlLdKBSU5HIjkBWZNK62T8go3p19cmRDlmdpf2cJ9dzrSUU5ThDgRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GnFm0af1C2m3XVMmLB0hIs07yqQf6xG4GCe3nhZtXIs=; b=bumfu+IskqrEvInm9LUfp1xZ9459TlmjSgixHsnWSuEuGiiZ8kgme4srRrkI2QqHnRQGekkzRMPCda5XXAUqsormFPpyP7vdMuzRCrYZy1mVAqujbQGAtlYaW6qfGeKg3YlJEczwO8M3760VAY4mC26u659Q7+VdMnT52dgElc+XxRYTF1vx+XYNd170qmtvpadZVq+yAb3cnYRE7zSO0IO8/R+IrqLjJ1/WEziUAcBVttm43w+WZNCbZw7MRVA10LQwzJZqhgbrdoluBZYzD9P3moOSQqxgp0yT8Go1UC6BLc5A5i4+wB/Od7woqsdZ/TD4HCHEqr7LwthAoWJAvA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=swisscom.com; dmarc=pass action=none header.from=swisscom.com; dkim=pass header.d=swisscom.com; arc=none From: To: , CC: , Thread-Topic: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif Thread-Index: AQHWdWVt0mBLbRaES02VUjy2aRVTDKk+cCwAgAunzwCAAJn6AIAAjDyAgAEjdYCAAOckAIAFR84AgAFNIXA= Date: Tue, 1 Sep 2020 13:32:45 +0000 Message-ID: References: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@us-east-1.amazonses.com> <01000173ca90a8d5-78b55d80-3a92-406a-8544-594dbe223735-000000@email.amazonses.com> <07b991b1e32347b58ae4ef968cdffc7f@huawei.com> <7b77f6ff39d4430aa549c9b53b902dde@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Enabled=True; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Owner=Thomas.Graf@swisscom.com; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SetDate=2020-09-01T13:32:43.7864541Z; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Name=C2 General; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Application=Microsoft Azure Information Protection; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ActionId=caea49c8-c8c8-40ba-a5ae-c56ba31bd76a; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Extended_MSFT_Method=Automatic authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none; yumaworks.com; dmarc=none action=none header.from=swisscom.com; x-originating-ip: [138.188.143.90] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0bc311a9-5ae6-4a00-f89e-08d84e7b82a1 x-ms-traffictypediagnostic: ZRAP278MB0112: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mnuB1DTsHnnHoI+yS+1WJIBmOQgX+JuHGYX+eIOUph3LwHHypGuLz7S7DNc7TppG/u3WiOS+upIVnMe1LwitanwmJ5HCUqo6q7WLdESKHZy2C6FLanJdTE2nOJ+CQkkigxOxbPFL8CG1Weqxuq6IVx6A9HkEzW+NXgOR1BI1xdZ4YAcbG+nsL7TVVI3d1xK7RPlpq5FkuC4xqEvtTK+tv8LzrKXQxI41jsoyJ+uPVluw5R2a7ojI4lK7bPACdiyez8tu+fOrft7RQGj8MqOwZTQNC/sXnNM1OaLNOZOzODyGsFsTvhq2s9vJiCHoAwSQqVoJ0aVBuzV8DyVSRal3vtZRoBNr39x/R4PtrVhGt1/6QHBZUmBPFELXqtOtH3+nzYjK3zvLkIDiJyRxZWzTfg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:ZRAP278MB0125.CHEP278.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(376002)(39860400002)(366004)(346002)(55016002)(5660300002)(966005)(54906003)(8936002)(316002)(10290500003)(478600001)(8676002)(9686003)(10300500001)(110136005)(33656002)(76116006)(66476007)(64756008)(52536014)(26005)(86362001)(66556008)(83380400001)(6506007)(186003)(71200400001)(66446008)(4326008)(53546011)(7696005)(66946007)(2906002)(166002)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: DFIqpOA+TCZBEcyYPG2/XUehxElfEUu+YCvezOEe8+3y3uSkFArVJ8EPTwhS1GyX4v07FeDsWCYfRc8jlR+HSy8knoGnArfvVhId6OP98Fa1ufVaoZozo8ws6ilVlgKGZtz5vgFCMFEmidQgcBBT7SC7vdCPkq4LQ93fD4lRInKSMJZ1F20EqLSh0UJBS25xnEYNnGNdgqhx69Mo9AgCRgytF0c6Fj3P5QMiTvAw8a4n+LOzMuh9LR7uIKMTNUDWaLulCMjrq2dCO8spkTx0JFq7ks09B+3uhIAkuCNyECO354vtEX6wA5InK2WSwQpkX/qiWrRyYk9c1KGscA2zdfKoS19pjPlJj+vRdUT4qn4o7cfd7wneVhEJg6XU4wyXoX4gRz8Rf1nM/8HDiuAPLb4zptXhhudp3+do9AphoCoEOIiusxIBC+r1kArhhvViWRfMAQdq8+ncESc9caqePL8IoXs8X2y6/GdJdXK+nHcgZJYEX5WTFoCTus5Q02puEt6laQSBUc57jXsyZaqPt2t/hdTZX8wBgR1qqFAQlPfzjgD8CuCvJHznMxqC3aglRMWd3FCJKKsb039ye0xLXR+Ivn15xBv+dLTTtIybz1YyY67IK4aJnCvBi2+Qt+Gg8QUhFRxyfAdVYKUoXWaFpw== x-ms-exchange-transport-forked: True X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: ZRAP278MB0125.CHEP278.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 0bc311a9-5ae6-4a00-f89e-08d84e7b82a1 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2020 13:32:45.1675 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 364e5b87-c1c7-420d-9bee-c35d19b557a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: v2e1EMy77D1bIKvWzcNP8yKL1bl4R1TT5OfTOX0kkx6wTOU7Mg2cDYqDp8/Py42D49KnC/g39iTvxTqcX9Q9Hc797/fpCzfRhS9NjO5peiE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: ZRAP278MB0112 X-OriginatorOrg: swisscom.com X-CFilter-Loop: Reflected X-Trustmail: processed Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 13:33:11 -0000 ------=_Part_116867_249589249.1598967169237 Content-Type: multipart/alternative; boundary="_000_ZRAP278MB01258EEC7E4161368EACE35C892E0ZRAP278MB0125CHEP_" Content-Language: en-US --_000_ZRAP278MB01258EEC7E4161368EACE35C892E0ZRAP278MB0125CHEP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andy, Thanks for the feedback. I think I understand in which direction your quest= ion goes, but haven't understood the detail, possible proposal and implicat= ions yet. Would it be ok to setup a call between you, the authors and mayb= e Rob as well to discuss this off the list and feedback the summary to the = list back? Looking forward to your reply. Best Wishes Thomas From: netconf On Behalf Of Andy Bierman Sent: Monday, August 31, 2020 7:40 PM To: Tianran Zhou Cc: netconf@ietf.org; Rob Wilton (rwilton) Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-not= if Hi, I am still very confused about the content. Not the encoding. That is a sep= arate issue. Sec 2, and 3.1 refer to the "subscription-started" notification and "the NETCONF/RESTCONF notification message". This text seems to imply that the element defined in RFC 527= 7 is used for the content. But sec. 3.4 mentions bundled notifications so ma= ybe not. Usually the application protocol defines the message flows that are expecte= d. This document is a transport protocol for an unspecified application. Ther= e is an assumption that publisher and receiver both know the protocol somehow. For GDB, they magically know how to distinguish different proto files. IMO this level of disregard for interoperability is unacceptable for a stan= dard protocol. Andy On Fri, Aug 28, 2020 at 2:01 AM Tianran Zhou > wrote: Hi Andy, Thanks again for your further comments. Tianran From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Friday, August 28, 2020 3:14 AM To: Tianran Zhou > Cc: Rob Wilton (rwilton) >; netconf@ietf.org Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-not= if On Wed, Aug 26, 2020 at 6:50 PM Tianran Zhou > wrote: Hi Andy, Thanks for your reply and suggestions. Cheers, Tianran From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Thursday, August 27, 2020 1:29 AM To: Tianran Zhou > Cc: Rob Wilton (rwilton) >; netconf@ietf.org Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-not= if On Wed, Aug 26, 2020 at 1:17 AM Tianran Zhou > wrote: Hi Andy, Please see inline. Tianran From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Wednesday, August 19, 2020 6:18 AM To: Rob Wilton (rwilton) > Cc: netconf@ietf.org Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-not= if On Tue, Aug 18, 2020 at 6:42 AM Rob Wilton (rwilton) > wrote: Hi, [Also as a contributor] My comments are broadly similar to Kent's. I believe that a UDP transport for dataplane telemetry where getting accura= te fresh data quickly is more important than getting every update. This is= particularly true if a subsequent notification will cover any lost values = anyway (e.g. periodic statistics). agreed. There is also the resync-subscription mechanism to help recover from missin= g data. [ztr] Our intention of using UDP is for data that do not care about occasio= nal loss. Typically for period data, and new data will anyway came and upda= te. Does the "resync-subscription" mean the retransmission? Here do you want to= add the "resync-subscription mechanism" when packet loss is detected in th= is draft? This is explained in RFC 8641 ZTR> Yes, I looked into RFC8641. It's the same as what I understand as "ret= ransmission". Two key points on "resync-subscription" from my perspective. 1. "This RPC is supported only for on-change subscriptions previously estab= lished using an "establish-subscription" RPC." 2. "On receipt, a publisher must either (1) accept the request and quickly = follow with a "push-update" or ..." So, what's your suggestion here? To support this? Or not support this and add text explicitly in the documen= t. Nothing to add to this document. I was just noting that YANG Push does not rely on every push-change-update notification to be delivered. The application layer will re-synch by itsel= f. ZTR> Agreed. Thanks. I suspect that having a mechanism to allow for the telemetry data being enc= rypted is probably also important. If the WG were to adopt a draft without= this, then as Benoit mentioned, I would have to test the water with the IE= SG to determine whether that would be acceptable. I suspect the lack of congestion control might get their attention as well. [ztr] Yes, I agree, both security and congestion considerations need to be = described in the document. We have section 4 for congestion control. Do you= have any idea on this? no -- I can't solve problems that IETF creates for itself. I think the draft says something like "do not use this protocol if congesti= on is a concern". I also note that the draft allows for a GPB encoding of the telemetry data,= but I'm not aware of any formal standard encoding of YANG data in GPB, and= there is a choice between whether the GPB encoding is generic for all YANG= data, or specific GPB encodings are useful for the specific data that is b= eing encoded. I was confused by the same thing. Is there a YANG schema for a notification element that is used? Which means the .proto file is hardwired? If not then how does the receiver know what is sent? There are some technical issues that can be addressed if the draft is adopt= ed. [ztr] In this draft we only consider to include a code point to indicate th= e GPB encoding. How to map YANG to GPB is out of the scope of this draft. In practice, there are several ways in my opinion. We can map YANG to proto firstly, and the proto actually describes the data= structure. I think YANG can almost translate to proto 1:1. We can also develop YANG to GPB directly, just like YANG to XML and JSON. In brief, the receiver can still know what is sent by YANG. I don't think the protocol should include placeholders for proprietary solu= tions. Either leave out GPB completely or support it in an interoperable way. ZTR> We have no position on this. If the WG agreed, we would like to leave = out GPB. What about just adding a 32-bit report-id field to the header This is enough. Assignment of the IDs is out of scope. ZTR> Sorry, I did not get you on what's this 32-bit report-id? We have a 4= bit encoding type field, which can support 16 encodings. We can set this a= s a registry and defer the assignment of GPB. More issues: This protocol is not usable by servers that stream data instead of building= an entire response in memory. With a streaming design the server doesn't know what will be sen= t in advance so it sure doesn't know the length in advance. CBOR does a great job of suppo= rting both types of server design. NETCONF and HTTP support chunking, which is used e= xtensively by streaming servers. This draft should mention streaming and explain why it i= s not supported. ZTR> If you mean bit streaming like TCP, I think UDP cannot support this. D= o you have any pointer on how CBOR can support the streaming. And how NETCO= NF and HTTP support chunking. In general, I understand this requirement with small memory or partial data= . But do you have any real case in the context of YANG push? So that we can= work on an optimal design. I think it is OK to say that a server is expected to build an entire respon= se and the length needs to be known in advance, if fragmentation is not enable= d. A server can stream data OK if UDP fragmentation is enabled. CoAP uses the = Block option to support streaming. ZTR> Got it. Yes, this draft enables UDP fragmentation which can support da= ta streaming. The generic wrappers (like gNMI and YANG notification schema) do not handle= "anydata" very well at all. The binary payload becomes mostly JSON. Only CBOR+SID handles anydata effi= ciently. The solution (maybe outside the scope of this protocol) should consider how= YANG anydata will be transmitted efficiently and converted from anydata to a real schema= correctly by the receiver. Regards, Rob Andy Andy Andy From: netconf > O= n Behalf Of Kent Watsen Sent: 07 August 2020 21:16 To: netconf@ietf.org Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-not= if [as a contributor] 1) is the problem important for the NETCONF WG to solve? I believe that it is important to enable publishers to send notifications u= sing a UDP-based transport. This belief is based on my experience from wh= en at Juniper dealing with very high-end firewalls with enormous log output= . I believe that the NETCONF WG is the appropriate WG for this work, having d= efined RFC 8639 (SN), RFC 8640 (NN), and RFC 8650 (RN). 2) is the draft a suitable basis for the work? I have read the current version of the draft and find it to be a reasonable= start. Presuming the "receiver-instances" augmentation defined in https://tools.ie= tf.org/html/draft-ietf-netconf-https-notif-04#section-3 takes off, the module defined in this draf= t should be updated to augment into it instead. I appreciate Section 5 (Applicability) noting that the UDP-transport is pri= marily for the data plane (not the control plane), as it doesn't matter so = much if data plane notifications are lost. This addresses (I think) the is= sue that Rob Shakir raised before: https://datatracker.ietf.org/doc/minutes= -103-netconf (search for "Rob S"). That sai= d, it is unclear to me how a receiver could configure this while, e.g., con= figuring control plane notifications to be sent via a TCP-based transport s= uch as "https-notif". 3) regarding Juergen's questions: a) I am willing to substantially review the drafts. b) I am willing to contribute to the discussion of any issue. c) I do NOT plan to implement the technology defined. Kent _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_ZRAP278MB01258EEC7E4161368EACE35C892E0ZRAP278MB0125CHEP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andy,

 

Thanks for the feedback. I t= hink I understand in which direction your question goes, but haven't unders= tood the detail, possible proposal and implications yet.  Would it be = ok to setup a call between you, the authors and maybe Rob as well to discuss this off the list and feedback the summar= y to the list back? Looking forward to your reply.

 

Best Wishes

Thomas

 

From: netconf <netconf-bounces@ietf.org> On Behalf Of Andy Bierman
Sent: Monday, August 31, 2020 7:40 PM
To: Tianran Zhou <zhoutianran@huawei.com>
Cc: netconf@ietf.org; Rob Wilton (rwilton) <rwilton=3D40cisco.com= @dmarc.ietf.org>
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

 

Hi,

 

I am still very confused about the content. Not the = encoding. That is a separate issue.

Sec 2, and 3.1 refer to the "subscription-start= ed" notification and

"the NETCONF/RESTCONF notification message"= ;.

 

This text seems to imply that the <notification&g= t; element defined in RFC 5277

is used for the content.  But sec. 3.4 mentions= bundled notifications so maybe not.

 

Usually the application protocol defines the message= flows that are expected.

This document is a transport protocol for an unspeci= fied application.  There is

an assumption that publisher and receiver both know = the protocol somehow.

For GDB, they magically know how to distinguish diff= erent proto files.

 

IMO this level of disregard for interoperability is = unacceptable for a standard protocol.

 

 

Andy

 

 

 

 

On Fri, Aug 28, 2020 at 2:01 AM Tianran Zhou <zhoutianran@huawei.com> wrote= :

Hi Andy,

 

Thanks again for your= further comments.

 

Tianran

 

From: Andy= Bierman [mailto:an= dy@yumaworks.com]
Sent: Friday, August 28, 2020 3:14 AM
To: Tianran Zhou <zhoutianran@huawei.com>
Cc: Rob Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org>; netconf@ietf.org<= br> Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

 

 

 

On Wed, Aug 26, 2020 at 6:50 PM Tianran Zhou = <zhoutianran= @huawei.com> wrote:

Hi Andy,

 

Thanks for your reply= and suggestions.

 

Cheers,

Tianran

 

From: Andy= Bierman [mailto:an= dy@yumaworks.com]
Sent: Thursday, August 27, 2020 1:29 AM
To: Tianran Zhou <zhoutianran@huawei.com>
Cc: Rob Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org>; netconf@ietf.org<= br> Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

 

 

 

On Wed, Aug 26, 2020 at 1:17 AM Tianran Zhou = <zhoutianran= @huawei.com> wrote:

Hi Andy,

 

Please see inline.

 

Tianran

 

From: netc= onf [mailto:n= etconf-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Wednesday, August 19, 2020 6:18 AM
To: Rob Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org>
Cc: netconf@ie= tf.org
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

 

 

 

On Tue, Aug 18, 2020 at 6:42 AM Rob Wilton (r= wilton) <rwilton=3D40cisco.com@dmarc.ietf.org> wrote:

Hi,

 =

[Also as a contributor]

 =

My comments are broadly similar to Kent’= ;s.

 =

I believe that a UDP transport for dataplane = telemetry where getting accurate fresh data quickly is more important than = getting every update.  This is particularly true if a subsequent notification will cover any lost values anyway (e.g. = periodic statistics).

 =

 

agreed.

There is also the resync-subscription mechani= sm to help recover from missing data.

 

[ztr] Our intention of using UDP is for data = that do not care about occasional loss. Typically for period data, and new = data will anyway came and update.

Does the “resync-subscription” me= an the retransmission? Here do you want to add the “resync-subscripti= on mechanism” when packet loss is detected in this draft?<= /span>

 

 

 

This is explained in RFC 8641

 

ZTR> Yes, I looked= into RFC8641. It’s the same as what I understand as “retransmi= ssion”. Two key points on “resync-subscription” from my perspective.

1. “This RPC is= supported only for on-change subscriptions previously established using an= "establish-subscription" RPC.”=

2. “On receipt,= a publisher must either (1) accept the request and quickly follow with a &= quot;push-update" or …”

 

So, what’s your= suggestion here?

To support this? Or n= ot support this and add text explicitly in the document.  

 

 

Nothing to add to this document.

I was just noting that YANG Push does not rel= y on every push-change-update

notification to be delivered.  The appli= cation layer will re-synch by itself.

 

ZTR> Agreed. Thank= s.

 

 =

I suspect that having a mechanism to allow fo= r the telemetry data being encrypted is probably also important.  If t= he WG were to adopt a draft without this, then as Benoit mentioned, I would have to test the water with the IESG to deter= mine whether that would be acceptable.

 

I suspect the lack of congestion control migh= t get their attention as well.

 

[ztr] Yes, I agree, both security and congest= ion considerations need to be described in the document. We have section 4 = for congestion control. Do you have any idea on this?

 

 

no -- I can't solve problems that IETF create= s for itself.

I think the draft says something like "d= o not use this protocol if congestion is a concern".=

 

 

 =

I also note that the draft allows for a GPB e= ncoding of the telemetry data, but I’m not aware of any formal standa= rd encoding of YANG data in GPB, and there is a choice between whether the GPB encoding is generic for all YANG data, or= specific GPB encodings are useful for the specific data that is being enco= ded.

 =

 

 

I was confused by the same thing.<= /span>

Is there a YANG schema for a notification ele= ment that is used?

Which means the .proto file is hardwired?

If not then how does the receiver know what i= s sent?

There are some technical issues that can be a= ddressed if the draft is adopted.

 

[ztr] In this draft we only consider to inclu= de a code point to indicate the GPB encoding. How to map YANG to GPB is out= of the scope of this draft.

In practice, there are several ways in my opi= nion.

We can map YANG to proto firstly, and the pro= to actually describes the data structure. I think YANG can almost translate= to proto 1:1.

We can also develop YANG to GPB directly, jus= t like YANG to XML and JSON.

In brief, the receiver can still know what is= sent by YANG.

 

 

 

I don't think the protocol should include pla= ceholders for proprietary solutions.

Either leave out GPB completely or support it= in an interoperable way.

 

ZTR> We have no po= sition on this. If the WG agreed, we would like to leave out GPB.

 

 

What about just adding a 32-bit report-id fie= ld to the header

This is enough. Assignment of the IDs is out = of scope.

 

 ZTR> S= orry, I did not get you on what’s this 32-bit report-id? We have a 4 = bit encoding type field, which can support 16 encodings. We can set this as a registry and defer the assignment of GPB.=

 

 

 

More issues:

 

This protocol is not usable by servers that s= tream data instead of building an entire response

in memory. With a streaming design the server= doesn't know what will be sent in advance so

it sure doesn't know the length in advance.&n= bsp; CBOR does a great job of supporting both

types of server design.  NETCONF and HTT= P support chunking, which is used extensively by

streaming servers. This draft should mention = streaming and explain why it is not supported.

 

ZTR> If you mean b= it streaming like TCP, I think UDP cannot support this. Do you have any poi= nter on how CBOR can support the streaming. And how NETCONF and HTTP support chunking.

In general, I underst= and this requirement with small memory or partial data. But do you have any= real case in the context of YANG push? So that we can work on an optimal design.=

 

 

I think it is OK to say that a server is expe= cted to build an entire response

and the length needs to be known in advance, = if fragmentation is not enabled.

A server can stream data OK if UDP fragmentat= ion is enabled. CoAP uses the Block option

to support streaming.

 

ZTR> Got it. Yes, = this draft enables UDP fragmentation which can support data streaming.

 

 

 

The generic wrappers (like gNMI and YANG noti= fication schema) do not handle "anydata" very well at all.

The binary payload becomes mostly JSON. = Only CBOR+SID handles anydata efficiently.

The solution (maybe outside the scope of this= protocol) should consider how YANG anydata

will be transmitted efficiently and converted= from anydata to a real schema correctly by the receiver.=

 

 

 

 

Regards,
Rob

 =

 

Andy

 

 

Andy

 

 

 

Andy

 

 

 

 =

From: netc= onf <netco= nf-bounces@ietf.org> On Behalf Of Kent Watsen
Sent: 07 August 2020 21:16
To: netconf@ie= tf.org
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

 =

[as a contributor]

 =

 =

   1) is the problem important= for the NETCONF WG to solve?=

 =

I believe that it is important to enable publ= ishers to send notifications using a UDP-based transport.   This belie= f is based on my experience from when at Juniper dealing with very high-end firewalls with enormous log output.

 =

I believe that the = ;NETCONF WG is the appropriate WG for this work= , having defined RFC 8639 (SN), RFC 8640 (NN), and RFC 8650 (RN).=

 =

 

   2) is the draft a suitable = basis for the work?

 =

I have read the current version of the draft = and find it to be a reasonable start.

 =

Presuming the “receiver-instances”= ; augmentation defined in https://tools.ietf.org/html/draft-ietf-netconf-https= -notif-04#section-3 takes off, the module defined in this draft should be updated to augment into it= instead.

 =

I appreciate Section 5 = (Applicability) noting that the UDP-transport is primarily for the data pla= ne (not the control plane), as it doesn’t matter so much if data plane notifications are lost.  This addresses = (I think) the issue that Rob Shakir raised before: https://datatracker.ietf.org/= doc/minutes-103-netconf (search for “Rob S”).  That said, it is unclear to me how a recei= ver could configure this while, e.g., configuring control plane notificatio= ns to be sent via a TCP-based transport such as “https-notif”.<= /span>

 

 

3) regarding Juergen= 217;s questions:

 

  a) I am willing = to substantially review the drafts.<= /span>

  b) I am wil= ling to contribute to the discussion of any issue.

  c) I do NOT = ;plan to implement the technology defined.=

 

 

 

Kent

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

--_000_ZRAP278MB01258EEC7E4161368EACE35C892E0ZRAP278MB0125CHEP_-- ------=_Part_116867_249589249.1598967169237 Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCAMIIG QTCCBSmgAwIBAgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCQ0gxFTATBgNVBAoTDFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFs IFNpbHZlciBDQSAyMDE0IC0gRzIyMB4XDTE5MDQxMTE2NDgyOFoXDTIyMDQxMTE2NDgyOFowgYEx CzAJBgNVBAYTAkNIMR4wHAYDVQQKExVTd2lzc2NvbSAoU2Nod2VpeikgQUcxJzAlBgkqhkiG9w0B CQEWGHRob21hcy5ncmFmQHN3aXNzY29tLmNvbTEpMCcGA1UEAxMgU2VjdXJlIE1haWw6IEdhdGV3 YXkgQ2VydGlmaWNhdGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCITr0/mumt/DE7 c8RDgwoi0IdMVLbGMQ1wzpjZ23C3KaauDnIDCAdgwJCj8H/4hy8Wj/EoKvbnJXc3DN/g5n4MyujX JjsLMo3cMaHqTSql2zKFsdFRnjNtOTEQMVleqnKgeiLwF5M+QpZGhS9T9M4br9PCKBEdwZ+BJRJN XPtxUjJWLh7ueFbMApS5lOryeoZrv9Yi6D5xSGErBuPrzn1ekUMzOfycZ4HcyLaEfzGNgYEax2yS 1/ZcM/qoj7k8e6dskfB6/PkFnf5BfWqwfWtmqn7PRJQQAEmjkJafFZNtvlyJ/ktjpI+pnju1AZaA c+LNL1eT1rwNdesrljxik/plAgMBAAGjggLZMIIC1TAjBgNVHREEHDAagRh0aG9tYXMuZ3JhZkBz d2lzc2NvbS5jb20wDgYDVR0PAQH/BAQDAgSwMBMGA1UdJQQMMAoGCCsGAQUFBwMEMB0GA1UdDgQW BBTAJbWmkqWsxJzHeilKdMU8NUhnwzAfBgNVHSMEGDAWgBTwx6MykbXryrVYdxWnTr4aXWFDJTCB /wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNzc2lnbi5uZXQvRjBDN0EzMzI5MUI1 RUJDQUI1NTg3NzE1QTc0RUJFMUE1RDYxNDMyNTCBqKCBpaCBooaBn2xkYXA6Ly9kaXJlY3Rvcnku c3dpc3NzaWduLm5ldC9DTj1GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1 JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmpl Y3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBrBgNVHSAEZDBiMFYGCWCFdAFZAQMBCzBJMEcG CCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tL1N3aXNzU2lnbi1TaWx2 ZXItQ1AtQ1BTLnBkZjAIBgYEAI96AQMwgdkGCCsGAQUFBwEBBIHMMIHJMGQGCCsGAQUFBzAChlho dHRwOi8vc3dpc3NzaWduLm5ldC9jZ2ktYmluL2F1dGhvcml0eS9kb3dubG9hZC9GMEM3QTMzMjkx QjVFQkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1MGEGCCsGAQUFBzABhlVodHRwOi8vc2lsdmVy LXBlcnNvbmFsLWcyLm9jc3Auc3dpc3NzaWduLm5ldC9GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVB NzRFQkUxQTVENjE0MzI1MA0GCSqGSIb3DQEBCwUAA4IBAQBPAGaURtN/46Vopba1sQJzad0O2JxG 8MwpE2F435dz+BfK/L8DGWN+EmWQV9k/p/IhNLFnj9WhBdd+iuscOT83XDCnUzyYiNqz7bhrQAEm B/87tdMsPhq5wUz5XfpnDcsSiQ1r/Woo+baMSN60QruEZM/be9mFILGOByV8BEwVbZTAiL7cLaOh bxUfQubFvyfOZ1HgJMVyfWizDVvDG2rL6YkWtsIBaVmCYGBqHrX0wSLyHlRNnbqiM2vawqQYme+1 +wxtbGCPPexp3wUBqpJde40Ke1xIpMj8c1kyvtaRM3CBX2p6xl0XHnSrybkJUidmaZnblUM6O18u b28x6Qp3MIIGvjCCBKagAwIBAgIPBUTWTq0e0zbVMkBdALk2MA0GCSqGSIb3DQEBCwUAMEcxCzAJ BgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxITAfBgNVBAMTGFN3aXNzU2lnbiBTaWx2 ZXIgQ0EgLSBHMjAeFw0xNDA5MTkyMDM2NDlaFw0yOTA5MTUyMDM2NDlaMFYxCzAJBgNVBAYTAkNI MRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBTaWx2 ZXIgQ0EgMjAxNCAtIEcyMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMs5sTmF/vrJ obzDg6kOSi2Ech7/aMWnxB3sD9eoixMes9EWi0DcD1NvAT3s6GS1l9uDvKiowIQ4WF4DFCvmyjDv ALLrEzkZkkcqIQDlcs3CMWIOzFYq/3fEY4yYwm9417W2zOl9HzOmkQUq/tFS1vTsnP5NTGpS4YV2 Yru5aOZSY/zBIZGSXRnY3IDRGeNJFlcCDhlEhaspyS/6xm1rCqH29/9rYTUVJpSUAmklXWn3vV5r gtmQDAb5QwUiSes20CBaYxDjOCHVfxYrQYpGevJn6KTQuh5/JCd1mJRJLVbEVDORnWL51V/eW6kV mJyUU8GA6QkXFbQbgCkyodCvE6cCAwEAAaOCApYwggKSMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB Af8ECDAGAQH/AgEAMB0GA1UdDgQWBBTwx6MykbXryrVYdxWnTr4aXWFDJTAfBgNVHSMEGDAWgBQX oM3B5EG2Ols7y0WdvRzCmPqGWDCB/wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNz c2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5OEZBODY1ODCBqKCBpaCB ooaBn2xkYXA6Ly9kaXJlY3Rvcnkuc3dpc3NzaWduLm5ldC9DTj0xN0EwQ0RDMUU0NDFCNjNBNUIz QkNCNDU5REJEMUNDMjk4RkE4NjU4JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBhBgNVHSAE WjBYMFYGCWCFdAFZAQMBBjBJMEcGCCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3Np Z24uY29tL1N3aXNzU2lnbi1TaWx2ZXItQ1AtQ1BTLnBkZjCBxgYIKwYBBQUHAQEEgbkwgbYwZAYI KwYBBQUHMAKGWGh0dHA6Ly9zd2lzc3NpZ24ubmV0L2NnaS1iaW4vYXV0aG9yaXR5L2Rvd25sb2Fk LzE3QTBDREMxRTQ0MUI2M0E1QjNCQ0I0NTlEQkQxQ0MyOThGQTg2NTgwTgYIKwYBBQUHMAGGQmh0 dHA6Ly9vY3NwLnN3aXNzc2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5 OEZBODY1ODANBgkqhkiG9w0BAQsFAAOCAgEAw3mnV7d7rVFo9USMQZUoAXx01jtqvG3vp9dNOZkd aI3KCNnQcbEZNZNvgsYcSbhR7kz5bApv2KX7/vswXgDSlKvEElG6qoqrat0Z1ytK9xaya1HPdFsp onPel/7YTyAhfWkMsFDljViMgC7lFxzdY3qq7wX5w2me5IxxYlxC7jryzeAS74tc6c5TKDLslQsZ VKIhjfp/UKdPvBl7smuMKT93Psojx2laQZ19ZjFvenF52qllOut/1xDVC19UGXzONyUkhFDQr0A0 wl+S4nqR8y9CRxufPEL72V+lvHBFju+gOZD1oXhs18BnWRnhAN5c/HjoT927rJEucov86kdvQyi8 u7mOlL76UN1QkxtMGLZ2/8NHClm0zW1V2Gq2X8kvwZQ2Pr6uQDUGIO3gAkwtNEUOQ6+i9NiQFeXQ wJtEQK48j5NRvJloc2l7dViZt9QET9/xgnERHXv8Ex13ZVVj11JyfN0xR4anldisJnE9I+YSO/R/ mpaG/ivqoPMmDXXGFowxIOcRR6HnqWqwpbKBHtw90KHjbtXwZqYcfdeSiE0ABwtx53Pnc+RUZWn8 N43xHm9w7qdss1JFZ1nWBUixIemXKNnZ9LSmoGcjNrxgRw5cKH9dk4oxuo0xNhTHekKdbyDBbCr4 Fg9q2QCUMrs9VbHFw6ENsXl3VB3gM4J+7uowggW9MIIDpaADAgECAghPG9QvVLsvSzANBgkqhkiG 9w0BAQUFADBHMQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMSEwHwYDVQQDExhT d2lzc1NpZ24gU2lsdmVyIENBIC0gRzIwHhcNMDYxMDI1MDgzMjQ2WhcNMzYxMDI1MDgzMjQ2WjBH MQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMSEwHwYDVQQDExhTd2lzc1NpZ24g U2lsdmVyIENBIC0gRzIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDE8Yd/03gx9zjJ +MOZQ7zH97w3505xukuPpXMdXG6YrgNXrjg3Qy8XPR/IzmgQwXiuGQMrEPoseYP26LlouVXyBESn Ofn8BIse8aJNJ/lhe7q35aITtuthPtBs0eb7+l7tHbSeoDVboZLL8EmS/oUKBT7m2QviT7vclTf8 kekyNSLRHzpOJ4WdsBWUMtphDUdNYEKukkfog1pQWOmKi7ldodzdmUofNme7SOSDtjfrSDqvD2eP FwfoBMrvajGH1MC2+ZRxe2dkuLaRSkJ7ZS4wagz1kO6V5vLNguzZoUrs9rJL5UWF5m14kwQunIJt NqnEMWQfhoMLKvQ1CnjJVc9BsEfpMJ+ZvmGoBoS5KHpfONkbqTiwg39zwcM7SCqCDyGbuMyoNcOE G4OzPr6klWkBOokAeATZyfSZGatWfluLhjkVkaQQLAkygGCzk8AqthgLnX6NSfIQSn/51UYvGZKj macmrLuMPOYOvEcH3HNR8XBkLwj5tEcdMGxE6ik3hZJoZryDOP57OS7TUPAf+15gtqmm+idB8ZsY cvL1hHRKyWfEVK5IZN+M0W6wHeEHjwgemZxx6UzYpfdHEh900VGehvPCoiNAC3PbS6bncwaMwaDp wVmsRvrmL/jPcZxGbbnEFY04eQNFSO/EXdcI7oc5IoayDQ9YQ/dxqUgu/erWHwIDAQABo4GsMIGp MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQXoM3B5EG2Ols7y0Wd vRzCmPqGWDAfBgNVHSMEGDAWgBQXoM3B5EG2Ols7y0WdvRzCmPqGWDBGBgNVHSAEPzA9MDsGCWCF dAFZAQMBATAuMCwGCCsGAQUFBwIBFiBodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tLzAN BgkqhkiG9w0BAQUFAAOCAgEAc8aB4CfSLQ/glTDimkF/UCxfX2JhqYZqaRgMdEnWXYTqQVIYb1it UFYgasa9KGlYkdyRETWpOh28GqVgntgff0WRadl+u3hywQYPKs6PhXBhrKDNC7g5KVaEMk6Guz3E KtnXH3Lu/lGhIkGxcQJjGoKwYqteVxIf38vddaDAXXmQjBvgUObeMf6Ye3BfpZDYrfgCtm/TYN1A SyLFPa06ep8aGkeReTO6gtwyaQOWbh9L8HH+42dyoLG/XIvk+pkix4S5G40jlz/tJeDPZbv1YQTv 3R6yWkEiWqGfXSzoW8ltqQwMeKpgxlaPAVoMaLxpGXnEH36XBb/F6SRRXtTVS1Pt2SNaNgNlo8ED rUEw80YbhZCvZbXVseQWW3h1HZd6bVmpKo973sOHiRCZSXN4yD29UTV0KtXxfmkbKrs7vSW4mlo9 cmGQZofuDNZN1BF0C2r+CwP8o1VXif5Ky65bFwXI8o0jMVM40i1qP4K5jQhq915BdG7DEX4HrClg kT84ylcQDb0wL8el5kGg2q4Fh5qgpGVsTAkMibq407nAk4ow+o3lmmsVAU5nqtpiVj6ECGbSxDZ9 pz4Q/Ijg1IDlAL2q804Go3pq+WJy4wlP65sOASPxn7t83NxsEZclsvK0YxTSBipnjIP1zuoH2Jpq HuzkCrsqTOsJYDnOymLYLm4AADGCA90wggPZAgEBMG4wVjELMAkGA1UEBhMCQ0gxFTATBgNVBAoT DFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFsIFNpbHZlciBDQSAyMDE0 IC0gRzIyAhR4i6Eec1b72YkIjJKOk4r62lxMbzANBglghkgBZQMEAgEFAKCCAkAwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwOTAxMTMzMjQ5WjAtBgkqhkiG9w0B CTQxIDAeMA0GCWCGSAFlAwQCAQUAoQ0GCSqGSIb3DQEBCwUAMC8GCSqGSIb3DQEJBDEiBCB/tPDn FJIXvBb6oylGCcJbFCV8vBrsdRP18cxwsB4GkjB9BgkrBgEEAYI3EAQxcDBuMFYxCzAJBgNVBAYT AkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBT aWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wfwYLKoZIhvcNAQkQAgsx cKBuMFYxCzAJBgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNz U2lnbiBQZXJzb25hbCBTaWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8w gaUGCSqGSIb3DQEJDzGBlzCBlDALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQB AjAKBggqhkiG9w0DBzAKBggqhkiG9w0DAjAKBggqhkiG9w0DAjAHBgUrDgMCBzAKBggqhkiG9w0D AjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATALBglghkgBZQMEAgQwDQYJ KoZIhvcNAQELBQAEggEAIC4IvvUNhiI1YLgpyiG3fdnaIQMf4E+MVmhJ7c0O/2/tZPtswxMp7MI/ B/2hHpLDdd1oQGa6j2TAPSKCOyuXFz2U1A7jU46p8FHOesyjnFRC45solP4ikWHWLWWEZ2hgJOyo b+4gUIF1oKRy4ghUtXgh1gKSpzQYKUwUx350ap8CZl4QoggSYYGJBLkgDreYxR4ytgxtB70vgw8Y F7ncFQMGVKH5fIFPM3IoUVlxL7xOFSe4OYRnHPoNUeDabzqwbLYqL+6FKnSs8jU0HN1Z2DgjVG3k ScL/R7XKZZ4j9KQOPv1BYZrXJE1NAZqiV3wSSlOEbYx9TS1AHRJBG4Jx/gAAAAAAAA== ------=_Part_116867_249589249.1598967169237-- From nobody Tue Sep 1 08:14:23 2020 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 EA83D3A0B44 for ; Tue, 1 Sep 2020 08:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 uckZ9N6P31T9 for ; Tue, 1 Sep 2020 08:14:19 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::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 9732D3A0B50 for ; Tue, 1 Sep 2020 08:14:18 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id h19so1946290ljg.13 for ; Tue, 01 Sep 2020 08:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Kw2AQnRlhTnpUXQ/xGhMKF/73E7FZUNwUhGpxLqDHTA=; b=PpH8K/DuO+rB0zVrQrs1T/PCbmvUp348tSPaD8N2J1NZaafiYock6hYnH5i5PbPB51 KLdnnv20E91cnHTWsLctNk37bxX8vRuHrf595ooL8cNqRVhQTYmm6oNKp4cSav1rpaWU bmndojWRC8SSl9z5wC/4u4LPIK9nmzoiw/dYAaXypBaXXjWAYwJ6JW/Mbn64EXyFYAc7 UR7Fu0fQy0NB19lCT8YFd8Alv9LvwLVbDXGaDNGkJv3615MAeGcfdfiHP6MxW9YpCtIO jt0CPj/0dSWjxeyGzUlRq5FG4RkRK0m+u+v2LScWOOHla6HIvNIWatlaeEPkfMSdVRdE A1KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Kw2AQnRlhTnpUXQ/xGhMKF/73E7FZUNwUhGpxLqDHTA=; b=ic7e6oVR85CZmmb1IB+HOIAYdSYyq2C7kklgQQAIoeQme+9KLG+VC5A2FbJvJsVf/T Dlt0/IiBWG2TwNXbO8V5qFi3piLdJsZVRWLvVzh/DCfX5ymG7sEq9tqVtM6XHhRTMyr+ HrrIlZXPBFC9M1X1KCXT8hWVgJc22WYvbXjG+P7onGvJPpcD/OySTbZKIqPJPsB40x79 +YUhJwYbNciXitTK+Khpt8FmWxF8CJi1YFa+WiO2K83ZGaOyx17xn63CuNEdGe+v6/CY tqKuQD30CYFWN8CY1+iX/PEAf80nwKZctPR4SKAFS9KLfpAKZUuaAdsz/fNMiaSyjILz bdaA== X-Gm-Message-State: AOAM531TZ+ibY1XI5svUgGwJp8Y+qt2UMqGnrDS9NapI/otn0OlFH0Hj PRLBlrfTPF4+SLEmLto/AAOBQ/Y9HYLo0HmreaA5rw== X-Google-Smtp-Source: ABdhPJxfvnJwMpKRqfso0odU7+P0BYHbv32VN8kzwRVYfV3xzhUWmUt1Krd+V6poecomvSHLljD1bh/vcIQcOpeS6vM= X-Received: by 2002:a2e:4e01:: with SMTP id c1mr840151ljb.144.1598973256360; Tue, 01 Sep 2020 08:14:16 -0700 (PDT) MIME-Version: 1.0 References: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@us-east-1.amazonses.com> <01000173ca90a8d5-78b55d80-3a92-406a-8544-594dbe223735-000000@email.amazonses.com> <07b991b1e32347b58ae4ef968cdffc7f@huawei.com> <7b77f6ff39d4430aa549c9b53b902dde@huawei.com> In-Reply-To: From: Andy Bierman Date: Tue, 1 Sep 2020 08:14:04 -0700 Message-ID: To: Thomas.Graf@swisscom.com Cc: Zhoutianran , Netconf , Robert Wilton Content-Type: multipart/alternative; boundary="000000000000f3843905ae41f8b2" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 15:14:22 -0000 --000000000000f3843905ae41f8b2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 1, 2020 at 6:33 AM wrote: > Hi Andy, > > > > Thanks for the feedback. I think I understand in which direction your > question goes, but haven't understood the detail, possible proposal and > implications yet. Would it be ok to setup a call between you, the author= s > and maybe Rob as well to discuss this off the list and feedback the summa= ry > to the list back? Looking forward to your reply. > > I don't know if a conf-call is needed. It appears that there is no application protocol here in this proposal. Take the "XML" encoding for example. That usually means the application content is an XML instance document -- a single XML element. OK, which one? Which schema does the receiver use to validate the XML instance document? If the answer is "any XML instance document you want" rather than "the application protocol defines the message content", then there is no application, right? Which means this proposal is for a general-purpose protocol for sending data as fast as possible over UDP, without regard for security or congestion. > > Best Wishes > > Thomas > Andy > > > *From:* netconf *On Behalf Of *Andy Bierman > *Sent:* Monday, August 31, 2020 7:40 PM > *To:* Tianran Zhou > *Cc:* netconf@ietf.org; Rob Wilton (rwilton) 40cisco.com@dmarc.ietf.org> > *Subject:* Re: [netconf] Adoption-suitability for > draft-unyte-netconf-udp-notif > > > > Hi, > > > > I am still very confused about the content. Not the encoding. That is a > separate issue. > > Sec 2, and 3.1 refer to the "subscription-started" notification and > > "the NETCONF/RESTCONF notification message". > > > > This text seems to imply that the element defined in RFC > 5277 > > is used for the content. But sec. 3.4 mentions bundled notifications so > maybe not. > > > > Usually the application protocol defines the message flows that are > expected. > > This document is a transport protocol for an unspecified application. > There is > > an assumption that publisher and receiver both know the protocol somehow. > > For GDB, they magically know how to distinguish different proto files. > > > > IMO this level of disregard for interoperability is unacceptable for a > standard protocol. > > > > > > Andy > > > > > > > > > > On Fri, Aug 28, 2020 at 2:01 AM Tianran Zhou > wrote: > > Hi Andy, > > > > Thanks again for your further comments. > > > > Tianran > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Friday, August 28, 2020 3:14 AM > *To:* Tianran Zhou > *Cc:* Rob Wilton (rwilton) ; > netconf@ietf.org > *Subject:* Re: [netconf] Adoption-suitability for > draft-unyte-netconf-udp-notif > > > > > > > > On Wed, Aug 26, 2020 at 6:50 PM Tianran Zhou > wrote: > > Hi Andy, > > > > Thanks for your reply and suggestions. > > > > Cheers, > > Tianran > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Thursday, August 27, 2020 1:29 AM > *To:* Tianran Zhou > *Cc:* Rob Wilton (rwilton) ; > netconf@ietf.org > *Subject:* Re: [netconf] Adoption-suitability for > draft-unyte-netconf-udp-notif > > > > > > > > On Wed, Aug 26, 2020 at 1:17 AM Tianran Zhou > wrote: > > Hi Andy, > > > > Please see inline. > > > > Tianran > > > > *From:* netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Andy > Bierman > *Sent:* Wednesday, August 19, 2020 6:18 AM > *To:* Rob Wilton (rwilton) > *Cc:* netconf@ietf.org > *Subject:* Re: [netconf] Adoption-suitability for > draft-unyte-netconf-udp-notif > > > > > > > > On Tue, Aug 18, 2020 at 6:42 AM Rob Wilton (rwilton) 40cisco.com@dmarc.ietf.org> wrote: > > Hi, > > > > [Also as a contributor] > > > > My comments are broadly similar to Kent=E2=80=99s. > > > > I believe that a UDP transport for dataplane telemetry where getting > accurate fresh data quickly is more important than getting every update. > This is particularly true if a subsequent notification will cover any los= t > values anyway (e.g. periodic statistics). > > > > > > agreed. > > There is also the resync-subscription mechanism to help recover from > missing data. > > > > [ztr] Our intention of using UDP is for data that do not care about > occasional loss. Typically for period data, and new data will anyway came > and update. > > Does the =E2=80=9Cresync-subscription=E2=80=9D mean the retransmission? H= ere do you want > to add the =E2=80=9Cresync-subscription mechanism=E2=80=9D when packet lo= ss is detected in > this draft? > > > > > > > > This is explained in RFC 8641 > > > > ZTR> Yes, I looked into RFC8641. It=E2=80=99s the same as what I understa= nd as > =E2=80=9Cretransmission=E2=80=9D. Two key points on =E2=80=9Cresync-subsc= ription=E2=80=9D from my > perspective. > > 1. =E2=80=9CThis RPC is supported only for on-change subscriptions previo= usly > established using an "establish-subscription" RPC.=E2=80=9D > > 2. =E2=80=9COn receipt, a publisher must either (1) accept the request an= d quickly > follow with a "push-update" or =E2=80=A6=E2=80=9D > > > > So, what=E2=80=99s your suggestion here? > > To support this? Or not support this and add text explicitly in the > document. > > > > > > Nothing to add to this document. > > I was just noting that YANG Push does not rely on every push-change-updat= e > > notification to be delivered. The application layer will re-synch by > itself. > > > > ZTR> Agreed. Thanks. > > > > > > I suspect that having a mechanism to allow for the telemetry data being > encrypted is probably also important. If the WG were to adopt a draft > without this, then as Benoit mentioned, I would have to test the water wi= th > the IESG to determine whether that would be acceptable. > > > > I suspect the lack of congestion control might get their attention as wel= l. > > > > [ztr] Yes, I agree, both security and congestion considerations need to b= e > described in the document. We have section 4 for congestion control. Do y= ou > have any idea on this? > > > > > > no -- I can't solve problems that IETF creates for itself. > > I think the draft says something like "do not use this protocol if > congestion is a concern". > > > > > > > > I also note that the draft allows for a GPB encoding of the telemetry > data, but I=E2=80=99m not aware of any formal standard encoding of YANG d= ata in > GPB, and there is a choice between whether the GPB encoding is generic fo= r > all YANG data, or specific GPB encodings are useful for the specific data > that is being encoded. > > > > > > > > I was confused by the same thing. > > Is there a YANG schema for a notification element that is used? > > Which means the .proto file is hardwired? > > If not then how does the receiver know what is sent? > > There are some technical issues that can be addressed if the draft is > adopted. > > > > [ztr] In this draft we only consider to include a code point to indicate > the GPB encoding. How to map YANG to GPB is out of the scope of this draf= t. > > In practice, there are several ways in my opinion. > > We can map YANG to proto firstly, and the proto actually describes the > data structure. I think YANG can almost translate to proto 1:1. > > We can also develop YANG to GPB directly, just like YANG to XML and JSON. > > In brief, the receiver can still know what is sent by YANG. > > > > > > > > I don't think the protocol should include placeholders for > proprietary solutions. > > Either leave out GPB completely or support it in an interoperable way. > > > > ZTR> We have no position on this. If the WG agreed, we would like to leav= e > out GPB. > > > > > > What about just adding a 32-bit report-id field to the header > > This is enough. Assignment of the IDs is out of scope. > > > > ZTR> Sorry, I did not get you on what=E2=80=99s this 32-bit report-id? W= e have a > 4 bit encoding type field, which can support 16 encodings. We can set thi= s > as a registry and defer the assignment of GPB. > > > > > > > > More issues: > > > > This protocol is not usable by servers that stream data instead of > building an entire response > > in memory. With a streaming design the server doesn't know what will be > sent in advance so > > it sure doesn't know the length in advance. CBOR does a great job of > supporting both > > types of server design. NETCONF and HTTP support chunking, which is used > extensively by > > streaming servers. This draft should mention streaming and explain why it > is not supported. > > > > ZTR> If you mean bit streaming like TCP, I think UDP cannot support this. > Do you have any pointer on how CBOR can support the streaming. And how > NETCONF and HTTP support chunking. > > In general, I understand this requirement with small memory or partial > data. But do you have any real case in the context of YANG push? So that = we > can work on an optimal design. > > > > > > I think it is OK to say that a server is expected to build an entire > response > > and the length needs to be known in advance, if fragmentation is not > enabled. > > A server can stream data OK if UDP fragmentation is enabled. CoAP uses th= e > Block option > > to support streaming. > > > > ZTR> Got it. Yes, this draft enables UDP fragmentation which can support > data streaming. > > > > > > > > The generic wrappers (like gNMI and YANG notification schema) do not > handle "anydata" very well at all. > > The binary payload becomes mostly JSON. Only CBOR+SID handles anydata > efficiently. > > The solution (maybe outside the scope of this protocol) should consider > how YANG anydata > > will be transmitted efficiently and converted from anydata to a real > schema correctly by the receiver. > > > > > > > > > > Regards, > Rob > > > > > > Andy > > > > > > Andy > > > > > > > > Andy > > > > > > > > > > *From:* netconf *On Behalf Of *Kent Watsen > *Sent:* 07 August 2020 21:16 > *To:* netconf@ietf.org > *Subject:* Re: [netconf] Adoption-suitability for > draft-unyte-netconf-udp-notif > > > > [as a contributor] > > > > > > 1) is the problem important for the NETCONF WG to solve? > > > > I believe that it is important to enable publishers to send notifications > using a UDP-based transport. This belief is based on my experience from > when at Juniper dealing with very high-end firewalls with enormous log > output. > > > > I believe that the NETCONF WG is the appropriate WG for this work, having > defined RFC 8639 (SN), RFC 8640 (NN), and RFC 8650 (RN). > > > > > > 2) is the draft a suitable basis for the work? > > > > I have read the current version of the draft and find it to be a > reasonable start. > > > > Presuming the =E2=80=9Creceiver-instances=E2=80=9D augmentation defined i= n > https://tools.ietf.org/html/draft-ietf-netconf-https-notif-04#section-3 > takes > off, the module defined in this draft should be updated to augment into i= t > instead. > > > > I appreciate Section 5 (Applicability) noting that the UDP-transport is > primarily for the data plane (not the control plane), as it doesn=E2=80= =99t matter > so much if data plane notifications are lost. This addresses (I think) t= he > issue that Rob Shakir raised before: > https://datatracker.ietf.org/doc/minutes-103-netconf > (search > for =E2=80=9CRob S=E2=80=9D). That said, it is unclear to me how a recei= ver could > configure this while, e.g., configuring control plane notifications to be > sent via a TCP-based transport such as =E2=80=9Chttps-notif=E2=80=9D. > > > > > > 3) regarding Juergen=E2=80=99s questions: > > > > a) I am willing to substantially review the drafts. > > b) I am willing to contribute to the discussion of any issue. > > c) I do NOT plan to implement the technology defined. > > > > > > > > Kent > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > --000000000000f3843905ae41f8b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Sep 1, 2020 at 6:33 AM <Thomas.Graf@swi= sscom.com> wrote:

Hi Andy,

=C2=A0

Thanks for the feedback. I think I understand in wh= ich direction your question goes, but haven't understood the detail, po= ssible proposal and implications yet.=C2=A0 Would it be ok to setup a call = between you, the authors and maybe Rob as well to discuss this off the list and feedback the summar= y to the list back? Looking forward to your reply.

I don't know if a conf-call is needed.=C2=A0
It a= ppears that there is no application protocol here in this proposal.
Take the "XML" encoding for example.=C2=A0 That usually means = the application content
is an XML instance document -- a single X= ML element.=C2=A0 OK, which one? Which schema
does the receiver u= se to validate the XML instance document?

If the a= nswer is "any XML instance document you want" rather than "t= he application protocol
defines the message content", then t= here is no application, right?
Which means this proposal=C2=A0is = for a general-purpose protocol for sending data as fast as possible
over UDP, without regard for security or congestion.

=C2=A0

Best Wishes

Thomas


=

Andy
=C2=A0

=C2=A0=

From: netconf <netconf-bounces@ietf.org> On Behalf Of Andy Bierman
Sent: Monday, August 31, 2020 7:40 PM
To: Tianran Zhou <zhoutianran@huawei.com>
Cc: netconf@ie= tf.org; Rob Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org>
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

=C2=A0

Hi,

=C2=A0

I am still very confused about the content. Not the = encoding. That is a separate issue.

Sec 2, and 3.1 refer to the "subscription-start= ed" notification and

"the NETCONF/RESTCONF notification message"= ;.

=C2=A0

This text seems to imply that the <notification&g= t; element defined in RFC 5277

is used for the content.=C2=A0 But sec. 3.4 mentions= bundled notifications so maybe not.

=C2=A0

Usually the application protocol defines the message= flows that are expected.

This document is a transport protocol for an unspeci= fied application.=C2=A0 There is

an assumption that publisher and receiver both know = the protocol somehow.

For GDB, they magically know how to distinguish diff= erent proto files.

=C2=A0

IMO this level of disregard for interoperability is = unacceptable for a standard protocol.

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Fri, Aug 28, 2020 at 2:01 AM Tianran Zhou <zhoutianran@huawei= .com> wrote:

= Hi Andy,

= =C2=A0

= Thanks again for your further comments.<= u>

= =C2=A0

= Tianran

= =C2=A0

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Friday, August 28, 2020 3:14 AM
To: Tianran Zhou <zhoutianran@huawei.com>
Cc: Rob Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org>; netconf@ietf.org<= br> Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

=C2=A0

=C2=A0

=C2=A0

On Wed, Aug 26, 2020 at 6:50 PM= Tianran Zhou <zhoutianran@huawei.com> wrote:

= Hi Andy,

= =C2=A0

= Thanks for your reply and suggestions.

= =C2=A0

= Cheers,

= Tianran

= =C2=A0

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Thursday, August 27, 2020 1:29 AM
To: Tianran Zhou <zhoutianran@huawei.com>
Cc: Rob Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org>; netconf@ietf.org<= br> Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

=C2=A0

=C2=A0

=C2=A0

On Wed, Aug 26, 2020 at 1:17 AM= Tianran Zhou <zhoutianran@huawei.com> wrote:

= Hi Andy,

= =C2=A0

= Please see inline.

= =C2=A0

= Tianran

= =C2=A0

From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Wednesday, August 19, 2020 6:18 AM
To: Rob Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org>
Cc: netconf@ie= tf.org
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

=C2=A0

=C2=A0

=C2=A0

On Tue, Aug 18, 2020 at 6:42 AM= Rob Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org> wrote:

Hi,=

=C2=A0

[Also as a contributor]<= span lang=3D"EN-US">

=C2=A0

My comments are broadly similar= to Kent=E2=80=99s.

=C2=A0

I believe that a UDP transport = for dataplane telemetry where getting accurate fresh data quickly is more i= mportant than getting every update.=C2=A0 This is particularly true if a subsequent notification will cover any lost values anyway (e.g. = periodic statistics).

=C2=A0

=C2=A0

agreed.

There is also the resync-subscr= iption mechanism to help recover from missing data.

=C2=A0

[ztr] Our intention of using UD= P is for data that do not care about occasional loss. Typically for period = data, and new data will anyway came and update.

Does the =E2=80=9Cresync-subscr= iption=E2=80=9D mean the retransmission? Here do you want to add the =E2=80= =9Cresync-subscription mechanism=E2=80=9D when packet loss is detected in t= his draft?

=C2=A0

=C2=A0

=C2=A0

This is explained in RFC 8641

= =C2=A0

= ZTR> Yes, I looked into RFC8641. It=E2=80=99s the same as what I underst= and as =E2=80=9Cretransmission=E2=80=9D. Two key points on =E2=80=9Cresync-= subscription=E2=80=9D from my perspective.

= 1. =E2=80=9CThis RPC is supported only for on-change subscriptions previous= ly established using an "establish-subscription" RPC.=E2=80=9D

= 2. =E2=80=9COn receipt, a publisher must either (1) accept the request and = quickly follow with a "push-update" or =E2=80=A6=E2=80=9D<= span lang=3D"EN-US">

= =C2=A0

= So, what=E2=80=99s your suggestion here?

= To support this? Or not support this and add text explicitly in the documen= t. =C2=A0

=C2=A0

=C2=A0

Nothing to add to this document= .

I was just noting that YANG Pus= h does not rely on every push-change-update

notification to be delivered.= =C2=A0 The application layer will re-synch by itself.<= /p>

=C2=A0

= ZTR> Agreed. Thanks.

=C2=A0

=C2=A0

I suspect that having a mechani= sm to allow for the telemetry data being encrypted is probably also importa= nt.=C2=A0 If the WG were to adopt a draft without this, then as Benoit mentioned, I would have to test the water with the IESG to deter= mine whether that would be acceptable.

=C2=A0

I suspect the lack of congestio= n control might get their attention as well.

=C2=A0

[ztr] Yes, I agree, both securi= ty and congestion considerations need to be described in the document. We h= ave section 4 for congestion control. Do you have any idea on this?

=C2=A0

=C2=A0

no -- I can't solve problem= s that IETF creates for itself.

I think the draft says somethin= g like "do not use this protocol if congestion is a concern".<= /u>

=C2=A0

=C2=A0

=C2=A0

I also note that the draft allo= ws for a GPB encoding of the telemetry data, but I=E2=80=99m not aware of a= ny formal standard encoding of YANG data in GPB, and there is a choice between whether the GPB encoding is generic for all YANG data, or= specific GPB encodings are useful for the specific data that is being enco= ded.

=C2=A0

=C2=A0

=C2=A0

I was confused by the same thin= g.

Is there a YANG schema for a no= tification element that is used?

Which means the .proto file is = hardwired?

If not then how does the receiv= er know what is sent?

There are some technical issues= that can be addressed if the draft is adopted.

=C2=A0

[ztr] In this draft we only con= sider to include a code point to indicate the GPB encoding. How to map YANG= to GPB is out of the scope of this draft.

In practice, there are several = ways in my opinion.

We can map YANG to proto firstl= y, and the proto actually describes the data structure. I think YANG can al= most translate to proto 1:1.

We can also develop YANG to GPB= directly, just like YANG to XML and JSON.

In brief, the receiver can stil= l know what is sent by YANG.

=C2=A0

=C2=A0

=C2=A0

I don't think the protocol = should include placeholders for proprietary=C2=A0solutions.

Either leave out GPB completely= or support it in an interoperable way.

= =C2=A0

= ZTR> We have no position on this. If the WG agreed, we would like to lea= ve out GPB.

=C2=A0

=C2=A0

What about just adding a 32-bit= report-id field to the header

This is enough. Assignment of t= he IDs is out of scope.

= =C2=A0

=C2=A0ZTR> Sorry, I did not get you on what=E2=80=99s this 32-bit = report-id? We have a 4 bit encoding type field, which can support 16 encodi= ngs. We can set this as a registry and defer the assignment of GPB.

=C2=A0

= =C2=A0

=C2=A0

More issues:

=C2=A0

This protocol is not usable by = servers that stream data instead of building an entire response

in memory. With a streaming des= ign the server doesn't know what will be sent in advance so

it sure doesn't know the le= ngth in advance.=C2=A0 CBOR does a great job of supporting both

types of server design.=C2=A0 N= ETCONF and HTTP support chunking, which is used extensively by

streaming servers. This draft s= hould mention streaming and explain why it is not supported.<= /span>

= =C2=A0

= ZTR> If you mean bit streaming like TCP, I think UDP cannot support this= . Do you have any pointer on how CBOR can support the streaming. And how NETCONF and HTTP support chunking.<= /u>

= In general, I understand this requirement with small memory or partial data= . But do you have any real case in the context of YANG push? So that we can work on an optimal design.

=C2=A0

=C2=A0

I think it is OK to say that a = server is expected to build an entire response

and the length needs to be know= n in advance, if fragmentation is not enabled.

A server can stream data OK if = UDP fragmentation is enabled. CoAP uses the Block option

to support streaming.=

=C2=A0

= ZTR> Got it. Yes, this draft enables UDP fragmentation which can support= data streaming.

=C2=A0

=C2=A0

= =C2=A0

The generic wrappers (like gNMI= and YANG notification schema) do not handle "anydata" very well = at all.

The binary payload becomes most= ly JSON.=C2=A0 Only CBOR+SID handles anydata efficiently.

The solution (maybe outside the= scope of this protocol) should consider how YANG anydata

will be transmitted efficiently= and converted from anydata to a real schema correctly by the receiver.<= /u>

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Regards,
Rob

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: netconf <netconf-bounces@ietf.org> On Behalf Of Kent Watsen
Sent: 07 August 2020 21:16
To: netconf@ie= tf.org
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

=C2=A0

[as a contributor]

=C2=A0

=C2=A0

=C2=A0=C2=A0=C2=A01) is the pro= blem important for the NETCONF WG to solve?<= /u>

=C2=A0

I believe that it is important = to enable publishers to send notifications using a UDP-based transport. =C2= =A0 This belief is based on my experience from when at Juniper dealing with very high-end firewalls with enormous log output.

=C2=A0

I believe= that the=C2=A0NETCONF WG is the appropriate WG= for this work, having defined RFC 8639 (SN),=C2=A0RFC 8640 (NN), and=C2=A0RFC 8650 (RN).

=C2=A0

= =C2=A0

=C2=A0=C2=A0=C2=A02) is the dra= ft a suitable basis for the work?=

=C2=A0

I have read the current version= of the draft and find it to be a reasonable start.

=C2=A0

Presuming the =E2=80=9Creceiver= -instances=E2=80=9D augmentation defined in=C2=A0https://tools.ietf.org/html/draft-= ietf-netconf-https-notif-04#section-3=C2=A0takes off, the module defined in this draft should be updated to augment into it= instead.

=C2=A0

I appreci= ate Section 5 (Applicability) noting that the UDP-transport is primarily fo= r the data plane (not the control plane), as it doesn=E2=80=99t matter so much if data plane notifications are lost.=C2=A0 This addresses = (I think) the issue that Rob Shakir raised before: https://datatracker.ietf.org/= doc/minutes-103-netconf=C2=A0(search for =E2=80=9CRob S=E2=80=9D).=C2=A0 That said, it is unclear to me how a r= eceiver could configure this while, e.g., configuring control plane notific= ations to be sent via a TCP-based transport such as =E2=80=9Chttps-notif=E2= =80=9D.

=C2=A0

=C2=A0

3) regard= ing Juergen=E2=80=99s questions:<= /span>

=C2=A0

=C2=A0 a)= I am willing to substantially review the drafts.

=C2=A0 b)= I am=C2=A0willing to contribute to the discussion of any issue.

=C2=A0 c)= I do NOT=C2=A0plan to implement the technology defined.

=C2=A0

=C2=A0

=C2=A0

Kent

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

--000000000000f3843905ae41f8b2-- From nobody Tue Sep 1 10:37:41 2020 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 8AF953A0CCD for ; Tue, 1 Sep 2020 10:37:39 -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, SPF_PASS=-0.001, URIBL_BLOCKED=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 tK7bLHFsNECw for ; Tue, 1 Sep 2020 10:37:38 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F1743A0CCC for ; Tue, 1 Sep 2020 10:37:38 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8E404F40785; Tue, 1 Sep 2020 10:37:26 -0700 (PDT) To: andy@yumaworks.com, mbj@tail-f.com, kwatsen@juniper.net, warren@kumari.net, rwilton@cisco.com, kent+ietf@watsen.net, mjethanandani@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: kent+ietf@watsen.net, netconf@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200901173726.8E404F40785@rfc-editor.org> Date: Tue, 1 Sep 2020 10:37:26 -0700 (PDT) Archived-At: Subject: [netconf] [Technical Errata Reported] RFC8040 (6271) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 17:37:40 -0000 The following errata report has been submitted for RFC8040, "RESTCONF Protocol". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6271 -------------------------------------- Type: Technical Reported by: Kent Watsen Section: 4.5 Original Text ------------- The "insert" (Section 4.8.5) and "point" (Section 4.8.6) query parameters MUST be supported by the PUT method for data resources. These parameters are only allowed if the list or leaf-list is "ordered-by user". Corrected Text -------------- The "insert" (Section 4.8.5) and "point" (Section 4.8.6) query parameters MUST be supported by the PUT method for data resources. These parameters are only allowed if the target resource is a non-existent entry of an "ordered-by user" list or leaf-list. Notes ----- First, Section 3.5 (Data Resource) says that "list" and "leaf-leaf" are not a data resources: A data resource represents a YANG data node that is a descendant node of a datastore resource. Each YANG-defined data node can be uniquely targeted by the request-line of an HTTP method. Containers, leafs, leaf-list entries, list entries, anydata nodes, and anyxml nodes are data resources. Second, these query parameters only make sense when targeting a non-existent entry. If the entry does not exist, then PUT is being used like a POST: to create and place an item in an ordered list. However, if the entry exists, then PUT is being used to both replace the contents and (presumably) re-place the order in the list; but this doesn't make sense because: 1) "insert" defaults to "last". 2) there is no "insert" value to indicate "keep existing placement". 3) having to concoct valid "insert" and "point" values is hard. Thus indiscriminate PUTs would move entries to the end, which can't be desired... Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8040 (draft-ietf-netconf-restconf-18) -------------------------------------- Title : RESTCONF Protocol Publication Date : January 2017 Author(s) : A. Bierman, M. Bjorklund, K. Watsen Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue Sep 1 12:28:38 2020 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 149FB3A0F9E for ; Tue, 1 Sep 2020 12:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 ihXJHOiTR3Ht for ; Tue, 1 Sep 2020 12:28:35 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::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 1D48D3A0F9F for ; Tue, 1 Sep 2020 12:28:35 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id w3so2960769ljo.5 for ; Tue, 01 Sep 2020 12:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xUYIdCC0SjYLPwircK53DWZPiN5XHfnAVKie2DJFoAg=; b=y43uzbuH/nYbVJ5ZKxUaU0tBT/YRBB0xD/mAvKwGwZf+Iwz2pzww+XioCZiHXLWeDF TfxJHD+NJV+oDk0nwl0Ow/wWM3mYEZt3T+EKw0+gLR3nz/e9KHip+DlZWH+jXqyPwpyu KtWqcS2wi6ljvo3vt9Ccljgn3Kw4fusaP/FhR+vAKZFJuTVB5p+yDtMBgWrO9F5LTCtj W6U4/d3Y57+PKWoiA/fh/5cPxE/SuYN3weAftjZr1MlvVP8NFAUeirvF4ZB8WcoVprpR uGbFgJUbnnUW507Q4k30zJXpMw0N0MFwzmUOFq8ug/y9OxltXw2PX5KbkNIaY/Gcog7U frAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xUYIdCC0SjYLPwircK53DWZPiN5XHfnAVKie2DJFoAg=; b=Z4XqtA2aG86a4WEpcyKxeNK8mOMqFYTBvjGdreUy3w4Efm6DrQc2iDjYsIsvKkMlcJ X+f9Bw6CyeRWK5hu+kcEGxpo/3JKaA/GIh/o5N5Ot/C5i/s6ONR/oNxnCs0t9yaSRuek L9bc021hINeAHb8tSjbwatPpFlwkPClnYQ9djgQWN8sL0pJTUhUvjmg6/enkVkARxEkg jGqzjD8pNpQ8Sbu7X+GDuXx3MLKr7GBKZn0EODPsFEIfvrfopyxHXTse5ZS7R/9RR/LF YNcZbl++HQLxyZxaQkmHDOx7heO99iBEJXswNhrCRB1Q3qAmDOc72270wQMoNU4A6My2 qKuQ== X-Gm-Message-State: AOAM530+YIIFU56ODU2PaD5H+ayMkyXVxw8ZX1kJOtPJBU3b5E+zcO5R 5drBk4mubdERSzku44ljEV6ot39f4iukltSYUsEFnA== X-Google-Smtp-Source: ABdhPJxLI6Medri1xe6SvMKLhB6hZ/i+DsrjVNCwFo9rL/ZQNrlX3Exmox2/c9qBmP+BB3rOPLESdxUA+pbpV1pYuIo= X-Received: by 2002:a2e:9bc3:: with SMTP id w3mr1291802ljj.320.1598988513180; Tue, 01 Sep 2020 12:28:33 -0700 (PDT) MIME-Version: 1.0 References: <20200901173726.8E404F40785@rfc-editor.org> In-Reply-To: <20200901173726.8E404F40785@rfc-editor.org> From: Andy Bierman Date: Tue, 1 Sep 2020 12:28:22 -0700 Message-ID: To: RFC Errata System Cc: Martin Bjorklund , Kent Watsen , Warren Kumari , Robert Wilton , Kent Watsen , Mahesh Jethanandani , Netconf Content-Type: multipart/alternative; boundary="00000000000054188205ae458652" Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6271) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 19:28:37 -0000 --00000000000054188205ae458652 Content-Type: text/plain; charset="UTF-8" Hi, I agree this errata should be accepted. Andy On Tue, Sep 1, 2020 at 10:37 AM RFC Errata System wrote: > The following errata report has been submitted for RFC8040, > "RESTCONF Protocol". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6271 > > -------------------------------------- > Type: Technical > Reported by: Kent Watsen > > Section: 4.5 > > Original Text > ------------- > The "insert" (Section 4.8.5) and "point" (Section 4.8.6) query > parameters MUST be supported by the PUT method for data resources. > These parameters are only allowed if the list or leaf-list is > "ordered-by user". > > > Corrected Text > -------------- > The "insert" (Section 4.8.5) and "point" (Section 4.8.6) query > parameters MUST be supported by the PUT method for data resources. > These parameters are only allowed if the target resource is a > non-existent entry of an "ordered-by user" list or leaf-list. > > Notes > ----- > First, Section 3.5 (Data Resource) says that "list" and "leaf-leaf" are > not a data resources: > > A data resource represents a YANG data node that is a descendant node > of a datastore resource. Each YANG-defined data node can be uniquely > targeted by the request-line of an HTTP method. Containers, leafs, > leaf-list entries, list entries, anydata nodes, and anyxml nodes are > data resources. > > Second, these query parameters only make sense when targeting a > non-existent entry. If the entry does not exist, then PUT is being used > like a POST: to create and place an item in an ordered list. However, if > the entry exists, then PUT is being used to both replace the contents and > (presumably) re-place the order in the list; but this doesn't make sense > because: > > 1) "insert" defaults to "last". > 2) there is no "insert" value to indicate "keep existing placement". > 3) having to concoct valid "insert" and "point" values is hard. > > Thus indiscriminate PUTs would move entries to the end, which can't be > desired... > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8040 (draft-ietf-netconf-restconf-18) > -------------------------------------- > Title : RESTCONF Protocol > Publication Date : January 2017 > Author(s) : A. Bierman, M. Bjorklund, K. Watsen > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > --00000000000054188205ae458652 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I agree this errata should be accep= ted.


Andy


On Tu= e, Sep 1, 2020 at 10:37 AM RFC Errata System <rfc-editor@rfc-editor.org> wrote:
The following errata report has= been submitted for RFC8040,
"RESTCONF Protocol".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6271

--------------------------------------
Type: Technical
Reported by: Kent Watsen <kent+ietf@watsen.net>

Section: 4.5

Original Text
-------------
=C2=A0 =C2=A0The "insert" (Section 4.8.5) and "point" (= Section 4.8.6) query
=C2=A0 =C2=A0parameters MUST be supported by the PUT method for data resour= ces.
=C2=A0 =C2=A0These parameters are only allowed if the list or leaf-list is<= br> =C2=A0 =C2=A0"ordered-by user".


Corrected Text
--------------
=C2=A0 =C2=A0The "insert" (Section 4.8.5) and "point" (= Section 4.8.6) query
=C2=A0 =C2=A0parameters MUST be supported by the PUT method for data resour= ces.
=C2=A0 =C2=A0These parameters are only allowed if the target resource is a<= br> =C2=A0 =C2=A0non-existent entry of an "ordered-by user" list or l= eaf-list.

Notes
-----
First, Section 3.5 (Data Resource) says that "list" and "lea= f-leaf" are not a data resources:

=C2=A0 A data resource represents a YANG data node that is a descendant nod= e
=C2=A0 of a datastore resource. Each YANG-defined data node can be uniquely=
=C2=A0 targeted by the request-line of an HTTP method. Containers, leafs, =C2=A0 leaf-list entries, list entries, anydata nodes, and anyxml nodes are=
=C2=A0 data resources.

Second, these query parameters only make sense when targeting a non-existen= t entry.=C2=A0 =C2=A0If the entry does not exist, then PUT is being used li= ke a POST: to create and place an item in an ordered list.=C2=A0 However, i= f the entry exists, then PUT is being used to both replace the contents and= (presumably) re-place the order in the list; but this doesn't make sen= se because:

=C2=A0 1) "insert" defaults to "last".
=C2=A0 2) there is no "insert" value to indicate "keep exist= ing placement".
=C2=A0 3) having to concoct valid "insert" and "point" = values is hard.

Thus indiscriminate PUTs would move entries to the end, which can't be = desired...

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party=C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC8040 (draft-ietf-netconf-restconf-18)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: RESTCONF Prot= ocol
Publication Date=C2=A0 =C2=A0 : January 2017
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A. Bierman, M. Bjorklun= d, K. Watsen
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Network Configurat= ion
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Operations an= d Management
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
--00000000000054188205ae458652-- From nobody Tue Sep 1 13:45:50 2020 Return-Path: <010001744b6b2011-58d28583-ed0a-47dd-a5eb-8677f3cac1a1-000000@amazonses.watsen.net> 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 0C8903A1082 for ; Tue, 1 Sep 2020 13:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 g0ordu5CRhZ1 for ; Tue, 1 Sep 2020 13:45:47 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5442C3A1081 for ; Tue, 1 Sep 2020 13:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1598993146; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=q7a4sNbEHXnvKejdl7X70AbkEpOqVUfIlAHnOmeqpcw=; b=eKU8342rUtoxuS40h1I6YvX35F2GN/CLT/oXBu7SfjI3Djw+jRQFHwO9OJzmx51h KP68YIYOITdkqNDcXJbzWIZk7b5UcinxX8caWh1jRAg6dgsZWzyUIi2Ll5RqMo0CsTC CVi7vlv+Io+XUjU982P6PQFqAhRfdZR/eiXizhlM= From: Kent Watsen Message-ID: <010001744b6b2011-58d28583-ed0a-47dd-a5eb-8677f3cac1a1-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BD1F881D-C693-4DD6-8364-87E11A634AAE" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 1 Sep 2020 20:45:46 +0000 In-Reply-To: Cc: RFC Errata System , Martin Bjorklund , Kent Watsen , Warren Kumari , Robert Wilton , Mahesh Jethanandani , "netconf@ietf.org" To: Andy Bierman References: <20200901173726.8E404F40785@rfc-editor.org> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.09.01-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6271) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 20:45:49 -0000 --Apple-Mail=_BD1F881D-C693-4DD6-8364-87E11A634AAE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Maybe the wording is too strong? OLD: These parameters are only allowed if...=20 NEW: These parameters are only processed if=E2=80=A6 Note also the HTTP goal to be idempotent. K. > On Sep 1, 2020, at 3:28 PM, Andy Bierman wrote: >=20 > Hi, >=20 > I agree this errata should be accepted. >=20 >=20 > Andy >=20 >=20 > On Tue, Sep 1, 2020 at 10:37 AM RFC Errata System = > wrote: > The following errata report has been submitted for RFC8040, > "RESTCONF Protocol". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6271 = >=20 > -------------------------------------- > Type: Technical > Reported by: Kent Watsen > >=20 > Section: 4.5 >=20 > Original Text > ------------- > The "insert" (Section 4.8.5) and "point" (Section 4.8.6) query > parameters MUST be supported by the PUT method for data resources. > These parameters are only allowed if the list or leaf-list is > "ordered-by user". >=20 >=20 > Corrected Text > -------------- > The "insert" (Section 4.8.5) and "point" (Section 4.8.6) query > parameters MUST be supported by the PUT method for data resources. > These parameters are only allowed if the target resource is a > non-existent entry of an "ordered-by user" list or leaf-list. >=20 > Notes > ----- > First, Section 3.5 (Data Resource) says that "list" and "leaf-leaf" = are not a data resources: >=20 > A data resource represents a YANG data node that is a descendant = node > of a datastore resource. Each YANG-defined data node can be uniquely > targeted by the request-line of an HTTP method. Containers, leafs, > leaf-list entries, list entries, anydata nodes, and anyxml nodes are > data resources. >=20 > Second, these query parameters only make sense when targeting a = non-existent entry. If the entry does not exist, then PUT is being = used like a POST: to create and place an item in an ordered list. = However, if the entry exists, then PUT is being used to both replace the = contents and (presumably) re-place the order in the list; but this = doesn't make sense because: >=20 > 1) "insert" defaults to "last". > 2) there is no "insert" value to indicate "keep existing placement". > 3) having to concoct valid "insert" and "point" values is hard. >=20 > Thus indiscriminate PUTs would move entries to the end, which can't be = desired... >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC8040 (draft-ietf-netconf-restconf-18) > -------------------------------------- > Title : RESTCONF Protocol > Publication Date : January 2017 > Author(s) : A. Bierman, M. Bjorklund, K. Watsen > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG --Apple-Mail=_BD1F881D-C693-4DD6-8364-87E11A634AAE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Maybe= the wording is too strong?

    OLD: These parameters are = only allowed if... 
    NEW: These parameters are only processed = if=E2=80=A6

Note also the HTTP goal to be = idempotent.

K.


On Sep = 1, 2020, at 3:28 PM, Andy Bierman <andy@yumaworks.com> = wrote:

Hi,

I agree this errata should be accepted.


Andy


On Tue, Sep 1, 2020 at 10:37 AM RFC Errata System = <rfc-editor@rfc-editor.org> wrote:
The following errata report has been = submitted for RFC8040,
"RESTCONF Protocol".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6271

--------------------------------------
Type: Technical
Reported by: Kent Watsen <kent+ietf@watsen.net>

Section: 4.5

Original Text
-------------
   The "insert" (Section 4.8.5) and "point" (Section 4.8.6) = query
   parameters MUST be supported by the PUT method for data = resources.
   These parameters are only allowed if the list or leaf-list = is
   "ordered-by user".


Corrected Text
--------------
   The "insert" (Section 4.8.5) and "point" (Section 4.8.6) = query
   parameters MUST be supported by the PUT method for data = resources.
   These parameters are only allowed if the target resource is = a
   non-existent entry of an "ordered-by user" list or = leaf-list.

Notes
-----
First, Section 3.5 (Data Resource) says that "list" and "leaf-leaf" are = not a data resources:

  A data resource represents a YANG data node that is a descendant = node
  of a datastore resource. Each YANG-defined data node can be = uniquely
  targeted by the request-line of an HTTP method. Containers, = leafs,
  leaf-list entries, list entries, anydata nodes, and anyxml nodes = are
  data resources.

Second, these query parameters only make sense when targeting a = non-existent entry.   If the entry does not exist, then PUT is = being used like a POST: to create and place an item in an ordered = list.  However, if the entry exists, then PUT is being used to both = replace the contents and (presumably) re-place the order in the list; = but this doesn't make sense because:

  1) "insert" defaults to "last".
  2) there is no "insert" value to indicate "keep existing = placement".
  3) having to concoct valid "insert" and "point" values is = hard.

Thus indiscriminate PUTs would move entries to the end, which can't be = desired...

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
= rejected. When a decision is reached, the verifying party 
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC8040 (draft-ietf-netconf-restconf-18)
--------------------------------------
Title               : RESTCONF = Protocol
Publication Date    : January 2017
Author(s)           : A. Bierman, M. = Bjorklund, K. Watsen
Category            : PROPOSED STANDARD
Source              : Network = Configuration
Area                : Operations = and Management
Stream              : IETF
Verifying Party     : IESG

= --Apple-Mail=_BD1F881D-C693-4DD6-8364-87E11A634AAE-- From nobody Tue Sep 1 23:27:25 2020 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 10FD73A0DAE for ; Tue, 1 Sep 2020 23:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.616 X-Spam-Level: X-Spam-Status: No, score=-0.616 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.482, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=xUTh1O42; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MJOPi45W Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CL02XYaS1xk for ; Tue, 1 Sep 2020 23:27:22 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33E03A0DAB for ; Tue, 1 Sep 2020 23:27:22 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 801BDDDC; Wed, 2 Sep 2020 02:27:21 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 02 Sep 2020 02:27:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm2; bh= zPZkmwSYiRKBwJ5Js9/dkwb+x+e3HLJNgslcd+5Bbw0=; b=xUTh1O420/Nlpwh9 6QQ43yvuVhTISt/1GMyRI0cq3RY8bEy91RaOQFSGDRvm0YbYFy/Tqmd4QizfBJPT dFymacpv2r9wsY3NjD3UYtCFa2NtjxA8JWfM7vL6Xr5iWgu6mPmRwqJ+TPHGR+wS lr5WYzvc7SeqlbVakBthgJpED+NopQqxBKAxNyXzAKUn2sl2Vz2EL/ECV83ZMURO nZW/Qvd0sHgoFDuAhFYWBjwhRO6LpXo4xKOsU6QolC4lHhQxRyMcanQusOiW6k1U Z0+/AZAMp5ruE3lHBQMpRv3jCYA33tAnXEzyB8Qeng5xeIC0v5yqwceAm1Pr6Ajs jQ077Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=zPZkmwSYiRKBwJ5Js9/dkwb+x+e3HLJNgslcd+5Bb w0=; b=MJOPi45WPjuPD2kFHp/Wsq8BN1tqcpwFKaP7ftKwBPJPlYGMqGF9q9hC5 PePjMcr0IDN4i/qQYS0BBls6VVPXjZX4JnKs0QLGUxHdF0PWM4lQyYgIrp7EFTJ3 KUt5NqCGDyxjGdMTtWTI2X/25bvRowI4FvlW+YushtTUIc37r1VFXJ1pygwS7DZN DoZ0tPEznexjijtht5Htpg6T0LvGyLLMYTVyInvfpo7va+lP6qO0TyNTRd0IjmYP mwP4OBsZfsjRwjW45l08vnLg8omnZiZPXUweJ72/jUaCAesPEv+wwcK5rTIHdlx+ 4x3QqqH3KlQPNFisGzomg6lbDutEg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudefkedguddtkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesth ejredtredtvdenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdo ihgvthhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpeeufeffudegveffhedtud ekledvgffffedugfethfegieevtddtvdefteefffefjeenucffohhmrghinheprhhftgdq vgguihhtohhrrdhorhhgpdhivghtfhdrohhrghenucfkphepudehkedrudejgedrgedrge egnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgs jhdoihgvthhfseegieeikedrshgv X-ME-Proxy: Received: from localhost (unknown [158.174.4.44]) by mail.messagingengine.com (Postfix) with ESMTPA id 5F704306005E; Wed, 2 Sep 2020 02:27:19 -0400 (EDT) Date: Wed, 02 Sep 2020 08:27:18 +0200 (CEST) Message-Id: <20200902.082718.1225293218517439729.id@4668.se> To: rfc-editor@rfc-editor.org Cc: andy@yumaworks.com, kwatsen@juniper.net, warren@kumari.net, rwilton@cisco.com, kent+ietf@watsen.net, mjethanandani@gmail.com, netconf@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <20200901173726.8E404F40785@rfc-editor.org> References: <20200901173726.8E404F40785@rfc-editor.org> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6271) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 06:27:24 -0000 Hi, RFC Errata System wrote: > The following errata report has been submitted for RFC8040, > "RESTCONF Protocol". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6271 > > -------------------------------------- > Type: Technical > Reported by: Kent Watsen > > Section: 4.5 > > Original Text > ------------- > The "insert" (Section 4.8.5) and "point" (Section 4.8.6) query > parameters MUST be supported by the PUT method for data resources. > These parameters are only allowed if the list or leaf-list is > "ordered-by user". > > > Corrected Text > -------------- > The "insert" (Section 4.8.5) and "point" (Section 4.8.6) query > parameters MUST be supported by the PUT method for data resources. > These parameters are only allowed if the target resource is a > non-existent entry of an "ordered-by user" list or leaf-list. I don't think this is correct. The new text makes it impossible to move an existing ordered-by user list entry, which should be possible. 4.8.6 says: The "point" query parameter is used to specify the insertion point for a data resource that is being created or moved within an "ordered-by user" list or leaf-list. See below. > Notes > ----- > First, Section 3.5 (Data Resource) says that "list" and "leaf-leaf" > are not a data resources: > > A data resource represents a YANG data node that is a descendant node > of a datastore resource. Each YANG-defined data node can be uniquely > targeted by the request-line of an HTTP method. Containers, leafs, > leaf-list entries, list entries, anydata nodes, and anyxml nodes are > data resources. > > Second, these query parameters only make sense when targeting a > non-existent entry. If the entry does not exist, then PUT is being > used like a POST: to create and place an item in an ordered list. > However, if the entry exists, then PUT is being used to both replace > the contents and (presumably) re-place the order in the list; but this > doesn't make sense because: > > 1) "insert" defaults to "last". > 2) there is no "insert" value to indicate "keep existing placement". I think this is the real problem. It should be (and the intention was): 1. if "insert" isn't present and a new entry is created, the new entry will be appended to the end of the list. 2. if "insert" isn't present a an entry is modified (PUT), the entry keeps its place in the list. /martin > 3) having to concoct valid "insert" and "point" values is hard. > > Thus indiscriminate PUTs would move entries to the end, which can't be > desired... > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8040 (draft-ietf-netconf-restconf-18) > -------------------------------------- > Title : RESTCONF Protocol > Publication Date : January 2017 > Author(s) : A. Bierman, M. Bjorklund, K. Watsen > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Sep 2 07:42:37 2020 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 BD58B3A0E0F for ; Wed, 2 Sep 2020 07:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 1mHyWt1-jo3c for ; Wed, 2 Sep 2020 07:42:33 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::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 C138D3A0825 for ; Wed, 2 Sep 2020 07:42:32 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id h19so6187458ljg.13 for ; Wed, 02 Sep 2020 07:42:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jhJ2V4nrh/VUw5aI6Mp25ptO4xaB2Ynelkn+DFKpa9E=; b=PisRKLA33Hh70HJcoiGLc5DUReGorEDoHoQnfssXaBFUgxRWGowcbe6e6KuAqaWJ8E lSws9lFAQy2uE9spIzHsUiKsquav76/uNAEzZ97e9DBaUPvgWTHtoSimfAnrta7JMDCW jLbYg4/AIIYvDAmqXPmVT/t1uivXNfYyLk+c9Glxeuh1+xt1pN2zMYig5NIXsscYjRQC j8adAZ1YXQHpyjinn/ihYnJkj0EAv8rHz6LMl3G65JTjUX6PyOcPz482DUOqH7c3h8gZ pjRC+N58GDWBAX6xlTeTk4jaqtKZlWNgQeTZJthRZ2dtE8CFimvX4OZ6GMMLoiGaYgUL Xz2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jhJ2V4nrh/VUw5aI6Mp25ptO4xaB2Ynelkn+DFKpa9E=; b=ffA8rLWlpsa+yfuz/QAekabXEuIfKe9gAabFuhFSQO3dc3Z5lyhA/cK7EFXeSYiBO3 tgnj4Dvewi00gVjOqZ9lDPk/D2I8MdbhjmSKB6lQl0yREHUQ5xzR4I/8a+RJK+4D+u5g xijrqICfXpu6hJI44jIlaMsicfnZ7xmWBzu9loZvDDGv/Een+6t5rZ0ZPiY8NHFGtt2u zMtLk2YZinOp5NCbgFAwVEbBqPHfVKekX1g9XoOLeO9my6KxSa3K1PBU/2fJsL4tqDLx xN062dbR048Okg8jo93nr3WqvgBqrFiY3LWzpRGv+B00uHSpKh0fqqhmniqDx7LMFVSY AJjw== X-Gm-Message-State: AOAM53372mb0wLxd3wwg6n7hRDZvUECfYg3OlbtroJUFUdcSBPO9Qtcc OziuV019asHmOgUZaxugTkpZaUQyQcNzS/rE6mmEVw== X-Google-Smtp-Source: ABdhPJw3rD+X91jUAAwcmY5Lwz0JeNH0OCETeKeSpmAK1ovNrhzA2FccL7tvPHKDDSv8oFcltTWt/TT+Sbie2cxN4bw= X-Received: by 2002:a2e:7c14:: with SMTP id x20mr3710982ljc.220.1599057750623; Wed, 02 Sep 2020 07:42:30 -0700 (PDT) MIME-Version: 1.0 References: <20200901173726.8E404F40785@rfc-editor.org> <20200902.082718.1225293218517439729.id@4668.se> In-Reply-To: <20200902.082718.1225293218517439729.id@4668.se> From: Andy Bierman Date: Wed, 2 Sep 2020 07:42:19 -0700 Message-ID: To: =?UTF-8?Q?Martin_Bj=C3=B6rklund?= Cc: RFC Editor , Kent Watsen , Warren Kumari , Robert Wilton , Kent Watsen , Mahesh Jethanandani , Netconf Content-Type: multipart/alternative; boundary="00000000000033a21905ae55a58b" Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6271) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 14:42:35 -0000 --00000000000033a21905ae55a58b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 1, 2020 at 11:27 PM Martin Bj=C3=B6rklund wr= ote: > Hi, > > RFC Errata System wrote: > > The following errata report has been submitted for RFC8040, > > "RESTCONF Protocol". > > > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid6271 > > > > -------------------------------------- > > Type: Technical > > Reported by: Kent Watsen > > > > Section: 4.5 > > > > Original Text > > ------------- > > The "insert" (Section 4.8.5) and "point" (Section 4.8.6) query > > parameters MUST be supported by the PUT method for data resources. > > These parameters are only allowed if the list or leaf-list is > > "ordered-by user". > > > > > > Corrected Text > > -------------- > > The "insert" (Section 4.8.5) and "point" (Section 4.8.6) query > > parameters MUST be supported by the PUT method for data resources. > > These parameters are only allowed if the target resource is a > > non-existent entry of an "ordered-by user" list or leaf-list. > > I don't think this is correct. The new text makes it impossible to > move an existing ordered-by user list entry, which should be > possible. 4.8.6 says: > > The "point" query parameter is used to specify the insertion point > for a data resource that is being created or moved within an > "ordered-by user" list or leaf-list. > > See below. > > > > Notes > > ----- > > First, Section 3.5 (Data Resource) says that "list" and "leaf-leaf" > > are not a data resources: > > > > A data resource represents a YANG data node that is a descendant node > > of a datastore resource. Each YANG-defined data node can be uniquely > > targeted by the request-line of an HTTP method. Containers, leafs, > > leaf-list entries, list entries, anydata nodes, and anyxml nodes are > > data resources. > > > > Second, these query parameters only make sense when targeting a > > non-existent entry. If the entry does not exist, then PUT is being > > used like a POST: to create and place an item in an ordered list. > > However, if the entry exists, then PUT is being used to both replace > > the contents and (presumably) re-place the order in the list; but this > > doesn't make sense because: > > > > 1) "insert" defaults to "last". > > 2) there is no "insert" value to indicate "keep existing placement". > > I think this is the real problem. It should be (and the intention was): > > 1. if "insert" isn't present and a new entry is created, the new > entry will be appended to the end of the list. > > 2. if "insert" isn't present a an entry is modified (PUT), the > entry keeps its place in the list. > > Agreed. So the errata only applies to the "insert" query parameter. > /martin > Andy > > > > > > 3) having to concoct valid "insert" and "point" values is hard. > > > > Thus indiscriminate PUTs would move entries to the end, which can't be > > desired... > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC8040 (draft-ietf-netconf-restconf-18) > > -------------------------------------- > > Title : RESTCONF Protocol > > Publication Date : January 2017 > > Author(s) : A. Bierman, M. Bjorklund, K. Watsen > > Category : PROPOSED STANDARD > > Source : Network Configuration > > Area : Operations and Management > > Stream : IETF > > Verifying Party : IESG > > > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > --00000000000033a21905ae55a58b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Sep 1, 2020 at 11:27 PM Marti= n Bj=C3=B6rklund <mbj+ietf@4668.se= > wrote:
= Hi,

RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> The following errata report has been submitted for RFC8040,
> "RESTCONF Protocol".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6271
>
> --------------------------------------
> Type: Technical
> Reported by: Kent Watsen <kent+ietf@watsen.net>
>
> Section: 4.5
>
> Original Text
> -------------
>=C2=A0 =C2=A0 The "insert" (Section 4.8.5) and "point&qu= ot; (Section 4.8.6) query
>=C2=A0 =C2=A0 parameters MUST be supported by the PUT method for data r= esources.
>=C2=A0 =C2=A0 These parameters are only allowed if the list or leaf-lis= t is
>=C2=A0 =C2=A0 "ordered-by user".
>
>
> Corrected Text
> --------------
>=C2=A0 =C2=A0 The "insert" (Section 4.8.5) and "point&qu= ot; (Section 4.8.6) query
>=C2=A0 =C2=A0 parameters MUST be supported by the PUT method for data r= esources.
>=C2=A0 =C2=A0 These parameters are only allowed if the target resource = is a
>=C2=A0 =C2=A0 non-existent entry of an "ordered-by user" list= or leaf-list.

I don't think this is correct.=C2=A0 The new text makes it impossible t= o
move an existing ordered-by user list entry, which should be
possible.=C2=A0 4.8.6 says:

=C2=A0 =C2=A0The "point" query parameter is used to specify the i= nsertion point
=C2=A0 =C2=A0for a data resource that is being created or moved within an =C2=A0 =C2=A0"ordered-by user" list or leaf-list.

See below.


> Notes
> -----
> First, Section 3.5 (Data Resource) says that "list" and &quo= t;leaf-leaf"
> are not a data resources:
>
>=C2=A0 =C2=A0A data resource represents a YANG data node that is a desc= endant node
>=C2=A0 =C2=A0of a datastore resource. Each YANG-defined data node can b= e uniquely
>=C2=A0 =C2=A0targeted by the request-line of an HTTP method. Containers= , leafs,
>=C2=A0 =C2=A0leaf-list entries, list entries, anydata nodes, and anyxml= nodes are
>=C2=A0 =C2=A0data resources.
>
> Second, these query parameters only make sense when targeting a
> non-existent entry.=C2=A0 If the entry does not exist, then PUT is bei= ng
> used like a POST: to create and place an item in an ordered list.
> However, if the entry exists, then PUT is being used to both replace > the contents and (presumably) re-place the order in the list; but this=
> doesn't make sense because:
>
>=C2=A0 =C2=A01) "insert" defaults to "last".
>=C2=A0 =C2=A02) there is no "insert" value to indicate "= keep existing placement".

I think this is the real problem.=C2=A0 It should be (and the intention was= ):

=C2=A0 1.=C2=A0 if "insert" isn't present and a new entry is = created, the new
=C2=A0 =C2=A0 =C2=A0 entry will be appended to the end of the list.

=C2=A0 2.=C2=A0 if "insert" isn't present a an entry is modif= ied (PUT), the
=C2=A0 =C2=A0 =C2=A0 entry keeps its place in the list.




Agreed.= =C2=A0 So the errata only applies to the=C2=A0 "insert" query par= ameter.




/martin


Andy
= =C2=A0




>=C2=A0 =C2=A03) having to concoct valid "insert" and "po= int" values is hard.
>
> Thus indiscriminate PUTs would move entries to the end, which can'= t be
> desired...
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary= , please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party=C2=A0
> can log in to change the status and edit the report, if necessary. >
> --------------------------------------
> RFC8040 (draft-ietf-netconf-restconf-18)
> --------------------------------------
> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: RESTCONF= Protocol
> Publication Date=C2=A0 =C2=A0 : January 2017
> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: A. Bierman, M. Bjo= rklund, K. Watsen
> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD<= br> > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Network Confi= guration
> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Operatio= ns and Management
> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
>
> _______________________________________________
> netconf mailing list
> netconf@ietf.org=
> https://www.ietf.org/mailman/listinfo/netconf<= br>
--00000000000033a21905ae55a58b-- From nobody Wed Sep 2 09:24:06 2020 Return-Path: <010001744fa1d4f9-c6c34f02-e5c6-4078-9244-c0bd567ae2a2-000000@amazonses.watsen.net> 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 893983A1281 for ; Wed, 2 Sep 2020 09:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 8MWhn-DmCyFk for ; Wed, 2 Sep 2020 09:24:03 -0700 (PDT) Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1A4A3A1254 for ; Wed, 2 Sep 2020 09:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1599063840; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=BZIgsxyt2pw/VT84KdJoChqT0O8jeLbhK5TmWaqj6Fk=; b=OH1MYlpM73RWroiNqHjHlU4YmN/Q2k7B6sb6KnfIMuKi9pNMqmYNrUE29AClcNvc gaYw/Vg453X4jniy1hkxPxGu+lXGAuT08w7ev6OjqvLioX0u3lcux7Kbk+zMe7PotUj nEVvcK5eAgQ7HDU3elm8eJKd+voqBpUHyWWsaXi4= From: Kent Watsen Message-ID: <010001744fa1d4f9-c6c34f02-e5c6-4078-9244-c0bd567ae2a2-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7499ECD7-36FB-47C5-A4B0-7B4AB60793A6" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 2 Sep 2020 16:24:00 +0000 In-Reply-To: Cc: =?utf-8?Q?Martin_Bj=C3=B6rklund?= , Kent Watsen , Warren Kumari , Robert Wilton , Mahesh Jethanandani , "netconf@ietf.org" To: Andy Bierman References: <20200901173726.8E404F40785@rfc-editor.org> <20200902.082718.1225293218517439729.id@4668.se> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.09.02-54.240.48.94 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6271) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 16:24:05 -0000 --Apple-Mail=_7499ECD7-36FB-47C5-A4B0-7B4AB60793A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [removing RFC Editor] > RFC Errata System > wrote: > > The following errata report has been submitted for RFC8040, > > "RESTCONF Protocol". > >=20 > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid6271 = > >=20 > > -------------------------------------- > > Type: Technical > > Reported by: Kent Watsen > > >=20 > > Section: 4.5 > >=20 > > Original Text > > ------------- > > The "insert" (Section 4.8.5) and "point" (Section 4.8.6) query > > parameters MUST be supported by the PUT method for data = resources. > > These parameters are only allowed if the list or leaf-list is > > "ordered-by user". > >=20 > >=20 > > Corrected Text > > -------------- > > The "insert" (Section 4.8.5) and "point" (Section 4.8.6) query > > parameters MUST be supported by the PUT method for data = resources. > > These parameters are only allowed if the target resource is a > > non-existent entry of an "ordered-by user" list or leaf-list. >=20 > I don't think this is correct. The new text makes it impossible to > move an existing ordered-by user list entry, which should be > possible. 4.8.6 says: >=20 > The "point" query parameter is used to specify the insertion point > for a data resource that is being created or moved within an > "ordered-by user" list or leaf-list. >=20 > See below. >=20 >=20 > > Notes > > ----- > > First, Section 3.5 (Data Resource) says that "list" and "leaf-leaf" > > are not a data resources: > >=20 > > A data resource represents a YANG data node that is a descendant = node > > of a datastore resource. Each YANG-defined data node can be = uniquely > > targeted by the request-line of an HTTP method. Containers, leafs, > > leaf-list entries, list entries, anydata nodes, and anyxml nodes = are > > data resources. > >=20 > > Second, these query parameters only make sense when targeting a > > non-existent entry. If the entry does not exist, then PUT is being > > used like a POST: to create and place an item in an ordered list. > > However, if the entry exists, then PUT is being used to both replace > > the contents and (presumably) re-place the order in the list; but = this > > doesn't make sense because: > >=20 > > 1) "insert" defaults to "last". > > 2) there is no "insert" value to indicate "keep existing = placement". >=20 > I think this is the real problem. It should be (and the intention = was): >=20 > 1. if "insert" isn't present and a new entry is created, the new > entry will be appended to the end of the list. >=20 > 2. if "insert" isn't present a an entry is modified (PUT), the > entry keeps its place in the list. >=20 >=20 >=20 >=20 > Agreed. So the errata only applies to the "insert" query parameter. We can cancel and resubmit errata as needed. I think there might be two Errata: 1) for the r/list/list entry/ fix NEWER: The "insert" (Section 4.8.5) and "point" (Section 4.8.6) query parameters MUST be supported by the PUT method for data = resources. These parameters are only allowed if the target resource is an entry of an "ordered-by user" list or leaf-list. 2) for the =E2=80=9Cinsert=E2=80=9D query parameter In Section 4.8.5: The "insert" Query Parameter OLD: The default value is "last". This parameter is only supported for the POST and PUT methods. = It 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 user=E2=80=9D. NEW: The default value is =E2=80=9Clast=E2=80=9D, with exception to = when used with PUT and the target resource already exists, in which case the default is to replace the target resource without altering its position = in the "ordered-by user=E2=80=9D list or leaf-list. This parameter is only supported for the POST and PUT methods. It is also only supported if the target resource is a data = resource=20 that is an entry of an "ordered-by user" list or leaf-list. Thoughts? Separately, but related, is it possible to PUT on an "ordered-by user=E2=80= =9D leaf-list? Presumably, the operation changes the implicit = =E2=80=9Ckey=E2=80=9D field... K. --Apple-Mail=_7499ECD7-36FB-47C5-A4B0-7B4AB60793A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 [removing RFC Editor]

RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> The following errata report has been submitted for RFC8040,
> "RESTCONF Protocol".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6271
>
> --------------------------------------
> Type: Technical
> Reported by: Kent Watsen <kent+ietf@watsen.net>
>
> Section: 4.5
>
> Original Text
> -------------
>    The "insert" (Section 4.8.5) and "point" (Section = 4.8.6) query
>    parameters MUST be supported by the PUT method for = data resources.
>    These parameters are only allowed if the list or = leaf-list is
>    "ordered-by user".
>
>
> Corrected Text
> --------------
>    The "insert" (Section 4.8.5) and "point" (Section = 4.8.6) query
>    parameters MUST be supported by the PUT method for = data resources.
>    These parameters are only allowed if the target = resource is a
>    non-existent entry of an "ordered-by user" list or = leaf-list.

I don't think this is correct.  The new text makes it impossible = to
move an existing ordered-by user list entry, which should be
possible.  4.8.6 says:

   The "point" query parameter is used to specify the = insertion point
   for a data resource that is being created or moved within = an
   "ordered-by user" list or leaf-list.

See below.


> Notes
> -----
> First, Section 3.5 (Data Resource) says that "list" and = "leaf-leaf"
> are not a data resources:
>
>   A data resource represents a YANG data node that is a = descendant node
>   of a datastore resource. Each YANG-defined data node = can be uniquely
>   targeted by the request-line of an HTTP method. = Containers, leafs,
>   leaf-list entries, list entries, anydata nodes, and = anyxml nodes are
>   data resources.
>
> Second, these query parameters only make sense when targeting a
> non-existent entry.  If the entry does not exist, then PUT is = being
> used like a POST: to create and place an item in an ordered = list.
> However, if the entry exists, then PUT is being used to both = replace
> the contents and (presumably) re-place the order in the list; but = this
> doesn't make sense because:
>
>   1) "insert" defaults to "last".
>   2) there is no "insert" value to indicate "keep = existing placement".

I think this is the real problem.  It should be (and the intention = was):

  1.  if "insert" isn't present and a new entry is created, = the new
      entry will be appended to the end of the list.

  2.  if "insert" isn't present a an entry is modified (PUT), = the
      entry keeps its place in the list.




Agreed.  So the errata only applies to the  = "insert" query parameter.

We can cancel and resubmit errata as = needed.

I think there might be two = Errata:

1) for the r/list/list = entry/ fix

    = NEWER:
        The "insert" (Section = 4.8.5) and "point" (Section 4.8.6) query
    =     parameters MUST be supported by the PUT method for data = resources.
        These parameters are = only allowed if the target resource is an
      =   entry of an "ordered-by user" list or leaf-list.

2) for the =E2=80=9Cinsert=E2=80=9D query = parameter

    In Section = 4.8.5: The "insert" Query Parameter

    OLD:

       The default = value is "last".

       This parameter is only supported = for the POST and PUT methods.  It 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 user=E2=80=9D.

    NEW:

       The default value is =E2=80=9Clast=E2= =80=9D, with exception to when used with PUT
       and the target resource already = exists, in which case the default
       is to = replace the target resource without altering its position in = the
       "ordered-by user=E2=80=9D list or = leaf-list.

  =      This parameter is only supported for the POST and = PUT methods.
       It is also only = supported if the target resource is a data = resource 
       that is = an entry of an "ordered-by user" list or leaf-list.
Thoughts?

Separately, but related, is it possible to PUT on = an "ordered-by user=E2=80=9D leaf-list?   Presumably, the operation = changes the implicit =E2=80=9Ckey=E2=80=9D field...


K.



= --Apple-Mail=_7499ECD7-36FB-47C5-A4B0-7B4AB60793A6-- From nobody Wed Sep 2 12:57:09 2020 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 7928C3A0EDA for ; Wed, 2 Sep 2020 12:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.616 X-Spam-Level: X-Spam-Status: No, score=-0.616 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.482, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=MumjCpjd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=N1KGM7sr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFhrbNh_Jtm9 for ; Wed, 2 Sep 2020 12:56:59 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F073A0EB5 for ; Wed, 2 Sep 2020 12:56:55 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id C80065C01B7; Wed, 2 Sep 2020 15:56:54 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 02 Sep 2020 15:56:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm2; bh= rdheuAnu8LL5kU+/Mxq/5vGI0mIO+Wkj524/r5Fiid8=; b=MumjCpjdzbxTU5N7 SNS52A89xj9Cmw0qf4zNyW5yc6T+iNNJs23W/chyaMSY63VXC0vMrtM7e014Yceq vgWRNZNcKNpOPadv9HL4Zq7/c2O2480UUb0kjTx66j47qz3xxjCcPrQpou23REel Nm7zaB4h30Uxw/buyWQfdFRRHZbWn8G3c12/WYv4y3WKVNyulwgHy2k71AK0vTyJ 4RriAsaJn89x1MDztMbRqvVNjtV7/YjHM0nocwHZizbowcA9ERXJu9jiNDDzDg9e eyK+t8J0hnMObNkzyV65XvyejRTlq75gmnNpVAkFgkhI6cljOFVT2gje8tdLH7qE QcodsA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=rdheuAnu8LL5kU+/Mxq/5vGI0mIO+Wkj524/r5Fii d8=; b=N1KGM7sr3fDtA8TbV6I8zMcWWCBENmrxO0LeRODG/u7JaeC5xE2h1NIkY 7DS0B8Jm5AuNK8Wp9No0HlQEacoCGCd6sHSdm8QVzOIwBGQYWDspiA3rg++zxgoy rJ+oA1mcz9yqAQlv5DCLaibyvlE4OP94VobdxRfkXsLGLGUZ2HxN9r1HPS4ta8Zd yP5J0+k1YdmS0owHe9B5RYZYOPiT/pb6cyJkc1VvffBZxSgLNzn1vtahTLp65/5j f91ajkmpIL482gzZe5n3S7VNyzOCJzQ6OPxjxE8M0GBYhsgKfxUPmmyY8yPUVXok s9yX0r1ytmknX9Uv+l6/Xx1AQ4HCg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudefledgudegfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesth gsredtredtjeenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdo ihgvthhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpeejleekieeufefftdevud egueehteektdduleegkeeuteefjefgueelieejgfdtjeenucffohhmrghinheprhhftgdq vgguihhtohhrrdhorhhgnecukfhppeduheekrddujeegrdegrdeggeenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmsghjodhivghtfhesgeei ieekrdhsvg X-ME-Proxy: Received: from localhost (unknown [158.174.4.44]) by mail.messagingengine.com (Postfix) with ESMTPA id 12A14306005F; Wed, 2 Sep 2020 15:56:52 -0400 (EDT) Date: Wed, 02 Sep 2020 21:56:51 +0200 (CEST) Message-Id: <20200902.215651.2161361777301988365.id@4668.se> To: kent+ietf@watsen.net Cc: andy@yumaworks.com, mbj+ietf@4668.se, kwatsen@juniper.net, warren@kumari.net, rwilton@cisco.com, mjethanandani@gmail.com, netconf@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <010001744fa1d4f9-c6c34f02-e5c6-4078-9244-c0bd567ae2a2-000000@email.amazonses.com> References: <20200902.082718.1225293218517439729.id@4668.se> <010001744fa1d4f9-c6c34f02-e5c6-4078-9244-c0bd567ae2a2-000000@email.amazonses.com> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6271) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 19:57:08 -0000 S2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0PiB3cm90ZToNCj4gW3JlbW92aW5nIFJG QyBFZGl0b3JdDQo+IA0KPiA+IFJGQyBFcnJhdGEgU3lzdGVtIDxyZmMtZWRpdG9yQHJmYy1lZGl0 b3Iub3JnIDxtYWlsdG86cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZz4+IHdyb3RlOg0KPiA+ID4g VGhlIGZvbGxvd2luZyBlcnJhdGEgcmVwb3J0IGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3IgUkZDODA0 MCwNCj4gPiA+ICJSRVNUQ09ORiBQcm90b2NvbCIuDQo+ID4gPiANCj4gPiA+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiBZb3UgbWF5IHJldmlldyB0aGUgcmVw b3J0IGJlbG93IGFuZCBhdDoNCj4gPiA+IGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0 YS9laWQ2MjcxIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGEvZWlkNjI3MT4NCj4g PiA+IA0KPiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+ IFR5cGU6IFRlY2huaWNhbA0KPiA+ID4gUmVwb3J0ZWQgYnk6IEtlbnQgV2F0c2VuIDxrZW50K2ll dGZAd2F0c2VuLm5ldCA8bWFpbHRvOmtlbnQlMkJpZXRmQHdhdHNlbi5uZXQ+Pg0KPiA+ID4gDQo+ ID4gPiBTZWN0aW9uOiA0LjUNCj4gPiA+IA0KPiA+ID4gT3JpZ2luYWwgVGV4dA0KPiA+ID4gLS0t LS0tLS0tLS0tLQ0KPiA+ID4gICAgVGhlICJpbnNlcnQiIChTZWN0aW9uIDQuOC41KSBhbmQgInBv aW50IiAoU2VjdGlvbiA0LjguNikgcXVlcnkNCj4gPiA+ICAgIHBhcmFtZXRlcnMgTVVTVCBiZSBz dXBwb3J0ZWQgYnkgdGhlIFBVVCBtZXRob2QgZm9yIGRhdGEgcmVzb3VyY2VzLg0KPiA+ID4gICAg VGhlc2UgcGFyYW1ldGVycyBhcmUgb25seSBhbGxvd2VkIGlmIHRoZSBsaXN0IG9yIGxlYWYtbGlz dCBpcw0KPiA+ID4gICAgIm9yZGVyZWQtYnkgdXNlciIuDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4g Q29ycmVjdGVkIFRleHQNCj4gPiA+IC0tLS0tLS0tLS0tLS0tDQo+ID4gPiAgICBUaGUgImluc2Vy dCIgKFNlY3Rpb24gNC44LjUpIGFuZCAicG9pbnQiIChTZWN0aW9uIDQuOC42KSBxdWVyeQ0KPiA+ ID4gICAgcGFyYW1ldGVycyBNVVNUIGJlIHN1cHBvcnRlZCBieSB0aGUgUFVUIG1ldGhvZCBmb3Ig ZGF0YSByZXNvdXJjZXMuDQo+ID4gPiAgICBUaGVzZSBwYXJhbWV0ZXJzIGFyZSBvbmx5IGFsbG93 ZWQgaWYgdGhlIHRhcmdldCByZXNvdXJjZSBpcyBhDQo+ID4gPiAgICBub24tZXhpc3RlbnQgZW50 cnkgb2YgYW4gIm9yZGVyZWQtYnkgdXNlciIgbGlzdCBvciBsZWFmLWxpc3QuDQo+ID4gDQo+ID4g SSBkb24ndCB0aGluayB0aGlzIGlzIGNvcnJlY3QuICBUaGUgbmV3IHRleHQgbWFrZXMgaXQgaW1w b3NzaWJsZSB0bw0KPiA+IG1vdmUgYW4gZXhpc3Rpbmcgb3JkZXJlZC1ieSB1c2VyIGxpc3QgZW50 cnksIHdoaWNoIHNob3VsZCBiZQ0KPiA+IHBvc3NpYmxlLiAgNC44LjYgc2F5czoNCj4gPiANCj4g PiAgICBUaGUgInBvaW50IiBxdWVyeSBwYXJhbWV0ZXIgaXMgdXNlZCB0byBzcGVjaWZ5IHRoZSBp bnNlcnRpb24gcG9pbnQNCj4gPiAgICBmb3IgYSBkYXRhIHJlc291cmNlIHRoYXQgaXMgYmVpbmcg Y3JlYXRlZCBvciBtb3ZlZCB3aXRoaW4gYW4NCj4gPiAgICAib3JkZXJlZC1ieSB1c2VyIiBsaXN0 IG9yIGxlYWYtbGlzdC4NCj4gPiANCj4gPiBTZWUgYmVsb3cuDQo+ID4gDQo+ID4gDQo+ID4gPiBO b3Rlcw0KPiA+ID4gLS0tLS0NCj4gPiA+IEZpcnN0LCBTZWN0aW9uIDMuNSAoRGF0YSBSZXNvdXJj ZSkgc2F5cyB0aGF0ICJsaXN0IiBhbmQgImxlYWYtbGVhZiINCj4gPiA+IGFyZSBub3QgYSBkYXRh IHJlc291cmNlczoNCj4gPiA+IA0KPiA+ID4gICBBIGRhdGEgcmVzb3VyY2UgcmVwcmVzZW50cyBh IFlBTkcgZGF0YSBub2RlIHRoYXQgaXMgYSBkZXNjZW5kYW50IG5vZGUNCj4gPiA+ICAgb2YgYSBk YXRhc3RvcmUgcmVzb3VyY2UuIEVhY2ggWUFORy1kZWZpbmVkIGRhdGEgbm9kZSBjYW4gYmUgdW5p cXVlbHkNCj4gPiA+ICAgdGFyZ2V0ZWQgYnkgdGhlIHJlcXVlc3QtbGluZSBvZiBhbiBIVFRQIG1l dGhvZC4gQ29udGFpbmVycywgbGVhZnMsDQo+ID4gPiAgIGxlYWYtbGlzdCBlbnRyaWVzLCBsaXN0 IGVudHJpZXMsIGFueWRhdGEgbm9kZXMsIGFuZCBhbnl4bWwgbm9kZXMgYXJlDQo+ID4gPiAgIGRh dGEgcmVzb3VyY2VzLg0KPiA+ID4gDQo+ID4gPiBTZWNvbmQsIHRoZXNlIHF1ZXJ5IHBhcmFtZXRl cnMgb25seSBtYWtlIHNlbnNlIHdoZW4gdGFyZ2V0aW5nIGENCj4gPiA+IG5vbi1leGlzdGVudCBl bnRyeS4gIElmIHRoZSBlbnRyeSBkb2VzIG5vdCBleGlzdCwgdGhlbiBQVVQgaXMgYmVpbmcNCj4g PiA+IHVzZWQgbGlrZSBhIFBPU1Q6IHRvIGNyZWF0ZSBhbmQgcGxhY2UgYW4gaXRlbSBpbiBhbiBv cmRlcmVkIGxpc3QuDQo+ID4gPiBIb3dldmVyLCBpZiB0aGUgZW50cnkgZXhpc3RzLCB0aGVuIFBV VCBpcyBiZWluZyB1c2VkIHRvIGJvdGggcmVwbGFjZQ0KPiA+ID4gdGhlIGNvbnRlbnRzIGFuZCAo cHJlc3VtYWJseSkgcmUtcGxhY2UgdGhlIG9yZGVyIGluIHRoZSBsaXN0OyBidXQgdGhpcw0KPiA+ ID4gZG9lc24ndCBtYWtlIHNlbnNlIGJlY2F1c2U6DQo+ID4gPiANCj4gPiA+ICAgMSkgImluc2Vy dCIgZGVmYXVsdHMgdG8gImxhc3QiLg0KPiA+ID4gICAyKSB0aGVyZSBpcyBubyAiaW5zZXJ0IiB2 YWx1ZSB0byBpbmRpY2F0ZSAia2VlcCBleGlzdGluZyBwbGFjZW1lbnQiLg0KPiA+IA0KPiA+IEkg dGhpbmsgdGhpcyBpcyB0aGUgcmVhbCBwcm9ibGVtLiAgSXQgc2hvdWxkIGJlIChhbmQgdGhlIGlu dGVudGlvbiB3YXMpOg0KPiA+IA0KPiA+ICAgMS4gIGlmICJpbnNlcnQiIGlzbid0IHByZXNlbnQg YW5kIGEgbmV3IGVudHJ5IGlzIGNyZWF0ZWQsIHRoZSBuZXcNCj4gPiAgICAgICBlbnRyeSB3aWxs IGJlIGFwcGVuZGVkIHRvIHRoZSBlbmQgb2YgdGhlIGxpc3QuDQo+ID4gDQo+ID4gICAyLiAgaWYg Imluc2VydCIgaXNuJ3QgcHJlc2VudCBhIGFuIGVudHJ5IGlzIG1vZGlmaWVkIChQVVQpLCB0aGUN Cj4gPiAgICAgICBlbnRyeSBrZWVwcyBpdHMgcGxhY2UgaW4gdGhlIGxpc3QuDQo+ID4gDQo+ID4g DQo+ID4gDQo+ID4gDQo+ID4gQWdyZWVkLiAgU28gdGhlIGVycmF0YSBvbmx5IGFwcGxpZXMgdG8g dGhlICAiaW5zZXJ0IiBxdWVyeSBwYXJhbWV0ZXIuDQo+IA0KPiBXZSBjYW4gY2FuY2VsIGFuZCBy ZXN1Ym1pdCBlcnJhdGEgYXMgbmVlZGVkLg0KPiANCj4gSSB0aGluayB0aGVyZSBtaWdodCBiZSB0 d28gRXJyYXRhOg0KPiANCj4gMSkgZm9yIHRoZSByL2xpc3QvbGlzdCBlbnRyeS8gZml4DQo+IA0K PiAgICAgTkVXRVI6DQo+ICAgICAgICAgVGhlICJpbnNlcnQiIChTZWN0aW9uIDQuOC41KSBhbmQg InBvaW50IiAoU2VjdGlvbiA0LjguNikgcXVlcnkNCj4gICAgICAgICBwYXJhbWV0ZXJzIE1VU1Qg YmUgc3VwcG9ydGVkIGJ5IHRoZSBQVVQgbWV0aG9kIGZvciBkYXRhIHJlc291cmNlcy4NCj4gICAg ICAgICBUaGVzZSBwYXJhbWV0ZXJzIGFyZSBvbmx5IGFsbG93ZWQgaWYgdGhlIHRhcmdldCByZXNv dXJjZSBpcyBhbg0KPiAgICAgICAgIGVudHJ5IG9mIGFuICJvcmRlcmVkLWJ5IHVzZXIiIGxpc3Qg b3IgbGVhZi1saXN0Lg0KDQpUaGlzIGlzbid0IHF1aXRlIGNvcnJlY3QgKHRoZSB0YXJnZXQgcmVz b3VyY2UgaW4gUE9TVCBpcyBub3QgYSBsaXN0DQplbnRyeSksIGFuZCBpdCBpc24ndCBuZWVkZWQg SU1PLiAgVGhlIHRleHQgaW4gNC44LjUgYW5kIDQuOC42IHNheXMgdGhlDQpzYW1lIHRoaW5nIGFs cmVhZHksIHNvIHdlIGRvbid0IG5lZWQgdG8gc2F5IGl0IGhlcmUgYXMgd2VsbC4gIEVzcC4gbm90 DQppbiBhbiBlcnJhdGEuDQoNCj4gMikgZm9yIHRoZSDigJxpbnNlcnTigJ0gcXVlcnkgcGFyYW1l dGVyDQo+IA0KPiAgICAgSW4gU2VjdGlvbiA0LjguNTogVGhlICJpbnNlcnQiIFF1ZXJ5IFBhcmFt ZXRlcg0KPiANCj4gICAgIE9MRDoNCj4gDQo+ICAgICAgICBUaGUgZGVmYXVsdCB2YWx1ZSBpcyAi bGFzdCIuDQo+IA0KPiAgICAgICAgVGhpcyBwYXJhbWV0ZXIgaXMgb25seSBzdXBwb3J0ZWQgZm9y IHRoZSBQT1NUIGFuZCBQVVQgbWV0aG9kcy4gIEl0IGlzDQo+ICAgICAgICBhbHNvIG9ubHkgc3Vw cG9ydGVkIGlmIHRoZSB0YXJnZXQgcmVzb3VyY2UgaXMgYSBkYXRhIHJlc291cmNlLCBhbmQNCj4g ICAgICAgIHRoYXQgZGF0YSByZXByZXNlbnRzIGEgWUFORyBsaXN0IG9yIGxlYWYtbGlzdCB0aGF0 IGlzDQo+ICAgICAgICAib3JkZXJlZC1ieSB1c2Vy4oCdLg0KPiANCj4gICAgIE5FVzoNCj4gDQo+ ICAgICAgICBUaGUgZGVmYXVsdCB2YWx1ZSBpcyDigJxsYXN04oCdLCB3aXRoIGV4Y2VwdGlvbiB0 byB3aGVuIHVzZWQgd2l0aCBQVVQNCj4gICAgICAgIGFuZCB0aGUgdGFyZ2V0IHJlc291cmNlIGFs cmVhZHkgZXhpc3RzLCBpbiB3aGljaCBjYXNlIHRoZSBkZWZhdWx0DQo+ICAgICAgICBpcyB0byBy ZXBsYWNlIHRoZSB0YXJnZXQgcmVzb3VyY2Ugd2l0aG91dCBhbHRlcmluZyBpdHMgcG9zaXRpb24g aW4gdGhlDQo+ICAgICAgICAib3JkZXJlZC1ieSB1c2Vy4oCdIGxpc3Qgb3IgbGVhZi1saXN0Lg0K DQpPaywgYnV0IGlzIHRoZSBncmFtbWFyIGNvcnJlY3QgIndpdGggZXhjZXB0aW9uIHRvIHdoZW4u Li4iPw0KDQoNCj4gICAgICAgIFRoaXMgcGFyYW1ldGVyIGlzIG9ubHkgc3VwcG9ydGVkIGZvciB0 aGUgUE9TVCBhbmQgUFVUIG1ldGhvZHMuDQo+ICAgICAgICBJdCBpcyBhbHNvIG9ubHkgc3VwcG9y dGVkIGlmIHRoZSB0YXJnZXQgcmVzb3VyY2UgaXMgYSBkYXRhIHJlc291cmNlIA0KPiAgICAgICAg dGhhdCBpcyBhbiBlbnRyeSBvZiBhbiAib3JkZXJlZC1ieSB1c2VyIiBsaXN0IG9yIGxlYWYtbGlz dC4NCg0KSSBwcmVmZXIgdGhlIG9sZCB0ZXh0IG92ZXIgdGhpcy4NCg0KPiANCj4gVGhvdWdodHM/ DQo+IA0KPiBTZXBhcmF0ZWx5LCBidXQgcmVsYXRlZCwgaXMgaXQgcG9zc2libGUgdG8gUFVUIG9u IGFuICJvcmRlcmVkLWJ5DQo+IHVzZXLigJ0gbGVhZi1saXN0PyAgIFByZXN1bWFibHksIHRoZSBv cGVyYXRpb24gY2hhbmdlcyB0aGUgaW1wbGljaXQNCj4g4oCca2V54oCdIGZpZWxkLi4uDQoNClNl Y3Rpb24gNC41IHNheXM6DQoNCiAgIElmIHRoZSB0YXJnZXQgcmVzb3VyY2UgcmVwcmVzZW50cyBh IFlBTkcgbGVhZi1saXN0LCB0aGVuIHRoZSBQVVQNCiAgIG1ldGhvZCBNVVNUIE5PVCBjaGFuZ2Ug dGhlIHZhbHVlIG9mIHRoZSBsZWFmLWxpc3QgaW5zdGFuY2UuDQoNCg0KL21hcnRpbg0K From nobody Wed Sep 2 12:57:36 2020 Return-Path: <010001745065426d-097daf26-8257-4b71-b504-e281734cfed6-000000@amazonses.watsen.net> 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 3A5DC3A0DCC for ; Wed, 2 Sep 2020 12:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 n1iZS52v3nng for ; Wed, 2 Sep 2020 12:57:34 -0700 (PDT) Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78C43A0DDC for ; Wed, 2 Sep 2020 12:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1599076647; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=LHpjiESSdGDymoiFFPY5pUw+LYefU7NpxtP6cICGYQw=; b=RH2nzzT3l17c3JAH0udT7CQ6+Brz8vggR2yYZYxNbCMVsxuB5N7vkiJmiMZ9UzHz RLJ14SRZ+Q3za2/nj9tEHNmcWFVzmQ4+cmJLgUpwrQqN7KQPmAtGSdrEZOY8aWaSb3c Zto+wly383VCEuXxDRyAnQExmqWhl+wjWVW6sGvg= From: Kent Watsen Message-ID: <010001745065426d-097daf26-8257-4b71-b504-e281734cfed6-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9544FF84-5626-4BBA-B708-B8444B6B226A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 2 Sep 2020 19:57:27 +0000 In-Reply-To: <010001744fa1d4f9-c6c34f02-e5c6-4078-9244-c0bd567ae2a2-000000@email.amazonses.com> Cc: Kent Watsen , "netconf@ietf.org" To: Andy Bierman , =?utf-8?Q?Martin_Bj=C3=B6rklund?= References: <20200901173726.8E404F40785@rfc-editor.org> <20200902.082718.1225293218517439729.id@4668.se> <010001744fa1d4f9-c6c34f02-e5c6-4078-9244-c0bd567ae2a2-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.09.02-54.240.48.92 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6271) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 19:57:35 -0000 --Apple-Mail=_9544FF84-5626-4BBA-B708-B8444B6B226A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 2, 2020, at 12:24 PM, Kent Watsen wrote: >=20 > NEW: >=20 > The default value is =E2=80=9Clast=E2=80=9D, with exception to = when used with PUT > and the target resource already exists, in which case the = default > is to replace the target resource without altering its position = in the > "ordered-by user=E2=80=9D list or leaf-list. The text above allows/suggests that are four =E2=80=9Cinsert=E2=80=9D = values MAY always be explicitly passed (and presumably processed). Do = we want to support the case where a PUT is used only to move an element? = i.e. the passed =E2=80=9Creplacement=E2=80=9D data is identical to what = exists on the server, only the insert/point have an effect? Or should this strategy be that the insert/point can always be passed = (in a PUT for an "ordered-by user=E2=80=9D list or leaf-list), but they = only have meaning (i.e., are processed) when/if the object is being = created, and otherwise ignored? K. --Apple-Mail=_9544FF84-5626-4BBA-B708-B8444B6B226A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


On Sep 2, 2020, at 12:24 PM, = Kent Watsen <kent+ietf@watsen.net> wrote:

 =   NEW:

      =  The default value is =E2=80=9Clast=E2=80=9D, with exception to = when used with PUT
       and the = target resource already exists, in which case the default
      =  is to replace the target resource without altering its position in = the
       "ordered-by user=E2=80=9D list = or leaf-list.

The = text above allows/suggests that are four =E2=80=9Cinsert=E2=80=9D values = MAY always be explicitly passed (and presumably processed).  Do we = want to support the case where a PUT is used only to move an element? =  i.e. the passed =E2=80=9Creplacement=E2=80=9D data is identical to = what exists on the server, only the insert/point have an = effect?

Or should this strategy be = that the insert/point can always be passed (in a PUT for an "ordered-by = user=E2=80=9D list or leaf-list), but they only have meaning (i.e., are = processed) when/if the object is being created, and otherwise = ignored?


K.

= --Apple-Mail=_9544FF84-5626-4BBA-B708-B8444B6B226A-- From nobody Wed Sep 2 13:07:54 2020 Return-Path: <01000174506ec41e-13dd2b0c-1591-4937-be1d-d58475f4a9b0-000000@amazonses.watsen.net> 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 4ECCE3A0E06 for ; Wed, 2 Sep 2020 13:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 prGkD2KrxFKT for ; Wed, 2 Sep 2020 13:07:52 -0700 (PDT) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBA4A3A0E05 for ; Wed, 2 Sep 2020 13:07:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1599077270; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=VjRXWiRS4S8YxsON2sQODh/0m67S287guS/zMrfSJH4=; b=FxgyvAUB1DasTX6GD3zcrTrpNnaQu4bx5YXjXU3fG0dFkQZ0MjIA65mcogv2fuwU NusYsQsjnCk67jKMPSF15M0iC3wJG3HV/HUnXF4aWgaTtDGQvBjSornTXQe6n3eeRFZ rMWnNSoUHfgFZkbdl1oXAZ/X+ipo1PDXDG2nHuoo= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Kent Watsen In-Reply-To: <20200902.215651.2161361777301988365.id@4668.se> Date: Wed, 2 Sep 2020 20:07:50 +0000 Cc: Andy Bierman , Warren Kumari , Robert Wilton , Mahesh Jethanandani , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000174506ec41e-13dd2b0c-1591-4937-be1d-d58475f4a9b0-000000@email.amazonses.com> References: <20200902.082718.1225293218517439729.id@4668.se> <010001744fa1d4f9-c6c34f02-e5c6-4078-9244-c0bd567ae2a2-000000@email.amazonses.com> <20200902.215651.2161361777301988365.id@4668.se> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.09.02-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6271) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 20:07:53 -0000 Hi Martin, >> NEWER: >> The "insert" (Section 4.8.5) and "point" (Section 4.8.6) query >> parameters MUST be supported by the PUT method for data = resources. >> These parameters are only allowed if the target resource is an >> entry of an "ordered-by user" list or leaf-list. >=20 > This isn't quite correct (the target resource in POST is not a list > entry), and it isn't needed IMO. The text in4.8.5 and 4.8.6 says the > same thing already, so we don't need to say it here as well. Esp. not > in an errata. But this is in Section 4.5, which only regards PUT. That said, I also noticed redundant text regarding where the = query-parameters are allowed. Generally, it seems such text should be = in Sections 4.8.5 and 4.8.6, more so than Section 4.5... >> 2) for the =E2=80=9Cinsert=E2=80=9D query parameter >>=20 >> In Section 4.8.5: The "insert" Query Parameter >>=20 >> OLD: >>=20 >> The default value is "last". >>=20 >> This parameter is only supported for the POST and PUT methods. = It 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 user=E2=80=9D. >>=20 >> NEW: >>=20 >> The default value is =E2=80=9Clast=E2=80=9D, with exception to = when used with PUT >> and the target resource already exists, in which case the = default >> is to replace the target resource without altering its position = in the >> "ordered-by user=E2=80=9D list or leaf-list. >=20 > Ok, but is the grammar correct "with exception to when..."? There=E2=80=99s a fork in this thread on this point. Let=E2=80=99s see = how that resolves first=E2=80=A6 >> This parameter is only supported for the POST and PUT methods. >> It is also only supported if the target resource is a data = resource=20 >> that is an entry of an "ordered-by user" list or leaf-list. >=20 > I prefer the old text over this. But Section 3.5 (Data Resource) clearly says that =E2=80=9Clist entry" = and "leaf-leaf entry" are data resources (not =E2=80=9Clist=E2=80=9D and = =E2=80=9Cleaf-list=E2=80=9D). >=20 >>=20 >> Thoughts? >>=20 >> Separately, but related, is it possible to PUT on an "ordered-by >> user=E2=80=9D leaf-list? Presumably, the operation changes the = implicit >> =E2=80=9Ckey=E2=80=9D field... >=20 > Section 4.5 says: >=20 > If the target resource represents a YANG leaf-list, then the PUT > method MUST NOTchange the value of the leaf-list instance. Ah-ha, very good. And, interestingly, if not "changing the value of the = leaf-list instance=E2=80=9D, then it seems the only thing it could be = used for it to move the entry=E2=80=99s position - right? >=20 > /Martin K. From nobody Wed Sep 2 13:24:49 2020 Return-Path: <01000174507dd788-18119adf-c886-42d0-973e-d76f351fff93-000000@amazonses.watsen.net> 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 15FDB3A0E92 for ; Wed, 2 Sep 2020 13:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 GBaeYo9_i0oG for ; Wed, 2 Sep 2020 13:24:46 -0700 (PDT) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E10973A0E8F for ; Wed, 2 Sep 2020 13:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1599078258; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=ccP2l/kjprO1VaDfHMZBjlei+IP6dkp7HU3suG/UlJI=; b=Q+rZzFgGIzTtGldffSd8F3HDUotFUyoCm3LVrwulN1zxqLGAmJ4MbSafjU+XELW/ dJ0ck3vGs6BRSP97nGCgJEeTdfYIxQvmm8jY19sBoKXuxj0JkLgzITDCU/2wyW1A4XK Emdn/wWFMzuNFARb55p9m57R/xYPTTAQHdzEZxRY= From: Kent Watsen Message-ID: <01000174507dd788-18119adf-c886-42d0-973e-d76f351fff93-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BD44FEAB-4291-44C7-9AA1-D71AE5353892" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 2 Sep 2020 20:24:18 +0000 In-Reply-To: <010001745065426d-097daf26-8257-4b71-b504-e281734cfed6-000000@email.amazonses.com> Cc: Kent Watsen , "netconf@ietf.org" To: Andy Bierman , =?utf-8?Q?Martin_Bj=C3=B6rklund?= References: <20200901173726.8E404F40785@rfc-editor.org> <20200902.082718.1225293218517439729.id@4668.se> <010001744fa1d4f9-c6c34f02-e5c6-4078-9244-c0bd567ae2a2-000000@email.amazonses.com> <010001745065426d-097daf26-8257-4b71-b504-e281734cfed6-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.09.02-54.240.48.90 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6271) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 20:24:47 -0000 --Apple-Mail=_BD44FEAB-4291-44C7-9AA1-D71AE5353892 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Typo: > The text above allows/suggests that are four =E2=80=9Cinsert=E2=80=9D = values MAY always be explicitly passed (and presumably processed). =20 s/that are four/that the four/ K. --Apple-Mail=_BD44FEAB-4291-44C7-9AA1-D71AE5353892 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Typo:

The text above allows/suggests that are four =E2=80=9Cinsert=E2= =80=9D values MAY always be explicitly passed (and presumably = processed).  

s/that are four/that = the four/

K.


= --Apple-Mail=_BD44FEAB-4291-44C7-9AA1-D71AE5353892-- From nobody Wed Sep 2 22:37:30 2020 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 A7AA53A0B78 for ; Wed, 2 Sep 2020 22:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.616 X-Spam-Level: X-Spam-Status: No, score=-0.616 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.482, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=nCV2IAta; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=h1ln13Fr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1Fw3EZAX1gV for ; Wed, 2 Sep 2020 22:37:27 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D03603A0A41 for ; Wed, 2 Sep 2020 22:37:27 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id CF365A30; Thu, 3 Sep 2020 01:37:26 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 03 Sep 2020 01:37:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm2; bh= X6XQ5+YPqlo+wKJMx4YFOmcS/FT5P75LGV7nO9GAusY=; b=nCV2IAtal2u/cjGd JsuQ1jI5j6a6LtNgFgwfptDksWXOwU1lgFPPpUJPZ2u4xkgRUQeGJQEqFzoS67OS XLcsU0WKiX0GK5MUtLNLHoyKQMusueKOyb001VoS626p6DBDZhP9blx3TkX3dLPy ZHLFJNYv/rd5tINSM1ZEGbwo7G7LMc+GeoSAtN4CIkQFNppnfjY16uf8kup8lB0e LRol3HrOTxcN1t+Nak32FgCl+UzVttdvfP+plSHCzc9ZSCeFX3iV+fOpuxK2QVhF bxqOZPMnaPLnraSEGfWINj7l5gMg03ISvOYtV5u0JlwzxJ7sltqkL/L0k1x/Unmo AJPyCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=X6XQ5+YPqlo+wKJMx4YFOmcS/FT5P75LGV7nO9GAu sY=; b=h1ln13Fr3FFqBzQ9xetNL87eJ/xuslA3h2ICEK+eyOx+ynEolpTxxDY1x ZbNIeSwg+oRxJWJZjRNyyeBL2Q1KPEgTPpd/MtREvoTetPTMiYZ/jNRPV5hUhWEV r44yZE9fOT5LfqoA3WloQyo/bFswDfUZnPQT0zjukMAtPlA8FEsHOFFZKpnmMSbK 15ZvpWA4ROTeOpPAb3YI5XzuWzXbMieQDEXsJwvZiN7AWp8A7gh8EoMNcDxQJfbB u0V/hpTY1cInIdZgRh4BC0slANywTOQ0xRhpb3eqZ9Ew0rc9ReSzUKx/+q0aTjgE SjthxQoCiLJMiHDTrTScC5cCqe6Qg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudegtddgleejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtsg ertdertdejnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepheetgedtfffggeffkedvje ekveelteeuuddttdffhfelgfetvdevhedvgeeutddunecukfhppeduheekrddujeegrdeg rdeggeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmsghjodhivghtfhesgeeiieekrdhsvg X-ME-Proxy: Received: from localhost (unknown [158.174.4.44]) by mail.messagingengine.com (Postfix) with ESMTPA id 3D7B0306005B; Thu, 3 Sep 2020 01:37:25 -0400 (EDT) Date: Thu, 03 Sep 2020 07:37:23 +0200 (CEST) Message-Id: <20200903.073723.641805022613525310.id@4668.se> To: kent+ietf@watsen.net Cc: andy@yumaworks.com, mbj+ietf@4668.se, netconf@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <010001745065426d-097daf26-8257-4b71-b504-e281734cfed6-000000@email.amazonses.com> References: <010001744fa1d4f9-c6c34f02-e5c6-4078-9244-c0bd567ae2a2-000000@email.amazonses.com> <010001745065426d-097daf26-8257-4b71-b504-e281734cfed6-000000@email.amazonses.com> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6271) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2020 05:37:29 -0000 S2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0PiB3cm90ZToNCj4gDQo+IA0KPiA+IE9u IFNlcCAyLCAyMDIwLCBhdCAxMjoyNCBQTSwgS2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4u bmV0PiB3cm90ZToNCj4gPiANCj4gPiAgICAgTkVXOg0KPiA+IA0KPiA+ICAgICAgICBUaGUgZGVm YXVsdCB2YWx1ZSBpcyDigJxsYXN04oCdLCB3aXRoIGV4Y2VwdGlvbiB0byB3aGVuIHVzZWQgd2l0 aCBQVVQNCj4gPiAgICAgICAgYW5kIHRoZSB0YXJnZXQgcmVzb3VyY2UgYWxyZWFkeSBleGlzdHMs IGluIHdoaWNoIGNhc2UgdGhlIGRlZmF1bHQNCj4gPiAgICAgICAgaXMgdG8gcmVwbGFjZSB0aGUg dGFyZ2V0IHJlc291cmNlIHdpdGhvdXQgYWx0ZXJpbmcgaXRzIHBvc2l0aW9uIGluIHRoZQ0KPiA+ ICAgICAgICAib3JkZXJlZC1ieSB1c2Vy4oCdIGxpc3Qgb3IgbGVhZi1saXN0Lg0KPiANCj4gVGhl IHRleHQgYWJvdmUgYWxsb3dzL3N1Z2dlc3RzIHRoYXQgYXJlIGZvdXIg4oCcaW5zZXJ04oCdIHZh bHVlcyBNQVkNCj4gYWx3YXlzIGJlIGV4cGxpY2l0bHkgcGFzc2VkIChhbmQgcHJlc3VtYWJseSBw cm9jZXNzZWQpLiAgRG8gd2Ugd2FudCB0bw0KPiBzdXBwb3J0IHRoZSBjYXNlIHdoZXJlIGEgUFVU IGlzIHVzZWQgb25seSB0byBtb3ZlIGFuIGVsZW1lbnQ/DQo+IGkuZS4gdGhlIHBhc3NlZCDigJxy ZXBsYWNlbWVudOKAnSBkYXRhIGlzIGlkZW50aWNhbCB0byB3aGF0IGV4aXN0cyBvbiB0aGUNCj4g c2VydmVyLCBvbmx5IHRoZSBpbnNlcnQvcG9pbnQgaGF2ZSBhbiBlZmZlY3Q/DQo+IA0KPiBPciBz aG91bGQgdGhpcyBzdHJhdGVneSBiZSB0aGF0IHRoZSBpbnNlcnQvcG9pbnQgY2FuIGFsd2F5cyBi ZSBwYXNzZWQNCj4gKGluIGEgUFVUIGZvciBhbiAib3JkZXJlZC1ieSB1c2Vy4oCdIGxpc3Qgb3Ig bGVhZi1saXN0KSwgYnV0IHRoZXkgb25seQ0KPiBoYXZlIG1lYW5pbmcgKGkuZS4sIGFyZSBwcm9j ZXNzZWQpIHdoZW4vaWYgdGhlIG9iamVjdCBpcyBiZWluZw0KPiBjcmVhdGVkLCBhbmQgb3RoZXJ3 aXNlIGlnbm9yZWQ/DQoNCk5vLCBtb3ZlIChhbmQgcG9zc2libHkgbW9kaWZ5IHRoZSBlbnRyeSkg aXMgc3VwcG9ydGVkLiAgU2VjdGlvbiA0LjguNg0Kc2F5czoNCg0KICAgVGhlICJwb2ludCIgcXVl cnkgcGFyYW1ldGVyIGlzIHVzZWQgdG8gc3BlY2lmeSB0aGUgaW5zZXJ0aW9uIHBvaW50DQogICBm b3IgYSBkYXRhIHJlc291cmNlIHRoYXQgaXMgYmVpbmcgY3JlYXRlZCBvciBtb3ZlZCB3aXRoaW4g YW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF5eXl5eXl5e DQogICAib3JkZXJlZC1ieSB1c2VyIiBsaXN0IG9yIGxlYWYtbGlzdC4NCg0KDQovbWFydGluDQo= From nobody Thu Sep 3 05:17:01 2020 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 26F783A09E3 for ; Thu, 3 Sep 2020 05:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.999, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 1X3TIzIZyUip for ; Thu, 3 Sep 2020 05:16:59 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 199523A09E1 for ; Thu, 3 Sep 2020 05:16:59 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 423ADF40786; Thu, 3 Sep 2020 05:16:43 -0700 (PDT) To: andy@yumaworks.com, mbj@tail-f.com, kwatsen@juniper.net, warren@kumari.net, rwilton@cisco.com, kent+ietf@watsen.net, mjethanandani@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: kent+ietf@watsen.net, netconf@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200903121643.423ADF40786@rfc-editor.org> Date: Thu, 3 Sep 2020 05:16:43 -0700 (PDT) Archived-At: Subject: [netconf] [Technical Errata Reported] RFC8040 (6277) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2020 12:17:00 -0000 The following errata report has been submitted for RFC8040, "RESTCONF Protocol". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6277 -------------------------------------- Type: Technical Reported by: Kent Watsen Section: 4.8.5 Original Text ------------- The default value is "last". Corrected Text -------------- The default value is “last”, except when used with PUT and the target resource already exists, in which case the default is to replace the target resource without altering its position in the "ordered-by user” list or leaf-list. Notes ----- The "last" default is intended for when creating a new element. A PUT operation that replaces a list or leaf-list entry should not move the entry unless the "insert" parameter is explicitly passed. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8040 (draft-ietf-netconf-restconf-18) -------------------------------------- Title : RESTCONF Protocol Publication Date : January 2017 Author(s) : A. Bierman, M. Bjorklund, K. Watsen Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Thu Sep 3 05:25:23 2020 Return-Path: <0100017453eda313-6583dabe-0ade-4773-a88d-27486a090808-000000@amazonses.watsen.net> 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 0860F3A0A6D for ; Thu, 3 Sep 2020 05:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 ljd1ernvzgAU for ; Thu, 3 Sep 2020 05:25:18 -0700 (PDT) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 446FD3A0A16 for ; Thu, 3 Sep 2020 05:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1599135917; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=DK/u/svrnUYt3bIlNWiL3unZP8/lvYxC86V3AWxP3KU=; b=a5k7/kSCFPkmJXVgGX14khw1H7LMfcXur3/lkxbXz5JBjD/iHGRbnU15Rc3AaGDK FRgMNKNpXr+0WeDS4bwsltEhmYOAc8qYr9Sq0JH2UybsnQ3HZlBRHDsqPcsgM5wtrUP T4HrI8v5/MvbVoYDV6SQqlU3ddvQJVqMdquKwg8c= From: Kent Watsen Message-ID: <0100017453eda313-6583dabe-0ade-4773-a88d-27486a090808-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7FF88E6E-2E37-431F-A54D-D71AEA54B817" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 3 Sep 2020 12:25:16 +0000 In-Reply-To: <20200903.073723.641805022613525310.id@4668.se> Cc: Andy Bierman , "netconf@ietf.org" To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= References: <010001744fa1d4f9-c6c34f02-e5c6-4078-9244-c0bd567ae2a2-000000@email.amazonses.com> <010001745065426d-097daf26-8257-4b71-b504-e281734cfed6-000000@email.amazonses.com> <20200903.073723.641805022613525310.id@4668.se> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.09.03-54.240.48.90 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6271) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2020 12:25:21 -0000 --Apple-Mail=_7FF88E6E-2E37-431F-A54D-D71AEA54B817 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I don=E2=80=99t think that I=E2=80=99m able to edit this errata for = Section 4.5. If I could, I would submit again with the new text that = fixes the *entries* language. I think that the AD needs to =E2=80=9Creject=E2=80=9D this Errata (EID = 6271). We could file separate errata to fix the =E2=80=9Centries=E2=80=9D= language in Sections 4.5, 4.8.5, and 4.8.6, but I=E2=80=99m unsure = it=E2=80=99s worth it. So I just filed a new errata https://www.rfc-editor.org/errata/eid6277 = to fix just the =E2=80=9Cinser= t=E2=80=9D query parameter "default" issue. K. > On Sep 3, 2020, at 1:37 AM, Martin Bj=C3=B6rklund = wrote: >=20 > Kent Watsen wrote: >>=20 >>=20 >>> On Sep 2, 2020, at 12:24 PM, Kent Watsen = wrote: >>>=20 >>> NEW: >>>=20 >>> The default value is =E2=80=9Clast=E2=80=9D, with exception to = when used with PUT >>> and the target resource already exists, in which case the = default >>> is to replace the target resource without altering its = position in the >>> "ordered-by user=E2=80=9D list or leaf-list. >>=20 >> The text above allows/suggests that are four =E2=80=9Cinsert=E2=80=9D = values MAY >> always be explicitly passed (and presumably processed). Do we want = to >> support the case where a PUT is used only to move an element? >> i.e. the passed =E2=80=9Creplacement=E2=80=9D data is identical to = what exists on the >> server, only the insert/point have an effect? >>=20 >> Or should this strategy be that the insert/point can always be passed >> (in a PUT for an "ordered-by user=E2=80=9D list or leaf-list), but = they only >> have meaning (i.e., are processed) when/if the object is being >> created, and otherwise ignored? >=20 > No, move (and possibly modify the entry) is supported. Section 4.8.6 > says: >=20 > The "point" query parameter is used to specify the insertion point > for a data resource that is being created or moved within an > ^^^^^^^^ > "ordered-by user" list or leaf-list. >=20 >=20 > /martin --Apple-Mail=_7FF88E6E-2E37-431F-A54D-D71AEA54B817 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = don=E2=80=99t think that I=E2=80=99m able to edit this errata for = Section 4.5.  If I could, I would submit again with the new text = that fixes the *entries* language.

I think that the AD needs to = =E2=80=9Creject=E2=80=9D this Errata (EID 6271).  We could file = separate errata to fix the =E2=80=9Centries=E2=80=9D language in = Sections 4.5, 4.8.5, and 4.8.6, but I=E2=80=99m unsure it=E2=80=99s = worth it.

So I just = filed a new errata https://www.rfc-editor.org/errata/eid6277 to = fix just the =E2=80=9Cinsert=E2=80=9D query parameter = "default" issue.

K.


On Sep 3, 2020, at 1:37 AM, Martin Bj=C3=B6rklund <mbj+ietf@4668.se> = wrote:

Kent Watsen <kent+ietf@watsen.net> wrote:


On Sep 2, 2020, at 12:24 PM, Kent Watsen <kent+ietf@watsen.net> wrote:

   NEW:

=       The default value is =E2=80=9Clast=E2=80= =9D, with exception to when used with PUT
=       and the target resource already = exists, in which case the default
=       is to replace the target resource = without altering its position in the
=       "ordered-by user=E2=80=9D list or = leaf-list.

The text above = allows/suggests that are four =E2=80=9Cinsert=E2=80=9D values MAY
always be explicitly passed (and presumably processed). =  Do we want to
support the case where a PUT is used = only to move an element?
i.e. the passed =E2=80=9Creplacemen= t=E2=80=9D data is identical to what exists on the
server, = only the insert/point have an effect?

Or = should this strategy be that the insert/point can always be passed
(in a PUT for an "ordered-by user=E2=80=9D list or = leaf-list), but they only
have meaning (i.e., are = processed) when/if the object is being
created, and = otherwise ignored?

No, move = (and possibly modify the entry) is supported.  Section 4.8.6
says:

  The "point" = query parameter is used to specify the insertion point
=   for a data resource that is being created or moved within = an
=             &n= bsp;           &nbs= p;            =        ^^^^^^^^
=   "ordered-by user" list or leaf-list.


/martin

= --Apple-Mail=_7FF88E6E-2E37-431F-A54D-D71AEA54B817-- From nobody Thu Sep 3 05:59:41 2020 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 0D9023A0B2D for ; Thu, 3 Sep 2020 05:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.616 X-Spam-Level: X-Spam-Status: No, score=-0.616 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.482, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=ZM4n/82S; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WgY8yog9 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOVG1qm4lwx8 for ; Thu, 3 Sep 2020 05:59:38 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 759CD3A0ADD for ; Thu, 3 Sep 2020 05:59:38 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id B7B025C01C5; Thu, 3 Sep 2020 08:59:37 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 03 Sep 2020 08:59:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm2; bh= m/kVpp5Rd57fi13ZVMZnj4WcspHDkpGEKV4DTj8aUnk=; b=ZM4n/82SM/wmBn3b 7EwLwvSeTh0En5LUFYvR7Dj5UO4V2ECWa44JD3mWtihkKzQtFpKDlpMqis0CAyu6 DtoJ0tgE3V3k8NukT2rzgAhKtXObAcGGlOtKTy3hFVnQGY//hSTpu+8w3LtfdmX2 5r8sWA3pPvYwh/gzF3Aj1Y1LDnr8v4YDOLASHSGrEwce+9aK6LdAz8TFfssrxk78 HgpSAdr3F/NpYtrMaVGCSh468icxuiNLurLQAG5LmJr60lBKlvbsm/ww5VRmRVeI T/C3ht+ukEKhJ4w0H2kay3jYL+KIqiETN6SzgfRyjV90YuRby9spt72TQBu7E2nK XROP+A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=m/kVpp5Rd57fi13ZVMZnj4WcspHDkpGEKV4DTj8aU nk=; b=WgY8yog9skS0FxO1IIhIJTHxDdzMHjMPX/M450Rkx5wcrzEkAl7f6l0my bV3KU7XswinAK2QAr3CWmO1xXCW0KCFBdMloPxJ5cBHIMEQ/s8lnuyj+bNGcJomV ImC4AQWMgkfKanjBH6TJMtaSXKT4U9JuIfLxX7ms/hhxmf7oG0P6od4lr9ef4N6/ M1C5wVcU4+nJ6xOgtArXwPI1wi7XxMiFdVwzWke7kan0bh/H2x8INWbIsKIdYOVi /edWWHvk96O8Qc/ypb5QwbKLG3MvGZmyRrlzAKqdE+AIcpbf+oa15Aqyng6hRLPf snyIWO6ZxtINbHMR3r4oQHxwfvU2w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudeguddgiedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtsg ertdertdejnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepfedvhefgieevteehleekke dvgfdthfduveffffelleeigefgvddvgfffledvveeknecuffhomhgrihhnpehrfhgtqdgv ughithhorhdrohhrghdpihgvthhfrdhorhhgnecukfhppedvuddvrddvudegrdduuddrie dtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgs jhdoihgvthhfseegieeikedrshgv X-ME-Proxy: Received: from localhost (212-214-11-60-static.se.customer.tele2.net [212.214.11.60]) by mail.messagingengine.com (Postfix) with ESMTPA id 1936C3060057; Thu, 3 Sep 2020 08:59:35 -0400 (EDT) Date: Thu, 03 Sep 2020 14:59:33 +0200 (CEST) Message-Id: <20200903.145933.1392342869737444306.id@4668.se> To: rfc-editor@rfc-editor.org Cc: andy@yumaworks.com, mbj+ietf@4668.se, warren@kumari.net, rwilton@cisco.com, kent+ietf@watsen.net, mjethanandani@gmail.com, netconf@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <20200903121643.423ADF40786@rfc-editor.org> References: <20200903121643.423ADF40786@rfc-editor.org> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (6277) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2020 12:59:40 -0000 SGksDQoNClRoaXMgZXJyYXRhIGlzIGNvcnJlY3QgKGl0IGlzIHRoZSByZXN1bHQgb2YgYSBkaXNj dXNzaW9uIG9uIHRoZQ0KbmV0Y29uZiBNTCByZSBlcnJhdGEgNjI3MSkuDQoNCg0KL21hcnRpbg0K DQoNClJGQyBFcnJhdGEgU3lzdGVtIDxyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPiB3cm90ZToN Cj4gVGhlIGZvbGxvd2luZyBlcnJhdGEgcmVwb3J0IGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3IgUkZD ODA0MCwNCj4gIlJFU1RDT05GIFByb3RvY29sIi4NCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IFlvdSBtYXkgcmV2aWV3IHRoZSByZXBvcnQgYmVsb3cgYW5k IGF0Og0KPiBodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGEvZWlkNjI3Nw0KPiANCj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gVHlwZTogVGVjaG5pY2Fs DQo+IFJlcG9ydGVkIGJ5OiBLZW50IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5uZXQ+DQo+IA0K PiBTZWN0aW9uOiA0LjguNQ0KPiANCj4gT3JpZ2luYWwgVGV4dA0KPiAtLS0tLS0tLS0tLS0tDQo+ IFRoZSBkZWZhdWx0IHZhbHVlIGlzICJsYXN0Ii4NCj4gDQo+IENvcnJlY3RlZCBUZXh0DQo+IC0t LS0tLS0tLS0tLS0tDQo+IFRoZSBkZWZhdWx0IHZhbHVlIGlzIOKAnGxhc3TigJ0sIGV4Y2VwdCB3 aGVuIHVzZWQgd2l0aCBQVVQgDQo+IGFuZCB0aGUgdGFyZ2V0IHJlc291cmNlIGFscmVhZHkgZXhp c3RzLCBpbiB3aGljaCBjYXNlIHRoZSANCj4gZGVmYXVsdCBpcyB0byByZXBsYWNlIHRoZSB0YXJn ZXQgcmVzb3VyY2Ugd2l0aG91dCBhbHRlcmluZw0KPiBpdHMgcG9zaXRpb24gaW4gdGhlICJvcmRl cmVkLWJ5IHVzZXLigJ0gbGlzdCBvciBsZWFmLWxpc3QuDQo+IA0KPiANCj4gTm90ZXMNCj4gLS0t LS0NCj4gVGhlICJsYXN0IiBkZWZhdWx0IGlzIGludGVuZGVkIGZvciB3aGVuIGNyZWF0aW5nIGEg bmV3IGVsZW1lbnQuICANCj4gDQo+IEEgUFVUIG9wZXJhdGlvbiB0aGF0IHJlcGxhY2VzIGEgbGlz dCBvciBsZWFmLWxpc3QgZW50cnkgc2hvdWxkIG5vdCBtb3ZlIHRoZSBlbnRyeSB1bmxlc3MgdGhl ICJpbnNlcnQiIHBhcmFtZXRlciBpcyBleHBsaWNpdGx5IHBhc3NlZC4NCj4gDQo+IEluc3RydWN0 aW9uczoNCj4gLS0tLS0tLS0tLS0tLQ0KPiBUaGlzIGVycmF0dW0gaXMgY3VycmVudGx5IHBvc3Rl ZCBhcyAiUmVwb3J0ZWQiLiBJZiBuZWNlc3NhcnksIHBsZWFzZQ0KPiB1c2UgIlJlcGx5IEFsbCIg dG8gZGlzY3VzcyB3aGV0aGVyIGl0IHNob3VsZCBiZSB2ZXJpZmllZCBvcg0KPiByZWplY3RlZC4g V2hlbiBhIGRlY2lzaW9uIGlzIHJlYWNoZWQsIHRoZSB2ZXJpZnlpbmcgcGFydHkgIA0KPiBjYW4g bG9nIGluIHRvIGNoYW5nZSB0aGUgc3RhdHVzIGFuZCBlZGl0IHRoZSByZXBvcnQsIGlmIG5lY2Vz c2FyeS4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBS RkM4MDQwIChkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNvbmYtMTgpDQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFRpdGxlICAgICAgICAgICAgICAgOiBSRVNUQ09O RiBQcm90b2NvbA0KPiBQdWJsaWNhdGlvbiBEYXRlICAgIDogSmFudWFyeSAyMDE3DQo+IEF1dGhv cihzKSAgICAgICAgICAgOiBBLiBCaWVybWFuLCBNLiBCam9ya2x1bmQsIEsuIFdhdHNlbg0KPiBD YXRlZ29yeSAgICAgICAgICAgIDogUFJPUE9TRUQgU1RBTkRBUkQNCj4gU291cmNlICAgICAgICAg ICAgICA6IE5ldHdvcmsgQ29uZmlndXJhdGlvbg0KPiBBcmVhICAgICAgICAgICAgICAgIDogT3Bl cmF0aW9ucyBhbmQgTWFuYWdlbWVudA0KPiBTdHJlYW0gICAgICAgICAgICAgIDogSUVURg0KPiBW ZXJpZnlpbmcgUGFydHkgICAgIDogSUVTRw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gbmV0Y29u ZkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNv bmYNCg== From nobody Thu Sep 3 22:39:40 2020 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 8D18B3A005E for ; Thu, 3 Sep 2020 22:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 sFxkPG6KWGrg for ; Thu, 3 Sep 2020 22:39:36 -0700 (PDT) Received: from mail.swisscom.com (mailout120.swisscom.com [138.188.166.120]) (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 6A5743A0044 for ; Thu, 3 Sep 2020 22:39:35 -0700 (PDT) Received: by mail.swisscom.com; Fri, 4 Sep 2020 07:39:20 +0200 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_19450_925867212.1599197960222" X-Mailer: Totemo_TrustMail_(Notification) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iTezwVnBCFAjm/lyHcIAKNn2DbQc2KQWDclB0hUzhF6lHlOm9OnPXh37YBaWsuAWEvyTHFrweVVg+ghgJa4Tyhnh/Zs8lPOjiYlF+HJeE3GirB50fe/Z44A8znfgKGqzQLAM0rmmkvwzfk2u6T5CSiUIRruA6WyyvPF8CI37Oa8+Hd6vTPO0el6160DmcY/E36FwMu8Jv2bW7TnfHuixl+zGEWPLpoqoALlvnf4yhYnwDtO2kKE/WiYbDbUlXSQdZLZ2niG0kQC4oJgJkrkwfJRfkl0kxbZaxctiIdoBVUw1Ar/3eRLPvCqh2/mbPr7HBMnsxDQwwTDGMq97pmSgPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n0NN/gvsaNDbh+LaZzR3Ew2aHaSMJIgzNOn6qbPRkvc=; b=SZ31yUcM3yEE6YO0HhbHD20/xwS0HmgmizGEfBhgulDejfnz9MKQ3kXigK2TtfKdqcNUpO2Z/A4HU2v361JVBn0AMok2dFSCry6lybJAFLXAHyJmqPE09+gcHJmcyduygzPKb/UuPolUzmf0qEVXEN/ifOD2wgoDCsNRUmMYCpamVIiLpOXa4VzDQgV9t1KAVtAKKoHz2qTOa6TKu8vX28fQkGUxKetxw6BgfjQ6Woww9JDgVEaAhRzL6kjCnPhSDvBxdf+Dobulf0rl1NkE39Vobpw8nmaXx+GqS3TdodCIbrEO3hhrjqxM+z3DD9a5FGrftepS14M22HULhcsCjg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=swisscom.com; dmarc=pass action=none header.from=swisscom.com; dkim=pass header.d=swisscom.com; arc=none From: To: CC: , , Thread-Topic: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif Thread-Index: AQHWdWVt0mBLbRaES02VUjy2aRVTDKk+cCwAgAunzwCAAJn6AIAAjDyAgAEjdYCAAOckAIAFR84AgAFNIXCAAByKAIAEFfOw Date: Fri, 4 Sep 2020 05:39:16 +0000 Message-ID: References: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@us-east-1.amazonses.com> <01000173ca90a8d5-78b55d80-3a92-406a-8544-594dbe223735-000000@email.amazonses.com> <07b991b1e32347b58ae4ef968cdffc7f@huawei.com> <7b77f6ff39d4430aa549c9b53b902dde@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Enabled=True; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Owner=Thomas.Graf@swisscom.com; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SetDate=2020-09-04T05:39:15.0064245Z; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Name=C2 General; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Application=Microsoft Azure Information Protection; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ActionId=aa66b29c-7992-4b14-91b0-8587286ee240; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Extended_MSFT_Method=Automatic authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none; yumaworks.com; dmarc=none action=none header.from=swisscom.com; x-originating-ip: [138.188.166.44] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cfe11652-2cf1-4f0e-693e-08d85094dd0d x-ms-traffictypediagnostic: ZR0P278MB0140: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ITXJ7UX530WE3z3YGBdq4THMwlGyiWyS+zoranobqozydFskGSvzF/1XOfpf7z1cFUXbnICy9RDQIqbb9WPHonZiAfOY2zlmJZY41fJB3pY+8+MY48XfKKVBxax5oYtKvjJ1sMpJS5u1+qSsQn6r29bd1/IXkX9SUXF5/ANbY0IqeYcwppsD0Q82KCnjocBZcp9l5LnVGqt8bQDXBTUwAmsKhvehfwj9iA45sMsUig/HBhqV9i/j3VzS6KlaSXfKodzQSxqMo1rsXqHhjTlHqtLxuTf4aY7zgPDMOdfFXRcMLeNPZIz6WWOXobIzcf8jsF3nf1FzNF/klzB7haSsr9ZJOKXQ7BUOUoQO2Cmael8jws78nmhZ9WYttmkNHK1acQO0wFS+pBcgpDVRXU60aA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:ZRAP278MB0125.CHEP278.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(136003)(39860400002)(376002)(346002)(2906002)(86362001)(10300500001)(33656002)(10290500003)(55016002)(8936002)(54906003)(30864003)(66946007)(64756008)(66476007)(8676002)(966005)(71200400001)(83380400001)(66556008)(66446008)(6916009)(316002)(478600001)(5660300002)(186003)(7696005)(53546011)(52536014)(166002)(6506007)(4326008)(76116006)(9686003)(26005)(579004)(559001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: fOiYnDVOfdKdrKR+jrnN+DHAFeN4NtIbp9gNHzFJq5Y1jn18A8nZJQwf/MNELA02iSMKdif14ni4FKD8ESJxM3RutV2KmWRXUJTlx3v5khOS6oZ2pzV9pagUDIJlE54qocuYbwB5MKfwXVhTGqU/kKqZzToPW465RYJENn6taGgi/1zt6nLqaNt7gRS1ZS5ul0IRWKuDm8UD+XOFnanV9J6qBn0INd7Hwjumy4lwzwvUK7Q2xd//ImTU3qwled1fK9YTA4QYVioYB4Qv1Uu6s+5cOC0j6P4AadNwajb26tqdOtqQ/tqUwNOVQAYpfjgv6B26Beg65B5MpK07PZ8/HdFMu4PbaADEjFqw9dZPl44wbqubT7sjC1V4Q2LkeqXSnm58EZv7nUSZqud4nyL/malfcGXfncbcDYu0vjSzcqL+mxi+MVJd+NhEXNgoVJToIxz91dVwsbaNHF/9d40MktFGhjswwb4Uq1srScd64g4WfYZMMW6sTlactlOhNjTQFKl06XBea3P6g/AH/cuysAPbGjasFcd+Lj/9WCdsTz24yrYjTjfMaKIUdM5vejTDntR/NfXhaHusMQv4cr/hOzEYxmDuFPcXVfm4BqtyPZQiB46bWyvr9SHYm2V3TORXdKqi3HrAjN9/fQ45w8WUnw== x-ms-exchange-transport-forked: True X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: ZRAP278MB0125.CHEP278.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: cfe11652-2cf1-4f0e-693e-08d85094dd0d X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2020 05:39:16.6293 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 364e5b87-c1c7-420d-9bee-c35d19b557a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tDKjhMJCHpTjzgPk7cGwrNrdQcKh+CMC5S8DPkEtpXA8zK2SESxiSDfZuIhREcAHEAF+c/xv6pKQzTXpN47ZOOaa+yMM7C8bI5DqMsVsi3g= X-MS-Exchange-Transport-CrossTenantHeadersStamped: ZR0P278MB0140 X-OriginatorOrg: swisscom.com X-CFilter-Loop: Reflected X-Trustmail: processed Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2020 05:39:40 -0000 ------=_Part_19450_925867212.1599197960222 Content-Type: multipart/alternative; boundary="_000_ZRAP278MB012592A7A24D74667979C66E892D0ZRAP278MB0125CHEP_" Content-Language: en-US --_000_ZRAP278MB012592A7A24D74667979C66E892D0ZRAP278MB0125CHEP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andy, Sure, * It appears that there is no application protocol here in this proposa= l. Correct. * Which means this proposal is for a general-purpose protocol for sendi= ng data as fast as possible * over UDP, without regard for security or congestion. It's a UDP-based transport for configured subscriptions. Where configured s= ubscriptions refers to section 2.5 of (https://tools.ietf.org/html/rfc8639#= section-2.5) Section 3.2 (https://tools.ietf.org/html/draft-unyte-netconf-udp-notif-00#s= ection-3.2) described the UDP header which facilitates the "Message-Generat= or-ID" and " Message ID" for loss detection. "ET" facilitates the encoding = type. How to handle fragmentation is described in Section 3.3.1 (https://tools.ie= tf.org/html/draft-unyte-netconf-udp-notif-00#section-3.3.1) by facilitating= the options header. There is no congestion control mechanism as described in Section 4 (https:/= /tools.ietf.org/html/draft-unyte-netconf-udp-notif-00#section-4). At IETF 109 another draft is going to be presented at netconf wg where DTLS= as encryption option is described. * Take the "XML" encoding for example. That usually means the applicat= ion content * is an XML instance document -- a single XML element. OK, which one? = Which schema * does the receiver use to validate the XML instance document? I believe you are referring here to the subscription-id identifier describe= d in RFC 8639 section 2.7.1 (https://tools.ietf.org/html/rfc8639#section-2.= 7.1) and section 3 (https://tools.ietf.org/html/rfc8639#section-3.3). When = a configured subscription for an xpath is created, a subscription-id is ass= igned and sent with each message. draft-unyte-netconf-udp-notif describes one transport option of RFC 8639. R= FC 8639 describes in section 1.1 (https://tools.ietf.org/html/rfc8639#secti= on-1.1) that it facilitates that multiple subscriptions can be handled on o= ne transport sessions. Let me know if this clarifies your questions. Feedback to draft-unyte-netco= nf-udp-notif or draft-unyte-netconf-distributed-notif are very welcome. Best Wishes Thomas From: Andy Bierman Sent: Tuesday, September 1, 2020 5:14 PM To: Graf Thomas, INI-NET-TCZ-ZH1 Cc: Zhoutianran ; Netconf ; Rober= t Wilton Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-not= if On Tue, Sep 1, 2020 at 6:33 AM > wrote: Hi Andy, Thanks for the feedback. I think I understand in which direction your quest= ion goes, but haven't understood the detail, possible proposal and implicat= ions yet. Would it be ok to setup a call between you, the authors and mayb= e Rob as well to discuss this off the list and feedback the summary to the = list back? Looking forward to your reply. I don't know if a conf-call is needed. It appears that there is no application protocol here in this proposal. Take the "XML" encoding for example. That usually means the application co= ntent is an XML instance document -- a single XML element. OK, which one? Which = schema does the receiver use to validate the XML instance document? If the answer is "any XML instance document you want" rather than "the appl= ication protocol defines the message content", then there is no application, right? Which means this proposal is for a general-purpose protocol for sending dat= a as fast as possible over UDP, without regard for security or congestion. Best Wishes Thomas Andy From: netconf > O= n Behalf Of Andy Bierman Sent: Monday, August 31, 2020 7:40 PM To: Tianran Zhou > Cc: netconf@ietf.org; Rob Wilton (rwilton) > Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-not= if Hi, I am still very confused about the content. Not the encoding. That is a sep= arate issue. Sec 2, and 3.1 refer to the "subscription-started" notification and "the NETCONF/RESTCONF notification message". This text seems to imply that the element defined in RFC 527= 7 is used for the content. But sec. 3.4 mentions bundled notifications so ma= ybe not. Usually the application protocol defines the message flows that are expecte= d. This document is a transport protocol for an unspecified application. Ther= e is an assumption that publisher and receiver both know the protocol somehow. For GDB, they magically know how to distinguish different proto files. IMO this level of disregard for interoperability is unacceptable for a stan= dard protocol. Andy On Fri, Aug 28, 2020 at 2:01 AM Tianran Zhou > wrote: Hi Andy, Thanks again for your further comments. Tianran From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Friday, August 28, 2020 3:14 AM To: Tianran Zhou > Cc: Rob Wilton (rwilton) >; netconf@ietf.org Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-not= if On Wed, Aug 26, 2020 at 6:50 PM Tianran Zhou > wrote: Hi Andy, Thanks for your reply and suggestions. Cheers, Tianran From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Thursday, August 27, 2020 1:29 AM To: Tianran Zhou > Cc: Rob Wilton (rwilton) >; netconf@ietf.org Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-not= if On Wed, Aug 26, 2020 at 1:17 AM Tianran Zhou > wrote: Hi Andy, Please see inline. Tianran From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Wednesday, August 19, 2020 6:18 AM To: Rob Wilton (rwilton) > Cc: netconf@ietf.org Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-not= if On Tue, Aug 18, 2020 at 6:42 AM Rob Wilton (rwilton) > wrote: Hi, [Also as a contributor] My comments are broadly similar to Kent's. I believe that a UDP transport for dataplane telemetry where getting accura= te fresh data quickly is more important than getting every update. This is= particularly true if a subsequent notification will cover any lost values = anyway (e.g. periodic statistics). agreed. There is also the resync-subscription mechanism to help recover from missin= g data. [ztr] Our intention of using UDP is for data that do not care about occasio= nal loss. Typically for period data, and new data will anyway came and upda= te. Does the "resync-subscription" mean the retransmission? Here do you want to= add the "resync-subscription mechanism" when packet loss is detected in th= is draft? This is explained in RFC 8641 ZTR> Yes, I looked into RFC8641. It's the same as what I understand as "ret= ransmission". Two key points on "resync-subscription" from my perspective. 1. "This RPC is supported only for on-change subscriptions previously estab= lished using an "establish-subscription" RPC." 2. "On receipt, a publisher must either (1) accept the request and quickly = follow with a "push-update" or ..." So, what's your suggestion here? To support this? Or not support this and add text explicitly in the documen= t. Nothing to add to this document. I was just noting that YANG Push does not rely on every push-change-update notification to be delivered. The application layer will re-synch by itsel= f. ZTR> Agreed. Thanks. I suspect that having a mechanism to allow for the telemetry data being enc= rypted is probably also important. If the WG were to adopt a draft without= this, then as Benoit mentioned, I would have to test the water with the IE= SG to determine whether that would be acceptable. I suspect the lack of congestion control might get their attention as well. [ztr] Yes, I agree, both security and congestion considerations need to be = described in the document. We have section 4 for congestion control. Do you= have any idea on this? no -- I can't solve problems that IETF creates for itself. I think the draft says something like "do not use this protocol if congesti= on is a concern". I also note that the draft allows for a GPB encoding of the telemetry data,= but I'm not aware of any formal standard encoding of YANG data in GPB, and= there is a choice between whether the GPB encoding is generic for all YANG= data, or specific GPB encodings are useful for the specific data that is b= eing encoded. I was confused by the same thing. Is there a YANG schema for a notification element that is used? Which means the .proto file is hardwired? If not then how does the receiver know what is sent? There are some technical issues that can be addressed if the draft is adopt= ed. [ztr] In this draft we only consider to include a code point to indicate th= e GPB encoding. How to map YANG to GPB is out of the scope of this draft. In practice, there are several ways in my opinion. We can map YANG to proto firstly, and the proto actually describes the data= structure. I think YANG can almost translate to proto 1:1. We can also develop YANG to GPB directly, just like YANG to XML and JSON. In brief, the receiver can still know what is sent by YANG. I don't think the protocol should include placeholders for proprietary solu= tions. Either leave out GPB completely or support it in an interoperable way. ZTR> We have no position on this. If the WG agreed, we would like to leave = out GPB. What about just adding a 32-bit report-id field to the header This is enough. Assignment of the IDs is out of scope. ZTR> Sorry, I did not get you on what's this 32-bit report-id? We have a 4= bit encoding type field, which can support 16 encodings. We can set this a= s a registry and defer the assignment of GPB. More issues: This protocol is not usable by servers that stream data instead of building= an entire response in memory. With a streaming design the server doesn't know what will be sen= t in advance so it sure doesn't know the length in advance. CBOR does a great job of suppo= rting both types of server design. NETCONF and HTTP support chunking, which is used e= xtensively by streaming servers. This draft should mention streaming and explain why it i= s not supported. ZTR> If you mean bit streaming like TCP, I think UDP cannot support this. D= o you have any pointer on how CBOR can support the streaming. And how NETCO= NF and HTTP support chunking. In general, I understand this requirement with small memory or partial data= . But do you have any real case in the context of YANG push? So that we can= work on an optimal design. I think it is OK to say that a server is expected to build an entire respon= se and the length needs to be known in advance, if fragmentation is not enable= d. A server can stream data OK if UDP fragmentation is enabled. CoAP uses the = Block option to support streaming. ZTR> Got it. Yes, this draft enables UDP fragmentation which can support da= ta streaming. The generic wrappers (like gNMI and YANG notification schema) do not handle= "anydata" very well at all. The binary payload becomes mostly JSON. Only CBOR+SID handles anydata effi= ciently. The solution (maybe outside the scope of this protocol) should consider how= YANG anydata will be transmitted efficiently and converted from anydata to a real schema= correctly by the receiver. Regards, Rob Andy Andy Andy From: netconf > O= n Behalf Of Kent Watsen Sent: 07 August 2020 21:16 To: netconf@ietf.org Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-not= if [as a contributor] 1) is the problem important for the NETCONF WG to solve? I believe that it is important to enable publishers to send notifications u= sing a UDP-based transport. This belief is based on my experience from wh= en at Juniper dealing with very high-end firewalls with enormous log output= . I believe that the NETCONF WG is the appropriate WG for this work, having d= efined RFC 8639 (SN), RFC 8640 (NN), and RFC 8650 (RN). 2) is the draft a suitable basis for the work? I have read the current version of the draft and find it to be a reasonable= start. Presuming the "receiver-instances" augmentation defined in https://tools.ie= tf.org/html/draft-ietf-netconf-https-notif-04#section-3 takes off, the module defined in this = draft should be updated to augment into it instead. I appreciate Section 5 (Applicability) noting that the UDP-transport is pri= marily for the data plane (not the control plane), as it doesn't matter so = much if data plane notifications are lost. This addresses (I think) the is= sue that Rob Shakir raised before: https://datatracker.ietf.org/doc/minutes= -103-netconf (search for "Rob S"). That sai= d, it is unclear to me how a receiver could configure this while, e.g., con= figuring control plane notifications to be sent via a TCP-based transport s= uch as "https-notif". 3) regarding Juergen's questions: a) I am willing to substantially review the drafts. b) I am willing to contribute to the discussion of any issue. c) I do NOT plan to implement the technology defined. Kent _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_ZRAP278MB012592A7A24D74667979C66E892D0ZRAP278MB0125CHEP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andy,

 

Sure,

 

  • It appears that there is no application protocol= here in this proposal.

 

Correct.

 

  • Which means this proposal is for a general-= purpose protocol for sending data as fast as possible
  • over UDP, without regard for security or conges= tion.

 

It’s a UDP-based transport for configured subscriptions. Wh= ere configured subscriptions refers to section 2.5 of (https://tools= .ietf.org/html/rfc8639#section-2.5)

Section 3.2 (https://tool= s.ietf.org/html/draft-unyte-netconf-udp-notif-00#section-3.2) described the UDP header which facilitates the "Message-Generator-ID&= quot; and " Message ID" for loss detection. "ET" facili= tates the encoding type.

 

How to handle fragmentation is described in Section 3.3.1 (https://tools.ietf.org/html/draft-unyte= -netconf-udp-notif-00#section-3.3.1) by facilitating the options header.

 

There is no congestion control mechanism as described in Section = 4 (https://tools.ietf.org/html/draft-= unyte-netconf-udp-notif-00#section-4).

 

At IETF 109 another draft is going to be presented at netconf wg = where DTLS as encryption option is described.

 

  • Take the "XML" encoding for example.&n= bsp; That usually means the application content
  • is an XML instance document -- a single XML element.&= nbsp; OK, which one? Which schema
  • does the receiver use to validate the XML instance document?

 

I believe you are referring here to the subscription-id identifie= r described in RFC 8639 section 2.7.1 (https://too= ls.ietf.org/html/rfc8639#section-2.7.1) and section 3 (https://tools.ietf.org= /html/rfc8639#section-3.3). When a= configured subscription for an xpath is created, a subscription-id is assi= gned and sent with each message.

&n= bsp;

draft-unyte-netconf-udp-notif describes one transport option of R= FC 8639. RFC 8639 describes in section 1.1 (https://tools= .ietf.org/html/rfc8639#section-1.1) that i= t facilitates that multiple subscriptions can be handled on one transport s= essions.

 

Let me know if this clarifies your questions. Feedback to draft-u= nyte-netconf-udp-notif or draft-unyte-netconf-distributed-notif are very welcome.

 

Best Wishes

Thomas

=  

From: Andy Bierman <andy@yumaworks.com>
Sent: Tuesday, September 1, 2020 5:14 PM
To: Graf Thomas, INI-NET-TCZ-ZH1 <Thomas.Graf@swisscom.com> Cc: Zhoutianran <zhoutianran@huawei.com>; Netconf <netconf@= ietf.org>; Robert Wilton <rwilton=3D40cisco.com@dmarc.ietf.org> Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

 

 

 

On Tue, Sep 1, 2020 at 6:33 AM <Thomas.Graf@swisscom.com&g= t; wrote:

Hi Andy,

 

Thanks for the feedback. I think I understand in wh= ich direction your question goes, but haven't understood the detail, possib= le proposal and implications yet.  Would it be ok to setup a call betw= een you, the authors and maybe Rob as well to discuss this off the list and feedback the summary to the list back? Lo= oking forward to your reply.

 

I don't know if a conf-call is needed. 

It appears that there is no application protocol her= e in this proposal.

Take the "XML" encoding for example. = That usually means the application content

is an XML instance document -- a single XML element.=   OK, which one? Which schema

does the receiver use to validate the XML instance d= ocument?

 

If the answer is "any XML instance document you= want" rather than "the application protocol

defines the message content", then there is no = application, right?

Which means this proposal is for a general-purp= ose protocol for sending data as fast as possible

over UDP, without regard for security or congestion.=

 

 

Best Wishes

Thomas

 

 

Andy

 

 

From: netc= onf <netco= nf-bounces@ietf.org> On Behalf Of Andy Bierman
Sent: Monday, August 31, 2020 7:40 PM
To: Tianran Zhou <zhoutianran@huawei.com>
Cc: netconf@ie= tf.org; Rob Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org>
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

 

Hi,

 

I am still very confused about the content. Not the encoding. That= is a separate issue.

Sec 2, and 3.1 refer to the "subscription-started" notif= ication and

"the NETCONF/RESTCONF notification message".<= /p>

 

This text seems to imply that the <notification> element def= ined in RFC 5277

is used for the content.  But sec. 3.4 mentions bundled notif= ications so maybe not.

 

Usually the application protocol defines the message flows that ar= e expected.

This document is a transport protocol for an unspecified applicati= on.  There is

an assumption that publisher and receiver both know the protocol s= omehow.

For GDB, they magically know how to distinguish different proto fi= les.

 

IMO this level of disregard for interoperability is unacceptable f= or a standard protocol.

 

 

Andy

 

 

 

 

On Fri, Aug 28, 2020 at 2:01 AM Tianran Zhou <zhoutianran@huawei.com> w= rote:

Hi Andy,<= /o:p>

 

Thanks again for your= further comments.

 

Tianran

 

From: Andy= Bierman [mailto:an= dy@yumaworks.com]
Sent: Friday, August 28, 2020 3:14 AM
To: Tianran Zhou <zhoutianran@huawei.com>
Cc: Rob Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org>; netconf@ietf.org<= br> Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

 

 

 

On Wed, Aug 26, 2020 at 6:50 PM Tianran Zhou = <zhoutianran= @huawei.com> wrote:

Hi Andy,<= /o:p>

 

Thanks for your reply= and suggestions.

 

Cheers,

Tianran

 

From: Andy= Bierman [mailto:an= dy@yumaworks.com]
Sent: Thursday, August 27, 2020 1:29 AM
To: Tianran Zhou <zhoutianran@huawei.com>
Cc: Rob Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org>; netconf@ietf.org<= br> Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

 

 

 

On Wed, Aug 26, 2020 at 1:17 AM Tianran Zhou = <zhoutianran= @huawei.com> wrote:

Hi Andy,<= /o:p>

 

Please see inline.

 

Tianran

 

From: netc= onf [mailto:n= etconf-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Wednesday, August 19, 2020 6:18 AM
To: Rob Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org>
Cc: netconf@ie= tf.org
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

 

 

 

On Tue, Aug 18, 2020 at 6:42 AM Rob Wilton (r= wilton) <rwilton=3D40cisco.com@dmarc.ietf.org> wrote:

Hi,

 

[Also as a contributor]

 

My comments are broadly similar to Kent’= ;s.

 

I believe that a UDP transport for dataplane = telemetry where getting accurate fresh data quickly is more important than = getting every update.  This is particularly true if a subsequent notification will cover any lost values anyway (e.g. = periodic statistics).

 

 

agreed.

There is also the resync-subscription mechani= sm to help recover from missing data.

 

[ztr] Our intention of using UDP is for data = that do not care about occasional loss. Typically for period data, and new = data will anyway came and update.

Does the “resync-subscription” me= an the retransmission? Here do you want to add the “resync-subscripti= on mechanism” when packet loss is detected in this draft?=

 

 

 

This is explained in RFC 8641

 

ZTR> Yes, I looked= into RFC8641. It’s the same as what I understand as “retransmi= ssion”. Two key points on “resync-subscription” from my perspective.

1. “This RPC is= supported only for on-change subscriptions previously established using an= "establish-subscription" RPC.”

2. “On receipt,= a publisher must either (1) accept the request and quickly follow with a &= quot;push-update" or …”

 

So, what’s your= suggestion here?

To support this? Or n= ot support this and add text explicitly in the document.  

 

 

Nothing to add to this document.<= /o:p>

I was just noting that YANG Push does not rel= y on every push-change-update

notification to be delivered.  The appli= cation layer will re-synch by itself.

 

ZTR> Agreed. Thank= s.

 

 

I suspect that having a mechanism to allow fo= r the telemetry data being encrypted is probably also important.  If t= he WG were to adopt a draft without this, then as Benoit mentioned, I would have to test the water with the IESG to deter= mine whether that would be acceptable.

 

I suspect the lack of congestion control migh= t get their attention as well.

 

[ztr] Yes, I agree, both security and congest= ion considerations need to be described in the document. We have section 4 = for congestion control. Do you have any idea on this?

 

 

no -- I can't solve problems that IETF create= s for itself.

I think the draft says something like "d= o not use this protocol if congestion is a concern".=

 

 

 

I also note that the draft allows for a GPB e= ncoding of the telemetry data, but I’m not aware of any formal standa= rd encoding of YANG data in GPB, and there is a choice between whether the GPB encoding is generic for all YANG data, or= specific GPB encodings are useful for the specific data that is being enco= ded.

 

 

 

I was confused by the same thing.=

Is there a YANG schema for a notification ele= ment that is used?

Which means the .proto file is hardwired?

If not then how does the receiver know what i= s sent?

There are some technical issues that can be a= ddressed if the draft is adopted.

 

[ztr] In this draft we only consider to inclu= de a code point to indicate the GPB encoding. How to map YANG to GPB is out= of the scope of this draft.

In practice, there are several ways in my opi= nion.

We can map YANG to proto firstly, and the pro= to actually describes the data structure. I think YANG can almost translate= to proto 1:1.

We can also develop YANG to GPB directly, jus= t like YANG to XML and JSON.

In brief, the receiver can still know what is= sent by YANG.

 

 

 

I don't think the protocol should include pla= ceholders for proprietary solutions.

Either leave out GPB completely or support it= in an interoperable way.

 

ZTR> We have no po= sition on this. If the WG agreed, we would like to leave out GPB.

 

 

What about just adding a 32-bit report-id fie= ld to the header

This is enough. Assignment of the IDs is out = of scope.

 

 ZTR> S= orry, I did not get you on what’s this 32-bit report-id? We have a 4 = bit encoding type field, which can support 16 encodings. We can set this as a registry and defer the assignment of GPB.

 

 

 

More issues:

 

This protocol is not usable by servers that s= tream data instead of building an entire response

in memory. With a streaming design the server= doesn't know what will be sent in advance so

it sure doesn't know the length in advance.&n= bsp; CBOR does a great job of supporting both

types of server design.  NETCONF and HTT= P support chunking, which is used extensively by

streaming servers. This draft should mention = streaming and explain why it is not supported.

 

ZTR> If you mean b= it streaming like TCP, I think UDP cannot support this. Do you have any poi= nter on how CBOR can support the streaming. And how NETCONF and HTTP support chunking.

In general, I underst= and this requirement with small memory or partial data. But do you have any= real case in the context of YANG push? So that we can work on an optimal design.

 

 

I think it is OK to say that a server is expe= cted to build an entire response

and the length needs to be known in advance, = if fragmentation is not enabled.

A server can stream data OK if UDP fragmentat= ion is enabled. CoAP uses the Block option

to support streaming.

 

ZTR> Got it. Yes, = this draft enables UDP fragmentation which can support data streaming.

 

 

 

The generic wrappers (like gNMI and YANG noti= fication schema) do not handle "anydata" very well at all.=

The binary payload becomes mostly JSON. = Only CBOR+SID handles anydata efficiently.

The solution (maybe outside the scope of this= protocol) should consider how YANG anydata

will be transmitted efficiently and converted= from anydata to a real schema correctly by the receiver.=

 

 

 

 

Regards,
Rob

 

 

Andy

 

 

Andy

 

 

 

Andy

 

 

 

 

From: netc= onf <netco= nf-bounces@ietf.org> On Behalf Of Kent Watsen
Sent: 07 August 2020 21:16
To: netconf@ie= tf.org
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= udp-notif

 

[as a contributor]

 

 

   1) is the problem important= for the NETCONF WG to solve?

 

I believe that it is important to enable publ= ishers to send notifications using a UDP-based transport.   This belie= f is based on my experience from when at Juniper dealing with very high-end firewalls with enormous log output.=

 

I believe that the = ;NETCONF WG is the appropriate WG for this work= , having defined RFC 8639 (SN), RFC 8640 (NN), and RFC 8650 (RN).

 

 

   2) is the draft a suitable = basis for the work?

 

I have read the current version of the draft = and find it to be a reasonable start.

 

Presuming the “receiver-instances”= ; augmentation defined in https://tools.ietf.org/html/draft-ietf-netconf-h= ttps-notif-04#section-3 takes off, the module defined in this draft should be updated to augment into it= instead.

 

I appreciate Section 5 = (Applicability) noting that the UDP-transport is primarily for the data pla= ne (not the control plane), as it doesn’t matter so much if data plane notifications are lost.  This addresses = (I think) the issue that Rob Shakir raised before: https://datatracker.ietf.org/= doc/minutes-103-netconf (search for “Rob S”).  That said, it is unclear to me how a recei= ver could configure this while, e.g., configuring control plane notificatio= ns to be sent via a TCP-based transport such as “https-notif”.<= /span>

 

 

3) regarding Juergen= 217;s questions:

 

  a) I am willing = to substantially review the drafts.

  b) I am wil= ling to contribute to the discussion of any issue.

  c) I do NOT = ;plan to implement the technology defined.

 

 

 

Kent<= /p>

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

--_000_ZRAP278MB012592A7A24D74667979C66E892D0ZRAP278MB0125CHEP_-- ------=_Part_19450_925867212.1599197960222 Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCAMIIG QTCCBSmgAwIBAgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCQ0gxFTATBgNVBAoTDFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFs IFNpbHZlciBDQSAyMDE0IC0gRzIyMB4XDTE5MDQxMTE2NDgyOFoXDTIyMDQxMTE2NDgyOFowgYEx CzAJBgNVBAYTAkNIMR4wHAYDVQQKExVTd2lzc2NvbSAoU2Nod2VpeikgQUcxJzAlBgkqhkiG9w0B CQEWGHRob21hcy5ncmFmQHN3aXNzY29tLmNvbTEpMCcGA1UEAxMgU2VjdXJlIE1haWw6IEdhdGV3 YXkgQ2VydGlmaWNhdGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCITr0/mumt/DE7 c8RDgwoi0IdMVLbGMQ1wzpjZ23C3KaauDnIDCAdgwJCj8H/4hy8Wj/EoKvbnJXc3DN/g5n4MyujX JjsLMo3cMaHqTSql2zKFsdFRnjNtOTEQMVleqnKgeiLwF5M+QpZGhS9T9M4br9PCKBEdwZ+BJRJN XPtxUjJWLh7ueFbMApS5lOryeoZrv9Yi6D5xSGErBuPrzn1ekUMzOfycZ4HcyLaEfzGNgYEax2yS 1/ZcM/qoj7k8e6dskfB6/PkFnf5BfWqwfWtmqn7PRJQQAEmjkJafFZNtvlyJ/ktjpI+pnju1AZaA c+LNL1eT1rwNdesrljxik/plAgMBAAGjggLZMIIC1TAjBgNVHREEHDAagRh0aG9tYXMuZ3JhZkBz d2lzc2NvbS5jb20wDgYDVR0PAQH/BAQDAgSwMBMGA1UdJQQMMAoGCCsGAQUFBwMEMB0GA1UdDgQW BBTAJbWmkqWsxJzHeilKdMU8NUhnwzAfBgNVHSMEGDAWgBTwx6MykbXryrVYdxWnTr4aXWFDJTCB /wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNzc2lnbi5uZXQvRjBDN0EzMzI5MUI1 RUJDQUI1NTg3NzE1QTc0RUJFMUE1RDYxNDMyNTCBqKCBpaCBooaBn2xkYXA6Ly9kaXJlY3Rvcnku c3dpc3NzaWduLm5ldC9DTj1GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1 JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmpl Y3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBrBgNVHSAEZDBiMFYGCWCFdAFZAQMBCzBJMEcG CCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tL1N3aXNzU2lnbi1TaWx2 ZXItQ1AtQ1BTLnBkZjAIBgYEAI96AQMwgdkGCCsGAQUFBwEBBIHMMIHJMGQGCCsGAQUFBzAChlho dHRwOi8vc3dpc3NzaWduLm5ldC9jZ2ktYmluL2F1dGhvcml0eS9kb3dubG9hZC9GMEM3QTMzMjkx QjVFQkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1MGEGCCsGAQUFBzABhlVodHRwOi8vc2lsdmVy LXBlcnNvbmFsLWcyLm9jc3Auc3dpc3NzaWduLm5ldC9GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVB NzRFQkUxQTVENjE0MzI1MA0GCSqGSIb3DQEBCwUAA4IBAQBPAGaURtN/46Vopba1sQJzad0O2JxG 8MwpE2F435dz+BfK/L8DGWN+EmWQV9k/p/IhNLFnj9WhBdd+iuscOT83XDCnUzyYiNqz7bhrQAEm B/87tdMsPhq5wUz5XfpnDcsSiQ1r/Woo+baMSN60QruEZM/be9mFILGOByV8BEwVbZTAiL7cLaOh bxUfQubFvyfOZ1HgJMVyfWizDVvDG2rL6YkWtsIBaVmCYGBqHrX0wSLyHlRNnbqiM2vawqQYme+1 +wxtbGCPPexp3wUBqpJde40Ke1xIpMj8c1kyvtaRM3CBX2p6xl0XHnSrybkJUidmaZnblUM6O18u b28x6Qp3MIIGvjCCBKagAwIBAgIPBUTWTq0e0zbVMkBdALk2MA0GCSqGSIb3DQEBCwUAMEcxCzAJ BgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxITAfBgNVBAMTGFN3aXNzU2lnbiBTaWx2 ZXIgQ0EgLSBHMjAeFw0xNDA5MTkyMDM2NDlaFw0yOTA5MTUyMDM2NDlaMFYxCzAJBgNVBAYTAkNI MRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBTaWx2 ZXIgQ0EgMjAxNCAtIEcyMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMs5sTmF/vrJ obzDg6kOSi2Ech7/aMWnxB3sD9eoixMes9EWi0DcD1NvAT3s6GS1l9uDvKiowIQ4WF4DFCvmyjDv ALLrEzkZkkcqIQDlcs3CMWIOzFYq/3fEY4yYwm9417W2zOl9HzOmkQUq/tFS1vTsnP5NTGpS4YV2 Yru5aOZSY/zBIZGSXRnY3IDRGeNJFlcCDhlEhaspyS/6xm1rCqH29/9rYTUVJpSUAmklXWn3vV5r gtmQDAb5QwUiSes20CBaYxDjOCHVfxYrQYpGevJn6KTQuh5/JCd1mJRJLVbEVDORnWL51V/eW6kV mJyUU8GA6QkXFbQbgCkyodCvE6cCAwEAAaOCApYwggKSMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB Af8ECDAGAQH/AgEAMB0GA1UdDgQWBBTwx6MykbXryrVYdxWnTr4aXWFDJTAfBgNVHSMEGDAWgBQX oM3B5EG2Ols7y0WdvRzCmPqGWDCB/wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNz c2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5OEZBODY1ODCBqKCBpaCB ooaBn2xkYXA6Ly9kaXJlY3Rvcnkuc3dpc3NzaWduLm5ldC9DTj0xN0EwQ0RDMUU0NDFCNjNBNUIz QkNCNDU5REJEMUNDMjk4RkE4NjU4JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBhBgNVHSAE WjBYMFYGCWCFdAFZAQMBBjBJMEcGCCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3Np Z24uY29tL1N3aXNzU2lnbi1TaWx2ZXItQ1AtQ1BTLnBkZjCBxgYIKwYBBQUHAQEEgbkwgbYwZAYI KwYBBQUHMAKGWGh0dHA6Ly9zd2lzc3NpZ24ubmV0L2NnaS1iaW4vYXV0aG9yaXR5L2Rvd25sb2Fk LzE3QTBDREMxRTQ0MUI2M0E1QjNCQ0I0NTlEQkQxQ0MyOThGQTg2NTgwTgYIKwYBBQUHMAGGQmh0 dHA6Ly9vY3NwLnN3aXNzc2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5 OEZBODY1ODANBgkqhkiG9w0BAQsFAAOCAgEAw3mnV7d7rVFo9USMQZUoAXx01jtqvG3vp9dNOZkd aI3KCNnQcbEZNZNvgsYcSbhR7kz5bApv2KX7/vswXgDSlKvEElG6qoqrat0Z1ytK9xaya1HPdFsp onPel/7YTyAhfWkMsFDljViMgC7lFxzdY3qq7wX5w2me5IxxYlxC7jryzeAS74tc6c5TKDLslQsZ VKIhjfp/UKdPvBl7smuMKT93Psojx2laQZ19ZjFvenF52qllOut/1xDVC19UGXzONyUkhFDQr0A0 wl+S4nqR8y9CRxufPEL72V+lvHBFju+gOZD1oXhs18BnWRnhAN5c/HjoT927rJEucov86kdvQyi8 u7mOlL76UN1QkxtMGLZ2/8NHClm0zW1V2Gq2X8kvwZQ2Pr6uQDUGIO3gAkwtNEUOQ6+i9NiQFeXQ wJtEQK48j5NRvJloc2l7dViZt9QET9/xgnERHXv8Ex13ZVVj11JyfN0xR4anldisJnE9I+YSO/R/ mpaG/ivqoPMmDXXGFowxIOcRR6HnqWqwpbKBHtw90KHjbtXwZqYcfdeSiE0ABwtx53Pnc+RUZWn8 N43xHm9w7qdss1JFZ1nWBUixIemXKNnZ9LSmoGcjNrxgRw5cKH9dk4oxuo0xNhTHekKdbyDBbCr4 Fg9q2QCUMrs9VbHFw6ENsXl3VB3gM4J+7uowggW9MIIDpaADAgECAghPG9QvVLsvSzANBgkqhkiG 9w0BAQUFADBHMQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMSEwHwYDVQQDExhT d2lzc1NpZ24gU2lsdmVyIENBIC0gRzIwHhcNMDYxMDI1MDgzMjQ2WhcNMzYxMDI1MDgzMjQ2WjBH MQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMSEwHwYDVQQDExhTd2lzc1NpZ24g U2lsdmVyIENBIC0gRzIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDE8Yd/03gx9zjJ +MOZQ7zH97w3505xukuPpXMdXG6YrgNXrjg3Qy8XPR/IzmgQwXiuGQMrEPoseYP26LlouVXyBESn Ofn8BIse8aJNJ/lhe7q35aITtuthPtBs0eb7+l7tHbSeoDVboZLL8EmS/oUKBT7m2QviT7vclTf8 kekyNSLRHzpOJ4WdsBWUMtphDUdNYEKukkfog1pQWOmKi7ldodzdmUofNme7SOSDtjfrSDqvD2eP FwfoBMrvajGH1MC2+ZRxe2dkuLaRSkJ7ZS4wagz1kO6V5vLNguzZoUrs9rJL5UWF5m14kwQunIJt NqnEMWQfhoMLKvQ1CnjJVc9BsEfpMJ+ZvmGoBoS5KHpfONkbqTiwg39zwcM7SCqCDyGbuMyoNcOE G4OzPr6klWkBOokAeATZyfSZGatWfluLhjkVkaQQLAkygGCzk8AqthgLnX6NSfIQSn/51UYvGZKj macmrLuMPOYOvEcH3HNR8XBkLwj5tEcdMGxE6ik3hZJoZryDOP57OS7TUPAf+15gtqmm+idB8ZsY cvL1hHRKyWfEVK5IZN+M0W6wHeEHjwgemZxx6UzYpfdHEh900VGehvPCoiNAC3PbS6bncwaMwaDp wVmsRvrmL/jPcZxGbbnEFY04eQNFSO/EXdcI7oc5IoayDQ9YQ/dxqUgu/erWHwIDAQABo4GsMIGp MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQXoM3B5EG2Ols7y0Wd vRzCmPqGWDAfBgNVHSMEGDAWgBQXoM3B5EG2Ols7y0WdvRzCmPqGWDBGBgNVHSAEPzA9MDsGCWCF dAFZAQMBATAuMCwGCCsGAQUFBwIBFiBodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tLzAN BgkqhkiG9w0BAQUFAAOCAgEAc8aB4CfSLQ/glTDimkF/UCxfX2JhqYZqaRgMdEnWXYTqQVIYb1it UFYgasa9KGlYkdyRETWpOh28GqVgntgff0WRadl+u3hywQYPKs6PhXBhrKDNC7g5KVaEMk6Guz3E KtnXH3Lu/lGhIkGxcQJjGoKwYqteVxIf38vddaDAXXmQjBvgUObeMf6Ye3BfpZDYrfgCtm/TYN1A SyLFPa06ep8aGkeReTO6gtwyaQOWbh9L8HH+42dyoLG/XIvk+pkix4S5G40jlz/tJeDPZbv1YQTv 3R6yWkEiWqGfXSzoW8ltqQwMeKpgxlaPAVoMaLxpGXnEH36XBb/F6SRRXtTVS1Pt2SNaNgNlo8ED rUEw80YbhZCvZbXVseQWW3h1HZd6bVmpKo973sOHiRCZSXN4yD29UTV0KtXxfmkbKrs7vSW4mlo9 cmGQZofuDNZN1BF0C2r+CwP8o1VXif5Ky65bFwXI8o0jMVM40i1qP4K5jQhq915BdG7DEX4HrClg kT84ylcQDb0wL8el5kGg2q4Fh5qgpGVsTAkMibq407nAk4ow+o3lmmsVAU5nqtpiVj6ECGbSxDZ9 pz4Q/Ijg1IDlAL2q804Go3pq+WJy4wlP65sOASPxn7t83NxsEZclsvK0YxTSBipnjIP1zuoH2Jpq HuzkCrsqTOsJYDnOymLYLm4AADGCA90wggPZAgEBMG4wVjELMAkGA1UEBhMCQ0gxFTATBgNVBAoT DFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFsIFNpbHZlciBDQSAyMDE0 IC0gRzIyAhR4i6Eec1b72YkIjJKOk4r62lxMbzANBglghkgBZQMEAgEFAKCCAkAwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwOTA0MDUzOTIwWjAtBgkqhkiG9w0B CTQxIDAeMA0GCWCGSAFlAwQCAQUAoQ0GCSqGSIb3DQEBCwUAMC8GCSqGSIb3DQEJBDEiBCDGgSm/ GCHRY2zlaIF3KcO9gXH6brNo9EiNkPqsc543pTB9BgkrBgEEAYI3EAQxcDBuMFYxCzAJBgNVBAYT AkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBT aWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wfwYLKoZIhvcNAQkQAgsx cKBuMFYxCzAJBgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNz U2lnbiBQZXJzb25hbCBTaWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8w gaUGCSqGSIb3DQEJDzGBlzCBlDALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQB AjAKBggqhkiG9w0DBzAKBggqhkiG9w0DAjAKBggqhkiG9w0DAjAHBgUrDgMCBzAKBggqhkiG9w0D AjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATALBglghkgBZQMEAgQwDQYJ KoZIhvcNAQELBQAEggEASGuUwrI20tpKcSvwx9yPcxjmEoWYkM/S65aJ8vElWz4GvAjsddWqBFWR lkb5LK8jF3Ex+EX03V5t4EfihjaWvhm/xwM3EWiaH/3bnEf4HyiFytijEDqET0ww04nu1J0M8lb1 o73ZZSjkrg4/kqqOG/MOwCI25zDN3cqjfkU9e9yd7v4N7OBtP2Mj0Bx90R3Tx+Zb+solSteirdfr FJOKWvvs3K4gijzUxJ6fEyW1OPltgKj4dq5P5GFsBhwliHtzzgXNwMlqutSHkRsOPsrk7xIprSsF zOMhS3wMKjz0f1QrCF9N1XGuDCTUgkOVIxKcRQisYus2hgfaLo+hMd4mkAAAAAAAAA== ------=_Part_19450_925867212.1599197960222-- From nobody Thu Sep 10 01:27:56 2020 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 BED993A1218 for ; Thu, 10 Sep 2020 01:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=Uq4nctbo; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=mPAeQlPo Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MZZmjLm5IAP for ; Thu, 10 Sep 2020 01:27:52 -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 303073A120D for ; Thu, 10 Sep 2020 01:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5506; q=dns/txt; s=iport; t=1599726472; x=1600936072; h=from:to:subject:date:message-id:mime-version; bh=hvkYh0Xbo9T3rDqHl56kvcdQZGDAPn8vo9Q53bzcUJU=; b=Uq4nctboWWQz4bAk2Ns62aOwMHK1N11tSbJktPJvoUZCDaDxb6dcrOxG o4d88l1bukaUrmFGne1ylVSt4ZJtfTfU4p661gnaOINw2nMAGkDDM3dSE 8WDTP8y/dYaRWsY1ZJAN/TvtHispOGd/9j2u9mDGY9hR8pGwnEoi0/Ht3 s=; IronPort-PHdr: =?us-ascii?q?9a23=3ANF362hOxfzzmh4YKA1Ql6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKw33l7EQYud7OhL2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YklYBMi4YEfd8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzBwDy4llf/5hdJa1fHgE8DAILFYF?= =?us-ascii?q?PgSMvUQeBSS8sCod0A41KlCmEboEuFIERA1ULAQEBDAEBLQIEAQGGaQIkNAk?= =?us-ascii?q?OAgMBAQsBAQUBAQECAQYEbYVcAQuGCy4BATgRAYEAJwQ1gwSBf00DLgEDqEM?= =?us-ascii?q?CgTmIYXSBNIMBAQEFgkuCTxiCEAmBOIJxijkbgUE/gTgMEIcOIoNigi2aCZx?= =?us-ascii?q?rCoJlBJovAx6gWIhEig+fVwIEAgQFAg4BAQWBVDqBV3AVOyoBgj5QFwINkhC?= =?us-ascii?q?KVnQ3AgYKAQEDCXyNOAGBEAEB?= X-IronPort-AV: E=Sophos;i="5.76,412,1592870400"; d="scan'208,217";a="539161955" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Sep 2020 08:27:50 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 08A8RoM0010601 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 10 Sep 2020 08:27:50 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 10 Sep 2020 03:27:49 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 10 Sep 2020 04:27:48 -0400 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 10 Sep 2020 04:27:48 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h2LZe7XVMh6ifjS7zdpIuUlDRU/Wv/m9TM5X0v3qhiTwQ6R4OIQnrb7YHVuY9bx6d6xFmQjjShnCPhpitnlLbVVgsyJYOmsUr0jG1lUKMuXmH3X9I277WVVbb0+e/l5TDH9CjzYoFijpY47hzWl3gY2teSaVgfBoG9AcpVBndQgMB/scnPAEpMEhsmY7RMSps8s3weE43RBscJcaiVKwwVIeIvQw/Gf08zIifnBBwacclBLayCcnOQgRh1/0p2NRrf0nL+jUDAaUlXwc9hLJ32TEi7/2bBjfZj4bUprezhSMK32NxwYIs/yJPBi16lqNtG+8yD2bf49krbGYJnSz0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LZMBLIzWU3EzDZI8afZB9c0klBTMopCsWN1lPS1Y7cI=; b=iLeb3rqGtukcVFGn8yV2OG4rt4Q4YF4jw92q6GX6U268FGyfZxZaG7wPJ5DJ7a9u0TKq567jgUD7uS9e0w6jf/tOWiwuU9Td4EQIcwroHTjrjCGkk7VEF+TTaVPpvOPsQauo/kLWmyQ0OVPFPIuNwwYU+e6mNB4zNUlaUMYaPRl5SENKI4f+MDONBd6Jba6Z8udNWtQWgt89ZGFIHsCSIDocPYQZ0ULYcRYI0vyeNtHP1kmGylP/hlSAa+bDXcpRZjEd4kxS7zjOdkC6/rPPOd1v7055R3y/DJZNCSY6CFL8NLvQUc9/G+g76mNZaehNg95jC7XqpChQoDSUeX4y0w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LZMBLIzWU3EzDZI8afZB9c0klBTMopCsWN1lPS1Y7cI=; b=mPAeQlPoN2+pIOQpN2yhjrJ8Hs1c+cz6+V0qn4Ve8MgtUUQ3ew+7YZbt/B60agymnRiHOTodBK+8a3SGA/E7jTDMK9nRvoSz1cq2SA0C7SbNQM+rXxXZ3IvqjiAnrD/hkp6vzKIA3KmpB+9ur/dCTNWPOc6wMjOCF8prpTNRLAA= Received: from DM6PR11MB2841.namprd11.prod.outlook.com (2603:10b6:5:c8::32) by DM6PR11MB2939.namprd11.prod.outlook.com (2603:10b6:5:70::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.21; Thu, 10 Sep 2020 08:27:47 +0000 Received: from DM6PR11MB2841.namprd11.prod.outlook.com ([fe80::fd62:3aa7:c332:92b2]) by DM6PR11MB2841.namprd11.prod.outlook.com ([fe80::fd62:3aa7:c332:92b2%7]) with mapi id 15.20.3370.016; Thu, 10 Sep 2020 08:27:47 +0000 From: "Jan Lindblad (jlindbla)" To: "netconf@ietf.org" Thread-Topic: Augmenting rpc-reply Thread-Index: AQHWh0xDDlljk9JqNkqcIGaQ8Ze9jg== Date: Thu, 10 Sep 2020 08:27:47 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [213.67.237.150] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c2d916e1-9519-4630-ab20-08d855636650 x-ms-traffictypediagnostic: DM6PR11MB2939: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nKVo4yUANOXiyL/7Q0pRoznRpyXrflB90J8qU8vFPueFvhD8RlADDutGFwpaJDTW4KqxJhchRq5x+dq5F4GdM6N3lMrM75J12d2cLeLFa0x8Z9EOPKWl6PoqT+mqOWaBhonaqqqaLg/28xx8R8fgWOugTS1JzsnbhJBZb6Xg1pjZizoqWXUmsYobDbB3cUXzxXkaKNYHvy+YmL/NT+r6juqkxN64aT9vIlh0thbQMqk4r3JooZhFD0qfbNp23mPUFD4VVswHn9suP8hqy/WsMndT7VaW/OnrA9FIOnwGpWIRnhAZVDtd6OCT6UX+EX0QjDXgpt8jJs7xDpoiHNTqy+Y6nr0SdDrQeslKTi+gBB+V14EoN9c1nuOHEi4Lt3hG x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB2841.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(396003)(39860400002)(346002)(136003)(8676002)(2616005)(26005)(186003)(36756003)(8936002)(71200400001)(6916009)(33656002)(6506007)(5660300002)(66556008)(316002)(66476007)(64756008)(83380400001)(66946007)(3480700007)(2906002)(66446008)(6486002)(6512007)(86362001)(91956017)(478600001)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 0JjCKDvYOXimgV0u9tLZW4Ojtjv8ByoyAZp2n8k4kChPjOvpOHRVvcl6Os7yIxRm6hTpDsVBy051BVPC2+JFPbEwYpEcVhJwhBdDiRgOxHLa9im0XAXzWfEt0xBb+ptPY369WdTLmplW0JdqtWD2z8E1AubmyGxT0k1+8L1dt/IfEVEaPC+HtXhbqgIDp2R76XpFEBS1P/yi8hc+ey7sDvlpZ6PH9A1vQD7JYGN3SLAjxXeSVCygPy1UIKlTfMXaSHB7QlwF2pLjBUwjXkhzssIzh2v67q89ZnIKb7Y94s0pPE8FRFhAskz+FKlayKNvgSpZQwy54o2SQ5ZnqpUgFuCAEfUPcrY7ZSoSmEAlRGWaOYoHiRjmXfLkR+3bTlIay61PAhKL2kxrHRXAPkxccbZ+bat3k/MGiIJLm6ognnQdTsecTaXPs+6KTq99VL5D7IlVDI9P9ONOHIaD7fS1PoE43vmDhwmZP+zDok9HeCZvfDbOv6078SarhuDRGUbQeBKDSgM6VP63ocqTDLLAjpahPuOg6r58DtoPISkz6CjWKYY4sOU6z0Ce/X9DptuioZCLktCE04D+LEa+thz3jZ/SP1NnX1oRUCmpS0OhHPHKnveAD3chxRcgFv02t47adwwgXjngTZ6WPuf6l+vsXA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_FC898DB083064E23BD3488657D36C98Bciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB2841.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c2d916e1-9519-4630-ab20-08d855636650 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2020 08:27:47.8002 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wCmStgqFfK8e7TZUVBXmqvGs+M6MjEbT5jpkp84IBapitYm7g/v3Bznha08S/KCO0qkJeaJolhubl81N9qQ0hw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2939 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: [netconf] Augmenting rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 08:27:55 -0000 --_000_FC898DB083064E23BD3488657D36C98Bciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, We have been discussing back and forth, and several interpretations of the = relevant RFCs (4741/6241 and 6020/7950) have come up. We would very much li= ke to hear the opinions on this list to settle the question. When a client issues an , a server would respond with an = or like this: or rpc missing-attribute error message-id rpc If the NETCONF server would like to augment additional information into the= rpc-reply, is that legal? If so, what would that look like? For the sake o= f the example, let's say the server would like to add something like this t= o the operation result: abc... While this example was for edit-config and a tag, we expect this dis= cussion should be equally applicable to other NETCONF operations with other= tags or attributes in both the success () and failure () ca= ses. Best Regards, /Jan Lindblad --_000_FC898DB083064E23BD3488657D36C98Bciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <6B8D22865284D346A457638D9BE4B844@namprd11.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Dear NETCONF WG,=

We have been disc= ussing back and forth, and several interpretations of the relevant RFCs (47= 41/6241 and 6020/7950) have come up. We would very much like to hear the op= inions on this list to settle the question.

When a client iss= ues an <edit-config>, a server would respond with an <ok> or &l= t;rpc-error> like this:

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

or

     <rpc-reply xmlns=3D"urn:ietf:params:xml:ns:ne=
tconf:base:1.0">
       <rpc-error>
         <error-type>rpc</error-type>
         <error-tag>missing-attribute</error-tag>
         <error-severity>error</error-severity>
         <error-info>
           <bad-attribute>message-id</bad-attribute>
           <bad-element>rpc</bad-element>
         </error-info>
       </rpc-error>
     </rpc-reply>

If the NETCONF server would like to augment additional info= rmation into the rpc-reply, is that legal? If so, what would that look like= ? For the sake of the example, let's say the server would like to add somet= hing like this to the operation result:

<note xmlns=3D"my-namespace">abc= ...</note>

While this example was for edit-config and a <note> t= ag, we expect this discussion should be equally applicable to other NETCONF= operations with other tags or attributes in both the success (<ok>) = and failure (<rpc-error>) cases.

Best Regards,
/Jan Lindblad

--_000_FC898DB083064E23BD3488657D36C98Bciscocom_-- From nobody Thu Sep 10 07:46:00 2020 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 619EB3A0C45 for ; Thu, 10 Sep 2020 07:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.947 X-Spam-Level: X-Spam-Status: No, score=-2.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ndt-inc.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 Ra30QjGIxQg4 for ; Thu, 10 Sep 2020 07:45:57 -0700 (PDT) Received: from delivery.mailspamprotection.com (delivery.mailspamprotection.com [146.66.121.80]) (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 8696C3A0C76 for ; Thu, 10 Sep 2020 07:45:57 -0700 (PDT) Received: from 108.134.209.35.bc.googleusercontent.com ([35.209.134.108] helo=usm9.siteground.biz) by se16.mailspamprotection.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1kGNpb-0006FC-I4 for netconf@ietf.org; Thu, 10 Sep 2020 09:45:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ndt-inc.com ; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=JdcvpEaVk4yQx9NYHh+l/MIK/X+nbZ0jkfvM6SPRUrA=; b=YIXNKzxnU/DK4vfT50Az7csQMJ J613ya3vjIH+S/HmrA6dJCUIKmW1vN1hUub9pr3IScX5/WKgmRfrF5eEo/6EAk5IaeEFUvgaFljQt 5ACh0ZxwPvpUKCHrPWRMLegZ3K3pqzwnUFllaD4gci53oYC32+OBQbuCEnIf+USPGGtyWSKz+4QMM /V60+NGh6prvpKq8qh57dmK3eLJ5yVGo4zcypVuPfgrQk3TR+iz+Apa/XVbAiPaKsSiHB70uM5rbY JrfgwdMkRU+TLcSIjFi/xO1Cs5pXFhPJpZWdcfohnBoO7yAMrZQtirq06NPrHMbNYe4ZYGP97nai/ 1lD/25Ag==; Received: from [104.158.52.238] (port=61121 helo=[192.168.0.11]) by usm9.siteground.biz with esmtpsa tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.90devstart-1178-b07e68e5-XX) (envelope-from ) id 1kGNpX-000CcQ-PX for netconf@ietf.org; Thu, 10 Sep 2020 09:45:43 -0500 To: netconf@ietf.org References: From: BL Message-ID: Date: Thu, 10 Sep 2020 10:45:46 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 8bit X-Originating-IP: 35.209.134.108 X-SpamExperts-Domain: usm9.siteground.biz X-SpamExperts-Username: 35.209.134.108 Authentication-Results: mailspamprotection.com; auth=pass smtp.auth=35.209.134.108@usm9.siteground.biz X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.19) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Ux9i8jFyHj5FzBttN4d2CmpSDasLI4SayDByyq9LIhVpIDKbSMKqCOo AOFMhMffZETNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDfAKZvAjuJrqAt2e//bIc/80D SEpCfISRYCKsig5kq2Jj2r6LwVzaeqJ+KmixyRrFZIOQYaDXB30lsHjt7j8HkIUhra8TUx3meeRt +wubTTN8IyMUYcjQIyM7A0a7Hw2/0LXYdRxy64PJ5ar6NXZxz1tOlr0+z/ilDEUwvRrWtaIJYSxy lOCUOhVdCS2dVe3E0p8T4Nd45j4kJRgJ8MJ6+H7AOBBVCDBuvQ2Tzrrvjr54DqxxlnCnOQKjhagE KuLSpFcLxHSMmVCkv47x59CmBIeCSxLZ5vMkhIi5r4+dNkkg921mdjeq9x3a70LThETW8FXNoZZP bj1AsAZNMWt0tZKDcNF1LrVoVLXP90si9Lylvnhbbs49QZ7Zf6tX0XMpdgXkdE4z4t2s9ub/ESVc nxUdFqkFA+YKkUlydLh5cSaHt73jJKU44zPi+Pzpc9G5DMXe7HNAN2+ce9dIwwYzhLSJjzN5e8VF lEjmqR4rzvUXKu1VbgppFJRGoXLED7mHbbgVl4iunqFoEGZzSy+km6VHO6XhXqN3g0DWG4Tioc84 Kpmg5+UpQ2PZprb+nvdWlgS6K9aAlnrXFI3hveFdl1IGypOmEegLwNvezJQnFJr0oL7gETS6dqfh jPl2KHb5vaeQZj2358XprAr7YTpSL1bGTHlR8YuZW/e2yUWvymUkMhj/QRW3+vPbIg67bbBfKC0g nYJkzp6VW+G2xA6YsX3F5Dq2ZyzveRjbFJnnfL66SqVkUMaZbxD5TnK9qN/v2zfpgu2LUdQgOCrc nAageVSgUi8Pewhw/V+Ek8zoH/xuIm8DYKCS8O75N9m22hw18PSCH03pPQqDktravYP+Va7emG6F Iv4osAGsCIqXSq0EpaVTOkDn4bjvSYvcVP/7NwpU15Un0FfK735x4KpOFKSEcE4wvr/xQ1llkMCC BlCXgDw+7QIw0sn8dfnInn3gM4OE8FBo9/u15HPAYu2P3WeupYYdzPm7YfRDaULOU2m1qXL+49o8 azgi4BgggOee9QgtUTdSx3/dYxat0mBq1ebZp1GDaNdqXDvHsn6feTg= X-Report-Abuse-To: spam@quarantine1.mailspamprotection.com Archived-At: Subject: Re: [netconf] Augmenting rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 14:45:59 -0000
RFC 6241: 4.3. <rpc-error> Element

error-info: ...
An implementation MAY include
additional elements to provide extended and/or implementation specific
debugging information.

Regards
    Borislav Lukovic

On 9/10/2020 4:27 AM, Jan Lindblad (jlindbla) wrote:
Dear NETCONF WG,

We have been discussing back and forth, and several interpretations of the relevant RFCs (4741/6241 and 6020/7950) have come up. We would very much like to hear the opinions on this list to settle the question.

When a client issues an <edit-config>, a server would respond with an <ok> or <rpc-error> like this:

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

or

     <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <rpc-error>
         <error-type>rpc</error-type>
         <error-tag>missing-attribute</error-tag>
         <error-severity>error</error-severity>
         <error-info>
           <bad-attribute>message-id</bad-attribute>
           <bad-element>rpc</bad-element>
         </error-info>
       </rpc-error>
     </rpc-reply>

If the NETCONF server would like to augment additional information into the rpc-reply, is that legal? If so, what would that look like? For the sake of the example, let's say the server would like to add something like this to the operation result:

<note xmlns="my-namespace">abc...</note>

While this example was for edit-config and a <note> tag, we expect this discussion should be equally applicable to other NETCONF operations with other tags or attributes in both the success (<ok>) and failure (<rpc-error>) cases.

Best Regards,
/Jan Lindblad



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


From nobody Thu Sep 10 09:53:06 2020 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 470B83A0DE5 for ; Thu, 10 Sep 2020 09:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.616 X-Spam-Level: X-Spam-Status: No, score=-0.616 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.482, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=cVBd8gpS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZWDzObvR Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thxnb8Sm4w6K for ; Thu, 10 Sep 2020 09:53:03 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 080883A0DE2 for ; Thu, 10 Sep 2020 09:53:03 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 73910E0E; Thu, 10 Sep 2020 12:53:01 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 10 Sep 2020 12:53:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm2; bh= bvgivuNKv4rbxKFuz6Mm8CNZmhyN3unOiq4cLGJZfFU=; b=cVBd8gpSmKGxtuKQ kklN23s0YWj8lO9kGDrDkM3uLcZOrrrsyvp4fY8+Pwr6SgdmQADcBsKjCBhIaBjY wTGxxBGWEWzPL83yBkWudocaU5xSLLSaFhwTZ1XTHXeLxN5QEdlPFq/YsXS/3TEE KzpUB2Yo5zkNeBB2XCOcmgk8X7uxwdmLJpx0CWgsMGLtVGxyu4Sc5u0Ydf+0GbvJ xuok70H4lB7mx04AZVJnhUCRxbhInPfunq50cBPOHxvfYVuvG+3oaBYJ+sa1Ztjt frjilGqtAIdLz+QMcaMeTWU+N4ZtWmOiUETwt5lr5t41kIoovGP2pISlxa7VO+B/ PZl3Jg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=bvgivuNKv4rbxKFuz6Mm8CNZmhyN3unOiq4cLGJZf FU=; b=ZWDzObvRRh9CQv2mTuDVSHoPTwpBbwVTPRps6fOl7UY4p3cxVmeaOqW9e Dr60q0KWWUFOlOy1F6Am+cHwiGmKc5i51xfa/cEpete0klcjO7TDh9iqD3lF8fXB YW6q0qjgaqeWsCwNG+D4Iej6+Z4fYQufdtn09E2UjglHyEExLJbX9RyA7aQxZDbj USU/eTjuNMIODLMpE66gfn2cToXrlgsNcTZLQwYZbMsNVQvOAG9HklOcRTJnDKW8 9j3tmIIV5xYhvolBlvR6x8EZVTaupeapEJQ+9eA3tXC0UYVtHzMtUSTz61FrGeyE vKbR5laMhvg+rUvbMRPapamykJuDA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudehjedguddttdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesth ejredtredtvdenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdo ihgvthhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpedtgefgtdduudejkeelve dviedvveehieegfeefteefgfeffeekheffvdefveffgfenucfkphepudehkedrudejgedr gedrgeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhgsjhdoihgvthhfseegieeikedrshgv X-ME-Proxy: Received: from localhost (unknown [158.174.4.44]) by mail.messagingengine.com (Postfix) with ESMTPA id 140DA306468D; Thu, 10 Sep 2020 12:52:59 -0400 (EDT) Date: Thu, 10 Sep 2020 18:52:58 +0200 (CEST) Message-Id: <20200910.185258.804843941725520730.id@4668.se> To: jlindbla=40cisco.com@dmarc.ietf.org Cc: netconf@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: References: X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] Augmenting rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 16:53:04 -0000 "Jan Lindblad \(jlindbla\)" wrote: > Dear NETCONF WG, > > We have been discussing back and forth, and several interpretations of > the relevant RFCs (4741/6241 and 6020/7950) have come up. We would > very much like to hear the opinions on this list to settle the > question. > > When a client issues an , a server would respond with an > or like this: > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > or > > > > > rpc > missing-attribute > error > > message-id > rpc > > > > > > If the NETCONF server would like to augment additional information > into the rpc-reply, is that legal? If so, what would that look like? The answer should be yes, this is legal, and it looks like this: augment /nc:edit-config/nc:output { leaf note { type string; } } And: abc... However, RFC 7950 says in section 7.14.4: If the RPC operation invocation succeeded and no output parameters are returned, the contains a single element defined in [RFC6241]. Which seems to say that if a note is returned, you would get: abc... This is also consistent with the XSD in RFC 6241. The problem with this though is that clients probably check for the presence of "ok" to verify that an edit-config succeeds, hence I think it should be allowed to reply with both and additional elements, as examplified above. > For the sake of the example, let's say the server would like to add > something like this to the operation result: > > abc... > > While this example was for edit-config and a tag, we expect > this discussion should be equally applicable to other NETCONF > operations with other tags or attributes in both the success () > and failure () cases. > > Best Regards, > /Jan Lindblad > /martin From nobody Thu Sep 10 11:48:16 2020 Return-Path: <01000174795889dc-006f122c-3f97-4738-a065-7f514ec544a6-000000@amazonses.watsen.net> 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 02F733A0F67 for ; Thu, 10 Sep 2020 11:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 ZGolWGsoC-8l for ; Thu, 10 Sep 2020 11:48:01 -0700 (PDT) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E413A0F69 for ; Thu, 10 Sep 2020 11:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1599763679; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=2+Ux5gnHgvXHiIVLz94a06McZZ2LqBkGH/1lyRlk4eU=; b=aVSwkGE4d4md5N+saTz9VespcjpNHblDNm/hfT8waMqxGE8TM7ypdlLnCsZji22K xKOmU/AgFN3Xz8cQhm7bVszcITxKKzKf0PEe+fF5WQvkdGFclgR5nDAuvkqHcrMGTmQ MoUroZdATsrIrOsZNhGcoYykweo7Psn1gKkW5hq4= From: Kent Watsen Message-ID: <01000174795889dc-006f122c-3f97-4738-a065-7f514ec544a6-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_075B3824-20F7-4CC6-A2D4-70EF6D824BCD" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 10 Sep 2020 18:47:59 +0000 In-Reply-To: <20200910.185258.804843941725520730.id@4668.se> Cc: jlindbla=40cisco.com@dmarc.ietf.org, "netconf@ietf.org" To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= References: <20200910.185258.804843941725520730.id@4668.se> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.09.10-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Augmenting rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 18:48:14 -0000 --Apple-Mail=_075B3824-20F7-4CC6-A2D4-70EF6D824BCD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 10, 2020, at 12:52 PM, Martin Bj=C3=B6rklund = wrote: >=20 > "Jan Lindblad \(jlindbla\)" > wrote: >> Dear NETCONF WG, >>=20 >> We have been discussing back and forth, and several interpretations = of >> the relevant RFCs (4741/6241 and 6020/7950) have come up. We would >> very much like to hear the opinions on this list to settle the >> question. >>=20 >> When a client issues an , a server would respond with an >> or like this: >>=20 >>=20 >> > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> >> >> >>=20 >>=20 >> or >>=20 >>=20 >> >> >> rpc >> missing-attribute >> error >> >> message-id >> rpc >> >> >> >>=20 >>=20 >> If the NETCONF server would like to augment additional information >> into the rpc-reply, is that legal? If so, what would that look like? >=20 > The answer should be yes, this is legal, and it looks like this: >=20 > augment /nc:edit-config/nc:output { > leaf note { > type string; > } > } >=20 > And: >=20 > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > abc... > >=20 > However, RFC 7950 says in section 7.14.4: >=20 > If the RPC operation invocation succeeded and no output parameters > are returned, the contains a single element = defined > in [RFC6241]. >=20 > Which seems to say that if a note is returned, you would get: >=20 > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > abc... > >=20 > This is also consistent with the XSD in RFC 6241. >=20 > The problem with this though is that clients probably check for the > presence of "ok" to verify that an edit-config succeeds, hence I think > it should be allowed to reply with both and additional elements, > as examplified above. I don=E2=80=99t think this would be enough, as client-validate of the = response might fail unless they know about the =E2=80=9Cmy-namespace=E2=80= =9D schema. For interoperability, it would be best for the clients to = send something in the request (or have something in their profile) = indicating that they=E2=80=99re able to process the extended response. For a longterm solution, please consider adding to the NETCONF-next = tracker: https://github.com/netconf-wg/netconf-next/issues = . We might also want = to consider the feasibility of doing the same for RESTCONF, as currently = RFC 8040 states that 204 (No Content) =E2=80=9Cis returned=E2=80=9D for = PUT and DELETE requests. K. >> For the sake of the example, let's say the server would like to add >> something like this to the operation result: >>=20 >> abc... >>=20 >> While this example was for edit-config and a tag, we expect >> this discussion should be equally applicable to other NETCONF >> operations with other tags or attributes in both the success () >> and failure () cases. >>=20 >> Best Regards, >> /Jan Lindblad >>=20 >=20 >=20 >=20 > /martin >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf = --Apple-Mail=_075B3824-20F7-4CC6-A2D4-70EF6D824BCD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Sep 10, 2020, at 12:52 PM, Martin Bj=C3=B6rklund <mbj+ietf@4668.se> = wrote:

"Jan Lindblad \(jlindbla\)" = <jlindbla=3D40cisco.com@dmarc.ietf.org> wrote:
Dear = NETCONF WG,

We have been discussing back = and forth, and several interpretations of
the relevant = RFCs (4741/6241 and 6020/7950) have come up. We would
very = much like to hear the opinions on this list to settle the
question.

When a client issues = an <edit-config>, a server would respond with an
<ok> or <rpc-error> like this:


    <rpc-reply = message-id=3D"101"
          &nb= sp;    xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.= 0">
      <ok/>
    </rpc-reply>


or


    <rpc-reply = xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
      <rpc-error>
        <error-type&= gt;rpc</error-type>
        <error-tag&g= t;missing-attribute</error-tag>
        <error-sever= ity>error</error-severity>
        <error-info&= gt;
          <= ;bad-attribute>message-id</bad-attribute>
          <= ;bad-element>rpc</bad-element>
        </error-info= >
      </rpc-error>
    </rpc-reply>


If the NETCONF server would like to augment = additional information
into the rpc-reply, is that legal? = If so, what would that look like?

The answer should be yes, this = is legal, and it looks like this:

 augment /nc:edit-config/nc:output {
   leaf note = {
     type string;
   }
 }

And:

     <rpc-reply = message-id=3D"101"
          &nb= sp;     xmlns=3D"urn:ietf:params:xml:ns:netconf:b= ase:1.0">
       <ok/>       <note = xmlns=3D"my-namespace">abc...</note>
     </rpc-reply>

However, RFC 7950 says in = section 7.14.4:

  If the RPC operation invocation succeeded and no = output parameters
  are returned, the <rpc-reply> contains a = single <ok/> element defined
  in [RFC6241].

Which seems to say that if a note is returned, you would = get:

     <rpc-reply = message-id=3D"101"
          &nb= sp;     xmlns=3D"urn:ietf:params:xml:ns:netconf:b= ase:1.0">
       <note = xmlns=3D"my-namespace">abc...</note>
     </rpc-reply>

This is also consistent with the = XSD in RFC 6241.

The problem with this though is that clients probably check = for the
presence of = "ok" to verify that an edit-config succeeds, hence I think
it should be allowed to reply = with both <ok/> and additional elements,
as examplified above.

I don=E2=80=99t = think this would be enough, as client-validate of the response might = fail unless they know about the =E2=80=9Cmy-namespace=E2=80=9D schema. =  For interoperability, it would = be best for the clients to send something in the request (or have = something in their profile) indicating that they=E2=80=99re able to = process the extended response.

For a longterm solution, please consider adding to = the NETCONF-next tracker: https://github.com/netconf-wg/netconf-next/issues. =  We might also want to consider the feasibility of doing the same = for RESTCONF, as currently RFC 8040 states that 204 (No Content) =E2=80=9C= is returned=E2=80=9D for PUT and DELETE requests.

K.



For = the sake of the example, let's say the server would like to add
something like this to the operation result:

<note xmlns=3D"my-namespace">abc...</note>

While this example was for edit-config and a = <note> tag, we expect
this discussion should be = equally applicable to other NETCONF
operations with other = tags or attributes in both the success (<ok>)
and = failure (<rpc-error>) cases.

Best = Regards,
/Jan Lindblad




/martin

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

= --Apple-Mail=_075B3824-20F7-4CC6-A2D4-70EF6D824BCD-- From nobody Thu Sep 10 12:31:45 2020 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 E2F703A10AD for ; Thu, 10 Sep 2020 12:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 MdVwsbJDQ87N for ; Thu, 10 Sep 2020 12:31:31 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 A165F3A1128 for ; Thu, 10 Sep 2020 12:31:30 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id d15so4205224lfq.11 for ; Thu, 10 Sep 2020 12:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dchW3WdRTXUgFwuVmMMiR5epI+mkFlpSGGYbU9acQSw=; b=pHCumdzgfCWHmH2hjAS20oZZlgx9JsgEre4pLwB/uTqLB1ZeEu22PmfFL4aQv8Hqv9 LRV1NrzBgLHJAaIL+CBxd8T1SmicoJQCWbYjpXA5nDmL8Lpvjxud9DzEO48TSkHfnw/o xz51+sLQcsEiKMQXJggJRirhNxFVFWlha57I+D4FS4KYmnQRFtP0HkGma80Sdz57BTp9 xCEUaFzNZN5TdQCKgac6hGCkYunyPyru5Sk4r4yn8AZDvJLZv1d3pISauIp9Ta4wlVGm +XzpGt4L0ERnim0pz8y+p/RrrHNB8v1WAEyMHtOUrSm1RXmYyg0s7uD9vUiwg5ovVm45 btlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dchW3WdRTXUgFwuVmMMiR5epI+mkFlpSGGYbU9acQSw=; b=UV6f3bXkMf9vcynrjYWXu3Ui9RhJsmgsl9oyoaNDIwsjcqAenKOidN4VRsfhkYLxtO 36oH5/+pgwwm+28xRtr68zxMyfg4awclJcc5EuR2sd1/k4DpxNsukD7DraG1LOHtN0N9 zqxez57Nr+39OfMAoFsi00EryMr+Aip1hLRGxTooLaWdAQRXymYQ2Uttcgn6vq8Kj2tC UdXxFR9gmk/nirjjUzeoO/9OafNdN6x2fwTy8cr0RgCK6Fs+dQ/evszTb5IbtfMe9wkP LvZ1wUQ2PRxChae3NvtaG2mM4+a/bZ9nFfcgvnEx12h769j/kDjkM2qEjlf2ud4gvlTm 4nmA== X-Gm-Message-State: AOAM532F7CRpkoIPn5QpFxhb/qBXuk/pV1lIPQQ4CnXLpYRdJAtYFolM Rd9KwuFjdGB6zi4klDAPL2j1ZZ7gle2YBuBSeRwQZw== X-Google-Smtp-Source: ABdhPJwSvMjCxVzg651R/+BrPYaakhiuBYjOCZW47XLGkDPF5fSDh8mkbHUpf7GfGk+fmkIpbE4kr9ZCtdscImwOcFg= X-Received: by 2002:a19:ee0d:: with SMTP id g13mr4874095lfb.139.1599766288640; Thu, 10 Sep 2020 12:31:28 -0700 (PDT) MIME-Version: 1.0 References: <20200910.185258.804843941725520730.id@4668.se> In-Reply-To: <20200910.185258.804843941725520730.id@4668.se> From: Andy Bierman Date: Thu, 10 Sep 2020 12:31:17 -0700 Message-ID: To: =?UTF-8?Q?Martin_Bj=C3=B6rklund?= Cc: jlindbla=40cisco.com@dmarc.ietf.org, Netconf Content-Type: multipart/alternative; boundary="0000000000005bc39d05aefa9dcc" Archived-At: Subject: Re: [netconf] Augmenting rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 19:31:44 -0000 --0000000000005bc39d05aefa9dcc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 10, 2020 at 9:53 AM Martin Bj=C3=B6rklund wr= ote: > "Jan Lindblad \(jlindbla\)" wrote= : > > Dear NETCONF WG, > > > > We have been discussing back and forth, and several interpretations of > > the relevant RFCs (4741/6241 and 6020/7950) have come up. We would > > very much like to hear the opinions on this list to settle the > > question. > > > > When a client issues an , a server would respond with an > > or like this: > > > > > > > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > > or > > > > > > > > > > rpc > > missing-attribute > > error > > > > message-id > > rpc > > > > > > > > > > > > If the NETCONF server would like to augment additional information > > into the rpc-reply, is that legal? If so, what would that look like? > > The answer should be yes, this is legal, and it looks like this: > > augment /nc:edit-config/nc:output { > leaf note { > type string; > } > } > > And: > > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > abc... > > > However, RFC 7950 says in section 7.14.4: > > If the RPC operation invocation succeeded and no output parameters > are returned, the contains a single element defined > in [RFC6241]. > > Which seems to say that if a note is returned, you would get: > > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > abc... > > > This is also consistent with the XSD in RFC 6241. > > The problem with this though is that clients probably check for the > presence of "ok" to verify that an edit-config succeeds, hence I think > it should be allowed to reply with both and additional elements, > as examplified above. > > I think this change is not backward-compatible because a conformant implementation might follow the XSD, which clearly shows "ok" as a choice, not mixed with the other responses. Also: 4.4 . Element The element is sent in messages if no errors or warnings occurred during the processing of an request, and no data was returned from the operation. Andy > > > For the sake of the example, let's say the server would like to add > > something like this to the operation result: > > > > abc... > > > > While this example was for edit-config and a tag, we expect > > this discussion should be equally applicable to other NETCONF > > operations with other tags or attributes in both the success () > > and failure () cases. > > > > Best Regards, > > /Jan Lindblad > > > > > > /martin > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --0000000000005bc39d05aefa9dcc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Sep 10, 2020 at 9:53 AM Marti= n Bj=C3=B6rklund <mbj+ietf@4668.se= > wrote:
= "Jan Lindblad \(jlindbla\)" <jlindbla=3D40cisco.com@dmarc.ietf.org>= ; wrote:
> Dear NETCONF WG,
>
> We have been discussing back and forth, and several interpretations of=
> the relevant RFCs (4741/6241 and 6020/7950) have come up. We would
> very much like to hear the opinions on this list to settle the
> question.
>
> When a client issues an <edit-config>, a server would respond wi= th an
> <ok> or <rpc-error> like this:
>
>
>=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=A0xmlns=3D&= quot;urn:ietf:params:xml:ns:netconf:base:1.0">
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <ok/>
>=C2=A0 =C2=A0 =C2=A0 </rpc-reply>
>
>
> or
>
>
>=C2=A0 =C2=A0 =C2=A0 <rpc-reply xmlns=3D"urn:ietf:params:xml:ns= :netconf:base:1.0">
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <rpc-error>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <error-type>rpc</error-type= >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <error-tag>missing-attribute&l= t;/error-tag>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <error-severity>error</erro= r-severity>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <error-info>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <bad-attribute>message-= id</bad-attribute>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <bad-element>rpc</ba= d-element>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </error-info>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </rpc-error>
>=C2=A0 =C2=A0 =C2=A0 </rpc-reply>
>
>
> If the NETCONF server would like to augment additional information
> into the rpc-reply, is that legal? If so, what would that look like?
The answer should be yes, this is legal, and it looks like this:

=C2=A0 augment /nc:edit-config/nc:output {
=C2=A0 =C2=A0 leaf note {
=C2=A0 =C2=A0 =C2=A0 type string;
=C2=A0 =C2=A0 }
=C2=A0 }

And:

=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=A0xmlns=3D"= ;urn:ietf:params:xml:ns:netconf:base:1.0">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <ok/>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <note xmlns=3D"my-namespace">ab= c...</note>
=C2=A0 =C2=A0 =C2=A0 </rpc-reply>

However, RFC 7950 says in section 7.14.4:

=C2=A0 =C2=A0If the RPC operation invocation succeeded and no output parame= ters
=C2=A0 =C2=A0are returned, the <rpc-reply> contains a single <ok/&= gt; element defined
=C2=A0 =C2=A0in [RFC6241].

Which seems to say that if a note is returned, you would get:

=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=A0xmlns=3D"= ;urn:ietf:params:xml:ns:netconf:base:1.0">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <note xmlns=3D"my-namespace">ab= c...</note>
=C2=A0 =C2=A0 =C2=A0 </rpc-reply>

This is also consistent with the XSD in RFC 6241.

The problem with this though is that clients probably check for the
presence of "ok" to verify that an edit-config succeeds, hence I = think
it should be allowed to reply with both <ok/> and additional elements= ,
as examplified above.


I think this change is not backward-co= mpatible because a conformant implementation
might follow the XSD= , which clearly shows "ok" as a choice, not mixed with the other<= /div>
responses.



=C2=A0<!--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <rpc-reply> element
= =C2=A0 =C2=A0 =C2=A0 =C2=A0-->
=C2=A0 =C2=A0 =C2=A0<xs:complexType= name=3D"rpcReplyType">
=C2=A0 =C2=A0 =C2=A0 =C2=A0<xs:c= hoice>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<xs:element name=3D"= ok"/>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<xs:sequence>
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<xs:element ref=3D"rpc-err= or"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0minOccurs=3D"0" maxOccurs=3D"unbounded&q= uot;/>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<xs:element ref=3D= "rpcResponse"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0minOccurs=3D"0" maxOccurs=3D&q= uot;unbounded"/>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</xs:seque= nce>
=C2=A0 =C2=A0 =C2=A0 =C2=A0</xs:choice>
=C2=A0 =C2=A0 = =C2=A0 =C2=A0<xs:attribute name=3D"message-id" type=3D"me= ssageIdType"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0use=3D"optional"/>
=C2=A0 =C2=A0 = =C2=A0 =C2=A0<!--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Any attributes s= upplied with <rpc> element must be returned
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 on <rpc-reply>.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--= >
=C2=A0 =C2=A0 =C2=A0 =C2=A0<xs:anyAttribute processContents=3D&q= uot;lax"/>
=C2=A0 =C2=A0 =C2=A0</xs:complexType>
=C2=A0= =C2=A0 =C2=A0<xs:element name=3D"rpc-reply" type=3D"rpcR= eplyType"/>

Also:
4.4.  <ok> Element


   The <ok> element is sent in <rpc-reply> messages if no error=
s or
   warnings occurred during the processing of an <rpc> request, and n=
o
   data was returned from the operation.


And=
y

=
=C2=A0

> For the sake of the example, let's say the server would like to ad= d
> something like this to the operation result:
>
> <note xmlns=3D"my-namespace">abc...</note>
>
> While this example was for edit-config and a <note> tag, we expe= ct
> this discussion should be equally applicable to other NETCONF
> operations with other tags or attributes in both the success (<ok&g= t;)
> and failure (<rpc-error>) cases.
>
> Best Regards,
> /Jan Lindblad
>



/martin

_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--0000000000005bc39d05aefa9dcc-- From nobody Thu Sep 10 13:02:48 2020 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 668FF3A00E0 for ; Thu, 10 Sep 2020 13:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.947 X-Spam-Level: X-Spam-Status: No, score=-2.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ndt-inc.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 1vlmJbWt5vu3 for ; Thu, 10 Sep 2020 13:02:41 -0700 (PDT) Received: from delivery.mailspamprotection.com (delivery.mailspamprotection.com [146.66.121.163]) (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 986B13A00E5 for ; Thu, 10 Sep 2020 13:02:41 -0700 (PDT) Received: from 108.134.209.35.bc.googleusercontent.com ([35.209.134.108] helo=usm9.siteground.biz) by se19.mailspamprotection.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1kGSmD-000EEz-9m for netconf@ietf.org; Thu, 10 Sep 2020 15:02:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ndt-inc.com ; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:References:To:Subject:From:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=80vJFvbjfGYd4rmFU5zqM/xXwqfJ0zdaDI90FHm6/KY=; b=Dqt3LkTcI8XYKJorJUeqg4gRkj di9RgttrdhFNaz466tk94KpAdpuA7HjWN49Dsme0hwLpyxZ/+exYUkVoY7L2Jlt3U6IDVrZex/svE iESYEQpX8pJTplaX/t33kmFYP3IXLLli+6r7Nd6NI5RBwtOpRxhGLG5msP6mg8Pmd1fytCtJAjj3g 73LQ0gx1Dt+bl5NcWULKTchE8eqnSusQOeTHJ+n0EnDE2EWI2CxWiKTQK9hPNQLWFGYne+9J/Esob eEEGMk7TEjKpVzabm+mV2KWmmJFOXCXnIpuIFdFwF7jEU74mW+VqtQ5XGFazTNjSG6zfBYRf2SmFo gjs4LPCg==; Received: from [104.158.52.238] (port=57729 helo=[192.168.0.11]) by usm9.siteground.biz with esmtpsa tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.90devstart-1178-b07e68e5-XX) (envelope-from ) id 1kGSmB-0008Vk-SB for netconf@ietf.org; Thu, 10 Sep 2020 15:02:35 -0500 From: BL To: netconf@ietf.org References: <20200910.185258.804843941725520730.id@4668.se> Message-ID: Date: Thu, 10 Sep 2020 16:02:36 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20200910.185258.804843941725520730.id@4668.se> Content-Type: text/html; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: 35.209.134.108 X-SpamExperts-Domain: usm9.siteground.biz X-SpamExperts-Username: 35.209.134.108 Authentication-Results: mailspamprotection.com; auth=pass smtp.auth=35.209.134.108@usm9.siteground.biz X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.16) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Ux9i8jFyHj5FzBttN4d2CmpSDasLI4SayDByyq9LIhVRd0maQyJx+hl 2Hpp+y2XbkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDfAKZvAjuJrqAt2e//bIc/80D SEpCfISRYCKsig5kq2J0sEdyL12LyawlyA4Rpz3fZIOQYaDXB30lsHjt7j8HkIUhra8TUx3meeRt +wubTTN8IyMUYcjQIyM7A0a7Hw2/0LXYdRxy64PJ5ar6NXZxz1tOlr0+z/ilDEUwvRrWtaIJYSxy lOCUOhVdCS2dVe3E0p8T4Nd45j4kJRgJ8MJ6+Lbg54OUBZbdh6VWgAnfl8p4DqxxlnCnOQKjhagE KuLSpFcLxHSMmVCkv47x59CmBIeCSxLZ5vMkhIi5r4+dNkkg921mdjeq9x3a70LThETW8FXNoZZP bj1AsAZNMWt0tZKDcNF1LrVoVLXP90si9Lylvnhbbs49QZ7Zf6tX0XMpdgXkdE4z4t2s9ub/ESVc nxUdFqkFA+YKkUlydLh5cSaHt73jJKU44zPi+Pzpc9G5DMXe7HNAN2+ce9dIwwYzhLSJjzN5e8VF lEjmqR4rzvUXKu1VbgppFJRGoXLED7mHbbgVl4iunqFoEGZzSy+km6VHO6XhXqN3g0DWG4Tioc84 Kpmg5+UpQ2PZprb+nvdWlgS6K9aAlnrXFI3hveFdl2eq/qzceto8CcRq9s+GCaXOeSo+FQAObmD0 VKOYk5mGiU5kvlu4NkDxYW25mjIWhoB/rjBzlgNbb1EnmZQ6W41BnxV7vrqtm+8eTkwXzwr2oKbs 1UemucIXgC/FkHy3pB1FwvATlZ9Ul2WmcMm637alfrrQwspGMmH9O9Ru/ZIqd5XdG63CgJuXpt48 NSiQMYLUAj1reKtuJ/PKbNBhf48EvBRuunLSplrr9QRZqw0PZZMNJ8quWiXUAmdknSuMGQ0xJ0iB XG5yyzNjv8REXgSClBil8hpVlsvzJoExwMCOfqb5R4VemuUI6bcEARsm0Dr3oUiCwaAHstJEoNvD O1dLfMJvL9MU4OTcHOkZJFZv3ZSvk4v9HutKS1dcD2JhVi7/+fOTvqVqTiiM4NskccTyD/jwFMJs L+hBK6STp56WJrV9kzdlDY8OFlMKDf8PPuirgpnjCsDh3bxR+3JNRr8= X-Report-Abuse-To: spam@quarantine1.mailspamprotection.com Archived-At: Subject: Re: [netconf] Augmenting rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 20:02:44 -0000
On 9/10/2020 12:52 PM, Martin Björklund wrote:
"Jan Lindblad \(jlindbla\)" <jlindbla=40cisco.com@dmarc.ietf.org> wrote:

Dear NETCONF WG,

We have been discussing back and forth, and several interpretations of
the relevant RFCs (4741/6241 and 6020/7950) have come up. We would
very much like to hear the opinions on this list to settle the
question.

When a client issues an <edit-config>, a server would respond with an
<ok> or <rpc-error> like this:


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


or


     <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <rpc-error>
         <error-type>rpc</error-type>
         <error-tag>missing-attribute</error-tag>
         <error-severity>error</error-severity>
         <error-info>
           <bad-attribute>message-id</bad-attribute>
           <bad-element>rpc</bad-element>
         </error-info>
       </rpc-error>
     </rpc-reply>


If the NETCONF server would like to augment additional information
into the rpc-reply, is that legal? If so, what would that look like?

The answer should be yes, this is legal, and it looks like this:

  augment /nc:edit-config/nc:output {
    leaf note {
      type string;
    }
  }

And:

      <rpc-reply message-id="101"
                 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <ok/>
        <note xmlns="my-namespace">abc...</note>
      </rpc-reply>

However, RFC 7950 says in section 7.14.4:

   If the RPC operation invocation succeeded and no output parameters
   are returned, the <rpc-reply> contains a single <ok/> element defined
   in [RFC6241].

Which seems to say that if a note is returned, you would get:

      <rpc-reply message-id="101"
                 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <note xmlns="my-namespace">abc...</note>
      </rpc-reply>

This is also consistent with the XSD in RFC 6241.

The problem with this though is that clients probably check for the
presence of "ok" to verify that an edit-config succeeds, hence I think
it should be allowed to reply with both <ok/> and additional elements,
as examplified above.
Returning both <ok> and <note>  is inconsistent with rfc6241: Appendix B:

     <xs:complexType name="rpcReplyType">
       <xs:choice>
         <xs:element name="ok"/>
         <xs:sequence>
           <xs:element ref="rpc-error" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="rpcResponse" minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
       </xs:choice>


/Borislav

For the sake of the example, let's say the server would like to add
something like this to the operation result:

<note xmlns="my-namespace">abc...</note>

While this example was for edit-config and a <note> tag, we expect
this discussion should be equally applicable to other NETCONF
operations with other tags or attributes in both the success (<ok>)
and failure (<rpc-error>) cases.

Best Regards,
/Jan Lindblad


/martin

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


From nobody Thu Sep 10 14:38:46 2020 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 E7DBA3A0C20; Thu, 10 Sep 2020 14:38:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: netconf@ietf.org, kent+ietf@watsen.net, rwilton@cisco.com, netconf-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159977392342.9765.6403874395448022271@ietfa.amsl.com> Date: Thu, 10 Sep 2020 14:38:43 -0700 Archived-At: Subject: [netconf] netconf - New Meeting Session Request for IETF 109 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 21:38:44 -0000 A new meeting session request has just been submitted by Kent Watsen, a Chair of the netconf working group. --------------------------------------------------------- Working Group Name: Network Configuration Area Name: Operations and Management Area Session Requester: Kent Watsen Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 65 Conflicts to Avoid: Chair Conflict: netmod tcpm idr Technology Overlap: opsarea opsawg People who must be present: Mahesh Jethanandani Kent Watsen Robert Wilton Resources Requested: Special Requests: First morning session preferred. --------------------------------------------------------- From nobody Fri Sep 11 05:30:04 2020 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 8D7C33A0FA9 for ; Fri, 11 Sep 2020 05:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=Lru6b82U; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=tsYbYyik Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pf93wZpXAtDc for ; Fri, 11 Sep 2020 05:30:00 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B0493A0F44 for ; Fri, 11 Sep 2020 05:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17313; q=dns/txt; s=iport; t=1599827398; x=1601036998; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Cd2BN0RWG5bvPMwTitXrrLmwYQE3M7woJxYtJ6nHsdU=; b=Lru6b82UOpAgsDq128Mokxo5+Ko4TTpe2x4x1yScvO1AN6Mr5+SfvdnQ bLFajA4Uj68gPrBNui4H600I9heGQtxyT5sonah9NLRgEATm4PM8z0GIU zUgBeLOf9gYUgUfC3A0AzquLmvf5i50PmuMQ16BtOFjKqUkggbw4uz8qf w=; IronPort-PHdr: =?us-ascii?q?9a23=3AoRfMvxXj/09FnGDyLGN4hAPNuw3V8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyBufNJl+SQtLrvCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFzfvnP06iQdSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DVBgD7bFtf/5FdJa1fgliBIy9RB3B?= =?us-ascii?q?ZLywKhC6DRgONQZQphG6BLhSBEQNVCwEBAQ0BASMKAgQBAYRLAheCDAIkNAk?= =?us-ascii?q?OAgMBAQsBAQUBAQECAQYEbYVcDIVzAgEDEhEdAQE3AQ8CAQhCAgICMCUCBA4?= =?us-ascii?q?gB4MEAYF+TQMuAQMLqGoCgTmIYXaBMoMBAQEFhRIYghADBoE4gnGDaYZDDxu?= =?us-ascii?q?BQT+BOAwQgk0+glwCgSUiRYJqM4ItkyeGbyaLS5B+CoJliGyGUIp8Ax6DCYl?= =?us-ascii?q?zk2edMJBjhCkCBAIEBQIOAQEFgVQ6gVdwFTsqAYI+UBcCDZIQilZ0NwIGAQk?= =?us-ascii?q?BAQMJfIwmLYEGAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.76,415,1592870400"; d="scan'208,217";a="559230836" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Sep 2020 12:29:56 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 08BCTu2l009032 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 11 Sep 2020 12:29:56 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 11 Sep 2020 07:29:55 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 11 Sep 2020 07:29:55 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 11 Sep 2020 07:29:55 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D+GjQ3pVLBUj4RJGX9x6zTxozx3o0u1G1ZkhVnSLdDd3iHnIsYCfa/Re/aIfcy8x5yFuTBR31IT4zP4EI/coCV3UyxOx/urtJbGgY0B6F2kBP6ckTdxD6qaS5LgdPYZ3+gLdMo/JgbEvkshsar44WIsxf7LjyM0mDq+8Zy4+b2jRu/nT2CiS3Fl97wuNIb+9eVk1C/npWb/cVdarTtS71JSdizmecbm1vYkwDheGHayEt46wedGDpeF1RRpTLCH1IdasnaCErCc7jZYVXQmNE5TvCihIZA3BD4fVxb93qRFA2JeO7EAabNNbD1hxs6ow8WNC0vXg7Cjkk5Tl7uz8qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Cd2BN0RWG5bvPMwTitXrrLmwYQE3M7woJxYtJ6nHsdU=; b=ZT4YMqZkU06DdP08wcqeDpa2iMyjA+WGRoF3XjjUS/DZ2nmKO9w2tYU5wkoNqpH8VoIuPhkNjgd7osPc+08E0sby1hlUaXgwch0oxqWSmIsC1jMvI0r4SkkzYAecuAwe+62IUvo1S8dp37H+qNo07lZDTAfNLtxMB3s236Qz8bghwCRiOaoy79rZvAtVDLkJxC02GdlzSOP/5Tcg91MAJNbvU/828l6gfylV8ouL08B7VRNDrxf2tosEBVBuEBRArDsTMePOE4KILoLN+HAELY6kRpVKiIyxb7eqJJ+7TdXvhZiPUO8mO5GWJ8BcdeMGHO2fNgz7sV8x1Es1H0PQEA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Cd2BN0RWG5bvPMwTitXrrLmwYQE3M7woJxYtJ6nHsdU=; b=tsYbYyiku/Aokt1vjEayVnXJDWUrvQgO+sliJWIUDZ+IMiYYM86anyMM7SdPJGneXxx5BZu/dQfbbqFWe5N1GPInGLHXZDEPLN8/XVJ9Zub5ILKe9qhUY4nYWsZ6rm5GRx0Ew0xEPHpHLL8H/gEJmaRFMw306RYRaitDAuh9M6M= Received: from DM6PR11MB2841.namprd11.prod.outlook.com (2603:10b6:5:c8::32) by DM6PR11MB2873.namprd11.prod.outlook.com (2603:10b6:5:bd::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3370.16; Fri, 11 Sep 2020 12:29:54 +0000 Received: from DM6PR11MB2841.namprd11.prod.outlook.com ([fe80::fd62:3aa7:c332:92b2]) by DM6PR11MB2841.namprd11.prod.outlook.com ([fe80::fd62:3aa7:c332:92b2%7]) with mapi id 15.20.3370.017; Fri, 11 Sep 2020 12:29:54 +0000 From: "Jan Lindblad (jlindbla)" To: Netconf CC: =?utf-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= , Andy Bierman , "bl@ndt-inc.com" , "kent@watsen.net" Thread-Topic: [netconf] Augmenting rpc-reply Thread-Index: AQHWh0xEdb16zB4JDk6ZAIx+dcpuoKliFxMAgAAsPICAARyVgA== Date: Fri, 11 Sep 2020 12:29:54 +0000 Message-ID: <0CCA567F-5691-4A85-812C-0B95470E5C6C@cisco.com> References: <20200910.185258.804843941725520730.id@4668.se> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [213.67.237.150] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9f2d3968-30bf-41a4-6aba-08d8564e6321 x-ms-traffictypediagnostic: DM6PR11MB2873: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IC/WPqtJW7sm3RknDj83AtFjCqTPTxhler+bceUGQQswPu+fofRZDyzjoWERrLpTtCnCrWM1PGNrwFw63nYGVrCh/n47/NWdt8C1pvEvJ25G0dEpdyNJzrD05rnEz7XneYv/ajRsoirTWoGH1ceYvgcukpIly+OiCbapdzY2JiPTxAR1PUkKv4DdZhNaRz8BD5SZqpcy9Sgi9X6rPZpI+Nq2DT88jneznrIr10mqU9HrdtG0ZoNzqdwh9pKJtrt1ggYUQX58gYyWA7ZIUCL1dIJu9DIZbVUW8G2vmmoriXXoJJLOu5XhbG0YegohYk228ikdxbC+YEg0ta076vgU5WvWvpjLTxtoJpn1pGQZ9QZ/x5LKPvOuYsUZX9/StPQEkbTgjxGwPAj5IN/NKD14HQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB2841.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(39860400002)(396003)(136003)(376002)(346002)(8936002)(66476007)(6916009)(64756008)(66946007)(8676002)(91956017)(5660300002)(6486002)(76116006)(66556008)(86362001)(186003)(26005)(36756003)(478600001)(6506007)(4326008)(71200400001)(54906003)(316002)(2906002)(66446008)(83380400001)(166002)(966005)(6512007)(2616005)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: miOzobMNiMX9FVVTfW76YZUDBp05OvZGUl/zHl/A2+6lDal5eA3ahPfih0XOKiHhkvHkNuh9X1JiuOeT9Bx3qQeoMk4ElVHUbaBsQ4klUT/EDiq/rydVM6e8aXVyFb42cGBa1g03y69WmpD+bKO/+7RiiOVrUeU1CWQJxulePjxdepBPdyIvI7mBnn284X3/RN14dASrh5sgZCndto5sViTcTMWnh6YdetycMvv4BFJ4n/+Ss/UGNcDRFxUC/V4oww8y9w5tEPyj5cROc8cvC1pyen6HItwmG764aJbIgSo162FeQpRuT53Z5KNlCqcRHToHp0saNJDXE0Txe+pacTA3kxvAxqzxfb/0c6Jby8376iow0Gi9W1OYAjh+PpA78UjJ2WH+seOwBZJUsje9QAtkp5xjh+m9k2hWopTCSt4IVo+eX7wHgVhZ6Gr8aM0feBkyH06m4hr2AGNndE/bTTWAprMQhMdAtMuLB57AsBghVvD2/45MXK8A3miN6ysiAWycIKL60JlWZc+fD1nZSVVHdtdsmPZ6Sqi2ASupTCXAVi3DBooZqzWef4UDs77G37fgjHpnFae1jg/tsIEgskrLjakNcNi2aobfkW1iFz5VYiZZudP0VEE4+FbQeq75Jj3VEZ2VR3pEskmLDczAWg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_0CCA567F56914A85812C0B95470E5C6Cciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB2841.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9f2d3968-30bf-41a4-6aba-08d8564e6321 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2020 12:29:54.2318 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: oeWLIE/oaMCORAGApM4n678RUbKXo/m8+HYWrLm5H0U2sI1Rl1Ul2jamQ0G3A4qUkz8EmJiutI8GnBKUNkhAIg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2873 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [netconf] Augmenting rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2020 12:30:03 -0000 --_000_0CCA567F56914A85812C0B95470E5C6Cciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBORVRDT05GIFdHLA0KDQpUaGFuayB5b3UgYWxsIGZvciBjb250cmlidXRpbmcgdmlld3Bv aW50cy4gQWN0dWFsbHksIHRoZXNlIGFuc3dlcnMgd2VyZSBhIHN1cnByaXNpbmdseSBmYWl0aGZ1 bCByZWZsZWN0aW9uIG9mIHRoZSBpbnRlcm5hbCBkaXNjdXNzaW9uIHdlIGhhZCwgd2hpY2ggcHJv bXB0ZWQgdXMgdG8gdG8gdGFrZSB0aGUgcXVlc3Rpb24gdG8gdGhlIGxpc3QuDQoNClNpbmNlIHRo ZXJlIHdhcyBjbGVhcmx5IG5vIHJvdWdoIGNvbnNlbnN1cyBvbiB0aGUgbWF0dGVyLCBsZXQgbWUg dm9pY2UgdGhlIGNvdW50ZXIgYXJndW1lbnRzIHdlIGhhZCBpbiBvdXIgaW50ZXJuYWwgZGlzY3Vz c2lvbiBmb3IgdGhvc2UgYXJndW1lbnRzIHRoYXQgd2VyZSBhbHNvIG1lbnRpb25lZCBoZXJlIG9u IHRoZSBsaXN0LCBpbiBvcmRlciB0byBzZWUgaWYgd2UgY2FuIGRpc3RpbGwgYXQgbGVhc3Qgc29t ZSBvcmRlciBpbiB0aGlzLg0KDQpNYXJ0aW4gc3VnZ2VzdGVkIHRoYXQ6DQoNCkhvd2V2ZXIsIFJG QyA3OTUwIHNheXMgaW4gc2VjdGlvbiA3LjE0LjQ6DQoNCiAgIElmIHRoZSBSUEMgb3BlcmF0aW9u IGludm9jYXRpb24gc3VjY2VlZGVkIGFuZCBubyBvdXRwdXQgcGFyYW1ldGVycw0KICAgYXJlIHJl dHVybmVkLCB0aGUgPHJwYy1yZXBseT4gY29udGFpbnMgYSBzaW5nbGUgPG9rLz4gZWxlbWVudCBk ZWZpbmVkDQogICBpbiBbUkZDNjI0MV0uDQoNCklzIGl0IHJlYXNvbmFibGUgdG8gaW50ZXJwcmV0 IHRoaXMgNzk1MCBsYW5ndWFnZSB0byBleGNsdWRlIGFueSBhbmQgYWxsIGV4dGVuc2lvbnM/IE9u ZSBjb3VsZCBhcmd1ZSB0aGF0IHRoaXMgcHJlc2NyaWJlcyBhIHNpbmdsZSA8b2svPiBhcyBmYXIg YXMgNzk1MCBhbmQgNjI0MSBhcmUgY29uY2VybmVkLCBidXQgbm90IHJ1bGluZyBvdXQgZXh0ZW5z aW9ucy4NCg0KV2hpY2ggc2VlbXMgdG8gc2F5IHRoYXQgaWYgYSBub3RlIGlzIHJldHVybmVkLCB5 b3Ugd291bGQgZ2V0Og0KDQogICAgICA8cnBjLXJlcGx5IG1lc3NhZ2UtaWQ9IjEwMSINCiAgICAg ICAgICAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEu MCI+DQogICAgICAgIDxub3RlIHhtbG5zPSJteS1uYW1lc3BhY2UiPmFiYy4uLjwvbm90ZT4NCiAg ICAgIDwvcnBjLXJlcGx5Pg0KDQpUaGlzIGlzIGFsc28gY29uc2lzdGVudCB3aXRoIHRoZSBYU0Qg aW4gUkZDIDYyNDEuDQoNClhTRHMgYWx3YXlzIHNwZWFrIGFib3V0IHdoYXQgdGhleSByZXF1aXJl IGluIHRoZWlyIHRhcmdldE5hbWVzcGFjZSwgYW5kIGhhdmUgbm8gImp1cmlzZGljdGlvbiIgb3Zl ciBvdGhlciBuYW1lc3BhY2VzLiBUaHVzIFhTRHMgaGF2ZSBubyB3YXkgb2YgcHJlY2x1ZGluZyBl eHRlbnNpb25zLiBJcyBpdCByZWFzb25hYmxlIHRoZXJlZm9yZSB0byBjb25jbHVkZSB0aGVuIHRo YXQgdGhlIE5FVENPTkYgWFNEcyBjYW5ub3QgYmUgdGFrZW4gYXMgZXZpZGVuY2UgZWl0aGVyIGZv ciBvciBhZ2FpbnN0IGV4dGVuc2lvbnM/DQoNClRoZSBwcm9ibGVtIHdpdGggdGhpcyB0aG91Z2gg aXMgdGhhdCBjbGllbnRzIHByb2JhYmx5IGNoZWNrIGZvciB0aGUNCnByZXNlbmNlIG9mICJvayIg dG8gdmVyaWZ5IHRoYXQgYW4gZWRpdC1jb25maWcgc3VjY2VlZHMsIGhlbmNlIEkgdGhpbmsNCml0 IHNob3VsZCBiZSBhbGxvd2VkIHRvIHJlcGx5IHdpdGggYm90aCA8b2svPiBhbmQgYWRkaXRpb25h bCBlbGVtZW50cywNCmFzIGV4YW1wbGlmaWVkIGFib3ZlLg0KDQpJdCBzZWVtcyByZWFzb25hYmxl IHRvIGFzc3VtZSBtb3N0IG9yIGFsbCBORVRDT05GIHNlcnZlcnMgd291bGQgc2VuZCwgYW5kIG1v c3QgY2xpZW50cyB3b3VsZCBsb29rIGZvciA8b2svPiBpbiB0aGUgcnBjLXJlcGx5LiBJZiBhbnlv bmUgaGFzIGEgY291bnRlciBleGFtcGxlIChpLmUuIGNhbiBuYW1lIGFuIGltcGxlbWVudGF0aW9u IHRoYXQgZG9lcyBub3QpLCBwbGVhc2Ugc3BlYWsgdXAuDQoNCkFuZHkgc3VnZ2VzdGVkIHRoYXQ6 DQoNCkkgdGhpbmsgdGhpcyBjaGFuZ2UgaXMgbm90IGJhY2t3YXJkLWNvbXBhdGlibGUgYmVjYXVz ZSBhIGNvbmZvcm1hbnQgaW1wbGVtZW50YXRpb24NCm1pZ2h0IGZvbGxvdyB0aGUgWFNELCB3aGlj aCBjbGVhcmx5IHNob3dzICJvayIgYXMgYSBjaG9pY2UsIG5vdCBtaXhlZCB3aXRoIHRoZSBvdGhl cg0KcmVzcG9uc2VzLg0KDQpJZiBYU0RzIGhhdmUgbm8gd2F5IG9mIGV4cHJlc3NpbmcgdGhlIGFi c2VuY2Ugb2YgdGFncyBpbiBmb3JlaWduIG5hbWVzcGFjZXMsIGFuZCBwcm9wZXJseSB3cml0dGVu IFhNTCBwYXJzaW5nIGFwcGxpY2F0aW9ucyBnZW5lcmFsbHkgYXJlIG1hZGUgdG8gc2tpcCBvdmVy IHRhZ3MgYW5kIGF0dHJpYnV0ZXMgaW4gdW5rbm93biBuYW1lc3BhY2VzLCB3b3VsZCBpdCBiZSBy ZWFzb25hYmxlIHRvIHNheSB0aGF0IGV4dGVuc2lvbnMgYXJlIGJhY2t3YXJkcyBjb21wYXRpYmxl PyBUaGlzIGlzIHRoZSB0aGVvcmV0aWNhbCBwYXJ0IG9mIHRoZSBxdWVzdGlvbi4NCg0KVGhlIG90 aGVyIHBhcnQgaXMgbW9yZSBwcmFjdGljYWw6IEFzc3VtaW5nIHRoZSB0aGVvcnkgaXMgdHJ1ZSwg d291bGQgdGhlIE5FVENPTkYgV0cgaGF2ZSB0aGUgY291cmFnZSB0byBjYWxsIGFueSBpbXBsZW1l bnRhdGlvbiB0aGF0IGRvZXMgbm90IGZvbGxvdyB0aGVzZSBYTUwvWFNEIHByaW5jaXBsZXMgaW5j b3JyZWN0Pw0KDQpLZW50IHN1Z2dlc3RlZCB0aGF0Og0KDQpJIGRvbuKAmXQgdGhpbmsgdGhpcyB3 b3VsZCBiZSBlbm91Z2gsIGFzIGNsaWVudC12YWxpZGF0ZSBvZiB0aGUgcmVzcG9uc2UgbWlnaHQg ZmFpbCB1bmxlc3MgdGhleSBrbm93IGFib3V0IHRoZSDigJxteS1uYW1lc3BhY2XigJ0gc2NoZW1h LiAgRm9yIGludGVyb3BlcmFiaWxpdHksIGl0IHdvdWxkIGJlIGJlc3QgZm9yIHRoZSBjbGllbnRz IHRvIHNlbmQgc29tZXRoaW5nIGluIHRoZSByZXF1ZXN0IChvciBoYXZlIHNvbWV0aGluZyBpbiB0 aGVpciBwcm9maWxlKSBpbmRpY2F0aW5nIHRoYXQgdGhleeKAmXJlIGFibGUgdG8gcHJvY2VzcyB0 aGUgZXh0ZW5kZWQgcmVzcG9uc2UuDQoNClRoZSBkaXNjdXNzaW9uIGFib3V0IHdlbGwgYmVoYXZl ZCBjbGllbnRzIGlzIGFscmVhZHkgY2FwdHVyZWQgYWJvdmUsIGJ1dCB0aGUgYW5nbGUgYWJvdXQg dGhlIGNsaWVudCBzaWRlIHNlbmRpbmcgY2FwYWJpbGl0eSBzdHJpbmdzIGluIGhlbGxvIGlzIG5l dy4gSW4gd2hhdCBzaXR1YXRpb25zIHdvdWxkIHN1Y2ggYSBjbGllbnQgc2lkZSBjYXBhYmlsaXR5 IGRlY2xhcmF0aW9uIGJlIHJlcXVpcmVkPyBXaGF0IFlBTkcgYXVnbWVudHMgd291bGQgb25seSBi ZSBzZW50IHRvIGNsaWVudHMgdGhhdCBoYXZlIGRlY2xhcmVkIGtub3dsZWRnZSBvZiB0aGVtLCBh bmQgd2hpY2ggYXVnbWVudHMgd291bGQgYWx3YXlzIGJlIHNlbnQ/DQoNCkZvciBhIGxvbmd0ZXJt IHNvbHV0aW9uLCBwbGVhc2UgY29uc2lkZXIgYWRkaW5nIHRvIHRoZSBORVRDT05GLW5leHQgdHJh Y2tlcjogaHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvbmV0Y29uZi1uZXh0L2lzc3Vlcy4g IFdlIG1pZ2h0IGFsc28gd2FudCB0byBjb25zaWRlciB0aGUgZmVhc2liaWxpdHkgb2YgZG9pbmcg dGhlIHNhbWUgZm9yIFJFU1RDT05GLCBhcyBjdXJyZW50bHkgUkZDIDgwNDAgc3RhdGVzIHRoYXQg MjA0IChObyBDb250ZW50KSDigJxpcyByZXR1cm5lZOKAnSBmb3IgUFVUIGFuZCBERUxFVEUgcmVx dWVzdHMuDQoNCkdvb2QgcG9pbnQuIElzIGl0IHJlYXNvbmFibGUgdG8gYmVsaWV2ZSBtYW55IFJF U1RDT05GIGNsaWVudHMgd291bGQgZmFpbCBpZiBhIHNlcnZlciByZXR1cm5lZCBhIGRpZmZlcmVu dCAyeHggY29kZSBhbmQgYSBib2R5IHJhdGhlciB0aGFuIDIwND8gQW5kIGlmIHNvLCB3b3VsZCBz dWNoIGEgUkVTVENPTkYgY2xpZW50IGJlIGNvbnNpZGVyZWQgd2VsbCBiZWhhdmVkPw0KDQpCb3Jp c2xhdiBhbHNvIGNvbW1lbnRlZCwgYnV0IEkgYmVsaWV2ZSB0aGUgdG9waWNzIGFyZSBhbHJlYWR5 IGNvdmVyZWQgaW4gdGhlIGFib3ZlLg0KDQpCZXN0IFJlZ2FyZHMsDQovamFuDQoNCg== --_000_0CCA567F56914A85812C0B95470E5C6Cciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <6C3291629D52E445954F5BEE0107121F@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+RGVhciBORVRDT05GIFdH LDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NClRoYW5rIHlvdSBh bGwgZm9yIGNvbnRyaWJ1dGluZyB2aWV3cG9pbnRzLiBBY3R1YWxseSwgdGhlc2UgYW5zd2VycyB3 ZXJlIGEgc3VycHJpc2luZ2x5IGZhaXRoZnVsIHJlZmxlY3Rpb24gb2YgdGhlIGludGVybmFsIGRp c2N1c3Npb24gd2UgaGFkLCB3aGljaCBwcm9tcHRlZCB1cyB0byB0byB0YWtlIHRoZSBxdWVzdGlv biB0byB0aGUgbGlzdC4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPlNpbmNlIHRoZXJlIHdhcyBjbGVhcmx5IG5vIHJvdWdoIGNvbnNlbnN1cyBvbiB0 aGUgbWF0dGVyLCBsZXQgbWUgdm9pY2UgdGhlIGNvdW50ZXIgYXJndW1lbnRzIHdlIGhhZCBpbiBv dXIgaW50ZXJuYWwgZGlzY3Vzc2lvbiBmb3IgdGhvc2UgYXJndW1lbnRzIHRoYXQgd2VyZSBhbHNv IG1lbnRpb25lZCBoZXJlIG9uIHRoZSBsaXN0LCBpbiBvcmRlciB0byBzZWUgaWYgd2UgY2FuIGRp c3RpbGwgYXQgbGVhc3Qgc29tZSBvcmRlcg0KIGluIHRoaXMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5NYXJ0aW4gc3VnZ2VzdGVkIHRo YXQ6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBUaW1lc05ld1JvbWFuUFNNVDsgZm9udC1zaXplOiAxNHB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4 dC1kZWNvcmF0aW9uOiBub25lOyI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0 eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdC13aWR0aDogMXB4OyBi b3JkZXItbGVmdC1zdHlsZTogc29saWQ7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0LCAyMDQs IDIwNCk7IHBhZGRpbmctbGVmdDogMWV4OyI+DQpIb3dldmVyLCBSRkMgNzk1MCBzYXlzIGluIHNl Y3Rpb24gNy4xNC40OjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtJ ZiB0aGUgUlBDIG9wZXJhdGlvbiBpbnZvY2F0aW9uIHN1Y2NlZWRlZCBhbmQgbm8gb3V0cHV0IHBh cmFtZXRlcnM8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7YXJlIHJldHVybmVkLCB0aGUgJmx0 O3JwYy1yZXBseSZndDsgY29udGFpbnMgYSBzaW5nbGUgJmx0O29rLyZndDsgZWxlbWVudCBkZWZp bmVkPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO2luIFtSRkM2MjQxXS48YnIgY2xhc3M9IiI+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+SXMgaXQgcmVhc29uYWJsZSB0byBpbnRlcnByZXQgdGhp cyA3OTUwIGxhbmd1YWdlIHRvIGV4Y2x1ZGUgYW55IGFuZCBhbGwgZXh0ZW5zaW9ucz8gT25lIGNv dWxkIGFyZ3VlIHRoYXQgdGhpcyBwcmVzY3JpYmVzIGEgc2luZ2xlICZsdDtvay8mZ3Q7IGFzIGZh ciBhcyA3OTUwIGFuZCA2MjQxIGFyZSBjb25jZXJuZWQsIGJ1dCBub3QgcnVsaW5nIG91dCBleHRl bnNpb25zLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IFRpbWVz TmV3Um9tYW5QU01UOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij4NCjxibG9j a3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHggMC44 ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOiAxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsgYm9y ZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4N CldoaWNoIHNlZW1zIHRvIHNheSB0aGF0IGlmIGEgbm90ZSBpcyByZXR1cm5lZCwgeW91IHdvdWxk IGdldDo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bHQ7cnBjLXJlcGx5IG1lc3NhZ2UtaWQ9JnF1b3Q7MTAxJnF1b3Q7PGJyIGNsYXNzPSIiPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDt4bWxucz0mcXVvdDt1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAmcXVv dDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtub3Rl IHhtbG5zPSZxdW90O215LW5hbWVzcGFjZSZxdW90OyZndDthYmMuLi4mbHQ7L25vdGUmZ3Q7PGJy IGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0Oy9ycGMtcmVwbHkmZ3Q7PGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhpcyBpcyBhbHNvIGNvbnNpc3RlbnQgd2l0aCB0aGUg WFNEIGluIFJGQyA2MjQxLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5YU0Rz IGFsd2F5cyBzcGVhayBhYm91dCB3aGF0IHRoZXkgcmVxdWlyZSBpbiB0aGVpciB0YXJnZXROYW1l c3BhY2UsIGFuZCBoYXZlIG5vICZxdW90O2p1cmlzZGljdGlvbiZxdW90OyBvdmVyIG90aGVyIG5h bWVzcGFjZXMuIFRodXMgWFNEcyBoYXZlIG5vIHdheSBvZiBwcmVjbHVkaW5nIGV4dGVuc2lvbnMu IElzIGl0IHJlYXNvbmFibGUgdGhlcmVmb3JlIHRvIGNvbmNsdWRlIHRoZW4gdGhhdCB0aGUgTkVU Q09ORiBYU0RzIGNhbm5vdCBiZSB0YWtlbiBhcyBldmlkZW5jZQ0KIGVpdGhlciBmb3Igb3IgYWdh aW5zdCBleHRlbnNpb25zPzwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 ImdtYWlsX3F1b3RlIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IFRpbWVzTmV3Um9tYW5QU01UOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7 Ij4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjogMHB4IDBw eCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOiAxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBz b2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgcGFkZGluZy1sZWZ0 OiAxZXg7Ij4NClRoZSBwcm9ibGVtIHdpdGggdGhpcyB0aG91Z2ggaXMgdGhhdCBjbGllbnRzIHBy b2JhYmx5IGNoZWNrIGZvciB0aGU8YnIgY2xhc3M9IiI+DQpwcmVzZW5jZSBvZiAmcXVvdDtvayZx dW90OyB0byB2ZXJpZnkgdGhhdCBhbiBlZGl0LWNvbmZpZyBzdWNjZWVkcywgaGVuY2UgSSB0aGlu azxiciBjbGFzcz0iIj4NCml0IHNob3VsZCBiZSBhbGxvd2VkIHRvIHJlcGx5IHdpdGggYm90aCAm bHQ7b2svJmd0OyBhbmQgYWRkaXRpb25hbCBlbGVtZW50cyw8YnIgY2xhc3M9IiI+DQphcyBleGFt cGxpZmllZCBhYm92ZS48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+SXQgc2Vl bXMgcmVhc29uYWJsZSB0byBhc3N1bWUgbW9zdCBvciBhbGwgTkVUQ09ORiBzZXJ2ZXJzIHdvdWxk IHNlbmQsIGFuZCBtb3N0IGNsaWVudHMgd291bGQgbG9vayBmb3IgJmx0O29rLyZndDsgaW4gdGhl IHJwYy1yZXBseS4gSWYgYW55b25lIGhhcyBhIGNvdW50ZXIgZXhhbXBsZSAoaS5lLiBjYW4gbmFt ZSBhbiBpbXBsZW1lbnRhdGlvbiB0aGF0IGRvZXMgbm90KSwgcGxlYXNlIHNwZWFrIHVwLjwvZGl2 Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+QW5keSBzdWdnZXN0ZWQgdGhhdDo8 L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5 bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBUaW1lc05ld1JvbWFu UFNNVDsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+DQo8ZGl2IGNsYXNzPSIi PkkgdGhpbmsgdGhpcyBjaGFuZ2UgaXMgbm90IGJhY2t3YXJkLWNvbXBhdGlibGUgYmVjYXVzZSBh IGNvbmZvcm1hbnQgaW1wbGVtZW50YXRpb248L2Rpdj4NCjxkaXYgY2xhc3M9IiI+bWlnaHQgZm9s bG93IHRoZSBYU0QsIHdoaWNoIGNsZWFybHkgc2hvd3MgJnF1b3Q7b2smcXVvdDsgYXMgYSBjaG9p Y2UsIG5vdCBtaXhlZCB3aXRoIHRoZSBvdGhlcjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5yZXNwb25z ZXMuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXY+SWYgWFNEcyBoYXZlIG5vIHdheSBvZiBleHByZXNzaW5nIHRoZSBh YnNlbmNlIG9mIHRhZ3MgaW4gZm9yZWlnbiBuYW1lc3BhY2VzLCBhbmQgcHJvcGVybHkgd3JpdHRl biBYTUwgcGFyc2luZyBhcHBsaWNhdGlvbnMgZ2VuZXJhbGx5IGFyZSBtYWRlIHRvIHNraXAgb3Zl ciB0YWdzIGFuZCBhdHRyaWJ1dGVzIGluIHVua25vd24gbmFtZXNwYWNlcywgd291bGQgaXQgYmUg cmVhc29uYWJsZSB0byBzYXkgdGhhdCBleHRlbnNpb25zIGFyZSBiYWNrd2FyZHMNCiBjb21wYXRp YmxlPyBUaGlzIGlzIHRoZSB0aGVvcmV0aWNhbCBwYXJ0IG9mIHRoZSBxdWVzdGlvbi48L2Rpdj4N CjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRoZSBvdGhlciBwYXJ0IGlzIG1vcmUg cHJhY3RpY2FsOiBBc3N1bWluZyB0aGUgdGhlb3J5IGlzIHRydWUsIHdvdWxkIHRoZSBORVRDT05G IFdHIGhhdmUgdGhlIGNvdXJhZ2UgdG8gY2FsbCBhbnkgaW1wbGVtZW50YXRpb24gdGhhdCBkb2Vz IG5vdCBmb2xsb3cgdGhlc2UgWE1ML1hTRCBwcmluY2lwbGVzIGluY29ycmVjdD88L2Rpdj4NCjxk aXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PktlbnQgc3VnZ2VzdGVkIHRoYXQ6PC9kaXY+ DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9IiI+PC9kaXY+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiBUaW1lc05ld1JvbWFuUFNNVDsiIGNsYXNzPSIiPkkgZG9u4oCZ dCB0aGluayB0aGlzIHdvdWxkIGJlIGVub3VnaCwgYXMgY2xpZW50LXZhbGlkYXRlIG9mIHRoZSBy ZXNwb25zZSBtaWdodCBmYWlsIHVubGVzcyB0aGV5IGtub3cgYWJvdXQgdGhlIOKAnG15LW5hbWVz cGFjZeKAnSBzY2hlbWEuICZuYnNwOzwvc3Bhbj48Zm9udCBjb2xvcj0iIzAwMDAwMCIgY2xhc3M9 IiIgc3R5bGU9ImZvbnQtZmFtaWx5OiBUaW1lc05ld1JvbWFuUFNNVDsiPkZvcg0KIGludGVyb3Bl cmFiaWxpdHksIGl0IHdvdWxkIGJlIGJlc3QgZm9yIHRoZSBjbGllbnRzIHRvIHNlbmQgc29tZXRo aW5nIGluIHRoZSByZXF1ZXN0IChvciBoYXZlIHNvbWV0aGluZyBpbiB0aGVpciBwcm9maWxlKSBp bmRpY2F0aW5nIHRoYXQgdGhleeKAmXJlIGFibGUgdG8gcHJvY2VzcyB0aGUgZXh0ZW5kZWQgcmVz cG9uc2UuPC9mb250PjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXY+VGhlIGRpc2N1c3Npb24gYWJvdXQgd2VsbCBiZWhhdmVkIGNsaWVudHMgaXMg YWxyZWFkeSBjYXB0dXJlZCBhYm92ZSwgYnV0IHRoZSBhbmdsZSBhYm91dCB0aGUgY2xpZW50IHNp ZGUgc2VuZGluZyBjYXBhYmlsaXR5IHN0cmluZ3MgaW4gaGVsbG8gaXMgbmV3LiBJbiB3aGF0IHNp dHVhdGlvbnMgd291bGQgc3VjaCBhIGNsaWVudCBzaWRlIGNhcGFiaWxpdHkgZGVjbGFyYXRpb24g YmUgcmVxdWlyZWQ/IFdoYXQgWUFORyBhdWdtZW50cyB3b3VsZA0KIG9ubHkgYmUgc2VudCB0byBj bGllbnRzIHRoYXQgaGF2ZSBkZWNsYXJlZCBrbm93bGVkZ2Ugb2YgdGhlbSwgYW5kIHdoaWNoIGF1 Z21lbnRzIHdvdWxkIGFsd2F5cyBiZSBzZW50PzwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5G b3IgYSBsb25ndGVybSBzb2x1dGlvbiwgcGxlYXNlIGNvbnNpZGVyIGFkZGluZyB0byB0aGUgTkVU Q09ORi1uZXh0IHRyYWNrZXI6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL25ldGNv bmYtd2cvbmV0Y29uZi1uZXh0L2lzc3VlcyIgY2xhc3M9IiI+aHR0cHM6Ly9naXRodWIuY29tL25l dGNvbmYtd2cvbmV0Y29uZi1uZXh0L2lzc3VlczwvYT4uICZuYnNwO1dlIG1pZ2h0IGFsc28gd2Fu dCB0byBjb25zaWRlciB0aGUgZmVhc2liaWxpdHkNCiBvZiBkb2luZyB0aGUgc2FtZSBmb3IgUkVT VENPTkYsIGFzIGN1cnJlbnRseSBSRkMgODA0MCBzdGF0ZXMgdGhhdCAyMDQgKE5vIENvbnRlbnQp IOKAnGlzIHJldHVybmVk4oCdIGZvciBQVVQgYW5kIERFTEVURSByZXF1ZXN0cy48L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpHb29kIHBvaW50LiBJcyBp dCByZWFzb25hYmxlIHRvIGJlbGlldmUgbWFueSBSRVNUQ09ORiBjbGllbnRzIHdvdWxkIGZhaWwg aWYgYSBzZXJ2ZXIgcmV0dXJuZWQgYSBkaWZmZXJlbnQgMnh4IGNvZGUgYW5kIGEgYm9keSByYXRo ZXIgdGhhbiAyMDQ/IEFuZCBpZiBzbywgd291bGQgc3VjaCBhIFJFU1RDT05GIGNsaWVudCBiZSBj b25zaWRlcmVkIHdlbGwgYmVoYXZlZD88L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2PkJvcmlzbGF2IGFsc28gY29tbWVudGVkLCBidXQgSSBiZWxpZXZlIHRoZSB0b3BpY3Mg YXJlIGFscmVhZHkgY292ZXJlZCBpbiB0aGUgYWJvdmUuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdj5CZXN0IFJlZ2FyZHMsPC9kaXY+DQo8ZGl2Pi9qYW48L2Rpdj4NCjxk aXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_0CCA567F56914A85812C0B95470E5C6Cciscocom_-- From nobody Fri Sep 11 05:56:31 2020 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 1CB213A08DE for ; Fri, 11 Sep 2020 05:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 CRChT9dvmkC1 for ; Fri, 11 Sep 2020 05:56:27 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65BFD3A08D6 for ; Fri, 11 Sep 2020 05:56:27 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id CF0DB83F; Fri, 11 Sep 2020 14:56:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id dTU9L3f-wt2P; Fri, 11 Sep 2020 14:56:25 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 11 Sep 2020 14:56:25 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 623C820156; Fri, 11 Sep 2020 14:56:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id KI6pLj0D9QNI; Fri, 11 Sep 2020 14:56:25 +0200 (CEST) Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id 2B42B20154; Fri, 11 Sep 2020 14:56:24 +0200 (CEST) Date: Fri, 11 Sep 2020 14:56:23 +0200 From: Juergen Schoenwaelder To: "Jan Lindblad (jlindbla)" Cc: Netconf , "kent@watsen.net" Message-ID: <20200911125623.upqcb4p5oqnv5xd7@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Jan Lindblad (jlindbla)" , Netconf , "kent@watsen.net" References: <20200910.185258.804843941725520730.id@4668.se> <0CCA567F-5691-4A85-812C-0B95470E5C6C@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0CCA567F-5691-4A85-812C-0B95470E5C6C@cisco.com> Archived-At: Subject: Re: [netconf] Augmenting rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2020 12:56:29 -0000 On Fri, Sep 11, 2020 at 12:29:54PM +0000, Jan Lindblad (jlindbla) wrote: > However, RFC 7950 says in section 7.14.4: > > If the RPC operation invocation succeeded and no output parameters > are returned, the contains a single element defined > in [RFC6241]. > > Is it reasonable to interpret this 7950 language to exclude any and all extensions? One could argue that this prescribes a single as far as 7950 and 6241 are concerned, but not ruling out extensions. This is how I would have read this statement. > Which seems to say that if a note is returned, you would get: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > abc... > > > This is also consistent with the XSD in RFC 6241. This behavior might be consistent with the XSD but I suspect that some clients get pretty confused if instead of an that get something they did not expect. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Sep 11 05:59:45 2020 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 0A8A63A0B23 for ; Fri, 11 Sep 2020 05:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.616 X-Spam-Level: X-Spam-Status: No, score=-0.616 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.482, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=VcvdBeAu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GXjQ4D3a Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ev_J9zyPPgZr for ; Fri, 11 Sep 2020 05:59:41 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6573A0B19 for ; Fri, 11 Sep 2020 05:59:37 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 04ED3C38; Fri, 11 Sep 2020 08:59:35 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Fri, 11 Sep 2020 08:59:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm2; bh= wqDZC8jsDd6MH4ho/3Pw9B38j0ASK0zZ9muZFZOY3YA=; b=VcvdBeAuGOdr7Bns RbJs8sUSmH6kh2Q19tEnIYJNHoetAy2wjXyHeJsthWQpRnZfFeGpwh9hww3Wy6sT 8PyRftSzguU7ZoLV5IHv9Dt5NLnPQgbEdm/z/7IPFlM/uIaOEGd5ad9PjDo/PSoE d9ssvXfdJx8pPqZaNcA6Obb7tcOc5ko3wZMalH8gAYqSUfntg2nW5NxPsN7sW4j+ tpXulntqpoOJcjKo9I8QTIaj3zEVTnEByt9XTOSqVEoivMLBxie0LffvJUAtCRWV aj35XzHMeX+4oC9sorCNkzl4AvrJ1B1Q+XepEuZ2LUTbdo65Pel0A4URTb9ko2MQ Ovamwg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=wqDZC8jsDd6MH4ho/3Pw9B38j0ASK0zZ9muZFZOY3 YA=; b=GXjQ4D3akye4yw36fNg/IK+8cAFge2Ipjm4hEjK5oQXlrRLM92DDc9rcO +ljfxBTn9aANNSHGGPUWrDocvkqSZKBDIsMmFvjVvyYmm2gpIU6ratm94J9iWRB4 XQ/LLqSU31VBGNhXw4aGpg5OTcT5nuhTPxX19qgNYP12AlNPFNG3pz1D8El6Kjih ccGBaMwam3k5m4j5hb4+Y5ETTTNwhrWEpV5pWr+b4I9FDGrjFom5u9cP1lrXDFXc 6TeTNJTfSRqGgninYmGtsWHthI9HalSEgH0H0luC0oxHIxCk9XeuQRosYeog3dAR qjaA3thnRuE4af6+T4yJy4GLPjWlg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudehledgieduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtsg ertdertdejnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepvdeuffegvedtfeeukeehke etffetffevheevgedvvdehffdujeevtdefiefggeelnecuffhomhgrihhnpehgihhthhhu sgdrtghomhenucfkphepudehkedrudejgedrgedrgeegnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgsjhdoihgvthhfseegieeikedrshgv X-ME-Proxy: Received: from localhost (unknown [158.174.4.44]) by mail.messagingengine.com (Postfix) with ESMTPA id AA42A3064674; Fri, 11 Sep 2020 08:59:33 -0400 (EDT) Date: Fri, 11 Sep 2020 14:59:32 +0200 (CEST) Message-Id: <20200911.145932.1721440341637757560.id@4668.se> To: jlindbla@cisco.com Cc: netconf@ietf.org, mbj+ietf@4668.se, andy@yumaworks.com, bl@ndt-inc.com, kent@watsen.net From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <0CCA567F-5691-4A85-812C-0B95470E5C6C@cisco.com> References: <20200910.185258.804843941725520730.id@4668.se> <0CCA567F-5691-4A85-812C-0B95470E5C6C@cisco.com> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] Augmenting rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2020 12:59:43 -0000 IkphbiBMaW5kYmxhZCAoamxpbmRibGEpIiA8amxpbmRibGFAY2lzY28uY29tPiB3cm90ZToNCj4g RGVhciBORVRDT05GIFdHLA0KPiANCj4gVGhhbmsgeW91IGFsbCBmb3IgY29udHJpYnV0aW5nIHZp ZXdwb2ludHMuIEFjdHVhbGx5LCB0aGVzZSBhbnN3ZXJzDQo+IHdlcmUgYSBzdXJwcmlzaW5nbHkg ZmFpdGhmdWwgcmVmbGVjdGlvbiBvZiB0aGUgaW50ZXJuYWwgZGlzY3Vzc2lvbiB3ZQ0KPiBoYWQs IHdoaWNoIHByb21wdGVkIHVzIHRvIHRvIHRha2UgdGhlIHF1ZXN0aW9uIHRvIHRoZSBsaXN0Lg0K PiANCj4gU2luY2UgdGhlcmUgd2FzIGNsZWFybHkgbm8gcm91Z2ggY29uc2Vuc3VzIG9uIHRoZSBt YXR0ZXIsIGxldCBtZSB2b2ljZQ0KPiB0aGUgY291bnRlciBhcmd1bWVudHMgd2UgaGFkIGluIG91 ciBpbnRlcm5hbCBkaXNjdXNzaW9uIGZvciB0aG9zZQ0KPiBhcmd1bWVudHMgdGhhdCB3ZXJlIGFs c28gbWVudGlvbmVkIGhlcmUgb24gdGhlIGxpc3QsIGluIG9yZGVyIHRvIHNlZQ0KPiBpZiB3ZSBj YW4gZGlzdGlsbCBhdCBsZWFzdCBzb21lIG9yZGVyIGluIHRoaXMuDQo+IA0KPiBNYXJ0aW4gc3Vn Z2VzdGVkIHRoYXQ6DQo+IA0KPiBIb3dldmVyLCBSRkMgNzk1MCBzYXlzIGluIHNlY3Rpb24gNy4x NC40Og0KPiANCj4gICAgSWYgdGhlIFJQQyBvcGVyYXRpb24gaW52b2NhdGlvbiBzdWNjZWVkZWQg YW5kIG5vIG91dHB1dCBwYXJhbWV0ZXJzDQo+ICAgIGFyZSByZXR1cm5lZCwgdGhlIDxycGMtcmVw bHk+IGNvbnRhaW5zIGEgc2luZ2xlIDxvay8+IGVsZW1lbnQgZGVmaW5lZA0KPiAgICBpbiBbUkZD NjI0MV0uDQo+IA0KPiBJcyBpdCByZWFzb25hYmxlIHRvIGludGVycHJldCB0aGlzIDc5NTAgbGFu Z3VhZ2UgdG8gZXhjbHVkZSBhbnkgYW5kDQo+IGFsbCBleHRlbnNpb25zPyBPbmUgY291bGQgYXJn dWUgdGhhdCB0aGlzIHByZXNjcmliZXMgYSBzaW5nbGUgPG9rLz4gYXMNCj4gZmFyIGFzIDc5NTAg YW5kIDYyNDEgYXJlIGNvbmNlcm5lZCwgYnV0IG5vdCBydWxpbmcgb3V0IGV4dGVuc2lvbnMuDQo+ IA0KPiBXaGljaCBzZWVtcyB0byBzYXkgdGhhdCBpZiBhIG5vdGUgaXMgcmV0dXJuZWQsIHlvdSB3 b3VsZCBnZXQ6DQo+IA0KPiAgICAgICA8cnBjLXJlcGx5IG1lc3NhZ2UtaWQ9IjEwMSINCj4gICAg ICAgICAgICAgICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6 MS4wIj4NCj4gICAgICAgICA8bm90ZSB4bWxucz0ibXktbmFtZXNwYWNlIj5hYmMuLi48L25vdGU+ DQo+ICAgICAgIDwvcnBjLXJlcGx5Pg0KPiANCj4gVGhpcyBpcyBhbHNvIGNvbnNpc3RlbnQgd2l0 aCB0aGUgWFNEIGluIFJGQyA2MjQxLg0KPiANCj4gWFNEcyBhbHdheXMgc3BlYWsgYWJvdXQgd2hh dCB0aGV5IHJlcXVpcmUgaW4gdGhlaXIgdGFyZ2V0TmFtZXNwYWNlLA0KPiBhbmQgaGF2ZSBubyAi anVyaXNkaWN0aW9uIiBvdmVyIG90aGVyIG5hbWVzcGFjZXMuIFRodXMgWFNEcyBoYXZlIG5vDQo+ IHdheSBvZiBwcmVjbHVkaW5nIGV4dGVuc2lvbnMuIElzIGl0IHJlYXNvbmFibGUgdGhlcmVmb3Jl IHRvIGNvbmNsdWRlDQo+IHRoZW4gdGhhdCB0aGUgTkVUQ09ORiBYU0RzIGNhbm5vdCBiZSB0YWtl biBhcyBldmlkZW5jZSBlaXRoZXIgZm9yIG9yDQo+IGFnYWluc3QgZXh0ZW5zaW9ucz8NCg0KVGhp cyBpcyBub3QgY29ycmVjdC4gIFNlZSBmb3IgZXhhbXBsZSBob3cgbmFtZXNwYWNlPSIjI290aGVy IiBpcyB1c2VkDQppbiBlcnJvckluZm9UeXBlIHRvIGV4cGxpY2l0bHkgYWxsb3cgZWxlbWVudHMg ZnJvbSBvdGhlciBuYW1lc3BhY2VzLg0KDQo+IFRoZSBwcm9ibGVtIHdpdGggdGhpcyB0aG91Z2gg aXMgdGhhdCBjbGllbnRzIHByb2JhYmx5IGNoZWNrIGZvciB0aGUNCj4gcHJlc2VuY2Ugb2YgIm9r IiB0byB2ZXJpZnkgdGhhdCBhbiBlZGl0LWNvbmZpZyBzdWNjZWVkcywgaGVuY2UgSSB0aGluaw0K PiBpdCBzaG91bGQgYmUgYWxsb3dlZCB0byByZXBseSB3aXRoIGJvdGggPG9rLz4gYW5kIGFkZGl0 aW9uYWwgZWxlbWVudHMsDQo+IGFzIGV4YW1wbGlmaWVkIGFib3ZlLg0KPiANCj4gSXQgc2VlbXMg cmVhc29uYWJsZSB0byBhc3N1bWUgbW9zdCBvciBhbGwgTkVUQ09ORiBzZXJ2ZXJzIHdvdWxkIHNl bmQsDQo+IGFuZCBtb3N0IGNsaWVudHMgd291bGQgbG9vayBmb3IgPG9rLz4gaW4gdGhlIHJwYy1y ZXBseS4gSWYgYW55b25lIGhhcw0KPiBhIGNvdW50ZXIgZXhhbXBsZSAoaS5lLiBjYW4gbmFtZSBh biBpbXBsZW1lbnRhdGlvbiB0aGF0IGRvZXMgbm90KSwNCj4gcGxlYXNlIHNwZWFrIHVwLg0KPiAN Cj4gQW5keSBzdWdnZXN0ZWQgdGhhdDoNCj4gDQo+IEkgdGhpbmsgdGhpcyBjaGFuZ2UgaXMgbm90 IGJhY2t3YXJkLWNvbXBhdGlibGUgYmVjYXVzZSBhIGNvbmZvcm1hbnQNCj4gaW1wbGVtZW50YXRp b24NCj4gbWlnaHQgZm9sbG93IHRoZSBYU0QsIHdoaWNoIGNsZWFybHkgc2hvd3MgIm9rIiBhcyBh IGNob2ljZSwgbm90IG1peGVkDQo+IHdpdGggdGhlIG90aGVyDQo+IHJlc3BvbnNlcy4NCj4gDQo+ IElmIFhTRHMgaGF2ZSBubyB3YXkgb2YgZXhwcmVzc2luZyB0aGUgYWJzZW5jZSBvZiB0YWdzIGlu IGZvcmVpZ24NCj4gbmFtZXNwYWNlcywgYW5kIHByb3Blcmx5IHdyaXR0ZW4gWE1MIHBhcnNpbmcg YXBwbGljYXRpb25zIGdlbmVyYWxseQ0KPiBhcmUgbWFkZSB0byBza2lwIG92ZXIgdGFncyBhbmQg YXR0cmlidXRlcyBpbiB1bmtub3duIG5hbWVzcGFjZXMsIHdvdWxkDQo+IGl0IGJlIHJlYXNvbmFi bGUgdG8gc2F5IHRoYXQgZXh0ZW5zaW9ucyBhcmUgYmFja3dhcmRzIGNvbXBhdGlibGU/IFRoaXMN Cj4gaXMgdGhlIHRoZW9yZXRpY2FsIHBhcnQgb2YgdGhlIHF1ZXN0aW9uLg0KPiANCj4gVGhlIG90 aGVyIHBhcnQgaXMgbW9yZSBwcmFjdGljYWw6IEFzc3VtaW5nIHRoZSB0aGVvcnkgaXMgdHJ1ZSwg d291bGQNCj4gdGhlIE5FVENPTkYgV0cgaGF2ZSB0aGUgY291cmFnZSB0byBjYWxsIGFueSBpbXBs ZW1lbnRhdGlvbiB0aGF0IGRvZXMNCj4gbm90IGZvbGxvdyB0aGVzZSBYTUwvWFNEIHByaW5jaXBs ZXMgaW5jb3JyZWN0Pw0KDQpJIHRoaW5rIGluIGdlbmVyYWwgd2UgZXhwZWN0IHdlbGwtYmVoYXZl ZCBjbGllbnRzIHRvIGlnbm9yZSBlbGVtZW50cw0KZnJvbSBvdGhlciBuYW1lc3BhY2VzLiAgQnV0 IHRoaXMgaXMgYSBzcGVjaWFsIGNhc2Ugc2luY2UgdGhlIFhTRA0KZXhwbGljaXRseSBkb2VzIG5v dCBhbGxvdyBlbGVtZW50cyBmcm9tIG90aGVyIG5hbWVzcGFjZXMgdG9nZXRoZXIgd2l0aA0KPG9r Lz4gIChJIHRoaW5rIHRoYXQgdGhpcyBpcyB2ZXJ5IHVuZm9ydHVuYXRlKS4NCg0KPiBLZW50IHN1 Z2dlc3RlZCB0aGF0Og0KPiANCj4gSSBkb27igJl0IHRoaW5rIHRoaXMgd291bGQgYmUgZW5vdWdo LCBhcyBjbGllbnQtdmFsaWRhdGUgb2YgdGhlIHJlc3BvbnNlDQo+IG1pZ2h0IGZhaWwgdW5sZXNz IHRoZXkga25vdyBhYm91dCB0aGUg4oCcbXktbmFtZXNwYWNl4oCdIHNjaGVtYS4gIEZvcg0KPiBp bnRlcm9wZXJhYmlsaXR5LCBpdCB3b3VsZCBiZSBiZXN0IGZvciB0aGUgY2xpZW50cyB0byBzZW5k IHNvbWV0aGluZw0KPiBpbiB0aGUgcmVxdWVzdCAob3IgaGF2ZSBzb21ldGhpbmcgaW4gdGhlaXIg cHJvZmlsZSkgaW5kaWNhdGluZyB0aGF0DQo+IHRoZXnigJlyZSBhYmxlIHRvIHByb2Nlc3MgdGhl IGV4dGVuZGVkIHJlc3BvbnNlLg0KPiANCj4gVGhlIGRpc2N1c3Npb24gYWJvdXQgd2VsbCBiZWhh dmVkIGNsaWVudHMgaXMgYWxyZWFkeSBjYXB0dXJlZCBhYm92ZSwNCj4gYnV0IHRoZSBhbmdsZSBh Ym91dCB0aGUgY2xpZW50IHNpZGUgc2VuZGluZyBjYXBhYmlsaXR5IHN0cmluZ3MgaW4NCj4gaGVs bG8gaXMgbmV3LiBJbiB3aGF0IHNpdHVhdGlvbnMgd291bGQgc3VjaCBhIGNsaWVudCBzaWRlIGNh cGFiaWxpdHkNCj4gZGVjbGFyYXRpb24gYmUgcmVxdWlyZWQ/IFdoYXQgWUFORyBhdWdtZW50cyB3 b3VsZCBvbmx5IGJlIHNlbnQgdG8NCj4gY2xpZW50cyB0aGF0IGhhdmUgZGVjbGFyZWQga25vd2xl ZGdlIG9mIHRoZW0sIGFuZCB3aGljaCBhdWdtZW50cyB3b3VsZA0KPiBhbHdheXMgYmUgc2VudD8N Cg0KVGhlcmUgaXMgbm8gZm9ybWFsIHdheSB0byBzcGVjaWZ5IGhvdyBhIHNlcnZlciB3b3VsZCBy ZWFjdCB0byBhDQpjbGllbnQncyBhZHZlcnRpc2VkIGNhcGFiaWxpdGllcyBpbiA8aGVsbG8+Lg0K DQoNCj4gRm9yIGEgbG9uZ3Rlcm0gc29sdXRpb24sIHBsZWFzZSBjb25zaWRlciBhZGRpbmcgdG8g dGhlIE5FVENPTkYtbmV4dA0KPiB0cmFja2VyOiBodHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13 Zy9uZXRjb25mLW5leHQvaXNzdWVzLiAgV2UgbWlnaHQNCj4gYWxzbyB3YW50IHRvIGNvbnNpZGVy IHRoZSBmZWFzaWJpbGl0eSBvZiBkb2luZyB0aGUgc2FtZSBmb3IgUkVTVENPTkYsDQo+IGFzIGN1 cnJlbnRseSBSRkMgODA0MCBzdGF0ZXMgdGhhdCAyMDQgKE5vIENvbnRlbnQpIOKAnGlzIHJldHVy bmVk4oCdIGZvcg0KPiBQVVQgYW5kIERFTEVURSByZXF1ZXN0cy4NCj4gDQo+IEdvb2QgcG9pbnQu IElzIGl0IHJlYXNvbmFibGUgdG8gYmVsaWV2ZSBtYW55IFJFU1RDT05GIGNsaWVudHMgd291bGQN Cj4gZmFpbCBpZiBhIHNlcnZlciByZXR1cm5lZCBhIGRpZmZlcmVudCAyeHggY29kZSBhbmQgYSBi b2R5IHJhdGhlciB0aGFuDQo+IDIwND8gQW5kIGlmIHNvLCB3b3VsZCBzdWNoIGEgUkVTVENPTkYg Y2xpZW50IGJlIGNvbnNpZGVyZWQgd2VsbA0KPiBiZWhhdmVkPw0KPiANCj4gQm9yaXNsYXYgYWxz byBjb21tZW50ZWQsIGJ1dCBJIGJlbGlldmUgdGhlIHRvcGljcyBhcmUgYWxyZWFkeSBjb3ZlcmVk DQo+IGluIHRoZSBhYm92ZS4NCj4gDQo+IEJlc3QgUmVnYXJkcywNCj4gL2phbg0KPiANCg0KDQoN Ci9tYXJ0aW4NCg== From nobody Fri Sep 11 09:44:01 2020 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 C54573A14DD for ; Fri, 11 Sep 2020 09:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 K8M_xlb_hzBp for ; Fri, 11 Sep 2020 09:43:52 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 3C5023A1494 for ; Fri, 11 Sep 2020 09:43:51 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id d15so6471209lfq.11 for ; Fri, 11 Sep 2020 09:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iZHRcoAj6mxO9EUleHdz8si6IPqTLd99wMcpSdmoNo8=; b=ndAk+Ps83H4oc+txeRXBjdfx0NeKSuXYL1jmc+2KMRF9pVymTIUMFwp65GCx+/3xUx 40ueVWcDKHE6Zo9Ue48zq5SEXylyuv2ljy4UkW8YXaoyd/g3FiATcW9OnRxMFbm5EkAR fLNI5SIKUC/a0XPlSWInTh1Cr0G2Xj7qX5L8ZZ8xWfjv/YoXXVpPo2brTtkKFF9lhKT1 YdpRDIN51dKpQx3ufhKSeztz6x6agZlSoMDBbf+n/+0igFKn/wZfeisXuLK73tBVBtyp dXL/Z4kqSrf4wA2+dFufzSLDn76fqxIXEjkeHZvC8QfZy92KJ1bAYJdj1HbNWMz5covZ IuvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iZHRcoAj6mxO9EUleHdz8si6IPqTLd99wMcpSdmoNo8=; b=IixMGogxQJblVb/GZ9qWua+GUz4sB2DGeiR+pTfaCW6MeyZsL8O1H6iGbXj+0Et5Yi jeePb+uOzbmbFdyp70R2Kk+re+8JRp6NFVGAcvS6USGlLq7HBVQYCYMFGVrW9M5oOZbu fU8IiHu2d52mwbZJkqguijf2QSlu6IZrzXzq3IXmVf5pjzPeq7INaubbZ0mx+44SiUQR 8tzYMwsmy7YDNJrh50ug6UcypY7aJfD4bGVqKw1coloD9XMfk26Is1R37oAQWK9p5Kw8 hb5oKZjRXgdFjlyZM6WI9rQZsJbZL7KtalMXxny1zXNGRli5EUYz/PhXiLbQLy3XQOMv RArA== X-Gm-Message-State: AOAM531WA0O8p9Sye1uWvm00a4PK/Vc6ZYcSFgiyLJkXV8RfX0/YlVHx 1h7rC3ASaEZ9k0UKpchKjA1jTBQKuH0O580TPOUWTA== X-Google-Smtp-Source: ABdhPJxRfD4uGoRHjwqYae9DJLvwGEGbwBDz7wrf+4kvGXwPU/trvPERan7c9NQp2qVbqL14U4juyY2xzDfXJgYf0/w= X-Received: by 2002:a19:e54:: with SMTP id 81mr1105318lfo.178.1599842629226; Fri, 11 Sep 2020 09:43:49 -0700 (PDT) MIME-Version: 1.0 References: <20200910.185258.804843941725520730.id@4668.se> <0CCA567F-5691-4A85-812C-0B95470E5C6C@cisco.com> <20200911.145932.1721440341637757560.id@4668.se> In-Reply-To: <20200911.145932.1721440341637757560.id@4668.se> From: Andy Bierman Date: Fri, 11 Sep 2020 09:43:38 -0700 Message-ID: To: =?UTF-8?Q?Martin_Bj=C3=B6rklund?= Cc: jlindbla@cisco.com, Netconf , bl@ndt-inc.com, Kent Watsen Content-Type: multipart/alternative; boundary="0000000000009caa1005af0c638d" Archived-At: Subject: Re: [netconf] Augmenting rpc-reply X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2020 16:43:59 -0000 --0000000000009caa1005af0c638d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I do not understand why this issue is causing confusion. RFC 6241 specifies the NETCONF protocol messages. RFC 7950 defines the data model that would be considered data returned from the operation. Note that the element is not defined in YANG at all. Note also that sec 4.4 is quite clear about not adding the element if data is returned: The element is sent in messages if no errors or warnings occurred during the processing of an request, *and no data was returned from the operation.* >From the protocol POV it does not matter if the data comes from the rpc-stmt or from an augment-stmt. In the provided example, would be sent and not . Any NETCONF client that claims to support YANG must expect and accept the augment. Andy On Fri, Sep 11, 2020 at 5:59 AM Martin Bj=C3=B6rklund wr= ote: > "Jan Lindblad (jlindbla)" wrote: > > Dear NETCONF WG, > > > > Thank you all for contributing viewpoints. Actually, these answers > > were a surprisingly faithful reflection of the internal discussion we > > had, which prompted us to to take the question to the list. > > > > Since there was clearly no rough consensus on the matter, let me voice > > the counter arguments we had in our internal discussion for those > > arguments that were also mentioned here on the list, in order to see > > if we can distill at least some order in this. > > > > Martin suggested that: > > > > However, RFC 7950 says in section 7.14.4: > > > > If the RPC operation invocation succeeded and no output parameters > > are returned, the contains a single element define= d > > in [RFC6241]. > > > > Is it reasonable to interpret this 7950 language to exclude any and > > all extensions? One could argue that this prescribes a single as > > far as 7950 and 6241 are concerned, but not ruling out extensions. > > > > Which seems to say that if a note is returned, you would get: > > > > > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > abc... > > > > > > This is also consistent with the XSD in RFC 6241. > > > > XSDs always speak about what they require in their targetNamespace, > > and have no "jurisdiction" over other namespaces. Thus XSDs have no > > way of precluding extensions. Is it reasonable therefore to conclude > > then that the NETCONF XSDs cannot be taken as evidence either for or > > against extensions? > > This is not correct. See for example how namespace=3D"##other" is used > in errorInfoType to explicitly allow elements from other namespaces. > > > The problem with this though is that clients probably check for the > > presence of "ok" to verify that an edit-config succeeds, hence I think > > it should be allowed to reply with both and additional elements, > > as examplified above. > > > > It seems reasonable to assume most or all NETCONF servers would send, > > and most clients would look for in the rpc-reply. If anyone has > > a counter example (i.e. can name an implementation that does not), > > please speak up. > > > > Andy suggested that: > > > > I think this change is not backward-compatible because a conformant > > implementation > > might follow the XSD, which clearly shows "ok" as a choice, not mixed > > with the other > > responses. > > > > If XSDs have no way of expressing the absence of tags in foreign > > namespaces, and properly written XML parsing applications generally > > are made to skip over tags and attributes in unknown namespaces, would > > it be reasonable to say that extensions are backwards compatible? This > > is the theoretical part of the question. > > > > The other part is more practical: Assuming the theory is true, would > > the NETCONF WG have the courage to call any implementation that does > > not follow these XML/XSD principles incorrect? > > I think in general we expect well-behaved clients to ignore elements > from other namespaces. But this is a special case since the XSD > explicitly does not allow elements from other namespaces together with > (I think that this is very unfortunate). > > > Kent suggested that: > > > > I don=E2=80=99t think this would be enough, as client-validate of the r= esponse > > might fail unless they know about the =E2=80=9Cmy-namespace=E2=80=9D sc= hema. For > > interoperability, it would be best for the clients to send something > > in the request (or have something in their profile) indicating that > > they=E2=80=99re able to process the extended response. > > > > The discussion about well behaved clients is already captured above, > > but the angle about the client side sending capability strings in > > hello is new. In what situations would such a client side capability > > declaration be required? What YANG augments would only be sent to > > clients that have declared knowledge of them, and which augments would > > always be sent? > > There is no formal way to specify how a server would react to a > client's advertised capabilities in . > > > > For a longterm solution, please consider adding to the NETCONF-next > > tracker: https://github.com/netconf-wg/netconf-next/issues. We might > > also want to consider the feasibility of doing the same for RESTCONF, > > as currently RFC 8040 states that 204 (No Content) =E2=80=9Cis returned= =E2=80=9D for > > PUT and DELETE requests. > > > > Good point. Is it reasonable to believe many RESTCONF clients would > > fail if a server returned a different 2xx code and a body rather than > > 204? And if so, would such a RESTCONF client be considered well > > behaved? > > > > Borislav also commented, but I believe the topics are already covered > > in the above. > > > > Best Regards, > > /jan > > > > > > /martin > --0000000000009caa1005af0c638d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I do not understand why = this issue is causing confusion.
RFC 6241 specifies the NETCONF p= rotocol messages.
RFC 7950 defines the data model that would be c= onsidered
data returned from the operation.

<= div>Note that the <ok/> element is not defined in YANG at all.
<= div>Note also that sec 4.4 is quite clear about not adding the <ok/><= /div>
element if data is returned:

   The <ok> element is sent=
 in <rpc-reply> messages if no errors or
   warnings occurred during the processing of an <rpc> request, an=
d no
   data was returned from the operation.

From= the protocol POV it does not matter if the data comes from the rpc-stmt or=
from an augment-stmt.

In the provided example= , <note> would be sent and not <ok/>.
Any NETCONF cli= ent that claims to support YANG must expect and accept=C2=A0the augment.


Andy


On Fri, Sep 1= 1, 2020 at 5:59 AM Martin Bj=C3=B6rklund <mbj+ietf@4668.se> wrote:
"Jan Lindblad (jlindbla)" <jlindbla@cisco.com> wro= te:
> Dear NETCONF WG,
>
> Thank you all for contributing viewpoints. Actually, these answers
> were a surprisingly faithful reflection of the internal discussion we<= br> > had, which prompted us to to take the question to the list.
>
> Since there was clearly no rough consensus on the matter, let me voice=
> the counter arguments we had in our internal discussion for those
> arguments that were also mentioned here on the list, in order to see > if we can distill at least some order in this.
>
> Martin suggested that:
>
> However, RFC 7950 says in section 7.14.4:
>
>=C2=A0 =C2=A0 If the RPC operation invocation succeeded and no output p= arameters
>=C2=A0 =C2=A0 are returned, the <rpc-reply> contains a single <= ;ok/> element defined
>=C2=A0 =C2=A0 in [RFC6241].
>
> Is it reasonable to interpret this 7950 language to exclude any and > all extensions? One could argue that this prescribes a single <ok/&= gt; as
> far as 7950 and 6241 are concerned, but not ruling out extensions.
>
> Which seems to say that if a note is returned, you would get:
>
>=C2=A0 =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=A0 xmlns=3D= "urn:ietf:params:xml:ns:netconf:base:1.0">
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<note xmlns=3D"my-namespace&q= uot;>abc...</note>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0</rpc-reply>
>
> This is also consistent with the XSD in RFC 6241.
>
> XSDs always speak about what they require in their targetNamespace, > and have no "jurisdiction" over other namespaces. Thus XSDs = have no
> way of precluding extensions. Is it reasonable therefore to conclude > then that the NETCONF XSDs cannot be taken as evidence either for or > against extensions?

This is not correct.=C2=A0 See for example how namespace=3D"##other&qu= ot; is used
in errorInfoType to explicitly allow elements from other namespaces.

> The problem with this though is that clients probably check for the > presence of "ok" to verify that an edit-config succeeds, hen= ce I think
> it should be allowed to reply with both <ok/> and additional ele= ments,
> as examplified above.
>
> It seems reasonable to assume most or all NETCONF servers would send,<= br> > and most clients would look for <ok/> in the rpc-reply. If anyon= e has
> a counter example (i.e. can name an implementation that does not),
> please speak up.
>
> Andy suggested that:
>
> I think this change is not backward-compatible because a conformant > implementation
> might follow the XSD, which clearly shows "ok" as a choice, = not mixed
> with the other
> responses.
>
> If XSDs have no way of expressing the absence of tags in foreign
> namespaces, and properly written XML parsing applications generally > are made to skip over tags and attributes in unknown namespaces, would=
> it be reasonable to say that extensions are backwards compatible? This=
> is the theoretical part of the question.
>
> The other part is more practical: Assuming the theory is true, would > the NETCONF WG have the courage to call any implementation that does > not follow these XML/XSD principles incorrect?

I think in general we expect well-behaved clients to ignore elements
from other namespaces.=C2=A0 But this is a special case since the XSD
explicitly does not allow elements from other namespaces together with
<ok/>=C2=A0 (I think that this is very unfortunate).

> Kent suggested that:
>
> I don=E2=80=99t think this would be enough, as client-validate of the = response
> might fail unless they know about the =E2=80=9Cmy-namespace=E2=80=9D s= chema.=C2=A0 For
> interoperability, it would be best for the clients to send something > in the request (or have something in their profile) indicating that > they=E2=80=99re able to process the extended response.
>
> The discussion about well behaved clients is already captured above, > but the angle about the client side sending capability strings in
> hello is new. In what situations would such a client side capability > declaration be required? What YANG augments would only be sent to
> clients that have declared knowledge of them, and which augments would=
> always be sent?

There is no formal way to specify how a server would react to a
client's advertised capabilities in <hello>.


> For a longterm solution, please consider adding to the NETCONF-next > tracker: https://github.com/netconf-wg/netconf= -next/issues.=C2=A0 We might
> also want to consider the feasibility of doing the same for RESTCONF,<= br> > as currently RFC 8040 states that 204 (No Content) =E2=80=9Cis returne= d=E2=80=9D for
> PUT and DELETE requests.
>
> Good point. Is it reasonable to believe many RESTCONF clients would > fail if a server returned a different 2xx code and a body rather than<= br> > 204? And if so, would such a RESTCONF client be considered well
> behaved?
>
> Borislav also commented, but I believe the topics are already covered<= br> > in the above.
>
> Best Regards,
> /jan
>



/martin
--0000000000009caa1005af0c638d-- From nobody Mon Sep 21 15:13:32 2020 Return-Path: <01000174b2ba9c57-cbc0d353-8d30-4885-8769-1ea869b4d0be-000000@amazonses.watsen.net> 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 A3BF93A0B5B for ; Mon, 21 Sep 2020 15:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 Gn0et9Xd5TDi for ; Mon, 21 Sep 2020 15:13:29 -0700 (PDT) Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F67B3A0B55 for ; Mon, 21 Sep 2020 15:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1600726408; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=LkZhsHlXVt3JIu6PzFBrJCH1VQj56eYgT73zeRy2+gk=; b=DNXsilv8R0n5wTzFHXroznAeFnwtPH72dr35biummH1z/MSkHGd4YngVbZy7n8Q9 fbjMGGk+4CEhL6JxRAXr+FQf4QPK2EtU+mjegH68JTkLJQLKrCZzQsYJfSc2Pb/0ZQP NdOGBR6ClnYENRe8MpNdBQS1KTF8LBG/p0m45WIc= From: Kent Watsen Message-ID: <01000174b2ba9c57-cbc0d353-8d30-4885-8769-1ea869b4d0be-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FD75646A-1C22-47B4-9FDF-ECA9666BEAEE" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 21 Sep 2020 22:13:28 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: Andy Bierman References: <01000173c0b07b33-ad0b793a-7afc-4b39-95f8-2f50574d57bb-000000@us-east-1.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.09.21-54.240.48.94 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 22:13:32 -0000 --Apple-Mail=_FD75646A-1C22-47B4-9FDF-ECA9666BEAEE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Andy, Does Tianran=E2=80=99s response resolve your "I do not understand why = the client needs this feature=E2=80=9D comment? As it currently = stands, your comment reads like an objection. The comment regarding if this work should be in its own RFC or as a Bis = is a process-question to chairs can ask the WG after determining support = for moving the work forward. Kent and Mahesh, as NETCONF chairs. > On Aug 10, 2020, at 11:28 PM, Tianran Zhou = wrote: >=20 > Hi Andy, > =20 > Thanks for your review. > Basically your understanding is correct. > The background is about the distributed notif, which the global = subscription will be decomposed to several component subscriptions. > And the client need to compose the data from multiple publishers. It = need to know if all the pieces of one data are received. > Current solution depends on ietf-netconf-notification-messages. I just = found it=E2=80=99s expired! > I would like to discuss with authors about the plan on that draft. = Fortunately you are one coauthor. Could you please help on the answer? > Otherwise, we can seek other way. > =20 > Best, > Tianran > =20 > From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy = Bierman > Sent: Tuesday, August 11, 2020 3:39 AM > To: Kent Watsen > Cc: netconf@ietf.org > Subject: Re: [netconf] Adoption-suitability for = draft-unyte-netconf-distributed-notif > =20 > Hi, > =20 > I am trying to understand what problem this draft attempts to solve. > It appears from the solution proposal is that the problem to be solved = is > the lack of message generator identifiers associated with configured = subscriptions. > These identifiers could presumably help a client understand some = implementation details > related to a subscription. The solution seems to rely on the = message-generator-id > field in the notification message (which does not exist in current = RFCs). > =20 > I do not understand why the client needs this feature. > =20 > =20 > Andy > =20 > =20 > On Wed, Aug 5, 2020 at 3:14 PM Kent Watsen > wrote: > NETCONF WG, >=20 > Per the previous email sent moments ago, the chairs would like to = solicit input on the following draft: > =20 > Title: Subscription to Distributed Notifications > Link: = https://tools.ietf.org/html/draft-unyte-netconf-distributed-notif = > Abstract: >=20 > This documents describes extensions to the YANG notifications > subscription to allow metrics being published directly from > processors on line cards to target receivers, while subscription = is > still maintained at the route processor in a distributed = forwarding > system. > =20 >=20 > In particular, please discuss adoption-suitability as it regards to = the following questions: > =20 > 1) is the problem important for the NETCONF WG to solve? > 2) is the draft a suitable basis for the work? >=20 >=20 > PS: this message is itself not an adoption poll, but rather an attempt = to gauge interest/support for a potential future adoption poll. >=20 > NETCONF Chairs > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf = --Apple-Mail=_FD75646A-1C22-47B4-9FDF-ECA9666BEAEE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Andy,

Does = Tianran=E2=80=99s response resolve your "I do not understand why the = client needs this feature=E2=80=9D comment?   As it currently = stands, your comment reads like an objection.

The comment regarding if this work = should be in its own RFC or as a Bis is a process-question to chairs can = ask the WG after determining support for moving the work = forward.

Kent = and Mahesh, as NETCONF chairs.



On Aug = 10, 2020, at 11:28 PM, Tianran Zhou <zhoutianran@huawei.com> wrote:

Hi Andy,

 

Thanks for your review.

Basically your understanding is correct.

The background is about the distributed notif, = which the global subscription will be decomposed to several component = subscriptions.

And the client need to compose the data from = multiple publishers. It need to know if all the pieces of one data are = received.

Current solution depends on = ietf-netconf-notification-messages. I just found it=E2=80=99s = expired!

I would like to discuss with authors about the plan = on that draft. Fortunately you are one coauthor. Could you please help = on the answer?

Otherwise, we can seek other way.

 

Best,

Tianran

 

From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Tuesday, August 11, 2020 3:39 AM
To: Kent Watsen <kent+ietf@watsen.net>
Cc: netconf@ietf.org
Subject: Re: [netconf] Adoption-suitability for = draft-unyte-netconf-distributed-notif

 

Hi,

 

I am trying to understand what = problem this draft attempts to solve.

It appears from the solution = proposal is that the problem to be solved is

the lack of message generator = identifiers associated with configured subscriptions.

These identifiers could = presumably help a client understand some implementation details

related to a = subscription.  The solution seems to rely on the = message-generator-id

field in the notification message = (which does not exist in current RFCs).

 

I do not understand why the = client needs this feature.

 

 

Andy

 

 

On Wed, Aug 5, 2020 at 3:14 PM = Kent Watsen <kent+ietf@watsen.net> wrote:

NETCONF= WG,

Per the previous email sent moments ago, the chairs would like to = solicit input on the following draft:

 

  =  Title: Subscription to Distributed Notifications

  =  Link: = https://tools.ietf.org/html/draft-unyte-netconf-distributed-notif
   Abstract:

  =     This documents describes extensions to the YANG = notifications

  =     subscription to allow metrics being published directly = from

  =     processors on line cards to target receivers, while = subscription is

  =     still maintained at the route processor in a distributed = forwarding

  =     system.

 


In particular, please discuss adoption-suitability as it regards to the = following questions:

 

  =   1) is the problem important for the NETCONF WG to solve?
    2) is the draft a suitable basis for the work?



PS: this message is itself not an adoption poll, but rather an attempt = to gauge interest/support for a potential future adoption poll.

NETCONF Chairs

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


= --Apple-Mail=_FD75646A-1C22-47B4-9FDF-ECA9666BEAEE-- From nobody Mon Sep 21 15:31:21 2020 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 C117B3A0BEC for ; Mon, 21 Sep 2020 15:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 MRbQhY-e-dnz for ; Mon, 21 Sep 2020 15:31:18 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 E5D8A3A0B41 for ; Mon, 21 Sep 2020 15:31:17 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id y2so15812321lfy.10 for ; Mon, 21 Sep 2020 15:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZUriNswak3paCGfWsp6CCXoxXlY9+9oQklrWLVBldAE=; b=yvJauXKCQf/znL0+R/pPj9OBiqT04OwRWBHH+KScBuchk+VXMe3uWQpthllmlifTo/ FHgjDg8mar49LQ3P4ejXsutDy0owhdQwmuNohUfqBOExB3hJCDr1Nvx2uRVucEYlmjyE ZzC4u3BAG/dAimsiB64VwKXz1RvN807bzlsTpy9cWUjA5xgcwdjzWEBGTr//cFHJ8TnE k0sB5A1AOzFe5FeRyRbKqB/3UIWl8UDgnhzzHMoj4RTLJIkw+KLUOB9i91F0Mb67OzLJ VMMfGkDDvphGgxYBi82GIz4gvLFe3FevNrmgfrVRYHkj4Oj93ZkePZYGJM/rfOAl5otv aYwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZUriNswak3paCGfWsp6CCXoxXlY9+9oQklrWLVBldAE=; b=jQAVQehyXjprS0DmTM5jQDmVdzezALb9Fw3pGScHLz3chADKtdEHHnzejtSaYEh8d+ apRf7SKz2Sw02KXLysZSDD4IcrOZXc2TxYxOQe2I53U6IlAg7eK7asMvoupa6+3D+522 Rq2UG1NO3tFtQezeDwwqUIxlhvV/rFhVV2ECF5Wv6BDKgKqea9xmkWWYn8TcfZK0EK4b WxaCuUrY07wBVzfulK7o4az1t7Z4vZZnD/uxlRDGKVhBPTcORLdQwGw+fYMd3+4+84b7 WD0bDqIqSGAPHE093eSmJwJy+PqPgR7f+aykZ+p8LR7vqxPa2hyPOJKkDdt4IF7ESpIA eF3g== X-Gm-Message-State: AOAM5306ZLQgWYyMSRDxWuxFj83a2hoJx2TjnsxfuOsdUriuXZvyxI/E Whm1u0wu9JxttR/+9SW/yQmjsR6kp5MmfAXi9Jf9TuFkXmhC1w== X-Google-Smtp-Source: ABdhPJyW8e61EevYU9SpChnfGc6lPSTDyq5lvoHG8x1XU9fdIJe/0I+P8a9JN5itjIuZbXLwXxts/e35NguN3Ke07Y0= X-Received: by 2002:a19:6818:: with SMTP id d24mr594418lfc.107.1600727475952; Mon, 21 Sep 2020 15:31:15 -0700 (PDT) MIME-Version: 1.0 References: <01000173c0b07b33-ad0b793a-7afc-4b39-95f8-2f50574d57bb-000000@us-east-1.amazonses.com> <01000174b2ba9c57-cbc0d353-8d30-4885-8769-1ea869b4d0be-000000@email.amazonses.com> In-Reply-To: <01000174b2ba9c57-cbc0d353-8d30-4885-8769-1ea869b4d0be-000000@email.amazonses.com> From: Andy Bierman Date: Mon, 21 Sep 2020 15:31:05 -0700 Message-ID: To: Kent Watsen Cc: "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000963afe05afda689f" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 22:31:20 -0000 --000000000000963afe05afda689f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 21, 2020 at 3:13 PM Kent Watsen wrote: > Hi Andy, > > Does Tianran=E2=80=99s response resolve your "I do not understand why the= client > needs this feature=E2=80=9D comment? As it currently stands, your comme= nt reads > like an objection. > > The comment regarding if this work should be in its own RFC or as a Bis i= s > a process-question to chairs can ask the WG after determining support for > moving the work forward. > > Kent and Mahesh, as NETCONF chairs. > > > The overall approach to the binary push features seems a bit incoherent to me. I don't see much value in this draft, but no harm either so I do not have an objection to adoption. Perhaps there is some debugging value here but since the architecture really does not define message generators as sub-components of a configured subscription, a client cannot expect any sort of consistent implementation of this field. Andy > On Aug 10, 2020, at 11:28 PM, Tianran Zhou wrote= : > > Hi Andy, > > > > Thanks for your review. > > Basically your understanding is correct. > > The background is about the distributed notif, which the global > subscription will be decomposed to several component subscriptions. > > And the client need to compose the data from multiple publishers. It need > to know if all the pieces of one data are received. > > Current solution depends on ietf-netconf-notification-messages. I just > found it=E2=80=99s expired! > > I would like to discuss with authors about the plan on that draft. > Fortunately you are one coauthor. Could you please help on the answer? > > Otherwise, we can seek other way. > > > > Best, > > Tianran > > > > *From:* netconf [mailto:netconf-bounces@ietf.org > ] *On Behalf Of *Andy Bierman > *Sent:* Tuesday, August 11, 2020 3:39 AM > *To:* Kent Watsen > *Cc:* netconf@ietf.org > *Subject:* Re: [netconf] Adoption-suitability for > draft-unyte-netconf-distributed-notif > > > > Hi, > > > > I am trying to understand what problem this draft attempts to solve. > > It appears from the solution proposal is that the problem to be solved is > > the lack of message generator identifiers associated with configured > subscriptions. > > These identifiers could presumably help a client understand some > implementation details > > related to a subscription. The solution seems to rely on the > message-generator-id > > field in the notification message (which does not exist in current RFCs). > > > > I do not understand why the client needs this feature. > > > > > > Andy > > > > > > On Wed, Aug 5, 2020 at 3:14 PM Kent Watsen wrote: > > NETCONF WG, > > Per the previous email sent moments ago, the chairs would like to solicit > input on the following draft: > > > > Title: Subscription to Distributed Notifications > > Link: https://tools.ietf.org/html/draft-unyte-netconf-distributed-noti= f > Abstract: > > This documents describes extensions to the YANG notifications > > subscription to allow metrics being published directly from > > processors on line cards to target receivers, while subscription is > > still maintained at the route processor in a distributed forwarding > > system. > > > > > In particular, please discuss adoption-suitability as it regards to the > following questions: > > > > 1) is the problem important for the NETCONF WG to solve? > 2) is the draft a suitable basis for the work? > > > > PS: this message is itself not an adoption poll, but rather an attempt to > gauge interest/support for a potential future adoption poll. > > NETCONF Chairs > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > --000000000000963afe05afda689f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Sep 21, 2020 at 3:13 PM Kent = Watsen <kent+ietf@watsen.net> wrote:
Hi Andy,

Does Ti= anran=E2=80=99s response resolve your "I do not understand why the cli= ent needs this feature=E2=80=9D comment? =C2=A0 As it currently stands, you= r comment reads like an objection.

The comment reg= arding if this work should be in its own RFC or as a Bis is a process-quest= ion to chairs can ask the WG after determining support for moving the work = forward.

Kent and Mahesh, as NETCONF chairs.
=








Hi Andy,

=C2=A0

Thanks for your review.

Basically your understanding is correct.

The background is a= bout the distributed notif, which the global subscription will be decompose= d to several component subscriptions.

And the client need= to compose the data from multiple publishers. It need to know if all the p= ieces of one data are received.

Current solution depends on ietf-netconf-notification-messages.= I just found it=E2=80=99s expired!

I would like to discuss with authors about the plan on that= draft. Fortunately you are one coauthor. Could you please help on the answ= er?

Otherwise, we ca= n seek other way.

=C2=A0

Best,=

Tianran<= /p>

=C2=A0

From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Tuesday, August 11, 2020 3:39 AM
To: Kent Watsen <kent+ietf@watsen.net>
Cc: netconf@ie= tf.org
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-= distributed-notif

=C2= =A0

Hi,

=C2=A0

I am trying to understand what problem this dra= ft attempts to solve.

It appears from the solution proposal is that t= he problem to be solved is

the lack of message generator identifiers assoc= iated with configured subscriptions.

These identifiers could presumably help a clien= t understand some implementation details

related=C2=A0to a subscription.=C2=A0 The solut= ion seems to rely on the message-generator-id

field in the notification message (which does n= ot exist in current RFCs).

=C2=A0

I do not understand why the client needs this f= eature.

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

On Wed, Aug 5, 2020 at 3:14 PM Kent Watsen <= kent+ietf@watse= n.net> wrote:

NETCONF WG,

Per the previous email sent moments ago, the chairs would like to solicit i= nput on the following draft:

=C2=A0

=C2=A0 =C2=A0Title:=C2=A0Subscription to = Distributed Notifications

=C2=A0 =C2= =A0Link: https://tools.ietf.org/html/draft-unyte-netconf-distributed-notif
=C2=A0 =C2=A0Abstract:

=C2=A0 =C2=A0 =C2=A0 This documents descr= ibes extensions to the YANG notifications

=C2=A0 =C2=A0 =C2=A0 subscription to allo= w metrics being published directly from

=C2=A0 =C2=A0 =C2=A0 processors on line c= ards to target receivers, while subscription is

=C2=A0 =C2=A0 =C2=A0 still maintained at = the route processor in a distributed forwarding

=C2=A0 =C2=A0 =C2=A0 system.

=C2=A0


In particular, please discuss adoption-suitability as it regards to the fol= lowing questions:

=C2=A0

=C2=A0 =C2=A0 1) is the problem important= for the NETCONF WG to solve?
=C2=A0 =C2=A0 2) is the draft a suitable basis for the work?<= /span>



PS: this message is itself not an adoption poll, but rather an attempt to g= auge interest/support for a potential future adoption poll.

NETCONF Chairs

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


--000000000000963afe05afda689f-- From nobody Mon Sep 21 15:55:04 2020 Return-Path: <01000174b2e0a349-52337b7b-81c3-4c56-a58b-36c95d68340f-000000@amazonses.watsen.net> 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 E21483A0C94 for ; Mon, 21 Sep 2020 15:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 nrwOQ5wvHL8l for ; Mon, 21 Sep 2020 15:55:01 -0700 (PDT) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3F63A0C81 for ; Mon, 21 Sep 2020 15:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1600728900; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=ncJ8f7RGuDyU9NuhcZhGbZZFw8UY3PLLSk1ssziw1Ew=; b=hIQ7PlewOdlEjAg7QYpQ/xvcGv/gVG2Xi9qfD9AoEoj1fUVs78Sku7j0bI0iBopn QFtBO4jn3twKeKnmnkLQTr/ZXtgZ/++gxBWDgJWC54GMm7i3MiV9A611krCpDarISCg mfgajy7MIX/cZc7nowlf1+w+2ZlbH6J/1swJwung= From: Kent Watsen Message-ID: <01000174b2e0a349-52337b7b-81c3-4c56-a58b-36c95d68340f-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_228CBF47-D525-46DF-B917-DB5D06AE3B2D" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 21 Sep 2020 22:55:00 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: Andy Bierman References: <01000173c0b07b33-ad0b793a-7afc-4b39-95f8-2f50574d57bb-000000@us-east-1.amazonses.com> <01000174b2ba9c57-cbc0d353-8d30-4885-8769-1ea869b4d0be-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.09.21-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2020 22:55:03 -0000 --Apple-Mail=_228CBF47-D525-46DF-B917-DB5D06AE3B2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [As an individual contributor] > The overall approach to the binary push features seems a bit = incoherent to me. > I don't see much value in this draft, but no harm either so I do not = have an objection > to adoption. Perhaps there is some debugging value here but since the = architecture > really does not define message generators as sub-components of a = configured subscription, > a client cannot expect any sort of consistent implementation of this = field. Good point. If I understand you correctly, what seems to be missing is = an ability for the client to determine which generator-id is used by = which publisher (e.g., line card). The solution enables the client to = partition notifications coming from different publishers, but that is = it. What value does this have to the client, I don=E2=80=99t know. =20 Answering myself here, perhaps it enables two servers on the same IP = address to send to the same receiver, as then the receiver doesn=E2=80=99t= solely rely on source-IP address (assuming unauthenticated push) to = designate the publisher? Can the authors help resolve the value-proposition question here? K. --Apple-Mail=_228CBF47-D525-46DF-B917-DB5D06AE3B2D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
[As an individual contributor]

The overall approach to the binary push features = seems a bit incoherent to me.
I don't see much = value in this draft, but no harm either so I do not have an = objection
to adoption.  Perhaps there is some = debugging value here but since the architecture
really does not define message generators as sub-components = of a configured subscription,
a client cannot = expect any sort of consistent implementation of this = field.

Good = point. If I understand you correctly, what seems to be missing is an ability for the client to = determine which generator-id is used by which publisher (e.g., line = card).  The solution enables the client to partition notifications = coming from different publishers, but that is it.  What value does this have to = the client, I don=E2=80=99t know.  

Answering myself here, perhaps it enables two servers on the = same IP address to send to the same receiver, as then the receiver = doesn=E2=80=99t solely rely on source-IP address (assuming = unauthenticated push) to designate the publisher?

Can the authors help = resolve the value-proposition question here?

K.


= --Apple-Mail=_228CBF47-D525-46DF-B917-DB5D06AE3B2D-- From nobody Mon Sep 21 19:04:41 2020 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 E43123A10DA for ; Mon, 21 Sep 2020 19:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 X0HwoyC5IGqY for ; Mon, 21 Sep 2020 19:04:38 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 061A53A10D8 for ; Mon, 21 Sep 2020 19:04:38 -0700 (PDT) Received: from lhreml704-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 0C5072209028AB3B628D for ; Tue, 22 Sep 2020 03:04:36 +0100 (IST) Received: from nkgeml704-chm.china.huawei.com (10.98.57.158) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Tue, 22 Sep 2020 03:04:35 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml704-chm.china.huawei.com (10.98.57.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 22 Sep 2020 10:04:33 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Tue, 22 Sep 2020 10:04:33 +0800 From: Tianran Zhou To: Kent Watsen , Andy Bierman CC: "netconf@ietf.org" Thread-Topic: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif Thread-Index: AQHWa3XT/yp90Vv9H0i3R7lOe+hPQ6kxPqwAgAEGkBCAQSaZAIAABOyAgAAGrgCAALMIwA== Date: Tue, 22 Sep 2020 02:04:32 +0000 Message-ID: <5c058aa40cbf4141b32b19bd53514415@huawei.com> References: <01000173c0b07b33-ad0b793a-7afc-4b39-95f8-2f50574d57bb-000000@us-east-1.amazonses.com> <01000174b2ba9c57-cbc0d353-8d30-4885-8769-1ea869b4d0be-000000@email.amazonses.com> <01000174b2e0a349-52337b7b-81c3-4c56-a58b-36c95d68340f-000000@email.amazonses.com> In-Reply-To: <01000174b2e0a349-52337b7b-81c3-4c56-a58b-36c95d68340f-000000@email.amazonses.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.128] Content-Type: multipart/alternative; boundary="_000_5c058aa40cbf4141b32b19bd53514415huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2020 02:04:40 -0000 --_000_5c058aa40cbf4141b32b19bd53514415huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEFuZHkgZm9yIHlvdXIgb3Bpbmlvbi4gQW5kIHRoYW5rIEtlbnQgZm9yIHlvdXIgZXhw YW5zaW9uIGFuZCBmdXJ0aGVyIHF1ZXN0aW9uLg0KVGhlIGdvYWwgaXMgdG8gYWxsb3cgdGhlIGNs aWVudCB0byBrbm93IGlmIGl0IGhhcyByZWNlaXZlZCBhbGwgdGhlIGRhdGEgcGllY2VzLiBGdXJ0 aGVybW9yZSwgdGhlIGNsaWVudCBrbm93IHdoaWNoIHB1Ymxpc2hlciBmYWlsZWQgdG8gc2VuZCBk YXRhLiBUaGVuIGl0IGRlcGVuZCBvbiB0aGUgY2xpZW50IHRvIGRvIHRoZSBhY3Rpb24sIGUuZy4s IGlnbm9yZSwgcmVxdWlyZSB0aGUgZGF0YSBvbmUgbW9yZSwg4oCmDQpXZSBqdXN0IHVzZSB0aGUg Z2VuZXJhdG9yLWlkIHRvIGluZGljYXRlIHRoZSBwdWJsaXNoZXIsIGFzIHdlIGZpbmQgaXQgaW4g aWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdlcywgYW5kIGl04oCZcyB2ZXJ5IGNvbnZl bmllbnQgZm9yIHRoaXMgdXNhZ2UuDQpPbmUgdXNlIGNhc2UgaXMgZXhhY3RseSBhcyBLZW50IG1l bnRpb25lZCDigJxBbnN3ZXJpbmcgbXlzZWxmIGhlcmUsIHBlcmhhcHMgaXQgZW5hYmxlcyB0d28g c2VydmVycyBvbiB0aGUgc2FtZSBJUCBhZGRyZXNzIHRvIHNlbmQgdG8gdGhlIHNhbWUgcmVjZWl2 ZXIsIGFzIHRoZW4gdGhlIHJlY2VpdmVyIGRvZXNu4oCZdCBzb2xlbHkgcmVseSBvbiBzb3VyY2Ut SVAgYWRkcmVzcyAoYXNzdW1pbmcgdW5hdXRoZW50aWNhdGVkIHB1c2gpIHRvIGRlc2lnbmF0ZSB0 aGUgcHVibGlzaGVy4oCdLg0KSXTigJlzIGFsc28gT0sgZm9yIHVzIHRvIHVzZSBhbm90aGVyIGlu ZGljYXRvciBpZiB0aGUgZ2VuZXJhdG9yLWlkIGlzIG5vdCBmZWFzaWJsZS4NCuKAnHdoYXQgc2Vl bXMgdG8gYmUgbWlzc2luZyBpcyBhbiBhYmlsaXR5IGZvciB0aGUgY2xpZW50IHRvIGRldGVybWlu ZSB3aGljaCBnZW5lcmF0b3ItaWQgaXMgdXNlZCBieSB3aGljaCBwdWJsaXNoZXIgKGUuZy4sIGxp bmUgY2FyZCkuIOKAnQ0KSWYgbmVjZXNzYXJ5LCBtYXliZSB3ZSBjYW4gZXh0ZW5kIHRoaXMgbWFw cGluZyBpbiBzb21lIGluaXRpYWwgZXhjaGFuZ2VzLiBUbyBiZSBjbGVhciwgaG93IGRvIHlvdSB3 YW50IHRvIG5hbWUgdGhlIHB1Ymxpc2hlcj8NCg0KVGhhbmtzLA0KVGlhbnJhbg0KDQpGcm9tOiBu ZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS2Vu dCBXYXRzZW4NClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAyMiwgMjAyMCA2OjU1IEFNDQpUbzog QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+DQpDYzogbmV0Y29uZkBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtuZXRjb25mXSBBZG9wdGlvbi1zdWl0YWJpbGl0eSBmb3IgZHJhZnQtdW55 dGUtbmV0Y29uZi1kaXN0cmlidXRlZC1ub3RpZg0KDQpbQXMgYW4gaW5kaXZpZHVhbCBjb250cmli dXRvcl0NCg0KVGhlIG92ZXJhbGwgYXBwcm9hY2ggdG8gdGhlIGJpbmFyeSBwdXNoIGZlYXR1cmVz IHNlZW1zIGEgYml0IGluY29oZXJlbnQgdG8gbWUuDQpJIGRvbid0IHNlZSBtdWNoIHZhbHVlIGlu IHRoaXMgZHJhZnQsIGJ1dCBubyBoYXJtIGVpdGhlciBzbyBJIGRvIG5vdCBoYXZlIGFuIG9iamVj dGlvbg0KdG8gYWRvcHRpb24uICBQZXJoYXBzIHRoZXJlIGlzIHNvbWUgZGVidWdnaW5nIHZhbHVl IGhlcmUgYnV0IHNpbmNlIHRoZSBhcmNoaXRlY3R1cmUNCnJlYWxseSBkb2VzIG5vdCBkZWZpbmUg bWVzc2FnZSBnZW5lcmF0b3JzIGFzIHN1Yi1jb21wb25lbnRzIG9mIGEgY29uZmlndXJlZCBzdWJz Y3JpcHRpb24sDQphIGNsaWVudCBjYW5ub3QgZXhwZWN0IGFueSBzb3J0IG9mIGNvbnNpc3RlbnQg aW1wbGVtZW50YXRpb24gb2YgdGhpcyBmaWVsZC4NCg0KR29vZCBwb2ludC4gSWYgSSB1bmRlcnN0 YW5kIHlvdSBjb3JyZWN0bHksIHdoYXQgc2VlbXMgdG8gYmUgbWlzc2luZyBpcyBhbiBhYmlsaXR5 IGZvciB0aGUgY2xpZW50IHRvIGRldGVybWluZSB3aGljaCBnZW5lcmF0b3ItaWQgaXMgdXNlZCBi eSB3aGljaCBwdWJsaXNoZXIgKGUuZy4sIGxpbmUgY2FyZCkuICBUaGUgc29sdXRpb24gZW5hYmxl cyB0aGUgY2xpZW50IHRvIHBhcnRpdGlvbiBub3RpZmljYXRpb25zIGNvbWluZyBmcm9tIGRpZmZl cmVudCBwdWJsaXNoZXJzLCBidXQgdGhhdCBpcyBpdC4gIFdoYXQgdmFsdWUgZG9lcyB0aGlzIGhh dmUgdG8gdGhlIGNsaWVudCwgSSBkb27igJl0IGtub3cuDQoNCkFuc3dlcmluZyBteXNlbGYgaGVy ZSwgcGVyaGFwcyBpdCBlbmFibGVzIHR3byBzZXJ2ZXJzIG9uIHRoZSBzYW1lIElQIGFkZHJlc3Mg dG8gc2VuZCB0byB0aGUgc2FtZSByZWNlaXZlciwgYXMgdGhlbiB0aGUgcmVjZWl2ZXIgZG9lc27i gJl0IHNvbGVseSByZWx5IG9uIHNvdXJjZS1JUCBhZGRyZXNzIChhc3N1bWluZyB1bmF1dGhlbnRp Y2F0ZWQgcHVzaCkgdG8gZGVzaWduYXRlIHRoZSBwdWJsaXNoZXI/DQoNCg0KQ2FuIHRoZSBhdXRo b3JzIGhlbHAgcmVzb2x2ZSB0aGUgdmFsdWUtcHJvcG9zaXRpb24gcXVlc3Rpb24gaGVyZT8NCg0K Sy4NCg0KDQo= --_000_5c058aa40cbf4141b32b19bd53514415huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEg MSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6 MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovk vZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+VGhhbmtzIEFuZHkgZm9yIHlvdXIgb3Bpbmlvbi4gQW5kIHRoYW5rIEtlbnQgZm9yIHlv dXIgZXhwYW5zaW9uIGFuZCBmdXJ0aGVyIHF1ZXN0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUg Z29hbCBpcyB0byBhbGxvdyB0aGUgY2xpZW50IHRvIGtub3cgaWYgaXQgaGFzIHJlY2VpdmVkIGFs bCB0aGUgZGF0YSBwaWVjZXMuIEZ1cnRoZXJtb3JlLCB0aGUgY2xpZW50IGtub3cgd2hpY2ggcHVi bGlzaGVyIGZhaWxlZCB0byBzZW5kIGRhdGEuIFRoZW4gaXQgZGVwZW5kDQogb24gdGhlIGNsaWVu dCB0byBkbyB0aGUgYWN0aW9uLCBlLmcuLCBpZ25vcmUsIHJlcXVpcmUgdGhlIGRhdGEgb25lIG1v cmUsIOKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XZSBqdXN0IHVzZSB0aGUgZ2VuZXJhdG9yLWlkIHRv IGluZGljYXRlIHRoZSBwdWJsaXNoZXIsIGFzIHdlIGZpbmQgaXQgaW48L3NwYW4+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1tZXNzYWdl cywgYW5kIGl04oCZcyB2ZXJ5IGNvbnZlbmllbnQgZm9yIHRoaXMgdXNhZ2UuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPk9uZSB1c2UgY2FzZSBpcyBleGFjdGx5IGFzIEtlbnQgbWVudGlvbmVkIOKAnEFuc3dl cmluZyBteXNlbGYgaGVyZSwgcGVyaGFwcyBpdCBlbmFibGVzIHR3byBzZXJ2ZXJzIG9uIHRoZSBz YW1lIElQIGFkZHJlc3MgdG8gc2VuZCB0byB0aGUgc2FtZSByZWNlaXZlciwgYXMgdGhlbg0KIHRo ZSByZWNlaXZlciBkb2VzbuKAmXQgc29sZWx5IHJlbHkgb24gc291cmNlLUlQIGFkZHJlc3MgKGFz c3VtaW5nIHVuYXV0aGVudGljYXRlZCBwdXNoKSB0byBkZXNpZ25hdGUgdGhlIHB1Ymxpc2hlcuKA nS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+SXTigJlzIGFsc28gT0sgZm9yIHVzIHRvIHVzZSBhbm90aGVy IGluZGljYXRvciBpZiB0aGUgZ2VuZXJhdG9yLWlkIGlzIG5vdCBmZWFzaWJsZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPuKAnHdoYXQgc2VlbXMgdG8gYmUgbWlzc2luZyBp cyBhbiBhYmlsaXR5IGZvciB0aGUgY2xpZW50IHRvIGRldGVybWluZSB3aGljaCBnZW5lcmF0b3It aWQgaXMgdXNlZCBieSB3aGljaCBwdWJsaXNoZXIgKGUuZy4sIGxpbmUgY2FyZCkuIOKAnTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5JZiBuZWNlc3NhcnksIG1heWJlIHdlIGNhbiBleHRlbmQgdGhpcyBtYXBw aW5nIGluIHNvbWUgaW5pdGlhbCBleGNoYW5nZXMuIFRvIGJlIGNsZWFyLCBob3cgZG8geW91IHdh bnQgdG8gbmFtZSB0aGUgcHVibGlzaGVyPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRpYW5yYW48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IG5ldGNvbmYgW21haWx0bzpuZXRjb25m LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPktlbnQgV2F0c2VuPGJyPg0K PGI+U2VudDo8L2I+IFR1ZXNkYXksIFNlcHRlbWJlciAyMiwgMjAyMCA2OjU1IEFNPGJyPg0KPGI+ VG86PC9iPiBBbmR5IEJpZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZndDs8YnI+DQo8Yj5D Yzo8L2I+IG5ldGNvbmZAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRjb25m XSBBZG9wdGlvbi1zdWl0YWJpbGl0eSBmb3IgZHJhZnQtdW55dGUtbmV0Y29uZi1kaXN0cmlidXRl ZC1ub3RpZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5bQXMgYW4gaW5kaXZpZHVhbCBjb250cmlidXRvcl08bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+VGhlIG92ZXJhbGwgYXBwcm9hY2ggdG8gdGhlIGJpbmFyeSBwdXNoIGZlYXR1cmVzIHNlZW1z IGEgYml0IGluY29oZXJlbnQgdG8gbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgZG9uJ3Qgc2Vl IG11Y2ggdmFsdWUgaW4gdGhpcyBkcmFmdCwgYnV0IG5vIGhhcm0gZWl0aGVyIHNvIEkgZG8gbm90 IGhhdmUgYW4gb2JqZWN0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPnRvIGFkb3B0aW9uLiZuYnNw OyBQZXJoYXBzIHRoZXJlIGlzIHNvbWUgZGVidWdnaW5nIHZhbHVlIGhlcmUgYnV0IHNpbmNlIHRo ZSBhcmNoaXRlY3R1cmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+cmVhbGx5IGRvZXMgbm90IGRlZmlu ZSBtZXNzYWdlIGdlbmVyYXRvcnMgYXMgc3ViLWNvbXBvbmVudHMgb2YgYSBjb25maWd1cmVkIHN1 YnNjcmlwdGlvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+YSBjbGllbnQgY2Fubm90IGV4cGVjdCBh bnkgc29ydCBvZiBjb25zaXN0ZW50IGltcGxlbWVudGF0aW9uIG9mIHRoaXMgZmllbGQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R29vZCBwb2ludC4gSWYgSSB1bmRlcnN0YW5k IHlvdSBjb3JyZWN0bHksIHc8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPmhhdCBzZWVtcyB0byBi ZSBtaXNzaW5nIGlzIGFuIGFiaWxpdHkgZm9yIHRoZSBjbGllbnQgdG8gZGV0ZXJtaW5lIHdoaWNo IGdlbmVyYXRvci1pZCBpcyB1c2VkIGJ5IHdoaWNoIHB1Ymxpc2hlciAoZS5nLiwgbGluZSBjYXJk KS4gJm5ic3A7VGhlIHNvbHV0aW9uIGVuYWJsZXMgdGhlIGNsaWVudCB0bw0KIHBhcnRpdGlvbiBu b3RpZmljYXRpb25zIGNvbWluZyBmcm9tIGRpZmZlcmVudCBwdWJsaXNoZXJzLCBidXQgdGhhdCBp cyBpdC4gJm5ic3A7V2hhdCB2YWx1ZSBkb2VzIHRoaXMgaGF2ZSB0byB0aGUgY2xpZW50LCBJIGRv buKAmXQga25vdy4gJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkFuc3dlcmlu ZyBteXNlbGYgaGVyZSwgcGVyaGFwcyBpdCBlbmFibGVzIHR3byBzZXJ2ZXJzIG9uIHRoZSBzYW1l IElQIGFkZHJlc3MgdG8gc2VuZCB0byB0aGUgc2FtZSByZWNlaXZlciwgYXMgdGhlbiB0aGUmbmJz cDtyZWNlaXZlciBkb2VzbuKAmXQgc29sZWx5IHJlbHkgb24gc291cmNlLUlQIGFkZHJlc3MgKGFz c3VtaW5nIHVuYXV0aGVudGljYXRlZCBwdXNoKSB0byBkZXNpZ25hdGUNCiB0aGUgcHVibGlzaGVy Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2FuIHRoZSBhdXRo b3JzIGhlbHAgcmVzb2x2ZSB0aGUgdmFsdWUtcHJvcG9zaXRpb24gcXVlc3Rpb24gaGVyZT88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPksuPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5c058aa40cbf4141b32b19bd53514415huaweicom_-- From nobody Tue Sep 22 08:10:37 2020 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 ED8FF3A0F9F for ; Tue, 22 Sep 2020 08:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 BQKvFx28X6OP for ; Tue, 22 Sep 2020 08:10:33 -0700 (PDT) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 CBC8A3A0F8A for ; Tue, 22 Sep 2020 08:10:32 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id v123so19308697qkd.9 for ; Tue, 22 Sep 2020 08:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=piPxfaFFNZT3uE78wMyx68a5eJ+xbjJ3toR/s3zy1kc=; b=Fqvqj2cY6szPvWnKd1kiD3WmFaNajVAqlXTGxsBZXHJTFF67hMwZ/4BBHH5/a1SMUA MziwXfakIbV7vbE3BUus4VE4tJTXx72oZN+yeknDHBfup4XH4CXgJD5K8OHjGNPRMQwn 9u7nNRjmi/HaCKzh4qJb7REd63HadVUwQ+RgGkUKziVIJhckKcTZYa8xYWGlgQdWCH9x VSrL5RraN4zZcCzZSi81KcKtwLy/jAC1Ws9VgOYuJq5JD+GkQAf9TMChZA1N0O6t8913 NqXneSn81tkc6RsGPBjRTtwTE2uC2KGAnqhTw9BPgLdtOy+sDucRrH3wXhOEz6A96fl8 cScA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=piPxfaFFNZT3uE78wMyx68a5eJ+xbjJ3toR/s3zy1kc=; b=dMTi5sn8GemFEJzdtEdZFPVvqbSTPQMl+Sjhr32jGM71zQPe9atBicBEZi1GBvbRy3 pJ/gFrFCTUExjt0udgJw0ABCH9kxfrz4pe1PwaF49KDxbaqhLaSeIoMZH7m6Bp1Kmc8U Q3m1KmY/FW6uOi9WFk2O49EId4VC/CZJN8pR3pN6Pe9XGnhTr35x5dcPxVFikMAUINL0 l1ZTdloNOiOVYecPj2K68ikaXMy9FeNKq7bw9NCYzZFbGLHiNtSUD240yJu/l6ZRU54U Op4i1kGCUCERAV9USLRMI4hq5kkVwJJRzJH6pUVxF26zMmeJ+s9PsBr1bbDa4cYYZF9v e+4A== X-Gm-Message-State: AOAM532GIjCMMyST5awiZqy6XIOrm3Hh7HziZ7botN+kdoKKtdmZHr1/ TP/Bf3YhOr1jyARzRuedk1vLB27/eM/UqA== X-Google-Smtp-Source: ABdhPJwX/KyPbJAlzQ4nzZ6lWajA+CGxIR0xcAJsLi//+ljtLo0BhhYuhV2zk9dTGLKmCAV90XnSaw== X-Received: by 2002:a37:9c8:: with SMTP id 191mr5218805qkj.292.1600787431740; Tue, 22 Sep 2020 08:10:31 -0700 (PDT) Received: from [172.17.101.162] (66-76-170-6.com.sta.suddenlink.net. [66.76.170.6]) by smtp.gmail.com with ESMTPSA id g12sm11870365qke.90.2020.09.22.08.10.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Sep 2020 08:10:30 -0700 (PDT) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_05BCDF4E-9114-41D4-9DFA-E57DA824E7E2" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Tue, 22 Sep 2020 08:10:28 -0700 In-Reply-To: <5c058aa40cbf4141b32b19bd53514415@huawei.com> Cc: Kent Watsen , Andy Bierman , "netconf@ietf.org" To: Tianran Zhou References: <01000173c0b07b33-ad0b793a-7afc-4b39-95f8-2f50574d57bb-000000@us-east-1.amazonses.com> <01000174b2ba9c57-cbc0d353-8d30-4885-8769-1ea869b4d0be-000000@email.amazonses.com> <01000174b2e0a349-52337b7b-81c3-4c56-a58b-36c95d68340f-000000@email.amazonses.com> <5c058aa40cbf4141b32b19bd53514415@huawei.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2020 15:10:35 -0000 --Apple-Mail=_05BCDF4E-9114-41D4-9DFA-E57DA824E7E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [As a contributor] Hi Tianran, I am confused by the value statement. Maybe you can help clarify. It would help if we can use a single terminology of publisher/subscriber = instead of mixing it with client, which I understand to be the = subscriber and server which I understand to be the publisher. Note, if = HTTPS is used, the role of client and server would be reversed, so it is = best to avoid using those terms. See inline with [mj]. > On Sep 21, 2020, at 7:04 PM, Tianran Zhou = wrote: >=20 > Thanks Andy for your opinion. And thank Kent for your expansion and = further question. > The goal is to allow the client to know if it has received all the = data pieces. Furthermore, the client know which publisher failed to send = data. Then it depend on the client to do the action, e.g., ignore, = require the data one more, =E2=80=A6 > We just use the generator-id to indicate the publisher, as we find it = in ietf-netconf-notification-messages, and it=E2=80=99s very convenient = for this usage. [mj] What usage would be that? The usage of generator-id to indicate who = is the publisher and thereby have the subscriber request for any missing = data? I would like to note that nothing prevents usage of a reliable = transport, e.g. HTTPS or TCP, with this draft. Would you still need a = generator-id? > One use case is exactly as Kent mentioned =E2=80=9CAnswering myself = here, perhaps it enables two servers on the same IP address to send to = the same receiver, as then the receiver doesn=E2=80=99t solely rely on = source-IP address (assuming unauthenticated push) to designate the = publisher=E2=80=9D. > It=E2=80=99s also OK for us to use another indicator if the = generator-id is not feasible. [mj] Precisely. If you use a reliable transport, you would have other = means to identify the source of the notifications, in which case you = would not need the generator-id. Which goes back to the question of why we need a generator-id. If we do = not want data loss, we should be using a reliable transport, in which = case we do not need a generator-id. If we can tolerate data loss, e.g. = with statistics, we do not care for generator-id because we are not = going to ask for missing data. What use case requires us to use = unreliable transport and yet need a generator-id? Thanks. > =E2=80=9Cwhat seems to be missing is an ability for the client to = determine which generator-id is used by which publisher (e.g., line = card). =E2=80=9D > If necessary, maybe we can extend this mapping in some initial = exchanges. To be clear, how do you want to name the publisher? > =20 > Thanks, > Tianran > =20 > From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent = Watsen > Sent: Tuesday, September 22, 2020 6:55 AM > To: Andy Bierman > Cc: netconf@ietf.org > Subject: Re: [netconf] Adoption-suitability for = draft-unyte-netconf-distributed-notif > =20 > [As an individual contributor] > =20 > The overall approach to the binary push features seems a bit = incoherent to me. > I don't see much value in this draft, but no harm either so I do not = have an objection > to adoption. Perhaps there is some debugging value here but since the = architecture > really does not define message generators as sub-components of a = configured subscription, > a client cannot expect any sort of consistent implementation of this = field. > =20 > Good point. If I understand you correctly, what seems to be missing is = an ability for the client to determine which generator-id is used by = which publisher (e.g., line card). The solution enables the client to = partition notifications coming from different publishers, but that is = it. What value does this have to the client, I don=E2=80=99t know. =20 > =20 > Answering myself here, perhaps it enables two servers on the same IP = address to send to the same receiver, as then the receiver doesn=E2=80=99t= solely rely on source-IP address (assuming unauthenticated push) to = designate the publisher? >=20 >=20 > Can the authors help resolve the value-proposition question here? > =20 > K. > =20 > =20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_05BCDF4E-9114-41D4-9DFA-E57DA824E7E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 [As = a contributor]

Hi = Tianran,

I am = confused by the value statement. Maybe you can help clarify.

It would help if we can = use a single terminology of publisher/subscriber instead of mixing it = with client, which I understand to be the subscriber and server which I = understand to be the publisher. Note, if HTTPS is used, the role of = client and server would be reversed, so it is best to avoid using those = terms.

See = inline with [mj].

On Sep 21, 2020, at 7:04 PM, = Tianran Zhou <zhoutianran@huawei.com> wrote:

Thanks Andy for your opinion. And thank Kent for = your expansion and further question.

The goal is to allow the client to know if it has = received all the data pieces. Furthermore, the client know which = publisher failed to send data. Then it depend on the client to do the action, e.g., ignore, require the data one = more, =E2=80=A6

We just use the generator-id to indicate the = publisher, as we find it in ietf-netconf-notification-messages, and it=E2=80=99s = very convenient for this = usage.


[mj] What usage would be that? The usage of = generator-id to indicate who is the publisher and thereby have the = subscriber request for any missing data? I would like to note that = nothing prevents usage of a reliable transport, e.g. HTTPS or TCP, with = this draft. Would you still need a generator-id?

One use case is exactly as Kent mentioned = =E2=80=9CAnswering myself here, perhaps it enables two servers on the = same IP address to send to the same receiver, as then the receiver doesn=E2=80=99t solely rely on source-IP address (assuming = unauthenticated push) to designate the publisher=E2=80=9D.

It=E2=80=99s also OK for us to use another = indicator if the generator-id is not = feasible.


[mj] Precisely. If you use a reliable transport, you = would have other means to identify the source of the notifications, in = which case you would not need the generator-id.

Which goes back to the question of why we need a = generator-id. If we do not want data loss, we should be using a reliable = transport, in which case we do not need a generator-id. If we can = tolerate data loss, e.g. with statistics, we do not care for = generator-id because we are not going to ask for missing data. What use = case requires us to use unreliable transport and yet need a = generator-id?

Thanks.

=E2=80=9Cwhat seems to be missing is an ability for = the client to determine which generator-id is used by which publisher = (e.g., line card). =E2=80=9D

If necessary, maybe we can extend this mapping in = some initial exchanges. To be clear, how do you want to name the = publisher?

 

Thanks,

Tianran

 

From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent Watsen
Sent: Tuesday, September 22, 2020 6:55 AM
= To: Andy Bierman <andy@yumaworks.com>
Cc: netconf@ietf.org
Subject: Re: [netconf] Adoption-suitability for = draft-unyte-netconf-distributed-notif

 

[As an individual = contributor]

 

The overall approach to the binary push features seems a bit = incoherent to me.

I don't see much value in this draft, but no harm either so I = do not have an objection

to adoption.  Perhaps there is some debugging value here = but since the architecture

really does not define message generators as sub-components = of a configured subscription,

a client cannot expect any sort of consistent implementation = of this field.

 

Good point. If I understand you = correctly, what seems to be missing is an = ability for the client to determine which generator-id is used by which = publisher (e.g., line card).  The solution enables the client to partition notifications coming from different publishers, but that is = it.  What value does this have to the client, I don=E2=80=99t know. =  

 

Answering myself here, perhaps it enables two servers on the = same IP address to send to the same receiver, as then the receiver = doesn=E2=80=99t solely rely on source-IP address (assuming = unauthenticated push) to designate the publisher?



Can the authors help resolve the = value-proposition question here?

 

K.

 

 

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

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_05BCDF4E-9114-41D4-9DFA-E57DA824E7E2-- From nobody Tue Sep 22 09:57:56 2020 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 E40033A09F3 for ; Tue, 22 Sep 2020 09:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 3Ar7BpsdaeJt for ; Tue, 22 Sep 2020 09:57:53 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 6AF923A09DB for ; Tue, 22 Sep 2020 09:57:53 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id 77so11501320lfj.0 for ; Tue, 22 Sep 2020 09:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yMI4Gd64BionvTKGo/Z5dzPsfH1cEsykWHPIfYhGDno=; b=ZpFKDLjzCvS5qK5nb1RvwckUkBRtkwkbDScoYJo8jAYOkPngGmFqjpeH9v7ysrJxlV uPoIyRycry+DWJcsenSG5JP0uYbaQeCD5Txm6fS2y3oNDKMU8lm69SanSJobrBa6+rtH N3TLhXZw/BMiq9VXGG5S0KDwPHlo9NFmgmdy/ndaNynvS8AONU5aiQTFEaZ4L/TaBhyx UJARjaw3fBNSuIEcdirCWX9RsMA9r3UTrm6ijVKXmUmoaxGJMgZ7HIy8jhGsx06e2qh7 gnGZvaZLPn0+TfIiyn6fOCiCplZlT1cLYZC+Dg7/Z3vxtmoOTYrb4sVR3hT3fbU0bVo1 cvSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yMI4Gd64BionvTKGo/Z5dzPsfH1cEsykWHPIfYhGDno=; b=K8veFMSD9N7Y/vgJDv3joLSFdXz9+50xE+cGOrJxcH7L5D6gvaUgMfyM62RYhim4JI NXeVdrljKniPV96sKQlt510yx0Fm/RJMuLBL8bNsoytFMtZjakfKDYACCRZal6PpRHQ5 IX6RWG67YxC05Tqve35up2/W0dkqkHIc1FrqYJNX+MCrVcUcXyWTE2vcuc9+QYRt6UIh mRBuof09qzUWyRon1clnAOrgO1toMa2dq2179KuhtuYMYPkKKT4C8LWnj2/GGj8tBDZz aYoMcVJxWFk8Sq1u9cYUh6DYkTjJlvBHcLOJwzLza48qaLojI+E3lgnp8GbnTVdjuPb3 Mmyw== X-Gm-Message-State: AOAM530RNeROJqRrxsIWtCSO0WHuQ5g1++lR18FRWJ9zTkZJETOf/++6 a8Ju3ff+ZCM1OenH/SuJ5Dv/o/lGhR3PQuXJA3LV7RykVDEleg== X-Google-Smtp-Source: ABdhPJzXtGg45Gp4FKWp+rm+VOz0nyHqyLsjP3y+9C9/UX89w+sNi+PyKnuQQQuJt1Zpt3srEn8r9+xdD61DEhN2zSg= X-Received: by 2002:a19:8708:: with SMTP id j8mr2191749lfd.266.1600793871344; Tue, 22 Sep 2020 09:57:51 -0700 (PDT) MIME-Version: 1.0 References: <01000173c0b07b33-ad0b793a-7afc-4b39-95f8-2f50574d57bb-000000@us-east-1.amazonses.com> <01000174b2ba9c57-cbc0d353-8d30-4885-8769-1ea869b4d0be-000000@email.amazonses.com> <01000174b2e0a349-52337b7b-81c3-4c56-a58b-36c95d68340f-000000@email.amazonses.com> In-Reply-To: <01000174b2e0a349-52337b7b-81c3-4c56-a58b-36c95d68340f-000000@email.amazonses.com> From: Andy Bierman Date: Tue, 22 Sep 2020 09:57:40 -0700 Message-ID: To: Kent Watsen Cc: "netconf@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000f7d2805afe9de57" Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2020 16:57:55 -0000 --0000000000000f7d2805afe9de57 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 21, 2020 at 3:55 PM Kent Watsen wrote: > [As an individual contributor] > > The overall approach to the binary push features seems a bit incoherent t= o > me. > I don't see much value in this draft, but no harm either so I do not have > an objection > to adoption. Perhaps there is some debugging value here but since the > architecture > really does not define message generators as sub-components of a > configured subscription, > a client cannot expect any sort of consistent implementation of this fiel= d. > > > Good point. If I understand you correctly, what seems to be missing is an > ability for the client to determine which generator-id is used by which > publisher (e.g., line card). The solution enables the client to partitio= n > notifications coming from different publishers, but that is it. What > value does this have to the client, I don=E2=80=99t know. > > The draft does not even have a section discussing the problem that needs to be solved. It is useful to distinguish between adoption of a problem-to-be-solved and adoption of a draft. Since I have to guess what problem this draft is solving, I suspect the proposed solution is just wrong. The ietf-hardware module should be augmented with a generator-id, not the subscriptions. The assumed problem is that data reported from multiple publishers for the same subscription needs to be correlated somehow. The client can use the ietf-hardware info to determine the standard and vendor-specific details about the hardware sending the generator-id. Andy Answering myself here, perhaps it enables two servers on the same IP > address to send to the same receiver, as then the receiver doesn=E2=80=99= t solely > rely on source-IP address (assuming unauthenticated push) to designate th= e > publisher? > > Can the authors help resolve the value-proposition question here? > > K. > > > --0000000000000f7d2805afe9de57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Sep 21, 2020 at 3:55 PM Kent = Watsen <kent+ietf@watsen.net> wrote:
[As an individual contributor]=

The overall approach to the binary push features seems a= bit incoherent to me.
I don't see much value in this draft, = but no harm either so I do not have an objection
to adoption.=C2= =A0 Perhaps there is some debugging value here but since the architecture
really does not define message generators as sub-components of a c= onfigured subscription,
a client cannot expect any sort of consis= tent implementation of this field.

<= /div>
Good point. If I understand you correctly, what seems to be missing is an ability for the client to determine which = generator-id is used by which publisher (e.g., line card).=C2=A0 The soluti= on enables the client to partition notifications coming from different publ= ishers, but that is it. =C2=A0What = value does this have to the client, I don=E2=80=99t know. =C2=A0



The draft does not even have a se= ction discussing the problem that needs to be solved.
It is usefu= l to distinguish between adoption of a problem-to-be-solved and adoption of= a draft.

Since I have to guess what problem this = draft is solving, I suspect the proposed solution
is just wrong.= =C2=A0 The ietf-hardware module should be augmented
with a genera= tor-id, not the subscriptions. The assumed problem is that
data r= eported from multiple publishers for the same subscription needs to be corr= elated somehow.
The client can use the ietf-hardware info to dete= rmine the standard and vendor-specific details
about the hardware= sending the generator-id.=C2=A0=C2=A0


<= div>Andy


Answering myself here, perhaps it enables two servers on the same IP a= ddress to send to the same receiver, as then the=C2=A0receiver doesn=E2=80= =99t solely rely on source-IP address (assuming unauthenticated push) to de= signate the publisher?
Can the authors help resolve the value-proposition ques= tion here?

K.


=
--0000000000000f7d2805afe9de57-- From nobody Tue Sep 22 23:51:12 2020 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 E173B3A0A2B for ; Tue, 22 Sep 2020 23:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 OMbDrH2m7qVx for ; Tue, 22 Sep 2020 23:51:08 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 90E303A0A25 for ; Tue, 22 Sep 2020 23:51:08 -0700 (PDT) Received: from lhreml738-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 29BE87CA55D6D9009141; Wed, 23 Sep 2020 07:51:07 +0100 (IST) Received: from nkgeml706-chm.china.huawei.com (10.98.57.153) by lhreml738-chm.china.huawei.com (10.201.108.188) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 23 Sep 2020 07:51:06 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml706-chm.china.huawei.com (10.98.57.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 23 Sep 2020 14:51:04 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Wed, 23 Sep 2020 14:51:04 +0800 From: Tianran Zhou To: Mahesh Jethanandani CC: Kent Watsen , Andy Bierman , "netconf@ietf.org" Thread-Topic: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif Thread-Index: AQHWa3XT/yp90Vv9H0i3R7lOe+hPQ6kxPqwAgAEGkBCAQSaZAIAABOyAgAAGrgCAALMIwIAAXYMAgAGGTKA= Date: Wed, 23 Sep 2020 06:51:03 +0000 Message-ID: <444c48abc18e4539acd4229075b5fb77@huawei.com> References: <01000173c0b07b33-ad0b793a-7afc-4b39-95f8-2f50574d57bb-000000@us-east-1.amazonses.com> <01000174b2ba9c57-cbc0d353-8d30-4885-8769-1ea869b4d0be-000000@email.amazonses.com> <01000174b2e0a349-52337b7b-81c3-4c56-a58b-36c95d68340f-000000@email.amazonses.com> <5c058aa40cbf4141b32b19bd53514415@huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.128] Content-Type: multipart/alternative; boundary="_000_444c48abc18e4539acd4229075b5fb77huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2020 06:51:11 -0000 --_000_444c48abc18e4539acd4229075b5fb77huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFoZXNoLA0KDQpQbGVhc2Ugc2VlIGluIGxpbmUgYWJvdXQgbXkgdGhvdWdodHMuDQoNClRo YW5rcywNClRpYW5yYW4NCg0KRnJvbTogTWFoZXNoIEpldGhhbmFuZGFuaSBbbWFpbHRvOm1qZXRo YW5hbmRhbmlAZ21haWwuY29tXQ0KU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDIyLCAyMDIwIDEx OjEwIFBNDQpUbzogVGlhbnJhbiBaaG91IDx6aG91dGlhbnJhbkBodWF3ZWkuY29tPg0KQ2M6IEtl bnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD47IEFuZHkgQmllcm1hbiA8YW5keUB5dW1h d29ya3MuY29tPjsgbmV0Y29uZkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRjb25mXSBBZG9w dGlvbi1zdWl0YWJpbGl0eSBmb3IgZHJhZnQtdW55dGUtbmV0Y29uZi1kaXN0cmlidXRlZC1ub3Rp Zg0KDQpbQXMgYSBjb250cmlidXRvcl0NCg0KSGkgVGlhbnJhbiwNCg0KSSBhbSBjb25mdXNlZCBi eSB0aGUgdmFsdWUgc3RhdGVtZW50LiBNYXliZSB5b3UgY2FuIGhlbHAgY2xhcmlmeS4NCg0KSXQg d291bGQgaGVscCBpZiB3ZSBjYW4gdXNlIGEgc2luZ2xlIHRlcm1pbm9sb2d5IG9mIHB1Ymxpc2hl ci9zdWJzY3JpYmVyIGluc3RlYWQgb2YgbWl4aW5nIGl0IHdpdGggY2xpZW50LCB3aGljaCBJIHVu ZGVyc3RhbmQgdG8gYmUgdGhlIHN1YnNjcmliZXIgYW5kIHNlcnZlciB3aGljaCBJIHVuZGVyc3Rh bmQgdG8gYmUgdGhlIHB1Ymxpc2hlci4gTm90ZSwgaWYgSFRUUFMgaXMgdXNlZCwgdGhlIHJvbGUg b2YgY2xpZW50IGFuZCBzZXJ2ZXIgd291bGQgYmUgcmV2ZXJzZWQsIHNvIGl0IGlzIGJlc3QgdG8g YXZvaWQgdXNpbmcgdGhvc2UgdGVybXMuDQoNClNlZSBpbmxpbmUgd2l0aCBbbWpdLg0KDQoNCk9u IFNlcCAyMSwgMjAyMCwgYXQgNzowNCBQTSwgVGlhbnJhbiBaaG91IDx6aG91dGlhbnJhbkBodWF3 ZWkuY29tPG1haWx0bzp6aG91dGlhbnJhbkBodWF3ZWkuY29tPj4gd3JvdGU6DQoNClRoYW5rcyBB bmR5IGZvciB5b3VyIG9waW5pb24uIEFuZCB0aGFuayBLZW50IGZvciB5b3VyIGV4cGFuc2lvbiBh bmQgZnVydGhlciBxdWVzdGlvbi4NClRoZSBnb2FsIGlzIHRvIGFsbG93IHRoZSBjbGllbnQgdG8g a25vdyBpZiBpdCBoYXMgcmVjZWl2ZWQgYWxsIHRoZSBkYXRhIHBpZWNlcy4gRnVydGhlcm1vcmUs IHRoZSBjbGllbnQga25vdyB3aGljaCBwdWJsaXNoZXIgZmFpbGVkIHRvIHNlbmQgZGF0YS4gVGhl biBpdCBkZXBlbmQgb24gdGhlIGNsaWVudCB0byBkbyB0aGUgYWN0aW9uLCBlLmcuLCBpZ25vcmUs IHJlcXVpcmUgdGhlIGRhdGEgb25lIG1vcmUsIOKApg0KV2UganVzdCB1c2UgdGhlIGdlbmVyYXRv ci1pZCB0byBpbmRpY2F0ZSB0aGUgcHVibGlzaGVyLCBhcyB3ZSBmaW5kIGl0IGluIGlldGYtbmV0 Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMsIGFuZCBpdOKAmXMgdmVyeSBjb252ZW5pZW50IGZv ciB0aGlzIHVzYWdlLg0KDQpbbWpdIFdoYXQgdXNhZ2Ugd291bGQgYmUgdGhhdD8gVGhlIHVzYWdl IG9mIGdlbmVyYXRvci1pZCB0byBpbmRpY2F0ZSB3aG8gaXMgdGhlIHB1Ymxpc2hlciBhbmQgdGhl cmVieSBoYXZlIHRoZSBzdWJzY3JpYmVyIHJlcXVlc3QgZm9yIGFueSBtaXNzaW5nIGRhdGE/IEkg d291bGQgbGlrZSB0byBub3RlIHRoYXQgbm90aGluZyBwcmV2ZW50cyB1c2FnZSBvZiBhIHJlbGlh YmxlIHRyYW5zcG9ydCwgZS5nLiBIVFRQUyBvciBUQ1AsIHdpdGggdGhpcyBkcmFmdC4gV291bGQg eW91IHN0aWxsIG5lZWQgYSBnZW5lcmF0b3ItaWQ/DQoNCk9uZSB1c2UgY2FzZSBpcyBleGFjdGx5 IGFzIEtlbnQgbWVudGlvbmVkIOKAnEFuc3dlcmluZyBteXNlbGYgaGVyZSwgcGVyaGFwcyBpdCBl bmFibGVzIHR3byBzZXJ2ZXJzIG9uIHRoZSBzYW1lIElQIGFkZHJlc3MgdG8gc2VuZCB0byB0aGUg c2FtZSByZWNlaXZlciwgYXMgdGhlbiB0aGUgcmVjZWl2ZXIgZG9lc27igJl0IHNvbGVseSByZWx5 IG9uIHNvdXJjZS1JUCBhZGRyZXNzIChhc3N1bWluZyB1bmF1dGhlbnRpY2F0ZWQgcHVzaCkgdG8g ZGVzaWduYXRlIHRoZSBwdWJsaXNoZXLigJ0uDQpJdOKAmXMgYWxzbyBPSyBmb3IgdXMgdG8gdXNl IGFub3RoZXIgaW5kaWNhdG9yIGlmIHRoZSBnZW5lcmF0b3ItaWQgaXMgbm90IGZlYXNpYmxlLg0K DQpbbWpdIFByZWNpc2VseS4gSWYgeW91IHVzZSBhIHJlbGlhYmxlIHRyYW5zcG9ydCwgeW91IHdv dWxkIGhhdmUgb3RoZXIgbWVhbnMgdG8gaWRlbnRpZnkgdGhlIHNvdXJjZSBvZiB0aGUgbm90aWZp Y2F0aW9ucywgaW4gd2hpY2ggY2FzZSB5b3Ugd291bGQgbm90IG5lZWQgdGhlIGdlbmVyYXRvci1p ZC4NCg0KenRyPiBZZXMuIEJ1dCBJIGp1c3QgdGhpbmsgaWYgd2UgY2FuIHVzZSB0aGUgZ2VuZXJh dG9yLWlkLCB3ZSBkbyBub3QgbmVlZCB0byBkZXZlbG9wIGRpZmZlcmVudCB3YXlzIGZvciBlYWNo IHRyYW5zcG9ydC4gU28gdGhhdCB0aGUgcHJvY2VkdXJlIGNvdWxkIGJlIGNvbnNpc3RlbnQuDQoN CldoaWNoIGdvZXMgYmFjayB0byB0aGUgcXVlc3Rpb24gb2Ygd2h5IHdlIG5lZWQgYSBnZW5lcmF0 b3ItaWQuIElmIHdlIGRvIG5vdCB3YW50IGRhdGEgbG9zcywgd2Ugc2hvdWxkIGJlIHVzaW5nIGEg cmVsaWFibGUgdHJhbnNwb3J0LCBpbiB3aGljaCBjYXNlIHdlIGRvIG5vdCBuZWVkIGEgZ2VuZXJh dG9yLWlkLiBJZiB3ZSBjYW4gdG9sZXJhdGUgZGF0YSBsb3NzLCBlLmcuIHdpdGggc3RhdGlzdGlj cywgd2UgZG8gbm90IGNhcmUgZm9yIGdlbmVyYXRvci1pZCBiZWNhdXNlIHdlIGFyZSBub3QgZ29p bmcgdG8gYXNrIGZvciBtaXNzaW5nIGRhdGEuIFdoYXQgdXNlIGNhc2UgcmVxdWlyZXMgdXMgdG8g dXNlIHVucmVsaWFibGUgdHJhbnNwb3J0IGFuZCB5ZXQgbmVlZCBhIGdlbmVyYXRvci1pZD8NCg0K enRyPiBIZXJlIHdlIHdhbnQgdG8gY2hlY2sgdGhlIGludGVncml0eSwgbm90IHRoZSBwcmVjaXNl IHBhY2tldCBsb3NzLiBGb3IgcmVsaWFibGUgdHJhbnNwb3J0LCB0aGUgcmVjZWl2ZXIga25vdyBo b3cgbWFueSBzZXNzaW9ucyBuZWVkIHRvIGVzdGFibGlzaCBmb3Igb25lIHN1YnNjcmlwdGlvbi4g T24gdGhlIG90aGVyIGhhbmQsICBpZiBvbmUgc2Vzc2lvbiBnZXQgbG9zdCwgd2hpY2ggc3Vic2Ny aXB0aW9ucyBhcmUgaW1wYWN0ZWQuDQpGb3IgdGhlIHVucmVsaWFibGUgdHJhbnNwb3J0LCBvbmUg bW9yZSBjYXNlIGlzLCBpZiBvbmUgc2Vzc2lvbiBpcyByZWFsbHkgYmFkIChzYXkgNTAlIHBhY2tl dCBsb3NzKSwgdGhlIHN1YnNjcmliZXIgbWF5IG5lZWQgdG8gZG8gc29tZSBhY3Rpb24vYWRqdXN0 bWVudC4gWWVzIHdlIGNhbiB0b2xlcmF0ZSBkYXRhIGxvc3MsIGJ1dCBJIHRoaW5rIGl0IHNob3Vs ZCBiZSBhIHRocmVzaG9sZC4NCg0KVGhhbmtzLg0KDQoNCuKAnHdoYXQgc2VlbXMgdG8gYmUgbWlz c2luZyBpcyBhbiBhYmlsaXR5IGZvciB0aGUgY2xpZW50IHRvIGRldGVybWluZSB3aGljaCBnZW5l cmF0b3ItaWQgaXMgdXNlZCBieSB3aGljaCBwdWJsaXNoZXIgKGUuZy4sIGxpbmUgY2FyZCkuIOKA nQ0KSWYgbmVjZXNzYXJ5LCBtYXliZSB3ZSBjYW4gZXh0ZW5kIHRoaXMgbWFwcGluZyBpbiBzb21l IGluaXRpYWwgZXhjaGFuZ2VzLiBUbyBiZSBjbGVhciwgaG93IGRvIHlvdSB3YW50IHRvIG5hbWUg dGhlIHB1Ymxpc2hlcj8NCg0KVGhhbmtzLA0KVGlhbnJhbg0KDQpGcm9tOiBuZXRjb25mIFttYWls dG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS2VudCBXYXRzZW4NClNl bnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAyMiwgMjAyMCA2OjU1IEFNDQpUbzogQW5keSBCaWVybWFu IDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+DQpDYzogbmV0 Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbmV0 Y29uZl0gQWRvcHRpb24tc3VpdGFiaWxpdHkgZm9yIGRyYWZ0LXVueXRlLW5ldGNvbmYtZGlzdHJp YnV0ZWQtbm90aWYNCg0KW0FzIGFuIGluZGl2aWR1YWwgY29udHJpYnV0b3JdDQoNClRoZSBvdmVy YWxsIGFwcHJvYWNoIHRvIHRoZSBiaW5hcnkgcHVzaCBmZWF0dXJlcyBzZWVtcyBhIGJpdCBpbmNv aGVyZW50IHRvIG1lLg0KSSBkb24ndCBzZWUgbXVjaCB2YWx1ZSBpbiB0aGlzIGRyYWZ0LCBidXQg bm8gaGFybSBlaXRoZXIgc28gSSBkbyBub3QgaGF2ZSBhbiBvYmplY3Rpb24NCnRvIGFkb3B0aW9u LiAgUGVyaGFwcyB0aGVyZSBpcyBzb21lIGRlYnVnZ2luZyB2YWx1ZSBoZXJlIGJ1dCBzaW5jZSB0 aGUgYXJjaGl0ZWN0dXJlDQpyZWFsbHkgZG9lcyBub3QgZGVmaW5lIG1lc3NhZ2UgZ2VuZXJhdG9y cyBhcyBzdWItY29tcG9uZW50cyBvZiBhIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uLA0KYSBjbGll bnQgY2Fubm90IGV4cGVjdCBhbnkgc29ydCBvZiBjb25zaXN0ZW50IGltcGxlbWVudGF0aW9uIG9m IHRoaXMgZmllbGQuDQoNCkdvb2QgcG9pbnQuIElmIEkgdW5kZXJzdGFuZCB5b3UgY29ycmVjdGx5 LCB3aGF0IHNlZW1zIHRvIGJlIG1pc3NpbmcgaXMgYW4gYWJpbGl0eSBmb3IgdGhlIGNsaWVudCB0 byBkZXRlcm1pbmUgd2hpY2ggZ2VuZXJhdG9yLWlkIGlzIHVzZWQgYnkgd2hpY2ggcHVibGlzaGVy IChlLmcuLCBsaW5lIGNhcmQpLiAgVGhlIHNvbHV0aW9uIGVuYWJsZXMgdGhlIGNsaWVudCB0byBw YXJ0aXRpb24gbm90aWZpY2F0aW9ucyBjb21pbmcgZnJvbSBkaWZmZXJlbnQgcHVibGlzaGVycywg YnV0IHRoYXQgaXMgaXQuICBXaGF0IHZhbHVlIGRvZXMgdGhpcyBoYXZlIHRvIHRoZSBjbGllbnQs IEkgZG9u4oCZdCBrbm93Lg0KDQpBbnN3ZXJpbmcgbXlzZWxmIGhlcmUsIHBlcmhhcHMgaXQgZW5h YmxlcyB0d28gc2VydmVycyBvbiB0aGUgc2FtZSBJUCBhZGRyZXNzIHRvIHNlbmQgdG8gdGhlIHNh bWUgcmVjZWl2ZXIsIGFzIHRoZW4gdGhlIHJlY2VpdmVyIGRvZXNu4oCZdCBzb2xlbHkgcmVseSBv biBzb3VyY2UtSVAgYWRkcmVzcyAoYXNzdW1pbmcgdW5hdXRoZW50aWNhdGVkIHB1c2gpIHRvIGRl c2lnbmF0ZSB0aGUgcHVibGlzaGVyPw0KDQoNCg0KQ2FuIHRoZSBhdXRob3JzIGhlbHAgcmVzb2x2 ZSB0aGUgdmFsdWUtcHJvcG9zaXRpb24gcXVlc3Rpb24gaGVyZT8NCg0KSy4NCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0Y29uZiBtYWlsaW5n IGxpc3QNCm5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg0KTWFoZXNoIEpldGhhbmFu ZGFuaQ0KbWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwu Y29tPg0KDQoNCg0KDQo= --_000_444c48abc18e4539acd4229075b5fb77huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkhpIE1haGVzaCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlBs ZWFzZSBzZWUgaW4gbGluZSBhYm91dCBteSB0aG91Z2h0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGlhbnJhbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTWFoZXNoIEpldGhhbmFu ZGFuaSBbbWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+ IFR1ZXNkYXksIFNlcHRlbWJlciAyMiwgMjAyMCAxMToxMCBQTTxicj4NCjxiPlRvOjwvYj4gVGlh bnJhbiBaaG91ICZsdDt6aG91dGlhbnJhbkBodWF3ZWkuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4g S2VudCBXYXRzZW4gJmx0O2tlbnQmIzQzO2lldGZAd2F0c2VuLm5ldCZndDs7IEFuZHkgQmllcm1h biAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0OzsgbmV0Y29uZkBpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW25ldGNvbmZdIEFkb3B0aW9uLXN1aXRhYmlsaXR5IGZvciBkcmFmdC11 bnl0ZS1uZXRjb25mLWRpc3RyaWJ1dGVkLW5vdGlmPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+W0FzIGEgY29udHJpYnV0b3JdPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBUaWFucmFuLDxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBjb25mdXNlZCBieSB0aGUgdmFsdWUg c3RhdGVtZW50LiBNYXliZSB5b3UgY2FuIGhlbHAgY2xhcmlmeS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgd291bGQgaGVscCBpZiB3ZSBj YW4gdXNlIGEgc2luZ2xlIHRlcm1pbm9sb2d5IG9mIHB1Ymxpc2hlci9zdWJzY3JpYmVyIGluc3Rl YWQgb2YgbWl4aW5nIGl0IHdpdGggY2xpZW50LCB3aGljaCBJIHVuZGVyc3RhbmQgdG8gYmUgdGhl IHN1YnNjcmliZXIgYW5kIHNlcnZlciB3aGljaCBJIHVuZGVyc3RhbmQgdG8gYmUgdGhlIHB1Ymxp c2hlci4gTm90ZSwgaWYgSFRUUFMgaXMgdXNlZCwgdGhlIHJvbGUgb2YgY2xpZW50DQogYW5kIHNl cnZlciB3b3VsZCBiZSByZXZlcnNlZCwgc28gaXQgaXMgYmVzdCB0byBhdm9pZCB1c2luZyB0aG9z ZSB0ZXJtcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+U2VlIGlubGluZSB3aXRoIFttal0uPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBTZXAgMjEsIDIwMjAsIGF0IDc6MDQgUE0sIFRpYW5yYW4gWmhv dSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnpob3V0aWFucmFuQGh1YXdlaS5jb20iPnpob3V0aWFucmFu QGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgQW5k eSBmb3IgeW91ciBvcGluaW9uLiBBbmQgdGhhbmsgS2VudCBmb3IgeW91ciBleHBhbnNpb24gYW5k IGZ1cnRoZXIgcXVlc3Rpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBnb2FsIGlzIHRvIGFsbG93 IHRoZSBjbGllbnQgdG8ga25vdyBpZiBpdCBoYXMgcmVjZWl2ZWQgYWxsIHRoZSBkYXRhIHBpZWNl cy4gRnVydGhlcm1vcmUsIHRoZSBjbGllbnQga25vdyB3aGljaCBwdWJsaXNoZXIgZmFpbGVkIHRv IHNlbmQgZGF0YS4gVGhlbiBpdCBkZXBlbmQNCiBvbiB0aGUgY2xpZW50IHRvIGRvIHRoZSBhY3Rp b24sIGUuZy4sIGlnbm9yZSwgcmVxdWlyZSB0aGUgZGF0YSBvbmUgbW9yZSwg4oCmPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPldlIGp1c3QgdXNlIHRoZSBnZW5lcmF0b3ItaWQgdG8gaW5kaWNhdGUgdGhlIHB1 Ymxpc2hlciwgYXMgd2UgZmluZCBpdCBpbjwvc3Bhbj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzLCBhbmQgaXTigJlzIHZl cnkgY29udmVuaWVudCBmb3IgdGhpcyB1c2FnZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bbWpdIFdo YXQgdXNhZ2Ugd291bGQgYmUgdGhhdD8gVGhlIHVzYWdlIG9mIGdlbmVyYXRvci1pZCB0byBpbmRp Y2F0ZSB3aG8gaXMgdGhlIHB1Ymxpc2hlciBhbmQgdGhlcmVieSBoYXZlIHRoZSBzdWJzY3JpYmVy IHJlcXVlc3QgZm9yIGFueSBtaXNzaW5nIGRhdGE/IEkgd291bGQgbGlrZSB0byBub3RlIHRoYXQg bm90aGluZyBwcmV2ZW50cyB1c2FnZSBvZiBhIHJlbGlhYmxlIHRyYW5zcG9ydCwgZS5nLiBIVFRQ Uw0KIG9yIFRDUCwgd2l0aCB0aGlzIGRyYWZ0LiBXb3VsZCB5b3Ugc3RpbGwgbmVlZCBhIGdlbmVy YXRvci1pZD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5PbmUgdXNlIGNhc2UgaXMgZXhh Y3RseSBhcyBLZW50IG1lbnRpb25lZCDigJxBbnN3ZXJpbmcgbXlzZWxmIGhlcmUsIHBlcmhhcHMg aXQgZW5hYmxlcyB0d28gc2VydmVycyBvbiB0aGUgc2FtZSBJUCBhZGRyZXNzIHRvIHNlbmQgdG8g dGhlIHNhbWUgcmVjZWl2ZXIsIGFzIHRoZW4NCiB0aGUgcmVjZWl2ZXIgZG9lc27igJl0IHNvbGVs eSByZWx5IG9uIHNvdXJjZS1JUCBhZGRyZXNzIChhc3N1bWluZyB1bmF1dGhlbnRpY2F0ZWQgcHVz aCkgdG8gZGVzaWduYXRlIHRoZSBwdWJsaXNoZXLigJ0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkl04oCZ cyBhbHNvIE9LIGZvciB1cyB0byB1c2UgYW5vdGhlciBpbmRpY2F0b3IgaWYgdGhlIGdlbmVyYXRv ci1pZCBpcyBub3QgZmVhc2libGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W21qXSBQcmVjaXNlbHku IElmIHlvdSB1c2UgYSByZWxpYWJsZSB0cmFuc3BvcnQsIHlvdSB3b3VsZCBoYXZlIG90aGVyIG1l YW5zIHRvIGlkZW50aWZ5IHRoZSBzb3VyY2Ugb2YgdGhlIG5vdGlmaWNhdGlvbnMsIGluIHdoaWNo IGNhc2UgeW91IHdvdWxkIG5vdCBuZWVkIHRoZSBnZW5lcmF0b3ItaWQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnp0ciZndDsgWWVzLiBCdXQgSSBqdXN0 IHRoaW5rIGlmIHdlIGNhbiB1c2UgdGhlIGdlbmVyYXRvci1pZCwgd2UgZG8gbm90IG5lZWQgdG8g ZGV2ZWxvcCBkaWZmZXJlbnQgd2F5cyBmb3IgZWFjaCB0cmFuc3BvcnQuIFNvIHRoYXQgdGhlIHBy b2NlZHVyZSBjb3VsZCBiZSBjb25zaXN0ZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X aGljaCBnb2VzIGJhY2sgdG8gdGhlIHF1ZXN0aW9uIG9mIHdoeSB3ZSBuZWVkIGEgZ2VuZXJhdG9y LWlkLiBJZiB3ZSBkbyBub3Qgd2FudCBkYXRhIGxvc3MsIHdlIHNob3VsZCBiZSB1c2luZyBhIHJl bGlhYmxlIHRyYW5zcG9ydCwgaW4gd2hpY2ggY2FzZSB3ZSBkbyBub3QgbmVlZCBhIGdlbmVyYXRv ci1pZC4gSWYgd2UgY2FuIHRvbGVyYXRlIGRhdGEgbG9zcywgZS5nLiB3aXRoIHN0YXRpc3RpY3Ms IHdlIGRvDQogbm90IGNhcmUgZm9yIGdlbmVyYXRvci1pZCBiZWNhdXNlIHdlIGFyZSBub3QgZ29p bmcgdG8gYXNrIGZvciBtaXNzaW5nIGRhdGEuIFdoYXQgdXNlIGNhc2UgcmVxdWlyZXMgdXMgdG8g dXNlIHVucmVsaWFibGUgdHJhbnNwb3J0IGFuZCB5ZXQgbmVlZCBhIGdlbmVyYXRvci1pZD88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+enRyJmd0OyBIZXJl IHdlIHdhbnQgdG8gY2hlY2sgdGhlIGludGVncml0eSwgbm90IHRoZSBwcmVjaXNlIHBhY2tldCBs b3NzLiBGb3IgcmVsaWFibGUgdHJhbnNwb3J0LCB0aGUgcmVjZWl2ZXIga25vdyBob3cgbWFueSBz ZXNzaW9ucyBuZWVkIHRvIGVzdGFibGlzaCBmb3Igb25lIHN1YnNjcmlwdGlvbi4NCiBPbiB0aGUg b3RoZXIgaGFuZCwgJm5ic3A7aWYgb25lIHNlc3Npb24gZ2V0IGxvc3QsIHdoaWNoIHN1YnNjcmlw dGlvbnMgYXJlIGltcGFjdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Gb3IgdGhlIHVucmVsaWFibGUg dHJhbnNwb3J0LCBvbmUgbW9yZSBjYXNlIGlzLCBpZiBvbmUgc2Vzc2lvbiBpcyByZWFsbHkgYmFk IChzYXkgNTAlIHBhY2tldCBsb3NzKSwgdGhlIHN1YnNjcmliZXIgbWF5IG5lZWQgdG8gZG8gc29t ZSBhY3Rpb24vYWRqdXN0bWVudC4gWWVzDQogd2UgY2FuIHRvbGVyYXRlIGRhdGEgbG9zcywgYnV0 IEkgdGhpbmsgaXQgc2hvdWxkIGJlIGEgdGhyZXNob2xkLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhhbmtzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPuKAnHdoYXQg c2VlbXMgdG8gYmUgbWlzc2luZyBpcyBhbiBhYmlsaXR5IGZvciB0aGUgY2xpZW50IHRvIGRldGVy bWluZSB3aGljaCBnZW5lcmF0b3ItaWQgaXMgdXNlZCBieSB3aGljaCBwdWJsaXNoZXIgKGUuZy4s IGxpbmUgY2FyZCkuIOKAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JZiBuZWNlc3NhcnksIG1heWJlIHdl IGNhbiBleHRlbmQgdGhpcyBtYXBwaW5nIGluIHNvbWUgaW5pdGlhbCBleGNoYW5nZXMuIFRvIGJl IGNsZWFyLCBob3cgZG8geW91IHdhbnQgdG8gbmFtZSB0aGUgcHVibGlzaGVyPw0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPlRpYW5yYW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IG5l dGNvbmYgWzxhIGhyZWY9Im1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpu ZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5LZW50IFdh dHNlbjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBTZXB0ZW1iZXIgMjIsIDIwMjAgNjo1NSBB TTxicj4NCjxiPlRvOjwvYj4gQW5keSBCaWVybWFuICZsdDs8YSBocmVmPSJtYWlsdG86YW5keUB5 dW1hd29ya3MuY29tIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4g PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0Y29uZl0gQWRvcHRpb24tc3VpdGFiaWxpdHkgZm9y IGRyYWZ0LXVueXRlLW5ldGNvbmYtZGlzdHJpYnV0ZWQtbm90aWY8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W0FzIGFuIGluZGl2aWR1YWwgY29u dHJpYnV0b3JdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBvdmVyYWxsIGFwcHJvYWNoIHRv IHRoZSBiaW5hcnkgcHVzaCBmZWF0dXJlcyBzZWVtcyBhIGJpdCBpbmNvaGVyZW50IHRvIG1lLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj5JIGRvbid0IHNlZSBtdWNoIHZhbHVlIGluIHRoaXMgZHJhZnQs IGJ1dCBubyBoYXJtIGVpdGhlciBzbyBJIGRvIG5vdCBoYXZlIGFuIG9iamVjdGlvbjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj50byBhZG9wdGlvbi4mbmJzcDsgUGVyaGFwcyB0aGVyZSBpcyBzb21lIGRl YnVnZ2luZyB2YWx1ZSBoZXJlIGJ1dCBzaW5jZSB0aGUgYXJjaGl0ZWN0dXJlPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPnJlYWxseSBkb2VzIG5vdCBkZWZpbmUgbWVzc2FnZSBnZW5lcmF0b3JzIGFzIHN1 Yi1jb21wb25lbnRzIG9mIGEgY29uZmlndXJlZCBzdWJzY3JpcHRpb24sPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPmEgY2xpZW50IGNhbm5vdCBleHBlY3QgYW55IHNvcnQgb2YgY29uc2lzdGVudCBpbXBs ZW1lbnRhdGlvbiBvZiB0aGlzIGZpZWxkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkdvb2QgcG9pbnQuIElmIEkgdW5kZXJzdGFuZCB5b3UgY29ycmVjdGx5LCB3aGF0IHNlZW1z IHRvIGJlIG1pc3NpbmcgaXMgYW4gYWJpbGl0eSBmb3IgdGhlIGNsaWVudCB0byBkZXRlcm1pbmUg d2hpY2ggZ2VuZXJhdG9yLWlkIGlzIHVzZWQgYnkgd2hpY2ggcHVibGlzaGVyIChlLmcuLCBsaW5l IGNhcmQpLiAmbmJzcDtUaGUgc29sdXRpb24gZW5hYmxlcyB0aGUgY2xpZW50IHRvIHBhcnRpdGlv biBub3RpZmljYXRpb25zIGNvbWluZw0KIGZyb20gZGlmZmVyZW50IHB1Ymxpc2hlcnMsIGJ1dCB0 aGF0IGlzIGl0LiAmbmJzcDtXaGF0IHZhbHVlIGRvZXMgdGhpcyBoYXZlIHRvIHRoZSBjbGllbnQs IEkgZG9u4oCZdCBrbm93LiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5zd2VyaW5nIG15c2VsZiBoZXJlLCBwZXJoYXBzIGl0IGVu YWJsZXMgdHdvIHNlcnZlcnMgb24gdGhlIHNhbWUgSVAgYWRkcmVzcyB0byBzZW5kIHRvIHRoZSBz YW1lIHJlY2VpdmVyLCBhcyB0aGVuIHRoZSZuYnNwO3JlY2VpdmVyIGRvZXNu4oCZdCBzb2xlbHkg cmVseSBvbiBzb3VyY2UtSVAgYWRkcmVzcyAoYXNzdW1pbmcgdW5hdXRoZW50aWNhdGVkIHB1c2gp IHRvIGRlc2lnbmF0ZSB0aGUgcHVibGlzaGVyPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DYW4gdGhlIGF1dGhvcnMgaGVs cCByZXNvbHZlIHRoZSB2YWx1ZS1wcm9wb3NpdGlvbiBxdWVzdGlvbiBoZXJlPzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sy48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0Y29uZiBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dGNvbmYiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk1haGVz aCBKZXRoYW5hbmRhbmk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0 bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_444c48abc18e4539acd4229075b5fb77huaweicom_-- From nobody Wed Sep 23 07:44:32 2020 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 50CA23A1039 for ; Wed, 23 Sep 2020 07:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=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 JJwCsoDMKgSM for ; Wed, 23 Sep 2020 07:44:25 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 261B93A0E22 for ; Wed, 23 Sep 2020 07:44:25 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id y17so1266885plb.6 for ; Wed, 23 Sep 2020 07:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=if/nOdk29S2isdIblEhEflzqMn+4IV6GJnuzwe8qB7k=; b=plXBlYF2RPj+Fds3HoCqz4UkEboBmExlTRLz/xR5HTunvc1OuPODGj9F78zUSqX6un sPzz59EsIfUejVRcN6+AADlUGVIc9oEdyQfQP9QbtFBEC8TWV4tWPDOYNgaaEiXjhikV zqjZOUfDUbh7SGFe4SsLYnmRONPEj4eZOF62CzA6QlMkpZ8SgRvh/d2t9VMxbMu+cDoe uj6Z8otPhPgQSZLZzbyQH8W01etS4wAZBpnt2vgQaJelz+8879Hn1BVooEP+EboQJgao rTgRCbLKILLKmSc3a/X5cOqVirvDFtRx1AxmeUWnLYN8bed8v7kMcYlVV+vkU9bkSv4G bs7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=if/nOdk29S2isdIblEhEflzqMn+4IV6GJnuzwe8qB7k=; b=GnHBPD0ROQt2WbT8yTctu4pKtDu8CyWH5qZ68MEocprpbcBOm3YBVPa3fEZU0M/jSm su1l91xra/PfUukm06Am25K5RTo3/3JJUtLpWA2j3xZLO8o6MKG3SImutpxFrz4fFVb5 6KlfAsXp57NoHfoRv/8M04ToWbEakrOxXNlHpQcp3zlcxsf9H/P1hk8Ako3gBbVWs0oJ b6Sr8w7+xL0bKDodMx/f8Nrz99+NTwVfpLsiLo2na8w24MUM/rYEkKuXBgQ3sQxsVru0 4ZuIfg3L+xdlKnKui2uX1tUNx5oq74rE1oIKCN8JTKM5btwTqb6+1wfdx6e7pTumP2fR z0rA== X-Gm-Message-State: AOAM533tAaRBiV8BPJswsEMMS2qlhZ3iS/J6Jaod2QQ9LZCe4W4LQcLB Fi38/Z+o+ey7AUTuXpCnkpQjNp5h6LN6ZQ== X-Google-Smtp-Source: ABdhPJwSaRWKg+ZEvbRVRP0opbxI4yGQzu8ujJB3VY7dRLSWSRzjocyWYEDnY22vklem+O5Ddz0bHw== X-Received: by 2002:a17:90b:360a:: with SMTP id ml10mr8375197pjb.198.1600872264422; Wed, 23 Sep 2020 07:44:24 -0700 (PDT) Received: from [172.17.101.162] (66-76-170-6.com.sta.suddenlink.net. [66.76.170.6]) by smtp.gmail.com with ESMTPSA id m12sm5154411pjs.34.2020.09.23.07.44.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Sep 2020 07:44:23 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <52CC888C-2AA1-4ED2-9DD5-9C3994BC9D3E@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8A2AD6BE-D006-4429-B636-32BB58CD7B5C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 23 Sep 2020 07:44:22 -0700 In-Reply-To: <444c48abc18e4539acd4229075b5fb77@huawei.com> Cc: Kent Watsen , Andy Bierman , "netconf@ietf.org" To: Tianran Zhou References: <01000173c0b07b33-ad0b793a-7afc-4b39-95f8-2f50574d57bb-000000@us-east-1.amazonses.com> <01000174b2ba9c57-cbc0d353-8d30-4885-8769-1ea869b4d0be-000000@email.amazonses.com> <01000174b2e0a349-52337b7b-81c3-4c56-a58b-36c95d68340f-000000@email.amazonses.com> <5c058aa40cbf4141b32b19bd53514415@huawei.com> <444c48abc18e4539acd4229075b5fb77@huawei.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2020 14:44:31 -0000 --Apple-Mail=_8A2AD6BE-D006-4429-B636-32BB58CD7B5C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tianran, I think you are finally articulating some of the reasons why you need = the generator-id. But they have nothing to do with being able to do data = recovery. In 108, the discussion on the mike made it clear that there was no = expectation of data recovery if it got lost over the unreliable = transport. The characteristics of the data, e.g. statistics, over that = transport had to be such that subsequent updates would fill any gaps = that were encountered because of packet loss. If you stop receiving = updates on a particular session, you do not know if it was because the = line card has nothing to send or it has been removed.=20 So the reasons for having a generator-id have to do with identifying the = session or the line card where the data is originating from. The point = that Andy raised about ietf-hardware therefore is relevant here. What = happens if the line card is removed and replaced with another but = similar line card? What generator-id would be used? What happens if the = same line card is removed and reinserted? What generator-id would be = used? The draft needs to describe these as the problems it is solving, and how = it is going to solve it. > On Sep 22, 2020, at 11:51 PM, Tianran Zhou = wrote: >=20 > =20 > [As a contributor] > =20 > Hi Tianran, > =20 > I am confused by the value statement. Maybe you can help clarify. > =20 > It would help if we can use a single terminology of = publisher/subscriber instead of mixing it with client, which I = understand to be the subscriber and server which I understand to be the = publisher. Note, if HTTPS is used, the role of client and server would = be reversed, so it is best to avoid using those terms. > =20 > See inline with [mj]. >=20 >=20 > On Sep 21, 2020, at 7:04 PM, Tianran Zhou > wrote: > =20 > Thanks Andy for your opinion. And thank Kent for your expansion and = further question. > The goal is to allow the client to know if it has received all the = data pieces. Furthermore, the client know which publisher failed to send = data. Then it depend on the client to do the action, e.g., ignore, = require the data one more, =E2=80=A6 > We just use the generator-id to indicate the publisher, as we find it = in ietf-netconf-notification-messages, and it=E2=80=99s very convenient = for this usage. > =20 > [mj] What usage would be that? The usage of generator-id to indicate = who is the publisher and thereby have the subscriber request for any = missing data? I would like to note that nothing prevents usage of a = reliable transport, e.g. HTTPS or TCP, with this draft. Would you still = need a generator-id? > =20 > One use case is exactly as Kent mentioned =E2=80=9CAnswering myself = here, perhaps it enables two servers on the same IP address to send to = the same receiver, as then the receiver doesn=E2=80=99t solely rely on = source-IP address (assuming unauthenticated push) to designate the = publisher=E2=80=9D. > It=E2=80=99s also OK for us to use another indicator if the = generator-id is not feasible. > =20 > [mj] Precisely. If you use a reliable transport, you would have other = means to identify the source of the notifications, in which case you = would not need the generator-id. > =20 > ztr> Yes. But I just think if we can use the generator-id, we do not = need to develop different ways for each transport. So that the procedure = could be consistent. > =20 > Which goes back to the question of why we need a generator-id. If we = do not want data loss, we should be using a reliable transport, in which = case we do not need a generator-id. If we can tolerate data loss, e.g. = with statistics, we do not care for generator-id because we are not = going to ask for missing data. What use case requires us to use = unreliable transport and yet need a generator-id? > =20 > ztr> Here we want to check the integrity, not the precise packet loss. = For reliable transport, the receiver know how many sessions need to = establish for one subscription. On the other hand, if one session get = lost, which subscriptions are impacted. > For the unreliable transport, one more case is, if one session is = really bad (say 50% packet loss), the subscriber may need to do some = action/adjustment. Yes we can tolerate data loss, but I think it should = be a threshold.=20 > =20 > Thanks. >=20 >=20 > =E2=80=9Cwhat seems to be missing is an ability for the client to = determine which generator-id is used by which publisher (e.g., line = card). =E2=80=9D > If necessary, maybe we can extend this mapping in some initial = exchanges. To be clear, how do you want to name the publisher? > =20 > Thanks, > Tianran > =20 > From: netconf [mailto:netconf-bounces@ietf.org = ] On Behalf Of Kent Watsen > Sent: Tuesday, September 22, 2020 6:55 AM > To: Andy Bierman > > Cc: netconf@ietf.org > Subject: Re: [netconf] Adoption-suitability for = draft-unyte-netconf-distributed-notif > =20 > [As an individual contributor] > =20 > The overall approach to the binary push features seems a bit = incoherent to me. > I don't see much value in this draft, but no harm either so I do not = have an objection > to adoption. Perhaps there is some debugging value here but since the = architecture > really does not define message generators as sub-components of a = configured subscription, > a client cannot expect any sort of consistent implementation of this = field. > =20 > Good point. If I understand you correctly, what seems to be missing is = an ability for the client to determine which generator-id is used by = which publisher (e.g., line card). The solution enables the client to = partition notifications coming from different publishers, but that is = it. What value does this have to the client, I don=E2=80=99t know. =20 > =20 > Answering myself here, perhaps it enables two servers on the same IP = address to send to the same receiver, as then the receiver doesn=E2=80=99t= solely rely on source-IP address (assuming unauthenticated push) to = designate the publisher? >=20 >=20 >=20 > Can the authors help resolve the value-proposition question here? > =20 > K. > =20 > =20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf = > =20 > Mahesh Jethanandani > mjethanandani@gmail.com > =20 > =20 > =20 >=20 > =20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_8A2AD6BE-D006-4429-B636-32BB58CD7B5C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Tianran,

I think you = are finally articulating some of the reasons why you need the = generator-id. But they have nothing to do with being able to do data = recovery.

In = 108, the discussion on the mike made it clear that there was no = expectation of data recovery if it got lost over the unreliable = transport. The characteristics of the data, e.g. statistics, over that = transport had to be such that subsequent updates would fill any gaps = that were encountered because of packet loss. If you stop receiving = updates on a particular session, you do not know if it was because the = line card has nothing to send or it has been removed. 

So the reasons for = having a generator-id have to do with identifying the session or the = line card where the data is originating from. The point that Andy raised = about ietf-hardware therefore is relevant here. What happens if the line = card is removed and replaced with another but similar line card? What = generator-id would be used? What happens if the same line card is = removed and reinserted? What generator-id would be used?

The draft needs to = describe these as the problems it is solving, and how it is going to = solve it.

On Sep 22, 2020, at 11:51 PM, Tianran Zhou = <zhoutianran@huawei.com> wrote:

 
[As a contributor]
 
Hi = Tianran,
 
I am confused by the value statement. = Maybe you can help clarify.
 
It would help if we can use a single = terminology of publisher/subscriber instead of mixing it with client, = which I understand to be the subscriber and server which I understand to = be the publisher. Note, if HTTPS is used, the role of client and server = would be reversed, so it is best to avoid using those terms.
 
See inline = with [mj].


On Sep 21, 2020, at 7:04 PM, Tianran = Zhou <zhoutianran@huawei.com> wrote:
 
Thanks Andy for your opinion. And thank = Kent for your expansion and further question.
The goal is to allow = the client to know if it has received all the data pieces. Furthermore, = the client know which publisher failed to send data. Then it depend on = the client to do the action, e.g., ignore, require the data one more, = =E2=80=A6
We just use the = generator-id to indicate the publisher, as we find it in ietf-netconf-notification-messages, and it=E2=80=99s very = convenient for this usage.
 
[mj] What usage would be that? The usage of = generator-id to indicate who is the publisher and thereby have the = subscriber request for any missing data? I would like to note that = nothing prevents usage of a reliable transport, e.g. HTTPS or TCP, with = this draft. Would you still need a generator-id?
 
One use case is exactly = as Kent mentioned =E2=80=9CAnswering myself here, perhaps it enables two = servers on the same IP address to send to the same receiver, as then the = receiver doesn=E2=80=99t solely rely on source-IP address (assuming = unauthenticated push) to designate the publisher=E2=80=9D.
It=E2=80=99s also OK = for us to use another indicator if the generator-id is not = feasible.
 
[mj] Precisely. If you use a reliable transport, you = would have other means to identify the source of the notifications, in = which case you would not need the generator-id.
 
ztr> Yes. But I just think if we can use the generator-id, = we do not need to develop different ways for each transport. So that the = procedure could be consistent.
 
Which goes = back to the question of why we need a generator-id. If we do not want = data loss, we should be using a reliable transport, in which case we do = not need a generator-id. If we can tolerate data loss, e.g. with = statistics, we do not care for generator-id because we are not going to = ask for missing data. What use case requires us to use unreliable = transport and yet need a generator-id?
 
ztr> Here we want to check the integrity, not the precise = packet loss. For reliable transport, the receiver know how many sessions = need to establish for one subscription. On the other hand,  if one = session get lost, which subscriptions are impacted.
For the unreliable = transport, one more case is, if one session is really bad (say 50% = packet loss), the subscriber may need to do some action/adjustment. Yes = we can tolerate data loss, but I think it should be a threshold. 
 
Thanks.


=E2=80=9Cwhat seems to be missing is an ability for the = client to determine which generator-id is used by which publisher (e.g., = line card). =E2=80=9D
If necessary, maybe we can extend this mapping in some = initial exchanges. To be clear, how do you want to name the = publisher?
 
Thanks,
Tianran
 
From: netconf = [mailto:netconf-bounces@ietf.org] On Behalf = Of Kent Watsen
Sent: Tuesday, September 22, 2020 = 6:55 AM
To: Andy Bierman <andy@yumaworks.com>
Cc: netconf@ietf.org
Subject: Re: [netconf] = Adoption-suitability for = draft-unyte-netconf-distributed-notif
 
[As an individual = contributor]
 
The overall = approach to the binary push features seems a bit incoherent to = me.
I don't see much = value in this draft, but no harm either so I do not have an = objection
to = adoption.  Perhaps there is some debugging value here but since the = architecture
really does not = define message generators as sub-components of a configured = subscription,
a client cannot = expect any sort of consistent implementation of this field.
 
Good point. If I understand you correctly, what seems = to be missing is an ability for the client to determine which = generator-id is used by which publisher (e.g., line card).  The = solution enables the client to partition notifications coming from = different publishers, but that is it.  What value does this have to = the client, I don=E2=80=99t know.  
 
Answering = myself here, perhaps it enables two servers on the same IP address to = send to the same receiver, as then the receiver doesn=E2=80=99t = solely rely on source-IP address (assuming unauthenticated push) to = designate the publisher?



Can the authors help resolve the value-proposition = question here?
 
K.
 
 
_______________________________________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf
 
Mahesh Jethanandani
mjethanandani@gmail.com
 
 

 

 
Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_8A2AD6BE-D006-4429-B636-32BB58CD7B5C-- From nobody Wed Sep 23 23:27:25 2020 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 A9C8F3A041B for ; Wed, 23 Sep 2020 23:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 QGwLoXRyQ99O for ; Wed, 23 Sep 2020 23:27:20 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 D68E83A0417 for ; Wed, 23 Sep 2020 23:27:19 -0700 (PDT) Received: from lhreml704-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 88ED58AD3D4C90DB1159; Thu, 24 Sep 2020 07:27:18 +0100 (IST) Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Thu, 24 Sep 2020 07:27:17 +0100 Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml707-chm.china.huawei.com (10.98.57.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 24 Sep 2020 14:27:15 +0800 Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Thu, 24 Sep 2020 14:27:15 +0800 From: Tianran Zhou To: Mahesh Jethanandani CC: Kent Watsen , Andy Bierman , "netconf@ietf.org" Thread-Topic: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif Thread-Index: AQHWa3XT/yp90Vv9H0i3R7lOe+hPQ6kxPqwAgAEGkBCAQSaZAIAABOyAgAAGrgCAALMIwIAAXYMAgAGGTKCAAAS+AIABjMTQ Date: Thu, 24 Sep 2020 06:27:15 +0000 Message-ID: <92ca069f090c42baba11a980682ea105@huawei.com> References: <01000173c0b07b33-ad0b793a-7afc-4b39-95f8-2f50574d57bb-000000@us-east-1.amazonses.com> <01000174b2ba9c57-cbc0d353-8d30-4885-8769-1ea869b4d0be-000000@email.amazonses.com> <01000174b2e0a349-52337b7b-81c3-4c56-a58b-36c95d68340f-000000@email.amazonses.com> <5c058aa40cbf4141b32b19bd53514415@huawei.com> <444c48abc18e4539acd4229075b5fb77@huawei.com> <52CC888C-2AA1-4ED2-9DD5-9C3994BC9D3E@gmail.com> In-Reply-To: <52CC888C-2AA1-4ED2-9DD5-9C3994BC9D3E@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.243.128] Content-Type: multipart/alternative; boundary="_000_92ca069f090c42baba11a980682ea105huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 06:27:23 -0000 --_000_92ca069f090c42baba11a980682ea105huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFoZXNoLA0KDQpZb3VyIHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdC4gU29ycnkgZm9yIG5v dCBtYWtpbmcgaXQgY2xlYXIuDQpUaGFua3MgZm9yIHlvdXIgYWR2aWNlLiBXZSB3aWxsIHdvcmsg b24gdGhlIHRleHQgYXMgeW91IHN1Z2dlc3RlZCBpbiB0aGUgd29ya2luZyB2ZXJzaW9uLg0KDQpD aGVlcnMsDQpUaWFucmFuDQoNCkZyb206IE1haGVzaCBKZXRoYW5hbmRhbmkgW21haWx0bzptamV0 aGFuYW5kYW5pQGdtYWlsLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDIzLCAyMDIw IDEwOjQ0IFBNDQpUbzogVGlhbnJhbiBaaG91IDx6aG91dGlhbnJhbkBodWF3ZWkuY29tPg0KQ2M6 IEtlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD47IEFuZHkgQmllcm1hbiA8YW5keUB5 dW1hd29ya3MuY29tPjsgbmV0Y29uZkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRjb25mXSBB ZG9wdGlvbi1zdWl0YWJpbGl0eSBmb3IgZHJhZnQtdW55dGUtbmV0Y29uZi1kaXN0cmlidXRlZC1u b3RpZg0KDQpIaSBUaWFucmFuLA0KDQpJIHRoaW5rIHlvdSBhcmUgZmluYWxseSBhcnRpY3VsYXRp bmcgc29tZSBvZiB0aGUgcmVhc29ucyB3aHkgeW91IG5lZWQgdGhlIGdlbmVyYXRvci1pZC4gQnV0 IHRoZXkgaGF2ZSBub3RoaW5nIHRvIGRvIHdpdGggYmVpbmcgYWJsZSB0byBkbyBkYXRhIHJlY292 ZXJ5Lg0KDQpJbiAxMDgsIHRoZSBkaXNjdXNzaW9uIG9uIHRoZSBtaWtlIG1hZGUgaXQgY2xlYXIg dGhhdCB0aGVyZSB3YXMgbm8gZXhwZWN0YXRpb24gb2YgZGF0YSByZWNvdmVyeSBpZiBpdCBnb3Qg bG9zdCBvdmVyIHRoZSB1bnJlbGlhYmxlIHRyYW5zcG9ydC4gVGhlIGNoYXJhY3RlcmlzdGljcyBv ZiB0aGUgZGF0YSwgZS5nLiBzdGF0aXN0aWNzLCBvdmVyIHRoYXQgdHJhbnNwb3J0IGhhZCB0byBi ZSBzdWNoIHRoYXQgc3Vic2VxdWVudCB1cGRhdGVzIHdvdWxkIGZpbGwgYW55IGdhcHMgdGhhdCB3 ZXJlIGVuY291bnRlcmVkIGJlY2F1c2Ugb2YgcGFja2V0IGxvc3MuIElmIHlvdSBzdG9wIHJlY2Vp dmluZyB1cGRhdGVzIG9uIGEgcGFydGljdWxhciBzZXNzaW9uLCB5b3UgZG8gbm90IGtub3cgaWYg aXQgd2FzIGJlY2F1c2UgdGhlIGxpbmUgY2FyZCBoYXMgbm90aGluZyB0byBzZW5kIG9yIGl0IGhh cyBiZWVuIHJlbW92ZWQuDQoNClNvIHRoZSByZWFzb25zIGZvciBoYXZpbmcgYSBnZW5lcmF0b3It aWQgaGF2ZSB0byBkbyB3aXRoIGlkZW50aWZ5aW5nIHRoZSBzZXNzaW9uIG9yIHRoZSBsaW5lIGNh cmQgd2hlcmUgdGhlIGRhdGEgaXMgb3JpZ2luYXRpbmcgZnJvbS4gVGhlIHBvaW50IHRoYXQgQW5k eSByYWlzZWQgYWJvdXQgaWV0Zi1oYXJkd2FyZSB0aGVyZWZvcmUgaXMgcmVsZXZhbnQgaGVyZS4g V2hhdCBoYXBwZW5zIGlmIHRoZSBsaW5lIGNhcmQgaXMgcmVtb3ZlZCBhbmQgcmVwbGFjZWQgd2l0 aCBhbm90aGVyIGJ1dCBzaW1pbGFyIGxpbmUgY2FyZD8gV2hhdCBnZW5lcmF0b3ItaWQgd291bGQg YmUgdXNlZD8gV2hhdCBoYXBwZW5zIGlmIHRoZSBzYW1lIGxpbmUgY2FyZCBpcyByZW1vdmVkIGFu ZCByZWluc2VydGVkPyBXaGF0IGdlbmVyYXRvci1pZCB3b3VsZCBiZSB1c2VkPw0KDQpUaGUgZHJh ZnQgbmVlZHMgdG8gZGVzY3JpYmUgdGhlc2UgYXMgdGhlIHByb2JsZW1zIGl0IGlzIHNvbHZpbmcs IGFuZCBob3cgaXQgaXMgZ29pbmcgdG8gc29sdmUgaXQuDQoNCg0KT24gU2VwIDIyLCAyMDIwLCBh dCAxMTo1MSBQTSwgVGlhbnJhbiBaaG91IDx6aG91dGlhbnJhbkBodWF3ZWkuY29tPG1haWx0bzp6 aG91dGlhbnJhbkBodWF3ZWkuY29tPj4gd3JvdGU6DQoNCg0KW0FzIGEgY29udHJpYnV0b3JdDQoN CkhpIFRpYW5yYW4sDQoNCkkgYW0gY29uZnVzZWQgYnkgdGhlIHZhbHVlIHN0YXRlbWVudC4gTWF5 YmUgeW91IGNhbiBoZWxwIGNsYXJpZnkuDQoNCkl0IHdvdWxkIGhlbHAgaWYgd2UgY2FuIHVzZSBh IHNpbmdsZSB0ZXJtaW5vbG9neSBvZiBwdWJsaXNoZXIvc3Vic2NyaWJlciBpbnN0ZWFkIG9mIG1p eGluZyBpdCB3aXRoIGNsaWVudCwgd2hpY2ggSSB1bmRlcnN0YW5kIHRvIGJlIHRoZSBzdWJzY3Jp YmVyIGFuZCBzZXJ2ZXIgd2hpY2ggSSB1bmRlcnN0YW5kIHRvIGJlIHRoZSBwdWJsaXNoZXIuIE5v dGUsIGlmIEhUVFBTIGlzIHVzZWQsIHRoZSByb2xlIG9mIGNsaWVudCBhbmQgc2VydmVyIHdvdWxk IGJlIHJldmVyc2VkLCBzbyBpdCBpcyBiZXN0IHRvIGF2b2lkIHVzaW5nIHRob3NlIHRlcm1zLg0K DQpTZWUgaW5saW5lIHdpdGggW21qXS4NCg0KDQoNCk9uIFNlcCAyMSwgMjAyMCwgYXQgNzowNCBQ TSwgVGlhbnJhbiBaaG91IDx6aG91dGlhbnJhbkBodWF3ZWkuY29tPG1haWx0bzp6aG91dGlhbnJh bkBodWF3ZWkuY29tPj4gd3JvdGU6DQoNClRoYW5rcyBBbmR5IGZvciB5b3VyIG9waW5pb24uIEFu ZCB0aGFuayBLZW50IGZvciB5b3VyIGV4cGFuc2lvbiBhbmQgZnVydGhlciBxdWVzdGlvbi4NClRo ZSBnb2FsIGlzIHRvIGFsbG93IHRoZSBjbGllbnQgdG8ga25vdyBpZiBpdCBoYXMgcmVjZWl2ZWQg YWxsIHRoZSBkYXRhIHBpZWNlcy4gRnVydGhlcm1vcmUsIHRoZSBjbGllbnQga25vdyB3aGljaCBw dWJsaXNoZXIgZmFpbGVkIHRvIHNlbmQgZGF0YS4gVGhlbiBpdCBkZXBlbmQgb24gdGhlIGNsaWVu dCB0byBkbyB0aGUgYWN0aW9uLCBlLmcuLCBpZ25vcmUsIHJlcXVpcmUgdGhlIGRhdGEgb25lIG1v cmUsIOKApg0KV2UganVzdCB1c2UgdGhlIGdlbmVyYXRvci1pZCB0byBpbmRpY2F0ZSB0aGUgcHVi bGlzaGVyLCBhcyB3ZSBmaW5kIGl0IGluIGlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2Fn ZXMsIGFuZCBpdOKAmXMgdmVyeSBjb252ZW5pZW50IGZvciB0aGlzIHVzYWdlLg0KDQpbbWpdIFdo YXQgdXNhZ2Ugd291bGQgYmUgdGhhdD8gVGhlIHVzYWdlIG9mIGdlbmVyYXRvci1pZCB0byBpbmRp Y2F0ZSB3aG8gaXMgdGhlIHB1Ymxpc2hlciBhbmQgdGhlcmVieSBoYXZlIHRoZSBzdWJzY3JpYmVy IHJlcXVlc3QgZm9yIGFueSBtaXNzaW5nIGRhdGE/IEkgd291bGQgbGlrZSB0byBub3RlIHRoYXQg bm90aGluZyBwcmV2ZW50cyB1c2FnZSBvZiBhIHJlbGlhYmxlIHRyYW5zcG9ydCwgZS5nLiBIVFRQ UyBvciBUQ1AsIHdpdGggdGhpcyBkcmFmdC4gV291bGQgeW91IHN0aWxsIG5lZWQgYSBnZW5lcmF0 b3ItaWQ/DQoNCk9uZSB1c2UgY2FzZSBpcyBleGFjdGx5IGFzIEtlbnQgbWVudGlvbmVkIOKAnEFu c3dlcmluZyBteXNlbGYgaGVyZSwgcGVyaGFwcyBpdCBlbmFibGVzIHR3byBzZXJ2ZXJzIG9uIHRo ZSBzYW1lIElQIGFkZHJlc3MgdG8gc2VuZCB0byB0aGUgc2FtZSByZWNlaXZlciwgYXMgdGhlbiB0 aGUgcmVjZWl2ZXIgZG9lc27igJl0IHNvbGVseSByZWx5IG9uIHNvdXJjZS1JUCBhZGRyZXNzIChh c3N1bWluZyB1bmF1dGhlbnRpY2F0ZWQgcHVzaCkgdG8gZGVzaWduYXRlIHRoZSBwdWJsaXNoZXLi gJ0uDQpJdOKAmXMgYWxzbyBPSyBmb3IgdXMgdG8gdXNlIGFub3RoZXIgaW5kaWNhdG9yIGlmIHRo ZSBnZW5lcmF0b3ItaWQgaXMgbm90IGZlYXNpYmxlLg0KDQpbbWpdIFByZWNpc2VseS4gSWYgeW91 IHVzZSBhIHJlbGlhYmxlIHRyYW5zcG9ydCwgeW91IHdvdWxkIGhhdmUgb3RoZXIgbWVhbnMgdG8g aWRlbnRpZnkgdGhlIHNvdXJjZSBvZiB0aGUgbm90aWZpY2F0aW9ucywgaW4gd2hpY2ggY2FzZSB5 b3Ugd291bGQgbm90IG5lZWQgdGhlIGdlbmVyYXRvci1pZC4NCg0KenRyPiBZZXMuIEJ1dCBJIGp1 c3QgdGhpbmsgaWYgd2UgY2FuIHVzZSB0aGUgZ2VuZXJhdG9yLWlkLCB3ZSBkbyBub3QgbmVlZCB0 byBkZXZlbG9wIGRpZmZlcmVudCB3YXlzIGZvciBlYWNoIHRyYW5zcG9ydC4gU28gdGhhdCB0aGUg cHJvY2VkdXJlIGNvdWxkIGJlIGNvbnNpc3RlbnQuDQoNCldoaWNoIGdvZXMgYmFjayB0byB0aGUg cXVlc3Rpb24gb2Ygd2h5IHdlIG5lZWQgYSBnZW5lcmF0b3ItaWQuIElmIHdlIGRvIG5vdCB3YW50 IGRhdGEgbG9zcywgd2Ugc2hvdWxkIGJlIHVzaW5nIGEgcmVsaWFibGUgdHJhbnNwb3J0LCBpbiB3 aGljaCBjYXNlIHdlIGRvIG5vdCBuZWVkIGEgZ2VuZXJhdG9yLWlkLiBJZiB3ZSBjYW4gdG9sZXJh dGUgZGF0YSBsb3NzLCBlLmcuIHdpdGggc3RhdGlzdGljcywgd2UgZG8gbm90IGNhcmUgZm9yIGdl bmVyYXRvci1pZCBiZWNhdXNlIHdlIGFyZSBub3QgZ29pbmcgdG8gYXNrIGZvciBtaXNzaW5nIGRh dGEuIFdoYXQgdXNlIGNhc2UgcmVxdWlyZXMgdXMgdG8gdXNlIHVucmVsaWFibGUgdHJhbnNwb3J0 IGFuZCB5ZXQgbmVlZCBhIGdlbmVyYXRvci1pZD8NCg0KenRyPiBIZXJlIHdlIHdhbnQgdG8gY2hl Y2sgdGhlIGludGVncml0eSwgbm90IHRoZSBwcmVjaXNlIHBhY2tldCBsb3NzLiBGb3IgcmVsaWFi bGUgdHJhbnNwb3J0LCB0aGUgcmVjZWl2ZXIga25vdyBob3cgbWFueSBzZXNzaW9ucyBuZWVkIHRv IGVzdGFibGlzaCBmb3Igb25lIHN1YnNjcmlwdGlvbi4gT24gdGhlIG90aGVyIGhhbmQsICBpZiBv bmUgc2Vzc2lvbiBnZXQgbG9zdCwgd2hpY2ggc3Vic2NyaXB0aW9ucyBhcmUgaW1wYWN0ZWQuDQpG b3IgdGhlIHVucmVsaWFibGUgdHJhbnNwb3J0LCBvbmUgbW9yZSBjYXNlIGlzLCBpZiBvbmUgc2Vz c2lvbiBpcyByZWFsbHkgYmFkIChzYXkgNTAlIHBhY2tldCBsb3NzKSwgdGhlIHN1YnNjcmliZXIg bWF5IG5lZWQgdG8gZG8gc29tZSBhY3Rpb24vYWRqdXN0bWVudC4gWWVzIHdlIGNhbiB0b2xlcmF0 ZSBkYXRhIGxvc3MsIGJ1dCBJIHRoaW5rIGl0IHNob3VsZCBiZSBhIHRocmVzaG9sZC4NCg0KVGhh bmtzLg0KDQoNCg0K4oCcd2hhdCBzZWVtcyB0byBiZSBtaXNzaW5nIGlzIGFuIGFiaWxpdHkgZm9y IHRoZSBjbGllbnQgdG8gZGV0ZXJtaW5lIHdoaWNoIGdlbmVyYXRvci1pZCBpcyB1c2VkIGJ5IHdo aWNoIHB1Ymxpc2hlciAoZS5nLiwgbGluZSBjYXJkKS4g4oCdDQpJZiBuZWNlc3NhcnksIG1heWJl IHdlIGNhbiBleHRlbmQgdGhpcyBtYXBwaW5nIGluIHNvbWUgaW5pdGlhbCBleGNoYW5nZXMuIFRv IGJlIGNsZWFyLCBob3cgZG8geW91IHdhbnQgdG8gbmFtZSB0aGUgcHVibGlzaGVyPw0KDQpUaGFu a3MsDQpUaWFucmFuDQoNCkZyb206IG5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBLZW50IFdhdHNlbg0KU2VudDogVHVlc2RheSwgU2VwdGVtYmVy IDIyLCAyMDIwIDY6NTUgQU0NClRvOiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbTxt YWlsdG86YW5keUB5dW1hd29ya3MuY29tPj4NCkNjOiBuZXRjb25mQGlldGYub3JnPG1haWx0bzpu ZXRjb25mQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtuZXRjb25mXSBBZG9wdGlvbi1zdWl0YWJp bGl0eSBmb3IgZHJhZnQtdW55dGUtbmV0Y29uZi1kaXN0cmlidXRlZC1ub3RpZg0KDQpbQXMgYW4g aW5kaXZpZHVhbCBjb250cmlidXRvcl0NCg0KVGhlIG92ZXJhbGwgYXBwcm9hY2ggdG8gdGhlIGJp bmFyeSBwdXNoIGZlYXR1cmVzIHNlZW1zIGEgYml0IGluY29oZXJlbnQgdG8gbWUuDQpJIGRvbid0 IHNlZSBtdWNoIHZhbHVlIGluIHRoaXMgZHJhZnQsIGJ1dCBubyBoYXJtIGVpdGhlciBzbyBJIGRv IG5vdCBoYXZlIGFuIG9iamVjdGlvbg0KdG8gYWRvcHRpb24uICBQZXJoYXBzIHRoZXJlIGlzIHNv bWUgZGVidWdnaW5nIHZhbHVlIGhlcmUgYnV0IHNpbmNlIHRoZSBhcmNoaXRlY3R1cmUNCnJlYWxs eSBkb2VzIG5vdCBkZWZpbmUgbWVzc2FnZSBnZW5lcmF0b3JzIGFzIHN1Yi1jb21wb25lbnRzIG9m IGEgY29uZmlndXJlZCBzdWJzY3JpcHRpb24sDQphIGNsaWVudCBjYW5ub3QgZXhwZWN0IGFueSBz b3J0IG9mIGNvbnNpc3RlbnQgaW1wbGVtZW50YXRpb24gb2YgdGhpcyBmaWVsZC4NCg0KR29vZCBw b2ludC4gSWYgSSB1bmRlcnN0YW5kIHlvdSBjb3JyZWN0bHksIHdoYXQgc2VlbXMgdG8gYmUgbWlz c2luZyBpcyBhbiBhYmlsaXR5IGZvciB0aGUgY2xpZW50IHRvIGRldGVybWluZSB3aGljaCBnZW5l cmF0b3ItaWQgaXMgdXNlZCBieSB3aGljaCBwdWJsaXNoZXIgKGUuZy4sIGxpbmUgY2FyZCkuICBU aGUgc29sdXRpb24gZW5hYmxlcyB0aGUgY2xpZW50IHRvIHBhcnRpdGlvbiBub3RpZmljYXRpb25z IGNvbWluZyBmcm9tIGRpZmZlcmVudCBwdWJsaXNoZXJzLCBidXQgdGhhdCBpcyBpdC4gIFdoYXQg dmFsdWUgZG9lcyB0aGlzIGhhdmUgdG8gdGhlIGNsaWVudCwgSSBkb27igJl0IGtub3cuDQoNCkFu c3dlcmluZyBteXNlbGYgaGVyZSwgcGVyaGFwcyBpdCBlbmFibGVzIHR3byBzZXJ2ZXJzIG9uIHRo ZSBzYW1lIElQIGFkZHJlc3MgdG8gc2VuZCB0byB0aGUgc2FtZSByZWNlaXZlciwgYXMgdGhlbiB0 aGUgcmVjZWl2ZXIgZG9lc27igJl0IHNvbGVseSByZWx5IG9uIHNvdXJjZS1JUCBhZGRyZXNzIChh c3N1bWluZyB1bmF1dGhlbnRpY2F0ZWQgcHVzaCkgdG8gZGVzaWduYXRlIHRoZSBwdWJsaXNoZXI/ DQoNCg0KDQoNCkNhbiB0aGUgYXV0aG9ycyBoZWxwIHJlc29sdmUgdGhlIHZhbHVlLXByb3Bvc2l0 aW9uIHF1ZXN0aW9uIGhlcmU/DQoNCksuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCm5ldGNvbmYgbWFpbGluZyBsaXN0DQpuZXRjb25mQGlldGYu b3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRjb25mDQoNCk1haGVzaCBKZXRoYW5hbmRhbmkNCm1qZXRoYW5hbmRhbmlA Z21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCg0KDQoNCg0KDQpNYWhl c2ggSmV0aGFuYW5kYW5pDQptamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpldGhhbmFu ZGFuaUBnbWFpbC5jb20+DQoNCg0KDQoNCg== --_000_92ca069f090c42baba11a980682ea105huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1z dHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5 MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkhpIE1haGVzaCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPllvdXIgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LiBTb3JyeSBmb3Ig bm90IG1ha2luZyBpdCBjbGVhci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB5b3VyIGFk dmljZS4gV2Ugd2lsbCB3b3JrIG9uIHRoZSB0ZXh0IGFzIHlvdSBzdWdnZXN0ZWQgaW4gdGhlIHdv cmtpbmcgdmVyc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGlhbnJhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4gTWFoZXNoIEpldGhhbmFuZGFuaSBbbWFpbHRvOm1qZXRoYW5h bmRhbmlAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgU2VwdGVtYmVy IDIzLCAyMDIwIDEwOjQ0IFBNPGJyPg0KPGI+VG86PC9iPiBUaWFucmFuIFpob3UgJmx0O3pob3V0 aWFucmFuQGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBLZW50IFdhdHNlbiAmbHQ7a2Vu dCYjNDM7aWV0ZkB3YXRzZW4ubmV0Jmd0OzsgQW5keSBCaWVybWFuICZsdDthbmR5QHl1bWF3b3Jr cy5jb20mZ3Q7OyBuZXRjb25mQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0 Y29uZl0gQWRvcHRpb24tc3VpdGFiaWxpdHkgZm9yIGRyYWZ0LXVueXRlLW5ldGNvbmYtZGlzdHJp YnV0ZWQtbm90aWY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IaSBUaWFucmFuLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSB0aGluayB5b3UgYXJlIGZpbmFsbHkgYXJ0aWN1bGF0aW5nIHNvbWUgb2YgdGhlIHJlYXNv bnMgd2h5IHlvdSBuZWVkIHRoZSBnZW5lcmF0b3ItaWQuIEJ1dCB0aGV5IGhhdmUgbm90aGluZyB0 byBkbyB3aXRoIGJlaW5nIGFibGUgdG8gZG8gZGF0YSByZWNvdmVyeS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gMTA4LCB0aGUgZGlzY3Vz c2lvbiBvbiB0aGUgbWlrZSBtYWRlIGl0IGNsZWFyIHRoYXQgdGhlcmUgd2FzIG5vIGV4cGVjdGF0 aW9uIG9mIGRhdGEgcmVjb3ZlcnkgaWYgaXQgZ290IGxvc3Qgb3ZlciB0aGUgdW5yZWxpYWJsZSB0 cmFuc3BvcnQuIFRoZSBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIGRhdGEsIGUuZy4gc3RhdGlzdGlj cywgb3ZlciB0aGF0IHRyYW5zcG9ydCBoYWQgdG8gYmUgc3VjaCB0aGF0IHN1YnNlcXVlbnQNCiB1 cGRhdGVzIHdvdWxkIGZpbGwgYW55IGdhcHMgdGhhdCB3ZXJlIGVuY291bnRlcmVkIGJlY2F1c2Ug b2YgcGFja2V0IGxvc3MuIElmIHlvdSBzdG9wIHJlY2VpdmluZyB1cGRhdGVzIG9uIGEgcGFydGlj dWxhciBzZXNzaW9uLCB5b3UgZG8gbm90IGtub3cgaWYgaXQgd2FzIGJlY2F1c2UgdGhlIGxpbmUg Y2FyZCBoYXMgbm90aGluZyB0byBzZW5kIG9yIGl0IGhhcyBiZWVuIHJlbW92ZWQuJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIHRo ZSByZWFzb25zIGZvciBoYXZpbmcgYSBnZW5lcmF0b3ItaWQgaGF2ZSB0byBkbyB3aXRoIGlkZW50 aWZ5aW5nIHRoZSBzZXNzaW9uIG9yIHRoZSBsaW5lIGNhcmQgd2hlcmUgdGhlIGRhdGEgaXMgb3Jp Z2luYXRpbmcgZnJvbS4gVGhlIHBvaW50IHRoYXQgQW5keSByYWlzZWQgYWJvdXQgaWV0Zi1oYXJk d2FyZSB0aGVyZWZvcmUgaXMgcmVsZXZhbnQgaGVyZS4gV2hhdCBoYXBwZW5zIGlmIHRoZSBsaW5l IGNhcmQNCiBpcyByZW1vdmVkIGFuZCByZXBsYWNlZCB3aXRoIGFub3RoZXIgYnV0IHNpbWlsYXIg bGluZSBjYXJkPyBXaGF0IGdlbmVyYXRvci1pZCB3b3VsZCBiZSB1c2VkPyBXaGF0IGhhcHBlbnMg aWYgdGhlIHNhbWUgbGluZSBjYXJkIGlzIHJlbW92ZWQgYW5kIHJlaW5zZXJ0ZWQ/IFdoYXQgZ2Vu ZXJhdG9yLWlkIHdvdWxkIGJlIHVzZWQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBkcmFmdCBuZWVkcyB0byBkZXNjcmliZSB0aGVzZSBh cyB0aGUgcHJvYmxlbXMgaXQgaXMgc29sdmluZywgYW5kIGhvdyBpdCBpcyBnb2luZyB0byBzb2x2 ZSBpdC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFNl cCAyMiwgMjAyMCwgYXQgMTE6NTEgUE0sIFRpYW5yYW4gWmhvdSAmbHQ7PGEgaHJlZj0ibWFpbHRv Onpob3V0aWFucmFuQGh1YXdlaS5jb20iPnpob3V0aWFucmFuQGh1YXdlaS5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPltBcyBhIGNvbnRyaWJ1dG9yXTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGkgVGlhbnJhbiw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gY29uZnVzZWQgYnkgdGhlIHZh bHVlIHN0YXRlbWVudC4gTWF5YmUgeW91IGNhbiBoZWxwIGNsYXJpZnkuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkl0IHdvdWxkIGhlbHAgaWYgd2UgY2FuIHVzZSBhIHNpbmdsZSB0ZXJtaW5v bG9neSBvZiBwdWJsaXNoZXIvc3Vic2NyaWJlciBpbnN0ZWFkIG9mIG1peGluZyBpdCB3aXRoIGNs aWVudCwgd2hpY2ggSSB1bmRlcnN0YW5kIHRvIGJlIHRoZSBzdWJzY3JpYmVyIGFuZCBzZXJ2ZXIg d2hpY2ggSSB1bmRlcnN0YW5kIHRvIGJlIHRoZSBwdWJsaXNoZXIuIE5vdGUsIGlmIEhUVFBTIGlz IHVzZWQsIHRoZSByb2xlIG9mIGNsaWVudA0KIGFuZCBzZXJ2ZXIgd291bGQgYmUgcmV2ZXJzZWQs IHNvIGl0IGlzIGJlc3QgdG8gYXZvaWQgdXNpbmcgdGhvc2UgdGVybXMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlNlZSBpbmxpbmUgd2l0aCBbbWpdLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gU2VwIDIxLCAyMDIwLCBhdCA3OjA0IFBNLCBUaWFucmFuIFpob3UgJmx0OzxhIGhyZWY9 Im1haWx0bzp6aG91dGlhbnJhbkBodWF3ZWkuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3 MiI+emhvdXRpYW5yYW5AaHVhd2VpLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgQW5keSBmb3Ig eW91ciBvcGluaW9uLiBBbmQgdGhhbmsgS2VudCBmb3IgeW91ciBleHBhbnNpb24gYW5kIGZ1cnRo ZXIgcXVlc3Rpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBnb2FsIGlz IHRvIGFsbG93IHRoZSBjbGllbnQgdG8ga25vdyBpZiBpdCBoYXMgcmVjZWl2ZWQgYWxsIHRoZSBk YXRhIHBpZWNlcy4gRnVydGhlcm1vcmUsIHRoZSBjbGllbnQga25vdyB3aGljaCBwdWJsaXNoZXIg ZmFpbGVkIHRvIHNlbmQgZGF0YS4gVGhlbiBpdCBkZXBlbmQNCiBvbiB0aGUgY2xpZW50IHRvIGRv IHRoZSBhY3Rpb24sIGUuZy4sIGlnbm9yZSwgcmVxdWlyZSB0aGUgZGF0YSBvbmUgbW9yZSwg4oCm PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldlIGp1c3QgdXNlIHRoZSBnZW5lcmF0 b3ItaWQgdG8gaW5kaWNhdGUgdGhlIHB1Ymxpc2hlciwgYXMgd2UgZmluZCBpdCBpbjwvc3Bhbj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tbWVzc2FnZXMs DQogYW5kIGl04oCZcyB2ZXJ5IGNvbnZlbmllbnQgZm9yIHRoaXMgdXNhZ2UuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W21qXSBXaGF0IHVzYWdlIHdv dWxkIGJlIHRoYXQ/IFRoZSB1c2FnZSBvZiBnZW5lcmF0b3ItaWQgdG8gaW5kaWNhdGUgd2hvIGlz IHRoZSBwdWJsaXNoZXIgYW5kIHRoZXJlYnkgaGF2ZSB0aGUgc3Vic2NyaWJlciByZXF1ZXN0IGZv ciBhbnkgbWlzc2luZyBkYXRhPyBJIHdvdWxkIGxpa2UgdG8gbm90ZSB0aGF0IG5vdGhpbmcgcHJl dmVudHMgdXNhZ2Ugb2YgYSByZWxpYWJsZSB0cmFuc3BvcnQsIGUuZy4gSFRUUFMNCiBvciBUQ1As IHdpdGggdGhpcyBkcmFmdC4gV291bGQgeW91IHN0aWxsIG5lZWQgYSBnZW5lcmF0b3ItaWQ/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ T25lIHVzZSBjYXNlIGlzIGV4YWN0bHkgYXMgS2VudCBtZW50aW9uZWQg4oCcQW5zd2VyaW5nIG15 c2VsZiBoZXJlLCBwZXJoYXBzIGl0IGVuYWJsZXMgdHdvIHNlcnZlcnMgb24gdGhlIHNhbWUgSVAg YWRkcmVzcyB0byBzZW5kIHRvIHRoZSBzYW1lIHJlY2VpdmVyLCBhcyB0aGVuDQogdGhlIHJlY2Vp dmVyIGRvZXNu4oCZdCBzb2xlbHkgcmVseSBvbiBzb3VyY2UtSVAgYWRkcmVzcyAoYXNzdW1pbmcg dW5hdXRoZW50aWNhdGVkIHB1c2gpIHRvIGRlc2lnbmF0ZSB0aGUgcHVibGlzaGVy4oCdLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JdOKAmXMgYWxzbyBPSyBmb3IgdXMgdG8gdXNl IGFub3RoZXIgaW5kaWNhdG9yIGlmIHRoZSBnZW5lcmF0b3ItaWQgaXMgbm90IGZlYXNpYmxlLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlttal0gUHJl Y2lzZWx5LiBJZiB5b3UgdXNlIGEgcmVsaWFibGUgdHJhbnNwb3J0LCB5b3Ugd291bGQgaGF2ZSBv dGhlciBtZWFucyB0byBpZGVudGlmeSB0aGUgc291cmNlIG9mIHRoZSBub3RpZmljYXRpb25zLCBp biB3aGljaCBjYXNlIHlvdSB3b3VsZCBub3QgbmVlZCB0aGUgZ2VuZXJhdG9yLWlkLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj56dHImZ3Q7IFllcy4gQnV0IEkganVzdCB0aGluayBpZiB3ZSBjYW4gdXNl IHRoZSBnZW5lcmF0b3ItaWQsIHdlIGRvIG5vdCBuZWVkIHRvIGRldmVsb3AgZGlmZmVyZW50IHdh eXMgZm9yIGVhY2ggdHJhbnNwb3J0LiBTbyB0aGF0IHRoZSBwcm9jZWR1cmUgY291bGQgYmUgY29u c2lzdGVudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+V2hpY2ggZ29lcyBiYWNrIHRvIHRoZSBxdWVzdGlvbiBvZiB3aHkgd2UgbmVlZCBh IGdlbmVyYXRvci1pZC4gSWYgd2UgZG8gbm90IHdhbnQgZGF0YSBsb3NzLCB3ZSBzaG91bGQgYmUg dXNpbmcgYSByZWxpYWJsZSB0cmFuc3BvcnQsIGluIHdoaWNoIGNhc2Ugd2UgZG8gbm90IG5lZWQg YSBnZW5lcmF0b3ItaWQuIElmIHdlIGNhbiB0b2xlcmF0ZSBkYXRhIGxvc3MsIGUuZy4gd2l0aCBz dGF0aXN0aWNzLCB3ZSBkbw0KIG5vdCBjYXJlIGZvciBnZW5lcmF0b3ItaWQgYmVjYXVzZSB3ZSBh cmUgbm90IGdvaW5nIHRvIGFzayBmb3IgbWlzc2luZyBkYXRhLiBXaGF0IHVzZSBjYXNlIHJlcXVp cmVzIHVzIHRvIHVzZSB1bnJlbGlhYmxlIHRyYW5zcG9ydCBhbmQgeWV0IG5lZWQgYSBnZW5lcmF0 b3ItaWQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnp0ciZndDsgSGVyZSB3ZSB3YW50IHRvIGNoZWNr IHRoZSBpbnRlZ3JpdHksIG5vdCB0aGUgcHJlY2lzZSBwYWNrZXQgbG9zcy4gRm9yIHJlbGlhYmxl IHRyYW5zcG9ydCwgdGhlIHJlY2VpdmVyIGtub3cgaG93IG1hbnkgc2Vzc2lvbnMgbmVlZCB0byBl c3RhYmxpc2ggZm9yIG9uZSBzdWJzY3JpcHRpb24uDQogT24gdGhlIG90aGVyIGhhbmQsICZuYnNw O2lmIG9uZSBzZXNzaW9uIGdldCBsb3N0LCB3aGljaCBzdWJzY3JpcHRpb25zIGFyZSBpbXBhY3Rl ZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Rm9yIHRoZSB1bnJlbGlhYmxlIHRy YW5zcG9ydCwgb25lIG1vcmUgY2FzZSBpcywgaWYgb25lIHNlc3Npb24gaXMgcmVhbGx5IGJhZCAo c2F5IDUwJSBwYWNrZXQgbG9zcyksIHRoZSBzdWJzY3JpYmVyIG1heSBuZWVkIHRvIGRvIHNvbWUg YWN0aW9uL2FkanVzdG1lbnQuIFllcw0KIHdlIGNhbiB0b2xlcmF0ZSBkYXRhIGxvc3MsIGJ1dCBJ IHRoaW5rIGl0IHNob3VsZCBiZSBhIHRocmVzaG9sZC48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj7igJx3aGF0IHNl ZW1zIHRvIGJlIG1pc3NpbmcgaXMgYW4gYWJpbGl0eSBmb3IgdGhlIGNsaWVudCB0byBkZXRlcm1p bmUgd2hpY2ggZ2VuZXJhdG9yLWlkIGlzIHVzZWQgYnkgd2hpY2ggcHVibGlzaGVyIChlLmcuLCBs aW5lIGNhcmQpLiDigJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SWYgbmVjZXNz YXJ5LCBtYXliZSB3ZSBjYW4gZXh0ZW5kIHRoaXMgbWFwcGluZyBpbiBzb21lIGluaXRpYWwgZXhj aGFuZ2VzLiBUbyBiZSBjbGVhciwgaG93IGRvIHlvdSB3YW50IHRvIG5hbWUgdGhlIHB1Ymxpc2hl cj88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+VGlhbnJhbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+bmV0Y29uZg0KIFs8YSBo cmVmPSJtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6 Izk1NEY3MiI+bWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XTxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5PbiBCZWhhbGYg T2Y8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPktl bnQgV2F0c2VuPGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPlR1ZXNkYXksIFNlcHRlbWJlciAyMiwgMjAyMCA2OjU1IEFNPGJy Pg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj5BbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20i PjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5hbmR5QHl1bWF3b3Jrcy5jb208L3NwYW4+PC9h PiZndDs8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj48c3BhbiBzdHls ZT0iY29sb3I6Izk1NEY3MiI+bmV0Y29uZkBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGI+U3Vi amVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PlJlOiBbbmV0Y29uZl0gQWRvcHRpb24tc3VpdGFiaWxpdHkgZm9yIGRyYWZ0LXVueXRlLW5ldGNv bmYtZGlzdHJpYnV0ZWQtbm90aWY8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W0FzIGFuIGlu ZGl2aWR1YWwgY29udHJpYnV0b3JdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBvdmVyYWxsIGFwcHJvYWNoIHRvIHRoZSBiaW5hcnkgcHVz aCBmZWF0dXJlcyBzZWVtcyBhIGJpdCBpbmNvaGVyZW50IHRvIG1lLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj5JIGRvbid0IHNlZSBtdWNoIHZhbHVlIGluIHRoaXMgZHJhZnQs IGJ1dCBubyBoYXJtIGVpdGhlciBzbyBJIGRvIG5vdCBoYXZlIGFuIG9iamVjdGlvbjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj50byBhZG9wdGlvbi4mbmJzcDsgUGVyaGFwcyB0 aGVyZSBpcyBzb21lIGRlYnVnZ2luZyB2YWx1ZSBoZXJlIGJ1dCBzaW5jZSB0aGUgYXJjaGl0ZWN0 dXJlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPnJlYWxseSBkb2VzIG5vdCBk ZWZpbmUgbWVzc2FnZSBnZW5lcmF0b3JzIGFzIHN1Yi1jb21wb25lbnRzIG9mIGEgY29uZmlndXJl ZCBzdWJzY3JpcHRpb24sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmEgY2xp ZW50IGNhbm5vdCBleHBlY3QgYW55IHNvcnQgb2YgY29uc2lzdGVudCBpbXBsZW1lbnRhdGlvbiBv ZiB0aGlzIGZpZWxkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdvb2QgcG9pbnQuIElmIEkgdW5kZXJzdGFuZCB5b3UgY29y cmVjdGx5LCB3aGF0IHNlZW1zIHRvIGJlIG1pc3NpbmcgaXMgYW4gYWJpbGl0eSBmb3IgdGhlIGNs aWVudCB0byBkZXRlcm1pbmUgd2hpY2ggZ2VuZXJhdG9yLWlkIGlzIHVzZWQgYnkgd2hpY2ggcHVi bGlzaGVyIChlLmcuLCBsaW5lIGNhcmQpLiAmbmJzcDtUaGUgc29sdXRpb24gZW5hYmxlcyB0aGUg Y2xpZW50IHRvIHBhcnRpdGlvbiBub3RpZmljYXRpb25zIGNvbWluZw0KIGZyb20gZGlmZmVyZW50 IHB1Ymxpc2hlcnMsIGJ1dCB0aGF0IGlzIGl0LiAmbmJzcDtXaGF0IHZhbHVlIGRvZXMgdGhpcyBo YXZlIHRvIHRoZSBjbGllbnQsIEkgZG9u4oCZdCBrbm93LiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+QW5zd2VyaW5nIG15c2VsZiBoZXJlLCBwZXJoYXBzIGl0IGVuYWJsZXMgdHdv IHNlcnZlcnMgb24gdGhlIHNhbWUgSVAgYWRkcmVzcyB0byBzZW5kIHRvIHRoZSBzYW1lIHJlY2Vp dmVyLCBhcyB0aGVuIHRoZSZuYnNwO3JlY2VpdmVyIGRvZXNu4oCZdCBzb2xlbHkgcmVseSBvbiBz b3VyY2UtSVAgYWRkcmVzcyAoYXNzdW1pbmcgdW5hdXRoZW50aWNhdGVkIHB1c2gpIHRvIGRlc2ln bmF0ZSB0aGUgcHVibGlzaGVyPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5DYW4gdGhlIGF1dGhvcnMgaGVscCByZXNvbHZlIHRoZSB2YWx1ZS1wcm9wb3NpdGlv biBxdWVzdGlvbiBoZXJlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KbmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPm5l dGNvbmZAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvc3Bhbj48L2E+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ TWFoZXNoIEpldGhhbmFuZGFuaTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRh bmlAZ21haWwuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+bWpldGhhbmFuZGFuaUBn bWFpbC5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+TWFoZXNo IEpldGhhbmFuZGFuaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRv Om1qZXRoYW5hbmRhbmlAZ21haWwuY29tIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_92ca069f090c42baba11a980682ea105huaweicom_-- From nobody Fri Sep 25 04:03:36 2020 Return-Path: <01000174c4eeb24e-c672ebe0-23a1-4f0e-afba-5b44d932e0ed-000000@amazonses.watsen.net> 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 9B0953A1361 for ; Fri, 25 Sep 2020 04:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 ipnOHVCA_neA for ; Fri, 25 Sep 2020 04:03:33 -0700 (PDT) Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4A113A1360 for ; Fri, 25 Sep 2020 04:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1601031811; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=WUjay43KW1TsomkSKH36Y5FHKENKsTKrnfGbcShFn20=; b=OCZkIO3EadKOwo2pOV3kIdJ649qVvQcdn2mNrfFvYZdgt2HfGgxPl3ER0gM0779W IGc/aiEjkDnoPnSfYy9SjSLcKdARcwEOk5hsHCPD24FOiTi8/XcD21hu68EWaDPBXmS DjGLxYMs6mJC7q0uqk9AO9KatO7ChguotMLfw5Y8= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_45FD12B9-D9D9-49E1-B793-7D7152CF644C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-ID: <01000174c4eeb24e-c672ebe0-23a1-4f0e-afba-5b44d932e0ed-000000@email.amazonses.com> Date: Fri, 25 Sep 2020 11:03:31 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.09.25-54.240.48.92 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 11:03:35 -0000 --Apple-Mail=_45FD12B9-D9D9-49E1-B793-7D7152CF644C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The restconf-collections draft [1] expired long ago, and yet the problem = remains. What is the problem? In my opinion, the problem is more narrow in scope = than before. Specifically, I feel that it is limited to just "config = false" lists, which tend to contain an enormous number entries. Classic = examples include "audit logs" and "device logs". I do not feel that "config true" lists are a problem because 1) if it's = possible for the client to configure a list, then it should be no = problem for the client to handle getting it back and 2) clearly this is = what everyone is doing today, unless using proprietary solutions, as RFC = 8040 offers no option. It's understood that supporting "config true" lists could improve = performance some, but this seems more like a "nice to have" compared to = supporting "config false" lists, where returning all list entries in a = single response risks exhausting internal memory buffers resulting in = failures, and thus solving this problem seems more of a "must have". = Not to mention, handling "ordered-by user" lists would be very = difficult. [As an aside, how are people handling large "config false" lists today? = Is each list-entry streamed out as a "notification"? Isn't there still = always a need to have at least the most-recent list entries, which could = still be a lot, on the server?] The net-net is that I'm thinking we should brushoff the = restconf-collections draft, and I'm wondering to what extent the WG = agrees. Anyone? Regarding solution, I suggest a two-fold approach: 1) only support query parameters (e.g., offset, limit, sort, where) if = a "config false" list is queried directly. E.g., GET = {+restconf}/ds/ietf-datastores:operational/example-module:widgets/widget?o= ffset=3D20?limit=3D50. Note that RESTCONF does not allow the list = itself to be a resource target is exactly why this makes sense. 2) any "config false" list that is a descendent of the resource target = returns a placeholder response, rather than its contents. Specifically, = a top-level query on would NOT return any "config false" = list entries. As for the placeholder response, perhaps it could return = metadata, something like: { "example-module:widgets": { "widget": [ { = "@": { "ietf-collections:redacted": [None] } } ] } }. To be = backwards-compatible, it could be this list "entry" is only returned if = the client sends a special query parameter (e.g., = ?collections-supported) or, alternately, the server implicitly always = only returns at most one list-entry (e.g., as if ?limit=3D1 was passed). Comments? K. [1] = https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-collection = = --Apple-Mail=_45FD12B9-D9D9-49E1-B793-7D7152CF644C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

The restconf-collections draft [1] = expired long ago, and yet the problem remains.

What is the problem?  In my = opinion, the problem is more narrow in scope than before. =  Specifically, I feel that it is limited to just "config false" = lists, which tend to contain an enormous number entries.  Classic = examples include "audit logs" and "device logs".

I do not feel that "config true" lists = are a problem because 1) if it's possible for the client to configure a = list, then it should be no problem for the client to handle getting it = back and 2) clearly this is what everyone is doing today, unless using = proprietary solutions, as RFC 8040 offers no = option.

It's = understood that supporting "config true" lists could improve performance = some, but this seems more like a "nice to have" compared to supporting = "config false" lists, where returning all list entries in a single = response risks exhausting internal memory buffers resulting in failures, = and thus solving this problem seems more of a "must have".  Not to = mention, handling "ordered-by user" lists would be very = difficult.

[As = an aside, how are people handling large "config false" lists today? =  Is each list-entry streamed out as a "notification"?  Isn't = there still always a need to have at least the most-recent list entries, = which could still be a lot, on the server?]

The net-net is that I'm = thinking we should brushoff the restconf-collections draft, and I'm = wondering to what extent the WG agrees.

Anyone?


Regarding solution, I suggest a two-fold approach:

  1) only support = query parameters (e.g., offset, limit, sort, where) if a "config false" = list is queried directly.  E.g., GET = {+restconf}/ds/ietf-datastores:operational/example-module:widgets/widget?o= ffset=3D20?limit=3D50.  Note that RESTCONF does not allow the list = itself to be a resource target is exactly why this makes = sense.

  = 2) any "config false" list that is a descendent of the resource target = returns a placeholder response, rather than its contents. =  Specifically, a top-level query on <operational> would NOT = return any "config false" list entries.  As for the placeholder = response, perhaps it could return metadata, something like: { = "example-module:widgets": { "widget": [ { "@": { = "ietf-collections:redacted": [None] } } ] } }.  To be = backwards-compatible, it could be this list "entry" is only returned if = the client sends a special query parameter (e.g., = ?collections-supported) or, alternately, the server implicitly always = only returns at most one list-entry (e.g., as if ?limit=3D1 was = passed).


Comments?

K.


[1] https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-co= llection
= --Apple-Mail=_45FD12B9-D9D9-49E1-B793-7D7152CF644C-- From nobody Fri Sep 25 05:31:25 2020 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 567FE3A1053 for ; Fri, 25 Sep 2020 05:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=DqlwsF3A; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=fkZaK+Lp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkneuyHX-dL7 for ; Fri, 25 Sep 2020 05:31:22 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1E13A0F53 for ; Fri, 25 Sep 2020 05:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3978; q=dns/txt; s=iport; t=1601037082; x=1602246682; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=XDSU+q+gcPxKVj1bndHm1yKDs/Li+ovb6wB6VSNV1uU=; b=DqlwsF3Ak5c8zopkeSweOqsf3AfiW1yoPQOmxBdva8F7kKysV9bCJLsn yzO/1tEXfuzISyqm3vGlGzhgU64KgHHa3b+6yN5zQXRe2mmTXK6IjVBw1 nCj5ItzsomrfGA2zRdgELnUJPTeSYfFpR2RbtXdAfrDswJYxyCQgcdplp A=; IronPort-PHdr: =?us-ascii?q?9a23=3AskYdZhZN0ujmSu44axSIDdn/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaXD5rS9+lJjazQvryzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsuteFTOuXC0qzgfBk?= =?us-ascii?q?a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR?= =?us-ascii?q?6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DDCgDW4m1f/4oNJK1fHQEBPAEFBQE?= =?us-ascii?q?CAQkBFYFPAoFQUQeBSS8sCod4A417mHaBLoElA1ULAQEBDQEBLQIEAQGESwK?= =?us-ascii?q?CLgIkNAkOAgMBAQsBAQUBAQECAQYEbYVcDIVyAQEBAQIBEi4BATgECwIBCBU?= =?us-ascii?q?BMDIlAgQBEggTB4VQAw4gAaw2AoE5iGF0gTSDAQEBBYUyGIIQCYE4AYJxijw?= =?us-ascii?q?bgUE/gVSCGDU+hBQBEBgCg0iCLZALCDaLLoFlmWUKgmeaeaEQkwigBQIEAgQ?= =?us-ascii?q?FAg4BAQWBVDqBV3AVO4JpUBcCDZIQilZ0NwIGCgEBAwl8i3MBJ4ENATFfAQE?= X-IronPort-AV: E=Sophos;i="5.77,302,1596499200"; d="scan'208";a="567964616" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Sep 2020 12:31:10 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 08PCV9ER028524 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 25 Sep 2020 12:31:10 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 25 Sep 2020 07:31:09 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 25 Sep 2020 07:31:09 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 25 Sep 2020 08:31:09 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B03Lx1WWgs/lAP4lP55yUJ+/fJSwv4jqQTwwNzoqSB6n4YXp9Ow5TI8vseIy8yOfQxopbaGLSD82qXkoFX0UVvI510peJDuTeVc57x8K+JpwNuduHZc+j+KfqGLkPZYlS5Jpv/ijrmCgCmZlE0LIwRUCe72+cZUcRTlJg+k0RVcv+Ds/EOk8m/BmZ1wb+wtcC8rUMDN/83P0h5/7FcuxZXmxYLaaRV6Efm1bE6fQ1hlJPtbHMjLdh36Xa6Hd3o5B71p4zTM7BE23xAV2gG2PwdtNa7qWvCNX14pDctgYV8YB11NyPsIZ50A3DQp/yuc0+AuhVEsZmE8S7LnMtxxN6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pWIDI+8LmjNnS7ggurk7US524i1TP8B0lHl1Npe7X+U=; b=i5ucrvI4rxpz0ykiMWQi1jV9rncjzbSsWh8b//znELEZoaGgbk+yzkVy3eayKRci2ZBjbJwbMbQCTHCkChv8tP4REAj4mf1MSRF5C2h50sP1DH3fyU423LCyN4A8zSKJTeGf/glt2JbKwHJkybohE2cCP73UDwzOZY590RGyG6ryaxv4hHpSOfAaJA/dvh7iqtNPv9dOtZkQdU4bS+dxYoD/70DTipAD/JXiqE0jwAYLxBrQqRoziBbSDm8DTYpKtZt9DPz778xmBE5r0QirmxfMOAa4dGZPqHH9OrlKcsWh3nId8yAevWWNl7tLNmrMgljI04QBW7UFxlNWO/TOcA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pWIDI+8LmjNnS7ggurk7US524i1TP8B0lHl1Npe7X+U=; b=fkZaK+LpfORM31ncXHoocdTozftgd2Y5wdij0sBz4EhbT6TvX87cHqB6GIKBZRvvqaYuSh3bc2UPlD/fMV/TnvGmbHYS/qcaFP+VppLCjUHpbc/aqc7EomGAjO57M6Jbp5/gkybrrE6dWhJwBl+14jkHOF8rPh7ScjizL06CIwQ= Received: from MWHPR11MB2032.namprd11.prod.outlook.com (2603:10b6:300:2b::13) by MWHPR11MB1374.namprd11.prod.outlook.com (2603:10b6:300:24::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.22; Fri, 25 Sep 2020 12:31:08 +0000 Received: from MWHPR11MB2032.namprd11.prod.outlook.com ([fe80::9966:b539:a9f4:60dc]) by MWHPR11MB2032.namprd11.prod.outlook.com ([fe80::9966:b539:a9f4:60dc%9]) with mapi id 15.20.3412.025; Fri, 25 Sep 2020 12:31:08 +0000 From: "Per Andersson (perander)" To: Kent Watsen , "netconf@ietf.org" Thread-Topic: [netconf] restconf collections Thread-Index: AQHWkyuf0+ZngtdDJ0S+NlOVghodU6l5Mm9+ Date: Fri, 25 Sep 2020 12:31:07 +0000 Message-ID: References: <01000174c4eeb24e-c672ebe0-23a1-4f0e-afba-5b44d932e0ed-000000@email.amazonses.com> In-Reply-To: <01000174c4eeb24e-c672ebe0-23a1-4f0e-afba-5b44d932e0ed-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.220.54] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ba323a37-55b2-4981-6e15-08d8614ee0df x-ms-traffictypediagnostic: MWHPR11MB1374: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oZjtfWYXNinmSOILm90JYLhvGakyQ1hXe4jP3j99q/7vIlwfLpY/I8+ci5WfcwTCfHGQX/c9BWdl9XB8mS1zDjq3M3mX3xbCkx3GI0tARAWRHqEmE0lBu844975Xz4N1oHzXNhmwWYYuVTGXkMdDF8/r+BNoFDiEkFJ7+STgkb9WQsDi4RLnobIkZK2BCMUiyZTcHqQBO3/egZkHCS6mezLZkVwXU7VdsMH8xz5DXk+WlngCVIlfXK1BZS30w9pHxzh+Al0vxf6j/t4OB9gWkyYytAyciwRLCKD3oueibvs6VaOL/PcUFJq/zc/qF3oSxeLXtvuaFMFUdeZoYLGM/tGkRZR2CxE/19vYJjBZW1LrySY37TiIUeUlWLPSEBVE x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB2032.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(136003)(396003)(346002)(39860400002)(376002)(9686003)(71200400001)(186003)(26005)(55016002)(8676002)(91956017)(76116006)(66946007)(2906002)(66476007)(66556008)(83380400001)(5660300002)(110136005)(33656002)(8936002)(86362001)(52536014)(316002)(478600001)(6506007)(66446008)(64756008)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 5468gq1cIjb9sPxmGNyxLBEqs6V4/jmXjc4vjo431d85ITlGGLoZrfGg9MWnVxm25T3f3vTpAW5Imuxj7Wz893XibHvudJed9Wwt19QR85uicXryH6/spbJeAWxpnJvL34w6ymcroneLiXV434oQIF10cZnqOYfZCe1ALhEw8NZ6ENdJ95Hq79j0prsOTBOw5F0xjXk8mCzhXXaG2sq1B7ps5G5+/+aUGhmFmbQlNkiVReg9bJT28HvJGezpRhr6AgLWJDwPFFVujzak8DE/RE1Rl6bHZXfOkt4FYxF35tzjwlEZ81DQrS0h3qKhl6IsmhUcokoEw5kO8qYG1MID6Um/q5UPQqfL3ejeY0wibxgMrOxdDoh+8tYs06bMuV53zloKItd6eud6BHbUIoS1BL4F8iz/kUudLI9l0jO23UIHuml6j1S0U4rQa1IS9d/nt6xkMduvCA2gfPftHmF0jruywp2qbdrsg4EE7HN5TWKoOvyxIZC3K9SxLUzPcbQHxXhrB60yffRxE2CJorDRy6gNQgBS6YU81SAj6/xj9TQkyHG/yiPx/DE0Q6uBwpSKJlk4wi7yZts72VFk3Powc0z0Mj+C28SkoOoQxUtOEFZQ99DIJqVinDmILkie/DdlPD2+RMSOPvl7WTjcwwasTg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB2032.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ba323a37-55b2-4981-6e15-08d8614ee0df X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2020 12:31:07.9248 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8TpDnxbp508Y8elLQNxP/IFDTiULHGeFcyLBVocpuR/CP6Lyw8yNpT8zSXb3CTo6XJtSvu3+mAaTc9qSpeJTaQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1374 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 12:31:24 -0000 From: Kent Watsen on Sent: Friday, September 25, 202= 0 13:03:=0A= > The restconf-collections draft [1] expired long ago, and yet the problem = remains.=0A= >=0A= > What is the problem? In my opinion, the problem is more narrow in scope = than before. Specifically, I feel that it is limited to just "config false= " lists, which tend to contain an enormous number entries. Classic example= s include "audit logs" and "device logs".=0A= >=0A= > I do not feel that "config true" lists are a problem because 1) if it's p= ossible for the client to configure a list, then it should be no problem fo= r the client to handle getting it back and 2) clearly this is what everyone= is doing today, unless using proprietary solutions, as RFC 8040 offers no = option.=0A= >=0A= > It's understood that supporting "config true" lists could improve perform= ance some, but this seems more like a "nice to have" compared to supporting= "config false" lists, where returning all list entries in a single respons= e risks exhausting internal memory buffers resulting in failures, and thus = solving this problem seems more of a "must have". Not to mention, handling= "ordered-by user" lists would be very difficult.=0A= >=0A= > [As an aside, how are people handling large "config false" lists today? = Is each list-entry streamed out as a "notification"? Isn't there still alw= ays a need to have at least the most-recent list entries, which could still= be a lot, on the server?]=0A= >=0A= > The net-net is that I'm thinking we should brushoff the restconf-collecti= ons draft, and I'm wondering to what extent the WG agrees.=0A= =0A= I agree it should be brushed off.=0A= =0A= I have been looking at restconf-next on github where this has been mentione= d.=0A= Will it be part of restconf-next or a separate effort?=0A= =0A= Today we implement limit and offset as proprietary extensions to RESTCONF.= =0A= It would be good to have them (or some other pagination mechanism)=0A= standardized.=0A= =0A= If I recall correctly, we have use cases for config true list sizes in the = thousands=0A= or even tens of thousands.=0A= =0A= =0A= > Regarding solution, I suggest a two-fold approach:=0A= >=0A= > 1) only support query parameters (e.g., offset, limit, sort, where) if a= "config false" list is queried directly. E.g., GET {+restconf}/ds/ietf-da= tastores:operational/example-module:widgets/widget?offset=3D20?limit=3D50. = Note that RESTCONF does not allow the list itself to be a resource target = is exactly why this makes sense.=0A= =0A= I would suggest supporting (at least) pagination for any list.=0A= =0A= What is the point of selective support? As a user I would find it strange.= =0A= =0A= =0A= > 2) any "config false" list that is a descendent of the resource target r= eturns a placeholder response, rather than its contents. Specifically, a t= op-level query on would NOT return any "config false" list en= tries. As for the placeholder response, perhaps it could return metadata, = something like: { "example-module:widgets": { "widget": [ { "@": { "ietf-co= llections:redacted": [None] } } ] } }. To be backwards-compatible, it coul= d be this list "entry" is only returned if the client sends a special query= parameter (e.g., ?collections-supported) or, alternately, the server impli= citly always only returns at most one list-entry (e.g., as if ?limit=3D1 wa= s passed).=0A= =0A= It feels like the implementation could be simpler with the implicit ?limit= =3D1=0A= behaviour. Even with pagination the list could be large and perhaps=0A= streamed out which would make collection of metadata more challenging.=0A= =0A= Another possibility is to let the client handle such queries, instead of=0A= replacing list contents with a placeholder let the client set ?depth=3D1=0A= and effectively omit list contents..=0A= =0A= =0A= --=0A= Per= From nobody Fri Sep 25 08:49:14 2020 Return-Path: <01000174c5f430be-3953d7e9-a364-4c55-8abb-58dbc233214f-000000@amazonses.watsen.net> 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 14B333A1174 for ; Fri, 25 Sep 2020 08:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 VjDXCV0Amafs for ; Fri, 25 Sep 2020 08:49:10 -0700 (PDT) Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F96D3A1158 for ; Fri, 25 Sep 2020 08:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1601048949; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=X0sNhrWQR7Y5V9lnLkR0tufdAGo3o/eMAMtVEfH1ibY=; b=AzwfQ5aT1pICnrbu5dOJvHEWhbq7LIV5Q/o3IC4AbVyaApbyuEizEHQizpOtCF8k us1Tv+InxGx6CL98a9xmjhqJJGRIhB7XPFtyGYXK/DH4YAT3XwSh+MID4ctIc1ZRr2I 01aq0BasC66mxHOUGuUk0AGWvgXCS1jywVKCOcac= From: Kent Watsen Message-ID: <01000174c5f430be-3953d7e9-a364-4c55-8abb-58dbc233214f-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7457EE80-8B90-4ED1-B2F1-E4B900ADA6A5" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 25 Sep 2020 15:49:09 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: "Per Andersson (perander)" References: <01000174c4eeb24e-c672ebe0-23a1-4f0e-afba-5b44d932e0ed-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.09.25-54.240.48.92 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 15:49:12 -0000 --Apple-Mail=_7457EE80-8B90-4ED1-B2F1-E4B900ADA6A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Per, > I agree it should be brushed off. Interested in being a co-author? > I have been looking at restconf-next on github where this has been = mentioned. Ref: https://github.com/netconf-wg/restconf-next/issues/1 = > Will it be part of restconf-next or a separate effort? If an NBC change is needed, it would have to be a -bis, otherwise, if = all backwards-compatible, it could be a -bis or a new RFC that "updates" = RFC 8040. > Today we implement limit and offset as proprietary extensions to = RESTCONF. > It would be good to have them (or some other pagination mechanism) > standardized. By "we", do you mean the Tail-F group within Cisco? What I'm really = asking here is if the proprietary extensions are essentially captured by = Martin in the restconf-collections draft. > If I recall correctly, we have use cases for config true list sizes in = the thousands > or even tens of thousands. List of "interfaces" is the quintessential example I've heard in the = past. Does your implementation support the extensions of CT lists? = If so, does it support them on "ordered-by user" lists too? Is the = use-case (to support on CT lists) a "nice-to-have" or a "must-have"? = If a "must-have", how is it justified? >> Regarding solution, I suggest a two-fold approach: >>=20 >> 1) only support query parameters (e.g., offset, limit, sort, where) = if a "config false" list is queried directly. E.g., GET = {+restconf}/ds/ietf-datastores:operational/example-module:widgets/widget?o= ffset=3D20?limit=3D50. Note that RESTCONF does not allow the list = itself to be a resource target is exactly why this makes sense. >=20 > I would suggest supporting (at least) pagination for any list. You mean to let the "limit" and "offset" params be available for both CT = and CF lists, but limit "sort" and "where" to CF lists? That might = work, as it sidesteps the odd "sorting a user-sorted list" case... > What is the point of selective support? As a user I would find it = strange. If by "selective support" you mean the "where" parameter, I think that = it's only useful for CF lists (e.g., logs) whereby the client only = wishes to fetch entries matching some criteria (e.g., where user=3D=3Dfoo = or source-addr=3Dbar). Makes sense? > It feels like the implementation could be simpler with the implicit = ?limit=3D1 > behaviour. Even with pagination the list could be large and perhaps > streamed out which would make collection of metadata more challenging. An implicit ?limit=3D1 would be simple to implement, but assuming we're = trying to introduce the behavior in a backwards-compatible manner, how = to differentiate a truncated list from a list that actually contains = just one value? Assuming a legacy client (that does not know to look = for or grok a ietf-restconf-collections module in yang-library)...or are = you saying that the current behavior is so broken that such an NBC = change would actually be welcomed by legacy clients? > Another possibility is to let the client handle such queries, instead = of > replacing list contents with a placeholder let the client set ?depth=3D1= > and effectively omit list contents.. Assuming the "depth" query parameter is supported, but the server could = still *implicitly* support ?depth=3D1 w/o supporting the capability. = That said, the response would still be the size of the list, right? = I've also thought to let server's implicitly return as if = "?fields=3D*" (i.e., just return the keys) has been passed but, = again, the response would be the size of the list. Such options might = be okay for CT-lists, but not so much for the potentially enormous = CF-lists I have in mind... K. --Apple-Mail=_7457EE80-8B90-4ED1-B2F1-E4B900ADA6A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Per,

I agree it should be brushed off.

Interested in being a co-author?


I have been = looking at restconf-next on github where this has been = mentioned.

Ref: https://github.com/netconf-wg/restconf-next/issues/1
<= div>

Will it be part of restconf-next or a separate = effort?

If = an NBC change is needed, it would have to be a -bis, otherwise, if all = backwards-compatible, it could be a -bis or a new RFC that "updates" RFC = 8040.


Today we implement limit and offset as proprietary extensions = to RESTCONF.
It would be = good to have them (or some other pagination mechanism)
standardized.

By "we", do you mean the Tail-F group within Cisco? =  What I'm really asking here is if the proprietary extensions are = essentially captured by Martin in the restconf-collections = draft.


If I recall = correctly, we have use cases for config true list sizes in the = thousands
or even tens = of thousands.

List = of "interfaces" is the quintessential example I've heard in the past. =   Does your implementation support the extensions of CT lists? =    If so, does it support them on "ordered-by user" lists too? =    Is the use-case (to support on CT lists) a "nice-to-have" = or a "must-have"?   If a "must-have", how is it = justified?



Regarding solution, I suggest a two-fold approach:

1) only support query parameters (e.g., = offset, limit, sort, where) if a "config false" list is queried = directly.  E.g., GET = {+restconf}/ds/ietf-datastores:operational/example-module:widgets/widget?o= ffset=3D20?limit=3D50.  Note that RESTCONF does not allow the list = itself to be a resource target is exactly why this makes sense.

I would suggest supporting (at least) pagination for any = list.

You = mean to let the "limit" and "offset" params be available for both CT and = CF lists, but limit "sort" and "where" to CF lists?  That might = work, as it sidesteps the odd "sorting a user-sorted list" = case...


What is the point of selective support? As a user I would = find it strange.

If by "selective support" you mean the "where" = parameter, I think that it's only useful for CF lists (e.g., logs) = whereby the client only wishes to fetch entries matching some criteria = (e.g., where user=3D=3Dfoo or source-addr=3Dbar).  Makes = sense?


It feels like = the implementation could be simpler with the implicit ?limit=3D1behaviour. = Even with pagination the list could be large and perhaps
streamed out = which would make collection of metadata more challenging.

An = implicit ?limit=3D1 would be simple to implement, but assuming we're = trying to introduce the behavior in a backwards-compatible manner, how = to differentiate a truncated list from a list that actually contains = just one value?   Assuming a legacy client (that does not know to = look for or grok a ietf-restconf-collections module in = yang-library)...or are you saying that the current behavior is so broken = that such an NBC change would actually be welcomed by legacy = clients?


Another possibility is to let the client handle such queries, = instead of
replacing = list contents with a placeholder let the client set ?depth=3D1
and = effectively omit list contents..

Assuming the "depth" query parameter is = supported, but the server could still *implicitly* support ?depth=3D1 = w/o supporting the capability.  That said, the response would still = be the size of the list, right?   I've also thought to let server's = implicitly return as if "?fields=3D<key>*" (i.e., just return the = keys) has been passed but, again, the response would be the = size of the list.  Such options might be okay for CT-lists, but not = so much for the potentially enormous CF-lists I have in = mind...


K.


= --Apple-Mail=_7457EE80-8B90-4ED1-B2F1-E4B900ADA6A5-- From nobody Fri Sep 25 09:00:23 2020 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 2FCB63A0E03 for ; Fri, 25 Sep 2020 09:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 6rNihwZ89i9E for ; Fri, 25 Sep 2020 09:00:19 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::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 6A2EC3A1192 for ; Fri, 25 Sep 2020 09:00:05 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id a22so2860082ljp.13 for ; Fri, 25 Sep 2020 09:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0mKLyAZiFoGB6Bci/c083fp/zAHhRU2swC4i0bsrdFE=; b=ud3jm2EQgv0HMIvv4Xl7M/C42XgB3smhULGpnE1eLPPOIldw+WlMLQjrv+/7vyWf9h 2658Tkyl5voAVjqntk+/8ZPVCPdCbAK44LGNzww77l/koZSJvcrzJUyDFCbXjG17wyGu 43MQWHsvxTRnF/iwvRjcKiioO6tMu+Oo1UlF6+w+gGidW3GbqXATP0vbfXnJGzuTVAUm 7nLec5h9BuP/c7tRf4Vs08hGgzUK+GpdI8ofDy49D9KuvmUnOV2WZMBvAGPuIIUgpEv5 Ef2bw7EzGmabE71Ylv3qFvFr8SWL0X2ph4V8tr4CKVzgLTvPVxAUmk+B5NoDfC0d//T0 oamg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0mKLyAZiFoGB6Bci/c083fp/zAHhRU2swC4i0bsrdFE=; b=A7UPh+JbRuqrJdfq+YqMVctZz83mrujXhDY1VhuGVCWPrNMhfLftlBqCwuAjdx/bX/ TasVeANyiPrTFRMrx/GcDAycmHmYgbDPqfevr/Utc81Eoz+lkBzUhWBblMbYE7OQ8HXX 5Nav+gJll5aUE9EnJYz65oTORqb1G/NAlFt5oxc+awVqi6nRs994n5W0CeQem4azo0I5 yd8XopFHhdvy9SHBpoLmfMK0BfCvqkH5I/BiXTjlick7zcOB5gdg5hUyV+/r9eMK/moD EYYbk4uW2j6bTl4yM3wn77jx8aCNCTVuUmyB3IhXZNKwbOSE0pQpDTZ7WL741jGPCl04 rpnw== X-Gm-Message-State: AOAM530xV5+PtOcrKyCxu280OBNMYZ+RgZGFP0fxNdeS9emUu+EEGhMb hidy6nXRzvnnlV5JcB3fviVx2dd43uzejaJI6aDj/iP/663T5Q== X-Google-Smtp-Source: ABdhPJyP0cc9+eQfz6k74CxkDM+DHKSvXq0R7y119UE16bUNS9+64bxZWxZbzdnXRZM+ylsCfTOOa1stauhngabIH8U= X-Received: by 2002:a2e:4e01:: with SMTP id c1mr1534413ljb.144.1601049603381; Fri, 25 Sep 2020 09:00:03 -0700 (PDT) MIME-Version: 1.0 References: <01000174c4eeb24e-c672ebe0-23a1-4f0e-afba-5b44d932e0ed-000000@email.amazonses.com> In-Reply-To: <01000174c4eeb24e-c672ebe0-23a1-4f0e-afba-5b44d932e0ed-000000@email.amazonses.com> From: Andy Bierman Date: Fri, 25 Sep 2020 08:59:52 -0700 Message-ID: To: Kent Watsen Cc: "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e0af4005b0256802" Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 16:00:21 -0000 --000000000000e0af4005b0256802 Content-Type: text/plain; charset="UTF-8" Hi, This has been discussed a few times by the WG. The co-authors never agreed on the set of bells and whistles that should be supported. There was an objection from Phil Shafer at the time that pagination was not needed at all and handling large responses from the server was just a minor implementation detail. The most significant objection was that this is a RESTCONF-only solution and that was not acceptable to ignore NETCONF (since and GET end being the same in the end, so the problem also exists for NETCONF) Andy On Fri, Sep 25, 2020 at 4:03 AM Kent Watsen wrote: > > The restconf-collections draft [1] expired long ago, and yet the problem > remains. > > What is the problem? In my opinion, the problem is more narrow in scope > than before. Specifically, I feel that it is limited to just "config > false" lists, which tend to contain an enormous number entries. Classic > examples include "audit logs" and "device logs". > > I do not feel that "config true" lists are a problem because 1) if it's > possible for the client to configure a list, then it should be no problem > for the client to handle getting it back and 2) clearly this is what > everyone is doing today, unless using proprietary solutions, as RFC 8040 > offers no option. > > It's understood that supporting "config true" lists could improve > performance some, but this seems more like a "nice to have" compared to > supporting "config false" lists, where returning all list entries in a > single response risks exhausting internal memory buffers resulting in > failures, and thus solving this problem seems more of a "must have". Not > to mention, handling "ordered-by user" lists would be very difficult. > > [As an aside, how are people handling large "config false" lists today? > Is each list-entry streamed out as a "notification"? Isn't there still > always a need to have at least the most-recent list entries, which could > still be a lot, on the server?] > > The net-net is that I'm thinking we should brushoff the > restconf-collections draft, and I'm wondering to what extent the WG agrees. > > Anyone? > > > Regarding solution, I suggest a two-fold approach: > > 1) only support query parameters (e.g., offset, limit, sort, where) if a > "config false" list is queried directly. E.g., GET > {+restconf}/ds/ietf-datastores:operational/example-module:widgets/widget?offset=20?limit=50. > Note that RESTCONF does not allow the list itself to be a resource target > is exactly why this makes sense. > > 2) any "config false" list that is a descendent of the resource target > returns a placeholder response, rather than its contents. Specifically, a > top-level query on would NOT return any "config false" list > entries. As for the placeholder response, perhaps it could return > metadata, something like: { "example-module:widgets": { "widget": [ { "@": > { "ietf-collections:redacted": [None] } } ] } }. To be > backwards-compatible, it could be this list "entry" is only returned if the > client sends a special query parameter (e.g., ?collections-supported) or, > alternately, the server implicitly always only returns at most one > list-entry (e.g., as if ?limit=1 was passed). > > > Comments? > > K. > > > [1] > https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-collection > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000e0af4005b0256802 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

This has been discussed a few times= by the WG.
The co-authors never agreed on the set of bells and w= histles=C2=A0that should be supported.
There was an objection fro= m Phil Shafer at the time that pagination was not needed
at all a= nd handling large responses from the server was just a minor implementation= =C2=A0detail.
The most significant objection was that this is a R= ESTCONF-only solution and that
was not acceptable to ignore NETCO= NF (since <get> and GET end being=C2=A0the same
in the end,= so the problem also exists for NETCONF)


Andy


On Fri, Sep 25, 2020 at 4:03 AM Kent Watsen = <kent+ietf@watsen.net> = wrote:

The restconf-collections dr= aft [1] expired long ago, and yet the problem remains.

W= hat is the problem?=C2=A0 In my opinion, the problem is more narrow in scop= e than before.=C2=A0 Specifically, I feel that it is limited to just "= config false" lists, which tend to contain an enormous number entries.= =C2=A0 Classic examples include "audit logs" and "device log= s".

I do not feel that "config true"= ; lists are a problem because 1) if it's possible for the client to con= figure a list, then it should be no problem for the client to handle gettin= g it back and 2) clearly this is what everyone is doing today, unless using= proprietary solutions, as=C2=A0RFC 8040 o= ffers=C2=A0no option.

It's understood t= hat supporting "config true" lists could improve performance some= , but this seems more like a "nice to have" compared to supportin= g "config false" lists, where returning all list entries in a sin= gle response risks exhausting internal memory buffers resulting in failures= , and thus solving this problem seems more of a "must have".=C2= =A0 Not to mention, handling "ordered-by user" lists would be ver= y difficult.

[As an aside, how are people handling= large "config false" lists today?=C2=A0 Is each list-entry strea= med out as a "notification"?=C2=A0 Isn't there still always a= need to have at least the most-recent list entries, which could still be a= lot, on the server?]

The net-net is that I'm th= inking we should brushoff the restconf-collections draft, and I'm wonde= ring to what extent the WG agrees.

Anyone?


Regarding solution, I suggest a two-fold a= pproach:

=C2=A0 1) only support query parameters (= e.g., offset, limit, sort, where) if a "config false" list is que= ried directly.=C2=A0 E.g., GET {+restconf}/ds/ietf-datastores:operational/e= xample-module:widgets/widget?offset=3D20?limit=3D50.=C2=A0 Note that RESTCO= NF does not allow the list itself to be a resource target is exactly why th= is makes sense.

=C2=A0 2) any "config false&q= uot; list that is a descendent of the resource target returns a placeholder= response, rather than its contents.=C2=A0 Specifically, a top-level query = on <operational> would NOT return any "config false" list e= ntries.=C2=A0 As for the placeholder response, perhaps it could return meta= data, something like: { "example-module:widgets": { "widget&= quot;: [ { "@": { "ietf-collections:redacted": [None] }= } ] } }.=C2=A0 To be backwards-compatible, it could be this list "ent= ry" is only returned if the client sends a special query parameter (e.= g., ?collections-supported) or, alternately, the server implicitly always o= nly returns at most one list-entry (e.g., as if ?limit=3D1 was passed).


Comments?

_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000e0af4005b0256802-- From nobody Fri Sep 25 09:56:38 2020 Return-Path: <01000174c631e0c3-8b790f60-b8f4-44f1-9d7f-e6a1d826ecd4-000000@amazonses.watsen.net> 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 4C7DE3A0FEB for ; Fri, 25 Sep 2020 09:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 KT2vOAjNczZJ for ; Fri, 25 Sep 2020 09:56:33 -0700 (PDT) Received: from a48-93.smtp-out.amazonses.com (a48-93.smtp-out.amazonses.com [54.240.48.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3673A0FF2 for ; Fri, 25 Sep 2020 09:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1601052991; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=uUFPDzeqWQIv2XyN/dDZ5ERK80TRljAMQaXOiLi/ESw=; b=jb5DYPAomK8wRJhHHOaJU4BS1XWC+3T13jTtTHrDlko/6v6MFI7SC7xqMIoGTS7J lGkShF6msuU/3oUUBwgqEsXzRW/DCqoLI5hbrBvnvasSONIlyhJfPXoh7SYrRR1Ppmr 0MHplYUIQK0+ma1V5zNrbzdCIUxDSMKv1u3z62SI= From: Kent Watsen Message-ID: <01000174c631e0c3-8b790f60-b8f4-44f1-9d7f-e6a1d826ecd4-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1CAA350F-2E28-4390-902B-4A12C3FD5E6A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 25 Sep 2020 16:56:31 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: Andy Bierman References: <01000174c4eeb24e-c672ebe0-23a1-4f0e-afba-5b44d932e0ed-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.09.25-54.240.48.93 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 16:56:34 -0000 --Apple-Mail=_1CAA350F-2E28-4390-902B-4A12C3FD5E6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Andy, > This has been discussed a few times by the WG. Perhaps a testament to it being a real problem? > The co-authors never agreed on the set of bells and whistles that = should be supported. True, but it's more like we lost interest / time to work on it...at = least that's my story! ;) > There was an objection from Phil Shafer at the time that pagination = was not needed > at all and handling large responses from the server was just a minor = implementation detail. Clearly Phil is in the rough, as many APIs support pagination for a = reason. Even if constraining the solution to networking gear, = interfaces and logs may be numerous, and on-box cli/web UIs can only = show a screen at a time... IMO, it's okay if we don't support for CT-lists (i.e., interfaces). As = you write above, and I wrote in before, it seems like a nice-to-have. = FYI, I'm asking Per in a fork of this thread to justify if supporting = CT-lists is a "must-have"...hopefully he'll come back with something = compelling. CF-lists, on the other hand, can be enormous...so much so that trying to = return all could exhaust server and/or client resources. I think = supporting CF-lists is a must-have. > The most significant objection was that this is a RESTCONF-only = solution and that > was not acceptable to ignore NETCONF (since and GET end being = the same > in the end, so the problem also exists for NETCONF) True. If we can find a way to extend support to NETCONF, all the = better. Of course, the solutions would be wildly different, much like = how NMDA had separate solutions for NC and RC (RFCs 8526 and 8527, = respectively). Perhaps Per or Martin can clue us into if they have a = NC-equivalent solution? However, if NC-support cannot be achieved, then I don't think it means = we don't do it for RC. Much like NC supports somethings RC doesn't = (e.g., confirmed commit), each protocol plays into its strengths. So = mote it be. > Andy K. --Apple-Mail=_1CAA350F-2E28-4390-902B-4A12C3FD5E6A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Andy,


This has been discussed a few = times by the WG.

Perhaps a testament to it being a real = problem?


The co-authors never agreed on the set of bells and = whistles that should be = supported.

True, but it's more like we lost interest / time = to work on it...at least that's my story!  ;)


There was an = objection from Phil Shafer at the time that pagination was not = needed
at all and handling large responses from the = server was just a minor = implementation detail.

Clearly Phil is in the rough, as many APIs support = pagination for a reason.   Even if constraining the solution to = networking gear, interfaces and logs may be numerous, and = on-box cli/web UIs can only show a screen at a = time...

IMO, it's okay if we don't support for = CT-lists (i.e., interfaces).  As you write above, and I wrote in = before, it seems like a nice-to-have.   FYI, I'm asking Per in a = fork of this thread to justify if supporting CT-lists is a = "must-have"...hopefully he'll come back with something = compelling.

CF-lists, on the other hand, can be enormous...so much = so that trying to return all could exhaust server and/or client = resources.   I think supporting CF-lists is a = must-have.


The most significant objection = was that this is a RESTCONF-only solution and that
was not acceptable to ignore NETCONF (since <get> and = GET end being the same
in the end, so the = problem also exists for NETCONF)

True.  If we can find a way to extend support = to NETCONF, all the better.   Of course, the solutions would be = wildly different, much like how NMDA had separate solutions for NC and = RC (RFCs 8526 and 8527, respectively).  Perhaps Per or Martin can = clue us into if they have a NC-equivalent solution?

However, if NC-support cannot be achieved, then I = don't think it means we don't do it for RC.   Much like NC supports = somethings RC doesn't (e.g., confirmed commit), each protocol plays into = its strengths.   So mote it be.


Andy

K.


= --Apple-Mail=_1CAA350F-2E28-4390-902B-4A12C3FD5E6A-- From nobody Fri Sep 25 10:22:26 2020 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 2F9D73A1050 for ; Fri, 25 Sep 2020 10:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 ncaaE8bOhfdJ for ; Fri, 25 Sep 2020 10:22:23 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::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 960853A104D for ; Fri, 25 Sep 2020 10:22:23 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id k25so3084764ljg.9 for ; Fri, 25 Sep 2020 10:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=edPOZn8BOSOiqPbzH0LdUWXeH0sOOBXmYllentoujvM=; b=vwJwqfCsicq6THxp60xHRJhkJvbpnwjSVQ9nNhFC/NywnIQcCe0kTnAOZGx9/7kHXz x+qoUtefLSU/ibfVovgmnEv5sjB/XjuMz2Bo55CwsKAPtUc1apdWDeKGD71ggh2RjQRS KlCh988E0gC2c/yp+C2WjfDWD1pF5oAJKOZQgSLisoIdq3jKpHCSS2/a57DGuTQCssgU BiiAip8kkZJ3a8Pu+eYHVXjFI+ZXwqOuqfTiyo7bSSuiXsZDFDZVOMZUU1v/SqIYYync 3jD0RfJW41SYilEAwUJbA8DfmLIRZeWaXqRCkXUqaAD5NK0lN6+vOAceFx3/syx9miJT QLYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=edPOZn8BOSOiqPbzH0LdUWXeH0sOOBXmYllentoujvM=; b=KusKNL2rCLUYR5DVI90PFzwHBjDgJ4gVSwAObuWKGd8+TjQtH65dGpmkCI9FSrsugo 2A265Frci2EAH3W9v6IYvGC+hRaPx3eGJpYblRqdyH2FOz8MLJlQFybWdw9GA/oetyJa mAmvaBzcGyeuM6k656NMPvP/+G6I2QWWCz4Wotb0eytNv2k5tm6ZOpqb7Ph/FLEZQ2Ry Jjk/kHGkxczRwVUU8PENmBRQvPz2NocXO40Lfizm9s94GmB7zubNmXBI3b4DNe8lPcGX QLSNc596iZcM/RvkU49EHASkabMsnQIX429fhsA9FxP4uT8oynfRMjJRZAjnkG6hT7/s WLbQ== X-Gm-Message-State: AOAM533kPRyGBwTqajc+qzCLot363MR6uiamQcNXXhurbvCGYXQclY/W E24XBtGHztQyujsj6JLodOj/6FNAragJtfrwNxVdqMVBEH0Nnw== X-Google-Smtp-Source: ABdhPJyxQJ+8oSdj0d9+c2XqXFZ74nHIbmccJqWRvQhEEjtp7Csi4WINDnn5zPU9HQn4Qe6AhBDTW/tCgu5xfr8bako= X-Received: by 2002:a2e:780d:: with SMTP id t13mr1839212ljc.324.1601054541317; Fri, 25 Sep 2020 10:22:21 -0700 (PDT) MIME-Version: 1.0 References: <01000174c4eeb24e-c672ebe0-23a1-4f0e-afba-5b44d932e0ed-000000@email.amazonses.com> <01000174c631e0c3-8b790f60-b8f4-44f1-9d7f-e6a1d826ecd4-000000@email.amazonses.com> In-Reply-To: <01000174c631e0c3-8b790f60-b8f4-44f1-9d7f-e6a1d826ecd4-000000@email.amazonses.com> From: Andy Bierman Date: Fri, 25 Sep 2020 10:22:10 -0700 Message-ID: To: Kent Watsen Cc: "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000339f0905b0268f88" Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 17:22:25 -0000 --000000000000339f0905b0268f88 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 25, 2020 at 9:56 AM Kent Watsen wrote: > Hi Andy, > > > This has been discussed a few times by the WG. > > > Perhaps a testament to it being a real problem? > > > The co-authors never agreed on the set of bells and whistles that should > be supported. > > > True, but it's more like we lost interest / time to work on it...at least > that's my story! ;) > > > There was an objection from Phil Shafer at the time that pagination was > not needed > at all and handling large responses from the server was just a minor > implementation detail. > > > Clearly Phil is in the rough, as many APIs support pagination for a > reason. Even if constraining the solution to networking gear, interfaces > and logs may be numerous, and on-box cli/web UIs can only show a screen > at a time... > > Our customers agree with you. Some of them only use our , and stopped using and . Since it is implemented as an RPC, all YANG-based protocols can use it. Obviously you need XPath filtering (XSLT-style) to select the list entries of interest. Count and depth and other parameters from are also useful. (My concern is that the IETF version will be too complex to implement or use as the feature list grows.) IMO, it's okay if we don't support for CT-lists (i.e., interfaces). As you > write above, and I wrote in before, it seems like a nice-to-have. FYI, > I'm asking Per in a fork of this thread to justify if supporting CT-lists > is a "must-have"...hopefully he'll come back with something compelling. > > There is no extra complexity to support config vs. operational data. I don't see the value in restricting the operation. > CF-lists, on the other hand, can be enormous...so much so that trying to > return all could exhaust server and/or client resources. I think > supporting CF-lists is a must-have. > > > The most significant objection was that this is a RESTCONF-only solution > and that > was not acceptable to ignore NETCONF (since and GET end being the > same > in the end, so the problem also exists for NETCONF) > > > True. If we can find a way to extend support to NETCONF, all the better. > Of course, the solutions would be wildly different, much like how NMDA > had separate solutions for NC and RC (RFCs 8526 and 8527, respectively). > Perhaps Per or Martin can clue us into if they have a NC-equivalent > solution? > > It is easy. Use RPC operations which map to RESTCONF POST automatically. > However, if NC-support cannot be achieved, then I don't think it means we > don't do it for RC. Much like NC supports somethings RC doesn't (e.g., > confirmed commit), each protocol plays into its strengths. So mote it be. > > > Andy > > > K. > > > Andy --000000000000339f0905b0268f88 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Sep 25, 2020 at 9:56 AM Kent = Watsen <kent+ietf@watsen.net> wrote:
Hi Andy,

<= div>
This has been = discussed a few times by the WG.

Perhaps a testament to it being a real problem?


The co-authors ne= ver agreed on the set of bells and whistles=C2=A0that should be supported.<= /div>

True, but it's more l= ike we lost interest / time to work on it...at least that's my story! = =C2=A0;)


There was an objection from Phil Shafer at the time that paginat= ion was not needed
at all and handling large responses from the s= erver was just a minor implementation=C2=A0detail.

Clearly Phil is in the rough, as many APIs suppor= t pagination for a reason. =C2=A0 Even if constraining the solution to netw= orking gear, interfaces and logs=C2=A0may = be numerous, and on-box cli/web UIs can only show a screen at a time...



<= div>




<= div style=3D"overflow-wrap: break-word;">
However, if N= C-support cannot be achieved, then I don't think it means we don't = do it for RC. =C2=A0 Much like NC supports somethings RC doesn't (e.g.,= confirmed commit), each protocol plays into its strengths. =C2=A0 So mote = it be.


Andy

K.



--000000000000339f0905b0268f88-- From nobody Fri Sep 25 16:02:46 2020 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 0CE613A0AE0; Fri, 25 Sep 2020 16:02:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir via Datatracker To: Cc: draft-ietf-netconf-trust-anchors.all@ietf.org, netconf@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160107496501.14047.597283542214697710@ietfa.amsl.com> Reply-To: Yoav Nir Date: Fri, 25 Sep 2020 16:02:45 -0700 Archived-At: Subject: [netconf] Secdir last call review of draft-ietf-netconf-trust-anchors-13 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 23:02:45 -0000 Reviewer: Yoav Nir Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document defines a YANG model for managing a trust anchor store. It allows two kinds of trust anchors: certificates and raw public keys. However, certificates are not just containers for public keys. Certificates include attributes about key usage, path constraints and name constraints, all of which constrain the ability to use the public key, and are relevant for trust anchors. As far as I can tell the document does not include any attributes to equivalently constrain the use of the raw public keys. If the intention is that raw public keys will not be constrained, the document should state this explicitly. Perhaps this is clear to the people who worked on the document, but it's not clear to me. Are the trust anchors managed with this module supposed to be used to establish trust for the NETCONF or RESTCONF connections? Section 1.1 seems to suggest that it does, but then how is the bootstrap problem solved? How do we establish the NETCONF connection the first time, and if we are able to do that, why do we need more certificates? If the answer is no, and the certificates are to be used by other protocols, then perhaps some re-wording in section 1.1 would help to show this. Currently, it says: "This document presents ... YANG modules that are part of a collection of RFCs ... define configuration modules for clients and servers of both the NETCONF and RESTCONF protocols." The security considerations section is OK, especially sub-section 4.2. Sub-section 4.1 has the following: The YANG module defined in this document defines a mechanism called a "truststore" that, by its name, suggests that it will protect its contents from unauthorized modification. Perhaps this is my different perspective, but the name doesn't lead me to expect that it protects its contents. I think that the document should either just suggest that some mechanism to prevent unauthorized modification should be used, or to present such a mechanism in detail. The current text suggests is partially specific by mentioning digital signatures and non-volatile storage, but not explaining where the trust for the digital signature comes from and what policies govern its us: In order to satisfy the expectations of a "truststore", it is RECOMMENDED that implementations ensure that the truststore contents are signed when persisted to non-volatile memory, to prevent unauthorized modifications from being made undetected. It is too vague to be a specification, but still unnecessarily constrains the solution space. I think the correct thing to do is to be explicitly vague and to just suggest some mechanism for protecting the content. From nobody Fri Sep 25 21:30:18 2020 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 0900E3A0FB5 for ; Fri, 25 Sep 2020 21:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 jmF7YfSyL8n6 for ; Fri, 25 Sep 2020 21:30:13 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 343D83A0FB3 for ; Fri, 25 Sep 2020 21:30:13 -0700 (PDT) Received: from lhreml726-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 6D2DEDC7B05FD9DE2E6A for ; Sat, 26 Sep 2020 05:30:08 +0100 (IST) Received: from lhreml726-chm.china.huawei.com (10.201.108.77) by lhreml726-chm.china.huawei.com (10.201.108.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Sat, 26 Sep 2020 05:30:08 +0100 Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml726-chm.china.huawei.com (10.201.108.77) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Sat, 26 Sep 2020 05:30:07 +0100 Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.160]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0487.000; Sat, 26 Sep 2020 12:30:02 +0800 From: Qin Wu To: Andy Bierman , Kent Watsen CC: "netconf@ietf.org" Thread-Topic: [netconf] restconf collections Thread-Index: AdaTu7oM6Ull5jqeThCPAKA7zO9G3A== Date: Sat, 26 Sep 2020 04:30:01 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.233.90] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAADA1006Edggeml511mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2020 04:30:16 -0000 --_000_B8F9A780D330094D99AF023C5877DABAADA1006Edggeml511mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 5Y+R5Lu25Lq6OiBuZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSDku6Po oaggQW5keSBCaWVybWFuDQrlj5HpgIHml7bpl7Q6IDIwMjDlubQ55pyIMjbml6UgMToyMg0K5pS2 5Lu25Lq6OiBLZW50IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5uZXQ+DQrmioTpgIE6IG5ldGNv bmZAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtuZXRjb25mXSByZXN0Y29uZiBjb2xsZWN0aW9ucw0K DQoNCg0KT24gRnJpLCBTZXAgMjUsIDIwMjAgYXQgOTo1NiBBTSBLZW50IFdhdHNlbiA8a2VudCtp ZXRmQHdhdHNlbi5uZXQ8bWFpbHRvOmtlbnQlMkJpZXRmQHdhdHNlbi5uZXQ+PiB3cm90ZToNCkhp IEFuZHksDQoNCg0KDQpUaGlzIGhhcyBiZWVuIGRpc2N1c3NlZCBhIGZldyB0aW1lcyBieSB0aGUg V0cuDQoNClBlcmhhcHMgYSB0ZXN0YW1lbnQgdG8gaXQgYmVpbmcgYSByZWFsIHByb2JsZW0/DQoN Cg0KDQpUaGUgY28tYXV0aG9ycyBuZXZlciBhZ3JlZWQgb24gdGhlIHNldCBvZiBiZWxscyBhbmQg d2hpc3RsZXMgdGhhdCBzaG91bGQgYmUgc3VwcG9ydGVkLg0KDQpUcnVlLCBidXQgaXQncyBtb3Jl IGxpa2Ugd2UgbG9zdCBpbnRlcmVzdCAvIHRpbWUgdG8gd29yayBvbiBpdC4uLmF0IGxlYXN0IHRo YXQncyBteSBzdG9yeSEgIDspDQoNCg0KDQpUaGVyZSB3YXMgYW4gb2JqZWN0aW9uIGZyb20gUGhp bCBTaGFmZXIgYXQgdGhlIHRpbWUgdGhhdCBwYWdpbmF0aW9uIHdhcyBub3QgbmVlZGVkDQphdCBh bGwgYW5kIGhhbmRsaW5nIGxhcmdlIHJlc3BvbnNlcyBmcm9tIHRoZSBzZXJ2ZXIgd2FzIGp1c3Qg YSBtaW5vciBpbXBsZW1lbnRhdGlvbiBkZXRhaWwuDQoNCkNsZWFybHkgUGhpbCBpcyBpbiB0aGUg cm91Z2gsIGFzIG1hbnkgQVBJcyBzdXBwb3J0IHBhZ2luYXRpb24gZm9yIGEgcmVhc29uLiAgIEV2 ZW4gaWYgY29uc3RyYWluaW5nIHRoZSBzb2x1dGlvbiB0byBuZXR3b3JraW5nIGdlYXIsIGludGVy ZmFjZXMgYW5kIGxvZ3MgbWF5IGJlIG51bWVyb3VzLCBhbmQgb24tYm94IGNsaS93ZWIgVUlzIGNh biBvbmx5IHNob3cgYSBzY3JlZW4gYXQgYSB0aW1lLi4uDQoNCg0KDQpPdXIgY3VzdG9tZXJzIGFn cmVlIHdpdGggeW91LiAgU29tZSBvZiB0aGVtIG9ubHkgdXNlIG91ciA8Z2V0LWJ1bGs+LCBhbmQg c3RvcHBlZCB1c2luZyA8Z2V0PiBhbmQgPGdldC1jb25maWc+Lg0KU2luY2UgaXQgaXMgaW1wbGVt ZW50ZWQgYXMgYW4gUlBDLCBhbGwgWUFORy1iYXNlZCBwcm90b2NvbHMgY2FuIHVzZSBpdC4NCk9i dmlvdXNseSB5b3UgbmVlZCBYUGF0aCBmaWx0ZXJpbmcgKFhTTFQtc3R5bGUpIHRvIHNlbGVjdCB0 aGUgbGlzdCBlbnRyaWVzIG9mIGludGVyZXN0Lg0KQ291bnQgYW5kIGRlcHRoIGFuZCBvdGhlciBw YXJhbWV0ZXJzIGZyb20gPGdldD4gYXJlIGFsc28gdXNlZnVsLg0KDQooTXkgY29uY2VybiBpcyB0 aGF0IHRoZSBJRVRGIHZlcnNpb24gd2lsbCBiZSB0b28gY29tcGxleCB0byBpbXBsZW1lbnQgb3Ig dXNlIGFzIHRoZSBmZWF0dXJlIGxpc3QgZ3Jvd3MuKQ0KW1Fpbl06VGhhdOKAmXMgdGhlIGlzc3Vl IHdlIHRyeSB0byBhZGRyZXNzIGluIG91ciBjdXN0b21lcuKAmXMgc2NlbmFyaW9zLiBJZiB0aGUg c29sdXRpb24gb25seSBmb2N1c2VzIG9uIGxpc3QsIHRoZSBjb21wbGV4aXR5IGlzIGNvbnRyb2xs YWJsZS4gSWYgdGhlIHNjb3BlIGlzIG5vdCBsaW1pdGVkIHRvIGxpc3QsIFhBUFRIIGZpbHRlcmlu ZyBhbmQgcXVlcnkgYWN0dWFsbHkgcHJvdmlkZXMgYSBnb29kIHNvbHV0aW9uIHRvIG5hdmlnYXRl IGZyb20gcm9vdCBub2RlIHRvIGxlYWYgbm9kZS4NCg0KSU1PLCBpdCdzIG9rYXkgaWYgd2UgZG9u J3Qgc3VwcG9ydCBmb3IgQ1QtbGlzdHMgKGkuZS4sIGludGVyZmFjZXMpLiAgQXMgeW91IHdyaXRl IGFib3ZlLCBhbmQgSSB3cm90ZSBpbiBiZWZvcmUsIGl0IHNlZW1zIGxpa2UgYSBuaWNlLXRvLWhh dmUuICAgRllJLCBJJ20gYXNraW5nIFBlciBpbiBhIGZvcmsgb2YgdGhpcyB0aHJlYWQgdG8ganVz dGlmeSBpZiBzdXBwb3J0aW5nIENULWxpc3RzIGlzIGEgIm11c3QtaGF2ZSIuLi5ob3BlZnVsbHkg aGUnbGwgY29tZSBiYWNrIHdpdGggc29tZXRoaW5nIGNvbXBlbGxpbmcuDQoNCg0KVGhlcmUgaXMg bm8gZXh0cmEgY29tcGxleGl0eSB0byBzdXBwb3J0IGNvbmZpZyB2cy4gb3BlcmF0aW9uYWwgZGF0 YS4NCkkgZG9uJ3Qgc2VlIHRoZSB2YWx1ZSBpbiByZXN0cmljdGluZyB0aGUgb3BlcmF0aW9uLg0K DQoNCkNGLWxpc3RzLCBvbiB0aGUgb3RoZXIgaGFuZCwgY2FuIGJlIGVub3Jtb3VzLi4uc28gbXVj aCBzbyB0aGF0IHRyeWluZyB0byByZXR1cm4gYWxsIGNvdWxkIGV4aGF1c3Qgc2VydmVyIGFuZC9v ciBjbGllbnQgcmVzb3VyY2VzLiAgIEkgdGhpbmsgc3VwcG9ydGluZyBDRi1saXN0cyBpcyBhIG11 c3QtaGF2ZS4NCg0KDQoNClRoZSBtb3N0IHNpZ25pZmljYW50IG9iamVjdGlvbiB3YXMgdGhhdCB0 aGlzIGlzIGEgUkVTVENPTkYtb25seSBzb2x1dGlvbiBhbmQgdGhhdA0Kd2FzIG5vdCBhY2NlcHRh YmxlIHRvIGlnbm9yZSBORVRDT05GIChzaW5jZSA8Z2V0PiBhbmQgR0VUIGVuZCBiZWluZyB0aGUg c2FtZQ0KaW4gdGhlIGVuZCwgc28gdGhlIHByb2JsZW0gYWxzbyBleGlzdHMgZm9yIE5FVENPTkYp DQoNClRydWUuICBJZiB3ZSBjYW4gZmluZCBhIHdheSB0byBleHRlbmQgc3VwcG9ydCB0byBORVRD T05GLCBhbGwgdGhlIGJldHRlci4gICBPZiBjb3Vyc2UsIHRoZSBzb2x1dGlvbnMgd291bGQgYmUg d2lsZGx5IGRpZmZlcmVudCwgbXVjaCBsaWtlIGhvdyBOTURBIGhhZCBzZXBhcmF0ZSBzb2x1dGlv bnMgZm9yIE5DIGFuZCBSQyAoUkZDcyA4NTI2IGFuZCA4NTI3LCByZXNwZWN0aXZlbHkpLiAgUGVy aGFwcyBQZXIgb3IgTWFydGluIGNhbiBjbHVlIHVzIGludG8gaWYgdGhleSBoYXZlIGEgTkMtZXF1 aXZhbGVudCBzb2x1dGlvbj8NCg0KDQpJdCBpcyBlYXN5LiBVc2UgUlBDIG9wZXJhdGlvbnMgd2hp Y2ggbWFwIHRvIFJFU1RDT05GIFBPU1QgYXV0b21hdGljYWxseS4NCg0KW1Fpbl06IEFncmVlLCBO RVRDT05GIGZyYWdtZW50IHByb3ZpZGUgYW4gZXhhbXBsZSBvbiB3aGF0IFJQQyBvcGVyYXRpb25z IGxvb2sgbGlrZQ0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoZW5nLW5ldGNv bmYtZnJhZ21lbnRhdGlvbi0wMg0Kd2hpY2ggaXMgc2ltaWxhciB0byBnZXRidWxrIG9wZXJhdGlv bi4NCg0KSG93ZXZlciwgaWYgTkMtc3VwcG9ydCBjYW5ub3QgYmUgYWNoaWV2ZWQsIHRoZW4gSSBk b24ndCB0aGluayBpdCBtZWFucyB3ZSBkb24ndCBkbyBpdCBmb3IgUkMuICAgTXVjaCBsaWtlIE5D IHN1cHBvcnRzIHNvbWV0aGluZ3MgUkMgZG9lc24ndCAoZS5nLiwgY29uZmlybWVkIGNvbW1pdCks IGVhY2ggcHJvdG9jb2wgcGxheXMgaW50byBpdHMgc3RyZW5ndGhzLiAgIFNvIG1vdGUgaXQgYmUu DQoNCg0KQW5keQ0KDQpLLg0KDQoNCg0KQW5keQ0KDQo= --_000_B8F9A780D330094D99AF023C5877DABAADA1006Edggeml511mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4w cHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/p m4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3Nw YW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPiBuZXRjb25m IFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXQ0KPC9zcGFuPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90Oyxz YW5zLXNlcmlmIj7ku6PooaggPC9zcGFuPg0KPC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fu cy1zZXJpZiI+QW5keSBCaWVybWFuPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlm Ij7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvl vq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+IDIwMjA8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMt c2VyaWYiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj45PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVT Ij4yNjwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+DQogMToyMjxicj4NCjwvc3Bhbj48Yj7m lLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi PiBLZW50IFdhdHNlbiAmbHQ7a2VudCYjNDM7aWV0ZkB3YXRzZW4ubmV0Jmd0Ozxicj4NCjwvc3Bh bj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiPiBuZXRjb25mQGlldGYub3JnPGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVO LVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJlOiBbbmV0Y29uZl0gcmVzdGNv bmYgY29sbGVjdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIEZyaSwgU2Vw IDI1LCAyMDIwIGF0IDk6NTYgQU0gS2VudCBXYXRzZW4gJmx0OzxhIGhyZWY9Im1haWx0bzprZW50 JTJCaWV0ZkB3YXRzZW4ubmV0Ij5rZW50JiM0MztpZXRmQHdhdHNlbi5uZXQ8L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBBbmR5LDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhpcyBoYXMgYmVlbiBkaXNjdXNzZWQgYSBm ZXcgdGltZXMgYnkgdGhlIFdHLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlBlcmhhcHMgYSB0ZXN0 YW1lbnQgdG8gaXQgYmVpbmcgYSByZWFsIHByb2JsZW0/PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPlRoZSBjby1hdXRob3JzIG5ldmVyIGFncmVlZCBvbiB0aGUgc2V0IG9mIGJlbGxzIGFuZCB3 aGlzdGxlcyZuYnNwO3RoYXQgc2hvdWxkIGJlIHN1cHBvcnRlZC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5UcnVlLCBidXQgaXQncyBtb3JlIGxpa2Ugd2UgbG9zdCBpbnRlcmVzdCAvIHRpbWUgdG8g d29yayBvbiBpdC4uLmF0IGxlYXN0IHRoYXQncyBteSBzdG9yeSEgJm5ic3A7Oyk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+VGhlcmUgd2FzIGFuIG9iamVjdGlvbiBmcm9tIFBoaWwgU2hhZmVy IGF0IHRoZSB0aW1lIHRoYXQgcGFnaW5hdGlvbiB3YXMgbm90IG5lZWRlZDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5hdCBhbGwgYW5kIGhhbmRsaW5nIGxhcmdlIHJlc3BvbnNlcyBmcm9tIHRoZSBzZXJ2 ZXIgd2FzIGp1c3QgYSBtaW5vciBpbXBsZW1lbnRhdGlvbiZuYnNwO2RldGFpbC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5DbGVhcmx5IFBoaWwgaXMgaW4gdGhlIHJvdWdoLCBhcyBtYW55IEFQSXMg c3VwcG9ydCBwYWdpbmF0aW9uIGZvciBhIHJlYXNvbi4gJm5ic3A7IEV2ZW4gaWYgY29uc3RyYWlu aW5nIHRoZSBzb2x1dGlvbiB0byBuZXR3b3JraW5nIGdlYXIsIGludGVyZmFjZXMgYW5kIGxvZ3Mm bmJzcDs8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPm1heSBiZSBudW1lcm91cywgYW5kIG9uLWJv eCBjbGkvd2ViIFVJcw0KIGNhbiBvbmx5IHNob3cgYSBzY3JlZW4gYXQgYSB0aW1lLi4uPC9zcGFu PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T3VyIGN1c3RvbWVycyBhZ3JlZSB3aXRoIHlvdS4mbmJz cDsgU29tZSBvZiB0aGVtIG9ubHkgdXNlIG91ciAmbHQ7Z2V0LWJ1bGsmZ3Q7LCBhbmQgc3RvcHBl ZCB1c2luZyAmbHQ7Z2V0Jmd0OyBhbmQgJmx0O2dldC1jb25maWcmZ3Q7LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5TaW5jZSBpdCBpcyBpbXBsZW1lbnRlZCBhcyBhbiBSUEMsIGFsbCBZQU5HLWJhc2Vk IHByb3RvY29scyBjYW4gdXNlIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PYnZpb3VzbHkgeW91 IG5lZWQgWFBhdGggZmlsdGVyaW5nIChYU0xULXN0eWxlKSB0byBzZWxlY3QgdGhlIGxpc3QgZW50 cmllcyBvZiBpbnRlcmVzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q291bnQgYW5kIGRlcHRoIGFu ZCBvdGhlciBwYXJhbWV0ZXJzIGZyb20gJmx0O2dldCZndDsgYXJlIGFsc28gdXNlZnVsLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+KE15IGNvbmNlcm4g aXMgdGhhdCB0aGUgSUVURiB2ZXJzaW9uIHdpbGwgYmUgdG9vIGNvbXBsZXggdG8gaW1wbGVtZW50 IG9yIHVzZSBhcyB0aGUgZmVhdHVyZSBsaXN0IGdyb3dzLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltRaW5dOlRoYXTigJlzIHRoZSBpc3N1ZSB3ZSB0cnkgdG8g YWRkcmVzcyBpbiBvdXIgY3VzdG9tZXLigJlzIHNjZW5hcmlvcy4gSWYgdGhlIHNvbHV0aW9uIG9u bHkgZm9jdXNlcyBvbiBsaXN0LCB0aGUgY29tcGxleGl0eSBpcyBjb250cm9sbGFibGUuIElmIHRo ZSBzY29wZSBpcyBub3QgbGltaXRlZCB0byBsaXN0LCBYQVBUSCBmaWx0ZXJpbmcgYW5kDQogcXVl cnkgYWN0dWFsbHkgcHJvdmlkZXMgYSBnb29kIHNvbHV0aW9uIHRvIG5hdmlnYXRlIGZyb20gcm9v dCBub2RlIHRvIGxlYWYgbm9kZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBj bSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5JTU8sIGl0J3Mgb2theSBpZiB3ZSBkb24ndCBz dXBwb3J0IGZvciBDVC1saXN0cyAoaS5lLiwgaW50ZXJmYWNlcykuJm5ic3A7IEFzIHlvdSB3cml0 ZSBhYm92ZSwgYW5kIEkgd3JvdGUgaW4gYmVmb3JlLCBpdCBzZWVtcyBsaWtlIGEgbmljZS10by1o YXZlLiAmbmJzcDsgRllJLCBJJ20gYXNraW5nIFBlciBpbiBhIGZvcmsgb2YgdGhpcyB0aHJlYWQg dG8ganVzdGlmeQ0KIGlmJm5ic3A7c3VwcG9ydGluZyBDVC1saXN0cyBpcyBhICZxdW90O211c3Qt aGF2ZSZxdW90Oy4uLmhvcGVmdWxseSBoZSdsbCBjb21lIGJhY2sgd2l0aCBzb21ldGhpbmcgY29t cGVsbGluZy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGVyZSBpcyBubyBleHRyYSBjb21wbGV4aXR5 IHRvIHN1cHBvcnQgY29uZmlnIHZzLiBvcGVyYXRpb25hbCBkYXRhLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5JIGRvbid0IHNlZSB0aGUgdmFsdWUgaW4gcmVzdHJpY3RpbmcgdGhlIG9wZXJhdGlvbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPkNGLWxpc3RzLCBvbiB0aGUmbmJzcDtvdGhlciBoYW5kLCBjYW4gYmUgZW5vcm1v dXMuLi5zbyBtdWNoIHNvIHRoYXQgdHJ5aW5nIHRvIHJldHVybiBhbGwgY291bGQgZXhoYXVzdCBz ZXJ2ZXIgYW5kL29yIGNsaWVudCByZXNvdXJjZXMuICZuYnNwOyBJIHRoaW5rIHN1cHBvcnRpbmcg Q0YtbGlzdHMgaXMgYSBtdXN0LWhhdmUuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIG1vc3Qgc2lnbmlmaWNhbnQgb2JqZWN0aW9uIHdhcyB0 aGF0IHRoaXMgaXMgYSBSRVNUQ09ORi1vbmx5IHNvbHV0aW9uIGFuZCB0aGF0PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPndhcyBub3QgYWNjZXB0YWJsZSB0byBpZ25vcmUgTkVUQ09ORiAoc2luY2UgJmx0 O2dldCZndDsgYW5kIEdFVCBlbmQgYmVpbmcmbmJzcDt0aGUgc2FtZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5pbiB0aGUgZW5kLCBzbyB0aGUgcHJvYmxlbSBhbHNvIGV4aXN0cyBmb3IgTkVUQ09ORik8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UcnVlLiZuYnNwOyBJZiB3ZSBjYW4gZmluZCBhIHdheSB0 byBleHRlbmQgc3VwcG9ydCB0byBORVRDT05GLCBhbGwgdGhlIGJldHRlci4gJm5ic3A7IE9mIGNv dXJzZSwgdGhlIHNvbHV0aW9ucyB3b3VsZCBiZSB3aWxkbHkgZGlmZmVyZW50LCBtdWNoIGxpa2Ug aG93IE5NREEgaGFkIHNlcGFyYXRlIHNvbHV0aW9ucyBmb3IgTkMgYW5kIFJDIChSRkNzIDg1MjYg YW5kIDg1MjcsIHJlc3BlY3RpdmVseSkuJm5ic3A7DQogUGVyaGFwcyBQZXIgb3IgTWFydGluIGNh biBjbHVlIHVzIGludG8gaWYgdGhleSBoYXZlIGEgTkMtZXF1aXZhbGVudCBzb2x1dGlvbj88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SXQgaXMgZWFz eS4gVXNlIFJQQyBvcGVyYXRpb25zIHdoaWNoIG1hcCB0byBSRVNUQ09ORiBQT1NUIGF1dG9tYXRp Y2FsbHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltRaW5dOiBBZ3JlZSwgTkVUQ09ORiBmcmFnbWVu dCBwcm92aWRlIGFuIGV4YW1wbGUgb24gd2hhdCBSUEMgb3BlcmF0aW9ucyBsb29rIGxpa2U8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC16aGVuZy1uZXRjb25mLWZyYWdtZW50YXRpb24tMDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPndoaWNoIGlzIHNpbWlsYXIgdG8gZ2V0YnVsayBvcGVyYXRpb24u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SG93ZXZlciwgaWYgTkMtc3VwcG9ydCBjYW5u b3QgYmUgYWNoaWV2ZWQsIHRoZW4gSSBkb24ndCB0aGluayBpdCBtZWFucyB3ZSBkb24ndCBkbyBp dCBmb3IgUkMuICZuYnNwOyBNdWNoIGxpa2UgTkMgc3VwcG9ydHMgc29tZXRoaW5ncyBSQyBkb2Vz bid0IChlLmcuLCBjb25maXJtZWQgY29tbWl0KSwgZWFjaCBwcm90b2NvbCBwbGF5cyBpbnRvIGl0 cyBzdHJlbmd0aHMuICZuYnNwOyBTbyBtb3RlIGl0DQogYmUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPkFuZHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPksuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QW5k eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B8F9A780D330094D99AF023C5877DABAADA1006Edggeml511mbschi_-- From nobody Sat Sep 26 10:13:19 2020 Return-Path: <01000174cb61f1a5-766d1a04-cb3f-4f13-9547-5b3ae4974361-000000@amazonses.watsen.net> 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 815A33A0B77 for ; Sat, 26 Sep 2020 10:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 FhF2YPGRJKNw for ; Sat, 26 Sep 2020 10:13:15 -0700 (PDT) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 777413A0B6B for ; Sat, 26 Sep 2020 10:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1601140028; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=aMjg2U5y4NuFUp5FxEoLOZ39V/+tZ+N2yZ3tQ2rCATc=; b=cJ2j/W4hzeJgAySD+cuRKStlT1UslQ2EriwpgdC5jXO5Gg0tn3+B0FtChgg7yDXe kIN74lcU7Ukv9FSMscHQgD5RBZ7fjGYZXWYe0E6BOU3i5zmI50vf6MkegD2fBKWqOtu FOZqZ3CRxKSheZ/wPx23xFFt/Pdcbwm4YmLxeyws= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Kent Watsen In-Reply-To: Date: Sat, 26 Sep 2020 17:07:07 +0000 Cc: "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000174cb61f1a5-766d1a04-cb3f-4f13-9547-5b3ae4974361-000000@email.amazonses.com> References: <01000174c4eeb24e-c672ebe0-23a1-4f0e-afba-5b44d932e0ed-000000@email.amazonses.com> <01000174c631e0c3-8b790f60-b8f4-44f1-9d7f-e6a1d826ecd4-000000@email.amazonses.com> To: Andy Bierman X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.09.26-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2020 17:13:18 -0000 Hi Andy, > Our customers agree with you. Some of them only use our , = and stopped using and . > Since it is implemented as an RPC, all YANG-based protocols can use = it. > Obviously you need XPath filtering (XSLT-style) to select the list = entries of interest. > Count and depth and other parameters from are also useful. >=20 > (My concern is that the IETF version will be too complex to implement = or use as the feature list grows.) Ack. > There is no extra complexity to support config vs. operational data. > I don't see the value in restricting the operation. Okay. This appears to be the prevailing interest. > It is easy. Use RPC operations which map to RESTCONF POST = automatically. Gotcha. =20 These RPCs could also be used for RESTCONF, but much better would be to = use query parameters in the GET calls. K. From nobody Sat Sep 26 10:21:05 2020 Return-Path: <01000174cb6ea9ee-d7716c10-a691-4a97-9e99-022e4c0ef55a-000000@amazonses.watsen.net> 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 4E7143A0C00 for ; Sat, 26 Sep 2020 10:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 4LWFPm7tmuAY for ; Sat, 26 Sep 2020 10:21:03 -0700 (PDT) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0D0C3A0BFD for ; Sat, 26 Sep 2020 10:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1601140861; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=NDsA60OkoW2WPEtiULxaxwP4bnOv1b7rdakn44Laz0I=; b=H5+XM/XDuHKf5ZqagJpGz0Z7UHgg4RLP4ihp1D6WIZ5ITdkVOledhsUy2IB4+Wdk E02OOKe9SdIXA84W4u/IJVpk0wGO8Ycq/f7cgBnyymYZph3gWE6Iqwz8pCG5K4WdHZh I9wTcSixz+p93jb97qObQ+xO8mHjI3m3SH+5aSjc= From: Kent Watsen Message-ID: <01000174cb6ea9ee-d7716c10-a691-4a97-9e99-022e4c0ef55a-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C655D627-494A-42F6-9D7C-1E412FD750B5" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sat, 26 Sep 2020 17:21:01 +0000 In-Reply-To: Cc: Andy Bierman , "netconf@ietf.org" To: Qin Wu References: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.09.26-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2020 17:21:04 -0000 --Apple-Mail=_C655D627-494A-42F6-9D7C-1E412FD750B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Qin, > (My concern is that the IETF version will be too complex to implement = or use as the feature list grows.) > [Qin]:That=E2=80=99s the issue we try to address in our customer=E2=80=99= s scenarios. If the solution only focuses on list, the complexity is = controllable. If the scope is not limited to list, XAPTH filtering and = query actually provides a good solution to navigate from root node to = leaf node. The functionality is only for lists. The functionality (e.g., paging) = being discussed only make sense for lists... > It is easy. Use RPC operations which map to RESTCONF POST = automatically. > =20 > [Qin]: Agree, NETCONF fragment provide an example on what RPC = operations look like > https://tools.ietf.org/html/draft-zheng-netconf-fragmentation-02 > which is similar to getbulk operation. The RPC may be a good starting point. It would be good to = also look at Andy=E2=80=99s RPC for inspiration. K. --Apple-Mail=_C655D627-494A-42F6-9D7C-1E412FD750B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Qin,= --Apple-Mail=_C655D627-494A-42F6-9D7C-1E412FD750B5-- From nobody Sat Sep 26 10:31:30 2020 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 D7C8B3A0C1B for ; Sat, 26 Sep 2020 10:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 CRDxjzb57rBr for ; Sat, 26 Sep 2020 10:31:27 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::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 CD6A03A0C20 for ; Sat, 26 Sep 2020 10:31:26 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id n25so5031814ljj.4 for ; Sat, 26 Sep 2020 10:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JpTCdxXvHqsffSh04ZiK3UTfoLYSzqsCuDcz+g5l3bU=; b=UjRwYQyR1Qm3WsWZWAWaRxR9ucFADUo5zqHX7qWhTcNMUbmd3+m10Y4vosHboXOrYa WOM2l8+oOYJKrZXogPl2e+NdYbyf9wD56aag35K5zIeT29YuUewWtleb0PgOoo+P5/R4 Vyi8gHWZ3tQRH9g3XGL6wae0Phv6XO97UXrNXIV+6n3MGu2hRchLrf6S4Dy2o9L7+W6r BQxFm3xRRe+XxytH0HsQGCV4FpN8cxxfHtTbxuDaPyUvkniEzLUAQINsR8RNeMbzWHOu ofzAirKXnyygQ4hxEspSif5xBT7Os3cvmODXpyT06agoFFIXCnxh8JvAhTnXxJVz3BC9 w6yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JpTCdxXvHqsffSh04ZiK3UTfoLYSzqsCuDcz+g5l3bU=; b=EZCOzTsFhEexAb+I5q4Qyp2ehaSkUpXChs4EHcPOmOWoJVr4hdSCM8tIEI5v0JS28F IBCmHGZUh8ChYnqDQajnmmJSQKInSUIse7B6/bWSj/mjaXre5r2Xk65M6ZYs20VwmTUj tj06sjxzJlA62NTZYpjBIbhaPIAxNGM+F1k/L4mtPMhQR4Fo/dmiZ5jzSAntYWI2Yas4 90sazyeXZteWFuDFr4/8X8Yh01vlcQcQ59JFrHav3WPsmsEz5V/sG/2juMrla7LqsFmn fdW/OyLmZjzuu6b/HVVAz/UBXuL7zzLtr2I6ME3aqcpYI0xGNxp2sRdL/o4b1j6PR8gJ 2fUg== X-Gm-Message-State: AOAM530GCm4JIvo2y/h3p7UCqLi6ZMoJpj7Z4eXWRpFqwJQCdCcvZ3L1 xZFVcfe20szYYmGGDpxpb0bp/WZLd+EV2hE6dl4SmQ== X-Google-Smtp-Source: ABdhPJxlzX3l+dRjfUYU0oidWX54aAfIM4uDu5+jB/9CZXrzzxUwsk7DhH9mXoocQ7u76ogSmTXBrzgfabS/c2YdllA= X-Received: by 2002:a2e:7c14:: with SMTP id x20mr3148750ljc.220.1601141484561; Sat, 26 Sep 2020 10:31:24 -0700 (PDT) MIME-Version: 1.0 References: <01000174cb6ea9ee-d7716c10-a691-4a97-9e99-022e4c0ef55a-000000@email.amazonses.com> In-Reply-To: <01000174cb6ea9ee-d7716c10-a691-4a97-9e99-022e4c0ef55a-000000@email.amazonses.com> From: Andy Bierman Date: Sat, 26 Sep 2020 10:31:13 -0700 Message-ID: To: Kent Watsen Cc: Qin Wu , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006c3e5305b03acd53" Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2020 17:31:29 -0000 --0000000000006c3e5305b03acd53 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Sep 26, 2020 at 10:21 AM Kent Watsen wrote: > Hi Qin, > > (My concern is that the IETF version will be too complex to implement or > use as the feature list grows.) > > [Qin]:That=E2=80=99s the issue we try to address in our customer=E2=80=99= s scenarios. If > the solution only focuses on list, the complexity is controllable. If the > scope is not limited to list, XAPTH filtering and query actually provides= a > good solution to navigate from root node to leaf node. > > > The functionality is only for lists. The functionality (e.g., paging) > being discussed only make sense for lists... > > > It is easy. Use RPC operations which map to RESTCONF POST automatically. > > > > [Qin]: Agree, NETCONF fragment provide an example on what RPC operations > look like > > https://tools.ietf.org/html/draft-zheng-netconf-fragmentation-02 > > which is similar to getbulk operation. > > > The RPC may be a good starting point. It would be good to > also look at Andy=E2=80=99s RPC for inspiration. > > > The operation seems very stateful and seems to be tied to the existing get-config operation The operation is not stateful. http://www.netconfcentral.org/modulereport/yumaworks-getbulk There are 3 completely different approaches: 1) stateless 2) stateful 3) stateful snapshot How to efficiently iterate through data that is changing constantly? This problem is harder than it looks. K. > > Andy --0000000000006c3e5305b03acd53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Sep 26, 2020 at 10:21 AM Kent= Watsen <kent+ietf@watsen.net<= /a>> wrote:
<= div style=3D"overflow-wrap: break-word;">Hi Qin,

(My concern is that the IETF version will be too= complex to implement or use as the feature list grows.)

[Qin]:That=E2=80=99s the issue we try to address in our customer=E2=80= =99s scenarios. If the solution only focuses on list, the complexity is con= trollable. If the scope is not limited to list, XAPTH filtering and query actually provides a good solution to navigate from root node to leaf= node.


=
The functionality is only for lists.=C2=A0 The functionality (e.= g., paging) being discussed only make sense for lists...



--0000000000006c3e5305b03acd53-- From nobody Sat Sep 26 11:57:56 2020 Return-Path: <01000174cbc7532c-81a16bed-e752-4e61-9a97-dfc95be744b5-000000@amazonses.watsen.net> 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 910C43A03C9 for ; Sat, 26 Sep 2020 11:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 TfIGK4o6DzKR for ; Sat, 26 Sep 2020 11:57:53 -0700 (PDT) Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FEBE3A0317 for ; Sat, 26 Sep 2020 11:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1601146672; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=DpIKh0e/f0rcysCoeCBLKTgF/J7FydeNwsOI8sysK94=; b=CbFaLNoKacELU0kR7CFMT7k7djJCZi6BdrAuZS3qnKPgjGQ7+Jrkc5Qc633j8ngy O+Nh+DaTjgFg82ETVtuJlLeh899TNY6gm+nmZNwkTSXI8kA/0ADa2jDKEUHUXqnKYnI FKzExaV072RVZ+Y1w1+ZRxzTUpOI0Ahup3JooydI= From: Kent Watsen Message-ID: <01000174cbc7532c-81a16bed-e752-4e61-9a97-dfc95be744b5-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3877FE33-0692-4B20-9219-E5823051AAB4" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sat, 26 Sep 2020 18:57:51 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: Andy Bierman References: <01000174cb6ea9ee-d7716c10-a691-4a97-9e99-022e4c0ef55a-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.09.26-54.240.48.92 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2020 18:57:54 -0000 --Apple-Mail=_3877FE33-0692-4B20-9219-E5823051AAB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > The operation is not stateful. > http://www.netconfcentral.org/modulereport/yumaworks-getbulk = This RPC is effectively 1-1 with RC query params approach being = discussed. I like it. The =E2=80=9Ccount=E2=80=9D param is like =E2=80=9Climit=E2=80=9D, and = =E2=80=9Clist-test=E2=80=9D is like a =E2=80=9Cwhere=E2=80=9D. One difference is that uses "last-keys=E2=80=9D instead of an = integral =E2=80=9Coffset=E2=80=9D. Any thoughts about the pros and = cons? I imagine performance depends on the backend database used. For = instance, SQL supports =E2=80=9Coffset=E2=80=9D so, to support = "last-keys=E2=80=9D instead would entail a first query to determine the = offset for a key. Missing is a =E2=80=9Csort=E2=80=9D. That said, of the four params = mentioned (limit, offset, where, sort), it might be least important. At = least, a general sort is=E2=80=A6and then there is the nasty issue of = sorting a user-sorted list. A likely must-have fallback would be = =E2=80=9Cdirection=E2=80=9D so, e.g., queries return the most-recent = (not the oldest) entires in a time-series list (e.g., a log). A = =E2=80=9Cdirection=E2=80=9D parameter would also work well on a = user-sorted list. > There are 3 completely different approaches: >=20 > 1) stateless > 2) stateful > 3) stateful snapshot >=20 > How to efficiently iterate through data that is changing constantly? > This problem is harder than it looks. Agreed. I recommend we NOT try to solve that problem. K. --Apple-Mail=_3877FE33-0692-4B20-9219-E5823051AAB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
The = <get-bulk> operation is not stateful.
 http://www.netconfcentral.org/modulereport/yumaworks-getbulk






There are 3 completely different approaches:

  1) = stateless
  2) stateful
  3) stateful snapshot

How to efficiently iterate through data = that is changing constantly?
This problem is harder = than it looks.

Agreed.  I recommend we NOT try to solve that = problem.


K.

= --Apple-Mail=_3877FE33-0692-4B20-9219-E5823051AAB4-- From nobody Sun Sep 27 08:12:23 2020 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 1C3AC3A0FB6 for ; Sun, 27 Sep 2020 08:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 aydGN7YX8Qhj for ; Sun, 27 Sep 2020 08:12:20 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::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 1BA873A0FB5 for ; Sun, 27 Sep 2020 08:12:19 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id s205so6250772lja.7 for ; Sun, 27 Sep 2020 08:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TBiV/8W3GAtjTgK1fZ42tPkdxr7vald6tFYEdEYc3os=; b=m3dHBjni1ZD4Zj1ZH6YOpAaC9zKkql5lH3eolOKAMVP1bmBhcA+JXnEQxN2COUbFfg /EQl0qekEJFakU4dk3roV3v/FpvC8caLrhIOsYLUFen5fmHQqxdNHwdY/9FCIFzxfnA6 NCVVu9mcrl+BvLI8HMHOy57tdMREjA27cmzwzZb+4DqIVtJ+WRXeFTqQPdsWBKwJGlKr b0qfwMWeLbAlt3Mam52ECdZ+8eUtloOBfhsHwJDhg9BIVJtdchDkS1uvtzHIL8FtQlFr zw6S8bhgWqkSgeXkBTsdvdDZ/QILAYTOGdv3Fz4hHolEPkURYYcvGHzD1KGMd8Imjvn9 pMZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TBiV/8W3GAtjTgK1fZ42tPkdxr7vald6tFYEdEYc3os=; b=q9Aq4TPn4qlDfRPrqTs4QRqIlN0G1ygLCnpZXzVtLDzIstp6lbNJt/JWiDzx3VmUKf 9Q+72VNw0ZdnAGR98ZL72xageEtwEmqxefJ/xx2Yx/mCegPCUz9tArDoEgneVG/xkcoN icNhCWmwqHhpVYunUTRwcNb1FxeJoIq8cqq3M052G7d3J8HM/2+6UHof2hdE8zEGhyTH 1+HUEO8vytTbskO66Wg39IksJmwfUBJZJdbNDD+OwnpNDP6Xd2/JNfrTCWBbmBNg1vpj T0XVBuNGRlNNhCBk2EYZmRKqDEqS6GO0F8ppbFUDY5PkvZbF95iQ0YRJj2uG2QQqEq5G 1qWQ== X-Gm-Message-State: AOAM532mPh6JSYxIIAyfCuWRRMfHhxyhTOmad5CiUzDL0/gSU/CASEpo KsJ4gM1LroTz+6EvRndtrNV8dA3EeJWUH4r/aYe9MiyC9yfhoQ== X-Google-Smtp-Source: ABdhPJzhhQFEsz3O4a/xhfv8oyoUBJGj6oVG407VNyh+1ujcOmixJnBGDQMCM/La8llmu4S7HyH/2gUa/wg7cf0i32k= X-Received: by 2002:a2e:a550:: with SMTP id e16mr4049657ljn.125.1601219537456; Sun, 27 Sep 2020 08:12:17 -0700 (PDT) MIME-Version: 1.0 References: <01000174cb6ea9ee-d7716c10-a691-4a97-9e99-022e4c0ef55a-000000@email.amazonses.com> <01000174cbc7532c-81a16bed-e752-4e61-9a97-dfc95be744b5-000000@email.amazonses.com> In-Reply-To: <01000174cbc7532c-81a16bed-e752-4e61-9a97-dfc95be744b5-000000@email.amazonses.com> From: Andy Bierman Date: Sun, 27 Sep 2020 08:12:06 -0700 Message-ID: To: Kent Watsen Cc: "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bcf3fd05b04cf951" Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 15:12:22 -0000 --000000000000bcf3fd05b04cf951 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Sep 26, 2020 at 11:57 AM Kent Watsen wrote: > > The operation is not stateful. > http://www.netconfcentral.org/modulereport/yumaworks-getbulk > > > This RPC is effectively 1-1 with RC query params approach being > discussed. I like it. > > The =E2=80=9Ccount=E2=80=9D param is like =E2=80=9Climit=E2=80=9D, and = =E2=80=9Clist-test=E2=80=9D is like a =E2=80=9Cwhere=E2=80=9D. > > One difference is that uses "last-keys=E2=80=9D instead of an = integral > =E2=80=9Coffset=E2=80=9D. Any thoughts about the pros and cons? I imag= ine performance > depends on the backend database used. For instance, SQL supports =E2=80= =9Coffset=E2=80=9D > so, to support "last-keys=E2=80=9D instead would entail a first query to = determine > the offset for a key. > > It would be unlikely that a distributed server (e.g. data can come from linecards) that it is efficient to find the Nth entry. Using a count approach is obviously vulnerable to additions and deletions to the dataset. If the count keeps changing then the relative Nth entry also keeps changing= . This causes duplicates or missed entries in the paginated data. Using key values instead of a count this source of inaccuracy is eliminated. Both approache= s are vulnerable to "moved" entries (e.g. user-ordered list entry changes position). This can happen in theory but (1) user-ordered config=3Dfalse data is very rare, (2) the "move" operation for user-ordered data is very rarely used and (3) an entry would have to be moved just at the time the walk was in progress. > Missing is a =E2=80=9Csort=E2=80=9D. That said, of the four params menti= oned (limit, > offset, where, sort), it might be least important. At least, a general > sort is=E2=80=A6and then there is the nasty issue of sorting a user-sorte= d list. A > likely must-have fallback would be =E2=80=9Cdirection=E2=80=9D so, e.g., = queries return the > most-recent (not the oldest) entires in a time-series list (e.g., a log). > A =E2=80=9Cdirection=E2=80=9D parameter would also work well on a user-so= rted list. > sort is much more expensive to implement correctly and makes more sense when a stateful snapshot approach is used. Sorting each chunk vs. the entire data-set is not that useful. > > > There are 3 completely different approaches: > > 1) stateless > 2) stateful > 3) stateful snapshot > > How to efficiently iterate through data that is changing constantly? > This problem is harder than it looks. > > > Agreed. I recommend we NOT try to solve that problem. > > But we are solving that problem to some degree. Operational state is changing constantly and iterating through a list vs. a single GET usually makes the problem worse. > K. > > Andy --000000000000bcf3fd05b04cf951 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Sep 26, 2020 at 11:57 AM Kent= Watsen <kent+ietf@watsen.net<= /a>> wrote:
<= div style=3D"overflow-wrap: break-word;">

This RPC is effectively 1-1 with RC query pa= rams approach being discussed.=C2=A0 I like it.

Th= e =E2=80=9Ccount=E2=80=9D param is like =E2=80=9Climit=E2=80=9D, and =E2=80= =9Clist-test=E2=80=9D is like a =E2=80=9Cwhere=E2=80=9D.

One difference is that <get-bulk> uses "last-keys=E2=80= =9D instead of an integral =E2=80=9Coffset=E2=80=9D. =C2=A0 Any thoughts ab= out the pros and cons?=C2=A0 I imagine performance depends on the backend d= atabase used.=C2=A0 For instance, SQL supports =E2=80=9Coffset=E2=80=9D so,= to support "last-keys=E2=80=9D instead would entail a first query to = determine the offset for a key.



It would be unlikely that a distribute= d server (e.g. data can come from linecards)
that it is efficient= to find the Nth entry.

Using a count approach is = obviously vulnerable to additions and deletions to the dataset.
I= f the count keeps changing then the relative Nth entry also keeps changing.=
This causes duplicates or missed entries in the paginated data.= =C2=A0 Using key values
instead of a count this source of inaccur= acy is eliminated.=C2=A0 Both approaches
are vulnerable to "= moved" entries (e.g. user-ordered list entry changes position).
<= div>This can happen in theory but (1) user-ordered config=3Dfalse data is v= ery rare,
(2) the "move" operation for user-ordered dat= a is very rarely used and (3)
an entry would have to be moved jus= t at the time the walk was in progress.

=C2=A0
Missing is a =E2=80=9Csort=E2=80=9D= .=C2=A0 That said, of the four params mentioned (limit, offset, where, sort= ), it might be least important.=C2=A0 At least, a general sort is=E2=80=A6a= nd then there is the nasty issue of sorting a user-sorted list.=C2=A0 A lik= ely must-have fallback would be =E2=80=9Cdirection=E2=80=9D so, e.g., queri= es return the most-recent (not the oldest) entires in a time-series list (e= .g., a log).=C2=A0 A =E2=80=9Cdirection=E2=80=9D parameter would also work = well on a user-sorted list.


sort is much more expensive to implement correctly and ma= kes more
sense when a stateful snapshot approach is used. Sorting= each chunk
vs. the entire data-set is not that useful.

=C2=A0


T= here are 3 completely different approaches:

=C2=A0= 1) stateless
=C2=A0 2) stateful
=C2=A0 3) stateful sna= pshot

How to efficiently iterate through data that= is changing constantly?
This problem is harder than it looks.

Agreed.=C2=A0 I recom= mend we NOT try to solve that problem.



But we are solving that problem= to some degree.
Operational state is changing constantly and ite= rating through a list
vs. a single GET usually makes the problem = worse.


=

K.

Andy
=C2=A0
--000000000000bcf3fd05b04cf951-- From nobody Sun Sep 27 09:56:42 2020 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 8A7BE3A1031 for ; Sun, 27 Sep 2020 09:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.274, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 RjIz2AEXubcW for ; Sun, 27 Sep 2020 09:56:36 -0700 (PDT) Received: from mail.swisscom.com (mailout120.swisscom.com [138.188.166.120]) (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 1CB4D3A0A73 for ; Sun, 27 Sep 2020 09:56:35 -0700 (PDT) Received: by mail.swisscom.com; Sun, 27 Sep 2020 18:56:11 +0200 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_351930_1972777100.1601225770818" X-Mailer: Totemo_TrustMail_(Notification) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gUH14nmS2iRA1wVYnbSkgoSHUFhLYotD1/nle9YxT+/ODBBmynGZ1elk+FnCDpbP6ETWk5xb/4BnG5VtHAnWwTTDfnunsJYybbURzeKt6U0HfuG2tq1z2ncgLrDyzepVIdAt2LYx3S37vW2NVFi8zRwzsotIlzpDHiZA8nBCKSEPUXvMCGFXP8t57TFIPyWe1ZOk6+ObSg9WSmPlKc5aMK66b4eIjjpDHdu4s6jM3qa7Nz/QztaKBpKte1iNcZtuMYpABWRSn81OLsQEW1u3FjIOVes/KQPEhI8csBbjYNMBqShCTxbxDr4DxFM2gGO/SEdKgIJbdZdmDKyfHrIEWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7+KyBCPa+3dCTtgm5JHm9gslU35WQCINrTpy4L4XsN0=; b=WNf0yBfB2C1xNCgjVlDJfShQ/hlJeSEbIc+XC6soFKQr7jAEXKQFq2W+lOnAJrd91k2WivhwoEE1znQdE3PkVurJ0g3A3mE/eCFeNXBolYqoJY2M/RXRf4flv5WJYskUk7QmPWrqCSPayk3cNhq2k6KR8KYkiSFA+AbvIB7VD3W73j91CbzHt4X7X9SirS019u8OdVCulowRhMX+ZK/Bu4nRNQuNrDUyolVfA3X4zHEy/d1vIH7gC95S7loBl6Jd1e1MN9gZOAae6QX6uBPfEKgKaRZb1IdFMVUbjDncaapGwAI+8KOY66p5yDO42MWvjk/8/z3fKz11LT60dWEO9w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=swisscom.com; dmarc=pass action=none header.from=swisscom.com; dkim=pass header.d=swisscom.com; arc=none From: To: , CC: , Thread-Topic: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif Thread-Index: AQHWkGRu/yp90Vv9H0i3R7lOe+hPQ6lzrQCAgAAGrgCAADT1AIAA25YAgAEGzICAAIQ+AIAGbQRA Date: Sun, 27 Sep 2020 16:55:24 +0000 Message-ID: References: <01000173c0b07b33-ad0b793a-7afc-4b39-95f8-2f50574d57bb-000000@us-east-1.amazonses.com> <01000174b2ba9c57-cbc0d353-8d30-4885-8769-1ea869b4d0be-000000@email.amazonses.com> <01000174b2e0a349-52337b7b-81c3-4c56-a58b-36c95d68340f-000000@email.amazonses.com> <5c058aa40cbf4141b32b19bd53514415@huawei.com> <444c48abc18e4539acd4229075b5fb77@huawei.com> <52CC888C-2AA1-4ED2-9DD5-9C3994BC9D3E@gmail.com> In-Reply-To: <52CC888C-2AA1-4ED2-9DD5-9C3994BC9D3E@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Enabled=True; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Owner=Thomas.Graf@swisscom.com; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SetDate=2020-09-27T16:55:23.5481657Z; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Name=C2 General; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Application=Microsoft Azure Information Protection; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ActionId=bee5ee9e-1353-4c34-92c6-5e130a17cc71; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Extended_MSFT_Method=Automatic authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=swisscom.com; x-originating-ip: [138.188.166.41] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 05c2de96-7408-400b-cbd0-08d86306211d x-ms-traffictypediagnostic: ZR0P278MB0074: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: So81Ar1AUzxQx7FrdVvRFjrAwIJnMT9Gl3Q2iL3onXcpZlekStKdzm9NycFywYQXYcX/sOYj6C7cA03AIj86cb3L6TSv7C8Nd3hU+YpA5YwWGc7VnZc0hvi7alp46B2vkVvJDEWYZbK+ITBpeBDX/Hn+dNibIqd7MbHtn39WzXRatptXwb4UZqASOPB9RoiLDj9HVJnvPsedt/u8xJBwZHbwzFM44RuWOuTKzoyupSXXcY12cHHcqgrSPsSJCfIrshYdPlW7BTHIjPNgwrBLX2I8J8ATFyASLTAfNEng7wUA6xuz2gw7+iQRz3yAHM0zrSPYDGJgPQuMJ84F2FgNyJJK9g0Ma0GXgZJyqxvACdN/qxzdNlmHggimFAmomSOvtXc+PWVTKxv3reBzjyk2KiTbfE5vPSKBIj9hL2aGxgSjlKrMPHUJalF/Ob1SHg4W x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:ZRAP278MB0125.CHEP278.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(366004)(39850400004)(396003)(346002)(52536014)(10290500003)(478600001)(110136005)(7696005)(6506007)(166002)(66574015)(83380400001)(33656002)(4326008)(53546011)(8936002)(54906003)(966005)(9686003)(86362001)(316002)(26005)(186003)(55016002)(10300500001)(66446008)(64756008)(66556008)(66476007)(66946007)(76116006)(30864003)(8676002)(2906002)(5660300002)(71200400001)(559001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: wWEbocv5FDr+3oOQXL0K3f+9SvKnnWbXKLtriIID9ilNgLPy8HhLOZ714uTsM3Z08WMNuHrLwIfpJ/rU2oPwAJIp+ESKGv/fDjz8sdaeo48qE7LHIKe+5b6FGCB/dXawbWacbuPkeQnw627voUl/arDc+Jr/r74jeZgfKfUfrOTMtAwsKypf4xZ/UyrBfd9Ia99D1zlpv8YZI/3J4gLpiBE300gj5Amu9v3/+XSLuxwGNPUi/if4HB2cK5ZeW133gAWgOMaUX2WPTq+niSrtXswDIMWBnp8E/nz7yeKGeMf/MGmkdrU8GJz/Ul/jvU4HjxcCm6dkp4C1aJ79sgoRGTMBBZykQy0iQ2vZS0b9KF1ol58RUDXXIykHg0xmx318vsiwRa6YDrAeRs7FQGOX/O0TiBUzXgJXHC3qQzLu1+iQXg4MNYX6XI1Z9e/xkgTzuEC5SE0vm28bz23XYsaWT23F4VkX3ka5GXCUqGTjfloVFtt0Jf2IO0PsjVyqf15lCdnTQurwgH5a+Epsw8gT5lA0pE2EpvVlNa7dKmm9PAsN0tsf5NVnmHmItSet2j3OJsFT94RXZ3id5cPG/aZ9jeYaTHx1tdTS0NsAOwcZJHf4I0KHGB9TJPHaAi+ACFL60V94XqGv9XI8N90jl/CEAg== x-ms-exchange-transport-forked: True X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: ZRAP278MB0125.CHEP278.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 05c2de96-7408-400b-cbd0-08d86306211d X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2020 16:55:24.8932 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 364e5b87-c1c7-420d-9bee-c35d19b557a1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NEAVk/VmRH4RuH31lLiHPvFSjTbGGJqgd0+oirKbZLHdQsqNmKJCoTsF3Zk8ecky7hFRngsDED/iPLg1+VbUjjSEI7adu1mqw11mIEIGScI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: ZR0P278MB0074 X-OriginatorOrg: swisscom.com X-CFilter-Loop: Reflected X-Trustmail: processed Archived-At: Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 16:56:41 -0000 ------=_Part_351930_1972777100.1601225770818 Content-Type: multipart/alternative; boundary="_000_ZRAP278MB0125BBFC1798596A285C24B689340ZRAP278MB0125CHEP_" Content-Language: en-US --_000_ZRAP278MB0125BBFC1798596A285C24B689340ZRAP278MB0125CHEP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andy and Mahesh, As a coauthor of draft-unyte-netconf-distributed-notif. Thank you very much= for the feedback. Your remarks about reasoning of generator-id and augment= ing ietf-hardware.yang. Both are valid inputs which need to be further clar= ified. I like them very much. Same to IPFIX, draft-unyte-netconf-distributed-notif enables RFC8641 to wor= k with distributed forwarding systems as described in Section 1 of draft-un= yte-netconf-distributed-notif. https://tools.ietf.org/html/draft-unyte-netconf-distributed-notif-00#sectio= n-1 This documents complement the general subscription requirements defined in section 4.2.1 of [RFC7923] = by the paragraph: A Subscription Service MAY support the ability to export from multiple software processes on a single routing system and expose the information which software process produced which message to maintain data integrity. Since we are not re-inventing the wheel, generator-id Is already existing i= n IPFIX. It is called "Observation Domain ID". RFC 7011 Section 2 and Section 3.1 describe the terms "Observation Domain" = and "Observation Domain ID" https://tools.ietf.org/html/rfc7011#section-2 Observation Domain An Observation Domain is the largest set of Observation Points for which Flow information can be aggregated by a Metering Process. For example, a router line card may be an Observation Domain if it is composed of several interfaces, each of which is an Observation Point. In the IPFIX Message it generates, the Observation Domain includes its Observation Domain ID, which is unique per Exporting Process. That way, the Collecting Process can identify the specific Observation Domain from the Exporter that sends the IPFIX Messages. Every Observation Point is associated with an Observation Domain. It is RECOMMENDED that Observation Domain IDs also be unique per IPFIX Device. https://tools.ietf.org/html/rfc7011#section-3.1 Observation Domain ID A 32-bit identifier of the Observation Domain that is locally unique to the Exporting Process. The Exporting Process uses the Observation Domain ID to uniquely identify to the Collecting Process the Observation Domain that metered the Flows. It is RECOMMENDED that this identifier also be unique per IPFIX Device. Collecting Processes SHOULD use the Transport Session and the Observation Domain ID field to separate different export streams originating from the same Exporter. The Observation Domain ID SHOULD be 0 when no specific Observation Domain ID is relevant for the entire IPFIX Message, for example, when exporting the Exporting Process Statistics, or in the case of a hierarchy of Collectors when aggregated Data Records are exported. These are the only two paragraphs I found in RFC 7011 describing the reason= ing and application of "Observation Domain ID". Speaking from an network operators and a data-collection perspective, one o= f the reasons we use "Observation Domain ID" in IPFIX and "generator-id" in= YANG Notifications is to pin point from which network processor loss or co= rrupt metrics are coming from. In the last 12 months, we experienced twice,= that a network processor was programmed falsely. Just to give an example. As Tianran pointed out already and described in Section 7 of draft-unyte-ne= tconf-distributed-notif https://tools.ietf.org/html/draft-unyte-netconf-distributed-notif-00#sectio= n-7 All Publisher Agents share the same source IP address for data export. For connectionless data transport such as UDP based transport [I-D.unyte-netconf-udp-notif] the same Layer 4 source po= rt for data export can be used. For connection based data transport such as HTTPS based transport [I-D.ietf-netconf-https-notif], e= ach Publisher Agent MUST be able to acknowledge packet retrieval from Receivers, and therefore requires a dedicated Layer 4 source port per software process. The IP address and Layer 4 port transport information is not enough to iden= tify the export process of the network processor on the line card. This is also described in draft-unyte-netconf-udp-notif In section 3.2 https://tools.ietf.org/html/draft-unyte-netconf-udp-notif-00#section-3.2 The UDP-Notif Message Header contains information that facilitate the message transmission before deserializing the notification message. The data format is shown in Figure 2. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------+-------+---------------+-------------------------------+ | Vers. | ET | Header Len | Message Length | +-------+-------+---------------+-------------------------------+ | Message-Generator-ID | +---------------------------------------------------------------+ | Message ID | +---------------------------------------------------------------+ ~ Options ~ +---------------------------------------------------------------+ o Message-Generator-ID is a 32-bit identifier of the process which created the notification message. This allows disambiguation of an information source, such as the identification of different line cards sending the notification messages. The source IP address of the UDP datagrams SHOULD NOT be interpreted as the identifier for the host that originated the UDP-Notif message. Indeed, the streamer sending the UDP-Notif message could be a relay for the actual source of data carried within UDP-Notif messages. As for updating draft-unyte-netconf-udp-notif. I suggest that we update sec= tion 2 with the term "Generator" or I would prefer we re-use " Observation = Domain" and explain its meaning. We insert a new section between 2 and 3, a= nd describe reasons why the export process of the network processor on the = line card needs to be exposed to the receiver. Does that make sense to you Andy and Mahesh? Thoughts about the term "Gener= ator" or " Observation Domain"? Regarding augmenting ietf-hardware.yang. You are referring to RFC 8348 sect= ion 7 and 7.2 Correct? https://tools.ietf.org/html/rfc8348#section-7 https://tools.ietf.org/html/rfc8348#section-7.2 In section 7.1. and 7.2 I miss "network processor" and "line card", but "fa= bric" (to represent distributed forwarding systems) seems to present. Sine = Andy is one of the authors of RFC8348, could you give guidance how "network= processor" and "line card" would be augmented, if this should be part of d= raft-unyte-netconf-distributed-notif or a new draft, and what the reason fo= r such an augmentation would be in context to above description. >From my perspective, and please correct me if mistaken, one of the benefit = is that the loss could not only be matched to the network processor on a li= ne card, but also additional operational metrics could be retrieved from th= is network processor since the exact xpath would be known. IPFIX did not ha= ve such a modeling. Here we would have this benefit and could go one step f= urther. Best Wishes Thomas From: netconf On Behalf Of Mahesh Jethanandani Sent: Wednesday, September 23, 2020 4:44 PM To: Tianran Zhou Cc: netconf@ietf.org Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distrib= uted-notif Hi Tianran, I think you are finally articulating some of the reasons why you need the g= enerator-id. But they have nothing to do with being able to do data recover= y. In 108, the discussion on the mike made it clear that there was no expectat= ion of data recovery if it got lost over the unreliable transport. The char= acteristics of the data, e.g. statistics, over that transport had to be suc= h that subsequent updates would fill any gaps that were encountered because= of packet loss. If you stop receiving updates on a particular session, you= do not know if it was because the line card has nothing to send or it has = been removed. So the reasons for having a generator-id have to do with identifying the se= ssion or the line card where the data is originating from. The point that A= ndy raised about ietf-hardware therefore is relevant here. What happens if = the line card is removed and replaced with another but similar line card? W= hat generator-id would be used? What happens if the same line card is remov= ed and reinserted? What generator-id would be used? The draft needs to describe these as the problems it is solving, and how it= is going to solve it. On Sep 22, 2020, at 11:51 PM, Tianran Zhou > wrote: [As a contributor] Hi Tianran, I am confused by the value statement. Maybe you can help clarify. It would help if we can use a single terminology of publisher/subscriber in= stead of mixing it with client, which I understand to be the subscriber and= server which I understand to be the publisher. Note, if HTTPS is used, the= role of client and server would be reversed, so it is best to avoid using = those terms. See inline with [mj]. On Sep 21, 2020, at 7:04 PM, Tianran Zhou > wrote: Thanks Andy for your opinion. And thank Kent for your expansion and further= question. The goal is to allow the client to know if it has received all the data pie= ces. Furthermore, the client know which publisher failed to send data. Then= it depend on the client to do the action, e.g., ignore, require the data o= ne more, ... We just use the generator-id to indicate the publisher, as we find it in ie= tf-netconf-notification-messages, and it's very convenient for this usage. [mj] What usage would be that? The usage of generator-id to indicate who is= the publisher and thereby have the subscriber request for any missing data= ? I would like to note that nothing prevents usage of a reliable transport,= e.g. HTTPS or TCP, with this draft. Would you still need a generator-id? One use case is exactly as Kent mentioned "Answering myself here, perhaps i= t enables two servers on the same IP address to send to the same receiver, = as then the receiver doesn't solely rely on source-IP address (assuming una= uthenticated push) to designate the publisher". It's also OK for us to use another indicator if the generator-id is not fea= sible. [mj] Precisely. If you use a reliable transport, you would have other means= to identify the source of the notifications, in which case you would not n= eed the generator-id. ztr> Yes. But I just think if we can use the generator-id, we do not need t= o develop different ways for each transport. So that the procedure could be= consistent. Which goes back to the question of why we need a generator-id. If we do not= want data loss, we should be using a reliable transport, in which case we = do not need a generator-id. If we can tolerate data loss, e.g. with statist= ics, we do not care for generator-id because we are not going to ask for mi= ssing data. What use case requires us to use unreliable transport and yet n= eed a generator-id? ztr> Here we want to check the integrity, not the precise packet loss. For = reliable transport, the receiver know how many sessions need to establish f= or one subscription. On the other hand, if one session get lost, which sub= scriptions are impacted. For the unreliable transport, one more case is, if one session is really ba= d (say 50% packet loss), the subscriber may need to do some action/adjustme= nt. Yes we can tolerate data loss, but I think it should be a threshold. Thanks. "what seems to be missing is an ability for the client to determine which g= enerator-id is used by which publisher (e.g., line card). " If necessary, maybe we can extend this mapping in some initial exchanges. T= o be clear, how do you want to name the publisher? Thanks, Tianran From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent Watsen Sent: Tuesday, September 22, 2020 6:55 AM To: Andy Bierman > Cc: netconf@ietf.org Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distrib= uted-notif [As an individual contributor] The overall approach to the binary push features seems a bit incoherent to = me. I don't see much value in this draft, but no harm either so I do not have a= n objection to adoption. Perhaps there is some debugging value here but since the arch= itecture really does not define message generators as sub-components of a configured= subscription, a client cannot expect any sort of consistent implementation of this field. Good point. If I understand you correctly, what seems to be missing is an a= bility for the client to determine which generator-id is used by which publ= isher (e.g., line card). The solution enables the client to partition noti= fications coming from different publishers, but that is it. What value doe= s this have to the client, I don't know. Answering myself here, perhaps it enables two servers on the same IP addres= s to send to the same receiver, as then the receiver doesn't solely rely on= source-IP address (assuming unauthenticated push) to designate the publish= er? Can the authors help resolve the value-proposition question here? K. _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com Mahesh Jethanandani mjethanandani@gmail.com --_000_ZRAP278MB0125BBFC1798596A285C24B689340ZRAP278MB0125CHEP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andy and Mahes= h,

 

As a coauthor of = draft-unyte-netconf-distributed-notif. Thank you very much for the feedback= . Your remarks about reasoning of generator-id and augmenting ietf-hardware.yang. Both are valid inputs which need to be furt= her clarified. I like them very much.

 

Same to IPFIX, draft-unyte-netconf-=
distributed-notif enables RFC8641 to work with distributed forwarding syste=
ms as described in Section 1 of draft-unyte-netconf-distributed-notif.
 <=
o:p>
https://tools.ietf.org/html/draft-unyte-netc=
onf-distributed-notif-00#section-1
 
   This documents complement the general subscripti=
on requirements
   defined in section 4.2.1 of [RFC7923] by the paragraph: A
   Subscription Service MAY support the ability to =
export from multiple
   software processes on a single routing system an=
d expose the
   information which software process produced whic=
h message to maintain
   data integrity.=

 
 
Since we are not re-inventing the w=
heel, generator-id Is already existing in IPFIX. It is called "Observa=
tion Domain ID".
 <=
o:p>

RFC 7011 Section = 2 and Section 3.1 describe the terms "Observation Domain" and &qu= ot;Observation Domain ID"

 

https://tools.ietf.org/html/rfc7011#section= -2

 
   Observation Domain
 
      An Observation Domain is the l=
argest set of Observation Points for=

      which Flow information can be =
aggregated by a Metering Process.
      For example, a router line car=
d may be an Observation Domain if it=

      is composed of several interfa=
ces, each of which is an Observation=

      Point.  In the IPFIX Mess=
age it generates, the Observation Domain
      includes its Observation Domai=
n ID, which is unique per Exporting<=
/span>
      Process.  That way, the C=
ollecting Process can identify the
      specific Observation Domain fr=
om the Exporter that sends the IPFIX=

      Messages.  Every Observat=
ion Point is associated with an
      Observation Domain.  It i=
s RECOMMENDED that Observation Domain IDs<=
/o:p>
      also be unique per IPFIX Devic=
e.

 

https://tools.ietf.org/html/rfc7011#section= -3.1

 

   Observation Domain ID

 

      A 32-bit ide= ntifier of the Observation Domain that is locally

      unique to th= e Exporting Process.  The Exporting Process uses the

      Observation = Domain ID to uniquely identify to the Collecting

      Process the = Observation Domain that metered the Flows.  It is

      RECOMMENDED = that this identifier also be unique per IPFIX Device.

      Collecting P= rocesses SHOULD use the Transport Session and the

      Observation = Domain ID field to separate different export streams

      originating = from the same Exporter.  The Observation Domain ID

      SHOULD be 0 = when no specific Observation Domain ID is relevant for

      the entire I= PFIX Message, for example, when exporting the

      Exporting Pr= ocess Statistics, or in the case of a hierarchy of

      Collectors w= hen aggregated Data Records are exported.<= /o:p>

 

 

These are the onl= y two paragraphs I found in RFC 7011 describing the reasoning and applicati= on of "Observation Domain ID".

 

Speaking from an = network operators and a data-collection perspective, one of the reasons we = use "Observation Domain ID" in IPFIX and "generator-id" in YANG Notifications is to pin point from which network processor loss or= corrupt metrics are coming from. In the last 12 months, we experienced twi= ce, that a network processor was programmed falsely. Just to give an exampl= e.

 

As Tianran pointe= d out already and described in Section 7 of draft-unyte-netconf-distributed= -notif

 

https://tool= s.ietf.org/html/draft-unyte-netconf-distributed-notif-00#section-7

 

   All Publisher Agents share the same source IP ad=
dress for data
   export.  For connectionless data transport =
such as UDP based
   transport [I-D.unyte-netconf-udp-notif] the sam=
e Layer 4 source port
   for data export can be used.  For connectio=
n based data transport
   such as HTTPS based transport [I-D.ietf-netconf-https-notif], each

   Publisher Agent MUST be able to acknowledge pack=
et retrieval from


   Receivers, and therefore requires a dedicated La=
yer 4 source port per


   software process.


 


The IP address an=
d Layer 4 port transport information is not enough to identify the export p=
rocess of the network processor on the line card.


 


This is also desc=
ribed in draft-unyte-netconf-udp-notif In section 3.2


 


https://tools.ietf=
.org/html/draft-unyte-netconf-udp-notif-00#section-3.2


 


   The UDP-Notif Message Header contains informatio=
n that facilitate the


   message transmission before deserializing the no=
tification message.


   The data format is shown in Figure 2.


 


     0   &=
nbsp;           &nbs=
p;   1          =
;         2    =
            &nb=
sp;  3


     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 =
8 9 0 1 2 3 4 5 6 7 8 9 0 1

     +-------+-------+---------------+---=
----------------------------+=



     | Vers. |  ET   |&nbs=
p; Header Len   |      Message Length&nb=
sp;          |


     +-------+-------+---=
------------+-------------------------------+


     |      =
;            &n=
bsp;    Message-Generator-ID     &n=
bsp;            =
;  |


     +-----------------------------------=
----------------------------+=



     |      =
;            &n=
bsp;    Message ID       =
            &nb=
sp;          |


     +-----------------------------------=
----------------------------+=



     ~      =
;            &n=
bsp;    Options       &nb=
sp;            =
             ~<=
/span>


     +-----------------------------------=
----------------------------+=



 


   o  Message-Generator-ID is a 32-bit identif=
ier of the process which

      created the notification messa=
ge.  This allows disambiguation of


      an information source, such as=
 the identification of different


      line cards sending the notific=
ation messages.  The source IP<=
/span>


      address of the UDP datagrams S=
HOULD NOT be interpreted as the


      identifier for the host that o=
riginated the UDP-Notif message.


      Indeed, the streamer sending t=
he UDP-Notif message could be a


      relay for the actual source of=
 data carried within UDP-Notif


      messages.


 


As for updating d=
raft-unyte-netconf-udp-notif. I suggest that we update section 2 with the t=
erm "Generator" or I would prefer we re-use " Observation
 Domain" and explain its meaning. We insert a new section between 2 an=
d 3, and describe reasons why the export process of the network processor o=
n the line card needs to be exposed to the receiver.


 


Does that make se=
nse to you Andy and Mahesh? Thoughts about the term "Generator" o=
r " Observation Domain"?


 


Regarding augment=
ing ietf-hardware.yang. You are referring to RFC 8348 section 7 and 7.2 Cor=
rect?


 


https://tools.ietf.org/html/rfc8348#sec=
tion-7


https://tools.ietf.org/html/rfc8348#sec=
tion-7.2


 


In section 7.1. a=
nd 7.2 I miss "network processor" and "line card", but =
"fabric" (to represent distributed forwarding systems) seems to p=
resent.
 Sine Andy is one of the authors of RFC8348, could you give guidance how &q=
uot;network processor" and "line card" would be augmented, i=
f this should be part of draft-unyte-netconf-distributed-notif or a new dra=
ft, and what the reason for such an augmentation would
 be in context to above description.=



 


From my perspecti=
ve, and please correct me if mistaken, one of the benefit is that the loss =
could not only be matched to the network processor
 on a line card, but also additional operational metrics could be retrieved=
 from this network processor since the exact xpath would be known. IPFIX di=
d not have such a modeling. Here we would have this benefit and could go on=
e step further.


 


Best Wishes


Thomas



 






From: netconf <netconf-bounces@ietf.org>
On Behalf Of Mahesh Jethanandani

Sent: Wednesday, September 23, 2020 4:44 PM

To: Tianran Zhou <zhoutianran@huawei.com>

Cc: netconf@ietf.org

Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-=
distributed-notif






 


Hi Tianran,




 






I think you are finally articulating some of the rea=
sons why you need the generator-id. But they have nothing to do with being =
able to do data recovery.






 






In 108, the discussion on the mike made it clear tha=
t there was no expectation of data recovery if it got lost over the unrelia=
ble transport. The characteristics of the data, e.g. statistics, over that =
transport had to be such that subsequent
 updates would fill any gaps that were encountered because of packet loss. =
If you stop receiving updates on a particular session, you do not know if i=
t was because the line card has nothing to send or it has been removed.&nbs=
p;






 






So the reasons for having a generator-id have to do =
with identifying the session or the line card where the data is originating=
 from. The point that Andy raised about ietf-hardware therefore is relevant=
 here. What happens if the line card
 is removed and replaced with another but similar line card? What generator=
-id would be used? What happens if the same line card is removed and reinse=
rted? What generator-id would be used?






 






The draft needs to describe these as the problems it=
 is solving, and how it is going to solve it.















On Sep 22, 2020, at 11:51 PM, Tianran Zhou <zhoutianran@huawei.com> wrote:<=
o:p>






 




 






[As a contributor]








 










Hi Tianran,








 










I am confused by the value statement. Maybe you =
can help clarify.










 










It would help if we can use a single terminology=
 of publisher/subscriber instead of mixing it with client, which I understa=
nd to be the subscriber and server which I understand
 to be the publisher. Note, if HTTPS is used, the role of client and server=
 would be reversed, so it is best to avoid using those terms.










 










See inline with [mj].

























On Sep 21, 2020, at 7:04 PM, Tianran Zhou <zhout=
ianran@huawei.com> wrote:








 










Thanks Andy for your o=
pinion. And thank Kent for your expansion and further question.<=
o:p>






The goal is to allow t=
he client to know if it has received all the data pieces. Furthermore, the =
client know which publisher failed to send data. Then it depend on the clie=
nt to do the action, e.g., ignore, require
 the data one more, …






We just use the genera=
tor-id to indicate the publisher, as we find it in i=
etf-netconf-notification-messages,
 and it’s very convenient for this usage.














 








[mj] What usage would be that? The usage of gene=
rator-id to indicate who is the publisher and thereby have the subscriber r=
equest for any missing data? I would like to note
 that nothing prevents usage of a reliable transport, e.g. HTTPS or TCP, wi=
th this draft. Would you still need a generator-id?










 












One use case is exactl=
y as Kent mentioned “Answering myself here, perhaps it enables two se=
rvers on the same IP address to send to the same receiver, as then the rece=
iver doesn’t solely rely on source-IP address
 (assuming unauthenticated push) to designate the publisher”.<=
span style=3D"font-size:12.0pt;font-family:"Times New Roman",seri=
f">






It’s also OK for=
 us to use another indicator if the generator-id is not feasible.














 








[mj] Precisely. If you use a reliable transport,=
 you would have other means to identify the source of the notifications, in=
 which case you would not need the generator-id.










 






ztr> Yes. But I jus=
t think if we can use the generator-id, we do not need to develop different=
 ways for each transport. So that the procedure could be consistent.=







 =











Which goes back to the question of why we need a=
 generator-id. If we do not want data loss, we should be using a reliable t=
ransport, in which case we do not need a generator-id.
 If we can tolerate data loss, e.g. with statistics, we do not care for gen=
erator-id because we are not going to ask for missing data. What use case r=
equires us to use unreliable transport and yet need a generator-id?










 






ztr> Here we want t=
o check the integrity, not the precise packet loss. For reliable transport,=
 the receiver know how many sessions need to establish for one subscription=
. On the other hand,  if one session get
 lost, which subscriptions are impacted.






For the unreliable tra=
nsport, one more case is, if one session is really bad (say 50% packet loss=
), the subscriber may need to do some action/adjustment. Yes we can tolerat=
e data loss, but I think it should be
 a threshold. =







 =











Thanks.





























“what seems to b=
e missing is an ability for the client to determine which generator-id is u=
sed by which publisher (e.g., line card). ”






If necessary, maybe we=
 can extend this mapping in some initial exchanges. To be clear, how do you=
 want to name the publisher?






 =







Thanks,






Tianran






 =











From:&n=
bsp;netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent
 Watsen

Sent: Tuesday, Sep=
tember 22, 2020 6:55 AM

To: Andy Bierman &=
lt;andy=
@yumaworks.com>

Cc: netconf@ietf.org=


Subject: Re: [netc=
onf] Adoption-suitability for draft-unyte-netconf-distributed-notif










 








[As an individual contributor]=









 
















The overall approach to the binary push features =
seems a bit incoherent to me.










I don't see much value in this draft, but no harm=
 either so I do not have an objection










to adoption.  Perhaps there is some debuggin=
g value here but since the architecture










really does not define message generators as sub-=
components of a configured subscription,










a client cannot expect any sort of consistent imp=
lementation of this field.
















 










Good point. If I understand you correctly, what =
seems to be missing is an ability for the client to determine which generat=
or-id is used by which publisher (e.g., line card).
  The solution enables the client to partition notifications coming fr=
om different publishers, but that is it.  What value does this have to=
 the client, I don’t know.  










 










Answering myself here, perhaps it enables two se=
rvers on the same IP address to send to the same receiver, as then the =
;receiver doesn’t solely rely on source-IP address
 (assuming unauthenticated push) to designate the publisher?





























Can the authors help resolve the value-propositi=
on question here?










 










K.








 










 










_______________________________________________<=
br>
netconf mailing list

netconf@i=
etf.org

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












 














Mahesh Jethanandani











 










 






 =







 














 










Mahesh Jethanandani=








 =







 =





 




 
--_000_ZRAP278MB0125BBFC1798596A285C24B689340ZRAP278MB0125CHEP_-- ------=_Part_351930_1972777100.1601225770818 Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCAMIIG QTCCBSmgAwIBAgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCQ0gxFTATBgNVBAoTDFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFs IFNpbHZlciBDQSAyMDE0IC0gRzIyMB4XDTE5MDQxMTE2NDgyOFoXDTIyMDQxMTE2NDgyOFowgYEx CzAJBgNVBAYTAkNIMR4wHAYDVQQKExVTd2lzc2NvbSAoU2Nod2VpeikgQUcxJzAlBgkqhkiG9w0B CQEWGHRob21hcy5ncmFmQHN3aXNzY29tLmNvbTEpMCcGA1UEAxMgU2VjdXJlIE1haWw6IEdhdGV3 YXkgQ2VydGlmaWNhdGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCITr0/mumt/DE7 c8RDgwoi0IdMVLbGMQ1wzpjZ23C3KaauDnIDCAdgwJCj8H/4hy8Wj/EoKvbnJXc3DN/g5n4MyujX JjsLMo3cMaHqTSql2zKFsdFRnjNtOTEQMVleqnKgeiLwF5M+QpZGhS9T9M4br9PCKBEdwZ+BJRJN XPtxUjJWLh7ueFbMApS5lOryeoZrv9Yi6D5xSGErBuPrzn1ekUMzOfycZ4HcyLaEfzGNgYEax2yS 1/ZcM/qoj7k8e6dskfB6/PkFnf5BfWqwfWtmqn7PRJQQAEmjkJafFZNtvlyJ/ktjpI+pnju1AZaA c+LNL1eT1rwNdesrljxik/plAgMBAAGjggLZMIIC1TAjBgNVHREEHDAagRh0aG9tYXMuZ3JhZkBz d2lzc2NvbS5jb20wDgYDVR0PAQH/BAQDAgSwMBMGA1UdJQQMMAoGCCsGAQUFBwMEMB0GA1UdDgQW BBTAJbWmkqWsxJzHeilKdMU8NUhnwzAfBgNVHSMEGDAWgBTwx6MykbXryrVYdxWnTr4aXWFDJTCB /wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNzc2lnbi5uZXQvRjBDN0EzMzI5MUI1 RUJDQUI1NTg3NzE1QTc0RUJFMUE1RDYxNDMyNTCBqKCBpaCBooaBn2xkYXA6Ly9kaXJlY3Rvcnku c3dpc3NzaWduLm5ldC9DTj1GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1 JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmpl Y3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBrBgNVHSAEZDBiMFYGCWCFdAFZAQMBCzBJMEcG CCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tL1N3aXNzU2lnbi1TaWx2 ZXItQ1AtQ1BTLnBkZjAIBgYEAI96AQMwgdkGCCsGAQUFBwEBBIHMMIHJMGQGCCsGAQUFBzAChlho dHRwOi8vc3dpc3NzaWduLm5ldC9jZ2ktYmluL2F1dGhvcml0eS9kb3dubG9hZC9GMEM3QTMzMjkx QjVFQkNBQjU1ODc3MTVBNzRFQkUxQTVENjE0MzI1MGEGCCsGAQUFBzABhlVodHRwOi8vc2lsdmVy LXBlcnNvbmFsLWcyLm9jc3Auc3dpc3NzaWduLm5ldC9GMEM3QTMzMjkxQjVFQkNBQjU1ODc3MTVB NzRFQkUxQTVENjE0MzI1MA0GCSqGSIb3DQEBCwUAA4IBAQBPAGaURtN/46Vopba1sQJzad0O2JxG 8MwpE2F435dz+BfK/L8DGWN+EmWQV9k/p/IhNLFnj9WhBdd+iuscOT83XDCnUzyYiNqz7bhrQAEm B/87tdMsPhq5wUz5XfpnDcsSiQ1r/Woo+baMSN60QruEZM/be9mFILGOByV8BEwVbZTAiL7cLaOh bxUfQubFvyfOZ1HgJMVyfWizDVvDG2rL6YkWtsIBaVmCYGBqHrX0wSLyHlRNnbqiM2vawqQYme+1 +wxtbGCPPexp3wUBqpJde40Ke1xIpMj8c1kyvtaRM3CBX2p6xl0XHnSrybkJUidmaZnblUM6O18u b28x6Qp3MIIGvjCCBKagAwIBAgIPBUTWTq0e0zbVMkBdALk2MA0GCSqGSIb3DQEBCwUAMEcxCzAJ BgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxITAfBgNVBAMTGFN3aXNzU2lnbiBTaWx2 ZXIgQ0EgLSBHMjAeFw0xNDA5MTkyMDM2NDlaFw0yOTA5MTUyMDM2NDlaMFYxCzAJBgNVBAYTAkNI MRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBTaWx2 ZXIgQ0EgMjAxNCAtIEcyMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMs5sTmF/vrJ obzDg6kOSi2Ech7/aMWnxB3sD9eoixMes9EWi0DcD1NvAT3s6GS1l9uDvKiowIQ4WF4DFCvmyjDv ALLrEzkZkkcqIQDlcs3CMWIOzFYq/3fEY4yYwm9417W2zOl9HzOmkQUq/tFS1vTsnP5NTGpS4YV2 Yru5aOZSY/zBIZGSXRnY3IDRGeNJFlcCDhlEhaspyS/6xm1rCqH29/9rYTUVJpSUAmklXWn3vV5r gtmQDAb5QwUiSes20CBaYxDjOCHVfxYrQYpGevJn6KTQuh5/JCd1mJRJLVbEVDORnWL51V/eW6kV mJyUU8GA6QkXFbQbgCkyodCvE6cCAwEAAaOCApYwggKSMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB Af8ECDAGAQH/AgEAMB0GA1UdDgQWBBTwx6MykbXryrVYdxWnTr4aXWFDJTAfBgNVHSMEGDAWgBQX oM3B5EG2Ols7y0WdvRzCmPqGWDCB/wYDVR0fBIH3MIH0MEegRaBDhkFodHRwOi8vY3JsLnN3aXNz c2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5OEZBODY1ODCBqKCBpaCB ooaBn2xkYXA6Ly9kaXJlY3Rvcnkuc3dpc3NzaWduLm5ldC9DTj0xN0EwQ0RDMUU0NDFCNjNBNUIz QkNCNDU5REJEMUNDMjk4RkE4NjU4JTJDTz1Td2lzc1NpZ24lMkNDPUNIP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDBhBgNVHSAE WjBYMFYGCWCFdAFZAQMBBjBJMEcGCCsGAQUFBwIBFjtodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3Np Z24uY29tL1N3aXNzU2lnbi1TaWx2ZXItQ1AtQ1BTLnBkZjCBxgYIKwYBBQUHAQEEgbkwgbYwZAYI KwYBBQUHMAKGWGh0dHA6Ly9zd2lzc3NpZ24ubmV0L2NnaS1iaW4vYXV0aG9yaXR5L2Rvd25sb2Fk LzE3QTBDREMxRTQ0MUI2M0E1QjNCQ0I0NTlEQkQxQ0MyOThGQTg2NTgwTgYIKwYBBQUHMAGGQmh0 dHA6Ly9vY3NwLnN3aXNzc2lnbi5uZXQvMTdBMENEQzFFNDQxQjYzQTVCM0JDQjQ1OURCRDFDQzI5 OEZBODY1ODANBgkqhkiG9w0BAQsFAAOCAgEAw3mnV7d7rVFo9USMQZUoAXx01jtqvG3vp9dNOZkd aI3KCNnQcbEZNZNvgsYcSbhR7kz5bApv2KX7/vswXgDSlKvEElG6qoqrat0Z1ytK9xaya1HPdFsp onPel/7YTyAhfWkMsFDljViMgC7lFxzdY3qq7wX5w2me5IxxYlxC7jryzeAS74tc6c5TKDLslQsZ VKIhjfp/UKdPvBl7smuMKT93Psojx2laQZ19ZjFvenF52qllOut/1xDVC19UGXzONyUkhFDQr0A0 wl+S4nqR8y9CRxufPEL72V+lvHBFju+gOZD1oXhs18BnWRnhAN5c/HjoT927rJEucov86kdvQyi8 u7mOlL76UN1QkxtMGLZ2/8NHClm0zW1V2Gq2X8kvwZQ2Pr6uQDUGIO3gAkwtNEUOQ6+i9NiQFeXQ wJtEQK48j5NRvJloc2l7dViZt9QET9/xgnERHXv8Ex13ZVVj11JyfN0xR4anldisJnE9I+YSO/R/ mpaG/ivqoPMmDXXGFowxIOcRR6HnqWqwpbKBHtw90KHjbtXwZqYcfdeSiE0ABwtx53Pnc+RUZWn8 N43xHm9w7qdss1JFZ1nWBUixIemXKNnZ9LSmoGcjNrxgRw5cKH9dk4oxuo0xNhTHekKdbyDBbCr4 Fg9q2QCUMrs9VbHFw6ENsXl3VB3gM4J+7uowggW9MIIDpaADAgECAghPG9QvVLsvSzANBgkqhkiG 9w0BAQUFADBHMQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMSEwHwYDVQQDExhT d2lzc1NpZ24gU2lsdmVyIENBIC0gRzIwHhcNMDYxMDI1MDgzMjQ2WhcNMzYxMDI1MDgzMjQ2WjBH MQswCQYDVQQGEwJDSDEVMBMGA1UEChMMU3dpc3NTaWduIEFHMSEwHwYDVQQDExhTd2lzc1NpZ24g U2lsdmVyIENBIC0gRzIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDE8Yd/03gx9zjJ +MOZQ7zH97w3505xukuPpXMdXG6YrgNXrjg3Qy8XPR/IzmgQwXiuGQMrEPoseYP26LlouVXyBESn Ofn8BIse8aJNJ/lhe7q35aITtuthPtBs0eb7+l7tHbSeoDVboZLL8EmS/oUKBT7m2QviT7vclTf8 kekyNSLRHzpOJ4WdsBWUMtphDUdNYEKukkfog1pQWOmKi7ldodzdmUofNme7SOSDtjfrSDqvD2eP FwfoBMrvajGH1MC2+ZRxe2dkuLaRSkJ7ZS4wagz1kO6V5vLNguzZoUrs9rJL5UWF5m14kwQunIJt NqnEMWQfhoMLKvQ1CnjJVc9BsEfpMJ+ZvmGoBoS5KHpfONkbqTiwg39zwcM7SCqCDyGbuMyoNcOE G4OzPr6klWkBOokAeATZyfSZGatWfluLhjkVkaQQLAkygGCzk8AqthgLnX6NSfIQSn/51UYvGZKj macmrLuMPOYOvEcH3HNR8XBkLwj5tEcdMGxE6ik3hZJoZryDOP57OS7TUPAf+15gtqmm+idB8ZsY cvL1hHRKyWfEVK5IZN+M0W6wHeEHjwgemZxx6UzYpfdHEh900VGehvPCoiNAC3PbS6bncwaMwaDp wVmsRvrmL/jPcZxGbbnEFY04eQNFSO/EXdcI7oc5IoayDQ9YQ/dxqUgu/erWHwIDAQABo4GsMIGp MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQXoM3B5EG2Ols7y0Wd vRzCmPqGWDAfBgNVHSMEGDAWgBQXoM3B5EG2Ols7y0WdvRzCmPqGWDBGBgNVHSAEPzA9MDsGCWCF dAFZAQMBATAuMCwGCCsGAQUFBwIBFiBodHRwOi8vcmVwb3NpdG9yeS5zd2lzc3NpZ24uY29tLzAN BgkqhkiG9w0BAQUFAAOCAgEAc8aB4CfSLQ/glTDimkF/UCxfX2JhqYZqaRgMdEnWXYTqQVIYb1it UFYgasa9KGlYkdyRETWpOh28GqVgntgff0WRadl+u3hywQYPKs6PhXBhrKDNC7g5KVaEMk6Guz3E KtnXH3Lu/lGhIkGxcQJjGoKwYqteVxIf38vddaDAXXmQjBvgUObeMf6Ye3BfpZDYrfgCtm/TYN1A SyLFPa06ep8aGkeReTO6gtwyaQOWbh9L8HH+42dyoLG/XIvk+pkix4S5G40jlz/tJeDPZbv1YQTv 3R6yWkEiWqGfXSzoW8ltqQwMeKpgxlaPAVoMaLxpGXnEH36XBb/F6SRRXtTVS1Pt2SNaNgNlo8ED rUEw80YbhZCvZbXVseQWW3h1HZd6bVmpKo973sOHiRCZSXN4yD29UTV0KtXxfmkbKrs7vSW4mlo9 cmGQZofuDNZN1BF0C2r+CwP8o1VXif5Ky65bFwXI8o0jMVM40i1qP4K5jQhq915BdG7DEX4HrClg kT84ylcQDb0wL8el5kGg2q4Fh5qgpGVsTAkMibq407nAk4ow+o3lmmsVAU5nqtpiVj6ECGbSxDZ9 pz4Q/Ijg1IDlAL2q804Go3pq+WJy4wlP65sOASPxn7t83NxsEZclsvK0YxTSBipnjIP1zuoH2Jpq HuzkCrsqTOsJYDnOymLYLm4AADGCA90wggPZAgEBMG4wVjELMAkGA1UEBhMCQ0gxFTATBgNVBAoT DFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFsIFNpbHZlciBDQSAyMDE0 IC0gRzIyAhR4i6Eec1b72YkIjJKOk4r62lxMbzANBglghkgBZQMEAgEFAKCCAkAwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwOTI3MTY1NjEwWjAtBgkqhkiG9w0B CTQxIDAeMA0GCWCGSAFlAwQCAQUAoQ0GCSqGSIb3DQEBCwUAMC8GCSqGSIb3DQEJBDEiBCB3rBME sAvgAbxIW6/7//xixebT+DYUPKBMDEGQO84wxzB9BgkrBgEEAYI3EAQxcDBuMFYxCzAJBgNVBAYT AkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBT aWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wfwYLKoZIhvcNAQkQAgsx cKBuMFYxCzAJBgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNz U2lnbiBQZXJzb25hbCBTaWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8w gaUGCSqGSIb3DQEJDzGBlzCBlDALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQB AjAKBggqhkiG9w0DBzAKBggqhkiG9w0DAjAKBggqhkiG9w0DAjAHBgUrDgMCBzAKBggqhkiG9w0D AjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATALBglghkgBZQMEAgQwDQYJ KoZIhvcNAQELBQAEggEAhs7Q6R3/ptVLoYGOR10M5qyVz3SWjnq/A5okeX7WdePzBswE0yvU2JkI qRuJ0VfGi0WPUuvzRpHUIMApNUNh6eTGkZzC7cXEtVrUeOVoMFh6xmzXzdVVT0/pOEDMigdHTmgx wjGBPN7npRXDjszQV4MFn9cq1V8b3nPf4mMPBbzc6EEuxjqF56oXneJj/xCdNmfKrrDegXUroFk7 nspJDUcvSsgVfuiRcmwUE5SkQVMt+2UQ6RATkbQLqpKbMLkEPq//p37dSBJpSuPxp/0Oxx/xob0T yz0JZn2Tg1GQy99T57Z3yx/H9f+cMxX3lXkEgObeo7y/vMxqHfvY20t02AAAAAAAAA== ------=_Part_351930_1972777100.1601225770818-- From nobody Mon Sep 28 07:21:52 2020 Return-Path: <01000174d5174af9-848a769d-ef3f-49a6-b1d6-1eb8349a489f-000000@amazonses.watsen.net> 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 E1AB93A0538 for ; Mon, 28 Sep 2020 07:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 O6sDr8YI5EwI for ; Mon, 28 Sep 2020 07:21:49 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08E953A08BB for ; Mon, 28 Sep 2020 07:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1601302907; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=A4F06zdf2bsYd8MFPbgk4FwL4JJmExK4pEDTNzorQ4s=; b=cHwZ8bsuB4oXEfVUepoLO+U3bvBrsVquBWSAZ51D9mpSUPqo56xqncvzJKyEAzk9 QsEncBxBh23sgYjEwB/ZAayHz98OrCjjR7aKnWLqvDdD9cvi4gdu6P7X0CQzNzNkOTD /fs/9R3UBEwFalrEjKrgyRlXlIe6hU5z2cSJZ7YA= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_71F18AF1-AEDA-429D-829B-85E1CB61A38C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 28 Sep 2020 14:21:47 +0000 References: <01000174cb6ea9ee-d7716c10-a691-4a97-9e99-022e4c0ef55a-000000@email.amazonses.com> <01000174cbc7532c-81a16bed-e752-4e61-9a97-dfc95be744b5-000000@email.amazonses.com> To: "netconf@ietf.org" In-Reply-To: Message-ID: <01000174d5174af9-848a769d-ef3f-49a6-b1d6-1eb8349a489f-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.09.28-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 14:21:51 -0000 --Apple-Mail=_71F18AF1-AEDA-429D-829B-85E1CB61A38C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It seems that we need two I-Ds: 1) =E2=80=9Crestconf-lists" a) =E2=80=9Cupdate=E2=80=9D RFC 8040 (and possibly RFC 8527) b) modify Section 3.5 (Data Resource) to state that =E2=80=9Clist=E2= =80=9D and =E2=80=9Cleaf-list=E2=80=9D themselves (not just their = entries) are =E2=80=9Cdata resources=E2=80=9D c) define impact on various HTTP methods GET, POST, PUT, DELETE, = PATCH, etc. d) additionally define query parameters for the GET: i) limit: number to return. Could name =E2=80=98count=E2=80= =99 to match ii) offset: where to begin. Need to discuss if = =E2=80=99s =E2=80=9Ckeys=E2=80=9D is better iii) where: some xpath expression iv) direction: ascending | descending 2) =E2=80=9Cnetconf-lists" a) =E2=80=9Cupdate=E2=80=9D RFC 6241 (and possibly RFC 8526) b) introduce a or like RPC for paging = through the entries of lists and leaf-lists. Anyone interested in working on said I-Ds, please email me privately. Thanks, Kent. // as a contributor > On Sep 27, 2020, at 11:12 AM, Andy Bierman wrote: >=20 >=20 >=20 > On Sat, Sep 26, 2020 at 11:57 AM Kent Watsen > wrote: >=20 >> The operation is not stateful. >> http://www.netconfcentral.org/modulereport/yumaworks-getbulk = > This RPC is effectively 1-1 with RC query params approach being = discussed. I like it. >=20 > The =E2=80=9Ccount=E2=80=9D param is like =E2=80=9Climit=E2=80=9D, and = =E2=80=9Clist-test=E2=80=9D is like a =E2=80=9Cwhere=E2=80=9D. >=20 > One difference is that uses "last-keys=E2=80=9D instead of = an integral =E2=80=9Coffset=E2=80=9D. Any thoughts about the pros and = cons? I imagine performance depends on the backend database used. For = instance, SQL supports =E2=80=9Coffset=E2=80=9D so, to support = "last-keys=E2=80=9D instead would entail a first query to determine the = offset for a key. >=20 >=20 >=20 > It would be unlikely that a distributed server (e.g. data can come = from linecards) > that it is efficient to find the Nth entry. >=20 > Using a count approach is obviously vulnerable to additions and = deletions to the dataset. > If the count keeps changing then the relative Nth entry also keeps = changing. > This causes duplicates or missed entries in the paginated data. Using = key values > instead of a count this source of inaccuracy is eliminated. Both = approaches > are vulnerable to "moved" entries (e.g. user-ordered list entry = changes position). > This can happen in theory but (1) user-ordered config=3Dfalse data is = very rare, > (2) the "move" operation for user-ordered data is very rarely used and = (3) > an entry would have to be moved just at the time the walk was in = progress. >=20 > =20 > Missing is a =E2=80=9Csort=E2=80=9D. That said, of the four params = mentioned (limit, offset, where, sort), it might be least important. At = least, a general sort is=E2=80=A6and then there is the nasty issue of = sorting a user-sorted list. A likely must-have fallback would be = =E2=80=9Cdirection=E2=80=9D so, e.g., queries return the most-recent = (not the oldest) entires in a time-series list (e.g., a log). A = =E2=80=9Cdirection=E2=80=9D parameter would also work well on a = user-sorted list. >=20 >=20 > sort is much more expensive to implement correctly and makes more > sense when a stateful snapshot approach is used. Sorting each chunk > vs. the entire data-set is not that useful. >=20 > =20 >=20 >=20 >> There are 3 completely different approaches: >>=20 >> 1) stateless >> 2) stateful >> 3) stateful snapshot >>=20 >> How to efficiently iterate through data that is changing constantly? >> This problem is harder than it looks. >=20 > Agreed. I recommend we NOT try to solve that problem. >=20 >=20 >=20 > But we are solving that problem to some degree. > Operational state is changing constantly and iterating through a list > vs. a single GET usually makes the problem worse. >=20 >=20 >=20 > K. >=20 >=20 > Andy --Apple-Mail=_71F18AF1-AEDA-429D-829B-85E1CB61A38C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

It seems that we need = two I-Ds:

1) = =E2=80=9Crestconf-lists"

= a) =E2=80=9Cupdate=E2=80=9D RFC 8040 (and possibly RFC = 8527)
b) modify Section 3.5 (Data = Resource) to state that =E2=80=9Clist=E2=80=9D and =E2=80=9Cleaf-list=E2=80= =9D themselves (not just their entries) are =E2=80=9Cdata = resources=E2=80=9D
c) define impact on various HTTP = methods GET, POST, PUT, DELETE, PATCH, etc.
d) = additionally define query parameters for the GET:
= i) limit: number to return.  Could name =E2=80=98count=E2= =80=99 to match <get-bulk>
= ii) offset: where to begin.  Need to discuss if = <get-bilk>=E2=80=99s =E2=80=9Ckeys=E2=80=9D is better
= iii) where: some xpath expression
= iv) direction: ascending | descending
2) =E2=80=9Cnetconf-lists"

a) = =E2=80=9Cupdate=E2=80=9D RFC 6241 (and possibly RFC 8526)
= b) introduce a <get-bulk> or <get-block> like RPC for = paging through the entries of lists and leaf-lists.


Anyone interested in working on said I-Ds, please email me = privately.

Thanks,
Kent. // as a = contributor


On Sep 27, 2020, at 11:12 AM, = Andy Bierman <andy@yumaworks.com> wrote:



On Sat, Sep 26, 2020 at 11:57 AM Kent Watsen <kent+ietf@watsen.net> wrote:

The = <get-bulk> operation is not stateful.
 http://www.netconfcentral.org/modulereport/yumaworks-getbulk

This RPC is effectively 1-1 with RC = query params approach being discussed.  I like it.

The =E2=80=9Ccount=E2=80=9D= param is like =E2=80=9Climit=E2=80=9D, and =E2=80=9Clist-test=E2=80=9D = is like a =E2=80=9Cwhere=E2=80=9D.

One difference is that <get-bulk> = uses "last-keys=E2=80=9D instead of an integral =E2=80=9Coffset=E2=80=9D. =   Any thoughts about the pros and cons?  I imagine performance = depends on the backend database used.  For instance, SQL supports = =E2=80=9Coffset=E2=80=9D so, to support "last-keys=E2=80=9D instead = would entail a first query to determine the offset for a key.



It would be unlikely that a distributed server (e.g. data can = come from linecards)
that it is efficient to find = the Nth entry.

Using a count approach is obviously vulnerable to additions = and deletions to the dataset.
If the count keeps = changing then the relative Nth entry also keeps changing.
This causes duplicates or missed entries in the paginated = data.  Using key values
instead of a count = this source of inaccuracy is eliminated.  Both approaches
are vulnerable to "moved" entries (e.g. user-ordered list = entry changes position).
This can happen in theory = but (1) user-ordered config=3Dfalse data is very rare,
(2) the "move" operation for user-ordered data is very rarely = used and (3)
an entry would have to be moved just = at the time the walk was in progress.

 
Missing is a =E2=80=9Csort=E2=80=9D.  That said, of the = four params mentioned (limit, offset, where, sort), it might be least = important.  At least, a general sort is=E2=80=A6and then there is = the nasty issue of sorting a user-sorted list.  A likely must-have = fallback would be =E2=80=9Cdirection=E2=80=9D so, e.g., queries return = the most-recent (not the oldest) entires in a time-series list (e.g., a = log).  A =E2=80=9Cdirection=E2=80=9D parameter would also work well = on a user-sorted list.


sort= is much more expensive to implement correctly and makes more
sense when a stateful snapshot approach is used. Sorting each = chunk
vs. the entire data-set is not that = useful.

 


There are 3 completely different = approaches:

  1) = stateless
  2) stateful
  3) = stateful snapshot

How to efficiently iterate through data that is changing = constantly?
This problem is harder than it = looks.

Agreed.  I recommend we NOT try to = solve that problem.



But = we are solving that problem to some degree.
Operational state is changing constantly and iterating = through a list
vs. a single GET usually makes the = problem worse.



Andy

= --Apple-Mail=_71F18AF1-AEDA-429D-829B-85E1CB61A38C-- From nobody Tue Sep 29 10:44:10 2020 Return-Path: <01000174daf6ded3-0ba5564d-f1c7-4c65-90dc-d8a22f2f9395-000000@amazonses.watsen.net> 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 DEFD73A0F4F for ; Tue, 29 Sep 2020 10:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 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_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 qJm04KGHFL-u for ; Tue, 29 Sep 2020 10:44:07 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 712B83A0F4E for ; Tue, 29 Sep 2020 10:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1601401446; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=uQbIUe+Fshfng1x9nL0nbvd92LyVkRbsMfZYnB9wg3E=; b=lBUJVb19oGWik1dlMpO8SAXivnBUoc2VvfTPWlx131mA1pLDZMZA2zT74yVqHwdS Pkf6nvp6H0/mOc7CWBAMxjzy/MYJSZKca0xrLEhJWMLQ3yyEuTm4Aj1iO2L5x/kkiR+ AHlJsZeWNw3SgwRadpVLcY95evbMUv6KhjW646lg= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_B9D46937-84EE-457D-8649-02B4B8AF5805" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 29 Sep 2020 17:44:06 +0000 References: <01000174cb6ea9ee-d7716c10-a691-4a97-9e99-022e4c0ef55a-000000@email.amazonses.com> <01000174cbc7532c-81a16bed-e752-4e61-9a97-dfc95be744b5-000000@email.amazonses.com> <01000174d5174af9-848a769d-ef3f-49a6-b1d6-1eb8349a489f-000000@email.amazonses.com> To: "netconf@ietf.org" In-Reply-To: <01000174d5174af9-848a769d-ef3f-49a6-b1d6-1eb8349a489f-000000@email.amazonses.com> Message-ID: <01000174daf6ded3-0ba5564d-f1c7-4c65-90dc-d8a22f2f9395-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.09.29-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2020 17:44:09 -0000 --Apple-Mail=_B9D46937-84EE-457D-8649-02B4B8AF5805 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Firstly, thank you to those that responded showing interest in working = on these I-Ds. If anyone else is interested, please send me a PM.=20 Regarding solution, I want to take one more stab at a sketch here, as a = last-chance for comments before the authors dive into producing the = I-Ds. Already it is assumed that there will be an RPC for NC, and query params = for RC=E2=80=A6that not what this email is about. Here=E2=80=99s my proposal: For all lists; a) =E2=80=9Climit=E2=80=9D or =E2=80=9Ccount=E2=80=9D b) =E2=80=9Coffset" or =E2=80=9Cskip=E2=80=9D c) =E2=80=9Cdirection=E2=80=9D (i.e., forward/backward) For non =E2=80=9Cordered-by user=E2=80=9D lists, but only for = indexable columns: d) =E2=80=9Csort-by=E2=80=9D or =E2=80=9Cordered-by=E2=80=9D= (single column max) e) =E2=80=9Cwhere=E2=80=9D or =E2=80=9Cfilter=E2=80=9D = (compound expression of some sort) Note: the lowercase =E2=80=9Cor=E2=80=9D is just for the label = selected (no semantic impact). The order of operation is =E2=80=9Ce =E2=80=94> a=E2=80=9D. That is, = first the filter is applied (if any), then the sort is applied (if any), = then the direction is applied (if any), then the offset/skip is applied = (if any), and then the limit/count is applied (if any). Now the tricky stuff. - =E2=80=9Ckey=E2=80=9D and =E2=80=9Cunique=E2=80=9D leafs are = indexed by default, assuming the leaf=E2=80=99s base type is indexable - a special extension is used to index other nodes - other indexable nodes must be a =E2=80=9Cleaf" - the leaf must be =E2=80=9Cmandatory true=E2=80=9D - the leaf must not be under a =E2=80=9Clist=E2=80=9D or = =E2=80=9Cchoice=E2=80=9D node - the leaf must have an indexable base type - all built-in types supported except: - binary - instance-identifier - unions are indexable, but assumes all values stored as a =E2=80=9Cstring=E2=80=9D in the DB. - =E2=80=9Cstring=E2=80=9D types may be coerced into = more DB-friendly types - =E2=80=9Cyang:date-and-time=E2=80=9D mapped to = a DB =E2=80=9CDateTime=E2=80=9D type Cons: - smart (e.g., netmask-based) filter/sorts is unlikely = supportable - at least not without custom (not generic) code Comments? K. --Apple-Mail=_B9D46937-84EE-457D-8649-02B4B8AF5805 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Firstly, thank you to = those that responded showing interest in working on these I-Ds.  If = anyone else is interested, please send me a PM. 

Regarding solution, I = want to take one more stab at a sketch here, as a last-chance for = comments before the authors dive into producing the I-Ds.

Already it is assumed = that there will be an RPC for NC, and query params for RC=E2=80=A6that = not what this email is about.

Here=E2=80=99s my proposal:

For all = lists;

= a) =E2=80=9Climit=E2=80=9D or =E2=80=9Ccount=E2=80=9D
= b) =E2=80=9Coffset" or =E2=80=9Cskip=E2=80=9D
= c) =E2=80=9Cdirection=E2= =80=9D  (i.e., forward/backward)

= For non =E2=80=9Cordered-by user=E2=80=9D lists, but = only for indexable columns:

= d) =E2=80=9Csort-by=E2=80=9D or = =E2=80=9Cordered-by=E2=80=9D (single column = max)
e) =E2=80=9Cwhere=E2=80=9D = or =E2=80=9Cfilter=E2=80=9D (compound expression of some sort)

= Note: the lowercase =E2=80=9Cor=E2=80=9D is just for the = label selected (no semantic impact).


The = order of operation is =E2=80=9Ce =E2=80=94> a=E2=80=9D.  That = is, first the filter is applied (if any), then the sort is applied (if = any), then the direction is applied (if any), then the offset/skip is = applied (if any), and then the limit/count is applied (if = any).

Now the = tricky stuff.

- =E2=80=9Ckey=E2=80=9D and =E2=80=9Cunique=E2=80=9D = leafs are indexed by default, assuming
  = the leaf=E2=80=99s base type is indexable
- a = special extension is used to index other nodes
= - other indexable = nodes must be a =E2=80=9Cleaf"
- the = leaf must be =E2=80=9Cmandatory true=E2=80=9D
= - the leaf must not be under a =E2=80=9Clist=E2=80=9D or = =E2=80=9Cchoice=E2=80=9D node
- the = leaf must have an indexable base type
= - all built-in types supported except:
= - binary
= - instance-identifier
- = unions are indexable, but assumes all values stored
=    as a =E2=80=9Cstring=E2=80=9D in the = DB.
= - =E2=80=9Cstring=E2=80=9D types may be coerced into more = DB-friendly types
- = =E2=80=9Cyang:date-and-time=E2=80=9D mapped to a DB =E2=80=9CDateTime=E2=80= =9D type

Cons:
- smart (e.g., netmask-based) = filter/sorts is unlikely supportable
- = at least not without custom (not generic) code


Comments?

K.



= --Apple-Mail=_B9D46937-84EE-457D-8649-02B4B8AF5805-- From nobody Tue Sep 29 11:57:20 2020 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 C14223A10DE for ; Tue, 29 Sep 2020 11:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.997, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=VjUDkJSx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=saxUjLmm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42jnSPrsb44e for ; Tue, 29 Sep 2020 11:57:16 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 992CD3A10DD for ; Tue, 29 Sep 2020 11:57:16 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 04F295C00B1; Tue, 29 Sep 2020 14:57:14 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 29 Sep 2020 14:57:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm2; bh= IEUbirBii9aBvXM1v3VdeI7gH9eeCcTYXD3/WvtizWY=; b=VjUDkJSxJlCv8B0X EgtrNO2dQSleDHL9k41cTgyl5prV/gAa/5R96Jnw1hUQOPkvtbVQykMAs9I6jbtz TjjKOh2eZC48/HmhHSxZJgVNqpCjt8ifMuJnFS9kjOhnQgdzHwiN1zG+brCdtEI4 QpYcPKBdT5IcyL1ospp+H0vfP35Siffei55/+Q8Ae/oj8X0oAUJSyG13Q/TOchdd VHyK5CZ1FhDiZ/AxcjlDDKeNeZ82RlYbFD+vENudYadKEOf73B83cOc9QnWTGooP 7au6lh6lYqHBhMbd5aZ5mNJaBI/3mGuV0TwiyXpjxeiDS0S2TrehZ7aFRvs0wVRs LueIrw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=IEUbirBii9aBvXM1v3VdeI7gH9eeCcTYXD3/Wvtiz WY=; b=saxUjLmmNHOUDKWFJro/uO5xeSGD81jfgWFZ9Jx/5ek2CZQTRklTbxXAX r3MKSyFimd+ThQcdHjj/n/t3mEuTS7tcLptDOM27Jd0AYJkDj1wg5fUStauzA+M8 drI3zsbjcXtmlY3IcOJ5BxDcav5NVXNmf50go2Cqpfp2bevjEkSoSgSrQAZxMx4T ZL799Qqn9Nj4LnklQrYi+yNewRVrWgIPitQtoQENsYz6aaKSNZKb22/jroOc+yg4 N2MsA0xz4Jxa/sVxWZmhbPIICqVPnuvscrbQgfTOely3KLn/XcvobTjG7yrdoRVG DwZZYpASZS0shJj8JUVXtiXoGW+Gg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdekgddufeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtsg ertdertdejnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepheetgedtfffggeffkedvje ekveelteeuuddttdffhfelgfetvdevhedvgeeutddunecukfhppeduheekrddujeegrdeg rddvudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhgsjhdoihgvthhfseegieeikedrshgv X-ME-Proxy: Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id 4E97A3064610; Tue, 29 Sep 2020 14:57:12 -0400 (EDT) Date: Tue, 29 Sep 2020 20:57:10 +0200 (CEST) Message-Id: <20200929.205710.165167541047857442.id@4668.se> To: kent+ietf@watsen.net Cc: netconf@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <01000174daf6ded3-0ba5564d-f1c7-4c65-90dc-d8a22f2f9395-000000@email.amazonses.com> References: <01000174d5174af9-848a769d-ef3f-49a6-b1d6-1eb8349a489f-000000@email.amazonses.com> <01000174daf6ded3-0ba5564d-f1c7-4c65-90dc-d8a22f2f9395-000000@email.amazonses.com> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2020 18:57:18 -0000 SGksDQoNCktlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD4gd3JvdGU6DQo+IA0KPiBG aXJzdGx5LCB0aGFuayB5b3UgdG8gdGhvc2UgdGhhdCByZXNwb25kZWQgc2hvd2luZyBpbnRlcmVz dCBpbiB3b3JraW5nDQo+IG9uIHRoZXNlIEktRHMuICBJZiBhbnlvbmUgZWxzZSBpcyBpbnRlcmVz dGVkLCBwbGVhc2Ugc2VuZCBtZSBhIFBNLg0KPiANCj4gUmVnYXJkaW5nIHNvbHV0aW9uLCBJIHdh bnQgdG8gdGFrZSBvbmUgbW9yZSBzdGFiIGF0IGEgc2tldGNoIGhlcmUsIGFzDQo+IGEgbGFzdC1j aGFuY2UgZm9yIGNvbW1lbnRzIGJlZm9yZSB0aGUgYXV0aG9ycyBkaXZlIGludG8gcHJvZHVjaW5n IHRoZQ0KPiBJLURzLg0KPiANCj4gQWxyZWFkeSBpdCBpcyBhc3N1bWVkIHRoYXQgdGhlcmUgd2ls bCBiZSBhbiBSUEMgZm9yIE5DLCBhbmQgcXVlcnkNCj4gcGFyYW1zIGZvciBSQ+KApnRoYXQgbm90 IHdoYXQgdGhpcyBlbWFpbCBpcyBhYm91dC4NCj4gDQo+IEhlcmXigJlzIG15IHByb3Bvc2FsOg0K PiANCj4gCUZvciBhbGwgbGlzdHM7DQo+IA0KPiAJCWEpIOKAnGxpbWl04oCdIG9yIOKAnGNvdW50 4oCdDQo+IAkJYikg4oCcb2Zmc2V0IiBvciDigJxza2lw4oCdDQo+IAkJYykg4oCcZGlyZWN0aW9u 4oCdICAoaS5lLiwgZm9yd2FyZC9iYWNrd2FyZCkNCj4gDQo+IAlGb3Igbm9uIOKAnG9yZGVyZWQt YnkgdXNlcuKAnSBsaXN0cywgYnV0IG9ubHkgZm9yIGluZGV4YWJsZSBjb2x1bW5zOg0KPiANCj4g CQlkKSDigJxzb3J0LWJ54oCdIG9yIOKAnG9yZGVyZWQtYnnigJ0gKHNpbmdsZSBjb2x1bW4gbWF4 KQ0KPiAJCWUpIOKAnHdoZXJl4oCdIG9yIOKAnGZpbHRlcuKAnSAoY29tcG91bmQgZXhwcmVzc2lv biBvZiBzb21lIHNvcnQpDQoNCkkgZG9uJ3QgdGhpbmsgZCkgYW5kIGUpIHNob3VsZCBiZSByZXN0 cmljdGVkIHRvIG9idSBsaXN0cywgYW5kIEkgZG9uJ3QNCnRoaW5rIHRoZXkgc2hvdWxkIGJlIHJl c3RyaWN0ZWQgdG8gImluZGV4YWJsZSIgY29sdW1ucy4NCg0KQW5kIEkgdGhpbmsgImV4cHJlc3Np b24gb2Ygc29tZSBzb3J0IiBzaG91bGQgYmUgWFBhdGguDQoNCkFsc28sIHNpbmNlIHRoZSBtYWlu IG9iamVjdGl2ZSBpcyBlZmZpY2llbnQgcmV0cmlldmFsLCAic29ydC1ieSINCmNhbiBwZXJoYXBz IGJlIHJlbW92ZWQuICBDb25zaWRlciBsYXJnZSBsaXN0cyBpbiBvcGVyYXRpb25hbCBzdGF0ZQ0K dGhhdCBhbHNvIGNoYW5nZSBvZnRlbi4NCg0KPiAJTm90ZTogdGhlIGxvd2VyY2FzZSDigJxvcuKA nSBpcyBqdXN0IGZvciB0aGUgbGFiZWwgc2VsZWN0ZWQgKG5vIHNlbWFudGljDQo+IAlpbXBhY3Qp Lg0KPiANCj4gDQo+IFRoZSBvcmRlciBvZiBvcGVyYXRpb24gaXMg4oCcZSDigJQ+IGHigJ0uICBU aGF0IGlzLCBmaXJzdCB0aGUgZmlsdGVyIGlzDQo+IGFwcGxpZWQgKGlmIGFueSksIHRoZW4gdGhl IHNvcnQgaXMgYXBwbGllZCAoaWYgYW55KSwgdGhlbiB0aGUNCj4gZGlyZWN0aW9uIGlzIGFwcGxp ZWQgKGlmIGFueSksIHRoZW4gdGhlIG9mZnNldC9za2lwIGlzIGFwcGxpZWQgKGlmDQo+IGFueSks IGFuZCB0aGVuIHRoZSBsaW1pdC9jb3VudCBpcyBhcHBsaWVkIChpZiBhbnkpLg0KPiANCj4gTm93 IHRoZSB0cmlja3kgc3R1ZmYuDQo+IA0KPiAJLSDigJxrZXnigJ0gYW5kIOKAnHVuaXF1ZeKAnSBs ZWFmcyBhcmUgaW5kZXhlZCBieSBkZWZhdWx0LCBhc3N1bWluZw0KPiAJICB0aGUgbGVhZuKAmXMg YmFzZSB0eXBlIGlzIGluZGV4YWJsZQ0KPiAJLSBhIHNwZWNpYWwgZXh0ZW5zaW9uIGlzIHVzZWQg dG8gaW5kZXggb3RoZXIgbm9kZXMNCj4gCS0gb3RoZXIgaW5kZXhhYmxlIG5vZGVzIG11c3QgYmUg YSDigJxsZWFmIg0KPiAJLSB0aGUgbGVhZiBtdXN0IGJlIOKAnG1hbmRhdG9yeSB0cnVl4oCdDQo+ IAktIHRoZSBsZWFmIG11c3Qgbm90IGJlIHVuZGVyIGEg4oCcbGlzdOKAnSBvciDigJxjaG9pY2Xi gJ0gbm9kZQ0KPiAJLSB0aGUgbGVhZiBtdXN0IGhhdmUgYW4gaW5kZXhhYmxlIGJhc2UgdHlwZQ0K PiAJCS0gYWxsIGJ1aWx0LWluIHR5cGVzIHN1cHBvcnRlZCBleGNlcHQ6DQo+IAkJCS0gYmluYXJ5 DQo+IAkJCS0gaW5zdGFuY2UtaWRlbnRpZmllcg0KPiAJCS0gdW5pb25zIGFyZSBpbmRleGFibGUs IGJ1dCBhc3N1bWVzIGFsbCB2YWx1ZXMgc3RvcmVkDQo+IAkJICAgYXMgYSDigJxzdHJpbmfigJ0g aW4gdGhlIERCLg0KPiAJCS0g4oCcc3RyaW5n4oCdIHR5cGVzIG1heSBiZSBjb2VyY2VkIGludG8g bW9yZSBEQi1mcmllbmRseSB0eXBlcw0KPiAJCQktIOKAnHlhbmc6ZGF0ZS1hbmQtdGltZeKAnSBt YXBwZWQgdG8gYSBEQiDigJxEYXRlVGltZeKAnSB0eXBlDQo+IA0KPiBDb25zOg0KPiAJLSBzbWFy dCAoZS5nLiwgbmV0bWFzay1iYXNlZCkgZmlsdGVyL3NvcnRzIGlzIHVubGlrZWx5IHN1cHBvcnRh YmxlDQo+IAkJLSBhdCBsZWFzdCBub3Qgd2l0aG91dCBjdXN0b20gKG5vdCBnZW5lcmljKSBjb2Rl DQoNCldlIGNvdWxkIGRlZmluZSBhIGZldyBtb3JlIFhQYXRoIGZ1bmN0aW9ucyBmb3Igc3VjaCBj b21wYXJpc29ucy4NCg0KDQoNCi9tYXJ0aW4NCg0KPiANCj4gDQo+IENvbW1lbnRzPw0KPiANCj4g Sy4NCj4gDQo+IA0KPiANCg== From nobody Tue Sep 29 14:56:44 2020 Return-Path: <01000174dbde18ac-c9293572-775f-4c8e-b8c1-a8522bd636b5-000000@amazonses.watsen.net> 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 7AC883A0C94 for ; Tue, 29 Sep 2020 14:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 h5ENQ2_xrWlD for ; Tue, 29 Sep 2020 14:56:41 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35143A0C7A for ; Tue, 29 Sep 2020 14:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1601416599; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=KF31aAdDkIa0lbHe1RiY7qRqwdrrnBwBJmkfZyG0ZXQ=; b=A6rlD1Qd2oZXyqdsuNUUXR24rI0ZZvcBY9zZ45VB3i1sQJr4kUR0SgQFLhXMw2U+ eAxW+V8OrwVdaNRwQlRv9lnU5/babVwtC+VDAx/KTaSoyhq45ev2z5DlkkVZpRqqP7y wNunYt9ANAa7qLzbpmysCcHY7jAF4jCB9upkr9fQ= From: Kent Watsen Message-ID: <01000174dbde18ac-c9293572-775f-4c8e-b8c1-a8522bd636b5-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4EEBF8F0-A620-479E-92E7-8805CFB43A8C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 29 Sep 2020 21:56:39 +0000 In-Reply-To: <20200929.205710.165167541047857442.id@4668.se> Cc: "netconf@ietf.org" To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= References: <01000174d5174af9-848a769d-ef3f-49a6-b1d6-1eb8349a489f-000000@email.amazonses.com> <01000174daf6ded3-0ba5564d-f1c7-4c65-90dc-d8a22f2f9395-000000@email.amazonses.com> <20200929.205710.165167541047857442.id@4668.se> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.09.29-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2020 21:56:43 -0000 --Apple-Mail=_4EEBF8F0-A620-479E-92E7-8805CFB43A8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Martin, > I don't think d) and e) should be restricted to obu lists, and I don't > think they should be restricted to "indexable" columns. >=20 > And I think "expression of some sort" should be XPath. >=20 > Also, since the main objective is efficient retrieval, "sort-by" > can perhaps be removed. Consider large lists in operational state > that also change often. Your last paragraph, if I read it correctly, says =E2=80=9Cmaybe don=E2=80= =99t do =E2=80=98d=E2=80=99=E2=80=9D, which if applied to the first part = of your response becomes "I don't think 'e' should be restricted to = OBU-lists=E2=80=9D, which is something I can agree with. As for =E2=80=98= d=E2=80=99 being a reasonable thing to support for OBU-lists, please = explain the use-case. Regarding =E2=80=9CI don=E2=80=99t think they should be restricted to = =E2=80=98indexable=E2=80=99 columns=E2=80=9D, we need to keep in mind = that, if the DB-backend can=E2=80=99t do it, then the server logic will = need to it, likely by retrieving all records and brute-forcing its way = through them, which would not only be painfully slow, but a lot of = implementation complexity. That said, I=E2=80=99m unsure what use-case = you have in mind whereby a non-indexable column is being = filtered/sorted. Only a couple of the built-in types aren=E2=80=99t = indexable, right? Yes, XPath is the =E2=80=9Cright answer=E2=80=9D, but we need to ensure = it=E2=80=99s constrained enough to be mappable to common DB-backends. Updating my previous response (per above, plus adding leaf-list, plus = locking-in names, which I=E2=80=99m choosing only to NOT sound like = SQL): For all lists and leaf-lists: a) count (uint, default: 0) b) skip (uint, default: 0) c) direction (enum: forwards/backwards, default: = forwards) For non =E2=80=9Cordered-by user=E2=80=9D lists only (N/A to = leaf-lists), but only for indexable columns: d) sort-by (string: a single column/leaf = name) For all lists and leaf-lists, but only for indexable columns = (note: for a leaf-list, it is its own indexable column): e) filter (a constrained Xpath expression) Again: sequence of operation is e =E2=80=94> a. We haven=E2=80=99t discussed =E2=80=9Cfeature=E2=80=9D statements yet, = but it seems reasonable to me for both =E2=80=98d=E2=80=99 and =E2=80=98e=E2= =80=99 to be optionally implemented. Additionally, it may be that = additional Xpath expressions can be unlocked by feature statements). > We could define a few more XPath functions for such comparisons. Sure, but I wonder if, e.g., a netmask filter, is supportable by common = DB-backends. I=E2=80=99m hoping we have some DB-experts on the list!=20 K. --Apple-Mail=_4EEBF8F0-A620-479E-92E7-8805CFB43A8C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Martin,

I don't think d) and e) should be restricted to obu lists, = and I don't
think they = should be restricted to "indexable" columns.

And I think "expression of some = sort" should be XPath.

Also, since the main objective is efficient retrieval, = "sort-by"
can perhaps = be removed.  Consider large lists in operational state
that also change = often.

Your = last paragraph, if I read it correctly, says =E2=80=9Cmaybe don=E2=80=99t = do =E2=80=98d=E2=80=99=E2=80=9D, which if applied to the first part of = your response becomes "I don't think 'e' should be restricted to = OBU-lists=E2=80=9D, which is something I can agree with.  As for = =E2=80=98d=E2=80=99 being a reasonable thing to support for OBU-lists, = please explain the use-case.

Regarding= =E2=80=9CI don=E2=80=99t think they should be restricted to = =E2=80=98indexable=E2=80=99 columns=E2=80=9D, we need to keep in mind = that, if the DB-backend can=E2=80=99t do it, then the server logic will = need to it, likely by retrieving all records and brute-forcing its way = through them, which would not only be painfully slow, but a lot of = implementation complexity.  That said, I=E2=80=99m unsure what = use-case you have in mind whereby a non-indexable column is being = filtered/sorted.  Only a couple of the built-in types aren=E2=80=99t = indexable, right?

Yes, XPath is the = =E2=80=9Cright answer=E2=80=9D, but we need to ensure it=E2=80=99s = constrained enough to be mappable to common DB-backends.

Updating my previous response (per above, plus = adding leaf-list, plus locking-in names, which I=E2=80=99m choosing only = to NOT sound like SQL):


= For all lists and leaf-lists:

a) = count = (uint, default: 0)
b) skip = (uint, default: 0)
c) = direction = (enum: forwards/backwards, default: forwards)


For non =E2=80=9Cordered-by = user=E2=80=9D lists only (N/A to leaf-lists), = but
= only for indexable columns:

d) sort-by = (string: a single column/leaf name)


For all lists and leaf-lists, but = only for indexable columns (note: for
a leaf-list, it is its own = indexable column):
e) filter = (a constrained Xpath expression)


Again: = sequence of operation is e =E2=80=94> a.


We haven=E2=80=99t = discussed =E2=80=9Cfeature=E2=80=9D statements yet, but it seems = reasonable to me for both =E2=80=98d=E2=80=99 and =E2=80=98e=E2=80=99 to = be optionally implemented.  Additionally, it may be that additional = Xpath expressions can be unlocked by feature statements).


We could define a few more XPath functions for such = comparisons.

Sure, but I wonder if, e.g., a netmask filter, is = supportable by common DB-backends.  I=E2=80=99m hoping we have some = DB-experts on the list! 


K.



= --Apple-Mail=_4EEBF8F0-A620-479E-92E7-8805CFB43A8C-- From nobody Tue Sep 29 16:05:44 2020 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 5ADD03A139E for ; Tue, 29 Sep 2020 16:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBLxh2LOBBb1 for ; Tue, 29 Sep 2020 16:05:40 -0700 (PDT) Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0FD53A1399 for ; Tue, 29 Sep 2020 16:05:38 -0700 (PDT) Received: from nitebug.nitenet.local (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id 5A82524704A; Wed, 30 Sep 2020 01:05:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1601420735; bh=yWE8DJ/Ky7456xtE5yLzsKAmnMLYPEub/HFMnmcKlnU=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=UjnmZKVXvJjIjhz7Ihq+teMHF7ZyP11jIAZOtqyNfmyz6pteygafaPytjOAItaLUT XojBd7LwaWnpUt7fy36mdiQloXvIbUj0h0V9W4tO84QNcHiLCafisGk4k7ZQ4teFy1 CXjsXguVS9yYmxaYr56kCnK0wYWm2S1AmnHGuPPo= To: Kent Watsen , Andy Bierman Cc: "netconf@ietf.org" References: <01000174cb6ea9ee-d7716c10-a691-4a97-9e99-022e4c0ef55a-000000@email.amazonses.com> <01000174cbc7532c-81a16bed-e752-4e61-9a97-dfc95be744b5-000000@email.amazonses.com> From: Robert Varga Message-ID: <03b851c0-f45b-05c5-a861-0c49724cb5f2@hq.sk> Date: Wed, 30 Sep 2020 01:05:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <01000174cbc7532c-81a16bed-e752-4e61-9a97-dfc95be744b5-000000@email.amazonses.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cCmP3nquiBsZeIdZSx68PYAbXv1Ws9AR5" Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2020 23:05:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cCmP3nquiBsZeIdZSx68PYAbXv1Ws9AR5 Content-Type: multipart/mixed; boundary="g02hNjlTSpy5mse8coGvKjfyN1gM63i6b" --g02hNjlTSpy5mse8coGvKjfyN1gM63i6b Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 26/09/2020 20:57, Kent Watsen wrote: >> There are 3 completely different approaches: >> >> =C2=A0 1) stateless >> =C2=A0 2) stateful >> =C2=A0 3) stateful snapshot >> >> How to efficiently iterate through data that is changing constantly? >> This problem is harder than it looks. >=20 > Agreed. =C2=A0I recommend we NOT try to solve that problem. Unfortunately you do need to pick an interaction model to tie together the first and second pagination requests. At the very least you need to specify consistency guarantees between the two -- which gives them worms juuust enough room to wiggle out of the can. A fair answer is 'well, they are not tied together and if the datastore moves, you are SOL' ... but then how do you make forward progress with enough consistency to be useful in the real world? :) At the end of the day, you will end up creating some state on the server, which the server will need to be free to revoke at any time (due to resource constraints, or whatever implementation-specific reasons). Regards, Robert --g02hNjlTSpy5mse8coGvKjfyN1gM63i6b-- --cCmP3nquiBsZeIdZSx68PYAbXv1Ws9AR5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQI/BAEBCgApFiEEdj+N7pgGP1gKvbdQJKB0S2uuNdsFAl9zvbkLHG5pdGVAaHEu c2sACgkQJKB0S2uuNdtrVBAAvIqWnwN3dgl7xkqRs0zSz5dNdYjtbM4xA1P4v0N8 X3PcgF2J12Jhd6maqjxH29ZP7n6ZfN3zz7yXDCTzm306OfOGkzV0+dspuFBhXJRy hTC09I0pb6PiVoGes/ddd18iBDwuu6ZDQPslAzBIv3b2mW0i8Xx/oVCX7xpx2iYI yxeQacl+MN2NYyunFpv3LAOJWcW9zcDMet4DrWzQE1Pdqaab8D/8VD+yYmlAwJji GYNS9TCff8Y2YKlqzMdURj+6NHVTUlf8+iVkbI40izRJODOB63jYh6Cy87AdBHjk T3V97VaCgYfO+nUgTrp5g6ikUFv/y6kQtoKpnHncKikGPsjTi4iyIsP+ISWAq+gY pk8fvzWByjylvOfDGUFZZU3kFSNeEp7RJW4YeL/hplSBBYjO4paCdB28xgmeAJIC K9Vafn1WsHUYHCtsMMmKi6z4NEUpYxmtWxTjZAk5cznPWgT4d9Uz+SresnntjmIP 8DEfJME7XH9ECfXBCCjw6VaATI06pglbEaPr7sr7wqf2uhi9woyf6Rh/y7tN/3Qy 3ob5ZIJ/oY0DVh5Thycxn1Qy5sD9RwVIVXhV+gDr0h71/4hstbfgoiNA9mP1d1t9 +El1RN0MSY6eRlVj2duOhAqRmvU3U9zoQS0zDPwd1hmyHeEw11KWhsmINViqytOa BWk= =iIK1 -----END PGP SIGNATURE----- --cCmP3nquiBsZeIdZSx68PYAbXv1Ws9AR5-- From nobody Tue Sep 29 16:23:54 2020 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 5518F3A13BB for ; Tue, 29 Sep 2020 16:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u_Qc9n6cGT7r for ; Tue, 29 Sep 2020 16:23:51 -0700 (PDT) Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C9B63A13B2 for ; Tue, 29 Sep 2020 16:23:51 -0700 (PDT) Received: from nitebug.nitenet.local (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id 8235C24704A; Wed, 30 Sep 2020 01:23:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1601421829; bh=GnScfSz0xCek9ow9WBENSQDgu3xCh0+OL0F61CJy1yk=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=nPtvMupBcyubWjjoMKZ2D1DGbmG5Y718mY96nGEOxtUCy8ZEQQraSkIMV6h4TGBRK 1QS3KEItFL3xL2LRgGJLsH2Cn1fqr39FMxpSlTR6ICDMW3gl8iJIokH6uDVst5yygv Jjor9o5+tcZ+BhcOFE2hqfVv9mtEU2DIQLCtFC/E= To: =?UTF-8?Q?Martin_Bj=c3=b6rklund?= , kent+ietf@watsen.net Cc: netconf@ietf.org References: <01000174d5174af9-848a769d-ef3f-49a6-b1d6-1eb8349a489f-000000@email.amazonses.com> <01000174daf6ded3-0ba5564d-f1c7-4c65-90dc-d8a22f2f9395-000000@email.amazonses.com> <20200929.205710.165167541047857442.id@4668.se> From: Robert Varga Message-ID: Date: Wed, 30 Sep 2020 01:23:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200929.205710.165167541047857442.id@4668.se> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="B4qgGWHLEAK4Nart151jbYHhAUGMrwLL1" Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2020 23:23:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --B4qgGWHLEAK4Nart151jbYHhAUGMrwLL1 Content-Type: multipart/mixed; boundary="HwQ1JZKWqU7g3TgV26tQk4YZiLb5G2hEr" --HwQ1JZKWqU7g3TgV26tQk4YZiLb5G2hEr Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 29/09/2020 20:57, Martin Bj=C3=B6rklund wrote: > Also, since the main objective is efficient retrieval, "sort-by" > can perhaps be removed. Consider large lists in operational state > that also change often. +1. Getting hold of enough state to guarantee stable iteration order can be done quite efficiently. Sorting requires touching the data indices at the very least (to understand that no sorting is needed), potentially a huge CPU/MEM/network operation at the worst (a.k.a. "establish global order of entities in a distributed system"). If the criteria is user-specified, the possibility of a DoS becomes very real -- and hence the question becomes 'can the query be sufficiently analyzed to reject it early and prevent overloading the system?' :) Regards, Robert --HwQ1JZKWqU7g3TgV26tQk4YZiLb5G2hEr-- --B4qgGWHLEAK4Nart151jbYHhAUGMrwLL1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQI/BAEBCgApFiEEdj+N7pgGP1gKvbdQJKB0S2uuNdsFAl9zwgULHG5pdGVAaHEu c2sACgkQJKB0S2uuNdv6Gw/9EFyd3ZVqOJxKFJXEC/zmmJBqHmcXiyik+obOV0Vq CPaIMU1e0KuesJugLHbFhusd782XaBmhMWL7RXwagwwL3ncIKnd84kjR+K/2HvTn jAX3F8LblwYaffTQYes462XVLzB9/HfGbymjP/J8U8b7lX8UUoyVDUO8krVuowjI zJfW3mN1ETnL6ADVkDGWab9JRw1bcOaAtGL38WGmo7PyG7+G1fQo3hlp90Em9ihT U5z6cQOK/pp7ZPdOfckLpNFlkW1iYthvwBV1pFxrq+1MvcC/GSuARvxDaweXkdIX v7Bpo4NWm59sCD9v9hiaOyNEwX9U9i/Qmgz/hKvPTOTZf6KILux1e0ipdXKoLALY 5avWjXcazi6qDZC9nX5lzV80GskKM/JtE+BZT+WdSXeCXgYAYbfyulf6aVkPzEF3 gccmQ4FTxj0rBCJM4VgCMUryGR5gAsCTJUnmSibuXosC2fX9yHb1OE4yEX6r3Dle ApZuHrIQKHWG6HeJm2hmmpdJEKZ0omog/Tl/TZ9cKVFA0ZMfimPjbgms1oqPBioW r7mxBawXMIuDria/McGzp+ko38bUXpr3DDkq7FYthdiboLE0vSzolrw91k+i3f+l va1XoF7+qPFLEB7zQH2+YPC54gR/1QxcJmok0uguoGaPzFoSnFSdjKHgF9Vnuslk Lzc= =Q+AI -----END PGP SIGNATURE----- --B4qgGWHLEAK4Nart151jbYHhAUGMrwLL1-- From nobody Tue Sep 29 18:12:09 2020 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 B3C8C3A0598 for ; Tue, 29 Sep 2020 18:12:07 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 eZEKAXhkUkbP for ; Tue, 29 Sep 2020 18:12:06 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 93BD83A0597 for ; Tue, 29 Sep 2020 18:12:06 -0700 (PDT) Received: from lhreml734-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 3BFFBA0B9C1A59244B53 for ; Wed, 30 Sep 2020 02:12:03 +0100 (IST) Received: from lhreml734-chm.china.huawei.com (10.201.108.85) by lhreml734-chm.china.huawei.com (10.201.108.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 30 Sep 2020 02:12:03 +0100 Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml734-chm.china.huawei.com (10.201.108.85) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Wed, 30 Sep 2020 02:12:02 +0100 Received: from DGGEML531-MBS.china.huawei.com ([169.254.5.245]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0487.000; Wed, 30 Sep 2020 09:11:57 +0800 From: Qin Wu To: Robert Varga , Kent Watsen , "Andy Bierman" CC: "netconf@ietf.org" Thread-Topic: [netconf] restconf collections Thread-Index: AdaWxrARb7QoF9WvRqqa3/OiAxOZvg== Date: Wed, 30 Sep 2020 01:11:57 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.101.103] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 01:12:08 -0000 SGksIFJvYmVydDoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogbmV0Y29uZiBb bWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIFJvYmVydCBWYXJnYQ0K5Y+R 6YCB5pe26Ze0OiAyMDIw5bm0OeaciDMw5pelIDc6MDUNCuaUtuS7tuS6ujogS2VudCBXYXRzZW4g PGtlbnQraWV0ZkB3YXRzZW4ubmV0PjsgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+ DQrmioTpgIE6IG5ldGNvbmZAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtuZXRjb25mXSByZXN0Y29u ZiBjb2xsZWN0aW9ucw0KDQpPbiAyNi8wOS8yMDIwIDIwOjU3LCBLZW50IFdhdHNlbiB3cm90ZToN Cj4+IFRoZXJlIGFyZSAzIGNvbXBsZXRlbHkgZGlmZmVyZW50IGFwcHJvYWNoZXM6DQo+Pg0KPj4g wqAgMSkgc3RhdGVsZXNzDQo+PiDCoCAyKSBzdGF0ZWZ1bA0KPj4gwqAgMykgc3RhdGVmdWwgc25h cHNob3QNCj4+DQo+PiBIb3cgdG8gZWZmaWNpZW50bHkgaXRlcmF0ZSB0aHJvdWdoIGRhdGEgdGhh dCBpcyBjaGFuZ2luZyBjb25zdGFudGx5Pw0KPj4gVGhpcyBwcm9ibGVtIGlzIGhhcmRlciB0aGFu IGl0IGxvb2tzLg0KPiANCj4gQWdyZWVkLiDCoEkgcmVjb21tZW5kIHdlIE5PVCB0cnkgdG8gc29s dmUgdGhhdCBwcm9ibGVtLg0KDQpVbmZvcnR1bmF0ZWx5IHlvdSBkbyBuZWVkIHRvIHBpY2sgYW4g aW50ZXJhY3Rpb24gbW9kZWwgdG8gdGllIHRvZ2V0aGVyIHRoZSBmaXJzdCBhbmQgc2Vjb25kIHBh Z2luYXRpb24gcmVxdWVzdHMuIEF0IHRoZSB2ZXJ5IGxlYXN0IHlvdSBuZWVkIHRvIHNwZWNpZnkg Y29uc2lzdGVuY3kgZ3VhcmFudGVlcyBiZXR3ZWVuIHRoZSB0d28gLS0gd2hpY2ggZ2l2ZXMgdGhl bSB3b3JtcyBqdXV1c3QgZW5vdWdoIHJvb20gdG8gd2lnZ2xlIG91dCBvZiB0aGUgY2FuLg0KDQpb UWluXTpJIHRoaW5rIHdoZW4gdGhlIGNsaWVudCBVc2luZyBwYWdlIHJlcXVlc3QgdG8gZ2V0IGFj Y2VzcyB0byB0aGUgZWxlbWVudCBpbiB0aGUgbGlzdCwgaGUgb25seSBuZWVkIHRvIHJlbWVtYmVy IHRoZSBwb3NpdGlvbiBvZiBsYXN0IGVsZW1lbnQgaW4gdGhlIGZpcnN0IHBhZ2luYXRpb24gcmVx dWVzdCBhbmQgc2V0IHRoZSBudW1iZXIgb2YgZWxlbWVudCBoZSB3YW50IHRvIHJlcXVlc3QgaW4g dGhlIHBhZ2luYXRpb24gcmVxdWVzdHMsDQpUaGUgc2VydmVyIGRvZXNuJ3QgbmVlZCB0byBrZWVw IGFueSBhZGRpdGlvbmFsIHN0YXRlcywgdGhlIHNlcnZlciBvbmx5IG5lZWQgdG8gc3VwcG9ydCBs aXN0IG9wZXJhdGlvbi4NCg0KQSBmYWlyIGFuc3dlciBpcyAnd2VsbCwgdGhleSBhcmUgbm90IHRp ZWQgdG9nZXRoZXIgYW5kIGlmIHRoZSBkYXRhc3RvcmUgbW92ZXMsIHlvdSBhcmUgU09MJyAuLi4g YnV0IHRoZW4gaG93IGRvIHlvdSBtYWtlIGZvcndhcmQgcHJvZ3Jlc3Mgd2l0aCBlbm91Z2ggY29u c2lzdGVuY3kgdG8gYmUgdXNlZnVsIGluIHRoZSByZWFsIHdvcmxkPyA6KQ0KDQoNCltRaW5dOiBJ IHRoaW5rIGl0IGRvZXNuJ3QgbWF0dGVyIHdoZXRoZXIgdGhlIGxpc3Qgd2lsbCBncm93IGFuZCBh ZGQgbmV3IGVsZW1lbnRzLCB3ZSBjb3VsZCBzdGlsbCB1c2UgbGFzdCBlbGVtZW50IHBvc2l0aW9u IGFuZCBjb3VudCBvZiBlbGVtZW50cyBpbiB0aGUgbGlzdCB0aGF0IG5lZWQgdG8gYmUgcXVlcmll ZCB0byByZXRyaWV2ZSBhZGRpdGlvbmFsIGVsZW1lbnRzIHdlIHdhbnQuDQoNCkF0IHRoZSBlbmQg b2YgdGhlIGRheSwgeW91IHdpbGwgZW5kIHVwIGNyZWF0aW5nIHNvbWUgc3RhdGUgb24gdGhlIHNl cnZlciwgd2hpY2ggdGhlIHNlcnZlciB3aWxsIG5lZWQgdG8gYmUgZnJlZSB0byByZXZva2UgYXQg YW55IHRpbWUgKGR1ZSB0byByZXNvdXJjZSBjb25zdHJhaW50cywgb3Igd2hhdGV2ZXIgaW1wbGVt ZW50YXRpb24tc3BlY2lmaWMgcmVhc29ucykuDQoNClJlZ2FyZHMsDQpSb2JlcnQNCg0K From nobody Tue Sep 29 18:27:54 2020 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 A40A33A0992 for ; Tue, 29 Sep 2020 18:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 F6sY_5KxJEoe for ; Tue, 29 Sep 2020 18:27:50 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 9C3023A0982 for ; Tue, 29 Sep 2020 18:27:50 -0700 (PDT) Received: from lhreml731-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 27C596BB8E2A243A69F8 for ; Wed, 30 Sep 2020 02:27:49 +0100 (IST) Received: from lhreml731-chm.china.huawei.com (10.201.108.82) by lhreml731-chm.china.huawei.com (10.201.108.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 30 Sep 2020 02:27:48 +0100 Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by lhreml731-chm.china.huawei.com (10.201.108.82) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Wed, 30 Sep 2020 02:27:48 +0100 Received: from DGGEML531-MBS.china.huawei.com ([169.254.5.245]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0487.000; Wed, 30 Sep 2020 09:27:43 +0800 From: Qin Wu To: Kent Watsen , =?utf-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= CC: "netconf@ietf.org" Thread-Topic: [netconf] restconf collections Thread-Index: AdaWyD+878Wbd/BNR1i0vXS4P7t/Ug== Date: Wed, 30 Sep 2020 01:27:43 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.101.103] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAADA34671dggeml531mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 01:27:53 -0000 --_000_B8F9A780D330094D99AF023C5877DABAADA34671dggeml531mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 5Y+R5Lu25Lq6OiBuZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSDku6Po oaggS2VudCBXYXRzZW4NCuWPkemAgeaXtumXtDogMjAyMOW5tDnmnIgzMOaXpSA1OjU3DQrmlLbk u7bkuro6IE1hcnRpbiBCasO2cmtsdW5kIDxtYmoraWV0ZkA0NjY4LnNlPg0K5oqE6YCBOiBuZXRj b25mQGlldGYub3JnDQrkuLvpopg6IFJlOiBbbmV0Y29uZl0gcmVzdGNvbmYgY29sbGVjdGlvbnMN Cg0KSGkgTWFydGluLA0KDQoNCkkgZG9uJ3QgdGhpbmsgZCkgYW5kIGUpIHNob3VsZCBiZSByZXN0 cmljdGVkIHRvIG9idSBsaXN0cywgYW5kIEkgZG9uJ3QNCnRoaW5rIHRoZXkgc2hvdWxkIGJlIHJl c3RyaWN0ZWQgdG8gImluZGV4YWJsZSIgY29sdW1ucy4NCg0KQW5kIEkgdGhpbmsgImV4cHJlc3Np b24gb2Ygc29tZSBzb3J0IiBzaG91bGQgYmUgWFBhdGguDQoNCkFsc28sIHNpbmNlIHRoZSBtYWlu IG9iamVjdGl2ZSBpcyBlZmZpY2llbnQgcmV0cmlldmFsLCAic29ydC1ieSINCmNhbiBwZXJoYXBz IGJlIHJlbW92ZWQuICBDb25zaWRlciBsYXJnZSBsaXN0cyBpbiBvcGVyYXRpb25hbCBzdGF0ZQ0K dGhhdCBhbHNvIGNoYW5nZSBvZnRlbi4NCg0KWW91ciBsYXN0IHBhcmFncmFwaCwgaWYgSSByZWFk IGl0IGNvcnJlY3RseSwgc2F5cyDigJxtYXliZSBkb27igJl0IGRvIOKAmGTigJnigJ0sIHdoaWNo IGlmIGFwcGxpZWQgdG8gdGhlIGZpcnN0IHBhcnQgb2YgeW91ciByZXNwb25zZSBiZWNvbWVzICJJ IGRvbid0IHRoaW5rICdlJyBzaG91bGQgYmUgcmVzdHJpY3RlZCB0byBPQlUtbGlzdHPigJ0sIHdo aWNoIGlzIHNvbWV0aGluZyBJIGNhbiBhZ3JlZSB3aXRoLiAgQXMgZm9yIOKAmGTigJkgYmVpbmcg YSByZWFzb25hYmxlIHRoaW5nIHRvIHN1cHBvcnQgZm9yIE9CVS1saXN0cywgcGxlYXNlIGV4cGxh aW4gdGhlIHVzZS1jYXNlLg0KDQpSZWdhcmRpbmcg4oCcSSBkb27igJl0IHRoaW5rIHRoZXkgc2hv dWxkIGJlIHJlc3RyaWN0ZWQgdG8g4oCYaW5kZXhhYmxl4oCZIGNvbHVtbnPigJ0sIHdlIG5lZWQg dG8ga2VlcCBpbiBtaW5kIHRoYXQsIGlmIHRoZSBEQi1iYWNrZW5kIGNhbuKAmXQgZG8gaXQsIHRo ZW4gdGhlIHNlcnZlciBsb2dpYyB3aWxsIG5lZWQgdG8gaXQsIGxpa2VseSBieSByZXRyaWV2aW5n IGFsbCByZWNvcmRzIGFuZCBicnV0ZS1mb3JjaW5nIGl0cyB3YXkgdGhyb3VnaCB0aGVtLCB3aGlj aCB3b3VsZCBub3Qgb25seSBiZSBwYWluZnVsbHkgc2xvdywgYnV0IGEgbG90IG9mIGltcGxlbWVu dGF0aW9uIGNvbXBsZXhpdHkuICBUaGF0IHNhaWQsIEnigJltIHVuc3VyZSB3aGF0IHVzZS1jYXNl IHlvdSBoYXZlIGluIG1pbmQgd2hlcmVieSBhIG5vbi1pbmRleGFibGUgY29sdW1uIGlzIGJlaW5n IGZpbHRlcmVkL3NvcnRlZC4gIE9ubHkgYSBjb3VwbGUgb2YgdGhlIGJ1aWx0LWluIHR5cGVzIGFy ZW7igJl0IGluZGV4YWJsZSwgcmlnaHQ/DQoNClllcywgWFBhdGggaXMgdGhlIOKAnHJpZ2h0IGFu c3dlcuKAnSwgYnV0IHdlIG5lZWQgdG8gZW5zdXJlIGl04oCZcyBjb25zdHJhaW5lZCBlbm91Z2gg dG8gYmUgbWFwcGFibGUgdG8gY29tbW9uIERCLWJhY2tlbmRzLg0KDQpVcGRhdGluZyBteSBwcmV2 aW91cyByZXNwb25zZSAocGVyIGFib3ZlLCBwbHVzIGFkZGluZyBsZWFmLWxpc3QsIHBsdXMgbG9j a2luZy1pbiBuYW1lcywgd2hpY2ggSeKAmW0gY2hvb3Npbmcgb25seSB0byBOT1Qgc291bmQgbGlr ZSBTUUwpOg0KDQoNCiAgICBGb3IgYWxsIGxpc3RzIGFuZCBsZWFmLWxpc3RzOg0KDQogICAgICAg YSkgY291bnQgICAgICAodWludCwgZGVmYXVsdDogMCkNCiAgICAgICBiKSBza2lwICAgICAgICh1 aW50LCBkZWZhdWx0OiAwKQ0KICAgICAgIGMpIGRpcmVjdGlvbiAgKGVudW06IGZvcndhcmRzL2Jh Y2t3YXJkcywgZGVmYXVsdDogZm9yd2FyZHMpDQoNCg0KICAgIEZvciBub24g4oCcb3JkZXJlZC1i eSB1c2Vy4oCdIGxpc3RzIG9ubHkgKE4vQSB0byBsZWFmLWxpc3RzKSwgYnV0DQogICAgb25seSBm b3IgaW5kZXhhYmxlIGNvbHVtbnM6DQoNCiAgICAgICBkKSBzb3J0LWJ5ICAgIChzdHJpbmc6IGEg c2luZ2xlIGNvbHVtbi9sZWFmIG5hbWUpDQoNCg0KICAgIEZvciBhbGwgbGlzdHMgYW5kIGxlYWYt bGlzdHMsIGJ1dCBvbmx5IGZvciBpbmRleGFibGUgY29sdW1ucyAobm90ZTogZm9yDQogICAgYSBs ZWFmLWxpc3QsIGl0IGlzIGl0cyBvd24gaW5kZXhhYmxlIGNvbHVtbik6DQogICAgICAgZSkgZmls dGVyICAgICAoYSBjb25zdHJhaW5lZCBYcGF0aCBleHByZXNzaW9uKQ0KDQogICAgQWdhaW46IHNl cXVlbmNlIG9mIG9wZXJhdGlvbiBpcyBlIOKAlD4gYS4NCg0KDQpXZSBoYXZlbuKAmXQgZGlzY3Vz c2VkIOKAnGZlYXR1cmXigJ0gc3RhdGVtZW50cyB5ZXQsIGJ1dCBpdCBzZWVtcyByZWFzb25hYmxl IHRvIG1lIGZvciBib3RoIOKAmGTigJkgYW5kIOKAmGXigJkgdG8gYmUgb3B0aW9uYWxseSBpbXBs ZW1lbnRlZC4gIEFkZGl0aW9uYWxseSwgaXQgbWF5IGJlIHRoYXQgYWRkaXRpb25hbCBYcGF0aCBl eHByZXNzaW9ucyBjYW4gYmUgdW5sb2NrZWQgYnkgZmVhdHVyZSBzdGF0ZW1lbnRzKS4NCg0KW1Fp bl0gVW1tLCB0aGlzIHNlZW1zIGEgZ29vZCBjaG9pY2UuIEkgZmVlbCBzb3J0LWJ5IGlzIG5pY2Ug dG8gaGF2ZSBmZWF0dXJlLCBpbiBtYW55IGNhc2VzLCB2ZXJ5IHVzZWZ1bC4gQnV0IHdlIG5lZWQg dG8gd2hlbiBzb3J0LWJ5IGlzIHJlcXVpcmVkIGFuZCB3aGVuIGlzIG5vdC4NCg0KV2UgY291bGQg ZGVmaW5lIGEgZmV3IG1vcmUgWFBhdGggZnVuY3Rpb25zIGZvciBzdWNoIGNvbXBhcmlzb25zLg0K DQpTdXJlLCBidXQgSSB3b25kZXIgaWYsIGUuZy4sIGEgbmV0bWFzayBmaWx0ZXIsIGlzIHN1cHBv cnRhYmxlIGJ5IGNvbW1vbiBEQi1iYWNrZW5kcy4gIEnigJltIGhvcGluZyB3ZSBoYXZlIHNvbWUg REItZXhwZXJ0cyBvbiB0aGUgbGlzdCENCg0KDQpLLg0KDQoNCg0K --_000_B8F9A780D330094D99AF023C5877DABAADA34671dggeml531mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBh bm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrl rovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uYXBw bGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkw LjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9IiMwNTYzQzEiIHZsaW5r PSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvl vq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMi Pjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPiBu ZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXQ0KPC9zcGFuPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZx dW90OyxzYW5zLXNlcmlmIj7ku6PooaggPC9zcGFuPg0KPC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVv dDssc2Fucy1zZXJpZiI+S2VudCBXYXRzZW48YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMt c2VyaWYiPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj4gMjAyMDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDss c2Fucy1zZXJpZiI+5bm0PHNwYW4gbGFuZz0iRU4tVVMiPjk8L3NwYW4+5pyIPHNwYW4gbGFuZz0i RU4tVVMiPjMwPC9zcGFuPuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4NCiA1OjU3PGJyPg0KPC9zcGFu PjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyI+IE1hcnRpbiBCasO2cmtsdW5kICZsdDttYmomIzQzO2lldGZANDY2OC5zZSZndDs8YnI+ DQo8L3NwYW4+PGI+5oqE6YCBPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIj4gbmV0Y29uZkBpZXRmLm9yZzxicj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBs YW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBSZTogW25ldGNvbmZd IHJlc3Rjb25mIGNvbGxlY3Rpb25zPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGkgTWFydGlu LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5J IGRvbid0IHRoaW5rIGQpIGFuZCBlKSBzaG91bGQgYmUgcmVzdHJpY3RlZCB0byBvYnUgbGlzdHMs IGFuZCBJIGRvbid0PGJyPg0KdGhpbmsgdGhleSBzaG91bGQgYmUgcmVzdHJpY3RlZCB0byAmcXVv dDtpbmRleGFibGUmcXVvdDsgY29sdW1ucy48YnI+DQo8YnI+DQpBbmQgSSB0aGluayAmcXVvdDtl eHByZXNzaW9uIG9mIHNvbWUgc29ydCZxdW90OyBzaG91bGQgYmUgWFBhdGguPGJyPg0KPGJyPg0K QWxzbywgc2luY2UgdGhlIG1haW4gb2JqZWN0aXZlIGlzIGVmZmljaWVudCByZXRyaWV2YWwsICZx dW90O3NvcnQtYnkmcXVvdDs8YnI+DQpjYW4gcGVyaGFwcyBiZSByZW1vdmVkLiAmbmJzcDtDb25z aWRlciBsYXJnZSBsaXN0cyBpbiBvcGVyYXRpb25hbCBzdGF0ZTxicj4NCnRoYXQgYWxzbyBjaGFu Z2Ugb2Z0ZW4uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPllvdXIgbGFzdCBwYXJh Z3JhcGgsIGlmIEkgcmVhZCBpdCBjb3JyZWN0bHksIHNheXMg4oCcbWF5YmUgZG9u4oCZdCBkbyDi gJhk4oCZ4oCdLCB3aGljaCBpZiBhcHBsaWVkIHRvIHRoZSBmaXJzdCBwYXJ0IG9mIHlvdXIgcmVz cG9uc2UgYmVjb21lcyAmcXVvdDtJIGRvbid0IHRoaW5rICdlJyBzaG91bGQgYmUgcmVzdHJpY3Rl ZCB0byBPQlUtbGlzdHPigJ0sIHdoaWNoIGlzIHNvbWV0aGluZyBJIGNhbiBhZ3JlZQ0KIHdpdGgu ICZuYnNwO0FzIGZvciDigJhk4oCZIGJlaW5nIGEgcmVhc29uYWJsZSB0aGluZyB0byBzdXBwb3J0 IGZvciBPQlUtbGlzdHMsIHBsZWFzZSBleHBsYWluIHRoZSB1c2UtY2FzZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZGluZyDigJxJIGRvbuKA mXQgdGhpbmsgdGhleSBzaG91bGQgYmUgcmVzdHJpY3RlZCB0byDigJhpbmRleGFibGXigJkgY29s dW1uc+KAnSwgd2UgbmVlZCB0byBrZWVwIGluIG1pbmQgdGhhdCwgaWYgdGhlIERCLWJhY2tlbmQg Y2Fu4oCZdCBkbyBpdCwgdGhlbiB0aGUgc2VydmVyIGxvZ2ljIHdpbGwgbmVlZCB0byBpdCwgbGlr ZWx5IGJ5IHJldHJpZXZpbmcgYWxsIHJlY29yZHMgYW5kIGJydXRlLWZvcmNpbmcNCiBpdHMgd2F5 IHRocm91Z2ggdGhlbSwgd2hpY2ggd291bGQgbm90IG9ubHkgYmUgcGFpbmZ1bGx5IHNsb3csIGJ1 dCBhIGxvdCBvZiBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5LiAmbmJzcDtUaGF0IHNhaWQsIEni gJltIHVuc3VyZSB3aGF0IHVzZS1jYXNlIHlvdSBoYXZlIGluIG1pbmQgd2hlcmVieSBhIG5vbi1p bmRleGFibGUgY29sdW1uIGlzIGJlaW5nIGZpbHRlcmVkL3NvcnRlZC4gJm5ic3A7T25seSBhIGNv dXBsZSBvZiB0aGUgYnVpbHQtaW4gdHlwZXMgYXJlbuKAmXQNCiBpbmRleGFibGUsIHJpZ2h0Pzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+WWVzLCBYUGF0 aCBpcyB0aGUg4oCccmlnaHQgYW5zd2Vy4oCdLCBidXQgd2UgbmVlZCB0byBlbnN1cmUgaXTigJlz IGNvbnN0cmFpbmVkIGVub3VnaCB0byBiZSBtYXBwYWJsZSB0byBjb21tb24gREItYmFja2VuZHMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5VcGRhdGlu ZyBteSBwcmV2aW91cyByZXNwb25zZSAocGVyIGFib3ZlLCBwbHVzIGFkZGluZyBsZWFmLWxpc3Qs IHBsdXMgbG9ja2luZy1pbiBuYW1lcywgd2hpY2ggSeKAmW0gY2hvb3Npbmcgb25seSB0byBOT1Qg c291bmQgbGlrZSBTUUwpOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsm bmJzcDsgPC9zcGFuPkZvciBhbGwgbGlzdHMgYW5kIGxlYWYtbGlzdHM6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5hKSBjb3VudDxzcGFuIGNsYXNzPSJhcHBsZS10 YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+KHVpbnQsIGRl ZmF1bHQ6IDApPGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPmIpIHNraXA8c3BhbiBjbGFzcz0iYXBwbGUt dGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPig8 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnVpbnQ8L3NwYW4+LCBkZWZhdWx0OiAwKTxicj4NCjxz cGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDwvc3Bhbj5jKSBkaXJlY3Rpb248c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZu YnNwOw0KPC9zcGFuPihlbnVtOiBmb3J3YXJkcy9iYWNrd2FyZHMsIGRlZmF1bHQ6IGZvcndhcmRz KTxicj4NCjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IDwvc3Bhbj5Gb3Igbm9uIOKAnG9yZGVyZWQtYnkgdXNlcuKAnSBsaXN0cyBvbmx5 ICg8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk4vQSB0byBsZWFmLWxpc3RzKTwvc3Bhbj4sIGJ1 dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5vbmx5IGZvciBp bmRleGFibGUgY29sdW1uczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xh c3M9ImFwcGxlLXRhYi1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ZCkg c29ydC1ieTxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwv c3Bhbj4oc3RyaW5nOiBhIHNpbmdsZSBjb2x1bW4vbGVhZiBuYW1lKTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNs YXNzPSJhcHBsZS10YWItc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6YmxhY2siPkZvciBhbGwgbGlzdHMgYW5kIGxlYWYtbGlzdHMsIGJ1dCBvbmx5 IGZvciBpbmRleGFibGUgY29sdW1ucyAobm90ZTogZm9yPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRh Yi1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+YSBsZWFmLWxpc3QsIGl0IGlzIGl0cyBvd24gaW5kZXhhYmxlIGNvbHVtbik6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ZSkgZmlsdGVyPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1z cGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPg0KKGEgY29uc3RyYWluZWQgWHBh dGggZXhwcmVzc2lvbik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9 ImFwcGxlLXRhYi1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwv c3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPkFnYWluOiBzZXF1ZW5jZSBvZiBvcGVyYXRp b24gaXMgZSDigJQmZ3Q7IGEuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2UgaGF2ZW7igJl0IGRpc2N1 c3NlZCDigJxmZWF0dXJl4oCdIHN0YXRlbWVudHMgeWV0LCBidXQgaXQgc2VlbXMgcmVhc29uYWJs ZSB0byBtZSBmb3IgYm90aCDigJhk4oCZIGFuZCDigJhl4oCZIHRvIGJlIG9wdGlvbmFsbHkgaW1w bGVtZW50ZWQuICZuYnNwO0FkZGl0aW9uYWxseSwgaXQgbWF5IGJlIHRoYXQgYWRkaXRpb25hbCBY cGF0aCBleHByZXNzaW9ucyBjYW4gYmUgdW5sb2NrZWQgYnkgZmVhdHVyZSBzdGF0ZW1lbnRzKS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1Fpbl0gVW1tLCB0aGlzIHNlZW1zIGEgZ29vZCBjaG9p Y2UuIEkgZmVlbCBzb3J0LWJ5IGlzIG5pY2UgdG8gaGF2ZSBmZWF0dXJlLCBpbiBtYW55IGNhc2Vz LCB2ZXJ5IHVzZWZ1bC4gQnV0IHdlIG5lZWQgdG8gd2hlbiBzb3J0LWJ5IGlzIHJlcXVpcmVkDQog YW5kIHdoZW4gaXMgbm90LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+V2UgY291bGQgZGVmaW5lIGEgZmV3IG1vcmUgWFBhdGgg ZnVuY3Rpb25zIGZvciBzdWNoIGNvbXBhcmlzb25zLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PlN1cmUsIGJ1dCBJIHdvbmRlciBpZiwgZS5nLiwgYSBuZXRtYXNrIGZpbHRlciwgaXMgc3VwcG9y dGFibGUgYnkgY29tbW9uIERCLWJhY2tlbmRzLiAmbmJzcDtJ4oCZbSBob3Bpbmcgd2UgaGF2ZSBz b21lIERCLWV4cGVydHMgb24gdGhlIGxpc3QhJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Sy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B8F9A780D330094D99AF023C5877DABAADA34671dggeml531mbschi_-- From nobody Tue Sep 29 23:43:33 2020 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 4C8063A1272 for ; Tue, 29 Sep 2020 23:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.997, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=pKn1hjJx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HNMXJzLE Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUnLpVrJZKcA for ; Tue, 29 Sep 2020 23:43:27 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B0273A0AA6 for ; Tue, 29 Sep 2020 23:43:16 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 072D95C01F9; Wed, 30 Sep 2020 02:43:15 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 30 Sep 2020 02:43:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm2; bh= Bz3r5b5A36pUrQQVrZ4LoS2H6oPA9fsVcqsSelZcZ+s=; b=pKn1hjJxXOfufk64 0+GXXn2syRcXYY3Pn0ZGGQwOOKILOAK31h33OxSI7lYac+ctnl5+dhxRbuk9EouU zzHZDGimAhI16S7dNyj4TFmgf5Q3fL3hZ2TPlIzBFvheJY4ghNMTJz1M3YoiiPab jy9tZziEepeZ41M5idiRWc66WGK7OlY2ELat6mFWpxB/Re4rrbc8QsufLCGPtE+c Q2NQYyIlKVwufldxSzKP6B/Mn9p3xYQwtJQ3mat25osEH4aYuI+O/blKNcPbO6iq RU6lA5c+9K4S+jGwtJfC6Mu20ICBVzCk3aiAVYRsFK7yD80Z+FkZjaK7zEP8mgfs CFhwWw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=Bz3r5b5A36pUrQQVrZ4LoS2H6oPA9fsVcqsSelZcZ +s=; b=HNMXJzLE/0cq8z+Xed8/zB3RC448W9463FS0G0d5NA7V5dXUFHmqTDOQ9 c80ZN+yaTk+PbhGIZQJFjeLs/cx9k+pfUajwK990wMN52EmFOuXbibfunXiBa6t/ qq2NnaC9ePKN2p3nfe2XVwDQdKUB8j0kHiwhqyC4C5BdQah1sO+0EBT5j+O2Usgu WuuM8TTzT0kBpVVq7XG+JgxGOPU5eR5zWJzKQRifq0E/eGgIGI2q8lhZ7VOaUxa4 /xmc1IVzfTPcf8ua9E0Ja6GWUF7WLBq9usgg4KS2cjKHgx9F6N1o/U60S9MiZkEl UdWHBBrc+h8/d7ZN6eoqFXhjcLBdg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrfedtgdduuddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtsg ertdertdejnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepheetgedtfffggeffkedvje ekveelteeuuddttdffhfelgfetvdevhedvgeeutddunecukfhppeduheekrddujeegrdeg rddvudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhgsjhdoihgvthhfseegieeikedrshgv X-ME-Proxy: Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id 69C583064674; Wed, 30 Sep 2020 02:43:14 -0400 (EDT) Date: Wed, 30 Sep 2020 08:43:12 +0200 (CEST) Message-Id: <20200930.084312.246821928590534256.id@4668.se> To: kent+ietf@watsen.net Cc: netconf@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <01000174dbde18ac-c9293572-775f-4c8e-b8c1-a8522bd636b5-000000@email.amazonses.com> References: <01000174daf6ded3-0ba5564d-f1c7-4c65-90dc-d8a22f2f9395-000000@email.amazonses.com> <20200929.205710.165167541047857442.id@4668.se> <01000174dbde18ac-c9293572-775f-4c8e-b8c1-a8522bd636b5-000000@email.amazonses.com> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 06:43:28 -0000 SGksDQoNCktlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD4gd3JvdGU6DQo+IEhpIE1h cnRpbiwNCj4gDQo+ID4gSSBkb24ndCB0aGluayBkKSBhbmQgZSkgc2hvdWxkIGJlIHJlc3RyaWN0 ZWQgdG8gb2J1IGxpc3RzLCBhbmQgSSBkb24ndA0KPiA+IHRoaW5rIHRoZXkgc2hvdWxkIGJlIHJl c3RyaWN0ZWQgdG8gImluZGV4YWJsZSIgY29sdW1ucy4NCj4gPiANCj4gPiBBbmQgSSB0aGluayAi ZXhwcmVzc2lvbiBvZiBzb21lIHNvcnQiIHNob3VsZCBiZSBYUGF0aC4NCj4gPiANCj4gPiBBbHNv LCBzaW5jZSB0aGUgbWFpbiBvYmplY3RpdmUgaXMgZWZmaWNpZW50IHJldHJpZXZhbCwgInNvcnQt YnkiDQo+ID4gY2FuIHBlcmhhcHMgYmUgcmVtb3ZlZC4gIENvbnNpZGVyIGxhcmdlIGxpc3RzIGlu IG9wZXJhdGlvbmFsIHN0YXRlDQo+ID4gdGhhdCBhbHNvIGNoYW5nZSBvZnRlbi4NCj4gDQo+IFlv dXIgbGFzdCBwYXJhZ3JhcGgsIGlmIEkgcmVhZCBpdCBjb3JyZWN0bHksIHNheXMg4oCcbWF5YmUg ZG9u4oCZdCBkbw0KPiDigJhk4oCZ4oCdLCB3aGljaCBpZiBhcHBsaWVkIHRvIHRoZSBmaXJzdCBw YXJ0IG9mIHlvdXIgcmVzcG9uc2UgYmVjb21lcyAiSQ0KPiBkb24ndCB0aGluayAnZScgc2hvdWxk IGJlIHJlc3RyaWN0ZWQgdG8gT0JVLWxpc3Rz4oCdLCB3aGljaCBpcyBzb21ldGhpbmcNCj4gSSBj YW4gYWdyZWUgd2l0aC4gIEFzIGZvciDigJhk4oCZIGJlaW5nIGEgcmVhc29uYWJsZSB0aGluZyB0 byBzdXBwb3J0IGZvcg0KPiBPQlUtbGlzdHMsIHBsZWFzZSBleHBsYWluIHRoZSB1c2UtY2FzZS4N Cg0KSWYgd2UgYWdyZWUgdG8gbm90IGRvIGQpIHRoZW4gd2UgZG9uJ3QgbmVlZCBhbnkgdXNlIGNh c2VzIGZvciBpdCA7LSkNCg0KQW55d2F5LCBpZiB5b3Ugd2FudCB0byBzb3J0IG9uIGRpZmZlcmVu dCBmaWVsZHMgeW91IHByb2JhYmx5IHdhbnQgdG8NCmRvIHRoaXMgcmVnYXJkbGVzcyBvZiBob3cg dGhlIGxpc3QgaXMgb3JkZXJkIG9uIHRoZSBzZXJ2ZXIuDQoNCj4gUmVnYXJkaW5nIOKAnEkgZG9u 4oCZdCB0aGluayB0aGV5IHNob3VsZCBiZSByZXN0cmljdGVkIHRvIOKAmGluZGV4YWJsZeKAmQ0K PiBjb2x1bW5z4oCdLCB3ZSBuZWVkIHRvIGtlZXAgaW4gbWluZCB0aGF0LCBpZiB0aGUgREItYmFj a2VuZCBjYW7igJl0IGRvIGl0LA0KPiB0aGVuIHRoZSBzZXJ2ZXIgbG9naWMgd2lsbCBuZWVkIHRv IGl0LCBsaWtlbHkgYnkgcmV0cmlldmluZyBhbGwNCj4gcmVjb3JkcyBhbmQgYnJ1dGUtZm9yY2lu ZyBpdHMgd2F5IHRocm91Z2ggdGhlbSwgd2hpY2ggd291bGQgbm90IG9ubHkNCj4gYmUgcGFpbmZ1 bGx5IHNsb3csIGJ1dCBhIGxvdCBvZiBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5LiAgVGhhdCBz YWlkLA0KPiBJ4oCZbSB1bnN1cmUgd2hhdCB1c2UtY2FzZSB5b3UgaGF2ZSBpbiBtaW5kIHdoZXJl YnkgYSBub24taW5kZXhhYmxlDQo+IGNvbHVtbiBpcyBiZWluZyBmaWx0ZXJlZC9zb3J0ZWQuICBP bmx5IGEgY291cGxlIG9mIHRoZSBidWlsdC1pbiB0eXBlcw0KPiBhcmVu4oCZdCBpbmRleGFibGUs IHJpZ2h0Pw0KDQpNeSBjb21tZW50IHdhcyBmb3IgYm90aCBkKSBhbmQgZSkgKHNvcnQgYW5kIGZp bHRlcikuICBBcyBmb3IgZmlsdGVyLA0KYW4gZXhhbXBsZSBpcyB0byBnZXQgaW50ZXJmYWNlcyBh bmQgd2l0aCBvcGVyLXN0YXR1cyA9PSAnZG93bicuDQoNCj4gWWVzLCBYUGF0aCBpcyB0aGUg4oCc cmlnaHQgYW5zd2Vy4oCdLCBidXQgd2UgbmVlZCB0byBlbnN1cmUgaXTigJlzDQo+IGNvbnN0cmFp bmVkIGVub3VnaCB0byBiZSBtYXBwYWJsZSB0byBjb21tb24gREItYmFja2VuZHMuDQoNClNvIHRo ZSBjbGllbnQgdGFsa3MgdG8gdGhlIHNlcnZlciwgYW5kIHRoZSBzZXJ2ZXIgdGFsa3MgdG8gdGhl ICJkYiINCmJhY2tlbmQgKG5vdGUgdGhhdCBpbiBtYW55IGltcGxlbWVudGF0aW9ucyAgb3BlcmF0 aW9uYWwgc3RhdGUgaXMNCnR5cGljYWxseSBub3Qgc3RvcmVkIGluIGEgcmVhbCBkYXRhYmFzZSku ICBTbyB3ZSBoYXZlOg0KDQogIGNsaWVudCAtPiAgc2VydmVyIC0+ICBiYWNrZW5kDQoNCklmIHdl IGRvbid0IGhhdmUgYW55IGZpbHRlciBjYXBhYmlsaXRpZXMsIHRoZSBjbGllbnQgaGFzIHRvIGdl dA0KZXZlcnl0aGluZywgYW5kIHRoZW4gZmlsdGVyLiAgSWYgd2Ugc3VwcG9ydCBYUGF0aCBhbmQg dGhlIGJhY2tlbmQNCmRvZXNuJ3Qgc3VwcG9ydCBpdCwgdGhlIHNlcnZlciB3aWxsIGhhdmUgdG8g ZmlsdGVyLiAgVGhpcyBpcyBzdGlsbA0KbW9yZSBlZmZpY2llbnQgdGhhbiBmaWx0ZXJpbmcgaW4g dGhlIGNsaWVudC4NCg0KSW4gQ29uZkQvTlNPIHdlIG1vdmVkIG1vcmUgYW5kIG1vcmUgZmlsdGVy aW5nIGxvZ2ljIHRvd2FyZHMgdGhlDQpiYWNrZW5kLCB0byBzcGVlZCB1cCBwZXJmb3JtYW5jZS4N Cg0KDQo+IFVwZGF0aW5nIG15IHByZXZpb3VzIHJlc3BvbnNlIChwZXIgYWJvdmUsIHBsdXMgYWRk aW5nIGxlYWYtbGlzdCwgcGx1cw0KPiBsb2NraW5nLWluIG5hbWVzLCB3aGljaCBJ4oCZbSBjaG9v c2luZyBvbmx5IHRvIE5PVCBzb3VuZCBsaWtlIFNRTCk6DQo+IA0KPiANCj4gCUZvciBhbGwgbGlz dHMgYW5kIGxlYWYtbGlzdHM6DQo+IA0KPiAJCWEpIGNvdW50CQkodWludCwgZGVmYXVsdDogMCkN Cj4gCQliKSBza2lwCQkodWludCwgZGVmYXVsdDogMCkNCj4gCQljKSBkaXJlY3Rpb24JKGVudW06 IGZvcndhcmRzL2JhY2t3YXJkcywgZGVmYXVsdDogZm9yd2FyZHMpDQo+IA0KPiANCj4gCUZvciBu b24g4oCcb3JkZXJlZC1ieSB1c2Vy4oCdIGxpc3RzIG9ubHkgKE4vQSB0byBsZWFmLWxpc3RzKSwg YnV0DQo+IAlvbmx5IGZvciBpbmRleGFibGUgY29sdW1uczoNCj4gDQo+IAkJZCkgc29ydC1ieQkJ KHN0cmluZzogYSBzaW5nbGUgY29sdW1uL2xlYWYgbmFtZSkNCj4gDQo+IA0KPiAJRm9yIGFsbCBs aXN0cyBhbmQgbGVhZi1saXN0cywgYnV0IG9ubHkgZm9yIGluZGV4YWJsZSBjb2x1bW5zIChub3Rl Og0KPiAJZm9yDQo+IAlhIGxlYWYtbGlzdCwgaXQgaXMgaXRzIG93biBpbmRleGFibGUgY29sdW1u KToNCj4gCQllKSBmaWx0ZXIJCShhIGNvbnN0cmFpbmVkIFhwYXRoIGV4cHJlc3Npb24pDQo+IA0K PiANCj4gCUFnYWluOiBzZXF1ZW5jZSBvZiBvcGVyYXRpb24gaXMgZSDigJQ+IGEuDQo+IA0KPiAN Cj4gV2UgaGF2ZW7igJl0IGRpc2N1c3NlZCDigJxmZWF0dXJl4oCdIHN0YXRlbWVudHMgeWV0LCBi dXQgaXQgc2VlbXMgcmVhc29uYWJsZQ0KPiB0byBtZSBmb3IgYm90aCDigJhk4oCZIGFuZCDigJhl 4oCZIHRvIGJlIG9wdGlvbmFsbHkgaW1wbGVtZW50ZWQuDQo+IEFkZGl0aW9uYWxseSwgaXQgbWF5 IGJlIHRoYXQgYWRkaXRpb25hbCBYcGF0aCBleHByZXNzaW9ucyBjYW4gYmUNCj4gdW5sb2NrZWQg YnkgZmVhdHVyZSBzdGF0ZW1lbnRzKS4NCg0KSSB0aGluayBlKSBpcyB3YXkgbW9yZSBpbXBvcnRh bnQgdGhhbiBjKS4gIEkgc3VnZ2VzdCBmb2N1cyBvbiBhICsgYiArDQpjLg0KDQo+ID4gV2UgY291 bGQgZGVmaW5lIGEgZmV3IG1vcmUgWFBhdGggZnVuY3Rpb25zIGZvciBzdWNoIGNvbXBhcmlzb25z Lg0KPiANCj4gU3VyZSwgYnV0IEkgd29uZGVyIGlmLCBlLmcuLCBhIG5ldG1hc2sgZmlsdGVyLCBp cyBzdXBwb3J0YWJsZSBieQ0KPiBjb21tb24gREItYmFja2VuZHMuICBJ4oCZbSBob3Bpbmcgd2Ug aGF2ZSBzb21lIERCLWV4cGVydHMgb24gdGhlIGxpc3QhDQoNClNlZSBhYm92ZS4gIEl0IGNhbiBi ZSBxdWl0ZSBlZmZpY2llbnQgZXZlbiBpZiB0aGUgYmFja2VuZCBkb2Vzbid0DQpzdXBwb3J0IGl0 Lg0KDQoNCi9tYXJ0aW4NCg== From nobody Wed Sep 30 01:39:28 2020 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 796E13A12FD for ; Wed, 30 Sep 2020 01:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euHfiyfn1jiL for ; Wed, 30 Sep 2020 01:39:23 -0700 (PDT) Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 706A43A12FA for ; Wed, 30 Sep 2020 01:39:23 -0700 (PDT) Received: from nitebug.nitenet.local (46.229.239.158.host.vnet.sk [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id C57C8246E16; Wed, 30 Sep 2020 10:39:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1601455160; bh=eTG6lV3Y0dfdLFrDYcA2c5xvLv1YFFUsYVLqGC5i8yI=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=ImtVcSIuDbYnToie4sVDGWSjewqqtrF3mhxlOlrJPgez6CP7Nldp3owZehDVuwIgg HyhWr8hKdyuFvoXCh3GWGW/2tT+Ft4tRis0wg/4C5Smtbr5/tsAw0bFBLH2uktNxTL WtLVcplTsMyWvUVbU9FsvIVSl2x1dBfcEY9tJsNw= To: Qin Wu , Kent Watsen , Andy Bierman Cc: "netconf@ietf.org" References: From: Robert Varga Message-ID: <441d95cc-fe41-6d63-849f-a1d30c86859d@hq.sk> Date: Wed, 30 Sep 2020 10:39:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gufZKMcNdbaAnDCaK5N1RhOm59YHcs2SH" Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 08:39:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gufZKMcNdbaAnDCaK5N1RhOm59YHcs2SH Content-Type: multipart/mixed; boundary="VO3d8IU2jp9VJTJUVxu0VfCOQzJ3m7NHA" --VO3d8IU2jp9VJTJUVxu0VfCOQzJ3m7NHA Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 30/09/2020 03:11, Qin Wu wrote: > Hi, Robert: Hellow Qin, > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: netconf [mailto:netconf-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Robert Varga > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B49=E6=9C=8830=E6=97=A5= 7:05 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Kent Watsen ; Andy B= ierman > =E6=8A=84=E9=80=81: netconf@ietf.org > =E4=B8=BB=E9=A2=98: Re: [netconf] restconf collections >=20 > On 26/09/2020 20:57, Kent Watsen wrote: >>> There are 3 completely different approaches: >>> >>> =C2=A0 1) stateless >>> =C2=A0 2) stateful >>> =C2=A0 3) stateful snapshot >>> >>> How to efficiently iterate through data that is changing constantly? >>> This problem is harder than it looks. >> >> Agreed. =C2=A0I recommend we NOT try to solve that problem. >=20 > Unfortunately you do need to pick an interaction model to tie together = the first and second pagination requests. At the very least you need to s= pecify consistency guarantees between the two -- which gives them worms j= uuust enough room to wiggle out of the can. >=20 > [Qin]:I think when the client Using page request to get access to the e= lement in the list, he only need to remember the position of last element= in the first pagination request and set the number of element he want to= request in the pagination requests, > The server doesn't need to keep any additional states, the server only = need to support list operation. That is assuming the list in question has iteration order which is stable. I do not believe this is something RFC7950 mandates on anything except ordered-by=3Duser. > A fair answer is 'well, they are not tied together and if the datastore= moves, you are SOL' ... but then how do you make forward progress with e= nough consistency to be useful in the real world? :) >=20 >=20 > [Qin]: I think it doesn't matter whether the list will grow and add new= elements, we could still use last element position and count of elements= in the list that need to be queried to retrieve additional elements we w= ant. So let's say the list has 4 elements A, B, C, D. 1) The first request returns items A, B, C. 2) An item is inserted before C, so that the list is E, A, B, C, D. 3) What does the second request return? Similarly: 1) The first request returns items A, B, C. 2) An item is deleted before C, so that the list is B, C, D. 3) What does the second request return? Pagination is deceptively hard. Regards, Robert --VO3d8IU2jp9VJTJUVxu0VfCOQzJ3m7NHA-- --gufZKMcNdbaAnDCaK5N1RhOm59YHcs2SH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQI/BAEBCgApFiEEdj+N7pgGP1gKvbdQJKB0S2uuNdsFAl90RDMLHG5pdGVAaHEu c2sACgkQJKB0S2uuNduYnA/+JvZTcJYDKm8l6RvP6nr5vnURezAsJw7cYeHY6Gad s1gYuJj3uvJ3o1BPlbhDMLI9zGBsqMhiUiR4a/1TOKXhiEFki2UknwNzQlhlc1Nu Y/08QP5Wm2TsVlHBh/+28xqzxFlkc0KKv3O7z2RhHNI/RJooxs5xS9aAiCrNGAE9 v7OH9/BZsJ3ZM1ZvbW5gGp9zzWXVTIgs+SoBtBfI6vk+lV/YKHgtzWJvpF9gTDGz bX6EKwQgtw3QgY6WghJgKAknIoc6UDWUvuDbs95Q+4wCCUbtDZ81JF4PN2Mk4ujI RxTL6B6n3mLOvtn3kjXMCKNYqT71OTvChXDi9KCetoK/NmuKIEXluHhneYD0tWnA sz2anPMUC1oXI9MlcK6ZVyCzvKG6l/HSa95Mx6K341tciUt52kaNnv9trxY3622b pLg6F7TtcY8ZnzS74R2z9NYxRkkV13/uz38PHM3z/D5hVDTIRZqisbZu59TVKQjD tM+h9SzWp4AljGk6XlJEPU0QtH/tx9PW7RtOarmheOC64tNMMnV8uiOuHvyHEi6b s30gKTpbNx72qPz3i8oTJn63UeO+EgSz3iZQC7Nvah92hMCzM0NHUD+CAi0R1FZt gm1JCBXUOgAI6zS+8h8Wk3LeOcjPadouGhX117BvtkHrKHlPilT2+ww5/xztpFNJ F70= =yEnA -----END PGP SIGNATURE----- --gufZKMcNdbaAnDCaK5N1RhOm59YHcs2SH-- From nobody Wed Sep 30 03:33:38 2020 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 2B3F63A0AA6 for ; Wed, 30 Sep 2020 03:33:37 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 qe5JWKXwGHXb for ; Wed, 30 Sep 2020 03:33:35 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 6CD2E3A0AA0 for ; Wed, 30 Sep 2020 03:33:35 -0700 (PDT) Received: from lhreml747-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 2932161A44F0826BFA61 for ; Wed, 30 Sep 2020 11:33:34 +0100 (IST) Received: from lhreml747-chm.china.huawei.com (10.201.108.197) by lhreml747-chm.china.huawei.com (10.201.108.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 30 Sep 2020 11:33:34 +0100 Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml747-chm.china.huawei.com (10.201.108.197) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Wed, 30 Sep 2020 11:33:33 +0100 Received: from DGGEML531-MBS.china.huawei.com ([169.254.5.245]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0487.000; Wed, 30 Sep 2020 18:33:27 +0800 From: Qin Wu To: Robert Varga , Kent Watsen , "Andy Bierman" CC: "netconf@ietf.org" Thread-Topic: [netconf] restconf collections Thread-Index: AdaXFCv070wS8R0MTlOTHGsG6zVmmA== Date: Wed, 30 Sep 2020 10:33:27 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.101.103] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 10:33:37 -0000 LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBSb2JlcnQgVmFyZ2EgW21haWx0bzpu aXRlQGhxLnNrXSANCuWPkemAgeaXtumXtDogMjAyMOW5tDnmnIgzMOaXpSAxNjozOQ0K5pS25Lu2 5Lq6OiBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT47IEtlbnQgV2F0c2VuIDxrZW50K2lldGZA d2F0c2VuLm5ldD47IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPg0K5oqE6YCBOiBu ZXRjb25mQGlldGYub3JnDQrkuLvpopg6IFJlOiBbbmV0Y29uZl0gcmVzdGNvbmYgY29sbGVjdGlv bnMNCg0KT24gMzAvMDkvMjAyMCAwMzoxMSwgUWluIFd1IHdyb3RlOg0KPiBIaSwgUm9iZXJ0Og0K DQpIZWxsb3cgUWluLA0KDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBu ZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSDku6PooaggUm9iZXJ0IFZh cmdhDQo+IOWPkemAgeaXtumXtDogMjAyMOW5tDnmnIgzMOaXpSA3OjA1DQo+IOaUtuS7tuS6ujog S2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0PjsgQW5keSBCaWVybWFuIA0KPiA8YW5k eUB5dW1hd29ya3MuY29tPg0KPiDmioTpgIE6IG5ldGNvbmZAaWV0Zi5vcmcNCj4g5Li76aKYOiBS ZTogW25ldGNvbmZdIHJlc3Rjb25mIGNvbGxlY3Rpb25zDQo+IA0KPiBPbiAyNi8wOS8yMDIwIDIw OjU3LCBLZW50IFdhdHNlbiB3cm90ZToNCj4+PiBUaGVyZSBhcmUgMyBjb21wbGV0ZWx5IGRpZmZl cmVudCBhcHByb2FjaGVzOg0KPj4+DQo+Pj4gwqAgMSkgc3RhdGVsZXNzDQo+Pj4gwqAgMikgc3Rh dGVmdWwNCj4+PiDCoCAzKSBzdGF0ZWZ1bCBzbmFwc2hvdA0KPj4+DQo+Pj4gSG93IHRvIGVmZmlj aWVudGx5IGl0ZXJhdGUgdGhyb3VnaCBkYXRhIHRoYXQgaXMgY2hhbmdpbmcgY29uc3RhbnRseT8N Cj4+PiBUaGlzIHByb2JsZW0gaXMgaGFyZGVyIHRoYW4gaXQgbG9va3MuDQo+Pg0KPj4gQWdyZWVk LiDCoEkgcmVjb21tZW5kIHdlIE5PVCB0cnkgdG8gc29sdmUgdGhhdCBwcm9ibGVtLg0KPiANCj4g VW5mb3J0dW5hdGVseSB5b3UgZG8gbmVlZCB0byBwaWNrIGFuIGludGVyYWN0aW9uIG1vZGVsIHRv IHRpZSB0b2dldGhlciB0aGUgZmlyc3QgYW5kIHNlY29uZCBwYWdpbmF0aW9uIHJlcXVlc3RzLiBB dCB0aGUgdmVyeSBsZWFzdCB5b3UgbmVlZCB0byBzcGVjaWZ5IGNvbnNpc3RlbmN5IGd1YXJhbnRl ZXMgYmV0d2VlbiB0aGUgdHdvIC0tIHdoaWNoIGdpdmVzIHRoZW0gd29ybXMganV1dXN0IGVub3Vn aCByb29tIHRvIHdpZ2dsZSBvdXQgb2YgdGhlIGNhbi4NCj4gDQo+IFtRaW5dOkkgdGhpbmsgd2hl biB0aGUgY2xpZW50IFVzaW5nIHBhZ2UgcmVxdWVzdCB0byBnZXQgYWNjZXNzIHRvIHRoZSANCj4g ZWxlbWVudCBpbiB0aGUgbGlzdCwgaGUgb25seSBuZWVkIHRvIHJlbWVtYmVyIHRoZSBwb3NpdGlv biBvZiBsYXN0IGVsZW1lbnQgaW4gdGhlIGZpcnN0IHBhZ2luYXRpb24gcmVxdWVzdCBhbmQgc2V0 IHRoZSBudW1iZXIgb2YgZWxlbWVudCBoZSB3YW50IHRvIHJlcXVlc3QgaW4gdGhlIHBhZ2luYXRp b24gcmVxdWVzdHMsIFRoZSBzZXJ2ZXIgZG9lc24ndCBuZWVkIHRvIGtlZXAgYW55IGFkZGl0aW9u YWwgc3RhdGVzLCB0aGUgc2VydmVyIG9ubHkgbmVlZCB0byBzdXBwb3J0IGxpc3Qgb3BlcmF0aW9u Lg0KDQpUaGF0IGlzIGFzc3VtaW5nIHRoZSBsaXN0IGluIHF1ZXN0aW9uIGhhcyBpdGVyYXRpb24g b3JkZXIgd2hpY2ggaXMgc3RhYmxlLiBJIGRvIG5vdCBiZWxpZXZlIHRoaXMgaXMgc29tZXRoaW5n IFJGQzc5NTAgbWFuZGF0ZXMgb24gYW55dGhpbmcgZXhjZXB0IG9yZGVyZWQtYnk9dXNlci4NCg0K PiBBIGZhaXIgYW5zd2VyIGlzICd3ZWxsLCB0aGV5IGFyZSBub3QgdGllZCB0b2dldGhlciBhbmQg aWYgdGhlIA0KPiBkYXRhc3RvcmUgbW92ZXMsIHlvdSBhcmUgU09MJyAuLi4gYnV0IHRoZW4gaG93 IGRvIHlvdSBtYWtlIGZvcndhcmQgDQo+IHByb2dyZXNzIHdpdGggZW5vdWdoIGNvbnNpc3RlbmN5 IHRvIGJlIHVzZWZ1bCBpbiB0aGUgcmVhbCB3b3JsZD8gOikNCj4gDQo+IA0KPiBbUWluXTogSSB0 aGluayBpdCBkb2Vzbid0IG1hdHRlciB3aGV0aGVyIHRoZSBsaXN0IHdpbGwgZ3JvdyBhbmQgYWRk IG5ldyBlbGVtZW50cywgd2UgY291bGQgc3RpbGwgdXNlIGxhc3QgZWxlbWVudCBwb3NpdGlvbiBh bmQgY291bnQgb2YgZWxlbWVudHMgaW4gdGhlIGxpc3QgdGhhdCBuZWVkIHRvIGJlIHF1ZXJpZWQg dG8gcmV0cmlldmUgYWRkaXRpb25hbCBlbGVtZW50cyB3ZSB3YW50Lg0KDQpTbyBsZXQncyBzYXkg dGhlIGxpc3QgaGFzIDQgZWxlbWVudHMgQSwgQiwgQywgRC4NCg0KMSkgVGhlIGZpcnN0IHJlcXVl c3QgcmV0dXJucyBpdGVtcyBBLCBCLCBDLg0KMikgQW4gaXRlbSBpcyBpbnNlcnRlZCBiZWZvcmUg Qywgc28gdGhhdCB0aGUgbGlzdCBpcyBFLCBBLCBCLCBDLCBELg0KMykgV2hhdCBkb2VzIHRoZSBz ZWNvbmQgcmVxdWVzdCByZXR1cm4/DQpTaW1pbGFybHk6DQoNCjEpIFRoZSBmaXJzdCByZXF1ZXN0 IHJldHVybnMgaXRlbXMgQSwgQiwgQy4NCjIpIEFuIGl0ZW0gaXMgZGVsZXRlZCBiZWZvcmUgQywg c28gdGhhdCB0aGUgbGlzdCBpcyBCLCBDLCBELg0KMykgV2hhdCBkb2VzIHRoZSBzZWNvbmQgcmVx dWVzdCByZXR1cm4/DQoNClBhZ2luYXRpb24gaXMgZGVjZXB0aXZlbHkgaGFyZC4NCltRaW5dOiBt YXliZSB1c2luZyBwb3NpdGlvbiBvZiB0aGUgbGFzdCBlbGVtZW50IGlzIG5vdCBhY2N1cmF0ZSwg dGhlIGNsaWVudCBvbmx5IG5lZWRzIHRvIHJlbWVtYmVyIHRoZSBsYXN0IGVsZW1lbnQgaGUgcmVx dWVzdCBpbiB0aGUgZmlyc3QgcGFnaW5hdGlvbiByZXF1ZXN0LCBhbmQgdXNlIHRoZSBsYXN0IGVs ZW1lbnQgYXMgY3Vyc29yIHJlZmVyZW5jZSBwb2ludCBhbmQgc2V0IGNvdW50IG9mIGVsZW1lbnRz IGhlIHdhbnQgaW4gdGhlIHNlY29uZCBwYWdpbmF0aW9uIHJlcXVlc3QsIHNvIGluIGJvdGggY2Fz ZXMsIHRoZSBzZWNvbmQgcmVxdWVzdCB3aWxsIHJldHVybiBELg0KQnV0IGlmIEMgaXMgZGVsZXRl ZCBpbiB0aGUgZXh0cmVtZSBjYXNlLCBJIHRoaW5rIHRoZSBzZXJ2ZXIgc2hvdWxkIHJldHVybiBl cnJvciB0byBpbmRpY2F0ZSB0aGUgQyBlbGVtZW50IGFzIGxhc3QgZWxlbWVudCBkb2Vzbid0IGV4 aXN0Lg0KDQpSZWdhcmRzLA0KUm9iZXJ0DQoNCg== From nobody Wed Sep 30 10:33:45 2020 Return-Path: <01000174e013b1f6-fd0b45d1-951d-41dd-85d8-39685a52e998-000000@amazonses.watsen.net> 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 35FA13A0A43 for ; Wed, 30 Sep 2020 10:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 d3nMrUCfJ2xc for ; Wed, 30 Sep 2020 10:33:42 -0700 (PDT) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC123A0A38 for ; Wed, 30 Sep 2020 10:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1601487221; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=2aFUEDmitDAKsEhHdr8MYKD40A5mYHNPl8UedOY3fI4=; b=bm2jXiKygf6dRGxN8tXxvTr6BjZ0xMaxr/X6P9CE5X3FH769Ancf2k9e/9TSzI7O qvtfyo4AKteUkHhMW0g9Mmm7FcvjZegx/s+cnbNRRBIcEk6dSB7y5z8L0pLC9iqfD/I NIAT5wpbvwO/r1j0mNhF/rtMaL2/rzehuM++XlOY= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Kent Watsen In-Reply-To: <441d95cc-fe41-6d63-849f-a1d30c86859d@hq.sk> Date: Wed, 30 Sep 2020 17:33:41 +0000 Cc: Qin Wu , Andy Bierman , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000174e013b1f6-fd0b45d1-951d-41dd-85d8-39685a52e998-000000@email.amazonses.com> References: <441d95cc-fe41-6d63-849f-a1d30c86859d@hq.sk> To: Robert Varga X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.09.30-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 17:33:44 -0000 Hi Robert, > That is assuming the list in question has iteration order which is > stable. I do not believe this is something RFC7950 mandates on = anything > except ordered-by=3Duser. If not =E2=80=9Cordered-by user=E2=80=9D, then its =E2=80=9Cordered-by = system=E2=80=9D that, as RFC 7950 says, "the server is free to sort the = list entries in any reasonable order.=E2=80=9D This is a stable = ordering, IMO. > So let's say the list has 4 elements A, B, C, D. >=20 > 1) The first request returns items A, B, C. > 2) An item is inserted before C, so that the list is E, A, B, C, D. > 3) What does the second request return? >=20 > Similarly: >=20 > 1) The first request returns items A, B, C. > 2) An item is deleted before C, so that the list is B, C, D. > 3) What does the second request return? >=20 > Pagination is deceptively hard. Is your conjecture that the solution should enable something akin to = cursors? Would this be an advanced feature that a server might support = on a list-by-list basis? Maybe "node-tags=E2=80=9D could be useful = here too=E2=80=A6 K. From nobody Wed Sep 30 10:55:27 2020 Return-Path: <01000174e0279006-63781c55-866c-4ea0-add6-a6fa8a11453c-000000@amazonses.watsen.net> 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 E19143A0A62 for ; Wed, 30 Sep 2020 10:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 Z15pH5sjGmCw for ; Wed, 30 Sep 2020 10:55:24 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C4AF3A0A5E for ; Wed, 30 Sep 2020 10:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1601488523; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=Jua7FRCviz+79ZCFL2K7egePMO8wrukDsI9uK5VI33g=; b=QA0GXm/NSMjtKBEg4Nm+fB4TzD9LKBiP96EVP00OZmJBFj6SqfWyW5KJabjumc+M L01I98Gr8cZIXM9JEswG21MtwFwYLxIprzjZqMSS7B6w/qMTnowmwHJznY7pXHdFmr8 Zc/QeB99mTNkWyAwBkf8885t3edIP+v8rWPYC8A0= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Kent Watsen In-Reply-To: <20200930.084312.246821928590534256.id@4668.se> Date: Wed, 30 Sep 2020 17:55:23 +0000 Cc: "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000174e0279006-63781c55-866c-4ea0-add6-a6fa8a11453c-000000@email.amazonses.com> References: <01000174daf6ded3-0ba5564d-f1c7-4c65-90dc-d8a22f2f9395-000000@email.amazonses.com> <20200929.205710.165167541047857442.id@4668.se> <01000174dbde18ac-c9293572-775f-4c8e-b8c1-a8522bd636b5-000000@email.amazonses.com> <20200930.084312.246821928590534256.id@4668.se> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.09.30-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 17:55:26 -0000 > If we agree to not do d) then we don't need any use cases for it ;-) We don=E2=80=99t agree that sorting isn=E2=80=99t ever need, but I think = that it=E2=80=99s fair to say that, amongst the various other = parameters, it=E2=80=99s the least important, and so enabling it via a = feature seems prudent. BTW, sort (d) comes after filter (e), in our e-->a processing model. = Hopefully the (fast) filter whittles the result-set down to something = manageable so the (slow) sort isn=E2=80=99t painfully too egregious. > Anyway, if you want to sort on different fields you probably want to > do this regardless of how the list is orderd on the server. Possibly, and certainly it would be easy to implement, I=E2=80=99m just = trying to understand when that might be the case. For instance, using a = firewall rulebase (an OBU-list) as an example, when could getting the = rules in any other order be meaningful to a client? >> Regarding =E2=80=9CI don=E2=80=99t think they should be restricted to = =E2=80=98indexable=E2=80=99 >> columns=E2=80=9D, >=20 > My comment was for both d) and e) (sort and filter). As for filter, > an example is to get interfaces and with oper-status =3D=3D 'down'. =E2=80=9Coper-status=E2=80=9D appears to be an enum, an hence = indexable=E2=80=A6or perhaps this is a forward-reference to your next = comment about some opstate not being in the DB... >> Yes, XPath is the =E2=80=9Cright answer=E2=80=9D, but we need to = ensure it=E2=80=99s >> constrained enough to be mappable to common DB-backends. >=20 > So the client talks to the server, and the server talks to the "db" > backend (note that in many implementations operational state is > typically not stored in a real database). =20 Some opstate must be persisted, e.g., long-lived counters, logs, etc., = but it=E2=80=99s a good point about other opstate not being persisted. = Perhaps =E2=80=9Cnode-tags=E2=80=9D can be used here, to differentiate = which is which=E2=80=A6and servers can indicate if/how they support the = ephemeral opstate leafs in queries? > So we have: >=20 > client -> server -> backend >=20 > If we don't have any filter capabilities, the client has to get > everything, and then filter. If we support XPath and the backend > doesn't support it, the server will have to filter. This is still > more efficient than filtering in the client. Probably, especially when assuming the server has better resources = and/or the client <--> server bandwidth is constrained. > In ConfD/NSO we moved more and more filtering logic towards the > backend, to speed up performance. Ack. > I think e) is way more important than c). I suggest focus on a + b + > c. Noted, but I think you meant a + b + e. Note sure how others feel about =E2=80=9Cdirection: (c), but my primary = use-case revolves around time-series data (e.g., logs), where the = interest is commonly on the most-recent entries, so = "reverse-->offset=E2=80=94>limit=E2=80=9D works nicely. =20 Perhaps an alternative would be to lift a concept from Python with = negative indexes so, for instance, offset=3D-N and limit=3D-N gives the = last N entries? >> Sure, but I wonder if, e.g., a netmask filter, is supportable by >> common DB-backends. I=E2=80=99m hoping we have some DB-experts on = the list! >=20 > See above. It can be quite efficient even if the backend doesn't > support it. I don=E2=80=99t see that above, but I don=E2=80=99t doubt that it can be = so, it=E2=80=99s just a whole lot of implementation complexity. It = seems that we should/must support servers doing it, we just need to find = a way (node-tags?) to enable them to express that ability. K. From nobody Wed Sep 30 12:00:08 2020 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 BB34C3A0AF6 for ; Wed, 30 Sep 2020 12:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 S3--Td-bTN_I for ; Wed, 30 Sep 2020 12:00:01 -0700 (PDT) Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [93.188.3.37]) (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 3E5C83A0AC5 for ; Wed, 30 Sep 2020 12:00:00 -0700 (PDT) Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id F34012F678EA for ; Wed, 30 Sep 2020 20:59:54 +0200 (CEST) Received: from s500.loopia.se (unknown [172.22.191.6]) by s807.loopia.se (Postfix) with ESMTP id D4EC32E292AC; Wed, 30 Sep 2020 20:59:54 +0200 (CEST) Received: from s474.loopia.se (unknown [172.22.191.6]) by s500.loopia.se (Postfix) with ESMTP id CF3A51E32B64; Wed, 30 Sep 2020 20:59:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s500.loopia.se ([172.22.191.5]) by s474.loopia.se (s474.loopia.se [172.22.190.14]) (amavisd-new, port 10024) with LMTP id FZu_yGj35jb3; Wed, 30 Sep 2020 20:59:54 +0200 (CEST) X-Loopia-Auth: user X-Loopia-User: olof@hagsand.se X-Loopia-Originating-IP: 78.82.254.64 Received: from [10.0.0.14] (c-40fe524e.712-1-64736c13.bbcust.telenor.se [78.82.254.64]) (Authenticated sender: olof@hagsand.se) by s500.loopia.se (Postfix) with ESMTPSA id 1DE3E1E32B2D; Wed, 30 Sep 2020 20:59:54 +0200 (CEST) To: Kent Watsen Cc: "netconf@ietf.org" References: <01000174daf6ded3-0ba5564d-f1c7-4c65-90dc-d8a22f2f9395-000000@email.amazonses.com> <20200929.205710.165167541047857442.id@4668.se> <01000174dbde18ac-c9293572-775f-4c8e-b8c1-a8522bd636b5-000000@email.amazonses.com> <20200930.084312.246821928590534256.id@4668.se> <01000174e0279006-63781c55-866c-4ea0-add6-a6fa8a11453c-000000@email.amazonses.com> From: Olof Hagsand Message-ID: <54cd8891-6c04-3ded-22ca-43a68ac8397f@hagsand.se> Date: Wed, 30 Sep 2020 20:59:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <01000174e0279006-63781c55-866c-4ea0-add6-a6fa8a11453c-000000@email.amazonses.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 19:00:07 -0000 On 2020-09-30 19:55, Kent Watsen wrote: > >> If we agree to not do d) then we don't need any use cases for it ;-) > > We don’t agree that sorting isn’t ever need, but I think that it’s fair to say that, amongst the various other parameters, it’s the least important, and so enabling it via a feature seems prudent. > > BTW, sort (d) comes after filter (e), in our e-->a processing model. Hopefully the (fast) filter whittles the result-set down to something manageable so the (slow) sort isn’t painfully too egregious. I agree sorting is less important (than a,b,e). Is it not also somewhat beyond the present yang concepts where there is already ordered-by and key indices? Supplying a differing sorting could in effect require a different set of index(es) which could be quite costly in runtime for large data sets. If you want to sort differently, should it not be present in the underlying model, ie as declaring a secondary set of keys, for example, as an extension of the original yang model (thus being out of scope here)? > >> Anyway, if you want to sort on different fields you probably want to >> do this regardless of how the list is orderd on the server. > > Possibly, and certainly it would be easy to implement, I’m just trying to understand when that might be the case. For instance, using a firewall rulebase (an OBU-list) as an example, when could getting the rules in any other order be meaningful to a client? > > >>> Regarding “I don’t think they should be restricted to ‘indexable’ >>> columns”, >> >> My comment was for both d) and e) (sort and filter). As for filter, >> an example is to get interfaces and with oper-status == 'down'. > > “oper-status” appears to be an enum, an hence indexable…or perhaps this is a forward-reference to your next comment about some opstate not being in the DB... > > >>> Yes, XPath is the “right answer”, but we need to ensure it’s >>> constrained enough to be mappable to common DB-backends. I would think a (strongly) constrained XPath would be a very nice solution. >> >> So the client talks to the server, and the server talks to the "db" >> backend (note that in many implementations operational state is >> typically not stored in a real database). > > Some opstate must be persisted, e.g., long-lived counters, logs, etc., but it’s a good point about other opstate not being persisted. Perhaps “node-tags” can be used here, to differentiate which is which…and servers can indicate if/how they support the ephemeral opstate leafs in queries? > > >> So we have: >> >> client -> server -> backend >> >> If we don't have any filter capabilities, the client has to get >> everything, and then filter. If we support XPath and the backend >> doesn't support it, the server will have to filter. This is still >> more efficient than filtering in the client. > > Probably, especially when assuming the server has better resources and/or the client <--> server bandwidth is constrained. > > >> In ConfD/NSO we moved more and more filtering logic towards the >> backend, to speed up performance. > > Ack. > > >> I think e) is way more important than c). I suggest focus on a + b + >> c. > > Noted, but I think you meant a + b + e. > > Note sure how others feel about “direction: (c), but my primary use-case revolves around time-series data (e.g., logs), where the interest is commonly on the most-recent entries, so "reverse-->offset—>limit” works nicely. > > Perhaps an alternative would be to lift a concept from Python with negative indexes so, for instance, offset=-N and limit=-N gives the last N entries? > To me reverse direction seems a subset of ordering/sorting? If sorting is less important, so would an alternate direction? Unless there are some important use-cases, reverse order having the advantage of the same sorting mechanism/indexes, just in reverse (not introducing other keys, for example) > >>> Sure, but I wonder if, e.g., a netmask filter, is supportable by >>> common DB-backends. I’m hoping we have some DB-experts on the list! >> >> See above. It can be quite efficient even if the backend doesn't >> support it. > > I don’t see that above, but I don’t doubt that it can be so, it’s just a whole lot of implementation complexity. It seems that we should/must support servers doing it, we just need to find a way (node-tags?) to enable them to express that ability. > > > K. > > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Wed Sep 30 13:00:29 2020 Return-Path: <01000174e09a04a9-f53134f8-009f-4d0a-84a1-3165a494054b-000000@amazonses.watsen.net> 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 780FC3A0B60 for ; Wed, 30 Sep 2020 13:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 G_B8p5hZuwNp for ; Wed, 30 Sep 2020 13:00:25 -0700 (PDT) Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 842123A0B5B for ; Wed, 30 Sep 2020 13:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1601496024; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=5+Eos4eAgb+t74MHJEAVUD8dy4Oz9Ah+fueYmGqUgr4=; b=N328ZJ7RL/SHXgY9kvO2fKFafDzvO5ibeD7G7PEWIEq3ZAR7nPyE1a2NexTryhco LraYcovpKPBEz1w7O0kegUJMdH5/QAK7u14nFqmfzCbioMVdyCoAwrvAVi4txFghFwt S94pJrLmf+Cz3RtyH0GIX6QhqIJsQxVTX5PXaNWg= From: Kent Watsen Message-ID: <01000174e09a04a9-f53134f8-009f-4d0a-84a1-3165a494054b-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5903AA6C-4871-467D-AEBC-89074BDDB7FA" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 30 Sep 2020 20:00:24 +0000 In-Reply-To: <54cd8891-6c04-3ded-22ca-43a68ac8397f@hagsand.se> Cc: "netconf@ietf.org" To: Olof Hagsand References: <01000174daf6ded3-0ba5564d-f1c7-4c65-90dc-d8a22f2f9395-000000@email.amazonses.com> <20200929.205710.165167541047857442.id@4668.se> <01000174dbde18ac-c9293572-775f-4c8e-b8c1-a8522bd636b5-000000@email.amazonses.com> <20200930.084312.246821928590534256.id@4668.se> <01000174e0279006-63781c55-866c-4ea0-add6-a6fa8a11453c-000000@email.amazonses.com> <54cd8891-6c04-3ded-22ca-43a68ac8397f@hagsand.se> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.09.30-54.240.48.92 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 20:00:28 -0000 --Apple-Mail=_5903AA6C-4871-467D-AEBC-89074BDDB7FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Olaf, > I agree sorting is less important (than a,b,e). Noted. > Is it not also somewhat beyond the present yang concepts where there = is > already ordered-by and key indices? > Supplying a differing sorting could in effect require a different set = of > index(es) which could be quite costly in runtime for large data sets. > If you want to sort differently, should it not be present in the > underlying model, ie as declaring a secondary set of keys, for = example, > as an extension of the original yang model (thus being out of scope = here)? A couple messages I sent yesterday alluded to defining an extension = statement that could be added to nodes in the YANG modules. Now I=E2=80=99m thinking that one-size doesn=E2=80=99t necessarily fit = all, and something like a server-specific =E2=80=9Cnode-tag=E2=80=9D = would be more flexible. = (https://tools.ietf.org/html/draft-tao-netmod-yang-node-tags = ) Maybe the answer is somewhere in-between, i.e., an extension that acts = like a =E2=80=9Chint=E2=80=9D and a node-tag indicating if the server = delivered it. Bad news w/ an extension is that legacy modules would = need to be revved or augmented. One thing, though, filtering on non-indexed nodes is guaranteed to have = slow performance, thus it seems that we need to enable indexing for more = than just a list=E2=80=99s keys. My conjecture is that, once we have the indexes for filtering (e), they = can be used for sorting (d). At least, that=E2=80=99s the way it works = with some DB-backends I=E2=80=99m familiar with... >>>> Yes, XPath is the =E2=80=9Cright answer=E2=80=9D, but we need to = ensure it=E2=80=99s >>>> constrained enough to be mappable to common DB-backends. >=20 > I would think a (strongly) constrained XPath would be a very nice = solution. +1 > To me reverse direction seems a subset of ordering/sorting? Indeed. In some DB-backends, =E2=80=9Cdirection" is a sub-statement to = the =E2=80=9Csort=E2=80=9D statement. > If sorting is less important, so would an alternate direction? Maybe, but an independent =E2=80=9Cdirection" works with OBU-lists, = which is why I teased it out. And, besides, that assumes sorting is less important. I do hear a = consensus beginning to form in that direction, so we=E2=80=99ll see... All I know is that there are tons of UIs that enable column sorting = (e.g., an email client). Do we feel data models defined by YANG are = somehow immune to this? =20 I hear folks expressing concern around sorting big data (e.g., logs), = which I grok, but what about for non-OBU CT lists (e.g., admins)? = Wouldn=E2=80=99t we like to sort by name, last-time-connected, etc.? = Can not supporting sorting on big data set be expressed via some = combination of extension + node-tag, or implicitly disabled if the = pre-filter fails to whittle the result set down to something that can be = sorted reasonably? > Unless there are some important use-cases, reverse order having the > advantage of the same sorting mechanism/indexes, just in reverse (not > introducing other keys, for example) Sorry, I didn=E2=80=99t parse that. Can you say another way? K. --Apple-Mail=_5903AA6C-4871-467D-AEBC-89074BDDB7FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Olaf,

I agree sorting is less important (than a,b,e).

Noted.


Is it not also somewhat beyond = the present yang concepts where there is
already ordered-by and key indices?
Supplying a differing sorting = could in effect require a different set of
index(es) which could be quite costly in runtime for large = data sets.
If you want = to sort differently, should it not be present in the
underlying model, ie as = declaring a secondary set of keys, for example,
as an extension of the original = yang model (thus being out of scope here)?

A couple messages I sent yesterday alluded to = defining an extension statement that could be added to nodes in the YANG = modules.


Maybe the answer is somewhere = in-between, i.e., an extension that acts like a =E2=80=9Chint=E2=80=9D = and a node-tag indicating if the server delivered it.  Bad news w/ = an extension is that legacy modules would need to be revved or = augmented.

One thing, though, = filtering on non-indexed nodes is guaranteed to have slow performance, = thus it seems that we need to enable indexing for more than just a = list=E2=80=99s keys.

My conjecture = is that, once we have the indexes for filtering (e), they can be used = for sorting (d).  At least, that=E2=80=99s the way it works with = some DB-backends I=E2=80=99m familiar with...


Yes, XPath is the =E2=80=9Cright answer=E2=80=9D, but we need = to ensure it=E2=80=99s
constrained enough to be mappable = to common DB-backends.

I would think a (strongly) = constrained XPath would be a very nice solution.

+1


To me reverse direction seems a subset of ordering/sorting? =

Indeed. =  In some DB-backends, =E2=80=9Cdirection" is a sub-statement to the = =E2=80=9Csort=E2=80=9D statement.


If sorting is less important, so would an = alternate direction?

Maybe, but an independent =E2=80=9Cdirection" = works with OBU-lists, which is why I teased it out.

And, besides, that assumes sorting is less = important.  I do hear a consensus beginning to form in that = direction, so we=E2=80=99ll see...

All= I know is that there are tons of UIs that enable column sorting (e.g., = an email client).  Do we feel data models defined by YANG = are somehow immune to this? =   

I hear folks expressing = concern around sorting big data (e.g., logs), which I grok, but what = about for non-OBU CT lists (e.g., admins)?  Wouldn=E2=80=99t we = like to sort by name, last-time-connected, etc.?  Can not = supporting sorting on big data set be expressed via some combination of = extension + node-tag, or implicitly disabled if the pre-filter fails to = whittle the result set down to something that can be sorted = reasonably?


Unless there = are some important use-cases, reverse order having the
advantage of the same sorting = mechanism/indexes, just in reverse (not
introducing other keys, for example)

Sorry, I = didn=E2=80=99t parse that.  Can you say another way?


K.

= --Apple-Mail=_5903AA6C-4871-467D-AEBC-89074BDDB7FA-- From nobody Wed Sep 30 13:04:19 2020 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 A968B3A0B65 for ; Wed, 30 Sep 2020 13:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEgdED3YcFIl for ; Wed, 30 Sep 2020 13:04:15 -0700 (PDT) Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E617C3A0D5F for ; Wed, 30 Sep 2020 13:04:06 -0700 (PDT) Received: from nitebug.nitenet.local (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id 6753E246E17; Wed, 30 Sep 2020 22:04:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1601496244; bh=JHUwDhitF8xmC5cORV5cwlQ1WinPncQxv+gFXGHrMaQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=GZwriBHj4HWWvgtxN5a+IijJs4jX6Q2AJ17a5na5V4+YFeQ9r7ueAYBcuIoVXeGMV QVhkRa6Zn9CGs1Hpgd+PEl+0wyFOGDkiu5yNqPONcLTBKhwLb0Zie/nQEVGcXoFAK8 tuL2zQnhf1EtRxj3Vt3/umoeAryC/dh5lpqgJbng= To: Kent Watsen Cc: Qin Wu , Andy Bierman , "netconf@ietf.org" References: <441d95cc-fe41-6d63-849f-a1d30c86859d@hq.sk> <01000174e013b1f6-fd0b45d1-951d-41dd-85d8-39685a52e998-000000@email.amazonses.com> From: Robert Varga Message-ID: Date: Wed, 30 Sep 2020 22:03:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <01000174e013b1f6-fd0b45d1-951d-41dd-85d8-39685a52e998-000000@email.amazonses.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="c2H4R5A6Y1zZM2I6HekiCDvSj2RD5TbHT" Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 20:04:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --c2H4R5A6Y1zZM2I6HekiCDvSj2RD5TbHT Content-Type: multipart/mixed; boundary="OMTTRWaeARTjdUastqM3czz7D7f4Ts8xK" --OMTTRWaeARTjdUastqM3czz7D7f4Ts8xK Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 30/09/2020 19:33, Kent Watsen wrote: > Hi Robert, >=20 >> That is assuming the list in question has iteration order which is >> stable. I do not believe this is something RFC7950 mandates on anythin= g >> except ordered-by=3Duser. >=20 > If not =E2=80=9Cordered-by user=E2=80=9D, then its =E2=80=9Cordered-by = system=E2=80=9D that, as RFC 7950 says, "the server is free to sort the l= ist entries in any reasonable order.=E2=80=9D This is a stable ordering,= IMO. It's been quite some time since I did lawyer-reading the RFCs, but for the sake of argument: - is use of hash maps for keyed lists okay, hence the sort order is the encounter order based on the contents? - if so, does that order remain the same even across server restarts? I am not sure what the litmus test for 'reasonable' would look like, I am afraid. >> So let's say the list has 4 elements A, B, C, D. >> >> 1) The first request returns items A, B, C. >> 2) An item is inserted before C, so that the list is E, A, B, C, D. >> 3) What does the second request return? >> >> Similarly: >> >> 1) The first request returns items A, B, C. >> 2) An item is deleted before C, so that the list is B, C, D. >> 3) What does the second request return? >> >> Pagination is deceptively hard. >=20 > Is your conjecture that the solution should enable something akin to cu= rsors? Would this be an advanced feature that a server might support on = a list-by-list basis? Maybe "node-tags=E2=80=9D could be useful here to= o=E2=80=A6 If the requirement is to really just have an iterator, which breaks when the list changes, then a node-tag+offset would be sufficient. But then you could end up in a situation where you will never traverse the list simply because its rate of change exceeds your ability to traverse it. The path forks quite a bit if you want something more specific, like: "visit all elements in any order, i.e. additions do not break iteration".= If we have requirements towards that level of complexity, then yes, I would very much prefer if there was a cursor-like resource associated with an ongoing pagination request. If I squint just a little bit, the first paginated request is not that different for a (one-shot) subscription to receive notification of all list entries. Subsequent requests are fetches from that notification stream... which shows my reactive systems bias :) Regards, Robert --OMTTRWaeARTjdUastqM3czz7D7f4Ts8xK-- --c2H4R5A6Y1zZM2I6HekiCDvSj2RD5TbHT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQI/BAEBCgApFiEEdj+N7pgGP1gKvbdQJKB0S2uuNdsFAl905K4LHG5pdGVAaHEu c2sACgkQJKB0S2uuNdtqSg//fQShS5MvjIo+1IR/eNsUHZfjEzkMm65+ArDekbGc uT7v24YTPgWRC8VBZTABhfyhv0L5Ec5Hv91IsNp9k7VX4Zp+PlEkPg7LrBLlWxJz 4QzVs8cx0qpWLlesaCWZl9KR/HzWzHpaFWwEuFALpzlA68JehL4zDA71+yhFOjxC /iTQ+j5tS1nPj3vF6DeSc5M+bjFhw9Zy3H6y5BKyB+MIrYkmLTaPSQrWsTCSlD2q u7j/Y5yZnnVEQJbvqJZhHXMl5QNv3QdkHn3Jtd9dldlOlZPpTZ6lNlpuqpLKJ+J9 ExyUulg+T7w4RNshL9wmxXyDRn5GCSJGkkBY6sq9S1lVWikqA9sPeNiDEhAzVvTW ADAg7MdHDOCwTf5NLSQmoTYsf6ubkpX+4EUKctEy0hX76PVoriegpapqH2vgSfL7 NKSx0fXUDhxtdM1gR4tCprjwafUl+Q/+h4azunYW5noAyiLJecLpluOd7lgoPELP mbjQYUPRct55xmFjScAqQEOun3oosYmuPf1qZLKMSf5m4K7fD+uGhSd+pD9KwfQN KluBsO0oI5d7zZDFfdUj7SRZS4AAzWikaKk22UnEd27bchCdWkwc4TybTf0A2+WY 6EZ/042MqjzUgjMxbqqNR3eto/ddl/GwvWJuOyFsaZUsO8jcmlfFuF13mGJMqvxH tlw= =8rQL -----END PGP SIGNATURE----- --c2H4R5A6Y1zZM2I6HekiCDvSj2RD5TbHT-- From nobody Wed Sep 30 15:54:52 2020 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 15E343A0D2A for ; Wed, 30 Sep 2020 15:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 1-obvrD8OYyI for ; Wed, 30 Sep 2020 15:54:46 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::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 B16ED3A0DF3 for ; Wed, 30 Sep 2020 15:54:37 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id k25so2989437ljg.9 for ; Wed, 30 Sep 2020 15:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c0lcNzk9w3pQZiptmFOEEKxm+pnC1c+oTPboJAFJORc=; b=Aq6n2d1Gznm12jjJR3bAqEYc1vRvShmWzBg8wVnE8IKrBfhGX7ufz+OInJQy3ghkeO 4aTzADiEgWEEa2QXO/kvapWEfIYkbkMdvT8Ny+C4jyt0ZXtbFSpZQe6Lv0aTadzBYL9l Z6tgyA6lpkXAYSV69ogi61yOEjC/5qTtYa5ESbQDb4bcH/vWC2sRRVob5E/8SqYI5XIn g79fLbCr+6Xu6zJnOZ4as0NFrl3kuVa9DIx0v/nEevJg7bEOJVl0GbrcwJSlIxhP8aQe BQaGY3AzdJBpuHOlGQzsEueA34h89AqvHsNDYZls9TUT9JwvtVZOKOfQyeu7v8hIBu8P 4qfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c0lcNzk9w3pQZiptmFOEEKxm+pnC1c+oTPboJAFJORc=; b=dqo+kFdJJDwam24Ks+UANYmffQaigLMRZhIEUzs5voSzYUOCtrujmS2MJm+s/4KXuw D446tach3jomvCfE+RnyZnqY7T67xDZLaktT9+bAjV6YKOYVYpogFQSAjbzd9XxzU7Yz lDQ1C6R1NX/7MF1bJocd7/hs5qSu0DCVoN/jZfkHs4yKMHltbpc+Emx8ww6Yd2bVvZ6n T2Z35vrM1mKavgTvFaKWy+9TmqP5VZ4IX+ZwhGIZKwEE0c+UjtncmXOESQZHH/2s97U5 naQ0NySQ8wWD7hC7LPI97Vzg/8pfNqo5AAFzTrWnyhJHY6RFuGbhdbFTKMQsGLB5FXFO i1zw== X-Gm-Message-State: AOAM531oLMibCF9WbxlUovEWPtZrocr1mm+rsScNtzZ1UHT41dYq/UEF CfXNTfvsGHCNBLGxPx+6K2qLznBY5qVnSIKhZ5b0ugkxuPmzow== X-Google-Smtp-Source: ABdhPJzqEfBXJoin0jHoGVLrlyqT35O+tpn3jYLbid6I+LhfxCg0jrHR61DWL78zC6X1f0NFmSHfRS6YKupwEtFerXo= X-Received: by 2002:a05:651c:1af:: with SMTP id c15mr1504429ljn.347.1601506475670; Wed, 30 Sep 2020 15:54:35 -0700 (PDT) MIME-Version: 1.0 References: <441d95cc-fe41-6d63-849f-a1d30c86859d@hq.sk> <01000174e013b1f6-fd0b45d1-951d-41dd-85d8-39685a52e998-000000@email.amazonses.com> In-Reply-To: From: Hongwei Li Date: Wed, 30 Sep 2020 18:54:24 -0400 Message-ID: To: Robert Varga Cc: Kent Watsen , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000967f0805b08fc8dc" Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 22:54:51 -0000 --000000000000967f0805b08fc8dc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 30, 2020 at 4:04 PM Robert Varga wrote: > On 30/09/2020 19:33, Kent Watsen wrote: > > Hi Robert, > > > >> That is assuming the list in question has iteration order which is > >> stable. I do not believe this is something RFC7950 mandates on anythin= g > >> except ordered-by=3Duser. > > > > If not =E2=80=9Cordered-by user=E2=80=9D, then its =E2=80=9Cordered-by = system=E2=80=9D that, as RFC 7950 > says, "the server is free to sort the list entries in any reasonable > order.=E2=80=9D This is a stable ordering, IMO. > > It's been quite some time since I did lawyer-reading the RFCs, but for > the sake of argument: > > - is use of hash maps for keyed lists okay, hence the sort order is the > encounter order based on the contents? > - if so, does that order remain the same even across server restarts? > > I am not sure what the litmus test for 'reasonable' would look like, I > am afraid. > > [HL] I would say there is no guarantee on the stable ordering. And the status may change across server restarts. > >> So let's say the list has 4 elements A, B, C, D. > >> > >> 1) The first request returns items A, B, C. > >> 2) An item is inserted before C, so that the list is E, A, B, C, D. > >> 3) What does the second request return? > >> > >> Similarly: > >> > >> 1) The first request returns items A, B, C. > >> 2) An item is deleted before C, so that the list is B, C, D. > >> 3) What does the second request return? > >> > >> Pagination is deceptively hard. > > > > Is your conjecture that the solution should enable something akin to > cursors? Would this be an advanced feature that a server might support o= n > a list-by-list basis? Maybe "node-tags=E2=80=9D could be useful here to= o=E2=80=A6 > > If the requirement is to really just have an iterator, which breaks when > the list changes, then a node-tag+offset would be sufficient. But then > you could end up in a situation where you will never traverse the list > simply because its rate of change exceeds your ability to traverse it. > > The path forks quite a bit if you want something more specific, like: > "visit all elements in any order, i.e. additions do not break iteration". > > If we have requirements towards that level of complexity, then yes, I > would very much prefer if there was a cursor-like resource associated > with an ongoing pagination request. > > If I squint just a little bit, the first paginated request is not that > different for a (one-shot) subscription to receive notification of all > list entries. Subsequent requests are fetches from that notification > stream... which shows my reactive systems bias :) > > [HL] In the above examples, they are more of dynamic linked lists with multiple threads making operations on the lists. The index or position parameter can't be used to get the same values as they change with system running. However pagination can be done on snapshot. It means the server can send data in pages (some or all) once the request is made. This also complies with the characteristic of a running system. > Regards, > Robert > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000967f0805b08fc8dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Sep 30, 2020 at 4:04 PM Rober= t Varga <nite@hq.sk> wrote:
On 30/09/2020 19:33, Ke= nt Watsen wrote:
> Hi Robert,
>
>> That is assuming the list in question has iteration order which is=
>> stable. I do not believe this is something RFC7950 mandates on any= thing
>> except ordered-by=3Duser.
>
> If not =E2=80=9Cordered-by user=E2=80=9D, then its =E2=80=9Cordered-by= system=E2=80=9D that, as RFC 7950 says, "the server is free to sort t= he list entries in any reasonable order.=E2=80=9D=C2=A0 This is a stable or= dering, IMO.

It's been quite some time since I did lawyer-reading the RFCs, but for<= br> the sake of argument:

- is use of hash maps for keyed lists okay, hence the sort order is the
encounter order based on the contents?
- if so, does that order remain the same even across server restarts?

I am not sure what the litmus test for 'reasonable' would look like= , I
am afraid.

[HL] I would say there is no guarantee on the stable = ordering. And the status may change across server restarts.
=C2= =A0
>> So let's say the list has 4 elements A, B, C, D.
>>
>> 1) The first request returns items A, B, C.
>> 2) An item is inserted before C, so that the list is E, A, B, C, D= .
>> 3) What does the second request return?
>>
>> Similarly:
>>
>> 1) The first request returns items A, B, C.
>> 2) An item is deleted before C, so that the list is B, C, D.
>> 3) What does the second request return?
>>
>> Pagination is deceptively hard.
>
> Is your conjecture that the solution should enable something akin to c= ursors?=C2=A0 Would this be an advanced feature that a server might support= on a list-by-list basis?=C2=A0 =C2=A0Maybe "node-tags=E2=80=9D could = be useful here too=E2=80=A6

If the requirement is to really just have an iterator, which breaks when the list changes, then a node-tag+offset would be sufficient. But then
you could end up in a situation where you will never traverse the list
simply because its rate of change exceeds your ability to traverse it.

The path forks quite a bit if you want something more specific, like:
"visit all elements in any order, i.e. additions do not break iteratio= n".

If we have requirements towards that level of complexity, then yes, I
would very much prefer if there was a cursor-like resource associated
with an ongoing pagination request.

If I squint just a little bit, the first paginated request is not that
different for a (one-shot) subscription to receive notification of all
list entries. Subsequent requests are fetches from that notification
stream... which shows my reactive systems bias :)

[HL] In the above examples, they are more of dynamic = linked lists with multiple threads making operations on the lists.=C2=A0
The index or position parameter can't be used to get the same v= alues as they change with system running.
However pagination can = be done on snapshot. It means the server can send data in pages (some or al= l) once the request is made.
This also complies with the characte= ristic of a running system.
=C2=A0
Regards,
Robert

_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000967f0805b08fc8dc-- From nobody Wed Sep 30 16:56:12 2020 Return-Path: <01000174e171d7f6-1d9832c9-b0f4-4a45-89a4-619763c03780-000000@amazonses.watsen.net> 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 4D3073A0D7A for ; Wed, 30 Sep 2020 16:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 E7xVL6y9FRbw for ; Wed, 30 Sep 2020 16:56:10 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C396C3A09F7 for ; Wed, 30 Sep 2020 16:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1601510168; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=Bs62I5FqhP0bmhh/44o8T5Aarabj3vREREzmoVZKMlg=; b=DAzP4pNnVqc9daGR9G/Hq64xI9HVgzy3BtoMB8HJF9AFAfJufBdVHLuo2bRqIMvS GrXvcZz9Tx9lsS8uO9SnJG8gY7mLkqwNP3O6W73fEbvCXtGXKrcey0RXuMHE6xlfMeZ QwY62udMNlI69B1PiYPjC6JbN4O9KCCLczsLUYi8= From: Kent Watsen Message-ID: <01000174e171d7f6-1d9832c9-b0f4-4a45-89a4-619763c03780-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_41F33E7C-8A4A-45B6-A4CC-1BC03FD79A97" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 30 Sep 2020 23:56:08 +0000 In-Reply-To: Cc: Qin Wu , Andy Bierman , "netconf@ietf.org" To: Robert Varga References: <441d95cc-fe41-6d63-849f-a1d30c86859d@hq.sk> <01000174e013b1f6-fd0b45d1-951d-41dd-85d8-39685a52e998-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.09.30-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 23:56:11 -0000 --Apple-Mail=_41F33E7C-8A4A-45B6-A4CC-1BC03FD79A97 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Robert, > It's been quite some time since I did lawyer-reading the RFCs, but for > the sake of argument: >=20 > - is use of hash maps for keyed lists okay, hence the sort order is = the > encounter order based on the contents? > - if so, does that order remain the same even across server restarts? >=20 > I am not sure what the litmus test for 'reasonable' would look like, I > am afraid. Perhaps it=E2=80=99s derived from the next sentence: The "description" string for the list may suggest an order to the server implementor. This suggests that the intention is that servers should be able to at = least *return* a stable order. How a server achieves this (given its = DB-backend, etc.) is implementation-specific. =20 > If the requirement is to really just have an iterator, which breaks = when > the list changes, then a node-tag+offset would be sufficient. But then > you could end up in a situation where you will never traverse the list > simply because its rate of change exceeds your ability to traverse it. >=20 > The path forks quite a bit if you want something more specific, like: > "visit all elements in any order, i.e. additions do not break = iteration". >=20 > If we have requirements towards that level of complexity, then yes, I > would very much prefer if there was a cursor-like resource associated > with an ongoing pagination request. Ack. And the tradeoffs aren=E2=80=99t even just "easy/potentially-imperfect" = vs. "hard/perfect", as resources come into play, and the scales tip = after a number of successive calls. FWIW, for CT-queries, RESTCONF's Etag/Last-Modified tags can be used to = catch a potential imperfect response. > If I squint just a little bit, the first paginated request is not that > different for a (one-shot) subscription to receive notification of all > list entries. Subsequent requests are fetches from that notification > stream... which shows my reactive systems bias :) Yes, streaming is goodness, but there=E2=80=99s generally a need for the = most-recent to be on-box also. That said, we could conclude that = streaming SHOULD be used to export very-fast logs and therefore = easy/potentially-imperfect is =E2=80=9Cgood enough=E2=80=9D for queries. Streaming only applies the CF lists holding time-series data (e.g., = logs), which is an important part, but not the only part, being = discussed. Maybe different =E2=80=9Crequirements=E2=80=9D, as you say, = apply to CF vs CT lists? K. --Apple-Mail=_41F33E7C-8A4A-45B6-A4CC-1BC03FD79A97 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Robert,

It's been quite some time = since I did lawyer-reading the RFCs, but for
the sake of = argument:

- is use of hash maps for keyed = lists okay, hence the sort order is the
encounter order = based on the contents?
- if so, does that order remain the = same even across server restarts?

I am not = sure what the litmus test for 'reasonable' would look like, I
am afraid.

Perhaps it=E2=80=99s derived from the next = sentence:

The = "description" string for the list may suggest an order
to the = server implementor.

This suggests = that the intention is that servers should be able to at least *return* a = stable order.   How a server achieves this (given its DB-backend, = etc.) is implementation-specific.  


If the requirement is to really just have an = iterator, which breaks when
the list changes, then a = node-tag+offset would be sufficient. But then
you could = end up in a situation where you will never traverse the list
simply because its rate of change exceeds your ability to = traverse it.

The path forks quite a bit if = you want something more specific, like:
"visit all = elements in any order, i.e. additions do not break iteration".

If we have requirements towards that level of = complexity, then yes, I
would very much prefer if there = was a cursor-like resource associated
with an ongoing = pagination request.

Ack.

And the = tradeoffs aren=E2=80=99t even just "easy/potentially-imperfect" vs. = "hard/perfect", as resources come into play, and the scales tip after a = number of successive calls.

FWIW, = for CT-queries, RESTCONF's Etag/Last-Modified tags can be used to catch = a potential imperfect response.


If I squint = just a little bit, the first paginated request is not that
different for a (one-shot) subscription to receive = notification of all
list entries. Subsequent requests are = fetches from that notification
stream... which shows my = reactive systems bias :)

Yes, streaming is goodness, but there=E2=80=99s = generally a need for the most-recent to be on-box also.  That said, = we could conclude that streaming SHOULD be used to export very-fast logs = and therefore easy/potentially-imperfect is =E2=80=9Cgood enough=E2=80=9D= for queries.

Streaming only applies the CF lists holding = time-series data (e.g., logs), which is an important part, but not the = only part, being discussed.  Maybe = different =E2=80=9Crequirements=E2=80=9D, as you say, apply to CF = vs CT lists?

K.



= --Apple-Mail=_41F33E7C-8A4A-45B6-A4CC-1BC03FD79A97-- From nobody Wed Sep 30 21:33:33 2020 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 7B2783A0A6A for ; Wed, 30 Sep 2020 21:33:26 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 jPGc4-xwhw2M for ; Wed, 30 Sep 2020 21:33:25 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 E11003A0A2E for ; Wed, 30 Sep 2020 21:33:24 -0700 (PDT) Received: from lhreml718-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id BC39B2A4BE4A37858B6B for ; Thu, 1 Oct 2020 05:33:22 +0100 (IST) Received: from lhreml718-chm.china.huawei.com (10.201.108.69) by lhreml718-chm.china.huawei.com (10.201.108.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 1 Oct 2020 05:33:22 +0100 Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml718-chm.china.huawei.com (10.201.108.69) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Thu, 1 Oct 2020 05:33:21 +0100 Received: from DGGEML531-MBS.china.huawei.com ([169.254.5.245]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0487.000; Thu, 1 Oct 2020 12:33:16 +0800 From: Qin Wu To: Kent Watsen , =?utf-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= CC: "netconf@ietf.org" Thread-Topic: [netconf] restconf collections Thread-Index: AdaXqmqKAXfr1Ii5SXaCwhU6e4V5sQ== Date: Thu, 1 Oct 2020 04:33:15 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.72.214] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 04:33:32 -0000 Pj4gWWVzLCBYUGF0aCBpcyB0aGUg4oCccmlnaHQgYW5zd2Vy4oCdLCBidXQgd2UgbmVlZCB0byBl bnN1cmUgaXTigJlzIA0KPj4gY29uc3RyYWluZWQgZW5vdWdoIHRvIGJlIG1hcHBhYmxlIHRvIGNv bW1vbiBEQi1iYWNrZW5kcy4NCj4gDQo+IFNvIHRoZSBjbGllbnQgdGFsa3MgdG8gdGhlIHNlcnZl ciwgYW5kIHRoZSBzZXJ2ZXIgdGFsa3MgdG8gdGhlICJkYiINCj4gYmFja2VuZCAobm90ZSB0aGF0 IGluIG1hbnkgaW1wbGVtZW50YXRpb25zICBvcGVyYXRpb25hbCBzdGF0ZSBpcyANCj4gdHlwaWNh bGx5IG5vdCBzdG9yZWQgaW4gYSByZWFsIGRhdGFiYXNlKS4NCg0KU29tZSBvcHN0YXRlIG11c3Qg YmUgcGVyc2lzdGVkLCBlLmcuLCBsb25nLWxpdmVkIGNvdW50ZXJzLCBsb2dzLCBldGMuLCBidXQg aXTigJlzIGEgZ29vZCBwb2ludCBhYm91dCBvdGhlciBvcHN0YXRlIG5vdCBiZWluZyBwZXJzaXN0 ZWQuICAgUGVyaGFwcyDigJxub2RlLXRhZ3PigJ0gY2FuIGJlIHVzZWQgaGVyZSwgdG8gZGlmZmVy ZW50aWF0ZSB3aGljaCBpcyB3aGljaOKApmFuZCBzZXJ2ZXJzIGNhbiBpbmRpY2F0ZSBpZi9ob3cg dGhleSBzdXBwb3J0IHRoZSBlcGhlbWVyYWwgb3BzdGF0ZSBsZWFmcyBpbiBxdWVyaWVzPw0KDQpb UWluXTpUaGF0J3MgYSBnb29kIGNhc2UgZm9yIG5vZGUgdGFnLCBpbiBlYXJsaWVyIGRpc2N1c3Np b24sIHdlIGRpc2N1c3NlZCBvcGVyYXRpb24gdHlwZSwgd2hpY2ggZGlzdGluZ3Vpc2hzIGN1bXVs YXRpdmUgc3RhdGlzdGljcyB2YWx1ZSBmcm9tIGN1cnJlbnQgdmFsdWUuIFRoZSBjYXNlIGRpc2N1 c3NlZCBoZXJlIGlzIHZlcnkgY2xvc2UgdG8gb3BlcmF0aW9uIHR5cGUgcHJvcG9zYWwgZGlzY3Vz c2VkIGVhcmxpZXIuDQoNCj4gU28gd2UgaGF2ZToNCj4gDQo+ICBjbGllbnQgLT4gIHNlcnZlciAt PiAgYmFja2VuZA0KPiANCj4gSWYgd2UgZG9uJ3QgaGF2ZSBhbnkgZmlsdGVyIGNhcGFiaWxpdGll cywgdGhlIGNsaWVudCBoYXMgdG8gZ2V0IA0KPiBldmVyeXRoaW5nLCBhbmQgdGhlbiBmaWx0ZXIu ICBJZiB3ZSBzdXBwb3J0IFhQYXRoIGFuZCB0aGUgYmFja2VuZCANCj4gZG9lc24ndCBzdXBwb3J0 IGl0LCB0aGUgc2VydmVyIHdpbGwgaGF2ZSB0byBmaWx0ZXIuICBUaGlzIGlzIHN0aWxsIA0KPiBt b3JlIGVmZmljaWVudCB0aGFuIGZpbHRlcmluZyBpbiB0aGUgY2xpZW50Lg0KDQpQcm9iYWJseSwg ZXNwZWNpYWxseSB3aGVuIGFzc3VtaW5nIHRoZSBzZXJ2ZXIgaGFzIGJldHRlciByZXNvdXJjZXMg YW5kL29yIHRoZSBjbGllbnQgPC0tPiBzZXJ2ZXIgYmFuZHdpZHRoIGlzIGNvbnN0cmFpbmVkLg0K DQoNCj4gSW4gQ29uZkQvTlNPIHdlIG1vdmVkIG1vcmUgYW5kIG1vcmUgZmlsdGVyaW5nIGxvZ2lj IHRvd2FyZHMgdGhlIA0KPiBiYWNrZW5kLCB0byBzcGVlZCB1cCBwZXJmb3JtYW5jZS4NCg0KQWNr Lg0KDQoNCj4gSSB0aGluayBlKSBpcyB3YXkgbW9yZSBpbXBvcnRhbnQgdGhhbiBjKS4gIEkgc3Vn Z2VzdCBmb2N1cyBvbiBhICsgYiArIA0KPiBjLg0KDQpOb3RlZCwgYnV0IEkgdGhpbmsgeW91IG1l YW50IGEgKyBiICsgZS4NCg0KTm90ZSBzdXJlIGhvdyBvdGhlcnMgZmVlbCBhYm91dCDigJxkaXJl Y3Rpb246IChjKSwgYnV0IG15IHByaW1hcnkgdXNlLWNhc2UgcmV2b2x2ZXMgYXJvdW5kIHRpbWUt c2VyaWVzIGRhdGEgKGUuZy4sIGxvZ3MpLCB3aGVyZSB0aGUgaW50ZXJlc3QgaXMgY29tbW9ubHkg b24gdGhlIG1vc3QtcmVjZW50IGVudHJpZXMsIHNvICJyZXZlcnNlLS0+b2Zmc2V04oCUPmxpbWl0 4oCdIHdvcmtzIG5pY2VseS4gIA0KDQpQZXJoYXBzIGFuIGFsdGVybmF0aXZlIHdvdWxkIGJlIHRv IGxpZnQgYSBjb25jZXB0IGZyb20gUHl0aG9uIHdpdGggbmVnYXRpdmUgaW5kZXhlcyBzbywgZm9y IGluc3RhbmNlLCBvZmZzZXQ9LU4gYW5kIGxpbWl0PS1OIGdpdmVzIHRoZSBsYXN0IE4gZW50cmll cz8NCltRaW5dOiBZZXMsIHRoYXQncyB3aGF0IEkgdGhvdWdodCBhcyB3ZWxsLCB3aXRoIG5lZ2F0 aXZlIGluZGV4ZXMsIChiKSBhbmQgKGMpIHNlZW1zIHRvIG1lLCBjYW4gYmUgY29tYmluZWQuDQoN Cj4+IFN1cmUsIGJ1dCBJIHdvbmRlciBpZiwgZS5nLiwgYSBuZXRtYXNrIGZpbHRlciwgaXMgc3Vw cG9ydGFibGUgYnkgDQo+PiBjb21tb24gREItYmFja2VuZHMuICBJ4oCZbSBob3Bpbmcgd2UgaGF2 ZSBzb21lIERCLWV4cGVydHMgb24gdGhlIGxpc3QhDQo+IA0KPiBTZWUgYWJvdmUuICBJdCBjYW4g YmUgcXVpdGUgZWZmaWNpZW50IGV2ZW4gaWYgdGhlIGJhY2tlbmQgZG9lc24ndCANCj4gc3VwcG9y dCBpdC4NCg0KSSBkb27igJl0IHNlZSB0aGF0IGFib3ZlLCBidXQgSSBkb27igJl0IGRvdWJ0IHRo YXQgaXQgY2FuIGJlIHNvLCBpdOKAmXMganVzdCBhIHdob2xlIGxvdCBvZiBpbXBsZW1lbnRhdGlv biBjb21wbGV4aXR5LiAgSXQgc2VlbXMgdGhhdCB3ZSBzaG91bGQvbXVzdCBzdXBwb3J0IHNlcnZl cnMgZG9pbmcgaXQsIHdlIGp1c3QgbmVlZCB0byBmaW5kIGEgd2F5IChub2RlLXRhZ3M/KSB0byBl bmFibGUgdGhlbSB0byBleHByZXNzIHRoYXQgYWJpbGl0eS4NCltRaW5dOiBNeSBmZWVsaW5nIGlz IHRoaXMgZWZmaWNpZW5jeSBtb3JlIGRlcGVuZHMgb24gdGhlIGFtb3VudCBvZiBkYXRhIHdlIG5l ZWQgdG8gcmVxdWVzdC4gSWYgYW1vdW50IG9mIGRhdGEgd2UgcmVxdWVzdCBpcyBodWdlLCBtYXli ZSwgY2xpZW50LT4gc2VydmVyLT4gYmFja2VuZCBtYXkgYmUgdGhlIGJldHRlciBjaG9pY2UuDQoN CksuDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KbmV0Y29uZiBtYWlsaW5nIGxpc3QNCm5ldGNvbmZAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0K From nobody Wed Sep 30 23:24:27 2020 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 4356E3A0AE6 for ; Wed, 30 Sep 2020 23:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.997, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=jukKqKQF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UIFPqZHc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZbB0MB6u3bn for ; Wed, 30 Sep 2020 23:24:23 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 697223A0AE9 for ; Wed, 30 Sep 2020 23:24:23 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id A9FF25C07A5; Thu, 1 Oct 2020 02:24:22 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 01 Oct 2020 02:24:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm2; bh= EYY5zIepcpy0kQPIniWK6t3ygOniHeYKEz8Xq69Ng6M=; b=jukKqKQFiql9VIX8 P0ZGQ3Szy+r/sEc575NrpcsgeEY1or4lHAPsiLDX30C3ACK+Z2ZrkzGeLSQWs3Pv twalumophtgx/Ttt1wSvABFVSNWjMenpUHY5XmeNDk4FjAPcKQHEv4xkNAbvxRR8 7leBg48pyhuhnq82eMhsP/azzMXl9G5ogdTBcPERfmdrCusABqUda+w7+NXxwSKI Arj/tTK37pqpQG1EJaufzgVUKKrVyFvk/YWsxKWGrBC0ylD8hgr4+LjWpFOTJNzg PoratGmQzQmYkz0Hk0+5M+i4s52zvb+vSk1alzpsSX7iftLyO1X87QDHRh/F0KnH lNkvGQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=EYY5zIepcpy0kQPIniWK6t3ygOniHeYKEz8Xq69Ng 6M=; b=UIFPqZHcfBUm9mApyy49Rfc2TbogT2h3IGH82X4AdWuonYwxqDbxA0D+F V2+RBcJ78VPKWR+7y1zxLjBtuptHb9PvKWm+DXj+ajVgnQ01UIJJR/3EQB6Tgq4E hiMkAz7zb7i29zq1XbE5/RIyKImC27X6seE85CYPSkFdUwIoFbonlmq3gCbkUsty CNjRMzJ+y8Pnqg9FIudtlMYpcGD/zrF1ZmoS+Z8x4PsQwQmx0g1GQOhMKTdQ6lMI +t9eamiJ8oqf1cnSEGFDx4gzvLX/+lVS1H/lIHXNI6ifBFwT85fp0rzdRLqyNNHb 5s89Bf2ONP45DBfL/n22pFD09X6Ig== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrfeefgddutdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtsg ertdertdejnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepfeehkefgudekfeehieehhf ekgedvffehteevgfeffeeghfdvfeeuleduvddvgfehnecuffhomhgrihhnpehivghtfhdr ohhrghenucfkphepudehkedrudejgedrgedrvdduheenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmsghjodhivghtfhesgeeiieekrdhsvg X-ME-Proxy: Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id 910B43064686; Thu, 1 Oct 2020 02:24:21 -0400 (EDT) Date: Thu, 01 Oct 2020 08:24:18 +0200 (CEST) Message-Id: <20201001.082418.2014472804547759381.id@4668.se> To: olof@hagsand.se Cc: kent+ietf@watsen.net, netconf@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <54cd8891-6c04-3ded-22ca-43a68ac8397f@hagsand.se> References: <20200930.084312.246821928590534256.id@4668.se> <01000174e0279006-63781c55-866c-4ea0-add6-a6fa8a11453c-000000@email.amazonses.com> <54cd8891-6c04-3ded-22ca-43a68ac8397f@hagsand.se> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 06:24:25 -0000 T2xvZiBIYWdzYW5kIDxvbG9mQGhhZ3NhbmQuc2U+IHdyb3RlOg0KPiBPbiAyMDIwLTA5LTMwIDE5 OjU1LCBLZW50IFdhdHNlbiB3cm90ZToNCj4gPiANCj4gPj4gSWYgd2UgYWdyZWUgdG8gbm90IGRv IGQpIHRoZW4gd2UgZG9uJ3QgbmVlZCBhbnkgdXNlIGNhc2VzIGZvciBpdCA7LSkNCj4gPiANCj4g PiBXZSBkb27igJl0IGFncmVlIHRoYXQgc29ydGluZyBpc27igJl0IGV2ZXIgbmVlZCwgYnV0IEkg dGhpbmsgdGhhdCBpdOKAmXMgZmFpciB0byBzYXkgdGhhdCwgYW1vbmdzdCB0aGUgdmFyaW91cyBv dGhlciBwYXJhbWV0ZXJzLCBpdOKAmXMgdGhlIGxlYXN0IGltcG9ydGFudCwgYW5kIHNvIGVuYWJs aW5nIGl0IHZpYSBhIGZlYXR1cmUgc2VlbXMgcHJ1ZGVudC4NCj4gPiANCj4gPiBCVFcsIHNvcnQg KGQpIGNvbWVzIGFmdGVyIGZpbHRlciAoZSksIGluIG91ciBlLS0+YSBwcm9jZXNzaW5nIG1vZGVs LiAgSG9wZWZ1bGx5IHRoZSAoZmFzdCkgZmlsdGVyIHdoaXR0bGVzIHRoZSByZXN1bHQtc2V0IGRv d24gdG8gc29tZXRoaW5nIG1hbmFnZWFibGUgc28gdGhlIChzbG93KSBzb3J0IGlzbuKAmXQgcGFp bmZ1bGx5IHRvbyBlZ3JlZ2lvdXMuDQo+IA0KPiBJIGFncmVlIHNvcnRpbmcgaXMgbGVzcyBpbXBv cnRhbnQgKHRoYW4gYSxiLGUpLg0KPiBJcyBpdCBub3QgYWxzbyBzb21ld2hhdCBiZXlvbmQgdGhl IHByZXNlbnQgeWFuZyBjb25jZXB0cyB3aGVyZSB0aGVyZSBpcw0KPiBhbHJlYWR5IG9yZGVyZWQt YnkgYW5kIGtleSBpbmRpY2VzPw0KPiBTdXBwbHlpbmcgYSBkaWZmZXJpbmcgc29ydGluZyBjb3Vs ZCBpbiBlZmZlY3QgcmVxdWlyZSBhIGRpZmZlcmVudCBzZXQgb2YNCj4gaW5kZXgoZXMpIHdoaWNo IGNvdWxkIGJlIHF1aXRlIGNvc3RseSBpbiBydW50aW1lIGZvciBsYXJnZSBkYXRhIHNldHMuDQoN CkFncmVlZC4NCg0KPiBJZiB5b3Ugd2FudCB0byBzb3J0IGRpZmZlcmVudGx5LCBzaG91bGQgaXQg bm90IGJlIHByZXNlbnQgaW4gdGhlDQo+IHVuZGVybHlpbmcgbW9kZWwsIGllIGFzIGRlY2xhcmlu ZyBhIHNlY29uZGFyeSBzZXQgb2Yga2V5cywgZm9yIGV4YW1wbGUsDQo+IGFzIGFuIGV4dGVuc2lv biBvZiB0aGUgb3JpZ2luYWwgeWFuZyBtb2RlbCAodGh1cyBiZWluZyBvdXQgb2Ygc2NvcGUgaGVy ZSk/DQoNClRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIGRlc2lnbmVyIG9mIHRoZSBkYXRhIG1vZGVs IGlzIGluIG1vc3QgY2FzZXMNCm5vdCB0aGUgY2xpZW50IHdobyBhc2tzIGZvciBhIHBhcnRpY3Vs YXIgc29ydCBvcmRlciwgYW5kIGl0IGlzIG5vdA0KZWFzeSB0byBhbnRpY2lwYXRlIGFsbCBmdXR1 cmUgdXNlIGNhc2VzIHdoZW4gYSBtb2RlbCBpcyBkZXNpZ25lZC4NCg0KDQo+IA0KPiA+IA0KPiA+ PiBBbnl3YXksIGlmIHlvdSB3YW50IHRvIHNvcnQgb24gZGlmZmVyZW50IGZpZWxkcyB5b3UgcHJv YmFibHkgd2FudCB0bw0KPiA+PiBkbyB0aGlzIHJlZ2FyZGxlc3Mgb2YgaG93IHRoZSBsaXN0IGlz IG9yZGVyZCBvbiB0aGUgc2VydmVyLg0KPiA+IA0KPiA+IFBvc3NpYmx5LCBhbmQgY2VydGFpbmx5 IGl0IHdvdWxkIGJlIGVhc3kgdG8gaW1wbGVtZW50LCBJ4oCZbSBqdXN0IHRyeWluZyB0byB1bmRl cnN0YW5kIHdoZW4gdGhhdCBtaWdodCBiZSB0aGUgY2FzZS4gIEZvciBpbnN0YW5jZSwgdXNpbmcg YSBmaXJld2FsbCBydWxlYmFzZSAoYW4gT0JVLWxpc3QpIGFzIGFuIGV4YW1wbGUsIHdoZW4gY291 bGQgZ2V0dGluZyB0aGUgcnVsZXMgaW4gYW55IG90aGVyIG9yZGVyIGJlIG1lYW5pbmdmdWwgdG8g YSBjbGllbnQ/DQo+ID4gDQo+ID4gDQo+ID4+PiBSZWdhcmRpbmcg4oCcSSBkb27igJl0IHRoaW5r IHRoZXkgc2hvdWxkIGJlIHJlc3RyaWN0ZWQgdG8g4oCYaW5kZXhhYmxl4oCZDQo+ID4+PiBjb2x1 bW5z4oCdLCA8c25pcC8+DQo+ID4+DQo+ID4+IE15IGNvbW1lbnQgd2FzIGZvciBib3RoIGQpIGFu ZCBlKSAoc29ydCBhbmQgZmlsdGVyKS4gIEFzIGZvciBmaWx0ZXIsDQo+ID4+IGFuIGV4YW1wbGUg aXMgdG8gZ2V0IGludGVyZmFjZXMgYW5kIHdpdGggb3Blci1zdGF0dXMgPT0gJ2Rvd24nLg0KPiA+ IA0KPiA+IOKAnG9wZXItc3RhdHVz4oCdIGFwcGVhcnMgdG8gYmUgYW4gZW51bSwgYW4gaGVuY2Ug aW5kZXhhYmxl4oCmb3IgcGVyaGFwcyB0aGlzIGlzIGEgZm9yd2FyZC1yZWZlcmVuY2UgdG8geW91 ciBuZXh0IGNvbW1lbnQgYWJvdXQgc29tZSBvcHN0YXRlIG5vdCBiZWluZyBpbiB0aGUgREIuLi4N Cj4gPiANCj4gPiANCj4gPj4+IFllcywgWFBhdGggaXMgdGhlIOKAnHJpZ2h0IGFuc3dlcuKAnSwg YnV0IHdlIG5lZWQgdG8gZW5zdXJlIGl04oCZcw0KPiA+Pj4gY29uc3RyYWluZWQgZW5vdWdoIHRv IGJlIG1hcHBhYmxlIHRvIGNvbW1vbiBEQi1iYWNrZW5kcy4NCj4gDQo+IEkgd291bGQgdGhpbmsg YSAoc3Ryb25nbHkpIGNvbnN0cmFpbmVkIFhQYXRoIHdvdWxkIGJlIGEgdmVyeSBuaWNlIHNvbHV0 aW9uLg0KDQpJIHRoaW5rIGNvbnN0cmFpbmcgd291bGQgYmUgYSBtaXN0YWtlLiAgTm90ZSB0aGF0 IHdlJ3JlIHRhbGtpbmcgYWJvdXQNClhQYXRoIDEuMCBoZXJlLiAgKEkgaG9wZSkuDQoNCg0KDQov bWFydGluDQoNCg0KPiA+PiBTbyB0aGUgY2xpZW50IHRhbGtzIHRvIHRoZSBzZXJ2ZXIsIGFuZCB0 aGUgc2VydmVyIHRhbGtzIHRvIHRoZSAiZGIiDQo+ID4+IGJhY2tlbmQgKG5vdGUgdGhhdCBpbiBt YW55IGltcGxlbWVudGF0aW9ucyAgb3BlcmF0aW9uYWwgc3RhdGUgaXMNCj4gPj4gdHlwaWNhbGx5 IG5vdCBzdG9yZWQgaW4gYSByZWFsIGRhdGFiYXNlKS4gIA0KPiA+IA0KPiA+IFNvbWUgb3BzdGF0 ZSBtdXN0IGJlIHBlcnNpc3RlZCwgZS5nLiwgbG9uZy1saXZlZCBjb3VudGVycywgbG9ncywgZXRj LiwgYnV0IGl04oCZcyBhIGdvb2QgcG9pbnQgYWJvdXQgb3RoZXIgb3BzdGF0ZSBub3QgYmVpbmcg cGVyc2lzdGVkLiAgIFBlcmhhcHMg4oCcbm9kZS10YWdz4oCdIGNhbiBiZSB1c2VkIGhlcmUsIHRv IGRpZmZlcmVudGlhdGUgd2hpY2ggaXMgd2hpY2jigKZhbmQgc2VydmVycyBjYW4gaW5kaWNhdGUg aWYvaG93IHRoZXkgc3VwcG9ydCB0aGUgZXBoZW1lcmFsIG9wc3RhdGUgbGVhZnMgaW4gcXVlcmll cz8NCj4gPiANCj4gPiANCj4gPj4gU28gd2UgaGF2ZToNCj4gPj4NCj4gPj4gIGNsaWVudCAtPiAg c2VydmVyIC0+ICBiYWNrZW5kDQo+ID4+DQo+ID4+IElmIHdlIGRvbid0IGhhdmUgYW55IGZpbHRl ciBjYXBhYmlsaXRpZXMsIHRoZSBjbGllbnQgaGFzIHRvIGdldA0KPiA+PiBldmVyeXRoaW5nLCBh bmQgdGhlbiBmaWx0ZXIuICBJZiB3ZSBzdXBwb3J0IFhQYXRoIGFuZCB0aGUgYmFja2VuZA0KPiA+ PiBkb2Vzbid0IHN1cHBvcnQgaXQsIHRoZSBzZXJ2ZXIgd2lsbCBoYXZlIHRvIGZpbHRlci4gIFRo aXMgaXMgc3RpbGwNCj4gPj4gbW9yZSBlZmZpY2llbnQgdGhhbiBmaWx0ZXJpbmcgaW4gdGhlIGNs aWVudC4NCj4gPiANCj4gPiBQcm9iYWJseSwgZXNwZWNpYWxseSB3aGVuIGFzc3VtaW5nIHRoZSBz ZXJ2ZXIgaGFzIGJldHRlciByZXNvdXJjZXMgYW5kL29yIHRoZSBjbGllbnQgPC0tPiBzZXJ2ZXIg YmFuZHdpZHRoIGlzIGNvbnN0cmFpbmVkLg0KPiA+IA0KPiA+IA0KPiA+PiBJbiBDb25mRC9OU08g d2UgbW92ZWQgbW9yZSBhbmQgbW9yZSBmaWx0ZXJpbmcgbG9naWMgdG93YXJkcyB0aGUNCj4gPj4g YmFja2VuZCwgdG8gc3BlZWQgdXAgcGVyZm9ybWFuY2UuDQo+ID4gDQo+ID4gQWNrLg0KPiA+IA0K PiA+IA0KPiA+PiBJIHRoaW5rIGUpIGlzIHdheSBtb3JlIGltcG9ydGFudCB0aGFuIGMpLiAgSSBz dWdnZXN0IGZvY3VzIG9uIGEgKyBiICsNCj4gPj4gYy4NCj4gPiANCj4gPiBOb3RlZCwgYnV0IEkg dGhpbmsgeW91IG1lYW50IGEgKyBiICsgZS4NCj4gPiANCj4gPiBOb3RlIHN1cmUgaG93IG90aGVy cyBmZWVsIGFib3V0IOKAnGRpcmVjdGlvbjogKGMpLCBidXQgbXkgcHJpbWFyeSB1c2UtY2FzZSBy ZXZvbHZlcyBhcm91bmQgdGltZS1zZXJpZXMgZGF0YSAoZS5nLiwgbG9ncyksIHdoZXJlIHRoZSBp bnRlcmVzdCBpcyBjb21tb25seSBvbiB0aGUgbW9zdC1yZWNlbnQgZW50cmllcywgc28gInJldmVy c2UtLT5vZmZzZXTigJQ+bGltaXTigJ0gd29ya3MgbmljZWx5LiAgDQo+ID4gDQo+ID4gUGVyaGFw cyBhbiBhbHRlcm5hdGl2ZSB3b3VsZCBiZSB0byBsaWZ0IGEgY29uY2VwdCBmcm9tIFB5dGhvbiB3 aXRoIG5lZ2F0aXZlIGluZGV4ZXMgc28sIGZvciBpbnN0YW5jZSwgb2Zmc2V0PS1OIGFuZCBsaW1p dD0tTiBnaXZlcyB0aGUgbGFzdCBOIGVudHJpZXM/DQo+ID4gDQo+IA0KPiBUbyBtZSByZXZlcnNl IGRpcmVjdGlvbiBzZWVtcyBhIHN1YnNldCBvZiBvcmRlcmluZy9zb3J0aW5nPyBJZiBzb3J0aW5n DQo+IGlzIGxlc3MgaW1wb3J0YW50LCBzbyB3b3VsZCBhbiBhbHRlcm5hdGUgZGlyZWN0aW9uPw0K PiBVbmxlc3MgdGhlcmUgYXJlIHNvbWUgaW1wb3J0YW50IHVzZS1jYXNlcywgcmV2ZXJzZSBvcmRl ciBoYXZpbmcgdGhlDQo+IGFkdmFudGFnZSBvZiB0aGUgc2FtZSBzb3J0aW5nIG1lY2hhbmlzbS9p bmRleGVzLCBqdXN0IGluIHJldmVyc2UgKG5vdA0KPiBpbnRyb2R1Y2luZyBvdGhlciBrZXlzLCBm b3IgZXhhbXBsZSkNCj4gDQo+ID4gDQo+ID4+PiBTdXJlLCBidXQgSSB3b25kZXIgaWYsIGUuZy4s IGEgbmV0bWFzayBmaWx0ZXIsIGlzIHN1cHBvcnRhYmxlIGJ5DQo+ID4+PiBjb21tb24gREItYmFj a2VuZHMuICBJ4oCZbSBob3Bpbmcgd2UgaGF2ZSBzb21lIERCLWV4cGVydHMgb24gdGhlIGxpc3Qh DQo+ID4+DQo+ID4+IFNlZSBhYm92ZS4gIEl0IGNhbiBiZSBxdWl0ZSBlZmZpY2llbnQgZXZlbiBp ZiB0aGUgYmFja2VuZCBkb2Vzbid0DQo+ID4+IHN1cHBvcnQgaXQuDQo+ID4gDQo+ID4gSSBkb27i gJl0IHNlZSB0aGF0IGFib3ZlLCBidXQgSSBkb27igJl0IGRvdWJ0IHRoYXQgaXQgY2FuIGJlIHNv LCBpdOKAmXMganVzdCBhIHdob2xlIGxvdCBvZiBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5LiAg SXQgc2VlbXMgdGhhdCB3ZSBzaG91bGQvbXVzdCBzdXBwb3J0IHNlcnZlcnMgZG9pbmcgaXQsIHdl IGp1c3QgbmVlZCB0byBmaW5kIGEgd2F5IChub2RlLXRhZ3M/KSB0byBlbmFibGUgdGhlbSB0byBl eHByZXNzIHRoYXQgYWJpbGl0eS4NCj4gPiANCj4gPiANCj4gPiBLLg0KPiA+IA0KPiA+IA0KPiA+ IA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gbmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPiBuZXRjb25mQGlldGYub3JnDQo+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo+ID4gDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRjb25mIG1h aWxpbmcgbGlzdA0KPiBuZXRjb25mQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0Y29uZg0K From nobody Wed Sep 30 23:33:55 2020 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 03FF43A0AEC for ; Wed, 30 Sep 2020 23:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.997, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=RWzJbVi/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BeIUnoJT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10EWGCzYUWSJ for ; Wed, 30 Sep 2020 23:33:52 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840093A0AE3 for ; Wed, 30 Sep 2020 23:33:52 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id DA5665C0741; Thu, 1 Oct 2020 02:33:51 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 01 Oct 2020 02:33:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm2; bh= OyTmKMkwHslLgOh+GFfSNI2b4GwwWDXIc7t9HS1h1+M=; b=RWzJbVi/CqpqpxFK +8dpyRskVROyVwbnWhBD/CtkenYMcIbDUhLNTzKVYxs/W4qo4kbZH0tw3Jkmwzak 0uutvu0x9WvWkYt71HwVFWvKIkCcj3AvhKgbv51KhsqeU0CNpguC1gxy6COZ7kAV ONgAC9x9psh3nbC+iCBIyQ5BuzBXF6UaOCfmr5WZY/3arzl0Tycr0mkWcOBttB8F ivziBvNWcykYLWGeiJxRzQv4U1Ol70fzKUMKmHr3/AzmvI2huO77nGfnqhnveTfp AdmMOWnC1yx7VBeVSeahDt458LF47uyOP5pm4wrWJiewsd5xX8hxao/A9vEIwEgA 66Zepg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=OyTmKMkwHslLgOh+GFfSNI2b4GwwWDXIc7t9HS1h1 +M=; b=BeIUnoJTYxwvtT8c9V7qeYleyH3T2eFanE98Fh/bxiOlVugNxTKsBcYVN m5S+ovwxK1svbSBxqMFN2YXPss/WXzPnly66CeTs+LCrsMg4Hyi/LeVGu6wl20EL oZr9Jnfs7ky10NUNy3K/Sa24y7p6lSLIN5AjJUpX+6uQZ+Ggypv6yJaPlbK7TygT qmVSvBZjiy7Aq1oyExkiWnzBVu9X3SP7IgUcYAa45S2xCL2co0HW7u+sQCkrC3Aq UO+FwzOeEAU396Hsyxm+7u5IaMLTIEWE/xEYlbJMb/mUyuZw4gT4BEWZTg4unRNs 4uEYslYSwZi3t0eN6SNo0Ji/ROwkw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrfeefgdduudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtsg ertdertdejnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepfeehkefgudekfeehieehhf ekgedvffehteevgfeffeeghfdvfeeuleduvddvgfehnecuffhomhgrihhnpehivghtfhdr ohhrghenucfkphepudehkedrudejgedrgedrvdduheenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmsghjodhivghtfhesgeeiieekrdhsvg X-ME-Proxy: Received: from localhost (unknown [158.174.4.215]) by mail.messagingengine.com (Postfix) with ESMTPA id C94243064680; Thu, 1 Oct 2020 02:33:50 -0400 (EDT) Date: Thu, 01 Oct 2020 08:33:49 +0200 (CEST) Message-Id: <20201001.083349.1861081830665539794.id@4668.se> To: kent+ietf@watsen.net Cc: olof@hagsand.se, netconf@ietf.org From: Martin =?iso-8859-1?Q?Bj=F6rklund?= In-Reply-To: <01000174e09a04a9-f53134f8-009f-4d0a-84a1-3165a494054b-000000@email.amazonses.com> References: <01000174e0279006-63781c55-866c-4ea0-add6-a6fa8a11453c-000000@email.amazonses.com> <54cd8891-6c04-3ded-22ca-43a68ac8397f@hagsand.se> <01000174e09a04a9-f53134f8-009f-4d0a-84a1-3165a494054b-000000@email.amazonses.com> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] restconf collections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 06:33:54 -0000 SGksDQoNCktlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD4gd3JvdGU6DQo+IEhpIE9s YWYsDQo+IA0KPiA+IEkgYWdyZWUgc29ydGluZyBpcyBsZXNzIGltcG9ydGFudCAodGhhbiBhLGIs ZSkuDQo+IA0KPiBOb3RlZC4NCj4gDQo+IA0KPiA+IElzIGl0IG5vdCBhbHNvIHNvbWV3aGF0IGJl eW9uZCB0aGUgcHJlc2VudCB5YW5nIGNvbmNlcHRzIHdoZXJlIHRoZXJlDQo+ID4gaXMNCj4gPiBh bHJlYWR5IG9yZGVyZWQtYnkgYW5kIGtleSBpbmRpY2VzPw0KPiA+IFN1cHBseWluZyBhIGRpZmZl cmluZyBzb3J0aW5nIGNvdWxkIGluIGVmZmVjdCByZXF1aXJlIGEgZGlmZmVyZW50IHNldA0KPiA+ IG9mDQo+ID4gaW5kZXgoZXMpIHdoaWNoIGNvdWxkIGJlIHF1aXRlIGNvc3RseSBpbiBydW50aW1l IGZvciBsYXJnZSBkYXRhIHNldHMuDQo+ID4gSWYgeW91IHdhbnQgdG8gc29ydCBkaWZmZXJlbnRs eSwgc2hvdWxkIGl0IG5vdCBiZSBwcmVzZW50IGluIHRoZQ0KPiA+IHVuZGVybHlpbmcgbW9kZWws IGllIGFzIGRlY2xhcmluZyBhIHNlY29uZGFyeSBzZXQgb2Yga2V5cywgZm9yDQo+ID4gZXhhbXBs ZSwNCj4gPiBhcyBhbiBleHRlbnNpb24gb2YgdGhlIG9yaWdpbmFsIHlhbmcgbW9kZWwgKHRodXMg YmVpbmcgb3V0IG9mIHNjb3BlDQo+ID4gaGVyZSk/DQo+IA0KPiBBIGNvdXBsZSBtZXNzYWdlcyBJ IHNlbnQgeWVzdGVyZGF5IGFsbHVkZWQgdG8gZGVmaW5pbmcgYW4gZXh0ZW5zaW9uDQo+IHN0YXRl bWVudCB0aGF0IGNvdWxkIGJlIGFkZGVkIHRvIG5vZGVzIGluIHRoZSBZQU5HIG1vZHVsZXMuDQo+ IA0KPiBOb3cgSeKAmW0gdGhpbmtpbmcgdGhhdCBvbmUtc2l6ZSBkb2VzbuKAmXQgbmVjZXNzYXJp bHkgZml0IGFsbCwgYW5kDQo+IHNvbWV0aGluZyBsaWtlIGEgc2VydmVyLXNwZWNpZmljIOKAnG5v ZGUtdGFn4oCdIHdvdWxkIGJlIG1vcmUgZmxleGlibGUuDQo+IChodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtdGFvLW5ldG1vZC15YW5nLW5vZGUtdGFncw0KPiA8aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRhby1uZXRtb2QteWFuZy1ub2RlLXRhZ3M+KQ0KPiANCj4g TWF5YmUgdGhlIGFuc3dlciBpcyBzb21ld2hlcmUgaW4tYmV0d2VlbiwgaS5lLiwgYW4gZXh0ZW5z aW9uIHRoYXQgYWN0cw0KPiBsaWtlIGEg4oCcaGludOKAnSBhbmQgYSBub2RlLXRhZyBpbmRpY2F0 aW5nIGlmIHRoZSBzZXJ2ZXIgZGVsaXZlcmVkIGl0Lg0KPiBCYWQgbmV3cyB3LyBhbiBleHRlbnNp b24gaXMgdGhhdCBsZWdhY3kgbW9kdWxlcyB3b3VsZCBuZWVkIHRvIGJlDQo+IHJldnZlZCBvciBh dWdtZW50ZWQuDQo+IA0KPiBPbmUgdGhpbmcsIHRob3VnaCwgZmlsdGVyaW5nIG9uIG5vbi1pbmRl eGVkIG5vZGVzIGlzIGd1YXJhbnRlZWQgdG8NCj4gaGF2ZSBzbG93IHBlcmZvcm1hbmNlLCB0aHVz IGl0IHNlZW1zIHRoYXQgd2UgbmVlZCB0byBlbmFibGUgaW5kZXhpbmcNCj4gZm9yIG1vcmUgdGhh biBqdXN0IGEgbGlzdOKAmXMga2V5cy4NCg0KSSBkaXNhZ3JlZSB3aXRoIGJvdGggdGhlc2Ugc3Rh dGVtZW50cy4gIFRoaXMgaXMgYW4gaW1wbGVtZW50YXRpb24NCmlzc3VlLg0KDQo+IE15IGNvbmpl Y3R1cmUgaXMgdGhhdCwgb25jZSB3ZSBoYXZlIHRoZSBpbmRleGVzIGZvciBmaWx0ZXJpbmcgKGUp LA0KPiB0aGV5IGNhbiBiZSB1c2VkIGZvciBzb3J0aW5nIChkKS4gIEF0IGxlYXN0LCB0aGF04oCZ cyB0aGUgd2F5IGl0IHdvcmtzDQo+IHdpdGggc29tZSBEQi1iYWNrZW5kcyBJ4oCZbSBmYW1pbGlh ciB3aXRoLi4uDQoNClRoaXMgaXMgb25lIGltcGxlbWVudGF0aW9uIHN0cmF0ZWd5LiAgV2Ugc2hv dWxkIG5vdCBkZXNpZ24gdGhlDQpzdGFuZGFyZCBhcm91bmQgb25lIGltcGxlbWVudGF0aW9uLg0K DQo+ID4+Pj4gWWVzLCBYUGF0aCBpcyB0aGUg4oCccmlnaHQgYW5zd2Vy4oCdLCBidXQgd2UgbmVl ZCB0byBlbnN1cmUgaXTigJlzDQo+ID4+Pj4gY29uc3RyYWluZWQgZW5vdWdoIHRvIGJlIG1hcHBh YmxlIHRvIGNvbW1vbiBEQi1iYWNrZW5kcy4NCj4gPiANCj4gPiBJIHdvdWxkIHRoaW5rIGEgKHN0 cm9uZ2x5KSBjb25zdHJhaW5lZCBYUGF0aCB3b3VsZCBiZSBhIHZlcnkgbmljZQ0KPiA+IHNvbHV0 aW9uLg0KPiANCj4gKzENCj4gDQo+IA0KPiA+IFRvIG1lIHJldmVyc2UgZGlyZWN0aW9uIHNlZW1z IGEgc3Vic2V0IG9mIG9yZGVyaW5nL3NvcnRpbmc/DQo+IA0KPiBJbmRlZWQuICBJbiBzb21lIERC LWJhY2tlbmRzLCDigJxkaXJlY3Rpb24iIGlzIGEgc3ViLXN0YXRlbWVudCB0byB0aGUNCj4g4oCc c29ydOKAnSBzdGF0ZW1lbnQuDQo+IA0KPiANCj4gPiBJZiBzb3J0aW5nIGlzIGxlc3MgaW1wb3J0 YW50LCBzbyB3b3VsZCBhbiBhbHRlcm5hdGUgZGlyZWN0aW9uPw0KPiANCj4gTWF5YmUsIGJ1dCBh biBpbmRlcGVuZGVudCDigJxkaXJlY3Rpb24iIHdvcmtzIHdpdGggT0JVLWxpc3RzLCB3aGljaCBp cw0KPiB3aHkgSSB0ZWFzZWQgaXQgb3V0Lg0KPiANCj4gQW5kLCBiZXNpZGVzLCB0aGF0IGFzc3Vt ZXMgc29ydGluZyBpcyBsZXNzIGltcG9ydGFudC4gIEkgZG8gaGVhciBhDQo+IGNvbnNlbnN1cyBi ZWdpbm5pbmcgdG8gZm9ybSBpbiB0aGF0IGRpcmVjdGlvbiwgc28gd2XigJlsbCBzZWUuLi4NCj4g DQo+IEFsbCBJIGtub3cgaXMgdGhhdCB0aGVyZSBhcmUgdG9ucyBvZiBVSXMgdGhhdCBlbmFibGUg Y29sdW1uIHNvcnRpbmcNCj4gKGUuZy4sIGFuIGVtYWlsIGNsaWVudCkuICBEbyB3ZSBmZWVsIGRh dGEgbW9kZWxzIGRlZmluZWQgYnkgWUFORyBhcmUNCj4gc29tZWhvdyBpbW11bmUgdG8gdGhpcz8N Cj4gDQo+IEkgaGVhciBmb2xrcyBleHByZXNzaW5nIGNvbmNlcm4gYXJvdW5kIHNvcnRpbmcgYmln IGRhdGEgKGUuZy4sIGxvZ3MpLA0KPiB3aGljaCBJIGdyb2ssIGJ1dCB3aGF0IGFib3V0IGZvciBu b24tT0JVIENUIGxpc3RzIChlLmcuLCBhZG1pbnMpPw0KPiBXb3VsZG7igJl0IHdlIGxpa2UgdG8g c29ydCBieSBuYW1lLCBsYXN0LXRpbWUtY29ubmVjdGVkLCBldGMuPyAgQ2FuIG5vdA0KPiBzdXBw b3J0aW5nIHNvcnRpbmcgb24gYmlnIGRhdGEgc2V0IGJlIGV4cHJlc3NlZCB2aWEgc29tZSBjb21i aW5hdGlvbg0KPiBvZiBleHRlbnNpb24gKyBub2RlLXRhZywgb3IgaW1wbGljaXRseSBkaXNhYmxl ZCBpZiB0aGUgcHJlLWZpbHRlcg0KPiBmYWlscyB0byB3aGl0dGxlIHRoZSByZXN1bHQgc2V0IGRv d24gdG8gc29tZXRoaW5nIHRoYXQgY2FuIGJlIHNvcnRlZA0KPiByZWFzb25hYmx5Pw0KDQpJIGFn cmVlIHRoYXQgdGhpcyBjYW4gYmUgdXNlZnVsLiAgQnV0IGFzIGhhcyBiZWVuIHBvaW50ZWQgb3V0 IGVhcmxpZXINCmluIHRoaXMgdGhyZWFkLCBzb3J0aW5nIGltcGxpZXMgYSBzdGF0ZWZ1bCBzb2x1 dGlvbiB3aGljaCB3aWxsIGNvbnN1bWUNCm1vcmUgcmVzb3VyY2VzIGFuZCBwcm9iYWJseSBjb21l cyB3aXRoIHNvbWUgYWRkaXRpb25hbCBjb21wbGV4aXR5Lg0KDQpBdCBDaXNjby90YWlsLWYgd2Ug aW1wbGVtZW50ZWQgc3VjaCBhIHNvbHV0aW9uOyBhIG1vcmUgZ2VuZXJpYyAicXVlcnkiDQptZWNo YW5pc20sIGZvciBib3RoIE5FVENPTkYgYW5kIFJFU1RDT05GLiAgUGVyaGFwcyBQZXIgQSBjYW4g c2hhcmUNCnNvbWUgZGV0YWlscy4NCg0KDQovbWFydGluDQoNCg0KDQoNCj4gPiBVbmxlc3MgdGhl cmUgYXJlIHNvbWUgaW1wb3J0YW50IHVzZS1jYXNlcywgcmV2ZXJzZSBvcmRlciBoYXZpbmcgdGhl DQo+ID4gYWR2YW50YWdlIG9mIHRoZSBzYW1lIHNvcnRpbmcgbWVjaGFuaXNtL2luZGV4ZXMsIGp1 c3QgaW4gcmV2ZXJzZSAobm90DQo+ID4gaW50cm9kdWNpbmcgb3RoZXIga2V5cywgZm9yIGV4YW1w bGUpDQo+IA0KPiBTb3JyeSwgSSBkaWRu4oCZdCBwYXJzZSB0aGF0LiAgQ2FuIHlvdSBzYXkgYW5v dGhlciB3YXk/DQo+IA0KPiANCj4gSy4NCj4gDQo=

(My concern is that the IETF version will be = too complex to implement or use as the feature list grows.)

[Qin]:That=E2=80=99s the issue we try = to address in our customer=E2=80=99s scenarios. If the solution only = focuses on list, the complexity is controllable. If the scope is not = limited to list, XAPTH filtering and query actually provides a good solution to navigate from root node to = leaf = node.


The functionality is only for lists.  The = functionality (e.g., paging) being discussed only make sense for = lists...


It = is easy. Use RPC operations which map to RESTCONF POST = automatically.

 

[Qin]: Agree, NETCONF = fragment provide an example on what RPC operations look like

https://tools.ietf.org/html/draft-zheng-netconf-fragmentation-0= 2

which is similar to getbulk = operation.