At Wed, 21 Dec 2016 12:20:54 +0000, Alvaro Retana (aretana) wrote:
...
> it still doesn?t tell me what the child should do. I don?t think
> you want to specify taking up one or the other, but at least include
> some text that says that the child can choose.
>
> In thinking about this I came up with another question. A
> repository doesn?t have to honor every publisher_request it
> receives, right? Specially ones that are the result of a referral?
> There is a ?refused? error reason defined, so that takes care of
> that?but I?m thinking that as a client I might want to take an
> <offer> instead of playing around with a <referral> because I know
> for sure my parent can do the job. I?m sure there are other
> considerations that the child should take into account. I?m ok if
> you just write that the selection criteria is out of scope.
I just added this to the end of "Protocol Walk-Through":
<t>
Any RPKI operator is free to run their own publication service
should they feel a need to do so, and a child need not accept
any particular <offer/> or <referral/>. In
general, having a smaller number of larger publication
repositories is probably good for overall system performance,
because it will tend to reduce the number of distinct
repositories from which each relying party will need to fetch,
but the decision on where to publish is up to individual RPKI
CA operators and out of scope for this protocol.
</t>
I hope this addresses the issue. Same URLs for updated version:
> Proposed -05, reflecting comments from AD review:
>
>
> https://subvert-ietf.hactrn.net/rpki-oob-setup/draft-ietf-sidr-rpki-oob-setup-05.txt
>
> https://subvert-ietf.hactrn.net/rpki-oob-setup/draft-ietf-sidr-rpki-oob-setup-05-from-04.diff.html
>
> Absent objections, I will post to I-D repository, probably tomorrow.
I think we are close enough at this point that I will push this
version this afternoon. Can always do another rev if we must, but I
want to get these changes into the version that directorates are being
asked to review.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
