Subject: [Gen-art] Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07

From: Ben Campbell <[email-masked]>
Date: Thu, 20 Jun 2013 18:06:31 -0500

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-thornburgh-adobe-rtmfp-07
Reviewer: Ben Campbell
Review Date:  2013-06-20
IETF LC End Date: 2013-06-25

Summary: This draft is almost ready for publication as an informational RFC. However, I have some concerns about the purpose and intended status of the document that I think should be considered prior to publication.

Note: This is an informational draft that describes what I understand to be an existing protocol as implemented by commercial products. Therefore, this review does not attempt to evaluate the protocol itself. I assume the protocol is what it is, and it is not up to the IETF to agree or disagree with it.

*** Major issues:

-- Why does this need to be published as an IETF stream RFC?  If I understand correctly, this documents an existing protocol as implemented by commercial products. I agree with Martin's comment that there is value in publishing this sort of thing, but I applaud the Adobe and the author for publishing it so other implementations can interoperate with their products. But that could have done that in an independent stream document, or even in an Adobe published document. (Perhaps even in a prettier format ;-)  )  If we publish this as an IETF stream document, then I think it needs stronger clarification that it is not an IETF consensus doc than just its informational status.

Along those lines:

	-- Is this document the authoritative specification? (I suspect not.) Who owns change control? I assume that to be Adobe and/or the authors. What expectation do readers of this draft have that it represents the current version of RTMFP at any point in time?

	-- Under what circumstances would one desire to implement this? I can infer that from the introduction, but it would be nice to see some sort of applicability statement making it explicitly clear that this is not an IETF protocol, and that one would implement it in order to interoperate with certain Adobe products. I know that some of this may be implied by the fact that this is informational rather than standards track. But I don't expect readers who are not IETF insiders to understand that subtlety without some explicit words to that effect. In particular, it would be good to clarify the difference between this and the many "not quite accepted as standards track by some working group" nature of a number of our informational RFCs that describe protocols.

That all being said, this is overall a well written document. The rest of my comments are mostly pedantic nits.

*** Minor issues:

-- section 1.2: 

I find the use of "MUST ONLY" confusing. I gather it means "you are _allowed_ to do X only under certain conditions" rather than "you are _required_ to do X under certain conditions." If correct, I think the words "MAY ONLY" would be more clear. If not, then I think the construct would be better handled using existing 2119 language.

-- section 3.2:

Do I understand correctly that all endpoints are expected to be able to present certificates? Do you find that common in the field? I realize the nature of the certs will depend on the security profiles.

-- sections 3.2 and 5

Do I assume correctly that endpoints need a common crypto profile to communicate? Is there a repository where one might find crypto profile documentation? Is there a commonly implemented one to which this draft could refer?

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

-- "Authenticity MAY comprise verifying an issuer signature chain in a public key infrastructure"

Is that really normative, or just an observation of fact?

-- " Canonical Endpoint Discriminators for distinct identities SHOULD be distinct."

What if they are not? Do things break? It might be worth making this a MUST, or adding some additional guidance about what might happen if the SHOULD is violated.

-- "A comparison function MAY comprise performing a lexicographic ordering..."

Is that really normative, or just an example of something one might do?

-- "A test SHOULD comprise testing whether the certificates are identical."

What if it doesn't? Also, what constitutes "identical"? All fields match values? Bitwise match?  Is it simply including the same identity or identities? Maybe an identity function provided by the crypto profile?

-- 3.5, last paragraph:

Can you offer guidance on reasonable buffer size and number ranges?

-- 3.5.1.1.1, 3rd paragraph:

What are the consequences of having a tag with less than 8 bytes of length? Is the SHOULD reasonable here?

-- 3.5.1.1.1 throughout, and following sections:

Does the upper case AND have special meaning?

-- 3.5.1.4, Deployment Note:

How would a redirector know which endpoints might do this? Or should it never initiate a session?

-- 3.5.2:

Do I infer correctly that two endpoints need not share the same congestion control algorithm to communicate?

-- 3.6.2.3.2, 2nd paragraph: "...an implementation SHOULD encode a Next User Data chunk instead of a User Data chunk"

