Subject: [dtn] Marking RFC5050 as Obsolete?

From: Rick Taylor <[email-masked]>
Date: Fri, 20 Sep 2019 16:02:22 +0000

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

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Fri, 20 Sep 2019 17:49:55 +0000

If I understand correctly, it sounds like choosing not to mark RFC5050 as obsolete would commit the DTN WG to considering alignment with BPv6 (as well as BPv7) in all future deliberations on DTN standards.  I think that would be a troublesome constraint on the working group.

We've done a lot of good work with BPv6, and existing BPv6 deployments certainly must continue to be supported.  However, I don't think that support necessarily has to extend to the development and standardization of new BPv6 features.

The BPv7 specification, together with bundle-in-bundle encapsulation, is an improved protocol design that encompasses a superset of BPv6 capabilities.  Migrating existing BPv6 deployments to BPv7 will not be effortless, but I think the investment will be amply repaid over the next few years.

So on this reasoning I support the IETF 105 consensus to obsolete RFC5050.

Scott

-----Original Message-----
From: dtn <[email-masked]> On Behalf Of Rick Taylor
Sent: Friday, September 20, 2019 9:02 AM
To: [email-masked]
Subject: [EXTERNAL] [dtn] Marking RFC5050 as Obsolete?

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 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dtn

---

From: Stan Ratliff <[email-masked]>
Date: Fri, 20 Sep 2019 13:55:59 -0400

+1 on marking RFC5050 as obsolete.

Regards,
Stan

On Fri, Sep 20, 2019 at 1:50 PM Burleigh, Scott C (US 312B)
<scott.c.burleigh=[email-masked]> wrote:

> If I understand correctly, it sounds like choosing not to mark RFC5050 as
> obsolete would commit the DTN WG to considering alignment with BPv6 (as
> well as BPv7) in all future deliberations on DTN standards.  I think that
> would be a troublesome constraint on the working group.
>
> We've done a lot of good work with BPv6, and existing BPv6 deployments
> certainly must continue to be supported.  However, I don't think that
> support necessarily has to extend to the development and standardization of
> new BPv6 features.
>
> The BPv7 specification, together with bundle-in-bundle encapsulation, is
> an improved protocol design that encompasses a superset of BPv6
> capabilities.  Migrating existing BPv6 deployments to BPv7 will not be
> effortless, but I think the investment will be amply repaid over the next
> few years.
>
> 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.
>
> 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.
> 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.
>

---

From: Rick Taylor <[email-masked]>
Date: Fri, 20 Sep 2019 18:20:28 +0000

+1 to marking RFC 5050 as obsolete

With my personal hat on…

Rick

From: Stan Ratliff [mailto:[email-masked]]
Sent: 20 September 2019 18:56
To: Burleigh, Scott C (US 312B)
Cc: Rick Taylor; [email-masked]
Subject: Re: [dtn] Marking RFC5050 as Obsolete?

Regards,
Stan

On Fri, Sep 20, 2019 at 1:50 PM Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]<mailto:[email-masked]>> wrote:
If I understand correctly, it sounds like choosing not to mark RFC5050 as obsolete would commit the DTN WG to considering alignment with BPv6 (as well as BPv7) in all future deliberations on DTN standards.  I think that would be a troublesome constraint on the working group.

Scott

-----Original Message-----
From: dtn <[email-masked]<mailto:[email-masked]>> On Behalf Of Rick Taylor
Sent: Friday, September 20, 2019 9:02 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] [dtn] Marking RFC5050 as Obsolete?

Hi All,

Cheers,

Rick & Marc
_______________________________________________
dtn mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dtn

_______________________________________________
dtn mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dtn

---

From: Carlo Caini <[email-masked]>
Date: Mon, 23 Sep 2019 07:47:23 +0000

I agree with the proposal.
Yours,
     Carlo

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 23 Sep 2019 08:16:13 +0000 (UTC)

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 <[email-masked]> wrote: 

Hi All,

Cheers,

Rick & Marc

---

From: Rick Taylor <[email-masked]>
Date: Mon, 23 Sep 2019 08:54:52 +0000

All,

For those looking for clarity between obsolete and historic: I refer to
https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-
historic-2014-07-20/

From my reading (and I am not an IESG process expert, but as chair I
can go find one to quiz if required), two bullets give critical
information, and I quote:

<quote>
* A document is obsolete when there is a newer version that replaces
it. RFC 821 is obsoleted by RFC 2821, which is, in turn, obsoleted by
RFC 5321. The technology that RFC 821 describes — SMTP — is still
current technology, but the documentation of it in RFC 821 is
obsolete. 

* A document is labelled Historic when what it describes is no longer
considered current: no longer recommended for use.
</quote>

The proposal is to mark RFC5050 as obsolete, pointing readers to BPbis,
as the consensus in the room at IETF-105 was that Bundle Protocol is
still "current technology", but the bundle formats and protocol rules
have evolved, as compared to "no longer recommended for use".

Additionally, Lloyd Wood asks a valid question about whether an IETF
working group can mark an IRTF document obsolete/historic.  I am hoping
someone with more experience in this area can add clarification.

Regards,

Rick

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 23 Sep 2019 12:28:54 +0200

> Explicitly obsolete RFC5050? Do you really want to do this?

Yes.

Generally, when experimental protocols are replaced by standards-track protocols, we mark the RFC documenting the experimental protocol as obsoleted by the RFC documenting the standards-track protocol.  E.g., see RFC 3940(*) and RFC 5740.  That, of course, doesn’t mean the *experiment* is “obsolete”, the experiment is done and was a great success, and has led to the standards-track protocol.

The fact that the obsoleted protocol specification was documented in a different process (here, in the IRTF stream) is not really relevant.  Of course, obsoleting the document in the RFC series doesn’t mean that other SDOs (here: CCSDS) magically also consider it obsoleted; that may be work that needs to be done.

I’m CCing the IRTF chair for another opinion on whether there is a problem with a IETF specification obsoleting an experimental IRTF protocol specification.  To me, it is obvious that the DTN WG was set up to do exactly that, and there were a few years to stop this process if this outcome wasn’t desired.

Grüße, Carsten

(*) which came out of an IRTF effort as well, but was completed as an experimental protocol by an IETF working group, so it is not an all-out analog to the situation here.

---

From: Colin Perkins <[email-masked]>
Date: Mon, 23 Sep 2019 12:37:47 +0100

> On 23 Sep 2019, at 11:28, Carsten Bormann <[email-masked]> wrote:

The RFC stream managers and RFC Editor had a discussion about this recently. It doesn’t seem problematic for a standards track RFC published on the IETF stream to obsolete an experimental RFC published by the IRTF, provided there’s coordination between the RFC stream managers and agreement that such a status change is appropriate. I’d expect the IESG to check with the IRTF Chair and IRSG before approving such a draft, for example.

I’ve not read the documents in question, so I won’t comment on this specific case. 

Colin

-- 
Colin Perkins
https://csperkins.org/

---

From: "R. Atkinson" <[email-masked]>
Date: Tue, 24 Sep 2019 07:18:34 -0400

Colin,

Procedurally, the IETF lacks authority over IRTF documents, just as the IETF lacks authority over IAB documents and the IETF lacks authority over Independent Submission documents.  

— This all was well understood when I was on the IAB about 20 years ago.  

— No subsequent process document has changed the above as the correct process.

That noted, the IRTF Chair (or IRSG) could make RFC-5050 (or any other IRTF track RFC) obsolete, and the IRTF process for doing so is WILDLY simpler — an email from IRTF Chair would be sufficient to make it happen.

> On Sep 23, 2019, at 07:37, Colin Perkins <[email-masked]> wrote:
> 
>> The fact that the obsoleted protocol specification was documented in a different process (here, in the IRTF stream) is not really relevant.

Disagree — based on the I* community's actual process documents.

However, the end result is easily accomplished, an email from you in your role as IRTF Chair would be sufficient to make RFC-5050 obsolete and would maintain compliance with the correct procedure.

>>  Of course, obsoleting the document in the RFC series doesn’t mean that other SDOs (here: CCSDS) magically also consider it obsoleted; that may be work that needs to be done.
>> 

