[Resending to ietf@xxxxxxxx] I am curious why an IETF WG (SIDR) has endorsed a wholly new protocol through which to configure policy information on routers (as proposed in draft-ietf-sidr-rpki-rtr), particularly when the IETF already has existing standards to do so, namely: NETCONF [RFC4741] & YANG [RFC6020]? In addition, given that NETCONF + YANG were designed for extensibility, they would allow operators to take it upon themselves, if they wish, to easily enrich and/or extend RPKI-validated data before it is sent from an RPKI cache to routers, (compared to a binary protocol like RPKI-RTR). I don't see any discussion in draft-ietf-sidr-rpki-rtr as to whether: a) consideration was given to develop a YANG model, for validated RPKI data, which then would use NETCONF to securely transport that from an RPKI cache to the router; and, b) if it was considered, what were the reasons that approach was not pursued. In the short-term, I am concerned that, from an architectural point-of-view, the IETF has not chosen to re-use the existing set of very successful configuration protocols, namely NETCONF & YANG, for the task of configuring validated policy information from the RPKI to/within routers. This could not only cause confusion in the industry, but also lead to additional operational costs to operators who would have to maintain two protocols for configuring policy on their network: RPKI-RTR and, separately, NETCONF/YANG, particularly when those same operators already have to use NETCONF/YANG for other router configuration tasks anyway. Furthermore, NETCONF is in shipping & deployed implementations today vs. RPKI-RTR which is likely still several years in the future before it starts shipping in GA SW releases, not including the time it will take to qualify it before it sees actual network deployment. Longer term, development of a new configuration protocol, (namely RPKI-RTR), likely has architectural implications given the discussion that occurred at IETF 82 in the SDN "informational-gathering session", held on Thursday afternoon. Although it is a too early to tell where the discussions at that SDN meeting will ultimately lead to, there did seem to be a significant amount of interest in the architectural concept of looking at the problem of attempting to configure networks using a top-down methodology and, in particular, re-using those existing IETF protocols, e.g.: NETCONF/YANG, SNMP, etc., southbound from an SDN Orchestrator toward various network elements. As such, it may be useful for the IESG and IAB to collaborate on the long-term architectural implications and additional complexity that another "southbound protocol", specifically: RPKI-RTR, could have on future efforts such as those discussed in the SDN meeting. -shane On Nov 29, 2011, at 3:51 PM, The IESG wrote: > The IESG has received a request from the Secure Inter-Domain Routing WG > (sidr) to consider the following document: > - 'The RPKI/Router Protocol' > <draft-ietf-sidr-rpki-rtr-19.txt> as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@xxxxxxxx mailing lists by 2011-12-13. Exceptionally, comments may be > sent to iesg@xxxxxxxx instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > In order to formally validate the origin ASs of BGP announcements, > routers need a simple but reliable mechanism to receive RPKI > [I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This > document describes a protocol to deliver validated prefix origin data > to routers. > > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf