Hi all, My apologies for being two months late with this reply, but fwiw I would like to support what Carlos and others raised in this thread about sidr-ops being inclusive to CA operators.
Tim > On 23 Aug 2016, at 16:48, Christopher Morrow <[email protected]> wrote: > > routing-ads -> rtg-ads. > > On Tue, Aug 23, 2016 at 10:32 AM, Christopher Morrow > <[email protected]> wrote: > (fixed sidr-chairs, don't know routing-ads alias, apparently) > > On Tue, Aug 23, 2016 at 10:22 AM, Christopher Morrow > <[email protected]> wrote: > The changes from Carlos seem ok to me, and declan's points about ca/rir also > seem on point. > thanks! (for fixing the clearly network centric text!) > > On Mon, Aug 22, 2016 at 5:03 PM, joel jaeggli <[email protected]> wrote: > On 8/17/16 7:43 PM, Declan Ma wrote: > > Joel, > > > > When we are talking about SIDROPS, we are referring to that BGP speakers > > are resorting to RPKI relying party to get verified INR authorization > > information, which is created by CA and maintained by repository managers. > > > > IMHO, network operators are not the only RPKI role that the community is > > going to solicit input from. CA operators, repository operators, RP > > service providers all bear significance as with SIDR Operations, in > > identifying issues and sharing experiences. > Yeah there are a bunch of actors who are operators of elements other > than networks. > > RIRs and CAs spring immediately to mind. > > Although network operators could also be CA operators, repository > > operators, RP service providers, yet RIRs, CA and repository backend > > service providers, and third party RP don’t fall into the category of > > ‘network operators’. > > > > I would suggest the “The goals of the sidr-ops working group” be adjusted > > slightly, with CA operators, repository operators, RP service providers > > involved. > yeah I think the tent should be inclusive. > > > > Di > > > >> 在 2016年8月18日，00:46，joel jaeggli <[email protected]> 写道： > >> > >> Folks, > >> > >> Some discussion prior to the recent IETF led us to ask the ask the > >> question about what to do now that SIDR is close to having achieved it's > >> major milestones. One possible approach we have been looking at is to > >> Charter a new activity associated with the deployment and operation of > >> SIDR systems within networks. Here is an initial stab at a sidrops > >> charter with the milestones drawn from existing SIDR discussion. > >> > >> https://datatracker.ietf.org/doc/charter-ietf-sidrops/ > >> > >> > >> The global deployment of RPKI, Origin Validation of BGP announcements > >> and BGPSEC, collectively called SIDR, is underway, creating an Internet > >> Routing System consisting of SIDR-aware and non-SIDR-aware networks. > >> This deployment must be properly handled to avoid the division of > >> the Internet into separate networks, ensuring as secure a routing > >> system as possible, through encouraged deployment of the SIDR > >> technologies. > >> > >> The SIDR Operations Working Group (sidr-ops) develops guidelines for > >> the operation of SIDR-aware networks, and provides operational guidance > >> on how to deploy and operate SIDR technologies in new and existing > >> networks. > >> > >> The main focuaess of the SIDR Operations Working Group are to: > >> o discuss deployment and operational issues related to SIDR technologies > >> in networks which are part of the global routing system. > >> o gather and discuss deployment experiences with the SIDR technologies > >> in > >> networks which are part of the global routing system. > >> > >> The goals of the sidr-ops working group are: > >> > >> 1. Solicit input from network operators to identify > >> operational issues with a SIDR-aware Internet, and determine solutions > >> or workarounds to those issues. > >> > >> 2. Solicit input from network operators to identify > >> operational interaction issues with the non-SIDR-aware Internet, > >> and determine solutions or workarounds to those issues. > >> > >> 3. Operational solutions for identified issues should be developed > >> in sidr-ops and documented in informational or BCP documents. > >> > >> These documents should document SIDR operational experience, including > >> interactions with non-SIDR-aware networks, the interfaces between > >> SIDR-aware > >> and non-SIDR-aware networks, and the continued operational/security > >> impacts > >> from non-SIDR-aware networks. > >> > >> SIDR operational and deployment issues with Interdomain Routing Protocols > >> are the primary responsibility of the IDR working gruop. However, the > >> sidr-ops Working Group may provide input to that group, as needed, and > >> cooperate with that group in reviewing solutions to SIDR operational and > >> deployment problems. > >> > >> Future work items within this scope will be adopted by the Working > >> Group only if there is a substantial expression of interest from > >> the community and if the work clearly does not fit elsewhere in the > >> IETF. > >> > >> There must be a continuous expression of interest for the Working > >> Group to work on a particular work item. If there is no longer > >> sufficient interest in the Working Group in a work item, the item > >> may be removed from the list of Working Group items. > >> > >> > >> Feedback on this proposal and possible milestones above and beyond those > >> currently present is appreciated before we circulate this for wider review. > >> > >> _______________________________________________ > >> sidr mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/sidr > > > > > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr > > > > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
