Re: [apps-discuss] Comments on draft-ietf-appsawg-received-state

Barry Leiba <barryleiba@computer.org> Thu, 07 June 2012 10:59 UTC

Return-Path: <barryleiba.mailing.lists@gmail.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 5EEDE21F87CD for <apps-discuss@ietfa.amsl.com>; Thu, 7 Jun 2012 03:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.962
X-Spam-Level:
X-Spam-Status: No, score=-102.962 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 TPNA9szSyywP for <apps-discuss@ietfa.amsl.com>; Thu, 7 Jun 2012 03:59:35 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7746D21F87C0 for <apps-discuss@ietf.org>; Thu, 7 Jun 2012 03:59:35 -0700 (PDT)
Received: by lbbgo11 with SMTP id go11so532287lbb.31 for <apps-discuss@ietf.org>; Thu, 07 Jun 2012 03:59:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2XeLj6dYK0oWK6ExVl/zusGLsJfrbavnN6PgAZDO6MI=; b=NJK4VUrNdJp/Gyzdvh6UUELvMegblmjd/JiHemqzyBijHxWudEmneLURhsKgiZBY8f cJKdQzpXyRXIfO0vDSeM4U2upSKiQIHl4genIvjPgrEA0zhubeQVMege/+DkJjtmtqjT 3alwOaCo/ETl34G5ofXX0mq2fhHqVEBsR0yp5E/aKO7Yj7P3jbZsi/RRkWK2BYuoIkVF WC7FTbVq5qZYw5y+Dml6EAb+hjcodWjSbGwpuNbgzQJfS8z9yTNa0ulpg9hdRcpUv+/C cJCiqaoBb40u6qYOrl0mGVb0G/7JmdGgaU7wR0K7fVBR+ZePogDkHOA1NNmWDx6MAtAY F71g==
MIME-Version: 1.0
Received: by 10.152.103.11 with SMTP id fs11mr1981492lab.23.1339066774417; Thu, 07 Jun 2012 03:59:34 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.112.48.104 with HTTP; Thu, 7 Jun 2012 03:59:34 -0700 (PDT)
In-Reply-To: <CAL0qLwY1DCP9RY7cykwrPi48A_1h_FJUXo5eRWkn3Rw=rFXpBw@mail.gmail.com>
References: <CAL0qLwY1DCP9RY7cykwrPi48A_1h_FJUXo5eRWkn3Rw=rFXpBw@mail.gmail.com>
Date: Thu, 07 Jun 2012 06:59:34 -0400
X-Google-Sender-Auth: SPi2HzLCxjv08PI-pXyydLslWII
Message-ID: <CAC4RtVBuET9h-QHEtS=genmJnJ6bfKk=KD0bTJQvZJApAsY_ww@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Content-Type: multipart/alternative; boundary="f46d040715c56b701704c1dfc71b"
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-received-state
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: Thu, 07 Jun 2012 10:59:36 -0000

>
> 1) Change the IANA rules for registering new states to Expert Review.
> Specification Requires is overkill.  (Expert Review might be too, but I
> didn't feel totally comfortable busting it down that far.  What do others
> think?)
>

I think this is a good idea.  I think FCFS would also be adequate, and
encourage the WG to use that.  The reason is that it's far better to
encourage people to register status codes that they want to use, and not to
put barriers in the way.  The usual reluctance to use FCFS is concern that
people will register a bunch of garbage.  In fact, (1) this hasn't ever
happened and (2) IANA would ask the IESG to intervene if they got a
suspicious flood of registration requests.

In any case, you're going to need to change the template if you don't
require a specification.   I suggest this:

OLD
Specification: The specification document that defines the queue state
being registered.

NEW
Specification: A pointer to a specification document that defines the queue
state being registered, if one exists; else, a more detailed description of
the queue state, to aid in interoperable usage.

Barry