hi med,

thanks a million for the time reviewing

>   *   Abstract: add "This document obsoletes RFC 9092.

sure; in my emacs buffer for -07.  aside: is this sort of doc tracking
in abstracts a fashion?

>   *   Abstract: s/datafiles/data files

doh.  thanks.

>   *   The changes vs 9092 lists "Geofeed file only UTF-8 CSV", but the
>       NEW abstract removes the CSV mentions that were called out in
>       the abstract of RFC9092. I would revert to the OLD wording in
>       9092.

my, admittedly poor, memory is that this happened because some other
reviewer pushed in the other direction.

but i think this would be a good change and is in my emacs buffer for
-07.  unless i hear otherwise, good change

>  * I would delete "Stress that authenticating geofeed data is
>    optional." as it was clear enough in 9092 that part is optional:
> "  An optional utterly awesome but slightly complex means for
>    authenticating geofeed data"

this was put in very intentionally.  we got a fair bit of ops reluctance
to implement because folk whined that the authentication was too high a
hill to climb.

to quote a proponent "This is probably the main push back I get from
people procrastinating [about] adoption."

so, unless you feel strongly, i suggest no harm in the redundancy of
leaving it in.

>   *   Inappropriate use of normative language in an example in Section
>       4: s/ this MUST be discarded because 192.0.2.0/24 is within the
>       more/ this must be discarded because 192.0.2.0/24 is within the
>       more

uh, discarding is not optional, but rather an 'absolute requirement'
[2119].  are we off here?  if you feel strongly, whack me again.

>   * Not sure I would keep the last para starting with "There is
>     open-source code to traverse ..." in Section 4. This is can be
>     moved to an appendix of to Section 8.

hmmm.  this is not describing an implementation (sec 8) of geofeed
objects, but a *use* of them.  it's a bit of a selling point, ease of
use.  i am open to argument either way.  clue bat please.

again, deep thanks for reviewing.  good reviews are not easy to get
these days.

randy

_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to