Skip to main content

A Uniform Resource Name (URN) Namespace for Sources of Law (LEX)
draft-spinosa-urn-lex-21

Revision differences

Document history

Date Rev. By Action
2024-03-18
21 Eliot Lear Tag Revised I-D Needed set.
2024-02-16
21 Cindy Morgan ISE state changed to In ISE Review::IESG Review Completed from In IESG Review
2024-02-12
21 Amanda Baber IANA Experts State changed to Expert Reviews OK from Reviews assigned
2024-02-12
21 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2024-01-31
21 Murray Kucherawy Shepherding AD changed to Murray Kucherawy
2024-01-02
21 Amanda Baber
(Via drafts-eval@iana.org): IESG/Authors/ISE:

IANA will need the authors to take action before we can complete the registrations for draft-spinosa-urn-lex-21. It should also be noted …
(Via drafts-eval@iana.org): IESG/Authors/ISE:

IANA will need the authors to take action before we can complete the registrations for draft-spinosa-urn-lex-21. It should also be noted that the public mailing lists meant to review those registrations may not have many active members.

We understand that this document will require three IANA actions: 1) updating the reference for the existing "lex" registration at https://www.iana.org/assignments/urn-namespaces, 2) adding a NAPTR record to the urn.arpa domain, and 3) adding a NAPTR record to the urn.uri.arpa domain.

However, according to RFC 3405, in order to add records to urn.arpa and uri.arpa, the authors must submit their requests to these mailing lists for a two-week public review:

https://mm.icann.org/mailman/listinfo/register-urn
https://mm.icann.org/mailman/listinfo/register-uri

Because those lists (which haven't seen much activity post-2011) currently have ~20 members each, we've sent informal review requests to Leslie Daigle and Ted Hardie. We haven't heard from Leslie yet, but Ted had these notes:

> My quick scan of this sees a few potential issues with things listed
> as SHOULD which I believe would be better as MUST; I was also a little
> confused by this:
>
> "Such DNS routing chain does not work for all the URN components
> containing %-encoded characters. Therefore, when converting a lex:URN
> in UTF-8 code to a DNS query, clients MUST perform any necessary
> punycode conversion [RFC5891] before sending the query."

There are no designated experts for urn.arpa or uri.arpa, so unless the IESG instructs us otherwise, we'll mark this document "IANA OK" two weeks after the authors submit their review requests, provided that the lists don't raise any of the objections described in Section 5 of RFC 3405.

Best regards,

Amanda Baber
IANA Operations Manager
2023-12-21
21 Eliot Lear ISE state changed to In IESG Review from Response to Review Needed
2023-12-21
21 Eliot Lear IETF conflict review initiated - see conflict-review-spinosa-urn-lex
2023-12-21
21 Eliot Lear
draft-spinoza-urn-lex has been presented to the ISE for
publication as an Informational RFC on the Independent Stream.

==Purpose==

This memo specifies a process for uniquely …
draft-spinoza-urn-lex has been presented to the ISE for
publication as an Informational RFC on the Independent Stream.

==Purpose==

This memo specifies a process for uniquely identifying legislation.

== History==

This document was first considered by the IETF in 2009(!).  After
quite some time, it was AD sponsored.  It was reviewed, DISCUSSED,
revised, and then hit the ISE queue in April of 2021.  During this
period it went through extensive review and revision.

==Non-IETF Work==

This document has received a positive review from Cornell's Legal
Information Institute.  Resolution and assignment processes will be
handled outside IANA (apart from URN.ARPA).

==Security Considerations==

See Section 11 of the document.

==IANA==

An entry in URN.ARPA has already been assigned.  See Section 12 of the
documenmt.


==Reviews==

Numerous people have reviewed this work, both inside and outside the
IETF.  Peter Saint-Andre provided the URN review.
2023-12-15
21 PierLuigi Spinosa New version available: draft-spinosa-urn-lex-21.txt
2023-12-15
21 (System) New version approved
2023-12-15
21 (System) Request for posting confirmation emailed to previous authors: Caterina Lupo , Enrico Francesconi , PierLuigi Spinosa
2023-12-15
21 PierLuigi Spinosa Uploaded new revision
2023-11-14
20 (System) Revised I-D Needed tag cleared
2023-11-14
20 PierLuigi Spinosa New version available: draft-spinosa-urn-lex-20.txt
2023-11-14
20 (System) New version approved
2023-11-14
20 (System) Request for posting confirmation emailed to previous authors: Caterina Lupo , Enrico Francesconi , PierLuigi Spinosa
2023-11-14
20 PierLuigi Spinosa Uploaded new revision
2023-11-06
19 Eliot Lear Tag Revised I-D Needed set.
2023-09-19
19 (System) Revised I-D Needed tag cleared
2023-09-19
19 Enrico Francesconi New version available: draft-spinosa-urn-lex-19.txt
2023-09-19
19 (System) New version approved
2023-09-19
19 (System) Request for posting confirmation emailed to previous authors: Caterina Lupo , Enrico Francesconi , PierLuigi Spinosa
2023-09-19
19 Enrico Francesconi Uploaded new revision
2023-09-08
18 (System) Document has expired
2023-03-07
18 Eliot Lear Tag Revised I-D Needed set. Tag Awaiting Reviews cleared.
2023-03-07
18 Eliot Lear ISE state changed to Response to Review Needed from In ISE Review
2023-03-07
18 Eliot Lear Tag Awaiting Reviews set.
2023-03-07
18 PierLuigi Spinosa New version available: draft-spinosa-urn-lex-18.txt
2023-03-07
18 (System) New version approved
2023-03-07
18 (System) Request for posting confirmation emailed to previous authors: Caterina Lupo , Enrico Francesconi , PierLuigi Spinosa
2023-03-07
18 PierLuigi Spinosa Uploaded new revision
2023-02-10
17 PierLuigi Spinosa New version available: draft-spinosa-urn-lex-17.txt
2023-02-10
17 (System) New version approved
2023-02-10
17 (System) Request for posting confirmation emailed to previous authors: Caterina Lupo , Enrico Francesconi , PierLuigi Spinosa
2023-02-10
17 PierLuigi Spinosa Uploaded new revision
2023-01-25
16 Eliot Lear ISE state changed to In ISE Review from Response to Review Needed
2023-01-24
16 (System) Revised ID Needed tag cleared
2023-01-24
16 PierLuigi Spinosa New version available: draft-spinosa-urn-lex-16.txt
2023-01-24
16 (System) New version approved
2023-01-24
16 (System) Request for posting confirmation emailed to previous authors: Caterina Lupo , Enrico Francesconi , PierLuigi Spinosa
2023-01-24
16 PierLuigi Spinosa Uploaded new revision
2022-09-23
15 (System) Document has expired
2022-05-05
15 Eliot Lear Tag Revised I-D Needed set.
2022-05-05
15 Eliot Lear ISE state changed to Response to Review Needed from Finding Reviewers
2022-03-22
15 Eliot Lear ISE state changed to Finding Reviewers from Response to Review Needed
2022-03-22
15 (System) Revised ID Needed tag cleared
2022-03-22
15 PierLuigi Spinosa New version available: draft-spinosa-urn-lex-15.txt
2022-03-22
15 (System) New version approved
2022-03-22
15 (System) Request for posting confirmation emailed to previous authors: Caterina Lupo , Enrico Francesconi , PierLuigi Spinosa
2022-03-22
15 PierLuigi Spinosa Uploaded new revision
2021-11-08
14 (System) Document has expired
2021-09-22
14 Adrian Farrel Tag Revised I-D Needed set.
2021-09-22
14 Adrian Farrel ISE state changed to Response to Review Needed from In ISE Review
2021-05-04
14 Cindy Morgan Created "Approve" ballot
2021-05-04
14 Cindy Morgan Closed "Approve" ballot
2021-05-01
14 Adrian Farrel ISE state changed to In ISE Review from Submission Received
2021-04-27
14 (System) Revised ID Needed tag cleared
2021-04-27
14 PierLuigi Spinosa New version available: draft-spinosa-urn-lex-14.txt
2021-04-27
14 (System) New version approved
2021-04-27
14 (System) Request for posting confirmation emailed to previous authors: Caterina Lupo , Enrico Francesconi , PierLuigi Spinosa , rfc-ise@rfc-editor.org
2021-04-27
14 PierLuigi Spinosa Uploaded new revision
2021-04-18
13 Adrian Farrel Tag Revised I-D Needed set.
2021-04-18
13 Adrian Farrel ISE state changed to Submission Received
2021-04-18
13 Adrian Farrel Notification list changed to rfc-ise@rfc-editor.org because the document shepherd was set
2021-04-18
13 Adrian Farrel Document shepherd changed to Adrian Farrel
2021-04-18
13 Adrian Farrel Stream changed to ISE from None
2020-07-27
13 (System) Document has expired
2020-07-25
13 Barry Leiba
The document will not be published in the IETF Stream, as there are too many issues with the document that the IESG considers too serious …
The document will not be published in the IETF Stream, as there are too many issues with the document that the IESG considers too serious for approval.  It has been suggested to the authors that they might pursue publication in the Independent Stream.
2020-07-25
13 Barry Leiba IESG state changed to Dead from IESG Evaluation::Revised I-D Needed
2020-03-22
13 Adrian Farrel Removed from Independent Stream pending publication request from authors
2020-03-22
13 Adrian Farrel Stream changed to None from ISE
2020-03-20
13 Alexey Melnikov Stream changed to ISE from IETF
2020-03-10
13 Alexey Melnikov Shepherding AD changed to Barry Leiba
2020-02-21
13 Alexey Melnikov
[Ballot discuss]
[Updated. See some extra comments at the end.]
I have some small issue which need fixing before I would recommend approval of this …
[Ballot discuss]
[Updated. See some extra comments at the end.]
I have some small issue which need fixing before I would recommend approval of this document:

1) ABNF for "manifestation" in Attachment A doesn't match the same from Section 6.7:

