Hi Erik, 

Thanks  for your review. I’ve addressed your comments in the  -17 version.

> On Jan 2, 2024, at 9:05 PM, Erik Kline via Datatracker <[email protected]> 
> wrote:
> 
> Erik Kline has entered the following ballot position for
> draft-ietf-rtgwg-vrrp-rfc5798bis-16: 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/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-vrrp-rfc5798bis/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> # Internet AD comments for draft-ietf-rtgwg-vrrp-rfc5798bis-16
> CC @ekline
> 
> * comment syntax:
>  - https://github.com/mnot/ietf-comments/blob/main/format.md
> 
> * "Handling Ballot Positions":
>  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> 
> * Thanks to Dave Thaler for the INT-DIR review.
> 
> ## Comments
> 
> ### S5.1.2.2, S8.2.4
> 
> * Super-nit-y, but RFC 5952 S4.3 indicates lowercase (ff02:...).

Fixed. 

> 
> ### S6.4.3
> 
> * "MUST respond to ND Neighbor Solicitation message"
> 
>  I think it might be helpful to reiterate here that the (R)outer Flag MUST
>  be set in these messages (similar to the text in S6.4.1).

Added. 

> 
> ## Nits
> 
> ### S1.4
> 
> * "will normally take more than 10 seconds to learn the default
>   routers on a LAN"
> 
>  I found this wording to be misleading.  Hosts regularly learn default
>  routers as soon as they join the network.  I think this text might actually
>  mean something more like: "to learn *about a change in* the default routers
>  on a LAN" and/or (possibly) "to learn *all* the default routers on a LAN".
> 
>  I see that 5798 had somewhat similarly worded text, so no strong feelings
>  about changing this; just for your consideration.

Actually I softened this once based on feedback. It used to say 38 seconds. 
I’ve softened
the statement again by replacing “will normally” with “can”. 

> 
> ### S5.1.1.3, S5.1.2.3, S7.1, S9
> 
> * Up to you, but RFC 5082 might be cite-able here, if it helps anything.

Added. Except in section 7.1. 

> 
> ### S5.2.5
> 
> * "is ignored" -> "MUST be ignored", in order to use standards terminology?

Changed.

> 
> ### S6.4.3
> 
> * "the primary IPvX Address of the sender is greater than the local primary
>   IPvX Address"
> 
>  I assume the comparison function implied here means "when IPvX addresses
>  are treated as network-byte order unsigned integers"?

Yes. I’ve clarified (of course, there are many protocol documents where this is
implied). 


> 
> ### S8.1.1
> 
> * Super nit-y, but you might consider:
> 
>  "running between a group of routers" ->
>  "running among a group of routers"

I agree - this is clearer. 


> 
> ### S8.3.2
> 
> * "Skew_Time is inversely proportional to the priority"
> 
>  Strictly speaking I think this isn't quite true (given the formula in
>  S6.1, it's linear but with a negative coefficient?).  But it's been a long,
>  long time since I've had any proper maths course, so maybe ignore me.
> 
>  "Skew_Time decreases with increasing priority", perhaps.  Or
>  just leave it as is, since the figurative meaning is correct.

You are correct. It would certainly be incorrect to use the mathematical symbol 
for inversely proportional. 


> 
> ### S9
> 
> * If it helps, perhaps drop a reference to RFC 9099 S2.3, for some IPv6
>  link-layer security considerations discussion.

Added. Hopefully, it is ok to say “RECOMMENDED” for guidance in an 
informational document. Coincidently, I did the
Routing Directorate review on this document. Unfortunately, this adds an IDNIT 
warning for the acute accents on Eric. 

Thanks,
Acee


> 
> 
> 

_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

Reply via email to