Hi John, > On 13 Sep 2016, at 15:54, John C Klensin <john-ietf@xxxxxxx> 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