Re: [OPSAWG] AD review of draft-ietf-opsawg-finding-geofeeds-04

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Randy,

Inline ...

> -----Original Message-----
> From: Randy Bush <[e-mail]>
> Sent: 13 April 2021 18:44
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: Ops Area WG <[e-mail]>; draft-ietf-opsawg-finding-
> [e-mail]
> Subject: Re: AD review of draft-ietf-opsawg-finding-geofeeds-04
> 
> mornin rob,
> 
> new diff attached
> 
> > So, solely for my understanding, if 8805 was updated in an
> > incompatible way
> 
> then it would not be 8805.  it would not be a geofeed file.  so the
> kiddies then can have fun with a complete do-over and write their own
> finding-blarffles draft.
> 
> > This makes me question whether this comment in section 4 is
> > valid/correct: "Until [RFC8805] is updated to formally define such an
> > appendix".  My understanding is that this couldn't be done without
> > either breaking clients, or requiring new attribute names?
> 
> point, how about
> 
> Unless <xref target="RFC8805"/> is modified to formally define
[RW] 

My comment was less about what gets written in the documents, and more about how this update would actually be done in practice.  E.g., updating 8805 to indicate a new section would presumably break any existing clients expecting to fetch a regular CSV file via the "geofeed: or "remaks: geofeed" attributes?

I.e., it seems that either 8805 would have to be updated in backwards compatible way, and it looks like adding such an appendix wouldn't be backwards compatible (c.f., RFC 8805 section 7), or all clients would have to be updated before the publishing format is changed, or it would need new geofeed attribute names to publish the different versions of the geofeed data at the same time.

How wedded are you to that text?  Perhaps it would be simpler to just delete the "Until [RFC8805] is updated to formally define such an appendix" text and just say that the signature is always predicated by '#' comments?


> 
> >>> 4. I think that INETNUM should be a normative reference, but I also
> >>> question whether it is going to be a sufficiently stable reference?
> >>> Hence, I was wondering whether it wouldn't be helpful to describe the
> >>> essence of the INETNUM hierarchy here to avoid a need for a normative
> >>> reference.
> >>
> >> this is why 2275 and 4012 are normative and the refs to ripe docs are
> >> informative.
> >
> > RFC 2275 doesn't explain the hierarchy of INETNUM entries
> 
> yup.  which is why the informative INETNUM refs were left.
> 
> > I think that you need to add a couple of sentences to explain the
> > hierarchy so that you don't need the normative references to RIPE.
> 
>         The Routing Policy Specification Language (RPSL), <xref
>         target="RFC4012"/> used by the Regional Internet Registries
>         (RIRs) specifies inetnum: database objects.  Each of these
>         objects describes an IP address range and its attributes.  The
>         inetnum: objects form a hierarchy ordered on the address space.
> 
[RW] 

Ack.



> > I'm happy for you to try and get "utterly awesome (i.e., practical but
> > slightly complex)" through instead, but if you get push back then
> > you're on your own ;-)
> 
> some day i can tell you of jari pushing me to write the AplusP document
> and then not backing me when the anti-nat vigilantes attacked.
> 
> >>> I think that it would aid clarity, at a minimum, if it always at least
> >>> referred to as the "proper geofeed: attribute", but it may better to
> >>> just refer to it as the "proper geofeed attribute", i.e., to avoid
> >>> binding the name used in this document to the proposed long term name?
> >>
> >> let's see how this goes.  the irr folk working on this do not seem to
> >> be getting creative, at least along this dimension.
> >
> > Are they getting creative along other dimensions?  Who controls this
> > definition, and are they okay with the IETF constraining the
> > definition this way?  I.e., is it possible to get the "irr folk" to
> > agree that they are happy with what is being proposed here?
> 
> they are.  the ripe community is still old school cooperative.  of
> course they have to blah blah about it for a few months; but the end
> will be what we need.  and then the other rirs, excepting arin of
> course, will follow.  warren, massimo, and i are part of the ripe
> community.  not to worry.
[RW] 

Okay.  Thanks for confirming.


> 
> >>      The address range of the signing certificate MUST cover all
> >>      prefixes in the geofeed file it signs; and therefore must be
> >> 	covered by the range of the inetnum:.
> >
> > This looks plausible to me, but don't have the expertise to know.  I
> > assume that one of the authors will speak up if this is not right.
> 
> russ has not whacked me.  yet.
> 
> > No need.  I don't think that iff is well known enough
> 
> i think this says a sad bit about computer science and the ietf
[RW] 

To be fair, after a quick grep of RFCs, it isn't that 'iff' isn't used at all, but it is quite rare:
736 occurrences of "if and only if" vs 12 for "iff".

Hence, I think that using it would be iffy. ;-)

Rob


> 
> randy
>