Subject: 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: John C Klensin <[email-masked]>
Date: Sat, 22 Jun 2013 12:59:38 -0400

--On Saturday, June 22, 2013 10:34 -0400 Barry Leiba
<[email-masked]> wrote:

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

FWIW, 

While the above is certainly true, I believe that synonym
relationship is one of the poorer ideas in 2119.  The problem is
that 2026 assigns a rather different interpretation to
"recommended" in the context of Applicability Statements (A/Ss).
That was relatively unimportant when we were almost never using
explicit Applicability Statements but, now that we are doing so
again, I believe that it would be wise to discourage
"RECOMMENDED" and "NOT RECOMMENDED" as synonyms for "SHOULD" and
"SHOULD NOT" unless they are clearly necessary to avoid awkward
sentences and the non-A/S intent is completely clear.

   john

---

From: Barry Leiba <[email-masked]>
Date: Sat, 22 Jun 2013 13:28:27 -0400

>
> I believe that it would be wise to discourage

A fine suggestion, with which I agree.

Barry

---

From: Hector Santos <[email-masked]>
Date: Sat, 22 Jun 2013 14:34:01 -0400

Hi,

I think there are far too many debates on RFC2119 semantics and I think 
it can be reduced by focusing on better technical protocol writing 
skills.  A simple recommendation to always include (if possible) a 
Minimum Requirements table or section can go a long way in removing 
ambiguity.  Some of these docs are just too verbose and design concepts 
too spread out to extract all that is needed. Too easy to have semantic 
conflicts. Things are missed or fall thru the crack.

It should be possible to have an automated RFC parser that pulls and 
extracts the minimum protocol framework configuration. Its been done 
since the 80s with automated configuration/fitting tools.  It can be 
done with IETF protocols as well, perhaps if only to extract a minimum 
requirements table.

Personally, I think RECOMMENDED is closer to a SHOULD than MAY. IMV, a 
SHOULD is a RECOMMENDED, yet still OPTIONAL mode of operation.  So I 
agree the term RECOMMENDED can be used to inform readers what is the 
preferred mode of operation. I personally view it as a DEFAULT ON 
condition where it is programmed for local policy to decide, but it is 
ON out of the box because of the RECOMMENDED mode of operation.  A MAY 
on the other hand is also possible recommendation, but I see it as a 
DEFAULT OFF or ON condition.

    [o] SHOULD OPTION
    [_] MAY OPTION

None of this is concrete of cause, but it should be easier if authors 
were better skilled in writing more precise technical requirements 
outlines to reduce the ambiguity and debates.

--
HLS

---

From: Dave Crocker <[email-masked]>
Date: Sun, 23 Jun 2013 15:00:12 -0700

> A fine suggestion, with which I agree.

For normative vocabulary, synonyms are sinful.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 24 Jun 2013 07:52:39 -0400

They are not synonyms

Lets go back to 1980:

Implementations SHOULD support DES
vs
RECOMMENDED encryption algorithms: DES, IDEA

There are many specifications that specify crypto algorithms that should
not. JOSE and XML Signature should not have required algorithms or even
SHOULD language. The protocols that are built on the specifications are
where the normative language belongs.

-- 
Website: http://hallambaker.com/

---

From: John C Klensin <[email-masked]>
Date: Mon, 24 Jun 2013 08:39:44 -0400

> RECOMMENDED encryption algorithms: DES, IDEA

Actually, that is the point.  The usage above, although much
earlier, reflects the Protocol Specification/ Applicability
Statement split rather well.

But 2119's language makes the two terms substitutable for and
equivalent to each other, which is about as close a definition
of "synonyms" as one can find.  What I said is that making them
equivalent was probably a mistake and that treating them that
was should be discouraged. Others expressed agreement with that
assessment.  

Personally, I don't think the problem is severe enough to reopen
2119.  If others disagree and believe that 2119 is generating
enough problems to be worth an update, I await a draft.

So, other than quibbling about the "synonym" issue -- not
generally, which no one has claimed, but in context with 2119--
are you disagreeing and, if so, about what?

   john

