ietf
[Top] [All Lists]

Re: Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07

2013-06-26 15:04:11
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.


<Prev in Thread] Current Thread [Next in Thread>