I'm not sure why this needs to be normative, as I assume its just normal behavior. But if it does need to be normative, why not a MUST?  Can the far endpoint reasonably handle things if the SHOULD is violated?

*** Nits/editorial comments:

-- General: There's quite a bit of inconsistent use of third-person vs second-person language.

-- 3.1: It would be nice to see the overview earlier in the draft. I found it difficult to read through all the data format stuff prior to section 3 putting them into context.

-- 3.5.1.4, Deployment Note:

s/which/that

-- 3.5.1.6, last paragraph:

Which diagram? (An explicit cross-ref would help.)

-- 3.5.2:

What is meant by "aggressive" in this context? Aggressive in avoiding congestion, or aggressive in sending data?

-- 3.6.2.3.1 and subsequent sections:

Does the all-caps "FIRST" have special meaning?

---

From: Barry Leiba <[email-masked]>
Date: Thu, 20 Jun 2013 22:14:42 -0400

>
> -- Why does this need to be published as an IETF stream RFC?  If I
> understand correctly, this documents an existing protocol as implemented by
> commercial products. I agree with Martin's comment that there is value in
> publishing this sort of thing, but I applaud the Adobe and the author for
> publishing it so other implementations can interoperate with their
> products. But that could have done that in an independent stream document,
> or even in an Adobe published document. (Perhaps even in a prettier format
> ;-)  )  If we publish this as an IETF stream document, then I think it
> needs stronger clarification that it is not an IETF consensus doc than just
> its informational status.

 FWIW, the IESG has discussed this in the context of other documents, and
is looking at boilerplate that does not say that the document is a "product
of the IETF", and makes it clear that the content is not a matter of IETF
consensus.  If that sort of boilerplate was used, do you think that would
be sufficient?

Barry

---

From: John C Klensin <[email-masked]>
Date: Thu, 20 Jun 2013 23:12:05 -0400

--On Thursday, June 20, 2013 22:14 -0400 Barry Leiba
<[email-masked]> wrote:

>  FWIW, the IESG has discussed this in the context of other
> documents, and is looking at boilerplate that does not say
> that the document is a "product of the IETF", and makes it
> clear that the content is not a matter of IETF consensus.  If
> that sort of boilerplate was used, do you think that would be
> sufficient?

FWIW, many IETF Stream Info documents definitely are "matters of
IETF consensus", even more so when those documents are the
consequence of a WG request to publish.   IMO, if a document
really isn't an IETf product in any way and has no relationship
to IETF consensus, it would be far more reasonable for ADs to
simply decline to sponsor it --leaving the document to the
Independent Submission Editor or outside the RFC Series-- rather
than trying to diddle around with boilerplate... especially
since we know that people rarely pay attention to stock
boilerplate.

The option of sponsoring individual submission informational
documents is one that the community granted the IESG in order to
give you folks a reasonable way to deal with circumstances that
were more or less unusual.  You don't need to use it.

   john

p.s. I started a much more detailed response to Ben, but I think
the essence of it is above.  IMO, a discussion that amounts to
whether or not an AD used bad judgment by choosing to sponsor an
individual Informational submission (or whether ADs should have
that power at all) should not become part of evaluating a
particular document's appropriateness.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 20 Jun 2013 22:54:22 -0500

On Jun 20, 2013, at 9:14 PM, Barry Leiba <[email-masked]> wrote:

>  FWIW, the IESG has discussed this in the context of other documents, and is looking at boilerplate that does not say that the document is a "product of the IETF", and makes it clear that the content is not a matter of IETF consensus.  If that sort of boilerplate was used, do you think that would be sufficient?
> 

I think that would help, depending on the specific language. My concerns about change control, authoritative specs, etc might still apply depending on the boilerplate details.

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 20 Jun 2013 22:58:38 -0500

> particular document's appropriateness.

I certainly didn't mean this to be a discussion of AD judgement. I suspect this would not be the first time the IETF has published an informational RFC that describes a non-IETF protocol, so there's probably precedent for doing so. It might be worth discussing whether that's a good precedent.

