> First, lets keep in mind that this is an Informational document.
I wonder whether Experimental wouldn't send a clearer signal that there is some doubt about the viability of the solution.
That would be better than informational.
But I still think the document should say "MUST prevent loops; SHOULD run IEEE 802.1D to prevent loops" and then talk about cases when the protocol is not needed. The one example we have is the case of PPP (e.g. to a GGSN) where the probability of a loop would be very small, so in that particular case there is no need for 802.1D (and there might be other examples, but the 802.11 scenario in the document isn't one of them).
I can see how this could be very useful in certain types of network environment, and publishing as Experimental will allow people to share experience and try to fix the open questions.
ok
Since the deployment future of SEND is unknown, I don't think it's appropriate to block this work because of SEND.
Yes, but at least the document should be internally inconsistent and not claim in section 3 that working with SeND is a requirement, even though it doesn't work with SeND.
Erik
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
