Subject: [CDNi] CDNI Logging - Origin directive

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 28 May 2013 08:53:05 +0100

Colleagues,

draft-ietf-cdni-logging-02 states:

   o  Origin:

      *  format: <host>

      *  semantic: this identifies the entity transmitting the CDNI
         Logging File (e.g.  the host in a dCDN supporting the CDNI
         Logging interface) or the entity responsible for transmitting
         the CDNI Logging File (e.g.  the dCDN).

      *  occurrence: there MUST be zero or one instance of this
         directive.  This directive MAY be included by the
         implementation transmitting the CDNI Logging file.  When
         included by the transmitting side, it MUST be validated or
         over-written by the receiving side.  When, it is not included
         by the transmitting side, it MAY be added locally by the
         receiving side.  [Editor's Note if we include a non-repudiation
         mechanism: discuss the fact that this will provide incentive to
         dCDN to not cheat , as it can be detected]

Why MUST the Origin directive be validated or over-written by the receiving side and how is the receiving side meant to perform validation on the contents of this directive?

Thanks
Ben

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 28 May 2013 08:37:28 +0000

Hi Ben, (and all)

Thanks for reviewing the doc. Also using a separate thread per issue will help us. 
To your first comment:

> Why MUST the Origin directive be validated or over-written by the receiving side and how is the receiving side meant to perform validation on the contents of this directive?

Perhaps a "MAY" would be more appropriate. Right?

In any case, here is how I picture the "Origin" field:
	* that field is intended to be a reliable record of the log file origin
	* the uCDN is ultimately responsible (to itself) for the accuracy of that field. To do that it can select the approach it sees best fit among several candidate approaches including:
		- uCDN establishes identity of the entity that transmitted the Log file via security mechanisms that are part of the CDNI log file exchange protocol (HTTPS) and then uCDN writes/overwrites this field
		- uCDN relies on dCDN to populate that field and then relies on non-repudiation mechanism to act as incentive for dCDN to not lie (or relies on special trust relationship with dCDN -eg it is part of the same administrative entity- to not lie)  .
Does that make sense? If yes, maybe we can tweak text to explain this better.

> Thanks
> Ben
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni