Skip to main content

Last Call Review of draft-ietf-cdni-redirection-17
review-ietf-cdni-redirection-17-secdir-lc-takahashi-2016-03-14-00

Request Review of draft-ietf-cdni-redirection
Requested revision No specific revision (document currently at 20)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-03-15
Requested 2016-03-03
Authors Ben Niven-Jenkins , Ray van Brandenburg
I-D last updated 2016-03-14
Completed reviews Secdir Last Call review of -17 by Takeshi Takahashi (diff)
Assignment Reviewer Takeshi Takahashi
State Completed
Review review-ietf-cdni-redirection-17-secdir-lc-takahashi-2016-03-14
Reviewed revision 17 (document currently at 20)
Result Ready
Completed 2016-03-14
review-ietf-cdni-redirection-17-secdir-lc-takahashi-2016-03-14-00
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area
directors.
Document editors and WG chairs should treat these comments just like any
other last call comments.

[overall feeling on this draft]

ready.

[summary of this document]

This document talks about a necessary interface for CDN.
It defines the CDNI Request Routing Recirection interface, which is the
interface for the synchronous operation of an upstream CDN requesting
whether a downstream CDN is prepared to accept a user request and of a
downstream CDN responding with how to actually redirect the user request.
Specifically speaking, this document defines general message sequences of
the redirection as well as the protocol message syntax. It also elaborates
on how to handle the caches of the messages and how to handle errors.

[questions]

Here are some clarification questions.
I would appreciate if you could provide some answers to them.

1. Example jsons in P.25:

Do we need "description" in the json?
Since we already have "error-code" in the json, I am not sure whether we
need to embed the "description" in the json.
The description is written in the IANA table and is unique to each
error-code.
For this reason, I feel that we can omit the "description" from the json,
can't we?

2. error code of 503 in page 26 (3rd paragraph of the page).

I have got one question by reading two sentences: "If a dCDN receives an RI
request where the number of CDN Provider IDs in cdn-path is greater than
max-hops, the dCDN SHOULD send an RI response with an error code of
503."(3rd paragraph of page 26) and "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"(last sentence of page 25)

If "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" is true,
no dCDN receives an RI request where the number of CDN Provider IDs in
cdn-path is greater than max-hops, is it correct?

Even if the answer is yes, I think it is wise to have the error code 503
(because some CDNs may be malfunctioning), but what types of actions should
the receivers of the error message take?


[typo]
In Table 1 in P.24:
"erred" -> "errored"?

Cheers,
Take