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

From: Bert Greevenbosch <[email-masked]>
Date: Sat, 29 Nov 2014 03:07:40 +0000

Hi all,

In Honolulu, I volunteered to review draft-ietf-cdni-redirection-05. I have done this, and think the draft is in good shape, and technically quite sound. Below follow more detailed comments.

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?

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

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

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

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

(BG6) Table in section 4.5.1: "cs-uri", "The URI requested by the UA". This URI is called URL elsewhere. Unify the wording.

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

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

(BG9) Related to (BG8): in the last line on page 16, should "cs(<headername>)" be "sc(<headername>)"?

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

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

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

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

________________________________
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!