On Apr 4, 2011, at 10:24 AM, Stephen Kent wrote: > At 1:24 PM -0400 4/2/11, Russ White wrote: >> Content-Type: multipart/signed; micalg=pgp-sha1; >> protocol="application/pgp-signature"; >> boundary="------------enig5992EC3DE2163EED1CCB39EC" >> >> >>> As it stands now, BGPSEC is opt-in. So it seems that clearly >>> documenting these issues is more operative than make absolute >>> requirements about them. >> >> Does this mean BGPSEC is not designated as a standards track document? >> how can a security system actually work if it's "opt in?" It sounds like >> this is an area that needs some discussion around it. >> >> :-) >> >> Russ > > A standards track protocol is usually mandatory to implement, but using > it is a local context determination. I expect that's what was meant by > opt-in.
Thanks Steve, that is what what I meant. Clearly the hope (and value proposition) is that it is deployed farily ubiquitously, but the design recognizes that some parts of the net might choose not to run it, or only run part of it (simplex mode). I have yet to see a box kicked off the net for choosing to skip a "mandatory to implement" feature. I think we have to deal with the market realities, no matter what the document's boiler plate says. dougm > > Steve _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
