Re: Ben Campbell's Discuss on draft-ietf-dmm-4283mnids-04: (with DISCUSS and COMMENT)

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