Subject: [OPSAWG] Opsdir last call partial review of draft-boydseda-ipfix-psamp-bulk-data-yang-model-02

From: Mehmet Ersue via Datatracker <[email-masked]>
Date: Sun, 01 Dec 2019 10:32:36 -0800

Review is partially done. Another assignment may be needed to complete it.

Reviewer: Mehmet Ersue
Review result: Not Ready

I reviewed the document "YANG Data Models for the IP Flow Information Export
(IPFIX) Protocol, Packet Sampling (PSAMP) Protocol, and Bulk Data Export
(draft-boydseda-ipfix-psamp-bulk-data-yang-model-02) as part of the Operational
directorate's ongoing effort to review all IETF documents being processed by
the IESG. These comments were written primarily for the benefit of the
operational area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

Obsoletes: 6728 (if approved)
Intended status: Standards Track
Current IESG state: I-D Exists

Summary:
The document aims to replace the YANG model for packet sampling (PSAMP) and
bulk data collection and export via the IPFIX protocol originally defined in
standard track RFC 6728 (Configuration Data Model for the IP Flow Information
Export (IPFIX) and Packet Sampling (PSAMP) Protocols). The YANG data model in
the document also aims to be conform with the Network Management Datastore
Architecture (NMDA) defined in RFC 8342. FYI: The YANG model is currently in
review by Martin Bjorklund from YANG modeling perspective.

The document further aims to decouple the PSAMP collecting process and the
IPFIX exporting process as well as defining an exporting process which does not
require SCTP support. The document tries to enable the export frequency to be
controlled by the exporting process, support of large IPFIX mediation
functions, and flexible referencing of interfaces. The new functionality
described above and the necessary restructuring of the model in RFC 6728 might
become useful if done properly as an extension to RFC 6728.

However based on missing IPFIX and PSAMP expertise, unfortunately I'm not able
to give a solid statement on to whether the document is capable to replace the
standard track RFC 6728. Moreover the new functionality and changes to the
original model require thorough and in-depth review by IPFIX and PSAMP experts.

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.

The document is proposed to publish as an AD sponsored draft, which is not an
issue per se. It is also not forbidden but very unusual that an AD sponsored
draft is proposed to replace a standard track RFC. I would be highly interested
to know why this path has been chosen.

However I believe it is a substantial issue that this draft has not been
discussed and supported in any IETF maillist until today. There was only a
short presentation in OPSAWG WG session one year ago without any record of
support. The authors are not known at IETF and have not written any other than
the current draft. The authors have most likely BBF background.

As IPFIX and PSAMP WGs have already concluded, I would like to recommend
_urgently_ to introduce the draft to OPSAWG maillist and ask for support. It is
IMO essentially important that the document gets discussed and reviewed by
IPFIX and PSAMP people available in OPSAWG and by the authors of RFC 6728
before publication. It also needs to be clarified whether the draft has been
already or is going to be implemented.

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.

Sorry for not being the right expert reviewer for the draft content. Therefore
I've set the review result to "Partially Completed - extra reviewer is to be
assigned" and hope the draft gets a proper review in OPSAWG WG and by the
authors of RFC 6728.

Mehmet

---

From: "Mehmet Ersue" <[email-masked]>
Date: Sun, 1 Dec 2019 20:13:09 +0100

I think this draft should be reviewed and commented by OPSAWG WG before
publishing as "AD sponsored standard track RFC" obsoleting RFC 6728.
(RFC 6728 authors CCed).

BR,
Mehmet

-----Original Message-----
From: OPS-DIR <[email-masked]> On Behalf Of Mehmet Ersue via
Datatracker
Sent: Sunday, December 1, 2019 7:33 PM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: [OPS-DIR] Opsdir last call partial review of
draft-boydseda-ipfix-psamp-bulk-data-yang-model-02

Reviewer: Mehmet Ersue
Review result: Not Ready

I reviewed the document "YANG Data Models for the IP Flow Information Export
(IPFIX) Protocol, Packet Sampling (PSAMP) Protocol, and Bulk Data Export
(draft-boydseda-ipfix-psamp-bulk-data-yang-model-02) as part of the
Operational directorate's ongoing effort to review all IETF documents being
processed by the IESG. These comments were written primarily for the benefit
of the operational area directors.  Document editors and WG chairs should
treat these comments just like any other last call comments.

Summary:
The document aims to replace the YANG model for packet sampling (PSAMP) and
bulk data collection and export via the IPFIX protocol originally defined in
standard track RFC 6728 (Configuration Data Model for the IP Flow
Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols). The YANG
data model in the document also aims to be conform with the Network
Management Datastore Architecture (NMDA) defined in RFC 8342. FYI: The YANG
model is currently in review by Martin Bjorklund from YANG modeling
perspective.

The document further aims to decouple the PSAMP collecting process and the
IPFIX exporting process as well as defining an exporting process which does
not require SCTP support. The document tries to enable the export frequency
to be controlled by the exporting process, support of large IPFIX mediation
functions, and flexible referencing of interfaces. The new functionality
described above and the necessary restructuring of the model in RFC 6728
might become useful if done properly as an extension to RFC 6728.

