ietf
[Top] [All Lists]

Re: Last Call: <draft-levine-herkula-oneclick-04.txt> (Signalling one-click functionality for list email headers) to Proposed Standard

2016-09-18 05:30:09
Hi John,

On 13 Sep 2016, at 15:54, John C Klensin <john-ietf(_at_)jck(_dot_)com> wrote:

After this (to me very helpful) discussion, let me summarize my
concerns and then move on -- if no one other than myself and
those directly involved care, I don't want to spend more time on
it.  The two issues below are almost completely separate.

(1) Traditionally, the IETF makes standards _for the Internet_.
When the needs, perspectives, and views of tradeoffs of a few
very specific providers (whether specific by size or some other
criteria) are different from those of the vast majority of
providers (by count, not number of users or, in this case,
number of messages), then we have a problem that, as far as I
know, the IETF community has never really addressed.  With no
disrespect to Google or AOL (or, in other areas and for example,
Cisco, Huawei, and Juniper) one extreme version of the question
is whether it appropriate for 600 pound gorillas or a consortium
or them to shape the Internet, even if that hurts or locks out
smaller providers or users with different profiles and needs.  

I don't know the answer to any of those questions, nor to what
the IETF should do about them.  They raise some old topics about
who really has change control of a suggested or approved
standard, but that is only part of the issue.  IMO, a serious
discussion is probably overdue.  I don't think that discussion
should be placed in the critical path of any given document if
we can process those documents without setting precedents that
preempt the discussion and its possible conclusions.

(2)  For a proposed standard that meets both the criteria of RFC
2026 and successors and what I believe to be IETF's traditional
approach and role, I think this document needs a lot of work.  I
think it should be explicit about use cases and motivations
(reflecting your comments above); that it should contain (or
normatively reference) enough information to permit
interoperable implementations and safe use without
side-knowledge that is not _very_ generally available; that it
should discuss difference (and maybe tradeoffs) among different
types of provider and user models; and that it should have a
sufficient discussion of security issues to permit readers to
assess risks, including risks associated with weak
implementations.  I don't think our norms for Proposed Standards
permit a document to say "security is out of scope" or even
"deliberate malicious behavior is out of scope", so that needs
to be fixed.

With one possible exception, all of this second issue is about
the spec, not the header/protocol.   The exception is that, for
interoperation this is appropriately safe, either you need to
describe the conditions for a sufficiently protective hash and
make its presence a MUST requirement or you need an in-depth
Security Considerations discussion about that issue.

The document got updated by John L. and I think your issues were addressed. As 
the document only spent 4 days in IETF LC, I will let it continue. I can add an 
extra week for reviews after the LC  is finished, to make sure people have 
enough time to review changes.

Best Regards,
Alexey


<Prev in Thread] Current Thread [Next in Thread>