IETF Logo Mail Archive

Re: [Ideas] draft-padma-ideas-problem-statement and "Common Infrastructure"

Uma Chunduri <uma.chunduri@huawei.com> Wed, 05 July 2017 22:58 UTC

Return-Path: <uma.chunduri@huawei.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 3CA7A126B72 for <ideas@ietfa.amsl.com>; Wed, 5 Jul 2017 15:58:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 kcsgtnAuJHez for <ideas@ietfa.amsl.com>; Wed, 5 Jul 2017 15:58:54 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D822129AAD for <ideas@ietf.org>; Wed, 5 Jul 2017 15:58:53 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJV01514; Wed, 05 Jul 2017 22:58:51 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 5 Jul 2017 23:58:49 +0100
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.142]) by SJCEML703-CHM.china.huawei.com ([169.254.5.136]) with mapi id 14.03.0301.000; Wed, 5 Jul 2017 15:58:43 -0700
From: Uma Chunduri <uma.chunduri@huawei.com>
To: Robert Moskowitz <rgm-ietf@htt-consult.com>, tjw ietf <tjw.ietf@gmail.com>
CC: "ideas@ietf.org" <ideas@ietf.org>
Thread-Topic: [Ideas] draft-padma-ideas-problem-statement and "Common Infrastructure"
Thread-Index: AQHS9ZPE963S1drr902KkhfKflevlaJFubYAgAAC9gCAABhC4A==
Date: Wed, 05 Jul 2017 22:58:42 +0000
Message-ID: <25B4902B1192E84696414485F5726854019E2929@SJCEML702-CHM.china.huawei.com>
References: <9084360a-160e-944a-96aa-0b33379ccdb8@htt-consult.com> <CADyWQ+FK7AJA4vvKG9oT+EwRVJkGWU7iiw62jCpLykxJeqeuGg@mail.gmail.com> <1788bf20-2ee5-c2fd-0108-ff4b2b779848@htt-consult.com>
In-Reply-To: <1788bf20-2ee5-c2fd-0108-ff4b2b779848@htt-consult.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.245.54]
Content-Type: multipart/alternative; boundary="_000_25B4902B1192E84696414485F5726854019E2929SJCEML702CHMchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.595D6F2B.0146, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.142, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: a9c7c8d0e79e69d1888db5d6c56bb68a
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/rw2DQJ-2M4N9g3MSiS6Huf4QZE0>
Subject: Re: [Ideas] draft-padma-ideas-problem-statement and "Common Infrastructure"
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, 05 Jul 2017 22:58:57 -0000

Hi Bob,

> I said 'requirements' to soften the blow, so to speak, about 'why NOT LDAP'.  Plus the data model to see if it can fit into an LDAP schema.
> Of course we could always go with DAP instead for richer policy control and distributed data support!

I am not sure if this would be LDAP or something else. I presume the context is entities authentication and subsequent operations to indicate policy. Is this correct?

If Yes, I have couple of thoughts:


1.       We ought to focus on category of entities (low power/regular nodes/routers) and see what suits best. Perhaps one of the EAP methods suitable to the environments (minimal RTTs, mutual authentication if needed in some cases)?

2.       Regarding policy - I see your point of "richer policy" but we may have to start with much more simpler policy (say white list/black list on Identifiers) as some of it has to be distributed/shared across without any privacy concerns

3.       Regarding distribution of public parts of policy and other information with Identifiers, we ought to see if we have to use any existing mapping servers (DDT, DHT, Blockchain or some simplified/selective pull based "new" protocol among each providers Identifiers).

May be we might have to discuss problems and requirements bit deeper to hash out the above.
--
Uma C.

From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Robert Moskowitz
Sent: Wednesday, July 05, 2017 7:16 AM
To: tjw ietf <tjw.ietf@gmail.com>
Cc: ideas@ietf.org
Subject: Re: [Ideas] draft-padma-ideas-problem-statement and "Common Infrastructure"

Tim,

Well it seems I got an upgrade to contributing to the problem statement.  I missed that in the last go around hours before the draft cutoff.  Thanks Padma.

I said 'requirements' to soften the blow, so to speak, about 'why NOT LDAP'.  Plus the data model to see if it can fit into an LDAP schema.

Of course we could always go with DAP instead for richer policy control and distributed data support!  (was it actually 20 years ago that I worked on this stuff? yikes!)

Bob

On 07/05/2017 10:05 AM, tjw ietf wrote:

Bob!

Brian and I had chatted briefly about charter direction and we wanted to hear some of the discussions during the session. And that's what they pay us the big bucks for!

But I have to agree with your plan of attack.  If we could give some guidance:

- work on the problem statement and gap analysis but don't invest larger cycles of time on them.

- requirements are good to capture, but we will shy away from turning them into published documents as they will change over time

- some discussion on LDAP is very necessary as the code base has gotten quite mature.

tim

On Wed, Jul 5, 2017 at 9:35 AM, Robert Moskowitz <rgm-ietf@htt-consult.com<mailto:rgm-ietf@htt-consult.com>> wrote:
Disclaimer:  I had a hand in edits to this version, though I am not listed in the Ack section.  In particular I pushed for "Common Infrastructure", not "Common Control Plane".


We have been talking a lot about Identity and Identifier and metadata.  One of the tasks of this workgroup (and charter item) needs to be data modeling of what is intended to be stored/available.

Further there needs to be Yet Another Gap Analysis (YAGA?  :) ) on why NOT LDAP or some other mature xyz data store access protocol.  I start with LDAP as there is actually a fit, and the various server implementations are very mature with good, secure, backends and data replication tools.

It is time to start thinking charter.  The problem statement, gap analysis, and use cases is barely a start.  What the group is going to DO is focus now.

So I propose two work items:

Common Infrastructure data modeling (and someone other than me can do it in YANG).
Common Infrastructure protocol requirements with a subsection on LDAP comparision.

Bob


_______________________________________________
Ideas mailing list
Ideas@ietf.org<mailto:Ideas@ietf.org>
https://www.ietf.org/mailman/listinfo/ideas





_______________________________________________

Ideas mailing list

Ideas@ietf.org<mailto:Ideas@ietf.org>

https://www.ietf.org/mailman/listinfo/ideas

v2.23.0 | Report a Bug | By Email