Re: [abfab] Barry Leiba's No Objection on draft-ietf-abfab-aaa-saml-13: (with COMMENT)

Barry Leiba <> Mon, 11 January 2016 14:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5B15E1A01A5; Mon, 11 Jan 2016 06:55:45 -0800 (PST)
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 6SlzV4-c_mTe; Mon, 11 Jan 2016 06:55:44 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 37FFB1A0151; Mon, 11 Jan 2016 06:55:44 -0800 (PST)
Received: by with SMTP id z14so120335853igp.0; Mon, 11 Jan 2016 06:55:44 -0800 (PST)
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=eXu7NKUJRli6SkLFDPqSDOT93xUaWqNbf+McDN6434Q=; b=mKNNbJBhJjrlv8AfOQlkDR2pqxgv3D4QdhCHWMkrve9Kat1HxoiQypwecgy4XWW62l b130H6YKWyk0giMnpbWLZKb6hK87qRsHLBy3YKdpFhH6qr3hReFR7iZ98R7B/auqvI17 Anf16os8Cq6XKThANGNNervrWDKObeg6Zt41/Vh7RwngRgHpHT1bt7bni2pGCOVQ3l6O tLhE1OkQuubygyIJ5pRs5gj9XTxLnRBEkN7BM6AwD6j/hHrJJxyYOPkDxbGoi8vSV5zc Jm89FmpuuilqZzfjo4E9xe9Rzg7rDFFlkjf8G5iKT5eaYwLGlR05Lwd+xlSXu/Zp9m3T SOpA==
MIME-Version: 1.0
X-Received: by with SMTP id ei11mr12117481igc.81.1452524143660; Mon, 11 Jan 2016 06:55:43 -0800 (PST)
Received: by with HTTP; Mon, 11 Jan 2016 06:55:43 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Mon, 11 Jan 2016 09:55:43 -0500
X-Google-Sender-Auth: kRkhbIzz3hTVORvXFj7iG99K4fs
Message-ID: <>
From: Barry Leiba <>
To: Sam Hartman <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc:,, The IESG <>,
Subject: Re: [abfab] Barry Leiba's No Objection on draft-ietf-abfab-aaa-saml-13: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Jan 2016 14:55:45 -0000

Hi, Sam -- thanks for the follow-up.  No worries: with your comments
and Alejandro's, I'm fine with leaving it as it is, so let's just
carry on.

And for what it's worth, I think we have ample evidence that repeating
last calls for this sort of thing *never* adds any value, and I'm
working on getting some folks to write an update to 3967 that changes
that (giving discretion to the IESG on the matter, rather than
*requiring* that it always be called out in the last call notice).
But that hasn't gotten off the ground yet; I'll have to poke people
and see if we can get it moving.


On Mon, Jan 11, 2016 at 9:23 AM, Sam Hartman
<> wrote:
> First, I care far more about publishing this document than I do about
> resolving the reference type of abfab-arch.
> I don't believe that you need to understand the term relying party, or
> the other role terms in order to implement this spec.
> I believe 7055, this spec and SAML define enough terminology that while
> you might not understand the overall system and how it fits together,
> you can implement this part without reading arch.
> I fully agree that we could do another last call and do a RFC 3967
> down-ref to arch.
> I don't think it's the right thing to do even  if we can find a way to
> do it without an additional last call; I think you and I probably have a
> different opinion about the boundary between normative and informative
> references.
> I don't think a third last call would be helpful for this document.
> However, so long as my input is considered, I would not try to block on
> this issue; any resolution is fine with me.
> --Sam