Gen-ART Review Assignments for 22 May 2008

Good approximation of what will be included in the Agenda of next Telechat (2008-05-22).



2. Protocol Actions

Reviews should focus on these questions: "Is this document a
reasonable basis on which to build the salient part of the Internet
infrastructure? If not, what changes would make it so?"
         

2.1 WG Submissions

          2.1.1 New Item
      AreaDate
GENTwo-Document ballot: [Open Web Ballot] - 1 of 8
Rights Contributors provide to the IETF Trust (BCP) - 1 of 8
draft-ietf-ipr-3978-incoming-09.txt
Advice to the Trustees of the IETF Trust on Rights to be Granted in IETF Documents (Informational)
draft-ietf-ipr-outbound-rights-06.txt
Token: Russ Housley
SECMultiple Signatures in S/MIME (Proposed Standard) - 2 of 8
draft-ietf-smime-multisig-05.txt [Open Web Ballot]
Token: Tim Polk
  Reviewer:Elwyn Davies (reviewed -04 for LC)
    
RTGMPLS Multicast Encapsulations (Proposed Standard) - 3 of 8
draft-ietf-mpls-multicast-encaps-09.txt [Open Web Ballot]
Token: Ross Callon
  Reviewer:Vijay Gurbani  (already reviewed)
    
SECSpecification for the Derivation of Root Keys from an Extended Master Session Key (EMSK) (Proposed Standard) - 4 of 8
draft-ietf-hokey-emsk-hierarchy-05.txt [Open Web Ballot]
Note: proto shepherd is Charles Clancy
Token: Tim Polk
  Reviewer:Joel Halpern (reviewed -04 for LC)
    
RTGPath Computation Element (PCE) Communication Protocol (PCEP) (Proposed Standard) - 5 of 8
draft-ietf-pce-pcep-12.txt
Token: Ross Callon
  Reviewer:Eric Gray (assigned LC)
    
RTGLDP extension for Inter-Area LSP (Proposed Standard) - 6 of 8
draft-ietf-mpls-ldp-interarea-03.txt [Open Web Ballot]
Token: Ross Callon
  Reviewer:Suresh Krishnan (already reviewed)
    
RTGA Backward Recursive PCE-based Computation (BRPC) Procedure To Compute Shortest Constrained Inter-domain Traffic Engineering Label Switched Paths (Proposed Standard) - 7 of 8
draft-ietf-pce-brpc-09.txt
Token: Ross Callon
  Reviewer:Christian Vogt (assigned LC)
    
TSVResource ReSerVation Protovol (RSVP) Extensions for Emergency Services (Proposed Standard) - 8 of 8
draft-ietf-tsvwg-emergency-rsvp-08.txt [Open Web Ballot]
  Token: Magnus Westerlund
  Reviewer: Joel Halpern (reviewed -07 for LC)
   
2.1.2 Returning Item
      NONE

2.2 Individual Submissions

          2.2.1 New Item
      AreaDate
APPInternet Message Format (Draft Standard) - 1 of 1
draft-resnick-2822upd-06.txt [Open Web Ballot]
  Token: Lisa Dusseault
  Reviewer: Francis Dupont (already reviewed for LC)
   
2.2.2 Returning Item
      NONE

3. Document Actions

         

3.1 WG Submissions

Reviews should focus on these questions: "Is this document a reasonable
contribution to the area of Internet engineering which it covers? If
not, what changes would make it so?"
          3.1.1 New Item
      AreaDate
OPSIPv6 Unicast Address Assignment Considerations (Informational) - 1 of 1
draft-ietf-v6ops-addcon-07.txt [Open Web Ballot]
  Token: Ron Bonica
  Reviewer: Elwyn Davies (already reviewed)
   
3.1.2 Returning Item
      NONE

3.2 Individual Submissions Via AD

Reviews should focus on these questions: "Is this document a reasonable
contribution to the area of Internet engineering which it covers? If
not, what changes would make it so?"
          3.2.1 New Item
      AreaDate
APPAtom Bidirectional Attribute (Experimental) - 1 of 1
draft-snell-atompub-bidi-06.txt [Open Web Ballot]
  Token: Lisa Dusseault
  Reviewer: Francis Dupont (already reviewed for LC)
   
3.2.2 Returning Item
      AreaDate
INTSAVA Testbed and Experiences to Date (Experimental) - 1 of 1
draft-wu-sava-testbed-experience-05.txt [Open Web Ballot]
  Token: Jari Arkko
  Reviewer: Eric Gray (assigned -04 for LC)
   

3.3 Independent Submissions Via RFC Editor

The IESG will use RFC 3932 responses: 1) The IESG has not
found any conflict between this document and IETF work; 2) The
IESG thinks that this work is related to IETF work done in WG
<X>, but this does not prevent publishing; 3) The IESG thinks
that publication is harmful to work in WG <X> and recommends
not publishing at this time; 4) The IESG thinks that this
document violates the IETF procedures for <X> and should
therefore not be published without IETF review and IESG
approval; 5) The IESG thinks that this document extends an
IETF protocol in a way that requires IETF review and should
therefore not be published without IETF review and IESG approval.

The document shepherd must propose one of these responses in
the Data Tracker note and supply complete text in the IESG
Note portion of the write-up. The Area Director ballot positions
indicate consensus with the response proposed by the
document shepherd.

Other matters may be recorded in comments, and the comments will
be passed on to the RFC Editor as community review of the document.
          3.3.1 New Item
      NONE
3.3.2 Returning Item
      NONE