Hi Stewart, As responsible AD I like to add a bit here. Please see inline. The WG will still need to discuss how to address these comments. Regarding the "pre-allocation" of certain bits and code-points, I would tend to agree. I think one can put tham as reserved in this specification. And in cases of where BPv7 and BPv6 (RFC5050) shares registry the actual code-point values are already registered for those purposes. On Wed, 2019-11-06 at 11:22 -0800, Stewart Bryant via Datatracker wrote: > Reviewer: Stewart Bryant > Review result: Not Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-dtn-bpbis-17 > Reviewer: Stewart Bryant > Review Date: 2019-11-06 > IETF LC End Date: 2019-11-12 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > There are quite a number of issues that need to be attended to in this > document. > > None of that is fundamental to the protocol itself, but work is needed to make > this ready for publication as a Proposed Standard. > > ======== > > Major issues: > > It is not clear what the status of this RFC will be relative to RFC5050. > If it modifies the status of RFC5050 it needs to make this clear in the > boilerplate, Abstract and Introduction. As have been pointed out the WG consensus is to not attempt to obsolete RFC 5050 at this point, rather let IRTF obsolete when they think it is not any more relevant. This, has also resulted in a discussion between the IESG and the IRTF chair and IRSG on how do deal with cases where we actually want to obsolete an IRTF stream document. So that is at least possible if the IRTF agrees to it.. > > ======== > > . 0 indicates "no CRC is present." > . 1 indicates "a standard X-25 CRC-16 is present." [CRC16] > . 2 indicates "a standard CRC32C (Castagnoli) CRC-32 is present." > [CRC32C] > > SB> I am surprised that in these more modern times something stronger > than a CRC is not used, for example a crypto hash. Particularly given the > harsh environment that this is targeting. As Lloyd commented this is for basic error checking. There is https://datatracker.ietf.org/doc/draft-ietf-dtn-bpsec/ that defines keyed crypto integrity protection as well as encryption that can be applied to bundles. > > ========= > . The bundle contains a "manifest" extension block. (Boolean) > SB> Given that manifest is not defined yet this seems out of place in an ST > text > > ====== > Relative to the section DTN Time: > > Unix epoch time is the next best option. Like TAI, Unix epoch time > is simply a count of seconds elapsed since a standard epoch. Unlike > TAI, the current value of Unix epoch time is provided by virtually > all operating systems on which BP is likely to run. > > SB> This section needs to be checked by a time expert. > > SB> I think you are saying that you use Unix time, but Unix time > includes leap seconds by double increment, so I don’t think > you are using that because that would give you the measurement > error you are concerned about. I think that what you are using is > a monotonically increasing time based on the Unix epoch. I think > that is what PTP (IEEE1588) is using and PTP might be a better > reference. PTP is likely to become more available in spacecraft > anyway, since it is finding deployment in precision measurement > applications. Thus I am not sure I understand why UET is more > accessible on spacecraft than TAI. Presumably the spacecraft are using > free-running clocks and so will drift, although I understand that > work is in progress to provide time sync to spacecraft for > navigation purposes. > > The argument in this section seems long and will become dated. > Surely all you need to say is that you need a monotonically > increasing time system such as TAI or UNIX time(), and out of > software convenience you choose the latter. However I don’t > think that is what you are actually doing. What I think you are doing > is using TAI with a free running clock that you accept will drift. > So, when I did the AD review I did raise similar concerns, and the note was really intended to answer these questions of why the chosen clock rather than TAI or other clock definitions that would avoid some other issues. I got enough good answers to progress, but apparently the motivation part isn't clear enough to make you comfortable over the choices. > SB> A lot of the text in this section is not really normative and > perhaps belongs in a non-normative appendix. > > ========== > > The following extension block types are reserved for extension > blocks for which a need is anticipated but for which no definitions > yet exist: > > . Block type 13 is reserved for the anticipated Manifest Block. > SB> This should really be handled through an IANA registry. It seems > strange to have text that is semi-definative about anticipated > features in a proposed standard. Same for types 14 and 15. > They should not be in ST text until they are standard. I don't see an issue with removing these forward incomplete references. With the common type namespaces these code-points are reserved for those particular uses already. > > ========= > In the Security Section > > Note that, while the primary block must remain in the clear for > routing purposes, the Bundle Protocol can be protected against > traffic analysis to some extent by using bundle-in-bundle > encapsulation to tunnel bundles to a safe forward distribution > point: the encapsulated bundle forms the payload of an encapsulating > bundle, and that payload block may be encrypted by a BCB. > > SB> Is there a definition of the bundle in bundle protocol? Yes, draft-ietf-dtn-bibext. > > SB> The material that follows seems to be defining protocol which > is unusual in a security section. I would be better to define protocol > in the body of the text or simply point to a definition in another document. > > ========= > > 10.1. Bundle Block Types > SB> The namespaces do not seem to be identified. So searching for "Bundle Block Types" on https://www.iana.org/protocols will find you the registry, so I don't know why you think the namespace isn't identified. Do you missing the general Bundle Protocol category for the registry? > > SB> The IANA reference for new allocations ought to be to this RFC So the registry is actually defined in RFC 6255. And the decision to allow both BPv6 and BPv7 so co-exist and co-use the registry results in this situation.. But I think you are correct in that the reference column of the table should contain both RFC5050 and [RFC-TBA] to make it clear that this is how it is intended to look. > > SB> Given that this is a Standards Document I am surprised that > references to RFC5050 are not replaced with references to this RFC. > Does this indicate that RFC5050 is expected to remain a current protocol. > If so we are in the odd position of a ST text relying on definitions in an > Experimental text. This is something that the IESG needs to consider. > > ========= > The registration policy is changed to "Expert Review". Given the > maximum number of bits available, the allocation should only be > approved with a well-defined specification and proof of real usage. > > SB> I am surprised that it (or some part of it) is not changed to one > of the more difficult critera, such as Standards Action. Also I am > surprised that there are no private use or experimental allocations. With Expert Review I think the argument can be that one don't need to have private use or experimental allocations as any such needs can be dealt with through the expert. From my perspective I think this make sense in this particular case. There is a limted range and re-use of bits for private and experimental purpose is not straightforward. Thus, taking each bit's definition into account if to assign it or not do make sense to me. > > ========= > > 11.1. Normative References > > [BPSEC] Birrane, E., "Bundle Security Protocol Specification", Work > In Progress, October 2015. > > SB> I am not sure what this points to but I think it is RFC6257 > which is experimental and hence is a downref. This needs the proper ref > and the downref addressing. That should be made clear that this is draft-ietf-dtn-bpsec. > > [CRC16] ITU-T Recommendation X.25, p. 9, section 2.2.7.4, > International Telecommunications Union, October 1996. > SB> This shows up in nits as a downref, but I am sure it is OK, > > [CRC32C] Castagnoli, G., Brauer, S., and M. Herrmann, "Optimization > of Cyclic Redundancy-Check Codes with 24 and 32 Parity Bits", IEEE > Transact. on Communications, Vol. 41, No. 6, June 1993. > > SB> I am not sure what the policy is WRT having a normative ref to an IEEE > paper. SB> Information on CRC32C is more accessibly found in RFC3385 > > [EPOCH] Thompson, K. and D. M. Ritchie, "UNIX Programmer's Manual, > Fifth Edition", Bell Telephone Laboratories Inc., June 1974. See > > https://protect2.fireeye.com/v1/url?k=773aa56c-2beea2c0-773ae5f7-8667c4afe13e-8af513574b1eb372&q=1&e=ed73115d-ee55-44cf-bf78-c189ad611603&u=https%3A%2F%2Fwww.tuhs.org%2FArchive%2FDistributions%2FResearch%2FDennis_v5%2Fv5man > . > pdf. > > SB> I am sure this is a fine document but again I am not sure if > you can point to it as normative. > > ========= > > This work is freely adapted from RFC 5050, which was an effort of > the Delay Tolerant Networking Research Group. > > SB> Is it simply adapted? What is the relative standing of the two? > As far as I can see this Standard relies on definitions provided by that RFC. To my understanding the actual BPv7 protocol definition should be stand-alone, but sharing some common infrastructure, like IANA registries. Do you have a particular case where there is a normative dependency to any of the IRTF stream RFCs, other than the IANA regstries? > > ========= > Appendix B. CDDL expression > SB> What is the licence position for the code that follows? > This is not code, it is CDDL so it is format description, comparable to ABNF. As it is submitted under BCP 78 and IETF TPL so I don't see any formal issues with it. Cheers Magnus Westerlund ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx ----------------------------------------------------------------------
<<attachment: smime.p7s>>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
