Subject: Re: [Gen-art] genART review of draft-ietf-cdni-logging-15

From: Jari Arkko <[email-masked]>
Date: Thu, 5 Mar 2015 13:14:56 +0200

Thanks for your detailed review, Martin, and for your work on this important document, Francois. Where are we with the updates? I chose to hold a Discuss on the IESG telechat to ensure that a couple of things are resolved. But if you already have changed text, I could clear.

Jari

On 16 Feb 2015, at 17:16, Francois Le Faucheur (flefauch) <[email-masked]> wrote:

> Hi,
> 
> Thank you Martin. 
> We are working on this.
> 
> Francois
> 
>> On 12 Feb 2015, at 02:24, Martin Thomson <[email-masked]> wrote:
>> 
>> And because I hit send too soon, here's more...
>> 
>> I think that this is ready.  I have a couple of major concerns:
>> 
>> Major General 1.
>> 
>> However, I would like to see more consideration given to forward
>> compatibility.  There are a lot of normative statements regarding what
>> MUST be included in the file, but no actions described for a receiver.
>> That means that it is hard to establish expectations regarding file
>> format evolution.  If the file is rejected when the version isn't
>> "CDNI/1.0", then that makes changes to that field impossible (and the
>> specification of ABNF for it somewhat pointless).
>> 
>> Major Specific 2.
>> 
>>  An implementation of the CDNI Logging interface MUST support the
>>  TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite ( [RFC5288]).
>> 
>> Please don't do that.  There are mandatory to implement cipher suites
>> in all the specs you cite and you don't need anything special here.  I
>> have no problem with recommending PFS suites, but you might be better
>> served there by citing the uta TLS usage draft:
>> https://tools.ietf.org/html/draft-ietf-uta-tls-bcp
>> 
>> S 3.4.1
>>  o  cs(<HTTP-header-name>):
>> HTTP header fields, esp. in HTTP/2 can contain HTAB, even if that
>> isn't permitted by the grammar.  You probably want to describe how
>> that is handled.
>> 
>> Bottom of P33 (won't adding the established-origin directive
>> invalidate the MD5?  What do you expect to happen there?  (I see two
>> choices, it would help if you could even *hint* at what you would
>> prefer implementations to do).
>> 
>> Nit: HTTP/2 not HTTP/2.0
>> 
>> Question: There is no mention made of range requests, for which this
>> might be well suited, particularly if files get large.
>> 
>> I note the privacy considerations are pretty reasonable.  I'd be much
>> happier if IP anonymization were not optional though.
>> 
>> 
>> 
>> On 12 February 2015 at 12:02, Martin Thomson <[email-masked]> wrote:
>>> 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-ietf-cdni-logging-15
>>> Reviewer: Martin Thomson
>>> Review Date: 2015-02-12
>>> IETF LC End Date: 2015-02-18
>>> IESG Telechat date: (if known)
>>> 
>>> Summary:
>>> 
>>> Major issues:
>>> 
>>> Minor issues:
>>> 
>>> S3.1 needs to define the basic atom that is used for the logging file.
>>> It appears as though the atom is an octet.
>>> 
>>> S3.2 uses the wildcard ABNF rule (i.e., <text....>) too aggressively.
>>> RECLINE (a potentially confusing name) could be more strictly defined.
>>> 
>>>   <CDNI Logging File> = 1*<DIRGROUP RECGROUP>
>>> 
>>> ... is not valid and could be:
>>> 
>>>   CDNI-LOG-FILE = 1*(DIRGROUP / RECGROUP)
>>> 
>>> That implies that an empty file is not valid.  I'd have thought that *
>>> rather than 1* would be better.
>>> 
>>> S3.3 again uses wildcard rules too aggressively.  DIRNAME (not the
>>> unix command) should be defined more explicitly, even if it is just to
>>> specify what characters are allowed.  Use text to further constrain
>>> it.  As it stands, a generic processor cannot know that the name
>>> doesn't permit the inclusion of (for instance) ":" or CRLF.  A common
>>> method is to define something like this as:
>>> 
>>>   DIRNAME = Version-directive / UUID-directive / ... / extension-directive
>>> 
>>> More commonly, go up a level and define directive using the choice.
>>> That way, each directive can define a name and value together using
>>> ABNF.  e.g.
>>> 
>>>   Version-directive = "Version" ":" HTAB "CDNI" "/" 1*DIGIT "." 1*DIGIT
>>> 
>>> I wouldn't be so prescriptive about the version format.  Unless there
>>> are specific semantics you want to extract from each digit.
>>> 
>>> What is a receiver expected to do if the version *isn't* CDNI/1.0 ?
>>> Discard the entire file?  That doesn't seem like a good way to ensure
>>> forward compatibility.
>>> 
>>> UUID: this a Universally Unique IDentifier (UUID)
>>>        from the UUID Uniform Resource Name (URN) namespace specified
>>>        in [RFC4122]) for the CDNI Logging File.
>>> 
>>> I don't know how to apply this.  Is it the UUID portion of the URN or a URN?
>>> 
>>> Please don't use MUST here: If the
>>>        two values are equal, then the received CDNI Logging File MUST
>>>        be considered non-corrupted.
>>> 
>>> MD5 collisions are easy to manufacture.  I'd also drop the MUST from
>>> the following sentence.
>>> 
>>> S3.4: more wildcards
>>> 
>>> S3.4.1: I wouldn't worry about HTTP/2 being special here.  All that
>>> speculation is painful, especially since HTTP/2 will likely be
>>> published before this document.  Better to just cite it and avoid
>>> getting caught up in the details.
>>> 
>>> 
>>> 
>>> 
>>> Nits/editorial comments:
>>> 
>>> There are lots of uses of lowercase "may".
>>> 
>>> Page 6 has a few instances of missing hyphens in dCDN3/dCDN2 etc...
>>> S6.2.1: chunck
>>> 
>>> S3.1 the DATE/TIME rules can/should reference RFC 3339
>>> 
>>> S3.3 using ":" HTAB as a separator makes it hard to construct these
>>> files manually.
>>> 
>>> S3.4 use of "c:" in combination with the unordered list is confusing
>>> when the prefix is actually "c-".  Maybe use the string "c-" quotes
>>> and all to denote the prefix.
>>> 
>>> S3.4.1 citing RFC 7230 is sufficient for HTTP/1.1; and probably for
>>> HTTP in general at this moment.
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 5 Mar 2015 12:53:54 +0000

