Re: [Gen-art] Gen-ART Telechat review of draft-spinosa-urn-lex-13

Alissa Cooper <alissa@cooperw.in> Thu, 20 February 2020 04:54 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1090812023E; Wed, 19 Feb 2020 20:54:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=z3p5N2zW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=1Fs9u2Pf
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwstZVuptq1G; Wed, 19 Feb 2020 20:54:52 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6990A1201E4; Wed, 19 Feb 2020 20:54:52 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1AD6B21EA0; Wed, 19 Feb 2020 23:54:51 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 19 Feb 2020 23:54:51 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=D xoKu2VrwHBQTQMaEerZTBfz8wlhsZIZNfxA1yul5SQ=; b=z3p5N2zWAwwgP8jFt 8bURLQF2kitYJj4dPuN1e+hu4UXMThYP8jR7e+Mc2oU7qEjzteYtLE3fqjIv9GW+ hmzMo9tVZMQwkXSYEN1vLpIf/vooyF7WbNN9IUmDUPmeIwVH+qsW/WroE9pM2h9L TrD4FHJsMEAowv+A9VaB+HTa70H84gDE6NGb8JiwvMjI5WGpFHo5zqwBcY6JDI0h zLtwt8yy8kdSJ5emrvoYawmfkmSQ1jFyIUcAt1AOv6jApjkHbvW1jBS8b01GExuL BXhyZEbVsnK13MQnOgy97XbgbK4b0FJHqzMz2CHy3Eeb2NPrEw62OQBJEC3HHYTh BD7jQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=DxoKu2VrwHBQTQMaEerZTBfz8wlhsZIZNfxA1yul5 SQ=; b=1Fs9u2Pf5NpO49ABPSNPht9+ANT5g8Ljbin5r0D+qzgnHBbd75vOwiwZe Cb05Z+3abK/t0vXT58LCgLUW40zScW5phgULSGmOFCawEAp6ih096LSwE0K8+lyV r2bijoLgqPyVrgC+5eQpiHtWb+ZTCQfnsgGHVGB7xT5ziQ87uJ7SYC8p6dMBffDe vGHMKMj0gp4B3gf/KLwIdHvpw3zdPYM7DxEix+2X3UvKkwvICUyu9GccrAJqhJ8y vTfszJJgdyXvAs2vm8kR4VtjIZJnnozO5/Wd0srXys3D8cP7XTmQQyyIwkEwrbI2 qEtw91ra4IlVw2Cmg17bHHXkAhS4A==
X-ME-Sender: <xms:GhFOXpGuVEo2f3kcCBEE4zOUEqZTHX_Vk0vJdY00JVXef18ng1kcow>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrkedugdejjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdekkeenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhishhsrgestghooh hpvghrfidrihhn
X-ME-Proxy: <xmx:GhFOXnzP0RNWBXethkIB5S14lEjw3WD1dDjcNfJlmIDuQabcqMAkIQ> <xmx:GhFOXqsNpQ3x9yuqu4Z5wZYq361sajhjzQDJMXHU22W2Zi4YX3XzZA> <xmx:GhFOXk2HHYXMAONXp8pYQHxGiu-LRBexInwWMhMi2w2bZMU0oUjaSQ> <xmx:GxFOXj8yiT2YjiMYKOBewDCLcJyfPBCd8d2hAoWEv2vEakF-rjXmxA>
Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.88]) by mail.messagingengine.com (Postfix) with ESMTPA id 421253280063; Wed, 19 Feb 2020 23:54:50 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <197a361d-6be6-e768-11b2-df06d5df8752@alum.mit.edu>
Date: Wed, 19 Feb 2020 23:54:49 -0500
Cc: draft-spinosa-urn-lex.all@ietf.org, General Area Review Team <gen-art@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <575667A4-D4EE-492B-A5DF-A4B6B8CAA579@cooperw.in>
References: <197a361d-6be6-e768-11b2-df06d5df8752@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/7PUJ16nvE6n2euL3S_HZEuReqnY>
Subject: Re: [Gen-art] Gen-ART Telechat review of draft-spinosa-urn-lex-13
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Feb 2020 04:54:57 -0000

