Re: [jose] Barry Leiba's No Objection on draft-ietf-jose-json-web-algorithms-32: (with COMMENT)

Barry Leiba <> Tue, 30 September 2014 16:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BB74F1A1AF4; Tue, 30 Sep 2014 09:39:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CFI_zMtXmD2D; Tue, 30 Sep 2014 09:39:33 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 46F271A1AFD; Tue, 30 Sep 2014 09:39:33 -0700 (PDT)
Received: by with SMTP id p9so1856114lbv.5 for <multiple recipients>; Tue, 30 Sep 2014 09:39:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=DrfMxfdOh9KSHyMThSCpjFrqsN6ymmLEksdmi/Y8Yug=; b=OqB6Seg70AVxm32F7rm/LrR+N8QzH/9AcXdoG9QWPg+iVUemWZ3YiD9GJOtJureP9+ lfFLCkwBVgIN1WUdBxf3fJkAra9oaDQCWED5n4OE8t30hA99aiZ/CyCukMCXESWglnqY TrwpHapxl/IDQ4/QvdDeqxioP5GKpdH4ApT7wriOlcmMZQYFCggi7EcQAJRdGRh5L25R 77nkd0bEcih+LtYQFywHRIG/6o5EarrDJ9qMAQ3URvGkcPEmOJ2fD/ocS4UczTkm7hL1 g+6GAVbt3Ke18RY1gM/o7dPBXLA+T+UzWh8sHKY/Z/QjSJ/WJKDAvkL9TYG7EhFuHK6T ZHAA==
MIME-Version: 1.0
X-Received: by with SMTP id ir3mr19232638lac.82.1412095171253; Tue, 30 Sep 2014 09:39:31 -0700 (PDT)
Received: by with HTTP; Tue, 30 Sep 2014 09:39:31 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Tue, 30 Sep 2014 17:39:31 +0100
X-Google-Sender-Auth: hIi4j33d9MTkLYGGscusa7_p09o
Message-ID: <>
From: Barry Leiba <>
To: Mike Jones <>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "" <>, "" <>, The IESG <>, "" <>
Subject: Re: [jose] Barry Leiba's No Objection on draft-ietf-jose-json-web-algorithms-32: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Sep 2014 16:39:34 -0000

>> 2 (the real point). I don't understand how the two sentences relate to each
>> other.  The first sentence seems to say that the DE(s) can change
>> implementation requirements on their own.  The second says it has to be done
>> using Specification Required (which doesn't really need to be said, as
>> that's the policy for the registry anyway).
>> Which is it?  If it's Specification Required, then anyone can propose a
>> change, using a specification, and the DE(s) will review that as they do any
>> other registration request.
> The intent is for both to be required - that a specification be written
> proposing the change and the designated experts approve the change.  I can
> look into a wording change to make this clearer when the document is next
> revised.

OK, but that's just normal Specification Required.  It's fine if you
want to point out that updates can also be made using the
Specification Required policy... but please avoid making it look like
you're setting up something special, as that might wind up being