I also recognize that the authors have done a _lot_ of work on this draft, so this entire discussion is probably a bit unfair to them. I actually do hope it gets published somewhere.

Thanks!

Ben.

---

From: Michael Thornburgh <[email-masked]>
Date: Fri, 21 Jun 2013 14:35:19 -0700

hi Ben. thanks for your review. comments/replies inline.

> From: Ben Campbell [mailto:[email-masked]]
> Sent: Thursday, June 20, 2013 4:07 PM
> 
> Summary: This draft is almost ready for publication as an informational RFC. However, I have some
> concerns about the purpose and intended status of the document that I think should be considered prior
> to publication.
> 
> 
> Note: This is an informational draft that describes what I understand to be an existing protocol as
> implemented by commercial products. Therefore, this review does not attempt to evaluate the protocol
> itself. I assume the protocol is what it is, and it is not up to the IETF to agree or disagree with
> it.
> 
> *** Major issues:
> 
> -- Why does this need to be published as an IETF stream RFC?  If I understand correctly, this
> documents an existing protocol as implemented by commercial products. I agree with Martin's comment
> that there is value in publishing this sort of thing, but I applaud the Adobe and the author for
> publishing it so other implementations can interoperate with their products. But that could have done
> that in an independent stream document, or even in an Adobe published document. (Perhaps even in a
> prettier format ;-)  )  If we publish this as an IETF stream document, then I think it needs stronger
> clarification that it is not an IETF consensus doc than just its informational status.

this memo documents an existing network transport protocol that is widely deployed and in widespread use in the Internet.  we felt that the IETF community (and in particular the participants in the Transport and Services Area) is the most appropriate community with which to share this work: 1) members of this community have the necessary and relevant expertise not only to understand the protocol, but to make use of it potentially in new applications beyond Flash; 2) it is a transport protocol similar in many ways to TCP and SCTP and widely deployed and used; 3) Adobe is interested in pursuing standardization of this protocol (with all that entails) if there is community interest, and the IETF is definitely the right place for that.

we are very grateful that Martin Stiemerling chose to sponsor this document.

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.

> Along those lines:
> 
> 	-- Is this document the authoritative specification? (I suspect not.) Who owns change control? I
> assume that to be Adobe and/or the authors. What expectation do readers of this draft have that it
> represents the current version of RTMFP at any point in time?

this memo is the authoritative specification for Adobe's RTMFP.  Adobe owns change control.  i believe the second and third paragraphs of the Introduction indicate to a reader that this draft represents RTMFP as deployed in the named Adobe products at the time of writing.

> 	-- Under what circumstances would one desire to implement this? I can infer that from the
> introduction, but it would be nice to see some sort of applicability statement making it explicitly
> clear that this is not an IETF protocol, and that one would implement it in order to interoperate with
> certain Adobe products. I know that some of this may be implied by the fact that this is informational
> rather than standards track. But I don't expect readers who are not IETF insiders to understand that
> subtlety without some explicit words to that effect. In particular, it would be good to clarify the
> difference between this and the many "not quite accepted as standards track by some working group"
> nature of a number of our informational RFCs that describe protocols.

i will expand on applicability beyond what i specify in the first paragraph of the Introduction, in general terms such as the kinds of functionality we use this protocol for in Flash. note that interoperation with certain Adobe products, such as Flash Player, requires additional information such as the Flash-specific Cryptography Profile and syntax/semantics of mapping Flash's "Real Time Messaging Protocol (RTMP)" messages onto RTMFP flows.  these Flash-specific profiles and mappings are application-layer for RTMFP, analogous to HTTP over TCP.

> I find the use of "MUST ONLY" confusing. I gather it means "you are _allowed_ to do X only under
> certain conditions" rather than "you are _required_ to do X under certain conditions." If correct, I
> think the words "MAY ONLY" would be more clear. If not, then I think the construct would be better
> handled using existing 2119 language.

you're not the first person to be confused by that construct. i will change instances of "MUST ONLY" to "is allowed only if" (or similar) and remove the definition for "MUST ONLY" from Section 1.2.

