Re: [OPSAWG] Call for adoption: draft-boydseda-ipfix-psamp-bulk-data-yang-model

"Joel M. Halpern" <jmh@joelhalpern.com> Sat, 16 May 2020 15:48 UTC

Return-Path: <jmh@joelhalpern.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 6B6773A08B7; Sat, 16 May 2020 08:48:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=joelhalpern.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 ZW9ORcMRxHm1; Sat, 16 May 2020 08:48:55 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 CF14A3A08AB; Sat, 16 May 2020 08:48:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 49PV7W4Dxlz1p4dW; Sat, 16 May 2020 08:48:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1589644135; bh=i7XZ3LdF971tz9L9rslmVpa9sK17sq8XqDlQBXqrnGg=; h=Subject:To:References:From:Date:In-Reply-To:From; b=LpeyrbQXMX+T1XubFsGsILHxXHFM3Y9T/uNwLKNl4/AdiEKZ5uzbNWJ1bJZUfLf8Z bhlk1VBufrQsiPw7CzXrAgDVDsyt0LQ38pqcCTHn1vQ6NxEVJJOWFJHLaqX0k7yIdd x8LY8fcCN3Nauvxwi2QPkqpQdqC1uwYS9eRFjgjw=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 49PV7W08Nlz1p4dV; Sat, 16 May 2020 08:48:54 -0700 (PDT)
To: Mehmet Ersue <mersue@gmail.com>, 'opsawg' <opsawg@ietf.org>, draft-boydseda-ipfix-psamp-bulk-data-yang-model@ietf.org
References: <214417FB-582B-49DF-A122-3005776CC011@cisco.com> <MN2PR11MB436681B87852EED3A6C054D2B5BD0@MN2PR11MB4366.namprd11.prod.outlook.com> <00c501d62b82$4476af60$cd640e20$@gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <fcf48bd4-8439-b736-5a81-b998951e4e75@joelhalpern.com>
Date: Sat, 16 May 2020 11:48:51 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <00c501d62b82$4476af60$cd640e20$@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/emsVr-uYSp8tJmrg9g60PLSyJlQ>
Subject: Re: [OPSAWG] Call for adoption: draft-boydseda-ipfix-psamp-bulk-data-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: Sat, 16 May 2020 15:48:57 -0000

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 <opsawg-bounces@ietf.org> On Behalf Of Rob Wilton
>> (rwilton)
>> Sent: Friday, May 15, 2020 6:09 PM
>> To: Joe Clarke (jclarke) <jclarke@cisco.com>; opsawg <opsawg@ietf.org>;
>> draft-boydseda-ipfix-psamp-bulk-data-yang-model@ietf.org
>> 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 <opsawg-bounces@ietf.org> On Behalf Of Joe Clarke
>>> (jclarke)
>>> Sent: 18 April 2020 22:13
>>> To: opsawg <opsawg@ietf.org>
>>> 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
>>> OPSAWG@ietf.org
>>> https://www.ietf.org/mailman/listinfo/opsawg
>>
>> _______________________________________________
>> OPSAWG mailing list
>> OPSAWG@ietf.org
>> https://www.ietf.org/mailman/listinfo/opsawg
> 
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>