From nobody Wed Mar 1 00:27:19 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02171294D5; Wed, 1 Mar 2017 00:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com 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 bJnLoccJ3-Ay; Wed, 1 Mar 2017 00:27:12 -0800 (PST) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0104.outbound.protection.outlook.com [104.47.93.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB3B01294C9; Wed, 1 Mar 2017 00:27:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZELd2U9LSufRF/fkgL6Ieuk9LkoGsB8weGVEwddCEPg=; b=MS40fbN3CSUx5k2Y3K8OAWmFfotGFfCUgxCprMXCGFhFwp0IogAYvxOxBrCNBrRvOvY+stoIQgkxSzHRQyt2X4eCwmW+AmwnHciPdIE2W3xELIdj5DfOVfZlSJ3KyNUEJC9Q4ZvxVr0tr+KOozQ+mFuJcxoHRRPBvHBgTOp8vF4= Authentication-Results: computer.org; dkim=none (message not signed) header.d=none;computer.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OSXPR01MB0648.jpnprd01.prod.outlook.com (10.167.147.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Wed, 1 Mar 2017 08:27:08 +0000 To: "Hakala, Juha E" , Stephen Farrell , The IESG References: <148832863670.29552.9014381848292739838.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <665e4263-9d21-9f70-3f26-2038e63093b5@it.aoyama.ac.jp> Date: Wed, 1 Mar 2017 17:27:06 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR01CA0102.jpnprd01.prod.outlook.com (10.167.154.20) To OSXPR01MB0648.jpnprd01.prod.outlook.com (10.167.147.14) X-MS-Office365-Filtering-Correlation-Id: 440167aa-5eca-4d41-f1d0-08d4607cc0a8 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:OSXPR01MB0648; X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0648; 3:bLhieLT5ffYxX4p6jl0X6eaa/N8MPNs1ePgnIiUBJNi3fz27MHAMV8D8NwgTfpxdGzdVNhiBbmtI8Js8g1ffnl9KySoxshUnwe+LTYUaGObOaD1n7mzQGdPZu9sTbtA2c+P2UDDFvGa2CymxlSJlhO9IpORYZIm2p/pvGUilOb0FzEgAsckFDNfRRPdk3V9w2/3p2BDoVWSlwMh9WVpyNPWaYjRCWgOd+sKdTuXO0u7FqvrOr61aiKL4p8Ffrk+j3d01HbX2vqKRbGCkP394qg==; 25:pv0EUIawIe7p4YqV+51fKCtE2M/qfw80AMDETCiXIInCWCF4o3CY6qm9H46aFcCFWXu2e9sab6I83rwaU45q8lPXrlDHSztl3F1P302wkGfqygWSa5HXP4hDVT5DB3WTFKtvzJZsgJ4WtS3nMuBbcOhWQgsjY5upzxsz0gmpPxbdlQN4hg5mzJ5uYus9BgsbPo6raNi/EDmcTL2Q+uLvx/Qy1kjmuG1fckFiSkGX+9vj46CsNaEGPzRUpMdToq+KOnxx5AU7cg9NgCrziJp20sM+CtvQdZrP0bp75eaffUDcHzswu9zqAZMZbgp9pZ8e38tiAD9S8AQUnwA5mJBz5oMJaoBPiuknQwLVuhtJuxbp3ck58fIbbSDha0V4CnE1eXzxoGqt9qvOqtCpcePclA6N38tNK44JtPaqsun9koZpRcJpycQZM1hYNvgTLcVuMWBQT5HyUO6tzYC19iDd9g== X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0648; 31:C1huZoWLygz32KTj7bj2+A0sn5gv898VSnSTa1O54xv9yKdBwXGoZKGS0Zq7bops1Qqv/RbiQBQ6DZGvML3nOobPqpukA7L6a+4QFgbw6waUwlwPFK8e0tXaWC48blclS+mjr4Spxjn9z8tsNMnVy+6/e2xovuya14lWvdnps7GIsvXTsooN8O9IHvHqMp5bZRMX34JH96TPNwfg2KeruTmB4tjvxhMKWW4zo1EIQg7WThw6PXpNpgVZVrUStPR2yH93B9sa78JxI/NTAkAgYEsUqWqhMBMGCva5lQWJIRo= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(20161123558025)(6072148); SRVR:OSXPR01MB0648; BCL:0; PCL:0; RULEID:; SRVR:OSXPR01MB0648; X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0648; 4:wN7kq93YJyduqkND2JSUIkGSjJjqbbpZGsei9PotPghJMwQSz/EURpoHQF163DdAet+1FHlPzEuOKzqJZAvYSTrJYn+ScqU1M2BfYS718C7+WHZOkhx4MUO9a4Q+UA0DISv+USIZgaBGsK0gxnJJjoVS0Z8r69LSu3YSqcn6tjeB+l98/0dbVKE03uIctA+OyblYCvjRBMw5i3w+1SVsmelMidS+kW72ZqqLOj+FlrN1Bd9vZIK3wxaupIW7YveldAIHEV2GEIipqs8fEeAM3U1H9F2KkzS0GMpjFC9R0IDKFcNIX1vBOKglPGcBvs9GsUw1IltHMLOn5S22kFCse8mvrTXucKLv/6a89imTAjC9+XWzUhv7Z9w6TAFLxMs5b24chx8x4iDlJh1iNRrSC9PPe+kWFtSvXT93yXM1FZQLjVxIgG59Zmq0qiUSYOEUdRIPJoBfV2dCKA6bEJy6+ppz59EsnZ92I4feDHDDsWlEUosr40f68zncH1kETeRDXTOk0fLeiIDVOMIVMhySL+ho3Ph92i+nolA8isTOVk2+48O1wqrnDd3Kb1beAoxcE1v11cpdTvPDcKLl/Ky7THvV19YuotgZ3Jv/4SBPTBN59MAJ+cqBxDWfM05TlqvyMR3kXfrlyL4O0ZzxMsbUuQ== X-Forefront-PRVS: 0233768B38 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(39450400003)(24454002)(6116002)(42186005)(76176999)(31430400001)(2906002)(3846002)(86362001)(81166006)(31696002)(50986999)(50466002)(74482002)(189998001)(31686004)(54356999)(4326008)(8676002)(230783001)(92566002)(7736002)(5660300001)(66066001)(65956001)(53546006)(229853002)(83506001)(47776003)(54906002)(6246003)(25786008)(38730400002)(42882006)(2950100002)(230700001)(33646002)(53936002)(305945005)(23676002)(90366009)(6486002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OSXPR01MB0648; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPU1hQUjAxTUIwNjQ4OzIzOmlUa243ai9LMlE3WXZPR2FJVHRrdTRNRGZG?= =?utf-8?B?WFRWRHo3Nkh4UDNVcnBuaFJFbmIyT25LTk9IUmdjSU1WQlN6TEdIUWJMWTM1?= =?utf-8?B?T09iUTN1UE42a1BMYWJnZVY2bDlCenBuYzZCRDZwUW03YTZ6NXZpREdwSWJZ?= =?utf-8?B?U2FwZDVyN2lPdUI4N2V4R1BYenJ0Y3VzRzVaSDhjdktDdXhUNzRnaUJ3TDky?= =?utf-8?B?Y3k3THpJK2VSNXVmbnU5MjN0bitua2ptdXE1YTgweVZoSmdQem1YOGtacUR4?= =?utf-8?B?cWNoYk5kZmZ0N0lQTzNBNEI0S3RyU0tITysvaE9jeUJ1ZGtpaEg0M1lIWTZr?= =?utf-8?B?aDRsZXVHSVl1TnA0T3QwS3pXTjJIdmllMFlaWU1acjJteWdCQjJaaHl0aVE0?= =?utf-8?B?WVNYTkJzU2N2RUFEQWgyQUM5ckVTa2lvREhqaFJ6ejc1NHlCRnJWcmttUXdk?= =?utf-8?B?b2Q2eGpiUmxQbTkydE1lVk9hY3FWalVSM2FxTml2c2NMbVNJTExqbzJqdFB5?= =?utf-8?B?Q3FUaGhKN1ZFNmFuL0JoV0FJUXl2dS9oVGNlRkVod0xQUHBkQlVNOTIraHhm?= =?utf-8?B?OXdXTnFMcUpoR292SThRSVQ4U09GR3B0QTNzTjhTN0ZRbHlMRWhlV0VYZWI2?= =?utf-8?B?eGR5VmNkUFdxM0tnV1pXeHB4UUdSZnpGS0syeDFONmwyUW44VUhXYzE4b0tQ?= =?utf-8?B?Sk1SN0t1RlZ3cW92VENhUHFYUFhUdTljS0tNTmlhRzNkNll2bTlZRldyL2pn?= =?utf-8?B?bUpvWEVsNzhLVk1zdE5pMFBUdlErS2JJdldRVk13MHlLdWhqZTFpUXFCMERD?= =?utf-8?B?RDh0RU1oOFhvOUVjeG0vNTNsZ2JBY0VkVFhnVkRZckEycG5IOG8yQTkvRHow?= =?utf-8?B?Y1VZMVVaTTNCN2hmdEtLQjlDaGx2MWk2eURGd01DcmU3Wk53a1Z5bkJLZVdG?= =?utf-8?B?K1ZpalZyOHdaRmNPZmpYcVNTV0lVbi9HYndkd1hTMEs4cXpRY3hhNVcvVmtm?= =?utf-8?B?djJHOTAyNkpzSXBDa2w3VnVLS0hmNS9pOFlNQm55UUNKVTZZaDAzV2JJc3Bw?= =?utf-8?B?dDBnS1FZRE5xVWY3cmM2K3FFanAwNHVQRVUwZlpTTnFVZ3RWRm5pRUhVN1l0?= =?utf-8?B?aTNnVFY4akRTV2dVVDdZRmNqZXM1VGdsVjYzWlNOZkkrb2lSeW80VG5JcXFN?= =?utf-8?B?VnN4V0lqRUFYZ3hrODFrM3MrV2RvWkxtVnNwUWtMQjVzT09QdkpSckRnTjEz?= =?utf-8?B?MytYZUVrY202L1o5ZUs5cXhNYllrT1pqa00xSHdnSFNNZ1BSVFVCaWJTWlVF?= =?utf-8?B?K1VlMUdlakJuWklsVy94K3RhbzJOaWQ3aWJLRDVyRUM3WkpsN3JXd3RqZkxC?= =?utf-8?B?UHBSaStuY3dDZVRvZTRIdEozcVFpREN3N09PZkJoSzB5RU9XRDVqc0YxMnRN?= =?utf-8?B?ZHZReTczZE11bldvWmFJWDFxUEY0TEtiM1AvcHc1Z1hkZVlzQkkwQ2ZtOTlD?= =?utf-8?B?U3F4RElteEdkY09mVHBmc3lkMGlMMlh1OVJhamtOZEFxRkMwM3gxcVRLRzYv?= =?utf-8?B?b3BrckV4a2dBR3ppckRBb0RiM2toVVE9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0648; 6:Y5R1yZWKCmCuLDe1Xq98sLOcDVycE3xVDe1WmvsvAbAwzb+vWr8hkbjKx/p18YBQrCqP6ngKjqBqrolMSN5UxJNHcv7oDMhi5uk+/DAwjZyLfcEQShvpRlUvPERlYEGpePDnoDymDXCYcDkE0FavCtd6BcMyHzlbG3vxxHO7pbXbOtZpW3A7G/0mtJZXXlYBNT8T4bS05L0zPMiL7b4uJvgRgDnRgNpEnFZxVGrKCmSthPqbMcfHrntmF6OfLfCY2ck6e8UN25upMR2Fzc+l/uanNNWwDh5yoS7lKN96y/5dftHA+JxOE/hsj/fPK5jPlkE+iTYcEBsoFECekkOAv/OJzdQYx5sqWGiao8QFeQcMqh2I9xLRIcxE6Tn7Z4hkCr9H7oJwN24vlY92fl7+gw==; 5:WLZbZRqTTnFbdw0wVh1bW7A0cCztqw0geCLBP8UojKIohZmSw4hK5oNZwbGEYw7LVaktM5f3xZUERqDA2vQ3/WlqpcHqbj7A26nzZtMLT3LA3JdCQ2mJIFfOUuyb8l5hDWTnzyTnyvz7fEHT3PWzZg==; 24:yn3oAogyi1ZALerx/NmhMW5WDsI7n40lGJ8sQ2tZRKoUj/V0yqpDeEXHsYSETN5gnrBgqwlzmCsJmkSegONSzOZKOaurXtRJFbvqYqYTgOE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0648; 7:7wvQNY81Biei1ROC3ohvMlfBdMXIq0LYoP0XvDsCIQUs6EuJyLcXfOLTUhADqF4HMKL4KXntntRef7jCjCpY/1WGAPX9kBJEZHDDlHDzByaAbQte+7DzqfsISozcBvBqQp9B3DCOKFZ9xdq+MdOT1UjJobeLBh1m8/3qpjyOqCighF1G3n5/A5/QQ+CjIaRa9XNLTkLZg3qEgbq+odhyB8aZYee+PsnT+Csur81m2Ht+7F5RHBZjXcmfMeiq0NXGVUh6HijxlPzaAAln7pDpmMFnWHR0iHPH/o+Pav9s8K42y76MtKR6mkw+yi/vSZEdDGtciS97Xu0tziA3YzpZ5w== X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Mar 2017 08:27:08.8559 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSXPR01MB0648 Archived-At: Cc: "urn@ietf.org" , "draft-ietf-urnbis-rfc2141bis-urn@ietf.org" , "urnbis-chairs@ietf.org" , "barryleiba@computer.org" Subject: Re: [urn] Stephen Farrell's Abstain on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 08:27:14 -0000 Hello Juha, Stephen, others, On 2017/03/01 16:16, Hakala, Juha E wrote: > Hello Stephen, > > Two comments: > > As regards this, > >> - What deployed code supports the ?+ or ?= constructs? If some arguably >> "important" code does, I'd change my abstain to a no-objection, as then >> there'd be an at least modest new feature to justify the new RFC. > > the National Library of Finland intends to revise its current URN resolver so that it supports r- and q-components. Funding for this work has been obtained from EU project EUDAT, which applies persistent identifiers to research data sets. The work will start as soon as RFC2141bis has become an Internet standard. As far as I'm aware, RFC2141bis will become a Proposed Standard, not an Internet Standard. My guess is that that's what Juha meant. It takes a lot of time to get to full Internet Standard, and interoperable implementations are definitely required. > As far as I know, there are no existing implementations of upcoming URN syntax features yet, since the URN user community has been patiently waiting for the final version of the URN syntax. Many of us are national libraries, so our time scale tends to be different from that of most other Internet organizations ;-). Once RFC2141bis has been published as an Internet standard, we still need to define the syntax for specifying resolution services and service parameters in the r-component. This should not take much time, and it can be done during the application development. > > Concerning this: > >> Normally, I'd just ballot no-objection and let that go, but given that this has >> consumed cycles for 6 years that could perhaps have been more usefully >> engaged in dealing with >> 3986 issues, I think abstaining is a better position to take on the off-chance >> that that sends some tiny form of signal. > > URNBIS needed 6 years partly because there were many 3986-based URN issues the WG had to solve before sufficient consensus was found. > > Just to give one example, URI syntax says that: > > "The fragment identifier component of a URI allows indirect > identification of a secondary resource by reference to a primary > resource and additional identifying information." > > However, f-component in the URN syntax has no role in identification, since fragment identifiers would have extended the scope of many existing standard identifier systems in an unacceptable manner. For instance, ISBNs identify books but not their component parts, so a URN:ISBN with an f-component still identifies a book as a whole, and the f-component indicates just a location within the book. This shows one of the main problems the WG was having: Not everybody uses the same vocabulary, and for many communities, vocabulary is pretty important. Regards, Martin. > The communities using URNs and other persistent identifiers (national libraries, national archives, universities, research institutions, scientific publishers etc.) need an updated URN syntax specification, not an improved version of URI syntax - which might of course be very useful for many other Web users out there. Be that as it may, I am glad that URI syntax revision is outside the scope of the URNBIS WG. > > All the best, > > Juha Hakala From nobody Wed Mar 1 07:11:23 2017 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D63912953A; Wed, 1 Mar 2017 07:11:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148838107824.7093.11755371556465062472.idtracker@ietfa.amsl.com> Date: Wed, 01 Mar 2017 07:11:18 -0800 Archived-At: Cc: urn@ietf.org, barryleiba@computer.org, draft-ietf-urnbis-rfc2141bis-urn@ietf.org, urnbis-chairs@ietf.org Subject: [urn] Alissa Cooper's Discuss on draft-ietf-urnbis-rfc2141bis-urn-21: (with DISCUSS and COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 15:11:18 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-urnbis-rfc2141bis-urn-21: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- What is the motivation behind specifying the r-component syntax at this point and then recommending against its use until further standardization is complete? Why not specify the syntax when those future standards get written? The current approach just seems like an invitation for people to start including r-components in URNs without independent implementations understanding their semantics. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- = General = I agree with Stephen that this spec seems unnecessarily long. There are a bunch of instances of repeated text in different sections that reference each other. I realize this doc was a negotiated outcome but if doing a streamlining pass is a possibility, it wouldn't hurt IMO. = Section 4.4 = "Further, all URN-aware applications MUST offer the option of displaying URNs in this canonical form to allow for direct transcription (for example by copy-and-paste techniques)." I know this was in 2141, but it seems needlessly constraining on applications and I would be surprised if every application that is aware of URNs actually does this. In general I think it would be preferable to avoid specifying normative requirements about what applications are to display, including the other requirements added to this section that were not in 2141. = Section 8 = Agree with Stephen's comment here. = Appendix C = "Truly experimental usages MAY, of course, employ the 'example' namespace [RFC6963]." It seems inappropriate to have normative language in this appendix. From nobody Wed Mar 1 15:32:22 2017 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6F3128DF6; Wed, 1 Mar 2017 15:32:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148841114111.6984.13452565574462814878.idtracker@ietfa.amsl.com> Date: Wed, 01 Mar 2017 15:32:21 -0800 Archived-At: Cc: urn@ietf.org, barryleiba@computer.org, draft-ietf-urnbis-rfc2141bis-urn@ietf.org, urnbis-chairs@ietf.org Subject: [urn] Ben Campbell's No Objection on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 23:32:21 -0000 Ben Campbell has entered the following ballot position for draft-ietf-urnbis-rfc2141bis-urn-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Alissa's comment about the "r-component" section. It seems to me that defining the syntax without the semantics risks finding out later the syntax was wrong. I agree with the general comments that this seems longer than it needs to be, and that we should remember that excess text has a cognitive cost. But it seems too late in the process to do much about that. The review tracker indicates there has been no GENART or SECDIR reviews. That's unfortunate, but I guess not a show stopper. From nobody Wed Mar 1 17:21:46 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EF31294FF; Wed, 1 Mar 2017 17:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=stpeter.im header.b=P55dv5Mu; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=BQczOML7 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 VAjMembSVO0c; Wed, 1 Mar 2017 17:21:40 -0800 (PST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3111293EB; Wed, 1 Mar 2017 17:21:40 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 763CF1A84; Wed, 1 Mar 2017 20:21:39 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 01 Mar 2017 20:21:39 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=WEaMxJxsWueyHEt qWhb098Ck5A4=; b=P55dv5MuaTw7+x/oqW0QLgTlaMq+xQ2mpwOwP7AHwxrQa+A z1knvYIs0HvDucClA1p47iE5XRRq7bhfHA4KsXWbJXRJFylCvBYeVmbiFcBuLamQ 2Mu/93tBXCp9X0eQWXIeTCjuned9pSIthCGWlOYPVp47rpnBQ/O5oYizO5Xg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=WEaMxJxsWueyHEtqWhb098Ck5A4=; b=BQczOML77Q7P8bHZQ2P7 pbqNhg+j9zj9me2tbjfeZcg4hX733oFqMVi98hFHJ7Ru1zupYndiG1okDppZ8cW8 UXp8bcQUdagXu6eMrwJzI39/8UJJ6wAolt74Q2E2LpcrR8bEyWo1oVTjlsCpTFFw KmVROPLl9Lu3j0YYgPLDEFU= X-ME-Sender: X-Sasl-enc: zNIE3YbRo+uwIg6iZ9m82g9kY+ok3azNBye2V4zJNb/s 1488417698 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 77DC27E0EE; Wed, 1 Mar 2017 20:21:38 -0500 (EST) To: Alissa Cooper , The IESG References: <148838107824.7093.11755371556465062472.idtracker@ietfa.amsl.com> From: Peter Saint-Andre Message-ID: <30519352-2add-e447-1078-ed4679b573f1@stpeter.im> Date: Wed, 1 Mar 2017 18:21:37 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <148838107824.7093.11755371556465062472.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: urn@ietf.org, Barry Leiba , draft-ietf-urnbis-rfc2141bis-urn@ietf.org, urnbis-chairs@ietf.org Subject: Re: [urn] Alissa Cooper's Discuss on draft-ietf-urnbis-rfc2141bis-urn-21: (with DISCUSS and COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 01:21:42 -0000 Hi Alissa, thanks for your input. On 3/1/17 8:11 AM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-urnbis-rfc2141bis-urn-21: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > What is the motivation behind specifying the r-component syntax at this > point and then recommending against its use until further standardization > is complete? Why not specify the syntax when those future standards get > written? The current approach just seems like an invitation for people to > start including r-components in URNs without independent implementations > understanding their semantics. My perspective is that we don't have the right people involved at the IETF (esp. many more members of the information sciences community) to undertake work on URN resolution, so it will happen elsewhere (perhaps ISO TC 46). However, this was probably our one and only chance to update the URN syntax so that others can work on URN resolution, which is why we defined the r-component syntax now. Naturally this is less than ideal, but we play the hand we're dealt. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > = General = > > I agree with Stephen that this spec seems unnecessarily long. I see a few areas where the main portion of this specification (~11500 words) is significantly longer than the combination of RFC 2141 and RFC 3406 (~7100 words): 1. Design tradeoffs; this could be moved to an appendix. 2. Terminology; given the wrangling over concepts, this was important. 3. URI syntax; more precision was needed and r-components were added. (Yes, there is some repeated text here, but it was extremely confusing to read when an earlier version tried to combine sections.) 4. URN equivalence; this now includes more examples and associated explanations, which seem helpful. 5. URI conformance; this was necessary because RFC 3986 was published since RFC 2141. 6. URN namespace registration; this was expanded because registrants often found the old text confusing. IMHO the new specification is *unnecessarily* long. > There are a > bunch of instances of repeated text in different sections that reference > each other. I realize this doc was a negotiated outcome but if doing a > streamlining pass is a possibility, it wouldn't hurt IMO. Specific suggestions are welcome, and we'll take another look as well. > = Section 4.4 = > > "Further, all URN-aware applications MUST > offer the option of displaying URNs in this canonical form to allow > for direct transcription (for example by copy-and-paste > techniques)." > > I know this was in 2141, but it seems needlessly constraining on > applications and I would be surprised if every application that is aware > of URNs actually does this. > > In general I think it would be preferable to avoid specifying normative > requirements about what applications are to display, including the other > requirements added to this section that were not in 2141. I have no objections to softening that language. > = Section 8 = > > Agree with Stephen's comment here. I'll reply separately to Stephen on this point. > = Appendix C = > > "Truly experimental usages MAY, of course, employ > the 'example' namespace [RFC6963]." > > It seems inappropriate to have normative language in this appendix. I suggest changing MAY to can. Peter From nobody Wed Mar 1 18:18:55 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5045129411; Wed, 1 Mar 2017 18:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 noXcsroxEHzA; Wed, 1 Mar 2017 18:18:44 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91615129559; Wed, 1 Mar 2017 18:18:44 -0800 (PST) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cjGKI-000AvC-RS; Wed, 01 Mar 2017 21:18:42 -0500 Date: Wed, 01 Mar 2017 21:18:36 -0500 From: John C Klensin To: Alissa Cooper , The IESG Message-ID: In-Reply-To: <148838107824.7093.11755371556465062472.idtracker@ietfa.amsl.com> References: <148838107824.7093.11755371556465062472.idtracker@ietfa.amsl.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.70 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org, urnbis-chairs@ietf.org, draft-ietf-urnbis-rfc2141bis-urn@ietf.org, barryleiba@computer.org Subject: Re: [urn] Alissa Cooper's Discuss on draft-ietf-urnbis-rfc2141bis-urn-21: (with DISCUSS and COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 02:18:50 -0000 --On Wednesday, March 1, 2017 07:11 -0800 Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-urnbis-rfc2141bis-urn-21: Discuss >.... > -------- DISCUSS: -------- > > What is the motivation behind specifying the r-component > syntax at this point and then recommending against its use > until further standardization is complete? Why not specify the > syntax when those future standards get written? The current > approach just seems like an invitation for people to start > including r-components in URNs without independent > implementations understanding their semantics. Commenting at this time on this one issue only and speaking for myself (if it is relevant, Barry or Alexey will need to comment on whether I've captured WG consensus). One of the important properties of URNs (more or less since they were first conceived of) is that they were location-independent (and, for things more like books than web pages, particular-copy-independent) abstract identifiers that would "resolve" into something more location and/or copy-dependent. While some early documents assumed that URNs would be resolved to locator-type URIs, that is not and never has been a requirement: URNs can resolve into other sorts of things or not resolve at all. When the "opportunity" came up to revise URNs, there were several different communities who wanted extended capabilities beyond those that can be supported under a strict interpretation of RFC 2141. The library community was important among them and needed the capability to both identify an object (or object-abstraction) and pass information to it. An initial view in the WG was to simple add a 3986-like query component to the URN syntax and be done with it. However, discussion on that point rapidly led to the realization that there were at least two different types of qualifying information: information that was needed to resolve or dereference the URN and information that was needed to work with, interpret, or get information from the object. That, in turn, led to the conclusion that the distinction between the r-component and q-component was necessary, even (or especially) if the WG didn't feel ready to precisely define the syntax and semantics of r-component (it may be worth noting that there was one proposal to do just that, but the WG decided to be conservative about untried solutions to a problem that was not itself, understood explicitly and in detail). It was, and is, still necessary, to define basic syntax for r-component, both to distinguish it from q-component and to address a more basic problem. That problem is that the predecessors of RFC 3986 established a generic, and quite prescriptive, syntax for URLs. RFC 3986 expanded that to cover all URIs, arguably including URNs without fully understanding the implications of that expansion. The result is that almost anything one puts in a URI either means something, is part of some specific component, or both. The WG was told that there are generic URI parsers that isolate those components according to the rules of 3986 and that the WG could not reasonably do anything that would foul up such parsers. The result is that, if one is going to separate the "part of URN processing" material that the document calls r-components from the "something the URN is expected to make available to the resolution object or equivalent if there is one" material the document calls q-components, then it is necessary to assign distinguishing syntax to both of them so it is clear how to tell them apart. That can be done without specifying parsing of the substring that the spec assigns to r-components, and, after a good deal of discussion about options, that is what the WG told the editors to do. But it cannot be done without defining that distinguishing syntax -- if that were done, if all that were defined now was the q-component (or the RFC 3986 ) then it would be impossible to add the r-component functionality later without complaints that some potential use of q-component or functionality of some real of hypothetical generic parser was being messed up. The discussion above is the answer to another question, or maybe another set of them. The URNBIS effort was driven by demands from several communities who had URNs in general use for functionality beyond that allowed by RFC 2141, even though 2141 and its predecessors discussed some of it and reserved syntax for future use. At least one of those communities, whose members include experts from several important repository libraries, have national and international standards-defining bodies of their own and a lead on the IETF in terms of thinking about persistent identifiers of at least a few hundred years. They could have simply gone off and defined and standardized their own extended URN format. Instead, they were, at least IMO, far more adult and responsible than many of the SDOs we deal with and preferred to bring requirements to us, ask us to figure out what would work best with URNs, and then participated in the process. Had the goal of the WG been simply to update and make minor adjustments to RFC 2141 and possibly to combine the registration issues of 3406 with it, the result would almost certainly have been a shorter document than the sum of the page count of those two. When the requirement because to expand functionality in ways that changed syntax while remaining compatible with prior practice and 3986 syntax and, necessarily, to address some of the subtle issues above, the explanations and the document got appreciably longer. Could it be streamlined? Yes, probably. Some of the issues you identified are the result of pulling text out (including some internal syntax for r-components and a longer discussion of f-components/fragments) over the last year. But, speaking from experience, it isn't easy -- virtually every non-trivial document change seems to stimulate someone in the WG who wants to revisit an old issue. Unless there are substantive issues, I recommend just letting things go with a plan to sort those issues out when URNs are progressed to full standard. With luck and some effort on the IESG's part, perhaps we will, by then, have a revised and clarified 3986bis to work with, something that would almost certainly make this document far simpler. On the other hand, if you object to a normative statement in the registration template because we make an arbitrary decision to put it in an appendix when 3406/3406bis was moved in, I think that template could be turned into a section of the main document (or a subsection of IANA Considerations) by applying a very small effort to the XML source. Again, my personal perspective with which some people in the WG might disagree. best, john From nobody Wed Mar 1 19:14:53 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7FD1297BD; Wed, 1 Mar 2017 19:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=stpeter.im header.b=nxBERKZ+; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=KER0SzwE 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 1O8Da0t27miK; Wed, 1 Mar 2017 19:14:51 -0800 (PST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50BE0129406; Wed, 1 Mar 2017 19:14:51 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id B15591BFC; Wed, 1 Mar 2017 22:14:50 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 01 Mar 2017 22:14:50 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=uq8HX5Me21fewNz 9Yr17JMPirTE=; b=nxBERKZ+AWC689Ym07E4Z6jOsZgfqRMDkGChSNteyYSEe2G VqLmT2/POAwDL9iuhlcNywFaBKmL7KS3LaHGGAfKc0NEYY2PgUrRNlCOUcyE0YfE VIsBnlBpcIreDxzYD/nMaZ6walIa5GAe1CVWAQcZDyQB6GueqRzH45+aadhQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=uq8HX5Me21fewNz9Yr17JMPirTE=; b=KER0SzwEao0OtwKqdUB4 wkqsRguU9k4oeY0KAgxZ6cYlhzJvFw70y2zWd2a5CuDJNVkHKht74TgDMLzCqZrt bgPNuiFyghljyTub95t6op6WE2poVIIApAH/Lp07UX+fw8UpYgOrJPJNJK9MEy/E bY0sQBnUS1XA/QCTxtGxPyg= X-ME-Sender: X-Sasl-enc: GRjVCzbaN2cuxG9mQrEUpnbcssQhr3WcDLwioNbAhNdh 1488424490 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id C211524216; Wed, 1 Mar 2017 22:14:49 -0500 (EST) To: Stephen Farrell , The IESG References: <148832863670.29552.9014381848292739838.idtracker@ietfa.amsl.com> From: Peter Saint-Andre Message-ID: <68d0ad57-9ba0-beb2-2fe4-2f036fce3e93@stpeter.im> Date: Wed, 1 Mar 2017 20:14:48 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <148832863670.29552.9014381848292739838.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: urn@ietf.org, urnbis-chairs@ietf.org, draft-ietf-urnbis-rfc2141bis-urn@ietf.org, barryleiba@computer.org Subject: Re: [urn] Stephen Farrell's Abstain on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 03:14:52 -0000 On 2/28/17 5:37 PM, Stephen Farrell wrote: > - Section 8 should I think recognise the dangers inherent > in long-term stable identifiers helping with > (re-)identification of people and/or network entities. Perhaps you could clarify what some of your concerns are here, above and beyond the use of URIs in general (after all, a URN is a URI). Reading between the lines, I imagine you might be worried that URNs within a particular URN namespace (e.g., for U.S. Social Security Numbers or the like) - once suitably resolved into one or more URLs - might enable an attacker to determine a person's physical location (e.g., via IP address) or actual identity (e.g., a pseudonym could "resolve" to a real name). Are these guesses on the mark? > While that is not the "fault" of URNs, I'd say it is worth > warning folks who may just possibly think twice before > creating new URNs with those failings. (Though I recognise > that that may call for a reference to RFC6919;-) I'm sure you meant RFC 6920. :-) Peter From nobody Wed Mar 1 23:07:45 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B0A1294A0; Wed, 1 Mar 2017 23:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 FxmsMNVlb73D; Wed, 1 Mar 2017 23:07:39 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 994591294A8; Wed, 1 Mar 2017 23:07:38 -0800 (PST) Received: from [192.168.178.20] ([93.217.107.91]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M1iGk-1cTBr80uza-00ti6C; Thu, 02 Mar 2017 08:07:20 +0100 To: John C Klensin , Alissa Cooper , The IESG References: <148838107824.7093.11755371556465062472.idtracker@ietfa.amsl.com> From: Julian Reschke Message-ID: <83e9152f-3ed1-6806-1861-45a7ee48f132@gmx.de> Date: Thu, 2 Mar 2017 08:07:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:qtp9SvdUUDv+YnMFljvlk4h4oMCxQ9dGUw2imVlib/2QFS9hw3h sJ68lrlI6fpcHkhwW2vEcxzrCBStLhFiJTmJ5SlZIwR2syhjx/OJQzC2ZgfHV4/BxPOZFU5 BRaDdTYbaCK2biu+TgUmnwbB1pxaF7ApkkLUFM8s+PjOMCiYrAy3BL7msG78BMIOnKjs1mb DtN+AiO8LC7r7yTyoiK7Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:UGwtyC49Ty0=:CXH3RnAjUz7ax6HIvAqjOq m7n/VizvuVEgEz3eKf5BDSK6KMfmc6Z3dS8itjJbAcN2v0N1EdFUEqAtmp8YtHW2Ej1OGlmtm KlGY5rwY3dvSMgkQL/FcXwBwwAQSHsa8oRwzvelVCA3aphn0w57CIlFAwtvntE0LNqI1Tiu3Q CVw0q+AWMCSKB4cU9hlAC6xgJwHbEI3jOTgKJnCGNJpsMF7SzbnK6O/MolA9cQABzeaJdw3lq HCt0isgk5DsUSDZ/XsLMXCaEVNyF3vUZmQcsEndHjs6Hhuzf4uxgQbNNnXsKduydvA9U6pIdi A4ug5vw/1359HilmlxTA6sq7CHIlG+sj7+xEkzfRNN6Qegrfh1E/nT/7ixH43iL0zbMhmafey eGYf6+bfPBecBIMD1g1cuj+AJm93LP10dvtRNFE/xvu7HSx1LeBAeHjNySvxD2W3lySFU9Erd RBJfF1hr90OD/XEsZhQmwVseCnpd4GX1+Qm4NXT/tO0g1leplkQM2VZOFU4izf4Z9pQopl6NA 1bSQQ0OVBMgEbtn4MNZEYZSvjQq6FFtX9m6YTD2VEg7HAV0kQYAOLUguyADVxzVanwwog/K+6 M9zyRUPLfiCaVQnyJhTu4StMHUp8tVzPKmCJRgNhFTkKzIfnntiDW1uOIhmGp5xxrjKa+hkVE uH2McWgFIQ8KCe6mMvmlo7Sz/mW54fqOYORTCRLOTRvDkWK7PGPZr58iQRTvndjObcwvGRILR sY9z5qGlimEuZI0maEd2uKqlAi67AYYPeLoVgX5g1WSC2hEkRqpOWZbzk65wenCSAtc8c9xjT eszc2CR Archived-At: Cc: urn@ietf.org, draft-ietf-urnbis-rfc2141bis-urn@ietf.org, urnbis-chairs@ietf.org, barryleiba@computer.org Subject: Re: [urn] Alissa Cooper's Discuss on draft-ietf-urnbis-rfc2141bis-urn-21: (with DISCUSS and COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 07:07:40 -0000 On 2017-03-02 03:18, John C Klensin wrote: > ... > That problem is that the predecessors of RFC 3986 established a > generic, and quite prescriptive, syntax for URLs. RFC 3986 > expanded that to cover all URIs, arguably including URNs without > fully understanding the implications of that expansion. The > result is that almost anything one puts in a URI either means > something, is part of some specific component, or both. > ... Actually, that happened with RFC 2396 in August 1998. > ... Best regards, Julian From nobody Thu Mar 2 00:11:13 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC5B129469; Thu, 2 Mar 2017 00:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 Nk04VjT3cTlr; Thu, 2 Mar 2017 00:11:06 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AA2F12941E; Thu, 2 Mar 2017 00:11:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A7E13BE80; Thu, 2 Mar 2017 08:11:03 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOIDbdVJrdzF; Thu, 2 Mar 2017 08:11:02 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 19089BE5C; Thu, 2 Mar 2017 08:11:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1488442262; bh=ECoJetzd6iYwYA9NjKZ1KucFuHbEFis7jao3B67I3q8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Lkyb6yL11dETV6jyM2NFDFK0OPz+TrEbtCLtas/cGUky8Caz3zD1v1/UlrIyMnKdv tE49cTZccXS+rePZoOHFej6sa2qi9PaWvt6h/9ZquEu6lzjEAE5EpYvvJiktWnjAxQ 6pK7cZwxLpELxPzDGVN+J5RnEogHcuNEcvi9laOs= To: Peter Saint-Andre , The IESG References: <148832863670.29552.9014381848292739838.idtracker@ietfa.amsl.com> <68d0ad57-9ba0-beb2-2fe4-2f036fce3e93@stpeter.im> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <836b3132-def8-0534-487a-bc78b69ee82c@cs.tcd.ie> Date: Thu, 2 Mar 2017 08:11:00 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <68d0ad57-9ba0-beb2-2fe4-2f036fce3e93@stpeter.im> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iunIeXBC18jR75kcuKNHGLqcq3sOwdEFD" Archived-At: Cc: urn@ietf.org, urnbis-chairs@ietf.org, draft-ietf-urnbis-rfc2141bis-urn@ietf.org, barryleiba@computer.org Subject: Re: [urn] Stephen Farrell's Abstain on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 08:11:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iunIeXBC18jR75kcuKNHGLqcq3sOwdEFD Content-Type: multipart/mixed; boundary="8c5iXkMnOIE1qDrBnXiLjd9qCpChTltPI"; protected-headers="v1" From: Stephen Farrell To: Peter Saint-Andre , The IESG Cc: urn@ietf.org, barryleiba@computer.org, draft-ietf-urnbis-rfc2141bis-urn@ietf.org, urnbis-chairs@ietf.org Message-ID: <836b3132-def8-0534-487a-bc78b69ee82c@cs.tcd.ie> Subject: Re: [urn] Stephen Farrell's Abstain on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT) References: <148832863670.29552.9014381848292739838.idtracker@ietfa.amsl.com> <68d0ad57-9ba0-beb2-2fe4-2f036fce3e93@stpeter.im> In-Reply-To: <68d0ad57-9ba0-beb2-2fe4-2f036fce3e93@stpeter.im> --8c5iXkMnOIE1qDrBnXiLjd9qCpChTltPI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 02/03/17 03:14, Peter Saint-Andre wrote: > On 2/28/17 5:37 PM, Stephen Farrell wrote: >=20 >> - Section 8 should I think recognise the dangers inherent >> in long-term stable identifiers helping with >> (re-)identification of people and/or network entities. >=20 > Perhaps you could clarify what some of your concerns are here, above an= d > beyond the use of URIs in general (after all, a URN is a URI). Reading > between the lines, I imagine you might be worried that URNs within a > particular URN namespace (e.g., for U.S. Social Security Numbers or the= > like) - once suitably resolved into one or more URLs - might enable an > attacker to determine a person's physical location (e.g., via IP > address) or actual identity (e.g., a pseudonym could "resolve" to a rea= l > name). Are these guesses on the mark? Yep. Perhaps things like including an IMSI or IMEI (or values easily correlated with such) in the NSS part is what it'd useful to call out. I'm not sure if there are real examples of such in existing URNs but if there were it'd be a fine thing to note that including such things imposes (often unmet) requirements for e.g. confidentiality on protocols and applications that use those URNs. If may also be useful to say that things like hashing the privacy sensitive value before inclusion in the URN don't prevent correlation and can be as "good" for re-identification as the non-hashed value. The argument to include text here is that it seems to be very tempting to include that kind of information for many folks. I'm not sure if there's a useful bit of text in RFC6973 at which you could point, but it'd be worth a look. >=20 >> While that is not the "fault" of URNs, I'd say it is worth >> warning folks who may just possibly think twice before >> creating new URNs with those failings. (Though I recognise >> that that may call for a reference to RFC6919;-) >=20 > I'm sure you meant RFC 6920. :-) Off-by-one error:-) Cheers, S. >=20 > Peter >=20 --8c5iXkMnOIE1qDrBnXiLjd9qCpChTltPI-- --iunIeXBC18jR75kcuKNHGLqcq3sOwdEFD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYt9OVAAoJEC88hzaAX42iMDgH/2tJi4yO6uk8Ws9PnU3lIT2v y3AXM6L8/MgDXUbIMfzOUvMjSNe4zlLH4IfqdI67VPAj7X3WZO7B1WYyXPPbPb6/ GgbkzqWjbRNqf/rHFHIVOohgO2fH0cX5QNQxxkVBg1WMjy6GD+itJXdilYsO1p2X 8TZHtouZmIYe+3hyS0epea/inQtnTrM1/FB7FTXuXcTomQ4mcMSvPI3kFfFiD2mF Gty2bAbQb8vlTIcKVir+T7Nos/YPGDvltoURLrfJ1wcTEHQBU+ER2ua1YhqA39d+ otZWiMFtXpClzFGXLUxvix57g3JWWlvrG+c5GsZHhc/qmm5VG6eKwC+LcWDfC14= =iUaA -----END PGP SIGNATURE----- --iunIeXBC18jR75kcuKNHGLqcq3sOwdEFD-- From nobody Thu Mar 2 04:14:44 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739C3129975; Thu, 2 Mar 2017 04:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com 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 G5fHFNsetnr6; Thu, 2 Mar 2017 04:14:39 -0800 (PST) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0093.outbound.protection.outlook.com [104.47.93.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 796B712996F; Thu, 2 Mar 2017 04:14:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ql4AL/4asmPKbRIFmj6Ae8nQmB/6U3nsP2RaVOqaiqc=; b=HBBFRxR3LnU/i2GY5o+LqTmGLIRIZJLfYaBBKDB+HFOQxDKRDyyjljOx0geJ7TPWFgS3lF6ow4NoBrPWX3ak6irvdalzG5aFPhXV57Qujt26vnlMlRl+ZIUiLkfkDPYrIPRjrmffjUK9yF2zGodqt0QOjcJ0TeoePYiHc5xPE1M= Authentication-Results: computer.org; dkim=none (message not signed) header.d=none;computer.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [192.168.1.2] (223.218.130.44) by OS2PR01MB0643.jpnprd01.prod.outlook.com (10.167.176.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Thu, 2 Mar 2017 12:13:46 +0000 To: Stephen Farrell , Peter Saint-Andre , The IESG References: <148832863670.29552.9014381848292739838.idtracker@ietfa.amsl.com> <68d0ad57-9ba0-beb2-2fe4-2f036fce3e93@stpeter.im> <836b3132-def8-0534-487a-bc78b69ee82c@cs.tcd.ie> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <9b79dcf6-fdff-8c80-e644-efaa8651cb05@it.aoyama.ac.jp> Date: Thu, 2 Mar 2017 21:13:44 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <836b3132-def8-0534-487a-bc78b69ee82c@cs.tcd.ie> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [223.218.130.44] X-ClientProxiedBy: OS2PR01CA0123.jpnprd01.prod.outlook.com (10.174.152.17) To OS2PR01MB0643.jpnprd01.prod.outlook.com (10.167.176.141) X-MS-Office365-Filtering-Correlation-Id: cfd41cc9-ff61-43b8-8a90-08d4616593a5 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:OS2PR01MB0643; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0643; 3:M9SRj5+f5uQ8oQmE67yAZqE4sdysScRbvMaae+OQql5BNHW85SIugtf4z7Lozgpsr1uutzKCrUa3tRQBYGFN96pWV1y5km4KrT89uC7QwPdHkQXwop6G3wCSKsiohQDyJfEh3JxpmdrT+qnq28uSphB3ZfJflL6aHf5Q4F052o6BL3aueAZWtkmkpXXk9q9tPBo2bII9FhHzrVTP6VOGTRbq6H25aFGaFUso3qt86ew9+eAQvlL6cIENheKFNYs0rNJDgMH2q1DA9zr5sDnIcw==; 25:PJtGKg6n5ItsblGeDN3M62AJiRkaKoMgTYnKkHxUAXN5vQheh4ymrLLRMIhvV4zYE/GNRrwGSo+ejwehkSsH7f99FBLTCObnI+KdkE5C5OW1U9oVbliGB7psORrOKzpz+Q/YBVsfXdu6QTGcQXojAbJX7Nm054rHLL2HBeZAQQdop8QbPttFxF1hQKYN19xDdPANFAtucq/wmLtbijeaOxrh8DxeLRbwNFMuTLtxmiF5jsQ0Z7Fe7hFTBVtWjJi4XO5kdP74F1mLu8PqAjyv6OdNTr+aMWtnAjITYRyLKC1CsA4QFpOMvZt9qPG/LUFD881XJjXSCWVAmvbLtX5MZnj9LDFWdULIOYbDuq3rkpElUOcjZlZqJpgNkvG/7boCzuJQtJFRJNGRDNSUFj7u3X9EqG1jkYgFKzsCtAQBuiOBS5kfzzzXaX16cwVVZDEQZdFGRyrnoZIF5pVsMgtMOA== X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0643; 31:KiLP3IU0E0vszbtu/dc5u0a8KzZV69FdZWRcdMVZ23Gtt5tngWAhatYJv9pO0BCt2lWLEKlXNhvpdYlwpWZl6E5yNDMODYO+2LNx5zDktevUJ1rXfqHrYdDdARYyNqT/T+qWSX2s0wxuC+affv4fpqa3GKMhVGyH1GMmVsZzszbR+LnFHtkVKBRGfz2gzn/yf093tWK1KTFdAobzIDl+FnYqVXOUoUW9XZlVdq1eLfrUZorm3MM2ZbBxQUYNBiLnkfRw1Ft0vq4WoLZqyd6xxg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(120809045254105)(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(20161123558025)(6072148); SRVR:OS2PR01MB0643; BCL:0; PCL:0; RULEID:; SRVR:OS2PR01MB0643; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0643; 4:lBbG/gLMzyXwGz/NraOZu76IqdsBZyMzn84Md2QqfwbDRWtj148ubk7tg3Hi2H7dwB+nsiSwWQTGKa7LnkPWE5eUX7YmJHotXrhdKsB9h7vf6JdcmxBIu4qkSSdihhMOBeDJehPNssft7muSs7hVmv8pa136qQOQhG6Cs734DPBSvXYLH7LoL6RLTteCuYy42QtBPJHgEEYH0fKOzz5bfPaPcrSJXC2V7BqUY4TELFFkJzp0Pzv7vn8RRACCL06T4rpfOURcjugAsUKfrPVSKdWkWQXz70JM6+q+naqeZQTuF1GpZRRXGR38s/GCWxUvSfmbZvivztSoQfpMukaAQv/Zm/rXStFaYefhlbdrIcgbEXLyUEuyAQPjQm1VHiibPMKRBfhv0DUBixh6j1p9NyZckgqZMzUwP+JU7R47J5FbCpqPSVMkfmYl5P9DwE6KQ4QqJhf38W0bJ68+Mo400QGUAx/+5nJaDsdMgoGwsugXWCqaBskSRzmsgiFh4qzQ2C6iH0ntZ619DUH00Czwj4z1YmZXof7VS9kHgsL/EalzOl6UYsQPChHHxesj/9wCdrppByzkdvMGnYJRkp8uobQ41V5HeiPRKNq+6oVct+Eyy8+hJYO4tqXj3G5h9rywD5Gk9CrGocqw63+Iy6nLCZaTejb7vHn5XnW8kdKwGz1ym3P6sZkEj285sglUq7QYXZPGzrvhXU4kJk2wa4ACNw== X-Forefront-PRVS: 023495660C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(39450400003)(24454002)(6306002)(229853002)(74482002)(2950100002)(6486002)(90366009)(77096006)(42882006)(33646002)(42186005)(4326008)(31686004)(53546006)(7736002)(305945005)(54906002)(92566002)(53936002)(230783001)(6246003)(230700001)(189998001)(117156001)(38730400002)(6116002)(3846002)(50466002)(66066001)(81166006)(25786008)(2906002)(5660300001)(83506001)(50986999)(76176999)(47776003)(8676002)(65806001)(86362001)(31696002)(23676002)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:OS2PR01MB0643; H:[192.168.1.2]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzJQUjAxTUIwNjQzOzIzOlpnMVlycmh2NlpqNURGdEJ5VGVsaDY3TDJU?= =?utf-8?B?blMwSzFXU3dYQWx5anltVFlpa1Jvc2NsblBFTUVCMFRCUWVFZVpSRjBKSzZF?= =?utf-8?B?UTJRYWZuaXJIL0FsZTB1dGM1OHdvd3FRTmNZczAvU3JyNSt4T1ZZUGhrQith?= =?utf-8?B?UG1iY3NodCtlaGVvZWwrMjBPRm92SWpKM2o2NW8zK2MxcDBLWjNrZmM5aTJw?= =?utf-8?B?Tm8veU9Va0t4UEpHcFRKcDVIRUtyRCtLUDkwWHJVcDhyaEhNdzBuV1VxbzE2?= =?utf-8?B?QWZmYjNyVzNRTHY1K2xHWGZmV2tOOTlDSWp5TTV6SWhXMm94QkNkelpJUjFL?= =?utf-8?B?OS9PYzVLTy90Y1NQNkp2NFl6QUpSSFdWaVZvYmVkWTcvVUFlUWJ4Mlk1S2FT?= =?utf-8?B?bzd0QnQ4eVo2YnlUcDdYZStCYnBOLyttVDV0SXZhbStNcjRwYkZ3WW9mOVZB?= =?utf-8?B?cWZYUHZlYnRQdjViQWExYkNCUmRsc3N6S3hIVm43V01td21vNWJ0MVVuRFkv?= =?utf-8?B?Q2prVER1R1ZQaDZyMUg2TVN6Y01XMTZlWXlKTy9XaU96bjRVNzRvbCtKLzJ5?= =?utf-8?B?NEJhRUoxdjV4Z0VnQi9hck44Nk9EU0VCQjFYbTdtcVMxSjg4TldhOGkvWU9Q?= =?utf-8?B?Z3krQUJjQjJTV0hnalBkUWFXNGNYcVNhN0h2NUZGRkhSZitRUk5HeWU0RXpt?= =?utf-8?B?WWNkcjA4WUVuNlYvQ3ZKNzZTNU44WlVaN0dPRmMyUmN0ekx5Qk1IZHZlWk94?= =?utf-8?B?c3JKaHFZK25IUHlieG04ZVkrYmlFNGZUL2VqN0x5WTNkU2k4alNxYjBrVmlG?= =?utf-8?B?a1FrOUZTNERHNVRTeFB5YXhWNnY3d0REMENYUElWSWJsL1JCdzJlcEZ6Z3hO?= =?utf-8?B?YUVYOWQrTlhwNENBcXQwcFR2TnFJeG5jRmRXYVJlNVZGQ0NwbW5pTlYyNEd4?= =?utf-8?B?UFNiS0VDelB0WlEyV0ZHOEsyZXZEcXovMmoxQisxdDNobTlkajFITDlGelhJ?= =?utf-8?B?TjRaT2daOGk2Z3R3TTY1d25iSUpaNEVCOEczL0Z1ZlZRajVNWU4xTDRnY3Vq?= =?utf-8?B?Nll2U01yRDZuaGZnYkMyNnQyWlFSbFpNdDlGZU9UVEFaYkdaRTFyb1VCKzJo?= =?utf-8?B?eVg5dmlTdGNvaXY5L1hvRUM2eU5OVjlxQ2JVL0RzcHNicWVQYStNbHRhREJs?= =?utf-8?B?c2wxeUJ4ZVZRcVNramRMY3Rvc3p1RThaTDFMeXZUcWRQOWFKOC96aE4ySXk5?= =?utf-8?B?WXJOQTc3QXVQRUtPODFxcVNPREhxamJ0VWE4YXVLbFV4bHo4Sjh0dDlud0Nv?= =?utf-8?B?R1ZXRExxTEpaOG1RNEdBc2kwaXI0N1cyU2VmckNiamkyOUpEdTZieXd0SFkz?= =?utf-8?B?Wko4dFR0SHZvZU4rTjkzWSt6dEpBM095d2JJZEczdTZYK0I4Q1UzUjJVYU43?= =?utf-8?B?aU92eXhrdG1uMTlobUdTT1ZRUW5HZ0NMTE92bmZnRUNaRWdyWElZV3k5VDhR?= =?utf-8?B?THBuSWh1RVBOYjRPblN1Yyt1QkN4VDErZnQ4UTB1d2FuZmk5K3FKc25HWkR3?= =?utf-8?B?Rm5URUZHVUNMSm9mWFdLc3hXVUF1bnc9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0643; 6:pJpbvq/regAruWFbnS0FJisKuWkdcBtt2vc3TSrV5OLfRsc18ccojWhnsZLlSvCZYwN5VMxoWRAICUO4ltSn/1K61bmvp+JY1c/sO7zYKdUjD51a15qE2vWNm8ERzwL5xnp/NK0YPdNFiVWZ2aZxaZUHXi4/YA0w509Da4AXJokAfHPePBamQBvcOrMLiJ6AT7qlaLRrRuOP+ceRaYzBiG2lR7MNc/gO4mNmLQGaiHHrOm5YQXXXJUUicm9muF7wdvuixdh2T18V7vuNNsyTsgvomgtjlXtttslXKHfQAcIJ4msJ2PPnpk8SWlRDW0EAULpHUlwwBPmiLh273gRMm3yvWY5sUbdph3bMwWI3mkHUikZlJmymfXSzNfsLEfKwvcLuKftWOFFnP/+9TusONA==; 5:WTb5JUB607NcgbFwcIThlkjZ639bOiN8IgpyoNI16E7ZQIxor8YlPgfL/+CCVIcGXjzPrVYGnEHLmwyeEQ6GHDnefCIYLJW1/Tvzasgtps53gUriwvtA3HME/O9Ahn4o2gXjwvtIShOntHQIw7eEfw==; 24:9HemI+Y/rvYIu+g+9hUwrJwns+/Gexl2S++RXbMmy22OEZY9Jrc7zeFQJHUi5T2pgLPxA9dPqVqHwIg01ID9yGm+/Vh5Uq7eQjKVMXbIWs4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0643; 7:5Te6yeggtcHqKJ9t7DzP0bqeIhpvIjG8YS9yIAHANWiJAmV9aqI07qk25RTNNoL/DbGgDeX4n/C4aePOt2PQgulfaNrqsRLSsoIh8OKwGft3sISiaYd1wQeflzUHxqFPWrNm2odrt8QSndIHGSy5pXH75BLJuMN1DSMQRPw/SkOxeiIXlOt2Pvxi05ZQtforayerD5delKolYgRh5baPg5y4nPIYfUhgZ+MCvi6xEviHz17i5yagrf7T/2oDx0d7F88VauKtAeMUQdk6dx9fPsN69mYrBtJe53b1vKMPPp3ArS6OLoc3KXFUJeG2DlR0D9k9cfjcqJMd3qyrPUBJ3g== X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Mar 2017 12:13:46.1054 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS2PR01MB0643 Archived-At: Cc: urn@ietf.org, draft-ietf-urnbis-rfc2141bis-urn@ietf.org, urnbis-chairs@ietf.org, barryleiba@computer.org Subject: Re: [urn] Stephen Farrell's Abstain on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 12:14:41 -0000 On 2017/03/02 17:11, Stephen Farrell wrote: > > Hiya, > > On 02/03/17 03:14, Peter Saint-Andre wrote: >> Perhaps you could clarify what some of your concerns are here, above and >> beyond the use of URIs in general (after all, a URN is a URI). Reading >> between the lines, I imagine you might be worried that URNs within a >> particular URN namespace (e.g., for U.S. Social Security Numbers or the >> like) - once suitably resolved into one or more URLs - might enable an >> attacker to determine a person's physical location (e.g., via IP >> address) or actual identity (e.g., a pseudonym could "resolve" to a real >> name). Are these guesses on the mark? > > Yep. Perhaps things like including an IMSI or IMEI (or > values easily correlated with such) in the NSS part is > what it'd useful to call out. I'm not sure if there are > real examples of such in existing URNs but if there were https://datatracker.ietf.org/doc/rfc7254/history/ Regards, Martin. > it'd be a fine thing to note that including such things > imposes (often unmet) requirements for e.g. confidentiality > on protocols and applications that use those URNs. If > may also be useful to say that things like hashing the > privacy sensitive value before inclusion in the URN don't > prevent correlation and can be as "good" for re-identification > as the non-hashed value. From nobody Thu Mar 2 04:14:58 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0C812997C; Thu, 2 Mar 2017 04:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com 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 em3nJ25zPCvV; Thu, 2 Mar 2017 04:14:43 -0800 (PST) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0105.outbound.protection.outlook.com [104.47.93.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6610129527; Thu, 2 Mar 2017 04:14:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ql4AL/4asmPKbRIFmj6Ae8nQmB/6U3nsP2RaVOqaiqc=; b=hudAP9aJuBnUbv8fCshUF7NP83qH/QYPMjwhsVmVv4h2UXdEQRjx+Vm1hwBAwKo/pC1ReoRB6rweyG/se9dMidYLEk2REKDRx3MRO9o9bSg2EqDv1FyqUyCl/33uKTUUz3JVF+zw/Q+QrB7nh/7JVjT/I4KBGq7PCCFz4pqk9ks= Authentication-Results: computer.org; dkim=none (message not signed) header.d=none;computer.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [192.168.1.2] (223.218.130.44) by OSXPR01MB0645.jpnprd01.prod.outlook.com (10.167.147.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Thu, 2 Mar 2017 12:14:39 +0000 To: Stephen Farrell , Peter Saint-Andre , The IESG References: <148832863670.29552.9014381848292739838.idtracker@ietfa.amsl.com> <68d0ad57-9ba0-beb2-2fe4-2f036fce3e93@stpeter.im> <836b3132-def8-0534-487a-bc78b69ee82c@cs.tcd.ie> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <69a994b0-2579-b1b0-7290-8d7979b0c678@it.aoyama.ac.jp> Date: Thu, 2 Mar 2017 21:14:36 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <836b3132-def8-0534-487a-bc78b69ee82c@cs.tcd.ie> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [223.218.130.44] X-ClientProxiedBy: OS2PR01CA0135.jpnprd01.prod.outlook.com (10.174.152.29) To OSXPR01MB0645.jpnprd01.prod.outlook.com (10.167.147.11) X-MS-Office365-Filtering-Correlation-Id: ef7cecd9-bdf4-4bce-85a8-08d46165b3b4 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:OSXPR01MB0645; X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0645; 3:Zpd2mYeh4bdtKwoeNU+fXcF4OJmo58DMeu3g5i0XaYdvthb7QG7zdwmnBlfX+je3nel0uuNAKUppxT9SUWQ122yWaEhKCSxVCKP8B9XnQW5nSitBHiybQXDxZL1yvriXaTgHuNe3ZrZKm7U7ytiQdhCuEyKCIJbaKdSjAkSKwx8BYMBpUNa2B638dbKPwvVKAiJ8F7speiMbM/oNhPOHedSrDt77L223v27nQ8jKTyUoXVPCHkWSgfuE1pU8FzDrWc7Pv7SMbN9uYXX+nGMyQQ==; 25:uVdf3MdTdHcg0wBSDtsxIyBHBhwGTRQMbzq4tfOc3pkNY30z3BmLzdLoLXjmg0M5VCV2Am6gClgK0bY3mHN0dtkAwJuVCq+iQXmuEsnye4hLs2B84RDtOKNLJ7kw41n75fCxcd3OqWQyn9uR1SU5lnUg0wGlSHKZ1ZkHa347YX8WD7gURR7miRTfd9CIqex4ignH7NidZhVfM53vZWazjLri81ddbeAylgMkepz4wAs/K8nFF+2PmZdmsNVXHtt9BajfjyZokCuCAi0gvN6rJnTyE5TEiEFTiPSHG0/zuA5f4AOW3ZMDRjvjOCLJSwNDOwxNVBXqPuH00+aX8XaWBjT4HV7a4t0ZH7AvHAHhlaWc92gagSYqv58AVLvC8tBHNcLcBVdU3wNwWDLuYAXtG13SHQLrxsohBJWiJ8CbiRwExwpV4tIEJANZTUe7XmEt96DKMQR4Kj0LkTsE/+CzEw== X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0645; 31:xrB7CVGWP04gnMHW3pN8t9RzbWgGRxUECHDOqE0hTJ9WP/NLZJ2670OfF4brIa4bE3rxqMXWDXOcqzFrML7NX0XAunsIIHxLRGWK6CwgSYXb+9UU+0JYnvPd3QVtGBmhzEHlZgqN6YBUbVFzqHMLmYxBbSmzqoxgigYpkO4VgeB7vbULMr6i5BAtKBpdvYgei6Q9Ded4w+fCpLE21dGTd6rBfICRuV8s/nnuCewOJRKWsqi1C5QRVdo30LhG06aD X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(120809045254105)(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:OSXPR01MB0645; BCL:0; PCL:0; RULEID:; SRVR:OSXPR01MB0645; X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0645; 4:x1pgxHu+VVjkbyNqP5aLbubynEH4wbz9fZONwo22PbKI6Z/yc+k+gYhmo652JOaGEj7AyMq5/9o6XxilMB6NTsJe5+Jk0Q9lNaTeHhDMGu4D9zlVJwN9Cmi+lpDz5g0r66ZIUCD7fnrZExr1Y3ziwU3KyfYzFEG0V9PmQGLobuI7iyeQ0HIXUSu4yedRsLTb3aiyPloFO+8U0hiuYB2ayTPcg7QfgOZ+5EtxsFGQU+VMUeCu0fQMSRsdPU6HyBvvsBHGM0YekiBWL5c+q6iDOzvm6YjWuFZMj6srmLwVcVZprjl+PoUBb609+UvVYJjkInN/qZyMOuv0a8T2qwLK+0iOzaK98KqBBSQMmEZ16ZNEwp8S8NI9WUYAPUziD+kgLLs2PL9izHGBEpu+lw/IPBaHqETa+wdJ3uCdoIQqGbCG/aDDUpDBZtSLX0TzBRnDp7wrbH78dEhun+maUpMZMdNyCuiEbNZb5fAtlX/GtG0R8douKks67FtWIkwKvEibaennS+1ibp9zuGod6joQmfrkwY0xCwozUcbrFw/FZs5Tu4qQ2BJirEIzy38gfxSOxHRBGaztj8RQT5EsnT445040KZjyVcMbQeCcEdOLLf8mcNMvWspORw9EJgj02sBfgziDvCcCH3CqQZCLdlfSjF/SBJR7qOD2INfB+f07JmOV3Bak+oOWR4j5dY+jRrASnBxrFlmmbNJV/UrKyAOjgQ== X-Forefront-PRVS: 023495660C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(39450400003)(24454002)(23676002)(90366009)(77096006)(6486002)(229853002)(6116002)(3846002)(42882006)(2950100002)(33646002)(6666003)(50466002)(54906002)(86362001)(65806001)(6306002)(230783001)(117156001)(31696002)(66066001)(83506001)(5660300001)(25786008)(7736002)(47776003)(38730400002)(2906002)(54356999)(6246003)(92566002)(74482002)(189998001)(31686004)(81166006)(42186005)(53546006)(230700001)(8676002)(4326008)(76176999)(53936002)(305945005)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:OSXPR01MB0645; H:[192.168.1.2]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPU1hQUjAxTUIwNjQ1OzIzOkpocmt2elNXblFHVzNncHJOc2dGTmd1UXVC?= =?utf-8?B?YlpuWVNnVThJSkJzZG9hTHVocmtzTDNWNE90QzE1eGttbUZnVmU4anRCakFy?= =?utf-8?B?ajRQYWFBWTVzZFBsdis5STF2cmFwZWNtd0tFMEN5RFNlT3FQa3hZZUg3Mm13?= =?utf-8?B?bDlXS3NHZTNqQjdoMWpWWE1UWlZaUjVjK3VtMGVkajJ1alp4NWljRk9zdU85?= =?utf-8?B?TktON1VocUFtaVNDdVNOc0RoUldWRkgrN1lTazRodTVtRitpWGlLR2c4bTEy?= =?utf-8?B?a3lhR3ZETytKblROaGdKRHczUHlpUWF6NzY5cXBmNGp1akF2TS8wYXVUclo1?= =?utf-8?B?NVFpWUJySFF5NU9RL1Y5NlJMV2w4NkpTSDhENWNMR0c5bUZtTHZxVVNldHdp?= =?utf-8?B?ODhVSGlUc3JHT1ZkaVI3endNWlp0dEhaY1l3RHpmSTJpLzFFL3NwZHVFVjFV?= =?utf-8?B?aUNhNWNFRXZmRFV5Qzl1TVZTdGxXeldUekQ2aWxMVFpCM3dwMTJrNnZ6WGRH?= =?utf-8?B?VmcvYjVzNFplbm5zRGJWTGZBbmU5eDRIT1hHN21YOE5RaTRHa2hJZWx2T2Mx?= =?utf-8?B?VkNuNlhsY2RyeWN4bjQrZGRhNjl5WGtQa09ZajlrTDhwdUxJSW1oY1ZVMUU2?= =?utf-8?B?VFdXeGtKSS9pZDJYUlJ5eE5DUnpRMzliRnBiNS9NaWVKR2lKbGpEMjVsM0Jq?= =?utf-8?B?UEI1MHo2dk9KaG5adUV0dUEyb0ZDRURxSk1yV2FlNDNYVmUwVVpPYm1PNlR1?= =?utf-8?B?MmM5VmxDc2Y2VnVUTW1KZW9ZcGF5MFlpWWlSV1BmK2tUemNIMTRkRUlOa1VU?= =?utf-8?B?UHZhRXdKRHlwdVVoR0s4eGhaNFhmM2x4ZnoweUFkWjFubkFGN3N4T0tKdFN0?= =?utf-8?B?bEVWOWh5cGRydEFtOU5xTnJ0VkNWaUFUb2xrY29PRmhyWkRBd2ljRHZkaTlm?= =?utf-8?B?NXMwNi9OQ2RENWdWOFhnRmQ5YVA5cUZXTGtNZ0NZaHRyWjBsYitpT3Fscjkw?= =?utf-8?B?dFQ5Y25oY1VlNXJQeEp1QTArc1h2blVhbkYzM3dzRGlnekdrcTUzbHgzTXli?= =?utf-8?B?TzFHTEZmT1NWS0Ftd1pJaFRtV3VCRDVEazdqTGdSTHptdUIwQWdvOWtlN2Z5?= =?utf-8?B?ZHNrcXNtYjUvS1JoYm16RUR0OHYyUitsd0VLMzhQT0t3QmllR2RabUNFL1lK?= =?utf-8?B?OG1qaDl4c0dENkp5WllnQTBBWGlrd0FTK2VzVExBempSNitCWEFYNTYwNWlJ?= =?utf-8?B?aWNOSmFkTU1yRmJlNmY5d1U3bnArY1l4YjZocmVlK3dIRHhPTXF3WGs3eUtz?= =?utf-8?B?UGZHblJQWVUzUzJSeE54TW42YlFJZndxektFU3ppbTJTMkZCZElBK0dOd0Nv?= =?utf-8?B?aGVOMzNIdzV5RGhTaTJ2ZW1YWmVWcEdYNS9xdjNyOE1qSW9VMTN4VUJEdVNa?= =?utf-8?B?ZUJmYi81VzE2Rkx6QVFLOUs3Z0sydG1pd25ka2J4QitsNTE1QnIwWmtoV0FE?= =?utf-8?B?SmhObjBqZHI2UzE1T05pSFVzMnFmQlZValdvTUNyLzBwaUhWcSszc2w4eEhW?= =?utf-8?Q?9tfaB97QqgC8fYDqR+c1odITuHjIYiBlWHVAUJiLwbg0=3D?= X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0645; 6:2NOHce2f4amVTGk/7yNIzb0iWfox3p3sOnHzr7Bl3BBZ/Uy55PcBBp16HzMmLMLm1mtsSq7FWOO1nHjL6s/ShkLutiGAuaFs3ucRgY1Ugrmq46eTiQ2NFgcYFBFuGkHplgJdKR90755+ErUMbqj59wCyREmoc9TCS4+HiiKnKOR73uKHeewvULyoV67EwDKMV+Ujxe9+jTs2oz8JQyDwgKWUqbRFbnSHmP/VQnMT4yRdg5yuRcM/0AI5bkKICdw2x/6PBQ8ETcfndTi3xN0BH4ku5pm6vnK5srINVgaTSAxl+ITlWElFFWGX0vd+tP0xJwgKNcEvZz+dJeDtu+voz6QNQehRa0JyV6v/9Qng+a8OxukQIf5sDCLM6tAxITLOgjrmYGVdKtjsiM2Ay1jzHQ==; 5:OsbhrEobFX5Scy6WYUOVYaW2H/Lz1tc4UePZL2MCNjz0TF4Bb5pg0OoPqU4XrOUtAAuZmdEhMrThTr1M/AHfca/sYf3KJOgRshTvh2y+VH4pdLxwcmGSe/c2Kpb1Y3U6SQcNXg/CMztmIVzbPKwLdw==; 24:DYv+ACYBanjPkAdkGTt760b0ma7PSc3n3AgIjmjExdEmnhFKGb+Zlp20UXvRi+XQtuYl8VdCjqUexC67PT09j833B6iAQDAN+Cfhorrr168= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0645; 7:l17/5FapUrpA+O1kY+X0mLsYOGx8+qztpuy+wxXjsA/MhTvjjULP7rb/wMEeNVhnO3icpDrXVAviEhqX3AUGZTF/7HFQMZzr7QmsoOGM4GEdtyi8pwzl+1HM6FPaE4a1wGHwR34k33gRciOS/Fbjqcy1bqslUkviwzXa1ZVN7HQtM8sERy24jppnCpINt3IC9Q/ziwbkyMFOuGeJDNgd8btEZpGnAtEWhGHVJzgKwW+cVAsTti3g6RW5sxQZAeSvUjdsoLqWaXCavUFYt095+8dq4crt0kCf+zzMqNxidgHq8zt9o2swDysDGAhwDhX9W44ArFLgGxZirsGiLV7Pvw== X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Mar 2017 12:14:39.8751 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSXPR01MB0645 Archived-At: Cc: urn@ietf.org, draft-ietf-urnbis-rfc2141bis-urn@ietf.org, urnbis-chairs@ietf.org, barryleiba@computer.org Subject: Re: [urn] Stephen Farrell's Abstain on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 12:14:48 -0000 On 2017/03/02 17:11, Stephen Farrell wrote: > > Hiya, > > On 02/03/17 03:14, Peter Saint-Andre wrote: >> Perhaps you could clarify what some of your concerns are here, above and >> beyond the use of URIs in general (after all, a URN is a URI). Reading >> between the lines, I imagine you might be worried that URNs within a >> particular URN namespace (e.g., for U.S. Social Security Numbers or the >> like) - once suitably resolved into one or more URLs - might enable an >> attacker to determine a person's physical location (e.g., via IP >> address) or actual identity (e.g., a pseudonym could "resolve" to a real >> name). Are these guesses on the mark? > > Yep. Perhaps things like including an IMSI or IMEI (or > values easily correlated with such) in the NSS part is > what it'd useful to call out. I'm not sure if there are > real examples of such in existing URNs but if there were https://datatracker.ietf.org/doc/rfc7254/history/ Regards, Martin. > it'd be a fine thing to note that including such things > imposes (often unmet) requirements for e.g. confidentiality > on protocols and applications that use those URNs. If > may also be useful to say that things like hashing the > privacy sensitive value before inclusion in the URN don't > prevent correlation and can be as "good" for re-identification > as the non-hashed value. From nobody Thu Mar 2 04:21:08 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85A8129976; Thu, 2 Mar 2017 04:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 Enp1hwWUBAqF; Thu, 2 Mar 2017 04:21:04 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3077C129977; Thu, 2 Mar 2017 04:21:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id ACAAABE5C; Thu, 2 Mar 2017 12:20:59 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvAnoz-exrBI; Thu, 2 Mar 2017 12:20:59 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 11EC4BE3E; Thu, 2 Mar 2017 12:20:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1488457259; bh=IgFSfSwLJdm2l7yQnL6+dsMDIoT9e4JgrGSlqQV6bw8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=yhWAlBSd5U6CRQ0Os7tfCWCCWWHMtvr7DFY0MpvcVTntP7obdChG7CGFhP7KBaZ5J OppvxM9L2wg3w2+4GnDbdSfnkcTz3Yi3J/nKUxQQOplwFcmaS4tT0U3eETYwT6rLaH L9Ls7VI3I2AE4U1k1dYAM2qt6L3NoHQjn+56D50Q= To: =?UTF-8?Q?Martin_J._D=c3=bcrst?= , Peter Saint-Andre , The IESG References: <148832863670.29552.9014381848292739838.idtracker@ietfa.amsl.com> <68d0ad57-9ba0-beb2-2fe4-2f036fce3e93@stpeter.im> <836b3132-def8-0534-487a-bc78b69ee82c@cs.tcd.ie> <69a994b0-2579-b1b0-7290-8d7979b0c678@it.aoyama.ac.jp> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Thu, 2 Mar 2017 12:20:58 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <69a994b0-2579-b1b0-7290-8d7979b0c678@it.aoyama.ac.jp> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xk6TtSuRnwmB5vrwwOHrV5eTtaG17akbb" Archived-At: Cc: urn@ietf.org, draft-ietf-urnbis-rfc2141bis-urn@ietf.org, urnbis-chairs@ietf.org, barryleiba@computer.org Subject: Re: [urn] Stephen Farrell's Abstain on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 12:21:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xk6TtSuRnwmB5vrwwOHrV5eTtaG17akbb Content-Type: multipart/mixed; boundary="DCwkuXpo4lc74o5GEgSHFj5u7VANfVDX3"; protected-headers="v1" From: Stephen Farrell To: =?UTF-8?Q?Martin_J._D=c3=bcrst?= , Peter Saint-Andre , The IESG Cc: urn@ietf.org, draft-ietf-urnbis-rfc2141bis-urn@ietf.org, urnbis-chairs@ietf.org, barryleiba@computer.org Message-ID: Subject: Re: [urn] Stephen Farrell's Abstain on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT) References: <148832863670.29552.9014381848292739838.idtracker@ietfa.amsl.com> <68d0ad57-9ba0-beb2-2fe4-2f036fce3e93@stpeter.im> <836b3132-def8-0534-487a-bc78b69ee82c@cs.tcd.ie> <69a994b0-2579-b1b0-7290-8d7979b0c678@it.aoyama.ac.jp> In-Reply-To: <69a994b0-2579-b1b0-7290-8d7979b0c678@it.aoyama.ac.jp> --DCwkuXpo4lc74o5GEgSHFj5u7VANfVDX3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/03/17 12:14, Martin J. D=C3=BCrst wrote: >=20 >=20 > On 2017/03/02 17:11, Stephen Farrell wrote: >> >> Hiya, >> >> On 02/03/17 03:14, Peter Saint-Andre wrote: >=20 >>> Perhaps you could clarify what some of your concerns are here, above = and >>> beyond the use of URIs in general (after all, a URN is a URI). Readin= g >>> between the lines, I imagine you might be worried that URNs within a >>> particular URN namespace (e.g., for U.S. Social Security Numbers or t= he >>> like) - once suitably resolved into one or more URLs - might enable a= n >>> attacker to determine a person's physical location (e.g., via IP >>> address) or actual identity (e.g., a pseudonym could "resolve" to a r= eal >>> name). Are these guesses on the mark? >> >> Yep. Perhaps things like including an IMSI or IMEI (or >> values easily correlated with such) in the NSS part is >> what it'd useful to call out. I'm not sure if there are >> real examples of such in existing URNs but if there were >=20 > https://datatracker.ietf.org/doc/rfc7254/history/ Thanks Martin - I had a feeling there was something I'd forgotten (or maybe tried to forget;-). That is a good example though. Cheers, S. >=20 > Regards, Martin. >=20 >> it'd be a fine thing to note that including such things >> imposes (often unmet) requirements for e.g. confidentiality >> on protocols and applications that use those URNs. If >> may also be useful to say that things like hashing the >> privacy sensitive value before inclusion in the URN don't >> prevent correlation and can be as "good" for re-identification >> as the non-hashed value. >=20 --DCwkuXpo4lc74o5GEgSHFj5u7VANfVDX3-- --xk6TtSuRnwmB5vrwwOHrV5eTtaG17akbb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYuA4qAAoJEC88hzaAX42i1JQH/RWv+/tya2FUd3YzWnqFFKpt ld3r3V+i7K7K2zzNajTjFn5pVNTQAeY+SCtZKI1mCW5GM+bP2EuT0NzxLyYDxDua pdMcJ1TTQe9JIMNMXhsSllGfEGeWiltSr5t6jkD+NFOjAhm3Zm2u2XCHmTZobTjz ztwme71nfAu2HCqSI9abRmTMXLObc8hsnoy4+UJg17Cf9cfthjp6BzsAExkEKljp TJhud2cXsxI0DZ569NcNNXI6QngPqkomj5zZiPhF9yCJ3MBEIWFMPHG3N7tgXypv J6MWgbEQB6ADGFs9oL0bzKVNmBkDKAoDFzAhYP4XvcdBjvHTvr5JrtvwlL9tb3U= =nivW -----END PGP SIGNATURE----- --xk6TtSuRnwmB5vrwwOHrV5eTtaG17akbb-- From nobody Thu Mar 2 05:35:51 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A99F129983; Thu, 2 Mar 2017 05:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 6gjxEJ5D0FYG; Thu, 2 Mar 2017 05:35:48 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BC8812956E; Thu, 2 Mar 2017 05:35:48 -0800 (PST) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cjQtR-000CMc-7Z; Thu, 02 Mar 2017 08:35:41 -0500 Date: Thu, 02 Mar 2017 08:35:34 -0500 From: John C Klensin To: Stephen Farrell , Peter Saint-Andre , The IESG Message-ID: In-Reply-To: <836b3132-def8-0534-487a-bc78b69ee82c@cs.tcd.ie> References: <148832863670.29552.9014381848292739838.idtracker@ietfa.amsl.com> <68d0ad57-9ba0-beb2-2fe4-2f036fce3e93@stpeter.im> <836b3132-def8-0534-487a-bc78b69ee82c@cs.tcd.ie> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.70 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org, urnbis-chairs@ietf.org, draft-ietf-urnbis-rfc2141bis-urn@ietf.org, barryleiba@computer.org Subject: Re: [urn] Stephen Farrell's Abstain on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 13:35:50 -0000 --On Thursday, March 2, 2017 08:11 +0000 Stephen Farrell wrote: >> Perhaps you could clarify what some of your concerns are >> here, above and beyond the use of URIs in general (after all, >> a URN is a URI). Reading between the lines, I imagine you >> might be worried that URNs within a particular URN namespace >> (e.g., for U.S. Social Security Numbers or the like) - once >> suitably resolved into one or more URLs - might enable an >> attacker to determine a person's physical location (e.g., via >> IP address) or actual identity (e.g., a pseudonym could >> "resolve" to a real name). Are these guesses on the mark? > > Yep. Perhaps things like including an IMSI or IMEI (or > values easily correlated with such) in the NSS part is > what it'd useful to call out. I'm not sure if there are > real examples of such in existing URNs but if there were > it'd be a fine thing to note that including such things > imposes (often unmet) requirements for e.g. confidentiality > on protocols and applications that use those URNs. If > may also be useful to say that things like hashing the > privacy sensitive value before inclusion in the URN don't > prevent correlation and can be as "good" for re-identification > as the non-hashed value. > > The argument to include text here is that it seems to be > very tempting to include that kind of information for many > folks. Stephen, It seems to me that the possibility of creating URNs that could disclose private, or personal-information-tracing, information is not an issue with URN symtax and definitions but with what namespaces are created (and NIDs registered). In principle (and as others have suggested), that issue could apply to any URI and to most other identifier types that can be used on the Internet. For URIs, even if the domain is fixed a simple search using a URI query can disclose personal location or other private information if the search parameters are then harvested and/or stored, which I understand to be a common practice. Two observations about this issue wrt the present document: (1) The NID registration approval process and associated protections. Because of the diversity of the issues involved, the intent of the WG was that Expert Review of URN NID registration proposals would never rely on a single individual but on a team with different perspectives, working together. As I reread the draft just now, while that team idea is strongly hinted at, perhaps it should be made more explicit (if you think so, text would be welcome). In any event, appointment of designated experts (individually or as a team) is under control of the IESG. It seems to me that it would be entirely appropriate for the IESG to include a privacy expert on that team if you (collectively) believe that would be helpful. Projecting a bit from other experience, a focused discussion about potential problems with a particular proposed namespace (including but not limited to privacy issues) is much more likely to lead to understanding and, where plausible, mitigation of those problems than some sort of general statement in a registration specification. The comments in the I-D about team efforts and parties working together "in a spirit of good faith and mutual understanding" are specifically intended to facilitate such discussions. Given the RFC 7254 example (and your ultimate "No objection" position on it), it is hard to imagine the new procedure working less well to prevent privacy problems than the current "IETF Consensus" arrangements. I also note that the registration template explicitly calls for consideration of security and privacy issues in namespaces and namespace registrations. That should be a considerable improvement from your standpoint over the language of RFC 3406. (2) Namespace registrations and the Protocol Police URN namespaces and the identifying NIDs are as, or more, easily used without formal IETF approval or registration than URI scheme names, media types, and many other identifiers. The Protocol Police have been quite ineffective in preventing or punishing such actions. If we create barriers to registration that seem burdensome and/or frustrate people from what they "want to do", experience indicates that the registration procedure, and perhaps syntax and other restrictions, will simply be ignored. RFC 7254 may be a good example here too: if GSMA really believed that they needed a namespace of that type and that the IETF had said "no, you can't have one because it might lead to disclosure of personal information", the only two outcomes I can imagine are that they would have gone ahead and used an unregistered URN namespace or that they would have picked out some other identifier over which the IETF does not claim authority. Neither would provide significant additional privacy. I find it very hard to imagine that they would have simply given up and conclude that no such identifier collection or namespace was needed. Rather than try to create prohibitions that we cannot enforce, the new registration procedures are intended to facilitate discussions in which our experts can use our expertise to shed light on issues and identify and mitigate problems where possible while encouraging the registrations themselves. The latter, if nothing else, reduces the odds of duplication of supposedly-unique identifiers. Avoiding such duplication is an important operational and security issue, at least IMO. best, john From nobody Thu Mar 2 06:04:53 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6EB12958D; Thu, 2 Mar 2017 06:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=F8fOFD8d; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=XsRbo8b+ 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 slMdpb9V6TWR; Thu, 2 Mar 2017 06:04:45 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 047DA1294E9; Thu, 2 Mar 2017 06:04:45 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 6AB1220B1A; Thu, 2 Mar 2017 09:04:44 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Thu, 02 Mar 2017 09:04:44 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=Ch1Pkf2HAS0WPd3 +Roy0A3eZRgo=; b=F8fOFD8dcMRduLOl/fS30N+AB5q/I2/PdfMfkV5vLU8W3ej liX0VeQ1jllo37zXOym05A3qvjNGymNJy9aAkzfyUV7bzkq4psJFIfIohXNyFF8m K/6NCtIaW2ac+NWa08p5bFnjX05ZQuvOsFPk+1lLuuGASwvZgxAbtgwpFp+4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=Ch1Pkf2HAS0WPd3+Roy0A3eZRgo=; b=XsRbo8b+JaoJyTjSfUR0 2pgj7JBXI24OwYDe2pUrT9CBKMHfjg0zEKLTO7gHKdH+P3VNG0Ec7YrcvBBt1jOt Gybbo21B+ATZHO6YISBc4efoZBvEqpKziR2FYI4esMGjHyweYuLMqc7myCRXgSgB YxjBN5HnPJOn0aYQ3Wl5FbU= X-ME-Sender: X-Sasl-enc: p4ABuCBPigo4dksnWCKDwmKfCsvvk6nPtzsbxlQJG6yR 1488463483 Received: from sjc-alcoop-8816.cisco.com (unknown [128.107.241.178]) by mail.messagingengine.com (Postfix) with ESMTPA id 18AAF243A5; Thu, 2 Mar 2017 09:04:42 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <30519352-2add-e447-1078-ed4679b573f1@stpeter.im> Date: Thu, 2 Mar 2017 09:04:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <21F132B7-EF56-4107-B1A7-06E9D2DEA3F3@cooperw.in> References: <148838107824.7093.11755371556465062472.idtracker@ietfa.amsl.com> <30519352-2add-e447-1078-ed4679b573f1@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.3124) Archived-At: Cc: urn@ietf.org, Barry Leiba , IESG , urnbis-chairs@ietf.org, draft-ietf-urnbis-rfc2141bis-urn@ietf.org Subject: Re: [urn] Alissa Cooper's Discuss on draft-ietf-urnbis-rfc2141bis-urn-21: (with DISCUSS and COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 14:04:47 -0000 > On Mar 1, 2017, at 8:21 PM, Peter Saint-Andre = wrote: >=20 > Hi Alissa, thanks for your input. >=20 > On 3/1/17 8:11 AM, Alissa Cooper wrote: >> Alissa Cooper has entered the following ballot position for >> draft-ietf-urnbis-rfc2141bis-urn-21: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> What is the motivation behind specifying the r-component syntax at = this >> point and then recommending against its use until further = standardization >> is complete? Why not specify the syntax when those future standards = get >> written? The current approach just seems like an invitation for = people to >> start including r-components in URNs without independent = implementations >> understanding their semantics. >=20 > My perspective is that we don't have the right people involved at the > IETF (esp. many more members of the information sciences community) to > undertake work on URN resolution, so it will happen elsewhere (perhaps > ISO TC 46). However, this was probably our one and only chance to = update > the URN syntax so that others can work on URN resolution, which is why > we defined the r-component syntax now. Naturally this is less than > ideal, but we play the hand we're dealt. Ok. This also seems to be part of the argument John made in his mail, = and I get it. Given the expectations that you state, however, I=E2=80=99m wondering if = the expression of the normative requirements might be more prudent if it = were phrased more along these lines: --- OLD Thus r-components SHOULD NOT be used for actual URNs until additional development and standardization work is complete, including specification of any necessary registration mechanisms. NEW Thus r-components SHOULD NOT be used for URNs before their semantics = have been standardized. --- Since the expectation is that the future standardization efforts will = take place elsewhere, it doesn=E2=80=99t seem justified to try to = constrain those efforts by normatively recommending registry mechanisms = or imposing an undefined notion of what it means for future standards to = be =E2=80=9Ccomplete.=E2=80=9D Better to be clear that all this document = is doing is specifying syntax and therefore cannot constrain how people = decide to use r-components in the future. I also was not sure what an = =E2=80=9Cactual=E2=80=9D URN is.=20 Thanks, Alissa >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> =3D General =3D >>=20 >> I agree with Stephen that this spec seems unnecessarily long. >=20 > I see a few areas where the main portion of this specification (~11500 > words) is significantly longer than the combination of RFC 2141 and = RFC > 3406 (~7100 words): >=20 > 1. Design tradeoffs; this could be moved to an appendix. >=20 > 2. Terminology; given the wrangling over concepts, this was important. >=20 > 3. URI syntax; more precision was needed and r-components were added. > (Yes, there is some repeated text here, but it was extremely confusing > to read when an earlier version tried to combine sections.) >=20 > 4. URN equivalence; this now includes more examples and associated > explanations, which seem helpful. >=20 > 5. URI conformance; this was necessary because RFC 3986 was published > since RFC 2141. >=20 > 6. URN namespace registration; this was expanded because registrants > often found the old text confusing. >=20 > IMHO the new specification is *unnecessarily* long. >=20 >> There are a >> bunch of instances of repeated text in different sections that = reference >> each other. I realize this doc was a negotiated outcome but if doing = a >> streamlining pass is a possibility, it wouldn't hurt IMO. >=20 > Specific suggestions are welcome, and we'll take another look as well. >=20 >> =3D Section 4.4 =3D >>=20 >> "Further, all URN-aware applications MUST >> offer the option of displaying URNs in this canonical form to allow >> for direct transcription (for example by copy-and-paste >> techniques)." >>=20 >> I know this was in 2141, but it seems needlessly constraining on >> applications and I would be surprised if every application that is = aware >> of URNs actually does this.=20 >>=20 >> In general I think it would be preferable to avoid specifying = normative >> requirements about what applications are to display, including the = other >> requirements added to this section that were not in 2141. >=20 > I have no objections to softening that language. >=20 >> =3D Section 8 =3D >>=20 >> Agree with Stephen's comment here. >=20 > I'll reply separately to Stephen on this point. >=20 >> =3D Appendix C =3D >>=20 >> "Truly experimental usages MAY, of course, employ >> the 'example' namespace [RFC6963]." >>=20 >> It seems inappropriate to have normative language in this appendix. >=20 > I suggest changing MAY to can. >=20 > Peter >=20 From nobody Thu Mar 2 06:11:12 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6923129549; Thu, 2 Mar 2017 06:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 ZeX58GDZtYEB; Thu, 2 Mar 2017 06:11:10 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1B7A129541; Thu, 2 Mar 2017 06:11:09 -0800 (PST) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cjRRk-000CPj-Gq; Thu, 02 Mar 2017 09:11:08 -0500 Date: Thu, 02 Mar 2017 09:11:01 -0500 From: John C Klensin To: Alissa Cooper , The IESG Message-ID: In-Reply-To: <83e9152f-3ed1-6806-1861-45a7ee48f132@gmx.de> References: <148838107824.7093.11755371556465062472.idtracker@ietfa.amsl.com> <83e9152f-3ed1-6806-1861-45a7ee48f132@gmx.de> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.70 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org, draft-ietf-urnbis-rfc2141bis-urn@ietf.org, urnbis-chairs@ietf.org, barryleiba@computer.org Subject: Re: [urn] document length and redundancy -- draft-ietf-urnbis-rfc2141bis-urn-21: (with DISCUSS and COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 14:11:11 -0000 Because there have been a few comments on the length of this document and internal redundancy, an explicit tradeoff may be worth a brief comment. While the document contains a good deal of theoretical and contextual material that the WG concluded was important, we (the editors and, I believe, the WG) also concluded that many readers who were trying to understand what was involved in registering a namespace and the procedure to be followed would read it looking for that information. There are, in essence, three separate procedures. They use reflecting different cases but depend on the same template. We decided to make each case and procedure as self-contained as possible for easy reading (or even skimming/ checking) but someone trying to work out a registration. Because the procedures are still similar, that resulted in considerable redundancy. The other alternative would have been to try to define a single procedure with lots of alternate cases and/or a web of cross-references. That would have created a much shorter document but one that would have been harder to use and that might have increased the odds of errors or omissions. Speaking personally, I hope the IESG doesn't feel a need to second-guess that set of document organization decisions. john From nobody Thu Mar 2 06:33:43 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F247129458; Thu, 2 Mar 2017 06:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 EINA95_6uojj; Thu, 2 Mar 2017 06:33:38 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78AA9129493; Thu, 2 Mar 2017 06:33:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F206FBEDB; Thu, 2 Mar 2017 14:33:35 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYBtLEUM5HFc; Thu, 2 Mar 2017 14:33:35 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 45931BED7; Thu, 2 Mar 2017 14:33:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1488465215; bh=in8QIlM64SNDUsOIdAxDht+BkdDVIL3u83x4YQGCctE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Sdl4Jn8P7QtoM/J/AR1PqHPS8ZQQTubXxq26j7KcahK9SaWHV9akZTzlCyw656mWJ bZ0dJAMEekJt5wGfp8jDfUrBWvYiWzPOkcwnN7CxU5pQQR/Cro4twYPWxfWjE9Q+NL b/31z3mFpOACaLLxBGfDStc0HAAptPpPjDw/xEpE= To: John C Klensin , Peter Saint-Andre , The IESG References: <148832863670.29552.9014381848292739838.idtracker@ietfa.amsl.com> <68d0ad57-9ba0-beb2-2fe4-2f036fce3e93@stpeter.im> <836b3132-def8-0534-487a-bc78b69ee82c@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <2cd348ce-1378-ddf7-574a-73283709999c@cs.tcd.ie> Date: Thu, 2 Mar 2017 14:33:34 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="onxjMIcpIxpXqGIUWaWBLfJL6UmIGoUsD" Archived-At: Cc: urn@ietf.org, draft-ietf-urnbis-rfc2141bis-urn@ietf.org, urnbis-chairs@ietf.org, barryleiba@computer.org Subject: Re: [urn] Stephen Farrell's Abstain on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 14:33:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --onxjMIcpIxpXqGIUWaWBLfJL6UmIGoUsD Content-Type: multipart/mixed; boundary="ExwitPgFP4XnHIkNS0hvSf4SdGLN04Tqa"; protected-headers="v1" From: Stephen Farrell To: John C Klensin , Peter Saint-Andre , The IESG Cc: urn@ietf.org, urnbis-chairs@ietf.org, draft-ietf-urnbis-rfc2141bis-urn@ietf.org, barryleiba@computer.org Message-ID: <2cd348ce-1378-ddf7-574a-73283709999c@cs.tcd.ie> Subject: Re: [urn] Stephen Farrell's Abstain on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT) References: <148832863670.29552.9014381848292739838.idtracker@ietfa.amsl.com> <68d0ad57-9ba0-beb2-2fe4-2f036fce3e93@stpeter.im> <836b3132-def8-0534-487a-bc78b69ee82c@cs.tcd.ie> In-Reply-To: --ExwitPgFP4XnHIkNS0hvSf4SdGLN04Tqa Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi John, For context (that I'm sure isn't needed for some of you, but will nonetheless spell out just in case:-), as I'm an abstain ballot, I'm not blocking this, but I am happy to chat of course. That said, yes, I think it would be good and sufficient to highlight the need for privacy to be considered as part of evaluations here, and I'd also hope that the IESG when appointing DEs keep that in mind. I also agree that there's a danger here of trying to police things too much, hence my reference to rfc6919 and it's fine concept of "MUST (but we know you won't)" that is worth avoiding in any text we add about privacy. Anyway, yes I think a bit more text that emphasises that there can be (for some folks, unexpected) privacy issues here and a pointer to the example of rfc7254 should be fine. If it helps for me to try help craft a bit of text along those lines, I'm happy to help with that, but I'm also happy for the folks involved to just do that if they so choose. Cheers, S. On 02/03/17 13:35, John C Klensin wrote: >=20 >=20 > --On Thursday, March 2, 2017 08:11 +0000 Stephen Farrell > wrote: >=20 >>> Perhaps you could clarify what some of your concerns are >>> here, above and beyond the use of URIs in general (after all, >>> a URN is a URI). Reading between the lines, I imagine you >>> might be worried that URNs within a particular URN namespace >>> (e.g., for U.S. Social Security Numbers or the like) - once >>> suitably resolved into one or more URLs - might enable an >>> attacker to determine a person's physical location (e.g., via >>> IP address) or actual identity (e.g., a pseudonym could >>> "resolve" to a real name). Are these guesses on the mark? >> >> Yep. Perhaps things like including an IMSI or IMEI (or >> values easily correlated with such) in the NSS part is >> what it'd useful to call out. I'm not sure if there are >> real examples of such in existing URNs but if there were >> it'd be a fine thing to note that including such things >> imposes (often unmet) requirements for e.g. confidentiality >> on protocols and applications that use those URNs. If >> may also be useful to say that things like hashing the >> privacy sensitive value before inclusion in the URN don't >> prevent correlation and can be as "good" for re-identification >> as the non-hashed value. >> >> The argument to include text here is that it seems to be >> very tempting to include that kind of information for many >> folks. >=20 > Stephen, >=20 > It seems to me that the possibility of creating URNs that could > disclose private, or personal-information-tracing, information > is not an issue with URN symtax and definitions but with what > namespaces are created (and NIDs registered). In principle (and > as others have suggested), that issue could apply to any URI and > to most other identifier types that can be used on the Internet. > For URIs, even if the domain is fixed a simple search using a > URI query can disclose personal location or other private > information if the search parameters are then harvested and/or > stored, which I understand to be a common practice. >=20 > Two observations about this issue wrt the present document: >=20 > (1) The NID registration approval process and associated > protections. >=20 > Because of the diversity of the issues involved, the intent of > the WG was that Expert Review of URN NID registration proposals > would never rely on a single individual but on a team with > different perspectives, working together. As I reread the draft > just now, while that team idea is strongly hinted at, perhaps it > should be made more explicit (if you think so, text would be > welcome). In any event, appointment of designated experts > (individually or as a team) is under control of the IESG. It > seems to me that it would be entirely appropriate for the IESG > to include a privacy expert on that team if you (collectively) > believe that would be helpful. =20 >=20 > Projecting a bit from other experience, a focused discussion > about potential problems with a particular proposed namespace > (including but not limited to privacy issues) is much more > likely to lead to understanding and, where plausible, mitigation > of those problems than some sort of general statement in a > registration specification. The comments in the I-D about team > efforts and parties working together "in a spirit of good faith > and mutual understanding" are specifically intended to > facilitate such discussions. Given the RFC 7254 example (and > your ultimate "No objection" position on it), it is hard to > imagine the new procedure working less well to prevent privacy > problems than the current "IETF Consensus" arrangements. >=20 > I also note that the registration template explicitly calls for > consideration of security and privacy issues in namespaces and > namespace registrations. That should be a considerable > improvement from your standpoint over the language of RFC 3406. >=20 >=20 > (2) Namespace registrations and the Protocol Police >=20 > URN namespaces and the identifying NIDs are as, or more, easily > used without formal IETF approval or registration than URI > scheme names, media types, and many other identifiers. The > Protocol Police have been quite ineffective in preventing or > punishing such actions. If we create barriers to registration > that seem burdensome and/or frustrate people from what they > "want to do", experience indicates that the registration > procedure, and perhaps syntax and other restrictions, will > simply be ignored. =20 >=20 > RFC 7254 may be a good example here too: if GSMA really believed > that they needed a namespace of that type and that the IETF had > said "no, you can't have one because it might lead to disclosure > of personal information", the only two outcomes I can imagine > are that they would have gone ahead and used an unregistered URN > namespace or that they would have picked out some other > identifier over which the IETF does not claim authority. > Neither would provide significant additional privacy. I find it > very hard to imagine that they would have simply given up and > conclude that no such identifier collection or namespace was > needed. >=20 > Rather than try to create prohibitions that we cannot enforce, > the new registration procedures are intended to facilitate > discussions in which our experts can use our expertise to shed > light on issues and identify and mitigate problems where > possible while encouraging the registrations themselves. The > latter, if nothing else, reduces the odds of duplication of > supposedly-unique identifiers. Avoiding such duplication is an > important operational and security issue, at least IMO. >=20 > best, > john >=20 >=20 >=20 --ExwitPgFP4XnHIkNS0hvSf4SdGLN04Tqa-- --onxjMIcpIxpXqGIUWaWBLfJL6UmIGoUsD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYuC0+AAoJEC88hzaAX42iod0H/3CrMujMIv1cMJFflDZYaOWf Q5UpdgI/egGF/CTlOP/pxCR8YxOeiKmSC96mWU2DuyV/hTsAaHrZtRtHTBW/Y+Zz ECFC1MkKrgJ82cILrvwRbcpC1u08csRxcoZjEsFQ9pyS1o2bUBQRJFDuy7YHalns cCRkCRKp1lb75XLaBznEaCTanlRluhhfGpxui3HsAOthaqW09Ed1W/sbiyZ8SFkK K4ecudFEjvTyaweX0ps7uPwIZWCW0TMurw0o/lvsmJvUJxzL8rbRzxAVCmetaTKL bUi26pqLFoYwhwTZatIDNJTcVSbsN3jn0YimBTM+IXzPhWjP7EiW17jv3It/IkU= =uinw -----END PGP SIGNATURE----- --onxjMIcpIxpXqGIUWaWBLfJL6UmIGoUsD-- From nobody Thu Mar 2 07:30:33 2017 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4D91294F2; Thu, 2 Mar 2017 07:30:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alissa Cooper To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148846862902.19483.15030465452736704538.idtracker@ietfa.amsl.com> Date: Thu, 02 Mar 2017 07:30:29 -0800 Archived-At: Cc: urn@ietf.org, barryleiba@computer.org, draft-ietf-urnbis-rfc2141bis-urn@ietf.org, urnbis-chairs@ietf.org Subject: [urn] Alissa Cooper's No Objection on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 15:30:29 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-urnbis-rfc2141bis-urn-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- = General = I agree with Stephen that this spec seems unnecessarily long. There are a bunch of instances of repeated text in different sections that reference each other. I realize this doc was a negotiated outcome but if doing a streamlining pass is a possibility, it wouldn't hurt IMO. = Section 2.3.1 = Given that r-components are expected to be standardized elsewhere, I’m wondering if the expression of the normative requirements might be more prudent if it were phrased more along these lines: --- OLD Thus r-components SHOULD NOT be used for actual URNs until additional development and standardization work is complete, including specification of any necessary registration mechanisms. NEW Thus r-components SHOULD NOT be used for URNs before their semantics have been standardized. --- Since the expectation is that the future standardization efforts will take place elsewhere, it doesn’t seem justified to try to constrain those efforts by normatively recommending registry mechanisms or imposing an undefined notion of what it means for future standards to be “complete.” Better to be clear that all this document is doing is specifying syntax and therefore cannot constrain how people decide to use r-components in the future. I also was not sure what an “actual” URN is. = Section 4.4 = "Further, all URN-aware applications MUST offer the option of displaying URNs in this canonical form to allow for direct transcription (for example by copy-and-paste techniques)." I know this was in 2141, but it seems needlessly constraining on applications and I would be surprised if every application that is aware of URNs actually does this. In general I think it would be preferable to avoid specifying normative requirements about what applications are to display, including the other requirements added to this section that were not in 2141. = Section 8 = Agree with Stephen's comment here. = Appendix C = "Truly experimental usages MAY, of course, employ the 'example' namespace [RFC6963]." It seems inappropriate to have normative language in this appendix. From nobody Thu Mar 2 07:45:47 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46131294B3; Thu, 2 Mar 2017 07:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 m6nnvHj26hsY; Thu, 2 Mar 2017 07:45:43 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8E0D129476; Thu, 2 Mar 2017 07:45:43 -0800 (PST) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cjSvD-000CYg-W5; Thu, 02 Mar 2017 10:45:39 -0500 Date: Thu, 02 Mar 2017 10:45:32 -0500 From: John C Klensin To: Stephen Farrell Message-ID: <9499477E8333E7F4AB7E0101@PSB> In-Reply-To: <2cd348ce-1378-ddf7-574a-73283709999c@cs.tcd.ie> References: <148832863670.29552.9014381848292739838.idtracker@ietfa.amsl.com> <68d0ad57-9ba0-beb2-2fe4-2f036fce3e93@stpeter.im> <836b3132-def8-0534-487a-bc78b69ee82c@cs.tcd.ie> <2cd348ce-1378-ddf7-574a-73283709999c@cs.tcd.ie> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.70 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: urn@ietf.org, The IESG , urnbis-chairs@ietf.org, barryleiba@computer.org, draft-ietf-urnbis-rfc2141bis-urn@ietf.org Subject: Re: [urn] Stephen Farrell's Abstain on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 15:45:46 -0000 Stephen, If you want to craft some text and tell us where to put it, I'd appreciate it. Noting that there is already a template requirement for security and privacy information and the DE team is charged with reviewing those templates for completeness, I think it is important that such text be as extensive as needed but no longer and, in particular, that it not add to the redundancy that you and Alissa have complained about any more than necessary. thanks, john --On Thursday, March 2, 2017 14:33 +0000 Stephen Farrell wrote: > > Hi John, > > For context (that I'm sure isn't needed for some of you, > but will nonetheless spell out just in case:-), as I'm > an abstain ballot, I'm not blocking this, but I am happy > to chat of course. > > That said, yes, I think it would be good and sufficient > to highlight the need for privacy to be considered as > part of evaluations here, and I'd also hope that the IESG > when appointing DEs keep that in mind. I also agree that > there's a danger here of trying to police things too > much, hence my reference to rfc6919 and it's fine concept > of "MUST (but we know you won't)" that is worth avoiding > in any text we add about privacy. > > Anyway, yes I think a bit more text that emphasises that > there can be (for some folks, unexpected) privacy issues > here and a pointer to the example of rfc7254 should be > fine. > > If it helps for me to try help craft a bit of text along > those lines, I'm happy to help with that, but I'm also > happy for the folks involved to just do that if they so > choose. > > Cheers, > S. > > On 02/03/17 13:35, John C Klensin wrote: >> >> >> --On Thursday, March 2, 2017 08:11 +0000 Stephen Farrell >> wrote: >> >>>> Perhaps you could clarify what some of your concerns are >>>> here, above and beyond the use of URIs in general (after >>>> all, a URN is a URI). Reading between the lines, I imagine >>>> you might be worried that URNs within a particular URN >>>> namespace (e.g., for U.S. Social Security Numbers or the >>>> like) - once suitably resolved into one or more URLs - >>>> might enable an attacker to determine a person's physical >>>> location (e.g., via IP address) or actual identity (e.g., a >>>> pseudonym could "resolve" to a real name). Are these >>>> guesses on the mark? >>> >>> Yep. Perhaps things like including an IMSI or IMEI (or >>> values easily correlated with such) in the NSS part is >>> what it'd useful to call out. I'm not sure if there are >>> real examples of such in existing URNs but if there were >>> it'd be a fine thing to note that including such things >>> imposes (often unmet) requirements for e.g. confidentiality >>> on protocols and applications that use those URNs. If >>> may also be useful to say that things like hashing the >>> privacy sensitive value before inclusion in the URN don't >>> prevent correlation and can be as "good" for >>> re-identification as the non-hashed value. >>> >>> The argument to include text here is that it seems to be >>> very tempting to include that kind of information for many >>> folks. >> >> Stephen, >> >> It seems to me that the possibility of creating URNs that >> could disclose private, or personal-information-tracing, >> information is not an issue with URN symtax and definitions >> but with what namespaces are created (and NIDs registered). >> In principle (and as others have suggested), that issue could >> apply to any URI and to most other identifier types that can >> be used on the Internet. For URIs, even if the domain is >> fixed a simple search using a URI query can disclose personal >> location or other private information if the search >> parameters are then harvested and/or stored, which I >> understand to be a common practice. >> >> Two observations about this issue wrt the present document: >> >> (1) The NID registration approval process and associated >> protections. >> >> Because of the diversity of the issues involved, the intent of >> the WG was that Expert Review of URN NID registration >> proposals would never rely on a single individual but on a >> team with different perspectives, working together. As I >> reread the draft just now, while that team idea is strongly >> hinted at, perhaps it should be made more explicit (if you >> think so, text would be welcome). In any event, appointment >> of designated experts (individually or as a team) is under >> control of the IESG. It seems to me that it would be >> entirely appropriate for the IESG to include a privacy expert >> on that team if you (collectively) believe that would be >> helpful. >> >> Projecting a bit from other experience, a focused discussion >> about potential problems with a particular proposed namespace >> (including but not limited to privacy issues) is much more >> likely to lead to understanding and, where plausible, >> mitigation of those problems than some sort of general >> statement in a registration specification. The comments in >> the I-D about team efforts and parties working together "in a >> spirit of good faith and mutual understanding" are >> specifically intended to facilitate such discussions. Given >> the RFC 7254 example (and your ultimate "No objection" >> position on it), it is hard to imagine the new procedure >> working less well to prevent privacy problems than the >> current "IETF Consensus" arrangements. >> >> I also note that the registration template explicitly calls >> for consideration of security and privacy issues in >> namespaces and namespace registrations. That should be a >> considerable improvement from your standpoint over the >> language of RFC 3406. >> >> >> (2) Namespace registrations and the Protocol Police >> >> URN namespaces and the identifying NIDs are as, or more, >> easily used without formal IETF approval or registration than >> URI scheme names, media types, and many other identifiers. >> The Protocol Police have been quite ineffective in preventing >> or punishing such actions. If we create barriers to >> registration that seem burdensome and/or frustrate people >> from what they "want to do", experience indicates that the >> registration procedure, and perhaps syntax and other >> restrictions, will simply be ignored. >> >> RFC 7254 may be a good example here too: if GSMA really >> believed that they needed a namespace of that type and that >> the IETF had said "no, you can't have one because it might >> lead to disclosure of personal information", the only two >> outcomes I can imagine are that they would have gone ahead >> and used an unregistered URN namespace or that they would >> have picked out some other identifier over which the IETF >> does not claim authority. Neither would provide significant >> additional privacy. I find it very hard to imagine that they >> would have simply given up and conclude that no such >> identifier collection or namespace was needed. >> >> Rather than try to create prohibitions that we cannot enforce, >> the new registration procedures are intended to facilitate >> discussions in which our experts can use our expertise to shed >> light on issues and identify and mitigate problems where >> possible while encouraging the registrations themselves. The >> latter, if nothing else, reduces the odds of duplication of >> supposedly-unique identifiers. Avoiding such duplication is >> an important operational and security issue, at least IMO. >> >> best, >> john >> >> >> > From nobody Thu Mar 2 07:58:35 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6BE129439; Thu, 2 Mar 2017 07:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=stpeter.im header.b=0elPr/tW; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=aq+JAM4M 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 z3fcZun6_2Zb; Thu, 2 Mar 2017 07:58:28 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 765261289B0; Thu, 2 Mar 2017 07:58:28 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id D244320A9A; Thu, 2 Mar 2017 10:58:27 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 02 Mar 2017 10:58:27 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=HyDwhiVmyTEoAAS MfFfZ31G/Rzo=; b=0elPr/tWBvki2PH33uV0ekhOtGcc8qRZIZ0zWwqX+OcdAK/ Fp25zqTbHv9iSYoRzdvV4pf8BbZVQjPmyBTUp1er5lquG1PR+5e+QB/4SJp7C2yK MA0tx9855RMeGrbsVOQsiILBOm6ZWm+vume/sZsUAX6KrIWati/EeLI2GjBM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=HyDwhiVmyTEoAASMfFfZ31G/Rzo=; b=aq+JAM4M8cHhavT1iOaT 4Dx6+0qQm/64H+vkTZR5PsmtuiOY6XbpNDdNSqgpxW2s/IrPTtKdR4EKxpBxQUDi uB2HjIDlcxiQ4icrYJ9n+5r5O/ceYWZ3bIIkxIca29u/c55LsEXsQr2dVkJ+o/gh zsgrSDAAbsghJp/gxiu/piM= X-ME-Sender: X-Sasl-enc: ELUP4hqbFDg/gVuKI4p8cZwHngam2+6WvuaAsdww5VKq 1488470307 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id C618224066; Thu, 2 Mar 2017 10:58:26 -0500 (EST) To: John C Klensin , Stephen Farrell References: <148832863670.29552.9014381848292739838.idtracker@ietfa.amsl.com> <68d0ad57-9ba0-beb2-2fe4-2f036fce3e93@stpeter.im> <836b3132-def8-0534-487a-bc78b69ee82c@cs.tcd.ie> <2cd348ce-1378-ddf7-574a-73283709999c@cs.tcd.ie> <9499477E8333E7F4AB7E0101@PSB> From: Peter Saint-Andre Message-ID: <66ec90ec-6c58-33b6-b233-cb11961da082@stpeter.im> Date: Thu, 2 Mar 2017 08:58:26 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <9499477E8333E7F4AB7E0101@PSB> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: urn@ietf.org, barryleiba@computer.org, The IESG , urnbis-chairs@ietf.org, draft-ietf-urnbis-rfc2141bis-urn@ietf.org Subject: Re: [urn] Stephen Farrell's Abstain on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 15:58:31 -0000 If Stephen can propose text, that's great. I'm happy to do so for Stephen's review, but I probably won't have time until tomorrow. On 3/2/17 8:45 AM, John C Klensin wrote: > Stephen, > > If you want to craft some text and tell us where to put it, I'd > appreciate it. Noting that there is already a template > requirement for security and privacy information and the DE team > is charged with reviewing those templates for completeness, I > think it is important that such text be as extensive as needed > but no longer and, in particular, that it not add to the > redundancy that you and Alissa have complained about any more > than necessary. > > thanks, > john > > > --On Thursday, March 2, 2017 14:33 +0000 Stephen Farrell > wrote: > >> >> Hi John, >> >> For context (that I'm sure isn't needed for some of you, >> but will nonetheless spell out just in case:-), as I'm >> an abstain ballot, I'm not blocking this, but I am happy >> to chat of course. >> >> That said, yes, I think it would be good and sufficient >> to highlight the need for privacy to be considered as >> part of evaluations here, and I'd also hope that the IESG >> when appointing DEs keep that in mind. I also agree that >> there's a danger here of trying to police things too >> much, hence my reference to rfc6919 and it's fine concept >> of "MUST (but we know you won't)" that is worth avoiding >> in any text we add about privacy. >> >> Anyway, yes I think a bit more text that emphasises that >> there can be (for some folks, unexpected) privacy issues >> here and a pointer to the example of rfc7254 should be >> fine. >> >> If it helps for me to try help craft a bit of text along >> those lines, I'm happy to help with that, but I'm also >> happy for the folks involved to just do that if they so >> choose. >> >> Cheers, >> S. >> >> On 02/03/17 13:35, John C Klensin wrote: >>> >>> >>> --On Thursday, March 2, 2017 08:11 +0000 Stephen Farrell >>> wrote: >>> >>>>> Perhaps you could clarify what some of your concerns are >>>>> here, above and beyond the use of URIs in general (after >>>>> all, a URN is a URI). Reading between the lines, I imagine >>>>> you might be worried that URNs within a particular URN >>>>> namespace (e.g., for U.S. Social Security Numbers or the >>>>> like) - once suitably resolved into one or more URLs - >>>>> might enable an attacker to determine a person's physical >>>>> location (e.g., via IP address) or actual identity (e.g., a >>>>> pseudonym could "resolve" to a real name). Are these >>>>> guesses on the mark? >>>> >>>> Yep. Perhaps things like including an IMSI or IMEI (or >>>> values easily correlated with such) in the NSS part is >>>> what it'd useful to call out. I'm not sure if there are >>>> real examples of such in existing URNs but if there were >>>> it'd be a fine thing to note that including such things >>>> imposes (often unmet) requirements for e.g. confidentiality >>>> on protocols and applications that use those URNs. If >>>> may also be useful to say that things like hashing the >>>> privacy sensitive value before inclusion in the URN don't >>>> prevent correlation and can be as "good" for >>>> re-identification as the non-hashed value. >>>> >>>> The argument to include text here is that it seems to be >>>> very tempting to include that kind of information for many >>>> folks. >>> >>> Stephen, >>> >>> It seems to me that the possibility of creating URNs that >>> could disclose private, or personal-information-tracing, >>> information is not an issue with URN symtax and definitions >>> but with what namespaces are created (and NIDs registered). >>> In principle (and as others have suggested), that issue could >>> apply to any URI and to most other identifier types that can >>> be used on the Internet. For URIs, even if the domain is >>> fixed a simple search using a URI query can disclose personal >>> location or other private information if the search >>> parameters are then harvested and/or stored, which I >>> understand to be a common practice. >>> >>> Two observations about this issue wrt the present document: >>> >>> (1) The NID registration approval process and associated >>> protections. >>> >>> Because of the diversity of the issues involved, the intent of >>> the WG was that Expert Review of URN NID registration >>> proposals would never rely on a single individual but on a >>> team with different perspectives, working together. As I >>> reread the draft just now, while that team idea is strongly >>> hinted at, perhaps it should be made more explicit (if you >>> think so, text would be welcome). In any event, appointment >>> of designated experts (individually or as a team) is under >>> control of the IESG. It seems to me that it would be >>> entirely appropriate for the IESG to include a privacy expert >>> on that team if you (collectively) believe that would be >>> helpful. >>> >>> Projecting a bit from other experience, a focused discussion >>> about potential problems with a particular proposed namespace >>> (including but not limited to privacy issues) is much more >>> likely to lead to understanding and, where plausible, >>> mitigation of those problems than some sort of general >>> statement in a registration specification. The comments in >>> the I-D about team efforts and parties working together "in a >>> spirit of good faith and mutual understanding" are >>> specifically intended to facilitate such discussions. Given >>> the RFC 7254 example (and your ultimate "No objection" >>> position on it), it is hard to imagine the new procedure >>> working less well to prevent privacy problems than the >>> current "IETF Consensus" arrangements. >>> >>> I also note that the registration template explicitly calls >>> for consideration of security and privacy issues in >>> namespaces and namespace registrations. That should be a >>> considerable improvement from your standpoint over the >>> language of RFC 3406. >>> >>> >>> (2) Namespace registrations and the Protocol Police >>> >>> URN namespaces and the identifying NIDs are as, or more, >>> easily used without formal IETF approval or registration than >>> URI scheme names, media types, and many other identifiers. >>> The Protocol Police have been quite ineffective in preventing >>> or punishing such actions. If we create barriers to >>> registration that seem burdensome and/or frustrate people >>> from what they "want to do", experience indicates that the >>> registration procedure, and perhaps syntax and other >>> restrictions, will simply be ignored. >>> >>> RFC 7254 may be a good example here too: if GSMA really >>> believed that they needed a namespace of that type and that >>> the IETF had said "no, you can't have one because it might >>> lead to disclosure of personal information", the only two >>> outcomes I can imagine are that they would have gone ahead >>> and used an unregistered URN namespace or that they would >>> have picked out some other identifier over which the IETF >>> does not claim authority. Neither would provide significant >>> additional privacy. I find it very hard to imagine that they >>> would have simply given up and conclude that no such >>> identifier collection or namespace was needed. >>> >>> Rather than try to create prohibitions that we cannot enforce, >>> the new registration procedures are intended to facilitate >>> discussions in which our experts can use our expertise to shed >>> light on issues and identify and mitigate problems where >>> possible while encouraging the registrations themselves. The >>> latter, if nothing else, reduces the odds of duplication of >>> supposedly-unique identifiers. Avoiding such duplication is >>> an important operational and security issue, at least IMO. >>> >>> best, >>> john >>> >>> >>> >> > > > > From nobody Thu Mar 2 08:18:37 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3A0129536; Thu, 2 Mar 2017 08:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 Ue9WCDS0_9zm; Thu, 2 Mar 2017 08:18:35 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E51E129517; Thu, 2 Mar 2017 08:18:35 -0800 (PST) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cjTR3-000CbV-DN; Thu, 02 Mar 2017 11:18:33 -0500 Date: Thu, 02 Mar 2017 11:18:26 -0500 From: John C Klensin To: Peter Saint-Andre , urn@ietf.org Message-ID: In-Reply-To: <21F132B7-EF56-4107-B1A7-06E9D2DEA3F3@cooperw.in> References: <148838107824.7093.11755371556465062472.idtracker@ietfa.amsl.com> <30519352-2add-e447-1078-ed4679b573f1@stpeter.im> <21F132B7-EF56-4107-B1A7-06E9D2DEA3F3@cooperw.in> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.70 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: draft-ietf-urnbis-rfc2141bis-urn@ietf.org, Alissa Cooper , urnbis-chairs@ietf.org, Alexey Melnikov , Barry Leiba , Stephen Farrell Subject: Re: [urn] Alissa Cooper's Discuss on draft-ietf-urnbis-rfc2141bis-urn-21: (with DISCUSS and COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 16:18:36 -0000 Hi (IESG, other than Alexey, Alissa, and Stephen, not copied to save them clutter), The IESG just tentatively signed off on this draft, pending a revised document (don't start celebrating yet). That means only editorial corrections and changes already agreed. I'd like to get that draft posted within the next 24 hours so that the IESG can issue an approval notice and we can get this behind us (modulo RFC Editor changes and AUTH48). As far as I know, the following changes are in the queue: (1) Alissa's suggestion about r-component below. The more complex text was trying to make a slightly different and stronger point, but I don't think it is worth fighting about and her text is definitely simpler and shorter. (2) Stephen's pending text on privacy. I expect this to be minimal and clarifying. (3) Review of Alissa's other suggestions. Absent strong (and immediate) comments/objections from the WG, I expect to resolve them as follows (for more details on some of these, see her DISCUSS and NO OBJECTION postings to the list): (3.1) = Section 4.4 = > "Further, all URN-aware applications MUST offer the > option of displaying URNs in this canonical form to > allow for direct transcription (for example by > copy-and-paste techniques)." > I know this was in 2141, but it seems needlessly constraining > > on applications and I would be surprised if every > application that is aware of URNs actually does this. >... I am very reluctant to tamper with this at this point -- it would, IMO, need WG discussion. In addition, questions about what "every application" does and does not do seem as or more appropriate when we come back to this for full standard. 3.2 = Appendix C = > "Truly experimental usages MAY, of course, employ > the 'example' namespace [RFC6963]." > > It seems inappropriate to have normative language in this > appendix. The text appears to me to be more of a comment than a normative requirement, so I'm simply going to change "MAY" to "may" and hope that lets us move on. (4) That is everything on my list. If anyone has other things, or I've missed an important note, please speak up _very_ soon. john --On Thursday, March 2, 2017 09:04 -0500 Alissa Cooper wrote: > > OLD > Thus r-components SHOULD NOT be used for actual > URNs until additional development and standardization work > is complete, including specification of any necessary > registration mechanisms. > > NEW > Thus r-components SHOULD NOT be used for URNs before their > semantics have been standardized. From nobody Thu Mar 2 08:57:38 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31457129515; Thu, 2 Mar 2017 08:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 dOhZVG98bu-U; Thu, 2 Mar 2017 08:57:18 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D53012951A; Thu, 2 Mar 2017 08:57:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AB407BEEA; Thu, 2 Mar 2017 16:57:15 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nzvq38WJiWaF; Thu, 2 Mar 2017 16:57:15 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0B2E2BE8E; Thu, 2 Mar 2017 16:57:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1488473835; bh=GKx53LLdHPiC11GUiE0jXiPPEu7SDKzVp4YRejVqrs0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=netKnoZCT2LOscLaiM9lfOtQSR3+MBsADXxmjEKSDq6nmlEme7TcUZ1QFmMIh4e3E 6RERQR8ZAiTZIR5djCBcHSF5dhTS3fmtxb7Wm97RtUBJ+riCeFayLK+XTngC7Ft+Rc KmTKJTgUOrRvmtZFGJ+lD1pU0qmxsAbZ3WEX4njE= To: John C Klensin References: <148832863670.29552.9014381848292739838.idtracker@ietfa.amsl.com> <68d0ad57-9ba0-beb2-2fe4-2f036fce3e93@stpeter.im> <836b3132-def8-0534-487a-bc78b69ee82c@cs.tcd.ie> <2cd348ce-1378-ddf7-574a-73283709999c@cs.tcd.ie> <9499477E8333E7F4AB7E0101@PSB> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Thu, 2 Mar 2017 16:57:14 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <9499477E8333E7F4AB7E0101@PSB> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qs3Nd9j8JTehevh8i7iURnNtMINpXROFm" Archived-At: Cc: barryleiba@computer.org, draft-ietf-urnbis-rfc2141bis-urn@ietf.org, The IESG , urnbis-chairs@ietf.org, urn@ietf.org Subject: Re: [urn] Stephen Farrell's Abstain on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 16:57:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qs3Nd9j8JTehevh8i7iURnNtMINpXROFm Content-Type: multipart/mixed; boundary="auS2x2cQKVJegSFA62RIgudrrAFaS7D4x"; protected-headers="v1" From: Stephen Farrell To: John C Klensin Cc: urn@ietf.org, Peter Saint-Andre , The IESG , urnbis-chairs@ietf.org, barryleiba@computer.org, draft-ietf-urnbis-rfc2141bis-urn@ietf.org Message-ID: Subject: Re: [urn] Stephen Farrell's Abstain on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT) References: <148832863670.29552.9014381848292739838.idtracker@ietfa.amsl.com> <68d0ad57-9ba0-beb2-2fe4-2f036fce3e93@stpeter.im> <836b3132-def8-0534-487a-bc78b69ee82c@cs.tcd.ie> <2cd348ce-1378-ddf7-574a-73283709999c@cs.tcd.ie> <9499477E8333E7F4AB7E0101@PSB> In-Reply-To: <9499477E8333E7F4AB7E0101@PSB> --auS2x2cQKVJegSFA62RIgudrrAFaS7D4x Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/03/17 15:45, John C Klensin wrote: > Stephen, >=20 > If you want to craft some text and tell us where to put it, I'd > appreciate it. Noting that there is already a template > requirement for security and privacy information and the DE team > is charged with reviewing those templates for completeness,=20 Sure. I'd suggest the following change in 6.4.4: OLD: o Various issues discussed in the guidelines for security considerations in RFCs [RFC3552] and the privacy considerations for Internet protocols [RFC6973]. NEW: o Various issues discussed in the guidelines for security considerations in RFCs [RFC3552] and the privacy considerations for Internet protocols [RFC6973]. In particular note the privacy considerations text in [RFC7254] which may provide a useful model for such cases. And adding 7254 as a reference as well. If Peter or someone wants to suggest more text, that'd also be fine by me. Cheers, S. > I > think it is important that such text be as extensive as needed > but no longer and, in particular, that it not add to the > redundancy that you and Alissa have complained about any more > than necessary. >=20 > thanks, > john >=20 >=20 > --On Thursday, March 2, 2017 14:33 +0000 Stephen Farrell > wrote: >=20 >> >> Hi John, >> >> For context (that I'm sure isn't needed for some of you, >> but will nonetheless spell out just in case:-), as I'm >> an abstain ballot, I'm not blocking this, but I am happy >> to chat of course. >> >> That said, yes, I think it would be good and sufficient >> to highlight the need for privacy to be considered as >> part of evaluations here, and I'd also hope that the IESG >> when appointing DEs keep that in mind. I also agree that >> there's a danger here of trying to police things too >> much, hence my reference to rfc6919 and it's fine concept >> of "MUST (but we know you won't)" that is worth avoiding >> in any text we add about privacy. >> >> Anyway, yes I think a bit more text that emphasises that >> there can be (for some folks, unexpected) privacy issues >> here and a pointer to the example of rfc7254 should be >> fine. >> >> If it helps for me to try help craft a bit of text along >> those lines, I'm happy to help with that, but I'm also >> happy for the folks involved to just do that if they so >> choose. >> >> Cheers, >> S. >> >> On 02/03/17 13:35, John C Klensin wrote: >>> >>> >>> --On Thursday, March 2, 2017 08:11 +0000 Stephen Farrell >>> wrote: >>> >>>>> Perhaps you could clarify what some of your concerns are >>>>> here, above and beyond the use of URIs in general (after >>>>> all, a URN is a URI). Reading between the lines, I imagine >>>>> you might be worried that URNs within a particular URN >>>>> namespace (e.g., for U.S. Social Security Numbers or the >>>>> like) - once suitably resolved into one or more URLs - >>>>> might enable an attacker to determine a person's physical >>>>> location (e.g., via IP address) or actual identity (e.g., a >>>>> pseudonym could "resolve" to a real name). Are these >>>>> guesses on the mark? >>>> >>>> Yep. Perhaps things like including an IMSI or IMEI (or >>>> values easily correlated with such) in the NSS part is >>>> what it'd useful to call out. I'm not sure if there are >>>> real examples of such in existing URNs but if there were >>>> it'd be a fine thing to note that including such things >>>> imposes (often unmet) requirements for e.g. confidentiality >>>> on protocols and applications that use those URNs. If >>>> may also be useful to say that things like hashing the >>>> privacy sensitive value before inclusion in the URN don't >>>> prevent correlation and can be as "good" for >>>> re-identification as the non-hashed value. >>>> >>>> The argument to include text here is that it seems to be >>>> very tempting to include that kind of information for many >>>> folks. >>> >>> Stephen, >>> >>> It seems to me that the possibility of creating URNs that >>> could disclose private, or personal-information-tracing, >>> information is not an issue with URN symtax and definitions >>> but with what namespaces are created (and NIDs registered). >>> In principle (and as others have suggested), that issue could >>> apply to any URI and to most other identifier types that can >>> be used on the Internet. For URIs, even if the domain is >>> fixed a simple search using a URI query can disclose personal >>> location or other private information if the search >>> parameters are then harvested and/or stored, which I >>> understand to be a common practice. >>> >>> Two observations about this issue wrt the present document: >>> >>> (1) The NID registration approval process and associated >>> protections. >>> >>> Because of the diversity of the issues involved, the intent of >>> the WG was that Expert Review of URN NID registration >>> proposals would never rely on a single individual but on a >>> team with different perspectives, working together. As I >>> reread the draft just now, while that team idea is strongly >>> hinted at, perhaps it should be made more explicit (if you >>> think so, text would be welcome). In any event, appointment >>> of designated experts (individually or as a team) is under >>> control of the IESG. It seems to me that it would be >>> entirely appropriate for the IESG to include a privacy expert >>> on that team if you (collectively) believe that would be >>> helpful. =20 >>> >>> Projecting a bit from other experience, a focused discussion >>> about potential problems with a particular proposed namespace >>> (including but not limited to privacy issues) is much more >>> likely to lead to understanding and, where plausible, >>> mitigation of those problems than some sort of general >>> statement in a registration specification. The comments in >>> the I-D about team efforts and parties working together "in a >>> spirit of good faith and mutual understanding" are >>> specifically intended to facilitate such discussions. Given >>> the RFC 7254 example (and your ultimate "No objection" >>> position on it), it is hard to imagine the new procedure >>> working less well to prevent privacy problems than the >>> current "IETF Consensus" arrangements. >>> >>> I also note that the registration template explicitly calls >>> for consideration of security and privacy issues in >>> namespaces and namespace registrations. That should be a >>> considerable improvement from your standpoint over the >>> language of RFC 3406. >>> >>> >>> (2) Namespace registrations and the Protocol Police >>> >>> URN namespaces and the identifying NIDs are as, or more, >>> easily used without formal IETF approval or registration than >>> URI scheme names, media types, and many other identifiers. >>> The Protocol Police have been quite ineffective in preventing >>> or punishing such actions. If we create barriers to >>> registration that seem burdensome and/or frustrate people >>> from what they "want to do", experience indicates that the >>> registration procedure, and perhaps syntax and other >>> restrictions, will simply be ignored. =20 >>> >>> RFC 7254 may be a good example here too: if GSMA really >>> believed that they needed a namespace of that type and that >>> the IETF had said "no, you can't have one because it might >>> lead to disclosure of personal information", the only two >>> outcomes I can imagine are that they would have gone ahead >>> and used an unregistered URN namespace or that they would >>> have picked out some other identifier over which the IETF >>> does not claim authority. Neither would provide significant >>> additional privacy. I find it very hard to imagine that they >>> would have simply given up and conclude that no such >>> identifier collection or namespace was needed. >>> >>> Rather than try to create prohibitions that we cannot enforce, >>> the new registration procedures are intended to facilitate >>> discussions in which our experts can use our expertise to shed >>> light on issues and identify and mitigate problems where >>> possible while encouraging the registrations themselves. The >>> latter, if nothing else, reduces the odds of duplication of >>> supposedly-unique identifiers. Avoiding such duplication is >>> an important operational and security issue, at least IMO. >>> >>> best, >>> john >>> >>> >>> >> >=20 >=20 >=20 >=20 --auS2x2cQKVJegSFA62RIgudrrAFaS7D4x-- --qs3Nd9j8JTehevh8i7iURnNtMINpXROFm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYuE7qAAoJEC88hzaAX42itsIIAI1iy09RBAgO4LjhpQwKDR/f Uj5Jdsxa/euxg7cBHngDT0Iykb0AGzLrC0DBC+IqOgZ6MR7+oycqwKswJjn0rZIr T9dalGDIYWJttyqIUoya+8C90kmY3kFbz3w0SibR9GcoKPLEfgUSKMgl+Dmhp7h3 ojpdwF48C2Lhozbj4BP6j3LE9Ju57Gb8gAK4Qa12BswqT7+BNFONVZvMaQHGzBy5 T/0MwjQbsPm0FkxRSS6JHVTQikf0vPqwCNQ/RhFGsKwtMBxIyu23A9tIRF9bKcts jfYSOG4BgTmuXfndoIgelJxzJDDtL0E5CLoovKMezHRNmfU5iTeElfIB5In66fQ= =l+jt -----END PGP SIGNATURE----- --qs3Nd9j8JTehevh8i7iURnNtMINpXROFm-- From nobody Thu Mar 2 09:16:52 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43373129567; Thu, 2 Mar 2017 09:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 Pg9rBvxQ59bb; Thu, 2 Mar 2017 09:16:50 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF1911294E3; Thu, 2 Mar 2017 09:16:49 -0800 (PST) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cjULP-000ChQ-Rm; Thu, 02 Mar 2017 12:16:47 -0500 Date: Thu, 02 Mar 2017 12:16:40 -0500 From: John C Klensin To: Stephen Farrell Message-ID: <73C38C9E8D1BC77A7A8F9707@PSB> In-Reply-To: References: <148832863670.29552.9014381848292739838.idtracker@ietfa.amsl.com> <68d0ad57-9ba0-beb2-2fe4-2f036fce3e93@stpeter.im> <836b3132-def8-0534-487a-bc78b69ee82c@cs.tcd.ie> <2cd348ce-1378-ddf7-574a-73283709999c@cs.tcd.ie> <9499477E8333E7F4AB7E0101@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.70 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: barryleiba@computer.org, draft-ietf-urnbis-rfc2141bis-urn@ietf.org, The IESG , urnbis-chairs@ietf.org, urn@ietf.org Subject: Re: [urn] Stephen Farrell's Abstain on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 17:16:51 -0000 Stephen, I edited your text to reflect the document's general practice of describe documents and attaching the RFC citation rather than using the reference anchor as a sentence object, but, otherwise, done. I'm going to wait a few hours to see if anyone complains that I've missed anything, then will compile and circulate the working draft to this list. That should still give Peter time to paste any alternate or additional text into the working draft if he feels the inclination or need. thanks, john --On Thursday, March 2, 2017 16:57 +0000 Stephen Farrell wrote: > > > On 02/03/17 15:45, John C Klensin wrote: >> Stephen, >> >> If you want to craft some text and tell us where to put it, >> I'd appreciate it. Noting that there is already a template >> requirement for security and privacy information and the DE >> team is charged with reviewing those templates for >> completeness, > > Sure. I'd suggest the following change in 6.4.4: > > OLD: > > o Various issues discussed in the guidelines for security > considerations in RFCs [RFC3552] and the privacy > considerations for Internet protocols [RFC6973]. > > NEW: > > o Various issues discussed in the guidelines for security > considerations in RFCs [RFC3552] and the privacy > considerations for Internet protocols [RFC6973]. In > particular note the privacy considerations text in > [RFC7254] which may provide a useful model for such > cases. > > And adding 7254 as a reference as well. > > If Peter or someone wants to suggest more text, that'd also be > fine by me. > > Cheers, > S. > >> I >> think it is important that such text be as extensive as needed >> but no longer and, in particular, that it not add to the >> redundancy that you and Alissa have complained about any more >> than necessary. >> >> thanks, >> john >> >> >> --On Thursday, March 2, 2017 14:33 +0000 Stephen Farrell >> wrote: >> >>> >>> Hi John, >>> >>> For context (that I'm sure isn't needed for some of you, >>> but will nonetheless spell out just in case:-), as I'm >>> an abstain ballot, I'm not blocking this, but I am happy >>> to chat of course. >>> >>> That said, yes, I think it would be good and sufficient >>> to highlight the need for privacy to be considered as >>> part of evaluations here, and I'd also hope that the IESG >>> when appointing DEs keep that in mind. I also agree that >>> there's a danger here of trying to police things too >>> much, hence my reference to rfc6919 and it's fine concept >>> of "MUST (but we know you won't)" that is worth avoiding >>> in any text we add about privacy. >>> >>> Anyway, yes I think a bit more text that emphasises that >>> there can be (for some folks, unexpected) privacy issues >>> here and a pointer to the example of rfc7254 should be >>> fine. >>> >>> If it helps for me to try help craft a bit of text along >>> those lines, I'm happy to help with that, but I'm also >>> happy for the folks involved to just do that if they so >>> choose. >>> >>> Cheers, >>> S. >>> >>> On 02/03/17 13:35, John C Klensin wrote: >>>> >>>> >>>> --On Thursday, March 2, 2017 08:11 +0000 Stephen Farrell >>>> wrote: >>>> >>>>>> Perhaps you could clarify what some of your concerns are >>>>>> here, above and beyond the use of URIs in general (after >>>>>> all, a URN is a URI). Reading between the lines, I imagine >>>>>> you might be worried that URNs within a particular URN >>>>>> namespace (e.g., for U.S. Social Security Numbers or the >>>>>> like) - once suitably resolved into one or more URLs - >>>>>> might enable an attacker to determine a person's physical >>>>>> location (e.g., via IP address) or actual identity (e.g., >>>>>> a pseudonym could "resolve" to a real name). Are these >>>>>> guesses on the mark? >>>>> >>>>> Yep. Perhaps things like including an IMSI or IMEI (or >>>>> values easily correlated with such) in the NSS part is >>>>> what it'd useful to call out. I'm not sure if there are >>>>> real examples of such in existing URNs but if there were >>>>> it'd be a fine thing to note that including such things >>>>> imposes (often unmet) requirements for e.g. confidentiality >>>>> on protocols and applications that use those URNs. If >>>>> may also be useful to say that things like hashing the >>>>> privacy sensitive value before inclusion in the URN don't >>>>> prevent correlation and can be as "good" for >>>>> re-identification as the non-hashed value. >>>>> >>>>> The argument to include text here is that it seems to be >>>>> very tempting to include that kind of information for many >>>>> folks. >>>> >>>> Stephen, >>>> >>>> It seems to me that the possibility of creating URNs that >>>> could disclose private, or personal-information-tracing, >>>> information is not an issue with URN symtax and definitions >>>> but with what namespaces are created (and NIDs registered). >>>> In principle (and as others have suggested), that issue >>>> could apply to any URI and to most other identifier types >>>> that can be used on the Internet. For URIs, even if the >>>> domain is fixed a simple search using a URI query can >>>> disclose personal location or other private information if >>>> the search parameters are then harvested and/or stored, >>>> which I understand to be a common practice. >>>> >>>> Two observations about this issue wrt the present document: >>>> >>>> (1) The NID registration approval process and associated >>>> protections. >>>> >>>> Because of the diversity of the issues involved, the intent >>>> of the WG was that Expert Review of URN NID registration >>>> proposals would never rely on a single individual but on a >>>> team with different perspectives, working together. As I >>>> reread the draft just now, while that team idea is strongly >>>> hinted at, perhaps it should be made more explicit (if you >>>> think so, text would be welcome). In any event, appointment >>>> of designated experts (individually or as a team) is under >>>> control of the IESG. It seems to me that it would be >>>> entirely appropriate for the IESG to include a privacy >>>> expert on that team if you (collectively) believe that >>>> would be helpful. >>>> >>>> Projecting a bit from other experience, a focused discussion >>>> about potential problems with a particular proposed >>>> namespace (including but not limited to privacy issues) is >>>> much more likely to lead to understanding and, where >>>> plausible, mitigation of those problems than some sort of >>>> general statement in a registration specification. The >>>> comments in the I-D about team efforts and parties working >>>> together "in a spirit of good faith and mutual >>>> understanding" are specifically intended to facilitate such >>>> discussions. Given the RFC 7254 example (and your ultimate >>>> "No objection" position on it), it is hard to imagine the >>>> new procedure working less well to prevent privacy problems >>>> than the current "IETF Consensus" arrangements. >>>> >>>> I also note that the registration template explicitly calls >>>> for consideration of security and privacy issues in >>>> namespaces and namespace registrations. That should be a >>>> considerable improvement from your standpoint over the >>>> language of RFC 3406. >>>> >>>> >>>> (2) Namespace registrations and the Protocol Police >>>> >>>> URN namespaces and the identifying NIDs are as, or more, >>>> easily used without formal IETF approval or registration >>>> than URI scheme names, media types, and many other >>>> identifiers. The Protocol Police have been quite >>>> ineffective in preventing or punishing such actions. If we >>>> create barriers to registration that seem burdensome and/or >>>> frustrate people from what they "want to do", experience >>>> indicates that the registration procedure, and perhaps >>>> syntax and other restrictions, will simply be ignored. >>>> >>>> RFC 7254 may be a good example here too: if GSMA really >>>> believed that they needed a namespace of that type and that >>>> the IETF had said "no, you can't have one because it might >>>> lead to disclosure of personal information", the only two >>>> outcomes I can imagine are that they would have gone ahead >>>> and used an unregistered URN namespace or that they would >>>> have picked out some other identifier over which the IETF >>>> does not claim authority. Neither would provide significant >>>> additional privacy. I find it very hard to imagine that >>>> they would have simply given up and conclude that no such >>>> identifier collection or namespace was needed. >>>> >>>> Rather than try to create prohibitions that we cannot >>>> enforce, the new registration procedures are intended to >>>> facilitate discussions in which our experts can use our >>>> expertise to shed light on issues and identify and mitigate >>>> problems where possible while encouraging the registrations >>>> themselves. The latter, if nothing else, reduces the odds >>>> of duplication of supposedly-unique identifiers. Avoiding >>>> such duplication is an important operational and security >>>> issue, at least IMO. >>>> >>>> best, >>>> john >>>> >>>> >>>> >>> >> >> >> >> > From nobody Thu Mar 2 10:08:51 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19EBF1294EB; Thu, 2 Mar 2017 10:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=stpeter.im header.b=whCiG8OX; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=l5uWvL9y 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 o34wmYjY7py3; Thu, 2 Mar 2017 10:08:48 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE8931294CF; Thu, 2 Mar 2017 10:08:48 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 0DE842072E; Thu, 2 Mar 2017 13:08:48 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 02 Mar 2017 13:08:48 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=SiO5Q0y8ohOxXTt 7/I95g4rt//M=; b=whCiG8OX1KYZ/hmWXe7GI12gOY/VosVlWmj81cqjzG1Ntfj c59U0xexyMut2sg0gEh+Hr8dPv64e+FUo6AnFSXG9zirBLdCipWKtMA+HeTUppPs wijMkCjVQ960Hdus/H4HghiTTwdgHiyVCzQx4raIRh4I3EuT3c3yawuM10HA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=SiO5Q0y8ohOxXTt7/I95g4rt//M=; b=l5uWvL9yxJM4Mm/F0Xgt cyYt0Doy1TAHQGCnTlbvZxj61tHeggXeuVPm82B75Ob+UxJoiPuMSrtjesWypU4J meopyip7RYzw+RCA7UubqCKlXzSakoaczOnm57QEHEpVYN9sLofFFNXk/fCSp/0i /3Ntcs3SK3bbEpu49vSBt0I= X-ME-Sender: X-Sasl-enc: ZHJJ9mqIckh7HrXJVGjRiCQVxKqF69oFjNMmVPdsxnHf 1488478127 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 2643E7E0EE; Thu, 2 Mar 2017 13:08:47 -0500 (EST) To: John C Klensin , Stephen Farrell References: <148832863670.29552.9014381848292739838.idtracker@ietfa.amsl.com> <68d0ad57-9ba0-beb2-2fe4-2f036fce3e93@stpeter.im> <836b3132-def8-0534-487a-bc78b69ee82c@cs.tcd.ie> <2cd348ce-1378-ddf7-574a-73283709999c@cs.tcd.ie> <9499477E8333E7F4AB7E0101@PSB> <73C38C9E8D1BC77A7A8F9707@PSB> From: Peter Saint-Andre Message-ID: <3ccc5410-f216-a63b-ed95-d9a02280b0f7@stpeter.im> Date: Thu, 2 Mar 2017 11:08:46 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <73C38C9E8D1BC77A7A8F9707@PSB> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-urnbis-rfc2141bis-urn@ietf.org, urn@ietf.org, The IESG , urnbis-chairs@ietf.org, barryleiba@computer.org Subject: Re: [urn] Stephen Farrell's Abstain on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 18:08:50 -0000 That seems like a fine path forward. I don't have anything else to add. On 3/2/17 10:16 AM, John C Klensin wrote: > Stephen, I edited your text to reflect the document's general > practice of describe documents and attaching the RFC citation > rather than using the reference anchor as a sentence object, > but, otherwise, done. > > I'm going to wait a few hours to see if anyone complains that > I've missed anything, then will compile and circulate the > working draft to this list. That should still give Peter time > to paste any alternate or additional text into the working draft > if he feels the inclination or need. > > thanks, > john > > > --On Thursday, March 2, 2017 16:57 +0000 Stephen Farrell > wrote: > >> >> >> On 02/03/17 15:45, John C Klensin wrote: >>> Stephen, >>> >>> If you want to craft some text and tell us where to put it, >>> I'd appreciate it. Noting that there is already a template >>> requirement for security and privacy information and the DE >>> team is charged with reviewing those templates for >>> completeness, >> >> Sure. I'd suggest the following change in 6.4.4: >> >> OLD: >> >> o Various issues discussed in the guidelines for security >> considerations in RFCs [RFC3552] and the privacy >> considerations for Internet protocols [RFC6973]. >> >> NEW: >> >> o Various issues discussed in the guidelines for security >> considerations in RFCs [RFC3552] and the privacy >> considerations for Internet protocols [RFC6973]. In >> particular note the privacy considerations text in >> [RFC7254] which may provide a useful model for such >> cases. >> >> And adding 7254 as a reference as well. >> >> If Peter or someone wants to suggest more text, that'd also be >> fine by me. >> >> Cheers, >> S. >> >>> I >>> think it is important that such text be as extensive as needed >>> but no longer and, in particular, that it not add to the >>> redundancy that you and Alissa have complained about any more >>> than necessary. >>> >>> thanks, >>> john >>> >>> >>> --On Thursday, March 2, 2017 14:33 +0000 Stephen Farrell >>> wrote: >>> >>>> >>>> Hi John, >>>> >>>> For context (that I'm sure isn't needed for some of you, >>>> but will nonetheless spell out just in case:-), as I'm >>>> an abstain ballot, I'm not blocking this, but I am happy >>>> to chat of course. >>>> >>>> That said, yes, I think it would be good and sufficient >>>> to highlight the need for privacy to be considered as >>>> part of evaluations here, and I'd also hope that the IESG >>>> when appointing DEs keep that in mind. I also agree that >>>> there's a danger here of trying to police things too >>>> much, hence my reference to rfc6919 and it's fine concept >>>> of "MUST (but we know you won't)" that is worth avoiding >>>> in any text we add about privacy. >>>> >>>> Anyway, yes I think a bit more text that emphasises that >>>> there can be (for some folks, unexpected) privacy issues >>>> here and a pointer to the example of rfc7254 should be >>>> fine. >>>> >>>> If it helps for me to try help craft a bit of text along >>>> those lines, I'm happy to help with that, but I'm also >>>> happy for the folks involved to just do that if they so >>>> choose. >>>> >>>> Cheers, >>>> S. >>>> >>>> On 02/03/17 13:35, John C Klensin wrote: >>>>> >>>>> >>>>> --On Thursday, March 2, 2017 08:11 +0000 Stephen Farrell >>>>> wrote: >>>>> >>>>>>> Perhaps you could clarify what some of your concerns are >>>>>>> here, above and beyond the use of URIs in general (after >>>>>>> all, a URN is a URI). Reading between the lines, I imagine >>>>>>> you might be worried that URNs within a particular URN >>>>>>> namespace (e.g., for U.S. Social Security Numbers or the >>>>>>> like) - once suitably resolved into one or more URLs - >>>>>>> might enable an attacker to determine a person's physical >>>>>>> location (e.g., via IP address) or actual identity (e.g., >>>>>>> a pseudonym could "resolve" to a real name). Are these >>>>>>> guesses on the mark? >>>>>> >>>>>> Yep. Perhaps things like including an IMSI or IMEI (or >>>>>> values easily correlated with such) in the NSS part is >>>>>> what it'd useful to call out. I'm not sure if there are >>>>>> real examples of such in existing URNs but if there were >>>>>> it'd be a fine thing to note that including such things >>>>>> imposes (often unmet) requirements for e.g. confidentiality >>>>>> on protocols and applications that use those URNs. If >>>>>> may also be useful to say that things like hashing the >>>>>> privacy sensitive value before inclusion in the URN don't >>>>>> prevent correlation and can be as "good" for >>>>>> re-identification as the non-hashed value. >>>>>> >>>>>> The argument to include text here is that it seems to be >>>>>> very tempting to include that kind of information for many >>>>>> folks. >>>>> >>>>> Stephen, >>>>> >>>>> It seems to me that the possibility of creating URNs that >>>>> could disclose private, or personal-information-tracing, >>>>> information is not an issue with URN symtax and definitions >>>>> but with what namespaces are created (and NIDs registered). >>>>> In principle (and as others have suggested), that issue >>>>> could apply to any URI and to most other identifier types >>>>> that can be used on the Internet. For URIs, even if the >>>>> domain is fixed a simple search using a URI query can >>>>> disclose personal location or other private information if >>>>> the search parameters are then harvested and/or stored, >>>>> which I understand to be a common practice. >>>>> >>>>> Two observations about this issue wrt the present document: >>>>> >>>>> (1) The NID registration approval process and associated >>>>> protections. >>>>> >>>>> Because of the diversity of the issues involved, the intent >>>>> of the WG was that Expert Review of URN NID registration >>>>> proposals would never rely on a single individual but on a >>>>> team with different perspectives, working together. As I >>>>> reread the draft just now, while that team idea is strongly >>>>> hinted at, perhaps it should be made more explicit (if you >>>>> think so, text would be welcome). In any event, appointment >>>>> of designated experts (individually or as a team) is under >>>>> control of the IESG. It seems to me that it would be >>>>> entirely appropriate for the IESG to include a privacy >>>>> expert on that team if you (collectively) believe that >>>>> would be helpful. >>>>> >>>>> Projecting a bit from other experience, a focused discussion >>>>> about potential problems with a particular proposed >>>>> namespace (including but not limited to privacy issues) is >>>>> much more likely to lead to understanding and, where >>>>> plausible, mitigation of those problems than some sort of >>>>> general statement in a registration specification. The >>>>> comments in the I-D about team efforts and parties working >>>>> together "in a spirit of good faith and mutual >>>>> understanding" are specifically intended to facilitate such >>>>> discussions. Given the RFC 7254 example (and your ultimate >>>>> "No objection" position on it), it is hard to imagine the >>>>> new procedure working less well to prevent privacy problems >>>>> than the current "IETF Consensus" arrangements. >>>>> >>>>> I also note that the registration template explicitly calls >>>>> for consideration of security and privacy issues in >>>>> namespaces and namespace registrations. That should be a >>>>> considerable improvement from your standpoint over the >>>>> language of RFC 3406. >>>>> >>>>> >>>>> (2) Namespace registrations and the Protocol Police >>>>> >>>>> URN namespaces and the identifying NIDs are as, or more, >>>>> easily used without formal IETF approval or registration >>>>> than URI scheme names, media types, and many other >>>>> identifiers. The Protocol Police have been quite >>>>> ineffective in preventing or punishing such actions. If we >>>>> create barriers to registration that seem burdensome and/or >>>>> frustrate people from what they "want to do", experience >>>>> indicates that the registration procedure, and perhaps >>>>> syntax and other restrictions, will simply be ignored. >>>>> >>>>> RFC 7254 may be a good example here too: if GSMA really >>>>> believed that they needed a namespace of that type and that >>>>> the IETF had said "no, you can't have one because it might >>>>> lead to disclosure of personal information", the only two >>>>> outcomes I can imagine are that they would have gone ahead >>>>> and used an unregistered URN namespace or that they would >>>>> have picked out some other identifier over which the IETF >>>>> does not claim authority. Neither would provide significant >>>>> additional privacy. I find it very hard to imagine that >>>>> they would have simply given up and conclude that no such >>>>> identifier collection or namespace was needed. >>>>> >>>>> Rather than try to create prohibitions that we cannot >>>>> enforce, the new registration procedures are intended to >>>>> facilitate discussions in which our experts can use our >>>>> expertise to shed light on issues and identify and mitigate >>>>> problems where possible while encouraging the registrations >>>>> themselves. The latter, if nothing else, reduces the odds >>>>> of duplication of supposedly-unique identifiers. Avoiding >>>>> such duplication is an important operational and security >>>>> issue, at least IMO. >>>>> >>>>> best, >>>>> john >>>>> From nobody Thu Mar 2 18:09:55 2017 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 329481279EB; Thu, 2 Mar 2017 18:09:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148850699120.30959.1001157766959296375.idtracker@ietfa.amsl.com> Date: Thu, 02 Mar 2017 18:09:51 -0800 Archived-At: Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-22.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 02:09:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names, Revised of the IETF. Title : Uniform Resource Names (URNs) Authors : Peter Saint-Andre John C Klensin Filename : draft-ietf-urnbis-rfc2141bis-urn-22.txt Pages : 44 Date : 2017-03-02 Abstract: A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN- equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFC 2141 and RFC 3406. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc2141bis-urn-22 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 2 18:10:36 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D312129426 for ; Thu, 2 Mar 2017 18:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=stpeter.im header.b=ttDoE5uo; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=YiEe4Hr7 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 yRSdt6--5dqz for ; Thu, 2 Mar 2017 18:10:33 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CBAA1293FF for ; Thu, 2 Mar 2017 18:10:33 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 1A81C20D41; Thu, 2 Mar 2017 21:10:33 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 02 Mar 2017 21:10:33 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=I/jYVDkV5AVn4vw oYh78TeTmqy8=; b=ttDoE5uoE3qVlVOuXVvQP/a0EDKhKgr1QOQO/mRvN/S6VgL N0RqjYf5zQcFoMou1gyVLA10PRBcbuFNr9/QFKTrgYKWuVE3VOheqfFCkaWJDjTy 7k9NvV0uOhbVw72h8TElkkYKARH8tqRBO4a57Eu0MPZYT9znFyCwWlV4l6fk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=I/jYVDkV5AVn4vwoYh78TeTmqy8=; b=YiEe4Hr7aiYmIhZr3HCk AKuI9V/3ORqqkXMWWZDZUv3UP8Ekp2ytsTEWjFYfx8wdtVwy2iobtJLz8lzhZh5B XxlfUPSfth9XniktArapjidnOAz27I0xoqkWcxDnJVCdgZiVDcCb66ZA30QgH13W 1YierLgsG2+Lvy66i/1kd2c= X-ME-Sender: X-Sasl-enc: e29PPFuD6wjXZVyt0g8HiiFNHoPE57J0YMv7/0hUk9Mg 1488507032 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 9F28E24216; Thu, 2 Mar 2017 21:10:32 -0500 (EST) To: urn@ietf.org References: <148850699120.30959.1001157766959296375.idtracker@ietfa.amsl.com> From: Peter Saint-Andre Message-ID: <268427c7-f5a6-5f38-ab74-c38bbac1058f@stpeter.im> Date: Thu, 2 Mar 2017 19:10:31 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <148850699120.30959.1001157766959296375.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] I-D Action: draft-ietf-urnbis-rfc2141bis-urn-22.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 02:10:35 -0000 This version addresses IESG feedback. Peter On 3/2/17 7:09 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Uniform Resource Names, Revised of the IETF. > > Title : Uniform Resource Names (URNs) > Authors : Peter Saint-Andre > John C Klensin > Filename : draft-ietf-urnbis-rfc2141bis-urn-22.txt > Pages : 44 > Date : 2017-03-02 > > Abstract: > A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) > that is assigned under the "urn" URI scheme and a particular URN > namespace, with the intent that the URN will be a persistent, > location-independent resource identifier. With regard to URN syntax, > this document defines the canonical syntax for URNs (in a way that is > consistent with URI syntax), specifies methods for determining URN- > equivalence, and discusses URI conformance. With regard to URN > namespaces, this document specifies a method for defining a URN > namespace and associating it with a namespace identifier, and > describes procedures for registering namespace identifiers with the > Internet Assigned Numbers Authority (IANA). This document obsoletes > both RFC 2141 and RFC 3406. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-22 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc2141bis-urn-22 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > From nobody Mon Mar 6 08:40:59 2017 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1FB129898; Mon, 6 Mar 2017 08:40:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <148881844532.15065.7008413262175126349.idtracker@ietfa.amsl.com> Date: Mon, 06 Mar 2017 08:40:45 -0800 Archived-At: Cc: barryleiba@computer.org, draft-ietf-urnbis-rfc2141bis-urn@ietf.org, The IESG , urnbis-chairs@ietf.org, alexey.melnikov@isode.com, urn@ietf.org, rfc-editor@rfc-editor.org Subject: [urn] Protocol Action: 'Uniform Resource Names (URNs)' to Proposed Standard (draft-ietf-urnbis-rfc2141bis-urn-22.txt) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 16:40:45 -0000 The IESG has approved the following document: - 'Uniform Resource Names (URNs)' (draft-ietf-urnbis-rfc2141bis-urn-22.txt) as Proposed Standard This document is the product of the Uniform Resource Names, Revised Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/ Technical Summary This document defines "Uniform Resource Name", a URI that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN-equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and describes procedures for registering namespace identifiers with IANA. This document obsoletes RFCs 2141 and 3406. The document is defining a standard, and is therefore submitted to the Standards Track as a Proposed Standard. Working Group Summary The life of this document and the URNbis working group that produced it has been long and troubled. Over the six years since the work started, the document has been reviewed by a fair number of people, but they have come and gone over those years. What remains is a stalwart, relatively small group -- on the order of ten participants -- who have stuck it through and continue to comment. That stalwart group comprises essentially the entire community within the IETF that cares how this comes out, which is a good sign. A few people who were active participants some time ago have gone silent over the last year or so, and they could resurface during IETF last call. Yet that stalwart group disagrees on many things, which fact has resulted in a six-year process for something that we expected to take more like two. It doesn't make much sense to try to list specific topics for which there was disagreement. What makes more sense is to note that most of the active participants were on a conference call at the end of June 2016, and that that call resulted in discussion of and plans for resolution of all the significant disagreements that remained. It took the authors a number of months to be able to allocate the time to go through and make the agreed-upon changes, but that call showed that the working group really was able to work together, compromise when necessary, and come up with something everyone could live with, even if it wasn't their preferred solution. The resulting document is a solid piece of work that does have rough consensus of the working group and accomplishes what the working group set out to do. One point that does merit pointing out is the relationship of this document to RFC 3986 (which defines URIs, and which is a key related document). There were discussions of deviating from 3986 or not, and how far, if so. There were discussions of what the concepts of URI fragments and query strings can mean with respect to URNs, whether to allow them, and how to handle them, if so. There were discussions of what to say about whether and when URNs might be resolvable, and what that would mean. In the end, while there remains some level of disagreement about some of that, the current document represents a consensus view on the resolution of those discussions. Document Quality URNs are used in many places, in particular as XML namespace URIs and more generally when using persistent identifiers in documents. The document is mostly updating IANA registration policy (which doesn't affect implementations) and making URNs more flexible as far as their use with fragment identifiers, etc. Personnel Barry Leiba is the document shepherd; Alexey Melnikov is the responsible Area Director. From nobody Wed Mar 22 13:01:46 2017 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3C1129C19; Wed, 22 Mar 2017 13:01:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Carlos Pignataro To: Cc: urn@ietf.org, draft-ietf-urnbis-rfc2141bis-urn.all@ietf.org, iesg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.00 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149021289354.7677.1768062630529652476@ietfa.amsl.com> Date: Wed, 22 Mar 2017 13:01:33 -0700 Archived-At: Subject: [urn] Review of draft-ietf-urnbis-rfc2141bis-urn-22 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 20:01:34 -0000 Reviewer: Carlos Pignataro Review result: Ready [This review just popped up in the queue -- although old, completing for the record] Particular operational areas relate interoperability, conformance verification, registration, and default behaviors -- I believe those are adequately covered. Carlos Pignataro. From nobody Wed Mar 22 13:59:15 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F330128DE5; Wed, 22 Mar 2017 13:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 yBvIJkVqCI5u; Wed, 22 Mar 2017 13:59:01 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F8ED120326; Wed, 22 Mar 2017 13:59:01 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id l7so71683959ioe.3; Wed, 22 Mar 2017 13:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=4usCgtVDU0NiM3BAvLYNwGzRUEFb8TZhnGijD6h2Dxs=; b=Okmewq6FURT1CGuHcNXamlOBD0omYMqIYKVQ3tZEVmV/RrM1JV6IWZt60LfnXUJi+K jUwhqp6CnFr3wPIDyA+uPQXQA0GX2DAAMVCtmqRmiXdXeDHwxbbqax5ihfHd6sFF5VWl JYIJJEj6rVUfFU5oCF29vkhQVbENzWwCy7XNuo96CTUSYKgWSovst/3NOawOzwwreOzW NrR/sFVNeyVtxHNoONcKRZbplWudHWrjTQKE4P6SFY5FeMNQno1bsN9TUqCVuKCtacLJ 6jd2OTyiyaU1e9zzA+xWPMv8v7TuHY/CRETfo3+Gu6I2UEPkki7kXr93HxZr58F0yIM8 UapQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=4usCgtVDU0NiM3BAvLYNwGzRUEFb8TZhnGijD6h2Dxs=; b=GWNbidN0APMxu0+QVOdXEFdnI5VGBEIKq+uSn2eNXfzK/Egnvdajoyh2J5pyfb3NNP QsIhTx3T/+1DUZ7dnbUYeSfqrCytmVO1GhC/pTzJeOGxdbjJaZF3zP20rLj8voPcaxPQ QBFPNjulj0DQ46zft4kwYfnodScbRyq6933ZhHOngpMT3ame5ItDalefuY6hK/lUeoVI fE1/aSoHNIKaOqIBdEkQFtiKAJCpl+sWhfWVDsy6iBFNg41B6KyWet9FXe5GglcEFFAy hAzUG8WCcy2T4m61nVPsxpx1PTE8T0zHDuKhIV7GQcSMWm5pRAqSrFg+Ta3P1Dq1b/0u 7Xpw== X-Gm-Message-State: AFeK/H3oDqycyrvqDL7QfJo1GbyDyXeQ35q4wJVZlWm98lABUDa2NwT9dcBzUNseBSHxraLX8JrNjLZ+2lX0Tg== X-Received: by 10.107.55.68 with SMTP id e65mr38955253ioa.145.1490216340739; Wed, 22 Mar 2017 13:59:00 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.107.187.7 with HTTP; Wed, 22 Mar 2017 13:59:00 -0700 (PDT) In-Reply-To: <149021289354.7677.1768062630529652476@ietfa.amsl.com> References: <149021289354.7677.1768062630529652476@ietfa.amsl.com> From: Barry Leiba Date: Wed, 22 Mar 2017 22:59:00 +0200 X-Google-Sender-Auth: -u03NfS_VnF1TVzZe6OJllRbo8Q Message-ID: To: Carlos Pignataro Cc: "ops-dir@ietf.org" , "urn@ietf.org" , draft-ietf-urnbis-rfc2141bis-urn.all@ietf.org, IESG Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [urn] Review of draft-ietf-urnbis-rfc2141bis-urn-22 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 20:59:03 -0000 Thanks, Carlos. We appreciate the review -- always welcome, old or not. Barry On Wed, Mar 22, 2017 at 10:01 PM, Carlos Pignataro wrote: > Reviewer: Carlos Pignataro > Review result: Ready > > [This review just popped up in the queue -- although old, completing > for the record] > > Particular operational areas relate interoperability, conformance > verification, registration, and default behaviors -- I believe those > are adequately covered. > > Carlos Pignataro. > -- Barry -- Barry Leiba (barryleiba@computer.org) http://internetmessagingtechnology.org/