[Roll] FYI -- rfc-editor revisions to draft-ietf-roll-admin-local-policy-03.txt

[Michael Richardson <[e-mail]>]

The draft-ietf-roll-admin-local-policy is in RFC-editor queue, and the editor
had some difficulties with some of the sentences and there was some
significant back and forth with the authors to make sure the sense was correct.

I want to first publically thank Lynne Bartholomew, Peter van der Stok
and Robert Craigie for their perseverance on this.

This "short" document is now two years in the making, in part due to
queuing issues with trickle-mcast, etc.

These are the changes that will be made, and I hope I got the last set of
them!

I am posting this in order to determine that there are no *serious*
and VERY *significant* objections.  We have been through this many times
already.


Michael and Ines.

Original:

 o  The message carries an MPL option (MPL message) and the
    incoming MPL interface is subscribed to the destination multicast
    address.

 o  The message does not carry an MPL option, the multicast address
    is unequal to ALL_MPL_FORWARDERS scope 4 or scope 3, and the
    interface has expressed interest to receive messages with the
    specified multicast address via MLD [RFC3810] or via IGMP
    [RFC3376].  The message was sent on according to PIM-DM
    [RFC3973] or according to PIM-SM [RFC4601].


Replace by :

 o  The message carries an MPL option (MPL message) and the incoming
    MPL interface is subscribed to the destination multicast address.
    [MCR: unchanged, I think]

 o  The message does not carry an MPL option and the
    interface has expressed interest to receive messages with the
    specified multicast address via MLD [RFC3810] or via IGMP
    [RFC3376].  The message was sent on according to PIM-DM [RFC3973]
    or according to PIM-SM [RFC4601].

=============
Original:

 Two types of legal multicast messages are considered: (1) MPL
 messages, and (2) multicast messages which do not carry the MPL option

Replace by:

 Two types of legal multicast messages are considered in Section 4.1:
 (1) MPL messages, and (2) multicast messages which do not carry the
 MPL option

=============
Original:

 o  MPL messages with a multicast scope of 5 or higher MUST
    encapsulate a message with the same multicast address without MPL
    option.  The decapsulated message can be forwarded over an
    interface when the interface is subscribed with MLD to the
    same multicast address.

Replace by:

 o  MPL messages which encapsulate a message with a multicast scope of 5 or
    higher
    are decapsulated and forwarded over the interface
    when the interface is subscribed to the multicast address of the
    decapsulated message.

=============
Original:

o  Link-local (scope 2) messages or realm-local (scope 3) multicast messages
   are not forwarded.

o  Admin-local (scope 4) multicast messages are encapsulated with a header
   carrying the MPL
   option and are forwarded on al MPL interfaces that are subscribed to the
   multicast address,
   have the same zone index, have PROACTIVE_FORWARDING set to true, and have
   MPL_BLOCKED set to false.

Replace by:

o  Link-local (scope 2), realm-local (scope 3) and admin-local (scope 4)
   multicast messages are not forwarded.

=============
Original:

o  Multicast messages with a multicast scope of 5 or higher are
   encapsulated with a header carrying the MPL option and are
   forwarded on al MPL interfaces that are subscribed to the
   multicast address, have PROACTIVE_FORWARDING set to true,
   and have MPL_BLOCKED set to false.  In addition these messages follow
   the Multicast forwarding rules as specified by PIM [RFC3973],
   [RFC4601] according to group specifications enabled by MLD
   [RFC3810] or IGMP [RFC3376].

Replace by:

 o  Multicast messages with a multicast scope of 5 or higher are
    encapsulated in a MPL message with destination address
    ALL_MPL_FORWARDERS scope 4.  The resulting message is then
    treated as described in section 4.2.1.




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



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