Re: [Dime] rfc3588bis version number
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dime] rfc3588bis version number



Hi,

> I guess it's really a question of what the version number in the
> header indicates. So far, its the opinion of most folks that the
> version number means ONLY "major update and/or new significant
> features" and bis is merely an update/patch to an existing version.
Well, what about calling it "version 1.1" in the draft and changing the
header field to some stupid value like 0x11 ? Would it release the
psychologic barrier ? :)

>
> Typically yes. But 1) we should confine ourselves to the changes in
> bis because those are the only changes that exist/relevant. 2) If bis
> is treated as fix/patch to problems that renders certain features in
> 3588 as non-interoperable then why would an implementation need to
> support both version ?
As pointed out by Lionel, we need to support both versions *because*
equipment already exist and is deployed that implement the original
3588. What do you do when you have to equipments bought at different
times, that support the same protocol, and that are unable to
interoperate? Especially in the case of several administrative domains...

To me, not changing the version number in the header will lead to a lot
more problems than changing it.

I am now starting to deploy Diameter in an academic environment. I plan
to use the revised version of the protocol. Then I will interconnect
this as much as possible with other organizations. If these
organizations already run a Diameter infrastructure, they will very
likely implement the original RFC. How is it possible to interconnect
with them?

Best regards,
Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.