Subject: Re: [CDNi] Review of draft-ietf-cdni-redirection-05

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 9 Dec 2014 12:56:01 +0000

Hi Bert,

Thanks for the review. Please see inline for my responses.

On 29 Nov 2014, at 03:07, Bert Greevenbosch <[email-masked]> wrote:

> ---
> (BG1) In section 4.2: "The cdn-path MAY be reflected back in RI responses, although doing so would expose information to the uCDN that a dCDN may not wish to expose (for example, the existence of business relationships between a dCDN and other CDNs)." The information in the cdn-path can be forwarded from a dCDN to another dCDN though. Why is it not a problem that the second dCDN acquires such information from the first?

Because having that information is required for loop prevention. cdn-path in an RI request exposes the CDNs that are before the current CDN in the RI flow. cdn-path in an RI response exposes the CDNs that come after the current CDN in the RI flow. We need to expose the former to prevent loops but we don't need to expose the latter.
  
> 
> (BG2) In section 4.4.1, the bullet list specifies five information points that need to be passed from the uCDN to the dCDN. The IP address or prefix of the UA is also listed, but in the following table, the related field "c-subnet" is not mandatory. Why is it not mandatory?

c-subnet is only available if the DNS resolvers between the User and the uCDN support a DNS extension (draft-vaandergaast) that is not widely deployed at the moment so it is not possible to make c-subnet mandatory.
 
> (BG3) Related to (BG2): It seems better to combine the text "This dns dictionary MUST contain the following keys: resolver-ip, qtype, qclass, qname and the value of each MUST be the value of the appropriate part of the User Agent's DNS query/request" with the bullet list at the start of section 4.4.1, as the information seems to be double. This comment also applies to section 4.5.1.

The idea is to introduce the concepts, then the dictionary structure and then define which of those dictionary keys are mandatory and their related behaviour.
 
> (BG4) In section 4.4.2: "The dns dictionary MAY include both 'a' and 'aaaa' keys. If the dns dictionary contains a cname key it MUST NOT contain either an a or aaaa key." Why? It makes sense to not do a DNS lookup for a cname if the related IP address is already available in the response, but why mandate the absence of cname in that case?

The cname returned is what the dCDN wants the User Agent to receive so it can perform DNS resolution based on the User Agent itself, e.g. to select a particular surrogate in response to a DNS request directly from the User Agent. Pre-resolving provides no value in that use case and provides an unclear semantic to the uCDN which does not know whether to return the A/AAAA records or the CNAME to the User Agent.
 
> (BG5) Do the 'a' and 'aaaa' fields point at the same RTs?  (I notice in the examples that the number of elements in the 'a' and 'aaaa' fields are equal, which may mean that for each element in a there is a related element in 'aaaa'.) I guess this is not the case, but want to make sure.

The A and AAAA fields do not have to be equal sized lists or point at the same RTs.
 
> (BG6) Table in section 4.5.1: "cs-uri", "The URI requested by the UA". This URI is called URL elsewhere. Unify the wording.

I unified on URI.
 
> (BG7) Section 4.5.1: "In the case where the User Agent request includes multiple HTTP header fields with the same field-name, it is up to the uCDN to determine how to handle this. One option would be to only send the contents of the first occurrence of that HTTP Header in the User Agent Request. Another would be to combine the different HTTP Headers into a single value according to Section 3.2.2 of [RFC7230]." The text in RFC 7230 says that such combined header field is semantically equivalent to the separated headers fields. However, here we allow different handling for such equivalent encodings. Maybe we should mandate that the Headers need to be combined into a single value, or at least use a SHOULD?

Unfortunately use of HTTP header fields in the wild is inconsistent for some headers fields, so it is really dependent on which header fields the uCDN is passing on as to what the best behaviour might be so we can't be too specific and have to rely on the uCDN knowing what they are passing on.
 
> (BG8) In sections 4.5.1 and 4.5.2, there is mentioning of the keys "sc(<headername>)" and "cs(<headername>)". Are these the same? If so, use a single key. If not, explain their difference. (Maybe this has something to do with the direction server->client, client->server.)

Correct it is a convention to show the direction the header field was passed.

