Representing Label Generation Rulesets Using XML
draft-ietf-lager-specification-13

[Ballot discuss]

Thanks for the changes in -12. I think we're down to one
remaining item to discuss. I'll follow up on the earlier email
where you answered directly to this point.

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

[Ballot 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:



200D







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

[Ballot 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 :-)

[Ballot comment]
IESG: if this document doesn't get any DISCUSSes and I am unable to call, I would like to have it in Approved::Point Raised - Writeup Needed (or whatever the state is).

My review comments sent to the WG: https://www.ietf.org/mail-archive/web/lager/current/msg00312.html

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-lager-specification-11.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are three actions which IANA must complete.

First, in the Media Types registry located at:

http://www.iana.org/assignments/media-types/

a new Media Type in the application subregistry will be created as follows:

Name: lgr+xml
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Second, in ns subregistry of the IETF XML Registry located at:

https://www.iana.org/assignments/xml-registry/

a new URI will be registered as follows:

ID: lgr-1.0
URI: urn:ietf:params:xml:ns:lgr-1.0
Filename: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, a new registry is to be created called the Label Generation Ruleset Dispositions registry. This will be a new registry on the IANA Protocol Registries page located at:

https://www.iana.org/protocols

The new registry will contain two, new subregistries.

The first of these will be the Standard Dispositions subregistry. This new subregistry will be managed through Specification Required as defined in RFC 5226. There are initial registrations in this new registry as follows:

Disposition Description Reference
-----------+----------------------------------------------------------------+-------------+
invalid The resulting string is not a valid label. This disposition [ RFC-to-be ]
may be assigned implicitly, see Section 7.5 of [ RFC-to-be ].
No variant labels should be generated from a variant mapping
with this type.

blocked The resulting string is a valid label, but should be blocked [ RFC-to-be ]
from registration. This would typically apply for a derived
variant that is undesirable due to having no practical use or
being confusingly similar to some other label.

allocatable The resulting string should be reserved for use by the [ RFC-to-be ]
same operator of the origin string, but not automatically
allocated for use.

activated The resulting string should be activated for use. (This [ RFC-to-be ]
is the same as a preferred variant in [RFC3743].)

valid The resultant string is a valid label. (This is the typical [ RFC-to-be ]
default action if no dispositions are defined.)
-----------+----------------------------------------------------------------+-------------+

The second subregistry will be the Private Dispositions subregistry. This new subregistry will be managed through First Come First Served as defined by RFC5226.

The format of the registry is:

Disposition Description/Purpose Reference/Registrant
-----------+----------------------------------------------------------------+--------------------+

-----------+----------------------------------------------------------------+--------------------+

There are no initial registrations in the Private Dispositions subregistry.

IANA understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-lager-specification@ietf.org, lager-chairs@ietf.org, audric.schiltknecht@viagenie.ca, "Audric Schiltknecht" , barryleiba@gmail.com, lager@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Representing Label Generation Rulesets using XML) to Proposed Standard


The IESG has received a request from the Label Generation Rules WG
(lager) to consider the following document:
- 'Representing Label Generation Rulesets using XML'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-04-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  This document describes a method of representing rules for validating
  identifier labels and alternate representations of those labels using
  Extensible Markup Language (XML).  These policies, known as "Label
  Generation Rulesets" (LGRs), are used for the implementation of
  Internationalized Domain Names (IDNs), for example.  The rulesets are
  used to implement and share that aspect of policy defining which
  labels and Unicode code points are permitted for registrations, which
  alternative code points are considered variants, and what actions may
  be performed on labels containing those variants.


The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lager-specification/

When IESG discussion begins, it can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lager-specification/ballot/

No IPR declarations have been submitted directly on this I-D.

1. Summary

The document shepherd is Audric Schiltknecht.
The responsible Area Director is Barry Leiba.

  This document describes a method of representing rules for validating
  identifier labels and alternate representations of those labels using
  Extensible Markup Language (XML).  These policies, known as "Label
  Generation Rulesets" (LGRs), are used for the implementation of
  Internationalized Domain Names (IDNs), for example.  The rulesets are
  used to implement and share that aspect of policy defining which
  labels and Unicode code points are permitted for registrations, which
  alternative code points are considered variants, and what actions may
  be performed on labels containing those variants.

The document is seeking Standards Track as it is the normative specification on the format and processing of Label Generation Rulesets.

2. Review and Consensus

The document was presented and discussed during at least two IETF meetings.
It has the support of the WG, and there are at least three independent implementations of LGR processor with good coverage of WLE processing; the format described is already used in expressing Root Zone LGR for various writing systems.

3. Intellectual Property

The authors have affirmed that they have no knowledge of any IPR associated to the document and are submitting it in compliance with BCPs 78 and 79.

There was no on-list discussion of IPR matters and none were reported.

4. Other Points

The document makes normative references to the Unicode Standard; these are correct and approved by the WG.

The document requests two new registrations in existing IANA registries:
- a new entry in the Media Type registry which has been reviewed by the media-types experts and comments have been integrated in the document;
- a new entry in the XML registry for a new namespace.
The document also requests the creation of a new IANA registry, to manage LGR dispositions. All requirements for such registry are met.

The RFC Editor should be advised that the appendix tracking document changes should be deleted prior to publication.