Subject: [Gen-art] Gen-ART review of draft-ietf-ltans-dssc-08.txt

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 17 Jun 2009 15:54:07 +0200

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-ltans-dssc-08.txt
Reviewer: Miguel Garcia <[email-masked]>
Review Date: 17 June 2009
IESG Telechat date: 18 June 2009

Summary: This draft is on the right track but has open issues, described 
in the review.

Major issues: none

Minor issues:

- The draft lacks formality about the XML. I suspect no one from the XML 
directorate has reviewed this draft. I am trying to do my best, but I 
highly recommend that someone from the XML directorate reviews and 
provide additional comments to the XML. I also recommend the authors to 
read RFC 3470 and follow the guidelines described in there.

- I am surprised to see that the namespace of the XML document is not in 
the IETF tree, but instead set to http://www.sit.fraunhofer.de/dssc. 
According to RFC 3470:

    In the case of namespaces in IETF standards-track documents, it would
    be useful if there were some permanent part of the IETF's own web
    space that could be used for this purpose.  In lieu of such, other
    permanent URIs can be used, e.g., URNs in the IETF URN namespace (see
    [11] and [12]).  Although there are instances of IETF specifications
    creating new URI schemes to define XML namespaces, this practice is
    strongly discouraged.

Also please, consider RFC 3688, in which case, the namespace of the XML 
document should be:

urn:ietf:params:xml:ns:dssc

which, of course, MUST be registered with IANA (but this is another story 
described below).

- Central to this document is the definition of the XML schema. I don't 
like to see the XML schema buried to a middle appendix, even when the 
appendix is classified as normative. The recommendation is to promote the 
XML schema to its own section, for example, between Sections 5 and 6. I 
would also move the complete XML example to its own section as well.

- I am missing some normative text saying that implementations according 
to this specification MUST implement this XML schema. For your 
convenience, let me provide an example of other RFCs that have captured 
the text. You can adapt it to your document as you wish:

    DSSC is an XML document [xx] that MUST be well-formed and
    SHOULD be valid.  DSSC documents MUST be based on XML 1.0 and
    MUST be encoded using UTF-8 [yy].
    This specification makes use of XML
    namespaces for identifying DSSC documents.  The namespace URI
    for elements defined by this specification is a URN [zz], using the
    namespace identifier 'ietf'.  This URN is:

       urn:ietf:params:xml:ns:dssc

Notice also the normative references to:

    [xx]  Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler,
          "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
          FirstEdition REC-xml-20001006, October 2000.

    [yy]   Yergeau, F., "UTF-8, a transformation format of ISO 10646",
          STD 63, RFC 3629, November 2003.

    [zz]   Moats, R., "URN Syntax", RFC 2141, May 1997.

which are also missing from this document.

- Associated MIME type. Many IETF XML documents have an associated MIME 
type. Well, this depends on whether someone is going to use the MIME type 
or not. Assume you want to attach a DSSC document to a web page, e-mail, 
etc. In that case, a MIME type might be beneficial. If you need one, you 
should add the following text (after the previous comment):

    DSSC documents are identified with the MIME type
    "application/dssc+xml" and are instances of the XML schema
    defined in Section sss.

- XML schema extensibility and Unique Particle Attribution Constraint. 
So, the first thing is that the XML schema does not offer any 
extensibility point, other than adding more parameter types.  I don't 
know if there is an extensibility strategy behind, but I believe this XML 
schema will need to be extended in the future, perhaps with additional 
information parameters. Assume that you need to add, for example, the 
"reason" why an algorithm is no longer valid, a new element within the 
Algorithm element, a pointer to the certificate of the examiner, or 
something like that. Currently it is no possible to add these extensions. 
So, you should add hooks (e.g., <any> elements) more often. However, you 
must be careful and bear in mind the Unique Particle Attribution 
Constraint rule to avoid ambiguity.

- Have you validated your XML schema and the XML example with a suitable 
validator, for example, http://validate.openlaboratory.net/ ? I haven't 
done it myself, just prefer to ask first.

- Section 3.4 provides a partial XML schema whose purpose is to hold a 
civic address. A question first... Why do you need to split the civic 
address into each of their components? Is it because an automata is 
suppose to read it, parse it, and point some address on a map (or 
something like that). If the information is merely be read by a human 
being, then it is much simpler to add a string element called <Address> 
that can hold the full address in a human readable format without further 
  subelements.

But if you have requirements for automata parsing of the address, then 
the elements you have defined in the current <Address> is FAR from being 
useful. For example, you cannot represent a Post Office Box. You cannot 
represent many complex civic address used in different places in this 
planet. The Geopriv WG went to the nightmare of representing all possible 
address in the world, and they failed at the first time. Presumably they 
have succeeded on their second attemp, so, I recommend you to read RFCs 
4119 and 5139 and investigate whether you can import and reuse the 
civicAddress element defined there.

- Section 3.7 defines the Usage element. It is currently a string, so, it 
seems like a free-format text intended for human consumption. Is this 
correct? If not, I would suggest an enumeration of possible values. So, 
what is the intended use of this Usage element?

- Section 3.9 defines the AlgorithmIdentifier. I think the "Name" of the 
AlgorithmIdentifier cannot be a free format text (string). because it 
would be valid, but useless, to have, for example, different policies 
referring to "SHA1", "sha1", "SHA-1", and "sha-1". This is because 
implementations will recognize one or a subset of all the possible "free 
formats" for each algorithm. One possible solution is to say in the 
verbal text that possible values are those included in a registry. For 
example, if you were using cryptographic hash algorithms, then you could 
use the following registryt:
http://www.iana.org/assignments/hash-function-text-names/
But in your examples, I've noticed that you are referring to other 
algorithms that are not listed there. You can try to find any other 
existing registry, or use one and extend it with new values.

