From what I am reading, there isn't an interest in splitting puzzles out as experimental. If you feel strongly that puzzles should be split out into a separate experimental draft, please speak up. If we don't hear anything by Monday, June 6, we will begin making preparations to send the draft as-is to the IESG.
Since we are wrapping up the WGLC, please also consider this a final call for comments on the draft before we send it off. Thanks, Dave > -----Original Message----- > From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Valery Smyslov > Sent: Tuesday, May 31, 2016 2:05 AM > To: Yoav Nir <ynir.i...@gmail.com> > Cc: ipsec@ietf.org; p...@nohats.ca > Subject: Re: [IPsec] Status of draft-ietf-ipsecme-ddos-protection > > >> The concern is not about stand-alone puzzles document. It is about an > >> Experimental status of that document versus Standards Track in the > current draft. Vendors tend to ignore Experimental RFCs. > > > > The conventional wisdom is that vendors tend to ignore whatever status > > the IETF assigns to documents and implement whatever meets their goals. > > That's true in general. However Experimaental status makes vendors more > suspicious that they will spend resources implementing the protocol and gain > little, because most other vendors will refrane from implementing it. For > puzzles to work they must become ubiquitous. > > > My preference is to keep it all in one document, and clearly state > > that the puzzle part of the document is OPTIONAL, meaning that you can > comply with the RFC even without implementing it. > > That's my preference too. In fact, the current draft doesn't mandate to > implement (or even to use) puzzles, so they are already optional. > > > There is a concern about an Initiator that does not implement puzzles > connecting to a Responder that does. > > Things will work fine until there is a DoS attack and then we’re > > helping the attacker by denying service to the non-implementing > > Initiator. And that could happen between an Initiator and Responder, > > both of whom can claim compliance with the document. This isn’t great, > but separating them into two documents does not make the problem go > away. > > That's true. > > > Yoav > > Regards, > Valery. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