However based on missing IPFIX and PSAMP expertise, unfortunately I'm not
able to give a solid statement on to whether the document is capable to
replace the standard track RFC 6728. Moreover the new functionality and
changes to the original model require thorough and in-depth review by IPFIX
and PSAMP experts.

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.

The document is proposed to publish as an AD sponsored draft, which is not
an issue per se. It is also not forbidden but very unusual that an AD
sponsored draft is proposed to replace a standard track RFC. I would be
highly interested to know why this path has been chosen.

However I believe it is a substantial issue that this draft has not been
discussed and supported in any IETF maillist until today. There was only a
short presentation in OPSAWG WG session one year ago without any record of
support. The authors are not known at IETF and have not written any other
than the current draft. The authors have most likely BBF background.

As IPFIX and PSAMP WGs have already concluded, I would like to recommend
_urgently_ to introduce the draft to OPSAWG maillist and ask for support. It
is IMO essentially important that the document gets discussed and reviewed
by IPFIX and PSAMP people available in OPSAWG and by the authors of RFC 6728
before publication. It also needs to be clarified whether the draft has been
already or is going to be implemented.

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.

Sorry for not being the right expert reviewer for the draft content.
Therefore I've set the review result to "Partially Completed - extra
reviewer is to be assigned" and hope the draft gets a proper review in
OPSAWG WG and by the authors of RFC 6728.

Mehmet

_______________________________________________
OPS-DIR mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ops-dir

---

From: William Lupton <[email-masked]>
Date: Thu, 5 Dec 2019 16:15:30 +0000

Dear Mehmet,

Speaking as Document Shepherd
for draft-boydseda-ipfix-psamp-bulk-data-yang-model, I'd like to thank you
very much for your review.

There are just a few items that I'd like to comment on:

   - RFC 6728 authors: We have been in contact with Benoit Claise (who is
   one of the three RFC 6728 authors) throughout the process of creating the
   draft, and at Benoit's behest we contacted the other two authors a year ago
   (during IETF 103) to inform them of the work and to solicit opinions on the
   draft and its proposed models. We didn't hear back from them. I expect we'd
   be happy to add them as co-authors (if this was deemed appropriate) and
   would certainly be happy to acknowledge them.
   - Procedural questions: We are discussing these with the AD.
   - YANG doctors' review: We very much look forward to seeing the results
   of this review.

Cheers,
William Lupton

On Sun, 1 Dec 2019 at 13:42, Mehmet Ersue via Datatracker <[email-masked]>
wrote:

> Operational
> Information
> might
> able
> of
> an
> than
> standard
> Therefore

---

From: Gerhard Muenz <[email-masked]>
Date: Sat, 28 Dec 2019 11:47:36 +0100

Dear Mehmet,

Thank you for forwarding this e-mail. I have not subscribed to the 
OPSAWG mailing list. So maybe, you need to forward my reply.

Together with Benoir and Paul, I was the main author of RFC 6728. For 
many years, however, I have neither been involved in IETF 
standardization nor in IPFIX/PSAMP activities. Therefore, I do not feel 
in a position to provide a complete review of the draft as an IPFIX 
expert. Nevertheless, I have a brief look at it and can share a few 
comments.

The main challenge of RFC 6728 was to create a configuration data model 
that covers all the metering and protocol features specified in the 
other PSAMP/IPFIX RFCs, and to also fit to the IPFIX MIB. We had long 
discussions to clarify and differentiate the functionality of each 
abstract functional block of an IPFIX Device (e.g. Metering Process, 
Exporting Process). So, it is good that the new draft does not reinvent 
the wheel but adopts the original configuration data model with only a 
few changes.

Most of the proposed changes of the original configuration data model 
shall facilitate extensions of the model for other use cases of the 
IPFIX protocol. The second contribution is the addition of bulk data 
export parameters to the model. If I understand correctly, bulk data 
transfer with IPFIX has not been standardized by IETF.

It would be possible to split the draft into two parts: (1) a revision 
of RFC 6728 covering the original scope of configuration (IPFIX/PSAMP 
Devices) including the changes to facilitate extensions for other use 
cases, and (2) a new draft with the specific extension for bulk data 
export (if IETF wants to standardize this).
Maybe, such a split would make it clear that bulk data export is not an 
IPFIX/PSAMP feature standardized by IETF.

Some further comments:
- RFC 7011 requires PR-SCTP for all compliant IPFIX devices. Therefore, 
the part is mandatory in configuration data model of RFC 6728. If we 
make SCTP optional, this would possibly reflect reality much better - 
but there would be a mismatch to RFC 7011.
- The Exporting Process does not influence the generation of Data 
Records, it may only throttle the speed of sending them in IPFIX packets 
(or drop in case of congestion). The proposed new parameter 
"export-interval" seems to refer to the generation of Data Records and 
therefore should not be configured as part of the Exporting Process, but 
as part of the process that generates the bulk data.
- I am not aware of any implementation of RFC 6728. It would be good to 
know whether there are any (possibly from Cisco, the main driver of 
IPFIX), and to get feedback from there.

Best regards,
Gerhard