From L.Svensson@dnb.de Mon Feb 3 01:34:07 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451161A0195 for ; Mon, 3 Feb 2014 01:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 mznyogbX-pXJ for ; Mon, 3 Feb 2014 01:34:05 -0800 (PST) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 31A2E1A01A0 for ; Mon, 3 Feb 2014 01:34:04 -0800 (PST) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.dnb.de (Postfix) with ESMTP id 931D87EE87 for ; Mon, 3 Feb 2014 10:33:59 +0100 (CET) From: "Svensson, Lars" To: "urn@ietf.org" Thread-Topic: IETF 89 Preliminary Agenda Thread-Index: AQHPHu11/X5iKFzbrEiNje0ms9o0CpqjR+2A Date: Mon, 3 Feb 2014 09:33:53 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA43DAEB8@dnbf-ex1.AD.DDB.DE> References: <20140201013111.9751.31078.idtracker@ietfa.amsl.com> In-Reply-To: <20140201013111.9751.31078.idtracker@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.163] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [urn] FW: IETF 89 Preliminary Agenda X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 09:34:07 -0000 QWxsLA0KDQo+IFRoZSBJRVRGIDg5IFByZWxpbWluYXJ5IEFnZW5kYSBoYXMgYmVlbiBwb3N0ZWQu IFRoZSBmaW5hbCBhZ2VuZGEgd2lsbCBiZQ0KPiBwdWJsaXNoZWQgb24gRnJpZGF5LCBGZWJydWFy eSA3dGgsIDIwMTQuDQo+IA0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcv ODkvYWdlbmRhLmh0bWwNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzg5 L2FnZW5kYS50eHQNCg0KbG9va2luZyBhdCB0aGUgYWdlbmRhIEkgc2VlIG5vIFVSTi1yZWxhdGVk IGFjdGl2aXRpZXMsIHNvIEkgYXNzdW1lIHRoYXQgbWVhbnMgdGhlcmUgd2lsbCBiZSBubyBVUk4g bWVldGluZyBpbiBMb25kb24uIENvcnJlY3Q/DQoNCkJlc3QsDQoNCkxhcnMNCg0KKioqIExlc2Vu LiBIw7ZyZW4uIFdpc3Nlbi4gRGV1dHNjaGUgTmF0aW9uYWxiaWJsaW90aGVrICoqKiANCi0tIA0K RHIuIExhcnMgRy4gU3ZlbnNzb24NCkRldXRzY2hlIE5hdGlvbmFsYmlibGlvdGhlaw0KSW5mb3Jt YXRpb25zdGVjaG5vbG9naWUNClRlbGVmb246ICs0OS02OS0xNTI1LTE1MjUNCm1haWx0bzpsLnN2 ZW5zc29uQGRuYi5kZSANCmh0dHA6Ly93d3cuZG5iLmRlDQoNCg== From andy@hxr.us Mon Feb 3 14:13:32 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3AA1A01EE for ; Mon, 3 Feb 2014 14:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 mRbuVZmxiehW for ; Mon, 3 Feb 2014 14:13:31 -0800 (PST) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id 06BC01A015D for ; Mon, 3 Feb 2014 14:13:30 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id fa1so7595936pad.41 for ; Mon, 03 Feb 2014 14:13:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zi//jWDAsVfdTSs+DMHFlCLn1DaRX0Z6bAyncKLoef8=; b=hHXeHFGEd+BBMplb1ZXhB/2EnOdwZAIXp6ouQXP3EhwrpzborEVXUDDSVuxTxZk6Gq GCUvwk86UJ37AbybB9L+AMkv3ekJL5wgs+7wb33G9pGu6gr6PTAtlFuHli+tKN8ij8w+ zBgtigERgu+qSPLj2yX+RdJ+s8VjxCkpQgn3VRmAWHQCKEGIWKBWPkXcqizFTWRq5kF5 0A9XbSiW9caok0ol3fE9lR3vrUwqseZ4Bk5Q/JqDgItBuzqmWnXtSbyxI77R3l+MVX+P k5U3SnsQrW3ATFnip4QgHXeMwe2ixYdKelsKqDaTTbahzJoo1To/mwLu7srM8AkPKV7A bNdg== X-Gm-Message-State: ALoCoQmY7PfAM69exarzlzhFfQMH1mZ+R9aa+OqVkbflVYkyLDDGFN52dlrpNNjpgtgumLtSStUg MIME-Version: 1.0 X-Received: by 10.66.188.203 with SMTP id gc11mr39493076pac.63.1391465611008; Mon, 03 Feb 2014 14:13:31 -0800 (PST) Received: by 10.68.143.4 with HTTP; Mon, 3 Feb 2014 14:13:30 -0800 (PST) X-Originating-IP: [192.149.252.11] In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA43DAEB8@dnbf-ex1.AD.DDB.DE> References: <20140201013111.9751.31078.idtracker@ietfa.amsl.com> <24637769D123E644A105A0AF0E1F92EFA43DAEB8@dnbf-ex1.AD.DDB.DE> Date: Mon, 3 Feb 2014 17:13:30 -0500 Message-ID: From: Andrew Newton To: "Svensson, Lars" Content-Type: text/plain; charset=ISO-8859-1 Cc: "urn@ietf.org" Subject: Re: [urn] FW: IETF 89 Preliminary Agenda X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 22:13:32 -0000 On Mon, Feb 3, 2014 at 4:33 AM, Svensson, Lars wrote: > looking at the agenda I see no URN-related activities, so I assume that means there will be no URN meeting in London. Correct? That is correct. -andy From stpeter@stpeter.im Tue Feb 11 12:12:11 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFCA1A0731 for ; Tue, 11 Feb 2014 12:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ktIoqC5rIzEI for ; Tue, 11 Feb 2014 12:12:08 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 55B9D1A06F4 for ; Tue, 11 Feb 2014 12:12:08 -0800 (PST) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D6E48403C4; Tue, 11 Feb 2014 13:12:06 -0700 (MST) Message-ID: <52FA8416.8030400@stpeter.im> Date: Tue, 11 Feb 2014 13:12:06 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: John C Klensin References: <8CE245D723DEE2BB953F028F@JcK-HP8200.jck.com> In-Reply-To: <8CE245D723DEE2BB953F028F@JcK-HP8200.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] 3406bis-07 - substantive comments X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 20:12:11 -0000 On 1/21/14, 11:54 PM, John C Klensin wrote: > Hi. > > Apologies for the long silence. Me too. I've had a change of jobs so I have been quite busy with that transition. However, I am committed to completing this work! > The comments below are ones that WG participants should review > because they contain suggestions for changes to the Namespace > Definition Mechanisms spec > (draft-ietf-urnbis-rfc3406bis-urn-ns-reg-07) that some may > consider substantive. Editorial comments that are mostly for > Peter by that I will post for the information of the WG will > follow, as will an updated version of the transition I-D. > > best wishes to all for what is left of 2014 > > john > > ------------------------- > > (1) End of Section 4 proper (before 4.1): It seems to me that > you need to say what happens with any Experimental namespaces > that are in the registry. Experiment namespaces were never registered. > You should either say "there aren't > any", specify that they are automatically reclassified as > "formal", or specify that they have to be registered or > re-registered using this document's template and indicate that > formal namespaces starting in "x-" are explicitly allowed. > Presumably the prohibition of trailing hyphens in 2141bis > eliminates the possibility of someone registering "x-" itself > as an NID, but clarity might benefit by mentioning that in this > Note or in the syntax description bullets of Section 4.1. I suggest adding the following sentence to that paragraph: Because experimental namespaces were never registered, removing the experimental category has no impact on the existing registries or future registration procedures. > (2) End of Section 4.1: Just a question, but would there be > any point in further reserving "xn--". That's a good idea, just in case. I suggest the following text: 5. It MUST NOT start with the string "xn--", which is reserved for potential representation of DNS A-labels in the future [RFC5891]. > (3) Section 4.2 or IANA Considerations (Section 9): I think > this document needs to be clear about whether the expectation > is that IANA will assign the next available number or whether > applicants get to pick their favorite number as long as it > isn't assigned already. I don't have a preference about the > choice, but I think the document needs to give IANA clear > instructions. Agreed. I suggest the following change. OLD Informal namespaces are full-fledged URN namespaces, with all the associated rights and responsibilities. Informal namespaces differ from formal namespaces in the process for assigning a NID: for an informal namespace, IANA will assign an NID consisting of the string 'urn-' followed by one or more digits (e.g., "urn-7"). NEW Informal namespaces are full-fledged URN namespaces, with all the associated rights and responsibilities. Informal namespaces differ from formal namespaces in the process for assigning a NID: for an informal namespace, the registrant does not designate the NID; instead, IANA assigns a NID consisting of the string 'urn-' followed by one or more digits (e.g., "urn-7") where the digits consist of the next available number in the sequence of positive integers assigned to informal namespaces. > (4) Given the recent and ongoing privacy snit, there are > several places in this spec where at least a nod to potential > privacy issues would be in order. For example, Section 5.4 > might indicate that any privacy issues other than "leakage > of..." should be described and the second paragraph of Section > 10 might say "...potential security and privacy issues...". Noted. > (5) Sections 6.9 and 8: I'd be a lot happier with this if there > was a clear preference expressed for what the RFC Editor > traditionally describes as a "stable specification", especially > since IANA has seemingly gone out of the business of keeping > library of documents submitted in support of registrations. > That is expecially important given the formal non-archival > status of I-Ds and the observation that "published document" > doesn't have nearly as much meaning today as it might have had > 20 or 30 years ago. If you/we really want to allow I-Ds, I > recommend "Any Internet-Draft, RFC, specification, or other > stable document..." in 6.9 I suggest: OLD A pointer to an Internet-Draft, RFC, non-IETF specification, or other published document that provides further information about the namespace. NEW A pointer to an RFC, a specification published by another standards development organization, or another stable document that provides further information about the namespace. > and "...Expert Review and a stable > and clear specification is not required, the designated > experts for NID registration requests are encouraged to prefer > that a stable specification exist documenting the namespace > definition." in Section 8. Yes. > I think the intent of that sentence in Section 8 might be a bit > more clear if it said "...experts for NID registration requests > should strongly encourage applicants to provide a stable > specification that documents...". Agreed. We'd in general do well to avoid the passive voice. Thus... OLD although the registration policy for formal namespaces is Expert Review and a specification is not required, the designated experts for NID registration requests are encouraged to prefer that a specification exist documenting the namespace definition. NEW although the registration policy for formal namespaces is Expert Review and stable a specification is not strictly required, the designated experts for NID registration requests ought to encourage applicants to provide a stable specification documenting the namespace definition. > (6) Section 7.1, item 4: It seems to me that this allows a > possibility in which the designated experts simply refuse to > approve and application, perhaps by engaging in never-ending > nitpicking. Do we need an appeal procedure? Maybe. Let's discuss that a bit more on the list here. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Tue Feb 11 13:15:55 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F68E1A0757 for ; Tue, 11 Feb 2014 13:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 TF9rHy9mkgs4 for ; Tue, 11 Feb 2014 13:15:53 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4696C1A0735 for ; Tue, 11 Feb 2014 13:15:53 -0800 (PST) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 54752403C4; Tue, 11 Feb 2014 14:15:50 -0700 (MST) Message-ID: <52FA9305.5070803@stpeter.im> Date: Tue, 11 Feb 2014 14:15:49 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: John C Klensin References: <8CE245D723DEE2BB953F028F@JcK-HP8200.jck.com> <52FA8416.8030400@stpeter.im> In-Reply-To: <52FA8416.8030400@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: [urn] appeals (was: Re: 3406bis-07 - substantive comments) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 21:15:55 -0000 On 2/11/14, 1:12 PM, Peter Saint-Andre wrote: > On 1/21/14, 11:54 PM, John C Klensin wrote: > >> (6) Section 7.1, item 4: It seems to me that this allows a >> possibility in which the designated experts simply refuse to >> approve and application, perhaps by engaging in never-ending >> nitpicking. Do we need an appeal procedure? > > Maybe. Let's discuss that a bit more on the list here. Is the appeals process perhaps covered by Section 7 of RFC 5226, which in turn references Section 6.5 of RFC 2026? Or would we prefer something a bit less heavy? Peter -- Peter Saint-Andre https://stpeter.im/ From john-ietf@jck.com Tue Feb 11 14:10:36 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E8F1A0767 for ; Tue, 11 Feb 2014 14:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham 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 kBFwwV2Pgxxf for ; Tue, 11 Feb 2014 14:10:34 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3F51A076A for ; Tue, 11 Feb 2014 14:10:33 -0800 (PST) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1WDLX6-0002oL-Vq; Tue, 11 Feb 2014 17:10:25 -0500 Date: Tue, 11 Feb 2014 15:52:22 -0500 From: John C Klensin To: Peter Saint-Andre Message-ID: <4E5C487D7BB59C1426A82717@JCK-EEE10> In-Reply-To: <52FA9305.5070803@stpeter.im> References: <8CE245D723DEE2BB953F028F@JcK-HP8200.jck.com> <52FA8416.8030400@stpeter.im> <52FA9305.5070803@stpeter.im> 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 Cc: urn@ietf.org Subject: Re: [urn] appeals (was: Re: 3406bis-07 - substantive comments) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 22:10:36 -0000 --On Tuesday, 11 February, 2014 14:15 -0700 Peter Saint-Andre wrote: > On 2/11/14, 1:12 PM, Peter Saint-Andre wrote: >> On 1/21/14, 11:54 PM, John C Klensin wrote: >> >>> (6) Section 7.1, item 4: It seems to me that this allows a >>> possibility in which the designated experts simply refuse to >>> approve and application, perhaps by engaging in never-ending >>> nitpicking. Do we need an appeal procedure? >> >> Maybe. Let's discuss that a bit more on the list here. > > Is the appeals process perhaps covered by Section 7 of RFC > 5226, which in turn references Section 6.5 of RFC 2026? > > Or would we prefer something a bit less heavy? It seems to me that it would be useful to devise some sort of mediation process in which experts with different perspectives could examine things as a group. The difficulty with 2026-style appeals processes and URNs is that, as we have seen in this WG, there may be fundamental differences in perspective and assumptions among experts and those who think they are. There is no particular reason to believe that the IESG, as a group and long term, will have the expertise needed to facilitate a useful discussion, much less be able to reach conclusions/ judgments that everyone will trust and accept. On the other hand, I don't know whether this WG has the expertise or energy needed to devise such a system. john From john-ietf@jck.com Tue Feb 11 14:22:13 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D681A0783 for ; Tue, 11 Feb 2014 14:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham 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 rz7I9EhCWHxZ for ; Tue, 11 Feb 2014 14:22:11 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id BD2EE1A078F for ; Tue, 11 Feb 2014 14:21:36 -0800 (PST) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1WDLhQ-0002pL-Sf; Tue, 11 Feb 2014 17:21:05 -0500 Date: Tue, 11 Feb 2014 16:00:56 -0500 From: John C Klensin To: Peter Saint-Andre Message-ID: <75C0EDF8846AA4DC6D3E8A1E@JCK-EEE10> In-Reply-To: <52FA8416.8030400@stpeter.im> References: <8CE245D723DEE2BB953F028F@JcK-HP8200.jck.com> <52FA8416.8030400@stpeter.im> 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 Cc: urn@ietf.org Subject: Re: [urn] 3406bis-07 - substantive comments X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 22:22:14 -0000 --On Tuesday, 11 February, 2014 13:12 -0700 Peter Saint-Andre wrote: >> You should either say "there aren't >> any", specify that they are automatically reclassified as >> "formal", or specify that they have to be registered or >> re-registered using this document's template and indicate that >> formal namespaces starting in "x-" are explicitly allowed. >> Presumably the prohibition of trailing hyphens in 2141bis >> eliminates the possibility of someone registering "x-" itself >> as an NID, but clarity might benefit by mentioning that in >> this Note or in the syntax description bullets of Section 4.1. > > I suggest adding the following sentence to that paragraph: > > Because experimental namespaces were never > registered, removing the experimental category has no > impact on the > existing registries or future registration procedures. wfm >> (2) End of Section 4.1: Just a question, but would there be >> any point in further reserving "xn--". > > That's a good idea, just in case. I suggest the following text: > > 5. It MUST NOT start with the string "xn--", which is > reserved for > potential representation of DNS A-labels in the future > [RFC5891]. Probably 5890, which is where A-labels and the constraints on them are actually defined but otherwise yes. >> (3) Section 4.2 or IANA Considerations (Section 9): I think >> this document needs to be clear about whether the expectation >> is that IANA will assign the next available number or whether >> applicants get to pick their favorite number as long as it >> isn't assigned already. I don't have a preference about the >> choice, but I think the document needs to give IANA clear >> instructions. > > Agreed. I suggest the following change. > > OLD > > Informal namespaces are full-fledged URN namespaces, with > all the > associated rights and responsibilities. Informal > namespaces differ > from formal namespaces in the process for assigning a NID: > for an > informal namespace, IANA will assign an NID consisting of > the string > 'urn-' followed by one or more digits (e.g., "urn-7"). > > NEW > > Informal namespaces are full-fledged URN namespaces, with > all the > associated rights and responsibilities. Informal > namespaces differ > from formal namespaces in the process for assigning a NID: > for an > informal namespace, the registrant does not designate the > NID; > instead, IANA assigns a NID consisting of the string > 'urn-' followed > by one or more digits (e.g., "urn-7") where the digits > consist of the > next available number in the sequence of positive integers > assigned > to informal namespaces. Yes, that does the job. >... >> (5) Sections 6.9 and 8: I'd be a lot happier with this if >> there was a clear preference expressed for what the RFC Editor >> traditionally describes as a "stable specification", >> especially since IANA has seemingly gone out of the business >> of keeping library of documents submitted in support of >> registrations. That is expecially important given the formal >> non-archival status of I-Ds and the observation that >> "published document" doesn't have nearly as much meaning >> today as it might have had 20 or 30 years ago. If you/we >> really want to allow I-Ds, I recommend "Any Internet-Draft, >> RFC, specification, or other stable document..." in 6.9 > > I suggest: > > OLD > A pointer to an Internet-Draft, RFC, non-IETF > specification, or other > published document that provides further information about > the > namespace. > > NEW > A pointer to an RFC, a specification published by another > standards > development organization, or another stable document that > provides > further information about the namespace. wfm >... >> I think the intent of that sentence in Section 8 might be a >> bit more clear if it said "...experts for NID registration >> requests should strongly encourage applicants to provide a >> stable specification that documents...". > > Agreed. We'd in general do well to avoid the passive voice. > > Thus... > > OLD > although the registration policy for formal namespaces is > Expert > Review and a specification is not required, the designated > experts > for NID registration requests are encouraged to prefer > that a > specification exist documenting the namespace definition. > > NEW > although the registration policy for formal namespaces is > Expert > Review and stable a specification is not strictly > required, the > designated experts for NID registration requests ought to > encourage > applicants to provide a stable specification documenting > the > namespace definition. s/stable a/a stable/ And I dislike playing games with "ought to" to avoid saying "should" (or "SHOULD") -- just very clumsy English, IMO. But my name isn't at the top of this one, so suit yourself. >... john From stpeter@stpeter.im Tue Feb 11 18:07:47 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB701A07C6 for ; Tue, 11 Feb 2014 18:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ItarcnXn8PND for ; Tue, 11 Feb 2014 18:07:46 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E7A251A0768 for ; Tue, 11 Feb 2014 18:07:45 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A6508403C4; Tue, 11 Feb 2014 19:07:44 -0700 (MST) Message-ID: <52FAD76F.7070100@stpeter.im> Date: Tue, 11 Feb 2014 19:07:43 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: John C Klensin References: <8CE245D723DEE2BB953F028F@JcK-HP8200.jck.com> <52FA8416.8030400@stpeter.im> <52FA9305.5070803@stpeter.im> <4E5C487D7BB59C1426A82717@JCK-EEE10> In-Reply-To: <4E5C487D7BB59C1426A82717@JCK-EEE10> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] appeals X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 02:07:48 -0000 On 2/11/14, 1:52 PM, John C Klensin wrote: > > > --On Tuesday, 11 February, 2014 14:15 -0700 Peter Saint-Andre > wrote: > >> On 2/11/14, 1:12 PM, Peter Saint-Andre wrote: >>> On 1/21/14, 11:54 PM, John C Klensin wrote: >>> >>>> (6) Section 7.1, item 4: It seems to me that this allows a >>>> possibility in which the designated experts simply refuse to >>>> approve and application, perhaps by engaging in never-ending >>>> nitpicking. Do we need an appeal procedure? >>> >>> Maybe. Let's discuss that a bit more on the list here. >> >> Is the appeals process perhaps covered by Section 7 of RFC >> 5226, which in turn references Section 6.5 of RFC 2026? >> >> Or would we prefer something a bit less heavy? > > It seems to me that it would be useful to devise some sort of > mediation process in which experts with different perspectives > could examine things as a group. The difficulty with > 2026-style appeals processes and URNs is that, as we have seen > in this WG, there may be fundamental differences in perspective > and assumptions among experts and those who think they are. > There is no particular reason to believe that the IESG, as a > group and long term, will have the expertise needed to > facilitate a useful discussion, much less be able to reach > conclusions/ judgments that everyone will trust and accept. > > On the other hand, I don't know whether this WG has the > expertise or energy needed to devise such a system. True. Perhaps we can say something like this: Naming can be difficult and contentious. Therefore the designated experts and applicants ought to work together in a spirit of good faith and mutual understanding to achieve rough consensus on progressing registrations through the process. I know, it sounds like "motherhood and apple pie", but it might be the best we can do. Peter -- Peter Saint-Andre https://stpeter.im/ From john-ietf@jck.com Tue Feb 11 21:23:11 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84BF1A0844 for ; Tue, 11 Feb 2014 21:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham 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 Rm3vY8aMjEoJ for ; Tue, 11 Feb 2014 21:23:09 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9301E1A0840 for ; Tue, 11 Feb 2014 21:23:02 -0800 (PST) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1WDSHF-0000Nl-7v; Wed, 12 Feb 2014 00:22:30 -0500 Date: Wed, 12 Feb 2014 00:22:23 -0500 From: John C Klensin To: Peter Saint-Andre Message-ID: <81E472654F6A09C2FEBF7364@JCK-EEE10> In-Reply-To: <52FAD76F.7070100@stpeter.im> References: <8CE245D723DEE2BB953F028F@JcK-HP8200.jck.com> <52FA8416.8030400@stpeter.im> <52FA9305.5070803@stpeter.im> <4E5C487D7BB59C1426A82717@JCK-EEE10> <52FAD76F.7070100@stpeter.im> 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 Cc: urn@ietf.org Subject: Re: [urn] appeals X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 05:23:12 -0000 --On Tuesday, 11 February, 2014 19:07 -0700 Peter Saint-Andre wrote: >... >... >> On the other hand, I don't know whether this WG has the >> expertise or energy needed to devise such a system. > > True. > > Perhaps we can say something like this: > > Naming can be difficult and contentious. Therefore the > designated experts and applicants ought to work together > in a spirit of good faith and mutual understanding to > achieve rough consensus on progressing registrations > through the process. > > I know, it sounds like "motherhood and apple pie", but it > might be the best we can do. Yes. How about adding an addition sentence which actually doesn't say much more but may convey the spirit a little better: "They are encouraged to bring additional expertise into the discussion if that would be helpful in adding perspective or otherwise resolving issues." Does that help? john From juha.hakala@helsinki.fi Wed Feb 12 00:55:34 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA041A08DE for ; Wed, 12 Feb 2014 00:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 gsnEn75vMy0Q for ; Wed, 12 Feb 2014 00:55:31 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4711A08CF for ; Wed, 12 Feb 2014 00:55:28 -0800 (PST) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s1C8tNFM011363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 12 Feb 2014 10:55:26 +0200 Message-ID: <52FB36FB.4010800@helsinki.fi> Date: Wed, 12 Feb 2014 10:55:23 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: urn@ietf.org References: <8CE245D723DEE2BB953F028F@JcK-HP8200.jck.com> <52FA8416.8030400@stpeter.im> <52FA9305.5070803@stpeter.im> <4E5C487D7BB59C1426A82717@JCK-EEE10> <52FAD76F.7070100@stpeter.im> <81E472654F6A09C2FEBF7364@JCK-EEE10> In-Reply-To: <81E472654F6A09C2FEBF7364@JCK-EEE10> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [urn] appeals X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 08:55:35 -0000 Hello, The current 3406bis says: > A formal namespace registration can be revised by updating the > registration template, following the same steps outlined above for > new registrations. Can we add something to the effect that if a URN namespace is based on existing identifier specification, the registration should be revised when a new version of that specification is published, especially if the revision changes the purpose, syntax of the assignment process of the identifier. An example of this is the on-going revision of the ISRC (International Standard Recording Code); if there were an ISRC namespace, it would be necessary to update the registration of it since the ISRC assignment process will change radically (although the purpose and syntax of ISRC remain the same). Is it necessary to always follow exactly the procedure outlined in 7.1 when a namespace is revised? We might allow the applicants to describe just the novel features (for instance, it may happen that just the registrant changes). This would make the life easier both for the registrants and the reviewers. A detail about 7.1: would it be better to say just "review" in step 2, instead of "technical review". The latter wording might give some people a wrong impression that non-technical information supplied in the registration request will not have an impact on the outcome of the review process. On 12.2.2014 7:22, John C Klensin wrote: > > --On Tuesday, 11 February, 2014 19:07 -0700 Peter Saint-Andre > wrote: > > >> Perhaps we can say something like this: Naming can be difficult and >> contentious. Therefore the designated experts and applicants ought to >> work together in a spirit of good faith and mutual understanding to >> achieve rough consensus on progressing registrations through the >> process. I know, it sounds like "motherhood and apple pie", but it >> might be the best we can do. > Yes. How about adding an addition sentence which actually > doesn't say much more but may convey the spirit a little better: > > "They are encouraged to bring additional expertise into > the discussion if that would be helpful in adding > perspective or otherwise resolving issues." > > Does that help? Yes, this will do for me. And I don't think that it is necessary / useful to go beyond this in rfc3406bis. It is important to make the namespace registration process as simple as possible, but not simpler. If registration process is considered to be too complicated, the risk that some communities invent their own namespaces (which is not discussed in the security considerations section of the 3406bis for the time being) may increase. On the other hand, the reviewers should have all the relevant information available. Juha > john > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From stpeter@stpeter.im Wed Feb 12 05:50:51 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540781A02C6 for ; Wed, 12 Feb 2014 05:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 LNsobgDHY7Oc for ; Wed, 12 Feb 2014 05:50:49 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC4F1A0238 for ; Wed, 12 Feb 2014 05:50:49 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B2C7F40410; Wed, 12 Feb 2014 06:50:47 -0700 (MST) Message-ID: <52FB7C36.5010500@stpeter.im> Date: Wed, 12 Feb 2014 06:50:46 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: John C Klensin References: <8CE245D723DEE2BB953F028F@JcK-HP8200.jck.com> <52FA8416.8030400@stpeter.im> <52FA9305.5070803@stpeter.im> <4E5C487D7BB59C1426A82717@JCK-EEE10> <52FAD76F.7070100@stpeter.im> <81E472654F6A09C2FEBF7364@JCK-EEE10> In-Reply-To: <81E472654F6A09C2FEBF7364@JCK-EEE10> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: urn@ietf.org Subject: Re: [urn] appeals X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 13:50:51 -0000 On 2/11/14, 10:22 PM, John C Klensin wrote: > > > --On Tuesday, 11 February, 2014 19:07 -0700 Peter Saint-Andre > wrote: > >> ... >> ... >>> On the other hand, I don't know whether this WG has the >>> expertise or energy needed to devise such a system. >> >> True. >> >> Perhaps we can say something like this: >> >> Naming can be difficult and contentious. Therefore the >> designated experts and applicants ought to work together >> in a spirit of good faith and mutual understanding to >> achieve rough consensus on progressing registrations >> through the process. >> >> I know, it sounds like "motherhood and apple pie", but it >> might be the best we can do. > > Yes. How about adding an addition sentence which actually > doesn't say much more but may convey the spirit a little better: > > "They are encouraged to bring additional expertise into > the discussion if that would be helpful in adding > perspective or otherwise resolving issues." Works for me. In my working copy I now have: Naming can be difficult and contentious; the designated experts and applicants are strongly encouraged to work together in a spirit of good faith and mutual understanding to achieve rough consensus on progressing registrations through the process. They are also encouraged to bring additional expertise into the discussion if that would be helpful in adding perspective or otherwise resolving issues. By the way, this is a new paragraph in Section 8. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Feb 12 05:56:26 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56761A0990 for ; Wed, 12 Feb 2014 05:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 hhFY-KdO41cl for ; Wed, 12 Feb 2014 05:56:25 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 61F7F1A0185 for ; Wed, 12 Feb 2014 05:56:25 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 961F940410; Wed, 12 Feb 2014 06:56:24 -0700 (MST) Message-ID: <52FB7D87.7000805@stpeter.im> Date: Wed, 12 Feb 2014 06:56:23 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Juha Hakala , urn@ietf.org References: <8CE245D723DEE2BB953F028F@JcK-HP8200.jck.com> <52FA8416.8030400@stpeter.im> <52FA9305.5070803@stpeter.im> <4E5C487D7BB59C1426A82717@JCK-EEE10> <52FAD76F.7070100@stpeter.im> <81E472654F6A09C2FEBF7364@JCK-EEE10> <52FB36FB.4010800@helsinki.fi> In-Reply-To: <52FB36FB.4010800@helsinki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [urn] appeals X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 13:56:27 -0000 Hi Juha, On 2/12/14, 1:55 AM, Juha Hakala wrote: > Hello, > > The current 3406bis says: > >> A formal namespace registration can be revised by updating the >> registration template, following the same steps outlined above for >> new registrations. > > Can we add something to the effect that if a URN namespace is based on > existing identifier specification, the registration should be revised > when a new version of that specification is published, especially if the > revision changes the purpose, syntax of the assignment process of the > identifier. An example of this is the on-going revision of the ISRC > (International Standard Recording Code); if there were an ISRC > namespace, it would be necessary to update the registration of it since > the ISRC assignment process will change radically (although the purpose > and syntax of ISRC remain the same). > > Is it necessary to always follow exactly the procedure outlined in 7.1 > when a namespace is revised? We might allow the applicants to describe > just the novel features (for instance, it may happen that just the > registrant changes). This would make the life easier both for the > registrants and the reviewers. That's a good point. How about this? OLD A formal namespace registration can be revised by updating the registration template, following the same steps outlined above for new registrations NEW A formal namespace registration can be revised by updating the registration template, following the same steps outlined above for new registrations. A revised registration should making special note of any relevant changes in the underlying technologies or namespace management processes. I'm not comfortable with saying that a revised registration can describe only the novel features, but in my opinion it should be rather easy to modify the old registration request -- it's not as if the registrant needs to write the whole thing again anew. > A detail about 7.1: would it be better to say just "review" in step 2, > instead of "technical review". The latter wording might give some people > a wrong impression that non-technical information supplied in the > registration request will not have an impact on the outcome of the > review process. Yes, agreed. Thanks for your feedback. Peter From internet-drafts@ietf.org Wed Feb 12 05:59:23 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBE41A0185; Wed, 12 Feb 2014 05:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 n_UG_23s7fFn; Wed, 12 Feb 2014 05:59:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 993E21A0993; Wed, 12 Feb 2014 05:59:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140212135921.19239.95109.idtracker@ietfa.amsl.com> Date: Wed, 12 Feb 2014 05:59:21 -0800 Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-09.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 13:59:23 -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 Working Group of the IETF. Title : Uniform Resource Name (URN) Namespace Definition Mechanisms Author : Peter Saint-Andre Filename : draft-ietf-urnbis-rfc3406bis-urn-ns-reg-09.txt Pages : 14 Date : 2014-02-12 Abstract: This document supplements the Uniform Resource Name (URN) syntax specification by defining the concept of a URN namespace, as well as mechanisms for defining and registering such namespaces. This document obsoletes RFC 3406. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc3406bis-urn-ns-reg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc3406bis-urn-ns-reg-09 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 stpeter@stpeter.im Wed Feb 12 06:00:24 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E9C1A099F for ; Wed, 12 Feb 2014 06:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 om04g8eWl7Xx for ; Wed, 12 Feb 2014 06:00:18 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 97CFE1A09A2 for ; Wed, 12 Feb 2014 06:00:06 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E622440410; Wed, 12 Feb 2014 07:00:05 -0700 (MST) Message-ID: <52FB7E64.4000503@stpeter.im> Date: Wed, 12 Feb 2014 07:00:04 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: urn@ietf.org References: <20140212135921.19239.95109.idtracker@ietfa.amsl.com> In-Reply-To: <20140212135921.19239.95109.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-09.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 14:00:24 -0000 Updated to reflect recent feedback from John and Juha. On 2/12/14, 6:59 AM, 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 Working Group of the IETF. > > Title : Uniform Resource Name (URN) Namespace Definition Mechanisms > Author : Peter Saint-Andre > Filename : draft-ietf-urnbis-rfc3406bis-urn-ns-reg-09.txt > Pages : 14 > Date : 2014-02-12 > > Abstract: > This document supplements the Uniform Resource Name (URN) syntax > specification by defining the concept of a URN namespace, as well as > mechanisms for defining and registering such namespaces. This > document obsoletes RFC 3406. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc3406bis-urn-ns-reg/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-09 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc3406bis-urn-ns-reg-09 > > > 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 stpeter@stpeter.im Wed Feb 12 08:10:56 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E149B1A040E for ; Wed, 12 Feb 2014 08:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 E0ixcuMLeGPA for ; Wed, 12 Feb 2014 08:10:54 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 27A9F1A047A for ; Wed, 12 Feb 2014 08:10:54 -0800 (PST) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CE2FE40410; Wed, 12 Feb 2014 09:10:52 -0700 (MST) Message-ID: <52FB9D0C.3070508@stpeter.im> Date: Wed, 12 Feb 2014 09:10:52 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: urn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [urn] editorial comments on draft-ietf-urnbis-ns-reg-transition-01 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 16:10:57 -0000 Thanks to John and Juha for working on this document. Overall I think the substance is fine. Here are a few small editorial issues I noticed. 1. Expand URN on first use: As a part of the initial development of the Uniform Resource Name (URN) system... 2. This is a bit awkward: model that focuses more on attempting to get all namespaces that follow the syntax of formal ones registered I suggest: model that focuses more on encouraging registration of all namespaces that follow the formal namespace syntax 3. There's a stray word here: collected as a possible consistent with that goal Should be: collected as possible consistent with that goal 4. A missing and: [RFC3044], International Standard Book Numbers (ISBNs) [RFC3187] Should be: [RFC3044] and International Standard Book Numbers (ISBNs) [RFC3187] 5. This text might be slightly ambiguous: For both ISSN and ISBN URNs, it is intended that the registrations track the evolution of ISO standardization without requiring resubmission of the templates or other formal IETF or IANA registration update approval procedures. I assume that refers to the current registrations, not any future registrations. 6. This is a bit of a run-on sentence: The revised ISBN namespace reflects the updated version of the ISO Standard for ISBNs, ISO 2108:2005 [ISO-ISBN-b] and allows for the use of both the ten character numbers described in RFC 3187 and the earlier ISO 2108:1992 [ISO-ISBN-a] (known as ISBN-10) and the expanded ones of the revised standard (known as ISBN-13). Perhaps: The revised ISBN namespace reflects the updated version of the ISO Standard for ISBNs, ISO 2108:2005 [ISO-ISBN-b]. The namespace allows for the use of both the ten character numbers described in RFC 3187 and the earlier ISO 2108:1992 [ISO-ISBN-a] (known as ISBN-10), as well as the expanded ones of the revised standard (known as ISBN-13). 7. Typo here: IANA is requested to update the registry entries for URN ISSNs, ISBNs, and NRNs I assume that "NBNs" is meant instead of "NRNs". 8. I sense some ambiguity here: IANA is requested to update the registry entries for URN ISSNs, ISBNs, and NRNs to reflect the new, RFC 3406bis-complaint templates as soon as they are available and to no longer reference the now- historic RFCs. Other registrations and templates conforming to the newer rules may be substituted for the older ones when they are available. However, neither this document nor RFC 3406bis invalidates existing registrations other than those listed above, so IANA needs to be prepared to maintain a registry whose contents reflect both old and new templates. I think "other registrations and templates" might be referring to registrations and templates for namespaces other than ISSN, ISBN, and NBN. I think "supersedes" might be more appropriate than "invalidates". And I think "a registry whose contents reflect both old and new templates" does not imply that IANA would point to both an old and a new template for the same namespace, but for different namespaces. Thus I suggest: IANA is requested to update the registry entries for URN ISSNs, ISBNs, and NBNs to reflect the new, RFC 3406bis-complaint templates as soon as they are available and to no longer reference the now- historic RFCs for those namespaces. With respect to namespaces other than those listed above, registrations and templates conforming to the newer rules may be substituted for the older ones when they are available. However, neither this document nor RFC 3406bis supersedes existing registrations other than those listed above. Therefore, IANA needs to be prepared to maintain a registry whose contents reflect old templates for some namespaces and new templates for other namespaces. Peter -- Peter Saint-Andre https://stpeter.im/ From juha.hakala@helsinki.fi Wed Feb 12 22:52:03 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF271A011A for ; Wed, 12 Feb 2014 22:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 JsEY7KsPBuV6 for ; Wed, 12 Feb 2014 22:52:01 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF7D1A010F for ; Wed, 12 Feb 2014 22:51:59 -0800 (PST) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s1D6ptJ0025477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Feb 2014 08:51:57 +0200 Message-ID: <52FC6B8B.1050404@helsinki.fi> Date: Thu, 13 Feb 2014 08:51:55 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Peter Saint-Andre , urn@ietf.org References: <8CE245D723DEE2BB953F028F@JcK-HP8200.jck.com> <52FA8416.8030400@stpeter.im> <52FA9305.5070803@stpeter.im> <4E5C487D7BB59C1426A82717@JCK-EEE10> <52FAD76F.7070100@stpeter.im> <81E472654F6A09C2FEBF7364@JCK-EEE10> <52FB36FB.4010800@helsinki.fi> <52FB7D87.7000805@stpeter.im> In-Reply-To: <52FB7D87.7000805@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [urn] appeals X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 06:52:04 -0000 Hi Peter, On 12.2.2014 15:56, Peter Saint-Andre wrote: > > OLD > A formal namespace registration can be revised by updating the > registration template, following the same steps outlined above for > new registrations > > NEW > A formal namespace registration can be revised by updating the > registration template, following the same steps outlined above for > new registrations. A revised registration should making special note > of any relevant changes in the underlying technologies or namespace > management processes. With the exception of "should making" the new formulation looks fine to me. > > I'm not comfortable with saying that a revised registration can > describe only the novel features, but in my opinion it should be > rather easy to modify the old registration request -- it's not as if > the registrant needs to write the whole thing again anew. OK. I have just one more comment: in chapter 8 we might make it more clear that different namespaces may have very different level of administration. The current wording gives an impression that we expect some level of uniformity and that there has to be a clearly formulated "contract" with the intended user community. While this may be true for some existing namespaces, there are other namespaces where both the intended user community and the "contract" are not and cannot be clearly specified. Juha -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Fri Feb 14 16:03:31 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230D51A050C for ; Fri, 14 Feb 2014 16:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 EO-mwYXUi_SK for ; Fri, 14 Feb 2014 16:03:28 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 65BE71A050B for ; Fri, 14 Feb 2014 16:03:28 -0800 (PST) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 579784010C; Fri, 14 Feb 2014 17:03:26 -0700 (MST) Message-ID: <52FEAECD.9040107@stpeter.im> Date: Fri, 14 Feb 2014 17:03:25 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Juha Hakala , urn@ietf.org References: <8CE245D723DEE2BB953F028F@JcK-HP8200.jck.com> <52FA8416.8030400@stpeter.im> <52FA9305.5070803@stpeter.im> <4E5C487D7BB59C1426A82717@JCK-EEE10> <52FAD76F.7070100@stpeter.im> <81E472654F6A09C2FEBF7364@JCK-EEE10> <52FB36FB.4010800@helsinki.fi> <52FB7D87.7000805@stpeter.im> <52FC6B8B.1050404@helsinki.fi> In-Reply-To: <52FC6B8B.1050404@helsinki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/xfvahwmv8s8FK1WTUK5CA-2EPqE Subject: Re: [urn] appeals X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 00:03:30 -0000 On 2/12/14, 11:51 PM, Juha Hakala wrote: > Hi Peter, > > On 12.2.2014 15:56, Peter Saint-Andre wrote: > >> >> OLD >> A formal namespace registration can be revised by updating the >> registration template, following the same steps outlined above for >> new registrations >> >> NEW >> A formal namespace registration can be revised by updating the >> registration template, following the same steps outlined above for >> new registrations. A revised registration should making special note >> of any relevant changes in the underlying technologies or namespace >> management processes. > > With the exception of "should making" the new formulation looks fine to me. Noted. >> I'm not comfortable with saying that a revised registration can >> describe only the novel features, but in my opinion it should be >> rather easy to modify the old registration request -- it's not as if >> the registrant needs to write the whole thing again anew. > > OK. > > I have just one more comment: in chapter 8 we might make it more clear > that different namespaces may have very different level of > administration. The current wording gives an impression that we expect > some level of uniformity and that there has to be a clearly formulated > "contract" with the intended user community. While this may be true for > some existing namespaces, there are other namespaces where both the > intended user community and the "contract" are not and cannot be clearly > specified. I *think* that makes sense. Perhaps we could at least try to describe when we expect a certain level of service, and when we don't? Peter -- Peter Saint-Andre https://stpeter.im/ From nobody Mon Feb 24 06:01:02 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8C31A008D for ; Mon, 24 Feb 2014 06:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.852 X-Spam-Level: X-Spam-Status: No, score=0.852 tagged_above=-999 required=5 tests=[BAYES_99=3.5, BAYES_999=0.2, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=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 J4DcktkCD8JZ for ; Mon, 24 Feb 2014 06:00:49 -0800 (PST) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC391A063C for ; Mon, 24 Feb 2014 06:00:36 -0800 (PST) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s1OE0WwS008228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 24 Feb 2014 16:00:34 +0200 Message-ID: <530B5080.7020204@helsinki.fi> Date: Mon, 24 Feb 2014 16:00:32 +0200 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Peter Saint-Andre , urn@ietf.org References: <8CE245D723DEE2BB953F028F@JcK-HP8200.jck.com> <52FA8416.8030400@stpeter.im> <52FA9305.5070803@stpeter.im> <4E5C487D7BB59C1426A82717@JCK-EEE10> <52FAD76F.7070100@stpeter.im> <81E472654F6A09C2FEBF7364@JCK-EEE10> <52FB36FB.4010800@helsinki.fi> <52FB7D87.7000805@stpeter.im> <52FC6B8B.1050404@helsinki.fi> <52FEAECD.9040107@stpeter.im> In-Reply-To: <52FEAECD.9040107@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/bT5NRI0brJ0j4-XKEErVDSSn7x8 Subject: Re: [urn] appeals X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 14:00:52 -0000 Hello, On 15.2.2014 2:03, Peter Saint-Andre wrote: > On 2/12/14, 11:51 PM, Juha Hakala wrote: >> >> I have just one more comment: in chapter 8 we might make it more clear >> that different namespaces may have very different level of >> administration. The current wording gives an impression that we expect >> some level of uniformity and that there has to be a clearly formulated >> "contract" with the intended user community. While this may be true for >> some existing namespaces, there are other namespaces where both the >> intended user community and the "contract" are not and cannot be clearly >> specified. > > I *think* that makes sense. Perhaps we could at least try to describe > when we expect a certain level of service, and when we don't? We may claim that if a namespace is based on an established (standard) identifier, there may be a well specified process of identifier assignment, and an organization (international center, supported by national / regional centers) which is overseeing the work. If there is no such administrative infrastructure, users of the identifier may not get much external support. Some other PID communities make it clear that the level of administration may also have a major impact on longevity / reliability of the identifier. So the most significant difference between Handle and DOI is that the latter is better administered. Within the URN system similar differences will exist between namespaces. IMO it is important to make it clear that we have not and we do not intend to specify - at least in any level of detail - the minimum level of administration required. Juha -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Fri Feb 28 12:14:59 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE311A0286 for ; Fri, 28 Feb 2014 12:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.447 X-Spam-Level: X-Spam-Status: No, score=-0.447 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] autolearn=ham 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 WftFj8tS1GMF for ; Fri, 28 Feb 2014 12:14:51 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id D7FC91A030A for ; Fri, 28 Feb 2014 12:14:48 -0800 (PST) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1WJTpU-000PBz-BO; Fri, 28 Feb 2014 15:14:44 -0500 Date: Fri, 28 Feb 2014 15:14:18 -0500 From: John C Klensin To: Peter Saint-Andre , urn@ietf.org Message-ID: In-Reply-To: <52FB9D0C.3070508@stpeter.im> References: <52FB9D0C.3070508@stpeter.im> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/fXqP0zP8MuXTolEYQNh-jeuMkMU Subject: Re: [urn] editorial comments on draft-ietf-urnbis-ns-reg-transition-01 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 20:14:55 -0000 Hi. Having heard no comments about Peter's suggestions from the WG list, all have been incorporated except as noted below. The revised draft will be posted Monday (if I remember) but the difference between 01 and 02 will be only these changes, so, if you want to read something today, 01 is safe. There is, however, at least one question below to which a WG response it needed. If there seems to be a clear answer before Monday, I'll get it into the next draft (subject to revision and yet another I-D version if Andy tells me otherwise). Observation from a participant in this WGs who thinks the work is very important and who has some experience with how the IETF works, but no official role in the WG other than being willing to help with writing: When WG drafts are posted and met with dead silence (or silence except from an extremely small number of people, the usual IETF tendency is to assume that the WG is dead, no one cares, and that, if it produces any work, that work doesn't represent enough meaningful consensus to be moved forward. Barry has been extremely patient, I think because he shares my/our sense of importance, but I'm very concerned about how we move forward this way. This is especially important because a few of us have been thinking about a very radical move to get the various issues of syntax, properties of the name or named object versus things that can be done only after it is retrieved, and so on unstuck. That move would be, IMO, impossible without strong backing from the WG. Because just raising it would probably stir up a lot of controversy, I (at least) haven't even been willing to explain it on this mailing list. So, nay I ask (and recommend) that those of you who are reading drafts, saying "seems ok" to yourselves, and moving on start posting "I have read this and seems ok" (or "I have read it and it is hopeless" if that is that better reflects your views) notes to the list. And those of you who haven't been reading drafts should start soon -- the silence will kill us, if not by action from the IESG than by the authors giving up. Again, a few notes on Peter's comments below thanks, john --On Wednesday, February 12, 2014 09:10 -0700 Peter Saint-Andre wrote: > Thanks to John and Juha for working on this document. Overall > I think the substance is fine. Here are a few small editorial > issues I noticed. > > 1. Expand URN on first use: >... > 2. This is a bit awkward: >... > 3. There's a stray word here: >... > 4. A missing and: >... > 5. This text might be slightly ambiguous: > > For both ISSN and ISBN URNs, it is intended that the > registrations > track the evolution of ISO standardization without > requiring > resubmission of the templates or other formal IETF or IANA > registration update approval procedures. > > I assume that refers to the current registrations, not any > future registrations. Actually, I was trying to finesse a problem. This really needs input from you and the read of the WG. Let me keep it separate from the editorial issues by writing a separate note. > 6. This is a bit of a run-on sentence: >... > 7. Typo here: >... > 8. I sense some ambiguity here: > > IANA is requested to update the registry entries for URN > ISSNs, > ISBNs, and NRNs to reflect the new, RFC 3406bis-complaint > templates > as soon as they are available and to no longer reference > the now- > historic RFCs. Other registrations and templates > conforming to the > newer rules may be substituted for the older ones when > they are > available. However, neither this document nor RFC 3406bis > invalidates existing registrations other than those listed > above, so > IANA needs to be prepared to maintain a registry whose > contents > reflect both old and new templates. > > I think "other registrations and templates" might be referring > to registrations and templates for namespaces other than ISSN, > ISBN, and NBN. Yes. And it needed to spelled out a bit more even where it wasn't ambiguous. I've substituted your proposed sentence, which is probably good enough. Suggestions for less tedious wording are welcome. > I think "supersedes" might be more appropriate than > "invalidates". I really did mean "invalidate", partially because of aspects of the ongoing "obsoletes" versus "historic" debate. In addition, in theory this document or 3507bis could declare all existing registrations invalid without any superceding documentation or registration (in some sense, it does make tham obsolete because the information required is different). We've decided (I think) to not do that and I thought it was worth making explicit. But I've changed the word to "supercedes". It can be changed back if anyone feels strongly about it. > And I think "a registry whose contents reflect both old and > new templates" does not imply that IANA would point to both an > old and a new template for the same namespace, but for > different namespaces. One would hope that, in the former case, a new NID would be assigned. > Thus I suggest: > > IANA is requested to update the registry entries for URN > ISSNs, > ISBNs, and NBNs to reflect the new, RFC 3406bis-complaint > templates > as soon as they are available and to no longer reference > the now- > historic RFCs for those namespaces. With respect to > namespaces > other than those listed above, registrations and templates > conforming to the newer rules may be substituted for the > older ones > when they are available. However, neither this document > nor RFC > 3406bis supersedes existing registrations other than those > listed > above. Therefore, IANA needs to be prepared to maintain a > registry > whose contents reflect old templates for some namespaces > and new > templates for other namespaces. Smoothed a bit but basically incorporated. Thanks for the careful reading, john From nobody Fri Feb 28 12:15:58 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E923F1A0349 for ; Fri, 28 Feb 2014 12:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] autolearn=ham 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 UZW2IoIOa1oz for ; Fri, 28 Feb 2014 12:15:54 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id DB7551A0316 for ; Fri, 28 Feb 2014 12:15:50 -0800 (PST) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1WJTqW-000PCA-RB; Fri, 28 Feb 2014 15:15:48 -0500 Date: Fri, 28 Feb 2014 15:15:23 -0500 From: John C Klensin To: Peter Saint-Andre , urn@ietf.org Message-ID: <1B1D296F042C7A4C9A15F2E8@JcK-HP8200.jck.com> In-Reply-To: <52FB9D0C.3070508@stpeter.im> References: <52FB9D0C.3070508@stpeter.im> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/tnWdD9u2STYNHEufMNEzrJ65MDY Subject: [urn] ISSNs, ISBNs, and automatic definition upgrading (was: Re: editorial comments on draft-ietf-urnbis-ns-reg-transition-01) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 20:15:56 -0000 The other note I promised... --On Wednesday, February 12, 2014 09:10 -0700 Peter Saint-Andre wrote: > 5. This text might be slightly ambiguous: > > For both ISSN and ISBN URNs, it is intended that the > registrations > track the evolution of ISO standardization without > requiring > resubmission of the templates or other formal IETF or IANA > registration update approval procedures. > > I assume that refers to the current registrations, not any > future registrations. As I said, this needs WG thought and input. As we have seen with the revisions that specified the longer identifiers for ISBNs, these underlying ISO standards change. The good news is that, at least in my opinion, changes that would make older identifiers invalid are just not going to happen: they would be extremely disruptive and costly to a community that is very dependent on stability over periods the IETF has trouble thinking about. My instinct is to trust that and allow a registration that does not require revision or updating to move from one version of an underlying ISO standard for the identifier to another. The current reference version of the underlying standard, syntax, assignment rules, etc., are what ISO says they are with no IETF, Expert, or registrant action being required (even though I'm sure we would welcome explanatory updates). I don't know whether that generalizes beyond ISSNs and ISBNs (and, maybe, if the IAB decides to go in that direction, the ISO version of DOIs). We would certainly want to have a very serious discussion if someone wanted to register a URN namespace that was dependent on a possibly more volatile set of references. But, for this case, it makes sense to me and would eliminate possible uncertainties between the time an ISO standard is updated and published and when someone gets around to updating the URN registration. Experience leds me to hate those sorts of timing dependencies, especially when they can be avoided. So, two questions (I'll try to interpret the answers, but the decision about agreement, as I noted earlier, belongs to Andy): (1) Does the WG agree with my analysis and believe that having the registration based on the "current version" of the ISO standard, whatever that version is at a given time, is wise? (2) If so, how should this be said? Note that it might (or might now) require some tuning to 3507bis to get an explicit statement in the registration template as to whether the referenced external standard is the version as of some specific date (and/or version number) or whether it always follows the versions of the external standard as I'm suggesting here. thanks, john