Subject: Re: [dtn] I-D Action: draft-ietf-dtn-tcpclv4-16.txt [AD-INT]

From: Magnus Westerlund <[email-masked]>
Date: Mon, 2 Dec 2019 13:19:09 +0000

Hi Scott, WG Chairs and the WG,

Let clarify the situation and what needs to happen. 

On Fri, 2019-11-29 at 23:34 +0000, Burleigh, Scott C (US 312B) wrote:
> Okay, wait.  If the consensus that was reached at the meeting is not the final
> consensus, despite direct contemporaneous IESG input, and we therefore have to
> go back to the WG mailing list again for a final decision, then I strongly
> suspect we will once again end up in a state of non-consensus and immobility. 

The IETF process says that the WG meeting decsicions do need to be confirmed on
the mailing list.

RFC 2418 (BCP) - Section 3.2 states:

3.2. Session venue

   Each working group will determine the balance of email and face-to-
   face sessions that is appropriate for achieving its milestones.
   Electronic mail permits the widest participation; face-to-face
   meetings often permit better focus and therefore can be more
   efficient for reaching a consensus among a core of the working group
   participants.  In determining the balance, the WG must ensure that
   its process does not serve to exclude contribution by email-only
   participants.  Decisions reached during a face-to-face meeting about
   topics or issues which have not been discussed on the mailing list,
   or are significantly different from previously arrived mailing list
   consensus MUST be reviewed on the mailing list.

And my understanding of the outcome of the WG meeting was such that this case do
apply as my understanding was that the meeting wanted to reneg its decision to
not obsolete RFC5050 after I had clarified that the process for having an IETF
document obsolete an IRTF document was now in place as the IESG has discussed
this with the IRTF chair and they have agreed on a process. 

>  I totally agree with Rick that we must stop going around this buoy, but it
> may be out of our hands:  I believe there is still significant opposition
> within the WG to the prospect of the BPbis specification obsoleting RFC 5050.

Based on the earlier discussion my judgement was that a quite rough consensus
could have been declared, but the WG chairs decided on this other route. 

In the meeting I just clarified Rick's statement that it was not possible to
obsolete the IRTF documents. That lead to the in meeting discussion that
obsoleting RFC 5050 would be good. I interpreted that it was the meetings
consensus to have BPv7 oboslete RFC5050. That is the reason I was requesting the
WG chairs to confirm that changed consensus on the mailing list. 

I like to note that although I personally would prefer to obsolete RFC 5050 from
a process perspective, I think it is the WG's decision on what direction to
take. However, I think it is important that the WG both follows IETF process as
well as the WG having the accurate information about process and implications of
there decision. 

Process wise, I think we are in a situation where the WG chairs basically has to
run a confirmation or consensus call on the mailing list for at least one week.
What decision they like to make a call on I think is up to the chairs. There are
two options. 

A) Confirm the meeting decision to obsolete.

B) State that the chairs believe the meeting was wrong and have the call confirm
that the old consensus still holds. 

Hope that clarifies the situation. 

Cheers

Magnus Westerlund