> -- section 3.2:
> 
> Do I understand correctly that all endpoints are expected to be able to present certificates? Do you
> find that common in the field? I realize the nature of the certs will depend on the security profiles.

yes, all endpoints have certificates. in the RTMFP-for-Flash world, these certificates are not X.509 certs, and are anonymous and ephemeral.

> -- sections 3.2 and 5
> 
> Do I assume correctly that endpoints need a common crypto profile to communicate? Is there a
> repository where one might find crypto profile documentation? Is there a commonly implemented one to
> which this draft could refer?

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.

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

> Is that really normative, or just an observation of fact?

that "MAY" should be "can".

> What if they are not? Do things break? It might be worth making this a MUST, or adding some additional
> guidance about what might happen if the SHOULD is violated.

i will add a note that if the canonical EPD is the same for two distinct identities, then the "duplicate session" logic in section 3.5.1.1.1 (paragraph 6 step 1) might abort a new opening session to the second identity, which might not be desired.

> Is that really normative, or just an example of something one might do?

that "MAY" should be "can".

> What if it doesn't? Also, what constitutes "identical"? All fields match values? Bitwise match?  Is it
> simply including the same identity or identities? Maybe an identity function provided by the crypto
> profile?

again, that SHOULD should be reworded to RECOMMENDED.  i will change "identical" to "bitwise identical".

> Can you offer guidance on reasonable buffer size and number ranges?

i assume you mean "3.4, last paragraph" (referring to packet reassembly buffers).  i will add some guidance and a "for example".  the guidance will depend on how that RTMFP will be used and the expected amount of resources available to it.

> What are the consequences of having a tag with less than 8 bytes of length? Is the SHOULD reasonable

both of those SHOULDs should be RECOMMENDEDs.

> Does the upper case AND have special meaning?

upper case is the closest to bold face available in this format.  the intention is to emphasize (since there are multiple conditionals) that all conditionals are required to hold.

> How would a redirector know which endpoints might do this? Or should it never initiate a session?

this is guidance for designing and deploying an RTMFP system.  the redirector wouldn't know -- the designer should design the system such that the described circumstance doesn't happen (for example, by having the redirector never initiate a session).  this is properly a SHOULD NOT since doing so can cause undesired behavior (as described).  it is not desirable to give a normative prohibition or recommendation against a redirector initiating any sessions.  i feel this paragraph gives the narrowest normative limitation and an explanation for that limitation.

> Do I infer correctly that two endpoints need not share the same congestion control algorithm to

correct.  the timestamp echo facility, ack behavior (as described for flow receivers), and limitations on aggressiveness in 3.5.2/.* impose the normative envelope in which any congestion control algorithms should interoperate.

> I'm not sure why this needs to be normative, as I assume its just normal behavior. But if it does need
> to be normative, why not a MUST?  Can the far endpoint reasonably handle things if the SHOULD is
> violated?

this should be a RECOMMENDED.  the far end will work just fine if Next User Data is never used.

> -- General: There's quite a bit of inconsistent use of third-person vs second-person language.

i will try to clean that up.

> -- 3.1: It would be nice to see the overview earlier in the draft. I found it difficult to read
> through all the data format stuff prior to section 3 putting them into context.

others have commented that they'd prefer sections 2 and 3 to be swapped. i resisted that as this order ("here are the pieces" and then "here's how they fit together") is my preferred way of explaining stuff.  also swapping those sections would be a huge editorial change which might have significant cross-reference and forward/back reference implications and could introduce hard-to-detect errors into the spec.  however, i think i can move the overview (or a summary thereof) to earlier in the spec (probably in Section 1).

> -- 3.5.1.4, Deployment Note:

good catch.

> Which diagram? (An explicit cross-ref would help.)

oops. that paragraph used to be the postamble of the figure, so it obviously meant "this figure".  i'll change "the figure" to "Figure 17".

> What is meant by "aggressive" in this context? Aggressive in avoiding congestion, or aggressive in

aggressive in sending data. i'll make that clarification.

> Does the all-caps "FIRST" have special meaning?

it is all-caps for typographical emphasis.

thank you!

-michael thornburgh

---

