Re: [OPSAWG] Review of draft-arokiarajseda-ipfix-data-export-yang-model

["Arokiaraj, Anand (Nokia - IN/Chennai)" <[e-mail]>]

Hi All,
                A new version of the draft is now available at https://www.ietf.org/archive/id/draft-arokiarajseda-ipfix-data-export-yang-model-01.txt
The comments raised by Joe have been addressed and all references to IPFIX MIB have been removed.
Please let us know if there are more comments.

Regards,
Anand Arokiaraj

From: Joe Clarke (jclarke) <[e-mail]>
Sent: Monday, April 11, 2022 6:09 PM
To: Arokiaraj, Anand (Nokia - IN/Chennai) <[e-mail]>; [e-mail]
Subject: Re: Review of draft-arokiarajseda-ipfix-data-export-yang-model

Thanks for addressing these.  I hope to see more WG reviews soon.

Joe
On 4/11/22 01:24, Arokiaraj, Anand (Nokia - IN/Chennai) wrote:
Hi Joe,
                Thanks for your feedback!
The comments show that we have not entirely come out of replacing-RFC-6728-mode. Please find our responses inline ([Anand/Marta]).
In addition to this, we will also remove the references to the IPFIX MIB since they are already part of RFC 6728 and not required to be stated again here.

Regards,
Anand Arokiaraj

From: OPSAWG <[e-mail]><mailto:[e-mail]> On Behalf Of Joe Clarke (jclarke)
Sent: Tuesday, April 5, 2022 8:34 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [OPSAWG] Review of draft-arokiarajseda-ipfix-data-export-yang-model

Hello, WG.  As promised (threatened?) I wanted to poke the WG to review this work.  The authors have done, in my opinion, a good job of simplifying the original work down to around 16 pages of text and then the YANG module, considerations, and examples.  So, PLEASE REVIEW!

We'd like to do a call for adoption in the next few weeks.

I figured the best way to tease out some more WG reviews was to provide one myself.  Overall I just found a few readability issues plus a couple of larger questions.  First, the big question.

Why are you specifying your own set of TLS parameters rather than reference and use https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tls-client-server-27.  It seems you could leverage the groupings there and reference a certificate for export encryption.
[Anand/Marta] Indeed, we could use the tls-client-grouping from the referenced draft.

Second, in the YANG module, you have some patterns like \S+.  Are you really that permissive?  Would certain Unicode patterns work for names or do you want to be more specific in allowed characters?  Maybe it is since, for example, IE names can be unicode characters (but it looks like they can have spaces).  I'm also concerned about the use of max in your string lengths.  Shouldn't the IE Name be limited to 65535?
[Anand/Marta] Again, this is an outdated definition i realize. I think it would be best to follow the interface name and hardware component name definitions - "type string" and no explicit length restriction.

As for typos and readability...

Section 1:

s/statisticis/statistics/

Section 2:

s/logical interface/logical interfaces/

s/suffient/sufficient/

s/and IE id/and IE ID/
[Anand/Marta] Thanks for listing out the typos.

Section 3.1:

You refer to ExportingProcess, but the code is exporting-process.  I'm not sure why the two couldn't align.  Maybe in Figure 1, you want the block to be ExportingProcess?

Ultimately, I'm trying to tie the text to the figure and YANG tree.
[Anand/Marta]Not just exporting-process, there is a mismatch for all the class names TransportLayerSecurity/transport-layer-security, TransportSession/transport-session, Template/template, DataProcess/data-export. Will update the yang names in all the references.

Joe