Re: New Version Notification for draft-cdn-loop-prevention-00.txt

On 03/07/18 04:29, Patrick McManus wrote:
> Hi, thanks for the draft! Some comments as an individual ...
> 
> * I agree with the comment that, as proposed, this isn't really a CDN
> specific solution. Its a more opaque version of via.. so it makes sense
> to me to construct it independent of CDNs and instead focus it on any
> element that wants to participate in loop prevention. CDNs serve as the
> primary illustrator.
> 
> * I would be interested in more text on why Via failed and therefore
> this should succeed.. you mention that via is used in practice as a
> control signal incompatibly enumerating intermediaries.. I agree, but I
> also think via in practice reveals information people don't want
> revealed.. is CDN-loop perhaps more robust to this because the token is
> opaque (and perhaps not consistent between exchanges)?


That is wrong and I think a derivative of people not reading the specs
properly.

RFC 7230 section 5.7.1:
"
   The received-by portion of the field value is normally the host and
   optional port number of a recipient server or client that
   subsequently forwarded the message.  However, if the real host is
   considered to be sensitive information, a sender MAY replace it with
   a pseudonym.
"


Or do you mean that the information "1.1" versus "1.0" is so important
for privacy that it cannot be shared around?


> 
> * the draft focuses on creation of the cdn-loop request header but has
> nothing to say on who/how/when that is policed.
> 

Aye, and this seems to also be part of the root problem with Via usage.
Lack of guidance on use for the particular cases, just statement that it
can be.


> * "the token defines the CDN as a whole." feels like it needs more
> guidance.. is it even the right advice? Is it more about the scope of
> the token? are there use cases where cascading cdns make sense that
> might involve CDN repeats without forming a loop?
> 

Seems like meaning of the token to me and also another thing which Via
already has.


> * it would really help the wg to understand the scope of the problem a
> little more.. "not unknown for CDNs to be configured in a loop" makes me
> wonder if the authors believe this is a serious problem (though I
> suspect they just didn't want to over-assert).. but given that the
> document basically wants to restandardize something that has been
> standardized (Via), a little discussion of the operational imperative
> makes sense. (this is not necessarily something that would have to be in
> the doc)
> 


The more I hear about the use-case the more I think reusing Via is still
the better choice, but perhapse an informational document explaining how
CDNs should best use Via for loop detection while protecting privacy.


Amos

Received on Tuesday, 3 July 2018 06:31:13 UTC