Re: [Ideas] Your Input requested: Charter Proposal New Version

Robert Moskowitz <rgm-ietf@htt-consult.com> Wed, 16 August 2017 19:58 UTC

Return-Path: <rgm-ietf@htt-consult.com>
X-Original-To: ideas@ietfa.amsl.com
Delivered-To: ideas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B09C132350 for <ideas@ietfa.amsl.com>; Wed, 16 Aug 2017 12:58:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 GHE41rad13sk for <ideas@ietfa.amsl.com>; Wed, 16 Aug 2017 12:57:57 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 479C01326DD for <ideas@ietf.org>; Wed, 16 Aug 2017 12:57:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 79917621AD; Wed, 16 Aug 2017 15:57:54 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DkuzTaB45zMP; Wed, 16 Aug 2017 15:57:47 -0400 (EDT)
Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 1FF7C621AC; Wed, 16 Aug 2017 15:57:46 -0400 (EDT)
To: Dipankar Raychaudhuri <ray@winlab.rutgers.edu>, ideas@ietf.org
References: <175f533795012c49555543dda2f1f3a8@mail.gmail.com>
From: Robert Moskowitz <rgm-ietf@htt-consult.com>
Message-ID: <61c9fd55-b7b7-e4b7-2f62-a1026a46ce0f@htt-consult.com>
Date: Wed, 16 Aug 2017 15:57:44 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <175f533795012c49555543dda2f1f3a8@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------41CAB2B49C8264AB750ED9A8"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/B1Og32xW_6Ag16nOIN_irE6TlCQ>
Subject: Re: [Ideas] Your Input requested: Charter Proposal New Version
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <ideas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ideas>, <mailto:ideas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ideas/>
List-Post: <mailto:ideas@ietf.org>
List-Help: <mailto:ideas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ideas>, <mailto:ideas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Aug 2017 19:58:00 -0000

Ray,

On 08/16/2017 01:11 PM, Dipankar Raychaudhuri wrote:
>
> I reviewed the charter document and feel that it is a good start.  My 
> main comments are:
>
> (1) I agree with the concept of an identity-identifier split, which is 
> necessary for an important set of applications requiring dynamic 
> change of identifier. Realizing this will require something similar to 
> a trusted “name certification service”  [cf. “MobilityFirst: A Robust 
> and Trustworthy Mobility-Centric Architecture for the Future Internet, 
> ACM MC2R, July 2012] in addition to a dynamic name-to-locator 
> mapping/resolution service [cf. ”DMap: A Shared Hosting Scheme for 
> Dynamic Identifier to Locator Mappings in the Global Internet”, ICDCS 
> 2012]
>
> (2) A key requirement for the mapping service is the ability to 
> support multiple types of resolution including identifier to 
> identifier (i.e. recursive), identifier to group of identifiers, 
> identifier to single locator, identifier to a list of locators, etc.  
> We have found the recursive identifier resolution capability to be 
> very useful for scaling and new service creation.
>
> (3) The final output of the WG at the end of the doc should be filled 
> in a bit further in terms of specific APIs and query/response/update 
> protocol definitions to be included in the spec.
>

You really don't want a starting charter this specific.  You can have 
wording about working on an API, but APIs have always been a sore item 
in the IETF.  Also this is why I2NSF talks about Interfaces and 
capablities, not APIs.  Leave the specitivity for the workgroup, not try 
and get the post-BOF to complete the work to start the workgroup.

> (4) While I realize that the current charter’s scope is intentionally 
> limited to defining general-purpose control plane support, the spec 
> could be of greater value by defining or linking one or more specific 
> identifier-based routing (data plane) protocols compatible with the 
> IDEAS infrastructure.
>

This comes out in the workgroup, and if necessary then you do a charter 
revision.  I need to talk to you separately about TAPS...

> Ray
>
>

Bob