[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 :-)
- [Lager] Stephen Farrell's Discuss on draft-ietf-l… Stephen Farrell
- Re: [Lager] Stephen Farrell's Discuss on draft-ie… Alexey Melnikov
- Re: [Lager] Stephen Farrell's Discuss on draft-ie… Stephen Farrell
- Re: [Lager] Stephen Farrell's Discuss on draft-ie… Asmus Freytag (c)
- Re: [Lager] Stephen Farrell's Discuss on draft-ie… Asmus Freytag (c)
- Re: [Lager] Stephen Farrell's Discuss on draft-ie… Asmus Freytag (c)
- Re: [Lager] Stephen Farrell's Discuss on draft-ie… Alexey Melnikov
- Re: [Lager] Stephen Farrell's Discuss on draft-ie… Asmus Freytag (c)
- Re: [Lager] Stephen Farrell's Discuss on draft-ie… Asmus Freytag (c)
- Re: [Lager] Stephen Farrell's Discuss on draft-ie… Alexey Melnikov
- Re: [Lager] Stephen Farrell's Discuss on draft-ie… Asmus Freytag (c)
- Re: [Lager] Stephen Farrell's Discuss on draft-ie… Asmus Freytag (c)
- Re: [Lager] Stephen Farrell's Discuss on draft-ie… Alexey Melnikov
- Re: [Lager] Stephen Farrell's Discuss on draft-ie… Asmus Freytag (c)
- Re: [Lager] Stephen Farrell's Discuss on draft-ie… Stephen Farrell
- Re: [Lager] Stephen Farrell's Discuss on draft-ie… Asmus Freytag (c)
- Re: [Lager] Stephen Farrell's Discuss on draft-ie… Alexey Melnikov
- Re: [Lager] Stephen Farrell's Discuss on draft-ie… Alexey Melnikov
- Re: [Lager] Stephen Farrell's Discuss on draft-ie… Stephen Farrell
- Re: [Lager] Stephen Farrell's Discuss on draft-ie… Asmus Freytag (c)
- Re: [Lager] Stephen Farrell's Discuss on draft-ie… Stephen Farrell
- Re: [Lager] Stephen Farrell's Discuss on draft-ie… Asmus Freytag (c)