[pim] Mahesh Jethanandani's No Objection on draft-ietf-pim-u pdt-ipv6-dyn-mcast-addr-grp-id-12: (with COMMENT)

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



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

"Abstract", paragraph 0
>    This document describes limitations of the existing range of dynamic
>    IPv6 multicast addresses specified in RFC3307.  It recommends
>    replacing these allocations with a new IANA registry in the IPv6
>    Multicast Address Space registry group.  The document also defines
>    initial contents of the new registry: a reduced allocation for MADCAP
>    (RFC2730), a range for SSM, a Private Use range, a range for
>    Experimental Use, and Solicited-Node multicast addresses (which were
>    not previously noted in RFC3307, Allocation Guidelines for IPv6
>    Multicast Addresses).

Generally, the Abstract clearly states if the document is updating or
obsoleting another document. This one mentions the document, but not that it is
being updated. It is only later in the Introduction that you learn that RFC3307
is being updated.

I also agree with Gorry that for a PS document, the use of words such as
"recommends" is a poor choice.

Section 1, paragraph 2
>    Only one server allocation protocol has been defined at the time of
>    writing (see [RFC2730]), but
>    [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps] advocates developing a
>    decentralized, zero-configuration host allocation protocol.  This
>    document updates Section 4.3 of [RFC3307] to allow multiple dynamic
>    allocation protocols to coexist on the same network, and so that
>    dynamic IPv6 multicast group ID ranges better align with current
>    practices for protocol number assignment.

I find the last sentence of the paragraph to be confusing. Which "current
practices" are being referred to? Can the sentence be simplified to say
something like: "... on the same network, and to enable that the dynamic IPv6
multicast group IP ranges suggested in this document should be followed."

Section 2, paragraph 2
>    However, SSM is not universally supported (see [RFC4607], Section 6
>    and [RFC8815], Section 3.1).  This document defines a range of
>    dynamic IPv6 multicast group IDs for use in environments that do
>    support SSM.

This section seems to be justifying why a range of addresses should be assigned
for SSM, till it does not, based on the first sentence of the above paragraph.
If SSM is not widely deployed, why not return the range to unassinged pool and
maybe later, when the SSM usage picks up, a range could be allocated for it.

Section 4, paragraph 0
>    This document reduces the range of group ID values available for
>    MADCAP ([RFC2730]).  At the time of writing, there is only one known
>    implementation of MADCAP, and there are no known large-scale
>    deployments.  Any implementations of MADCAP (known or otherwise)
>    should be updated to reflect the new group ID range set forth in
>    Table 2.  Any existing deployments of MADCAP should either use an
>    updated implementation or operate in an environment without other
>    IPv6 multicast address allocation protocols.

I will note that the Shepherd report, on the question of any existing
implementation says "Nothing to implement here". While I agree that it is not
protocol implementation in a traditional sense of the word, nevertheless, this
document does make a note of how existing implementations could be affected by
the new allocation scheme. The Shepherd report should be updated to reflect
that.

This document does not use RFC2119 keywords, but contains the RFC8174
boilerplate.

The IANA review of this document seems to not have concluded yet.

No reference entries found for these items, which were mentioned in the text:
[avoiding].

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1, paragraph 2
>    This document adheres to the IPv multicast address architecture
>    outlined in [RFC4291], [RFC3307], [RFC7371], et al.

What is "IPv"?

Reference [RFC2908] to RFC2908, which was obsoleted by RFC6308 (this may be on
purpose).

Document references draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-11, but -13 is
the latest available revision.

Found non-HTTP URLs in the document:

 * lispers.net

These URLs in the document did not return content:

 * lispers.net



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