Re: [apps-discuss] Request for review: draft-ietf-mile-rfc6045-bis-01

Larry Masinter <masinter@adobe.com> Sat, 03 December 2011 19:21 UTC

Return-Path: <masinter@adobe.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C3D21F8E7C for <apps-discuss@ietfa.amsl.com>; Sat, 3 Dec 2011 11:21:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xWtElIQRf1c for <apps-discuss@ietfa.amsl.com>; Sat, 3 Dec 2011 11:21:48 -0800 (PST)
Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by ietfa.amsl.com (Postfix) with ESMTP id AF41821F9309 for <apps-discuss@ietf.org>; Sat, 3 Dec 2011 11:21:35 -0800 (PST)
Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKTtp2tlDQph+AlcUXC5pLzRl+Z1mD/hsn@postini.com; Sat, 03 Dec 2011 11:21:47 PST
Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pB3JLPZc002225; Sat, 3 Dec 2011 11:21:25 -0800 (PST)
Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id pB3JLLRH027344; Sat, 3 Dec 2011 11:21:22 -0800 (PST)
Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Sat, 3 Dec 2011 11:21:21 -0800
From: Larry Masinter <masinter@adobe.com>
To: SM <sm+ietf@elandsys.com>, "Kathleen.Moriarty@emc.com" <Kathleen.Moriarty@emc.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "draft-ietf-mile-rfc6045-bis.all@tools.ietf.org" <draft-ietf-mile-rfc6045-bis.all@tools.ietf.org>
Date: Sat, 03 Dec 2011 11:21:18 -0800
Thread-Topic: Request for review: draft-ietf-mile-rfc6045-bis-01
Thread-Index: Acyx2y1gEK186n+jT7SbNHZ7d0jy1QAC1hmw
Message-ID: <C68CB012D9182D408CED7B884F441D4D0612042FE3@nambxv01a.corp.adobe.com>
References: <6.2.5.6.2.20111203082441.0a251830@elandnews.com>
In-Reply-To: <6.2.5.6.2.20111203082441.0a251830@elandnews.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [apps-discuss] Request for review: draft-ietf-mile-rfc6045-bis-01
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Dec 2011 19:21:49 -0000

Document:  draft-ietf-mile-rfc6045-bis-01
Title: Real-time Inter-network Defense
Reviewer: Larry Masinter
Review Date: 12/3/2011

Summary:
This draft is not ready for publication as a Proposed Standard and should be revised before publication.

Major issues:
The document defines a language for describing a security incident intended for exchange between services or service providers, but the terminology used for describing incidents and the extensibility and refinement of that terminology is not clear and doesn't seem to be managed.
But this is a preliminary review about the status & intent... 

Minor issues:
The status of the document seems to be confusing or incorrect.  The introduction says "This document moves Real-time Inter-network Defense (RID) [RFC6045]    to Historic status as it provides minor updates."  And the status lists that it "updates" RFC 6045.

In fact, the document seems to be a revision of all of RFC 6045
 http://tools.ietf.org/rfcdiff?url1=rfc6045&url2=draft-ietf-mile-rfc6045-bis-01
which moves from "Informational"  to Standards Track.
There doesn't seem to be a summary of "Changes from RFC 6045" which explains what changed, based on actual practice..


Details:

There are several namespaces of enumerated values ("TrafficType", "PolicyRegion", ...) which seem to depend on a common understanding of the meaning of the terminology, but which do not define the terms sufficiently (in my opinion) for anyone to know how to use this.

To pick a couple of examples:

PolicyRegion starts out with "region", and there are mysterious labels. "One. Enum."
There is likely a convention in the document for this, but I think unless it is an explicit table it is better to be more specific. 

The bulk of the document contains what seem like definitions of terms in a vocabulary, such as:

> ClientToSP.  An enterprise initiated the request to their service provider.

But the terms "enterprise" and "service provider" are defined ... where? Is my home network an enterprise? What is the scope or scale of an enterprise?  Could different service providers define what an "enterprise" is differently? What is the utility of this value in an incident report?

>   LawEnforcement.  This option is used when incident information is exchanged with LawEnforcement, local government,
>  or other authorities assisting with an investigation.  If the law enforcement agency resides within a different nation that
>  the sending entity, the "crossNationalBoundaries" enumeration MUST also be set .

Again, many undefined terms, and no particular way, indication, hint, of how to clarify them, when they apply, what constitutes a "local government" across the world, etc.   What is a "National Boundary"? Is it a legal jurisdiction? What about security incidents where there is some dispute about what constitutes a "national boundary"? How would one use this value? If you expect consistent processing of incident reports from multiple sources, don't you need to insure common understanding of the terms? And if you don't, why is it standards track?

The extensibility of the protocol is unclear... how are these terms clarified, how do they evolve, what happens when different organizations interpret the terms differently? Is there a registry? Can the set of terms change?  

I understand the desire to pass semantic information between multiple parties about security incidents, but I think the fundamental problem is in the management of the evolution of a common understanding of the terminology and namespace supplied.

Larry
--
http://larry.masinter.net