Hi Acee,
introducing non-backward-compatible revision of protocol is very big
deal both for vendors and customers.
What I am vigorously objecting is approach of developing
non-backward-compatible protocol revision with "minimum of changes"
being the primary requirement. This almost guarantees end result to be
inefficient.
Protocol *extension* must be designed to be backward compatible even
if that makes it very complex.
That complexity should be addressed by major protocol *revision*.
Work on major protocol revision should start from writing requirements
document - and this stage alone should probably last couple of years.
> Additionally,
> history has proven that more focused work has a better chance of
> reaching fruition.
That's why burning need for new feature should not be mentioned while
discussing non-backward-compatible protocol extension. Latter should be
developed on its own.
Anton
On 05/04/2013 11:31 PM, Acee Lindem wrote:
Hi Anton,
If you look at the drafts Fred recently refreshed, I think you'll have to
agree that we have a burning requirement for this extension. Additionally,
history has proven that more focused work has a better chance of reaching
fruition. As for backward compatibly, it is possible to do something akin
to RFC 1793 and the original unpublished version of this draft contained
these mechanisms. However, it is not clear that the complexity justifies
the mechanisms - we'll leave that for the WG to decide.
Acee
P.S. To quote a philosopher of the late 20th century, "You can't always
get what you want. But if you try sometimes well you might find you get
what you need."
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
