Re: [Gen-art] [marf] Gen-ART review: draft-ietf-marf-as-13

Barry Leiba <> Fri, 13 April 2012 21:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1BA0011E80FD; Fri, 13 Apr 2012 14:06:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.808
X-Spam-Status: No, score=-102.808 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1262gd1AHtzB; Fri, 13 Apr 2012 14:06:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3B8BB11E80E4; Fri, 13 Apr 2012 14:05:46 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so2131211ghb.31 for <multiple recipients>; Fri, 13 Apr 2012 14:05:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ErQ/XrLI8AYnbwhhVW3jgJj5TMHmvNTbaAiqxrK6xU4=; b=gF7KnSNAsytTuTkpgQ2PXhZaT7GR3RLxMd7UkIF4a3FcKqFJBMGSFuY76TevGJ+Ifl BF7DFkUCZ3DiIKQS9YoMNN4ciz3vbUjgjZmyISxw4TvswYR5I/VTrW/g3yUfL36r4EQO ues9c5U9giC5QIGnrn/yJZeh0FoR/uotQ0IE9cn4P0Xwwv9tM83ciuGNac5SDl2I9QpF Abm1PzomdURyqA9WGAweB7C9oYjT11WKWzGuhnIP1HJMXDQSOIg8s/l4VVOb+NJnu6N+ H0+72pujmUgk/8/JR9ZxS6l2jpzCD3yfpf+e/XHhyf/cixHkrJ9OlziYxUJd4sGvhNiu C49w==
MIME-Version: 1.0
Received: by with SMTP id f35mr169267anh.37.1334351145863; Fri, 13 Apr 2012 14:05:45 -0700 (PDT)
Received: by with HTTP; Fri, 13 Apr 2012 14:05:45 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Fri, 13 Apr 2012 17:05:45 -0400
X-Google-Sender-Auth: 7lyvmUc_jB9HRkd26nAQuk8EMO0
Message-ID: <>
From: Barry Leiba <>
To: "Murray S. Kucherawy" <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "" <>, "" <>, "" <>
Subject: Re: [Gen-art] [marf] Gen-ART review: draft-ietf-marf-as-13
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Apr 2012 21:06:46 -0000

Just one comment here; leaving the rest for Murray:

>> Reading through, this doesn't smell very much like an applicability
>> statement at all.  It has the distinct odor of a profile, or a set of
>> implementation/deployment/operational guidelines.  That might just be
>> me.

> It is an Applicability Statement in the sense of Section 3.2 of RFC 2026.

Indeed, and the problem is that we've used stand-along Applicability
Statements so infrequently in recent years that we don't seem to know
what they are any more.  Worse, we've often started to call them

I think an Applicability Statement is a normative document that does
not in itself define a protocol, but specifies how to *apply* one or
more profiles to solve a particular (set of) problem(s) or to perform
a particular (set of) function(s).  It might well be that we should
start calling many of the "profiles" that we do "Applicability
Statements" instead.

The advantage here is that the AS is a standards-track document, and
will progress along the standards track just as a Technical
Specification would.  Making it Information loses that aspect.

Barry, document shepherd