From: Barry Leiba <[email-masked]>
Date: Sat, 22 Jun 2013 10:34:42 -0400

> you're not the first person to be confused by that construct. i will change instances of
> "MUST ONLY" to "is allowed only if" (or similar) and remove the definition for "MUST
> ONLY" from Section 1.2.

I think this is an excellent idea.  RFC 6919 aside (ahem), it's rarely
a good idea to try to define new 2119-ish key words.

Speaking of which (my comments after a bunch of quotes)...

> 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.
...
>> What if it doesn't?
> again, that SHOULD should be reworded to RECOMMENDED.
...
> both of those SHOULDs should be RECOMMENDEDs.
...
>> -- 3.6.2.3.2, 2nd paragraph: "...an implementation SHOULD encode a Next
>> User Data chunk instead of a User Data chunk"
>>
>> I'm not sure why this needs to be normative, as I assume its just normal
>> behavior. But if it does need to be normative, why not a MUST?  Can the far
>> endpoint reasonably handle things if the SHOULD is violated?
>

In RFC 2119, "SHOULD" and "RECOMMENDED" are synonymous (they're just
covering different parts of speech; they fit differently into
sentences).  Changing "SHOULD" to "RECOMMENDED" (and, of course,
rewording the sentences accordingly) doesn't affect Ben's comments on
the points.

"MUST" means that the protocol will not work properly unless you do
this.  You just have to, without fail.

"SHOULD" (and "RECOMMENDED") is really only a *little* lighter: it
still means that the protocol requires that you do this, but that
there might be good reasons not to -- you have to fully understand
what will happen if you don't do this before you can consider not
doing it.

To my mind (and I consider this when I do IESG Evaluation on documents
with SHOULD), whenever a document uses SHOULD (or RECOMMENDED) it
needs to (one might say "SHOULD") make it very clear what will happen
if you don't do this, so that implementors can have that necessary
understanding.  Perhaps the protocol will fail in some unusual
situations.  Perhaps it will break compatibility with older clients.
Perhaps it will still work, but will adversely affect performance.

But without an explanation, there's no way for implementors to meet
the terms in RFC 2119:

   3. SHOULD   This word, or the adjective "RECOMMENDED", mean that
   there may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

If something is simply a suggested value or response, the text should
say it that way.  If it's a suggestion that really is a best-practice
recommendation that comes from a lot of experience with the protocol,
the text should say that, without the 2119 key words.

For the first item, in Section 3.2, for example, you say:

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

That might well be a valid "SHOULD".  Don't change it to "RECOMMENDED"
(or do, if you like), but put in the explanation that you have here.
It would be especially helpful if you can also include an example of a
reason, and/or say something about the consequences of the confusion
it will cause.

For the cases of 3.5.1.1.1 and 3.6.2.3.2, it seems that you don't want
2119 key words there at all: these look like recommendations (not in
the 2119 sense) that are based on what's been deployed already, and it
would simply be good to make that clear: "implementation experience
suggests [x]".

Barry

---

From: Michael Thornburgh <[email-masked]>
Date: Tue, 25 Jun 2013 12:02:45 -0700

hi Ben, all.

i have uploaded a new revision -08 of this draft that addresses comments raised during the IETF Last Call, which has now concluded.

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

thank you for helping to improve the quality of this document.

-michael thornburgh

