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

From: "Barry Leiba" <[email-masked]>
Date: Wed, 06 Jan 2016 17:46:38 -0800

Barry Leiba has entered the following ballot position for
draft-ietf-abfab-aaa-saml-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-abfab-aaa-saml/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Because abfab-arch defines the terms "Client", "Relying Party", and 
"Identity Provider", I think abfab-arch should be a normative reference.

-- Section 3 --

   The RADIUS SAML binding defined in Section 4 of this document uses
   two attributes to convey SAML assertions and protocol messages
   respectively [OASIS.saml-core-2.0-os]

Nit: "respectively" is out of place here, and should be removed.  You 
would only use "respectively" if you named the two attributes ("...uses 
two attributes, SAML-Assertion and SAML-Protocol, to convey SAML 
assertions and protocol messages, respectively.").

-- Section 7.3.5 --

   If issued by the Identity Provider, the Relying Party MUST process
   the <samlp:Response> message and any enclosed assertion elements as
   described in [OASIS.saml-core-2.0-os]

"If issued" is dangling, and  makes it look like the Relying Party is 
issued by the Identity Provider.

NEW
   If a <samlp:Response> message is issued by the Identity Provider,
   the Relying Party MUST process that message and any enclosed
   assertion elements as described in [OASIS.saml-core-2.0-os]
END

-- Section 11.2 --
Thank you; this section is well done.

---

From: Alejandro Pérez Méndez <[email-masked]>
Date: Fri, 8 Jan 2016 10:50:48 +0100

Hi Barry, Alice,

thanks for the review. Should I generate a -14 version in order to 
address these comments or can this be done in an editing phase without a 
new version?

Regards,
Alejandro

El 07/01/16 a las 02:46, Barry Leiba escribió:
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 8 Jan 2016 13:33:40 +0000

Hiya,

> Hi Barry, Alice,

I'm not sure if Barry and Alissa are on this list but in any
case, the thing to do is to reply to their comments and then
if there are changes needed, yes please shoot out a -14 with
*only* those changes. At that point I can send the approved
message and the document will be sent to the RFC editor for
processing.

Cheers,
S.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 08 Jan 2016 16:08:13 -0500

>>>>> "Barry" == Barry Leiba <[email-masked]> writes:

    Barry> ----------------------------------------------------------------------
    Barry> COMMENT: ----------------------------------------------------------------------

    Barry> Because abfab-arch defines the terms "Client", "Relying
    Barry> Party", and "Identity Provider", I think abfab-arch should be
    Barry> a normative reference.

I don't think abfab-arch can be a normative reference because I think
 it's an informational document.

I note this is a comment not a discuss, but wanted to explain why we
won't be able to address it.

I think your other comments look good.

---

From: Barry Leiba <[email-masked]>
Date: Sat, 9 Jan 2016 06:35:21 +0800

Thanks for the response, Sam, but we've allowed normative references
to Informational documents for more than ten years, since RFC 3967,
and there are a great many examples where a normative reference to an
informational document is used when the latter is needed for
terminology definitions.

Yes, this isn't a DISCUSS, and I won't block publication on this
point.  But please consider whether it's really the right thing to
have necessary terminology definitions in an informative reference.
Can someone fully understand this document without having definitions
for "relying party" and "identity provider"?

(No need for further response, unless you want to discuss it.  I've
said all I need to, and, again, thanks for the reply.)

Barry

---

From: Alejandro Pérez Méndez <[email-masked]>
Date: Mon, 11 Jan 2016 09:45:05 +0100

Hi Barry,

thanks for your comments. See my responses inline, please.

> https://datatracker.ietf.org/doc/draft-ietf-abfab-aaa-saml/

As per the discussion you had with Sam, I see your point and I'm not 
against it.
On the other hand, I think that the terms "Client", "Relaying Party", 
and "Identity Provider" are common enough to don't require readers to go 
to the reference to understand them, specially when the document already 
contains a terminlogy table that matches these terms with their SAML and 
RADIUS correspondences.

> assertions and protocol messages, respectively.").

Right, thanks. Probably the result of an edit to remove the attribute 
names from that paragraph.

>     assertion elements as described in [OASIS.saml-core-2.0-os]

Thanks, the text you've provided sounds much more clear. I will include it.

Best regards,
Alejandro

---

From: Barry Leiba <[email-masked]>
Date: Mon, 11 Jan 2016 09:05:15 -0500

Thanks for the response, Alejandro, and for addressing my comments.

Barry

On Mon, Jan 11, 2016 at 3:45 AM, Alejandro Pérez Méndez <[email-masked]> wrote:
> As per the discussion you had with Sam, I see your point and I'm not against
> it.
> On the other hand, I think that the terms "Client", "Relaying Party", and
> "Identity Provider" are common enough to don't require readers to go to the
> reference to understand them, specially when the document already contains a
> terminlogy table that matches these terms with their SAML and RADIUS
> correspondences.
>
>>
>> -- Section 3 --
>>
> Right, thanks. Probably the result of an edit to remove the attribute names
> from that paragraph.
>
>>
>> -- Section 7.3.5 --
>>

---

From: Sam Hartman <[email-masked]>
Date: Mon, 11 Jan 2016 09:23:03 -0500

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

---

From: Barry Leiba <[email-masked]>
Date: Mon, 11 Jan 2016 09:55:43 -0500

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.

Barry