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) <[email protected]>
Sent: Monday, April 11, 2022 6:09 PM
To: Arokiaraj, Anand (Nokia - IN/Chennai) <[email protected]>;
[email protected]
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 <[email protected]><mailto:[email protected]> On
Behalf Of Joe Clarke (jclarke)
Sent: Tuesday, April 5, 2022 8:34 PM
To: [email protected]<mailto:[email protected]>
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
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