I've added the following text to explain them
   The dictionary keys used in HTTP Redirection requests and responses
   use the following conventions for their prefixes:

   o  c- is prefixed to keys for information related to the Client (User
      Agent).

   o  cs- is prefixed to keys for information passed by the Client (User
      Agent) to the Server (uCDN).

   o  sc- is prefixed to keys for information to be passed by the Server
      (uCDN) to the Client (User Agent).
 
> (BG9) Related to (BG8): in the last line on page 16, should "cs(<headername>)" be "sc(<headername>)"?

Good catch!
 
> (BG10) I propose to modify first sentence in section 4.6, "RI responses may be cacheable and may be reused by the uCDN in response to User Agent requests without the uCDN issuing another RI request to the dCDN if the RI response is considered cachable & not stale according to the standard HTTP Cache-Control, etc mechanisms." as follows: "RI responses may be cacheable. As long as a cached RI response is not stale according to standard HTTP Cache-Control or other applicable mechanisms, it may be reused by the uCDN in response to User Agent requests without sending another RI request to the dCDN."

Done.
 
> (BG11) Section 4.6 contains the following text: "(except for the c-ip field provided the User Agent's c-ip is covered by the scope in the original RI response)". The scope dictionary ("iprange") is only defined later, making the sentence confusing. Maybe reword as follows: "(except for the c-ip field provided that the User Agent's c-ip is covered by the scope in the original RI response, as elaborated upon below)".

Done.
 
> (BG12) The second example on page 9 in has two "max-age" fields: one in the header ("max-age=60") and one in the body ("max-age=30"). The former must be meant for the uCDN, whereas the latter is meant for the UA. Maybe it would be good to add the following text after "Example of HTTP redirection response from Section 4.5.2 that is cacheable by the uCDN for 60 seconds and can be returned to any User Agent with an IPv4 address in 198.51.100.0/24.": "Notice that the response to the UA is only valid for 30 seconds, whereas the uCDN can cache the RI response for 60 seconds."

Done.
 
> (BG13) In the second table in section 4.7, on page 22, there is the text "<reason>" for codes 100, 400, and 500. From the IANA considerations section, it later becomes clear that this "<reason>" is actually the value of the "reason" string in the error information. However, that is not clear from the table. I think it would be good to clarify this already in section 4.7.

Done. I added the following text above the table:

   Error codes with a "Reason" of "<reason>" do not have a defined value
   for their 'reason'-key.  Depending on the error-code semantics, the
   value of this field may be determined dynamically.
 
> (BG14) In section 4.8, there is the following text (A) about the max-hops value: "Transit CDNs MUST NOT propagate to any downstream CDNs if the number of CDN Provider IDs in cdn-path is equal to or greater than max-hops." In addition, there is the text (B): "If a downstream CDN receives a RI request where the number of CDN Provider IDs in cdn-path is greater than max-hops, the downstream CDN SHOULD send a RI response with an error code of 503.". Text (B) seems to indicate that the values of max-hops / cdn-path are checked upon receipt of the message, not before sending it. Thus, if max-hops = 1, the first dCDN can propagate the RI request, but the second cannot. That means that in text (A), the cdn-path is evaluated _before_ the dCDN adds its own Provider ID. I propose to write this explicitly, and thus rephrase (A) as follows: "Transit CDNs MUST NOT propagate to any downstream CDNs if the number of CDN Provider IDs in cdn-path (before adding its own Provider ID) is equal to or greater than max-hops."

Done.

Thanks
Ben

>  
>  
> Bert Greevenbosch
> Huawei Technologies Co., Ltd.
>  
> [email-masked]
>  
> Huawei Industrial Base F1-8
> Bantian, Longgang District
> Shenzhen 518129
> P.R. China
>  
> http://www.huawei.com
> 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
> 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
> 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from HUAWEI, which 
> is intended only for the person or entity whose address is listed above. Any use of the 
> information contained herein in any way (including, but not limited to, total or partial 
> disclosure, reproduction, or dissemination) by persons other than the intended 
> recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by 
> phone or email immediately and delete it!
>  
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: Bert Greevenbosch <[email-masked]>
Date: Wed, 10 Dec 2014 01:07:11 +0000

Hi Ben,

Thank you for your answer to my comments.

Please find my response below.

Best regards,
Bert

