>I think that this is a specific corner case for the more generic case of
>incremental
>deployment, where a given path has some routers/ASNs that support BGPSec
>and some that do not, and as far as I can tell, incremental deployment isn't
>really
>discussed as a concept beyond the [non]negotia
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Inter-Domain Routing Working Group of
the IETF.
Title : A Profile for BGPsec Router Certificates, Certificate
Revocation Lists, and Certification Requests
Gave this a review, and stumbled across an issue that may not necessarily
be gating to this draft, but should probably be addressed in some other
drafts.
Regarding this text in 4.2:
"Additionally, BGPsec requires that all BGPsec speakers will support
4-byte AS Numbers [RFC6793]. This is because
It appears the working group consensus is that a note should be made in the
security consideration section that hash collisions can occur and that a
relying party should notify the operators if any such collisions are discovered.
Could the authors please provide a new draft with such a security
We were about to ask the WG chairs for a WG Last Call on this document,
but then noticed that this is an informational document and its
attempting to update a standards track RFC
Changing the "intended status" of a doc seems easier than spinning a new
one. In any case, I would prefer to see t
This version has two major changes:
- it includes text that describes the impact of each of the adverse
actions,
in the context of each RPKI repository object type. This text was
added in
response to a request fro Andrei.
- the subsections have been re-ordered to be unifor
Hi Geoff,
In many cases we publish an Appendix on update documents detailing the
changes from previous version and given the rational that Arturo mentioned.
Roque
‹
Roque Gagliano
Tail-f Solutions Architect Southern Europe
+41 76 449 8867
On 13/10/15 20:06, "sidr on behalf of Geoff Huston
