[16NG] Document Shepherd Write-Up for draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-06

[gabriel montenegro <g_e_montenegro at yahoo.com>]

To: Ralph Droms, 16ng WG Advising AD

On behalf of the 16ng WG, I request publication of draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-06 
as Proposed Standard RFC.

As required by RFC 4858, current Document Shepherd Write-Up per  
latest format at http://www.ietf.org/IESG/content/Doc-Writeup.html.

Document Shepherd Write-Up on draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-06:
  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the 
        document and, in particular, does he or she believe this 
        version is ready for forwarding to the IESG for publication? 

Gabriel Montenegro. Yes and yes.

  (1.b) Has the document had adequate review both from key WG members 
        and from key non-WG members? Does the Document Shepherd have 
        any concerns about the depth or breadth of the reviews that 
        have been performed?  

Proper review including WiMAX NWG (Network Working Group) folks in addition to the IETF.
The document's first officially adopted version (draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-00)
appeared on May 28, 2007.
  
Note: This is the so-called "IPv4 CS" document ("IPv6 CS" has already been published as RFC5121).
More info below.
• 1st WG LC feb 25 - mar 10, 2008
• MTU issue of 1500 (versus 1400 in WiMAX).
 • same as in IPv6 CS, but in IPv6 an RA reliably takes care of this
 • however, there is no good mechanism in IPv4.
• Review from NWG/WiMAX was unfavorable due to this issue and other inaccuracies due to much text that 
is not actually related directly to "IP-over-foo" business
• a revised version elided much needless text and provided a simpler flow.
• 14-Jun-09: Addressed feedback with publication of version 06
• 03-Jul-09: 2nd WG LC on version 06 announced from 3 thru 13 Jul 2009 (completed with no further
feedback).
 
  (1.c) Does the Document Shepherd have concerns that the document 
        needs more review from a particular or broader perspective, 
        e.g., security, operational complexity, someone familiar with 
        AAA, internationalization or XML? 

No. The document has received more than enough review. The issue is not lack of 
review but the fact that WiMAX NWG and this document do not say the same thing with respect
to the MTU.

  (1.d) Does the Document Shepherd have any specific concerns or 
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he 
        or she is uncomfortable with certain parts of the document, or 
        has concerns whether there really is a need for it. In any 
        event, if the WG has discussed those issues and has indicated 
        that it still wishes to advance the document, detail those 
        concerns here. Has an IPR disclosure related to this document 
        been filed? If so, please include a reference to the 
        disclosure and summarize the WG discussion and conclusion on 
        this issue. 

Other 16ng document have been adopted by WiMAX NWG and are referred to by their specs:
 - draft-ietf-16ng-ip-over-ethernet-over-802-dot-16 (currently in RFC ed queue)
 - RFC5121 ("IPv6 CS").
However, given that this document deals with the more urgent deployment need to specify IPv4 over 
802.16, WiMAX finalized their specification before a proper IETF response was posible 
(before 16ng). Accordingly, this document is too late for WiMAX to refer to it. Furthermore,
there is a disagreement on the MTU size when using IPv4 CS over 802.16. The MTU in this
document started out at 1500, was moved back to 1400 and then--due to strong
objection within the WG--moved back to 1500. While it is true
that WiMAX does not represent all the 802.16 deployments, it is a significant portion of them.
It is unfortunate that both organizations could not agree, but after trying for a couple of years
it is clear that this is not possible. Accordingly, WiMAX NWG position is not favorable to 
this document as they have already decided on 1400 MTU which they don’t foresee changing in the near 
future. 
Nevertheless, the consensus within the IETF debate is that publishing this document with an MTU of
1500 is important as it is the IETF position.

  (1.e) How solid is the WG consensus behind this document? Does it 
        represent the strong concurrence of a few individuals, with 
        others being silent, or does the WG as a whole understand and 
        agree with it?   

It represents an IETF consensus, even if it does not have full support from WiMAX.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme 
        discontent? If so, please summarise the areas of conflict in 
        separate email messages to the Responsible Area Director. (It 
        should be in a separate email because this questionnaire is 
        entered into the ID Tracker.) 

No appeals threatened.

  (1.g) Has the Document Shepherd personally verified that the 
        document satisfies all ID nits? (See the Internet-Drafts Checklist 
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are 
        not enough; this check needs to be thorough. Has the document 
        met all formal review criteria it needs to, such as the MIB 
        Doctor, media type and URI type reviews? 

One minor nit found:
  == Outdated reference: A later version (-12) exists of
     draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-08
This outdated reference to an informative document will be updated when addressing
IESG comments.

  (1.h) Has the document split its references into normative and 
        informative? Are there normative references to documents that 
        are not ready for advancement or are otherwise in an unclear 
        state? If such normative references exist, what is the 
        strategy for their completion? Are there normative references 
        that are downward references, as described in [RFC3967]? If 
        so, list these downward references to support the Area 
        Director in the Last Call procedure for them [RFC3967]. 

Yes. All normative references are final published documents.

  (1.i) Has the Document Shepherd verified that the document IANA 
        consideration section exists and is consistent with the body 
        of the document? If the document specifies protocol 
        extensions, are reservations requested in appropriate IANA 
        registries? Are the IANA registries clearly identified? If 
        the document creates a new registry, does it define the 
        proposed initial contents of the registry and an allocation 
        procedure for future registrations? Does it suggest a 
        reasonable name for the new registry? See [RFC5226]. If the 
        document describes an Expert Review process has Shepherd 
        conferred with the Responsible Area Director so that the IESG 
        can appoint the needed Expert during the IESG Evaluation? 

No IANA implications as documented in the IANA section.

  (1.j) Has the Document Shepherd verified that sections of the 
        document that are written in a formal language, such as XML 
        code, BNF rules, MIB definitions, etc., validate correctly in 
        an automated checker? 

Not applicable.

  (1.k) The IESG approval announcement includes a Document 
        Announcement Write-Up. Please provide such a Document 
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval 
        announcement contains the following sections:      
 
 Technical Summary 

   IEEE 802.16 is an air interface specification for wireless broadband
   access.  IEEE 802.16 has specified multiple service specific
   Convergence Sublayers for transmitting upper layer protocols.  The
   packet CS (Packet Convergence Sublayer) is used for the transport of
   all packet-based protocols such as Internet Protocol (IP) and IEEE
   802.3 (Ethernet).  The IP-specific part of the Packet CS enables the
   transport of IPv4 packets directly over the IEEE 802.16 MAC.
   This document specifies the frame format, the Maximum Transmission
   Unit (MTU) and address assignment procedures for transmitting IPv4
   packets over the IP-specific part of the Packet Convergence Sublayer
   of IEEE 802.16.

 Working Group Summary

The document underwent much heated discussion, particularly on the proper choice of MTU. 
The document captures consensus within the IETF and includes some information about the
source of such opposing views: WiMAX Forum's use of an MTU of 1400 as opposed to 1500 in
this document. Such discrepancy is not new, as it is also found in the case of the so-called
IPv6 CS (RFC5121). However, in the IPv6 case, the RA MTU option provides an easy solution,
whereas no such reliable method exists for IPv4. Other topics received much input and 
guidance from 802.16 and WiMAX participants.

          Document Quality

This document was produced with the appropriate expertise, as it benefitted from the efforts 
within the IETF of many participants in IEEE 802.16 and the WiMAX Forum, including formal 
reviews from relevant experts in those bodies. 

  (end)