Subject: [Anima] Ben Campbell's No Objection on draft-ietf-anima-grasp-12: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Mon, 22 May 2017 18:25:22 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-anima-grasp-12: 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-anima-grasp/

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

Substantive:

-3.5.2.1: "Messages MUST be authenticated and encryption MUST be
   implemented."
Should the latter be "... MUST be used"? It seems odd for authentication
to be MUST use, but crypto to only be MTI.

-3.5.4.3: "An exponential backoff SHOULD be used for subsequent
   repetitions, to limit the load during busy periods."
Why not MUST? Also, is there a retry limit?  (Comment applies to the
other sections that mention retries with exponential backoff)

-3.5.6.2: "To ensure that flooding does not result in a loop, the
originator of
   the Flood Synchronization message MUST set the loop count in the
   objectives to a suitable value "
I assume this is true for discovery and negotiation as well? I don't
think it was mentioned in those sections (although I think I saw a
related mention in the message format sections.)

- 3.10.5: "SHOULD NOT be used in
   unmanaged networks such as home networks."
Why not MUST?

-5, Privacy and Confidentiality: Did people consider IP Addresses and
other potentially persistent identifiers as impacting privacy?

-7, Grasp Message and Options table: Why "Standards Action"? Would you
expect some harm to be done if this were only Spec Required?

Editorial:

- Is section 2 expected to be useful to implementers once this is
published as an RFC? Unless there's a reason otherwise, I would suggest
moving this to an appendix, or even removing it entirely. As it is, you
have to wade through an unusual amount of front material before you get
to the meat of the protocol.

- Along the lines of the previous comment, I found the organization a bit
hard to follow. I didn't find actual protocol details until around page
21. Procedures are split (and sometimes repeated) between the procedure
sections and the message format sections. I think that will make this
more difficult and error prone than necessary for implementors to read
and reference.  I fear readers will read one section and think they
understand the procedures, and miss a requirement in the other.

- 3.5.2.2: First bullet:
Please consider a "MUST NOT construction. "MUST only" can be ambiguous.
It would be helpful to explain why the loop count must not be more than
one. I can infer that from the later sections on relays, but it was not
obvious when reading this section. And unless I missed something, there's
no text that puts the two ideas together.

- 3.5.4.5: This section seems redundant to the similar sections under
negotiation . Since those sections have more information, would it make
sense to consolidate them there?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 May 2017 16:07:46 +1200

Again cherry-picking in line, as I'm on vacation travel this week:

> https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/

This was a bit of a compromise between the authors. Personally I'd prefer
MUST be used, but we'd need to ask the WG.

> other sections that mention retries with exponential backoff)

Personally I'm reluctant to specify this too tightly. I'd expect the
retry limit to be use-case dependent; there might be cases where trying
for ever is the right thing to do. Similarly for the strictly exponential
backoff; for example, backing off to one try per minute might be reasonable
for a given application, or to one try per hour for another.

> related mention in the message format sections.)

Discovery and flooding are multicast, so it really is about loop
prevention. I thought we did say the same for discovery, if not
that needs fixing. In negotiation it's a bit different - it's part
of the semantics of the application (how many rounds of negotiation
make sense) so there's not much to say from the protocol design
viewpoint. 

More when I get home.

    Brian

---

From: Ben Campbell <[email-masked]>
Date: Tue, 23 May 2017 09:37:46 -0500

Thanks for the response! Comments inline:

Ben.

> On May 22, 2017, at 11:07 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Okay. I was mainly checking that the existing language was intentional.

> for a given application, or to one try per hour for another.

Do I understand correctly that you want there to be some congestion avoidance strategy, but it could be something other than exponential backoff? Would it make sense to say something like the following: 

"Some strategy MUST be in effect to avoid causing network congestion with too many repetition. This stragegy SHOULD be an exponential backoff, but other strategies might be reasonable for specific applications."

> make sense) so there's not much to say from the protocol design

Okay.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 May 2017 15:59:56 +1200

...
> expect some harm to be done if this were only Spec Required?