In 6.7:

            manifestation = format ":" editor
                            [(":" component [":" feature]) /
                              (":" "all" ":" feature)]

In Attachment A:

manifestation = format *(";" specification)
                ":" editor *(";" specification)
                [(":" component [":" feature]) /
                (":" "all" ":" feature)]


It looks like you updated the definition in Section 6.7, but forgot to update the Attachment A to match. Please advise how you intend to fix this.
2020-02-21
13 Alexey Melnikov
[Ballot comment]
1) In 6.7:

  Note that the value "all" can be expressed by language-dependent
  equivalents.

The ABNF seems to suggest that "all" …
[Ballot comment]
1) In 6.7:

  Note that the value "all" can be expressed by language-dependent
  equivalents.

The ABNF seems to suggest that "all" is always supported. Is the word "also" missing after "can"?

2) In 6.8:

  Using a different separator ("~") from the document name, the
  partition ID is not withheld by the browser but it is transmitted to
  the resolution process. This enables the resolver to retrieve (for
  example, out of a database), if it is possible, only the referred
  partition, otherwise to return the whole act.
  Anyway, to make it effective in a browser pointing to the indicated
  partition, the resolver SHOULD transform the partition ID of each
  returned URL in a URI fragment; this is obtained appending to the URL
  the "#" character followed by the partition ID (in the example above,
  the returned URL will be #art15;par3)

Note that the fragment syntax is defined by the media type retrieved, so the above comment is only going to be valid if the partition syntax is compatible with the URI fragment for the media type used!


**********************************************************************
* Note, that I am conducting an experiment when people aspiring to be*
* Area Directors get exposed to AD work ("AD shadowing experiment"). *
* As a part of this experiment they get to review documents on IESG  *
* telechats according to IESG Discuss criteria document and their    *
* comments get relayed pretty much verbatim to relevant editors/WGs. *
* As an AD I retain responsibility in defending their position when  *
* I agree with it.                                                  *
* Recipients of these reviews are encouraged to reply to me directly *
* about perceived successes or failures of this experiment.          *
**********************************************************************

I also have some comments on Benjamin's comments below marked with "[[Alexey]]:"


The following comments were provided by Benjamin Schwartz :

Benjamin would have balloted *DISCUSS* on this document. He wrote:

**********************************************************************
* Note, that I am conducting an experiment when people aspiring to be*
* Area Directors get exposed to AD work ("AD shadowing experiment"). *
* As a part of this experiment they get to review documents on IESG  *
* telechats according to IESG Discuss criteria document and their    *
* comments get relayed pretty much verbatim to relevant editors/WGs. *
* As an AD I retain responsibility in defending their position when  *
* I agree with it.                                                  *
* Recipients of these reviews are encouraged to reply to me directly *
* about perceived successes or failures of this experiment.          *
**********************************************************************

The following comments were provided by Benjamin Schwartz :

Benjamin would have balloted *No Objections* on this document. He wrote:

I support the URN proposal here, but assigning control of this namespace is unnecessary and should be avoided.  We need more clarity around which requirements bind whom, because of the jurisdiction-specified format, and around the lookup procedure.  I also think the intended status should be Proposed Standard or Experimental, given the detailed, novel proposal.


## Section 1.3


The two sentences:
> “Outside Europe, similar initiatives have faced similar problems.”  “Numerous less-visible efforts in the United States and elsewhere have struggled with similar issues.”
What problems?  The text doesn’t identify any problems or struggles.  Please explain or rephrase.


## Section 3.1


Please specify the allowed characters in jurisdiction-code and jurisdiction-unit.


Please provide an example of how this URN is expected to work for legal systems that do not principally rely on a roman-type alphabet.


The text claims that jurisdictions are free to choose their own format, but the listed examples all conform to a single structure.  This is confusing.


## Section 5


The thing being described in this section needs a name.  I would suggest calling it the “baseline structure”, “simple schema”, or similar.  That would allow improved clarity about when these requirements are binding, e.g. they are binding only if the jurisdiction chooses to adopt the baseline structure.


# Section 6.4


I can no longer tell who is bound by this.  Is this part of the recommended simple schema in Section 5, or is it a binding requirement on all schemas that might be used by jurisdictions?


The example of “fsf.org” as a “jurisdiction” suggests that the word “jurisdiction” is not appropriate for this element.  “Source of law” would be better.  If the name “jurisdiction” is kept, a substantial caveat text up front would be appropriate, and all text indicating that this is “normally a country” should be removed, as non-state entities produce vastly more indexable legal documents than the states themselves.


# Section 6.8


What is an “ tag”?  This should have a reference.


# Section 7.1


Why “country or international organization”?  Surely national and local non-governmental organizations, corporations, or natural persons might also produce legal documents of interest?


“is assigned” by whom?  At a minimum, needs a forward reference to Section 7.4


# Section 7.4


   In particular, ITTIG-CNR, as proposer, is responsible of maintaining
   the uniqueness of the  element


Why do we need ITTIG-CNR to take on this role?  We already have the DNS itself.  Why not simply declare that the jurisdiction element is a domain name?


# Section 8.1


This technical architecture unnecessarily replicates the existing DNS TLD system, restricts participation in the LEX scheme, and centralizes control (and vulnerability) of the LEX namespace.  Instead of constructing a domain using the suffix “lex.urn.arpa”, this draft should use an attrleaf label (https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-16) (e.g. “_lex”) as a prefix.


   Such DNS routing chain does not work for all the URN components
   containing %-encoded characters. Therefore in these cases a proper
   software implementing punycode conversion or routing service has to
   be developed.


This paragraph should be rephrased as a normative requirement to implement IDN-punycode conversion with an RFC reference.


RFC 2169 is ancient, experimental, and hasn’t been cited in 15 years.  If it’s mentioned here, it needs more of a disclaimer, especially since it predates HTTPS.  However, I also think it’s the wrong architecture in this case.  Instead of identifying “the characteristics (protocol, port, site) of the service ... capable of associating the relative URLs with the URN in question”, it would be more flexible to simply declare that client shall do a NAPTR query that resolves to an HTTPS URL, which conveys the document itself.  If redirection is needed, HTTP 301 will suffice.


# Section 11.2


As noted above, there is no need for a lex.urn.arpa domain, or a new registry.  In the case of institutions that no longer exist (e.g. EEC), they can be represented by their successor institutions, or explicitly as subdomains of historic archives.  Representations without active control would place the registry in the position of arbiter of history.  We should not ask ITTIG-CNR or IANA to resolve disputes on who shall control the records of the law of the Soviet Union, Ancient Rome, or any other defunct institution.  We can simply let the user decide, by their choice of “jurisdiction” domain.
2020-02-21
13 Alexey Melnikov Ballot comment and discuss text updated for Alexey Melnikov
2020-02-20
13 Cindy Morgan Changed consensus to No from Yes
2020-02-20
13 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2020-02-20
13 Cindy Morgan Changed consensus to Yes from Unknown
2020-02-20
13 Éric Vyncke
[Ballot comment]
Thank you for the authors for this long effort for a useful and valid goal.

As I am running out of time to …
[Ballot comment]
Thank you for the authors for this long effort for a useful and valid goal.

As I am running out of time to review seriously and in depth this document, I am balloting 'ABSTAIN" but please note that while I am not always supporting all DISCUSS points by default (or even I do not agree with them); but, on this one Alissa's, Roman's, and Adam's DISCUSS appear like pretty valid and MUST be addressed...
2020-02-20
13 Éric Vyncke [Ballot Position Update] New position, Abstain, has been recorded for Éric Vyncke
2020-02-19
13 Benjamin Kaduk
[Ballot discuss]
There is no Security Considerations section, required by RFC 7322, so I
support Roman's Discuss.  I'll also add a note that the …
[Ballot discuss]
There is no Security Considerations section, required by RFC 7322, so I
support Roman's Discuss.  I'll also add a note that the presence of
aliases for a given resource also has potential security considerations,
as the aliased URNs are no longer unique identifiers.

I also support Alissa and Adam's Discusses.

Repeated advocacy for the use of http URLs seems misplaced in this
modern era (https is the appropriate replacement, providing for data
integrity and source authentication even when confidentiality is not
important).

The HTTP LEX identifier structure(s) proposed in Attachment D's
subsections are grossly inconsistent with BCP 190, and even the proposed
update in draft-nottingham-rfc7320bis.

There seems to be something of a mismatch between the goal of having "an
unequivocal identifier" and the weakness of only having a "recommended
construction" for the identifier.

The registration template in Section 2 seems internally inconsistent,
saying both that "use of r- and q-components [...] is not defined in
this document" but then going on to talk about things that can be done
using both the r-component and the q-component.

The ABNF in Attachment A uses only the 2*3alfa portion of the language
construction from BCP47, but BCP47 allows several other variants, and I
didn't see any descriptive text that indicates this limitation is
intentional.

The ABNF in Attachment A also does not admit the localization of the
"all" literal for the manifestation construction that is discussed in
the body text.

I agree with the conclusion of the genart reviewer: in aggregate, this
document is not ready for publication.  That said, I also agree with
Barry, that it's important to have a document published that properly
registers the "LEX" URN namespace ... there's just more work to be done
before this document can be that document.
2020-02-19
13 Benjamin Kaduk
[Ballot comment]
Section 1.1

  document. Even a document that is not available online at all may
  still have a URN LEX that identifies …
[Ballot comment]
Section 1.1

  document. Even a document that is not available online at all may
  still have a URN LEX that identifies it.

I'm not sure how to parse this; isn't "URN" the subject and "LEX" an
adjective modifying it (so that the order would be "LEX URN")?

Section 1.2

It's not clear that hardcoding this list into the immutable RFC provides
useful archival value.

  The following entities support this proposal at the time of
  publication:

Is this "support" in the sense of "utilize LEX URNs as identifiers" or
"believe that the proposal has merit and should proceed"?

Section 1.3

  In the last few years a number of initiatives have arisen in the
  field of legal document management.

I suggest rewording to a formulation that will not grow stale over time.

  Recently in the European Union, the community institutions have
  stressed the need for citizens, businesses, lawyers, prosecutors and
  judges to become more aware not only of (directly applicable) EU law,
  but also of the various national legal systems. The growing

"Recently" will still not age well.
Also, is this a recommendation to be aware of the existence of the
national legal systems, or particular aspects thereof?

  More recently the Council of the European Union invited the Member
  States to introduce in the legal information systems the European
  Legislation Identifier (ELI), an http-based Semantic Web oriented
  identification system for European Union and Member States
  legislation.

It's rather unfortunate that this is http-based, not https-based, since
regular http does not provide integrity protection or source
authentication.

  However specifications and syntax rules of LEX identifier can be used
  also for http-based naming convention (Appendix D) to cope with

[http (not https) again]

Section 1.4

  Registrants wish now to promote interoperability among legal
  information systems by the definition of a namespace convention and
  structure that will create and manage identifiers for legal

Who are "registrants", here?  (Also, I think "now wish" is a more
conventional word order, not that talking about "now" is very helpful in
an archival document.)

  documents. The identifiers will be:
  - globally unique
  - transparent
  - bidirectional

What does "bidirectional" mean?  I note that it has a usage in terms of
"bidirectional text" (combining both left-to-right scripts and
right-to-left scripts), which one might perhaps imagine combining in LEX
URNs (and has its own technical challenges), but I'm not sure whether
that's what's intended.  For the "can go back and forth from one form to
the other", I think that "reversible" or "invertable" are more common
words.

  Transparency means that given an act and its relevant metadata
  (issuing authority, type of measure, etc.) it is possible to create
  the related urn identifier. Moreover this identifier is able to
  unequivocally identify the related act. These two properties makes
  the identification system bidirectional (from an act to its URN and
  from a URN to the related act).

These properties, again, seem inconsistent with merely having a
"recommended" scheme for constructing URNs; achieving them seems to
require rigid rules.

  country or jurisdiction. This second part depends only on sources of
  law identification system operating in that nation and it is mainly
  composed by a formalized information related to the enacting
  authority, the type of measure, the details and possibly the annex.

nit: singular/plural mismatch "sources of law"/"system".
nit: "information" does not need an article

  The identification system based on uniform names SHOULD include:

What is having requirements imposed on it by this list -- the remainder
of this specification?  If so, normative language does not seem
appropriate.

  - a schema for assigning names capable of representing unambiguously
    any addressed source of law, namely legislation, case law and
    administrative acts, issued by any authority (intergovernmental,
    supranational, national, regional and local) at any time (past,
    present and future);

nit: I suggest a parallel linguistic construction that places "namely
legislation, case law, and administrative acts" in parentheses to match
the other two top-level list elements.

  - a resolution mechanism - in a distributed environment - that ties a
    uniform name to the on-line location of the corresponding
    resources.

nit: I suggest "resource(s)"

  This document only considers the first of these requirements. It also
  contains a few references to the architecture of the resolution
  service and to the corresponding software.

"Only" doesn't seem appropriate given that we follow it up with "also,
part of the other one".

Section 1.5

  - externally by means of an RDF triple, a specific attribute in a
    database, etc.

Please expand and/or provide a reference for "RDF"; it's not marked as
"well-known" at
https://www.rfc-editor.org/materials/abbrev.expansion.txt .

  One of these modalities is necessary for enabling automated

nit: exactly one, at least one, or a specific one?

Section 1.6

  LEX names will be used on a large scale in references as a HREF
  attribute value of the hypertext link to the referred document.

Forward-looking statements like this ("large scale") are risky; what if
reality proves to have different plans?

  In any case, whatever the method adopted is, new documents produced
  in XML format compliant with the relative DTD/XMLSchema, SHOULD
  express references through the uniform name of the document referred
  to.

I don't know what schema this is referring to.

Section 1.7

  - Jurisdictional Registrar:
    is an organization which shares and defines in any country or
    jurisdiction the assignment of the main components of the resource
    identifier through which its uniqueness is guaranteed. This task

What does "its" refer to?

    includes the definition of possible jurisdiction unit and the
    primary elements (issuing authority and type of legal measure) of
    uniform name, according to the characteristics of its own state or
    institution organization.

nits(?): I think maybe this is intended as "allowed jurisdiction units"
and "uniform names", though I'm not entirely sure.

Section 1.8

RFC 8174 has updated the BCP 14 boilerplate originally defined in RFC
2119
.

Section 2

        In the last few years a number of institutional initiatives
        have arisen in the field of legal document management. They

[still not going to age well]

        were aimed at introducing standards for sources of law
        description and identification using XML and URI techniques,
        respectively (for more details see Section 1.3) LEX identifier

This seems needlessly ambiguous to parse.  For example, I could group it
as "standards for (sources of law) (description and identification)",
"(standards for sources of law) (description and identification)", or
potentially even "standards for (sources of) (law description and
identification)".

        The LEX identifier is conceived to be: globally unique,
        transparent, bidirectional, persistent, location-independent,

