IETF conflict review for draft-google-self-published-geofeeds
conflict-review-google-self-published-geofeeds-01
Yes
(Suresh Krishnan)
No Objection
Roman Danyliw
Éric Vyncke
(Alexey Melnikov)
(Alvaro Retana)
(Barry Leiba)
(Deborah Brungard)
(Martin Vigoureux)
Recuse
Note: This ballot was opened for revision 00 and is now closed.
Ballot question: "Is this the correct conflict review response?"
Roman Danyliw
No Objection
Éric Vyncke
No Objection
Warren Kumari
Recuse
Comment
(2020-01-21 for -00)
Sent
Recuse - author.
Alissa Cooper Former IESG member
Yes
Yes
(2020-01-21 for -00)
Not sent
Note (for the IESG) that the GEOPRIV WG closed in 2014.
Benjamin Kaduk Former IESG member
Yes
Yes
(2020-01-22 for -00)
Sent
Yes to the conflict-review response. Additional comments are for the authors. If this was an IETF-stream document, we'd have to document the "known flaws or omissions" that the shepherd writeup alludes to, e.g., in the Introduction and/or Abstract. Section 2.1 Feeds MUST use UTF-8 [RFC3629] character encoding. Text after a '#' character is treated as a comment only and ignored. Blank lines are similarly ignored. Comments are ignored only to the end of the current line, I trust. (What's the line separator?) Section 3.4 As a publisher can change geolocation data at any time and without notification, consumers SHOULD implement mechanisms to periodically refresh local copies of feed data. In the absence of any other refresh timing information, it is recommended that consumers SHOULD refresh feeds no less often than weekly. And presumably not so often that it causes excessive load/traffic, either. Section 8.1 To date, geolocation feeds have been shared informally in the form of HTTPS URIs exchanged in email threads. The two example URIs documented above describe networks that change locations periodically, the operators and operational practices of which are well known within their respective technical communities. Er, which two URIs are those, again? Section 11.2 RFC 4180 feels kind of normative ot me, and perhaps 5952 as well. Appendix A A clearer separation between the two code files might be helpful (e.g., separate BEGIN/END CODE markers).
Suresh Krishnan Former IESG member
Yes
Yes
(for -00)
Not sent
Adam Roach Former IESG member
No Objection
No Objection
(2020-01-22 for -00)
Not sent
No objection, although there should probably be an annotation along the lines of "...the (now closed) GEOPRIV working group..."
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -00)
Not sent
Alvaro Retana Former IESG member
No Objection
No Objection
(for -00)
Not sent
Barry Leiba Former IESG member
No Objection
No Objection
(for -00)
Not sent
Deborah Brungard Former IESG member
No Objection
No Objection
(for -00)
Not sent
Magnus Westerlund Former IESG member
(was Discuss)
No Objection
No Objection
(2020-01-23 for -00)
Sent for earlier
IESG discussion indicated we want to be clear on that GEOPRIV is closed in the response.
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -00)
Not sent
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2020-01-23 for -00)
Sent
I think the reply is fine but I agree that we could add the word "concluded" or something. However, I wonder why this work went to ISE. I guess we could have published this in the IETF as "Google's Geofeed Format" or something. Was that considered/discussed anywhere?