Subject: AD Evaluation: draft-ietf-6man-multicast-scopes

From: Brian Haberman <[email-masked]>
Date: Fri, 16 May 2014 09:13:01 -0400

All,
     I have completed my AD Evaluation of
draft-ietf-6man-multicast-scopes as a part of the publication process.
This is clearly written document and I thank the author for that.  I
only have a few issues that I would like addressed before moving this to
IETF Last Call.

1. I am curious about the inclusion of section 5 in this document.
Based on the guidance in section 3, shouldn't
draft-ietf-roll-trickle-mcast be the document defining the scop 3 usage?

2. A nit in the IANA section... It references section 1 for the scope
table, but that table is in section 2.

3. As for the new IANA registry... Is there really an expectation that
the multicast scopes will be updated enough to justify the registry? A
big reason why many of the scopes are marked unassigned is so that
network operators can use those scopes as they see fit within the
networks under their control. Given that this document updates the two
RFCs that describe the scopes, is the registry needed?

Regards,
Brian

---

From: Ralph Droms <[email-masked]>
Date: Fri, 16 May 2014 09:38:47 -0400

Responses in-line...

> draft-ietf-roll-trickle-mcast be the document defining the scop 3 usage?

My recollection is that the roll WG discussed at least three options for publishing the definition of scop 3:

1) in this document
2) in draft-ietf-roll-trickle-mcast
3) in a separate RFC

Again working from memory, and hoping the roll WG chairs can help my memory, there was thought to be no substantive difference between 1 and 2 and, pragmatically, publishing the definition in this document was less disruptive.

I see that draft-ietf-roll-trickle-mcast is also currently with the IESG and, if desired, it would probably be easy enough to move the definition from this document to draft-ietf-roll-trickle-mcast at this time.
> table, but that table is in section 2.

Thanks; will be fixed in next rev.

> RFCs that describe the scopes, is the registry needed?

The motivation for a new registry was not so much future updates to other scopes, but rather that it would be useful to have the definitions for scop 3 in one place and the list of all the definitions in the IANA repository rather than just in an RFC (that has updated other RFCs).

- Ralph

---

From: Michael Richardson <[email-masked]>
Date: Fri, 16 May 2014 10:41:20 -0400

> Again working from memory, and hoping the roll WG chairs can help my
    > memory, there was thought to be no substantive difference between 1 and
    > 2 and, pragmatically, publishing the definition in this document was
    > less disruptive.

There was also some view that scope 3 might have meaning beyond
trickle-mcast, and that "this document" need a 6man stamp and it would be
easier to get 6man to focus on just that part.
And, we thought that roll-trickle-mcast would be long done by now.

    > I see that draft-ietf-roll-trickle-mcast is also currently with the
    > IESG and, if desired, it would probably be easy enough to move the
    > definition from this document to draft-ietf-roll-trickle-mcast at this
    > time.

Adrian has a private comment on the document that he has to work through.
That could delay the document more, and so it might make sense to just let
multicast-scopes proceed now.

    > The motivation for a new registry was not so much future updates to
    > other scopes, but rather that it would be useful to have the
    > definitions for scop 3 in one place and the list of all the definitions
    > in the IANA repository rather than just in an RFC (that has updated
    > other RFCs).

I also agree: people are getting trained to go to IANA's web site for the
latest reference, and it's good to encourage that.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Brian Haberman <[email-masked]>
Date: Fri, 16 May 2014 11:32:04 -0400

Michael & Ralph,

> latest reference, and it's good to encourage that.

Given the above, the document seems ready to go to IETF Last Call modulo
fixing up the reference to the table.  I will put this in Revised ID
needed state so that change can be made.  Once a new version pops out, I
will start IETF LC.

Regards,
Brian

---

From: Ralph Droms <[email-masked]>
Date: Fri, 16 May 2014 11:49:58 -0400

The new rev has been uploaded with the reference to section 2 fixed.

- Ralph