Re: [OPSAWG] Finding and Using Geofeed Data

[Owen DeLong]

I personally think it might be reasonable to add a standard for extended 
communities in BGP to represent prefix geo-data, but in general, I think it is 
preferable to discourage the idea that IP and physical addresses have any 
rational correlation whatsoever, since they really don’t and many of the 
instances I’ve encountered have wrong assumptions and sloppy thinking applied 
to create poor user experiences and those are the good ones.

Owen


> On Aug 31, 2020, at 1:45 PM, Massimo Candela  wrote:
> 
> Hi all,
> 
> IP geolocation is often essential but hard to correct when wrong, mostly
> due to the lack of a unified way to provide geolocation data.
> Internet operators may wish to publish the location of some
> of their IP addresses. RFC 8805 (geofeeds) allows network operators
> to publish "a mapping of IP address prefixes to simplified geolocation".
> Unfortunately it doesn't provide any mechanism to actually *find* the
> geofeed files.
> 
> Section 8  ("Finding Self-Published IP Geolocation Feeds") lists this
> as an open problem, and that:
>   Ad hoc mechanisms, while useful for early experimentation by
>   producers and consumers, are unlikely to be adequate for long-term,
>   widespread use by multiple parties.  Future versions of any such
>   self-published geolocation feed mechanism SHOULD address scalability
>   concerns by defining a means for automated discovery and verification
>   of operational authority of advertised prefixes.
> 
> This document provides a (simple) solution to this issue by describing
> a way to include a URL to a geofeed file in an inetnum object, and
> how to prudently consume such geolocation data.
> 
> Draft: https://tools.ietf.org/html/draft-ymbk-opsawg-finding-geofeeds-00
> 
> Please, provide your feedback.
> 
> Have a great day!
> 
> Ciao,
> Massimo
> 
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Finding and Using Geofeed Data

[Randy Bush]

> But “UTC” is more canonical than UCT.



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Finding and Using Geofeed Data

[Joe Clarke (jclarke)]

> On Sep 14, 2020, at 13:05, Randy Bush  wrote:
> 
>> FWIW, we tried to have some HTTP header discussion in 8805:
>> https://www.rfc-editor.org/rfc/rfc8805.html#name-refreshing-feed-information
> 
>An entity fetching geofeed data using these mechanisms MUST NOT
>do frequent real-time look-ups to prevent load on RPSL and
>geofeed servers.   Section 3.4 suggests
>use of the  HTTP Expires Cacheing Header
>to signal when geofeed data should be refetched.  As the data
>change very infrequently, in the absense of such an HTTP Header
>signal, collectors MUST NOT fetch more frequently than weekly.
>It would be wise not to fetch at magic times such as midnight
>UCT, the first of the month, etc., because too many others are
>likely to do the same.

This text works for me.  But “UTC” is more canonical than UCT.

Joe
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Finding and Using Geofeed Data

[Randy Bush]

> FWIW, we tried to have some HTTP header discussion in 8805:
> https://www.rfc-editor.org/rfc/rfc8805.html#name-refreshing-feed-information

An entity fetching geofeed data using these mechanisms MUST NOT
do frequent real-time look-ups to prevent load on RPSL and
geofeed servers.   Section 3.4 suggests
use of the  HTTP Expires Cacheing Header
to signal when geofeed data should be refetched.  As the data
change very infrequently, in the absense of such an HTTP Header
signal, collectors MUST NOT fetch more frequently than weekly.
It would be wise not to fetch at magic times such as midnight
UCT, the first of the month, etc., because too many others are
likely to do the same.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Finding and Using Geofeed Data

[Joe Clarke (jclarke)]

On Sep 14, 2020, at 01:11, Erik Kline 
mailto:ek.i...@gmail.com>> wrote:



On Sun, Sep 13, 2020 at 11:10 AM Massimo Candela 
mailto:mass...@us.ntt.net>> wrote:
Hi Joe,

Thanks for your feedback.

>
>> One thing that did stick out to me, though (and I don’t know how to
>> solve it) is when you talk about update frequency in section 5.  Okay,
>> don’t do frequent polls and don’t poll at midnight.  However, in the
>> case of something like the IETF conference network, how would
>> consumers know that this GeoFeed data _is_ likely to change and at a
>> certain periodicity?  The GeoFeed format doesn’t have any parsable way
>> to reflect that.  I don’t know if RPSL does.  Perhaps the remark:
>> could offer some clue as to when one might want to come and retaste?


>
>o could there be a signal on the server side, e.g. an expiry or
>  suggested poll frequency in the geofeeds file or in the pointer in
>  the rpsl?  for example, massimo is looking at html tags.

What I'm loking at is http cache max-age headers.
Since the geofeed file is served on http(s), that's free to achieve
(like for any other file).

FWIW, we tried to have some HTTP header discussion in 8805:

https://www.rfc-editor.org/rfc/rfc8805.html#name-refreshing-feed-information

The IETF is an example that can be solved with a simple operational practice 
that Warren already implements: update the contents of the feed the day after 
the conference ends.  This gives everyone ~3 months to learn the new location 
from the updated feed.

Thanks, Erik.  Yes, that should cover the periodicity.  A reference to that 
might be a good addition to the ops considerations in your new draft to 
complement the bit about not polling in real-time.

Joe


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Finding and Using Geofeed Data

[Erik Kline]

On Sun, Sep 13, 2020 at 11:10 AM Massimo Candela  wrote:

> Hi Joe,
>
> Thanks for your feedback.
>
> >
> >> One thing that did stick out to me, though (and I don’t know how to
> >> solve it) is when you talk about update frequency in section 5.  Okay,
> >> don’t do frequent polls and don’t poll at midnight.  However, in the
> >> case of something like the IETF conference network, how would
> >> consumers know that this GeoFeed data _is_ likely to change and at a
> >> certain periodicity?  The GeoFeed format doesn’t have any parsable way
> >> to reflect that.  I don’t know if RPSL does.  Perhaps the remark:
> >> could offer some clue as to when one might want to come and retaste?
>
>
> >
> >o could there be a signal on the server side, e.g. an expiry or
> >  suggested poll frequency in the geofeeds file or in the pointer in
> >  the rpsl?  for example, massimo is looking at html tags.
>
> What I'm loking at is http cache max-age headers.
> Since the geofeed file is served on http(s), that's free to achieve
> (like for any other file).
>

FWIW, we tried to have some HTTP header discussion in 8805:


https://www.rfc-editor.org/rfc/rfc8805.html#name-refreshing-feed-information

The IETF is an example that can be solved with a simple operational
practice that Warren already implements: update the contents of the feed
the day after the conference ends.  This gives everyone ~3 months to learn
the new location from the updated feed.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Finding and Using Geofeed Data

[Michael Richardson]

Joe Clarke \(jclarke\)  wrote:
> One thing that did stick out to me, though (and I don’t know how to
> solve it) is when you talk about update frequency in section 5.  Okay,
> don’t do frequent polls and don’t poll at midnight.  However, in the
> case of something like the IETF conference network, how would consumers
> know that this GeoFeed data _is_ likely to change and at a certain
> periodicity?  The GeoFeed format doesn’t have any parsable way to
> reflect that.  I don’t know if RPSL does.  Perhaps the remark: could
> offer some clue as to when one might want to come and retaste?

Yes, I got the impression that Randy doesn't want to fix the geofeed 
specification.
If one were to do that, then a TTL on each line, or a notAfter date would work.

The problem with the IETF/etc. conference network isn't that we don't update
things, but that caches don't expire sanely.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


signature.asc
Description: PGP signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Finding and Using Geofeed Data

[Massimo Candela]

Hi Joe,

Thanks for your feedback.




