[pim] Éric Vyncke's Discuss on draft-ietf-pim-zeroconf- mcast-addr-alloc-ps-08: (with DISCUSS and COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-08: Discuss

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-pim-zeroconf-mcast-addr-alloc-ps/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for
draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-08 CC @evyncke

Thank you for the work put into this document, solutions based on this set of
requirements would be useful indeed.

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

Special thanks to Stig Venaas for the shepherd's detailed write-up including
the WG consensus and the justification of the intended status.

Other thanks to Benson Muite, the Internet directorate reviewer (at my
request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-pim-zeroconf-mcast-addr-alloc-ps-07-intdir-telechat-muite-2025-11-11/
(and I have read Nate's reply -- even if I would prefer, like Benton, use cases
beyond marine).

I hope that this review helps to improve the document,

Regards,

-éric

## DISCUSS (blocking)

As noted in
https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
a DISCUSS ballot is a request to have a discussion on the points below; I
really think that the document would be improved with a change here, but can be
convinced otherwise.

### Limited to 48-bit MAC addresses ?

It seems that this document only targets layer-2 with 48-bit MAC addresses,
ignored other data link (e.g., IEEE 802.15.4 with its 16 or 64-bit MAC
addresses, see RFC 4944).

The text must either be clear about this limitation (including in title &
abstract) or be modified to also include 16- and 64- bit MAC addresses.

### Section 3

`Support for Unprivileged Applications`, this is not really something that it
within IETF remit nor clear. Please rephrase.

### Section 4

`A solution to these issues is presented in
[I-D.ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id].` this sentence has no logical
place in a *requirements* document. Please remove it.


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


## COMMENTS (non-blocking)

### Section 2

Why limiting to Ethernet (i.e., not considering Wi-Fi) in `many Ethernet
interfaces allow filtering` ?

Unsure whether the low-cost switches limitations should be a basis for a
requirements at the IETF. Consider removing the paragraph starting with `Third,
the internal design of some switches`. Especially, in the marine use case where
the overal cost of the ship is much bigger than a normal switch ;-)

### Section 3

If this I-D will be the basis for solution protocols, then I *STRONGLY* advise
to number the requirements for easier reference by other documents, e.g., REQ-n
for the "shall" or CONS-n for the "should"

### Section 4

s/section 2 of *this* RFC /section 2 of RFC *3307*/ let's be clear ;-)

More important, why not specifying a requirement for this consideration ?

### Section 5

In `the protocol should try` it is (somehow) unclear what is 'the protocol' and
also why not using BCP14 "SHOULD" rather "should" to align with section 3 ?

Finally, why not specifying a requirement for this consideration ?

### Section 7

Like Paul's IESG and Joe's secdir review, this section should rather list
security requirement(s) and probably use BCP14 terms.



_______________________________________________
pim mailing list -- [email protected]
To unsubscribe send an email to [email protected]