Subject: [Mobopts] Randomness from Wi-Fi background noise

From: Pars Mutaf <[email-masked]>
Date: Fri, 03 Mar 2006 17:15:32 +0100

Hi folks, 

This is slightly off topic but I know 
that some people on list would be interested.
A while ago I wrote a C code for generating 
true random numbers from Wi-Fi 
background noise  :-D

For the theory of operation and C code click: 

http://www.freewebs.com/pmutaf/iwrandom.html

Enjoy! 

pars

ps: In fact, honestly, I'm interested in 
your Wi-Fi material. If you test the code
PLEASE return feedback (vendor name, driver)
to [email-masked]

ps2: hey this is not completely off topic!
true random numbers are needed for Optimistic 
DAD ;-)

_______________________________________________
Mobopts mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mobopts

---

From: "James Kempf" <[email-masked]>
Date: Wed, 8 Mar 2006 13:32:01 -0800

What is the IRSG?

            jak

----- Original Message ----- 
From: "Rajeev Koodli" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, February 22, 2006 5:09 PM
Subject: [Mobopts] New IRTF process for RG RFCs

>
> Folks,
>
> after considerable deliberation, we have a new process which I believe 
> will bring a much-needed formal peer review process for RG documents. I 
> feel this is very good for us, personally having brought it up many a time 
> earlier, including during the IAB review of MobOpts in Paris. So, I am 
> looking forward to it.
>
> Please see the process description below. I hope it is encouraging to all!
>
> Regards,
>
> -Rajeev
>
> ps: to begin with, I will act as the shepherd (see below).
>
> ...............................................................
>
> - An RG decides to publish a document using the IRTF publication
>     track. The RG performs a review for editorial and technical
>     content.  The document should have a statement in the abstract
>     identifying the document as the product of the RG and a paragraph
>     in the first section describing the level of support for the
>     document (e.g., "this document represents the consensus of the
>     FOOBAR RG", "the views in this document were considered
>     controversial by the FOOBAR RG but the RG reached a consensus that
>     the document should still be published") and the breadth of review
>     for the document.  I.e., was this document read by all the active
>     contributors, 3 people, or folks who are not "in" the RG but are
>     expert in the area?  It should also be very clear throughout the
>     document that it is not an IETF product and is not a standard.  If
>     an experimental protocol is described appropriate caveats need to
>     be present.
>
>   - Documents should have a shepherd.  This is a relatively new
>     concept developed in the IETF to ensure that issues raised in the
>     review and publication process (e.g., by the IESG and RFC Editor)
>     are responded to in a timely manner.  The IETF shepherding process
>     is described in draft-ietf-proto-wgchair-doc-shepherding-05.txt
>     and should be adapted to the IRTF publication process as some
>     items in the draft will not apply.
>
>   - The sponsoring RG chair brings the document to the IRSG for
>     publication.  The expectation is that the RG chair has already
>     reviewed the draft thoroughly and considers it of publishable
>     quality editorially and technically.  The RG should be copied on
>     the mail message requesting IRSG review.
>
>   - A (firm) eight-week IRSG review period follows after which a poll
>     is taken.  Reviews should be similar to that for a conference
>     paper.  Votes can be:
>
>     = 'ready to publish' -- requires a thorough read and reasonably
>       detailed review
>
>     = 'not ready to publish' -- requires a thorough read, reasonably
>        detailed review, and actionable comments.
>
>     = 'no objection' -- I don't object if this document goes forward;
>       I've read the document (perhaps quickly); I have some small
>       comments which are not show stoppers; I don't have great
>       expertise in the area.
>
>     = 'request more time to review' -- a commitment to to provide a
>       thorough review in a specified period of time.
>
>     Reviews should be written to be public.  In particular, they
>     should be sent to the submitted RG mailing list.  (We may need a
>     tracker of some sort to collect reviews.)
>
>     At least two other IRSG members (besides the one sponsoring the
>     document) need to vote 'ready to publish' for the document to move
>     forward.  Any vote of 'not ready to publish' will hold a documents
>     progress until the comments are addressed.  The IRTF chair may
>     choose to override 'not ready to publish' holds that, in the
>     opinion of the chair, have received an adequate response.
>
>   - The document is submitted to the RFC Editor who does not perform
>     an ISR review.  The RFC Editor sends it to the IESG for an RFC3932
>     review.  There are several reasons why the IESG may block a
>     document, described in RFC3932 section 4.  (The document shepherd
>     should be responsible for checking the IETF datatracker for IESG
>     blocking and non-blocking comments and forward them to the RG.)
>
>   - Rather than the disclaimers found in RFC3932, the IESG will
>     instruct the RFC Editor to add the following disclaimer:
>
>       "This RFC is a product of the Internet Research Task Force and
>       is not a candidate for any level of Internet Standard.  The IRTF
>       publishes the results of Internet-related research and
>       development activities.  These results may not be suitable for
>       deployment."
>
>     For documents that specify a protocol or other technology, and
>     that have been considered in the IETF at one time:
>
>       "This RFC is a product of the Internet Research Task Force.  The
>       content of this RFC was at one time considered by the IETF, and
>       therefore it may resemble a current IETF work in progress or a
>       published IETF work.  However, this is not an IETF document is
>       not a candidate for any level of Internet Standard.  The IRTF
>       publishes the results of Internet-related research and
>       development activities.  These results may not be suitable for
>       deployment."
>
>    (These disclaimers will require approval by the IESG.)
>
>
>

---

From: Greg Daley <[email-masked]>
Date: Thu, 09 Mar 2006 16:35:13 -0500

Hi James,

> What is the IRSG?

IRSG := Internet Research Steering Group

The IRSG is the set of IRTF WG chairs
plus the IRTF Chair.

This is described on http://www.irtf.org/

Greg