routing-ads -> rtg-ads. On Tue, Aug 23, 2016 at 10:32 AM, Christopher Morrow < morrowc.li...@gmail.com> wrote:
> (fixed sidr-chairs, don't know routing-ads alias, apparently) > > On Tue, Aug 23, 2016 at 10:22 AM, Christopher Morrow < > morrowc.li...@gmail.com> 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 <joe...@bogus.com> 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 <joe...@bogus.com> 写道： >>> >> >>> >> 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 >>> >> sidr@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/sidr >>> > >>> >>> >>> >>> _______________________________________________ >>> 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