Hello Jari,

I have responded to Klaas, Adrian and Richard’s comments.

I have not yet worked on the gen-art comments but will get onto those next.

Thanks everyone for working on our document.

Francois

> On 5 Mar 2015, at 12:14, Jari Arkko <[email-masked]> wrote:
>

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 5 Mar 2015 15:21:42 +0000

Hello Martin,

Thanks for your thorough review. Please see proposed resolution or reponse below:

On 12 Feb 2015, at 02:24, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

Major General 1.

format evolution.

Good point.

I have added this at the end of S3.3:

NEW:
“
An uCDN-side implementation of the CDNI Logging interface MUST reject a CDNI Logging File that does not comply with the occurences specified above for each and every directive. For example, an uCDN-side implementation of the CDNI Logging interface receiving a CDNI Logging file with zero occurence of the Version directive, or with two occurences of the Integrity-hash, SHOULD reject this CDNI Logging File.
"

And also edited the end of S3.4 as per the following:

OLD:
"
 An uCDN-side implementation of the CDNI Logging interface MUST be
   able to accept CDNI Logging Files with CDNI Logging Records of
   Record-Type "cdni_http_request_v1" containing any CDNI Logging Field
   defined in Section 3.4.1 as long as the CDNI Logging Record and the
   CDNI Logging File are compliant with the present document.
“
NEW:
“
 An uCDN-side implementation of the CDNI Logging interface MUST be
   able to accept CDNI Logging Files with CDNI Logging Records of
   Record-Type "cdni_http_request_v1" containing any CDNI Logging Field
   defined in Section 3.4.1 as long as the CDNI Logging Record and the
   CDNI Logging File are compliant with the present document.

