Subject: [dtn] DTN WG Virtual Meeting - Thursday December 5, 2014

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Fri, 5 Dec 2014 17:14:43 +0000

Please let me know if I got something wrong.

Sorry if I misspelled any names.

==============================
DTN  Meeting December 5, 2014
 
Notes by Will Ivancic

Marc - Agenda and Goals
Get consensus on what to work on.

Reviewing google documents
https://docs.google.com/document/d/1RVwIUVIoJbZDCqIaZX5SICZN06kVjx42VzH82_r
m3JI/edit

Will -  terminate  bundles stuck in routing loops and hop-by-hop
integrity for the header and end-to-end integrity for the bundle if the
bundles
are large.
 
Conesus that these need to be worked.

Marc, where should these topics reside?

Discussion of header.

Created INTEGRITY task for  header
integrity, header immutability.

Discussion of primary block vs header blocks.

Elwynd indicated that extension blocks get quite complicated
 particularly if you have meta-data blocks, order of blocks.

???Need something to indicate what headers are there???

Marc  we think we need to work some type of addressing, but
scope may be to large. Need to determine the scope of the work.

Fred  volunteered to work on use cases that correspond to
Addressing

Marc  what does the industry need with regard to
addressing?

Fred  what about zero/one indicating aggregated vs flat
address space.

Will  mult-homed, mobile systems are hard.  Adding disconnection is
harder. Adding
propagation delay adds additional complication.

Neighbor discovery:

Elwynd  is discovery, discovering your neighbors or
discovering what you neighbors are capable of?

Marc  first just discovering you neighbors.

Keith  should neighbor discovery be part of the core
bundling protocol or an application that uses the neighbor discovery?

Simple Routing:  

>From Group  what does it mean?
 
F
red  manet has routing protocol separate from neighbor
Discovery

Elwynd  manet may not be a good example.  One that uses 2 hop discovery
is good work,
but only by one (or a few) manet routing protocols.

Elwynd  recommend that discovery is separate from routing.

Scott Burleigh  agrees with Elwynd.

Marc  summary and consensus is to work some type of
neighbor discovery.

Fred  a modular neighbor discovery will enable hooks with
routing protocols.

Dynamic routing: 
Consensus is to not include as work item at this time.  Too big and one
size does not fit all.

Simple Routing: 
What is it?  Consensus appears to be Static Routing.

Keith Scott  simple forwarding table.  No discussion about how to
populate the
Table.

Network Management:

Scott Burleigh  needed, but to big for current charter.

Elwynd  is this just monitoring or monitoring and
configuration.

Brian  may be synergy with other working groups.  Some groups are working
layer independent
management models.  DTN may be able to
make their needs known.

Marc  would like to hear from industry as experience has shown
that network management is usually needed.

Jeremry Pierce Mayer  Network management is important even
for small networks.

Marc  is configuration or just monitoring.

Jeremy  to many open items such as addressing that need to
be discussed prior to configuration.
Concentrate on monitoring.

Scott Burleigh  really to large at this time.

Fred  can work on items that are not in charter?

Marc  individuals can submit individual submissions and
then working group can consider the draft as moved to WG item.

SECURITY:

Marc  improved security.

Scott Burleigh  needs to be done.

Brian  what are you discussing: integrity, confidentiality,
none repudiation?

Chuck Sheehe  what about creation/expiration time, how is
that treated?

Ed Barrine  allows layering of security.

Scott and Fred  strong support for simplified bundle
security.

Elwynd  what about key distribution.

Fred and Scott  both Boeing and JPL working on
implementations of key management.

Brian  there appears to be interest in working on
simplified security.

Elwynd  need to ensure that BP structure does not make
security break.

Will  Does security have to operate with reactive
Fragmentation?

Scott B. If reactive fragmentation is part of core bundle
protocol, then security my work with reactive fragmentation or whatever
else.

EXTENDED CLASS OF SERVICE:
Scott B and Keith Scott  Extended Class of Service should
be left for future work

Elwynd  forget ECOS, it doesn¹t work except perhaps for
close deployments.

MULTICAST:
 
Scott B  have some work, but propose until next iteration.

Elwynd  existing protocol has multi-node endpoints.

Will  ICN has multicast concepts that my be useful.

Ronald Velt  interested and relevant, but push to later.

STREAMING:

Scott B.  JPL has working solution for NASA.

DRL is working on this, but no need for standards track.

Keith Scott  does base protocol need something for
streaming?  

Answer, ECOS is mandatory for streaming to work, but nothing needed
in base protocol.

BUNDLE SIZE:

Will  large, small or what?  large bundles requires reactive
Fragmentation.

Keith  perhaps no need for reactive fragmentation.

Elwynd  restricting bundle size would be fundamental change
to architecture/protocol.

TIME:
 
Will  explained position and referenced wiki:
https://sites.google.com/site/dtnresgroup/home/dtn-bone

Scott B.  Work item but disagrees with Will on time

Elwynd  keep as work item.

Item 18  22:  Bugs, operation in constrained environments, default
operations, gateway for 5050.

Scott B.  all items should be considered.

Elwynd  do we really need to be gateway consideration.

REGISTRY OF SERVICE IDENTIFIER

Marc  Already a work item.

SUMMARY OF TOPICS TO WORK / EXCLUDE  See Google Docs document:
https://docs.google.com/document/d/1RVwIUVIoJbZDCqIaZX5SICZN06kVjx42VzH82_r
m3JI/edit