> > (BG1) In section 4.2: "The cdn-path MAY be reflected back in RI responses,
> although doing so would expose information to the uCDN that a dCDN may not
> wish to expose (for example, the existence of business relationships between a
> dCDN and other CDNs)." The information in the cdn-path can be forwarded from a
> dCDN to another dCDN though. Why is it not a problem that the second dCDN
> acquires such information from the first?
> 
> Because having that information is required for loop prevention. cdn-path in
> an RI request exposes the CDNs that are before the current CDN in the RI flow.
> cdn-path in an RI response exposes the CDNs that come after the current CDN in
> the RI flow. We need to expose the former to prevent loops but we don't need
> to expose the latter.

OK - I see the need for forwarding visited nodes in the cdn-path, and that this is a kind of best effort approach.

Still, I wonder in how far the confidential information from the uCDN is really protected by the mechanism. Nevertheless, sending information that is not needed is just a waste of bandwidth, so indeed it is better to omit it.

> > (BG2) In section 4.4.1, the bullet list specifies five information points
> that need to be passed from the uCDN to the dCDN. The IP address or prefix of
> the UA is also listed, but in the following table, the related field "c-
> subnet" is not mandatory. Why is it not mandatory?
> 
> c-subnet is only available if the DNS resolvers between the User and the uCDN
> support a DNS extension (draft-vaandergaast) that is not widely deployed at
> the moment so it is not possible to make c-subnet mandatory.

OK

> > (BG3) Related to (BG2): It seems better to combine the text "This dns
> dictionary MUST contain the following keys: resolver-ip, qtype, qclass, qname
> and the value of each MUST be the value of the appropriate part of the User
> Agent's DNS query/request" with the bullet list at the start of section 4.4.1,
> as the information seems to be double. This comment also applies to section
> 4.5.1.
> 
> The idea is to introduce the concepts, then the dictionary structure and then
> define which of those dictionary keys are mandatory and their related
> behaviour.

I realise that this is an editorial. Nevertheless if you write the information twice, you need to double check for inconsistencies too, and the reader has to read more than they need. I'll leave it up to the authors whether to keep this structure.

> > (BG4) In section 4.4.2: "The dns dictionary MAY include both 'a' and 'aaaa'
> keys. If the dns dictionary contains a cname key it MUST NOT contain either an
> a or aaaa key." Why? It makes sense to not do a DNS lookup for a cname if the
> related IP address is already available in the response, but why mandate the
> absence of cname in that case?
> 
> The cname returned is what the dCDN wants the User Agent to receive so it can
> perform DNS resolution based on the User Agent itself, e.g. to select a
> particular surrogate in response to a DNS request directly from the User Agent.
> Pre-resolving provides no value in that use case and provides an unclear
> semantic to the uCDN which does not know whether to return the A/AAAA records
> or the CNAME to the User Agent.

OK

> > (BG5) Do the 'a' and 'aaaa' fields point at the same RTs?  (I notice in the
> examples that the number of elements in the 'a' and 'aaaa' fields are equal,
> which may mean that for each element in a there is a related element in
> 'aaaa'.) I guess this is not the case, but want to make sure.
> 

Maybe remove one of the IPv4 addresses from the example?
 
> > (BG6) Table in section 4.5.1: "cs-uri", "The URI requested by the UA". This
> URI is called URL elsewhere. Unify the wording.
> 
> I unified on URI.

OK

> > (BG7) Section 4.5.1: "In the case where the User Agent request includes
> multiple HTTP header fields with the same field-name, it is up to the uCDN to
> determine how to handle this. One option would be to only send the contents of
> the first occurrence of that HTTP Header in the User Agent Request. Another
> would be to combine the different HTTP Headers into a single value according
> to Section 3.2.2 of [RFC7230]." The text in RFC 7230 says that such combined
> header field is semantically equivalent to the separated headers fields.
> However, here we allow different handling for such equivalent encodings. Maybe
> we should mandate that the Headers need to be combined into a single value, or
> at least use a SHOULD?
> 
> Unfortunately use of HTTP header fields in the wild is inconsistent for some
> headers fields, so it is really dependent on which header fields the uCDN is
> passing on as to what the best behaviour might be so we can't be too specific
> and have to rely on the uCDN knowing what they are passing on.

Yes, but still there is an inconsistency with RFC 7230. I would opt for a SHOULD or RECOMMENDED, e.g. change the text to:

