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

From: SM <[email-masked]>
Date: Wed, 05 Jun 2013 09:12:30 -0700

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
>[email-masked] 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 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.

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?

Regards,
-sm

---

From: Michael Thornburgh <[email-masked]>
Date: Tue, 11 Jun 2013 14:51:39 -0700

hi SM. thanks for your comments.  sorry for the delay in response; i was on vacation and unable to reply.  replies inline.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Wednesday, June 05, 2013 9:13 AM
> 

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.

> Individual Submission.  I would like to be considered as not part of

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.

> 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.

> -sm

thanks.

-michael thornburgh

---

From: John C Klensin <[email-masked]>
Date: Wed, 12 Jun 2013 05:44:05 -0400

--On Tuesday, June 11, 2013 14:51 -0700 Michael Thornburgh
<[email-masked]> wrote:

>...
> 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.

Michael, SM, and others,

I think the advantages to the community of having
widely-deployed protocols like this published for information
are considerable.  It seems to me that those advantages are
increasingly getting lost in our quest for consensus (or even
unanimity).  Perhaps we should be handling them all as
Independent Submissions where the community wouldn't even think
it had a "vote", but, as Michael points out, community review
often improves document quality.

For such a protocol, information about how widely deployed it is
and even the context in which it is used are important
information, nearly as important as the protocol specification
itself.  Without that information, it would be very hard to tell
a description of a widely-deployed protocol that it is useful
for the community to know about from a description of a fantasy
(or even the product of a fictitious standards body) that the
author hopes others will pick up and use.  By contrast, for
standards-track documents, that information is less important:
it changes more proportionally, the recommendation is based more
on engineering and other technical quality issues, and it is an
IETF recommendation.

So, assuming the document is accurate and clear, I think our
principles should favor publication and should favor publication
with the deployment comment included.

best,
    john

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 12 Jun 2013 13:37:56 +0200

Hi SM,

On 06/05/2013 06:12 PM, SM wrote:
> 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.
>
> Individual Submission.  I would like to be considered as not part of the
> consensus.

The last call is not intended to gather IETF consensus about this draft 
but give the community an opportunity to see the draft and comment on it 
before it progress to the IESG. This draft is an AD sponsored draft.

As Michael also pointed out in his email: The draft has been brought to 
the attention of parts of the Transport Area.

The intention is to document the RTMFP protocol for the general public.

> Shouldn't the memo be about the protocol?

The memo is about the protocol, but it is worth mentioning the 
deployment base.

Regards,

   Martin

-- 
[email-masked]

NEC Laboratories Europe
NEC Europe Limited
Registered Office:
Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB
Registered in England 2832014

---

From: SM <[email-masked]>
Date: Wed, 12 Jun 2013 14:10:03 -0700

Hi Michael,

I am adding my response to John and Martin at the end of this message.

At 14:51 11-06-2013, Michael Thornburgh wrote:
>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.

Thanks for the explanation.  I don't have any problem with the IPR disclosure.

>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.

I'll comment about this in my response to Martin.

>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.

Yes, I noticed that.

>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.

I don't think that any technical concerns which might have been 
raised were not addressed.

>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.

My preference is to have something neutral but that can be ignored as 
it is nit.

>often improves document quality.

Yes.

At 04:37 12-06-2013, Martin Stiemerling wrote:
>The last call is not intended to gather IETF consensus about this 
>draft but give the community an opportunity to see the draft and 
>comment on it before it progress to the IESG. This draft is an AD 
>sponsored draft.

I'll keep it short; the intended status is Informational, it's not 
worth spending too much time arguing about it. :-)

Regards,
-sm