Re: [yang-doctors] reference in import statement

Ebben Aries <exa@juniper.net> Thu, 22 February 2018 21:00 UTC

Return-Path: <exa@juniper.net>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E506112DA11 for <yang-doctors@ietfa.amsl.com>; Thu, 22 Feb 2018 13:00:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 ItEeTAgSJ783 for <yang-doctors@ietfa.amsl.com>; Thu, 22 Feb 2018 13:00:57 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 4144D12DA0C for <yang-doctors@ietf.org>; Thu, 22 Feb 2018 13:00:57 -0800 (PST)
Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1MKxxNo025410; Thu, 22 Feb 2018 13:00:54 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to; s=PPS1017; bh=WixqTd4ow2c/C4OjQaA2GvA9aiyE1jAt+0gC/R+xhDk=; b=wN1q7J3rOm6ZOcIaAEHrg2uJsy2UNbaDPQ5NbFJAGSTLBEQvliC5M8c+xc6XAxJD69mP oodWAY6Y24s49lq1ohF+RBP0yYF8Xit+12O4pXPNr4hQdBahD5XMEYOvGYF7A4HTf4hm 70IN6VlerXAko/4jmMVYrA3M6VSnPjqVpGAFM9cFD7LmfKYIMhSL0dZZEp86LScKAPED /QH0duWGk4K+Oi9fLyFk1Zii7sSaYLNUGBn4SQHzdu+FptkqzXqmrfSG8zIZJRsi41rq 1vMI1nll+AsRz2MKtZjE3vxu2N8ZlIh11zp9/S7sSqpwQZIeMPAXpTflI9SDb4KFHTUy XQ==
Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0056.outbound.protection.outlook.com [216.32.180.56]) by mx0a-00273201.pphosted.com with ESMTP id 2ga5cfr04e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 22 Feb 2018 13:00:51 -0800
Received: from BLUPR05CA0041.namprd05.prod.outlook.com (10.141.20.11) by CY4PR05MB3640.namprd05.prod.outlook.com (10.171.247.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.527.6; Thu, 22 Feb 2018 21:00:48 +0000
Received: from CO1NAM05FT057.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::204) by BLUPR05CA0041.outlook.office365.com (2a01:111:e400:855::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.548.6 via Frontend Transport; Thu, 22 Feb 2018 21:00:48 +0000
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender)
Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by CO1NAM05FT057.mail.protection.outlook.com (10.152.96.174) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.20.527.7 via Frontend Transport; Thu, 22 Feb 2018 21:00:47 +0000
Received: from p-mailhub01.juniper.net (10.47.226.20) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 22 Feb 2018 12:59:17 -0800
Received: from smtp.juniper.net (svl-evodev-exa.juniper.net [10.160.40.78]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id w1MKxEZE019631; Thu, 22 Feb 2018 12:59:15 -0800 (envelope-from exa@juniper.net)
Date: Thu, 22 Feb 2018 13:59:14 -0700
From: Ebben Aries <exa@juniper.net>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
CC: Benoit Claise <bclaise@cisco.com>, <yang-doctors@ietf.org>
Message-ID: <20180222205914.2fmyp4733wqckrvb@smtp.juniper.net>
References: <20180215083130.uagwwr5huxgs5qst@elstar.local> <9783C687-6D5B-4FF4-BFB6-3D9FA62DB249@gmail.com> <20180222.085323.144940543114040096.mbj@tail-f.com> <A37B4457-245F-4ACA-957E-94206F08C491@gmail.com> <14396a94-e79f-1c94-564f-d1a9ebf87aec@cisco.com> <80C8A9F0-1067-4937-9FC1-7D18070CDF7A@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <80C8A9F0-1067-4937-9FC1-7D18070CDF7A@gmail.com>
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(39860400002)(396003)(376002)(346002)(39380400002)(2980300002)(199004)(189003)(377424004)(51444003)(2870700001)(7520500002)(6916009)(2950100002)(81166006)(4326008)(81156014)(39060400002)(76176011)(50466002)(6306002)(53936002)(54906003)(106466001)(97736004)(53416004)(316002)(966005)(1076002)(7696005)(2906002)(53546011)(59450400001)(2486003)(23676004)(8936002)(69596002)(8676002)(1411001)(229853002)(93886005)(5660300001)(47776003)(186003)(478600001)(26005)(77096007)(336011)(305945005)(105596002)(356003)(6246003)(68736007)(86362001)(575784001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR05MB3640; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-Microsoft-Exchange-Diagnostics: 1; CO1NAM05FT057; 1:hu3ARS9H+ghcjZxcArmbVMtCJHzFi0IqD63iwOFVSBSBTQt1lwJ1JHHlWPm5stGBf0Ntwscj7qabLzClbYEbO8zkkDLbIwGJWn8ug8yNlpo8nEi0HVlmWVXikFlR/rD5
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: cde7e123-dddc-4839-45d5-08d57a3758fb
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060); SRVR:CY4PR05MB3640;
X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3640; 3:TmOL1OdjGb6Ui965sMCC1+4clQdsLlxHH8O0TNvNjXOkfQG8kWsOE9kNAM3u7xcrgb4ugYnsNYhGN6nguwcO5NU5VxZ1c9FkBE8fl6xzv99W9mKiflcRC5278wdCAdXTZhUheTrRPD+1dopJxEZdgfNHBccpNduh9qUAE23wLHWPtLZPHXi9JrtksJiEqabUrXnEzVrC+KZEr+bUZptTe7zAaYfVYWIlozCVZZzcvP/9FzsomHfd/PZw3F7LXNdHAIWPdvRbw39PrFfFWS1iQ8Gbwh7Q8DGQ+x6KdH1e6GnptAFwhkOFn+TK9NU/aUbXg01fItDR0D4BOCn3wVNol56hXY+3Ha6fm1nExKuveoU=; 25:aKwL0Orh6ADElVVYtyu9vW2NutwBcf9oMWIUqFUiAv8eVGCKQKDwBAKNYvKXY1E94Yg3KJllcGtBvUTSmOzxjUfAA0gxelPHW1573LB8x3sjrQBFLzNXK4o9ImAJueai4QvCa1hOKGtMUBghpqY2iouxcR6Y5RTcpYmKZ/j1UaGgfK6Fpe2gQzXogOoulBgx+zX+iYaOPnrL4dY4ETeVSIGhKGD4ETCndfDOTcnSyrqbV7pYp7tWB7DgiTouTFfE/Cs3dFB0DYFODb4wBLLpcCi+mCiAfgAdIbl7cWP0mK7dd/736mCy9KHUeHqwVZMe2A8uqNhfI00m2CpWKeJ8sQ==
X-MS-TrafficTypeDiagnostic: CY4PR05MB3640:
X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3640; 31:ldJnoMChkrBl9Txic73QDQlLb9ktUNgD33My1HG7li2epiG95TFZ3X5n5WtUiBQM/0xAqthXAADgUwlCqr2pzP+hhc2AJVbsU1d+tMBSox/KGGu03US/UnKbQVvzAcPuYhsokxO2C271WcGgMEN1IF3TJKOiSYf0xGh2cMQlRK94UTllDTi8SXcYDIY+no9ZBtHqaN7/+Evs+PO9Zh0gKGd6U+fieiJGAvu+gzgLGho=; 20:xh7/8kKJu5sI4Ip99sRvtIOtpfkIYE22K5SbspXteBrGQyGbUdK/AlE6q/Wk+y3+wHjpSlswhJ+b+PmGaLVkjem+Ubzm7oArDSu8xiZ9SfjY9NewXnTuTXEuwQSPPnigQ39/5ZHkRwjgtDB7VMJSNq20JCnsY3E2jiYtzS5ouqnedI+7NXH0/q4hWOXq2mZ/KRd3I1CqLgCe6R3S7yiKMdYy3cRY9BwzYwdZULErIrnUEfrOgZCQaWW4R+WXofPVouLTHcBiJSykd1iEhdK8PHED9irfiD0fIezWw5lpjhxsmYKSqAsDMuFn59XfMoUlH5N7c16YGdGWKS7hkVyCeC5YXuwPC5InDo8DBqPE960i08RMOy2c5a/3iqTUshMjP7NK+rkJNYytbH7w0d1AwFtPBT+b8h94YZSvGLthv+1wBSr6K7VCsPtRpt+AZO2aSYV629PfXWj78o3gLtMNDbCnmaGh895lW+JwwqZUqQv1KcvkryHjuMSAQYkcinKk
X-Microsoft-Antispam-PRVS: <CY4PR05MB364036C3406178E112D99827A8CD0@CY4PR05MB3640.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(10436049006162)(85827821059158)(95692535739014);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001082)(6040501)(2401047)(5005006)(8121501046)(3231101)(944501161)(3002001)(93006095)(93003095)(10201501046)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:CY4PR05MB3640; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3640;
X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3640; 4:68jFYpfTL8+iPIaSk7LCVqQeJvN0YT53zRZ5peiR6R242B5JHnZmDBLBGpC+0EFvkagcYDsZw+CUJzqXT5PAduhlqULC4QIYaJzx8pM8N2XMuRJimM5Ups/me2WF0/LSxHG5QPgulnnhypf43em6xzCJNZ3mHf+AqzWxFCds8U1OVGvZGeQHEHUkAVH9Q56nXNw0cyHVJmkVvYqn9rAlonAxMjhNWUIklVBx3geLwZYeTled85j/vDElYAzbFvIejb99U02jVGjU4OBFQ+qHHmPDtfsoX+0wDq7jHz/pFOXVFezHeC6005vsKvGa4BKA0c+sYbqbOknChKaUeXdOZEenxc8Hj/lmXb2WpCOlRH89wDorJYToo6bp30ZltK+Q
X-Forefront-PRVS: 059185FE08
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTRQUjA1TUIzNjQwOzIzOlZMRERtOXQrdkxLcURvSjBZQkFuNHUvOWdv?= =?utf-8?B?Zmd6MW8yYnFnMVZWNFNMMmxPaEswVm1qTWhEbWdlcXZKK3Vlb0tja2N0Tm9F?= =?utf-8?B?ckdRMFJwNEExdDFlV2JLZjdEL3lmcmE1Wml1SlB1Smx0ZVNKbEF0LzVJanNU?= =?utf-8?B?MWFaRU5FRWp6NWNSTElzS2FoT2hJdTRkOStsL3NoWWxTZWJjNlJMV3lUdHYw?= =?utf-8?B?bGk1UTBwOXE4WFhldjJFaStxRXU3d1lreDNiVSsxenFzWXZiVi9QZjVreHJL?= =?utf-8?B?TzdEYWlncWtIUG5URTNFZW4rQUEwZC9wRS85YUt5MzFiT3haUi8zTHVrL3BJ?= =?utf-8?B?T2FmYVVjK0h6QUpMNWJ6K0FOeTVLRCtGQitLKzVualdDMzkxR1llOVlWbTly?= =?utf-8?B?dlVnSHB6NngycWVDeTIzL1BraDYzaTJHSW9HUnd6NVY5Q3Ziakh6cFdkU3o4?= =?utf-8?B?cld6dGczMEFIR002YXkveDlCR2kzcld2YTJXaU9JWEpLMlVNcVM4RzVaY25D?= =?utf-8?B?L0hnQzhuQmFUak9VMEJiQW5veUdyaVRUamFYQWRaMGtjNFg3MlFvQXlRZW9p?= =?utf-8?B?R0pxSXJDSjdpQWFwbkFreis0dUF2cERKQzViWFdFS3BwMlFQWE5HckpJYmhX?= =?utf-8?B?VWMrTU4yNkNEdnRIK3B3QXF6Sk5mVGJDeVp4OVlGL0lFU09IcUJkZ2RvdDVU?= =?utf-8?B?bVhucFI4ZkNSait4OHc4cjkxQTBMK1NKeXp3QzFKY3p1em5RaVBiQ21VdlUr?= =?utf-8?B?Z0NLc285U1hMTktaaVRkRDhCSDdWSEtsTTg1a3RObUlkN2tCMnROM1kxbzYy?= =?utf-8?B?Z29uTnBLUGdjbVhpeGY3QTBNalRObi82SngvNzA4Ym9GRHBUSEduT0tBNG95?= =?utf-8?B?alRHejQ1bUtIZ1dxOGFmbVZORTNHejRlSjJPR0F5Y0IxZ21TeUNYcXVaQVRK?= =?utf-8?B?VUNYeWYwOUZZREpRbE1raVU3MFBzYmlIUlEwMUF4TDZQZk1NdmJWbnd4c0la?= =?utf-8?B?TXZWM1lCNExaV053WERJbm5STkNrOGVvZUF6R056Wk85dnFDd2FndnorS1p3?= =?utf-8?B?VFZ6eW5pSC90bXk5U1pQV3BZaHhaZGh6dEVOWlVZNkt2RkpGOERQaVFHR2dj?= =?utf-8?B?cGUvWmxVemFzMFcwQUdtZTZ0THZJSW1BKzdzcnBzY3JRK1l6WEVDdTFQZHRn?= =?utf-8?B?UUtWM2FtdGFyV0RXUDc5ZWVpT0dsRVpUbXZuaTRNd3BzWVlJZzg1SGM5OEg3?= =?utf-8?B?THRpVEJEY2VqMEI3RUpGei9CUFN1QkROUjFxYWIxd0g3SHE5RlBHOXZmalFR?= =?utf-8?B?TTN6RHpnNGNSQjNXWnlUWkZWak1kTlJMak1CeUtpcFNzbmxKUVQ2bkliVFRE?= =?utf-8?B?aWRSeVI0cDhZcGhoTXd3Z21TNjRlQzBhTGdKU0Y5Zk5lV0M4L2RaY09FNllw?= =?utf-8?B?MGw2dVU5QnZzYUluQWtIVDNPS2ZrRStmREJhOGdYREFkVndkd1F2TTA2RE9u?= =?utf-8?B?VndGSy9ydS92ZFJpcnZhOUZiZndZTnpMbW9nQW9RcS9mZGdldWduRHpnZW5K?= =?utf-8?B?UGd1ZHdEZ0w0VjJYb3ZieFNCN0VxMjlEWFZod0dBK1g1R2JZTXh4WGdEcWdP?= =?utf-8?B?cUxqVm9mejZpcVZjMjRtTzk0NmVlQWV6a3JTM29hNnZiYXhlTlhySitFN29t?= =?utf-8?B?aFZ3Mks5OFB5ejV1bTR0djQrMGM1K1Y2NjhCenoxZURqOHh1SEVQQ2tJZk5H?= =?utf-8?Q?rrGkWfK9yrLXmCSRilG4HnSi1x1Me6w2W9eRs=3D?=
X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3640; 6:VFCADESe8hiWxCHQmGu3q8yCaNx40DwFDMgeASTkAsuFv/wHtciXU1W0aP9hPKixTOn7aUDux0Z6l3ZkKd2Fs/DGiB7IGvm1vK5CKZPegOPxzKLIyC55x7nm5FDN0QjhWaRsca0+HlUMDXD+uY6Xo4bzyTr1ABdy3v+56PWDsa16M8MGMjtMsJC043xoMVrU8I85fS+2+1DTFgZzi1RA61KldbRjPh7ocDglmGuEoAMKVajcC6MgWhKjRH9sP3emkYU7TukJEa+5ow1KkNQSH1aXx+BmXQKVTWCgXKeaq5qjZCNFyDQgAo5bpIKSg6aLBYEEovIpdAtUnZIYZ7nEYcnjAfxNyBxJODGmY5+um5g=; 5:Ej9MufNq/hLILrEd9TWilnrfCEUVGOZ2jyUOnO3cmVs4jovmWb27+VEF7wFCedyhHJyn4PaN8H4HQorHDm0lDqXDiGp6cGCLMuJrrRfizGCneeSH72wCeKlQsYDuchzbK1wQ8DEegBFbi2mTluwxxeP+a7tGNtbJWVPZ3QnZNeA=; 24:HczqwgK3LVawb3JPfj2NWBCZlV9yGDV6Hkg1B19O4i9K02zVJniP1IaWxApMuOaNu7sVqdbGxk/UtPeTzfAR0uSefTVKIbRCW2KdGBoFDeQ=; 7:JcWdHmSFm267e0BEbg2XKJ6hYSkRQjfZHUK4ZrYc3kS0NmyhTH6QdbpW6DFBWvGd8JJ+nyzlCNwQQdGjfrKJAOng198rRF9tI4TPWUOuVvPIfoJ1JT1W5fKmzrz/mIucjHtvJtMp8FtyAf3Rg9UtB+qwVc7MUwXxWFdWVrbttkk0yayyqQEIi4ygA7RtBDVjSmxYUGqk4t9dQ7q+MrWeGDjpLf8vwsdFheL2Uumuo4r/TrdXcJTWYO+KYt820MQh
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Feb 2018 21:00:47.4476 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: cde7e123-dddc-4839-45d5-08d57a3758fb
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3640
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-22_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802220263
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/qrQqTZgLZMQXyJQbKTkP55pX8EA>
Subject: Re: [yang-doctors] reference in import statement
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Feb 2018 21:01:00 -0000

