[pim] Mohamed Boucadair's Discuss on draft-ietf-pim-updt-ipv 6-dyn-mcast-addr-grp-id-10: (with DISCUSS and COMMENT)

Mohamed Boucadair has entered the following ballot position for
draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-10: 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-updt-ipv6-dyn-mcast-addr-grp-id/



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

Hi Nate, Dino, and Mike,

Thank you for the effort put into this document.

Thank you to Dhruv Dhody for the OPSDIR review and for the authors for engaging
and addressing the review.

Please find below some points for DISCUSSion:

# Be explicit about the update to 3307

Can we please indicate what is updated in 3307 and how one should interpret
this?

For example, can we say that we update Section 4.3 of 3307 as follows

OLD:
Dynamic IPv6 multicast addresses can be allocated by an allocation server or by
an end-host.

NEW:
Dynamic IPv6 multicast addresses can be allocated by an allocation server, an
end-host, or coordinated via a global registry (e.g., IANA-maintained registry).

# De we need a range for experimentations?

CURRENT:
    +-----------------------+-----------------+-----------------------+
    | 0xFE000000-0xFEFFFFFF | Private Use     | [This document]       |
    +-----------------------+-----------------+-----------------------+

As SSM is the recommended inter-domain case (and putting aside real deployment
cases): shouldn’t there be a range for experimentation? Such use doesn’t fall
under private use.

# Operational Impact and Backward Compatibility

CURRENT:
   This reduces the range previously available for MADCAP, while still
   providing a sizable allocation.

A key point missing in the spec is the backward compatibility of the changes.

Please add a discussion to a NEW Operational Considerations Section whether
this is an issue or not.

More generally, I’d hope we can have a discussion recorded here about what are
the implications of this changes, discuss if there is anything that is broken
or all is OK (if so, say it explicitly there).

The use of the group ids is not impacted. Maybe indicate how the new mode will
work/expected to work.

# IANA Actions

## Clarity

CURRENT:
   The "Standards Action" registration policy is required to update the
   registry.

I guess you meant only 0x90000000-0xEFFFFFFF range, not all any entry in the
table. Please check.

## Please s/MUST/must in the following per the guidance in
https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/
(Inappropriate Uses of Key Words ).

CURRENT:
       Values MUST be
       within the range for dynamic multicast address allocation
       mechanisms specified in [RFC3307]: 0x80000000 to 0xFFFFFFFF.

## RFC3307 as an additional reference to the new registry

Rather than having the text above under the range value, I think that this is
better if this is placed as a note in the registry itself + add 3307 as an
additional reference to the registry.

# Normative specification

CURRENT:
7.2.  Informative References

   [RFC2730]  Hanna, S., Patel, B., and M. Shah, "Multicast Address
              Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
              DOI 10.17487/RFC2730, December 1999,
              <https://www.rfc-editor.org/info/rfc2730>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
              <https://www.rfc-editor.org/info/rfc4607>.

## 2730 is normative IMO to assess the impact of the change on MADCAP.

## 4291 is needed for Solicited-Node multicast

## 4607: I’m less sure about this one, but this is the only reference we have
here for SSM. A normative reference for SSM is needed, otherwise.


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

# General: Correct Registry Name

Please update “IPv6 Multicast Address Space Registry” registry to “IPv6
Multicast Address Space” to use the exact name as maintained by IANA:
https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml

# Abstract

## Add title of RFC cited in the abstract so that we have a self-contained
abstract per the following guidance:

   An Abstract is not a substitute for an Introduction; the RFC should
   be self-contained as if there were no Abstract.  Similarly, the
   Abstract should be complete in itself.  Given that the Abstract will
   appear independently in announcements and indices, uncommon
   abbreviations should be expanded, and mentions of other RFCs within
   the Abstract should include both an RFC number and either the full or
   short title.

## s/suggests/defines

# IPv6 Multicast Address Architecture

## I would add a pointer to the multicast address architecture (RFC7371), as
that with 4291 are where to look for these matters. This would help set a
context for where “global id” intervenes in an IPv6 multicast address.

## Also, I suggest we add a mention that this document adheres to that
architecture

# Section 2

## No network-wide coordination

CURRENT:
   This reduces
   the need for coordinated dynamic assignment of G because multiple
   distinct hosts could use the same value for G and traffic would still
   be directed to the node that requested the stream.

Maybe add a pointer as well to the rfc8815#section-3.2.2 (BCP 229) as it
discusses that specific point. This would back this statement.

## SSM Deployment

CURRENT:
   However, SSM is not universally supported ([RFC4607], Section 6 lists
   one example).

I would refer to rfc8815#section-3.1 as it is more recent than 4607 and reflect
more recent deployment status.

# nits

## Abstract

OLD: allocations with a new registry in

NEW: allocations with a new IANA registry in

## Introduction

OLD: Only one server allocation protocol has been defined so far

NEW:    Only one server allocation protocol has been defined at the time of
writing

## IANA

OLD: IANA should create

NEW: This document requests IANA to create

Please let me know if any clarification is needed.

Cheers,
Med



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