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

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.

This document refers to itself as a "standard" in approximately 30 different places. This seems problematically misleading for a document being published as Informational.

[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.

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 <https://mailarchive.ietf.org/arch/msg/gen-art/A9NBHgeHucLGHlIDgZvAaq7-RyU> 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 <https://mailarchive.ietf.org/arch/msg/gen-art/xR44OWrdejWK77_8CywYhuYsvZo> 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.

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.