[MBONED] draft-ietf-mboned-rfc3171bis-04

[Alfred Hönes <[e-mail]>]

Hello,
following up from draft-cotton-v4mcast-guidelines to
       draft-ietf-mboned-rfc3171bis-04,
I would like to again submit a few comments.


(1)  Front matter

See item (3) below!


(2)  Abstract

It's only a matter of 'marketing' :

I suggest to shuffle the words in order to give the _constructive_
part first, then the _destructive" one (obsoletes).

See also (3) below.


(3)  Section 1, second paragraph.

Sorry, I do not understand the rationale and how that shall work:

   This document is a revision of RFC 3171 [RFC3171], which it
|  obsoletes.  It should retain RFC 3171's status as BCP 51.  It also
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|  obsoletes RFC 3138 [RFC3138]."
                                ^

The draft indeed is a full functional replacement for RFC 3171 and
it covers all topics addressed there.  But if the document replaces
(Obsoletes) RFC 3171, RFC 3171 will be deleted from the rfcxx00 file
and the BCP index, and the new RFC should become the new BCP 51,
according to the rules stated in the procedural RFCs and the latest
IAB drafts of the RFC Series and the RFC Editor.

These rules explicitely state that, notwithstanding historiocal
procedural flaws that (admittedly) have occured, BCP numbers are
functional and stable in the same way as STD numbers.

Therefore, I strongly recommend to elide the second sentence above.
Furthermore, the unmatched trailing double-quote should be removed.

Hence, the above paragraph should be modified to say:

   This document is a revision of RFC 3171 [RFC3171], which it
|  obsoletes.  It also obsoletes RFC 3138 [RFC3138].

To carry this information over to the RFC metadata, the draft
front matter should be amended by the clause:

" Obsoletes: 3138, 3171 (if approved)"

For completeness, the Abstract should mention *both* obsolescenses.


(4)  Section 1, third paragraph, and Section 1.2

The 3rd paragraph in Section 1 belongs into Section 1.2.

The first sentence in it should be updated to accommodate for the
new BCP 26, RFC 5226:

 - update ref. tag:     [RFC2434]        --" [RFC5226]

 - update terminology:  "IETF Consensus" --> "IETF Review"

Further, the second sentence is a duplicate of the existing text in
Section 1.2 and should be deleted.

In the second paragraph of the present Section 1.2, 'is defined as'
seems to be slightly improper; I suggest to say "designates" instead.


(5)  Section 3 ff. -- complete CIDR notation

My earlier comments on the rules set forth for CIDR notation
still apply.  I have attached below the still relevant excerpts
of that message (with a dew typos corrected) -- see item (0)(a)
there.

I really would like to see the IETF eat its own doggy-food!
Otherwise BCPs are going to loose their credibility.


(6)  Section 3

My earlier comments on the registry content still apply.
See item (1) and its sub-items in the attached message excerpts.

To avoid confusion and further reference to legacy flaws,
I strongly recommend to update and streamline the registry
file *before* publication of this memo as an RFC (preferably
much sooner!), and include that version in section 3.


(7)  Section 8 -- typos

Yhe last sentence of Setcion 8 should be corrected:

|  Note that this block as initially assigned to the VMTP transient
         vvvvvv        ^^^
|  groups IANA [IANA].
---
|  Note that this block was initially assigned to the VMTP transient
         v             ^^^^
|  groups [IANA].


(8)  Section 9 -- spurious word replication

One of the flaws originally reported has not been corrected.
Please fix:   s/ of of / of /  .


(9)  Section 9.2 -- textual improvement

The current text might still cause confusion between the two
namespaces under consideration.

Therefore, I suggest to shuffle the wording, in order to group
the values shown close to the terms referring to them, and add
the missing AS numbers, for completeness:

   [RFC3138] delegated assignment of the GLOP sub-block mapped by the
   [RFC1930] private AS space (233.252.0.0 - 233.255.255.255) to the
   RIRs.  [...]
---
|  [RFC3138] delegated to the RIRs the assignment of the GLOP sub-block
|  (233.252.0.0 - 233.255.255.255) mapped by the private AS space
|  (64512-65534) and the IANA reserved ASN 65535 [RFC1930].  [...]

Note: Historical records indicate that the distinction between
      ASN 65535 and the private use ASN range 64512-65534 predates
      RFC 1930 and has never been changed in the IANA registry.
      Some sources support the opinion that RFC 1930 primarily
      wanted to indicate that the whole AS range 64512-65535 is
      reserved and "not to be advertised on the global Internet",
      and therefore did not make the distinction.


(10)  Section 12.1, second paragraph

The previous draft version has been discussed in item (6) of the
old review quoted below.

In the meantime, the entry for the ST Multicast Groups block has
been restored in the IANA registry, and a ref. to RFC 1190 has
been added to the draft text:

|  The IANA should also review assignments in the AD-HOC, DIS Transient
|  Groups, and ST Multicast Groups [RFC1190] blocks and reclaim those
   addresses that are not in use on the global Internet (i.e, those
   applications which can use SSM, GLOP, or Administratively Scoped
   addressing, or are not globally routed).

Still, the term "DIS Transient Groups" is undefined, and no useful
reference has been given.  To give a specific indication to the
questionable (?) nature of this block, I suggest to enclose that
term in quotes.


(11)  Section 17.2

Please delete the outdated entry  [RFC2434]  and add -- according to
collation oreder -- at the end of the section a new entry  [RFC5226] .


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+