> From: Michael Thornburgh
> Sent: Friday, June 21, 2013 2:35 PM
> 
> this memo documents an existing network transport protocol that is widely deployed and in widespread
> use in the Internet.  we felt that the IETF community (and in particular the participants in the
> Transport and Services Area) is the most appropriate community with which to share this work: 1)
> members of this community have the necessary and relevant expertise not only to understand the
> protocol, but to make use of it potentially in new applications beyond Flash; 2) it is a transport
> protocol similar in many ways to TCP and SCTP and widely deployed and used; 3) Adobe is interested in
> pursuing standardization of this protocol (with all that entails) if there is community interest, and
> the IETF is definitely the right place for that.
> 
> 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.
> 
> > Along those lines:
> >
> this memo is the authoritative specification for Adobe's RTMFP.  Adobe owns change control.  i believe
> the second and third paragraphs of the Introduction indicate to a reader that this draft represents
> RTMFP as deployed in the named Adobe products at the time of writing.
> 
> i will expand on applicability beyond what i specify in the first paragraph of the Introduction, in
> general terms such as the kinds of functionality we use this protocol for in Flash. note that
> interoperation with certain Adobe products, such as Flash Player, requires additional information such
> as the Flash-specific Cryptography Profile and syntax/semantics of mapping Flash's "Real Time
> Messaging Protocol (RTMP)" messages onto RTMFP flows.  these Flash-specific profiles and mappings are
> application-layer for RTMFP, analogous to HTTP over TCP.
> 
> you're not the first person to be confused by that construct. i will change instances of "MUST ONLY"
> to "is allowed only if" (or similar) and remove the definition for "MUST ONLY" from Section 1.2.
> 
> > -- section 3.2:
> >
> 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.
> 
> 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.
> 
> i will add a note that if the canonical EPD is the same for two distinct identities, then the
> "duplicate session" logic in section 3.5.1.1.1 (paragraph 6 step 1) might abort a new opening session
> to the second identity, which might not be desired.
> 
> i assume you mean "3.4, last paragraph" (referring to packet reassembly buffers).  i will add some
> guidance and a "for example".  the guidance will depend on how that RTMFP will be used and the
> expected amount of resources available to it.
> 
> upper case is the closest to bold face available in this format.  the intention is to emphasize (since
> there are multiple conditionals) that all conditionals are required to hold.
> 
> this is guidance for designing and deploying an RTMFP system.  the redirector wouldn't know -- the
> designer should design the system such that the described circumstance doesn't happen (for example, by
> having the redirector never initiate a session).  this is properly a SHOULD NOT since doing so can
> cause undesired behavior (as described).  it is not desirable to give a normative prohibition or
> recommendation against a redirector initiating any sessions.  i feel this paragraph gives the
> narrowest normative limitation and an explanation for that limitation.
> 
> > -- 3.5.2:
> >
> correct.  the timestamp echo facility, ack behavior (as described for flow receivers), and limitations
> on aggressiveness in 3.5.2/.* impose the normative envelope in which any congestion control algorithms
> should interoperate.
> 
> others have commented that they'd prefer sections 2 and 3 to be swapped. i resisted that as this order
> ("here are the pieces" and then "here's how they fit together") is my preferred way of explaining
> stuff.  also swapping those sections would be a huge editorial change which might have significant
> cross-reference and forward/back reference implications and could introduce hard-to-detect errors into
> the spec.  however, i think i can move the overview (or a summary thereof) to earlier in the spec
> (probably in Section 1).
>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 25 Jun 2013 18:09:59 -0500

Thanks for the response! Comments inline:

Thanks!

Ben.

> 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, not…

Some additional text (whether IESG boilerplate or otherwise) that clarifies the purpose of the draft would help a lot.

> this memo is the authoritative specification for Adobe's RTMFP.  Adobe owns change control.  i believe the second and third paragraphs of the Introduction indicate to a reader that this draft repre…

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?

> i will expand on applicability beyond what i specify in the first paragraph of the Introduction, in general terms such as the kinds of functionality we use this protocol for in Flash. note that int…

Okay

> you're not the first person to be confused by that construct. i will change instances of "MUST ONLY" to "is allowed only if" (or similar) and remove the definition for "MUST ONLY" from Section 1.2.

Works for me.

> yes, all endpoints have certificates. in the RTMFP-for-Flash world, these certificates are not X.509 certs, and are anonymous and ephemeral.

Okay.

> 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 o…

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?

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

As Barry mentioned, RECOMMENDED is a synonym for SHOULD. Adding some text the effect of your additional explanation would solve my concern.

> that "MAY" should be "can".

Okay.

> i will add a note that if the canonical EPD is the same for two distinct identities, then the "duplicate session" logic in section 3.5.1.1.1 (paragraph 6 step 1) might abort a new opening session t…

Okay.

> that "MAY" should be "can".

Okay.