One thing that did stick out to me, though (and I don’t know how to
solve it) is when you talk about update frequency in section 5.  Okay,
don’t do frequent polls and don’t poll at midnight.  However, in the
case of something like the IETF conference network, how would
consumers know that this GeoFeed data _is_ likely to change and at a
certain periodicity?  The GeoFeed format doesn’t have any parsable way
to reflect that.  I don’t know if RPSL does.  Perhaps the remark:
could offer some clue as to when one might want to come and retaste?





   o could there be a signal on the server side, e.g. an expiry or
 suggested poll frequency in the geofeeds file or in the pointer in
 the rpsl?  for example, massimo is looking at html tags.


What I'm loking at is http cache max-age headers.
Since the geofeed file is served on http(s), that's free to achieve  
(like for any other file).



Ciao,
Massimo

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Finding and Using Geofeed Data

[Randy Bush]

> I just reviewed rev -02.  Other than noticing two ’s’ in “objects”
> in section 5, I didn’t notice any other issues.

thanks for taking a pass.  objectss corrected, plus a other thinks
erik kline pointed out.  we'll push -03 when there have been changes
of substance.

> One thing that did stick out to me, though (and I don’t know how to
> solve it) is when you talk about update frequency in section 5.  Okay,
> don’t do frequent polls and don’t poll at midnight.  However, in the
> case of something like the IETF conference network, how would
> consumers know that this GeoFeed data _is_ likely to change and at a
> certain periodicity?  The GeoFeed format doesn’t have any parsable way
> to reflect that.  I don’t know if RPSL does.  Perhaps the remark:
> could offer some clue as to when one might want to come and retaste?

i have recently become overly sensitive to this.  i have turned off
rrdp on my rpki CAs because of a DDoS by abusive pollers.  and i may
be driven to just turn off rpki entirely.

i see at least three pieces to the problem

  o what is a reasonable frequency?  imiho, things change very
infrequently.  the ietf meeting network should be happy with a
weekly poll.  but, as ggm might say, there is a discussion to be
had here.

  o could there be a signal on the server side, e.g. an expiry or
suggested poll frequency in the geofeeds file or in the pointer in
the rpsl?  for example, massimo is looking at html tags.

  o given the rpki DDoS, will implementors even follow guidelines in
an RFC?  if we assume not, then we probably should also specify
a damping mechanism on the service side.  there is a reason rpsl
servers are strongly damped.  welcome to the tragedy of the
commons.

folk might have other thoughts.

again, thanks for reading!

randy

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Finding and Using Geofeed Data

[Joe Clarke (jclarke)]

I just reviewed rev -02.  Other than noticing two ’s’ in “objects” in section 
5, I didn’t notice any other issues.

One thing that did stick out to me, though (and I don’t know how to solve it) 
is when you talk about update frequency in section 5.  Okay, don’t do frequent 
polls and don’t poll at midnight.  However, in the case of something like the 
IETF conference network, how would consumers know that this GeoFeed data _is_ 
likely to change and at a certain periodicity?  The GeoFeed format doesn’t have 
any parsable way to reflect that.  I don’t know if RPSL does.  Perhaps the 
remark: could offer some clue as to when one might want to come and retaste?

Joe

> On Sep 11, 2020, at 16:48, Randy Bush  wrote:
> 
> would appreciate review prior to calling for wg adoption
> 
> thanks
> 
> randy
> 
> A new version of I-D, draft-ymbk-opsawg-finding-geofeeds-02.txt
> has been successfully submitted by Randy Bush and posted to the
> IETF repository.
> 
> Name: draft-ymbk-opsawg-finding-geofeeds
> Revision: 02
> Title:Finding and Using Geofeed Data
> Document date:2020-09-11
> Group:Individual Submission
> Pages:16
> URL:
> https://www.ietf.org/id/draft-ymbk-opsawg-finding-geofeeds-02.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ymbk-opsawg-finding-geofeeds/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ymbk-opsawg-finding-geofeeds
> Htmlized:   
> https://tools.ietf.org/html/draft-ymbk-opsawg-finding-geofeeds-02
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ymbk-opsawg-finding-geofeeds-02
> 
> Abstract:
>   This document describes how to find and authenticate geofeed data.
> 
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Finding and Using Geofeed Data

[Randy Bush]