- Section 3.11 defines 3 elements, <Min>, <Max>, and <Range>. I don't 
understand why you need 3. I think you should need either <Min><Max> or 
<Range>, but not all 3. Specially, <Range> says that it consist of a 
minimum and a maximum value. So can't you survive with <Min> and <Max> if 
you allow both to be present at a given time? Then you have the means to 
define a range.

- I've noticed in Sections 3.14, 4, and 6 that there are many lower-case 
normative words, where it appears that they should be capitalized 
according to RFC 2119. For example:

"The signature must relate to the SecuritySuitabilityPolicy element. "

"... the SecuritySuitabilityPolicy element must have the optional id
attribute"

"This attribute must be used to reference the SecuritySuitabilityPolicy 
element... "

"... the signature must use the transformation algorithm ..."

"The parameter of RSA should be named "moduluslength". "

"The parameters for DSA should be "plength" and "qlength"."

"Publishers must ensure"

"Operators should only accept"

etc... Please consider the capitalization of those normative reserved words.

- Section 6, the 2nd bullet point reads:

   "It must not be possible to alter or replace a
    security suitability once accepted by the client."

Honestly, I don't understand how to implement this requirement. Which 
entity has to do what?

- Section 7, IANA considerations, says that there are no actions to IANA. 
If my previous comments are accepted, then you need to add IANA 
considerations to register:
   + the XML schema
   + the URN Sub-Namespace
   + the MIME type

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Thomas Kunz <[email-masked]>
Date: Wed, 24 Jun 2009 17:46:38 +0200

Miguel,

thanks for reviewing the draft. I think we will adopt most of your 
comments. Thus I will address only some of your issues:

Miguel A. Garcia schrieb:

> appendix is classified as normative. The recommendation is to promote 
> the XML schema to its own section, for example, between Sections 5 and 
> 6. I would also move the complete XML example to its own section as well.
> 
I personally doesn't like to have the XML schema in an own section. 
Besides I would always expect things like XML schemata, ASN.1 
definitions or extended examples in the appendix.
Reasons:
- In section 3 we have the complete XML schema, divided into fragments, 
and text to explain the schema. So the XML schema as a whole in the 
appendix is primarily intended for implementors which can easily cut and 
paste.
- Keep in mind that we have also an ASN.1 representation. If we put the 
XML schema in its own section, we have to do the same with the ASN.1 
definitions.
- IMO many pages of XML schema and ASN.1 definitions bother the reader, 
so it's better to put this stuff in the appendix.

> done it myself, just prefer to ask first.
Yes, we have validated the schema.

> that can hold the full address in a human readable format without 
> further  subelements.
> 
The address is merely to be read by humans. But I prefer a structured 
data format for better readability. Maybe we add a hook in the Address 
element so that the address can be extended.

> minimum and a maximum value. So can't you survive with <Min> and <Max> 
> if you allow both to be present at a given time? Then you have the means 
> to define a range.
> 
That's right. We could keep only the <Range> consisting of <Min> and <Max>
and remove the <Min> and <Max> elements outside <Range>.
Only <Min> and <Max> without the <Range> would make the data structure 
unnecessary complicated since it should not be allowed to have e.g 
<Exact> and <Min>.

- Thomas

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 25 Jun 2009 09:18:01 +0200

Hi Thomas:

Some inline comments.

Thomas Kunz wrote:
>> - Central to this document is the definition of the XML schema. I 
>> don't like to see the XML schema buried to a middle appendix, even 
>> when the appendix is classified as normative. The recommendation is to 
>> promote the XML schema to its own section, for example, between 
>> Sections 5 and 6. I would also move the complete XML example to its 
>> own section as well.
>>

Ok, I think you have a good motivation, so I accept your comments.

> 
>>
>> - Have you validated your XML schema and the XML example with a 
>> suitable validator, for example, http://validate.openlaboratory.net/ ? 
>> I haven't done it myself, just prefer to ask first.
>>
>> being, then it is much simpler to add a string element called 
>> <Address> that can hold the full address in a human readable format 
>> without further  subelements.
>>
> element so that the address can be extended.ç

So, if the address is intended to be read by humans, first I would write 
it in the draft. And then, I still don't see any benefit by structuring 
the address as you have it, when it is going to be consumed by a human, 
who will need to assemble all the structure to use it. And the problem 
you get is what I already mentioned: the current structure does not allow 
for writing all the possible combinations of addresses in the the world.

>> understand why you need 3. I think you should need either <Min><Max> 
>> or <Range>, but not all 3. Specially, <Range> says that it consist of 
>> a minimum and a maximum value. So can't you survive with <Min> and 
>> <Max> if you allow both to be present at a given time? Then you have 
>> the means to define a range.
>>

In this case, I think this data is to be consumed by an automata, so I 
think it would be useful to allow a better parsing that a <Range>. The 
problem with <Range> is that you need to provide code for allowing white 
spaces, dashes, and all sort of separations. For example, you should have 
code that allows to read a range in any of the following formats:
<Range>10-14</Range>
<Range>10 - 14</Range>
<Range>10, 14</Range>

If you have a <Min> and <Max> elements, everything is crystal clear, 
because the only way to express that range is:
<Min>10</Min>
<Max>14</Max>

And this make <Exact> redundant. Actually, you should also remove it. An 
exact value is expressed by the same value in the <Min> and <Max> 
elements, for example:
<Min>10</Min>
<Max>10</Max>

So, I think this covers all your use cases. If you add some text to the 
draft indicating how to express an exact value, you would be done with 
only <Min> and <Max>.

I hope this helps,

          Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain