Subject: [Hipsec-rg] IRSG review of draft-irtf-hiprg-nat-01.txt
From: [email-masked] (Lars Eggert)
Date: Mon Feb 27 12:17:00 2006

--Apple-Mail-11--455332256
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Hi, Tom,

On Feb 24, 2006, at 21:27, Henderson, Thomas R wrote:
>
> We have volunteered draft-irtf-hiprg-nat-01.txt as one of the first of
> three IRTF documents to undergo this process.  I have agreed to  
> serve as
> shepherd of this document.  Aaron is now soliciting two IRSG  
> volunteers
> to review this draft's readiness to publish.  Upon agreement or
> successful comment resolution, the following disclaimer will be added:
>        "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."
> and the document will enter the RFC editor's queue at the same  
> priority
> as an IETF WG draft.

great, thanks!

Aaron, I have one suggestion on the process described below; overall,  
it's IMO very sensible.

> As you assuredly know, RG drafts are treated like independent
> submissions by the RFC Editor.  Some members of the community are
> dissatisfied with the process which includes the following steps:
>
>    - The RFC Editor performs independent submission review (ISR) for
>      editorial acceptability and may request the authors revise the
>      document before publishing.
>
>    - The IESG performs a review (to avoid standards process
>      end-arounds) and inserts a disclaimer (see RFC3932).
>
>    - Independent submissions are delayed by lower priority  
> treatment as
>      they move through the RFC Editor's queue.
>
> As I see it, there are three aspects of RG document publication that
> are on the table:
>
>    - ISR review
>    - RFC publication priority
>    - the RFC3932 blurb
>
> Here is my proposal:
>
> I propose we use the process for IETF-sponsored individual submissions
> (sometimes called AD-sponsored individual submissions) as a model for
> IRTF document handling.  From time to time, individuals will approach
> a member of the IESG to publish a document that is not the product of
> an IETF working group.  These documents do not receive RFC3932
> disclaimers, do not receive low priority treatment by the RFC Editor,
> and do not experience ISR review.  However, they do receive a thorough
> review by the IESG.  For non-standards documents (yes, there are rare
> cases of non-wg standards documents), the sponsoring AD gives the
> document a thorough review, sometimes requiring expert reviews or
> IETF-wide last calls, if the topic seems to warrant broad review.  The
> bottom line is that a set of experienced, responsible folks give the
> document a thorough review before publishing it as an "IETF product".
>
> Using this as a model, I suggest we adapt this process to the IRTF as
> follows.  The RFC Editor has reviewed the procedure below and fully
> supports it.
>
>    - 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.

If the IRSG takes on a more executive role, I think the members need  
to be identified a bit more explicitly. The IRTF web site just says  
"IRSG membership includes the IRTF Chair, the chairs of the various  
Research Group and possibly other individuals ("members at large")  
from the research community."

While I can click through the RGs to find the chairs, that doesn't  
tell me if there are currently any "members at large". Something  
equivalent to http://www.ietf.org/IESGmems.html may be good.

>    - 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.)
>
>    - The document enters the RFC Editor queue at the same priority as
>      IETF documents.
>
> _______________________________________________
> Hipsec-rg mailing list
> [email-masked]
> http://honor.cybertrust.com/mailman/listinfo/hipsec-rg

Lars
-- 
Lars Eggert                                     NEC Network Laboratories

--Apple-Mail-11--455332256
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

--Apple-Mail-11--455332256--

From: [email-masked] (Henderson, Thomas R)
Date: Fri Feb 24 15:27:00 2006
Subject: [Hipsec-rg] IRSG review of draft-irtf-hiprg-nat-01.txt
Message-ID: <[email-masked]>

All,
Aaron Falk has initiated a new process to handle IRTF documents.  I've
attached the details below, which will be published someday in an
internet draft.

We have volunteered draft-irtf-hiprg-nat-01.txt as one of the first of
three IRTF documents to undergo this process.  I have agreed to serve as
shepherd of this document.  Aaron is now soliciting two IRSG volunteers
to review this draft's readiness to publish.  Upon agreement or
successful comment resolution, the following disclaimer will be added:
       "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."
and the document will enter the RFC editor's queue at the same priority
as an IETF WG draft.

>From the RG perspective, I don't think anything needs to be done at this
time-- the results of this process will be discussed on the list, and
the RG has already agreed to the following statement at the end of the
Introduction:
   "This memo was discussed and modified in the Host Identity Protocol
   Research Group and represents a consensus view of the research group
   at the time of its submission for publication."

Tom

Below is Aaron Falk's proposal
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

