Subject: [babel] Éric Vyncke's No Objection on draft-ietf-babel-v4viav6-07: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Wed, 16 Feb 2022 07:53:56 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-babel-v4viav6-07: 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/blog/handling-iesg-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-babel-v4viav6/

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

Thank you for the work put into this document. The re-use of RFC 7600 (4rd)
192.0.0.8 dummy address is consistent with other practices, e.g., the
IPv4-mapped IPv6 addresses for 6PE.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education).

Special thanks to Donald Eastlake for the shepherd's write-up including the
section about the WG consensus around the IPv4 dummy address.

Thanks also to Bernie Volz for the INT directorate review dated 27th of
January. Some nits were detected and the author should address them as if they
were my own COMMENTs. See
<https://datatracker.ietf.org/doc/review-ietf-babel-v4viav6-07-intdir-lc-volz-2022-01-27/>.

I hope that this helps to improve the document,

Regards,

-éric
## Section 1
Is there a reason why IPv4 link-local addresses, 169.254/16 RFC 3927, are not
mentioned in this section ? They could easily be used as next IPv4 hop as the
fe80::1234:5678 in the example.

## Section 2.2

"If no IPv6 next hop exists, then the Update MUST be silently ignored.", would
this behaviour make operations/debugging more complex ?

## Section 8

Should there be a "contributor" section for Théophile Bastian ?

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 16 Feb 2022 17:58:42 +0100

> January. Some nits were detected and the author should address them

Of course.  I'll make a new revision of the draft integrating all nits
to date when I next have some quiet time.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 24 Feb 2022 18:34:01 +0100

Thanks, Éric.

> fe80::1234:5678 in the example.

Yes.  IPv6 link-locals have all the desired properties for a next-hop:
they almost always exist (at least after DaD), they are stable, they are
unique with very high probability.  IPv4 link-locals, on the other hand,
are typically assigned by a potentially fragile userspace daemon, they
tend to come and go as DHCP triggers, and they are non-unique with
significant probability.

In short, while they are useful for their intended usage (locating your
closest printer), I don't feel they are robust enough to be used at layer 3.

> this behaviour make operations/debugging more complex ?

Removed "silently", which aligns this document with Section 4.6.9 of RFC
8966.

> Should there be a "contributor" section for Théophile Bastian ?

No objection if that's the way it's usually done, although I feel that the
current acknowledgments gives suitable credit.

-- Juliusz