[if "bidirectional" is changed above it should change here as well]

        LEX names will be used on a large scale in references either in
        (X)HTML document or, more generally, in XML documents format
        compliant with the relative DTD/XMLSchema (see Section 1.6 for
        more information).

[same comment about forward-looking statements]
[same comment about "the relative DTD/XMLSchema"]

          is the part providing the identification of the
        jurisdiction, generally corresponding to the country, where the
        source of law is issued. It is also possible to represent

So we don't care about state, regional, municipal, or other laws more
locally scoped than country?

        Identifiers in the "lex" namespace are defined through a
          element assigned to the sources of law of a
        specific country or organization, and a  assigned

Perhaps it's just me, but " element" makes it really hard
to think of anything that's not an XML-like markup language.

        by the assigned URNs. The elements values for the LEX
        identifier within a jurisdiction are defined by the
        Jurisdictional Registrar, this ensures that the constructed
        URNs are unique (see Section 7.3 for details on uniqueness).

nit: comma splice.

        The resolution service associates a LEX identifier with a
        specific document address on the net. The related system will

The resolution service that Section 1.4 claims we're not considering in
this document?

        have a distributed architecture based on two fundamental
        components: a chain of information in DNS (Domain Name System)

What "related system"?

        To cope with possible incomplete or inaccurate uniform names,
        the implementation of a catalogue, based on a relational-
        database, able to associate a URN to related URLs, is
        suggested, as it will lead to a higher flexibility in the
        resolution process. A resolver can provide names normalization,
        completion of inaccurate or incomplete names, and finally their
        resolution in network locations (see Section 8.2 and 8.3 for
        characteristics and behaviour of a catalogue for resolution).

