Hi Randy,
Comments inline.
On 4/29/21 4:30 PM, Randy Bush wrote:
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 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.
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.
If these two efforts are already coordinated then all is well.
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?
No I don't. Now it is clear.
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.
It will be interesting to see.
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.
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.
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>.
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
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
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
