Area/Group Details

Area: INT
Area Director: Tommy Jensen
Working Group: Delay/Disruption Tolerant Networking (DTN)
Chairs: Ed Birrane, Rick Taylor
Secretary: Adam Wiethuechter

Session 1

Meeting: IETF 126 - Vienna
Session: Monday I (120 minutes)
Date/Time (UTC): 20 JUL 2026 / 07:00 - 09:00

AI Generated (src=ietfminutes.org)

1. CoAP over BP

Presenter: Carles Gomez
Slides: CoAP over BP

• Status & Updates: Carles Gomez presented revision 04, which
  resolves review comments from Marco Davids. Notable updates include
  clarifying that the maximum aggregation delay parameter is
  independent of confirmable (CON) or non-confirmable (NON) message
  types, and security considerations regarding the promotion of the
  payload length option from Class U (unprotected) to Class E
  (encrypted/integrity-protected) using hop-by-hop OSCORE with
  OSCORE-capable proxies.
• Implementation: Carles Gomez noted that UPC has an existing
  implementation that will be updated to conform to the latest version
  of the draft.
• Discussion:
  • The CoAP Working Group chairs plan to declare version 04 stable
    to implement.
  • Rick Taylor raised a concern regarding the mention of
    .dtn.arpa as a URI scheme, noting that the working group's
    understanding of DTN EIDs beyond RFC 9171 is limited and its
    interaction with DNS is an open question. He suggested removing
    the reference to .dtn.arpa to avoid stalling the draft, while
    retaining .ipn.arpa. Carles Gomez agreed that this was a
    reasonable approach.
  • The chairs suggested initiating a Working Group Last Call (WGLC)
    once the UPC implementation is verified as fully conformant to
    the latest draft.

2. Sipos Individual Drafts

Presenter: Brian Sipos
Slides: Sipos individual drafts

DTN Manifest Block

• Status & Updates: This draft defines a way to take a
  cryptographic "snapshot" of a bundle's blocks at a specific point in
  time to support the Secure BP Audit Mechanism (S-PAM) and transit
  network preservation. Version 01 splits out the encoding structure
  (purpose code, block identity, and metadata map) to avoid dependency
  on CBOR map encoding order and adds a key identifier to the security
  block processing based on S-PAM feedback.
• Discussion:
  • Rick Taylor suggested adding a flag in the primary block to
    indicate the presence of a manifest block, helping to detect
    man-in-the-middle attacks where a manifest block is stripped
    entirely.
  • Brian Sipos noted that enforcing the presence of a manifest
    block is best handled via out-of-band policy/configuration since
    in-band signaling can still be manipulated.
  • Edward Birrane asked whether the manifest is a snapshot of
    source blocks or expected destination blocks. Brian Sipos
    clarified it represents a snapshot of selected blocks at the
    moment the manifest is added, and multiple manifest blocks can
    coexist.

Security Associations Key Exchange (SAFE)

• Status & Updates: Brian Sipos presented the SAFE draft, which
  defines an in-band key agreement protocol using ephemeral
  Diffie-Hellman over COSE (EDHOC) to establish and upkeep symmetric
  keys. It is designed to support unilateral, out-of-band rekeying by
  the content key owner. It is forward-compatible with the COSE
  security context defined in draft-ietf-dtn-bpsec-cose.
• Discussion:
  • Erik Klein expressed support for adoption, comparing SAFE's role
    in BPsec to IKEv2's role in IPsec.
  • Edward Birrane requested that Brian Sipos formally ask for
    adoption on the mailing list to initiate a Working Group
    adoption call.

3. BPv7 Echo Service

Presenter: Rick Taylor
Slides: BPv7 Echo Service

• Status & Updates: Rick Taylor presented revision 01 of the BP
  echo service, which standardizes "ping" behavior over BP. The draft
  was redesigned from an overengineered "reflector" model in v00 to a
  simple request-response wire contract. The responder creates a new
  independent bundle with a fresh timestamp and must preserve the
  payload exactly.
• Interoperability: The service has been successfully
  interoperated across several implementations (uD3TN, dtn7-rs, HDTN,
  dtn-me, ION, ESA BP, and CFS BP).
• IANA Request: The draft requests the registration of IPN service
  number 128 (the lowest public reservable IPN service number).
• Discussion:
  • Edward Birrane suggested adding a security consideration
    regarding how the inclusion of extension blocks on ping requests
    can be used to probe network capabilities and verify processing
    behaviors of intermediate BPAs.
  • Brian Sipos and Edward Birrane recommended adding an operational
    considerations section.
  • Scott Burleigh suggested explicitly excluding pings sourced from
    a null endpoint to prevent amplification and Denial of Service
    (DoS) attacks. Rick Taylor confirmed this is already excluded in
    the draft.
  • Rick Taylor will request Working Group adoption on the mailing
    list.

4. Bundle-in-Bundle Encapsulation (BIBE)

Presenter: Rick Taylor (as individual contributor; chaired by Edward
Birrane)
Slides: Bundle-in-Bundle Encapsulation (BIBE)

• Status & Updates: Rick Taylor presented a proposal to resurrect
  the expired BIBE work, renaming and rescoping it to focus
  exclusively on encapsulation and segmentation (excluding custody
  transfer).
• Motivation: The core motivation is the formal deprecation of
  Application Data Unit (ADU) fragmentation defined in RFC 9171, which
  is fundamentally incompatible with Bundle Protocol Security (BPsec).
  Standardizing a secure encapsulation and segmentation mechanism
  allows the IETF to publish a standards-track document that
  deprecates ADU fragmentation.
• Technical Details: The draft aligns with the technical mechanics
  of the CCSDS SIS-DTN Orange Book. It utilizes a CBOR array to
  represent either a complete encapsulated bundle or a segmented chunk
  (using total length and segment offset fields). It removes windowing
  machinery and fails silently when receiving corrupted or
  unreassembled segments.
• Discussion:
  • Scott Burleigh strongly endorsed the approach and confirmed that
    CCSDS is also removing custody transfer in favor of segmentation
    and reassembly. He agreed that this document should formally
    deprecate ADU fragmentation.
  • Tommy Jensen (AD) and Brian Sipos supported the rescoping. Brian
    Sipos suggested keeping the scope tight and avoiding unnecessary
    convergence-layer consolidation.
  • Edward Birrane noted the benefits of having these technical
    discussions in the open within the IETF.
  • The proposed next step is to publish the updated text as the
    next revision of the WG document, removing "CT" (Custody
    Transfer) from the name to become draft-ietf-dtn-bp (updating
    draft-ietf-dtn-bibe-ct).

5. Reliability Considerations for DTNs

Presenter: Sabrina Pellegrini
Slides: Reliability Considerations for DTNs

