Re: draft-ietf-mboned-ieee802-mcast-problems-06 review

Hello Jake,

Thanks for the additional review.  I will prepare a new revision of the 
document for submission on Monday.

By the way, due to a last-minute change of plans, I will be unable to 
attend this IETF in person.  I'll try to attend remotely and prepare 
some presentation materials if needed.

Regards,
Charlie P.


On 7/18/2019 5:09 PM, Holland, Jake wrote:
> Hi guys,
>
> I was working on the document shepherd write-up and noticed another
> few minor issues in the doc that I think will need fixing:
>
>
> New technical:
> 1.
> I noticed an addition in -06 in the AMT section that I recommend
> changing:
>
> <OLD>
>     It is RECOMMENDED that multicast-enabled networks deploying AMT
>     relays for this purpose make the relays discoverable with the
>     following methods:
>
>     o  DNS-SD [RFC6763]
>     o  the well-known IP addresses from Section 7 of [RFC7450], and
>     o  DRIAD [I-D.ietf-mboned-driad-amt-discovery]
> </OLD>
>
> I would remove the DRIAD line item, since this is advice to the
> local Wi-Fi network operator:
> <NEW>
>     It is RECOMMENDED that multicast-enabled networks deploying AMT
>     relays for this purpose make the relays locally discoverable with
>     the following methods, as described in [I-D.ietf-mboned-driad-amt-discovery]:
>
>     o  DNS-SD [RFC6763]
>     o  the well-known IP addresses from Section 7 of [RFC7450]
> </NEW>
>
> Sorry, I hadn't caught this suggestion when it was raised, but in
> the context of this section, I don't think DRIAD belongs in the
> list, because this is advice for the local (to the receiver)
> network operator, but DRIAD discovery is something a remote sender
> would deploy.
>
> This is because the new method DRIAD defines is for looking up an
> AMT relay known to the sender, so it's only applicable to the
> one sending traffic.  (And if the Wi-Fi network operator is also
> operating the source of traffic, it's either within the same
> multicast-capable local or local-ish network, in which case the
> DRIAD lookup isn't needed, or the sender is in a separate network,
> in which case DRIAD could be useful, but it's not something
> provided by the Wi-Fi portion of the network.)
>
>
> New editorial (minor):
> 2.
> The first few references are separated by commas without exposition,
> where usually they'd be without commas if they're intended as a
> reference for a claim, but in fact I think 2 of these references are
> outlining the well-known issues, and one is the description of the
> 802.11 networks (new in -05, I think):
> <OLD>
>     Well-known issues with multicast have prevented the deployment of
>     multicast in 802.11 [dot11], [mc-props], [mc-prob-stmt], and other
>     local-area wireless environments.  Performance issues have been
> </OLD>
>
> I think it might make more sense as:
> <NEW>
>     Well-known issues with multicast have prevented the deployment of
>     multicast in 802.11 [dot11], and other local-area wireless
>     environments, as outlined in [mc-props] and [mc-prob-stmt].
> </NEW>
>
> (Or maybe "as outlined", might be better "as documented" or "as
> described"?  This bit of wordsmithing I don't care about, just
> trying to fix the weird comma-separated reference list...)
>
>
> References:
> I've also checked the references a little more thoroughly, and
> noticed a few issues I didn't see before:
>
>
> 3.
> The [arpsponge] reference link doesn't work:
> https://ams-ix.net/downloads/arpsponge/3.12.2/arpsponge-3.12.2/arpsponge.txt
>
> I was thinking it might make sense to reference the original paper instead:
> "Effects of IPv4 and IPv6 address resolution on AMS-IX and the ARP Sponge"
> by Marco Wessel and Niels Sijm
> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.182.4692
>
> Or perhaps the github repo:
> https://github.com/AMS-IX/arpsponge
>
> 3.a.
> (Editorial: in the reference to this, it might make sense to call it "one of the
> most widely deployed arp sponges" instead of "the standard one".)
>
> 4.
> [dot11] reference has a broken link:
> https://standards.ieee.org/getieee802/download/802.11-2016.pdf
>
> I get a 404 on this.  The RFC Style guide uses a different
> formulation in one of the IEEE examples, which worked for me:
> http://standards.ieee.org/findstds/standard/802.11-2016.html
>
> (from https://tools.ietf.org/html/rfc7322#section-4.8.6.6 )
>
> 4.a.
> Also: in the draft's html page the link is not clickable, and it
> seems to be because the url contains extra text inside the
> <> instead of outside of it (the "(includes 802.11v amendment)" bit)
>
>                Medium Access Control (MAC) and Physical Layer (PHY)
>                Specification", March 2016,
>                <http://standards.ieee.org/getieee802/
>                download/802.11-2016.pdf (includes 802.11v amendment)>.
>                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> 5.
> [dot11aa] same broken link style as dot11 (#4)
>
>
>

_______________________________________________
MBONED mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mboned