I shared the directorate reviewer's unease about recommending such
flexibility/fuzziness.

Section 3.1

  The  element is composed of two specific fields:

      jurisdiction = jurisdiction-code *(";" jurisdiction-unit)

I echo the directorate reviewer's concerns about using semicolon as a
delimeter.

  To facilitate the transparency of the name, the
  follows usually the rules of identification of other Internet

Usually?  How am I supposed to build unequivocable service based on
"usually"?

  urn:lex:us:federal.supreme.court:decision:1963-03-18;372.us.335 (US
  FSC decision)

I'm not sure I understand the "us:federal.supreme.court" bit (i.e., why
no semicolon is needed).

Section 3.2

  The "lex" NID syntax conforms to [RFC8141]. However, a series of
  characters are reserved to identify elements or sub-elements, or for
  future extensions of the identifier.

Which identifier?

Section 4.4

  If this conversion is not acceptable by a specific jurisdiction, UTF-
  8 %-encoding [STD63] may be used. In this case it should be noted
  that the generated URN (as some of its parts) can not be used
  directly for routing through DNS, and therefore the jurisdiction must
  adopt one of the following strategies:

I think technically the following list is not an exhaustive one (as the
current wording indicates), as (e.g.) a non-punycode DNS encoding might
be used under the control of a specific domain.

Section 5.2

  The use of acronyms might be confusing and encourage ambiguity in
  uniform names (the same acronym may indicate two different
  institutions or structures), therefore their expansion is highly
  RECOMMENDED.

Who is this recommendation directed at?
Who is responsible for ensuring uniqueness of identifiers and the
absence of ambiguity?

Section 6.1

  The uniform name must identify one and only one document (more
  precisely a "bibliographic entity") and is created in such a way that

Please define "bibliographic entity" whether directly or by reference.

Section 6.2

  In this document the FRBR model has been interpreted for the specific
  characteristics of the legal domain. In particular, a part from the

nit: s/a part/apart/ (right?)

Section 6.4

    is the type of the measure, both public nature (e.g.,
  constitution, act, treaty, regulation, decree, decision, etc.) as
  well as private one (e.g., license, agreement, etc);

A license or agreement can be a source of *law* erga omnes?!

  Examples (hypothetical) of  identifiers are:

  urn:lex:it:stato:legge:2006-05-14;22
  urn:lex:uk:ministry.justice:decree:1999-10-07;45

What happens if there's more than one decree from the ministry of
justice on a given day?

Section 6.6

    is the identifier of the version of the (original or
  amended) source of law. In general it is expressed by the
  promulgation date of the amending act; anyway other specific
  information can be used for particular documents. If necessary, the

This is not looking so good from the perspective of "going backwards"
from a given document to the authoritative LEX URN based solely on the
document...

  urn:lex:ch:etat:loi:2006-05-14;22@originel:fr (original version in
  French)
  [...]
  urn:lex:be:conseil.etat:decision:2008-07-09;185.273@originel:fr
  (original version in French of a Belgian decision)

These are inconsistent with the text three paragraphs prior about '''the
string "original"'''.

Section 6.7

  - digital format (e.g., XML, HTML, PDF, etc.) expressed according to
    the MIME Content-Type standard [RFC2045], where the "/" character
    is to be substituted by the "-" sign;

