Sorry not to be clear.
In the absence of consensus in the wg, Matt gets to make the choice.
Clearer?
--Sandy, speaking as wg chair
On Tue, 15 Jun 2010, Geoff Huston wrote:
Wg Chair:
That would be fine if the note you quoted included a choice of direction. I see
no such choice, and instead I see the careful use of a neutral stance on the
part of the note's author. So what exactly is the guidance being given here?
Geoff
On 15/06/2010, at 3:25 AM, Sandra Murphy wrote:
There has been too little discussion of this to say that there is any consensus
of the wg.
So Matt's choice of direction stands.
--Sandy, speaking as wg chair
On Wed, 12 May 2010, Sandra Murphy wrote:
Matt Lepinski requested that the wg chairs judge consensus on the following
topics. Both topics were discussed in the sidr IETF 77 meeting, but consensus
was not clear at the time.
Please send your thoughts on the following to the list so that the wg chairs
can give guidance on the drafts to the author.
--Sandy, speaking as wg chair
---------- Forwarded message ----------
From: Matt Lepinski <[email protected]>
To: Sandra Murphy <[email protected]>, Chris Morrow <[email protected]>
Subject: Request to Chairs for Concensus Calls
There are two issues which I brought up at the meeting, for which I would like
to determine if the working group has achieved concensus.
First [arch]: Scope of the architecture document. Following two choices:
A) The architecture document covers only the RPKI with no discussion of
applications. It describes behaivor for entities that want to be a part of the
RPKI, but is silent on how relying parties use this data
(this requires only minor revisions to the current document)
B) The architecture document expands to include some discussion of origin
validation in a partial deployment setting
(this requires more significant changes to the current document, and will
create a normative dependency on roa-validation)
At the meeting we heard views on both sides. I believe that Sam was the only
vocal proponent of (B). I believe that Rob A, Geoff, Danny and Ruediger were
proponents of (A).
Second [roa-format]: Cautionary text in the document
A) I put some "make-before-break" cautionary text in the security
considerations of the ROA Format document. (Similar text will remain in the architecture
documnet ... and could potentially be put in other places as well.)
B) The ROA Format document is the wrong place for such text, since ROA format only talks
about things within the ROA wrapper ... and the "make-before-break" issue is
actually larger since it applies not just to ROAs but also to resource certificates
higher up the chain.
Note: The cautionary text will stay in architecture regardless (and indeed I
think I can even improve that text in light of the discussions at the meeting).
It's possible that such warning text could [additionally] be reasonably put in
the security considerations of ROA-Validation and/or Rescert profile.
I heard a lot of opinions during the meeting. However, I'm not convinced that
anyone feels strongly enough about this issue to justify holding up this
document for prolonged discussion.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
