-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This was general remarks about the whole process, which I especially dislike.
On 07/16/2011 06:47 PM, Bruce Lowekamp wrote: > On Sat, Jul 16, 2011 at 2:12 PM, Marc Petit-Huguenin <[email protected]> wrote: > On 07/16/2011 09:41 AM, Cullen Jennings wrote: >>>> >>>> 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. > > Well, I kind of disagree here. The problem is that *future* implementers will > not have access to the whole history of the development of the RELOAD protocol > when trying to decipher the specification. The RELOAD specification is *not* > developer friendly (but it is not specific to this spec). I am still not > saying > that a protocol must be developer-friendly, just that the text describing it > should be, and that when it makes no fundamental difference to the protocol, > making it easier for future developers should have priority over not breaking > compatibility. > > >> While I think we're a bit late in the process for a wholesale rewrite >> (we've done it about twice), if you have specific suggestions on >> editorial issues that would make it clearer, please make them now >> while we might be able to adjust some of the text. > > >>>> 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. > > I still do not see this as a good reason to stop fixing stuff in the protocol. > What is the point of having internet *drafts* if they are to be considered as > standard track RFCs? > >> There are quite a few people who want to build things on top of it, >> and it needs to not be a moving target for that to happen. >> Presumably, if a significant amount of practical experience shows >> things need to be changed, extensions and/or a v2.0 can be done. But >> right now the lack of a v1.0 is blocking other people's work. > >> Bruce > > >>>> >>>> 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. > > OK, now we agree. > >>>> 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 use 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: >>>> >>>> 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. >>>>>>>> >>>> >>>> [...] >>>> >>>>> > >>>> Cullen Jennings For corporate legal information go to: >>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html - -- 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) iEYEARECAAYFAk4ifaIACgkQ9RoMZyVa61fPIgCfXHENMbCurA48yDa8luqfDruT Ih0AoIgCzBWIRssi3kvGwSMLZLBa8i05 =6UXw -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