---

From: Hector Santos <[email-masked]>
Date: Mon, 24 Jun 2013 14:51:03 -0400

> are you disagreeing and, if so, about what?

In my view, a SHOULD is just a highly RECOMMENDED mode of operation, the 
preferred mode, the mode that SHOULD be enabled out of the box.

The conflicts I see is whether the usage of a SHOULD means it really is 
a MUST be implemented as described and the exception is when there is no 
other alternative available. A common reference is use EHLO first, 
fallback to HELO.

What is often forgotten is the ON/OFF configuration aspect. So even if 
there is a MUST implement SHOULD thinking, the question is whether there 
is an allowance to disable or turn off the feature, i.e. can an SMTP 
server disable EHLO and operate in pure RFC821 (STD10) mode?  The answer 
to the question is yes, its possible, and therefore all implementations 
MUST be ready in operate in SMTP (821) mode FIRST, ESMTP mode second.

I think the dilemma is that we have new integration needs and in some 
cases, one protocol or set of integrated protocols simple works better 
when a traditional optional technology i.e. SMTP extension, is used. So 
there is a mindset, it seems, a SHOULD is really a MUST and only under 
extreme situations,  the alternative can be used, if presented.

--
HLS

---

From: Michael Thornburgh <[email-masked]>
Date: Mon, 24 Jun 2013 12:47:03 -0700

my feeling and belief is that RFC 2119 only gives SHOULD and RECOMMENDED the same normative requirement level, but that it does not override or change the distinct meanings of these words in English.  sentences using each of these terms have different meanings in English, even when those sentences appear in RFCs.

-michael thornburgh

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John C Klensin
> Sent: Monday, June 24, 2013 5:40 AM 
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 24 Jun 2013 13:52:23 -0600

On 6/24/13 1:47 PM, Michael Thornburgh wrote:
> my feeling and belief is that RFC 2119 only gives SHOULD and
> RECOMMENDED the same normative requirement level, but that it does
> not override or change the distinct meanings of these words in
> English.  sentences using each of these terms have different meanings
> in English, even when those sentences appear in RFCs.

I expect that the subtle differences between these words are lost on
non-native speakers, and even most native speakers, of English. I'd be
genuinely curious to hear that you think the distinct meanings are.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 24 Jun 2013 15:53:50 -0400

The mistake I was attempting to avoid here was concluding that RECOMMENDED should not be used.

It does have a necessary use that is distinct from SHOULD.

Given the number of citations it gets, I am sure someone will be willing to volunteer to do a revision if Scott Bradner is not interested.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 24 Jun 2013 13:08:32 -0700

> genuinely curious to hear that you think the distinct meanings are.

I suspect you are wrong...

In your implication that there is /any/ meaningful distinction made by 
native English speakers when reading an RFC...

For the times I've seen the different words used normatively in RFC, I 
have not discerned any semantic difference.

d/

---

From: Yoav Nir <[email-masked]>
Date: Mon, 24 Jun 2013 20:18:03 +0000

> genuinely curious to hear that you think the distinct meanings are.

"It is RECOMMENDED that implementations send the AUTH_LIFETIME notification at least 4 minutes before the SA is to be deleted, to facilitate the user entering credentials in time."

"The implementation SHOULD send the AUTH_LIFETIME notification at least 4 minutes before the SA is to be deleted, to facilitate the user entering credentials in time."

- What are the subtle differences in meaning between these two sentences?

- Would an implementation written by a native speaker be any different depending on which of the above sentences was in the RFC?

Yoav

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 24 Jun 2013 14:21:19 -0600

> have not discerned any semantic difference.

