>> 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.
sigh. a shy co-author reminded me privately that, to make it illegal to have both a remarks: geofeed reference and a geofeed: attribute would mandate that RIRs look *inside* all remarks: attributes. as a compiler writer in a long ago previous life, i really do not like looking inside comments. >> ** 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 if we leave the two SHOULDs, though sloppy, it provides pretty direct instruction to the fetching application without getting us into operational knots. randy _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
