IETF conflict review for draft-google-self-published-geofeeds
conflict-review-google-self-published-geofeeds-01

The following approval message was sent
From: The IESG
To: draft-google-self-published-geofeeds@ietf.org,
    Adrian Farrel ,
    rfc-ise@rfc-editor.org
Cc: The IESG ,
    IETF-Announce ,
    iana@iana.org
Subject: Results of IETF-conflict review for draft-google-self-published-geofeeds-09

The IESG has completed a review of draft-google-self-published-geofeeds-09
consistent with RFC5742.

The IESG has no problem with the publication of 'A Format for Self-published
IP Geolocation Feeds'  as an
Informational RFC.

The IESG has concluded that this work is related to IETF work done in the
GEOPRIV WG (now closed), but this relationship does not prevent publishing.

The IESG would also like the Independent Submissions Editor to review the
comments in the datatracker related to this document and determine whether or
not they merit incorporation into the document. Comments may exist in both
the ballot and the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-google-self-published-geofeeds/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-google-self-published-geofeeds/

The process for such documents is described at
https://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]
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?

[Ballot discuss]
I think it is quite bad form to indicate that it relates to work (implied ongoing) when it is in fact not happening anymore. What do we do to modify the reply so that it doesn't imply that. In which way are the closed WG's work related to a conflict assessment between this document and any IETF work?

[Ballot comment]
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).