[Gen-art] genART review of draft-ietf-cdni-logging-15

Martin Thomson <martin.thomson@gmail.com> Thu, 12 February 2015 01:02 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BB91A8880 for <gen-art@ietfa.amsl.com>; Wed, 11 Feb 2015 17:02:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gazyfDkxz3mr for <gen-art@ietfa.amsl.com>; Wed, 11 Feb 2015 17:02:38 -0800 (PST)
Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F02501A00F0 for <gen-art@ietf.org>; Wed, 11 Feb 2015 17:02:36 -0800 (PST)
Received: by mail-ob0-f169.google.com with SMTP id wp4so7070267obc.0 for <gen-art@ietf.org>; Wed, 11 Feb 2015 17:02:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=RplYQS+e5usrOi8jxt5p4z7YNUw7qLYygVBs7J0SulY=; b=v2ApZJ4x/5ciq8bLTOIpR3bBxaM3uiD4DYw+emkRZaBY6PDfzwwbIMSy4FMZ4DEVd+ qSMqqurvk+qEQ26niPyCgNEBJiV32ZYVXW8UjwVXdYD+NJ2LXI1lvqxE6DfmIqKe/PF4 CbBYuoQ1+ronOPP/9GXDQdCecgHp5Lpaav2cRrxQ0XDRwa4dIpFwBsxUA2yF0BbYn5Qn HCd0fDtFW6BDcXLoAXDrvxurMAIxA9kuE3A0PguKRvzmVeMWTqI5Jsk8uAHA5hjo1eGM JGYf9NunUZpzMCQxeIOnG9D9bLHb0PzcGFSlzi4n3oOTp+DD+uI+phwdX04iVHuyRaWe OJ7g==
MIME-Version: 1.0
X-Received: by 10.182.68.12 with SMTP id r12mr967092obt.84.1423702938965; Wed, 11 Feb 2015 17:02:18 -0800 (PST)
Received: by 10.202.225.135 with HTTP; Wed, 11 Feb 2015 17:02:12 -0800 (PST)
Date: Thu, 12 Feb 2015 12:02:12 +1100
Message-ID: <CABkgnnU95w0SzS+PVZL0Lh0bCjfKr7DwYp0xajJ8-WBKnmao6w@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "gen-art@ietf.org" <gen-art@ietf.org>, draft-ietf-cdni-logging.all@tools.ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/O2x1hf9ey7_WGrT6PT-f3D_EMKI>
Subject: [Gen-art] genART review of draft-ietf-cdni-logging-15
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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>
X-List-Received-Date: Thu, 12 Feb 2015 01:02:43 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-cdni-logging-15
Reviewer: Martin Thomson
Review Date: 2015-02-12
IETF LC End Date: 2015-02-18
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

S3.1 needs to define the basic atom that is used for the logging file.
It appears as though the atom is an octet.

S3.2 uses the wildcard ABNF rule (i.e., <text....>) too aggressively.
RECLINE (a potentially confusing name) could be more strictly defined.

    <CDNI Logging File> = 1*<DIRGROUP RECGROUP>

... is not valid and could be:

    CDNI-LOG-FILE = 1*(DIRGROUP / RECGROUP)

That implies that an empty file is not valid.  I'd have thought that *
rather than 1* would be better.

S3.3 again uses wildcard rules too aggressively.  DIRNAME (not the
unix command) should be defined more explicitly, even if it is just to
specify what characters are allowed.  Use text to further constrain
it.  As it stands, a generic processor cannot know that the name
doesn't permit the inclusion of (for instance) ":" or CRLF.  A common
method is to define something like this as:

    DIRNAME = Version-directive / UUID-directive / ... / extension-directive

More commonly, go up a level and define directive using the choice.
That way, each directive can define a name and value together using
ABNF.  e.g.

    Version-directive = "Version" ":" HTAB "CDNI" "/" 1*DIGIT "." 1*DIGIT

I wouldn't be so prescriptive about the version format.  Unless there
are specific semantics you want to extract from each digit.

What is a receiver expected to do if the version *isn't* CDNI/1.0 ?
Discard the entire file?  That doesn't seem like a good way to ensure
forward compatibility.

UUID: this a Universally Unique IDentifier (UUID)
         from the UUID Uniform Resource Name (URN) namespace specified
         in [RFC4122]) for the CDNI Logging File.

I don't know how to apply this.  Is it the UUID portion of the URN or a URN?

Please don't use MUST here: If the
         two values are equal, then the received CDNI Logging File MUST
         be considered non-corrupted.

MD5 collisions are easy to manufacture.  I'd also drop the MUST from
the following sentence.

S3.4: more wildcards

S3.4.1: I wouldn't worry about HTTP/2 being special here.  All that
speculation is painful, especially since HTTP/2 will likely be
published before this document.  Better to just cite it and avoid
getting caught up in the details.




Nits/editorial comments:

There are lots of uses of lowercase "may".

Page 6 has a few instances of missing hyphens in dCDN3/dCDN2 etc...
S6.2.1: chunck

S3.1 the DATE/TIME rules can/should reference RFC 3339

S3.3 using ":" HTAB as a separator makes it hard to construct these
files manually.

S3.4 use of "c:" in combination with the unordered list is confusing
when the prefix is actually "c-".  Maybe use the string "c-" quotes
and all to denote the prefix.

S3.4.1 citing RFC 7230 is sufficient for HTTP/1.1; and probably for
HTTP in general at this moment.