Content Distribution Network Interconnection (CDNI) Logging Interface
draft-ietf-cdni-logging-27
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2016-08-26
|
27 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2016-08-01
|
27 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2016-07-06
|
27 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2016-06-28
|
27 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2016-06-28
|
27 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2016-06-28
|
27 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2016-06-27
|
27 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2016-06-27
|
27 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2016-06-16
|
27 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2016-06-09
|
27 | (System) | RFC Editor state changed to EDIT |
2016-06-09
|
27 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2016-06-09
|
27 | (System) | Announcement was received by RFC Editor |
2016-06-09
|
27 | (System) | IANA Action state changed to In Progress |
2016-06-09
|
27 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2016-06-09
|
27 | Amy Vezza | IESG has approved the document |
2016-06-09
|
27 | Amy Vezza | Closed "Approve" ballot |
2016-06-09
|
27 | Amy Vezza | Ballot approval text was generated |
2016-06-09
|
27 | Amy Vezza | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2016-06-09
|
27 | Amy Vezza | Ballot writeup was changed |
2016-06-08
|
27 | Ben Campbell | [Ballot comment] Thanks for addressing my DISCUSS and COMMENT points. |
2016-06-08
|
27 | Ben Campbell | [Ballot Position Update] Position for Ben Campbell has been changed to No Objection from Discuss |
2016-06-08
|
27 | Alexey Melnikov | [Ballot comment] Thank you for addressing my DISCUSS points. |
2016-06-08
|
27 | Alexey Melnikov | Ballot comment text updated for Alexey Melnikov |
2016-06-08
|
27 | François Le Faucheur | New version available: draft-ietf-cdni-logging-27.txt |
2016-05-29
|
26 | Alexey Melnikov | [Ballot comment] Thank you for addressing my DISCUSS points. Ok, you now clarified that version names are case-insensitive. However I didn't get this impression while … [Ballot comment] Thank you for addressing my DISCUSS points. Ok, you now clarified that version names are case-insensitive. However I didn't get this impression while reading 3.3, as there is no version ABNF there. So you might want to say that earlier in the document as well. In 7.1, last sentence: TLS only provides for protection from tampering when in transit, not when a log file being stored. |
2016-05-29
|
26 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss |
2016-05-25
|
26 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2016-05-25
|
26 | François Le Faucheur | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2016-05-25
|
26 | François Le Faucheur | New version available: draft-ietf-cdni-logging-26.txt |
2016-05-19
|
25 | Amy Vezza | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2016-05-18
|
25 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2016-05-18
|
25 | Ben Campbell | [Ballot discuss] While the security and privacy bits are much improved from earlier versions, I think I have found some holes. I assume these are … [Ballot discuss] While the security and privacy bits are much improved from earlier versions, I think I have found some holes. I assume these are not intentional, and it's entirely possible I have misread some things. But I would like to make sure they are considered prior to progressing. - 3.4.1, c-groupid: The privacy-related guidance about c-groupids indentifying individual clients (in the several bullet list entries with "-" bullets) seems contingent on the MAY in the parent (with the "+" bullet.) The parent says that you MAY structure the field so that parts identify the aggregate and one part aggregates the individual, with the sub-bullets following an "In this case..." clause. I assume the guidance is intended to apply even when an implementation doesn't structure c-groupid that way (or at all.) - 7.1: This section seems to effectively say that various protections are required when they are required. But it doesn't give advice on when they may be required. (For example, when c-groupid can be mapped to individual client addresses.) - 7.3: "Making detailed CDNI logging information known to the uCDN does not represent a particular privacy concern because the uCDN is already exposed at request redirection time to most of the information that shows up as CDNI logging information (e.g., enduser IP@, URL, HTTP headers - at least when HTTP redirection is used between uCDN and dCDN)." I agree this is mostly true for HTTP redirection. But as you mention, the assertion seems to fall down for DNS redirection, where the uCDN may have considerably less information. I think some different guidance for that case may be needed. -- "Transporting detailed CDNI logging information over the HTTP based CDNI Logging Interface does not represent a particular privacy concern because it is protected by usual IETF privacy-protection mechanism (e.g.,TLS)." I don't find normative text that says privacy-sensitive information MUST be protected. Just that information that needs to be protected MUST be protected. The reader is left to infer that privacy-sensitive information is covered by that. (See previous comment about 7.1). Without something explicit there, I think it highly likely that some people will rationalize that their deployments don't need protection for one reason or another. |
2016-05-18
|
25 | Ben Campbell | [Ballot comment] - 3.3, 2nd to last paragraph: What does it mean to reject a logging file? Does it mean to simply ignore it, or … [Ballot comment] - 3.3, 2nd to last paragraph: What does it mean to reject a logging file? Does it mean to simply ignore it, or does it imply some notice back the source of the file that there's a problem? (I tend to think of "reject" as implying the latter in a protocol, in contrast to words like "drop" or "ignore".) - 3.4.1, 3rd "-" bullet: "The algorithmic mapping and variation over time MAY allow the uCDN ... to reconstruct the actual client IPv4 or IPv6 address" Is that intended to be a 2119 MAY or a statement of fact? If the former, it seems to directly contradict the NOT RECOMMENDED in the next "-" bullet.. |
2016-05-18
|
25 | Ben Campbell | [Ballot Position Update] New position, Discuss, has been recorded for Ben Campbell |
2016-05-18
|
25 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2016-05-18
|
25 | Alexey Melnikov | [Ballot discuss] I know this document has long history and I want to get it done as well. Below is a list of small issues … [Ballot discuss] I know this document has long history and I want to get it done as well. Below is a list of small issues that I think need to be addressed: Is version directive value case-insensitive? The IANA registration is in lowercase, but all examples show uppercase. On page 28: SHA-3, AES-GCM and base64 all need normative references. (Use "Section 4 of [RFC4648]" for base64, as RFC 4648 defines 2 base54 encodings). On page 33: where does the "missing field value is denoted by -" specified in ABNF? If this is not defined in ABNF, it would be good to have an example record with a field missing. |
2016-05-18
|
25 | Alexey Melnikov | [Ballot comment] In 7.1, last sentence: TLS only provides for protection from tampering when in transit, not when a log file being stored. |
2016-05-18
|
25 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to Discuss from No Record |
2016-05-18
|
25 | Alexey Melnikov | [Ballot comment] Is version directive value case-insensitive? The IANA registration is in lowercase, but all examples show uppercase. On page 28: SHA-3, AES-GCM need references. … [Ballot comment] Is version directive value case-insensitive? The IANA registration is in lowercase, but all examples show uppercase. On page 28: SHA-3, AES-GCM need references. In 7.1, last sentence: TLS only provides for protection from tampering when in transit, not when a log file being stored. |
2016-05-18
|
25 | Alexey Melnikov | Ballot comment text updated for Alexey Melnikov |
2016-05-18
|
25 | Alexey Melnikov | [Ballot comment] Is version directive value case-insensitive? The IANA registration is in lowercase, but all examples show uppercase. In 7.1, last sentence: TLS only provides … [Ballot comment] Is version directive value case-insensitive? The IANA registration is in lowercase, but all examples show uppercase. In 7.1, last sentence: TLS only provides for protection from tampering when in transit, not when a log file being stored. |
2016-05-18
|
25 | Alexey Melnikov | Ballot comment text updated for Alexey Melnikov |
2016-05-18
|
25 | Alexey Melnikov | [Ballot comment] Is version directive value case-insensitive? The IANA registration is in lowercase, but all examples show uppercase. |
2016-05-18
|
25 | Alexey Melnikov | Ballot comment text updated for Alexey Melnikov |
2016-05-17
|
25 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2016-05-17
|
25 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2016-05-17
|
25 | Mirja Kühlewind | [Ballot comment] I still agree to the privacy concerns that have been raised earlier by Richard Barnes but don't see a solution that would justify … [Ballot comment] I still agree to the privacy concerns that have been raised earlier by Richard Barnes but don't see a solution that would justify a "DISCUSS" to hold up the document. Further I think it's important that TLS is mandatory and it could be useful to already state this earlier in the doc and not only Section 7. |
2016-05-17
|
25 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2016-05-16
|
25 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2016-04-26
|
25 | Spencer Dawkins | Telechat date has been changed to 2016-05-19 from 2015-03-05 |
2016-04-26
|
25 | Spencer Dawkins | IESG state changed to IESG Evaluation from Approved-announcement to be sent::Point Raised - writeup needed |
2016-04-07
|
25 | François Le Faucheur | New version available: draft-ietf-cdni-logging-25.txt |
2016-04-04
|
24 | Spencer Dawkins | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation::AD Followup |
2016-04-04
|
24 | Alissa Cooper | [Ballot 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 … [Ballot 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. |
2016-04-04
|
24 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Abstain |
2016-04-04
|
24 | François Le Faucheur | New version available: draft-ietf-cdni-logging-24.txt |
2016-03-31
|
23 | Alissa Cooper | [Ballot comment] I think we could resolve my DISCUSS points to the satisfaction of all parties given more time, but I think the issues have … [Ballot comment] I think we could resolve my DISCUSS points to the satisfaction of all parties given more time, but I think the issues have narrowed through the list discussion and time is running out to get this approved, so moving to abstain to not delay it further. |
2016-03-31
|
23 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to Abstain from Discuss |
2016-03-25
|
23 | Alissa Cooper | [Ballot discuss] I appreciate all the work that has gone into this document. It was originally up for IESG review when I was on leave, … [Ballot discuss] I appreciate all the work that has gone into this document. It was originally up for IESG review when I was on leave, so I was not able to review it at that time. The document needs one more ballot to progress, so I told Spencer I would review it. I realize it's probably frustrating to see another DISCUSS at this point but these should be straightforward to resolve I think. (1) I am wondering about a potential inconsistency that I see in Section 3.4.1. I see with the definition of the c-groupid field that there is inherent support for reporting about clients as aggregates, which is great, and even when reporting is done about individual clients there are a bunch of normative recommendations to try to reduce the chances that a logging field will be tied back to an individual user or host. Excellent. But then with the definition of the cs(insert_HTTP_header_name_here) field and discussion about it, there is no equivalent normative guidance given about not including headers that could potentially be used to identify an individual user or host. There is discussion about cookies but none of it is normative, and cookies are not the only headers that could be identifying. In fact, one of the examples given -- User-Agent -- is known to be identifying in some cases. Given the extent to which the specification of c-groupid goes to support masking the identity of the host, I would expect normative guidance about the use of the header field. That is, if an implementation is using c-groupid to represent an aggregate, it would make sense to me that it MUST NOT include header fields that could be uniquely identifying. I also wonder if the recommendations about cookies in 3.4.1 could be made normative. I will say that based on the use cases for these logs listed in 2.2.5 it's hard to understand what a uCDN needs headers like cookies for on a consistent basis; if they're needed for an occasional troubleshoot, logging them consistently seems like overkill. (2) Section 7.1 says: "In an environment where any such protection is required, mutually authenticated encrypted transport MUST be used to ensure confidentiality of the logging information. To that end, TLS MUST be used (including authentication of the remote end) by the server-side and the client-side of the CDNI Logging feed, as well as the server- side and the client-side of the CDNI Logging File pull mechanism." I know this text has been the subject of much discussion and careful editing, and that I raised an issue on this on the redirection draft. What I don't understand from reading this is whether the expectation is that all servers and clients implementing this specification will use TLS. The first sentence seems to indicate that there will be cases when that is not true. The second sentence says MUST use, which means use in every case. Which is it? |
2016-03-25
|
23 | Alissa Cooper | [Ballot comment] (1) Per my first DISCUSS point above, I wonder if it makes sense to specify a field where the dCDN could report a … [Ballot comment] (1) Per my first DISCUSS point above, I wonder if it makes sense to specify a field where the dCDN could report a sanitized version of the client User-Agent string. This would allow a uCDN to calculate the "terminal type" KPI listed in 2.2.5.5.2 without requiring full, potentially identifying User-Agent strings to be logged. (2) I think the use of partial-time in 3.4.1 means that the timestamps have no time zone information. It's not clear to me how the uCDN uses these timestamps in an absolute sense anyway, but I'm wondering if that could create problems if the uCDN does not know what time zone the dCDN is in. The time information in that case is somewhat meaningless if the uCDN needs to know the actual time at which something occurred. |
2016-03-25
|
23 | Alissa Cooper | [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper |
2016-03-18
|
23 | Barry Leiba | [Ballot comment] The ABNF issues have all been fixed; thanks for all the work on this. |
2016-03-18
|
23 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to Yes from Discuss |
2016-03-18
|
23 | François Le Faucheur | New version available: draft-ietf-cdni-logging-23.txt |
2016-03-02
|
22 | Stephen Farrell | [Ballot comment] Thanks for the additional text in -22, which clears up the last of my discuss points. old comments below, I didn't check 'em … [Ballot comment] Thanks for the additional text in -22, which clears up the last of my discuss points. old comments below, I didn't check 'em - in the description of c-groupid, "the address with a shared secret that is pre-synchronised and rotated at a predefined time interval" isn't very clear. I know what you mean but I don't think you state it very clearly. Could be that a bit of text earlier in the document that describes the basic idea would be better than doing it all inline as you have in -21. OLD COMMENTS Below, not updated for -21, I didn't check if you took 'em on board, feel free to chat about 'em if that's useful - I'm happy to do so anyway. - I support Richard's discuss. Isn't it ironic that the dCDN's privacy (that of a company) is better supported than that of the end user (a person) - 2.2.1 - why is per-chunk always needed? - 2.2.5.3: what's "track audience" mean? - 2.2.5.4: there are more security goals in the universe - 2.2.5.4: seems like the user is the enemy, that's odd - 2.2.5.6.2: there is no "browser type header" that I know of, but there is the well-known UA string. Being specific about that is better. - 3.1: SS.S - does that imply a time granularity of 100ms? If so, please say so. - 3.4.4: cs-uri: please not that these can be privacy sensitive, though presumably less so than e.g. logged URIs on a search engine. - 3.4.4: foo-uri: do these contain fragments or not? |
2016-03-02
|
22 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2016-03-02
|
22 | François Le Faucheur | New version available: draft-ietf-cdni-logging-22.txt |
2015-11-09
|
21 | Stephen Farrell | [Ballot discuss] DISCUSS points updated for -21, thanks for the great improvement in the privacy related stuff. I do however have one remaining (security related) … [Ballot discuss] DISCUSS points updated for -21, thanks for the great improvement in the privacy related stuff. I do however have one remaining (security related) thing to ask about but with a concrete suggested change below. (1) cleared (2) cleared (3) cleared (thanks!) (4) cleared (take as part of point (3) if need be) but I think you fixed it (5) I'm not clear why you need to be able to send HTTP header values or session IDs via this i/f. Why is that needed? And it seems very dangerous, e.g. "cs(COOKIE)" could be a doosy. I would suggest adding new text in section 3.4 to cover all of the log content basically saying that you really need to know what you're doing or you can break security very easily. Some suggested text that could be added to the end of 3.4 just before the start of 3.4.1: "Logging fields from HTTP requests and responses can be very dangerous. For example, cookies will often contain (months) long lived bearer token values that can be used to login to a service as the relevant user. Similar values may be included in other header fields or within URLs or elsewhere in HTTP requests and responses. Centralising such values in a log can therefore represent a significant increase in risk both for the user and the web service provider, but also for the CDNs involved. Implementations ought therefore attempt to lower the probability of such bad outcomes e.g. by only allowing a configured set of headers to be added to logs, or by not supporting wildcard selection of HTTP request/response fields to add. Such mechanisms can reduce the probability that security (or privacy) sensitive values are centralised in logs." I'm sure that can be improved on, and have no problem with any specific better words. (6) cleared (7) cleared |
2015-11-09
|
21 | Stephen Farrell | [Ballot comment] - in the description of c-groupid, "the address with a shared secret that is pre-synchronised and rotated at a predefined time interval" isn't … [Ballot comment] - in the description of c-groupid, "the address with a shared secret that is pre-synchronised and rotated at a predefined time interval" isn't very clear. I know what you mean but I don't think you state it very clearly. Could be that a bit of text earlier in the document that describes the basic idea would be better than doing it all inline as you have in -21. OLD COMMENTS Below, not updated for -21, I didn't check if you took 'em on board, feel free to chat about 'em if that's useful - I'm happy to do so anyway. - I support Richard's discuss. Isn't it ironic that the dCDN's privacy (that of a company) is better supported than that of the end user (a person) - 2.2.1 - why is per-chunk always needed? - 2.2.5.3: what's "track audience" mean? - 2.2.5.4: there are more security goals in the universe - 2.2.5.4: seems like the user is the enemy, that's odd - 2.2.5.6.2: there is no "browser type header" that I know of, but there is the well-known UA string. Being specific about that is better. - 3.1: SS.S - does that imply a time granularity of 100ms? If so, please say so. - 3.4.4: cs-uri: please not that these can be privacy sensitive, though presumably less so than e.g. logged URIs on a search engine. - 3.4.4: foo-uri: do these contain fragments or not? |
2015-11-09
|
21 | Stephen Farrell | Ballot comment and discuss text updated for Stephen Farrell |
2015-11-09
|
21 | Stephen Farrell | [Ballot discuss] DISCUSS points updated for -21, thanks for the great improvement in the privacy related stuff. I do however have one remaining thing to … [Ballot discuss] DISCUSS points updated for -21, thanks for the great improvement in the privacy related stuff. I do however have one remaining thing to ask but with a concrete suggested change below. (1) cleared (2) cleated (3) cleared (thanks!) (4) cleared (take as part of point (3) if need be) but I think you fixed it (5) I'm not clear why you need to be able to send HTTP header values or session IDs via this i/f. Why is that needed? (And it seems very dangerous, e.g. "cs(COOKIE)" could be a doosy.) (6) cleared (7) cleared |
2015-11-09
|
21 | Stephen Farrell | [Ballot comment] - in the description of c-groupid, "the address with a shared secret that is pre-synchronised and rotated at a predefined time interval" isn't … [Ballot comment] - in the description of c-groupid, "the address with a shared secret that is pre-synchronised and rotated at a predefined time interval" isn't clear. I know what you mean but I don't think you state it very clearly. OLD COMMENTS Below, not updated for -21, I didn't check if you took 'em on board, feel free to chat about 'em if that's useful - I'm happy to do so anyway. - I support Richard's discuss. Isn't it ironic that the dCDN's privacy (that of a company) is better supported than that of the end user (a person) - 2.2.1 - why is per-chunk always needed? - 2.2.5.3: what's "track audience" mean? - 2.2.5.4: there are more security goals in the universe - 2.2.5.4: seems like the user is the enemy, that's odd - 2.2.5.6.2: there is no "browser type header" that I know of, but there is the well-known UA string. Being specific about that is better. - 3.1: SS.S - does that imply a time granularity of 100ms? If so, please say so. - 3.4.4: cs-uri: please not that these can be privacy sensitive, though presumably less so than e.g. logged URIs on a search engine. - 3.4.4: foo-uri: do these contain fragments or not? |
2015-11-09
|
21 | Stephen Farrell | Ballot comment and discuss text updated for Stephen Farrell |
2015-11-03
|
21 | Kevin Ma | Notification list changed to "Kevin J. Ma" <kevin.j.ma@ericsson.com> |
2015-11-03
|
21 | Kevin Ma | Document shepherd changed to Kevin J. Ma |
2015-11-03
|
21 | François Le Faucheur | New version available: draft-ietf-cdni-logging-21.txt |
2015-10-16
|
20 | François Le Faucheur | New version available: draft-ietf-cdni-logging-20.txt |
2015-10-14
|
19 | (System) | Notify list changed from cdni-chairs@ietf.org, draft-ietf-cdni-logging@ietf.org to (None) |
2015-07-13
|
18 | Stephen Farrell | [Ballot discuss] DISCUSS points updated for -19, I'm not seeing changes that respond to my discuss points, nor do I recall email on the topic. … [Ballot discuss] DISCUSS points updated for -19, I'm not seeing changes that respond to my discuss points, nor do I recall email on the topic. (Apologies if I missed some.) I'd be happy to chat whenever folks are ready. Let me preface the specific discuss points with an overall point - I do not think our job here is to force CDNs to behave well in relation to privacy. However, it is our job to provide an API that encourages and effectively supports behaving well in relation to privacy. So, that said... (1) cleared (2) 3.3: Thanks for changing from MD5->SHA256 but I think you need the format for the SHA256-Hash thing to be 64HEXDIG don't you? (3) c-ip-anonymizing: guidance is needed that IPv4 and IPv6 aren't the same here. Why isn't the same idea done for c-port and other fields? Has there been any analysis of the effectiveness of this scheme in not allowing identification or re-identification? If not, isn't that really needed if we are serious about defining an API that can protect privacy? If that was discussed on the list, please send some pointers so I can get familiar with the work during the discussion. (4) cleared (take as part of point (3) if need be) but I think you fixed it (5) I'm not clear why you need to be able to send HTTP header values or session IDs via this i/f. Why is that needed? (And it seems very dangerous, e.g. "cs(COOKIE)" could be a doosy.) (6) cleared (7) This is kind of new, but I'd like to adopt Richard's DISCUSS so that doesn't get lost and it's very related to my point (3) too and I previously noted that I supported him. So that was: "I'm concerned that the information model of this log format encourages the sharing of far more granular information than is justified by the use cases. All of the use cases in Section 2 are focused on statistical information, in which case collecting things like individual IP addresses and ports is unnecessary." |
2015-07-13
|
18 | Stephen Farrell | Ballot discuss text updated for Stephen Farrell |
2015-07-06
|
19 | Iuniana Oprescu | New version available: draft-ietf-cdni-logging-19.txt |
2015-07-02
|
18 | Jean Mahoney | Closed request for Last Call review by GENART with state 'No Response' |
2015-06-08
|
18 | Gunter Van de Velde | Request for Telechat review by OPSDIR Completed. Reviewer: Benoit Claise. |
2015-06-08
|
18 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Benoit Claise |
2015-06-08
|
18 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Benoit Claise |
2015-04-20
|
18 | Kathleen Moriarty | [Ballot comment] Thanks for your work on this draft. I've cleared my prior discusses. Although for the first one I would have preferred my suggested … [Ballot comment] Thanks for your work on this draft. I've cleared my prior discusses. Although for the first one I would have preferred my suggested text over what you wound up with from the SecDir review after I had provided the suggestions just because I think it covers the points a bit more cleanly. |
2015-04-20
|
18 | Kathleen Moriarty | [Ballot Position Update] Position for Kathleen Moriarty has been changed to No Objection from Discuss |
2015-04-20
|
18 | Barry Leiba | [Ballot discuss] Pete has the ABNF issues in hand, and I'm happy to let him take care of that... but I'm picking up the DISCUSS … [Ballot discuss] Pete has the ABNF issues in hand, and I'm happy to let him take care of that... but I'm picking up the DISCUSS now that he's retired from the IESG. |
2015-04-20
|
18 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to Discuss from No Objection |
2015-04-20
|
18 | Kathleen Moriarty | [Ballot discuss] Thanks for your work on this draft. I'll clear on my prior discusses, for the first one, I would have preferred my suggested … [Ballot discuss] Thanks for your work on this draft. I'll clear on my prior discusses, for the first one, I would have preferred my suggested text over what you wound up with from the SecDir review after I had provided the suggestion just because I think it covers the points a bit more cleanly. I'm just leaving a discuss here to make sure Pete's points get covered, but I am not an ABNF expert. |
2015-04-20
|
18 | Kathleen Moriarty | Ballot discuss text updated for Kathleen Moriarty |
2015-04-14
|
18 | Stephen Farrell | [Ballot discuss] DISCUSS points updated for -18, thanks for the changes so far. I suspect for the next step we'll want to chat some. Let … [Ballot discuss] DISCUSS points updated for -18, thanks for the changes so far. I suspect for the next step we'll want to chat some. Let me preface the specific discuss points with an overall point - I do not think our job here is to force CDNs to behave well in relation to privacy. However, it is our job to provide an API that encourages and effectively supports behaving well in relation to privacy. So, that said... (1) cleared (2) 3.3: Thanks for changing from MD5->SHA256 but I think you need the format for the SHA256-Hash thing to be 64HEXDIG don't you? (3) c-ip-anonymizing: guidance is needed that IPv4 and IPv6 aren't the same here. Why isn't the same idea done for c-port and other fields? Has there been any analysis of the effectiveness of this scheme in not allowing identification or re-identification? If not, isn't that really needed if we are serious about defining an API that can protect privacy? If that was discussed on the list, please send some pointers so I can get familiar with the work during the discussion. (4) cleared (take as part of point (3) if need be) but I think you fixed it (5) I'm not clear why you need to be able to send HTTP header values or session IDs via this i/f. Why is that needed? (And it seems very dangerous, e.g. "cs(COOKIE)" could be a doosy.) (6) cleared (7) This is kind of new, but I'd like to adopt Richard's DISCUSS so that doesn't get lost and it's very related to my point (3) too and I previously noted that I supported him. So that was: "I'm concerned that the information model of this log format encourages the sharing of far more granular information than is justified by the use cases. All of the use cases in Section 2 are focused on statistical information, in which case collecting things like individual IP addresses and ports is unnecessary." |
2015-04-14
|
18 | Stephen Farrell | Ballot discuss text updated for Stephen Farrell |
2015-04-14
|
18 | Stephen Farrell | [Ballot discuss] DISCUSS points updated for -18, thanks for the changes so far. I suspect for the next step we'll want to chat some. Let … [Ballot discuss] DISCUSS points updated for -18, thanks for the changes so far. I suspect for the next step we'll want to chat some. Let me preface the specific discuss points with an overall point - I do not think our job here is to force CDNs to behave well in relation to privacy. However, it is our job to provide an API that encourages and effectively supports behaving well in relation to privacy. So, that said... (1) cleared (2) 3.3: Thanks for changing from MD5->SHA256 but I think you need the format for the SHA256-Hash thing to be 64HEXDIG don't you? (3) c-ip-anonymizing: guidance is needed that IPv4 and IPv6 aren't the same here. Why isn't the same idea done for c-port and other fields? Has there been any analysis of the effectiveness of this scheme in not allowing identification or re-identification? If not, isn't that really needed if we are serious about defining an API that can protect privacy? If that was discussed on the list, please send some pointers so I can get familiar with the work during the discussion. (4) cleared (take as part of point (3) if need be) but I think you fixed it (5) I'm not clear why you need to be able to send HTTP header values or session IDs via this i/f. Why is that needed? (And it seems very dangerous, e.g. "cs(COOKIE)" could be a doosy.) (6) cleared (7) This is kind of new, but I'd like to adopt Richard's DISCUSS so that doesn't get lost and it's very related to my point (3) too and I previously noted that I supported him. So that was: "I'm concerned that the information model of this log format encourages the sharing of far more granular information than is justified by the use cases. All of the use cases in Section 2 are focused on statistical information, in which case collecting things like individual IP addresses and ports is unnecessary." |
2015-04-14
|
18 | Stephen Farrell | [Ballot comment] OLD COMMENTS Below, not updated for -18, I didn't check if you took 'em on board, feel free to chat about 'em if … [Ballot comment] OLD COMMENTS Below, not updated for -18, I didn't check if you took 'em on board, feel free to chat about 'em if that's useful - I'm happy to do so anyway. - I support Richard's discuss. Isn't it ironic that the dCDN's privacy (that of a company) is better supported than that of the end user (a person) - 2.2.1 - why is per-chunk always needed? - 2.2.5.3: what's "track audience" mean? - 2.2.5.4: there are more security goals in the universe - 2.2.5.4: seems like the user is the enemy, that's odd - 2.2.5.6.2: there is no "browser type header" that I know of, but there is the well-known UA string. Being specific about that is better. - 3.1: SS.S - does that imply a time granularity of 100ms? If so, please say so. - 3.4.4: cs-uri: please not that these can be privacy sensitive, though presumably less so than e.g. logged URIs on a search engine. - 3.4.4: foo-uri: do these contain fragments or not? |
2015-04-14
|
18 | Stephen Farrell | Ballot comment and discuss text updated for Stephen Farrell |
2015-03-25
|
18 | Barry Leiba | [Ballot comment] Pete has the ABNF issues in hand, and I'm happy to let him take care of that. |
2015-03-25
|
18 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2015-03-25
|
18 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2015-03-23
|
18 | François Le Faucheur | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2015-03-23
|
18 | François Le Faucheur | New version available: draft-ietf-cdni-logging-18.txt |
2015-03-21
|
17 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Withdrawn' |
2015-03-19
|
17 | Cindy Morgan | New revision available |
2015-03-17
|
16 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2015-03-09
|
16 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2015-03-09
|
16 | François Le Faucheur | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2015-03-09
|
16 | François Le Faucheur | New version available: draft-ietf-cdni-logging-16.txt |
2015-03-05
|
15 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from Waiting for Writeup |
2015-03-05
|
15 | Cindy Morgan | Changed consensus to Yes from Unknown |
2015-03-05
|
15 | Jari Arkko | [Ballot comment] Thanks for working on this very useful specification. I think it is soon ready to move forward, but there are a couple of … [Ballot comment] Thanks for working on this very useful specification. I think it is soon ready to move forward, but there are a couple of things that we should try to address before the final approval. Martin raised a number of comments in the Gen-ART review, and I'd like to see the resolution of those. For me, I think the following issues at least deserve a document change: I'm not sure the definition of is correct. I would simply do CDNI-LOG-FILE = 1*(DIRGROUP / RECGROUP) For the reasons that Martin outlined. Also, Section 3.4.1 needs an update, given that HTTP 2 specifications have been approved. I suspect you could simply say that the work applies to both HTTP 1 and 2, and that any new information derived from HTTP 2 specifically is outside the scope of this spec. Security considerations should rather refer to existing mandates in TLS specifications (such as the UTA document that was recently approved) rather than make their own specific crypto requirements. |
2015-03-05
|
15 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss |
2015-03-05
|
15 | Ted Lemon | [Ballot comment] I support Stephen's DISCUSS, but don't otherwise object. |
2015-03-05
|
15 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2015-03-05
|
15 | Stephen Farrell | [Ballot discuss] Let me preface the specific discuss points with an overall point - I do not think our job here is to force CDNs … [Ballot discuss] Let me preface the specific discuss points with an overall point - I do not think our job here is to force CDNs to behave well in relation to privacy. However, it is our job to provide an API that encourages and effectively supports behaving well in relation to privacy. So, that said... (1) 2.2.5.5: there's no interoperability need for this section, and even if there are data retention requirements to be met, I don't see how the logging API is relevant to that. For example, a dCDN would not have it's data retention requirements met by a uCDN I think. I think just deleting this is the right action. (2) 3.3: MD5 is no longer good enough for data integrity and 128 bits in 32 ascii-hex is too short for SHA-256, which ought be the MUST alg here. (Some variable length is needed or else put the algorithm name in the field name.) (3) c-ip-anonymizing: guidance is needed that IPv4 and IPv6 aren't the same here. Why isn't the same idea done for c-port and other fields? Has there been any analysis of the effectiveness of this scheme in not allowing identification or re-identification? If not, isn't that really needed if we are serious about defining an API that can protect privacy? If that was discussed on the list, please send some pointers so I can get familiar with the work during the discussion. (4) Why is c-ip MTI but the (hopefully) privacy friendly variant is not? (5) I'm not clear why you need to be able to send HTTP header values or session IDs via this i/f. Why is that needed? (And it seems very dangerous, e.g. "cs(COOKIE)" could be a doosy.) (6) Just checking - given relevations of snooping, why not say "MUST use TLS with mutual-auth"? In particular if we don't end up with a usefully privacy-friendly version of this, where is the safe-but-cleartext use-case described that justifies the current SHOULD? |
2015-03-05
|
15 | Stephen Farrell | [Ballot comment] - I support Richard's discuss. Isn't it ironic that the dCDN's privacy (that of a company) is better supported than that of the … [Ballot comment] - I support Richard's discuss. Isn't it ironic that the dCDN's privacy (that of a company) is better supported than that of the end user (a person) - 2.2.1 - why is per-chunk always needed? - 2.2.5.3: what's "track audience" mean? - 2.2.5.4: there are more security goals in the universe - 2.2.5.4: seems like the user is the enemy, that's odd - 2.2.5.6.2: there is no "browser type header" that I know of, but there is the well-known UA string. Being specific about that is better. - 3.1: SS.S - does that imply a time granularity of 100ms? If so, please say so. - 3.4.4: cs-uri: please not that these can be privacy sensitive, though presumably less so than e.g. logged URIs on a search engine. - 3.4.4: foo-uri: do these contain fragments or not? |
2015-03-05
|
15 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2015-03-05
|
15 | Jari Arkko | [Ballot discuss] Thanks for working on this very useful specification. I think it is soon ready to move forward, but there are a couple of … [Ballot discuss] Thanks for working on this very useful specification. I think it is soon ready to move forward, but there are a couple of things that we should try to address before the final approval. Martin raised a number of comments in the Gen-ART review, and I'd like to see the resolution of those. For me, I think the following issues at least deserve a document change: I'm not sure the definition of is correct. I would simply do CDNI-LOG-FILE = 1*(DIRGROUP / RECGROUP) For the reasons that Martin outlined. Also, Section 3.4.1 needs an update, given that HTTP 2 specifications have been approved. I suspect you could simply say that the work applies to both HTTP 1 and 2, and that any new information derived from HTTP 2 specifically is outside the scope of this spec. Security considerations should rather refer to existing mandates in TLS specifications (such as the UTA document that was recently approved) rather than make their own specific crypto requirements. |
2015-03-05
|
15 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded for Jari Arkko |
2015-03-05
|
15 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2015-03-04
|
15 | Richard Barnes | [Ballot discuss] I'm concerned that the information model of this log format encourages the sharing of far more granular information than is justified by the … [Ballot discuss] I'm concerned that the information model of this log format encourages the sharing of far more granular information than is justified by the use cases. All of the use cases in Section 2 are focused on statistical information, in which case collecting things like individual IP addresses and ports is unnecessary. |
2015-03-04
|
15 | Richard Barnes | [Ballot Position Update] New position, Discuss, has been recorded for Richard Barnes |
2015-03-04
|
15 | Pete Resnick | [Ballot discuss] I am very concerned about the syntax specification here. I'm not convinced it's complete and correct. I am certainly willing to be talked … [Ballot discuss] I am very concerned about the syntax specification here. I'm not convinced it's complete and correct. I am certainly willing to be talked out of my concern, but I think this could use a massive edit by someone who knows ABNF, as well as a discussion about intended contents. Details: 3.1: I always prefer to import the rules you are using simply by reference rather than of copying them. Prevents silly errors. On these, let's see if you really mean what you say you mean: NAMEFORMAT = ALPHANUM *(ALPHANUM / "_" / "-") So, are you really OK with a NAMEFORMAT of "1---___---"? Often what people really want is: NAMEFORMAT = ALPHANUM *(["_" / "-"] ALPHANUM) Is that what you want? On the next bit: QSTRING = DQUOTE *NDQUOTE DQUOTE ; where NDQUOTE = / 2DQUOTE ; whereby a DQUOTE is conveyed inside a QSTRING unambiguously by repeating it. NHTABSTRING = *NHTAB ; where NHTAB = (By way of formatting, outdent NDQUOTE and NHTAB, and get rid of "; where".) When you say , is that what you really mean? You want to allow control characters? Seems to me that that is going to introduce a whole new set of security considerations. Also, the fact that you call these things xSTRING sends up a flag for me that you maybe want them to be textual. Are you allowing for things outside of US-ASCII? Section 3.2 seems to say only US-ASCII. Finally, do you really want NDQUOTE to allow for CR, LF, and HTAB? That means that parsers have to be a bit smarter, and the line in 3.2 that says, "Each line ... MUST contain either a directive of a CDNI Logging Record", and the line in 3.4 that says, "CDNI Logging Fields MUST be separated by the HTAB character", both seem bogus. So, assuming you want only US-ASCII and that you don't want CR LF or HTAB in any of these, these should be: QSTRING = DQUOTE *NDQUOTE DQUOTE NDQUOTE = SP / %x21 / %x23-7E / (DQUOTE DQUOTE) ; DQUOTE is conveyed inside a QSTRING unambiguously by repeating ; it. NHTABSTRING = *NHTAB NHTAB = SP / VCHAR or if you like, simply: NHTABSTRING = *( SP / VCHAR ) If you want non-US-ASCII, I'd include UTF-8 and call that out. I can tell you how to do that, but I hope you're not doing that. If you want CR and LF in both QSTRING and NHTABSTRING, and HTAB in QSTRING, you need to fix the lines in 3.2 and 3.4. If don't want them, you're going to have to describe how to unfold and de-tab the HTTP header field values somewhere. 3.2: RECLINE = CRLF RECGROUP = *RECLINE = 1* These seem kind of a cop-out. Seems like you could easily define RECLINE as: RECLINE = date HTAB time HTAB time-taken HTAB ... date = DATE time = TIME time-taken = DEC [...] The last line is nowhere near legitimate ABNF. How about just defining a proper LOGFILE as: LOGFILE = 1*(DIRGROUP RECGROUP) If you're going to bother with ABNF, use ABNF. The explanations can still appear in 3.3 and 3.4.1. 3.3: The top-level ABNF for DIRNAME and DIRVAL give the implementer no help with regard to what is legitimate syntax. You mention the syntax for DIRNAME in 6.1, but that's not where it belongs. At least you should put in: DIRNAME = NAMEFORMAT For DIRVAL, you should probably have at least the most general format of: DIRVAL = NHTABSTRING / QSTRING and then give specifics below. But you could also change 3.2 and say something like: DIRGROUP = version uuid [claimed-orig] [established-orig] 1*record-type 1*fields [integrity-hash] *new-dir Then in 3.3, you could define: version = "Version:" HTAB "CDNI" "/" 1*DIGIT "." 1*DIGIT uuid = "UUID:" HTAB NHTABSTRING ... new-dir = and indicate that unknown directives must be ignored, or something like that. This is wrong: o Fields: * format: FIENAME * Angle brackets don't appear like that in ABNF. 3.4: Again, incorrect ABNF, if that's what it's meant to be. |
2015-03-04
|
15 | Pete Resnick | [Ballot Position Update] New position, Discuss, has been recorded for Pete Resnick |
2015-03-04
|
15 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2015-03-03
|
15 | Kathleen Moriarty | [Ballot discuss] Thanks for your work on this draft. I'd like to discuss a few points rom the security considerations section that we should be … [Ballot discuss] Thanks for your work on this draft. I'd like to discuss a few points rom the security considerations section that we should be able to clear up quickly. In order for the following statements to be true, a little more text is needed, so I'll provide a suggestion. I see that you've recommended one of the cipher suites recommended in the new TLS BCP (in the RFC editor queue), so it appears a reference to that would be good to help with the strong statement already offered about TLS protections (true, if configured with best practice recommendations). Old: The use of TLS for transport of the CDNI Logging feed and CDNI Logging File pull allows: o the dCDN and uCDN to authenticate each other (to ensure they are transmitting/receiving CDNI Logging File from an authenticated CDN) o the CDNI Logging information to be transmitted with confidentiality o the integrity of the CDNI Logging information to be protected during the exchange New: The use of mutually authenticated TLS for transport, configured according to best practices [draft-ietf-uta-tls-bcp] of the CDNI Logging feed and CDNI Logging File pull allows: o the dCDN and uCDN to authenticate each other (to ensure they are transmitting/receiving CDNI Logging File from an authenticated CDN) o the CDNI Logging information to be transmitted with confidentiality o the integrity of the CDNI Logging information to be protected during the exchange I found the next paragraph a little difficult to read, so I'll offer a suggestion for that text as well. Old: In an environment where any such protection is required, TLS SHOULD be used (including authentication of the remote end) by the server- side and the client-side of the CDNI Logging feed and the CDNI Logging File pull mechanism unless alternate methods are used for ensuring the confidentiality of the information in the logging files (such as setting up an IPsec tunnel between the two CDNs or using a physically secured internal network between two CDNs that are owned by the same corporate entity). New: In an environment where any such protection is required, the use of a mutually authenticated encrypted transport MUST be used to ensure confidentiality of the log information. TLS SHOULD be used (including authentication of the remote end) by the server- side and the client-side of the CDNI Logging feed as well as by the CDNI Logging File pull mechanism unless alternate methods are used. Alternate methods could include establishing an IPsec tunnel between the two CDNs or using a physically secured internal network between two CDNs that are owned by the same corporate entity). Thanks for also putting thought into the privacy considerations and including anonymization options as that is one of the better options. I'd like to make a suggestion for the second paragraph as TLS is just protecting data in transit. Old: The use of TLS for transport of the CDNI Logging feed and CDNI Logging pull as discussed in Section 7.1 protects the confidentiality of logged information by preventing any other party than the authorised uCDN to gain access to the logging information. New: The use of mutually authenticated TLS to establish a secure session for the transport of the CDNI Logging feed and CDNI Logging pull as discussed in Section 7.1 protects access to the logged information. This provides confidentiality while the logs are in transit and prevents any other party than the authorised uCDN to gain access to the logging information. Thanks to the SecDir review which raised some of these issues. https://www.ietf.org/mail-archive/web/secdir/current/msg05452.html |
2015-03-03
|
15 | Kathleen Moriarty | [Ballot Position Update] New position, Discuss, has been recorded for Kathleen Moriarty |
2015-03-03
|
15 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2015-03-03
|
15 | Adrian Farrel | [Ballot comment] I have No Objection to the publication of this document. I don't think the use of "MAY" in section 5 adds anything over … [Ballot comment] I have No Objection to the publication of this document. I don't think the use of "MAY" in section 5 adds anything over "may" |
2015-03-03
|
15 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2015-03-02
|
15 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Klaas Wierenga. |
2015-03-02
|
15 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2015-02-18
|
15 | Spencer Dawkins | Ballot has been issued |
2015-02-18
|
15 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2015-02-18
|
15 | Spencer Dawkins | Created "Approve" ballot |
2015-02-18
|
15 | Spencer Dawkins | Ballot writeup was changed |
2015-02-18
|
15 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2015-02-17
|
15 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2015-02-17
|
15 | Amanda Baber | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-cdni-logging-15. Please report any inaccuracies and respond to any questions as soon as possible. IANA's reviewer has the following comments/questions: … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-cdni-logging-15. Please report any inaccuracies and respond to any questions as soon as possible. IANA's reviewer has the following comments/questions: IANA has a question about the creation of new registries requested in this document. Upon approval of this document, IANA understands that there are four actions which must be completed. IANA Question --> The IANA Considerations Section of this document requests the creation of three new registries. Where should these new registry be located? Should they be placed at an existing URL? If not, do they belong in an existing category at http://www.iana.org/protocols, or in a new one? If you'd like us to create a new webpage and/or a new category, please provide the titles of each. Would "CDN Interconnection (CDNI)" be appropriate for both? First, IANA will create a new registry called the CDNI Logging Directive Names Registry. The location for the new registry will be provided by a response to this note. The maintenance of the new registry will be through Specification Required as defined by RFC 5226. There are seven initial registrations in the new registry: +------------------------------+----------------+ | Directive Name | Reference | +------------------------------+----------------+ | Version | [ RFC-to-be ] | | UUID | [ RFC-to-be ] | | Claimed-Origin | [ RFC-to-be ] | | Established-Origin | [ RFC-to-be ] | | Record-Type | [ RFC-to-be ] | | Fields | [ RFC-to-be ] | | Integrity-Hash | [ RFC-to-be ] | +------------------------------+----------------+ Second, IANA will create a new registry called the CDNI Logging Record-Types Registry. The location for the new registry will be provided by a response to this note. The maintenance of the new registry will be through Specification Required as defined by RFC 5226. There is a single, initial registration in the new registry as follows: +----------------------+----------------+--------------------+ | Record-Types | Reference | Description | +----------------------+----------------+--------------------+ | cdni_http_request_v1 | [ RFC-to-be ] | CDNI Logging Record version 1 | | | | for content delivery using HTTP | +----------------------+----------------+--------------------+ Third, a new registry will be created called the CDNI Logging Field Names Registry. The location for the new registry will be provided by a response to this note. The maintenance of the new registry will be through Specification Required as defined by RFC 5226. There are twenty-one initial registrations in the new registry as follows: +------------------------------------------+----------------+ | Field Name | Reference | +------------------------------------------+----------------+ | date | [ RFC-to-be ] | | time | [ RFC-to-be ] | | time-taken | [ RFC-to-be ] | | c-ip | [ RFC-to-be ] | | c-ip-anonymizing | [ RFC-to-be ] | | c-port | [ RFC-to-be ] | | s-ip | [ RFC-to-be ] | | s-hostname | [ RFC-to-be ] | | s-port | [ RFC-to-be ] | | cs-method | [ RFC-to-be ] | | cs-uri | [ RFC-to-be ] | | u-uri | [ RFC-to-be ] | | protocol | [ RFC-to-be ] | | sc-status | [ RFC-to-be ] | | sc-total-bytes | [ RFC-to-be ] | | sc-entity-bytes | [ RFC-to-be ] | | cs() | [ RFC-to-be ] | | sc() | [ RFC-to-be ] | | s-ccid | [ RFC-to-be ] | | s-sid | [ RFC-to-be ] | | s-cached | [ RFC-to-be ] | +------------------------------------------+----------------+ Fourth, in the Application Media Types registry under the Media Types heading at https://www.iana.org/assignments/media-types/ a new application media type will be registered as follows: Name: cdni.LoggingFile Template: application/cdni.LoggingFile [ As-Provided-in-Document ] Reference: [ RFC-to-be ] Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. |
2015-02-10
|
15 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to David Harrington |
2015-02-10
|
15 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to David Harrington |
2015-02-05
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Martin Thomson |
2015-02-05
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Martin Thomson |
2015-02-05
|
15 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Klaas Wierenga |
2015-02-05
|
15 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Klaas Wierenga |
2015-02-04
|
15 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2015-02-04
|
15 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (CDNI Logging Interface) to Proposed … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (CDNI Logging Interface) to Proposed Standard The IESG has received a request from the Content Delivery Networks Interconnection WG (cdni) to consider the following document: - 'CDNI Logging Interface' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-02-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework. First, it describes a reference model for CDNI logging. Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-cdni-logging/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-cdni-logging/ballot/ No IPR declarations have been submitted directly on this I-D. |
2015-02-04
|
15 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2015-02-04
|
15 | Daryl Malas | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This draft is a proposed standard, because it normatively defines an interface for exchanging logging information between two or more interconnected CDNs. Yes, this is indicated on the page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework. First, it describes a reference model for CDNI logging. Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files. Working Group Summary: We had a lot of discussion regarding the security of the logging files, specifically as it relates to non-repudiation. Originally, the logging draft had text regarding non-repudiation, but later we determined non-repudiation was not as mature of a solution relative the rest of the logging draft and there was other work regarding non-repudiation occurring in the IETF. We decided to remove all references to non-repudiation for the following reasons: 1) Avoid the potential of defining anything for non-repudiation within CDNi and creating a conflict with other IETF work; 2) the requirement for non-repudiation was not a critical requirement for the logging draft. Recently, we had discussion and debate over which drafts should define the advertisement of capabilities (I.e., what logging fields are required to be supported). This was specifically related to the Footprint and Capabilities Interface (FCI) draft (https://tools.ietf.org/html/draft-ietf-cdni-footprint-capabilities-semantics-04). Ideally, capability advertisement would be defined with the interfaces themselves, but the FCI draft is not as mature as this (and other drafts). As a result of vigorous discussion, we decided to remove a placeholder for the FCI advertisement information from the logging draft. In the future, the FCI draft will define the template for FCI objects and a registry for FCI objects. We will publish a separate RFC for capability advertisement for the logging interface. We determined this approach as the best trade-off between draft publish expediency and necessary functionality. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? CDNI interfaces are still mostly in prototypes with plans for production support. Vendors, such as Cisco and Alcatel-Lucent, continue to progress the development and testing of the CDNI solution space, including the logging draft. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Daryl Malas (co-chair of CDNI) is the document shepherd, and Spencer Dawkins is the responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I completed a full review of the draft prior to submission to the IESG. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? I have no concerns. We completed a WGLC, a 3rd party review and expert (Ops Area – David Harrington) review of this draft. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Due to the Ops nature of this draft, we requested and received a thorough review from an expert in this area, David Harrington. We discussed and included necessary changes based on this review. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. I have no concerns with this draft. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? All authors confirmed there is no IPR to be disclosed on this draft. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? We have solid consensus with no concerns. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nits have been checked, and there are no “boilerplate” issues. We have a few miscellaneous issues, which can be resolved during IESG review, if necessary. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? N/A (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. N/A (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). I have reviewed the IANA considerations section to ensure it aligns with the body of the work whereas new registry items are properly defined in prior sections. Everything appears to be well defined, referenced and instructions described for future allocations. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. Expert reviews will need to take place for many of the CDNI documents, so a Directorate or expert review committee should be established for all CDNI drafts. To begin with, Francois Le Faucheur volunteered to be part of this committee. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. We requested a formal XML review, but we were unable to coordinate such a review. In lieu of this request, we validated the code would parse correctly in an XML editor. The result of this approach corrected an error in the XML code example within the draft. |
2015-02-04
|
15 | Spencer Dawkins | Placed on agenda for telechat - 2015-03-05 |
2015-02-04
|
15 | Spencer Dawkins | Last call was requested |
2015-02-04
|
15 | Spencer Dawkins | Ballot approval text was generated |
2015-02-04
|
15 | Spencer Dawkins | Ballot writeup was generated |
2015-02-04
|
15 | Spencer Dawkins | IESG state changed to Last Call Requested from Expert Review::External Party |
2015-02-04
|
15 | Spencer Dawkins | Last call announcement was generated |
2015-02-04
|
15 | Spencer Dawkins | Last call announcement was generated |
2015-02-04
|
15 | François Le Faucheur | New version available: draft-ietf-cdni-logging-15.txt |
2014-11-08
|
14 | Spencer Dawkins | Waiting on an expert review for the XML in the document. |
2014-11-08
|
14 | Spencer Dawkins | IESG state changed to Expert Review::External Party from Publication Requested |
2014-10-31
|
14 | Daryl Malas | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This draft is a proposed standard, because it normatively defines an interface for exchanging logging information between two or more interconnected CDNs. Yes, this is indicated on the page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework. First, it describes a reference model for CDNI logging. Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files. Working Group Summary: We had a lot of discussion regarding the security of the logging files, specifically as it relates to non-repudiation. Originally, the logging draft had text regarding non-repudiation, but later we determined non-repudiation was not as mature of a solution relative the rest of the logging draft and there was other work regarding non-repudiation occurring in the IETF. We decided to remove all references to non-repudiation for the following reasons: 1) Avoid the potential of defining anything for non-repudiation within CDNi and creating a conflict with other IETF work; 2) the requirement for non-repudiation was not a critical requirement for the logging draft. Recently, we had discussion and debate over which drafts should define the advertisement of capabilities (I.e., what logging fields are required to be supported). This was specifically related to the Footprint and Capabilities Interface (FCI) draft (https://tools.ietf.org/html/draft-ietf-cdni-footprint-capabilities-semantics-04). Ideally, capability advertisement would be defined with the interfaces themselves, but the FCI draft is not as mature as this (and other drafts). As a result of vigorous discussion, we decided to remove a placeholder for the FCI advertisement information from the logging draft. In the future, the FCI draft will define the template for FCI objects and a registry for FCI objects. We will publish a separate RFC for capability advertisement for the logging interface. We determined this approach as the best trade-off between draft publish expediency and necessary functionality. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? CDNI interfaces are still mostly in prototypes with plans for production support. Vendors, such as Cisco and Alcatel-Lucent, continue to progress the development and testing of the CDNI solution space, including the logging draft. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Daryl Malas (co-chair of CDNI) is the document shepherd, and Spencer Dawkins is the responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I completed a full review of the draft prior to submission to the IESG. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? I have no concerns. We completed a WGLC, a 3rd party review and expert (Ops Area – David Harrington) review of this draft. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Due to the Ops nature of this draft, we requested and received a thorough review from an expert in this area, David Harrington. We discussed and included necessary changes based on this review. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. I have no concerns with this draft. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? All authors confirmed there is no IPR to be disclosed on this draft. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? We have solid consensus with no concerns. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nits have been checked, and there are no “boilerplate” issues. We have a few miscellaneous issues, which can be resolved during IESG review, if necessary. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? N/A (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. N/A (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). I have reviewed the IANA considerations section to ensure it aligns with the body of the work whereas new registry items are properly defined in prior sections. Everything appears to be well defined, referenced and instructions described for future allocations. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. [Question: If the format is followed as described in the draft, is an expert review required? Is it recommended? I would like guidance on this as a document shepherd. Thanks.] (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. We have not completed an formal reviews of the included XML code. I request guidance on the right contact for pursing this. |
2014-10-31
|
14 | Daryl Malas | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2014-10-31
|
14 | Daryl Malas | IESG state changed to Publication Requested from AD is watching |
2014-10-31
|
14 | Daryl Malas | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This draft is a proposed standard, because it normatively defines an interface for exchanging logging information between two or more interconnected CDNs. Yes, this is indicated on the page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework. First, it describes a reference model for CDNI logging. Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files. Working Group Summary: We had a lot of discussion regarding the security of the logging files, specifically as it relates to non-repudiation. Originally, the logging draft had text regarding non-repudiation, but later we determined non-repudiation was not as mature of a solution relative the rest of the logging draft and there was other work regarding non-repudiation occurring in the IETF. We decided to remove all references to non-repudiation for the following reasons: 1) Avoid the potential of defining anything for non-repudiation within CDNi and creating a conflict with other IETF work; 2) the requirement for non-repudiation was not a critical requirement for the logging draft. Recently, we had discussion and debate over which drafts should define the advertisement of capabilities (I.e., what logging fields are required to be supported). This was specifically related to the Footprint and Capabilities Interface (FCI) draft (https://tools.ietf.org/html/draft-ietf-cdni-footprint-capabilities-semantics-04). Ideally, capability advertisement would be defined with the interfaces themselves, but the FCI draft is not as mature as this (and other drafts). As a result of vigorous discussion, we decided to remove a placeholder for the FCI advertisement information from the logging draft. In the future, the FCI draft will define the template for FCI objects and a registry for FCI objects. We will publish a separate RFC for capability advertisement for the logging interface. We determined this approach as the best trade-off between draft publish expediency and necessary functionality. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? CDNI interfaces are still mostly in prototypes with plans for production support. Vendors, such as Cisco and Alcatel-Lucent, continue to progress the development and testing of the CDNI solution space, including the logging draft. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Daryl Malas (co-chair of CDNI) is the document shepherd, and Spencer Dawkins is the responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I completed a full review of the draft prior to submission to the IESG. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? I have no concerns. We completed a WGLC, a 3rd party review and expert (Ops Area – David Harrington) review of this draft. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Due to the Ops nature of this draft, we requested and received a thorough review from an expert in this area, David Harrington. We discussed and included necessary changes based on this review. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. I have no concerns with this draft. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? All authors confirmed there is no IPR to be disclosed on this draft. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? We have solid consensus with no concerns. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nits have been checked, and there are no “boilerplate” issues. We have a few miscellaneous issues, which can be resolved during IESG review, if necessary. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? N/A (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. N/A (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). I have reviewed the IANA considerations section to ensure it aligns with the body of the work whereas new registry items are properly defined in prior sections. Everything appears to be well defined, referenced and instructions described for future allocations. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. [Question: If the format is followed as described in the draft, is an expert review required? Is it recommended? I would like guidance on this as a document shepherd. Thanks.] (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. We have not completed an formal reviews of the included XML code. I request guidance on the right contact for pursing this. |
2014-10-25
|
14 | François Le Faucheur | New version available: draft-ietf-cdni-logging-14.txt |
2014-07-24
|
13 | François Le Faucheur | New version available: draft-ietf-cdni-logging-13.txt |
2014-07-04
|
12 | François Le Faucheur | New version available: draft-ietf-cdni-logging-12.txt |
2014-04-08
|
11 | Gunter Van de Velde | Request for Early review by OPSDIR Completed: Has Issues. Reviewer: David Harrington. |
2014-03-31
|
11 | Gunter Van de Velde | Request for Early review by OPSDIR is assigned to David Harrington |
2014-03-31
|
11 | Gunter Van de Velde | Request for Early review by OPSDIR is assigned to David Harrington |
2014-03-31
|
11 | Gunter Van de Velde | Assignment of request for Early review by OPSDIR to Dorothy Gellert was rejected |
2014-03-29
|
11 | Daryl Malas | IETF WG state changed to In WG Last Call from WG Document |
2014-03-25
|
11 | François Le Faucheur | New version available: draft-ietf-cdni-logging-11.txt |
2014-03-10
|
10 | Gunter Van de Velde | Request for Early review by OPSDIR is assigned to Dorothy Gellert |
2014-03-10
|
10 | Gunter Van de Velde | Request for Early review by OPSDIR is assigned to Dorothy Gellert |
2014-03-03
|
10 | François Le Faucheur | New version available: draft-ietf-cdni-logging-10.txt |
2014-02-13
|
09 | François Le Faucheur | New version available: draft-ietf-cdni-logging-09.txt |
2014-01-30
|
08 | Daryl Malas | Document shepherd changed to Daryl Malas |
2013-10-18
|
08 | François Le Faucheur | New version available: draft-ietf-cdni-logging-08.txt |
2013-10-10
|
07 | François Le Faucheur | New version available: draft-ietf-cdni-logging-07.txt |
2013-09-27
|
06 | François Le Faucheur | New version available: draft-ietf-cdni-logging-06.txt |
2013-07-12
|
05 | François Le Faucheur | New version available: draft-ietf-cdni-logging-05.txt |
2013-06-25
|
04 | François Le Faucheur | New version available: draft-ietf-cdni-logging-04.txt |
2013-05-31
|
03 | François Le Faucheur | New version available: draft-ietf-cdni-logging-03.txt |
2013-05-27
|
02 | François Le Faucheur | New version available: draft-ietf-cdni-logging-02.txt |
2013-05-20
|
01 | Cindy Morgan | Shepherding AD changed to Spencer Dawkins |
2013-02-22
|
01 | Iuniana Oprescu | New version available: draft-ietf-cdni-logging-01.txt |
2012-12-18
|
00 | Martin Stiemerling | Intended Status changed to Proposed Standard |
2012-12-18
|
00 | Martin Stiemerling | IESG process started in state AD is watching |
2012-12-12
|
00 | Gilles Bertrand | New version available: draft-ietf-cdni-logging-00.txt |