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
>> <[email protected]> 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
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
