Subject: [Dime] 3588-bis

From: <[email-masked]>
Date: Fri, 9 Jun 2006 12:14:21 +0300

Hi all,

We've discussed both a 3588-bis (Diameter Base) & a 4005-bis (NASREQ).
Before starting to produce such
documents, I would like to get some feedback on some ground-rules.

IANA considerations in 3588 explain the mechanisms to extend Diameter.
As there are existing deployments of Diameter, I think we should not add
new features to 3588-bis, just focusing on either removing features that
are not used and correcting mistakes.  

I'd like discussion to be very focused, having proposed text changes.
General statements like "wouldn't it be nice if feature x could do
this?" aren't very helpful.

I think that we should spend time in Montreal talking about this - I
think we should prepare a list of issues with 3588.  There are a number
of issues in the issue tracker, I suggest we start from that.

comments?
John

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 9 Jun 2006 10:04:15 -0400

Hi John,

Just my two cents:

1)I also believe that it is a good idea to clean up/fix first, what is
already defined, with focused text changes. Especially for the bis document,
this may be all what is needed.

2)OTOH, there may be featues, which are not currently defined in RFC3588 but
which are usefull for certain real-life deployment cases. Rather than ending
up with multiple proprietary -and non-interoperable- solutions, it could be
nice to standardize them . I hope WG will have time/interest at least to
discuss such concerns as well -not necessarily as part of the bis effort-.

3)RFC3588 11 "IANA Considerations" addresses extensibility of Diameter
protocol, but more from defining new objects point of view, e.g. defining
new applications. I was wondering, what the approach should be when
fixing/adding stuff for the base protocol itself. Actually not big deal,
hopefully we will have some feeling about that, once we start to discuss the
issues.

4)IMHO, it could be good to start discussing issues on the mailing list. It
may be the case that a good number of people which actually implemented the
protocol couldn't/wouldn't make it to IETF meeting.

    Thanks,
    Tolga

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, June 09, 2006 5:14 AM
> To: [email-masked]
> Subject: [Dime] 3588-bis
>
>
> Hi all,
>

---

From: Anders Kristensen <[email-masked]>
Date: Fri, 16 Jun 2006 18:12:58 -0400

Backwards compatibility is obviously a valid concern but in my view it's 
not a goal to not allow or even to limit the number of new features as 
long as they can be added in way that preserves backwards compatibility. 
I think we have to consider whatever ideas people have on a case by case 
basis.

Anders

---

From: <[email-masked]>
Date: Sat, 17 Jun 2006 19:54:41 +0300

Andres,

>Backwards compatibility is obviously a valid concern but in my 
>view it's not a goal to not allow or even to limit the number 
>of new features as long as they can be added in way that 
>preserves backwards compatibility. 
>I think we have to consider whatever ideas people have on a 
>case by case basis.

By no means do I imply that we cannot have new features. I'd prefer
to see new features as extensions, using the basic extensibility
options - I just wanting to be cautious about adding new features
to the base spec document.  I'm more comfortable if they are in
separate documents, but then again, this is a consensus based
process, so if there is consensus, then we should run with it.

John