[MBONED] False positive idnit in draft-ietf-mboned-driad-amt-discovery?

["Holland, Jake" <[e-mail]>]

Hi Mboned,

I wanted to ask for your expert opinions on one of the warnings that
idnits reports in draft-ietf-mboned-driad-amt-discovery.  I think
it's a false positive, but I wanted to check if wg consensus agrees
with me here regarding the use of 232.x vs. 233.252.0.x:

In the draft, I'm using 232.252.0.2, which is not the MCAST-TEST-NET
space of 233.252.0.0/24, which is causing a warning.

From:
https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-mboned-driad-amt-discovery-08.txt&verbose=true

  /tmp/draft-ietf-mboned-driad-amt-discovery-08.txt(409): Found possible IPv4
    address '232.252.0.2' in position 24; this doesn't match the suggested
    documentation address ranges specified in RFC 6890 (or successor): blocks
    192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/24
    (TEST-NET-3); or the 233.252.0.0/24 (MCAST-TEST-NET) example multicast
    address range specified in RFC 5771.

  == There are 1 instance of lines with multicast IPv4 addresses in the
     document.  If these are generic example addresses, they should be changed
     to use the 233.252.0.x range defined in RFC 5771


However, I think it’s better here to use the designated SSM space, because
this is specifically a SSM group, and the S that’s associated is one from
one of the proper example test nets.

Section 8.1 of RFC 5771 mentions that there's deliberately no IANA
assignment policy for 232.x (leaving aside the reserved 232.0.0.x/24
from section 9 of RFC 4607):

https://tools.ietf.org/html/rfc5771#section-8.1
   Because the SSM model essentially makes the entire multicast address
   space local to the host, no IANA assignment policy is required.
   Note, however, that while no additional IANA assignment is required,
   addresses in the Source-Specific Multicast Block are explicitly for
   use by SSM and MUST NOT be used for other purposes.

In this case, I think using an example SSM group in a (S,G) that uses
one of the recommended example networks for the S is already a proper
example.

I think the problem with using the TEST-MCAST-NET block is that GLOP
addresses in 233 are globally scoped and statically assigned, so they
wouldn’t fit inside the default ssm space for things like configuring
RPF for PIM, so you might actually get different behavior out of the
network if you tried to use them without special config to support them.

So my opinion is it’s better to use 232.x in this case.  I'm not sure
one way or the other whether it perfectly matches the letter of RFC 6890,
but I think it's a better match for the spirit, as I understand it.

I'd be very happy to take advice from the WG or the IESG if anyone thinks
it's better to use the suggested 233.252.0.x destination instead.  I'm
soliciting opinions on the point, since it's relatively likely to come up
in review, since idnits flags it.

Cheers,
Jake


PS:
there is another warning that I think is more obviously a false positive.

You may of course comment if you like, but I'm not asking about this one,
I just wanted to mention it also to head off some of the confusion:

  /tmp/draft-ietf-mboned-driad-amt-discovery-08.txt(374): Found possible IPv4
    address '15.100.51.198' in position 46; this doesn't match the suggested
    documentation address ranges specified in RFC 6890 (or successor): blocks
    192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/24
    (TEST-NET-3); or the 233.252.0.0/24 (MCAST-TEST-NET) example multicast
    address range specified in RFC 5771.

  == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses
     in the document.  If these are example addresses, they should be changed.

'15.100.51.198' appears in 3 places, but each of those places is actually part
of the reverse-ip DNS zone for 198.51.100.15: 15.100.51.198.in-addr.arpa.  So
this is a false positive because it uses one of the RFC 6890 test net addresses,
but it’s properly reversed to indicate the corresponding DNS zone.