On 20/11/13 22:54, joel jaeggli wrote:
a surveillor and a surveyor are rather different things.
s/surveillor/surveillant/ ?
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
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
