Re: [OPSAWG] Call for adoption: draft-boydseda-ipfix-psamp-bulk-data-yang-model (renamed "draft-arokiarajseda-opsawg-ipfix-data-export-yang-model")

Marta Seda <Marta.Seda@calix.com> Fri, 08 October 2021 15:46 UTC

Return-Path: <Marta.Seda@calix.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056CC3A005C for <opsawg@ietfa.amsl.com>; Fri, 8 Oct 2021 08:46:54 -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, HTML_MESSAGE=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=calix.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 HfhbN4Tr14Xn for <opsawg@ietfa.amsl.com>; Fri, 8 Oct 2021 08:46:48 -0700 (PDT)
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2173.outbound.protection.outlook.com [104.47.58.173]) (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 E9DE53A003C for <opsawg@ietf.org>; Fri, 8 Oct 2021 08:46:47 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kW7py2eifYhcdxvOc5vylkUyJtohH1raFv018G84T/H887OE3kw2kvJ4H4wVWs6sUgw2gth09TdPlvc3X0v+qNDDkoFn5C4bvJZKbAvrRyAJd5Ao5FC2+Mcx1cMRa4+Yb9/FgYYSRhU/szSDVd4e5jNTYhyUO0ewcl9zSENR9XmNiHehZ9ekU36icomn0+JudKBR1typQg5flkQ1O3PxEkC8RRQfjS5eoUAX9DDnKt6Stot3r9ALuH5iFN1S2pmVkEz+0+6HnV0u20rmGfXb6wFPR8Ik03NgAMSD+PhSgR7GKJ7tMf7FlHKZhPQ+mkRt+CXCwB/ivXIHf6u8C8sDNQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qUAp8iKureRF3OEKU9dqLob3ocJkOYIK+FRjaj3ku9A=; b=fvmWCFUMELWHGGPtW/XdzZiNaDrzrXMHL8d8d1SXTElmWhD3b3OJOy80Hy8luZHRbBzVJrXcc32qX1rr7ffT+fk3brAOp4vqqMA+/OmZZ2/1tNDO5ZOXe+QDOF1uUVjQYdubX8O7Vf3JtZaHz+88tcuptBESS6uKz11u52Bn1TIZj/iUbYpbcVjALs64fZMacHOMv0MZcBeYy5XYiGjza6hjLmRHt/d5f8GSNJ3KPBb7uEthbxvifHGa2ymh52s5bIzaamePDOVy7kddwYKLltIf/Mx6KvC+x4Z7OQD9k0bf0wF0luZrJXtR+mUm4cUqQabHWsXHDCVsLvnB3lLH9Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=calix.com; dmarc=pass action=none header.from=calix.com; dkim=pass header.d=calix.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=calix.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qUAp8iKureRF3OEKU9dqLob3ocJkOYIK+FRjaj3ku9A=; b=HJKmU+TmZKUcJrZf3zvfve77KwUthsBNs8uTWSWmOAmbvr6GSPMD2IBUJTN3P9jAx75p9+ERua+2/R8lAKXPAAmC0a/KRJwKLRlgpNnc2KTJ6jdmAUVHlcl3d70WcvDZymzpLjFCzdjF6xxuMHBzeKAEOuZg/H0nvTfxThlyFqI=
Received: from BY3PR05MB7953.namprd05.prod.outlook.com (2603:10b6:a03:367::17) by BYAPR05MB4517.namprd05.prod.outlook.com (2603:10b6:a02:f3::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.4; Fri, 8 Oct 2021 15:46:44 +0000
Received: from BY3PR05MB7953.namprd05.prod.outlook.com ([fe80::dc58:dd13:2ed6:c804]) by BY3PR05MB7953.namprd05.prod.outlook.com ([fe80::dc58:dd13:2ed6:c804%7]) with mapi id 15.20.4587.017; Fri, 8 Oct 2021 15:46:44 +0000
From: Marta Seda <Marta.Seda@calix.com>
To: "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: [OPSAWG] Call for adoption: draft-boydseda-ipfix-psamp-bulk-data-yang-model (renamed "draft-arokiarajseda-opsawg-ipfix-data-export-yang-model")
Thread-Index: Ade8Wrupx8ok4bf0S9SQUfNgQdXrgQ==
Date: Fri, 08 Oct 2021 15:46:44 +0000
Message-ID: <BY3PR05MB795372F222710E522B9AAEDE9CB29@BY3PR05MB7953.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=calix.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8e858925-a0bc-4b80-e170-08d98a72d470
x-ms-traffictypediagnostic: BYAPR05MB4517:
x-microsoft-antispam-prvs: <BYAPR05MB451714379045AA380A3DE5B89CB29@BYAPR05MB4517.namprd05.prod.outlook.com>
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: IERhpr5oJ6HkIEp1fNze8boe4A+PT/TbTQk9j/C9RxQ+honsIa6QjND8/HD+oQwoFqzrRB3pUy5rIuPeie00mLDj+uwO/2uq/jWDQ2jeCvCJ6xeSjLqE590xhFlvuIC4ZGhUIt1tQPWGF+8y8SFsz+7ECoC0fjxIqq993uB8P5A1P7lC7g1srowjgUyf6OA12gbk+NQ4H9BmuPVzzOvYb2tAScOj2AzhZXQRYrhmyol/T0EBBr2SW6zJSp3ZehPxN8sDDfrViLSvXHxWL6O+qCC+6pYdHV+rsAkmfWDlpQUcC04IC0QkLyubvAp4LV1krmdzE8f3gI8bHIfXuCnYw2sGDrPdVT8B1txkOpUvKc1fRmJ36Hf3W29UdwKRl+6iPOIZcvd1fWIevYyfzVE4Uyo6/9iv763M/IYqSPEF2KSmKCLpfHCId8J89e/7EaG16NxdLazJgWg3ss0juLu6xJ/HfIneEbBLfkXhc+B9rgCBs5pNmN2zKEJhRRsl1tvUd/NdNIPHyRc6zq2h7EoUwrvdzGrBT7g+e9vo3+7L3xY6fwjLgjxoNVK7XjzwcqTreM142XWErZlk4cxaiifwbMRWB+n0WzjP1yVpDKn/HDGd5kndKWjfOiAX74wVG8CT6agkyVhITPf9RiIS4S02rvhIHmodVssYdZkAsC9IS6Zkvtm/oTWC3t6oEJqYHEeQipHT/QNUFjVRc2buajeYiEeKVOKcroL3gIujC1iaTuYLNXZFsy51Bz7ZvZAWCnebicsJYR0WOOBSYVsKimQ+goJ+GQIBebBPCLQ8CDV1WLs=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR05MB7953.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(2906002)(30864003)(83380400001)(76116006)(71200400001)(66476007)(4743002)(26005)(66446008)(186003)(6506007)(6916009)(122000001)(66946007)(966005)(508600001)(316002)(4001150100001)(66556008)(64756008)(38070700005)(52536014)(38100700002)(86362001)(33656002)(9686003)(166002)(5660300002)(55016002)(8676002)(55236004)(8936002)(7696005)(53546011); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: OrFrTaAycoZI7NXnd3MHFs12YmzFpER+AqjNLtLXUHDqvg3zvnc8zWac5PnROOJvLmvONfeppDOjJjIsP1aIDRpLYfvHWUFbqOhErwSNUVLs7cCuXcfZr+eAW/aXe3rerSUo8nOQLTeiz6x7f4yRARvxQER5zoRQhevGzrfe8BXWI4PMEO3fUVOH76+dX2ybd97N1u2V4T6Y+m6MIwac1MMVqMavYrXXiMmpvQp87nXz068G9FCqgfLmgIhatMN3oS6OYC0PMLDBIkE5CD1RGQqZAeOXnAzP7YWdiqs+6dngqclH96arh0I3t9T3bukkP5Fag3DtHAq+QPZGH5PGRIlfntnAJl2gaqFEMH62TwP34Sn90JffRk020T+KJwIu/rya+r2I6tuxWPYkvDCc4qpTx4hmMnIg9axy4qQo4HAwgf5ll7sld5EpZwCZmJlA8YkPl1l7hScutHEau27euRLxngBme+FoziwXlgKFX9Ojp2TEBg1aWYGgF/ZKrDtsmdGqaxp7/tAHRCyuy+PCha/UQwDU3E7uilBuWkp8vfkf2ySqS49NaCsiw30V65Q1kEyYbMHgx+b35fmKOF+a+bl/+z3N1LoxFnvx7KAv7yDwFAYCodWRLM1v2AgmwgOs72kHTWcAblH7rg3Nz9NIhanF9DXP/JUK3Q3BsKnkU/4cHidfL6URZsYx0iVRboseBTWHQHURR4zev2C1PgV+r5wFAUDndUSRUHFcNdTYHnQcbdUEsKIrZZHzjEPvpwrK02VFO2jqM+wrfYb7TbS6duvq8uJ0Car5p6/3b870wBxYeNEnYewzgZ/Vv1RoJZNaXwF16vvqmRmO3+W5aveo2rvIj6MtDaOkHt3r7WSwqrWoxJ3ps3SS6vNjWz+xvKXYKRF9FCgXmb8+og+A6hXaniloGU5hvJT1sWtXJkEvjvSW2Pkoxmnm0U77FhbgGIuvLy0DvYCA/3njpgNdu5U1Qp8I6HX5rQrpMjYfBTZqNGTHdRJ9pXy3KIIwHtWFeIqjSzAgcBZ7656azjQcYGRnv31NLCQOhB3bP3ZY40agH9yas5kARUQ3VOT8GlU70T4z5czyhv75wDc7g75ie17pHLAZfjOw9zF4EB02FM3CTw3TxMJ9z0ScqSOn9XFF9baPUc3/Pt8MpV5NKtGOJOnzrzqMhDv6BYMxBjrRBoeS7Jki81+LhHoTqjGTqJUjWlnXb2QS7zXU/fofPmlGcRRGJQIuqG2GQbdaPBocygYn86KnlVIxlakwT5MXJPN20PuiNxnupT7JghJ4gdElFIhUvlY6wOhRjkQe9tgQxfonS5VayIDk9FnKia5Hthtcud8f
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BY3PR05MB795372F222710E522B9AAEDE9CB29BY3PR05MB7953namp_"
MIME-Version: 1.0
X-OriginatorOrg: calix.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY3PR05MB7953.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8e858925-a0bc-4b80-e170-08d98a72d470
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2021 15:46:44.2826 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ffae2e5-6ff0-4510-bbf3-ca842d7ca55e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: b+T0MtoUXr4TRZVsu9r/qNRuc43EpSXEo9yifABCNBwpPSH+fzDCA3sxw+Nw9cUhBUCyC1F+eQu76PenWFgVnA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4517
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/h5SmrjpFSaI-bWSVJj8kMWhpI5o>
Subject: Re: [OPSAWG] Call for adoption: draft-boydseda-ipfix-psamp-bulk-data-yang-model (renamed "draft-arokiarajseda-opsawg-ipfix-data-export-yang-model")
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Oct 2021 15:46:54 -0000

Hello OPSAWG group,
I would like to note that draft-boydseda-ipfix-psamp-bulk-data-yang-model has been renamed draft-arokiarajseda-opsawg-ipfix-data-export-yang-model.  We have had a change of editors and that prior OPSAWG feedback has been addressed in this latest draft.  The new editors are: Marta Seda and Anand Arokiaraj.

Here is a breakdown of what has been done to address the comments from Benoit,and others :

[Rob Wilton, Gerhard Muenz 15 May]
Would it be feasible to split this work up into smaller chunks that would make it easier to review.  E.g. to put the packet-sampling and bulk-data-export into separate drafts?  Perhaps pare back some optional functionality.
[Editors answer]
The updated draft has removed psamp (packet sampling).  The present draft only addresses bulk data export.  The draft name has been changed to "IPFIX Data Export YANG model".  This has resulted in the present text (excluding appendix, tree and YANG)  being reduced to 16 pages long.  As a result of removing psamp, and changing editors, the new draft document is being renamed:
draft-arokiarajseda-ipfix-data-export-yang-model

/[Benoit, 27 August feedback section]
3a feedback:
- the abstract doesn't mention the IPFIX YANG module, while https://tools.ietf.org/html/draft-boydseda-ipfix-psamp-bulk-data-yang-model-03#section-2<https://protect-us.mimecast.com/s/WRNICOY6R0c5z5zZiESTbV?domain=tools.ietf.org> does
[Editor's answer]
The document no longer is concerned with replacing RFC 6728.  The abstract and objectives have been updated to reflect the IETF OPSAWG desired updates.

3b. Feedback
- The Tree Diagrams (currently in appendix) should be moved inside the document
[Editor's answer]
The YANG and tree diagrams have been moved into the normative section of the document as recommended.

3c. Terminology
[Editor's comment]:  No effort is made to define terms (instead terms used in this document refer back to RFC 7011).

EDITOR's REQUEST to OPSAWG group:
The editors would like to ask IETF OPSAWG to review the latest updates and provide feedback.


From: OPSAWG <opsawg-bounces@ietf.org<mailto:opsawg-bounces@ietf.org>> On Behalf Of Joey Boyd
Sent: Friday, September 4, 2020 1:15 AM
To: Joe Clarke (jclarke) <jclarke@cisco.com<mailto:jclarke@cisco.com>>; Benoit Claise <bclaise=40cisco.com@dmarc.ietf.org<mailto:bclaise=40cisco.com@dmarc.ietf.org>>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>; draft-boydseda-ipfix-psamp-bulk-data-yang-model.all@ietf.org<mailto:draft-boydseda-ipfix-psamp-bulk-data-yang-model.all@ietf.org>
Subject: Re: [OPSAWG] Call for adoption: draft-boydseda-ipfix-psamp-bulk-data-yang-model

Indeed, thank you Benoit for the detailed review. The authors are currently analyzing your feedback and will be preparing an updated draft as we feel that progressing the draft through the WG is the correct approach.

Best regards,
Joey

From: Joe Clarke (jclarke) <jclarke@cisco.com<mailto:jclarke@cisco.com>>
Sent: Thursday, August 27, 2020 12:00 PM
To: Benoit Claise <bclaise=40cisco.com@dmarc.ietf.org<mailto:bclaise=40cisco.com@dmarc.ietf.org>>
Cc: Joey Boyd <joey.boyd@adtran.com<mailto:joey.boyd@adtran.com>>; opsawg@ietf.org<mailto:opsawg@ietf.org>; draft-boydseda-ipfix-psamp-bulk-data-yang-model.all@ietf.org<mailto:draft-boydseda-ipfix-psamp-bulk-data-yang-model.all@ietf.org>
Subject: Re: [OPSAWG] Call for adoption: draft-boydseda-ipfix-psamp-bulk-data-yang-model

Thank you for your analysis, Benoit.  I appreciate you taking a deeper look into this document's text than what's been perhaps done previously in the various reviews.  Certainly the proposal of AD-sponsored/experimental would mitigate the concern around bypassing IETF process.  Though pursuing this route, I feel we'd run into issues ratifying this into the standards track down the line when there is sufficient feedback based on the other issues you raise (as well as potential issues beyond Section 4).

So a question to the authors and those that have recently expressed support (and you, Benoit) is could these issues be fixed and is there a desire to take on that work in this WG?  Are those changes worth doing, or would the authors like to move forward with your proposed approach?

Joe

On Aug 27, 2020, at 08:37, Benoit Claise <bclaise=40cisco.com@dmarc.ietf.org<mailto:bclaise=40cisco.com@dmarc.ietf.org>> wrote:

Dear all,

I finally spent some time reviewing draft-boydseda-ipfix-psamp-bulk-data-yang-model-03

A couple of observations to start with:

Let's look at the draft objectives first:
1. Obsoleting RFC 6728 with new IPFIX and PSAMP YANG modules.
RFC 6728 was the first YANG module produced outside of NETMOD. So obviously, we learned a lot in the mean time.
As an example, the reference to the ifIndex as opposed to ifName in ietf-interfaces.
So starting from a fresh new YANG module, which would follow the new YANG guidelines (RFC8407) and NMDA (RFC8342), is obvisously a good idea
2. Removing the SCTP constraint
The requirement is clearly to use UDP, as opposed to SCTP. This makes sense to me, as SCTP did not take off in NetFlow/IPFIX/PSAMP world. Now, what would the IESG, and transport ADs in particular, say about using UDP in a standard document, while it has been imposing congestion-aware protocols? If the answer is "no way", the answer might be an experimental RFC.
For your copious leisure time, some IPFIX history, along with my thoughts (*)
3. Bulk-data-export
It goes beyond the RFC6728 scope
What's not clear: bulk data is also for non-PSAMP data?

   This coupling and transport requirement

   makes it difficult for a device, which does not support SCTP, to use

   the model for collecting and exporting non-PSAMP bulk data.
Some feedback:

- the abstract doesn't mention the IPFIX YANG module, while https://tools.ietf.org/html/draft-boydseda-ipfix-psamp-bulk-data-yang-model-03#section-2<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FWRNICOY6R0c5z5zZiESTbV%3Fdomain%3Dtools.ietf.org&data=04%7C01%7CMarta.Seda%40calix.com%7C05033f2878a64b72bed808d98a07f6bb%7C8ffae2e56ff04510bbf3ca842d7ca55e%7C1%7C0%7C637692589107619742%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=c92fSTCsscJRX7jdwzYKVbpGvveaSYxlO5eXjjIJWVI%3D&reserved=0> does

- The Tree Diagrams (currently in appendix) should be moved inside the document

- You wrote:

   These are some of the other issues with the current model:



   o  The PSAMP YANG model defines the frequency of export in the PSAMP

      cache.  Bulk data needs the export frequency to be controlled by

      the exporting process.
Well, the IPFIX world, as soon as the flow expires (active and inactive timers), it streams out of the device b/c we speak about many flow records.
See https://tools.ietf.org/html/rfc5470#section-5.1.1<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2F-V9XCPNW8Vhv8v8NI0311M%3Fdomain%3Dtools.ietf.org&data=04%7C01%7CMarta.Seda%40calix.com%7C05033f2878a64b72bed808d98a07f6bb%7C8ffae2e56ff04510bbf3ca842d7ca55e%7C1%7C0%7C637692589107629688%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7C5pXsksHOzcYB84XaXII7H1CyTNfEKZxVrL2Ap%2BrXs%3D&reserved=0>

- Terminology.
You chose to cut/paste each definition in this draft. It's your chose, even if RFC6728 decided to use this format:

   o  Definitions adopted from [RFC5101<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2F_VjKCQWgR8CBMBMltMLw7V%3Fdomain%3Dtools.ietf.org&data=04%7C01%7CMarta.Seda%40calix.com%7C05033f2878a64b72bed808d98a07f6bb%7C8ffae2e56ff04510bbf3ca842d7ca55e%7C1%7C0%7C637692589107629688%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=geKPeNGs4Zu48PzE6W%2FmKT%2BxLzVJWixyVWbAPDm%2BXc8%3D&reserved=0>]:

      *  Collection Process

      *  Collector

      *  Data Record

      *  Exporter

      *  Flow

      *  Flow Key

      *  Flow Record

      *  Information Element

      *  IPFIX Device

      *  IPFIX Message

      *  Observation Domain

      *  Observation Point

      *  (Options) Template
You rightly added the RFC reference in case of cut/paste.
Now, here is one issue. Metering Process and Exporting Process have their own definitions in RFC6728 and in this draft.
The following text, from RFC6728, is still useful IMO.

   The terms Metering Process and Exporting Process have different

   definitions in [RFC5101<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2F_VjKCQWgR8CBMBMltMLw7V%3Fdomain%3Dtools.ietf.org&data=04%7C01%7CMarta.Seda%40calix.com%7C05033f2878a64b72bed808d98a07f6bb%7C8ffae2e56ff04510bbf3ca842d7ca55e%7C1%7C0%7C637692589107639657%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zpZjHgpwJk8Awc0BKQFcOCCKqqcfv6XO3e%2FceCa2tOw%3D&reserved=0>] and [RFC5476<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FzRiCCR6j7VInjnj0uOX5q_%3Fdomain%3Dtools.ietf.org&data=04%7C01%7CMarta.Seda%40calix.com%7C05033f2878a64b72bed808d98a07f6bb%7C8ffae2e56ff04510bbf3ca842d7ca55e%7C1%7C0%7C637692589107649611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RxvD5O%2FFWqwbvRy%2FnYmB0ulxay4wNJ7Fxfn3Ge1JfFI%3D&reserved=0>].  In the scope of this

   document, these terms are used according to the following

   definitions, which cover the deployment in both PSAMP Devices and

   IPFIX Devices:

What you decided to do is change the Metering Process definition compared to RFC6728 by adding some extra sentences, and more importantly, by deleting this sentence:

      Inputs to the process are packets observed at one

      or more Observation Points, as well as characteristics describing

      the packet treatment at these Observation Points.
This came as a surprise. Explain why?
What we really need a section "change since RFC 6728", highlighting these type of changes, along with some justifications.
See, as an example https://tools.ietf.org/html/rfc7011#section-1.1<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2F8_V3CVOn9Vf0N0NkiQ1yNk%3Fdomain%3Dtools.ietf.org&data=04%7C01%7CMarta.Seda%40calix.com%7C05033f2878a64b72bed808d98a07f6bb%7C8ffae2e56ff04510bbf3ca842d7ca55e%7C1%7C0%7C637692589107649611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2FHNWo9vesVIkgcw81NSUbNUE6mLcumIHKcSu7%2BAwCM%3D&reserved=0>

Note: all IPFIX/PSAMP RFCs have, by convention, the first letter capitalized for each terms specified in the terminology. Granted, this is not of highest importance but ...

- section 3. Structure of the Configuration Data Model.
While https://tools.ietf.org/html/rfc6728#section-3<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2F57_QCW6oR9IzRzRXhpMGo7%3Fdomain%3Dtools.ietf.org&data=04%7C01%7CMarta.Seda%40calix.com%7C05033f2878a64b72bed808d98a07f6bb%7C8ffae2e56ff04510bbf3ca842d7ca55e%7C1%7C0%7C637692589107659556%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=F7n8PGoMGI0RlvuffccxosqUJP79StstBRZCGFJuSNE%3D&reserved=0> has a (maybe long) explanation of IPFIX/PSAMP, https://tools.ietf.org/html/draft-boydseda-ipfix-psamp-bulk-data-yang-model-03#section-3<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FCpqyCXDpR9hBVBVDt7jawt%3Fdomain%3Dtools.ietf.org&data=04%7C01%7CMarta.Seda%40calix.com%7C05033f2878a64b72bed808d98a07f6bb%7C8ffae2e56ff04510bbf3ca842d7ca55e%7C1%7C0%7C637692589107669523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7SVJzjp0CxJZ%2BGF0ltav6cOIL2Rb6agXSFT3j1FO%2FQw%3D&reserved=0> is pretty short.
What bothers me is that you seem to pick what you want out of RFC6728... up to point where it's sometimes wrong.

   o  A PSAMP/IPFIX metered model where a PSAMP/IPFIX device configures

      a meter that samples packets passing through a device, applies an

      IPFIX template to those packets, and exports IPFIX templates/data

      records to an IPFIX collector.
IPFIX is an exporting protocol
PSAMP is a sampling metering process.
The following sentence is too simplistic/wrong:

      A PSAMP/IPFIX metered model where a PSAMP/IPFIX device configures

      a meter that samples packets passing through a device
You introduce new term: "PSAMP/IPFIX metered model", "PSAMP/IPFIX device"
This YANG module must be able to configure IPFIX without sampling.

- section 3.1, Metering Process Decomposition in Selection Process and Cache
Let me illustrate a general concern with the draft with a diff of this section, from RFC6758 to this draft
<eifnaohgcbjmdcfp.png>
Note: the generic IETF diff tool https://www6.ietf.org/tools/rfcdiff/<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FHQtcCYEqR9CkEkEpij87E_%3Fdomain%3Dwww6.ietf.org%2F&data=04%7C01%7CMarta.Seda%40calix.com%7C05033f2878a64b72bed808d98a07f6bb%7C8ffae2e56ff04510bbf3ca842d7ca55e%7C1%7C0%7C637692589107669523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VKgAvRCTwePvrTtFP3tr9nG%2BNhhrS6IKlgYTBxZUDqU%3D&reserved=0> was not useful, so I had to cut/paste the respective section in txt file as a prerequisite

In the first sentence, you removed "commonly".
In the first sentence, you changed "split into packet Sampling" and "Filtering functions performed by Selection Process, and the maintenance of the Flow Records and Packet Reports is performed by a Cache" into "split into the selection process and cache"
The sentence "The configuration data model adopts the separation of Selection Processes and Caches in order to support the flexible configuration and combination of these functional blocks." disappeared
The reference "As defined in [RFC5476]" disappeared.
"The action of the Selection Process on a single packet" became "The action of the selection-process on a single packet": No only you removed the capitalized first letter of the definition but the definition aspect is completely lost because you now have "selection-process", which you changed in the picture.
Regarding the section starting with "The configuration data model  does ...", you re-wrote it with your interpretation and btw, you forgot the reference
Same remark for the sentence starting with "The configuration data model enables the configuration of a Selection Process".
You change the spec: "a Cache MUST NOT aggregate packets observed" => a cache must not aggregate packets observed

All in all, while the goal to clarify the text is noble, you took some freedom. Some modifications are wrong, some are not ideal, and some others need a more careful review by IPFIX experts. You know, we went through 11 draft versions, carefully evaluating each sentence, before publishing the RFC.
When creating a bis document, the goal is to modify the text minimally to facilitate the diff comparison... involving the authors day one to understand why the text is written that way.

-  I could make the same remarks for other sections.
Ex: "The ObservationPoint class specifies an Observation Point" => "The ObservationPoint class specifies an observation-point"
Clearly you missed the fact that Observation Point refers to a definition.
Ex: "A Selection Process MAY pass the Selected Packet Stream to a Cache." => "A selection process may pass the selected packet stream to a cache


At this point in time, I've been spending a couple of hours, barely arriving at section 4 and I'll stop there...
Reviewing this draft is very time consuming (and I know IPFIX, and maybe that's the reason).
This might explain why you did not get much feedback.

Let's start from the objectives.
1. Obsoleting RFC 6728 with new IPFIX and PSAMP YANG modules.
    There are two parts here.
    1.1 The YANG module. Martin Bjorklund did the YANG doctors review. As long as he is fine, I'm fine.
    1.2 This draft text obsoleting RFC 6728. For all the reasons mentioned above, I believe this draft is NOT a good basis.
2. Removing the SCTP constraint
    Sure, that's important, if the IESG agrees.
3. Bulk-data-export
    While I personally believe that the telemetry future is more into model-driven (to use the same data model for configuration and operational data), this new bulk-data-export feature does not do any harm. No objection here.


Let's keep some other factors in mind.
The BBF members did the absolute right thing to come to the IETF to update RFC6728, as opposed to focus this work in BBF. Thanks.
The IETF did not provide much feedback, even if the draft was presented a few times. Some reasons why are mentioned above.

In conclusion, my suggestion to the AD is therefore to publish this document, as experimental, not obsoleting RFC 6728, as AD sponsor.

Regards, Benoit

========================================

I started with some editorial/idnits, then I stopped
-

   [RFC6728] defines a single YANG module for the IP Flow Information

   Export (IPFIX) and Packet Sampling (PSAMP) protocols.  The PSAMP

   collecting process and the IPFIX exporting process are tightly

   coupled in this module.  Moreover, the exporting process requires a

   device to support SCTP.  This coupling and transport requirement

   makes it difficult for a device, which does not support SCTP, to use

   the model for collecting and exporting non-PSAMP bulk data.

Inline reference to RFC6728.
-

         The transport sessions are modeled such that they can be

         retrieved individually in addition to retrieving the entire

         list (which may be quite large for devices such as an NG-PON2

         OLT).
Describe NG-PON2 OLT

- https://datatracker.ietf.org/doc/review-boydseda-ipfix-psamp-bulk-data-yang-model-02-opsdir-lc-ersue-2019-12-01/<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2Fc_p2CZ6rR9IPrPr8iMAXIc%3Fdomain%3Ddatatracker.ietf.org%2F&data=04%7C01%7CMarta.Seda%40calix.com%7C05033f2878a64b72bed808d98a07f6bb%7C8ffae2e56ff04510bbf3ca842d7ca55e%7C1%7C0%7C637692589107679478%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=MTgYMxD4p65G5x7YdKe5Hhs%2BKRmykDj2skrMCDbP1hs%3D&reserved=0> => Not Ready
Also as the document is largely based on RFC 6728, introducing the authors of RFC 6728 as co-authors and involving them for review would very useful. As a minimum they need to be involved as reviewers and mentioned in the Acknowledgments section.

...

In case there is no support in OPSAWG WG for this draft to replace the standard track RFC 6728 I believe it would be appropriate to publish it as an "AD sponsored Experimental RFC". It can still become a standard track RFC after getting implementation reports and appropriate community feedback on its usage.
- https://datatracker.ietf.org/doc/review-boydseda-ipfix-psamp-bulk-data-yang-model-02-opsdir-lc-clarke-2019-12-20/<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FHUF1C1w3DvSn2n2BuANY_H%3Fdomain%3Ddatatracker.ietf.org%2F&data=04%7C01%7CMarta.Seda%40calix.com%7C05033f2878a64b72bed808d98a07f6bb%7C8ffae2e56ff04510bbf3ca842d7ca55e%7C1%7C0%7C637692589107689438%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CsvgX%2BaJr6do2YhA36UL1H6ielutmmr6kyIP6reRywU%3D&reserved=0> => Not Ready
One other point that struck me as I read this document was that 6728 is being obsoleted by this, but there are references to things defined within it. I would think that anything that this new document will use in a normative fashion should be explicitly stated in this document. Such examples are found in Section 3 where text like "based on [RFC6728]" is used.
========================================

(*) https://www.claise.be/from-netflow-to-ipfix-via-psamp-13-years-of-standardization-explained-2/<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FlQChC2kDEwhKPKPZtpOfIn%3Fdomain%3Dclaise.be%2F&data=04%7C01%7CMarta.Seda%40calix.com%7C05033f2878a64b72bed808d98a07f6bb%7C8ffae2e56ff04510bbf3ca842d7ca55e%7C1%7C0%7C637692589107699396%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=P4ST1CHn%2BG7gY%2FN6FazE6jcWGzqPzQcCo9ggiJOnBKM%3D&reserved=0>
The next couple of years were dedicated to IPFIX protocol specifications. According to my recollection, the WG spend one year or maybe one year and half on transport-related discussions: should we use TCP or SCTP as the congestion-aware transport protocol ... while most customers only cared about UDP when the flow export collection is exclusively within their management domain ... and where the distributed function of forwarding ASICs complicate congestion aware transport-requirements.
The final specifications compromise on: "SCTP [RFC4960] using the PR-SCTP extension specified in [RFC3758] MUST be implemented by all compliant implementations.  UDP [UDP] MAY also be implemented by compliant implementations.  TCP [TCP] MAY also be implemented by compliant implementations."

Hi all,

I support progression of this draft as it addresses current needs for IPFIX applications within Access Networks. The modular way this draft constructs the configuration models will aid to the longevity of the IPFIX protocol as additional use cases are identified.

As a co-author of the draft, I would also like to address some previous comments raised.

I acknowledge the draft is long, but the content is necessary. In order to address the shortcomings of the existing RFC 6728 data model in the context of these new applications (see section 1.1 of the draft), the data model was rewritten and restructured. As such, the authors felt it was necessary to obsolete RFC 6728 so that there was no confusion over the existence of the two data model approaches. This meant that most of the content from RFC 6728 was carried over with some necessary changes needed to a) align with the new data models and b) modify how functional descriptions are tied to the data model to conform to the latest RFCs which define YANG data models, e.g. use of tree diagrams instead of class diagrams. As other author noted, splitting the document into smaller parts doesn't really change the amount of text that must be reviewed and actually increases it as some portions will need to be repeated. This opens the door to introduce inconsistencies. As such, I would not be in favor of splitting the draft.

I look forward to working with everyone to progress this draft forward.

Best regards,
Joey





_______________________________________________

OPSAWG mailing list

OPSAWG@ietf.org<mailto:OPSAWG@ietf.org>

https://www.ietf.org/mailman/listinfo/opsawg<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FcV9cC31VGxs76769i9m__u%3Fdomain%3Dietf.org&data=04%7C01%7CMarta.Seda%40calix.com%7C05033f2878a64b72bed808d98a07f6bb%7C8ffae2e56ff04510bbf3ca842d7ca55e%7C1%7C0%7C637692589107699396%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rqhiRu49gm025XJHuPJyaGh2R%2B%2F5WdN4gWz7lehG%2FKE%3D&reserved=0>

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org<mailto:OPSAWG@ietf.org>
https://www.ietf.org/mailman/listinfo/opsawg<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect-us.mimecast.com%2Fs%2FcV9cC31VGxs76769i9m__u%3Fdomain%3Dietf.org&data=04%7C01%7CMarta.Seda%40calix.com%7C05033f2878a64b72bed808d98a07f6bb%7C8ffae2e56ff04510bbf3ca842d7ca55e%7C1%7C0%7C637692589107709345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=O%2FYmyYIeysDxqycgtNmUk4v187rg2ksMMqy%2BGMYgM%2F4%3D&reserved=0>