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

The following approval message was sent
From: The IESG
To: Adrian Farrel ,
    draft-zia-route@ietf.org,
    rfc-ise@rfc-editor.org
Cc: IETF-Announce ,
    The IESG ,
    iana@iana.org
Subject: Results of IETF-conflict review for draft-zia-route-04

The IESG has completed a review of draft-zia-route-04 consistent with RFC5742.

The IESG has no problem with the publication of 'Real-time Transport Object
delivery over Unidirectional Transport (ROUTE)'  as
an Informational RFC.

The IESG has concluded that this work is related to IETF work done in TSVWG
and MOPS, but this relationship does not prevent publishing.

The IESG would also like the Independent Submissions Editor to review the
comments in the datatracker related to this document and determine whether or
not they merit incorporation into the document. Comments may exist in both
the ballot and the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-zia-route/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-zia-route/

The process for such documents is described at
https://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]
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.

[Ballot comment]
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

[Ballot discuss]
Thank you for the work done on this topic.

My ballot about the conflict is DISCUSS only because I want 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.

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.

Looking forward to reading about the MOPS interaction,

Regards

-éric