DTN WG Minutes IETF 93 July 22, 2015 ============================== Administrativia ------------------------------ - Bluesheets distributed. - Notewell noted. Agenda Bashing ------------------------------ * Accepted proposal to move agenda item 5 (Numeric Node IDs) to be after Agenda Item 2. Summary ------------------------------ 1. General agreement that draft-dtnwg-bp-00 should serve as the basis document for a revision of RFC5050. 2. The working group will support monthly interims to keep progress on track and cover the variety of work being done in the WG. 3. Several items referred to mailing list for technical discussion Questions (Q), Answers (A), and Comments (C): Presentation 1: draft-dtnwg-bp-00 Overview (Scott Burleigh) ------------------------------ Topic - Bundle Inventory Q: Elwyn Davies: If only the bundle source adds an inventory and the blocks in a bundle change through the network, what happens. A: Agreement to defer discussion to mailing list. Topic - Extension Blocks in draft-dtnwg-bp-00 Q: Will Ivancic: Is it required that the extension blocks in this document be implemented by every bundle agent? A: Scott Burleigh: We have rules already for processing blocks we do not understand and there had not been consideration to treat these blocks in a special way beyond existing policy. Also, extension blocks carry more than ancillary data. C: Kevin Fall: Defining a minimal set of required supported specifications would be useful. Also mentioned that an extension block to carry higher-precision time would be useful. Q: Ronald In 'T Velt: If extension blocks are "first-class" citizens of the bundle, why is the primary block immutable but extension blocks can be mutable? If they are more susceptible to tampering, then they are second-class citizens of the bundle. A: Scott Burleigh: Primary block immutability versus extension block flexibility does not make extension blocks less important. Q: Marc Blanchet: Experience with IP is that header options are rarely used and usually dropped. Are we building extension blocks that will never be used and need to deprecate later? When moving from research to standards we should be careful what items we add to the standard. A: Scott Burleigh: Fine with moving some or all of the extension block definitions into their own drafts but wanted a place to capture them currently and consider moving them to different drafts later. C: Marc Blanchet: Everything that can be optional should be clearly identified. Q: Rick Taylor: Would renaming extension blocks clarify the kind of information carried by these blocks, as extension implies an optional thing. A: Kevin Fall: The term extension is borrowed from extension headers in IPv6. C: Ronald In 'T Velt: If you call the primary block primary every other block can be interpreted as secondary. C: Scott Burleigh: Would be in favor of renaming the "Primary Block" the "Initial Block" if it helped clarify. Topic - Numeric Scheme Encoding Q: March Blanchet: Why encode names such as the encoding rules proposed for numeric EID schemes. A: Scott Burleigh: Bandwidth constrained environments require smaller messages and even ~20 bytes can make adoption of the standard impractical for highly constrained networks with predominantly small message payloads. Topic - Are Bundle Sources and Custody Accepting Entities EIDs or NodeIDs? C: Kevin Fall: Similar to IP where multicast has a unicast source address and the fact that we have use a unicast source address in a multicast setting implies no issue with using NodeIDs and not EIDs in this instance. C: Elwyn Davies: If multiple nodes all take custody how do they coordination, particularly in a DTN environment. So, NodeIDs not EIDs should be used in this setting. C: Kevin Fall: There exist echniques to use erasure coding to send messages with no assumption of a backchannel so you never get an acknowledgement, just a high probability of downstream nodes being able to re-assemble. C: Scott Burleigh: That isn't the same as the concept of accepting custody. C: Rick Taylor: Agreed with Kevin's point on IP multicast, but noted that the multicast endpoint idea is an interesting concept. Yes there are problems with coordinating custody transfer but it is a shame to rule it our altogether. C: Scott Burleigh: We could achieve similar results without allowing EIDs to be the bundle source or that take custody. Endpoints as destinations make lots of sense. Topic - SDNV language in the BP spec C: Kevin Fall: The argument that putting SDNV text in the spec prevents the reader from having to click on a new link making us carry this text and changes forward seems like a bad idea. Topic - ECOS Critical Flag C: Kevin Fall: Lacking some other big argument, look up DSCP/diffserv literature. The class of service field there and what it might be used to encode may inform what we do here. Topic - Future specifications override this specification C: Kevin Fall: IETF answer is "of course". C: Scott Burleigh: If this happens, do we mark this spec obsolete? C: Brian Haberman: It would be marked "updated by" Topic - Does BPA or CLA identify time to send/forward? C: Kevin Fall: When a message is sent or forwarded is an operational question. It would over-constrain policy operationally to mandate something like that in the spec. Issues are beyond technical implementation. C: Elwyn Davies: This is something that routing decides and routing is out of scope for this document. Topic - Adoption of draft-dtnwg-bp-00 Q: Scott Burleigh asked what adoption of the specification by the WG means other than name change. A: Brian Haberman: That the WG is responsible for the content of the document at that point, versus the individual author. HUM on the topic. Does the WG think this is ready for adoptions? Does anyone feel this is not the case? Presentation Two: Naming (Fred Templin) ------------------------------ C: Fred Templin: I have recently discovered Compressed Binary Object Representation (CBOR) which may be a useful alternative approach and I am investigating. C: Elwyn Davies: If adopted, who would manage the organizational numbers? A: Fred Templin: IANA Topic - Why not use Organization Unique Identifiers (OUIs) C: Marc Blanchet - These are for hardware manufacturers. C: Stephen Ferrel - You have to buy them. Q: Kevin Fall - Why are we inventing a naming structure when so many already exist? A: Fred Templin; Like to have a fresh start, to have more space for organizations. There is a concern that a land-grab could reduce existing space in existing mechanisms. C: Stephen Ferrel: IANA has private enterprise #. C: Fred Templin: They are 32 bits. Don’t want to spend 32 of 64 bits on enterprise ID. C: Brian Haberman: May not make sense to try and figure out how to do it if we haven’t decided if we want to do it. Q: Bohao Feng: What is a known number used for? Routing or just to identify the node? A: Fred Templin: Used to identify the node. Not used for routing due to late binding. For nodeID vs EID, talking NodeIDs. C: Kevin Fall: This started as an IPN scheme (binary thing). It isn’t tied to IPN. Just a name. The idea of a short thing, ppl have made that argument. So namespace, encoding, etc… there are questions there that imply research. C: Fred: Yes, with CBOR as an example and do we want other encoding schemes? Other presentations descoped due to time issues. Wrap Up Activities ------------------------------ Topic - Interim Meetings C: Brian Haberman / Marc Blanchet: WG will have interim meetings once each month. First to occur at end of August. Topic - Hum on EID/NodeID for bundle source and custodian. HUM 1 Let bundle source be an EID: Make bundle source be NodeID: HUM 2 Let custodian be an EID: Make custodian be a NodeId: C: Marc Blanchet: Not clear consensus, may need to take issue to mailing list. Seems both are leaning to NodeID though. C: Rick Taylor: Room seems to be saying don’t stop 5050bis for this. Maybe an item for DTNRG, don’t stop 5050bis now. C: Brian Haberman: That is how I interpreted this. Will send item to list to clarify.