In case, an uCDN-side implementation of the CDNI Logging interface receives a CDNI Logging File with HTTP Request Logging Records that do not contain field values for exactly the set of field names actually listed in the preceding “Fields” directive, the implementation SHOULD reject those HTTP Request Logging Records, and SHOULD accept the other HTTP Request Logging Records .
"

If the file is rejected when the version isn't
"CDNI/1.0", then that makes changes to that field impossible (and the
specification of ABNF for it somewhat pointless).

Right, the expectation is not that the file be rejected if the version is not "CDNI/1.0”.

I have incorporated the following change:

OLD:
"
The value MUST be "CDNI/1.0" for the version specified
         in the present document.
“
NEW:
“
The entity transmitting a CDNI Logging File as per the present document MUST set the value to "CDNI/1.0”. In the future, other versions of CDNI Logging File might be specified; those would use a value different to "CDNI/1.0” allowing the entity receiving the CDNI Logging File to identify the corresponding version.
"

Major Specific 2.

Absolutely. We were not aware of the TLS BCP which is why we tried to make some minimum recommendations, but we’d much rather leverage teh UTA work.

Here’s the edit that has been incorporated:
OLD:
“
   An implementation of the CDNI Logging interface MUST support the
   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite ( [RFC5288]).  An
   implementation of the CDNI Logging interface SHOULD prefer cipher
   suites which support perfect forward secrecy over cipher suites that
   don't.
"
NEW:
"
 The general TLS usage guidance in [I-D.ietf-uta-tls-bcp] SHOULD be
   followed.
“

S 3.4.1

Since the value of the HTTP header is encoded as a “quoted string” (QSTRING), is it not OK to have a HTAB within the HTTP header value as long as it is properly bracketed by the Quotes?

