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

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

> 
> 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?

> 
> 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)

iEYEARECAAYFAk4h1J0ACgkQ9RoMZyVa61cFxQCfTPJuP/YveHmTK4AMZfonQK3m
Q+IAmgJN8sYZMzfygCqnocSYuosMsJT9
=o9Rj
-----END PGP SIGNATURE-----