All, Thanks to Geoff and Tom for pointing out that we do have definitions of what PS and Experimental mean. If those definitions are wrong (c.f. some of the comments relating to whether some designation does or doesn't advance some greater good or agenda) is not a question for SIDR to decide -- if you don't like the definitions, propose revisions to RFCs 7127 and/or 2026.
Based on the definitions provided in those two RFCs, BGPSEC fits into the PS bucket. If there is debate about whether it falls short of any of the RFC 7127 criteria for PS, the best time to have raised that would have been at WGLC but of course there's still IESG review and IETF LC, so there's ample time for anyone who wants to be heard. $0.02 from this individual WG member, --John > On Apr 13, 2016, at 2:17 PM, Stephen Kent <[email protected]> wrote: > > I didn't attend the IETF meeting, but I did listen to the Wednesday SIDR > session, at > which the issue was raised as to whether the BGPSec RFC should be standards > track > or experimental. > > I believe standards track is the right approach here. This document has been > viewed as standards track since we began work on it long ago. It is the > successor > to the origin validation standards, addressing the residual vulnerabilities > that > persist based on that use of the RPKI. From the perspective of promoting > adoption > it is critical that this remain a standards track document; router vendors > will > be unlikely to devote resources to design and implementation if BGPsec is > labeled > experimental. I agree that this is new technology, but I heard that we > already have > a couple of implementations already, and we may discourage others from > continuing to > work on BGPSec implementations if we downgrade the status of the RFC. The > design has > evolved to accommodate real-world routing deployment topics such as the role > of IXPs > and AS migration. In my long experience in the IETF experience, the level of > attention > to these an analogous details makes BGPsec a very solid candidate for > standards track > publication. > > Steve _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
