Hi, > >In my opinion, it is better to update the current RFCs or obsolete > >them instead of adding more specifications which will result on > >confusing vendors. Of course, it is my point of view and some people > >are disagree with that. They would like to have several optional > >standards and let the implementers to choose. > > Proposed Standards were supposed to be "optional". Implementers > choosing to implement them was a good test for running code (code > which is actually used on the Internet). The specifications can then > be published as Standard. If you don't have time to track all the > Proposed Standard you could implement the Standard and achieve at > least minimum interoperability. It does not work in practice. There > isn't any Standard for IPv6. The Standard for SMTP (email) is old and it is not worth basing an implementation on that. > > I am curious about what you find difficult about IETF specifications. > Note that I am not going to disagree with your opinion or argue that > what you said is wrong. :-) >
As you stated here, there are some old RFCs that, in my opinion, we do not know whether or not they still address today's minimum requirements. There are also some vendors that still using them because they did not see any update on them. This means we are adding more and more standards while we do a few efforts to check the old standards and obsolete them or update them. I do not have any problem with having several options. But I do think that addressing the current RFCs has more priority on adding new specifications. In other word, to say whether or not the current RFCs can still address our needs or they need a few modifications to address our needs, has higher priority than trying to come up with something that might have the same impact as we resolve the problem with the current RFCs. I heard from some people that their problem of not addressing the old RFC is backward compatibilities. In my opinion, It is the choice of vendors to improve their old implementations or just leave it as it is. But by addressing those RFCs at least the customers know that they did not choose the best option. This means that the customers will force vendors to improve their current implementations. Then instead of having thousands of RFCs we will have some that we can rely on and we are sure that they are not something not useful. When something does not have our today's requirement why we need to think about that?! Regards, Hosnieh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------