Are you really simultaneously saying
1) As far as you know, the existing draft is not being used
2) You do not want the working group to work on the replacement a number
of operators need
3) And you oppose the AD sponsoring the work
You are not even saying you don't like it, as you also say you would not
want to work on the problem. Even ADs don't get to say "this should not
go forward even though there is no technical objection."
Huh?
Yours,
Joel
On 5/16/2020 9:02 AM, Mehmet Ersue wrote:
Hi All,
although technically (and surprisingly) allowed I would like to state my
discomfort for publishing this draft as AD sponsored document. I believe a
draft which is proposed to replace a standard-track RFC developed with long
discussions and reviews in an IETF WG should be again re-discussed and
reviewed with its changes in a WG before publishing. Otherwise it feels like
bypassing IETF process.
I personally have no big interest in this draft as I assume RFC 6728 has not
been used in the industry widely. Though if there is strong support in
OPSAWG for the changes in this draft and updating RFC 6728 I would be
supportive too. However I did not see such strong support in OPSAWG yet. I
think we also should clarify on the maillist whether the changes in the
draft are only technically interesting or sufficient amount of people in the
WG (excluding draft authors) are planning to implement and use.
If ever the WG decides to develop such a draft replacing RFC 6728 I believe
it should be divided in parts where the WG should at the first place focus
on changes related to RFC 6728. The decision on developing a draft on bulk
data transfer should be provided separately as I assume the interest on this
part would be less than updating the existing RFC. Dividing into parts makes
it indeed more manageable.
My 2 cents.
Cheers,
Mehmet
-----Original Message-----
From: OPSAWG <[email protected]> On Behalf Of Rob Wilton
(rwilton)
Sent: Friday, May 15, 2020 6:09 PM
To: Joe Clarke (jclarke) <[email protected]>; opsawg <[email protected]>;
[email protected]
Subject: Re: [OPSAWG] Call for adoption: draft-boydseda-ipfix-psamp-bulk-
data-yang-model
[With AD hat on]
Hi,
I was really hoping that there would be more support for adopting this
work
in OPSAWG, given it covers both YANG and IPFIX it does seem like the
correct home for it.
In general, I am keen that IETF continues to flesh out and improve YANG
models for the protocols standardized in IETF.
I'm also not sure whether I would realistically be able to AD sponsor this
document, given that I am new in the AD role, and this is currently a long
document. The document and YANG model both look like they are in
reasonable shape, but probably could do with some more reviews.
I have a question for the authors:
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.
And a question for the WG:
2) If this work was split up, and if I ask very nicely ;-), then is it
possible that a
few more people would be willing to help review a smaller shorter version
of
this document?
Regards,
Rob
-----Original Message-----
From: OPSAWG <[email protected]> On Behalf Of Joe Clarke
(jclarke)
Sent: 18 April 2020 22:13
To: opsawg <[email protected]>
Subject: [OPSAWG] Call for adoption:
draft-boydseda-ipfix-psamp-bulk-data-
yang-model
As was discussed in the April 7 virtual interim, we are doing a
three-week call for opsawg adoption for this work.
This draft was an AD-sponsored work with Ignas and has now moved under
Rob. It has received a number of reviews (some thorough, some more
cursory), and it is destined to obsolete 6728 (Configuration Data
Model for the IP Flow Information Export (IPFIX) and Packet Sampling
(PSAMP)
Protocols) if ratified. Because of that latter point, making this a
WG item seems more appropriate than pushing it through as an
AD-sponsored document.
To that end, does the WG feel this work is important and wants to take
it up? In a nutshell, this document breaks up the original YANG
module into three for the IPFIX collector and exporter functions, the
PSAMP functions, and the templates for bulk data exports. While it
preserves the SCTP support, SCTP is no longer mandatory. It also adds
support for ietf- interfaces and hardware management (those did not
exist at the time of 6728).
The reason for the three-week call is to give people enough time to
read through and digest this document. Please reply with support (or
objections) as well as comments by May 10, 2020.
Thanks.
Joe
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
