[OPSAWG] IPPROV BoF was declined

Benoit Claise <bclaise@cisco.com> Tue, 11 October 2016 16:27 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5D9BC129645; Tue, 11 Oct 2016 09:27:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.517
X-Spam-Status: No, score=-17.517 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id kWczIK0aR9Ah; Tue, 11 Oct 2016 09:27:50 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15768129643; Tue, 11 Oct 2016 09:27:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7429; q=dns/txt; s=iport; t=1476203269; x=1477412869; h=from:subject:to:cc:message-id:date:mime-version; bh=QJNKZ1eU+w5vWh3IcL3dSn+slABg2HkDZR8wIhRw9S0=; b=WEOSqw6zBQcN4EWMfwTo1fnIwAJ2p8O+bXbO2oDa4CAWfQ0sf5jxP7ID FCfQeFcBitS3DCD5odTOK5cVqHhH3QxmmrD1A1lTfde2+LL9ENmYIhX5N 6PpD3GWzcrA6OKnK56XWGghxJJcatXnMT9Wisj6I0nqv4bRML6fl4oD9e 4=;
X-IronPort-AV: E=Sophos;i="5.31,329,1473120000"; d="scan'208,217";a="646300406"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Oct 2016 16:27:47 +0000
Received: from [] (ams-bclaise-8914.cisco.com []) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u9BGRkPj003567; Tue, 11 Oct 2016 16:27:46 GMT
From: Benoit Claise <bclaise@cisco.com>
To: "opsawg@ietf.org" <opsawg@ietf.org>
Message-ID: <6516fa03-8075-1401-933f-dda07c507db1@cisco.com>
Date: Tue, 11 Oct 2016 18:27:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------709E24ED4FD48B19F4652F44"
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/g74fPa3UuMPo4mKvj15-ZJpfLU4>
Cc: Sebastien Marchal <smarchal@cisco.com>, draft-xie-ps-centralized-address-management@ietf.org, draft-sun-i2apm-address-pool-management-arch@ietf.org, draft-sun-i2apm-address-pool-management-yang@ietf.org
Subject: [OPSAWG] IPPROV BoF was declined
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 11 Oct 2016 16:27:52 -0000

Dear all,

Let me inform you that the IPPROV 
<https://trac.tools.ietf.org/bof/trac/#OperationsandManagement>BoF was 
declined by the IESG/IAB.

Even if the IETF discussion started three IETF meetings ago 
and draft-sun-i2apm-address-pool-management-yang 
were presented at IETF 94 in OPSAWG), this BoF request came as a 
surprise, on the last day just before the BoF submission deadline. As 
such, it didn't generate much (visible) discussion among the community.

is about a YANG model for IPv4 management. Coming from an operator, it 
was specifically welcome, and OPSAWG seems like the perfect WG.

        This document describes an mechanism for a standard, programmatic
    interface for address pool management.   With the remaining IPv4
        address becoming more and more scattered, it is complicated to
        manually configure the address pools on lots of Broadband Network
        Gateways(BNGs) for operators.  By introducing SDN/NFV in BNG, the
        address pools can be allocatedin a centralized way.  It will not
        only simplify the address management for operators, but also improve
        the utilization efficiency of the address pool.

One issue is that IPAM use cases involve many different NMS/OSS 
different systems: IPAM, DHCP, DNS, Orchestrator, CMTS, Router, 
Firewall. All these different key players need to agree on these 
protocol exchanges/APIs/data models. Btw, I consider YANG models as 
APIs, as the APIs can be deduced from the models.
While we understand that any operators have this issue today and would 
like to have a simplified solution for address pool management, do we 
have all the key players from the NMS/OSS ecosystems involved, and a 
willingness to implement what would become a standard?

On top of that, some integration happens today, as those independent 
different systems have some embedded automation and event mechanisms. 
Today, the controller/orchestrator will take whatever is APIs are 
available. Granted, the integration is certainly clean and standardized, 
but aren't we risking to be late if a standard is approved in 1.5 years? 
Or maybe this effort should be supported in opensource, with de facto 

Looking at the scope, it seems that it extended along the time: From 
IPv4 address management to IPv6 (well, obviously, we have the same 
issues with IPv6) to bandwidth and services management, along with some 
"possible protocol work", as mentioned in the BoF description.
A well defined scope is a plus for a BoF request.

This BoF would be have benefited from some more preparation and 
preliminary discussions with the community and the ADs.
The connection with ANIMA, as discovered on the mailing list, is 
certainly a prove of that.

Finally, not having a BoF is certainly not a reason for the community to 
stop organizing itself.

Regards, Benoit