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

[Ben Campbell <[e-mail]>]

Thanks for the response! Comments inline:

Ben.

> On May 22, 2017, at 11:07 PM, Brian E Carpenter <[e-mail]> wrote:
> 
> 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.

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


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

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

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

Okay.

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