[16NG] Document Shepherd Write-Up for draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-06
gabriel montenegro <g_e_montenegro@yahoo.com> Sat, 03 October 2009 08:15 UTC
Return-Path: <g_e_montenegro@yahoo.com>
X-Original-To: 16ng@core3.amsl.com
Delivered-To: 16ng@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C29EF3A684C for <16ng@core3.amsl.com>; Sat, 3 Oct 2009 01:15:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.334
X-Spam-Level:
X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[AWL=1.265, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43e-nZ-0VjNP for <16ng@core3.amsl.com>; Sat, 3 Oct 2009 01:15:46 -0700 (PDT)
Received: from web82602.mail.mud.yahoo.com (web82602.mail.mud.yahoo.com [68.142.201.119]) by core3.amsl.com (Postfix) with SMTP id 8854E3A6847 for <16ng@ietf.org>; Sat, 3 Oct 2009 01:15:46 -0700 (PDT)
Received: (qmail 29637 invoked by uid 60001); 3 Oct 2009 08:10:33 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XKm6uWtgJtCGjaMny11Bvb6Jv/uHihIf+H8guPYzUkztRlkuZZE7fapYqhru8GeUevAEyuSdTi+XXkuiK/fQDE19kecvXWHjWFLRIP8gZF+DC8LohBDxjlreCQIT5r4G/OK8RLMx9SpbstthU5O5Q1AuP6a0jlwRNZqTqXXUoZM=;
Message-ID: <991533.29576.qm@web82602.mail.mud.yahoo.com>
X-YMail-OSG: W4zsbxoVM1m4b1joUmTU54YQET4SgKsTKGwbnsehGYaIGqVkkondTxY8j5k1Jcd.PCLZifans.gJu6YgtIqnUqdwmEB_BT3q083JLVmpYnfJXZN0uTAlsDAfbPsxLwtnapxdJgWaiYcKcHxO86myla9TYlDo42AgF_s9VOLrfWlTGrQyQpx2hC1pRsMxHuHy5BfFapm7jC1V1lKAjxIa8HVWOFtO1HWSXHWePwX_S2FZc5RWNt2evthu5xhtILp25e3WLSAGXBW3iQdrYLD0bWNU8NoGlA2bY6yk2hzLpilFXk1pl6JbQYZK.ogrl36eWLm3wYwP_VL8wnCL_UZoxoRY0ffJzTOcZfGJoLENRB0SPeYQDfGnvqG2GrnQTySVVdFTqDkGIojurKQfR5TV.heD3fPWVFQ3YtTsorOSFw--
Received: from [98.237.194.230] by web82602.mail.mud.yahoo.com via HTTP; Sat, 03 Oct 2009 01:10:32 PDT
X-Mailer: YahooMailRC/157.18 YahooMailWebService/0.7.347.3
Date: Sat, 03 Oct 2009 01:10:32 -0700
From: gabriel montenegro <g_e_montenegro@yahoo.com>
To: Ralph Droms <rdroms@cisco.com>, IESG Secretary <iesg-secretary@ietf.org>, 16ng@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Subject: [16NG] Document Shepherd Write-Up for draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-06
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Oct 2009 08:15:46 -0000
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)
- [16NG] Document Shepherd Write-Up for draft-ietf-… gabriel montenegro