Skip to main content

A Uniform Resource Name (URN) Namespace for Sources of Law (LEX)


No Objection

(Deborah Brungard)


Note: This ballot was opened for revision 13 and is now closed.

Roman Danyliw
Discuss (2020-02-19 for -13) Sent
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

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
Comment (2020-02-19 for -13) Sent
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.
Éric Vyncke
Comment (2020-02-20 for -13) Sent
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...
Adam Roach Former IESG member
Discuss [Treat as non-blocking comment] (2020-02-19 for -13) Sent
This document refers to itself as a "standard" in approximately 30 different places. This seems problematically misleading for a document being published as Informational.
Alexey Melnikov Former IESG member
(was Yes) Discuss
Discuss [Treat as non-blocking comment] (2020-02-21 for -13) Sent
[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.
Alissa Cooper Former IESG member
Discuss [Treat as non-blocking comment] (2020-02-19 for -13) Sent
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.
Benjamin Kaduk Former IESG member
Discuss [Treat as non-blocking comment] (2020-02-19 for -13) Sent
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

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

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.
Deborah Brungard Former IESG member
No Objection
No Objection (for -13) Not sent

Barry Leiba Former IESG member
Abstain (2020-02-07 for -13) Sent
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.