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
>>> 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.
> 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.
>> 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
randy
<<< text/html; charset=UTF-8; name="Diff draft-ietf-opsawg-finding-geofeeds-04.txt - draft-ietf-opsawg-finding-geofeeds.txt.html": Unrecognized >>>
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
