Randy, > well, actually, the discussion in april was walking around many of the > implications thereof. it is hard to discuss "do we keep/replace > AS[4]_PATH" as it is abstract and draws deep philosophical discourse > with no hard handles on technical decision points.
I think you should remove the [4] from the discussion. 4 bytes ASN is mandatory for BGPSEC speakers. So, there should be no AS4_PATH attributes between BGPSEC routers to keep/replace. Roque > otoh, i would be really interested in hearing/discussing if anyone sees > any show-stoppers to the current draft doing so. > > i am amused that the current draft says, in the intro, > > 2. Every AS listed in the AS_Path attribute of the update explicitly > authorized the advertisement of the route to the subsequent AS in > the AS_Path. > > when there is no bgpsec as_path. :) > >> The absence of the AS_PATH did come up in discussing other topics (see >> the minutes), but we did not discuss it directly. > > see above > >> (2) router private key provisioning. >> >> In the interim in San Diego, there were requests (from operators) that >> guidance to operators of how to provision a router with the needed >> keys would be a good idea. We had some discussion in the Paris >> meeting of two drafts discussing provisioning the routers with their >> needed private keys. There's also been a recent flurry of discussion >> on the list. > > no comments on the new version of draft-ietf-sidr-rtr-keying-00.txt. > would appreciate some now or we can ask for wglc. > > there have been no comments on list to confed and aliasing. may we call > them done? > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
