Re: [Gen-art] Gen-ART Last Call review of draft-ietf-opsawg-finding-geofeeds-06

[Randy Bush <[e-mail]>]

hi paul:

thanks for the review.

> 1) Minor: Definition of "remarks: Geofeed"
> 
> Section 3 says:
> 
>    ... The format of the inetnum: geofeed
>    attribute MUST be as in this example, "remarks: Geofeed" followed by
>    a URL ...
> 
> From the examples and common sense there should be a space preceding
> the URL. But the text doesn't mention this.
> 
> I suggest changing to:
> 
>    ... The format of the inetnum: geofeed
>    attribute MUST be as in this example, "remarks: Geofeed " followed by
>    a URL ...

aha!  good one.  thanks.

> Also, is the word "Geofeed" case sensitive?

"MUST be as in this example."  do we need ABNF the ex compiler hacker
asks?  i can add enough syntactic sugar to give you a diabetic coma :)

i contend that it was good enough that your eagle eye caught a bug.

> 2) Minor: Modification of RPSL
> 
> Section 3 says:
> 
>    While we leave global agreement of RPSL modification to the relevant
>    parties, we specify that a proper geofeed: attribute in the inetnum:
>    class be simply "geofeed: " followed by a URL which will vary, but
>    MUST refer only to a [RFC8805] geofeed file.
>    ...
>    Until all producers of inetnum:s, i.e. the RIRs, state that they have
>    migrated to supporting a geofeed: attribute, consumers looking at
>    inetnum:s to find geofeed URLs MUST be able to consume both the
>    remarks: and geofeed: forms.
> 
> This is a bit presumptive. You say you are leaving the RPSL
> modification to others, yet you are herein standardizing the exact
> form that modification must take. What if the relevant parties want to
> choose a different form?

we have met the enemy and he is us -- pogo by walt kelly

the work is being done in the ripe database wg of which most authors are
part.  the wg is driving off this draft and really appreciates having
the syntax thrown over the wall.  the ripe community is more cooperative
than the ietf.

> 3) Minor/Nit: IANA Considerations
> 
> I don't understand why this section is present. I don't find any
> reference of it within the document.

   0 1197: SEQUENCE {
   4  917:  SEQUENCE {
   8    3:   [0] {
  10    1:    INTEGER 2
         :     }
  13   20:   INTEGER 27AD394083D7F2B5B99B8670C775B2B96EE166E3
  35   13:   SEQUENCE {
  37    9:    OBJECT IDENTIFIER
         :     sha256WithRSAEncryption (1 2 840 113549 1 1 11)   <<<<<=====
  48    0:    NULL
         :     }
...

you mean you don't read decoded certs for breakfast?  they are said to
make one strong.  the few i have tried had other effects :)

> 4) NIT: Use of "awesome"
> 
> I'm not sure how to feel about using *awesome* in the Introduction. It
> seems unusually informal for a standards document. But in a way I also
> find it refreshing.

so do we.  as i said to the kind opsdir reviewer, we'll see how far up
the chain a sense of perspective still exists.

> IdNits reports a number of things worth looking into. Notably the
> downrefs

the downrefs are only informational.  they are the best doccos on
INETNUM today.  sigh.

> and the lack of an IPv6 example.

iij deployed ipv6 on our global network in '97, so i don't really feel a
strong need to pander to the insecurities of today's ipv6 fans.  action
speaks louder than words.  </snark>.

as i said to kyle, secdir reviewer, unless someone pushes, i'll hold -07
until a few more reviews come in.

again, review MUCH appreciated.

randy