|            | 
  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
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
        NONE 
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
        NONE 
3.3.2 Returning Item
        NONE 
 |   
 |