-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
protocol-determined vdaf representation #419
Conversation
31a7b3d
to
d06df76
Compare
|
98964bc
to
1ef84c1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It otherwise looks good, I like the representation_for_protocol
pattern.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple high level questions:
- This sets protocol = DAP-04 on existing paired aggregators, which makes sense. Do we require that all further aggregators someone pairs have to include their supported protocol in the capabilities API?
- Why store the protocol version in the tasks table? If each aggregator supports exactly one protocol version (which I think is the right thing to do), then a task's protocol version is implied by the protocol version of the aggregators it uses.
Yes. If they do not, they will be treated as DAP-04 for posterity. This is a mandatory field in the config api now. Edit: Wait, maybe I misunderstood. If they are in fact DAP-04, they don't need to advertise a protocol and it will work fine. There's a serde(default) on Protocol and the default is Dap04.
I'm open to dropping it. I know aggregators cannot currently upgrade or support multiple DAP versions, but I was defensively programming against a future scenario in which it isn't always possible to determine from the aggregator pair. This is also why there's a variable named Edit: Removed the task protocol column |
e0628b2
to
fcb7fb3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This all works for me:
- existing DAP-04 aggregators will be treated as supporting DAP-04, but any new aggregators that support DAP-05 will include the protocol version advertisement so this will all work
- inferring task protocol version from aggregator version also makes sense.
fcb7fb3
to
22d230d
Compare
Co-authored-by: David Cook <[email protected]>
this is because there's always an implicit top bucket greater than the highest bound
closes #410