Re: [netmod] Proposal for minimalist full NMDA support in schema mount

Christian Hopps <chopps@chopps.org> Wed, 28 February 2018 18:28 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636A6120727 for <netmod@ietfa.amsl.com>; Wed, 28 Feb 2018 10:28:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 O0BYGSaKt8_A for <netmod@ietfa.amsl.com>; Wed, 28 Feb 2018 10:28:51 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 174C11200E5 for <netmod@ietf.org>; Wed, 28 Feb 2018 10:28:51 -0800 (PST)
Received: from tops.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 4CBE662A79; Wed, 28 Feb 2018 18:28:50 +0000 (UTC)
References: <87woz2a3x1.fsf@chopps.org> <596f5e0b-301e-e102-bcae-c3421b24455b@cisco.com> <87lgfg9ded.fsf@chopps.org> <20180226.160921.622063322182936097.mbj@tail-f.com> <20180227083116.xtlnju34s7ksjntc@elstar.local> <1519720727.10739.1.camel@nic.cz>
User-agent: mu4e 1.0; emacs 25.3.1
From: Christian Hopps <chopps@chopps.org>
To: Ladislav Lhotka <lhotka@nic.cz>
Cc: netmod@ietf.org
In-reply-to: <1519720727.10739.1.camel@nic.cz>
Date: Wed, 28 Feb 2018 13:28:48 -0500
Message-ID: <87muztq87z.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/cBCWggqcx3EpIzkGV1BY8lJvXMU>
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Feb 2018 18:28:52 -0000

Ladislav Lhotka <lhotka@nic.cz> writes:

> On Tue, 2018-02-27 at 09:31 +0100, Juergen Schoenwaelder wrote:
>> On Mon, Feb 26, 2018 at 04:09:21PM +0100, Martin Bjorklund wrote:
>> > Hi,
>> >
>> > Christian Hopps <chopps@chopps.org> wrote:
>> > >
>> > > Hi Rob,
>> > >
>> > > You do realize that no-one trying to actually deploy and run networks
>> > > cares about live-discovery of different schema per datastore for the
>> > > same mount point right? Like 99.999% of the clients know where things
>> > > are supposed to reside and expect them to be there.
>> >
>> > But then why advertise anything at all?   We can do a *much* simpler
>> > solution by just having the mountpoint extension, and nothing else.
>> > Clients will know what to find anyway.
>> >
>>
>> So it this a possible way out of the current situation? We publish a
>> trimmed down document that just defines the mount point extension and
>> we do an update of this document that adds all the details needed to
>> obtain the schema information?
>
> I would say so. It would be immediately usable for the inline case.

This still requires that we pull the routing NI work from the RFC ED queue, change normative text (the document specifically states that use-schema MUST be present, although it does mention that that may be relaxed in the future) as well as the examples listing the schema/modules, this is going to require at least another run through WGLC. It's slightly less obnoxious than the original proposal as its simply removing stuff and losing functionality vs. changing functionality.

Thanks,
Chris.

> Lada
>
>>
>> /js
>>