• Status & Updates: Sabrina Pellegrini presented revision 02,
  which refines the architectural terminology (renaming "adaptation
  layer" to "convergence layer" [CL]) and introduces the concept of
  a "convergence layer protocol stack" representing the collection of
  protocols underneath the convergence layer adapter (CLA). Normative
  "should/shall" language was removed to align with the informational
  nature of the document.
• Architecture Discussion:
  • The presenters proposed a four-layer architecture (Application,
    Bundle, Convergence, Underlay) that groups the CLs and CLA into
    the bundle node boundary.
  • Scott Burleigh agreed that the CLA belongs inside the node, but
    questioned the practical necessity of separating the "underlay
    layer" from the "convergence layer". Edward Birrane clarified
    that this separation is useful for reasoning about scenarios
    where an unreliable underlay requires a thicker, more complex
    convergence layer stack.
  • Rick Taylor suggested that trying to strictly draw
    inside/outside node boundaries on logical architectures is
    counterproductive and warned against overengineering.
  • Edward Birrane and Scott Burleigh agreed that high-level
    architectural definitions and recursive stacking ("turtles all
    the way down") are better addressed in the ongoing revision of
    the DTN Architecture (RFC 4838-bis).
  • Brian Sipos suggested separating logical entity relationships
    and protocol stacking into two distinct diagrams to improve
    clarity.

6. DTN Access Gateway for IP Edge Networks

Presenter: Jianhao Yu
Slides: DTN Access Gateway for IP Edge Networks

• Concept: Jianhao Yu presented a boundary function to bridge
  local IP networks (which may not run the bundle protocol or
  understand DTN semantics, such as lunar surface assets) across
  deep-space DTN backbones. The gateway acts as a TCP/QUIC proxy on
  the IP side and a BPA on the DTN side, splitting the end-to-end IP
  connection into two local IP hops.

• Key Mechanisms:

  • Dynamic Bundle Payload Construction: Converts continuous
    bitstreams into bounded bundles using a shared, bounded buffer.
    Payloads are prepended with subheaders containing flow
    identifiers and offsets.
  • Contact-Aware Admission Control: Bundles are only submitted to
    the DTN side when contact storage, interval windows, and link
    capacity are available.
  • Passive Back-Pressure: When the DTN path is congested, the
    shared buffer fills, causing the gateway to pause reading from
    local IP connections, triggering standard TCP/QUIC flow control
    back to the original sender.
  • IP-to-DTN Service Mapping: Maps standard IP requests (e.g.,
    HTTP over TCP) to DTN native services (e.g., HTTP over BP, or
    HTTP GET mapped to CFDP).

• Discussion:

  • Rick Taylor praised the work and noted that it is highly
    valuable for multi-vendor interoperability. He mentioned ongoing
    work to integrate BP information into the Domain Name System
    (DNS) to assist gateways in resolving IP destinations to EIDs.
  • Brian Sipos suggested that for applications using HTTP or CoAP,
    the gateway could leverage native proxying architectures, using
    raw IP encapsulation only as a fallback.
  • Edward Birrane and Rick Taylor encouraged Jianhao Yu to submit
    an individual draft detailing these mechanisms for discussion at
    the next meeting.

7. Open Mic

• Xisen Tian introduced upcoming work on key establishment protocols
  designed for space environments. Traditional secure channels (such
  as draft-ietf-dtn-bpsec-cose) assume pre-shared keys are
  already in place.
• In high-latency or highly disrupted environments, interactive key
  exchange handshakes (like those in TLS or EDHOC) are impractical.
• Susan highlighted Messaging Layer Security (MLS) as an asynchronous
  key establishment protocol that provides useful security features
  such as post-compromise security.
• Announcement: A Birds of a Feather (BoF) session for the
  "CURRENT" group is scheduled for Tuesday at 16:30 local time. Xisen
  Tian will post the details on the DTN mailing list and present more
  details during DTN Session 2 on Thursday.

Decisions and Action Items

1. CoAP over BP:

   • Carles Gomez to update the UPC implementation to align with
     revision 04.
   • Carles Gomez to coordinate with the chairs to issue a Working
     Group Last Call (WGLC) once implementation conformance is
     confirmed.

2. Sipos Individual Drafts:

   • Brian Sipos to formally request Working Group adoption of the
     SAFE key agreement draft on the DTN mailing list.

3. Echo Service:

   • Rick Taylor to update the draft with operational considerations
     (as suggested by Brian Sipos) and security considerations
     regarding network probing via extension blocks.
   • Rick Taylor to formally request Working Group adoption on the
     mailing list.

4. Bundle-in-Bundle Encapsulation (BIBE):

   • The Working Group agreed to resurrect the expired BIBE work,
     rescoped to encapsulation and segmentation only.
   • The draft will be renamed to remove the "CT" suffix and
     published as a new revision of the active WG document sequence
     (draft-ietf-dtn-bp).

5. DTN Access Gateway:

   • Jianhao Yu to author and submit an individual internet-draft
     detailing the gateway's technical specifications for review at
     the next IETF meeting.

6. Key Establishment:

   • Xisen Tian to post details of the CURRENT BoF to the DTN mailing
     list and prepare slides for the DTN Thursday session.

Live Notes

Administrative (5 mins)

Presenter(s): Chairs
Document(s): N/A

CoAP over BP (10 mins)

Presenter(s): Carles Gomez (Remote)
Document(s): draft-ietf-core-coap-bp

Revision -04. Changes are in -03.
CoRE to declare that -04 is stable to implement.
Added OSCORE options to sec. considerations for payload-length
protection
Reviews and implementation comments welcome!

cEB: should we entertain implementation with WGLC or parallel?
Have one, but from older version. Would be great for others for interop

cEB: Do share with ML when moved forward

cRT: .dtn.arpa -- seems to be reaching concensous with ipn.arpa, wariay
of adding stuff to document introducing dtn.arpa.
cRT: Do not want to slow document to be clear.
Consider contacting DNS people?
cRT: yes, wider ongoing dicussion on how DTN/BP interacts with DNS
cEB: if there was ipn.arpa does this break anything?

Sipos Individual (10 mins)

Presenter(s): Brian Sipos
Document(s): draft-sipos-dtn-bp-safe, draft-sipos-dtn-manifest-block

Requesting feedback or advice or trial implementations on these things
Manifest Block

• Come forward with use-cases
• Mark content that need to be preserved; transit networks
• Things that goes in, and things that go out
• "chain of custody"
• SBAM for Key ID for sec. block

cEB: are you working with people with SBAM and in agreement with block
fields
cRT: may have another use-case and will contact offline. Value of
indicator in primary block, to indicate that there is one.
BS: Not currently there, makes more sense to enforce through
non-in-band. If you need something, it has to be negotaited out of band
and policy
cRT: take point, just thinking how this is handled.
BS: not harmful, what value and what does descripancy imply?
cEB/cTR: mailing list!
cEB: blocks at source or expected at dest?
BS: selected subset at time manifest is added. Snapsnot, and comparing
later.
cEB: can multiple manifests exist?
BS: yes, no problem.
cRT: that makes a PB flag complex.

BP Securty Associations with Few Exchanges (SAFE)

• This falls under key management umbrella. Lots of different topics.
  Key distribution, key agreement, key upkeep, key generations etc.
• Intentionally no distribution, etc.
• Technically complete, trial implementation
• unilateral rekey
• Feedback needed

cRT: asking for adoption?
BS: if interest, not opposed.
cRT: forward compat. with COSE CTX?
BS: Yes
RT: I will look in some depth and get implementation
EK: quick read, IKEv2 for BPSec and support adoption
cEB: can you make request on list to start adoption call?
cEB: any comment or concern for adoption?
[Jorge(Chat): interested!]

Echo Service (10 mins)

Presenter(s): Rick Taylor
Document(s): draft-taylor-dtn-echo-service

Intention to standardize "ping something over BP"
Came out of development of Hardy
Request/Response wire contract
Response is indepedent
No obligation for extension block replies

cEB: at least note that extension blocks in ping allow probe capability
of network, in sec. considerations?
RT: yes, please look at document and may want to add some text for admin
considerations. OAM WGs
BS: Good state, technically. Operational consideration for the topics
you are talking about and guidance and level of granularity for BPA
filtering.
RT: welcome contribution to get that correct.
Scott B.: exclude from null source
RT: explicity called out
EK: not just admin, operational use. might want to probe for things
(that sounds wrong how I typed it).
cRT: rough approval in room, and will ask for adoption.
EK: richer context is better left for other drafts
EK: if you want payload to be modified, for other measurement
protocols...
RT: that is a different service.
EK: BP Iperf3
cEB: any concern on adopting such a document?
[Jorge(Chat): no problem adopting]

BIBE (10 mins)

Presenter(s): Rick Taylor
Document(s): N/A

Imagine discussion, and we will come back to this at the end!
Do not intend to be contencous (help can't spell)
We have to say something on deprecation of fragmentation.
9171 fragmentation breaks BPSec, everyone understands that ADU
fragmentation must go
There needs to be an IETF document that does this deprecation formally
Proposal: update, rename NOT an adoption call
Just encapsulation, no custody-transfer.
Technical details in the open mic

SB: endorse, excellent! CCSDS orange book, is removing CT and adding
segmentation and re-assembly
RT: will do everything in orange book
SB: deprecate fragmentation in this document?
RT: yes! this document will deprecate fragemention of 9171
cEB: irony of encapsulating CCSDS work in RFC
RT: no custody?
cEB: good idea for a more open forum, and making the technical bits out

cEB: does anyone not agree with this approach?
cRT: new AD, does this seem reasonable?
adTJ: yes it does, good work on drawing the lines
BS: this all sounds great. scope defined without lose ends. Consolidate
convergence layer stuff?

Reliability (10 mins)

Presenter(s): Sabrinna Pellegrini
Document(s): draft-birrane-dtn-rel

Terminology updates with other RFCs floating around
Adaption -> Convergance Layer

cEB: does the right picture make sense?
SB: I think CLA is inside the node and invoked by BPA
cEB: CLP -> CLA in right image
SB: need to think why separate udnerlay vs converage layer
cEB: implementation, underlayer network would not give certain
relability guarentees. when low-level thicker convergence layer
SB: definitely a range at bottom of stack, naming separately means
reasoning about it differently.
RT: general agreement with scott, all of this is not implementation but
for context around discussion.
SB: recursion! constrain concept of a node is not unhelpful, turtles all
the way down
cEB: like layer respon. definition, is this discussion on layering in
4838bis?
SB: constructive idea for 4838bis!
BS: confusion, left is logical entities, while right is mixing entities
with layers. maybe do not mix them?
cRT: talking about classes, are you intending to specify these are the
ultimate classes? divison of different reliability for document? how
does this map to qos?
SP: still a discussion we are having
cRT: you will bump up against local admin policy
cEB: an idea, talk solely at BP layer. not a crisp def of custodial
behavior and custody transfer. This was an attempt at defining this.

DTN Access Gateway for IP Edge Networks (15 mins)

Presenter(s): Jianhao Yu
Document(s): draft-yu-dtn-access-gateway-ip-edge-networks

RT: this is valuable for interopability and thus standardization. IP to
BP bridges are important between vendors.
cRT: please submit this as a draft.
BS: this is good work and great presentation. if you have apps that use
http/coap you can take advantage of such proxy but drawing a dividing
line is useful for operations.
cEB: good ideas and well presented. i would ask to see a personal draft
to present at next ietf.
EB: very excited well done
Ben Roberts: very good. do you see LEO as part of relay? overall interop
of LEOs
cRT: yes there is lots looking at different combos. This tech is built
upon that infrastructure.
RT: this is useful for non-specific-later app proxies. when users say
"special ip procotol" ok we just do ip for you

Open Mic (50 mins) - actually 17 mins

Presenter(s): N/A
Document(s): N/A

cEB: any walk-on topics or others
Xisen (NRL): bringing some attention for key establishment for space,
several efforts. Want to think about how agreements for keys will occur.

Xisen: CURRENT BOF
https://datatracker.ietf.org/meeting/126/materials/agenda-126-current

BIBE Technical (Rick Taylor)

Reliability belongs to another othogonal mechanism
IP Tunneling == BIBE, good litness test
Well-known segmentation pattern like TCPCLv4 and BTPU
BS: great that technical detail is here, might be good to narrow to
observal behavior (endpoint-endpoint not node-node)
RT: "node" should be in qoutes

Session 2

Meeting: IETF 126 - Vienna
Session: Thursday II (60 minutes)
Date/Time (UTC): 23 JUL 2026 / 09:30 - 10:30

AI Generated (src=ietfminutes.org)

1. DTNMA YANG Modeling for ADM

Per Andersson presented updates on the YANG modeling work for the
Application Management Model (AMM) and Application Data Model (ADM),
focusing on updates within draft-ietf-dtn-amm and
draft-ietf-dtn-adm-yang.

• Native YANG Type Adoption: The modeling now utilizes native YANG
  statements and types wherever possible, reducing the reliance on
  custom extensions originally defined in the AMM.
• Tooling Integration: A new extension (amm:amm) has been
  introduced to signal to parser tooling that it is processing an AMM
  YANG module.
• IEEE Float Limitations: Standard YANG does not natively support
  IEEE float types (Real32 and Real64). These types must still be
  defined as custom extensions in normative text (a topic recently
  discussed in the NETMOD working group for "YANG Next").

• Collection and Map Types: Per Andersson presented
  alternatives for modeling these complex types:

  • Option A (YANG-Native): Provides declarative validation
    directly through standard tooling.
  • Option B (AnyData/Extension): Defers data validation to the
    application runtime, bypassing standard tooling validation.
  • Feedback: Rick Taylor and Edward Birrane strongly
    preferred the YANG-native approach to ensure type safety.

• YANG Union Types: Don Fettig raised a concern regarding the
  use of native YANG union types, noting that YANG validates unions
  by using the first matching type, which can lead to unintended type
  coercion. Per Andersson acknowledged that this could affect
  coercion and requires further attention.

• Externally Derived Data (EDD): Discussion occurred regarding
  whether EDD should be represented as config false
  (operational-only data). Edward Birrane clarified that while EDD
  represents sampled runtime data that is not writable within the
  model, it is not strictly equivalent to standard configuration
  states.
• Alternative Management Protocols: Javier shared that his
  team is implementing DTN management using CoreConf (and CoreConf
  M2M) over CBOR for satellite communications. He suggested this as a
  lightweight alternative to NETCONF/RESTCONF. Rick Taylor and
  Per Andersson invited him to share these findings on the DTN
  mailing list.

2. Status Updates on Working Group Drafts

Brian Sipos presented status updates on several active working group
drafts using the slide deck Sipos individual drafts.

draft-ietf-dtn-bpsec-cose (BPSec COSE Context)

• Recent Updates (v16): Added Key Derivation Function (KDF)
  context (Section 2.5.2) to resolve missing bindings, expanded
  examples, and consolidated security considerations.
• Post-Quantum Algorithms: The draft now explains how to configure
  and use the recently approved COSE algorithm for ML-DSA
  (Module-Lattice-Based Digital Signature Algorithm).
• Implementation Status: Symmetric key mechanisms have completed
  interoperability testing. A NASA-funded BPSec security library
  containing this context is scheduled for release, with
  interoperability testing commencing shortly.

draft-ietf-dtn-eid-pattern (BP Endpoint ID Patterns)

• Status: The draft is stable, complete, and has several
  independent implementations. Recent updates added concrete minimum
  implementation limits to guarantee consistent parsing behavior
  across compliant processors.
• WGLC Readiness: Rick Taylor confirmed their implementation
  is functional and supported transitioning the document to Working
  Group Last Call (WGLC). No objections were raised in the room.

draft-ietf-dtn-udpcl (UDP CL Protocol Version 2)

• Status: The protocol is stable. Recent revisions cleaned up
  terminology, clarified middlebox/firewall/NAT compatibility, and
  consolidated congestion control choices.
• Early Allocations: The draft has pending requests for IPv4 and
  IPv6 multicast addresses. Tommy Jensen (AD) confirmed he is
  investigating the criteria to facilitate early allocation for the
  working group.
• WGLC Strategy: While the draft is stable, Rick Taylor
  advised holding the WGLC briefly to allow current active
  implementations to mature and identify any lingering operational
  issues.

draft-ietf-dtn-bp-sand (BPSec Secure Advertisement and Neighborhood Discovery)

• Message Structure: The encoding was simplified. Critical
  discovery metadata has been moved to the very top of the CBOR
  byte-string structure, allowing nodes to quickly parse or skip
  advertisements.
• Routing Advertisements: Discussion occurred on whether routing
  willingness/advertisements belong in the core SAND specification.
  Rick Taylor cautioned that routing mechanisms fall outside the
  DTN working group's primary area and suggested deferring them to
  keep the core specification lightweight.
• Implementation Status: The d3tn team is beginning trial
  implementations of the updated specification.

3. Secure Bundle Asset Manifest (SPAM / SBAM)

Xisen Tian presented a proposal for end-to-end cryptographic
integrity of source-added security operations to detect modifications by
intermediate nodes.

• Mechanism: SPAM uses two mechanisms: reporting on intermediate
  node processing (drops/additions) and auditing source-created key
  information at the destination.
• Integration: In the chat, Bhagya Wimalasiri clarified that
  SBAM blocks combine the manifest block and BPSec security block
  types to construct a single logical block.
• Document Status: Revisions incorporated feedback from Edward
  Birrane, making the audit and report blocks critical and adding
  IANA considerations for key identifiers. The authors requested
  Working Group adoption.

4. Key Establishment in Space (MLS for BPSec)

Xisen Tian presented a proposal to use Message Layer Security (MLS)
as a continuous, asynchronous key agreement protocol for space networks.

• Benefits: Unlike TLS (used in QUIC handshakes), MLS is highly
  compatible with post-quantum algorithms because it amortizes
  signature overhead over long-lasting sessions. It supports
  unidirectional, asynchronous key updates and provides both forward
  secrecy and post-compromise security (PCS).

• Group Topology & Commits: The presentation analyzed logical
  group management strategies for space missions:

  1. Leader-only commits: A single coordinator manages group
     membership. Low client overhead but subordinates lose PCS.
  2. Subordinate-proposed, leader-commit: Subordinates propose
     membership changes, but the leader executes them. Restores PCS
     but adds synchronization overhead.
  3. Subordinate commits: Fully decentralized. High overhead,
     making it less suitable for constrained links.

• BoF and WG Coordination: A Birds of a Feather (BoF) session on
  this topic is active. In the chat, Erik Kline (AD) and Rick
  Taylor agreed that the DTN working group should progress MLS for
  BPSec regardless of the BoF’s outcome.

Decisions and Action Items

• draft-ietf-dtn-eid-pattern: The chairs will initiate a Working
  Group Last Call (WGLC) on the mailing list.
• Early Multicast Allocation (draft-ietf-dtn-udpcl): AD Tommy
  Jensen and the chairs will coordinate to resolve the outstanding
  IPv4/IPv6 multicast address early allocation.
• SAND Multicast Endpoints (draft-ietf-dtn-bp-sand): The chairs
  will contact the authors of the IMC/IAC specifications to resolve
  the pending multi-point messaging endpoint definitions.
• CoreConf Integration: Javier to post his team's findings on
  using CoreConf and CoreConf M2M for space networks to the DTN
  mailing list.
• Future Session Requests: Due to a highly congested agenda, the
  chairs will request two 2-hour slots for the next meeting (IETF 127
  in San Francisco).

Next Steps

• SPAM Draft: The chairs will issue a call for Working Group
  adoption on the mailing list.
• YANG Validation: The DTNMA design team will coordinate with
  NETMOD/YANG experts regarding native support for IEEE float types
  and potential type coercion workarounds for union types.

Live Notes

Administrative (5 mins)

Presenter(s): Chairs
Document(s): N/A

DTNMA ADM YANG (15 min)

Presenter(s): Per Andersson
Document(s): draft-ietf-dtn-adm-yang

Using native as much as possible
collection, non-native so custom ARI construct
cEB: intuitive native seems preferable, whats the purpose of
alternative?
PA: to form discussion! Preference for YANG native.
cRT: as understand ARI encoding, type safety
BS: we do currently have catalog produced agent implementation, baseline
of alternative through the tools
PA: very much needs to work, complex types do not have implementations
yet hence the alts
EDD keep or config false?
cRT: for EDD, not sure config false is correct, an EDD may be
configurable just external
cEB: that is correct and I was too "config false" is operationaly
sampled
RT: thank you. pretty standard yang for the basic concepts then augment
with amm special.
DF: questioning use of "union"
PA: having validate was first thing but type might be bad
BS: do you care how model being used? you can't be ignorant of
implementation. deep nesting of yang. adm is flat.
PA: purely config is simple, but have to carry into implementation for
api
RT: my original point about reuse
JF: recently implementation in coreconf; this might be default for
satellite m:n - have you looked into this? happy to share more.
PA: no but would love it
cRT: please send to mailing list

Sipos Mature (20 mins)

Presenter(s): Brian Sipos (Remote)
Document(s): draft-ietf-dtn-bpsec-cose, draft-ietf-dtn-eid-pattern,
draft-ietf-dtn-udpcl, draft-ietf-dtn-bp-sand

Next month approaching interop phase for BPSec COSE work
EID is stable and more implementations welcome for testing
RT: ready for last call
cEB: agree, does anyone have any concerns with putting into WGLC? We
will take to mailing list
cRT: are we following process correct for early allocation for multicast
assignment?
adTJ: will answer on chat, will help.
EK: has to come from chairs
cRT: know there is implementors active rn, want some shakedowns
SAND depends on some a few items from udpcl and eid
cRT: routing advertisements need to be careful about as not being in
routing area
RT: rtg adv. do need subset of eid pattern - take to list to work way
forward
cRT: will poke team for IMC EID form

adTJ: AD Update: chair's request belatedly reviewed, I can justify early
allocation for both requested earlier. Work in progress.

SBAM Updates / Key Establishment in Space (15 mins)

Presenter(s): Xisen Tian
Document(s): draft-tian-dtn-sbam

SBAM: looking for adoption and feedback.
cRT: what are the difference between manifest and sbam? or are they
conceptually different?
XT: intent of SBAM idea fits into manifest block, you could combine but
kept separate for additional option/modular.
cRT: rick sorted it out by thinking outloud
cEB: any questions or concerns before taking adoption to list?

MLS Message on slide 5 into Payload for BPSec not Extensions