At Sun, 12 Jul 2009 20:54:14 +0000,
David A. Bryan wrote:
>
> Actually this is more of a general comment that it is big enough
> that using it as an excuse to not include something isn't really a
> valid reason.
So you'll totally support it when I suggest we incorporate a feature
to carry around BGP route tables? After all, we might need that
someday and if the protocol is bloated already, no harm no
foul, right?
> My point is more that you saying "you don't like cruft" is not a
> very well articulated reason to not include a 16 bit field in an
> already 141 page document. I think we have included enough that,
> this looks to me as useful as many other things in the draft, and I
> personally support it.
Of course, you're just totally mischaracterizing what I said, which
was:
I don't see that this change adds any value. It's just additional
cruft.
To be clear, my objection isn't just that I don't like cruft, but
rather that this feature is useless. Actually, now that I look at it,
it's worse than useless, it's actively harmful; RELOAD doesn't include
clients as a first-class concept for a good reason, it's not necessary
and it interferes with the orthogonality of the protocol, which is
almost never a good architectural decision.
It's particularly bad in this case because we're adding an ad hoc
indicator that receivers don't process but that categorizes nodes in
an ill-defined way. In fact, of the five possible settings Bruce
listed, I don't know what two of them ("peer optimization" and "client
optimization") mean, and one distinction (neighbor versus routing
table) only makes sense with specific overlays, and so properly
belongs at the Topology Plugin Layer.
-Ekr
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