As you assuredly know, RG drafts are treated like independent
submissions by the RFC Editor.  Some members of the community are
dissatisfied with the process which includes the following steps:

   - The RFC Editor performs independent submission review (ISR) for
     editorial acceptability and may request the authors revise the
     document before publishing.

   - The IESG performs a review (to avoid standards process
     end-arounds) and inserts a disclaimer (see RFC3932).

   - Independent submissions are delayed by lower priority treatment as
     they move through the RFC Editor's queue.

As I see it, there are three aspects of RG document publication that
are on the table:

   - ISR review
   - RFC publication priority
   - the RFC3932 blurb

Here is my proposal:

I propose we use the process for IETF-sponsored individual submissions
(sometimes called AD-sponsored individual submissions) as a model for
IRTF document handling.  From time to time, individuals will approach
a member of the IESG to publish a document that is not the product of
an IETF working group.  These documents do not receive RFC3932
disclaimers, do not receive low priority treatment by the RFC Editor,
and do not experience ISR review.  However, they do receive a thorough
review by the IESG.  For non-standards documents (yes, there are rare
cases of non-wg standards documents), the sponsoring AD gives the
document a thorough review, sometimes requiring expert reviews or
IETF-wide last calls, if the topic seems to warrant broad review.  The
bottom line is that a set of experienced, responsible folks give the
document a thorough review before publishing it as an "IETF product".

Using this as a model, I suggest we adapt this process to the IRTF as
follows.  The RFC Editor has reviewed the procedure below and fully
supports it.

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

     =3D 'ready to publish' -- requires a thorough read and reasonably
       detailed review

     =3D 'not ready to publish' -- requires a thorough read, reasonably
        detailed review, and actionable comments.

     =3D '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.

     =3D '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.)

   - The document enters the RFC Editor queue at the same priority as
     IETF documents.

From: [email-masked] (Henderson, Thomas R)
Date: Tue Feb 21 13:17:00 2006
Subject: [Hipsec-rg] OpenHIP question
Message-ID: <[email-masked]>

Fernando, thanks for your comments-- some responses inline below:

> 	From: Fernando Pedro Moreira [mailto:[email-masked]]=20
> 	Sent: Tuesday, February 21, 2006 9:40 AM
> 	To: [email-masked]
> 	Subject: [Hipsec-rg] OpenHIP question
> =09
> =09
> 	I just installed OpenHIP 0.3.2 on Linux, following all=20
> the instructions in the wiki. I chose to build it from =20
> source with kernel patch.  It took some time but i was=20
> finally able to get to the part where i could  test  it.=20
> 	When prompted to run hip on win32/ dir i found that i=20
> hadn't compiled it yet so hip wasn't there to run. When i=20
> tried do compile it, at first i got some thread errors,=20
> which, after correction by altering the Makefile, where solved.
> 	Then, trying to compile again i got a lot of debug=20
> info, which started with:
> =09
> 	>> Building user-mode HIP...
> =09
> 	After using the kernel mode installation do iI need a=20
> daemon running?

It seems that you may be mixing the user mode and kernel mode
installation processes.  Please follow these instructions (i.e., you
should not have to do anything in the win32/ directory if you are
running in kernel mode).
http://www.openhip.org/wiki/index.php?title=3DBuilding_from_source_on_Lin=
u
x_with_kernel_patch

> =09
> 	Also, i find it weird that i would run/compile hip from=20
> a win32/ named dir.
> 	I'm i doing everything ok?

The use of a win32/ directory for user-mode Linux HIP derives from the
fact that we first did a user-mode implementation for Windows XP, and
later ported to Linux.  We plan to revisit this directory structure for
our next release.  But again, you shouldn't have to use that directory
to use kernel-mode HIP.

> =09
> 	If any more info is necessary, i'll post it if you need=20
> it to find the problem... just didn't want to flood this.

Feel free to follow-up directly with us if you want.

Thanks,
Tom

From: [email-masked] (Fernando Pedro Moreira)
Date: Tue Feb 21 12:40:00 2006
Subject: [Hipsec-rg] OpenHIP question
Message-ID: <[email-masked]>

------=_Part_3730_3939586.1140543582849
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I just installed OpenHIP 0.3.2 on Linux, following all the instructions in
the wiki. I chose to build it from  source with kernel patch.  It took some
time but i was finally able to get to the part where i could  test  it.
When prompted to run hip on win32/ dir i found that i hadn't compiled it ye=
t
so hip wasn't there to run. When i tried do compile it, at first i got some
thread errors, which, after correction by altering the Makefile, where
solved.
Then, trying to compile again i got a lot of debug info, which started with=
:

>> Building user-mode HIP...

After using the kernel mode installation do iI need a daemon running?

Also, i find it weird that i would run/compile hip from a win32/ named dir.
I'm i doing everything ok?

