[Supa] Time to close SUPA

Benoit Claise <bclaise@cisco.com> Sat, 22 July 2017 20:29 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E0312EC18 for <supa@ietfa.amsl.com>; Sat, 22 Jul 2017 13:29:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 mtcz5WiAYOsY for <supa@ietfa.amsl.com>; Sat, 22 Jul 2017 13:29:43 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F00B127342 for <supa@ietf.org>; Sat, 22 Jul 2017 13:29:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4519; q=dns/txt; s=iport; t=1500755382; x=1501964982; h=from:subject:to:message-id:date:mime-version; bh=7n5fmM5aQTRI76eFN/cTcNlUsNlf9C5HIN/50sn3QL8=; b=h4TTejr0SaWDw99i3KzJKq15i4XWAAi9l7mI51C5cH9RpXN0Ux6JSqAl lAfbSZNMR4DZXluMgAjMaHoKpXSN+uMghS9c7PG4KLHEZ/i6zumsyJvEW g45Ff2vDYg2qy4vkDz3UcIaoCPBwDZ0WAuEq8jOpJ5nHagSvIMkpcq0/R Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AqAwAatXNZ/xbLJq1CGh4GDIQ+gRSOf5BOgRaPZYUsghIuiVgYAQIBAQEBAQEBax0LhUJ1PgJfDQgBAYorEDKdUZAOgiYniwQBAQEHAQEBAR8FgyiDTYFhKwuCOjSERwcBAYMugmEFiWeVZ4FohWaMUIsxhwaNAohiHziBCjEhCBsVh2E+NgEBhx4PF4IaAQEB
X-IronPort-AV: E=Sophos;i="5.40,397,1496102400"; d="scan'208,217";a="695984782"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jul 2017 20:29:38 +0000
Received: from [10.61.194.153] ([10.61.194.153]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v6MKTbRI017948 for <supa@ietf.org>; Sat, 22 Jul 2017 20:29:38 GMT
From: Benoit Claise <bclaise@cisco.com>
To: "supa@ietf.org" <supa@ietf.org>
Message-ID: <e371ebe2-07bb-cebe-6356-fc70965922b6@cisco.com>
Date: Sat, 22 Jul 2017 22:29:37 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------08FD23D881D312A2E5AE3AD3"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/supa/oQTj2_2S1EzXIsk6_I4TMr2Yu08>
Subject: [Supa] Time to close SUPA
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This list is to discuss SUPA \(Simplified Use of Policy Abstractions\) related issues." <supa.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/supa>, <mailto:supa-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/supa/>
List-Post: <mailto:supa@ietf.org>
List-Help: <mailto:supa-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/supa>, <mailto:supa-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 22 Jul 2017 20:29:45 -0000

Dear all,

The SUPA charter was created with one goal in mind:

    The working group will have succeeded when the SUPA policy constructs are
    re-used in future IETF specifications (and ideally specifications from other
    SDOs), in a manner that saves development time and avoid inconsistencies
    between data models developed by different working groups.

At charter time, the IESG limited the scope of work, the deliverables, 
and the related milestones dates for a phase approach in this world of 
policy and data modeling: event-condition-action, a single management 
domains, etc.

All the SUPA documents should have been published a year ago. Delays are 
actually common at the IETF, but what concerns me is that the SUPA data 
model is not being reused 
<https://yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-supa-policy&recurse=0&rfcs=1>, 
while all the data models are being standardized, including ones 
containing policies.
The SUPA reuse success is not there, and I regret it. As I mentioned 
before, the window of opportunity has been closing rapidly.
Note: using the SUPA data model as a way to encode polices between two 
controllers is nice, but not that reuse metric.

The WG received some early warnings, one of them at IETF 98 
<https://www.ietf.org/mail-archive/web/supa/current/msg01612.html>.
After reviewing the facts during this week, and discussing them with the 
IESG and the IAB this Friday afternoon, I concluded to close the SUPA WG.

I invite the authors who want to pursue publication to pursue the 
Independent Submission 
<https://https://www.rfc-editor.org/about/independent/www.rfc-editor.org/about/independent/> 
road.

Let me thanks the SUPA chairs Nevil and Daniel, who have been trying hard.

Regards, Benoit (responsible AD).