Subject: [CDNi] Alissa Cooper's No Objection on draft-ietf-cdni-logging-24: (with COMMENT)

From: "Alissa Cooper" <[email-masked]>
Date: Mon, 04 Apr 2016 12:28:59 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-cdni-logging-24: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for resolving my DISCUSS points.

I will note that I don't think the issue with partial-time has been
completely resolved, because the document still says it uses partial-time
as defined in RFC 3339, and partial-time by definition does not have a
time zone associated with it, whereas the document text now says all
times are reported in UTC. Bit of a detail, but it might make sense to
use full-time since you are specifying the time zone offset. There are
probably other folks who know better than I do what standard practice is
here.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 4 Apr 2016 19:10:27 -0300

Hi, Francois,

> https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/

Do you need to take a look at this?

And if you do, just let me know. I can ask Amy to move this to Approved, AD
Follow-up, and the ballot positions won't disappear on Wednesday.

Thanks,

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

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 5 Apr 2016 11:46:05 +0000

Alissa and all,

> probably other folks who know better than I do what standard practice is

I don’t quite see the problem here.

The cdni-logging :
* refers to the definition of partial time, which does not have a time zone, which i understand mean that the timezone is undefined in that format and is to be defined by the context (e.g. by a full-time format, or by whatever uses partial-time)
* states, in the definition of the one field that uses the partial-time format that it is expressed in UTC. ("the time, expressed in Coordinated Universal Time (UTC), at which the processing of request completed on the Surrogate".)

In other words, I don’t see a contradiction with the definition of RFC3339 and I don’t see any ambiguity.
Am i missing something?

Thanks

Francois

PS: For the record, I will also remind folks that the document used to define its own time format (in exactly the same way as partial-time but without referring to RFC3339) and as part of the IESG review, an AD recommended we replace our own definition and instead pointed to RFC3339. And note that (i) there is an explicit preference from the working group to not include timezone information in the format and (ii) the common practice in CDNs is to not have timezone included (e.g. see existing W3C log format).

And if you do, just let me know. I can ask Amy to move this to Approved, AD Follow-up, and the ballot positions won't disappear on Wednesday.

Thanks,

Spencer
> CDNi mailing list
> [email-masked]<mailto:[email-masked]>

---

From: Kevin Ma J <[email-masked]>
Date: Wed, 6 Apr 2016 21:56:45 +0000

