Re: [netconf] IANA templates for algorithms

Ladislav Lhotka <lhotka@nic.cz> Wed, 19 February 2020 12:57 UTC

Return-Path: <lhotka@nic.cz>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE82212003F for <netconf@ietfa.amsl.com>; Wed, 19 Feb 2020 04:57:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 BekMdQZtHMMQ for <netconf@ietfa.amsl.com>; Wed, 19 Feb 2020 04:57:20 -0800 (PST)
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 EC4EE120019 for <netconf@ietf.org>; Wed, 19 Feb 2020 04:57:19 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id C3053140B42; Wed, 19 Feb 2020 13:57:16 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1582117036; bh=BT00lymVDZo665X6XFKSxhTE1br101bh6zW49gePNC8=; h=From:To:Date; b=wyXbVEoq/UTqLc+LJpUbRJcdIRbGJ8hzh5utAvEQ3xr2uXO8tf588WvI/B5MP8YPX C+gaNlsOb1jlUoq8OTPgAx056MnPetwIWnwxj6fOfc8zrxWfQsG6MV81YjkmJYMKhr DUDuYsrBaLJl1YpfLzSvtGaeFy9BBU/+a3JJ5M7c=
Message-ID: <93d0d5faf613b8b5c72b74d59ed2e0a55e9ac509.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: Kent Watsen <kent+ietf@watsen.net>
Cc: "netconf@ietf.org" <netconf@ietf.org>
Date: Wed, 19 Feb 2020 13:57:16 +0100
In-Reply-To: <010001705d5105d1-87b474be-6b84-4a22-8a7f-2629923661c3-000000@email.amazonses.com>
References: <010001705ad1e8a3-891d7081-80c2-4a0d-857e-f6242b1a8793-000000@email.amazonses.com> <87h7znvtvg.fsf@nic.cz> <010001705d5105d1-87b474be-6b84-4a22-8a7f-2629923661c3-000000@email.amazonses.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.34.4
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.101.4 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/_-ThAAzNtU6LWb22ITF52FpYjkI>
Subject: Re: [netconf] IANA templates for algorithms
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Feb 2020 12:57:25 -0000

On Wed, 2020-02-19 at 11:59 +0000, Kent Watsen wrote:
> Hi Lada,
> 
> > Strictly speaking, the XSLT stylesheet is still intended only for producing
> > the initial revision of the module.
> 
> Apparently  my expectations got ahead of me.

This solved the objections raised in the DNSOP WG, and I don't want to harass
them with any more complications. :^) 

> 
> 
> > Re-running the stylesheet on a later revision of the registry would
> > essentially work, only the revision history would be lost. I don't see any
> > easy workaround to this.
> 
> Perhaps pass the YIN of the “current” YANG module into the XSLT script too?
> 

Yeah, but this is already not exactly straightforward. 

> 
> > It is up to IANA (we can help them) to decide whether the YANG module will
> > be updated as before, e.g. by manually adding new enums, identities etc., or
> > whether they use the stylesheet and then manually edit the revision history.
> 
> But it’s still a manual YANG-editor level effort, which is new (I assume) to
> IANA.

I assume they do manual editing of modules like "iana-if-type" when rolling out
a new revision.

> 
> 
> > Maybe it would be useful to write an informational RFC suggesting a workflow
> > for these cases.
> 
> Don’t think that there is a patten just yet.  Your draft’s use XSLT to create
> the initial revision makes sense only in that the registry already exists and 

Yes, this is intended for mapping existing registries to YANG in a 1-1 fashion.

> new registrations may occur while your draft is being published.

The main concern of some DNSOP people was that the RFC itself is not updated, so
somebody can use the obsolete module contained therein any time later. If they
do it with the XSLT stylesheet, they should get basically the current data.

>  
> 
> In crypto-type's case, the intention is to create a brand new registry/YANG-
> module, so we could just as easily put the initial YANG module into the draft,
> negating the need for IANA to run `xsltproc` at all.

Then the YANG module effectively becomes the registry. It is a different problem
though.

> 
> If IANA doesn’t run XSLT for subsequent updates, I think that we (NETCONF)
> need to question if a registry is even needed.   The motives behind defining a

This is of course a rather NETCONF/YANG-centric view. There are people who don't
give a damn to YANG and NETCONF, but still need a registry. 

> registry are 1) to accommodate IANA and 2) to make it seem more
> official/interesting to the Sec folks (since “YANG” appears to be
> uncool/taboo?).  But if IANA is okay editing the YANG, and the Sec folks are
> still uninterested, then we could skip creating the registry altogether.

Yes, but then somebody will have to take care about maintaining the module. I
think that NETCONF isn't the right place for it, and sec folks may not be
interested.

Lada

> 
> That said, I feel that creating a, e.g., “base algorithms” registry is best,
> as it allows for potential future/other use cases, and I’m hopeful/optimistic
> that we can get the Sec folks onboard.
> 
> 
> Kent // contributor
> 
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67