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

[Alexey Melnikov <[e-mail]>]

Hi John,

> On 13 Sep 2016, at 15:54, John C Klensin <[e-mail]> 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