Subject: [MBONED] general comments on draft-ietf-mboned-auto-multicast-12

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 29 Mar 2012 19:49:19 +0200

Here is my quick review of draft-ietf-mboned-auto-multicast-12.

I see this as a major textual change to the I-D, so I have tried to read 
the whole of the document and provide general comments in this message. 
General comments follow (a separate message will send transport-related 
feedback).

Gorry

####
Section 1:
    Unfortunately, many of these
    applications must currently rely on unicast replication at or near
    sources because most clients lack multicast connectivity to the
    network containing the sources.

- While this may be correct, it's easy to misread this as AMT defines 
how to inject traffic sources into the multicast cloud. This may be 
clearer if it says something more like "because most clients at 
receivers do not have multicast connectivity to the network that carry 
traffic from the sources."

####
    have native multicast access to a multicast source network to request
                                                ^^^^^^
- Is "source" helpful here?

####
    To allow fast deployment, the solution presented here only requires
    small and concentrated changes to the network infrastructure, and no
    changes at all to user applications or to the socket API of end-
    nodes' operating systems.
- The above para was in the intro, and I'd hoped to see something like 
this in the applicability section of the new draft. That is, what needs 
to eb change to deploy this?

####
Section 2.
    multicast traffic from sources in a multicast enabled network to

- remove "sources in". To clarify the next sentence.

####
    The downstream side of a gateway services multicast receivers - the
                                             ^
- insert "one or more" to make this sentence more easily read.

####
4.1.4.1
    does not yet allow this, as many relays will lack native multicast
                             ^^
- replace 'as" by "because"

####
    access to sources even though they may be globally accessible via
- consider replacing sources, since AMT doesn't directly access sources.

####
4.2.1
       in order to find a relay with which to communicate.
       ^^^^^^^^^
- To make it less confusing, suggest you omit the "order".

####
4.2.1.4
         request is typically made through some form IGMP/MLD service
                                           ^^^^^^^^^
- does not parse missing word?

####
    10.  Multicast datagrams transmitted by a source travel through the
- say "from" instead of "transmitted by"?

####
4.2.2.3
    datagrams.  These IP datagrams are encapsulated in AMT messages which
- /which/that/

####
5.1.4.5
    A 1-bit flag set to 0 to indicate that the message does NOT carry the
- RFC 2119 keyword "NOT" seems like it should be lower case.

####
5.2.3.4.2
    message must be computed as described in Section 5.2.3.4.5.
- /must?MUST/ ??

####
5.2.3.5.1
       Unsolicited
       state-change reports are typically retransmitted multiple times
       while current-state reports are not.
- Presumably advice, not a requirement.

####
    The gateway must start a timer that will trigger the next iteration
- /must?MUST/ ??

####
5.2.3.6.2
    has not yet located a relay with which to communicate, it must first
- /must?MUST/ ??

####
5.2.3.6.2
    not yet received a Membership Query message, it must first execute
- /must?MUST/ ??

####
5.2.3.7.2.
    If the gateway sends the
    Teardown message multiple times, it SHOULD insert a delay between
    each transmission using the timing algorithm employed in IGMP/MLD for
    transmitting unsolicited state-change reports.
- Can you recommend a value? An arbitrary delay is clearly not what is 
intended, so can we suggest a range or value please!

####
5.3.3.2
    address, it must respond just as it would if the message had been
- /must?MUST/ ??

####
5.3.3.7
    The RECOMMENDED endpoint timer duration MAY be computed from tunable
- The second keyword /MAY/may/ - a recommended value can't be optional?

####
    Property implemented gateways and relays will also filter
    ^^^^^^^^
- /property/Properly/

####
The draft speaks about IP encapsulation of membership reports etc, which 
would normally carry the IP Router Alert option. What is the expectation 
here?
- Is an IP packet with an RA option discarded?
- IS an IP packet with a RA option accepted?

####