Minutes IETF106: dtn
minutes-106-dtn-00

Meeting Minutes Delay/Disruption Tolerant Networking (dtn) WG
Title Minutes IETF106: dtn
State Active
Other versions plain text
Last updated 2019-12-19

Meeting Minutes
minutes-106-dtn

IETF DTN Working Group Minutes
November 21st, 2019
IETF106, Singapore
Chairs: Marc Blanchet & Rick Taylor
================================================================================

Administrativia
--------------------------------------------------------------------------------
- Notewell noted.
- Ed Birrane and Adam Wiethuechter will take notes.
- Light agenda: BPbis, BPSec, BIBE, New Charter

Agenda Bashing
--------------------------------------------------------------------------------
- No changes.
 


YouTube link to proceedings:
--------------------------------------------------------------------------------
https://www.youtube.com/watch?v=DjN_DuWW8vw



ACTIONS
--------------------------------------------------------------------------------

0. Chairs to ask mailing list what to do with MTCP-CL. 
1. S. Burleigh to take to list discussion on BP time.
2. S. Burleigh to add experiental/private area for IANA registrations in BPbis.
3. R. Taylor to take new charter items to mailing list.
4. DTNWG chairs to post final call for RFC5050 obselescence to mailing list.



Questions (Q), Answers (A), and Comments (C):


Presentation 1: Document Status (Rick Taylor)
-------------------------------------------------------------------------------
- 3 documents being worked on (BPbis, BPSec, TCPCLv4)
- BPbis
	* Waiting on OPSDIR and SECDIR reviews.
- TCPCLv4: 
	* Updating initial work from IRTF. OPSDIR said fine, some typos. 
    * SECDIR had comments, mostly on certificate revocation. Also on option
      to not require TLS (may be attack surface, believe we addressed this
      and waiting for SECDIR response). 
    * Waiting for GENART review.
- BPSec:
	* Marked as on-hold pending normative reference for BPbis.
	* No major issues identified.
	* Waiting for SECDIR review. 



Presentation 2: Virtual Interim Report (Rick Taylor)
-------------------------------------------------------------------------------

- Held to ensure progress on 3 key documents.
- Debate on how to mark RFC5050 - does ZBPbis obsolete RFC5050?
	* Some politics and admin around versioning and support.
	* BPv6 ownbed by IRTF
	* Chairs/AD took action to work with IRTF to understand how to mark RFC5050
- What is to be included in the recharter
	* Ambitious initial list - is there energy to do all of this?
- Other items
	* What to do with Minimal TCP (MTCP) Convergence Layer (CL).
	* Is this needed now that TCPCLv4 in the IESG pipeline?


(C) S. Burleigh: MTCP is simple/small enough spec that it is not a big workload,
                 but no need to push if not needed.

(Q) R. Taylor: Who has read MTCP or TCPCLv4?  

Very few hands in room

(C) R. Taylor: Will take to the list. 



Presentation 3: BPbis GENART last call review (Scott Burleigh)
-------------------------------------------------------------------------------
- Worked through slides. 20-or-so-slides brought up by reviewer (Stewart Bryant)
	* Discussed items as follows.

- Not DTNWG job to obsolete RFC5050 - called out in BPbis Intro/abstract.

(C) M. Westerlund: Be careful with term "Update". Used differently in IETF. 
                   Maybe say revision. 

(C) R. Taylor: Consensus was to recommend to IRTF that they obsolete RFC5050.
               Chair at time (Colin Perkins?) seemed ok with this.

(C) M. Kühlewind: Expect IRTF would obsolete. If you want to have this doc
                  obsolete, you should do it now. We have process for this.

(C) S. Burleigh: I would need help with that text.

(C) M. Kühlewind: Add text that this obsoletes RFC5050. As part of publishing,
                  IRTF will obsolete RFC5050. 

(Q) S. Burleigh: If we obsolete RFC5050 will it obsolete RFCs that rely on it?

