hi SM. thanks for your comments. sorry for the delay in response; i was on
vacation and unable to reply. replies inline.
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of SM
Sent: Wednesday, June 05, 2013 9:13 AM
At 09:12 28-05-2013, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Adobe's Secure Real-Time Media Flow Protocol'
<draft-thornburgh-adobe-rtmfp-07.txt> as Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2013-06-25. Exceptionally,
comments may be
The write-up mentions that:
"As a private protocol, no technical changes were performed on the
protocol itself, but the authors disclosed more details in
response to the WG discussions."
I don't see why this specification requires IETF consensus as it is
not possible to suggest any major changes. The explanation given for
the intended status is that the aspects of the protocol protected by
IPR were not reviewed externally.
the intended status is Informational because the specification describes a
protocol that was developed outside the IETF, the protocol is in widespread use
in the Internet today, and may be of interest to the Internet community. the
Shepherd write-up does not draw any connection (nor is there any connection)
between the intended Informational status and the existence of IPR. aspects of
the protocol that are protected by IPR are disclosed in the specification and
are (and have been) available for the review of the community. the relevant
IPR was disclosed (IPR 1942) immediately after draft -00 was submitted.
my understanding of the "A-D Sponsored" process for an Informational track
document is that the IETF Last Call should serve as a final check with the IETF
community that there are no important concerns that have been missed or
misunderstood. as this protocol and specification are not products of an IETF
WG, technical changes to the protocol itself are not expected; however, the
specification should be clear and complete enough that an independent and
interoperable implementation could be created from it. i have received
thorough and detailed feedback from several members of the community that i
believe has helped me improve the quality and clarity of the specification.
in the course of face-to-face discussion at IETF-86 in the TSVWG meeting, i was
prompted to disclose additional detail and supplementary information about the
protocol, which i believe improves the clarity of the specification.
The summary is that there is a memo which is not a WG memo, which is
supposed to have gained WG consensus, where some group is supposed to
consider the IPR disclosure, and which is being Last-Called as an
Individual Submission. I would like to be considered as not part of
the consensus.
the memo (and the protocol it describes) is not the product of a WG. the
protocol was presented in person at IETF-77 (in the TSV Area meeting) and
IETF-86 (in the TSVWG meeting), and feedback was solicited on the TSVWG and
MMUSIC mailing lists. at this time i am not aware of any unaddressed concerns
regarding this specification, with the exception of your following comment that
i am about to address.
Nits:
"At the time of writing, the Adobe Flash Player runtime is
installed on more than one billion end-user desktop computers."
Shouldn't the memo be about the protocol?
agreed. i included this statement at the suggestion of the Responsible (and
Sponsoring) Area Director, to help establish the breadth of deployment of the
protocol, and therefore the relevance of the specification in the RFC Series as
an independent submission. the Shepherd, A-D and i are discussing your concern
regarding this statement off-list. possible solutions are: move this comment
to the Shepherd write-up for the IESG's consideration, change the wording to be
more neutral, leave as-is or strike it completely.
Regards,
-sm
thanks.
-michael thornburgh