On Sun, Jul 12, 2009 at 5:08 PM, Eric Rescorla<[email protected]> wrote: > 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.
The terms were explained in the email I sent out prior to that one. Were we to add such a field, I think the exact values that it should have would be a matter that required some thought. (I at first considered adding an overlay-specific bit, but since clients don't need to implement the full overlay algorithm decided it would be better to focus on more general concepts.) Regardless, after further thought I believe that something more like ForwardingOption with comprehension required/optional would be far more useful. Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
