Re: [Privacy-pass] Robert Wilton's Discuss on draft-ietf-privacypass-auth-scheme-12: (with DISCUSS and COMMENT)

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Tommy,

Thanks.  I’ve cleared my discuss, so just Francesca’s discuss remains.

Regards,
Rob


From: Tommy Pauly <[e-mail]>
Sent: 12 September 2023 21:48
To: Tommy Pauly <tpauly=[e-mail]>
Cc: Rob Wilton (rwilton) <[e-mail]>; The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; Benjamin Schwartz <[e-mail]>
Subject: Re: [Privacy-pass] Robert Wilton's Discuss on draft-ietf-privacypass-auth-scheme-12: (with DISCUSS and COMMENT)

Hi Rob,

We’ve published a revision, which does add the normative reference to the architecture:

https://www.ietf.org/archive/id/draft-ietf-privacypass-auth-scheme-13.html

Thanks!
Tommy


On Sep 6, 2023, at 7:55 AM, Tommy Pauly <tpauly=[e-mail]<mailto:tpauly=[e-mail]>> wrote:

Hi Rob,

I do think that we would want the architecture to be published along with or before the auth-scheme doc — and ideally, the protocol document would go along with those. So, from that regard a normative reference isn’t an issue.

Let us know what the IESG thinks about a normative downref here after your discussion!

Best,
Tommy


On Sep 6, 2023, at 1:06 AM, Rob Wilton (rwilton) <rwilton=[e-mail]<mailto:rwilton=[e-mail]>> wrote:

Hi Tommy,

Top posting because of my “non-optimal” email client inline quoting behaviour …

For the first two issues, your resolution sounds fine.

For the last issue, we can discuss on Thursday.  Obviously, I cannot speak for the collective IESG, but a downref from a protocol or spec to an informational architecture document is quite common, and not normally an issue.  But please also be aware, if not already, that a normative reference would mean that the architecture document needs to be published as an RFC before, or the same time, as this document.

Regards,
Rob


From: iesg <[e-mail]<mailto:[e-mail]>> On Behalf Of Tommy Pauly
Sent: 05 September 2023 22:11
To: Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>; The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Benjamin Schwartz <[e-mail]<mailto:[e-mail]>>
Subject: Re: Robert Wilton's Discuss on draft-ietf-privacypass-auth-scheme-12: (with DISCUSS and COMMENT)

Hi Rob,

Thanks for the review! Responses inline.



On Sep 4, 2023, at 8:36 AM, Robert Wilton via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:

Robert Wilton has entered the following ballot position for
draft-ietf-privacypass-auth-scheme-12: 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/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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi,

Thanks for this document.  I found the document to be well written and
reasonable clear, and I think that this is useful technology (but worry about
the centralization aspects that the protocol is likely the encourage). However,
I feel that this document is somewhat hard to fully understand without reading
the architecture document first (which is only an informative rather than
normative reference).  Hence, I have a flagged a few issues which I think rise
to the category of discuss but hopefully should not be hard to resolve.

(1) p 15, sec 5.2.  Token Type Registry

  *  Private Metadata: A Y/N value indicating if the output tokens can
     contain private metadata.

This is the first time that some of these fields (e.g., Publicly Verifiable,
Public/Private Metadata) have been introduced.  Does the document need any
additional prose to describe what they and how they are used?  The current text
feels somewhat terse as a description in a standard track document.

(2) p 17, sec 5.2.  Token Type Registry

  *  Nid: N/A

Shoudln't Nk and Nid default to 0 rather than 'N/A'?  This comment also applies
to the text above the greased values, or otherwise (at a stretch) it could
arguably be interpreted as putting is randomly sized Nk and Nid fields
containing random data.

I filed this issue to cover these: https://github.com/ietf-wg-privacypass/base-drafts/issues/472

We’ll add better explanation, much of which will likely refer back to the architecture draft.



(3) p 18, sec 6.2.  Informative References

  [ARCHITECTURE]
             Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy
             Pass Architecture", Work in Progress, Internet-Draft,
             draft-ietf-privacypass-architecture-13, 15 June 2023,
             <https://datatracker.ietf.org/doc/html/draft-ietf-
             privacypass-architecture-13<https://datatracker.ietf.org/doc/html/draft-ietf-%0b%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0%C2%A0privacypass-architecture-13>>.

It seems strange to me that the architecture reference isn't normative.  I.e.,
I would think that reading aspects of the architecture is a prerequisite to
fully understanding the protocol aspects defined here.

I filed this issue:

https://github.com/ietf-wg-privacypass/base-drafts/issues/473

Happy to make this change, but can we get confirmation first from the IESG that this normative downref to an informational document will be approved?

Thanks,
Tommy




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

Thanks to Yingzhen for the OPSDIR review.

Regards,
Rob




--
Privacy-pass mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/privacy-pass