
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PsvNUh84g3+F5Xi6325wUeTdveFxF70Qs2M0FbUeDNH+S/Z8Uoh/6x5CkKUftE3jo4 qDhFE10VgrWdkKE3hQtPXdez/Lx2Nq5hLALN5oCWYwV6p78xzLgfpW1Lw4+ni78IaWAE a732YYtJr6pqXXIdjdfIq+T7Oa/49eguRiLYI=
MIME-Version: 1.0
In-Reply-To: <4A427DC5.3080306@dcrocker.net>
References: <4A427DC5.3080306@dcrocker.net>
Date: Thu, 25 Jun 2009 13:13:42 -0400
Message-ID: <e4b033900906251013k3ac59bcdo44ad4f50a74c2651@mail.gmail.com>
From: Munjo Yu <munjo.yu@gmail.com>
To: dcrocker@bbiw.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: jskim@vinegen.com, apps-review@ietf.org
Subject: Re: [APPS-REVIEW] Gen-ART review of draft-ietf-dkim-overview-11
Precedence: list

Thank you so much, Dave for your review.

Your comments are right to the point.
We'll come up with a revised draft based on your comments.

-Munjo Yu

On Wed, Jun 24, 2009 at 3:25 PM, Dave CROCKER<dhc2@dcrocker.net> wrote:
> I have been selected as the App Area Review Team reviewer for:
> =A0 <http://www.ietf.org/internet-drafts/draft-kim-abnf-codegen-00.txt>
>
> The Apps Area Review team reference is at:
> =A0 <http://www.standardstrack.com/ietf/apps-review/>
>
>
>
>
> Document: =A0 =A0 =A0An ABNF Extension for code generation
> I-D: =A0 =A0 =A0 =A0 =A0 draft-kim-abnf-codegen-00
> Reviewer: =A0 =A0 =A0Dave Crocker
> Review Date: =A0 2009-06-24
>
>
>
> Summary:
>
> =A0 =A0 This draft proposes two types of enhancements for ABNF: =A0an uno=
rdered
> set
> construct and a generation-time directives construct. =A0The draft provid=
es
> far
> too little explanation for its choices or specification of them. =A0Furth=
er it
> requires special-case handling of numerous existing ABNF constructs and i=
s
> likely to be confusing to use and complex to implement.
>
>
>
> Extended Comments:
>
> =A0 =A0 ABNF permits specifying formats of protocol data units and payloa=
d
> contents. It was first codified in RFC 733 and then RFC 822 and gained
> popularity from amongst a variety of efforts that tailored pure BNF
> notation. As
> part of the DRUMS effort to revise the primary email specifications, ABNF
> was
> split out as a stand-alone reference, in RFC 5234. =A0The DRUMS effort
> included
> extensive review of existing and proposed ABNF refinements. =A0The draft =
under
> review, "An ABNF Extension for code generation" proposes enhancements to
> ABNF.
> The stated purpose is to facilitate automated generate of software based =
on
> ABNF
> specification.
>
> =A0 =A0 ABNF permits specifying an ordered sequence with the "( )" constr=
uct.
> The
> current draft adds the construct of an unordered set noted with "{ }". Th=
e
> draft also defines a means of adding code-generation directions, with an
> enhanced commenting notation: =A0";-- ".
>
> =A0 =A0 Over the years, many proposals for enhancing ABNF have been made.=
 From
> this it has become clear that the single biggest requirement for ABNF
> enhancement is to develop a community demand for the change. =A0This revi=
ew
> notes
> that requirement but does not have the task of commenting on its presence=
 or
> absence for this particular proposal.
>
> =A0 =A0 In general, the draft text has clear and understandable text, wit=
h few
> typographical or language errors. =A0However it has virtually no explanat=
ion
> for
> the motivation behinds its particulars, or detailed explanation for how t=
he
> particulars work, including extended examples. =A0The draft needs a
> substantial
> amount of both.
>
> =A0 =A0 Structurally, the draft has Section 2 defining Non-Sequence Group=
 with
> restrictions imposed by it, and Sections 3 & 4 discussion the Extension r=
ule
> and
> restrictions imposed by it. =A0That is, the two discussions have differen=
t
> sub-structures and should be made to be comparable.
>
> =A0 =A0 The draft notes that an unordered set ("Non-sequence Group") cons=
truct
> was
> part of the DRUMS effort but was dropped due to ambiguity concerns. =A0Th=
e
> draft
> does not discuss how the current proposal satisfies those concerns.
>
> =A0 =A0 Within the context of Non-sequence Groups, the draft imposes spec=
ial
> interpretations of ABNF repetition, sequence, grouping and alternation.
> =A0This
> makes Non-sequence Groups essentially independent of existing ABNF. =A0Ha=
ving
> to
> make definition of existing constructs be context-dependent -- non-sequen=
ce
> group versus other uses -- is highly problematic. =A0It is certain to be
> confusing
> and to make the code for an ABNF parser notably more complex.
>
> =A0 =A0 There is a long history in having parsing languages support
> generation-time directives. =A0Hence, the basic idea in this part of the =
draft
> could be useful. =A0Unfortunately, this portion of the draft is insuffici=
ently
> specified.
>
> =A0 =A0 The draft proposes a meta-notation for ABNF comments, by having t=
he
> comment begin with two dashes. =A0Hence: =A0;-- . =A0This is specified as
> providing
> "data type" and "variable name". =A0However I was not able to see that th=
ese
> were
> provided in the particular Extension rules that were supplied.
>
> =A0 =A0 Mechanically, the draft needs to define a registry for directives=
.
>
> =A0 =A0 More basically, it needs to explain each provided directive in fa=
r more
> detail than is supplied in the current draft. =A0Frequently, I could not =
tell
> what
> a particular directive was meant to accomplish. =A0Other times I could no=
t
> tell
> how it as meant to accomplish it; that is, whether the supplied informati=
on
> was
> sufficient.
>
>
> d/
>
>
> --
>
> =A0Dave Crocker
> =A0Brandenburg InternetWorking
> =A0bbiw.net
>