> 
> If I am wrong about this, excellent; let's press ahead!
> 
> But if I am right, then I would urge us to drop back to the formulation that
> had been arduously worked out by the chairs as of 17 October:
> 
> "RFC5050 is an experimental RFC, done in IRTF, while draft-ietf-dtn-bpbis will
> be a Standard track RFC, done in IETF. Different streams, different processes.
> 
> "We believe there is a strong consensus to not continue working on RFC5050 and
> not try to be backward compatible. RFC5050 implementations and deployments can
> continue as they see fit.
> 
> "IANA registries have their own life, whatever the stream or type of RFC they
> were created from. They can always be updated by a new RFC.
> 
> "Given that, we suggest the following steps: 
> 	1) draft-ietf-dtn-bpbis would not obsolete RFC5050. Instead we would
> notify IRTF that draft-ietf-dtn-bpbis is an update of RFC5050. IRTF will
> decide what they want to do, if anything, with RFC5050.
> 	2) in the new version of the charter that we are currently working on,
> we will state clearly that there is no intent to work on or make compatible
> work with RFC5050 and related RFCs 
> 	3) DTN working group document authors will review the IANA registries as
> they are today and request whatever modifications needed, which may include
> changing the policies, the content, the rules, …"
> 
> 
> My interpretation of which is:
> 
> 1.	The IETF DTN WG does not have authority to obsolete a document produced
> by another organization (IRTF), so it will not do so.
> 2.	The IRTF is informed that BPbis is being standardized.  If IRTF,
> pursuant to its own deliberations, thereupon chooses to obsolete RFC5050,
> fine.
> 
> (I think the same policy would apply to TCPCLv3.)
> 
> I think this can be clearly communicated in the BPv7 specification, and I
> suspect it may be the only way to achieve the objectives of the WG and move
> forward.
> 
> Scott
> 
> -----Original Message-----
> From: dtn <[email-masked]> On Behalf Of Magnus Westerlund
> Sent: Friday, November 29, 2019 1:07 AM
> To: [email-masked]; magnus.westerlund=[email-masked]; 
> [email-masked]; [email-masked]
> Subject: [EXTERNAL] Re: [dtn] I-D Action: draft-ietf-dtn-tcpclv4-16.txt [AD-
> INT]
> 
> Rick,
> 
> It was discussed and the meetings consensus was to obsolete it. Until you have
> confirmed it on the WG mailing list, it is not yet a WG consensus, so please
> run that consensus call. 
> 
> Cheers
> 
> Magnus
> 
> 
> On Wed, 2019-11-27 at 11:03 +0000, Taylor, Rick wrote:
> > [ AIRBUS DEFENCE AND SPACE INTERNAL ]
> > Magnus,
> > 
> > The consensus of the WG is to obsolete BPv6 and by extension TCPCLv3.
> > 
> > Let's try not to keep going around this buoy ;)
> > 
> > Rick
> > 
> > 
> > 
> > THIS DOCUMENT IS NOT SUBJECT TO EXPORT CONTROL.
> > 
> > -----Original Message-----
> > From: dtn [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> > Sent: Wednesday, November 27, 2019 9:40 AM
> > To: [email-masked]; [email-masked]
> > Subject: Re: [dtn] I-D Action: draft-ietf-dtn-tcpclv4-16.txt
> > 
> > On Tue, 2019-11-26 at 19:26 +0000, Brian Sipos wrote:
> > > Magnus,
> > > I've asked for a SECDIR review of last changes to the draft.
> > > 
> > > The port assignee and contact being the IESG makes sense to me and I 
> > > will update the draft to reflect this.
> > > 
> > > The use of two reference RFCs doesn't make sense to me, though, and 
> > > I don't see any examples of this in the current IANA registry. The
> > > TCPCLv4 supersedes
> > > v3 and is entity-level interoperable with v3. The RFC-TBA also 
> > > references
> > > RFC7242 internally, so if the IANA port registration of just RFC-TBA 
> > > will allow someone to trace back to RFC7242 if they need to. Seeing 
> > > one port with two separate protocol versions in the reference seems 
> > > confusing.
> > 
> > So my goal here was that there would be clear that there might be 
> > multiple different versions using this particular port.
> > 
> > What was confusing me here and lead me down the reasoning that both 
> > should be listed was the expectation that BPv6 and its usage of 
> > TCPclv3 would not be directly obsoleted, and definitely not disapear 
> > from usage. Re-reading the IANA section and looking at this document I 
> > think it is clear that if you actually go look in this docuemnt, you 
> > can figure out that TCPclv3 may also be used on this port. Thus, a 
> > single reference is fine with me after this additional consideration.
> > 
> > And if we are back to having BPv7 obsolete BPv6, then I think having 
> > this direct obosletion is fine. If we are not having the first, this 
> > document's obsoletion of TCPclv3 needs another thought. I note that we 
> > have not been consistent in our actions due to the obsoletion discussion.
> > 
> > Cheers
> > 
> > Magnus
> > 
> > 
> > 
> > > 
> > >  From: Magnus Westerlund
> > > Sent: Monday, November 25, 2019 04:27
> > > To: [email-masked]; Brian Sipos
> > > Subject: Re: [dtn] I-D Action: draft-ietf-dtn-tcpclv4-16.txt
> > > 
> > > Hi Brian,
> > > 
> > > Can you please try to get feedback on the update from the Secdir 
> > > reviewer, or if you already have, it provide a pointer to that.
> > > 
> > > Anyway, looking at the update I did find an issue we need to fix. 
> > > 
> > > In Section 9.1 the Update to the dtn-bundle TCPCL port registration. 
> > > 
> > > As this is an IETF protocol now, the assigne should be:
> > > 
> > > IESG <[email-masked]>
> > > 
> > > IESG have had some discussion about the contact person and if that 
> > > also should be the IESG, the WG or an individual. The argument for 
> > > making it to IESG is that it likely to be more long term stable that 
> > > the other options. But, this is more open to discussion, so consider 
> > > what makes most sense long term and use that.
> > > 
> > > When it comes to references I think there is a point to list both 
> > > the RFC-TBA as well as RFC7242 that defines the earlier version. 
> > > But, please list RFC7242 after this docuemnt.
> > > 
> > > Cheers
> > > 
> > > Magnus
> > > 
> > > 
> > > 
> > > 
> > > On Fri, 2019-11-22 at 22:18 +0000, Brian Sipos wrote:
> > > > All,
> > > > This latest draft of TCPCLv4 addresses comments from SECDIR review 
> > > > and IANA review. It does not change any of the messaging 
> > > > structure, only clarifies behaviors related to TLS use and 
> > > > sequencing, and fixes some contradictory text.
> > > > From: dtn <[email-masked]> on behalf of 
> > > > [email-masked] < [email-masked]>
> > > > Sent: Friday, November 22, 2019 17:04
> > > > To: [email-masked] <[email-masked]>
> > > > Cc: [email-masked] <[email-masked]>
> > > > Subject: [dtn] I-D Action: draft-ietf-dtn-tcpclv4-16.txt
> > > >  
> > > > 
> > > > A New Internet-Draft is available from the on-line Internet-Drafts 
> > > > directories.
> > > > This draft is a work item of the Delay/Disruption Tolerant 
> > > > Networking WG of the IETF.
> > > > 
> > > >         Title           : Delay-Tolerant Networking TCP Convergence
> > > > Layer
> > > > Protocol Version 4
> > > >         Authors         : Brian Sipos
> > > >                           Michael Demmer
> > > >                           Joerg Ott
> > > >                           Simon Perreault
> > > >         Filename        : draft-ietf-dtn-tcpclv4-16.txt
> > > >         Pages           : 63
> > > >         Date            : 2019-11-22
> > > > 
> > > > Abstract:
> > > >    This document describes a revised protocol for the TCP-based
> > > >    convergence layer (TCPCL) for Delay-Tolerant Networking (DTN).  The
> > > >    protocol revision is based on implementation issues in the original
> > > >    TCPCL Version 3 of RFC7242 and updates to the Bundle Protocol
> > > >    contents, encodings, and convergence layer requirements in Bundle
> > > >    Protocol Version 7.  Specifically, the TCPCLv4 uses CBOR-encoded BPv7
> > > >    bundles as its service data unit being transported and provides a
> > > >    reliable transport of such bundles.  Several new IANA registries are
> > > >    defined for TCPCLv4 which define some behaviors inherited from
> > > >    TCPCLv3 but with updated encodings and/or semantics.
> > > > 
> > > > 
> > > > The IETF datatracker status page for this draft is:
> > > > https://datatracker.ietf.org/doc/draft-ietf-dtn-tcpclv4/
> > > > 
> > > > There are also htmlized versions available at:
> > > > https://tools.ietf.org/html/draft-ietf-dtn-tcpclv4-16
> > > > https://datatracker.ietf.org/doc/html/draft-ietf-dtn-tcpclv4-16
> > > > 
> > > > A diff from the previous version is available at:
> > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dtn-tcpclv4-16
> > > > 
> > > > 
> > > > Please note that it may take a couple of minutes from the time of 
> > > > submission until the htmlized version and diff are available at 
> > > > tools.ietf.org.
> > > > 
> > > > Internet-Drafts are also available by anonymous FTP at:
> > > > ftp://ftp.ietf.org/internet-drafts/
> > > > 
> > > > _______________________________________________
> > > > dtn mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/dtn
> > > > _______________________________________________
> > > > dtn mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/dtn
> > 
> > --
> > Cheers
> > 
> > Magnus Westerlund
> > 
> > 
> > ----------------------------------------------------------------------
> > Networks, Ericsson Research
> > ----------------------------------------------------------------------
> > Ericsson AB                 | Phone  +46 10 7148287
> > Torshamnsgatan 23           | Mobile +46 73 0949079
> > SE-164 80 Stockholm, Sweden | mailto: [email-masked]
> > ----------------------------------------------------------------------
> > 
> > 
> > This email and its attachments may contain confidential and/or 
> > privileged information.  If you have received them in error you must 
> > not use, copy or disclose their content to any person.  Please notify 
> > the sender immediately and then delete this email from your system.  
> > This e-mail has been scanned for viruses, but it is the responsibility 
> > of the recipient to conduct their own security measures. Airbus 
> > Operations Limited is not liable for any loss or damage arising from the
> > receipt or use of this e-mail.
> > 
> > Airbus Operations Limited, a company registered in England and Wales, 
> > registration number, 3468788.  Registered office:  Pegasus House, 
> > Aerospace Avenue, Filton, Bristol, BS34 7PA, UK.
> > _______________________________________________
> > dtn mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dtn
> 
> --
> Cheers
> 
> Magnus Westerlund 
> 
> 
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: [email-masked]
> ----------------------------------------------------------------------
> 
> 
-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, 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: Tue, 3 Dec 2019 20:13:46 +0000

+1 to Scott's analysis.

> From: dtn [mailto:[email-masked]] On Behalf Of Burleigh, Scott C (US 312B)
> Sent: Friday, November 29, 2019 3:35 PM
> To: Magnus Westerlund <magnus.westerlund=[email-masked]>; [email-masked]; [email-masked]; BSipos@rkf-
> eng.com
> Subject: Re: [dtn] I-D Action: draft-ietf-dtn-tcpclv4-16.txt [AD-INT]
> 
> Okay, wait.  If the consensus that was reached at the meeting is not the final consensus, despite direct contemporaneous IESG input,
> and we therefore have to go back to the WG mailing list again for a final decision, then I strongly suspect we will once again end up in a
> state of non-consensus and immobility.  I totally agree with Rick that we must stop going around this buoy, but it may be out of our
> hands:  I believe there is still significant opposition within the WG to the prospect of the BPbis specification obsoleting RFC 5050.
> 
> But if I am right, then I would urge us to drop back to the formulation that had been arduously worked out by the chairs as of 17
> October:
> 
> "RFC5050 is an experimental RFC, done in IRTF, while draft-ietf-dtn-bpbis will be a Standard track RFC, done in IETF. Different streams,
> different processes.
> 
> "We believe there is a strong consensus to not continue working on RFC5050 and not try to be backward compatible. RFC5050
> implementations and deployments can continue as they see fit.
> 
> "IANA registries have their own life, whatever the stream or type of RFC they were created from. They can always be updated by a
> new RFC.
> 
> 	1) draft-ietf-dtn-bpbis would not obsolete RFC5050. Instead we would notify IRTF that draft-ietf-dtn-bpbis is an update of
> RFC5050. IRTF will decide what they want to do, if anything, with RFC5050.
> 	2) in the new version of the charter that we are currently working on, we will state clearly that there is no intent to work on or
> make compatible work with RFC5050 and related RFCs
> 	3) DTN working group document authors will review the IANA registries as they are today and request whatever modifications
> needed, which may include changing the policies, the content, the rules, …"
> 
> 
> 1.	The IETF DTN WG does not have authority to obsolete a document produced by another organization (IRTF), so it will not do
> so.
> 2.	The IRTF is informed that BPbis is being standardized.  If IRTF, pursuant to its own deliberations, thereupon chooses to
> obsolete RFC5050, fine.
> 
> I think this can be clearly communicated in the BPv7 specification, and I suspect it may be the only way to achieve the objectives of the
> WG and move forward.
> 
> Scott
> 
> To: [email-masked]; magnus.westerlund=[email-masked]; [email-masked]; [email-masked]
> Subject: [EXTERNAL] Re: [dtn] I-D Action: draft-ietf-dtn-tcpclv4-16.txt [AD-INT]
> 
> Rick,
> 
> It was discussed and the meetings consensus was to obsolete it. Until you have confirmed it on the WG mailing list, it is not yet a WG
> consensus, so please run that consensus call.
> 
> Cheers
> 
> Magnus
> 
> 
> > > >         Title           : Delay-Tolerant Networking TCP Convergence Layer
> > > > Protocol Version 4
> > > >         Authors         : Brian Sipos
> > > >                           Michael Demmer
> > > >                           Joerg Ott
> > > >                           Simon Perreault
> > Operations Limited is not liable for any loss or damage arising from the receipt or use of this e-mail.
> >

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Tue, 3 Dec 2019 20:42:34 +0000

Magnus, where is the agreed-upon process for having an IETF document obsolete an IRTF document now documented?  Is there an I-D?

Scott

-----Original Message-----
From: Magnus Westerlund <magnus.westerlund=[email-masked]> 
Sent: Monday, December 2, 2019 5:19 AM
To: Burleigh, Scott C (US 312B) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: [EXTERNAL] Re: [dtn] I-D Action: draft-ietf-dtn-tcpclv4-16.txt [AD-INT]

3.2. Session venue

Cheers

Magnus Westerlund

-- 
Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 4 Dec 2019 10:00:21 +0000

On Tue, 2019-12-03 at 20:42 +0000, Burleigh, Scott C (US 312B) wrote:
> Magnus, where is the agreed-upon process for having an IETF document obsolete
> an IRTF document now documented?  Is there an I-D?
> 

So the important IRTF part do exist here: 

https://irtf.org/policies/cross-stream-updates.html

That policy is in effect as the IRSG has approved it. So the IETF side is only
to ensure that the approval is requested prior to approviding the document. 

Cheers

Magnus

> To: Burleigh, Scott C (US 312B) <[email-masked]>; [email-masked];
-- 
Cheers

Magnus Westerlund