Sorry for letting this sit so long; I must have missed it somewhere (and thanks Alissa for the reminder!)
On Fri, May 03, 2019 at 01:48:45PM -0400, Christian Hopps wrote: > > > > On Apr 11, 2019, at 9:49 AM, Benjamin Kaduk via Datatracker > > <[email protected]> wrote: > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I think this document does introduce new security considerations, > > specifically the ability for one user to remove ("mask") tags from being > > visible to other users. A malicious user could interfere with the > > operations of other users/entities, especially in the case mentioned in > > an example where multiple semi-independent clients use tags to indicate > > modules to avoid that may be broken. > > So here was the thinking on this, since this document doesn't define any > actions or behaviors based on tags (or the lack of them) it's hard to talk > about what the security considerations would be. However, it is expected that > to be useful users (or future specifications) *will* define behaviors based > on tag use. The security section does talk about this case: > > " > Users of the tag-meta data may define various actions to be taken > based on the tag meta-data. These actions and their definitions are > outside the scope of this document. Users will need to consider the > security implications of any actions they choose to define. > " > > Which I believe covered this. For example, if an RFC were to define a > behavior based on the tag presence then it would need to talk about the > security concerns with that behavior. In some sense it covers this, but my Discuss is more about the somewhat-subtle point involving somewhat "long-range" interactions that it doesn't seem reasonable to expect people specifying tags to think about without help. > If this doesn't adequately cover your concern though, do you have a bit of > suggested text we could add? I'd suggest to add another clause at the end of the paragraph you quoted: ", including the potential for a tag to get 'masked away' by another user." > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > > Section 2 > > > > Similarly to Alissa's DISCUSS, perhaps "registered prefix" is better > > than "standard prefix". > > > > Section 2.4 > > > > Similarly, "future registration" or "future use" seem to be better fits > > for the intended sentiment. > > > > Section 3.2 > > > > I may be misreading, but this seems to be encouraging implementations to > > add new ietf:-prefixed tags that are not necessarily registered or > > specified in IETF-consensus documents. > > > > Section 7.2 > > > > This registry allocates prefixes that have the standard prefix > > "ietf:". [...] > > > > The registry name just talks about "tags"; are we really allocating > > *prefix*es? > > > > Fixed these, thanks. Thanks! -Ben _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
