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.
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.
My preference is to have something neutral but that can be ignored as
it is nit.
At 02:44 12-06-2013, John C Klensin wrote:
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.
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