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

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Apr 2021 12:57:07 -0400

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-opsawg-finding-geofeeds-06
Reviewer: Paul Kyzivat
Review Date: 2021-04-29
IETF LC End Date: 2021-05-04
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.

General:

I'm not competent to review the crypto and security aspects of this 
document. Hopefully there will also be a security review to cover those.

Issues:

Major: 0
Minor: 3
Nits:  2

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 ...

Also, is the word "Geofeed" case sensitive?

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?

ISTM that this document should only mandate support for the Remarks form 
and leave support of the modified RPSL form to later, after RPSL has 
been updated.

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.

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.

I just suggest you rethink about whether you want that. I'm good either way.

5) Nit: IdNits

IdNits reports a number of things worth looking into. Notably the 
downrefs and the lack of an IPv6 example.

---

From: Randy Bush <[email-masked]>
Date: Thu, 29 Apr 2021 13:30:47 -0700

hi paul:

thanks for the review.

> the URL. But the text doesn't mention this.
> 
> I suggest changing to:
> 

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.

> 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.

> 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 :)

> seems unusually informal for a standards document. But in a way I also

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.

> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Apr 2021 10:31:00 -0400

Hi Randy,

Comments inline.

> asks?  i can add enough syntactic sugar to give you a diabetic coma :)

I don't think you need abnf. But some text specifying it is/isn't case 
sensitive would help. It may not be necessary if there is a strong 
established policy for handling case in RPSL. But even if there is it 
might not be applicable to processing the text of remarks.

> the syntax thrown over the wall.  the ripe community is more cooperative

If these two efforts are already coordinated then all is well.

> you mean you don't read decoded certs for breakfast? 

No I don't. Now it is clear.

> they are said to

> the chain a sense of perspective still exists.

It will be interesting to see.

> the downrefs are only informational.  they are the best doccos on

But the references are included in the Normative References section. If 
you put them in an Informative References section then I think IdNits 
will be happy.

> speaks louder than words.  </snark>.

Its only a matter of how much you want to fight mother nature (IdNits). 
If you "fix" the things it complains about then nobody will bring up the 
issue again.

	Thanks,
	Paul

---

From: Randy Bush <[email-masked]>
Date: Fri, 30 Apr 2021 09:35:57 -0700

mornin' paul,

> might not be applicable to processing the text of remarks.

will clarify.  how about

   The format of the inetnum: geofeed attribute MUST be as in this
   example, "remarks: Geofeed ", where the token "Geofeed" is case
   sensitive, followed by a URL which will vary, but MUST refer only to
   a single [RFC8805] geofeed file.

> No I don't.

nor do i.  but i trust russ :)

>>> 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.
> 

we tend to take ourselves too seriously.  but i hope there is life in
us yet.

> But the references are included in the Normative References
> section. If you put them in an Informative References section then I
> think IdNits will be happy.

something weird going on here.  in the -06 on datatrucker, i see the
INETNUM and INET6NUM refs under informative.  so we are either talking
about different downrefs or one or both of us needs new glasses.  clue
bat, please.

thanks!

randy