RE: Last Call: <draft-thornburgh-adobe-rtmfp-07.txt> (Adobe's Secure Real-Time Media Flow Protocol) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] 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@xxxxxxxx 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






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]