Re: [netmod] "iana" in yang modules' name/namespace/prefix

"Acee Lindem (acee)" <> Sun, 22 July 2018 14:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD5D3130F4F for <>; Sun, 22 Jul 2018 07:20:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9KQoxO66p_pw for <>; Sun, 22 Jul 2018 07:20:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A895130F46 for <>; Sun, 22 Jul 2018 07:20:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3022; q=dns/txt; s=iport; t=1532269216; x=1533478816; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=7vpVUh0kK746EuavK8y45W0MokJjKhpwFuZRtS7qQDI=; b=U2i+2J2s+IyRHI0Hjh4+ASSmyIqkina4eC3SEQDBR0EfK8UJ+oApdopg WrnJIv9Upwd769AtJJ1vBwchzy6WPGHrVoZkQqpXRj1q5lwxx6I9mpApS inHT2HCSaZFh4mmEU7Ixx1Opv0rTnIplToryvDGvdJA60OmTEM9/i63+W o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtAgCXkVRb/4wNJK1cGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYNNY38oCoN0iASMMoFog12SBIF6CxgLhANGAheCdSE0GAECAQE?= =?us-ascii?q?CAQECbRwMhTcCAQMBASEROhsCAQgaAiYCAgIlCxUQAgQBEoMgAYF/D65qgS6?= =?us-ascii?q?KSQWBC4d3ghaBEScMgl6DGwEBAoRfMYIkAoxcjRAJAo8ujXKRegIRFIEkHTi?= =?us-ascii?q?BUnAVOyoBgj6LFYU+bwGNeIEbAQE?=
X-IronPort-AV: E=Sophos;i="5.51,389,1526342400"; d="scan'208";a="427340616"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jul 2018 14:20:15 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id w6MEKEEF007396 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 22 Jul 2018 14:20:15 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 22 Jul 2018 10:20:14 -0400
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Sun, 22 Jul 2018 10:20:14 -0400
From: "Acee Lindem (acee)" <>
To: Benoit Claise <>, Martin Vigoureux <>, "" <>
Thread-Topic: [netmod] "iana" in yang modules' name/namespace/prefix
Thread-Index: AQHUIDAKdENQS5PIXkGtPzyGTnThaaSbiagA///ELYA=
Date: Sun, 22 Jul 2018 14:20:14 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [netmod] "iana" in yang modules' name/namespace/prefix
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 22 Jul 2018 14:20:18 -0000

Hi Benoit, et al, 
I couldn't agree more. The IETF has much more exigent issues with respect to YANG models and the attendant protocol infrastructure than whether IANA might go away in the future. 

On 7/22/18, 9:54 AM, "netmod on behalf of Benoit Claise" < on behalf of>; wrote:

    I'm wonder whether this is really an important optimization, worth 
    changing now, in the hypothetical case that IANA is not called IANA any 
    longer in the future?
    Right now, "iana" n the YANG module name correctly states what this is about
         => "maintained by IANA"
    I agree with Jürgen that documenting this in 6087bis is the right way 
    Regards, Benoit.
    > Hello
    > As part of a recent IESG review (of draft-bfd-yang) a point came up on 
    > the use of "iana" in yang modules' name/namespace/prefix.
    > This is typically used in the case where the module refers to an IANA 
    > maintained registry. However, the point raised was that the name of 
    > the registry operator might not always be IANA, and that using that 
    > name might not put modules on the most stable deployment footing under 
    > all possible circumstances.
    > On top of that, as far as I can tell, the use of "iana" is an 
    > undocumented convention.
    > So, I wanted to collect views:
    > on whether a convention should be documented,
    > and, with regards to the point raised in IESG, on whether that keyword 
    > should be changed going forward. In that context, what about "reg" 
    > (for registry) or "regop" (for registry operator)? Other proposals are 
    > welcome.
    > Thanks
    > -m
    > _______________________________________________
    > netmod mailing list
    > .
    netmod mailing list