Followup on draft-mraihi-inch-thraud-06.txt (was re: Gen-ART Last Call Review of draft-mraihi-inch-thraud-05)

Ben Campbell <ben@estacado.net> Thu, 03 July 2008 21:42 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1F253A6947; Thu, 3 Jul 2008 14:42:48 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A6803A6964 for <ietf@core3.amsl.com>; Thu, 3 Jul 2008 14:42:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 5X95RRNk76sz for <ietf@core3.amsl.com>; Thu, 3 Jul 2008 14:42:47 -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 D42D03A6912 for <ietf@ietf.org>; Thu, 3 Jul 2008 14:42:45 -0700 (PDT)
Received: from dn3-213.estacado.net (dn3-213.estacado.net [172.16.3.213]) (authenticated bits=0) by estacado.net (8.14.2/8.14.1) with ESMTP id m63Lgkw8047890 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Jul 2008 16:42:47 -0500 (CDT) (envelope-from ben@estacado.net)
Message-Id: <90B2B95C-7E91-4FE9-BC65-6B06EA358711@estacado.net>
From: Ben Campbell <ben@estacado.net>
To: General Area Review Team <gen-art@ietf.org>
In-Reply-To: <4ECA6E44-AAB2-417F-B49D-BCEF5D34CB5D@estacado.net>
Mime-Version: 1.0 (Apple Message framework v926)
Subject: Followup on draft-mraihi-inch-thraud-06.txt (was re: Gen-ART Last Call Review of draft-mraihi-inch-thraud-05)
Date: Thu, 03 Jul 2008 16:42:46 -0500
References: <4ECA6E44-AAB2-417F-B49D-BCEF5D34CB5D@estacado.net>
X-Mailer: Apple Mail (2.926)
Cc: sharon.boeyen@entrust.com, ietf@ietf.org, michael.grandcolas@hotmail.com, sbajaj@verisign.com, dmraihi@verisign.com
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

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 mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf