IETF 111 DTN working group meeting

Monday 2021-07-26 19:00 - 21:00 (UTC)

Co-chairs: Rick Taylor, Ed Birrane

Name Shorthands:
- AD Zaheduzzaman Sarker == adZS
- Rick Taylor == RT
- Rick Taylor (Chair) == cRT
- Ed Birrane == EB
- Ed Birrane (Chair) == cEB
- Adam Wiethuechter == AW
- Adam Wiethuechter (Secretary) == sAW
- Scott Burleigh == SB
- Oscar Garcia == OG
- Sarah Heiner == SH
- James Annis == JA
- Brian Sipos == BS

Official YT Recording:
https://www.youtube.com/watch?v=sFkSylvDOYs

Agenda

cRT:
- Welcome all! Introductions and what not.
- Agenda overview, administivia notes
- Please help with the minutes!
- Main activities on mailing list, please subscribe.

cEB:
- Spent first half on interim trying to lay out next work for recharter
- Break things into categories to help explain to many why several things would not overwhelm those involved
- DTNRG items for refresh, Extensions to new work, New algos/protocols
- Best guess, can change with reviews
- Break down of tasks based on these categories
- DTNRG: LTP would be worked on by CCSDS, custody transfer
- Will not solve Naming and Addressing; can be 20 year long task
- Anyone have anything to add
cRT:
- Alternative methods of relability as a light weight version of custody transfer?
- Worth being more generic item instead of explicit?

SB:
- Term and concept from JPL ages ago
- As the data makes way through network each forwarding point would say, you can let it go ill take it from here - it works from end to end
- BPv6 used by ????
- Seperate but not in conflict, aggregated status reports
- Suggest custody transfer as a work item would be avoided instead focus on concept

cRT:
- So work on bundle reliability

SB:
- Feli idea is more about signalling

cRT:
- So sounds no interest in BPv6 custody transfer and trying to forward port to BPv7

cEB:
- Good ppoint. Not removed from ecosystem

SB:
- another other relability tcl like v4 would accomplish same thing

cRT:
- disagree, a reliable CL would across one hop, but end-to-end without knowing CLs between you

SB:
- Multihop problem is mission creep for custody transfer
- If you don't know who gets how do you set things?
- Concern is what is requirements and how to be addressed

cRT:
- Remove "Custody Transfer" as loaded with BPv6 conotation in WG

OG:
- ???

RT:
- Use case is one DTN should be addressing
- BPv6 CT had known problems
- New methods to perform same actions

FT:
- Coming in late. What was verdict on LTP?

cEB:
- No. CCSDS wants to standardize and in their charter.

cRT:
- If another SDO wants to do work fine
- Very space focused

FT:
- Also seeing apps in terresterial domain
- Vaible in disrupted envirorments

cRT:
- FT do you have a draft for this? I think so

FT:
- ???

cRT:
- Builds on top of LPT implementation
- BPv7 and bringing LPT would be willing
- Do we need to laison with CCSDS?

cEB:
- How much work would it be for a CL for LPT in this WG?

cRT:
- Split problem in two. CCSDS, go for it. We will focus on CL using LPT as underlying protocol.

SB:
- Likes that idea a lot. Using LPT to support BP CL belongs here.
- Fine to take on LPT standardization, but would be tricky with CCSDS interactions
- Suggests the split as RT pointed to

cRT:
- Comments on other things on charter?
- Added Neighbor Discovery, Service IDs merged into Naming/Addressing
- Anything else to include?
- They will be focus on WG, any other I.D.s not in scope could be ignored

cEB:
- Covered very well.
- As we adopt drafts its to map things in charter

cRT:
- We missed key management.
- SB, FT do you have cycles or willing to pass?

SB:
- Very invested in WG takes it up

FT:
- Also shares interest

cRT:
- Very happy to peer review
- Made note of that.

EB:
- Pacakge of documents ofr standardization of BPv7
- In course of review, requested to have default security contexts
- Started to interopability ones, to be defaults
- Coming out of IESG review
- Vast amount of changes most for reader understanding, non-technical
- Needed to be more specific with some security things

adZS:
- Sorry for being late!
- Working to catch up

cRT:
- Thanks to all reviewers!

EB:
- CDDL with unadorned CBOR sequences ???
- Tons of work, thanks everyone who helped.

SH:
- Hello! I work at JH APL
- Next steps for BPsec
- Need to develop security policy and its architecture
- Design principles
- Needs semantic and syntactic interop
- Need to be effecient, due to constraints
- Block granularity
- Node customability
- Data model
- Security policy rules; filter, spec, event
- Operation Events; are there any missing?

OG:
- Processing this on bundle not the content of the bundle?

SH:
- Some processing of contents, representation of security blocks; mainly to see if they exists or not

OG:
- My concern: stucture should be complete and trustful

cRT:
- What I think Sarah is doing is this: bundle contains metadata + payload
- Her work is focusing on metadata portion

SH:
- Event Sets, hold multiple events
- Naming allows them to be cited
- Processing actions
- slide 11; left column is Events, all others are Actions

cRT:
- Bundle/block manipulation means?
- Editing in flight?

SH:
- In next slide. WE modify bundle transmission or its contents
- Blocks are modifying block procssing
- Data generation: for later analysis
- Comments on processing actions?
- Initial implementation in ION
- APL added in 4.0.2 release

cRT:
- Thank you! Fascinating.
- Is policy in-band or out of band?
- Have you considered if policy be attached to bundle?

SH:
- Hybrid approach to policy
- Some on node, some as parametersin security block
- Need to take some data going through bundle

cRT:
- Genrealize beyond sec. policy? AMP, ADM system as management?
- Avoid corruption or misconfiguration

SH:
- Would be useful - there are other directions to take this.

OG:
- interfacing, thank you!

cEB:
- informational rfc? normative?
- Can it be generalized to be used by many implementations?
- What is future of this work for WG?

cRT:
- If this is WG item, what is it standardizing?
- Hybrid solution is normative
- Charter items, feature creep...

SB:
- Same feeling, if required spec of protocol between interoperable implementations protocol spec would be straight forward
- Information RFC seems best

cRT:
- We do standardize best practice documents
- This could be considered best practice for DTNs
- Take discussion to list?

cEB:
- If it standards and enumarates things IANA? Would informational RFC allow this?

cRT:
- Jumping the gun!
- If links to ADN then it is on charter!

EB:
- That is brilliant, thank you!

cRT:
- "I am not brilliant, don't call me that"

JA:
- "Almost like Zoom!"
- AMA concept is in work today, open source and commercial, push through next step
- Review AMA; manager send controls to agents and waits for reports back
- Where we are today:
- went through WGLC, could it be more?
- What do we do to do this?
- AMA for IoT in smart city
- Scope function of autonomy
- Federate control (actor to actor)?

cRT:
- This sounds little bit like reopen AMA document, take out of WGLC, to revist more than just management of network

cEB:
- This is one comment that came out of WGLC. Simply remove network and doesn't change much.

cRT:
- Preempt ZS: Yes, we have been around NETMOD, NETCONF and have had no interest.

adZS:
- Mind read == Mind blown.
- Want to look at bigger scope, this has to go through some more things

cRT:
- We are happy to.

adZS:
- if beyond DTN, this has to go couple place again

cEB:
- When outside of DTN we talk about application on ethernet
- When we talk to others its so different, they would rather provide review after the face

adZS:
- If you want to open up here thats fine but need to cross-check

cEB:
- Understood

cRT:
- Can it be fixed without removing it out of last call?

JA:
- Here and ready. Clarifcations mostly.

cRT:
- Do you a deal.
- Freeze call on AMA, review/fix and reopen LC nice and long
- Last of current charter items needed to be done

JA:
- To make this work is addressing objects in network and parameters in network. Many different ADMs for each agent
- Extract and address in new rfc how to ....
- Both drafts say should be done, but not how
- Need to represent namespaces and nicknames

cEB:
- if we want to register uri schema, then would we produce small graph?

cRT:
- registering scheme is easy
- ADM section should include uri spec? stand alone seems strange

OG:
- ???

cEB:
- Take to mailing list.

cRT:
- Agree. Need to review some things (YANG, NETCONF)

OG:
- IPNSIG group lead
- Working with several topics.
- Ronny Bull of Utica College has been helping
- Working on a test plan starting Sept. 2020
- Review of recent accomplishments...
- Requirements and goals...

cRT:
- Very interesting!

cRT:
- Anything?

BS:
- Status on ACME, last week passed AD review
- points on URI naming and issues with admin type record
- AD not happy with info rfc updating sdt rfc

RT:
- WebPack, bundling HTTP requests together, suggest poking head in
- Might be looking for transport to move bundles...

cEB:
- Thanks everyone!

cRT:
- Lots of interesting topics, lets get charter done
- Will work with ZS to get signed off and sealed
- Thanks everyone!
- "I now declare this meeting over."