I agree. (It would have been better for me to say "subtle differences,
if any".)

I'm open to an argument that in standard English "should" has a shade of
obligation and "recommended" has a shade of suggestion, but in practice
(especially in RFCs) those shades are lost.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Melinda Shore <[email-masked]>
Date: Mon, 24 Jun 2013 12:23:42 -0800

> - What are the subtle differences in meaning between these two

I think "I recommend" is rather clearly different from "you should,"
in terms of strength and (in the case of normative text) obligation.
I don't think that "recommend" is useful in the context of an RFC,
may be confusing and a bit subtle, and is probably best avoided.

Melinda

---

From: Alia Atlas <[email-masked]>
Date: Mon, 24 Jun 2013 16:28:47 -0400

I read SHOULD and RECOMMENDED as different.

SHOULD is how a implementation ought to behave unless there are special
circumstances (deployment, additional functionality, better idea).  MUST
says that there are no circumstances special enough to change the behavior.

RECOMMENDED is closer to a Best Current Practice (BCP); so I might write
"It is RECOMMENDED that the network-converged timer have a minimum value of
2 seconds."  but in 10 years, maybe it'll only take 2 microseconds - so
that'll become a bad recommendation!

Alia

---

From: John C Klensin <[email-masked]>
Date: Mon, 24 Jun 2013 16:38:10 -0400

--On Monday, June 24, 2013 16:28 -0400 Alia Atlas
<[email-masked]> wrote:

> SHOULD is how a implementation ought to behave unless there
> are special circumstances (deployment, additional
> functionality, better idea).  MUST says that there are no
> circumstances special enough to change the behavior.
> 
> RECOMMENDED is closer to a Best Current Practice (BCP); so I
> might write "It is RECOMMENDED that the network-converged
> timer have a minimum value of 2 seconds."  but in 10 years,
> maybe it'll only take 2 microseconds - so that'll become a bad
> recommendation!

And that, again, is close to the distinction that a reasonable
person might read into 2026.  But not into 2119 which appears
(at least to me) to make them fully-substitutable alternatives.

The distinction doesn't make the comments made by Peter, Dave,
or others any less valid.  If we told ourselves that readers
should (lower case) infer conformance statements from SHOULD and
applicability ones from RECOMMENDED... well, we would be pretty
delusional.

   john

---

From: "Bradner, Scott" <[email-masked]>
Date: Mon, 24 Jun 2013 21:02:48 +0000

while I like to take credit for the good things in RFC 2119 (and disclaim the bad things) - the
term RECOMMENDED (good or bad)  comes from RFC 1122 

basically I copied the definition section from RFC 1122 for the 1st version of what became RFC 2119.
(see http://www.sobco.com/ids/draft-bradner-key-words-00.txt) 

based on mailing list discussion I produced two revisions of the ID (mostly to add guidance on usage)
http://www.sobco.com/ids/draft-bradner-key-words-01.txt
and
http://www.sobco.com/ids/draft-bradner-key-words-02.txt

the 02 version is what was approved by the IESG as RFC 2119

all of the above is to say that I can not help in this discussion about the difference between SHOULD & 
RECOMMENDED other than the fact they represent  different parts of speech

maybe Bob Braden has an idea since I do find  not a usage of RECOMMENDED in the RFC series before RFC 1122

Scott

---

From: Dave Crocker <[email-masked]>
Date: Mon, 24 Jun 2013 15:05:51 -0700

> may be confusing and a bit subtle, and is probably best avoided.

A number of the notes have offered personal views about the differences 
between the two words.  No doubt each of us could offer such comments. 
And perhaps some of us might even offer similar meanings.

Unfortunately, the ability of one person to impart their own semantic 
distinction is irrelevant to the current discussion, which is about 
normative language used for global standards that are read by widely and 
wildly different people around the world, with extreme differences in 
English language skills.

This is technical specification, not literature.  Subtlety and nuance -- 
especially of a linguistic nature -- is wholly inappropriate.

Just as we find simpler technology propagates better across the 
Internet, so does simpler specification language.

MAY/SHOULD/MUST has proved simple and sufficient.  Any gradations beyond 
that have demonstrated no utility for IETF specifications.

Hell, we still debate the differences of just /those/ 3 words...

d/

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Jun 2013 10:30:50 +1200

> applicability ones from RECOMMENDED... well, we would be pretty

Also, issuing 2119bis with a subtle difference between the two
would create a horrible problem of interpretation for all existing
documents (including numerous documents from other SDOs) that
explicitly cite 2119. This has ramifications that make my head hurt.

   Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 24 Jun 2013 20:33:16 -0400

RECOMMENDED is a strong suggestion that the implementation may override at
the discretion of the implementer. SHOULD is normative.

So the first tells me that I can make up my own mind, the second says that
I should give a reason if I don't comply.

On Mon, Jun 24, 2013 at 4:18 PM, Yoav Nir <[email-masked]> wrote:

> "It is RECOMMENDED that implementations send the AUTH_LIFETIME
> notification at least 4 minutes before the SA is to be deleted, to
> facilitate the user entering credentials in time."
>
> "The implementation SHOULD send the AUTH_LIFETIME notification at least 4
> minutes before the SA is to be deleted, to facilitate the user entering
> credentials in time."
>
> - Would an implementation written by a native speaker be any different
> depending on which of the above sentences was in the RFC?
>
> Yoav
>
>
>

---

From: Dave Cridland <[email-masked]>
Date: Tue, 25 Jun 2013 13:27:57 +0100

> the discretion of the implementer. SHOULD is normative.
Of course, they both mean the same, because the author has (one assumes)
explicitly said that it means what it says in RFC 2119. Applying your own
meanings to words used in specifications is never going to work, because
otherwise I could start waxing lyrical on what exactly a credential meant
(and in traditional spoken English, it relates to authorization rather than
authentication as here).

In ordinary English, without specific guidance as RFC 2119 gives, I'd
consider "should" and "must" as having virtually the same strength, and
"recommended" being far lower. "Should", however, is used for third parties
and also when a requirement has exceptions, conditions, and so on - it's
also used for general conditional statements, too, such as "I'd like that",
which really expands to "I should like that" rather than "I would like
that". Another case is that if I say "Phillip must have read RFC 2119",
I've made an incorrect statement if he hasn't, whereas if I say "Phillip
should have read RFC 2119", then it's clear Phillip would be the one at
fault.

Much of the problem with actual English in specifications comes from the
fact that specifications are written to tell people what something else
should do, and English as a language is more adept at telling you what you
must do, and ideally by using the imperative form instead.

So while I can write, "You must read RFC 2119. Do not attempt to derive
implied meaning not present in RFC 2119", I can only express a desire that
Phillip should do the same.

Dave.

---

From: [email-masked] (Martin Rex)
Date: Tue, 25 Jun 2013 14:31:49 +0200 (CEST)

> I should give a reason if I don't comply.

This is only half of the story.

PKIX (rfc5280) defines the concept of a "minimum requirements RP",
i.e. an implementation which implements only MUSTs, and potentially not
a single SHOULD.  Essentially, this waters down all SHOULDs to MAYs.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 25 Jun 2013 08:52:45 -0400

I DO NOT agree that 2119 is the only source of consequence here.

Perhaps if I showed Dave Cridland an article on netiquete he could try to
be less patronizing. Unlike some here I do not regard the RFC series as
having divine inspiration.

Many other standards organizations use normative language. Though at this
point who is following whom is difficult to determine.

RECOMMENDED is a very useful term to have. Particularly when writing specs
for middleware.

The IETF document describing use of the term is WRONG it needs to be
corrected. Any corrections would only apply to new specs that reference the
new RFC.

On Tue, Jun 25, 2013 at 8:27 AM, Dave Cridland <[email-masked]> wrote:

>> RECOMMENDED is a strong suggestion that the implementation may override
>> at the discretion of the implementer. SHOULD is normative.
>>
>>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 25 Jun 2013 09:03:52 -0400

On Tue, Jun 25, 2013 at 8:31 AM, Martin Rex <[email-masked]> wrote:

> at

>From a minimum implementation point of view MAY, RECOMMENDED and SHOULD all
have the same effect. They are not identical from other points of view.

MAY tells the implementer that there is behavior that they are required to
accept from other implementations they interact with. So it creates an
implicit MUST NOT.

SHOULD tells the implementer that there is behavior that cannot be
compliance checked that is important.

I would like to see more clarity in IETF specs and the minimum use of MUST,
SHOULD and MAY since they all create compliance requirements.
Distinguishing RECOMMENDED from SHOULD properly would help here.

I suggest that if specs want to use RECOMMENDED and SHOULD as not being
synonyms that they follow the reference to 2119 with a statement explaining
the difference.

---

From: Scott Brim <[email-masked]>
Date: Tue, 25 Jun 2013 10:08:24 -0400

> I DO NOT agree that 2119 is the only source of consequence here.

Sorry.  RFCs are not written in English, they are written in RFCish, a
language based in English but with modifications (specified in RFCs).
2119 overrides anything you might think you know about what words
mean.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 25 Jun 2013 14:24:13 -0000

If a document explicitly states that the term "RECOMMENDED" is to be
interpreted as in RFC 2119, then that really is the only
interpretation, and RFC 2119 does then become the only source of
consequence. This is beyond personal opinions.

Perhaps if I showed Dave Cridland an article on netiquete he could try
to be less patronizing. Unlike some here I do not regard the RFC
series as having divine inspiration.

I'm not claiming it's the traditional meaning of the term, just that
RFCs do tend to be explicit in what they mean by it..

I've no idea how I'm being patronizing, but I'm certainly not claiming
any kind of divine inspiration for the RFCs. I'm merely suggesting
that if a document says "This word means X", we should accept that and
move on.

RECOMMENDED is a very useful term to have. Particularly when writing
specs for middleware.

That's an interesting debate to have, but it has no bearing on what
the term means in the context of documents citing RFC 2119.

For what it's worth, I entirely agree that a term with force somewhere
between MAY and SHOULD would be very useful in some cases, but in
general we can work around this, such as saying "implementations are
encouraged to use channel binding", or some such.

The IETF document describing use of the term is WRONG it needs to be
corrected. Any corrections would only apply to new specs that
reference the new RFC.

It's not wrong, it clearly gives a meaning to the term. That meaning
is not in line with the implications it might have if used in spoken
English, certainly, but it's clearly stated, and used in that sense as
far as I can tell.

Dave.

Sent with [inky: <http://inky.com?kme=signature>]

---

From: Hector Santos <[email-masked]>
Date: Tue, 25 Jun 2013 13:13:12 -0400

I want to know more what it translates to as a technical specification 
for CODING.   To me, it means this:

    o Authorization Lift Time
      [X] Send Notification
          Time to send: __4__ mins (default)

The problem as I experienced thus far is whether one MUST IMPLEMENT this 
protocol feature,in this case code for AUTH_LIFETIME and make it 
flexible with a default 4 mins timeout.

At the end of the day, this feature is not functionally described as a 
MUST protocol requirement, therefore as a product producer I have two 
design options:

   1) Don't implement, possible less feature than competitors.
      See if others implement it.

   2) Implement and make it optional as the UI shows above.

So I don't think its a really a language or native culture thing, its 
just poor functional/technical specification writing.  Of course, if one 
does not implement AUTH_LIFETIME and they later find out there are 
interoperability issues with other products in the market, then there is 
a "BUG" in the specification.  It may need to be fixed in a BIS as a 
MUST or maybe the products that failed when a peer did not support it, 
then its considered buggy because it read the above as a MUST.

I would like to see a focus to produce more protocol writing guidelines, 
outline examples and tips on how to best reduce the ambiguity.   I think 
the available RFC templates should include a new section:

    1.x Minimum Requirements

This should help writers focus on these type of issues for the multiple 
discipline readers out there.

--
HLS

---

From: Hector Santos <[email-masked]>
Date: Tue, 25 Jun 2013 13:40:26 -0400

Sounds like an never ending loop. 2119 is an RFC too and thus written in 
"RFCish" as well.

To me, it only matters in terms of implementation - should we waste time 
and money on implementing a SHOULD/RECOMMENDED feature?  Is it required 
to be coded?  Can it be delayed, for version 2.0?  Is it really needed, 
competitively? Will something break if we don't add it?

A good example was the DKIM and BIT8MIME issue.

BIT8MIME is an SMTP extension, therefore NOT REQUIRED by SMTP servers to 
support it.

It was determined the conversion and translation recommendations in 
BIT8MIME helps DKIM function better with less integrity errors, 
therefore there was an argument that all SMTP servers MUST support 
BIT8MIME if they claim to support DKIM. There was an attempt to mandate 
this in DKIM-BIS:

         SMTP Servers MUST support BIT8MIME.

This created an immediate, resounding uproar and negative response 
simply because not every SMTP server supported BIT8 MIME conversions. 
So it was changed back to:

         SMTP Servers SHOULD support BIT8MIME.

This shows the growing integration design and requirements pressure we 
are in, especially with newer protocols that depend on other OPTIONAL 
protocols in order to function correctly.  The same is true with other 
things like international conversions and translations, all currently 
optional for the most part.

--

---

From: Scott Brim <[email-masked]>
Date: Tue, 25 Jun 2013 14:13:15 -0400

On Tue, Jun 25, 2013 at 1:40 PM, Hector Santos <[email-masked]> wrote:
> To me, it only matters in terms of implementation - should we waste time and
> money on implementing a SHOULD/RECOMMENDED feature?  Is it required to be
> coded?  Can it be delayed, for version 2.0?  Is it really needed,

Every vendor goes through that decision process.  Some operators make
SHOULDs required in their RFIs.  The IETF WG decides on what it feels
is a necessary level of interoperability and leaves the rest up to
them.  The IETF is not going to make decisions for you about things it
thinks are optional.

> competitively? Will something break if we don't add it?

If leaving it out breaks something that's required, then it should be
a MUST and you should (not must) say so.

---

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: Yoav Nir <[email-masked]>
Date: Tue, 25 Jun 2013 20:41:35 +0000

Those sentences are here without the context given in RFC 4478. But that RFC is entirely about AUTH_LIFETIME, so if you're not sending it, you're just not implementing the RFC. 

Those sentences are about the timing of sending the message. Upon receipt of the message, the client software prompts the user for credentials, so we'd like to have that message sent soon enough so that a human user will have enough time to enter the credentials before the SA expires. So is specifying 4 minutes a "recommendation" or a "should-level requirement"?

IMO, in normal English this would be a recommendation. But in an RFC this is also a should-level requirement, one that a particular implementation might ignore (if the implementers know that the client in this case has no human user). In terms of code, you do the same thing with both sentences: you make sure your VPN gateway sends AUTH_LIFETIME at least 4 minutes before the SA is scheduled to expire. You might even do 15 if you find out that your users tend to take coffee breaks that last that long.

On Jun 25, 2013, at 8:13 PM, Hector Santos <[email-masked]> wrote:

> I want to know more what it translates to as a technical specification for CODING.   To me, it means this:
> 
> The problem as I experienced thus far is whether one MUST IMPLEMENT this protocol feature,in this case code for AUTH_LIFETIME and make it flexible with a default 4 mins timeout.
> 
> At the end of the day, this feature is not functionally described as a MUST protocol requirement, therefore as a product producer I have two design options:
> 
> So I don't think its a really a language or native culture thing, its just poor functional/technical specification writing.  Of course, if one does not implement AUTH_LIFETIME and they later find out there are interoperability issues with other products in the market, then there is a "BUG" in the specification.  It may need to be fixed in a BIS as a MUST or maybe the products that failed when a peer did not support it, then its considered buggy because it read the above as a MUST.
> 
> I would like to see a focus to produce more protocol writing guidelines, outline examples and tips on how to best reduce the ambiguity.   I think the available RFC templates should include a new section:
> 
>   1.x Minimum Requirements
> 
> This should help writers focus on these type of issues for the multiple discipline readers out there.
> 
> --
> HLS
> 
> 
>

---

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: Hector Santos <[email-masked]>
Date: Tue, 25 Jun 2013 20:15:54 -0400

Good point, timeouts are important and we know in practice, they vary 
for many reasons, and in many cases, there are different functional 
needs depending on human versus automated interfaces/handlers.

Nonetheless, I always prefer being specific when all possible.  I still 
believe this is universal and global and readers will "get it." Give 
them the benefit of the doubt. Its a matter of having better written 
specifications and understanding there are multiple disciplined readers 
and conflicts between administrators (sysops) vs developers (coders).

IMO, in this case because it is related to a required time property 
(including the idea that it could be infinite, forever, zero, -1 or 
otherwise ), it would be up to the protocol specification to clearly 
define what are the boundary conditions for success and failure;

     The implementator MUST offer a reasonable timeout value for the
     AUTH_LIFETIME notification. A RECOMMENDED timeout value is
     4 minutes.  Anything less risk X, Y and Z and anything more has
     shown to cause this or that.

etc, "Being specific is Terrific"

(Note, I am not aware of RFC 4478. I am provided general input because 
this is a general problem.  Maybe its too late for existing specs but 
future specifications can benefit from better guidelines.)

--
HLS

---

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: Doug Barton <[email-masked]>
Date: Wed, 26 Jun 2013 17:26:32 -0700

In English as it is commonly spoken "recommended," and "should" do 
indeed mean different things. Arguably it's unfortunate that 2119 
conflated them, but that's the landscape we're living in.

So if the question is, "How do we improve the normative language in 
RFCs?" we should probably be thinking along the lines of giving more 
details about the conditions related to the things should/recommended 
apply to. I think it was Brian that said a while back that there should 
never be a SHOULD in a doc without an accompanied "unless ..." that 
spells out when the SHOULD can safely not be followed. It's not hard to 
imagine a similar guideline for "RECOMMENDED, because ..." that explains 
why something is recommended, and ideally also spells out the 
consequences if it is not done.

The idea being that 10 years from now a document can stand on its own as 
the repository of information about the topic it describes without 
having to fall back on WG discussions, anecdotes, etc. Another way to 
look at it is to ask the question, "Does this document have everything 
necessary for someone to create an interoperable implementation from 
scratch?"

thoughts?

Doug

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 26 Jun 2013 21:27:31 -0400

+1

I think SHOULD and RECOMMENDED should both be used when there is a strong
suggestion that implementations comply with the following statement unless
there are reasons not to.

Where I think it is time to go beyond 2119 is that we can distinguish two
circumstances:

SHOULD is the preferred term when the reasons are objective, e.g. certain
platforms don't support green flidgets.

RECOMMENDED is the preferred term when the reasons are subjective or
subject to change. I can recommend AES but only on the basis of current
knowledge.

I really don't see hotlinks from other institutions to RFC 2119 as any
problem at all. RFC 2119 will not change even if the IETF updates it. A
document that references 2119 for normative language will continue to do so
unless reissued with a new RFC number.

On Wed, Jun 26, 2013 at 8:26 PM, Doug Barton <[email-masked]> wrote:

> In English as it is commonly spoken "recommended," and "should" do indeed
> mean different things. Arguably it's unfortunate that 2119 conflated them,
> but that's the landscape we're living in.
>
> So if the question is, "How do we improve the normative language in RFCs?"
> we should probably be thinking along the lines of giving more details about
> the conditions related to the things should/recommended apply to. I think
> it was Brian that said a while back that there should never be a SHOULD in
> a doc without an accompanied "unless ..." that spells out when the SHOULD
> can safely not be followed. It's not hard to imagine a similar guideline
> for "RECOMMENDED, because ..." that explains why something is recommended,
> and ideally also spells out the consequences if it is not done.
>
> the repository of information about the topic it describes without having
> to fall back on WG discussions, anecdotes, etc. Another way to look at it
> is to ask the question, "Does this document have everything necessary for
> someone to create an interoperable implementation from scratch?"
>
> thoughts?
>
> Doug
>

---

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