> On Apr 15, 2016, at 11:09, John G. Scudder <j...@juniper.net> wrote: > > 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.
Not liking something very much is not a great basis for experimental status vs ps as opposed to yes vs not at this time. IMHO when we look at BGPSec we've go to ascertain whether we can live with the consequences of various actors outside the IETF participants deciding it's cooked enough to deploy, use, require and so on. >From my vantage point it's about time, not because we're done, but the >documents are not going to get much more cooked, we've accumulated significant >infrastructure around it, and the marketplace needs to have as say on >deployment and this is how we signal that. > $0.02 from this individual WG member, > > --John > >> On Apr 13, 2016, at 2:17 PM, Stephen Kent <k...@bbn.com> 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 > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
