I reviewed performed a Gen-ART last-call review on draft-mraihi-inch-
thraud-05. Since my review, the authors published version 06 of that
draft. I'm not sure what the current status of the draft is, so here
is an informal followup on my original review.
Summary: This draft is almost ready for publication as a informational
RFC. I have (a much smaller set of ) comments that should be
considered prior to publication.
General:
This draft is a significant rewrite of the previous version, and is
much easier to follow. It no longer claims to specify a protocol, and
a lot of text appears to have been removed. I think this is a much
better draft, but I am surprised to see this much change post IETF LC.
(I'm not suggesting any action here--just pointing it out)
Otherwise, most of my previous comments are addressed, although I have
a few minor new ones.
Specific:
Section 1, paragraph 4:
Were the lower case "should" and "may" in this paragraph intended to
be normative?
Paragraph 7:
IODEF is referenced as a work in progress draft--is it expected to
progress with this draft?
Section 5.2.1:
What does the "xs" in "xs:string" refer to? It _looks_ to me that it
is merely an XML namespace prefix (i.e. xmlns:xs="..."), which is
fairly ephemeral. That is, any given document might use a different
prefix. It seems odd to use it in the text this way. I guess the text
is intended for humans that may reasonably be expected to figure it
out. In any case, this usage is pervasive through the document (also
for "iodef:" and "thraud:").
5.4.1:
Is there any registration or other mechanism to promote consistent
usage for new OtherEventTypes? What keeps people from picking the same
type for different kinds of new events, or use inconsistent types for
otherwise similar new events?
Section 7, definition of Incident.Method.URL:
Can you offer any guidance on what sort of URI is appropriate here?
Additionally, IDNITS reports the following:
Miscellaneous warnings:
----------------------------------------------------------------------------
-- The exact meaning of the all-uppercase expression 'NOT REQUIRED'
is not
defined in RFC 2119. If it is intended as a requirements
expression, it
should be rewritten using one of the combinations defined in RFC
2119;
otherwise it should not be all-uppercase.
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'OATH' is defined on line 791, but no explicit
reference was found in the text
== Unused Reference: 'XMLSIG' is defined on line 798, but no explicit
reference was found in the text
On Mar 18, 2008, at 2:49 PM, Ben Campbell wrote:
--General:
I'd like to see some text clarifying the relationship of this draft
to the Open Authentication initiative. The draft states that the
work has been endorsed by that group. Is this draft merely intended
to document work done by that group? (I note that the XML name space
is scoped to http://www.openauthentication.org/. ) Or is intended to
specify an interoperable extension to the IODEF format? If the
latter, how much consideration has been given to whether this should
properly be an informational vs a standards-track RFC?
--Detailed Comments:
Abstract:
Please expand IODEF on first use.
Section 1, paragraph 4:
Please expand IODEF and XML on first use.
Paragraph 5:
"Verification procedures and the specific requirements for
authorization are outside the scope of this specification."
Are these requirements specified elsewhere? They seem pretty
fundamental for this mechanism to be useful.
Section 4, paragraph 3:
"The primary difference in the "inbound" and "outbound" reports is
the removal in the "outbound" reports of reporting organization
information in order to protect confidentiality. We elaborate on
this aspect in section 7, Security Considerations."
It's a little unclear to me at this point what the outbound report
contains and what it is used for. Maybe a discussion of what network
element comsumes "inbound" reports and what generates "outbound
reports" would help.
Section 4, 2nd paragraph on Page 7
(nit) There is an unfortunate line break in EventData.AdditionalData
that has the effect of rendering the paragraph incoherent. It looks
like AdditionalData starts a new sentence.
Section 5.4.1:
Has there been thought whether OtherEventType needs to be registered
somewhere?
Section 6.2:
The section is titled "Optional Contents" but goes on to say these
contents SHOULD be included. That's really stronger than "optional".
Perhaps the section should be retitled something to the effect of
"Recommended Contents".
paragraph 6:
"The IPv4 or IPv6 address or subnet mask..."
Address of what?
Section 6.3, first paragraph:
I'm having trouble parsing the last paragraph. I suspect a missing
comma, along with the inconsistent verb tense ("performing",
"views", "has changed") contribute to the problem.
Method.URL:
"A URL that represents the detailed definition of the fraud event
signature."
Does represent mean that the URL points to the definition, or
somehow encodes it? Is there a definition of the format of the data
this will point to? What URL schemes can go here?
Section 8:
I think the security consideration section should talk a little more
on what attacks are known possible, and how the required security
features address them. That is, _why_ we need signatures, etc. Don't
just assume it to be obvious.
Section 8.3, first paragraph:
"A simple mechanism MUST enable the query of any data to return a
valid reponse without disclosing the unique Identifier of a
specific organization. "
Is the requirement that such a mechanism must simply exist, or that
the implementation must actually use it?
paragraphs 2 through end of section
"We suggest to use" should probably be recast as normative
language. Also, I'd like to see a little more about how
OpaqueIdentifier is to be used--I gather that the publisher needs to
be able to correlate the OpaqueIdentifier with the original
IncidentID Field in the future? If so, we should mention that.
Section 8.4:
I think we need a little more here--if you use a secure transport,
do you still need application level crypto? Can you say a little
more about what security properties are needed? Also, do you mean
SSL or TLS?
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf