From nobody Mon Nov 1 14:36:44 2021 Return-Path: <0100017cdd6ec538-d4af9a5d-53cc-445b-a056-21042686f6ba-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 0A9853A2FE1 for ; Mon, 1 Nov 2021 14:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=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 tkfa2zcgmc4Z for ; Mon, 1 Nov 2021 14:36:38 -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 3E1033A2FE0 for ; Mon, 1 Nov 2021 14:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1635802597; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=8rmWx5NJ7BTtmAETl6ltZYzJahDkUC4fIpsV8wnM6Ro=; b=QZLYBKZE2li7Ipas+CaCTXImV/s0pQ/cSa7ZCE4ggo0q0rNasDhGI+XN5YrCeeYn 7PnNEtChUw+FIoV370GgRsyOvNx9leYufpxVGOgUIXhC3r2oxaiFcFVjg8AOm/8Agpq oYUUCulQ4H/khmlVntpyShKluCVpGwYKrZGzsSmw= From: Kent Watsen Content-Type: multipart/mixed; boundary="Apple-Mail=_8E156BA3-E4FE-485F-A85B-697D81492CD3" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Mon, 1 Nov 2021 21:36:37 +0000 References: <0100017cb9ba73f6-cae0ba6d-8a06-4e4b-98ef-fe674e3411bd-000000@email.amazonses.com> To: "netconf@ietf.org" In-Reply-To: <0100017cb9ba73f6-cae0ba6d-8a06-4e4b-98ef-fe674e3411bd-000000@email.amazonses.com> Message-ID: <0100017cdd6ec538-d4af9a5d-53cc-445b-a056-21042686f6ba-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.11.01-54.240.8.33 Archived-At: Subject: [netconf] Final 112 agenda 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, 01 Nov 2021 21:36:43 -0000 --Apple-Mail=_8E156BA3-E4FE-485F-A85B-697D81492CD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear NETCONF WG, The NETCONF 112 meeting is next Monday, 7 days from now! Attached is = the ICS file for our meeting, in case you would like to update you = Calendars. No modifications to the agenda have transpired, and thus the draft = agenda sent before stands. Regards, Mahesh and Kent --Apple-Mail=_8E156BA3-E4FE-485F-A85B-697D81492CD3 Content-Disposition: attachment; filename=netconf-112.ics Content-Type: text/calendar; x-unix-mode=0644; name="netconf-112.ics" Content-Transfer-Encoding: 7bit BEGIN:VCALENDAR VERSION:2.0 METHOD:PUBLISH PRODID:-//IETF//datatracker.ietf.org ical agenda//EN BEGIN:VTIMEZONE TZID:UTC BEGIN:STANDARD TZOFFSETFROM:+0000 TZOFFSETTO:+0000 TZNAME:UTC DTSTART:19000101T000000 RDATE:19000101T000000 END:STANDARD END:VTIMEZONE BEGIN:VEVENT UID:ietf-112-14031-netconf SUMMARY:netconf - Network Configuration LOCATION:Room 3 STATUS:CONFIRMED CLASS:PUBLIC DTSTART;TZID=UTC:20211108T143000 DTEND;TZID=UTC:20211108T153000 DTSTAMP:20211004T092807Z DESCRIPTION:Session II\n \n Meetecho: https://meetings.conf.meetecho.com/ietf112/?group=netconf&short=&item=1\n \n Session materials: https://datatracker.ietf.org/meeting/112/session/netconf\n \n See in schedule: https://datatracker.ietf.org/meeting/112/agenda#row-112-2021-11-08-mon-1430-ops-netconf\n END:VEVENT END:VCALENDAR --Apple-Mail=_8E156BA3-E4FE-485F-A85B-697D81492CD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 25, 2021, at 7:12 PM, Kent Watsen wrote: >=20 > The NETCONF Agenda has been uploaded: =20 >=20 > = https://datatracker.ietf.org/meeting/112/materials/agenda-112-netconf-00 >=20 > Please send any comments to the netconf-chairs alias (CC-ed) >=20 > The agenda is also pasted below. >=20 > Chairs // Mahesh and Kent >=20 >=20 >=20 > Agenda for the NETCONF 112 WG Session > ------------------------------------- > https://datatracker.ietf.org/meeting/112/materials/agenda-112-netconf >=20 >=20 > Session: >=20 > Monday, November 8, 2021 > Session I (14:30-15:30 UTC, 9:30-10:30 EST, 12:30-13:30 PDT) >=20 >=20 > WG Chairs: >=20 > Mahesh Jethanandani (mjethanandani at gmail dot com) > Kent Watsen (kent plus ietf at watsen dot net) >=20 >=20 > Available During Session: >=20 > ICS: = https://datatracker.ietf.org/meeting/112/sessions/netconf.ics > MeetEcho: = https://meetings.conf.meetecho.com/ietf112/?group=3Dnetconf > Audio Only: http://mp3.conf.meetecho.com/ietf112/netconf/1.m3u > Jabber: xmpp:netconfjabber.ietf.org?join >=20 >=20 > Available During and After Session: >=20 > CodiMD: https://codimd.ietf.org/notes-ietf-112-netconf > Slides: = https://datatracker.ietf.org/meeting/112/session/netconf > Drafts (PDF): = https://datatracker.ietf.org/meeting/112/agenda/netconf-drafts.pdf > Drafts (TGZ): = https://datatracker.ietf.org/meeting/112/agenda/netconf-drafts.tgz >=20 >=20 > Available After Session: >=20 > Recording: http://www.meetecho.com/ietf112/recordings#NETCONF > Jabber Logs: https://www.ietf.org/jabber/logs/netconf >=20 >=20 > Introduction >=20 > Chairs (10 minutes) > Session Intro & WG Status >=20 >=20 > Chartered items: >=20 > UDP-based Transport for Configured Subscriptions (10 min) > https://tools.ietf.org/html/draft-ietf-netconf-udp-notif-04 > Discussion Leader: Pierre Francois >=20 >=20 > Non-Chartered items: >=20 > Adaptive Subscription to YANG Notification (10 mins) > = https://datatracker.ietf.org/doc/html/draft-wang-netconf-adaptive-subscrip= tion-07 > Discussion Leader: Qiufang Ma >=20 > Transaction ID Mechanism for NETCONF (10 min) > = https://datatracker.ietf.org/doc/html/draft-lindblad-netconf-transaction-i= d-01 > Discussion Leader: Jan Lindblad >=20 > List Pagination for YANG-driven Protocols (20 mins) > = https://datatracker.ietf.org/doc/html/draft-wwlh-netconf-list-pagination-0= 0 > = https://datatracker.ietf.org/doc/html/draft-wwlh-netconf-list-pagination-n= c-02 > = https://datatracker.ietf.org/doc/html/draft-wwlh-netconf-list-pagination-r= c-02 > Discussion Leader: Qin Wu >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail=_8E156BA3-E4FE-485F-A85B-697D81492CD3-- From nobody Wed Nov 3 05:49:46 2021 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 27BFF3A13ED; Wed, 3 Nov 2021 05:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.146 X-Spam-Level: X-Spam-Status: No, score=-5.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, NICE_REPLY_A=-3.33, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qesIjWcFu98n; Wed, 3 Nov 2021 05:49:34 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) (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 A334D3A13D0; Wed, 3 Nov 2021 05:49:33 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id 1A3CnR2V017693 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 3 Nov 2021 13:49:28 +0100 Received: from [139.22.42.144] ([139.22.42.144]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 1A3CnQKc021954; Wed, 3 Nov 2021 13:49:26 +0100 Content-Type: multipart/alternative; boundary="------------bDsbWHW71jQR0JoOa8htYISZ" Message-ID: Date: Wed, 3 Nov 2021 13:49:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Content-Language: en-US To: Kent Watsen Cc: "Rob Wilton (rwilton)" , "netconf@ietf.org" , "draft-ietf-netconf-sztp-csr@ietf.org" , "Brockhaus, Hendrik" References: <162907788324.2949.13159388023679125044@ietfa.amsl.com> <0100017b4cb20cee-3638c1d3-c5d0-4417-8cd9-8df5669a2a2b-000000@email.amazonses.com> <6247a309-c24d-041b-704c-2ddf8b372d00@siemens.com> <0100017b551d703e-ea44f163-2ab5-40c3-9edc-c0eb41620172-000000@email.amazonses.com> <0100017b78a75ff9-6506e24d-20c5-4bd7-83a4-0e7472cdfc6e-000000@email.amazonses.com> <7d5059f5-c0b6-390c-99d3-4fcdc13d445d@siemens.com> <0100017b97c879d0-c2cd3be9-a2d3-4e6d-9ed8-16e99432ff4c-000000@email.amazonses.com> <8a40f036-53d0-5c7b-beb2-72a274f86f1c@siemens.com> <0100017ca9f3d18a-18d07b15-002e-4981-8b33-ffa8067b7849-000000@email.amazonses.com> <4b9cb732-422f-06cc-b194-fa39b0a287f6@siemens.com> <0100017cc94f8422-6081654f-87ca-47aa-892b-f6057d8f4ac2-000000@email.amazonses.com> From: David von Oheimb In-Reply-To: <0100017cc94f8422-6081654f-87ca-47aa-892b-f6057d8f4ac2-000000@email.amazonses.com> Archived-At: Subject: Re: [netconf] Adaptations for draft-ietf-netconf-sztp-csr-09.txt 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, 03 Nov 2021 12:49:44 -0000 This is a multi-part message in MIME format. --------------bDsbWHW71jQR0JoOa8htYISZ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Kent, thanks for your update. The change to section 4.2.1 is fine, but section 4.2.2 still contains: > When a new asymmetric key is used, proof-or-origin is provided, in > the CMP and CMC formats, by the CSR's parent ASN.1 structure > containing origin authentication using either the manufacturer- > generated private key or a shared secret. which should be removed. (The following paragraph, starting with the same words, is an improved version of it). Regards,     David On 29.10.21 01:50, Kent Watsen wrote: > Hi David, > > Thank you for your valuable comments.  Please find the updated draft here: > > https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-10 > > > And the diff here: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-sztp-csr-10 > > > Can you confirm is all your concerns have been addressed? > > Thanks, > Kent > > > >> On Oct 25, 2021, at 6:42 AM, David von Oheimb >> wrote: >> >> Hi Kent et al., >> >> On 10/22/21 23:41, Kent Watsen wrote: >>> >>> Updated draft here: >>> https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-09 >>> >>> >> thanks for your answer and new version 09. >> >> >>>> * Regarding the proposed new text of the section "Verifying Proof >>>> of Origin": >>>> >>>>> >>>>> When the bootstrapping device's manufacturer-generated >>>>> >>>>> private key (e.g., the IDevID key) is reused for the CSR, >>>>> >>>>> proof-of-origin is verified by ensuring the CSR was signed >>>>> >>>>> by that key. >>>>> >>>> Hmm, this proof of origin only works if the IDevID has already been >>>> authenticated before by the entity performing the proof - is this >>>> the case? >>> >>> Yes.  First validate the IDevID (which is readily available) using >>> the IDevID-issuer cert, then ensure the public key in the CSR is the >>> same as the public key in the IDevID. >> I see - so in this case the IDevID has already been enrolled before >> and can be used for authentication. >> Since the details are crucial but rather implicit at this point, it >> would be good to state them clearly. >> >>> Please OLD/NEW text for how you would like to see it improved. >> OLD: >> >> When the bootstrapping device's manufacturer-generated >> private key (e.g., the IDevID key) is reused for the CSR, >> proof-of-origin is verified by ensuring the CSR was signed >> by that key. >> >> NEW: >> >> When the bootstrapping device's manufacturer-generated >> private key (e.g., the IDevID key) is reused for the CSR, >> proof-of-origin is verified by validating the IDevID-issuer cert >>             and ensuring that the CSR uses the same key pair. >> >> >> >>> >>>> Concerning the 2nd part of the new section, >>>> [...] >>>> >>>>> >>>>> When a new asymmetric key is used, proof-or-origin is >>>>> provided, in the CMP and CMC formats, by the CSR’s >>>>> parent ASN.1 structure containing origin authentication >>>>> using either the manufacturer-generated private key or >>>>> a shared secret. >>>>> >>>> >>>> This text loses the link between POP and POO that I was aiming to >>>> point out with my earlier text. >>>> Therefore, I propose a further adaptation of this part, as follows: >>>> >>>>     When a new asymmetric key is used with the CMP or CMC formats, >>>> the parent ASN.1 structure of the CSR >>>>     provides origin authentication using either the >>>> manufacturer-generated private key or shared secret. >>>>     In this way the proof-of-possession of the CSR is directly >>>> linked to the proof-or-origin provided by the parent ASN.1 structure. >>>> >>> >>> Incorporated.  But I added a missing comma and a missing article (‘a’). >> Thanks. >> Yet you forgot to remove the OLD text, just before that new paragraph: >> When a new asymmetric key is used, proof-or-origin is provided, in >> the CMP and CMC formats, by the CSR's parent ASN.1 structure >> containing origin authentication using either the manufacturer- >> generated private key or a shared secret. >> >> >> Pleased to note that you added in version version 06 a "Contributors" >> section saying: >> >> Special thanks goes to David von Oheimb and Hendrik Brockhaus for >> helping with the descriptions for the "cmc-csr" and "cmp-csr" nodes. >> >> >> Cheers, >> >>     David >> >> > --------------bDsbWHW71jQR0JoOa8htYISZ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi Kent,

thanks for your update.

The change to section 4.2.1 is fine,
but section 4.2.2 still contains:

   When a new asymmetric key is used, proof-or-origin is provided, in
   the CMP and CMC formats, by the CSR's parent ASN.1 structure
   containing origin authentication using either the manufacturer-
   generated private key or a shared secret.
which should be removed.
(The following paragraph, starting with the same words, is an improved version of it).

Regards,

    David


On 29.10.21 01:50, Kent Watsen wrote:
Hi David,

Thank you for your valuable comments.  Please find the updated draft here:


And the diff here:


Can you confirm is all your concerns have been addressed?

Thanks,
Kent



On Oct 25, 2021, at 6:42 AM, David von Oheimb <David.von.Oheimb@siemens.com> wrote:

Hi Kent et al.,

On 10/22/21 23:41, Kent Watsen wrote:


thanks for your answer and new version 09.


  • Regarding the proposed new text of the section "Verifying Proof of Origin":

            When the bootstrapping device's manufacturer-generated 

            private key (e.g., the IDevID key) is reused for the CSR, 

            proof-of-origin is verified by ensuring the CSR was signed

            by that key.

Hmm, this proof of origin only works if the IDevID has already been authenticated before by the entity performing the proof - is this the case?

Yes.  First validate the IDevID (which is readily available) using the IDevID-issuer cert, then ensure the public key in the CSR is the same as the public key in the IDevID.
I see - so in this case the IDevID has already been enrolled before and can be used for authentication.
Since the details are crucial but rather implicit at this point, it would be good to state them clearly.

Please OLD/NEW text for how you would like to see it improved.
OLD:

            When the bootstrapping device's manufacturer-generated 
            private key (e.g., the IDevID key) is reused for the CSR, 
            proof-of-origin is verified by ensuring the CSR was signed
            by that key.

NEW:

            When the bootstrapping device's manufacturer-generated 
            private key (e.g., the IDevID key) is reused for the CSR, 
            proof-of-origin is verified by validating the IDevID-issuer cert
            and ensuring that the CSR uses the same key pair.




Concerning the 2nd part of the new section,
[...]


            When a new asymmetric key is used, proof-or-origin is
            provided, in the CMP and CMC formats, by the CSR’s
            parent ASN.1 structure containing origin authentication
            using either the manufacturer-generated private key or
            a shared secret.


This text loses the link between POP and POO that I was aiming to point out with my earlier text.
Therefore, I propose a further adaptation of this part, as follows:

    When a new asymmetric key is used with the CMP or CMC formats, the parent ASN.1 structure of the CSR
    provides origin authentication using either the manufacturer-generated private key or shared secret.
    In this way the proof-of-possession of the CSR is directly linked to the proof-or-origin provided by the parent ASN.1 structure.


Incorporated.  But I added a missing comma and a missing article (‘a’).
Thanks.
Yet you forgot to remove the OLD text, just before that new paragraph:
   When a new asymmetric key is used, proof-or-origin is provided, in
   the CMP and CMC formats, by the CSR's parent ASN.1 structure
   containing origin authentication using either the manufacturer-
   generated private key or a shared secret.


Pleased to note that you added in version version 06 a "Contributors" section saying:

   Special thanks goes to David von Oheimb and Hendrik Brockhaus for
   helping with the descriptions for the "cmc-csr" and "cmp-csr" nodes.


Cheers,

    David



--------------bDsbWHW71jQR0JoOa8htYISZ-- From nobody Sun Nov 7 17:03:47 2021 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 118103A0A70; Sun, 7 Nov 2021 17:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, 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 w4jMxy3b93ri; Sun, 7 Nov 2021 17:03:41 -0800 (PST) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 C20CD3A1016; Sun, 7 Nov 2021 17:03:38 -0800 (PST) Received: by mail-pl1-x62f.google.com with SMTP id b11so1470208pld.12; Sun, 07 Nov 2021 17:03:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:mime-version:from:date:cc:content-transfer-encoding :message-id:to; bh=y22wUtGb6nTdBBnaGItdyDSkJwkG3edxkE1qC6PZBaQ=; b=J4fRBNkNyIsr0dAwh+eHJQgCYSg+lPOB8og1oAMDQHmSRYu78+nM8sOPwap/YefIY5 ezBcm60Y2tNJOQSG/SJeE6WyxCzp266tCc7n3tPbxqmdyfuyNLyF0FiQk/cyvYKTh/eA aKBzAARcufKeuGOGYF1wvOP43ylU9mBnzECtVtBEVlYSf33GlYf0VYceeqEJ0ML0XOaR eoE64HqD7YKjx1A9PP+A8Nch10sHEM3FTFNh7spu0iHQ589KTCr7+yODb/O+bqxpSxpt M3fBJau5FjjjzTPQSpCza/cTspzcBtATK+gSE7AgN5awmRlRIbRrnKLln86BbIspkfMe sL2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:mime-version:from:date:cc :content-transfer-encoding:message-id:to; bh=y22wUtGb6nTdBBnaGItdyDSkJwkG3edxkE1qC6PZBaQ=; b=yXXV3uePVkUMMRxcyIVljBjgSo0UIL12ZVh51Z2aakZm2JWpjr/K+JDhia+Ti9YSMS a8hJ9c7ZSi2nw6alcxLIVPOou4Fe7Q3BvKaOY/SrxWj3w40/PL7bas/vBIaN06sVf6tv CFSQanCexlVLrkijJHRBBjogrbUUxnfdaFk/lB9daVqHcobtwBiohQ4n4GC3xXoJu/qa QlOxV1L7CBgrOG1fYvAgIrGzsFa7XRj1mZ/AQD9aYq6ntk/KZGxkVty8arVM/pPohVmU x9xIHukLzcd6w4D80HeG0crvEghWYfp0EDtgCdVADGXnuL2GPvQRsgSZy5wk3tTvlJr9 Nb7Q== X-Gm-Message-State: AOAM533AZxSE6eX8ghR6IVGNnVj9dFxpcOCpAt95w6+8Y3B4lV6U3cnW VraNq8iIGo94pbwp53qSRf9unUpdJe4= X-Google-Smtp-Source: ABdhPJz7DIecaETxE/pDxquE4hw4NKwGruO41X1cj1M2/lEEN43fN3Bhlk5LbYrkPONpsz6wcmrgZw== X-Received: by 2002:a17:903:1111:b0:13f:d1d7:fb67 with SMTP id n17-20020a170903111100b0013fd1d7fb67mr66234963plh.85.1636333417124; Sun, 07 Nov 2021 17:03:37 -0800 (PST) Received: from [192.168.1.133] (c-69-181-169-15.hsd1.ca.comcast.net. [69.181.169.15]) by smtp.gmail.com with ESMTPSA id w7sm4533132pgt.37.2021.11.07.17.03.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Nov 2021 17:03:36 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Content-Type: text/html; charset=utf-8 X-Apple-Auto-Saved: 1 X-Apple-Base-Url: x-msg://22/ X-Apple-Mail-Remote-Attachments: YES From: Mahesh Jethanandani X-Apple-Windows-Friendly: 1 Date: Sun, 7 Nov 2021 17:21:01 -0500 Cc: Netconf X-Apple-Mail-Signature: SKIP_SIGNATURE Content-Transfer-Encoding: quoted-printable Message-Id: <12D5318C-D645-477A-8651-31D4C35C34D4@gmail.com> X-Uniform-Type-Identifier: com.apple.mail-draft To: draft-ietf-netconf-udp-notif@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [netconf] Review comments on draft-ietf-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: Mon, 08 Nov 2021 01:03:46 -0000
Hi authors of draft-ietf-netconf-udp-notif,

Here = are some of my comments on the -04 version of the draft.

Nits:
  • Please give the = draft a more descriptive description for the short title rather than = unyte-udp-notif. Something like "UDP-based Subscription=E2=80=9D.
  • S/DTLS is layered next tot/DTLS is layered on top = of/

Comments= (major and minor):

  • In Section 1 there = is an inherent assumption that the network processors/line cards have = network access to the receiver. I think that requirement needs to be = made explicit. Otherwise, routing all messages through an internal = consolidator might be the only option. BTW, I believe the option to = route notification messages through a internal consolidator should be = kept as an option for UDP transport in case the line cards cannot route = out of the box.
  • In Section 2, it is not clear who is = responsible for sending the notification to the publisher that the = receiver is ready to receive notifications.
  • In = Section 3.1, TLS is specified as a transport protocol. I think you mean = TCP or HTTP2 over TCP.
  • There is use of term = =E2=80=99notification message=E2=80=9D and =E2=80=9CNotification = Messages=E2=80=9D. What is the difference? If you are using a = pre-defined term, can you add a definition and nomenclature section that = brings in the reference. If you are defining a new term, can you add a = definition in the document.
  • In Section 3.2, it is = better for the Ver field to have an initial version of 1 instead of 0 to = distinguish from a value that my not have been set.
  • Section 6.1. Not clear on the statement =E2=80=9CSince UDP is = an unreliable transport, with DTLS, an originator or a relay may not = realize ..=E2=80=9D. What has DTLS got to do with the unreliability of = the transport protocol?
  • Section 6.2. Is the draft = asking for assignment of a well known port for UDP based = transport?
  • Section 8. 
    • Has the model been compiled with pyang and yanglint? See = compilation outputs below.
    • File name has a date that = is different from the revision date in the model.
    • Please add references to the models that are imported into = this model in the draft itself. They are there in the model, but not in = the draft itself.
    • How about support for = retransmission timeout value in the YANG model?
    • Change = WG reference to  <https://datatracker.ietf.org/wg/netconf>
    • Remove the prefix =E2=80=9Cmailto:=E2=80=9D It is great in a = HTML document, but does not help in a YANG model.
    • Update Copyright year to 2021.
    • Indentations = are off the model. Please fix.
    • If the grouping = =E2=80=9Ctarget-receiver=E2=80=9D is not going to reused anywhere else, = please remove it and inline it within the augment = statement.


$= pyang -f tree ietf-udp-notif@2021-10-18.yang 
ietf-udp-notif@2021-10-18.yang:120: warning: node = "ietf-subscribed-notifications::transport" is not found in = "ietf-subscribed-notifications::subscriptions=E2=80=9D
$ yanglint ietf-udp-notif@2021-10-18.yang
libyang= warn: Schema node "transport" for parent = "/ietf-subscribed-notifications:subscriptions" not found; in expr = "derived-from(../../../transport" with context node = "/ietf-subscribed-notifications:subscriptions/subscription/receivers/recei= ver=E2=80=9D.

Thanks

Mahesh Jethanandani
mjethanandani@gmail.com





= From nobody Mon Nov 8 04:37:02 2021 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 A078E3A0E8C; Mon, 8 Nov 2021 04:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ef0TjtTqSIzH; Mon, 8 Nov 2021 04:36:56 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC7133A0E87; Mon, 8 Nov 2021 04:36:55 -0800 (PST) Received: from fraeml736-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HnrFz3bVLz688Fd; Mon, 8 Nov 2021 20:36:39 +0800 (CST) Received: from kwepeml100006.china.huawei.com (7.221.188.192) by fraeml736-chm.china.huawei.com (10.206.15.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Mon, 8 Nov 2021 13:36:52 +0100 Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml100006.china.huawei.com (7.221.188.192) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Mon, 8 Nov 2021 20:36:50 +0800 Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.015; Mon, 8 Nov 2021 20:36:50 +0800 From: Tianran Zhou To: Mahesh Jethanandani , "draft-ietf-netconf-udp-notif@ietf.org" CC: Netconf Thread-Topic: Review comments on draft-ietf-netconf-udp-notif Thread-Index: AQHX1DyRJA0/gypCuU2KqKtZamET/Kv5cNyA Date: Mon, 8 Nov 2021 12:36:50 +0000 Message-ID: <4a5c424a36d245b386789b3775cb43de@huawei.com> References: <12D5318C-D645-477A-8651-31D4C35C34D4@gmail.com> In-Reply-To: <12D5318C-D645-477A-8651-31D4C35C34D4@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.112.40.195] Content-Type: multipart/alternative; boundary="_000_4a5c424a36d245b386789b3775cb43dehuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Review comments on draft-ietf-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: Mon, 08 Nov 2021 12:37:01 -0000 --_000_4a5c424a36d245b386789b3775cb43dehuaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFoZXNoLA0KDQpUaGFua3MgdmVyeSBtdWNoIGZvciB5b3VyIGRldGFpbGVkIHJldmlldyBh bmQgY29tbWVudHMuDQpQbGVhc2Ugc2VlIGluIGxpbmUgZm9yIG15IHJlcGx5Lg0KDQpDaGVlcnMs DQpUaWFucmFuDQoNCkZyb206IE1haGVzaCBKZXRoYW5hbmRhbmkgW21haWx0bzptamV0aGFuYW5k YW5pQGdtYWlsLmNvbV0NClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgOCwgMjAyMSA2OjIxIEFNDQpU bzogZHJhZnQtaWV0Zi1uZXRjb25mLXVkcC1ub3RpZkBpZXRmLm9yZw0KQ2M6IE5ldGNvbmYgPG5l dGNvbmZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZXZpZXcgY29tbWVudHMgb24gZHJhZnQtaWV0Zi1u ZXRjb25mLXVkcC1ub3RpZg0KDQpIaSBhdXRob3JzIG9mIGRyYWZ0LWlldGYtbmV0Y29uZi11ZHAt bm90aWYsDQoNCkhlcmUgYXJlIHNvbWUgb2YgbXkgY29tbWVudHMgb24gdGhlIC0wNCB2ZXJzaW9u IG9mIHRoZSBkcmFmdC4NCg0KTml0czoNCg0KICAqICAgUGxlYXNlIGdpdmUgdGhlIGRyYWZ0IGEg bW9yZSBkZXNjcmlwdGl2ZSBkZXNjcmlwdGlvbiBmb3IgdGhlIHNob3J0IHRpdGxlIHJhdGhlciB0 aGFuIHVueXRlLXVkcC1ub3RpZi4gU29tZXRoaW5nIGxpa2UgIlVEUC1iYXNlZCBTdWJzY3JpcHRp b27igJ0uDQogICogICBTL0RUTFMgaXMgbGF5ZXJlZCBuZXh0IHRvdC9EVExTIGlzIGxheWVyZWQg b24gdG9wIG9mLw0KWlRSPiBJIGFncmVlIHdpdGggeW91ciBzdWdnZXN0aW9ucy4NCg0KQ29tbWVu dHMgKG1ham9yIGFuZCBtaW5vcik6DQoNCg0KICAqICAgSW4gU2VjdGlvbiAxIHRoZXJlIGlzIGFu IGluaGVyZW50IGFzc3VtcHRpb24gdGhhdCB0aGUgbmV0d29yayBwcm9jZXNzb3JzL2xpbmUgY2Fy ZHMgaGF2ZSBuZXR3b3JrIGFjY2VzcyB0byB0aGUgcmVjZWl2ZXIuIEkgdGhpbmsgdGhhdCByZXF1 aXJlbWVudCBuZWVkcyB0byBiZSBtYWRlIGV4cGxpY2l0LiBPdGhlcndpc2UsIHJvdXRpbmcgYWxs IG1lc3NhZ2VzIHRocm91Z2ggYW4gaW50ZXJuYWwgY29uc29saWRhdG9yIG1pZ2h0IGJlIHRoZSBv bmx5IG9wdGlvbi4gQlRXLCBJIGJlbGlldmUgdGhlIG9wdGlvbiB0byByb3V0ZSBub3RpZmljYXRp b24gbWVzc2FnZXMgdGhyb3VnaCBhIGludGVybmFsIGNvbnNvbGlkYXRvciBzaG91bGQgYmUga2Vw dCBhcyBhbiBvcHRpb24gZm9yIFVEUCB0cmFuc3BvcnQgaW4gY2FzZSB0aGUgbGluZSBjYXJkcyBj YW5ub3Qgcm91dGUgb3V0IG9mIHRoZSBib3guDQpaVFI+WWVzLCBpdOKAmXMgYSBnb29kIHN1Z2dl c3Rpb24uIEkgd2lsbCBhZGQgdGhpcyB0byB0aGUgbmV3IHJldmlzaW9uLg0KDQogICogICBJbiBT ZWN0aW9uIDIsIGl0IGlzIG5vdCBjbGVhciB3aG8gaXMgcmVzcG9uc2libGUgZm9yIHNlbmRpbmcg dGhlIG5vdGlmaWNhdGlvbiB0byB0aGUgcHVibGlzaGVyIHRoYXQgdGhlIHJlY2VpdmVyIGlzIHJl YWR5IHRvIHJlY2VpdmUgbm90aWZpY2F0aW9ucy4NClpUUj4gSSBhbSBzb3JyeSwgSSBkbyBub3Qg cmVtZW1iZXIgdGhlIGNvbmZpZ3VyZSBzdWJzY3JpcHRpb24gY2xlYXIuIFdoYXTigJlzIGRlZmlu ZWQgZ2VuZXJpYyBpbiBSRkM4NjM5IGFib3V0IGhvdyB0aGUgcHVibGlzaGVyIGtub3cgdGhlIHJl Y2VpdmVyPyBPciB0aGUgcHVibGlzaGVyIGRvZXMgbm90IG5lZWQgdG8gZGVhbCB3aXRoIHRoaXMg YW55d2F5Pw0KDQogICogICBJbiBTZWN0aW9uIDMuMSwgVExTIGlzIHNwZWNpZmllZCBhcyBhIHRy YW5zcG9ydCBwcm90b2NvbC4gSSB0aGluayB5b3UgbWVhbiBUQ1Agb3IgSFRUUDIgb3ZlciBUQ1Au DQpaVFI+IFRoaXMgSSB3b3VsZCBsaWtlIHRvIGxlYXZlIGl0IHRvIFBpZXJyZS4NCg0KICAqICAg VGhlcmUgaXMgdXNlIG9mIHRlcm0g4oCZbm90aWZpY2F0aW9uIG1lc3NhZ2XigJ0gYW5kIOKAnE5v dGlmaWNhdGlvbiBNZXNzYWdlc+KAnS4gV2hhdCBpcyB0aGUgZGlmZmVyZW5jZT8gSWYgeW91IGFy ZSB1c2luZyBhIHByZS1kZWZpbmVkIHRlcm0sIGNhbiB5b3UgYWRkIGEgZGVmaW5pdGlvbiBhbmQg bm9tZW5jbGF0dXJlIHNlY3Rpb24gdGhhdCBicmluZ3MgaW4gdGhlIHJlZmVyZW5jZS4gSWYgeW91 IGFyZSBkZWZpbmluZyBhIG5ldyB0ZXJtLCBjYW4geW91IGFkZCBhIGRlZmluaXRpb24gaW4gdGhl IGRvY3VtZW50Lg0KWlRSPiBJbiBteSBvcGluaW9uLCBubyBkaWZmZXJlbmNlLiBJIHdvdWxkIGxp a2UgdG8gYWRkIGEgcmVmIGZyb20gZXhpc3RpbmcgZGVmaW5pdGlvbi4NCg0KICAqICAgSW4gU2Vj dGlvbiAzLjIsIGl0IGlzIGJldHRlciBmb3IgdGhlIFZlciBmaWVsZCB0byBoYXZlIGFuIGluaXRp YWwgdmVyc2lvbiBvZiAxIGluc3RlYWQgb2YgMCB0byBkaXN0aW5ndWlzaCBmcm9tIGEgdmFsdWUg dGhhdCBteSBub3QgaGF2ZSBiZWVuIHNldC4NClpUUj4gSXMgdGhpcyBub3JtYWw/IEkgZG8gbm90 IG1pbmQgdG8gZG8gdGhpcy4NCg0KICAqICAgU2VjdGlvbiA2LjEuIE5vdCBjbGVhciBvbiB0aGUg c3RhdGVtZW50IOKAnFNpbmNlIFVEUCBpcyBhbiB1bnJlbGlhYmxlIHRyYW5zcG9ydCwgd2l0aCBE VExTLCBhbiBvcmlnaW5hdG9yIG9yIGEgcmVsYXkgbWF5IG5vdCByZWFsaXplIC4u4oCdLiBXaGF0 IGhhcyBEVExTIGdvdCB0byBkbyB3aXRoIHRoZSB1bnJlbGlhYmlsaXR5IG9mIHRoZSB0cmFuc3Bv cnQgcHJvdG9jb2w/DQpaVFI+IFRoaXMgSSB3b3VsZCBsaWtlIHRvIGxlYXZlIGl0IHRvIFBpZXJy ZS4NCg0KICAqICAgU2VjdGlvbiA2LjIuIElzIHRoZSBkcmFmdCBhc2tpbmcgZm9yIGFzc2lnbm1l bnQgb2YgYSB3ZWxsIGtub3duIHBvcnQgZm9yIFVEUCBiYXNlZCB0cmFuc3BvcnQ/DQpaVFI+IFll cy4gVGhpcyBpcyB3aGF0IHdlIHJlcXVlc3QgZnJvbSBJQU5BLg0KDQogICogICBTZWN0aW9uIDgu DQoNCiAgICAgKiAgIEhhcyB0aGUgbW9kZWwgYmVlbiBjb21waWxlZCB3aXRoIHB5YW5nIGFuZCB5 YW5nbGludD8gU2VlIGNvbXBpbGF0aW9uIG91dHB1dHMgYmVsb3cuDQpaVFI+IEkgbm90aWNlZCB0 aGlzLiBCdXQgaXQgc2VlbXMgZnJvbSDigJxpZXRmLXN1YnNjcmliZWQtbm90aWZpY2F0aW9uc+KA nS4gRG8geW91IGtub3cgd2hhdOKAmXMgaGFwcGVuZWQ/DQpJIGFsc28gbm90aWNlZCB0aGUgZGF0 YXRyYWNrZXIgc2hvd3MgNCBlcnJvcnMuIEl0IHNlZW1zIHRoZSBzYW1lIGVycm9ycyBleGlzdCBp biBkcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWYuIENvdWxkIGFueW9uZSBoZWxwIG9uIHRo aXM/DQoNCiAgICAgKiAgIEZpbGUgbmFtZSBoYXMgYSBkYXRlIHRoYXQgaXMgZGlmZmVyZW50IGZy b20gdGhlIHJldmlzaW9uIGRhdGUgaW4gdGhlIG1vZGVsLg0KICAgICAqICAgUGxlYXNlIGFkZCBy ZWZlcmVuY2VzIHRvIHRoZSBtb2RlbHMgdGhhdCBhcmUgaW1wb3J0ZWQgaW50byB0aGlzIG1vZGVs IGluIHRoZSBkcmFmdCBpdHNlbGYuIFRoZXkgYXJlIHRoZXJlIGluIHRoZSBtb2RlbCwgYnV0IG5v dCBpbiB0aGUgZHJhZnQgaXRzZWxmLg0KICAgICAqICAgSG93IGFib3V0IHN1cHBvcnQgZm9yIHJl dHJhbnNtaXNzaW9uIHRpbWVvdXQgdmFsdWUgaW4gdGhlIFlBTkcgbW9kZWw/DQpaVFI+IEkgZG8g bm90IHVuZGVyc3RhbmQgdGhpcy4gV2hhdOKAmXMgdGhpcyBzdWdnZXN0aW9uPw0KDQogICAgICog ICBDaGFuZ2UgV0cgcmVmZXJlbmNlIHRvICA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93 Zy9uZXRjb25mPg0KICAgICAqICAgUmVtb3ZlIHRoZSBwcmVmaXgg4oCcbWFpbHRvOuKAnSBJdCBp cyBncmVhdCBpbiBhIEhUTUwgZG9jdW1lbnQsIGJ1dCBkb2VzIG5vdCBoZWxwIGluIGEgWUFORyBt b2RlbC4NCiAgICAgKiAgIFVwZGF0ZSBDb3B5cmlnaHQgeWVhciB0byAyMDIxLg0KICAgICAqICAg SW5kZW50YXRpb25zIGFyZSBvZmYgdGhlIG1vZGVsLiBQbGVhc2UgZml4Lg0KICAgICAqICAgSWYg dGhlIGdyb3VwaW5nIOKAnHRhcmdldC1yZWNlaXZlcuKAnSBpcyBub3QgZ29pbmcgdG8gcmV1c2Vk IGFueXdoZXJlIGVsc2UsIHBsZWFzZSByZW1vdmUgaXQgYW5kIGlubGluZSBpdCB3aXRoaW4gdGhl IGF1Z21lbnQgc3RhdGVtZW50Lg0KWlRSPiBPdGhlcnMgcmVjZWl2ZWQuIEkgd2lsbCB1cGRhdGUu IE1hbnkgdGhhbmtzIQ0KDQokIHB5YW5nIC1mIHRyZWUgaWV0Zi11ZHAtbm90aWZAMjAyMS0xMC0x OC55YW5nPG1haWx0bzppZXRmLXVkcC1ub3RpZkAyMDIxLTEwLTE4Lnlhbmc+DQppZXRmLXVkcC1u b3RpZkAyMDIxLTEwLTE4Lnlhbmc8bWFpbHRvOmlldGYtdWRwLW5vdGlmQDIwMjEtMTAtMTgueWFu Zz46MTIwOiB3YXJuaW5nOiBub2RlICJpZXRmLXN1YnNjcmliZWQtbm90aWZpY2F0aW9uczo6dHJh bnNwb3J0IiBpcyBub3QgZm91bmQgaW4gImlldGYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zOjpz dWJzY3JpcHRpb25z4oCdDQokIHlhbmdsaW50IGlldGYtdWRwLW5vdGlmQDIwMjEtMTAtMTgueWFu ZzxtYWlsdG86aWV0Zi11ZHAtbm90aWZAMjAyMS0xMC0xOC55YW5nPg0KbGlieWFuZyB3YXJuOiBT Y2hlbWEgbm9kZSAidHJhbnNwb3J0IiBmb3IgcGFyZW50ICIvaWV0Zi1zdWJzY3JpYmVkLW5vdGlm aWNhdGlvbnM6c3Vic2NyaXB0aW9ucyIgbm90IGZvdW5kOyBpbiBleHByICJkZXJpdmVkLWZyb20o Li4vLi4vLi4vdHJhbnNwb3J0IiB3aXRoIGNvbnRleHQgbm9kZSAiL2lldGYtc3Vic2NyaWJlZC1u b3RpZmljYXRpb25zOnN1YnNjcmlwdGlvbnMvc3Vic2NyaXB0aW9uL3JlY2VpdmVycy9yZWNlaXZl cuKAnS4NCg0KVGhhbmtzDQoNCk1haGVzaCBKZXRoYW5hbmRhbmkNCm1qZXRoYW5hbmRhbmlAZ21h aWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCg0KDQoNCg0K --_000_4a5c424a36d245b386789b3775cb43dehuaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdy YXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFy Z2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCglt YXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkw LjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6OTgz ODk0NTgxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTk2MTU2MDc5MDt9DQpAbGlzdCBsMDps ZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1p ZDoxNjQ4NDM2MjEwOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNDE1MzY5Njc2O30NCkBsaXN0 IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoy NTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0 b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+SGkgTWFoZXNoLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+VGhhbmtzIHZlcnkgbXVjaCBmb3IgeW91ciBkZXRhaWxlZCByZXZpZXcgYW5kIGNvbW1lbnRz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5QbGVhc2Ugc2VlIGluIGxpbmUgZm9yIG15IHJlcGx5LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2hlZXJzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5UaWFucmFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiBNYWhlc2ggSmV0aGFuYW5kYW5pIFttYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb21dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBOb3ZlbWJlciA4LCAyMDIxIDY6MjEgQU08YnI+DQo8 Yj5Ubzo8L2I+IGRyYWZ0LWlldGYtbmV0Y29uZi11ZHAtbm90aWZAaWV0Zi5vcmc8YnI+DQo8Yj5D Yzo8L2I+IE5ldGNvbmYgJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJldmlldyBjb21tZW50cyBvbiBkcmFmdC1pZXRmLW5ldGNvbmYtdWRwLW5vdGlmPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I aSBhdXRob3JzIG9mJm5ic3A7PGI+ZHJhZnQtaWV0Zi1uZXRjb25mLXVkcC1ub3RpZiw8L2I+PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXJlIGFyZSBzb21l IG9mIG15IGNvbW1lbnRzIG9uIHRoZSAtMDQgdmVyc2lvbiBvZiB0aGUgZHJhZnQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5pdHM6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4NClBsZWFzZSBnaXZlIHRoZSBkcmFm dCBhIG1vcmUgZGVzY3JpcHRpdmUgZGVzY3JpcHRpb24gZm9yIHRoZSBzaG9ydCB0aXRsZSByYXRo ZXIgdGhhbiB1bnl0ZS11ZHAtbm90aWYuIFNvbWV0aGluZyBsaWtlICZxdW90O1VEUC1iYXNlZCBT dWJzY3JpcHRpb27igJ0uPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNv LWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPg0KUy9EVExTIGlzIGxheWVyZWQgbmV4dCB0b3QvRFRMUyBp cyBsYXllcmVkIG9uIHRvcCBvZi88bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+WlRSJmd0OyBJIGFncmVl IHdpdGggeW91ciBzdWdnZXN0aW9ucy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db21t ZW50cyAobWFqb3IgYW5kIG1pbm9yKTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZl bDEgbGZvMiI+DQpJbiBTZWN0aW9uIDEgdGhlcmUgaXMgYW4gaW5oZXJlbnQgYXNzdW1wdGlvbiB0 aGF0IHRoZSBuZXR3b3JrIHByb2Nlc3NvcnMvbGluZSBjYXJkcyBoYXZlIG5ldHdvcmsgYWNjZXNz IHRvIHRoZSByZWNlaXZlci4gSSB0aGluayB0aGF0IHJlcXVpcmVtZW50IG5lZWRzIHRvIGJlIG1h ZGUgZXhwbGljaXQuIE90aGVyd2lzZSwgcm91dGluZyBhbGwgbWVzc2FnZXMgdGhyb3VnaCBhbiBp bnRlcm5hbCBjb25zb2xpZGF0b3IgbWlnaHQgYmUgdGhlIG9ubHkgb3B0aW9uLg0KIEJUVywgSSBi ZWxpZXZlIHRoZSBvcHRpb24gdG8gcm91dGUgbm90aWZpY2F0aW9uIG1lc3NhZ2VzIHRocm91Z2gg YSBpbnRlcm5hbCBjb25zb2xpZGF0b3Igc2hvdWxkIGJlIGtlcHQgYXMgYW4gb3B0aW9uIGZvciBV RFAgdHJhbnNwb3J0IGluIGNhc2UgdGhlIGxpbmUgY2FyZHMgY2Fubm90IHJvdXRlIG91dCBvZiB0 aGUgYm94LjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+WlRSJmd0O1llcywgaXTigJlzIGEgZ29vZCBzdWdn ZXN0aW9uLiBJIHdpbGwgYWRkIHRoaXMgdG8gdGhlIG5ldyByZXZpc2lvbi4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KSW4gU2VjdGlvbiAyLCBpdCBpcyBub3QgY2xlYXIgd2hv IGlzIHJlc3BvbnNpYmxlIGZvciBzZW5kaW5nIHRoZSBub3RpZmljYXRpb24gdG8gdGhlIHB1Ymxp c2hlciB0aGF0IHRoZSByZWNlaXZlciBpcyByZWFkeSB0byByZWNlaXZlIG5vdGlmaWNhdGlvbnMu PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5aVFImZ3Q7IEkgYW0gc29ycnksIEkgZG8gbm90IHJlbWVtYmVy IHRoZSBjb25maWd1cmUgc3Vic2NyaXB0aW9uIGNsZWFyLiBXaGF04oCZcyBkZWZpbmVkIGdlbmVy aWMgaW4gUkZDODYzOQ0KIGFib3V0IGhvdyB0aGUgcHVibGlzaGVyIGtub3cgdGhlIHJlY2VpdmVy PyBPciB0aGUgcHVibGlzaGVyIGRvZXMgbm90IG5lZWQgdG8gZGVhbCB3aXRoIHRoaXMgYW55d2F5 Pw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQpJbiBTZWN0aW9uIDMuMSwgVExT IGlzIHNwZWNpZmllZCBhcyBhIHRyYW5zcG9ydCBwcm90b2NvbC4gSSB0aGluayB5b3UgbWVhbiBU Q1Agb3IgSFRUUDIgb3ZlciBUQ1AuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5aVFImZ3Q7IFRoaXMgSSB3 b3VsZCBsaWtlIHRvIGxlYXZlIGl0IHRvIFBpZXJyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVs MSBsZm8yIj4NClRoZXJlIGlzIHVzZSBvZiB0ZXJtIOKAmW5vdGlmaWNhdGlvbiBtZXNzYWdl4oCd IGFuZCDigJxOb3RpZmljYXRpb24gTWVzc2FnZXPigJ0uIFdoYXQgaXMgdGhlIGRpZmZlcmVuY2U/ IElmIHlvdSBhcmUgdXNpbmcgYSBwcmUtZGVmaW5lZCB0ZXJtLCBjYW4geW91IGFkZCBhIGRlZmlu aXRpb24gYW5kIG5vbWVuY2xhdHVyZSBzZWN0aW9uIHRoYXQgYnJpbmdzIGluIHRoZSByZWZlcmVu Y2UuIElmIHlvdSBhcmUgZGVmaW5pbmcgYSBuZXcgdGVybSwgY2FuIHlvdSBhZGQNCiBhIGRlZmlu aXRpb24gaW4gdGhlIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+WlRSJmd0OyBJbiBteSBv cGluaW9uLCBubyBkaWZmZXJlbmNlLiBJIHdvdWxkIGxpa2UgdG8gYWRkIGEgcmVmIGZyb20gZXhp c3RpbmcgZGVmaW5pdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+ DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCkluIFNl Y3Rpb24gMy4yLCBpdCBpcyBiZXR0ZXIgZm9yIHRoZSBWZXIgZmllbGQgdG8gaGF2ZSBhbiBpbml0 aWFsIHZlcnNpb24gb2YgMSBpbnN0ZWFkIG9mIDAgdG8gZGlzdGluZ3Vpc2ggZnJvbSBhIHZhbHVl IHRoYXQgbXkgbm90IGhhdmUgYmVlbiBzZXQuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5aVFImZ3Q7IElz IHRoaXMgbm9ybWFsPyBJIGRvIG5vdCBtaW5kIHRvIGRvIHRoaXMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDps MCBsZXZlbDEgbGZvMiI+DQpTZWN0aW9uIDYuMS4gTm90IGNsZWFyIG9uIHRoZSBzdGF0ZW1lbnQg 4oCcU2luY2UgVURQIGlzIGFuIHVucmVsaWFibGUgdHJhbnNwb3J0LCB3aXRoIERUTFMsIGFuIG9y aWdpbmF0b3Igb3IgYSByZWxheSBtYXkgbm90IHJlYWxpemUgLi7igJ0uIFdoYXQgaGFzIERUTFMg Z290IHRvIGRvIHdpdGggdGhlIHVucmVsaWFiaWxpdHkgb2YgdGhlIHRyYW5zcG9ydCBwcm90b2Nv bD88bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlpUUiZndDsgVGhpcyBJIHdvdWxkIGxpa2UgdG8gbGVhdmUg aXQgdG8gUGllcnJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KU2VjdGlvbiA2 LjIuIElzIHRoZSBkcmFmdCBhc2tpbmcgZm9yIGFzc2lnbm1lbnQgb2YgYSB3ZWxsIGtub3duIHBv cnQgZm9yIFVEUCBiYXNlZCB0cmFuc3BvcnQ/PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5aVFImZ3Q7IFll cy4gVGhpcyBpcyB3aGF0IHdlIHJlcXVlc3QgZnJvbSBJQU5BLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzIiPg0KU2VjdGlvbiA4LiZuYnNwOzxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHVs IHR5cGU9ImRpc2MiPg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21zby1saXN0OmwwIGxldmVsMiBsZm8yIj4NCkhhcyB0aGUgbW9kZWwgYmVlbiBjb21waWxlZCB3 aXRoIHB5YW5nIGFuZCB5YW5nbGludD8gU2VlIGNvbXBpbGF0aW9uIG91dHB1dHMgYmVsb3cuPG86 cD48L286cD48L2xpPjwvdWw+DQo8L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+WlRSJmd0OyBJIG5vdGljZWQgdGhpcy4gQnV0IGl0IHNl ZW1zIGZyb20g4oCcaWV0Zi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnPigJ0uIERvIHlvdSBrbm93 IHdoYXTigJlzIGhhcHBlbmVkPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhbHNvIG5vdGljZWQg dGhlIGRhdGF0cmFja2VyIHNob3dzIDQgZXJyb3JzLiBJdCBzZWVtcyB0aGUgc2FtZSBlcnJvcnMg ZXhpc3QgaW4gZHJhZnQtaWV0Zi1uZXRjb25mLWh0dHBzLW5vdGlmLg0KIENvdWxkIGFueW9uZSBo ZWxwIG9uIHRoaXM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPHVs IHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVs MiBsZm8yIj4NCkZpbGUgbmFtZSBoYXMgYSBkYXRlIHRoYXQgaXMgZGlmZmVyZW50IGZyb20gdGhl IHJldmlzaW9uIGRhdGUgaW4gdGhlIG1vZGVsLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMiBsZm8yIj4NClBsZWFzZSBhZGQgcmVmZXJlbmNl cyB0byB0aGUgbW9kZWxzIHRoYXQgYXJlIGltcG9ydGVkIGludG8gdGhpcyBtb2RlbCBpbiB0aGUg ZHJhZnQgaXRzZWxmLiBUaGV5IGFyZSB0aGVyZSBpbiB0aGUgbW9kZWwsIGJ1dCBub3QgaW4gdGhl IGRyYWZ0IGl0c2VsZi48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28t bGlzdDpsMCBsZXZlbDIgbGZvMiI+DQpIb3cgYWJvdXQgc3VwcG9ydCBmb3IgcmV0cmFuc21pc3Np b24gdGltZW91dCB2YWx1ZSBpbiB0aGUgWUFORyBtb2RlbD88bzpwPjwvbzpwPjwvbGk+PC91bD4N CjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5aVFImZ3Q7IEkgZG8gbm90IHVuZGVyc3RhbmQgdGhpcy4gV2hhdOKAmXMgdGhpcyBzdWdn ZXN0aW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjx1bCB0eXBl PSJjaXJjbGUiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDIgbGZv MiI+DQpDaGFuZ2UgV0cgcmVmZXJlbmNlIHRvICZuYnNwOyZsdDs8YSBocmVmPSJodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL3dnL25ldGNvbmYiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvd2cvbmV0Y29uZjwvYT4mZ3Q7PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzIiPg0KUmVtb3ZlIHRoZSBwcmVmaXgg4oCcbWFpbHRv OuKAnSBJdCBpcyBncmVhdCBpbiBhIEhUTUwgZG9jdW1lbnQsIGJ1dCBkb2VzIG5vdCBoZWxwIGlu IGEgWUFORyBtb2RlbC48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28t bGlzdDpsMCBsZXZlbDIgbGZvMiI+DQpVcGRhdGUgQ29weXJpZ2h0IHllYXIgdG8gMjAyMS48bzpw PjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDIgbGZv MiI+DQpJbmRlbnRhdGlvbnMgYXJlIG9mZiB0aGUgbW9kZWwuIFBsZWFzZSBmaXguPG86cD48L286 cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzIiPg0K SWYgdGhlIGdyb3VwaW5nIOKAnHRhcmdldC1yZWNlaXZlcuKAnSBpcyBub3QgZ29pbmcgdG8gcmV1 c2VkIGFueXdoZXJlIGVsc2UsIHBsZWFzZSByZW1vdmUgaXQgYW5kIGlubGluZSBpdCB3aXRoaW4g dGhlIGF1Z21lbnQgc3RhdGVtZW50LjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC91bD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5aVFImZ3Q7IE90aGVycyByZWNlaXZlZC4gSSB3aWxsIHVwZGF0ZS4gTWFueSB0aGFua3Mh PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+JCBweWFuZyAtZiB0cmVlIDxhIGhyZWY9Im1haWx0bzppZXRmLXVkcC1ub3Rp ZkAyMDIxLTEwLTE4LnlhbmciPg0KaWV0Zi11ZHAtbm90aWZAMjAyMS0xMC0xOC55YW5nPC9hPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGEgaHJlZj0ibWFpbHRvOmlldGYtdWRwLW5vdGlmQDIwMjEtMTAtMTgueWFuZyI+aWV0Zi11ZHAt bm90aWZAMjAyMS0xMC0xOC55YW5nPC9hPjoxMjA6IHdhcm5pbmc6IG5vZGUgJnF1b3Q7aWV0Zi1z dWJzY3JpYmVkLW5vdGlmaWNhdGlvbnM6OnRyYW5zcG9ydCZxdW90OyBpcyBub3QgZm91bmQgaW4g JnF1b3Q7aWV0Zi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnM6OnN1YnNjcmlwdGlvbnPigJ08bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiQgeWFuZ2xpbnQgPGEgaHJlZj0ibWFpbHRvOmlldGYtdWRwLW5vdGlmQDIwMjEtMTAt MTgueWFuZyI+aWV0Zi11ZHAtbm90aWZAMjAyMS0xMC0xOC55YW5nPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bGlieWFuZyB3YXJuOiBTY2hl bWEgbm9kZSAmcXVvdDt0cmFuc3BvcnQmcXVvdDsgZm9yIHBhcmVudCAmcXVvdDsvaWV0Zi1zdWJz Y3JpYmVkLW5vdGlmaWNhdGlvbnM6c3Vic2NyaXB0aW9ucyZxdW90OyBub3QgZm91bmQ7IGluIGV4 cHIgJnF1b3Q7ZGVyaXZlZC1mcm9tKC4uLy4uLy4uL3RyYW5zcG9ydCZxdW90OyB3aXRoIGNvbnRl eHQgbm9kZSAmcXVvdDsvaWV0Zi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnM6c3Vic2NyaXB0aW9u cy9zdWJzY3JpcHRpb24vcmVjZWl2ZXJzL3JlY2VpdmVy4oCdLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rczxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk1haGVzaCBKZXRoYW5hbmRhbmk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5p QGdtYWlsLmNvbSI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4a5c424a36d245b386789b3775cb43dehuaweicom_-- From nobody Mon Nov 8 05:43:47 2021 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 E491B3A0101; Mon, 8 Nov 2021 05:43:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <163637902187.5188.6107387779869949542@ietfa.amsl.com> Date: Mon, 08 Nov 2021 05:43:41 -0800 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-sztp-csr-11.txt 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: Mon, 08 Nov 2021 13:43:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request Authors : Kent Watsen Russ Housley Sean Turner Filename : draft-ietf-netconf-sztp-csr-11.txt Pages : 34 Date : 2021-11-08 Abstract: This draft extends the "get-bootstrapping-data" RPC defined in RFC 8572 to include an optional certificate signing request (CSR), enabling a bootstrapping device to additionally obtain an identity certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the "onboarding information" response provided in the RPC-reply. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-netconf-sztp-csr-11.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-sztp-csr-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 8 05:46:11 2021 Return-Path: <0100017cffcc5158-4d701084-5107-4c8a-bbbc-bee0842e9db8-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 AFA243A0101; Mon, 8 Nov 2021 05:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.818 X-Spam-Level: X-Spam-Status: No, score=-1.818 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=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 CBXeNCknedVs; Mon, 8 Nov 2021 05:46:04 -0800 (PST) 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 300AC3A0B99; Mon, 8 Nov 2021 05:45:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1636379152; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=DcxfcnPJFhKai7+gmkgUg84pBdIFZ2loBJ5YkKdw5XY=; b=khSp3ljUJsWvhgVZsB9fbN3PNJ9eDPUUEAi1FOdiYHxY1K6pi3aPRuJpUo6fRpKA O8bKbmqsoodDv925wM6CmAfazGBRw0GqRHbKYempLT0kGZc4jzoMEOT0osk15/2amxc agKTe6d6yPUFlOEXb6xo2WLNsaKdxYmR68OCunb8= From: Kent Watsen Message-ID: <0100017cffcc5158-4d701084-5107-4c8a-bbbc-bee0842e9db8-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_837C5EBD-81F6-4245-ACED-3862DD163BCA" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Mon, 8 Nov 2021 13:45:52 +0000 In-Reply-To: Cc: "Rob Wilton (rwilton)" , "netconf@ietf.org" , "draft-ietf-netconf-sztp-csr@ietf.org" , "Brockhaus, Hendrik" To: David von Oheimb References: <162907788324.2949.13159388023679125044@ietfa.amsl.com> <0100017b4cb20cee-3638c1d3-c5d0-4417-8cd9-8df5669a2a2b-000000@email.amazonses.com> <6247a309-c24d-041b-704c-2ddf8b372d00@siemens.com> <0100017b551d703e-ea44f163-2ab5-40c3-9edc-c0eb41620172-000000@email.amazonses.com> <0100017b78a75ff9-6506e24d-20c5-4bd7-83a4-0e7472cdfc6e-000000@email.amazonses.com> <7d5059f5-c0b6-390c-99d3-4fcdc13d445d@siemens.com> <0100017b97c879d0-c2cd3be9-a2d3-4e6d-9ed8-16e99432ff4c-000000@email.amazonses.com> <8a40f036-53d0-5c7b-beb2-72a274f86f1c@siemens.com> <0100017ca9f3d18a-18d07b15-002e-4981-8b33-ffa8067b7849-000000@email.amazonses.com> <4b9cb732-422f-06cc-b194-fa39b0a287f6@siemens.com> <0100017cc94f8422-6081654f-87ca-47aa-892b-f6057d8f4ac2-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.11.08-54.240.48.90 Archived-At: Subject: Re: [netconf] Adaptations for draft-ietf-netconf-sztp-csr-09.txt 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, 08 Nov 2021 13:46:09 -0000 --Apple-Mail=_837C5EBD-81F6-4245-ACED-3862DD163BCA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi David, Thanks for catching that. The just-submitted -11 removes that = paragraph. = https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-11 = Cheers, Kent > On Nov 3, 2021, at 8:49 AM, David von Oheimb = wrote: >=20 > Hi Kent, >=20 > thanks for your update. >=20 > The change to section 4.2.1 is fine, > but section 4.2.2 still contains: >=20 >=20 >> When a new asymmetric key is used, proof-or-origin is provided, in >> the CMP and CMC formats, by the CSR's parent ASN.1 structure >> containing origin authentication using either the manufacturer- >> generated private key or a shared secret. > which should be removed. > (The following paragraph, starting with the same words, is an improved = version of it). >=20 > Regards, >=20 > David >=20 >=20 >=20 > On 29.10.21 01:50, Kent Watsen wrote: >> Hi David, >>=20 >> Thank you for your valuable comments. Please find the updated draft = here: >>=20 >> = https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-10 = >>=20 >> And the diff here: >>=20 >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-sztp-csr-10= = >>=20 >> Can you confirm is all your concerns have been addressed? >>=20 >> Thanks, >> Kent >>=20 >>=20 >>=20 >>> On Oct 25, 2021, at 6:42 AM, David von Oheimb = > = wrote: >>>=20 >>> Hi Kent et al., >>>=20 >>> On 10/22/21 23:41, Kent Watsen wrote: >>>>=20 >>>> Updated draft here: = https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-09 = >>>>=20 >>> thanks for your answer and new version 09. >>>=20 >>>=20 >>>=20 >>>>> Regarding the proposed new text of the section "Verifying Proof of = Origin": >>>>>>=20 >>>>>> When the bootstrapping device's = manufacturer-generated=20 >>>>>>=20 >>>>>> private key (e.g., the IDevID key) is reused for the = CSR,=20 >>>>>>=20 >>>>>> proof-of-origin is verified by ensuring the CSR was = signed >>>>>>=20 >>>>>> by that key. >>>>>>=20 >>>>> Hmm, this proof of origin only works if the IDevID has already = been authenticated before by the entity performing the proof - is this = the case? >>>>=20 >>>> Yes. First validate the IDevID (which is readily available) using = the IDevID-issuer cert, then ensure the public key in the CSR is the = same as the public key in the IDevID. >>> I see - so in this case the IDevID has already been enrolled before = and can be used for authentication. >>> Since the details are crucial but rather implicit at this point, it = would be good to state them clearly. >>>=20 >>>> Please OLD/NEW text for how you would like to see it improved. >>> OLD: >>> When the bootstrapping device's manufacturer-generated=20= >>> private key (e.g., the IDevID key) is reused for the = CSR,=20 >>> proof-of-origin is verified by ensuring the CSR was = signed >>> by that key. >>>=20 >>> NEW: >>>=20 >>> When the bootstrapping device's manufacturer-generated=20= >>> private key (e.g., the IDevID key) is reused for the = CSR,=20 >>> proof-of-origin is verified by validating the = IDevID-issuer cert >>> and ensuring that the CSR uses the same key pair. >>>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>>> Concerning the 2nd part of the new section,=20 >>>>> [...] >>>>>=20 >>>>>>=20 >>>>>> When a new asymmetric key is used, proof-or-origin is >>>>>> provided, in the CMP and CMC formats, by the CSR=E2=80=99= s >>>>>> parent ASN.1 structure containing origin = authentication >>>>>> using either the manufacturer-generated private key = or >>>>>> a shared secret. >>>>>>=20 >>>>>=20 >>>>> This text loses the link between POP and POO that I was aiming to = point out with my earlier text. >>>>> Therefore, I propose a further adaptation of this part, as = follows: >>>>>=20 >>>>> When a new asymmetric key is used with the CMP or CMC formats, = the parent ASN.1 structure of the CSR=20 >>>>> provides origin authentication using either the = manufacturer-generated private key or shared secret. >>>>> In this way the proof-of-possession of the CSR is directly = linked to the proof-or-origin provided by the parent ASN.1 structure. >>>>>=20 >>>>=20 >>>> Incorporated. But I added a missing comma and a missing article = (=E2=80=98a=E2=80=99). >>> Thanks. >>> Yet you forgot to remove the OLD text, just before that new = paragraph: >>> When a new asymmetric key is used, proof-or-origin is provided, = in >>> the CMP and CMC formats, by the CSR's parent ASN.1 structure >>> containing origin authentication using either the manufacturer- >>> generated private key or a shared secret. >>>=20 >>>=20 >>> Pleased to note that you added in version version 06 a = "Contributors" section saying: >>>=20 >>> Special thanks goes to David von Oheimb and Hendrik Brockhaus for >>> helping with the descriptions for the "cmc-csr" and "cmp-csr" = nodes. >>>=20 >>> Cheers, >>>=20 >>> David >>>=20 >>>=20 >>=20 --Apple-Mail=_837C5EBD-81F6-4245-ACED-3862DD163BCA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = David,

Thanks for = catching that.  The just-submitted -11 removes that = paragraph.

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-c= sr-11

Cheers,
Kent



On Nov = 3, 2021, at 8:49 AM, David von Oheimb <David.von.Oheimb@siemens.com> wrote:

=20 =20

Hi Kent,

thanks for = your update.

The change to section 4.2.1 is fine,
but section 4.2.2 still contains:


   When a new asymmetric key is used, =
proof-or-origin is provided, in
   the CMP and CMC formats, by the CSR's parent ASN.1 structure
   containing origin authentication using either the manufacturer-
   generated private key or a shared secret.
which should be removed.
(The following paragraph, starting with the same words, is an improved version of it).

Regards,

    David


On 29.10.21 01:50, Kent Watsen = wrote:
Hi David,

Thank you for your valuable comments.  Please = find the updated draft here:

https://datatracker.ietf.org/doc/html/draft-ietf-= netconf-sztp-csr-10

And the diff here:

https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ne= tconf-sztp-csr-10

Can you confirm is all your concerns have been addressed?

Thanks,
Kent



On Oct 25, 2021, at 6:42 AM, David von = Oheimb <David.von.Oheimb@siemens.com> wrote:

Hi Kent et al.,
=

On 10/22/21 23:41, Kent Watsen wrote:

Updated draft here: https://datatracker.ietf.org/doc/html/draft-ietf-= netconf-sztp-csr-09

thanks for your answer and = new version 09.


  • Regarding the proposed new text of the section "Verifying Proof of Origin":

          &nb= sp; When the bootstrapping device's = manufacturer-generated 

          &nb= sp; private key (e.g.,= the IDevID key) is reused for the CSR, 

          &nb= sp; proof-of-origin is verified by ensuring the CSR was signed

          &nb= sp; by that key.

Hmm, this proof of origin only works if the IDevID has already been authenticated before by the entity performing the proof - is this the case?

Yes.  First validate the = IDevID (which is readily available) using the IDevID-issuer cert, then ensure the public key in the CSR is the same as the public key in the IDevID.
I see - so in this case the IDevID has already been enrolled before and can be used for authentication.
Since the details are crucial but rather implicit at this point, it would be good to state them clearly.

Please OLD/NEW text for how you = would like to see it improved.
OLD:

          &nb= sp; When the bootstrapping = device's manufacturer-generated 
=             = private key (e.g., = the IDevID key) is reused for the CSR, 
=             = proof-of-origin is verified by = ensuring the CSR was signed
     =        by that key.

NEW:

          &nb= sp; When the bootstrapping = device's manufacturer-generated 
=             = private key (e.g., = the IDevID key) is reused for the CSR, 
=             = proof-of-origin is verified by = validating the IDevID-issuer= cert
=             and = ensuring that the CSR uses the same = key pair.




Concerning the = 2nd part of the new section,
[...]


        &= nbsp;   When a new asymmetric key is used, proof-or-origin = is
=             = provided, in the CMP and CMC formats, by the = CSR=E2=80=99s
=             = parent ASN.1 = structure containing origin authentication
=             = using either the manufacturer-generated = private key or
=             = a shared = secret.


This text loses the link between POP and POO that I was aiming to point out with my earlier text.
Therefore, I propose a further adaptation of this part, as follows:

    When = a new asymmetric key is used with the CMP or CMC formats, the parent ASN.1 structure of the CSR
    provides origin = authentication using either the manufacturer-generated private key or shared secret.
    In this way the = proof-of-possession of the CSR is directly linked to the proof-or-origin provided by the parent ASN.1 structure.


Incorporated.  But I added a = missing comma and a missing article (=E2=80=98a=E2=80=99).=
Thanks.
Yet you forgot to remove the OLD text, just before that new paragraph:
   When a new asymmetric key is =
used, proof-or-origin is provided, in
   the CMP and CMC formats, by the CSR's parent ASN.1 structure
   containing origin authentication using either the manufacturer-
   generated private key or a shared secret.


Pleased to note that you added in = version version 06 a "Contributors" section saying:

   Special thanks goes to David =
von Oheimb and Hendrik Brockhaus for
   helping with the descriptions for the "cmc-csr" and "cmp-csr" =
nodes.


Cheers,

    David




= --Apple-Mail=_837C5EBD-81F6-4245-ACED-3862DD163BCA-- From nobody Tue Nov 9 03:53:19 2021 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 25C853A0B42; Tue, 9 Nov 2021 03:53:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-netconf-sztp-csr@ietf.org, mjethanandani@gmail.com, netconf-chairs@ietf.org, netconf@ietf.org, rwilton@cisco.com Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <163645879708.7636.14186018456190843256@ietfa.amsl.com> Date: Tue, 09 Nov 2021 03:53:17 -0800 Archived-At: Subject: [netconf] Last Call: (Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request) to Proposed Standard 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: Tue, 09 Nov 2021 11:53:17 -0000 The IESG has received a request from the Network Configuration WG (netconf) to consider the following document: - 'Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-11-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This draft extends the "get-bootstrapping-data" RPC defined in RFC 8572 to include an optional certificate signing request (CSR), enabling a bootstrapping device to additionally obtain an identity certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the "onboarding information" response provided in the RPC-reply. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: draft-ietf-netconf-crypto-types: YANG Data Types and Groupings for Cryptography (None - Internet Engineering Task Force (IETF)) From nobody Tue Nov 9 04:12:01 2021 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 01F0B3A0FD7; Tue, 9 Nov 2021 04:11:58 -0800 (PST) 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 An03HEw4efan; Tue, 9 Nov 2021 04:11:53 -0800 (PST) Received: from smtpout02-ext4.partage.renater.fr (smtpout02-ext4.partage.renater.fr [194.254.241.31]) by ietfa.amsl.com (Postfix) with ESMTP id 43BB63A0FD9; Tue, 9 Nov 2021 04:11:52 -0800 (PST) Received: from zmtaout04.partage.renater.fr (zmtaout04.partage.renater.fr [194.254.241.61]) by smtpout20.partage.renater.fr (Postfix) with ESMTP id 30F1DC0B76; Tue, 9 Nov 2021 13:11:42 +0100 (CET) Received: from zmtaout04.partage.renater.fr (localhost [127.0.0.1]) by zmtaout04.partage.renater.fr (Postfix) with ESMTPS id CAA9714015B; Tue, 9 Nov 2021 13:11:22 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zmtaout04.partage.renater.fr (Postfix) with ESMTP id B988E14015A; Tue, 9 Nov 2021 13:11:22 +0100 (CET) X-Virus-Scanned: amavisd-new at zmtaout04.partage.renater.fr Received: from zmtaout04.partage.renater.fr ([127.0.0.1]) by localhost (zmtaout04.partage.renater.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VmkTjyAKhbRK; Tue, 9 Nov 2021 13:11:22 +0100 (CET) Received: from zstore-b3-033.partage.renater.fr (zstore-b3-033.partage.renater.fr [10.254.241.156]) by zmtaout04.partage.renater.fr (Postfix) with ESMTP id 75BD114010B; Tue, 9 Nov 2021 13:11:22 +0100 (CET) Date: Tue, 9 Nov 2021 13:11:22 +0100 (CET) From: Pierre Francois To: Tianran Zhou Cc: Mahesh Jethanandani , draft-ietf-netconf-udp-notif@ietf.org, Netconf Message-ID: <1033979831.2157206.1636459882397.JavaMail.zimbra@insa-lyon.fr> In-Reply-To: <4a5c424a36d245b386789b3775cb43de@huawei.com> References: <12D5318C-D645-477A-8651-31D4C35C34D4@gmail.com> <4a5c424a36d245b386789b3775cb43de@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Zimbra 8.8.15_GA_4059 (ZimbraWebClient - GC94 (Mac)/8.8.15_GA_4059) Thread-Topic: Review comments on draft-ietf-netconf-udp-notif Thread-Index: AQHX1DyRJA0/gypCuU2KqKtZamET/Kv5cNyAqhAmy0M= X-Renater-Ptge-SpamState: clean X-Renater-Ptge-SpamScore: -100 Archived-At: Subject: Re: [netconf] Review comments on draft-ietf-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, 09 Nov 2021 12:11:58 -0000 Hello Tianran, Mahesh,=20 Thank you for the comprehensive review.=20 Inline PFR> ----- Mail original ----- > De: "Tianran Zhou" > =C3=80: "Mahesh Jethanandani" , draft-ietf-netco= nf-udp-notif@ietf.org > Cc: "Netconf" > Envoy=C3=A9: Lundi 8 Novembre 2021 13:36:50 > Objet: RE: Review comments on draft-ietf-netconf-udp-notif > Hi Mahesh, >=20 > Thanks very much for your detailed review and comments. > Please see in line for my reply. >=20 > Cheers, > Tianran >=20 > From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com] > Sent: Monday, November 8, 2021 6:21 AM > To: draft-ietf-netconf-udp-notif@ietf.org > Cc: Netconf > Subject: Review comments on draft-ietf-netconf-udp-notif >=20 > Hi authors of draft-ietf-netconf-udp-notif, >=20 > Here are some of my comments on the -04 version of the draft. >=20 > Nits: >=20 > * Please give the draft a more descriptive description for the short t= itle > rather than unyte-udp-notif. Something like "UDP-based Subscription=E2= =80=9D. > * S/DTLS is layered next tot/DTLS is layered on top of/ > ZTR> I agree with your suggestions. >=20 > Comments (major and minor): >=20 >=20 > * In Section 1 there is an inherent assumption that the network > processors/line cards have network access to the receiver. I think that > requirement needs to be made explicit. Otherwise, routing all messages t= hrough > an internal consolidator might be the only option. BTW, I believe the op= tion to > route notification messages through a internal consolidator should be ke= pt as > an option for UDP transport in case the line cards cannot route out of t= he box. > ZTR>Yes, it=E2=80=99s a good suggestion. I will add this to the new revis= ion. >=20 > * In Section 2, it is not clear who is responsible for sending the > notification to the publisher that the receiver is ready to receive > notifications. > ZTR> I am sorry, I do not remember the configure subscription clear. What= =E2=80=99s > defined generic in RFC8639 about how the publisher know the receiver? Or = the > publisher does not need to deal with this anyway? >=20 > * In Section 3.1, TLS is specified as a transport protocol. I think yo= u mean > TCP or HTTP2 over TCP. > ZTR> This I would like to leave it to Pierre. PFR> I'm afraid I don't understand the comment. >=20 > * There is use of term =E2=80=99notification message=E2=80=9D and =E2= =80=9CNotification Messages=E2=80=9D. > What is the difference? If you are using a pre-defined term, can you add= a > definition and nomenclature section that brings in the reference. If you= are > defining a new term, can you add a definition in the document. > ZTR> In my opinion, no difference. I would like to add a ref from existin= g > definition. >=20 > * In Section 3.2, it is better for the Ver field to have an initial ve= rsion of > 1 instead of 0 to distinguish from a value that my not have been set. > ZTR> Is this normal? I do not mind to do this. >=20 > * Section 6.1. Not clear on the statement =E2=80=9CSince UDP is an unr= eliable > transport, with DTLS, an originator or a relay may not realize ..=E2=80= =9D. What has > DTLS got to do with the unreliability of the transport protocol? > ZTR> This I would like to leave it to Pierre. PFR> What this means is that you don't get to know whether what you produce= d as an originator=20 got consumed by the receiver, as you would using a connection oriented tran= sport. Actually,=20 it's obvious so we may want to remove this paragraph. The intent was to not= have the reader think=20 dtls changes things compared to basic udp transport. Cheers,=20 Pierre. >=20 > * Section 6.2. Is the draft asking for assignment of a well known port= for UDP > based transport? > ZTR> Yes. This is what we request from IANA. >=20 > * Section 8. >=20 > * Has the model been compiled with pyang and yanglint? See compilat= ion outputs > below. > ZTR> I noticed this. But it seems from =E2=80=9Cietf-subscribed-notificat= ions=E2=80=9D. Do you > know what=E2=80=99s happened? > I also noticed the datatracker shows 4 errors. It seems the same errors e= xist in > draft-ietf-netconf-https-notif. Could anyone help on this? >=20 > * File name has a date that is different from the revision date in = the model. > * Please add references to the models that are imported into this m= odel in the > draft itself. They are there in the model, but not in the draft itsel= f. > * How about support for retransmission timeout value in the YANG mo= del? > ZTR> I do not understand this. What=E2=80=99s this suggestion? >=20 > * Change WG reference to > * Remove the prefix =E2=80=9Cmailto:=E2=80=9D It is great in a HTML= document, but does not > help in a YANG model. > * Update Copyright year to 2021. > * Indentations are off the model. Please fix. > * If the grouping =E2=80=9Ctarget-receiver=E2=80=9D is not going to= reused anywhere else, > please remove it and inline it within the augment statement. > ZTR> Others received. I will update. Many thanks! >=20 > $ pyang -f tree > ietf-udp-notif@2021-10-18.yang > ietf-udp-notif@2021-10-18.yang:120= : > warning: node "ietf-subscribed-notifications::transport" is not found in > "ietf-subscribed-notifications::subscriptions=E2=80=9D > $ yanglint ietf-udp-notif@2021-10-18.yang > libyang warn: Schema node "transport" for parent > "/ietf-subscribed-notifications:subscriptions" not found; in expr > "derived-from(../../../transport" with context node > "/ietf-subscribed-notifications:subscriptions/subscription/receivers/rece= iver=E2=80=9D. >=20 > Thanks >=20 > Mahesh Jethanandani > mjethanandani@gmail.com From nobody Tue Nov 9 14:05:07 2021 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 695333A08F6; Tue, 9 Nov 2021 14:05:04 -0800 (PST) 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 V1sbBEyagSXj; Tue, 9 Nov 2021 14:04:59 -0800 (PST) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 2BB7D3A11B2; Tue, 9 Nov 2021 14:04:59 -0800 (PST) Received: by mail-pg1-x532.google.com with SMTP id g28so381093pgg.3; Tue, 09 Nov 2021 14:04:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=HdA6hvq1F9GtsFzycy+qbfi24La79EFMALq5IxQbs0g=; b=qfYJtxOu0mV8kCnB2ii/W+EmkC5fSmMKE5QYxmKN+vBStxyLsC7/QE9TOhAI+2vSfJ YBpuJn55q5Qf0nZpv+9pOtHwC/mmZexnITxYZFSkbGcQkj5FuuF7Z7WGa1O9qlbI/4pw ps8aWNQ3qRH8ZE86Nat+ZxlFQDPb1mQuLKtZlt1QV1XXXKz4yiodYwEeI+vHENOTerlb +9wlCAy/Kb5koCRdsiyxqMWkw6wXUsWZCCc+HoOFIBkjAnKVdrM6f7fC23tlC1SJOzaH Hv4xxeilPCRNI1QBHYYHw6nTJh6h3iAE+v0qPjTEKZHN2GSSvvBWSAbo+MEAJeDgj+s0 vrJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=HdA6hvq1F9GtsFzycy+qbfi24La79EFMALq5IxQbs0g=; b=o/cj2yPvKHKe39ckLhpXEhUCP5cbvXydmVR0uP2jYqhdlSmlDSepljRReOwCdB7wep 7SzJzXvnoZEVYu0s05XhqvcsgTaSExme96Je+uEOnDWGWspaNFWNIqIaiCZHgVez3bAT FDmHVbeJOI/6125NBz37x43u1F0IaZT5cB8mvg8I/WkWwBd8wRLQywpcIGwJMF20kbL6 AolMfoHgO0mRbM8fepu+h5CeDPSBffwBqXB5of0ZI8bZYLK3haigGgmn0ePMtOCOGwOJ YQGd+Cni2yicIde8TkszJzGGLCWfgp2TdkdeFVPkkMmFAuSf5vcQOq24gAJCX0yjlBPj sssQ== X-Gm-Message-State: AOAM530+YTRaNPbLaiqxoBPbvEPKNMqkkWtrHurIVFEaOreD5RlSvSzH B16EjlGdOilPkFkp03UTszE= X-Google-Smtp-Source: ABdhPJy1BCRLGpU7j8qr889bRZ+zl+/knd0m4yLLvrioQtxtRGXUroIBGe2RsGL3akTn3AMpbAUz9Q== X-Received: by 2002:a05:6a00:8d0:b0:44c:26e6:1c13 with SMTP id s16-20020a056a0008d000b0044c26e61c13mr11696286pfu.28.1636495497850; Tue, 09 Nov 2021 14:04:57 -0800 (PST) Received: from nangal.nikung.org (c-69-181-169-15.hsd1.ca.comcast.net. [69.181.169.15]) by smtp.gmail.com with ESMTPSA id a8sm4032833pfv.176.2021.11.09.14.04.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Nov 2021 14:04:57 -0800 (PST) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A21870C8-66F2-483A-8767-C9DDD12796E4" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Tue, 9 Nov 2021 14:05:10 -0800 In-Reply-To: <1033979831.2157206.1636459882397.JavaMail.zimbra@insa-lyon.fr> Cc: Tianran Zhou , draft-ietf-netconf-udp-notif@ietf.org, Netconf To: Pierre Francois References: <12D5318C-D645-477A-8651-31D4C35C34D4@gmail.com> <4a5c424a36d245b386789b3775cb43de@huawei.com> <1033979831.2157206.1636459882397.JavaMail.zimbra@insa-lyon.fr> X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [netconf] Review comments on draft-ietf-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, 09 Nov 2021 22:05:05 -0000 --Apple-Mail=_A21870C8-66F2-483A-8767-C9DDD12796E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Pierre, See inline with [mj] > On Nov 9, 2021, at 4:11 AM, Pierre Francois = wrote: >=20 > Hello Tianran, Mahesh,=20 >=20 > Thank you for the comprehensive review.=20 >=20 > Inline PFR> >=20 > ----- Mail original ----- >> De: "Tianran Zhou" >> =C3=80: "Mahesh Jethanandani" , = draft-ietf-netconf-udp-notif@ietf.org >> Cc: "Netconf" >> Envoy=C3=A9: Lundi 8 Novembre 2021 13:36:50 >> Objet: RE: Review comments on draft-ietf-netconf-udp-notif >=20 >> Hi Mahesh, >>=20 >> Thanks very much for your detailed review and comments. >> Please see in line for my reply. >>=20 >> Cheers, >> Tianran >>=20 >> From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com] >> Sent: Monday, November 8, 2021 6:21 AM >> To: draft-ietf-netconf-udp-notif@ietf.org >> Cc: Netconf >> Subject: Review comments on draft-ietf-netconf-udp-notif >>=20 >> Hi authors of draft-ietf-netconf-udp-notif, >>=20 >> Here are some of my comments on the -04 version of the draft. >>=20 >> Nits: >>=20 >> * Please give the draft a more descriptive description for the = short title >> rather than unyte-udp-notif. Something like "UDP-based = Subscription=E2=80=9D. >> * S/DTLS is layered next tot/DTLS is layered on top of/ >> ZTR> I agree with your suggestions. >>=20 >> Comments (major and minor): >>=20 >>=20 >> * In Section 1 there is an inherent assumption that the network >> processors/line cards have network access to the receiver. I think = that >> requirement needs to be made explicit. Otherwise, routing all = messages through >> an internal consolidator might be the only option. BTW, I believe the = option to >> route notification messages through a internal consolidator should be = kept as >> an option for UDP transport in case the line cards cannot route out = of the box. >> ZTR>Yes, it=E2=80=99s a good suggestion. I will add this to the new = revision. >>=20 >> * In Section 2, it is not clear who is responsible for sending the >> notification to the publisher that the receiver is ready to receive >> notifications. >> ZTR> I am sorry, I do not remember the configure subscription clear. = What=E2=80=99s >> defined generic in RFC8639 about how the publisher know the receiver? = Or the >> publisher does not need to deal with this anyway? >>=20 >> * In Section 3.1, TLS is specified as a transport protocol. I think = you mean >> TCP or HTTP2 over TCP. >> ZTR> This I would like to leave it to Pierre. >=20 > PFR> I'm afraid I don't understand the comment. [mj] TLS is a cryptographic protocol, not a transport protocol.=20 >=20 >>=20 >> * There is use of term =E2=80=99notification message=E2=80=9D and = =E2=80=9CNotification Messages=E2=80=9D. >> What is the difference? If you are using a pre-defined term, can you = add a >> definition and nomenclature section that brings in the reference. If = you are >> defining a new term, can you add a definition in the document. >> ZTR> In my opinion, no difference. I would like to add a ref from = existing >> definition. >>=20 >> * In Section 3.2, it is better for the Ver field to have an initial = version of >> 1 instead of 0 to distinguish from a value that my not have been set. >> ZTR> Is this normal? I do not mind to do this. >>=20 >> * Section 6.1. Not clear on the statement =E2=80=9CSince UDP is an = unreliable >> transport, with DTLS, an originator or a relay may not realize ..=E2=80= =9D. What has >> DTLS got to do with the unreliability of the transport protocol? >> ZTR> This I would like to leave it to Pierre. >=20 > PFR> What this means is that you don't get to know whether what you = produced as an originator=20 > got consumed by the receiver, as you would using a connection oriented = transport. Actually,=20 > it's obvious so we may want to remove this paragraph. The intent was = to not have the reader think=20 > dtls changes things compared to basic udp transport. Ok. Thanks >=20 > Cheers,=20 >=20 > Pierre. >=20 >=20 >>=20 >> * Section 6.2. Is the draft asking for assignment of a well known = port for UDP >> based transport? >> ZTR> Yes. This is what we request from IANA. >>=20 >> * Section 8. >>=20 >> * Has the model been compiled with pyang and yanglint? See = compilation outputs >> below. >> ZTR> I noticed this. But it seems from = =E2=80=9Cietf-subscribed-notifications=E2=80=9D. Do you >> know what=E2=80=99s happened? >> I also noticed the datatracker shows 4 errors. It seems the same = errors exist in >> draft-ietf-netconf-https-notif. Could anyone help on this? >>=20 >> * File name has a date that is different from the revision date = in the model. >> * Please add references to the models that are imported into = this model in the >> draft itself. They are there in the model, but not in the draft = itself. >> * How about support for retransmission timeout value in the YANG = model? >> ZTR> I do not understand this. What=E2=80=99s this suggestion? >>=20 >> * Change WG reference to = >> * Remove the prefix =E2=80=9Cmailto:=E2=80=9D It is great in a = HTML document, but does not >> help in a YANG model. >> * Update Copyright year to 2021. >> * Indentations are off the model. Please fix. >> * If the grouping =E2=80=9Ctarget-receiver=E2=80=9D is not going = to reused anywhere else, >> please remove it and inline it within the augment statement. >> ZTR> Others received. I will update. Many thanks! >>=20 >> $ pyang -f tree >> ietf-udp-notif@2021-10-18.yang = > >> ietf-udp-notif@2021-10-18.yang = >:120: >> warning: node "ietf-subscribed-notifications::transport" is not found = in >> "ietf-subscribed-notifications::subscriptions=E2=80=9D >> $ yanglint ietf-udp-notif@2021-10-18.yang = > >> libyang warn: Schema node "transport" for parent >> "/ietf-subscribed-notifications:subscriptions" not found; in expr >> "derived-from(../../../transport" with context node >> = "/ietf-subscribed-notifications:subscriptions/subscription/receivers/recei= ver=E2=80=9D. >>=20 >> Thanks >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com = > Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_A21870C8-66F2-483A-8767-C9DDD12796E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Pierre,

See inline = with [mj]

On Nov 9, 2021, at 4:11 AM, Pierre Francois = <pierre.francois@insa-lyon.fr> wrote:

Hello Tianran, Mahesh, 

Thank you for the comprehensive = review. 

Inline PFR>

----- Mail original = -----
De: = "Tianran Zhou" <zhoutianran@huawei.com>
=C3=80: "Mahesh = Jethanandani" <mjethanandani@gmail.com>, draft-ietf-netconf-udp-notif@ietf.org
Cc: = "Netconf" <netconf@ietf.org>
Envoy=C3=A9: Lundi 8 = Novembre 2021 13:36:50
Objet: RE: Review comments on = draft-ietf-netconf-udp-notif

Hi = Mahesh,

Thanks very much for your detailed = review and comments.
Please see in line for my reply.

Cheers,
Tianran

From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com]
Sent: = Monday, November 8, 2021 6:21 AM
To: draft-ietf-netconf-udp-notif@ietf.org
Cc: = Netconf <netconf@ietf.org>
Subject: Review = comments on draft-ietf-netconf-udp-notif

Hi = authors of draft-ietf-netconf-udp-notif,

Here= are some of my comments on the -04 version of the draft.

Nits:

* =   Please give the draft a more descriptive description for the = short title
rather than unyte-udp-notif. Something like = "UDP-based Subscription=E2=80=9D.
*   S/DTLS is = layered next tot/DTLS is layered on top of/
ZTR> I = agree with your suggestions.

Comments = (major and minor):


* =   In Section 1 there is an inherent assumption that the = network
processors/line cards have network access to the = receiver. I think that
requirement needs to be made = explicit. Otherwise, routing all messages through
an = internal consolidator might be the only option. BTW, I believe the = option to
route notification messages through a internal = consolidator should be kept as
an option for UDP transport = in case the line cards cannot route out of the box.
ZTR>Yes, it=E2=80=99s a good suggestion. I will add this = to the new revision.

*   In = Section 2, it is not clear who is responsible for sending the
notification to the publisher that the receiver is ready to = receive
notifications.
ZTR> I am sorry, I = do not remember the configure subscription clear. What=E2=80=99s
defined generic in RFC8639 about how the publisher know the = receiver? Or the
publisher does not need to deal with this = anyway?

*   In Section 3.1, TLS = is specified as a transport protocol. I think you mean
TCP = or HTTP2 over TCP.
ZTR> This I would like to leave it = to Pierre.

PFR> I'm afraid I don't understand the comment.

[mj] TLS is a = cryptographic protocol, not a transport protocol. 



*   There is use of term =E2=80=99notification = message=E2=80=9D and =E2=80=9CNotification Messages=E2=80=9D.
What is the difference? If you are using a pre-defined term, = can you add a
definition and nomenclature section that = brings in the reference. If you are
defining a new term, = can you add a definition in the document.
ZTR> In my = opinion, no difference. I would like to add a ref from existing
definition.

*   In = Section 3.2, it is better for the Ver field to have an initial version = of
1 instead of 0 to distinguish from a value that my not = have been set.
ZTR> Is this normal? I do not mind to do = this.

*   Section 6.1. Not clear = on the statement =E2=80=9CSince UDP is an unreliable
transport, with DTLS, an originator or a relay may not = realize ..=E2=80=9D. What has
DTLS got to do with the = unreliability of the transport protocol?
ZTR> This I = would like to leave it to Pierre.

PFR> What this means is that = you don't get to know whether what you produced as an originator 
got consumed by the receiver, as = you would using a connection oriented transport. Actually, 
it's obvious so we may want to = remove this paragraph. The intent was to not have the reader think 
dtls changes things compared to = basic udp transport.

Ok.

Thanks


Cheers, 

Pierre.



*   Section 6.2. Is the draft asking for assignment = of a well known port for UDP
based transport?
ZTR> Yes. This is what we request from IANA.

*   Section 8.

   *   Has the model been compiled = with pyang and yanglint? See compilation outputs
   below.
ZTR> I noticed = this. But it seems from =E2=80=9Cietf-subscribed-notifications=E2=80=9D. = Do you
know what=E2=80=99s happened?
I also = noticed the datatracker shows 4 errors. It seems the same errors exist = in
draft-ietf-netconf-https-notif. Could anyone help on = this?

   *   File = name has a date that is different from the revision date in the = model.
   *   Please add = references to the models that are imported into this model in the
   draft itself. They are there in the model, = but not in the draft itself.
   * =   How about support for retransmission timeout value in the = YANG model?
ZTR> I do not understand this. What=E2=80=99s= this suggestion?

   * =   Change WG reference to  <https://datatracker.ietf.org/wg/netconf>
   *   Remove the prefix = =E2=80=9Cmailto:=E2=80=9D It is great in a HTML document, but does = not
   help in a YANG model.
   *   Update Copyright year to = 2021.
   *   Indentations are off = the model. Please fix.
   *   If = the grouping =E2=80=9Ctarget-receiver=E2=80=9D is not going to reused = anywhere else,
   please remove it and = inline it within the augment statement.
ZTR> Others = received. I will update. Many thanks!

$ = pyang -f tree
ietf-udp-notif@2021-10-18.yang<mailto:ietf-udp-notif@2021-10-18.yang>
ietf-udp-notif@2021-10-18.yang<mailto:ietf-udp-notif@2021-10-18.yang>:120:
warning: node "ietf-subscribed-notifications::transport" is = not found in
"ietf-subscribed-notifications::subscriptions=E2=80=9D
$ yanglint ietf-udp-notif@2021-10-18.yang<mailto:ietf-udp-notif@2021-10-18.yang>
libyang warn: Schema node "transport" for parent
"/ietf-subscribed-notifications:subscriptions" not found; in = expr
"derived-from(../../../transport" with context = node
"/ietf-subscribed-notifications:subscriptions/subscription/rece= ivers/receiver=E2=80=9D.

Thanks

Mahesh Jethanandani
mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>

Mahesh Jethanandani



= --Apple-Mail=_A21870C8-66F2-483A-8767-C9DDD12796E4-- From nobody Tue Nov 9 23:34:07 2021 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 B051B3A1348; Tue, 9 Nov 2021 23:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5Y91HI4iX-B; Tue, 9 Nov 2021 23:34:00 -0800 (PST) Received: from smtpout02-ext4.partage.renater.fr (smtpout02-ext4.partage.renater.fr [194.254.241.31]) by ietfa.amsl.com (Postfix) with ESMTP id DBA5E3A12B5; Tue, 9 Nov 2021 23:33:58 -0800 (PST) Received: from zmtaout04.partage.renater.fr (zmtaout04.partage.renater.fr [194.254.241.61]) by smtpout20.partage.renater.fr (Postfix) with ESMTP id 8C303BFCAA; Wed, 10 Nov 2021 08:33:52 +0100 (CET) Received: from zmtaout04.partage.renater.fr (localhost [127.0.0.1]) by zmtaout04.partage.renater.fr (Postfix) with ESMTPS id 7941B140122; Wed, 10 Nov 2021 08:33:52 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zmtaout04.partage.renater.fr (Postfix) with ESMTP id 6D032140113; Wed, 10 Nov 2021 08:33:52 +0100 (CET) X-Virus-Scanned: amavisd-new at zmtaout04.partage.renater.fr Received: from zmtaout04.partage.renater.fr ([127.0.0.1]) by localhost (zmtaout04.partage.renater.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ALojmoFWkMQB; Wed, 10 Nov 2021 08:33:52 +0100 (CET) Received: from zstore-b3-033.partage.renater.fr (zstore-b3-033.partage.renater.fr [10.254.241.156]) by zmtaout04.partage.renater.fr (Postfix) with ESMTP id 25DD514010A; Wed, 10 Nov 2021 08:33:52 +0100 (CET) Date: Wed, 10 Nov 2021 08:33:52 +0100 (CET) From: Pierre Francois To: Mahesh Jethanandani Cc: Tianran Zhou , draft-ietf-netconf-udp-notif , Netconf Message-ID: <584001588.2945351.1636529632081.JavaMail.zimbra@insa-lyon.fr> In-Reply-To: References: <12D5318C-D645-477A-8651-31D4C35C34D4@gmail.com> <4a5c424a36d245b386789b3775cb43de@huawei.com> <1033979831.2157206.1636459882397.JavaMail.zimbra@insa-lyon.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_cafd83d1-71b1-4f35-8fb7-abd11e25ba07" X-Mailer: Zimbra 8.8.15_GA_4059 (ZimbraWebClient - GC94 (Mac)/8.8.15_GA_4059) Thread-Topic: Review comments on draft-ietf-netconf-udp-notif Thread-Index: IGK+emIstm9as3LkFZjReaBAAaotIg== X-Renater-Ptge-SpamState: clean X-Renater-Ptge-SpamScore: -100 Archived-At: Subject: Re: [netconf] Review comments on draft-ietf-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: Wed, 10 Nov 2021 07:34:06 -0000 --=_cafd83d1-71b1-4f35-8fb7-abd11e25ba07 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mahesh,=20 >>> * In Section 3.1, TLS is specified as a transport protocol. I think you= mean >>> TCP or HTTP2 over TCP. >>> ZTR> This I would like to leave it to Pierre. >> PFR> I'm afraid I don't understand the comment. > [mj] TLS is a cryptographic protocol, not a transport protocol. Haha ok right I'll make sure we are precise there.=20 >>> * Section 6.1. Not clear on the statement =E2=80=9CSince UDP is an unre= liable >>> transport, with DTLS, an originator or a relay may not realize ..=E2=80= =9D. What has >>> DTLS got to do with the unreliability of the transport protocol? >>> ZTR> This I would like to leave it to Pierre. >> PFR> What this means is that you don't get to know whether what you prod= uced as >> an originator >> got consumed by the receiver, as you would using a connection oriented >> transport. Actually, >> it's obvious so we may want to remove this paragraph. The intent was to = not have >> the reader think >> dtls changes things compared to basic udp transport. > Ok. Great.=20 Thanks again for the review,=20 Cheers,=20 Pierre.=20 --=_cafd83d1-71b1-4f35-8fb7-abd11e25ba07 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Mahesh, 


*   In Section 3.1, TLS is specified as a trans= port protocol. I think you mean
TCP or HTTP2 over TCP.
ZTR> This I would like to leave it to Pierre.

PFR> I'm afraid I= don't understand the comment.

[mj] TLS is a cryptographic p= rotocol, not a transport protocol. 


Haha ok right I'll make sure we are pre= cise there. 




*   Section 6.1. Not clear on the statement =E2=80=9CSince = UDP is an unreliable
transport, with DTLS, an originator or a= relay may not realize ..=E2=80=9D. What has
DTLS got to do w= ith the unreliability of the transport protocol?
ZTR> This= I would like to leave it to Pierre.

PFR> What this means is that you do= n't get to know whether what you produced as an originator
got consumed by the receiver, as you w= ould using a connection oriented transport. Actually,
it's obvious so we may want to remove this p= aragraph. The intent was to not have the reader think
dtls changes things compared to basic udp tr= ansport.

Ok.

Gre= at. 
Thanks again for the review, 

Cheers, 

=
Pierre.
--=_cafd83d1-71b1-4f35-8fb7-abd11e25ba07-- From nobody Thu Nov 11 12:40:20 2021 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 868D13A0E23 for ; Thu, 11 Nov 2021 12:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.618 X-Spam-Level: X-Spam-Status: No, score=-9.618 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_NONE=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=lip0yLSl; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=u4rOzv/I Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17OWxyJGZhxJ for ; Thu, 11 Nov 2021 12:40:13 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8F1C3A0E1F for ; Thu, 11 Nov 2021 12:40:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2867; q=dns/txt; s=iport; t=1636663213; x=1637872813; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=i/fkwdIrC6Nan2X7caluonG4wzT4pCVRbR7SF/UAPxA=; b=lip0yLSlqwB2jCyy0uAZRUzn9iVTkNMg6qkKNqNYXD6Yab6cLL2ci77V Bz+4iF/qYySEia1X7Q+uoMqfgScIy4OvN/9XQyZKdeUyirwJPlzDqaTnP aYqKKqy5W+rYWQfkQscT+WnTATlrWDb+1UUxOKeOWW2RUdVOq07zNLC8k Y=; IronPort-PHdr: =?us-ascii?q?A9a23=3AwmJrzhU4a8KB7OHx1oYqxZoq4hLV8K36AWYlg?= =?us-ascii?q?6HPw5pCcaWmqpLlOkGXpfBgl0TAUoiT7fVYw/HXvKbtVS1lg96BvXkOfYYKW?= =?us-ascii?q?0oDjsMbzAAlCdSOXEv8KvOiZicmHcNEAVli+XzzMUVcFMvkIVPIpXjn5j8JE?= =?us-ascii?q?RK5Pg1wdYzI?= IronPort-Data: =?us-ascii?q?A9a23=3AvursVqohaqpyWdqmln3OYPPQCPJeBmIEZxIvg?= =?us-ascii?q?KrLsJaIsI4StFCztgarIBmDaKyIYmSgLdAjbIq0/E8Eu5XSxt9gTABrrS9jQ?= =?us-ascii?q?i9DouPIVI+TRqvS04x+DSFioHqKZKzyU/GYRCwPZiKa9kjF3oTJ9yEmjPjRH?= =?us-ascii?q?+OkUYYoBwgoLeNaYHZ54f5cs7ZRbr5A2bBVMivV0T/Ai5S31GyNg1aYBlkpB?= =?us-ascii?q?5er83uDihhdVAQw5TTSbdgT1LPXeuJ84Jg3fcldJFOgKmVY83LTegrN8F251?= =?us-ascii?q?juxExYFENiplPPwdVcHB++UNgmVgX0QUK+n6vRAjnVtieBga7xNMgEO12jhc?= =?us-ascii?q?9NZkL2hsbSyTQYvMqfIkcwWUgJTFGd1OqguFLrvcCbk6ZHNkBabG5fr67A0Z?= =?us-ascii?q?K0sBqUe9/p8BmdA3f0VND5LaQqM799aaprTpvJEnM8vKozgO5kS/yAmxjDCB?= =?us-ascii?q?vFgSpfGK5gmLORwhF8Y7v2i196HDybBVQdSUQ=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A3paudqC2VQaeHo7lHej1sseALOsnbusQ8z?= =?us-ascii?q?AXPh9KKCC9I/b3qynxppsmPEfP+UossOlJo6HABEDyewKiyXcT2/hQAV7CZn?= =?us-ascii?q?iphILMFuFfBOTZskXd8kHFh4tgPOJbAtVD4b7LfBtHZKTBkXKF+r8bqbHtms?= =?us-ascii?q?3F9ISurUuFDzsaEZ2IhD0JbTpzZ3cGPTWucqBJcqZ0iPA3wwaISDAyVICWF3?= =?us-ascii?q?MFV+/Mq5ngj5T9eyMLABYh9U2nkS6owKSSKWnb4j4uFxd0hZsy+2nMlAL0oo?= =?us-ascii?q?+5teug9xPa32jPq7xLhdrazMdZDsDksLlRFtyssHftWG1SYczFgNkHmpD31L?= =?us-ascii?q?/sqqiVn/4UBbU115oWRBDvnfKi4Xi77N9k0Q6d9bbRuwqTnSW+fkNmNyKE7r?= =?us-ascii?q?gpLScwLCEbzY1BOetwrhGknosSAhXakCvn4d/UExlsi0qvuHIn1fUelnpFTO?= =?us-ascii?q?IlGfJsRRx2xjIkLH4sJlOw1GkcKpglMCgc3ocgTXqKK3TC+mV/yt2lWXo+Wh?= =?us-ascii?q?+AX0gZo8SQlzxbhmpwwUcUzNEW2i5ozuNzd7BUo+Dfdqh4nrBHScEbKap7Ge?= =?us-ascii?q?caWMOyTmjAWwjFPm6eKUnuUKsHJ3XOoZjq56hd3pDnRLUYiJ8p3JjRWlJRsm?= =?us-ascii?q?A/P0roFM2VxZVOtgvARW2sNA6dgv22J6IJ84EUaICbRBFreWpe5fdI+c9vcP?= =?us-ascii?q?Ezc8zDTK5rPw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CEBwCwfo1h/5FdJa1aHgEBCxIMQIF?= =?us-ascii?q?OC4FSUQd3WjcxiA4DhTmFDl2CJQObDIEugSUDVAsBAQENAQE3CgQBAYUEAoJ?= =?us-ascii?q?bAiU0CQ4BAgQBAQESAQEFAQEBAgEGBIERE4VoDYZCAQEBAQIBEigGAQE4BAs?= =?us-ascii?q?CASAeEDIlAgQTGweCTwGCVQMOIQEOoQABgToCih94gTOBAYIIAQEGBASBOgI?= =?us-ascii?q?OQUaCORiCNQMGgTqDDIJ8VIdQJxyBSUSBPByGCAEBAQEBF4Eug2eCLo8hgTA?= =?us-ascii?q?EUQEBFH1NCkoILpF+IIxln1AKgzgFikuUMQUtg2yLc5dNlhRVjB+UBghjAYQ?= =?us-ascii?q?dAgQCBAUCDgEBBoFhO4FZcBUaSwGCPj4TGQ+OIINyhRSFSnQCNgIGCwEBAwm?= =?us-ascii?q?PdAEB?= X-IronPort-AV: E=Sophos;i="5.87,226,1631577600"; d="scan'208";a="963056735" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Nov 2021 20:40:11 +0000 Received: from mail.cisco.com (xbe-aln-007.cisco.com [173.36.7.22]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 1ABKeB9H008828 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Thu, 11 Nov 2021 20:40:11 GMT Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xbe-aln-007.cisco.com (173.36.7.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 11 Nov 2021 14:40:11 -0600 Received: from xfe-aln-002.cisco.com (173.37.135.122) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 11 Nov 2021 14:40:11 -0600 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Thu, 11 Nov 2021 14:40:10 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YxrdwpLJ7SCW7tHQ8px60NDrS0W76dMrD9UnKgryJfBYCMUx1FFzGkTj9vkhzBn+FgRpIT6fM5ovg3BtYT9lYkS6j6keEWLJAowCs3kpID7JdvuSrHn/YG8NxFKakzwMWj9020g6vzFJVyw1xHihEeJ8Beq1RYn7TieBSAAljBtxgVSMBSQobMTuoPAmSNi6N9UO0wRshTA/JZ+pLAxBbSD1RC2zmTVxKLfrxa2cZJujRMVmClBeUWtOww+QTbHxNmlJqVbUTm9KdzQa0XPRIeva4as0Gqbh7hQuyV1Ab7AwS0NxTWkmeWAKXAoBeYXEtz81q0hta863dI2HFDhrUw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MzXyHxObKWMLMea9CKtyCucTJckEP4RR2rm7QFpfxCk=; b=eYchAoQnmA2iO2a9XdKe3vFcpBWtxIXOXh0ZRd1yARQHmryVvM6NJOft/mzQuZYAy0VAWoRsGILj3hb2P0owh4nQAqnVYDq0csLCR8xlhq9MQ//sIGG4cSOm/TI9b+vw9CAoeWetl7jSntc3tYwa+Kik/AcU+ZfEuix5kqtb34hsMddkbz8hSz/bNNr7zQpQIbMh6EhXNDyKYZkH9AMQ6BmWpiWV8na15+gGtFVADhASFgNeUTUaTJE0cjJWFsXBVOxrVzPNn2Xn8d+MF9ASY2s/9AbirUunmsf94AwYXmM446qbuV2RueOmG190AlbTwLXBq+90ac8S/k8g/l91PQ== 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=MzXyHxObKWMLMea9CKtyCucTJckEP4RR2rm7QFpfxCk=; b=u4rOzv/I+kN2xFPJ/Y0FgcLgu8x0QtrINgcXgG0r4b7U55kfPLir56hx3DDFEVUwE4oLylwu6K+CGHzOjNU5WYlKVQI6OJgoOY1JJROXKhPIyTmLuY4L211jdntAemE2zEoAt2vxSJI0fUXecmrkMy3KJ1Ei0B0YIzpZy3gv1nw= Received: from DM6PR11MB2841.namprd11.prod.outlook.com (2603:10b6:5:c8::32) by DM5PR11MB1835.namprd11.prod.outlook.com (2603:10b6:3:114::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.19; Thu, 11 Nov 2021 20:40:09 +0000 Received: from DM6PR11MB2841.namprd11.prod.outlook.com ([fe80::74cd:ce34:6dcb:11b4]) by DM6PR11MB2841.namprd11.prod.outlook.com ([fe80::74cd:ce34:6dcb:11b4%7]) with mapi id 15.20.4669.016; Thu, 11 Nov 2021 20:40:09 +0000 From: "Jan Lindblad (jlindbla)" To: Netconf Thread-Topic: Open question 1/4 "Etag values" in draft-lindblad-netconf-transaction-id-01.txt Thread-Index: AQHX1zxRxMy+6H+FE0C0WtaMBAkKNA== Date: Thu, 11 Nov 2021 20:40:09 +0000 Message-ID: References: <163490209138.9955.12584931650278112847@ietfa.amsl.com> In-Reply-To: <163490209138.9955.12584931650278112847@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.120.23.2.7) authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: da7ea3c8-525f-45d6-c533-08d9a5537420 x-ms-traffictypediagnostic: DM5PR11MB1835: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IzNGiG7RGoBA+UannHnYzwovm2MVSdENcggrFPK77jrjieda0MgQXGlqgskwZ4cM0V62F3dBE3qrf7welfi0kugTDgwJ7z9JzIdMqKEk6u9kcsa9jZ+zM6Ijwbkqozjr+6cuIF0dW4RHgu4c7OP1ZgG9bztbPIZXtAPLBQdSXdEEEULHhh8GvBAQ00DlLkfEJ9IUqJKJwBsf5qiUpam1tazYUmB7DrBZtgzkjyVXzhKk7dHkxIyts9rFgUAWD+VpEqCkAQRh6sjvoASkKYZBC1GP8FBzZNp1hx7GQrgWzAb1mavH4s92KuyW8FgRp957c+h3REuT2pj5H630vZzdI0PIVPiWPu/x4bhfzxB16TS6SkbxSRNiZZDlMMl1UUu2gAwLWMxlhPAnUjlfaIdLtLafjMVd+uEqHRmEDgV9vQvkC5EyBQYn0UXASmcOvLtTAXrKpYe2c9yEy7ZyysbODpx+oIbnQnSpnjOcSpbplYNDz67ZXnlj6OtOnvmqrq7BneHUW+mQcj4ARus+p+OZFS+32hUkkMhzg1W7LJwRMxkcW16vE54hX6fRt40V5ViuDkZdVMHerz+s5cvzMLIu4IdW6vqvY0OqmXq9Wf0/sdbyEEDm1RjrXzCFGZmeiyiaWfEQ6+ZSwZ0+kJojnn0dcnp0n0wUFGRsnG9dTQvlBac3H3+hKblkneobSJjIYlwD4+d7hdhH+aBOeY00srACzXkJg/MhD2hTOXKl3y2Ig8T6MF8lB0K3jHVeMsrPcwZ1B7Dg11Biz6l7P5x+uzyKIELVSHe5XsZzRAnSpC4SlYG1BIzrsqZ0EuqkawjHL8DR2DOqkNoasyY/9ACG+1k6G2DXf3G9lq7WxzqYt57DC8M= 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)(76116006)(966005)(8676002)(38100700002)(8936002)(36756003)(91956017)(26005)(83380400001)(508600001)(66574015)(186003)(122000001)(66446008)(66556008)(66476007)(6512007)(66946007)(6486002)(64756008)(71200400001)(2616005)(4001150100001)(6506007)(53546011)(38070700005)(33656002)(86362001)(2906002)(5660300002)(316002)(6916009)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?a9ta7neolzYon+YwrnqV47XXckjjWD8swlJnfZuEiTGhE/RjDZUjxKyy/w11?= =?us-ascii?Q?7rvlkxIIgyOp34ckXLZ71l/VKgoopjyhe4cyMJYpQ0poEsAgRwxTlLEy+iS2?= =?us-ascii?Q?q4IuihgEMVWBJJ0UtQhRbRWIyszJ1CSWuHSNIByRK4ku8xvxgteWCAPETFiT?= =?us-ascii?Q?bVkmgy/RXaJzvvM84n/86qMLFrbQMKi1EHoUCl5xaqyx50Cwn111un0G7Xwl?= =?us-ascii?Q?WIQBE96srx4UFqY2+1Capiwm61k2TSYdiOtc3dRgtg0oK+2JNZUIyiSylSWi?= =?us-ascii?Q?DtWYzoHLjHhWa05+ysipaplTuRt4KH++YgWW3TZzZ/GLgzHzuteCtjhEilVe?= =?us-ascii?Q?4d8p6mA3HsenPsoy+V8qJxX9OyZAw1/j2j9TbNkIlKz8ItHMNc7GlsokmORi?= =?us-ascii?Q?znwGz8XN/wdUvzChYwk0MVG6tdOtL5n0I90UK0LOkU6oP2r0/aj4xocV+w9y?= =?us-ascii?Q?U8zL4HMB0OKh2SoI57D3vSK2awuJIYKDZsclMvN7CnatGSwr6LDS9pBzSOsn?= =?us-ascii?Q?nKYHrqXWUcPNSXPY2p37/sSY2vujEdDe7nrHczkxqoaPRGMBAUUk4nojImHc?= =?us-ascii?Q?NHYZ2YspvqFe2wMTp8PgOo9jpV33yuqzWL0bOigQewArEPzFsX7a34Idm+Xx?= =?us-ascii?Q?Y7VIRyRfyzjoFsXGJslSmfX5vGtl1dVOuUZUpmpus7qtMZzuH6Z/yj6mr+ga?= =?us-ascii?Q?u+Ig/SGecKfiIr1H7Gb0w7fjP9LxJWuTBZzztg4YfF96b/vemhxm7zbi3YxX?= =?us-ascii?Q?u4iTuvPMtu6YS2RvClXMypDrKSOnd5nOfWPyyemjlBgWM2v4XDCx7sqwBM7Z?= =?us-ascii?Q?MGlmcW5Xv+GsNcdSqUcrHV20QCCABB9TGQWp5l7e0DPNvI1OuVrhij8KNZkh?= =?us-ascii?Q?7jrOa4EWUjQ+pXpsEJwg2e+BOnp98V36G61oE0pagFbbf/qBaje6Vd6OoHP8?= =?us-ascii?Q?AAFypQvDVpKeQfXYwOzp3YJUn5Ec8YxsVNt0Yt6gyvph0LiicO0INCV4a54F?= =?us-ascii?Q?uFP8Nv7Bs81i3YaXJzduokXBM68WB1xfK4gcq8FML89Om+l7dx9hla2esAo5?= =?us-ascii?Q?96wbZcovcioI33T0VUwrW86ras3vKR2CbWMldBU6tt6JP9CbBNmU5xvqjn5a?= =?us-ascii?Q?FaKapM1YbpPR95lcllg2wbzeKee/oLHVqdafJbaLPZMre8rpuyFJbRopjovS?= =?us-ascii?Q?a+FuDY0KSoj3nbKtuEYhDT6fXbHKZiQkcQl5Wu1IXiRJS7/0eACLV9FT7QR4?= =?us-ascii?Q?FdPKCyPJzbCMJfRA2iUmuxD11n4aY22IDvzgpW5UYJY9E9QOgYjbs6g7HyMc?= =?us-ascii?Q?NQ59+4uzz3gbBkC6BW9VR5gAHRe+atzqxIYHHb9oe3wnb/teGsONOGsUaE+d?= =?us-ascii?Q?D0yn7gVh0BWdLnyXcADS8u/6ibmVfWzgTn+kSQOq7iBhmnK8GxggMqnHCQ/B?= =?us-ascii?Q?1PLbBXfwIbSuTsiXIIudAsPEgfbLFM2Xk8b4fmPj+lLWv63w5gezTeE/4Mb4?= =?us-ascii?Q?bdr3AalRjULuQcDYCVkWJL1PWRMeOXIetzVWFDk6jfsCEd0O5MbZnG3iSISG?= =?us-ascii?Q?fCuIHHmpeYt6Ek9e4SbMbvQGd9WXOuYkqkDHeYdjKpOoMsx9aUlNsOfgLDt2?= =?us-ascii?Q?uCTqAY8iAP+r5dRfi7MlIo8=3D?= Content-Type: text/plain; charset="us-ascii" Content-ID: <9F27410132BDC842BDA78DA4131ED58F@namprd11.prod.outlook.com> Content-Transfer-Encoding: quoted-printable 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: da7ea3c8-525f-45d6-c533-08d9a5537420 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2021 20:40:09.7230 (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: mATwfggVnTht9XuY+WUgBkF4RXC18tY7ymoWFgA+qozlWHwd8IXNZg4eNFe+q4owQdqOJxXTsVZCx3Aa9321XA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1835 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.22, xbe-aln-007.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: [netconf] Open question 1/4 "Etag values" in draft-lindblad-netconf-transaction-id-01.txt 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, 11 Nov 2021 20:40:19 -0000 Hello NETCONF team, This thread (1/4) is about Etag values: at the NETCONF WG session earlier t= his week, the chairs asked me to start a separate thread for each of the ou= tstanding question relating to draft-lindblad-netconf-transaction-id-01.=20 When clients and servers send and receive Etag values, what should be the v= alue space and semantics associated with them? Proposed solution #1) Use exactly the same value space as specified in RFC = 8040 (RESTCONF) which in turn points to RFC 7232 (HTTP Conditional Requests= ) sec 2.3. This means the Etag is an arbitrary length string of 8-bit chara= cters of the server's own choice, except it must not contain ASCII control = characters, space, backslash or double quotes. Proposed solution #2) Server uses a monotonously increasing integer for Eta= g values. Special cases like behavior at server reboot have not yet been di= scussed. Proposed solution #3) Server uses an arbitrary length string of UTF-8 chara= cters of its own choice. The -01 draft specifies solution #1. Please indicate your preferences among= the options. Comments or suggestions for other options are also welcome. Best Regards, /jan > On 22 Oct 2021, at 13:28, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-lindblad-netconf-transaction-id-01.txt > has been successfully submitted by Jan Lindblad and posted to the > IETF repository. >=20 > Name: draft-lindblad-netconf-transaction-id > Revision: 01 > Title: Transaction ID Mechanism for NETCONF > Document date: 2021-10-22 > Group: Individual Submission > Pages: 22 > URL: https://www.ietf.org/archive/id/draft-lindblad-netconf-tr= ansaction-id-01.txt > Status: https://datatracker.ietf.org/doc/draft-lindblad-netconf-t= ransaction-id/ > Html: https://www.ietf.org/archive/id/draft-lindblad-netconf-tr= ansaction-id-01.html > Htmlized: https://datatracker.ietf.org/doc/html/draft-lindblad-netc= onf-transaction-id > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-lindblad-netcon= f-transaction-id-01 >=20 > Abstract: > NETCONF clients and servers often need to have a synchronized view of > the server's configuration data stores. The volume of configuration > data in a server may be very large, while data store changes > typically are small when observed at typical client resynchronization > intervals. >=20 > Rereading the entire data store and analyzing the response for > changes is an inefficient mechanism for synchronization. This > document specifies an extension to NETCONF that allows clients and > servers to keep synchronized with a much smaller data exchange and > without any need for servers to store information about the clients. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 From nobody Thu Nov 11 12:45:06 2021 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 A6E613A0E23 for ; Thu, 11 Nov 2021 12:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.617 X-Spam-Level: X-Spam-Status: No, score=-9.617 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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=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=BcJXC160; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=qtgUEz3O Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3eCYNBAaujx for ; Thu, 11 Nov 2021 12:44:59 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75E7B3A0E1F for ; Thu, 11 Nov 2021 12:44:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13763; q=dns/txt; s=iport; t=1636663499; x=1637873099; h=from:to:subject:date:message-id:mime-version; bh=gYokGoq7tQzbH29Elrlx4yTAyp764LRrd9ZCpisMBFY=; b=BcJXC160l2+rTlWeEIzGCJuWmPC7mAiIyU8AbZaNefi2zP5lnc4TIx2D gSd05CatuSQDptFWPrSdrXJZ7TPDT+X69vgC6IXsqdF/xD5uLPNpZEe7p ujcvegYlxHeaX27JPMRJt5ISehJQ6HLPi4UBHZ5LvuvW7WrSoh3uZE8m5 k=; IronPort-PHdr: =?us-ascii?q?A9a23=3AYxA8gR3qqSD9i0ZosmDPr1BlVkEcU/3cMg0U7?= =?us-ascii?q?88hjLRDOuSm8o/5NUPSrfNqkBfSXIrd5v4F7oies63pVWEap5rUtncEfc9AU?= =?us-ascii?q?hYfgpAQmAotSMeOFUz8KqvsaCo3VMRPXVNo5Te1K09QTc3/fFbV5Ha16G16J?= =?us-ascii?q?w=3D=3D?= IronPort-Data: =?us-ascii?q?A9a23=3AYp5aK6KGqZH68C4UFE+RzZclxSXFcZb7ZxGr2?= =?us-ascii?q?PjKsXjdYENSgWBRx2sfWGyOaKuMYzb1Loxza4608ktU7JSBnINkGlAd+CA2R?= =?us-ascii?q?RqmiyZq6fd1j6vI0qj7wvTrFCqL1O1DLImfRCwIZiWE/E70a+G49SAUOZygH?= =?us-ascii?q?9IQNsaVYkideic8IMsRoUoLd98R2uaEs/Dga+++kYuaT/nkBbOQ82Uc3lT4R?= =?us-ascii?q?E60gEgHUPza4Fv0t7GlDBxBlAe2e3I9VPrzKUwtRkYUTLW4HsbiLwrC5Kuy8?= =?us-ascii?q?mWc9BA3B5b81L36aUYNBLXVOGBiiFIPBPPk2UcE93d0i/thXBYfQR8/ZzGhn?= =?us-ascii?q?dRwztlHsZWYQgYyNaqKk+MYO/VdO3AgZPAcpeSZcRBTtuTWlSUqaUDExfhyB?= =?us-ascii?q?0YwM6UZ9/p5R2ZU+pQlxJolBvyYr/i9zLT+Qe52i4F6asLqJ4gY/HpnyFnk4?= =?us-ascii?q?T8dacira833CRVwhV/cXvxzIMs=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3Ar6pdqapYTAruriZ66QPWABkaV5ubL9V00z?= =?us-ascii?q?EX/kB9WHVpm5Oj9vxGzc506farslkssSkb6Kq90dq7MA7hHP9OkMUs1NKZPD?= =?us-ascii?q?UO11HYVL2KgbGSpgEIeBeOudK1t50QCJSWYeeYZTMR4KqKg3jbLz9K+qjhzE?= =?us-ascii?q?ncv5am854bd3ANV0gP1XYcNi+rVmlNACVWD5swE5SRouBdoSC7RHgRZsOnQl?= =?us-ascii?q?EYQunqvbTw5dzbSC9DIyRixBiFjDuu5rK/OQOfxA0iXzRGxqpn2XTZkjb++r?= =?us-ascii?q?6ov5iAu17hPi7ontRrcenau5l+7f+3+40ow/LX+0KVjbFaKv6/VfYO0aaSAR?= =?us-ascii?q?gR4Z/xSlwbTrhOAjvqDx6ISF3WqlDdOPJE0Q649bde6kGT+fARDQhKevZplM?= =?us-ascii?q?ZXdADU5FEnu8w52KVX33iBv54SFh/Ymj/hjuK4HC2DBiKP0AQfeMMo/jViuL?= =?us-ascii?q?ElGfdsRE0kjTZoOYZFGDi/5JEsEeFoAs2Z7PFKcUmCZ3ScumV02tSjUnk6Ax?= =?us-ascii?q?/DGyE5y4Go+ikTmGo8w1oTxcQZkHtF/JUhS4Nc7+CBNqhzjrlBQsIfcKo4Du?= =?us-ascii?q?YcRsm8DHDLXHv3QSivCEWiELtCN2PGqpbx7rlw7Oa2eIYQxJ93g5jFWEMwjx?= =?us-ascii?q?9FR6svM7z44HRmyGG/fIyNZ0WY9igF3ekIhlTVfsuYDRG+?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzBwBbgI1h/5hdJa1agQmBWYFSIy4?= =?us-ascii?q?Hd1o3MYgOA4U5hQ5dgiWWBYUKgS6BJQNUCwEBAQ0BATcKBAEBhQSCXgIlNAk?= =?us-ascii?q?OAQIEAQEBEgEBBQEBAQIBBgSBEROFaA2GWy4BATgRAUc5FBMEExsHgk8BgX5?= =?us-ascii?q?XAy8BDqB+AYE6AoofeIEzgQGCCAEBBgQEgToCDkFGgjkYgjUDBoE6gwyCfFR?= =?us-ascii?q?KhwYnHIFJRIE8DBCBZoQiAQEBAQEXgS5FgyKCLo5+JoEwBDsWAhRdIE0KSgg?= =?us-ascii?q?DK5IejCo7n1AKgzgFikuUMQUtg2yLc5dNlhRVgWuKNJQGCGMBhB0CBAIEBQI?= =?us-ascii?q?OAQEGgWE7gVlwFRpLAYI+PhMZD5IShRSFSnQCNgIGCwEBAwmPdAEB?= X-IronPort-AV: E=Sophos;i="5.87,226,1631577600"; d="scan'208,217";a="961525368" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Nov 2021 20:44:58 +0000 Received: from mail.cisco.com (xbe-aln-001.cisco.com [173.36.7.16]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 1ABKivVw007823 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Thu, 11 Nov 2021 20:44:58 GMT Received: from xfe-rtp-001.cisco.com (64.101.210.231) by xbe-aln-001.cisco.com (173.36.7.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 11 Nov 2021 14:44:57 -0600 Received: from xfe-rcd-004.cisco.com (173.37.227.252) by xfe-rtp-001.cisco.com (64.101.210.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 11 Nov 2021 15:44:57 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-004.cisco.com (173.37.227.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Thu, 11 Nov 2021 14:44:56 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UiBqc8OKq5N8Bu7s9O217W80dJVemTbPodC4IrHCpiaKwdk2LIrCcD+t7cx0BlNy2otSv5//QKvzbce4Tn4+b0986E5UltoRSzmHNz4Q6uY1btQ4AKU/PF2DZRDA4cr/fqk5/Eei/9UOCuy5mtzWkyM9FvBOcsRPlbw2vlQOwkM/P/0kaUsuewBOeTJs7LB7eHwcOd/ez4hG+uktJ0LuCeG/EkKBbHzyispvct2LeyOUeMgswdLrL6YVC2/6EDXQ4ZkDPqQtsuDVXcD4DSQxtAdGICcqkNAV/0C5ZuB7htOUPjJ2ldN53NcX+2RKXS4o4RMJM1ywQ8/FIzRcQOh1DA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=s3A9GoHelwFKfLZGtvEeiIozjpH/21CikqMuU7UZ90c=; b=NzKCHf1q06uPSkrePQZYGh2aCECu6dFen5HI/zmuOEnLhxE2+bGyQvmXkoy1muSyKOf9e9rzgkvsD+7aO0j+lIVmnIYSXhAnq8mpyKp80J007ZfsCA0BHCosIy7TCPTfCWmBdKRi2/AAcZHBvhSDRIejD02XmEDdqie6vilfl/m/mBWP/iYP5Vyn0i4k7hzqHAdiyN4W/EhEhKuSNmHywBYF1J9782YdbW0e7dpVPy2XQ7nbs0XRclcmzjczGwIV5RgwL1sRSLXQEQk/+C2tRkIF3gdamsKqm7xBcD4mXzM6gEA+QG6GDeMR2IzR9Hsj5yhsPYRJttv2o6pQTfT9pA== 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=s3A9GoHelwFKfLZGtvEeiIozjpH/21CikqMuU7UZ90c=; b=qtgUEz3OfbqP+BW7kum3LlYNhga1avMrNdX7zDPRJ0pFeicOhyXO9ZZcAU/NWHtHqHLLifEbauaW5cjgUkL9TwASb5ToQIF4fSzIQxyMOBCRu7MfsR/1WMo4PeBBR3wlPDfIFFK2NTySQ8iFf1E/zQQ4VbxFGw69rtzrTWI8Iwo= Received: from DM6PR11MB2841.namprd11.prod.outlook.com (2603:10b6:5:c8::32) by DM5PR11MB0057.namprd11.prod.outlook.com (2603:10b6:4:6b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.15; Thu, 11 Nov 2021 20:44:55 +0000 Received: from DM6PR11MB2841.namprd11.prod.outlook.com ([fe80::74cd:ce34:6dcb:11b4]) by DM6PR11MB2841.namprd11.prod.outlook.com ([fe80::74cd:ce34:6dcb:11b4%7]) with mapi id 15.20.4669.016; Thu, 11 Nov 2021 20:44:55 +0000 From: "Jan Lindblad (jlindbla)" To: Netconf Thread-Topic: Open question 2/4 "Timestamps" in draft-lindblad-netconf-transaction-id-01.txt Thread-Index: AQHX1zz7c7PXKXZ4Kk6gMgXNwJBmxg== Date: Thu, 11 Nov 2021 20:44:55 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.120.23.2.7) authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ade845b3-3f67-4d20-261c-08d9a5541e6e x-ms-traffictypediagnostic: DM5PR11MB0057: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cTb2N+rGIJgGD8hNAgmtW5lgEe/80NBfQn73T5MSWrRoV5kf7gKzkEsgk/WdfJeRsgoclDEXFPQq8lgHjY6qidbIsst6xmsW2h81D9fmrJWISEV5v/MgiEmtJ/Iqb58DvwvQSn6tXNAMRzvENP0rc76I3HALxx9tSIMBX2rLLrBSTIiLIimHrv6UeFoEenk6Aos4pUvoLyZd9RJXPtJUEgURXIYZtJ768krYARpTLGTZsV7Jw3Zg5CE+TUpbL3zpI0MEyu3QJ7gZLnt+C/KtDEtUGrn4Q1mJnatrzL5Goib5U1AVskLJyjVRKn6UKuZCPxHWQ1gTGZyBlkEsZTDTsgAw0PIFwxWHE7lOrVa5lpQfcRarlPQXyM9DWfWXou5So1Zpdo/1z17reS/USa5IE+fg/JTXpRW9jfa3OVg1txHrE3gOonkmKXunNBfx3R55y5T9X4tMSuVuEFgG6JOMS1j/TRHKVXPY9nGKtakz8frkLtcphbF37MB0gAZXVFU/CsPu09D5Sahpx5prlS89OferdTDR8IzGxgdyMpVT4M4LkfpNf+AsryzEHaK9EaGHvvIxa0uK/YfVhkAARJZ7erfKAFjAQ3ezjnvSaQuJM7FkseFsJTT3JHVpv1ypIjC1ja+q6qs6/EI19x/uegqdFapdpq8g3nU9NhGp833nqqkpjnvwaPtwdyIkc44FtfqLSxP9fD3cC2BVA+6/6EUBhgHzIPhdKBbVdLQYgLm59o+eXvsAQ/ZYdOsLa/kq7d37FOrCRGcCfEZ2X2gxQAU7oA8VXez7GkYFUBXtzVqN2vaWd+pv1g5a8NQa6oiV6UW905YGiRdQwRUiqbtnEj7bB01V5f11sbZK6G6SWsr2Cjg= 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)(6512007)(83380400001)(2616005)(6506007)(53546011)(71200400001)(66574015)(21615005)(4001150100001)(66556008)(64756008)(186003)(26005)(86362001)(8676002)(166002)(5660300002)(8936002)(6916009)(38100700002)(508600001)(316002)(6486002)(76116006)(66946007)(91956017)(122000001)(66476007)(33656002)(38070700005)(2906002)(966005)(36756003)(66446008)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?eaKz1KfC6Hn1EW1m2dq6LsKnAlhewWw26QcPY0/cwCjXLxQl65X0f1F1fBIM?= =?us-ascii?Q?ZymLzaX8g5Zfn7jbfiDLFgbde0v0KxfoxgKIDimRpAVsoJHqhtJ2YzEYk0Fa?= =?us-ascii?Q?zYyNkJaXOSow4gQwz+NI11uXjURBpsw/6xQswdY7ihxT49gfPX8ZyYIiAEiL?= =?us-ascii?Q?+n1arEfzEgj/AhAyQBfLcApmXkdGBL8iTIHkfH9LlmhVjw+08hdkJQ9RR0zd?= =?us-ascii?Q?MYfL3tkxIw7tM5zgKnK1HZY7U47HVhoI4Gd8RGVpjLbg7I+lrnJDiFllEOY+?= =?us-ascii?Q?XOCgaWPbEtkwl30H2MA3JpGCzQ+kmN59jHI1UdagoY7sXmTT3WWQwG5q9P8t?= =?us-ascii?Q?TCGJduAyYpvLsNvAM7VGCI7VgtZkYIUpvZgsAj8T+Pmy0HceM/pfDr+HHKua?= =?us-ascii?Q?SGTqXiVEp3Gn245pplhQ3bB2q0/EwiJwItYMcq2D16umscutWJtvoB++Is8E?= =?us-ascii?Q?eR1+g2xP2J6b3MP3dUYh1VAQGd7sitpF4rq1eig8Ku2cnUrVZcwNh+9mLZLs?= =?us-ascii?Q?uIcyTvYIwE3jgI2p13JI5AJKkJ5SFkVSiOPu6AO3sKARxGQ42ZPep0VrO169?= =?us-ascii?Q?NHI19KNiSSIK2e2wgc5y33yINYpVJJl2n+GeXqBNmrtbbgsUxVbnTwxR85Np?= =?us-ascii?Q?bOWXygL5nsUlP8EB8uMzBYcszm8fHOshdpOMT49mNsmaZ5W44kmZ+jL4UQfT?= =?us-ascii?Q?R2B6M3d8Jiw+vsn8gkh8U/dEU4BsEaHJrV4Szkvc1u8QuNoSRWEPW2GuiXJU?= =?us-ascii?Q?f+0egF05/t7whOL+YfyiJdL8N8MrNEk5xaizy6WqA0v/hLYxVao3YKVWis9V?= =?us-ascii?Q?LxJwo80y6JeRXQptylYpmTUbtzr1BeNQQj9rgPtSHsd3VcJim0Q+TQkYyOCt?= =?us-ascii?Q?j7uNNlIB9U8LFv2AWTFk4DdPrfxHv6Of64GnOppfcqvejW3uIVqWfc64OmFX?= =?us-ascii?Q?cdDxIVz5/ylZpXUL5dVdA3CfUYIjWGdUFjzF+OW96i1bkOdmYufeVRS9ZIBG?= =?us-ascii?Q?tBMeP5bYJ6Tm0/mL1g8nmBMF94CxPY5zptiUKaPa0kf4P+37yvS2J6TFHNx+?= =?us-ascii?Q?tPRVNecs4xB/vJcSp16oxUuq8/7BrI+Xh8GJGeYidaiDkqlVanTIbSt9K0Hu?= =?us-ascii?Q?QDXNDyqEeSpp9XZR8hXBei5LPIcRyOB/NpOTtrKHF4w4da5tN126UPc3ul9x?= =?us-ascii?Q?Gb8QlVn/gNtdKj44T0p1iE5lZNSv6UpyaflwUGNRRVDvqSdzI31FFHKlagHL?= =?us-ascii?Q?4HQbHZ+Mn+u2EN5izAkSJHQrHp84Qx0yIETG3ihChnozVQPrOGGMOOIcemm0?= =?us-ascii?Q?HfRHRJQA+E9GXGhtoB3RE0x2kjuV60YRWQy+okusUCBvUJpxUdh7SCKSlGMA?= =?us-ascii?Q?MnB5Y3h1pct4Sli30IyxS0s6rXJmypz6cuCQZa8AddXjUjnxh/is9sI2fKNB?= =?us-ascii?Q?8Sdme0OcHnR32y3esUK9x5PSzYYToIuRqCj7uC8FQhoQCNsH1J2xzftsYF5n?= =?us-ascii?Q?TGTWBHSRE0lJMYdd6DcTl5mOUZa+Ms/GaUosSMcMGPSp3MxxwzbucqlopwzF?= =?us-ascii?Q?QY0i9Jk/p6ChJ/z1fIY02a9N6eJL6rOFSc1tyIM/GpagZHXKm5XW/QBL+XWc?= =?us-ascii?Q?aMdVdh1ehTWWEl3GuAe62CI=3D?= Content-Type: multipart/alternative; boundary="_000_AD4C171A071C4011BB04CEEECFB94CE1ciscocom_" 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: ade845b3-3f67-4d20-261c-08d9a5541e6e X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2021 20:44:55.4897 (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: laBZrgLnSmJCtPbo0Ktjl5T5iXxq9tignYg0XgL4eX4psdJ2YHT5LjPpUicOGm1/n0xt/snXo9XhWg5hFopJrg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB0057 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xbe-aln-001.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: [netconf] Open question 2/4 "Timestamps" in draft-lindblad-netconf-transaction-id-01.txt 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, 11 Nov 2021 20:45:05 -0000 --_000_AD4C171A071C4011BB04CEEECFB94CE1ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello NETCONF team, This thread (2/4) is about Timestamps: at the NETCONF WG session earlier th= is week, the chairs asked me to start a separate thread for each of the out= standing question relating to draft-lindblad-netconf-transaction-id-01. In RESTCONF (RFC 8040), clients and servers may send and receive Etag value= s, or they may opt to use a similar mechanism based on timestamps. Should a= similar timestamp mechanism also be introduced for NETCONF transaction IDs= ? Proposed solution #1) No, this is not needed. IETF or another SDO is of cou= rse free to define such a mechanism at a later time, and an implementor cou= ld define a proprietary mechanism. Proposed solution #2) Yes, but it should be an optional capability for a se= rver to implement. If available on a server, it would also be optional for = a client to use it. Proposed solution #3) Yes, and it should me mandatory for servers that impl= ement the Etag mechanism to also support the timestamp mechanism. It would = be optional for a client to use it. The -01 draft specifies solution #1. Please indicate your preferences among= the options. Comments or suggestions for other options are also welcome. Comments: I have collected arguments for and against this feature. Here are= the most salient ones, in my opinion. + Adding timestamps makes feature parity between RESTCONF and NETCONF. + Using timestamps is potentially saving a lot of overhead, since timestamp= s are inherently ordered, and can be used as short hand for large set of Et= ag values. + Clock synchronization between clients and servers in a large network may = not always be very reliable. + NETCONF edit-configs may often have a larger scope than RESTCONF update o= perations. It is not uncommon with transaction commit times of a few minute= s (or occasionally more than a few). This may dilute the meaning of the tim= estamp, and thereby reduce its utility for If-Before etc. In order to make = it useful, some additional language (beyond what's found in RFC 8040) may b= e necessary. Perfect feature parity may not be achievable here. + In RESTCONF update operations, only a single timestamp is being exchanged= . When translated to a NETCONF context, I expect many Etag values and times= tamps would be present in the payload. The added overhead for providing bot= h kinds of meta information is significant. To include both attributes (Eta= gs and timestamp) for a lot of nodes in the data tree sounds unnecessarily = costly. Best Regards, /jan On 22 Oct 2021, at 13:28, internet-drafts@ietf.org wrote: A new version of I-D, draft-lindblad-netconf-transaction-id-01.txt has been successfully submitted by Jan Lindblad and posted to the IETF repository. Name: draft-lindblad-netconf-transaction-id Revision: 01 Title: Transaction ID Mechanism for NETCONF Document date: 2021-10-22 Group: Individual Submission Pages: 22 URL: https://www.ietf.org/archive/id/draft-lindblad-netconf-tran= saction-id-01.txt Status: https://datatracker.ietf.org/doc/draft-lindblad-netconf-tra= nsaction-id/ Html: https://www.ietf.org/archive/id/draft-lindblad-netconf-tran= saction-id-01.html Htmlized: https://datatracker.ietf.org/doc/html/draft-lindblad-netcon= f-transaction-id Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-lindblad-netconf-= transaction-id-01 Abstract: NETCONF clients and servers often need to have a synchronized view of the server's configuration data stores. The volume of configuration data in a server may be very large, while data store changes typically are small when observed at typical client resynchronization intervals. Rereading the entire data store and analyzing the response for changes is an inefficient mechanism for synchronization. This document specifies an extension to NETCONF that allows clients and servers to keep synchronized with a much smaller data exchange and without any need for servers to store information about the clients. The IETF Secretariat --_000_AD4C171A071C4011BB04CEEECFB94CE1ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <2C94EBD402CC7C4983211AF49C70E6CB@namprd11.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hello NETCONF te= am,

This thread (2/4= ) is about Timestamps: at the NETCONF WG session earlier this week, the cha= irs asked me to start a separate thread for each of the outstanding questio= n relating to draft-lindblad-netconf-transaction-id-01. 


In RESTCONF (RFC= 8040), clients and servers may send and receive Etag values, or they may o= pt to use a similar mechanism based on timestamps. Should a similar timesta= mp mechanism also be introduced for NETCONF transaction IDs?

Proposed solutio= n #1) No, this is not needed. IETF or another SDO is of course free to defi= ne such a mechanism at a later time, and an implementor could define a prop= rietary mechanism.

Proposed solutio= n #2) Yes, but it should be an optional capability for a server to implemen= t. If available on a server, it would also be optional for a client to use = it.

Proposed solutio= n #3) Yes, and it should me mandatory for servers that implement the Etag m= echanism to also support the timestamp mechanism. It would be optional for = a client to use it.


The -01 draft sp= ecifies solution #1. Please indicate your preferences among the options. Co= mments or suggestions for other options are also welcome.


Comments: I have= collected arguments for and against this feature. Here are the most salien= t ones, in my opinion.
+ Adding timesta= mps makes feature parity between RESTCONF and NETCONF.
+ Using timestam= ps is potentially saving a lot of overhead, since timestamps are inherently= ordered, and can be used as short hand for large set of Etag values.
+ Clock synchron= ization between clients and servers in a large network may not always be ve= ry reliable.
+ NETCONF edit-c= onfigs may often have a larger scope than RESTCONF update operations. It is= not uncommon with transaction commit times of a few minutes (or occasional= ly more than a few). This may dilute the meaning of the timestamp, and thereby reduce its utility for If-Before= etc. In order to make it useful, some additional language (beyond what's f= ound in RFC 8040) may be necessary. Perfect feature parity may not be achie= vable here.
+ In RESTCONF up= date operations, only a single timestamp is being exchanged. When translate= d to a NETCONF context, I expect many Etag values and timestamps would be p= resent in the payload. The added overhead for providing both kinds of meta information is significant. To include bo= th attributes (Etags and timestamp) for a lot of nodes in the data tree sou= nds unnecessarily costly.

Best Regards,
/jan

On 22 Oct 2021, at 13:28, internet-drafts@ietf.org wrote:


A new version of I-D, draft-lindblad-netconf-transaction-id-01.txt
has been successfully submitted by Jan Lindblad and posted to the
IETF repository.

Name: draft-lindbl= ad-netconf-transaction-id
Revision: 01
Title: Transaction= ID Mechanism for NETCONF
Document date: <= /span>2021-10-22
Group: Individual = Submission
Pages: 22
URL:            https://www.ietf.org/archive/id/draft-lindblad-netconf= -transaction-id-01.txt
Status:         https://datatracker.ietf.org/doc/draft-lindblad-netconf-transaction-id/
Html:           https://www.ietf.org/archive/id/draft-lindblad-netconf-t= ransaction-id-01.html
Htmlized:       https= ://datatracker.ietf.org/doc/html/draft-lindblad-netconf-transaction-id<= br class=3D""> Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-lindblad-netcon= f-transaction-id-01

Abstract:
 NETCONF clients and servers often need to have a synchronized view of=
 the server's configuration data stores.  The volume of configura= tion
 data in a server may be very large, while data store changes
 typically are small when observed at typical client resynchronization=
 intervals.

 Rereading the entire data store and analyzing the response for
 changes is an inefficient mechanism for synchronization.  This  document specifies an extension to NETCONF that allows clients and  servers to keep synchronized with a much smaller data exchange and  without any need for servers to store information about the clients.<= br class=3D"">



The IETF Secretariat
--_000_AD4C171A071C4011BB04CEEECFB94CE1ciscocom_-- From nobody Thu Nov 11 12:46:31 2021 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 D480A3A0E2C for ; Thu, 11 Nov 2021 12:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.618 X-Spam-Level: X-Spam-Status: No, score=-9.618 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_NONE=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=biN9NkeL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BAfs8inB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CL6JWs8Q0P5 for ; Thu, 11 Nov 2021 12:46:23 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0CA43A0E23 for ; Thu, 11 Nov 2021 12:46:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3441; q=dns/txt; s=iport; t=1636663583; x=1637873183; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Z0OBbcUCfTbYwWX/Lll2nx5VRkAGWqDn0VwliMjS4lg=; b=biN9NkeLDexxU/0N6YvlDlU5lqRA6MxObUYTt2h3X4rqobAwW00laDB8 yRRkRcQh8Cn1XUUNzRjevT40QUk8CQE4ctS1dZ1JU72QscVzLi0mv+pbP c08hGkq+aqr5pWDmMJ+0p9XeCgf93bHd9Vd4rExrUDd1HeLIu7YEcco5E 4=; IronPort-PHdr: =?us-ascii?q?A9a23=3AAPXGoROMV0KYY7/pcL8l6ncDWUAX0o4cdiYZ6?= =?us-ascii?q?Zsi3rRJdKnrv5HvJ1fW6vgliljVFZ7a5PRJh6uz0ejgVGUM7IzHvCUEd5pBB?= =?us-ascii?q?BMAgN8dygonBsPNAEbnLfnsOio9GskKVFJs83yhd0ZPH8OrbFzJqXr05jkXS?= =?us-ascii?q?X3C?= IronPort-Data: =?us-ascii?q?A9a23=3AXsEIeqI/YDC65hCdFE+Rz5clxSXFcZb7ZxGr2?= =?us-ascii?q?PjKsXjdYENS1zUOm2odC2mOOq2NYjDzKtF/b4m+oEsBu5XUzoVnGVMd+CA2R?= =?us-ascii?q?RqmiyZq6fd1j6vI0qj7wvTrFCqL1O1DLImfRCwIZiWE/E70a+G49SAUOZygH?= =?us-ascii?q?9IQNsaVYkideic8IMsRoUoLd98R2uaEs/Dga+++kYuaT/nkBbOQ82Uc3lT4R?= =?us-ascii?q?E60gEgHUPza4Fv0t7GlDBxBlAe2e3I9VPrzKUwtRkYUTLW4HsbiLwrC5Kuy8?= =?us-ascii?q?mWc9BA3B5b8y/Dwc1YBRfjZOg3mZnh+Avf5xEMd4H1plP9na5Lwam8P49mNt?= =?us-ascii?q?9J1ydNBv5i5YQwoJabL3u8aVnG0FgkvZvAZoeGYcSTXXcu7iheun2HX6/NjE?= =?us-ascii?q?EoxO4Mw++trDydJ7/NwFdynRnhvnMqsy769D+JrnMlmdZCtN4IEsXYmxjbcZ?= =?us-ascii?q?cvKiKvrG83ijeK0Fh9q7iyWIcvjWg=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AV6xeWK+wKcak90El35xuk+F1db1zdoMgy1?= =?us-ascii?q?knxilNoENuE/BwxvrBoB1E73DJYW4qKQsdcUjpAtjOfZquz+8J3WB3B8btYO?= =?us-ascii?q?CGghrlEGgG1+vfKlLbalXDH4JmpMJdmstFeZzN5DpB/L3HCWCDer5KqrTqgc?= =?us-ascii?q?PY59s2pE0dKj2CHpsQljuRfTzrdHGeKjM2YaYRJd653I5qtjCgcXMYYoCQHX?= =?us-ascii?q?8eRdXOoNXNidbPfQMGLwRP0njPsRqYrJrBVzSI1BYXVD1ChZ0493LergD/7q?= =?us-ascii?q?K/99mm1x7n0XPJ5Zg+oqqj9jIDPr3PtiEmEESptu+aXvUnZ1REhkFynAib0i?= =?us-ascii?q?durDALmWZ4Ay080QKIQoj/m2qQ5+Cp6kdQ15al8y7CvZMmyvaJGQ7TzKF69N?= =?us-ascii?q?hkm1LimjsdlcA536RR022DsZ1LSRvGgSTm/tDNEwpnj0yuvBMZ4KUuZ+w2a/?= =?us-ascii?q?phVFZ9l/1XwKpuKuZJIMs60vFTLMB+SMXHoPpGe1KTaH7U+mFp3dy3R3w2Wh?= =?us-ascii?q?OLWFILtMCZ2yVf2CkR9TpU+OUP2nMbsJ4tQZhN4OrJdqxuibFVV8cTKaZwHv?= =?us-ascii?q?0IT8e7AnHEBRjMLGWRK1L6E7xvAQOGl7fnpLEuoO26cp0By5U/3JzHTVNDrG?= =?us-ascii?q?Y3P1njDMWftac7hCwlgF/NKggF5vsulKSRi4eMMIYDaxfzOGzGu/HQ0ckiPg?= =?us-ascii?q?=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B4BwAIgI1h/5NdJa1aHgEBCxIMQIF?= =?us-ascii?q?OC4FSUQd3WjcxiA4DhTmFDl2CJZsPgS6BJQNUCwEBAQ0BATcKBAEBh2ECJTQ?= =?us-ascii?q?JDgECBAEBARIBAQUBAQECAQYEgREThWgNhkIBAQQTKAYBATgEDQEgHgU9JwQ?= =?us-ascii?q?TGweCTwGCVQMOIQEOoH8BgToCih94gTOBAYIIAQEGBASBOgIOQYJ/GII1Awa?= =?us-ascii?q?BOoMMgnxUh1AnHIFJRIE8HII3g1EBAQEBAReBLoNngi6PIoEwBDsWAhR9TVw?= =?us-ascii?q?DERqRfiCMZZ9QCoM4BYpLlDEFLYNsi3OXTYMghjeMPVWMH5QGCGMBhB0CBAI?= =?us-ascii?q?EBQIOAQEGgWE7gVlwFRpLAYI+PhMZD44gN4M7hRSFSnQCNgIGCwEBAwmPdAE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.87,226,1631577600"; d="scan'208";a="935716784" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Nov 2021 20:46:22 +0000 Received: from mail.cisco.com (xbe-aln-004.cisco.com [173.36.7.19]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 1ABKkMIu004966 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Thu, 11 Nov 2021 20:46:22 GMT Received: from xfe-aln-004.cisco.com (173.37.135.124) by xbe-aln-004.cisco.com (173.36.7.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 11 Nov 2021 14:46:22 -0600 Received: from xfe-aln-004.cisco.com (173.37.135.124) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 11 Nov 2021 14:46:21 -0600 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Thu, 11 Nov 2021 14:46:21 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OzsYxaPAB87kaT49KMPoQoiQnLovOUzZ9oui6oXaUqqTf54Lqgk+sRQdPYKRm/qI9ZwSQu9ROoPqHsBqR9v+9AvDqB/XAG2Dw/6ZRx4lOGR31BwPlIeJgIWTdNaukFLw95iarmW6coJyriOUdSzMD9xSVFQ7OsYgsZl8PNZmoVxCO+itPn7YF5g5SSZ0ZnUUfJuIpgTTFaJ/On9YBkiEQ4gnmwA2oakKVgBxqgWWDjPQ9U3ZUhyKCgD+74ejFXPdpHKUIO/KSFkDaKFF2vri0sfzrCMX0zsAFNM6Bv9oYny1Qk5bqRstGAiwGhTKabs7eeE8aKVivesImvvb3JZErg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ImwIs0csMKrGS/mPVZpVidA9xZa+J6aiZ4CKJfJPoSI=; b=YhA7uFlnCwLlIV1GQncHrF8iwzt6Iu2mNaL3zHnKM/V8/gKRnTRpCtZa7oc9ddtRdiYajnijSTkElkp+EZ/elLgUYDUtQYbhl8XHhvGR1ZDFnf6ahSYwI0NUas/S3FTLng4RfpVyAAlfvNqnzSrUSMH0Ic19yWlNo0P8urx/pe5+bKK/2NB0MkHBpfnHHa6BgoEmvVL9kUwdnDGmvWggpO/mfYWjRSbz4+k1KcW4noFUzTSR2jQC/N99LeDRqdOv5+/rjcdMbc6FOMnCPF7vQn2ezIUWgiyUtJLrB/Z7IJddgQQtUFgi3CDOnB51HJSd6KMvy1y1hf3B31eH94G7UQ== 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=ImwIs0csMKrGS/mPVZpVidA9xZa+J6aiZ4CKJfJPoSI=; b=BAfs8inBvrXFOdf4GvZOrgtMynJcRcQw7Kqc4kFAwovafCm1wTPvMAFbf5MO5iBisfNBnyZZlQ2rXXIIJz4gzKr/j9OlsALSWMXnvS6uSlfyvE+noNRPCB+cB/zudwzsa60e85YxGeB32/pDTK/eFKmqo2lHhGFe2A1uNYTgo5k= Received: from DM6PR11MB2841.namprd11.prod.outlook.com (2603:10b6:5:c8::32) by DM5PR11MB0057.namprd11.prod.outlook.com (2603:10b6:4:6b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.15; Thu, 11 Nov 2021 20:46:20 +0000 Received: from DM6PR11MB2841.namprd11.prod.outlook.com ([fe80::74cd:ce34:6dcb:11b4]) by DM6PR11MB2841.namprd11.prod.outlook.com ([fe80::74cd:ce34:6dcb:11b4%7]) with mapi id 15.20.4669.016; Thu, 11 Nov 2021 20:46:21 +0000 From: "Jan Lindblad (jlindbla)" To: Netconf Thread-Topic: Open question 3/4 "Allowing client side allocation of Etag values" in draft-lindblad-netconf-transaction-id-01.txt Thread-Index: AQHX1z0uB+WL4NRsKkCTUHwwpzXrNg== Date: Thu, 11 Nov 2021 20:46:20 +0000 Message-ID: <3DD6F22F-D0FC-4EB0-BAA0-906A24C4E32F@cisco.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.120.23.2.7) authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f7ce807c-f1a0-44a9-4a66-08d9a5545160 x-ms-traffictypediagnostic: DM5PR11MB0057: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iDH5kLRYo7IOhhPGVPJpBfTKipzR/Y63ZRPFz6vyGRjDXiio9A6Y2dSvEctiAR1672XFNZhrFMODd7YpZljWCpB4nTXJ8Se7zQiBh9LDD/Nacku0E76j2IfeW72cRFD6pBqKaccRxVVkH8zWfh8VfXVN5OC8Ld5D89hJj9KvH1+heI4BStSBYR+HrhQW5cnC+8MDa4FrqTTCqwIvXjK1UzKGv3kdEnBFZuPF6t+zZRubP49LFOiFmV1U0fav8u0nElnVvUk2D/zHCE3hBtHtw0gvBJHumpfOQDTzmCF28nrfbAFeKbROW8hDQ7PWwyQ75hu7reEaiJrkjq3Db8T+jwu4FaCQEHLXBl9ETqbou124LK8gLYTvMcRJ9FMbn31byUkAuRBQNq3lGOtCtlEopDghljS9nBh85LYj0/8ZVZFWumMJZtr/KzyMGR5+NqXfkM6WGh0KyYbyWdyHkRnY7nkbNeRj/xhJ100CjA7fUW+bMO4IlAYk9mejHi88sxmXHgDg1InSFd1zpjeX9MMmUKsK2j+3YRq8xv8R+l1hgHOrmWPQdBO7duEt8vIZmIXfk7zWQHuHe0Qh9BOPLYlgTANG+l3owNPbNSk7H6Et87H9ICrpD6C7/n+DBSitKTWLyb1kQR4eUwvevYNpD/PvWNsLZhW4o9GHvfpI2NGuZ9lF0PvZoORGviH36pXSNzTsQbNXtKCptEcqkRezHKdkiRNZUA03/vvW5r11M0Xtea1zbOLLE9Vj3XQtoj0/VTLnw+2u/xb93Ven4ZUX4PsFiN8r6C8QVn8vKz5AxAnGjluWFBaH6wR1ark5aUKu+UBTwZnnzBUQ7tw4bt6dB20DonjDXymSkKPZyb+n9KHUIus= 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)(316002)(6486002)(38100700002)(508600001)(5660300002)(6916009)(8936002)(66446008)(966005)(36756003)(76116006)(66946007)(91956017)(66476007)(33656002)(38070700005)(2906002)(122000001)(66556008)(64756008)(4001150100001)(6512007)(6506007)(53546011)(71200400001)(66574015)(2616005)(8676002)(26005)(86362001)(186003)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?5UmCR5bnC6RF7cajiGMxaTUlP6oL6QLfGKEOrBSQ8oF0zoOWg8NT64NE3IPE?= =?us-ascii?Q?EHsVufA+xlQfJOwXBi0jBh6aQryr8qO24vZJJbxYhXE81LauzsX6bcS71GsN?= =?us-ascii?Q?YN3YvPa6HOa64v5hmOfnSBgsDyG6zZV4pWAnGgN+/OBJSaoRZDrvxoBETiMW?= =?us-ascii?Q?mC8j2eU+hxUAFPpKCVYXf46+wtBFvGaLs5+XWmQIgqPGJC6thtSSGwJgM1da?= =?us-ascii?Q?Z13SaQJaTlZZssHGrMcyqVuIGdBfrnnfm2jublf6flvWxw4emLVoTl1QhrXA?= =?us-ascii?Q?1Xu9uwknDinODDp94pYdC1Oby0F6NL8fLK7MXT3nV/SI6QIRQ9ULc3Xb25kA?= =?us-ascii?Q?e6tJrFebly11tIY5/DusZhHoTjieaOdu9wtQWlZT7sysuhWCfOM5AetF8l9G?= =?us-ascii?Q?LA4zy3vLdxkBiYjZliL6J7ttMIvaNdlQ1gz9/u9w8+3Dz5OFE7+W17JJl61N?= =?us-ascii?Q?OpdG23yYt/zPN5e6esrD/9iElguV/748KylPaMWfKhWCTIWXjkFFroPxEnVS?= =?us-ascii?Q?6v/0JoDaIkUWMvEORYZA4+1VEffSug20qw40uuZ9wQSqWoCIUc96tL5zMbzk?= =?us-ascii?Q?5mc3PXN53k01rkMEamYxinDhHAoZyl3/E7jNElrw2nboDk9mA1sjx2mUNSz9?= =?us-ascii?Q?AkRU1cZC9HwErkjHhKQok+DOCbqFIFa+Ib8MuyL6brWrIwZYlR6kBJsjxYh7?= =?us-ascii?Q?qAxMkNXJbawWuM2OrgJ50UzI4nzklBNcq68iEY0Ucdm5xAN7guk8FiQdHbhW?= =?us-ascii?Q?HLipnMctgM9YYEYrnU9xfpgInZAAw/XqhAd7RE2ScT+4qgxQEp8D2Z9Ew06g?= =?us-ascii?Q?X6zqYdqjNeeSilcGath5x5kcBfyULQ+l1UhvzV+MTmoxf+NwIJH7OzsjbrZ7?= =?us-ascii?Q?4tiMgyYAgA0qbir3fuUSELGCCeaAKd4AlecAtKi3kjLrDMlViIsJUtN8tPyO?= =?us-ascii?Q?9C0Q+DXsD86kWYUPZxAQaP0jMSGlWdpiaOqp+GQYWCmbKBOa889eDJMD5W6D?= =?us-ascii?Q?XJm8JR3rO1uhtRLO+EBwaU8meE1j5Ne3nzt/eru9rbGaKUe3bbIU7+xi1bcl?= =?us-ascii?Q?9ltLinMC8O6Ms8m7p6dG3/eCgRw6rSJBweTVoj9fd/J2fOhxnEyFh/20wL0E?= =?us-ascii?Q?dZqh6js6gp3l7VghB54IK0Vf5tmAUtbbimySV2q77+3GvRn9CDLWKxKFj5tE?= =?us-ascii?Q?2loIK6kFC9tAEcMMC8+kwP2hpkb4s8e+24DFqY/wJQoPjTzx1ce0XvtMTgCe?= =?us-ascii?Q?7By5S/clEHY3gfRXVEGJ22ZSCam7YNM30mFbimcUDFPojUmzbU7NJ8Ei/cfz?= =?us-ascii?Q?q26wv5cK1okhLdpQHsPwDBhn9oXtTaWoWo7QNGgj0yr75fI4KaLQ9RrqFX5O?= =?us-ascii?Q?CvrEXoTZbpXr5w8XW+OfPN8Lp9brP85CcBdEWOTQXXjti/EBIOBeV85o9Kwy?= =?us-ascii?Q?8s5/KKXntqLQFKdkhGs3wN/uub4wbI9rSuUL1wyoiuA0RZoutht5TqcfSZgJ?= =?us-ascii?Q?l7FTmCN1/YtxU30irRVsnRy5kFW2eawWO4XZQpbTqC+9zJcLnZOSEef//rFE?= =?us-ascii?Q?bI2daLnrptsBQUiYaVX7ZYAQh3Wg6dwi9eJ+25g77/Au36IHC9CQkBsJDkLO?= =?us-ascii?Q?TeMijbMjpNZyYdvqrno0b6I=3D?= Content-Type: text/plain; charset="us-ascii" Content-ID: <6C312C3655916941A96BE1E7FF269322@namprd11.prod.outlook.com> Content-Transfer-Encoding: quoted-printable 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: f7ce807c-f1a0-44a9-4a66-08d9a5545160 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2021 20:46:20.8817 (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: 1s5A42NAkBJtQ7OkcQ4UtbOWjxcyqaqJWWzzDysbsTTRrb65KhSmynX/5CwcK768fepEY47SI1+DDePn99TuaQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB0057 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.19, xbe-aln-004.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: [netconf] Open question 3/4 "Allowing client side allocation of Etag values" in draft-lindblad-netconf-transaction-id-01.txt 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, 11 Nov 2021 20:46:29 -0000 Hello NETCONF team, This thread (3/4) is about Allowing client side allocation of Etag values: = at the NETCONF WG session earlier this week, the chairs asked me to start a= separate thread for each of the outstanding question relating to draft-lin= dblad-netconf-transaction-id-01.=20 Should it be possible for a client to specify which Etag value the server s= hould use for a particular transaction? Proposed solution #1) No, this is not needed. IETF or another SDO is of cou= rse free to define such a mechanism at a later time, and an implementor cou= ld define a proprietary mechanism. Proposed solution #2) Yes, but it should be an optional capability for a se= rver to implement. If available on a server, it would also be optional for = a client to use it. Proposed solution #3) Yes, and it should me mandatory for servers that impl= ement the Etag mechanism to also support the timestamp mechanism. It would = be optional for a client to use it. The -01 draft specifies solution #1. Please indicate your preferences among= the options. Comments or suggestions for other options are also welcome. Comments: Without this feature, the server will have to generate valid Etag= values. If a server supported this feature, and a client chose to leverage= the possibility to specify an Etag value, the server would simply use the = Etag value specified by the client instead of generating a different value.= This is trivial to implement. This mechanism allows the client to know bef= ore hand what the Etag values will be, and does not need to keep a transact= ion hanging until completed by all participating servers. This would signif= icantly simplify and speed up high cadence orchestration scenarios. Best Regards, /jan > On 22 Oct 2021, at 13:28, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-lindblad-netconf-transaction-id-01.txt > has been successfully submitted by Jan Lindblad and posted to the > IETF repository. >=20 > Name: draft-lindblad-netconf-transaction-id > Revision: 01 > Title: Transaction ID Mechanism for NETCONF > Document date: 2021-10-22 > Group: Individual Submission > Pages: 22 > URL: https://www.ietf.org/archive/id/draft-lindblad-netconf-tr= ansaction-id-01.txt > Status: https://datatracker.ietf.org/doc/draft-lindblad-netconf-t= ransaction-id/ > Html: https://www.ietf.org/archive/id/draft-lindblad-netconf-tr= ansaction-id-01.html > Htmlized: https://datatracker.ietf.org/doc/html/draft-lindblad-netc= onf-transaction-id > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-lindblad-netcon= f-transaction-id-01 >=20 > Abstract: > NETCONF clients and servers often need to have a synchronized view of > the server's configuration data stores. The volume of configuration > data in a server may be very large, while data store changes > typically are small when observed at typical client resynchronization > intervals. >=20 > Rereading the entire data store and analyzing the response for > changes is an inefficient mechanism for synchronization. This > document specifies an extension to NETCONF that allows clients and > servers to keep synchronized with a much smaller data exchange and > without any need for servers to store information about the clients. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 From nobody Thu Nov 11 12:47:53 2021 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 171E43A0E23 for ; Thu, 11 Nov 2021 12:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 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_H2=-0.001, SPF_NONE=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=dZYOEajo; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=JVZm2iBZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpIO2r6yLaBP for ; Thu, 11 Nov 2021 12:47:46 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C84B3A0E2D for ; Thu, 11 Nov 2021 12:47:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2957; q=dns/txt; s=iport; t=1636663666; x=1637873266; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=bYa5cTR5CBE9pwNQs0dB2IPGeSSTuPyH//P5AYqz+9M=; b=dZYOEajosULZ38jUj08LFszGSsgHPBh3fHdeSY+17JPsw1jH/tOPW2/t X7WLgjIJTrb3HbIqfFx2AiLYeAB/MtaUUul7VLo84b8ishUzQhIXl2jUf DTEmngHfUgxdW+ynYzxS0kmAirHYweH6kxovhnY6zf8X4DIM3fcWM5tYQ A=; IronPort-PHdr: =?us-ascii?q?A9a23=3ApAA1fxBA71uzUr39QxYXUyQVdBdPi9zP1kY96?= =?us-ascii?q?5c7hfRJaKvwt5jhPUmK4/JrgReJWIjA8PtLhqLQtLyoQm0P55uN8RVgOJxBX?= =?us-ascii?q?hMIk4MaygonBsPWCEDnIrjtdSNpVMhHXUVuqne8N0UdEc3iZlrU93u16zNaG?= =?us-ascii?q?hj2OQdvYOrvHYuHhMWs3Of08JrWMG11?= IronPort-Data: =?us-ascii?q?A9a23=3AAwsyl6h1jOy3ZNEG9HiEpyd9X161fBIKZh0uj?= =?us-ascii?q?C45NGQN5FlHY01jehtvCGyFO/qCNjb8KdsnYY7i8E4OucXSzoIyQAA9pCsyR?= =?us-ascii?q?XljpJueD7x1DKtf0wB+jyH7ockOA/w2MrEsF+hpCC+DzvuRGuK59yAljPjRH?= =?us-ascii?q?uOU5NPsY0ideyc1EE/Ntjo78wIJqtYAbemRW2thi/uryyHsEAfNNwpPD44hw?= =?us-ascii?q?/nrRCWDExjFkGhwUlQWPZintbJF/pUfJMp3yaqZdxMUTmTId9NWSdovzJnhl?= =?us-ascii?q?o/Y1w0mBtXgmbHhfwhUBLXTJgOJzHFRXsBOgDAb+Xd0ifl9ZaFaMBoI49mKt?= =?us-ascii?q?4gZJNFlt5ixTwsjOqTkk+UGWB4eGCZ7VUFD0O6acCXj6pzOlSUqdFOpmZ2CF?= =?us-ascii?q?noeO4AE8eFxD0lP+OAWbjcXYXi+a0ieqF6gYvNnisJmJ87xMcZB/Hph1jreS?= =?us-ascii?q?/0hRPj+r2zxzYcw9F8NagpmRJ4yv/YkVAc=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AbMCDuqg4wh/wmY8RNAxufuc/nHBQX3d13D?= =?us-ascii?q?Abv31ZSRFFG/FwyPrOoB1L73HJYWgqN03IwerwQpVp2RvnhNFICPoqTMqftW?= =?us-ascii?q?7dySWVxeBZnMffKljbexEWmdQtrZuIH5IObeEYbmIKzPoSgjPIaOrIqePvmM?= =?us-ascii?q?vD6IuurAYOcegAUdAG0+4NMHfjLqQAfnghOXNWLuv52uN34x6bPVgHZMWyAX?= =?us-ascii?q?cIG8LZocfQqZ7gaRkaQzY69Qinl1qTmf7HOind+i1bfyJEwL8k/2SAuRf+/L?= =?us-ascii?q?+fv/ayzQKZ/3PP7q5RhMDqxrJ4dY+xY4kuW3fRYzSTFcBcso65zXcISSaUmR?= =?us-ascii?q?AXeez30lId1gJImirsly+O0EPQMkLboUoTAjfZuCClaD3Y0JfErPZQMbsduW?= =?us-ascii?q?qfGSGpsXbI9esMoZ5jziaXsYFaAgjHmzm479/UVwtynk7xunY6l/UP5kYvGr?= =?us-ascii?q?f3+Ndq3PIiFW5uYd499RjBmcga+ShVfbThzecTdUnfY2HSv2FpztDpVnMvHg?= =?us-ascii?q?2eSkxHvsCOyTBZkH1w0kNdnaUk7zo93YN4T4MB6/XPM6xumr0LRsgKbbhlDO?= =?us-ascii?q?NERcesEGTCTR/FLWrXK1X6E6MMPW7LtvfMkf8IzfDvfIZNwIo5mZzHXl8dvW?= =?us-ascii?q?kue1j2AcnLx5FP+gClehTKYd0s8LAo23FUgMyOeFPbC1z2dLl1qbrRnxw2OL?= =?us-ascii?q?yoZ8qO?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B1BwAWgY1h/51dJa1aHgEBCxIMQIF?= =?us-ascii?q?OC4FSUQd3WjcxiA4DhTmFa4Ilmw+BLoElA1QLAQEBDQEBNwoEAQGHYgIlNAk?= =?us-ascii?q?OAQIEAQEBEgEBBQEBAQIBBgSBEROFaA2GQgEBBBMoBgEBOAQNASAeQicEExs?= =?us-ascii?q?Hgk8BglUDDiEBDqB0AYE6AoofeIEzgQGCCAEBBgQEgToCDkGCfxiCNQMGgTq?= =?us-ascii?q?DDIJ8VIdQJxyBSUSBPByGCAEBAQEBF4Eug2eCLo8kgTAEUQIUfU0mNi6RfiC?= =?us-ascii?q?MZZ9QCoM4BYpLlDEFLYNsi3OXTZYUVYwflAYIYwGEHQIEAgQFAg4BAQaBYTu?= =?us-ascii?q?BWXAVGiEqAYI+PhMZD44gN4M7hRSFSnQCNgIGCwEBAwmPdAEB?= X-IronPort-AV: E=Sophos;i="5.87,226,1631577600"; d="scan'208";a="959543852" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Nov 2021 20:47:45 +0000 Received: from mail.cisco.com (xbe-aln-006.cisco.com [173.36.7.21]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 1ABKlj76010682 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Thu, 11 Nov 2021 20:47:45 GMT Received: from xfe-rtp-005.cisco.com (64.101.210.235) by xbe-aln-006.cisco.com (173.36.7.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 11 Nov 2021 14:47:44 -0600 Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xfe-rtp-005.cisco.com (64.101.210.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 11 Nov 2021 15:47:43 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Thu, 11 Nov 2021 14:47:43 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZDxCS7Owr4VqBamheP4hH+cyJKqxzK8XjdWESUTVRWijXpcHIUiAI31OMAAlbV2oYhnom0ZUkUGdUxED2WNCOQS5iyFm5eVgWcZC24/bfBYXqfcnDHtcCtUdU/HYUdotNVHCB6Fqa6EVrz5QlMbVoFi29oYyaYjIx8B+fY3NdWS3OE9DlK8/qsepQLS6RHtbfrqi6sKpzJOa065YUB+53KwU5smp0sxoDK/cga86wCBVZfYVXr9peB/3iDvGS6Kiy5Nf/32R08SragQKdwDGs5z41KPCo+mfxVPyFm/Ep93i/lk+2Zet2YgyidbBE/orXz742lI0lz1mpsfQy0c56A== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TlGPHPhD8kYG8NXXPu0hMMACBLjhMFADow/bDzpbVlg=; b=G5Q4ifKdkBwsaoniLtrvEJM+ijGqdU1wB0urb2eY4Du3+guKEcYdQbWpxMplBKntTFyhtxDA9MD1Un1cd/F9/xC/8S6PA7E0+4iSD/fPxCwGv4jYKBUFG5CCUSQXO4Q+YuoPXWspB6BcqAeHe/SlA8GAZDPRywaWxEZW4jAJ7KNvVl4fe0Qb69xvLdkFmpT3f8JSGSCSa3FCNIyyIdyYppAspHucISMWk1TnLoc8N717GEwI6h4C+HfQvqpJstVUPVhoaQP4uFwLaGBlSqlPRcdMadn6Oh4+yc7jjrleDpt1TF5J74r43yYzzz1t1u2ShH5mX/LjRcDJ14GPgmG3lA== 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=TlGPHPhD8kYG8NXXPu0hMMACBLjhMFADow/bDzpbVlg=; b=JVZm2iBZN01yOXrPrZ5sqsvgQrspCzL+K+rLKoKFIyUdnMfHe7zMdFvwvfBlyFfGFLNkmOcnhDv4Ckwy5c9Kg6lk2i4omRm4+1DRWDRYgMZYUSoDUpFOINmOapCkTY161Y3JkfvtdPzwYnSf/QQbK5sUBg6rbRvbZ61UnjcaHR4= Received: from DM6PR11MB2841.namprd11.prod.outlook.com (2603:10b6:5:c8::32) by DM4PR11MB5264.namprd11.prod.outlook.com (2603:10b6:5:38b::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.10; Thu, 11 Nov 2021 20:47:42 +0000 Received: from DM6PR11MB2841.namprd11.prod.outlook.com ([fe80::74cd:ce34:6dcb:11b4]) by DM6PR11MB2841.namprd11.prod.outlook.com ([fe80::74cd:ce34:6dcb:11b4%7]) with mapi id 15.20.4669.016; Thu, 11 Nov 2021 20:47:42 +0000 From: "Jan Lindblad (jlindbla)" To: Netconf Thread-Topic: Open question 4/4 "Granularity of Etags" in draft-lindblad-netconf-transaction-id-01.txt Thread-Index: AQHX1z1fo+6gKNA+1Emmr1/8326/vA== Date: Thu, 11 Nov 2021 20:47:42 +0000 Message-ID: <9F766580-DE33-44E1-B2B1-5EA8A43C455A@cisco.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.120.23.2.7) authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1e4664ea-2297-4d53-d0bf-08d9a55481df x-ms-traffictypediagnostic: DM4PR11MB5264: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vWZRhfE3XUjZju2HVdfSxUj+uaCWQ1rrhWqTnCBpIeSXscr0vOkvXD88yt6y/K+WuOwHjNSdF1CfuCO4AxLcHBQMWgmG/D89P/I5pXsNKkIj3z4e7gfTWoRvhOt99HWZKmSxRMsiKAVnyDNmbBxB15p74b4RSYFOdBi9BcKVZQj/pYZ9chE/ivOvHubSpciwlBq+ii2PD+FZKC0bss+5Xw+NW1Toxg365yiry6LrGghg3GDgRLjPcfXwMFAhNpnqhSGnEUNv1als0jBns3FMZnPEkxB7eKfYkD8onHehYKMSDvvB+Pw7+22mXjtbDqomnC6kbgfMtW+qgwLTpuuTSuSrT0mwXz6OPzbnROJqRMhBDlki0MUYtkHiMbDhQmEcD4uAqKAbUSDIao1AogJvWRNBPK677TtJsFxSTjF3xawIhYzbO/VJSoCHkmVmtiqveaF6/23e77vIoWQX2lYEXAKbVOJ5HTCgluBNhJBIxdxl3F8MbL2kFu2icBkpXZvknjigokQH04CU5gdvJdqIqu8dW9hSjMSMB84ka5FT3m0/GivI39dY4jsHdceZ8DIih6QIm0DLFJi1SjwZ1k/ydl65R8qcwDQTfJC2FLCyeSTIxi0CxLk27eIGhS2xnmUvUB6Z0wIw6QS3Luvrc5Z91oYMocX5ON6H5EIKY2ZkKzqYQeT4tYHG/tWFLzlUd3OYFOS2MDPGnU3riFe50I/7p/ef/IYVvl0MrOjoRj2IdslbNTXy1ric2C263zhQlVP5mzwORebzM8iRPaK1gseGNl+zHDJNrLxiTG2V2tsz1CG6idots69Pb50bAo0prmlUQ2wR7Otaiu2DveR0oSHyY/JHuBWH3GVf9Hdv5g4gXCA= 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)(4001150100001)(38070700005)(316002)(8676002)(66574015)(6512007)(508600001)(966005)(6916009)(33656002)(38100700002)(2616005)(8936002)(186003)(36756003)(66446008)(66556008)(26005)(86362001)(6486002)(122000001)(76116006)(6506007)(71200400001)(2906002)(66946007)(91956017)(64756008)(5660300002)(53546011)(66476007)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?yQMdT4wLH1OU2AXCUTdXzdvR4Srgj0CHEhpl7nTIJziwIhA3CkNr1VdT+Nkm?= =?us-ascii?Q?qaYnPGmNZcbEwDj/Ca7YI5QkLGEC/C8e7zbqaNEOchD+gxqfJagjijSnOqZM?= =?us-ascii?Q?e+sI62zkyqosOX5tM0AupUek/KzHjb+gQnpopTeElQ8dGdhrjLjtYCWZ9jko?= =?us-ascii?Q?bX7CCqOmndYFVnuyUehANxjVjsJEgizb2QP51VovHakssxT7z073VzcXGwhK?= =?us-ascii?Q?VLBP08WJo3caUvV6YnCVUnfqZ+eFyyAZr1aMMcLLm4ZmMWDsGRlwnE01GzlY?= =?us-ascii?Q?8aTC7zi3u2GD4lssJ0JAiLJOgHWGJ0Odc3v1rrJOudQKSu3JtH+qoOrqXKLg?= =?us-ascii?Q?fFps4UqjAsDrX7ig99Y8RbFL3qiKyJC7HV8Jg0zscYctlmXiEhzglQXjotGg?= =?us-ascii?Q?DICjPdMnCv6oUUHFkfY0Vq3NqDUapRcL+uIngLUV+5D6n25VKZh8zx2x4xs/?= =?us-ascii?Q?W7qo5CpYpdGnUUzcZTPcDvNz1N/SH1visnx4Z9fzKKq8lmvF2eanFnthi+VF?= =?us-ascii?Q?i7Ei0yz82WmVPcOpsC3piDte20b2cl7nPiQAzjTs1wpvNnoLJbwZpilJNiY3?= =?us-ascii?Q?xKAe3KJAdjd3aMsPQY7U3QUJfs9pi/sZ+nzXcH0lHkG94HZeKhb9woGYFpFo?= =?us-ascii?Q?LEo724R0M2C6ZN0A53F/YFYoCwWIwVn8+bHEfjDr2cCWfxmxwEea73KWIlfh?= =?us-ascii?Q?r+BpzmVPb3yws0vUpU16r4x0jpDvXKBj88JgqA1V765eNBqmiGS46jTqDJfh?= =?us-ascii?Q?oXUv+wiQ5JkeE2jPouOjnXiNauYK52OddG2N2/OlRKFi3mwGKS126rt9ccLu?= =?us-ascii?Q?MOdl397abgOZ8e2PB/cdxNCId3CbF8L1q8vLsYf6JjSIfd4b59MY0SH18QvQ?= =?us-ascii?Q?MuYLq+oaZ1Ad1ZFfJpA6oLYzkaO+/Vvl245JgdW+9p5wA5uB3UqhFXOJtt9z?= =?us-ascii?Q?JtGf8tMG+vQArCBN3TCMN1tR0T05n3RI2tY+XG0L02WOlA18HwX1uHiLJ8UE?= =?us-ascii?Q?YQvMeiOcg91nEGAbNE2YoDuj9eTRyfiubj1QiGhNeYnC+Xe4qlVd5TZ6rGHJ?= =?us-ascii?Q?trUzGIRFUrryagkgBWtXpIlpX6IZIeicsw8rIRED5sjlGDWPzXioN6OVKaI6?= =?us-ascii?Q?/fuKg2Rq+lh+zxumdsFXgzIwSDadLCRoIy3FTwIBmJorSWU6SxzFk1AvW4WD?= =?us-ascii?Q?v9MAHL1RyRi0iiGppl/OxEvo2Se1zeXjl3pnIHg/6pKfxnBcAl9WUKoHrhts?= =?us-ascii?Q?nJ7AS3uSeLq8UGtg1zBPwwtsgZ4oU5sCJgOx+e2p/3eV1DRSrVK0ntsH590Q?= =?us-ascii?Q?nifRsWAhABQJkvKsr7ASW6tJtGUOwGJbc/zQdlNujXX0sS9NaSrn9z4rchnT?= =?us-ascii?Q?RI59+Of70VQT1LZ/ZizyUJML6+1tdP8BRDUv68gtQnkO1aRN6PcmxfNhCUGC?= =?us-ascii?Q?Hcd37vwwNBZJhtKsjbLFZaynpUqEt0rNLbKIKdNhm3xCCP3/WNR8RKGpwJhs?= =?us-ascii?Q?CdwcUqQ0z8phalaV+zPa/sO7Z/CWIjGvUefQdsh1cliseIXOE7CysXB4I38q?= =?us-ascii?Q?NPDppDPB093bCbXmj9+90v2Gbk/h5DHg8NPpMm9ISeMaDjTggxzpJjz1Tx02?= =?us-ascii?Q?ydGGIIjqnEyft26nmtL2zjg=3D?= Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable 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: 1e4664ea-2297-4d53-d0bf-08d9a55481df X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2021 20:47:42.2551 (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: 8Lzh3052zidOAW7b2jFz4mLJrxnmsM8lPeWmcddtSs3buU6ZRJCA5zH82rL1S5fBu7YrLm20DsLTEPes7qNidA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB5264 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.21, xbe-aln-006.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: [netconf] Open question 4/4 "Granularity of Etags" in draft-lindblad-netconf-transaction-id-01.txt 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, 11 Nov 2021 20:47:52 -0000 Hello NETCONF team, This thread (4/4) is about Granularity of Etags: at the NETCONF WG session = earlier this week, the chairs asked me to start a separate thread for each = of the outstanding question relating to draft-lindblad-netconf-transaction-= id-01.=20 Should it be possible for a client to specify which Etag value the server s= hould use for a particular transaction? Proposed solution #1) Etags are only available at the datastore top level Proposed solution #2) Etags are available at the datastore top level, and s= ome containers and list elements, as decided by the server implementor Proposed solution #3) Etags are available at the datastore top level and so= me elements (containers, list elements, leafs, ...), as decided by the serv= er implementor Proposed solution #4) Etags are available at the datastore top level and so= me elements (containers, list elements, leafs, ...), as decided by the clie= nt in runtime The -01 draft specifies solution #2. Please indicate your preferences among= the options. Comments or suggestions for other options are also welcome. Comments: For some use cases, solution #1 may be enough. For others, soluti= on #1 is counter productive, and a more comprehensive solution is required. Best Regards, /jan > On 22 Oct 2021, at 13:28, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-lindblad-netconf-transaction-id-01.txt > has been successfully submitted by Jan Lindblad and posted to the > IETF repository. >=20 > Name: draft-lindblad-netconf-transaction-id > Revision: 01 > Title: Transaction ID Mechanism for NETCONF > Document date: 2021-10-22 > Group: Individual Submission > Pages: 22 > URL: https://www.ietf.org/archive/id/draft-lindblad-netconf-tr= ansaction-id-01.txt > Status: https://datatracker.ietf.org/doc/draft-lindblad-netconf-t= ransaction-id/ > Html: https://www.ietf.org/archive/id/draft-lindblad-netconf-tr= ansaction-id-01.html > Htmlized: https://datatracker.ietf.org/doc/html/draft-lindblad-netc= onf-transaction-id > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-lindblad-netcon= f-transaction-id-01 >=20 > Abstract: > NETCONF clients and servers often need to have a synchronized view of > the server's configuration data stores. The volume of configuration > data in a server may be very large, while data store changes > typically are small when observed at typical client resynchronization > intervals. >=20 > Rereading the entire data store and analyzing the response for > changes is an inefficient mechanism for synchronization. This > document specifies an extension to NETCONF that allows clients and > servers to keep synchronized with a much smaller data exchange and > without any need for servers to store information about the clients. >=20 >=20 >=20 >=20 > The IETF Secretariat From nobody Thu Nov 11 14:28:35 2021 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 A29483A0B19 for ; Thu, 11 Nov 2021 14:28:34 -0800 (PST) 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 IuVyl6iXO6gI for ; Thu, 11 Nov 2021 14:28:30 -0800 (PST) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 704C43A0AD1 for ; Thu, 11 Nov 2021 14:28:30 -0800 (PST) Received: by mail-pl1-x634.google.com with SMTP id b13so6927915plg.2 for ; Thu, 11 Nov 2021 14:28:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xthP5gh8lQxkiO7m4jXoHY3nE8ESKcXXji7GLqqgH3Q=; b=N8nlLn0tBx3uNpUWeMyT8+OuyuqvKMensJlOl1Lco49oO5E64LlU6FGNfgU9b16fE4 S3UCtLc/KE3cOEeoZk1mTdxCBd6WJZT1+uW8KZ78tQyHRaUkPkIakeCh8edCGodM+4LO ekkmuF8fZeRF4M8zEBnK86sf3PHTT/FZTcr23zZuUggCgVnsEb26VPqWc7tJCTQBI4nY lrZ1dQgtnHHCmUeaZl6LzUJytnS7WVaQqjOrv3koimMHWk2P661RnL9/a2WBIkqnhbz4 l/tjuGxtXjB0Ymogc2U4TjAuap98YiOLBuYqSHi3YUZzs4uG3+cUxMgUENQq/yjZpPUA XQyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=xthP5gh8lQxkiO7m4jXoHY3nE8ESKcXXji7GLqqgH3Q=; b=8DmWKfJq2vGYPzY63mZJ0ecy87VJRh7/g85Jq7Mf76PZvX02MyE17CHyfd1ttJlJbS F8seBu8QOkj+Hbt7ZYAFQ4TFh0qOYvIG6CCWDTyTrdne5UHNoO39Bkl8MdLG9k9ZeFRQ VekXFi/a600rUKfA4GvIRK8sou/ktlhqGsWWEan0UnpVNPN3UdrEc4dcvcn740y9lHPh LCx1che7JPM9txcvgYjpeMeLfa8DpsB4qW3pBaTcAvOGGptj7zmruTccjVRnwy08nHgu arbfkP+d6BbhVVHHtkkn5hpK0xvZ21EEekWRccQpD4mJiRfs7VrrSCZOAnF6k1LaWdMu 7DYw== X-Gm-Message-State: AOAM533CQQkxOWY2N7YJgixA3PAHDHaHQqVMlcrpq0mR0vKj4pX/HTx+ /BRdlnlRzVyTaihW5c2tEExKPdnw1RRNNg== X-Google-Smtp-Source: ABdhPJxD8r4M46s7eSfFY+lKsjjvsMgd5cXWea9B4wSroUcZdx67lqf5C7blH5azc84WsGahDtHukA== X-Received: by 2002:a17:90a:ec0a:: with SMTP id l10mr12178554pjy.92.1636669709047; Thu, 11 Nov 2021 14:28:29 -0800 (PST) Received: from [192.168.1.133] (c-69-181-169-15.hsd1.ca.comcast.net. [69.181.169.15]) by smtp.gmail.com with ESMTPSA id t13sm4058899pfl.98.2021.11.11.14.28.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Nov 2021 14:28:28 -0800 (PST) From: Mahesh Jethanandani Message-Id: <2EEB0710-D2F2-4503-A431-8F11EB7A2495@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E9CEA152-80D4-4D24-98D2-D08616F8811A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Thu, 11 Nov 2021 14:28:26 -0800 In-Reply-To: Cc: Netconf To: "Jan Lindblad (jlindbla)" References: <163490209138.9955.12584931650278112847@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [netconf] Open question 1/4 "Etag values" in draft-lindblad-netconf-transaction-id-01.txt 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, 11 Nov 2021 22:28:35 -0000 --Apple-Mail=_E9CEA152-80D4-4D24-98D2-D08616F8811A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [As a contributor] My preference would also be solution #1. That way the application logic = remains the same, and does not depend on whether the request/response is = being send/received over NETCONF or RESTCONF. Cheers. > On Nov 11, 2021, at 12:40 PM, Jan Lindblad (jlindbla) = wrote: >=20 > Hello NETCONF team, >=20 > This thread (1/4) is about Etag values: at the NETCONF WG session = earlier this week, the chairs asked me to start a separate thread for = each of the outstanding question relating to = draft-lindblad-netconf-transaction-id-01.=20 >=20 >=20 > When clients and servers send and receive Etag values, what should be = the value space and semantics associated with them? >=20 > Proposed solution #1) Use exactly the same value space as specified in = RFC 8040 (RESTCONF) which in turn points to RFC 7232 (HTTP Conditional = Requests) sec 2.3. This means the Etag is an arbitrary length string of = 8-bit characters of the server's own choice, except it must not contain = ASCII control characters, space, backslash or double quotes. >=20 > Proposed solution #2) Server uses a monotonously increasing integer = for Etag values. Special cases like behavior at server reboot have not = yet been discussed. >=20 > Proposed solution #3) Server uses an arbitrary length string of UTF-8 = characters of its own choice. >=20 >=20 > The -01 draft specifies solution #1. Please indicate your preferences = among the options. Comments or suggestions for other options are also = welcome. >=20 >=20 > Best Regards, > /jan >=20 >> On 22 Oct 2021, at 13:28, internet-drafts@ietf.org wrote: >>=20 >>=20 >> A new version of I-D, draft-lindblad-netconf-transaction-id-01.txt >> has been successfully submitted by Jan Lindblad and posted to the >> IETF repository. >>=20 >> Name: draft-lindblad-netconf-transaction-id >> Revision: 01 >> Title: Transaction ID Mechanism for NETCONF >> Document date: 2021-10-22 >> Group: Individual Submission >> Pages: 22 >> URL: = https://www.ietf.org/archive/id/draft-lindblad-netconf-transaction-id-01.t= xt >> Status: = https://datatracker.ietf.org/doc/draft-lindblad-netconf-transaction-id/ >> Html: = https://www.ietf.org/archive/id/draft-lindblad-netconf-transaction-id-01.h= tml >> Htmlized: = https://datatracker.ietf.org/doc/html/draft-lindblad-netconf-transaction-i= d >> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-lindblad-netconf-transaction-id-= 01 >>=20 >> Abstract: >> NETCONF clients and servers often need to have a synchronized view = of >> the server's configuration data stores. The volume of configuration >> data in a server may be very large, while data store changes >> typically are small when observed at typical client = resynchronization >> intervals. >>=20 >> Rereading the entire data store and analyzing the response for >> changes is an inefficient mechanism for synchronization. This >> document specifies an extension to NETCONF that allows clients and >> servers to keep synchronized with a much smaller data exchange and >> without any need for servers to store information about the clients. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >>=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_E9CEA152-80D4-4D24-98D2-D08616F8811A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii [As = a contributor]

My = preference would also be solution #1. That way the application logic = remains the same, and does not depend on whether the request/response is = being send/received over NETCONF or RESTCONF.

Cheers.

On Nov = 11, 2021, at 12:40 PM, Jan Lindblad (jlindbla) <jlindbla=3D40cisco.com@dmarc.ietf.org> wrote:

Hello = NETCONF team,

This thread (1/4) is about = Etag values: at the NETCONF WG session earlier this week, the chairs = asked me to start a separate thread for each of the outstanding question = relating to draft-lindblad-netconf-transaction-id-01.


When clients and servers send and receive Etag = values, what should be the value space and semantics associated with = them?

Proposed solution #1) Use exactly the = same value space as specified in RFC 8040 (RESTCONF) which in turn = points to RFC 7232 (HTTP Conditional Requests) sec 2.3. This means the = Etag is an arbitrary length string of 8-bit characters of the server's = own choice, except it must not contain ASCII control characters, space, = backslash or double quotes.

Proposed = solution #2) Server uses a monotonously increasing integer for Etag = values. Special cases like behavior at server reboot have not yet been = discussed.

Proposed solution #3) Server = uses an arbitrary length string of UTF-8 characters of its own = choice.


The -01 draft = specifies solution #1. Please indicate your preferences among the = options. Comments or suggestions for other options are also welcome.


Best Regards,
/jan

On 22 Oct 2021, at 13:28, internet-drafts@ietf.org wrote:


A new version of I-D, = draft-lindblad-netconf-transaction-id-01.txt
has been = successfully submitted by Jan Lindblad and posted to the
IETF repository.

Name: = draft-lindblad-netconf-transaction-id
Revision: 01
Title:= = Transaction ID Mechanism for NETCONF
Document = date: = 2021-10-22
Group: Individual Submission
Pages:= = 22
URL: =            https://www.ietf.org/archive/id/draft-lindblad-netconf-transact= ion-id-01.txt
Status: =         https://datatracker.ietf.org/doc/draft-lindblad-netconf-transac= tion-id/
Html: =           https://www.ietf.org/archive/id/draft-lindblad-netconf-transact= ion-id-01.html
Htmlized: =       https://datatracker.ietf.org/doc/html/draft-lindblad-netconf-tr= ansaction-id
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-lindblad-netconf-tran= saction-id-01

Abstract:
=  NETCONF clients and servers often need to have a synchronized view = of
 the server's configuration data stores. =  The volume of configuration
 data in a server = may be very large, while data store changes
=  typically are small when observed at typical client = resynchronization
 intervals.

 Rereading the entire data store and analyzing the = response for
 changes is an inefficient mechanism = for synchronization.  This
 document specifies = an extension to NETCONF that allows clients and
=  servers to keep synchronized with a much smaller data exchange = and
 without any need for servers to store = information about the clients.




The IETF Secretariat



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

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_E9CEA152-80D4-4D24-98D2-D08616F8811A-- From nobody Mon Nov 15 14:53:17 2021 Return-Path: <0100017d25cdeaeb-c6ad2da8-c120-4657-8c99-630a977a3e4b-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 2EF543A0C33; Mon, 15 Nov 2021 14:53:15 -0800 (PST) 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 (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 3id4ywmdgHzi; Mon, 15 Nov 2021 14:53:13 -0800 (PST) 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 756D63A0A90; Mon, 15 Nov 2021 14:53:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1637016792; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:Cc:To:Feedback-ID; bh=IfWpCXvkfio+voG/XYQZ47qVW+/8ekeffxiM9Kjk3fo=; b=LSCnSArt0h4vx78jrE/9yktk/aqup+WOf9Iym21L4lf3mCe4k2Xoe5Lu2BoycNlr VogoKPEYmThvO0fkEmNfUp8wu3ZQ7WmIbArEY3v3ydDI7e6McK4B4Nk9sEgR61YraPN MIzAJ0jESQyTYmlW2K7vZ8E7lo3Q4YY26SAAoNmw= From: Kent Watsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Message-ID: <0100017d25cdeaeb-c6ad2da8-c120-4657-8c99-630a977a3e4b-000000@email.amazonses.com> Date: Mon, 15 Nov 2021 22:53:12 +0000 Cc: "netconf-chairs@ietf.org" To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.11.15-54.240.48.93 Archived-At: Subject: [netconf] Draft minutes for NETMOD 112 session uploaded 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, 15 Nov 2021 22:53:15 -0000 The draft minutes for our session today are both below and uploaded = here: https://datatracker.ietf.org/meeting/112/materials/minutes-112-netconf Please review and send any corrections to the chairs alias (CC-ed). Thanks! Kent (and Mahesh) # Meeting Minutes for the NETCONF 112 WG Session # Introduction ## Chair slides (10 minutes) - Session Intro & WG Status Rob: re: the IEEE liaison on the keystore draft, says that he'll setup a = meeting. Kent: requests all authors to bring discussions to the WG list. # Chartered items: ## UDP-based Transport for Configured Subscriptions (10 min) - = https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-04 - Discussion Leader: Pierre Francois Rob: Need to check with Sec Area. =46rom a quick discussion with the = ADs they may not be happy with allowing unencrypted UDP in a standards = track doc. (2) We should also check that we cover transport issues such = as congestion. Pierre: XXX Kent: I have sympathy for implementations that want to send = notifications unencrypted in a private network. Pierre: Do you think that having this traffic over a secure network = would not be good enough? Rob: Yes, I have sympathy for the the deployment scenario, but I'm still = not sure whether this will be sufficient for the security ADs, they may = think that the cost of encrypting all of the traffic is low enough to = justify Mahesh: Draft talks about a transmission timeout value to be set, but = there is no configuration in the YANG module for that timer? Is the = draft asking for a well known UDP port? Pierre: I need to check for the timeout. We might need to have this = configured, but a default value may be sufficient. Re 2nd question. We = had this in, but we decided that having a single default value is not = really needed and nobody was caring. # Non-Chartered items: ## Adaptive Subscription to YANG Notification (10 mins) - = https://datatracker.ietf.org/doc/html/draft-wang-netconf-adaptive-subscrip= tion-07 - Discussion Leader: Qiufang Ma =20 Rob: Thank you for Qin's comments. I think that you are on the right = track. Okay to allow more complex expressions as long as all = implementions support a minimum level of complexity. Should have a well = defined error code if the expression is too complex. Kent: Arbitrary XPaths may also turn up in list pagination. This may be = a problem if the backend is supported by a simple database. How does = the server indicate to the client what level of complexity is supported. = I see the same problem turning up here and in the list pagination work. ## Transaction ID Mechanism for NETCONF (10 min) - = https://datatracker.ietf.org/doc/html/draft-lindblad-netconf-transaction-i= d-01 - Discussion Leader: Jan Lindblad Kent: You had some open issues, there is no time for discussion. I do = think that we should take issues to the list. Please take the open = issues there. Benoit: I really support the id being issued by the client, or at least = having a way to label the required. Particularly helpful if there are = multiple clients configuring a server, and we want to keep track of the = service request Id. Kent: I do also think that there is value there. Just need to decide = the best way to introduce it. # List Pagination for YANG-driven Protocols (20 mins) - = https://datatracker.ietf.org/doc/html/draft-wwlh-netconf-list-pagination-0= 0 - = https://datatracker.ietf.org/doc/html/draft-wwlh-netconf-list-pagination-n= c-02 - = https://datatracker.ietf.org/doc/html/draft-wwlh-netconf-list-pagination-r= c-02 - Discussion Leader: Qin Wu Mahesh: Out of time, so please take these questions to the list.= From nobody Mon Nov 15 16:10:00 2021 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 8B7653A0CD9; Mon, 15 Nov 2021 16:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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 fKTETr_ZpqUF; Mon, 15 Nov 2021 16:09:50 -0800 (PST) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 9D8143A0CD6; Mon, 15 Nov 2021 16:09:45 -0800 (PST) Received: by mail-pg1-x531.google.com with SMTP id p17so15981094pgj.2; Mon, 15 Nov 2021 16:09:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=AG3FYtTWFKD9P12Qq8bx9usxkv7tivZiG59oe0T0pwY=; b=Yb6HOmfsyrx6aUOmsKpBl3sRMjUdh+g7QPqlyzT/PQbnmq0Vv15JWTJFA0TUcwTnno DufurJxEyvyDec0iozyN1uF4/MTJnIimjtib/vSBvaY+Yl10hu7CV8y2uccPWGoSGs/4 7c9dqPn3a0fM8jzQRY+nF3lDnXBq9zIO4oGJ+cUeztuixPd/YE5GW3kPF98rvINEUP54 of8wiYUKY+WgCbsMYjy7s2MJBM8wPaLZqEHbUQvHrsjjmU3neg96nK9eCCz8492E8wpY Pe4/7TCZqEsE6DGqn1xR+krwOn8uysuwRldybrNv1BRUcRL+52FetgM2wKw8APjEgl0s Ylyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=AG3FYtTWFKD9P12Qq8bx9usxkv7tivZiG59oe0T0pwY=; b=t9VjzaDMxpfz+2TGSP90hw6mHL2TVO65Lo6jSv8sisKjBkfPfSbeyKo/MC5asI8MvL Oqu9gVIhbke2I8aRixPXl53pT5wkdDlGTPPmT8UJRjBmo8V524phHfcE30YdJZkdiQH5 REX38OvEJzLvZac8eqrwRnCBpvbYi6vh40QJz/lfMNtLtvMTwAynrpc1vviJ1VF2edb6 sjEPc6drmGs3JJHW02AKXTLjeTd2hSgqM/uKZcfTN3m/p0eXaaJVD6MYtJpfN2CFRnmT +7bGAydeKPxkbrDbkbsiG0FfNMCj85AH5nf2eyiIHUKM4SPbJirfUOd1TG7BdpLfsnzD KEpw== X-Gm-Message-State: AOAM5306gqiFal4+dChtjgsZ46VheXwOT9Z/SG4G2D0tLEHd4b3c3pGm 49Oz0dfTjVNYHZCGYyS4BJ29clEXit3uIQ== X-Google-Smtp-Source: ABdhPJzRyYMPyJ6q7hRpg46a6DrJlJ0ZZbJHeZ6qEcXvAu2Yk/PpNH3ASVhavdeSw72clHEolJTJcA== X-Received: by 2002:a05:6a00:b89:b0:49f:f600:658f with SMTP id g9-20020a056a000b8900b0049ff600658fmr37458243pfj.71.1637021383310; Mon, 15 Nov 2021 16:09:43 -0800 (PST) Received: from smtpclient.apple (c-69-181-169-15.hsd1.ca.comcast.net. [69.181.169.15]) by smtp.gmail.com with ESMTPSA id n14sm229772pfj.164.2021.11.15.16.09.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Nov 2021 16:09:43 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Mahesh Jethanandani Mime-Version: 1.0 (1.0) Date: Mon, 15 Nov 2021 16:09:42 -0800 Message-Id: <17D44A27-5442-48E2-8422-D57F74634C26@gmail.com> References: <0100017d25cdeaeb-c6ad2da8-c120-4657-8c99-630a977a3e4b-000000@email.amazonses.com> Cc: Kent Watsen , netconf-chairs@ietf.org In-Reply-To: <0100017d25cdeaeb-c6ad2da8-c120-4657-8c99-630a977a3e4b-000000@email.amazonses.com> To: netconf@ietf.org X-Mailer: iPhone Mail (18H17) Archived-At: Subject: Re: [netconf] Draft minutes for NETCONF (and not NETMOD) 112 session uploaded 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, 16 Nov 2021 00:09:59 -0000 Just a minor correction to the subject line.=20 Mahesh (and Kent) > On Nov 15, 2021, at 2:53 PM, Kent Watsen wrote: >=20 > =EF=BB=BF > The draft minutes for our session today are both below and uploaded here: >=20 > https://datatracker.ietf.org/meeting/112/materials/minutes-112-netconf >=20 > Please review and send any corrections to the chairs alias (CC-ed). >=20 > Thanks! > Kent (and Mahesh) >=20 >=20 >=20 >=20 > # Meeting Minutes for the NETCONF 112 WG Session >=20 > # Introduction >=20 > ## Chair slides (10 minutes) > - Session Intro & WG Status >=20 > Rob: re: the IEEE liaison on the keystore draft, says that he'll setup a m= eeting. >=20 > Kent: requests all authors to bring discussions to the WG list. >=20 >=20 >=20 > # Chartered items: >=20 > ## UDP-based Transport for Configured Subscriptions (10 min) > - https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-04 > - Discussion Leader: Pierre Francois >=20 > Rob: Need to check with Sec Area. =46rom a quick discussion with the ADs t= hey may not be happy with allowing unencrypted UDP in a standards track doc.= (2) We should also check that we cover transport issues such as congestion= . >=20 > Pierre: XXX >=20 > Kent: I have sympathy for implementations that want to send notifications u= nencrypted in a private network. >=20 > Pierre: Do you think that having this traffic over a secure network would n= ot be good enough? >=20 > Rob: Yes, I have sympathy for the the deployment scenario, but I'm still n= ot sure whether this will be sufficient for the security ADs, they may think= that the cost of encrypting all of the traffic is low enough to justify >=20 > Mahesh: Draft talks about a transmission timeout value to be set, but ther= e is no configuration in the YANG module for that timer? Is the draft askin= g for a well known UDP port? >=20 > Pierre: I need to check for the timeout. We might need to have this confi= gured, but a default value may be sufficient. Re 2nd question. We had this= in, but we decided that having a single default value is not really needed a= nd nobody was caring. >=20 >=20 >=20 > # Non-Chartered items: >=20 >=20 > ## Adaptive Subscription to YANG Notification (10 mins) > - https://datatracker.ietf.org/doc/html/draft-wang-netconf-adaptive-subsc= ription-07 > - Discussion Leader: Qiufang Ma >=20 > Rob: Thank you for Qin's comments. I think that you are on the right trac= k. Okay to allow more complex expressions as long as all implementions supp= ort a minimum level of complexity. Should have a well defined error code if= the expression is too complex. >=20 >=20 > Kent: Arbitrary XPaths may also turn up in list pagination. This may be a= problem if the backend is supported by a simple database. How does the ser= ver indicate to the client what level of complexity is supported. I see the= same problem turning up here and in the list pagination work. >=20 >=20 >=20 >=20 > ## Transaction ID Mechanism for NETCONF (10 min) > - https://datatracker.ietf.org/doc/html/draft-lindblad-netconf-transactio= n-id-01 > - Discussion Leader: Jan Lindblad >=20 > Kent: You had some open issues, there is no time for discussion. I do thi= nk that we should take issues to the list. Please take the open issues ther= e. >=20 > Benoit: I really support the id being issued by the client, or at least ha= ving a way to label the required. Particularly helpful if there are multipl= e clients configuring a server, and we want to keep track of the service req= uest Id. >=20 > Kent: I do also think that there is value there. Just need to decide the b= est way to introduce it. >=20 >=20 >=20 > # List Pagination for YANG-driven Protocols (20 mins) > - https://datatracker.ietf.org/doc/html/draft-wwlh-netconf-list-paginatio= n-00 > - https://datatracker.ietf.org/doc/html/draft-wwlh-netconf-list-paginatio= n-nc-02 > - https://datatracker.ietf.org/doc/html/draft-wwlh-netconf-list-paginatio= n-rc-02 > - Discussion Leader: Qin Wu >=20 > Mahesh: Out of time, so please take these questions to the list. From nobody Mon Nov 15 19:45:37 2021 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 ED66F3A0688 for ; Mon, 15 Nov 2021 19:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20210112.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 oOgTS3u5u6hV for ; Mon, 15 Nov 2021 19:45:33 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E45B43A0687 for ; Mon, 15 Nov 2021 19:45:32 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id d11so40156183ljg.8 for ; Mon, 15 Nov 2021 19:45:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=XVjPyHo5/XaZ3VuP1KDSyuN6BKxR3pNW/nq2Nss8iTQ=; b=FE4i33miiBfvc3WCp/y12qYeac400HIhIGaxFSVI+Dt6k6H5SnUQeZuZAakRang6PA OHzlMWVclU5ecDc0Bz2nIBTXvdkah2u9mH6X7kzML+/FlS2nbWtqkM3BLyIw5gMhQbKS Jh2EEcHEDwtrziPycHBX1iuy3t7P/VetGWiLrnox8+00ORjjDHy6XZhw2nLSzvGOvlpj UD4Tf88XoIzulQ2YliODCwRO1GTqxKzqHG6d9AlZZZlLQcVGaDIvfwQtrS8J+NW01BAT Ku5x5fQLCvCv5grTgsA90gd6KPdMNgRp/YjiLzkQ4qaYkLxzFOVbrgrq1b4uKFotgKgy 9tGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XVjPyHo5/XaZ3VuP1KDSyuN6BKxR3pNW/nq2Nss8iTQ=; b=7MY842jZNG6h38BMMAOXOhC2ddg983kaFzK/EkwqZLN1Mfr4cGMz4FGwLzcOjlIZI4 5OO3vlGMu6Cwfvwszs+R7q0xGAlrkSSwjqP111Zs8l50SgabZg9NU3DrdrytDoX1xJ0N NKfGtvGP6MT/vPm9yN2HTJsNqjSd9hWFkyzXSULBeZXj5fk0+mcooHa7ySpE6UR7rAnI a661WA7dPyQ030tXW4zvJIS2UfgivWmPFiE/Yg9oN01MTHmQCdHXmCrvBbu5/1Yv1CPs xj5G0GuF4G984kPDh1zuTJTKa313BIj/pkr8PcDFekn0ukqpzAKESsEg4nPIVFItqQ8y YGuA== X-Gm-Message-State: AOAM533HujBcl4UPChhWbhtiz6cq897He7570AnUIeJEJyobr/JgrUo7 MDg7BEZFLwsZYmsmYn9t/izLk1PipfVF+Ffx0zb7oBlDB3MpAg== X-Google-Smtp-Source: ABdhPJwgr11zujiAQoxyn8FnhSYj1esl8SsBryEAEvxxdqn09V5/cFVwNQnoLkV2iXFLOfdKlwYr+6Mt1POO5JSz2NU= X-Received: by 2002:a2e:8248:: with SMTP id j8mr3838933ljh.1.1637034329519; Mon, 15 Nov 2021 19:45:29 -0800 (PST) MIME-Version: 1.0 From: Andy Bierman Date: Mon, 15 Nov 2021 19:45:18 -0800 Message-ID: To: Netconf Content-Type: multipart/alternative; boundary="000000000000b24bbc05d0dfc16e" Archived-At: Subject: [netconf] Issues with draft-ietf-netconf-udp-notif-04 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, 16 Nov 2021 03:45:35 -0000 --000000000000b24bbc05d0dfc16e Content-Type: text/plain; charset="UTF-8" Hi, I am wondering if there implementations of this draft already. IMO there are problems with in that prevent reasonable and optimal implementations. 1) Use of UDP as the Application Message Framing UDP is a transport protocol. Tightly coupling one NETCONF notification message to one UDP frame (+ fragments) is not very optimal. 1A) wastes space in the UDP frame if the NETCONF notification happens to be short 1B) imposes an application-level max-message-size 2) Not Efficient for Streaming Servers (no Message Chunking) The application framing in NETCONF and RESTCONF (HTTP) is not coupled to any transport protocol. Instead, a sender may emit as many message chunks as desired. This is how a streaming server works. Content comes from many different sources and it is sent on-the-fly in chunks, instead of constructing large replies. - Application framing allows multiple notifications in one UDP frame - Application framing does not need a max-message-size. Streaming servers often do not know the size of the data that will be sent in a notification. Q1) Should proprietary encoding be used to support application-layer framing or should the standard support it? 3) Protocol Message Encoding for CBOR The NETCONF notification message is not modelled in YANG. This is an open issue for YANG to CBOR encoding. https://github.com/core-wg/yang-cbor/issues/96 The "notification" and "eventTime" elements do not have YANG definitions. SID assignments for these elements will be needed. This draft is the likely place for these SID assignment requests to the IESG and IANA. 4) Subscription-ID Missing from Header It is quite possible for one message generator to create messages for multiple subscriptions. The subscription-ID will be needed to dispatch notifications to subscribers correctly. The Observation-Domain-ID is not sufficient. 5) Private Encoding Option does not seem interoperable The "Enc. Descr" field is completely opaque. This field could be structured to provide the "ET number space owner" e.g, urn [wsp description] Andy --000000000000b24bbc05d0dfc16e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I am wondering if there implementat= ions of this draft already.
IMO there are problems with in that p= revent reasonable and
optimal implementations.

1) Use of UDP as the Application Message Framing
UDP is a = transport protocol.=C2=A0 Tightly coupling one
NETCONF notificati= on message to one UDP frame (+ fragments)
is not very optimal.

1A) wastes space in the UDP frame if the NETCONF not= ification=C2=A0
=C2=A0 =C2=A0 happens to be short
1B) i= mposes an application-level max-message-size

2) No= t Efficient for Streaming Servers (no Message Chunking)
The appli= cation framing in NETCONF and RESTCONF (HTTP) is not
coupled to a= ny transport protocol. Instead, a sender may emit as
many message= chunks as desired. This is how a streaming server works.
Content= comes from many different sources and it is sent on-the-fly
in c= hunks, instead of constructing large replies.

=C2= =A0 =C2=A0 - Application framing allows multiple notifications in one UDP f= rame
=C2=A0 =C2=A0 - Application framing does not need a max-= message-size.=C2=A0
=C2=A0 =C2=A0 =C2=A0 Streaming servers often = do not know the size of the data that will be sent=C2=A0
=C2=A0 = =C2=A0 =C2=A0 in a notification.

Q1) Should propri= etary encoding be used to support application-layer framing
=C2= =A0 =C2=A0 =C2=A0 =C2=A0or should the standard support it?
=C2=A0= =C2=A0
3) Protocol Message Encoding for CBOR
The NETCO= NF notification message is not modelled in YANG.
This is an open = issue for YANG to CBOR encoding.

<= div>






--000000000000b24bbc05d0dfc16e-- From nobody Tue Nov 16 05:24:38 2021 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 151D03A0904; Tue, 16 Nov 2021 05:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=sandelman.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYcPH8Dw6afc; Tue, 16 Nov 2021 05:24:29 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E06E3A0909; Tue, 16 Nov 2021 05:24:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id D3CD61801F; Tue, 16 Nov 2021 08:26:46 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cIg6Gy5lx1D3; Tue, 16 Nov 2021 08:26:43 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1A5D518017; Tue, 16 Nov 2021 08:26:42 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1637069203; bh=WUzbYhwOhXDOuxgzss5aEVqJy8EEk1Z3Ftmp0gDnYLA=; h=From:cc:to:Subject:In-Reply-To:References:Date:From; b=7naORat2TgFGWR7yIC9BYrWOP0V1Ezxws02etZaJC0V6nBCp5bcAB+R+vTXy6PTfF B0tbLE25PeqT4AfjLL9YDWk1HewYZzXivy58eYRmqqqyi7/9X0hjNuLHNI6hE0ygwo CoFyTRYM0ZyTXNsXJm/hdzfxe71A9Bhf0tYmc8Qa8psqJQ0/kHnSev8CUOglVtFici wkSj9dacZhPg8BVaHnALL/Yn+7WXoP7K1OYXlRJnlwfOt7dBHxWncrcn7LQ6Kq66Gv sHJCj9rSDs78HQUS7w1eEWo1VZZAQ46dnAnDHTfBJLt6KGD8ExB6DebRFu/ieP+3ko Xe7QQmUOkvuVA== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7FEC165; Tue, 16 Nov 2021 08:24:21 -0500 (EST) From: Michael Richardson cc: Toerless Eckert to: anima@ietf.org, netconf@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [netconf] [Anima] [ANIMA] discuss _how_ to adopt draft-richardson-anima-rfc8366bis 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, 16 Nov 2021 13:24:35 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Adding netconf@. Reminding that 8366 was originally a pooling of interests between 6tisch, ANIMA and NETCONF. {We haven't yet fixed the entire 6tisch scenario yet. draft-selander-ace-ake-authz is probably closest to what 6tisch wanted. It doesn't use 8366 literally as described, but figuratively.} Toerless Eckert wrote: > To move the discussion from IETF112 meeting to the mailing list: > a) To be able for other drafts to extend the RFC8366 voucher YANG dat= a model, we need > to fix up the RFC8366 voucher model. This is the smallest possible RF= C8366bis scope. If we go this direction, fixing the one obvious bug with the assertion enumeration probably means that we can also advance RFC8633bis to Internet = Standard. There might be a few other bugs that we find that we have to fix. Anyway, I will attempt to post an update around Dec.1 > b) We can make the scope bigger by also adding not only the hooks to = make it extensible, > but actually integrating extensions from other WG drafts. Bringing in the other extensions, some of which are not yet fully baked, probably means a pretty long cycle. For some documents, it might be very disruptive to both. So, I think that this is a bad idea. > I have no strong opinion either way. I would be happy with option a),= as long as we > know we are not missing out on any othrer extension point than the on= e we did already > identify! I think that it's fine if we did 8633bis as IS, and then in a few years, we collected things again into a new comprehensive document. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmGTsQUACgkQgItw+93Q 3WWyiAgAlgORt9Cg+MJbH23O4dt1JQ1dhUkug8+Sn8T0XdEGjKx4FSOlX/lWc9Bg 3zuACumrxgtd+rJvv0+wPeALrHpzpNrmkaFc9bVssbjujbxQ1sYcVOhzuAXIi3Zt Wn+rIg+ImyydAnJjV1bnhneT18yG8IkC2s29RlT3ke+dDd2yL2WMG0Z9hkah6Ypa Z2cyKxUKOOoTqRwU2lC7B5ZvFY/Ipn5KZgNbe2Bu2wmwyOb23jaBFVHKvObtyP67 w0Q05Jdouj5WX+AzcKDDHn2a6SP+I9Tu/0/cd8t74qbDy7Cfh6Sv8RQ+C+nwlRVg IH6chb8ERzMMLCxMInStZRErdiHSow== =ZHby -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 17 03:03:21 2021 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 F309B3A0C15 for ; Wed, 17 Nov 2021 03:03:19 -0800 (PST) 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 jqgZcBe2TxTu for ; Wed, 17 Nov 2021 03:03:15 -0800 (PST) Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (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 033903A0C14 for ; Wed, 17 Nov 2021 03:03:14 -0800 (PST) Received: by mail-yb1-xb35.google.com with SMTP id i194so6291166yba.6 for ; Wed, 17 Nov 2021 03:03:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UK3uo167GsnEHGbnlCYI1x+8G79JvfRwdjIfblV8qrw=; b=ossytCQ821K9FuZ17gTq2mInB67dWOZ2xJhE6bQRQyWA1347neKaLUTwYzEjPrqd1v tVKNUd3isFCjroV2fOeytPvoNafVJI+H6nCh0YzC2YYqbzMtjjGr4WPIOjnrrWwWKEAm KbHissTfx0exBbhoOIJaGYu1Idte2tfHKF0CjDo2wzem1H4yKb3RgvOiH4KlMDi/zxUh noRHv1FwJT4cEK7aM+tc7/3UsjqEb7M/TiVqF2hSNLzRF9GRe5tdgTKKCrClOqK89MUj aBA7RT0+Iy/R8qcK+jLsRgE8c6zwqyu93sn/DtWIMmluXbtZz3ntb1zqVj1LgxeoXEB4 niIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UK3uo167GsnEHGbnlCYI1x+8G79JvfRwdjIfblV8qrw=; b=BjsDX1PHjRxN2zgSygoG4x8b9PKPr2TVWM9gVQb7r3XlYDl0QXbc+weMTQ2Uemu10A IZ7LoiUUDDC5ToqmvgQpXkBOjWlPYmPJ4H3Ng8d7pozpdlYlC7YimQgM9aUxia9b4o/p Oe9thgU+rCE37K2Q44DyXrd0Supj3g5DWBn6ZRg1rfy9aVPnGqTiBcAlMuGa7I96/JA3 181GkrE3Z8D3m+3S/BWIh/2bFKIGh/HvjbEymcXQIsIZt4bz7WNdVR3qbGuYpMAxQzeS V4+FPbezZY0suNGA1Xc6rSxlVcIJBwoxJHC2mWdib5DJJ1fvw7KngngHLjZlJs5gktsv xfnA== X-Gm-Message-State: AOAM531TZO/9BbPD9hpmmLkepwD1lEb71EC0fPob2cRUg6pf3GtXel5x PoLGZaawO3SOk/tqSPNHPsuL3/BqUgz5CJFcJ7o= X-Google-Smtp-Source: ABdhPJxU1WjtkOVmzBsQp80Ybkf0X831jb7niVu/r5zOWwdC/4iWCpcjbpFk/uYzGkEfkPV2j8f175j2+ZyZQhbM740= X-Received: by 2002:a25:d895:: with SMTP id p143mr15487489ybg.513.1637146993562; Wed, 17 Nov 2021 03:03:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Pierre Francois Date: Wed, 17 Nov 2021 12:03:07 +0100 Message-ID: To: Andy Bierman Cc: Netconf Content-Type: multipart/alternative; boundary="000000000000ff1aa205d0f9fc52" Archived-At: Subject: Re: [netconf] Issues with draft-ietf-netconf-udp-notif-04 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, 17 Nov 2021 11:03:20 -0000 --000000000000ff1aa205d0f9fc52 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Andy, Thanks for the feedback, answers inline. Le mar. 16 nov. 2021 =C3=A0 04:45, Andy Bierman a =C3= =A9crit : > Hi, > > I am wondering if there implementations of this draft already. > IMO there are problems with in that prevent reasonable and > optimal implementations. > There is support of udp-notif publisher in VRP. There is a C collector lib for udp-notif in https://github.com/insa-unyte/udp-notif-c-collector > 1) Use of UDP as the Application Message Framing > UDP is a transport protocol. Tightly coupling one > NETCONF notification message to one UDP frame (+ fragments) > is not very optimal. > There is a segmentation option in the protocol, so a udp notif message is not tightly coupled to a UDP frame. > > 1A) wastes space in the UDP frame if the NETCONF notification > happens to be short > I don't get it, I'm sorry. To me a UDP header + small udp-notif header is rather short. > 1B) imposes an application-level max-message-size > Not with the segmentation option, do we agree? > > 2) Not Efficient for Streaming Servers (no Message Chunking) > The application framing in NETCONF and RESTCONF (HTTP) is not > coupled to any transport protocol. Instead, a sender may emit as > many message chunks as desired. This is how a streaming server works. > Content comes from many different sources and it is sent on-the-fly > in chunks, instead of constructing large replies. > > - Application framing allows multiple notifications in one UDP frame > - Application framing does not need a max-message-size. > Streaming servers often do not know the size of the data that will > be sent > in a notification. > I think we meet these goals. Let me think about this further. > > Q1) Should proprietary encoding be used to support application-layer > framing > or should the standard support it? > I think we'd need to meet on this or else it will end up with thousands of long emails ;) > > 3) Protocol Message Encoding for CBOR > The NETCONF notification message is not modelled in YANG. > This is an open issue for YANG to CBOR encoding. > https://github.com/core-wg/yang-cbor/issues/96 > > The "notification" and "eventTime" elements do not have YANG definitions. > SID assignments for these elements will be needed. > This draft is the likely place for these SID assignment requests to > the IESG and IANA. > Shouldn't these be transport agnostic? I don't see why this would be bound to udp-notif only and not, say, https-notif. > > 4) Subscription-ID Missing from Header > It is quite possible for one message generator to create > messages for multiple subscriptions. The subscription-ID > will be needed to dispatch notifications to subscribers correctly. > The Observation-Domain-ID is not sufficient. > Same answer as above, we understand obs-domain-id to be used in the transport to meet load-balancing goals, but thought it would violate layers to place subscription-IDs in the transport itself. > > 5) Private Encoding Option does not seem interoperable > The "Enc. Descr" field is completely opaque. > Correct. > This field could be structured to provide the "ET number space owner" > e.g, urn [wsp description] > Mmm it's a valid option. Our opinion was that once you want it interoperable, you should make it standard instead of private. If the wg thinks we should kinda standardize private options, I'm personally okay to add that to the draft. > > Andy > Thanks a lot for your comments, Pierre. Le mar. 16 nov. 2021 =C3=A0 04:45, Andy Bierman a =C3= =A9crit : > Hi, > > I am wondering if there implementations of this draft already. > IMO there are problems with in that prevent reasonable and > optimal implementations. > > 1) Use of UDP as the Application Message Framing > UDP is a transport protocol. Tightly coupling one > NETCONF notification message to one UDP frame (+ fragments) > is not very optimal. > > 1A) wastes space in the UDP frame if the NETCONF notification > happens to be short > 1B) imposes an application-level max-message-size > > 2) Not Efficient for Streaming Servers (no Message Chunking) > The application framing in NETCONF and RESTCONF (HTTP) is not > coupled to any transport protocol. Instead, a sender may emit as > many message chunks as desired. This is how a streaming server works. > Content comes from many different sources and it is sent on-the-fly > in chunks, instead of constructing large replies. > > - Application framing allows multiple notifications in one UDP frame > - Application framing does not need a max-message-size. > Streaming servers often do not know the size of the data that will > be sent > in a notification. > > Q1) Should proprietary encoding be used to support application-layer > framing > or should the standard support it? > > 3) Protocol Message Encoding for CBOR > The NETCONF notification message is not modelled in YANG. > This is an open issue for YANG to CBOR encoding. > https://github.com/core-wg/yang-cbor/issues/96 > > The "notification" and "eventTime" elements do not have YANG definitions. > SID assignments for these elements will be needed. > This draft is the likely place for these SID assignment requests to > the IESG and IANA. > > 4) Subscription-ID Missing from Header > It is quite possible for one message generator to create > messages for multiple subscriptions. The subscription-ID > will be needed to dispatch notifications to subscribers correctly. > The Observation-Domain-ID is not sufficient. > > 5) Private Encoding Option does not seem interoperable > The "Enc. Descr" field is completely opaque. > This field could be structured to provide the "ET number space owner" > e.g, urn [wsp description] > > > Andy > > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000ff1aa205d0f9fc52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Andy,=C2=A0

Thanks for the feedback, ans= wers inline.=C2=A0

Le=C2=A0mar. 1= 6 nov. 2021 =C3=A0=C2=A004:45, Andy Bierman <andy@yumaworks.com> a =C3=A9crit=C2=A0:=
Hi,

I am wondering if there implementations of this dr= aft already.
IMO there are problems with in that prevent reasonab= le and
optimal implementations.

=
There is support of udp-notif publisher in VRP.=C2=A0
There is a C collector lib for udp-notif in=C2=A0https://gith= ub.com/insa-unyte/udp-notif-c-collector=C2=A0=C2=A0


1) Use of UDP as the Application Mess= age Framing
UDP is a transport protocol.=C2=A0 Tightly coupling o= ne
NETCONF notification message to one UDP frame (+ fragments)
is not very optimal.

=
There is a segmentation option in the protocol, so a udp notif message= is not tightly coupled to a UDP frame.=C2=A0
=C2=A0

1A) wastes space in the UDP frame if the NETC= ONF notification=C2=A0
=C2=A0 =C2=A0 happens to be short

I don't get it, I'm sorr= y. To me a UDP header=C2=A0+ small udp-notif header is rather short.
<= span class=3D"gmail-im">
=C2=A0
1B) imposes an application-level max-messa= ge-size

Not with the segmentat= ion option, do we agree?
=C2=A0

2) Not Efficient for Streaming Servers (no Message Chunking)
=
The application framing in NETCONF and RESTCONF (HTTP) is not
coupled to any transport protocol. Instead, a sender may emit as
many message chunks as desired. This is how a streaming server works.
Content comes from many different sources and it is sent on-the-fly<= /div>
in chunks, instead of constructing large replies.

<= /div>
=C2=A0 =C2=A0 - Application framing allows multiple notifications= in one UDP frame
=C2=A0 =C2=A0 - Application framing does no= t need a max-message-size.=C2=A0
=C2=A0 =C2=A0 =C2=A0 Streaming s= ervers often do not know the size of the data that will be sent=C2=A0
=
=C2=A0 =C2=A0 =C2=A0 in a notification.
<= br>
I think we meet these goals. Let me think about this f= urther.=C2=A0
=C2=A0

Q1= ) Should proprietary encoding be used to support application-layer framing<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0or should the standard support it?

I think we'd need to me= et on this or else it will end up with thousands of long emails ;)
=C2=A0
=C2=A0 =C2=A0
3) Protocol Mes= sage Encoding for CBOR
The NETCONF notification message is not mo= delled in YANG.
This is an open issue for YANG to CBOR encoding.<= /div>
The "notification" and "eventTime" ele= ments do not have YANG definitions.
SID assignments for these ele= ments will be needed.
This draft is the likely place for these SI= D assignment requests to
the IESG and IANA.

Shouldn't these be transport agnostic? I = don't see why this would be bound to udp-notif only and not, say, https= -notif.
=C2=A0

4) Subsc= ription-ID Missing from Header
It is quite possible for one messa= ge generator to create
messages for multiple subscriptions.=C2=A0= The subscription-ID
will be needed to dispatch notifications to = subscribers correctly.
The Observation-Domain-ID is not sufficien= t.

Same answer as above,= we understand obs-domain-id to be used in the transport to meet load-balan= cing goals, but thought it would violate layers to place subscription-IDs i= n the transport itself.
=C2=A0

5) Private Encoding Option does not seem interoperable
<= /blockquote>
The "Enc. Descr" field is completely opaque.

Correct.
= =C2=A0
This field could be structured to provide the "ET number spac= e owner"=C2=A0
e.g, urn [wsp description]

Mmm it's a valid option. Our opinion w= as that once you want it interoperable, you should make it standard instead= of private.=C2=A0
If the wg thinks we should kinda standardize p= rivate options, I'm personally okay to add that to the draft.=C2=A0
=C2=A0

Andy

=
Thanks a lot for your comments,=C2=A0

Pierre.=C2=A0

Le=C2=A0mar. 16 nov.= 2021 =C3=A0=C2=A004:45, Andy Bierman <andy@yumaworks.com> a =C3=A9crit=C2=A0:
Hi,

I am wondering if there implementations of this draft already.
I= MO there are problems with in that prevent reasonable and
optimal= implementations.

1) Use of UDP as the Application= Message Framing
UDP is a transport protocol.=C2=A0 Tightly coupl= ing one
NETCONF notification message to one UDP frame (+ fragment= s)
is not very optimal.

1A) wastes space= in the UDP frame if the NETCONF notification=C2=A0
=C2=A0 =C2=A0= happens to be short
1B) imposes an application-level max-message= -size

2) Not Efficient for Streaming Servers (no M= essage Chunking)
The application framing in NETCONF and RESTCONF = (HTTP) is not
coupled to any transport protocol. Instead, a sende= r may emit as
many message chunks as desired. This is how a strea= ming server works.
Content comes from many different sources and = it is sent on-the-fly
in chunks, instead of constructing large re= plies.

=C2=A0 =C2=A0 - Application framing allows = multiple notifications in one UDP frame
=C2=A0 =C2=A0 - Appli= cation framing does not need a max-message-size.=C2=A0
=C2=A0 =C2= =A0 =C2=A0 Streaming servers often do not know the size of the data that wi= ll be sent=C2=A0
=C2=A0 =C2=A0 =C2=A0 in a notification.

Q1) Should proprietary encoding be used to support applica= tion-layer framing
=C2=A0 =C2=A0 =C2=A0 =C2=A0or should the stand= ard support it?
=C2=A0 =C2=A0
3) Protocol Message Encod= ing for CBOR
The NETCONF notification message is not modelled in = YANG.
This is an open issue for YANG to CBOR encoding.

The "notification" and "eventTime" elements do n= ot have YANG definitions.
SID assignments for these elements will= be needed.
This draft is the likely place for these SID assignme= nt requests to
the IESG and IANA.

4) Sub= scription-ID Missing from Header
It is quite possible for one mes= sage generator to create
messages for multiple subscriptions.=C2= =A0 The subscription-ID
will be needed to dispatch notifications = to subscribers correctly.
The Observation-Domain-ID is not suffic= ient.

5) Private Encoding Option does not seem int= eroperable
The "Enc. Descr" field is completely opaque.=
This field could be structured to provide the "ET number sp= ace owner"=C2=A0
e.g, urn [wsp description]


Andy



_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000ff1aa205d0f9fc52-- From nobody Wed Nov 17 11:00:00 2021 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 613953A0062; Wed, 17 Nov 2021 10:59:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer via Datatracker To: Cc: draft-ietf-netconf-sztp-csr.all@ietf.org, last-call@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163717559932.18384.2156774121641934785@ietfa.amsl.com> Reply-To: Yaron Sheffer Date: Wed, 17 Nov 2021 10:59:59 -0800 Archived-At: Subject: [netconf] Secdir last call review of draft-ietf-netconf-sztp-csr-11 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: Wed, 17 Nov 2021 18:59:59 -0000 Reviewer: Yaron Sheffer Review result: Has Issues This draft defines a mechanism for a device, when it first starts, to generate a CSR to get itself provisioned with one or more certificates it needs to identify itself during its normal operation. * I was confused that the document starts out describing a generic cert request mechanism. Then deep into the YANG modules, it turns out that there is guidance (only?) for very specific types of certs, namely LDevID and IDevID. And the choice is non-orthogonal: it is unclear what is the guidance for other certs when using CMC and CMP, and conversely, whether these two certs can be generated with a PKCS#10 CSR. * I suggest adding a Security Considerations section about the need for strong randomness, which is often unavailable to small embedded devices at the early stages of provisioning. I wish we were more successful with: https://datatracker.ietf.org/doc/html/draft-sheffer-dhc-initial-random-00 * Negotiation (?) of the CSR format and supported algorithms is unclear in Sec. 2.2: is it the client that provides the values it supports and the server picks one? Alternatively, is the list conveyed by the server in the error-info and so the client knows exactly what is supported? IOW, why include these values at all in error-info? * It is not clear from Sec. 2.2 how exactly the client is supposed to associate one of possibly multiple received certificates to the CSR it just sent out. Surely it is not expected to grep for the string "Newly-Generated"? * 2.3: the description of "error-info" still does not specify if the server should list all CSR format and algorithms it supports. * Is there really need to support 3 different CSR formats? * Where does the client indicate which cert is wants to receive based on this CSR, e.g. "this CSR is for a LDevID"? Is this information embedded in the CSR itself? * Is RFC 2986 (published Nov. 2000) the best reference for an AlgorithmIdentifier? Is there no IANA registry we could reference instead? * When talking about algorithm matching, I suggest changing "It is an error if..." into normative text, "The recipient MUST reject...". * "Details for how to generate a new private key and associate a new identity certificate are outside the scope of this document." - This is rather disappointing, since we just RECOMMENDED to regenerate certs periodically (and given that IOT devices often lack HSMs). From nobody Wed Nov 17 11:31:24 2021 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 C8BC23A0129 for ; Wed, 17 Nov 2021 11:31:23 -0800 (PST) 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.20210112.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 GTT5nI9wDZB7 for ; Wed, 17 Nov 2021 11:31:18 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 55F9F3A0124 for ; Wed, 17 Nov 2021 11:31:18 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id b1so13459382lfs.13 for ; Wed, 17 Nov 2021 11:31:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9uJwdi2tccVg6FAEYrSAA3PdQkmZZCF/9WQYdbAfMCg=; b=yiLjmG61CMG1QPkOwK+bsIUlI3ENMJh6pmhJ7TN28w96exfm8m8bPBYV3cLIHYzZKx AYYjBdsItfQhLkbE8m20MG7+LUNIxnbqdaX4uesZ8GInbCL9qQAgvWZg2HjX/bCOicJ8 veCI+e6Z+KcjkmLHTD+9pfRN6jQgARVETdO5cTryACDhq5lMiasxSF/vILmNL5meCCf3 YJav65ENPEVcSscFZzXvWTYS9Dwa2kF0kv+N8gFq3c9R7kDDRKc+GwyfRV6SKyI3u59A rb9YVmT5BaoQxukQpYOP8AIMTMuF+Cl/hSES780w1epE/Pw9M/y7OzI2jfdYH5P30xh8 Q4Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9uJwdi2tccVg6FAEYrSAA3PdQkmZZCF/9WQYdbAfMCg=; b=G1sRh4niMKWAmDctmUFHd9/EsbGYm6ey/OiinJvgtGCrUIY3Egzm1BZUnDtXFIpYKt jr9+RSdiuxlWZ7c9wapJsxY/PSOLcv5TmhKJB2NH0OeOL5lTwGjl7ob48JNB5A9iirYK 9Pss/LyTPwV/ZlVAwYaimx8cL7Vu9dRNJxrZSreCSerQpqy4uZ8QrY7qpb35YseXlK7j s4+RlO8Me9R5rcKJe/U8pOo4hrWwRv8pu8NxTromIb9nF9HLqHwRQMG4nqcUYrLDBbwk VsS/EV9e57tStUKcOKufJ0OqwTDhjrfs1APdEn0cWW3MW2B0Yb0ELW43SP8oDJBUquaA Ol4A== X-Gm-Message-State: AOAM5335MlN4x8oZyYvS/mFJNmNJF6a/8apMx2+A1KBGUdh7jOz0kmoZ njo1ay9wQctaarsFPpbsk1OO8ej9ZYYNl5QEEUB5y6EjliCrXg== X-Google-Smtp-Source: ABdhPJwFgSrsrIgaYSjmvd7Z8HdPDHzwwjbR4jKWHpecRX5/x8XxDVx+OMnKAMUoRXHH2df9tDnQfNjNoE2hlD571y4= X-Received: by 2002:a05:6512:68c:: with SMTP id t12mr17474483lfe.10.1637177474593; Wed, 17 Nov 2021 11:31:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Wed, 17 Nov 2021 11:31:03 -0800 Message-ID: To: Pierre Francois Cc: Netconf Content-Type: multipart/alternative; boundary="000000000000cec9f805d1011594" Archived-At: Subject: Re: [netconf] Issues with draft-ietf-netconf-udp-notif-04 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, 17 Nov 2021 19:31:24 -0000 --000000000000cec9f805d1011594 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 17, 2021 at 3:03 AM Pierre Francois < pierre.francois.ietf@gmail.com> wrote: > Hello Andy, > > Thanks for the feedback, answers inline. > > Le mar. 16 nov. 2021 =C3=A0 04:45, Andy Bierman a = =C3=A9crit : > >> Hi, >> >> I am wondering if there implementations of this draft already. >> IMO there are problems with in that prevent reasonable and >> optimal implementations. >> > > There is support of udp-notif publisher in VRP. > There is a C collector lib for udp-notif in > https://github.com/insa-unyte/udp-notif-c-collector > > >> 1) Use of UDP as the Application Message Framing >> UDP is a transport protocol. Tightly coupling one >> NETCONF notification message to one UDP frame (+ fragments) >> is not very optimal. >> > > There is a segmentation option in the protocol, so a udp notif message is > not tightly coupled to a UDP frame. > But this segmentation is optional to implement. My point is that application protocols like NETCONF have their own message framing which does not exist here because the transport framing is used instead. > > >> >> 1A) wastes space in the UDP frame if the NETCONF notification >> happens to be short >> > > I don't get it, I'm sorry. To me a UDP header + small udp-notif header is > rather short. > If I can fit 100 notification messages in 1 UDP frame then I save 99% of the redundant headers. > > >> 1B) imposes an application-level max-message-size >> > > Not with the segmentation option, do we agree? > https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif#section-= 4.1 There can be 32767 segments of a max 65535 each: about 2G of data. However the segment-size is allowed to be smaller and segmentation is completely optional-to-implement. Application layer framing allows unlimited message size without any need to support UDP segmentation at all, > >> >> 2) Not Efficient for Streaming Servers (no Message Chunking) >> The application framing in NETCONF and RESTCONF (HTTP) is not >> coupled to any transport protocol. Instead, a sender may emit as >> many message chunks as desired. This is how a streaming server works. >> Content comes from many different sources and it is sent on-the-fly >> in chunks, instead of constructing large replies. >> >> - Application framing allows multiple notifications in one UDP frame >> - Application framing does not need a max-message-size. >> Streaming servers often do not know the size of the data that will >> be sent >> in a notification. >> > > I think we meet these goals. Let me think about this further. > I agree, by ignoring the idea that this protocol provides any normative information about the application layer protocol in use. This draft should remove any hint that the application payload is defined in this document. It is OK to say a different RFC (or spec) defines the content for a particular Encoding Type. The "notification" in Figure 1 implies that the payload is one NETCONF notification. The draft should be clear that there is no structure to the payload defined in this document. > >> >> Q1) Should proprietary encoding be used to support application-layer >> framing >> or should the standard support it? >> > > I think we'd need to meet on this or else it will end up with thousands o= f > long emails ;) > I think the draft should let other documents define the exact content expected in the payload. I am used to application protocols defining specific message flows. Since this draft does not do that, it should not attempt to impose any rules on the application payload at all. > > >> >> 3) Protocol Message Encoding for CBOR >> The NETCONF notification message is not modelled in YANG. >> This is an open issue for YANG to CBOR encoding. >> https://github.com/core-wg/yang-cbor/issues/96 >> >> The "notification" and "eventTime" elements do not have YANG definitions= . >> SID assignments for these elements will be needed. >> This draft is the likely place for these SID assignment requests to >> the IESG and IANA. >> > > Shouldn't these be transport agnostic? I don't see why this would be boun= d > to udp-notif only and not, say, https-notif. > This is related to application/yang-data+cbor. A separate document for the SID assignments can be done. > >> >> 4) Subscription-ID Missing from Header >> It is quite possible for one message generator to create >> messages for multiple subscriptions. The subscription-ID >> will be needed to dispatch notifications to subscribers correctly. >> The Observation-Domain-ID is not sufficient. >> > > Same answer as above, we understand obs-domain-id to be used in the > transport to meet load-balancing goals, but thought it would violate laye= rs > to place subscription-IDs in the transport itself. > So I will put the Subscription-ID here instead I guess because a common use-case is to allow a Collector to support subscriptions from client applications. Only datastore subscriptions include a subscription-id, not event stream notifications. > >> >> 5) Private Encoding Option does not seem interoperable >> > The "Enc. Descr" field is completely opaque. >> > > Correct. > Then perhaps there is no need for this at all since it does not attempt to provide any interoperability? > > >> This field could be structured to provide the "ET number space owner" >> e.g, urn [wsp description] >> > > Mmm it's a valid option. Our opinion was that once you want it > interoperable, you should make it standard instead of private. > If the wg thinks we should kinda standardize private options, I'm > personally okay to add that to the draft. > Use of structured strings like URNs does not seem like a bad thing that should be discouraged. The ET field is not interopable if every implementation can define their own 4-bit values and there is no standard way to tell them apart. Perhaps just a domain name if a URN is too much of a burden. > >> >> Andy >> > > Thanks a lot for your comments, > > Pierre. > > Andy > Le mar. 16 nov. 2021 =C3=A0 04:45, Andy Bierman a = =C3=A9crit : > >> Hi, >> >> I am wondering if there implementations of this draft already. >> IMO there are problems with in that prevent reasonable and >> optimal implementations. >> >> 1) Use of UDP as the Application Message Framing >> UDP is a transport protocol. Tightly coupling one >> NETCONF notification message to one UDP frame (+ fragments) >> is not very optimal. >> >> 1A) wastes space in the UDP frame if the NETCONF notification >> happens to be short >> 1B) imposes an application-level max-message-size >> >> 2) Not Efficient for Streaming Servers (no Message Chunking) >> The application framing in NETCONF and RESTCONF (HTTP) is not >> coupled to any transport protocol. Instead, a sender may emit as >> many message chunks as desired. This is how a streaming server works. >> Content comes from many different sources and it is sent on-the-fly >> in chunks, instead of constructing large replies. >> >> - Application framing allows multiple notifications in one UDP frame >> - Application framing does not need a max-message-size. >> Streaming servers often do not know the size of the data that will >> be sent >> in a notification. >> >> Q1) Should proprietary encoding be used to support application-layer >> framing >> or should the standard support it? >> >> 3) Protocol Message Encoding for CBOR >> The NETCONF notification message is not modelled in YANG. >> This is an open issue for YANG to CBOR encoding. >> https://github.com/core-wg/yang-cbor/issues/96 >> >> The "notification" and "eventTime" elements do not have YANG definitions= . >> SID assignments for these elements will be needed. >> This draft is the likely place for these SID assignment requests to >> the IESG and IANA. >> >> 4) Subscription-ID Missing from Header >> It is quite possible for one message generator to create >> messages for multiple subscriptions. The subscription-ID >> will be needed to dispatch notifications to subscribers correctly. >> The Observation-Domain-ID is not sufficient. >> >> 5) Private Encoding Option does not seem interoperable >> The "Enc. Descr" field is completely opaque. >> This field could be structured to provide the "ET number space owner" >> e.g, urn [wsp description] >> >> >> Andy >> >> >> >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > --000000000000cec9f805d1011594 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 17, 2021 at 3:03 AM Pierr= e Francois <pierre.francois.ietf@gmail.com> wrote:
Hello Andy,=C2=A0

<= /div>
Thanks for the feedback, answers inline.=C2=A0
<= /div>
Le=C2=A0mar. 16 nov. 2021 =C3=A0=C2=A004:45, Andy Bierman <andy@yumaworks.com>= a =C3=A9crit=C2=A0:
Hi,

I am wondering if there implem= entations of this draft already.
IMO there are problems with in t= hat prevent reasonable and
optimal implementations.

There is support of udp-notif publish= er in VRP.=C2=A0
There is a C collector lib for udp-notif in=C2= =A0https://github.com/insa-unyte/udp-notif-c-collector=C2=A0= =C2=A0


1) Use of UDP as the Applicati= on Message Framing
UDP is a transport protocol.=C2=A0 Tightly cou= pling one
NETCONF notification message to one UDP frame (+ fragme= nts)
is not very optimal.

=
There is a segmentation option in the protocol, so a udp notif = message is not tightly coupled to a UDP frame.=C2=A0

But this segmentation is optional to impl= ement.
My point is that application protocols like NETCONF have t= heir own message framing
which does not exist here because the tr= ansport framing is used instead.
=C2=A0
=C2=A0

1A) wastes space in the= UDP frame if the NETCONF notification=C2=A0
=C2=A0 =C2=A0 happen= s to be short

I don'= t get it, I'm sorry. To me a UDP header=C2=A0+ small udp-notif header i= s rather short.

If = I can fit 100 notification messages in 1 UDP frame then I save 99% of the r= edundant headers.

=C2=A0
=C2=A0
1B) imposes an application-level max-mes= sage-size

Not with the segment= ation option, do we agree?


= There can be 32767 segments of a max 65535 each: about 2G of data.
However the segment-size is allowed to be smaller and segmentation is com= pletely optional-to-implement.

Application layer f= raming allows unlimited message size without any need
to support = UDP segmentation at all,


=C2=A0

2) Not Efficient fo= r Streaming Servers (no Message Chunking)
The application framing= in NETCONF and RESTCONF (HTTP) is not
coupled to any transport p= rotocol. Instead, a sender may emit as
many message chunks as des= ired. This is how a streaming server works.
Content comes from ma= ny different sources and it is sent on-the-fly
in chunks, instead= of constructing large replies.

=C2=A0 =C2=A0 - Ap= plication framing allows multiple notifications in one UDP frame
<= div>=C2=A0 =C2=A0 - Application framing does not need a max-message-size.= =C2=A0
=C2=A0 =C2=A0 =C2=A0 Streaming servers often do not know t= he size of the data that will be sent=C2=A0
=C2=A0 =C2=A0 =C2=A0 = in a notification.

I thi= nk we meet these goals. Let me think about this further.=C2=A0
<= /div>


I agree, by igno= ring the idea that this protocol provides any normative information
about the application layer protocol in use.=C2=A0 This draft should rem= ove any hint
that the application payload is defined in this docu= ment.=C2=A0 It is OK to say
a different RFC (or spec) defines the= content for a particular Encoding Type.

The "= ;notification" in Figure 1 implies that the payload is one NETCONF not= ification.
The draft should be clear that there is no structure t= o the payload defined in this document.

=C2=A0

Q1) Should propriet= ary encoding be used to support application-layer framing
=C2=A0 = =C2=A0 =C2=A0 =C2=A0or should the standard support it?

I think we'd need to meet on this or els= e it will end up with thousands of long emails ;)


I think the draft should let = other documents define the exact content expected in the payload.
I am used to application protocols defining specific message flows. Since = this draft does
not do that, it should not attempt to impose any = rules on the application payload at all.

=C2=A0
=C2=A0
=C2=A0 =C2=A0
3) Protocol Message Encoding for CBOR
The NETCONF notific= ation message is not modelled in YANG.
This is an open issue for = YANG to CBOR encoding.

The "notification" and &q= uot;eventTime" elements do not have YANG definitions.
SID as= signments for these elements will be needed.
This draft is the li= kely place for these SID assignment requests to
the IESG and IANA= .

Shouldn't these be= transport agnostic? I don't see why this would be bound to udp-notif o= nly and not, say, https-notif.
This is related to application/yang-data+cbor.=C2=A0
= A separate document for the SID assignments can be done.


=C2=A0
4) Subscription-ID Missing from Header
It is quite p= ossible for one message generator to create
messages for multiple= subscriptions.=C2=A0 The subscription-ID
will be needed to dispa= tch notifications to subscribers correctly.
The Observation-Domai= n-ID is not sufficient.

= Same answer as above, we understand obs-domain-id to be used in the transpo= rt to meet load-balancing goals, but thought it would violate layers to pla= ce subscription-IDs in the transport itself.


So I will put the Subscription-ID = here instead I guess because a common
use-case is to allow a Coll= ector to support subscriptions from client applications.
Only dat= astore subscriptions include a subscription-id, not event stream notificati= ons.

=
=C2= =A0

5) Private Encoding Option does not seem interoperable=
=
The "Enc. Descr" field is completely opaque.

Correct.
<= /blockquote>


Then perhaps there is no nee= d for this at all since it does not
attempt to provide any intero= perability?
=C2=A0
=C2=A0
This field could be structured to provide the "ET num= ber space owner"=C2=A0
e.g, urn [wsp description]

Mmm it's a valid option. Our o= pinion was that once you want it interoperable, you should make it standard= instead of private.=C2=A0
If the wg thinks we should kinda stand= ardize private options, I'm personally okay to add that to the draft.= =C2=A0

Use of struc= tured strings like URNs does not seem like a bad thing that should be disco= uraged.
The ET field is not interopable=C2=A0if every implementat= ion can define their own 4-bit values
and there is no standard wa= y to tell them apart. Perhaps just a domain name if a URN is too much of a = burden.


=C2=A0

Andy

Thanks a lot for your comments,=C2=A0
<= div>
Pierre.=C2=A0


Andy

=C2=A0
Le=C2=A0mar. 16 nov. 2021 =C3=A0=C2=A004:45= , Andy Bierman <= andy@yumaworks.com> a =C3=A9crit=C2=A0:
Hi,

I = am wondering if there implementations of this draft already.
IMO = there are problems with in that prevent reasonable and
optimal im= plementations.

1) Use of UDP as the Application Me= ssage Framing
UDP is a transport protocol.=C2=A0 Tightly coupling= one
NETCONF notification message to one UDP frame (+ fragments)<= /div>
is not very optimal.

1A) wastes space in= the UDP frame if the NETCONF notification=C2=A0
=C2=A0 =C2=A0 ha= ppens to be short
1B) imposes an application-level max-message-si= ze

2) Not Efficient for Streaming Servers (no Mess= age Chunking)
The application framing in NETCONF and RESTCONF (HT= TP) is not
coupled to any transport protocol. Instead, a sender m= ay emit as
many message chunks as desired. This is how a streamin= g server works.
Content comes from many different sources and it = is sent on-the-fly
in chunks, instead of constructing large repli= es.

=C2=A0 =C2=A0 - Application framing allows mul= tiple notifications in one UDP frame
=C2=A0 =C2=A0 - Applicat= ion framing does not need a max-message-size.=C2=A0
=C2=A0 =C2=A0= =C2=A0 Streaming servers often do not know the size of the data that will = be sent=C2=A0
=C2=A0 =C2=A0 =C2=A0 in a notification.
<= br>
Q1) Should proprietary encoding be used to support applicatio= n-layer framing
=C2=A0 =C2=A0 =C2=A0 =C2=A0or should the standard= support it?
=C2=A0 =C2=A0
3) Protocol Message Encoding= for CBOR
The NETCONF notification message is not modelled in YAN= G.
This is an open issue for YANG to CBOR encoding.

<= div>The "notification" and "eventTime" elements do not = have YANG definitions.
SID assignments for these elements will be= needed.
This draft is the likely place for these SID assignment = requests to
the IESG and IANA.

4) Subscr= iption-ID Missing from Header
It is quite possible for one messag= e generator to create
messages for multiple subscriptions.=C2=A0 = The subscription-ID
will be needed to dispatch notifications to s= ubscribers correctly.
The Observation-Domain-ID is not sufficient= .

5) Private Encoding Option does not seem interop= erable
The "Enc. Descr" field is completely opaque.
This field could be structured to provide the "ET number space = owner"=C2=A0
e.g, urn [wsp description]

=

Andy



=
_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000cec9f805d1011594-- From nobody Thu Nov 18 11:43:48 2021 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 D60603A0A08 for ; Thu, 18 Nov 2021 11:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.629 X-Spam-Level: X-Spam-Status: No, score=-0.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MISSING_HEADERS=1.021, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 toUFJvTQyEIa for ; Thu, 18 Nov 2021 11:43:41 -0800 (PST) Received: from smtp.lax.icann.org (smtp.lax.icann.org [192.0.33.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B26463A0A04 for ; Thu, 18 Nov 2021 11:43:41 -0800 (PST) Received: from request4.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp.lax.icann.org (Postfix) with ESMTP id 20BE8E1981; Thu, 18 Nov 2021 19:43:41 +0000 (UTC) Received: by request4.lax.icann.org (Postfix, from userid 48) id 0CCE5205F4; Thu, 18 Nov 2021 19:43:41 +0000 (UTC) RT-Owner: michelle.cotton From: "Michelle Cotton via RT" Reply-To: drafts-expert-review-comment@iana.org In-Reply-To: References: Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #1217006 X-Managed-BY: RT 4.4.3 (http://www.bestpractical.com/rt/) X-RT-Originator: michelle.cotton@icann.org CC: tbray@textuality.com, mt@lowentropy.net, netconf@ietf.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Thu, 18 Nov 2021 19:43:41 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [netconf] [IANA #1217006] Expert Review for draft-ietf-netconf-sztp-csr (xml-registry) 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, 18 Nov 2021 19:43:46 -0000 Hi Martin and Tim, (CC to the netconf WG) As designated experts for the IETF XML Registry, can you please review the XML ns registrations in this document? https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ The due date for this request is 02 December 2021. Thank you, Michelle Cotton IANA Services From nobody Thu Nov 18 13:49:14 2021 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 E5DC43A0ABA for ; Thu, 18 Nov 2021 13:49:12 -0800 (PST) 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, 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=textuality-com.20210112.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 OLPSTHhtIj4b for ; Thu, 18 Nov 2021 13:49:08 -0800 (PST) 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 22E123A0AB9 for ; Thu, 18 Nov 2021 13:49:08 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id z34so33097270lfu.8 for ; Thu, 18 Nov 2021 13:49:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3/PyxT1xjG0aBLX3/QX7kwzsFVJF6oA1Dd6tFW3B3Tk=; b=i+hhDte/k/znLauNL6Rv5teEHpQew5VlLlxE7GRQT+8d84HfVXuthC0fKTQONYNyXA O4/PaVYGa/Aw3K/h9QHOGN/+w7lOh8N+ahZaPyrCxkEveG8mcNiy5Qla4aM8M9QvAZjs 1GsFiw9XWJq+r59ozY0ebl98sCYYTtoCo8e5oZyNnen4mYJnaWP+e1zOT9XGKCRsAWRO eDMKWIWmi1wWvY8zyGVcz6297eCsMXGnIfHdZmeTM508kKw4RuB6S9wUJETjKmac7+pS GeGJnx8PTW/O+GPHUzM85yQ8XUfZ599K7RD9sqKBXBDowJox+4UBo+WRT/ndOltP+Pl/ AeDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3/PyxT1xjG0aBLX3/QX7kwzsFVJF6oA1Dd6tFW3B3Tk=; b=iFw13sbiizHz5uvm/HGXNX/KODHZkDAEo841t2mTmHhI5CGU3qYzljfX2kiWAQAlZt Tulop8Z1NpWco7r+K6WJikdG2VkZkvKtf9mgjjlGq+2rdOvXpVQYfG3gy1TgzkF5eV7B hqKGiEu/dDLtaZjZ/ukaQmAwB0bLOX71DPmCblP+wfgZOevRPLhN+YeXZ/Z9KwxvE1QT 8F9cYlhhYjUpGX+Y12G1j28340E5CVsNX4rfcdNXlkeZD6xrK4M8i0Hd5XiFSB7/QD6V iDqW31TNeugVKWnxauSOLbZtiQIEM34ZAGleGWJFIxr7TYmQti8QY2Szhj4TMHGVEud2 Mcig== X-Gm-Message-State: AOAM531RnyJ5XggJkcmK3k+HlAlYwEpkneg/xnum3wshXd6sXywEpMfJ xkaicoao/S7o3YcvNLc5SJ8ZWSsT4Jae/bTMOyg3N5tLCjBz1PWZ X-Google-Smtp-Source: ABdhPJxRdpywO0UwnAKhOanyOmH3HE+Y9hBQ1/dHsmmMj9fXjCt6HKFhsb0+kKfCd7+wYQm/ls5mwTSMJ0j7LjLCKDY= X-Received: by 2002:a05:651c:49b:: with SMTP id s27mr19361084ljc.404.1637272144306; Thu, 18 Nov 2021 13:49:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tim Bray Date: Thu, 18 Nov 2021 13:48:53 -0800 Message-ID: To: Amanda Baber via RT Cc: Martin Thomson , netconf@ietf.org Content-Type: multipart/alternative; boundary="0000000000009010be05d11720d1" Archived-At: Subject: Re: [netconf] [IANA #1217006] Expert Review for draft-ietf-netconf-sztp-csr (xml-registry) 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, 18 Nov 2021 21:49:13 -0000 --0000000000009010be05d11720d1 Content-Type: text/plain; charset="UTF-8" LGTM. On Thu, Nov 18, 2021 at 11:43 AM Michelle Cotton via RT < drafts-expert-review-comment@iana.org> wrote: > Hi Martin and Tim, > (CC to the netconf WG) > > As designated experts for the IETF XML Registry, > can you please review the XML ns registrations in this document? > > https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ > > The due date for this request is 02 December 2021. > > Thank you, > > Michelle Cotton > IANA Services > --0000000000009010be05d11720d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
LGT= M.

On Thu, Nov 18, 2021 at 11:43 AM Michelle Cotton via RT <drafts-expert-review-comm= ent@iana.org> wrote:
Hi Martin and Tim, (CC to the netconf WG)

As designated experts for the IETF XML Registry,
can you please review the XML ns registrations in this document?

https://datatracker.ietf.org/doc/draft-= ietf-netconf-sztp-csr/

The due date for this request is 02 December 2021.

Thank you,

Michelle Cotton
IANA Services
--0000000000009010be05d11720d1-- From nobody Thu Nov 18 18:13:45 2021 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 62C543A017E for ; Thu, 18 Nov 2021 18:13:43 -0800 (PST) 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.20210112.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 rLHdlx3jOnj6 for ; Thu, 18 Nov 2021 18:13:37 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 0D0903A0163 for ; Thu, 18 Nov 2021 18:13:36 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id f18so35905425lfv.6 for ; Thu, 18 Nov 2021 18:13:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VbVTcVPpwolcYFQJwXTXw/DCDMqcTwECrnTTZIQ/dJU=; b=paWksT7nLl4oUi4HIdBn4ObSWN9Bol6aIOisRb2cplD8/dLyeW9z8/OdDvVBu4j6xN TDM5qUqcoS4AcNiMc0TjPaTpwrzOU7v1Z8Pdq8gvgFJC60CEv2+3IE1MJwZc021hW1kr kRUpq1WGC2FqaAhpEdreXs4jq6sBfT7x/L4y6d5A0lcET0S3xqnk37P03apLkI3quF4V MeY/y2T2uQCfKy1o9ukpp4tDYVGPRtCkYqR/++cal+0XHO/EBmlJFsMmRnHrVQQZP95G o7La4/wCP91QZPbYlO39Ijc4nyVNK5MU0y77JAW76EzhmdJjlx3aaClO0DvJiCA/OgJ3 hgxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VbVTcVPpwolcYFQJwXTXw/DCDMqcTwECrnTTZIQ/dJU=; b=QYVaPt6lVELoiq/RfHJwjoab5nQkf/c43KTqlkLpqZcUh7m/CjOorip+v+T04aD9m7 CU/z1D63vmC3SdZs8BGdW+NLgbNq/99LGKJOrKQykVrqpDBtu1H7/iydW2fNZMfWvqTI LoeB4JtVGnKt73p7ChhilSYaF6A4hT2VJwsNC4iIVCJ/R8uQb8kUt/46phogCC/lQ2Oq hio6wsZIYbCnpHZVT22hePvDBx4y+D2ChHvU4LcQEhkkWBz3LCXReYptbW0UmbTBMmsK qnvYtngOIrr9JmZgqExtIYLsZbd/t9aX5iZrUrOApA/PWS2koVQphuRKL1ICbt3kJTWE +QBQ== X-Gm-Message-State: AOAM5318Efy2oCik7M6oSW9VNA5y7GVsqZnV1Mqd7CoUODCVCuNG+nQc TVaStAt4SLRfd9vDAbPcQkBg7gYwgDKGndW3aP+oPg== X-Google-Smtp-Source: ABdhPJzM6pE6fMz27HQ/T0PcqGnCn51llL2PpaJuseyMNlx2yRG6eaCdIaF02d+w+AVOdTw8aMfhY7dFnTbvh+vIiO0= X-Received: by 2002:a2e:3012:: with SMTP id w18mr21261270ljw.344.1637288013412; Thu, 18 Nov 2021 18:13:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Thu, 18 Nov 2021 18:13:22 -0800 Message-ID: To: Pierre Francois Cc: Netconf Content-Type: multipart/alternative; boundary="0000000000006f4d3905d11ad2ed" Archived-At: Subject: Re: [netconf] Issues with draft-ietf-netconf-udp-notif-04 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, 19 Nov 2021 02:13:43 -0000 --0000000000006f4d3905d11ad2ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, It is unclear why this document needs to reinvent content types using a 4-bit ET field. There is already a registry of integer mappings for CoAP https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#cont= ent-formats IMO this draft needs to (at least) define a header option for a 16-bit "CF" field. Implementations SHOULD provide a CF option if none of the standard ET types apply. One of the 16 standard ET values should mean "See CF option". Andy On Wed, Nov 17, 2021 at 11:31 AM Andy Bierman wrote: > > > On Wed, Nov 17, 2021 at 3:03 AM Pierre Francois < > pierre.francois.ietf@gmail.com> wrote: > >> Hello Andy, >> >> Thanks for the feedback, answers inline. >> >> Le mar. 16 nov. 2021 =C3=A0 04:45, Andy Bierman a = =C3=A9crit : >> >>> Hi, >>> >>> I am wondering if there implementations of this draft already. >>> IMO there are problems with in that prevent reasonable and >>> optimal implementations. >>> >> >> There is support of udp-notif publisher in VRP. >> There is a C collector lib for udp-notif in >> https://github.com/insa-unyte/udp-notif-c-collector >> >> >>> 1) Use of UDP as the Application Message Framing >>> UDP is a transport protocol. Tightly coupling one >>> NETCONF notification message to one UDP frame (+ fragments) >>> is not very optimal. >>> >> >> There is a segmentation option in the protocol, so a udp notif message i= s >> not tightly coupled to a UDP frame. >> > > But this segmentation is optional to implement. > My point is that application protocols like NETCONF have their own messag= e > framing > which does not exist here because the transport framing is used instead. > > >> >> >>> >>> 1A) wastes space in the UDP frame if the NETCONF notification >>> happens to be short >>> >> >> I don't get it, I'm sorry. To me a UDP header + small udp-notif header i= s >> rather short. >> > > If I can fit 100 notification messages in 1 UDP frame then I save 99% of > the redundant headers. > > > >> >> >>> 1B) imposes an application-level max-message-size >>> >> >> Not with the segmentation option, do we agree? >> > > > https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif#sectio= n-4.1 > > There can be 32767 segments of a max 65535 each: about 2G of data. > However the segment-size is allowed to be smaller and segmentation is > completely optional-to-implement. > > Application layer framing allows unlimited message size without any need > to support UDP segmentation at all, > > > >> >>> >>> 2) Not Efficient for Streaming Servers (no Message Chunking) >>> The application framing in NETCONF and RESTCONF (HTTP) is not >>> coupled to any transport protocol. Instead, a sender may emit as >>> many message chunks as desired. This is how a streaming server works. >>> Content comes from many different sources and it is sent on-the-fly >>> in chunks, instead of constructing large replies. >>> >>> - Application framing allows multiple notifications in one UDP fram= e >>> - Application framing does not need a max-message-size. >>> Streaming servers often do not know the size of the data that wil= l >>> be sent >>> in a notification. >>> >> >> I think we meet these goals. Let me think about this further. >> > > > I agree, by ignoring the idea that this protocol provides any normative > information > about the application layer protocol in use. This draft should remove an= y > hint > that the application payload is defined in this document. It is OK to sa= y > a different RFC (or spec) defines the content for a particular Encoding > Type. > > The "notification" in Figure 1 implies that the payload is one NETCONF > notification. > The draft should be clear that there is no structure to the payload > defined in this document. > > >> >>> >>> Q1) Should proprietary encoding be used to support application-layer >>> framing >>> or should the standard support it? >>> >> >> I think we'd need to meet on this or else it will end up with thousands >> of long emails ;) >> > > > I think the draft should let other documents define the exact content > expected in the payload. > I am used to application protocols defining specific message flows. Since > this draft does > not do that, it should not attempt to impose any rules on the application > payload at all. > > > >> >> >>> >>> 3) Protocol Message Encoding for CBOR >>> The NETCONF notification message is not modelled in YANG. >>> This is an open issue for YANG to CBOR encoding. >>> https://github.com/core-wg/yang-cbor/issues/96 >>> >>> The "notification" and "eventTime" elements do not have YANG definition= s. >>> SID assignments for these elements will be needed. >>> This draft is the likely place for these SID assignment requests to >>> the IESG and IANA. >>> >> >> Shouldn't these be transport agnostic? I don't see why this would be >> bound to udp-notif only and not, say, https-notif. >> > > This is related to application/yang-data+cbor. > A separate document for the SID assignments can be done. > > > >> >>> >>> 4) Subscription-ID Missing from Header >>> It is quite possible for one message generator to create >>> messages for multiple subscriptions. The subscription-ID >>> will be needed to dispatch notifications to subscribers correctly. >>> The Observation-Domain-ID is not sufficient. >>> >> >> Same answer as above, we understand obs-domain-id to be used in the >> transport to meet load-balancing goals, but thought it would violate lay= ers >> to place subscription-IDs in the transport itself. >> > > > So I will put the Subscription-ID here instead I guess because a common > use-case is to allow a Collector to support subscriptions from client > applications. > Only datastore subscriptions include a subscription-id, not event stream > notifications. > > >> >>> >>> 5) Private Encoding Option does not seem interoperable >>> >> The "Enc. Descr" field is completely opaque. >>> >> >> Correct. >> > > > Then perhaps there is no need for this at all since it does not > attempt to provide any interoperability? > > >> >> >>> This field could be structured to provide the "ET number space owner" >>> e.g, urn [wsp description] >>> >> >> Mmm it's a valid option. Our opinion was that once you want it >> interoperable, you should make it standard instead of private. >> If the wg thinks we should kinda standardize private options, I'm >> personally okay to add that to the draft. >> > > Use of structured strings like URNs does not seem like a bad thing that > should be discouraged. > The ET field is not interopable if every implementation can define their > own 4-bit values > and there is no standard way to tell them apart. Perhaps just a domain > name if a URN is too much of a burden. > > > >> >>> >>> Andy >>> >> >> Thanks a lot for your comments, >> >> Pierre. >> >> > Andy > > > >> Le mar. 16 nov. 2021 =C3=A0 04:45, Andy Bierman a = =C3=A9crit : >> >>> Hi, >>> >>> I am wondering if there implementations of this draft already. >>> IMO there are problems with in that prevent reasonable and >>> optimal implementations. >>> >>> 1) Use of UDP as the Application Message Framing >>> UDP is a transport protocol. Tightly coupling one >>> NETCONF notification message to one UDP frame (+ fragments) >>> is not very optimal. >>> >>> 1A) wastes space in the UDP frame if the NETCONF notification >>> happens to be short >>> 1B) imposes an application-level max-message-size >>> >>> 2) Not Efficient for Streaming Servers (no Message Chunking) >>> The application framing in NETCONF and RESTCONF (HTTP) is not >>> coupled to any transport protocol. Instead, a sender may emit as >>> many message chunks as desired. This is how a streaming server works. >>> Content comes from many different sources and it is sent on-the-fly >>> in chunks, instead of constructing large replies. >>> >>> - Application framing allows multiple notifications in one UDP fram= e >>> - Application framing does not need a max-message-size. >>> Streaming servers often do not know the size of the data that wil= l >>> be sent >>> in a notification. >>> >>> Q1) Should proprietary encoding be used to support application-layer >>> framing >>> or should the standard support it? >>> >>> 3) Protocol Message Encoding for CBOR >>> The NETCONF notification message is not modelled in YANG. >>> This is an open issue for YANG to CBOR encoding. >>> https://github.com/core-wg/yang-cbor/issues/96 >>> >>> The "notification" and "eventTime" elements do not have YANG definition= s. >>> SID assignments for these elements will be needed. >>> This draft is the likely place for these SID assignment requests to >>> the IESG and IANA. >>> >>> 4) Subscription-ID Missing from Header >>> It is quite possible for one message generator to create >>> messages for multiple subscriptions. The subscription-ID >>> will be needed to dispatch notifications to subscribers correctly. >>> The Observation-Domain-ID is not sufficient. >>> >>> 5) Private Encoding Option does not seem interoperable >>> The "Enc. Descr" field is completely opaque. >>> This field could be structured to provide the "ET number space owner" >>> e.g, urn [wsp description] >>> >>> >>> Andy >>> >>> >>> >>> _______________________________________________ >>> netconf mailing list >>> netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> >> --0000000000006f4d3905d11ad2ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

It is unclear why this document nee= ds to reinvent content types using a 4-bit ET field.

There is already a registry of integer mappings for CoAP

IMO this dr= aft needs to (at least) define a header option for a 16-bit "CF" = field.
Implementations SHOULD provide a CF option if none of = the standard ET types apply.
One of the 16 standard ET values sho= uld mean "See CF option".


Andy





On W= ed, Nov 17, 2021 at 11:31 AM Andy Bierman <andy@yumaworks.com> wrote:


=
On Wed, No= v 17, 2021 at 3:03 AM Pierre Francois <pierre.francois.ietf@gmail.com> w= rote:
Hello Andy,=C2=A0

Thanks for the feedback, answers inl= ine.=C2=A0

Le=C2=A0mar. 16 nov. 2021 =C3=A0=C2=A004:= 45, Andy Bierman <andy@yumaworks.com> a =C3=A9crit=C2=A0:
Hi,

I = am wondering if there implementations of this draft already.
IMO = there are problems with in that prevent reasonable and
optimal im= plementations.

There is = support of udp-notif publisher in VRP.=C2=A0
There is a C collect= or lib for udp-notif in=C2=A0https://github.com/insa-unyte/udp-notif= -c-collector=C2=A0=C2=A0


1) Use o= f UDP as the Application Message Framing
UDP is a transport proto= col.=C2=A0 Tightly coupling one
NETCONF notification message to o= ne UDP frame (+ fragments)
is not very optimal.

There is a segmentation option in the pro= tocol, so a udp notif message is not tightly coupled to a UDP frame.=C2=A0<= /div>

But this segmentati= on is optional to implement.
My point is that application protoco= ls like NETCONF have their own message framing
which does not exi= st here because the transport framing is used instead.
=C2=A0
=C2=A0

1A= ) wastes space in the UDP frame if the NETCONF notification=C2=A0
=C2=A0 =C2=A0 happens to be short

<= /span>
I don't get it, I'm sorry. To me a UDP header=C2=A0+ sma= ll udp-notif header is rather short.

If I can fit 100 notification messages in 1 UDP frame the= n I save 99% of the redundant headers.

=C2=A0
<= /div>
=C2=A0
1B) imposes an appl= ication-level max-message-size

Not with the segmentation option, do we agree?

https://data= tracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif#section-4.1

There can be 32767 segments of a max 65535 each: about= 2G of data.
However the segment-size is allowed to be smaller an= d segmentation is completely optional-to-implement.

Application layer framing allows unlimited message size without any need<= /div>
to support UDP segmentation at all,


=
=C2=A0

2) Not Efficient for Streaming Servers (no Message Chunking)
Th= e application framing in NETCONF and RESTCONF (HTTP) is not
coupl= ed to any transport protocol. Instead, a sender may emit as
many = message chunks as desired. This is how a streaming server works.
= Content comes from many different sources and it is sent on-the-fly
in chunks, instead of constructing large replies.

=C2=A0 =C2=A0 - Application framing allows multiple notifications in one= UDP frame
=C2=A0 =C2=A0 - Application framing does not need = a max-message-size.=C2=A0
=C2=A0 =C2=A0 =C2=A0 Streaming servers = often do not know the size of the data that will be sent=C2=A0
= =C2=A0 =C2=A0 =C2=A0 in a notification.

I think we meet these goals. Let me think about this furthe= r.=C2=A0


=
I agree, by ignoring the idea that this protocol provides any normativ= e information
about the application layer protocol in use.=C2=A0 = This draft should remove any hint
that the application payload is= defined in this document.=C2=A0 It is OK to say
a different RFC = (or spec) defines the content for a particular Encoding Type.
The "notification" in Figure 1 implies that the paylo= ad is one NETCONF notification.
The draft should be clear that th= ere is no structure to the payload defined in this document.

=
=C2=A0

Q1) Should proprietary encoding be used to support application-layer fram= ing
=C2=A0 =C2=A0 =C2=A0 =C2=A0or should the standard support it?=

I think we'd need t= o meet on this or else it will end up with thousands of long emails ;)


I think = the draft should let other documents define the exact content expected in t= he payload.
I am used to application protocols defining specific = message flows. Since this draft does
not do that, it should not a= ttempt to impose any rules on the application payload at all.
=C2=A0
<= div dir=3D"ltr">
=C2= =A0
=C2=A0 =C2=A0
3) Protocol Message Encoding for CBOR
The NETCONF notification message is not modelled in YANG.
This= is an open issue for YANG to CBOR encoding.

The "not= ification" and "eventTime" elements do not have YANG definit= ions.
SID assignments for these elements will be needed.
This draft is the likely place for these SID assignment requests to
=
the IESG and IANA.

= Shouldn't these be transport agnostic? I don't see why this would b= e bound to udp-notif only and not, say, https-notif.

This is related to application/yang-data+= cbor.=C2=A0
A separate document for the SID assignments can be do= ne.


=
=C2=A0

4) Subscription-ID Missing from Header
It is quite possible for one message generator to create
messages for multiple subscriptions.=C2=A0 The subscription-ID
w= ill be needed to dispatch notifications to subscribers correctly.
The Observation-Domain-ID is not sufficient.
=
Same answer as above, we understand obs-domain-id to = be used in the transport to meet load-balancing goals, but thought it would= violate layers to place subscription-IDs in the transport itself.


So I will pu= t the Subscription-ID here instead I guess because a common
use-c= ase is to allow a Collector to support subscriptions from client applicatio= ns.
Only datastore subscriptions include a subscription-id, not e= vent stream notifications.

=C2=A0

5) Private Encoding Option does = not seem interoperable
The "Enc. Descr" field is = completely opaque.

Correct.


Then p= erhaps there is no need for this at all since it does not
attempt= to provide any interoperability?
=C2=A0
=C2=A0
This field could be structured to pr= ovide the "ET number space owner"=C2=A0
e.g, urn [wsp d= escription]

Mmm it's= a valid option. Our opinion was that once you want it interoperable, you s= hould make it standard instead of private.=C2=A0
If the wg thinks= we should kinda standardize private options, I'm personally okay to ad= d that to the draft.=C2=A0

Use of structured strings like URNs does not seem like a bad thing = that should be discouraged.
The ET field is not interopable=C2=A0= if every implementation can define their own 4-bit values
and the= re is no standard way to tell them apart. Perhaps just a domain name if a U= RN is too much of a burden.


=C2=A0

Andy

Thanks a lot for your comments,=C2=A0

Pierre.=C2=A0


Andy

= =C2=A0
Le=C2=A0mar. 16 nov. 20= 21 =C3=A0=C2=A004:45, Andy Bierman <andy@yumaworks.com> a =C3=A9crit=C2=A0:
Hi,
I am wondering if there implementations of this draft alrea= dy.
IMO there are problems with in that prevent reasonable and
optimal implementations.

1) Use of UDP as = the Application Message Framing
UDP is a transport protocol.=C2= =A0 Tightly coupling one
NETCONF notification message to one UDP = frame (+ fragments)
is not very optimal.

1A) wastes space in the UDP frame if the NETCONF notification=C2=A0
<= div>=C2=A0 =C2=A0 happens to be short
1B) imposes an application-= level max-message-size

2) Not Efficient for Stream= ing Servers (no Message Chunking)
The application framing in NETC= ONF and RESTCONF (HTTP) is not
coupled to any transport protocol.= Instead, a sender may emit as
many message chunks as desired. Th= is is how a streaming server works.
Content comes from many diffe= rent sources and it is sent on-the-fly
in chunks, instead of cons= tructing large replies.

=C2=A0 =C2=A0 - Applicatio= n framing allows multiple notifications in one UDP frame
=C2= =A0 =C2=A0 - Application framing does not need a max-message-size.=C2=A0
=C2=A0 =C2=A0 =C2=A0 Streaming servers often do not know the size o= f the data that will be sent=C2=A0
=C2=A0 =C2=A0 =C2=A0 in a noti= fication.

Q1) Should proprietary encoding be used = to support application-layer framing
=C2=A0 =C2=A0 =C2=A0 =C2=A0o= r should the standard support it?
=C2=A0 =C2=A0
3) Prot= ocol Message Encoding for CBOR
The NETCONF notification message i= s not modelled in YANG.
This is an open issue for YANG to CBOR en= coding.
https://github.com/core-wg/yang-cbor/issues/96
<= /div>

The "notification" and "eventTime&q= uot; elements do not have YANG definitions.
SID assignments for t= hese elements will be needed.
This draft is the likely place for = these SID assignment requests to
the IESG and IANA.
4) Subscription-ID Missing from Header
It is quite po= ssible for one message generator to create
messages for multiple = subscriptions.=C2=A0 The subscription-ID
will be needed to dispat= ch notifications to subscribers correctly.
The Observation-Domain= -ID is not sufficient.

5) Private Encoding Option = does not seem interoperable
The "Enc. Descr" field is c= ompletely opaque.
This field could be structured to provide the &= quot;ET number space owner"=C2=A0
e.g, urn [wsp description]=


Andy


=

_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--0000000000006f4d3905d11ad2ed-- From nobody Fri Nov 19 07:48:21 2021 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 675F73A07DE; Fri, 19 Nov 2021 07:48:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu via Datatracker To: Cc: draft-ietf-netconf-sztp-csr.all@ietf.org, last-call@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163733688535.10662.12846915795187697217@ietfa.amsl.com> Reply-To: Dan Romascanu Date: Fri, 19 Nov 2021 07:48:05 -0800 Archived-At: Subject: [netconf] Opsdir last call review of draft-ietf-netconf-sztp-csr-11 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, 19 Nov 2021 15:48:11 -0000 Reviewer: Dan Romascanu Review result: Ready This document is Ready from an OPS-DIR perspective. This document extends the "get-bootstrapping-data" RPC defined in RFC 8572 to include an optional certificate signing request (CSR), enabling a bootstrapping device to additionally obtain an identity certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the "onboarding information" response provided in the RPC-reply. It proides the ability to provision an identity certificate that is purpose-built for a production environment during the bootstrapping process removing the reliance on the manufacturer CA, and enabling the bootstraped device to join the production environment with an appropriate identity. It's a clear and useful document, which needs to be read and understood by operators of IOT networks using the respective technologies. >From an operator perspective, the most relevant sections are 2 and 3. Section 2 refers to the ietf-sztp-csr module. It includes a Data Model Overview as well as hints about how the augmentation and structure defined by the "ietf-sztp-csr" module are used, including two additional tree diagrams showing the nodes placed where they are used. I found the example usage in Section 2.2 very useful. Section 2.3 contains the YANG module. Section 3 contains the description of the data model and the ietf-ztp-types YANG module. I have one question related to the type of certificates that are supported. Section 3.2 includes the following: The terms 'IDevID' and 'LDevID' are used herein to mean 'initial device identifier' and 'local device identifer'. These terms are defined consistent with the IEEE 802.1AR specification, though there is no requirement that a ZTP-client's identity certificate conform to IEEE 802.1AR. If my understanding is correct, the mechanism described in this document is generic. However, all the examples and the definitions in the modules refer to certification conform to IEEE 802.1AR. This is some kind of contradiction. Maybe some text speaking about other types of certificates should be added. Or maybe the scope should be defined more narrow to refer to IEEE 802.1AR. In any case it seems to me that Std-802.1AR-2018 needs to be a Normative Reference - one cannot understand this document without reading and understanding the IEEE standards. From nobody Sat Nov 20 09:24:05 2021 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 09A6F3A00AD for ; Sat, 20 Nov 2021 09:24:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, 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 TaWrxT9nl85b for ; Sat, 20 Nov 2021 09:23:58 -0800 (PST) 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 738323A00AE for ; Sat, 20 Nov 2021 09:23:57 -0800 (PST) Received: by mail.swisscom.com; Sat, 20 Nov 2021 18:23:53 +0100 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_1590136_882838588.1637429032664" X-Mailer: Totemo_TrustMail_(Notification) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QtfBxtCA6cWBE38bUlqZ0BWKdSsLkU3rMHvMDXGc7N+4wA23MWTQRJS69Mcqow7n0isjJDsni5aN6V1+36s8sVwHLzWeq3eFfsDpEiiPW3kC85eY0YsbwPt7s4tMtjLrndejgK6Fome0EiFC6mptszYUhgP/sTR+6hFwugJ/iGbaqMu78mlGdEj6Fuz25Kvqy5UT9OksBp65Tv/zH0YucA+BK6IVNR3w/tqDFapcaLX23bgGv+JCOMSRTykjTlAxB6ZzkhP3qWUnsiCrjlCL5Dn5GizWNBzFoWfdDvyZwVojc3vBeIDnXzwilcOX8UxtN5yvlTk6Wgo0AINIDqkGqQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=cxIcjk2Cieqw889xl/TMxXBOF28phxQ6lL7JWEqqpAM=; b=e+V3IaxINbFR8+LkfTHIjbKOtLugY2Hf+OLh3plUPM4b5yYTy3ITVJ97KK5IzngHCAjDrdFl2wSPQBiTVTSHFPan/TFtqpghFS+diBNH7HoIRwxxFD/oWho/tK3m/7YbRPwSN2wEiPA6diVAl/F/NfH19P4rXrYJ6yEYsJG3KlwcyRLTuObgqpJ9ze+nueXFYPDeTUpkiPfNyBCHLUHqU339Yjb8vUfVQJI86Hr3CPNbZzKEmbP2UFFI3GKU8vOgLJb7MT3H6H/1d8G9L5s/IJp0eGwwHAuEvsWixU2bJar1NpVhVpx4+SKa9LBpnFHpAUed3rz8x/WjLKfsF/fdNA== 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] Issues with draft-ietf-netconf-udp-notif-04 Thread-Index: AQHX2px0mTrR0HpnoEGx1KUWYd/Kp6wHkC2AgACN6oCABJLFEA== Date: Sat, 20 Nov 2021 17:23:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=swisscom.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 32da4fe6-60f1-4f38-606a-08d9ac4a8408 x-ms-traffictypediagnostic: ZR0P278MB0346: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OKUaG/ugDleugY7Vc+zXLEpGQXBV5PhXDH+mz5fgOCLDcpzcMtVMwFLJAi3EfcMl/S6eG2NU30WmMfZW99isfzP2B3E+MIwWin42r52sOcBvqwieJkoqXuJb21BHftb2lxbddRpmVqkCURp1q/qlLzr+bSUU5eVEuFB+wgHIOKFmcMJ3/kDF1k6d4GGvYGDXVlW2qiAcBiFeye9TcsunPIOhK1QRo30SDJRyigTfBCg8LCXbv1wD+1GQgZmXrzHHwbCvA2W9f42ctebULjmeVMtxlHOVOazEUwOkHAA1m6AdY6ekePePFcBlFl87Sm5Xv3lIjRUI+0bODMDGc0xZqvcOBl03GrhpFtMugAfDsESn13rQTdCFZ3nOGOV6iVvnuITuq8Sont1yrR9oThGXR/V5dgzgkT9IPMCk41ukHwgkErMLoNfAccEfR7/bpCT8+xNp3GysTlM/ErV8JJTEIBUdmyM90soZvrJowcGZc7O1Y5XtM3SqeBOUcE4sbVeWQgLgUXusFq7NEiHJPraC1bXKgAtezb8RhNOFOV7VpDHR6eiQzUOgpiOChBAXXafgnEizy6qij2jafv8fP8p6qP/IPzFDgnNoatrs9mo9G9XVBLdlxjgJmq13ntJMqiHY90YVQ7YoJJDPKtkepAWSO5lnVk3kd42pt8b2JBkEYWPsHle8gje3XZHPkxK7xZcxwMKoE2kn72hv4HmbNDgatbPd3+8g1x5Gm+zrHi4ppEMO/bZfgFqpC9ODtoK5ZfmAuZXHa7zqSmpOiTXScLctL6nsno3A9YhrDk6XlGCBhZ3nLb2pxU768eWpH7jsLGFL x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:ZRAP278MB0176.CHEP278.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(66556008)(66476007)(66446008)(110136005)(64756008)(4326008)(52536014)(66574015)(166002)(38100700002)(8936002)(66946007)(83380400001)(86362001)(9686003)(55016002)(8676002)(10290500003)(82960400001)(10300500001)(2906002)(5660300002)(33656002)(26005)(316002)(71200400001)(186003)(38070700005)(76116006)(966005)(7696005)(53546011)(508600001)(6506007)(122000001)(356854002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?UgbVrH8oHZ3JvVZT+tqNloqo+psUjhxCnybKGsImFa/zgfQJq7oZuNmuPT?= =?iso-8859-1?Q?ekDn+P8w220W0ivBV12znzwANtlPAcBasu6qmWLdfYIFqzhqt5mIhdFnbq?= =?iso-8859-1?Q?GZonhtBRtPioY9EbJQD2FpCZ4a5OZZ+xG6fJEKkc2RdG4D4bAlFQZClNck?= =?iso-8859-1?Q?XblYjiojZ7dDF45Io8MuHu6V6ncVws83labqyzfLq8V/iZnekDARMC3l8T?= =?iso-8859-1?Q?Ks/Q4TlMY5Slhd8CFabDa6J9MFcczSVZaQXJGvm9jCNXmC7CnRSFsiT91a?= =?iso-8859-1?Q?XisgdgBLFTmMTW+HFWSY6RuA9WYInB4boIE5ygD/obCoSXO0QQnHWVuRxR?= =?iso-8859-1?Q?aU8oS2QC8y7ewy7qrsb7P8VfhmpgSGfKTm5XPZK3g58RTxx1XWZ/oBQFKm?= =?iso-8859-1?Q?0wEoeuE7iT7MR7UiUivKs+hbZPF2e3WGj8RYqViOgyyPVeNYmt5OzJ+i3T?= =?iso-8859-1?Q?C/0PMEp399d/YPYBj0siOLUVI7NNzEwx4NDEp9EoJD1S/5ViYCKg7j7JtC?= =?iso-8859-1?Q?lJHhymKb/NJaZFwOa3urNE20cyfVDTeFMxdinPSe4+hD8FuBPV19IJgYZ6?= =?iso-8859-1?Q?ANdb04ZvivqZ4mF+3wc2yKI1zwh6FcQAAp8CbK2rM0HgejgYmJfZdDLMUS?= =?iso-8859-1?Q?SbLX+aGy40+jZCvsvw/6S3SUi/pDVaJxvQa5BtnAp9d1BDu3mfr4fejkc+?= =?iso-8859-1?Q?fSpOA/lgYoI4RX1RHM8lBzZCKkUNYwU933U3lTCC9BuyeyUblp0kN361YS?= =?iso-8859-1?Q?mJr5Zy+BO57Ls6hSE9Qu9CDQn1ws4UPKlmB51CJHq/pNVkgvMEu4Eutn/R?= =?iso-8859-1?Q?6fKzeOMrvbms2GM8KZoqWmCNG3sWXj+d9xu/cYNDHIAfw/7+WyeqGz109y?= =?iso-8859-1?Q?tMe8UyUug7SyZLTO7dZr8e0e/wL2Se10iGkrCGGT6MfZzk2W6bxb+Uu2nj?= =?iso-8859-1?Q?Chxj+AJW2WFOOj0cBleU0g/GXzqQLL/fRw6uT+3apv7GphGjdlA52O8wHq?= =?iso-8859-1?Q?EvNfsDhKcONoaXpfFhBiHkhPCLqRSytobStvy2sxXU7udsGMVwTDOJBmKz?= =?iso-8859-1?Q?t76vWUb55KOeOtoT0MitCn5OsoeslvLQ6DrHK9S/zBw2XakOTmXRdlAfKm?= =?iso-8859-1?Q?HWk3JI6TO55mDv1Lu8wsnM33WG2e3Ncdf5Wle9HJyFBUKHtkL4QiASgLcI?= =?iso-8859-1?Q?qA0KTmrn+zFwglk8BY8O+C7jHYzoT+UajLYktBCRf37x99Y0SMMk+aqUWv?= =?iso-8859-1?Q?B1Xp4ltmy7ROgbBXWMaM3cjl+NRM6O+TNYGIJcvH23203RHW6PSJhKeO0W?= =?iso-8859-1?Q?aDzXgBEzX1e2yuphSHeXKyXOJL1kqGg1QWrVtMgqcE8FuEx3GmOeTwp1/B?= =?iso-8859-1?Q?RJOTCP1dvYJeITgrRBknLyfNXCUHlYEF8jNw/NmETTpDFpvU4JQ5H4+Vxw?= =?iso-8859-1?Q?UYDlVotwgy7VQYtrQJ00hXLT9KPCqphg32qyKHw+OK1tq9yH2jvjKhycrw?= =?iso-8859-1?Q?RrqHMaPHhnAG+CVbNK6GDdh8MxaS8/fMQD9EwL7US5Ivh1d0aAhy28yJLE?= =?iso-8859-1?Q?J+jTKvGvxpN05PpMnxzS0aYl8XNSYa+9Mm3EPMB5WkcgTcG/IWhaVb/Cg4?= =?iso-8859-1?Q?Rh2LCiNaXbJ5/XjffcGLnwINA1rLmeWHq2zPjlj9aF9yLb+waYBwqrAw2B?= =?iso-8859-1?Q?9k0YOjxDlfjErY3VOtxzO8UfTiKWWSgWobTJiHj3MP3OGFZ8CXKkVcaS5y?= =?iso-8859-1?Q?7MTA=3D=3D?= X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: ZRAP278MB0176.CHEP278.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 32da4fe6-60f1-4f38-606a-08d9ac4a8408 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2021 17:23:48.9616 (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: wlY6EmzLyjWUdoJgxGM3nLFsC/Qs/ercS7Sn0cFVbEfNeLz/5Qci0knjlEzj+3kxkPOIMp7QOxQ2HXGqGFaJwGkXY4QpUQLZ2lpEYN3lY4I= X-MS-Exchange-Transport-CrossTenantHeadersStamped: ZR0P278MB0346 X-OriginatorOrg: swisscom.com X-CFilter-Loop: Reflected X-Trustmail: processed Archived-At: Subject: Re: [netconf] Issues with draft-ietf-netconf-udp-notif-04 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, 20 Nov 2021 17:24:03 -0000 ------=_Part_1590136_882838588.1637429032664 Content-Type: multipart/alternative; boundary="_000_ZRAP278MB01768ADC3C161FE2D07441CC899D9ZRAP278MB0176CHEP_" Content-Language: en-US --_000_ZRAP278MB01768ADC3C161FE2D07441CC899D9ZRAP278MB0176CHEP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Andy and Mahesh, Following this thread, wherever it makes sense to add an application messag= e header to allow multiple notification messages being carried in one singl= e udp-notif message, we need to have the full context. I understood from section 4.2 of draft-ietf-netconf-notification-messages https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-messa= ges#section-4.2 That the intend of the working group is to support multiple notifications w= ithin one notification-message. Correct? >From the data tracker https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-messages/h= istory/ I understood that this draft is currently on-hold until the first transport= draft (draft-ietf-netconf-udp-notif or draft-ietf-netconf-https-notif) has= reached RFC status. Correct? If both correct, what is the added value of supporting multiple notificatio= n messages within the notification itself AND supporting multiple notificat= ions at transport within an application framing as well? >From a standardization point of view we should avoid duplicity as much as p= ossible. If it is the intend of the working group to address this with draf= t-ietf-netconf-notification-messages than I suggest not to address this in = draft draft-ietf-netconf-udp-notif as well. Have a transport agnostic imple= mentation. Best wishes Thomas From: netconf On Behalf Of Andy Bierman Sent: Wednesday, November 17, 2021 8:31 PM To: Pierre Francois Cc: Netconf Subject: Re: [netconf] Issues with draft-ietf-netconf-udp-notif-04 On Wed, Nov 17, 2021 at 3:03 AM Pierre Francois > wrote: Hello Andy, Thanks for the feedback, answers inline. Le mar. 16 nov. 2021 =E0 04:45, Andy Bierman > a =E9crit : Hi, I am wondering if there implementations of this draft already. IMO there are problems with in that prevent reasonable and optimal implementations. There is support of udp-notif publisher in VRP. There is a C collector lib for udp-notif in https://github.com/insa-unyte/u= dp-notif-c-collector 1) Use of UDP as the Application Message Framing UDP is a transport protocol. Tightly coupling one NETCONF notification message to one UDP frame (+ fragments) is not very optimal. There is a segmentation option in the protocol, so a udp notif message is n= ot tightly coupled to a UDP frame. But this segmentation is optional to implement. My point is that application protocols like NETCONF have their own message = framing which does not exist here because the transport framing is used instead. 1A) wastes space in the UDP frame if the NETCONF notification happens to be short I don't get it, I'm sorry. To me a UDP header + small udp-notif header is r= ather short. If I can fit 100 notification messages in 1 UDP frame then I save 99% of th= e redundant headers. 1B) imposes an application-level max-message-size Not with the segmentation option, do we agree? https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif#section-= 4.1 There can be 32767 segments of a max 65535 each: about 2G of data. However the segment-size is allowed to be smaller and segmentation is compl= etely optional-to-implement. Application layer framing allows unlimited message size without any need to support UDP segmentation at all, 2) Not Efficient for Streaming Servers (no Message Chunking) The application framing in NETCONF and RESTCONF (HTTP) is not coupled to any transport protocol. Instead, a sender may emit as many message chunks as desired. This is how a streaming server works. Content comes from many different sources and it is sent on-the-fly in chunks, instead of constructing large replies. - Application framing allows multiple notifications in one UDP frame - Application framing does not need a max-message-size. Streaming servers often do not know the size of the data that will be= sent in a notification. I think we meet these goals. Let me think about this further. I agree, by ignoring the idea that this protocol provides any normative inf= ormation about the application layer protocol in use. This draft should remove any = hint that the application payload is defined in this document. It is OK to say a different RFC (or spec) defines the content for a particular Encoding Typ= e. The "notification" in Figure 1 implies that the payload is one NETCONF noti= fication. The draft should be clear that there is no structure to the payload defined= in this document. Q1) Should proprietary encoding be used to support application-layer framin= g or should the standard support it? I think we'd need to meet on this or else it will end up with thousands of = long emails ;) I think the draft should let other documents define the exact content expec= ted in the payload. I am used to application protocols defining specific message flows. Since t= his draft does not do that, it should not attempt to impose any rules on the application p= ayload at all. 3) Protocol Message Encoding for CBOR The NETCONF notification message is not modelled in YANG. This is an open issue for YANG to CBOR encoding. https://github.com/core-wg/yang-cbor/issues/96 The "notification" and "eventTime" elements do not have YANG definitions. SID assignments for these elements will be needed. This draft is the likely place for these SID assignment requests to the IESG and IANA. Shouldn't these be transport agnostic? I don't see why this would be bound = to udp-notif only and not, say, https-notif. This is related to application/yang-data+cbor. A separate document for the SID assignments can be done. 4) Subscription-ID Missing from Header It is quite possible for one message generator to create messages for multiple subscriptions. The subscription-ID will be needed to dispatch notifications to subscribers correctly. The Observation-Domain-ID is not sufficient. Same answer as above, we understand obs-domain-id to be used in the transpo= rt to meet load-balancing goals, but thought it would violate layers to pla= ce subscription-IDs in the transport itself. So I will put the Subscription-ID here instead I guess because a common use-case is to allow a Collector to support subscriptions from client appli= cations. Only datastore subscriptions include a subscription-id, not event stream no= tifications. 5) Private Encoding Option does not seem interoperable The "Enc. Descr" field is completely opaque. Correct. Then perhaps there is no need for this at all since it does not attempt to provide any interoperability? This field could be structured to provide the "ET number space owner" e.g, urn [wsp description] Mmm it's a valid option. Our opinion was that once you want it interoperabl= e, you should make it standard instead of private. If the wg thinks we should kinda standardize private options, I'm personall= y okay to add that to the draft. Use of structured strings like URNs does not seem like a bad thing that sho= uld be discouraged. The ET field is not interopable if every implementation can define their ow= n 4-bit values and there is no standard way to tell them apart. Perhaps just a domain name= if a URN is too much of a burden. Andy Thanks a lot for your comments, Pierre. Andy Le mar. 16 nov. 2021 =E0 04:45, Andy Bierman > a =E9crit : Hi, I am wondering if there implementations of this draft already. IMO there are problems with in that prevent reasonable and optimal implementations. 1) Use of UDP as the Application Message Framing UDP is a transport protocol. Tightly coupling one NETCONF notification message to one UDP frame (+ fragments) is not very optimal. 1A) wastes space in the UDP frame if the NETCONF notification happens to be short 1B) imposes an application-level max-message-size 2) Not Efficient for Streaming Servers (no Message Chunking) The application framing in NETCONF and RESTCONF (HTTP) is not coupled to any transport protocol. Instead, a sender may emit as many message chunks as desired. This is how a streaming server works. Content comes from many different sources and it is sent on-the-fly in chunks, instead of constructing large replies. - Application framing allows multiple notifications in one UDP frame - Application framing does not need a max-message-size. Streaming servers often do not know the size of the data that will be= sent in a notification. Q1) Should proprietary encoding be used to support application-layer framin= g or should the standard support it? 3) Protocol Message Encoding for CBOR The NETCONF notification message is not modelled in YANG. This is an open issue for YANG to CBOR encoding. https://github.com/core-wg/yang-cbor/issues/96 The "notification" and "eventTime" elements do not have YANG definitions. SID assignments for these elements will be needed. This draft is the likely place for these SID assignment requests to the IESG and IANA. 4) Subscription-ID Missing from Header It is quite possible for one message generator to create messages for multiple subscriptions. The subscription-ID will be needed to dispatch notifications to subscribers correctly. The Observation-Domain-ID is not sufficient. 5) Private Encoding Option does not seem interoperable The "Enc. Descr" field is completely opaque. This field could be structured to provide the "ET number space owner" e.g, urn [wsp description] Andy _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_ZRAP278MB01768ADC3C161FE2D07441CC899D9ZRAP278MB0176CHEP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear Andy and Mahesh,

Following this thread, wherever it makes sense to add an applicat= ion message header to allow multiple notification messages being carried in one single udp-notif message, we need to have th= e full context.

I understood from section 4.2 of draft-ietf-netconf-notification-= messages

https://datatracker.ietf.org/do= c/html/draft-ietf-netconf-notification-messages#section-4.2=

That the intend of the working group is to support multiple notif= ications within one notification-message. Correct?

 

From the data tracker

https://datatracker.ietf.org/doc/draft-= ietf-netconf-notification-messages/history/

I understood that this draft is currently on-hold until the first= transport draft (draft-ietf-netconf-udp-notif or draft-ietf-netconf-https-notif) has reached RFC status. Correct?

If both correct, what is the added value of supporting multiple n= otification messages within the notification itself AND supporting multiple notifications at transport within an application f= raming as well?

From a standardization point of view we should avoid duplicity as= much as possible. If it is the intend of the working group to address this with draft-ietf-netconf-notification-messages than I= suggest not to address this in draft draft-ietf-netconf-udp-notif as well. Have a transport agno= stic implementation.

=  

Best = wishes

Thoma= s

=  

From: netconf <netconf-bounces@ietf.org> On Behalf Of Andy Bierman
Sent: Wednesday, November 17, 2021 8:31 PM
To: Pierre Francois <pierre.francois.ietf@gmail.com>
Cc: Netconf <netconf@ietf.org>
Subject: Re: [netconf] Issues with draft-ietf-netconf-udp-notif-04

 

 

 

On Wed, Nov 17, 2021 at 3:03 AM Pierre Francois <= pierre.= francois.ietf@gmail.com> wrote:

Hello Andy, 

 

Thanks for the feedback, answers inline. <= /o:p>

 

Le mar. 16 nov. 2021 =E0 04:45, Andy Bierm= an <andy@yumawor= ks.com> a =E9crit :

Hi,

 

I am wondering if there implementations of this draf= t already.

IMO there are problems with in that prevent reasonab= le and

optimal implementations.

 

There is support of udp-notif publisher in VRP. = ;

There is a C collector lib for udp-notif in https://github.com/insa-unyte/udp-notif-c-collector&n= bsp; 

 

 

1) Use of UDP as the Application Message Framing

UDP is a transport protocol.  Tightly coupling = one

NETCONF notification message to one UDP frame (+ fra= gments)

is not very optimal.

 

There is a segmentation option in the protocol, so a= udp notif message is not tightly coupled to a UDP frame. <= /p>

 

But this segmentation is optional to implement.=

My point is that application protocols like NETCONF = have their own message framing

which does not exist here because the transport fram= ing is used instead.

 

 

 

1A) wastes space in the UDP frame if the NETCONF not= ification 

    happens to be short

 

I don't get it, I'm sorry. To me a UDP header += small udp-notif header is rather short.

 

If I can fit 100 notification messages in 1 UDP fram= e then I save 99% of the redundant headers.

 

 

 

1B) imposes an application-level max-message-size

 

Not with the segmentation option, do we agree?<= /o:p>

 

 

There can be 32767 segments of a max 65535 each: abo= ut 2G of data.

However the segment-size is allowed to be smaller an= d segmentation is completely optional-to-implement.

 

Application layer framing allows unlimited message s= ize without any need

to support UDP segmentation at all,

 

 

 

 

2) Not Efficient for Streaming Servers (no Message C= hunking)

The application framing in NETCONF and RESTCONF (HTT= P) is not

coupled to any transport protocol. Instead, a sender= may emit as

many message chunks as desired. This is how a stream= ing server works.

Content comes from many different sources and it is = sent on-the-fly

in chunks, instead of constructing large replies.

 

    - Application framing allows multiple = notifications in one UDP frame

    - Application framing does not need a = max-message-size. 

      Streaming servers often do not = know the size of the data that will be sent 

      in a notification.

 

I think we meet these goals. Let me think about this= further. 

 

 

I agree, by ignoring the idea that this protocol pro= vides any normative information

about the application layer protocol in use.  T= his draft should remove any hint

that the application payload is defined in this docu= ment.  It is OK to say

a different RFC (or spec) defines the content for a = particular Encoding Type.

 

The "notification" in Figure 1 implies tha= t the payload is one NETCONF notification.

The draft should be clear that there is no structure= to the payload defined in this document.

 

 

 

Q1) Should proprietary encoding be used to support a= pplication-layer framing

       or should the standard su= pport it?

 

I think we'd need to meet on this or else it will en= d up with thousands of long emails ;)

 

 

I think the draft should let other documents define = the exact content expected in the payload.

I am used to application protocols defining specific= message flows. Since this draft does

not do that, it should not attempt to impose any rul= es on the application payload at all.

 

 

 

This is related to application/yang-data+cbor. =

A separate document for the SID assignments can be d= one.

 

 

 

 

4) Subscription-ID Missing from Header

It is quite possible for one message generator to cr= eate

messages for multiple subscriptions.  The subsc= ription-ID

will be needed to dispatch notifications to subscrib= ers correctly.

The Observation-Domain-ID is not sufficient.

 

Same answer as above, we understand obs-domain-id to= be used in the transport to meet load-balancing goals, but thought it woul= d violate layers to place subscription-IDs in the transport itself.

 

 

So I will put the Subscription-ID here instead I gue= ss because a common

use-case is to allow a Collector to support subscrip= tions from client applications.

Only datastore subscriptions include a subscription-= id, not event stream notifications.

 

 

 

5) Private Encoding Option does not seem interoperab= le

The "Enc. Descr" field is completely opaqu= e.

 

Correct.

 

 

Then perhaps there is no need for this at all since = it does not

attempt to provide any interoperability?<= /p>

 

 

This field could be structured to provide the "= ET number space owner" 

e.g, urn [wsp description]

 

Mmm it's a valid option. Our opinion was that once y= ou want it interoperable, you should make it standard instead of private.&n= bsp;

If the wg thinks we should kinda standardize private= options, I'm personally okay to add that to the draft. 

 

Use of structured strings like URNs does not seem li= ke a bad thing that should be discouraged.

The ET field is not interopable if every implem= entation can define their own 4-bit values

and there is no standard way to tell them apart. Per= haps just a domain name if a URN is too much of a burden.

 

 

 

 

Andy

 

Thanks a lot for your comments, 

 

Pierre. 

 

 

Andy

 

 

Hi,

 

I am wondering if there implementations of this draf= t already.

IMO there are problems with in that prevent reasonab= le and

optimal implementations.

 

1) Use of UDP as the Application Message Framing

UDP is a transport protocol.  Tightly coupling = one

NETCONF notification message to one UDP frame (+ fra= gments)

is not very optimal.

 

1A) wastes space in the UDP frame if the NETCONF not= ification 

    happens to be short

1B) imposes an application-level max-message-size

 

2) Not Efficient for Streaming Servers (no Message C= hunking)

The application framing in NETCONF and RESTCONF (HTT= P) is not

coupled to any transport protocol. Instead, a sender= may emit as

many message chunks as desired. This is how a stream= ing server works.

Content comes from many different sources and it is = sent on-the-fly

in chunks, instead of constructing large replies.

 

    - Application framing allows multiple = notifications in one UDP frame

    - Application framing does not need a = max-message-size. 

      Streaming servers often do not = know the size of the data that will be sent 

      in a notification.

 

Q1) Should proprietary encoding be used to support a= pplication-layer framing

       or should the standard su= pport it?

   

3) Protocol Message Encoding for CBOR

The NETCONF notification message is not modelled in = YANG.

This is an open issue for YANG to CBOR encoding.

 

The "notification" and "eventTime&quo= t; elements do not have YANG definitions.

SID assignments for these elements will be needed.

This draft is the likely place for these SID assignm= ent requests to

the IESG and IANA.

 

4) Subscription-ID Missing from Header

It is quite possible for one message generator to cr= eate

messages for multiple subscriptions.  The subsc= ription-ID

will be needed to dispatch notifications to subscrib= ers correctly.

The Observation-Domain-ID is not sufficient.

 

5) Private Encoding Option does not seem interoperab= le

The "Enc. Descr" field is completely opaqu= e.

This field could be structured to provide the "= ET number space owner" 

e.g, urn [wsp description]

 

 

Andy

 

 

 

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

--_000_ZRAP278MB01768ADC3C161FE2D07441CC899D9ZRAP278MB0176CHEP_-- ------=_Part_1590136_882838588.1637429032664 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 HuzkCrsqTOsJYDnOymLYLm4AADGCA7swggO3AgEBMG4wVjELMAkGA1UEBhMCQ0gxFTATBgNVBAoT DFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFsIFNpbHZlciBDQSAyMDE0 IC0gRzIyAhR4i6Eec1b72YkIjJKOk4r62lxMbzANBglghkgBZQMEAgEFAKCCAh4wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjExMTIwMTcyMzUyWjAtBgkqhkiG9w0B CTQxIDAeMA0GCWCGSAFlAwQCAQUAoQ0GCSqGSIb3DQEBCwUAMC8GCSqGSIb3DQEJBDEiBCA9TFXb RLojBNxyjNOMdoEt1l1o96ObJP9lldKXZIVwSTB9BgkrBgEEAYI3EAQxcDBuMFYxCzAJBgNVBAYT AkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBT aWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wfwYLKoZIhvcNAQkQAgsx cKBuMFYxCzAJBgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNz U2lnbiBQZXJzb25hbCBTaWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8w gYMGCSqGSIb3DQEJDzF2MHQwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwCwYJYIZI AWUDBAIEMAsGCWCGSAFlAwQCBzANBgkqhkiG9w0BAQsFAASCAQBEwlwEm5D02vEqKGS06zAlQzfO X/4Mi3JaZukZTvlT+jlH1nSPerj4PjyKPuIULmd2iSR2Is+0PkTdFrA3cpCZNzzbEW+Lcx6RUOjo zwQ5J4qmBwDvck9uTTOtAD56y4e2+mMRPbSzzzX3ZpXnjjfCUSyJnE/pxP3OsKlqIqNxJ8cSCQnR gTjWwIhX6zzLr1v+lwVlw0yZTYHN7CCczrObz5rrcSRt/JXtTS/kPGNdGwjsFsNWE8HUJT+BgPIM SGrHm6NeLUJZ6Ikc5GvwGpd9astJ0PPhsvfvU1a04dt9vbyUdy2PMuy64yLYL+5w/oDs7Qc3k3hn yFt31t8JqSfVAAAAAAAA ------=_Part_1590136_882838588.1637429032664-- From nobody Sat Nov 20 09:49:24 2021 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 0BBB33A0403 for ; Sat, 20 Nov 2021 09:49:22 -0800 (PST) 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.20210112.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 wCOWcNjHXwHS for ; Sat, 20 Nov 2021 09:49:17 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 721B03A03F4 for ; Sat, 20 Nov 2021 09:49:16 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id m27so58746333lfj.12 for ; Sat, 20 Nov 2021 09:49:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SezSqNc4lnHWMfFNXhJUwf/jPeFii4+aRL6zbAotEqs=; b=XAabd5N1gkd7sy+Daph+o85M2/6jsGg+ssMfMZKQvM6zz+cS0opp7EiuZ5dUX1E6kT tdzgrOlWPAjdtAGFFpFCUYNG2+G8sIHHfsyN+Ty3AslmTWxPZWuiKqvDO8Snx9gHLQuD hNktalVM+1qY6GPMulj+EyYF8+i8aHdzWrmJ0A4VHwb2hlKfQUq3hPrT2dY1g5zxn2HH qXhPPZk+T9U0085IZdFFolSR6cRKn33XuwKZWoiM68hio6yFh7FlyrG6GIeddQuIK5FK 9Qdw8bzSC0jX6Nd5iLkpRzszatozYE3Cj/mL+Y+ZWNZkIGL3enB/fVCMwhE/4BVtKdVR 8wTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SezSqNc4lnHWMfFNXhJUwf/jPeFii4+aRL6zbAotEqs=; b=EjsTY8jq7gjpb6gkTcZ5IkU6gkvuo8CinVW96hVHcjgikZtTW14e1wgBGyavmaa5VK UoG0377oQv8mgBifNdm+NIp2jqRuMBGWONe5Jj7JMwmyWHxopW3ujI56uiRwXPm3UqRH ZJfSLyLwk/VcYSdlX5V54Ka2rpB7WPqqpSp65PgqXgjyEDPi85zUqgn/RIQU2w9Iu2gI DBa2ObP5xXvfkSZ8QhpRISQE/sHyHmtYupzfS/yE4/iJWre3TlMW+JXnpfJXxpmXqIYu UmEKzh3/iXMQM6ODxj+YJjChadWCxDExNWcrArhAFz6tyKHQT2odmWUxEvuVATQrCaqB KcCg== X-Gm-Message-State: AOAM532ykauqLNcMumDKh0oidmhCv0VgCxSXozWQu9EnY3Wq61enMURh 4gHQOYWRTJg59xz9VkeMo7JvZ2cM0+MHsZhmIeGQUg== X-Google-Smtp-Source: ABdhPJy8CJGqVQWfSmCRB+8zdoNqtb4mQTxk2XiVP95ZpiLp5oOQ9/wYNh7OkGuW2ruU16Zgm/BmBZqZPah5bmpSkNw= X-Received: by 2002:a05:6512:2305:: with SMTP id o5mr44131472lfu.362.1637430553131; Sat, 20 Nov 2021 09:49:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Sat, 20 Nov 2021 09:49:02 -0800 Message-ID: To: Thomas.Graf@swisscom.com Cc: Pierre Francois , Netconf Content-Type: multipart/alternative; boundary="00000000000076cfa905d13c02ca" Archived-At: Subject: Re: [netconf] Issues with draft-ietf-netconf-udp-notif-04 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, 20 Nov 2021 17:49:22 -0000 --00000000000076cfa905d13c02ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I have 2 separate issues with the protocol design. Maybe only one is in scope. 1) ET field I would like to see more standards value with the proprietary encoding type field. The standard encoding types are also under-specified. (e.g. if ET=3Dxml does the payload contain exactly one XML instance documen= t? If, so any particular element, or undefined?) Application Content Format should be more standard. 2) Application Framing This is to support Binary NETCONF or RESTCONF (not under development by the WG). This issue can be dropped, since the WG does not agree any valid use-cases exist for reusing the application layer with the application/yang-data+cbor media type. Andy On Sat, Nov 20, 2021 at 9:23 AM wrote: > Dear Andy and Mahesh, > > Following this thread, wherever it makes sense to add an application > message header to allow multiple notification messages being carried in o= ne > single udp-notif message, we need to have the full context. > > I understood from section 4.2 of draft-ietf-netconf-notification-messages > > > https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-mes= sages#section-4.2 > > That the intend of the working group is to support multiple notifications > within one notification-message. Correct? > > > > From the data tracker > > > https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-messages= /history/ > > I understood that this draft is currently on-hold until the first > transport draft (draft-ietf-netconf-udp-notif or > draft-ietf-netconf-https-notif) has reached RFC status. Correct? > > If both correct, what is the added value of supporting multiple > notification messages within the notification itself AND supporting > multiple notifications at transport within an application framing as well= ? > > From a standardization point of view we should avoid duplicity as much as > possible. If it is the intend of the working group to address this with > draft-ietf-netconf-notification-messages than I suggest not to address th= is > in draft draft-ietf-netconf-udp-notif as well. Have a transport agnostic > implementation. > > > > Best wishes > > Thomas > > > > *From:* netconf *On Behalf Of *Andy Bierman > *Sent:* Wednesday, November 17, 2021 8:31 PM > *To:* Pierre Francois > *Cc:* Netconf > *Subject:* Re: [netconf] Issues with draft-ietf-netconf-udp-notif-04 > > > > > > > > On Wed, Nov 17, 2021 at 3:03 AM Pierre Francois < > pierre.francois.ietf@gmail.com> wrote: > > Hello Andy, > > > > Thanks for the feedback, answers inline. > > > > Le mar. 16 nov. 2021 =C3=A0 04:45, Andy Bierman a = =C3=A9crit : > > Hi, > > > > I am wondering if there implementations of this draft already. > > IMO there are problems with in that prevent reasonable and > > optimal implementations. > > > > There is support of udp-notif publisher in VRP. > > There is a C collector lib for udp-notif in > https://github.com/insa-unyte/udp-notif-c-collector > > > > > > > > 1) Use of UDP as the Application Message Framing > > UDP is a transport protocol. Tightly coupling one > > NETCONF notification message to one UDP frame (+ fragments) > > is not very optimal. > > > > There is a segmentation option in the protocol, so a udp notif message is > not tightly coupled to a UDP frame. > > > > But this segmentation is optional to implement. > > My point is that application protocols like NETCONF have their own messag= e > framing > > which does not exist here because the transport framing is used instead. > > > > > > > > 1A) wastes space in the UDP frame if the NETCONF notification > > happens to be short > > > > I don't get it, I'm sorry. To me a UDP header + small udp-notif header is > rather short. > > > > If I can fit 100 notification messages in 1 UDP frame then I save 99% of > the redundant headers. > > > > > > > > 1B) imposes an application-level max-message-size > > > > Not with the segmentation option, do we agree? > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif#sectio= n-4.1 > > > > > There can be 32767 segments of a max 65535 each: about 2G of data. > > However the segment-size is allowed to be smaller and segmentation is > completely optional-to-implement. > > > > Application layer framing allows unlimited message size without any need > > to support UDP segmentation at all, > > > > > > > > > > 2) Not Efficient for Streaming Servers (no Message Chunking) > > The application framing in NETCONF and RESTCONF (HTTP) is not > > coupled to any transport protocol. Instead, a sender may emit as > > many message chunks as desired. This is how a streaming server works. > > Content comes from many different sources and it is sent on-the-fly > > in chunks, instead of constructing large replies. > > > > - Application framing allows multiple notifications in one UDP frame > > - Application framing does not need a max-message-size. > > Streaming servers often do not know the size of the data that will > be sent > > in a notification. > > > > I think we meet these goals. Let me think about this further. > > > > > > I agree, by ignoring the idea that this protocol provides any normative > information > > about the application layer protocol in use. This draft should remove an= y > hint > > that the application payload is defined in this document. It is OK to sa= y > > a different RFC (or spec) defines the content for a particular Encoding > Type. > > > > The "notification" in Figure 1 implies that the payload is one NETCONF > notification. > > The draft should be clear that there is no structure to the payload > defined in this document. > > > > > > > > Q1) Should proprietary encoding be used to support application-layer > framing > > or should the standard support it? > > > > I think we'd need to meet on this or else it will end up with thousands o= f > long emails ;) > > > > > > I think the draft should let other documents define the exact content > expected in the payload. > > I am used to application protocols defining specific message flows. Since > this draft does > > not do that, it should not attempt to impose any rules on the application > payload at all. > > > > > > > > > > 3) Protocol Message Encoding for CBOR > > The NETCONF notification message is not modelled in YANG. > > This is an open issue for YANG to CBOR encoding. > > https://github.com/core-wg/yang-cbor/issues/96 > > > > > The "notification" and "eventTime" elements do not have YANG definitions. > > SID assignments for these elements will be needed. > > This draft is the likely place for these SID assignment requests to > > the IESG and IANA. > > > > Shouldn't these be transport agnostic? I don't see why this would be boun= d > to udp-notif only and not, say, https-notif. > > > > This is related to application/yang-data+cbor. > > A separate document for the SID assignments can be done. > > > > > > > > > > 4) Subscription-ID Missing from Header > > It is quite possible for one message generator to create > > messages for multiple subscriptions. The subscription-ID > > will be needed to dispatch notifications to subscribers correctly. > > The Observation-Domain-ID is not sufficient. > > > > Same answer as above, we understand obs-domain-id to be used in the > transport to meet load-balancing goals, but thought it would violate laye= rs > to place subscription-IDs in the transport itself. > > > > > > So I will put the Subscription-ID here instead I guess because a common > > use-case is to allow a Collector to support subscriptions from client > applications. > > Only datastore subscriptions include a subscription-id, not event stream > notifications. > > > > > > > > 5) Private Encoding Option does not seem interoperable > > The "Enc. Descr" field is completely opaque. > > > > Correct. > > > > > > Then perhaps there is no need for this at all since it does not > > attempt to provide any interoperability? > > > > > > This field could be structured to provide the "ET number space owner" > > e.g, urn [wsp description] > > > > Mmm it's a valid option. Our opinion was that once you want it > interoperable, you should make it standard instead of private. > > If the wg thinks we should kinda standardize private options, I'm > personally okay to add that to the draft. > > > > Use of structured strings like URNs does not seem like a bad thing that > should be discouraged. > > The ET field is not interopable if every implementation can define their > own 4-bit values > > and there is no standard way to tell them apart. Perhaps just a domain > name if a URN is too much of a burden. > > > > > > > > > > Andy > > > > Thanks a lot for your comments, > > > > Pierre. > > > > > > Andy > > > > > > Le mar. 16 nov. 2021 =C3=A0 04:45, Andy Bierman a = =C3=A9crit : > > Hi, > > > > I am wondering if there implementations of this draft already. > > IMO there are problems with in that prevent reasonable and > > optimal implementations. > > > > 1) Use of UDP as the Application Message Framing > > UDP is a transport protocol. Tightly coupling one > > NETCONF notification message to one UDP frame (+ fragments) > > is not very optimal. > > > > 1A) wastes space in the UDP frame if the NETCONF notification > > happens to be short > > 1B) imposes an application-level max-message-size > > > > 2) Not Efficient for Streaming Servers (no Message Chunking) > > The application framing in NETCONF and RESTCONF (HTTP) is not > > coupled to any transport protocol. Instead, a sender may emit as > > many message chunks as desired. This is how a streaming server works. > > Content comes from many different sources and it is sent on-the-fly > > in chunks, instead of constructing large replies. > > > > - Application framing allows multiple notifications in one UDP frame > > - Application framing does not need a max-message-size. > > Streaming servers often do not know the size of the data that will > be sent > > in a notification. > > > > Q1) Should proprietary encoding be used to support application-layer > framing > > or should the standard support it? > > > > 3) Protocol Message Encoding for CBOR > > The NETCONF notification message is not modelled in YANG. > > This is an open issue for YANG to CBOR encoding. > > https://github.com/core-wg/yang-cbor/issues/96 > > > > > The "notification" and "eventTime" elements do not have YANG definitions. > > SID assignments for these elements will be needed. > > This draft is the likely place for these SID assignment requests to > > the IESG and IANA. > > > > 4) Subscription-ID Missing from Header > > It is quite possible for one message generator to create > > messages for multiple subscriptions. The subscription-ID > > will be needed to dispatch notifications to subscribers correctly. > > The Observation-Domain-ID is not sufficient. > > > > 5) Private Encoding Option does not seem interoperable > > The "Enc. Descr" field is completely opaque. > > This field could be structured to provide the "ET number space owner" > > e.g, urn [wsp description] > > > > > > Andy > > > > > > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > --00000000000076cfa905d13c02ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I have 2 separate issues= with the protocol design.
Maybe only one is in scope.=C2=A0=C2= =A0

1) ET field
I would like to see more= =C2=A0standards value with the proprietary encoding type field.=C2=A0
=
The standard encoding types are also under-specified.=C2=A0
= (e.g. if ET=3Dxml does the payload contain exactly one XML instance documen= t?
If, so any particular element, or undefined?)

Application Content Format should be more standard.

=
2) Application Framing
This is to support Binary NETCO= NF or RESTCONF (not under development by the WG).
This issue can = be dropped, since the WG does not agree any valid use-cases exist
for reusing the application layer with the application/yang-data+cbor medi= a type.


Andy

On Sat, = Nov 20, 2021 at 9:23 AM <Tho= mas.Graf@swisscom.com> wrote:

Dear Andy an= d Mahesh,

Following th= is thread, wherever it makes sense to add an application message header to = allow multiple notification messages being carried in one single udp-notif message, we need to have th= e full context.

I understood= from section 4.2 of draft-ietf-netconf-notification-messages=

https://datatracker.ietf.org/doc/ht= ml/draft-ietf-netconf-notification-messages#section-4.2

That the int= end of the working group is to support multiple notifications within one no= tification-message. Correct?

=C2=A0

From the dat= a tracker

https://datatracker.ietf.org/doc/draft-iet= f-netconf-notification-messages/history/

I understood= that this draft is currently on-hold until the first transport draft (draf= t-ietf-netconf-udp-notif or draft-ietf-netconf-https-notif) has reached RFC status. Correct?=

If both corr= ect, what is the added value of supporting multiple notification messages w= ithin the notification itself AND supporting multiple notifications at transport within an application f= raming as well?

From a stand= ardization point of view we should avoid duplicity as much as possible. If = it is the intend of the working group to address this with draft-ietf-netconf-notification-messages than I= suggest not to address this in draft draft-ietf-netconf-udp-notif as well. Have a transport agnostic implementation.

=C2=A0=

Best wishes

Thomas=

=C2=A0=

From: netconf <netconf-bounces@ietf.org> On Behalf Of Andy Bierman
Sent: Wednesday, November 17, 2021 8:31 PM
To: Pierre Francois <pierre.francois.ietf@gmail.com>
Cc: Netconf <netconf@ietf.org>
Subject: Re: [netconf] Issues with draft-ietf-netconf-udp-notif-04

=C2=A0

=C2=A0

=C2=A0

On Wed, Nov 17, 2021 at 3:03 AM Pierre Francois <= pierre.= francois.ietf@gmail.com> wrote:

Hello Andy,=C2=A0

=C2=A0

Thanks for the feedback, answers inline.=C2=A0

=C2=A0

Le=C2=A0mar. 16 nov. 2021 =C3=A0=C2=A004:45, Andy Bi= erman <andy@yuma= works.com> a =C3=A9crit=C2=A0:

Hi,

=C2=A0

I am wondering if there implementations of this draf= t already.

IMO there are problems with in that prevent reasonab= le and

optimal implementations.

=C2=A0

There is support of udp-notif publisher in VRP.=C2= =A0

There is a C collector lib for udp-notif in=C2=A0https://github.com/insa-unyte/udp-notif-c-collector= =C2=A0=C2=A0

=C2=A0

=C2=A0

1) Use of UDP as the Application Message Framing<= /u>

UDP is a transport protocol.=C2=A0 Tightly coupling = one

NETCONF notification message to one UDP frame (+ fra= gments)

is not very optimal.

=C2=A0

There is a segmentation option in the protocol, so a= udp notif message is not tightly coupled to a UDP frame.=C2=A0

=C2=A0

But this segmentation is optional to implement.

My point is that application protocols like NETCONF = have their own message framing

which does not exist here because the transport fram= ing is used instead.

=C2=A0

=C2=A0

=C2=A0

1A) wastes space in the UDP frame if the NETCONF not= ification=C2=A0

=C2=A0 =C2=A0 happens to be short

=C2=A0

I don't get it, I'm sorry. To me a UDP heade= r=C2=A0+ small udp-notif header is rather short.

=C2=A0

If I can fit 100 notification messages in 1 UDP fram= e then I save 99% of the redundant headers.

=C2=A0

=C2=A0

=C2=A0

1B) imposes an application-level max-message-size=

=C2=A0

Not with the segmentation option, do we agree?

=C2=A0

=C2=A0

There can be 32767 segments of a max 65535 each: abo= ut 2G of data.

However the segment-size is allowed to be smaller an= d segmentation is completely optional-to-implement.

=C2=A0

Application layer framing allows unlimited message s= ize without any need

to support UDP segmentation at all,

=C2=A0

=C2=A0

=C2=A0

=C2=A0

2) Not Efficient for Streaming Servers (no Message C= hunking)

The application framing in NETCONF and RESTCONF (HTT= P) is not

coupled to any transport protocol. Instead, a sender= may emit as

many message chunks as desired. This is how a stream= ing server works.

Content comes from many different sources and it is = sent on-the-fly

in chunks, instead of constructing large replies.=

=C2=A0

=C2=A0 =C2=A0 - Application framing allows multiple = notifications in one UDP frame

=C2=A0 =C2=A0 - Application framing does not need a = max-message-size.=C2=A0

=C2=A0 =C2=A0 =C2=A0 Streaming servers often do not = know the size of the data that will be sent=C2=A0

=C2=A0 =C2=A0 =C2=A0 in a notification.

=C2=A0

I think we meet these goals. Let me think about this= further.=C2=A0

=C2=A0

=C2=A0

I agree, by ignoring the idea that this protocol pro= vides any normative information

about the application layer protocol in use.=C2=A0 T= his draft should remove any hint

that the application payload is defined in this docu= ment.=C2=A0 It is OK to say

a different RFC (or spec) defines the content for a = particular Encoding Type.

=C2=A0

The "notification" in Figure 1 implies tha= t the payload is one NETCONF notification.

The draft should be clear that there is no structure= to the payload defined in this document.

=C2=A0

=C2=A0

=C2=A0

Q1) Should proprietary encoding be used to support a= pplication-layer framing

=C2=A0 =C2=A0 =C2=A0 =C2=A0or should the standard su= pport it?

=C2=A0

I think we'd need to meet on this or else it wil= l end up with thousands of long emails ;)

=C2=A0

=C2=A0

I think the draft should let other documents define = the exact content expected in the payload.

I am used to application protocols defining specific= message flows. Since this draft does

not do that, it should not attempt to impose any rul= es on the application payload at all.

=C2=A0

=C2=A0

=C2=A0

This is related to application/yang-data+cbor.=C2=A0=

A separate document for the SID assignments can be d= one.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

4) Subscription-ID Missing from Header=

It is quite possible for one message generator to cr= eate

messages for multiple subscriptions.=C2=A0 The subsc= ription-ID

will be needed to dispatch notifications to subscrib= ers correctly.

The Observation-Domain-ID is not sufficient.<= u>

=C2=A0

Same answer as above, we understand obs-domain-id to= be used in the transport to meet load-balancing goals, but thought it woul= d violate layers to place subscription-IDs in the transport itself.<= u>

=C2=A0

=C2=A0

So I will put the Subscription-ID here instead I gue= ss because a common

use-case is to allow a Collector to support subscrip= tions from client applications.

Only datastore subscriptions include a subscription-= id, not event stream notifications.

=C2=A0

=C2=A0

=C2=A0

5) Private Encoding Option does not seem interoperab= le

The "Enc. Descr" field is completely opaqu= e.

=C2=A0

Correct.

=C2=A0

=C2=A0

Then perhaps there is no need for this at all since = it does not

attempt to provide any interoperability?

=C2=A0

=C2=A0

This field could be structured to provide the "= ET number space owner"=C2=A0

e.g, urn [wsp description]

=C2=A0

Mmm it's a valid option. Our opinion was that on= ce you want it interoperable, you should make it standard instead of privat= e.=C2=A0

If the wg thinks we should kinda standardize private= options, I'm personally okay to add that to the draft.=C2=A0=

=C2=A0

Use of structured strings like URNs does not seem li= ke a bad thing that should be discouraged.

The ET field is not interopable=C2=A0if every implem= entation can define their own 4-bit values

and there is no standard way to tell them apart. Per= haps just a domain name if a URN is too much of a burden.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Andy

=C2=A0

Thanks a lot for your comments,=C2=A0<= /p>

=C2=A0=

Pierre.=C2=A0=

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

Hi,

=C2=A0

I am wondering if there implementations of this draf= t already.

IMO there are problems with in that prevent reasonab= le and

optimal implementations.

=C2=A0

1) Use of UDP as the Application Message Framing<= /u>

UDP is a transport protocol.=C2=A0 Tightly coupling = one

NETCONF notification message to one UDP frame (+ fra= gments)

is not very optimal.

=C2=A0

1A) wastes space in the UDP frame if the NETCONF not= ification=C2=A0

=C2=A0 =C2=A0 happens to be short

1B) imposes an application-level max-message-size=

=C2=A0

2) Not Efficient for Streaming Servers (no Message C= hunking)

The application framing in NETCONF and RESTCONF (HTT= P) is not

coupled to any transport protocol. Instead, a sender= may emit as

many message chunks as desired. This is how a stream= ing server works.

Content comes from many different sources and it is = sent on-the-fly

in chunks, instead of constructing large replies.=

=C2=A0

=C2=A0 =C2=A0 - Application framing allows multiple = notifications in one UDP frame

=C2=A0 =C2=A0 - Application framing does not need a = max-message-size.=C2=A0

=C2=A0 =C2=A0 =C2=A0 Streaming servers often do not = know the size of the data that will be sent=C2=A0

=C2=A0 =C2=A0 =C2=A0 in a notification.

=C2=A0

Q1) Should proprietary encoding be used to support a= pplication-layer framing

=C2=A0 =C2=A0 =C2=A0 =C2=A0or should the standard su= pport it?

=C2=A0 =C2=A0

3) Protocol Message Encoding for CBOR<= /p>

The NETCONF notification message is not modelled in = YANG.

This is an open issue for YANG to CBOR encoding.<= /u>

=C2=A0

The "notification" and "eventTime&quo= t; elements do not have YANG definitions.

SID assignments for these elements will be needed.

This draft is the likely place for these SID assignm= ent requests to

the IESG and IANA.

=C2=A0

4) Subscription-ID Missing from Header=

It is quite possible for one message generator to cr= eate

messages for multiple subscriptions.=C2=A0 The subsc= ription-ID

will be needed to dispatch notifications to subscrib= ers correctly.

The Observation-Domain-ID is not sufficient.<= u>

=C2=A0

5) Private Encoding Option does not seem interoperab= le

The "Enc. Descr" field is completely opaqu= e.

This field could be structured to provide the "= ET number space owner"=C2=A0

e.g, urn [wsp description]

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

=C2=A0

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

--00000000000076cfa905d13c02ca-- From nobody Sat Nov 20 10:14:57 2021 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 4741D3A0765 for ; Sat, 20 Nov 2021 10:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, 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 9cgjFbwgnejS for ; Sat, 20 Nov 2021 10:14:50 -0800 (PST) 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 CCC883A067B for ; Sat, 20 Nov 2021 10:14:49 -0800 (PST) Received: by mail.swisscom.com; Sat, 20 Nov 2021 19:14:45 +0100 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_1590486_1929586991.1637432084916" X-Mailer: Totemo_TrustMail_(Notification) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XraskLu3TUrNz7WsAJ+dLE4JhfBgktLa8YP5eJIECr49FiMw10XjHGP/G5UL3R+/E5Yi3vq7yD0pSXbuWJLulnopq0gseAI+7gkj7Y5/3MupeJQPmtVy1yLqPnupl4yiebjMLc2mLSjBjaEOzuRHe3Mj+m/HTF+JXjhtRqJj1St9gXv3lb2HBv19VZVfAdeqZVHI7TMJ/c8lrCkst8wu+dmGu7qUqJ1195q3M5MR/HCRym9EcaK1iK6xyZBNRRlYfh2gYXLNxjXVvYh+ZLKncnWxBu8We3RapLGDAvjtX9frHoayy+MA3Pvpd5Mvuf4Io9CKzV6VswfztaV/QmA/+g== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7BNV5enFS/L5PcGQo28UEgg7yNpj5Axxt3qUbTdWnzk=; b=FyPt0lXukhkEYxED3GNtkcOu89Lxc4eCNdyy+B1HQaPm+RZOfh9g1xOyVD8o1l5aoMDPRcIQzzrLfobge2xcBUUFvAGCOdp8ym7wST+kf4V3h6LtvBFf8+6QXmwO+Upo4/9F27/HU3tELtULq7eYO1HutczvQmaq57HvIIL1TxdwgdWa/O4Zs8vWla8rqwjb1JZzP5/J4fV9dIskypz7OXCmoCs44vWXkXYkc5p98AwBXUB6GRH5yBvbEbOlck6ewQoS58h7kR3wuahldLXkogTPauF/YwXfgk+2wznoMuuSOX72Mzmu+EeRgG5oG24sJ0DrOJnouJa6T9YKJ94waQ== 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] Issues with draft-ietf-netconf-udp-notif-04 Thread-Index: AQHX2px0mTrR0HpnoEGx1KUWYd/Kp6wHkC2AgACN6oCAAgK9AIAClCEg Date: Sat, 20 Nov 2021 18:14:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=swisscom.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8760c4b2-c84c-40bb-84e5-08d9ac519317 x-ms-traffictypediagnostic: ZRAP278MB0094: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: raZvoZWU0qcgwKvi9tpvOBkin4yzgyc23nP363lGzb5QidzAARTxm/W43dRZCWbz8mdqLb/PahSugLFC0B3LrtsaYa/nlaPMM1Tju9ZQkH9Ex076hSx/oWtaduNmnfvSv0v3GiTR40w9P4IBGnNvH5i2Gv+TfvWUy3+JfO4hl/MV/MKgUzVjOTcvEmiaHAbUQJMSiq8fFRHyQTgrJsrUsqLnfYfSK7P1Mti+HeLWnSzYyAPp2FcGpq8YHzVKCXbSXKI01HoDqAGe787tC4gvEo5c8XPWUtKHCzRVY6p5fYtSDJ5zEnZtLUnKYmHP57vhZKh1Ugm/5W8E4fM8ht6GTcpcukfmr2c6MZqFaG++M0HUSMi4sXK8jg4eMK4AGsoPt22Rkl2lhQfALVvAV2V/c5JESMe+7/bWNsq2GB6+/AUQatONolB2n6g25PcEZ/VWJZFfoh/1twfw0wNvU8aOC2OiTKz0m+6Vi8otXObJdIxrEhQ/Fvn8tiKX24DxljV0zsIufjX/Ejq3AICzIvtQm6uUhC+9YpsvpTHn0EC/usOl7AYvpdY/dzdEmFRq6y10XUjWYXBJQQjDg7AgAacnFW5i+Vr0gee798FSHkWPN5qoXEmZ+7+7c5SOjwleF67TCU2igHCdEWVtIoC9wB8FJddfPLk9ENyM2/h6XiSjRWuI3A6F6xTCJvNTeTQ7KuJkC5VwGspCWtyWN4kOsw6gqcTtm3nf3eM+axIiTK2lthyKs+lvuJXmIL3J0xHTN8AgQsG8ACuBSxd9rvGokm5awuIeukH1+5/m9jlsBiFslzI0bLD8SWtg2TFEuCzSITgk x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:ZRAP278MB0176.CHEP278.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(66946007)(110136005)(66556008)(66476007)(64756008)(71200400001)(66446008)(10290500003)(10300500001)(76116006)(5660300002)(966005)(52536014)(316002)(8936002)(86362001)(9686003)(38070700005)(6506007)(7696005)(53546011)(30864003)(38100700002)(55016002)(508600001)(83380400001)(122000001)(4326008)(66574015)(166002)(33656002)(82960400001)(186003)(8676002)(2906002)(26005)(356854002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?P1bEJBFWZ+w8OvioNE4tBlI8OKoyU3D0mu7R2ZLA2i2B4ENOX+qYYC8uxl?= =?iso-8859-1?Q?Xh6UOe/aE5N0m/SmDBFqluDEVQIo7Rbp2GUWnbqdcgpP+SJLikAhZNVWr5?= =?iso-8859-1?Q?biOK9fpKqRBESV0s1nUjR9vwCFkSyqQ/bm6LBv2zHK/+fXOX0BhuPKehAq?= =?iso-8859-1?Q?Hb+/GMC6Y+mT5UuUjycHOtdXreURrmxTtlJ1UHs/s3sH2OjEJSAyatj2b3?= =?iso-8859-1?Q?aVD7ijjusfrdhg/P5tl5N9js4l5Tr3UEC4evGlbOAd/r/7w3nRP73GKDn5?= =?iso-8859-1?Q?dL37OdffVR68D08MyIiy3v3/OKdH+jQg71B0D6z9cj804FooIOCNA/2mux?= =?iso-8859-1?Q?HLofhuLyomCD8UjOdUUwLjF2yWyae9bt5zgurYcqNBUGBdlRb2n4L67uzL?= =?iso-8859-1?Q?einiYrVS1lOh5WY5K087KHP9uktfhxSGw1/gDeWKwO6YxTx6MUGvwv+/xx?= =?iso-8859-1?Q?LGhcBPy1bcEbGNsawrxH9CTq5gLjUGsD8UCgiyfuZz85VMBje037sFHy1l?= =?iso-8859-1?Q?zUsBVAs2fog1Ssn2D360FIOvtmarHg6kFveIltrOm8ILOVBfpLycwHBjaU?= =?iso-8859-1?Q?mdYTLkEA28Fq5xb98x1U54+/IHpgb50DLe5BxLhn9dbr6NHsCkB0m5JN2V?= =?iso-8859-1?Q?CbTCkWYzFU6YK8FFuKV5jacCIKo2FDXWhaqPbovrSuo/3W4WkfIyTaGzBz?= =?iso-8859-1?Q?neDjNJLy3ozS81ARl6qBD36k7OMNOoo0Iucps+F/VojxGcETkio2Unhlcm?= =?iso-8859-1?Q?pTiLTKrjTS0ouyFEhWwfVWXd74BJI1aQwBaq1GWcF9gKe7GKNE23GGv5d9?= =?iso-8859-1?Q?wPlJSo0NoI3GxBIWsstUGOtWrHh/sENC/fSeDro0oDzbr0pL/dX/iaS9YG?= =?iso-8859-1?Q?FdIXkDJW5tdjZxrEclvnr9KShmKSWR8RaXEW65RLvfkJnKFomMB7fe8jB5?= =?iso-8859-1?Q?uSdFOhfBL3QRkQbU2PdS0eNreCPV4VV2rThgjiiRhda1U7UkeQHFZ+8vTx?= =?iso-8859-1?Q?dS8LSfyU1WooXwgWcvk75tBqhnNnymGCRPxYYBRoqjqwuL6M1+S8VlSVc5?= =?iso-8859-1?Q?MzxzndSIX02ptdOOds1mP1TMvY9uSLj6l2LOLWd69S61VDeHgZZQyxJKuV?= =?iso-8859-1?Q?mN8+31R7okDCmV98qnhESH+3N3tOOWAqRBCw3HigG+VzGzdAIu6yazRYIl?= =?iso-8859-1?Q?ljkG5QsL987r/qBsi9IHTRLcyfWaYKsGuasl4BpFE9WbsCX5u44ecrGBSa?= =?iso-8859-1?Q?72zcTy3IscaLdFR/9J96RO4Q7mex2+wxDEdHIaLrg/rFlZ5qx8V2GwVpqk?= =?iso-8859-1?Q?rTKeU6prhvAsYYsVmHnvORVXaJahpNjgmUNQTYiebhy/+qNGq6mN90gfXG?= =?iso-8859-1?Q?wOxasIusF4KMgkEgP7IJWYnH8tTVvByU0BUDPxOmwd9eHLs9msVKu86486?= =?iso-8859-1?Q?E7OOOYovfpUaaRLSd7swIP4mF+Big0DOi1LSNqiZWxWgWI1Pog3gK4sPvA?= =?iso-8859-1?Q?H/3n9itoNouSArTemUHR/XI1PsP/n2Cd16ctyfIDeVBL1IoBi+1RXjfd4z?= =?iso-8859-1?Q?Fo8OgaTBB9xMPDD1IKs4WLsUTzjgUMmINilS3+G7Zi1yhII0QVKPiYxEwa?= =?iso-8859-1?Q?OeiLilg0ZEFH2CP5fiUghwh5HdwfgzfYJ6BCOVRdikgy2Fjnu65o9XMf21?= =?iso-8859-1?Q?+jX9vdw8aVS81OTMgiTLoZdZhoNJ4RGPtp6Ymnr46W7EZgth4h1DR0P7Bo?= =?iso-8859-1?Q?j0yg=3D=3D?= X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: ZRAP278MB0176.CHEP278.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 8760c4b2-c84c-40bb-84e5-08d9ac519317 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2021 18:14:20.8262 (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: 0bis4HRni2WJ0SLqgvujab7r4yCXQ6kxWVBKQtUDMoAfwEYPbcqxptd9dUmN2huVIGGcx0bsAsa7fipLKYo7Gw6UrQ6TAcxdpJrLEe4rsGw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: ZRAP278MB0094 X-OriginatorOrg: swisscom.com X-CFilter-Loop: Reflected X-Trustmail: processed Archived-At: Subject: Re: [netconf] Issues with draft-ietf-netconf-udp-notif-04 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, 20 Nov 2021 18:14:56 -0000 ------=_Part_1590486_1929586991.1637432084916 Content-Type: multipart/alternative; boundary="_000_ZRAP278MB0176053E97CD255B041B96C2899D9ZRAP278MB0176CHEP_" Content-Language: en-US --_000_ZRAP278MB0176053E97CD255B041B96C2899D9ZRAP278MB0176CHEP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Andy, Looking at the list of media types I disagree with your observation. Please= correct me if I am wrong, only a small subset is applicable to YANG push. The possible encodings are currently being defined in both transport drafts https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif#sectio= n-8.3 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-04#secti= on-3.2 However, you are raising a very valid point I noticed that the netconf work= ing group haven't addressed clearly yet. I understood from previous threads= with draft-ietf-netconf-https-notif and draft-ietf-netconf-udp-notif that = multiple times questions were raised which are the valid transport encoding= s for YANG push. For me it is unclear wherever CBOR could be used as encoding in draft-ietf-= netconf-https-notif or not. Wherever draft-ietf-netconf-https-notif is enco= ding agnostic or not. I assume both transport drafts are encoding agnostic.= Therefor we as working group should address the topic, which are the suppo= rted encodings for YANG push at present time, an how in the future when new= encodings are being developed, we address this topic. My suggestion is to keep the initial registries for both drafts equal. Defi= ning JSON, XML and CBOR as the initial encoding. And if in the future new e= ncodings are being added, ensure that both registries, for udp-notif and ht= tps-notif are being updated equally. >From my point of view, we can roughly foresee that YANG push supports never= more than 16 encoding types. However, due to the late YANG pus transport s= tandardization at IETF and already existing non standardized YANG push enco= ding implementations, I understood that private encodings is something we = can't ignore. Therefore it makes sense to support it in the initial version= of the transport documents. Best wishes Thomas From: netconf On Behalf Of Andy Bierman Sent: Friday, November 19, 2021 3:13 AM To: Pierre Francois Cc: Netconf Subject: Re: [netconf] Issues with draft-ietf-netconf-udp-notif-04 Hi, It is unclear why this document needs to reinvent content types using a 4-b= it ET field. There is already a registry of integer mappings for CoAP https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#cont= ent-formats IMO this draft needs to (at least) define a header option for a 16-bit "CF"= field. Implementations SHOULD provide a CF option if none of the standard ET types= apply. One of the 16 standard ET values should mean "See CF option". Andy On Wed, Nov 17, 2021 at 11:31 AM Andy Bierman > wrote: On Wed, Nov 17, 2021 at 3:03 AM Pierre Francois > wrote: Hello Andy, Thanks for the feedback, answers inline. Le mar. 16 nov. 2021 =E0 04:45, Andy Bierman > a =E9crit : Hi, I am wondering if there implementations of this draft already. IMO there are problems with in that prevent reasonable and optimal implementations. There is support of udp-notif publisher in VRP. There is a C collector lib for udp-notif in https://github.com/insa-unyte/u= dp-notif-c-collector 1) Use of UDP as the Application Message Framing UDP is a transport protocol. Tightly coupling one NETCONF notification message to one UDP frame (+ fragments) is not very optimal. There is a segmentation option in the protocol, so a udp notif message is n= ot tightly coupled to a UDP frame. But this segmentation is optional to implement. My point is that application protocols like NETCONF have their own message = framing which does not exist here because the transport framing is used instead. 1A) wastes space in the UDP frame if the NETCONF notification happens to be short I don't get it, I'm sorry. To me a UDP header + small udp-notif header is r= ather short. If I can fit 100 notification messages in 1 UDP frame then I save 99% of th= e redundant headers. 1B) imposes an application-level max-message-size Not with the segmentation option, do we agree? https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif#section-= 4.1 There can be 32767 segments of a max 65535 each: about 2G of data. However the segment-size is allowed to be smaller and segmentation is compl= etely optional-to-implement. Application layer framing allows unlimited message size without any need to support UDP segmentation at all, 2) Not Efficient for Streaming Servers (no Message Chunking) The application framing in NETCONF and RESTCONF (HTTP) is not coupled to any transport protocol. Instead, a sender may emit as many message chunks as desired. This is how a streaming server works. Content comes from many different sources and it is sent on-the-fly in chunks, instead of constructing large replies. - Application framing allows multiple notifications in one UDP frame - Application framing does not need a max-message-size. Streaming servers often do not know the size of the data that will be= sent in a notification. I think we meet these goals. Let me think about this further. I agree, by ignoring the idea that this protocol provides any normative inf= ormation about the application layer protocol in use. This draft should remove any = hint that the application payload is defined in this document. It is OK to say a different RFC (or spec) defines the content for a particular Encoding Typ= e. The "notification" in Figure 1 implies that the payload is one NETCONF noti= fication. The draft should be clear that there is no structure to the payload defined= in this document. Q1) Should proprietary encoding be used to support application-layer framin= g or should the standard support it? I think we'd need to meet on this or else it will end up with thousands of = long emails ;) I think the draft should let other documents define the exact content expec= ted in the payload. I am used to application protocols defining specific message flows. Since t= his draft does not do that, it should not attempt to impose any rules on the application p= ayload at all. 3) Protocol Message Encoding for CBOR The NETCONF notification message is not modelled in YANG. This is an open issue for YANG to CBOR encoding. https://github.com/core-wg/yang-cbor/issues/96 The "notification" and "eventTime" elements do not have YANG definitions. SID assignments for these elements will be needed. This draft is the likely place for these SID assignment requests to the IESG and IANA. Shouldn't these be transport agnostic? I don't see why this would be bound = to udp-notif only and not, say, https-notif. This is related to application/yang-data+cbor. A separate document for the SID assignments can be done. 4) Subscription-ID Missing from Header It is quite possible for one message generator to create messages for multiple subscriptions. The subscription-ID will be needed to dispatch notifications to subscribers correctly. The Observation-Domain-ID is not sufficient. Same answer as above, we understand obs-domain-id to be used in the transpo= rt to meet load-balancing goals, but thought it would violate layers to pla= ce subscription-IDs in the transport itself. So I will put the Subscription-ID here instead I guess because a common use-case is to allow a Collector to support subscriptions from client appli= cations. Only datastore subscriptions include a subscription-id, not event stream no= tifications. 5) Private Encoding Option does not seem interoperable The "Enc. Descr" field is completely opaque. Correct. Then perhaps there is no need for this at all since it does not attempt to provide any interoperability? This field could be structured to provide the "ET number space owner" e.g, urn [wsp description] Mmm it's a valid option. Our opinion was that once you want it interoperabl= e, you should make it standard instead of private. If the wg thinks we should kinda standardize private options, I'm personall= y okay to add that to the draft. Use of structured strings like URNs does not seem like a bad thing that sho= uld be discouraged. The ET field is not interopable if every implementation can define their ow= n 4-bit values and there is no standard way to tell them apart. Perhaps just a domain name= if a URN is too much of a burden. Andy Thanks a lot for your comments, Pierre. Andy Le mar. 16 nov. 2021 =E0 04:45, Andy Bierman > a =E9crit : Hi, I am wondering if there implementations of this draft already. IMO there are problems with in that prevent reasonable and optimal implementations. 1) Use of UDP as the Application Message Framing UDP is a transport protocol. Tightly coupling one NETCONF notification message to one UDP frame (+ fragments) is not very optimal. 1A) wastes space in the UDP frame if the NETCONF notification happens to be short 1B) imposes an application-level max-message-size 2) Not Efficient for Streaming Servers (no Message Chunking) The application framing in NETCONF and RESTCONF (HTTP) is not coupled to any transport protocol. Instead, a sender may emit as many message chunks as desired. This is how a streaming server works. Content comes from many different sources and it is sent on-the-fly in chunks, instead of constructing large replies. - Application framing allows multiple notifications in one UDP frame - Application framing does not need a max-message-size. Streaming servers often do not know the size of the data that will be= sent in a notification. Q1) Should proprietary encoding be used to support application-layer framin= g or should the standard support it? 3) Protocol Message Encoding for CBOR The NETCONF notification message is not modelled in YANG. This is an open issue for YANG to CBOR encoding. https://github.com/core-wg/yang-cbor/issues/96 The "notification" and "eventTime" elements do not have YANG definitions. SID assignments for these elements will be needed. This draft is the likely place for these SID assignment requests to the IESG and IANA. 4) Subscription-ID Missing from Header It is quite possible for one message generator to create messages for multiple subscriptions. The subscription-ID will be needed to dispatch notifications to subscribers correctly. The Observation-Domain-ID is not sufficient. 5) Private Encoding Option does not seem interoperable The "Enc. Descr" field is completely opaque. This field could be structured to provide the "ET number space owner" e.g, urn [wsp description] Andy _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_ZRAP278MB0176053E97CD255B041B96C2899D9ZRAP278MB0176CHEP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Andy,

 

Looking at the list of media types I disagree with your observati= on. Please correct me if I am wrong, only a small subset is applicable to YANG push.

 

The possible encodings are currently being defined in both transp= ort drafts

https://datatracker.ietf.org/doc/html/draft-iet= f-netconf-https-notif#section-8.3

https://datatracker.ietf.org/doc/html/draft-ie= tf-netconf-udp-notif-04#section-3.2

 

However, you are raising =
a very valid point I noticed that the netconf working group haven't address=
ed clearly yet. I understood from previous threads with draft-ietf-netconf-=
https-notif and draft-ietf-netconf-udp=
-notif that multiple times questions were raised which are th=
e valid transport encodings for YANG push.
 
For me it is unclear wher=
ever CBOR could be used as encoding in draft-ietf-netconf-https-notif or no=
t. Wherever draft-ietf-netconf-https-notif is encoding agnostic or not. I a=
ssume both transport drafts are encoding agnostic. Therefor we as working g=
roup should address the topic, which are the supported encodings for YANG p=
ush at present time, an how in the future when new encodings are being deve=
loped, we address this topic.
 <=
/pre>

My suggestion is to keep =
the initial registries for both drafts equal. Defining JSON, XML and CBOR a=
s the initial encoding. And if in the future new encodings are being added,=
 ensure that both registries, for udp-notif and https-notif are being updat=
ed equally.


 <=
/pre>

From my point of view, we=
 can roughly foresee that YANG push supports never more than 16 encoding ty=
pes. However, due to the late YANG pus transport standardization at IETF an=
d already existing non standardized YANG push encoding implementations, &nb=
sp;I understood that private encodings is something we can't ignore. Theref=
ore it makes sense to support it in the initial version of the transport do=
cuments.


 <=
/pre>

Best wishes


Thomas


 




From: netconf <netconf-bounces@ietf.org>
On Behalf Of Andy Bierman

Sent: Friday, November 19, 2021 3:13 AM

To: Pierre Francois <pierre.francois.ietf@gmail.com>

Cc: Netconf <netconf@ietf.org>

Subject: Re: [netconf] Issues with draft-ietf-netconf-udp-notif-04




 



 











 




 






On Wed, Nov 17, 2021 at 3:03 AM Pierre Francois <=
pierre.=
francois.ietf@gmail.com> wrote:
















Hello Andy, 




 






Thanks for the feedback, answers inline. <=
/o:p>










 






Le mar. 16 nov. 2021 =E0 04:45, Andy Bierm=
an <andy@yumawor=
ks.com> a =E9crit :








Hi,




 






I am wondering if there implementations of this draf=
t already.






IMO there are problems with in that prevent reasonab=
le and






optimal implementations.










 






There is support of udp-notif publisher in VRP. =
;






There is a C collector lib for udp-notif in https://github.com/insa-unyte/udp-notif-c-collector =
 






 










 






1) Use of UDP as the Application Message Framing






UDP is a transport protocol.  Tightly coupling =
one






NETCONF notification message to one UDP frame (+ fra=
gments)






is not very optimal.










 






There is a segmentation option in the protocol, so a=
 udp notif message is not tightly coupled to a UDP frame. <=
/p>













 






But this segmentation is optional to implement.=







My point is that application protocols like NETCONF =
have their own message framing






which does not exist here because the transport fram=
ing is used instead.






 














 










 






1A) wastes space in the UDP frame if the NETCONF not=
ification 






    happens to be short










 






I don't get it, I'm sorry. To me a UDP header +=
 small udp-notif header is rather short.














 






If I can fit 100 notification messages in 1 UDP fram=
e then I save 99% of the redundant headers.






 






 














 








1B) imposes an application-level max-message-size








 






Not with the segmentation option, do we agree?<=
/o:p>














 







 






There can be 32767 segments of a max 65535 each: abo=
ut 2G of data.






However the segment-size is allowed to be smaller an=
d segmentation is completely optional-to-implement.






 






Application layer framing allows unlimited message s=
ize without any need






to support UDP segmentation at all,






 






 














 










 






2) Not Efficient for Streaming Servers (no Message C=
hunking)






The application framing in NETCONF and RESTCONF (HTT=
P) is not






coupled to any transport protocol. Instead, a sender=
 may emit as






many message chunks as desired. This is how a stream=
ing server works.






Content comes from many different sources and it is =
sent on-the-fly






in chunks, instead of constructing large replies.






 






    - Application framing allows multiple =
notifications in one UDP frame






    - Application framing does not need a =
max-message-size. 






      Streaming servers often do not =
know the size of the data that will be sent 






      in a notification.









 






I think we meet these goals. Let me think about this=
 further. 














 






 






I agree, by ignoring the idea that this protocol pro=
vides any normative information






about the application layer protocol in use.  T=
his draft should remove any hint






that the application payload is defined in this docu=
ment.  It is OK to say






a different RFC (or spec) defines the content for a =
particular Encoding Type.






 






The "notification" in Figure 1 implies tha=
t the payload is one NETCONF notification.






The draft should be clear that there is no structure=
 to the payload defined in this document.






 














 










 






Q1) Should proprietary encoding be used to support a=
pplication-layer framing






       or should the standard su=
pport it?










 






I think we'd need to meet on this or else it will en=
d up with thousands of long emails ;)














 






 






I think the draft should let other documents define =
the exact content expected in the payload.






I am used to application protocols defining specific=
 message flows. Since this draft does






not do that, it should not attempt to impose any rul=
es on the application payload at all.






 






 














 










   






3) Protocol Message Encoding for CBOR






The NETCONF notification message is not modelled in =
YANG.






This is an open issue for YANG to CBOR encoding.







 






The "notification" and "eventTime&quo=
t; elements do not have YANG definitions.






SID assignments for these elements will be needed.






This draft is the likely place for these SID assignm=
ent requests to






the IESG and IANA.










 






Shouldn't these be transport agnostic? I don't see w=
hy this would be bound to udp-notif only and not, say, https-notif.














 






This is related to application/yang-data+cbor. =







A separate document for the SID assignments can be d=
one.






 






 














 










 






4) Subscription-ID Missing from Header





It is quite possible for one message generator to cr=
eate






messages for multiple subscriptions.  The subsc=
ription-ID






will be needed to dispatch notifications to subscrib=
ers correctly.






The Observation-Domain-ID is not sufficient.










 






Same answer as above, we understand obs-domain-id to=
 be used in the transport to meet load-balancing goals, but thought it woul=
d violate layers to place subscription-IDs in the transport itself.














 






 






So I will put the Subscription-ID here instead I gue=
ss because a common






use-case is to allow a Collector to support subscrip=
tions from client applications.






Only datastore subscriptions include a subscription-=
id, not event stream notifications.






 














 










 






5) Private Encoding Option does not seem interoperab=
le












The "Enc. Descr" field is completely opaqu=
e.








 






Correct.














 






 






Then perhaps there is no need for this at all since =
it does not






attempt to provide any interoperability?<=
/p>





 














 










This field could be structured to provide the "=
ET number space owner" 






e.g, urn [wsp description]










 






Mmm it's a valid option. Our opinion was that once y=
ou want it interoperable, you should make it standard instead of private.&n=
bsp;






If the wg thinks we should kinda standardize private=
 options, I'm personally okay to add that to the draft. 













 






Use of structured strings like URNs does not seem li=
ke a bad thing that should be discouraged.






The ET field is not interopable if every implem=
entation can define their own 4-bit values






and there is no standard way to tell them apart. Per=
haps just a domain name if a URN is too much of a burden.






 






 














 










 






Andy










 






Thanks a lot for your comments, 






 






Pierre. 










 






 






Andy






 






 










Le mar. 16 nov. 2021 =E0 04:45, Andy Bierm=
an <andy@yumawor=
ks.com> a =E9crit :








Hi,




 






I am wondering if there implementations of this draf=
t already.






IMO there are problems with in that prevent reasonab=
le and






optimal implementations.






 






1) Use of UDP as the Application Message Framing






UDP is a transport protocol.  Tightly coupling =
one






NETCONF notification message to one UDP frame (+ fra=
gments)






is not very optimal.






 






1A) wastes space in the UDP frame if the NETCONF not=
ification 






    happens to be short






1B) imposes an application-level max-message-size






 






2) Not Efficient for Streaming Servers (no Message C=
hunking)






The application framing in NETCONF and RESTCONF (HTT=
P) is not






coupled to any transport protocol. Instead, a sender=
 may emit as






many message chunks as desired. This is how a stream=
ing server works.






Content comes from many different sources and it is =
sent on-the-fly






in chunks, instead of constructing large replies.






 






    - Application framing allows multiple =
notifications in one UDP frame






    - Application framing does not need a =
max-message-size. 






      Streaming servers often do not =
know the size of the data that will be sent 






      in a notification.





 






Q1) Should proprietary encoding be used to support a=
pplication-layer framing






       or should the standard su=
pport it?






   






3) Protocol Message Encoding for CBOR






The NETCONF notification message is not modelled in =
YANG.






This is an open issue for YANG to CBOR encoding.







 






The "notification" and "eventTime&quo=
t; elements do not have YANG definitions.






SID assignments for these elements will be needed.






This draft is the likely place for these SID assignm=
ent requests to






the IESG and IANA.






 






4) Subscription-ID Missing from Header





It is quite possible for one message generator to cr=
eate






messages for multiple subscriptions.  The subsc=
ription-ID






will be needed to dispatch notifications to subscrib=
ers correctly.






The Observation-Domain-ID is not sufficient.






 






5) Private Encoding Option does not seem interoperab=
le






The "Enc. Descr" field is completely opaqu=
e.






This field could be structured to provide the "=
ET number space owner" 






e.g, urn [wsp description]






 






 






Andy






 






 






 






_______________________________________________

netconf mailing list

netconf@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/netconf=
--_000_ZRAP278MB0176053E97CD255B041B96C2899D9ZRAP278MB0176CHEP_-- ------=_Part_1590486_1929586991.1637432084916 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 HuzkCrsqTOsJYDnOymLYLm4AADGCA7swggO3AgEBMG4wVjELMAkGA1UEBhMCQ0gxFTATBgNVBAoT DFN3aXNzU2lnbiBBRzEwMC4GA1UEAxMnU3dpc3NTaWduIFBlcnNvbmFsIFNpbHZlciBDQSAyMDE0 IC0gRzIyAhR4i6Eec1b72YkIjJKOk4r62lxMbzANBglghkgBZQMEAgEFAKCCAh4wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjExMTIwMTgxNDQ0WjAtBgkqhkiG9w0B CTQxIDAeMA0GCWCGSAFlAwQCAQUAoQ0GCSqGSIb3DQEBCwUAMC8GCSqGSIb3DQEJBDEiBCCgyiqn aUQ4Xd3cHYD3danGECJdJt3n/rg+gRJSl2FItTB9BgkrBgEEAYI3EAQxcDBuMFYxCzAJBgNVBAYT AkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBT aWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wfwYLKoZIhvcNAQkQAgsx cKBuMFYxCzAJBgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNz U2lnbiBQZXJzb25hbCBTaWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8w gYMGCSqGSIb3DQEJDzF2MHQwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwCwYJYIZI AWUDBAIEMAsGCWCGSAFlAwQCBzANBgkqhkiG9w0BAQsFAASCAQBZflKFwZIn3ItB4A98JTNSqM7E +pokRDAMjP/qaGw2rpEk7jrG/gqJPsIdTLXCzZTRFGkygpAocEhIl87yPHVgUr5//BGakMemzdda iDp/biI5sK0w7IUjAnLma28uAs9IeLT3EhlBxmVRfyci7QwZf+3idTnoFcWeDY5Q4MjdN26qMU8A kAKnKYZCuTSf7Uj01n8FEEJ8qJ0PDzEYPtkuboHlRTuEaOBJgdKc7SfaL6YfijcPcGqU8+uHI32V npCd+erf5xkBNBflz4VCc8wU1T5DEr2jB3duovtuMxotCNZsr1xcATdhEWc14EJYjtqpUyiJ+pc4 8lU9J3bQFd/SAAAAAAAA ------=_Part_1590486_1929586991.1637432084916-- From nobody Sat Nov 20 11:49:20 2021 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 21DB73A0844 for ; Sat, 20 Nov 2021 11:49:19 -0800 (PST) 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.20210112.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 mPiLUNM04LBN for ; Sat, 20 Nov 2021 11:49:14 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 743523A0842 for ; Sat, 20 Nov 2021 11:49:13 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id u3so59842739lfl.2 for ; Sat, 20 Nov 2021 11:49:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FBZSNJNrrstazbka7gRaOENhpQ9RB/DeWZ0+whxIygg=; b=RWKJRlTOdvfPTFFAguGEwbyre3tvkBsjxb4gAR0ZL9PROsf8ZOZOs3ExdB4RkyagJn aIWAVNfYBO2irqlWYIk5/Z10GM7S5ZCoUkQX9ri0KVfIIKcis6yfsGB0IJ+Ht8NIY+pS uixZDtvqfaCEmSunMfo4fupEaakU7JM8OuNPFa/8KgQj4//YpldBpOSvVIY2xPBBVbtr ClAi1A+6N32QEBypbEIHMVRG0brIf9hNO0FsepbadsfmdBuJbZEYtkID8K3ldeETFC6R w8ppFV0vL70jhZ9n/6YLEgqDKsn8qbGdIrGxKjJ1hz/OBk5z96fd5zuTFIYV4q+1YOmO mYKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FBZSNJNrrstazbka7gRaOENhpQ9RB/DeWZ0+whxIygg=; b=jYDrSQ/udJqDxZhMqE1Nu66Dj0dJKAX5JYjOYG2iysv9ZDXhHtaTttO9CMIr0T/fIH xU1lTV0Dyv3I3v7ROLSn8zdjXrdGv1q4b/iNq2tUDjCD62eW8lYKhd6du90NMEHFA9nA 25JLg9wUHMqFCnZpFIrR+a4caRlX/AdGs+AQ3dku9KujIivvflPeT5MwBYHzKGgK7qHG zJPut6BrKeT5/zHhQ5usH8g0giZ8Xsj5GwTpyrSDnlSmE2jMnamnDhpMY6TTjboiT6Sg S0F2Yy6dz0wvxSkI6ItW2yYr8suJCBmDrSq2ydLi+je+R86QD7vvc0iRDzIpWeUlNSXi CaFA== X-Gm-Message-State: AOAM533hRVq22xKsggwwrGtRQl/PBk4+YaI/KF4BDX46YY7EfRc6fF9+ u/xtGPU9HdQ5UtTqHPnD2oCzdOgwCClqF8vj6KFCzg== X-Google-Smtp-Source: ABdhPJwVo6PF11F3Ey0CeoDKAkZHzQSf34EJlup5O8KTIuUi/5RSxjcNzkhkU/dOzuMtz9gqxVsArX/TuxoAqFP9wNo= X-Received: by 2002:a2e:7618:: with SMTP id r24mr36726257ljc.144.1637437750303; Sat, 20 Nov 2021 11:49:10 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Sat, 20 Nov 2021 11:48:59 -0800 Message-ID: To: Thomas.Graf@swisscom.com Cc: Pierre Francois , Netconf Content-Type: multipart/alternative; boundary="00000000000072f13e05d13dafb3" Archived-At: Subject: Re: [netconf] Issues with draft-ietf-netconf-udp-notif-04 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, 20 Nov 2021 19:49:19 -0000 --00000000000072f13e05d13dafb3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 20, 2021 at 10:14 AM wrote: > Hi Andy, > > > > Looking at the list of media types I disagree with your observation. > Please correct me if I am wrong, only a small subset is applicable to YAN= G > push. > > > > The possible encodings are currently being defined in both transport draf= ts > > > https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif#sect= ion-8.3 > > > https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-04#sec= tion-3.2 > > > It is not clear if this is supposed to be an application protocol or not. Supposedly, the header cannot have a subscription-id because the application layer defines that. But this document defines the encoding type of the application payload, called "the notification message" in 3.1 Perhaps 3 complete examples showing an XML, JSON, and CBOR encoding of "the notification message" would help clarify the intended usage of these standard ET values. Andy However, you are raising a very valid point I noticed that the netconf working group haven't addressed clearly yet. I understood from previous threads with draft-ietf-netconf-https-notif and draft-ietf-netconf-udp-notif that multiple times questions were raised which are the valid transport encodings for YANG push. > > > > For me it is unclear wherever CBOR could be used as encoding in draft-iet= f-netconf-https-notif or not. Wherever draft-ietf-netconf-https-notif is en= coding agnostic or not. I assume both transport drafts are encoding agnosti= c. Therefor we as working group should address the topic, which are the sup= ported encodings for YANG push at present time, an how in the future when n= ew encodings are being developed, we address this topic. > > > > My suggestion is to keep the initial registries for both drafts equal. De= fining JSON, XML and CBOR as the initial encoding. And if in the future new= encodings are being added, ensure that both registries, for udp-notif and = https-notif are being updated equally. > > > > From my point of view, we can roughly foresee that YANG push supports nev= er more than 16 encoding types. However, due to the late YANG pus transport= standardization at IETF and already existing non standardized YANG push en= coding implementations, I understood that private encodings is something w= e can't ignore. Therefore it makes sense to support it in the initial versi= on of the transport documents. > > > > Best wishes > > Thomas > > > > *From:* netconf *On Behalf Of *Andy Bierman > *Sent:* Friday, November 19, 2021 3:13 AM > *To:* Pierre Francois > *Cc:* Netconf > *Subject:* Re: [netconf] Issues with draft-ietf-netconf-udp-notif-04 > > > > Hi, > > > > It is unclear why this document needs to reinvent content types using a > 4-bit ET field. > > > > There is already a registry of integer mappings for CoAP > > > https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#co= ntent-formats > > > > > IMO this draft needs to (at least) define a header option for a 16-bit > "CF" field. > > Implementations SHOULD provide a CF option if none of the standard ET > types apply. > > One of the 16 standard ET values should mean "See CF option". > > > > > > Andy > > > > > > > > > > > > On Wed, Nov 17, 2021 at 11:31 AM Andy Bierman wrote: > > > > > > On Wed, Nov 17, 2021 at 3:03 AM Pierre Francois < > pierre.francois.ietf@gmail.com> wrote: > > Hello Andy, > > > > Thanks for the feedback, answers inline. > > > > Le mar. 16 nov. 2021 =C3=A0 04:45, Andy Bierman a = =C3=A9crit : > > Hi, > > > > I am wondering if there implementations of this draft already. > > IMO there are problems with in that prevent reasonable and > > optimal implementations. > > > > There is support of udp-notif publisher in VRP. > > There is a C collector lib for udp-notif in > https://github.com/insa-unyte/udp-notif-c-collector > > > > > > > > 1) Use of UDP as the Application Message Framing > > UDP is a transport protocol. Tightly coupling one > > NETCONF notification message to one UDP frame (+ fragments) > > is not very optimal. > > > > There is a segmentation option in the protocol, so a udp notif message is > not tightly coupled to a UDP frame. > > > > But this segmentation is optional to implement. > > My point is that application protocols like NETCONF have their own messag= e > framing > > which does not exist here because the transport framing is used instead. > > > > > > > > 1A) wastes space in the UDP frame if the NETCONF notification > > happens to be short > > > > I don't get it, I'm sorry. To me a UDP header + small udp-notif header is > rather short. > > > > If I can fit 100 notification messages in 1 UDP frame then I save 99% of > the redundant headers. > > > > > > > > 1B) imposes an application-level max-message-size > > > > Not with the segmentation option, do we agree? > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif#sectio= n-4.1 > > > > > There can be 32767 segments of a max 65535 each: about 2G of data. > > However the segment-size is allowed to be smaller and segmentation is > completely optional-to-implement. > > > > Application layer framing allows unlimited message size without any need > > to support UDP segmentation at all, > > > > > > > > > > 2) Not Efficient for Streaming Servers (no Message Chunking) > > The application framing in NETCONF and RESTCONF (HTTP) is not > > coupled to any transport protocol. Instead, a sender may emit as > > many message chunks as desired. This is how a streaming server works. > > Content comes from many different sources and it is sent on-the-fly > > in chunks, instead of constructing large replies. > > > > - Application framing allows multiple notifications in one UDP frame > > - Application framing does not need a max-message-size. > > Streaming servers often do not know the size of the data that will > be sent > > in a notification. > > > > I think we meet these goals. Let me think about this further. > > > > > > I agree, by ignoring the idea that this protocol provides any normative > information > > about the application layer protocol in use. This draft should remove an= y > hint > > that the application payload is defined in this document. It is OK to sa= y > > a different RFC (or spec) defines the content for a particular Encoding > Type. > > > > The "notification" in Figure 1 implies that the payload is one NETCONF > notification. > > The draft should be clear that there is no structure to the payload > defined in this document. > > > > > > > > Q1) Should proprietary encoding be used to support application-layer > framing > > or should the standard support it? > > > > I think we'd need to meet on this or else it will end up with thousands o= f > long emails ;) > > > > > > I think the draft should let other documents define the exact content > expected in the payload. > > I am used to application protocols defining specific message flows. Since > this draft does > > not do that, it should not attempt to impose any rules on the application > payload at all. > > > > > > > > > > 3) Protocol Message Encoding for CBOR > > The NETCONF notification message is not modelled in YANG. > > This is an open issue for YANG to CBOR encoding. > > https://github.com/core-wg/yang-cbor/issues/96 > > > > > The "notification" and "eventTime" elements do not have YANG definitions. > > SID assignments for these elements will be needed. > > This draft is the likely place for these SID assignment requests to > > the IESG and IANA. > > > > Shouldn't these be transport agnostic? I don't see why this would be boun= d > to udp-notif only and not, say, https-notif. > > > > This is related to application/yang-data+cbor. > > A separate document for the SID assignments can be done. > > > > > > > > > > 4) Subscription-ID Missing from Header > > It is quite possible for one message generator to create > > messages for multiple subscriptions. The subscription-ID > > will be needed to dispatch notifications to subscribers correctly. > > The Observation-Domain-ID is not sufficient. > > > > Same answer as above, we understand obs-domain-id to be used in the > transport to meet load-balancing goals, but thought it would violate laye= rs > to place subscription-IDs in the transport itself. > > > > > > So I will put the Subscription-ID here instead I guess because a common > > use-case is to allow a Collector to support subscriptions from client > applications. > > Only datastore subscriptions include a subscription-id, not event stream > notifications. > > > > > > > > 5) Private Encoding Option does not seem interoperable > > The "Enc. Descr" field is completely opaque. > > > > Correct. > > > > > > Then perhaps there is no need for this at all since it does not > > attempt to provide any interoperability? > > > > > > This field could be structured to provide the "ET number space owner" > > e.g, urn [wsp description] > > > > Mmm it's a valid option. Our opinion was that once you want it > interoperable, you should make it standard instead of private. > > If the wg thinks we should kinda standardize private options, I'm > personally okay to add that to the draft. > > > > Use of structured strings like URNs does not seem like a bad thing that > should be discouraged. > > The ET field is not interopable if every implementation can define their > own 4-bit values > > and there is no standard way to tell them apart. Perhaps just a domain > name if a URN is too much of a burden. > > > > > > > > > > Andy > > > > Thanks a lot for your comments, > > > > Pierre. > > > > > > Andy > > > > > > Le mar. 16 nov. 2021 =C3=A0 04:45, Andy Bierman a = =C3=A9crit : > > Hi, > > > > I am wondering if there implementations of this draft already. > > IMO there are problems with in that prevent reasonable and > > optimal implementations. > > > > 1) Use of UDP as the Application Message Framing > > UDP is a transport protocol. Tightly coupling one > > NETCONF notification message to one UDP frame (+ fragments) > > is not very optimal. > > > > 1A) wastes space in the UDP frame if the NETCONF notification > > happens to be short > > 1B) imposes an application-level max-message-size > > > > 2) Not Efficient for Streaming Servers (no Message Chunking) > > The application framing in NETCONF and RESTCONF (HTTP) is not > > coupled to any transport protocol. Instead, a sender may emit as > > many message chunks as desired. This is how a streaming server works. > > Content comes from many different sources and it is sent on-the-fly > > in chunks, instead of constructing large replies. > > > > - Application framing allows multiple notifications in one UDP frame > > - Application framing does not need a max-message-size. > > Streaming servers often do not know the size of the data that will > be sent > > in a notification. > > > > Q1) Should proprietary encoding be used to support application-layer > framing > > or should the standard support it? > > > > 3) Protocol Message Encoding for CBOR > > The NETCONF notification message is not modelled in YANG. > > This is an open issue for YANG to CBOR encoding. > > https://github.com/core-wg/yang-cbor/issues/96 > > > > > The "notification" and "eventTime" elements do not have YANG definitions. > > SID assignments for these elements will be needed. > > This draft is the likely place for these SID assignment requests to > > the IESG and IANA. > > > > 4) Subscription-ID Missing from Header > > It is quite possible for one message generator to create > > messages for multiple subscriptions. The subscription-ID > > will be needed to dispatch notifications to subscribers correctly. > > The Observation-Domain-ID is not sufficient. > > > > 5) Private Encoding Option does not seem interoperable > > The "Enc. Descr" field is completely opaque. > > This field could be structured to provide the "ET number space owner" > > e.g, urn [wsp description] > > > > > > Andy > > > > > > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > --00000000000072f13e05d13dafb3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Nov 20, 2021 at 10:14 AM <= Thomas.Graf@swisscom.com>= ; wrote:

Hi Andy,<= /u>

=C2= =A0

Looking at t= he list of media types I disagree with your observation. Please correct me = if I am wrong, only a small subset is applicable to YANG push.

=C2= =A0

The possible= encodings are currently being defined in both transport drafts

https://datatracker.ietf.org/doc/html/draft-ietf-ne= tconf-https-notif#section-8.3

https://datatracker.ietf.org/doc/html/draft-ietf-n= etconf-udp-notif-04#section-3.2

=C2= =A0



<= br>

It is not clear if this is supposed to be an a= pplication protocol or not.
Supposedly, the=C2=A0header cannot ha= ve a subscription-id because the application layer defines that.
= But this document defines the encoding type of the application payload, cal= led "the notification message" in 3.1

Pe= rhaps 3 complete examples showing an XML, JSON, and CBOR encoding of "= the notification message"
would help clarify the intended us= age of these standard ET values.


An= dy

However, you are raising a very valid point I=
 noticed that the netconf working group haven't addressed clearly yet. =
I understood from previous threads with draft-ietf-netconf-https-notif and =
draft-ietf-netconf-udp-not=
if that multiple times questions were raised which are the=
 valid transport encodings for YANG push.
=C2=A0
For me it is unclear wherever CBOR could be u=
sed as encoding in draft-ietf-netconf-https-notif or not. Wherever draft-ie=
tf-netconf-https-notif is encoding agnostic or not. I assume both transport=
 drafts are encoding agnostic. Therefor we as working group should address =
the topic, which are the supported encodings for YANG push at present time,=
 an how in the future when new encodings are being developed, we address th=
is topic.
=C2=A0
My suggestion is to keep the initial registri=
es for both drafts equal. Defining JSON, XML and CBOR as the initial encodi=
ng. And if in the future new encodings are being added, ensure that both re=
gistries, for udp-notif and https-notif are being updated equally.
=C2=A0
From my point of view, we can roughly foresee=
 that YANG push supports never more than 16 encoding types. However, due to=
 the late YANG pus transport standardization at IETF and already existing n=
on standardized YANG push encoding implementations, =C2=A0I understood that=
 private encodings is something we can't ignore. Therefore it makes sen=
se to support it in the initial version of the transport documents.<=
u>
=C2=A0

Best wishes<= u>

Thomas

=C2= =A0

From: netconf <netconf-bounces@ietf.org> On Behalf Of Andy Bierman
Sent: Friday, November 19, 2021 3:13 AM
To: Pierre Francois <pierre.francois.ietf@gmail.com>
Cc: Netconf <netconf@ietf.org>
Subject: Re: [netconf] Issues with draft-ietf-netconf-udp-notif-04

=C2=A0

Hi,

=C2=A0

It is unclear why this document needs to reinvent co= ntent types using a 4-bit ET field.

=C2=A0

There is already a registry of integer mappings for = CoAP

=C2=A0

IMO this draft needs to (at least) define a header o= ption for a 16-bit "CF" field.

Implementations SHOULD provide a CF option if none o= f the standard ET types apply.

One of the 16 standard ET values should mean "S= ee CF option".

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Wed, Nov 17, 2021 at 11:31 AM Andy Bierman <andy@yumaworks.com> wrote:

=C2=A0

=C2=A0

On Wed, Nov 17, 2021 at 3:03 AM Pierre Francois <= pierre.= francois.ietf@gmail.com> wrote:

Hello Andy,=C2=A0

=C2=A0

Thanks for the feedback, answers inline.=C2=A0

=C2=A0

Le=C2=A0mar. 16 nov. 2021 =C3=A0=C2=A004:45, Andy Bi= erman <andy@yuma= works.com> a =C3=A9crit=C2=A0:

Hi,

=C2=A0

I am wondering if there implementations of this draf= t already.

IMO there are problems with in that prevent reasonab= le and

optimal implementations.

=C2=A0

There is support of udp-notif publisher in VRP.=C2= =A0

There is a C collector lib for udp-notif in=C2=A0https://github.com/insa-unyte/udp-notif-c-collector=C2=A0= =C2=A0

=C2=A0

=C2=A0

1) Use of UDP as the Application Message Framing<= /u>

UDP is a transport protocol.=C2=A0 Tightly coupling = one

NETCONF notification message to one UDP frame (+ fra= gments)

is not very optimal.

=C2=A0

There is a segmentation option in the protocol, so a= udp notif message is not tightly coupled to a UDP frame.=C2=A0

=C2=A0

But this segmentation is optional to implement.

My point is that application protocols like NETCONF = have their own message framing

which does not exist here because the transport fram= ing is used instead.

=C2=A0

=C2=A0

=C2=A0

1A) wastes space in the UDP frame if the NETCONF not= ification=C2=A0

=C2=A0 =C2=A0 happens to be short

=C2=A0

I don't get it, I'm sorry. To me a UDP heade= r=C2=A0+ small udp-notif header is rather short.

=C2=A0

If I can fit 100 notification messages in 1 UDP fram= e then I save 99% of the redundant headers.

=C2=A0

=C2=A0

=C2=A0

1B) imposes an application-level max-message-size=

=C2=A0

Not with the segmentation option, do we agree?

=C2=A0

=C2=A0

There can be 32767 segments of a max 65535 each: abo= ut 2G of data.

However the segment-size is allowed to be smaller an= d segmentation is completely optional-to-implement.

=C2=A0

Application layer framing allows unlimited message s= ize without any need

to support UDP segmentation at all,

=C2=A0

=C2=A0

=C2=A0

=C2=A0

2) Not Efficient for Streaming Servers (no Message C= hunking)

The application framing in NETCONF and RESTCONF (HTT= P) is not

coupled to any transport protocol. Instead, a sender= may emit as

many message chunks as desired. This is how a stream= ing server works.

Content comes from many different sources and it is = sent on-the-fly

in chunks, instead of constructing large replies.=

=C2=A0

=C2=A0 =C2=A0 - Application framing allows multiple = notifications in one UDP frame

=C2=A0 =C2=A0 - Application framing does not need a = max-message-size.=C2=A0

=C2=A0 =C2=A0 =C2=A0 Streaming servers often do not = know the size of the data that will be sent=C2=A0

=C2=A0 =C2=A0 =C2=A0 in a notification.

=C2=A0

I think we meet these goals. Let me think about this= further.=C2=A0

=C2=A0

=C2=A0

I agree, by ignoring the idea that this protocol pro= vides any normative information

about the application layer protocol in use.=C2=A0 T= his draft should remove any hint

that the application payload is defined in this docu= ment.=C2=A0 It is OK to say

a different RFC (or spec) defines the content for a = particular Encoding Type.

=C2=A0

The "notification" in Figure 1 implies tha= t the payload is one NETCONF notification.

The draft should be clear that there is no structure= to the payload defined in this document.

=C2=A0

=C2=A0

=C2=A0

Q1) Should proprietary encoding be used to support a= pplication-layer framing

=C2=A0 =C2=A0 =C2=A0 =C2=A0or should the standard su= pport it?

=C2=A0

I think we'd need to meet on this or else it wil= l end up with thousands of long emails ;)

=C2=A0

=C2=A0

I think the draft should let other documents define = the exact content expected in the payload.

I am used to application protocols defining specific= message flows. Since this draft does

not do that, it should not attempt to impose any rul= es on the application payload at all.

=C2=A0

=C2=A0

=C2=A0

=C2=A0 =C2=A0

3) Protocol Message Encoding for CBOR<= /p>

The NETCONF notification message is not modelled in = YANG.

This is an open issue for YANG to CBOR encoding.<= /u>

=C2=A0

The "notification" and "eventTime&quo= t; elements do not have YANG definitions.

SID assignments for these elements will be needed.

This draft is the likely place for these SID assignm= ent requests to

the IESG and IANA.

=C2=A0

Shouldn't these be transport agnostic? I don'= ;t see why this would be bound to udp-notif only and not, say, https-notif.=

=C2=A0

This is related to application/yang-data+cbor.=C2=A0=

A separate document for the SID assignments can be d= one.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

4) Subscription-ID Missing from Header=

It is quite possible for one message generator to cr= eate

messages for multiple subscriptions.=C2=A0 The subsc= ription-ID

will be needed to dispatch notifications to subscrib= ers correctly.

The Observation-Domain-ID is not sufficient.<= u>

=C2=A0

Same answer as above, we understand obs-domain-id to= be used in the transport to meet load-balancing goals, but thought it woul= d violate layers to place subscription-IDs in the transport itself.<= u>

=C2=A0

=C2=A0

So I will put the Subscription-ID here instead I gue= ss because a common

use-case is to allow a Collector to support subscrip= tions from client applications.

Only datastore subscriptions include a subscription-= id, not event stream notifications.

=C2=A0

=C2=A0

=C2=A0

5) Private Encoding Option does not seem interoperab= le

The "Enc. Descr" field is completely opaqu= e.

=C2=A0

Correct.

=C2=A0

=C2=A0

Then perhaps there is no need for this at all since = it does not

attempt to provide any interoperability?

=C2=A0

=C2=A0

This field could be structured to provide the "= ET number space owner"=C2=A0

e.g, urn [wsp description]

=C2=A0

Mmm it's a valid option. Our opinion was that on= ce you want it interoperable, you should make it standard instead of privat= e.=C2=A0

If the wg thinks we should kinda standardize private= options, I'm personally okay to add that to the draft.=C2=A0=

=C2=A0

Use of structured strings like URNs does not seem li= ke a bad thing that should be discouraged.

The ET field is not interopable=C2=A0if every implem= entation can define their own 4-bit values

and there is no standard way to tell them apart. Per= haps just a domain name if a URN is too much of a burden.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Andy

=C2=A0

Thanks a lot for your comments,=C2=A0<= /p>

=C2=A0=

Pierre.=C2=A0=

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

Le=C2=A0mar. 16 nov. 2021 =C3=A0=C2=A004:45, Andy Bi= erman <andy@yuma= works.com> a =C3=A9crit=C2=A0:

Hi,

=C2=A0

I am wondering if there implementations of this draf= t already.

IMO there are problems with in that prevent reasonab= le and

optimal implementations.

=C2=A0

1) Use of UDP as the Application Message Framing<= /u>

UDP is a transport protocol.=C2=A0 Tightly coupling = one

NETCONF notification message to one UDP frame (+ fra= gments)

is not very optimal.

=C2=A0

1A) wastes space in the UDP frame if the NETCONF not= ification=C2=A0

=C2=A0 =C2=A0 happens to be short

1B) imposes an application-level max-message-size=

=C2=A0

2) Not Efficient for Streaming Servers (no Message C= hunking)

The application framing in NETCONF and RESTCONF (HTT= P) is not

coupled to any transport protocol. Instead, a sender= may emit as

many message chunks as desired. This is how a stream= ing server works.

Content comes from many different sources and it is = sent on-the-fly

in chunks, instead of constructing large replies.=

=C2=A0

=C2=A0 =C2=A0 - Application framing allows multiple = notifications in one UDP frame

=C2=A0 =C2=A0 - Application framing does not need a = max-message-size.=C2=A0

=C2=A0 =C2=A0 =C2=A0 Streaming servers often do not = know the size of the data that will be sent=C2=A0

=C2=A0 =C2=A0 =C2=A0 in a notification.

=C2=A0

Q1) Should proprietary encoding be used to support a= pplication-layer framing

=C2=A0 =C2=A0 =C2=A0 =C2=A0or should the standard su= pport it?

=C2=A0 =C2=A0

3) Protocol Message Encoding for CBOR<= /p>

The NETCONF notification message is not modelled in = YANG.

This is an open issue for YANG to CBOR encoding.<= /u>

=C2=A0

The "notification" and "eventTime&quo= t; elements do not have YANG definitions.

SID assignments for these elements will be needed.

This draft is the likely place for these SID assignm= ent requests to

the IESG and IANA.

=C2=A0

4) Subscription-ID Missing from Header=

It is quite possible for one message generator to cr= eate

messages for multiple subscriptions.=C2=A0 The subsc= ription-ID

will be needed to dispatch notifications to subscrib= ers correctly.

The Observation-Domain-ID is not sufficient.<= u>

=C2=A0

5) Private Encoding Option does not seem interoperab= le

The "Enc. Descr" field is completely opaqu= e.

This field could be structured to provide the "= ET number space owner"=C2=A0

e.g, urn [wsp description]

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

=C2=A0

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

--00000000000072f13e05d13dafb3-- From nobody Mon Nov 22 08:34:03 2021 Return-Path: <0100017d487f0f15-c299535d-2006-4dde-9b36-4799849666c0-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 B1F683A0C6C; Mon, 22 Nov 2021 08:33:55 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 (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 8qKkFxxsss-p; Mon, 22 Nov 2021 08:33:51 -0800 (PST) Received: from a48-95.smtp-out.amazonses.com (a48-95.smtp-out.amazonses.com [54.240.48.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A87B23A0C71; Mon, 22 Nov 2021 08:33:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1637598826; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=0sXWtjir8XE/acR5XO8nHClREV4ceedWqeUAtg1O4V4=; b=DN64RSNnelvrwYP9CmE1NcAAKWq4D+ytmdz+9Kcic71thjcyNB0NLuwEx8y4fixE E2a1N2vaNbtRAn55ZUVDhHyVt4MMMwvxlLOY8pW0WsPyFWhx9IpVyfsaDRF6N/qCZpB B/bIOlNZSa8Z95yhffgkao66HW4cWmM0soZqBnqE= From: Kent Watsen Message-ID: <0100017d487f0f15-c299535d-2006-4dde-9b36-4799849666c0-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7BBC051B-E0D2-458D-9AEC-D62DCE6D944D" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Mon, 22 Nov 2021 16:33:46 +0000 In-Reply-To: <163733688535.10662.12846915795187697217@ietfa.amsl.com> Cc: ops-dir@ietf.org, last-call@ietf.org, draft-ietf-netconf-sztp-csr.all@ietf.org, "netconf@ietf.org" To: Dan Romascanu References: <163733688535.10662.12846915795187697217@ietfa.amsl.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.11.22-54.240.48.95 Archived-At: Subject: Re: [netconf] Opsdir last call review of draft-ietf-netconf-sztp-csr-11 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, 22 Nov 2021 16:33:56 -0000 --Apple-Mail=_7BBC051B-E0D2-458D-9AEC-D62DCE6D944D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Dan, Thank you for your review. Please see below for responses to your = comments. Kent > On Nov 19, 2021, at 10:48 AM, Dan Romascanu via Datatracker = wrote: >=20 > Reviewer: Dan Romascanu > Review result: Ready >=20 > This document is Ready from an OPS-DIR perspective. >=20 > This document extends the "get-bootstrapping-data" RPC defined in RFC = 8572 to > include an optional certificate signing request (CSR), enabling a = bootstrapping > device to additionally obtain an identity certificate (e.g., an = LDevID, from > IEEE 802.1AR) as part of the "onboarding information" response = provided in the > RPC-reply. It proides the ability to provision an identity certificate = that is > purpose-built for a production environment during the bootstrapping = process > removing the reliance on the manufacturer CA, and enabling the = bootstraped > device to join the production environment with an appropriate = identity. It's a > clear and useful document, which needs to be read and understood by = operators > of IOT networks using the respective technologies. >=20 >> =46rom an operator perspective, the most relevant sections are 2 and = 3. Section=20 > 2 refers to the ietf-sztp-csr module. It includes a Data Model = Overview as > well as hints about how the augmentation and structure defined by the > "ietf-sztp-csr" module are used, including two additional tree = diagrams showing > the nodes placed where they are used. I found the example usage in = Section 2.2 > very useful. Section 2.3 contains the YANG module. Section 3 contains = the > description of the data model and the ietf-ztp-types YANG module. >=20 > I have one question related to the type of certificates that are = supported. > Section 3.2 includes the following: >=20 > The terms 'IDevID' and 'LDevID' are used herein to > mean 'initial device identifier' and 'local device > identifer'. These terms are defined consistent with > the IEEE 802.1AR specification, though there is no > requirement that a ZTP-client's identity certificate > conform to IEEE 802.1AR. >=20 > If my understanding is correct, the mechanism described in this = document is > generic. However, all the examples and the definitions in the modules = refer to > certification conform to IEEE 802.1AR. This is some kind of = contradiction. > Maybe some text speaking about other types of certificates should be = added. Or > maybe the scope should be defined more narrow to refer to IEEE = 802.1AR. In any > case it seems to me that Std-802.1AR-2018 needs to be a Normative = Reference - > one cannot understand this document without reading and understanding = the IEEE > standards. Your understanding is correct, the document regards device identity = certificates in a generic X.509v3 sense. Actually, a careful reading = of 802.1AR shows that it, effectively, says the same, placing very few = (if any) restrictions on the contents of the X.509v3 certificate. =20 That said, 802.1AR did define the terms =E2=80=9CIDevID=E2=80=9D and = =E2=80=9CLDevID=E2=80=9D, which have become fairly well known in the = industry. Thusly, this document attempts to capitalize on that = familiarity w/o stating that identity certificates MUST be = 802.1AR-compliant. Throughout the body of the document, the text consistently uses = phraseology such as =E2=80=9Can initial device identity certificate = (e.g., an IDevID from 802.1AR)=E2=80=9D that simultaneously doesn't bind = implementations to a particular identity-certificate definition while = remaining highly understandable.=20 However, the text in the YANG module uses a different approach, out of a = sense if brevity, by using the terms IDevID/LDevID directly (w/o any = parenthetical reference to 802.1AR), along with the = terminology-disclaimer you copy/pasted above. Whilst the document appears technically accurate/unambiguous, the issue = seems to warrant a remedy, as the SecDir-review made a similar comment. Options: 1) Define formal terms for IDeviD and LDevID in Section 1.2 = (Terminology) stating that 1) they are acronyms for =E2=80=9Cinitial/local= device identifier=E2=80=9D and 2) they are consistent with the same = terms in 802.1AR but do not imply that any implementation must adhere to = 802.1AR. This update could be coupled with the removal of all the = parenthetical phraseology throughout the body of the document. 2) Modify the YANG module to 1) also use the parenthetical phraseology = (greatly expanding the verbosity of the =E2=80=9Cdescription=E2=80=9D = statement text) and 2) remove the quoted terminology-disclaimer at the = top of the YANG module. 3) Do nothing. Which option seems best? Does anyone have. preference? Kent // co-author --Apple-Mail=_7BBC051B-E0D2-458D-9AEC-D62DCE6D944D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Dan,

Thank you for = your review.  Please see below for responses to your = comments.

Kent


On Nov = 19, 2021, at 10:48 AM, Dan Romascanu via Datatracker <noreply@ietf.org> = wrote:

Reviewer: Dan Romascanu
Review result: Ready

This document is Ready from an OPS-DIR =  perspective.

This document extends = the "get-bootstrapping-data" RPC defined in RFC 8572 to
include an optional certificate signing request (CSR), = enabling a bootstrapping
device to additionally obtain an = identity certificate (e.g., an LDevID, from
IEEE 802.1AR) = as part of the "onboarding information" response provided in the
RPC-reply. It proides the ability to provision an identity = certificate that is
purpose-built for a production = environment during the bootstrapping process
removing the = reliance on the manufacturer CA, and enabling the bootstraped
device to join the production environment with an appropriate = identity. It's a
clear and useful document, which needs to = be read and understood by operators
of IOT networks using = the respective technologies.

=46rom an operator perspective, the most = relevant sections are 2 and 3. Section
2 = refers to the ietf-sztp-csr  module. It includes a Data Model = Overview as
well as hints about how the augmentation and = structure defined by the
"ietf-sztp-csr" module are used, = including two additional tree diagrams showing
the nodes = placed where they are used. I found the example usage in Section 2.2
very useful. Section 2.3 contains the YANG module. Section 3 = contains the
description of the data model and the = ietf-ztp-types YANG module.

I have one = question related to the type of certificates that are supported.
Section 3.2 includes the following:

       The terms 'IDevID' = and 'LDevID' are used herein to
=        mean 'initial device = identifier' and 'local device
=        identifer'.  These terms = are defined consistent with
=        the IEEE 802.1AR = specification, though there is no
=        requirement that a = ZTP-client's identity certificate
=        conform to IEEE 802.1AR.

If my understanding is correct, the mechanism = described in this document is
generic. However, all the = examples and the definitions in the modules refer to
certification conform to IEEE 802.1AR. This is some kind of = contradiction.
Maybe some text speaking about other types = of certificates should be added. Or
maybe the scope should = be defined more narrow to refer to IEEE 802.1AR. In any
case= it seems to me that Std-802.1AR-2018 needs to be a Normative Reference = -
one cannot understand this document without reading and = understanding the IEEE
standards.

Your = understanding is correct, the document regards device identity = certificates in a generic X.509v3 sense.   = Actually, a careful reading of 802.1AR shows that it, effectively, says = the same, placing very few  (if any) restrictions on the contents = of the X.509v3 certificate.  

That said, 802.1AR did define the terms = =E2=80=9CIDevID=E2=80=9D and =E2=80=9CLDevID=E2=80=9D, which have become = fairly well known in the industry.  Thusly, this document attempts = to capitalize on that familiarity w/o stating that identity certificates = MUST be 802.1AR-compliant.

Throughout = the body of the document, the text consistently uses phraseology such as = =E2=80=9Can initial device identity certificate (e.g., an IDevID from = 802.1AR)=E2=80=9D that simultaneously doesn't bind implementations to a = particular identity-certificate definition while remaining highly = understandable. 

However, the = text in the YANG module uses a different approach, out of a sense if = brevity, by using the terms IDevID/LDevID directly (w/o any = parenthetical reference to 802.1AR), along with the = terminology-disclaimer you copy/pasted above.

Whilst the document appears technically = accurate/unambiguous, the issue seems to warrant a remedy, as = the SecDir-review made a similar comment.

Options:

1) = Define formal terms for IDeviD and LDevID in Section 1.2 (Terminology) = stating that 1) they are acronyms for =E2=80=9Cinitial/local device = identifier=E2=80=9D and 2) they are consistent with the same terms in = 802.1AR but do not imply that any implementation must adhere to 802.1AR. =  This update could be coupled with the removal of all the = parenthetical phraseology throughout the body of the = document.

2) Modify the YANG = module to 1) also use the parenthetical phraseology (greatly expanding the verbosity of = the =E2=80=9Cdescription=E2=80=9D statement text) and 2) remove the = quoted terminology-disclaimer at the top of the YANG module.

3) Do nothing.


Which option seems best? =  Does anyone have. preference?


Kent // = co-author




= --Apple-Mail=_7BBC051B-E0D2-458D-9AEC-D62DCE6D944D-- From nobody Mon Nov 22 13:49:52 2021 Return-Path: <0100017d49a045e3-d1919799-0247-4fb5-abe6-d0c661f80f6a-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 DDC673A0819; Mon, 22 Nov 2021 13:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 4pR1OGsNytdV; Mon, 22 Nov 2021 13:49:42 -0800 (PST) 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 A9F633A081C; Mon, 22 Nov 2021 13:49:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1637617780; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=xR2c0SAkwv5ugufBQMUOL/qm7vShhzAyYhkKaPvXi94=; b=Af54RFfDU/5o7dnG/djhyqJw4CfrLbDpLF7GtoQSxq8ElCAt1ZEgg2aeKk13EFnv Tp+Kl6StD1+tDtsuLn1sXD5W/3raLIKLOV8J3mbQceiJkf8yo2oLe2/4SKWmVrAvgYi rEjhB5JaYvpV3WuUviO1mtVWAE4pVg+a2/WNC/Yk= From: Kent Watsen Message-ID: <0100017d49a045e3-d1919799-0247-4fb5-abe6-d0c661f80f6a-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_947C588E-6924-4A94-8069-A4B51A5B50A5" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Mon, 22 Nov 2021 21:49:40 +0000 In-Reply-To: <163717559932.18384.2156774121641934785@ietfa.amsl.com> Cc: secdir@ietf.org, draft-ietf-netconf-sztp-csr.all@ietf.org, last-call@ietf.org, "netconf@ietf.org" To: Yaron Sheffer References: <163717559932.18384.2156774121641934785@ietfa.amsl.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.11.22-54.240.8.33 Archived-At: Subject: Re: [netconf] Secdir last call review of draft-ietf-netconf-sztp-csr-11 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, 22 Nov 2021 21:49:47 -0000 --Apple-Mail=_947C588E-6924-4A94-8069-A4B51A5B50A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Yaron, Thank you for your valuable comments. My co-authors and I have the = following responses to your comments. > On Nov 17, 2021, at 1:59 PM, Yaron Sheffer via Datatracker = wrote: >=20 > Reviewer: Yaron Sheffer > Review result: Has Issues >=20 > This draft defines a mechanism for a device, when it first starts, to = generate > a CSR to get itself provisioned with one or more certificates it needs = to > identify itself during its normal operation. >=20 > * I was confused that the document starts out describing a generic = cert request > mechanism. Then deep into the YANG modules, it turns out that there is = guidance > (only?) for very specific types of certs, namely LDevID and IDevID. = And the > choice is non-orthogonal: it is unclear what is the guidance for other = certs > when using CMC and CMP, and conversely, whether these two certs can be > generated with a PKCS#10 CSR. We updated the YANG module to greatly remove references to = IDevID/LDevID. Specifically: 1) s/IDevID/initial device identity certificate/g 2) s/LDevID/local device identity certificate/g 3) manually rewrap lines to col 69 as required 4) removed the terminology-disclaimer block at top The diff is here: = https://github.com/netconf-wg/sztp-csr/commit/ac35f96eec96528dddf5798d528d= 9874a85c604b = Good? > * I suggest adding a Security Considerations section about the need = for strong > randomness, which is often unavailable to small embedded devices at = the early > stages of provisioning. I wish we were more successful with:=20 > = https://datatracker.ietf.org/doc/html/draft-sheffer-dhc-initial-random-00 OLD: It is RECOMMENDED that a new private key is generated for each CSR described in this document. NEW: It is RECOMMENDED that a new private key is generated for each CSR described in this document. This private key MUST be generated using a quality random source. = The use of inadequate pseudo-random number generators (PRNGs) to generate private keys can result in little or no security. An = attacker may find it much easier to reproduce the PRNG environment that produced the private key, searching the resulting small set of possibilities, = rather than brute force searching the whole private key space. The = generation of quality random numbers is difficult. BCP 106 [RFC4086] offers important guidance in this area. and we added an Informational reference to RFC 4086. Good now? > * Negotiation (?) of the CSR format and supported algorithms is = unclear in Sec. > 2.2: is it the client that provides the values it supports and the = server picks > one? Alternatively, is the list conveyed by the server in the = error-info and so > the client knows exactly what is supported? IOW, why include these = values at > all in error-info? Section 2.1 states the sequence of exchanges, but we went ahead and = added more context to the examples for additional clarity. The diff is = here: = https://github.com/netconf-wg/sztp-csr/commit/7ed4f5b1daee539dc9071061e4d4= 27e843467d02 = Better? > * It is not clear from Sec. 2.2 how exactly the client is supposed to = associate > one of possibly multiple received certificates to the CSR it just sent = out. > Surely it is not expected to grep for the string "Newly-Generated"? There doesn=E2=80=99t have to be any logic on the client to detect the = signed certificate or, for that matter, to ensure that the server sent = one at all. The point of the bootstrap process is to *configure* the = SZTP-client, and the client's only post-update logic is to =E2=80=9Crun = as configured=E2=80=9D, whatever that might be. That said, it wouldn=E2=80=99t be hard for a client to, e.g., search a = =E2=80=9Ckeystore" mechanism for a key having the key used in the CSR = and then search certificates associated with that key for that cert = having the matching attributes (e.g., the =E2=80=9CSubject=E2=80=9D = attribute) as in the CSR. Makes sense? [No update to the draft was made to address this comment] > * 2.3: the description of "error-info" still does not specify if the = server > should list all CSR format and algorithms it supports. Section 2.1 indicates that the client=E2=80=99s message lists all of the = key-algorithms and csr-formats it supports and the server=E2=80=99s = message merely selects the specific algorithm/format it wishes the = client use. This comment is nearly identical to one of your earlier = comments, for which we added more context around the examples. Good = enough? =20 > * Is there really need to support 3 different CSR formats? Yes and, FWIW, the PKI world has even more formats; we actually = restricted them to just those that are most widely implemented. > * Where does the client indicate which cert is wants to receive based = on this > CSR, e.g. "this CSR is for a LDevID"? Is this information embedded in = the CSR > itself? The CSR is always for an LDevID. It can never be for an IDevID, which = can (effectively) only be generated/installed by the vendor during the = device=E2=80=99s manufacturing process.=20 Makes sense? [No update to the draft was made to address this comment] > * Is RFC 2986 (published Nov. 2000) the best reference for an > AlgorithmIdentifier? Is there no IANA registry we could reference = instead? There is not an IANA registry for AlgorithmIdentifiers. RFC 2986 is the = reference for the PKCS#10 CSR. [No update to the draft was made to address this comment] > * When talking about algorithm matching, I suggest changing "It is an = error > if..." into normative text, "The recipient MUST reject...". OLD: It is an error if the 'AlgorithmIdentifier' field contained inside the 'SubjectPublicKeyInfo' field does not match the algorithm identified by the 'selected-algorithm' node."; NEW: If the 'AlgorithmIdentifier' field contained inside the certificate 'SubjectPublicKeyInfo' field does not match the algorithm identified by the 'selected-algorithm' node, then the client MUST reject the certificate and raise an error."; Good? > * "Details for how to generate a new private key and associate a new = identity > certificate are outside the scope of this document." - This is rather > disappointing, since we just RECOMMENDED to regenerate certs = periodically (and > given that IOT devices often lack HSMs). Understood, but key-generation is indeed outside the scope of this = document. [No update to the draft was made to address this comment] Thanks again, Kent (and Sean and Russ) --Apple-Mail=_947C588E-6924-4A94-8069-A4B51A5B50A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Yaron,

Thank you for = your valuable comments.  My co-authors and I have the = following
responses to your comments.



On Nov = 17, 2021, at 1:59 PM, Yaron Sheffer via Datatracker <noreply@ietf.org> = wrote:

Reviewer: Yaron Sheffer
Review result: Has = Issues

This draft defines a mechanism for a = device, when it first starts, to generate
a CSR to get = itself provisioned with one or more certificates it needs to
identify itself during its normal operation.

* I was confused that the document starts out describing a = generic cert request
mechanism. Then deep into the YANG = modules, it turns out that there is guidance
(only?) for = very specific types of certs, namely LDevID and IDevID. And the
choice is non-orthogonal: it is unclear what is the guidance = for other certs
when using CMC and CMP, and conversely, = whether these two certs can be
generated with a PKCS#10 = CSR.

We = updated the YANG module to greatly remove references to = IDevID/LDevID.

Specifically:
1) = s/IDevID/initial device identity certificate/g
= 2) s/LDevID/local device identity = certificate/g
3) manually rewrap lines to col = 69 as required
4) removed the terminology-disclaimer block at = top


Good?


* I suggest adding a Security Considerations section about = the need for strong
randomness, which is often unavailable = to small embedded devices at the early
stages of = provisioning. I wish we were more successful with:
https://datatracker.ietf.org/doc/html/draft-sheffer-dhc-initial= -random-00

OLD:

    It = is RECOMMENDED that a new private key is generated for each CSR
    described in this document.

NEW:

    It is = RECOMMENDED that a new private key is generated for each CSR
    described in this document.

    This private key MUST be generated using a = quality random source. The
    use of inadequate = pseudo-random number generators (PRNGs) to
    = generate private keys can result in little or no security.  An = attacker may
    find it much easier to = reproduce the PRNG environment that produced
    = the private key, searching the resulting small set of possibilities, = rather
    than brute force searching the whole = private key space.  The generation
    of = quality random numbers is difficult.  BCP 106 [RFC4086] offers
    important guidance in this area.

and we added an Informational = reference to RFC 4086.

Good = now?


* Negotiation = (?) of the CSR format and supported algorithms is unclear in Sec.
2.2: is it the client that provides the values it supports = and the server picks
one? Alternatively, is the list = conveyed by the server in the error-info and so
the client = knows exactly what is supported? IOW, why include these values at
all in error-info?

Section= 2.1 states the sequence of exchanges, but we went ahead and added more = context to the examples for additional clarity.  The diff is = here: https://github.com/netconf-wg/sztp-csr/commit/7ed4f5b1daee539dc= 9071061e4d427e843467d02

Better?


* It is not clear from Sec. 2.2 how exactly the client is = supposed to associate
one of possibly multiple received = certificates to the CSR it just sent out.
Surely it is not = expected to grep for the string "Newly-Generated"?

There = doesn=E2=80=99t have to be any logic on the client to detect = the signed certificate or, for that matter, to ensure that the = server sent one at all.  The point  of = the bootstrap process is to *configure* the = SZTP-client, and the client's only post-update logic is to =E2=80=9Crun = as configured=E2=80=9D, whatever that might be.

That said, it wouldn=E2=80=99t be hard for a = client to, e.g., search a =E2=80=9Ckeystore" mechanism for a key having = the key used in the CSR and then search certificates associated = with that key for that cert having the matching attributes = (e.g., the =E2=80=9CSubject=E2=80=9D attribute) as in the = CSR.

Makes sense?   [No update = to the draft was made to address this comment]


* 2.3: the description of "error-info" still = does not specify if the server
should list all CSR format = and algorithms it supports.


Section 2.1 indicates that the client=E2=80=99s = message lists all of the key-algorithms and csr-formats it supports = and the server=E2=80=99s message merely selects the specific = algorithm/format it wishes the client use.   This comment is nearly = identical to one of your earlier comments, for which we added more = context around the examples.  Good enough?  


* Is there really need to = support 3 different CSR formats?

Yes = and, FWIW, the PKI world has even more formats; we actually restricted = them to just those that are most widely implemented.


* Where does the client indicate which cert = is wants to receive based on this
CSR, e.g. "this CSR is = for a LDevID"? Is this information embedded in the CSR
itself?

The CSR is always for an LDevID.  It can = never be for an IDevID, which can (effectively) only be = generated/installed by the vendor during the device=E2=80=99s = manufacturing process. 

Makes sense? =   [No update to the draft was made to address this = comment]


* Is RFC 2986 (published Nov. 2000) the best reference for = an
AlgorithmIdentifier? Is there no IANA registry we could = reference instead?

There is not an IANA registry for AlgorithmIdentifiers. =  RFC 2986 is the reference for the PKCS#10 CSR.

[No update to the draft was made to address = this comment]



* When talking about = algorithm matching, I suggest changing "It is an error
if..." into normative text, "The recipient MUST = reject...".

OLD:

  =        It is an error if the 'AlgorithmIdentifier' = field
         contained inside = the 'SubjectPublicKeyInfo' field
      =    does not match the algorithm identified by the
         'selected-algorithm' = node.";

NEW:

         If the = 'AlgorithmIdentifier' field contained inside the
  =        certificate 'SubjectPublicKeyInfo' field does = not match
         the algorithm = identified by the 'selected-algorithm' node,
    =      then the client MUST reject the certificate and = raise an
        =  error.";

Good?



* "Details for how to generate a new private key and = associate a new identity
certificate are outside the scope = of this document." - This is rather
disappointing, since = we just RECOMMENDED to regenerate certs periodically (and
given that IOT devices often lack HSMs).

Understood, = but key-generation is indeed outside the scope of this = document.

[No = update to the draft was made to address this comment]



Thanks = again,
Kent (and Sean and = Russ)



= --Apple-Mail=_947C588E-6924-4A94-8069-A4B51A5B50A5-- From nobody Tue Nov 23 01:52:18 2021 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 BB9903A0C47; Tue, 23 Nov 2021 01:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 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_NONE=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=hfd/3R6g; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ipIWfBCp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpWCPbtoAVa0; Tue, 23 Nov 2021 01:52:12 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B7EC3A0890; Tue, 23 Nov 2021 01:52:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27928; q=dns/txt; s=iport; t=1637661131; x=1638870731; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aYIMWYIbTyU6ak2kFtNXriOnUsAajA8EPIfARsUVBQg=; b=hfd/3R6gpB4RsBLNBlNxlQeAqGpkDAa3QHSs8rej/PSwT2dY/5ybc7sr nxH90dCFbsRE5O87Ldk7HBOnTfhTvxaojWj+F4xeftmyYCbfiihlkgKHe XmkuPK437sQ189CLeg2rQFJpo044MatK3rde8IhOeBnUwq6rNYkfv2B+q 0=; IronPort-PHdr: =?us-ascii?q?A9a23=3AY8XfxxCalYqUpST57kzDUyQVaBdPi9zP1kY95?= =?us-ascii?q?pkmjudIdaKut9TnMVfE7PpgxFnOQc3A6v1ChuaX1sKoWWEJ7Zub9nxXdptKW?= =?us-ascii?q?kwJjMwMlFkmB8iIQUTwMP/taXk8G8JPHF9o9n22Kw5bAsH7MlbTuXa1qzUVH?= =?us-ascii?q?0aXCA=3D=3D?= IronPort-Data: =?us-ascii?q?A9a23=3AfYHrIqoYZQIwiqlJ4buk0ybXHCBeBmKQZxIvg?= =?us-ascii?q?KrLsJaIsI4StFCztgarIBnUb/jcMTOnfNxyb4q18hkHvMCEzIVqTwNpr302E?= =?us-ascii?q?y0Q8ePIVI+TRqvS04x+DSFioHqKZKzyU/GYRCwPZiKa9kjF3oTJ9yEmjPjRH?= =?us-ascii?q?OGkUoYoBwgoLeNaYHZ54f5cs7ZRbr5A2bBVMivV0T/Ai5S31GyNg1aYBlkpB?= =?us-ascii?q?5er83uDihhdVAQw5TTSbdgT1LPXeuJ84Jg3fcldJFOgKmVY83LTegrN8F251?= =?us-ascii?q?juxExYFENiplPPwdVcHB+eUNgmVgX0QUK+n6vRAjnVtieBga7xNMgEO1m/hc?= =?us-ascii?q?9NZkL2hsbSqVgYtIqrKsO8cSBJfVSp5OMWq/ZeWfyfi4JbIkRyun3zEhq8G4?= =?us-ascii?q?FsNFYsV5u1wB29m9PEEJnYKdB/rr+6sybynD+hhmspmKsT3N4QZtDR73y3BS?= =?us-ascii?q?P09W9bKR6Hi5NJE0nE3nM8mNfLXfNZcYjNraDzBbgFBfFANB/oWm/+zw3X+a?= =?us-ascii?q?RVZpU6b460t7AD7wBZ21bH2O9P9ddmDRMETlUGdzkrF8mLlKg4TKMeSz3yD/?= =?us-ascii?q?27EuwNltUsXQ6oIH7G+s/VtmlDWnyoYCQYdUh2wpvzRt6J3YPoHQ2R8x8bkh?= =?us-ascii?q?fJaGJSXc+TA?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AESZfRKPPkYHusMBcT23155DYdb4zR+YMi2?= =?us-ascii?q?TDiHoRdfUFSKKlfp6V88jzjSWE9wr4WBkb6Le90dq7MA3hHP9OkMcs1NKZPD?= =?us-ascii?q?UO11HYV72KgbGSpgEIXheOitK1tp0QMpSWaueAd2SS5PySiGLTfrpQo6jkzE?= =?us-ascii?q?nrv5ai854Hd3ANV0gU1XYANu/tKDwOeOApP+tcKLOsou584xawc3Ueacq2Ql?= =?us-ascii?q?MfWfLYmtHNnJX6JTYbGh8O8mC1/HOVwY+/NyLd8gYVUjtJz7tn23PCiRbF6q?= =?us-ascii?q?KqtOz+4gPA1lXU849dlLLau5h+7Y23+4oowwfX+0KVjbdaKvq/VfcO0aeSAW?= =?us-ascii?q?MR4ZzxStEbTp1OAj3qDzmISFDWqnjdOX4Vmg/fIBmj8CDeSQiTfkNmNyKH7r?= =?us-ascii?q?gpKCcxonBQz+1UweZF2XmUuIFQCg6FlCPh58LQXxUvjUasp2E++NRjwkC3fL?= =?us-ascii?q?FuI4O5l7Zvtn+90a1wax7S+cQiCq1jHcvc7PFZfReTaG3YpHBmxJipUm4oFh?= =?us-ascii?q?mLT0AesojNugIm00xR3g8d3ogSj30A/JUyR91N4PnFKL1hkPVLQtUNZaxwCe?= =?us-ascii?q?8dSY+8C3DLQxjLLGWOSG6XWJ0vKjbIsdr68b817OaldNgBy4Yzgo3IVBdCuW?= =?us-ascii?q?s7ayvVeIWzNV1wg1nwqUmGLEHQI/Bllu5EU+fHNcjW2AW4OSQTr/c=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CcBgCBuJxh/5hdJa1RCR4BAQsSDII?= =?us-ascii?q?OC4EhMVEHd1o3MYRHg0cDhTmFDoMCA4sEkAmBLoElA1QLAQEBDQEBQQQBAYU?= =?us-ascii?q?EAheCWgIlNAkOAQIEAQEBEgEBBQEBAQIBBgSBCROFaA2GQgEBAQEDEhEKEwE?= =?us-ascii?q?BNwEPAgEIEQQBASgDAgICHxEUCQgCBAENBQgaglCBflcDLwGjAgGBOgKKH3q?= =?us-ascii?q?BMYEBgggBAQYEBIUKDQuCNQmBOoMOhBwBAYEegWCDDXsnHIFJRIEVQ4JnPoI?= =?us-ascii?q?hgXguNIJiN4IujzgwPAUzDCYEcw9QRggRBhUEAQQRkl2DLYkVnnQ0aAqDOpk?= =?us-ascii?q?YBIYEFYNsi3WGTIpBhj+WFR+CIo19kGKEagIEAgQFAg4BAQaBYTuBWXAVgyR?= =?us-ascii?q?RGQ+OIAwWg1CKXnQ4AgYBCgEBAwmTLAEB?= X-IronPort-AV: E=Sophos;i="5.87,257,1631577600"; d="scan'208,217";a="967592369" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Nov 2021 09:52:06 +0000 Received: from mail.cisco.com (xbe-rcd-002.cisco.com [173.37.102.17]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 1AN9q6ot007177 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 23 Nov 2021 09:52:06 GMT Received: from xfe-aln-004.cisco.com (173.37.135.124) by xbe-rcd-002.cisco.com (173.37.102.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Tue, 23 Nov 2021 03:52:06 -0600 Received: from xfe-rtp-003.cisco.com (64.101.210.233) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Tue, 23 Nov 2021 03:52:05 -0600 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-003.cisco.com (64.101.210.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Tue, 23 Nov 2021 04:52:05 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PWKVm5+47ruODbpHo1k48bY97YYWNcifeO9y5Xu+oP7/ZXjmWprBlPgVfDFGQh6J7CG+ZWxBH4XBr1BRPQWnqlcfwETdSPq3kJIR7JyhyDNn1gjO713R/DZ0lImc/HjkNoO1z0xhY3Cx15Wwh+Lk0a9ErQraylR0PIsydpPWwrx2NTChFr/UNhDa0dl7Ji/YhnFNJglg4dnmgLYNwnm8zreLwILWBgJy/VTbfGvPwti6w3pZ853MArcaLWfC8ET6HBNOldg459MamWbJKVeYIG92KQZ4brApocjUmqB1006AFWYax+odYJbqvVzp0JgIO8ILGA+u37x9NYF9btDoyg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=aYIMWYIbTyU6ak2kFtNXriOnUsAajA8EPIfARsUVBQg=; b=RrW17xYNC2+8cZBdBhVkCHsuoSYuTw6mMax8gfNYaonmjdE4DU5V2kCHS7nkjgD4totXuANJ1XLk3mkO7UYCJ0i9OL7aoI0fUTrQ6To5fjugCjmJpWfwHJb9QczGPnZqQbB0kpEBzb/Z2VruHbzC9WxRuf/c2rHtWo5Hk/xThILmT96P0XhMI2Jw88bPpZFlLEEssRRG5qVr9EbFbSS/F18NChuW3zA/L6VzIAt8/5BzvAxuErIxVPMy7xr8t2PBrmcLuAuR1V/4XX3J8rUwrgQeI/MwKBPmV7pJYhsLHNIa5GGUTtz+fj1Twu75SmOotz2U0OTi/uzXOr6idTRGzA== 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=aYIMWYIbTyU6ak2kFtNXriOnUsAajA8EPIfARsUVBQg=; b=ipIWfBCpm0yxwXLitYfjwOrzfH1DOUQHXxVg1qe0t9fff2VpnEjsTtwEAzy4EMobU5nSh3fZx1oRAV7PzeodB6n8a1OBxK7m9cb9Jms/hJvUid2nkTSxeTzwE7t3c/uPmWbtcpyaQBVWEuTmXzzCLWgEzW6rsapkKPs0xNEGIyg= Received: from BY5PR11MB4196.namprd11.prod.outlook.com (2603:10b6:a03:1ce::13) by BYAPR11MB3654.namprd11.prod.outlook.com (2603:10b6:a03:b2::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.19; Tue, 23 Nov 2021 09:52:03 +0000 Received: from BY5PR11MB4196.namprd11.prod.outlook.com ([fe80::3dad:eeb0:be1c:b167]) by BY5PR11MB4196.namprd11.prod.outlook.com ([fe80::3dad:eeb0:be1c:b167%5]) with mapi id 15.20.4690.028; Tue, 23 Nov 2021 09:52:03 +0000 From: "Rob Wilton (rwilton)" To: Kent Watsen , Dan Romascanu CC: "ops-dir@ietf.org" , "last-call@ietf.org" , "draft-ietf-netconf-sztp-csr.all@ietf.org" , "netconf@ietf.org" Thread-Topic: [netconf] Opsdir last call review of draft-ietf-netconf-sztp-csr-11 Thread-Index: AQHX3VzmFld5pMSM+0SuUbD0sK8r0qwPwrYAgAEb33A= Date: Tue, 23 Nov 2021 09:52:03 +0000 Message-ID: References: <163733688535.10662.12846915795187697217@ietfa.amsl.com> <0100017d487f0f15-c299535d-2006-4dde-9b36-4799849666c0-000000@email.amazonses.com> In-Reply-To: <0100017d487f0f15-c299535d-2006-4dde-9b36-4799849666c0-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4eea0b22-e3d7-47b6-ab8b-08d9ae66e701 x-ms-traffictypediagnostic: BYAPR11MB3654: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +775lKZk1vRzkFfF4WGRqcbNC7Mx1FVj6/jW8a+3wApynp/xLcTbayQBljeCrF6Bjz3fup/sRjj8KYVoxJfgcT+kIOf/Gr46ow7JVD5qCejkUoXfVI0nL6NSCVCAXUakG5vwUr0IztSep8F80vpFd474twGZEbbwqkLV6z7Dvqwi+pzcKs8z7bqUu8OjlijhnyzoNG09/8xDa9HH94jv6EFmeQ3I7/DfmfF3PwTqYhQW3Fp60PZh13Z/5zoCopzwR0Ev65vUBmRrXtj0QVVlAOxVf7AUCeH8BlkQICwldPmnqlSSzjmlvcLqsTv7F/LOIKLdpAVkbKP9LGu1IVEFBMxy3wHKyBmmYYTTdQo/RXobFGvf2PBfLFPpe4hW1as8UHa61EEnv/SnggWkFDrkpez1SPxQCa5/SC7bQL2rojn2ROFq/MEvccVd9IPYkuCeQiAmE/LkNxBLBsd9/J/o30TLzKX0DreWWO/IQp43UCwQU3vSwAUWlGB7+/nAVVH/OKcgNuRMW0kkVXZ0Iaiy5pznGOLXXA4SOnZtz+CiMVy1Z0aaAhIOKFzWKZWD6OEqe2D1zd0y1+YfozyQkVEd96o4RtwLuzifen4gxSVLkWD1DbbN9JY7FmJGSmof1vUpVGjBHcjn76VOC3A5XahBiUk9sunKVii5606w9wx1E7KEAT9K6IH6Luifm9JiN2d72JP3muwP8aUcDdAIFUV9Xw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4196.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(6506007)(9686003)(66446008)(2906002)(33656002)(55016003)(64756008)(5660300002)(83380400001)(71200400001)(66476007)(508600001)(186003)(86362001)(122000001)(52536014)(66556008)(8936002)(53546011)(76116006)(38100700002)(38070700005)(26005)(110136005)(66946007)(4326008)(8676002)(316002)(54906003)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Uy9Bb1UwYzByZGg5TURxVWhITlA2b3o5a2NZd0t6a0w4TEZCbURLYzVvM0Y5?= =?utf-8?B?a3VXM1IzaGE4ZlFaM0pzcXhOUjREb3Qrd3JkTzk3elJ0Ni9qSkRWNGVTRGtS?= =?utf-8?B?M2IvT2RtZnJFT1FDVUY0T2NXeGtxdjJYYVNYaUlLeUN1ZlVZa0JBMlZKeUFD?= =?utf-8?B?RXIwTjBxb3ZFd1M1UzdiRnBRQzd2V1JIZndIN3RvU0ZHNHhKeTBDMUhtSmpZ?= =?utf-8?B?OXNDQ3Z5QmVxMERGb1FoM2I3cEU3QXY4dXRuYzV6TDFtc0lDekNYVjRXRlc4?= =?utf-8?B?RjltU0QvTkZlTUhxM25ENHlSNTEvVXk3dHdhczZHODM2RGl4SC9CeEpXS3NT?= =?utf-8?B?ODMvT0MvVlhlei9lVjZHRkZ3VmpMM1dXNS8xMjZpNHhIdGJSWmpJYnlka05r?= =?utf-8?B?aEFzajJnL28zZHVGSmpuRHQ1Y3k5LzNYZ29vc2pWaGpERHRJdTVaR29PbEh6?= =?utf-8?B?QW9taUUvNGJ0b1JZQ053Nm02YmVrUlNwa1BzY1JtREZya2J0VExFVVNYSVJp?= =?utf-8?B?aHllSmtDMVJjN3puM3NvcGRNRUNjc3JvcTF4M2p5V0Vaa3I4Zyt6YmZrZFF4?= =?utf-8?B?WGpFUU9LTm8zMnFyTkpZK3RiblNNalJuNXJLazFNSE1VRzMvRVRWWnRUODVP?= =?utf-8?B?RlpDZXFrNFlLRHVKVE1qNnVkWVlFM1JGOU8yc3R0MGJVSW5KT1JDRTN6U01E?= =?utf-8?B?R3dZQ3dJNFJ3UkJYYS9ueVRPYnZmdENHRTBrRUVmWTNZcFBRa3VMU3YxQkpt?= =?utf-8?B?bHF3b1hVaVdkTGFMcjRtbmpNQUJveHZKSWJkdWQrSWZvSmdBS1RRSWkxcFd4?= =?utf-8?B?YVJqOEMzaUw3YTFHcXZNWjhoUHNKM0lWd1lrV1FrYUIrL3NKRDFSMmlwTGNT?= =?utf-8?B?bjNlTVBza0IzM3dCd1JzMTFIZjE2SDlpOFdMV1grVmlHdDYvdGNlaUpLNVFw?= =?utf-8?B?bkpjM1Uyck1ndkRRemIxeWtXVmZwMXRMc1JNRkZxUm1qeWJuS3ZPNGhjRnFi?= =?utf-8?B?OUJ0Zkt2OXJmSDNBRm1hY1pCMzFYZ2xsTTBKMm9BMEZBVTk5bllibWlHNDJ1?= =?utf-8?B?amI3eGpFeUw3L3BiV2drVERlTkVYTi9wVjdtV2xFb2tjeDNySDFVZENjNXpX?= =?utf-8?B?YXFCUGw1K1RtUUNUUzYvNk5HWTlGNm5pRHlKZHdSQVN1KzE1OURSMHdpeE16?= =?utf-8?B?dlJvYzEvd2hjSGJGRzlldFFhSm9ONEtiM081dWRwMFdBRlZqei9SWUxiSWRv?= =?utf-8?B?aEYzQXF1MG03RmdpcGtha25jSmViNmhyWTFZdWw5T1dIa2k2UFNGcnZNekI2?= =?utf-8?B?alp5MjZ4djNLMjBzRVVvQ2xpUlZuNnRidFFwaFFkYjh2SzdpWERKY0FTVkVl?= =?utf-8?B?R1ptZC9BWm8wNXlCM1lBLzZYZ1BlK3c0TFI5dUZKWkdYQVlpQWlMakJJQkxY?= =?utf-8?B?UUpTNklsWlJCT1NnS1R0cUc2UE41LzY2MXdTaW9XNXlwZFJ0K3EvakJkV1Vx?= =?utf-8?B?UWxram80a0drbVlqVUtxT1ZXdnIyNHNDVmV2alhZN0UxcWx0K05KUUxabm4w?= =?utf-8?B?OWQ0Q2pQZDBjeVhsQm9PVVIxTU1adnJTWC9sSWpOdmFoNFUvQ1VPMFcrV1hr?= =?utf-8?B?aE55WjVxeVdRSkRKTEpTdVYvUzc2RXpJUFBQYk9LTzdpc0hNWkRVNy9ybEdl?= =?utf-8?B?NVJaR1dzZWdkOEJMZzlIQy9EQ1RDVnoyZmFuclpPNzZTMXpFSFRJNmlaVkhH?= =?utf-8?B?R2t3Y3VqMTFkRHU5elBlVkxJbGpjam8zMHhvMmE1cllqcDk4WU1WN01xUHcr?= =?utf-8?B?VFR4M093Ri9xWTB6SytyeS9EOXFOZTZUTCt0bzAxQlh2clRJWGU5dDNwMmhu?= =?utf-8?B?VlduNUZwVFF6YU9QT2pGZUlQMENSWU5VaUdnRTNuT2REOVVZTDFEWUwza0g3?= =?utf-8?B?eDNhajZhYUZWdmoraXllSmgzRU9FMnl1aEhLMXUyTytkVUhWTUtXVjBmbW5s?= =?utf-8?B?aTQ1Tm9HajZseGhOYmVHK3hyU3hVRXBUYUZJOW5TV1dXdUNaMzV5ZmRNQWRD?= =?utf-8?B?RWk4TGlNRG1lbnZSYk5jVFdPNEd0VFdvUnJ1ZnRZQnJjQVVIemg0OXpqemcw?= =?utf-8?B?QTlXNVVsV1VhcDYxRXRLdVYzTjlsd1RQdGhzYXA3aXUyWS96dU5hTERKYzRs?= =?utf-8?Q?I8HgDH3enk9eMTdQFLnzU5U=3D?= Content-Type: multipart/alternative; boundary="_000_BY5PR11MB41964C53DC283350143B6E01B5609BY5PR11MB4196namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4196.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4eea0b22-e3d7-47b6-ab8b-08d9ae66e701 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2021 09:52:03.3730 (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: SnVuji/TktYKIfKic7hzgRwWbaLhKlKKxP23frCpRmxKy10qq5dzOkMgqa44QjHcRHE0h4iPdSxCEmW/E+q1qw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3654 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.17, xbe-rcd-002.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [netconf] Opsdir last call review of draft-ietf-netconf-sztp-csr-11 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, 23 Nov 2021 09:52:17 -0000 --_000_BY5PR11MB41964C53DC283350143B6E01B5609BY5PR11MB4196namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2VudCwgYWxsLA0KDQpQbGVhc2Ugc2VlIGlubGluZSDigKYNCg0KRnJvbTogS2VudCBXYXRz ZW4gPGtlbnRAd2F0c2VuLm5ldD4NClNlbnQ6IDIyIE5vdmVtYmVyIDIwMjEgMTY6MzQNClRvOiBE YW4gUm9tYXNjYW51IDxkcm9tYXNjYUBnbWFpbC5jb20+DQpDYzogb3BzLWRpckBpZXRmLm9yZzsg bGFzdC1jYWxsQGlldGYub3JnOyBkcmFmdC1pZXRmLW5ldGNvbmYtc3p0cC1jc3IuYWxsQGlldGYu b3JnOyBuZXRjb25mQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW25ldGNvbmZdIE9wc2RpciBsYXN0 IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0Y29uZi1zenRwLWNzci0xMQ0KDQpIaSBEYW4s DQoNClRoYW5rIHlvdSBmb3IgeW91ciByZXZpZXcuICBQbGVhc2Ugc2VlIGJlbG93IGZvciByZXNw b25zZXMgdG8geW91ciBjb21tZW50cy4NCg0KS2VudA0KDQoNCg0KT24gTm92IDE5LCAyMDIxLCBh dCAxMDo0OCBBTSwgRGFuIFJvbWFzY2FudSB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5v cmc8bWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmc+PiB3cm90ZToNCg0KUmV2aWV3ZXI6IERhbiBSb21h c2NhbnUNClJldmlldyByZXN1bHQ6IFJlYWR5DQoNClRoaXMgZG9jdW1lbnQgaXMgUmVhZHkgZnJv bSBhbiBPUFMtRElSICBwZXJzcGVjdGl2ZS4NCg0KVGhpcyBkb2N1bWVudCBleHRlbmRzIHRoZSAi Z2V0LWJvb3RzdHJhcHBpbmctZGF0YSIgUlBDIGRlZmluZWQgaW4gUkZDIDg1NzIgdG8NCmluY2x1 ZGUgYW4gb3B0aW9uYWwgY2VydGlmaWNhdGUgc2lnbmluZyByZXF1ZXN0IChDU1IpLCBlbmFibGlu ZyBhIGJvb3RzdHJhcHBpbmcNCmRldmljZSB0byBhZGRpdGlvbmFsbHkgb2J0YWluIGFuIGlkZW50 aXR5IGNlcnRpZmljYXRlIChlLmcuLCBhbiBMRGV2SUQsIGZyb20NCklFRUUgODAyLjFBUikgYXMg cGFydCBvZiB0aGUgIm9uYm9hcmRpbmcgaW5mb3JtYXRpb24iIHJlc3BvbnNlIHByb3ZpZGVkIGlu IHRoZQ0KUlBDLXJlcGx5LiBJdCBwcm9pZGVzIHRoZSBhYmlsaXR5IHRvIHByb3Zpc2lvbiBhbiBp ZGVudGl0eSBjZXJ0aWZpY2F0ZSB0aGF0IGlzDQpwdXJwb3NlLWJ1aWx0IGZvciBhIHByb2R1Y3Rp b24gZW52aXJvbm1lbnQgZHVyaW5nIHRoZSBib290c3RyYXBwaW5nIHByb2Nlc3MNCnJlbW92aW5n IHRoZSByZWxpYW5jZSBvbiB0aGUgbWFudWZhY3R1cmVyIENBLCBhbmQgZW5hYmxpbmcgdGhlIGJv b3RzdHJhcGVkDQpkZXZpY2UgdG8gam9pbiB0aGUgcHJvZHVjdGlvbiBlbnZpcm9ubWVudCB3aXRo IGFuIGFwcHJvcHJpYXRlIGlkZW50aXR5LiBJdCdzIGENCmNsZWFyIGFuZCB1c2VmdWwgZG9jdW1l bnQsIHdoaWNoIG5lZWRzIHRvIGJlIHJlYWQgYW5kIHVuZGVyc3Rvb2QgYnkgb3BlcmF0b3JzDQpv ZiBJT1QgbmV0d29ya3MgdXNpbmcgdGhlIHJlc3BlY3RpdmUgdGVjaG5vbG9naWVzLg0KDQoNCkZy b20gYW4gb3BlcmF0b3IgcGVyc3BlY3RpdmUsIHRoZSBtb3N0IHJlbGV2YW50IHNlY3Rpb25zIGFy ZSAyIGFuZCAzLiBTZWN0aW9uDQoyIHJlZmVycyB0byB0aGUgaWV0Zi1zenRwLWNzciAgbW9kdWxl LiBJdCBpbmNsdWRlcyBhIERhdGEgTW9kZWwgT3ZlcnZpZXcgYXMNCndlbGwgYXMgaGludHMgYWJv dXQgaG93IHRoZSBhdWdtZW50YXRpb24gYW5kIHN0cnVjdHVyZSBkZWZpbmVkIGJ5IHRoZQ0KImll dGYtc3p0cC1jc3IiIG1vZHVsZSBhcmUgdXNlZCwgaW5jbHVkaW5nIHR3byBhZGRpdGlvbmFsIHRy ZWUgZGlhZ3JhbXMgc2hvd2luZw0KdGhlIG5vZGVzIHBsYWNlZCB3aGVyZSB0aGV5IGFyZSB1c2Vk LiBJIGZvdW5kIHRoZSBleGFtcGxlIHVzYWdlIGluIFNlY3Rpb24gMi4yDQp2ZXJ5IHVzZWZ1bC4g U2VjdGlvbiAyLjMgY29udGFpbnMgdGhlIFlBTkcgbW9kdWxlLiBTZWN0aW9uIDMgY29udGFpbnMg dGhlDQpkZXNjcmlwdGlvbiBvZiB0aGUgZGF0YSBtb2RlbCBhbmQgdGhlIGlldGYtenRwLXR5cGVz IFlBTkcgbW9kdWxlLg0KDQpJIGhhdmUgb25lIHF1ZXN0aW9uIHJlbGF0ZWQgdG8gdGhlIHR5cGUg b2YgY2VydGlmaWNhdGVzIHRoYXQgYXJlIHN1cHBvcnRlZC4NClNlY3Rpb24gMy4yIGluY2x1ZGVz IHRoZSBmb2xsb3dpbmc6DQoNCiAgICAgICBUaGUgdGVybXMgJ0lEZXZJRCcgYW5kICdMRGV2SUQn IGFyZSB1c2VkIGhlcmVpbiB0bw0KICAgICAgIG1lYW4gJ2luaXRpYWwgZGV2aWNlIGlkZW50aWZp ZXInIGFuZCAnbG9jYWwgZGV2aWNlDQogICAgICAgaWRlbnRpZmVyJy4gIFRoZXNlIHRlcm1zIGFy ZSBkZWZpbmVkIGNvbnNpc3RlbnQgd2l0aA0KICAgICAgIHRoZSBJRUVFIDgwMi4xQVIgc3BlY2lm aWNhdGlvbiwgdGhvdWdoIHRoZXJlIGlzIG5vDQogICAgICAgcmVxdWlyZW1lbnQgdGhhdCBhIFpU UC1jbGllbnQncyBpZGVudGl0eSBjZXJ0aWZpY2F0ZQ0KICAgICAgIGNvbmZvcm0gdG8gSUVFRSA4 MDIuMUFSLg0KDQpJZiBteSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3QsIHRoZSBtZWNoYW5pc20g ZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgaXMNCmdlbmVyaWMuIEhvd2V2ZXIsIGFsbCB0aGUg ZXhhbXBsZXMgYW5kIHRoZSBkZWZpbml0aW9ucyBpbiB0aGUgbW9kdWxlcyByZWZlciB0bw0KY2Vy dGlmaWNhdGlvbiBjb25mb3JtIHRvIElFRUUgODAyLjFBUi4gVGhpcyBpcyBzb21lIGtpbmQgb2Yg Y29udHJhZGljdGlvbi4NCk1heWJlIHNvbWUgdGV4dCBzcGVha2luZyBhYm91dCBvdGhlciB0eXBl cyBvZiBjZXJ0aWZpY2F0ZXMgc2hvdWxkIGJlIGFkZGVkLiBPcg0KbWF5YmUgdGhlIHNjb3BlIHNo b3VsZCBiZSBkZWZpbmVkIG1vcmUgbmFycm93IHRvIHJlZmVyIHRvIElFRUUgODAyLjFBUi4gSW4g YW55DQpjYXNlIGl0IHNlZW1zIHRvIG1lIHRoYXQgU3RkLTgwMi4xQVItMjAxOCBuZWVkcyB0byBi ZSBhIE5vcm1hdGl2ZSBSZWZlcmVuY2UgLQ0Kb25lIGNhbm5vdCB1bmRlcnN0YW5kIHRoaXMgZG9j dW1lbnQgd2l0aG91dCByZWFkaW5nIGFuZCB1bmRlcnN0YW5kaW5nIHRoZSBJRUVFDQpzdGFuZGFy ZHMuDQoNCllvdXIgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LCB0aGUgZG9jdW1lbnQgcmVnYXJk cyBkZXZpY2UgaWRlbnRpdHkgY2VydGlmaWNhdGVzIGluIGEgZ2VuZXJpYyBYLjUwOXYzIHNlbnNl LiAgIEFjdHVhbGx5LCBhIGNhcmVmdWwgcmVhZGluZyBvZiA4MDIuMUFSIHNob3dzIHRoYXQgaXQs IGVmZmVjdGl2ZWx5LCBzYXlzIHRoZSBzYW1lLCBwbGFjaW5nIHZlcnkgZmV3ICAoaWYgYW55KSBy ZXN0cmljdGlvbnMgb24gdGhlIGNvbnRlbnRzIG9mIHRoZSBYLjUwOXYzIGNlcnRpZmljYXRlLg0K DQpUaGF0IHNhaWQsIDgwMi4xQVIgZGlkIGRlZmluZSB0aGUgdGVybXMg4oCcSURldklE4oCdIGFu ZCDigJxMRGV2SUTigJ0sIHdoaWNoIGhhdmUgYmVjb21lIGZhaXJseSB3ZWxsIGtub3duIGluIHRo ZSBpbmR1c3RyeS4gIFRodXNseSwgdGhpcyBkb2N1bWVudCBhdHRlbXB0cyB0byBjYXBpdGFsaXpl IG9uIHRoYXQgZmFtaWxpYXJpdHkgdy9vIHN0YXRpbmcgdGhhdCBpZGVudGl0eSBjZXJ0aWZpY2F0 ZXMgTVVTVCBiZSA4MDIuMUFSLWNvbXBsaWFudC4NCg0KVGhyb3VnaG91dCB0aGUgYm9keSBvZiB0 aGUgZG9jdW1lbnQsIHRoZSB0ZXh0IGNvbnNpc3RlbnRseSB1c2VzIHBocmFzZW9sb2d5IHN1Y2gg YXMg4oCcYW4gaW5pdGlhbCBkZXZpY2UgaWRlbnRpdHkgY2VydGlmaWNhdGUgKGUuZy4sIGFuIElE ZXZJRCBmcm9tIDgwMi4xQVIp4oCdIHRoYXQgc2ltdWx0YW5lb3VzbHkgZG9lc24ndCBiaW5kIGlt cGxlbWVudGF0aW9ucyB0byBhIHBhcnRpY3VsYXIgaWRlbnRpdHktY2VydGlmaWNhdGUgZGVmaW5p dGlvbiB3aGlsZSByZW1haW5pbmcgaGlnaGx5IHVuZGVyc3RhbmRhYmxlLg0KDQpIb3dldmVyLCB0 aGUgdGV4dCBpbiB0aGUgWUFORyBtb2R1bGUgdXNlcyBhIGRpZmZlcmVudCBhcHByb2FjaCwgb3V0 IG9mIGEgc2Vuc2UgaWYgYnJldml0eSwgYnkgdXNpbmcgdGhlIHRlcm1zIElEZXZJRC9MRGV2SUQg ZGlyZWN0bHkgKHcvbyBhbnkgcGFyZW50aGV0aWNhbCByZWZlcmVuY2UgdG8gODAyLjFBUiksIGFs b25nIHdpdGggdGhlIHRlcm1pbm9sb2d5LWRpc2NsYWltZXIgeW91IGNvcHkvcGFzdGVkIGFib3Zl Lg0KDQpXaGlsc3QgdGhlIGRvY3VtZW50IGFwcGVhcnMgdGVjaG5pY2FsbHkgYWNjdXJhdGUvdW5h bWJpZ3VvdXMsIHRoZSBpc3N1ZSBzZWVtcyB0byB3YXJyYW50IGEgcmVtZWR5LCBhcyB0aGUgU2Vj RGlyLXJldmlldyBtYWRlIGEgc2ltaWxhciBjb21tZW50Lg0KDQpPcHRpb25zOg0KDQoxKSBEZWZp bmUgZm9ybWFsIHRlcm1zIGZvciBJRGV2aUQgYW5kIExEZXZJRCBpbiBTZWN0aW9uIDEuMiAoVGVy bWlub2xvZ3kpIHN0YXRpbmcgdGhhdCAxKSB0aGV5IGFyZSBhY3JvbnltcyBmb3Ig4oCcaW5pdGlh bC9sb2NhbCBkZXZpY2UgaWRlbnRpZmllcuKAnSBhbmQgMikgdGhleSBhcmUgY29uc2lzdGVudCB3 aXRoIHRoZSBzYW1lIHRlcm1zIGluIDgwMi4xQVIgYnV0IGRvIG5vdCBpbXBseSB0aGF0IGFueSBp bXBsZW1lbnRhdGlvbiBtdXN0IGFkaGVyZSB0byA4MDIuMUFSLiAgVGhpcyB1cGRhdGUgY291bGQg YmUgY291cGxlZCB3aXRoIHRoZSByZW1vdmFsIG9mIGFsbCB0aGUgcGFyZW50aGV0aWNhbCBwaHJh c2VvbG9neSB0aHJvdWdob3V0IHRoZSBib2R5IG9mIHRoZSBkb2N1bWVudC4NCg0KMikgTW9kaWZ5 IHRoZSBZQU5HIG1vZHVsZSB0byAxKSBhbHNvIHVzZSB0aGUgcGFyZW50aGV0aWNhbCBwaHJhc2Vv bG9neSAoZ3JlYXRseSBleHBhbmRpbmcgdGhlIHZlcmJvc2l0eSBvZiB0aGUg4oCcZGVzY3JpcHRp b27igJ0gc3RhdGVtZW50IHRleHQpIGFuZCAyKSByZW1vdmUgdGhlIHF1b3RlZCB0ZXJtaW5vbG9n eS1kaXNjbGFpbWVyIGF0IHRoZSB0b3Agb2YgdGhlIFlBTkcgbW9kdWxlLg0KDQozKSBEbyBub3Ro aW5nLg0KDQoNCldoaWNoIG9wdGlvbiBzZWVtcyBiZXN0PyAgRG9lcyBhbnlvbmUgaGF2ZS4gcHJl ZmVyZW5jZT8NCg0KSSBkb27igJl0IHRoaW5rIHRoYXQgd2Ugc2hvdWxkIGRvICgxKS4gIElmIHRo ZSBpbmR1c3RyeSB3aWRlbHkgdW5kZXJzdGFuZHMgSURldklEL0xEZXZJRCB0byBtZWFuIDgwMi4x QVIgdGhlbiByZWRlZmluaW5nIGl0IGluIHRoaXMgZHJhZnQgdG8gaGF2ZSBhIHdpZGVyIG1lYW5p bmcgY291bGQganVzdCBiZSBjb25mdXNpbmcgdG8gcmVhZGVycy4NCg0KU28gSSB0aGluayB0aGF0 IHRoZSBkcmFmdCBoYXMgYnJvYWRseSBnb3QgdGhpcyByaWdodCBpbiBpdHMgY3VycmVudCBhcHBy b2FjaCwgYnV0IEkgd291bGQgcHJvcG9zZSBhbHNvIGV4dGVuZGluZyB0aGF0IHRvIHRoZSBZQU5H IG1vZHVsZSBkZXNjcmlwdGlvbnMuDQoNClNwZWNpZmljYWxseSwgSSB3b3VsZCBzdWdnZXN0IGFk ZGluZyBhIHZlcnNpb24gb2YgdGhpcyBwYXJhZ3JhcGggdG8gdGhlIGVuZCBvZiB0aGUgZGVzY3Jp cHRpb25zIG9mIGNtYy1jc3IgYW5kIGNtcC1jc3IsIHdoaWNoIGFscmVhZHkgaGF2ZSBxdWl0ZSBs b25nIGRlc2NyaXB0aW9ucywgc28gdGhlIGV4dHJhIHBhcmFncmFwaCBzaG91bGRu4oCZdCByZWFs bHkgYmUgYSBwcm9ibGVtLg0KDQogICAgICAgIFRoZSB0ZXJtcyAnSURldklEJyBhbmQgJ0xEZXZJ RCcgYXJlIHVzZWQgaGVyZWluIHRvDQogICAgICAgIG1lYW4gJ2luaXRpYWwgZGV2aWNlIGlkZW50 aWZpZXInIGFuZCAnbG9jYWwgZGV2aWNlDQogICAgICAgIGlkZW50aWZlcicuICBUaGVzZSB0ZXJt cyBhcmUgZGVmaW5lZCBjb25zaXN0ZW50IHdpdGgNCiAgICAgICAgdGhlIElFRUUgODAyLjFBUiBz cGVjaWZpY2F0aW9uLCB0aG91Z2ggdGhlcmUgaXMgbm8NCiAgICAgICAgcmVxdWlyZW1lbnQgdGhh dCBhIFpUUC1jbGllbnQncyBpZGVudGl0eSBjZXJ0aWZpY2F0ZQ0KICAgICAgICBjb25mb3JtIHRv IElFRUUgODAyLjFBUi4NCg0KSSB3b3VsZCBzdWdnZXN0IGNoYW5naW5nIHRoZSBkZXNjcmlwdGlv biBpbiBjZXJ0LXJlcS1pbmZvIHRvIOKAnChlLmcuLCBhbiBJRGV2SUQgZnJvbSBJRUVFIDgwMi4x QVIp4oCdDQoNClJvYg0KDQpLZW50IC8vIGNvLWF1dGhvcg0KDQoNCg0KDQo= --_000_BY5PR11MB41964C53DC283350143B6E01B5609BY5PR11MB4196namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13 b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIEtlbnQsIGFsbCw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+UGxlYXNlIHNlZSBpbmxpbmUg4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IEtlbnQg V2F0c2VuICZsdDtrZW50QHdhdHNlbi5uZXQmZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMjIgTm92 ZW1iZXIgMjAyMSAxNjozNDxicj4NCjxiPlRvOjwvYj4gRGFuIFJvbWFzY2FudSAmbHQ7ZHJvbWFz Y2FAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gb3BzLWRpckBpZXRmLm9yZzsgbGFzdC1j YWxsQGlldGYub3JnOyBkcmFmdC1pZXRmLW5ldGNvbmYtc3p0cC1jc3IuYWxsQGlldGYub3JnOyBu ZXRjb25mQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0Y29uZl0gT3BzZGly IGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRjb25mLXN6dHAtY3NyLTExPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SGkgRGFuLDxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhhbmsgeW91IGZvciB5b3VyIHJldmll dy4gJm5ic3A7UGxlYXNlIHNlZSBiZWxvdyBmb3IgcmVzcG9uc2VzIHRvIHlvdXIgY29tbWVudHMu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPktlbnQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+T24gTm92IDE5LCAyMDIxLCBhdCAxMDo0OCBBTSwgRGFuIFJvbWFzY2Fu dSB2aWEgRGF0YXRyYWNrZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpub3JlcGx5QGlldGYub3JnIj5u b3JlcGx5QGlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij5SZXZpZXdlcjogRGFuIFJvbWFzY2FudTxicj4NClJldmlldyByZXN1 bHQ6IFJlYWR5PGJyPg0KPGJyPg0KVGhpcyBkb2N1bWVudCBpcyBSZWFkeSBmcm9tIGFuIE9QUy1E SVIgJm5ic3A7cGVyc3BlY3RpdmUuPGJyPg0KPGJyPg0KVGhpcyBkb2N1bWVudCBleHRlbmRzIHRo ZSAmcXVvdDtnZXQtYm9vdHN0cmFwcGluZy1kYXRhJnF1b3Q7IFJQQyBkZWZpbmVkIGluIFJGQyA4 NTcyIHRvPGJyPg0KaW5jbHVkZSBhbiBvcHRpb25hbCBjZXJ0aWZpY2F0ZSBzaWduaW5nIHJlcXVl c3QgKENTUiksIGVuYWJsaW5nIGEgYm9vdHN0cmFwcGluZzxicj4NCmRldmljZSB0byBhZGRpdGlv bmFsbHkgb2J0YWluIGFuIGlkZW50aXR5IGNlcnRpZmljYXRlIChlLmcuLCBhbiBMRGV2SUQsIGZy b208YnI+DQpJRUVFIDgwMi4xQVIpIGFzIHBhcnQgb2YgdGhlICZxdW90O29uYm9hcmRpbmcgaW5m b3JtYXRpb24mcXVvdDsgcmVzcG9uc2UgcHJvdmlkZWQgaW4gdGhlPGJyPg0KUlBDLXJlcGx5LiBJ dCBwcm9pZGVzIHRoZSBhYmlsaXR5IHRvIHByb3Zpc2lvbiBhbiBpZGVudGl0eSBjZXJ0aWZpY2F0 ZSB0aGF0IGlzPGJyPg0KcHVycG9zZS1idWlsdCBmb3IgYSBwcm9kdWN0aW9uIGVudmlyb25tZW50 IGR1cmluZyB0aGUgYm9vdHN0cmFwcGluZyBwcm9jZXNzPGJyPg0KcmVtb3ZpbmcgdGhlIHJlbGlh bmNlIG9uIHRoZSBtYW51ZmFjdHVyZXIgQ0EsIGFuZCBlbmFibGluZyB0aGUgYm9vdHN0cmFwZWQ8 YnI+DQpkZXZpY2UgdG8gam9pbiB0aGUgcHJvZHVjdGlvbiBlbnZpcm9ubWVudCB3aXRoIGFuIGFw cHJvcHJpYXRlIGlkZW50aXR5LiBJdCdzIGE8YnI+DQpjbGVhciBhbmQgdXNlZnVsIGRvY3VtZW50 LCB3aGljaCBuZWVkcyB0byBiZSByZWFkIGFuZCB1bmRlcnN0b29kIGJ5IG9wZXJhdG9yczxicj4N Cm9mIElPVCBuZXR3b3JrcyB1c2luZyB0aGUgcmVzcGVjdGl2ZSB0ZWNobm9sb2dpZXMuPGJyPg0K PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPkZyb20gYW4gb3BlcmF0b3IgcGVyc3BlY3RpdmUsIHRoZSBt b3N0IHJlbGV2YW50IHNlY3Rpb25zIGFyZSAyIGFuZCAzLiBTZWN0aW9uDQo8bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjIgcmVmZXJzIHRvIHRoZSBpZXRmLXN6dHAtY3NyICZuYnNwO21vZHVsZS4gSXQg aW5jbHVkZXMgYSBEYXRhIE1vZGVsIE92ZXJ2aWV3IGFzPGJyPg0Kd2VsbCBhcyBoaW50cyBhYm91 dCBob3cgdGhlIGF1Z21lbnRhdGlvbiBhbmQgc3RydWN0dXJlIGRlZmluZWQgYnkgdGhlPGJyPg0K JnF1b3Q7aWV0Zi1zenRwLWNzciZxdW90OyBtb2R1bGUgYXJlIHVzZWQsIGluY2x1ZGluZyB0d28g YWRkaXRpb25hbCB0cmVlIGRpYWdyYW1zIHNob3dpbmc8YnI+DQp0aGUgbm9kZXMgcGxhY2VkIHdo ZXJlIHRoZXkgYXJlIHVzZWQuIEkgZm91bmQgdGhlIGV4YW1wbGUgdXNhZ2UgaW4gU2VjdGlvbiAy LjI8YnI+DQp2ZXJ5IHVzZWZ1bC4gU2VjdGlvbiAyLjMgY29udGFpbnMgdGhlIFlBTkcgbW9kdWxl LiBTZWN0aW9uIDMgY29udGFpbnMgdGhlPGJyPg0KZGVzY3JpcHRpb24gb2YgdGhlIGRhdGEgbW9k ZWwgYW5kIHRoZSBpZXRmLXp0cC10eXBlcyBZQU5HIG1vZHVsZS48YnI+DQo8YnI+DQpJIGhhdmUg b25lIHF1ZXN0aW9uIHJlbGF0ZWQgdG8gdGhlIHR5cGUgb2YgY2VydGlmaWNhdGVzIHRoYXQgYXJl IHN1cHBvcnRlZC48YnI+DQpTZWN0aW9uIDMuMiBpbmNsdWRlcyB0aGUgZm9sbG93aW5nOjxicj4N Cjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RoZSB0ZXJt cyAnSURldklEJyBhbmQgJ0xEZXZJRCcgYXJlIHVzZWQgaGVyZWluIHRvPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bWVhbiAnaW5pdGlhbCBkZXZpY2UgaWRl bnRpZmllcicgYW5kICdsb2NhbCBkZXZpY2U8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtpZGVudGlmZXInLiAmbmJzcDtUaGVzZSB0ZXJtcyBhcmUgZGVmaW5l ZCBjb25zaXN0ZW50IHdpdGg8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDt0aGUgSUVFRSA4MDIuMUFSIHNwZWNpZmljYXRpb24sIHRob3VnaCB0aGVyZSBpcyBu bzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3JlcXVpcmVt ZW50IHRoYXQgYSBaVFAtY2xpZW50J3MgaWRlbnRpdHkgY2VydGlmaWNhdGU8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjb25mb3JtIHRvIElFRUUgODAyLjFB Ui48YnI+DQo8YnI+DQpJZiBteSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3QsIHRoZSBtZWNoYW5p c20gZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgaXM8YnI+DQpnZW5lcmljLiBIb3dldmVyLCBh bGwgdGhlIGV4YW1wbGVzIGFuZCB0aGUgZGVmaW5pdGlvbnMgaW4gdGhlIG1vZHVsZXMgcmVmZXIg dG88YnI+DQpjZXJ0aWZpY2F0aW9uIGNvbmZvcm0gdG8gSUVFRSA4MDIuMUFSLiBUaGlzIGlzIHNv bWUga2luZCBvZiBjb250cmFkaWN0aW9uLjxicj4NCk1heWJlIHNvbWUgdGV4dCBzcGVha2luZyBh Ym91dCBvdGhlciB0eXBlcyBvZiBjZXJ0aWZpY2F0ZXMgc2hvdWxkIGJlIGFkZGVkLiBPcjxicj4N Cm1heWJlIHRoZSBzY29wZSBzaG91bGQgYmUgZGVmaW5lZCBtb3JlIG5hcnJvdyB0byByZWZlciB0 byBJRUVFIDgwMi4xQVIuIEluIGFueTxicj4NCmNhc2UgaXQgc2VlbXMgdG8gbWUgdGhhdCBTdGQt ODAyLjFBUi0yMDE4IG5lZWRzIHRvIGJlIGEgTm9ybWF0aXZlIFJlZmVyZW5jZSAtPGJyPg0Kb25l IGNhbm5vdCB1bmRlcnN0YW5kIHRoaXMgZG9jdW1lbnQgd2l0aG91dCByZWFkaW5nIGFuZCB1bmRl cnN0YW5kaW5nIHRoZSBJRUVFPGJyPg0Kc3RhbmRhcmRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPllvdXIg dW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LCB0aGUgZG9jdW1lbnQgcmVnYXJkcyBkZXZpY2UgaWRl bnRpdHkgY2VydGlmaWNhdGVzIGluIGEgZ2VuZXJpYyZuYnNwOzxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+WC41MDl2Mzwvc3Bhbj4mbmJzcDtzZW5zZS4gJm5ic3A7IEFjdHVhbGx5LCBhIGNhcmVm dWwgcmVhZGluZyBvZiA4MDIuMUFSIHNob3dzIHRoYXQgaXQsIGVmZmVjdGl2ZWx5LA0KIHNheXMg dGhlIHNhbWUsIHBsYWNpbmcgdmVyeSBmZXcgJm5ic3A7KGlmIGFueSkgcmVzdHJpY3Rpb25zIG9u IHRoZSBjb250ZW50cyBvZiB0aGUgWC41MDl2MyBjZXJ0aWZpY2F0ZS4gJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRoYXQgc2FpZCwgODAy LjFBUiBkaWQgZGVmaW5lIHRoZSB0ZXJtcyDigJxJRGV2SUTigJ0gYW5kIOKAnExEZXZJROKAnSwg d2hpY2ggaGF2ZSBiZWNvbWUgZmFpcmx5IHdlbGwga25vd24gaW4gdGhlIGluZHVzdHJ5LiAmbmJz cDtUaHVzbHksIHRoaXMgZG9jdW1lbnQgYXR0ZW1wdHMgdG8gY2FwaXRhbGl6ZSBvbiB0aGF0IGZh bWlsaWFyaXR5IHcvbyBzdGF0aW5nIHRoYXQgaWRlbnRpdHkgY2VydGlmaWNhdGVzDQogTVVTVCBi ZSA4MDIuMUFSLWNvbXBsaWFudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+VGhyb3VnaG91dCB0aGUgYm9keSBvZiB0aGUgZG9jdW1lbnQsIHRoZSB0 ZXh0IGNvbnNpc3RlbnRseSB1c2VzIHBocmFzZW9sb2d5IHN1Y2ggYXMg4oCcYW4gaW5pdGlhbCBk ZXZpY2UgaWRlbnRpdHkgY2VydGlmaWNhdGUgKGUuZy4sIGFuIElEZXZJRCBmcm9tIDgwMi4xQVIp 4oCdIHRoYXQgc2ltdWx0YW5lb3VzbHkgZG9lc24ndCBiaW5kIGltcGxlbWVudGF0aW9ucyB0byBh DQogcGFydGljdWxhciBpZGVudGl0eS1jZXJ0aWZpY2F0ZSBkZWZpbml0aW9uIHdoaWxlIHJlbWFp bmluZyBoaWdobHkgdW5kZXJzdGFuZGFibGUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkhvd2V2ZXIsIHRoZSB0ZXh0IGluIHRoZSBZQU5H IG1vZHVsZSB1c2VzIGEgZGlmZmVyZW50IGFwcHJvYWNoLCBvdXQgb2YgYSBzZW5zZSBpZiBicmV2 aXR5LCBieSB1c2luZyB0aGUgdGVybXMgSURldklEL0xEZXZJRCBkaXJlY3RseSAody9vIGFueSBw YXJlbnRoZXRpY2FsIHJlZmVyZW5jZSB0byA4MDIuMUFSKSwgYWxvbmcgd2l0aCB0aGUgdGVybWlu b2xvZ3ktZGlzY2xhaW1lcg0KIHlvdSBjb3B5L3Bhc3RlZCBhYm92ZS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+V2hpbHN0IHRoZSBkb2N1bWVudCBh cHBlYXJzIHRlY2huaWNhbGx5IGFjY3VyYXRlL3VuYW1iaWd1b3VzLCB0aGUgaXNzdWUgc2VlbXMg dG8gd2FycmFudCBhIHJlbWVkeSwgYXMgdGhlJm5ic3A7U2VjRGlyLXJldmlldyBtYWRlIGEgc2lt aWxhciBjb21tZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij5PcHRpb25zOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij4xKSBEZWZpbmUgZm9ybWFsIHRlcm1zIGZvciBJRGV2aUQgYW5kIExEZXZJRCBp biBTZWN0aW9uIDEuMiAoVGVybWlub2xvZ3kpIHN0YXRpbmcgdGhhdCAxKSB0aGV5IGFyZSBhY3Jv bnltcyBmb3Ig4oCcaW5pdGlhbC9sb2NhbCBkZXZpY2UgaWRlbnRpZmllcuKAnSBhbmQgMikgdGhl eSBhcmUgY29uc2lzdGVudCB3aXRoIHRoZSBzYW1lIHRlcm1zIGluIDgwMi4xQVIgYnV0IGRvDQog bm90IGltcGx5IHRoYXQgYW55IGltcGxlbWVudGF0aW9uIG11c3QgYWRoZXJlIHRvIDgwMi4xQVIu ICZuYnNwO1RoaXMgdXBkYXRlIGNvdWxkIGJlIGNvdXBsZWQgd2l0aCB0aGUgcmVtb3ZhbCBvZiBh bGwgdGhlIHBhcmVudGhldGljYWwgcGhyYXNlb2xvZ3kgdDxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+aHJvdWdob3V0IHRoZSBib2R5IG9mIHRoZSBkb2N1bWVudC48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjIpIE1vZGlmeSB0aGUgWUFO RyBtb2R1bGUgdG8gMSkgYWxzbyB1c2UgdGhlJm5ic3A7PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5wYXJlbnRoZXRpY2FsIHBocmFzZW9sb2d5IChncmVhdGx5IGV4cGFuZGluZyB0aGUgdmVyYm9z aXR5IG9mIHRoZSZuYnNwO+KAnGRlc2NyaXB0aW9u4oCdIHN0YXRlbWVudCB0ZXh0KSBhbmQgMikg cmVtb3ZlIHRoZSBxdW90ZWQmbmJzcDt0ZXJtaW5vbG9neS1kaXNjbGFpbWVyJm5ic3A7YXQNCiB0 aGUgdG9wIG9mIHRoZSBZQU5HIG1vZHVsZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjMpIERvIG5vdGhpbmcuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+V2hpY2ggb3B0aW9uIHNlZW1zIGJlc3Q/ICZuYnNwO0RvZXMgYW55b25lIGhhdmUu IHByZWZlcmVuY2U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9u4oCZdCB0aGluayB0aGF0IHdlIHNob3VsZCBkbyAo MSkuJm5ic3A7IElmIHRoZSBpbmR1c3RyeSB3aWRlbHkgdW5kZXJzdGFuZHMgSURldklEL0xEZXZJ RCB0byBtZWFuIDgwMi4xQVIgdGhlbiByZWRlZmluaW5nIGl0IGluIHRoaXMgZHJhZnQgdG8gaGF2 ZSBhIHdpZGVyIG1lYW5pbmcgY291bGQganVzdCBiZSBjb25mdXNpbmcgdG8gcmVhZGVycy48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gSSB0aGluayB0aGF0IHRoZSBkcmFmdCBoYXMgYnJvYWRs eSBnb3QgdGhpcyByaWdodCBpbiBpdHMgY3VycmVudCBhcHByb2FjaCwgYnV0IEkgd291bGQgcHJv cG9zZSBhbHNvIGV4dGVuZGluZyB0aGF0IHRvIHRoZSBZQU5HIG1vZHVsZSBkZXNjcmlwdGlvbnMu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNwZWNpZmljYWxseSwgSSB3b3VsZCBzdWdnZXN0IGFk ZGluZyBhIHZlcnNpb24gb2YgdGhpcyBwYXJhZ3JhcGggdG8gdGhlIGVuZCBvZiB0aGUgZGVzY3Jp cHRpb25zIG9mIGNtYy1jc3IgYW5kIGNtcC1jc3IsIHdoaWNoIGFscmVhZHkgaGF2ZSBxdWl0ZSBs b25nIGRlc2NyaXB0aW9ucywgc28gdGhlIGV4dHJhIHBhcmFncmFwaCBzaG91bGRu4oCZdCByZWFs bHkgYmUgYSBwcm9ibGVtLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJhLWJvcmRlci1k aXY7Ym9yZGVyOnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzo4LjBwdCA4LjBwdCA4LjBwdCA4 LjBwdDtiYWNrZ3JvdW5kOiNGRkZERjUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxs O2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIHRlcm1zICdJRGV2SUQnIGFu ZCAnTERldklEJyBhcmUgdXNlZCBoZXJlaW4gdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNG RkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20iPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBtZWFuICdpbml0aWFsIGRldmljZSBpZGVudGlmaWVyJyBhbmQgJ2xvY2FsIGRldmljZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3Jk ZXI6bm9uZTtwYWRkaW5nOjBjbSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlkZW50aWZlcicuJm5ic3A7IFRoZXNlIHRl cm1zIGFyZSBkZWZpbmVkIGNvbnNpc3RlbnQgd2l0aDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6 I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHRoZSBJRUVFIDgwMi4xQVIgc3BlY2lmaWNhdGlvbiwgdGhvdWdoIHRoZXJlIGlzIG5v PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2Jv cmRlcjpub25lO3BhZGRpbmc6MGNtIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVxdWlyZW1lbnQgdGhhdCBhIFpUUC1j bGllbnQncyBpZGVudGl0eSBjZXJ0aWZpY2F0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZG RkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGNvbmZvcm0gdG8gSUVFRSA4MDIuMUFSLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIHdvdWxkIHN1Z2dlc3QgY2hhbmdpbmcgdGhlIGRlc2NyaXB0aW9uIGluIGNl cnQtcmVxLWluZm8gdG8g4oCcKGUuZy4sIGFuIElEZXZJRCBmcm9tIElFRUUgODAyLjFBUinigJ08 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Um9iPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPktlbnQgLy8gY28tYXV0aG9yPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BY5PR11MB41964C53DC283350143B6E01B5609BY5PR11MB4196namp_-- From nobody Tue Nov 23 07:18:43 2021 Return-Path: <0100017d4d608976-11759577-0c2e-4efb-bc34-3da1d8ad2bcb-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 A58593A08BC; Tue, 23 Nov 2021 07:18:35 -0800 (PST) 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 rCynVaaRKDGj; Tue, 23 Nov 2021 07:18:33 -0800 (PST) Received: from a48-95.smtp-out.amazonses.com (a48-95.smtp-out.amazonses.com [54.240.48.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AC003A08B7; Tue, 23 Nov 2021 07:18:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1637680712; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=QuNirnoOzXYZKqkxFafUrgXq9aDRofEvrp6ZJRlZql4=; b=Hwa/7wxGHbzvuizZiEF8rm08c+fokgWQYACs4C2j8MBMC2wCaCY7RlEppZXyllW5 rvBU057GOw3WTsodNuhY9v7a9Vn0inefB/Gj9lTYK88OIUzsUxRx0OsrFeFGHSuZ9lq pDyIx+62slkhuhsNYvg8vew5YODamjXR5w4Klk0g= From: Kent Watsen Message-ID: <0100017d4d608976-11759577-0c2e-4efb-bc34-3da1d8ad2bcb-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8A7C0F78-4812-4671-B007-FC4505F7D609" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 23 Nov 2021 15:18:32 +0000 In-Reply-To: Cc: Dan Romascanu , "last-call@ietf.org" , "ops-dir@ietf.org" , "draft-ietf-netconf-sztp-csr.all@ietf.org" , "netconf@ietf.org" To: "Rob Wilton (rwilton)" References: <163733688535.10662.12846915795187697217@ietfa.amsl.com> <0100017d487f0f15-c299535d-2006-4dde-9b36-4799849666c0-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.11.23-54.240.48.95 Archived-At: Subject: Re: [netconf] [Last-Call] Opsdir last call review of draft-ietf-netconf-sztp-csr-11 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, 23 Nov 2021 15:18:36 -0000 --Apple-Mail=_8A7C0F78-4812-4671-B007-FC4505F7D609 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Rob, Thank you for your input. Please see below for responses to your = comments. Kent >=20 > Which option seems best? Does anyone have. preference? > =20 > I don=E2=80=99t think that we should do (1). If the industry widely = understands IDevID/LDevID to mean 802.1AR then redefining it in this = draft to have a wider meaning could just be confusing to readers. Agreed. > So I think that the draft has broadly got this right in its current = approach, but I would propose also extending that to the YANG module = descriptions. Agreed. =20 > Specifically, I would suggest adding a version of this paragraph to = the end of the descriptions of cmc-csr and cmp-csr, which already have = quite long descriptions, so the extra paragraph shouldn=E2=80=99t really = be a problem. > =20 > The terms 'IDevID' and 'LDevID' are used herein to >=20 > mean 'initial device identifier' and 'local device >=20 > identifer'. These terms are defined consistent with >=20 > the IEEE 802.1AR specification, though there is no >=20 > requirement that a ZTP-client's identity certificate >=20 > conform to IEEE 802.1AR. >=20 Yikes! After sending the response to Dan, I decided on option 2 = (expanding all the IDevID/LDevID usages). In my response to Yaron = yesterday I wrote: We updated the YANG module to greatly remove references to = IDevID/LDevID. Specifically: 1) s/IDevID/initial device identity certificate/g 2) s/LDevID/local device identity certificate/g 3) manually rewrap lines to col 69 as required 4) removed the terminology-disclaimer block at top The diff is here: = https://github.com/netconf-wg/sztp-csr/commit/ac35f96eec96528dddf5798d528d= 9874a85c604b Good? This isn=E2=80=99t what you suggest, but it=E2=80=99s quite good, maybe = better? Your approach seems like it would=E2=80=99ve been more = convenient but, given that it is what it is now, are you okay with the = current edit? [PS: I haven=E2=80=99t posted an updated draft yet as = I=E2=80=99m waiting to complete the reviews with Yaron and Dan first] > =20 > I would suggest changing the description in cert-req-info to =E2=80=9C(e= .g., an IDevID from IEEE 802.1AR)=E2=80=9D Done! = https://github.com/netconf-wg/sztp-csr/commit/45ace9b40eedabb84e10607592d2= 9146cb54a9c9 = > Rob K. --Apple-Mail=_8A7C0F78-4812-4671-B007-FC4505F7D609 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Rob,

Thank you for = your input.  Please see below for responses to your = comments.

Kent



Which option seems best?  Does = anyone have. preference?
 
I don=E2=80=99t think that = we should do (1).  If the industry widely understands IDevID/LDevID = to mean 802.1AR then redefining it in this draft to have a wider meaning = could just be confusing to = readers.

Agreed.


So I think that the draft has broadly got this = right in its current approach, but I would propose also extending that = to the YANG module = descriptions.

Agreed.

 
Specifically, I would suggest adding a = version of this paragraph to the end of the descriptions of cmc-csr and = cmp-csr, which already have quite long descriptions, so the extra = paragraph shouldn=E2=80=99t really be a problem.
 

        The = terms 'IDevID' and 'LDevID' are used herein to

        mean 'initial = device identifier' and 'local device

        identifer'.  = These terms are defined consistent with

        the IEEE 802.1AR = specification, though there is no

        requirement that a = ZTP-client's identity certificate

        conform to IEEE = 802.1AR.



Yikes!   After = sending the response to Dan, I decided on option 2 (expanding = all the IDevID/LDevID usages).  In my response to Yaron yesterday I = wrote:

We = updated the YANG module to greatly remove references to = IDevID/LDevID.

Specifically:
= 1) s/IDevID/initial device identity certificate/g
= 2) s/LDevID/local device identity certificate/g
= 3) manually rewrap lines to col 69 as required
= 4) removed the terminology-disclaimer block at top

The diff is here: https://github.com/netconf-wg/sztp-csr/commit/ac35f96eec96528dd= df5798d528d9874a85c604b

Good?

This isn=E2=80=99t what you = suggest, but it=E2=80=99s quite good, maybe better?   Your approach = seems like it would=E2=80=99ve been more convenient but, given that it = is what it is now, are you okay with the current edit?  [PS: I = haven=E2=80=99t posted an updated draft yet as I=E2=80=99m waiting to = complete the reviews with Yaron and Dan first]

 
I would suggest changing the description in = cert-req-info to =E2=80=9C(e.g., an IDevID from IEEE = 802.1AR)=E2=80=9D


Done! https://github.com/netconf-wg/sztp-csr/commit/45ace9b40eedabb84= e10607592d29146cb54a9c9


Rob

K.





= --Apple-Mail=_8A7C0F78-4812-4671-B007-FC4505F7D609-- From nobody Tue Nov 23 07:33:52 2021 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 43CD13A08F6; Tue, 23 Nov 2021 07:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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_H2=-0.001, SPF_NONE=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=OwSWQ2l+; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=rIWC7rCp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJc3jBBEymnK; Tue, 23 Nov 2021 07:33:40 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E22C73A08F7; Tue, 23 Nov 2021 07:33:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22000; q=dns/txt; s=iport; t=1637681620; x=1638891220; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=P1LnheSmW1vw4Dkm0n+PI7Tqwd5UgMYzhCccJ24t++k=; b=OwSWQ2l+DurZuhGnDMxNy7UWv1h4N363G30zYzbdpfHZIgIyn5v0BSyz zLfGJSjT964GTiziqWl+iI3ciHq0eoebbknu7VDcWcANzFJn11B1tOgM7 1WJag4Qz9w3SntcVf9683ifAMFKCmwpcz3V3FHrvyxMyOldZVFaAHTafq A=; X-IPAS-Result: =?us-ascii?q?A0BDBgAwCZ1h/4MNJK1RCYJigSExUQd3WjcxhEeDRwOFO?= =?us-ascii?q?YUOgwIDiwSQCYEuFIERA1QLAQEBDQEBNwoEAQGFBAIXglsCJTQJDgECBAEBA?= =?us-ascii?q?QEDAgMBAQEBBQEBBQEBAQIBBgSBCROFaA2GQgEBAQEDEhEKEwEBNwEPAgEIE?= =?us-ascii?q?QQBASsCAgIfER0IAgQOBQgaglCBflcDLwEOomsBgToCih96gTGBAYIIAQEGB?= =?us-ascii?q?ASBNgGDUw0LgjUDBoE6gw6EHAEBhgt7JxyBSUSBWIFmUTA+giFCAoE0Ehwrg?= =?us-ascii?q?ms3gi6QER4YJypDEIFFOAcPAh6VIwFGiRaNWZFPaAqDOopSjkaGCBWDbIt1k?= =?us-ascii?q?Q2GP5YVjHaDSJVMAgQCBAUCDgEBBoFhO4FZcBWDJFEZD45XgzuKXnQLLQIGA?= =?us-ascii?q?QoBAQMJkywBAQ?= IronPort-PHdr: A9a23:GUp45BHtT94iZy6vpHNu3J1GfiYY04WdBeZdwpYkircbdKOl8tyiO UHE/vxigRfPWpmT8PNLjefa8sWCEWwN6JqMqjYOJZpLURJWhcAfhQd1BsmDBAXyJ+LraCpvG sNEWRdl8ni3PFITFtz5YgjZo2a56ngZHRCsXTc= IronPort-Data: A9a23:pRpD7Kj3jRtYzuHBiQvSlcB4X161DhEKZh0ujC45NGQN5FlHY01je htvWjqOOa7bNGeket8gYdjgpBkFvpXdxtU3GwY/rCE3HyJjpJueD7x1DKtf0wB+jyHnZBg6h ynLQoCYdKjYdpJfz/uUGuCJQUNUjclkfZKhTr6bUsxNbVU8En540Eg4w7VRbrNA2LBVPSvc4 bsenOWHULOV82Yc3rU8sv/rRLtH5ZweiRtA1rAMTakjUGz2yxH5OKkiyZSZdBMUdGX78tmSH I4vxJnhlo/QEoxE5tmNyt4XeWVSKlLe0JTnZnd+A8CfbhZ+SiMawKcQGMc2Vh9t1DjRlvBUy oppm6LrcFJ8VkHMsLx1vxhwGiV6O+hN/6XKZCH5us2IxEqAeHzpqxlsJBhpZstDpKAuWicXr qVwxDMlNnhvg8qs37O/Vu5qrs8iN8LseogYvxmMyBmJV6t3H86eHfSiCdlw5moii+5uPM7kW JBBZB5jSh3FMyMSAwJCYH45tKLy7pXlSBVepU6eoqw5y2ne0AI316LiWPLZYNWEWYBUk1qW4 2TL42/+BB9fL86D0X+O6Wjqj+vLtSL2RIxUE6e3ntZtmEbWym0JIBwbSVX9puO24ma6UslDb kcd/i4GrKUu+gqsVNaVdxGip3uNpRUVc9VVGuw+rgqKz8L84AufGkAbRyJaZdpgssIqLQHGz XeAm9fvQDdoqrDQEDSW96yfqnW5Pi19wXI+WBLohDAtu7HLyLzfRDqWJjq/OMZZVuHIJAw= IronPort-HdrOrdr: A9a23:TCAIJKNvBtdxsMBcT23155DYdb4zR+YMi2TDiHoRdfUFSKKlfp 6V88jzjSWE9wr4WBkb6Le90dq7MA3hHP9OkMcs1NKZPDUO11HYV72KgbGSpgEIXheOitK1tp 0QMpSWaueAd2SS5PySiGLTfrpQo6jkzEnrv5ai854Hd3ANV0gU1XYANu/tKDwOeOApP+tcKL Osou584xawc3Ueacq2QlMfWfLYmtHNnJX6JTYbGh8O8mC1/HOVwY+/NyLd8gYVUjtJz7tn23 PCiRbF6qKqtOz+4gPA1lXU849dlLLau5h+7Y23+4oowwfX+0KVjbdaKvq/VfcO0aeSAWMR4Z zxStEbTp1OAj3qDzmISFDWqnjdOX4Vmg/fIBmj8CDeSQiTfkNmNyKH7rgpKCcxonBQz+1Uwe ZF2XmUuIFQCg6FlCPh58LQXxUvjUasp2E++NRjwkC3fLFuI4O5l7Zvtn+90a1wax7S+cQiCq 1jHcvc7PFZfReTaG3YpHBmxJipUm4oFhmLT0AesojNugIm00xR3g8d3ogSj30A/JUyR91N4P nFKL1hkPVLQtUNZaxwCe8dSY+8C3DLQxjLLGWOSG6XWJ0vKjbIsdr68b817OaldNgBy4Yzgo 3IVBdCuWs7ayvVeIWzNV1wg1nwqUmGLEHQI/Bllu5EU+fHNcjW2AW4OSQTr/c= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.87,258,1631577600"; d="scan'208,217";a="825966569" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Nov 2021 15:33:38 +0000 Received: from mail.cisco.com (xbe-rcd-005.cisco.com [173.37.102.20]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 1ANFXctF019476 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 23 Nov 2021 15:33:38 GMT Received: from xfe-rtp-005.cisco.com (64.101.210.235) by xbe-rcd-005.cisco.com (173.37.102.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Tue, 23 Nov 2021 09:33:38 -0600 Received: from xfe-rtp-001.cisco.com (64.101.210.231) by xfe-rtp-005.cisco.com (64.101.210.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Tue, 23 Nov 2021 10:33:37 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-001.cisco.com (64.101.210.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Tue, 23 Nov 2021 10:33:37 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=khqyLVqH30dytwShX88ovK4/8z7DDkXYjUpKyIe1WvFDeDBPFYUltD5+auA2tdKGfmpnTTiwdm4nPmvq+BMrIZhnwKq0Fdm4F6GhMN5Pq8kbUjZVfIgxgwPfS+kKosd3dhooh9giHC8DGOaAtOluSHIFSUwKz/K8oxjqZeOtx5gBMI2Qw/v1YVWCoU9MvFYdusYOZIn6ln2ctdI/ApDW455laEYZeR92dLMHqYgpXGgpr3DYyAyJyYqG2BSES6GQYuhjAESxI7hQb68mrVF/5Rh/A/o4oaIJU68F4XzlQVHLlFJRCY7wg09pYXVNNdc7V7/9Zuat339GZakore05aw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=P1LnheSmW1vw4Dkm0n+PI7Tqwd5UgMYzhCccJ24t++k=; b=EAKwWW0vXVoBU70PzRNxmW5wjiTUTWsMtXHLO2CtRaU2fD9AbRxiC6RcfgzlKjsO5MvjYxQxgP6TBeEskx5PTULeqhoNzWsxtt7uAunAGUZ9JQcSL9AaOI0jxqCbx5t9s6ecmCeMYkz8bT9mEe1uFHOgB75hJeDtoULuSlLfc9cUs+fxeYrgG3ugXB3jVnlnHLTH0wQ8undcjLR1DGVwbjfNqh6dpiTexAyEmbnLsur6U4rE2bU/SuS2NSO0RrRI/1pSfFFJeQEY3/BLX+U58t97M84F3J7/KyunluYm5PGYNDlF0CVAij6rC5meVKDmYMPFxu0QMln5k3/zbLL6MQ== 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=P1LnheSmW1vw4Dkm0n+PI7Tqwd5UgMYzhCccJ24t++k=; b=rIWC7rCpsAEful4pkeG008NbAgYhbHHvbF+0PsYecnuCfsviL5rKAyL6D5jxdfLMhZT1x3ffd2cW8099RXkWiZmKhv6ZJESCB3saQFB81OUS6gdSOi8SLLMJedCQDfIxwBTa4hepYDPREALG8pls60JqLlk3vSuGUcrW8aTBNlw= Received: from BY5PR11MB4196.namprd11.prod.outlook.com (2603:10b6:a03:1ce::13) by BYAPR11MB2760.namprd11.prod.outlook.com (2603:10b6:a02:c0::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.26; Tue, 23 Nov 2021 15:33:36 +0000 Received: from BY5PR11MB4196.namprd11.prod.outlook.com ([fe80::3dad:eeb0:be1c:b167]) by BY5PR11MB4196.namprd11.prod.outlook.com ([fe80::3dad:eeb0:be1c:b167%5]) with mapi id 15.20.4690.028; Tue, 23 Nov 2021 15:33:36 +0000 From: "Rob Wilton (rwilton)" To: Kent Watsen CC: Dan Romascanu , "last-call@ietf.org" , "ops-dir@ietf.org" , "draft-ietf-netconf-sztp-csr.all@ietf.org" , "netconf@ietf.org" Thread-Topic: [Last-Call] [netconf] Opsdir last call review of draft-ietf-netconf-sztp-csr-11 Thread-Index: AQHX3VzmFld5pMSM+0SuUbD0sK8r0qwPwrYAgAEb33CAAGFxAIAAA3Pg Date: Tue, 23 Nov 2021 15:33:36 +0000 Message-ID: References: <163733688535.10662.12846915795187697217@ietfa.amsl.com> <0100017d487f0f15-c299535d-2006-4dde-9b36-4799849666c0-000000@email.amazonses.com> <0100017d4d608976-11759577-0c2e-4efb-bc34-3da1d8ad2bcb-000000@email.amazonses.com> In-Reply-To: <0100017d4d608976-11759577-0c2e-4efb-bc34-3da1d8ad2bcb-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8cd1b420-911b-47d2-0538-08d9ae969db2 x-ms-traffictypediagnostic: BYAPR11MB2760: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ilfgGx8xz2kNUKVi1XYRScE0HX992hFg/G6/IxJU3sBMUMZlFSEThnfhVTMFKY6Fd/y3NnB6L8vntyYBXoU/33zz2mTe3dfZAtes8hUxpsSMSGCdXCXx99hFzf/YP3HiYg9t3rzdSjWfuFxBeNjkaJnYhm8qTT+PO0/twu6bYmB1RxpZq3smcDaOr646GwLDenVl07+Ruw2BBWVZ1nvwDLS9RtAaCM+t9074D/FNk3TttMXFZaG4EmpVWSXSzz7mHSTIpT5qttilZI7vPFrLkHc4ga2CJjAIgPsFt0HNAdQYqo5xC9w/QsmtyN4lEsPZRWSwpOF/qX0mh5JZC1h4YfMf+n5zUi1DrlFlnKt7u/kM3d9+N168rmSLga40PQGvqmBU6zGR8dnUCtnVjWUV2gKykTMdFMFl7mdX+/vijdC96jP64LHB4wqtm2ieO1U49z8d2zS1rjwZMGC+uEI3OjbHf32vHlvi6a4cnqXOgMUhYu+lkg40Q6dkwZPlD9J9F9m9Z4FofhByrYh+iup0VKBp08WYD/cuF9+k2szCeKwqCuC8+BNDmeKFibtIBXjrbRMgapunVYXYN33U4ruiLHAz3QxugZdSsvx7yavAXaobHsLK3EVgzp9UV+IyHmWXFgJmWhOEdx0Vx3xzweP77u5WEu8bkqMCKiEPyaKWbt/7/HIgJkxAELllP6MW0vU3zSrcx5hjipkfDA6tjonFpuuykTnUyzVxprc0tBNsvij64eePYTdnfWsa1fSvJsebiOVyfHscqBC9W2Z0jP2xfXqbwQ1m/o3MM4Dgjniz9Ct5Uh/C1M9x2cvGRTGSBK2pna7gAZDCbHrjBoSqXvoANQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4196.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(53546011)(7696005)(6506007)(186003)(316002)(83380400001)(52536014)(6916009)(8676002)(966005)(33656002)(66946007)(26005)(66476007)(71200400001)(9326002)(9686003)(8936002)(2906002)(38070700005)(508600001)(66556008)(38100700002)(122000001)(166002)(66446008)(4326008)(54906003)(76116006)(64756008)(5660300002)(86362001)(55016003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dS9mUktZTExkcktXWUpPTWpHY0RKbTh0b0UxeXg2eVc5dWZtTkIvYU1IV0M2?= =?utf-8?B?b3dkRThPTHdoOTVMemI5aVJtdEVUNnIrVnpwR1hpUXg2MmR3aWgrRDhGcVNp?= =?utf-8?B?YU9ScE1jVEEzQU9ZVUZqT1pwcWxsU3ROUXd4RG85T2Q4R2xiUTFDZ3Fsczln?= =?utf-8?B?UnVqK0xyWHdkWjFVTVV4UEprS2RFZk5TWFNZdFp4UjlvcU9ULyt1d1o4Z1lp?= =?utf-8?B?UEtpcnZ5NUhxN0J4WTZrZEFUSi9jZFplNGpFQTNKMjV4cVZCWC9yQlVTT2l2?= =?utf-8?B?bmdFaE9iWlY1Mm90Rm8wOHhZOFU3ekdLTjBpSHpDMko4S2JNYWkybFpta2VY?= =?utf-8?B?bVVVQm80NmU2L2o4T21DRWRSTTgybXF2dEQySmFTR1VOclA1UmpNTXJKeW9P?= =?utf-8?B?RFdZVHBTSFo3L0VKbVlFeU9MbnZiNUhKak5YNC80UGZFdlBETDROR01GNDh0?= =?utf-8?B?L2tvSnhsd1YwRkJQeTdzeXorVUxPTnFaNEtNRG9Wc0E5bWhOazQ0QWl3Q2NO?= =?utf-8?B?c3YyRjFkZFVwbTNma2dpWEFZR0hNOW1HcFJ5VHRMb3lTZG9SNUtibUYyS1pW?= =?utf-8?B?RXJsUHdLWVdxZEtYNVdLR3ZaYWplSHF5VS9Ta1BRMWF2Qnd3VDE1bE1LREsx?= =?utf-8?B?NjNqNit2blQvVWNJYm5ZSzdQR2RPa2Y4Z0hoM3gwT3ZFMWIzZXNrUzJteGFM?= =?utf-8?B?YXkzS0RCMXRVSXZpa3JoV2VSb05IZFR2QkUvUlFPei9HWDJBU0g4UlpYS2c3?= =?utf-8?B?bUs5TjlmdlZuTnV3S1RWb3diOS84NDA1SmQwa2pwanNHSkZ3VnVmTWgzb3JE?= =?utf-8?B?SjQ4Yy9neDlmZnFMNGhQNVpkZjNkNnZ6SFpPakVpNDUxZGs0VU9FNkZ6Q29G?= =?utf-8?B?VHlIV1R5cjJXcTMvUmRpT1E5cFB0ZXl5Qjhnc3dRb2VPTzRIeEM5eFZiaXZC?= =?utf-8?B?aFY3SGNHMXUvRDlkOThlcDdVN3NWcTRHWnQxV1lXbEVBOXQ5L3lReW1kZXp3?= =?utf-8?B?SlZpUmVmWThOTFRjZk1hRUtmcE1DSDBOWGlaQ0Jsb0o5cTNQMXAwQS83aUds?= =?utf-8?B?NDZDN2k5V3kzV3kxVllQVkRuTWFIcDI2c0RPaXFHdS9oYjRha1dxSjB0amhG?= =?utf-8?B?OVlpYTFJRGJEbE9OOVR2cWpqQWVVMEo1UzUvRTJMRUlXeGVuRTlyelVTMm41?= =?utf-8?B?L1JCM2xFeEFHbHJEUnRqdGk1Y2NJb0lROHRHcmdxV0lpYVBRbnJyWExiWWFm?= =?utf-8?B?Y3RjUlg4NGF5WXhGaW4xNll2UkVyYTFOejZQQkw1SllUL2NHamQyd1BsU0hw?= =?utf-8?B?WFZweGwyb2xHemRYOUJTcmE0MXBJd0RlTnNhaWxBUUwvVlo5eHJSNC9iYTY4?= =?utf-8?B?aXFId3pmclE1Tk16VnlBd0wzTUNSbnFQTmVTNTdJdXExWkZSRmt5VzlNTCth?= =?utf-8?B?cFF2MG9EWWxpZFd3K0VPU080RitqZ01kUGtBS1BoY25EMlg4TllOdnJGV1o5?= =?utf-8?B?N3Aya0xvdkZZYW43RUR6bFVxNVo5N2g0QkRUNDFjWXd0Y0lVbXBxQ0RCRmZj?= =?utf-8?B?UVpYNXpOMyt6TERGSHNkNFRwS21rWk1aOFV5Q0d4VkdjRDlWUHFjcE55KzZh?= =?utf-8?B?QUhtOUllQkRDZ1dVVkErTHV4VkVuUENRcHNRcnBhcTRLaFBiWmJPSWlpeTMy?= =?utf-8?B?K0J2ODYrRWFhUmh6dDg4SHVsdnlvL2dCWDl5YngyWnFHMmVwNENjNFJKaEt5?= =?utf-8?B?bHNJd0l0TC9LRTlBMUJaSm1NdmVvdXJ2bDVYaTBOWXFFL044dnZCL00rbCtz?= =?utf-8?B?Snl1S01DUW9ZZDRteUJsSmcvNUVSdE5ieTBnNzRvV21BSmZSRnBBY1Rma2hV?= =?utf-8?B?N25ZSVB4aGtkUWlaeVprUU1QeHM1dk95dWdqMUgxVTFLWmZ3UFN6VGh1NnZP?= =?utf-8?B?aVpEbXlYTkJiRm01N0ZPMFB2QndiTUx4dnRQcmRpeHNpM2NGbU5jZ2tPci9P?= =?utf-8?B?cVBGV1pvTTNvWG1UOWl3NTFGc1ZWV2dZc3lucXhiTG5SS3F2bFA0WlY4ZVY3?= =?utf-8?B?QlVrK3JLN0dHelAwUVpVUHoyT29SVkNFdmhZbXZGWldqNVdkY1ROL3lWSGlr?= =?utf-8?B?aHZtQ3hSbkdkV1ZNK1kwM050YnpxbldoZnNVTnlhbzlkdjdTNDdrNmlCbjB3?= =?utf-8?Q?qUDoVrzfYKk+ovAcpimz6x4=3D?= Content-Type: multipart/alternative; boundary="_000_BY5PR11MB4196BF6ED097584FA88CED11B5609BY5PR11MB4196namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4196.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8cd1b420-911b-47d2-0538-08d9ae969db2 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2021 15:33:36.2353 (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: IUG9PzuniSCjnYlMnGlsd9MVSkF4sC8zly3yfCZy2KG29ZbCdBCmt9y0LNqnCQ7K2ntQ0O1UFOFT7Ht1OzG1yQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2760 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xbe-rcd-005.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [netconf] [Last-Call] Opsdir last call review of draft-ietf-netconf-sztp-csr-11 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, 23 Nov 2021 15:33:47 -0000 --_000_BY5PR11MB4196BF6ED097584FA88CED11B5609BY5PR11MB4196namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2VudCwNCg0KQWxsIGZpbmUsIGFzIHBlciBpbmxpbmUgYmVsb3cg4oCmDQoNCkZyb206IEtl bnQgV2F0c2VuIDxrZW50QHdhdHNlbi5uZXQ+DQpTZW50OiAyMyBOb3ZlbWJlciAyMDIxIDE1OjE5 DQpUbzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPg0KQ2M6IERhbiBS b21hc2NhbnUgPGRyb21hc2NhQGdtYWlsLmNvbT47IGxhc3QtY2FsbEBpZXRmLm9yZzsgb3BzLWRp ckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1uZXRjb25mLXN6dHAtY3NyLmFsbEBpZXRmLm9yZzsgbmV0 Y29uZkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtMYXN0LUNhbGxdIFtuZXRjb25mXSBPcHNkaXIg bGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLW5ldGNvbmYtc3p0cC1jc3ItMTENCg0KSGkg Um9iLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgaW5wdXQuICBQbGVhc2Ugc2VlIGJlbG93IGZvciBy ZXNwb25zZXMgdG8geW91ciBjb21tZW50cy4NCg0KS2VudA0KDQoNCg0KV2hpY2ggb3B0aW9uIHNl ZW1zIGJlc3Q/ICBEb2VzIGFueW9uZSBoYXZlLiBwcmVmZXJlbmNlPw0KDQpJIGRvbuKAmXQgdGhp bmsgdGhhdCB3ZSBzaG91bGQgZG8gKDEpLiAgSWYgdGhlIGluZHVzdHJ5IHdpZGVseSB1bmRlcnN0 YW5kcyBJRGV2SUQvTERldklEIHRvIG1lYW4gODAyLjFBUiB0aGVuIHJlZGVmaW5pbmcgaXQgaW4g dGhpcyBkcmFmdCB0byBoYXZlIGEgd2lkZXIgbWVhbmluZyBjb3VsZCBqdXN0IGJlIGNvbmZ1c2lu ZyB0byByZWFkZXJzLg0KDQpBZ3JlZWQuDQoNCg0KDQpTbyBJIHRoaW5rIHRoYXQgdGhlIGRyYWZ0 IGhhcyBicm9hZGx5IGdvdCB0aGlzIHJpZ2h0IGluIGl0cyBjdXJyZW50IGFwcHJvYWNoLCBidXQg SSB3b3VsZCBwcm9wb3NlIGFsc28gZXh0ZW5kaW5nIHRoYXQgdG8gdGhlIFlBTkcgbW9kdWxlIGRl c2NyaXB0aW9ucy4NCg0KQWdyZWVkLg0KDQoNCg0KU3BlY2lmaWNhbGx5LCBJIHdvdWxkIHN1Z2dl c3QgYWRkaW5nIGEgdmVyc2lvbiBvZiB0aGlzIHBhcmFncmFwaCB0byB0aGUgZW5kIG9mIHRoZSBk ZXNjcmlwdGlvbnMgb2YgY21jLWNzciBhbmQgY21wLWNzciwgd2hpY2ggYWxyZWFkeSBoYXZlIHF1 aXRlIGxvbmcgZGVzY3JpcHRpb25zLCBzbyB0aGUgZXh0cmEgcGFyYWdyYXBoIHNob3VsZG7igJl0 IHJlYWxseSBiZSBhIHByb2JsZW0uDQoNCiAgICAgICAgVGhlIHRlcm1zICdJRGV2SUQnIGFuZCAn TERldklEJyBhcmUgdXNlZCBoZXJlaW4gdG8NCiAgICAgICAgbWVhbiAnaW5pdGlhbCBkZXZpY2Ug aWRlbnRpZmllcicgYW5kICdsb2NhbCBkZXZpY2UNCiAgICAgICAgaWRlbnRpZmVyJy4gIFRoZXNl IHRlcm1zIGFyZSBkZWZpbmVkIGNvbnNpc3RlbnQgd2l0aA0KICAgICAgICB0aGUgSUVFRSA4MDIu MUFSIHNwZWNpZmljYXRpb24sIHRob3VnaCB0aGVyZSBpcyBubw0KICAgICAgICByZXF1aXJlbWVu dCB0aGF0IGEgWlRQLWNsaWVudCdzIGlkZW50aXR5IGNlcnRpZmljYXRlDQogICAgICAgIGNvbmZv cm0gdG8gSUVFRSA4MDIuMUFSLg0KDQoNCllpa2VzISAgIEFmdGVyIHNlbmRpbmcgdGhlIHJlc3Bv bnNlIHRvIERhbiwgSSBkZWNpZGVkIG9uIG9wdGlvbiAyIChleHBhbmRpbmcgYWxsIHRoZSBJRGV2 SUQvTERldklEIHVzYWdlcykuICBJbiBteSByZXNwb25zZSB0byBZYXJvbiB5ZXN0ZXJkYXkgSSB3 cm90ZToNCg0KICAgICAgICAgICAgICBXZSB1cGRhdGVkIHRoZSBZQU5HIG1vZHVsZSB0byBncmVh dGx5IHJlbW92ZSByZWZlcmVuY2VzIHRvIElEZXZJRC9MRGV2SUQuDQoNCiAgICAgICAgICAgICAg U3BlY2lmaWNhbGx5Og0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxKSBzL0lEZXZJRC9p bml0aWFsIGRldmljZSBpZGVudGl0eSBjZXJ0aWZpY2F0ZS9nDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDIpIHMvTERldklEL2xvY2FsIGRldmljZSBpZGVudGl0eSBjZXJ0aWZpY2F0ZS9n DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgMykgbWFudWFsbHkgcmV3cmFwIGxpbmVzIHRv IGNvbCA2OSBhcyByZXF1aXJlZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICA0KSByZW1v dmVkIHRoZSB0ZXJtaW5vbG9neS1kaXNjbGFpbWVyIGJsb2NrIGF0IHRvcA0KDQogICAgICAgICAg ICAgIFRoZSBkaWZmIGlzIGhlcmU6IGh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3N6dHAt Y3NyL2NvbW1pdC9hYzM1Zjk2ZWVjOTY1MjhkZGRmNTc5OGQ1MjhkOTg3NGE4NWM2MDRiDQoNCiAg ICAgICAgICAgICAgR29vZD8NClRoaXMgaXNu4oCZdCB3aGF0IHlvdSBzdWdnZXN0LCBidXQgaXTi gJlzIHF1aXRlIGdvb2QsIG1heWJlIGJldHRlcj8gICBZb3VyIGFwcHJvYWNoIHNlZW1zIGxpa2Ug aXQgd291bGTigJl2ZSBiZWVuIG1vcmUgY29udmVuaWVudCBidXQsIGdpdmVuIHRoYXQgaXQgaXMg d2hhdCBpdCBpcyBub3csIGFyZSB5b3Ugb2theSB3aXRoIHRoZSBjdXJyZW50IGVkaXQ/ICBbUFM6 IEkgaGF2ZW7igJl0IHBvc3RlZCBhbiB1cGRhdGVkIGRyYWZ0IHlldCBhcyBJ4oCZbSB3YWl0aW5n IHRvIGNvbXBsZXRlIHRoZSByZXZpZXdzIHdpdGggWWFyb24gYW5kIERhbiBmaXJzdF0NCg0KWWVz LCB3aGF0IHlvdSBoYXZlIGRvbmUgaXMgcHJvYmFibHkgYmV0dGVyIOKAkyBzaW5jZSBpdCBtYWtl cyBpdCB1bmFtYmlndW91cy4NCg0KDQpJIHdvdWxkIHN1Z2dlc3QgY2hhbmdpbmcgdGhlIGRlc2Ny aXB0aW9uIGluIGNlcnQtcmVxLWluZm8gdG8g4oCcKGUuZy4sIGFuIElEZXZJRCBmcm9tIElFRUUg ODAyLjFBUinigJ0NCg0KDQpEb25lISBodHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy9zenRw LWNzci9jb21taXQvNDVhY2U5YjQwZWVkYWJiODRlMTA2MDc1OTJkMjkxNDZjYjU0YTljOQ0KDQpU aGFua3MsDQpSb2INCg0KDQpSb2INCg0KSy4NCg0KDQoNCg0KDQo= --_000_BY5PR11MB4196BF6ED097584FA88CED11B5609BY5PR11MB4196namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmFwcGxlLXRhYi1zcGFuDQoJe21zby1z dHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0id29y ZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkg S2VudCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+QWxsIGZpbmUsIGFzIHBlciBpbmxpbmUgYmVsb3cg4oCmPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyI+IEtlbnQgV2F0c2VuICZsdDtrZW50QHdhdHNlbi5uZXQmZ3Q7DQo8YnI+ DQo8Yj5TZW50OjwvYj4gMjMgTm92ZW1iZXIgMjAyMSAxNToxOTxicj4NCjxiPlRvOjwvYj4gUm9i IFdpbHRvbiAocndpbHRvbikgJmx0O3J3aWx0b25AY2lzY28uY29tJmd0Ozxicj4NCjxiPkNjOjwv Yj4gRGFuIFJvbWFzY2FudSAmbHQ7ZHJvbWFzY2FAZ21haWwuY29tJmd0OzsgbGFzdC1jYWxsQGll dGYub3JnOyBvcHMtZGlyQGlldGYub3JnOyBkcmFmdC1pZXRmLW5ldGNvbmYtc3p0cC1jc3IuYWxs QGlldGYub3JnOyBuZXRjb25mQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTGFz dC1DYWxsXSBbbmV0Y29uZl0gT3BzZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1u ZXRjb25mLXN6dHAtY3NyLTExPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+SGkgUm9iLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ VGhhbmsgeW91IGZvciB5b3VyIGlucHV0LiAmbmJzcDtQbGVhc2Ugc2VlIGJlbG93IGZvciByZXNw b25zZXMgdG8geW91ciBjb21tZW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+S2VudDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPldoaWNoIG9wdGlvbiBzZWVtcyBiZXN0PyAmbmJz cDtEb2VzIGFueW9uZSBoYXZlLiBwcmVmZXJlbmNlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij5JIGRvbuKAmXQgdGhpbmsgdGhhdCB3ZSBzaG91bGQgZG8gKDEpLiZuYnNwOyBJ ZiB0aGUgaW5kdXN0cnkgd2lkZWx5IHVuZGVyc3RhbmRzIElEZXZJRC9MRGV2SUQgdG8gbWVhbiA4 MDIuMUFSIHRoZW4gcmVkZWZpbmluZyBpdCBpbiB0aGlzIGRyYWZ0IHRvIGhhdmUgYSB3aWRlciBt ZWFuaW5nIGNvdWxkIGp1c3QgYmUgY29uZnVzaW5nIHRvIHJlYWRlcnMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+QWdyZWVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPlNvIEkgdGhpbmsgdGhhdCB0aGUgZHJhZnQgaGFzIGJyb2FkbHkgZ290IHRoaXMgcmln aHQgaW4gaXRzIGN1cnJlbnQgYXBwcm9hY2gsIGJ1dCBJIHdvdWxkIHByb3Bvc2UgYWxzbyBleHRl bmRpbmcgdGhhdCB0byB0aGUgWUFORyBtb2R1bGUgZGVzY3JpcHRpb25zLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPkFncmVlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5TcGVjaWZpY2FsbHksIEkgd291bGQgc3VnZ2VzdCBhZGRpbmcgYSB2ZXJz aW9uIG9mIHRoaXMgcGFyYWdyYXBoIHRvIHRoZSBlbmQgb2YgdGhlIGRlc2NyaXB0aW9ucyBvZiBj bWMtY3NyIGFuZCBjbXAtY3NyLCB3aGljaCBhbHJlYWR5IGhhdmUgcXVpdGUgbG9uZyBkZXNjcmlw dGlvbnMsIHNvIHRoZSBleHRyYSBwYXJhZ3JhcGggc2hvdWxkbuKAmXQgcmVhbGx5IGJlIGENCiBw cm9ibGVtLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6OC4wcHQg OC4wcHQgOC4wcHQgOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjcuOXB0O21hcmdp bi1sZWZ0OjM2LjBwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBUaGUgdGVybXMgJ0lEZXZJRCcgYW5kICdMRGV2SUQnIGFyZSB1c2VkIGhlcmVpbiB0 bzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo3LjlwdDtt YXJnaW4tbGVmdDozNi4wcHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxs Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgbWVhbiAnaW5pdGlhbCBkZXZpY2UgaWRlbnRpZmllcicgYW5kICdsb2NhbCBk ZXZpY2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206Ny45 cHQ7bWFyZ2luLWxlZnQ6MzYuMHB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFr LWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGlkZW50aWZlcicuJm5ic3A7IFRoZXNlIHRlcm1zIGFyZSBkZWZpbmVk IGNvbnNpc3RlbnQgd2l0aDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2lu LWJvdHRvbTo3LjlwdDttYXJnaW4tbGVmdDozNi4wcHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQt YnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIElFRUUgODAyLjFBUiBzcGVjaWZpY2F0aW9u LCB0aG91Z2ggdGhlcmUgaXMgbm88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21h cmdpbi1ib3R0b206Ny45cHQ7bWFyZ2luLWxlZnQ6MzYuMHB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3 b3JkLWJyZWFrOmJyZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlcXVpcmVtZW50IHRoYXQgYSBaVFAtY2xp ZW50J3MgaWRlbnRpdHkgY2VydGlmaWNhdGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6 MGNtO21hcmdpbi1ib3R0b206Ny45cHQ7bWFyZ2luLWxlZnQ6MzYuMHB0O2JhY2tncm91bmQ6I0ZG RkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbmZvcm0gdG8gSUVFRSA4MDIu MUFSLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij5ZaWtlcyEgJm5ic3A7IEFmdGVyIHNlbmRpbmcgdGhlIHJlc3BvbnNl IHRvIERhbiwmbmJzcDs8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkkgZGVjaWRlZCBvbiBvcHRp b24gMiAoZXhwYW5kaW5nIGFsbCB0aGUgSURldklEL0xEZXZJRCB1c2FnZXMpLiAmbmJzcDtJbiBt eSByZXNwb25zZSB0byBZYXJvbiB5ZXN0ZXJkYXkgSSB3cm90ZTo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDow Y207bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGNsYXNz PSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5XZSB1cGRhdGVk IHRoZSBZQU5HIG1vZHVsZSB0byBncmVhdGx5IHJlbW92ZSByZWZlcmVuY2VzIHRvIElEZXZJRC9M RGV2SUQuPGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPC9zcGFuPlNwZWNpZmljYWxseTo8YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUt dGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8L3NwYW4+MSkgcy9JRGV2SUQvaW5pdGlhbCBkZXZpY2UgaWRlbnRpdHkgY2VydGlm aWNhdGUvZzxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4yKSZuYnNwO3Mv TERldklEL2xvY2FsIGRldmljZSBpZGVudGl0eSBjZXJ0aWZpY2F0ZS9nPGJyPg0KPHNwYW4gY2xh c3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDwvc3Bhbj4zKSBtYW51YWxseSByZXdyYXAgbGluZXMgdG8gY29sIDY5IGFzIHJlcXVp cmVkPGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjQpIHJlbW92ZWQgdGhl IHRlcm1pbm9sb2d5LWRpc2NsYWltZXIgYmxvY2sgYXQgdG9wPGJyPg0KPGJyPg0KPHNwYW4gY2xh c3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPlRoZSBkaWZm IGlzIGhlcmU6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvc3p0 cC1jc3IvY29tbWl0L2FjMzVmOTZlZWM5NjUyOGRkZGY1Nzk4ZDUyOGQ5ODc0YTg1YzYwNGIiPmh0 dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3N6dHAtY3NyL2NvbW1pdC9hYzM1Zjk2ZWVjOTY1 MjhkZGRmNTc5OGQ1MjhkOTg3NGE4NWM2MDRiPC9hPjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJh cHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5Hb29kPzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+VGhpcyBpc27igJl0IHdoYXQgeW91IHN1Z2dlc3QsIGJ1dCBpdOKAmXMg cXVpdGUgZ29vZCwgbWF5YmUgYmV0dGVyPyAmbmJzcDsgWW91ciBhcHByb2FjaCBzZWVtcyBsaWtl IGl0IHdvdWxk4oCZdmUgYmVlbiBtb3JlIGNvbnZlbmllbnQgYnV0LCBnaXZlbiB0aGF0IGl0IGlz IHdoYXQgaXQgaXMgbm93LCBhcmUgeW91IG9rYXkgd2l0aCB0aGUgY3VycmVudCBlZGl0PyAmbmJz cDtbUFM6IEkgaGF2ZW7igJl0DQogcG9zdGVkIGFuIHVwZGF0ZWQgZHJhZnQgeWV0IGFzIEnigJlt IHdhaXRpbmcgdG8gY29tcGxldGUgdGhlIHJldmlld3Mgd2l0aCBZYXJvbiBhbmQgRGFuIGZpcnN0 XTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIHdoYXQgeW91IGhhdmUgZG9uZSBpcyBwcm9i YWJseSBiZXR0ZXIg4oCTIHNpbmNlIGl0IG1ha2VzIGl0IHVuYW1iaWd1b3VzLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SSB3b3VsZCBzdWdnZXN0IGNoYW5n aW5nIHRoZSBkZXNjcmlwdGlvbiBpbiBjZXJ0LXJlcS1pbmZvIHRvIOKAnChlLmcuLCBhbiBJRGV2 SUQgZnJvbSBJRUVFIDgwMi4xQVIp4oCdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5Eb25lISZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZ2l0aHVi LmNvbS9uZXRjb25mLXdnL3N6dHAtY3NyL2NvbW1pdC80NWFjZTliNDBlZWRhYmI4NGUxMDYwNzU5 MmQyOTE0NmNiNTRhOWM5Ij5odHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy9zenRwLWNzci9j b21taXQvNDVhY2U5YjQwZWVkYWJiODRlMTA2MDc1OTJkMjkxNDZjYjU0YTljOTwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Um9iPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlJvYjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPksuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BY5PR11MB4196BF6ED097584FA88CED11B5609BY5PR11MB4196namp_-- From nobody Tue Nov 23 21:35:29 2021 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 3760C3A0BB5; Tue, 23 Nov 2021 21:35:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Meral Shirazipour via Datatracker To: Cc: draft-ietf-netconf-sztp-csr.all@ietf.org, last-call@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163773212617.25289.11973969487179870918@ietfa.amsl.com> Reply-To: Meral Shirazipour Date: Tue, 23 Nov 2021 21:35:26 -0800 Archived-At: Subject: [netconf] Genart last call review of draft-ietf-netconf-sztp-csr-11 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: Wed, 24 Nov 2021 05:35:26 -0000 Reviewer: Meral Shirazipour Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-netconf-sztp-csr-11 Reviewer: Meral Shirazipour Review Date: 2021-11-23 IETF LC End Date: 2021-11-23 IESG Telechat date: NA Summary: This draft is ready to be published as Standards Track RFC. Major issues: Minor issues: Nits/editorial comments: [Page 3], Section 1.1 "bootstraped"->"bootstrapped" From sergio.gutierrezbe@unaula.edu.co Tue Nov 23 22:50:02 2021 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 B5A153A0C1A for ; Tue, 23 Nov 2021 22:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MISSING_HEADERS=1.021, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=unaulaedu.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DkbW6GsJz4q for ; Tue, 23 Nov 2021 22:49:58 -0800 (PST) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2103.outbound.protection.outlook.com [40.107.93.103]) (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 ECF653A0C18 for ; Tue, 23 Nov 2021 22:49:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XmuTmn7pyhimvbj23ZSIXgBL436MrMOVan2hUe6FiKVSoA/8KDfXAzNV/Lvmkd3FZlhKFYV+H618Md8qw172+5EdN/NhCa3kDq1dbrkEfJAGYFBpF3G4107eTpNRtVgtp6RUyuR1+h3PCOZORb0aoZAWSZkk/fkgV7DjVW+cXNPwu/PNKt9h/1OGUNBnGmQpzZ08UquYlnnKlcQZCI6a9QllVKP8+OyRcN8QFJZB+woR2Ia/ivE5tIF4gMMWA1T3r7lDsVVxvRRp4wYVSXsPJs5hC9Sb9fbQ542B0vAvYkTHu2UbD18rWuc7fVbjTIfQUr9lrZZd7ZD9N+0h/FFqSw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5Ylyk0TLeD4Hn8LL6pAUCUfZ7eJKKyfal9McJdTCQ5k=; b=A+c6oGXkDclWJ1tiBndzr9IuagWLMS1GuDqNUipyPdMp2gj/8upus5SvUJWW1XGDMYBPzCnpozo2q+uKbcqRnwF2NI59p0T/piw5v7rsWxU1RWpHORCoemo6Y1Q39BJXE3ne3zd2R7uDpj1tDiUy9xrDO68Xn1nvhKYNmHuFe04alwsy4+RGzgRm/128rQ3Kv9Qznq9UZgo0sYdkHFuLMY+maRlJef4um1UoIce9VlErHbtNYiSeKjRwrbWyhOZcnnQx8Y2oClz7BYH9dRMnOMtCsrOTVlZfvhqjX/Ys0zOnRHRi2M1/ss9SYhyoh1b8/m1Q4idF/rImCvx3TYWEag== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=unaula.edu.co; dmarc=pass action=none header.from=unaula.edu.co; dkim=pass header.d=unaula.edu.co; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unaulaedu.onmicrosoft.com; s=selector2-unaulaedu-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5Ylyk0TLeD4Hn8LL6pAUCUfZ7eJKKyfal9McJdTCQ5k=; b=d0Z/UemzSFoCWc5EfisK9X8fnqLeoiqShNnVxwBpntHZufyofyGJ8GKdWJKSdFRy9KYzyN7zK04H8a27ysPBlHM9a3RRehEmgkerhrM7eAp5Av4CstT4p4aoLyPyqKBqhmYGjJwF/dNuU6QW37ba/pfYzWEdkwO95vURIAfszBg= Received: from DM8P220MB0567.NAMP220.PROD.OUTLOOK.COM (2603:10b6:8:26::22) by DM8P220MB0472.NAMP220.PROD.OUTLOOK.COM (2603:10b6:8:25::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4734.20; Wed, 24 Nov 2021 06:49:54 +0000 Received: from DM8P220MB0567.NAMP220.PROD.OUTLOOK.COM ([fe80::7446:9748:454f:d6c9]) by DM8P220MB0567.NAMP220.PROD.OUTLOOK.COM ([fe80::7446:9748:454f:d6c9%3]) with mapi id 15.20.4734.021; Wed, 24 Nov 2021 06:49:54 +0000 From: Sergio Armando Gutierrez Betancur CC: "netconf@ietf.org" Thread-Topic: =?utf-8?B?SUVFRS9JRklQIEFuTmV0IDIwMjIg4oCTIENBTEwgRk9SIFBBUEVSUw==?= Thread-Index: AQHX4P980DhEpghQ+02HGjebxcx91w== Date: Wed, 24 Nov 2021 06:49:53 +0000 Message-ID: <8840566.zQ0Gbyo6oJ@eos> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=unaula.edu.co; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d1d7d293-940b-42e6-68b1-08d9af169eee x-ms-traffictypediagnostic: DM8P220MB0472: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: TvIP16JEa933MmhpOC6pUnl9Cy5ZZCl6OcyDpVMvmCVmNpAl4nfu2AytxOzclt8zPIEXHbobe7IaHGo7KhsGqGIuVLdtP7IS8ji45V+rQ/lkYknEmivqRsvtlhXGaQ//5iiRGtgGOAAXJhay4L4AOg1g/Now7nIIPbtnMeZO5xfxROhmSm3IH6vaVVA2ljgwj1XE3ynB8Pyvd9/2lkooMRqzIX+HTHuWL6BuC3a4PBKp1R26TMdA2h/F50qMd4d9ZfQrZl/CkDepA4BXucAZYT6tkunUHoJyA7oqNw8YDmHrjSOXCshFYSNZC3Z/1qQ/+ijcxWKdgVC6iVGdyqyqtM8r16t71OfZ02t7H3U4FlqcDf+ChBZ6lvgeQ5jWOPUdK6s6DxODfkA0OekfeHKy9Sggk1TuLUEIX5mXpKPINTW15f9WHXFA7AtawdB9YXgWWJCHBaEkDnQvp/+3ps6kE4RMdfrdHtK0XcOZm6kux1pRnfWIdhEG1fk0c0tlzUvSNSNWJ7Ren4r7wqcH5zp+PfD1Ikz9wBz1/qPv0ca/nQBu9Lpp+xal6XW9fdSSrt04JKK0kbulr0A2uDkXzsG19ClqeH356J6RW0evos5vacqIgxubSGrIGqEsFTaaHgnm2eeUvBJuOETxuHSqsG+BFbUGq8w4rPdJjW9i4T28dJsY78EmItbyjEZy2K3uX91vO5rDCOxKsxzm1K7I9lTd17PCmyTc8aPMP0x9KQaqxmRLdgVu3DWV9uNbL8fcM+V6EP2COcmrV21t2cGhd6f6f2CgETwC7ByHH4iq0y7fFDZDJbZigjBUjx6tvnlCudIS x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM8P220MB0567.NAMP220.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(6029001)(7916004)(366004)(316002)(786003)(66574015)(71200400001)(38070700005)(38100700002)(2906002)(26005)(186003)(4326008)(64756008)(8936002)(508600001)(76116006)(91956017)(966005)(83380400001)(66446008)(66946007)(6506007)(109986005)(5660300002)(122000001)(33716001)(6486002)(86362001)(66476007)(66556008)(6512007)(9686003)(39026012)(225293002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?YTJFMXZQR1QzN3l1YmhSdjFrTXQvcmJCMVR2d09XTk9GWXlIZGlJMEtNaTk0?= =?utf-8?B?MHFFRVhTcTF3RDI5MG5nV254ZDEyRzFXaW1iTjFYakJRdWM4cVJwMnpPbmxN?= =?utf-8?B?U1lEY0NheTdBZ2huWEJGVjR1a3JpKzY4MFJOakY3UFlDRytDRTNKdUowblBI?= =?utf-8?B?U1hOZlg0STVQdnN1NFIvV0hIVDdyT0d1Q1NudjJoaW9mbVFrbmdOU3VCRXNE?= =?utf-8?B?NzdTbXYvYkdRY3NhWmhkOFFKbTdDWWRSSm5DYUo3ektQRjNrNzdiUXB0S0lD?= =?utf-8?B?dWNWYTAvRG93U0dQNmtZWC9sdlhIanJJcDNVcWNaNmZPOU5aT2hHbGdlL2NJ?= =?utf-8?B?Q0NJQWtZcUZCU21JZERqRklZd01lcERVa2hHdHJrVHhaay80OUZKRDc0NUhF?= =?utf-8?B?M0xjaHFyWnVmOE84NXZFSHBsc0c4Q2J4NHk1aDBMbE45dWNRaFh5Wjh1ZkZZ?= =?utf-8?B?eWtURGkrQ2htSElMa0pLTVBjdzdMR0FHbC9VWm1EYnRGNVBxQlJKQ1k0dVY1?= =?utf-8?B?dWo1dFNBR0t6K201Um5yR0c2U3JVQmdCU20wSlFwanorWGE4TkFXNDA4Y1dz?= =?utf-8?B?WUcxYjRtMzU5MFFoNGxnYmNNekxGdmpkTDlkWi9Ed1Z0VHVxZll0MFJ1RTc4?= =?utf-8?B?Zi96RU1DRmlQdUlSZXhUMmpXdWdSc3NZZ09oQk82VkMrK1JiV3ZCQk1KbmF5?= =?utf-8?B?c29CRmdVRlgyZmtMUzl3K05QbkpyZmgxa04zanhGQVArSlNvNlRBNkpoTERD?= =?utf-8?B?a2JLVmx4NXA1Mk4zMG8yVnF4ay9OcEpCcHdCWGNLLzcyc1VUYVJkSTlUcmJw?= =?utf-8?B?dlF4bjNOTDc3M2QwbWxnUXVQdXN1S2l0S3hnbW1YRVYyaEZnVzYzYm5IREkv?= =?utf-8?B?ZFZpZFhPOHk0bEJYVStWODFmWmtTVC9kZGlUWWovb0FnV3I0NFhlTjI1cGJH?= =?utf-8?B?dXlGWGM1U1VBT1NGV1NwbUhXQ0s5dG9PUDBXWWdVcE1uSDdRZ0FmNVZZMTNy?= =?utf-8?B?eU52dGlMRkZYaGZES1Z0WUJXL3ZnNVN3eU1admtXK0dGZWV6bVFmbnlrN3dI?= =?utf-8?B?UHVNZlZOcm1yQ2k5RzdwVlpwWkxpTjI1dHIvSlo1SEV0RngxZDVQRTU3OGVM?= =?utf-8?B?T3grL3VoSkNTd3lUYzhaTTBCVGJ6czFmZUJCdE1zT3N6M0VtNm54bVBoZnVV?= =?utf-8?B?SFd2empEeEtqQU50RXZ3WGJrM3lnNHpRcS9pMUpiYnhoUGQrc2lzWXZRL3Er?= =?utf-8?B?L0NES3d5cldSUVFJUEpydU1sS1lsT1RqSTFycW45TXdNc0JoN0ZjT2JQeXhz?= =?utf-8?B?QmR6N3M1RXRWMkJMMzVjQURZVktpVWxqQ0hRV01XNTdPdlVHQUJZa3BCQlBk?= =?utf-8?B?dVkrbzcwRmtZdlQ4QXRxRG8wWkhGNkxkSk1MdnhqdER4WnljMDYxVmNUMlNm?= =?utf-8?B?eTlrWUlMUEZaaTZCOWJsdGZWR2lWTlpPakRldFVLQVI0UXZoMHVhU2FaRUFn?= =?utf-8?B?RDl6NWZoVlpvVXJTeVdvK3JNK1pHb1JVMzhLTWQ3TzNyc1R1bkZlWnpBOXFD?= =?utf-8?B?R0hBc1FyMmZqTDF1cThMZXNMVzc3SDVJMGRxazhITC9zNlFZRjVHWTVUZmda?= =?utf-8?B?STF6bElSK29aQmd6TEFnVUtOTEtqK3ltL241dmJUUnRHenBYU1BZMEtldDBi?= =?utf-8?B?YVR5SWRESzlqZkpkT3hPb2NCWXJNNlNtRmZqQ2NabmE2M2J1NDhTN25YNlBO?= =?utf-8?B?Mjl4RnUvUThpSzEwTThiZmw4S3ZRMHFndEFmK0NyM3pPQi9XOUpRUVRWZU9E?= =?utf-8?B?UDJlVk5RT1pxNzFhODNuRXhoSldhV21naEd3MW8zSCszSnA3Vi9sdjk4dkVL?= =?utf-8?B?N1d2b3I2UHMvWThtQzJQUHZnWjBnemNRbGcyZzl1aExsZ1MzVk40RlY0K1c5?= =?utf-8?B?SHY1SmtUQU1YZGJUTllFWXNaak0rQ1N1TSswSzBMMFY2TklEVC9NUjk4LzVO?= =?utf-8?B?L1JRWFByYU1uRkozdndyMFZZbnVrdUNuMGtCeEtmZzFrSXQwTWpBRzVYK0lu?= =?utf-8?B?bkRNQ25kTStrcEtCS2NDOEhDdTFrYURVenJ4cnNkM2dhelBiU1RoUjAyeG50?= =?utf-8?B?VlFZeXl4cFdsZDY0MEpXcUJBRU9aRmpXZytycGp4MVlYNktoRE41TmwvelNm?= =?utf-8?B?YUtqMDBxNUNsRFpiSU9Gd1JFRDJpSW9rWDI5SVlOTlFTcTlORmFLQ2E2bTRQ?= =?utf-8?B?R3kyRDZBS29vSUxpQlp1d2dUZHkvdTBGa1ZKV0dDQVMxeVgwOVRsd2RnNlNM?= =?utf-8?B?a24zME9BYlB3T3VpVkFkYnNhaElUUC9DZXJaZ2pUSE9PQmFHQWx6UT09?= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: unaula.edu.co X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM8P220MB0567.NAMP220.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: d1d7d293-940b-42e6-68b1-08d9af169eee X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2021 06:49:53.8399 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 26abf082-b7c9-4c86-970d-314f452912da X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vllokWPa5xW8rjwhLH8DDnV+qsQ7f975c+xRAlroT8w9cG++WNHpFquOpCensXLNes0V39q2e9vtCZTK/nDcq5dF0A1ezDuFmeumXqvzaqAnby3yt2rZpDRZNY7wWsOq X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8P220MB0472 Archived-At: Subject: [netconf] =?utf-8?q?IEEE/IFIP_AnNet_2022_=E2=80=93_CALL_FOR_PAPE?= =?utf-8?q?RS?= 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, 24 Nov 2021 06:51:41 -0000 KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqCgogICAgICAgICAgICAgICAgICAgSUVFRS9JRklQIEFuTmV0 IDIwMjIg4oCTIENBTEwgRk9SIFBBUEVSUwoKICAgICAgICAgICAgIDd0aCBJRklQL0lFRUUgSW50 ZXJuYXRpb25hbCBXb3Jrc2hvcCBvbiBBbmFseXRpY3MgZm9yIE5ldHdvcmsgYW5kIApTZXJ2aWNl IE1hbmFnZW1lbnQgKEFuTmV0KQoKICAgICAgICAgICAgICAgICAgICAgIENvLWxvY2F0ZWQgd2l0 aCBJRklQL0lFRUUgTk9NUyAyMDIyCgogICAgICAgICAgICAgICAgICAgIEFwciAyNS0tMjksIDIw MjIgLy8gQnVkYXBlc3QsIEh1bmdhcnkKCmh0dHBzOi8vc2l0ZXMuZ29vZ2xlLmNvbS91bmFsLmVk dS5jby9hbm5ldHdvcmtzaG9wMjAyMi93ZWxjb21lCgoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgoK VGhlIFNldmVudGggSUVFRS9JRklQIEludGVybmF0aW9uYWwgV29ya3Nob3Agb24gQW5hbHl0aWNz IGZvciBOZXR3b3JrIGFuZCAKU2VydmljZSBNYW5hZ2VtZW50IChBbk5ldCAyMDIyKSB3aWxsIGJl IGhlbGQgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgSUVFRS9JRklQIApOZXR3b3JrIE9wZXJhdGlv bnMgYW5kIE1hbmFnZW1lbnQgU3ltcG9zaXVtIChOT01TIDIwMjIpIGZyb20gQXByaWwgMjV0aCB0 byAKMjl0aCAyMDIyIGluIEJ1ZGFwZXN0LCBIdW5nYXJ5CgpGb2xsb3dpbmcgdGhlIHN1Y2Nlc3Mg b2YgdGhlIHNpeCBwcmV2aW91cyBlZGl0aW9ucyBvZiB0aGlzIHdvcmtzaG9wLCB0aGUgbWFpbiAK Z29hbCBvZiBBbk5ldCBpcyB0byBwcmVzZW50IHJlc2VhcmNoIGFuZCBleHBlcmllbmNlIHJlc3Vs dHMgaW4gdGhlIGFyZWEgb2YgCmRhdGEgYW5hbHl0aWNzIGFuZCBtYWNoaW5lIGxlYXJuaW5nIGZv ciBuZXR3b3JrIGFuZCBzZXJ2aWNlIG1hbmFnZW1lbnQuIApBcHByb2FjaGVzIHN1Y2ggYXMgc3Rh dGlzdGljYWwgYW5hbHlzaXMsIGRhdGEgbWluaW5nLCBhbmQgbWFjaGluZSBsZWFybmluZyBhcmUg CnByb21pc2luZyBtZWNoYW5pc21zIHRvIGhhcm5lc3MgdGhlIGltbWVuc2Ugc3RyZWFtIG9mIG9w ZXJhdGlvbmFsIGRhdGEgYW5kIHRvIAppbXByb3ZlIG9wZXJhdGlvbnMgYW5kIG1hbmFnZW1lbnQg b2YgSVQgc3lzdGVtcyBhbmQgbmV0d29ya3MuCgpBbk5ldCAyMDIyIHdpbGwgaW5jbHVkZSBvcmln aW5hbCBmdWxsLXBhcGVyIHByZXNlbnRhdGlvbnMgYW5kIHNob3J0LXBhcGVyIApzZXNzaW9ucy4g VGhlIHdvcmtzaG9wIGF0dGVuZGVlcyB3aWxsIGJlIHN0aW11bGF0ZWQgdG8gcGFydGljaXBhdGUg aW4gCmludGVyZXN0aW5nIGRpc2N1c3Npb25zLiBUbyB0aGlzIGVuZCwgc2hvcnQgcGFwZXJzIGRl c2NyaWJpbmcgbGF0ZS1icmVha2luZyAKYWR2YW5jZXMgYW5kIHdvcmstaW4tcHJvZ3Jlc3MgcmVw b3J0cyBmcm9tIG9uZ29pbmcgcmVzZWFyY2ggYW5kIGV4cGVyaW1lbnRhbCAKd29yayBhcmUgYWxz byB3ZWxjb21lLgoKVE9QSUNTIE9GIElOVEVSRVNUCj09PT09PT09PT09PT09PT09PT09PT09PT0K CldlIGludml0ZSBvdXIgY29tbXVuaXR5IHRvIGNvbnRyaWJ1dGUgd2l0aCBtYW51c2NyaXB0cyBk ZXNjcmliaW5nIG5vdmVsLCAKd29ya+KAkWlu4oCRcHJvZ3Jlc3MgcmVzZWFyY2ggb24gdGhlIGRl c2lnbiBvZiBzb2x1dGlvbnMgdG8gcmVsZXZhbnQgc2VjdXJpdHkgCmlzc3VlcyBvbiBhIHdpZGUg dmFyaWV0eSBvZiBuZXh0IGdlbmVyYXRpb24gbmV0d29ya2luZyB0ZWNobm9sb2dpZXMuIFRoZSAK dG9waWNzIG9mIGludGVyZXN0IGluY2x1ZGU6CgpEYXRhIGFuYWx5dGljcwoKKiBBbmFseXNpcywg bW9kZWxpbmcgYW5kIHZpc3VhbGl6YXRpb24KKiBPcGVyYXRpb25hbCBhbmFseXRpY3MgYW5kIGlu dGVsbGlnZW5jZQoqIEV2ZW50LCBsb2cgYW5kIGJpZyBkYXRhIGFuYWx5dGljcwoqIE5ldHdvcmsg dHJhZmZpYyBhbmFseXNpcwoqIEFub21hbHkgZGV0ZWN0aW9uIGFuZCBwcmVkaWN0aW9uCiogQ3Jv d2Qgc2Vuc2luZwoqIE1vbml0b3JpbmcgYW5kIG1lYXN1cmVtZW50cyBmb3IgbWFuYWdlbWVudAoq IFByZWRpY3RpdmUgYW5kIHJlYWwtdGltZSBhbmFseXRpY3MKKiBIYXJuZXNzaW5nIHNvY2lhbCBk YXRhIGZvciBtYW5hZ2VtZW50CgpNYWNoaW5lIGxlYXJuaW5nIHRlY2huaXF1ZXMKCiogU3VwZXJ2 aXNlZCwgc2VtaS1zdXBlcnZpc2VkLCBhbmQgdW5zdXBlcnZpc2VkIGxlYXJuaW5nCiogQ2x1c3Rl cmluZyBhbmQgZGF0YSBtaW5pbmcKKiBSZWluZm9yY2VtZW50IGxlYXJuaW5nCiogTXVsdGktYWdl bnQgYmFzZWQgbGVhcm5pbmcKKiBEZWVwIGxlYXJuaW5nCiogQmF5ZXNpYW4gbWV0aG9kcwoqIEVu c2VtYmxlIG1ldGhvZHMKKiBDb2duaXRpdmUgY29tcHV0aW5nCiogTWluaW5nIHNwYXRpb3RlbXBv cmFsIGFuZCB0aW1lIHNlcmllcyBkYXRhCgpOZXR3b3JrIG1hbmFnZW1lbnQgcGFyYWRpZ21zCgoq IEF1dG9ub21vdXMgYW5kIGF1dG9ub21pYyBuZXR3b3JrcwoqIEZvZy9lZGdlIGNvbXB1dGluZwoq IEluLW5ldHdvcmsgcHJvY2Vzc2luZwoqIEJpby1pbnNwaXJlZCBuZXR3b3JrcyBhbmQgc2VsZi1t YW5hZ2VtZW50CiogQ29nbml0aXZlIGFuZCBzb2Z0d2FyZSBkZWZpbmVkIG5ldHdvcmtzCiogTmV0 d29yayBmdW5jdGlvbiB2aXJ0dWFsaXphdGlvbgoqIFNlY3VyaXR5LCBmYXVsdCwgcGVyZm9ybWFu Y2UsIGFuZCByZXNvdXJjZSBtYW5hZ2VtZW50CiogSW50ZW50LWJhc2VkIG5ldHdvcmtpbmcKKiBQ cm9ncmFtbWFibGUgZGF0YSBwbGFuZXMKCkFwcGxpY2F0aW9uIGRvbWFpbnMKCiogQ29tcHV0ZXIg bmV0d29ya3MKKiBNb2JpbGUgYWQtaG9jIGFuZCB3aXJlbGVzcyBzZW5zb3IgbmV0d29ya3MKKiBD bG91ZHMgYW5kIGRhdGEgY2VudGVycwoqIFZpcnR1YWxpemVkIGluZnJhc3RydWN0dXJlcwoqIElu dGVybmV0IG9mIFRoaW5ncwoqIENvbXB1dGluZyBhbmQgbmV0d29yayBzZXJ2aWNlcwoqIElUIHNl cnZpY2UgbWFuYWdlbWVudCwgc3RvcmFnZSByZXNvdXJjZSBtYW5hZ2VtZW50CgpBVVRIT1IgSU5T VFJVQ1RJT05TCj09PT09PT09PT09PT09PT09PT09PT09PT0KClBhcGVyIHN1Ym1pc3Npb25zIG11 c3QgcHJlc2VudCBvcmlnaW5hbCwgdW5wdWJsaXNoZWQgcmVzZWFyY2ggb3IgZXhwZXJpZW5jZXMu IApQYXBlcnMgdW5kZXIgcmV2aWV3IGVsc2V3aGVyZSBtdXN0IG5vdCBiZSBzdWJtaXR0ZWQgdG8g dGhlIHdvcmtzaG9wLiBBbGwgCmNvbnRyaWJ1dGlvbnMgbXVzdCBiZSBzdWJtaXR0ZWQgaW4gUERG IGZvcm1hdCB2aWEgSkVNUyBzdWJtaXNzaW9uIHN5c3RlbSAKKGh0dHBzOi8vamVtcy5zYmMub3Jn LmJyL2hvbWUuY2dpP2M9NDAxOSkuCgpUaGVyZSBpcyBhIGxlbmd0aCBsaW1pdGF0aW9uIG9mIDYg cGFnZXMgKGluY2x1ZGluZyB0aXRsZSwgYWJzdHJhY3QsIGFsbCAKZmlndXJlcywgdGFibGVzLCBh bmQgcmVmZXJlbmNlcykgZm9yIHJlZ3VsYXIgcGFwZXJzLCBhbmQgNCBwYWdlcyBmb3Igc2hvcnQg CnBhcGVycyBkZXNjcmliaW5nIHdvcmsgaW4gcHJvZ3Jlc3MuIFN1Ym1pc3Npb25zIG11c3QgYmUg aW4gSUVFRSAyLWNvbHVtbiAKc3R5bGUuIFNlbGYtcGxhZ2lhcml6ZWQgcGFwZXJzIHdpbGwgYmUg cmVqZWN0ZWQgd2l0aG91dCBmdXJ0aGVyIHJldmlldy4gVGhlIAphY2NlcHRlZCBwYXBlcnMgd2ls bCBiZSBzdWJtaXR0ZWQgZm9yIHB1YmxpY2F0aW9uIGluIHRoZSBJRUVFIFhwbG9yZSBEaWdpdGFs IApMaWJyYXJ5LiBQYXBlcnMgd2lsbCBiZSB3aXRoZHJhd24gZnJvbSBJRUVFIFhwbG9yZSBpbiBj YXNlIHRoZSBhdXRob3JzIGRvIG5vdCAKcHJlc2VudCB0aGVpciBwYXBlciBhdCB0aGUgd29ya3No b3AuCgpJTVBPUlRBTlQgREFURVMKPT09PT09PT09PT09PT09PT09PT09PT09PQoKUGFwZXIgU3Vi bWlzc2lvbjogSmFuIDIzLCAyMDIyCkFjY2VwdGFuY2U6IEZlYiAyNywgMjAyMgpDYW1lcmEtcmVh ZHk6IE1hciAxMywgMjAyMgoKT1JHQU5JWklORyBDT01NSVRURUUKPT09PT09PT09PT09PT09PT09 PT09PT09PQoKR0VORVJBTCBDSEFJUgoKKiBKdWFuIEZlbGlwZSBCb3Rlcm8gVmVnYSAoVW5pdmVy c2l0eSBvZiBBbnRpb3F1aWEsIENvbG9tYmlhKQoKVFBDIENIQUlSUwoKKiBBZHJpw6FuIExhcmEg KFVuaXZlcnNpdHkgb2YgQ29zdGEgUmljYSwgQ29zdGEgUmljYSkKKiBTZXJnaW8gQXJtYW5kbyBH dXRpw6lycmV6IEJldGFuY3VyIChVbml2ZXJzaWRhZCBBdXTDs25vbWEgTGF0aW5vYW1lcmljYW5h LCAKQ29sb21iaWEpCgpTVEVFUklORyBDT01NSVRURUUKCiogUmFvdWYgQm91dGFiYSAoVW5pdmVy c2l0eSBvZiBXYXRlcmxvbywgQ2FuYWRhKQoqIFlpeGluIERpYW8gKElCTSBULiBKLiBXYXRzb24g UmVzZWFyY2ggQ2VudGVyLCBVU0EpCiogUm9sZiBTdGFkbGVyIChLVEggUm95YWwgSW5zdGl0dXRl IG9mIFRlY2hub2xvZ3ksIFN3ZWRlbikKKiBGaWxpcCBEZSBUdXJjayAoR2hlbnQgVW5pdmVyc2l0 eSDigJMgaU1pbmRzLCBCZWxnaXVtKQoqIE1laG1ldCBVbGVtYSAoTWFuaGF0dGFuIENvbGxlZ2Us IFVTQSkKKiBOdXIgWmluY2lyLUhleXdvb2QgKERhbGhvdXNpZSBVbml2ZXJzaXR5LCBDYW5hZGEp CgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t CgpTZXJnaW8gQXJtYW5kbyBHdXRpw6lycmV6IEJldGFuY3VyLCBQaC5ELgpSZXNlYXJjaCBMZWN0 dXJlcgpzZXJnaW8uZ3V0aWVycmV6YmVAdW5hdWxhLmVkdS5jbwpPZmljaW5hIDQxOCwgQmxvcXVl IDEKQ2FycmVyYSA1NSBOwrogNDkgLSA1MQpNZWRlbGzDrW4sIENvbG9tYmlhCg== From nobody Tue Nov 23 23:49:03 2021 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 7B9533A0C52; Tue, 23 Nov 2021 23:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 hEfpe_lnNecd; Tue, 23 Nov 2021 23:48:56 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 758CB3A0C50; Tue, 23 Nov 2021 23:48:56 -0800 (PST) Received: from fraeml736-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HzY5D5TZRz67PQL; Wed, 24 Nov 2021 15:47:44 +0800 (CST) Received: from [10.47.69.204] (10.47.69.204) by fraeml736-chm.china.huawei.com (10.206.15.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Wed, 24 Nov 2021 08:48:45 +0100 Message-ID: Date: Wed, 24 Nov 2021 08:48:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Content-Language: en-GB To: Sergio Armando Gutierrez Betancur , netconf-chairs CC: "netconf@ietf.org" References: <8840566.zQ0Gbyo6oJ@eos> From: Benoit Claise In-Reply-To: <8840566.zQ0Gbyo6oJ@eos> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.47.69.204] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To fraeml736-chm.china.huawei.com (10.206.15.217) X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] =?utf-8?q?IEEE/IFIP_AnNet_2022_=E2=80=93_CALL_FOR_PAPE?= =?utf-8?q?RS?= 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, 24 Nov 2021 07:49:02 -0000 Dear WG chairs, I hope we will not start seeing all the CALL FOR PAPERS in the WG mailing lists. It's already annoying enough in the RGs (read NMRG) IMO. Regards, Benoit On 11/24/2021 7:49 AM, Sergio Armando Gutierrez Betancur wrote: > ****************************************************************************** > > IEEE/IFIP AnNet 2022 – CALL FOR PAPERS > > 7th IFIP/IEEE International Workshop on Analytics for Network and > Service Management (AnNet) > > Co-located with IFIP/IEEE NOMS 2022 > > Apr 25--29, 2022 // Budapest, Hungary > > https://sites.google.com/unal.edu.co/annetworkshop2022/welcome > > ******************************************************************************** > > The Seventh IEEE/IFIP International Workshop on Analytics for Network and > Service Management (AnNet 2022) will be held in conjunction with the IEEE/IFIP > Network Operations and Management Symposium (NOMS 2022) from April 25th to > 29th 2022 in Budapest, Hungary > > Following the success of the six previous editions of this workshop, the main > goal of AnNet is to present research and experience results in the area of > data analytics and machine learning for network and service management. > Approaches such as statistical analysis, data mining, and machine learning are > promising mechanisms to harness the immense stream of operational data and to > improve operations and management of IT systems and networks. > > AnNet 2022 will include original full-paper presentations and short-paper > sessions. The workshop attendees will be stimulated to participate in > interesting discussions. To this end, short papers describing late-breaking > advances and work-in-progress reports from ongoing research and experimental > work are also welcome. > > TOPICS OF INTEREST > ========================= > > We invite our community to contribute with manuscripts describing novel, > work‑in‑progress research on the design of solutions to relevant security > issues on a wide variety of next generation networking technologies. The > topics of interest include: > > Data analytics > > * Analysis, modeling and visualization > * Operational analytics and intelligence > * Event, log and big data analytics > * Network traffic analysis > * Anomaly detection and prediction > * Crowd sensing > * Monitoring and measurements for management > * Predictive and real-time analytics > * Harnessing social data for management > > Machine learning techniques > > * Supervised, semi-supervised, and unsupervised learning > * Clustering and data mining > * Reinforcement learning > * Multi-agent based learning > * Deep learning > * Bayesian methods > * Ensemble methods > * Cognitive computing > * Mining spatiotemporal and time series data > > Network management paradigms > > * Autonomous and autonomic networks > * Fog/edge computing > * In-network processing > * Bio-inspired networks and self-management > * Cognitive and software defined networks > * Network function virtualization > * Security, fault, performance, and resource management > * Intent-based networking > * Programmable data planes > > Application domains > > * Computer networks > * Mobile ad-hoc and wireless sensor networks > * Clouds and data centers > * Virtualized infrastructures > * Internet of Things > * Computing and network services > * IT service management, storage resource management > > AUTHOR INSTRUCTIONS > ========================= > > Paper submissions must present original, unpublished research or experiences. > Papers under review elsewhere must not be submitted to the workshop. All > contributions must be submitted in PDF format via JEMS submission system > (https://jems.sbc.org.br/home.cgi?c=4019). > > There is a length limitation of 6 pages (including title, abstract, all > figures, tables, and references) for regular papers, and 4 pages for short > papers describing work in progress. Submissions must be in IEEE 2-column > style. Self-plagiarized papers will be rejected without further review. The > accepted papers will be submitted for publication in the IEEE Xplore Digital > Library. Papers will be withdrawn from IEEE Xplore in case the authors do not > present their paper at the workshop. > > IMPORTANT DATES > ========================= > > Paper Submission: Jan 23, 2022 > Acceptance: Feb 27, 2022 > Camera-ready: Mar 13, 2022 > > ORGANIZING COMMITTEE > ========================= > > GENERAL CHAIR > > * Juan Felipe Botero Vega (University of Antioquia, Colombia) > > TPC CHAIRS > > * Adrián Lara (University of Costa Rica, Costa Rica) > * Sergio Armando Gutiérrez Betancur (Universidad Autónoma Latinoamericana, > Colombia) > > STEERING COMMITTEE > > * Raouf Boutaba (University of Waterloo, Canada) > * Yixin Diao (IBM T. J. Watson Research Center, USA) > * Rolf Stadler (KTH Royal Institute of Technology, Sweden) > * Filip De Turck (Ghent University – iMinds, Belgium) > * Mehmet Ulema (Manhattan College, USA) > * Nur Zincir-Heywood (Dalhousie University, Canada) > > ------------------------------------------------------- > > Sergio Armando Gutiérrez Betancur, Ph.D. > Research Lecturer > sergio.gutierrezbe@unaula.edu.co > Oficina 418, Bloque 1 > Carrera 55 Nº 49 - 51 > Medellín, Colombia > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Nov 25 06:03:03 2021 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 9B97F3A089E; Thu, 25 Nov 2021 06:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, 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 pL7TuIegQ2OC; Thu, 25 Nov 2021 06:02:42 -0800 (PST) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 31C8F3A089A; Thu, 25 Nov 2021 06:02:42 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id w22so7672519ioa.1; Thu, 25 Nov 2021 06:02:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:date:from:subject:thread-topic:in-reply-to:message-id :references:to:cc:content-transfer-encoding; bh=DOvITYLZYi4w4gH4c5/lY0QYRZbREdDso+ud1jh1Qb0=; b=TWg0hRj+g9WvibgPS3uHMfzp+lU9wXe/ZDuzTUNKv/reswsu9NNN7LT8uvvhUs99/F IwB2SGspWgiMed+0hxUxB9XS1RyGyC/omK5n+RlDWravrzqxWbSJ9xGxmQB8gMILyBMr VxLXocVSbmuGCfjtQYoO8AoVep7CY1gKRLDGxRnpufYWMDK5rp1GsopOpJ02IJ2M/zOG ksTmgqF4gRIQO6wFTViZHDoD9bxg8BoOEnWLAvsVP22gKS1TVZiAq0x0EiPgB4UcuIMz IOU3w15dom6ioMNouHBaqALko52/iLPjjIAopYZssMZ9vTS2UQeFB6FusapHw2QkiBL6 SsQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:date:from:subject:thread-topic :in-reply-to:message-id:references:to:cc:content-transfer-encoding; bh=DOvITYLZYi4w4gH4c5/lY0QYRZbREdDso+ud1jh1Qb0=; b=2l2XBpsID+R9cO9eimSe+WVAFNpq+PDAwghQHEtikQqJjDj+eveVvaZrsh3gowq/MG H3Yjm7LNXcx3QAC0RptIyvWSNURKeuxHC5x4uiUwih/Hek0qrQ3uDl3BBPB0Z6bK4jmt AGnrjRag9B1rAF+fKddeIhJk4izim3CtdgjxX+cLAzCOF8JFxbQW1ym1vG6qD44TqJ2g c5EPsAft2DLMdA+DgBg9XhcOLaLwGWvoQuJw2SV0JiDB/0LuSC1XNNOcMPY5la6EBS5Z kyT0kqfZ5i93VBu1WSJ6Drz1JsOwuEYci//XoOBsRhIN/a2iu4xicpZ6xd5G6iP0A8d4 8neQ== X-Gm-Message-State: AOAM533g8Ozs5Jf8uZnvWDKoQnwdgr1fLvzP3QoRL1Ch7YX4w5K729kv 19HT5Gd7Fc1KFLR66CIC7oQJa9dXm30= X-Google-Smtp-Source: ABdhPJyGgMf26d038o+mu29aH2nuAmTc7Mnbboo4IjWDDx3+E8Kes1dgD1SHGbQT4sF818xaitcQeg== X-Received: by 2002:a05:6638:2178:: with SMTP id p24mr29235348jak.142.1637848960508; Thu, 25 Nov 2021 06:02:40 -0800 (PST) Received: from MacBook-Pro.local (IGLD-84-229-147-189.inter.net.il. [84.229.147.189]) by smtp.gmail.com with ESMTPSA id x5sm1515537iov.50.2021.11.25.06.02.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Nov 2021 06:02:39 -0800 (PST) MIME-Version: 1.0 Date: Thu, 25 Nov 2021 16:02:32 +0200 From: Yaron Sheffer Thread-Topic: Re: Secdir last call review of draft-ietf-netconf-sztp-csr-11 In-Reply-To: <0100017d49a045e3-d1919799-0247-4fb5-abe6-d0c661f80f6a-000000@email.amazonses.com> Message-ID: References: <163717559932.18384.2156774121641934785@ietfa.amsl.com>, <0100017d49a045e3-d1919799-0247-4fb5-abe6-d0c661f80f6a-000000@email.amazonses.com> To: Kent Watsen Cc: "secdir@ietf.org" , "draft-ietf-netconf-sztp-csr.all@ietf.org" , "last-call@ietf.org" , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Archived-At: Subject: Re: [netconf] Secdir last call review of draft-ietf-netconf-sztp-csr-11 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, 25 Nov 2021 14:02:48 -0000

Hi Kent,

 

Thank you for addre= ssing my comments, I am happy with most of your responses but I do have a f= ew remaining questions:

 

  • The commit that removes t= he dependency on IDevID and LDevID does not fix the issue of non-orthogonal= ity. There is very detailed description for CMP and CMC, but nothing for PK= CS #10 (p10-csr). Does it mean =E2=80=9Cuse PKCS#10 out of the box and it= =E2=80=99ll just work=E2=80=9D? Or does it mean =E2=80=9Cthe usage of PKCS#= 10 for these certs is still TBD=E2=80=9D?
  • I suggest to a= dd the following reference to the paragraph on quality randomness, as a str= ong proof that this is a real world concern:

 

Heninger, N., Durume= ric, Z., Wustrow, E., and J. Halderman, "Mining Your Ps and Qs: Detect= ion of Widespread Weak Keys in Network Devices", Proceedings of the 21= st USENIX Security Symposium , August 2012, <https://factorable.net/>.

 

    =
  • I understand that key generation is out of scope and maybe this needs t= o be a separate work item, but recommending periodic replacement of the cer= ts without recommending a suitable mechanism leaves this solution with a bi= g hole.
  • It is really annoying that 21 years after PKCS #= 10, we still cannot provide a reference that would enable implementers to f= ind out all available, non-deprecated AlgorithmIdentifier values. (And I re= alize there=E2=80=99s little you can do about it.)

 

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

 

 

From: = Kent Watsen <kent+ietf@watsen.net>
Date: Monday, November 2= 2, 2021 at 23:49
To: Yaron Sheffer <yaronf.ietf@gmail.com><= br>Cc: secdir@ietf.org <secdir@ietf.org>, draft-ietf-netconf-s= ztp-csr.all@ietf.org <draft-ietf-netconf-sztp-csr.all@ietf.org>, last= -call@ietf.org <last-call@ietf.org>, netconf@ietf.org <netconf@iet= f.org>
Subject: Re: Secdir last call review of draft-ietf-netc= onf-sztp-csr-11

Hi Yaron,

 

Thank you for your valuable comments.  My co-au= thors and I have the following

responses to your comments.

 

 



On Nov 17, 2021, at 1:59 PM, Ya= ron Sheffer via Datatracker <noreply= @ietf.org> wrote:

 

Reviewer: Yaron Sheffer
Review result: Has Issues<= br>
This draft defines a mechanism for a device, when it first starts, t= o generate
a CSR to get itself provisioned with one or more certificates= it needs to
identify itself during its normal operation.

* I was= confused that the document starts out describing a generic cert requestmechanism. Then deep into the YANG modules, it turns out that there is gui= dance
(only?) for very specific types of certs, namely LDevID and IDevID= . And the
choice is non-orthogonal: it is unclear what is the guidance f= or other certs
when using CMC and CMP, and conversely, whether these two= certs can be
generated with a PKCS#10 CSR.

 =

We updated = the YANG module to greatly remove references to IDevID/LDevID.

 

Specifica= lly:

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 1) s/IDevID/initial device= identity certificate/g

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 2)&nb= sp;s/LDevID/local device identity certificate/g

=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3) manually rewrap lines to col 69 as required

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4) removed the terminology-disclaimer = block at top

 

 <= /p>

Good?

 



=

* I suggest adding a S= ecurity Considerations section about the need for strong
randomness, whi= ch is often unavailable to small embedded devices at the early
stages of= provisioning. I wish we were more successful with:
https://= datatracker.ietf.org/doc/html/draft-sheffer-dhc-initial-random-00<= /o:p>

 

OLD:

    It is RECOMMENDED that a new private key is ge= nerated for each CSR
    described in this document.

NE= W:

    It is RECOMMENDED that a new private key is generat= ed for each CSR
    described in this document.

  =   This private key MUST be generated using a quality random source. Th= e
    use of inadequate pseudo-random number generators (PRNGs= ) to
    generate private keys can result in little or no secu= rity.  An attacker may
    find it much easier to reprodu= ce the PRNG environment that produced
    the private key, sea= rching the resulting small set of possibilities, rather
    th= an brute force searching the whole private key space.  The generation<= br>    of quality random numbers is difficult.  BCP 106 [RFC= 4086] offers
    important guidance in this area.

and we added a= n Informational reference to RFC 4086.

 

<= p class=3DMsoNormal style=3D'margin-left:.5in'>Good now?

 



<= /p>

* Negotiation (?) of the CSR f= ormat and supported algorithms is unclear in Sec.
2.2: is it the client = that provides the values it supports and the server picks
one? Alternati= vely, is the list conveyed by the server in the error-info and so
the cl= ient knows exactly what is supported? IOW, why include these values at
a= ll in error-info?

 

Section 2.1 states the sequence of = exchanges, but we went ahead and added more context to the examples for add= itional clarity.  The diff is here: https= ://github.com/netconf-wg/sztp-csr/commit/7ed4f5b1daee539dc9071061e4d427e843= 467d02

 

Better?

 



* It is not clear from Sec. 2.2 how exactly the client is suppo= sed to associate
one of possibly multiple received certificates to the C= SR it just sent out.
Surely it is not expected to grep for the string &q= uot;Newly-Generated"?

 

There doesn=E2=80=99t have= to be any logic on the client to detect the signed certificate or, fo= r that matter, to ensure that the server sent one at all.  The point &= nbsp;of the bootstrap process is to *configure* the SZT= P-client, and the client's only post-update logic is to =E2=80=9Crun as con= figured=E2=80=9D, whatever that might be.

 

That said, it wouldn=E2=80=99t=  be hard for a client to, e.g., search a =E2=80=9Ckeystore" mecha= nism for a key having the key used in the CSR and then search certificates = associated with that key = for that cert having the matching attributes (e.g., the =E2=80=9CSubject=E2= =80=9D attribute) as in the CSR.

 

Makes sense?   [No update to the d= raft was made to address this comment]

 



* 2.3: the description of "error-info"= still does not specify if the server
should list all CSR format and alg= orithms it supports.

 

 

Section 2.1 indicates tha= t the client=E2=80=99s message lists all of the key-algorithms and csr= -formats it supports and the server=E2=80=99s message merely selects t= he specific algorithm/format it wishes the client use.   This comment = is nearly identical to one of your earlier comments, for which we added mor= e context around the examples.  Good enough?  

 

 

* Is there really nee= d to support 3 different CSR formats?

 

Yes and, FWIW, = the PKI world has even more formats; we actually restricted them to just th= ose that are most widely implemented.

 



* Where does the client indicate which cert is wa= nts to receive based on this
CSR, e.g. "this CSR is for a LDevID&qu= ot;? Is this information embedded in the CSR
itself?

 

The CSR is always for an LDevID.  It can never be for an IDevID, wh= ich can (effectively) only be generated/installed by the vendor during the = device=E2=80=99s manufacturing process. 

 

Makes sense?   [No update to the draft was made to address this= comment]

 

 

* Is RFC 2986 (published Nov. 2000) the best referenc= e for an
AlgorithmIdentifier? Is there no IANA registry we could referen= ce instead?

 

There is not an IANA registry for AlgorithmIde= ntifiers.  RFC 2986 is the reference for the PKCS#10 CSR.

 

[No update to the draft was made to address this comment= ]



 



* When talking about algorithm = matching, I suggest changing "It is an error
if..." into norma= tive text, "The recipient MUST reject...".

=  

= OLD:

         I= t is an error if the 'AlgorithmIdentifier' field
      &n= bsp;  contained inside the 'SubjectPublicKeyInfo' field
  &nbs= p;      does not match the algorithm identified by the
&n= bsp;        'selected-algorithm' node.";

NE= W:

         If the 'AlgorithmIdentifier' fi= eld contained inside the
         certificate '= SubjectPublicKeyInfo' field does not match
        &= nbsp;the algorithm identified by the 'selected-algorithm' node,
  &= nbsp;      then the client MUST reject the certificate and r= aise an
         error.";

 

Good?

&n= bsp;

 

 

* &= quot;Details for how to generate a new private key and associate a new iden= tity
certificate are outside the scope of this document." - This is= rather
disappointing, since we just RECOMMENDED to regenerate certs per= iodically (and
given that IOT devices often lack HSMs).

 

Understood, but key-generation is indeed outside the scope of this documen= t.

 

[No update to the draft was made to = address this comment]



=





Thanks again,

Kent (and Sean and Russ)

 

 

 

= From nobody Fri Nov 26 08:01:37 2021 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 1FE433A07D2 for ; Fri, 26 Nov 2021 08:01:03 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08VoT4Onz7K1 for ; Fri, 26 Nov 2021 08:00:58 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA58C3A07DE for ; Fri, 26 Nov 2021 08:00:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id F015F300C1D for ; Fri, 26 Nov 2021 10:53:11 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id m19kYFDcxt2m for ; Fri, 26 Nov 2021 10:53:07 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 6452A300B38; Fri, 26 Nov 2021 10:53:07 -0500 (EST) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_643D9F68-DCD6-4ACC-8D68-EF10BCB53217" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Fri, 26 Nov 2021 10:53:03 -0500 In-Reply-To: Cc: Kent Watsen , IETF SecDir , "draft-ietf-netconf-sztp-csr.all@ietf.org" , "last-call@ietf.org" , "netconf@ietf.org" To: Yaron Sheffer References: <163717559932.18384.2156774121641934785@ietfa.amsl.com> <0100017d49a045e3-d1919799-0247-4fb5-abe6-d0c661f80f6a-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [netconf] Secdir last call review of draft-ietf-netconf-sztp-csr-11 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, 26 Nov 2021 16:01:03 -0000 --Apple-Mail=_643D9F68-DCD6-4ACC-8D68-EF10BCB53217 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yaron: > Thank you for addressing my comments, I am happy with most of your = responses but I do have a few remaining questions: > =20 > The commit that removes the dependency on IDevID and LDevID does not = fix the issue of non-orthogonality. There is very detailed description = for CMP and CMC, but nothing for PKCS #10 (p10-csr). Does it mean =E2=80=9C= use PKCS#10 out of the box and it=E2=80=99ll just work=E2=80=9D? Or does = it mean =E2=80=9Cthe usage of PKCS#10 for these certs is still TBD=E2=80=9D= ? PKCS#10 is pretty simple. Are you aware of anything more that ought to = be said? > I suggest to add the following reference to the paragraph on quality = randomness, as a strong proof that this is a real world concern: > =20 > Heninger, N., Durumeric, Z., Wustrow, E., and J. Halderman, "Mining = Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices", = Proceedings of the 21st USENIX Security Symposium , August 2012, = >. In another thread, something like this was suggested for another = document: Implementations must randomly generate nonces and private keys. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic keys can result in little or no security. An = attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of = possibilities, rather than brute force searching the whole key space. As example for predictable random numbers see CVE-2008-0166 [=E2=80=A6]. The = generation of quality random numbers is difficult. ISO/IEC 20543:2019 [=E2=80=A6],= NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [=E2=80=A6], BCP = 106 [RFC4086], and others offers valuable guidance in this area. If this approach works for you, we'll dig up the appropriate references. > =20 > I understand that key generation is out of scope and maybe this needs = to be a separate work item, but recommending periodic replacement of the = certs without recommending a suitable mechanism leaves this solution = with a big hole. I do not agree. It does offer the protocol for obtaining replacement = certificates for devices that are able to generating a fresh = public/private key pair. Getting more detailed would be algorithm = specific, which is not appropriate in this document. > It is really annoying that 21 years after PKCS #10, we still cannot = provide a reference that would enable implementers to find out all = available, non-deprecated AlgorithmIdentifier values. (And I realize = there=E2=80=99s little you can do about it.) So, we will leave this part alone. Russ --Apple-Mail=_643D9F68-DCD6-4ACC-8D68-EF10BCB53217 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yaron:

Thank you for addressing my = comments, I am happy with most of your responses but I do have a few = remaining questions:
 
  • The commit that removes the dependency on IDevID and LDevID = does not fix the issue of non-orthogonality. There is very detailed = description for CMP and CMC, but nothing for PKCS #10 (p10-csr). Does it = mean =E2=80=9Cuse PKCS#10 out of the box and it=E2=80=99ll just work=E2=80= =9D? Or does it mean =E2=80=9Cthe usage of PKCS#10 for these certs is = still TBD=E2=80=9D?

PKCS#10 is pretty simple.  Are you aware of = anything more that ought to be said?

  • I suggest to = add the following reference to the paragraph on quality randomness, as a = strong proof that this is a real world concern:
 
Heninger, N., Durumeric, = Z., Wustrow, E., and J. Halderman, "Mining Your Ps and Qs: Detection of = Widespread Weak Keys in Network Devices", Proceedings of the 21st USENIX Security Symposium , = August 2012, <https://factorable.net/>.
=

In another thread, something like this was = suggested for another document:

  =  Implementations must randomly generate nonces and = private keys.
   The use of inadequate pseudo-random number = generators (PRNGs) to
  =  generate cryptographic keys can result in little or no security. = An attacker
   may find it much easier to = reproduce the PRNG environment that
  =  produced the keys, searching the resulting small set of = possibilities,
   rather than brute force searching = the whole key space. As example for
  =  predictable random numbers see CVE-2008-0166 [=E2=80=A6]. The = generation
   of quality random numbers is = difficult. ISO/IEC = 20543:2019 [=E2=80=A6],
   NIST = SP 800-90A Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [=E2=80=A6], BCP 106 = [RFC4086], and
   others offers valuable = guidance in this area.

If this approach works for you, we'll dig up = the appropriate references.

 
  • I understand that key generation is out of scope and maybe = this needs to be a separate work item, but recommending periodic = replacement of the certs without recommending a suitable mechanism = leaves this solution with a big = hole.

I do = not agree.  It does offer the protocol for obtaining replacement = certificates for devices that are able to generating a fresh = public/private key pair.  Getting more detailed would be algorithm = specific, which is not appropriate in this document.

  • It is really annoying that 21 years after PKCS #10, we = still cannot provide a reference that would enable implementers to find = out all available, non-deprecated AlgorithmIdentifier values. (And I = realize there=E2=80=99s little you can do about = it.)

So, we = will leave this part alone.

Russ

= --Apple-Mail=_643D9F68-DCD6-4ACC-8D68-EF10BCB53217-- From nobody Sun Nov 28 01:29:38 2021 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 C1A533A05DF; Sun, 28 Nov 2021 01:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, 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 OhEYqqcbLZv1; Sun, 28 Nov 2021 01:29:26 -0800 (PST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 5107E3A05F0; Sun, 28 Nov 2021 01:29:26 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id a18so29548853wrn.6; Sun, 28 Nov 2021 01:29:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:date:from:subject:thread-topic:in-reply-to:message-id :references:to:cc:content-transfer-encoding; bh=bStiFcCprgsoL/pLNQHhwew18a81e84d/8a3jANDLvk=; b=R5yTh63B9Cw/KjTylwuDuzvDBBcyawWZIJ+5hTcl6bOEKExOJVVcnEIV7iNyyE1XmU hF+PDoZI1PskQKaveJl013MOcpHa++WrovfeDnx8DgzRwtH85Oi/J/Eew3VhyNUrDl87 R8GMwMnEOztE2gcbSyhWUybRq6qWGis88/czDFZhRXxqbecKgJWlBp7nmeKIAFw33lTe NwyQwmXiGbDM2gYHjWYBgqMgvRp/id5h6xkPFYHc1CtOyL3TXr3e5lE0LaR6gsCmd6tO PTiTcDng0gbl++C54EmQunqZcU1XopElY2cmybOthnM6PCg9vonMIMC/BLa+z90Ay+qy RG7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:date:from:subject:thread-topic :in-reply-to:message-id:references:to:cc:content-transfer-encoding; bh=bStiFcCprgsoL/pLNQHhwew18a81e84d/8a3jANDLvk=; b=WY2VZdU3yUTFvfcFeA/SEwZTw8Gqbv1F3uMmRGQlbXKTChGZ+inWbMFNzOqI38PgLO ijx+JVG5J0melaTusJOCgn33zKndr6X88kAcQw31p+VILGYOO4bcwgYYpNL9986LSm07 GLnA99Qr/OFGf8Ez3LcWdO8pvM4lMcWe01cwwssrWWA/T0BScavx0j0rE6r5IHcbgoTW WLg4dUm8JDXj+g+zPi0VskSmwCtDe3g+5wz+qHlK/d57QKKXX7FAp8j+fLF2O57fLEUt p1uyiFv6cFwyZTbBlPW7T01z6B2X1XqLkI71snleQIiozdBeoz4kUecClU//ssHZNewV GaYg== X-Gm-Message-State: AOAM533wlTxNBZIqpIMZ7QKJnIxOF86o/+6zA6YdXqE2U6FssEgkcyux Sm3fUbgP5nTF9lzWxsXL9LqJ1LAuHEU= X-Google-Smtp-Source: ABdhPJxOkTRniPDfp9uaJE0pu1OXbcn28Wy4Azv4ceB1NLIDuzG3vqk1xBBs523Xn5ZfWodmy2T3iQ== X-Received: by 2002:a5d:4e0b:: with SMTP id p11mr25585296wrt.88.1638091763332; Sun, 28 Nov 2021 01:29:23 -0800 (PST) Received: from MacBook-Pro.local (IGLD-84-229-147-189.inter.net.il. [84.229.147.189]) by smtp.gmail.com with ESMTPSA id 9sm13355768wry.0.2021.11.28.01.29.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Nov 2021 01:29:22 -0800 (PST) MIME-Version: 1.0 Date: Sun, 28 Nov 2021 11:29:19 +0200 From: Yaron Sheffer Thread-Topic: Re: Secdir last call review of draft-ietf-netconf-sztp-csr-11 In-Reply-To: Message-ID: <8EC1807D-C357-DB41-8D94-FF8F0A2EF13C@hxcore.ol> References: <163717559932.18384.2156774121641934785@ietfa.amsl.com> <0100017d49a045e3-d1919799-0247-4fb5-abe6-d0c661f80f6a-000000@email.amazonses.com> , To: Russ Housley Cc: Kent Watsen , IETF SecDir , "draft-ietf-netconf-sztp-csr.all@ietf.org" , "last-call@ietf.org" , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Archived-At: Subject: Re: [netconf] Secdir last call review of draft-ietf-netconf-sztp-csr-11 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, 28 Nov 2021 09:29:32 -0000

Hi Russ,

 

Please see my answe= rs in-line.

 

Thanks,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ya= ron

 

From: Russ Housley= <housley@vigilsec.com>
Date: Friday, November 26, 2021 at = 17:53
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: <= /b>Kent Watsen <kent+ietf@watsen.net>, IETF SecDir <secdir@ietf.or= g>, draft-ietf-netconf-sztp-csr.all@ietf.org <draft-ietf-netconf-sztp= -csr.all@ietf.org>, last-call@ietf.org <last-call@ietf.org>, netco= nf@ietf.org <netconf@ietf.org>
Subject: Re: Secdir last cal= l review of draft-ietf-netconf-sztp-csr-11

Yaron:

 

Thank you for addressing my comments, I am happy w= ith most of your responses but I do have a few remaining questions:

 

=C2=B7       &nb= sp; The commit that r= emoves the dependency on IDevID and LDevID does not fix the issue of non-or= thogonality. There is very detailed description for CMP and CMC, but nothin= g for PKCS #10 (p10-csr). Does it mean =E2=80=9Cuse PKCS#10 out of the box = and it=E2=80=99ll just work=E2=80=9D? Or does it mean =E2=80=9Cthe usage of= PKCS#10 for these certs is still TBD=E2=80=9D?

 

PKCS#10 is prett= y simple.  Are you aware of anything more that ought to be said?<= /o:p>

&n= bsp;

I think we should explicitly mention wha= t this method *cannot* provide. As far as I can tell, none of the or= igin authentication methods are available when using PKCS #10 directly with= out wrapping it further.

= =C2=B7    =       

=C2=B7      &= nbsp;  I suggest= to add the following reference to the paragraph on quality randomness, as = a strong proof that this is a real world concern:

 

<= p class=3DMsoNormal style=3D'margin-left:.5in'>Heninger, N., Durumeric, Z.,= Wustrow, E., and J. Halderman, "Mining Your Ps and Qs: Detection of W= idespread Weak Keys in Network Devices", Proceedings of the 21st<= /sup> USENIX Security Sympo= sium , August 2012, <https://factora= ble.net/>.

 

In another thread, something like this w= as suggested for another document:

 

   Implementations mus= t randomly generate nonces and private keys.

=

   The use of ina= dequate pseudo-random number generators (PRNGs) to

   generate cryp= tographic keys can result in little or no security. An attacker<= /p>

   = may find it much easier to reproduce the PRNG environment that

   p= roduced the keys, searching the resulting small set of possibilities,<= /o:p>

  =  rather than brute force searching the whole key space. As example for=

&= nbsp;  predictable random numbers see CVE-2008-0166 [=E2=80=A6]. The g= eneration

   of quality random numbers is difficult. ISO/IEC 2= 0543:2019 [=E2=80=A6],

   NIST SP 800-90A Rev.1 [=E2=80=A6], = BSI AIS 31 V2.0 [=E2=80=A6], BCP 106 [RFC4086], and

   others offer= s valuable guidance in this area.

 

If this approach works for you, w= e'll dig up the appropriate references.

=  

Yes, but the Heninger et al. refe= rence is a better fit than the Debian CVE because (1) it discusses network = devices rather than servers and (2) it shows how even less broken RNGs can = be exploited by a network attacker that only sees the public keys.

 = ;

 

=C2=B7         I understand that key g= eneration is out of scope and maybe this needs to be a separate work item, = but recommending periodic replacement of the certs without recommending a s= uitable mechanism leaves this solution with a big hole.

&nb= sp;

I do not= agree.  It does offer the protocol for obtaining replacement certific= ates for devices that are able to generating a fresh public/private key pai= r.  Getting more detailed would be algorithm specific, which is not ap= propriate in this document.

 

Not rea= lly, because the =E2=80=9Cprotocol=E2=80=9D described here is: Client sends= a CSR, Server responds with a complete client configuration blob. This obv= iously doesn=E2=80=99t work for an already deployed client.

<= p class=3DMsoNormal style=3D'margin-left:.5in'>

=C2=B7&nb= sp;         

<= span style=3D'font-size:10.0pt;font-family:Symbol'>=C2=B7  &nbs= p;      It is really annoying that 21 years after PKCS #10, we still = cannot provide a reference that would enable implementers to find out all a= vailable, non-deprecated AlgorithmIdentifier values. (And I realize there= =E2=80=99s little you can do about it.)

 

So, we will leave this p= art alone.

 

Agreed. Sigh.

 

Russ

 

= From nobody Sun Nov 28 10:16:15 2021 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 8018C3A07D0 for ; Sun, 28 Nov 2021 10:16:09 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTjFNeXyFHSP for ; Sun, 28 Nov 2021 10:16:05 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 151283A0860 for ; Sun, 28 Nov 2021 10:16:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1E2EE300BE0 for ; Sun, 28 Nov 2021 13:10:09 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZXhEC_hRWH8y for ; Sun, 28 Nov 2021 13:10:03 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 397C13002A6; Sun, 28 Nov 2021 13:10:03 -0500 (EST) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_794155BA-5AF1-4DEE-8C1A-04D478DAA00D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Sun, 28 Nov 2021 13:09:59 -0500 In-Reply-To: <8EC1807D-C357-DB41-8D94-FF8F0A2EF13C@hxcore.ol> Cc: Kent Watsen , IETF SecDir , "draft-ietf-netconf-sztp-csr.all@ietf.org" , "last-call@ietf.org" , "netconf@ietf.org" To: Yaron Sheffer References: <163717559932.18384.2156774121641934785@ietfa.amsl.com> <0100017d49a045e3-d1919799-0247-4fb5-abe6-d0c661f80f6a-000000@email.amazonses.com> <8EC1807D-C357-DB41-8D94-FF8F0A2EF13C@hxcore.ol> X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [netconf] Secdir last call review of draft-ietf-netconf-sztp-csr-11 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, 28 Nov 2021 18:16:10 -0000 --Apple-Mail=_794155BA-5AF1-4DEE-8C1A-04D478DAA00D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yaron: > =20 > Thank you for addressing my comments, I am happy with most of your = responses but I do have a few remaining questions: > =20 > =C2=B7 The commit that removes the dependency on IDevID and = LDevID does not fix the issue of non-orthogonality. There is very = detailed description for CMP and CMC, but nothing for PKCS #10 = (p10-csr). Does it mean =E2=80=9Cuse PKCS#10 out of the box and it=E2=80=99= ll just work=E2=80=9D? Or does it mean =E2=80=9Cthe usage of PKCS#10 for = these certs is still TBD=E2=80=9D? > =20 > PKCS#10 is pretty simple. Are you aware of anything more that ought = to be said? > =20 > I think we should explicitly mention what this method *cannot* = provide. As far as I can tell, none of the origin authentication methods = are available when using PKCS #10 directly without wrapping it further. That is reasonable. I will talk with my co-authors and see if we can = come up with a brief summary. =20 > =C2=B7 I suggest to add the following reference to the = paragraph on quality randomness, as a strong proof that this is a real = world concern: > =20 > Heninger, N., Durumeric, Z., Wustrow, E., and J. Halderman, "Mining = Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices", = Proceedings of the 21st USENIX Security Symposium , August 2012, = >. > =20 > In another thread, something like this was suggested for another = document: > =20 > Implementations must randomly generate nonces and private keys. > The use of inadequate pseudo-random number generators (PRNGs) to > generate cryptographic keys can result in little or no security. An = attacker > may find it much easier to reproduce the PRNG environment that > produced the keys, searching the resulting small set of = possibilities, > rather than brute force searching the whole key space. As example = for > predictable random numbers see CVE-2008-0166 [=E2=80=A6]. The = generation > of quality random numbers is difficult. ISO/IEC 20543:2019 [=E2=80=A6= ], > NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [=E2=80=A6], BCP = 106 [RFC4086], and > others offers valuable guidance in this area. > =20 > If this approach works for you, we'll dig up the appropriate = references. > =20 > Yes, but the Heninger et al. reference is a better fit than the Debian = CVE because (1) it discusses network devices rather than servers and (2) = it shows how even less broken RNGs can be exploited by a network = attacker that only sees the public keys. I just read the Abstract of the paper, and I see your point about the = attacker only observing the public keys. How about: =20 Implementations must randomly generate nonces and private keys. The use of inadequate pseudo-random number generators (PRNGs) to generate cryptographic keys can result in little or no security. An = attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of = possibilities, rather than brute force searching the whole key space. As an example = of predictable random numbers see CVE-2008-0166 [=E2=80=A6], and some = consequences of low-entropy random numbers are discussed in Mining Your Ps and Qs = [...]. The generation of quality random numbers is difficult. ISO/IEC = 20543:2019 [=E2=80=A6], NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [=E2=80=A6], BCP = 106 [RFC4086], and others offers valuable guidance in this area. > =20 > =20 > =C2=B7 I understand that key generation is out of scope and = maybe this needs to be a separate work item, but recommending periodic = replacement of the certs without recommending a suitable mechanism = leaves this solution with a big hole. > =20 > I do not agree. It does offer the protocol for obtaining replacement = certificates for devices that are able to generating a fresh = public/private key pair. Getting more detailed would be algorithm = specific, which is not appropriate in this document. > =20 > Not really, because the =E2=80=9Cprotocol=E2=80=9D described here is: = Client sends a CSR, Server responds with a complete client configuration = blob. This obviously doesn=E2=80=99t work for an already deployed = client. I am really confused. The document is an addition to the Secure Zero = Touch Provisioning (SZTP). As such, it is technique to securely = provision a networking device when it is booting in a factory-default = state. That should happen at the initial deployment or after the device = is reset to the factory configuration. This is not the protocol for use = with an already deployed client. Russ --Apple-Mail=_794155BA-5AF1-4DEE-8C1A-04D478DAA00D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yaron:

 
Thank you for addressing my comments, I = am happy with most of your responses but I do have a few remaining = questions:
 

=C2=B7         The commit that removes the dependency on = IDevID and LDevID does not fix the issue of non-orthogonality. There is = very detailed description for CMP and CMC, but nothing for PKCS #10 = (p10-csr). Does it mean =E2=80=9Cuse PKCS#10 out of the box and it=E2=80=99= ll just work=E2=80=9D? Or does it mean =E2=80=9Cthe usage of PKCS#10 for = these certs is still TBD=E2=80=9D?

 
PKCS#10 is pretty simple.  Are you aware of anything = more that ought to be said?
 
I think we should = explicitly mention what this method *cannot* provide. = As far as I can tell, none of the origin authentication methods are = available when using PKCS #10 directly without wrapping it further.

That is reasonable.  I will talk with my = co-authors and see if we can come up with a brief = summary.
 

=C2=B7         I suggest to add the following reference = to the paragraph on quality randomness, as a strong proof that this is a = real world concern:

 
Heninger, N., Durumeric, Z., Wustrow, E., and J. Halderman, = "Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network = Devices", Proceedings of the 21st USENIX Security Symposium , = August 2012, <https://factorable.net/>.
 
In = another thread, something like this was suggested for another = document:
 
   Implementations must = randomly generate nonces and private keys.
   The use of inadequate pseudo-random number = generators (PRNGs) to
   generate = cryptographic keys can result in little or no security. An attacker
   may find it much easier to reproduce the PRNG = environment that
   produced the keys, = searching the resulting small set of possibilities,
   rather than brute force searching the whole key = space. As example for
   predictable = random numbers see CVE-2008-0166 [=E2=80=A6]. The generation
   of quality random numbers is = difficult. ISO/IEC 20543:2019 [=E2=80=A6],
   NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS = 31 V2.0 [=E2=80=A6], BCP 106 [RFC4086], and
   others offers valuable guidance in this = area.
 
If this approach works for you, we'll dig up the appropriate = references.
 
Yes, but the Heninger et = al. reference is a better fit than the Debian CVE because (1) it = discusses network devices rather than servers and (2) it shows how even = less broken RNGs can be exploited by a network attacker that only sees = the public keys.

I just read the Abstract of the paper, and I see your = point about the attacker only observing the public keys.  How = about:

 
  =  Implementations must randomly generate nonces and private = keys.
   The use of = inadequate pseudo-random number generators (PRNGs) = to
   generate = cryptographic keys can result in little or no security. An = attacker
   may find it = much easier to reproduce the PRNG environment = that
   produced = the keys, searching the resulting small set of = possibilities,
  =  rather than brute force searching the whole key space. As an = example of
  =  predictable random numbers see CVE-2008-0166 [=E2=80=A6], and some = consequences
  =  of low-entropy random numbers are discussed = in Mining Your Ps and Qs [...].
  =  The generation of quality random numbers is difficult. ISO/IEC = 20543:2019 [=E2=80=A6],
   NIST SP = 800-90A Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [=E2=80=A6], BCP 106 = [RFC4086], and
  =  others offers valuable guidance in this = area.

 
 

=C2=B7         I understand that key generation is out of = scope and maybe this needs to be a separate work item, but recommending = periodic replacement of the certs without recommending a suitable = mechanism leaves this solution with a big hole.

 
I do not agree.  It does offer the protocol = for obtaining replacement certificates for devices that are able to = generating a fresh public/private key pair.  Getting more detailed = would be algorithm specific, which is not appropriate in this = document.
 
Not really, because = the =E2=80=9Cprotocol=E2=80=9D described here is: Client sends a CSR, = Server responds with a complete client configuration blob. This = obviously doesn=E2=80=99t work for an already deployed = client.

I = am really confused.  The document  is an addition to = the Secure Zero Touch Provisioning (SZTP).  As such, it is = technique to securely provision a networking device when it is booting = in a factory-default state.  That should happen at the initial = deployment or after the device is reset to the factory configuration. =  This is not the protocol for use with an already deployed = client.

Russ

= --Apple-Mail=_794155BA-5AF1-4DEE-8C1A-04D478DAA00D-- From nobody Sun Nov 28 12:23:17 2021 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 1AB183A096C; Sun, 28 Nov 2021 12:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, 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 VJ1MZPei1j1U; Sun, 28 Nov 2021 12:23:05 -0800 (PST) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 3715C3A096B; Sun, 28 Nov 2021 12:23:05 -0800 (PST) Received: by mail-ed1-x52e.google.com with SMTP id t5so63300556edd.0; Sun, 28 Nov 2021 12:23:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:date:from:subject:thread-topic:in-reply-to:message-id :references:to:cc:content-transfer-encoding; bh=IQCuWtZe20FWcu7mYhHLJQ2psYQwDN4cDtGXphk6qWI=; b=L0mpGM7HAEx6cw0v21nv5RvMpxocDRUERfbT5KzBGVJ6yc3NPAXF+YNRfTFyE+HW5S 1nnM4PZsQeyAUW9JsDfs1hL+VSW+Ey01+xDzoscisBG/Guckd72MJE1SpyN7EvlUIe42 Bk8B7cAgHphdqnM06vHd92pBH7HV4IHJCJuB5RJIS63h9ld6XhRgXrdPlO3fPuXbVeNy yolsyhH/UyeoP16BRmKcL3Bx03mlZ7piN48ZKfEQavSYL8oi897yy54JfrxtWK0J4jHU TNXZwTpvENMb8oho03mHDxxENB9Mp9KDRCwdIfa55Q7eKPs3YlhW/FfNLZyxOwc4Y/Ge yopQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:date:from:subject:thread-topic :in-reply-to:message-id:references:to:cc:content-transfer-encoding; bh=IQCuWtZe20FWcu7mYhHLJQ2psYQwDN4cDtGXphk6qWI=; b=1Hd5C8gsNuzph6jXxRR5CbbncNVs1Rughv6Rd5cyeMiYyNRTMr3NjajhWM6vSbsP9m J66hZpbZTX4rtjOMhM2JGNUZWf1N6ZS78Ul7B8CF60avPhEf3WeMD1jO7dDClL5v184Z iwlAVaFGAUR0vANs8foKFxj/glmQKycB4tlAZBsyyOjsZilegaB9TRLFBFinVYydz6bS nkPNvXJjXjsaGhzYzzats4LMXaWWHK0IqrZQIkuzM/wJa++phpZyYalSGELrD8B3Lxs0 D5w5RH1o21qBuP7AYL+u2itd3Wtt5yI/lzOZ0Cbvtf/SwqNx9An0Z0f8zuYzpzUZPmBv snhg== X-Gm-Message-State: AOAM532nq6Kc+1evgw3scs9xe5EIw2n29RQWhABugNQHq2oDMlSLotWy 2ZTOu1u9ml7aG93n1sYgznFJGowv+iQ= X-Google-Smtp-Source: ABdhPJw64XQ0QC3U4qg8e8UEiaua1GkoS6zGR7cUbnkAgBB9v2A7n9FMaBO5MEKxh0ic3JXJmtH+oA== X-Received: by 2002:a05:6402:445:: with SMTP id p5mr68578548edw.110.1638130978683; Sun, 28 Nov 2021 12:22:58 -0800 (PST) Received: from MacBook-Pro.local (IGLD-84-229-147-189.inter.net.il. [84.229.147.189]) by smtp.gmail.com with ESMTPSA id d18sm7931129edj.23.2021.11.28.12.22.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Nov 2021 12:22:58 -0800 (PST) MIME-Version: 1.0 Date: Sun, 28 Nov 2021 22:22:54 +0200 From: Yaron Sheffer Thread-Topic: Re: Secdir last call review of draft-ietf-netconf-sztp-csr-11 In-Reply-To: Message-ID: <003BF754-E414-384E-91DA-47BFB117C0CE@hxcore.ol> References: <163717559932.18384.2156774121641934785@ietfa.amsl.com> <0100017d49a045e3-d1919799-0247-4fb5-abe6-d0c661f80f6a-000000@email.amazonses.com> <8EC1807D-C357-DB41-8D94-FF8F0A2EF13C@hxcore.ol>, To: Russ Housley Cc: Kent Watsen , IETF SecDir , "draft-ietf-netconf-sztp-csr.all@ietf.org" , "last-call@ietf.org" , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Archived-At: Subject: Re: [netconf] Secdir last call review of draft-ietf-netconf-sztp-csr-11 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, 28 Nov 2021 20:23:11 -0000

Hi Russ,

 

Thank you for the q= uick response.

 

We are in agreement re: PKCS #10 and randomness.

 

In the = third point below (certificate rotation), I understand why the editors see = it as out of scope. But we are still leaving implementers with no guidance,= and we=E2=80=99ve all seen enough real world cases where this leads to peo= ple ignoring the vague =E2=80=9Cregenerate the private key=E2=80=9D. Let me= try to offer an alternative.

 = ;

Old:

 

In cases where the SZTP-client does = not possess an HSM, or otherwise is unable to use an HSM for the private ke= y, it is RECOMMENDED to regenerate the private key (and associated identity= certificates) periodically. Details for how to generate a new private key = and associate a new identity certificate are outside the scope of this docu= ment.

 

New:

 

In cases where the SZTP-client does not possess an HSM, or o= therwise is unable to use an HSM for the private key, it is RECOMMENDED to = regenerate the private key (and associated identity certificates) periodica= lly. If CMP or CMC was used for initial certificate provisioning, it is REC= OMMENDED to reuse the protocol (CMC or CMP) for periodic certificate regist= ration. Similarly, implementations SHOULD also reuse the initial origin aut= hentication method.

 

Thanks,

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Yaron

 

 

From: Russ Housley <housley@vigilsec.co= m>
Date: Sunday, November 28, 2021 at 20:10
To: Yaro= n Sheffer <yaronf.ietf@gmail.com>
Cc: Kent Watsen <kent+= ietf@watsen.net>, IETF SecDir <secdir@ietf.org>, draft-ietf-netcon= f-sztp-csr.all@ietf.org <draft-ietf-netconf-sztp-csr.all@ietf.org>, l= ast-call@ietf.org <last-call@ietf.org>, netconf@ietf.org <netconf@= ietf.org>
Subject: Re: Secdir last call review of draft-ietf-n= etconf-sztp-csr-11

Yaron:

 

 

Thank you for = addressing my comments, I am happy with most of your responses but I do hav= e a few remaining questions:

 =

=C2=B7 &nbs= p;      &= nbsp;The commit that removes the dependency on IDevID and LDe= vID does not fix the issue of non-orthogonality. There is very detailed des= cription for CMP and CMC, but nothing for PKCS #10 (p10-csr). Does it mean = =E2=80=9Cuse PKCS#10 out of the box and it=E2=80=99ll just work=E2=80=9D? O= r does it mean =E2=80=9Cthe usage of PKCS#10 for these certs is still TBD= =E2=80=9D?

 

=

PKCS#10 is pretty simple.  Are you aware of anything = more that ought to be said?

 =

I thin= k we should explicitly mention what this method *cannot* provide. As= far as I can tell, none of the origin authentication methods are available= when using PKCS #10 directly without wrapping it further.

 

That is reasonable.  I will talk with my co-authors and see if = we can come up with a brief summary.

 

=C2=B7         I suggest to add the following= reference to the paragraph on quality randomness, as a strong proof that t= his is a real world concern:

 

<= /div>

Heninger, N., Durumeric, Z., Wustrow, E., and J. Hald= erman, "Mining Your Ps and Qs: Detection of Widespread Weak Keys in Ne= twork Devices", Proceedings of the 21st USENIX Security Symposium , August 2012, <<= a href=3D"https://factorable.net/">https://factorable.net/>.

=

 

=

In another thread, something like this was suggested for another= document:

<= p class=3DMsoNormal style=3D'margin-left:.5in'> 

<= /div>

   Implementations must randomly generate n= onces and private keys.

  &nb= sp;The use of inadequate pseudo-random number generators (PRNGs) to

   generate cryptographic keys can r= esult in little or no security. An attacker

=

   may find it much easier to reproduce the PRNG environment= that

   produced the keys, s= earching the resulting small set of possibilities,

   rather than brute force searching the whole key sp= ace. As example for

   predic= table random numbers see CVE-2008-0166 [=E2=80=A6]. The generation

   of quality random numbers is diffi= cult. ISO/IEC 20543:2019 [=E2=80=A6],

<= div style=3D'margin-left:.5in'>

   NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [= =E2=80=A6], BCP 106 [RFC4086], and

&nbs= p;  others offers valuable guidance in this area.

<= /div>

 

If this ap= proach works for you, we'll dig up the appropriate references.

 

Yes, but = the Heninger et al. reference is a better fit than the Debian CVE because (= 1) it discusses network devices rather than servers and (2) it shows how ev= en less broken RNGs can be exploited by a network attacker that only sees t= he public keys.

 

I just read the Abstract of th= e paper, and I see your point about the attacker only observing the public = keys.  How about:

 

<= p class=3DMsoNormal style=3D'margin-left:.5in'>=  

   Implementations must r= andomly generate nonces and private keys.

<= p class=3DMsoNormal style=3D'margin-left:.5in'>=    The use of inadequate pseudo-random number generators (PRNGs) = to

   generate cryptographic key= s can result in little or no security. An attacker

   may find it much easier to reproduce the PRNG environ= ment that

   produced the keys, = searching the resulting small set of possibilities,

   rather than brute force searching the whole key spac= e. As an example of

   predictab= le random numbers see CVE-2008-0166 [=E2=80=A6], and some consequences

   of low-entropy random numbers are= discussed in Mining Your Ps and Qs [...].

=

   The gener= ation of quality random numbers is difficult. ISO/IEC 20543:2019 [=E2=80=A6= ],

   NIST SP 800-90A Rev.1 [=E2=80=A6]= , BSI AIS 31 V2.0 [=E2=80=A6], BCP 106 [RFC4086], and

=

   others offers valuable guidance in this area.



 

 

=C2=B7     &nbs= p;   I und= erstand that key generation is out of scope and maybe this needs to be a se= parate work item, but recommending periodic replacement of the certs withou= t recommending a suitable mechanism leaves this solution with a big hole.

 

=

I do not agree.  It does offer the protocol f= or obtaining replacement certificates for devices that are able to generati= ng a fresh public/private key pair.  Getting more detailed would be al= gorithm specific, which is not appropriate in this document.

=

 

Not really, because the =E2=80=9Cprotocol=E2=80= =9D described here is: Client sends a CSR, Server responds with a complete = client configuration blob. This obviously doesn=E2=80=99t work for an alrea= dy deployed client.

 

I am really confused.  The = document  is an addition to the Secure Zero Touch Provisioning (S= ZTP).  As such, it is technique to securely provision a networking dev= ice when it is booting in a factory-default state.  That should happen= at the initial deployment or after the device is reset to the factory conf= iguration.  This is not the protocol for use with an already deployed = client.

 

Russ

 

= From nobody Mon Nov 29 07:40:09 2021 Return-Path: <0100017d6c5a2a02-0f81b796-78d5-402b-9cc3-025ec2f85cef-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 C8D823A0B0D; Mon, 29 Nov 2021 07:39:55 -0800 (PST) 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 (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 Z97GZ8BCMkq8; Mon, 29 Nov 2021 07:39:50 -0800 (PST) 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 DA5603A0B08; Mon, 29 Nov 2021 07:39:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1638200388; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=JIptoE02WoZgfDXt7yxvddmvk6gsxmVXCAlobwtXr4g=; b=H0oqxpjz+O/4dQiQy7464qDp/8l3n0cfob/VAHWhcGwLeYNQ8G2Omhho51t6XGXj IOTPyM5ebZfF3WAPUVGVyAqRgTEQkWOU4TGc2EOqNby/MKOaKbdx/QCwGX9NUCDYv2T TGlZvA6Y4mhMyFNxRjD88wEkK1yxTVd1+IGkTRQo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Kent Watsen In-Reply-To: <163773212617.25289.11973969487179870918@ietfa.amsl.com> Date: Mon, 29 Nov 2021 15:39:48 +0000 Cc: gen-art@ietf.org, last-call@ietf.org, draft-ietf-netconf-sztp-csr.all@ietf.org, "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <0100017d6c5a2a02-0f81b796-78d5-402b-9cc3-025ec2f85cef-000000@email.amazonses.com> References: <163773212617.25289.11973969487179870918@ietfa.amsl.com> To: Meral Shirazipour X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.11.29-54.240.48.92 Archived-At: Subject: Re: [netconf] Genart last call review of draft-ietf-netconf-sztp-csr-11 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, 29 Nov 2021 15:39:56 -0000 Hi Meral, Thank you for your review! I have fixed the typo found in our local = copy. An updated draft with this fix will be posted as soon as the = Secdir review discussion completes. Thanks again, Kent (and Russ and Sean) > On Nov 24, 2021, at 12:35 AM, Meral Shirazipour via Datatracker = wrote: >=20 > Reviewer: Meral Shirazipour > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-netconf-sztp-csr-11 >=20 > Reviewer: Meral Shirazipour > Review Date: 2021-11-23 > IETF LC End Date: 2021-11-23 > IESG Telechat date: NA >=20 >=20 > Summary: This draft is ready to be published as Standards Track RFC. >=20 >=20 > Major issues: >=20 >=20 > Minor issues: >=20 >=20 > Nits/editorial comments: >=20 > [Page 3], Section 1.1 "bootstraped"->"bootstrapped" >=20 >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Nov 29 08:38:47 2021 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 413993A0AE4 for ; Mon, 29 Nov 2021 08:38:45 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7lb2wYeXko3 for ; Mon, 29 Nov 2021 08:38:40 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76F703A0687 for ; Mon, 29 Nov 2021 08:38:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 615B3300C09 for ; Mon, 29 Nov 2021 11:38:42 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Tx7kohpO7QjH for ; Mon, 29 Nov 2021 11:38:35 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 09928300B30; Mon, 29 Nov 2021 11:38:35 -0500 (EST) From: Russ Housley Message-Id: <9BF6DBF5-9394-4CFE-A8E5-E064AFE3A76D@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F8B832BD-0538-4803-8053-23DD31DE5E6A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Mon, 29 Nov 2021 11:38:31 -0500 In-Reply-To: <003BF754-E414-384E-91DA-47BFB117C0CE@hxcore.ol> Cc: "last-call@ietf.org" , Kent Watsen , "draft-ietf-netconf-sztp-csr.all@ietf.org" , "netconf@ietf.org" , IETF SecDir To: Yaron Sheffer References: <163717559932.18384.2156774121641934785@ietfa.amsl.com> <0100017d49a045e3-d1919799-0247-4fb5-abe6-d0c661f80f6a-000000@email.amazonses.com> <8EC1807D-C357-DB41-8D94-FF8F0A2EF13C@hxcore.ol> <003BF754-E414-384E-91DA-47BFB117C0CE@hxcore.ol> X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [netconf] [Last-Call] Secdir last call review of draft-ietf-netconf-sztp-csr-11 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, 29 Nov 2021 16:38:45 -0000 --Apple-Mail=_F8B832BD-0538-4803-8053-23DD31DE5E6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yaron: Perhaps the word "regenerate" is the thing that is causing confusion. Suggestion: In cases where the SZTP-client does not possess an HSM, or otherwise is = unable to use an HSM for the private key, it is RECOMMENDED that the = device periodically reset the configuration to the factory default and = repeat the SZTP protocol. Repeating the SZTP protocol may cause the = device to generate a fresh private key (and associated identity = certificates). Details for how to generate a new private key and = associate a new identity certificate are outside the scope of this = document. Russ > On Nov 28, 2021, at 3:22 PM, Yaron Sheffer = wrote: >=20 > Hi Russ, > =20 > Thank you for the quick response. > =20 > We are in agreement re: PKCS #10 and randomness. > =20 > In the third point below (certificate rotation), I understand why the = editors see it as out of scope. But we are still leaving implementers = with no guidance, and we=E2=80=99ve all seen enough real world cases = where this leads to people ignoring the vague =E2=80=9Cregenerate the = private key=E2=80=9D. Let me try to offer an alternative. > =20 > Old: > =20 > In cases where the SZTP-client does not possess an HSM, or otherwise = is unable to use an HSM for the private key, it is RECOMMENDED to = regenerate the private key (and associated identity certificates) = periodically. Details for how to generate a new private key and = associate a new identity certificate are outside the scope of this = document. > =20 > New: > =20 > In cases where the SZTP-client does not possess an HSM, or otherwise = is unable to use an HSM for the private key, it is RECOMMENDED to = regenerate the private key (and associated identity certificates) = periodically. If CMP or CMC was used for initial certificate = provisioning, it is RECOMMENDED to reuse the protocol (CMC or CMP) for = periodic certificate registration. Similarly, implementations SHOULD = also reuse the initial origin authentication method. > =20 > Thanks, > Yaron > =20 > =20 > From: Russ Housley > > Date: Sunday, November 28, 2021 at 20:10 > To: Yaron Sheffer > > Cc: Kent Watsen >, = IETF SecDir >, = draft-ietf-netconf-sztp-csr.all@ietf.org = = >, last-call@ietf.org = >, netconf@ietf.org = > > Subject: Re: Secdir last call review of draft-ietf-netconf-sztp-csr-11 >=20 > Yaron: > =20 > =20 > Thank you for addressing my comments, I am happy with most of your = responses but I do have a few remaining questions: > =20 > =C2=B7 The commit that removes the dependency on IDevID and = LDevID does not fix the issue of non-orthogonality. There is very = detailed description for CMP and CMC, but nothing for PKCS #10 = (p10-csr). Does it mean =E2=80=9Cuse PKCS#10 out of the box and it=E2=80=99= ll just work=E2=80=9D? Or does it mean =E2=80=9Cthe usage of PKCS#10 for = these certs is still TBD=E2=80=9D? > =20 > PKCS#10 is pretty simple. Are you aware of anything more that ought = to be said? > =20 > I think we should explicitly mention what this method *cannot* = provide. As far as I can tell, none of the origin authentication methods = are available when using PKCS #10 directly without wrapping it further. > =20 > That is reasonable. I will talk with my co-authors and see if we can = come up with a brief summary. > =20 >=20 > =C2=B7 I suggest to add the following reference to the = paragraph on quality randomness, as a strong proof that this is a real = world concern: > =20 > Heninger, N., Durumeric, Z., Wustrow, E., and J. Halderman, "Mining = Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices", = Proceedings of the 21st USENIX Security Symposium , August 2012, = >. > =20 > In another thread, something like this was suggested for another = document: > =20 > Implementations must randomly generate nonces and private keys. > The use of inadequate pseudo-random number generators (PRNGs) to > generate cryptographic keys can result in little or no security. An = attacker > may find it much easier to reproduce the PRNG environment that > produced the keys, searching the resulting small set of = possibilities, > rather than brute force searching the whole key space. As example = for > predictable random numbers see CVE-2008-0166 [=E2=80=A6]. The = generation > of quality random numbers is difficult. ISO/IEC 20543:2019 [=E2=80=A6= ], > NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [=E2=80=A6], BCP = 106 [RFC4086], and > others offers valuable guidance in this area. > =20 > If this approach works for you, we'll dig up the appropriate = references. > =20 > Yes, but the Heninger et al. reference is a better fit than the Debian = CVE because (1) it discusses network devices rather than servers and (2) = it shows how even less broken RNGs can be exploited by a network = attacker that only sees the public keys. > =20 > I just read the Abstract of the paper, and I see your point about the = attacker only observing the public keys. How about: > =20 > =20 > Implementations must randomly generate nonces and private keys. > The use of inadequate pseudo-random number generators (PRNGs) to > generate cryptographic keys can result in little or no security. An = attacker > may find it much easier to reproduce the PRNG environment that > produced the keys, searching the resulting small set of = possibilities, > rather than brute force searching the whole key space. As an = example of > predictable random numbers see CVE-2008-0166 [=E2=80=A6], and some = consequences > of low-entropy random numbers are discussed in Mining Your Ps and = Qs [...]. > The generation of quality random numbers is difficult. ISO/IEC = 20543:2019 [=E2=80=A6], > NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [=E2=80=A6], BCP = 106 [RFC4086], and > others offers valuable guidance in this area. >=20 >=20 > =20 > =20 > =C2=B7 I understand that key generation is out of scope and = maybe this needs to be a separate work item, but recommending periodic = replacement of the certs without recommending a suitable mechanism = leaves this solution with a big hole. > =20 > I do not agree. It does offer the protocol for obtaining replacement = certificates for devices that are able to generating a fresh = public/private key pair. Getting more detailed would be algorithm = specific, which is not appropriate in this document. > =20 > Not really, because the =E2=80=9Cprotocol=E2=80=9D described here is: = Client sends a CSR, Server responds with a complete client configuration = blob. This obviously doesn=E2=80=99t work for an already deployed = client. > =20 > I am really confused. The document is an addition to the Secure Zero = Touch Provisioning (SZTP). As such, it is technique to securely = provision a networking device when it is booting in a factory-default = state. That should happen at the initial deployment or after the device = is reset to the factory configuration. This is not the protocol for use = with an already deployed client. > =20 > Russ > =20 > --=20 > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call = --Apple-Mail=_F8B832BD-0538-4803-8053-23DD31DE5E6A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yaron:

Perhaps the word "regenerate" is the thing that is = causing confusion.

Suggestion:

In = cases where the SZTP-client does not possess an HSM, or otherwise is = unable to use an HSM for the private key, it is RECOMMENDED that the = device periodically reset the configuration to the factory default and = repeat the SZTP protocol.  Repeating the SZTP protocol may cause = the device to generate a fresh private key (and associated identity = certificates). Details for how to generate a new private key and = associate a new identity certificate are outside the scope of this = document.

Russ



On = Nov 28, 2021, at 3:22 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Hi Russ,
 
Thank you for the quick = response.
 
We are in agreement re: = PKCS #10 and randomness.
 
In the third point below = (certificate rotation), I understand why the editors see it as out of = scope. But we are still leaving implementers with no guidance, and = we=E2=80=99ve all seen enough real world cases where this leads to = people ignoring the vague =E2=80=9Cregenerate the private key=E2=80=9D. = Let me try to offer an alternative.
 
Old:
 
In cases where the SZTP-client does not possess = an HSM, or otherwise is unable to use an HSM for the private key, it is = RECOMMENDED to regenerate the private key (and associated identity = certificates) periodically. Details for how to generate a new private = key and associate a new identity certificate are outside the scope of = this document.
 
New:
 
In cases where the = SZTP-client does not possess an HSM, or otherwise is unable to use an = HSM for the private key, it is RECOMMENDED to regenerate the private key = (and associated identity certificates) periodically. If CMP or CMC was = used for initial certificate provisioning, it is RECOMMENDED to reuse = the protocol (CMC or CMP) for periodic certificate registration. = Similarly, implementations SHOULD also reuse the initial origin = authentication method.
 
Thanks,
          &nb= sp;     Yaron
 
 
From: Russ Housley <housley@vigilsec.com>
Date: Sunday, November 28, = 2021 at 20:10
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: Kent Watsen <kent+ietf@watsen.net>, = IETF SecDir <secdir@ietf.org>, draft-ietf-netconf-sztp-csr.all@ietf.org <draft-ietf-netconf-sztp-csr.all@ietf.org>, last-call@ietf.org <last-call@ietf.org>, netconf@ietf.org <netconf@ietf.org>
Subject: Re: Secdir last call = review of draft-ietf-netconf-sztp-csr-11

Yaron:
 
 
Thank you for addressing my comments, I am happy with most of = your responses but I do have a few remaining questions:
 

=C2=B7         The commit that = removes the dependency on IDevID and LDevID does not fix the issue of = non-orthogonality. There is very detailed description for CMP and CMC, = but nothing for PKCS #10 (p10-csr). Does it mean =E2=80=9Cuse PKCS#10 = out of the box and it=E2=80=99ll just work=E2=80=9D? Or does it mean = =E2=80=9Cthe usage of PKCS#10 for these certs is still TBD=E2=80=9D?

 
PKCS#10 is pretty simple.  Are you aware of anything = more that ought to be said?
 
I think we should explicitly mention what this method *cannot* provide. As far as I can tell, none of the origin = authentication methods are available when using PKCS #10 directly = without wrapping it further.
 
That= is reasonable.  I will talk with my co-authors and see if we can = come up with a brief summary.
 

=C2=B7         I suggest to add the = following reference to the paragraph on quality randomness, as a strong = proof that this is a real world concern:

 
Heninger, N., Durumeric, Z., Wustrow, E., and J. Halderman, = "Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network = Devices", Proceedings of the 21st USENIX Security Symposium , = August 2012, <https://factorable.net/>.
 
In another thread, something like this was suggested for = another document:
 
   Implementations must randomly generate nonces = and private keys.
   The use of inadequate = pseudo-random number generators (PRNGs) to
   generate cryptographic keys can result in little = or no security. An attacker
   may find it much easier to = reproduce the PRNG environment that
   produced the keys, searching the resulting small = set of possibilities,
   rather than brute force = searching the whole key space. As example for
   predictable random numbers see CVE-2008-0166 = [=E2=80=A6]. The generation
   of quality random numbers = is difficult. ISO/IEC 20543:2019 [=E2=80=A6],
   NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS = 31 V2.0 [=E2=80=A6], BCP 106 [RFC4086], and
   others offers valuable guidance in this = area.
 
If this approach works for you, we'll = dig up the appropriate references.
 
Yes, but the Heninger et al. reference is a better fit than = the Debian CVE because (1) it discusses network devices rather than = servers and (2) it shows how even less broken RNGs can be exploited by a = network attacker that only sees the public keys.
 
I = just read the Abstract of the paper, and I see your point about the = attacker only observing the public keys.  How about:
 
 
   Implementations must randomly generate nonces = and private keys.
   The use of inadequate pseudo-random number = generators (PRNGs) to
   generate cryptographic keys can result in little = or no security. An attacker
   may find it much easier to reproduce the PRNG = environment that
   produced the keys, searching the resulting small = set of possibilities,
   rather than brute force searching the whole key = space. As an example of
   predictable random numbers see CVE-2008-0166 = [=E2=80=A6], and some consequences
   of low-entropy = random numbers are discussed in Mining Your Ps and Qs = [...].
   The generation of quality = random numbers is difficult. ISO/IEC 20543:2019 [=E2=80=A6],
   NIST SP 800-90A = Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [=E2=80=A6], BCP 106 [RFC4086], = and
  =  others offers valuable guidance in this area.


 
 

=C2=B7         I understand that = key generation is out of scope and maybe this needs to be a separate = work item, but recommending periodic replacement of the certs without = recommending a suitable mechanism leaves this solution with a big = hole.

 
I do not agree. =  It does offer the protocol for obtaining replacement certificates = for devices that are able to generating a fresh public/private key pair. =  Getting more detailed would be algorithm specific, which is not = appropriate in this document.
 
Not really, because the =E2=80=9Cprotocol=E2=80=9D described = here is: Client sends a CSR, Server responds with a complete client = configuration blob. This obviously doesn=E2=80=99t work for an already = deployed client.
 
I = am really confused.  The document  is an addition to = the Secure Zero Touch Provisioning (SZTP).  As such, it is = technique to securely provision a networking device when it is booting = in a factory-default state.  That should happen at the initial = deployment or after the device is reset to the factory configuration. =  This is not the protocol for use with an already deployed = client.
 
Russ
 
-- last-call mailing list
last-call@ietf.org
https://www.ietf.org/mailman/listinfo/last-call
= --Apple-Mail=_F8B832BD-0538-4803-8053-23DD31DE5E6A-- From nobody Mon Nov 29 09:55:31 2021 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 576CB3A03EA; Mon, 29 Nov 2021 09:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, 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 1QB0D2zm6P4s; Mon, 29 Nov 2021 09:55:17 -0800 (PST) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 AA5443A0332; Mon, 29 Nov 2021 09:55:16 -0800 (PST) Received: by mail-ed1-x536.google.com with SMTP id x6so75116900edr.5; Mon, 29 Nov 2021 09:55:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:date:from:subject:thread-topic:in-reply-to:message-id :references:to:cc:content-transfer-encoding; bh=bvdX+9/FGFCS7rTpFCLU1nAZkzM210QJKAWVxrzx5NI=; b=aZDjCtKsdP/VvbIUaUAN3N2JikdkCNBFsUDCnAkbWG36quiDlmGnxEOouE/pryzJCH Bri2DFm2mAudte/1r7pHiBbcFIGa0tKsQjeEX2YbIV6A8SUsMPIVzBY4zZ4slaPBdVly xfSQzwWxeUDtLLJKl7IJhyvCuKAWNi0QeRwgvKtwuDG4HlB9I/KHFpmG38Q+jZ8zcMRY U2KW+a4Xxw9l//m7Eik7NDK0RsN1OhemV3ZAZON1ez7Rc0AG4j2W9x/cwZqYT7jYo7B3 OPE9F2oc8TOuFOUI+//Dlx42G70G2Ow3DLJSr6zBbKo5cDFpJrfvpDYOvFA1BgkpR22x oQDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:date:from:subject:thread-topic :in-reply-to:message-id:references:to:cc:content-transfer-encoding; bh=bvdX+9/FGFCS7rTpFCLU1nAZkzM210QJKAWVxrzx5NI=; b=ZJfB+qojULuC7HstDSV3b5nIpbuu02CC1pa7RujufWqHPg4tcQIETHFiMLeedK/T+J u2jZwuHjSKZAYNCtY7U4cMuyhFmXztZxB1PxVj9ESj2Cs5DC1OdbteKPSJ2o+Bn17FbL +vkbK/vN0EFpwYftkuvlGIErThYeqlRon0tGvT1Mbb32FolNMfv487gXpzCFt2Ny2oBR 7RmgRFFbcHygvS0MRZRoFretiPNnNQZtPVk5eY8eBOYej11D+5CtV+6n6el8W44pOKgc rrtL8Jtk7mQCZFXBcQl9UMdhNJX+N0UjfuMb0Qu9AnlL4ckr64we8gfmnMZ9/ER65T8+ qeoQ== X-Gm-Message-State: AOAM533WyXQV144xE4Lb6DEe99fNa16VwejMPfh6tyR020ELuwyXnrc5 /PMmNxfYhYwf0Pkor765L0DL7PusVvg= X-Google-Smtp-Source: ABdhPJxovu03zAE6yR/eJyDVEzwFveaanDu6nh8HCIrVB9KdTI0n8XwXlICQEvYHgTCzGZ28Is3zAA== X-Received: by 2002:a17:906:4fc7:: with SMTP id i7mr38202811ejw.514.1638208513156; Mon, 29 Nov 2021 09:55:13 -0800 (PST) Received: from MacBook-Pro.local (IGLD-84-229-147-189.inter.net.il. [84.229.147.189]) by smtp.gmail.com with ESMTPSA id sa17sm8240200ejc.123.2021.11.29.09.55.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Nov 2021 09:55:12 -0800 (PST) MIME-Version: 1.0 Date: Mon, 29 Nov 2021 19:55:08 +0200 From: Yaron Sheffer Thread-Topic: Re: [Last-Call] Secdir last call review of draft-ietf-netconf-sztp-csr-11 In-Reply-To: <9BF6DBF5-9394-4CFE-A8E5-E064AFE3A76D@vigilsec.com> Message-ID: <94FD2B17-7F8A-6843-9799-EF0C20F3F435@hxcore.ol> References: <163717559932.18384.2156774121641934785@ietfa.amsl.com> <0100017d49a045e3-d1919799-0247-4fb5-abe6-d0c661f80f6a-000000@email.amazonses.com> <8EC1807D-C357-DB41-8D94-FF8F0A2EF13C@hxcore.ol> <003BF754-E414-384E-91DA-47BFB117C0CE@hxcore.ol>, <9BF6DBF5-9394-4CFE-A8E5-E064AFE3A76D@vigilsec.com> To: Russ Housley Cc: "last-call@ietf.org" , Kent Watsen , "draft-ietf-netconf-sztp-csr.all@ietf.org" , "netconf@ietf.org" , IETF SecDir Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Archived-At: Subject: Re: [netconf] [Last-Call] Secdir last call review of draft-ietf-netconf-sztp-csr-11 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, 29 Nov 2021 17:55:22 -0000

Hi Russ,

 

I=E2=80=99m really = surprised that a factory reset is the right thing to do in this use case. B= ut you are the expert.

 =

The new text works for me.

 

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

 

From: Russ Housley <housley@vigilsec.com>
= Date: Monday, November 29, 2021 at 18:38
To: Yaron Sheffer= <yaronf.ietf@gmail.com>
Cc: last-call@ietf.org <last-ca= ll@ietf.org>, Kent Watsen <kent+ietf@watsen.net>, draft-ietf-netco= nf-sztp-csr.all@ietf.org <draft-ietf-netconf-sztp-csr.all@ietf.org>, = netconf@ietf.org <netconf@ietf.org>, IETF SecDir <secdir@ietf.org&= gt;
Subject: Re: [Last-Call] Secdir last call review of draft-iet= f-netconf-sztp-csr-11

Yaron:

 

Perhaps the word "regenerate" is t= he thing that is causing confusion.

 

Suggestion:

 

In cases where the S= ZTP-client does not possess an HSM, or otherwise is unable to use an HSM fo= r the private key, it is RECOMMENDED that the device periodically reset the= configuration to the factory default and repeat the SZTP protocol.  R= epeating the SZTP protocol may cause the device to generate a fresh private= key (and associated identity certificates). Details for how to generate a = new private key and associate a new identity certificate are outside the sc= ope of this document.

 

Russ

 

 

 

On Nov 28, 2021, at 3:22 PM, Yaron Sheffer <= ;yaronf.ietf@gmail.com> wro= te:

 

Hi Russ,

 

Thank you for the quick response.

 

We are in agreement re: P= KCS #10 and randomness.

 

In the third point below (certificate rotation),= I understand why the editors see it as out of scope. But we are still leav= ing implementers with no guidance, and we=E2=80=99ve all seen enough real w= orld cases where this leads to people ignoring the vague =E2=80=9Cregenerat= e the private key=E2=80=9D. Let me try to offer an alternative.<= /p>

 

Old:

 = ;

= In cases where the SZTP-client does not possess an HSM, or otherwise is una= ble to use an HSM for the private key, it is RECOMMENDED to regenerate the = private key (and associated identity certificates) periodically. Details fo= r how to generate a new private key and associate a new identity certificat= e are outside the scope of this document.

 

New:

=

 

=

In cases where the SZT= P-client does not possess an HSM, or otherwise is unable to use an HSM for = the private key, it is RECOMMENDED to regenerate the private key (and assoc= iated identity certificates) periodically. If CMP or CMC was used for initi= al certificate provisioning, it is RECOMMENDED to reuse the protocol (CMC o= r CMP) for periodic certificate registration. Similarly, implementations SH= OULD also reuse the initial origin authentication method.

 

Thanks,

 &n= bsp;            = ;  Yaron

 

 

Yaron:

<= /div>

 

&n= bsp;

Thank you for addr= essing my comments, I am happy with most of your responses but I do have a = few remaining questions:

 

=C2=B7       &nb= sp; The commit that = removes the dependency on IDevID and LDevID does not fix the issue of non-o= rthogonality. There is very detailed description for CMP and CMC, but nothi= ng for PKCS #10 (p10-csr). Does it mean =E2=80=9Cuse PKCS#10 out of the box= and it=E2=80=99ll just work=E2=80=9D? Or does it mean =E2=80=9Cthe usage o= f PKCS#10 for these certs is still TBD=E2=80=9D?

 

PKCS#10 is pretty simple.=  Are you aware of anything more that ought to be said?

=

 

I think we should explicitly mention what this = method *cannot* provide. As far as I can tell, none of the origin au= thentication methods are available when using PKCS #10 directly without wra= pping it further.

<= div style=3D'margin-left:.5in'>

 

That is reasonable.  I will = talk with my co-authors and see if we can come up with a brief summary.

 

=C2=B7&nb= sp;        I suggest to add the following reference to the p= aragraph on quality randomness, as a strong proof that this is a real world= concern:

 

Hen= inger, N., Durumeric, Z., Wustrow, E., and J. Halderman, "Mining Your = Ps and Qs: Detection of Widespread Weak Keys in Network Devices", Proc= eedings of the 21st USENIX Security Symposium , August 2012, <https://factorable.net/>.

=

 

In another th= read, something like this was suggested for another document:

 

&nb= sp;  Implementations must randomly generate nonces and private ke= ys.

   The use of inadequate pseudo-random number generators (PRNG= s) to

=

   generate cryptographic keys can result in little or no se= curity. An attacker

   may find it much easier to reproduce the PR= NG environment that

   produced the keys, searching the resulting = small set of possibilities,

   rather than brute force searching t= he whole key space. As example for

   predictable random numbers s= ee CVE-2008-0166 [=E2=80=A6]. The generation

   of quality random = numbers is difficult. ISO/IEC 20543:2019 [=E2=80=A6],

   = ;NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [=E2=80=A6], BCP 106 [R= FC4086], and

   others offers valuable guidance in this area.=

=  

If this approach works for you, we'll dig up the appropriate referenc= es.

 

Yes, but the Heninger et al. reference is a better fit than the Deb= ian CVE because (1) it discusses network devices rather than servers and (2= ) it shows how even less broken RNGs can be exploited by a network attacker= that only sees the public keys.

 

I just read = the Abstract of the paper, and I see your point about the attacker only obs= erving the public keys.  How about:

 

 

   Implementations must randomly= generate nonces and private keys.

&nbs= p;  The use of inadequate pseudo-random number generators (PRNGs) to

   generate cryptographic keys= can result in little or no security. An attacker

   may find it much easier to reproduce the PRNG envir= onment that

=

   produced the k= eys, searching the resulting small set of possibilities,

   rather than brute force searching the whole = key space. As an example of

  &nbs= p;predictable random numbers see CVE-2008-0166 [=E2=80=A6], and some conseq= uences

   of low-entropy rand= om numbers are discussed in Mining Your Ps and Qs [...].

   The generation of quality random number= s is difficult. ISO/IEC 20543:2019 [=E2=80=A6],

<= div>

   NIST SP 800-90A Rev.1 [=E2=80=A6], BSI AIS 31 V2.0 [= =E2=80=A6], BCP 106 [RFC4086], and

&nbs= p;  others offers valuable guidance in this area.

=

 

 

 

=C2=B7    &nbs= p;    I understand that key generation is out of scope and maybe this needs to b= e a separate work item, but recommending periodic replacement of the certs = without recommending a suitable mechanism leaves this solution with a big h= ole.

=

 

I do not agree.  It does offer the protocol = for obtaining replacement certificates for devices that are able to generat= ing a fresh public/private key pair.  Getting more detailed would be a= lgorithm specific, which is not appropriate in this document.

 

Not really, because the =E2=80=9Cprotocol=E2= =80=9D described here is: Client sends a CSR, Server responds with a comple= te client configuration blob. This obviously doesn=E2=80=99t work for an al= ready deployed client.

<= div>

 

<= p class=3DMsoNormal style=3D'margin-left:.5in'>I am really confused.  = The document  is an addition to the Secure Zero Touch Provisionin= g (SZTP).  As such, it is technique to securely provision a networking= device when it is booting in a factory-default state.  That should ha= ppen at the initial deployment or after the device is reset to the factory = configuration.  This is not the protocol for use with an already deplo= yed client.

=

 

=

Russ

 <= /p>

-- 
last-call mailing list
last-call@ietf.org
https://www.ie= tf.org/mailman/listinfo/last-call

 <= /p>=