Subject: Comments on draft-ietf-6man-multicast-scopes-02

From: Jouni Korhonen <[email-masked]>
Date: Mon, 10 Feb 2014 12:41:17 +0200

Sorry for being late with my comments but here we go anyway.

I think this document is almost ready. Few comments/questions
though.

** In Section 3:

   NEW:

     o  The boundaries of zones of a scope are defined by the IPv6
        addressing architecture [RFC4291].

Ok.. this is confusing since it is *this* I-D that updates RFC4291
with a new Realm-scope aware boundary, thus RFC4291 would eventually
point back to this I-D. So while the above change is correct it
definitely is confusing.

Just like with draft-ietf-6man-multicast-addr-arch-update I see a
need for RFC4291bis, where Section 1 like enhancements would
belong to rather than stacking up I-Ds that patch things here and
there.  Again I recon it might be too late for this, though.

** Section 5

What would go under the other scopes than 3? Shouldn't we say at
least something about the possible future use of those? Will they
also list RFCs? 

** Section 7

I don't think it is sufficient just to refer to RFC4291 (almost non
existent) security considerations. For example there should be a
reference to RFC4007 which actually has text related to security
considerations of boundaries and scopes.

- JOuni

---

From: Ralph Droms <[email-masked]>
Date: Mon, 10 Feb 2014 11:18:15 -0500

> point back to this I-D. So while the above change is correct it

How about:

    o  The boundaries of zones of a scope are defined by the IPv6
       addressing architecture [RFC4291] and updated by this document.

> there.  Again I recon it might be too late for this, though.

In my opinion, it would be fine to start on an RFC4291bis now.  I would strongly object to holding up this document for that effort, as the definition of scop 3 is needed now for MPL.

> least something about the possible future use of those? Will they

RFC 4291 explicitly leaves the other scopes "(unassigned)".  It would be out of scope for this document to say more about those scopes than RFC 4291.

> considerations of boundaries and scopes.

Good point.  I suggest:

7.  Security Considerations

   This document has no security considerations beyond those in RFC 4007
   [RFC4007] and RFC 4291 [RFC4291].

- Ralph

> 
> - JOuni
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 10 Feb 2014 19:14:38 +0200

>       addressing architecture [RFC4291] and updated by this document.

Wfm.

> RFC 4291 explicitly leaves the other scopes "(unassigned)".  It would be out of scope for this document to say more about those scopes than RFC 4291.

Since this document establishes a new registry, we at least
need to define the guidelines on how future assignments are
to be made as per RFC5226.

>   [RFC4007] and RFC 4291 [RFC4291].

Wfm.

- JOuni

---

From: Ralph Droms <[email-masked]>
Date: Thu, 13 Feb 2014 14:07:06 -0500

I saw one comment posted during the WG last call on draft-ietf-6man-multicast-scopes-02.  Based on the discussion of that comment, I will make the following changes to the document and post a new revision before the cutoff on Monday.

Section 3:

OLD:

Section 7:

OLD:

   This document has no security considerations beyond those in RFC 4291
   [RFC4291].

NEW:

Section 5:

OLD:

   IANA is asked to establish a sub-registry titled "IPv6 Multicast
   Address Scopes" in the existing "Internet Protocol version 6 (IPv6)
   Multicast Address Allocations" registry.  The "IPv6 Multicast Address
   Scopes" is to be populated with the scope values given in section 1,
   with a note associated with scope 3 listing all RFCs that define
   Realm-Local scoping rules that use scope 3.

NEW:

   IANA is asked to establish a sub-registry titled "IPv6 Multicast
   Address Scopes" in the existing "Internet Protocol version 6 (IPv6)
   Multicast Address Allocations" registry.  The "IPv6 Multicast
   Address Scopes" is to be populated with the scope values given in
   section 1.  New definitions for scop values will be made with "IETF
   Review" policy.  The registry will have a note associated with
   scope 3 listing all RFCs that define Realm-Local scoping rules that
   use scope 3.

Section 1:

OLD:

   0  reserved

   1  Interface-Local scope

   2  Link-Local scope

   3  Realm-Local scope

   4  Admin-Local scope

   5  Site-Local scope

   6  (unassigned)

   7  (unassigned)

   8  Organization-Local scope

   9  (unassigned)

   A  (unassigned)

   B  (unassigned)

   C  (unassigned)

   D  (unassigned)

   E  Global scope

   F  reserved

NEW:

   +------+--------------------------+
   | scop | NAME                     |
   +------+--------------------------+
   |  0   | reserved                 |
   |  1   | Interface                |
   |  2   | Link-Local scope         |
   |  3   | Realm-Local scope        |
   |  4   | Admin-Local scope        |
   |  5   | Site-Local scope         |
   |  6   | (unassigned)             |
   |  7   | (unassigned)             |
   |  8   | Organization-Local scope |
   |  9   | (unassigned)             |
   |  A   | (unassigned)             |
   |  B   | (unassigned)             |
   |  C   | (unassigned)             |
   |  D   | (unassigned)             |
   |  E   | Global scope             |
   |  F   | reserved                 |
   +------+--------------------------+

- Ralph

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Fri, 14 Feb 2014 00:52:02 +0000

draft-ietf-6man-multicast-scopes-03.txt addresses the comment posted during the WG last call (see attached diff).

In my opinion, this rev of the document is ready to be sent to the IESG.

- Ralph

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 24 Feb 2014 12:06:32 +0200

Looks good to me now.

- Jouni

On Feb 14, 2014, at 2:52 AM, Ralph Droms (rdroms) <[email-masked]> wrote:

> <draft-ietf-6man-multicast-scopes-03-from-2.diff.html>--------------------------------------------------------------------

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Mon, 24 Feb 2014 20:52:16 +0000

> Looks good to me now.

OK, thanks.

- Ralph