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 (UTC)
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