Subject: [kitten] sasl-saml-ec-18: bookkeeping changes requested

From: Robbie Harwood <[email-masked]>
Date: Thu, 22 Aug 2019 17:14:41 -0400

Hello Scott and Simon,

There are a number of issues flagged by idnits [1][2] that I believe
need to be addressed:

- rfc4402 is obsoleted by rfc7802.

- rfc2617 is obsoleted by several things; I think here we're probably
  looking for rfc7617.

- rfc5246 is obsoleted by rfc8446.

- rfc2616 is obsoleted by several things; I think here we're probably
  looking for rfc7230.  I could see an argument for using the
  obsolete one if it's more correct, but...

- rfc3920 is obsoleted by rfc6120.

Additionally, it doesn't like having a separate "Normative References"
and "Normative References for GSS-API Implementers" section.  While I
don't know that it's technically required to name the sections a certain
way, I think it would be easiest to make a single "Normative References"
section.

Could you please address these and resubmit?

Thanks,
--Robbie

1: https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-kitten-sasl-saml-ec-18.txt
2: https://www6.ietf.org/tools/idnits/

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 23 Aug 2019 14:09:11 +0000

> way, I think it would be easiest to make a single "Normative References"

That was taken verbatim from the earlier GS2 mechanims, I believe, but it doesn't matter to me.

> Could you please address these and resubmit?

Won't be until next week probably.

-- Scott

---

From: Robbie Harwood <[email-masked]>
Date: Fri, 23 Aug 2019 11:13:59 -0400

"Cantor, Scott" <[email-masked]> writes:

>> Additionally, it doesn't like having a separate "Normative
>> References" and "Normative References for GSS-API Implementers"
>> section.  While I don't know that it's technically required to name
>> the sections a certain way, I think it would be easiest to make a
>> single "Normative References" section.
>

Ah, okay.  Either way should be fine then; I'll just note it in the
review.

Thanks,
--Robbie

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 26 Aug 2019 17:20:12 -0500

> Ah, okay.  Either way should be fine then; I'll just note it in the

My recollection is that the references have to be divided into normative
vs. informative, but that further subdivision is not precluded.  So,
sticking to tradition is probably okay (but we may get further comments
about it from directorate and/or IESG reviews).

-Ben

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 28 Aug 2019 15:36:54 +0000

> Could you please address these and resubmit?

This is done. I decided to go ahead and merge the reference sections, I don't think maintaining the split adds enough value to be arguing with anybody over it.

All of the RFC updates were obvious, save for one. I did move the TLS 1.2 client authn reference to TLS 1.3, but I hesitated because that's really a conformance/interop sort of consideration, and TLS 1.2 client authn is not the same as 1.3 and is definitely not the same from a ubiquity / interop point of view. But given that the number of implementations of this is and will always be very small, I decided to be forward looking and just rev it.

-- Scott

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 31 Aug 2019 15:20:30 -0500

> All of the RFC updates were obvious, save for one. I did move the TLS 1.2 client authn reference to TLS 1.3, but I hesitated because that's really a conformance/interop sort of consideration, and T…

That's a fair decision to make; I'll just note for future reference that we
do have a fair number of documents getting published that reference both
5246 and 8446 by virtue of needing to interact with the bits that have
different semantics between TLS versions.

-Ben