At 6:07 PM -0400 5/3/11, Sam Hartman wrote:
Stephen == Stephen Kent k...@bbn.com writes:
I guess the only question I'd have remaining is whether ROAs or
other signed objects are intended to be used in other protocols
besides simply living in the SIDR repository?
Stephen == Stephen Kent k...@bbn.com writes:
Stephen The BGPSEC protocol being defined does not pass around ROAs
Stephen or other RPKI repository objects. It defines two new,
Stephen signed objects that are passed in UPDATE messages, and are
Stephen not stored in the repository.
At 7:48 AM -0400 5/4/11, Sam Hartman wrote:
Stephen == Stephen Kent k...@bbn.com writes:
Stephen The BGPSEC protocol being defined does not pass around ROAs
Stephen or other RPKI repository objects. It defines two new,
Stephen signed objects that are passed in UPDATE messages, and
Stephen == Stephen Kent k...@bbn.com writes:
Stephen At 7:48 AM -0400 5/4/11, Sam Hartman wrote:
Stephen == Stephen Kent k...@bbn.com writes:
Stephen The BGPSEC protocol being defined does not pass around ROAs
Stephen or other RPKI repository objects. It defines two new,
At 10:32 AM -0400 5/4/11, Sam Hartman wrote:
...
Let me see if I can summarize where we are:
You've describe an upgrade strategey for the origin validation in the
current set of docs. It depends on the ability to store multiple certs,
ROAs and other objects in the repository.
requirements
Steve, I'd like to thank you for working through these issues with me.
I think the new texxt you added before approval is very helpful. You
indicated you could add an additional sentence pointing out that
multiple signed objects would need to be used in order to deal with
phase 2 for end-entity
On 05/03/2011 01:43, SM wrote:
I am stupid but I am not that stupid to go and argue about a draft that
has been blessed by DNSOP and v6ops.
Blessed is rather strong. There are a non-zero number of people in
both groups (of which I am one) who don't like the draft, and don't
agree that
The IESG has received a request from the Source Address Validation
Improvements WG (savi) to consider the following document:
- 'SAVI Threat Scope'
draft-ietf-savi-threat-scope-05.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments
The IESG has approved the following document:
- 'Certificate Policy (CP) for the Resource PKI (RPKI'
(draft-ietf-sidr-cp-17.txt) as a BCP
This document is the product of the Secure Inter-Domain Routing Working
Group.
The IESG contact persons are Stewart Bryant and Adrian Farrel.
A URL of this
The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document:
- 'CA Key Rollover in the RPKI'
draft-ietf-sidr-keyroll-06.txt as a BCP
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please
The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document:
- 'A Profile for Resource Certificate Repository Structure'
draft-ietf-sidr-repos-struct-07.txt as a BCP
The IESG plans to make a decision in the next few weeks, and solicits
The IESG has received a request from the Source Address Validation
Improvements WG (savi) to consider the following document:
- 'FCFS SAVI: First-Come First-Serve Source-Address Validation for
Locally Assigned IPv6 Addresses'
draft-ietf-savi-fcfs-09.txt as a Proposed Standard
The IESG plans
The IESG has received a request from the Common Control and Measurement
Plane WG (ccamp) to consider the following document:
- 'Operating Virtual Concatenation (VCAT) and the Link Capacity
Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label
Switching (GMPLS)'
13 matches
Mail list logo
