idnits 2.17.1 draft-kalin-geant-urn-namespace-01.txt: -(58): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 377. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 348), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 348. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 11) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 33 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 46 has weird spacing: '... groups and...' == Line 68 has weird spacing: '... as top str...' == Line 69 has weird spacing: '...n these proje...' == Line 182 has weird spacing: '...ries of immed...' == Line 280 has weird spacing: '...esource with ...' == (1 more instance...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 3, 2006) is 6356 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2141 (ref. '1') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) ** Downref: Normative reference to an Informational RFC: RFC 3120 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 3121 (ref. '4') ** Obsolete normative reference: RFC 3406 (ref. '5') (Obsoleted by RFC 8141) -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 15 errors (**), 0 flaws (~~), 10 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T.Kalin 2 Internet-Draft DANTE 3 Expires: May 3 2007 M.Molina 4 DANTE 6 November 3, 2006 8 A URN Namespace for GEANT 9 draft-kalin-geant-urn-namespace-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 5, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). All Rights Reserved. 40 Abstract 42 This document describes a proposed URN (Uniform Resource Name) 43 namespace that would be managed by DANTE, representing European 44 Research and academic networks, for naming persistent resources 45 defined by GEANT, the Consortium of European R&E networks, its 46 projects, activities, working groups and other designated 47 subordinates. 49 1. Introduction and community considerations 51 The Consortium of European Academic and Research Networks (GEANT) 52 provides high-speed, high-quality network connectivity for education 53 institutions, universities, and research centres in Europe. The 54 network infrastructure is composed by several National Research and 55 Education Networks (NRENs) and their European-wide interconnection, 56 GEANT. The current network is G�ANT2 [6], and is the seventh gene- 57 ration of pan-European research and education network, successor to 58 the pan-European multi-gigabit research network G�ANT. DANTE [7] is a 59 UK based organization representing the members of the Consortium and 60 operating the GEANT2 Network. This cooperative work is mainly done in 61 the framework of EU funded projects. The biggest of such activities is 62 currently the GN2 project [6], started Sep 2004, that follows other 63 successful ones having evolved the European Networks for Research and 64 Education for almost two decades. It is expected that these activities 65 and the network evolution will continue to be supported by European 66 Union and all European Governments in the years to come, as the 67 existence of a state of the art network for Research in Europe is 68 viewed as top strategic importance by them. We will refer to the 69 organisation involved in these projects or benefiting from their 70 outcome as the "GEANT community". 72 The GEANT community produces many kinds of documents: specifications, 73 working drafts, project reports, schemas, stylesheets, etc. 74 The community wishes to provide global, distributed, persistent, 75 location-independent names for these resources. The Uniform Resource 76 Name (URN) variant of URIs meets these requirements. 78 The GEANT community and other GEANT-affiliated groups would benefit 79 from the GEANT URN proposal by having an easy, efficient way to 80 assign globally unique, persistent identifiers to resources that they 81 create. The nature of GEANT work is that it is carried out to serve 82 the needs of many communities of interest. A namespace 83 managed so as to facilitate the creation, registration and resolution 84 of unique, persistent identifiers would be of great value for GEANT, 85 its affiliates and the higher education community generally. 86 The possibility of fitting the naming needs under existing namespaces 87 has been considered, but the conclusion was that the number of the 88 activities and the size of the developers community is such that 89 creating a lot of (possibly uncoordinated) dependencies from other 90 namespaces is undesirable 92 The proposed URN namespace specification is for a formal namespace. 94 2. Specification Template 96 Namespace ID: 98 "geant" requested. 100 Registration Information: 102 Registration Version Number 1 104 Registration Date: 2006-03-21 106 Registrant of the namespace: 108 DANTE 109 ATTN: Maurizio Molina 110 City House 111 126 - 130 Hills Road 112 Cambridge CB2 1PQ 113 United Kingdom 114 Phone: +44 1223 371340 116 Contact: Tomaz Kalin 117 Affiliation: DANTE 118 City House 119 126 - 130 Hills Road 120 Cambridge CB2 1PQ 122 tomaz.kalin@dante.org.uk 123 Phone: +386 1 430 3055 125 Syntactic structure: 127 The Namespace Specific Strings (NSS) of all URNs assigned by 128 GEANT will conform to the syntax defined in section 2.2 of 129 RFC2141, "URN Syntax." [1] In addition, all GEANT URN NSSs will 130 consist of a left-to-right series of tokens delimited by 131 colons. The left-to-right sequence of colon-delimited tokens 132 corresponds to descending nodes in a tree. To the right of the 133 lowest naming authority node there may be zero, one or more 134 levels of hierarchical naming nodes terminating in a rightmost 135 leaf node. See the section entitled "Identifier assignment" 136 below for more on the semantics of NSSs. This syntax 137 convention is captured in the following normative ABNF rules 138 for GEANT NSSs (see RFC2234): [2] 140 GEANT-NSS = 1*(subStChar) 0*(":" 1*(subStChar)) 142 subStChar = trans / "%" HEXDIG HEXDIG 144 trans = ALPHA / DIGIT / other / reserved 146 other = "(" / ")" / "+" / "," / "-" / "." / 148 "=" / "@" / ";" / "$" / 150 "_" / "!" / "*" / "'" 152 reserved = "%" / "/" / "?" / "#" 154 The exclusion of the colon from the list of "other" characters 155 means that the colon can only occur as a delimiter between 156 string tokens. Note that this ABNF rule set guarantees that 157 any valid GEANT NSS is also a valid RFC2141 NSS. 159 Relevant ancillary documentation: 161 None. 163 Identifier uniqueness: 165 It is the responsibility of DANTE to guarantee 166 uniqueness of the names of immediately subordinate naming 167 authorities. Each lower-level naming authority in turn 168 inherits the responsibility of guaranteeing uniqueness of names 169 in their branch of the naming tree. 171 Identifier persistence: 173 DANTE bears ultimate responsibility for maintaining 174 the usability of GEANT urns over time. This responsibility may 175 be delegated to subordinate naming authorities per the 176 discussion in the section below on identifier assignment. That 177 section provides a mechanism for the delegation to be revoked 178 in the case a subordinate naming authority ceases to function. 180 Identifier assignment: 182 DANTE will create an initial series of immediately 183 subordinate naming authorities, and will define a process for 184 adding to that list of authorities. Each top-level working 185 group of GEANT will be invited to designate a naming authority 186 and to suggest one or more candidate names. 188 Institutions and communities affiliated with GEANT may request, 189 through their designated GEANT liaison, that they be granted 190 GEANT-subordinate naming authority status. They may propose 191 candidate names for that authority. One way for such entities 192 to guarantee uniqueness of their proposed name is to base it on 193 a DNS name. That is, if e.g. the German National Research and 194 Education Network wished to be designated a subordinate naming 195 authority under GEANT, the institutional GEANT liaison could 196 propose to DANTE to be delegated control over names beginning 197 with, "urn:geant:dfn.de." Institutions seeking affiliation 198 with GEANT should send email to geant-submit@dante.org.uk, 199 nominating an institutional liaison and providing contact 200 information for that person. 202 On at least an annual basis, DANTE will contact the 203 liaisons or directors of each immediately subordinate naming 204 authority. If there is no response, or if the respondent 205 indicates that they wish to relinquish naming authority, the 206 authority over that branch of the tree reverts to GEANT. This 207 process will be enforced recursively by each naming authority 208 on its subordinates. This process guarantees that 209 responsibility for each branch of the tree will lapse for less 210 than one year at worst before being reclaimed by a superior 211 authority. 213 Lexical equivalence of two GEANT namespace specific strings 214 (NSSs) is defined below as an exact, case-sensitive string 215 match. DANTE will assign names of immediately subordinate 216 naming authorities in lower case only. This forestalls the 217 registration of two GEANT-subordinate naming authorities whose 218 names differ only in case. 220 Identifier resolution: 222 DANTE will maintain an index of all GEANT and GEANT 223 workgroup assigned URNs on its web site, 224 http://www.dante.net/urn-geant/urn-geant.html. 225 That index will map URNs to resource identifiers, usually URLs. 226 GEANT- affiliated naming authorities will specify how to 227 resolve the URNs they assign if they are resolvable. 229 Lexical equivalence: 231 Lexical equivalence of two GEANT namespace specific strings 232 (NSSs) is defined as an exact, case-sensitive string match. 234 Conformance with URN syntax: 236 All GEANT NSSs fully conform to RFC2141 syntax rules for NSSs. 238 Validation mechanism: 240 As specified in the "Identifier resolution" section above, 241 DANTE will maintain an index of all GEANT and GEANT 242 workgroup assigned URNs on its web site, 243 http://www.dante.net/urn-geant/urn-geant.html 244 Presence in that index implies that a given URN is valid. 245 GEANT-affiliated naming authorities will specify how to validate 246 the URNs they assign. 248 Scope: 250 Global. 252 3. Security Considerations 254 There are no additional security considerations beyond those normally 255 associated with the use and resolution of URNs in general. 257 4. Namespace Considerations 259 Registration of an NID specific to GEANT is reasonable given the 260 following considerations: 262 1. GEANT would like to assign URNs to some very fine-grained objects 263 This does not seem to be the primary intended use of the XMLORG 264 namespace (RFC3120) [3], or the more tightly controlled OASIS 265 namespace (RFC 3121) [4]. 267 2. GEANT seeks naming autonomy. GEANT is not a member of OASIS, so 268 becoming a subordinate naming authority under the OASIS URN space 269 is not an option. 271 3. GEANT will want to assign URNs to non-XML objects as well. That 272 is another reason that XMLORG may not be an appropriate higher-level 273 naming authority for GEANT. 275 Some GEANT-developed schema and namespaces may be good candidates for 276 inclusion in the XMLORG or possible future "EU" registry. The 277 fact that such an object might already have a GEANT-assigned URN 278 shouldn't be a hindrance. Work in progress to update RFC2611 [5] 279 includes an explicit statement that two or more URNs may point to the 280 same resource. A resource with a GEANT-assigned 281 namespace-specific-string would, of course, be given an XMLORG or EU 282 namespace-specific-string as it enters the XMLORG or "EU" registry. 284 5. Community Considerations 286 The assignment and use of identifiers within the namespace are open, 287 and the related rule is established by DANTE. Registration agencies - 288 the next level naming authorities will be the European National Research 289 and Education Networks and the established organizational cross-border 290 formations. 292 It is expected that the majority of the NRENs and all GEANT base activities 293 make use of the GEANT namespace. 295 After the establishment of the GEANT namespace the consortium will, as soon 296 as practical, establish a resolution service (analogously to other 297 distributed pan - European services, like EduROAM, PerfSONAR, etc) for 298 the namespace clients. 300 6. IANA Considerations 302 This document is intended as a formal request to IANA for the 303 registration of a "GEANT" NID within the IANA registry of URN NIDs. 305 References 307 [1] Moats, R., "URN Syntax", RFC 2141, May 1997. 309 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 310 Specifications: ABNF", RFC 2234, November 1997. 312 [3] Best, K. and N. Walsh, "A URN Namespace for XML.org", RFC 3120, 313 June 2001. 315 [4] Best, K. and N. Walsh, "A URN Namespace for OASIS", RFC 3121, 316 June 2001. 318 [5] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, "URN 319 Namespace Definition Mechanisms", RFC 3406, October 2002. 321 [6] G�ANT2 project's website http://www.geant2.net/ 323 [7] DANTE's company website http://www.dante.net/ 325 Authors' Addresses 327 T. Kalin 328 c/o DANTE 329 City House 330 126 - 130 Hills Road 331 Cambridge 332 CB2 1PQ 333 Unired Kingdom 335 EMail: tomaz.kalin@dante.org.uk 337 Maurizio Molina 338 City House 339 126 - 130 Hills Road 340 Cambridge 341 CB2 1PQ 342 United Kingdom 344 EMail: maurizio.molina@dante.org.uk 346 Full Copyright Statement 348 Copyright (C) The Internet Society (2006). All Rights Reserved. 350 This document and translations of it may be copied and furnished to 351 others, and derivative works that comment on or otherwise explain it 352 or assist in its implementation may be prepared, copied, published 353 and distributed, in whole or in part, without restriction of any 354 kind, provided that the above copyright notice and this paragraph are 355 included on all such copies and derivative works. However, this 356 document itself may not be modified in any way, such as by removing 357 the copyright notice or references to the Internet Society or other 358 Internet organizations, except as needed for the purpose of 359 developing Internet standards in which case the procedures for 360 copyrights defined in the Internet Standards process must be 361 followed, or as required to translate it into languages other than 362 English. 364 The limited permissions granted above are perpetual and will not be 365 revoked by the Internet Society or its successors or assigns. 367 This document is subject to the rights, licenses and restrictions 368 contained in BCP 78, and except as set forth therein, the authors 369 retain all their rights." 371 This document and the information contained herein are provided on 372 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 373 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 374 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 375 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 376 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 377 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 379 Acknowledgement 381 Funding for the RFC Editor function is currently provided by the 382 Internet Society.