Subject: Re: [dtn] [EXTERNAL] Last Call: <draft-ietf-dtn-bpbis-17.txt> (Bundle Protocol Version 7) to Proposed Standard

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Thu, 25 Jun 2020 18:24:23 +0000

Hello.  I am well aware that most of us are working from home under less-than-ideal conditions due to the COVID-19 pandemic, so everything can be expected to take longer than usual.  I'd just like to ping the WG once again on this IESG review, which began on October 29 of last year and which goes to the fundamental purpose of the Working Group.  Responses to all comments on the BPbis draft from IESG members have been posted in emails and/or reflected in updated versions of the draft, but most points of discussion have not yet been resolved.  What is our next step?

Scott

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Tuesday, October 29, 2019 6:54 AM
To: IETF-Announce <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Fred Templin <[email-masked]>; [email-masked]; [email-masked]
Subject: [EXTERNAL] Last Call: <draft-ietf-dtn-bpbis-17.txt> (Bundle Protocol Version 7) to Proposed Standard

The IESG has received a request from the Delay/Disruption Tolerant Networking WG (dtn) to consider the following document: - 'Bundle Protocol Version 7'
  <draft-ietf-dtn-bpbis-17.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [email-masked] mailing lists by 2019-11-12. Exceptionally, comments may be sent to [email-masked] instead. In either case, please retain the beginning of the Subject line to allow automated sorting.

Abstract

   This Internet Draft presents a specification for Bundle Protocol,
   adapted from the experimental Bundle Protocol specification
   developed by the Delay-Tolerant Networking Research group of the
   Internet Research Task Force and documented in RFC 5050.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dtn-bpbis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dtn-bpbis/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 29 Jun 2020 12:33:53 +0000

Hi,

Unfortunetely the blame goes around a bit on me as AD, and on the Chairs etc to
not be able to conclude on some of these issues. So from a high level I think
the situation looks like this for BPbis:

Alvarao's discuss: 

The update of the registration rules to Standards Action policy prevents future
IRTF registrations in the DTN related registries that are updated by BPbis. This
issue I think can be resolved in either of two ways:

1. WG makes it clear that they have consensus for this tightening and I assuming
that sufficient amound of the more DTN research folks are active in this WG to
state their position. or,

2. We change the policies to Specification required with expert verifying
reasonable use of the code points. The expert guidance would then be included in
the specification stating what the WG consider appropriate usage.

Mirja's Discuss: The one on congestion control is resolved with a requirement on
the Convergance Layer. 

The second one has been reworded and I am fine with implementation aspect of
this issue. So I will clear the parts that are related to Mirja's discuss.

IANA's Issue: To my understand IANA are satisfied assuming that the last 2
editorial edits are done. 

Thus, I should be able to clear as soon as the last change are done.

This leaves Benjamin's discuss:

1) Mandatory to implement BPSec: The issue for this one is that a protection
profile needs to be normative reference. We are also lacking automatic key-
exchange for this, but I believe the Sec ADs are ok with this on the WGs ToDo
list. However, I am not yet certain that the WG are okay with this.

Issues 2), 3) 4), 5), 10)  all have proposals for them but the WG reactions have
been minimal on the several version published. 

Issues 6, 7, 8, 9 was answered in eamils.

When it comes to Issue 10, I think it would be good to make 10.6 clearer that
values above 255 are open for private usage?

I do wonder if not a First Come First Service for the values above 255 would
make sense. 

So to conclude I think most issues are either resolved or have proposed fixes.
What is missing is WG consensus on these changes as they have significant
impact. 

Cheers

Magnus

On Thu, 2020-06-25 at 18:24 +0000, Burleigh, Scott C (US 312B) wrote:
> Hello.  I am well aware that most of us are working from home under less-than-
> ideal conditions due to the COVID-19 pandemic, so everything can be expected
> to take longer than usual.  I'd just like to ping the WG once again on this
> IESG review, which began on October 29 of last year and which goes to the
> fundamental purpose of the Working Group.  Responses to all comments on the
> BPbis draft from IESG members have been posted in emails and/or reflected in
> updated versions of the draft, but most points of discussion have not yet been
> resolved.  What is our next step?
> 
> Scott
> 
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; Fred Templin <[email-masked]>; 
> [email-masked]; [email-masked]
> The IESG has received a request from the Delay/Disruption Tolerant Networking
> WG (dtn) to consider the following document: - 'Bundle Protocol Version 7'
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the 
> [email-masked] mailing lists by 2019-11-12. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
-- 
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]
----------------------------------------------------------------------