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

[Ben Campbell <[e-mail]>]

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 <[e-mail]> wrote:
> 
> Comments on some more of Ben's comments:
> 
> On 23/05/2017 13:25, Ben Campbell wrote:
>> 

[…]

>> -5, Privacy and Confidentiality: Did people consider IP Addresses and
>> 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.
> 

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.


>> -7, Grasp Message and Options table: Why "Standards Action"? Would you
>> expect some harm to be done if this were only Spec Required?
> 
> I have asked the WG's opinion.

Okay, I will follow that separately.

> 
>> 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.
> 
> I have asked the WG's opinion.

Okay.

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

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

[…]