Re: [Privacy-pass] Zaheduzzaman Sarker's No Objection on draft-ietf-privacypass-auth-scheme-12: (with COMMENT)

[Tommy Pauly <[e-mail]>]

Thanks, Zahed!

> On Sep 6, 2023, at 2:54 AM, Zaheduzzaman Sarker via Datatracker <[e-mail]> wrote:
> 
> Zaheduzzaman Sarker has entered the following ballot position for
> draft-ietf-privacypass-auth-scheme-12: 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/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-privacypass-auth-scheme/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for working on this specification.
> 
> This specification does not raise transport related issues, however, I kind of
> agree with Martin's concerns on assumptions and user interaction. On top of
> the, section 3 only describe when this is used in a website context. I didn't
> find what are the other context and how that would be different or what need to
> be done differently. I think I needs to be clarified as well. Hence, supporting
> Francesca's discuss.

I’ve opened this PR to work on this:
https://github.com/ietf-wg-privacypass/base-drafts/pull/474

This removes the website-specific text, and also describes the fact that there are different models where this protocol can be used (closed services where tokens may be required, and open services — which would include the web — where the tokens may or may not be supported by clients).

> 
> I also think the privacy pass architecture document and this specification
> should have been at least reviewed together or preferably architecture doc
> should have get to us first to review/approve. I don't expect lots will change
> in the architecture after IESG evaluation but still there are some
> possibilities. As this document relay's on the architecture terminologies it
> feels odd to review this when we haven't reviewed the terminologies defined in
> the architecture doc.

I certainly think that these documents should be published together, and we shouldn’t let this get published ahead of the architecture.

Thanks,
Tommy

> 
> 
>