If any more info is necessary, i'll post it if you need it to find the
problem... just didn't want to flood this.

Thank you for your help.

F. Moreira
<http://www.openhip.org/wiki/index.php?title=3DInstallation#Building_from_s=
ource_on_Linux_with_kernel_patch>

------=_Part_3730_3939586.1140543582849
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I just installed OpenHIP 0.3.2 on Linux, following all the instructions
in the wiki. I chose to build it from&nbsp; source with kernel
patch.&nbsp; It took some time but i was finally able to get to the
part where i could&nbsp; test&nbsp; it. <br>
When prompted to run hip on win32/ dir i found that i hadn't compiled
it yet so hip wasn't there to run. When i tried do compile it, at first
i got some thread errors, which, after correction by altering the
Makefile, where solved.<br>
Then, trying to compile again i got a lot of debug info, which started with=
:<br>
<br>

&gt;&gt; Building user-mode HIP...<br>
<br>
After using the kernel mode installation do iI need a daemon running?<br>
<br>
Also, i find it weird that i would run/compile hip from a win32/ named dir.=
<br>
I'm i doing everything ok?<br>
<br>
If any more info is necessary, i'll post it if you need it to find the prob=
lem... just didn't want to flood this.<br>
<br>
Thank you for your help.<br>
<br>
F. Moreira<br>
<a href=3D"http://www.openhip.org/wiki/index.php?title=3DInstallation#Build=
ing_from_source_on_Linux_with_kernel_patch"><span class=3D"toctext"></span>=
</a>

------=_Part_3730_3939586.1140543582849--

From: [email-masked] (Aaron Falk)
Date: Fri Feb 10 12:32:01 2006
Subject: [Hipsec-rg] Re: HIP RG wiki
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-4-224557048
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

OK.  Done.

--aaron

On Feb 10, 2006, at 9:24 AM, Henderson, Thomas R wrote:

> Yes, that is the intention.
>
> Thanks,
> Tom
>
>> -----Original Message-----
>> From: Aaron Falk [mailto:[email-masked]]
>> Sent: Friday, February 10, 2006 9:12 AM
>> To: Henderson, Thomas R
>> Cc: [email-masked]
>> Subject: Re: HIP RG wiki
>>
>> Tom-
>>
>> The meeting information on the other HIP RG page (http://
>> hiprg.piuha.net/) is out of date.  Would you like to change
>> the URL on the charter page to point to the wiki?
>>
>> --aaron
>>

--Apple-Mail-4-224557048
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-4-224557048--

From: [email-masked] (Henderson, Thomas R)
Date: Fri Feb 10 12:20:00 2006
Subject: [Hipsec-rg] RE: HIP RG wiki
Message-ID: <[email-masked]>

Yes, that is the intention.

Thanks,
Tom=20

> -----Original Message-----
> From: Aaron Falk [mailto:[email-masked]]=20
> Sent: Friday, February 10, 2006 9:12 AM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: Re: HIP RG wiki
>=20
> Tom-
>=20
> The meeting information on the other HIP RG page (http://
> hiprg.piuha.net/) is out of date.  Would you like to change=20
> the URL on the charter page to point to the wiki?
>=20
> --aaron
>

From: [email-masked] (Aaron Falk)
Date: Fri Feb 10 12:08:00 2006
Subject: [Hipsec-rg] Re: HIP RG wiki
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-3-223061565
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

Tom-

The meeting information on the other HIP RG page (http:// 
hiprg.piuha.net/) is out of date.  Would you like to change the URL  
on the charter page to point to the wiki?

--aaron

On Feb 2, 2006, at 10:15 AM, Henderson, Thomas R wrote:

