Minutes IETF97: dtn
Delay/Disruption Tolerant Networking
||Minutes IETF97: dtn
IETF DTN Working Group Minutes
November 15th, 2016
IETF97, Seoul, South Korea
- Ed Birrane and John Dowdell to take notes.
- Notewell noted.
- No changes.
- 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
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.
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
C: Marc Blanchet: We should ask Spencer. Current policy is to encrypt
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
- 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,
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
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
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Ó
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
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
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