Hi Alissa/all,

  I agree with Francois; I don't see a problem.

  - We tried to match the W3C spec [https://www.w3.org/TR/WD-logfile] as much as possible, and for time, they do not include a timezone, but state: "All times are specified in GMT"

  - RFCs 2616/7231 support asctime, which does not include a timezone, and RFC7231 simply states: "values in the asctime format are assumed to be in UTC.  A sender that generates HTTP-date values from a local clock ought to use NTP ([RFC5905<https://tools.ietf.org/html/rfc5905>]) or some similar protocol to synchronize its clock to UTC." [https://tools.ietf.org/html/rfc7231#section-7.1.1.1].

  - RFC 3339 itself, wrt unqualified local time, says, "MUST use a mechanism that ensures correct synchronization with UTC.  Some suitable mechanisms are: o  Use Network Time Protocol [NTP<https://tools.ietf.org/html/rfc3339#ref-NTP>] to obtain the time in UTC." [https://tools.ietf.org/html/rfc3339#section-4.4], which seems to be along the same lines as RFCs 2616/7231 in assuming that unqualified local time is UTC?

  We could change the text from:

    "the time, expressed in Coordinated Universal Time (UTC),"

  to:

    "the time, which MUST be expressed in Coordinated Universal Time (UTC),"

  if that would make it clearer?

thanx.

--  Kevin J. Ma

From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
Sent: Tuesday, April 05, 2016 7:46 AM
To: Spencer Dawkins at IETF; Alissa Cooper
Cc: Francois Le Faucheur (flefauch); <[email-masked]>; [email-masked]; The IESG; [email-masked]
Subject: Re: [CDNi] Alissa Cooper's No Objection on draft-ietf-cdni-logging-24: (with COMMENT)

Alissa and all,

The cdni-logging :

Thanks

Francois

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 6 Apr 2016 19:10:44 -0300

Hi Kevin,

> On 6 Apr 2016, at 18:56, Kevin Ma J <[email-masked]> wrote:
> 
> Hi Alissa/all,
>  
>   - RFCs 2616/7231 support asctime, which does not include a timezone, and RFC7231 simply states: "values in the asctime format are assumed to be in UTC.  A sender that generates HTTP-date values from a local clock ought to use NTP ([RFC5905]) or some similar protocol to synchronize its clock to UTC." [https://tools.ietf.org/html/rfc7231#section-7.1.1.1]. 
>  
>   - RFC 3339 itself, wrt unqualified local time, says, "MUST use a mechanism that ensures correct synchronization with UTC.  Some suitable mechanisms are: o  Use Network Time Protocol [NTP] to obtain the time in UTC." [https://tools.ietf.org/html/rfc3339#section-4.4], which seems to be along the same lines as RFCs 2616/7231 in assuming that unqualified local time is UTC?
>  

I think that would help.

Alexey,
Incoming AD for CDNI.

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 6 Apr 2016 23:22:46 +0000

Hi
I will post a new rev with the proposed change tomorrow unless i hear disagreement about that by then.
Thanks
Francois

Sent from my iPhone

On 06 Apr 2016, at 19:07, Alexey Melnikov <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kevin,

On 6 Apr 2016, at 18:56, Kevin Ma J <[email-masked]<mailto:[email-masked]>> wrote:

Hi Alissa/all,

  to:

I think that would help.

Alexey,
Incoming AD for CDNI.

thanx.

--  Kevin J. Ma

Cc: Francois Le Faucheur (flefauch); <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; The IESG; [email-masked]<mailto:[email-masked]>

Alissa and all,
> probably other folks who know better than I do what standard practice is
I don't quite see the problem here.

The cdni-logging :

In other words, I don't see a contradiction with the definition of RFC3339 and I don't see any ambiguity.
Am i missing something?

Thanks

Francois

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 6 Apr 2016 23:16:13 -0300

Francois,

> disagreement about that by then.

MUST UTC seems helpful to me as well. Thank you for working through this
(non-blocking) comment.

Spencer, as responsible AD for this document

> Thanks
> Francois
>
> Sent from my iPhone
>
> On 06 Apr 2016, at 19:07, Alexey Melnikov <[email-masked]> wrote:
>
> Hi Kevin,
>
>   - We tried to match the W3C spec [https://www.w3.org/TR/WD-logfile] as
> much as possible, and for time, they do not include a timezone, but state: "All
> times are specified in GMT"
>
>
>
>   - RFCs 2616/7231 support asctime, which does not include a timezone, and RFC7231 simply states: "values in the asctime format are assumed to be in UTC.  A sender that generates HTTP-date values from a local clock ought to use NTP ([RFC5905 <https://tools.ietf.org/html/rfc5905>]) or some similar protocol to synchronize its clock to UTC." [https://tools.ietf.org/html/rfc7231#section-7.1.1.1].
>
>
>
>   - RFC 3339 itself, wrt unqualified local time, says, "MUST use a mechanism that ensures correct synchronization with UTC.  Some suitable mechanisms are: o  Use Network Time Protocol [NTP <https://tools.ietf.org/html/rfc3339#ref-NTP>] to obtain the time in UTC." [https://tools.ietf.org/html/rfc3339#section-4.4], which seems to be along the same lines as RFCs 2616/7231 in assuming that unqualified local time is UTC?
>
>
>
> *From:* Francois Le Faucheur (flefauch) [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Tuesday, April 05, 2016 7:46 AM
> *To:* Spencer Dawkins at IETF; Alissa Cooper
> *Cc:* Francois Le Faucheur (flefauch); <[email-masked]>;
> [email-masked]; The IESG; [email-masked]
> *Subject:* Re: [CDNi] Alissa Cooper's No Objection on
> draft-ietf-cdni-logging-24: (with COMMENT)
>
>
>
> Alissa and all,
>
> >
> * refers to the definition of partial time, which does not have a time
> zone, which i understand mean that the timezone is undefined in that format
> and is to be defined by the context (e.g. by a full-time format, or by
> whatever uses partial-time)
>
> * states, in the definition of the one field that uses the partial-time
> format that it is expressed in UTC. ("the time, expressed in Coordinated
> Universal Time (UTC), at which the processing of request completed on the
> Surrogate".)
>
>
>
> PS: For the record, I will also remind folks that the document used to
> define its own time format (in exactly the same way as partial-time but
> without referring to RFC3339) and as part of the IESG review, an AD
> recommended we replace our own definition and instead pointed to RFC3339.
> And note that (i) there is an explicit preference from the working group to
> not include timezone information in the format and (ii) the common practice
> in CDNs is to not have timezone included (e.g. see existing W3C log format).
>
>
>
>
>
>
>
> And if you do, just let me know. I can ask Amy to move this to Approved,
> AD Follow-up, and the ballot positions won't disappear on Wednesday.
>
> Thanks,
>
> Spencer

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 7 Apr 2016 12:26:48 +0000

All,

-25 was just posted with the change agreed below.

Cheers

Francois

On 6 Apr 2016, at 23:16, Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>> wrote:

Francois,

On Wed, Apr 6, 2016 at 8:22 PM, Francois Le Faucheur (flefauch) <[email-masked]<mailto:[email-masked]>> wrote:
Hi
I will post a new rev with the proposed change tomorrow unless i hear disagreement about that by then.

MUST UTC seems helpful to me as well. Thank you for working through this (non-blocking) comment.

Thanks
Francois

Sent from my iPhone

Hi Kevin,

Hi Alissa/all,

  to:

I think that would help.

Alexey,
Incoming AD for CDNI.

thanx.

--  Kevin J. Ma

Alissa and all,

The cdni-logging :

Thanks

Francois