MAJOR 1. I was debating with myself about the pros and cons of leaving the bundle representation completely out-of-the-spec. Yes, we have made it more abstract this way and deployment-wise optimal representations may be made. But we have made interoperability - which also is one of the core goals of a standard - far more difficult. As a compromise, I feel that it would only be helpful to have a "reference" representation. If you do not wish to have it tightly built into the spec., it may appear as an appendix section, or a separate internet-draft. I think we've converged on providing at least one representation (CBOR) right away as a separate draft. The SDNV-based representation that we have in RFC5050 may be easily adapted as a reference representation. A new designer who happens to stumble upon this RFC (in future) would have a less difficult time - in terms of interoperability issues - if there were a reference representation. One could start with the reference representation, and subsequently optimize the representation with usage. Further, there is no scope for signaling the representation-in-use in the bundle itself - for a receiving bundle-node to reliably know whether it can understand it or not. What if, and a bundle-node which is capable of handling only bundle representations A and B, receives representation C, which unfortunately happens to look like representation A or B; it is all bit stream, right. Although this is probably a low-probability event, the poor bundle-node may process it and do arbitrary things. Perhaps, the usual way we deal with problems such as this in protocol design: introduce a representation-number after the bundle version number should be added to resolve this? The problem here would be that the representation number (and the bundle version number) need to be in some common representation, which is what we're trying to avoid. Further, one or two lines giving the motivation for why the representation is left unspecified deliberately would be nice. I think for now, the draft only just says that it is out of scope. Sure, good idea. 2. Sec 4.6.4, Line 6: Perhaps we could make a stronger statement that bundle must be deleted if limit exceeded? Change "a bundle may be deleted" ==> "a bundle MUST be deleted" ?? How about SHOULD? I'm thinking there might be some conditions under which this shouldn't happen. 3. Sec 5.2 Bundle Transmission, Step 3: "Section 5.4" ==> "Section 5.3" ?? I think Section 5.4 is better here. I suspect BP loopback is more valuable for testing than anything else, and for that purpose you don't want to short-circuit the procedure. 4. Sec 5.4 Bundle Forwarding, Step 2 and Step 3 refer to "Figure 12" which is not present. Good catch; should be Figure 3. 5. Sec 5.4, Step 4, "Section 5.10.2" ==> "Section 5.10" ?? Yes. 6. Sec 5.4, Step 6: Why is the retention constraint "custody accepted" mandatory for sending the reason-code "forwarded over unidirectional links". Is there any issue if this reason-code is sent as a forwarding-status-report even if custody is not taken? I think the rationale is that it's not needed, rather than that it's harmful. 7. With respect to Sec 5.5, some where earlier in the document, we should probably say that "Bundle Age Extension Block" is mandatory when the local clock in the bundle-node is not good (i.e., timestamps are always getting populated with 0)? I think 4.6.3 essentially says this. 8. Sec 5.6 Bundle Reception, Step 3: What should a bundle-node do if it got a block that is unintelligible but the block processing flags are neither indicating deletion of this bundle as a whole nor deletion of this block alone in the bundle? I assume that it should let the block be, and move on processing the other blocks in the bundle, and if forwarding is required, the bundle is to be forwarded with this unintelligible block in place. If so, an explicit statement to this effect may please be added after the three bulleted-paragraphs as the fourth paragraph to provide clarity. I don't think it's unclear but sure, another bullet would be okay. 9. Sec 5.7 Local Bundle Delivery, Step 3, Last bulleted-para: "Succeeded custody signal" is being generated and sent here without going through the custody transfer procedure in Sec 5.10 just based on seeing the "custody-transfer requested" flag. Sec 5.10 should be referred, and Succeeded/Failed indication must be given, right? Doesn't the text already say this? 10. Sec 5.8 Bundle Fragmentation, III Param first-line: Why not? Why should a bundle-node not fragment if another custodian exists? Because the custodian of the original bundle will never receive a custody signal for it, because that original bundle no longer exists. Multiple fragmentation episodes may perhaps result if we allowed it and overlapping fragments may be received. But reassembly seems to be designed to be robust to it (as it should) as in the first bulleted-para following - listing the fragmentation constraints. 11. Sec 5.10.1 Custody Acceptance, V para: After asserting itself as a new current custodian, nominally, I expected the bundle node to delete all the existing current custodians. What is suggested - add itself as a custodian or change any custodian by itself seems arbitrary. Why is this proposed this way? Good point. I would be fine with saying that all pre-existing current custodian blocks should be deleted when the new one is added. 12. Sec 5.10.2 Custody Release, Pg 33: A line may be added in the para to say that persistent storage may be released? Constraint removal enables the bundle to be discarded. The details of this are implementation-dependent; I think we can count on implementers being smart enough to understand that this entails release of persistent storage (as appropriate). 13. Sec 5.12 Custody Transfer Failure, Pg 33, I para: If custody request had been forwarded to multiple bundle-nodes, should we not wait for FAILED message from all of them? Text in "(b)" may be suitably updated for this? Please, no. We are already expending way more energy on custody transfer than is warranted. 14. Sec 5.13 Bundle Deletion, Step 1: II line: "discarded" ==> "deleted"? No, I think "discarded" is correct here. III line: "Custody of the node" ==> "Custody of the bundle"? Yes. 15. Sec 6.1.1 Bundle Status Reports, Pg 35, last para: Like in creation-timestamp case, the receiver should probably set 0 if it does not have a good local clock perhaps? If so, text may be added to this effect? Sure. 16. Sec 8, Last but one para: "'Discard block if it can't be processed' flag unset" ==> "'Discard block if it can't be processed' flag set"? Yes. MINOR 1. Sec 4.2, Pg 16, Last Para: What is the use-case for allowing source-node to be null? Is it to provide an equivalent of "localhost" on UNIX machines? Or its motivation is from security context, perhaps in bundle-in-bundle tunneling type of scenarios? A line or two in this would be nice. The motivation (as I recall) is to enable anonymous traffic. Sure, a line to this effect would be fine. 2. Sec 4.6.2, Line 2: On some scenarios, such as in a long-haul deep-space link, the content in brackets: "(the node at which the bundle currently resides)" may not be true; It might have been deleted there, by the time it reached the receiving BP node - unless in CUSTODY. No, the content in brackets refers to the receiving node, not the sending node. 3. Sec 4.6.3, Line 7: Again, the age-of-the-bundle description in brackets seems to assume negligible transmission delay. Deep-space links? Yes, negligible delay is assumed. Vehicles in deep space have clocks. 4. Sec 5.4, Pg 25, Step 2, After II-para: please remove the redundant(?) lines that go: o o Sure. It's a mysterious artifact of Windows, but it should be solvable. 5. Sec 6.1, Pg 35: Figure for Administrative Record Type codes must be numbered as "Figure 3". There is already a "Figure 2" in the document. Similarly, Pg 37, Figure 3 ==> Figure 4, and all subsequent figures need to be renumbered appropriately. Excellent catch. Yes.