Randy Bush <[email protected]> wrote:
    >> 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.

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 protected]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

Attachment: signature.asc
Description: PGP signature

_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to