"In the case where the User Agent request includes multiple HTTP header fields with the same field-name, it is RECOMMENDED that the uCDN combines these different HTTP headers into a single value according to Section 3.2.2 of [RFC7230]. However, because of the plurality of already defined HTTP header fields, and inconsistency of some of these header fields concerning the combination mechanism defined in RFC 7230, the uCDN MAY have to deviate from using the combination mechanism where appropriate. For example, it MAY only send the contents of the first occurrence of the HTTP Headers instead."

> > (BG8) In sections 4.5.1 and 4.5.2, there is mentioning of the keys
> "sc(<headername>)" and "cs(<headername>)". Are these the same? If so, use a
> single key. If not, explain their difference. (Maybe this has something to do
> with the direction server->client, client->server.)
> 

That clarifies a lot. Thanks!

> > (BG9) Related to (BG8): in the last line on page 16, should
> "cs(<headername>)" be "sc(<headername>)"?
> 
> Good catch!
> 
> > (BG10) I propose to modify first sentence in section 4.6, "RI responses may
> be cacheable and may be reused by the uCDN in response to User Agent requests
> without the uCDN issuing another RI request to the dCDN if the RI response is
> considered cachable & not stale according to the standard HTTP Cache-Control,
> etc mechanisms." as follows: "RI responses may be cacheable. As long as a
> cached RI response is not stale according to standard HTTP Cache-Control or
> other applicable mechanisms, it may be reused by the uCDN in response to User
> Agent requests without sending another RI request to the dCDN."
> 
> Done.
> 
> > (BG11) Section 4.6 contains the following text: "(except for the c-ip field
> provided the User Agent's c-ip is covered by the scope in the original RI
> response)". The scope dictionary ("iprange") is only defined later, making the
> sentence confusing. Maybe reword as follows: "(except for the c-ip field
> provided that the User Agent's c-ip is covered by the scope in the original RI
> response, as elaborated upon below)".
> 
> Done.
> 
> > (BG12) The second example on page 9 in has two "max-age" fields: one in the
> header ("max-age=60") and one in the body ("max-age=30"). The former must be
> meant for the uCDN, whereas the latter is meant for the UA. Maybe it would be
> good to add the following text after "Example of HTTP redirection response
> from Section 4.5.2 that is cacheable by the uCDN for 60 seconds and can be
> returned to any User Agent with an IPv4 address in 198.51.100.0/24.": "Notice
> that the response to the UA is only valid for 30 seconds, whereas the uCDN can
> cache the RI response for 60 seconds."
> 
> Done.
> 
> > (BG13) In the second table in section 4.7, on page 22, there is the text
> "<reason>" for codes 100, 400, and 500. From the IANA considerations section,
> it later becomes clear that this "<reason>" is actually the value of the
> "reason" string in the error information. However, that is not clear from the
> table. I think it would be good to clarify this already in section 4.7.
> 
> > (BG14) In section 4.8, there is the following text (A) about the max-hops
> value: "Transit CDNs MUST NOT propagate to any downstream CDNs if the number
> of CDN Provider IDs in cdn-path is equal to or greater than max-hops." In
> addition, there is the text (B): "If a downstream CDN receives a RI request
> where the number of CDN Provider IDs in cdn-path is greater than max-hops, the
> downstream CDN SHOULD send a RI response with an error code of 503.". Text (B)
> seems to indicate that the values of max-hops / cdn-path are checked upon
> receipt of the message, not before sending it. Thus, if max-hops = 1, the
> first dCDN can propagate the RI request, but the second cannot. That means
> that in text (A), the cdn-path is evaluated _before_ the dCDN adds its own
> Provider ID. I propose to write this explicitly, and thus rephrase (A) as
> follows: "Transit CDNs MUST NOT propagate to any downstream CDNs if the number
> of CDN Provider IDs in cdn-path (before adding its own Provider ID) is equal
> to or greater than max-hops."
> 
> Done.
> 
> Thanks
> Ben
> 
> >
> >
> > Bert Greevenbosch

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 10 Dec 2014 10:54:56 +0000

Bert,

> Maybe remove one of the IPv4 addresses from the example?

I added an extra IPv4 address instead but the effect is the same (the example has different length lists for a and aaaa).

> "In the case where the User Agent request includes multiple HTTP header fields with the same field-name, it is RECOMMENDED that the uCDN combines these different HTTP headers into a single value ac…

Thanks. I changed the text to what you provided above.

Ben