[apps-discuss] apps-team review of draft-cdmi-mediatypes-04
Barry Leiba <barryleiba@computer.org> Fri, 17 December 2010 15:54 UTC
Return-Path: <barryleiba@gmail.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00F043A68DA for <apps-discuss@core3.amsl.com>; Fri, 17 Dec 2010 07:54:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.137
X-Spam-Level:
X-Spam-Status: No, score=-102.137 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 5ds0Me7BWwZn for <apps-discuss@core3.amsl.com>; Fri, 17 Dec 2010 07:54:52 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 228283A68E2 for <apps-discuss@ietf.org>; Fri, 17 Dec 2010 07:54:52 -0800 (PST)
Received: by iyi42 with SMTP id 42so554276iyi.31 for <apps-discuss@ietf.org>; Fri, 17 Dec 2010 07:56:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lBGpK48QXqdROQj3DSxjZXJcOjwwRUqzwd8QNqf3MsY=; b=a17kcxizIRtfBkycOs2zKU3qFn7NTRggjC9bYFxR46sqLqvlS3i4MQ3yI+yj45VxnH GbgeyrfXdqR0fOCnpriM6GhC1VH24VlPH2Y8w0ybPL4QwizmjPZLSvjS5pvEXYD1mrDU r4xp9M2TyI+1m0TDDtw1T76E10mo5tS5x6EFE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=R42lsXjQAj0wQFr6QtQPpe/hForBu2e3y54tOGsTLcLLX9CKOZlSNs/Xqb6ZTdhwJl CtA8SR87E6Nemo7FOde0TcTP1pUa73xClCyWRsQwr51j2YypXjfQsnpN1wToJIGhlv52 7RPy26QTUZ4qsTYYHFAuuWTzUG7BKjJ0PdX8c=
MIME-Version: 1.0
Received: by 10.231.11.204 with SMTP id u12mr920932ibu.109.1292601399247; Fri, 17 Dec 2010 07:56:39 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.231.208.12 with HTTP; Fri, 17 Dec 2010 07:56:39 -0800 (PST)
Date: Fri, 17 Dec 2010 10:56:39 -0500
X-Google-Sender-Auth: djDpOp1t7hg3JrLzPGBX6jIE3Ik
Message-ID: <AANLkTika+=bL=Jz9S=46-V32_qbR9dJ=asQucO5-cmG2@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: draft-cdmi-mediatypes.all@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] apps-team review of draft-cdmi-mediatypes-04
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 17 Dec 2010 15:54:54 -0000
I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team) Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Summary: The draft is pretty much ready to go, but there are quite a few minor items that really should be fixed. There's a pervasive number-agreement problem. Remember that "a set of X" is *singular*, even if there are many X, because the subject is "a set", not "50 X". If that's not what you want, you need to re-word. No major issues. Minor issues: 3.1, number agreement error OLD A CDMI object is the basic storage element in a CDMI system and are analogous to files within a filesystem. NEW A CDMI object is the basic storage element in a CDMI system and is analogous to a file within a filesystem. 3.1, JSON reference It seems odd to me to have a general reference to the JSON web site, followed immediately by a proper reference to the RFC that defines the format. I see no reason for the reference to the web site. Alternatively, if you want to cite the web site, maybe putting it inline would be better, like this: The object is represented in the CDMI interface in JSON format [RFC4627] (see the JSON web site at http://www.json.org/ for general information about JSON). 3.1, number agreement error OLD defines the JSON format. Each data object has a set of well-defined fields that include a single value and optional metadata. NEW, if the subject is "set" defines the JSON format. Each data object has a set of well-defined fields that includes a single value and optional metadata. NEW, if the subject is "a field" defines the JSON format. Each data object has a set of well-defined fields; each field includes a single value and optional metadata. 3.1, normative language ? OLD but the application/cdmi-object should be represented in the CDMI interface as defined in section 8 of the CDMI specification. NEW but the application/cdmi-object SHOULD be represented in the CDMI interface as defined in section 8 of the CDMI specification. 3.2, number agreement error OLD Container objects are the fundamental grouping of stored data within CDMI and is analogous to directories within a filesystem. NEW A container object is the fundamental grouping of stored data within CDMI and is analogous to a directory within a filesystem. 3.2, number agreement error OLD Each container has zero or more child objects and a set of well-defined fields that include standardized and optional metadata. NEW Each container has zero or more child objects and a set of well-defined fields that includes standardized and optional metadata. (Consider whether "includes" should be "represents".) 3.2, normative language ? OLD implementations are free to represent the container in amy form they choose, but the application/cdmi-container should be represented in the CDMI interface as defined in section 9 of the CDMI specification. NEW implementations are free to represent the container in amy form they choose, but the application/cdmi-container SHOULD be represented in the CDMI interface as defined in section 9 of the CDMI specification. 3.4, number agreement error OLD Capability objects are a special class of container object that allow a CDMI client to discover what subset of the CDMI standard is implemented by a CDMI provider. NEW Capability objects form a special class of container object that allows a CDMI client to discover what subset of the CDMI standard is implemented by a CDMI provider. 3.4, number agreement error OLD For each URI in a CDMI system, the set of interactions that the system is capable of performing against that URI are described by the presence of named "capabilities". NEW For each URI in a CDMI system, the set of interactions that the system is capable of performing against that URI is described by the presence of named "capabilities". 3.5, dangling subject error OLD If supported by the cloud storage system, cloud clients create the queue objects by using the same mechanism used to create data objects. NEW If queues are supported by the cloud storage system, cloud clients create the queue objects by using the same mechanism used to create data objects. 4, definition of "transport protocols" I have a bit of a problem, in general, with referring to HTTP and SMTP as "transports"; they are application protocols that sit above the transport layer, and they, themselves, use transport protocols such as TCP (and there's an experiment doing HTTP over SCTP). Maybe I'm alone in this concern, but I'd rather avoid that terminology. I also don't really see a need to mention SMTP (and not, say, BEEP or whatever). Why not this?: OLD The CDMI uses HTTP (RFC 2616) transport and does not make sense outside the HTTP realm. We do not expect the CDMI to use other transports like SMTP (RFC2821) or raw TCP (RFC 793) protocols. NEW The CDMI operates over HTTP (RFC 2616) and does not make sense outside the HTTP realm. We do not expect the CDMI to operate over other protocols, nor to use a transport protocol, such as TCP (RFC 793), directly. 6.1: You don't need to capitalize "confidentiality" in the first sentence. 6.1, I suggest this change: OLD CDMI does not contain any specific mechanisms and relies on transport mechanisms like https [RFC2818] for confidentiality and integrity of the messages across the network. NEW CDMI does not contain any specific mechanisms for this, and relies on mechanisms such as TLS (see https [RFC2818]) for confidentiality and integrity of the messages across the network. I'm also wondering whether 2818 should be a normative reference, rather than informative. I'm on the fence.... 6.2, missing comma; I had to read this three times to understand it. OLD If required applications should use appropriate URL authentication and authorization techniques. NEW If required, applications should use appropriate URL authentication and authorization techniques. (In the next sentence, "fine-grained" should be hyphenated.) 6.3; what does "to facilitate the access" mean? Please reword. 6.4; hyphen, commas, number agreement OLD JSON related security considerations described in RFC 4627 [RFC4627] applies. NEW JSON-related security considerations, described in RFC 4627 [RFC4627], apply. 7; a comma after "Faltstrom" would make this easier to understand. -- Barry Leiba