Re: [Dime] [SPAM] RE: rfc3588bis version number

["Glen Zorn" <gwz at net-zen.net>]

Sebastien Decugis [mailto:sdecugis at nict.go.jp] writes:

> Hello again,
> > On
> > the initiator side, a new implementation would try the special port
> first
> > (because it's a "SHOULD") & if no answer then fall back to the old
> way
> > (because it's a "MAY", though we can specify this behavior more
> precisely).
> > That sounds fairly simple to me.
> So the initiator has to try two protocols (SCTP, TCP) and two ports
> (legacy, new TLS) when attempting a new connection... 

In the worst case, yes; however, I imagine that this would happen rarely
outside of conformance testing.  Diameter peers don't just connect "out of
the blue", so I would expect that in The Real World (TM) peers would either
be initially configured to use the right combination or (if they were smart)
remember the result of the discovery process.

> I would not call
> this "fairly simple" ;)
> 
> I guess it's doable... Just adding even more complexity to Diameter.
> 
> In any case, these changes (TLS and CER/CEA) require at least precise
> instructions in the draft, if we want to avoid multiple implementations
> that are not interoperable.

I think that we can leave capabilities update out of bis: it would be harder
to maintain backward compatibility (since it would change the state machine)
and it works cleanly as a separate app.

> Do we agree on this?

Precise specification is almost always a good thing.

> 
> Best regards,
> Sebastien.
> 
> --
> Sebastien Decugis
> Research fellow
> Network Architecture Group
> NICT (nict.go.jp)
>