From nobody Sun Aug 1 07:21: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 7A2D73A3E1C for ; Sun, 1 Aug 2021 07:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=ericsson.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 gQJldIUfduZ0 for ; Sun, 1 Aug 2021 07:21:27 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2046.outbound.protection.outlook.com [40.107.20.46]) (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 E2EB33A27A4 for ; Sun, 1 Aug 2021 07:21:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MCKoO2SO1IKs6Z2+MTy+90whVdwDIKbDJusE1cWsFWz4DJlTgV5vOlTfsp7YFTmSe9HSOVZnHi0+VMjPaJXkAeYD23dXMg9yYbM4ozMVuxnBpfQ6uWZaBLd42G7P0TDPpxJxoqHzN/mGAMUhdMlzH07foZ/5Yv9sG/vrlArVNUuOOyT0mMG2pkxdvLAPMdkL2cf49aqRew8am0FInvlIecfdP+IVytmjCK9dzZLVlgMzLeJCsTn5kYnHNOJyTcADgj5cJe8nDAlRNccRIH5Tel/FPpftb4Hy+i/RMFpjZZljz4KTUmGI+cdMce/7GMXBvf6mgKVPu3yvdHBfr8Dslw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vheEvbh4JRoAR6FiEWTwB9vV9rtYEFox+2UzfLQ5iCY=; b=Zjhq7pujPWSWXBKIPggq+rXpg3BHq17pMzsWqF3JxgZ54glSuWFV2bBMtrEHMoPGSZeXvVt895/L31BBifV45Knmjij60Fu4YTmxii8RLOFDj3tEqTi2kVJhWIWV9URT18pnzMAhIkg4fOTda+AE2IcpiYtvVospbBRqfff7q/iM0dKy8NxNzB0IggMUw1cXtaXn1zPPS6OynHCYXBg2ZAzGhNJ+FzgUHJQwrEM0XBUyn0UVdp9dwNmRMihf/u+MjBBGuNbhuPYuwvd8hfbtsuuMG73GPRpOggxHn/1bYTFz7eda/0bKNr8/CwtHycyOHuTMNuuKUuWDt90nQtv9sw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vheEvbh4JRoAR6FiEWTwB9vV9rtYEFox+2UzfLQ5iCY=; b=kGKgt7XPSJFdsPY/zg+06YoFm6lgudA5rd71UMWuVNn5ZkRiBNiukLNO5PFHryXTfkcRp8IJo7fm8j64fKiOt4xo8TK5KRpt3gXlH4uLmV1uuRlumXxZcuwnWVOmSMUh03oED5rs0pnLzoFvmzPPmb5PXDi6wtfUDzNdWvu8fhc= Received: from AM8PR07MB8230.eurprd07.prod.outlook.com (2603:10a6:20b:325::15) by AM8PR07MB8190.eurprd07.prod.outlook.com (2603:10a6:20b:321::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.21; Sun, 1 Aug 2021 14:21:24 +0000 Received: from AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625]) by AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625%9]) with mapi id 15.20.4373.018; Sun, 1 Aug 2021 14:21:24 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: "netconf@ietf.org" Thread-Topic: Comments on draft-claise-netconf-metadata-for-collection-02 Thread-Index: AdeGWTGMCp7qLP3ZQhytMbWLqTYUWQ== Date: Sun, 1 Aug 2021 14:21:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0e1e1937-6dcc-4af1-4af8-08d954f7a458 x-ms-traffictypediagnostic: AM8PR07MB8190: 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: hAawQZxSPojXQlcwV8ere0xx6CB482XWe7Oz5n2iGKXMsZIzdXaJbBgfOP4W1lAlPmIwwaQ1eKIwb167Zv7BEmTwGlpdOhYsFceo50+l/oFSHzEBjnlpXLxq9vYDkFE6AMY+pdlIIYN5S0rpkUEvQ0/KW3UyxJFLSGt6wXlVprKukyAbdH4tcHDEPs8aVbAUHJacQeTmoqx9XasuPJjUxKvWEchwSqG3Stueqyu5C712DKni3of9xk+ryWnJ3s3cFqE2ybGrJB7CLj7ffYAtl1YetlPF0hiuW3we7GY6FBR8wmsa260eiJNjLu1x/6oFeCgFQPDgZy7fSgrmRR4mWvqqY5mIw0UaRlVFLSCwWVoFy1Y4yw5HcoSDjN2FPicyMfp/QwFAZhFBlgkJGGBzrt6g3Uz9zmsArpRJBpZdl9HzGHv1LfOxS/fRJ3uMPJt818cUppNMk9+Y8NW67ZX9dQzyHaavy48P0whKJEqa5DfmT22s+nSNzoW69Ld2Gks+/rg3gFHu9mJh9p0Ykl5h+yfyQ55+MnOSOjeEGRQ/oCpMGL3whP7FmbUPw61dStXSZoBuNsDJJK3qvu/ydI/7vTIWxT2vb13NISQvV7ve3jd50eYdDImf67N0ExwHfwnCfbFJI2BxR0Eu/I3OwZaCg91PergOzKkpTSrX9chdWhATDKgvwoeK5RH3lZuYvjCuRnf5ABI7O8RKuyNTolocXIBzEtk96eZ87E+n7Q1gYSyho6nM8Ie7Y2qQbDhH7KiwAnUlnKFDBG/gjyZFee1fcHjJmWBgRNny1kUUjvEkH+uBaOdr82TMeOGf5EKOla+vYjpBubpHo7S2XblkYyZYSw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB8230.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(366004)(39860400002)(346002)(136003)(186003)(52536014)(166002)(66946007)(99936003)(478600001)(5660300002)(6506007)(83380400001)(76116006)(8936002)(86362001)(55016002)(8676002)(66556008)(38100700002)(33656002)(316002)(26005)(4326008)(38070700005)(64756008)(9326002)(7696005)(66446008)(66616009)(71200400001)(6916009)(66476007)(966005)(122000001)(9686003)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?vcAM3lyclNLj5aw0Nam1e6qiBgXiOnnOEab2rnlHRRAGdzwXa6FIZmZN6s?= =?iso-8859-1?Q?MwEMByxIuAA+JydA8lshyMW1mVoarUdw8ZG/4r/UTd2vh2H22Y063ZoqrN?= =?iso-8859-1?Q?d4I7AhYjXAw3rhKQXS/SwLeaYxpUCqRuIYmu9/e7L85tbrUmpEZ12sUvJC?= =?iso-8859-1?Q?Ez3hTX0Q33BMdiaCyEtoNuI8TIslflDxlcBpu6DVY6na6N/d/P8luOADfJ?= =?iso-8859-1?Q?O7wuA2PhoGmKYW7adTIX/VZTorDopKnIkD9mxUC96yNbyMMrplYYKFyRzB?= =?iso-8859-1?Q?gGokrfjt51vWNKa2A3k1zuVLzyVsZHRNErjs5x5FHghp+dQHtYfzTAs2uR?= =?iso-8859-1?Q?ed9U8rPqNwmIEXn3P+TfKUEFGepmoaLxDqQ3ibrHH8MeiFMn1TPQ2t6vAg?= =?iso-8859-1?Q?B4tr1msjifbZFkf6Ff0gIpQy5kaPy1dwhOMmqqNzI0SiWRLWm/SGjp8xCi?= =?iso-8859-1?Q?L2xBae6A55/LTq/VM29e8pca/PEYIUqwQS2wy8G3U9waVXtMdNXJhG7Np0?= =?iso-8859-1?Q?vNTIlJUkwAi8ooIS0jKSgD0qGZPQ0qCJmK1mgktMaWgP64xDw3qKlfnCpy?= =?iso-8859-1?Q?cuXB3P0r+wEB9+qLfzWRBnTjJ3rPuXbUN/0TE3QLK2Uz+atQh+vKFBDK4V?= =?iso-8859-1?Q?iaEzvaRBjcUtcshMcQ9LiPqRlmNzATGTX7re0ee0ZHoZrxKr+b+cCBuKXc?= =?iso-8859-1?Q?BQKBEwFF+VlpxI8XcqZhsZDfOnUUUm2YL1Wxc2TltB8Z2bn8x+upWJMHFo?= =?iso-8859-1?Q?c8SYw0BDsBtCp5GXouf4gitlfDQsbsDkckQ173FfhJsCKYfUOPy2KfatkB?= =?iso-8859-1?Q?hOTUT+pVfaBLW3YvKsEl8MwaHFKFCNwNfhYry4qDeLcExwnK7ktqgkSseR?= =?iso-8859-1?Q?tjOzaUBSx5kBstI55kSDr4XQoP5789Y3g67Sp6RccLBGHAb+IzjogMRo38?= =?iso-8859-1?Q?7yOzJP0mBY2bLZbi2D3l+PIbp8ZKEulgNGvarB/QlCindlDJWes4Kl3cuk?= =?iso-8859-1?Q?H1x4va1sBF/UPCXp725rIOohx1Ix9yNiZCBqdbJ4Pi/K6aH48wJEVTAdmv?= =?iso-8859-1?Q?9ew2Dx9hDcYhDFYt4JTjJy0pzw1JxQgH7xNZF38IrXPeg9ZFlXFrB9OWPs?= =?iso-8859-1?Q?5o62M17x/fOgc2tYTXj+Bur33XGQyVGQSYEv8LJ1ASia4Membhn1UHo2GE?= =?iso-8859-1?Q?NOsuQnkdOoGGiR0RsbRRTAnmeliYkM1IiykaJIUucdL5Jf2F2B+zbD6hGv?= =?iso-8859-1?Q?MrO5xnRYqbwrWJocKk9zDbe5X3QAr2sOfrz9pN9Inu5wHvJ9X/aqfz4f7j?= =?iso-8859-1?Q?XFXzC80N7B9QU95nScHqrQeIaRCJDe3Z+AXwuJvjRNuDGeM=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00DF_01D786F1.3CC62D60" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB8230.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0e1e1937-6dcc-4af1-4af8-08d954f7a458 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Aug 2021 14:21:23.9326 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: d+p8K/t7gDlp3aPjzskzB8VdFaBJtqKXd2y4dzTr+2BWvugRbCnj9vlzVb019xX7PQzOytQF+7B5YZCc21y/OCIwykXVBaChyiEhnS6/KBM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8190 Archived-At: Subject: [netconf] Comments on draft-claise-netconf-metadata-for-collection-02 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, 01 Aug 2021 14:21:33 -0000 ------=_NextPart_000_00DF_01D786F1.3CC62D60 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00E0_01D786F1.3CC62D60" ------=_NextPart_001_00E0_01D786F1.3CC62D60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, The draft contains good ideas, but it needs more work. Comments below. =20 General: The base drafts use the term capabilities not metadata. Unless = you have a reason for it, please stick to capabilities. =20 Ch.3 suggested-observable-period: why is this available only at = implementation time? IMHO it should be available in runtime too. I don=92t understand = the description.=20 =93Those 5 seconds ...=94 What does this refer too? =20 optimized-measurement-point: How should this effect a YANG-Push = subscription ? Some examples would be good. =20 corresponding-mib-oid: Wouldn=92t it be easier to define a YANG = extension statement that defines this SNMP OIDs in the YANG models itself? These = are static design time values, that cannot change in run-time. =20 related-node: A relationship can be of many-many types. IMHO for this to = be usable in an interoperable manner you need to narrow down what you mean = by relationship. E.g. config-state-node-relationship: The capability is used for YANG models = that use separate branches to specify the configuration and the state data = for management objects, For a config=3Dtrue container or list this = capability specifies the list/container that carries the state data for the same managed object.=20 =20 =93A generic RPC...=94 remove the word generic. It does not mean = anything specific. =20 =93Per-node dynamic metadata includes, part of the = get-measurement-metadata RPC=94 I think you mean:=20 =20 =20 =20 optimized-measurement-point: =93up the data tree chain=94 change to up the containment hierarchy. The sentence could use some rewording. Can the node selector be any selector, or maybe it should point at a specific schema node? Otherwise, it would be very hard to specify the answer. =20 =93computed-observable-period=94: This is the same as suggested-observable-period after it is dynamically adjusted. It serves = the same purpose. IMHO it is a general principle of ALL capabilities, that=20 * Capabilities are potentially available both in implementation time and in run-time. However, a network node may decide that it has no = useful information in implementation time, so it does not publish a value * During runtime the system MAY or MAY NOT be change/update a capability value. Just because the value may be updated dynamically it = is still the same capability. =20 =93active-measurements=94: Needs rewording. It is unclear what this = returns, why do you need to calculate measurement-periods to return the subscription = IDs =20 Ch.4.1 According to https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-cap= abi lities#section-4 =93Every set of such capabilities SHOULD be wrapped in a container under the augment statement to cleanly separate different groups of capabilities. These "wrapper containers" SHALL be augmented in at /sysc:system-capabilities and /sysc:system-capabilities/sysc:datastore-capabilities/sysc:per-node- capabilities.=94=94 Please follow it. =20 grouping system-node-metadata-info: this is a very generic name, that = says nothing about what capabilities are contained in the grouping. Find a = better name. Generally the base draft uses the term capability not metadata. =20 minimum-observable-period: I would call this either measurement-update-period or granularity (widely used by other SDOs) = This really states the update period of the counter. The fact that there is = no real sense in observing it more frequently is just a consequence. =20 suggested-observable-period: =93only available at implementation time=94 = Why? Do you hide the value that was available in implementation-time? If yes = why? If this is part of the YANG model it should be available in run-time. I = propose to remove this half-sentence. =20 related-node: description should be improved. In case of an NMDA server = with a non-NMDA model (e.g. ietf-system) this could still be useful. =20 get-measurement-metadata:=20 The input node selector MAY point to multiple nodes if some key values = are missing. This is not handled. =93RPC that returns the optimized=94 =96 what does optimized mean in = this case? Avoid the word, describe instead what you mean. =93This RPC is added to allow clients to learn dynamically changing metadata=94 =96 You could learn dynamic metadata(? Use capabilities) = with a simple an RPC is not needed. State the real purpose.=20 I would rather call the rpc something like: get-per-node-metadata Why is this rpc only valid for measurement metadata? It could be useful = for any capability. What if there are multiple optimized-measurement-points above the input node? Specify. Why are minimum-observable-period, corresponding-mib-oid and = related-node not returned. Illogical. =20 list active-measurements: What is a =93measurement=94 in this context? = Is it the YangPush subscription for the counter? If yes return a subscriptionId.=20 Or did you mean the smallest reporting period of all YangPush = subscriptions? What is returned if there are on-change Yang-Push subscriptions for the counter (or whatever data node)? =20 get-system-node-capabilities The difference between the 2 RPCs is not clear. The input node selector MAY point to multiple nodes if some key values = are missing. Is this intentional? Why is this rpc only valid for measurement metadata? It could be useful = for any capability. =93If the input node is not leaf/leaf-list then metadata of its subtree = nodes is returned.=94 The metadata/capabilities can be very different for = different schema nodes in the subtree. Will you return a separate set of = capabilities for every child node? That could be long! =20 Output: Node should be a key node-selector-capability: the name is wrong. This is a list of = capabilities not a new node-selector-capability. Regards Balazs =20 --=20 Balazs Lengyel Senior Specialist Ericsson Hungary Ltd.=20 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com =20 ------=_NextPart_001_00E0_01D786F1.3CC62D60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

The draft contains good ideas, but it needs more work. = Comments below.

 

General: The = base drafts use the term capabilities not metadata. Unless you have a = reason for it, please stick to capabilities.

 

Ch.3

suggested-observable-period: why is this available = only at implementation time? IMHO it should be available in runtime too. = I don’t understand the description.

“Those 5 seconds ...” What does this refer = too?

 

optimized-measurement-point: How should this effect a = YANG-Push subscription ? Some examples would be good.

 

corresponding-mib-oid: Wouldn’t it be easier to = define a YANG extension statement that defines this SNMP OIDs in the = YANG models itself? These are static design time values, that cannot = change in run-time.

 

related-node: A relationship can be of many-many = types. IMHO for this to be usable in an interoperable manner you need to = narrow down what you mean by relationship. E.g.

config-state-node-relationship: The capability is used = for YANG models that use separate branches to specify the configuration = and the state data for management objects, =A0For a config=3Dtrue = container or list this capability specifies the list/container that = carries the state data for the same managed object.

 

“A generic RPC...” remove the word = generic. It does not mean anything specific.

 

“Per-node =
dynamic metadata includes, part of the get-measurement-metadata =
RPC”<=
/o:p>
 I think you =
mean: 
 

 

 

optimized-measurement-point:<=
o:p>

“up the data tree = chain” change to up the containment hierarchy. The = sentence could use some rewording.

Can the node selector be any selector, or maybe it = should point at a specific schema node? Otherwise, it would be very hard = to specify the answer.

 

“computed-observable-period”: This is the = same as suggested-observable-period after it is dynamically adjusted. It = serves the same purpose. IMHO it is a general principle of ALL = capabilities, that

  • Capabilities are = potentially available both in implementation time and in run-time. = However, a network node may decide that it has no useful information in = implementation time, so it does not publish a value
  • During runtime the system MAY or MAY NOT be change/update a = capability value. Just because the value may be updated dynamically it = is still the same capability.

 

“active-measurements”: Needs rewording. It = is unclear what this returns, why do you need to calculate = measurement-periods to return the subscription IDs

 

Ch.4.1

According =A0to https://datatracker.ietf.org/doc/html/draft-= ietf-netconf-notification-capabilities#section-4

“Every set of such capabilities SHOULD = be

=A0=A0 wrapped in a container = under the augment statement to cleanly

=A0=A0 separate different groups of capabilities.=A0 = These "wrapper

=A0=A0 = containers" SHALL be augmented in at /sysc:system-capabilities = and

=A0=A0 = /sysc:system-capabilities/sysc:datastore-capabilities/sysc:per-node-=

=A0=A0 = capabilities.””

Please = follow it.

 

grouping system-node-metadata-info: this is a very = generic name, that says nothing about what capabilities are contained in = the grouping. Find a better name. Generally the base draft uses the term = capability not metadata.

 

minimum-observable-period: I would call this either = measurement-update-period or granularity (widely used by other SDOs) = This really states the update period of the counter. The fact that there = is no real sense in observing it more frequently is just a = consequence.

 

suggested-observable-period: “only available at = implementation time” Why? Do you hide the value that was available = in implementation-time? If yes why? If this is part of the YANG model it = should be available in run-time. I propose to remove this = half-sentence.

 

related-node: description should be improved. In case = of an NMDA server with a non-NMDA model (e.g. ietf-system) this could = still be useful.

 

get-measurement-metadata:

The input node selector MAY point to multiple nodes if = some key values are missing. This is not handled.

“RPC that returns the optimized” – = what does optimized mean in this case? Avoid the word, describe instead = what you mean.

“This RPC=A0 is = added to allow clients to learn dynamically changing=A0 metadata” = – You could learn dynamic metadata(? Use capabilities)=A0 with a = simple <get> an RPC is not needed. State the real purpose. =

I would rather call the rpc = something like: get-per-node-metadata

Why is this rpc only valid for measurement metadata? = It could be useful for any capability.

What if there are multiple = optimized-measurement-points above the input node? = Specify.

Why are = minimum-observable-period, corresponding-mib-oid and =A0related-node not = returned. Illogical.

 

list = active-measurements: What is a “measurement” in this = context? Is it the YangPush subscription for the counter? If yes return = a subscriptionId.

Or did you mean = the smallest reporting period of all YangPush = subscriptions?

What is returned if = there are on-change Yang-Push subscriptions for the counter (or whatever = data node)?

 

get-system-node-capabilities

The difference between the 2 RPCs is not = clear.

The input node selector MAY = point to multiple nodes if some key values are missing. Is this = intentional?

Why is this rpc only = valid for measurement metadata? It could be useful for any = capability.

“If the input node = is not leaf/leaf-list then metadata of its subtree nodes is = returned.” The metadata/capabilities can be very different for = different schema nodes in the subtree. Will you return a separate set of = capabilities for every child node? That could be long!

 

Output: Node = should be a key

node-selector-capability: the name is wrong. This is a = list of capabilities not a new = node-selector-capability.

Regards = Balazs

 

--

Balazs = Lengyel=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Senior = Specialist=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 Ericsson Hungary Ltd.

Mobile: = +36-70-330-7909=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 email: = Balazs.Lengyel@ericsson.com

 

------=_NextPart_001_00E0_01D786F1.3CC62D60-- ------=_NextPart_000_00DF_01D786F1.3CC62D60 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF7DCCA9SgAwIBAgIPAXUc1ROE7L9MPfu7eEiGMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMTIxMjQyMDVaFw0yMzEwMTMxMjQy MDRaMFkxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9CYWzDoXpzIExlbmd5ZWwxKjAoBgkq hkiG9w0BCQEWG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAIY9tW43KkX0v7F/PJBbw9U3ygqpHruC1COfeak4TXgZkHPCY+wATiveaId4 y8GstEVH3spxA+G4B5r4+wqbEEPJSjf6pRgOkdE6ORwlApyIJeWHPSC+NN8IeyErzZNIrZli3vpU V236s4Z8CL05QeXg6OnO8vIPzjKqOmNSxlSlFnxiBK1Tj+4lMqZmI9xyaQ+RRJyaWTQKOkEeaa6V 2i4N1Gicr7/5IJdoBB+oT5vCV3tO+B0ubC40f4vdVwu7nLgAgDJOBL4j7Op8BvNmLBmKdnlK0Vj+ nW1kFgCSNepVO7Fx08n4UEOufAp0RPI3z0AcnOwMJT5khqdz08xoI1kCAwEAAaOCAcEwggG9MB8G A1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQWBBQQoIERhKwaNK1dOsySWsLF ygxQPTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwJgYDVR0R BB8wHYEbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjANBgkqhkiG9w0BAQsF AAOCAgEAMyuEx/Jnxv1chc1eA81RXqFyxv7056cNkVGgRJP5j9kNAFNreHI3yY6folHuWMrIeE7p ad1YZ87UrWiBU97CbV+zrOc2EqnlcLfBCKMT24gGw8jTcE+KeNPoh5QKBYNYf+evBhITv16N4N8B eU3hRCHHGvQiKow/aaWqsQcgDtQdTIzDpw8cNB6UzSzqwtmtVERsnNzVbp3Bv4/SbLB9TP+YZPKm Bw8jgNQ4w42O6vYhhtNLsGvDswJ/f1bYwfa50b99o14Pz23oGDYcWDOQ2snUXq/FlMxj4oJ0EbHY mzHiJe6rQMSyl6iMb6HZ+S8Syzf84hmlRHtVr8/t/6Jz3DxSE4dlS5fORnKXbAPdEHk9558SJcQp I9zgXsOzNw5O1Btu3Cb4URv1ycf43Km25PRHjoNiXjkOgig58tIOeWwxtTiSWGYLckpTlmw1Papz VlhBzEs302V+cFo2xHADqoGfoHHpJcUATonJgSzscVMGauKhaujqRte5NBVcysJPvxFjTThhOaA6 JrqboqyTpToAJ8Rz/PF8o8zpX5Or1yJ9LfNoT3Q6hSJsBE7nDyDylaeibvqo0MLFtvx+RguycgnC sJvnuy28hDilBxytQR7nuNWR6/6IDy5ZNSaY7/oksleJNAiUZ7A51mjoJvqHA2xCMKb5SzxywsBt 70MMJigwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDAS BgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1 MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJ fpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxA vWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX 6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1J hNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2N S8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0V NXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zR zdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U /V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUH MAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2Vy MBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0f BEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVy YXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qW DNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjp HUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/ jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udG ZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8 H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQC o6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lD GJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFB V9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRq Yb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggNQMIIDTAIBATBaMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MwIPAXUc1ROE7L9MPfu7eEiGMAkGBSsOAwIaBQCgggHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDgwMTE0MjEwOVowIwYJKoZIhvcNAQkEMRYEFDfq/bKtYjeu fQEt6VR9omtG44nrMGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdRzVE4Tsv0w9 +7t4SIYwawYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXUc1ROE7L9MPfu7eEiG MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0D BzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAHgG zhxwj9w+mxIvho+gBxs5i4XoJpihMFuFNYN4m5srRsJNDjcHe3Qc6HNmeo1pQm/BuaTL7pnBw1Pg 0D/e/Ie0JloTpi7LOEyF4ycYCnQUCCvF+l7rnEj1gyf4hO1MXj/0jJ5qSuHhkMd1yPT/WUyKCIUR pYA/GZVq2DVAnh+b0wdvw8c+obfZLtV4ZPZe0i/OgXXP+I7ItA46n6l+joOwMBT+fLkrPR95KJOF 8Kj2vT9v47jt+PnNFvh8MbT53O1uLcwRol/Dl0ixKyalGsjit/mHJiOGm44mF/gTMVIH5db5Azg3 ZWXyb0D7fzeX+iUGMmBpW5rx3ljUjx5GfhQAAAAAAAA= ------=_NextPart_000_00DF_01D786F1.3CC62D60-- From nobody Mon Aug 2 01:59: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 475F83A1448 for ; Mon, 2 Aug 2021 01:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.47 X-Spam-Level: X-Spam-Status: No, score=0.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_HELO_IP_MISMATCH=2.368, RCVD_IN_DNSWL_BLOCKED=0.001, 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 nvDhNm-uzpki for ; Mon, 2 Aug 2021 01:59:14 -0700 (PDT) Received: from smtpout01-ext1.partage.renater.fr (smtpout01-ext1.partage.renater.fr [194.254.240.32]) by ietfa.amsl.com (Postfix) with ESMTP id DC2C33A1441 for ; Mon, 2 Aug 2021 01:59:13 -0700 (PDT) Received: from zmtaauth01.partage.renater.fr (zmtaauth01.partage.renater.fr [194.254.240.25]) by smtpout10.partage.renater.fr (Postfix) with ESMTP id 639D6624A7; Mon, 2 Aug 2021 10:59:08 +0200 (CEST) Received: from zmtaauth01.partage.renater.fr (localhost [127.0.0.1]) by zmtaauth01.partage.renater.fr (Postfix) with ESMTPS id 539BA1401EE; Mon, 2 Aug 2021 10:59:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zmtaauth01.partage.renater.fr (Postfix) with ESMTP id 4CE30140297; Mon, 2 Aug 2021 10:59:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at zmtaauth01.partage.renater.fr Received: from zmtaauth01.partage.renater.fr ([127.0.0.1]) by localhost (zmtaauth01.partage.renater.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8HBJ3C1FQ46X; Mon, 2 Aug 2021 10:59:08 +0200 (CEST) Received: from 77.199.85.50 (unknown [194.254.241.250]) by zmtaauth01.partage.renater.fr (Postfix) with ESMTPA id 072A71401EE; Mon, 2 Aug 2021 10:59:08 +0200 (CEST) From: Zmail Content-Type: multipart/alternative; boundary="Apple-Mail=_32374F64-095F-4D29-A4DA-0BE4FE018AC1" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Message-Id: <51A0785B-F9B3-4644-92E5-06820835291C@insa-lyon.fr> Date: Mon, 2 Aug 2021 10:59:07 +0200 Cc: pierre francois , "" , zhoutianran@huawei.com To: netconf@ietf.org X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Renater-Ptge-SpamState: clean X-Renater-Ptge-SpamScore: -100 X-Renater-Ptge-SpamCause: gggruggvucftvghtrhhoucdtuddrgedvtddriedvgddtjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucftgffptefvgfftnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhtggguffkfffvofesrgdtmherhhdtjeenucfhrhhomhepkghmrghilhcuoegrlhgvgidrhhhurghnghdqfhgvnhhgsehinhhsrgdqlhihohhnrdhfrheqnecuggftrfgrthhtvghrnhepgfefuddutedtteeivdetfeefteeiueejgffhteelkeelgedtffdutdffhfeiieegnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepudelgedrvdehgedrvdeguddrvdehtdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduleegrddvheegrddvgedurddvhedtpdhhvghlohepjeejrdduleelrdekhedrhedtpdhmrghilhhfrhhomhepkghmrghilhcuoegrlhgvgidrhhhurghnghdqfhgvnhhgsehinhhsrgdqlhihohhnrdhfrheqpdhrtghpthhtohepnhgvthgtohhnfhesihgvthhfrdhorhhgpdhrtghpthhtohepphhivghrrhgvrdhfrhgrnhgtohhishesihhnshgrqdhlhihonhdrfhhrpdhrtghpthhtohepofgrrhgtohdrvfholhhlihhnihdusehsfihishhstghomhdrtghomhdprhgtphhtthhopeiihhhouhhtihgrnhhrrghnsehhuhgrfigvihdrtghomh Archived-At: Subject: [netconf] Securing UDP-notif messages with DTLS 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, 02 Aug 2021 08:59:18 -0000 --Apple-Mail=_32374F64-095F-4D29-A4DA-0BE4FE018AC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello to everyone, We would like to present a new draft we didn=E2=80=99t have time to show = on the last IETF meeting. https://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-dtls/ = This draft defines a mechanism to secure UDP-notif protocol messages = using DTLS 1.3.=20 It defines the different layers involved, the DTLS session lifecycle and = the mandatory cipher suites to use. It also explicits that no extensions = of DTLS are needed and that IP fragmentation should be avoided. We would like to have some feedback for this draft. We will present the draft to the WG on the next IETF meeting. Looking forward to hearing from you, Alex Huang Feng= --Apple-Mail=_32374F64-095F-4D29-A4DA-0BE4FE018AC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= to everyone,

We = would like to present a new draft we didn=E2=80=99t have time to show on = the last IETF meeting.

https://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-= dtls/

This = draft defines a mechanism to secure UDP-notif protocol messages using = DTLS 1.3. 
It defines the different layers = involved, the DTLS session lifecycle and the mandatory cipher suites to = use. It also explicits that no extensions of DTLS are needed and that IP = fragmentation should be avoided.
We would like to = have some feedback for this draft.

We will present the draft to the WG on = the next IETF meeting.

Looking forward to hearing from you,

Alex Huang Feng
= --Apple-Mail=_32374F64-095F-4D29-A4DA-0BE4FE018AC1-- From nobody Mon Aug 2 02:40:34 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 B9C6A3A15D5 for ; Mon, 2 Aug 2021 02:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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=jacobsuniversity.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 NwycxFK_R_Kx for ; Mon, 2 Aug 2021 02:40:28 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60060.outbound.protection.outlook.com [40.107.6.60]) (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 078A23A15CF for ; Mon, 2 Aug 2021 02:40:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Pbu66Z4DiSjk/dHxe7h1e2LbpGq6lbZj3IpJgO9AMfFPK+n2Mxo/DoZYxYb1oX67BpFqnFmVd6EZzEWrX1LdAoJy2oIBRh9M2shEIZPGcdOnGq/72DaLdNZEmqH+UzkoF9vI4PPspNkW33aXY2ITBoSV3z2EpGWYfOv1CHqlZByxlqhKYLVb52lfDPQNmz8dVQmecG8tZ46b9ovkSJ8sMnExJWyYTdvwF3urALW+fGVtki8lXqOpVh9BXu5kdCZY3APXHwuOyNTu3OfWm22dVFHsLSzn1gtWDS58MQhW+2ubfHOoEjPo1oUDcZF9AjDm46QmZgesCu3siNCxYr1kIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DYCMf4TDlnalYORzpRIFpjyIJoRNQknzRbB7hDdQJvI=; b=eKltMMywXiT6HFm/oUu7bdVHncjtkutNQiwHIPBUCODB620xjPioMk1Pb2OU67TIAVDqeZck8bije2kvkpLEXlQeEsyNrmwituq7OSd5bo2hzSEkkbClx0iQYKF/Pz1TOh0LN/p0TWXxemGX9dvt28YCD1bA+N+vwfTvxsD6lFYtDjHbj2noGt2zkVQrL9PpTDqWbnN9V4Ldo4hNPog4eicTRnqoI47kMjYhee88qib7L1yoeRWMxBayRu6AQZc5gp75yR6xx0MOsnxvs87Jh3UxpGMEwXCahdpgFIBdf3kvanoMh30d+eG2LY0SZYKS/HXMY4515GC9ERB7IziQTA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DYCMf4TDlnalYORzpRIFpjyIJoRNQknzRbB7hDdQJvI=; b=T9y0kTr5JQ64OEhJMuRG3+o9EILOHat4rNJ4WLa3mcYzO+bbaiuFkCWVPLGH26ks1GWNoyXKQTfYDJOdMb3sl4qozT1ADwMUaNjZ5S/9r/Mc9cIgBNrv0Qc7Prg72Cw9xE5HbFQ8GhM+BTy+9C/7XTkZQ07rDppane9eJSWl7B4= Authentication-Results: insa-lyon.fr; dkim=none (message not signed) header.d=none;insa-lyon.fr; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM4P190MB0115.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:5e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.26; Mon, 2 Aug 2021 09:40:25 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::58c1:599a:1d3d:cdeb]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::58c1:599a:1d3d:cdeb%9]) with mapi id 15.20.4373.026; Mon, 2 Aug 2021 09:40:25 +0000 Date: Mon, 2 Aug 2021 11:40:24 +0200 From: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= To: Zmail Cc: netconf@ietf.org, "" , pierre francois Message-ID: <20210802094024.e2hhsnbtwop4ihmj@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Zmail , netconf@ietf.org, "" , pierre francois References: <51A0785B-F9B3-4644-92E5-06820835291C@insa-lyon.fr> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <51A0785B-F9B3-4644-92E5-06820835291C@insa-lyon.fr> X-ClientProxiedBy: AM0PR01CA0087.eurprd01.prod.exchangelabs.com (2603:10a6:208:10e::28) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by AM0PR01CA0087.eurprd01.prod.exchangelabs.com (2603:10a6:208:10e::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.18 via Frontend Transport; Mon, 2 Aug 2021 09:40:24 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ff559d87-27bf-4665-83a0-08d955998dc8 X-MS-TrafficTypeDiagnostic: AM4P190MB0115: X-MS-Exchange-Transport-Forked: True 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: xYk0iOcWH3hqcBfAtkLK9rLhwGlfflIref1aGoweiiRSBisHEEL0L7jwPYo3gK03tiDHeAU6tp3g3OWcfmFy8E8JpptV2tRmbssjbAYYVOVsDTHridkBjqDlHvA13XThmbQosaulNzX4KNjN/Kz6Y4sI9pxqZx3rN/PxX0zqfpvFTap4u7L/EbRCN0Fy546llpstb0PN/snBAIvlJc+VdN7sHplotLtQkcx1A6Jo4IkAlCGQur1Nsipva4LbrG0Sz7YuJBQV4DhmChHvTlExBs3nwXBJ70IWg54+aCe7etUY0DY5btyrIKRmt40fEL2m3U6VvNmH5TNj4u8rttS8HBHaMUGBX4K3mdjxpKs73D+Cwe1BFe/4xpFf7tDtiPJ06zkIiUuHo8vg9h9sqX0AcGIT0y9mS9cfFQj5XJOoYW3gyvC/K8UcjwzeQjT6rZFtSlUED2/iW8ILEzxSnFzw+svVqTKAJ8ulQNN2RM9FstLzf7mGlcCgEmvzPjmQqgV2xseFa+ocZBos/3t4wJpZm2wSLWYFEvtlrznTP8NrJ9ejLFGX+/4Od+E8y5YPpoGY4PuDwXqtb03XAGFsvyOLXgEQudRION+Ny+UjD5+hiK16hDMW0OAAa8IpHUC5uPn/7wFpcilgLbCIKxmJtN/CaPFyVVW0BB1HR4rNw4RijbU0PpFjN5X1LltqusIzn6tCpUlB+tbB/xPvqWxNrIinlVOn7mhot4bhJo8XQA1zQFcgA/50/htcqqOj1nQ5yA1IIg7InAWdZLizIkuIquHtyaYsg5doTzRns+5ePjHsPHhFDdGV1VdRArWxAPjn2NBH X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(396003)(366004)(346002)(39850400004)(136003)(26005)(52116002)(478600001)(6496006)(8936002)(6916009)(186003)(66946007)(66476007)(66556008)(6486002)(15650500001)(4326008)(966005)(8676002)(38100700002)(85202003)(38350700002)(5660300002)(3450700001)(86362001)(2906002)(786003)(316002)(85182001)(83380400001)(956004)(1076003); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NXNKRVVEMm9SdDFjZkZoM3ZpYy95MURldDQxRWszOHJBQllRbU5TUERzbnlK?= =?utf-8?B?Q05RaXhGY1JTT2NlNWVudU1IbmV5OU5UdjR2bVFNeW9BV1ZkT1VDMXRZZkJh?= =?utf-8?B?bmN0ay9vaHM0dkRlNHJ2ZkMxTklyT2JheHhGWWhtNVVsMHpHVHhGQUFHR3J5?= =?utf-8?B?Z0piTmhHY0dFNXVGNU9LSGZXK2hVWGpoTUNxMitnZDl4RUo0SHFHMHpuM3hx?= =?utf-8?B?QUN1eFczd3hjOXo4akZ4VnkwYzA5a3pjSUhQSU41WnhpcmNHZXhDNG5tZExC?= =?utf-8?B?S0VFc00vbE80d2xEYUNEL2Z1djkrYlhudWhVVk5IZzJUSFBRNnB6N0R6NXVj?= =?utf-8?B?dmNFdlY0aFhiUy94UnJ2WUQza0tTOG5YalRGUHZDRWJTT2lMV0FLV2FDQWJR?= =?utf-8?B?Tmdkb3h1a1BHczk5dnkvV1JJUHNkZmxmY2JSeXB1cjZRbWVMQlZIQmhncmNE?= =?utf-8?B?SFFkTmxDbzdCYTNkU25adlNyRWxLRCtaam1aeGtoekNjVVJMOVVPYlI4WEJG?= =?utf-8?B?ZWZwYXQ2L1NLTkI2MlovMkFBOTE2bk5mZXhWUnBDUHhKK1I5STFBRmJydS9j?= =?utf-8?B?c3ZRbEpNOCt6dzZwN2R3Uk1VWHBVcTVmN1dmVGwwTHB3ZjFZVFFiZUdwbTly?= =?utf-8?B?SkY2M2NSSUhWd2FDbDBncllYRkRobys5dUJlWm9wV1VLYjVIRXc0UG5DWEs4?= =?utf-8?B?czJJTWc1eTRhUzBteU5peitqcmNZOExORHJCQXk2b0RlbUZMdVZUMFB3eW05?= =?utf-8?B?THh1SjRzVEtJM0E1UStYbzVqQVFVdFlQWHdGVFVUOEVCS0RLMUdPNC9hcHFo?= =?utf-8?B?ckxaRWJOd2tPK3ZOUEpwT1paTm5XMjY1QjUzL1VqZ3FQRzUrUEJOdTBrQWJn?= =?utf-8?B?M1p1M3FtdXFYcmpOTmZHUkxqSjVvMDR3TXNRcFVXZ0Rsc3NwREc1VUFrS2sx?= =?utf-8?B?QXlqQjQvVnZuR1hCajdwV0YvTll6SVM0UWpxcDY2aVJwOURoVFF5ekw3dm1q?= =?utf-8?B?QndpMS9HejZuczhxM3MxUWJTRGQ5M1AralFRSm55Q2MzZ3ZLSkw2NXc2MjRw?= =?utf-8?B?Y2NvMmVIV0JnaEgxdzJpbDh6bUo1YVV4ZTQ0a0FZWENTR3E2STZETmVnOXdL?= =?utf-8?B?aTQxWlYvSTMzdDRsRkpsOWVVMmVJR3JkcWR2UXU1Z0RCMkM4Y3FGVGRob1JW?= =?utf-8?B?Z1B5Wmk0dXlxT3dHY3N2bHU2VzVDRkloZTNKcnZuNmoza3ZwVU85RFBPNk91?= =?utf-8?B?SGFZTkY0WC9vdVd3RmFzZVA3emFWSFRSTGo0b040aHdBeEp5cjJKY0ZuY0FK?= =?utf-8?B?RUhoYXFSOVdXRGU0c3NNY0lKRXZGOTdTUlptYmVuUFBrNnJKSGw2cWhoKzFG?= =?utf-8?B?cXIzVG5IK2kzUWRwWi9yRmczOEkraXI3dnhsUE12N01XSkphOHNvN1FsL0Fz?= =?utf-8?B?N0c1ekcwamFnODR4eTBvWmd4NlVhalBZVWUyNGNOZGpaKys2NzhNcGNqaWcw?= =?utf-8?B?R3dnUUFIelZxUTB4NzhQZCswcUlsZkRrL3pQeGRGdS80TUhmY2xNTThxZlpL?= =?utf-8?B?SDZzYk1yVTBFNDVGV2paS1Z1L0hxdnVKSkhLNDE0YjlEY3FKQ2ZQbHpZQ2Z6?= =?utf-8?B?dkdjS2dMUnJ4endOelQvbWZsYjBDMXFEbVVtSys3NmJGWVN2c1RvNVBxdDRz?= =?utf-8?B?dTN6U1JWOVdmTG9HdmE0S3BpL3R6OVVLOHRZNTN6dWxoMUJoc05BYTFrb3Jt?= =?utf-8?Q?AJl3ZOrkOECLDOwRpquCeCeLvgMn4BWG2G8xEdM?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: ff559d87-27bf-4665-83a0-08d955998dc8 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Aug 2021 09:40:24.9887 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Ukkp6vVRGpOnJyJMs9MJOWygw8PozByq65mpoiP5EqHGCmIS2x9GsKQtfHPY34/nOUAhmTlgEOA85m32QLTG+XuxEtUGOJiV78qvWqCqoMw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4P190MB0115 Archived-At: Subject: Re: [netconf] Securing UDP-notif messages with DTLS 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, 02 Aug 2021 09:40:33 -0000 Since I doubt that a protocol not providing security will receive IESG approval, I suggest that this work is getting integrated into draft-ietf-netconf-udp-notif-03.txt. I have not read the content but the I-D seems fairly small so integration into the WG document should be fairly trivial. Given past experience, it might be that the DTLS/UDP transport will become the mandatory to implement transport. /js On Mon, Aug 02, 2021 at 10:59:07AM +0200, Zmail wrote: > Hello to everyone, > > We would like to present a new draft we didn’t have time to show on the last IETF meeting. > > https://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-dtls/ > > This draft defines a mechanism to secure UDP-notif protocol messages using DTLS 1.3. > It defines the different layers involved, the DTLS session lifecycle and the mandatory cipher suites to use. It also explicits that no extensions of DTLS are needed and that IP fragmentation should be avoided. > We would like to have some feedback for this draft. > > We will present the draft to the WG on the next IETF meeting. > > Looking forward to hearing from you, > > Alex Huang Feng > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Aug 2 08:53: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 1CCE93A07E6 for ; Mon, 2 Aug 2021 08:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.473 X-Spam-Level: X-Spam-Status: No, score=0.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_HELO_IP_MISMATCH=2.368, RCVD_IN_DNSWL_BLOCKED=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=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 fmaagNc7peMm for ; Mon, 2 Aug 2021 08:53:13 -0700 (PDT) Received: from smtpout02-ext2.partage.renater.fr (smtpout02-ext2.partage.renater.fr [194.254.241.33]) by ietfa.amsl.com (Postfix) with ESMTP id 35A0E3A07E0 for ; Mon, 2 Aug 2021 08:53:12 -0700 (PDT) Received: from zmtaauth02.partage.renater.fr (zmtaauth02.partage.renater.fr [194.254.241.25]) by smtpout20.partage.renater.fr (Postfix) with ESMTP id 09F00C067F; Mon, 2 Aug 2021 17:53:08 +0200 (CEST) Received: from zmtaauth02.partage.renater.fr (localhost [127.0.0.1]) by zmtaauth02.partage.renater.fr (Postfix) with ESMTPS id E4997A02AC; Mon, 2 Aug 2021 17:53:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zmtaauth02.partage.renater.fr (Postfix) with ESMTP id DD927A02CC; Mon, 2 Aug 2021 17:53:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at zmtaauth02.partage.renater.fr Received: from zmtaauth02.partage.renater.fr ([127.0.0.1]) by localhost (zmtaauth02.partage.renater.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Mr63HmVbziJ5; Mon, 2 Aug 2021 17:53:07 +0200 (CEST) Received: from 77.199.85.50 (unknown [194.254.241.249]) by zmtaauth02.partage.renater.fr (Postfix) with ESMTPA id 83232A02AC; Mon, 2 Aug 2021 17:53:07 +0200 (CEST) From: Zmail Message-Id: <152841A6-6A37-4F75-857D-2F70346AFB5D@insa-lyon.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_2E2B8A1E-5911-4041-AC1D-18AEA039EA44" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Mon, 2 Aug 2021 17:53:07 +0200 In-Reply-To: <20210802094024.e2hhsnbtwop4ihmj@anna.jacobs.jacobs-university.de> Cc: netconf@ietf.org, "" , pierre francois To: Juergen Schoenwaelder References: <51A0785B-F9B3-4644-92E5-06820835291C@insa-lyon.fr> <20210802094024.e2hhsnbtwop4ihmj@anna.jacobs.jacobs-university.de> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Renater-Ptge-SpamState: clean X-Renater-Ptge-SpamScore: -100 X-Renater-Ptge-SpamCause: gggruggvucftvghtrhhoucdtuddrgedvtddriedvgdekiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucftgffptefvgfftnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtjeenucfhrhhomhepkghmrghilhcuoegrlhgvgidrhhhurghnghdqfhgvnhhgsehinhhsrgdqlhihohhnrdhfrheqnecuggftrfgrthhtvghrnhepjefggfejvedtieeijeevffefjeefjeeikeeuudduheduheejieekvdeuheeffeevnecuffhomhgrihhnpehivghtfhdrohhrghdpjhgrtghosghsqdhunhhivhgvrhhsihhthidruggvnecukfhppeduleegrddvheegrddvgedurddvgeelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepudelgedrvdehgedrvdeguddrvdegledphhgvlhhopeejjedrudelledrkeehrdehtddpmhgrihhlfhhrohhmpegkmhgrihhluceorghlvgigrdhhuhgrnhhgqdhfvghnghesihhnshgrqdhlhihonhdrfhhrqedprhgtphhtthhopehjrdhstghhohgvnhifrggvlhguvghrsehjrggtohgsshdquhhnihhvvghrshhithihrdguvgdprhgtphhtthhopehnvghttghonhhfsehivghtfhdrohhrghdprhgtphhtthhopeforghrtghordfvohhllhhinhhiudesshifihhsshgtohhmrdgtohhmpdhrtghpthhtohepphhivghrrhgvrdhfrhgrnhgt ohhishesihhnshgrqdhlhihonhdrfhhr Archived-At: Subject: Re: [netconf] Securing UDP-notif messages with DTLS 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, 02 Aug 2021 15:53:19 -0000 --Apple-Mail=_2E2B8A1E-5911-4041-AC1D-18AEA039EA44 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Noted, I=E2=80=99ll discuss this with Unyte team. Alex > On 2 Aug 2021, at 11:40, J=C3=BCrgen Sch=C3=B6nw=C3=A4lder = wrote: >=20 > Since I doubt that a protocol not providing security will receive > IESG approval, I suggest that this work is getting integrated into > draft-ietf-netconf-udp-notif-03.txt. >=20 > I have not read the content but the I-D seems fairly small so > integration into the WG document should be fairly trivial. Given past > experience, it might be that the DTLS/UDP transport will become the > mandatory to implement transport. >=20 > /js >=20 > On Mon, Aug 02, 2021 at 10:59:07AM +0200, Zmail wrote: >> Hello to everyone, >>=20 >> We would like to present a new draft we didn=E2=80=99t have time to = show on the last IETF meeting. >>=20 >> https://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-dtls/ = = > >>=20 >> This draft defines a mechanism to secure UDP-notif protocol messages = using DTLS 1.3.=20 >> It defines the different layers involved, the DTLS session lifecycle = and the mandatory cipher suites to use. It also explicits that no = extensions of DTLS are needed and that IP fragmentation should be = avoided. >> We would like to have some feedback for this draft. >>=20 >> We will present the draft to the WG on the next IETF meeting. >>=20 >> Looking forward to hearing from you, >>=20 >> Alex Huang Feng >=20 >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --Apple-Mail=_2E2B8A1E-5911-4041-AC1D-18AEA039EA44 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Noted, I=E2=80=99ll discuss this with Unyte team.

Alex

On 2 Aug 2021, at 11:40, J=C3=BCrgen Sch=C3=B6nw=C3=A4lder = <j.schoenwaelder@jacobs-university.de> wrote:

Since I doubt that a protocol not providing security will = receive
IESG = approval, I suggest that this work is getting integrated into
draft-ietf-netconf-udp-notif-03.txt.

I have not read the content but = the I-D seems fairly small so
integration into the WG document should be fairly trivial. = Given past
experience, = it might be that the DTLS/UDP transport will become the
mandatory to implement = transport.

/js

On Mon, Aug 02, 2021 at = 10:59:07AM +0200, Zmail wrote:
Hello to everyone,

We would like to present a new draft we didn=E2=80=99t have = time to show on the last IETF meeting.

https://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-= dtls/ <https://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-= dtls/>

This draft defines a = mechanism to secure UDP-notif protocol messages using DTLS 1.3. 
It defines = the different layers involved, the DTLS session lifecycle and the = mandatory cipher suites to use. It also explicits that no extensions of = DTLS are needed and that IP fragmentation should be avoided.
We would like to have some feedback for this draft.

We will present the draft to the WG on the = next IETF meeting.

Looking forward to = hearing from you,

Alex Huang Feng

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


-- Juergen Schoenwaelder =           Jacobs = University Bremen gGmbH
Phone: +49 421 200 3587 =         Campus Ring 1 | 28759 = Bremen | Germany
Fax:   +49 421 200 3103 =         <https://www.jacobs-university.de/>

= --Apple-Mail=_2E2B8A1E-5911-4041-AC1D-18AEA039EA44-- From nobody Mon Aug 2 09:26:06 2021 Return-Path: <0100017b07afa694-e244f7b7-ab7b-4fab-b669-793f9f6b87d2-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 22F9C3A0C15 for ; Mon, 2 Aug 2021 09:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBzdszFZiOry for ; Mon, 2 Aug 2021 09:25:58 -0700 (PDT) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF26B3A0C0B for ; Mon, 2 Aug 2021 09:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1627921557; h=Content-Type:Content-Transfer-Encoding:From:Mime-Version:Subject:Date:Message-Id:References:Cc:In-Reply-To:To:Feedback-ID; bh=TKmQHbyhsmV8TCCsZvhjbbBlybW8laQheoATuwsN0qs=; b=WfgZLsXsSfTN0i6xMD7wOedXv98xrRwxGhl8wWPM6vbHjR7wnIHVfE46T+Y5vbfD p3pTeto6lTmBHquLIYmiahCG4iSpmIdspxwj6T2IaYoiBU+kinnm3CYQHDlVM3Erz7o Ujz7g1iPpimGP1U4E1JmMxzFxYlvxS3zFvutWGao= Content-Type: multipart/alternative; boundary=Apple-Mail-211765DA-74FD-4A3F-B445-32C2A0A0D751 Content-Transfer-Encoding: 7bit From: Kent Watsen Mime-Version: 1.0 (1.0) Date: Mon, 2 Aug 2021 16:25:57 +0000 Message-ID: <0100017b07afa694-e244f7b7-ab7b-4fab-b669-793f9f6b87d2-000000@email.amazonses.com> References: <152841A6-6A37-4F75-857D-2F70346AFB5D@insa-lyon.fr> Cc: Juergen Schoenwaelder , Marco.Tollini1@swisscom.com, netconf@ietf.org, pierre francois In-Reply-To: <152841A6-6A37-4F75-857D-2F70346AFB5D@insa-lyon.fr> To: Zmail X-Mailer: iPhone Mail (18F72) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.08.02-54.240.48.90 Archived-At: Subject: Re: [netconf] Securing UDP-notif messages with DTLS 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, 02 Aug 2021 16:26:04 -0000 --Apple-Mail-211765DA-74FD-4A3F-B445-32C2A0A0D751 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mahesh and I were wondering about this. When Pierre mentioned the DTLS work= , we were =E2=80=9Csurprised=E2=80=9D in that we too assumed the =E2=80=9Cud= p=E2=80=9D draft had the security bits.=20 It is true that the IESG is all but mandating security for a for years now. = IIRC, Syslog over UDP is obsolete due to being unsecured. =20 K.=20 > On Aug 2, 2021, at 11:53 AM, Zmail wrote: >=20 > =EF=BB=BFNoted, I=E2=80=99ll discuss this with Unyte team. >=20 > Alex >=20 >> On 2 Aug 2021, at 11:40, J=C3=BCrgen Sch=C3=B6nw=C3=A4lder wrote: >>=20 >> Since I doubt that a protocol not providing security will receive >> IESG approval, I suggest that this work is getting integrated into >> draft-ietf-netconf-udp-notif-03.txt. >>=20 >> I have not read the content but the I-D seems fairly small so >> integration into the WG document should be fairly trivial. Given past >> experience, it might be that the DTLS/UDP transport will become the >> mandatory to implement transport. >>=20 >> /js >>=20 >>> On Mon, Aug 02, 2021 at 10:59:07AM +0200, Zmail wrote: >>> Hello to everyone, >>>=20 >>> We would like to present a new draft we didn=E2=80=99t have time to show= on the last IETF meeting. >>>=20 >>> https://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-dtls/ >>>=20 >>> This draft defines a mechanism to secure UDP-notif protocol messages usi= ng DTLS 1.3.=20 >>> It defines the different layers involved, the DTLS session lifecycle and= the mandatory cipher suites to use. It also explicits that no extensions of= DTLS are needed and that IP fragmentation should be avoided. >>> We would like to have some feedback for this draft. >>>=20 >>> We will present the draft to the WG on the next IETF meeting. >>>=20 >>> Looking forward to hearing from you, >>>=20 >>> Alex Huang Feng >>=20 >>> _______________________________________________ >>> netconf mailing list >>> netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>=20 >>=20 >> --=20 >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail-211765DA-74FD-4A3F-B445-32C2A0A0D751 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Mahesh and I were wondering a= bout this.  When Pierre mentioned the DTLS work, we were =E2=80=9Csurpr= ised=E2=80=9D in that we too assumed the =E2=80=9Cudp=E2=80=9D draft had the= security bits. 

It is true that the IESG is all but= mandating security for a for years now.  IIRC, Syslog over UDP is obso= lete due to being unsecured.  

K. 

On Aug 2, 2021, at 11:53 AM= , Zmail <alex.huang-feng@insa-lyon.fr> wrote:

=EF=BB=BFNoted, I=E2=80=99ll discu= ss this with Unyte team.

Alex

On 2 Aug 2021, at 11:40, J=C3=BCrgen Sch=C3=B6nw=C3=A4lder &= lt;j.scho= enwaelder@jacobs-university.de> wrote:

Since I d= oubt that a protocol not providing security will receive
IESG approval, I suggest that this work is getting int= egrated into
draft-ietf-netconf-u= dp-notif-03.txt.

I have not read the content but the I-D seems fairly small s= o
integration into the WG documen= t should be fairly trivial. Given past
experience, it might be that the DTLS/UDP transport will become the
mandatory to implement transport.<= br style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12= px; font-style: normal; font-variant-caps: normal; font-weight: normal; lett= er-spacing: normal; text-align: start; text-indent: 0px; text-transform: non= e; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; t= ext-decoration: none;" class=3D"">
/js

O= n Mon, Aug 02, 2021 at 10:59:07AM +0200, Zmail wrote:
Hello to everyone,

We would like to present a new draft we didn=E2=80=99t have time to sh= ow on the last IETF meeting.

ht= tps://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-dtls/ <https://data= tracker.ietf.org/doc/draft-unyte-netconf-udp-notif-dtls/>

This draft defines a mechanism to secure UDP-notif protoco= l messages using DTLS 1.3. 
It defines the different layers involved, the DTLS session l= ifecycle and the mandatory cipher suites to use. It also explicits that no e= xtensions of DTLS are needed and that IP fragmentation should be avoided.We would like to have some feedback for this draft.

We will present the draft to the WG on the next IETF meetin= g.

Looking forward to hearing from you,

Alex Huang Feng

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


-- 
Juergen Schoenwaelder          = ; Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         C= ampus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103       &nb= sp; <https://www.jacobs-university.de/>

___________________= ____________________________
netconf mailing list
= netconf@ietf.org
https://www.ietf.org/mailman/listinfo= /netconf
= --Apple-Mail-211765DA-74FD-4A3F-B445-32C2A0A0D751-- From nobody Mon Aug 2 10:14:54 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 16EA23A101D for ; Mon, 2 Aug 2021 10:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VV_uJWzQ_1f for ; Mon, 2 Aug 2021 10:14:47 -0700 (PDT) Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (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 09F9C3A0EEC for ; Mon, 2 Aug 2021 10:14:46 -0700 (PDT) Received: by mail-yb1-xb2a.google.com with SMTP id p145so14974530ybg.6 for ; Mon, 02 Aug 2021 10:14:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Iu2ZP20Ge2bIAVMEA01Hoi7EjvkkndX81WRT1x39tQk=; b=ofK3c2tUlrKLWcC+oc+J1q81aTe+0xHlPiOJO9XWnQ0hfA/5pIJmxY9jV52LuDAkdX 7bdUejToLHojrDS/cAcT2X6J9UNBLbAYmhNQgij5WStBH3lW9szeTRRfKRK/ogiXdgOy Z6UgKE1Wz6mkvlUqAAnBpkt/wWRdgHFlRl/BQotMpmqhhCU3amlkOMrySuFYVDL79LLs JwlBr/U7wsqdEIBiGX1KNxfwHhcnix2nccKm90PZFcRag3VjcOme0hNK/CqOB/7flS8K ZCMZ1lLcBn7De7Yr3ZToIkuU8a9iCKkk+c+zAtqpGVCvUi2Nlaa6ceHnvVRkt9r/Okjg /iqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Iu2ZP20Ge2bIAVMEA01Hoi7EjvkkndX81WRT1x39tQk=; b=ZTElTR0roEw7jNGGrMni1+MZSHJK9UPrw5Z4OV6vXCm5v0Her89SskMRzvUYL6ngjX DyENUeA8D8SnSVBng8Ig2wpolnCz2PsxCCW/KuFU8/aEhZpuLaBOOzn23gjavzFN3KHy NizYn7upXJ+msV/J03BfUmM8C8GRJrlVY1pENewHzwIGVEBR/BMHMJ7s1rpgbJUr7LA7 3SChUEife512fjvTm++Aw3h9+hTBVrjFaFjOVv+i9zcQHVmXSLrFkarYxSx0Lu78mJlC kXUp5We9rMvgtJMyBCYnj5mYyhDxJVtqHc4ISwdMUa35s261L3c9B+vRh3cjRMqAoybR zMoA== X-Gm-Message-State: AOAM533wg2thIC+5qspOc3mq33MJzFd89GpxR2cM0e46MqtymuJgytlR +yFTCmLAVE/Ol98WUzh/ZAjdzfoh0TaFwfXqNOI= X-Google-Smtp-Source: ABdhPJz0HCZh1Miv6yWpWr2Uq4v6JqJDT4SPRC+O5SBgA+stojPt+znBB2W/N7Bkw7a6AwoPtHIqdaovU9qJ79UnQ04= X-Received: by 2002:a25:d683:: with SMTP id n125mr23194216ybg.113.1627924485690; Mon, 02 Aug 2021 10:14:45 -0700 (PDT) MIME-Version: 1.0 References: <152841A6-6A37-4F75-857D-2F70346AFB5D@insa-lyon.fr> <0100017b07afa694-e244f7b7-ab7b-4fab-b669-793f9f6b87d2-000000@email.amazonses.com> In-Reply-To: <0100017b07afa694-e244f7b7-ab7b-4fab-b669-793f9f6b87d2-000000@email.amazonses.com> From: Pierre Francois Date: Mon, 2 Aug 2021 19:14:35 +0200 Message-ID: To: Kent Watsen Cc: Zmail , Marco.Tollini1@swisscom.com, Netconf , pierre francois Content-Type: multipart/alternative; boundary="000000000000b0d79c05c896b4f4" Archived-At: Subject: Re: [netconf] Securing UDP-notif messages with DTLS 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, 02 Aug 2021 17:14:52 -0000 --000000000000b0d79c05c896b4f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello everyone, I'm fine with merging the two drafts. What I wish is that the existing implementations that do not mandate dtls activation remain legit wrt the resulting RFC. We're aiming at lightweight transport in controlled environments here. Cheers, Pierre. Le lun. 2 ao=C3=BBt 2021 =C3=A0 18:26, Kent Watsen a =C3= =A9crit : > > Mahesh and I were wondering about this. When Pierre mentioned the DTLS > work, we were =E2=80=9Csurprised=E2=80=9D in that we too assumed the =E2= =80=9Cudp=E2=80=9D draft had the > security bits. > > It is true that the IESG is all but mandating security for a for years > now. IIRC, Syslog over UDP is obsolete due to being unsecured. > > K. > > On Aug 2, 2021, at 11:53 AM, Zmail wrote: > > =EF=BB=BFNoted, I=E2=80=99ll discuss this with Unyte team. > > Alex > > On 2 Aug 2021, at 11:40, J=C3=BCrgen Sch=C3=B6nw=C3=A4lder < > j.schoenwaelder@jacobs-university.de> wrote: > > Since I doubt that a protocol not providing security will receive > IESG approval, I suggest that this work is getting integrated into > draft-ietf-netconf-udp-notif-03.txt. > > I have not read the content but the I-D seems fairly small so > integration into the WG document should be fairly trivial. Given past > experience, it might be that the DTLS/UDP transport will become the > mandatory to implement transport. > > /js > > On Mon, Aug 02, 2021 at 10:59:07AM +0200, Zmail wrote: > > Hello to everyone, > > We would like to present a new draft we didn=E2=80=99t have time to show = on the > last IETF meeting. > > https://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-dtls/ < > https://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-dtls/> > > This draft defines a mechanism to secure UDP-notif protocol messages usin= g > DTLS 1.3. > It defines the different layers involved, the DTLS session lifecycle and > the mandatory cipher suites to use. It also explicits that no extensions = of > DTLS are needed and that IP fragmentation should be avoided. > We would like to have some feedback for this draft. > > We will present the draft to the WG on the next IETF meeting. > > Looking forward to hearing from you, > > Alex Huang Feng > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000b0d79c05c896b4f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,=C2=A0

I'm fine with= merging the two drafts. What I wish is that the existing implementations t= hat do not mandate dtls activation remain legit wrt the resulting RFC.=C2= =A0
We're aiming at lightweight transport in controlled envir= onments here.

Cheers,=C2=A0
Pierre.

Le=C2=A0lun. 2 ao=C3=BBt 2021 =C3=A0=C2=A018:26, Kent Watsen <kent@watsen.net> a =C3=A9crit=C2=A0:
=
<= div>
Mahesh and I were wondering about this.=C2=A0 When Pierre men= tioned the DTLS work, we were =E2=80=9Csurprised=E2=80=9D in that we too as= sumed the =E2=80=9Cudp=E2=80=9D draft had the security bits.=C2=A0

=
It is true that the IESG is all but mandating security for a for= years now.=C2=A0 IIRC, Syslog over UDP is obsolete due to being unsecured.= =C2=A0

K.=C2=A0

On Aug 2, 2021, at 11:53 AM, Zmail <alex.huang-feng@insa-ly= on.fr> wrote:

=EF=BB=BFNoted, I=E2=80=99ll discuss this with Unyte team.
Alex

On 2 Aug = 2021, at 11:40, J=C3=BCrgen Sch=C3=B6nw=C3=A4lder <j.schoenwaelder@jacobs= -university.de> wrote:

Since I doubt that a protocol not providing security will = receive
IESG approval, I suggest that this work is getting integrated into
dr= aft-ietf-netconf-udp-notif-03.txt.

I have not read the c= ontent but the I-D seems fairly small so
integration into the WG document sh= ould be fairly trivial. Given past
experience, it might be that the DTLS/UDP= transport will become the
mandatory to implement transport.

/js

On Mon, Aug 02, 2021 at 10:59:07AM +0200, Zmail = wrote:
= Hello to everyone,

We would like to present a new draft we didn=E2= =80=99t have time to show on the last IETF meeting.

https://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-dtls= /=C2=A0<https://datatracker.iet= f.org/doc/draft-unyte-netconf-udp-notif-dtls/>

This draft def= ines a mechanism to secure UDP-notif protocol messages using DTLS 1.3.=C2=A0
It defines the different layers involved, the DTLS sessio= n lifecycle and the mandatory cipher suites to use. It also explicits that = no extensions of DTLS are needed and that IP fragmentation should be avoide= d.
We would like to have some feedback for this draft.

We will pr= esent the draft to the WG on the next IETF meeting.

Looking forward = to hearing from you,

Alex Huang Feng

____________________________= ___________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mai= lman/listinfo/netconf


--=C2=A0
Juergen Schoenwaelder =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Campus Ring 1 | 28759 Bremen | Germany<= /span>
F= ax: =C2=A0=C2=A0+49 421 200 3103 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0<https://www.jacobs-university.de/>

____________= ___________________________________
netconf mailing list
netconf= @ietf.org
https://www.ietf.org/mailman/listinfo/netcon= f
______________________= _________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000b0d79c05c896b4f4-- From nobody Mon Aug 2 10:33:55 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 4FE853A1164 for ; Mon, 2 Aug 2021 10:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-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=jacobsuniversity.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 8lelpy3lnbxu for ; Mon, 2 Aug 2021 10:33:47 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2083.outbound.protection.outlook.com [40.107.20.83]) (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 5DA0A3A1159 for ; Mon, 2 Aug 2021 10:33:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ljgj0tXsXJp61tIEtLQaQT/67m92s4LbiOQnXTA8hfc9jX8b2bqW0KU3G1D2CkeIS+X0n90qpTOCkdEgKQt38XWu3zaKvTrBEc51LKKXZh8dNcdYyGBmI/Djl47jTZIMtdPBaEzDKiNWRy78hibPLldDWJF1eCc57sqACrYaUlP5+8ezf/TP4kSawyThlET3q0mD5h7ThiACMq6tJ7XlbDPCSijYXukFItLey9dYp0QHd+NIjZwRBj5dBB4wHQlLvg9/6OE9y65pVgLaUIC8Zg1y681YwFUFj2JcDsO22zCeYGgmjH4twT1qdjJaCLxJwQzS74ZNuLjvP5cgk7Z1Wg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UHvRZuJP1LEMFLzFxO68s2Ij2oc2yhNqfFynJihjA6E=; b=HNJ7oheCwshrkbov3HO+elq8auQkw8il8pZfO7mWiHxfEVgzwcEcq7+ye4eC5GK8F8Z8jyENUNCiCou1h/FNg19L6VuSSJnxvL9L+WzfpOgNEGVuLGXUvSw+Cnt7ZxFu3ckvirIe4wGnfYE51heIGziAVH+nxq9dpcCSLxyVBgsD+iY8IY3+EhZEsliA0/pEVEMQXW/crRmmlbpoFGJXlaIhR1x1FnT5RNKMY7y2BXEzqNdYyQXLnnJVdL1DNFa79607T47Md1hJpUmlvLw65SgK87OK0IXtldH8g/NYakkXDWx9oR85T/VGYk4HWh9EgvuhAXa/EbGG8ecT/uFagg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UHvRZuJP1LEMFLzFxO68s2Ij2oc2yhNqfFynJihjA6E=; b=rh3t1NDTVVi1MgsI2Bf7Ey47UOEC5Euy5Nm5B4JdimkQeFPjwH5lR3HImP/hLSz8Qt+rk3i06OOiXEEpR9NAduc7hXG5Buujult3I48qyMkDmHr5BLajREwsv3KskqVpGpVTB6QBq3ZGPWs8cXuhtQ3d+F3HA9szpQY+IhCWhQ8= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM0P190MB0594.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:1a1::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.17; Mon, 2 Aug 2021 17:33:43 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::58c1:599a:1d3d:cdeb]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::58c1:599a:1d3d:cdeb%9]) with mapi id 15.20.4373.026; Mon, 2 Aug 2021 17:33:43 +0000 Date: Mon, 2 Aug 2021 19:33:42 +0200 From: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= To: Pierre Francois Cc: Kent Watsen , pierre francois , Marco.Tollini1@swisscom.com, Netconf Message-ID: <20210802173342.6kv5gkhkuu4tapcw@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Pierre Francois , Kent Watsen , pierre francois , Marco.Tollini1@swisscom.com, Netconf References: <152841A6-6A37-4F75-857D-2F70346AFB5D@insa-lyon.fr> <0100017b07afa694-e244f7b7-ab7b-4fab-b669-793f9f6b87d2-000000@email.amazonses.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: FR3P281CA0012.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:1d::15) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by FR3P281CA0012.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:1d::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.9 via Frontend Transport; Mon, 2 Aug 2021 17:33:43 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 23ecf4f6-cfab-41ce-8bda-08d955dbacdc X-MS-TrafficTypeDiagnostic: AM0P190MB0594: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: SqEY4jGIx5VK0lZHmpxC9hDelIb8V7sngExdBfiowieFK+8dUyf7xnyKe7RpWHtnz08sgwyYGlhQVFs0LHhrxmDDepbCwJeZGoDKErfYVhRfT3DHmqgQfqCKBudwPoLrwge2/c1NT+mQGUqEFPjsPPtampeh5juR+IB9W5odMnAP4UOXogX9Du1h5QlAk5bJ8bOKMATqMymhJVxs8qWH1rdUY8fuJyR4q4oUi4T+Pk8oB5m6DpXyB6ONkrSnvkNLRYENH3cOOTuqGFsaeYZyT6wZFbkYpQ7oz8ZWp3wtD9+M97rR6EsHLhuT3nGzW8SgZgmXQvPNBoTc8KBnA6wEK6LibdoIKfZ9QA+4f+01Ca0EJGnsCDqrqOKqwLXFL+bbMMpyxzUELdQmHjFJb2c0WUwf9nt/WdQM/+Z3iPPUINc0hU/R9YVvA3W9Slmsa/puvE1ju2ryDO3kMn1qcBFJ9p8w8d+CcyBfIU1X9gPCDJm+OK8Nk6Vh/7V9Zis7l54wPwrRLq2IcFlRkIMpV5p6gu9g8GP6i0rgaDdZX3DYfbe7kETeyOMz1djGcCllgY9MlL43hLHrI3o+yDivAxbVWnBBl0wjbTENqtDRU8MS1WBDP3iaekvtQQ3Yq2KaItRe9SQAyAjDrR0tjYv3gr4aWYw8S/1YA+lEsg0gKtBgdy2gQMP9PnbQLE8PPJPpagpUi965C1pzPKLuu8nTGvq5mZnLFlBX4EcXDGYUxTqVHk/ZPq8ICGKd8l5LdodQRsffE/1jy1tKRi0toFjUqO4Z1EVbx0OSRswJiRuzS22alNN6apICKCExFIueGa10X2ad X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(66946007)(66556008)(66476007)(66574015)(2906002)(53546011)(3450700001)(15650500001)(38100700002)(6486002)(85202003)(966005)(6496006)(52116002)(38350700002)(4326008)(316002)(1076003)(508600001)(786003)(186003)(26005)(956004)(8676002)(5660300002)(83380400001)(8936002)(54906003)(85182001)(86362001)(6916009); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZDdJYkZpaElJb0E4OGNpd0d3Zmg2ZUFSZEZDVVJKb2RPS1dXb1BoV0JnOHEv?= =?utf-8?B?R2FCTDdkQkNMZVJORi9GWEwxekNEQ01vV1A4Q3N5ajdEY3VPVDdKemFtbjEy?= =?utf-8?B?alJ6OVBGeXExaVhmYzVhM0xtRlp1SktDY3pSaS80c2U4VkFwOWpVZXUwMi9S?= =?utf-8?B?QUVYcytvL2gvOHQ0Q0NESWdnRnZsaitvcXA4dU5KRlBadzlnc3puYU9oc1VZ?= =?utf-8?B?M1B1NWp1L0pTNnhFQU5ERGVJdmMrNWtSZzF0SGJZT2tEQjR0YjBrYnN3Nys1?= =?utf-8?B?emFHbzdwUW9aOFVCck9rRnlyYXdhMU0wWW92cEN0TUFLQzBtTWRKZ3czNDBM?= =?utf-8?B?aktXSnE5Z2ZQNVFPSTQ1NENhQVlETks2eXFhNkJsRXBmdnJnN1haVWZjR0wz?= =?utf-8?B?UUNkZmhlM0czd0NEdGFEd2dMbTZ5TG5HQy9yckd2d2h0QzZVUHJPMEFxUUl5?= =?utf-8?B?V1FtVUcxRXloOEorT1dQM2lBV3R2Q1F3UDBqem1vOWJvSjVUOTVvZE0zbS81?= =?utf-8?B?Q3lUT0NESkZqY2VGbkY3Y0h5OSt3dHZSb2p4MzIvdzdYWlQwMFJRVVJRME5h?= =?utf-8?B?SWNadXhHSGFOSjd3amJ6Uk9JVXJ0MjA1eU5vbUFSV29nU09VaGtLbFZ1Z09O?= =?utf-8?B?ZlNHYlplQTQyQ1dHK1RnaWVGbWFWN1cxeGdPQ3BiZFQ1TEJkSnRobndYUEk5?= =?utf-8?B?WlQwWWgxWnNpWnZacEZhMXpyMUdWZG03YnJydmp4NFJqNi90NHl0OGxjM2ZR?= =?utf-8?B?ZTZCVGRNZHlRSUVBQW1SYktqZWxmOHFJYytNUE5WNEgwVWYvTmRONStoZmJQ?= =?utf-8?B?dkpFSVBQTVErZHhsOFZRREhWTTFDbTZsa3FxL2s2TkQ1Unl0c2x5UXovN3l2?= =?utf-8?B?czVJQ3dTNC9SMlhXMThia1FDL08veDhvU1paZzR4Z1RpU21CYlpEdUM1SlFp?= =?utf-8?B?Q28vK25zcmtPclUxSmxJZkNVTFpuaEp3VEwzS0tSb2wrUTlTejAzWFd2WVB6?= =?utf-8?B?a0FiMnRwUGpaSnNLYi83WDNncGRNbExBSHJldmUxRFEyYzR5bm9pWkNOY0VH?= =?utf-8?B?eHZEYk9IV1Q5QnhYeDY5M205ZCtzdlFMcTNoTmI2QVh0UzByQ3M4dSs2U3I4?= =?utf-8?B?Zno4WFlNZW9Ic2NpNHFNZGQxeXFWVDcwQ2pnSEgvRklzeXJOU2Q1ZnFyZXhJ?= =?utf-8?B?VTV6bGh0QTZjYUxlbVQwdHcrcUhDbkxlQkU1NnBjV29UelRvR25VbzMrN2p6?= =?utf-8?B?TUwxTStoTCtxQ25pMSt1Q3VUZjI3ODE3THVjSUcwWS9kNmttdGdway96QWFs?= =?utf-8?B?QTRwR3VhbUNGT1IzRU5WS255UlV4QmZKN3V1bElHL1lmanVJWWp2RWhPTE9t?= =?utf-8?B?SVJ0ODRqREZ2OXd5WHc2QmFBS2RrSEFYcXhSbDVKdnNqdWd4REFCVzVHb1gr?= =?utf-8?B?aEFQUHNXNklVYmZ4ZjVFT2xJd1Y4ZDBBdStKOCtTbFJ3UVMwQjZ4K3F3VUt5?= =?utf-8?B?a016WE5JNzhWb0gvVGd2MGhrdE1lSmhVYkZQREJPQVVFSXh5K0RZempLWWRJ?= =?utf-8?B?S1Y5UE8zY09hWUlNTzJsRVBGcmdMSmFpTlc2UnFtSkpDcy9QVjFJandEWTJn?= =?utf-8?B?UGNCUVhkVkpHSU1ya2djQ1p0b01sc0Q3Ri9xUVVjYWZxdGRuMS9WMHFCb1pX?= =?utf-8?B?U3psRW1YQlBOaGE5VUVJZzlGUEJjOHFJTXVLSHlVNkpNMGhOaDRScW84Ukdk?= =?utf-8?Q?QIkdthUNf/6w1asTn4ccvBJ8RlbCX28OpBT03MA?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 23ecf4f6-cfab-41ce-8bda-08d955dbacdc X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Aug 2021 17:33:43.7253 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: c7Wmz56hUnUi47VTarGQszTpSm4crv/X1+uP7oO7zSZh2tJhWhCW++JK43nvI8dYrQ/cPg5EFf73iTCXXpWKzcXxxWrHG1s8DXCBsqrR7zw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0594 Archived-At: Subject: Re: [netconf] Securing UDP-notif messages with DTLS 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, 02 Aug 2021 17:33:53 -0000 In the past, there were people on the IESG that would tell you that "a controlled environment" is in most cases a myth. (There is something to this argument once you think about how messed up the world appears to be these days.) There certainly is a point that compliant implementations must support a secure transport so that people deploying the technology have the choice to use it. If an operator then decides to not use the secure transport, so be it, that is then the operator's free choice (and responsibility). But not being able make this choice, because a secure transport is not universally implemented, is an obstacle to avoid. And yes, this is all about what needs to be implemented to be compliant. The IESG has little influence on what people use, but it can influence that people have a choice by requiring the implementation of a secure transport by compliant implementations. /js PS: Of course, I am talking from past experience, and the details of the story lines usually change with the IESG composition. On Mon, Aug 02, 2021 at 07:14:35PM +0200, Pierre Francois wrote: > Hello everyone, > > I'm fine with merging the two drafts. What I wish is that the existing > implementations that do not mandate dtls activation remain legit wrt the > resulting RFC. > We're aiming at lightweight transport in controlled environments here. > > Cheers, > Pierre. > > Le lun. 2 août 2021 à 18:26, Kent Watsen a écrit : > > > > > Mahesh and I were wondering about this. When Pierre mentioned the DTLS > > work, we were “surprised” in that we too assumed the “udp” draft had the > > security bits. > > > > It is true that the IESG is all but mandating security for a for years > > now. IIRC, Syslog over UDP is obsolete due to being unsecured. > > > > K. > > > > On Aug 2, 2021, at 11:53 AM, Zmail wrote: > > > > Noted, I’ll discuss this with Unyte team. > > > > Alex > > > > On 2 Aug 2021, at 11:40, Jürgen Schönwälder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > Since I doubt that a protocol not providing security will receive > > IESG approval, I suggest that this work is getting integrated into > > draft-ietf-netconf-udp-notif-03.txt. > > > > I have not read the content but the I-D seems fairly small so > > integration into the WG document should be fairly trivial. Given past > > experience, it might be that the DTLS/UDP transport will become the > > mandatory to implement transport. > > > > /js > > > > On Mon, Aug 02, 2021 at 10:59:07AM +0200, Zmail wrote: > > > > Hello to everyone, > > > > We would like to present a new draft we didn’t have time to show on the > > last IETF meeting. > > > > https://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-dtls/ < > > https://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-dtls/> > > > > This draft defines a mechanism to secure UDP-notif protocol messages using > > DTLS 1.3. > > It defines the different layers involved, the DTLS session lifecycle and > > the mandatory cipher suites to use. It also explicits that no extensions of > > DTLS are needed and that IP fragmentation should be avoided. > > We would like to have some feedback for this draft. > > > > We will present the draft to the WG on the next IETF meeting. > > > > Looking forward to hearing from you, > > > > Alex Huang Feng > > > > > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Aug 2 12:22:22 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 6E5703A17F1 for ; Mon, 2 Aug 2021 12:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Yz4KZwmomzMS for ; Mon, 2 Aug 2021 12:22:14 -0700 (PDT) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 6A7723A17E5 for ; Mon, 2 Aug 2021 12:22:14 -0700 (PDT) Received: by mail-yb1-xb34.google.com with SMTP id s48so7129900ybi.7 for ; Mon, 02 Aug 2021 12:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Mbbei0TtN0ksh+Gst9iMMGuAuFRAlkGCy0JH8xo1bkA=; b=JMA0KBQyKCEp2pRRquz7+q0Ixx2xDalLTua0YVN4tXpSceLWMg/36Sary9bxSOYi4q C4uPLa8veJMB3TfY3743PlC/JXstrBAhSaT8VrahcdpgTaCJpauKEYzeR+uf9VPQb5nv AzBzSYXIouSaIZXkFewDbauvHwDNC1ceesGDFjBjteoV3mXvCg1EVW+m3/TVJUq7qMVp 0F+8cliMq0RgBO8sZtbRow5Mvl1mMe+pNzylhWfeB4C/ba1VMZ5pTeVsK4PHaRpX/19x X8BWgRwpHuoOi3riNlXjRoeCoDI+ClpGqtGXYVnQj3zAk9ePM2jDO/KxBeaXzv0RtNKh 5jqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Mbbei0TtN0ksh+Gst9iMMGuAuFRAlkGCy0JH8xo1bkA=; b=Q0uxNlq/S+wMKZ5rG33ApWve+v8rXpSNPfWdOJnluwcap/dywqo2e79ljO7DMW88Q2 JAhAtyyLt9+k4PixdoKSS+1K0JPbNm5tA6XSId2xvbb0UZ2mymaBvaCrxKQi3FtoBUvY N6WU3gTpQ7yQGhdVZMQUjKbpg4BD4DI77qFrbu6Zz4/t1N91UhxW8M2ZZr+u/FL+xjkW AgTZtZSIwB9UvPrGXYZUcGZ8cMCVnT/ht3QI3BO5wqLEivu8EiHZY8r9g63cx6ACrYIw PAPhS10cxV6CMuYC6CGRJtbgolmB87RkA/7xXv55uRpv/bcwQVhxVu5xi2S3RZX2dpgN vOBA== X-Gm-Message-State: AOAM532SgVCOYfgPFPuxkmkzp+J2AscTfr2AR7qZ9l1m95fOUeGTyLrP DQDYiOT048eRdQ3mXOrD6VEAJwsovnV8iFW1K1I= X-Google-Smtp-Source: ABdhPJzFd2KTXSBOQuoe/DFE1wqFGQJuGQOPAK7E/Y9tsLM2niFc/8ZOB/tNLeHy7dTRGPM/t3n6/1PxLu3mpxZlL/4= X-Received: by 2002:a25:d683:: with SMTP id n125mr23858894ybg.113.1627932132700; Mon, 02 Aug 2021 12:22:12 -0700 (PDT) MIME-Version: 1.0 References: <152841A6-6A37-4F75-857D-2F70346AFB5D@insa-lyon.fr> <0100017b07afa694-e244f7b7-ab7b-4fab-b669-793f9f6b87d2-000000@email.amazonses.com> <20210802173342.6kv5gkhkuu4tapcw@anna.jacobs.jacobs-university.de> In-Reply-To: <20210802173342.6kv5gkhkuu4tapcw@anna.jacobs.jacobs-university.de> From: Pierre Francois Date: Mon, 2 Aug 2021 21:22:02 +0200 Message-ID: To: Juergen Schoenwaelder , Pierre Francois , Kent Watsen , pierre francois , Marco.Tollini1@swisscom.com, Netconf Content-Type: multipart/alternative; boundary="0000000000007cf46e05c8987cad" Archived-At: Subject: Re: [netconf] Securing UDP-notif messages with DTLS 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, 02 Aug 2021 19:22:21 -0000 --0000000000007cf46e05c8987cad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Juergen, Thanks for your input. IESG composition won't change much to the story on this aspect, I think. Alright, I'll discuss with all the authors involved and get back to the list. I guess no one in the wg will object to a merge if we decide to go this way. Cheers, /pfr Le lun. 2 ao=C3=BBt 2021 =C3=A0 19:33, J=C3=BCrgen Sch=C3=B6nw=C3=A4lder < j.schoenwaelder@jacobs-university.de> a =C3=A9crit : > In the past, there were people on the IESG that would tell you that "a > controlled environment" is in most cases a myth. (There is something > to this argument once you think about how messed up the world appears > to be these days.) > > There certainly is a point that compliant implementations must support > a secure transport so that people deploying the technology have the > choice to use it. If an operator then decides to not use the secure > transport, so be it, that is then the operator's free choice (and > responsibility). But not being able make this choice, because a secure > transport is not universally implemented, is an obstacle to avoid. > > And yes, this is all about what needs to be implemented to be > compliant. The IESG has little influence on what people use, but it > can influence that people have a choice by requiring the > implementation of a secure transport by compliant implementations. > > /js > > PS: Of course, I am talking from past experience, and the details of > the story lines usually change with the IESG composition. > > On Mon, Aug 02, 2021 at 07:14:35PM +0200, Pierre Francois wrote: > > Hello everyone, > > > > I'm fine with merging the two drafts. What I wish is that the existing > > implementations that do not mandate dtls activation remain legit wrt th= e > > resulting RFC. > > We're aiming at lightweight transport in controlled environments here. > > > > Cheers, > > Pierre. > > > > Le lun. 2 ao=C3=BBt 2021 =C3=A0 18:26, Kent Watsen a = =C3=A9crit : > > > > > > > > Mahesh and I were wondering about this. When Pierre mentioned the DT= LS > > > work, we were =E2=80=9Csurprised=E2=80=9D in that we too assumed the = =E2=80=9Cudp=E2=80=9D draft had > the > > > security bits. > > > > > > It is true that the IESG is all but mandating security for a for year= s > > > now. IIRC, Syslog over UDP is obsolete due to being unsecured. > > > > > > K. > > > > > > On Aug 2, 2021, at 11:53 AM, Zmail > wrote: > > > > > > =EF=BB=BFNoted, I=E2=80=99ll discuss this with Unyte team. > > > > > > Alex > > > > > > On 2 Aug 2021, at 11:40, J=C3=BCrgen Sch=C3=B6nw=C3=A4lder < > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > Since I doubt that a protocol not providing security will receive > > > IESG approval, I suggest that this work is getting integrated into > > > draft-ietf-netconf-udp-notif-03.txt. > > > > > > I have not read the content but the I-D seems fairly small so > > > integration into the WG document should be fairly trivial. Given past > > > experience, it might be that the DTLS/UDP transport will become the > > > mandatory to implement transport. > > > > > > /js > > > > > > On Mon, Aug 02, 2021 at 10:59:07AM +0200, Zmail wrote: > > > > > > Hello to everyone, > > > > > > We would like to present a new draft we didn=E2=80=99t have time to s= how on the > > > last IETF meeting. > > > > > > https://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-dtls/ = < > > > https://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-dtls/> > > > > > > This draft defines a mechanism to secure UDP-notif protocol messages > using > > > DTLS 1.3. > > > It defines the different layers involved, the DTLS session lifecycle > and > > > the mandatory cipher suites to use. It also explicits that no > extensions of > > > DTLS are needed and that IP fragmentation should be avoided. > > > We would like to have some feedback for this draft. > > > > > > We will present the draft to the WG on the next IETF meeting. > > > > > > Looking forward to hearing from you, > > > > > > Alex Huang Feng > > > > > > > > > _______________________________________________ > > > netconf mailing list > > > netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > > Fax: +49 421 200 3103 > > > > > > > > > _______________________________________________ > > > netconf mailing list > > > netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > _______________________________________________ > > > netconf mailing list > > > netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --0000000000007cf46e05c8987cad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Juergen,=C2=A0

Thanks for your input.

IESG composition won't change much to the story= on this aspect, I think.=C2=A0
Alright, I'll discuss with al= l the authors involved and get back to the list. I guess no one in the wg w= ill object to a merge if we decide to go this way.

=
Cheers,=C2=A0

/pfr

<= br>




Le=C2=A0lun. 2 ao=C3= =BBt 2021 =C3=A0=C2=A019:33, J=C3=BCrgen Sch=C3=B6nw=C3=A4lder <j.schoen= waelder@jacobs-university.de> a =C3=A9crit=C2=A0:
In the past, there were people on = the IESG that would tell you that "a
controlled environment" is in most cases a myth. (There is something to this argument once you think about how messed up the world appears
to be these days.)

There certainly is a point that compliant implementations must support
a secure transport so that people deploying the technology have the
choice to use it. If an operator then decides to not use the secure
transport, so be it, that is then the operator's free choice (and
responsibility). But not being able make this choice, because a secure
transport is not universally implemented, is an obstacle to avoid.

And yes, this is all about what needs to be implemented to be
compliant. The IESG has little influence on what people use, but it
can influence that people have a choice by requiring the
implementation of a secure transport by compliant implementations.

/js

PS: Of course, I am talking from past experience, and the details of
=C2=A0 =C2=A0 the story lines usually change with the IESG composition.

On Mon, Aug 02, 2021 at 07:14:35PM +0200, Pierre Francois wrote:
> Hello everyone,
>
> I'm fine with merging the two drafts. What I wish is that the exis= ting
> implementations that do not mandate dtls activation remain legit wrt t= he
> resulting RFC.
> We're aiming at lightweight transport in controlled environments h= ere.
>
> Cheers,
> Pierre.
>
> Le lun. 2 ao=C3=BBt 2021 =C3=A0 18:26, Kent Watsen <kent@watsen.net> a =C3=A9crit = :
>
> >
> > Mahesh and I were wondering about this.=C2=A0 When Pierre mention= ed the DTLS
> > work, we were =E2=80=9Csurprised=E2=80=9D in that we too assumed = the =E2=80=9Cudp=E2=80=9D draft had the
> > security bits.
> >
> > It is true that the IESG is all but mandating security for a for = years
> > now.=C2=A0 IIRC, Syslog over UDP is obsolete due to being unsecur= ed.
> >
> > K.
> >
> > On Aug 2, 2021, at 11:53 AM, Zmail <alex.huang-feng@insa-lyon.fr>= ; wrote:
> >
> > =EF=BB=BFNoted, I=E2=80=99ll discuss this with Unyte team.
> >
> > Alex
> >
> > On 2 Aug 2021, at 11:40, J=C3=BCrgen Sch=C3=B6nw=C3=A4lder < > > j.schoenwaelder@jacobs-university.de> wrote:
> >
> > Since I doubt that a protocol not providing security will receive=
> > IESG approval, I suggest that this work is getting integrated int= o
> > draft-ietf-netconf-udp-notif-03.txt.
> >
> > I have not read the content but the I-D seems fairly small so
> > integration into the WG document should be fairly trivial. Given = past
> > experience, it might be that the DTLS/UDP transport will become t= he
> > mandatory to implement transport.
> >
> > /js
> >
> > On Mon, Aug 02, 2021 at 10:59:07AM +0200, Zmail wrote:
> >
> > Hello to everyone,
> >
> > We would like to present a new draft we didn=E2=80=99t have time = to show on the
> > last IETF meeting.
> >
> > https://datatracker.ie= tf.org/doc/draft-unyte-netconf-udp-notif-dtls/ <
> > https://datatracker.ie= tf.org/doc/draft-unyte-netconf-udp-notif-dtls/>
> >
> > This draft defines a mechanism to secure UDP-notif protocol messa= ges using
> > DTLS 1.3.
> > It defines the different layers involved, the DTLS session lifecy= cle and
> > the mandatory cipher suites to use. It also explicits that no ext= ensions of
> > DTLS are needed and that IP fragmentation should be avoided.
> > We would like to have some feedback for this draft.
> >
> > We will present the draft to the WG on the next IETF meeting.
> >
> > Looking forward to hearing from you,
> >
> > Alex Huang Feng
> >
> >
> > _______________________________________________
> > netconf mailing list
> > netconf@iet= f.org
> > https://www.ietf.org/mailman/listinfo/netconf=
> >
> >
> >
> > --
> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jac= obs University Bremen gGmbH
> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus R= ing 1 | 28759 Bremen | Germany
> > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<https://www.jacobs-university.de/>
> >
> >
> > _______________________________________________
> > netconf mailing list
> > netconf@iet= f.org
> > https://www.ietf.org/mailman/listinfo/netconf=
> >
> > _______________________________________________
> > netconf mailing list
> > netconf@iet= f.org
> > https://www.ietf.org/mailman/listinfo/netconf=
> >

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

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>
--0000000000007cf46e05c8987cad-- From nobody Tue Aug 3 05:45:40 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 8EA233A2205 for ; Tue, 3 Aug 2021 05:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-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 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 bNaHz2_zvlbh for ; Tue, 3 Aug 2021 05:45:33 -0700 (PDT) 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 3A9223A2204 for ; Tue, 3 Aug 2021 05:45:33 -0700 (PDT) Received: from fraeml736-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GfF2l339Lz6GCyM; Tue, 3 Aug 2021 20:45:19 +0800 (CST) Received: from [10.47.29.35] (10.47.29.35) 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.2176.2; Tue, 3 Aug 2021 14:45:24 +0200 To: Pierre Francois , Juergen Schoenwaelder , Kent Watsen , pierre francois , , Netconf References: <152841A6-6A37-4F75-857D-2F70346AFB5D@insa-lyon.fr> <0100017b07afa694-e244f7b7-ab7b-4fab-b669-793f9f6b87d2-000000@email.amazonses.com> <20210802173342.6kv5gkhkuu4tapcw@anna.jacobs.jacobs-university.de> From: Benoit Claise Message-ID: Date: Tue, 3 Aug 2021 14:45:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DC02628D50837D0591E7B2C2" Content-Language: en-GB X-Originating-IP: [10.47.29.35] 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] Securing UDP-notif messages with DTLS 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, 03 Aug 2021 12:45:39 -0000 --------------DC02628D50837D0591E7B2C2 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi, This discussion reminds me of IPFIX discussions :-) Considering that the industry/operators will implement what they need (not more), or request what they need from router vendors, regardless of the RFCs say, let's go with the path of least resistance regarding publication. I would say: merge the two drafts. Regards, Benoit On 8/2/2021 9:22 PM, Pierre Francois wrote: > Juergen, > > Thanks for your input. > > IESG composition won't change much to the story on this aspect, I think. > Alright, I'll discuss with all the authors involved and get back to > the list. I guess no one in the wg will object to a merge if we decide > to go this way. > > Cheers, > > /pfr > > > > > > > Le lun. 2 août 2021 à 19:33, Jürgen Schönwälder > > a écrit : > > In the past, there were people on the IESG that would tell you that "a > controlled environment" is in most cases a myth. (There is something > to this argument once you think about how messed up the world appears > to be these days.) > > There certainly is a point that compliant implementations must support > a secure transport so that people deploying the technology have the > choice to use it. If an operator then decides to not use the secure > transport, so be it, that is then the operator's free choice (and > responsibility). But not being able make this choice, because a secure > transport is not universally implemented, is an obstacle to avoid. > > And yes, this is all about what needs to be implemented to be > compliant. The IESG has little influence on what people use, but it > can influence that people have a choice by requiring the > implementation of a secure transport by compliant implementations. > > /js > > PS: Of course, I am talking from past experience, and the details of >     the story lines usually change with the IESG composition. > > On Mon, Aug 02, 2021 at 07:14:35PM +0200, Pierre Francois wrote: > > Hello everyone, > > > > I'm fine with merging the two drafts. What I wish is that the > existing > > implementations that do not mandate dtls activation remain legit > wrt the > > resulting RFC. > > We're aiming at lightweight transport in controlled environments > here. > > > > Cheers, > > Pierre. > > > > Le lun. 2 août 2021 à 18:26, Kent Watsen > a écrit : > > > > > > > > Mahesh and I were wondering about this.  When Pierre mentioned > the DTLS > > > work, we were “surprised” in that we too assumed the “udp” > draft had the > > > security bits. > > > > > > It is true that the IESG is all but mandating security for a > for years > > > now.  IIRC, Syslog over UDP is obsolete due to being unsecured. > > > > > > K. > > > > > > On Aug 2, 2021, at 11:53 AM, Zmail > > wrote: > > > > > > Noted, I’ll discuss this with Unyte team. > > > > > > Alex > > > > > > On 2 Aug 2021, at 11:40, Jürgen Schönwälder < > > > j.schoenwaelder@jacobs-university.de > > wrote: > > > > > > Since I doubt that a protocol not providing security will receive > > > IESG approval, I suggest that this work is getting integrated into > > > draft-ietf-netconf-udp-notif-03.txt. > > > > > > I have not read the content but the I-D seems fairly small so > > > integration into the WG document should be fairly trivial. > Given past > > > experience, it might be that the DTLS/UDP transport will > become the > > > mandatory to implement transport. > > > > > > /js > > > > > > On Mon, Aug 02, 2021 at 10:59:07AM +0200, Zmail wrote: > > > > > > Hello to everyone, > > > > > > We would like to present a new draft we didn’t have time to > show on the > > > last IETF meeting. > > > > > > > https://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-dtls/ > > < > > > > https://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-dtls/ > > > > > > > > This draft defines a mechanism to secure UDP-notif protocol > messages using > > > DTLS 1.3. > > > It defines the different layers involved, the DTLS session > lifecycle and > > > the mandatory cipher suites to use. It also explicits that no > extensions of > > > DTLS are needed and that IP fragmentation should be avoided. > > > We would like to have some feedback for this draft. > > > > > > We will present the draft to the WG on the next IETF meeting. > > > > > > Looking forward to hearing from you, > > > > > > Alex Huang Feng > > > > > > > > > _______________________________________________ > > > netconf mailing list > > > netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > > > > > -- > > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | > Germany > > > Fax:   +49 421 200 3103        >   > > > > > > > > > > _______________________________________________ > > > netconf mailing list > > > netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > _______________________________________________ > > > netconf mailing list > > > netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > -- > Juergen Schoenwaelder           Jacobs University Bremen gGmbH > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany > Fax:   +49 421 200 3103          > > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------DC02628D50837D0591E7B2C2 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Hi,

This discussion reminds me of IPFIX discussions :-)
Considering that the industry/operators will implement what they need (not more), or request what they need from router vendors, regardless of the RFCs say, let's go with the path of least resistance regarding publication. I would say: merge the two drafts.

Regards, Benoit

On 8/2/2021 9:22 PM, Pierre Francois wrote:
Juergen, 

Thanks for your input.

IESG composition won't change much to the story on this aspect, I think.
Alright, I'll discuss with all the authors involved and get back to the list. I guess no one in the wg will object to a merge if we decide to go this way.

Cheers, 

/pfr






Le lun. 2 août 2021 à 19:33, Jürgen Schönwälder <j.schoenwaelder@jacobs-university.de> a écrit :
In the past, there were people on the IESG that would tell you that "a
controlled environment" is in most cases a myth. (There is something
to this argument once you think about how messed up the world appears
to be these days.)

There certainly is a point that compliant implementations must support
a secure transport so that people deploying the technology have the
choice to use it. If an operator then decides to not use the secure
transport, so be it, that is then the operator's free choice (and
responsibility). But not being able make this choice, because a secure
transport is not universally implemented, is an obstacle to avoid.

And yes, this is all about what needs to be implemented to be
compliant. The IESG has little influence on what people use, but it
can influence that people have a choice by requiring the
implementation of a secure transport by compliant implementations.

/js

PS: Of course, I am talking from past experience, and the details of
    the story lines usually change with the IESG composition.

On Mon, Aug 02, 2021 at 07:14:35PM +0200, Pierre Francois wrote:
> Hello everyone,
>
> I'm fine with merging the two drafts. What I wish is that the existing
> implementations that do not mandate dtls activation remain legit wrt the
> resulting RFC.
> We're aiming at lightweight transport in controlled environments here.
>
> Cheers,
> Pierre.
>
> Le lun. 2 août 2021 à 18:26, Kent Watsen <kent@watsen.net> a écrit :
>
> >
> > Mahesh and I were wondering about this.  When Pierre mentioned the DTLS
> > work, we were “surprised” in that we too assumed the “udp” draft had the
> > security bits.
> >
> > It is true that the IESG is all but mandating security for a for years
> > now.  IIRC, Syslog over UDP is obsolete due to being unsecured.
> >
> > K.
> >
> > On Aug 2, 2021, at 11:53 AM, Zmail <alex.huang-feng@insa-lyon.fr> wrote:
> >
> > Noted, I’ll discuss this with Unyte team.
> >
> > Alex
> >
> > On 2 Aug 2021, at 11:40, Jürgen Schönwälder <
> > j.schoenwaelder@jacobs-university.de> wrote:
> >
> > Since I doubt that a protocol not providing security will receive
> > IESG approval, I suggest that this work is getting integrated into
> > draft-ietf-netconf-udp-notif-03.txt.
> >
> > I have not read the content but the I-D seems fairly small so
> > integration into the WG document should be fairly trivial. Given past
> > experience, it might be that the DTLS/UDP transport will become the
> > mandatory to implement transport.
> >
> > /js
> >
> > On Mon, Aug 02, 2021 at 10:59:07AM +0200, Zmail wrote:
> >
> > Hello to everyone,
> >
> > We would like to present a new draft we didn’t have time to show on the
> > last IETF meeting.
> >
> > https://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-dtls/ <
> > https://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-dtls/>
> >
> > This draft defines a mechanism to secure UDP-notif protocol messages using
> > DTLS 1.3.
> > It defines the different layers involved, the DTLS session lifecycle and
> > the mandatory cipher suites to use. It also explicits that no extensions of
> > DTLS are needed and that IP fragmentation should be avoided.
> > We would like to have some feedback for this draft.
> >
> > We will present the draft to the WG on the next IETF meeting.
> >
> > Looking forward to hearing from you,
> >
> > Alex Huang Feng
> >
> >
> > _______________________________________________
> > netconf mailing list
> > netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> >
> >
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
> >
> >
> > _______________________________________________
> > netconf mailing list
> > netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> >
> > _______________________________________________
> > netconf mailing list
> > netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> >

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


--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

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

--------------DC02628D50837D0591E7B2C2-- From nobody Tue Aug 3 10:14: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 61C013A2A61; Tue, 3 Aug 2021 10:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEWyRzvI2dBK; Tue, 3 Aug 2021 10:13:55 -0700 (PDT) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 77F2F3A2A5D; Tue, 3 Aug 2021 10:13:55 -0700 (PDT) Received: by mail-pj1-x1032.google.com with SMTP id q17-20020a17090a2e11b02901757deaf2c8so5726662pjd.0; Tue, 03 Aug 2021 10:13:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=lIBBCuvdEd1pkaDNZZxA5ZDG+BtMhInhY37VvBXVuG0=; b=W2poFtHXVNNa17nCPy4lPqZfNqNzuCdNRzwLYv/gxZJsWq/Zcg0L2+7zxZW/VvrZGs +5Bo+Uq6RnBlj4EXXGYgUFV9NilQjWCy824L3+JTqDxeCNGBMVJzvt1S5PSgI0hduf90 72+Xkx6Wrp33moQ3QUyMGeB35wM57miRjo6/FrHjqClTZaR3NE/oI2BDAxaf2ljnCAfp CjmP5DvbE2Nwl/j+Exx2E7YgenuKjAyaM8NFcJKD0Mfp0KL2vYGdYxa/KSLiPgNQOIw5 HKWRZyp+9lwaQnEeVoWMUxEsykpLHIdjprOdXVgGIPqyGygf2kl3mTJO6Y8V+Qse+6Ci cmHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=lIBBCuvdEd1pkaDNZZxA5ZDG+BtMhInhY37VvBXVuG0=; b=rkaAUfYDLQB1fRU5vMno9uulajzsnooW8d8Pmo7aRJ4pEWifZSQGFy42LOrD9UUsCr afMlZJBa1tqExRmphBkxIwORjxQ6nFcdsTsrxB4ZZV3OD80+LFGkY0xQnTbGQR+11xmZ zhbKvmliMg0SiJ5qd8A82qOWm+4PXLI0YuPSS+XDY1TM2UZ1nshmUBPv2sJhJtd/qaHC MFZHTGOXRP+yyFKDN5M9L840I5BKLxvg3+bqGpgdhDuwIuMxh5/o6WtiHNbvWTflaxmC nsoSR8AYdbwZUDa5Hpr/A+kQu4R5eZg0EUHAW3+U0CoujLMHBAzyzf3WpR43eWOj8T7U Bhfg== X-Gm-Message-State: AOAM532F9CFPAfZysUFzPOQaNv0EX+B5KNB+orvqJBEwqco4ANny09ct UrEYqPhMEh01Lv18zO3UDlIoXjIHz3E= X-Google-Smtp-Source: ABdhPJysKM8dgE3CasK21euZYXDUH0hF92rCWNHdEJjUaheSPfTBkum2/PiXRw5p26UkcEJeiVZRbQ== X-Received: by 2002:a17:902:740c:b029:12c:188b:97c4 with SMTP id g12-20020a170902740cb029012c188b97c4mr1746331pll.55.1628010833968; Tue, 03 Aug 2021 10:13:53 -0700 (PDT) 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 t23sm16218101pfe.8.2021.08.03.10.13.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Aug 2021 10:13:53 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <6C7BBC61-5E9C-49AB-84C6-630CA1F0E141@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_97DFEBBC-1B02-47FD-AE8B-96F1D1BA146C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Tue, 3 Aug 2021 10:13:51 -0700 In-Reply-To: <4f62-61093e00-23-572d3100@187206536> Cc: netmod , =?utf-8?Q?Michal_Va=C5=A1ko?= To: Netconf References: <4f62-61093e00-23-572d3100@187206536> X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [netconf] [netmod] ietf-subscribed-notifications RPC modify-subscription 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, 03 Aug 2021 17:14:02 -0000 --Apple-Mail=_97DFEBBC-1B02-47FD-AE8B-96F1D1BA146C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [Cross posting to netconf] > On Aug 3, 2021, at 6:01 AM, Michal Va=C5=A1ko = wrote: >=20 > Hi, >=20 > it seems the "modify-subscription" RPC [1] includes a mandatory choice = "target" [2]. In effect, it is not possible to modify a subscription for = it to be without a filter. I do not understand the reason for this, is = it intentional or an error in the module? >=20 > Regards, > Michal >=20 > [1] https://www.rfc-editor.org/rfc/rfc8639#page-53 > [2] https://www.rfc-editor.org/rfc/rfc8639#page-48 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_97DFEBBC-1B02-47FD-AE8B-96F1D1BA146C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 [Cross posting to netconf]

On Aug = 3, 2021, at 6:01 AM, Michal Va=C5=A1ko <mvasko@cesnet.cz> = wrote:

Hi,

it seems the = "modify-subscription" RPC [1] includes a mandatory choice "target" [2]. = In effect, it is not possible to modify a subscription for it to be = without a filter. I do not understand the reason for this, is it = intentional or an error in the module?

Regards,
Michal

[1] = https://www.rfc-editor.org/rfc/rfc8639#page-53
[2] https://www.rfc-editor.org/rfc/rfc8639#page-48

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

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_97DFEBBC-1B02-47FD-AE8B-96F1D1BA146C-- From nobody Tue Aug 3 11:21:30 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 F27203A2C7A; Tue, 3 Aug 2021 11:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=futurewei.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 7x0BypLTxy3i; Tue, 3 Aug 2021 11:21:18 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2103.outbound.protection.outlook.com [40.107.243.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 95AA43A2C76; Tue, 3 Aug 2021 11:21:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BJfEZOemWA+c4DyVqgkrh8V80kdlChFAxbsyuQiIHrGklkcKvsilM2K3QZT30h7kjzqQSKS2RJaokd6McnCX3dFPtcz+u7RcAQdKXBKp7eLr31v0uBHHKbaCpyxOsRCvPgXALyAZPIpp8Y28wyPN2nc6rSWzxChhQXiTTjim9bsrkvJwBhoZiztQrmU0A+MnMoLeHhE7/m9tUgH1e+eN/fulpt+E+Pk7/O3nEIkOREHRqf8VnYyjJgIZwvMB4w5ciJBkIwzIy6sdZbLAsGdNs5DcEUKdGctNOAocMwuTcYq+QEKxNA/iWh8IpavKlWKF7T8Bu0GGVfzk20+w55ejwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=658+ejRkqXouQBereWOXTU/3aRmPhxAlX1wEaqgW140=; b=UFedyBMLqViq5Oye/zCX3LvjhcbU28muyCJNzkH1XisOlbk5/y7qj5gFsDGukFjTOFeiam+bl0lIt/x27JQTP0VBsSO0fZiJA4hP+4Sb78JTOGSFzd91qm6XTJuUgKZBHYdBplihbTejG/tmJonyn7oh34VgIdk7cZTPSF04nxy3+uKAZjkVipvJf+3//zvRBDYEHZn1kLEDMKJa7OrrGqnxeW7i4/p4OmOs5zvyy2q/ZnEEbcAHDC0vzCjS6HYtOt2pipBRh5lwVNmlr1+VeXZInqgapm18gJyAhMVmshPX7RdrKNydl9LCkVkkK/Aiqul6gFyl4mr7mE8MZU5mfA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=658+ejRkqXouQBereWOXTU/3aRmPhxAlX1wEaqgW140=; b=YNyrD7RNh8QQLsRrejVELKoG8YjLi2CvQVlRtXQ2sICAaR9IAXgOV6X99hj6g9BsFuy/5B1GmnqxULAaykEddDq+U/VZF3ivZ7v+mVXf00fpAy0+UzCnHdWHpy4ePoJ6XMWgQGABhzqihYHvvDyw4S0Z/SC78T16KNktekoy63A= Received: from BY5PR13MB3793.namprd13.prod.outlook.com (2603:10b6:a03:226::15) by BY5PR13MB3378.namprd13.prod.outlook.com (2603:10b6:a03:1a4::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.9; Tue, 3 Aug 2021 18:21:15 +0000 Received: from BY5PR13MB3793.namprd13.prod.outlook.com ([fe80::fd77:79b3:2b36:f13d]) by BY5PR13MB3793.namprd13.prod.outlook.com ([fe80::fd77:79b3:2b36:f13d%7]) with mapi id 15.20.4394.015; Tue, 3 Aug 2021 18:21:15 +0000 From: Alexander Clemm To: Mahesh Jethanandani , Netconf CC: netmod Thread-Topic: [netmod] ietf-subscribed-notifications RPC modify-subscription Thread-Index: AQHXiGevH16Bf98r9EObFWy1oneQIKtiBQyAgAARH2A= Date: Tue, 3 Aug 2021 18:21:15 +0000 Message-ID: References: <4f62-61093e00-23-572d3100@187206536> <6C7BBC61-5E9C-49AB-84C6-630CA1F0E141@gmail.com> In-Reply-To: <6C7BBC61-5E9C-49AB-84C6-630CA1F0E141@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 840203ed-bca6-4e45-e588-08d956ab7b47 x-ms-traffictypediagnostic: BY5PR13MB3378: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yXnhN9pPeYq7oUyYy+A97EaKG81a8Na42tMp/oY7fBsx0tgunblVoGhqCV5RKVaVTwR0Uerp9X0p/0PX+qVFBjvTNn+W/0jJfKgPm+QnfnJLyes80+VTNsj3lFvc4IYByZOAlhtXM0eV1VuSsmd0XARWgfQ5w6PTBVw34O+du4u87AAR8t1C/91OKNXwsMNORdiFchPPPDxa4waahPlYl9KNHaJYq3+F1k2WJQQ5LjkVF3hLQDUnIzXhY9sjGc/gLdOYDMMRzeV/NWzvj9H/YjFCtTqzyVR28ER2fCldz+ScLLnRpl3GrVki+sIpgPbPrnjX4qQswee+BVSluQossE6lwRJt2r3yZjXVleNoq279aK5xCj5TXK/2Kbidtqb0tyuPXLpue4jxQTqEWbhMYJeBBcEfPiA2mYcyVHOwNmlEBjbWzxj+Ui0E8/RRYkn7Kf+QTnNp8iAZ3oCmjarY8+4cEaFvOspUipwKJKLLfTnfNhL0SuA+yEeJ4VOboJKaY4RnMV1eOUKi5ouWWJCW1gXUNJVZ98LSp1MJ+mH6+6rUPRU2NucdwyBoX0ZBFfcg9EiD5o18XPtMq4h560AWEfPgRuH/vKe+ViSn4U1gNGtazrRVNrFPlCiP/WE+FNmWAi9lP5qdnp31a1ACv15gzC2ns3Au6TcOCf5RmbUB81kRsmsevlisVIkQGTL/Tl6FUzIDo0ez0corj1A0Jsk3fmVGiiGVTcIlF7KPPweDXn41JubQTi/GddsMCxJwDq2W9oEOJTFwBHUbdYzlFgDOKiE2DgLq2L3Js9uFLMrvIjc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB3793.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(366004)(136003)(39840400004)(396003)(2906002)(8936002)(186003)(26005)(8676002)(66946007)(71200400001)(4326008)(52536014)(5660300002)(38070700005)(66446008)(66556008)(15650500001)(110136005)(64756008)(66476007)(316002)(166002)(86362001)(83380400001)(38100700002)(76116006)(6506007)(9326002)(478600001)(966005)(53546011)(9686003)(55016002)(122000001)(33656002)(7696005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-2?Q?cmhDxDAowx3XKYt4AUpkKMPFJP56gekg5pY0GRuX7HicyaxXEnBQiYT6Fn?= =?iso-8859-2?Q?9UyKefD6zKv/ps+VRLqXm4QtMkzv42iWNIkSXfn40jVB5A2hn0bsNe2Zis?= =?iso-8859-2?Q?CX1MucF2y7uFbeu/TaxQka2NqsNR6mPTIy9QhlVJUMrR+FDPMK0+IFqFi8?= =?iso-8859-2?Q?LiDLssbsuVL5Fe8y+ub44dETl3eqRrjJLcRSr9bSAQJoeNtSdlbCIKSlDc?= =?iso-8859-2?Q?COciqBmk5K09zv8zUoeTiRA64kinej2TID5UjixfASZ3pQD9Lxb2rwqOKq?= =?iso-8859-2?Q?E169APjqpGtzk5+RoAnqDrvmkB1j1OopW8M7Tai3UagvaECOu4BFCmVU7x?= =?iso-8859-2?Q?NJsqfnQBx3y6zGgpWyo7po0RnfQCitYwT2yPClAgDFYkdCJD/VCeMFVWjk?= =?iso-8859-2?Q?L+K8anWp4/5otKFd6VnVryucrhOWR7isHWUryB2wNwdGUoslzlO/FABiu4?= =?iso-8859-2?Q?ma6A7m7ppqcadci8LB3PvLqqOKSrIGklJYUL0u2Ru+zf3Q1qmsl1Fr1IKa?= =?iso-8859-2?Q?H59v9/JH9SqPHnsUSQEEFLFU+5Vvx0E0ltnKUOkUwEfQC6za/BkOaDUtjp?= =?iso-8859-2?Q?o/aPdWj9aoIXYm9OzeX7v5kCrGhVgJNMfgJioFk/N6RgiyaZnSlqTDTGOT?= =?iso-8859-2?Q?ezcvhlINSDkKQrHfl/MPIZwerU4/UWLwLXTWZn7co9WLHZi8MyHxKB3jkv?= =?iso-8859-2?Q?zMtDu8h6KWVilDHk3GF20LziSj+VvGellfVv9TL+hlRLwEiEUtbQ2lXyLo?= =?iso-8859-2?Q?dPfcNcc5DlnJaTWNLyZp7/uJIaj4nzp8/G6QrdiRBA8NVM9ox0LSR3sVeM?= =?iso-8859-2?Q?sloXEf5Tp4yQuinNCSwSYWGOLUUrqCrtA1ClBP4YFnGBmW7PXj+68vyurL?= =?iso-8859-2?Q?Uu5VvW25qnjeHEAhKeWzfNtWI42njO8uY7Fx7Kcil1VWPmY1Tlmlc/cr38?= =?iso-8859-2?Q?kS3nCY5akzb7rjdpTLXCY79Edq1kbRNqLebZy+O0hTBFolf+7tyGOQ59LC?= =?iso-8859-2?Q?k/EPwctoORnvPGD5aCgcw89em9NfY8/JwFUmYKGeZbqavwUlT7Vz7a8WnY?= =?iso-8859-2?Q?jrOOmuH3YCkmvjrDD9iP9iTqzhEpWoBXA5XGAplMJOIfcifDDP+q7UAHJg?= =?iso-8859-2?Q?6bMf9Aau9/r81sXyySaZvGQ0Akl++2piczW5OhkpDE7mK9A8qoAEzFxg4C?= =?iso-8859-2?Q?kVjV6pZfsnEN5buV+5Ngpe5xXQJ0pAGf2fuTaq2LJWJy4jMEetqk94QM61?= =?iso-8859-2?Q?N+x7G77yyUDKY9RrK3OcVqdXAYoSNcecJAcHLXKJ1xr0X79CH+Vnsjv/Rt?= =?iso-8859-2?Q?3SdELBOQgJ0T5OO8K8cg2hs6x4gnA2aLCoHT+81FZVKGWtOFi1t78n94il?= =?iso-8859-2?Q?xLsm8GVPWb?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR13MB37930C3A703FDC0816F65C19DBF09BY5PR13MB3793namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR13MB3793.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 840203ed-bca6-4e45-e588-08d956ab7b47 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2021 18:21:15.5678 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JwWGeJcKA3NNLmsF0SQFKKTqhDyvrEsE2yJkzfFAHcj70Mbea7R5b38Pz+5o8bdERSATa6oZCv66rt+7WhHuKw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3378 Archived-At: Subject: Re: [netconf] [netmod] ietf-subscribed-notifications RPC modify-subscription 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, 03 Aug 2021 18:21:24 -0000 --_000_BY5PR13MB37930C3A703FDC0816F65C19DBF09BY5PR13MB3793namp_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi, When you modify the subscription, you need to specify the subscription para= meters that you want to modify the subscription to - i.e. the subscription= parameters that you want to be in effect after modifying the subscription.= If you want nothing to be filtered, just specify a "null" filter. --- Alex From: netmod On Behalf Of Mahesh Jethanandani Sent: Tuesday, August 3, 2021 10:14 AM To: Netconf Cc: netmod Subject: Re: [netmod] ietf-subscribed-notifications RPC modify-subscription [Cross posting to netconf] On Aug 3, 2021, at 6:01 AM, Michal Va=B9ko > wrote: Hi, it seems the "modify-subscription" RPC [1] includes a mandatory choice "tar= get" [2]. In effect, it is not possible to modify a subscription for it to = be without a filter. I do not understand the reason for this, is it intenti= onal or an error in the module? Regards, Michal [1] https://www.rfc-editor.org/rfc/rfc8639#page-53 [2] https://www.rfc-editor.org/rfc/rfc8639#page-48 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani mjethanandani@gmail.com --_000_BY5PR13MB37930C3A703FDC0816F65C19DBF09BY5PR13MB3793namp_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hi,

When you modify the subscription, you need to specif= y the subscription parameters that you want to modify the subscription to &= #8211; i.e.  the subscription parameters that you want to be in effect= after modifying the subscription. If you want nothing to be filtered, just specify a “null” filter. 

--- Alex

 

From: netmod <netmod-bounces@ietf.org> = On Behalf Of Mahesh Jethanandani
Sent: Tuesday, August 3, 2021 10:14 AM
To: Netconf <netconf@ietf.org>
Cc: netmod <netmod@ietf.org>
Subject: Re: [netmod] ietf-subscribed-notifications RPC modify-subsc= ription

 

[Cross posting to netconf]



On Aug 3, 2021, at 6:01 AM, Michal Va=B9ko <mvasko@cesnet.cz> wrote:

 

Hi,

it seems the "modify-subscription" RPC [1] includes a mandatory c= hoice "target" [2]. In effect, it is not possible to modify a sub= scription for it to be without a filter. I do not understand the reason for= this, is it intentional or an error in the module?

Regards,
Michal

[1] https://www.rfc-editor.org/rfc/rfc8639#page-53
[2] https://www.rfc-editor.org/rfc/rfc8639#page-48

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.o= rg/mailman/listinfo/netmod

 

Mahesh Jethanandani=

 =

 =

 

 

--_000_BY5PR13MB37930C3A703FDC0816F65C19DBF09BY5PR13MB3793namp_-- From nobody Tue Aug 3 11:26:19 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 46BC53A2CA0 for ; Tue, 3 Aug 2021 11:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=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 81qj2WZsHCbA for ; Tue, 3 Aug 2021 11:26:12 -0700 (PDT) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (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 1E4EB3A2C9C for ; Tue, 3 Aug 2021 11:26:12 -0700 (PDT) Received: by mail-yb1-xb31.google.com with SMTP id z128so118649ybc.10 for ; Tue, 03 Aug 2021 11:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aESYiC2TKh1s1rloLWc0uP2QOyCov+7Ja0UekzGS//4=; b=GGOza8cYN39YlYKhswMoEytmohnGBSJIpMsLsPebKPYXefQrfKM9EEaOkfV0XQD7Kl xaR8a6SyclqpI91iNr/EKa35TTQqYz2m3FfQVhaslZ1OP6TWT+FsxyOcY/01Qh76gDR1 lucm0rG5NCdilwO8LtqFZc3rcu+/uyL2C1z5rtXOHPlvJW8+1bH9fV8LlmQ8xiJQdloC nSs+oEWs3M7ikGUcmQSEP/mpRjaZnNnIdqgxZJw9ON/XOHKHvl0yMOAz4SyvaiDOmPwX 0yMSbRfg2M++JLhcBG3alLJGEDhAk4xfJURNumf635gLIAk722NNvLf6jNVJxOBLKfvQ 8zlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aESYiC2TKh1s1rloLWc0uP2QOyCov+7Ja0UekzGS//4=; b=gCLBSMUB0dpELCnsHXeZj5uw7ntaX5Yyc9IZduwz852a0bJJin2nvpdZRDI68Z7Uyn vEvcnW2KtDMxtCyBJEzLkBvyCEXMz0+tyWI67I8Ziv15objT3IIzPoC+fOdAYuTk3Rbq 6q0+bOFMbZx418FjWx9hvmy122MSD1jyUJwvb0E0LiDmsQ8nTKhDA6YtGleuoq3DQ3do BDT9szSNpNKJYKJNFEoCdFOivmc0oh7ekiStjJIpKWOElZqaDbfv46bvqsRJh/+wwiq4 HvRwc8/nnWN+JXDNNfb5DoGTHtwDqRtq1jEkjHeeCMB+sqbmAvopcb3q3F1grLpPgZw7 7LCA== X-Gm-Message-State: AOAM530JHBMNwd2a1MtuAFbDJTWMGdpRgJ2Me6CCFjP4c7OJWF9lw1s+ 69iKe2v5gIl12mHKawYet0xz4zugEBQCyNyf88E= X-Google-Smtp-Source: ABdhPJw3dSNiEoe/ljx9G7CJWlu3Z3Hk1Dcr78Kj9xloZYvKlgPtoyF54DRIffSYkLG4hW9++oUN7yPh6TXp4mz+NBs= X-Received: by 2002:a25:aa6f:: with SMTP id s102mr27221794ybi.54.1628015170088; Tue, 03 Aug 2021 11:26:10 -0700 (PDT) MIME-Version: 1.0 References: <152841A6-6A37-4F75-857D-2F70346AFB5D@insa-lyon.fr> <0100017b07afa694-e244f7b7-ab7b-4fab-b669-793f9f6b87d2-000000@email.amazonses.com> <20210802173342.6kv5gkhkuu4tapcw@anna.jacobs.jacobs-university.de> In-Reply-To: From: Pierre Francois Date: Tue, 3 Aug 2021 20:26:01 +0200 Message-ID: To: Benoit Claise Cc: Juergen Schoenwaelder , Kent Watsen , pierre francois , Marco.Tollini1@swisscom.com, Netconf Content-Type: multipart/alternative; boundary="000000000000e6f12205c8abd12d" Archived-At: Subject: Re: [netconf] Securing UDP-notif messages with DTLS 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, 03 Aug 2021 18:26:17 -0000 --000000000000e6f12205c8abd12d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Benoit, It works for me. Pierre. Le mar. 3 ao=C3=BBt 2021 =C3=A0 14:45, Benoit Claise a =C3=A9crit : > Hi, > > This discussion reminds me of IPFIX discussions :-) > Considering that the industry/operators will implement what they need (no= t > more), or request what they need from router vendors, regardless of the > RFCs say, let's go with the path of least resistance regarding publicatio= n. > I would say: merge the two drafts. > > Regards, Benoit > > On 8/2/2021 9:22 PM, Pierre Francois wrote: > > Juergen, > > Thanks for your input. > > IESG composition won't change much to the story on this aspect, I think. > > Alright, I'll discuss with all the authors involved and get back to the > list. I guess no one in the wg will object to a merge if we decide to go > this way. > > Cheers, > > /pfr > > > > > > > Le lun. 2 ao=C3=BBt 2021 =C3=A0 19:33, J=C3=BCrgen Sch=C3=B6nw=C3=A4lder = < > j.schoenwaelder@jacobs-university.de> a =C3=A9crit : > >> In the past, there were people on the IESG that would tell you that "a >> controlled environment" is in most cases a myth. (There is something >> to this argument once you think about how messed up the world appears >> to be these days.) >> >> There certainly is a point that compliant implementations must support >> a secure transport so that people deploying the technology have the >> choice to use it. If an operator then decides to not use the secure >> transport, so be it, that is then the operator's free choice (and >> responsibility). But not being able make this choice, because a secure >> transport is not universally implemented, is an obstacle to avoid. >> >> And yes, this is all about what needs to be implemented to be >> compliant. The IESG has little influence on what people use, but it >> can influence that people have a choice by requiring the >> implementation of a secure transport by compliant implementations. >> >> /js >> >> PS: Of course, I am talking from past experience, and the details of >> the story lines usually change with the IESG composition. >> >> On Mon, Aug 02, 2021 at 07:14:35PM +0200, Pierre Francois wrote: >> > Hello everyone, >> > >> > I'm fine with merging the two drafts. What I wish is that the existing >> > implementations that do not mandate dtls activation remain legit wrt t= he >> > resulting RFC. >> > We're aiming at lightweight transport in controlled environments here. >> > >> > Cheers, >> > Pierre. >> > >> > Le lun. 2 ao=C3=BBt 2021 =C3=A0 18:26, Kent Watsen a= =C3=A9crit : >> > >> > > >> > > Mahesh and I were wondering about this. When Pierre mentioned the >> DTLS >> > > work, we were =E2=80=9Csurprised=E2=80=9D in that we too assumed the= =E2=80=9Cudp=E2=80=9D draft had >> the >> > > security bits. >> > > >> > > It is true that the IESG is all but mandating security for a for yea= rs >> > > now. IIRC, Syslog over UDP is obsolete due to being unsecured. >> > > >> > > K. >> > > >> > > On Aug 2, 2021, at 11:53 AM, Zmail >> wrote: >> > > >> > > =EF=BB=BFNoted, I=E2=80=99ll discuss this with Unyte team. >> > > >> > > Alex >> > > >> > > On 2 Aug 2021, at 11:40, J=C3=BCrgen Sch=C3=B6nw=C3=A4lder < >> > > j.schoenwaelder@jacobs-university.de> wrote: >> > > >> > > Since I doubt that a protocol not providing security will receive >> > > IESG approval, I suggest that this work is getting integrated into >> > > draft-ietf-netconf-udp-notif-03.txt. >> > > >> > > I have not read the content but the I-D seems fairly small so >> > > integration into the WG document should be fairly trivial. Given pas= t >> > > experience, it might be that the DTLS/UDP transport will become the >> > > mandatory to implement transport. >> > > >> > > /js >> > > >> > > On Mon, Aug 02, 2021 at 10:59:07AM +0200, Zmail wrote: >> > > >> > > Hello to everyone, >> > > >> > > We would like to present a new draft we didn=E2=80=99t have time to = show on >> the >> > > last IETF meeting. >> > > >> > > https://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-dtls/ >> < >> > > https://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-dtls/= > >> > > >> > > This draft defines a mechanism to secure UDP-notif protocol messages >> using >> > > DTLS 1.3. >> > > It defines the different layers involved, the DTLS session lifecycle >> and >> > > the mandatory cipher suites to use. It also explicits that no >> extensions of >> > > DTLS are needed and that IP fragmentation should be avoided. >> > > We would like to have some feedback for this draft. >> > > >> > > We will present the draft to the WG on the next IETF meeting. >> > > >> > > Looking forward to hearing from you, >> > > >> > > Alex Huang Feng >> > > >> > > >> > > _______________________________________________ >> > > netconf mailing list >> > > netconf@ietf.org >> > > https://www.ietf.org/mailman/listinfo/netconf >> > > >> > > >> > > >> > > -- >> > > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germa= ny >> > > Fax: +49 421 200 3103 >> > > >> > > >> > > _______________________________________________ >> > > netconf mailing list >> > > netconf@ietf.org >> > > https://www.ietf.org/mailman/listinfo/netconf >> > > >> > > _______________________________________________ >> > > netconf mailing list >> > > netconf@ietf.org >> > > https://www.ietf.org/mailman/listinfo/netconf >> > > >> >> > _______________________________________________ >> > netconf mailing list >> > netconf@ietf.org >> > https://www.ietf.org/mailman/listinfo/netconf >> >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 >> > > _______________________________________________ > netconf mailing listnetconf@ietf.orghttps://www.ietf.org/mailman/listinfo= /netconf > > > --000000000000e6f12205c8abd12d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Benoit,=C2=A0

It works for me.

Pierre.

Le=C2=A0mar. 3 ao=C3=BBt 2021 =C3=A0=C2=A014:= 45, Benoit Claise <benoit.cl= aise@huawei.com> a =C3=A9crit=C2=A0:
=20 =20 =20
Hi,

This discussion reminds me of IPFIX discussions :-)
Considering that the industry/operators will implement what they need (not more), or request what they need from router vendors, regardless of the RFCs say, let's go with the path of least resistance regarding publication. I would say: merge the two drafts.
Regards, Benoit

On 8/2/2021 9:22 PM, Pierre Francois wrote:
Juergen,=C2=A0

Thanks for your input.

IESG composition won't change much to the story on this aspect, I think.
Alright, I'll discuss with all the authors involved and ge= t back to the list. I guess no one in the wg will object to a merge if we decide to go this way.

Cheers,=C2=A0

/pfr






Le=C2=A0lun. 2 ao=C3=BBt 2021= =C3=A0=C2=A019:33, J=C3=BCrgen Sch=C3=B6nw=C3=A4lder <j.schoenwaelder@jacobs-unive= rsity.de> a =C3=A9crit=C2=A0:
In the past, there were people on the IESG that would tell you that "a
controlled environment" is in most cases a myth. (There is something
to this argument once you think about how messed up the world appears
to be these days.)

There certainly is a point that compliant implementations must support
a secure transport so that people deploying the technology have the
choice to use it. If an operator then decides to not use the secure
transport, so be it, that is then the operator's free choice (and
responsibility). But not being able make this choice, because a secure
transport is not universally implemented, is an obstacle to avoid.

And yes, this is all about what needs to be implemented to be
compliant. The IESG has little influence on what people use, but it
can influence that people have a choice by requiring the
implementation of a secure transport by compliant implementations.

/js

PS: Of course, I am talking from past experience, and the details of
=C2=A0 =C2=A0 the story lines usually change with the IESG compos= ition.

On Mon, Aug 02, 2021 at 07:14:35PM +0200, Pierre Francois wrote:
> Hello everyone,
>
> I'm fine with merging the two drafts. What I wish is tha= t the existing
> implementations that do not mandate dtls activation remain legit wrt the
> resulting RFC.
> We're aiming at lightweight transport in controlled environments here.
>
> Cheers,
> Pierre.
>
> Le lun. 2 ao=C3=BBt 2021 =C3=A0 18:26, Kent Watsen <kent@watsen.net> a = =C3=A9crit :
>
> >
> > Mahesh and I were wondering about this.=C2=A0 When Pier= re mentioned the DTLS
> > work, we were =E2=80=9Csurprised=E2=80=9D in that we to= o assumed the =E2=80=9Cudp=E2=80=9D draft had the
> > security bits.
> >
> > It is true that the IESG is all but mandating security for a for years
> > now.=C2=A0 IIRC, Syslog over UDP is obsolete due to bei= ng unsecured.
> >
> > K.
> >
> > On Aug 2, 2021, at 11:53 AM, Zmail <alex.huang-feng@insa-lyon= .fr> wrote:
> >
> > =EF=BB=BFNoted, I=E2=80=99ll discuss this with Unyte te= am.
> >
> > Alex
> >
> > On 2 Aug 2021, at 11:40, J=C3=BCrgen Sch=C3=B6nw=C3=A4l= der <
> > j.schoenwaelder@jacobs-university.de> wrote:
> >
> > Since I doubt that a protocol not providing security will receive
> > IESG approval, I suggest that this work is getting integrated into
> > draft-ietf-netconf-udp-notif-03.txt.
> >
> > I have not read the content but the I-D seems fairly small so
> > integration into the WG document should be fairly trivial. Given past
> > experience, it might be that the DTLS/UDP transport will become the
> > mandatory to implement transport.
> >
> > /js
> >
> > On Mon, Aug 02, 2021 at 10:59:07AM +0200, Zmail wrote:
> >
> > Hello to everyone,
> >
> > We would like to present a new draft we didn=E2=80=99t = have time to show on the
> > last IETF meeting.
> >
> > https://data= tracker.ietf.org/doc/draft-unyte-netconf-udp-notif-dtls/ <
> > https://data= tracker.ietf.org/doc/draft-unyte-netconf-udp-notif-dtls/>
> >
> > This draft defines a mechanism to secure UDP-notif protocol messages using
> > DTLS 1.3.
> > It defines the different layers involved, the DTLS session lifecycle and
> > the mandatory cipher suites to use. It also explicits that no extensions of
> > DTLS are needed and that IP fragmentation should be avoided.
> > We would like to have some feedback for this draft.
> >
> > We will present the draft to the WG on the next IETF meeting.
> >
> > Looking forward to hearing from you,
> >
> > Alex Huang Feng
> >
> >
> > _______________________________________________
> > netconf mailing list
> > n= etconf@ietf.org
> > https://www.ietf.org/mailman/listin= fo/netconf
> >
> >
> >
> > --
> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Campus Ring 1 | 28759 Bremen | Germany
> > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0<https://www.jacobs-university.de/>
> >
> >
> > _______________________________________________
> > netconf mailing list
> > n= etconf@ietf.org
> > https://www.ietf.org/mailman/listin= fo/netconf
> >
> > _______________________________________________
> > netconf mailing list
> > n= etconf@ietf.org
> > https://www.ietf.org/mailman/listin= fo/netconf
> >

> _______________________________________________
> netconf mailing list
> netcon= f@ietf.org
> https://www.ietf.org/mailman/listinfo/ne= tconf


--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jac= obs University Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus R= ing 1 | 28759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<https://www.jacobs-university.de/>

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

--000000000000e6f12205c8abd12d-- From nobody Tue Aug 3 11:45:33 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 5412F3A2D62; Tue, 3 Aug 2021 11:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=futurewei.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 cL3KK380On51; Tue, 3 Aug 2021 11:45:25 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2109.outbound.protection.outlook.com [40.107.220.109]) (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 8E3593A2D5E; Tue, 3 Aug 2021 11:45:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eD9kTuUbkQeWwIbqJzctUReK4gDKY/FNSr+lA171tmNjCcdWD8Q8MX8qgLs8UhTToD9FngKKYGbZTnu0esaE2H+oJNjL3ekniFxJrZStRLEvof66HA3T8yF4lBs3aFfKtvOqxPtJHXGi5y/RPnrsBDhErOd0L0pvlW2eOnodEHI7LAX63RkgPcD6rG+fE+hdZ3rziCPnvUJYmbO+ZkpjMcdl8h2e5cC77/rBNN9Bl8FwWwrN29jf3qCLb4+U8WlmOPaKYdPn4wka0+pHDXjSyA7aFpBeJjm5ysLxwhfAr3lpMf8EAzQhEPWoJ7R6EG/RaUu3CIFj7ojl7atyksEcdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E+C+wANLN5OjnarnJwqo5bRALPB0IZByxY5tmsI+ivA=; b=kJbAYa/bcHg/Xwnx81UTZ4BNDllCd1iLDjhiZZWgYYRnPOlp8mujJMa4O8Nxzv5MCB9Oxs50q8jjlQYGdKvKug4WFC7KWOr3KRw7+gZGRtvSwLVmZ5boA1GZkhmoaLI4fTECtWwob30chUXS78n3dW1KCXnflALuDmtMINpRQ5F+zFFab4+LKwz6i4mEF2IYY8N4IaSXheLcpvJdeX7Y3r391h3SAGZpKOvUB4P7Jd70Mzoxf0IrrFcmIQ0I6L2qAs+a+fu8wwxdZR9oR+4e/0SZfb5y9CcWCTzlpgcE4XQBv8QLT8Jekv4hSALCeIDodlNusFZBZw7MNC4bN6YeGA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E+C+wANLN5OjnarnJwqo5bRALPB0IZByxY5tmsI+ivA=; b=DuteiTcJ04EdGMyeFjfO7Pd5qBpncGYLSctOjy7o6CPO6vXxVyv3Le6aMI6dg4rR70wZHiuY3DassFtHbzVGAxDuVu4dtuFrdtvP6r6yYn1P1CsvjEwEtLzcnCeOJ+4PK5rpQIEj1YrPx75m2bhDQamHMTQ7gA6bMTqqnf1naTI= Received: from BY5PR13MB3793.namprd13.prod.outlook.com (2603:10b6:a03:226::15) by BYAPR13MB2502.namprd13.prod.outlook.com (2603:10b6:a02:ca::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.12; Tue, 3 Aug 2021 18:45:22 +0000 Received: from BY5PR13MB3793.namprd13.prod.outlook.com ([fe80::fd77:79b3:2b36:f13d]) by BY5PR13MB3793.namprd13.prod.outlook.com ([fe80::fd77:79b3:2b36:f13d%7]) with mapi id 15.20.4394.015; Tue, 3 Aug 2021 18:45:22 +0000 From: Alexander Clemm To: Alexander Clemm , Mahesh Jethanandani , Netconf CC: netmod Thread-Topic: [netmod] ietf-subscribed-notifications RPC modify-subscription Thread-Index: AQHXiGevH16Bf98r9EObFWy1oneQIKtiBQyAgAARH2CAAALSoA== Date: Tue, 3 Aug 2021 18:45:22 +0000 Message-ID: References: <4f62-61093e00-23-572d3100@187206536> <6C7BBC61-5E9C-49AB-84C6-630CA1F0E141@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9ccc1574-830f-4dc8-180b-08d956aed99f x-ms-traffictypediagnostic: BYAPR13MB2502: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VrWfvhkYiEktjh+UNcKrOPJK+IiImCAnVTZsWbpvTEuM6/kUbm5TEcxBsFsbPtNwByC8Q5MhYpZ8WXTnYbhjqNyl0K7tPqvGhMXUmoYe7mPJXY8HTcdtS6s0sFKBuqPkfNkbrnw2ACSiVI5fV9Lzl5XjTkclCR+iYhKXQizqlSFUbUUi9RxwM5xnyzLhowUtK0sEgAQqlYmKFaqtstKizEKgWg2Evg3wdVyUwu4icCl42qCnzEW++Oufr+XSdgLta25Qp7BmAy6uu+1E9mn1jh2DAv3YqF7+1z8L9OdFD1f8MjpF+VSIDy3gYKGUPZeUa1hD8/5eE75v2LZSmlsl7iJznoXDALyFWaGAKSTHoZi8lU7XP+jduEWyO17DX58YbE8NUaazYBCVv4yIbn4J39qEsuBT4d+hqsVJaYjgqJzEkJ7/2gHwbdIwf7g5JakQsGoO1P76572FtK0MrE+xnw2nmI9eUMVZDzpMFKobosWoOP+wZ7VNnCVKn0ZH5rpwvVZm9j17rUyFgbKHgZiEFaYB17xG+uN+poatnrTOc8a1pcP01TW2xxCmJ+hBJUjrDMlgbch7QDoYmzNjPr535GJss602M+S2PiVsnzx70bCHmUBqrlWjnw+IXdPDfzGAS8pFyI8roK1E7EoBAesjtUDmfbTWZf5v83hgcRyGWp3RevjOfqDs5tM1jL/xuNoz5t5zaPxNtl30ZiI/6TkhT5t3zgKakuaOXiKg6ryW0i+BJx1f/IPvPycSgLX7mVknXFEeGqN2ISFjE3baxIN2ZUPaoPSlQX1Wa5SJ0rk641U= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB3793.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(39840400004)(136003)(346002)(376002)(2906002)(83380400001)(66556008)(316002)(5660300002)(66946007)(8936002)(55016002)(38070700005)(9686003)(66476007)(966005)(186003)(66446008)(64756008)(110136005)(71200400001)(52536014)(8676002)(478600001)(76116006)(2940100002)(6506007)(66574015)(53546011)(4326008)(86362001)(7696005)(26005)(15650500001)(33656002)(166002)(38100700002)(122000001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-2?Q?2w3EEA7sh0QdVKV/piJiZyLtsHz2JVh+7R2dKLefQz9+hGSRviraEVu+Bz?= =?iso-8859-2?Q?E/eyJItAlrbYjkofU34V2cyd/Qh/oVSYg5ftqVTqfk5jWP8DDMymJSNMlf?= =?iso-8859-2?Q?/AAcyOjx858zFPQL2BTg1N06czgWkEP73Nxf0QxGySL/NipYOgKWbjSwnO?= =?iso-8859-2?Q?WHXxnQzHvHCxyPGJe9ps7x1e6PdF/nPXkNLj+yIqvTaAs81raAPsgRhj96?= =?iso-8859-2?Q?DX+Ax/sG23uqmU/1mkuVQ7KjrUGUul5lFPgftayLRwmnCNuN1vpCDozCSw?= =?iso-8859-2?Q?VKpgpegfklkxuDkWg+PANpvPJ9PheeZRA40UhGheq+8XwmI6q1NSQMp3bQ?= =?iso-8859-2?Q?Sht6xQS1NVbqKfV8Hd3LqrdwXOxSN56jaQbZVP32F2UFIvP+Q7dRgAlho2?= =?iso-8859-2?Q?nqkzdBs4LPiI8ym88/8EtutG1SFxFDLTCqKTCGabgKxGeawr8D4OUgnpAY?= =?iso-8859-2?Q?7J9MZ4blHzO5l0HrjuIqc/8JKisC0MrvzilkXoGjw9+ChrY0UJszyxe7xk?= =?iso-8859-2?Q?q31/uuWsmh5bhkyL27cQRW6iWhIqmsE9AQznLM+VFtBOyIK3prdHkCSTgz?= =?iso-8859-2?Q?+/VQzmumb39K9B4EyrTkBDuIT4oc4IBEcfe5lOwlC0m+uKX6Hw9v3fpHaN?= =?iso-8859-2?Q?vM0T3HIoxbmsEeg+nooQAHfwWnNrafRl9PMSPBm7InDLRWTJgOkRppRo6i?= =?iso-8859-2?Q?3drLI1MSEvBbXGJKfcLfWL6x6LQ+aGR6obFHm7fSspxIR0Qlq6838ukP69?= =?iso-8859-2?Q?UsVJbSUARZOxv+5+8ThbTZcZHXoub8p6rYZ1FXIfKoCm8DMnTzurhbGm4e?= =?iso-8859-2?Q?CsC6Ju5YltCh0RY6mGFgfg6D5zzNtLNsYqptnrWvk20q7yZOUIapk4GKxX?= =?iso-8859-2?Q?l2BL0oK1Ovr7LhKFEfgAqHKa+CBzssTPbA8aUgqjlotG1Poqp5SfWVZxaJ?= =?iso-8859-2?Q?fqGn64+LWqwfJ00wIUOh2Q9SFBD5wT9WqibdnrHDSry3WWnx7g7qMcAi31?= =?iso-8859-2?Q?0yx6BmQwlszAWnfeIkznqUCyxILwWmfizGuJ2wOuj8+sOM3VK6hzRP9USi?= =?iso-8859-2?Q?B+W4kPTCfRObPVTFveTs1FxKTczyPOo9ApjZxLfnhrp5bYi55Oj+TXnHVJ?= =?iso-8859-2?Q?Qvfqq6hebi7MWH2FYiIjpJ6s4cA7tKfrU0AXsMsLvFb/Jp1vykJVmTMCTS?= =?iso-8859-2?Q?7j0yAVxSv+OLiIPyeINDiMMadfXu7dRLJR1K2PMKJ2NGTVpGdnR0BFY82/?= =?iso-8859-2?Q?rOy3Y+IvTYhYVT5KeHsH76xhAXDw7QnxVnDIOJF5SvZZNR4X4Jfh53R5aa?= =?iso-8859-2?Q?zJaegI7V2W3wkd81hwr9dXInE6dZLCZIhCh4RuF0to7gv0W92UAU6DYjmt?= =?iso-8859-2?Q?2c8ncmAoE1?= Content-Type: multipart/alternative; boundary="_000_BY5PR13MB3793BF27F7BAF2B4764D65B6DBF09BY5PR13MB3793namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR13MB3793.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9ccc1574-830f-4dc8-180b-08d956aed99f X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2021 18:45:22.3453 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FGT8f6Xt5Cxoeo0X6g0Ngu6BvdHfkfrii2Q6XUsqNPDjBUb891QHb2LI3oA6dCHhibm4FU3k+RDKHe40VPyDHA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR13MB2502 Archived-At: Subject: Re: [netconf] [netmod] ietf-subscribed-notifications RPC modify-subscription 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, 03 Aug 2021 18:45:32 -0000 --_000_BY5PR13MB3793BF27F7BAF2B4764D65B6DBF09BY5PR13MB3793namp_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable I am just rereading this (sorry, it's been a while since we wrote this). When you look at the modify-subscription RPC, the "case stream" itself is o= ptional, even if the choice "target" is mandatory. So, it is in fact optio= nal to include, no need to specify a null filter. (However, when present, = then parameters of the individual choices need to be present as well.) In = effect, you have a mandatory choice, but can select a case whose nodes are = optional. This is depicted in the Tree Diagram here: RFC 8639: Subscriptio= n to YANG Notifications (rfc-editor.org) What may also be confusing at first is the fact that the choice "target" it= self has "stream" as the single case (in RFC 8639). So, why put a choice t= here in the first place? The reason why it is there is so that it can be au= gmented, and RFC 8641 specifies a second case, namely "datastore". --- Alex From: netmod On Behalf Of Alexander Clemm Sent: Tuesday, August 3, 2021 11:21 AM To: Mahesh Jethanandani ; Netconf Cc: netmod Subject: Re: [netmod] ietf-subscribed-notifications RPC modify-subscription Hi, When you modify the subscription, you need to specify the subscription para= meters that you want to modify the subscription to - i.e. the subscription= parameters that you want to be in effect after modifying the subscription.= If you want nothing to be filtered, just specify a "null" filter. --- Alex From: netmod > On B= ehalf Of Mahesh Jethanandani Sent: Tuesday, August 3, 2021 10:14 AM To: Netconf > Cc: netmod > Subject: Re: [netmod] ietf-subscribed-notifications RPC modify-subscription [Cross posting to netconf] On Aug 3, 2021, at 6:01 AM, Michal Va=B9ko > wrote: Hi, it seems the "modify-subscription" RPC [1] includes a mandatory choice "tar= get" [2]. In effect, it is not possible to modify a subscription for it to = be without a filter. I do not understand the reason for this, is it intenti= onal or an error in the module? Regards, Michal [1] https://www.rfc-editor.org/rfc/rfc8639#page-53 [2] https://www.rfc-editor.org/rfc/rfc8639#page-48 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani mjethanandani@gmail.com --_000_BY5PR13MB3793BF27F7BAF2B4764D65B6DBF09BY5PR13MB3793namp_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

I am just rereading this (sorry, it’s been a w= hile since we wrote this). 

 

When you look at the modify-subscription RPC, the &#= 8220;case stream” itself is optional, even if the choice “targe= t” is mandatory.  So, it is in fact optional to include, no need= to specify a null filter.  (However, when present, then parameters of the individual choices need to be present as well.)  In effect, yo= u have a mandatory choice, but can select a case whose nodes are optional.&= nbsp; This is depicted in the Tree Diagram here: RFC 8639: Subscr= iption to YANG Notifications (rfc-editor.org)

 

What may also be confusing at first is the fact that= the choice “target” itself has “stream” as the sin= gle case (in RFC 8639).  So, why put a choice there in the first place= ? The reason why it is there is so that it can be augmented, and RFC 8641 specifies a second case, namely “datastore”.

--- Alex

 

From: netmod <netmod-bounces@ietf.org> = On Behalf Of Alexander Clemm
Sent: Tuesday, August 3, 2021 11:21 AM
To: Mahesh Jethanandani <mjethanandani@gmail.com>; Netconf <= ;netconf@ietf.org>
Cc: netmod <netmod@ietf.org>
Subject: Re: [netmod] ietf-subscribed-notifications RPC modify-subsc= ription

 

Hi,

When you modify the subscription, you need to specif= y the subscription parameters that you want to modify the subscription to &= #8211; i.e.  the subscription parameters that you want to be in effect= after modifying the subscription. If you want nothing to be filtered, just specify a “null” filter. 

--- Alex

 

From: netmod <netmod-bounces@ietf.org> On Behalf Of Mahesh Jethanandani
Sent: Tuesday, August 3, 2021 10:14 AM
To: Netconf <netconf@ietf.org= >
Cc: netmod <netmod@ietf.org>
Subject: Re: [netmod] ietf-subscribed-notifications RPC modify-subsc= ription

 

[Cross posting to netconf]

 

 

Hi,

it seems the "modify-subscription" RPC [1] includes a mandatory c= hoice "target" [2]. In effect, it is not possible to modify a sub= scription for it to be without a filter. I do not understand the reason for= this, is it intentional or an error in the module?

Regards,
Michal

[1] https://www.rfc-editor.org/rfc/rfc8639#page-53
[2] https://www.rfc-editor.org/rfc/rfc8639#page-48

_______________________________________________
netmod mailing list
netmod@ietf.org
https://ww= w.ietf.org/mailman/listinfo/netmod

 

Mahesh Jethanandani=

 =

 =

 

 

--_000_BY5PR13MB3793BF27F7BAF2B4764D65B6DBF09BY5PR13MB3793namp_-- From nobody Tue Aug 3 23:16:55 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 A9A6C3A0E7B; Tue, 3 Aug 2021 23:16:53 -0700 (PDT) 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, RCVD_IN_DNSWL_BLOCKED=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=cesnet.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DR4RyoozMSGX; Tue, 3 Aug 2021 23:16:48 -0700 (PDT) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee:34]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4D763A0E7A; Tue, 3 Aug 2021 23:16:47 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id C12F760084; Wed, 4 Aug 2021 08:16:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1628057802; bh=xcowt7pCtTlCAkcSVHKD7upg0H2maEyhxWZMgnEHlQM=; h=From:In-Reply-To:Date:Cc:To:Subject; b=LyhG2IiSoDp8e3GpnOaM0WwPduhTyr0stUL4eAvaGR/DvSgtUvLBlg04RMnD80zFg wlHp6M0DctZCzJxu3rYdguNbgbSyIPS846TD7niabb+kTQt/Tot6jG4Gsf0yRVAFB2 x8uvYxrzt6iGgxmXATRp8bhaGSBb2wOHKkFaMmE8= From: =?utf-8?q?Michal_Va=C5=A1ko?= In-Reply-To: Content-Type: text/plain; charset="utf-8" X-Forward: 2001:67c:1220:80c:b5:55d3:81d5:8636 Date: Wed, 04 Aug 2021 08:16:42 +0200 Cc: "Mahesh Jethanandani" , "Netconf" , "netmod" To: "Alexander Clemm" MIME-Version: 1.0 Message-ID: <4f62-610a3100-27-572d3100@123539460> User-Agent: SOGoMail 5.1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] =?utf-8?q?=5Bnetmod=5D_ietf-subscribed-notifications_R?= =?utf-8?q?PC_modify-subscription?= 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, 04 Aug 2021 06:16:54 -0000 Hi Alex, thanks for the reply and I see that I should have included more details= . I understand the design (but it was confusing at first) in general be= cause we have implemented YANG Push as well. However, I do not think > you have a mandatory choice, but can select a case whose nodes are op= tional applies. YANG 1.1 clearly defines [1] that some data nodes must exist i= n a mandatory choice. In this case it can be "stream-filter-name", "str= eam-subtree-filter", or "stream-xpath-filter" (clearly seen from the tr= ee snippet you referenced) but I think it should be allowed to not incl= ude any of these. Please, provide a valid example of "modify-subscripti= on" invocation that uses no filter, I could not come up with any. In my opinion, there should be a refine on the "subscription-policy-mod= ifiable" grouping in this case and change the mandatory to "false". Pro= vided that it should not be allowed to change the stream of a subscript= ion, which I guess it should not. Regards, Michal [1] https://datatracker.ietf.org/doc/html/rfc7950#section-7.9.4 > I am just rereading this (sorry, it's been a while since we wrote thi= s). > > When you look at the modify-subscription RPC, the "case stream" itsel= f is optional, even if the choice "target" is mandatory. So, it is in = fact optional to include, no need to specify a null filter. (However, = when present, then parameters of the individual choices need to be pres= ent as well.) In effect, you have a mandatory choice, but can select a= case whose nodes are optional. This is depicted in the Tree Diagram h= ere: RFC 8639: Subscription to YANG Notifications (rfc-editor.org) > > What may also be confusing at first is the fact that the choice "targ= et" itself has "stream" as the single case (in RFC 8639). So, why put = a choice there in the first place? The reason why it is there is so tha= t it can be augmented, and RFC 8641 specifies a second case, namely "da= tastore". > --- Alex > > From: netmod On Behalf Of Alexander Clemm > Sent: Tuesday, August 3, 2021 11:21 AM > To: Mahesh Jethanandani ; Netconf > Cc: netmod > Subject: Re: [netmod] ietf-subscribed-notifications RPC modify-subscr= iption > > Hi, > When you modify the subscription, you need to specify the subscriptio= n parameters that you want to modify the subscription to - i.e. the su= bscription parameters that you want to be in effect after modifying the= subscription. If you want nothing to be filtered, just specify a "null= " filter. > --- Alex > > From: netmod = > On Behalf Of Mahesh Jethanandani > Sent: Tuesday, August 3, 2021 10:14 AM > To: Netconf > > Cc: netmod > > Subject: Re: [netmod] ietf-subscribed-notifications RPC modify-subscr= iption > > [Cross posting to netconf] > > On Aug 3, 2021, at 6:01 AM, Michal Va=C5=A1ko > wrote: > > Hi, > > it seems the "modify-subscription" RPC [1] includes a mandatory choic= e "target" [2]. In effect, it is not possible to modify a subscription = for it to be without a filter. I do not understand the reason for this,= is it intentional or an error in the module? > > Regards, > Michal > > [1] https://www.rfc-editor.org/rfc/rfc8639#page-53 > [2] https://www.rfc-editor.org/rfc/rfc8639#page-48 > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > From nobody Wed Aug 4 01:01:11 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 85C7F3A0C0C for ; Wed, 4 Aug 2021 01:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=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 fP-BRX84Ca5L for ; Wed, 4 Aug 2021 01:01:05 -0700 (PDT) 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 50F013A0BF4 for ; Wed, 4 Aug 2021 01:01:05 -0700 (PDT) Received: from fraeml708-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Gfkgs71pJz6GFb3 for ; Wed, 4 Aug 2021 16:00:41 +0800 (CST) Received: from dggeml701-chm.china.huawei.com (10.3.17.134) by fraeml708-chm.china.huawei.com (10.206.15.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Wed, 4 Aug 2021 10:00:55 +0200 Received: from dggeml753-chm.china.huawei.com (10.1.199.152) by dggeml701-chm.china.huawei.com (10.3.17.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Wed, 4 Aug 2021 16:00:53 +0800 Received: from dggeml753-chm.china.huawei.com ([10.1.199.152]) by dggeml753-chm.china.huawei.com ([10.1.199.152]) with mapi id 15.01.2176.012; Wed, 4 Aug 2021 16:00:53 +0800 From: Qin Wu To: =?gb2312?B?QmFsqKJ6cyBMZW5neWVs?= , "netconf@ietf.org" Thread-Topic: Comments on draft-tao-netconf-data-export-capabilities Thread-Index: AdeJBGefKPCEiczkTwuY/jEU2p/YgQ== Date: Wed, 4 Aug 2021 08:00:53 +0000 Message-ID: <0cb25885b42c4f7aa18b874e0bba4bef@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.123.117] Content-Type: multipart/alternative; boundary="_000_0cb25885b42c4f7aa18b874e0bba4befhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Comments on draft-tao-netconf-data-export-capabilities 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, 04 Aug 2021 08:01:10 -0000 --_000_0cb25885b42c4f7aa18b874e0bba4befhuaweicom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIEJhbGF6czoNCreivP7IyzogbmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRm Lm9yZ10gtPqx7SBCYWyoonpzIExlbmd5ZWwNCreiy83KsbzkOiAyMDIxxOo31MIzMcjVIDE4OjA1 DQrK1bz+yMs6IG5ldGNvbmZAaWV0Zi5vcmcNCtb3zOI6IFtuZXRjb25mXSBDb21tZW50cyBvbiBk cmFmdC10YW8tbmV0Y29uZi1kYXRhLWV4cG9ydC1jYXBhYmlsaXRpZXMtMA0KDQpIZWxsbywNCqGw Q2FwYWJpbGl0eSB2YWx1ZXMgb24gYSBzbWFsbGVyLCBtb3JlIHNwZWNpZmljIHBhcnQgb2YgdGhl DQpzZXJ2ZXIncyBkYXRhIGFsd2F5cyBvdmVycmlkZSBtb3JlIGdlbmVyaWMgdmFsdWVzLqGxDQoN ClRoaXMgbm90IGZvbGxvd2luZyB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgZHJhZnQtaWV0Zi1uZXRj b25mLW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMuIFBsZWFzZSBjaGVjayB0aGUgZGVzY3JpcHRp b24gb2YgbW9kdWxlIGlldGYtc3lzdGVtLWNhcGFiaWxpdGllcy4NCg0KDQoNCltRaW4gV3VdIFRo YW5rcyBmb3IgY29ycmVjdGlvbiwgeW91IGFyZSByaWdodCwgdGhpcyBzdGF0ZW1lbnQgaXMgbm90 IGFwcGxpY2FibGUgaGVyZSBhbnkgbW9yZSBhbmQgc2hvdWxkIGJlIHRha2VuIG91dC4gV2Ugd2ls bCBtYWtlIHlhbmcgcHVzaCByZWxhdGVkIHNlcnZlciBjYXBhYmlsaXR5IGRlc2NyaWJlZCBpbiB0 aGlzIGRyYWZ0IGFsaWduIHdpdGggdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIEktRC5uZXRjb25mLW5v dGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMuDQoNCg0KDQoyLjEgdHJlZSBkaWFncmFtOg0KDQpodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1ub3Rp ZmljYXRpb24tY2FwYWJpbGl0aWVzI3NlY3Rpb24tNCBzdGF0ZXM6DQoNCkV2ZXJ5IHNldCBvZiBz dWNoIGNhcGFiaWxpdGllcyBTSE9VTEQgYmUNCg0KICAgd3JhcHBlZCBpbiBhIGNvbnRhaW5lciB1 bmRlciB0aGUgYXVnbWVudCBzdGF0ZW1lbnQgdG8gY2xlYW5seQ0KDQogICBzZXBhcmF0ZSBkaWZm ZXJlbnQgZ3JvdXBzIG9mIGNhcGFiaWxpdGllcy4NCg0KVGhpcyBpcyBub3QgZm9sbG93ZWQgaW4g eW91ciBhdWdtZW50IG9mIC9zeXNjOnN5c3RlbS1jYXBhYmlsaXRpZXMNCg0KW1FpbiBXdV0gQWdy ZWUgdG8gZm9sbG93IHRoZSBydWxlIGRlZmluZWQgaW4gSS1ELm5ldGNvbmYtbm90aWZpY2F0aW9u LWNhcGFiaWxpdGllcywgdG8gZG8gc28sIHdlIGhhdmUgdHdvIGNob2ljZQ0KDQphZGQgZGF0YS1l eHBvcnQtZXhwb3J0LWNhcGFiaWxpdGllcyBjb250YWluZXIgb24gdG9wIG9mIGRhdGEtZXhwb3J0 LWNhcGFiaWxpdGllcyBsaXN0Ow0KDQpjaGFuZ2UgZGF0YS1leHBvcnQtY2FwYWJpbGl0aWVzIGxp c3QgaW50byBkYXRhLWV4cG9ydC1jYXBhYmlsaXRpZXMgY29udGFpbmVyIGFuZCBpbiBhZGRpdGlv biwgY2hhbmdlIGFsbCB0aGUgbGVhZiB1bmRlciBkYXRhLWV4cG9ydC1jYXBhYmlsaXRpZXMgbGlz dCBpbnRvIGxlYWYgbGlzdCB0byBzdXBwb3J0IGUuZy4sIG11bHRpcGxlIHRyYW5zcG9ydCwgZW5j b2Rpbmcgc3VwcG9ydC4NCg0KTXkgcHJlZmVyZW5jZSBpcyB0aGUgb3B0aW9uIGIuDQoNCg0KDQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1u b3RpZmljYXRpb24tY2FwYWJpbGl0aWVzI3NlY3Rpb24tNC4yIHN0YXRlczoNCg0KMSkgc2VhcmNo IGZvciBhIGRhdGFzdG9yZS1jYXBhYmlsaXRpZXMgbGlzdCBlbnRyeSBmb3INCg0KICAgICB0aGUg c3BlY2lmaWMgZGF0YXN0b3JlLiBXaGVuIHN0YXRpbmcgYSBzcGVjaWZpYyBjYXBhYmlsaXR5LCB0 aGUNCg0KICAgICByZWxhdGl2ZSBwYXRoIGZvciBhbnkgc3BlY2lmaWMgY2FwYWJpbGl0eSBtdXN0 IGJlIHRoZSBzYW1lDQoNCiAgICAgdW5kZXIgdGhlIHN5c3RlbS1jYXBhYmlsaXRpZXMgY29udGFp bmVyIGFuZCB1bmRlciB0aGUNCg0KICAgICBwZXItbm9kZS1jYXBhYmlsaXRpZXMgbGlzdDogdGhl IHNhbWUgZ3JvdXBpbmcgZm9yIGRlZmluaW5nDQoNCiAgICAgdGhlIGNhcGFiaWxpdGllcyBNVVNU IGJlIHVzZWQuDQoNClBsZWFzZSBmb2xsb3cgdGhhdC4gUGxlYXNlIHNwZWNpZnkgZXZlcnkgY2Fw YWJpbGl0eSBib3RoIG9uIHRoZSB1bmRlciBzeXN0ZW0tY2FwYWJpbGl0aWVzIGFuZCB1bmRlciBw ZXItbm9kZS1jYXBhYmlsaXRpZXMuDQoNCkEgc3BlY2lmaWMgY2FwYWJpbGl0eSBtaWdodCBhbHdh eXMgYmUgZGVmaW5lZCBvbiBzeXN0ZW0gb3IgZGF0YXN0b3JlIG9yIHBlci1ub2RlIGxldmVsIG9u IHlvdXIgc3lzdGVtLCBvdGhlciBzeXN0ZW1zIG1pZ2h0IGhhdmUgYSBtb3JlIGdyYW51bGFyIGNh cGFiaWxpdHkgc2V0LiBFdmVuIGlmIGEgY2FwYWJpbGl0eSBpcyBhdmFpbGFibGUgb24gZS5nLiBw ZXItbm9kZSBsZXZlbCwgeW91ciBzeXN0ZW0gaXMgZnJlZSBub3QgdG8gdXNlIGl0Lg0KDQpbUWlu IFd1XSBBZ3JlZSB0byBhZGQgcGVyLW5vZGUgbGV2ZWwgY2FwYWJpbGl0aWVzLg0KDQpXaHkgaXMg dGhpcyBtb2RlbCB2YWxpZCBvbmx5IGZvciB0ZWxlbWV0cnk/IEl0IHNob3VsZCBiZSB1c2FibGUg Zm9yIG90aGVyIG5vdGlmaWNhdGlvbnMgdG9vLiBFLmcuIHRyYW5zcG9ydC1wcm90b2NvbCBvciBz ZWN1cml0eSBpcyBqdXN0IGFzIHJlbGV2YW50IGZvciBhbnkgb3RoZXIgbm90aWZpY2F0aW9uLg0K DQpbUWluIFd1XSBZZXMsIHRlbGVtZXRyeSBpcyB0aGUga2V5IHVzZSBjYXNlLiBCdXQgSSBhZ3Jl ZSBpdCBpcyBhcHBsaWNhYmxlIG90aGVyIG5vdGlmaWNhdGlvbiwgd2lsbCBtYWtlIHRoaXMgY2xl YXIgaW4gdGhlIG5leHQgdmVyc2lvbi4NCg0KV2hhdCBpcyBldmVudCBiYXNlZCBzdWJzY3JpcHRp b24gbW9kZT8NCg0KW1FpbiBXdV0gVGltZXItZXZlbnQtc3VwcG9ydCBpcyBzaW1pbGFyIHRvIHdo YXQgaXMgZGVzY3JpYmVkIGluIHBlcmlvZCBzdWJzY3JpcHRpb24sIGkuZS4sIHB1c2ggdXBkYXRl IGlzIHRyaWdnZXJlZCBwZXJpb2RpY2FsbHksIHRoZSB0aW1lciB3aWxsIGJlIHNldCB0byB0aGUg dXBkYXRlIGludGVydmFsIGRlZmluZWQgaW4gUkZDODY0MS4gSSBmZWVsIHRoaXMgcGFyYW1ldGVy IGlzIGEgbGl0dGxlIGJpdCByZWR1bmRhbnQsIEkgdGhpbmsgd2UgY2FuIHRha2UgaXQgb3V0Lg0K DQpXaGF0IGlzIGNvdXRuZXIgYmFzZWQgdHJpZ2dlciBtb2RlID8NCg0KW1FpbiBXdV0gQ291bnRl ciB0aHJlc2hvbGQgc3VwcG9ydCBpcyBhcHBsaWNhYmxlIHRvIGEgc2V0IG9mIGRhdGEgbm9kZXMg d2hpY2ggYXJlIGludGVnZXIgYnVpbHQtaW4gdHlwZS4gIFRoZSBkYXRhIG5vZGUgdmFsdWUgYXJl IHJlc3RyaWN0ZWQgbm90IHRvIGV4Y2VlZCB0aGUgc3BlY2lmaWMgdGhyZXNob2xkIHZhbHVlLiBC dXQgbm90IGFsbCB0aGUgZGF0YSBub2RlcyBuZWVkIHRvIGhhdmUgc3VjaCBjb3VudGVyIHRocmVz aG9sZCBzdXBwb3J0IHNpbmNlIG5vdCBhbGwgb2YgZGF0YSBub2RlcyBhcmUgaW50ZWdlciBidWls dC1pbiB0eXBlLiBFdmVuIGRhdGEgbm9kZXMgYXJlIGludGVnZXIgYnVpbHQtaW4gdHlwZSwgaXQg aXMgbm90IG1hbmRhdG9yeSB0byBzdXBwb3J0IHRocmVzaG9sZCBjb25zdHJhaW50cywgYmUgZGVm YXVsdCwgdGhpcyBmZWF0dXJlIGNhbiBiZSBkaXNhYmxlZC4NCg0KRG9lcyB0aGlzIHBhcmFtZXRl ciBtYWtlIHNlbnNlIHRvIHlvdT8NCg0KDQoNCnN1cHByZXNzLXJlZHVuZGFudCwgdGhpcyBtZWNo YW5pc20gaXMgbm90IGRlc2NyaWJlZC4gV2hhdCBpcyBzdXBwcmVzc2VkPw0KDQpbUWluIFd1XSBT dXBwcmVzcy1yZWR1bmRhbnQgaW5kaWNhdGUgdGhhdCBkdXBsaWNhdGVkIGRhdGEgb2JqZWN0cyBz aG91bGQgYmUgc3VwcHJlc3NlZCB0byBiZSBzZW50IGR1cmluZyBlYWNoIHVwZGF0ZSBpbnRlcnZh bC4NCg0KVGhlIG1lY2hhbmlzbSBpcyB0byBkZXRlY3QgdGhlIG9jY3VycmVuY2Ugb2YgbW9uaXRv cmVkIGRhdGEgb2JqZWN0IGluIGVhY2ggdXBkYXRlIGludGVydmFsLiBJZiB0aGUgb2NjdXJyZW5j ZSBpcyBlcXVhbCB0byBvciBtb3JlIHRoYW4gMiwgdGhlIHZhbHVlIG9mIG1vbml0b3JlZCBkYXRh IG9iamVjdCB3aWxsIG5vdCBiZSByZXBvcnRlZC4NCg0KDQpSZWdhcmRzIEJhbGF6cw0KDQotLQ0K QmFsYXpzIExlbmd5ZWwgICAgICAgICAgICAgICAgICAgIFNlbmlvciBTcGVjaWFsaXN0ICAgICAg ICAgICAgICAgICAgICAgICBFcmljc3NvbiBIdW5nYXJ5IEx0ZC4NCk1vYmlsZTogKzM2LTcwLTMz MC03OTA5ICAgICAgICAgICAgICBlbWFpbDogQmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24uY29tPG1h aWx0bzpCYWxhenMuTGVuZ3llbEBlcmljc3Nvbi5jb20+DQoNCg== --_000_0cb25885b42c4f7aa18b874e0bba4befhuaweicom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable 
Hi, Balazs:

=B7=A2=BC=FE=C8=CB: netconf [mailto:netconf-bounces@ietf.org] =B4=FA=B1=ED Bal=A8=A2zs Lengyel
=B7=A2=CB=CD=CA=B1=BC=E4: 2021=C4=EA7=D4=C231=C8=D5 18:05
=CA=D5=BC=FE=C8=CB: netconf@ietf.org
=D6=F7=CC=E2: [netconf] Comments on draft-tao-netconf-data-export-capabilities-0

 

Hello,

=A1=B0Capability values on a smaller, more specific part o= f the

server's data always override more generic values.=A1=B1

This not following the latest version of draft-ietf-netconf-notific=
ation-capabilities. Please check the description of module ietf-system-capa=
bilities.
 
[Qin Wu] Thanks for correction, you are right, this statement is =
not applicable here any more and should be taken out. We will make yang pus=
h related server capability described in this draft align with the latest v=
ersion of I-D.netconf-notification-capabilities.

 =



2.1 tree diagram: 


https://datatracker.ietf.org/doc/html=
/draft-ietf-netconf-notification-capabilities#section-4 states: 


Every set of such capabilities SHOULD be


   wrapped in a container under the augment statement to =
cleanly


   separate different groups of capabilities.<=
/span>


This is not followed in your augment of /sysc:system-capabilities


[Qin Wu] Agree =
to follow the rule defined in I-D.netconf-notification-capabilities, to do =
so, we have two choice


add data-export-export-capabilities contain=
er on top of data-export-capabilities list;


change data-export-capabilities list into d=
ata-export-capabilities container and in addition, change all the leaf unde=
r data-export-capabilities list into leaf list to support e.g., multiple tr=
ansport, encoding support.


My preference is the option b.


 


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


1) search for a datastore-capabilities list entry for


     the specific datastore. When stating a spe=
cific capability, the


     relative path for any specific capability =
must be the same


     under the system-capabilities container an=
d under the


     per-node-capabilities list: the same group=
ing for defining


     the capabilities MUST be used.<=
/span>


Please follow that. Please specify every capability both on the und=
er system-capabilities and under per-node-capabilities.

A specific capability might always be defined on system or datastor=
e or per-node level on your system, other systems might have a more granula=
r capability set. Even if a capability is available on e.g. per-node level,=
 your system is free not to use it.


[Qin Wu] Agree to add per-node level capabilities.


Why is this model valid only for telemetry? It should be usable for=
 other notifications too. E.g. transport-protocol or security is just as re=
levant for any other notification.


[Qin Wu] Yes, telemetry is the key use case. But I agree it is applicable o=
ther notification, will make this clear in the next version.


What is event based subscription mode?


[Qin Wu] Timer-event-support is similar to what is described in p=
eriod subscription, i.e., push update is triggered periodically, the timer =
will be set to the update interval defined in RFC8641. I feel this paramete=
r is a little bit redundant, I think we can take it out.<=
/span>


What is coutner based trigger mode ?


[Qin Wu] Counter threshold support is applicable to =
a set of data nodes which are integer built-in type.  The data node va=
lue are restricted not to exceed the specific threshold value. But not all =
the data nodes need to have such counter threshold support since not all of=
 data nodes are integer built-in type. Even data nodes are integer built-in=
 type, it is not mandatory to support threshold constraints, be default, th=
is feature can be disabled.


Does this parameter make sense to you?=



 


suppress-redundant, this mechanism is not described. What is suppre=
ssed?


[Qin Wu] Suppress-redundant indicate that duplicated=
 data objects should be suppressed to be sent during each update interval.<=
o:p>


The mechanism is to detect the occurrence o=
f monitored data object in each update interval. If the occurrence is equal=
 to or more than 2, the value of monitored data object will not be reported=
.


 


Regards Balazs


 


--



Balazs Lengyel      =
;            &n=
bsp; Senior Specialist         =
;            &n=
bsp; Ericsson Hungary Ltd.



Mobile: +36-70-330-7909   &nbs=
p;          email:
Balazs.Lengyel@ericsson.com<=
/a>


 
--_000_0cb25885b42c4f7aa18b874e0bba4befhuaweicom_-- From nobody Wed Aug 4 01:17:33 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 E34DC3A0D2E for ; Wed, 4 Aug 2021 01:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 BhV2IdTlx3hM for ; Wed, 4 Aug 2021 01:17:27 -0700 (PDT) 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 307D63A0D2A for ; Wed, 4 Aug 2021 01:17:27 -0700 (PDT) Received: from fraeml740-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Gfl2s46J7z6DKWp; Wed, 4 Aug 2021 16:17:09 +0800 (CST) Received: from dggeme768-chm.china.huawei.com (10.3.19.114) by fraeml740-chm.china.huawei.com (10.206.15.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Wed, 4 Aug 2021 10:17:21 +0200 Received: from dggeml753-chm.china.huawei.com (10.1.199.152) by dggeme768-chm.china.huawei.com (10.3.19.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Wed, 4 Aug 2021 16:17:19 +0800 Received: from dggeml753-chm.china.huawei.com ([10.1.199.152]) by dggeml753-chm.china.huawei.com ([10.1.199.152]) with mapi id 15.01.2176.012; Wed, 4 Aug 2021 16:17:19 +0800 From: Qin Wu To: Mahesh Jethanandani , "netconf@ietf.org" Thread-Topic: Compression mode vs Encoding format (draft-tao-netconf-data-export-capabilities) Thread-Index: AdeJCR8GwIJ+F9GrSD6JPQCDkPH5pQ== Date: Wed, 4 Aug 2021 08:17:19 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.123.117] Content-Type: multipart/alternative; boundary="_000_b56baf2d47ca4be3a3da983850d5f0f3huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netconf] Compression mode vs Encoding format (draft-tao-netconf-data-export-capabilities) 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, 04 Aug 2021 08:17:32 -0000 --_000_b56baf2d47ca4be3a3da983850d5f0f3huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Mahesh: One of comments you raised in the meeting on draft-tao-netconf-data-export-= capabilities-05 (https://datatracker.ietf.org/doc/html/draft-tao-netconf-da= ta-export-capabilities-05.txt) is the relation between compression mode and Encoding format. Here is a few clarifications: 1. Compression mode is not encoding format Compression mode indicates that the server support data compression or defl= ate or gzip compression supported by NETCONF. The deflate or gzip compressi= on will be applied to xml file. It is independent from what encoding (e.g., JSON, XML, binary) is chosen fo= r exported data. 2. Compression mode is not header compression defined by HTTP2. 3. Right now, we haven't seen any standard documenting compression mo= de. Efficient XML Interchange Capability for NETCONF has been proposed befo= re https://datatracker.ietf.org/doc/html/draft-varga-netconf-exi-capability-01 but it doesn't reach any agreement. The idea is very close to what we propo= se in draft-tao-netconf-data-export-capabilities-05. But still different. Hope this clarify your comment. -Qin (On behalf of authors) --_000_b56baf2d47ca4be3a3da983850d5f0f3huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Mahesh:

One of comments you raised= in the meeting on draft-tao-netconf-data-export-capabilities-05 (https://d= atatracker.ietf.org/doc/html/draft-tao-netconf-data-export-capabilities-05.= txt)

is the relation between co= mpression mode and Encoding format.

Here is a few clarificatio= ns:

1= .   &= nbsp;   Compression mode is not= encoding format

Compression mode indicates that the server support data compression or d= eflate or gzip compression supported by NETCONF. The deflate or gzip compre= ssion will be applied to xml file.

It is independent from what encoding (e.g., JSON, XML, binary) is chose= n for exported data.

2= .   &= nbsp;   Compression mode is not= header compression defined by HTTP2.

3= .   &= nbsp;   Right now, we havenR= 17;t seen any standard documenting compression mode. Efficient XML Intercha= nge Capability for NETCONF has been proposed before

https://datatracker.ietf.org/doc/html/draft-varga-netconf-e= xi-capability-01

but it doesn’t reach any agreement. The idea is very close to what= we propose in draft-tao-netconf-data-export-capabilities-05. But still dif= ferent.

Hope this clarify your com= ment.

 

-Qin (On behalf of authors= )

--_000_b56baf2d47ca4be3a3da983850d5f0f3huaweicom_-- From nobody Wed Aug 4 10:17:23 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 810203A0C4F; Wed, 4 Aug 2021 10:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=futurewei.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 ytBSqY1TEpkt; Wed, 4 Aug 2021 10:17:16 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2096.outbound.protection.outlook.com [40.107.220.96]) (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 30DA93A0C4E; Wed, 4 Aug 2021 10:17:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a3/AuJE3GUdEmbbRYAnurB8FfJVt7avB4Cvc6lK7tl9I9l3sJoGKL1KRbVHyx2FoguhNNMZfQsKjeekMjSzkNz0vC6DUAeMkw6X/GNae2MoTGBQK9RggQSoZxXYdLzEjCtKyiDKxF7s6k3Yi7IMDePxvxZ444wPu4/AhCHD0KnDoM8U+3c5Lw367zk8EbSxfrzogDRxCd/SjkwLZ7nrKm5f3tBBN6OTVykVncChCFZO6Z603xFNugAnn7C72NrnBZ1hBzD8Z5FxUlZTPyosg+up4BNELz5fWjokgn1JWgdNk2fjfVRxKKAmHyXaq2y37RXiRweqj77fj92I6Cerc+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zYX47yXUBfSt6NkbDT6mbGIl9l2MzZ0qVh82GHO8Gqs=; b=jM98zkyNluAhtAH0lNgwsMjzaLWzgzG9D3/tdHH2OuA4asdCLpQF7bo+Ei6WXxvMaNZoTBvHWdCaKcPH6ksWbAOsOqJqSY1AXbK4tDMEwIcaI8BVsu9pSNLXFlVtryMMH0+XVNt0D5ao39Kj4yOl81PZpXi0dHyP1QiP207OX6vdzTBrHFfu70Fi8Q8O2SdlhSkV2klj6ZhT6XLEiDNVaYhEPZkRcOVBcCq5NP5ltOeSMZBbra3BElFWd6aQOfWRLevEPnGdLQT7NENy4h0N28agsavq3ZYrYx1OW/jl3fwSQ706dMmLcwF+7xAuyr5yc+/oIGvsjVjjctxiAwkCoA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zYX47yXUBfSt6NkbDT6mbGIl9l2MzZ0qVh82GHO8Gqs=; b=LhVgOLIOOq7vPpwJQh0uxVrQ5a6IP/+lE4Tj+sGuyjfNKToFibX2GZq19zfeZbJzATjc4N6np2wPJmJsRXf8NY5chUBsRKgMdD3GnsXEH1mVQ0TXMmX4tKc8fSuF/zKuSc41a1dNJ0MxHvqjxR8EN3pnjE3ECP6DQmscZOnOOyM= Received: from BY5PR13MB3793.namprd13.prod.outlook.com (2603:10b6:a03:226::15) by BYAPR13MB2614.namprd13.prod.outlook.com (2603:10b6:a03:b4::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.4; Wed, 4 Aug 2021 17:17:14 +0000 Received: from BY5PR13MB3793.namprd13.prod.outlook.com ([fe80::fd77:79b3:2b36:f13d]) by BY5PR13MB3793.namprd13.prod.outlook.com ([fe80::fd77:79b3:2b36:f13d%7]) with mapi id 15.20.4394.016; Wed, 4 Aug 2021 17:17:14 +0000 From: Alexander Clemm To: =?iso-8859-2?Q?Michal_Va=B9ko?= CC: Mahesh Jethanandani , Netconf , netmod Thread-Topic: [netconf] [netmod] ietf-subscribed-notifications RPC modify-subscription Thread-Index: AQHXiPhOA+l8symYmkKNiB/5WkMK9qtjkvMw Date: Wed, 4 Aug 2021 17:17:14 +0000 Message-ID: References: <4f62-610a3100-27-572d3100@123539460> In-Reply-To: <4f62-610a3100-27-572d3100@123539460> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cesnet.cz; dkim=none (message not signed) header.d=none;cesnet.cz; dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d0bdefaa-07aa-4b30-6c64-08d9576bb417 x-ms-traffictypediagnostic: BYAPR13MB2614: 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: 17l7KLXP4LEEyNHyoZrhl50flabfpMJdJmr1UTeZb/ttmvinKW2vbdmFmhmDMwHoFp+gxCcxa6W/IpxjR6jtR2AQ7SyL5bQCgqzz6ue9z/y8kYkJWufv2LuhVffhqTpfnrxUsj1QVUxF4cyEMoLZEWLFfmIisX40yQE+R110D7gNv1l3jBG4Emi/MMeL8PkFXEVZ8nHk8mY5MQBWVEhZi9ux/7P7Q4o9WLscerHjRBT7Wio+PpTMI1lbp7u4BvnmcpAK7Mc+N1oinb0iRsXOJYcK5gxgD51qe8Ss7IJVn4Ogf7Ew+uyFQk8z3RCVMw04Q1pLYrGsHpr19iUHihulFWq7NKpI1tP4MGGcJjNljnYCElrqA6Xwdz5bZ0ovPqhb710wvYAYfpY5592RrLfeA+hHSkshobAi8d/jcIAF/V6fEt74X2e8tUGYN4nCPciu/94Pr9SiFU6iodW9Epmv5BmuA4RGzWuXbVVVb+OiIBkhyvGTLlXnC9JYCZY1vVITWNgroQQOH+cptVYzYLzq88pHNDW6ob46sF+9KpX2AdIbofG/4OzZhjx7Pja/WZuVeodWKJg+nRx7bFM0iHgtRifnGo3mQ8GAOpeRdYckYvvKVwwfj27JZwlmWuVGy2H1/AMXiLxYFqHD3cUV5S8hINRQaxOyu8srYLo8NLE1iQsyIOMukqrYatfQNi7o40EtHaRLY7NDT6YT4XDrJnse17ls6XKzcJ/MpGSgHa5bmgyaL6NZ7HmkAAld4trpPqm2KqIsdJFTc6r52pWKie2dzq41+bPF2cj50Dlu4EwfWqC3PRNY9jChntN31Mgk5kb5xkex8V70SDFjyYN6ogNPwA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB3793.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(366004)(346002)(39840400004)(396003)(136003)(66446008)(26005)(71200400001)(5660300002)(186003)(83380400001)(122000001)(55016002)(478600001)(38100700002)(9686003)(2906002)(966005)(15650500001)(45080400002)(66574015)(6916009)(76116006)(33656002)(7696005)(66946007)(316002)(66556008)(8936002)(53546011)(86362001)(66476007)(8676002)(52536014)(38070700005)(6506007)(54906003)(64756008)(15974865002)(4326008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-2?Q?E2oMHOwaW8rUR5TUTavtgCgatP+bW4hMU9QW6VfF6RlK+DANVHkrru0us4?= =?iso-8859-2?Q?xd60qMCTZ3sFHc6xCtnc0kfEueo0XL4NZYVCdtq3e/tST3kgj640bTkjaE?= =?iso-8859-2?Q?DKrVp4qvOEArzGSlU3p5N4usYkJ3Jd/JSlLM9LGls7OTgoFdsNHYu9bTaf?= =?iso-8859-2?Q?9eXTvtQLwRjQol5u0L6Jt/SR0NfJxncTvpCOKWmS0i7iQ766egB0AB3iH2?= =?iso-8859-2?Q?8AH7GZWkTwLm8/qVpO4dJ4hEjyHcHGQ9B+XJvk3cLD1jrkifvU1/7NeEj9?= =?iso-8859-2?Q?rJigNsgiKd2DqzTgwmRih0UlHE5IKD5qtQr21iGHMK+2AOuFUYie4UrO9I?= =?iso-8859-2?Q?T09GUlRzvNE8AD+ifV9PfN1XQOSmIY1aHFtKRpHfxQH99RXC9PjOqf8658?= =?iso-8859-2?Q?TlFELv7bAGuaA1bfqDEmV22nfNbYWG6tAMcTMOA35XHkd7zaM+4rKXZDqA?= =?iso-8859-2?Q?wqoXuYOx3WsRUNso0itjXCB4+slRbF1D37J7txT7ADzvxZuMWzZejplxF7?= =?iso-8859-2?Q?h4/SZCza2JnRNt36tBleYQxvciV7ACM0KAgDFCl+JeAdsaX+8YfxdqhZjy?= =?iso-8859-2?Q?eUiJh1hVbo4dbzWkxJxReNIOdUISnDyyrWVHjr5V7HxwBN2gpMtiCsPlQH?= =?iso-8859-2?Q?Rh3o1vurHiqbszAvw0ay+t2acSLp0gJxEoETAmJjEFbBw+ytvCuPTfK18q?= =?iso-8859-2?Q?MC7RMqNOYihhMQ1fzwxjVJU4O5uZU0kUae6GGZ8vCClKqfFAzbgAxgHAKV?= =?iso-8859-2?Q?Dxde3kCccg5PeOkq/kUcSLqpzXqZzpRUr6C/XPFlJ5j4h3Hj36gRmRM996?= =?iso-8859-2?Q?ue0ZLmbRfAEfC5H6+kfqbmGbVX/edW2rYhM8dKpTZxt1QJBPmPzV1oGjf9?= =?iso-8859-2?Q?XIveYwoedn8lI4hLklu8i6urKj1y62wMfwZO6ErVAR5LX9akLjXMxyptBU?= =?iso-8859-2?Q?3gH4skPwcQh06RC+VE5lhSYQwwUqMarzrHqJe68CKTolQEtORMTMj4fuO8?= =?iso-8859-2?Q?v2hgpmIr3rqX30NYup2rHZ/ir7h1Mx6+2fRtZ+1ChExoUSwd2e3jq3EkN6?= =?iso-8859-2?Q?jzsTyi4rxUltn1j2iBV9ChNsvLXSZ0BWxPEXacrAP+NGoGm695f7ZBjqlF?= =?iso-8859-2?Q?1w82uZu+CfkxW182p2SnbM+WmPKjMVD6DOVZAsbXlvGv71bHs64bggshBc?= =?iso-8859-2?Q?rvsqTSdK3CGTHXxsJIyrJQaVCeSpr0k7uUpQcaoSDpN4fsA0+L8D5l39Vb?= =?iso-8859-2?Q?qwgopjrSm7heXvouQ+9DclT7niaedIIvClRWWHoUFUElFFTo+Fpm7/3yBn?= =?iso-8859-2?Q?YBc1AUhcgbQcPU0Hvyp/0OzEyXTVJzTF8QTHNxdw3JoZyPYDT/bZ8Q94/a?= =?iso-8859-2?Q?a78yrjEWzD?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR13MB3793.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d0bdefaa-07aa-4b30-6c64-08d9576bb417 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2021 17:17:14.2006 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +mSgiQ1KCDR+4JSjr5iKajPKvqOEDxKm6ovQotHB7YbdnQWIaE2GpAYbIXZoIXOCc9D4+UKr85v57jIN1vDFHA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR13MB2614 Archived-At: Subject: Re: [netconf] [netmod] ietf-subscribed-notifications RPC modify-subscription 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, 04 Aug 2021 17:17:22 -0000 Hi Michal, I think in part there is a YANG question here - can you define a mandatory = choice, for which you have multiple cases, each of which (or even, just one= of which) contains only nodes that are optional - which allows for the sce= nario that despite a mandatory choice, there are no data nodes from that ch= oice included. I think the answer here is yes.=20 As for the use of this in modify-subscription, one question is why you woul= d invoke this in the first place if you didn't want to modify something - s= o generally you would include a data node anyway. One possibility to do th= is without changing the filter would be if you wanted to simply change the = stop time, which is outside the target choice. Now, could we have made a d= ifferent design choice to make the target choice optional? Possibly, but in= the end I don't think it matters as at the end of the day you can make the= same modifications. (Or is there something that you think this does not a= llow you to do, which it should be able to?) So, I do not think this const= itutes an error in the module, but a design choice that IMHO at this point = should simply be accepted. =20 Kind regards -- Alex -----Original Message----- From: Michal Va=B9ko =20 Sent: Tuesday, August 3, 2021 11:17 PM To: Alexander Clemm Cc: Mahesh Jethanandani ; Netconf ; netmod Subject: Re: [netconf] [netmod] ietf-subscribed-notifications RPC modify-su= bscription Hi Alex, thanks for the reply and I see that I should have included more details. I = understand the design (but it was confusing at first) in general because we= have implemented YANG Push as well. However, I do not think > you have a mandatory choice, but can select a case whose nodes are=20 > optional applies. YANG 1.1 clearly defines [1] that some data nodes must exist in a = mandatory choice. In this case it can be "stream-filter-name", "stream-subt= ree-filter", or "stream-xpath-filter" (clearly seen from the tree snippet y= ou referenced) but I think it should be allowed to not include any of these= . Please, provide a valid example of "modify-subscription" invocation that = uses no filter, I could not come up with any. In my opinion, there should be a refine on the "subscription-policy-modifia= ble" grouping in this case and change the mandatory to "false". Provided th= at it should not be allowed to change the stream of a subscription, which I= guess it should not. Regards, Michal [1] https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdat= atracker.ietf.org%2Fdoc%2Fhtml%2Frfc7950%23section-7.9.4&data=3D04%7C01= %7Calex%40futurewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8ff2a3b240= 189c753a1d5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CTWFpbGZsb3d8eyJ= WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&= sdata=3DJNWOC8ym9j%2FNJ90oSRNyHCMSdEv%2FoLDru%2FRnsUozFGo%3D&reserved= =3D0 > I am just rereading this (sorry, it's been a while since we wrote this). >=20 > When you look at the modify-subscription RPC, the "case stream" itself=20 > is optional, even if the choice "target" is mandatory. So, it is in=20 > fact optional to include, no need to specify a null filter. (However,=20 > when present, then parameters of the individual choices need to be=20 > present as well.) In effect, you have a mandatory choice, but can=20 > select a case whose nodes are optional. This is depicted in the Tree=20 > Diagram here: RFC 8639: Subscription to YANG Notifications=20 > (rfc-editor.org) ttps%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8639%23page-16&data=3D04% > 7C01%7Calex%40futurewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8 > ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CT > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI > 6Mn0%3D%7C1000&sdata=3DSVPLR4GRtZC6U%2FaJu5c0Yf9jhRjHocOhtRp7Mtzt6tM > %3D&reserved=3D0> >=20 > What may also be confusing at first is the fact that the choice "target" = itself has "stream" as the single case (in RFC 8639). So, why put a choice= there in the first place? The reason why it is there is so that it can be = augmented, and RFC 8641 specifies a second case, namely "datastore". > --- Alex >=20 > From: netmod On Behalf Of Alexander Clemm > Sent: Tuesday, August 3, 2021 11:21 AM > To: Mahesh Jethanandani ; Netconf=20 > > Cc: netmod > Subject: Re: [netmod] ietf-subscribed-notifications RPC=20 > modify-subscription >=20 > Hi, > When you modify the subscription, you need to specify the subscription pa= rameters that you want to modify the subscription to - i.e. the subscripti= on parameters that you want to be in effect after modifying the subscriptio= n. If you want nothing to be filtered, just specify a "null" filter. > --- Alex >=20 > From: netmod >=20 > On Behalf Of Mahesh Jethanandani > Sent: Tuesday, August 3, 2021 10:14 AM > To: Netconf > > Cc: netmod > > Subject: Re: [netmod] ietf-subscribed-notifications RPC=20 > modify-subscription >=20 > [Cross posting to netconf] >=20 > On Aug 3, 2021, at 6:01 AM, Michal Va=B9ko > wrote: >=20 > Hi, >=20 > it seems the "modify-subscription" RPC [1] includes a mandatory choice "t= arget" [2]. In effect, it is not possible to modify a subscription for it t= o be without a filter. I do not understand the reason for this, is it inten= tional or an error in the module? >=20 > Regards, > Michal >=20 > [1]=20 > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > rfc-editor.org%2Frfc%2Frfc8639%23page-53&data=3D04%7C01%7Calex%40fut > urewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8ff2a3b240189c753a > 1d5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CTWFpbGZsb3d8eyJWIj > oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&am > p;sdata=3DAf%2FoGGiRESrrd4PzdNp5PvII4%2BQ54rwToLe1%2FrvJH%2BE%3D&res > erved=3D0 F%2Fwww.rfc-editor.org%2Frfc%2Frfc8639%23page-53&data=3D04%7C01%7Cal > ex%40futurewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8ff2a3b240 > 189c753a1d5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CTWFpbGZsb3 > d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7 > C1000&sdata=3DAf%2FoGGiRESrrd4PzdNp5PvII4%2BQ54rwToLe1%2FrvJH%2BE%3D > &reserved=3D0> [2]=20 > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > rfc-editor.org%2Frfc%2Frfc8639%23page-48&data=3D04%7C01%7Calex%40fut > urewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8ff2a3b240189c753a > 1d5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CTWFpbGZsb3d8eyJWIj > oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&am > p;sdata=3DpsIuBfJ%2BIoKGcky%2F8LJZmK1MtKhaUPynUtO1Y7vODdk%3D&reserve > d=3D0 www.rfc-editor.org%2Frfc%2Frfc8639%23page-48&data=3D04%7C01%7Calex%4 > 0futurewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8ff2a3b240189c > 753a1d5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CTWFpbGZsb3d8ey > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100 > 0&sdata=3DpsIuBfJ%2BIoKGcky%2F8LJZmK1MtKhaUPynUtO1Y7vODdk%3D&res > erved=3D0> >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=3D04%7C01%7Calex%40futur > ewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8ff2a3b240189c753a1d > 5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000& > sdata=3D5ywkEvUGzZK9Bn6woKv3HqATU1eYsTYGYHW%2FEnl9FxY%3D&reserved=3D0= < > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=3D04%7C01%7Calex%40futur > ewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8ff2a3b240189c753a1d > 5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000& > sdata=3D5ywkEvUGzZK9Bn6woKv3HqATU1eYsTYGYHW%2FEnl9FxY%3D&reserved=3D0= > >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 > From nobody Thu Aug 5 01:11:36 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 595803A15D7; Thu, 5 Aug 2021 01:11:13 -0700 (PDT) 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 (1024-bit key) header.d=cesnet.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-vWT8z0snYi; Thu, 5 Aug 2021 01:11:08 -0700 (PDT) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee:34]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E5373A15E6; Thu, 5 Aug 2021 01:11:07 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 110) id B4C8260095; Thu, 5 Aug 2021 10:11:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1628151062; bh=0Qhhrz2jP1UQSmaZiAgKJbKS3bAZmn0spacJha0Pqm0=; h=From:In-Reply-To:Date:Cc:To:Subject; b=iXj6QdMewRb+fhSGlFzD7ExKo/XVECaZRt1bCPNiuUW25aFI1Dlg7/zOEZ/CUvJmt VnZx/0eVm1oQT4wjZKCMsYCtvjyZn8xN/y8kidYG14uyczw8q0yGHPoJLJzX981vsM npMK4dfcV/zRI3eImoidpiVFipgiaMR/xi5TN+UA= From: =?utf-8?q?Michal_Va=C5=A1ko?= In-Reply-To: Content-Type: text/plain; charset="utf-8" X-Forward: 2001:67c:1220:80c:b5:55d3:81d5:8636 Date: Thu, 05 Aug 2021 10:11:02 +0200 Cc: "Mahesh Jethanandani" , "Netconf" , "netmod" To: "Alexander Clemm" MIME-Version: 1.0 Message-ID: <79a4-610b9d00-5f-54377380@80566603> User-Agent: SOGoMail 5.1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] =?utf-8?q?=5Bnetmod=5D_ietf-subscribed-notifications_R?= =?utf-8?q?PC_modify-subscription?= 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, 05 Aug 2021 08:11:22 -0000 Hi Alex, > I think in part there is a YANG question here - can you define a mand= atory choice, for which you have multiple cases, each of which (or even= , just one of which) contains only nodes that are optional - which allo= ws for the scenario that despite a mandatory choice, there are no data = nodes from that choice included. I think the answer here is yes. Per the reference to the YANG 1.1 specification I have included in my l= ast email I am quite certain the answer is no, you cannot have a mandat= ory choice without any data nodes. That is exactly what is written in t= he RFC: If "mandatory" is "true", at least one node from exactly one of the choice's case branches MUST exist. > As for the use of this in modify-subscription, one question is why yo= u would invoke this in the first place if you didn't want to modify som= ething - so generally you would include a data node anyway. One possib= ility to do this without changing the filter would be if you wanted to = simply change the stop time, which is outside the target choice. Yes, that is exactly the use-case. Are you saying changing the stop-tim= e of a subscription without a filter is not supported? > Now, could we have made a different design choice to make the target= choice optional? Possibly, but in the end I don't think it matters as = at the end of the day you can make the same modifications. (Or is ther= e something that you think this does not allow you to do, which it shou= ld be able to?) See my previous comment. > So, I do not think this constitutes an error in the module, but a des= ign choice that IMHO at this point should simply be accepted. Not sure why I am the first to bring this up, but I do think the design= includes an error or is simply based on wrong YANG-related assumptions= . Regards, Michal > > Kind regards > -- Alex > > -----Original Message----- > From: Michal Va=C5=A1ko > Sent: Tuesday, August 3, 2021 11:17 PM > To: Alexander Clemm > Cc: Mahesh Jethanandani ; Netconf ; netmod > Subject: Re: [netconf] [netmod] ietf-subscribed-notifications RPC mod= ify-subscription > > Hi Alex, > > thanks for the reply and I see that I should have included more detai= ls. I understand the design (but it was confusing at first) in general = because we have implemented YANG Push as well. However, I do not think > > > you have a mandatory choice, but can select a case whose nodes are = > > optional > > applies. YANG 1.1 clearly defines [1] that some data nodes must exist= in a mandatory choice. In this case it can be "stream-filter-name", "s= tream-subtree-filter", or "stream-xpath-filter" (clearly seen from the = tree snippet you referenced) but I think it should be allowed to not in= clude any of these. Please, provide a valid example of "modify-subscrip= tion" invocation that uses no filter, I could not come up with any. > > In my opinion, there should be a refine on the "subscription-policy-m= odifiable" grouping in this case and change the mandatory to "false". P= rovided that it should not be allowed to change the stream of a subscri= ption, which I guess it should not. > > Regards, > Michal > > [1] https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= %2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7950%23section-7.9.4&data= =3D04%7C01%7Calex%40futurewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C= 0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637636546076357311%7CUnknown= %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX= VCI6Mn0%3D%7C1000&sdata=3DJNWOC8ym9j%2FNJ90oSRNyHCMSdEv%2FoLDru%2FR= nsUozFGo%3D&reserved=3D0 > > > I am just rereading this (sorry, it's been a while since we wrote t= his). > > > > When you look at the modify-subscription RPC, the "case stream" its= elf > > is optional, even if the choice "target" is mandatory. So, it is i= n > > fact optional to include, no need to specify a null filter. (Howev= er, > > when present, then parameters of the individual choices need to be = > > present as well.) In effect, you have a mandatory choice, but can = > > select a case whose nodes are optional. This is depicted in the Tr= ee > > Diagram here: RFC 8639: Subscription to YANG Notifications > > (rfc-editor.org) > ttps%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8639%23page-16&data=3D= 04% > > 7C01%7Calex%40futurewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0f= ee8 > > ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%= 7CT > > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX= VCI > > 6Mn0%3D%7C1000&sdata=3DSVPLR4GRtZC6U%2FaJu5c0Yf9jhRjHocOhtRp7Mt= zt6tM > > %3D&reserved=3D0> > > > > What may also be confusing at first is the fact that the choice "ta= rget" itself has "stream" as the single case (in RFC 8639). So, why pu= t a choice there in the first place? The reason why it is there is so t= hat it can be augmented, and RFC 8641 specifies a second case, namely "= datastore". > > --- Alex > > > > From: netmod On Behalf Of Alexander Clemm= > > Sent: Tuesday, August 3, 2021 11:21 AM > > To: Mahesh Jethanandani ; Netconf > > > > Cc: netmod > > Subject: Re: [netmod] ietf-subscribed-notifications RPC > > modify-subscription > > > > Hi, > > When you modify the subscription, you need to specify the subscript= ion parameters that you want to modify the subscription to - i.e. the = subscription parameters that you want to be in effect after modifying t= he subscription. If you want nothing to be filtered, just specify a "nu= ll" filter. > > --- Alex > > > > From: netmod > > > On Behalf Of Mahesh Jethanandani > > Sent: Tuesday, August 3, 2021 10:14 AM > > To: Netconf > > > Cc: netmod > > > Subject: Re: [netmod] ietf-subscribed-notifications RPC > > modify-subscription > > > > [Cross posting to netconf] > > > > On Aug 3, 2021, at 6:01 AM, Michal Va=C5=A1ko > wrote: > > > > Hi, > > > > it seems the "modify-subscription" RPC [1] includes a mandatory cho= ice "target" [2]. In effect, it is not possible to modify a subscriptio= n for it to be without a filter. I do not understand the reason for thi= s, is it intentional or an error in the module? > > > > Regards, > > Michal > > > > [1] > > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= Fwww. > > rfc-editor.org%2Frfc%2Frfc8639%23page-53&data=3D04%7C01%7Calex%= 40fut > > urewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8ff2a3b240189c7= 53a > > 1d5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CTWFpbGZsb3d8eyJ= WIj > > oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000= &am > > p;sdata=3DAf%2FoGGiRESrrd4PzdNp5PvII4%2BQ54rwToLe1%2FrvJH%2BE%3D&am= p;res > > erved=3D0 > F%2Fwww.rfc-editor.org%2Frfc%2Frfc8639%23page-53&data=3D04%7C01= %7Cal > > ex%40futurewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8ff2a3b= 240 > > 189c753a1d5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CTWFpbGZ= sb3 > > d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3= D%7 > > C1000&sdata=3DAf%2FoGGiRESrrd4PzdNp5PvII4%2BQ54rwToLe1%2FrvJH%2= BE%3D > > &reserved=3D0> [2] > > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= Fwww. > > rfc-editor.org%2Frfc%2Frfc8639%23page-48&data=3D04%7C01%7Calex%= 40fut > > urewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8ff2a3b240189c7= 53a > > 1d5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CTWFpbGZsb3d8eyJ= WIj > > oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000= &am > > p;sdata=3DpsIuBfJ%2BIoKGcky%2F8LJZmK1MtKhaUPynUtO1Y7vODdk%3D&re= serve > > d=3D0 > www.rfc-editor.org%2Frfc%2Frfc8639%23page-48&data=3D04%7C01%7Ca= lex%4 > > 0futurewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8ff2a3b2401= 89c > > 753a1d5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CTWFpbGZsb3d= 8ey > > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C= 100 > > 0&sdata=3DpsIuBfJ%2BIoKGcky%2F8LJZmK1MtKhaUPynUtO1Y7vODdk%3D&am= p;res > > erved=3D0> > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > > netmod mailing list > > netmod@ietf.org > > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= Fwww. > > ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=3D04%7C01%7Calex%40= futur > > ewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8ff2a3b240189c753= a1d > > 5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CTWFpbGZsb3d8eyJWI= joi > > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&a= mp; > > sdata=3D5ywkEvUGzZK9Bn6woKv3HqATU1eYsTYGYHW%2FEnl9FxY%3D&reserv= ed=3D0< > > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= Fwww. > > ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=3D04%7C01%7Calex%40= futur > > ewei.com%7Cbe2fa9745ccb473b902108d9570f6ea0%7C0fee8ff2a3b240189c753= a1d > > 5591fedc%7C1%7C0%7C637636546076357311%7CUnknown%7CTWFpbGZsb3d8eyJWI= joi > > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&a= mp; > > sdata=3D5ywkEvUGzZK9Bn6woKv3HqATU1eYsTYGYHW%2FEnl9FxY%3D&reserv= ed=3D0> > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > > > > > > > > From nobody Fri Aug 6 04:12:43 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 8F1013A2900; Fri, 6 Aug 2021 04:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 x-PgqNoUAOdQ; Fri, 6 Aug 2021 04:11:52 -0700 (PDT) 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 36DAA3A28FF; Fri, 6 Aug 2021 04:11:52 -0700 (PDT) Received: from fraeml741-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Gh2q32svHz6GDsq; Fri, 6 Aug 2021 19:11:27 +0800 (CST) Received: from dggeme719-chm.china.huawei.com (10.1.199.115) by fraeml741-chm.china.huawei.com (10.206.15.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Fri, 6 Aug 2021 13:11:47 +0200 Received: from dggeme770-chm.china.huawei.com (10.3.19.116) by dggeme719-chm.china.huawei.com (10.1.199.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Fri, 6 Aug 2021 19:11:45 +0800 Received: from dggeme770-chm.china.huawei.com ([10.8.68.58]) by dggeme770-chm.china.huawei.com ([10.8.68.58]) with mapi id 15.01.2176.012; Fri, 6 Aug 2021 19:11:45 +0800 From: "maqiufang (A)" To: Juergen Schoenwaelder CC: "netmod@ietf.org" , "netconf@ietf.org" Thread-Topic: [netmod][netconf] Question on Subtree Filtering Usage Example Thread-Index: AdeKsyDJmZPyEoTYRIii/yYWDv0UMw== Date: Fri, 6 Aug 2021 11:11:45 +0000 Message-ID: <43f259b7886c4aa4aee3577a4904ce1a@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.123.93] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] [netmod] Question on Subtree Filtering Usage Example 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, 06 Aug 2021 11:11:57 -0000 SGksIA0KVGhhbmtzIGZvciB5b3VyIHJlcGx5LiBDcm9zcyBwb3N0aW5nIHRvIE5FVENPTkYgbGlz dC4NCg0KQmVzdCBSZWdhcmRzLA0KUWl1ZmFuZyBNYQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogSsO8cmdlbiBTY2jDtm53w6RsZGVyIFttYWlsdG86ai5zY2hvZW53YWVsZGVy QGphY29icy11bml2ZXJzaXR5LmRlXSANClNlbnQ6IEZyaWRheSwgQXVndXN0IDYsIDIwMjEgNjoz NSBQTQ0KVG86IG1hcWl1ZmFuZyAoQSkgPG1hcWl1ZmFuZzFAaHVhd2VpLmNvbT4NCkNjOiBuZXRt b2RAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBRdWVzdGlvbiBvbiBTdWJ0cmVlIEZp bHRlcmluZyBVc2FnZSBFeGFtcGxlDQoNCkhpLA0KDQp5b3UgbWF5IHdhbnQgdG8gc2VuZCB5b3Vy IHF1ZXN0aW9uIHRvIHRoZSBuZXRjb25mIGxpc3Qgc2luY2UgdGhpcyBpcyBhIHByb3RvY29sIHF1 ZXN0aW9uIGFuZCBub3QgYSBZQU5HIHF1ZXN0aW9uLiAoQ29uY2VybmluZyB5b3VyIHF1ZXN0aW9u LCBwbGVhc2UgcmVhZCBzZWN0aW9uIDYuMi40ICJTZWxlY3Rpb24gTm9kZXMiLiBUaGVyZSBpcyBu byByZXN0cmljdGlvbiB0byBvbmx5IG9uZSBzZWxlY3Rpb24gbm9kZSBhcyBmYXIgYXMgSSBjYW4g dGVsbC4pDQoNCi9qcw0KDQpPbiBGcmksIEF1ZyAwNiwgMjAyMSBhdCAwOToyOTo1MEFNICswMDAw LCBtYXFpdWZhbmcgKEEpIHdyb3RlOg0KPiBIaSwgYWxsOg0KPiANCj4gSW4gUkZDNjI0MSBzZWN0 aW9uIDYuNChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL3JmYzYyNDEjc2Vj dGlvbi02LjQpLCBzZXZlcmFsIHNpbmdsZSBzdWJ0cmVlIGZpbHRlcmluZyBleGFtcGxlcyBhcmUg Z2l2ZW4uDQo+IEkgYW0gd29uZGVyaW5nIHdoZXRoZXIgd2UgY2FuIHNlbGVjdCBtdWx0aXBsZSBl bGVtZW50cyB3aXRoaW4gdGhlIDx1c2Vycz4gU3VidHJlZS4NCj4gTm90ZSB0aGF0IHdlIGFsc28g YXNzdW1lICJ1c2VycyIgcGFyZW50IGVsZW1lbnQgaXMgdGhlIGNvbnRhaW5lciB3aXRoIHByZXNl bmNlIHN1YnN0YXRlbWVudC4NCj4gSGVyZSBpcyB0aGUgUlBDIHJlcXVlc3QgbWVzc2FnZSB3aXRo IHNwZWNpZmljIHN1YnRyZWUgZmlsdGVyaW5nIDoNCj4gICAgICA8cnBjIG1lc3NhZ2UtaWQ9IjEw MSINCj4gICAgICAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFz ZToxLjAiPg0KPiAgICAgICAgPGdldC1jb25maWc+DQo+ICAgICAgICAgIDxzb3VyY2U+DQo+ICAg ICAgICAgICAgPHJ1bm5pbmcvPg0KPiAgICAgICAgICA8L3NvdXJjZT4NCj4gICAgICAgICAgPGZp bHRlciB0eXBlPSJzdWJ0cmVlIj4NCj4gICAgICAgICAgICA8dG9wIHhtbG5zPSJodHRwOi8vZXhh bXBsZS5jb20vc2NoZW1hLzEuMi9jb25maWciPg0KPiAgICAgICAgICAgICAgPHVzZXJzPg0KPiAg ICAgICAgICAgICAgICA8dXNlcj4NCj4gICAgICAgICAgICAgICAgICAgICA8bmFtZS8+DQo+ICAg ICAgICAgICAgICAgICAgICAgIDx0eXBlLz4NCj4gICAgICAgICAgICAgICAgPC91c2VyPg0KPiAg ICAgICAgICAgICAgPC91c2Vycz4NCj4gICAgICAgICAgICA8L3RvcD4NCj4gICAgICAgICAgPC9m aWx0ZXI+DQo+ICAgICAgICA8L2dldC1jb25maWc+DQo+ICAgICAgPC9ycGM+DQo+IA0KPiBJIGFt IHdvbmRlcmluZyB3aGF0IFJQQyByZXNwb25zZSB3aWxsIGxvb2sgbGlrZT8gSXQgd2lsbCByZXNw b25kIHdpdGggbnVsbCBvciBpdCB3aWxsIHJlc3BvbmQgYXMgZm9sbG93czoNCj4gICAgICA8cnBj LXJlcGx5IG1lc3NhZ2UtaWQ9IjEwMSINCj4gICAgICAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJh bXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiPg0KPiAgICAgICAgPGRhdGE+DQo+ICAgICAgICAg IDx0b3AgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9zY2hlbWEvMS4yL2NvbmZpZyI+DQo+ICAg ICAgICAgICAgPHVzZXJzPg0KPiAgICAgICAgICAgICAgPHVzZXI+DQo+ICAgICAgICAgICAgICAg IDxuYW1lPnJvb3Q8L25hbWU+DQo+ICAgICAgICAgICAgICAgIDx0eXBlPnN1cGVydXNlcjwvdHlw ZT4NCj4gICAgICAgICAgICAgIDwvdXNlcj4NCj4gICAgICAgICAgICAgIDx1c2VyPg0KPiAgICAg ICAgICAgICAgICA8bmFtZT5mcmVkPC9uYW1lPg0KPiAgICAgICAgICAgICAgICA8dHlwZT5hZG1p bjwvdHlwZT4NCj4gICAgICAgICAgICAgIDwvdXNlcj4NCj4gICAgICAgICAgIDwvdXNlcnM+DQo+ ICAgICAgICA8L3RvcD4NCj4gICAgPC9kYXRhPg0KPiA8L3JwYy1yZXBseT4NCj4gDQo+IA0KPiAN Cj4gQmVzdCBSZWdhcmRzLA0KPiBRaXVmYW5nIE1hDQoNCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRt b2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt b2QNCg0KDQotLSANCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZl cnNpdHkgQnJlbWVuIGdHbWJIDQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1 cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEw MyAgICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo= From nobody Mon Aug 9 15:52:03 2021 Return-Path: <0100017b2d1d8404-36f80ded-fb6b-4f53-983a-c346966a85c3-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 F41733A1C05; Mon, 9 Aug 2021 15:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxmGvkj1EQtO; Mon, 9 Aug 2021 15:51:56 -0700 (PDT) Received: from a48-93.smtp-out.amazonses.com (a48-93.smtp-out.amazonses.com [54.240.48.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C88853A1C08; Mon, 9 Aug 2021 15:51:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1628549514; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:Cc:To:Feedback-ID; bh=CQmKDBrSshuFU2wl2npuphYdIRFhI3c3B7NeEJxUN6U=; b=J+U2n95FEX02K+e62pRQZugDp0EDsk9jePsoafpeMIuDDD+x0PnRZ2wKBVLh1KcP ugxoa+5I6mOLxumFvGtWzC8RUoV7gjCc9aPORsz6RQkUbCzmwPKxetUROtDJj19lx+E m6wDhz7Hpy4TbswwPPLtK+ccrwYEmYBko2yWk6Wc= 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.100.0.2.22\)) Message-ID: <0100017b2d1d8404-36f80ded-fb6b-4f53-983a-c346966a85c3-000000@email.amazonses.com> Date: Mon, 9 Aug 2021 22:51:54 +0000 Cc: "netconf-chairs@ietf.org" To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3654.100.0.2.22) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.08.09-54.240.48.93 Archived-At: Subject: [netconf] Draft 111 NETCONF minutes posted 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, 09 Aug 2021 22:52:01 -0000 NETCONF WG, The draft minutes from the 111 session have been posted: = https://datatracker.ietf.org/meeting/111/materials/minutes-111-netconf-00.= md Please take a moment to ensure that your valuable comments have been = captured. Kent and Mahesh From nobody Mon Aug 9 16:12:39 2021 Return-Path: <0100017b2d307005-c8c91273-452b-4466-9798-c8f318712cdd-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 C301F3A1CB6 for ; Mon, 9 Aug 2021 16:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djjGPA6RrrKh for ; Mon, 9 Aug 2021 16:12:36 -0700 (PDT) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4DC13A1CB7 for ; Mon, 9 Aug 2021 16:12:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1628550754; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=i2MBiQcdjJu+EwMi6mIs84BoE0IrsdhYQEEqGDzk8Fs=; b=YfENmS6WPX8+BEcpDwoRdp020lOQhRQ9XLuOZsRwoigR/W7y0UI4fj/UQjQsPX6P AGc2wmHl7GgUOav7UUBC8LxlZWltkapDUPY1i02urFFFMp5dOnSc8CDN+VZ2pfalddz Am+0GtSGOexkhbW6oH7PbDfaeIDc9F15by0P0jKY= From: Kent Watsen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Message-ID: <0100017b2d307005-c8c91273-452b-4466-9798-c8f318712cdd-000000@email.amazonses.com> Date: Mon, 9 Aug 2021 23:12:34 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3654.100.0.2.22) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.08.09-54.240.8.83 Archived-At: Subject: [netconf] https-notif: concern w/ YANG module 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, 09 Aug 2021 23:12:39 -0000 Hiya Folks, The 111 discussed again the idea of using an IANA-maintained module = (i.e., derived from an IANA registry). Pictorially: Current: strings --> IANA registry Proposed: strings --> IANA registry --> IANA-maintained module The value of using a YANG module is, presumably, to enable finer = syntactic validation (e.g., "type identityref=E2=80=9D vs. "type = string=E2=80=9D), but by whom and why? - Receivers validating their messages before transmission to = Publishers may occur in development, but is typically disabled in = production. - Publishers validating messages received from Receivers is common. = But the draft says that Publishers should ignore any unknown = capabilities. However, YANG-validation would produce a validation = error, which seems worse. Yes, the validation error could be examined = and, in case only due to an unknown identityref, ignored, but does it = make sense to do this? At this point, the CONs seem to outweigh the PROs. We=E2=80=99re = considering to abandon the YANG-module=E2=80=A6comments? Kent and Mahesh (as authors) From nobody Mon Aug 9 16:30:35 2021 Return-Path: <0100017b2d40c875-874f41f5-6f64-4f8e-acb1-cf0e3816ff3d-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 2FCF83A1D5A; Mon, 9 Aug 2021 16:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrjU1tw-m3HJ; Mon, 9 Aug 2021 16:30:27 -0700 (PDT) Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBAE53A1D59; Mon, 9 Aug 2021 16:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1628551825; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:Cc:To:Feedback-ID; bh=XgFsIMMRIWmbPIuGiVSuvf08OHO+AgT/JU/iYJHYMKQ=; b=YC3nV3nd3NKkgLgr9OHO9umDuyDbeWmIryJyI6wjC76gK+3KmHCW4DmUzlJGtnNR ZVqom2a3sSXty3X9cFb7NPrFN2bUPrh97+e1EWi6GV3YZCPTZJZquCXyn6SS/Ytf0ik 8cSmCtMleJYQ3agZaftFgsZcob7oO7rFEH4iJC8A= From: Kent Watsen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Message-ID: <0100017b2d40c875-874f41f5-6f64-4f8e-acb1-cf0e3816ff3d-000000@email.amazonses.com> Date: Mon, 9 Aug 2021 23:30:25 +0000 Cc: "netconf@ietf.org" To: draft-tao-netconf-data-export-capabilities@ietf.org, draft-claise-netconf-metadata-for-collection@ietf.org, draft-wang-netconf-adaptive-subscription@ietf.org X-Mailer: Apple Mail (2.3654.100.0.2.22) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.08.09-54.240.48.110 Archived-At: Subject: [netconf] Overview of the various "capabilities" drafts 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, 09 Aug 2021 23:30:32 -0000 Draft-authors in the =E2=80=9CTo=E2=80=9D line, During the 111 session I made the statement that all these drafts are = augmenting the new =E2=80=9Csystem capabilities=E2=80=9D data tree and = wondered to what extent these efforts compliment and/or overlap each = other. Could you please discuss this? Kent (no hat) From nobody Tue Aug 10 00:54: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 84C2D3A2D6C for ; Tue, 10 Aug 2021 00:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 y5HeXcmdkm2P for ; Tue, 10 Aug 2021 00:54:45 -0700 (PDT) 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 75CA23A1D98 for ; Tue, 10 Aug 2021 00:54:45 -0700 (PDT) Received: from fraeml734-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GkQFW406lz6D8sf; Tue, 10 Aug 2021 15:54:07 +0800 (CST) Received: from dggeme768-chm.china.huawei.com (10.3.19.114) by fraeml734-chm.china.huawei.com (10.206.15.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.8; Tue, 10 Aug 2021 09:54:36 +0200 Received: from dggeml753-chm.china.huawei.com (10.1.199.152) by dggeme768-chm.china.huawei.com (10.3.19.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Tue, 10 Aug 2021 15:54:34 +0800 Received: from dggeml753-chm.china.huawei.com ([10.1.199.152]) by dggeml753-chm.china.huawei.com ([10.1.199.152]) with mapi id 15.01.2176.012; Tue, 10 Aug 2021 15:54:34 +0800 From: Qin Wu To: "maqiufang (A)" , Juergen Schoenwaelder CC: "netconf@ietf.org" Thread-Topic: [netmod] [netconf] Question on Subtree Filtering Usage Example Thread-Index: AdeNvD2HOWW/L1cEQA61BdH4OSB3Vw== Date: Tue, 10 Aug 2021 07:54:34 +0000 Message-ID: <5a61cb1234b6435c9ed5aab3bc528d7d@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.123.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] [netmod] Question on Subtree Filtering Usage Example 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, 10 Aug 2021 07:54:52 -0000 V2hhdCBpZiA8bmFtZT5hbmQ8dHlwZT4gbm90IGNvbmZpZ3VyZWQgdW5kZXIgPHVzZXJzPj8NCk15 IHVuZGVyc3RhbmRpbmcgaXMgc3VidHJlZSBmaWx0ZXIgd2lsbCBub3QgY2FyZSBhYm91dCAidXNl cnMiIHBhcmVudCBlbGVtZW50IGlzIHRoZSBjb250YWluZXIgd2l0aCBwcmVzZW5jZSBzdWJzdGF0 ZW1lbnQNClNpbmNlIHN1YnRyZWUgZmlsdGVyIGlzIGFwcGxpY2FibGUgdG8geG1sIGZpbGUgcmF0 aGVyIHRoYW4gWUFORyBmaWxlLg0KDQpJIGFtIG5vdCBzdXJlIGhvdyB0aGUgc2VydmVyIHBhcnNl cyBzdWJ0cmVlIGZpbHRlcj8gSXQgbG9va3Mgd2VpcmQgdG8gbG9vayB1cCBZQU5HIGZpbHRlciBm b3Igc2NoZW1lIGZpcnN0IGFuZCB0aGVuIGFwcGx5IHN1YnRyZWUgZmlsdGVyIHRvIHRoZSB4bWwg ZmlsZSBjb3JyZXNwb25kaW5nIHRvIHlhbmcgZmlsZS4NClRoZXJlZm9yZSBpZiBib3RoIDxuYW1l PmFuZDx0eXBlPiBhcmUgbm90IGNvbmZpZ3VyZWQsIHRoZSByZXNwb25zZSBJIGV4cGVjdCBpcyBy ZXR1cm4gbnVsbCBpcnJlc3BlY3RpdmUgb2YgcHJlc2VuY2UgY29udGFpbmVyICJ1c2VycyIuDQoN Ci1RaW4NCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogbmV0bW9kIFttYWlsdG86 bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBtYXFpdWZhbmcgKEEpDQrlj5HpgIHml7bp l7Q6IDIwMjHlubQ45pyINuaXpSAxOToxMg0K5pS25Lu25Lq6OiBKdWVyZ2VuIFNjaG9lbndhZWxk ZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4NCuaKhOmAgTogbmV0Y29u ZkBpZXRmLm9yZzsgbmV0bW9kQGlldGYub3JnDQrkuLvpopg6IFJlOiBbbmV0bW9kXSBbbmV0Y29u Zl0gUXVlc3Rpb24gb24gU3VidHJlZSBGaWx0ZXJpbmcgVXNhZ2UgRXhhbXBsZQ0KDQpIaSwgDQpU aGFua3MgZm9yIHlvdXIgcmVwbHkuIENyb3NzIHBvc3RpbmcgdG8gTkVUQ09ORiBsaXN0Lg0KDQpC ZXN0IFJlZ2FyZHMsDQpRaXVmYW5nIE1hDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBKw7xyZ2VuIFNjaMO2bnfDpGxkZXIgW21haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2Jz LXVuaXZlcnNpdHkuZGVdIA0KU2VudDogRnJpZGF5LCBBdWd1c3QgNiwgMjAyMSA2OjM1IFBNDQpU bzogbWFxaXVmYW5nIChBKSA8bWFxaXVmYW5nMUBodWF3ZWkuY29tPg0KQ2M6IG5ldG1vZEBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtuZXRtb2RdIFF1ZXN0aW9uIG9uIFN1YnRyZWUgRmlsdGVyaW5n IFVzYWdlIEV4YW1wbGUNCg0KSGksDQoNCnlvdSBtYXkgd2FudCB0byBzZW5kIHlvdXIgcXVlc3Rp b24gdG8gdGhlIG5ldGNvbmYgbGlzdCBzaW5jZSB0aGlzIGlzIGEgcHJvdG9jb2wgcXVlc3Rpb24g YW5kIG5vdCBhIFlBTkcgcXVlc3Rpb24uIChDb25jZXJuaW5nIHlvdXIgcXVlc3Rpb24sIHBsZWFz ZSByZWFkIHNlY3Rpb24gNi4yLjQgIlNlbGVjdGlvbiBOb2RlcyIuIFRoZXJlIGlzIG5vIHJlc3Ry aWN0aW9uIHRvIG9ubHkgb25lIHNlbGVjdGlvbiBub2RlIGFzIGZhciBhcyBJIGNhbiB0ZWxsLikN Cg0KL2pzDQoNCk9uIEZyaSwgQXVnIDA2LCAyMDIxIGF0IDA5OjI5OjUwQU0gKzAwMDAsIG1hcWl1 ZmFuZyAoQSkgd3JvdGU6DQo+IEhpLCBhbGw6DQo+IA0KPiBJbiBSRkM2MjQxIHNlY3Rpb24gNi40 KGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjNjI0MSNzZWN0aW9uLTYu NCksIHNldmVyYWwgc2luZ2xlIHN1YnRyZWUgZmlsdGVyaW5nIGV4YW1wbGVzIGFyZSBnaXZlbi4N Cj4gSSBhbSB3b25kZXJpbmcgd2hldGhlciB3ZSBjYW4gc2VsZWN0IG11bHRpcGxlIGVsZW1lbnRz IHdpdGhpbiB0aGUgPHVzZXJzPiBTdWJ0cmVlLg0KPiBOb3RlIHRoYXQgd2UgYWxzbyBhc3N1bWUg InVzZXJzIiBwYXJlbnQgZWxlbWVudCBpcyB0aGUgY29udGFpbmVyIHdpdGggcHJlc2VuY2Ugc3Vi c3RhdGVtZW50Lg0KPiBIZXJlIGlzIHRoZSBSUEMgcmVxdWVzdCBtZXNzYWdlIHdpdGggc3BlY2lm aWMgc3VidHJlZSBmaWx0ZXJpbmcgOg0KPiAgICAgIDxycGMgbWVzc2FnZS1pZD0iMTAxIg0KPiAg ICAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCI+ DQo+ICAgICAgICA8Z2V0LWNvbmZpZz4NCj4gICAgICAgICAgPHNvdXJjZT4NCj4gICAgICAgICAg ICA8cnVubmluZy8+DQo+ICAgICAgICAgIDwvc291cmNlPg0KPiAgICAgICAgICA8ZmlsdGVyIHR5 cGU9InN1YnRyZWUiPg0KPiAgICAgICAgICAgIDx0b3AgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNv bS9zY2hlbWEvMS4yL2NvbmZpZyI+DQo+ICAgICAgICAgICAgICA8dXNlcnM+DQo+ICAgICAgICAg ICAgICAgIDx1c2VyPg0KPiAgICAgICAgICAgICAgICAgICAgIDxuYW1lLz4NCj4gICAgICAgICAg ICAgICAgICAgICAgPHR5cGUvPg0KPiAgICAgICAgICAgICAgICA8L3VzZXI+DQo+ICAgICAgICAg ICAgICA8L3VzZXJzPg0KPiAgICAgICAgICAgIDwvdG9wPg0KPiAgICAgICAgICA8L2ZpbHRlcj4N Cj4gICAgICAgIDwvZ2V0LWNvbmZpZz4NCj4gICAgICA8L3JwYz4NCj4gDQo+IEkgYW0gd29uZGVy aW5nIHdoYXQgUlBDIHJlc3BvbnNlIHdpbGwgbG9vayBsaWtlPyBJdCB3aWxsIHJlc3BvbmQgd2l0 aCBudWxsIG9yIGl0IHdpbGwgcmVzcG9uZCBhcyBmb2xsb3dzOg0KPiAgICAgIDxycGMtcmVwbHkg bWVzc2FnZS1pZD0iMTAxIg0KPiAgICAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6 bnM6bmV0Y29uZjpiYXNlOjEuMCI+DQo+ICAgICAgICA8ZGF0YT4NCj4gICAgICAgICAgPHRvcCB4 bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS8xLjIvY29uZmlnIj4NCj4gICAgICAgICAg ICA8dXNlcnM+DQo+ICAgICAgICAgICAgICA8dXNlcj4NCj4gICAgICAgICAgICAgICAgPG5hbWU+ cm9vdDwvbmFtZT4NCj4gICAgICAgICAgICAgICAgPHR5cGU+c3VwZXJ1c2VyPC90eXBlPg0KPiAg ICAgICAgICAgICAgPC91c2VyPg0KPiAgICAgICAgICAgICAgPHVzZXI+DQo+ICAgICAgICAgICAg ICAgIDxuYW1lPmZyZWQ8L25hbWU+DQo+ICAgICAgICAgICAgICAgIDx0eXBlPmFkbWluPC90eXBl Pg0KPiAgICAgICAgICAgICAgPC91c2VyPg0KPiAgICAgICAgICAgPC91c2Vycz4NCj4gICAgICAg IDwvdG9wPg0KPiAgICA8L2RhdGE+DQo+IDwvcnBjLXJlcGx5Pg0KPiANCj4gDQo+IA0KPiBCZXN0 IFJlZ2FyZHMsDQo+IFFpdWZhbmcgTWENCg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQoN Ci0tIA0KSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBC cmVtZW4gZ0dtYkgNClBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcg MSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCkZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAg ICAgPGh0dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRt b2RAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9k DQo= From nobody Tue Aug 10 01:56:51 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 2AE533A092F for ; Tue, 10 Aug 2021 01:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-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=jacobsuniversity.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 bKkpxsWA-9Tb for ; Tue, 10 Aug 2021 01:56:42 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70045.outbound.protection.outlook.com [40.107.7.45]) (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 49B473A092B for ; Tue, 10 Aug 2021 01:56:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=im5asKXdIgR377XwUj265AB9+lxyos5zu8cLYLiIlLlF1j5jPvzshzL6hd5d59ymZ8+/rqYf6mY4GYPQvzDYm3aEKGzMINDxg3sjbtHGl9gHH8UIWnsIbTDXpsa9x0hy2SJ3pNBXLUimBQAf5ekhhT7a9SkaQpyrVFAEDUPAcec8IsuM6/QEruOS/VLDILpokM3CiAX2wOl5epCRvrA+9OrJ+ngzHvr7HNOXHhl3dYW/sZpN0iwEGSzuP1dmsnEMz8vO0cqSRv0EkR/80qYjAPIYyG7Pm55YTAdZXUOWKexNSvi0q6HehVFWvTpHJ4g8WEenrIVCjZuh0uq9MCWcYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Xi14DegroO86w9lqfg5pVxk9jAX/HpJ2PV7rDzQqVr0=; b=KJcpWId1r42vMVTyR4KFLwiyNr/33GStxJGdwtCjxUhiXky4A4Hdib++iUW8UKj69WerN2NHIcnn0BXz+b4i650epVbfQQWUHpuB+CH5h9pnND202+3j3EBm2ZReJroQBU4dHUYOOK6E3F4UWYNScGxfUTpcAc92gnBaLvwG05KUkEBHglD1XdqBCVapVgBQMwg4g4uL3sSthC4nJwvAQNXTpIiDQaZYv9FHuVWXOgrVKS6S+u2iD0afS3txvmchLoj/xvQ2eyYtHCtt/HT1m2GVkXr1IabAUcb+JCc42xy5bi+DgfOU6i2xBzb/9sXb3TxU6Ad2kpnMXrgr+aOKnw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Xi14DegroO86w9lqfg5pVxk9jAX/HpJ2PV7rDzQqVr0=; b=Y6MDLQg0ra8mN0l9S0b/e+IEG177MpssWceM1jh0PZaKEE4wCozQe2C/b1naiXPAW+38s7jfyYnOpmf2Wgnc7h3ndvlzEerdKgxMcDbySSEgCX3dC37pcAjFDcJsy0Ejhhfdm4Nk3Pgx5Ztn5Z3kE6BFvwx/EC00MtAEbeQHYrs= Authentication-Results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM0P190MB0707.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:196::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.13; Tue, 10 Aug 2021 08:56:38 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::58c1:599a:1d3d:cdeb]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::58c1:599a:1d3d:cdeb%9]) with mapi id 15.20.4394.023; Tue, 10 Aug 2021 08:56:38 +0000 Date: Tue, 10 Aug 2021 10:56:37 +0200 From: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= To: Qin Wu Cc: "maqiufang (A)" , "netconf@ietf.org" Message-ID: <20210810085637.3wuj2gzwbv2qlrh4@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Qin Wu , "maqiufang (A)" , "netconf@ietf.org" References: <5a61cb1234b6435c9ed5aab3bc528d7d@huawei.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5a61cb1234b6435c9ed5aab3bc528d7d@huawei.com> X-ClientProxiedBy: PR1P264CA0031.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:19f::18) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR1P264CA0031.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:19f::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.17 via Frontend Transport; Tue, 10 Aug 2021 08:56:38 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 82274f52-1ae1-495a-fee7-08d95bdcc3d9 X-MS-TrafficTypeDiagnostic: AM0P190MB0707: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: tmJ+yhLXkwPPae/rDDZ64PfrrDySnP0A7ZhGNS5cxm7n4uAn6nOVSAnC++3jLBNWZcL4RsI/OsERVBD3P5Phpt9uzJipt3/c9fxqo6SAlDeoKV7NUZDe6+kHTREiEA+Fyuc+5mhMaKRNR0RBHHr2WnJhKGHbnUwsZn+ufxeLLDfyI3k4uBZrSPnzept0R72xUaKnXT02qIXDGCup9Boqmen0xXgyE2Qek2fjhu0r3OgbhNxh/cbincUYnFUAlCkpz0r5kPLGjerHIMwFhz4RXCXnuSav3cx7/PLybLmwinL9hM2rp/u0zw73VFA3PIdcoWJsOtXsavUC54oFtIGxIjle9RpN7M8v6hEp+mXAFPoAYTWdB9y4/Gr8/xvo8bgF70NRo+ZiCuQqK5AX7lKoJDrwyKnr+ZwvDIISzxsmXc+x20HnhUj7yffHk7LbEz9VZ6pczf31C8dD2hjD5Bkv6LLZDU1ToiBlIPMXl3wyjMl1P0k9x5uCclI3hoJ7xWh28YOBUG47yVOuu+emOKC2V8IRoExb9J0z6naNQAuuZ2FandgyrYgWXQbC33MnXqwCOMvixUnxDRi+MNjKEibfUzO8nyA4Hw+JW7qhXXQThmm6nq9BE0Z/y+R8fEjYHYIXpcFVTw92LBuSgl2cZzgPJRydwuFXFcF8DcjV5zZa8dfqqIHFPQwwjtoGiE3GOeZsovi9Ma07bfHJDU+j3RniaqNhR1U2vU5v5bnCo/30BTvVdT/cJWpkcqb4IRXfEZQiX8eBCU01U8DWpx9xc+MD66UxGa1GrUiNq7GhJPtX7BZK6aM2iT5oEyougNvplX/H7CF69fYPrJ56rEx2FGgQMQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(136003)(366004)(396003)(376002)(346002)(39850400004)(86362001)(85182001)(83380400001)(956004)(66574015)(966005)(6486002)(478600001)(54906003)(4326008)(3450700001)(786003)(316002)(6916009)(8676002)(8936002)(6496006)(26005)(186003)(1076003)(38100700002)(66556008)(66476007)(66946007)(38350700002)(5660300002)(53546011)(85202003)(52116002)(2906002)(562404015); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OUhteFo4ZnppVnFxYXJJMFY2T2tYYnAwNnpOVXQ0bCtiUXAvVEJqNjB1UkMw?= =?utf-8?B?bGZmSXQxOEhnY0RsRGlueG1XNitiV0JGYWd6cE5XNWluTFB3aGZoTXBaZGRT?= =?utf-8?B?QWxPLzZZUWViV00wM2crS2R1SDZZdnpFVk5hLzkxR0RWRzBVYmllRUhZdlYy?= =?utf-8?B?ODdBL1M0aDNZNENyeEJOWUlaaWMzd21nRFVPd1NSbHNoeE95T0ZDbzB3d0hL?= =?utf-8?B?SUpleTB2NytNalNBRndOcVJKZXVzeWdQVFE5V3llaTlkUGsrWVdmQUI3OUxD?= =?utf-8?B?dEttRzByNG1BTUc1S2RLTHp2eFJHN09tVTAxZkNUdkNudFVVZ0x4Q1BQdlMz?= =?utf-8?B?NDFrY1l1ZytvZ2dlRlhtRmZ3NUhVYzBvbmFxZ1dQaFUxTUpJVy9LUXh4QURR?= =?utf-8?B?anZKUjhXRmpNTi9aWkpWVVZVNEgvWHZEMER5d3JBRlA2cFlrL054MTNCK0VH?= =?utf-8?B?enBoQlVJTVZzaE1OUmQ5MzBWSm1BVjc4Q09ZcmIxdVlWMFRhWmlMbTlGZkZR?= =?utf-8?B?b2k0TURvRWU3TFdMc2NyZDBwTEVmNXVuMUNKdlQvTUdzQ3hJV09PVi80bERm?= =?utf-8?B?WWpvcCt1VFFjNDJVeTQvTkNEdXhGbkRjejZ3Qy9oOWRNdUc5b1ZBR1B2Vm1x?= =?utf-8?B?M2tYeTh2MzJ4SmF5Z3dYR2kvZ3JiVURDNkRMWEVuQ1RycW9ncDc2WWFEV1Vk?= =?utf-8?B?R3p2UzRPNzRDeStmUTZPZFM4VjdJdkJxZG1xREE5NFhMUDllclg1RXBrZjJj?= =?utf-8?B?K0g5R0RZT1FWMkxJQ0ZmV0ozUjRQUXUwalRCb1FjMnl1eHdaQWhFUUNsMTRQ?= =?utf-8?B?dUhoeEJxTVp2OGYyaC9iS29QblR6NU1TK0NWcVgyY0RScVN2ZjFKRzFKM1Qw?= =?utf-8?B?Q1pFK1RjUXdsTnBlVUtyUEhGWUdMaHZwTkFJYlNDTUFkZHNzMHdRb0VtdU1v?= =?utf-8?B?WFR4VGEyUXRBN3I4bk12ckFJYUFFL3N0U0FvYm4ybHdmcEVoTU1lTER3eUJq?= =?utf-8?B?RGExa0pJYW5rbVErNXZBY0FJdGRXcTJPWGNYd0dOY09aUFN2TWw2dmdrRTBO?= =?utf-8?B?NlBaQ1phelZrNnNQajNrNFkxc1NQL3RRUmVHQXJGdUUvVjg0OUVsbkYrYVZP?= =?utf-8?B?NGpCSHBFVUJ1NzhsVmRxdG43WmNhYitmUCtrVTEvUkFJK3ZaZ3pVL1Y5K1Ux?= =?utf-8?B?SlpORnluVUJ0U3RXbFd2U01MTWZjSUtaaEpwWDl1Y2VWRDV0c3UvTEt0elBQ?= =?utf-8?B?V0dtQlQvQjBqVDZXaUtpZ1RSR3pmQXpzcGlNVG5oWVdKUTc3aWUxN0VIR3V5?= =?utf-8?B?QUh1WjduU0pmODR3RDZpbU9sOVN4Sm81S0p1WGNYL1A1T0NrRUpBTnY3NWZV?= =?utf-8?B?TFc0NkhyUzQremVFUWZ3VENkeFpqMGtodmR3QkVFZHF3eTJNQnFxakR3RGFN?= =?utf-8?B?RlN0VDE0aWxGMU5FcWIwR0ptdGVmcDNvRUJVUEk1eUIvQ2hmWU5pekYxVTlS?= =?utf-8?B?aWRPcTkxMTdGZWlSMXlzTjN1N1ZkQ3N4amh4TGJpNE8zUlJ0V2UxYVQvcEVV?= =?utf-8?B?Um8yenJNdFVzOTVjN1lRZk96RFNPbVozWlBMdzVCbXBTaVd6alc1eDV6QTF6?= =?utf-8?B?clFEVUxtYmlpdmdaS0dheEJ1elIyN29ZcGgyVnBRa2dNTzU3dzJocHRJVTVq?= =?utf-8?B?VnFiUk55SDA0WHlmNHREMUkxUmcrWE5YaWw1SE0wQmNGdUtTbU12ZzFTeFFD?= =?utf-8?Q?ZqTuejJevKjzsIrN4TbyoQ0M5jycGi+JekLs6Bv?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 82274f52-1ae1-495a-fee7-08d95bdcc3d9 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Aug 2021 08:56:38.7806 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Sb/Wky21tFu9ir7syK2fDt5U8kvgdBVM2ecAY+BRo7WNG4V6+jj0EHpu0jZRYIWPkTO0FajAvp409+vyWZ8R2Tz4XreI0L2bG1VE/0PUvEQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0707 Archived-At: Subject: Re: [netconf] [netmod] Question on Subtree Filtering Usage Example 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, 10 Aug 2021 08:56:49 -0000 Perhaps you can write down an instance tree to help us understand your question. I assume your question is whether a server has to prune empty fragments of the tree. I do not think that this is suggested by section 6.2.5., i.e., you might get if nothing is matching. /js On Tue, Aug 10, 2021 at 07:54:34AM +0000, Qin Wu wrote: > What if and not configured under ? > My understanding is subtree filter will not care about "users" parent element is the container with presence substatement > Since subtree filter is applicable to xml file rather than YANG file. > > I am not sure how the server parses subtree filter? It looks weird to look up YANG filter for scheme first and then apply subtree filter to the xml file corresponding to yang file. > Therefore if both and are not configured, the response I expect is return null irrespective of presence container "users". > > -Qin > -----邮件原件----- > 发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 maqiufang (A) > 发送时间: 2021年8月6日 19:12 > 收件人: Juergen Schoenwaelder > 抄送: netconf@ietf.org; netmod@ietf.org > 主题: Re: [netmod] [netconf] Question on Subtree Filtering Usage Example > > Hi, > Thanks for your reply. Cross posting to NETCONF list. > > Best Regards, > Qiufang Ma > > -----Original Message----- > From: Jürgen Schönwälder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, August 6, 2021 6:35 PM > To: maqiufang (A) > Cc: netmod@ietf.org > Subject: Re: [netmod] Question on Subtree Filtering Usage Example > > Hi, > > you may want to send your question to the netconf list since this is a protocol question and not a YANG question. (Concerning your question, please read section 6.2.4 "Selection Nodes". There is no restriction to only one selection node as far as I can tell.) > > /js > > On Fri, Aug 06, 2021 at 09:29:50AM +0000, maqiufang (A) wrote: > > Hi, all: > > > > In RFC6241 section 6.4(https://datatracker.ietf.org/doc/html/rfc6241#section-6.4), several single subtree filtering examples are given. > > I am wondering whether we can select multiple elements within the Subtree. > > Note that we also assume "users" parent element is the container with presence substatement. > > Here is the RPC request message with specific subtree filtering : > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am wondering what RPC response will look like? It will respond with null or it will respond as follows: > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > > root > > superuser > > > > > > fred > > admin > > > > > > > > > > > > > > > > > > Best Regards, > > Qiufang Ma > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Aug 10 02:13:10 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 641B33A09F3 for ; Tue, 10 Aug 2021 02:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 J6ET1OGEIydD for ; Tue, 10 Aug 2021 02:13:02 -0700 (PDT) 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 155663A09EF for ; Tue, 10 Aug 2021 02:13:02 -0700 (PDT) Received: from fraeml735-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GkRzs2Xxhz6C9Hc; Tue, 10 Aug 2021 17:12:25 +0800 (CST) Received: from dggeml701-chm.china.huawei.com (10.3.17.134) by fraeml735-chm.china.huawei.com (10.206.15.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.8; Tue, 10 Aug 2021 11:12:57 +0200 Received: from dggpemm500003.china.huawei.com (7.185.36.56) by dggeml701-chm.china.huawei.com (10.3.17.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Tue, 10 Aug 2021 17:12:56 +0800 Received: from dggpemm500003.china.huawei.com ([7.185.36.56]) by dggpemm500003.china.huawei.com ([7.185.36.56]) with mapi id 15.01.2176.012; Tue, 10 Aug 2021 17:12:56 +0800 From: "Fengchong (frank)" To: Juergen Schoenwaelder , Qin Wu CC: "netconf@ietf.org" Thread-Topic: [netconf] [netmod] Question on Subtree Filtering Usage Example Thread-Index: AdeNvD2HOWW/L1cEQA61BdH4OSB3V///jKmA//92/oA= Date: Tue, 10 Aug 2021 09:12:55 +0000 Message-ID: References: <5a61cb1234b6435c9ed5aab3bc528d7d@huawei.com> <20210810085637.3wuj2gzwbv2qlrh4@anna.jacobs.jacobs-university.de> In-Reply-To: <20210810085637.3wuj2gzwbv2qlrh4@anna.jacobs.jacobs-university.de> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.113.80] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netconf] =?utf-8?b?562U5aSNOiAgW25ldG1vZF0gUXVlc3Rpb24gb24gU3Vi?= =?utf-8?q?tree_Filtering_Usage_Example?= 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, 10 Aug 2021 09:13:09 -0000 SSB0aGluayBzb21lIGV4cHJlc3Npb24gbWF5IGJlIGFkZGVkIHRvIHN1YnRyZWUgbWVjaGFuaXNt IHRvIGV4cHJlc3MgdGhlIHByZXNlbmNlIGNvbnRhaW5lciBpcyBhbHNvIGEgc2VsZWN0aW9uLWVs ZW1lbnQuIEJlY2F1c2UgcHJlc2VuY2UgY29udGFpbmVyIGlzIG5vdCBvbmx5IHNpbXBseSBwYXRo IGJ1dCBhbHNvIGhhcyBpdCdzIG1lYW5pbmcuDQoNCkZvciBleGFtcGxlLCBhbiBhdHRyaWJ1dGUg Y2FuIGJlIGluc2VydGVkIHRvIHByZXNlbmNlIGNvbnRhaW5lciB0byBpbmRpY2F0ZSB0aGlzIGlz IGFsc28gYSBzZWxlY3Rpb24gZWxlbWVudC4NCiAgICAgIDxycGMgbWVzc2FnZS1pZD0iMTAxIg0K ICAgICAgICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4w Ij4NCiAgICAgICA8Z2V0LWNvbmZpZz4NCiAgICAgICAgIDxzb3VyY2U+DQogICAgICAgICAgIDxy dW5uaW5nLz4NCiAgICAgICAgIDwvc291cmNlPg0KICAgICAgICAgPGZpbHRlciB0eXBlPSJzdWJ0 cmVlIj4NCiAgICAgICAgICAgPHRvcCB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS8x LjIvY29uZmlnIj4NCiAgICAgICAgICAgICA8dXNlcnMgc2VsZWN0YWJsZT10cnVlPg0KICAgICAg ICAgICAgICAgPHVzZXI+DQogICAgICAgICAgICAgICAgICAgICA8bmFtZS8+DQogICAgICAgICAg ICAgICAgICAgICAgPHR5cGUvPg0KICAgICAgICAgICAgICAgIDwvdXNlcj4NCiAgICAgICAgICAg ICA8L3VzZXJzPg0KICAgICAgICAgICAgPC90b3A+DQogICAgICAgICAgPC9maWx0ZXI+DQogICAg ICAgIDwvZ2V0LWNvbmZpZz4NCiAgICAgIDwvcnBjPg0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0t DQrlj5Hku7bkuro6IG5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIOS7 o+ihqCBKw7xyZ2VuIFNjaD9udz9sZGVyDQrlj5HpgIHml7bpl7Q6IDIwMjHlubQ45pyIMTDml6Ug MTY6NTcNCuaUtuS7tuS6ujogUWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb20+DQrmioTpgIE6IG5l dGNvbmZAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtuZXRjb25mXSBbbmV0bW9kXSBRdWVzdGlvbiBv biBTdWJ0cmVlIEZpbHRlcmluZyBVc2FnZSBFeGFtcGxlDQoNClBlcmhhcHMgeW91IGNhbiB3cml0 ZSBkb3duIGFuIGluc3RhbmNlIHRyZWUgdG8gaGVscCB1cyB1bmRlcnN0YW5kIHlvdXIgcXVlc3Rp b24uIEkgYXNzdW1lIHlvdXIgcXVlc3Rpb24gaXMgd2hldGhlciBhIHNlcnZlciBoYXMgdG8gcHJ1 bmUgZW1wdHkgZnJhZ21lbnRzIG9mIHRoZSB0cmVlLiBJIGRvIG5vdCB0aGluayB0aGF0IHRoaXMg aXMgc3VnZ2VzdGVkIGJ5IHNlY3Rpb24gNi4yLjUuLCBpLmUuLCB5b3UgbWlnaHQgZ2V0IDx1c2Vy cz48dXNlci8+PC91c2Vycz4gaWYgbm90aGluZyBpcyBtYXRjaGluZy4NCg0KL2pzDQoNCk9uIFR1 ZSwgQXVnIDEwLCAyMDIxIGF0IDA3OjU0OjM0QU0gKzAwMDAsIFFpbiBXdSB3cm90ZToNCj4gV2hh dCBpZiA8bmFtZT5hbmQ8dHlwZT4gbm90IGNvbmZpZ3VyZWQgdW5kZXIgPHVzZXJzPj8NCj4gTXkg dW5kZXJzdGFuZGluZyBpcyBzdWJ0cmVlIGZpbHRlciB3aWxsIG5vdCBjYXJlIGFib3V0ICJ1c2Vy cyIgcGFyZW50IA0KPiBlbGVtZW50IGlzIHRoZSBjb250YWluZXIgd2l0aCBwcmVzZW5jZSBzdWJz dGF0ZW1lbnQgU2luY2Ugc3VidHJlZSBmaWx0ZXIgaXMgYXBwbGljYWJsZSB0byB4bWwgZmlsZSBy YXRoZXIgdGhhbiBZQU5HIGZpbGUuDQo+IA0KPiBJIGFtIG5vdCBzdXJlIGhvdyB0aGUgc2VydmVy IHBhcnNlcyBzdWJ0cmVlIGZpbHRlcj8gSXQgbG9va3Mgd2VpcmQgdG8gbG9vayB1cCBZQU5HIGZp bHRlciBmb3Igc2NoZW1lIGZpcnN0IGFuZCB0aGVuIGFwcGx5IHN1YnRyZWUgZmlsdGVyIHRvIHRo ZSB4bWwgZmlsZSBjb3JyZXNwb25kaW5nIHRvIHlhbmcgZmlsZS4NCj4gVGhlcmVmb3JlIGlmIGJv dGggPG5hbWU+YW5kPHR5cGU+IGFyZSBub3QgY29uZmlndXJlZCwgdGhlIHJlc3BvbnNlIEkgZXhw ZWN0IGlzIHJldHVybiBudWxsIGlycmVzcGVjdGl2ZSBvZiBwcmVzZW5jZSBjb250YWluZXIgInVz ZXJzIi4NCj4gDQo+IC1RaW4NCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6 IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSDku6PooaggbWFxaXVmYW5n IChBKQ0KPiDlj5HpgIHml7bpl7Q6IDIwMjHlubQ45pyINuaXpSAxOToxMg0KPiDmlLbku7bkuro6 IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5 LmRlPg0KPiDmioTpgIE6IG5ldGNvbmZAaWV0Zi5vcmc7IG5ldG1vZEBpZXRmLm9yZw0KPiDkuLvp opg6IFJlOiBbbmV0bW9kXSBbbmV0Y29uZl0gUXVlc3Rpb24gb24gU3VidHJlZSBGaWx0ZXJpbmcg VXNhZ2UgRXhhbXBsZQ0KPiANCj4gSGksDQo+IFRoYW5rcyBmb3IgeW91ciByZXBseS4gQ3Jvc3Mg cG9zdGluZyB0byBORVRDT05GIGxpc3QuDQo+IA0KPiBCZXN0IFJlZ2FyZHMsDQo+IFFpdWZhbmcg TWENCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IErDvHJnZW4gU2No w7Zud8OkbGRlciBbbWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZV0N Cj4gU2VudDogRnJpZGF5LCBBdWd1c3QgNiwgMjAyMSA2OjM1IFBNDQo+IFRvOiBtYXFpdWZhbmcg KEEpIDxtYXFpdWZhbmcxQGh1YXdlaS5jb20+DQo+IENjOiBuZXRtb2RAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUmU6IFtuZXRtb2RdIFF1ZXN0aW9uIG9uIFN1YnRyZWUgRmlsdGVyaW5nIFVzYWdlIEV4 YW1wbGUNCj4gDQo+IEhpLA0KPiANCj4geW91IG1heSB3YW50IHRvIHNlbmQgeW91ciBxdWVzdGlv biB0byB0aGUgbmV0Y29uZiBsaXN0IHNpbmNlIHRoaXMgaXMgYSANCj4gcHJvdG9jb2wgcXVlc3Rp b24gYW5kIG5vdCBhIFlBTkcgcXVlc3Rpb24uIChDb25jZXJuaW5nIHlvdXIgcXVlc3Rpb24sIA0K PiBwbGVhc2UgcmVhZCBzZWN0aW9uIDYuMi40ICJTZWxlY3Rpb24gTm9kZXMiLiBUaGVyZSBpcyBu byByZXN0cmljdGlvbiANCj4gdG8gb25seSBvbmUgc2VsZWN0aW9uIG5vZGUgYXMgZmFyIGFzIEkg Y2FuIHRlbGwuKQ0KPiANCj4gL2pzDQo+IA0KPiBPbiBGcmksIEF1ZyAwNiwgMjAyMSBhdCAwOToy OTo1MEFNICswMDAwLCBtYXFpdWZhbmcgKEEpIHdyb3RlOg0KPiA+IEhpLCBhbGw6DQo+ID4gDQo+ ID4gSW4gUkZDNjI0MSBzZWN0aW9uIDYuNChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9odG1sL3JmYzYyNDEjc2VjdGlvbi02LjQpLCBzZXZlcmFsIHNpbmdsZSBzdWJ0cmVlIGZpbHRl cmluZyBleGFtcGxlcyBhcmUgZ2l2ZW4uDQo+ID4gSSBhbSB3b25kZXJpbmcgd2hldGhlciB3ZSBj YW4gc2VsZWN0IG11bHRpcGxlIGVsZW1lbnRzIHdpdGhpbiB0aGUgPHVzZXJzPiBTdWJ0cmVlLg0K PiA+IE5vdGUgdGhhdCB3ZSBhbHNvIGFzc3VtZSAidXNlcnMiIHBhcmVudCBlbGVtZW50IGlzIHRo ZSBjb250YWluZXIgd2l0aCBwcmVzZW5jZSBzdWJzdGF0ZW1lbnQuDQo+ID4gSGVyZSBpcyB0aGUg UlBDIHJlcXVlc3QgbWVzc2FnZSB3aXRoIHNwZWNpZmljIHN1YnRyZWUgZmlsdGVyaW5nIDoNCj4g PiAgICAgIDxycGMgbWVzc2FnZS1pZD0iMTAxIg0KPiA+ICAgICAgICAgICB4bWxucz0idXJuOmll dGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIj4NCj4gPiAgICAgICAgPGdldC1jb25m aWc+DQo+ID4gICAgICAgICAgPHNvdXJjZT4NCj4gPiAgICAgICAgICAgIDxydW5uaW5nLz4NCj4g PiAgICAgICAgICA8L3NvdXJjZT4NCj4gPiAgICAgICAgICA8ZmlsdGVyIHR5cGU9InN1YnRyZWUi Pg0KPiA+ICAgICAgICAgICAgPHRvcCB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS8x LjIvY29uZmlnIj4NCj4gPiAgICAgICAgICAgICAgPHVzZXJzPg0KPiA+ICAgICAgICAgICAgICAg IDx1c2VyPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgPG5hbWUvPg0KPiA+ICAgICAgICAgICAg ICAgICAgICAgIDx0eXBlLz4NCj4gPiAgICAgICAgICAgICAgICA8L3VzZXI+DQo+ID4gICAgICAg ICAgICAgIDwvdXNlcnM+DQo+ID4gICAgICAgICAgICA8L3RvcD4NCj4gPiAgICAgICAgICA8L2Zp bHRlcj4NCj4gPiAgICAgICAgPC9nZXQtY29uZmlnPg0KPiA+ICAgICAgPC9ycGM+DQo+ID4gDQo+ ID4gSSBhbSB3b25kZXJpbmcgd2hhdCBSUEMgcmVzcG9uc2Ugd2lsbCBsb29rIGxpa2U/IEl0IHdp bGwgcmVzcG9uZCB3aXRoIG51bGwgb3IgaXQgd2lsbCByZXNwb25kIGFzIGZvbGxvd3M6DQo+ID4g ICAgICA8cnBjLXJlcGx5IG1lc3NhZ2UtaWQ9IjEwMSINCj4gPiAgICAgICAgICAgeG1sbnM9InVy bjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCI+DQo+ID4gICAgICAgIDxkYXRh Pg0KPiA+ICAgICAgICAgIDx0b3AgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9zY2hlbWEvMS4y L2NvbmZpZyI+DQo+ID4gICAgICAgICAgICA8dXNlcnM+DQo+ID4gICAgICAgICAgICAgIDx1c2Vy Pg0KPiA+ICAgICAgICAgICAgICAgIDxuYW1lPnJvb3Q8L25hbWU+DQo+ID4gICAgICAgICAgICAg ICAgPHR5cGU+c3VwZXJ1c2VyPC90eXBlPg0KPiA+ICAgICAgICAgICAgICA8L3VzZXI+DQo+ID4g ICAgICAgICAgICAgIDx1c2VyPg0KPiA+ICAgICAgICAgICAgICAgIDxuYW1lPmZyZWQ8L25hbWU+ DQo+ID4gICAgICAgICAgICAgICAgPHR5cGU+YWRtaW48L3R5cGU+DQo+ID4gICAgICAgICAgICAg IDwvdXNlcj4NCj4gPiAgICAgICAgICAgPC91c2Vycz4NCj4gPiAgICAgICAgPC90b3A+DQo+ID4g ICAgPC9kYXRhPg0KPiA+IDwvcnBjLXJlcGx5Pg0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IEJlc3Qg UmVnYXJkcywNCj4gPiBRaXVmYW5nIE1hDQo+IA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+IG5l dG1vZEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bmV0bW9kDQo+IA0KPiANCj4gLS0gDQo+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAg SmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3 ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj4gRmF4OiAg ICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHku ZGUvPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQotLSANCkp1ZXJnZW4gU2Nob2Vud2Fl bGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQpQaG9uZTogKzQ5 IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJt YW55DQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMt dW5pdmVyc2l0eS5kZS8+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpuZXRjb25mIG1haWxpbmcgbGlzdA0KbmV0Y29uZkBpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo= From nobody Tue Aug 10 07:17:50 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 1D87F3A0C74 for ; Tue, 10 Aug 2021 07:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FB031I6q_FcA for ; Tue, 10 Aug 2021 07:17:42 -0700 (PDT) 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 59EA33A0C64 for ; Tue, 10 Aug 2021 07:17:42 -0700 (PDT) Received: from fraeml744-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GkZlP3Pgqz6DKY3; Tue, 10 Aug 2021 22:17:05 +0800 (CST) Received: from dggeme719-chm.china.huawei.com (10.1.199.115) by fraeml744-chm.china.huawei.com (10.206.15.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.8; Tue, 10 Aug 2021 16:17:37 +0200 Received: from dggeml753-chm.china.huawei.com (10.1.199.152) by dggeme719-chm.china.huawei.com (10.1.199.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Tue, 10 Aug 2021 22:17:35 +0800 Received: from dggeml753-chm.china.huawei.com ([10.1.199.152]) by dggeml753-chm.china.huawei.com ([10.1.199.152]) with mapi id 15.01.2176.012; Tue, 10 Aug 2021 22:17:34 +0800 From: Qin Wu To: Juergen Schoenwaelder CC: "maqiufang (A)" , "netconf@ietf.org" Thread-Topic: [netmod] [netconf] Question on Subtree Filtering Usage Example Thread-Index: AdeN8XX+OWW/L1cEQA61BdH4OSB3Vw== Date: Tue, 10 Aug 2021 14:17:34 +0000 Message-ID: <3ee03fd6be9f402ca23061f46d111857@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.123.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] [netmod] Question on Subtree Filtering Usage Example 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, 10 Aug 2021 14:17:48 -0000 SGVyZSBpcyB0aGUgaW5zdGFuY2UgZXhhbXBsZToNCiAgIFlBTkcgRXhhbXBsZToNCiAgICBjb250 YWluZXIgdXNlcnMgew0KCSBwcmVzZW5jZSAicHJlc2VuY2UgY29udGFpbmVyIHVzZXJzIjsNCiAg ICAgbGlzdCB1c2VyIHsNCiAgICAgICBrZXkgIm5hbWUiOw0KICAgICAgIGxlYWYgbmFtZSB7DQog ICAgICAgICB0eXBlIHN0cmluZzsNCiAgICAgICB9DQoJICAgbGVhZiB0eXBlIHsNCiAgICAgICAg IHR5cGUgc3RyaW5nOw0KICAgICAgIH0NCgkgICBsZWFmIGZ1bGwtbmFtZSB7DQoJICAgICB0eXBl IHN0cmluZw0KCSAgIH0NCiAgICAgfQ0KCX0NCglOb3RlIHRoYXQgdXNlcnMgaXMgcHJlc2VuY2Ug Y29udGFpbmVyLg0KCUluIHRoZSBSUEMgcmVxdWVzdCwgd2Ugd2FudCB0byByZXF1ZXN0IEFsbCA8 bmFtZT4gRWxlbWVudHMgdG9nZXRoZXIgYWxsIDx0eXBlPiBlbGVtZW50cyB3aXRoaW4gdGhlIDx1 c2Vycz4gU3VidHJlZQ0KICAgIHRoZSBzdWJ0cmVlIGZpbHRlciBleGFtcGxlIGlzIGFzIGZvbGxv d3M6DQogICAgICA8cnBjIG1lc3NhZ2UtaWQ9IjEwMSINCiAgICAgICAgICAgeG1sbnM9InVybjpp ZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCI+DQogICAgICAgPGdldC1jb25maWc+ DQogICAgICAgICA8c291cmNlPg0KICAgICAgICAgICA8cnVubmluZy8+DQogICAgICAgICA8L3Nv dXJjZT4NCiAgICAgICAgIDxmaWx0ZXIgdHlwZT0ic3VidHJlZSI+DQogICAgICAgICAgIDx0b3Ag eG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9zY2hlbWEvMS4yL2NvbmZpZyI+DQogICAgICAgICAg ICAgPHVzZXJzIHNlbGVjdGFibGU9dHJ1ZT4NCiAgICAgICAgICAgICAgIDx1c2VyPg0KICAgICAg ICAgICAgICAgICAgPG5hbWUvPg0KICAgICAgICAgICAgICAgICAgPHR5cGUvPg0KICAgICAgICAg ICAgICAgIDwvdXNlcj4NCiAgICAgICAgICAgICA8L3VzZXJzPg0KICAgICAgICAgICAgPC90b3A+ DQogICAgICAgICAgPC9maWx0ZXI+DQogICAgICAgIDwvZ2V0LWNvbmZpZz4NCiAgICAgIDwvcnBj Pg0KCUl0IHNlZW1zIHRoYXQgc2VjdGlvbiA2LjIuNSBvZiBSRkM2MjQxDQoJICAgbyAgTXVsdGlw bGUgY29udGVudCBtYXRjaCBub2RlcyAoaS5lLiwgc2libGluZyBub2RlcykgYXJlIGxvZ2ljYWxs eQ0KICAgICAgY29tYmluZWQgaW4gYW4gIkFORCIgZXhwcmVzc2lvbi4NCgkgYXBwbGllcyB0byB0 aGlzIGNhc2UuDQogICBJZiBib3RoIDxuYW1lPiBhbmQgPGxlYWY+IGFyZSBub3QgY29uZmlndXJl ZCwgb3IgdGhlcmUgYXJlIG5vIGVudHJ5IHVuZGVyIDx1c2VyPiBsaXN0Lg0KICAgd2Ugd2lsbCBn ZXQgdGhlIGZvbGxvd2luZyByZXNwb25zZSBldmVuIHRob3VnaCBwcmVzZW5jZSBjb250YWluZXIg PHVzZXJzPiBhcmUgZGVmaW5lZCBpbiB0aGUgeWFuZyBmaWxlLg0KICAgICAgICA8cnBjLXJlcGx5 IG1lc3NhZ2UtaWQ9IjEwMSINCiAgICAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6 bnM6bmV0Y29uZjpiYXNlOjEuMCI+DQogICAgICAgIDxkYXRhLz4NCiAgPC9ycGMtcmVwbHk+DQpS YXRoZXIgdGhhbg0KICAgICAgICA8cnBjLXJlcGx5IG1lc3NhZ2UtaWQ9IjEwMSINCiAgICAgICAg ICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCI+DQogICAg ICAgIDxkYXRhPg0KICAgICAgICAgIDx1c2Vycy8+DQogICAgICAgIDwvZGF0YT4NCiAgPC9ycGMt cmVwbHk+DQogSSB0aGluayB0aGUgc2VydmVyIGRvZXNuJ3QgY2hlY2sgd2hldGhlciA8dXNlcnM+ IGlzIHByZXNlbmNlIGNvbnRhaW5lciBvciBub3QsIGJlY29zDQogdGhlIHN1YnRyZWUgZmlsdGVy IGlzIGFwcGxpZWQgdG8geG1sIGZpbGUgYWJvdmUgdW5sZXNzIHRoZXJlIGlzIHNvbWUgd2F5IGlu IHRoZSBzdWJ0cmVlIGZpbHRlciB0byBpbmRpY2F0ZSB0aGF0IHVzZXJzIHNob3VsZCBiZSByZXR1 cm5lZCBpcnJlc3BlY3RpdmUgb2Ygd2hldGhlciBjaGlsZCBub2RlIHVuZGVyIDx1c2Vycz4gaGFz IHZhbHVlLg0KDQotUWluDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IErDvHJn ZW4gU2Now7Zud8OkbGRlciBbbWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0 eS5kZV0gDQrlj5HpgIHml7bpl7Q6IDIwMjHlubQ45pyIMTDml6UgMTY6NTcNCuaUtuS7tuS6ujog UWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb20+DQrmioTpgIE6IG1hcWl1ZmFuZyAoQSkgPG1hcWl1 ZmFuZzFAaHVhd2VpLmNvbT47IG5ldGNvbmZAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtuZXRtb2Rd IFtuZXRjb25mXSBRdWVzdGlvbiBvbiBTdWJ0cmVlIEZpbHRlcmluZyBVc2FnZSBFeGFtcGxlDQoN ClBlcmhhcHMgeW91IGNhbiB3cml0ZSBkb3duIGFuIGluc3RhbmNlIHRyZWUgdG8gaGVscCB1cyB1 bmRlcnN0YW5kIHlvdXIgcXVlc3Rpb24uIEkgYXNzdW1lIHlvdXIgcXVlc3Rpb24gaXMgd2hldGhl ciBhIHNlcnZlciBoYXMgdG8gcHJ1bmUgZW1wdHkgZnJhZ21lbnRzIG9mIHRoZSB0cmVlLiBJIGRv IG5vdCB0aGluayB0aGF0IHRoaXMgaXMgc3VnZ2VzdGVkIGJ5IHNlY3Rpb24gNi4yLjUuLCBpLmUu LCB5b3UgbWlnaHQgZ2V0IDx1c2Vycz48dXNlci8+PC91c2Vycz4gaWYgbm90aGluZyBpcyBtYXRj aGluZy4NCg0KL2pzDQoNCk9uIFR1ZSwgQXVnIDEwLCAyMDIxIGF0IDA3OjU0OjM0QU0gKzAwMDAs IFFpbiBXdSB3cm90ZToNCj4gV2hhdCBpZiA8bmFtZT5hbmQ8dHlwZT4gbm90IGNvbmZpZ3VyZWQg dW5kZXIgPHVzZXJzPj8NCj4gTXkgdW5kZXJzdGFuZGluZyBpcyBzdWJ0cmVlIGZpbHRlciB3aWxs IG5vdCBjYXJlIGFib3V0ICJ1c2VycyIgcGFyZW50IA0KPiBlbGVtZW50IGlzIHRoZSBjb250YWlu ZXIgd2l0aCBwcmVzZW5jZSBzdWJzdGF0ZW1lbnQgU2luY2Ugc3VidHJlZSBmaWx0ZXIgaXMgYXBw bGljYWJsZSB0byB4bWwgZmlsZSByYXRoZXIgdGhhbiBZQU5HIGZpbGUuDQo+IA0KPiBJIGFtIG5v dCBzdXJlIGhvdyB0aGUgc2VydmVyIHBhcnNlcyBzdWJ0cmVlIGZpbHRlcj8gSXQgbG9va3Mgd2Vp cmQgdG8gbG9vayB1cCBZQU5HIGZpbHRlciBmb3Igc2NoZW1lIGZpcnN0IGFuZCB0aGVuIGFwcGx5 IHN1YnRyZWUgZmlsdGVyIHRvIHRoZSB4bWwgZmlsZSBjb3JyZXNwb25kaW5nIHRvIHlhbmcgZmls ZS4NCj4gVGhlcmVmb3JlIGlmIGJvdGggPG5hbWU+YW5kPHR5cGU+IGFyZSBub3QgY29uZmlndXJl ZCwgdGhlIHJlc3BvbnNlIEkgZXhwZWN0IGlzIHJldHVybiBudWxsIGlycmVzcGVjdGl2ZSBvZiBw cmVzZW5jZSBjb250YWluZXIgInVzZXJzIi4NCj4gDQo+IC1RaW4NCj4gLS0tLS3pgq7ku7bljp/k u7YtLS0tLQ0KPiDlj5Hku7bkuro6IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYu b3JnXSDku6PooaggbWFxaXVmYW5nIChBKQ0KPiDlj5HpgIHml7bpl7Q6IDIwMjHlubQ45pyINuaX pSAxOToxMg0KPiDmlLbku7bkuro6IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVs ZGVyQGphY29icy11bml2ZXJzaXR5LmRlPg0KPiDmioTpgIE6IG5ldGNvbmZAaWV0Zi5vcmc7IG5l dG1vZEBpZXRmLm9yZw0KPiDkuLvpopg6IFJlOiBbbmV0bW9kXSBbbmV0Y29uZl0gUXVlc3Rpb24g b24gU3VidHJlZSBGaWx0ZXJpbmcgVXNhZ2UgRXhhbXBsZQ0KPiANCj4gSGksDQo+IFRoYW5rcyBm b3IgeW91ciByZXBseS4gQ3Jvc3MgcG9zdGluZyB0byBORVRDT05GIGxpc3QuDQo+IA0KPiBCZXN0 IFJlZ2FyZHMsDQo+IFFpdWZhbmcgTWENCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IErDvHJnZW4gU2Now7Zud8OkbGRlciBbbWFpbHRvOmouc2Nob2Vud2FlbGRlckBq YWNvYnMtdW5pdmVyc2l0eS5kZV0NCj4gU2VudDogRnJpZGF5LCBBdWd1c3QgNiwgMjAyMSA2OjM1 IFBNDQo+IFRvOiBtYXFpdWZhbmcgKEEpIDxtYXFpdWZhbmcxQGh1YXdlaS5jb20+DQo+IENjOiBu ZXRtb2RAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtuZXRtb2RdIFF1ZXN0aW9uIG9uIFN1YnRy ZWUgRmlsdGVyaW5nIFVzYWdlIEV4YW1wbGUNCj4gDQo+IEhpLA0KPiANCj4geW91IG1heSB3YW50 IHRvIHNlbmQgeW91ciBxdWVzdGlvbiB0byB0aGUgbmV0Y29uZiBsaXN0IHNpbmNlIHRoaXMgaXMg YSANCj4gcHJvdG9jb2wgcXVlc3Rpb24gYW5kIG5vdCBhIFlBTkcgcXVlc3Rpb24uIChDb25jZXJu aW5nIHlvdXIgcXVlc3Rpb24sIA0KPiBwbGVhc2UgcmVhZCBzZWN0aW9uIDYuMi40ICJTZWxlY3Rp b24gTm9kZXMiLiBUaGVyZSBpcyBubyByZXN0cmljdGlvbiANCj4gdG8gb25seSBvbmUgc2VsZWN0 aW9uIG5vZGUgYXMgZmFyIGFzIEkgY2FuIHRlbGwuKQ0KPiANCj4gL2pzDQo+IA0KPiBPbiBGcmks IEF1ZyAwNiwgMjAyMSBhdCAwOToyOTo1MEFNICswMDAwLCBtYXFpdWZhbmcgKEEpIHdyb3RlOg0K PiA+IEhpLCBhbGw6DQo+ID4gDQo+ID4gSW4gUkZDNjI0MSBzZWN0aW9uIDYuNChodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL3JmYzYyNDEjc2VjdGlvbi02LjQpLCBzZXZlcmFs IHNpbmdsZSBzdWJ0cmVlIGZpbHRlcmluZyBleGFtcGxlcyBhcmUgZ2l2ZW4uDQo+ID4gSSBhbSB3 b25kZXJpbmcgd2hldGhlciB3ZSBjYW4gc2VsZWN0IG11bHRpcGxlIGVsZW1lbnRzIHdpdGhpbiB0 aGUgPHVzZXJzPiBTdWJ0cmVlLg0KPiA+IE5vdGUgdGhhdCB3ZSBhbHNvIGFzc3VtZSAidXNlcnMi IHBhcmVudCBlbGVtZW50IGlzIHRoZSBjb250YWluZXIgd2l0aCBwcmVzZW5jZSBzdWJzdGF0ZW1l bnQuDQo+ID4gSGVyZSBpcyB0aGUgUlBDIHJlcXVlc3QgbWVzc2FnZSB3aXRoIHNwZWNpZmljIHN1 YnRyZWUgZmlsdGVyaW5nIDoNCj4gPiAgICAgIDxycGMgbWVzc2FnZS1pZD0iMTAxIg0KPiA+ICAg ICAgICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIj4N Cj4gPiAgICAgICAgPGdldC1jb25maWc+DQo+ID4gICAgICAgICAgPHNvdXJjZT4NCj4gPiAgICAg ICAgICAgIDxydW5uaW5nLz4NCj4gPiAgICAgICAgICA8L3NvdXJjZT4NCj4gPiAgICAgICAgICA8 ZmlsdGVyIHR5cGU9InN1YnRyZWUiPg0KPiA+ICAgICAgICAgICAgPHRvcCB4bWxucz0iaHR0cDov L2V4YW1wbGUuY29tL3NjaGVtYS8xLjIvY29uZmlnIj4NCj4gPiAgICAgICAgICAgICAgPHVzZXJz Pg0KPiA+ICAgICAgICAgICAgICAgIDx1c2VyPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgPG5h bWUvPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgIDx0eXBlLz4NCj4gPiAgICAgICAgICAgICAg ICA8L3VzZXI+DQo+ID4gICAgICAgICAgICAgIDwvdXNlcnM+DQo+ID4gICAgICAgICAgICA8L3Rv cD4NCj4gPiAgICAgICAgICA8L2ZpbHRlcj4NCj4gPiAgICAgICAgPC9nZXQtY29uZmlnPg0KPiA+ ICAgICAgPC9ycGM+DQo+ID4gDQo+ID4gSSBhbSB3b25kZXJpbmcgd2hhdCBSUEMgcmVzcG9uc2Ug d2lsbCBsb29rIGxpa2U/IEl0IHdpbGwgcmVzcG9uZCB3aXRoIG51bGwgb3IgaXQgd2lsbCByZXNw b25kIGFzIGZvbGxvd3M6DQo+ID4gICAgICA8cnBjLXJlcGx5IG1lc3NhZ2UtaWQ9IjEwMSINCj4g PiAgICAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEu MCI+DQo+ID4gICAgICAgIDxkYXRhPg0KPiA+ICAgICAgICAgIDx0b3AgeG1sbnM9Imh0dHA6Ly9l eGFtcGxlLmNvbS9zY2hlbWEvMS4yL2NvbmZpZyI+DQo+ID4gICAgICAgICAgICA8dXNlcnM+DQo+ ID4gICAgICAgICAgICAgIDx1c2VyPg0KPiA+ICAgICAgICAgICAgICAgIDxuYW1lPnJvb3Q8L25h bWU+DQo+ID4gICAgICAgICAgICAgICAgPHR5cGU+c3VwZXJ1c2VyPC90eXBlPg0KPiA+ICAgICAg ICAgICAgICA8L3VzZXI+DQo+ID4gICAgICAgICAgICAgIDx1c2VyPg0KPiA+ICAgICAgICAgICAg ICAgIDxuYW1lPmZyZWQ8L25hbWU+DQo+ID4gICAgICAgICAgICAgICAgPHR5cGU+YWRtaW48L3R5 cGU+DQo+ID4gICAgICAgICAgICAgIDwvdXNlcj4NCj4gPiAgICAgICAgICAgPC91c2Vycz4NCj4g PiAgICAgICAgPC90b3A+DQo+ID4gICAgPC9kYXRhPg0KPiA+IDwvcnBjLXJlcGx5Pg0KPiA+IA0K PiA+IA0KPiA+IA0KPiA+IEJlc3QgUmVnYXJkcywNCj4gPiBRaXVmYW5nIE1hDQo+IA0KPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gbmV0bW9k IG1haWxpbmcgbGlzdA0KPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+IA0KPiANCj4gLS0gDQo+IEp1ZXJnZW4gU2No b2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+IFBo b25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1l biB8IEdlcm1hbnkNCj4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly93 d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQot LSANCkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJl bWVuIGdHbWJIDQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEg fCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAg IDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo= From nobody Tue Aug 10 13:09:08 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 A6D543A1AB8 for ; Tue, 10 Aug 2021 13:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sh9Kelg2m6jg for ; Tue, 10 Aug 2021 13:09:01 -0700 (PDT) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 2AE263A1AB5 for ; Tue, 10 Aug 2021 13:09:01 -0700 (PDT) Received: by mail-pj1-x1036.google.com with SMTP id hv22-20020a17090ae416b0290178c579e424so818964pjb.3 for ; Tue, 10 Aug 2021 13:09:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=O58ts12fd9eCcCnYofpKgjXW4MERkasTmMYwmcVpgO4=; b=T4Mrvrqj7tABkKMik+SoMRTieFeeT+CZpcUaOaTwPQ5D4tkyfektTu+biVOmnBpwHR T6M+078oDoRZkxSIJeHggyi7TJAgc0VA4kUncQtPNRapIaCuaE2QRjKfcQHeVxQRBqUZ 6vktn1WB/eNqTvG3DNWBiJCqkqt/9StapBn8V+kbLTGwpBZfDqnHDndshbBc5toklFlX k4YB4qxuNIS/JHtnz4G2oILVfYZz9WVbZJJSl/NUNkRABETaSh9doNlu1q/G3d7pFc1v fw6SZeXSdRBygsv/2RnauMbpSdv88Sv/x9UvfT+7p2gestQNKbKG0f+3pfUWwWn2HTPG k0dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=O58ts12fd9eCcCnYofpKgjXW4MERkasTmMYwmcVpgO4=; b=iaUMMMAc8nmXxxnzU6L7KN5w9RoZ+Nxoyf9wbOoyNgy4BOcrNYs3oJWXl2dJV8DHmq oOpZFMdgAmPWiYoHLIlSFq3Z0ZZYEp7/OMCoosPaclL8cR/8FO88p/nWQhtxtwhNU5RR 4/dPJMHD0oIjMjCxHxO8vzOaJWvUtsSdqcGiEA47ZsAheUaTGbdjqqDlZO44FowukPyF /tDuPrq/EIn7jXQtQWsVfcYpyG0/3ZZjeC2IpnQccwSCdqiXdJCXa35jvWZPV/xWSzws 9uzEj5utqZhpp8ijKX+3A1ZPp6Q7aWY5cd6HraSBNcA0Z7DCeAxMhUtQGocBpbAC0BUc xK7g== X-Gm-Message-State: AOAM530LYc46vjCsGfmAMfaz0eVs2gUkOuIqQOID3kCai77pa6cRIwl9 bVEj03JZKBGBELZWn7mZe2Tnyw54X6Q= X-Google-Smtp-Source: ABdhPJxRPQJfmYeSFSr7FOZwpTi8q/eTsXglV8BJpYPrjRDqhtnZDPDiBBZ5iYFLRB3YabxlMHTyBg== X-Received: by 2002:a63:4e51:: with SMTP id o17mr1623644pgl.126.1628626139123; Tue, 10 Aug 2021 13:08:59 -0700 (PDT) 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 f5sm23437921pjo.23.2021.08.10.13.08.58 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Aug 2021 13:08:58 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_EB5782FF-3F6F-4321-A0A5-8192B313B968" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Message-Id: <34A2F61E-D1C7-4483-A647-8D941CE6C055@gmail.com> Date: Tue, 10 Aug 2021 13:08:57 -0700 To: Netconf X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [netconf] Draft minutes of IETF 111 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, 10 Aug 2021 20:09:06 -0000 --Apple-Mail=_EB5782FF-3F6F-4321-A0A5-8192B313B968 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The draft minutes of the IETF 111 NETCONF WG meeting have been posted = here = If the minutes do not reflect what was said in the meeting, or is = missing what was said in the meeting, please let us (the chairs) know. Thanks Mahesh & Kent (as co-chairs) --Apple-Mail=_EB5782FF-3F6F-4321-A0A5-8192B313B968 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii The draft minutes of the IETF 111 NETCONF WG meeting have been posted here  If the minutes do not reflect what was said in the meeting, or is missing what was said in the meeting, please let us (the chairs) know.

Thanks

Mahesh & Kent (as co-chairs)




--Apple-Mail=_EB5782FF-3F6F-4321-A0A5-8192B313B968-- From nobody Wed Aug 11 00:13:59 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 8C2DB3A0FDA for ; Wed, 11 Aug 2021 00:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-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=jacobsuniversity.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 WouyzsGaL_vu for ; Wed, 11 Aug 2021 00:13:52 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2060.outbound.protection.outlook.com [40.107.20.60]) (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 A87A53A0FDD for ; Wed, 11 Aug 2021 00:13:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gPFX+ZXwDHF+jTVwQhuTZN9sYFVQSNEqH5j8qQQf6NTKjWVcezZ4zXToXQvOn4zp5AN9VNyVVGZFVLqmh9ekwp/kWhchc4jR+88TVjwA+8RyMwR47fjyc0kuVv5Q5HQoMGYOk6vYfWluB5KmfnC7FHBeCxeGubDYlQXTglnQ8mLvgJ5XdKOzTFEGpKdKPH5v13lzpinvZCG6dJHT9Q+GktjYYCpPZoO9S5PdGKojFpl7CMYjOF9exIcS56CgNp6wfYJSu4Suj4TsuPF6kGdCnkwujgReJ2QHkKCiSUvHMDZcvO632J5lbfuEZ0akUa1UlHmO/Q7cztLsTwA1skIXrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KEoG0kTFh41DApcFLEEUJZB9vAXjCYsdKrePxhmDoMI=; b=OFMqtLjur0vI8JAOMiiHirPDt4YRKb2xzBQYG370rK0OmmqYKjTicWpUCqdXVCvNw+Ac6yBvx+S/VBqb7zSjOdckolFl9+Ww9Pd3FBq+rvIJx9boJQUCijQ8QgJ0SIwfGuL5QFkALWjhjJ/yUf85W/WaTuxX0XBEe/1GYEgsVJNt9G+otqZF6rnTmbZPMWih69AW+HqQhEmifYwNXiW6SK9JMbTvRDAXZdYUjOUlZLjqpdaucuxKqRmGOpjC7AAXVj9tpxXQlraQ1G/2JQ3fpYAa7l+PA6F3yuqcGURi7a9bhjN1xpDK5annBpNv7zOcm04x9muoejxeTM8H2NNevA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KEoG0kTFh41DApcFLEEUJZB9vAXjCYsdKrePxhmDoMI=; b=WJYeCfwjsARkqwGoZuhIxBdAUVqvExQQbo905q6nMp5xpHhRAiOJFYoi/aI+1KkzGdQ01fFYWYNIiWf7l7ehAjwrk91qxfH3VrPzEHWqUq1lQvq0mXiuAuogw2kQHBZ8dR/5Tv4RNBa0KKXdAtb0rHFc8N8/kDi9PdIclX0LfFc= Authentication-Results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM0P190MB0753.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:195::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.17; Wed, 11 Aug 2021 07:13:47 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::58c1:599a:1d3d:cdeb]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::58c1:599a:1d3d:cdeb%9]) with mapi id 15.20.4415.015; Wed, 11 Aug 2021 07:13:47 +0000 Date: Wed, 11 Aug 2021 09:13:45 +0200 From: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= To: "Fengchong (frank)" Cc: Qin Wu , "netconf@ietf.org" Message-ID: <20210811071345.lblhwmubtjq3g5ql@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Fengchong (frank)" , Qin Wu , "netconf@ietf.org" References: <5a61cb1234b6435c9ed5aab3bc528d7d@huawei.com> <20210810085637.3wuj2gzwbv2qlrh4@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: PR2PR09CA0020.eurprd09.prod.outlook.com (2603:10a6:101:16::32) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR2PR09CA0020.eurprd09.prod.outlook.com (2603:10a6:101:16::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.13 via Frontend Transport; Wed, 11 Aug 2021 07:13:46 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4bbdd65e-d80a-44d4-3015-08d95c978fa9 X-MS-TrafficTypeDiagnostic: AM0P190MB0753: X-MS-Exchange-Transport-Forked: True 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: r4K/4kcOooIoQC2w0ZoOJjp3QgFlI/3/sAO9h8JjZeZtubEQv9hUJ5v7Cke0ZL4t8FNQ42IXfEYFzFnnC2dVZ4EoPlJbKPL+VPr9rSzYh5gaxejhzYO2O26+h6QGfpMH17hDDubzwU6wEMWdJmYlOM5P8yt/JSgewhpTDWVwJgAl15/JxH+zFXlwRgoOLUgBO8I/4Shw+5TXZaPu1uRQ38CIm2C4YGDgbKnyuJmYuAvOMeJX38FuqQdsqthINzHzywiriK6g8XxFLAj7qKdft9Dqe54OeMEHYkkRRAuTlFqcPRKGTjcj1pI4OsRkAYNLqx6kRVGeouP5FsTz5bVsOqEHh3u7FvsJWIZyBtZmyYdcwjvBQwuVwWzX6S1weBY55Qxpa7zctryPQSJxSRmPnQFfyoE1AIuTb91iTW0oVuOZw9gevUYtn5xjLmvV5zr/7yn04aiyuhpqm5QsyaTLrLHwIsip0V3MSegx5VqlmJS8vJRME+pQzBAPYlhRbNc8+9iDsLVUOgRmSsyhhPpWGxceX3sbeZFj5FPwwPHP98dSujmCXbCI+5LHv22YIIw79HXQOkcEOj9Opjp7HH7mcNClNvybxAVpuJSG/0F5tTaJBkDu8FCOlZVqi7yj5L9gweIn+1Qk45bHDJkiQW1na64zhE4GRjHNucVD/LCIzg2DrkQOYN1UfvbePzxn18VDHwSIuQ4p4xrVR+4D8ea1Zq7RY6xuE98Qc4p0NHi/2nbYwAg7+Pc1XqHxtqzOoj8vjFCRvKOJLx7WBdeHn7jatxGCGFdtZu48WqZNk5QQIC1u9Z012iQ8AZuCQG/1my8a3KI3pDi5lme2cfUXKfwXLQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39840400004)(346002)(396003)(376002)(136003)(366004)(83380400001)(6916009)(2906002)(6486002)(224303003)(66574015)(4326008)(3450700001)(66476007)(66556008)(66946007)(8936002)(38100700002)(5660300002)(956004)(85202003)(54906003)(85182001)(52116002)(6496006)(53546011)(1076003)(86362001)(786003)(316002)(38350700002)(26005)(478600001)(186003)(966005)(562404015); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WXViMnZPOFJHS1hQVnR0U1dUTCtvMlFmUEk3UER4bjg4SjJNZmxXOWQ3QVBB?= =?utf-8?B?Q3FYZnhsTEp1RjBtZG9BdXlJeGNiUzRwelZhb0tRVG9DYUUzZEtaUVhObFpJ?= =?utf-8?B?QWFxTWM2OUxSTmxKME5YbUtHZG4rUFNOQi9rbW5VcUZuTFo2STBsY1hWclVO?= =?utf-8?B?VUg4ZFFxNWMrOGxhaDhaa3JiSUtXdWtBYUt6dFpqM0xEQTFTK1JlOG81a2Fy?= =?utf-8?B?eHpWU2xWanp5RE9MWWlaUHZBdXI2Z0xJOGFoWEZTTWZaT1dJWUpHYTFYTHEw?= =?utf-8?B?ODMwRW85Nm9JeGRGSDFKdTFnWittbmh1aXZUZVFpeU1KMFpmYmJ1R05sbEVL?= =?utf-8?B?TDhXSVpvQ09mV1FUeXhCYWxzajhOMWEyNDBwemU4eE9kL0Q3L1NoZFJoM2Ux?= =?utf-8?B?bDY3SUV4Vzk0c0E1Q1J1ZWNyRFZRVUV6QjV1ZUQxU3VLUnNENkRhbnNNOUdW?= =?utf-8?B?M0lsVEtmbk1uOW1pbDZxUEk2NEFZWFNNWk5jRkhPemlFM2R6NGtHMG03R2tw?= =?utf-8?B?dk1OU1oyb3JGK0I5ZnhPc2lML3lyemFXSWFaVERuRXZ3Z1FVQ2xuODZhUzIv?= =?utf-8?B?bkFRT1RwaXNlTnZzNnZXQmRzNnBaaWZCSDRyNkZIR09yNEVtZzZaZXhvanVw?= =?utf-8?B?TjFuWFZSUmhVcjE5SndCbDNJS1ZXd0w5MkorTkR3Q05jMzdxU1hkb1dxVVB4?= =?utf-8?B?TVdhM3ZXNVFydzFuOE51d1Ric2NTTEw4Sll1S0FXSXBEOFVMZ0xvdWlxU1ky?= =?utf-8?B?NGorcnlDZ3kzUk1tenB4M3M2TTgvbFZpYTdCYVVteDZiSGMzbjlSZDFUdFdr?= =?utf-8?B?Z2F6c2pCWHphV1UvMWdrZXFzcGdCQ3pIcVE4M2VWa0gxeVUzZWpDdHZVSEUx?= =?utf-8?B?dnROMHU0TmF0ajZVeHV6dlFEYnE2S2ZCWjNqUVRKS2RnWFlWTG0vaWplTjZH?= =?utf-8?B?ajcyTFVtK2s1STd3d1FTakdQeTlUMEJ6SFpNa0JIL1RwMEsyajR3b0hqK0d5?= =?utf-8?B?T2w5SW9jYStmckR4bFd3TzJ6c0E2Z2ppejIzLy9vNUFDbjBNQmRGWnRNeTk2?= =?utf-8?B?SnprMlVOZ2pyZElCL1VVUklNMDlXQnRvaFR0TDFOUkhDM3lkaGNYL2dUS1pS?= =?utf-8?B?emI5RzdieWVCTEc5YnJYbmdwQ0Y2Y1VWQk5NblJWNm9Lc3JzRmtWTWIySklK?= =?utf-8?B?aktlNXRXNE81Y3NQcTFVT2NXZytDZWtKZERSdS9RdUxqYWVlMnZ0NzNqa3NJ?= =?utf-8?B?QjdndTVqRGJBRnBPN2RyUHYwbHYxSjhuQ0htbE5RV2hJOHA2b25rcDNpZnls?= =?utf-8?B?dXpJaFlzSWNDSWVuSUJUcVV0L2V4TVZDV0VLbUR0cTZpTkxJWURtNlJMMzYv?= =?utf-8?B?bXpjZzMzelRtUE1OMFRhTWhwV1o5ZytvZU5WR3hkUXdWbGg5ZVdObUs2RGU2?= =?utf-8?B?Mmo5eDU3eS9RaE1TTGdRelFKRDdsTVZKbjBSSE5vbVc4ZHRpWmVCNDhGUXdF?= =?utf-8?B?TUNiQURySkZ3SlZkcTEra3hsRExicmx6OHBQaXRXOGhXR293MTFkbEZGK1lo?= =?utf-8?B?NndibkM4bklWQVUxcDdGSzZUcEEweHZuMGg4L0dzcHRGYTMySmtTVHNlRlUx?= =?utf-8?B?c0c2N2tRUFBvY01nZW5DVEM2Z3JhYmM1WEFORy9FS09zdm9hUWtxamdlajJE?= =?utf-8?B?N0h1b1U0YmRPSitiUzAzTTMrV0sveGJtNTdPM3psdGJ0SkpYT2xLSmpGVk1x?= =?utf-8?Q?cz1/tJLLP2zB3iGpjhNSxWgtleD+oi91fVNm7Ne?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 4bbdd65e-d80a-44d4-3015-08d95c978fa9 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2021 07:13:47.0857 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 63E6WpYhHBQVRnzzNl02LbAa96Dg5vsZ1GDX7HC44YBgryPuMhZaNPf5yXaCFNPnUUg2bCwaIciuvGj0fVQuO/CqhE7LthsVLGlBxDWtfHg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0753 Archived-At: Subject: Re: [netconf] =?utf-8?b?562U5aSNOiAgW25ldG1vZF0gUXVlc3Rpb24gb24gU3Vi?= =?utf-8?q?tree_Filtering_Usage_Example?= 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, 11 Aug 2021 07:13:58 -0000 While the handling of presence containers may indeed be not well specified (which is not surprising given that NETCONF was designed before we had YANG and presence containers), I am not sure we should go and add data tree annotations for things that are defined in the data model. At the end, it is an implementation issue how a server implements data model awareness. /js On Tue, Aug 10, 2021 at 09:12:55AM +0000, Fengchong (frank) wrote: > I think some expression may be added to subtree mechanism to express the presence container is also a selection-element. Because presence container is not only simply path but also has it's meaning. > > For example, an attribute can be inserted to presence container to indicate this is also a selection element. > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > > > > > > > > > > -----邮件原件----- > 发件人: netconf [mailto:netconf-bounces@ietf.org] 代表 Jürgen Sch?nw?lder > 发送时间: 2021年8月10日 16:57 > 收件人: Qin Wu > 抄送: netconf@ietf.org > 主题: Re: [netconf] [netmod] Question on Subtree Filtering Usage Example > > Perhaps you can write down an instance tree to help us understand your question. I assume your question is whether a server has to prune empty fragments of the tree. I do not think that this is suggested by section 6.2.5., i.e., you might get if nothing is matching. > > /js > > On Tue, Aug 10, 2021 at 07:54:34AM +0000, Qin Wu wrote: > > What if and not configured under ? > > My understanding is subtree filter will not care about "users" parent > > element is the container with presence substatement Since subtree filter is applicable to xml file rather than YANG file. > > > > I am not sure how the server parses subtree filter? It looks weird to look up YANG filter for scheme first and then apply subtree filter to the xml file corresponding to yang file. > > Therefore if both and are not configured, the response I expect is return null irrespective of presence container "users". > > > > -Qin > > -----邮件原件----- > > 发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 maqiufang (A) > > 发送时间: 2021年8月6日 19:12 > > 收件人: Juergen Schoenwaelder > > 抄送: netconf@ietf.org; netmod@ietf.org > > 主题: Re: [netmod] [netconf] Question on Subtree Filtering Usage Example > > > > Hi, > > Thanks for your reply. Cross posting to NETCONF list. > > > > Best Regards, > > Qiufang Ma > > > > -----Original Message----- > > From: Jürgen Schönwälder [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Friday, August 6, 2021 6:35 PM > > To: maqiufang (A) > > Cc: netmod@ietf.org > > Subject: Re: [netmod] Question on Subtree Filtering Usage Example > > > > Hi, > > > > you may want to send your question to the netconf list since this is a > > protocol question and not a YANG question. (Concerning your question, > > please read section 6.2.4 "Selection Nodes". There is no restriction > > to only one selection node as far as I can tell.) > > > > /js > > > > On Fri, Aug 06, 2021 at 09:29:50AM +0000, maqiufang (A) wrote: > > > Hi, all: > > > > > > In RFC6241 section 6.4(https://datatracker.ietf.org/doc/html/rfc6241#section-6.4), several single subtree filtering examples are given. > > > I am wondering whether we can select multiple elements within the Subtree. > > > Note that we also assume "users" parent element is the container with presence substatement. > > > Here is the RPC request message with specific subtree filtering : > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am wondering what RPC response will look like? It will respond with null or it will respond as follows: > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > > > > > > > root > > > superuser > > > > > > > > > fred > > > admin > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards, > > > Qiufang Ma > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Aug 11 00:16: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 A18A93A00C1 for ; Wed, 11 Aug 2021 00:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-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=jacobsuniversity.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 dmSHCvymEuh1 for ; Wed, 11 Aug 2021 00:16:17 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60057.outbound.protection.outlook.com [40.107.6.57]) (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 B45CB3A00C0 for ; Wed, 11 Aug 2021 00:16:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hcNbtThTB01qbn8hFDF9R6ySfdUaqiXwx+h9CMqWATIAVI7H6Zikec42f2hRjh3c+xzmfbhU+41vjsDxl6HT3Q+oiHnVG++Dj9utgNoiy80q1KI+NPykqjkDqGYA8TS1jhvATpACTanGJllJxwDSKWGkN4++iPoow0/Wa39Y989rQFsWyuasIYoDDACrxoCsPKRZN4peob+cNdyA39IbnQGYZFcT1+wrGiSBL9FOoWNXZBNnn6lMrKSrbgx6fkPIU3/971l6hua6CxoWeDFwjvVJgHOlma8oJ7TsZcDXEQ60A55dozUroUKK9hdulctjKmefn9LjfIE2yYUT4AZfug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vBjOLaUeTZ6adpaz9ayXKAZzDolX1YnySNqffwbx2HM=; b=I+qBb8MvPPwRgofyd0UJYlGsLn0tKaK6PIsLUBKAsxdVpyP99//9p57p9tpuy6/yd4YoltVsbDzqbShqpReIPm3xPyL9bk4LUlv/Xti8jtdEOmf+RWBGHKvRhTroBR6uouD+qbqFn7bQzW9k3j4YBsxWf05cKzJiB85lbUP5bhGbZ8nL+rQUiJhxU5O8X0Qb/jWliksY3PJgUVbsjhG+T6ArtiwjqjTBpx3UzeZ47qOrpRiqOHdVSj3qtATAfodw7yzaI5X7JAgIqBqZT5Dxd21WVSUvFdtqfJHJD6QHMRLNgfFRZ1lUm/5mWwF5i7n4Ighnq3ir0zxLgmNbXXSkeQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vBjOLaUeTZ6adpaz9ayXKAZzDolX1YnySNqffwbx2HM=; b=PbCa1mM4GL8FjgRuj+azh+OnPyNXw45Wf+84DgjrGfAG4L8SYtOI6yw8k8oodi+oiGTRad4kT/4/o9zvSBZvPL0nFCwRIS3Q6fQDroag2vjPhUPumghVjnbbAmiRC2z19SH8XU0P1sQnp1g6EmUcCAFMiJdXLb7HSy8vK08QK0o= Authentication-Results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM8P190MB0817.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d0::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.21; Wed, 11 Aug 2021 07:16:13 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::58c1:599a:1d3d:cdeb]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::58c1:599a:1d3d:cdeb%9]) with mapi id 15.20.4415.015; Wed, 11 Aug 2021 07:16:13 +0000 Date: Wed, 11 Aug 2021 09:16:12 +0200 From: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= To: Qin Wu Cc: "maqiufang (A)" , "netconf@ietf.org" Message-ID: <20210811071612.4226573rdxhucmzs@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Qin Wu , "maqiufang (A)" , "netconf@ietf.org" References: <3ee03fd6be9f402ca23061f46d111857@huawei.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3ee03fd6be9f402ca23061f46d111857@huawei.com> X-ClientProxiedBy: PR3P189CA0062.EURP189.PROD.OUTLOOK.COM (2603:10a6:102:b4::7) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR3P189CA0062.EURP189.PROD.OUTLOOK.COM (2603:10a6:102:b4::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.17 via Frontend Transport; Wed, 11 Aug 2021 07:16:13 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 59ca1591-13fe-44a5-e94c-08d95c97e6f9 X-MS-TrafficTypeDiagnostic: AM8P190MB0817: X-MS-Exchange-Transport-Forked: True 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: FjtaY/WrFxUqg+PaEpN48UcZ0LZAJFEWEsG/s8Kez5Zs+wRG+iGuh1Jfrz1vk3lccz8zHcRa/hsDVklNIt7DlLmr0/i1ZTQ0Zx4uRzIHeieY2BltUO+D+BF8Wi5Pwtp8fnPs0MfN84sF2SN7XkzGeSzMNzR457YlH9jnH989rpk60sTfoWmn3gJYkhIXT4JoHicPV3gpQAW1/AdiM+7PKm3kTeKt3F6fTWOTIIjaYKlG4RPMC7jCUl3kfimZU9YZWYfj0Fx8a1gd8Yduy8tC1vpfRxFp/REhby89rrnDNwFoI9EAH/bPL76MbYhij/FI8t4Ngad7EoIof2ybWyfWLnnhR0Rfn3NBrDDlHk0nRoTX7Jx9ZkHk8BDA+yN2j5KggUNJyTfV79YOYHmJ68yWiN3z0S2iqTgz8VMqb78PU2Pno3nZktwT4MSYigI7O4aJLg6qErVb95kVlj/yg3n3I5l8/RHOnLtDr+GZzva3L+zl7L5iOjx9XprNWJGZabyXVfPpdFj1NC6HGcv/B6LoQhjpfke3oOdh0q1QiIC77WGolsNrce2d2TboI6yQmyVmRSmWd8D8nwcyHLAJ3Z4Ki5vHX9ASx1o8mJ4DkAJ0pZ0MLHkhmO2+7V+CQGF7UkK9PqRDJGPyaCk6ZEICYqg4N0FP1e3R0JcKgKlXQzTjDy1CSu4OeeIA22PzFEVQHkO74/DMNa6FA4oMQTGX7vbVKcHkXhPrl5dltmnI9kzau0ZyReyuuBW8ufgUquAm+aBrhd13vhT6aul81uSFAcplUGsCLcwGvZ2jpvBuM/Hw/qs7bNKbhQlFnD3LbPruLEZIi57i/cWBE1qsRMjF4j6gWyXCkiPfSdzIKPN0NPvWWj0= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(39840400004)(136003)(396003)(346002)(376002)(83380400001)(66946007)(186003)(26005)(66574015)(956004)(6916009)(66476007)(2906002)(66556008)(1076003)(86362001)(8676002)(52116002)(6496006)(3450700001)(316002)(54906003)(6486002)(4326008)(85202003)(53546011)(8936002)(786003)(38350700002)(38100700002)(478600001)(5660300002)(85182001)(966005)(562404015); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Wnc3QkxZSExZWTR5emNqbVpWN1dGTnE3ejRsV2RXcFV3MkRmbzF6b2tGM3c3?= =?utf-8?B?ejhCZmp6S1VpUGk0MitYRjRwb3lUTk1PV1FsYjFnWFVYa2Nnc25BV0cva0t6?= =?utf-8?B?QjVsRDJCUVNSUHNyWDF5REpLLzhna3dtMkhlV0FObGFzbVZoVkxmc0pCNitz?= =?utf-8?B?blU4UU1GS2xubS9YUkVXREJQZnJETm1oeGlpQzlOcWhYWGhCQUo3U2RmeG5Z?= =?utf-8?B?RDljQldqZVowNFByeENTMHpVMGJ2bHpsMDVhQmZVS1lGY2JxTkNyRW5xUXVa?= =?utf-8?B?M1ZiRDJaNDFuZGlwUDJlaTJaaHFWUHZ3WkkySHI1ZmYxd0tTeE51aTV4WVB3?= =?utf-8?B?dlc3QUsyMXE0YzNpSTVZY1FtT3JGdWhNb3RKMTNUWTdoeUUvRG1RTnBvelBD?= =?utf-8?B?Zy81NHVYUGNKZmFJaFo4TUJFdzQ2TzV6Mm1NeEExRXBweUhSaU93UjlTS1Bl?= =?utf-8?B?bkI3YmFDQklXd0hhTFVIQWc1SDQ4d2hzUkxqcHZUNFE5cENYcTlIVzd6eVl6?= =?utf-8?B?ZG5PZlhOTjNUL3pUWXl0ZFdTTVNMQjRJZnZKdzN0ZFhITXdkc2FnQnpiNGc2?= =?utf-8?B?WHh2TUl4ZktncDZHQldubDN4RzB5bVVNR0pyQUROS2I5UjlDNXo4b2laWWFt?= =?utf-8?B?SmV0cmpLd1dBRGQ1VHk4c2FQdmk1UTlpZTRjWXJnNHNyOFBQSzhQdktTSHBw?= =?utf-8?B?NVlXdnFLa0F3eTFvdm00N05ZTFpRUDBJcnJSR2JTR3NTRWRlWjdlT1lZMiti?= =?utf-8?B?Qno5QWFCc3RRT2ZXbkZCNWdOYmhCV3lkYWlPK05TZEl1VjRhQk16eGRQd0xK?= =?utf-8?B?WXZwVnJvRHBoRGh2ckJ2T253eHlSLzZkbW5EUWFXZnZ6MFhEZDQ5aG9wVHJa?= =?utf-8?B?UzNJQ0hMVWpaOGY1ZXVlUzJkYWhWSGFLUTJlempUSktxdzBJK0t0Y2VzRU4v?= =?utf-8?B?MUkwRm0yRDcvUEtvRHJ6Kzc3U0c0YWZkVEh2R2FXQ0dhUkRZOHhHYi8xV2Rl?= =?utf-8?B?TlNWYWE0STgxMjJ4dGcxTTJMWUY3elhtb1A5MlpQTkl5aXMvVE4veEttSS91?= =?utf-8?B?bkl3a0lRS0FnaTNlQ0FVNUFHOHhkbUVjWVRGTEVhVk1Ya3Jqc1lyVktlbVV5?= =?utf-8?B?NkgvbG4vWTFTNVgrVEdzZDZJcVBzQTFtSUU2dCtSVTl6WjREeVRlYUJqV28v?= =?utf-8?B?NFp4Y083M2s3RUl0Nit1Njc5R1Zxb2U0blNUWUFrVnk5TVMxRDQwSjRaMU5i?= =?utf-8?B?N0s0YnJPTmpMZ0xYQVUxQ1FjRHFreUQyMCtnbWhmOXowUnV6cjdWRnVpMDYz?= =?utf-8?B?MUp0K0N1NEFHOU1NVUhKVGxGbHpRWXQ1ZFFlYmhscE9qYWNBWHhORVhmN0Jx?= =?utf-8?B?My8vVjdIMkpYbUpaNEY4TzlObUR0dTVkaXZaTjJwTnpOY3dMWCt5OVl4bGgw?= =?utf-8?B?ZVlWUEsyQ0RmYXQ3YmV5NHhLRUN4b2ttako3bUVoeElyYURhcGl0dERma25w?= =?utf-8?B?V3ZkZFNVbEdXNWk0cGI5dVROa1N2THdIWDZ0NkJWRFpIUnNlRFdzczVDV1kx?= =?utf-8?B?NmNoYlA3bUVIK2NGbmpqOGdvcEU0SThaZ1JaNXQ3WXM5RkxiTEpnVWV0U2FP?= =?utf-8?B?UHQ0WExhQ3ZGN25VRWwyZzZpdk1CVUZCeHZ2MHRIbnk1R1pwcWthS0w2NEhu?= =?utf-8?B?M2NvNlExcVJlWkZaWGZqT01KeXN1MVZMbU55ZWRlRHZ1cHRKdCtzYStNeklF?= =?utf-8?Q?Fz1fG75/EGR32iOdyyUHmMqQJ3v/AcLj9QHaY6p?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 59ca1591-13fe-44a5-e94c-08d95c97e6f9 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2021 07:16:13.5656 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: dbDwUgi9Z70Er7A4hd5EovBejXT8qdRs0bxmmf9ZsefCLhHBnYj2P3PRODEoD1bWswthWWiH1NHETY+Q99xMg4g+8zUE/LQurCQTqZwwzUA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8P190MB0817 Archived-At: Subject: Re: [netconf] [netmod] Question on Subtree Filtering Usage Example 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, 11 Aug 2021 07:16:23 -0000 Thanks, I now understand your question. Since NETCONF predates YANG (and in principle is not bound to YANG), the handling of presence containers is likely not well specified. /js On Tue, Aug 10, 2021 at 02:17:34PM +0000, Qin Wu wrote: > Here is the instance example: > YANG Example: > container users { > presence "presence container users"; > list user { > key "name"; > leaf name { > type string; > } > leaf type { > type string; > } > leaf full-name { > type string > } > } > } > Note that users is presence container. > In the RPC request, we want to request All Elements together all elements within the Subtree > the subtree filter example is as follows: > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > > > > > > > > > It seems that section 6.2.5 of RFC6241 > o Multiple content match nodes (i.e., sibling nodes) are logically > combined in an "AND" expression. > applies to this case. > If both and are not configured, or there are no entry under list. > we will get the following response even though presence container are defined in the yang file. > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > Rather than > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > I think the server doesn't check whether is presence container or not, becos > the subtree filter is applied to xml file above unless there is some way in the subtree filter to indicate that users should be returned irrespective of whether child node under has value. > > -Qin > -----邮件原件----- > 发件人: Jürgen Schönwälder [mailto:j.schoenwaelder@jacobs-university.de] > 发送时间: 2021年8月10日 16:57 > 收件人: Qin Wu > 抄送: maqiufang (A) ; netconf@ietf.org > 主题: Re: [netmod] [netconf] Question on Subtree Filtering Usage Example > > Perhaps you can write down an instance tree to help us understand your question. I assume your question is whether a server has to prune empty fragments of the tree. I do not think that this is suggested by section 6.2.5., i.e., you might get if nothing is matching. > > /js > > On Tue, Aug 10, 2021 at 07:54:34AM +0000, Qin Wu wrote: > > What if and not configured under ? > > My understanding is subtree filter will not care about "users" parent > > element is the container with presence substatement Since subtree filter is applicable to xml file rather than YANG file. > > > > I am not sure how the server parses subtree filter? It looks weird to look up YANG filter for scheme first and then apply subtree filter to the xml file corresponding to yang file. > > Therefore if both and are not configured, the response I expect is return null irrespective of presence container "users". > > > > -Qin > > -----邮件原件----- > > 发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 maqiufang (A) > > 发送时间: 2021年8月6日 19:12 > > 收件人: Juergen Schoenwaelder > > 抄送: netconf@ietf.org; netmod@ietf.org > > 主题: Re: [netmod] [netconf] Question on Subtree Filtering Usage Example > > > > Hi, > > Thanks for your reply. Cross posting to NETCONF list. > > > > Best Regards, > > Qiufang Ma > > > > -----Original Message----- > > From: Jürgen Schönwälder [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Friday, August 6, 2021 6:35 PM > > To: maqiufang (A) > > Cc: netmod@ietf.org > > Subject: Re: [netmod] Question on Subtree Filtering Usage Example > > > > Hi, > > > > you may want to send your question to the netconf list since this is a > > protocol question and not a YANG question. (Concerning your question, > > please read section 6.2.4 "Selection Nodes". There is no restriction > > to only one selection node as far as I can tell.) > > > > /js > > > > On Fri, Aug 06, 2021 at 09:29:50AM +0000, maqiufang (A) wrote: > > > Hi, all: > > > > > > In RFC6241 section 6.4(https://datatracker.ietf.org/doc/html/rfc6241#section-6.4), several single subtree filtering examples are given. > > > I am wondering whether we can select multiple elements within the Subtree. > > > Note that we also assume "users" parent element is the container with presence substatement. > > > Here is the RPC request message with specific subtree filtering : > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am wondering what RPC response will look like? It will respond with null or it will respond as follows: > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > > > > > > > root > > > superuser > > > > > > > > > fred > > > admin > > > > > > > > > > > > > > > > > > > > > > > > > > > Best Regards, > > > Qiufang Ma > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Aug 11 15:48:44 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 0DB073A2813 for ; Wed, 11 Aug 2021 15:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-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=hq.sk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTpbgdabu4eQ for ; Wed, 11 Aug 2021 15:48:36 -0700 (PDT) Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC8633A280D for ; Wed, 11 Aug 2021 15:48:34 -0700 (PDT) Received: from nitebug.nitenet.local (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id 5B9E6243A55; Thu, 12 Aug 2021 00:48:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1628722111; bh=4aPz5S+HCCE/YqbQp1Q/AJ7rD4ePPoy1XrbpCijXeAc=; h=To:References:From:Subject:Date:In-Reply-To; b=RtHkakuHBzrAfEZzlbsrLXnDqVH/UfW/HAtYmId1i2uP2xx9wNTx9Be7XlFy04CX6 vV75hGalu/V94cLyxctOgqAz9yw0iqq5pi+Ggdx2WG6NnW4JX9wZGQN+H1qircFqZA mjy6TCQsE/PJEgUoWTRJj71ko2yAzZhh2mf48U+M= To: Qin Wu , Mahesh Jethanandani , "netconf@ietf.org" References: From: Robert Varga Message-ID: Date: Thu, 12 Aug 2021 00:48:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="aYxeEfJf2WhiaQFCU1SXL3t0R5Ffp82d5" Archived-At: Subject: Re: [netconf] Compression mode vs Encoding format (draft-tao-netconf-data-export-capabilities) 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, 11 Aug 2021 22:48:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aYxeEfJf2WhiaQFCU1SXL3t0R5Ffp82d5 Content-Type: multipart/mixed; boundary="MDF7Qx3VGU7i89GuA7vvJPdb3w8cu9Iau"; protected-headers="v1" From: Robert Varga To: Qin Wu , Mahesh Jethanandani , "netconf@ietf.org" Message-ID: Subject: Re: [netconf] Compression mode vs Encoding format (draft-tao-netconf-data-export-capabilities) References: In-Reply-To: --MDF7Qx3VGU7i89GuA7vvJPdb3w8cu9Iau Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 04/08/2021 10:17, Qin Wu wrote: > Hi, Mahesh: Hello everyone, > One of comments you raised in the meeting on > draft-tao-netconf-data-export-capabilities-05 > (https://datatracker.ietf.org/doc/html/draft-tao-netconf-data-export-ca= pabilities-05.txt) >=20 > is the relation between compression mode and Encoding format. >=20 > Here is a few clarifications: >=20 > 1.=A0=A0=A0=A0=A0=A0 Compression mode is not encoding format >=20 > Compression mode indicates that the server support data compression or > deflate or gzip compression supported by NETCONF. The deflate or gzip > compression will be applied to xml file. >=20 > It is independent from what encoding (e.g., JSON, XML, binary) is chose= n > for exported data. Perhaps we should be using different names? I think the modeling intent is really to reference various media types: dec:xml and dec:json correspond to https://datatracker.ietf.org/doc/html/rfc8040#section-11.3 dec:cbor corresponds to https://www.ietf.org/archive/id/draft-ietf-core-yang-cbor-16.html#name-me= dia-types-registry dec:gpb corresponds to ??? Converting between encodings routinely requires understanding of the YANG model (for example instance-identifiers in JSON vs XML). > 2.=A0=A0=A0=A0=A0=A0 Compression mode is not header compression defined= by HTTP2. >=20 > 3.=A0=A0=A0=A0=A0=A0 Right now, we haven=92t seen any standard document= ing compression > mode. Right, but compression (in the bit stream sense) is probably best left to the transport protocol -- SSH/HTTP can routinely handle that. This is more akin to HTTP's Transfer-Encoding, I think. Efficient XML Interchange Capability for NETCONF has been proposed > before >=20 > https://datatracker.ietf.org/doc/html/draft-varga-netconf-exi-capabilit= y-01 > >=20 > but it doesn=92t reach any agreement. The idea is very close to what we= > propose in draft-tao-netconf-data-export-capabilities-05. But still > different. Right, and then the exi-capability draft would define an identity derived from dec:binary (and probably a media type as well). Not that I plan to pick it up again anytime soon :) Regards, Robert >=20 > Hope this clarify your comment. >=20 > =A0 >=20 > -Qin (On behalf of authors) >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 --MDF7Qx3VGU7i89GuA7vvJPdb3w8cu9Iau-- --aYxeEfJf2WhiaQFCU1SXL3t0R5Ffp82d5 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEE9xJg9S8sgC+6qlK6U310SwoeP0UFAmEUU74FAwAAAAAACgkQU310SwoeP0Wo Dg//QA9fXhbkK5wHl569btyCkwV5L/EmkMRKNhpGg3n/BNRRQ1YdAmzLC7sF2dgr9NLDaY6hMTUq o5b6RKjIlymkK1xI6R+YUPNJkJW7zPphxST7c6EMx5XgYxeWUHcc/yFGA2GcM6VzaM0fB8VEHiF2 3RGLnA9lLMhExUXI4Wl6XqCX0TPRG4f8p2k0PL62An7dTSXmhbSmj2AXNzv69D61pUugZPrT0dwy rzF4GMnvvqtR98uO8PSIiHQhWPYsc4m0hkBb9geLRop9ewS4b+FcA09gnjC/i1hWEOx9Uk408wFi 4iuT8weH8jW3bgbca8Hci40rkuxEKNJyhQz5AaOvFUzRucO/9OFZgj3XKSTtD8nJaPTrY+synu8m dOBhwUQfqhZb4axnGXvJNOXu0miE/Kppj8icFZQ7ETEcf0ayp0ie+aRTdcDf84tL+eT0skbe655j D8lKktCaOazxmdpINn0Xp/ThaBF27QkkcUy6gkGGebR60xxhTdAlibnWpFwJsHPta1oaKZDdhGG5 ATAXfOlqNEkZLonoPCvZr2+YBG/erbvdHOoPuTdlrqINxg3XM//fKH57uM64FaVh9hF77VtaTs0a tf3kp8iUNt0HC2EDE6I3sR4t7xOL3uBOv4Y9U38209L0EHsjc3W6jNPscR/Pm56o0SfOGqlspN60 AAI= =ML1F -----END PGP SIGNATURE----- --aYxeEfJf2WhiaQFCU1SXL3t0R5Ffp82d5-- From nobody Thu Aug 12 18:15:23 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 9D0B33A1357 for ; Thu, 12 Aug 2021 18:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 F4NzW2yWI02U for ; Thu, 12 Aug 2021 18:15:15 -0700 (PDT) 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 85BBD3A1354 for ; Thu, 12 Aug 2021 18:15:15 -0700 (PDT) Received: from fraeml701-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Gm5F31VTbz6G9JD; Fri, 13 Aug 2021 09:14:31 +0800 (CST) Received: from dggeml753-chm.china.huawei.com (10.1.199.152) by fraeml701-chm.china.huawei.com (10.206.15.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.8; Fri, 13 Aug 2021 03:15:10 +0200 Received: from dggeml753-chm.china.huawei.com (10.1.199.152) by dggeml753-chm.china.huawei.com (10.1.199.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Fri, 13 Aug 2021 09:15:08 +0800 Received: from dggeml753-chm.china.huawei.com ([10.1.199.152]) by dggeml753-chm.china.huawei.com ([10.1.199.152]) with mapi id 15.01.2176.012; Fri, 13 Aug 2021 09:15:08 +0800 From: Qin Wu To: Robert Varga , Mahesh Jethanandani , "netconf@ietf.org" Thread-Topic: [netconf] Compression mode vs Encoding format (draft-tao-netconf-data-export-capabilities) Thread-Index: AdeP4Kb9wIJ+F9GrSD6JPQCDkPH5pQ== Date: Fri, 13 Aug 2021 01:15:08 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.123.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Compression mode vs Encoding format (draft-tao-netconf-data-export-capabilities) 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, 13 Aug 2021 01:15:22 -0000 SGksIFJvYmVydDoNCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPuWPkeS7tuS6ujogUm9iZXJ0 IFZhcmdhIFttYWlsdG86bml0ZUBocS5za10gDQo+5Y+R6YCB5pe26Ze0OiAyMDIx5bm0OOaciDEy 5pelIDY6NDkNCj7mlLbku7bkuro6IFFpbiBXdSA8YmlsbC53dUBodWF3ZWkuY29tPjsgTWFoZXNo IEpldGhhbmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+OyBuZXRjb25mQGlldGYub3Jn DQo+5Li76aKYOiBSZTogW25ldGNvbmZdIENvbXByZXNzaW9uIG1vZGUgdnMgRW5jb2RpbmcgZm9y bWF0IChkcmFmdC10YW8tbmV0Y29uZi1kYXRhLWV4cG9ydC1jYXBhYmlsaXRpZXMpDQoNCj5PbiAw NC8wOC8yMDIxIDEwOjE3LCBRaW4gV3Ugd3JvdGU6DQo+PiBIaSwgTWFoZXNoOg0KDQo+SGVsbG8g ZXZlcnlvbmUsDQoNCj4+IE9uZSBvZiBjb21tZW50cyB5b3UgcmFpc2VkIGluIHRoZSBtZWV0aW5n IG9uDQo+PiBkcmFmdC10YW8tbmV0Y29uZi1kYXRhLWV4cG9ydC1jYXBhYmlsaXRpZXMtMDUNCj4+ IChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXRhby1uZXRjb25m LWRhdGEtZXhwb3J0LWMNCj4+IGFwYWJpbGl0aWVzLTA1LnR4dCkNCj4+IA0KPj4gaXMgdGhlIHJl bGF0aW9uIGJldHdlZW4gY29tcHJlc3Npb24gbW9kZSBhbmQgRW5jb2RpbmcgZm9ybWF0Lg0KPj4g DQo+PiBIZXJlIGlzIGEgZmV3IGNsYXJpZmljYXRpb25zOg0KPj4gDQo+PiAxLsKgwqDCoMKgwqDC oCBDb21wcmVzc2lvbiBtb2RlIGlzIG5vdCBlbmNvZGluZyBmb3JtYXQNCj4+IA0KPj4gQ29tcHJl c3Npb24gbW9kZSBpbmRpY2F0ZXMgdGhhdCB0aGUgc2VydmVyIHN1cHBvcnQgZGF0YSBjb21wcmVz c2lvbiBvciANCj4+IGRlZmxhdGUgb3IgZ3ppcCBjb21wcmVzc2lvbiBzdXBwb3J0ZWQgYnkgTkVU Q09ORi4gVGhlIGRlZmxhdGUgb3IgZ3ppcCANCj4+IGNvbXByZXNzaW9uIHdpbGwgYmUgYXBwbGll ZCB0byB4bWwgZmlsZS4NCj4+IA0KPj4gSXQgaXMgaW5kZXBlbmRlbnQgZnJvbSB3aGF0IGVuY29k aW5nIChlLmcuLCBKU09OLCBYTUwsIGJpbmFyeSkgaXMgDQo+PiBjaG9zZW4gZm9yIGV4cG9ydGVk IGRhdGEuDQoNCj5QZXJoYXBzIHdlIHNob3VsZCBiZSB1c2luZyBkaWZmZXJlbnQgbmFtZXM/DQpb UWluIFd1XSBTb3VuZHMgZ29vZCBzdWdnZXN0aW9uLCBJIHRoaW5rIGVuY29kaW5nIGhlcmUgaXMg bm90aWZpY2F0aW9uIG1lc3NhZ2UgZW5jb2RpbmcNCldoaWNoIEkgcmVhbGl6ZSwgaXMgZGlmZmVy ZW50IGZyb20gSFRUUCBjb250ZW50IGVuY29kaW5nIA0KaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNz aWdubWVudHMvaHR0cC1wYXJhbWV0ZXJzL2h0dHAtcGFyYW1ldGVycy54aHRtbA0KaGUgcmVnaXN0 cnkgY3VycmVudGx5IGxpc3RzOg0KDQpiciAgICAgICAgICAgQnJvdGxpIENvbXByZXNzZWQgRGF0 YSBGb3JtYXQgICAgICAgICAgICAgICAgW1JGQzc5MzJdICAgICANCmNvbXByZXNzICAgICBVTklY ICJjb21wcmVzcyIgZGF0YSBmb3JtYXQgICAgICAgICAgICAgICAgICBbUkZDNzIzMF0gU2VjdGlv biA0LjIuMQ0KZGVmbGF0ZSAgICAgICJkZWZsYXRlIiBjb21wcmVzc2VkIGRhdGEgKFtSRkMxOTUx XSkgICAgICAgIFtSRkM3MjMwXSBTZWN0aW9uIDQuMi4yDQogICAgICAgICAgICAgaW5zaWRlIHRo ZSAiemxpYiIgZGF0YSBmb3JtYXQgKFtSRkMxOTUwXSkNCmV4aSAgICAgICAgICBXM0MgRWZmaWNp ZW50IFhNTCBJbnRlcmNoYW5nZQ0KDQo+PkkgdGhpbmsgdGhlIG1vZGVsaW5nIGludGVudCBpcyBy ZWFsbHkgdG8gcmVmZXJlbmNlIHZhcmlvdXMgbWVkaWEgdHlwZXM6DQoNCj4+ZGVjOnhtbCBhbmQg ZGVjOmpzb24gY29ycmVzcG9uZCB0bw0KPj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9odG1sL3JmYzgwNDAjc2VjdGlvbi0xMS4zDQo+PmRlYzpjYm9yIGNvcnJlc3BvbmRzIHRvDQo+ Pmh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtaWV0Zi1jb3JlLXlhbmctY2Jv ci0xNi5odG1sI25hbWUtbWVkaWEtdHlwZXMtcmVnaXN0cnkNCg0KPj5kZWM6Z3BiIGNvcnJlc3Bv bmRzIHRvID8/Pw0KDQpbUWluIFd1XSBUaGVyZSBpcyBubyBvZmZpY2lhbCBtZWRpYSB0eXBlIGZv ciBwcm90b2NvbCBidWZmZXJzIHJlZ2lzdGVyZWQgd2l0aCB0aGUgSUFOQSwgVGhleSBjaG9vc2Ug Q29udGVudF90eXBlIG9yIEFMVCBDb250ZW50X3R5cGUgaW5zdGVhZCwgc2VlIHRoZSBsaW5rDQpo dHRwczovL2dvb2dsZWFwaXMuZGV2L2phdmEvZ29vZ2xlLWh0dHAtY2xpZW50LzEuMjkuMC9jb20v Z29vZ2xlL2FwaS9jbGllbnQvcHJvdG9idWYvUHJvdG9jb2xCdWZmZXJzLmh0bWwNCk1heWJlIGRl YzpncGIgc2hvdWxkIGJlIHRha2VuIG91dC4NCg0KPj5Db252ZXJ0aW5nIGJldHdlZW4gZW5jb2Rp bmdzIHJvdXRpbmVseSByZXF1aXJlcyB1bmRlcnN0YW5kaW5nIG9mIHRoZSBZQU5HIG1vZGVsIChm b3IgZXhhbXBsZSBpbnN0YW5jZS1pZGVudGlmaWVycyBpbiBKU09OIHZzIFhNTCkuDQoNCj4+IDIu wqDCoMKgwqDCoMKgIENvbXByZXNzaW9uIG1vZGUgaXMgbm90IGhlYWRlciBjb21wcmVzc2lvbiBk ZWZpbmVkIGJ5IEhUVFAyLg0KPj4gDQo+PiAzLsKgwqDCoMKgwqDCoCBSaWdodCBub3csIHdlIGhh dmVu4oCZdCBzZWVuIGFueSBzdGFuZGFyZCBkb2N1bWVudGluZyANCj4+IGNvbXByZXNzaW9uIG1v ZGUuDQoNCj5SaWdodCwgYnV0IGNvbXByZXNzaW9uIChpbiB0aGUgYml0IHN0cmVhbSBzZW5zZSkg aXMgcHJvYmFibHkgYmVzdCBsZWZ0IHRvIHRoZSB0cmFuc3BvcnQgcHJvdG9jb2wgLS0gU1NIL0hU VFAgY2FuIHJvdXRpbmVseSBoYW5kbGUgdGhhdC4NCg0KPlRoaXMgaXMgbW9yZSBha2luIHRvIEhU VFAncyBUcmFuc2Zlci1FbmNvZGluZywgSSB0aGluay4NCg0KW1FpbiBXdV0gSSBhZ3JlZS4gU2Vl IGFib3ZlIHRoZSByZWZlcmVuY2UgbGluazoNCmh0dHBzOi8vZ29vZ2xlYXBpcy5kZXYvamF2YS9n b29nbGUtaHR0cC1jbGllbnQvMS4yOS4wL2NvbS9nb29nbGUvYXBpL2NsaWVudC9wcm90b2J1Zi9Q cm90b2NvbEJ1ZmZlcnMuaHRtbA0KDQo+RWZmaWNpZW50IFhNTCBJbnRlcmNoYW5nZSBDYXBhYmls aXR5IGZvciBORVRDT05GIGhhcyBiZWVuIHByb3Bvc2VkDQo+PiBiZWZvcmUNCj4+IA0KPj4gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC12YXJnYS1uZXRjb25mLWV4 aS1jYXBhYmlsaQ0KPj4gdHktMDEgDQo+PiA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvaHRtbC9kcmFmdC12YXJnYS1uZXRjb25mLWV4aS1jYXBhYmlsDQo+IGl0eS0wMT4NCj4+IA0K Pj4gYnV0IGl0IGRvZXNu4oCZdCByZWFjaCBhbnkgYWdyZWVtZW50LiBUaGUgaWRlYSBpcyB2ZXJ5 IGNsb3NlIHRvIHdoYXQgd2UgDQo+PiBwcm9wb3NlIGluIGRyYWZ0LXRhby1uZXRjb25mLWRhdGEt ZXhwb3J0LWNhcGFiaWxpdGllcy0wNS4gQnV0IHN0aWxsIA0KPj4gZGlmZmVyZW50Lg0KDQo+Umln aHQsIGFuZCB0aGVuIHRoZSBleGktY2FwYWJpbGl0eSBkcmFmdCB3b3VsZCBkZWZpbmUgYW4gaWRl bnRpdHkgZGVyaXZlZCBmcm9tIGRlYzpiaW5hcnkgKGFuZCBwcm9iYWJseSBhIG1lZGlhIHR5cGUg YXMgd2VsbCkuIE5vdCB0aGF0IEkgcGxhbiB0byBwaWNrIGl0IHVwIGFnYWluIGFueXRpbWUgc29v biA6KQ0KDQpbUWluIFd1XSBVbmRlcnN0b29kLCB0aGFuayBmb3IgY2xhcmlmaWNhdGlvbi4NCg0K PlJlZ2FyZHMsDQo+Um9iZXJ0DQoNCj4gDQo+IEhvcGUgdGhpcyBjbGFyaWZ5IHlvdXIgY29tbWVu dC4NCj4gDQo+IMKgDQo+IA0KPiAtUWluIChPbiBiZWhhbGYgb2YgYXV0aG9ycykNCj4gDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRj b25mIG1haWxpbmcgbGlzdA0KPiBuZXRjb25mQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KPiANCg0K From nobody Sun Aug 15 18:38:09 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 0DB2C3A0D3C; Sun, 15 Aug 2021 18:38:03 -0700 (PDT) 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.36.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <162907788297.2949.18080422908641530735@ietfa.amsl.com> Date: Sun, 15 Aug 2021 18:38:03 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-sztp-csr-06.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, 16 Aug 2021 01:38:03 -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-06.txt Pages : 34 Date : 2021-08-15 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-06.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-sztp-csr-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Aug 15 18:59:18 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 4D8393A0F0C; Sun, 15 Aug 2021 18:59:16 -0700 (PDT) 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.36.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <162907915626.5590.12310323325954359989@ietfa.amsl.com> Date: Sun, 15 Aug 2021 18:59:16 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-sztp-csr-07.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, 16 Aug 2021 01:59:17 -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-07.txt Pages : 34 Date : 2021-08-15 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-07.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-sztp-csr-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Aug 15 19:02:30 2021 Return-Path: <0100017b4cb20cee-3638c1d3-c5d0-4417-8cd9-8df5669a2a2b-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 504E83A0FC2; Sun, 15 Aug 2021 19:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tw418yFF1Jht; Sun, 15 Aug 2021 19:02:23 -0700 (PDT) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6833A0FC3; Sun, 15 Aug 2021 19:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1629079342; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=s/QoKBKXFuEulINVv/DIfnjhqkANrXhar+RyW6I0TxE=; b=QPXEdp4dfP0TMoxAgJOEQmN6w48YsMhy4VqphODAVbHo22ShgDcmPKxZDJCqJol3 2rI+zdAAttD2jMa6UNW4AvOgQ4H6wfFNEo9ye60GSv593aqoPB7gqViVbzkoIkYs215 YIJuD8PkL4jC5ll18PHrgvF0fbLhba0c1SoPnthk= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Kent Watsen In-Reply-To: <162907788324.2949.13159388023679125044@ietfa.amsl.com> Date: Mon, 16 Aug 2021 02:02:22 +0000 Cc: "netconf@ietf.org" , draft-ietf-netconf-sztp-csr@ietf.org, "Brockhaus, Hendrik" , David von Oheimb Content-Transfer-Encoding: quoted-printable Message-ID: <0100017b4cb20cee-3638c1d3-c5d0-4417-8cd9-8df5669a2a2b-000000@email.amazonses.com> References: <162907788324.2949.13159388023679125044@ietfa.amsl.com> To: "Rob Wilton (rwilton)" X-Mailer: Apple Mail (2.3654.100.0.2.22) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.08.16-54.240.8.31 Archived-At: Subject: Re: [netconf] New Version Notification for draft-ietf-netconf-sztp-csr-06.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, 16 Aug 2021 02:02:29 -0000 Hi Rob, The -06 update addresses: - Your AD Review comments. - The request from the ANIMA WG to factor out some groupings. - An update to the description statement for the =E2=80=9Ccmc-csr=E2=80=9D= and =E2=80=9Ccmp-csr=E2=80=9D nodes prompted by Security experts. - A number of editorial items. The -07 update fixes an item spotted when looking at the -06 =E2=80=9Cdiff= =E2=80=9D. I believe all the issues have now been resolved. Kent // as co-author > On Aug 15, 2021, at 9:38 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-ietf-netconf-sztp-csr-06.txt > has been successfully submitted by Kent Watsen and posted to the > IETF repository. >=20 > Name: draft-ietf-netconf-sztp-csr > Revision: 06 > Title: Conveying a Certificate Signing Request (CSR) in = a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request > Document date: 2021-08-15 > Group: netconf > Pages: 34 > URL: = https://www.ietf.org/archive/id/draft-ietf-netconf-sztp-csr-06.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ > Html: = https://www.ietf.org/archive/id/draft-ietf-netconf-sztp-csr-06.html > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-sztp-csr-06 >=20 > 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. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 From nobody Mon Aug 16 21:01: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 9ED5D3A0B72; Mon, 16 Aug 2021 21:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GJrzdSds1Vyl; Mon, 16 Aug 2021 21:01:44 -0700 (PDT) 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 DFAAB3A0B4B; Mon, 16 Aug 2021 21:01:43 -0700 (PDT) Received: from fraeml701-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Gpcl75L5Vz6BGG4; Tue, 17 Aug 2021 12:00:51 +0800 (CST) Received: from dggeme720-chm.china.huawei.com (10.1.199.116) by fraeml701-chm.china.huawei.com (10.206.15.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.8; Tue, 17 Aug 2021 06:01:39 +0200 Received: from dggeme770-chm.china.huawei.com (10.3.19.116) by dggeme720-chm.china.huawei.com (10.1.199.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Tue, 17 Aug 2021 12:01:38 +0800 Received: from dggeme770-chm.china.huawei.com ([10.8.68.58]) by dggeme770-chm.china.huawei.com ([10.8.68.58]) with mapi id 15.01.2176.012; Tue, 17 Aug 2021 12:01:38 +0800 From: "maqiufang (A)" To: Kent Watsen , "draft-tao-netconf-data-export-capabilities@ietf.org" , "draft-claise-netconf-metadata-for-collection@ietf.org" , "draft-wang-netconf-adaptive-subscription@ietf.org" CC: "netconf@ietf.org" Thread-Topic: [netconf] Overview of the various "capabilities" drafts Thread-Index: AdeShLLjfi28n+LuRkqHioZUx+tT/w== Date: Tue, 17 Aug 2021 04:01:38 +0000 Message-ID: <732deac48bb04780b8e144f99eac7a2c@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.123.93] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Overview of the various "capabilities" drafts 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, 17 Aug 2021 04:01:50 -0000 SGksIEtlbnQsIGFsbA0KQXMgYSBjb2F1dGhvciBvZiBkYXRhLWV4cG9ydC1jYXBhYmlsaXRpZXMg YW5kIGFkYXB0aXZlLXN1YnNjcmlwdGlvbiBkcmFmdDoNCg0KMS4gSSB3b3VsZCBsaWtlIHRvIGNs YXJpZnkgdGhhdCBhZGFwdGl2ZS1zdWJzY3JpcHRpb24gYXVnbWVudHMgdGhlICJ1cGRhdGUtdHJp Z2dlciIgY2hvaWNlIGRlZmluZWQgaW4gImlldGYteWFuZy1wdXNoIiBtb2R1bGUoUkZDIDg2NDEp LiBBbHRob3VnaCBpdCBhbHNvIHByb3ZpZGVzIGFuIG9wdGltdW0gZGF0YSBjb2xsZWN0aW9uIG1l Y2hhbmlzbSwgdGhpcyBkcmFmdCBkb2Vzbid0IGFkdm9jYXRlIHRoZSBjYXBhYmlsaXRpZXMgZXhw b3N1cmUsIGJ1dCBwcm92aWRlcyBhbm90aGVyIHdheSBvZiBzdWJzY3JpcHRpb24gdHJpZ2dlciBp biBhZGRpdGlvbiB0byBwZXJpb2RpYyBhbmQgb24tY2hhbmdlIHN1YnNjcmlwdGlvbi4NCkl0IGFs bG93cyBhIHB1Ymxpc2hlciB0byBzd2l0Y2ggdG8gZGlmZmVyZW50IHBlcmlvZCBpbnRlcnZhbHMg YXV0b21hdGljYWxseSBhY2NvcmRpbmcgdG8gdGhlIHhwYXRoIGV2YWx1YXRpb24gcmVzdWx0cy4N ClRoZSBhZGFwdGl2ZS1zdWJzY3JpcHRpb24gcmVsYXRlZCBjYXBhYmlsaXRpZXMgaXMgZGlzY292 ZXJlZCB0aHJvdWdoIGFkYXB0aXZlLWludGVydmFsLXN1cHBvcnQgcGFyYW1ldGVyIGRlZmluZWQg aW4gZHJhZnQtdGFvLW5ldGNvbmYtZGF0YS1leHBvcnQtY2FwYWJpbGl0aWVzLCBidXQgaXQgZG9l cyBub3QgbmVlZCB0byBkZXBlbmQgb24gdGhlIGRhdGEgZXhwb3J0IGNhcGFiaWxpdHkgaWYgdGhl IGNsaWVudCBoYXMgaGV1cmlzdGljIGtub3dsZWRnZSBhYm91dCB0aGUgc2VydmVyIHN1cHBvcnRz IG11bHRpcGxlIHVwZGF0ZSBpbnRlcnZhbC4NClNvIEkgdGhpbmsgbWF5YmUgYWRhcHRpdmUtc3Vi c2NyaXB0aW9uIHNob3VsZCBiZSBleGNsdWRlZCBmcm9tIG91ciAiY2FwYWJpbGl0aWVzIGRpc2N1 c3Npb24iLg0KDQoyLiBEcmFmdC1jbGFpc2UtbmV0Y29uZi1tZXRhZGF0YS1mb3ItY29sbGVjdGlv biBhdWdtZW50cyAic3lzdGVtLWNhcGFiaWxpdGllcyIgIGRhdGEgbW9kZWwgYW5kIHByb3ZpZGVz IHBlci1ub2RlIG1ldGFkYXRhIGluZm9ybWF0aW9uIGZvciBvcHRpbXVtIGRhdGEgY29sbGVjdGlv bi4gSSB0aGluayBpdCBpcyBkZXNpZ25lZCBmb3Igc2VydmljZSBhc3N1cmFuY2UgdXNlIGNhc2Ug ZGVmaW5lZCBpbiBJLUQuaWV0Zi1vcHNhd2ctc2VydmljZS1hc3N1cmFuY2UteWFuZyBidXQgY291 bGQgYWxzbyBiZSBhcHBsaWVkIHRvIG90aGVyIHRlbGVtZXRyeSB1c2UgY2FzZXM7DQpBbmQgZHJh ZnQtdGFvLW5ldGNvbmYtZGF0YS1leHBvcnQtY2FwYWJpbGl0aWVzIGF1Z21lbnRzICJzeXN0ZW0t Y2FwYWJpbGl0aWVzIiBkYXRhIG1vZGVsIHRvIHByb3ZpZGUgdHJhbnNwb3J0IHNwZWNpZmljIHN5 c3RlbS1sZXZlbCBjYXBhYmlsaXRpZXMgYW5kIHNvbWUgcGVyLW5vZGUgc3VwcG9ydCBjYXBhYmls aXRpZXMoc3VjaCBhcyBtZXNzYWdlLWJ1bmRsaW5nLXN1cHBvcnQsIGFkYXB0aXZlLWludGVydmFs LXN1cHBvcnQsIGV0YykuIEl0IGlzIGRlc2lnbmVkIGZvciBZQU5HIHB1c2ggdXNlIGNhc2UsIGFk YXB0aXZlIHN1YnNjcmlwdGlvbiB1c2UgY2FzZSwgVURQLW5vdGlmIHVzZSBjYXNlIGFuZCBtZXNz YWdlIGJ1bmRsaW5nIHVzZSBjYXNlLg0KDQozLiBSZWdhcmRpbmcgY29tcGxpbWVudCBhbmQvb3Ig b3ZlcmxhcCBvZiBkYXRhLWV4cG9ydC1jYXBhYmlsaXRpZXMgYW5kIG1ldGFkYXRhLWZvci1jb2xs ZWN0aW9uLCBJIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2QgdG8gY29tYmluZSB0aGVzZSB0d28gZHJh ZnRzIGFuZCB3ZSBjYW4gYWxzbyByZXZpZXcgaWYgdGhlcmUgYXJlIGFueSBvdGhlciBjYXBhYmls aXRpZXMgbmVlZGVkIHRvIHN1cHBvcnQgdGhlIGNsb3NlZC1sb29wIGF1dG9tYXRpb24gYmV5b25k IG9uZXMgYWxyZWFkeSBkZWZpbmVkIGluIHRoaXMgdHdvIGRyYWZ0cy4NCmFmdGVyIHRoaW5raW5n IGFib3V0IGl0LCBJIHRoaW5rIHRoZXJlIGFyZSAzIGNvbWJpbmF0aW9uIG9wdGlvbnM6DQpPcHRp b24gQTogTWVyZ2UgZGF0YSBleHBvcnQgY2FwYWJpbGl0eSBkcmFmdCBhbmQgbWV0YSBkYXRhIGNv bGxlY3Rpb24gZHJhZnQgaW50byBvbmUgYnV0IHN0aWxsIGRlZmluZSB0d28gZGlmZmVyZW50IG1v ZGVscywgb25lIGZvciBkYXRhIGV4cG9ydCwgb25lIGZvciBtZXRhZGF0YSBjb2xsZWN0aW9uDQog ICAgICAgICAgICAgICAgICAgIFBybzogU2NvcGUgZm9yICJzeXN0ZW0tY2FwYWJpbGl0eSIgZXh0 ZW5zaW9uIGlzIGNsZWFyDQpPcHRpb24gQjogTWVyZ2UgZGF0YSBleHBvcnQgY2FwYWJpbGl0eSBk cmFmdCBhbmQgbWV0YSBkYXRhIGNvbGxlY3Rpb24gZHJhZnQgaW50byBvbmUsIGNvbnNvbGlkYXRl IGRhdGEgZXhwb3J0IGNhcGFiaWxpdHkgbW9kZWwgaW50byBtZXRhIGRhdGEgY29sbGVjdGlvbiBt b2RlbA0KICAgICAgICAgICAgICAgICAgIENvbjogU2NvcGUgZm9yICJzeXN0ZW0tY2FwYWJpbGl0 eSIgZXh0ZW5zaW9uIGlzIG5vdCBjbGVhciBzaW5jZSBkaWZmZXJlbnQgc3lzdGVtIGNhcGFiaWxp dGllcyBhcmUgbWl4ZWQgdG9nZXRoZXIuDQpPcHRpb24gQzogS2VlcCB0d28gZHJhZnRzIHNlcGFy YXRlLCBtb3ZlIHNvbWUgb2YgbWV0YWRhdGEgcmVsYXRlZCBwZXItbm9kZSBwYXJhbWV0ZXJzKG1l c3NhZ2UtYnVuZGxpbmctc3VwcG9ydCwgYWRhcHRpdmUtaW50ZXJ2YWwtc3VwcG9ydCwgZXRjKSBm cm9tIGRhdGEgZXhwb3J0IGRyYWZ0IHRvIG1ldGEgZGF0YSBjb2xsZWN0aW9uIGRyYWZ0LCBhbmQg a2VlcCB0aGUgdHJhbnNwb3J0IHNwZWNpZmljIHBhcmFtZXRlcnModHJhbnNwb3J0LXByb3RvY29s LCBlbmNvZGluZy1mb3JtYXQsIGV0YykgaW4gdGhlIGRhdGEtZXhwb3J0LWNhcGFiaWxpdGllcyBk cmFmdC4NCiAgICAgICAgICAgICAgICAgIFBybzogU2NvcGUgZm9yIGJvdGggcGVyLW5vZGUgbWV0 YWRhdGEgY2FwYWJpbGl0eSBhbmQgdHJhbnNwb3J0IHNwZWNpZmljIHN5c3RlbS1sZXZlbCBjYXBh YmlsaXR5IGFyZSBjbGVhcg0KDQpBbnkgdGhvdWdodHM/DQoNCg0KQmVzdCBSZWdhcmRzLA0KUWl1 ZmFuZyBNYQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogS2VudCBXYXRzZW4g W21haWx0bzprZW50K2lldGZAd2F0c2VuLm5ldF0gDQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMTAs IDIwMjEgNzozMCBBTQ0KVG86IGRyYWZ0LXRhby1uZXRjb25mLWRhdGEtZXhwb3J0LWNhcGFiaWxp dGllc0BpZXRmLm9yZzsgZHJhZnQtY2xhaXNlLW5ldGNvbmYtbWV0YWRhdGEtZm9yLWNvbGxlY3Rp b25AaWV0Zi5vcmc7IGRyYWZ0LXdhbmctbmV0Y29uZi1hZGFwdGl2ZS1zdWJzY3JpcHRpb25AaWV0 Zi5vcmcNCkNjOiBuZXRjb25mQGlldGYub3JnDQpTdWJqZWN0OiBPdmVydmlldyBvZiB0aGUgdmFy aW91cyAiY2FwYWJpbGl0aWVzIiBkcmFmdHMNCg0KRHJhZnQtYXV0aG9ycyBpbiB0aGUg4oCcVG/i gJ0gbGluZSwNCg0KRHVyaW5nIHRoZSAxMTEgc2Vzc2lvbiBJIG1hZGUgdGhlIHN0YXRlbWVudCB0 aGF0IGFsbCB0aGVzZSBkcmFmdHMgYXJlIGF1Z21lbnRpbmcgdGhlIG5ldyDigJxzeXN0ZW0gY2Fw YWJpbGl0aWVz4oCdIGRhdGEgdHJlZSBhbmQgd29uZGVyZWQgdG8gd2hhdCBleHRlbnQgdGhlc2Ug ZWZmb3J0cyBjb21wbGltZW50IGFuZC9vciBvdmVybGFwIGVhY2ggb3RoZXIuICBDb3VsZCB5b3Ug cGxlYXNlIGRpc2N1c3MgdGhpcz8NCg0KS2VudCAobm8gaGF0KQ0KDQoNCg== From nobody Tue Aug 17 02:55:26 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 DBA493A11B6; Tue, 17 Aug 2021 02:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Y9D3mJKZdr-h; Tue, 17 Aug 2021 02:55:17 -0700 (PDT) Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) (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 F125A3A11C8; Tue, 17 Aug 2021 02:55:16 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 17H9t9B6007523 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 17 Aug 2021 11:55:09 +0200 Received: from [139.22.33.193] ([139.22.33.193]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 17H9t5J1023274; Tue, 17 Aug 2021 11:55:06 +0200 To: Kent Watsen , "Rob Wilton (rwilton)" Cc: "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> From: David von Oheimb Message-ID: <6247a309-c24d-041b-704c-2ddf8b372d00@siemens.com> Date: Tue, 17 Aug 2021 11:55:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <0100017b4cb20cee-3638c1d3-c5d0-4417-8cd9-8df5669a2a2b-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="------------829B1B0941CE38B53344467C" Content-Language: en-US Archived-At: Subject: Re: [netconf] New Version Notification for draft-ietf-netconf-sztp-csr-06.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: Tue, 17 Aug 2021 09:55:23 -0000 This is a multi-part message in MIME format. --------------829B1B0941CE38B53344467C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Kent et al, thanks for your message regarding the update to the draft and for updating the CMP-related parts of the YANG module exactly as discussed. Regarding the minor extension to the example in section 2.2, likely the outcome of our discussion was a bit unclear. We agreed that the new CMP profile does not need to be referenced there. Yet what we still suggest to do is to extend the paragraph The SZTP-server responds with "onboarding-information" (encoded inside the "conveyed-information" node) containing a signed identity certificate for the CSR provided by the SZTP-client: as follows: The SZTP-server validates the origin of the CSR and on success forwards it to a backend server, which may be an RA or CA.The backend servermust accept only legitimate CSRs approved by the SZTP-server. Upon receiving a new identity certificate from the backend server, the SZTP-server responds with "onboarding-information" (encoded inside the "conveyed-information" node) containing the identity certificate for the CSR provided by the SZTP-client: Regards,     David On 16.08.21 04:02, Kent Watsen wrote: > Hi Rob, > > The -06 update addresses: > - Your AD Review comments. > - The request from the ANIMA WG to factor out some groupings. > - An update to the description statement for the “cmc-csr” and > “cmp-csr” nodes prompted by Security experts. > - A number of editorial items. > > The -07 update fixes an item spotted when looking at the -06 “diff”. > > I believe all the issues have now been resolved. > > Kent // as co-author > > >> On Aug 15, 2021, at 9:38 PM, internet-drafts@ietf.org wrote: >> >> >> A new version of I-D, draft-ietf-netconf-sztp-csr-06.txt >> has been successfully submitted by Kent Watsen and posted to the >> IETF repository. >> >> Name: draft-ietf-netconf-sztp-csr >> Revision: 06 >> Title: Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request >> Document date: 2021-08-15 >> Group: netconf >> Pages: 34 >> URL: ... >> >> 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 Secretariat --------------829B1B0941CE38B53344467C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Kent et al,

thanks for your message regarding the update to the draft and for
updating the CMP-related parts of the YANG module exactly as discussed.

Regarding the minor extension to the example in section 2.2, likely the outcome of
our discussion was a bit unclear.
We agreed that the new CMP profile does not need to be referenced there.
Yet what we still suggest to do is to extend the paragraph

The SZTP-server responds with "onboarding-information" (encoded
inside the "conveyed-information" node) containing a signed identity
certificate for the CSR provided by the SZTP-client:

as follows:

The SZTP-server validates the origin of the CSR and on success
forwards it to a backend server, which may be an RA or CA. The backend
server must accept only legitimate CSRs approved by the SZTP-server.
Upon receiving a new identity certificate from the backend server,
the SZTP-server responds with "onboarding-information" (encoded
inside the "conveyed-information" node) containing the identity
certificate for the CSR provided by the SZTP-client:

Regards,

    David

On 16.08.21 04:02, Kent Watsen wrote:
Hi Rob,

The -06 update addresses:
  - Your AD Review comments.
  - The request from the ANIMA WG to factor out some groupings.
  - An update to the description statement for the “cmc-csr” and
    “cmp-csr” nodes prompted by Security experts.
  - A number of editorial items.

The -07 update fixes an item spotted when looking at the -06 “diff”.

I believe all the issues have now been resolved.

Kent // as co-author



On Aug 15, 2021, at 9:38 PM, internet-drafts@ietf.org wrote:


A new version of I-D, draft-ietf-netconf-sztp-csr-06.txt
has been successfully submitted by Kent Watsen and posted to the
IETF repository.

Name:		draft-ietf-netconf-sztp-csr
Revision:	06
Title:		Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request
Document date:	2021-08-15
Group:		netconf
Pages:		34
URL:            ...

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 Secretariat
--------------829B1B0941CE38B53344467C-- From nobody Tue Aug 17 04:36:57 2021 Return-Path: <0100017b53e64e86-e8ac5ed0-6dbe-4048-8454-d3b9115f1879-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 2445B3A103F; Tue, 17 Aug 2021 04:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1NHkDl5mwWc; Tue, 17 Aug 2021 04:36:49 -0700 (PDT) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D216F3A1034; Tue, 17 Aug 2021 04:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1629200207; h=Content-Type:Content-Transfer-Encoding:From:Mime-Version:Subject:Date:Message-Id:References:Cc:In-Reply-To:To:Feedback-ID; bh=XaGAIzHWGwLT9vylL92pKa2GJSlYI8hCgk3yzsK7xsM=; b=CX+9h69Nr265MYkygaAQAI/aHdPEneY6b/Kf+DaO135szowDc2tMeEEQJ9eaOwJH E+5cKEoV+YMHo9nkHMpMYirzHUfUfgQ3tR4A+WI7xl4t9Ntn2tCV+5eOnLpc5ZgH8A9 C+XXSRW80Kp2RuGonqg/+o1c2ec0SCS9WJdfktMw= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Kent Watsen Mime-Version: 1.0 (1.0) Date: Tue, 17 Aug 2021 11:36:47 +0000 Message-ID: <0100017b53e64e86-e8ac5ed0-6dbe-4048-8454-d3b9115f1879-000000@email.amazonses.com> References: <732deac48bb04780b8e144f99eac7a2c@huawei.com> Cc: draft-tao-netconf-data-export-capabilities@ietf.org, draft-claise-netconf-metadata-for-collection@ietf.org, draft-wang-netconf-adaptive-subscription@ietf.org, netconf@ietf.org In-Reply-To: <732deac48bb04780b8e144f99eac7a2c@huawei.com> To: "maqiufang (A)" X-Mailer: iPhone Mail (18F72) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.08.17-54.240.8.31 Archived-At: Subject: Re: [netconf] Overview of the various "capabilities" drafts 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, 17 Aug 2021 11:36:56 -0000 One quick response, would it be okay for me to CC the list on a bigger respo= nse later? - as this is exactly the kind of conversation I was hoping to h= appen there=E2=80=A6 K.=20 Sent from my iPhone > On Aug 17, 2021, at 12:07 AM, maqiufang (A) wrote:= >=20 > =EF=BB=BFHi, Kent, all > As a coauthor of data-export-capabilities and adaptive-subscription draft:= >=20 > 1. I would like to clarify that adaptive-subscription augments the "update= -trigger" choice defined in "ietf-yang-push" module(RFC 8641). Although it a= lso provides an optimum data collection mechanism, this draft doesn't advoca= te the capabilities exposure, but provides another way of subscription trigg= er in addition to periodic and on-change subscription. > It allows a publisher to switch to different period intervals automaticall= y according to the xpath evaluation results. > The adaptive-subscription related capabilities is discovered through adapt= ive-interval-support parameter defined in draft-tao-netconf-data-export-capa= bilities, but it does not need to depend on the data export capability if th= e client has heuristic knowledge about the server supports multiple update i= nterval. > So I think maybe adaptive-subscription should be excluded from our "capabi= lities discussion". >=20 > 2. Draft-claise-netconf-metadata-for-collection augments "system-capabilit= ies" data model and provides per-node metadata information for optimum data= collection. I think it is designed for service assurance use case defined i= n I-D.ietf-opsawg-service-assurance-yang but could also be applied to other t= elemetry use cases; > And draft-tao-netconf-data-export-capabilities augments "system-capabiliti= es" data model to provide transport specific system-level capabilities and s= ome per-node support capabilities(such as message-bundling-support, adaptive= -interval-support, etc). It is designed for YANG push use case, adaptive sub= scription use case, UDP-notif use case and message bundling use case. >=20 > 3. Regarding compliment and/or overlap of data-export-capabilities and met= adata-for-collection, I think it would be good to combine these two drafts a= nd we can also review if there are any other capabilities needed to support t= he closed-loop automation beyond ones already defined in this two drafts. > after thinking about it, I think there are 3 combination options: > Option A: Merge data export capability draft and meta data collection draf= t into one but still define two different models, one for data export, one f= or metadata collection > Pro: Scope for "system-capability" extension is clear > Option B: Merge data export capability draft and meta data collection draf= t into one, consolidate data export capability model into meta data collecti= on model > Con: Scope for "system-capability" extension is not clea= r since different system capabilities are mixed together. > Option C: Keep two drafts separate, move some of metadata related per-node= parameters(message-bundling-support, adaptive-interval-support, etc) from d= ata export draft to meta data collection draft, and keep the transport speci= fic parameters(transport-protocol, encoding-format, etc) in the data-export-= capabilities draft. > Pro: Scope for both per-node metadata capability and tran= sport specific system-level capability are clear >=20 > Any thoughts? >=20 >=20 > Best Regards, > Qiufang Ma >=20 > -----Original Message----- > From: Kent Watsen [mailto:kent+ietf@watsen.net]=20 > Sent: Tuesday, August 10, 2021 7:30 AM > To: draft-tao-netconf-data-export-capabilities@ietf.org; draft-claise-netc= onf-metadata-for-collection@ietf.org; draft-wang-netconf-adaptive-subscripti= on@ietf.org > Cc: netconf@ietf.org > Subject: Overview of the various "capabilities" drafts >=20 > Draft-authors in the =E2=80=9CTo=E2=80=9D line, >=20 > During the 111 session I made the statement that all these drafts are augm= enting the new =E2=80=9Csystem capabilities=E2=80=9D data tree and wondered t= o what extent these efforts compliment and/or overlap each other. Could you= please discuss this? >=20 > Kent (no hat) >=20 >=20 From nobody Tue Aug 17 04:41:58 2021 Return-Path: <0100017b53ea9cc2-637ab356-0113-45c8-b000-24a4662cbbfb-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 08A713A11BA; Tue, 17 Aug 2021 04:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0odCzS95L8O; Tue, 17 Aug 2021 04:41:31 -0700 (PDT) Received: from a48-93.smtp-out.amazonses.com (a48-93.smtp-out.amazonses.com [54.240.48.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC4083A11A7; Tue, 17 Aug 2021 04:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1629200489; h=Content-Type:Content-Transfer-Encoding:From:Mime-Version:Subject:Date:Message-Id:References:Cc:In-Reply-To:To:Feedback-ID; bh=UuPuhYDAiV5EfPAH6HNQ2thAjGRQEvcLAu0P5pIls3c=; b=LI3as4XIDljb/Ya0jfY7vadVxQU6JuJBaK091U2bKUDrRxMfZcWJamv/kK8qn9/H zEVJorWJp7UeHmFJF0/yB0jnPboLVcYgKo8leI7gKhKXUtMXk9Uz1QRUxl6YsjaAbmk FIAPARO0g/Hc+nL16c3uoJyQCgd64COL3UeZXJHs= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Kent Watsen Mime-Version: 1.0 (1.0) Date: Tue, 17 Aug 2021 11:41:29 +0000 Message-ID: <0100017b53ea9cc2-637ab356-0113-45c8-b000-24a4662cbbfb-000000@email.amazonses.com> References: <0100017b53e64e86-e8ac5ed0-6dbe-4048-8454-d3b9115f1879-000000@email.amazonses.com> Cc: draft-tao-netconf-data-export-capabilities@ietf.org, draft-claise-netconf-metadata-for-collection@ietf.org, netconf@ietf.org, draft-wang-netconf-adaptive-subscription@ietf.org In-Reply-To: <0100017b53e64e86-e8ac5ed0-6dbe-4048-8454-d3b9115f1879-000000@email.amazonses.com> To: "maqiufang (A)" X-Mailer: iPhone Mail (18F72) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.08.17-54.240.48.93 Archived-At: Subject: Re: [netconf] Overview of the various "capabilities" drafts 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, 17 Aug 2021 11:41:56 -0000 Ooops, it appears that I need to drink coffee before using email first thing= in the morning ;) > On Aug 17, 2021, at 7:43 AM, Kent Watsen wrote: >=20 > =EF=BB=BFOne quick response, would it be okay for me to CC the list on a b= igger response later? - as this is exactly the kind of conversation I was h= oping to happen there=E2=80=A6 >=20 > K.=20 >=20 > Sent from my iPhone >=20 >> On Aug 17, 2021, at 12:07 AM, maqiufang (A) wrote= : >>=20 >> =EF=BB=BFHi, Kent, all >> As a coauthor of data-export-capabilities and adaptive-subscription draft= : >>=20 >> 1. I would like to clarify that adaptive-subscription augments the "updat= e-trigger" choice defined in "ietf-yang-push" module(RFC 8641). Although it a= lso provides an optimum data collection mechanism, this draft doesn't advoca= te the capabilities exposure, but provides another way of subscription trigg= er in addition to periodic and on-change subscription. >> It allows a publisher to switch to different period intervals automatical= ly according to the xpath evaluation results. >> The adaptive-subscription related capabilities is discovered through adap= tive-interval-support parameter defined in draft-tao-netconf-data-export-cap= abilities, but it does not need to depend on the data export capability if t= he client has heuristic knowledge about the server supports multiple update i= nterval. >> So I think maybe adaptive-subscription should be excluded from our "capab= ilities discussion". >>=20 >> 2. Draft-claise-netconf-metadata-for-collection augments "system-capabili= ties" data model and provides per-node metadata information for optimum dat= a collection. I think it is designed for service assurance use case defined i= n I-D.ietf-opsawg-service-assurance-yang but could also be applied to other t= elemetry use cases; >> And draft-tao-netconf-data-export-capabilities augments "system-capabilit= ies" data model to provide transport specific system-level capabilities and s= ome per-node support capabilities(such as message-bundling-support, adaptive= -interval-support, etc). It is designed for YANG push use case, adaptive sub= scription use case, UDP-notif use case and message bundling use case. >>=20 >> 3. Regarding compliment and/or overlap of data-export-capabilities and me= tadata-for-collection, I think it would be good to combine these two drafts a= nd we can also review if there are any other capabilities needed to support t= he closed-loop automation beyond ones already defined in this two drafts. >> after thinking about it, I think there are 3 combination options: >> Option A: Merge data export capability draft and meta data collection dra= ft into one but still define two different models, one for data export, one f= or metadata collection >> Pro: Scope for "system-capability" extension is clear >> Option B: Merge data export capability draft and meta data collection dra= ft into one, consolidate data export capability model into meta data collect= ion model >> Con: Scope for "system-capability" extension is not clea= r since different system capabilities are mixed together. >> Option C: Keep two drafts separate, move some of metadata related per-nod= e parameters(message-bundling-support, adaptive-interval-support, etc) from d= ata export draft to meta data collection draft, and keep the transport speci= fic parameters(transport-protocol, encoding-format, etc) in the data-export-= capabilities draft. >> Pro: Scope for both per-node metadata capability and tran= sport specific system-level capability are clear >>=20 >> Any thoughts? >>=20 >>=20 >> Best Regards, >> Qiufang Ma >>=20 >> -----Original Message----- >> From: Kent Watsen [mailto:kent+ietf@watsen.net]=20 >> Sent: Tuesday, August 10, 2021 7:30 AM >> To: draft-tao-netconf-data-export-capabilities@ietf.org; draft-claise-net= conf-metadata-for-collection@ietf.org; draft-wang-netconf-adaptive-subscript= ion@ietf.org >> Cc: netconf@ietf.org >> Subject: Overview of the various "capabilities" drafts >>=20 >> Draft-authors in the =E2=80=9CTo=E2=80=9D line, >>=20 >> During the 111 session I made the statement that all these drafts are aug= menting the new =E2=80=9Csystem capabilities=E2=80=9D data tree and wondered= to what extent these efforts compliment and/or overlap each other. Could y= ou please discuss this? >>=20 >> Kent (no hat) >>=20 >>=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Aug 17 10:16:55 2021 Return-Path: <0100017b551d703e-ea44f163-2ab5-40c3-9edc-c0eb41620172-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 8FCE93A2359; Tue, 17 Aug 2021 10:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kml1J4PecIlq; Tue, 17 Aug 2021 10:16:39 -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 3BF8F3A2331; Tue, 17 Aug 2021 10:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1629220598; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=l6N7oHIE+rs5Pz+Nqvdhf2Fj1ASQ6Jhs9MxH55BJ5wk=; b=Z379lilih/EqulVoGUZJuUoxulFO/HMMyEUswDlXM/PzhHY+UYnI4H/COYyvDnag wM+NIcc8NRP8Ir5zm7d3pK6gIcc0adcnD//6EPPiZqRB1rZGAy1nZ17Gior/TrkTqbg IS1rM4wtQTdxwB1A10ZDnE3wR10XfSewJ/o2rxQU= From: Kent Watsen Message-ID: <0100017b551d703e-ea44f163-2ab5-40c3-9edc-c0eb41620172-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_369C8192-E56F-4AF2-8A3A-FD724785E53F" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Tue, 17 Aug 2021 17:16:37 +0000 In-Reply-To: <6247a309-c24d-041b-704c-2ddf8b372d00@siemens.com> 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> X-Mailer: Apple Mail (2.3654.100.0.2.22) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.08.17-54.240.8.33 Archived-At: Subject: Re: [netconf] New Version Notification for draft-ietf-netconf-sztp-csr-06.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: Tue, 17 Aug 2021 17:16:53 -0000 --Apple-Mail=_369C8192-E56F-4AF2-8A3A-FD724785E53F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi David, > thanks for your message regarding the update to the draft and for > updating the CMP-related parts of the YANG module exactly as = discussed. >=20 Not *exact*, as Sean tweaked CMC Case 2 (removing the controlSequence = restriction and adding a new final sentence) and CMC Case 3 (removing = the controlSequence restriction X2). > Regarding the minor extension to the example in section 2.2, likely = the outcome of > our discussion was a bit unclear. > We agreed that the new CMP profile does not need to be referenced = there.=20 > Yet what we still suggest to do is to extend the paragraph >=20 > The SZTP-server responds with "onboarding-information" (encoded > inside the "conveyed-information" node) containing a signed identity > certificate for the CSR provided by the SZTP-client: >=20 > as follows: >=20 > The SZTP-server validates the origin of the CSR and on success=20 > forwards it to a backend server, which may be an RA or CA. The backend > server must accept only legitimate CSRs approved by the SZTP-server. > Upon receiving a new identity certificate from the backend server, > the SZTP-server responds with "onboarding-information" (encoded > inside the "conveyed-information" node) containing the identity > certificate for the CSR provided by the SZTP-client: >=20 I=E2=80=99m unsure if this is a good addition because nowhere, except in = the Security Considerations section, is there any discussion about a = backend CA. Of course it is the most likely scenario, but it could also = be the case that the CA has the SZTP-server functionality embedded. =20 Additionally, whilst not a bad idea for the SZTP-server to validate the = CSR, it seems even more important that the CA be able to do so without = taking the SZTP-server=E2=80=99s word for it - right? Note: = https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-07#secti= on-4.2.1 = . PS: currently the draft just says =E2=80=9CCA=E2=80=9D. Do you think it = should say =E2=80=9CCA or RA=E2=80=9D instead? Thanks, Kent --Apple-Mail=_369C8192-E56F-4AF2-8A3A-FD724785E53F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = David,

thanks for your = message regarding the update to the draft and for
updating the CMP-related parts of the YANG module exactly as discussed.

Not *exact*, as Sean = tweaked CMC Case 2 (removing the controlSequence restriction and adding = a new final sentence) and CMC Case 3 (removing the controlSequence = restriction X2).

Regarding the minor extension to the example in = section 2.2, likely the outcome of
our discussion was a bit unclear.
We agreed that the new CMP profile does not need to be referenced there.
Yet what we still suggest to do is to extend the paragraph

The SZTP-server responds with "onboarding-information" (encoded
inside the "conveyed-information" node) containing a signed identity
certificate for the CSR provided by the SZTP-client:

as follows:

The SZTP-server validates the origin of the CSR and on success
forwards it to a backend server, which may be = an RA or CA. The backend
server must accept only legitimate CSRs approved by the SZTP-server.
Upon receiving a new identity certificate from the backend server,
the SZTP-server responds with "onboarding-information" (encoded
inside the "conveyed-information" node) containing the identity
certificate for the CSR provided by the SZTP-client:


I=E2=80=99m unsure if this is a good = addition because nowhere, except in the Security Considerations section, = is there any discussion about a backend CA.  Of course it is the = most likely scenario, but it could also be the case that the CA has the = SZTP-server functionality embedded.  

Additionally, whilst not a bad idea for = the SZTP-server to validate the CSR, it seems even more important that = the CA be able to do so without taking the SZTP-server=E2=80=99s word = for it - right?   Note: https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-c= sr-07#section-4.2.1.

PS: currently the draft just says =E2=80=9CCA=E2=80=9D. =  Do you think it should say =E2=80=9CCA or RA=E2=80=9D = instead?

Thanks,
Kent


= --Apple-Mail=_369C8192-E56F-4AF2-8A3A-FD724785E53F-- From nobody Tue Aug 17 10:54:19 2021 Return-Path: <0100017b553fcdf9-cc45a73a-81f6-41a5-8ebf-c272755d2cb5-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 311883A2491; Tue, 17 Aug 2021 10:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8q238pIdd7Ce; Tue, 17 Aug 2021 10:54:12 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FDC43A248D; Tue, 17 Aug 2021 10:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1629222850; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=p+JemCrGnLJWLt7MuC5v39UE6ujp6gRrqkhfeZ1IHqM=; b=M8gzGUizHsMGpYXeE1j//nAmCwyr6cFb0cr9mC29gEQtxKSklG/NKOyAgPnusf1N Vywof5nIU3FpUOTEbetK/vojmfxd4NHvKm99gZCSANZfCHBevEh2q6+VqucvgYjjSoP PBO7uBcxe+1JoFu6JrXOklPEQHg0h7htG0h9GRb4= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Kent Watsen In-Reply-To: <732deac48bb04780b8e144f99eac7a2c@huawei.com> Date: Tue, 17 Aug 2021 17:54:10 +0000 Cc: "draft-tao-netconf-data-export-capabilities@ietf.org" , "draft-claise-netconf-metadata-for-collection@ietf.org" , "draft-wang-netconf-adaptive-subscription@ietf.org" , "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <0100017b553fcdf9-cc45a73a-81f6-41a5-8ebf-c272755d2cb5-000000@email.amazonses.com> References: <732deac48bb04780b8e144f99eac7a2c@huawei.com> To: "maqiufang (A)" X-Mailer: Apple Mail (2.3654.100.0.2.22) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.08.17-54.240.8.88 Archived-At: Subject: Re: [netconf] Overview of the various "capabilities" drafts 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, 17 Aug 2021 17:54:17 -0000 Hi Qiufang, > Hi, Kent, all > As a coauthor of data-export-capabilities and adaptive-subscription = draft: >=20 > 1. I would like to clarify that adaptive-subscription augments the = "update-trigger" choice defined in "ietf-yang-push" module(RFC 8641). = Although it also provides an optimum data collection mechanism, this = draft doesn't advocate the capabilities exposure, but provides another = way of subscription trigger in addition to periodic and on-change = subscription. > It allows a publisher to switch to different period intervals = automatically according to the xpath evaluation results. > The adaptive-subscription related capabilities is discovered through = adaptive-interval-support parameter defined in = draft-tao-netconf-data-export-capabilities, but it does not need to = depend on the data export capability if the client has heuristic = knowledge about the server supports multiple update interval. > So I think maybe adaptive-subscription should be excluded from our = "capabilities discussion". Okay. And thank-you for the great explanation. > 2. Draft-claise-netconf-metadata-for-collection augments = "system-capabilities" data model and provides per-node metadata = information for optimum data collection. I think it is designed for = service assurance use case defined in = I-D.ietf-opsawg-service-assurance-yang but could also be applied to = other telemetry use cases; > And draft-tao-netconf-data-export-capabilities augments = "system-capabilities" data model to provide transport specific = system-level capabilities and some per-node support capabilities(such as = message-bundling-support, adaptive-interval-support, etc). It is = designed for YANG push use case, adaptive subscription use case, = UDP-notif use case and message bundling use case. So maybe some overlap=E2=80=A6 > 3. Regarding compliment and/or overlap of data-export-capabilities and = metadata-for-collection, I think it would be good to combine these two = drafts and we can also review if there are any other capabilities needed = to support the closed-loop automation beyond ones already defined in = this two drafts. > after thinking about it, I think there are 3 combination options: > Option A: Merge data export capability draft and meta data collection = draft into one but still define two different models, one for data = export, one for metadata collection > Pro: Scope for "system-capability" extension is = clear > Option B: Merge data export capability draft and meta data collection = draft into one, consolidate data export capability model into meta data = collection model > Con: Scope for "system-capability" extension is not = clear since different system capabilities are mixed together. > Option C: Keep two drafts separate, move some of metadata related = per-node parameters(message-bundling-support, adaptive-interval-support, = etc) from data export draft to meta data collection draft, and keep the = transport specific parameters(transport-protocol, encoding-format, etc) = in the data-export-capabilities draft. > Pro: Scope for both per-node metadata capability and = transport specific system-level capability are clear >=20 > Any thoughts? Also: D. Merge data export capability draft and meta data collection draft = into one and move some of metadata related per-node = parameters(message-bundling-support, adaptive-interval-support, etc) = from data export model to meta data collection model, and keep the = transport specific parameters(transport-protocol, encoding-format, etc) = in the data-export-capabilities model. =E2=80=98D=E2=80=99 is a combination of =E2=80=98A=E2=80=99 and = =E2=80=98C=E2=80=99=E2=80=A6does it mean we'd get the best (the Pro=E2=80=99= s) from both? I hope that the authors of the =E2=80=9Cmetadata-for-collection" draft = will chime in. > Best Regards, > Qiufang Ma Thanks, Kent From nobody Tue Aug 17 23:17: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 D196C3A12CE; Tue, 17 Aug 2021 23:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=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 bCJVIXQl3e1d; Tue, 17 Aug 2021 23:17:29 -0700 (PDT) Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) (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 1070D3A12C6; Tue, 17 Aug 2021 23:17:28 -0700 (PDT) Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id 17I6HLsh027887 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 18 Aug 2021 08:17:21 +0200 Received: from [139.22.33.193] ([139.22.33.193]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 17I6HJSD017061; Wed, 18 Aug 2021 08:17:19 +0200 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> From: David von Oheimb Message-ID: Date: Wed, 18 Aug 2021 08:17:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <0100017b551d703e-ea44f163-2ab5-40c3-9edc-c0eb41620172-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="------------59B3EEDB7348CD18C58AE9FD" Content-Language: en-US Archived-At: Subject: Re: [netconf] New Version Notification for draft-ietf-netconf-sztp-csr-06.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, 18 Aug 2021 06:17:35 -0000 This is a multi-part message in MIME format. --------------59B3EEDB7348CD18C58AE9FD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Kent, >> thanks for your message regarding the update to the draft and for >> updating the CMP-related parts of the YANG module exactly as discussed. >> > Not *exact*, as Sean tweaked CMC Case 2 (removing the controlSequence > restriction and adding a new final sentence) and CMC Case 3 (removing > the controlSequence restriction X2). I did not have a look at other portions of the draft, such as those you mention here regarding CMC. Our focus is CMP. >> Regarding the minor extension to the example in section 2.2, likely >> the outcome of >> our discussion was a bit unclear. >> We agreed that the new CMP profile does not need to be referenced there. >> Yet what we still suggest to do is to extend the paragraph >> >> The SZTP-server responds with "onboarding-information" (encoded >> inside the "conveyed-information" node) containing a signed identity >> certificate for the CSR provided by the SZTP-client: >> >> as follows: >> >> The SZTP-server validates the origin of the CSR and on success >> forwards it to a backend server, which may be an RA or CA.The backend >> servermust accept only legitimate CSRs approved by the SZTP-server. >> Upon receiving a new identity certificate from the backend server, >> the SZTP-server responds with "onboarding-information" (encoded >> inside the "conveyed-information" node) containing the identity >> certificate for the CSR provided by the SZTP-client: >> > > I’m unsure if this is a good addition because nowhere, except in the > Security Considerations section, is there any discussion about a > backend CA. > Of course it is the most likely scenario, but it could also be the > case that the CA has the SZTP-server functionality embedded. That's right. Though one could argue that the text in section 2.2 is "just" on example usage, here is a generalization: After the origin of the CSR and the included proof-of-possession have been validated successfully and the CSR has been approved, the SZTP-server responds with "onboarding-information" (encoded inside the "conveyed-information" node) containing the identity certificate for the CSR provided by the SZTP-client: > > Additionally, whilst not a bad idea for the SZTP-server to validate > the CSR, it seems even more important that the CA be able to do so > without taking the SZTP-server’s word for it - right?   > Note: https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-07#section-4.2.1 > . > > PS: currently the draft just says “CA”.  Do you think it should say > “CA or RA” instead? Good point that the checks should be mentioned (also) in the security considerations, and indeed just mentioning "CA" is not general enough. Here is a couple of suggested text improvements: 4.1.5 . Selecting the Best Origin Authentication Mechanism old:  When generating a new key, it is important that the client be able to provide additional proof to the CA that it was the entity that generated the key. new:  When generating a new key, it is important that the client be able to provide additional proof that it was the entity that generated the key. This should be verified successfully before issuing the certificate. old: 4.2.1 . Conveying Proof of Possession to a CA new: 4.2.1 . Conveying Proof of Possession old: When the bootstrapping device's manufacturer-generated private key (e.g., the IDevID key) is reused, a CA may validate that the CSR was signed by that key. new: When the bootstrapping device's manufacturer-generated private key (e.g., the IDevID key) is reused, verifying the proof-of-possession validates that the CSR was signed by that key. old:  Both the CMP and CMC formats entail the bootstrapping device signing the request once with its (e.g., LDevID) key and then again with its (e.g., IDevID) key, which enables a downstream CA to be assured that the bootstrapping device possesses the public key being signed. new:  Both the CMP and CMC formats entail that the bootstrapping device signs the request once with its (e.g., LDevID) key and then again with its (e.g., IDevID) key. This enables verifying the proof-of-possession of the private key that corresponds to the public key being signed.     David --------------59B3EEDB7348CD18C58AE9FD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Kent,

thanks for your message regarding the update to the draft and for
updating the CMP-related parts of the YANG module exactly as discussed.

Not *exact*, as Sean tweaked CMC Case 2 (removing the controlSequence restriction and adding a new final sentence) and CMC Case 3 (removing the controlSequence restriction X2).

I did not have a look at other portions of the draft, such as those you mention here regarding CMC. Our focus is CMP.


Regarding the minor extension to the example in section 2.2, likely the outcome of
our discussion was a bit unclear.
We agreed that the new CMP profile does not need to be referenced there.
Yet what we still suggest to do is to extend the paragraph

The SZTP-server responds with "onboarding-information" (encoded
inside the "conveyed-information" node) containing a signed identity
certificate for the CSR provided by the SZTP-client:

as follows:

The SZTP-server validates the origin of the CSR and on success
forwards it to a backend server, which may be an RA or CA. The backend
server must accept only legitimate CSRs approved by the SZTP-server.
Upon receiving a new identity certificate from the backend server,
the SZTP-server responds with "onboarding-information" (encoded
inside the "conveyed-information" node) containing the identity
certificate for the CSR provided by the SZTP-client:


I’m unsure if this is a good addition because nowhere, except in the Security Considerations section, is there any discussion about a backend CA.
Of course it is the most likely scenario, but it could also be the case that the CA has the SZTP-server functionality embedded.

That's right. Though one could argue that the text in section 2.2 is "just" on example usage, here is a generalization:

After the origin of the CSR and the included proof-of-possession
have been validated successfully and the CSR has been approved,
the SZTP-server responds with "onboarding-information" (encoded
inside the "conveyed-information" node) containing the identity
certificate for the CSR provided by the SZTP-client:



Additionally, whilst not a bad idea for the SZTP-server to validate the CSR, it seems even more important that the CA be able to do so without taking the SZTP-server’s word for it - right?   Note: https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-07#section-4.2.1.

PS: currently the draft just says “CA”.  Do you think it should say “CA or RA” instead?

Good point that the checks should be mentioned (also) in the security considerations,
and indeed just mentioning "CA" is not general enough.

Here is a couple of suggested text improvements:

4.1.5.  Selecting the Best Origin Authentication Mechanism

old:

   When generating a new key, it is important that the client be able to
   provide additional proof to the CA that it was the entity that
   generated the key.

new:

   When generating a new key, it is important that the client be able to
   provide additional proof that it was the entity that generated the key.
   This should be verified successfully before issuing the certificate.

old:

4.2.1.  Conveying Proof of Possession to a CA

new:

4.2.1.  Conveying Proof of Possession

old:

   When the bootstrapping device's manufacturer-generated private key
   (e.g., the IDevID key) is reused, a CA may validate that the CSR was
   signed by that key.

new:

   When the bootstrapping device's manufacturer-generated private key
   (e.g., the IDevID key) is reused, verifying the proof-of-possession
   validates that the CSR was signed by that key.

old:

   Both the CMP and CMC formats entail the bootstrapping device signing
   the request once with its (e.g., LDevID) key and then again with its
   (e.g., IDevID) key, which enables a downstream CA to be assured that
   the bootstrapping device possesses the public key being signed.

new:

   Both the CMP and CMC formats entail that the bootstrapping device signs
   the request once with its (e.g., LDevID) key and then again with its
   (e.g., IDevID) key. This enables verifying the proof-of-possession
   of the private key that corresponds to the public key being signed.

    David


--------------59B3EEDB7348CD18C58AE9FD-- From nobody Tue Aug 24 07:48:42 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 E03503A153A; Tue, 24 Aug 2021 07:48:39 -0700 (PDT) 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.36.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <162981651984.1252.6072215432278728864@ietfa.amsl.com> Date: Tue, 24 Aug 2021 07:48:39 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-sztp-csr-08.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: Tue, 24 Aug 2021 14:48:40 -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-08.txt Pages : 34 Date : 2021-08-24 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-08.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-sztp-csr-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 24 07:54:09 2021 Return-Path: <0100017b78a75ff9-6506e24d-20c5-4bd7-83a4-0e7472cdfc6e-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 5F2C83A15E3; Tue, 24 Aug 2021 07:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 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.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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=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 sC5om3Giestb; Tue, 24 Aug 2021 07:54:02 -0700 (PDT) Received: from a48-93.smtp-out.amazonses.com (a48-93.smtp-out.amazonses.com [54.240.48.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F8D53A15DB; Tue, 24 Aug 2021 07:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1629816840; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=s8MQNVRZ7Yr0mGVHOSxPA2pE2QIC+YjhT4n+XhNi1lM=; b=ARaQ05pwAMvyzQoAgNY2j8jKe2fXUfd33bU+mx0o5QK2MHYnD2t1asHPVwpkiOD1 BGKWCa+cxJGVFMxaffg6n5bNWPtfI9Po7D9j+AZ64KWWky8i0qIb7ecHYAsCv9Fvjvt iihwDDNJdjXZu0sDfsv6+KyZb3fuvBOLKKJLLI6s= From: Kent Watsen Message-ID: <0100017b78a75ff9-6506e24d-20c5-4bd7-83a4-0e7472cdfc6e-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_37E49B7D-2556-4B28-9900-DA8E905AB663" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 24 Aug 2021 14:54:00 +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> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.08.24-54.240.48.93 Archived-At: Subject: Re: [netconf] New Version Notification for draft-ietf-netconf-sztp-csr-06.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: Tue, 24 Aug 2021 14:54:08 -0000 --Apple-Mail=_37E49B7D-2556-4B28-9900-DA8E905AB663 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi David, I took all your suggestions into account. I reworded things so, please = review the diffs. Here=E2=80=99s the direct link to the diffs: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-sztp-csr-08.txt = Thanks again, Kent > On Aug 18, 2021, at 2:17 AM, David von Oheimb = wrote: >=20 > Hi Kent, >=20 >>> thanks for your message regarding the update to the draft and for >>> updating the CMP-related parts of the YANG module exactly as = discussed. >>>=20 >> Not *exact*, as Sean tweaked CMC Case 2 (removing the controlSequence = restriction and adding a new final sentence) and CMC Case 3 (removing = the controlSequence restriction X2). > I did not have a look at other portions of the draft, such as those = you mention here regarding CMC. Our focus is CMP. >=20 >=20 >=20 >>> Regarding the minor extension to the example in section 2.2, likely = the outcome of >>> our discussion was a bit unclear. >>> We agreed that the new CMP profile does not need to be referenced = there.=20 >>> Yet what we still suggest to do is to extend the paragraph >>>=20 >>> The SZTP-server responds with "onboarding-information" (encoded >>> inside the "conveyed-information" node) containing a signed identity >>> certificate for the CSR provided by the SZTP-client: >>>=20 >>> as follows: >>>=20 >>> The SZTP-server validates the origin of the CSR and on success=20 >>> forwards it to a backend server, which may be an RA or CA. The = backend >>> server must accept only legitimate CSRs approved by the SZTP-server. >>> Upon receiving a new identity certificate from the backend server, >>> the SZTP-server responds with "onboarding-information" (encoded >>> inside the "conveyed-information" node) containing the identity >>> certificate for the CSR provided by the SZTP-client: >>>=20 >>=20 >> I=E2=80=99m unsure if this is a good addition because nowhere, except = in the Security Considerations section, is there any discussion about a = backend CA. >> Of course it is the most likely scenario, but it could also be the = case that the CA has the SZTP-server functionality embedded.=20 > That's right. Though one could argue that the text in section 2.2 is = "just" on example usage, here is a generalization: >=20 > After the origin of the CSR and the included proof-of-possession > have been validated successfully and the CSR has been approved, > the SZTP-server responds with "onboarding-information" (encoded > inside the "conveyed-information" node) containing the identity > certificate for the CSR provided by the SZTP-client: >=20 >=20 >=20 >>=20 >> Additionally, whilst not a bad idea for the SZTP-server to validate = the CSR, it seems even more important that the CA be able to do so = without taking the SZTP-server=E2=80=99s word for it - right? Note: = https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-07#secti= on-4.2.1 = . >>=20 >> PS: currently the draft just says =E2=80=9CCA=E2=80=9D. Do you think = it should say =E2=80=9CCA or RA=E2=80=9D instead? > Good point that the checks should be mentioned (also) in the security = considerations, > and indeed just mentioning "CA" is not general enough. >=20 > Here is a couple of suggested text improvements: >=20 > 4.1.5 = . Selecting the Best Origin Authentication Mechanism >=20 > old: >=20 > When generating a new key, it is important that the client be able = to > provide additional proof to the CA that it was the entity that > generated the key. >=20 > new: >=20 > When generating a new key, it is important that the client be able = to > provide additional proof that it was the entity that generated the = key. > This should be verified successfully before issuing the = certificate. >=20 > old: >=20 > 4.2.1 = . Conveying Proof of Possession to a CA >=20 > new: >=20 > 4.2.1 = . Conveying Proof of Possession > old: >=20 > When the bootstrapping device's manufacturer-generated private key > (e.g., the IDevID key) is reused, a CA may validate that the CSR = was > signed by that key. > new: >=20 > When the bootstrapping device's manufacturer-generated private key > (e.g., the IDevID key) is reused, verifying the proof-of-possession > validates that the CSR was signed by that key. > old: >=20 > Both the CMP and CMC formats entail the bootstrapping device = signing > the request once with its (e.g., LDevID) key and then again with = its > (e.g., IDevID) key, which enables a downstream CA to be assured = that > the bootstrapping device possesses the public key being signed. > new: >=20 > Both the CMP and CMC formats entail that the bootstrapping device = signs > the request once with its (e.g., LDevID) key and then again with = its > (e.g., IDevID) key. This enables verifying the proof-of-possession > of the private key that corresponds to the public key being signed. >=20 > David >=20 >=20 --Apple-Mail=_37E49B7D-2556-4B28-9900-DA8E905AB663 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = David,

I took = all your suggestions into account.   I reworded things so, = please review the diffs.  Here=E2=80=99s the direct link to = the diffs:

https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-sztp-csr= -08.txt

Thanks again,
Kent



On Aug 18, 2021, at 2:17 AM, David von Oheimb = <David.von.Oheimb@siemens.com> wrote:

=20 =20

Hi Kent,

thanks for your message = regarding the update to the draft and for
updating the CMP-related parts of the YANG module exactly as discussed.

Not *exact*, as Sean tweaked CMC Case 2 (removing the controlSequence restriction and adding a new final sentence) and CMC Case 3 (removing the controlSequence restriction = X2).

I did not have a look at other portions = of the draft, such as those you mention here regarding CMC. Our focus is CMP.


Regarding the minor = extension to the example in section 2.2, likely the outcome of
our discussion was a bit unclear.
We agreed that the new CMP profile does not need to be referenced there.
Yet what we still suggest to do is to extend the paragraph

The SZTP-server = responds with "onboarding-information" (encoded
inside the "conveyed-information" node) containing a signed identity
certificate for the CSR provided = by the SZTP-client:

as follows:

The SZTP-server validates the origin of the CSR and on success
forwards it to a backend server, which may be an RA or CA. = The backend
server must accept only legitimate CSRs approved by the SZTP-server.
Upon receiving a new identity certificate from the backend server,
the SZTP-server responds with "onboarding-information" (encoded
inside the "conveyed-information" node) containing the identity
certificate for the CSR provided = by the SZTP-client:


I=E2=80=99m unsure if this is a good addition = because nowhere, except in the Security Considerations section, is there any discussion about a backend CA.
Of course it is the most likely scenario, but it could also be the case that the CA has the SZTP-server functionality embedded.

That's right. Though one could argue that = the text in section 2.2 is "just" on example usage, here is a generalization:
=

After the origin of the CSR and the included proof-of-possession
have been validated successfully and the CSR has been approved,
the SZTP-server responds with "onboarding-information" = (encoded
inside the "conveyed-information" node) containing the identity
certificate for the CSR provided by the SZTP-client:



Additionally, whilst not a bad idea for the SZTP-server to validate the CSR, it seems even more important that the CA be able to do so without taking the SZTP-server=E2=80=99s word for it - right?   = Note: https://datatracker.ietf.org/doc/html/draft-ietf-= netconf-sztp-csr-07#section-4.2.1.

PS: currently the draft just says =E2=80=9CCA=E2= =80=9D.  Do you think it should say =E2=80=9CCA or RA=E2=80=9D = instead?

Good point that the checks should be = mentioned (also) in the security considerations,
and indeed just mentioning "CA" is not general enough.

Here is a couple of suggested text improvements:

4.1.5.  Selecting the Best Origin Authentication =
Mechanism

old:

   When generating a new key, it is =
important that the client be able to
   provide additional proof to the CA that it was the entity that
   generated the key.

new:

   When generating a new key, it is =
important that the client be able to
   provide additional proof that it was the entity that generated the =
key.
   This should be verified successfully before issuing the certificate.

old:

4.2.1.  Conveying Proof of Possession to a =
CA

new:

4.2.1.  Conveying Proof of Possession

old:

   When the bootstrapping device's =
manufacturer-generated private key
   (e.g., the IDevID key) is reused, a CA may validate that the CSR was
   signed by that key.

new:

   When the bootstrapping device's =
manufacturer-generated private key
   (e.g., the IDevID key) is reused, verifying the proof-of-possession
   validates that the CSR was signed by that key.

old:

   Both the CMP and CMC formats entail =
the bootstrapping device signing
   the request once with its (e.g., LDevID) key and then again with its
   (e.g., IDevID) key, which enables a downstream CA to be assured that
   the bootstrapping device possesses the public key being =
signed.

new:

   Both the CMP and CMC formats entail =
that the bootstrapping device signs
   the request once with its (e.g., LDevID) key and then again with its
   (e.g., IDevID) key. This enables verifying the proof-of-possession
   of the private key that corresponds to the public key being signed.

    David



= --Apple-Mail=_37E49B7D-2556-4B28-9900-DA8E905AB663-- From nobody Tue Aug 24 08:25:27 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 52F953A183B; Tue, 24 Aug 2021 08:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 KiKZ04AWFZwr; Tue, 24 Aug 2021 08:25:18 -0700 (PDT) Received: from gw-eagle1.siemens.com (gw-eagle1.siemens.com [194.138.20.72]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0DF03A180C; Tue, 24 Aug 2021 08:25:17 -0700 (PDT) Received: from mail2.dc4ca.siemens.de (mail2.dc4ca.siemens.de [139.25.224.94]) by gw-eagle1.siemens.com (Postfix) with ESMTPS id D0D6F4F00F6; Tue, 24 Aug 2021 17:25:15 +0200 (CEST) Received: from DEMCHDC89XA.ad011.siemens.net (demchdc89xa.ad011.siemens.net [139.25.226.103]) by mail2.dc4ca.siemens.de (Postfix) with ESMTPS id 6409E1A14CBBF; Tue, 24 Aug 2021 17:25:15 +0200 (CEST) Received: from DEMCHDC89XA.ad011.siemens.net (139.25.226.103) by DEMCHDC89XA.ad011.siemens.net (139.25.226.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14; Tue, 24 Aug 2021 17:25:14 +0200 Received: from DEMCHDC89XA.ad011.siemens.net ([139.25.226.103]) by DEMCHDC89XA.ad011.siemens.net ([139.25.226.103]) with mapi id 15.01.2308.014; Tue, 24 Aug 2021 17:25:14 +0200 From: "Fries, Steffen" To: "anima@ietf.org" , "netconf@ietf.org" Thread-Topic: CSR grouping introduced in draft-ietf-netconf-sztp-csr-06 Thread-Index: AdeY/DvkV0QLVanvTY+xf/bvIVpSAA== Date: Tue, 24 Aug 2021 15:25:14 +0000 Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2021-08-24T15:25:13Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=f970cbd7-b471-4e3c-a2c6-41e7e9f62df6; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted x-originating-ip: [139.25.108.54] x-tm-as-product-ver: SMEX-14.0.0.3080-8.6.1018-26366.000 x-tm-as-result: No-10--28.125200-8.000000 x-tmase-matchedrid: Dx1F0HKfCAM22uoEm245fojjTDpHKwYmhzv5Bvz7TekItCy6ZX/lL4IW SprjdsebAy6/bz1VsIjFQNPEve+5IPj696hz7L2ZZmGkOF0fx8wsS7de5tK9AWK3N9p/OFh6YUu Zn9VXZWFq5aiUaVUyIPfnaHkTI99QcOiL5ZrDbJIqhZrv4f7cO9BEpGpbfHw4nVTWWiNp+v/xAJ QLHjrob4hIjrzeyQMKucQiVAlY+hpzwb9qaRe4k025+PR9BbseJqzhr5uCxM85UYVNPDbxh+Jc6 hKWj0C1twi3bXRtaAiA2U4DoCTZiJhOpUvp2UlCJK3/o1QYFlSJL0uyuozT/TZoNXJMbH+n1ViV 5EWK7TubKItl61J/yc8943oc3p3s32mPO5tnasdtAbvuGw/Y7CjhHi0GqVX+wiOt5nuU237pz9n 91cknB+Tie0t89GVd x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No x-tmase-result: 10--28.125200-8.000000 x-tmase-version: SMEX-14.0.0.3080-8.6.1018-26366.000 x-tm-snts-smtp: 2D32CECBA5063E581AF70B3203AF0C123755215D7A7F1BA54A7284112008EC4B2000:8 Content-Type: multipart/alternative; boundary="_000_c9cd4eb49d6b4ba4b93f06a37c7b9664siemenscom_" MIME-Version: 1.0 Archived-At: Subject: [netconf] CSR grouping introduced in draft-ietf-netconf-sztp-csr-06 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, 24 Aug 2021 15:25:24 -0000 --_000_c9cd4eb49d6b4ba4b93f06a37c7b9664siemenscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kent, I just went over the changes regarding the csr-grouping (https://datatracke= r.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-08#section-3.2) you introdu= ced in draft-ietf-netconf-sztp-csr-06. To my understanding (I'm not too dee= p into YANG yet) the new grouping of the csr in the YANG module ietf-ztp-ty= pes can now be used directly. This should enable the direct application in BRSKI-AE, which we were lookin= g for to avoid double definition. Thanks for the incorporation. While we ar= e currently using only the PKCS#10 approach, the module provides also the o= ption to switch to cmp-csr or cmc-csr. So were are open also for other form= ats. Best regards Steffen -- Steffen Fries Siemens AG --_000_c9cd4eb49d6b4ba4b93f06a37c7b9664siemenscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kent,

 

I just went over the changes regarding the csr-group= ing (https://datatracker.ietf.org/doc/html/draft-ietf-net= conf-sztp-csr-08#section-3.2) you introduced in draft-ietf-netconf-sztp-csr-06. To my understanding (I’= ;m not too deep into YANG yet) the new grouping of the csr in the YANG modu= le ietf-ztp-types can now be used directly.

This should enable the direct application in BRSKI-A= E, which we were looking for to avoid double definition. Thanks for the inc= orporation. While we are currently using only the PKCS#10 approach, the mod= ule provides also the option to switch to cmp-csr or cmc-csr. So were are open also for other formats.  

 

Best regards

Steffen

--
Steffen Fries
Siemens AG

 

--_000_c9cd4eb49d6b4ba4b93f06a37c7b9664siemenscom_-- From nobody Tue Aug 24 11:29:50 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 DE4B53A0B00; Tue, 24 Aug 2021 11:29:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Valery Smyslov via Datatracker To: Cc: draft-ietf-netconf-crypto-types.all@ietf.org, last-call@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162982978380.3381.17549750696257276827@ietfa.amsl.com> Reply-To: Valery Smyslov Date: Tue, 24 Aug 2021 11:29:43 -0700 Archived-At: Subject: [netconf] Secdir last call review of draft-ietf-netconf-crypto-types-20 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, 24 Aug 2021 18:29:44 -0000 Reviewer: Valery Smyslov Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. When I was re-assigned to review this draft the indicated deadline was already missed by 8 months, so I don't know how relevant the review is. I reviewed the latest -20 version of the draft instead of -18, that was requested. The draft defines common YANG data types and groupings useful for cryptography. I din't try to check the YANG module itself. Issues: Shouldn't a Privacy Considerations section be added to the draft? The draft defines quite a lot of privacy-sensitive information (like certificates) with no restriction on read access (as far as I understand). Section 3.5. While I understand and support the idea, expressed in this section, I think that the way it is expressed makes it difficult to follow in practice. In general, it's not always obvious how to estimate the "strength" of the underlying secure transport. For this reason it's not clear for me how it is supposed to "compare" the "strength" of the transport with the "strength" of the keys being transported. In addition, the requirement, that "Implementations SHOULD fail the write-request if ever the strength of the private key is greater then the strength of the underlying transport" looks wrong to me. You don't need to have 1024 bits transport protocol strength to transfer 1024 bit key, since even for say 256 bits it's infeasible to break. I think that the better approach would be to advise using strong ciphersuites for transport protocols defined in corresponding RFCs. For example, for TLS 1.3 there are ciphersuites marked as "recommended", that were evaluated by IETF crypto community. Section 3.6: For instance, AES using "EBC" SHOULD NOT be used to encrypt passwords, whereas "CBC" mode is okay since it a unique initialization vector (IV) should be used for each run. Not only IV for CBC should be unique, it should be unpredictable (random or pseudo-random). I also think that lowercase "should" here must be uppercase, or even MUST. Typos, nits: Section 3.6: In order to thwart rainbow attacks, algorithms that result in a unique output for the same input SHOULD be used. s/SHOULD/SHOULD NOT For instance, AES using "EBC" SHOULD NOT be used to encrypt passwords, whereas "CBC" mode is okay since it a unique initialization vector (IV) should be used for each run. s/EBC/ECB s/it// I believe "okay' is a bit of slang, isn't it? Section 3.8: Since the module in this document only define groupings, these considerations are primarily for the designers of other modules that use these groupings. s/define/defines From nobody Tue Aug 24 14:16:03 2021 Return-Path: <0100017b7a050446-f79543cf-d921-4f05-8fe2-c51fad0e6dd2-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 753C13A137D for ; Tue, 24 Aug 2021 14:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=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 uMNiAWBQelrO for ; Tue, 24 Aug 2021 14:15:56 -0700 (PDT) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B39833A1381 for ; Tue, 24 Aug 2021 14:15:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1629839754; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=sjJsMSolbMtlB77HS8VPUZ9fhwLQqrO7SMvPLfdBETE=; b=cDv1Yn5E/YCGrY9xZrC/QOCD9nJO2pEpVGOl7TxTCVywv7qy6H3K62TEk9/AjcST mLZzxiZlnIE6KLqO7iHFfAV49jbOFPId1x3bDgRdYcTESN50OMEEncJLtlOCQpgmZ20 izXecWiX0SSQEqiM8k3TVovSFa9aeFJ7i3zIhodY= From: Kent Watsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Message-ID: <0100017b7a050446-f79543cf-d921-4f05-8fe2-c51fad0e6dd2-000000@email.amazonses.com> Date: Tue, 24 Aug 2021 21:15:54 +0000 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.08.24-54.240.48.90 Archived-At: Subject: [netconf] 111 Minutes updated 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, 24 Aug 2021 21:16:02 -0000 The minutes have updated. Mahesh updated them based on the audio recording. https://datatracker.ietf.org/meeting/111/materials/minutes-111-netconf Kent and Mahesh From nobody Tue Aug 24 14:31:26 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 668B23A1429; Tue, 24 Aug 2021 14:31:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: mjethanandani@gmail.com, netconf-chairs@ietf.org, netconf@ietf.org, rwilton@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162984068332.3458.9003579926297206963@ietfa.amsl.com> Date: Tue, 24 Aug 2021 14:31:23 -0700 Archived-At: Subject: [netconf] netconf - New Meeting Session Request for IETF 112 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, 24 Aug 2021 21:31:24 -0000 A new meeting session request has just been submitted by Mahesh Jethanandani, a Chair of the netconf working group. --------------------------------------------------------- Working Group Name: Network Configuration Area Name: Operations and Management Area Session Requester: Mahesh Jethanandani Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 45 Conflicts to Avoid: People who must be present: Mahesh Jethanandani Kent Watsen Robert Wilton Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Aug 24 14:44:17 2021 Return-Path: <0100017b7a1ee05f-77916da4-e934-4068-8912-2e7862f1a1fc-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 A64C03A0D31 for ; Tue, 24 Aug 2021 14:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 tT-JktqL-9NS for ; Tue, 24 Aug 2021 14:44:10 -0700 (PDT) Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974543A14B3 for ; Tue, 24 Aug 2021 14:44:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1629841449; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=kErjASLJuL9YujyM5S9b5/huzjKbYwfqRypAbLGu2Pw=; b=Vh/PVLarkK2yYpKBiApxpXOyGQy9OFh/lho4wQ52Vkm+eJxac95IXKILBOwltWf0 9UEwQ/x6ujCepMdbLqWrPm6cSmGx/R759TNwJSvSfzQ0bxKJyW30yLbg7I1BbOKU7rc NhN/SbvnnGJzMsAd59YamdBSKQLXUZGWbL0Sk8rU= From: Kent Watsen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 24 Aug 2021 21:44:09 +0000 References: <0100017b2d307005-c8c91273-452b-4466-9798-c8f318712cdd-000000@email.amazonses.com> To: "netconf@ietf.org" In-Reply-To: <0100017b2d307005-c8c91273-452b-4466-9798-c8f318712cdd-000000@email.amazonses.com> Message-ID: <0100017b7a1ee05f-77916da4-e934-4068-8912-2e7862f1a1fc-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.08.24-54.240.48.94 Archived-At: Subject: Re: [netconf] https-notif: concern w/ YANG module 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, 24 Aug 2021 21:44:16 -0000 There has been no response in two weeks. Mahesh and I feel that the WG = is okay with not adding a module defining identities. Thusly the = current draft does not need any changes. Kent and Mahesh (as co-authors) > On Aug 9, 2021, at 7:12 PM, Kent Watsen wrote: >=20 > Hiya Folks, >=20 > The 111 discussed again the idea of using an IANA-maintained module = (i.e., derived from an IANA registry). Pictorially: >=20 > Current: strings --> IANA registry > Proposed: strings --> IANA registry --> IANA-maintained module >=20 > The value of using a YANG module is, presumably, to enable finer = syntactic validation (e.g., "type identityref=E2=80=9D vs. "type = string=E2=80=9D), but by whom and why? >=20 > - Receivers validating their messages before transmission to = Publishers may occur in development, but is typically disabled in = production. >=20 > - Publishers validating messages received from Receivers is common. = But the draft says that Publishers should ignore any unknown = capabilities. However, YANG-validation would produce a validation = error, which seems worse. Yes, the validation error could be examined = and, in case only due to an unknown identityref, ignored, but does it = make sense to do this? >=20 > At this point, the CONs seem to outweigh the PROs. We=E2=80=99re = considering to abandon the YANG-module=E2=80=A6comments? >=20 > Kent and Mahesh (as authors) >=20 >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Aug 24 19:12:44 2021 Return-Path: <0100017b7b142f27-4cb06097-7349-44e4-be7a-9f93fbea40a8-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 C44C43A1EE6; Tue, 24 Aug 2021 19:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 UgUIdAPIqcSo; Tue, 24 Aug 2021 19:12:08 -0700 (PDT) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BB573A1EE8; Tue, 24 Aug 2021 19:12:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1629857526; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=MNOGyUnuxC0dbeCdKF81MM2QpiOznhsF8RoJGPvGu7Q=; b=ko1x0C8OJfylhFsA7gyaI78nr0Zjx2E9iPHUWMCdUzlwnzpUCcpV2+3S1eS3B5D7 p33WmfqICwholyMmZuLEZxR51inujvg1Ven/ZMQG2/QA/AAl1kGYdecKfyqct5y3XNA sCwJaYU+34PbtN9E/vLSQcQB9WG3maBR6l7+BUaA= From: Kent Watsen Message-ID: <0100017b7b142f27-4cb06097-7349-44e4-be7a-9f93fbea40a8-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D85DF740-91F9-4B95-8D2B-462418CE7900" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Wed, 25 Aug 2021 02:12:05 +0000 In-Reply-To: Cc: "anima@ietf.org" , "netconf@ietf.org" To: "Fries, Steffen" References: X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.08.25-54.240.8.83 Archived-At: Subject: Re: [netconf] [Anima] CSR grouping introduced in draft-ietf-netconf-sztp-csr-06 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, 25 Aug 2021 02:12:14 -0000 --Apple-Mail=_D85DF740-91F9-4B95-8D2B-462418CE7900 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 You=E2=80=99re welcome. K. > On Aug 24, 2021, at 11:25 AM, Fries, Steffen = wrote: >=20 > Hi Kent, > =20 > I just went over the changes regarding the csr-grouping = (https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-08#sect= ion-3.2 = ) you introduced in draft-ietf-netconf-sztp-csr-06. To my = understanding (I=E2=80=99m not too deep into YANG yet) the new grouping = of the csr in the YANG module ietf-ztp-types can now be used directly. > This should enable the direct application in BRSKI-AE, which we were = looking for to avoid double definition. Thanks for the incorporation. = While we are currently using only the PKCS#10 approach, the module = provides also the option to switch to cmp-csr or cmc-csr. So were are = open also for other formats. =20 > =20 > Best regards > Steffen > -- > Steffen Fries > Siemens AG >=20 > =20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima = --Apple-Mail=_D85DF740-91F9-4B95-8D2B-462418CE7900 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 You=E2=80=99re welcome.

K.



On Aug = 24, 2021, at 11:25 AM, Fries, Steffen <steffen.fries@siemens.com> wrote:

Hi Kent,
 
I = just went over the changes regarding the csr-grouping (https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-c= sr-08#section-3.2) you introduced in draft-ietf-netconf-sztp-csr-06. = To my understanding (I=E2=80=99m not too deep into YANG yet) the new = grouping of the csr in the YANG module ietf-ztp-types can now be used = directly.
This = should enable the direct application in BRSKI-AE, which we were looking = for to avoid double definition. Thanks for the incorporation. While we = are currently using only the PKCS#10 approach, the module provides also = the option to switch to cmp-csr or cmc-csr. So were are open also for = other formats.  
 
Best regards
Steffen
--
Steffen Fries
Siemens AG

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

= --Apple-Mail=_D85DF740-91F9-4B95-8D2B-462418CE7900-- From nobody Wed Aug 25 20:44: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 5C4883A129E for ; Wed, 25 Aug 2021 20:44:46 -0700 (PDT) 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, HTML_MESSAGE=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 (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 RU54LsOihzLE for ; Wed, 25 Aug 2021 20:44:45 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 15E803A1295 for ; Wed, 25 Aug 2021 20:44:45 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id e7so1938286pgk.2 for ; Wed, 25 Aug 2021 20:44:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=vTGSu5ck+AobgebsDnEjWMymJnF/8nn03bFF2BBknZY=; b=hxa5AEE2PSTTc0x2wl5J20EeofcVBGmLYegmFXdbyBfMhZVzQOwFHROu0X5WCyjmvt Rc7eLn/WZPPaLdOtudKbKbcOd846WppZydYGbrFvWVfM7g2Az8EW8rX10dj16zscfDa3 2r3BEOvhj8SWRfnhwXgeJl4NZ6WHzyzqEuBD9h/aJL9Ch4XUoqe25W/M02ZPzv1bfZHj 6TKLF90N6Br25L3uuuZMIntlY+WANbe3c+CGsJL/NjcYtsnxj2a3i5Iwn3mErSwutxEq /ZKXzEe/MNJwqxmSAMGXOzJmd0NbXgIPDlyt7+6tngFFr12+XASZa7vVW2v7P1OCcpcQ 20cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=vTGSu5ck+AobgebsDnEjWMymJnF/8nn03bFF2BBknZY=; b=jTPcAbYMB1C2FI80KL9+ecFA7gJ/sKwj5b60DhbP4Fjrjh7wYahwGKXmnRQOT/mbMX KwXAaHk+nkzf4ZWzh8NJ9s8xoPZEecQKlA95/rDjE6qKooF2GK7vxW35n9EazObITOLf UM24B911B0WyZI9vA521zXF6fZVYejcA4sKLRK2gTa8EyWnCOTkJBWO+G3OjEHCcrDKp 1BbgOc0cyKqZAH0lc6VozS5/K86UyE+RvbKAJNnA9KIgXqM1I+qCZUSXLNC7aqqXvaRI NEQvTsa4dJAAePLl2CR4tUJ6cV3Np8Xo68kTWPH8D7D2OujcYvM/AzQThhw2AqBqvETd CVcQ== X-Gm-Message-State: AOAM533/NU6GHXOdf6KzrhmvK2cUhKBjcaJNgyrUyxww5ZOBN4fHz0tb GLLYRsWiHafGRgZjlYNLK80Zf5sJZWc= X-Google-Smtp-Source: ABdhPJyXN5wY7VcJNMHrSnnbMRBgWR1utfroVmKdAdAJlHz99JMpen+cWImR1AH2mNMaQHn5RUXK2A== X-Received: by 2002:a63:2217:: with SMTP id i23mr1486744pgi.448.1629949482908; Wed, 25 Aug 2021 20:44:42 -0700 (PDT) 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 p9sm1543867pgn.36.2021.08.25.20.44.41 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Aug 2021 20:44:42 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_B3BC5F6D-C232-411B-96BD-688042E6F839" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Message-Id: <3192879D-5892-4FBD-8A89-A82BDDFA15FC@gmail.com> Date: Wed, 25 Aug 2021 20:44:41 -0700 To: Netconf X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [netconf] IPR poll for draft-ietf-netconf-netconf-client-server 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, 26 Aug 2021 03:44:46 -0000 --Apple-Mail=_B3BC5F6D-C232-411B-96BD-688042E6F839 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Authors, Contributors, WG, As part of WGLC on this document: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3669, 5378 and 8179 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author. Also please send the response to the list above, and not unicast it. Thanks. Mahesh Jethanandani (as co-chair) mjethanandani@gmail.com --Apple-Mail=_B3BC5F6D-C232-411B-96BD-688042E6F839 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Authors, Contributors, WG,

As = part of WGLC on this document:

Are you = aware of any IPR that applies to draft identified above?
Please state either:

"No, I'm = not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in = compliance with IETF IPR rules
(see RFCs 3669, 5378 and = 8179 for more details)?

If yes to the = above, please state either:

"Yes, the IPR = has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you = think
appropriate.

If you are = listed as a document author or contributor please answer the
above by responding to this email regardless of whether or = not you are
aware of any relevant IPR. This document will = not advance to the next
stage until a response has been = received from each author.

Also please send = the response to the list above, and not unicast it.

Thanks.

Mahesh Jethanandani (as = co-chair)
mjethanandani@gmail.com


= --Apple-Mail=_B3BC5F6D-C232-411B-96BD-688042E6F839-- From nobody Wed Aug 25 20:45: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 3EEA03A1295 for ; Wed, 25 Aug 2021 20:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1Dju6jsEyue for ; Wed, 25 Aug 2021 20:44:42 -0700 (PDT) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 6445F3A128F for ; Wed, 25 Aug 2021 20:44:42 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id a21so1563506pfh.5 for ; Wed, 25 Aug 2021 20:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=TzT8i4GS2hzydZvaoODPdzRFghfDDdBbtACLL0opPXM=; b=oXJhfV7csXNzxezH3+qoTzYrwKxt6iup8kGhCgiwLUOsNDqAOBJHtP6z3Mx7DJi9ye BTWZsrez7jMPY36lkemH+BCC6tisOJ0SVpQCR4EJcBG698wud23SxrIi7VZHRWceNuOU yWSBXOzp/mtCaz7pL0tfk+19YJzjNYJhLOzqD7mKacwsX+M+vJDmkTjlsgarnJcF4iuL Tj7Q8HTRIpoRGwMgokPa+YvizmvibxB0cx813TpnR5vSYWrJ6hb9tk0YaM8dRLB36Er3 Dw60M3tWcXFR6PXoypD1PpYK/kVVWeYJEVROMI/orJGNiwVqyGOEaaqTSC2553CWSTAN TiBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=TzT8i4GS2hzydZvaoODPdzRFghfDDdBbtACLL0opPXM=; b=VGRz5JV726sSaW1a+WpK1KsemQIRg6bu8KprlJNV/DCIv0NE/vzQnPyl3Jfblt9qEW OvCdz4oBGBCGWsNGz/C9i3Z1tNdHzWVdapMLAlb9tdjdWCWOdlr+k91CdB5WFObDOhh/ QNYW3PD//TZ7aKsYXslbsnxrJfgGqJExn3B/icsC4EN0ipReHNh8l2jlCrenKFNEm7g1 XPWHb72IQnFb4odDTthdgKZ5wjEpvmqLc3TY/t8NcW10JUG3OlqEccQQ6U2DGEz0WvDV EC14UzWkwHLDjQMwTTaU8stCxvkDGGcf6CHuVcxpm9px1DTt93gmMmYoiDYeD9KP4Bp2 ZrwA== X-Gm-Message-State: AOAM530KmhmBB5YmpJjwuNWR71v9TXgIg1hVq6yFpihVEp6Hy20CWs38 c/05vOVX2YouD/5BVHxugoCnJ2irV88= X-Google-Smtp-Source: ABdhPJz5FHEYBggD0YVIAjoObo2iOZJJe8C//9IGcYgdn7c6j+wLsR4UuuZc99/XCiXvMiVayIJITg== X-Received: by 2002:a63:3c5d:: with SMTP id i29mr1452400pgn.147.1629949480057; Wed, 25 Aug 2021 20:44:40 -0700 (PDT) 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 p9sm1543867pgn.36.2021.08.25.20.44.39 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Aug 2021 20:44:39 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_91E9ABB8-D3BA-4CFD-92A2-B2F221A07519" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Message-Id: <8DB8D596-9357-4D94-B1DA-F3DBFFED4BAF@gmail.com> Date: Wed, 25 Aug 2021 20:44:38 -0700 To: Netconf X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [netconf] WGLC on on draft-ietf-netconf-netconf-client-server 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, 26 Aug 2021 03:44:47 -0000 --Apple-Mail=_91E9ABB8-D3BA-4CFD-92A2-B2F221A07519 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We are starting a 3 week WGLC on = draft-ietf-netconf-netconf-client-server version 23. The extra week = because the US is coming up to some holidays in that time period. The = document can be found here: = https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-client-server/= Please respond on this thread indicating your support or concerns about = why this document should/should not be adopted. We are particularly interested in statement of the form: - I have reviewed the draft and found no issues.=20 - I have reviewed the draft and found the following issues =E2=80=A6 This WGLC will conclude on Wednesday, September 15. An IPR call will be = issued separately. Thank you. Mahesh & Kent (as co-chairs) --Apple-Mail=_91E9ABB8-D3BA-4CFD-92A2-B2F221A07519 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We = are starting a 3 week WGLC = on draft-ietf-netconf-netconf-client-server version 23. The extra = week because the US is coming up to some holidays in that time period. = The document can be found here:

https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-cli= ent-server/

Please respond on this thread indicating your = support or concerns about why this document should/should not be = adopted.

We = are particularly interested in statement of the form:

- I have reviewed the = draft and found no issues. 
- I have reviewed = the draft and found the following issues =E2=80=A6

This WGLC will conclude = on Wednesday, September 15. An IPR call will be issued = separately.

Thank you.

Mahesh & Kent (as co-chairs)

= --Apple-Mail=_91E9ABB8-D3BA-4CFD-92A2-B2F221A07519-- From nobody Wed Aug 25 20:45:16 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 DE9E33A128F for ; Wed, 25 Aug 2021 20:44:47 -0700 (PDT) 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 4vC-xV5qb8qm for ; Wed, 25 Aug 2021 20:44:42 -0700 (PDT) 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 8CFFF3A1292 for ; Wed, 25 Aug 2021 20:44:42 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id w8so1916783pgf.5 for ; Wed, 25 Aug 2021 20:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=8Dwubdt8i6/NjOwhjMuWgyMH9ivfVZ1kYB16h/O9Zu0=; b=LV9GTIZaMcJpMX3pEiEWHko9ATmoX/jyp/O2UA7IEY6KqykCDNi/El+BddLS/UYsxc bJMCobSEF19WTjjfEZ0ELU9OGwcrcI/1Vhgn5qDMShXApxP3piKFpg4lO5f4pQhRHoyC MdsUQEE7PbkKzz4Uxv0M5uluSv4lKAGpvtZET6Lmj/vBUyKSwwN5uOQyrvT+ZMjmrkjE GtVxaoqFESFQlHfswGG9zdPwihnpXtgiBNfK1XKDqYyII2Spnfcs8kE4x2N5h4Vf2d91 GWZiPbkTYO0Oa6lf/+be/X6rGuZcggq45soFnKk1SZDJ1jMcy22kFXd8m9QDDy6MGPCT l7vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=8Dwubdt8i6/NjOwhjMuWgyMH9ivfVZ1kYB16h/O9Zu0=; b=f2k6/rF5lWYJ6AIfXZSfKaypME4F+Iwyok6Upu5Ch5bdYL9zMJqYMFzuZWbRlD0X2f CdFhD1uuVJzw6YrhYRRS+2UtSXjq/E0sWu6D4g5oID+CLwCYhXV2o0G0ynJlDjd24x8W 82wsnsEggWu7KQV40nBp0Vs078fjuVm6QtIGmobPOwhtHbI5TxTW1d//+rh2cEGQm1b9 2/Sg+IHp9b4R27y/DQBGcReOy4wNB8cdkDGJ3FP5VRkX6MMBywTHxu2Y2I5/zZT5FB+0 s7rJJZaYdvPWboNDoCc0raDn0GRebBMvigWagRl7qA0Jo1ODgqGyxes92FZKKSz5RBKH CbsA== X-Gm-Message-State: AOAM533v6iiS2W62v/Js0xoidKqLM3Cgn2HfXYHfxQ07DkopGo6TK73R 35fw6b2l3Z1vCmenWYTsADbtwQ1MKNE= X-Google-Smtp-Source: ABdhPJwHYfk2FA0llZ/WWcRbqehAZwOITxcRaCk6JePVhaIS5OsuhM3EbbAGB86K8SONmfcIPc1wqg== X-Received: by 2002:a63:411:: with SMTP id 17mr1466962pge.335.1629949481181; Wed, 25 Aug 2021 20:44:41 -0700 (PDT) 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 p9sm1543867pgn.36.2021.08.25.20.44.40 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Aug 2021 20:44:40 -0700 (PDT) From: Mahesh Jethanandani Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Message-Id: <830F697E-2491-40B2-82B7-0D0C20EDFA31@gmail.com> Date: Wed, 25 Aug 2021 20:44:40 -0700 To: Netconf X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [netconf] WGLC on draft-ietf-netconf-restconf-client-server 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, 26 Aug 2021 03:44:48 -0000 We are starting a 3 week WGLC on = draft-ietf-netconf-restconf-client-server version 23. The extra week = because the US is coming up to some holidays in that time period. The = document can be found here: = https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-client-server= / Please respond on this thread indicating your support or concerns about = why this document should/should not be adopted. We are particularly interested in statement of the form: - I have reviewed the draft and found no issues.=20 - I have reviewed the draft and found the following issues =E2=80=A6 This WGLC will conclude on Wednesday, September 15. An IPR call will be = issued separately. Thank you. Mahesh & Kent (as co-chairs) From nobody Wed Aug 25 20:45: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 1D01A3A129F for ; Wed, 25 Aug 2021 20:44:49 -0700 (PDT) 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, HTML_MESSAGE=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 (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 GQovTV3bVKQv for ; Wed, 25 Aug 2021 20:44:46 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 09AD53A129D for ; Wed, 25 Aug 2021 20:44:46 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id x16so1577444pfh.2 for ; Wed, 25 Aug 2021 20:44:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=wAog9GpJgb/BKbvzGakHpPoYjueG3P1lZ2qnN47YUak=; b=WpzIw3AM4ADlLzdEPKVWiUdiVUc+0plr3VT+Gdae6+AUZdIwE1Iu+So1e0UQPyS32J m33TceM2TZ4/vEpilQFEuKfd4zNcEYDXS4WvSH7Omx7yjBvUK2XKHlM696eAyZrxV+LQ 6kf9yLDKHB/NB/IbBtfwKOiVsBtNG3kkeqT9ICg2eH0z9mVEXQx3j4gfB8Djbjk+8/pO Hut9b6nc/BN7D1quxifKmyNtcoDogoIc2ADciST5dwwFJfsfO+uAaxIoVUtmAb/Q1Yw/ BeXTUHscmmopR8Tg88C7u4xeTAbNzdmR23q8/DBHrHKEEwPMjlKyIlMfdmrAF8aBx+II 7iJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=wAog9GpJgb/BKbvzGakHpPoYjueG3P1lZ2qnN47YUak=; b=TtVwAkuVG5vyavTaOyhc44dLi1UzN4tcaefxVzv8bWL31HJb2qhUA3CqTX3H2tpBJu c2gqnLDOfruJj5PnoRk/GUNaBbqP3WQTS/7Hcs4pN+/jMvkgIrRyUkLGOev8T+IgdO0P 3MNMAdjIMDpBQYxjAcFPCzWh77vDT7ywslHLLOM1zyy7wRf4LxnGHmNK7tWFrlGGQf2d rxwwlDELZZ70AR1tjbBpR6MuwhE6EDufS7WqzPuSRLfWCkXQjGTAdxJxv3QELuA5Ofrn PP+Nei7vxZFTBsun1MFRegXtgscMU+bQsZGaTyr2Ao8MbEzuuS4rnFqy2VpAWCodCVR2 s5Wg== X-Gm-Message-State: AOAM530AjJ8yvkBlLeCspFRIuCBzHC0ExAo9D1UPFiRTy3OrwOTuIg56 oRoylqxUGGUPhLjOyrxgXeoPWuUFw60= X-Google-Smtp-Source: ABdhPJzb45uU+JZVOYMQy26NVMimJ8QkHbiAm7px/IywWCbTVXxH9SvTGGWrGnCZK7q8Bg/6Mg0UTg== X-Received: by 2002:a63:1542:: with SMTP id 2mr1478354pgv.102.1629949484661; Wed, 25 Aug 2021 20:44:44 -0700 (PDT) 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 p9sm1543867pgn.36.2021.08.25.20.44.43 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Aug 2021 20:44:44 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_0945A565-2ABC-4047-A7AD-1F48B6B4EB56" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Message-Id: Date: Wed, 25 Aug 2021 20:44:43 -0700 To: Netconf X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [netconf] IPR poll for draft-ietf-netconf-restconf-client-server 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, 26 Aug 2021 03:44:49 -0000 --Apple-Mail=_0945A565-2ABC-4047-A7AD-1F48B6B4EB56 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Authors, Contributors, WG, As part of WGLC on this document: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3669, 5378 and 8179 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author. Also please send the response to the list above, and not unicast it. Thanks. Mahesh Jethanandani (as co-chair) mjethanandani@gmail.com --Apple-Mail=_0945A565-2ABC-4047-A7AD-1F48B6B4EB56 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Authors, Contributors, WG,

As = part of WGLC on this document:

Are you = aware of any IPR that applies to draft identified above?
Please state either:

"No, I'm = not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in = compliance with IETF IPR rules
(see RFCs 3669, 5378 and = 8179 for more details)?

If yes to the = above, please state either:

"Yes, the IPR = has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you = think
appropriate.

If you are = listed as a document author or contributor please answer the
above by responding to this email regardless of whether or = not you are
aware of any relevant IPR. This document will = not advance to the next
stage until a response has been = received from each author.

Also please send = the response to the list above, and not unicast it.

Thanks.

Mahesh Jethanandani (as = co-chair)
mjethanandani@gmail.com


= --Apple-Mail=_0945A565-2ABC-4047-A7AD-1F48B6B4EB56-- From nobody Thu Aug 26 10:52:54 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 D45193A189D; Thu, 26 Aug 2021 10:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkJtwguKSA4t; Thu, 26 Aug 2021 10:52:45 -0700 (PDT) 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 9EB3B3A1892; Thu, 26 Aug 2021 10:52:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 4861038A25; Thu, 26 Aug 2021 13:58:20 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GO-igf1-4mOh; Thu, 26 Aug 2021 13:58:14 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BF0F638A14; Thu, 26 Aug 2021 13:58:14 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1EB5B5E5; Thu, 26 Aug 2021 13:52:38 -0400 (EDT) From: Michael Richardson To: Kent Watsen , "Fries\, Steffen" , "netconf\@ietf.org" , "anima\@ietf.org" In-Reply-To: <0100017b7b142f27-4cb06097-7349-44e4-be7a-9f93fbea40a8-000000@email.amazonses.com> References: <0100017b7b142f27-4cb06097-7349-44e4-be7a-9f93fbea40a8-000000@email.amazonses.com> 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: [netconf] async-enroll and CSR grouping introduced in draft-ietf-netconf-sztp-csr-06 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, 26 Aug 2021 17:52:52 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Kent Watsen wrote: > You=E2=80=99re welcome. This is where I think we are now: I'm writing this to confirm our understan= ding! I think that we are now going to build a new traditional YANG module (not a ietf-restconf) that contains this sztp-csr grouping. We are going to use this over: HTTP, CoAP and CoAP-over-BTLE. For HTTP, I know we want to use JSON serialization only. For CoAP (over-BTLE), CBOR (with SID) would make more sense, but that might be premature optimization. I think that we could use trust-anchors directly as is, but I'm not sure ye= t. In any case, we have a new YANG module to add to async =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+93Q3WUFAmEn1OUACgkQgItw+93Q 3WXNRQgAjkSq3wYIQunyexoygQ/PiZAjCr+CJ9pZtoPXuNVojYw2s1tOe0ne/QlZ gY9zNDQBnKdK2qNq/hI0XwRFoeIQqnPG6DeehQS8zYiRVWYLfGuGiT8SxX9SQuws GVVF8M3HKSSf/bRjIqfNqIcdwgZ/z8PO81082FQMxXTkbpeV14v645NFg40ksY3H Leo2wLNnTP913FLNhOxQ9s/4nwKapHVu6qXhMEhKmxZusePML+/RJ/fwXpqlPj7s CtuUVPvVtwmdMt/SpjcXJIECiY+r4O1la1ZQSBllYSYYljAD9pNTLd1Vsj9KodvU x1aloIfA8bf7zosOQn3/tIYgXtB1ag== =5SPl -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 27 04:34:47 2021 Return-Path: <0100017b8763ec25-2f73b7b9-091d-4a16-95a1-382d55603537-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 D80E63A0899 for ; Fri, 27 Aug 2021 04:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=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 gf_gwt5i_2ds for ; Fri, 27 Aug 2021 04:34:39 -0700 (PDT) Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 400643A0888 for ; Fri, 27 Aug 2021 04:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1630064078; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=RjmBsrIN3Fc8mbVDaXRqYHTh6GBK5vqlzhnIgJzfu4M=; b=RIjFugQn8rTs8K1zRKFgpNBe3zvIfElPPE5eGDLPTHCPRSMNnTrjlv6ookjH+AYs flqTDRjtH0/YtPIr5LxyNXq9Lm5cBznf1Pru8jMh7tXMITVDtUbiFSbZq8AFZWFPHoE PDqJCViu6nesClMmKl4U7vztJ5gN1ph4ILh3VT7c= From: Kent Watsen Message-ID: <0100017b8763ec25-2f73b7b9-091d-4a16-95a1-382d55603537-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CE20B9F3-D861-47D1-8C15-6133CFA68485" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Fri, 27 Aug 2021 11:34:37 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: Mahesh Jethanandani References: X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.08.27-54.240.48.92 Archived-At: Subject: Re: [netconf] IPR poll for draft-ietf-netconf-restconf-client-server 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, 27 Aug 2021 11:34:45 -0000 --Apple-Mail=_CE20B9F3-D861-47D1-8C15-6133CFA68485 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I am unaware of any IPR related to the =E2=80=9Crestconf-client-server" = draft. Kent, as author. > On Aug 25, 2021, at 11:44 PM, Mahesh Jethanandani = wrote: >=20 > Authors, Contributors, WG, >=20 > As part of WGLC on this document: >=20 > Are you aware of any IPR that applies to draft identified above? >=20 > Please state either: >=20 > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3669, 5378 and 8179 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think > appropriate. >=20 > If you are listed as a document author or contributor please answer = the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author. >=20 > Also please send the response to the list above, and not unicast it. >=20 > Thanks. >=20 > Mahesh Jethanandani (as co-chair) > mjethanandani@gmail.com >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail=_CE20B9F3-D861-47D1-8C15-6133CFA68485 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = am unaware of any IPR related to the =E2=80=9Crestconf-client-server" = draft.

Kent,= as author.


On Aug 25, 2021, at 11:44 PM, Mahesh = Jethanandani <mjethanandani@gmail.com> wrote:

Authors, Contributors, = WG,

As part of WGLC on this document:

Are you aware of any IPR that applies to draft = identified above?

Please state either:

"No, I'm not aware of any IPR that applies to = this draft"
or
"Yes, I'm aware of IPR that = applies to this draft"

If so, has this IPR = been disclosed in compliance with IETF IPR rules
(see RFCs = 3669, 5378 and 8179 for more details)?

If = yes to the above, please state either:

"Yes, = the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any = additional details you think
appropriate.

If you are listed as a document author or contributor please = answer the
above by responding to this email regardless of = whether or not you are
aware of any relevant IPR. This = document will not advance to the next
stage until a = response has been received from each author.

Also please send the response to the list above, and not = unicast it.

Thanks.

Mahesh Jethanandani (as co-chair)
mjethanandani@gmail.com


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

= --Apple-Mail=_CE20B9F3-D861-47D1-8C15-6133CFA68485-- From nobody Fri Aug 27 04:34:54 2021 Return-Path: <0100017b8763f8f0-ba1b14fd-ad91-4124-9a9b-5bb01e605047-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 605CC3A08A7 for ; Fri, 27 Aug 2021 04:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=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 DTGWmwy4MDT4 for ; Fri, 27 Aug 2021 04:34:44 -0700 (PDT) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DDF03A0898 for ; Fri, 27 Aug 2021 04:34:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1630064081; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=WR7K4AmVGTdldUNmtjdxlLRsO+fg+O2WitnnuPHuJ6U=; b=V/NwKXlcINs7uRI7miAm3HlZD8ikQD7va/HQ6SbnLZyN6jTCtXM1nlPeyHExDusN 2j9WLe68874mT3XP0tRs2RQqJ7Z82oiKmX9MqL/YCUsP7UWOf8k/4+MuuEmOYdWn8we oGIpMo11zuyJwXLTLT+7re3IIvBSmMfk351N9LJI= From: Kent Watsen Message-ID: <0100017b8763f8f0-ba1b14fd-ad91-4124-9a9b-5bb01e605047-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E0567802-70B1-470A-80F8-5606F018E98F" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Fri, 27 Aug 2021 11:34:41 +0000 In-Reply-To: <3192879D-5892-4FBD-8A89-A82BDDFA15FC@gmail.com> Cc: "netconf@ietf.org" To: Mahesh Jethanandani References: <3192879D-5892-4FBD-8A89-A82BDDFA15FC@gmail.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.08.27-54.240.48.90 Archived-At: Subject: Re: [netconf] IPR poll for draft-ietf-netconf-netconf-client-server 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, 27 Aug 2021 11:34:52 -0000 --Apple-Mail=_E0567802-70B1-470A-80F8-5606F018E98F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I am unaware of any IPR related to the =E2=80=9Cnetconf-client-server" = draft. Kent, as author. > On Aug 25, 2021, at 11:44 PM, Mahesh Jethanandani = wrote: >=20 > Authors, Contributors, WG, >=20 > As part of WGLC on this document: >=20 > Are you aware of any IPR that applies to draft identified above? >=20 > Please state either: >=20 > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3669, 5378 and 8179 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think > appropriate. >=20 > If you are listed as a document author or contributor please answer = the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author. >=20 > Also please send the response to the list above, and not unicast it. >=20 > Thanks. >=20 > Mahesh Jethanandani (as co-chair) > mjethanandani@gmail.com >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --Apple-Mail=_E0567802-70B1-470A-80F8-5606F018E98F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = am unaware of any IPR related to the =E2=80=9Cnetconf-client-server" = draft.

Kent, as = author.


On Aug = 25, 2021, at 11:44 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

Authors, Contributors, = WG,

As part of WGLC on this document:

Are you aware of any IPR that applies to draft = identified above?

Please state either:

"No, I'm not aware of any IPR that applies to = this draft"
or
"Yes, I'm aware of IPR that = applies to this draft"

If so, has this IPR = been disclosed in compliance with IETF IPR rules
(see RFCs = 3669, 5378 and 8179 for more details)?

If = yes to the above, please state either:

"Yes, = the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any = additional details you think
appropriate.

If you are listed as a document author or contributor please = answer the
above by responding to this email regardless of = whether or not you are
aware of any relevant IPR. This = document will not advance to the next
stage until a = response has been received from each author.

Also please send the response to the list above, and not = unicast it.

Thanks.

Mahesh Jethanandani (as co-chair)
mjethanandani@gmail.com


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

= --Apple-Mail=_E0567802-70B1-470A-80F8-5606F018E98F-- From nobody Fri Aug 27 07:53:28 2021 Return-Path: <0100017b8819bf19-1f20d528-72e4-462c-884a-6c29eff0769b-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 6A28E3A088A; Fri, 27 Aug 2021 07:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=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 GOTQ0n9UMIGX; Fri, 27 Aug 2021 07:53:20 -0700 (PDT) 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 173233A088C; Fri, 27 Aug 2021 07:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1630075994; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=Uu/ONjl7dl7hWoksXtnjx/UeTEwG5YasRHnS0hzF/C4=; b=aW/eA3gkN6CNF8x0YAR8W+pvy74y9RZaE2fdPQQJexU/N+7LJhJJoeGZ9V1q+we7 BV4fdQwIXLr+XdH/cl8dgRVBFOje9ifYELFDTq/KwiHctYOzM8gbfd9LImwjIdCXxdI l2SoG3SfNOSbruMbTZLw7ILxfIT4soHelgfiQ0+s= From: Kent Watsen Message-ID: <0100017b8819bf19-1f20d528-72e4-462c-884a-6c29eff0769b-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_17EAF07D-2366-4962-B625-7E97D33BF5B2" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Fri, 27 Aug 2021 14:53:14 +0000 In-Reply-To: <162982978380.3381.17549750696257276827@ietfa.amsl.com> Cc: secdir@ietf.org, draft-ietf-netconf-crypto-types.all@ietf.org, "netconf@ietf.org" To: Valery Smyslov References: <162982978380.3381.17549750696257276827@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.08.27-54.240.48.95 Archived-At: Subject: Re: [netconf] [Last-Call] Secdir last call review of draft-ietf-netconf-crypto-types-20 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, 27 Aug 2021 14:53:26 -0000 --Apple-Mail=_17EAF07D-2366-4962-B625-7E97D33BF5B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [removing =E2=80=9Clast-call=E2=80=9D alias] Hello Valery. =20 Thank you for your SecDir review, it is very much appreciated and never = too late! More comments below. Thanks, Kent > On Aug 24, 2021, at 2:29 PM, Valery Smyslov via Datatracker = wrote: >=20 > Reviewer: Valery Smyslov > Review result: Has Issues >=20 > I have reviewed this document as part of the security directorate's = ongoing > effort to review all IETF documents being processed by the IESG. = These > comments were written primarily for the benefit of the security area = directors. > Document editors and WG chairs should treat these comments just like = any other > last call comments. >=20 > When I was re-assigned to review this draft the indicated deadline was = already > missed by 8 months, so I don't know how relevant the review is. I = reviewed > the latest -20 version of the draft instead of -18, that was = requested. Perfect. > The draft defines common YANG data types and groupings useful for = cryptography. > I din't try to check the YANG module itself.=20 >=20 > Issues: >=20 > Shouldn't a Privacy Considerations section be added to the draft? > The draft defines quite a lot of privacy-sensitive information (like = certificates) > with no restriction on read access (as far as I understand). Both the "trust-anchor-cert-grouping=E2=80=9D and = =E2=80=9Cend-entity-cert-grouping=E2=80=9D groupings have = "nacm:default-deny-write=E2=80=9D that, to your point, does not restrict = reads. That said, only management protocols having mutual = authentication (e.g., SSH and/or TLS based transport) can access the = data. =20 Is your concern that the certificate=E2=80=99s content would be visible = to the administrators? Is your comment on end-entity certificates = (containing personally-identifying information), more than = trust-anchor-certificates? > Section 3.5. > While I understand and support the idea, expressed in this section, I = think that > the way it is expressed makes it difficult to follow in practice. In = general, it's > not always obvious how to estimate the "strength" of the underlying = secure transport. > For this reason it's not clear for me how it is supposed to "compare" = the=20 > "strength" of the transport with the "strength" of the keys being = transported. I saw language like this once in a DoD setting. I agree that it is = difficult to implement in practice. I used =E2=80=9CSHOULD=E2=80=9D = (not MUST) to buy some leeway for implementations to be compliant. = Makes sense? FWIW, my YANG-driven server is able to remember what key the client used = for authentication (e.g., RSA 2048) and register a callback to test that = no greater keys (e.g., 3072 or 4096) are configured by that client. = Additional logic would be needed to prevent a low-strength client from = *reading* a high-strength key configured by another client=E2=80=A6though = the issue can be alternatively resolved by configuring the TLS-stack to = prevent low-strength algorithms. > In addition, the requirement, that "Implementations SHOULD fail the = write-request if ever > the strength of the private key is greater then the strength of the > underlying transport" looks wrong to me. You don't need to have > 1024 bits transport protocol strength to transfer 1024 bit key, since > even for say 256 bits it's infeasible to break. IDK about this. Again, I saw this constraint once in a DoD setting. =20 > I think that the better approach would be to advise using strong > ciphersuites for transport protocols defined in corresponding RFCs. > For example, for TLS 1.3 there are ciphersuites marked as = "recommended", > that were evaluated by IETF crypto community. I added this sentence: Implementations SHOULD configure allowed transport=20 algorithms to include only those meeting local policy (e.g., listed as "recommended" by the IETF). Good? > Section 3.6: > For instance, AES > using "EBC" SHOULD NOT be used to encrypt passwords, whereas "CBC" > mode is okay since it a unique initialization vector (IV) should be > used for each run. >=20 > Not only IV for CBC should be unique, it should be unpredictable = (random or pseudo-random). > I also think that lowercase "should" here must be uppercase, or even = MUST. Replaced =E2=80=9Cunique=E2=80=9D with =E2=80=9Cunpredictable=E2=80=9D Replaced =E2=80=9Cshould=E2=80=9D with MUST. > Typos, nits: >=20 > Section 3.6:=20 > In order to thwart rainbow attacks, algorithms that result in a > unique output for the same input SHOULD be used.=20 >=20 > s/SHOULD/SHOULD NOT Egads - fixed! > For instance, AES > using "EBC" SHOULD NOT be used to encrypt passwords, whereas "CBC" > mode is okay since it a unique initialization vector (IV) should be > used for each run. >=20 > s/EBC/ECB > s/it// > I believe "okay' is a bit of slang, isn't it? Fixed, now reads: In order to thwart rainbow attacks, algorithms that result in a unique output for the same input SHOULD NOT be used. For instance, AES using "ECB" SHOULD NOT be used to encrypt passwords, whereas "CBC" mode is permissible since an unpredictable initialization vector (IV) MUST be used for each use. > Section 3.8: > Since the module in this document only define groupings, these > considerations are primarily for the designers of other modules that > use these groupings. >=20 > s/define/defines Fixed! Kent, as author --Apple-Mail=_17EAF07D-2366-4962-B625-7E97D33BF5B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
[removing =E2=80=9Clast-call=E2=80=9D alias]


Hello= Valery.  

Thank = you for your SecDir review, it is very much appreciated and never too = late!

More comments below.

Thanks,
Kent


On Aug 24, 2021, at 2:29 PM, Valery Smyslov = via Datatracker <noreply@ietf.org> wrote:

Reviewer: Valery Smyslov
Review result: Has = Issues

I have reviewed this document as = part of the security directorate's ongoing
effort to = review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the = security area directors.
Document editors and WG chairs = should treat these comments just like any other
last call = comments.

When I was re-assigned to review = this draft the indicated deadline was already
missed by 8 = months, so I don't know how relevant the review is. I reviewed
the latest -20 version of the draft instead of -18, that was = requested.

Perfect.


The draft defines common YANG data types and groupings useful = for cryptography.
I din't try to check the YANG module = itself.

Issues:

Shouldn't a Privacy Considerations section be added to the = draft?
The draft defines quite a lot of privacy-sensitive = information (like certificates)
with no restriction on = read access (as far as I understand).


Both the "trust-anchor-cert-grouping=E2=80=9D and = =E2=80=9Cend-entity-cert-grouping=E2=80=9D groupings have "nacm:default-deny-write=E2=80=9D that, to = your point, does not restrict reads.  That said, = only management protocols having mutual authentication (e.g., SSH = and/or TLS based transport) can access the data. =  

Is your = concern that the certificate=E2=80=99s content would be visible to the = administrators? =  Is your comment on end-entity certificates (containing = personally-identifying information), more than = trust-anchor-certificates?


Section 3.5.
While I understand = and support the idea, expressed in this section, I think that
the way it is expressed makes it difficult to follow in = practice. In general, it's
not always obvious how to = estimate the "strength" of the underlying secure transport.
For this reason it's not clear for me how it is supposed to = "compare" the
"strength" of the transport with the = "strength" of the keys being transported.

I saw = language like this once in a DoD setting.  I agree that it is = difficult to implement in practice.  I used =E2=80=9CSHOULD=E2=80=9D = (not MUST) to buy some leeway for implementations to be compliant. =  Makes sense?

FWIW, my = YANG-driven server is able to remember what key the client used for = authentication (e.g., RSA 2048) and register a callback to test that no = greater keys (e.g., 3072 or 4096) are configured by that client. =  Additional logic would be needed to prevent a low-strength client = from *reading* a high-strength key configured by another client=E2=80=A6th= ough the issue can be alternatively resolved by configuring the = TLS-stack to prevent low-strength algorithms.


In addition, the requirement, that = "Implementations SHOULD fail the write-request if ever
the = strength of the private key is greater then the strength of the
underlying transport" looks wrong to me. You don't need to = have
1024 bits transport protocol strength to transfer = 1024 bit key, since
even for say 256 bits it's infeasible = to break.

IDK about this.  Again, I saw this constraint = once in a DoD setting.  


I think that the better approach would be to advise using = strong
ciphersuites for transport protocols defined in = corresponding RFCs.
For example, for TLS 1.3 there are = ciphersuites marked as "recommended",
that were evaluated = by IETF crypto community.

I added this sentence:

Implementations SHOULD = configure allowed transport 
 = algorithms to include only those meeting local
policy = (e.g., listed as "recommended" by the IETF).

Good?


Section 3.6:
  For instance, AES
  using "EBC" SHOULD NOT be used to encrypt = passwords, whereas "CBC"
  mode is okay since = it a unique initialization vector (IV) should be
=   used for each run.

Not only IV = for CBC should be unique, it should be unpredictable (random or = pseudo-random).
I also think that lowercase "should" here = must be uppercase, or even MUST.

Replaced =E2=80=9Cunique=E2=80=9D with = =E2=80=9Cunpredictable=E2=80=9D
Replaced =E2=80=9Cshould=E2=80=9D= with MUST.


Typos, nits:

Section 3.6:
  In order to thwart rainbow attacks, algorithms = that result in a
  unique output for the same = input SHOULD be used.

s/SHOULD/SHOULD = NOT

Egads - fixed!


  For instance, AES
=   using "EBC" SHOULD NOT be used to encrypt passwords, whereas = "CBC"
  mode is okay since it a unique = initialization vector (IV) should be
  used for = each run.

s/EBC/ECB
s/it//
I believe "okay' is a bit of slang, isn't it?

Fixed, = now reads:

In order = to thwart rainbow attacks, algorithms that result
in a = unique output for the same input SHOULD NOT be = used.
= For instance, AES using "ECB" SHOULD NOT be = used to
encrypt passwords, whereas = "CBC" mode is permissible
since = an unpredictable initialization vector (IV) MUST = be
= used for each use.</t>


Section 3.8:
=   Since the module in this document only define groupings, = these
  considerations are primarily for the = designers of other modules that
  use these = groupings.

s/define/defines

Fixed!



Kent, as = author


= --Apple-Mail=_17EAF07D-2366-4962-B625-7E97D33BF5B2-- From nobody Fri Aug 27 09:14: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 0FBBF3A1412; Fri, 27 Aug 2021 09:14:50 -0700 (PDT) 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, 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=smyslov.net 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 n1uIMlIi-7mT; Fri, 27 Aug 2021 09:14:43 -0700 (PDT) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (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 156903A140F; Fri, 27 Aug 2021 09:14:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To: References:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=oTGB8ROnhmf2dc6rHqn0QBKZnqdw6fE4JiAHMQrovmQ=; b=mJz753VN3dfe6qRd8oJRNHNXCr +Y38ONE/oPdBEE/CDjNX5r6WrDl3ygqv7E181lXL1JaBkbpkBFqnCy9qRj+pqs1LSMykHHispHCNU i7ulcSCdZ51zkisUfHGHrT194NFBLEssJvz/UMXEzWoK0uPNdm89o6lurSEOqE5B14KEw8SBi/KRf 4438EVhrlj+0S04BM8dyC2P11nYb8xzA/M03M9bPcbrXlGt/sJLICBJoWxrJA8e+aELmYJ34uzhMv iL5apKnlYwvxTFEjVVEvUfiexCmjqVPfYMwrQuEIDGcXZ/CIFvS0MIaPsQDmV+aYB6s3BXWSeGmIC OdZgh8/g==; Received: from [93.188.44.204] (port=62899 helo=buildpc) by direct.host-care.com with esmtpsa (TLS1.2) tls TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mJeV3-0007rS-Kj; Fri, 27 Aug 2021 12:14:38 -0400 From: "Valery Smyslov" To: "'Kent Watsen'" Cc: , , References: <162982978380.3381.17549750696257276827@ietfa.amsl.com> <0100017b8819bf19-1f20d528-72e4-462c-884a-6c29eff0769b-000000@email.amazonses.com> In-Reply-To: <0100017b8819bf19-1f20d528-72e4-462c-884a-6c29eff0769b-000000@email.amazonses.com> Date: Fri, 27 Aug 2021 19:14:30 +0300 Message-ID: <017c01d79b5e$a00a0000$e01e0000$@smyslov.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_017D_01D79B77.C55A4540" X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQGndKy5sGszK4BuDx47nymU5VnBUwHC5W7jq9m0WHA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net Archived-At: Subject: Re: [netconf] [Last-Call] Secdir last call review of draft-ietf-netconf-crypto-types-20 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, 27 Aug 2021 16:14:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_017D_01D79B77.C55A4540 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Kent, =20 thank you for addressing my comments. A bit more inline. =20 [removing =E2=80=9Clast-call=E2=80=9D alias] =20 =20 Hello Valery. =20 =20 Thank you for your SecDir review, it is very much appreciated and never = too late! =20 More comments below. =20 Thanks, Kent =20 On Aug 24, 2021, at 2:29 PM, Valery Smyslov via Datatracker = wrote: =20 Reviewer: Valery Smyslov Review result: Has Issues I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area = directors. Document editors and WG chairs should treat these comments just like any = other last call comments. When I was re-assigned to review this draft the indicated deadline was = already missed by 8 months, so I don't know how relevant the review is. I = reviewed the latest -20 version of the draft instead of -18, that was requested. =20 Perfect. =20 The draft defines common YANG data types and groupings useful for = cryptography. I din't try to check the YANG module itself.=20 Issues: Shouldn't a Privacy Considerations section be added to the draft? The draft defines quite a lot of privacy-sensitive information (like = certificates) with no restriction on read access (as far as I understand). =20 =20 Both the "trust-anchor-cert-grouping=E2=80=9D and = =E2=80=9Cend-entity-cert-grouping=E2=80=9D groupings have = "nacm:default-deny-write=E2=80=9D that, to your point, does not restrict = reads. That said, only management protocols having mutual = authentication (e.g., SSH and/or TLS based transport) can access the = data. =20 =20 Is your concern that the certificate=E2=80=99s content would be visible = to the administrators? Is your comment on end-entity certificates = (containing personally-identifying information), more than = trust-anchor-certificates? =20 Yes, it=E2=80=99s mostly on end-entity certificates, however = there may be quite a lot of interesting private information besides certificates. =20 If this information is only visible to the administrators and = the used management protocols must=20 have mutual authentication, then it=E2=80=99s probably not a = big deal. I would have still added a sentence about privacy of the stored data (i.e. that = persons, that are allowed to access this data are able to learn quite a lot of private information from it). = I don=E2=80=99t insist though, it=E2=80=99s up to you. =20 Section 3.5. While I understand and support the idea, expressed in this section, I = think that the way it is expressed makes it difficult to follow in practice. In = general, it's not always obvious how to estimate the "strength" of the underlying = secure transport. For this reason it's not clear for me how it is supposed to "compare" = the=20 "strength" of the transport with the "strength" of the keys being = transported. =20 I saw language like this once in a DoD setting. I agree that it is = difficult to implement in practice. I used =E2=80=9CSHOULD=E2=80=9D = (not MUST) to buy some leeway for implementations to be compliant. = Makes sense? =20 My understanding of using RFC2119 language is that SHOULD is = very close to MUST, but allows some exceptions. So, I still think that you put a = responsibility to make security-related decisions on implementers, who often are not = experts in this area. =20 FWIW, my YANG-driven server is able to remember what key the client used = for authentication (e.g., RSA 2048) and register a callback to test that = no greater keys (e.g., 3072 or 4096) are configured by that client. = Additional=20 =20 What if the other key configured for the client is X25519? = Which is stronger? =20 logic would be needed to prevent a low-strength client from *reading* a = high-strength key configured by another client=E2=80=A6though the issue = can be alternatively resolved by configuring the TLS-stack to prevent = low-strength algorithms. =20 That was my point. I think that it=E2=80=99s better to require = (by SHOULD) that only those ciphersuites that were =E2=80=9Cvetted=E2=80=9D by IETF = (i.e. got =E2=80=9CRecommended=E2=80=9D status) be used. This will make implementers=E2=80=99 life easier. =20 In addition, the requirement, that "Implementations SHOULD fail the = write-request if ever the strength of the private key is greater then the strength of the underlying transport" looks wrong to me. You don't need to have 1024 bits transport protocol strength to transfer 1024 bit key, since even for say 256 bits it's infeasible to break. =20 IDK about this. Again, I saw this constraint once in a DoD setting. =20 =20 My (another) point was that there is generally no point to = increase security strength beyond some level. Currently it is believed that 128 bit of symmetric key is infeasible to break (provided = the algorithm is not broken itself), If you are lucky have full-sized Post Quantum computer, = it=E2=80=99ll be 256 bits. It=E2=80=99s enough to transfer symmetric keys with say 1024 = bits of entropy (FWIW). So the requirement that the strength of transport must be always greater than the strength of transported key=20 seems not a good requirement to me. Instead require that the strength of transport be sufficient to make infeasible for an attacker to break it. =20 I think that the better approach would be to advise using strong ciphersuites for transport protocols defined in corresponding RFCs. For example, for TLS 1.3 there are ciphersuites marked as "recommended", that were evaluated by IETF crypto community. =20 I added this sentence: =20 Implementations SHOULD configure allowed transport=20 algorithms to include only those meeting local policy (e.g., listed as "recommended" by the IETF). =20 Good? =20 Perfect. =20 Regards, Valery. Section 3.6: For instance, AES using "EBC" SHOULD NOT be used to encrypt passwords, whereas "CBC" mode is okay since it a unique initialization vector (IV) should be used for each run. Not only IV for CBC should be unique, it should be unpredictable (random = or pseudo-random). I also think that lowercase "should" here must be uppercase, or even = MUST. =20 Replaced =E2=80=9Cunique=E2=80=9D with =E2=80=9Cunpredictable=E2=80=9D Replaced =E2=80=9Cshould=E2=80=9D with MUST. =20 =20 Typos, nits: Section 3.6:=20 In order to thwart rainbow attacks, algorithms that result in a unique output for the same input SHOULD be used.=20 s/SHOULD/SHOULD NOT =20 Egads - fixed! =20 For instance, AES using "EBC" SHOULD NOT be used to encrypt passwords, whereas "CBC" mode is okay since it a unique initialization vector (IV) should be used for each run. s/EBC/ECB s/it// I believe "okay' is a bit of slang, isn't it? =20 Fixed, now reads: =20 In order to thwart rainbow attacks, algorithms that result in a unique output for the same input SHOULD NOT be used. For instance, AES using "ECB" SHOULD NOT be used to encrypt passwords, whereas "CBC" mode is permissible since an unpredictable initialization vector (IV) MUST be used for each use. =20 Section 3.8: Since the module in this document only define groupings, these considerations are primarily for the designers of other modules that use these groupings. s/define/defines =20 Fixed! =20 =20 =20 Kent, as author =20 =20 ------=_NextPart_000_017D_01D79B77.C55A4540 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Kent,

 

thank you for addressing my comments. A bit more = inline.

 

[removing = =E2=80=9Clast-call=E2=80=9D alias]

 

 

Hello = Valery.  

 

Thank you for your SecDir review, it is very much = appreciated and never too late!

 

More comments below.

 

Thanks,

Kent

 



On = Aug 24, 2021, at 2:29 PM, Valery Smyslov via Datatracker <noreply@ietf.org> = wrote:

 

Reviewer: Valery Smyslov
Review result: Has = Issues

I have reviewed this document as part of the security = directorate's ongoing
effort to review all IETF documents being = processed by the IESG.  These
comments were written primarily = for the benefit of the security area directors.
Document editors and = WG chairs should treat these comments just like any other
last call = comments.

When I was re-assigned to review this draft the = indicated deadline was already
missed by 8 months, so I don't know = how relevant the review is. I reviewed
the latest -20 version of the = draft instead of -18, that was = requested.

 

Perfect.

 



The draft defines common YANG data types and groupings = useful for cryptography.
I din't try to check the YANG module itself. =

Issues:

Shouldn't a Privacy Considerations section be = added to the draft?
The draft defines quite a lot of = privacy-sensitive information (like certificates)
with no restriction = on read access (as far as I = understand).

 

 

Both the "trust-anchor-cert-grouping=E2=80=9D and = =E2=80=9Cend-entity-cert-grouping=E2=80=9D groupings have "nacm:default-deny-write=E2=80=9D that, to = your point, does not restrict reads.  That said, = only management protocols having mutual authentication (e.g., SSH = and/or TLS based transport) can access the data.  

 

Is your concern that the = certificate=E2=80=99s content would be visible to the administrators? =  Is your comment on end-entity = certificates (containing personally-identifying information), more than = trust-anchor-certificates?

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Yes, it=E2=80=99s mostly on end-entity certificates, however there = may be quite a lot of interesting

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 private = information besides certificates.

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If this = information is only visible to the administrators and the used = management protocols must

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 have mutual = authentication, then it=E2=80=99s probably not a big deal. I would have = still added

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a sentence = about privacy of the stored data (i.e. that persons, that are allowed to = access this data

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 are able to = learn quite a lot of private information from it). I don=E2=80=99t = insist though, it=E2=80=99s up to you.

 

Section 3.5.
While I understand and support the = idea, expressed in this section, I think that
the way it is expressed = makes it difficult to follow in practice. In general, it's
not always = obvious how to estimate the "strength" of the underlying = secure transport.
For this reason it's not clear for me how it is = supposed to "compare" the
"strength" of the = transport with the "strength" of the keys being = transported.

 

I = saw language like this once in a DoD setting.  I agree that it is = difficult to implement in practice.  I used = =E2=80=9CSHOULD=E2=80=9D (not MUST) to buy some leeway for = implementations to be compliant.  Makes sense?

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 My = understanding of using RFC2119 language is that SHOULD is very close to = MUST,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 but allows = some exceptions. So, I still think that you put a responsibility to = make

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = security-related decisions on implementers, who often are not experts in = this area.

 

FWIW, my YANG-driven server is able to remember what = key the client used for authentication (e.g., RSA 2048) and register a = callback to test that no greater keys (e.g., 3072 or 4096) are = configured by that client.  Additional

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 What if the = other key configured for the client is X25519? Which is = stronger?

 

logic would be needed to prevent a low-strength client from = *reading* a high-strength key configured by another = client=E2=80=A6though the issue can be alternatively resolved by = configuring the TLS-stack to prevent low-strength = algorithms.

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 That was my = point. I think that it=E2=80=99s better to require (by SHOULD) that = only

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 those = ciphersuites that were =E2=80=9Cvetted=E2=80=9D by IETF (i.e. got = =E2=80=9CRecommended=E2=80=9D status) be used.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This will make = implementers=E2=80=99 life easier.

 

In addition, the requirement, that = "Implementations SHOULD fail the write-request if ever
the = strength of the private key is greater then the strength of = the
underlying transport" looks wrong to me. You don't = need to have
1024 bits transport protocol strength to transfer 1024 = bit key, since
even for say 256 bits it's infeasible to = break.

 

IDK about this.  Again, I saw this constraint = once in a DoD setting.  

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 My (another) = point was that there is generally no point to = increase

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 security = strength beyond some level. Currently it is = believed

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that 128 bit = of symmetric key is infeasible to break (provided the algorithm is not = broken itself),

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If you are = lucky have full-sized Post Quantum computer, it=E2=80=99ll be 256 = bits.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 It=E2=80=99s = enough to transfer symmetric keys with say 1024 bits of = entropy

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (FWIW). So the = requirement that the strength of transport must

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 be always = greater than the strength of transported key

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 seems not a = good requirement to me. Instead require that

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the strength = of transport be sufficient to make

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 infeasible for = an attacker to break it.

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

I think that the better approach would be to advise using = strong
ciphersuites for transport protocols defined in corresponding = RFCs.
For example, for TLS 1.3 there are ciphersuites marked = as "recommended",
that were evaluated by IETF crypto = community.

 

I = added this sentence:

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Implementations SHOULD configure allowed transport 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 algorithms to include only those meeting = local

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 policy (e.g., listed as "recommended" by = the IETF).

 

Good?

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Perfect.

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Regards,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Valery.

Section 3.6:
  For = instance, AES
  using "EBC" SHOULD NOT be used to = encrypt passwords, whereas "CBC"
  mode is okay = since it a unique initialization vector (IV) should = be
  used for each run.

Not only IV for CBC should = be unique, it should be unpredictable (random or pseudo-random).
I = also think that lowercase "should" here must be uppercase, or = even MUST.

 

Replaced =E2=80=9Cunique=E2=80=9D with = =E2=80=9Cunpredictable=E2=80=9D

Replaced =E2=80=9Cshould=E2=80=9D with = MUST.

 

 

Typos, nits:

Section 3.6:
  In = order to thwart rainbow attacks, algorithms that result in = a
  unique output for the same input SHOULD be used. =

s/SHOULD/SHOULD = NOT

 

Egads - fixed!

 



  For instance, AES
  using = "EBC" SHOULD NOT be used to encrypt passwords, whereas = "CBC"
  mode is okay since it a unique = initialization vector (IV) should be
  used for each = run.

s/EBC/ECB
s/it//
I believe "okay' is a bit of = slang, isn't it?

 

Fixed, now reads:

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 In order to thwart rainbow attacks, algorithms that = result
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 in a unique output for the same input SHOULD NOT be = used.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 For instance, AES using "ECB" SHOULD NOT be = used to

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 encrypt passwords, whereas "CBC" mode is = permissible

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 since an unpredictable initialization vector (IV) = MUST be

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 used for each use.</t>

 

Section 3.8:
  Since the module in this = document only define groupings, these
  considerations are = primarily for the designers of other modules that
  use = these = groupings.

s/define/defines

 

Fixed!

 

 

 

Kent, as author

 

 

------=_NextPart_000_017D_01D79B77.C55A4540-- From nobody Fri Aug 27 09:20: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 8C83B3A148C; Fri, 27 Aug 2021 09:19:57 -0700 (PDT) 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, 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=smyslov.net 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 e7-O6NWPHFMu; Fri, 27 Aug 2021 09:19:52 -0700 (PDT) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (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 E6F0E3A1488; Fri, 27 Aug 2021 09:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To: References:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ddT5aP/NZfqYe16O1ZQEbWbVYihrGJp1IjEAAVEeLEE=; b=trMNplqtpFawsn7dxcPvYMoX6B XN9gjrFh5BIcZMamDB8x1ROExKsjCx8XaJ4G+LMQUTj+DItP3wsg+AIVXCcHDTj6FERalTUj2QSCQ maNgWX8C4QIUkpKdNjhigE95ts/V20LLB3ldQcNxYzAL8m3BTFVIx9TqnO86P0pE6TLKeSsWWSuq0 f7EnS0rdDEZ407uW3QcE4AYZgly1hvffjPDFuOuG15Z+EVaKu43ltz2tEVUlgsfnw3N2CVxFEjoXq NtVyPCLDMg4q4PMj6tsbNQSK8kUE1ZmVC+LKe4DdAP/w1nvCYg61r2Iz+9RQBlzEcjCK+Z6nNMfnU sON26yiw==; Received: from [93.188.44.204] (port=55235 helo=buildpc) by direct.host-care.com with esmtpsa (TLS1.2) tls TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mJea4-0000T5-4K; Fri, 27 Aug 2021 12:19:48 -0400 From: "Valery Smyslov" To: "'Kent Watsen'" Cc: , , References: <162982978380.3381.17549750696257276827@ietfa.amsl.com> <0100017b8819bf19-1f20d528-72e4-462c-884a-6c29eff0769b-000000@email.amazonses.com> <017c01d79b5e$a00a0000$e01e0000$@smyslov.net> In-Reply-To: <017c01d79b5e$a00a0000$e01e0000$@smyslov.net> Date: Fri, 27 Aug 2021 19:19:41 +0300 Message-ID: <018401d79b5f$591b51c0$0b51f540$@smyslov.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0185_01D79B78.7E6889C0" X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQGndKy5sGszK4BuDx47nymU5VnBUwHC5W7jAisjdPWryGQXwA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net Archived-At: Subject: Re: [netconf] [Last-Call] Secdir last call review of draft-ietf-netconf-crypto-types-20 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, 27 Aug 2021 16:19:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0185_01D79B78.7E6889C0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Spotted a typo in own message =E2=80=93 of course it was meant Quantum = computer, not a Post Quantum one (I have no idea what Post Quantum computer may mean :-), I know only = Post-quantum cryptography). =20 =20 In addition, the requirement, that "Implementations SHOULD fail the = write-request if ever the strength of the private key is greater then the strength of the underlying transport" looks wrong to me. You don't need to have 1024 bits transport protocol strength to transfer 1024 bit key, since even for say 256 bits it's infeasible to break. =20 IDK about this. Again, I saw this constraint once in a DoD setting. =20 =20 My (another) point was that there is generally no point to = increase security strength beyond some level. Currently it is believed that 128 bit of symmetric key is infeasible to break (provided = the algorithm is not broken itself), If you are lucky have full-sized Post Quantum computer, = it=E2=80=99ll be 256 bits. It=E2=80=99s enough to transfer symmetric keys with say 1024 = bits of entropy (FWIW). So the requirement that the strength of transport must be always greater than the strength of transported key=20 seems not a good requirement to me. Instead require that the strength of transport be sufficient to make infeasible for an attacker to break it. =20 ------=_NextPart_000_0185_01D79B78.7E6889C0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Spotted a typo in own message =E2=80=93 of course it was meant = Quantum computer, not a Post Quantum one

(I have no idea what Post Quantum computer may mean :-), I know only = Post-quantum cryptography).

 

 

In addition, the requirement, that = "Implementations SHOULD fail the write-request if ever
the = strength of the private key is greater then the strength of = the
underlying transport" looks wrong to me. You don't = need to have
1024 bits transport protocol strength to transfer 1024 = bit key, since
even for say 256 bits it's infeasible to = break.

 

IDK about this.  Again, I saw this constraint = once in a DoD setting.  

 

          My (another) = point was that there is generally no point to = increase

          security = strength beyond some level. Currently it is = believed

          that 128 bit = of symmetric key is infeasible to break (provided the algorithm is not = broken itself),

          If you are = lucky have full-sized Post Quantum computer, it=E2=80=99ll be 256 = bits.

          It=E2=80=99s = enough to transfer symmetric keys with say 1024 bits of = entropy

          (FWIW). So the = requirement that the strength of transport must

          be always = greater than the strength of transported key

          seems not a = good requirement to me. Instead require that

          the strength = of transport be sufficient to make

          infeasible for = an attacker to break it.

          =

------=_NextPart_000_0185_01D79B78.7E6889C0-- From nobody Fri Aug 27 13:52:24 2021 Return-Path: <0100017b89613006-504db539-c16c-4c87-8772-2b6676e9c295-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 42B813A18B5; Fri, 27 Aug 2021 13:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=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 YvHCZZbTgZiU; Fri, 27 Aug 2021 13:50:56 -0700 (PDT) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FA713A18B4; Fri, 27 Aug 2021 13:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1630097453; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=xR1YvpEQ+4dJZZdDiGLE8SloqxEIwTbteEvkVtHfv0M=; b=dMH1tJR8aiff5tKURsk6SIdwZJfEqiiOdyRDVLHdyDgSTOgbHDFiPZO4XkbJ2IFl A5ERO8NK+WrA+C70kMe2JSS3NP4PZHf/C99bI1TJVXRkSDAz1hef8jqF7D3eTlPbHMM 5JkDy5IrC6um3YKhSk7SR0YKg3nsDU4WQcf5AeBM= From: Kent Watsen Message-ID: <0100017b89613006-504db539-c16c-4c87-8772-2b6676e9c295-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D0AC81A2-385D-463C-937B-5ED5A7C76C38" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Fri, 27 Aug 2021 20:50:53 +0000 In-Reply-To: <017c01d79b5e$a00a0000$e01e0000$@smyslov.net> Cc: secdir@ietf.org, draft-ietf-netconf-crypto-types.all@ietf.org, "netconf@ietf.org" To: Valery Smyslov References: <162982978380.3381.17549750696257276827@ietfa.amsl.com> <0100017b8819bf19-1f20d528-72e4-462c-884a-6c29eff0769b-000000@email.amazonses.com> <017c01d79b5e$a00a0000$e01e0000$@smyslov.net> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.08.27-54.240.48.90 Archived-At: Subject: Re: [netconf] [Last-Call] Secdir last call review of draft-ietf-netconf-crypto-types-20 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, 27 Aug 2021 20:51:04 -0000 --Apple-Mail=_D0AC81A2-385D-463C-937B-5ED5A7C76C38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Valery, > On Aug 27, 2021, at 12:14 PM, Valery Smyslov = wrote: >=20 > Hi Kent, > =20 > thank you for addressing my comments. A bit more inline. All good. =20 =20 > [removing =E2=80=9Clast-call=E2=80=9D alias] > =20 > =20 > Hello Valery. =20 > =20 > Thank you for your SecDir review, it is very much appreciated and = never too late! > =20 > More comments below. > =20 > Thanks, > Kent > =20 >=20 >=20 > On Aug 24, 2021, at 2:29 PM, Valery Smyslov via Datatracker = > wrote: > =20 > Reviewer: Valery Smyslov > Review result: Has Issues >=20 > I have reviewed this document as part of the security directorate's = ongoing > effort to review all IETF documents being processed by the IESG. = These > comments were written primarily for the benefit of the security area = directors. > Document editors and WG chairs should treat these comments just like = any other > last call comments. >=20 > When I was re-assigned to review this draft the indicated deadline was = already > missed by 8 months, so I don't know how relevant the review is. I = reviewed > the latest -20 version of the draft instead of -18, that was = requested. > =20 > Perfect. > =20 >=20 >=20 > The draft defines common YANG data types and groupings useful for = cryptography. > I din't try to check the YANG module itself.=20 >=20 > Issues: >=20 > Shouldn't a Privacy Considerations section be added to the draft? > The draft defines quite a lot of privacy-sensitive information (like = certificates) > with no restriction on read access (as far as I understand). > =20 > =20 > Both the "trust-anchor-cert-grouping=E2=80=9D and = =E2=80=9Cend-entity-cert-grouping=E2=80=9D groupings have = "nacm:default-deny-write=E2=80=9D that, to your point, does not restrict = reads. That said, only management protocols having mutual = authentication (e.g., SSH and/or TLS based transport) can access the = data. =20 > =20 > Is your concern that the certificate=E2=80=99s content would be = visible to the administrators? Is your comment on end-entity = certificates (containing personally-identifying information), more than = trust-anchor-certificates? > =20 > Yes, it=E2=80=99s mostly on end-entity certificates, however = there may be quite a lot of interesting > private information besides certificates. > =20 > If this information is only visible to the administrators = and the used management protocols must=20 > have mutual authentication, then it=E2=80=99s probably not a = big deal. I would have still added > a sentence about privacy of the stored data (i.e. that = persons, that are allowed to access this data > are able to learn quite a lot of private information from = it). I don=E2=80=99t insist though, it=E2=80=99s up to you. I added the following to Section 3.8 (The "ietf-crypto-types" YANG = Module). The "cert-data" node: The "cert-data" node, defined in both the = "trust-anchor-cert-grouping" and "end-entity-cert-grouping" groupings, is = additionally sensitive to read operations, as certificates sometimes convey = personally identifying information (especially end-entity certificates). = However, as it is commonly understood that certificates are "public", = the NACM extension "nacm:default-deny-write" (not "default-deny-all") = has been applied. It is RECOMMENDED that implementations adjust = read-access to certificates to comply with local policy. Is this okay? Separately, I thought about if there are any other values in the module = that may have privacy concerns but was unable to locate any. >> Section 3.5. >> While I understand and support the idea, expressed in this section, I = think that >> the way it is expressed makes it difficult to follow in practice. In = general, it's >> not always obvious how to estimate the "strength" of the underlying = secure transport. >> For this reason it's not clear for me how it is supposed to "compare" = the=20 >> "strength" of the transport with the "strength" of the keys being = transported. All comments from this point to the end regard the Security = Consideration "Strength of Keys Conveyed=E2=80=9D (was "Strength of Keys = Configured=E2=80=9D). I rewrote the section as follows. Can you please = check for accuracy? Strength of Keys Conveyed When accessing key values, it is desireable that = implementations ensure that the strength of the keys being accessed is not = greater than the strength of the underlying secure transport = connection over which the keys are conveyed. However, comparing key = strengths can be complicated and difficult to implement in practice. That said, expert Security opinion suggests that already it = is infeasible to break a 128-bit key using a classical = computer, and=20 thus the concern for conveying higher-strength keys begins = to lose=20 its allure. Implementations SHOULD only use transport algorithms to = those=20 meeting local policy. A reasonable policy may, e.g., state = that=20 only algorithms listed as "recommended" by the IETF be used. Another reasonable policy may be to only use = quantum-resistant=20 algorithms. Thanks! Kent, as author > =20 > I saw language like this once in a DoD setting. I agree that it is = difficult to implement in practice. I used =E2=80=9CSHOULD=E2=80=9D = (not MUST) to buy some leeway for implementations to be compliant. = Makes sense? > =20 > My understanding of using RFC2119 language is that SHOULD is = very close to MUST, > but allows some exceptions. So, I still think that you put a = responsibility to make > security-related decisions on implementers, who often are = not experts in this area. > =20 > FWIW, my YANG-driven server is able to remember what key the client = used for authentication (e.g., RSA 2048) and register a callback to test = that no greater keys (e.g., 3072 or 4096) are configured by that client. = Additional=20 > =20 > What if the other key configured for the client is X25519? = Which is stronger? > =20 > logic would be needed to prevent a low-strength client from *reading* = a high-strength key configured by another client=E2=80=A6though the = issue can be alternatively resolved by configuring the TLS-stack to = prevent low-strength algorithms. > =20 > That was my point. I think that it=E2=80=99s better to = require (by SHOULD) that only > those ciphersuites that were =E2=80=9Cvetted=E2=80=9D by = IETF (i.e. got =E2=80=9CRecommended=E2=80=9D status) be used. > This will make implementers=E2=80=99 life easier. > =20 > In addition, the requirement, that "Implementations SHOULD fail the = write-request if ever > the strength of the private key is greater then the strength of the > underlying transport" looks wrong to me. You don't need to have > 1024 bits transport protocol strength to transfer 1024 bit key, since > even for say 256 bits it's infeasible to break. > =20 > IDK about this. Again, I saw this constraint once in a DoD setting. =20= > =20 > My (another) point was that there is generally no point to = increase > security strength beyond some level. Currently it is = believed > that 128 bit of symmetric key is infeasible to break = (provided the algorithm is not broken itself), > If you are lucky have full-sized Post Quantum computer, = it=E2=80=99ll be 256 bits. > It=E2=80=99s enough to transfer symmetric keys with say 1024 = bits of entropy > (FWIW). So the requirement that the strength of transport = must > be always greater than the strength of transported key=20 > seems not a good requirement to me. Instead require that > the strength of transport be sufficient to make > infeasible for an attacker to break it. > =20 > I think that the better approach would be to advise using strong > ciphersuites for transport protocols defined in corresponding RFCs. > For example, for TLS 1.3 there are ciphersuites marked as = "recommended", > that were evaluated by IETF crypto community. > =20 > I added this sentence: > =20 > Implementations SHOULD configure allowed transport=20 > algorithms to include only those meeting local > policy (e.g., listed as "recommended" by the IETF). > =20 > Good? > =20 > Perfect. > =20 > Regards, > Valery. >=20 --Apple-Mail=_D0AC81A2-385D-463C-937B-5ED5A7C76C38 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Valery,


On Aug 27, 2021, at 12:14 PM, = Valery Smyslov <valery@smyslov.net> wrote:

Hi Kent,
 
thank you for addressing my comments. A bit more = inline.

All good.  
 

[removing = =E2=80=9Clast-call=E2=80=9D alias]
 
 
Hello Valery.  
 
Thank you for your SecDir review, it is = very much appreciated and never too late!
 
More comments below.
 
Thanks,
Kent
 


On Aug 24, 2021, at 2:29 PM, Valery Smyslov via = Datatracker <noreply@ietf.org> = wrote:
 
Reviewer: = Valery Smyslov
Review result: Has Issues

I have reviewed this document as part of the security = directorate's ongoing
effort to review all IETF documents = being processed by the IESG.  These
comments were = written primarily for the benefit of the security area directors.
Document editors and WG chairs should treat these comments = just like any other
last call comments.

When I was re-assigned to review this draft the indicated = deadline was already
missed by 8 months, so I don't know = how relevant the review is. I reviewed
the latest -20 = version of the draft instead of -18, that was requested.
 
Perfect.
 


The draft defines common = YANG data types and groupings useful for cryptography.
I = din't try to check the YANG module itself. 

Issues:

Shouldn't a Privacy = Considerations section be added to the draft?
The draft = defines quite a lot of privacy-sensitive information (like = certificates)
with no restriction on read access (as far = as I understand).
 
 
Both the "trust-anchor-cert-grouping=E2=80= =9D and =E2=80=9Cend-entity-cert-grouping=E2=80=9D groupings = have "nacm:default-deny-write=E2=80=9D = that, to your point, does not restrict reads.  That said, = only management protocols having mutual authentication (e.g., SSH = and/or TLS based transport) can access the data.  
 
Is your concern that the certificate=E2=80=99s = content would be visible to the administrators?  Is your comment on end-entity certificates = (containing personally-identifying information), more than = trust-anchor-certificates?
 
          Yes, it=E2=80=99s mostly on end-entity = certificates, however there may be quite a lot of interesting
          = private information besides certificates.
 
          If = this information is only visible to the administrators and the used = management protocols must 
          have = mutual authentication, then it=E2=80=99s probably not a big deal. I = would have still added
          a = sentence about privacy of the stored data (i.e. that persons, that are = allowed to access this data
          are = able to learn quite a lot of private information from it). I don=E2=80=99t= insist though, it=E2=80=99s up to you.

I added the following = to Section 3.8 (The "ietf-crypto-types" YANG Module).

            =  The "cert-data" node:

 =                  The = "cert-data" node, defined in both the = "trust-anchor-cert-grouping"
        =             and = "end-entity-cert-grouping" groupings, is additionally sensitive = to
                =     read operations, as certificates sometimes = convey personally identifying
        =             information (especially = end-entity certificates).  However, as it is
                =     commonly understood that certificates are = "public", the NACM extension
        =             "nacm:default-deny-write" = (not "default-deny-all") has been applied. It
  =                   is = RECOMMENDED that implementations adjust read-access to = certificates
            =         to comply with local policy.

Is this okay?

Separately, I thought about if there are any other = values in the module that may have privacy concerns but was unable to = locate any.


Section 3.5.
While I understand and = support the idea, expressed in this section, I think that
the way it is expressed makes it difficult to follow in = practice. In general, it's
not always obvious how to = estimate the "strength" of the underlying secure transport.
For this reason it's not clear for me how it is supposed to = "compare" the 
"strength" of the transport with the "strength" of the keys = being transported.


All comments from this point to the = end regard the Security Consideration "Strength of Keys Conveyed=E2=80=9D = (was "Strength of Keys Configured=E2=80=9D= ).  I rewrote the section as follows.  Can you please check = for accuracy?

    =   Strength of Keys Conveyed

      =      When accessing key values, it is = desireable that implementations
      =       ensure that the strength of the keys = being accessed is not greater
      =       than the strength of the underlying = secure transport connection
      =       over which the keys are = conveyed.  However, comparing key strengths
            can be = complicated and difficult to implement in practice.

           That said, expert = Security opinion suggests that already it is
  =           infeasible to break a 128-bit = key using a classical computer, and 
  =           thus the concern for conveying = higher-strength keys begins to lose 
    =         its allure.

          =   Implementations SHOULD only use transport algorithms to = those 
          =   meeting local policy.  A reasonable = policy may, e.g., state that 
    =         only algorithms listed as "recommended" = by the IETF be used.
        =     Another reasonable policy may be to only = use quantum-resistant 
      =       algorithms.

Thanks!
Kent, as author


 
I saw language like this once in a DoD = setting.  I agree that it is difficult to implement in practice. =  I used =E2=80=9CSHOULD=E2=80=9D (not MUST) to buy some leeway for = implementations to be compliant.  Makes sense?
 
          My = understanding of using RFC2119 language is that SHOULD is very close to = MUST,
          but = allows some exceptions. So, I still think that you put a responsibility = to make
          = security-related decisions on implementers, who often are not experts in = this area.
 
FWIW, my = YANG-driven server is able to remember what key the client used for = authentication (e.g., RSA 2048) and register a callback to test that no = greater keys (e.g., 3072 or 4096) are configured by that client. =  Additional 
 
          What = if the other key configured for the client is X25519? Which is = stronger?
 
logic = would be needed to prevent a low-strength client from *reading* a = high-strength key configured by another client=E2=80=A6though the issue = can be alternatively resolved by configuring the TLS-stack to prevent = low-strength algorithms.
 
          That = was my point. I think that it=E2=80=99s better to require (by SHOULD) = that only
          those = ciphersuites that were =E2=80=9Cvetted=E2=80=9D by IETF (i.e. got = =E2=80=9CRecommended=E2=80=9D status) be used.
          This = will make implementers=E2=80=99 life easier.
 
In addition, the requirement, that = "Implementations SHOULD fail the write-request if ever
the = strength of the private key is greater then the strength of the
underlying transport" looks wrong to me. You don't need to = have
1024 bits transport protocol strength to transfer = 1024 bit key, since
even for say 256 bits it's infeasible = to break.
 
IDK about this.  Again, I saw this = constraint once in a DoD setting.  
 
          My = (another) point was that there is generally no point to increase
          = security strength beyond some level. Currently it is believed
          that = 128 bit of symmetric key is infeasible to break (provided the algorithm = is not broken itself),
          If you = are lucky have full-sized Post Quantum computer, it=E2=80=99ll be 256 = bits.
          It=E2=80= =99s enough to transfer symmetric keys with say 1024 bits of entropy
          = (FWIW). So the requirement that the strength of transport must
          be = always greater than the strength of transported key 
          seems = not a good requirement to me. Instead require that
          the = strength of transport be sufficient to make
          = infeasible for an attacker to break it.
          
I think that the better approach would be to advise using = strong
ciphersuites for transport protocols defined in = corresponding RFCs.
For example, for TLS 1.3 there = are ciphersuites marked as "recommended",
that were = evaluated by IETF crypto community.
 
I added this sentence:
 
        &= nbsp; Implementations = SHOULD configure allowed = transport 
        &= nbsp; algorithms = to include only those meeting local
        &= nbsp; policy = (e.g., listed as "recommended" by the IETF).
 
Good?
 
          Perfect.
 
          Regards,
          = Valery.

<= br class=3D"">
= --Apple-Mail=_D0AC81A2-385D-463C-937B-5ED5A7C76C38-- From nobody Mon Aug 30 01:29:08 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 55A023A19E7; Mon, 30 Aug 2021 01:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.795 X-Spam-Level: X-Spam-Status: No, score=-6.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 lkiUm9Q66gE2; Mon, 30 Aug 2021 01:28:58 -0700 (PDT) Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) (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 9433D3A19E5; Mon, 30 Aug 2021 01:28:57 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 17U8SknR010513 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 30 Aug 2021 10:28:46 +0200 Received: from [139.22.32.95] ([139.22.32.95]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 17U8SiVl019959; Mon, 30 Aug 2021 10:28:44 +0200 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> From: David von Oheimb Message-ID: <7d5059f5-c0b6-390c-99d3-4fcdc13d445d@siemens.com> Date: Mon, 30 Aug 2021 10:28:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <0100017b78a75ff9-6506e24d-20c5-4bd7-83a4-0e7472cdfc6e-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="------------D959AA866F979E5D069BEA7C" Content-Language: en-US Archived-At: Subject: Re: [netconf] New Version Notification for draft-ietf-netconf-sztp-csr-06.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, 30 Aug 2021 08:29:05 -0000 This is a multi-part message in MIME format. --------------D959AA866F979E5D069BEA7C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Kent, thanks for your update and providing the diff. I had a closer look at sections 4.1.5 and 4.2.1 and found some further issues. * Section 4.1.5 - since correct identity of the request origin is *crucial* for any type of identity cert generation: old: A The CSR's origin SHOULD be verified before a certificate is issued. new:  The origin of the CSR MUST be verified before a certificate is issued. * Section 4.2.1 - actually, a proof-of-possession can and should be done in all addressed situations, while for PKCS#10 it is hard to link this to a proof-of-origin. old: When the bootstrapping device's manufacturer-generated private key     (e.g., the IDevID key) is reused for the CSR, proof-of-possession is    verified by ensuring the CSR was signed by that key.   When a new asymmetric key is used, proof-of-possession may be    verified, with the CMP or CMC formats, by ensuring the parent ASN.1    structure containing the CSR is signed by the manufacturer-generated key.    new: Since the CSR should have been self-signed using the private key corresponding to the public key placed in the CSR, the proof-of-possession can be checked by verifying this signature using the included public key. With the CMP or CMC formats, this proof-of-origin is directly linked to the proof-or-origin provided by the parent ASN.1 structure, which contains origin authentication using the manufacturer-generated private key or using the shared secret. Regards,     David On 24.08.21 16:54, Kent Watsen wrote: > Hi David, > > I took all your suggestions into account.   I reworded things so, > please review the diffs.  Here’s the direct link to the diffs: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-sztp-csr-08.txt > > > Thanks again, > Kent > > > >> On Aug 18, 2021, at 2:17 AM, David von Oheimb >> > >> wrote: >> >> Hi Kent, >> >>>> thanks for your message regarding the update to the draft and for >>>> updating the CMP-related parts of the YANG module exactly as discussed. >>>> >>> Not *exact*, as Sean tweaked CMC Case 2 (removing the >>> controlSequence restriction and adding a new final sentence) and CMC >>> Case 3 (removing the controlSequence restriction X2). >> >> I did not have a look at other portions of the draft, such as those >> you mention here regarding CMC. Our focus is CMP. >> >> >>>> Regarding the minor extension to the example in section 2.2, likely >>>> the outcome of >>>> our discussion was a bit unclear. >>>> We agreed that the new CMP profile does not need to be referenced >>>> there. >>>> Yet what we still suggest to do is to extend the paragraph >>>> >>>> The SZTP-server responds with "onboarding-information" (encoded >>>> inside the "conveyed-information" node) containing a signed identity >>>> certificate for the CSR provided by the SZTP-client: >>>> >>>> as follows: >>>> >>>> The SZTP-server validates the origin of the CSR and on success >>>> forwards it to a backend server, which may be an RA or CA.The backend >>>> servermust accept only legitimate CSRs approved by the SZTP-server. >>>> Upon receiving a new identity certificate from the backend server, >>>> the SZTP-server responds with "onboarding-information" (encoded >>>> inside the "conveyed-information" node) containing the identity >>>> certificate for the CSR provided by the SZTP-client: >>>> >>> >>> I’m unsure if this is a good addition because nowhere, except in the >>> Security Considerations section, is there any discussion about a >>> backend CA. >>> Of course it is the most likely scenario, but it could also be the >>> case that the CA has the SZTP-server functionality embedded. >> >> That's right. Though one could argue that the text in section 2.2 is >> "just" on example usage, here is a generalization: >> >> After the origin of the CSR and the included proof-of-possession >> have been validated successfully and the CSR has been approved, >> the SZTP-server responds with "onboarding-information" (encoded >> inside the "conveyed-information" node) containing the identity >> certificate for the CSR provided by the SZTP-client: >> >> >>> >>> Additionally, whilst not a bad idea for the SZTP-server to validate >>> the CSR, it seems even more important that the CA be able to do so >>> without taking the SZTP-server’s word for it - right?   >>> Note: https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-07#section-4.2.1 >>> . >>> >>> PS: currently the draft just says “CA”.  Do you think it should say >>> “CA or RA” instead? >> >> Good point that the checks should be mentioned (also) in the security >> considerations, >> and indeed just mentioning "CA" is not general enough. >> >> Here is a couple of suggested text improvements: >> >> 4.1.5 >> . >> Selecting the Best Origin Authentication Mechanism >> >> old: >> >>  When generating a new key, it is important that the client be able to >> provide additional proof to the CA that it was the entity that >> generated the key. >> >> new: >> >>  When generating a new key, it is important that the client be able to >> provide additional proof that it was the entity that generated the key. >> This should be verified successfully before issuing the certificate. >> >> old: >> >> 4.2.1 >> . >> Conveying Proof of Possession to a CA >> >> new: >> >> 4.2.1 >> . >> Conveying Proof of Possession >> >> old: >> >> When the bootstrapping device's manufacturer-generated private key >> (e.g., the IDevID key) is reused, a CA may validate that the CSR was >> signed by that key. >> >> new: >> >> When the bootstrapping device's manufacturer-generated private key >> (e.g., the IDevID key) is reused, verifying the proof-of-possession >> validates that the CSR was signed by that key. >> >> old: >> >>  Both the CMP and CMC formats entail the bootstrapping device signing >> the request once with its (e.g., LDevID) key and then again with its >> (e.g., IDevID) key, which enables a downstream CA to be assured that >> the bootstrapping device possesses the public key being signed. >> >> new: >> >>  Both the CMP and CMC formats entail that the bootstrapping device signs >> the request once with its (e.g., LDevID) key and then again with its >> (e.g., IDevID) key. This enables verifying the proof-of-possession >> of the private key that corresponds to the public key being signed. >> >>     David >> --------------D959AA866F979E5D069BEA7C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Kent,

thanks for your update and providing the diff.
I had a closer look at sections 4.1.5 and 4.2.1 and found some further issues.

  • Section 4.1.5 - since correct identity of the request origin is crucial for any type of identity cert generation:

old:

A The CSR's origin SHOULD be verified before a certificate is issued.

new: 

The origin of the CSR MUST be verified before a certificate is issued.


  • Section 4.2.1 - actually, a proof-of-possession can and should be done in all addressed situations,
    while for PKCS#10 it is hard to link this to a proof-of-origin.

old:

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

When a new asymmetric key is used, proof-of-possession may be   
verified, with the CMP or CMC formats, by ensuring the parent ASN.1   
structure containing the CSR is signed by the manufacturer-generated key.   

new:

Since the CSR should have been self-signed using the private key
corresponding to the public key placed in the CSR, the proof-of-possession
can be checked by verifying this signature using the included public key.

With the CMP or CMC formats, this proof-of-origin is directly linked to the
proof-or-origin provided by the parent ASN.1 structure, which contains
origin authentication using the manufacturer-generated private key or using
the shared secret.


Regards,

    David


On 24.08.21 16:54, Kent Watsen wrote:
Hi David,

I took all your suggestions into account.   I reworded things so, please review the diffs.  Here’s the direct link to the diffs:


Thanks again,
Kent

On Aug 18, 2021, at 2:17 AM, David von Oheimb <David.von.Oheimb@siemens.com> wrote:

Hi Kent,

thanks for your message regarding the update to the draft and for
updating the CMP-related parts of the YANG module exactly as discussed.

Not *exact*, as Sean tweaked CMC Case 2 (removing the controlSequence restriction and adding a new final sentence) and CMC Case 3 (removing the controlSequence restriction X2).

I did not have a look at other portions of the draft, such as those you mention here regarding CMC. Our focus is CMP.


Regarding the minor extension to the example in section 2.2, likely the outcome of
our discussion was a bit unclear.
We agreed that the new CMP profile does not need to be referenced there.
Yet what we still suggest to do is to extend the paragraph

The SZTP-server responds with "onboarding-information" (encoded
inside the "conveyed-information" node) containing a signed identity
certificate for the CSR provided by the SZTP-client:

as follows:

The SZTP-server validates the origin of the CSR and on success
forwards it to a backend server, which may be an RA or CA. The backend
server must accept only legitimate CSRs approved by the SZTP-server.
Upon receiving a new identity certificate from the backend server,
the SZTP-server responds with "onboarding-information" (encoded
inside the "conveyed-information" node) containing the identity
certificate for the CSR provided by the SZTP-client:


I’m unsure if this is a good addition because nowhere, except in the Security Considerations section, is there any discussion about a backend CA.
Of course it is the most likely scenario, but it could also be the case that the CA has the SZTP-server functionality embedded.

That's right. Though one could argue that the text in section 2.2 is "just" on example usage, here is a generalization:

After the origin of the CSR and the included proof-of-possession
have been validated successfully and the CSR has been approved,
the SZTP-server responds with "onboarding-information" (encoded
inside the "conveyed-information" node) containing the identity
certificate for the CSR provided by the SZTP-client:



Additionally, whilst not a bad idea for the SZTP-server to validate the CSR, it seems even more important that the CA be able to do so without taking the SZTP-server’s word for it - right?   Note: https://datatracker.ietf.org/doc/html/draft-ietf-netconf-sztp-csr-07#section-4.2.1.

PS: currently the draft just says “CA”.  Do you think it should say “CA or RA” instead?

Good point that the checks should be mentioned (also) in the security considerations,
and indeed just mentioning "CA" is not general enough.

Here is a couple of suggested text improvements:

4.1.5.  Selecting the Best Origin Authentication Mechanism

old:

   When generating a new key, it is important that the client be able to
   provide additional proof to the CA that it was the entity that
   generated the key.

new:

   When generating a new key, it is important that the client be able to
   provide additional proof that it was the entity that generated the key.
   This should be verified successfully before issuing the certificate.

old:

4.2.1.  Conveying Proof of Possession to a CA

new:

4.2.1.  Conveying Proof of Possession

old:

   When the bootstrapping device's manufacturer-generated private key
   (e.g., the IDevID key) is reused, a CA may validate that the CSR was
   signed by that key.

new:

   When the bootstrapping device's manufacturer-generated private key
   (e.g., the IDevID key) is reused, verifying the proof-of-possession
   validates that the CSR was signed by that key.

old:

   Both the CMP and CMC formats entail the bootstrapping device signing
   the request once with its (e.g., LDevID) key and then again with its
   (e.g., IDevID) key, which enables a downstream CA to be assured that
   the bootstrapping device possesses the public key being signed.

new:

   Both the CMP and CMC formats entail that the bootstrapping device signs
   the request once with its (e.g., LDevID) key and then again with its
   (e.g., IDevID) key. This enables verifying the proof-of-possession
   of the private key that corresponds to the public key being signed.

    David

--------------D959AA866F979E5D069BEA7C-- From nobody Mon Aug 30 08:58:43 2021 Return-Path: <0100017b97c879d0-c2cd3be9-a2d3-4e6d-9ed8-16e99432ff4c-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 ADF6E3A17F4; Mon, 30 Aug 2021 08:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_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 9CSzF92DzRbQ; Mon, 30 Aug 2021 08:58:26 -0700 (PDT) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EA033A17E5; Mon, 30 Aug 2021 08:58:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1630339103; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=GOLmZB+Ej+Fwk8v5zy5DBjbwXLtYi+VdD7OP91VILK0=; b=gZGoAPyLUpu4WZjcyzVxxzrCeQPSHulvf3pbwnS+THmUnGx39EQrtUcL7phBTNLr r/IxDpdq2yrTAOUMsCvAiaTycNgiS5zka0+REk0D2390CdfEBXOQ8uD6MvIxmjruH/5 4Ap7yfyvnnRkBxu4oPo4fK6r5QbsDMHHlSmh71pE= From: Kent Watsen Message-ID: <0100017b97c879d0-c2cd3be9-a2d3-4e6d-9ed8-16e99432ff4c-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_61D37C6B-ADFD-4177-9F85-D837B32E05B7" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Mon, 30 Aug 2021 15:58:23 +0000 In-Reply-To: <7d5059f5-c0b6-390c-99d3-4fcdc13d445d@siemens.com> 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> X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.08.30-54.240.8.83 Archived-At: Subject: Re: [netconf] New Version Notification for draft-ietf-netconf-sztp-csr-06.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, 30 Aug 2021 15:58:40 -0000 --Apple-Mail=_61D37C6B-ADFD-4177-9F85-D837B32E05B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi David, > Hi Kent, > thanks for your update and providing the diff. > I had a closer look at sections 4.1.5 and 4.2.1 and found some further = issues. >=20 >=20 >=20 > Section 4.1.5 - since correct identity of the request origin is = crucial for any type of identity cert generation: > old: >=20 > A The CSR's origin SHOULD be verified before a certificate is issued. >=20 > new: =20 >=20 > The origin of the CSR MUST be verified before a certificate is issued. >=20 Ack. =20 Perhaps replace =E2=80=9CMUST=E2=80=9D with =E2=80=9Cmust=E2=80=9D, = since the behavior is normatively defined by other documents?=20 > Section 4.2.1 - actually, a proof-of-possession can and should be done = in all addressed situations, > while for PKCS#10 it is hard to link this to a proof-of-origin. > old: >=20 > When the bootstrapping device's manufacturer-generated private key =20= > (e.g., the IDevID key) is reused for the CSR, proof-of-possession is = =20 > verified by ensuring the CSR was signed by that key. =20 >=20 > When a new asymmetric key is used, proof-of-possession may be =20 > verified, with the CMP or CMC formats, by ensuring the parent ASN.1 =20= > structure containing the CSR is signed by the manufacturer-generated = key. =20 >=20 > new: >=20 > Since the CSR should have been self-signed using the private key=20 > corresponding to the public key placed in the CSR, the = proof-of-possession > can be checked by verifying this signature using the included public = key. >=20 > With the CMP or CMC formats, this proof-of-origin is directly linked = to the > proof-or-origin provided by the parent ASN.1 structure, which contains > origin authentication using the manufacturer-generated private key or = using > the shared secret. The current section is titled "Verifying Proof of Possession=E2=80=9D. = I think that new =E2=80=9Cproof of origin" text should go into a new = section called "Verifying Proof of Origin=E2=80=9D. Something like = this: Verifying Proof of Possession Regardless if using a new asymmetric key or the bootstrapping device's manufacturer-generated key (e.g., the IDevID key), the public key is placed in the CSR and the CSR is signed by that private key. Proof-of-possession of the private key is verified by ensuring the signature over the CSR using the public key placed in the CSR. Verifying Proof of Origin 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 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. Thoughts? K. --Apple-Mail=_61D37C6B-ADFD-4177-9F85-D837B32E05B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = David,


Hi Kent,

thanks for your = update and providing the diff.
I had a closer look at sections 4.1.5 and 4.2.1 and found some further issues.


  • Section 4.1.5 - since correct identity of the = request origin is crucial for any type of identity cert = generation:

old:

A The CSR's origin SHOULD be verified = before a certificate is issued.

new:  =

The origin of the = CSR MUST be verified before a certificate is issued.


Ack.  

Perhaps replace =E2=80=9CMUST=E2=80=9D with = =E2=80=9Cmust=E2=80=9D, since the behavior is normatively defined by = other documents? 


  • Section 4.2.1 - actually, a proof-of-possession can = and should be done in all addressed situations,
    while for PKCS#10 it is hard to link this to a = proof-of-origin.

old:

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

When a new asymmetric key is used, proof-of-possession may = be   
verified, with the CMP or CMC formats, by ensuring the parent ASN.1   
structure containing the CSR is signed by the manufacturer-generated key.   

new:

Since the CSR should have been self-signed using = the private key
corresponding to the public key placed in the CSR, the proof-of-possession
can be checked by verifying this signature using the included public key.

With the CMP or CMC formats, this proof-of-origin is directly linked to the
proof-or-origin provided by the parent ASN.1 structure, which contains
origin authentication using the manufacturer-generated private key or using
the shared secret.


The current section is = titled "Verifying Proof of Possession=E2=80=9D.  I think that new = =E2=80=9Cproof of origin" text should go into a new section called = "Verifying Proof = of Origin=E2=80=9D.  Something like = this:


= Verifying Proof of Possession

Regardless if using a = new asymmetric key or the = bootstrapping
device's manufacturer-generated = key (e.g., = the IDevID key), the
public key is = placed in the CSR and the CSR is signed by that
private key. =  Proof-of-possession of = the private key is verified
= by ensuring the signature over the CSR using the public key
placed in = the CSR.


= 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.   

= 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.


Thoughts?

K.


= --Apple-Mail=_61D37C6B-ADFD-4177-9F85-D837B32E05B7-- From nobody Mon Aug 30 09:11:01 2021 Return-Path: <0100017b97d3e272-f8b7f123-6693-45a2-94d4-9e77de2d169d-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 01FD63A1817 for ; Mon, 30 Aug 2021 09:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 i1-jMX-Xsu3s for ; Mon, 30 Aug 2021 09:10:52 -0700 (PDT) Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB2683A1813 for ; Mon, 30 Aug 2021 09:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1630339851; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=8fVGCemwZ+wWaXIj7sfuoN/qHKjWjnKrUxYSE9CR5aA=; b=iXwVXuHmnwwJs5loeRk3Jfq/oS9dRx/Asyk83N6Bj+VSEWXycr7ZEhc7g7ZaU+DW Ja53Y7otLdUHLXxRlO6VgsLI8/DT0ZMnVxOHK2Lz6HbeTi7JlQNrgntkDNfT3Hg85r7 i4tm8Bjf6fsWCG6ixk/DjtaILVfsLV2gSBRhxzNo= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Kent Watsen In-Reply-To: Date: Mon, 30 Aug 2021 16:10:50 +0000 Cc: "netconf@ietf.org" , Juergen Schoenwaelder Content-Transfer-Encoding: quoted-printable Message-ID: <0100017b97d3e272-f8b7f123-6693-45a2-94d4-9e77de2d169d-000000@email.amazonses.com> References: <010001798c0d947e-4d2d14f5-9f0e-450d-ac99-e18c260f0c2b-000000@email.amazonses.com> <01000179a0aa5d37-4810234e-8db2-434d-b8fa-780c1648955a-000000@email.amazonses.com> <01000179a5bdc371-b665451f-61d4-4364-9d55-e9369f3adc8e-000000@email.amazonses.com> <0100017a0aebfbf3-9e9c22e8-da12-4364-a572-8ce7fd43bf0f-000000@email.amazonses.com> <540b31e5-10a6-495f-cf44-820adb6213b3@sit.fraunhofer.de> <20210615121804.weihro7eusvnfym6@anna.jacobs.jacobs-university.de> To: tom petch X-Mailer: Apple Mail (2.3654.120.0.1.13) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.08.30-54.240.48.110 Archived-At: Subject: Re: [netconf] More complications 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, 30 Aug 2021 16:10:59 -0000 I think we are overlooking that the ietf-tls-client/server models are = not solely for NETCONF protocol, e.g., the RESTCONF CLIENT/SERVER, = SYSLOG, and PCEP modules also import the TLS modules. The desire to = support PSKs and RPKs in the TLS modules is not (yet) for the NETCONF = WG. That said, I=E2=80=99m beginning to want to remove the support for them = if it holds up publication. To be clear, we=E2=80=99re waiting to = determine how best to model TLS 1.3 support while maintaining TLS 1.2 = support. I=E2=80=99ll ping Henk again. K. > On Jun 15, 2021, at 12:22 PM, tom petch wrote: >=20 > From: netconf on behalf of Juergen = Schoenwaelder > Sent: 15 June 2021 13:18 >=20 > The way TLS is used with NETCONF is defined in RFC 7589. If any of > that needs clarification to properly support TLS 1.3, then we need to > revise RFC 7589. Defining the proper configuration knobs should follow > from that. >=20 > > You wisely pointed out this before and then and now, I re-read RFC7589 = and think that updating it will take some time and that I am unclear how = much scope it gives us for the time being. >=20 > It only mentions TLS1.2 (of course) but does not prohibit other = versions so arguably caters for some forms of TLS1.3. >=20 > It is very keen on certificates but allows for other suitable mutual = authentication which could be taken to include PSK but would appear not = to cater for deriving a username from a PSK (s.7) which suggests PSK is = out of scope. TLS regards a public key as a certificate which is fine = until you need a subjectAltName or some such from which to derive the = username, which the RFC does so that would seem to be out of scope.=20 >=20 > It does not cover TLS keepalive (which netconf-tls does). >=20 > So, TLS1.3 with proper certificates would seem to be the only option. >=20 > Tom Petch >=20 > And as Kent reminds us, the scope of the TLS configuration draft is > much wider than just NETCONF over TLS. Hence, dropping support for > certain TLS 1.3 features, that may be essential in some use cases, > should be done with great care. (And lets keep in mind that dropping > standard configuration knobs just means that there are no standard > configuration knobs, it does not mean that a certain protocol feature > won't be used, it will just be configured using other non-standard > means). >=20 > /js >=20 > On Tue, Jun 15, 2021 at 01:53:19PM +0200, Henk Birkholz wrote: >> Hi all, >>=20 >> a fellow IETF'ler poked me to pay attention to this thread. Sorry for = the >> latency. >>=20 >> Hm - dropping PSK support for TLS 1.3 seems to be leaving a bunch of >> implementations in the IoT space behind that are inching towards = migration, >> currently. >>=20 >> How urgent is this? I can certainly massage the current YANG module, = but (in >> theory) I am occupied by another SDO meeting this week. >>=20 >> Viele Gr=C3=BC=C3=9Fe, >>=20 >> Henk >>=20 >>=20 >> On 15.06.21 13:36, tom petch wrote: >>> From: Kent Watsen >>> Sent: 14 June 2021 15:27 >>>=20 >>> [CC-ing Henk, to whom a question is directed to below] >>>=20 >>>=20 >>> Hi Tom, >>>=20 >>>> Top posting a new and different issue. >>>=20 >>> Thanks for updating the subject line. >>>=20 >>>=20 >>>> server case psk references ServerKeyExchange and psk-identity-hint = neither of which exist in TLS1.3. The client sends an extension = PreSharedKeyExtension which contains a list of identities from which the = server selects one as selected-identity for which the identifier is = uint16 indexing into the client's list. RFC8446 s.4.2.11. >>>>=20 >>>> The client description also needs amending. >>>>=20 >>>> TLS1.2 was extended to use tickets in this area to aid session = resumption; these have now gone and been replaced by this extension. I = would not suggest adding support for tickets. >>>>=20 >>>> As I may have said before, TLS 1.3 is different. >>>=20 >>> Henk, could you help with these edits? Support for PSK and raw = public key were added to draft-ietf-netconf-tls-client-server per your = request and, if memory serves me, didn=E2=80=99t you help me with the = YANG update too? I suppose what is needed is a either a =E2=80=9Cchoice=E2= =80=9D statement (with cases for 1.2 and 1.3) *or* sibling-container = statements (in case it=E2=80=99s necessary both are configured in case, = e.g., the client sends one or the other)... >>>=20 >>> >>> Or else drop support for PSK with TLS1.3 at this time because too = little is known about it outside the use for HTTP. I am starting to see = I-D about how to use TLS1.3 with application X, even for HTTP, and I = think that such an I-D will be needed for many applications with or = without PSK. >>>=20 >>> Tom Petch >>>=20 >>>> Tom Petch >>>=20 >>> Kent >>>=20 >>=20 >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Aug 31 00:56:16 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 3B1F03A3763; Tue, 31 Aug 2021 00:56:13 -0700 (PDT) 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, 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=smyslov.net 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 5S7aOfowizco; Tue, 31 Aug 2021 00:56:07 -0700 (PDT) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (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 A9DE03A3761; Tue, 31 Aug 2021 00:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To: References:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=biQPn0sYKpES3YLipMAPnhiVH8u9WhGjSq/TWLtQRHs=; b=qKWPeLHCuAK76hIlYnFNhi6BOE i8SvQAqCa2LTi/RxQ9igPdYdGjFsp10dy/XuT3RBAGTF+arbgFTQ8eHyQLt8KLlB3QQrdR6pEzQCr 1Ytxz6Fh+8Haur5JHptWYFzC2tMD+SMxCXj0vAA6lA4E3sdrUcLlP9nY3cmH60r8Pr6R+M3qC+0RX 6gX79yk7CTLCTbQto27uwnjP6bAdqFFuPsw780fULM8iTTmXf3b0ZRAkj2DmwRNTkc/cTvV/8xPSI XvEymk8wg7vmmfdOg9xlVQ4yzuOctH867/5inehW3p3Ao6jPiS8HaBB0stuspJ9WW/HRc4K44U98v OwidMvrg==; Received: from [93.188.44.204] (port=61675 helo=buildpc) by direct.host-care.com with esmtpsa (TLS1.2) tls TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mKycj-00033h-Cn; Tue, 31 Aug 2021 03:56:02 -0400 From: "Valery Smyslov" To: "'Kent Watsen'" Cc: , , References: <162982978380.3381.17549750696257276827@ietfa.amsl.com> <0100017b8819bf19-1f20d528-72e4-462c-884a-6c29eff0769b-000000@email.amazonses.com> <017c01d79b5e$a00a0000$e01e0000$@smyslov.net> <0100017b89613006-504db539-c16c-4c87-8772-2b6676e9c295-000000@email.amazonses.com> In-Reply-To: <0100017b89613006-504db539-c16c-4c87-8772-2b6676e9c295-000000@email.amazonses.com> Date: Tue, 31 Aug 2021 10:56:00 +0300 Message-ID: <034d01d79e3d$a5b5d5b0$f1218110$@smyslov.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_034E_01D79E56.CB07A190" X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQGndKy5sGszK4BuDx47nymU5VnBUwHC5W7jAisjdPUBQDIbDqvEDG5g X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net Archived-At: Subject: Re: [netconf] [Last-Call] Secdir last call review of draft-ietf-netconf-crypto-types-20 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, 31 Aug 2021 07:56:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_034E_01D79E56.CB07A190 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Kent, =20 please. see inline. =20 Hi Valery, =20 On Aug 27, 2021, at 12:14 PM, Valery Smyslov wrote: =20 Hi Kent, =20 thank you for addressing my comments. A bit more inline. =20 All good. =20 =20 [removing =E2=80=9Clast-call=E2=80=9D alias] =20 =20 Hello Valery. =20 =20 Thank you for your SecDir review, it is very much appreciated and never = too late! =20 More comments below. =20 Thanks, Kent =20 On Aug 24, 2021, at 2:29 PM, Valery Smyslov via Datatracker < = noreply@ietf.org> wrote: =20 Reviewer: Valery Smyslov Review result: Has Issues I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area = directors. Document editors and WG chairs should treat these comments just like any = other last call comments. When I was re-assigned to review this draft the indicated deadline was = already missed by 8 months, so I don't know how relevant the review is. I = reviewed the latest -20 version of the draft instead of -18, that was requested. =20 Perfect. =20 The draft defines common YANG data types and groupings useful for = cryptography. I din't try to check the YANG module itself.=20 Issues: Shouldn't a Privacy Considerations section be added to the draft? The draft defines quite a lot of privacy-sensitive information (like = certificates) with no restriction on read access (as far as I understand). =20 =20 Both the "trust-anchor-cert-grouping=E2=80=9D and = =E2=80=9Cend-entity-cert-grouping=E2=80=9D groupings have = "nacm:default-deny-write=E2=80=9D that, to your point, does not restrict = reads. That said, only management protocols having mutual = authentication (e.g., SSH and/or TLS based transport) can access the = data. =20 =20 Is your concern that the certificate=E2=80=99s content would be visible = to the administrators? Is your comment on end-entity certificates = (containing personally-identifying information), more than = trust-anchor-certificates? =20 Yes, it=E2=80=99s mostly on end-entity certificates, however = there may be quite a lot of interesting private information besides certificates. =20 If this information is only visible to the administrators and = the used management protocols must=20 have mutual authentication, then it=E2=80=99s probably not a = big deal. I would have still added a sentence about privacy of the stored data (i.e. that = persons, that are allowed to access this data are able to learn quite a lot of private information from it). = I don=E2=80=99t insist though, it=E2=80=99s up to you. =20 =20 I added the following to Section 3.8 (The "ietf-crypto-types" YANG = Module). =20 The "cert-data" node: The "cert-data" node, defined in both the = "trust-anchor-cert-grouping" and "end-entity-cert-grouping" groupings, is = additionally sensitive to read operations, as certificates sometimes convey = personally identifying information (especially end-entity certificates). = However, as it is commonly understood that certificates are "public", = the NACM extension "nacm:default-deny-write" (not "default-deny-all") = has been applied. It is RECOMMENDED that implementations adjust = read-access to certificates to comply with local policy. Is this okay? =20 Yes, thanks. =20 Separately, I thought about if there are any other values in the module = that may have privacy concerns but was unable to locate any. =20 certificate-signing-request? =20 =20 Section 3.5. While I understand and support the idea, expressed in this section, I = think that the way it is expressed makes it difficult to follow in practice. In = general, it's not always obvious how to estimate the "strength" of the underlying = secure transport. For this reason it's not clear for me how it is supposed to "compare" = the=20 "strength" of the transport with the "strength" of the keys being = transported. =20 =20 All comments from this point to the end regard the Security = Consideration "Strength of Keys Conveyed=E2=80=9D (was "Strength of Keys = Configured=E2=80=9D). I rewrote the section as follows. Can you please = check for accuracy? =20 Strength of Keys Conveyed When accessing key values, it is desireable that = implementations ensure that the strength of the keys being accessed is not = greater than the strength of the underlying secure transport = connection over which the keys are conveyed. However, comparing key = strengths can be complicated and difficult to implement in practice. That said, expert Security opinion suggests that already it = is infeasible to break a 128-bit key using a classical = computer, and=20 =20 s/key/symmetric key/ thus the concern for conveying higher-strength keys begins = to lose=20 its allure. Implementations SHOULD only use transport algorithms to = those=20 s/transport algorithms/secure transport/ meeting local policy. A reasonable policy may, e.g., state = that=20 only algorithms listed as "recommended" by the IETF be used. s\algorithms/ciphersuites/ Another reasonable policy may be to only use = quantum-resistant=20 algorithms. Works for me with changes above. I would only add a few words = at the end of the second para that=20 things may change in the future (e.g. if full-size quantum = computers appear), so it is recommended to follow up-to-date advise from crypto = community when protecting transport channel. I would also remove the last sentence in the last para, mostly = because it=E2=80=99s difficult to follow in practice (we still know = not much about post-quantum crypto and generally it=E2=80=99s not yet widely supported in = protocols like TLS) and instead reference RFC 7525 which contains recommendations how to use TLS in applications. I don=E2=80=99t know in similar RFC exists for SSH, sorry... Regards, Valery. Thanks! Kent, as author =20 =20 I saw language like this once in a DoD setting. I agree that it is = difficult to implement in practice. I used =E2=80=9CSHOULD=E2=80=9D = (not MUST) to buy some leeway for implementations to be compliant. = Makes sense? =20 My understanding of using RFC2119 language is that SHOULD is = very close to MUST, but allows some exceptions. So, I still think that you put a = responsibility to make security-related decisions on implementers, who often are not = experts in this area. =20 FWIW, my YANG-driven server is able to remember what key the client used = for authentication (e.g., RSA 2048) and register a callback to test that = no greater keys (e.g., 3072 or 4096) are configured by that client. = Additional=20 =20 What if the other key configured for the client is X25519? = Which is stronger? =20 logic would be needed to prevent a low-strength client from *reading* a = high-strength key configured by another client=E2=80=A6though the issue = can be alternatively resolved by configuring the TLS-stack to prevent = low-strength algorithms. =20 That was my point. I think that it=E2=80=99s better to require = (by SHOULD) that only those ciphersuites that were =E2=80=9Cvetted=E2=80=9D by IETF = (i.e. got =E2=80=9CRecommended=E2=80=9D status) be used. This will make implementers=E2=80=99 life easier. =20 In addition, the requirement, that "Implementations SHOULD fail the = write-request if ever the strength of the private key is greater then the strength of the underlying transport" looks wrong to me. You don't need to have 1024 bits transport protocol strength to transfer 1024 bit key, since even for say 256 bits it's infeasible to break. =20 IDK about this. Again, I saw this constraint once in a DoD setting. =20 =20 My (another) point was that there is generally no point to = increase security strength beyond some level. Currently it is believed that 128 bit of symmetric key is infeasible to break (provided = the algorithm is not broken itself), If you are lucky have full-sized Post Quantum computer, = it=E2=80=99ll be 256 bits. It=E2=80=99s enough to transfer symmetric keys with say 1024 = bits of entropy (FWIW). So the requirement that the strength of transport must be always greater than the strength of transported key=20 seems not a good requirement to me. Instead require that the strength of transport be sufficient to make infeasible for an attacker to break it. =20 I think that the better approach would be to advise using strong ciphersuites for transport protocols defined in corresponding RFCs. For example, for TLS 1.3 there are ciphersuites marked as "recommended", that were evaluated by IETF crypto community. =20 I added this sentence: =20 Implementations SHOULD configure allowed transport=20 algorithms to include only those meeting local policy (e.g., listed as "recommended" by the IETF). =20 Good? =20 Perfect. =20 Regards, Valery. =20 ------=_NextPart_000_034E_01D79E56.CB07A190 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Kent,

 

please. see inline.

 

Hi Valery,

 



On = Aug 27, 2021, at 12:14 PM, Valery Smyslov <valery@smyslov.net> = wrote:

 

Hi Kent,

 

thank you for addressing my comments. A bit more = inline.

 

All good.  

 



[removing = =E2=80=9Clast-call=E2=80=9D = alias]

 

 

Hello Valery.  

 

Thank you for your SecDir review, it is very much = appreciated and never too late!

 

More comments = below.

 

Thanks,

Kent

 




On Aug 24, 2021, at 2:29 PM, Valery Smyslov via = Datatracker <noreply@ietf.org> = wrote:

 

Reviewer: Valery Smyslov
Review result: Has = Issues

I have reviewed this document as part of the security = directorate's ongoing
effort to review all IETF documents being = processed by the IESG.  These
comments were written primarily = for the benefit of the security area directors.
Document editors and = WG chairs should treat these comments just like any other
last call = comments.

When I was re-assigned to review this draft the = indicated deadline was already
missed by 8 months, so I don't know = how relevant the review is. I reviewed
the latest -20 version of the = draft instead of -18, that was = requested.

 

Perfect.

 




The draft defines common YANG data types and groupings = useful for cryptography.
I din't try to check the YANG module = itself. 

Issues:

Shouldn= 't a Privacy Considerations section be added to the draft?
The draft = defines quite a lot of privacy-sensitive information (like = certificates)
with no restriction on read access (as far as I = understand).

 

 

Both the "trust-anchor-cert-grouping=E2=80=9D and = =E2=80=9Cend-entity-cert-grouping=E2=80=9D groupings = have "nacm:default-deny-write=E2=80=9D that, to your point, = does not restrict reads.  That said, only management protocols = having mutual authentication (e.g., SSH and/or TLS based transport) can = access the data.  

 

Is your concern that the = certificate=E2=80=99s content would be visible to the administrators? =  Is your comment on end-entity certificates (containing = personally-identifying information), more than = trust-anchor-certificates?

 

        &= nbsp; Yes, it=E2=80=99s mostly on end-entity certificates, however there = may be quite a lot of interesting

          private = information besides certificates.

 

          If this = information is only visible to the administrators and the used = management protocols must 

          have mutual = authentication, then it=E2=80=99s probably not a big deal. I would have = still added

          a sentence = about privacy of the stored data (i.e. that persons, that are allowed to = access this data

          are able to = learn quite a lot of private information from it). I don=E2=80=99t = insist though, it=E2=80=99s up to = you.

 

 

I = added the following to Section 3.8 (The "ietf-crypto-types" = YANG Module).

 

            =  The "cert-data" node:

      =              The = "cert-data" node, defined in both the = "trust-anchor-cert-grouping"
        =             and = "end-entity-cert-grouping" groupings, is additionally = sensitive to
                =     read operations, as certificates sometimes = convey personally identifying
          =           information (especially = end-entity certificates).  However, as it is
  =                 =   commonly understood that certificates are = "public", the NACM extension
        =           =   "nacm:default-deny-write" = (not "default-deny-all") has been applied. It
  =                   is = RECOMMENDED that implementations adjust read-access to = certificates
                =     to comply with local = policy.

Is this okay?

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yes, = thanks.

 

Separately, I thought about if there are any other = values in the module that may have privacy concerns but was unable to = locate any.

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = certificate-signing-request?

 

 

Section 3.5.
While I understand and support the = idea, expressed in this section, I think that
the way it is expressed = makes it difficult to follow in practice. In general, it's
not always = obvious how to estimate the "strength" of the underlying = secure transport.
For this reason it's not clear for me how it is = supposed to "compare" the 
"strength" of = the transport with the "strength" of the keys being = transported.

 

 

All comments from this = point to the end regard the Security Consideration "Strength of = Keys Conveyed=E2=80=9D (was "Strength of = Keys Configured=E2=80=9D).  I rewrote the section as follows. =  Can you please check = for accuracy?

 

    =   Strength of Keys Conveyed


      =      When accessing key values, it is = desireable that implementations
        =     ensure that the strength of the keys = being accessed is not greater
          =   than the strength of the underlying secure transport = connection
            over which = the keys are conveyed.  However, comparing key = strengths
            can be = complicated and difficult to implement in = practice.


           That = said, expert Security opinion suggests that already it is
  =           infeasible to break a 128-bit = key using a classical computer, and 

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = s/key/symmetric key/


        =     thus the concern for conveying higher-strength keys = begins to lose 
          =   its allure.


          =   Implementations SHOULD only use transport algorithms to = those 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 s/transport = algorithms/secure transport/

          =   meeting local = policy.  A reasonable policy may, e.g., state = that 
            only = algorithms listed as "recommended" by the IETF be = used.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = s\algorithms/ciphersuites/


          =   Another reasonable policy may be to only = use quantum-resistant 
          =   algorithms.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Works for me = with changes above. I would only add a few words at the end of the = second para that =
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 things may = change in the future (e.g. if full-size quantum computers = appear),
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 so it = is recommended to follow up-to-date advise from crypto = community
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 when = protecting transport channel.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I would also = remove the last sentence in the last para, mostly = because
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = it=E2=80=99s difficult to follow in practice (we still know not much = about post-quantum = crypto
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and = generally it=E2=80=99s not yet widely supported in protocols like TLS) = and instead reference RFC = 7525
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 which = contains recommendations how to use TLS in = applications.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = I don=E2=80=99t know in similar RFC exists for SSH, = sorry...

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Regards,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Valery.

Thanks!

Kent, as = author

 



 

I saw language like this once in a = DoD setting.  I agree that it is difficult to implement in = practice.  I used =E2=80=9CSHOULD=E2=80=9D (not MUST) to buy = some leeway for implementations to be compliant.  Makes = sense?

 

          My = understanding of using RFC2119 language is that SHOULD is very close to = MUST,

          but allows = some exceptions. So, I still think that you put a responsibility to = make

          = security-related decisions on implementers, who often are not experts in = this area.

 

FWIW, my YANG-driven server is able to remember what = key the client used for authentication (e.g., RSA 2048) and register a = callback to test that no greater keys (e.g., 3072 or 4096) are = configured by that client.  Additional 

 

          What if the = other key configured for the client is X25519? Which is = stronger?

 

logic would be needed to prevent a low-strength client from = *reading* a high-strength key configured by another = client=E2=80=A6though the issue can be alternatively resolved by = configuring the TLS-stack to prevent low-strength = algorithms.

 

          That was my = point. I think that it=E2=80=99s better to require (by SHOULD) that = only

          those = ciphersuites that were =E2=80=9Cvetted=E2=80=9D by IETF (i.e. got = =E2=80=9CRecommended=E2=80=9D status) be = used.

          This will make = implementers=E2=80=99 life = easier.

 

In addition, the requirement, that = "Implementations SHOULD fail the write-request if ever
the = strength of the private key is greater then the strength of = the
underlying transport" looks wrong to me. You don't need to = have
1024 bits transport protocol strength to transfer 1024 bit key, = since
even for say 256 bits it's infeasible to = break.

 

IDK about this.  Again, I saw this constraint = once in a DoD setting.  

 

          My (another) = point was that there is generally no point to = increase

          security = strength beyond some level. Currently it is = believed

          that 128 bit = of symmetric key is infeasible to break (provided the algorithm is not = broken itself),

          If you are = lucky have full-sized Post Quantum computer, it=E2=80=99ll be 256 = bits.

          It=E2=80=99s = enough to transfer symmetric keys with say 1024 bits of = entropy

          (FWIW). So the = requirement that the strength of transport = must

          be always = greater than the strength of transported key 

          seems not a = good requirement to me. Instead require = that

          the strength = of transport be sufficient to make

          infeasible for = an attacker to break it.

          

I think that = the better approach would be to advise using strong
ciphersuites for = transport protocols defined in corresponding RFCs.
For = example, for TLS 1.3 there are ciphersuites marked as = "recommended",
that were evaluated by IETF crypto = community.

 

I added this = sentence:

 

        &n= bsp; Implementations SHOULD = configure allowed transport 
        &n= bsp; algorithms = to include only those meeting = local

        &n= bsp; policy = (e.g., listed as "recommended" by = the IETF).

 

Good?

 

        &= nbsp; Perfect.

 

        &= nbsp; Regards,

          = Valery.


 

------=_NextPart_000_034E_01D79E56.CB07A190-- From nobody Tue Aug 31 04:50:29 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 6942F3A0FB9 for ; Tue, 31 Aug 2021 04:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Cz_2z5aZW-fY for ; Tue, 31 Aug 2021 04:50:20 -0700 (PDT) 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 EE49E3A0EFD for ; Tue, 31 Aug 2021 04:50:19 -0700 (PDT) Received: from fraeml702-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GzQSQ47Hqz67xh9 for ; Tue, 31 Aug 2021 19:48:38 +0800 (CST) Received: from dggeme720-chm.china.huawei.com (10.1.199.116) by fraeml702-chm.china.huawei.com (10.206.15.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.8; Tue, 31 Aug 2021 13:50:15 +0200 Received: from dggeme770-chm.china.huawei.com (10.3.19.116) by dggeme720-chm.china.huawei.com (10.1.199.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.8; Tue, 31 Aug 2021 19:50:13 +0800 Received: from dggeme770-chm.china.huawei.com ([10.8.68.58]) by dggeme770-chm.china.huawei.com ([10.8.68.58]) with mapi id 15.01.2308.008; Tue, 31 Aug 2021 19:50:13 +0800 From: "maqiufang (A)" To: "netconf@ietf.org" Thread-Topic: New Version Notification for draft-tao-netconf-data-export-capabilities-06.txt Thread-Index: AQHXngcAPpGKH3P1qEeEhJncNNQJHKuM03og Date: Tue, 31 Aug 2021 11:50:13 +0000 Message-ID: <50fe0cb365fc4f939d6ca7b6787ab9bd@huawei.com> References: <163037308409.31773.13330270465217383725@ietfa.amsl.com> In-Reply-To: <163037308409.31773.13330270465217383725@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.123.93] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] New Version Notification for draft-tao-netconf-data-export-capabilities-06.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: Tue, 31 Aug 2021 11:50:27 -0000 SGksIGFsbA0KVi0wNiBpcyBhdmFpbGFibGUgbm93LiANClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRz IHJhaXNlZCBieSBNYWhlc2gsIFJvYmVydCBhbmQgQmFsYXpzLCBtdWNoIGFwcHJlY2lhdGVkLiAN ClRoZSBmb2xsb3dpbmcgY2hhbmdlcyBoYXZlIGNvbnNpZGVyZWQgdGhlbSBhbGw6DQogICAqICBS ZXZpc2UgYWJzdHJhY3QgYW5kIGludHJvZHVjdGlvbiBzZXNzaW9ucyBzbyB0aGF0IHRoZSBzY29w ZSBvZg0KICAgICAgdGhpcyBkcmFmdCBpcyBub3QgbGltaXRlZCB0byB0ZWxlbWV0cnkgYnV0IG90 aGVyIG5vdGlmaWNhdGlvbi4NCiAgICogIFJldmlzZSB0aGUgZGVzY3JpcHRpb24gb2YgbW9kdWxl IGlldGYtc3lzdGVtLWNhcGFiaWxpdGllcyB0byBhbGlnbg0KICAgICAgd2l0aCB0aGUgbGF0ZXN0 IHZlcnNpb24gb2YgZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi0NCiAgICAgIGNhcGFi aWxpdGllcy4NCiAgICogIFJlbW92ZSBjb21wcmVzc2lvbi1tb2RlLCB0aW1lci1ldmVudC1zdXBw b3J0IGFuZCBzdXBwcmVzcy0NCiAgICAgIHJlZHVuZGFudCBwYXJhbWV0ZXJzIGluIHRoZSBtb2Rl bC4NCiAgICogIE1vdmUgcGVyLW5vZGUgcmVsYXRlZCBjYXBhYmlsaXR5IHBhcmFtZXRlcnMgdG8g YXBwZW5kaXggc2VjdGlvbi4NCiAgICogIEFkZCBhIGNvbnRhaW5lciB0byB3cmFwIGRhdGEgZXhw b3J0IGNhcGFiaWxpdGllcyB0byBjbGVhbmx5DQogICAgICBzZXBhcmF0ZSBkaWZmZXJlbnQgZ3Jv dXBzIG9mIGNhcGFiaWxpdGllcy4NClRoZSBkaWZmIGlzIGF2YWlsYWJsZSBhdCA6IGh0dHBzOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC10YW8tbmV0Y29uZi1kYXRhLWV4cG9ydC1j YXBhYmlsaXRpZXMtMDYgDQpBbnkgZnVydGhlciBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJl IHdlbGNvbWUuIFRoYW5rIHlvdS4NCg0KQmVzdCBSZWdhcmRzLA0KUWl1ZmFuZyBNYShPbiBiZWhh bGYgb2YgYXV0aG9ycykNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpT ZW50OiBUdWVzZGF5LCBBdWd1c3QgMzEsIDIwMjEgOToyNSBBTQ0KVG86IFBlbmcgTGl1IDxsaXVw ZW5neWp5QGNoaW5hbW9iaWxlLmNvbT47IFFpbiBXdSA8YmlsbC53dUBodWF3ZWkuY29tPjsgUWlu IFd1IDxiaWxsLnd1QGh1YXdlaS5jb20+OyBtYXFpdWZhbmcgKEEpIDxtYXFpdWZhbmcxQGh1YXdl aS5jb20+OyBXZWkgV2FuZyA8d2FuZ3czNkBjaGluYXRlbGVjb20uY24+DQpTdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXRhby1uZXRjb25mLWRhdGEtZXhwb3J0LWNh cGFiaWxpdGllcy0wNi50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdGFvLW5l dGNvbmYtZGF0YS1leHBvcnQtY2FwYWJpbGl0aWVzLTA2LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBRaXVmYW5nIE1hIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3Np dG9yeS4NCg0KTmFtZToJCWRyYWZ0LXRhby1uZXRjb25mLWRhdGEtZXhwb3J0LWNhcGFiaWxpdGll cw0KUmV2aXNpb246CTA2DQpUaXRsZToJCURhdGEgRXhwb3J0IE5vdGlmaWNhdGlvbiBDYXBhYmls aXR5DQpEb2N1bWVudCBkYXRlOgkyMDIxLTA4LTMwDQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlz c2lvbg0KUGFnZXM6CQkxNg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2Fy Y2hpdmUvaWQvZHJhZnQtdGFvLW5ldGNvbmYtZGF0YS1leHBvcnQtY2FwYWJpbGl0aWVzLTA2LnR4 dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXRhby1uZXRjb25mLWRhdGEtZXhwb3J0LWNhcGFiaWxpdGllcy8NCkh0bWxpemVkOiAgICAgICBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXRhby1uZXRjb25mLWRh dGEtZXhwb3J0LWNhcGFiaWxpdGllcw0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC10YW8tbmV0Y29uZi1kYXRhLWV4cG9ydC1jYXBhYmlsaXRp ZXMtMDYNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHByb3Bvc2VzIGEgWUFORyBtb2R1 bGUgZm9yIGRhdGEgZXhwb3J0IG5vdGlmaWNhdGlvbg0KICAgY2FwYWJpbGl0aWVzIHdoaWNoIGF1 Z21lbnRzIFN5c3RlbS1DYXBhYmlsaXRpZXMgbW9kZWwgZGVmaW5lZCBpbiBbSS0NCiAgIEQubmV0 Y29uZi1ub3RpZmljYXRpb24tY2FwYWJpbGl0aWVzXSBhbmQgcHJvdmlkZXMgYWRkaXRpb25hbCBk YXRhDQogICBleHBvcnQgYXR0cmlidXRlcyBhc3NvY2lhdGVkIHdpdGggc3lzdGVtIGNhcGFiaWxp dGllcyBmb3IgdHJhbnNwb3J0DQogICBzcGVjaWZpYyBOb3RpZmljYXRpb24uICBUaGlzIFlBTkcg bW9kdWxlIGNhbiBiZSB1c2VkIGJ5IHRoZSBjbGllbnQgdG8NCiAgIGxlYXJuIGNhcGFiaWxpdHkg aW5mb3JtYXRpb24gZnJvbSB0aGUgc2VydmVyIGF0IHJ1bi10aW1lIG9yDQogICBpbXBsZW1lbnRh dGlvbi0gdGltZSwgcGVyIHRoZSBZQU5HIEluc3RhbmNlIERhdGEgRmlsZSBGb3JtYXQuDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg==