[BEHAVE] Errata 5415 (RE: Closing the mailing list)
<mohamed.boucadair@orange.com> Wed, 15 January 2020 14:19 UTC
Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F7B120025 for <behave@ietfa.amsl.com>; Wed, 15 Jan 2020 06:19:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxabjMLZH9Mn for <behave@ietfa.amsl.com>; Wed, 15 Jan 2020 06:19:38 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E4F120071 for <behave@ietf.org>; Wed, 15 Jan 2020 06:19:38 -0800 (PST)
Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 47yTwn0l3czBsBf; Wed, 15 Jan 2020 15:19:37 +0100 (CET)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.82]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 47yTwm6ZMGzCqkl; Wed, 15 Jan 2020 15:19:36 +0100 (CET)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM5E.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Wed, 15 Jan 2020 15:19:36 +0100
From: mohamed.boucadair@orange.com
To: Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org>, "behave@ietf.org" <behave@ietf.org>, "mcr@sandelman.ca" <mcr@sandelman.ca>, "tte@cs.fau.de" <tte@cs.fau.de>
Thread-Topic: Errata 5415 (RE: [BEHAVE] Closing the mailing list)
Thread-Index: AdXLrs8tI5jt9u5tQ4qJcYt8sAKAng==
Date: Wed, 15 Jan 2020 14:19:35 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93303140915B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: multipart/mixed; boundary="_002_787AE7BB302AE849A7480A190F8B93303140915BOPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/bMhMQrrdHS78vJ7hRFhlF_tQb-4>
Subject: [BEHAVE] Errata 5415 (RE: Closing the mailing list)
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/behave/>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2020 14:19:44 -0000
Hi Magnus, In reference to errata 5415, please find attached the response I sent when the errata was received. I still maintain that position. Cheers, Med > -----Message d'origine----- > De : Behave [mailto:behave-bounces@ietf.org] De la part de Magnus > Westerlund > Envoyé : mercredi 15 janvier 2020 14:15 > À : behave@ietf.org; mcr@sandelman.ca; tte@cs.fau.de > Objet : Re: [BEHAVE] Closing the mailing list > > On Fri, 2020-01-10 at 10:46 -0500, Michael Richardson wrote: > > Toerless Eckert <tte@cs.fau.de> wrote: > > > Whats the benefit of closing the list ? If someone has > calculated that > > > the 20 KByte of disk space required to maintain it on IETF > servers costs > > > 50 cents/quarter, i am happy to shoulder that cost. > > > > I also don't know why we close lists for WGs that have documents in > the wild. > > The result is that we can't process errata. If you get stream of > > unsubscribes are a result of this thread, fine, people have sorted > themselves. > > > > I think the largest cost is in volunteer effort from having someone > moderate the list. If someone is willing to become admin of the list > then I can keep it alive for now as there apparently some that care. > > When it comes to errata there are some benefit in the mailing list. > There are actually 7 Errata that are not processed. > > RFC5766 (4933) 17.3.3 Technical behave (tsv) shakeeb > TEXT > 2017-02-15 > RFC5769 (4776) 2 Technical behave (tsv) software should > include > manufacturer and version number TEXT 2016-08-12 > RFC6052 (5415) 2.2 Technical behave (tsv) Dale R. Worley > TEXT > 2018-07-01 > RFC6062 (3467) 5.2. Technical behave (tsv) Nazmus Shakeeb > TEXT > 2013-01-22 > RFC6145 (4090) 6 Technical behave (tsv) Fernando Gont > TEXT > 2014-08-20 > RFC6146 (4756) 3.5.3 Technical behave (tsv) Alberto Leiva > Popper > TEXT 2016-08-02 > RFC7050 (5152) IANA Conside Technical behave (tsv) Mark > Andrews > TEXT 2017-10-11 > > If I get recommendation for how to handle them I will sanity check the > recommendation and then register it in the system. > > > Cheers > > Magnus Westerlund > > > ---------------------------------------------------------------------- > Networks, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ----------------------------------------------------------------------
--- Begin Message ---Dear Dale, Thank you for formally raising the point. I do think that the u byte makes things complex and is not justified any more. Nevertheless, that artificially boundary was provisioned for "historical" reasons that were clarified in RFC 7136. The community considered in the past updating RFC6052 to reflect that. For example, you may refer to https://www.ietf.org/mail-archive/web/softwires/current/msg05508.html, but even at that time, the consensus of the softwire wg was to follow RFC6052 as it is (https://tools.ietf.org/html/rfc7599). I suggest to maintain RFC6052 as it is. The harm is behind us given the installed deployment base: RFC6052-based implementations are widely deployed. It is key for all IPv6-only deployments in cellular networks over the world.. There is more harm in updating its vs. maintain it because of interoperability issue. Cheers, Med > -----Message d'origine----- > De : Behave [mailto:behave-bounces@ietf.org] De la part de RFC Errata System > Envoyé : dimanche 1 juillet 2018 15:46 > À : congxiao@cernet.edu.cn; huitema@microsoft.com; marcelo@it.uc3m.es; > mohamed.boucadair@orange-ftgroup.com; xing@cernet.edu.cn; > spencerdawkins.ietf@gmail.com; ietf@kuehlewind.net; dwing@cisco.com; > dthaler@microsoft.com > Cc : worley@ariadne.com; behave@ietf.org; rfc-editor@rfc-editor.org > Objet : [BEHAVE] [Technical Errata Reported] RFC6052 (5415) > > The following errata report has been submitted for RFC6052, > "IPv6 Addressing of IPv4/IPv6 Translators". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5415 > > -------------------------------------- > Type: Technical > Reported by: Dale R. Worley <worley@ariadne.com> > > Section: 2.2 > > Original Text > ------------- > Bits 64 to 71 of the address are reserved for compatibility with the > host identifier format defined in the IPv6 addressing architecture > [RFC4291]. These bits MUST be set to zero. When using a /96 > Network-Specific Prefix, the administrators MUST ensure that the bits > 64 to 71 are set to zero. A simple way to achieve that is to > construct the /96 Network-Specific Prefix by picking a /64 prefix, > and then adding 4 octets set to zero. > > [and other parts of the text] > > > Corrected Text > -------------- > [This paragraph should be removed and corresponding changes made to > the rest of section 2.2.] > > Notes > ----- > Section 2.2 says that bits 64 to 71 of the Ipv6 address MUST be set to zero > and references RFC 4291 as the authority. However, RFC 7136 says: > > In particular, RFC 4291 defines a method by which the > Universal and Group bits of an IEEE link-layer address are mapped > into an IPv6 unicast interface identifier. This document clarifies > that those two bits are significant only in the process of deriving > interface identifiers from an IEEE link-layer address, and it updates > RFC 4291 accordingly. > > Thus, the text I've referenced in RFC 6052 is to enforce a requirement that > was not correctly applied, and RFC 6052's statement about bits 64 to 71 > should be removed. In addition, there are consequent changes in other parts > of RFC 6052, including Figure 1, where the "u" field should be removed from > the address formats. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6052 (draft-ietf-behave-address-format-10) > -------------------------------------- > Title : IPv6 Addressing of IPv4/IPv6 Translators > Publication Date : October 2010 > Author(s) : C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, X. Li > Category : PROPOSED STANDARD > Source : Behavior Engineering for Hindrance Avoidance > Area : Transport > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave--- End Message ---
- [BEHAVE] Errata 5415 (RE: Closing the mailing lis… mohamed.boucadair