Subject: [Roll] Stephen Farrell's No Objection on draft-ietf-roll-applicability-ami-14: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 27 Sep 2016 04:53:44 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-roll-applicability-ami-14: No Objection

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-roll-applicability-ami/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the changes in response to my discuss ballot.

In the new privacy considerations section I think there
are two changes still needed:

1) The reference to I_D.thaler... should be to
draft-ietf-6lo-privacy-considerations which replaced
the Dave Thaler's individual draft. 

2) RFC6550 doesn't contain the term "privacy" at all
so I'm not sure what section(s) you're referring to there.

[DEVCC] does however seem to cover the issues, so
I've cleared my discuss. That said, I'm not sure if
the privacy considerations for deployments outside
the US may be significantly different, (I would not
be surprised if they are) so I'd  encourage you to also 
search for and reference e.g. a European equivalent 
document if there is one available. I've not read it
but maybe [1], or some of the references contained
in [1] might be useful.

   [1]
http://publications.lib.chalmers.se/records/fulltext/215870/215870.pdf

OLD COMMENTS below - I didn't check 'em.

- 1.3: what's the 3rd bullet mean? It's worded very
ambiguously. With s/(vs. non-storing)// it'd be clear.

- section 3: "a potentially significant portion of which
is taken up by protocol and encryption overhead" seems
overstated to me - are there numbers to back that up?

- 5.1, last sentence: why is it important to note that?
explaining would be good

- 7.2.3: I don't get what you're telling me here that
assists in security or interop?

- section 9: please provide references to back up the
assertion that "many available security mechanisms are not
practical for use in such networks" for some relevant
security mechanisms. The problem is that such assertions
are used to justify doing nothing at all so they ought not
be blithely made.

- 9.1: "are unique per device" etc is the only sensible
thing and would be nice if always true, but that is often
not the case - why state what's known to not be true? Or
are you trying to say something else? 

- 9.2: "it is replaced" - again that's not true, only
devices known to be compromised would be replaced, which
is by no means all compromised devices

- 9.3: "already existing" - you really should have a
reference there.

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Tue, 27 Sep 2016 12:12:42 +0000

Hi Stephen,

[NCW] My bad, will provide the update.

>so I'm not sure what section(s) you're referring to there.
[NCW] I was mapping it to the 6lo-privacy-considerations draft, but yes
As it doesn’t contain privacy I can remove this reference.

>http://publications.lib.chalmers.se/records/fulltext/215870/215870.pdf
[NCW] This may be a good one, but I will double check to see if there are
Others that may be as if not more relevant.

[NCW] As to the OLD comments below, they were also addressed in the draft
already
(I had sent a response to those a very long while ago!)….

	Nancy