(A) M. Westerlund: No. You can be specific on what is obsoleted.

(C) S. Burleigh: I can put text in that obsoletes RFC5050, merge values to 
                 prevent conflict with RFC5050 registries. 

- Use BPSec if you want more capability than CRC provides.

- Remove manifest block from BPbis (as not defined yet). Remove all referenced
  tp anticipated-but-not-created blocks. 

- Simplify to monotonically-increasing time system: # seconds since 2000 UTC.

(C) M. Westerlund: SHALL is same as MUST. A shall is not needed here, just
                   say it is represented as a CBOR integer. Not necessary for
                   all such SHALLs. It is a minor point.

(Q) M. Westerlund: How are leap seconds counted?

(A) S. Burleigh: It doesn't. Just counting seconds. DTN time isn't a UTC time,
                 it is a count from a UTC point in time. 

(C) M. Westerlund: Shoudl continue this on the mailing list.


- BIBE references an Internet draft.

(C) R. Taylor: Make it an informative reference.

(C) M. Kühlewind: No issue referencing a draft if not normative.

- Remove all security material and point to BPSec.

- Namespace vs registry terms

(C) M. Westerlund: Do not change term to namespace - you are correct to use
                   registry. Just make sure the registry name you use is the
                   same as what is in IANA. 

- Change new allocations to IANA assigned.

- Referenced to RFC5050

(C) M. Westerlund: IANA section is RFC5050 merged with RFC-to-be. 

(C) M. Kühlewind: Fine as long as definitions not repeated.

- Why no experimental or private use? 

(C) R. Taylor: Values 21-63 unassigned. Could redefine area.

(C) S. Burleigh: Will add handful: Maybe 8, to top end of spectrum.

- Updated BPSec reference and others as needed. Time references not needed.

- No license issue with CDDL, it is not code but format description.

- Should we have more info for URI scheme types?

(C) M. Westerlund: Section 10.6 in bpbis-17. only 0 and 255 reserved. Not issue.  
                   Do not need larger # reserved. If we run out we can handle it
                   and unlikely to happen.

(C) S. Card: Also see "reserved for future standard action". 

(C) R. Taylor: Whole 8 bits is under standasrd track control. You need a
               standards track document to get a value.

(C) M. Westerlund: You need a URI scheme to start with, so needing a doc is
                   reasonable. 

- Revisit use of contraindicated

(C) M. Westerlund: Simplify if you can. 

(C) S. Burleigh: Will leave to copy editors. 


Presentation 3: BPSec Updates (Ed Birrane)
-------------------------------------------------------------------------------

- Discussed BPSec updated and throughts on security contexts and node roles.

- Decided to use terms "Security verifier" and "security acceptor".


Presentation 4: Bundle-in-bundle Encapsulation (BIBE) (Scott Burleigh)
-------------------------------------------------------------------------------

- Brief update on BIBE by S. Burleigh.


Presentation 5: New Charter Topics (Rick Taylor)
-------------------------------------------------------------------------------

- Review of charter topic list.

(C) E. Birrane: Willing to work AMA/ADM/AMP and manifest block.

(C) R. Taylor: Existing naming schemes simple. Need a more global DTN scheme.

(C) S. Burleigh: Committed to BIBE. Also naming/addressing. There is an
                 experimental RFC for neighbor discovery. ION implements
                 opportunistic forwarding based on contact-graph routing. Also
                 willing to work Wuality of Service. 

(Q) R. Taylor: Question from AD: what does the WG want to prioritize?

(C) S. Card: Interested in naming/addressing and mapping EIDs to other ID
             spaces. Also looking at NORM and SMTP convergence layers. Also
             network coding RG wants to support DTN. And prophet extention 
             block.

(Q) R. Taylor: Is author of prophet extension block here?

- no

(C) A. Whitaker: Willing to review some work.

(C) S. Card: naming/addressing should be a priority. 

(C) R. Taylor: Will taker other items to list.