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

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

On 01/06/2017 08:36, Ben Campbell wrote:
> 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.

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

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