Return-Path: <dhc2@dcrocker.net>
X-Original-To: apps-review@core3.amsl.com
Delivered-To: apps-review@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 417B73A6907 for <apps-review@core3.amsl.com>; Wed, 24 Jun 2009 12:25:53 -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 63mjA5PrL2oQ for <apps-review@core3.amsl.com>; Wed, 24 Jun 2009 12:25:51 -0700 (PDT)
Received: from sbh17.songbird.com (unknown [IPv6:2001:470:1:76:0:ffff:4834:7147]) by core3.amsl.com (Postfix) with ESMTP id 99CDE3A6FC4 for <apps-review@ietf.org>; Wed, 24 Jun 2009 12:25:50 -0700 (PDT)
Received: from [127.0.0.1] (ppp-67-124-89-55.dsl.pltn13.pacbell.net [67.124.89.55]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n5OJPv09028788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jun 2009 12:26:02 -0700
Message-ID: <4A427DC5.3080306@dcrocker.net>
Date: Wed, 24 Jun 2009 12:25:57 -0700
From: Dave CROCKER <dhc2@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: apps-review@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 24 Jun 2009 12:26:03 -0700 (PDT)
Cc: jskim@vinegen.com, Munjo Yu <munjo.yu@gmail.com>
Subject: [APPS-REVIEW] Gen-ART review of draft-ietf-dkim-overview-11
X-BeenThere: apps-review@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: Applications Review List <apps-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-review>, <mailto:apps-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-review>
List-Post: <mailto:apps-review@ietf.org>
List-Help: <mailto:apps-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-review>, <mailto:apps-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jun 2009 19:25:53 -0000

I have been selected as the App Area Review Team reviewer for:
    <http://www.ietf.org/internet-drafts/draft-kim-abnf-codegen-00.txt>

The Apps Area Review team reference is at:
    <http://www.standardstrack.com/ietf/apps-review/>


Document:      An ABNF Extension for code generation
I-D:           draft-kim-abnf-codegen-00
Reviewer:      Dave Crocker
Review Date:   2009-06-24


Summary:

      This draft proposes two types of enhancements for ABNF:  an unordered set
construct and a generation-time directives construct.  The draft provides far
too little explanation for its choices or specification of them.  Further it
requires special-case handling of numerous existing ABNF constructs and is
likely to be confusing to use and complex to implement.


Extended Comments:

      ABNF permits specifying formats of protocol data units and payload
contents. It was first codified in RFC 733 and then RFC 822 and gained
popularity from amongst a variety of efforts that tailored pure BNF notation. As
part of the DRUMS effort to revise the primary email specifications, ABNF was
split out as a stand-alone reference, in RFC 5234.  The DRUMS effort included
extensive review of existing and proposed ABNF refinements.  The draft under
review, "An ABNF Extension for code generation" proposes enhancements to ABNF.
The stated purpose is to facilitate automated generate of software based on ABNF
specification.

      ABNF permits specifying an ordered sequence with the "( )" construct. The
current draft adds the construct of an unordered set noted with "{ }". The
draft also defines a means of adding code-generation directions, with an
enhanced commenting notation:  ";-- ".

      Over the years, many proposals for enhancing ABNF have been made. From
this it has become clear that the single biggest requirement for ABNF
enhancement is to develop a community demand for the change.  This review notes
that requirement but does not have the task of commenting on its presence or
absence for this particular proposal.

      In general, the draft text has clear and understandable text, with few
typographical or language errors.  However it has virtually no explanation for
the motivation behinds its particulars, or detailed explanation for how the
particulars work, including extended examples.  The draft needs a substantial
amount of both.

      Structurally, the draft has Section 2 defining Non-Sequence Group with
restrictions imposed by it, and Sections 3 & 4 discussion the Extension rule and
restrictions imposed by it.  That is, the two discussions have different
sub-structures and should be made to be comparable.

      The draft notes that an unordered set ("Non-sequence Group") construct was
part of the DRUMS effort but was dropped due to ambiguity concerns.  The draft
does not discuss how the current proposal satisfies those concerns.

      Within the context of Non-sequence Groups, the draft imposes special
interpretations of ABNF repetition, sequence, grouping and alternation.  This
makes Non-sequence Groups essentially independent of existing ABNF.  Having to
make definition of existing constructs be context-dependent -- non-sequence
group versus other uses -- is highly problematic.  It is certain to be confusing
and to make the code for an ABNF parser notably more complex.

      There is a long history in having parsing languages support
generation-time directives.  Hence, the basic idea in this part of the draft
could be useful.  Unfortunately, this portion of the draft is insufficiently
specified.

      The draft proposes a meta-notation for ABNF comments, by having the
comment begin with two dashes.  Hence:  ;-- .  This is specified as providing
"data type" and "variable name".  However I was not able to see that these were
provided in the particular Extension rules that were supplied.

      Mechanically, the draft needs to define a registry for directives.

      More basically, it needs to explain each provided directive in far more
detail than is supplied in the current draft.  Frequently, I could not tell what
a particular directive was meant to accomplish.  Other times I could not tell
how it as meant to accomplish it; that is, whether the supplied information was
sufficient.


d/


-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net