>> Identifying the private key associated with the certificate, and
>> getting the department with the HSM to sign the CMS blob is left as
>> an exercise for the implementor.
> 
> This cynical comment jumped out at me.
> It seems that you don't have a lot of confidence that the key will be
> easily used.

actually, i am hoping that ggm et alia will revive
draft-michaelson-rpki-rta

until then, i am personally not all that concerned about signing.  as
folk start to actually follow this path (and massimo is keeping a list
of those who are), after a while folk may care enough about authenticity
to go through the effort of signing geofeeds.

but we felt it incumbent on us to specify how to do so.

> As I understand it, you are not creating the geofeed: attribute, but
> instead shoving a URL into a "remark".

one thing at a time.  the ietf gave up on specifying rpsl a couple of
decades ago.  a first task i was given as a new ops area director was
to shoot the rps wg.  so we are not attempting to modify rpsl, though
we do suggest how it might be done.

> I don't see an IANA Considerations in RFC2622... so many you have to
> Updates?

let's you and them fight :)

> I gather from my quick reading that the geofeed data should be signed
> by the same RPKI key, and that such keys are rather high value.
> Should they be signing geofeed data?

got any other congruent authoritative keys?

> I understand RFC8805 to be a simple CSV format.
> One thought I have is to just stuff that into the "remark" directly.

scale issues.  as i just said on nanog

for some flat fan out last kilometer providers that could be the
inetnum: object from hell.  there are global providers which segment
large prefixes over diverse areas.  etc.

i doubt the rpsl providers would like multi-megabyte inetnum:s.  rpsl
providers already throttle in defense.

> I think that each inetnum:/inet6num: entry will be unique per prefix.
> Maybe the geography is not 1:1, particularly with larger IPv6
> allocations.

it isn't even for ipv4

> But, if the HTTP(S) indirection via URL requires a signature from the
> same key as the RPSL signature

there is no such thing as an rpsl signature.  and i sure as bleep ain't
gonna propose one.

> then why not just put a SHA256 hash into the remark, eliminating the
> need to find the private key?  That way, the same person with access
> signs both?

because, as the draft tries to politely say

Unfortunately the RPSL in many repositories is weakly authenticated
at best.

randy

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Finding and Using Geofeed Data

[Erik Kline]

On Fri, Sep 11, 2020 at 11:02 PM Randy Bush  wrote:

> thanks for review!  proposed diff attached.
>

Seems like a fair next step.  =)  I'll see about putting together a PR, too.

>   If the comments change, the signature changes?
>
> yep.  otherwise vast complexity lurks.  but is there a text change you
> want?  i may be naïve expecting that "a digest of the main body of the
> file" is sufficient.
>
> > [a] the source of the geofeed claims is authoritative to make said
> > claims for the contained prefixes, and
>
> iff you trust the rpki crypto chain
>
> > [b] the correctness of the claims themselves (i.e. that the location
> of
> > 2001:db8::/32 really is "Shire, Middle Earth").
>
> above my pay grade
>
> do you have suggested text?
>

No, I don't and I don't think we need any.  I just wanted to highlight that
there're 2 different things that could be "authenticated" -- where geofeeds
are concerned -- and this draft (rightly) only deals with one of them.
Probably not worth text unless it turns out folks find it confusing.

Thanks

