nit: If this is 6810bis, shouldn't it formally list 6810 in the updates/obsoletes metadata?
Other comments: Section 6 Expire interval - this seems out of step with the way that we've done most things in RPKI, i.e. what to do with the information provided is usually thought of as a matter of local policy. I realize that there is increasing risk to keeping the data beyond the expiry time as it grows more stale, but there isn't much justification for why this MUST NOT is present. I think that perhaps the tradeoff between staleness and everything failing back to unknown status is something that the operator needs to weigh themselves. We could provide guidance that [MUST/SHOULD] NOT keep data from a certain cache beyond expiry time *if* another cache is available, but acknowledge that in some cases stale info may be more desirable than nothing at all (unless that's not actually true and I'm missing something...) This is discussed in the failover scenarios in the bottom of section 10 (only keep data if you don't have a full set from another cache) but figured I'd mention it in case we think there's some tweaks necessary in the section 6 text. Also - Since we say in section 10 that it is permissible to hold data from multiple caches, the doc appears to be missing guidance on what the router side of RPKI-router should do in the case where there are multiple caches that disagree with one another. It does say MUST NOT distinguish between data sources when validating, but that may not cover this scenario. This may be as simple as recommending that in the case where data from multiple caches is held and specific entries conflict with one another, there SHOULD be an odd number of caches so that there is basis for comparison to determine which cache is out of sync or providing incorrect info. (i.e. Have 3 so that you can go with the 2/3 that agree) Thanks, Wes On 3/17/15, 4:07 AM, "Sandra Murphy" <sa...@tislabs.com> wrote: >A reminder to everyone that this wglc ends Mar 20. > >There have been a couple of detailed responses. There should be more, in >order to judge consensus to publish. > >--Sandy, speaking as one of the wg co-chairs and chief nag > >On Mar 6, 2015, at 4:22 AM, Sandra Murphy <sa...@tislabs.com> wrote: > >> The authors of The Resource Public Key Infrastructure (RPKI) to Router >>Protocol believe that the work is ready for a working grow last call. >> >> This starts a last call for that draft. You may find it at >>https://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bis-03. >> >> Please comment to the list whether you believe that this draft is ready >>for publication. The wglc will be two weeks, ending on Friday, March 20. >> >> --Sandy, speaking as one of the wg co-chairs > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