Personal opinion: I see potential for harm. I could imagine that if
GRASP is a success, then with experience we might be more relaxed
about it, but for now I tend to be conservative about it. Of course,
the WG may disagree...

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 May 2017 16:02:50 +1200

> - Is section 2 [Requirements] expected to be useful to implementers once this is> published as an RFC? Unless there's a reason otherwise, I would suggest

I'm open to that, and you are not the only reader with that comment.
But we'd need WG consent...

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 May 2017 16:16:24 +1200

Comments on some more of Ben's comments:

>    unmanaged networks such as home networks."

Yes, that is more logical.
> other potentially persistent identifiers as impacting privacy?

Here we are dealing with the addresses of network elements, not user
devices, so there don't seem to to be personal privacy issues.

> expect some harm to be done if this were only Spec Required?

I have asked the WG's opinion.

> to the meat of the protocol.

I have asked the WG's opinion.

> understand the procedures, and miss a requirement in the other.

I understand the problem but I don't have a solution; there is an attempt
to give an overview before getting into message formats, but that leads
to some repetition as well.

> no text that puts the two ideas together.

OK

> sense to consolidate them there?

It makes sense to condense it. I think the forward reference is useful.

Regards
     Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 May 2017 14:51:48 -0400

> GRASP is a success, then with experience we might be more relaxed about
    > it, but for now I tend to be conservative about it. Of course, the WG
    > may disagree...

Is it easier to raise the bar or lower it?  I think lowering is easier.
I could live with "Spec Required" or even FCFS for M_* values >65536, btw.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Ben Campbell <[email-masked]>
Date: Mon, 29 May 2017 17:41:40 -0500

> On May 28, 2017, at 10:59 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> the WG may disagree…

If that’s the WG answer, I am perfectly happy. I just want to make sure people have thought about it.

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 31 May 2017 15:36:53 -0500

Hi, thanks for the responses. Further comments below.  I deleted sections that seem resolved.

Thanks!

Ben.

> On May 28, 2017, at 11:16 PM, Brian E Carpenter <[email-masked]> wrote:
> 

[…]

> devices, so there don't seem to to be personal privacy issues.

Did I miss something that indicated that these network elements can’t/won’t ever be end-user devices?

Now, I don’t necessarily think that would change the privacy considerations—I was mainly questioning the assertion the “ no personal information” assertion.

> I have asked the WG's opinion.

Okay, I will follow that separately.

Okay.

> to some repetition as well.

On reflection, it’s probably not worth trying to reorganize things this late in the process. Other reviewers seem to have followed things just fine, so maybe it’s me :-)

[…]

---

From: Ben Campbell <[email-masked]>
Date: Wed, 31 May 2017 15:39:22 -0500

> On May 28, 2017, at 11:02 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> But we'd need WG consent…

Understood. I’m not going to stand in the way if the WG wants to keep things as is. But I do think that moving/removing the section would make the document more friendly to it’s post-publication target audience.

Thanks!

Ben.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 1 Jun 2017 11:18:00 +1200

> Now, I don’t necessarily think that would change the privacy considerations—I was mainly questioning the assertion the “ no personal information” assertion.

No, I don't think you missed anything, because we can't reasonably assert
that. People can install what they want where they want. We will qualify
the text accordingly; it only strengthens the case for encryption.
 
> On reflection, it’s probably not worth trying to reorganize things this late in the process. Other reviewers seem to have followed things just fine, so maybe it’s me :-)

No, it's complicated. I have exactly the same problem - both in
updating the draft and in chasing bugs through the prototype code.
I just don't think it can be fixed by reorganising the text, because
to some extent you have to understand everything before you can
understand anything.

Thanks
    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 1 Jun 2017 15:52:17 +1200

> I could live with "Spec Required" or even FCFS for M_* values >65536, btw.

Probably, but it's definitely impossible to squeeze toothpaste back in the tube,
so IMHO lowering the bar later is the safer approach.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 1 Jun 2017 15:54:09 +1200

> But we'd need WG consent...

I'm not hearing much from the WG but since several new readers have made
this comment, my proposal is to move the requirements into an Appendix.
If we don't like the look of it when done, we can always move them
back again.

    Brian