Paul, thanks for your review. I have cc’ed you on my DISCUSS ballot.

Best,
Alissa


> On Feb 18, 2020, at 1:29 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Document: draft-spinosa-urn-lex-13
> Reviewer: Paul Kyzivat
> Review Date: 2020-02-18
> IETF LC End Date: 2017-09-14
> IESG Telechat date: 2020-02-18
> 
> Summary:
> 
> This draft is on the right track but has open issues, described in the review.
> 
> General:
> 
> I did a Last Call review on version -11 three years ago. Given the amount of time that has passed, and the extent of changes, I'm surprised that there wasn't another Last Call prior to scheduling the Telechat!
> 
> I had difficulty classifying the severity of the issues. Individually most of them may be minor, but in aggregate they imply that IMO the document still requires a lot of work.
> 
> Issues:
> 
> Major: 1
> Minor: 15
> Nits:  2
> 
> 1) MAJOR: Structure & ordering of the document
> 
> In spite of my earlier experience with this document I found it very difficult to read in a single front to back pass. In retrospect, I think it would have made much more sense if I had read Section 7 first.
> 
> A major problem was that I got the impression it was a goal that an arbitrary legal document reader should be able to construct a valid LEX URN to that document from information readily available to him, typically in the body of the document itself. Yet I found many places where terms must be chosen in ways that are not deterministic.
> 
> In retrospect, especially after reading Section 7, I tentatively reached the conclusion that my first impression was wrong. Instead, it appears that an expert (probably within the Jurisdiction Registrar) must choose the LEX URN representation(s) for the legal document. This can then be incorporated into the document and/or some metadata about the document that is potentially available to those who later have need to reference the document.
> 
> I'm not sure I'm right about this. How this is intended to work should be spelled out early in the document. I suggest moving Section 7 early in the document, and elaborating it to cover this.
> 
> Section 3 (Registration Template) is very hard to follow when reading the document front to back. Understanding it requires information that hasn't yet been provided. In particular, section 3.1 gives an overview of the syntax of 'jurisdiction', but not for 'local-name'. It then goes on to present examples of full lex URNs.
> 
> I suggest that it would be helpful to move sections 2 and 3 to a position later in the document - somewhere after section 5. Near or in Section 11 (IANA considerations) would be a good place.
> 
> 2) MINOR(?): Encoding national characters and diacritic signs
> 
> Section 4.4 has guidelines for encoding national characters and diacritic signs for compatibility with DNS. I'm not qualified to evaluate whether these guidelines are in agreement with best practice for DNS. If it hasn't already, this document should be reviewed and approved by relevant experts.
> 
> 3) MINOR: Section 5 (Specific Syntax and Features of the LEX Identifier):
> 
> It isn't clear to me what specific components of the syntax are being addressed in this section. I *think* these apply to 'jurisdiction-unit'. Can you please make this clear?
> 
> I'm concerned that most of the specifications here are only RECOMMENDED. Who makes the decision whether to follow these rules, and how can it be assured that they are followed consistently? It is a problem if a consistent approach to these isn't followed. For instance, when a reader of a document is trying to create a LEX URN manually from a reference in the text, how will he know whether to follow the recommendation or not?
> 
> (However, if the expectation is that an expert constructs the URN then this is less of a concern.)
> 
> 4) MINOR: Annexes and Sub-Annexes:
> 
> When I read Section 6.4 the first time I was confused about the significance of multiple annexes in a name - whether this refers to peer annexes of the main document, or to a sub-annex of an annex. I later learned (in section 7) that it means sub-annexes. This is an example of why the doc needs reordering. Or else spell this out in this section.
> 
> 5) MINOR: "original" as document version
> 
> Both sections 6.6 and C1.2 discuss using "original" as the document version to identify the original version of the document. But this is allowed to be written in different languages. However it doesn't specify how the language for this is chosen. How can someone constructing the URN from a textual reference decide which spelling to use? More specification is needed.
> 
> 6) MINOR: Manifestation:
> 
> The following in section 6.7:
> 
>   Note that the value "all" can be expressed by language-dependent
>   equivalents. To indicate possible features or peculiarities, each
>   main element of the manifestation MAY be followed by further
>   specifications, for example as regards <format> the version, for
>   <editor> the archive name and the electronic publisher, etc.
> 
> doesn't appear to be normative regarding what the "specification" means for any particular element. Rather it merely gives "examples". There needs to be normative text defining the semantics. (Section 7 clarifies things to an extent, but also isn't normative.)
> 
> Also, as with "original" above, the language to be used for "all" isn't specified.
> 
> Also, by using semicolon to separate the format from its specification you have excluded using semicolon to denote mime type parameters, as is conventionally done. (E.g., in Content-Type header fields.) Some mime types have mandatory parameters, so this will exclude using those types at all. Some discussion of mime type parameters is needed.
> 
> The following example:
> 
>   - XML format (version 2.2 DTD NIR) of the text of the act and PDF
>     format (version 1.7) of the "Figura 1" (figure 1) contained in the
>     body, edited by the Italian Senate:
>     "urn:lex:it:stato:legge:2000-04-03;56$text-xml;dtd-nir-
>     2.2:senato.it:testo"
> 
> introduces further confusion, by mapping "XML format (version 2.2 DTD NIR)" to "text-xml;dtd-nir-2.2". I see nothing that specifies how to perform this mapping. Nor how to find out what this means. It appears to be very ad hoc. Also, the XML Format is normally encoded within the XML itself, so why should it be encoded in the LEX URN?
> 
> Then I had trouble deciphering the following example:
> 
>   the Spanish URN of the html format of the whole Judgement of the
>   European Court of Justice n. 33/08 of 11/06/2009, in Spanish version,
>   published in the Jurifast data base in anonymized form:
>   "urn:lex:eu:tribunal.justicia:sentencia:2009-06-11;33-
>   08@original:es$   the Spanish URN of the html format of the whole Judgement of the
>   European Court of Justice n. 33/08 of 11/06/2009, in Spanish version,
>   published in the Jurifast data base in anonymized form:
>   "urn:lex:eu:tribunal.justicia:sentencia:2009-06-11;33-
>   08@original:es$text-html:juradmin.eu;jurifast:todo:anonimo"
> 
> As best I understand, "todo" is the 'component' and "anonimo" is the 'feature. I discovered the Spanish "todo" means "everything" in English. So apparently this means the anonymized form of everything. But how would someone know to use "todo" or "everything"? Is the language for this word determined by language tag in "original:es"? And even if the language is well defined, how is the term to use ("everything" rather than "all", etc.) determined? Again this seems underspecified, and may lead to interoperability problems.
> 
> (Is this covered by section 7.2 that puts this responsibility on the Jurisdictional Registry? If so, it would be good to have an exhaustive list of things that the Jurisdictional Registry must define.)
> 
> 7) MINOR: Partition Identifiers:
> 
> It appears that section 6.8 is attempting to invent a one-off mechanism for partition identifiers that is entirely redundant to the r- and q- components of a URI as specified in RFC8141. ISTM it would be better to embrace those mechanisms.
> 
> 8) MINOR: Resolution Examples:
> 
> While the high level intent of section 8.1 is reasonably clear, the details are not. Some concrete examples showing relevant DNS records would be extremely helpful.
> 
> 9) MINOR: Catalogs for Resolution:
> 
> While a catalog db for lex URN resolution (section 8.2) could offer some advantages, it will be only as good as the content that populates it. For such a catalog to be well populated it will probably need to be fed the results of applying a good resolver algorithm, such as described in section 8.3. If you have that, then the db really only serves as a optimizer.
> 
> I think this section needs better explanation.
> 
> 10) MINOR: Normalizing the Partition ID:
> 
> Section 8.3 says to separate the Partition ID and then use it determine what to return. Not mentioned is that the partition ID itself may be inaccurate, so normalization of it is also likely to be required. This may even involve a trial and error mechanism to try different transformations of the partition ID until the one that works is found. Again it would be helpful for the document to mention this.
> 
> 11) MINOR: Returning multiple manifestations:
> 
> The following in Section 8.3:
> 
>   Lacking more specific indications, the resolver SHOULD select the
>   best (most recent) version of the requested source of law, and
>   provide all the manifestations with their related items.
>   A more specific indication in the uniform name to be resolved will,
>   of course, result in a more selective retrieval, based on any
>   suggested expression and/or manifestations components (e.g. date,
>   language, format, etc.).
> 
> implies that multiple items are to be returned. The form to return these isn't specified. Are these to be returned as a single document containing all this information? (May or may not be possible.) Or as multiple documents? (Represented how?) For instance, if I'm looking for text/plain and there are multiple annexes, will they come back as a multipart/mixed, or a zip of the parts, or simply a concatenation of all the pieces as a single text/plain? How will it know what I'm prepared to receive? (For some retrieval protocols the types I can receive are specified in the request.)
> 
> 12) MINOR: Jurisdiction-code registration
> 
> Section 11.2 doesn't address what is to happen when a domain name that has been used as a jurisdiction code is assigned to a different entity. (And can this also happen for ccTLDs?) The old owner of the domain name may then get a different domain name. And both the old and new entities may want to assign LEX URNs. This situation needs to be addressed.
> 
> And regarding the IANA Jurisdiction-code Registry, it is common practice when defining a new IANA registry to supply a template for what must be supplied. Perhaps the first bullet list in section 11.2 is intended to be that, but it is pretty vague, especially regarding the registrant. It should be more explicit about what information is to be provided and the format for how it is to be provided in a new registration and how it is to be represented in the IANA registry.
> 
> 13) MINOR: jurisdiction-code syntax:
> 
> I suspect the following syntax in Attachment A:
> 
>   jurisdiction-code = 2*alf-dot
> 
> is not exactly what you want, though I'm not certain exactly what you do want. I suspect you are trying to forbid a code that is a single character. If so, then the following might be better:
> 
>   jurisdiction-code = alfanum alf-dot
> 
> 14) MINOR: ABNF ambiguities (Attachment A):
> 
> First, the rule 'specification' is used in a variety of contexts. But the semantics differ with the context. I strongly recommend making them separate rule names that correspond to the semantics they denote. And then refer to the corresponding names in the text.
> 
> Also, the following is ambiguous:
> 
>   ;-------------------------------------------------------------------
>   ; Structure of the <authority> element
>   ;-------------------------------------------------------------------
>   authority = issuer *("+" issuer)
>   issuer = (institution *(";" body-function)) / office
>   institution = alf-dot
>   body-function = alf-dot
>   office = alf-dot
> 
> Something matchng 'alf-dot' could be either an 'institution' or a 'office'. This can present problems when using tools to generate a parser from the ABNF.
> 
> 15) MINOR: Purpose of Attachment D (Http LEX Identifier):
> 
> There are no references to Attachment D within the body of the document, and it seems entirely unnecessary to the understanding of the document. And it doesn't appear to be normative.
> 
> Consideration should be given to moving this to another document describing a system for using and resolving LEX URNs.
> 
> If it is to be retained in this document, then there should be a reference to it from within the body of the document, explaining its reason for being included.
> 
> 16) NIT: Use of "However":
> 
> Section 3.2 says:
> 
>   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.
> 
> The use of "However" here is confusing. It seems to suggest that this is an exception to conformance with RFC8141. If that is not what is intended, then this should be reworded. For instance:
> 
>   The "lex" NID syntax conforms to [RFC8141]. A series of
>   characters are reserved to identify elements or sub-elements, or for
>   future extensions of the identifier. Hence only a subset of the
>   syntax allowed by RFC8141 is available for definition of local-names.
> 
> 17) NIT: Use of "Recently"
> 
> There are a couple of uses of "recently" that won't (haven't) age(d) well:
> 
> In the following text from section 2:
> 
>         The use of r- and q- components, recently introduced by
>         [RFC8141], with LEX URNs is not defined in this document.
> 
> RFC8141 is now almost three years old. I don't think you can still call this recent.
> 
> There is a similar issue in the following from Section D1:
> 
>   Http URIs have been recently promoted as stable and location-
>   independent identifiers [RFC3986].
> 
> This same wording was in version -11 from three years ago, so it isn't very recent. And if the "recent" reference is really in RFC3986 then it is much older.
> 
> In both cases I think you should find more suitable wording that recognizes that these are by now well established.
> 
> (THE END)
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art