Subject: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-finding-geofeeds

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Mon, 19 Oct 2020 14:05:42 +0000

Hello, opsawg members.  The chairs would like to poll the working group on your interest for adopting this work.  As a reminder, this draft describes a way to use remarks attribute of the inetnum: class of RPSL to point consumers to goofed data for a given address block.  There has been some discussion on-list around this work, and the authors have incorporated said comments into the latest -04 version.

This serves as a two-week poll for adoption of this work.  Please reply with your support and especially any substantive comments you may have.  This call for adoption will end on November 2, 2020.

Joe for the opsawg co-chairs

Joe

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Mon, 19 Oct 2020 15:24:33 +0000

Writing as an individual, I have read -04 of this draft, and I think what it is proposing is useful (for the IETF conference net, in fact).  I support its adoption by opsawg.  I do think the “awesome” authentication bit might need to come out before ultimate publication, though.

Joe

> On Oct 19, 2020, at 10:05, Joe Clarke (jclarke) <jclarke=[email-masked]> wrote:
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Randy Bush <[email-masked]>
Date: Mon, 19 Oct 2020 10:39:41 -0700

> I do think the “awesome” authentication bit might need to come out
> before ultimate publication, though.

just the snark, or are you saying the whole auth?

randy

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Mon, 19 Oct 2020 17:45:51 +0000

Just the snark :-).

Joe

> On Oct 19, 2020, at 13:39, Randy Bush <[email-masked]> wrote:
>

---

From: Randy Bush <[email-masked]>
Date: Mon, 19 Oct 2020 10:49:16 -0700

>> just the snark, or are you saying the whole auth?

we can negotiate

btw, the draft is intended to document and prefer a new geofeed:
attribute, not just the interim remarks: hack.  e.g.

   Ideally, RPSL would be augmented to define a new RPSL geofeed:
   attribute in the inetnum: class.  Until such time, this document
   defines the syntax of a Geofeed remarks: attribute which contains an
   HTTPS URL of a geofeed file.

would you suggest stronger wording?

randy

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Mon, 19 Oct 2020 18:03:18 +0000

> On Oct 19, 2020, at 13:49, Randy Bush <[email-masked]> wrote:
> 
>> Just the snark :-).

Not with me.  I’d say leave it.  Probably with RFC Editor.

> would you suggest stronger wording?

When I read that, I assumed that such an attribute would be out of scope of this document and that would be a target of future work to happen in RIPE (perhaps?).

If this draft is intended to ALSO propose that, I would clearly describe the intended geofeed: attribute with examples and any additional links to work in RIPE. 

Joe

---

From: Randy Bush <[email-masked]>
Date: Mon, 19 Oct 2020 15:40:45 -0700

> When I read that, I assumed that such an attribute would be out of
> scope of this document and that would be a target of future work to
> happen in RIPE (perhaps?).

yep

> If this draft is intended to ALSO propose that, I would clearly
> describe the intended geofeed: attribute with examples and any
> additional links to work in RIPE.

how about

   Ideally, RPSL would be augmented to define a new RPSL geofeed:
   attribute in the inetnum: class.  Until such time, this document
   defines the syntax of a Geofeed remarks: attribute which contains an
   HTTPS URL of a geofeed file.  The format MUST be as in this example,
   "remarks: Geofeed " followed by a URL which will vary.

       inetnum: 192.0.2.0/24 # example
       remarks: Geofeed https://example.com/geofeed.csv

   While we leave global agreement of RPSL modification to the relevant
   parties, we suggest that a proper geofeed: attribute in the inetnum:
   class be simply "geofeed: " followed by a URL which will vary.

       inetnum: 192.0.2.0/24 # example
       geofeed: https://example.com/geofeed.csv

   Any particular inetnum: object MAY have, at most, one geofeed
   reference, whether a remark: or a proper geofeed: attribute when one
   is defined.

randy

---

From: Michael Richardson <[email-masked]>
Date: Mon, 19 Oct 2020 21:24:46 -0400

> class be simply "geofeed: " followed by a URL which will vary.

Hi Randy, the new text is much better, and I can live with it.

I'm lost as to why you don't just do the appropriate IANA action to register "geofeed".
Well, okay I looked it up, and maybe it's a challenge.

