Re: [dtn] Marking RFC5050 as Obsolete?

["[e-mail]" <[e-mail]>]

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 <[e-mail]> 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