Brian Haberman wrote:
I take it from your detailed responses below that you see it in IETF's best interest to publish this document and protocol without any quality improvements to neither the document nor the protocol. Did I understand that correctly?
I never said that. I was commenting on the very broad brush you were painting with. If there are things that can be changed to improve a spec, they should be considered. In this particular case, it appears that the supporters of the spec are limiting the deployment scenarios. With those limitations, I am not sure that SeND would be used in concert with proxy ND.
You say that, yet you fail to respond to my comment that the 802.11 scenario in the document is a case where this might be used and there is also a desire to use SeND.
First, lets keep in mind that this is an Informational document. I don't see it as the eventual solution for the problem space. Secondly,
I think INFO documents produced by IETF WGs should have "truth in advertising", so I don't buy the claim that the document can be silent on the dangers of loops, and misleading (internally inconsistent) on whether it works in the presence of SeND.
> I see proxy ND being used in very small, cost-constrained networks. > Something where a router is over-kill.
Unfortunately, there are many times when the IETF has created a protocol intending it to be used in a limited environment, where the generality of IP has resulted in it being more widely deployed. The IETF tries to avoid this (for example, see the security requirements for IP Storage, where the original argument was that it would be used in a limited local environment, hence no need for things like IPsec), by requiring that protocols not cause harm should they be deployed much more widely than the designers anticipated.
I will admit to missing the stated requirement in to support SeND. The Security Considerations section spells out how SeND does not work with the existing proxy text in 2461. That, to me, made interoperating with SeND a non-requirement.
So now you understand the issue.
I suspect that the requirement should effect how a protocol is designed, as opposed to creating requirements which are the things that the artifact is capable of supporting. But as I said to Brian, in this case the issue is to make the document clear what it supports and doesn't support, with some explicit warnings that it can't be deployed in conjunction with SeND.
The counterexample is that there are ISPs that have their home users with 802.11 run public hotspots and get some compensation from the ISP. In this case, since it is a public access 802.11, SeND would be a good thing to use. And 802.11 is also a key scenario for proxynd.
This is the first I have ever heard of that particular scenario.
And Jim Kempf said, it's being deployed that way.
Erik
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