RFC2622 section 10.2 says:
   New attributes can be added to any class.  To ensure full
   compatibility, new attributes should not contradict the semantics of
   the objects they are attached to.  Any tool that uses the IRR should
   be designed so that it ignores attributes that it doesn't understand.
   Most existing tools adhere to this design principle.

And neither RFC2622 nor RFC4012 have an IANA Considerations.

I'm not sure what this means in the end, but it seems that your document can
just define geofeed: and Update RFC2622.  Maybe some AD will want you to
create a registry, but cross that bridge when you get to it.

Maybe Warren will comment.

The Remark: hack reminds me of COBOL or JCL, and I gotta wonder if it's necessary.
Are the ARIN and/or RIPE and... databases really so ossified that you need
this hack?

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Randy Bush <[email-masked]>
Date: Mon, 19 Oct 2020 19:33:14 -0700

> I'm lost as to why you don't just do the appropriate IANA action to
> register "geofeed".  Well, okay I looked it up, and maybe it's a
> challenge.
> 
> I'm not sure what this means in the end, but it seems that your
> document can just define geofeed: and Update RFC2622.  Maybe some AD
> will want you to create a registry, but cross that bridge when you get
> to it.
> 
> The Remark: hack reminds me of COBOL or JCL, and I gotta wonder if
> it's necessary.  Are the ARIN and/or RIPE and... databases really so
> ossified that you need this hack?

welcome to the realities of network operations, five registries who have
social issues, an ietf rps wg that was moribund, ...  if you really
care, i perhaps someone with more social skills than i can explain it
all to meet your interest.

but trust me, the remarks: finesse is needed, and the doc and massimo's
hack [geofeed-finder], are set to handle a transition should it happen.

randy

---

From: Robert Kisteleki <[email-masked]>
Date: Tue, 20 Oct 2020 08:47:58 +0200

>     reference, whether a remark: or a proper geofeed: attribute when one

(speaking as an individual)

Let's assume this becomes RFC9999, and I claim I implement/support 
RFC9999. What does that mean? MAY or SHOULD or MUST I support the 
geofeed: attribute?

I don't think that "ideally ... would be" or "suggest" help here.

Robert

---

From: Jonathan Kosgei <[email-masked]>
Date: Tue, 20 Oct 2020 11:02:03 +0300

I support this for adoption, we are a geolocation provider and find this
useful.

On Mon, Oct 19, 2020 at 6:25 PM Joe Clarke (jclarke) <jclarke=
[email-masked]> wrote:

> Writing as an individual, I have read -04 of this draft, and I think what
> it is proposing is useful (for the IETF conference net, in fact).  I
> support its adoption by opsawg.  I do think the “awesome” authentication
> bit might need to come out before ultimate publication, though.
>
> Joe
>
> > Hello, opsawg members.  The chairs would like to poll the working group
> on your interest for adopting this work.  As a reminder, this draft
> describes a way to use remarks attribute of the inetnum: class of RPSL to
> point consumers to goofed data for a given address block.  There has been
> some discussion on-list around this work, and the authors have incorporated
> said comments into the latest -04 version.
> >
> > This serves as a two-week poll for adoption of this work.  Please reply
> with your support and especially any substantive comments you may have.
> This call for adoption will end on November 2, 2020.
> >

---

From: Randy Bush <[email-masked]>
Date: Tue, 20 Oct 2020 11:35:21 -0700

< speaking as a random idiot >

> RFC9999. What does that mean? MAY or SHOULD or MUST I support the

something such as

   Until all producers of inetnum:s, i.e. the RIRs, state that they have
   migrated to supporting a geofeed: attribute, consumers looking at
   inetnum:s to find geofeed URLs MUST be able to consume both the
   remarks: and geofeed: forms.  This not only implies that the RIRs
   support the geofeed: attribute, but that all registrants have
   migrated any inetnum:s from remarks: use to geofeed:s.

randy

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Thu, 22 Oct 2020 17:48:59 +0000

> On Oct 19, 2020, at 18:40, Randy Bush <[email-masked]> wrote:
> 

I like this new text better, especially the last paragraph on how the two might interoperate.

Joe