Minutes for DTN at IETF-96
minutes-96-dtn-1

IETF DTN Working Group Minutes
July 18th, 2016
IETF96, Berlin, Germany
========================================


Administrativia
----------------------------------------
- Ed Birrane to take notes.
- Notewell noted.


Agenda Bashing
----------------------------------------
- Due to time constraints, re-ordering the agenda to push AMA to the end to
  ensure time to discuss addressing.

Summary
----------------------------------------
- WG agreed that BPBis without an encoding should not go into standardization.
  Specific discussions are to be taken to the mailing list.

- New BPBis to split custody refusal as separate signaling mechanism not
  triggered by custody transfer.

- An interim meeting focused specifically on BPBis and associated documents
  will be scheduled in late September.



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


Presentation 1 : BPBis (Scott Burleigh)
----------------------------------------

Summarized changes to BPBIS (-04) to include:
  - Editorial changes.
  - Custody transfer discussions from the mailing list.
Open discussion on whether BPBis can be standardized on its own.


Q: Rick Taylor: How many people have ready the spec? (roughly 30% of room)

Q: Scott Burleigh: Do documents go together or independently? If we need
                   multiple, do we have the minimum set?

A: John Dowdell: Recommend a reference implementation before we standardize.
                 Also recommend we take multiple documents forward as a set.
		 Newer concepts on EIDs and addressing may cause us to amend
                 RFCs later if not careful. Do recognize need to publish.

C: Marc Blanchet: We do not need an implementation for first-step standards
                  track.

C: Jorg Ott: It is not required, but it is a good idea.

C: John Dowdell: I have seen other drafts help up without an implementation.

C: Brian Sipos: Agree having an encoding and a transport would ease concerns.
                TCP-CL changes are simple. CBOR encoding clear enough to likely
                not cause issues if standardized.

C: Spencer Dawkins: You will get better reviews out of last call for BPBis if
                    people understand how things fit together.

C: Rick Taylor: Personal opinion: without a full stack of drafts on how we move
                bundles, address bundles, etc... and having only a draft that
                covers one part of the picture in isolation, we will not get
                traction through the IESG. Need a complete picture of how to do
                DTN in the IETF style.

C: Ron in ’t Velt: At least BPBis and encoding should have representation. Not
                   sure about a CL, so long as we have a clearly defined API. An
                   API means definitions of responsibilities, not a "C" library.

C: Scott Burleigh: BPBis already defines a service-level specification.

Q: Scott Burleigh: Does anyone disagree with a multiple-document approach to a
                   BPBis last call?

<No disagreement>

Q: Scott Burleigh: What is the triggering phenomena? We have drafts posted for
                   all documents (BPBis, CBOR encoding, TCP-CL).

A: Marc Blanchet: All three documents must be WG items, then go to last call.
                  When all three are last-called, move the whole set forward.

Q: Scott Burleigh: Can we ask the WG to adopt the CBOR and TCP-CL documents now?

A: Marc Blanchet: We can as about TCP-CL during its presentation. CBOR encoding
                  not on agenda, but presented previously so could do this by
                  mailing list.

Q: Marc Blanchet: Who here has read the CBOR encoding document?

<~6-7 hands in the room, +1 on jabber>

Q: Marc Blanchet: Who thinks we are ready to adopt CBOR encoding document into
                  the WG?

<~6-7 hands in the room, +1 on jabber>

Q: Marc Blanchet: Who thinks we are not ready, or should not adopt?

<~1 hand>

C: Rick Taylor: No concern over CBOR encoding as a WG document. Concern about
                how CL determines which encoding to use?

C: Scott Burleigh: At the moment, determined by configuration. Long term,
                   enhance and use neighbor discovery protocol.

<Consensus that BPBis + CBOR Encoding + TCP-CL go forward together>

Q: Kevin Fall: Does this imply that a minimal conforming implementation will do
               these things together?

A: Rick Taylor: Imagine so.

A: Scott Burleigh: If possible, don't mandate a conformant implementation do
                   these three things together. An implementation of BP needs
                   1 encoding and 1 CL, but don't specify which.

C: Kevin Fall: If we go down the neighbor discovery path, will there be an
               expected minimal config for the discovery?

A: Scott Burleigh: Would need to be added to the work of the WG.

C: Elwyn Davies: Wary of implementing lots of options for mechanisms.
                 Fragmentation further complicates interoperability. Inclined
                 to choose 1 encoding and say that it is what it is.

C: Scott Burleigh: Our model is more or less the IP model. IP runs over lots
                   of things and configuration is an issue, but also the strength
                   of the narrow-waist idea.  Limiting weakens the architecture.

