Re: [Unbearable] Ben Campbell's Discuss on draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT)

Thanks Ben.

EKR once this Discuss is cleared are we good to move on to the final
embrace of the RFC editor?

Regards
John B.

On Tue, Jun 26, 2018, 2:58 PM Ben Campbell <ben@nostrum.com> wrote:

>
>
> > On Jun 26, 2018, at 1:54 PM, Andrei Popov <Andrei.Popov@microsoft.com>
> wrote:
> >
> > Hi Ben,
> >
> > Thanks for the review.
> >
> >> Are the “applications” from paragraph 3 the same as those from
> paragraph 2?
> >
> > Yes, the same throughout paragraphs 1, 2 and 3.
> >
> >> It seems like paragraph 2 is talking more about local APIs (at least, I
> see that was mentioned in the text in version 17 but not in 18), but
> paragraph 3 uses an example of a signal from a server. (I can accept that
> the difference in control may be weak enough for web applications that the
> distinction does not matter.)
> >
> > The APIs provided by the TB implementation and called by the application
> are local APIs.
> > The application needs to make a decision whether to request that the TB
> implementation include a Referred binding in the TB message or not.
> > In the example, the server provides a signal to the application using
> the Include-Referred-Token-Binding-ID HTTP response header.
> > The signal could be different, or an application may have out-of-band
> ways to determine this (e.g. a local database of RP->IDP associations).
>
> I just re-read the 3rd paragraph, and I think I missed the “then” in
> “which then signals” on the first reading. It’s fine as is.
>
> Thanks!
>
> Ben.
>
> >
> > Cheers,
> >
> > Andrei
> >
> > -----Original Message-----
> > From: Ben Campbell <ben@nostrum.com>
> > Sent: Tuesday, June 26, 2018 11:41 AM
> > To: Eric Rescorla <ekr@rtfm.com>
> > Cc: Dirk Balfanz <balfanz=40google.com@dmarc.ietf.org>;
> draft-ietf-tokbind-https@ietf.org; Tokbind WG <unbearable@ietf.org>; The
> IESG <iesg@ietf.org>; John Bradley <ve7jtb@ve7jtb.com>;
> tokbind-chairs@ietf.org
> > Subject: Re: [Unbearable] Ben Campbell's Discuss on
> draft-ietf-tokbind-https-14: (with DISCUSS and COMMENT)
> >
> > Hi, thanks for the pointer.
> >
> > The text in version 18 is sufficient to clear my discuss. I have one
> remaining (or maybe new) non-blocking question for section 6:
> >
> > Are the “applications” from paragraph 3 the same as those from paragraph
> 2? It seems like paragraph 2 is talking more about local APIs (at least, I
> see that was mentioned in the text in version 17 but not in 18), but
> paragraph 3 uses an example of a signal from a server. (I can accept that
> the difference in control may be weak enough for web applications that the
> distinction does not matter.)
> >
> > I did not check my editorial comments.
> >
> > Thanks!
> >
> > Ben.
> >
> >> On Jun 25, 2018, at 6:30 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> >>
> >> Ben,
> >>
> >> Does the following new text address your concern:
> >> https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?modeAsFormat=html/a
> >> scii&url=https://raw.githubusercontent.com/TokenBinding/Internet-Draft
> >> s/master/draft-ietf-tokbind-https-18.xml
> >>
> >>
> >> On Mon, Jun 4, 2018 at 1:26 PM, Dirk Balfanz <balfanz=
> 40google..com@dmarc.ietf.org> wrote:
> >> Hi Ben,
> >>
> >> thanks for the feedback. Most of it is addressed in the new draft (
> https://tools.ietf.org/html/draft-ietf-tokbind-https-16). See below
> (inline) for details.
> >>
> >> On Wed, May 9, 2018 at 1:38 PM Ben Campbell <ben@nostrum.com> wrote:
> >> Ben Campbell has entered the following ballot position for
> >> draft-ietf-tokbind-https-14: Discuss
> >>
> >> 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-tokbind-https/
> >>
> >>
> >>
> >> ----------------------------------------------------------------------
> >> DISCUSS:
> >> ----------------------------------------------------------------------
> >>
> >> I plan to ballot "YES", but I want to clear up once concern first:
> >>
> >> After reading section 6 several times, I don't know what it means. I
> >> think it's [...]
> >>
> >> Addressed in new draft.
> >>
> >>
> >> ----------------------------------------------------------------------
> >> COMMENT:
> >> ----------------------------------------------------------------------
> >>
> >> Substantive Comments:
> >>
> >> §1.1: Please consider using the boilerplate from 8174 across the
> >> cluster. Both this and the protocol draft have lower case keyword
> instances.
> >>
> >> Addressed in new draft.
> >>
> >>
> >> §8.2:
> >> - Does it really make sense to wait for a user to request the keys be
> expired?
> >> I suspect the average user does this about never. Did the working
> >> group discuss possibly making the keys default to expiring after some
> period of time?
> >>
> >> Yes, we did discuss it. This was chosen consciously to be in sync with
> cookies and their expirations / manual user-initiated purges.
> >>
> >> - Why
> >> is the SHOULD in paragraph 2 not a MUST?
> >>
> >> Addressed in new draft.
> >>
> >>
> >> Editorial Comments:
> >>
> >> §2:
> >> - Paragraph 1: "The ABNF of the Sec-Token-Binding header field is (in
> >> [RFC7230] style, see also Section 8.3 of [RFC7231]):" The open
> parenthesis before "in"
> >> seems misplaced. Also, as written the comma after "style" creates a
> >> comma splice. (Note that this pattern occurs elsewhere in the
> >> document.)
> >>
> >> - Paragraph 3: The paragraph is a single hard-to-parse sentence.
> >> Please consider breaking into simpler sentences.
> >>
> >> Addressed in new draft.
> >>
> >>
> >> - example: Am I correct to assume the backslashes are just for print
> >> purposes and are not in the actual message? If so, please mention that.
> >>
> >> Addressed in new draft.
> >>
> >>
> >> § 2.1:
> >> - first paragraph, "Within the latter context...": There was no former
> context.
> >> I suggest "Within that context..."
> >>
> >> Addressed in new draft.
> >>
> >> - 2nd paragraph: The first sentence is hard to parse. I suggest
> >> breaking it into separate paragraphs, or restructure without the
> >> center-imbedding.
> >>
> >> Addressed in new draft.
> >>
> >> - 2nd to last paragraph: Does "SHOULD generally"
> >> mean the same as just "SHOULD"?
> >>
> >> Addressed in new draft.
> >>
> >>
> >> §5.1: 2nd paragraph: Unneeded comma in "... itself, to another
> server..."
> >>
> >> Addressed in new draft.
> >>
> >>
> >> §5.2,
> >> - last bullet: " (between client and Token Consumer)" seems more than
> >> parenthetical. Please consider removing the parentheses.
> >>
> >> Addressed in new draft.
> >>
> >> - paragraph after last
> >> bullet: The parenthetical phrase starting with "(proving
> >> possession...) is quite long and makes the sentence hard to parse.
> >> Given that the concept is covered in the immediately preceding
> paragraph, can it be removed?
> >>
> >> Addressed in new draft.
> >>
> >>
> >> §7.1 and §7.2: These sections seem to be copied from (or restate
> >> requirements
> >> in) the protocol and negotiation drafts. Can they be included by
> >> reference instead, or at least attributed?
> >>
> >> Addressed in new draft.
> >>
> >>
> >> §7.2, 2nd paragraph: This seams like a restatement of §7.1.
> >>
> >> Addressed in new draft.
> >>
> >>
> >> §8.3: Unneeded comma in first sentence.
> >>
> >> Addressed in new draft.
> >>
> >> Thanks again for the thoughtful comments!
> >>
> >> Dirk.
> >>
> >> _______________________________________________
> >> Unbearable mailing list
> >> Unbearable@ietf.org
> >> https://www.ietf.org/mailman/listinfo/unbearable
> >>
> >>
> >
>
>