Eric,
Thanks very much for your review. Just a couple of quick comments:
In section 3.7.1 - you say:
"The XML format for CT-KIP messages have been designed to be
extensible. However, it is possible that the use of extensions will
harm interoperability and therefore any use of extensions should be
carefully considered."
Can we say anything about what "harm interoperability" or "carefully
considered" means? What are the risks? How can they be avoided?
Is there a reference you can point to that talks about the issues?
I can add an explanation and example (of course, it means the document
won't be a true republication anymore, but this can be clarified in the
abstract).
In section 3.8.6 (CT-KIP server's second PDU), on pages 27 and 28,
I am having trouble matching message fields (shown on page 27) with
descriptions (given on pages 27 and 28).
The initial fields in the description are attributes inherited from the
abstract type (c.f. 3.8.5 that makes it explicit that the Version
attribute is inherited from the abstract type). I can clarify this.
I agree with your suggestions for the nits, but will, as you propose, hold
back on making any changes until all comments have been received and Russ
has had a chance to discuss them with me.
-- Magnus
On Wed, 5 Jul 2006, Gray, Eric wrote:
Magnus,
I am the assigned Gen-ART reviewer for:
draft-nystrom-ct-kip-01.txt
For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
Please wait for instructions from Russ Housley before
taking any action on these comments.
This document is nearly ready for publication as an
Informational RFC.
I have some questions/comments and a few very minor
NITs.
Comments:
========
General Comment:
---------------
The abstract claims this is almost entirely a literal
republication of a document produced by the OTPS service
of RSA Laboratories - who intends to retain change control.
The abstract specifically excludes the Intellectual Propety,
and IANA, Considerations sections.
I'm not sure what that means with respect to handling of
comments relative to the "republished" material.
Also, it's a minor point but, unless the previous document
was also an RFC (I saw no indication that this was true),
there are quite a few other portions of the current draft
that probably did not exist in the original document (RFC
boiler-plate, reference sections and author information,
for example).
Perhaps this is implied by the phrase "body of this ..."
I read through the document. It appears to be well thought
out and written, and I did not see anything that is ambiguous
or obviously unclear - although (not being an expert in this
area) some sections just eluded comprehension for me.
Specific Comments/Questions:
---------------------------
In section 3.7.1 - you say:
"The XML format for CT-KIP messages have been designed to be
extensible. However, it is possible that the use of extensions will
harm interoperability and therefore any use of extensions should be
carefully considered."
Can we say anything about what "harm interoperability" or "carefully
considered" means? What are the risks? How can they be avoided?
Is there a reference you can point to that talks about the issues?
---------------------------------------------------------------------
In section 3.8.6 (CT-KIP server's second PDU), on pages 27 and 28,
I am having trouble matching message fields (shown on page 27) with
descriptions (given on pages 27 and 28).
---------------------------------------------------------------------
NITs:
----
In section 5.2.1, the last sentence would be better worded as:
"Sections 5.2.2 through 5.2.7 analyze these attack scenarios."
---------------------------------------------------------------------
In section 6 (IANA Considerations), you say:
"None at this point; the MIME type is already registered."
The document mentions several MIME types. I assume you meant:
"application/vnd.otps.ct-kip+xml" in this case (as opposed to
- for instance - "image/jpeg" or "image/gif").
I would change the section to read either -
"None at this point; the MIME type (section 4.2.2) is already
registered."
OR
"IANA has no action with respect to this document."
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
