IETF Logo Mail Archive

Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-finding-geofeeds

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 20 October 2020 01:24 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4473A08E7 for <opsawg@ietfa.amsl.com>; Mon, 19 Oct 2020 18:24:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikchkV7QsbtL for <opsawg@ietfa.amsl.com>; Mon, 19 Oct 2020 18:24:55 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465DB3A08DC for <opsawg@ietf.org>; Mon, 19 Oct 2020 18:24:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 654E138995; Mon, 19 Oct 2020 21:30:58 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tepreHY3j0SZ; Mon, 19 Oct 2020 21:30:56 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8C37E38993; Mon, 19 Oct 2020 21:30:56 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 829BC976; Mon, 19 Oct 2020 21:24:46 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Randy Bush <randy@psg.com>
cc: "Joe Clarke (jclarke)" <jclarke@cisco.com>, opsawg <opsawg@ietf.org>
In-Reply-To: <m2imb5261e.wl-randy@psg.com>
References: <683B3974-C923-4B51-8C7E-3D8005941904@cisco.com> <8DB65180-CF9A-47B1-AD4F-6A8BCB1525E8@cisco.com> <m2sgaa15eq.wl-randy@psg.com> <3B399322-A264-4B26-A2E9-50D812F0F71D@cisco.com> <m2r1pu14yr.wl-randy@psg.com> <205C00AE-23D3-4C7C-9A3D-630C5039CAD8@cisco.com> <m2imb5261e.wl-randy@psg.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Mon, 19 Oct 2020 21:24:46 -0400
Message-ID: <28710.1603157086@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/60e8Or1uGUHCRnBM70ooxDjAIGg>
Subject: Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-finding-geofeeds
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Oct 2020 01:24:57 -0000

Randy Bush <randy@psg.com> 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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email