IETF conflict review for draft-zia-route
conflict-review-zia-route-01

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.

I'm a little worried about an application protocol called ROUTE ...