thanks roman,
> ** Section 3. Editorial. Consider this clarification.
> OLD
> At the time of publishing this document, change control effectively
> lies in the operator community.
>
> NEW
> At the time of publishing this document, change control of RPSL effectively
> lies in the operator community.
yup. paul w tripped over it.
> ** Section 3.
>
> Any particular inetnum: object SHOULD have, at most, one geofeed
> reference, whether a remarks: or a proper geofeed: attribute when it
> is implemented. A geofeed: attribute is preferred, of course, if the
> RIR supports it. If there is more than one type of attribute in the
> intetnum: object, the geofeed: attribute SHOULD be used.
>
> Is there a reason that the second SHOULD, to prefer the geofeed:
> attribute isn’t a MUST? Otherwise, there isn’t deterministic behavior
> on which attribute will be used and geofeed: won’t necessarily be
> preferred.
i think we have been over this one before, but i can not remember the
rationale. unless i hear otherwise from co-authors or general public,
i am happy to change the second to MUST.
note that below i suggest also making the first SHOULD a MUST to make
life a bit simpler. i do not remember why we wussed out on this.
> ** Section 3
> For inetnum:s covering the same address range, or an inetnum: with
> both remarks: and geofeed: attributes, a signed geofeed file SHOULD
> be preferred over an unsigned file.
>
> Is the net result of this guidance that when encountering a both types
> of attributes, and despite preferring the geofeed, an implementation
> still needs to download both and see which one is signed?
this runs into trouble with the previous, especially if it becomes
If there is more than one type of attribute in the intetnum: object,
the geofeed: attribute MUST be used.
> Effectively:
>
> If there is more than one type of attribute in the intetnum: object,
> the geofeed: attribute SHOULD be used unless the remarks: is signed?
or vice versa, of course
personally, i would cut the gordian knot and simply not allow both
remarks: and geofeed: in an inetnum: object.
but i note that the bit from section 3 you quote also talks about
multiple inetnums: over the same address range.
> ** Section 4.
>
> To minimize the load on RIRs' WHOIS [RFC3912] services, the RIR's FTP
> [RFC0959] services SHOULD be used for large-scale access to gather
> inetnum:s with geofeed references. This uses efficient bulk access
> instead of fetching via brute-force search through the IP space.
>
> This guidance was in RFC9092 (July 2021). Has anything changed in the
> ecosystem that would allow the use of at least SFTP?
not that i am aware, but i could be wrong. this is a facility provided
by the RIRs.
randy
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
