comments on draft-ietf-6man-multicast-addr-arch-update-02

[神明達哉 <[e-mail]>]

As promised in the Vancouver meeting, I reviewed the draft.  Overall,
it looks good to me.  I have a few minor comments:

- Allowing FFF0::/12 to be considered an embedded RP address seems to
  me a semantics change, not just a clarification (as hinted in the
  introduction), since RFC 3956 clearly states (and also as cited in
  the draft itself):

   the encoding and the
   protocol mode used when the two high-order bits in "flgs" are set to
   11 ("FFF0::/12") is intentionally unspecified until such time that
   the highest-order bit is defined.

  So does this mean "such time" has come?  I guess there was a
  background discussion that I didn't follow and led to this change,
  so I wouldn't oppose to the update per se.  But the rationale isn't
  really clear from the updated text, and I think it should be
  clarified.

- Aside from the previous point, the updated text is generally quite
  confusing to me:

      R = 1 indicates a multicast address that embeds the address of the RP.
      P MUST be set to 1, and consequently T MUST be set to 1, according
      to [RFC3306], as this is a special case of
      unicast-prefix based addresses. This implies that for instance prefixes
      ff70::/12 and fff0::/12 are embedded RP prefixes, but all multicast
      addresses with the R-bit set to 1 MUST be treated as Embedded RP
      addresses. The behavior is unspecified if P or T is not set to 1. When the
      R-bit is set, the last 4 bits of the previously reserved field are
      interpreted as embedding the RP interface ID, as specified in this memo.

  As explained in the first sentence, for any embedded-RP addresses
  both P and T must be 1.  As a logical consequence, an address with P
  or T being 0 cannot be an embedded-RP addresses, right?  Yet the
  text states "all multicast addresses with the R-bit set to 1 MUST be
  treated as Embedded RP addresses".  Maybe the "behavior is
  unspecified if P or T is not set to 1" part in the subsequent
  sentence tries to address the point, but it's still confusing to me
  - specifically what does "MUST be treated as Embedded RP addresses"
  mean, then?  I think some more clarification is necessary here.

- In Section 4.1, I suspect the "NEW" format needs the new "flgs"
  bits:

   NEW:

         |   8    |  4 |  4 |   8    |    8   |       64       |    32    |
         +--------+----+----+--------+--------+----------------+----------+
         |11111111|flgs|scop|reserved|  plen  | network prefix | group ID |
         +--------+----+----+--------+--------+----------------+----------+
                             ^^^^ <= should be "flgs"

  And, with this change, the following part will become ambiguous:

                                      +-+-+-+-+
      flgs is a set of 4 flags:       |X|Y|P|T|
                                      +-+-+-+-+

  Since there are now 2 "flgs" fields.  The same comment applies to
  the NEW formats shown in Section 4.2.

- Also in the NEW format of Section 4.1, I'm not sure if [ADDRARCH] is
  an appropriate reference, e.g., in:

            o  P = 0 indicates a multicast address that is not assigned
               based on the network prefix.  This indicates a multicast
               address as defined in [ADDRARCH].

  Since there's no such reference in this document.  For the OLD text
  it's probably okay as it should be a verbatim copy of the original
  text, but I'm not sure if it should apply to the new text.

- (A very minor point) Also in the NEW format of Section 4.1, why
  lower-cased letters are now used for the addresses?

      If the flag bits are set to 0011, these settings create an SSM
      range of ff3x::/32 (where 'x' is any valid scope value).  The

  The policy isn't consistent either with the original RFC 3306 or
  with other parts of the draft.

- In the NEW format of Section 4.2, this sentence may need to be
  revisited:

      In this case, the last 4
      bits of the previously reserved field are interpreted as embedding
      the RP interface ID, as specified in this memo.

  in that what "the previously reserved field" means is not really
  clear as this document now also is revising RFC 3306.  To be very
  clear, for example, I'd rephrase it as:

      In this case, the last 4
      bits of the field that were reserved in [RFC3306] are
      interpreted as embedding the RP interface ID, as specified in
      this memo.

--
JINMEI, Tatuya