On Feb 22 11:02 AM, Mahesh Jethanandani wrote:
> Benoit,
> 
> > On Feb 22, 2018, at 10:36 AM, Benoit Claise <bclaise@cisco.com> wrote:
> > 
> > Dear all,
> > 
> > I think that keeping the reference is good thing. Btw, this is not specifically a reference to where the YANG module is, but mainly where the supporting document is.
> > I think that having the reference pointing to where the extracted YANG module is (read the IANA registry, as Mahesh suggested) misses the pointer to the supporting document.
> 
> I was thinking the registry would be of this format:
> 
> ID                                                  URI                                                             Filename                                          Reference
> 
> ietf-interfaces@2014-05-08               urn:ietf:params:xml:ns:yang:ietf-interfaces      ietf-interfaces@2014-05-08.yang         RFC7223
> ietf-interfaces@2018-02-22               urn:ietf:params:xml:ns:yang:ietf-interfaces      ietf-interfaces@2018-02-22.yang <mailto:ietf-interfaces@2018-02-22.yang>         RFCXXXX
> 
> where the last column would be a hyperlink to the supporting document. No?
> 

I agree w/ Martin's comments below regarding modules being detached and
living their own life outside of the originating document.  With that
said each module will have its revision-date w/ a reference to its
supporting document.  Isn't this all you are describing in the above
registry example?

