IETF 116 DTN working group meeting Tuesday 2023-03-28 00:30 - 02:30 (UTC) Co-chairs: Ed Birrane (cEB, EB), Rick Taylor (cRT, RT) Secretary: Adam Wiethuechter (sAW, AW) # Agenda {#agenda} # Intro (Chairs, 5 min) {#intro-chairs-5-min} ## Administrivia: 5 minutes {#administrivia-5-minutes} Welcome! Notewell. We are recorded it will be on YouTube. Please join queue on meetecho, even if in person. Mic and video off if not presenting. Masks on unless speaking please. Packed agenda! Agenda bash? Nothing, moving on! # Presentations (105 min) {#presentations-105-min} ## Updated: COSE Security Contexts and BPv7 Administrative Record Types (Ed Birrane, 5 min) {#updated-cose-security-contexts-and-bpv7-administrative-record-types-ed-birrane-5-min} https://datatracker.ietf.org/doc/draft-ietf-dtn-bpsec-cose/ https://datatracker.ietf.org/doc/draft-ietf-dtn-bpv7-admin-iana/ Two documents finalizing. * BPSec COSE Context * Comments! * BPv7 Admin Record Types * Clarifies use of speific sub-registry for BPv7 * WGLC Marc Blanchet (MB): when started with RG. There were a lot of code points not in IANA. Wrote document to register to IANA. We should not do documents solely for this, must be in spec documents. This should be last document that does that. All new should be in standard documents. cEB: please send to mailing list for Brian Sipos. It is also holding up omething in another WG cRT: yes last to catch up ommisions in other documents. Totally agree. ## IPN URI Scheme Updates (Rick Taylor, 25 min) {#ipn-uri-scheme-updates-rick-taylor-25-min} https://datatracker.ietf.org/doc/draft-ietf-dtn-ipn-update/ We believe all comments taken. Fundamentally rewritten to remove rationale text. Replaced with specification text. Split into two parts. * IPN URI scheme * Encoding IPN scheme for BPv7 EIDs However, please review if you made a comment was satisfied. All IPN URIs look like: ipn:auth-num.node-num.svc-num Hardest part, dancing around "node". It is logical, not physical. Every resouce that is colocated on a construct of a node shares a node number. What was wrong with no authority? Gives discrimation for better allocation of node numbers. The existing registry and will continue to be used will use Authority=0 and be the Default. X taken from existing IANA registry. Forward port of CBHE registry. Reserved some well known node numbers and maintained existing allocations. Node-num=0 is "nowhere". =1 is "local-node" (localhost); non-routable. 2-2^14 is private use (free for all); must assume they will crash unless in your admin domain. Snapshot of registry is old in document, will be update. Feel free to interrupt. Registered authorities. Org can grab block of node-numbers and use as they wish and be heterogeneous. New: allowed for range of auth-num. Subdivision in an allocation is good. CCSDS could ask range, and hand out one number in that range to sub-orgs. AW: is there a mechanism to mark a single for metadata info? RT: IANA delegates this authority. Can be done but might be messy. Adminstive issue. Reduce load of iana registry to handle it. Eric Kline (EK): use now or later? documentation example /31 of authorities? RT: final slide but yes EK: table 3, initial values. No range column in CIDR format. RT: wary of doing slash notation, we are not an IP address! Felt weird... EK: should have range. do you see /notation that needs to be in string form? are we reinventing class-space. RT: hard to parse when cidr was introduce. we take this to the list. 0\.1.y is localnode only! clarify from chat CBOR of URI * two element \[rfc9171\], semantics of original uri. word smith on wire same * three element If default authority continue to use two element, otherwise use three element. Two element can be handled without a code change. Three elements incompatible with existing deployments, so interactions need to be aware. Feedback! Reserved auth-num top bit range for other use. Discussion: * auth-num policy * FCFS for >4095 - too low? * expert review? * Experimental section? * svc-num policy * spec required <4096 (from tcp ports) - too low? * private use to "unattractive range"? * formal term for (auth-num, node-num) * lost "this is the id of the node" * node-numeral * "all a bit node" EK: call in question for svc-num allocation policy. for resolution layer! always going to be in endpoint so no need to reserve RT: ping service number EK: fully qualified node number MB: nuetral to proposal. auth-num allocation. IANA does not talk to orgs. PEM which is a bot. IPv4/6 AS numbers are allocated to RIRs. MAy want to discuss with IANA from orgs like this. 2. who is expert how you gonna verify? or asking iana? interesting questions. cEB: more discussion for list, guidance to desigated experts. one last slide, please make sure comments are represented. Scott Johnson (chat): That is a job for a dedicated entity or group of entities like the RIRs. ## DTN Management Architecture Updates (Sarah Heiner, 10 min) {#dtn-management-architecture-updates-sarah-heiner-10-min} https://datatracker.ietf.org/doc/draft-ietf-dtn-dtnma/ DTN-MA draft changes. v5, high level and solicit final reviews before WGLC. auto mgmt in challenged environments. cant support request response. use open loop instead. self-management with local autonomy agent. dynamic arch due to dynamic topology Jorge Amodio (chat): Does DTNMA include sort of a watchdog function? EB(chat): it allows for it hierarch model of information push mechanisms not pull. local to determine what and when to push. effecient data encoding from data model design universal data id, so individual datums can be maniped * avoids sync and associated lookups runtime data defs * create new data from existing data for data fushion auto operaetion * deterministic behavior updates to use-cases * can be applied to various scenarios Sauli Kivir: comment about notion of remote control and no idea of availiblity. shared models. approaching change state could lead to scaling problem. can discuss offline. SH: can take to mailing list, and explain more. cEB: further discussion to mailing list but Stu Card (SC): autonomy, determistic: fully or bounded? SH: emphasize predicatable and goal is to ensure that when manager and agent cant communicate we can still know what state applications can be in that are being managed. SC: you need to know down to bit or from space? cEB: good mailing list dicussion. MB: yang models? SH: intentinally avoiding anything already providing features. yang is viable option. EB: do we hear volunteer to continue work? MB: looking for yang model of node... ## ARI URI Scheme Updates (Sarah Heiner, 10 min) {#ari-uri-scheme-updates-sarah-heiner-10-min} https://datatracker.ietf.org/doc/draft-birrane-dtn-ari/ On behalf of Brian Sipos. ARI is part of DTN-MA ecosystem. ID and envoke objects in ADM. Out in couple years with implementations. Some changes based on work. In work! changes are ARI encodings, not concepts or ADM itself. ARI syntax simple to use, encode. Issue address: * binary was close but not cbor; custom handling was needed * redundancies of binary and text * text parts like uri not well speced * some were never sent over wire or sent via different object simplification * categorized as literal or reference * binary encoding is cbor * cddl grammer now usable * context-free grammer Enhanced/simple typing * literal from object reference types * closely mirroring cbor No compound types for over wire Real CBOR - now use existing tools and smaller encodings. Summary * separate between literal and object-type * simpler encoding for text * cbor encoding * enumeration cleaned up Related Issues * please review and go to mailing list * would love help RT: Thanks! havent looked for a long time. ara syntax is about referencing instaniates members of model and ??? EB: yes. cRT: parallel work that could be looked at in terms. almost cborpath - like jsonpath. have looked at any of that? SH: cant answer for brian. definitely would love to look at existing approaches. cRT: go talk to carsten. ## Email over BPv7 (Marc Blanchet, 15 min) {#email-over-bpv7-marc-blanchet-15-min} https://datatracker.ietf.org/doc/draft-blanchet-dtn-email-over-bp/ BP is not IP! On sale for 2k each. Rationale * running apps over BP, we start here! * IP network on planet body * both end side using regular stuff Encapsulation * smtp chatty between MTAs * 00 used \[RFC5322\] * does not include envelope * 01 use \[RFC2443\] Consideration * if big use BP fragments * both ends need to know each other * BP service num? (25?) Working on Postfix and uD3TN prototype. Send note. Steve Farrell (SF): email over previous. could be done. bad idea. when we did that is was more useful to do sync of message stores instead. bunch of reasons. MB: lets argue!!! SF: pubish mx and smtp over entity?? MB: discuss offline? SF: layering spam will get a lot. not gonna stop, but wiser to sit back and think about it. might be message sync. MB: agree. this way is indepent. sync needs to know format and stuff thus more implementation details. encap is more standard. SF: do we want to have this discussion? cEB: question is what are we asking for? wg adoption or are we asking way to exchange email over DTN? perhaps we need a statement of problems and concerns of email over dtn at all. request: take to list. SF: think that is fair. not an rfc, but think what we want to spend cycles on. cEB: queue for people of people in queue. writings about email over bp? SF: sent to list. can ressurect. MB: i agree, different ways mailing list! ## HTTP over BPv7 (Marc Blanchet, 10 min) {#http-over-bpv7-marc-blanchet-10-min} https://datatracker.ietf.org/doc/draft-blanchet-dtn-http-over-bp/ Now HTTP! Most things are HTTP based, try to reuse. Space app dev is a regular Interenet App dev with "best practices" - far reaching stmt Encap * whole request in single bundle * other wise fragment * uuid before payload for keeping track * counter added, to signal if more * was done in bpv6 for streaming Considerations * htlm page has lots of references! * url redirection will delay further * service number assignment * time related headers, cache control Comments * Mark Nottingham; Mr.HTTP said fine * Sipos; multiple HTTP versions use 9292 * connect id/seq in cbor; disagree * multiplex: yes * preemtive cache: need to look implementation in nginx and uD3TN - please send note! RT: thank you! applies to both smtp and http - more power to be achieved than just sticking in bundle. destructure logical parts of them and use multi-block in dtn to store. extension blocks with http headers. chunk decoding, fix seq? http2/3 fixes the other part. dont just encap. just like t-shirt. cEB: longer discussion. MB: disagree!!!! talk on mailing list SC: thrilled! unpleasent consequences. Back in the dail was dial on demond routers, UCCP and did stuff like this - it was how email moved! still good ideas from those days. to ricks point, lets think about granularity and layers of abstraction. dont do with fancy webpages but dont let the endpijnt parse the html, instead proxy does it for you and sends big bundle. Did it in 1993, can be done but is smart? MB: can be done using pre-cache and optimation.. SF: less crazy. http client is modified cause it will timeout. we use HTTPS... AW: BPSec == TLS??? in HTTPS MB: ??? SF: app developer, they have security model and it doesnt match here. cEB: we need to move on (bad joke) Joshua Deaton (JD): quick comment. like the idea to be taken care of. not see why we std this specific concept - just do an giant ip wrapper. set list of app cl. more things to take advantage of! encap is not the only answer. other things done. cEB: +1 to open discussion on list MB: provide text Zahed: day-0 kind of thinking. adZ: great that we are talking about it! agree with people are saying - focus on app we are envisioning and guidance then map to our protocol. MB: yes cEB: lets discuss on list! ## EID Patterning (Emery Annis, 10 min) {#eid-patterning-emery-annis-10-min} https://datatracker.ietf.org/doc/draft-sipos-dtn-eid-pattern/ On behalf of Brian Sipos. define set of eids in a structured way ipn stuff in reference to updates to said scheme Use Cases * security identities * routed blocks * config and policy * colloquial DTN scheme * separate node and svc-path segment * match/regular expression for patterns IPN scheme * three single integer parts * matching base * compress cbor encoding Consideration * pattern is not an eid * pattern superset of eids * concept simple, practive complex cRT: love the work! very important and address EK comments on CIDR. ## Scenarios and Lessons Learned for Low-Latency, High-Resilience Communications (Sauli Kiviranta, 20 min) {#scenarios-and-lessons-learned-for-low-latency-high-resilience-communications-sauli-kiviranta-20-min} No Draft Bakground state research in various areas. * augmented reality for space missions POINTR, cool for space context but fine tune for terresterial Security is matter of life and death and can not be after thought variable connectivity and legacy systems * led to dtn... internal implementation of BP, more primitive but concept there... measurements of what done lots of wg advice and best practice is needed and useful! cRT: thanks! cross-over between DTN and DETNET. Ensure that bounds on characteristics are there. Suggest look at DETNET and other determistic groupds. JD: do you have ore info regarding delay resilience of LTP. 4sec delay range, slightly different stuff... Feel free to reach out after and share. cEB: please share to mailing list. # Wrap-Up (10 min) {#wrap-up-10-min} ## Walk-On Topics: 5 min {#walk-on-topics-5-min} ## Final Comments: 5 min {#final-comments-5-min}