>   The text from section 4 provides a suggestion: perhaps replace
> >   "authenticate" with "verify the authority of", or some such
> >   formulation?
>
> h.  hacked a bit.
>
> > [ section 1 ]
> >
> > * Probably the intro should hint at the authentication awesomeness
> contained
> >   within.  I think, actually, the last paragraph of section 2 can just be
> >   relocated to the end of this section and it will flow well.
>
> ok
>
> > [[ nits ]]
>
> thanks!
>
> randy
>
>
> < 
> draft-ymbk-opsawg-finding-geofeeds.txt
> 
> draft-ymbk-opsawg-finding-geofeeds.txt
>  >
> 
> skipping to change at* page 2, line 11 ¶* <#m_7593764623018977219_part-1> 
> skipping
> to change at* page 2, line 11 ¶* <#m_7593764623018977219_part-1>
> carefully, as they describe your rights and restrictions with respect 
> carefully,
> as they describe your rights and restrictions with respect
> to this document. Code Components extracted from this document must to
> this document. Code Components extracted from this document must
> include Simplified BSD License text as described in Section 4.e of include
> Simplified BSD License text as described in Section 4.e of
> the Trust Legal Provisions and are provided without warranty as the Trust
> Legal Provisions and are provided without warranty as
> described in the Simplified BSD License. described in the Simplified BSD
> License.
> Table of Contents Table of Contents
> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.
> Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
> 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 1.1.
> Requirements Language . . . . . . . . . . . . . . . . . . 2
> 2. Geofeed Files . . . . . . . . . . . . . . . . . . . . . . . . 2 2.
> Geofeed Files . . . . . . . . . . . . . . . . . . . . . . . . 3
> 3. inetnum: Class . . . . . . . . . . . . . . . . . . . . . . . 3 3.
> inetnum: Class . . . . . . . . . . . . . . . . . . . . . . . 3
> 4. Authenticating Geofeed Data . . . . . . . . . . . . . . . . . 3 4.
> Authenticating Geofeed Data . . . . . . . . . . . . . . . . . 3
> 5. Operational Considerations . . . . . . . . . . . . . . . . . 5 5.
> Operational Considerations . . . . . . . . . . . . . . . . . 5
> 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6.
> Security Considerations . . . . . . . . . . . . . . . . . . . 5
> 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7.
> IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
> 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 8.
> Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
> 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 9.
> Normative References . . . . . . . . . . . . . . . . . . . . 6
> Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 7 Appendix
> A. Example . . . . . . . . . . . . . . . . . . . . . . 7
> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors'
> Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
> 1. Introduction 1. Introduction
> Providers of Internet content and other services may wish to Providers of
> Internet content and other services may wish to
> customize those services based on the geographic location of the user 
> customize
> those services based on the geographic location of the user
> of the service. This is often done using the source IP address used of
> the service. This is often done using the source IP address used
> to contact the service. Also, infrastructure and other services to
> contact the service. Also, infrastructure and other services
> might wish to publish the 

Re: [OPSAWG] Finding and Using Geofeed Data

[Michael Richardson]

>   Identifying the private key associated with the certificate, and
>   getting the department with the HSM to sign the CMS blob is left as
>   an exercise for the implementor.

This cynical comment jumped out at me.
It seems that you don't have a lot of confidence that the key will be easily 
used.

