[pim] Gorry Fairhurst's Discuss on draft-ietf-pim-zeroconf-m cast-addr-alloc-ps-09: (with DISCUSS and COMMENT)

Gorry Fairhurst has entered the following ballot position for
draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-09: 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:
----------------------------------------------------------------------

(1) The documents says it defines requirements.
I saw in the abstract this statement:
"The document presents explicit requirements covering discovery", but yet from
a standards perspective it does not - there are no formal requirements based on
RFC-2119 keywords derived. That may well be suitable for an Informational
document, and I expect the declaration of keywords can also be removed, and
this sentence could be rewritten as guidance for future work rather than
requirements?

- I see new text, and plan to re-review the RFC-2119 usage.

... Thank you, I think the new text resolves my other DISCUSS positions.


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

Thank you Joe Touch for his TSV-ART review, I'd like to pick-up on the issues
discussed there, so include them here:

(i) It also appears that the limited number of (host) hardware address filters
has been overlooked; i.e., if a device is capable of filtering only 4 multicast
addresses in hardware, the device would more efficiently support 7 addresses if
at least 3 DID collide, rather than ensuring that none collide.  When no
addresses collide and the number of filters is exceeded, the network interface
is driven into promiscuous mode that requires software filtering – i.e., it
completely undermines the goal of this doc.

(ii) The protocol requirements need some refinement. Resistance to failure is
NOT the same as robustness to a single point of failure; the tag phrase and the
definition need to be adjusted to align. Item 3 is “multicast self-assignment
protocol coexistence”, i.e., this isn’t about interoperation with other
protocols in general. Item 7 (collision detection and resolution) is not a
requirement; it is an approach to satisfying other requirements, such as 1, 2,
and 5. It would help if the tag phrases were similar (they seem to be phrases
defining properties, except for #6, which should be “supports host-level
multiplexing” – check this throughout for all lists).

(iii) The Note needs revision; the collisions arise after *rejoining
disconnected networks caused by* a temporary network partition. I.e., it is the
rejoining that causes the problem, not the partitioning. The second list should
describe goals of a design; it seems odd to include “cross-platform
availability”, as this seems to conflate deployment with OS capabilities; it is
difficult to appreciate what OS properties could ever interfere with these
mechanisms. An example would help as would rephrasing this as “OS independence”.

... Please see additional comments in the review that may also be helpful.



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