Gen-ART Review Assignments for 28 Aug 2008

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


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
RTGA Link-Type sub-TLV to convey the number of Traffic Engineering Label Switched Paths signalled with zero reserved bandwidth across a link (Proposed Standard) - 1 of 1
draft-ietf-mpls-number-0-bw-te-lsps-11.txt [Open Web Ballot]
  Token: Ross Callon
  Reviewer: Ben Campbell (reviewed -09 for LC)
   
2.1.2 Returning Item
      NONE
2.1.3 For Action
      AreaDate
OPSSimple Network Management Protocol (SNMP) Context EngineID Discovery (Proposed Standard) - 1 of 1
draft-ietf-opsawg-snmp-engineid-discovery-03.txt [Open Web Ballot]
  Token: Dan Romascanu
  Reviewer: Brian Carpenter (already reviewed)
   

2.2 Individual Submissions

          2.2.1 New Item
      AreaDate
SECExtensions to the IODEF-Document Class for Reporting Phishing, Fraud, and Other Crimeware (Proposed Standard) - 1 of 1
draft-cain-post-inch-phishingextns-05.txt [Open Web Ballot]
  Token: Tim Polk
  Reviewer: Brian Carpenter (already reviewed)
   
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
INTWhy Authentication Data suboption is needed for MIP6 (Informational) - 1 of 1
draft-ietf-mip6-whyauthdataoption-06.txt [Open Web Ballot]
Note: No document shepherd -- old MIP6 document
  Token: Jari Arkko
  Reviewer: Eric Gray (assigned LC due 7/30)
   
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
GENDynamic Provisioning using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) (Informational) - 1 of 2
draft-cam-winget-eap-fast-provisioning-09.txt [Open Web Ballot]
Token: Tim Polk
  Reviewer:Vijay Gurbani (already reviewed)
    
OPSDiameter ITU-T Rw Policy Enforcement Interface Application (Informational) - 2 of 2
draft-sun-dime-itu-t-rw-01.txt [Open Web Ballot]
  Token: Dan Romascanu
  Reviewer: Brian Carpenter (already reviewed for LC)
   
3.2.2 Returning Item
      NONE

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
      AreaDate
OPSSNMP Traffic Measurements and Trace Exchange Formats (Informational) - 1 of 1
draft-irtf-nmrg-snmp-measure-05.txt [Open Web Ballot]
Note: Proposed IESG Note:

The IESG thinks that this work is related to IETF work done in the Operations and Management Area related to SNMP, but this does not prevent publishing.

This RFC is not a candidate for any level of Internet Standard.
The IETF disclaims any knowledge of the fitness of this RFC for
any purpose and notes that the decision to publish is not based on
IETF review apart from the IETF Last Call on the allocation of an URI by IANA and the IESG review for conflict with IETF work.
The RFC Editor has chosen to publish this document at its
discretion.  See RFC 3932 for more information.

Token: Dan Romascanu
3.3.2 Returning Item
      NONE