Subject: [sidr] Consensus calls

From: Sandra Murphy <[email-masked]>
Date: Wed, 12 May 2010 17:14:58 -0400 (Eastern Daylight Time)

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-masked]>
To: Sandra Murphy <[email-masked]>, Chris Morrow <[email-masked]>
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.

---

From: Stephen Kent <[email-masked]>
Date: Sun, 16 May 2010 11:47:58 -0400

At 5:14 PM -0400 5/12/10, Sandra Murphy wrote:
>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.
>
>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.
>
>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
>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).

The discussion of partial deployment scenarios will take some time to 
resolve, so I vote for deferring this (important) discussion to 
another document.

>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.
>

I think it best to remove the cautionary text from the ROA doc, and 
leave it in the arch doc.

Steve