This substitution seems like it could introduce ambiguity (there are
*many* instances of "-" in
https://www.iana.org/assignments/media-types/media-types.xhtml).

  - editorial staff who produced it, expressed according to its
    Internet domain name. Since publishers' domain names may vary over
    time, manifestations already assigned by a publisher remain
    unchanged even if the identified object is no longer accessible. In
    this case, in order to make its materials accessible, the publisher
    will have to create for each of them a new manifestation with the
    new domain name;

I'm confused.  This sounds like "to make such a manifestation available,
some other manifestation will have to be used instead of the original
manifestation", which sounds an awful lot like "such a manifestation
cannot be made available".

  The  suffix will thus read:

            manifestation = format ":" editor
                            [(":" component [":" feature]) /
                              (":" "all" ":" feature)]

I thought the string "all" was supposed to be a language-dependent
label; this ABNF does not allow for such behavior.  The following
paragraph notwithstanding, I would suggest using a dedicated ABNF
construction for .

  equivalents. To indicate possible features or peculiarities, each
  main element of the manifestation MAY be followed by further
  specifications, for example as regards  the version, for

"Followed" using what separator?

Section 6.8

  represented by an element (a block of text) with its own ID; this ID
  aims to identify the related element and to locate it. In this case,
  therefore, it is possible either extracting or pointing to a
  partition.

nit: s/extracting or pointing/to extract or to point/

  In both cases, having a partition identifier is useful; therefore,
  for allowing browsers to point to a specific partition, it is
  necessary that such partition is endowed with an unequivocal label or
  ID within the including document and its value is the same
  independently from the document format.

What/who is going to require (and enforce) the consistency of ID value
across formats?

  For enabling the construction of the partition identifier between
  different collections of documents, specific construction rules for
  IDs or labels SHOULD be defined and shared, within each country or
  jurisdiction, for any document type (e.g., for legislation, the

When might this "SHOULD" be violated?

  (e.g., to refer to the paragraph 3 of the article 15 of the French
  Act of 15 may 2004, n. 106, the reference is written
  "urn:lex:fr:etat:loi:2004-05-15;106~art15;par3").

nit: unless the French jurisdictional registrar has already promulgated
this encoding, I suggest to avoid definitive language such as "is
written".

  Anyway, to make it effective in a browser pointing to the indicated
  partition, the resolver SHOULD transform the partition ID of each
  returned URL in a URI fragment; this is obtained appending to the URL
  the "#" character followed by the partition ID (in the example above,
  the returned URL will be #art15;par3). Doing this,

Has this recommendation seen specific review from ART-area expertise?
It seems surprising to me, though I am not an expert in this area.

Section 7.1

  the source of law of that country or jurisdiction. This code is
  assigned according to ccTLD (as well as TLDN or DN for the

Please expand TLDN and DN.

Section 7.2

  Such a set of rules will have to be followed by all institutional
  bodies adherent to the project as well as by private publishers and
  each of them will be responsible for assigning names to their
  domains.

What is "the project"?

Section 8.1

  Such DNS routing chain does not work for all the URN components
  containing %-encoded characters. Therefore in these cases a proper
  software implementing punycode conversion or routing service has to
  be developed.

Given that a goal of this proposal is to make national law accessible to
all audiences (including international ones), it seems an unreasonable
requirement to expect a given user outside of the jurisdiction requiring
such a routing service to know how to properly use that routing service
to access the law information.  I note that clients may not be
performing (e.g.) QNAME minimization and would thus face errors when
attempting to construct a request for the full resource, even though a
reduced query would allow it to proceed towards a more local resolver
that may be aware of the necessary procedures for handling
percent-encoded characters.

Section 8.2, 8.3

[same comment as above in Section 2 regarding "fuzziness"]

Section 10

  quality and currency. A shared identification mechanism resources
  guarantees that a distributed system will be as efficient and
  effective as a comparable centralized system.

nit: singular/plural mismatch ("mechanism resources")

  Creators of Internet content that references legal materials -
  including publishers operating well outside the traditional arenas of
  legal publishing - benefit by the registration of the namespace
  because facilitates the linking of legal documents, whether by manual
  or automated means, and reduces the cost of maintaining documents
  that contain such references.

nit: s/because facilitates/because it facilitates/ (?)

  Any citizen or organisation with Internet web browser capability will
  be entitled to access the namespace and its associated application,
  registers, and resolution services, to facilitate document access.

Who is going to enforce this?  It is a laudable goal and consistent with
IETF ideals on openness and transparency, but regrettably the law is not
open-access at present in all jurisdictions.

  It is envisaged to promote the urn:lex identification system for
  sources of law through all the various dissemination channels such as
  conferences, a project dedicated website, references from other
  projects, etc.

This doesn't really seem to add value in an archival document.

Section 11.1

  where  indicates the server of the organization
  that is responsible for the "lex" area under urn.arpa and
  urn.uri.arpa, and will be specified at implementation time.

What is "implementation time"?  When IANA processes the registration?

Section 11.2

  - : all information about the organization that requested
    the registration of the code. Such organization will be responsible

"All information" subject to what scope?  "All information" about an
organization seems potentially unbounded...

  In the current experimental LEX registration phase, ITTIG-CNR will
  take care to create and maintain the registry for . As the criteria of the LEX names assignment will be
  consolidated, after the experimental phase such registry will be
  maintained by IANA.

What are the criteria to determine the exit from the "experimental
phase"?

  - in case when such multi-national or international organization does
    not have a registered domain, Designated Expert(s) should assign
    something like .lex.arpa, where  is the English acronym
    of the organization name. For example, the jurisdiction code of the
    European Economic Community is "eec.lex.arpa".

*is*?!  This assignment has already been made?

Attachment A

There doesn't seem to be anything to distinguish between the
"institution" and "office" constructions.

It's slightly surprising to see a production named "alfanum" admit
percent-encoded values as well.

Attachment B1.2

How is a list of multiple issuers sorted to obtain a definitive
identifier?

Attachment B2.3

  In order to ensure, in all the cases, the validity of the references,
  an alias that takes into account the measure category is associated
  to the uniform name, representing the legislative form.

I don't understand what is meant by "is associated to".

Attachment B3.3

  To ensure that the uniform name is unambiguous, the  field
  MUST, in any case, contain a discriminating element, which can be any
  identifier used internally, and not published, by the authority
  (e.g., protocol).

How can an identifier be not published and used only internally but
remain part of the URN that unequivocally identifies a measure?

Attachment B3.4

  This conversion may imply that the uniform name of the document is no
  more unique (e.g., removal 123-BIS and return 123/BIS of the bill 123
  both are identified as "123-bis"); in this case, it is necessary to
  add a specific distinctive ending (e.g., "123-bis-removal" and "123-
  bis-return").

This seems awkward to implement and introduces state to the allocation
process such that there is an ordering dependency on how identifiers are
allocated.  In particular, it cannot be known in advance if some other
document will be created that this procedure would cause to produce a
conflict in need of a distinctive ending, so in some sense a distinctive
ending should always be used.

Attachment B4.1

  Although annexes are an integral part of the legal document, they may
  be referred to and undergo amendments separately from the act to
  which they are annexed. It is, therefore, necessary that both the
  main document as well as each formal individual annex is univocally
  identified.

["unequivocally" seems to be used much more than "univocally" in the
rest of this document]

Attachment C1.1

  In a "multi-version" document each time interval should have a link
  to the related in-force document version obtained by displaying in a
  different way the very same document.

I don't understand what this sentence means.  What is "obtained by
displaying in a different way the very same document"?  How is a given
document supposed to be "displayed in a different way"?

  -  contains the issuing date of the last considered
    amendment or of the last communication of amendment. In case the
    original text introduces differentiated periods in which an act is
    effective and the information system produces one version for each
    of them, such element contains the string "original";

Is this string localized to the relevant language?

Attachment D1

  Http URIs have been recently promoted as stable and location-
  independent identifiers [RFC3986].  According to this syntax, at all

As noted by the directorate reviewer, "recently" seems very out of place
here.

I reiterate my unease at using "http" vs. "https".

  Such kind of identifiers have been recently suggested also within the

["recently" again; RFC 5988 is hardly "recent" (ten years old) and the
w3.org reference older still]

  identifier and manifestation of an act). The independence from the
  resource location is managed by a "303 Redirect" status code (see
  http://linkeddatabook.com/editions/1.0/#htoc11) which may require a

I suggest that RFC 7231 is a much more appropriate reference for the
"303 See Other" status code.
2020-02-19
13 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2020-02-19
13 Alissa Cooper
[Ballot discuss]
Given that this document is AD-sponsored, that it has changed significantly since it went through IETF LC, and that the IETF LC was …
[Ballot discuss]
Given that this document is AD-sponsored, that it has changed significantly since it went through IETF LC, and that the IETF LC was several years ago, I think it needs to go through IETF LC again before proceeding.

The original Gen-ART review of this document  raised a major issue about how it is "partially specifying a complete system for federating the naming and access to legal documents." This issue does not appear to have been addressed. I believe Section 8 needs to be separated into a different document to accomplish this. I also don't see how Section 8 can be included and have this document remain informational.

The most recent Gen-ART review of this document  raises a number of significant issues. I think the totality of that review indicates that this document is not ready for publication. At a minimum, issues 1, 5, 6, 11, and 12 need to be resolved prior to publication.

I support Adam's and Roman's DISCUSS positions.
2020-02-19
13 Alissa Cooper Ballot discuss text updated for Alissa Cooper
2020-02-19
13 Alissa Cooper
[Ballot discuss]
The original Gen-ART review of this document  raised a major issue about how it is "partially specifying a complete system for federating the …
[Ballot discuss]
The original Gen-ART review of this document  raised a major issue about how it is "partially specifying a complete system for federating the naming and access to legal documents." This issue does not appear to have been addressed. I believe Section 8 needs to be separated into a different document to accomplish this. I also don't see how Section 8 can be included and have this document remain informational.

The most recent Gen-ART review of this document  raises a number of significant issues. I think the totality of that review indicates that this document is not ready for publication. At a minimum, issues 1, 5, 6, 11, and 12 need to be resolved prior to publication.

I support Adam's and Roman's DISCUSS positions.
2020-02-19
13 Alissa Cooper Ballot discuss text updated for Alissa Cooper
2020-02-19
13 Alissa Cooper
[Ballot discuss]
The original Gen-ART review of this document raised a major issue about how it is "partially specifying a complete system for federating the …
[Ballot discuss]
The original Gen-ART review of this document raised a major issue about how it is "partially specifying a complete system for federating the naming and access to legal documents." This issue does not appear to have been addressed.

I support Adam's and Roman's DISCUSS positions.
2020-02-19
13 Alissa Cooper [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper
2020-02-19
13 Roman Danyliw
[Ballot discuss]
This document does not contain a Security Considerations section.  There is only the following text in Section 2:

        This …
[Ballot discuss]
This document does not contain a Security Considerations section.  There is only the following text in Section 2:

        This document introduces no additional security considerations
        beyond those associated with the use and resolution of URNs in
        general.

As this document suggests a notional architecture and workflow for the URNs in this namespace (not just registration of a namespace), one would have expected at least:

-- general caution about handling URI/URNs such as found in RFC3986, “A URI does not in itself pose a security threat.  However, as URIs are often used to provide a compact set of instructions for access to network resources [in this case of LEX, legal documents], care must be taken to properly interpret the data within a URI, to prevent that data from causing unintended access, and to avoid including data that should not be revealed in plain text.”

-- references to security considerations of generic URNs

-- caution on how the resolution of URNs over the network if done in the clear could leak sensitive information based on which specific laws were interesting; and point to privacy enhancing DNS technologies

-- given the delegated environment, caution on how URNs could be used as redirects users to malicious content

-- the vetting process that will be used to delegate portions of the namespace
2020-02-19
13 Roman Danyliw
[Ballot comment]
The text, as written (particularly Section 8), does not appear to provide sufficient detail to create an interoperable system.  However, as this draft …
[Ballot comment]
The text, as written (particularly Section 8), does not appear to provide sufficient detail to create an interoperable system.  However, as this draft is Information, beyond addressing the DISCUSS, I won’t stand the way of the proponents building an ecosystem around this namespace.

Suggested areas of clarifications/polish:

** Section 1.2.  What’s the purpose of indicating these entities supported the publication?  It seems out of place.  Would we say “Vendor-1, University-2, Carrier-3 … supported this proposal?”  IMO, if specific individuals from that organization contributed to this document, please use the acknowledgement section. 

** Section 1.3.  Per “Outside Europe, similar initiatives have faced similar problems”, based on the prior text in this section, it isn’t clear what problems are being described.  The previous text only establishes that various countries are pursuing approaches to “introduce standards for the description of legal sources”.  Their respective design or implementation success isn’t explained.

** Section 1.3.  Consider adding a reference for these statements:
-- “The need for a unequivocal identifier of sources of law in different EU Member States … has been expressed in several conferences …”

-- “Similar concerns have been raised by international groups concerned with free access to legal information, …”

** Section 1.3.  Per “The Permanent Bureau of the Hague Conference on Private International Law is considering a resolution that would encourage member states …”, will references to draft legislation age well in an enduring RFC?

** Section 1.5.  What is a “LEX name”?  Is that the same as a “LEX identifier” previously used?  Recommend establishing the link between these two before use. 

** Section 4.4  Per “it is strongly RECOMMENDED that national characters and diacritic signs are turned into base ASCII characters”, the intent is clear, but what is the proposed deterministic algorithm?

** Section 6.2.  Consider adding a reference for IFLA’s FRBR.

** Section 8.1.  Per “Delegation of this responsibility will not be unreasonably withheld provided that the processes for their resolution and management are robust and are followed.”, can this withholding of delegation be clarified.

** Editorial Nits
-- Section 2.  Typo.  s/persitence/persistence/

-- Section 2.  Resolution.  What is “on the net”?  If that means the internet, consider using less colloquial language.
2020-02-19
13 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2020-02-19
13 Amanda Baber
IANA is waiting for experts to approve the URN NID registration.

In addition, a reviewer had the following comments: "Section 8.1 states that 'ITTIG-CNR will …
IANA is waiting for experts to approve the URN NID registration.

In addition, a reviewer had the following comments: "Section 8.1 states that 'ITTIG-CNR will maintain the root zone "lex.urn.arpa" (see [RFC3405]) ...' whereas Section 11.1 suggests the organization choice is not settled and/or outside the scope of the RFC, i.e. '... indicates the server of the organization that is responsible for the "lex" area under urn.arpa and urn.uri.arpa, and will be specified at implementation time.' These should be consistent. Agree that the appointment of specific organizations should be outside the scope of the RFC unless it is essential, because RFCs are meant to be timeless and I think appointments like that are probably IESG actions or similar."

Finally, we have a question about this statement: "In the current experimental LEX registration phase, ITTIG-CNR will take care to create and maintain the registry for . As the criteria of the LEX names assignment will be consolidated, after the experimental phase such registry will be maintained by IANA."

How will IANA be notified of this? Will another document be published? How long is the experimental phase intended to last?
2020-02-19
13 Amanda Baber IANA Experts State changed to Reviews assigned
2020-02-19
13 Amanda Baber IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2020-02-19
13 Adam Roach
[Ballot discuss]
This document refers to itself as a "standard" in approximately 30 different places. This seems problematically misleading for a document being published as …
[Ballot discuss]
This document refers to itself as a "standard" in approximately 30 different places. This seems problematically misleading for a document being published as Informational.
2020-02-19
13 Adam Roach
[Ballot comment]
Section 1.8: Please update this section to use the boilerplate from RFC 8174.

I share Barry's concerns, but reach the same conclusion …
[Ballot comment]
Section 1.8: Please update this section to use the boilerplate from RFC 8174.

I share Barry's concerns, but reach the same conclusion as he has.
2020-02-19
13 Adam Roach [Ballot Position Update] New position, Discuss, has been recorded for Adam Roach
2020-02-19
13 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-02-18
13 Paul Kyzivat Request for Telechat review by GENART Completed: Ready with Issues. Reviewer: Paul Kyzivat.
2020-02-13
13 Jean Mahoney Request for Telechat review by GENART is assigned to Paul Kyzivat
2020-02-13
13 Jean Mahoney Request for Telechat review by GENART is assigned to Paul Kyzivat
2020-02-12
13 Scott Bradner Request for Telechat review by OPSDIR Completed: Has Issues. Reviewer: Scott Bradner. Sent review to list.
2020-02-10
13 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Scott Bradner
2020-02-10
13 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Scott Bradner
2020-02-07
13 Amy Vezza Placed on agenda for telechat - 2020-02-20
2020-02-07
13 Alexey Melnikov
[Ballot discuss]
I have some small issue which need fixing before I would recommend approval of this document:

1) ABNF for "manifestation" in Attachment A …
[Ballot discuss]
I have some small issue which need fixing before I would recommend approval of this document:

1) ABNF for "manifestation" in Attachment A doesn't match the same from Section 6.7:

In 6.7:

            manifestation = format ":" editor
                            [(":" component [":" feature]) /
                              (":" "all" ":" feature)]

In Attachment A:

manifestation = format *(";" specification)
                ":" editor *(";" specification)
                [(":" component [":" feature]) /
                (":" "all" ":" feature)]


It looks like you updated the definition in Section 6.7, but forgot to update the Attachment A to match. Please advise how you intend to fix this.
2020-02-07
13 Alexey Melnikov
[Ballot comment]
1) In 6.7:

  Note that the value "all" can be expressed by language-dependent
  equivalents.

The ABNF seems to suggest that "all" …
[Ballot comment]
1) In 6.7:

  Note that the value "all" can be expressed by language-dependent
  equivalents.

The ABNF seems to suggest that "all" is always supported. Is the word "also" missing after "can"?

2) In 6.8:

  Using a different separator ("~") from the document name, the
  partition ID is not withheld by the browser but it is transmitted to
  the resolution process. This enables the resolver to retrieve (for
  example, out of a database), if it is possible, only the referred
  partition, otherwise to return the whole act.
  Anyway, to make it effective in a browser pointing to the indicated
  partition, the resolver SHOULD transform the partition ID of each
  returned URL in a URI fragment; this is obtained appending to the URL
  the "#" character followed by the partition ID (in the example above,
  the returned URL will be #art15;par3)

Note that the fragment syntax is defined by the media type retrieved, so the above comment is only going to be valid if the partition syntax is compatible with the URI fragment for the media type used!
2020-02-07
13 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to Discuss from Yes
2020-02-07
13 Barry Leiba
[Ballot comment]
As I've explained in extensive reviews of this document over its long, overly delayed history, I think there are serious issues with this …
[Ballot comment]
As I've explained in extensive reviews of this document over its long, overly delayed history, I think there are serious issues with this document and how the "lex" URN namespace will be managed... but I also think it's more important to get it defined and registered, and to let the proponents manage it and prove me wrong.
2020-02-07
13 Barry Leiba [Ballot Position Update] New position, Abstain, has been recorded for Barry Leiba
2020-02-07
13 Alexey Melnikov Ballot has been issued
2020-02-07
13 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2020-02-07
13 Alexey Melnikov Created "Approve" ballot
2020-02-07
13 Alexey Melnikov Ballot writeup was changed
2020-02-07
13 Alexey Melnikov IESG state changed to IESG Evaluation from Waiting for Writeup::AD Followup
2019-11-20
13 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Team Will not Review Version'
2019-11-20
13 Tero Kivinen Assignment of request for Last Call review by SECDIR to Russ Mundy was marked no-response
2018-06-06
13 PierLuigi Spinosa New version available: draft-spinosa-urn-lex-13.txt
2018-06-06
13 (System) New version approved
2018-06-06
13 (System) Request for posting confirmation emailed to previous authors: PierLuigi Spinosa , Caterina Lupo , Enrico Francesconi
2018-06-06
13 PierLuigi Spinosa Uploaded new revision
2017-11-16
12 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-11-16
12 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2017-11-16
12 PierLuigi Spinosa New version available: draft-spinosa-urn-lex-12.txt
2017-11-16
12 (System) New version approved
2017-11-16
12 (System) Request for posting confirmation emailed to previous authors: PierLuigi Spinosa , Caterina Lupo , Enrico Francesconi
2017-11-16
12 PierLuigi Spinosa Uploaded new revision
2017-09-20
11 Alexey Melnikov
Some very good comments from the GenArt review. I don't agree with all of them, but many of them are similar to comments from my …
Some very good comments from the GenArt review. I don't agree with all of them, but many of them are similar to comments from my original review.
2017-09-20
11 Alexey Melnikov IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup
2017-09-20
11 Alexey Melnikov Removed from agenda for telechat
2017-09-20
11 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Scott Bradner.
2017-09-14
11 Paul Kyzivat Request for Last Call review by GENART Completed: Not Ready. Reviewer: Paul Kyzivat.
2017-09-14
11 (System) IESG state changed to Waiting for Writeup from In Last Call
2017-09-13
11 Alexey Melnikov Placed on agenda for telechat - 2017-09-28
2017-09-13
11 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2017-09-13
11 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-spinosa-urn-lex-11. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-spinosa-urn-lex-11. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has questions about the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the Formal URN Namespaces registry on the Uniform Resource Names (URN) Namespaces registry page located at:

https://www.iana.org/assignments/urn-namespaces/

a single, new URN will be registered as follows:

URN Namespace: lex
Template:
Reference: [ RFC-to-be ]

Because this registry requires Expert Review [RFC 8126] for registration, the IESG-designated experts for Formal URN Namespaces have asked that you send a review request to the mailing list urn@ietf.org. Expert review should be completed before your document can be approved for publication as an RFC.

Second, we will request the approval of the IAB to implement the following two NAPTR records:

in the URN.ARPA domain:
lex IN NAPTR 100 10 "" "" "" lex.ittig.cnr.it.

in the URN.URI.ARPA domain:
lex IN NAPTR 100 10 "" "" "" lex.ittig.cnr.it.

IANA QUESTIONS -> Is the hostname lex.ittig.cnr.it guaranteed to have a long lifetime? Is it appropriate for that to be permanently documented, i.e. not subject to change? It might be better to document the approach in such a way that that exact form of the NAPTR record is not in the I-D. (For example, when we add new .ARPA domains via RFCs, it does not spell out what the NS records would be, that is considered an implementation detail to be managed outside the document.)

Third, a new registry is to be created called the Jurisdiction-Code registry. The new registry will be managed using Expert Review as defined by [RFC 8126].

IANA QUESTION -> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

We understand that there are no initial registrations in the new registry.

The IANA Services Operator understands that these three actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist
2017-09-07
11 Jean Mahoney Request for Last Call review by GENART is assigned to Paul Kyzivat
2017-09-07
11 Jean Mahoney Request for Last Call review by GENART is assigned to Paul Kyzivat
2017-09-07
11 Jouni Korhonen Assignment of request for Last Call review by GENART to Jouni Korhonen was rejected
2017-08-24
11 Tero Kivinen Request for Last Call review by SECDIR is assigned to Russ Mundy
2017-08-24
11 Tero Kivinen Request for Last Call review by SECDIR is assigned to Russ Mundy
2017-08-22
11 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Scott Bradner
2017-08-22
11 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Scott Bradner
2017-08-17
11 Jean Mahoney Request for Last Call review by GENART is assigned to Jouni Korhonen
2017-08-17
11 Jean Mahoney Request for Last Call review by GENART is assigned to Jouni Korhonen
2017-08-17
11 Amy Vezza IANA Review state changed to IANA - Review Needed
2017-08-17
11 Amy Vezza
The following Last Call announcement was sent out (ends 2017-09-14):

From: The IESG
To: IETF-Announce
CC: alexey.melnikov@isode.com, andy@arin.net, draft-spinosa-urn-lex@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: …
The following Last Call announcement was sent out (ends 2017-09-14):

From: The IESG
To: IETF-Announce
CC: alexey.melnikov@isode.com, andy@arin.net, draft-spinosa-urn-lex@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Uniform Resource Name (URN) Namespace for Sources of Law (LEX)) to Informational RFC


The IESG has received a request from an individual submitter to consider the
following document: - 'A Uniform Resource Name (URN) Namespace for Sources of
Law (LEX)'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-09-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document describes a Uniform Resource Name (URN) Namespace
  Identification (NID) convention as prescribed by the World Wide Web
  Consortium (W3C) for identifying, naming, assigning, and managing
  persistent resources in the legal domain.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-spinosa-urn-lex/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-spinosa-urn-lex/ballot/


No IPR declarations have been submitted directly on this I-D.




2017-08-17
11 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2017-08-17
11 Alexey Melnikov Last call was requested
2017-08-17
11 Alexey Melnikov Last call announcement was generated
2017-08-17
11 Alexey Melnikov Ballot approval text was generated
2017-08-17
11 Alexey Melnikov Ballot writeup was generated
2017-08-17
11 Alexey Melnikov IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2017-08-09
11 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-08-09
11 PierLuigi Spinosa New version available: draft-spinosa-urn-lex-11.txt
2017-08-09
11 (System) New version approved
2017-08-09
11 (System) Request for posting confirmation emailed to previous authors: PierLuigi Spinosa , Caterina Lupo , Enrico Francesconi
2017-08-09
11 PierLuigi Spinosa Uploaded new revision
2017-05-01
10 Alexey Melnikov
Summary of blocking outstanding issues for draft-spinosa-urn-lex-10:

1) Missing/incomplete registration template for a new URN Namespace "lex".

2) Use of domains not registered in …
Summary of blocking outstanding issues for draft-spinosa-urn-lex-10:

1) Missing/incomplete registration template for a new URN Namespace "lex".

2) Use of domains not registered in DNS (like "eec.lex") is confusing.
Either they should be change to be under "urn.arpa" domain or
the document should change terminology to make it clear that
these are not domain names. Maybe use something like
"jurisdiction identifier" instead.

3)  need a new IANA registry or a deterministic
mechanism to find out valid jurisdiction codes. It is probably
easier to create a new IANA registry.

4) Text about being able to rename jurisdiction codes need to be deleted,
as this breaks URN semantics (i.e. guarantee of their persistence).

5) Section 3 should be split into 2 top level sections: one that talks
about general syntax and another one that talks about recommendations that
should be done within each specific jurisdiction. For example,
the following sub-sections of 3 would be moved to the latter top level
section:

      3.5  National Characters and Diacritic Signs . . . . . . . . .  15
      3.7  Abbreviations . . . . . . . . . . . . . . . . . . . . . .  15
      3.8  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . .  16
      3.10  Ordinal Numbers  . . . . . . . . . . . . . . . . . . . .  16

and possibly:

      3.6  Spaces, Connectives and Punctuation Marks . . . . . . . .  15

The following sub-section can stay under the current section 3:

      3.1  Syntax Used in this Document  . . . . . . . . . . . . . .  14
      3.2  Allowed and Not Allowed Characters  . . . . . . . . . . .  14
      3.3  Reserved Characters . . . . . . . . . . . . . . . . . . .  14
      3.4  Case sensitivity  . . . . . . . . . . . . . . . . . . . .  14
      3.9  Date Format . . . . . . . . . . . . . . . . . . . . . . .  16
