I apologize for taking a while to circle back on this—I missed the fact that there was an update.
Version 5 changes the assertion that “some of these identifiers” may be considered private information to simply saying mobile identifiers are private information, and changes the lower-case “should" encrypt to a MUST. That resolves my DISCUSS point. I will clear. Thanks! Ben. > On Feb 15, 2017, at 9:47 PM, Ben Campbell <[email protected]> wrote: > > Ben Campbell has entered the following ballot position for > draft-ietf-dmm-4283mnids-04: 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/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > The security considerations says some of these identifiers can carry > sensitive information, and when they do you should encrypt. This leaves > it to the reader to decide which might be sensitive. The draft should > tell the reader which ones the working group thinks are sensitive, > keeping in mind that if an identifier is sometimes sensitive, it usually > needs to be treated as if always sensitive. (It's hard for deployed code > to figure out when it is or isn't sensitive.) > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with Stephen's, Alissa's, and Mirja's discusses. I especially > agree that we should not standardize new identifiers without justifying > each one. > > Section 5 says this document does not impact existing security > mechanisms. But it does add new data elements, and acknowledges some of > them may be sensitive. Thus I think the "does not impact" assertion needs > some supporting discussion. Are the existing mechanisms still adequate? > Why? > > There are a bunch of acronyms that would benefit from expansion on first > mention. > > _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
