Re: [netmod] An abundant amount of IANA if types...

Ladislav Lhotka <lhotka@nic.cz> Fri, 06 April 2018 13:22 UTC

Return-Path: <lhotka@nic.cz>
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 8866A12702E for <netmod@ietfa.amsl.com>; Fri, 6 Apr 2018 06:22:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level:
X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 vBL75iOx0te1 for <netmod@ietfa.amsl.com>; Fri, 6 Apr 2018 06:22:50 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 9AFFE1201FA for <netmod@ietf.org>; Fri, 6 Apr 2018 06:22:49 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:4431:4fff:fe6e:1c10]) by mail.nic.cz (Postfix) with ESMTPSA id 289476244A; Fri, 6 Apr 2018 15:22:48 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1523020968; bh=fPWqFLiYCsYxGyga+hLdBT+HyB07bdHzZBSL2oqYrgw=; h=From:To:Date; b=T1qod7AeW4K3XtobemwOrssO48+zczpdyohUk1tJDsj/VTQrIcQ1ZTsX1744D2OFG 9nyZ2KpxAA2ueYKGKhBp1s2vho+5dhFL89bKzsN3kOvoeTcr/42sxnPTUSISTVQhXl BHUHdUHHcqz3pG8B1wZRuQFzxuJBy9JBu64QszO0=
Message-ID: <8de7899b9f7c7b61d200c2b6ad11aeca45d712df.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Cc: netmod@ietf.org
Date: Fri, 06 Apr 2018 15:22:47 +0200
In-Reply-To: <20180406122901.yayqpgrvxmjzu4eo@elstar.local>
References: <AM4PR07MB1716AECAC144285D98B0E1EE94BB0@AM4PR07MB1716.eurprd07.prod.outlook.com> <1522972773708.26374@Aviatnet.com> <95e15ae380a2e114a8defa3ad924d73c15137b1b.camel@nic.cz> <AM4PR07MB1716DDB1796AA320616F7C0F94BA0@AM4PR07MB1716.eurprd07.prod.outlook.com> <20180406081830.go3hfajpr4hp6svm@elstar.local> <87h8oora3f.fsf@nic.cz> <20180406113639.rgmxofccvsn7gzw5@elstar.local> <2d13795de2ba190878afaf8b1dd94e9d9495a6a7.camel@nic.cz> <20180406122901.yayqpgrvxmjzu4eo@elstar.local>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.1
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/xHqTAGDT4Hlt_f_l1on-4bVFWtc>
Subject: Re: [netmod] An abundant amount of IANA if types...
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: Fri, 06 Apr 2018 13:22:52 -0000

On Fri, 2018-04-06 at 14:29 +0200, Juergen Schoenwaelder wrote:
> On Fri, Apr 06, 2018 at 02:01:30PM +0200, Ladislav Lhotka wrote:
> > On Fri, 2018-04-06 at 13:36 +0200, Juergen Schoenwaelder wrote:
> > > On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote:
> > > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:
> > > > 
> > > > > If we would have a mechanism to deviate an identityref to a subset of
> > > > > identity values supported by an implementation, we would have solved a
> > > > > more generic problem. Yes, the IANA list could be 'nicer' but it will
> > > > > never be 'nice'.
> > > > 
> > > > Three mechanisms can be used for this:
> > > > 
> > > > - splitting the identities into separate modules
> > > 
> > > Whatever module organization you come up with, it won't work for all
> > > implementations. 
> > > 
> > > > - using features
> > > 
> > > Making every identity a feature will turn the feature system upside
> > > down. This is similar to making every leaf a feature.
> > > 
> > > > - using deviations (even though vendors frown on them)
> > > 
> > > If my implementation only supports A and B and C, then a deviation may
> > > state exactly that and the problem is solved. Hoping that my specific
> > 
> > In fact, deviations cannot delete identity values because they aren't schema
> > nodes, so they are of no use.
> 
> Putting today's limits of YANG syntax aside for the moment, I still
> believe implementations need to publish the identities they support
> without requiring matching features or module definition.

OK, but then I certainly wouldn't call it a deviation.

> 
> > > combination of A and B and C matches a set of modules or some set of
> > > features is in my view an illusion.
> > 
> > An implementation that supports, say, a given type of tunnel interface will
> > implement the module that covers this tunnel type. If the identity for this
> > tunnel interface type is defined in the same module, then all is good. I
> > don't
> > get why this should be an illusion. On the contrary, I think it is the
> > cleanest
> > available solution to this conformance specification problem.
> > 
> > > 
> > > Vendors not shipping proper deviations are essentially telling their
> > > customers that they have not yet understood model driven management.
> > > We need to change the mindset here instead of polluting our data
> > > models with hundreds or thousands of fine grained 'features'.
> > 
> > I agree that zillions of features aren't nice but it seems to be the only
> > solution that we currently have for modules of the iana-if-type style.
> > 
> > Having an bulky set of identity values, most of which are of no interest, is
> > IMO
> > much worse and could also be a security issue if implementors aren't careful
> > enough.
> 
> If an implementation does not check input, then the code is broken,

Come on, the cyberspace is full of such code. We should do our best to enable
schemas that are as strict as possible.

In XML, it should have been clear to everybody that hardwired namespace prefixes
are broken, and yet they were used so often that eventually the prefix-URL
duality was identified as a flaw of XML itself.

Lada 

> regardless whether we restrict the identities somewhere or not. I do
> not buy the security point.
> 
> /js
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67