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

From: "Holland, Jake" <[email-masked]>
Date: Sun, 1 Sep 2019 19:42:43 +0000

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.

---

From: Leonard Giuliano <[email-masked]>
Date: Tue, 3 Sep 2019 12:58:18 -0700

Jake- If it's supposed to be an SSM group for the example, you definitely 
want to pick an address in 232/8.

>From RFC 6676, I think you are in good shape:

2.  IPv4 Multicast Documentation Addresses

   For Any-Source Multicast (ASM), the IPv4 multicast addresses
   allocated for documentation purposes are 233.252.0.0 - 233.252.0.255
   (233.252.0.0/24).

   For Source-Specific Multicast (SSM), it is less important which
   multicast addresses are used, since a host/application joins a
   channel identified by both source and group.  Any source addresses
   used in SSM examples should be unicast addresses reserved for
   documentation purposes.  There are three unicast address ranges
   provided for documentation use in [RFC5737].  The ranges are
   192.0.2.0/24, 198.51.100.0/24 and 203.0.113.0/24.

   Sometimes one wants to give examples where a specific type of address
   is desired.  For example, for text about multicast scoping, one might
   want the examples to use addresses that are to be used for
   administrative scoping.  See below for guidance on how to construct
   specific types of example addresses.

On Sun, 1 Sep 2019, Holland, Jake wrote:

| 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://urldefense.proofpoint.com/v2/url?u=https-3A__www6.ietf.org_tools_idnits-3Furl-3Dhttps-3A__www.ietf.org_archive_id_draft-2Dietf-2Dmboned-2Ddriad-2Damt-2Ddiscovery-2D08.txt-26verbose-3Dtrue&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=xsk5PcsYEt_KVg7TP9YF66RP-SQnean6GQq5Ri7mmgo&s=DZ-tcZiA71UT3PNABbEuLfQ1IBPYbEpbEbVMgepu5Sw&e= 
| 
|   /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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5771-23section-2D8.1&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=xsk5PcsYEt_KVg7TP9YF66RP-SQnean6GQq5Ri7mmgo&s=dDJAgFTDtnN2TskyxRHWgEhdxo0vbsalClLtM-o6zfc&e= 
|    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.
| 
| 
| _______________________________________________
| MBONED mailing list
| [email-masked]
| https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mboned&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=xsk5PcsYEt_KVg7TP9YF66RP-SQnean6GQq5Ri7mmgo&s=F4jgoi0FYp9JopiVMqpv2zQ3BU5rLMwDPh-I8qzgltI&e= 
|