As I understand it, you are not creating the geofeed: attribute, but instead
shoving a URL into a "remark".  (Wasn't JCL afflicted by endless hacks like 
this?)
(I don't see an IANA Considerations in RFC2622... so many you have to Updates?)

I gather from my quick reading that the geofeed data should be signed by the
same RPKI key, and that such keys are rather high value.
Should they be signing geofeed data?

I understand RFC8805 to be a simple CSV format.
One thought I have is to just stuff that into the "remark" directly.
I think that each inetnum:/inet6num: entry will be unique per prefix.
Maybe the geography is not 1:1, particularly with larger IPv6 allocations.

But, if the HTTP(S) indirection via URL requires a signature from the same
key as the RPSL signature, then why not just put a SHA256 hash into the
remark, eliminating the need to find the private key?
That way, the same person with access signs both?

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Finding and Using Geofeed Data

[Randy Bush]

thanks for review!  proposed diff attached.

>   If the comments change, the signature changes?

yep.  otherwise vast complexity lurks.  but is there a text change you
want?  i may be naïve expecting that "a digest of the main body of the
file" is sufficient.

> [a] the source of the geofeed claims is authoritative to make said
> claims for the contained prefixes, and

iff you trust the rpki crypto chain

> [b] the correctness of the claims themselves (i.e. that the location of
> 2001:db8::/32 really is "Shire, Middle Earth").

above my pay grade

do you have suggested text?

>   The text from section 4 provides a suggestion: perhaps replace
>   "authenticate" with "verify the authority of", or some such
>   formulation?

h.  hacked a bit.

> [ section 1 ]
> 
> * Probably the intro should hint at the authentication awesomeness contained
>   within.  I think, actually, the last paragraph of section 2 can just be
>   relocated to the end of this section and it will flow well.

ok

> [[ nits ]]

thanks!

randy


<<< text/html; charset=UTF-8; name="Diff draft-ymbk-opsawg-finding-geofeeds.txt - draft-ymbk-opsawg-finding-geofeeds.txt.html": Unrecognized >>>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Finding and Using Geofeed Data

[Erik Kline]

On Fri, Sep 11, 2020 at 1:48 PM Randy Bush  wrote:

> would appreciate review prior to calling for wg adoption
>
> thanks
>
> randy
>
> A new version of I-D, draft-ymbk-opsawg-finding-geofeeds-02.txt
> has been successfully submitted by Randy Bush and posted to the
> IETF repository.
>
> Name:   draft-ymbk-opsawg-finding-geofeeds
> Revision:   02
> Title:  Finding and Using Geofeed Data
> Document date:  2020-09-11
> Group:  Individual Submission
> Pages:  16
> URL:
> https://www.ietf.org/id/draft-ymbk-opsawg-finding-geofeeds-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-ymbk-opsawg-finding-geofeeds/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ymbk-opsawg-finding-geofeeds
> Htmlized:
> https://tools.ietf.org/html/draft-ymbk-opsawg-finding-geofeeds-02
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ymbk-opsawg-finding-geofeeds-02
>
> Abstract:
>This document describes how to find and authenticate geofeed data.
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg



Probably I should have noticed this before and/or just sent a pull request,
but for the sake of discussion, here are some random thoughts.


[[ questions ]]

[ section 4 ]

* Based on RFC 5485 section 2.2, I assume that any comments in the geofeed
  prior to having the CMS appended are included in the canonicalized text?

  ##
  # Auto-generated by shirebot; do not edit.
  ##
  # This conference is in the Prancing Pony.
  2001:db8:1::/48,Shire,West Farthing,Hobbiton,
  2001:db8:2::/48,Shire,East Farthing,Frogmorton, # NOC is by the
stables

  If the comments change, the signature changes?  That seems fine to me, I
  just wanted to be sure.


[[ comments ]]

[ abstract ]

* "authenticate geofeed data"

  There are two things that need authenticating or verifying when it comes
  to geofeeds:

[a] the source of the geofeed claims is authoritative to make said
claims for the contained prefixes, and

[b] the correctness of the claims themselves (i.e. that the location of
2001:db8::/32 really is "Shire, Middle Earth").

  This document nicely addresses "a" (whereas "b" is necessarily left as an
  exercise for the consumer).

  The text from section 4 provides a suggestion: perhaps replace
  "authenticate" with "verify the authority of", or some such formulation?

[ section 1 ]

* Probably the intro should hint at the authentication awesomeness contained
  within.  I think, actually, the last paragraph of section 2 can just be
  relocated to the end of this section and it will flow well.


[[ nits ]]

[ section 5 ]

* s/objectss/objects/

[ section 6 ]

* "an sadly"
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Finding and Using Geofeed Data

[Randy Bush]

would appreciate review prior to calling for wg adoption

thanks

randy

A new version of I-D, draft-ymbk-opsawg-finding-geofeeds-02.txt
has been successfully submitted by Randy Bush and posted to the
IETF repository.

Name:   draft-ymbk-opsawg-finding-geofeeds
Revision:   02
Title:  Finding and Using Geofeed Data
Document date:  2020-09-11
Group:  Individual Submission
Pages:  16
URL:
https://www.ietf.org/id/draft-ymbk-opsawg-finding-geofeeds-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-ymbk-opsawg-finding-geofeeds/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ymbk-opsawg-finding-geofeeds
Htmlized:   
https://tools.ietf.org/html/draft-ymbk-opsawg-finding-geofeeds-02
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ymbk-opsawg-finding-geofeeds-02

Abstract:
   This document describes how to find and authenticate geofeed data.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg