[hiprg] HIPRG document process

"Henderson, Thomas R" <thomas.r.henderson@boeing.com> Tue, 01 December 2009 18:14 UTC

Return-Path: <thomas.r.henderson@boeing.com>
X-Original-To: hiprg@core3.amsl.com
Delivered-To: hiprg@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id B8D2C3A6910 for <hiprg@core3.amsl.com>; Tue, 1 Dec 2009 10:14:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 4Ezq9Klxeu8J; Tue, 1 Dec 2009 10:14:40 -0800 (PST)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com []) by core3.amsl.com (Postfix) with ESMTP id 4999C3A6899; Tue, 1 Dec 2009 10:14:40 -0800 (PST)
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com []) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id nB1IENwd004961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Dec 2009 10:14:23 -0800 (PST)
Received: from slb-av-01.boeing.com (localhost []) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id nB1IENU4007540; Tue, 1 Dec 2009 10:14:23 -0800 (PST)
Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com []) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id nB1IEMst007514 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 1 Dec 2009 10:14:23 -0800 (PST)
Received: from XCH-NW-10V.nw.nos.boeing.com ([]) by XCH-NWHT-01.nw.nos.boeing.com ([]) with mapi; Tue, 1 Dec 2009 10:14:21 -0800
From: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
To: "hiprg@irtf.org" <hiprg@irtf.org>
Date: Tue, 01 Dec 2009 10:14:21 -0800
Thread-Topic: HIPRG document process
Thread-Index: AcpkQXHRooFjKig8QQSLMUSJY5sEAgCliACwAUhJQeABqaUXwAAEipeA
Message-ID: <AAF2CBF9D2573B45A7ED75C4FFD9883F4B98098E41@XCH-NW-10V.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--38.908000-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "irtf-chair@irtf.org" <irtf-chair@irtf.org>
Subject: [hiprg] HIPRG document process
X-BeenThere: hiprg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Host Identity Protocol \(HIP\) Research Group" <hiprg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/listinfo/hiprg>, <mailto:hiprg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/hiprg>
List-Post: <mailto:hiprg@irtf.org>
List-Help: <mailto:hiprg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hiprg>, <mailto:hiprg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Dec 2009 18:14:41 -0000

This note proposes a HIP RG process for advancing documents to draft-irtf-hip status.  Andrei and I have discussed formulating such a process for the past month or two, and have also raised the issue for discussion within the Internet Research Steering Group (IRSG).  Below is a policy that seems appropriate for our research group.

The purpose of advancing an independent submission to draft-irtf-hip status is to reflect that the HIP research group desires to work towards publishing the document as an IRTF-track RFC (http://www.ietf.org/id/draft-irtf-rfcs-05.txt).  It may also be the case that the document is later transferred to the HIP working group in the IETF if the HIP working group wants to adopt it.

The criteria for advancing an individual submission are:
1) the draft represents the consensus of the HIP research group, or even if the draft is not a consensus position, the HIP research group reached consensus that it should be published as a product of the RG
2) the document either already conforms to the guidelines posted at http://trac.tools.ietf.org/group/irtf/trac/wiki/IRTF-RFCs, or there is a commitment from the authors to bring the draft into alignment
3) technical reviewers (non-authors) are identified

All drafts presented or posted for discussion on the HIP RG mailing list will be tracked on the wiki.  Anyone may propose (on the mailing list) a draft to be advanced to research group status, at which time the chairs will ask on the mailing list whether there is support. There must be some level of positive acknowledgment by non-authors to help review and improve the document to take this action.  If the chairs believe that the criteria are met, the draft can be advanced to research group status.  Authors may be asked to resolve comments or concerns and come back to the list with a revised draft at a later time.

Once the document reaches IRSG state, a document shepherd will be appointed (typically one of the RG chairs):
The document shepherd will work with the authors to advance the document to the state at which it is ready for IRSG review:  http://trac.tools.ietf.org/group/irtf/trac/wiki/IRTF-RFCs#IRSGReview.
While the RG will not officially have a "document shepherd" during the RG preparation stage, the technical reviewers reviewing this draft for the RG can look to the criteria in the above process in guiding their comments.

Not all HIP RG drafts will advance to IRSG review; some may migrate to the HIP WG, while some may never reach readiness for either state.  To keep things moving along, draft status will be reviewed at the beginning of each research group meeting.  Open issues may be tracked on the wiki or in an issue tracker.  If a draft languishes (no progress on open issues) after being identified as a research group draft, it may be taken off the list of research group drafts at a future date.

Below is a list of the drafts that have been discussed during the past year (aside from those that have been introduced to the RG for informational purposes such as RANGI and shim6 API) that we will add to the tracker.

1) Object naming with HIP
2) HIP for RF-ID
3) HIP and the IoT
4) HIP and user authentication
5) HI revocation
6) Hierarchical HI
8) DNS Locators
9) HIP DHT interface
10) HIP services
11) HIP middleboxes
14) Mobile router
15) HIP Proxy (Melen, Ylitalo, Salmela)
16) HIP proxies (Zhang, Xu, Yao)

Of the above, we believe that the topics of HIP for Internet of Things, HI revocation, HIP
DHT interface, and proxies each probably meet the criteria for level of interest, although
in two cases (IoT and proxies) there are multiple contributions and we should try to chart
out a process to end up with RG-level drafts.   It may be that others are ready to move
forward at this time; please let us know your thoughts.

Please send your comments on the proposed process to the list, or let us know if we are missing any drafts above.

- Tom and Andrei