I think all the people that implemented early version know that changes can, and will, break backwards compatibility. I don't recall very many places where I used this as augment for one way or another. I recall some places where it was 6 of one of half a dozen of the other and it made no fundamental difference to the protocol so we decided to go which what was already implemented.
That said some types of changes are very easy to move into a fully operational deployed DHT. Others are not. For example, a change that you can detect the version number and then just have the software do the right things is pretty easy particularly if both the new code and old code can exist in the ring at the same time. A change where every device in the ring needs to get a new certificate and you can' have a mixed ring with the old and new certificates at the same time is not easy to deploy. To the point of this specific proposal for change. This fundamentally changes the security model and nearly every part of this protocol that has anything to do with security - which is most of it. The suggestions is several years late - it was many years ago that this WG made the decision about what the general security model was doing to be. If people want this, it seems like a fine thing to do in version 2.0 of the protocol. Thought my previous email suggested that one could look at doing it in an extension, closer examination of that makes me think there would be some real hard problems in trying to do that as it requires all the security component to be re-thought and redesigned. Given the current level of energy in the WG, that would take several years to happen. I have pretty much zero interest in doing that, I'd like to actually have an RFC for this in the next year instead of several years from now. As practical improvement of the protocol, I have not seen a single us e case proposed where this improves things so much we can actually do something interesting that we can no do with the current proposal. On Jul 15, 2011, at 10:55 , Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/07/2011 03:34 PM, Cullen Jennings wrote: > > > > This would break all the current deployments and implementation and not just > > in a way where some new software would need to be pushed out - all new > > certificates would need to be issues. From my point of view, this is too > > late > > for this change and instead it could be addressed with an extension. > > About this "breaking current deployment" thing, it seems to me that anyway > when > RELOAD will be published as an RFC, the version number with be incremented to > 1.0 (0x0a), so implementations of the RFC will *not* be compatible with *any* > of > the current implementations. And because of this, I really do not understand > why the authors of RELOAD are fighting so hard to not break things that will > be > broken anyway - there was multiple instances of things that could have been > improved in the document but stayed because of this (the fragment bit is one > example of this). Having been there multiple times I really understand the > plight of early implementers but I would never ever use this as a > justification > to keep useless stuff in a protocol. What should have been done is simply to > increment the version each time a new version of the draft would have broken > interoperability - and we had the possibility to do that 8 times (versions 0.1 > to 0.9). > > > > > On Jul 1, 2011, at 5:47 AM, Gonzalo Camarillo wrote: > > > >> Hi, > >> > >> please, let me know whether or not these modifications will be included in > >> the base draft at this point. > >> > > [...] > > - -- > Marc Petit-Huguenin > Personal email: [email protected] > Professional email: [email protected] > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAk4gfxoACgkQ9RoMZyVa61cxtQCeK9nUyj9XzOp0+8q9Mdhtp9Sg > 3QoAoJaA4VCBUqtphhjrUMyAiaVmsNRc > =gx2i > -----END PGP SIGNATURE----- > Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
