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.
> On 23 Aug 2016, at 16:48, Christopher Morrow <morrowc.li...@gmail.com> wrote:
> 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
> >> email@example.com
> >> https://www.ietf.org/mailman/listinfo/sidr
> sidr mailing list
> sidr mailing list
sidr mailing list