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 <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
> >> 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

_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to