Existing correct process would not merely “expect”, but would actually “require”, such coordination.  Further, the authority to obsolete an IRTF document procedurally rests with the IRTF Chair and/or IRSG, not with the IETF or IESG.  In practice, I imagine it is unlikely for the IESG to request anything silly of the IRTF Chair or IRSG, but PLEASE let us follow the correct process.  It is EASY to follow the correct process here.

IRTF is not a subsidiary of the IETF.  The IRTF is a subsidiary of the IAB.  The IAB also is not a subsidiary of the IETF — indeed, the IAB has to review and approve/disapprove IESG nominations coming from NOMCOM.  

And for the avoidance of doubt, that IAB review & approve/disapprove responsibility is NOT a rubber stamp.  I personally know of more than 1 case where the IAB declined to confirm a NOMCOM nomination of someone for the IESG.  I believe this is rare, but it has happened for particular cases where that decline really was the correct answer.

I assume that the ISOC folks who approve/disapprove of NOMCOM nominations for the IAB take equal care in deciding whether to approve/disapprove particular candidates.

> I’ve not read the documents in question, so I won’t comment on this specific case. 

In the specific case, I concur with the numerous folks who believe that RFC-5050 ought to be obsoleted by the publication of the standards-track RFC(s).

If the DTN WG chairs believe, after they decide this thread is finished, that there is WG consensus to obsolete RFC-5050, then I’d suggest that the DTN WG chairs ask the IRTF Chair (with CC: to the IESG) to obsolete RFC-5050 while noting the WG consensus to do so.  If that request were made, then I would hope the IRTF Chair then would do so.

It is EASY to follow the correct process here.  We need not leave the well trod path and go bushwhacking to create a new path.

Yours,

Ran

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 24 Sep 2019 13:33:41 +0200

