On 11/20/13, 2:43 PM, Stephen Farrell wrote:
>
>
> On 11/20/2013 10:41 PM, Brian E Carpenter wrote:
>> Just do it.
>
> I wish:-)
>
>> However, I am concerned by the 'bad actor' phrase. The problem is
>> that it's fine as explained in the draft, but it's highly likely to
>> be quoted out of context and thereby cause confusion. It would be
>> safer to use a neutral term ('observer'? 'surveyor'?).
>
> Fair point, and "bad-actor" doesn't fit that well anyway. Will
> find a better term or gladly take suggestions.a surveillor and a surveyor are rather different things. > > S. > >> >> Regards >> Brian >> >> On 21/11/2013 11:16, Stephen Farrell wrote: >>> Hi all, >>> >>> Following up on item 3a from the status/plan mail [1] I sent >>> last week, Hannes and myself have written up an I-D [2] that >>> tries to capture the consensus in the room from the Vancouver >>> tech plenary and we're proposing as a BCP. >>> >>> We're deliberately trying to keep this short and sweet and to >>> not (yet) go beyond what was the gist of the hums - we think >>> progressing e.g. the threat model or the privacy BCP or other >>> bits of related work is liable to take longer and there's value >>> in documenting that the IETF as a whole has consensus on the >>> most significant bit first so those and other bits of work >>> don't all have to re-establish that as they are processed. >>> Hopefully we can all easily agree that that's a useful target >>> and focus comments on whether on not we've expressed that >>> consensus well or not. >>> >>> <boring-bit> >>> We've been bouncing versions of this around amongst the IESG >>> and IAB for the last week, and process-wise, that has been >>> fun already. As you'll see from section 3 of the draft, we can >>> no longer just shoot out an RFC agreed by the IESG and IAB so >>> the plan for this is that when Hannes and I figure this looks >>> ready, based on your comments, then we'll ask Jari to start a >>> 4-week IETF LC for it. When he thinks that's ok he'll start it >>> and then we'll see how that goes. Assuming that goes well, then >>> sometime during IESG evaluation the IAB will decide if they >>> like the final text (or not, which'd be "interesting") and if >>> they do then an IAB note saying "yep, we like it" will be added >>> sometime during/after IESG evaluation before this goes to the >>> RFC editor. In an ideal world, you'll all love the -00 already >>> and tell us that and we'll be done with all of the above super >>> duper process stuff by the end of the year. (Haven't we built >>> ourselves a lovely crazy process? ;-) >>> >>> I really hope we don't end up with a process debate over this, >>> since the above, silly and all as it is, should achieve the >>> desirable outcome which is a simple BCP, approved by the IESG >>> after an IETF LC and also supported by the IAB. The value in >>> that is that it seems to be as close as we can get to the same >>> setup as RFCs 1984 and 2804 which is the right kind of heritage >>> for this one. So there is a reasonably good reason for the >>> process-crap. >>> </boring-bit> >>> >>> Anyway, ignoring process, comments on this are welcome, so >>> please take a read of the two pages of content and let us know >>> what you think. If you do think its already good enough for >>> starting an IETF last call, then saying that is useful as well. >>> >>> And since the IETF LC will happen on the [email protected] list, >>> using this list for initial processing should be fine. >>> >>> Cheers, >>> S. >>> >>> [1] http://www.ietf.org/mail-archive/web/perpass/current/msg01016.html >>> [2] http://tools.ietf.org/html/draft-farrell-perpass-attack >>> _______________________________________________ >>> perpass mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/perpass >>> >> _______________________________________________ >> perpass mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/perpass >> >> > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