What we're talking about here is a reference on import w/o an import by
revision (Otherwise this reference should match up cleanly).  To a
module consumer, this can prove handy if they are just dealing w/ the
modules offline but this reference is detached from the possible
iterations that have come over separate supporting documents over time
thus creating this confusion of a potential soft relationship to a
specific revision.

If you aren't importing by revision then this really means the
dependency can be fulfilled by any revision you have accessible or
assume the latest.  These dependency modules will have their respective
references encoded within each so I'm not sure there is that much of a
need to have this encoded in each import statement tbh

If we leave out the reference, a consumer has to find another way to
resolve the dependency and find a module other than going to the
supporting document referenced (Which really shouldn't be the preferred
way in which folks resolve dependencies).  If we leave in the reference
and that dependency iterates over time, this can become out of date and
in need of update to all modules referencing said dependency even though
we are not importing by revision.

> > I think that this problem is maybe not that confusing. Either people find the YANG module from the RFCs and they would see RFCbis links, or people find YANG module from a repo (IANA, yangcatalog.org, github) and they would directly discover the latest revision. So adding "(at the time of this writing)" doesn't hurt but doesn't add a lot of value. Actually, this is typically the type of rules that hurts if not done consistently. Ex: 90% of YANG modules contains "(at the time of this writing)", while the complementary 10% doesn't. What should I conclude for the 10%? Something special or simply an oversight?
> > 
> > Regards, Benoit (as a contributor)
> >> Hi Martin,
> >> 
> >> 
> >>> On Feb 21, 2018, at 11:53 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
> >>> 
> >>> Hi,
> >>> 
> >>> Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
> >>>> I agree that this is grounds for confusion.
> >>>> 
> >>>> My preference would be that we NOT have a reference statement for
> >>>> import, or a comment for that matter, unless the module is doing
> >>>> import by revision. The text of the document is already required to
> >>>> have normative references to whatever the module imports.
> >>> I think this would be quite unfortunate, even though I agree that it
> >>> might be confusing to have the reference.  The problem with having
> >>> the reference only in the main body is that modules are typically
> >>> extracted from the RFCs and live their own life.  So all you have is a
> >>> list of various imported modules, and it is not obvious where to find
> >>> them.
> >> Wasn’t the idea to not have the relationship between RFC number and a YANG model because of some of these very reasons, and move to IANA maintaining a copy of all version of the YANG models? If so, would it not make sense to refer to the IANA registry, rather than point to the RFC?
> >> 
> >>> We added the "reference" statement to "import" for this very reason in
> >>> YANG 1.1.
> >>> 
> >>> So maybe the best solution is the one suggested by Juergen initially:
> >>> 
> >>>    reference "RFC 6991: Common YANG Data Types
> >>>                 (at the time of this writing)";
> >>> 
> >>> 
> >>> Or maybe we declare that in fact this is not confusing (or at least it
> >>> is not a major issue) - people are aware of the fact that documents
> >>> evolve, and that there might be a more recent version available.
> >>> 
> >>> 
> >>> /martin
> >>> 
> >>>> Cheers.
> >>>> 
> >>>>> On Feb 15, 2018, at 12:31 AM, Juergen Schoenwaelder
> >>>>> <j.schoenwaelder@jacobs-university.de> wrote:
> >>>>> 
> >>>>> Hi,
> >>>>> 
> >>>>> I have just seen this pattern
> >>>>> 
> >>>>>  import ietf-inet-types {
> >>>>>    prefix "inet";
> >>>>>    reference "RFC 6991";
> >>>>>  }
> >>>>> 
> >>>>> and I wonder how people understand this. From the way this import
> >>>>> works, any (newer) version of ietf-inet-types is OK to use to resolve
> >>>>> the import but I could see that this statement makes people believe
> >>>>> they have to use the version of ietf-inet-types contained in RFC 6991
> >>>>> (but then this should have been import by revision). I know that we
> >>>>> had a common practice to have comments before this was possible, like
> >>>>> 
> >>>>>  import ietf-inet-types {             // RFC 6991
> >>>>>    prefix "inet";
> >>>>>  }
> >>>>> 
> >>>>> but then this was a comment, now the RFC numbers becomes part of the
> >>>>> definition. Should we be concerned about this? Or should we suggest
> >>>>> to be more clear about this, e.g.:
> >>>>> 
> >>>>>  import ietf-inet-types {
> >>>>>    prefix "inet";
> >>>>>    reference "RFC 6991 (at the time of this writing)";
> >>>>>  }
> >>>>> 
> >>>>> /js
> >>>>> 
> >>>>> -- 
> >>>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >>>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> >>>>> Fax:   +49 421 200 3103         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=TSpyWMoMJVbOm9RsA5dcAUNf05lE1Hp1OHroK2hNyg4&s=veqwbYHV1hLJdgQPus6LkKH-qWMRlJYVp3UMxeQ9_r0&e=>
> >>>>> 
> >>>>> _______________________________________________
> >>>>> yang-doctors mailing list
> >>>>> yang-doctors@ietf.org
> >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=TSpyWMoMJVbOm9RsA5dcAUNf05lE1Hp1OHroK2hNyg4&s=XLWOHjJF8xVeSkfUDdIhoY6xKJcem_73Vc0dVH5WsEw&e=
> >>>> Mahesh Jethanandani
> >>>> mjethanandani@gmail.com
> >>>> 
> >>>> _______________________________________________
> >>>> yang-doctors mailing list
> >>>> yang-doctors@ietf.org
> >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=TSpyWMoMJVbOm9RsA5dcAUNf05lE1Hp1OHroK2hNyg4&s=XLWOHjJF8xVeSkfUDdIhoY6xKJcem_73Vc0dVH5WsEw&e=
> >>>> 
> >> Mahesh Jethanandani
> >> mjethanandani@gmail.com
> >> 
> >> _______________________________________________
> >> yang-doctors mailing list
> >> yang-doctors@ietf.org
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=TSpyWMoMJVbOm9RsA5dcAUNf05lE1Hp1OHroK2hNyg4&s=XLWOHjJF8xVeSkfUDdIhoY6xKJcem_73Vc0dVH5WsEw&e=
> > 
> 
> Mahesh Jethanandani
> mjethanandani@gmail.com
> 

> _______________________________________________
> yang-doctors mailing list
> yang-doctors@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=TSpyWMoMJVbOm9RsA5dcAUNf05lE1Hp1OHroK2hNyg4&s=XLWOHjJF8xVeSkfUDdIhoY6xKJcem_73Vc0dVH5WsEw&e=