[Gen-art] Gen-ART Last Call Review of draft-mraihi-inch-thraud-05
Ben Campbell <ben@estacado.net> Tue, 18 March 2008 19:52 UTC
Return-Path: <gen-art-bounces@ietf.org>
X-Original-To: ietfarch-gen-art-archive@core3.amsl.com
Delivered-To: ietfarch-gen-art-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F2FF3A6EBD; Tue, 18 Mar 2008 12:52:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.797
X-Spam-Level:
X-Spam-Status: No, score=-100.797 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdnGwA1B3TXa; Tue, 18 Mar 2008 12:52:05 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F0C73A69BB; Tue, 18 Mar 2008 12:52:05 -0700 (PDT)
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 215E43A67F2 for <gen-art@core3.amsl.com>; Tue, 18 Mar 2008 12:52:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsRXhw-lLcTw for <gen-art@core3.amsl.com>; Tue, 18 Mar 2008 12:52:00 -0700 (PDT)
Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 0CC363A6E86 for <gen-art@ietf.org>; Tue, 18 Mar 2008 12:51:54 -0700 (PDT)
Received: from [10.0.1.195] (adsl-68-94-31-41.dsl.rcsntx.swbell.net [68.94.31.41]) (authenticated bits=0) by estacado.net (8.14.2/8.14.1) with ESMTP id m2IJnOJc027749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Mar 2008 14:49:29 -0500 (CDT) (envelope-from ben@estacado.net)
Message-Id: <4ECA6E44-AAB2-417F-B49D-BCEF5D34CB5D@estacado.net>
From: Ben Campbell <ben@estacado.net>
To: gen-art@ietf.org
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Tue, 18 Mar 2008 14:49:24 -0500
X-Mailer: Apple Mail (2.919.2)
Cc: sharon.boeyen@entrust.com, ietf@ietf.org, tim.polk@nist.gov, michael.grandcolas@hotmail.com, sbajaj@verisign.com, dmraihi@verisign.com
Subject: [Gen-art] Gen-ART Last Call Review of draft-mraihi-inch-thraud-05
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: gen-art-bounces@ietf.org
Errors-To: gen-art-bounces@ietf.org
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 resolve these comments along with any other Last Call comments you may receive. Document: draft-mraihi-inch-thraud-05 Reviewer: Ben Campbell Review Date: 2008-03-18 IETF LC End Date: 2008-03-20 IESG Telechat date: (if known) Summary: This document is almost ready for publication as an informational RFC, but there are issues which should be considered first. Comments: --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? _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
- [Gen-art] Gen-ART Last Call Review of draft-mraih… Ben Campbell
- [Gen-art] Followup on draft-mraihi-inch-thraud-06… Ben Campbell