Hi Michael,
Thanks for the continued responses. A few more comments inline. I deleted
sections that did not seem to need further comment. In summary, all of my
concerns are resolved except for the crypto profile question.
Thanks!
Ben.
On Jun 26, 2013, at 2:00 PM, Michael Thornburgh <mthornbu(_at_)adobe(_dot_)com>
wrote:
[...]
with regard to comments in later messages in this thread, i'd be happy to
include some (IESG-
supplied) boilerplate in the document to clarify that it is not the product
of an IETF WG. however,
note that both the title and first sentence of the Introduction indicate
that this is "Adobe's
blahblahblah", consistent with other vendor-protocol RFCs and consistent
with IESG editorial
insistence (as told to me by a former TSV AD). see RFC 4332 and RFC 6802
for two examples of vendor-
specific/supplied protocols. see also the IESG note in RFC 4332 as an
example disclaimer that could
be added.
Some additional text (whether IESG boilerplate or otherwise) that clarifies
the purpose of the draft
would help a lot.
the sponsoring AD has proposed an additional statement that will be inserted
by the RFC Editor on publication. note that draft -08 has additional
clarification that this is an Adobe protocol and is not the product of an
IETF activity.
The additional statement in 08 resolves my concern in the context of this
specific document. (I have mixed feelings about the idea of documenting
proprietary protocols in IETF stream drafts at all, but it's not reasonable to
hold any particular draft hostage over a larger policy question.)
At the time of writing yes. My concern is how a future implementor can be
confident that this doc
describes RTMFP as used by Adobe at points in the future. When you say this
is the authoritative
specification, does that mean that Adobe does not plan to modify the
protocol without timely
publication of an update to this document?
this is a problem for *any* published protocol.
RTMFP (as documented in this memo) hasn't changed substantially in many
years. i have every expectation that, should a change be made to the
protocol, we would publish an updated specification.
(Let me preface this comment: This is also an issue with the general idea of
publishing proprietary protocols in IETF stream documents. I'm not picking on
this draft in particular, and we can consider this issue closed for the
purposes of my Gen-ART review.)
I disagree that this is an issue for any published protocol. In the case of an
IETF produced protocol, an RFC is the definitive specification. If the IETF
chooses to revise the protocol in the future, it does so by publishing a new
RFC that updates or obsoletes the original.
You indicate Adobe plans to do the same, and that this protocol is pretty
stable. You mentioned previously that this document would be the authoritative
specification. So, then maybe there's not an issue. But if Adobe maintains
internal documentation that an Adobe engineer would consult to understand and
implement the protocol, and you revise that documentation internally, it's
going to be pretty tricky keeping the IETF -published specification in sync.
yes, endpoints need a common cryptography profile to interoperate. there
is no repository for
crypto profile documentation at this time. currently, there is one defined
cryptography profile (the
one used for Flash communication) that is not publicly documented, because i
do not yet have
permission to publish it. i (meaning me personally) hope that a memo
documenting the
crypto/application profile for Flash communication (as being a widely
deployed and used profile for
RTMFP) would also be published someday as an I-D and hopefully an
Informational RFC.
I understand the issue about permission to publish, but does this document
serve its purpose until you
are ready to publish the crypto profile? Ideally they would be published
together and this document
would reference that one. Do I infer correctly that there is no way someone
could create an
implementation that interops with Adobe products based on the documents
available at this time?
additional documentation is needed to interoperate (at the application layer)
with the Adobe products that implement RTMFP. i hope that the successful
publication of this memo will help me in getting the necessary approval to
publish the higher layer details of Adobe's RTMFP ecosystem.
the situation is analogous to having published TCP, but there's a lot more
you need to know to talk to a web server with HTTPS (like TLS and HTTP).
it's still useful to know how TCP works, and plenty more to do with it than
talk to web servers.
I don't think that's a fair analogy. I can use TCP for many purposes other than
talking to web servers. It can even be useful all itself. But if I understand
correctly, you can't expect to use RTMFP _at_all_ until you publish they
crypto-profile(s). Is that correct? If so, a better analogy would be to publish
TLS without any published cryptosuites.
If I am correct on the inability to use the protocol at all without more
documentation that does not currently exist, then I think it would be
reasonable to put a clearly worded assertion to that effect early in the draft,
along with a comment that you intend to publish at least one crypto profile in
the future. (Perhaps an applicability statement would be helpful here.)
-- section 3.2: "Multiple endpoints SHOULD NOT have the same identity."
Why not MUST? Will things not break if two endpoints do have the same
identity?
this should be "It is RECOMMENDED that multiple endpoints not have the same
identity." if two
endpoints have the same identity, then they will be indistinguishable. this
will not break RTMFP, but
might confuse an application. that being said, there could potentially be
reasons to have different
endpoints with indistinguishable identities and that potential should not be
normatively prohibited.
As Barry mentioned, RECOMMENDED is a synonym for SHOULD. Adding some text
the effect of your
additional explanation would solve my concern.
i changed this to RECOMMENDED (because while i agree that RECOMMENDED and
SHOULD impart the same force of normative requirement for an implementer, the
words' different English meanings help the reader understand the reason for
the normative constraint). see draft -08 for additional explanation i added
for this constraint.
The added text in 08 resolves my concerns. (I'm not going to get into the
RECOMMENDED vs SHOULD argument other than to note that the thread on the IETF
discussion list tells me that English speakers don't necessarily agree on the
difference :-) )
[...]
*** Nits/editorial comments:
-- General: There's quite a bit of inconsistent use of third-person vs
second-person language.
i will try to clean that up.
Okay.
as i mentioned in a separate message: """i believe the "second-person" voice
in this memo is used exclusively for detailing algorithms that are to be
performed. i believe the imperative "do it like this" voice is appropriate to
that use, so i did not change it. i also feel that the change in voice helps
indicate that the implementation is being addressed/instructed."""
Oops, sorry, I meant to cut that part out of my previous reply after seeing
your other email. I seem to recall finding 2nd person language in sections that
were not clearly identified as algorithm specifications, but on re-review I
can't find it--so consider it dropped.