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

[Brian E Carpenter <[e-mail]>]

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

On 23/05/2017 13:25, Ben Campbell wrote:
> 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.

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.

> 
> -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)

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.

> 
> -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.)

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

> 
> - 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?
> 
> 
>