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.