> again, that SHOULD should be reworded to RECOMMENDED.  i will change "identical" to "bitwise identical".

See my earlier comment on SHOULD vs RECOMMENDED. The important thing is to clarify the implications of violating the SHOULD.

> i assume you mean "3.4, last paragraph" (referring to packet reassembly buffers).  i will add some guidance and a "for example".  the guidance will depend on how that RTMFP will be used and the exp…

That would probably help. The important thing is to help implementers avoid bad decisions on buffer size ranges.

> both of those SHOULDs should be RECOMMENDEDs.

See previous comment

> upper case is the closest to bold face available in this format.  the intention is to emphasize (since there are multiple conditionals) that all conditionals are required to hold.

Understood. I'm not sure if there is a convention for that--I guess the RFC editor will either leave it or advise something else.

> this is guidance for designing and deploying an RTMFP system.  the redirector wouldn't know -- the designer should design the system such that the described circumstance doesn't happen (for example…

Okay. Some words to that effect would help.

> correct.  the timestamp echo facility, ack behavior (as described for flow receivers), and limitations on aggressiveness in 3.5.2/.* impose the normative envelope in which any congestion control al…

Okay.

> this should be a RECOMMENDED.  the far end will work just fine if Next User Data is never used.

See previous comments on SHOULD vs RECOMMENDED.

> i will try to clean that up.

Okay.

> others have commented that they'd prefer sections 2 and 3 to be swapped. i resisted that as this order ("here are the pieces" and then "here's how they fit together") is my preferred way of explain…

Okay.

> oops. that paragraph used to be the postamble of the figure, so it obviously meant "this figure".  i'll change "the figure" to "Figure 17".

Okay.

> aggressive in sending data. i'll make that clarification.

Okay.

---

From: Michael Thornburgh <[email-masked]>
Date: Wed, 26 Jun 2013 12:00:19 -0700

comments inline.

> Sent: Tuesday, June 25, 2013 4:10 PM
> 	

[...]

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

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.

> > this memo is the authoritative specification for Adobe's RTMFP.  Adobe owns change control.  i
> believe the second and third paragraphs of the Introduction indicate to a reader that this draft
> represents RTMFP as deployed in the named Adobe products at the time of writing.
> 
> 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.

[...]

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

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

[...]

> > i will try to clean that up.

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

[...]

thanks.

-michael thornburgh

---

From: Ben Campbell <[email-masked]>
Date: Wed, 26 Jun 2013 15:03:39 -0500

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

[...]

> 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 i…

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

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

> 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 ple…

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

> 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 re…

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 :-) )

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

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.

---

From: Michael Thornburgh <[email-masked]>
Date: Wed, 26 Jun 2013 14:08:24 -0700

hi Ben. comment inline.

> Sent: Wednesday, June 26, 2013 1:04 PM
> 
> 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.
> 

[...]

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

interoperating with the Flash ecosystem requires additional documentation. i agree that a better analogy is publishing TLS without any published cryptosuites.

using RTMFP requires _a_ cryptography profile. this memo describes the required semantics of a cryptography profile.  the first bullet of Section 1.1 "Design Highlights" (which occurs on the first page after the TOC), Section 2.2.3 "Encryption", and the first paragraph of the Security Considerations section all indicate that this protocol defines a general framework for security, and that the application designer chooses/defines the algorithms and data formats to be used within that framework.  an application designer could, using only this memo (and knowledge of security and cryptography principles), define her own cryptography profile suitable for her application of RTMFP, and create a correct and useful RTMFP application.

since i don't yet have permission, i can't make a commitment in this memo that Adobe will (or intends to) publicly document any additional layers of the RTMFP-in-Flash ecosystem.  just for extra clarification: it is my *personal* hope that i will be able to do so in the future.

[...]

thanks!

-michael thornburgh

---

From: Jari Arkko <[email-masked]>
Date: Thu, 27 Jun 2013 08:20:30 -0400

Ben, thank you very much for the review, and Michael, thank you for answering and addressing the issues. 

I am still concerned about the crypto profile question, however. I'd like to understand what the lack of a profile specification means for interoperability and the ability of others to use this spec.

Jari