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

Christian Hopps <> Sun, 25 February 2018 14:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97C61120227 for <>; Sun, 25 Feb 2018 06:36:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nMQlhtVAlRQI for <>; Sun, 25 Feb 2018 06:36:31 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DE940126C89 for <>; Sun, 25 Feb 2018 06:36:30 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id A3FE262A28; Sun, 25 Feb 2018 14:36:29 +0000 (UTC)
References: <> <> <> <> <> <> <> <20180223192814.xpicpsmsbpcqnwyg@elstar.local> <> <20180225140203.5osj7szmyudwwpxp@elstar.local>
User-agent: mu4e 1.0; emacs 25.3.1
From: Christian Hopps <>
To: Juergen Schoenwaelder <>
Cc: Christian Hopps <>, Lou Berger <>,
In-reply-to: <20180225140203.5osj7szmyudwwpxp@elstar.local>
Date: Sun, 25 Feb 2018 09:36:28 -0500
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: <>
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 25 Feb 2018 14:36:33 -0000

Juergen Schoenwaelder <> writes:

> On Sat, Feb 24, 2018 at 11:37:11AM -0500, Christian Hopps wrote:
>> Juergen Schoenwaelder <> writes:
>> > - For the pre 09 'camp', it seems integration with YLbis is the key
>> >   technical requirement that is driving them.
>> >
>> > What is the key technical critical issue for the other camp?
>> We have RFCs in the publication queue (i.e., awaiting RFC numbers) to manage VPNs, VMs, etc, that are literally only blocked on this work being published (as written). To change this document in the proposed fashion invalidates the pending RFCs which would then need to be pulled from the publication queue and reworked along with the new proposed changes. The industry is waiting on and needs these RFCs to get work done. I do not think it's reasonable to ask the industry to now wait even longer to go back and rewrite what is already good enough and ready for publication and use.
> If the change to schema mount (i.e., how schema information is
> exposed) invalidates the normative parts of documents that define data
> models that may exist under a mount point, then I think we got the
> coupling between documents wrong.

It invalidates the examples for sure. But normative vs informative isn't the point. Doing the examples last time exposed issues with the design. There's no reason to think that won't occur here. The point is that people are justifying the proposed change by saying it's quick and non-disruptive, and that's simply *not* the case.

We have finished this work, and important stuff that the industry requires is waiting (one wonders how much longer though)

It's time to publish the good work we've done.

> Anyway, if we can't find a solution that can work for everybody
> involved, then we may be left with the only alternative to escalate
> this further. My guess is that we will only loose time and we will all
> look stupid at the end, hence I was hoping we could avoid this.

If by escalation you mean protests to hold up the work the industry needs during the IESG/IETF LC versus just doing the new work separately?

<sarcasm> Yeah, that'll make us look *really* competent to the industry too. </sarcasm>

One hopes that we don't end up with that nonsense.


> /js