Bottom of P33 (won't adding the established-origin directive
invalidate the MD5?
What do you expect to happen there?  (I see two
choices, it would help if you could even *hint* at what you would
prefer implementations to do).

Yes, adding the established-origin directive invalidate the MD5. So it needs to be recalculated after adding an established-origin directive.

The text specifying the Integrity Hash already covers that :
"
         If the entity
         receiving a non-corrupted CDNI Logging File adds an
         Established-Origin directive, it MUST then recompute and update
         the Integrity-Hash directive so it also protects the added
         Established-Origin directive.
“

Do you see that we need to say something more?

Nit: HTTP/2 not HTTP/2.0

Fixed.

The document says that "client-side implementation of the CDNI Logging interface MAY pull, at its convenience, a CDNI Logging File “ using standard HTTP. Since range request is just a standard HTTP mechanism, the clien-side may use it if it sees fit.
Do you feel it is worth specifically calling out that range requests can be used?
No problem in doing that if you feel it is useful.

I note the privacy considerations are pretty reasonable.

Great.

 I'd be much

Hmm.
As discussed in response to another related comment, I see value in leaving the choice.
For example, exchanging full IP address can help with some use cases such as fault tracking across the interconnected CDNs.
Also, logging full IP address is the standard practise today in a single CDN environment, so CDN operators are likely to expect that from an interconnected CDN , unless there are reasons to anonymize in a particuylar environment.

I’ll address your other batch of comment separately.

Francois

On 12 February 2015 at 12:02, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

Summary:

Major issues:

Minor issues:

S3.4: more wildcards

Nits/editorial comments:

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 5 Mar 2015 15:24:28 +0000

Hi Jari,

I have an interim version that addresses part of the IEG review comments (all the ones for which I have discussed resolution by mail).
Do you prefer that:
	* I post that interim version, to allow some folks to clear their position, OR
	* I hold off until I have addressed all/most review comments ?
Whatever is most convenient for you guys.

Thanks

Francois

---

From: Jari Arkko <[email-masked]>
Date: Thu, 5 Mar 2015 17:31:24 +0200

Take instruction from your AD. I have cleared…

---

From: Martin Thomson <[email-masked]>
Date: Thu, 5 Mar 2015 10:56:11 -0800

On 5 March 2015 at 07:21, Francois Le Faucheur (flefauch)
<[email-masked]> wrote:
...
> An uCDN-side implementation of the CDNI Logging interface MUST reject a CDNI
> Logging File that does not comply with the occurences specified above for
> each and every directive. For example, an uCDN-side implementation of the
> CDNI Logging interface receiving a CDNI Logging file with zero occurence of
> the Version directive, or with two occurences of the Integrity-hash, SHOULD
> reject this CDNI Logging File.
> "

That SHOULD needs to be qualified somehow.  Why would an
implementation ignore the SHOULD and not reject the file?

> In case, an uCDN-side implementation of the CDNI Logging interface receives
> a CDNI Logging File with HTTP Request Logging Records that do not contain
> field values for exactly the set of field names actually listed in the
> preceding “Fields” directive, the implementation SHOULD reject those HTTP
> Request Logging Records, and SHOULD accept the other HTTP Request Logging
> Records .
> "

Again, SHOULD is weak without some support.

> NEW:
> “
> The entity transmitting a CDNI Logging File as per the present document MUST
> set the value to "CDNI/1.0”. In the future, other versions of CDNI Logging
> File might be specified; those would use a value different to "CDNI/1.0”
> allowing the entity receiving the CDNI Logging File to identify the
> corresponding version.
> "

This doesn't tell a receiver what to do with "CDNI/1.1".  It needs to do that.

>  The general TLS usage guidance in [I-D.ietf-uta-tls-bcp] SHOULD be

In this case, a SHOULD is OK, I suppose.

> Since the value of the HTTP header is encoded as a “quoted string”
> (QSTRING), is it not OK to have a HTAB within the HTTP header value as long
> as it is properly bracketed by the Quotes?

Header field *names* aren't quoted.

My point was that even though this is a bug in the sender, you are
going to see these in the wild and they are going to screw up the
logging file.

> The document says that "client-side implementation of the CDNI Logging
> interface MAY pull, at its convenience, a CDNI Logging File “ using standard
> HTTP. Since range request is just a standard HTTP mechanism, the clien-side
> may use it if it sees fit.

Nah, that's OK.

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 6 Mar 2015 16:03:09 +0000

> On 5 Mar 2015, at 19:56, Martin Thomson <[email-masked]> wrote:
> 

Sorry that was a typo. It was meant to be a MUST (like in the previous sentence). It has been updated.

> Again, SHOULD is weak without some support.

I can’t really think of a good reason to not do that, so those have been turned into MUST.

> This doesn't tell a receiver what to do with "CDNI/1.1".  It needs to do that.

This discussion made me realise that we need a registry for Versions. Thank you.

I have added a new registry:

NEW:
“
6.2.  CDNI Logging File Version Registry

   The IANA is requested to create a new registry, CDNI Logging File
   Version.

   The initial contents of the CDNI Logging Logging File Version
   registry comprise the value "CDNI/1.0" specified in Section 3.3 of
   the present document, and are as follows:

    +-----------------+-----------+----------------------------------+
    | Version         | Reference |        Description               |
    +-----------------+-----------+----------------------------------+
    | CDNI/1.0      | RFC xxxx  | CDNI Logging File version 1.0    |
    |                      |           | as specified in RFC xxxx         |
    +-----------------+-----------+----------------------------------+

                                 Figure 9

   [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of
   the present document]

   Within the registry, Version values are to be allocated by IANA
   according to the "Specification Required" policy specified in
   [RFC5226].  Version values are to be allocated by IANA with a format
   as specified for the Version directive in Section 3.3.
"

and added this text:

NEW:
"
An entity receiving a CDNI Logging File with a value set to "CDNI/1.0” MUST process the CDNI Logging File as per the present document. An entity receiving a CDNI Logging File with a value set to a different value MUST process the CDNI Logging File as per the specification referenced in the CDNI Logging File Version registry (see section 6.2) if the implementation supports this specification and MUST reject the CDNI Logging File otherwise.
“

I’ll wait to hear from you, and if you’re OK with taht I’ll reach out to the IANA to notify them about the extra registry to be created.

> Header field *names* aren't quoted.

Oh, I see , invalid HTAB inside the HTTP header name itself.

> going to see these in the wild and they are going to screw up the

I have added this:

NEW:
“
The entity transmitting the CDNI Logging File MUST ensure that the <HTTP-header-name> of the cs(<HTTP-header-name) listed in the Fields directive comply with HTTP specifications and, in particular, does not include any HTAB, since this would prevent proper parsing of the Fields directive by the entity receiving the CDNI Logging File.
" 

>> No problem in doing that if you feel it is useful.

Thanks for helping improve our document.

Francois

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 9 Mar 2015 17:13:01 +0000

Hi Martin,

> It appears as though the atom is an octet.

We have the following statement:
" A CDNI Logging File MUST contain a sequence of lines containing US-
   ASCII characters [CHAR_SET] terminated by CRLF.”
I see that as defining the atom as an ASCII character. 

> S3.2 uses the wildcard ABNF rule (i.e., <text....>) too aggressively.

Can you give me the specifics (unless this refers to what you've expanded below already)

> RECLINE (a potentially confusing name) could be more strictly defined.

potentially confusing, but hopefully not really given the consistent structure across DIRLINE/DIRGROUP/RECLINE/RECGROUP.

>    CDNI-LOG-FILE = 1*(DIRGROUP / RECGROUP)

I have changed it to :
"
CDNI Logging File = 1*<DIRGROUP RECGROUP>
"

This is to avoid defining an extra name (CDNI-LOG-FILE) and have to explain that CDNI-LOG-FILE is actually the CDNI Logging File.
Let me know if that is not valid.

> rather than 1* would be better.

A logging file with no Logging Records is considered valid and allowed, but a logging file without any directive is not considered valid.
This is consistent with the text that I added based on our previous discussion stating that “occurrences” for all directives need to be respected (in other words, some directives are mandatory).

>    Version-directive = "Version" ":" HTAB "CDNI" "/" 1*DIGIT "." 1*DIGIT

I’ll park these ABNF comments since I got many others and will handle them together.

> are specific semantics you want to extract from each digit.

Fair enough. I have relaxed it and simply made the format NHTABSTRING.

In the corresponding IANA section for the Version registry, I have added:
“
Within the registry, Version values are to be allocated by IANA
   according to the "Specification Required" policy specified in
   [RFC5226].  Version values are to be allocated by IANA with a format
   of NAMEFORMAT (see Section 3.1).  Version values corresponding to
   specifications produced by the IETF CDNI Working Group are to be
   allocated a name starting with "CDNI".  All other Version values are
   to be allocated a name that does not start with "CDNI”.
“

I have kept CDNI/1.0 as the value allocated by this document.

> Discard the entire file?  That doesn't seem like a good way to ensure

This has been discussed and fixed already.

Good point.

Text has been modified to:
“
this a Uniform Resource Name (URN) from the
         Universally Unique IDentifier (UUID) URN namespace specified in
         [RFC4122]).  The UUID contained in the URN uniquely identifies
         the CDNI Logging File.
"

>         be considered non-corrupted.

Done. Replaced MUST by “is to be”.

> MD5 collisions are easy to manufacture.  I'd also drop the MUST from

Done. Replaced MUST by “is to be”.

> S3.4: more wildcards

Sorry. I didn’t get that.

> getting caught up in the details.

The thing is that there are additional things in HTTP2 that could be logged and the WG has not yet discussed whether there is real value in doing that, and how. So we do not have specific extensions for those. So we need to be clear that we “only” log the same thing for HTTP/2 as for HTTP/1.1, even if we know that one may potentially want to log more. 
And I’d rather we don;t hold publication of this document until teh WG has worked out exactly waht to do for the few additional things specific to HTTP/2.
So I think the current text is quite appropriate.

> 
> 
> Nits/editorial comments:
> 
> There are lots of uses of lowercase "may”.

Right. But we’ve been quite careful at using “MAY" as per RFC2119 and “may" where appropriate.
Do you see specific occurences of “may” that are not appropriate?

> 
> Page 6 has a few instances of missing hyphens in dCDN3/dCDN2 etc…

Fixed.

> S6.2.1: chunck

Fixed

Good point.

NEW:
“
Dates are encoded as "full-date" specified in [RFC3339].
“
and 

NEW:
“
Times are encoded as "partial-time" specified in [RFC3339].
“

> S3.3 using ":" HTAB as a separator makes it hard to construct these

This is a recommendation from ELF and commonly used today. Since we want to be as consistent as possible with ELF, I’d rather we stick to HTAB.

> and all to denote the prefix.

Done. For example it says:
“
"c-" refers to the User Agent that issues the request (corresponds to the "client" of W3C Extended Log Format)
"

> HTTP in general at this moment.

RFC3270 itself says that HTTP1.1 is specified collectively by RFC3270, RFC3271,… RFC3275. So we may as well be consistent with that.

Finally got to the bottom !  

Thanks much for the review.

Francois

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Mar 2015 15:36:12 -0700

Gotta run, but I hope these responses help.

> I see that as defining the atom as an ASCII character.

I'd prefer it be explicit near the ABNF definitions.

> Can you give me the specifics (unless this refers to what you've expanded below already)

Using <> says to a generic processor : ignore everything that follows.
It breaks automatic validation.  It's a cop-out that you don't need.
You know what letters you want to permit, so build a rule for it.

That does mean that you need to consider whether you want to permit
the ASCII BELL (or BEL) character, but I think that you already have
an answer ready-to-hand.

> CDNI Logging File = 1*<DIRGROUP RECGROUP>

Again, <> is not appropriate here, it puts what you have inside it
down as comments, not actionable BNF.  Also, that name is not valid
ABNF.

> This is consistent with the text that I added based on our previous discussion stating that “occurrences” for all directives need to be respected (in other words, some directives are mandatory).

I think that you could express that better than you have.

LoggingFile = 1*(1*DIRGROUP *RECGROUP)

Might work.

>    to be allocated a name that does not start with "CDNI”.

Creating carve-outs in registries like that is inadvisable.  Someone
might attach semantics to them and then you get into trouble.  See the
RFC on x-.

> Sorry. I didn’t get that.

<> rules, not () rules.  <> is a wildcard.

> So I think the current text is quite appropriate.

If you aren't fixing it now, fix it later and don't worry about saying
that you will.  Because you might not.

> Do you see specific occurences of “may” that are not appropriate?

Some people get antsy about lowercase uses because it is confusing.  I
don't.  If you've checked I'm happy.  Expect others to notice, that's
all.

> RFC3270 itself says that HTTP1.1 is specified collectively by RFC3270, RFC3271,… RFC3275. So we may as well be consistent with that.

We get this question all the time.  You don't need to expand, because
RFC 7230 does that for you...

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Mar 2015 16:24:03 -0700

Might work.

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 10 Mar 2015 09:41:59 +0000

> On 9 Mar 2015, at 23:36, Martin Thomson <[email-masked]> wrote:
> 

I have updated to:

"
CDNI-LOG-FILE = 1*(DIRGROUP RECGROUP)
“

This defines the base syntax, and what defines whether/how-many/where actuel directives can be present is the “occurences” specification below (semantic dependent).

> might attach semantics to them and then you get into trouble.  See the

I checked RFC 6648 and see your point.
So I have removed the text in IANA sections recommendation a naming structure.

> that you will.  Because you might not.

But we are not saying that we will. We are saying that it is not addressed in this doc. It may be useful, and it may be addressed in the future. Unless I am missing something, I believe this is correct and useful.

> RFC 7230 does that for you…

This is not a important point at all and I apologize to waste time on it. But as RFC7230 is worded, it makes it clear that it defines only one part of HTTP/1.1 and that HTTP/1.1 is defined by teh set of RFCs. 
In other words RFC7230 refers to the other RFC but it does not include them. To me HTTP/1.1 is really defined by the set of RFCs and not simply RFC7230. So I’m more comfortable referncing the set.
If you guys feel strongly to remove it, I’ll just obey.

Thanks again

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Mar 2015 08:39:41 -0700

That looks fine.

On 10 March 2015 at 02:41, Francois Le Faucheur (flefauch)
<[email-masked]> wrote:
...