C: Rick Taylor: Multiple CLs underneath bundling and ensuing diversity is good.

Q: Ron in ’t Velt: How far do we take separation of semantics and
                   representation? Will this affect BPSec? All extension blocks?
                   Will each new extension block require a semantic description
                   and separate encoding documents?

A: Scott Burleigh: I don't see a way to make extension blocks work otherwise.

Q: Ed Birrane: How do you negotiate encodings bundle-by-bundle if two nodes both
               support multiple, overlapping encodings?

A: Scott Burleigh: We would figure out how to do that in neighbor discovery.

<Overview of custody transfer text from BPBis>

C: Kevin Fall: Issues with wording - Ensuring bundle delivery troublesome in
               the past for 2 dimensions of reason. (1) in many environments,
               custody transfer does not ensure delivery. (2) Custody transfer
               does not ensure bits sent == bits received. Custody transfer
               here is enhancing robustness against loss of messaging, which is
               not reliability in the TCP sense.

C: Rick Taylor: Fan of custody transfer, and see value when esoteric routing
                protocols come online. Having it in BPBis keeps people from
                re-inventing it.

C: Ron in ’t Velt: Custody transfer useless in complex routing, such
                   as multi-copy areas (epidemic, spray-and-wait).

C: Kevin Fall: Epidemic incorporates custody transfer concepts (like resend from
               intermediate points). This makes communications possible in
               situations where they are not otherwise possible.
               Just avoid saying it is reliable and sends the same bits.

C: Scott Burleigh: Will adjust first sentence to lighten language on "reliable".

<Discussion on benefits of the custody refusal signal>

Q: Will Ivancic: How do you know that forwarding is impossible?

A: Scott Burleigh: The thing refusing custody makes that determination.

C: Kevin Fall: Text is far too prescriptive. "Must" and "Impossible" should
               be removed. Also discussion of proximal in time. Description
               fraught with problems as stated. This is not an editorial change.
               Something may take custody, not forward now, but forward in the
               future. "Forwarded" implies intentionality.

C: Scott Burleigh: We can adjust language. Intent was not to be prescriptive.

C: Jorge Ott: Do we have alternative mechanism to signal "no route to host"?
              Do not tie this useful bit of information to custody signaling.
              Split the two apart.

C: Scott Burleigh: Can add third class of admin record: Cannot forward for
                   whatever reason. Make custody refusal separate from the
                   custody transfer mechanism.

Q: Rick Taylor: Is there consensus that a mechanism for custody and reporting is
                valid even though no consensus on use cases.

<General agreement>

C: Kevin Fall: Cleave off bit about re-forwarding, same comment on "ensured" when
               making alternate language when custody transfer not requested.


Presentation 2 : TCPCL (Brian Sipos)
----------------------------------------

Summarized changes/additions for TCL-CL.


Q: Jorge Ott: Should we use SDNVs? TCP limits range of RTTs supported.

A: Brian Sipos: No preference. Used SDNV to avoid adding a bit length. No
                asserted bit length works for everyone.

C: Jorg Ott: Disagree that using TLS makes an endpoint trustworthy. TLS
             protects the exchange. If you need to protect the EID you should
             not be using StartTLS as one side could choose to send EID in the
             clear. Recommend using different port or out-of-band.

C: Brian Sipos: Contact header changed from TCL-CLv3 - items now optional, so
                possible to not send EID in the clear, apply contact security,
                and transmit EID after. Agree EID is not sufficient to
                establish identity. In a PKI environment, cert exchange and
                bidirectional authentication would be reasonable.

C: Jorge Ott: If two ends connect but only one end wants security, doesn't help
              that things in the contact header are optional. Cannot prevent
              this when using StartTLS.

C: Rick Taylor: Suggest security consideration questions be taken to the list.
                There is lots of best practice material out there.

Q: Brian Sipos: How would WG like to specify the forward compatibility that was
                mandated in TCP-CLv3?

C: Jorge Ott: Protocols do not usually get better with complexity. Many things
              added here, such as BP version ID. Suggest asking which changes
              we really need to build something functional. Each feature must
              be dealt with when not handled correctly which leads to
              combinatorial explosions and pecial cases. Some flaws in this
              spec, and must be careful what we add to avoid "second system
              syndrome". Feel strongly as editor of previous TCP-CL document.

C: Rick Taylor: Before we do an adoption call, need to chat with AD to sort out
                administrivia. Likely ask for adoption on the mailing list.

Q: Marc Blanchet: Feeling of the room: Is this useful?

<~50% say useful. 0% say not useful.>


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

- Summarized updates, additions, removals from last version of spec.
- Discussed whether to adopt security best-practices document
- Discussed whether to adopt Suite-B ciphersuites and profiles documents.

C: Spencer Dawkins: Make sure this has been reviewed from a privacy perspective.

C: John Dowdell: Would like a security best practices document to go through
                 standards at the same time as this spec.

Q: Marc Blanchet: Many existing profiles and ciphersuite specs published.
                  How do we make sure we are not duplicating work?

A: Ed Birrane: The proposed profile and ciphersuite documents for DTN are
               configurations and adaptations of existing specs, and reference
               those specs. For example, the Suite-B profile and ciphersuite
               specs for BPSec are each about 6 pages long.


Presentation 4 : Numeric Node IDs (Fred Templin)
----------------------------------------

Q: Jorge Ott: How about no numeric scheme? Many problems go away.

C: Rick Taylor: I like numeric IDs for constrained devices.

C: Jorge Ott: Make you own Numeric ID is fine. Overdoing it to
              define a scheme.

Q: Rick Taylor: Why not use the same DTN scheme?

A: Fred Templin: There is also IPN.

C: Kevin Fall: Call one scheme IPv4 and have a 32-bit number, call another
               IPv6, etc...If this is really trying to adopt the IPv4 space is
               there a compatibility issue when you come out of DTN space and
               back to other networks?

C: Rick Taylor: Out of time, take to list.


Presentation 5 : FIB for DTN (Rick Taylor)
----------------------------------------

A Forwarding Information Base is essentially a routing table for
DTN. Is such a concept useful?

C: Kevin Fall: Have had this conversation before. Some addressing is pre-solved,
               some computed. Others are dynamic, like geo-routing. Need to
               handle different schemes. Also, some concerns regarding
               CLs - you may want to split multiple paths so one-directional
               egress needs to be generalized.

C: Scott Burleigh: Intent of URI notation was to support multiple schemes.
                   Some amenable to FIB notation. For example IPN scheme
                   matches well with CGR. We need FIBs for different schemes.

Q: Rick Taylor: Can we generalize a core FIB?

A: Scott Burleigh: I suspect not.

C: Elwyn Davies: Heavily involved in routing with DTNs. Issue is late binding.
                 Often have no idea where to go until you have the connection.
                 Putting items into a FIB may not be useful.

C: Jorge Ott: Good intellectual exercise. Not sure if preloading helps, but
              figuring out what goes into such a table may teach us something.

C: Elwyn Davies: May be a layer problem here. Not clear that the CL performs
                 neighbor discovery. Not sure how this concerns the CLs, they
                 want to be told what to do and that's it.

C: Rick Taylor: CL could receive event-driven notification, like smart
                radio meshing.

C: Scott Burleigh: Suggest some implementation work to answer some of these
                   questions. There is no unanimity on these concepts.

C: Kevin Fall: There are cases where you might want to load balance, or
               encode. Other cases (various protocols) where you copy across
               multiple ones.

C: Jorge Ott: You will probably want a time field. And also an entry timeout.

C: Rick Taylor: That is routing. That function adds/removes items to the FIB
                based on time or expiration.

C: Jorge Ott: Interesting scheduling question. The entity that has to make the
              forwarding decision must know about the future or you cannot
              implement this.

C: Scott Burleigh: CGR does exactly this.

Q: Kevin Fall: Are you proposing an informational RFC?

A: Rick Taylor: Yes. As a reference for other drafts. Perhaps as a way to
                specify minimum requirements on routing protocols.

C: Ron in ’t Velt: FIB is probably not the right way to do that.


Presentation 6: Semantic Addressing (John Dowdell)
----------------------------------------

C: Rick Taylor: This work is all about addressing, but we don't have
                consensus as to what is an EID or how it is encoded or
                aggregated.

C: Scott Burleigh: Propose to consider multiple schemes. There is not a
                   single answer to "can you aggregate". I am confident
                   it will be different per scheme. Some concepts for how
                   to handle this in implementation, though nothing is
                   universally acceptable enough to turn into a WG item.
                   May need a BGP-like structure that matches things up.

C: Elwyn Davies: There are a few papers on what happens when you interconnect
                 multiple DTNs via the Internet. Interesting topic to consider.
                 Though what happens with multiple organizations when you need
                 to distribute keys?

C: John Dowdell: Not thinking security at all right now.

C: Elwyn Davies: You must. When figuring if a node will take bundles
                  off you, addressing and whether they trust you and have
                  capacity, etc... are important. It all comes down to local
                  policy decisions.