IETF conflict review for draft-pantos-http-live-streaming
conflict-review-pantos-http-live-streaming-01

The following approval message was sent
From: The IESG
To: draft-pantos-http-live-streaming@ietf.org,
    Nevil Brownlee ,
    rfc-ise@rfc-editor.org
Cc: IETF-Announce ,
    The IESG ,
    iana@iana.org
Subject: Results of IETF-conflict review for draft-pantos-http-live-streaming-23

The IESG has completed a review of draft-pantos-http-live-streaming-23
consistent with RFC5742.


The IESG has no problem with the publication of 'HTTP Live Streaming'
as an Informational RFC.



The IESG has concluded that this work is related to IETF work done in WGs
MMUSIC and AVTCORE,  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-pantos-http-live-streaming/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-pantos-http-live-streaming/

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

Thank you,

The IESG Secretary

[Ballot discuss]
I think Ben's point about the copyright notice warrants a bit of discussion. I realize that this doesn't fall into one of the established RFC 5742 buckets, but it also seems a bit weird to effectively say that this document is not prevented from being published as an RFC, when the document text itself prevents it from being published as an RFC. Would it make sense to note that in the conflict review response?

[Ballot comment]
I agree with Ben's comment that the following statement does not seems to be compatible with the IETF copyright:
"This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft."

[Ballot comment]
I don't object to the final result of the relationship to the work not preventing publication.  However, the text is not one of the rfc5742 options; I don't think we need to qualify the relationship, it either is related or it isn't.

[Ballot comment]
I agree with Ben that the updated MIME registration template should go through MIME expert reviewer. I don't see anything particularly wrong with the new template, so this shouldn't be a problem.

[Ballot comment]
A few comments/questions on the draft itself:

- The draft contains the following addition to the copyright notice: "This document may not be modified,
and derivative works of it may not be created, and it may not be published except as an Internet-Draft.”
While this is up to the ISE to decide, it seems like that notice may preclude publication as an RFC.

- I am concerned at the lack of a privacy discussion in the draft. Authors, please consider adding a privacy consideration section to address questions like the following: What can an on-path third party (e.g. an ISP) learn about the media consumption habits of a person using this mechanism?  Can that be mitigated? If so, how?

- application/vnd.apple.mpegurl is already registered. This appears to be an update to that registration. Has (or will) this update go through the expert review required for the registration of vendor-tree media types?