> If the DTN WG chairs believe, after they decide this thread is finished, that there is WG consensus to obsolete RFC-5050, then I’d suggest that the DTN WG chairs ask the IRTF Chair (with CC: to the…

Sounds like a good approach to me.

> It is EASY to follow the correct process here.  We need not leave the well trod path and go bushwhacking to create a new path.

Agreed.  

Translating this to a useful process from the point of the WG that creates the obsoleting specification:

— WG agrees that the RFC-to-be should obsolete the experimental RFC; write this into the I-D (“obsoletes” attribute + mention in abstract/introduction)
— confirm the consensus for this in the WGLC
— put out the formal request to the IRTF chair at the time the document is submitted to the IESG (i.e., “leaves the WG”) — as always, an early heads up is probably appreciated, but the IRTF chair’s decision should be based on what actually leaves the WG.

The IESG should probably check before approval that such a process was followed (oh no, another line item in the shepherd’s writeup), but, really, the RFC editor should be the gating point here.

Grüße, Carsten

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Sep 2019 12:49:55 +0100

That all sounds right to me, as does obsoleting 5050.

One tweak though - at some point someone should check
(informally) if CCSDS need some formal notification
about this or not. Hopefully not, as Scott and others
active there are active here, but if they do, then
that maybe ought come from the IETF I guess as the
IRTF hasn't previously "liaised." So that could be
another thing for the WG chairs and AD to include
in the dance.

Cheers,
S.

On 24/09/2019 12:33, Carsten Bormann wrote:
>> If the DTN WG chairs believe, after they decide this thread is
>> finished, that there is WG consensus to obsolete RFC-5050, then I’d
>> suggest that the DTN WG chairs ask the IRTF Chair (with CC: to the
>> IESG) to obsolete RFC-5050 while noting the WG consensus to do so.
>> If that request were made, then I would hope the IRTF Chair then
>> would do so.
> 
>> It is EASY to follow the correct process here.  We need not leave
>> the well trod path and go bushwhacking to create a new path.
> 
> Agreed.
> 
> — WG agrees that the RFC-to-be should obsolete the experimental RFC;
> write this into the I-D (“obsoletes” attribute + mention in
> abstract/introduction) — confirm the consensus for this in the WGLC —
> put out the formal request to the IRTF chair at the time the document
> is submitted to the IESG (i.e., “leaves the WG”) — as always, an
> early heads up is probably appreciated, but the IRTF chair’s decision
> should be based on what actually leaves the WG.
> 
> The IESG should probably check before approval that such a process
> was followed (oh no, another line item in the shepherd’s writeup),
> but, really, the RFC editor should be the gating point here.
> 
> Grüße, Carsten
> 
> _______________________________________________ dtn mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dtn
>

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 24 Sep 2019 12:12:04 +0000 (UTC)

The IESG note at the start of RFC5050 *is* the formalnotification; the IETF has already washed their hands of it,CCSDS was already told, as were all readers.

done and dusted.

Given that warning, how the IETF can declare somethingit's already disclaimed to be obsolete is a puzzle to me.It's withdrawing an endorsement that was never there.

Lloyd Wood

    On Tuesday, 24 September 2019, 21:50:15 GMT+10, Stephen Farrell <[email-masked]> wrote:  

about this or not.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 24 Sep 2019 15:02:42 +0200

On Sep 24, 2019, at 14:12, [email-masked] <lloyd.wood=[email-masked]> wrote:
> 
> Given that warning, how the IETF can declare something
> it's already disclaimed to be obsolete is a puzzle to me.
> It’s withdrawing an endorsement that was never there.

We are not discussing whether RFC 5050 is obsolete.

We are discussing whether the BPv7 specification obsoletes RFC 5050.
“Obsoletes” is a technical term here, keep your hands off your Webster’s (or OED or whatever).

Grüße, Carsten

---

From: Colin Perkins <[email-masked]>
Date: Tue, 24 Sep 2019 15:04:28 +0100

> On 24 Sep 2019, at 12:33, Carsten Bormann <[email-masked]> wrote:

Indeed – it seems we’re in vigorous agreement on the principle, but perhaps differ in how to make the process concrete.

> — confirm the consensus for this in the WGLC

I agree with all this.

> — put out the formal request to the IRTF chair at the time the document is submitted to the IESG (i.e., “leaves the WG”) — as always, an early heads up is probably appreciated, but the IRTF chair’s…

An early heads-up from working group would be appreciated, and might be useful to avoid late surprises, but I'd expect the formal request to change the status of the IRTF RFC to come from the IESG, not the working group.

Colin

-- 
Colin Perkins
https://csperkins.org/

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 25 Sep 2019 19:52:08 +0000

Coming into this late, no one has mentioned the analogy of IPv4 and IPv6. IPv6
did not obsolete IPv4 when it was published over 20 years ago. Had IPv6 come
out and said "obsoletes IPv4" at the time of its publication would we now have
an all-IPv6 Internet today? Probably not - operational experience with IPv4
would have continued along its then-current trajectory extending up to the
present day.

It is the same with BPv6 and BPv7 - there is a non-negligible deployment of BPv6
that will still continue after BPv7 is published whether we say "obsoletes" or not.
There is operational experience with BPv6 that will continue onwards the same
as happened with IPv4, and that is not a bad thing.

Fred

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Wed, 25 Sep 2019 21:27:22 +0000

Absolutely.  I think the issue really is just whether or not the IETF DTN WG will be responsible for maintenance and extension of BPv6 in the future.  And maybe that's simply not an issue.

Scott

-----Original Message-----
From: dtn <[email-masked]> On Behalf Of Templin (US), Fred L
Sent: Wednesday, September 25, 2019 12:52 PM
Cc: [email-masked]; [email-masked]
Subject: [EXTERNAL] Re: [dtn] Marking RFC5050 as Obsolete?

Coming into this late, no one has mentioned the analogy of IPv4 and IPv6. IPv6 did not obsolete IPv4 when it was published over 20 years ago. Had IPv6 come out and said "obsoletes IPv4" at the time of its publication would we now have an all-IPv6 Internet today? Probably not - operational experience with IPv4 would have continued along its then-current trajectory extending up to the present day.

It is the same with BPv6 and BPv7 - there is a non-negligible deployment of BPv6 that will still continue after BPv7 is published whether we say "obsoletes" or not.
There is operational experience with BPv6 that will continue onwards the same as happened with IPv4, and that is not a bad thing.

Fred

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 26 Sep 2019 09:39:23 +0200

> as happened with IPv4, and that is not a bad thing.

There will always be protocols in real world use that have been replaced by newer ones.

The question here is one of expressing intent.  Is BPv7 intended to supersede BPv6 or not?  

I’m not talking about “deployment realities” here (heck, I still have some Python v2 on my system), I’m talking about intent going forward.  Either the intent is to sustain both versions indefinitely (with bug fixes and extensions still going into BPv6), or the intent is to move to BPv7.  Like with Python v3, which ultimately needed a strong statement (and even a deadline) that it is now time to stop using Python v2 (and even then, the Python v2 is not going to vanish from my systems magically, and there will likely be some people hacking v2 and keeping it alive even beyond 2020-01-01).
(We don’t need a deadline here, but we need to be clear about the intent.)

I don’t think IPv4 vs. IPv6 is a good analogy here, but if you have a massive infrastructure processing BPv6 bundles, it may seem to be that way to you.

Grüße, Carsten

---

From: Loiseau lucien <[email-masked]>
Date: Thu, 26 Sep 2019 16:52:05 +0800

Hi,

>From an implementation point of view it would make sense to obsolete
RFC5050 as it would make it clear that new implementation shall be done
following the BPv7 specification. It would send a clear signal that the
working group has decided to no longer support this protocol and will
instead focus its effort into developing BPv7.

Regarding the analogy with IPv4/IPv6, when IPv6 came out there were already
hundreds of millions of IPv4 users interconnected to the same network.
Today most of the existing BPv6 networks are not really "public" nor
interconnected to one another so obsoleting the RFC doesn't prevent the
administrators to simply ignore this status update and continue operating
their legacy network as usual.

Regards,
Lucien

On Thu, Sep 26, 2019 at 3:39 PM Carsten Bormann <[email-masked]> wrote:

> I’m not talking about “deployment realities” here (heck, I still have some
> Python v2 on my system), I’m talking about intent going forward.  Either
> the intent is to sustain both versions indefinitely (with bug fixes and
> extensions still going into BPv6), or the intent is to move to BPv7.  Like
> with Python v3, which ultimately needed a strong statement (and even a
> deadline) that it is now time to stop using Python v2 (and even then, the
> Python v2 is not going to vanish from my systems magically, and there will
> likely be some people hacking v2 and keeping it alive even beyond
> 2020-01-01).
> I don’t think IPv4 vs. IPv6 is a good analogy here, but if you have a
> massive infrastructure processing BPv6 bundles, it may seem to be that way
> to you.
>
> Grüße, Carsten
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 26 Sep 2019 11:02:05 +0000

On Tue, 2019-09-24 at 15:04 +0100, Colin Perkins wrote:
> > 
> 
> > — put out the formal request to the IRTF chair at the time the document is
> > submitted to the IESG (i.e., “leaves the WG”) — as always, an early heads up
> > is probably appreciated, but the IRTF chair’s decision should be based on
> > what actually leaves the WG.
> 
> An early heads-up from working group would be appreciated, and might be useful
> to avoid late surprises, but I'd expect the formal request to change the
> status of the IRTF RFC to come from the IESG, not the working group.
> 

Yes, and I think a formal request to the IRTF chair and IRSG is easy to 
create as the document goes for IETF last call. That way the IESG should have 
that agreement in hand prior to deciding on approving the document. 

Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 26 Sep 2019 13:57:39 +0000

Actually, I like the IPv4 / IPv6 analogy but if you don't consider also that IPv4 did not
"obsolete" OSI yet there are still small pockets of OSI deployment worldwide. (For
that matter, I don't think anyone ever claimed to "obsolete" DECnet.) In this sense,
by going out of our way to say "obsoletes" BPv7 would going against the precedence
set by a number of significant earlier examples.

Fred

> From: Carsten Bormann [mailto:[email-masked]]
> Sent: Thursday, September 26, 2019 12:39 AM
> To: Templin (US), Fred L <[email-masked]>
> I’m not talking about “deployment realities” here (heck, I still have some Python v2 on my system), I’m talking about intent going
> forward.  Either the intent is to sustain both versions indefinitely (with bug fixes and extensions still going into BPv6), or the intent is to
> move to BPv7.  Like with Python v3, which ultimately needed a strong statement (and even a deadline) that it is now time to stop
> using Python v2 (and even then, the Python v2 is not going to vanish from my systems magically, and there will likely be some people
> hacking v2 and keeping it alive even beyond 2020-01-01).