Ballot for conflict-review-zia-route
Yes
No Objection
Note: This ballot was opened for revision 00 and is now closed.
Ballot question: "Is this the correct conflict review response?"
I'm a little worried about an application protocol called ROUTE ...
Thank you for the work done on this topic. Zahed, I strongly suggest to extend the conflict note by citing MOPS. My previous ballot about the conflict is DISCUSS only because I wanted to get a reply from the authors on whether this work was presented at Media Operations (MOPS) working group: this document would perfectly fit MOPS interest. Of course, MOPS is not chartered to do protocol work but getting feedback from the MOPS WG would have benefited the IETF community. Authors replied that it was presented at GGIE (informal precursor of MOPS) and was also shared in the MOPS mailing list: https://mailarchive.ietf.org/arch/msg/mops/XFNWw13MHPhl4VSQbM_EHQlpy9s/ As side notes (nothing blocking here), I only regret the very misleading ROUTE name. I also wonder whether the metadata "connection ID" (not specified in the doc) supports both IPv4 and IPv6 addresses. Regards -éric
This seems like the correct conflict-review response. Some comments on the draft itself: Abstract The ROUTE protocol is suitable for unicast, broadcast, and multicast transport. Therefore, it can be run over IP/UDP including multicast The phrase TCP/IP is nearly-universal for referencing TCP running over IP, such that one might interpret IP/UDP to refer to running IP over UDP (presumably also over IP). Perhaps "UDP/IP" is easier on the reader, here (and doubly so given that §1.2 uses the "UDP/IP" spelling). Section 1 Unidirectional transport in this document has identical meaning as in RFC 6726 [RFC6726]. [...] Interestingly, RFC 6726 doesn't seem to actually provide an explicit definition of the term, which is somewhat unfortunate. Section 3.2 contentType (o) - A string that SHALL represent media type for the media content. It SHALL obey the semantics of the Content-Type header nit: "the media type" as specified by HTTP/1.1 protocol in RFC 7231 [RFC7231]. This draft-ietf-httpbis-semantics might be a better reference here, as it is going to obsolete RFC 7231. (Also later on, e.g., in §4.2.) Section 9.2 In contrast to the FDT in RFC 6726 [RFC6726], Section 3.4.2 and MBMS [MBMS], Section 7.2.10, besides separated delivery of file metadata from the delivery object it describes, the FDT functionality in ROUTE may be extended by additional file metadata and rules that enable the receiver to generate the Content-Location attribute of the File element of the FDT, on-the-fly, by using information in both the extensions to the FDT and the LCT header. [...] (nit) this sentence is quite long and somewhat convoluted; it might be worth trying to split it into multiple sentences. Section 11 I did not read carefully enough to note whether the @Expires attribute limits the usability of the actual content or just the FEC data, but it seemed like the limitation there relied on the receiver heeding the restriction, such that a misbehaving receiver would be able to use the content or FEC data in question after the listed expiration time. It's not entirely clear to me if that's significant enough to be worth mentioning in the security considerations, especially if the main use case for ROUTE is inside a single administrative domain, with conversion to HTTP for transport to the external endpoints. When ROUTE is carried over UDP, then the security mechanisms provided in RFC 6347 [RFC6347] SHALL apply. DTLS 1.3 is nearing completion; you may want to consider whether it should be permitted (and whether any adaptation would be needed -- the main question that I see is whether a profile for use of 0-RTT could or should be defined). Section 13.2 If this was an IETF-stream document I think there would be strong pressure to reclassify some of these references as normative (e.g., RFCs 3740 and 6347) owing to SHOULD-level guidance for their usage. Of course, https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ does not apply to ISE documents so I don't actually object to the current classification.