Re: [dtn] Marking RFC5050 as Obsolete?
"lloyd.wood@yahoo.co.uk" <lloyd.wood@yahoo.co.uk> Mon, 23 September 2019 08:17 UTC
Return-Path: <lloyd.wood@yahoo.co.uk>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8ADD12013B for <dtn@ietfa.amsl.com>; Mon, 23 Sep 2019 01:17:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.025
X-Spam-Level:
X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.co.uk
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 ZB7grZAHfyRo for <dtn@ietfa.amsl.com>; Mon, 23 Sep 2019 01:17:40 -0700 (PDT)
Received: from sonic303-19.consmr.mail.ir2.yahoo.com (sonic303-19.consmr.mail.ir2.yahoo.com [77.238.178.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8958B120143 for <dtn@ietf.org>; Mon, 23 Sep 2019 01:17:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1569226658; bh=tg/vLveveqAf6UzZBJYjT4QcraY0HMb/qOi3iSoE+WM=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=i2IDXdWVY8BaX+f4KT5hiKKQp4kct0ozbHI9qjt3y7ZTlj8KSUqmXlnGizUA8GYd9ko9oBeOHvtnK1bggNBmASBdzXrqS4dPHXpFda9UyleaO65GbH5Jf5TSwBpPUArWR09OVIskvPHsO4/JcX4KRrmXdgGo2zbPdWRlcP7LMXzPGIQquUoJghZOdGt0utJ9MMm1lgt1Jbdk8RjMa2Z6+WqCAAdYt61PkyowJrvUlYYYEQKmRJOx5NrFXhUm0kqe65zdbuZyrdxRwkwMuxSose2omzhe+p4u7e5PQHwfBnhwCbuLxAiNW1HwQdS1cIH2+olJwmREKHxXZWaEke8IsQ==
X-YMail-OSG: l_TaKhcVM1lPheJSkgPwkDvBoP0jwwR1HY4R_mPTpVDTdjDguENAk1kMmrxIfTX Yz_RjEuyGOmwWCm_U3sgLt5gbU6bVr33_VubOuxUl2K23AUMvPo0LdgOWh1Op7_LfOx5GBM9MGoQ MIO7JzkCAhlKF8CsgDO97Xu3uTMQh2tVfvhhnuozVN7tpm49m8ZFRXRcjFnF9_FldrjWQBp5QmUe Z7Ug5R4YrdCjftzRWqqYsB4DWXBPuopHZRGr06YRPQ7orkec6nKe91ULrisWVoALKUg5GHkqeayn JR91an1cArwcko_7Blee.xq2ojrMIgoSbTP2L5bXd8Nhxqmc4Rde7bELIPxldW6wHibysmgzqH09 4NqA4Pj.xmwoaY2B8G6j3TPdj6_DKQMNgn3YTWDpYDsU2fg530EuOtdeHVSC5papergRy.gKXppz muxnpRro2Erdi4.cCXRoAnkUm2qcnFQxi3cC_w.eiI2Euiii56CgrquRdFYwuKEMJcK4eTfaVAfP eWxRdIAufc0BRzk5i2E.iht6xbA2L6R7Tz1y3TB5HrIVZVRd7Ys9K0_rJcSWpphkSkYs5UMk_F7o jmsyfv8cutTKf1da.5nJIhqjyUcjPBmho3Pg6dsU8.l7TRXMfvDmwIkxZ.5vwTcgn5wfb1Q2o1PM 6gXyfp9uzAIqEDJKjUmidl5Ykhwro2B2NEVx8D7AIXg8NFt_3W9Ww.EQv.Memhqr5ZVkSneETiB3 Le521r7Z8mXA0LBP1Cc1twDxa92BYO83eks18RBmUy5rL2PuP7_c134_PivU8ZwWQDeopXtMtA0l ZcUp4SLOlKfq5R1PVhXYPk2mYaVNu0WlOpL.xzKbo_nW7UKnrH0Xw9KxEozvMnCYqtnIGqAy0S.M YLLcYyoDK2Sk7hqzbw0Jds5wCyxfSSSx8pAAQC6o9NHdoR34ORUgevfJqKtSkrNxyepfzEkMBjLd oD0AG3G2AsqEpyK3jaLWYmJbVtkLbFQkZZD4tqlX7zZywVTw1ie3YR2ZgrRLUBmhpq_tizFzmleB e1FNH6o5tpdWtzXO1gNPgi8t3gFSXBDUVgsAjxe4BWFHSkE6MILED0aB0CM3BVSzWbUMV_7DvqyF 0ki.EPS5JurtjYotxKN3Lbl9Qq.dTxty89ySlPrfHZ7KJCMQ09kdzzZF56DiTHTh8DLFyQR9ceoz Wiu3Q20XVGG.HJeBdyV80QLHxOC_mkBiFZ48HOTSl_wp1MVZUzaO7nNu6_ZgIIA0gTXJLieJdQnc rrDUfdF5XuWXA2yqXt63__n4imbTvn5NTpgodt.mo03zpgar69ox5zhzWnhjseCcRqA--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ir2.yahoo.com with HTTP; Mon, 23 Sep 2019 08:17:38 +0000
Date: Mon, 23 Sep 2019 08:16:13 +0000
From: "lloyd.wood@yahoo.co.uk" <lloyd.wood@yahoo.co.uk>
To: "dtn@ietf.org" <dtn@ietf.org>, Rick Taylor <rick@tropicalstormsoftware.com>
Message-ID: <1376435003.14731004.1569226573419@mail.yahoo.com>
In-Reply-To: <ecc5ee275929440b8b70d570451219a77dc5a176.camel@tropicalstormsoftware.com>
References: <ecc5ee275929440b8b70d570451219a77dc5a176.camel@tropicalstormsoftware.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Mailer: WebService/1.1.14303 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/ZRbwHUbYRm4J__JyH2OPwnHdZpI>
Subject: Re: [dtn] Marking RFC5050 as Obsolete?
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Sep 2019 08:17:43 -0000
A question for clarity. Is the desire to have RFC5050 marked as obsolete because one of: a. once draft-bpbis gets published as an RFC, 5050 is considered deprecated, and the new RFC is considered the one to use, so this is a promotional exercise? b. no-one is using RFC5050? I think the answer to that from the limited mailing list discussion I've seen is clearly a. The problems and further questions start in how this gets done as a process: i. RFC5050 is really an _IRTF_ document, even though it's published as an IETF RFC, product of the Network Working Group, actual implementations, yadda yadda. Can IRTF products, marked as experimental, really ever be obsoleted? They're for research! I don't know of any IRTF things that have been obsoleted offhand. ii. Obsolete isn't an RFC status AFAIK. Historic is, though. Writing up an RFC saying that an RFC is obsolete and is being moved to Historic has been done, and that gets you the 'Obsoleted by' bit. See e.g. RFC4048, which says that RFC1888 (which was experimental) is obsolete, and why -- actual technical reasons for why -- and moves it to Historic. Now, that could be done in a note in the published draft-bpbis-as-RFC, which could move 5050 to Historic, and say why -- except RFC5050 is clearly in use, and Historic would not be appropriate for something in such active use that works for those use cases. (Feel free to tell me that the RFC5050 user base is in fact very small, and not very active, and can be disregarded, so Historic would be appropriate. In which case, no strong signal is needed...) As there are 5050 implementations in existence and in use, sending a command that it's obsolete can't really be justified imo -- and neither can moving it to Historic without strong technical reasons. (Helpfully, I can think of a number of technical reasons: see "A Bundle of Problems", IEEE Aerospace, 2009. Checksums! clocks! ...) iii. RFC5050 is not a product of this working group. It's a product of the IRTF and the DTNRG, not the DTNWG, so it is arguably not this working group's problem, and anyway, it was experimental, use at own risk, etc. Maintaining backwards compatibility with the experimental RFC5050 might seem both voluntary and entirely unnecessary. And, does the WG have the actual authority to declare an IRTF product from a different RG obsolete -- if 'obsolete' was a category, which it isn't? Nitpicking, I know, but sans an RFC Editor etc. someone has to ask these oversight questions. iv. Didn't CCSDS restandardize RFC5050 https://public.ccsds.org/Pubs/734x2b1.pdf RECOMMENDED STANDARD CCSDS 734.2-B-1 September 2015 (dedicated to Adrian) based on RFC5050? So, unsure about IRTF products, but this workgroup definitely doesn't have the authority to mark that CCSDS recommended standard obsolete. And a good question is how many have implemented to RFC5050, and how many have implemented to this CCSDS doc? And what would trying to move RFC5050 to historic do for the standards bodies relationship here? Suddenly RFC5050 backcompatibility looks very necessary. My take is that publishing bpbis as an RFC is, by itself, sufficient to indicate that RFC5050 is considered obsolete (at least, by the authors of bpbis and the workgroup that got it through) but the rest is -entirely- up to the market and cannot be this workgroup's problem. The CCSDS stuff is then entirely out of this group's hands. Attempting to deliberately mark RFC5050 as Historic opens... difficulties; benign neglect is your friend here. (I find the fact that the CCSDS crowd has caused yet another legacy problem for itself interesting; people are still contemplating moving from CFDP... promoting the future as you want to see it remains as tricky as ever.) If telling people that protocols are obsolete were easy, IPv6 would have marked IPv4 as Historic a long time ago, and there would be a "don't use IPv4 ever, as it's obsolete, we're marking everything Historic, you have been told" section in some RFC or other. Explicitly obsolete RFC5050? Do you really want to do this? Lloyd Wood http://lloydwood.users.sf.net/Personal/L.Wood/dtn On Saturday, 21 September 2019, 02:02:35 GMT+10, Rick Taylor <rick@tropicalstormsoftware.com> wrote: Hi All, During the DTN interim meeting on Sept 18th, there was a discussion on making RFC5050 obsolete or not. This discussion also happened at IETF 105 and the consensus of the room was to obsolete RFC5050. This consensus was not formally called and verified on the mailing list afterwards (although minutes were posted), and so this is the purpose of this email. It is well understood by the working group that there is existing investment in RFC5050 implementations and installations, and that these will not immediately move to BPv7 if RFC5050 is marked as obsolete. However, by doing so a strong signal is sent to industry that the working group considers BPv7 as the replacement for RFC5050, and that future effort by the working group will be directed solely at BPv7. This would not automatically preclude any work around supporting moving from RFC5050 to BPv7 or interoperability, but such work would not be considered a priority. If the working group does not choose to mark RFC5050 as obsolete, we are committing to maintain it as a suitable target for convergence layers, addressing schemes, routing and management protocols, etc. that may be standardised in the future by the working group. Hence, here is the request: Should draft-ietf-dtn-bpbis obsolete RFC5050? Cheers, Rick & Marc
- [dtn] Marking RFC5050 as Obsolete? Rick Taylor
- Re: [dtn] Marking RFC5050 as Obsolete? Burleigh, Scott C (US 312B)
- Re: [dtn] Marking RFC5050 as Obsolete? Stan Ratliff
- Re: [dtn] Marking RFC5050 as Obsolete? Rick Taylor
- Re: [dtn] Marking RFC5050 as Obsolete? Carlo Caini
- Re: [dtn] Marking RFC5050 as Obsolete? lloyd.wood@yahoo.co.uk
- Re: [dtn] Marking RFC5050 as Obsolete? Rick Taylor
- Re: [dtn] Marking RFC5050 as Obsolete? Carsten Bormann
- Re: [dtn] Marking RFC5050 as Obsolete? Colin Perkins
- Re: [dtn] Marking RFC5050 as Obsolete? R. Atkinson
- Re: [dtn] Marking RFC5050 as Obsolete? Carsten Bormann
- Re: [dtn] Marking RFC5050 as Obsolete? Stephen Farrell
- Re: [dtn] Marking RFC5050 as Obsolete? lloyd.wood@yahoo.co.uk
- Re: [dtn] Marking RFC5050 as Obsolete? Carsten Bormann
- Re: [dtn] Marking RFC5050 as Obsolete? Colin Perkins
- Re: [dtn] Marking RFC5050 as Obsolete? Templin (US), Fred L
- Re: [dtn] Marking RFC5050 as Obsolete? Burleigh, Scott C (US 312B)
- Re: [dtn] Marking RFC5050 as Obsolete? Carsten Bormann
- Re: [dtn] Marking RFC5050 as Obsolete? Loiseau lucien
- Re: [dtn] Marking RFC5050 as Obsolete? Magnus Westerlund
- Re: [dtn] Marking RFC5050 as Obsolete? Templin (US), Fred L
- Re: [dtn] Marking RFC5050 as Obsolete? Burleigh, Scott C (US 312B)
- Re: [dtn] Marking RFC5050 as Obsolete? Templin (US), Fred L
- Re: [dtn] Marking RFC5050 as Obsolete? Carsten Bormann
- Re: [dtn] Marking RFC5050 as Obsolete? Templin (US), Fred L