RE: Comments on draft-ietf-6man-multicast-addr-arch-update-02

[<[e-mail]>]

Hi Jouni,

Thank you for the comments. 

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : Jouni Korhonen [mailto:[e-mail]]
>Envoyé : lundi 10 février 2014 10:24
>À : IPv6 IPv6 List; draft-ietf-6man-multicast-addr-arch-
>[e-mail]
>Objet : Comments on draft-ietf-6man-multicast-addr-arch-update-02
>
>Sorry being a bit late but I had a read of this document.
>
>** Some nits:
>
>s/[ADDRARCH]/[RFC4291]
[Med] Will be fixed. Thanks.

>
>** While I agree this document is needed there is a general procedural
>issue I have. This I-D patches three other RFCs, which over the time
>may become an issue. I would rather see each document having their
>own bis and RFC4291 update being the master on all of these updates. I
>recon it might be awfully late for this, though.

[Med] The point was raised in the mailing list (http://www.ietf.org/mail-archive/web/ipv6/current/msg17811.html) and also during the f2f meeting (e.g., slide 4 of http://www.ietf.org/proceedings/88/slides/slides-88-6man-6.pdf). As no comment was raised during the meeting (http://www.ietf.org/proceedings/88/minutes/minutes-88-6man), we maintained the changes in the same document.

>
>** Section 4.1:
>
>   NEW:
>
>         |   8    |  4 |  4 |   8    |    8   |       64       |    32    |
>         +--------+----+----+--------+--------+----------------+----------+
>         |11111111|flgs|scop|reserved|  plen  | network prefix | group ID |
>         +--------+----+----+--------+--------+----------------+----------+
>                             ^^^^^^^^
>
>Shouldn't this also be align with other NEW formats? Others have a new set
>of "flgs" + "rsvd" here.
[Med] Agree. This point is also raised by Tatuya. Will be fixed. 

>
>** In all proposed updated address formats we seem to have the following:
>
>    |   8    |  4 |  4 |  4 |..
>    +--------+----+----+----+----+--------+----------------+----------+
>    |11111111|flgs|scop|flgs|..                                       |
>    +--------+----+----+----+----+--------+----------------+----------+
>              ^^^^^^^^^^^^^^
>
>I find this confusing having two distinct sets of "flgs". Why not
>concatenate
>that to one 12 bits field? Or at least name the latter "flgs" differently?
[Med] We are considering using "Flag Fied 1" and "Flag Field 2".

>
>Either way current statements like in Section 4.2
>
>                                         +-+-+-+-+
>         flgs is a set of four flags:    |X|R|P|T|
>                                         +-+-+-+-+
>
>are wrong, since there are now two sets of "flgs" that sum up to eight
>flags.
[Med] This will be clarified in the new version (i.e., this "flgs" will be renamed to "ff1"). Thanks. 


>
>
>Therefore I would propose for example the following format:
>
>    |   8    |      12      | ..
>    +--------+----+----+----+----+--------+----------------+----------+
>    |11111111|flgs_and_scop | ..                                      |
>    +--------+----+----+----+----+--------+----------------+----------+
>
>Then describe the "flgs_and_scop" as
>
>    11       7       3     0
>    +-+-+-+-+-+-+-+-+-+-+-+-+
>    |X|R|P|T| scope |r|r|r|r|
>    +-+-+-+-+-+-+-+-+-+-+-+-+
>
>where "rrrr" are for future assignment as additional flag bits.
>
>Or alternatively:
>
>    |   8    |  4 |  4 |  4 |..
>    +--------+----+----+----+----+--------+----------------+----------+
>    |11111111|flgs|scop|newf|..                                       |
>    +--------+----+----+----+----+--------+----------------+----------+
>
>where "newf" are for future assignment as additional flag bits.
[Med] The current approach we are discussing with Stig is to use ff1 and ff2.

>
>
>
>** Section 5 IANA Considerations:
>
>   This document may require IANA updates.  However, at this point it is
>   not clear exactly what these updates may be.
>
>I find this statement rather sloppy. At least the authors should
>give a try listing possible impacts & updates.
[Med] That text will be removed. 

>
>- Jouni