------------ begin excerpts of original message ------------

> From: Alfred Hönes <[e-mail]>
> To: [e-mail], [e-mail]
> Message-Id: <[e-mail]>
> Date: Mon, 11 Feb 2008 00:32:57 +0100 (MEZ)
> Subject: draft-cotton-v4mcast-guidelines-00

Hello,
after studying the Internet-Draft authored/edited by you,
          draft-cotton-v4mcast-guidelines-00,
I'd like to submit a few comments, mostly addressing textual
flaws I found in that memo.

...

(0)  General

(a)
The basic "strategic" document for CIDR notation now is BCP 122,
RFC 4632, and that document clearly states (in section 3.1, at
the bottom of page 5):
                                                           vvvvvvv
|          [...]  In CIDR notation, a prefix is shown as a 4-octet
   quantity, just like a traditional IPv4 address or network number,
   followed by the "/" (slash) character, followed by a decimal value
   between 0 and 32 that describes the number of significant bits.

As your draft also is intended for BCP, it should conform to
established terminology and notation and not use "popular" yet
sluggish shorthand notation for prefixes.

Therefore, I strongly recommend to expand all prefixes in the
draft to the above mentioned full 4-octed ("dotted quad") form.

(b) ...  [[ signed off in current draft ]]


(1)  Section 3

There are multiple issues with the table in section 3:

(a)
Without any explanation, the third column of that table holds
a cornupia of different entries:  abbreviated prefix, decimal
count of addresses, or number of prefixes of specified length.
It is not clear whether there exists rationale for these entries,
beyond legacy.

(b)
I strongly suspect that the address in the second column of the
third line is wrong;
           224.0.2.0 - 224.0.255.0
should be:
           224.0.2.0 - 224.0.255.255
                                 ^^^
(This is a very old legacy issue with the registration file!)
Correspondingly, the lenght given must be increased by 255.

(c)
This table has (RFC) line width problems.
I therefore suggest considering to replace the first two columns
by a one-column, strict prefix notation of the assigned ranges,
and to give the size in the new second column.
Also, a table heading would perhaps add much to clarity.

(d)
The reader of this table most probably intuitively expects
that the table contain non-overlapping ranges together filling
up the available range for multicast addresses.

Yet there is a gap in the table, and the line for the EGLOP /
extended ad-hoc block breaks the non-overlapping assumption.
Taking this new assignment fixed, I suggest to make it visible
that this line is subordinate to the line above it, by making
use of indentation -- which will be much easier to apply in the
new structure I propose -- and to add lines for the missing
224.3.0.0/16 ... 224.251.0.0/16 ranges.

Let's try.
How about using this format (I have filled in the gaps
and also added a "Reference" column; see also (6) below!):


   Address Range         Size  Use                             Reference
   ---------------  ---------  ------------------------------- ---------
   224.0.0.0/24           256  Local Network Control Block     [IANA]

   224.0.1.0/24           256  Internetwork Control Block      [IANA]

   224.0.2.0/24   \     65024
       ...         )      =    AD-HOC Block                    [IANA]
   224.0.255.0/24 /  254 /24s

   224.1.0.0/16         65536  -reserved-
                               (ex ST-II Multicast Groups)     [RFC1190]

   224.2.0.0/16         65536  SDP/SAP Block                   [RFC2974]

   224.3.0.0/16   \  16318464
       ...         )      =    -reserved-
   224.251.0.0/16 /  249 /16s

   224.252.0.0/14      262144  -reserved-
                               (ex "DIS Transient Groups")

   225.0.0.0/8    \ 117440512
       ...         )      =    -reserved-
   231.0.0.0/8    /     7 /8s

   232.0.0.0/8       16777216  Source Specific Multicast Block [RFC4608]

   233.0.0.0/8       16515072  GLOP Block                      [RFC3180]

     233.252.0.0/14    262144  AD-HOC Block (ex eGLOP Block)   [IANA]

   234.0.0.0/8    \  83886080
       ...         )      =    -reserved-
   238.0.0.0/8    /     5 /8s

   239.0.0.0/8                 Administratively Scoped Block   [RFC2365]
                               (some subranges: -reserved-)

With the ref. [IANA] , I have tries to tag the blocks where
IANA currently performs assignments from.


...   [[ various nits signed off in current draft ]]


(6)  Section 12.1

The draft says:

   The IANA should also review assignments in the AD-HOC, DIS Transient
   Groups, and ST Multicast Groups blocks and reclaim ...

The terms, "DIS Transient Groups" and "ST Multicast Groups" are not
defined or used elsewhere in the document.
These terms should be explained.

Note:
The former term could be found in the registry w/o explanation;
the latter term has disappeared from the registry file; I found
an old archived version where 224.1.0.0/16 was labelled with
this term and [RFC1190].  Interestingly, [RFC1190] is listed as
an Informative Reference, but does not appear anywhere in the text.

I have (provisionally) added both terms as "ex" refs to the table
above, for the purpose of exposition.
When consensus is reached that these address spaces indeed shall be
reclaimed, it should be considered to join the 224.252.0.0/14 range
with the immediately preceding ranges, in the table.


(7)  Section 12.2  ...  [[ signed off in current draft ]

...


(8)  Section 17.2  ...  [[ mostly signed off in current draft ]]

...

A ref. to BCP 122, RFC 4632 should perhaps be added for CIDR prefix
notation.


Best regards,
  Alfred Hönes.

------------ end of original message ------------

_______________________________________________
MBONED mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mboned