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

From: Jouni Korhonen <[email-masked]>
Date: Mon, 10 Feb 2014 11:23:37 +0200

Sorry being a bit late but I had a read of this document. 

** Some nits:

s/[ADDRARCH]/[RFC4291]

** 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.

** 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.

** 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?

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.

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.

** 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.

- Jouni

---

From: <[email-masked]>
Date: Mon, 10 Feb 2014 14:37:14 +0100

Hi Jouni,

Thank you for the comments. 

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : Jouni Korhonen [mailto:[email-masked]]
>Envoyé : lundi 10 février 2014 10:24
>À : IPv6 IPv6 List; draft-ietf-6man-multicast-addr-arch-
>[email-masked]
>Objet : Comments on draft-ietf-6man-multicast-addr-arch-update-02
>
[Med] Will be fixed. Thanks.

>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.

>   NEW:
[Med] Agree. This point is also raised by Tatuya. Will be fixed. 

>** In all proposed updated address formats we seem to have the following:
[Med] We are considering using "Flag Fied 1" and "Flag Field 2".

>are wrong, since there are now two sets of "flgs" that sum up to eight
[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:
[Med] The current approach we are discussing with Stig is to use ff1 and ff2.

>give a try listing possible impacts & updates.
[Med] That text will be removed.

---

From: Stig Venaas <[email-masked]>
Date: Mon, 10 Feb 2014 10:24:53 -0800

Hi Jouni

> recon it might be awfully late for this, though.

I agree. I'm not sure what is the right thing to do here, I've also been
wondering if what you say would be better. I've been asking this
question several time, but I haven't really got much feedback.

I wonder if it might be worth checking with the IESG or others to see
what the best way is. It would be a big task updating those documents
though. One way forward could be to publish this document soon, and then
work on bis versions of those documents that may also include other
improvements.

>     NEW:

You're right, will update this.

> ** In all proposed updated address formats we seem to have the following:

I'm thinking of maybe calling them flag field 1 and flag field 2 and
use the names ff1 and ff2 in the diagram. Thoughts on that?

> are wrong, since there are now two sets of "flgs" that sum up to eight flags.

So maybe say that flag field one contain 4 flags...

> Therefore I would propose for example the following format:

I prefer this latter one. What do you think of flag field 1 and
flag field 2 versus your proposal?
> give a try listing possible impacts & updates.

Oops. This was true at some point and I guess we overlooked this later.
I agree, it is pretty sloppy. I need to think a bit about this,

Thanks for your comments. I intend to submit a new version before
Friday.

Stig

---

From: Brian Haberman <[email-masked]>
Date: Mon, 10 Feb 2014 18:15:58 -0500

Stig,

> work on bis versions of those documents that may also include other

I will point out that I suggested doing errata or -bis documents several
times.  I don't those updates would be that involved.  There really is
only a need to clarify the definition of the flgs and possibly
highlighting the relationship between the specs.

Regards,
Brian