Minutes IETF97: dtn
minutes-97-dtn-00

IETF DTN Working Group Minutes
November 15th, 2016
IETF97, Seoul, South Korea
========================================


Administrativia
----------------------------------------
- Ed Birrane and John Dowdell to take notes.
- Notewell noted.


Agenda Bashing
----------------------------------------
- No changes.

Summary
----------------------------------------
- BPBis should be considered for last call. Will take to the list.

- BPSec can be standardized without requiring standardizing a suite-b profile
  and without standardizing a security best practices guide.

- DTNWG members encouraged to read and comment on the TCPCLv4.

- Take to mailing list consideration of AMA for inclusion in the DTNWG items
  as part of defining network management requirements.

- Ed Birrane and Brian Sipos to write ADM template and YANG model document.

- John Dowdell and Rick Taylor to write internet draft for static addressing.


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


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

Review of items from the interim meeting. Walked through changes from list
and interim review. 

C: Rick Taylor: Request comments now since we are getting ready for last call.

C: Kevin Fall: Section describing custody delegation seems newer. Suggest people
               go read this section, as it is different than stuff from before.

C: Scott Burleigh: Custodial retransmission relies on timeouts - intent of
                   delegation is to give new info to current custodian about 
                   future transmission that custodian can use with other info
                   to figure out most accurate timeout. 

C: Kevin Fall: Concern is situation where bundle requesting custody goes through
               nodes and all generate something like this and no-one takes
               custody, so amplification problem.

Q: Rick Taylor: Any concerns with putting BPbis to last call?

C: Ron in Õt Velt: Would like chance to review.

C: Marc Blanchet: Final call is a chance to review. 

HUM on last call for BPBis
Ready for last call: Several hums
Not ready for last call: Silence.  


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

Summarized updates to BPSec.
  - Cleaned up language.
  - Added section on how to extend the spec for new security blocks.
  - Discussion of three created expired drafts.

Q: Rick Taylor: Given your ÒOther Security BlockÓ (OSB) section, do you need
                additional reserved values and an IANA request section? Are 
                you suggesting we request values for 3rd party OSBs?

A: Ed Birrane: No. OSB authors need to go and register with IANA. No need to
               pre-reserve numbers.

Q: Ed Birrane: Can we standardize BPSec without also standardizing other 
               documents: the suite-b profile/cipher-suite specs and the
               security best practices?

Q: John Dowdell: Can these be informational, as examples? 

A: Ed Birrane: Yes, can be useful for people who want to deploy in certain
               areas, but should not hold up bpsec in standards track.

C: Marc Blanchet: One answer is whether the documents are necessary to bpsec.

<<General agreement that BPSec does not depend upon supplementary documents.>>

C: Marc Blanchet: If you are defining a new registry you can place values
                  in the specification. Otherwise, you must leave these 
                  values TBD and let IANA assign them.


Presentation 3 : TCPCLv4 (Brian Sipos)
----------------------------------------

Reviewed changes since last IETF
- Reduced sequencing variability from TCPCLv3
- Does not change workflow of TCPCL
- Uses fixed sequence, removes all SDNV
- Initiate TLS, add transfer id, add segment/transfer maximum size


Q: Rick Taylor: Who has read the latest version of the draft?

<< No hands >>

Q: Brian Sipos: I removed the TLS cipher suite and referred instead to best
                practices. Is that OK or do I need to specify a minimum
                cipher suite?

C: Marc Blanchet: We should ask Spencer. Current policy is to encrypt 
                  everything everywhere.

C: Rick Taylor: Also, there is a privacy concern over discovering fact that
                two parties are having a BP conversation.

C: Spencer Dawkins: Speaking as AD and channeling Security ADs, right answer
                    is that in order to not encrypt everything everywhere, you
                    need security considerations to explain that. We should
                    not produce protocols that are not safe for the Internet
                    and transport is usually not safe over the Internet. I
                    would take these documents to the IESG if you can pull off
                    a convincing security considerations section that does
                    explain what the exposures are.

Q: Marc Blanchet: Where should security be discussed? You have BP, multiple 
                  convergence layers beneath it, and BPSec. You could have
                  security in each area, or in none.

A: Spencer Dawkins: The considerations should be in the base protocol. It is
                    the only thing that you know everyone is running. I would
                    be happy to take first draft text and talk with the 
                    security ADs. Do not want to start a conversation without
                    text because they have really lurid imaginations. 

Q: Rick Taylor: Does the security best practices guide that Ed talked about
                help us here?

C: Scott Burleigh: The security section in BPbis is inherited from RFC5050.
                   I will update this, but am not an expert in this area and
                   would ask for some review.

C: Spencer Dawkins: Security ADs can be asked to review before a WG last call.

C: Ed Birrane: Security best practice guide does not help here. it is a recipe
               book for achieving security results, but is driven by security
               considerations, not the other way around. 

C: Ed Birrane: BPSec has a security considerations section that may be useful
               for BPbis if we want to migrate it over.



Presentation 4 : AMA/AMP (Ed Birrane)
----------------------------------------

