Re: [dmarc-ietf] Additional review of draft-ietf-dmarc-arc-protocol-16

2018-08-03 Thread Seth Blank
As stated previously, I've made all stated changes, with the exception of the below, for further discussion: On Thu, Aug 2, 2018 at 6:43 AM, Dave Crocker wrote: > 4. Protocol Elements >> > > > I keep thinking that it would help to have some summary text, possibly > with a figure, that shows

Re: [dmarc-ietf] Additional review of draft-ietf-dmarc-arc-protocol-16

2018-08-03 Thread Seth Blank
On Fri, Aug 3, 2018 at 11:04 AM, Dave Crocker wrote: > > At a minimum, I suggest clear and relatively forceful language, making > clear the privacy concerns. (Privacy is new enough and, frankly, fuzzy > enough as a technical topic, to warrant the redundancy I usually argue > against...) > What

Re: [dmarc-ietf] Additional review of draft-ietf-dmarc-arc-protocol-16

2018-08-03 Thread Dave Crocker
On 8/3/2018 10:16 AM, Brandon Long wrote: >    o  smtp.client-ip - The connecting client IP address from which the >       message is received. this seems such a large privacy concern, I question allowing it here. (This highlights the difference between passing information

Re: [dmarc-ietf] Additional review of draft-ietf-dmarc-arc-protocol-16

2018-08-02 Thread Seth Blank
On Thu, Aug 2, 2018 at 6:43 AM, Dave Crocker wrote: > Continuing my review of: draft-ietf-dmarc-arc-protocol-16 > > NB: These are comments, not demands. Use however is helpful... Dave, thanks for these comments. I've quickly scanned your notes and nearly everything makes sense. I'll go

[dmarc-ietf] Additional review of draft-ietf-dmarc-arc-protocol-16

2018-08-02 Thread Dave Crocker
Continuing my review of: draft-ietf-dmarc-arc-protocol-16 NB: These are comments, not demands. Use however is helpful... 4. Protocol Elements I keep thinking that it would help to have some summary text, possibly with a figure, that shows the role of individual header fields and sets