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

"Acee Lindem (acee)" <> Fri, 20 July 2018 14:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D0F16130E2D for <>; Fri, 20 Jul 2018 07:01:09 -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 l5uozjqu4L1X for <>; Fri, 20 Jul 2018 07:01:08 -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 1C8B5130DE7 for <>; Fri, 20 Jul 2018 07:01:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2042; q=dns/txt; s=iport; t=1532095268; x=1533304868; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=RIXkfy7PTY45zHdYs/8aGpgm4c3bNOj9oCSGLehAHjU=; b=BCFlhHFfPu9zv2XXoTfdm51Gb1vG2YHaOJmaZ6xpjoQYTzMlaqFLYtuS dbcrEMnjRp2TTz+bYPBhPeHO5lCayHwHBC/jOO5ERLVXNK2OBB4IOj0Pd fgm6V9ZRmst0Yrp0DFvCb0YuYJ1aOV326FS+Zd4HeNwY23UPj43gReNem A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRAwA76lFb/4MNJK1bGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYNNY38oCoN0iASML4Fog1ySBIF6CxgLhANGAheCdSE0GAECAQE?= =?us-ascii?q?CAQECbRwMhTcCBAEBIRE6GwIBCBoCJgICAiULFRACBAESgyABgX8PqiyBLoR?= =?us-ascii?q?dhW4FgQuHd4IWgREnDIJegxkBAYFggwExgiQCjFyNEAkCjy6NcpF6AhEUgSQ?= =?us-ascii?q?dOIFScBU7KgGCPosVhT5vjCmBGwEB?=
X-IronPort-AV: E=Sophos;i="5.51,379,1526342400"; d="scan'208";a="145352676"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jul 2018 14:01:07 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id w6KE170p011163 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 20 Jul 2018 14:01:07 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 20 Jul 2018 10:01:06 -0400
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Fri, 20 Jul 2018 10:01:06 -0400
From: "Acee Lindem (acee)" <>
To: Martin Vigoureux <>, "" <>
Thread-Topic: [netmod] "iana" in yang modules' name/namespace/prefix
Date: Fri, 20 Jul 2018 14:01:05 +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: Fri, 20 Jul 2018 14:01:10 -0000

Hi Martin, 
I would prefer not using "reg" since it will always be an abbreviation for a machine language register to me. I'd favor using "registry" in the module name and the more cryptic "reg" in the module prefix. 

´╗┐On 7/20/18, 9:46 AM, "netmod on behalf of Martin Vigoureux" < on behalf of>; wrote:

    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.
    netmod mailing list