Re: [CDNi] [E] Logging: draft-finkelman-cdni-sva-extensions-00.txt

[[e-mail]]

On 28 Nov 2017, at 09:27, [e-mail] wrote:

>The working group standardised on the format specified in RFC7937. Introduction of a second format just to satisfy a subset of CDNs that use a different format doesn’t solve the problem it just moves it around and places the burden of transformation on another party, it doesn’t solve it.
I don’t disagree however given there was lack (no implementation) of the logging based on RFC7937 led us to consider an alternative that minimized work for the participating CDNs and leveraged what they already had invested in. We can remove the logging section from the I-D, but I am not sure if that improves odds for new development within CDNs conforming to RFC 7937.

Best
Sanjay



From: Ben Niven-Jenkins [mailto:[e-mail]]
Sent: Tuesday, November 28, 2017 9:27 AM
To: Mishra, Sanjay <[e-mail]>; Ori Finkelman <[e-mail]>; [e-mail]
Subject: [E] Logging: draft-finkelman-cdni-sva-extensions-00.txt

Sanjay, Ori, Colleagues,

On 17 Nov 2017, at 02:57, [e-mail]<mailto:[e-mail]> wrote:

Kevin Ma wrote:
>For Logging, it would be unfortunate if the logging interface we specified had to be >completely bypassed.  If there is a need, then we should address it, but I would be interested in >hearing from vendors on this.
Primary motivators for specifying logging requirements in draft-finkelman-cdni-sva-extensions is largely because of CDNs already have and use Squid based logging and would rather not add a separate process to receive and process logging information sent by the dCDN (ISP’s open caching nodes).

I do not find this argument particularly persuasive. Our purpose at IETF is to specify interoperability and introducing a new format works against that goal IMO. Not all CDNs produce squid-format logs, so squid-format is not a magic bullet, people are always going to have to support some kind of transformation if they want CDNs that use different logging formats to interoperate.

The working group standardised on the format specified in RFC7937. Introduction of a second format just to satisfy a subset of CDNs that use a different format doesn’t solve the problem it just moves it around and places the burden of transformation on another party, it doesn’t solve it.

The example cited in the draft of logging the hit/miss status of the request is already supported by RFC7937 through the s-cached field. It only logs hit vs miss although could be extended to support additional granularity rather than introducing a new log format along which would bring with it the interoperability concerns having another format raises.

Regards
Ben