2017-01-04
10 Alexey Melnikov Further comments/questions sent in reply to editors' comments on my AD review. Another revision is needed.
2017-01-04
10 Alexey Melnikov IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2016-11-14
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2016-11-14
10 PierLuigi Spinosa New version available: draft-spinosa-urn-lex-10.txt
2016-11-14
10 (System) New version approved
2016-11-14
10 (System) Request for posting confirmation emailed to previous authors: "Caterina Lupo" , "Enrico Francesconi" , "PierLuigi Spinosa"
2016-11-14
10 PierLuigi Spinosa Uploaded new revision
2016-06-24
09 Alexey Melnikov
My AD review of the draft:

In addition to issues raised below, I am a bit concerned about use of "$", "@", etc. as delimiters …
My AD review of the draft:

In addition to issues raised below, I am a bit concerned about use of "$", "@", etc. as delimiters with special meaning, but I need to research a bit more on the subject before I can decide whether it is a valid concern or not.

-------------
In 2.3: ABNF (RFC 5234) needs to be a Normative Reference.

In 2.4:

When talking about jurisdiction codes, the document suggests to use ISO 3166 code in some cases and domain names in other cases. If this is supposed to be normative, you need to pick one of the methods or at least specify what is used when (for example, you can use 2 letter country codes from ISO 3166 and for values which at 3 letters or longer, or contain ".", you use domain names), you can't have unspecified mixture of both. Alternatively (the 3rd choice), you ask for a registry to be created, which is populated by an expert, who will decide on a case by case basis which values are legal.

