Re: [P2PSIP] Breaking RELOAD [was Re: Identity certificate segregation]

[Marc Petit-Huguenin <[e-mail]>]

-----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 <[e-mail]> 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: [e-mail]
Professional email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk4ifaIACgkQ9RoMZyVa61fPIgCfXHENMbCurA48yDa8luqfDruT
Ih0AoIgCzBWIRssi3kvGwSMLZLBa8i05
=6UXw
-----END PGP SIGNATURE-----