Re: [perpass] "Its an attack" BCP draft

[joel jaeggli <[e-mail]>]

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 [e-mail] 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/perpass
>>>
>> _______________________________________________
>> perpass mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/perpass
>>
>>
> _______________________________________________
> perpass mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/perpass
>