The whole section needs multiple edits to address the above concern. For example:

    is usually the identification code of the country
  where the source of law is issued; this code follows the standard
  [ISO3166] Alpha-2 (it=Italy, fr=France, dk=Denmark, etc.) which
  usually is identical to the country code Top-Level Domain (ccTLD). In
  case such codes are not identical (as for United Kingdom, whose ISO
  3166 code is .gb while its ccTLD is .uk), one of them is chosen as
  .

Chosen by whom? If you make a statement like this, you need to explain who has the authority to decide.


I think use of special .lex domain might be problematic, if this top level domain gets assigned by IETF or ICANN.

Suggestion how to handle domain reassignments by appending dates need more work! Again, you need to specify rules who can decide.

In 3.3:

I assume when you say "case sensitive", you mean case sensitive in ASCII range, right?

In 3.4:

It would be better to pick a single way of handling Diacritic Signs or at least state the preferred one.

In 3.5:

This section seems to suggests that in order to generate a URN, generator needs to be language aware, because it needs to suppress articles, prepositions, etc. Being language aware is problematic, because different jurisdictions would use different languages, which would mean supporting all common written languages and maintaining a table of which languages will be used in which jurisdiction. I don't think this is implementable. If this is just a recommendation for jurisdictions, then you should clearly state that the section talks about recommended way of creating URNs, but that the procedure can't be used to create LEX URNs algorithmically.


In 3.6:

Again, this is not implementable without being language aware and you have MUST level requirement here.

In 3.9:

Again, similar problem ("Third" ==> "3")


7.6  IANA Considerations

According to RFC format rules, this should be a top level section.

  This document includes a URN NID registration for "lex" for entry in
  the IANA registry of URN NIDs (see [RFC5226]), as well as the

RFC5226 has nothing to do with URN NID registrations, so this is an incorrect reference. See also below.

  registration of the following NAPTRs record:


Please provide full IANA registration template according to the template specified in Appendix A of RFC 3406. You can have references to other sections of your document from the registration template. I see that some subsections of section 5 have relevant information, but you don't provide all information required by the registration template.


In 7.7 - this should be another top level section.


In Attachment A:

The following ABNF productions are not defined. You need to either add them or add a comment how different pieces of LEX URNs related to each other:

local-name
DIGIT
HEXDIG

Can you elaborate on the purpose of the following production:

encoded = "%" ( 1*6DIGIT / ( "x" 1*6HEXDIG ) )

If it is meant to encoded Unicode characters that are represented as multiple octets in UTF-8, then your syntax is incorrect, because % is only allowed to be followed by 2 hexadecimal digits. See Section 2.1 of RFC 3986, which defines:

pct-encoded = "%" HEXDIG HEXDIG


C.1.1 - Do you have a recommendation on how can different versions be linked? Maybe link-relation can be used here?
2016-04-08
09 Alexey Melnikov IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2016-04-08
09 Alexey Melnikov Shepherding AD changed to Alexey Melnikov
2015-10-14
09 (System) Notify list changed from pierluigi.spinosa@ittig.cnr.it, enrico.francesconi@ittig.cnr.it, caterina.lupo@gmail.com, draft-spinosa-urn-lex@ietf.org to (None)
2014-04-29
09 Barry Leiba IESG state changed to AD Evaluation from Publication Requested
2014-04-29
09 Cindy Morgan IESG process started in state Publication Requested
2014-04-29
09 Cindy Morgan Notification list changed to : pierluigi.spinosa@ittig.cnr.it, enrico.francesconi@ittig.cnr.it, caterina.lupo@gmail.com, draft-spinosa-urn-lex@tools.ietf.org, andy@hxr.us
2014-04-29
09 Cindy Morgan Intended Status changed to Informational from None
2014-04-29
09 Cindy Morgan Changed document writeup
2014-04-29
09 Cindy Morgan Document shepherd changed to Andrew Newton
2014-04-29
09 Cindy Morgan Stream changed to IETF from None
2014-03-20
09 PierLuigi Spinosa New version available: draft-spinosa-urn-lex-09.txt
2013-09-17
08 PierLuigi Spinosa New version available: draft-spinosa-urn-lex-08.txt
2012-10-01
07 PierLuigi Spinosa New version available: draft-spinosa-urn-lex-07.txt
2012-04-02
06 PierLuigi Spinosa New version available: draft-spinosa-urn-lex-06.txt
2012-03-05
05 PierLuigi Spinosa New version available: draft-spinosa-urn-lex-05.txt
2011-09-06
04 (System) New version available: draft-spinosa-urn-lex-04.txt
2011-04-05
03 (System) New version available: draft-spinosa-urn-lex-03.txt
2011-04-04
04 (System) Document has expired
2010-10-01
02 (System) New version available: draft-spinosa-urn-lex-02.txt
2010-04-05
01 (System) New version available: draft-spinosa-urn-lex-01.txt
2009-11-09
00 (System) New version available: draft-spinosa-urn-lex-00.txt