Extensible Markup Language Evidence Record Syntax (XMLERS)
draft-ietf-ltans-xmlers-11

[Ballot comment]
Since at the time being there is no standard
  for an XML Time-Stamp, the following structure example is provided
  (referring to the Entrust XML Schema for Time-Stamp
  http://www.entrust.com/schemas/timestamp19protocol-20020207), which
  is a digital signature compliant to [XMLDSig] specification
  containing Time-Stamp specific data, such as time-stamped value and
  time within  element of a signature.

Is this enough for interoperability? The text almost looks informative,
however in other places in the document it is clear that a timestamp
field is mandatory.

   
     
         
             
             
             
             
             
             
             
             
         
     
 

[Ballot comment]
Ari Keränen helped me review this. Here are his comments:

There are some musts and mays (e.g., in Section 2.2 and 3) that could be capitalized (RFC2119'ised). I'd recommend going through all of them once more and capitalizing them when describing normative behavior.


2.1. Structure

       
       

I guess these should be:

       
       


    REQUIRED Order attribute to indicate the order within the parent
    element and an OPTIONAL Type attribute to indicate processing
    directions.

It is a bit confusing to have an *element* with the name "attribute" (that is the case, right?) when the same text uses also the term "attribute" to refer to element's (XML) attributes.


3.1.1. Hash Tree

  The newly calculated hash value is added to the next list of hashes

Should that be "concatenated" instead of "added"? (same issue is found multiple times in this section).



3.2.1. Generation of Hash Tree

  3. Group together items in the input list by the order of N

"order of N" is not defined. Should that be "order of the hash tree"?

[Ballot discuss]
[Updated. All my other issues were resolved. Please let me know if I missed a resolution or reply to the only remaining issue.]

3.1.2. Time-Stamp

  Since at the time being there is no standard
  for an XML Time-Stamp, the following structure example is provided
  (referring to the Entrust XML Schema for Time-Stamp
  http://www.entrust.com/schemas/timestamp19protocol-20020207), which
  is a digital signature compliant to [XMLDSig] specification
  containing Time-Stamp specific data, such as time-stamped value and
  time within  element of a signature.

Is this enough for interoperability? The text almost looks informative in places.

   
     
         
             
             
             
             
             
             
             
             
         
     
 

[Ballot discuss]
This is an updated discuss based on draft -11.

#1) addressed

#2) addressed

#3) addressed

#4) addressed

#5) addressed

#6) addressed

#7) addressed

#8) addressed

#9) addressed

#10) addressed

#11) addressed

[Ballot comment]
#1) addressed

#2) addressed

#3) addressed

#4) addressed

#5) Sec 2.1: Should probably also indicate how many of the fields can be included (i.e, match the +, ?, * in the schema to the text).

#6) I didn't see the changes for this one:

Sec 3.1.1: I put that hex string in to a couple of Base64 encoders and got:

QTk5OTNFMzYgNDcwNjgxNkEgQkEzRTI1NzEgNzg1MEMyNkMgOUNEMEQ4OUQ==

#7) addressed

[Ballot discuss]
This is an updated discuss based on draft -11.

#1) addressed

#2) addressed

#3) addressed

#4) addressed

#5) addressed

#6) Sec 3.1.1: What's the required Hash Algorithm?

#7) addressed

#8) addressed

#9) addressed

#10) addressed

#11) addressed

[Ballot comment]
COMMENTS

1. In Section 1.3, some of these terms are repeated from RFC 3275 and RFC 4051. Sometimes the definitions are the same (e.g., "Archive data object") and sometimes they are slightly different (e.g., "Evidence"). Why does this document not simply reference RFC 3275 and RFC 4051 for the repeated terms?

2. [addressed in -11]

3. [addressed in -11]

4. [addressed in -11]

5. [addressed in -11]

6. [addressed in -11]

7. [addressed in -11]

8. [addressed in -11]

9. [addressed in -11]

[Ballot discuss]
This a reconstructed review, since the first one was lost in a datatracker accident. My apologies if I have missed anything that was in the initial review.

(Updated per version -11 of the spec.)

DISCUSSES

1. [addressed in -11]

2. [addressed in -11]

3. [addressed in -11]

4. [addressed in -11]

5. Section 2.1 states:

    tag holds a  element with a Time-Stamp
  Token provided by the Time-Stamping Authority and optional element
  .

This makes it sound as if the structure of the  element (not "tag"!) is a sequence formed of a required  element and an optional  element. However, the schema in Section 7 defines the  element as having a mixed content model. This is confusing. Furthermore, mixed content models can make parsing more complex. Is there a good reason why this document defines a mixed content model for the  element?

As a further clarification, in Section 3.1.2 there can be found the following examples...

  For example:

  MIAGCSqGSIb3DQEH...

  or

  ...
  .

To prevent the mixed content model, why not do something like the following?

  MIAGCSqGSIb3DQEH...

That would enable you to define the schema as something like this:

 
     
       
       
     
 

Much simpler...

6. Section 2.1 states:

      tag contains additional information that may be
    provided by an LTA used to support processing of Evidence Records.
    An example of this supporting information may be a processing
    policy, like a renewal, a cryptographic (e.g. [RFC5698]) or an
    archiving policy. Such policies can provide inputs, which are
    relevant for data object(s) preservation and evidence validation at
    a later stage. Each data object is put into a separate child
    element , with a mandatory Order attribute to indicate
    the order within the parent element and an optional Type attribute
    to indicate processing directions.

This makes it sound as if the structure of the  element (not "tag"!) is a sequence formed of one or more required  elements. However, the schema in Section 7 defines the  element as having a mixed content model. This is confusing. Furthermore, mixed content models can make parsing more complex. Is there a good reason why this document defines a mixed content model for the  element?

7. Section 2.1 does not define the syntax and semantics for the 'Type' attribute of the  element or the  element. The text says only that this attribute is used "to indicate processing directions". What does that mean? What values are allowed? How is the application supposed to determine the processing directions based on the value of the 'Type' attribute? The lack of specification here will likely cause interoperability problems.

8. [addressed in -11]

9. In Section 3.1.2, the "ts:" prefix is undefined. Is it hardcoded to "ts:" or is that just an example? Is the "ts:" prefix associated with the (unspecified) namespace from ? Are you aware that the referenced URL currently yields an HTTP 404 error at www.entrust.com? Can you please provide a stable reference to the "Entrust XML Schema for Time-Stamp"? The lack of a clear definition or a stable reference is problematic. Finally, if the text beginning with  is intended to be a schema snippet that defines the  element, then this should be included in the schema within Section 7 or in a separate schema, and we should make sure that this contribution was made in conformance with the IETF's "Note Well" policy.

10. [addressed in -11]

11. In Section 7, I suggest that you redefine the schema so that it no longer uses mixed content models.

12. [addressed in -11]

13. [addressed in -11]

14. [addressed in -11]

15. [addressed in -11]

[Ballot comment]
COMMENTS

1. In Section 1.3, some of these terms are repeated from RFC 3275 and RFC 4051. Sometimes the definitions are the same (e.g., "Archive data object") and sometimes they are slightly different (e.g., "Evidence"). Why does this document not simply reference RFC 3275 and RFC 4051 for the repeated terms?

2. The text in Section 2.1 with lots of angle brackets looks like XML, but it's really a kind of pseudo-XML. This is confusing. For example, something like " +" is presumably meant to show that the  element may/should/must include an 'Order' attribute and a 'Type' attribute and that the element may/should/must be included one or more times. However, that's not clear from the text. I suggest saying that this is "pseudo-XML" and providing a forward pointer to the schema in Section 7 before the angle-bracket-blob.

3. In Section 2.1, this sentence is supposed to point to Section 7, not Section 6:

      The syntax of an evidence record is defined as an XML schema
      [XMLSchema], see Section 6.

4. Why does Section 2.1 include the XML declaration and the opening  tag? That is:

  The schema uses the following XML
  namespace [XMLName] urn:ietf:params:xml:ns:ers as default namespace
  and starts with following definition:

 
 

That information is duplicated from the schema in Section 7, but for no apparent reason. I suggest removing everything after "and starts with the following definition...".

5. Section 2.1 states:

  The XML tags have the following meanings:

However, XML attributes are not tags. Please use correct XML terminology. I suggest:

  The XML elements and attributes have the following meanings:

6. The document does not specify allowable values for the 'Algorithm' attribute of the  element. Could we possibly point to the IANA registry for "Hash Function Textual Names"  and recommend the use of those values?

7. The document does not specify allowable values for the 'Algorithm' attribute of the  element. Do we need a registry of such values?

8. In Section 3.1.2, please enclose the literal values "XMLENTRUST" and "RFC3161" in quotes. Thus:

  ...with values "XMLENTRUST" or "RFC3161" respectively...

9. In both Section 4.1.1 and 4.1.2, the values of the 'Algorithm' attribute seem to be limited to those defined in RFC 3275 and RFC 4051. Does that limit algorithm-agility?

[Ballot discuss]
This a reconstructed review, since the first one was lost in a datatrack accident. My apologies if I have missed anything that was in the initial review.

DISCUSSES

1. In Section 1.3, "Digest Method" is defined as a one-way hash function and in Section 2.1 the  element is described as "a required element" that "identifies the digest algorithm". However, in actuality (and in the XML schema) it is the 'Algorithm' attribute of the  element that identifies the one-way hash function, whereas the XML character data of the  element is the output of the hash function. This is confusing and will likely cause interoperability problems if not corrected.

2. Section 2.1 seems to state that the defined children of the  element are  and . However, the schema in Section 7 states that the element names are  and . These are in conflict and will likely cause interoperability problems if not corrected. Furthermore, the semantics of these child elements are not defined anywhere in the specification, which will also likely cause interoperability problems.

3. I concur with Alexey Melnikov's DISCUSS regarding the 'Version' attribute described in Section 2.1. I suggest looking at Section 4.7.5 of draft-ietf-xmpp-3920bis-22 for text about versioning. You might even be able to borrow some of that text directly, or modify it to meet your needs.

4. Section 2.1 states that the current version is "1.0". However, the XML schema in Section 7 fixes the version to "1", not "1.0". These are in conflict, and will likely cause interoperability problems if not corrected.

5. Section 2.1 states:

    tag holds a  element with a Time-Stamp
  Token provided by the Time-Stamping Authority and optional element
  .

This makes it sound as if the structure of the  element (not "tag"!) is a sequence formed of a required  element and an optional  element. However, the schema in Section 7 defines the  element as having a mixed content model. This is confusing. Furthermore, mixed content models can make parsing more complex. Is there a good reason why this document defines a mixed content model for the  element?

As a further clarification, in Section 3.1.2 there can be found the following examples...

  For example:

  MIAGCSqGSIb3DQEH...

  or

  ...
  .

To prevent the mixed content model, why not do something like the following?

  MIAGCSqGSIb3DQEH...

That would enable you to define the schema as something like this:

 
     
       
       
     
 

Much simpler...

6. Section 2.1 states:

      tag contains additional information that may be
    provided by an LTA used to support processing of Evidence Records.
    An example of this supporting information may be a processing
    policy, like a renewal, a cryptographic (e.g. [RFC5698]) or an
    archiving policy. Such policies can provide inputs, which are
    relevant for data object(s) preservation and evidence validation at
    a later stage. Each data object is put into a separate child
    element , with a mandatory Order attribute to indicate
    the order within the parent element and an optional Type attribute
    to indicate processing directions.

This makes it sound as if the structure of the  element (not "tag"!) is a sequence formed of one or more required  elements. However, the schema in Section 7 defines the  element as having a mixed content model. This is confusing. Furthermore, mixed content models can make parsing more complex. Is there a good reason why this document defines a mixed content model for the  element?

7. Section 2.1 does not define the syntax and semantics for the 'Type' attribute of the  element or the  element. The text says only that this attribute is used "to indicate processing directions". What does that mean? What values are allowed? How is the application supposed to determine the processing directions based on the value of the 'Type' attribute? The lack of specification here will likely cause interoperability problems.

8. Sections 2.2, 2.3, 3.2, 3.3, and 3.4 do not contain conformance terms (e.g., MUST or SHOULD) regarding the algorithms for generation and verification of data. This is worrisome, because implementers are likely to consider these algorithms non-normative. I strongly suggest modifying these sections to specify that the algorithms are MUST-implement.

9. In Section 3.1.2, the "ts:" prefix is undefined. Is it hardcoded to "ts:" or is that just an example? Is the "ts:" prefix associated with the (unspecified) namespace from ? Are you aware that the referenced URL currently yields an HTTP 404 error at www.entrust.com? Can you please provide a stable reference to the "Entrust XML Schema for Time-Stamp"? The lack of a clear definition or a stable reference is problematic. Finally, if the text beginning with  is intended to be a schema snippet that defines the  element, then this should be included in the schema within Section 7 or in a separate schema, and we should make sure that this contribution was made in conformance with the IETF's "Note Well" policy.

10. In Section 3.1.2 and elsewhere, please specify which flavor of Base64 is to be used for encoding. For example:

  The text value of the  element SHALL be the base64 encoding
  of this bit string viewed as a 20-octet octet stream, where the encoding
  MUST adhere to the definition from Section 4 of [RFC4648] with the padding
  bits set to zero.

11. In Section 7, I suggest that you redefine the schema so that it no longer uses mixed content models.

12. In Section 7, why is the type of the 'Version' attribute not "xs:decimal"?

13. In Section 7, why are you using processContents="skip" instead of processContents="lax"? That is, why are you preventing applications from validating the contents if they are able to do so?

14. In Section 7, there are only two defined values for the 'Type' attribute of the  element. Why not define an enumeration?

 
   
     
       
       
     
   
 

(I recognize that additional values might be defined in the future via registration with the IANA's new "Time-Stamp Toek Type" sub-registry, so that might be a reason not to define an enumeration.)

Is one of those values the default?

Is the datatype really "xs:string"? It seems to me that "xs:NMTOKEN" might be more appropriate.

15. In Section 7, there are only four defined values for the 'Type' attribute of the  element. Why not define an enumeration?

 
   
     
       
       
       
       
     
   
 

(I recognize that additional values might be defined in the future via registration with the IANA's new "Cryptographic Information Type" sub-registry, so that might be a reason not to define an enumeration.)

Is one of those values the default?

Is the datatype really "xs:string"? It seems to me that "xs:NMTOKEN" might be more appropriate.

[Ballot discuss]
2.1. Structure

The XML tags have the following meanings:

    Version attribute indicates the syntax version, for compatibility
    with future revisions of this specification and to distinguish it
    from earlier non-conformant or proprietary versions of the XMLERS.
    Current version of the XMLERS syntax is 1.0.

What is the meaning of major and minor versions and what are the requirements
on forward compatibility?


3.1.1. Hash Tree

  The algorithm by which a root hash value is generated from the
    element is as follows: the content of each 
  element within the first  element is base64 decoded to
  obtain a binary value (representing the hash value). All collected
  hash values from the sequence are ordered in binary ascending order,
  concatenated and a new hash value is generated from that string. With
  one exception from this rule: when the first  element has
  only one  element, then its binary value is added to the
  next list obtained from the next  element. The newly
  calculated hash value is added to the next list of hashes obtained

Does this sentence apply only together with the previous sentence
("With one exception from this rule") or unconditionally? If the latter,
then I suggest you split the paragraph into 2 paragraphs.

  from the next  element and the previous step is repeated
  until there is only one hash value left, i.e. when there are no
    elements left. The last calculated hash value is the root
  hash value. When an archive object is a group and composed of more
  than one data object, the first hash list MUST contain the hash
  values of all its data objects.


3.1.2. Time-Stamp

  Since at the time being there is no standard
  for an XML Time-Stamp, the following structure example is provided
  (referring to the Entrust XML Schema for Time-Stamp
  http://www.entrust.com/schemas/timestamp19protocol-20020207), which
  is a digital signature compliant to [XMLDSig] specification
  containing Time-Stamp specific data, such as time-stamped value and
  time within  element of a signature.

Is this enough for interoperability? The text almost looks informative in places.

   
     
         
             
             
             
             
             
             
             
             
         
     
   


3.2.1. Generation of Hash Tree

  Example: An input list with 18 hash values, where the h'1 is
  generated for a group of data objects (d4, d5, d6 and d7) and has
  been grouped by 3. The group could be of any size (2, 3...).

I am sorry for being dense, but I don't quite understand how this works from
the description and the ASCII art. Should grouping be done into groups
of the same size at each level of the tree?

  It is
  also possible to extend the tree with "dummy" values;

"Dummy" values don't contribute hashes, right?

  to make every
  node have the same number of children.

[Ballot comment]
3.1.2. Time-Stamp

  Time-Stamp Token is an attestation generated by a TSA that a data
  item existed at a certain time. The Time-Stamp Token is a signed data
  object that contains the hash value, the identity of the TSA, and the
  exact time (obtained from trusted time source) of Time-Stamping. This
  proves that the given data existed before the time of Time-Stamping.
  For example, [RFC3161] specifies a structure for signed Time-Stamp
  Tokens in ASN.1 format. Since at the time being there is no standard
  for an XML Time-Stamp, the following structure example is provided
  (referring to the Entrust XML Schema for Time-Stamp
  http://www.entrust.com/schemas/timestamp19protocol-20020207),

I think this URL should be made a proper reference

3.1.3. Cryptographic Information List

  Digital certificates, CRLs, SCVP or OCSP-Responses needed to verify
  the Time-Stamp Token SHOULD be stored in the Time-Stamp Token itself.
  When this is not possible, such data MAY be stored in the
    element, each data object into a

I think "is stored" is missing after "into".

  separate  element, using a mandatory Order
  attribute.


In 4.1.1: the first mentioning of "URI" needs an Informative Reference.

In 4.1.2: the first mentioning of "UTF-8" needs an Informative Reference.

[Ballot discuss]
This is an updated discuss based on draft -10.

In the general I think this document is fine, but I think there's some issues with the 2119-language (i.e., I think there needs to be more).  The authors need to do a review to ensure that there is 2119-language associated with the implementation requirements.  I found many, but I'm sure I missed some:

#1) Section 2.1 and 3:  I think you mean MUST in the following:

2.1: This process must continue during the
    desired archiving period of the archive data object(s)

3: To achieve this, an ATS
  must be renewed before it becomes invalid

If implementations don't do these steps then the whole thing falls apart.

#2) Section 2.1:  When describing the XML elements I think you need to use 2119 language for each element (i.e., is a MUST, SHOULD):

Add: The Version attribute MUST be included.

Change:  tag is OPTIONAL

Change:  tag is OPTIONAL

Change:  is REQUIRED and contains a sequence of one or more .

Change:  is a REQUIRED field that holds  .... and the order MUST be ...

Change:  is a REQUIRED

Change:  is a REQUIRED

Change:  is an OPTIONAL tag that holds...

Change:  is REQUIRED and it holds a  element with a Time-Stamp Token provided by the Time-Stamping Authority and OPTIONAL element .

Change:  is an OPTIONAL tag that

Change: The Order attribute is REQUIRED ...

#3) Sec 2.1: Need to explain what the TimeStampToken Type is.  It's later explained in 3.1.2 so maybe a pointer to it there?

#4) Sec 2.2 & 2.1: Step #2 seems to imply there is some kind of ordering that needs to be maintained for .  This is not captured in the  description in section 2.1.  If the order is to maintained then I think you should state this using 2119 language.

#5) Sec 3.1.1: Need a normative reference to RFC 4648 for Base64 encoding.  Also note that there are two alphabets.  You need to specify which one is used.

#6) Sec 3.1.1: What's the required Hash Algorithm?

#7) addressed

#8) Sec 3.1.3:  Mandatory isn't 2119-lagnuage.  Use MUST/REQUIRED.

#9) addressed

#10) Sec 4.1.2: .. (URIs) MUST be used ...

#11) In the IANA considerations you need to say under what circumstances the registry will be updated.  See Sec 4.1 of http://tools.ietf.org/html/rfc5226.

[Ballot comment]
#1) Expand: ERS, ASN.1 in abstract

#2) Delete the "Conventions" before the TOC.  There's already a section in 1.4 for 2119 language.

#3) Section 1.1 & 3: (tales from the crypt) What's a "decomposing Time-Stamping authority"?  Should it be decommissioning TSA?

#4) Section 1.3, TS definition: I think you need to add:  [ISO-18014-1.2002], [ISO-18014-2.2002], [ISO-18014-3.2004], and [ANSI.X9-95.2005] as informative references.

#5) Sec 2.1: Should probably also indicate how many of the fields can be included (i.e, match the +, ?, * in the schema to the text).

#6) Sec 3.1.1: I put that hex string in to a couple of Base64 encoders and got:

QTk5OTNFMzYgNDcwNjgxNkEgQkEzRTI1NzEgNzg1MEMyNkMgOUNEMEQ4OUQ==

#7) Sec 3.1.2): Expand CRLs, SCVP and OCSP.

[Ballot discuss]
In the general I think this document is fine, but I think there's some issues with the 2119-language (i.e., I think there needs to be more).  The authors need to do a review to ensure that there is 2119-language associated with the implementation requirements.  I found many, but I'm sure I missed some:

#1) Section 2.1 and 3:  I think you mean MUST in the following:

2.1: This process must continue during the
    desired archiving period of the archive data object(s)

3: To achieve this, an ATS
  must be renewed before it becomes invalid

If implementations don't do these steps then the whole thing falls apart.

#2) Section 2.1:  When describing the XML elements I think you need to use 2119 language for each element (i.e., is a MUST, SHOULD):

Add: The Version attribute MUST be included.

Change:  tag is OPTIONAL

Change:  tag is OPTIONAL

Change:  is REQUIRED and contains a sequence of one or more .

Change:  is a REQUIRED field that holds  .... and the order MUST be ...

Change:  is a REQUIRED

Change:  is a REQUIRED

Change:  is an OPTIONAL tag that holds...

Change:  is REQUIRED and it holds a  element with a Time-Stamp Token provided by the Time-Stamping Authority and OPTIONAL element .

Change:  is an OPTIONAL tag that

Change: The Order attribute is REQUIRED ...

#3) Sec 2.1: Need to explain what the TimeStampToken Type is.  It's later explained in 3.1.2 so maybe a pointer to it there?

#4) Sec 2.2 & 2.1: Step #2 seems to imply there is some kind of ordering that needs to be maintained for .  This is not captured in the  description in section 2.1.  If the order is to maintained then I think you should state this using 2119 language.

#5) Sec 3.1.1: Need a normative reference to RFC 4648 for Base64 encoding.  Also note that there are two alphabets.  You need to specify which one is used.

#6) Sec 3.1.1: What's the required Hash Algorithm?

#7) Sec 3.1: Think you meant MUST:

The Attribute type MUST be used ...

and

...  element MUST contain

#8) Sec 3.1.3:  Mandatory isn't 2119-lagnuage.  Use MUST/REQUIRED.

#9) Sec 4.1.1: ... those MUST be used ...

#10) Sec 4.1.2: .. (URIs) MUST be used ...

#11) In the IANA considerations you need to say under what circumstances the registry will be updated.  See Sec 4.1 of http://tools.ietf.org/html/rfc5226.

Upon approval of this document, IANA understands that there are five
IANA Actions that need to be completed.

First, in the IANA XML ns registry located at:

http://www.iana.org/assignments/xml-registry/ns.html

a new XML namespace will be registered as follows:

id: ers
URI: urn:ietf:params:xml:ns:ers
Registration template: none
Reference [RFC-to-be]

Second, in the IANA XML schema registry located at:

http://www.iana.org/assignments/xml-registry/schema.html

a new XML schema will be registered as follows:

id: ers
URI: urn:ietf:params:xml:schema:ers
filename: Provided by Section 6 of the approved document
reference: [RFC-to-be]

Third, IANA is to create a new IANA registry entitled "XML Evidence
Record Syntax (ERSXML)". This registry will contain two sub-registries:

"Time-Stamp Token Type" and
"Cryptographic Information Type"

The policy for future assignments to both sub-registries is "RFC
Required". The reference for both sub-registries is to be [RFC-to-be].

Fourth, the "Time-Stamp Token Type" subregistry is to have the following
initial values:

Value Description Reference
----- ------------- ------------------------

RFC3161 RFC3161 Time-Stamp Token RFC 3161
XMLENTRUST EnTrust XML Schema
http://www.entrust.com/schema/timestamp19protocol-20020207

Fifth, the sub-registry "Cryptographic Information Type" will have the
following initial values:

Value Description Reference

----- ------------------ -----------------
CERT DER-encoded X.509 Certificate RFC 5280
CRL DER-encoded X.509 RFC 5280
Certificate Revocation List
OCSP DER-encoded OCSPResponse RFC 2560
SCVP DER-encoded SCVP response RFC 5055
(CVResponse)

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

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Extensible Markup Language Evidence Record Syntax) to Proposed Standard


The IESG has received a request from the Long-Term Archive and Notary
Services WG (ltans) to consider the following document:
- 'Extensible Markup Language Evidence Record Syntax'
  as a 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 2011-01-11 (note extension by one week to
provide ample review time). 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.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ltans-xmlers/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ltans-xmlers/

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Carl Wallace


  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

Yes. The document has received slight but sufficient review. It
specifies an XML equivalent of ERS (RFC4998).

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

No.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

No.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

Within the LTANS context, the support is sufficiently solid. The draft
has been before the working group for years.  There were some late
objections related to bundling DSSC policies in the structure, but this
is not done in ERS and there's been no compelling reason given for doing
so here.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

The IDNITS output was inspected.  There were no warnings of concern.


  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

Yes, the references have been split. No, there are no normative
references to documents that are not ready for advancement.  There are
no downward references.

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

There is an IANA section that is consistent with discussion held during
the last working group meeting.  The AD can decide which method is best
for IANA registration.  The draft proposes "RFC Required" but "Expert
Review" is probably fine too.


  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

The authors provided output from an XML schema checking tool and the
results were reviewed by the document shepherd.

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
            In many scenarios, users must be able to demonstrate the
(time of) existence,
            integrity and validity of data including signed data for
long or undetermined periods of time.
            This document specifies XML syntax and processing rules for
creating evidence for
            long-term non-repudiation of existence of data. ERS-XML
incorporates alternative syntax
            and processing rules to ASN.1 ERS syntax by using XML
language.

          Working Group Summary
            The WG process was uneventful. The document is an XML
equivalent of ERS [RFC4998].

            Author's Note: some of the authors of the document are not
native English speakers.
            There was review and correction of language/grammar and the
AD suggested at the
            last WG meeting (in Maastricht) that it is ok to submit the
draft for IETF LC and leverage
            the superior professional editing skills of the RFC editor
for final language adjustments if necessary.

          Document Quality
            There are a few existing implementations of the protocol.
The specification may pick-up further implementations after its release
as RFC (i.e. when implementers can rely on it being stable).

          Personnel
          Document Shepherd: Carl Wallace
            Responsible AD: Tim Polk