Walked through document map of network management documents and then each in 
turn.
  - AMA as a description of the motivation/needs for asynchronous management.
  - ADMs and templates as a way to capture the data model for this concept
  - AMP as one (of maybe many) ways to communicate these models on constrained,
    embedded devices.


Q: Rick Taylor: Any YANG gurus willing to help moving the ADM model to be more
                YANG-like? Do we think ADM in YANG is necessary or can we re-use
                existing work in YANG?

C: Eric Voit: I like the AMA/AMP concept, I know YANG, and would be happy to
              review a YANG ADM. Can see problems, but are there any common 
              rules and syntax between platforms?

Q: Marc Blanchet: This looks like MIB++ with additional semantics. Is there a
                  reason to use YANG?

A: Ed Birrane: YANG has RPCs, data type definitions, so seemed reasonable. For
               a constrained system we canÕt use long strings. We need to 
               encode in CBOR for constrained devices. 

C: Marc Blanchet: Using YANG may reduce the complexity of the model.

C: Ed Birrane: AMA/ADM/AMP are not tied to SNMP OIDs. We just need a good, 
               compact encoding of identifiers.

C: Eric Voit: In SNMP for every trap you have to define what that is, you canÕt
              define your own. YANG has no pre-defined traps - can do any
              query you want. This sounds like the best of both.

C: Rick Taylor: Like how data models can be simply defined in YANG. How we
                transmit the data is a different problem.

C: Brian Sipos: Important to note that for AMA/AMP, YANG is decoupled from
                NETCONF. Using the YANG data model is useful, and there are no
                technical limitations because YANG is open-ended. 

Q: Ed Birrane: Brian, will you help author the ADM Template in YANG?

A: Brian Sipos: yes. Also, there is an expired draft for a YAND ADM model.

Q: Rick Taylor: Are you bringing these drafts to the DTNWG for adoption?

A: Ed Birrane: Yes.
 
C: Marc Blanchet: Network management is not yet in the charter.

C: Ed Birrane: Agreed not all of this is in the charter. Suggest that the AMA
               be submitted to speak to the existing charter item of network
               management requirements.

C: Rick Taylor: We should take this to the list.



Presentation 5 : Static Addressing (John Dowdell)
----------------------------------------

Q: Jorge Ott: DidnÕt we have something like areas or zones 15 years ago that
              gave a 2-layer hierarchy? Are we introducing something that we
              previously abandoned?

A: Scott Burleigh: They were regions, and the term region should be exhumed and
                   rehabilitated but not for this concept. Addressing is not
                   routing and we are talking 2 distinct things: (1) migration
                   of the bundle into a namespace shared with the destination
                   namespace so routing can happen and (2) topological routing
                   itself which, for scaleability might need to be hierarchical
                   and federated and need a structure for that. My preference
                   is to use the term ÒnamespaceÓ for (1) and the term ÒregionÓ
                   for (2).

C: Rick Taylor: This is similar to MPLS and label switching.

Q: Marc Blanchet: This is like tunneling to another namespace. Do we really need
                 this? Are people gatewaying between different namespaces?

Q: Jorge Ott: The slide has 2 separate clouds that presume namespaces are neatly
              isolated, similar to topologies. If you think in this way, a
              resolver may make sense. In a grand deployment, many routers may
              support multiple namespaces. Will this be workable with 
              intertwining namespaces?

C: Rick Taylor: The default route is a resolver. If you do not understand the
                namespace, give it to someone else; this is late binding.

A: Scott Burleigh: The resolver is something that knows how to do the binding,
                   and the source is someone who does not know how to do that
                   binding. It is the ability to do that late binding that is
                   an issue. Regarding tunneling, that is a way to do this, but
                   also doing this with some pushing and popping of extension
                   blocks may be a lower impact way of doing it.

C: Rick Taylor: There is an implicit understanding when tunneling that the
                wrapped packet/bundle is now opaque and to look at that 
                external header for forwarding. Reason I am keen on the ESB,
                there is nothing to stop intermediate nodes en-route from
                looking at the primary block (unencapsulated) and saying ÒI
                know where to route thisÓ.

Q: Ed Birrane: Do all resolvers understand all namespaces and, if not, does
               this imply something like BGP for resolvers?

A: Rick Taylor: No, different resolvers can understand different namespaces.
                And no, we do not need BGP, we would look to a DNS-like
                architecture instead.

C: Jorge Ott: I recommend to NOT leave out the Òden:Ó from the bundle. Some
              schemes, like named information could be useful, so want to
              avoid always assuming den:. The scheme might not be obvious.

Q: Marc Mosko: For URIs, // is not part of the path. Why did you choose to
               use // in this way?

A: Rick Taylor: because the open source implementations of DTN use it this way.

C: Scott Burleigh: We would have 2 levels of scheme. In BPBis an EID is a 
                   scheme ID and a scheme-specific part. The SSP can be numeric 
                   or whatever. Probably not a problem, but an angle I had not
                   realized. Think it is doable.

Q: Rick Taylor: If John and Rick wrote this up as a draft, would the DTNWG
                want to read it?

A: Jorge Ott: It would be an interesting exercise.

A: Scott Burleigh: At the very least, a definition of the DTN scheme would be
                   produced. Even if it did nothing else, that would be
                   enough.