Describe the risks of filtering at the DS #258
Conversation
draft-ietf-mls-architecture.md
Outdated
| For example, having the DS wait to update its state until it gets confirmation | ||
| of acceptance from a quorum of members provides some protection against buggy | ||
| clients. It is up to the designers and operators of a DS to ensure that | ||
| sufficient mechanisms are in place to address these risks. |
There was a problem hiding this comment.
I believe this PR is essentially the same as mine except that you've removed the proposal to defer to clients / allow forks, with a proposal to have a quorum. Is that a correct statement? Why do you think quorum is better than allowing forks, when quorum requires all group members to be online and forking can be offline?
|
I think this PR does a good job at framing the problem described in #251, however I think it would be best to refrain from trying to give solutions: the only solution would be to transmit all commits in a consistent order, and any attempt to filter may lead to DoS. The architecture document should allow the DS to filter (because actual deployments will filter), but warn about the risks it implies. |
|
I propose we take Richard's first two grafs more or less as-is and then reduce the last graf to say:
|
|
@ekr done |
Fixes #251