> I've established a wiki for our research group.  This is intended to
> serve as the supplementary page for our group (replacing
> http://hiprg.piuha.net/).
>
> The wiki uses MediaWiki software.  Anyone can add to or edit the pages
> (it is configured to require users to establish an account and  
> login to
> edit pages).
>
> I'm hoping that people will contribute links relevant to our work and
> build this site up as a good reference site (at the very least, a
> comprehensive research bibliography related to HIP and ID/Locator  
> split
> research).  I've added some initial structure and content to the wiki,
> but more work remains.  Please add a link to papers you've written  
> about
> HIP or other references you may know about.
>
> wiki url:
> http://www.openhip.org/irtf/wiki/
>
> RSS feed for the "Recent changes" page:
> http://www.openhip.org/irtf/wiki/index.php? 
> title=Special:Recentchanges&f
> eed=rss
>
> -Tom

--Apple-Mail-3-223061565
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-3-223061565--

From: [email-masked] (Ahrenholz, Jeffrey M)
Date: Tue Feb  7 15:40:00 2006
Subject: [Hipsec-rg] new OpenHIP code snapshot
Message-ID: <[email-masked]>

Andrei,
The openhip-0.3.2-install.exe file has now been released. (Notice the =
smaller file size, because we no longer need the Cygwin DLLs.)

-Jeff

> -----Original Message-----
> From: Andrei Gurtov [mailto:[email-masked]]=20
> Sent: Tuesday, February 07, 2006 1:53 AM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: Re: [Hipsec-rg] new OpenHIP code snapshot
>=20
>=20
> Great,
>=20
> Do you plan to provide a Windows installer as well?
>=20
> Andrei
>=20
> Henderson, Thomas R wrote:
>=20
> >We've made available an interim snapshot of our OpenHIP code
> >(hipd-0.3.2.tgz) at http://www.openhip.org.
> >
> >Some features:
> >- version of HIP interoperated from November IETF (no changes)
> >- RVS and registration patch, courtesy of Miriam Esteban of Ambient
> >Networks project
> >- client-side DNS extensions
> >- DHT extensions corresponding to the DHT draft published last August
> >- native Windows support (without Cygwin dependence)
> >
> >Our documentation has been moved to the project wiki:
> >http://www.openhip.org/wiki/
> >
> >We are planning another release around March IETF, including:
> >- OS X support
> >- support for emerging drafts (probably base-05, esp-02, mm-03)
> >- possibly more DNS integration
> >
> >Tom
> >_______________________________________________
> >Hipsec-rg mailing list
> >[email-masked]
> >http://honor.cybertrust.com/mailman/listinfo/hipsec-rg
> > =20
> >
>=20
>=20

From: [email-masked] (Andrei Gurtov)
Date: Tue Feb  7 04:48:02 2006
Subject: [Hipsec-rg] new OpenHIP code snapshot
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_courier-7389-1139305965-0001-2
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Great,

Do you plan to provide a Windows installer as well?

Andrei

Henderson, Thomas R wrote:

>We've made available an interim snapshot of our OpenHIP code
>(hipd-0.3.2.tgz) at http://www.openhip.org.
>
>Some features:
>- version of HIP interoperated from November IETF (no changes)
>- RVS and registration patch, courtesy of Miriam Esteban of Ambient
>Networks project
>- client-side DNS extensions
>- DHT extensions corresponding to the DHT draft published last August
>- native Windows support (without Cygwin dependence)
>
>Our documentation has been moved to the project wiki:
>http://www.openhip.org/wiki/
>
>We are planning another release around March IETF, including:
>- OS X support
>- support for emerging drafts (probably base-05, esp-02, mm-03)
>- possibly more DNS integration
>
>Tom
>_______________________________________________
>Hipsec-rg mailing list
>[email-masked]
>http://honor.cybertrust.com/mailman/listinfo/hipsec-rg
>  
>

--=_courier-7389-1139305965-0001-2
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--=_courier-7389-1139305965-0001-2--

From: [email-masked] (Henderson, Thomas R)
Date: Tue Feb  7 00:19:00 2006
Subject: [Hipsec-rg] new OpenHIP code snapshot
Message-ID: <[email-masked]>

We've made available an interim snapshot of our OpenHIP code
(hipd-0.3.2.tgz) at http://www.openhip.org.

Some features:
- version of HIP interoperated from November IETF (no changes)
- RVS and registration patch, courtesy of Miriam Esteban of Ambient
Networks project
- client-side DNS extensions
- DHT extensions corresponding to the DHT draft published last August
- native Windows support (without Cygwin dependence)

Our documentation has been moved to the project wiki:
http://www.openhip.org/wiki/

We are planning another release around March IETF, including:
- OS X support
- support for emerging drafts (probably base-05, esp-02, mm-03)
- possibly more DNS integration

Tom

From: [email-masked] (Henderson, Thomas R)
Date: Thu Feb  2 13:12:01 2006
Subject: [Hipsec-rg] HIP RG wiki
Message-ID: <[email-masked]>

I've established a wiki for our research group.  This is intended to
serve as the supplementary page for our group (replacing
http://hiprg.piuha.net/).

The wiki uses MediaWiki software.  Anyone can add to or edit the pages
(it is configured to require users to establish an account and login to
edit pages). =20

I'm hoping that people will contribute links relevant to our work and
build this site up as a good reference site (at the very least, a
comprehensive research bibliography related to HIP and ID/Locator split
research).  I've added some initial structure and content to the wiki,
but more work remains.  Please add a link to papers you've written about
HIP or other references you may know about.

wiki url:
http://www.openhip.org/irtf/wiki/

RSS feed for the "Recent changes" page:
http://www.openhip.org/irtf/wiki/index.php?title=3DSpecial:Recentchanges&=
f
eed=3Drss

-Tom