Re: [Idr] Lars Eggert's No Objection on draft-ietf-idr-bgp-flowspec-oid-13: (with COMMENT)

["Juan Alcaide (jalcaide)" <[e-mail]>]

Thanks Lars,

Thanks for your comments. Sorry, I missed them before publishing -14. Some of changes on -14 address your concerns.

I'll incorporate most of your comments.
Please take a look at my answer to John for the rewrite of Section 7, paragraph 4. He had also some rewriting ideas a bit different.

-J

-----Original Message-----
From: Lars Eggert via Datatracker <[e-mail]> 
Sent: Monday, May 10, 2021 12:27 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Susan Hares <[e-mail]>; [e-mail]; [e-mail]
Subject: Lars Eggert's No Objection on draft-ietf-idr-bgp-flowspec-oid-13: (with COMMENT)

Lars Eggert has entered the following ballot position for
draft-ietf-idr-bgp-flowspec-oid-13: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-flowspec-oid/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 7, paragraph 4, comment:
>    from a route server peer.  If that peer is known for a fact not to be
>    a route server, that optional rule SHOULD be enforced for Flow
>    Specification routes.

The phrasing here seems complicated. Would it be easier to say that the rule MUST NOT be enforced if the peer is known to be a route server?

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools, so there will likely be some false positives. There is no need to let me know what you did with these suggestions.

Section 5, paragraph 2, nit:
-    it has a congruent topology amongst ipv4 unicast routes and Flow
-                                        ^^
+    it has a congruent topology amongst IPv4 unicast routes and Flow
+                                        ^^

Section 5, paragraph 2, nit:
-    for the two equivalent routes (i.e. the Flow Specification route and
-    its best-match unicast route) are learned from the same peer accross
-                                                                   -
+    for the two equivalent routes (i.e., the Flow Specification route and
+                                       +
+    its best-match unicast route) are learned from the same peer across

Section 7, paragraph 2, nit:
-    servers.  This change is in line with the procedures in [rfc8955] and
-                                                             ^^^
+    servers.  This change is in line with the procedures in [RFC8955] and
+                                                             ^^^

Section 7, paragraph 4, nit:
-    hereby optional (section 4.2).  If that original rule is actually not
-           ^^^^^^^^
-    enforced it may introduce some security risks.  A peer (or a client
+    hereby OPTIONAL (section 4.2).  If that original rule is actually not
+           ^^^^^^^^
+    enforced, it may introduce some security risks.  A peer (or a client
+            +

Section 2, paragraph 3, nit:
> e in an autonomous system with a large number of border routers having compl
>                                ^^^^^^^^^^^^^^^^^
Specify a number, remove phrase, or simply use "many" or "numerous"

Section 2, paragraph 7, nit:
> n autonomous system which has a large number of border routers having complex
>                               ^^^^^^^^^^^^^^^^^^^^
Specify a number, remove phrase, or simply use "many" or "numerous"

Section 3, paragraph 8, nit:
> ms exist to protect each AS independently from network security attacks using
>                             ^^^^^^^^^^^^^^^^^^
The usual collocation for "independently" is "of", not "from". Did you mean "independently of"?

Section 4.1, paragraph 2, nit:
> tion 6 is redefined as follows: b) One of the following conditions MUST ho
>                                  ^
Unpaired symbol: '(' seems to be missing

Section 4.1, paragraph 6, nit:
> he next list item (b.2.1)).. an empty AS_PATH. 2. This
>                           ^^
Two consecutive dots

Section 4.2, paragraph 12, nit:
> bious. Although it is conceivable that an router in the same local domain (
>                                        ^^
Use "a" instead of 'an' if the following word doesn't start with a vowel sound, e.g. 'a sentence', 'a university'.

Section 5, paragraph 2, nit:
> tter applies, a network should be designed so it has a congruent topology am
>                                   ^^^^^^^^^^^
Use a comma before 'so' if it connects two independent clauses (unless they are closely connected and short).

"MUST", paragraph 2, nit:
> tes are also considered trusted. Therefore it is not required to validate th
>                                  ^^^^^^^^^
Did you forget a comma after a conjunctive/linking adverb?

Uncited references: [RFC6793].