[Lager] Stephen Farrell's Discuss on draft-ietf-lager-specification-11: (with DISCUSS and COMMENT)

"Stephen Farrell" <stephen.farrell@cs.tcd.ie> Thu, 21 April 2016 10:24 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: lager@ietf.org
Delivered-To: lager@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4334212D6A9; Thu, 21 Apr 2016 03:24:01 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.19.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160421102401.19578.54300.idtracker@ietfa.amsl.com>
Date: Thu, 21 Apr 2016 03:24:01 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/lager/ScUg6V2QJTipTGTwQk-bpG6sHsI>
Cc: audric.schiltknecht@viagenie.ca, draft-ietf-lager-specification@ietf.org, lager-chairs@ietf.org, lager@ietf.org
Subject: [Lager] Stephen Farrell's Discuss on draft-ietf-lager-specification-11: (with DISCUSS and COMMENT)
X-BeenThere: lager@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Label Generation Rules <lager.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lager>, <mailto:lager-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lager/>
List-Post: <mailto:lager@ietf.org>
List-Help: <mailto:lager-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lager>, <mailto:lager-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2016 10:24:01 -0000

Stephen Farrell has entered the following ballot position for
draft-ietf-lager-specification-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lager-specification/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


This spec is tackling a hard problem, (machines doing what
humans do to classify identifiers), and as a result there are
some tricky bits here. That inherently hard problem has thrown
up a few things I'd like to discuss (though the 1st one is
easy:-)...

(1) section 5: this says code points MUST be 4 hex digits.
What is s/w supposed to do if it sees only 2 hex digits?
Should it ignore the range or char element or fail to process
the entire LGR document? I think the same issue applies to
other uses of 2119 language as well, (e.g. "MUST be treated as
an error at the end of p19), so I'd recommend you state some
kind of general rule if you can.

(2) 5.2: when and not-when etc seem to me to allow for
infinitely baroque representations of useless things like: 

	<char cp="200D" when="cpisnot200D" />
	<classs "cpis200D">
		200D
	</class>
	<rule name="cpisnot200D">
		<start/>
			<complement><class by-ref="cpis200D"/></complement>
		<end/>
	</rule>

What is parsing s/w supposed to do with structures like that?
For example, how would you handle the likes of this or more
convoluted but equivalent structures which could be delivered
by accident or deliberately?  I think the response to this
discuss point needs to either be a) all such constructs are
automatically detectable and here's why, or else b) here's how
s/w can handle that (without crashing or looping forever).
Note that I don't think that the "MUST be rejected" at the end
of 6.1 provides an answer to this point.  (But if you do,
please argue that.)

(3) 6.3.4: While recursion is said to be disallowed, the "for
which the complete definition has not been seen" is pretty odd
for an XML specification, as it means that you need a full
ordering for the elements in the document (or at least within
the <rules> element).  That means if some editor decodes from
disk and then encodes to disk, you need to be sure that the
order is preserved or else you break the "has been seen"
constraint. (And if you do that, then you're allowing rules to
mutually refer to one another, which brings us back to discuss
point 2.) 7.4 maybe has a similar issue. I think for this you
could simply state up front that these XML documents MUST NOT
be re-ordered during editing. (Or else add some kind of
attribute to help with ordering which seems ickky.)

(4) section 12: I don't think this is at all sufficient.
Missing aspects include: Imprecise LGRs could result in
registration of identifiers that are unexpected in many other
protocols, leading to new vulnerabilities; LGRs could be
deliberately manipulated so as to create such imprecision, and
if I could feed one such to a registry (e.g. via some nice
friendly looking git repo) then I could exploit the vuln later
for fun and profit - that seems to call for some
interoperable form of data integrity and origin
authentication (is the lager WG doing that?) and lastly (for
now), the XML language defined here is very flexible as noted
earlier - I would expect there to be many implementation bugs
in new code that attempts to parse this language. So I think
the security considerations needs to be re-done really.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- 4.3.6: my bet: validity-end is a mistake.

- 4.3.8: odd that the examples have no URLs

- 4.3 generally: I bet that these objects will evolve and will
be stored in some VCS. I'm surprised so that there's no
meta-data element to represent information about the version
of say the previous instance of the object. If there were,
then it would then be possible to establish a hash-chain which
I'd have thought would be useful in disputes.

- 5.3.1: "normally not only symmetric, but also transitive" -
isn't that hugely ambiguous?  What is the programmer supposed
to do? The answer is "nothing" I think so I'd just recommend
to delete that paragraph and say that only the explicitly
stated rules apply.

- 6.2.4: "repertoire" - please define that term or reference a
definition. I don't think it's a commonly understood technical
term, at least for implementers.  

- 8.2: What "suitable optimisations" do you mean? It seems
cruel to the implementer to say that but not even have a
reference.

- 8.5: I think you could have explained this more clearly - the
2nd para there is not really useful as it's too opaque.

- Appendix C: Another example of BNF being impressively
more terse than XML :-)