Subject: Re: [Dime] AD Review of draft-ietf-dime-rfc3588bis-25.txt

From: "Glen Zorn" <[email-masked]>
Date: Sat, 11 Dec 2010 10:56:25 +0700

Dan Romascanu [mailto://[email-masked]] writes:

...

> 2. Same comment about the Diameter realm routing clarifications
> described in RFC 5729.

Section 1.1.1 now reads:

1.1.1.  Description of the Document Set

   The Diameter specification consists of an updated version of the base
   protocol specification (this document) and the Transport Profile
   [RFC3539].  This document obsoletes RFC 3588.  A summary of the base
   protocol updates included in this document can be found in
   Section 1.1.3.

   This document defines the base protocol specification for AAA, which
   includes support for accounting.  There are also a myriad of
   applications documents describing applications that use this base
   specification for Authentication, Authorization and Accounting.
   These application documents specify how to use the Diameter protocol
   within the context of their application.

   The Transport Profile document [RFC3539] discusses transport layer
   issues that arise with AAA protocols and recommendations on how to
   overcome these issues.  This document also defines the Diameter
   failover algorithm and state machine.

   RFC 5729 [RFC5729] defines the behavior required of Diameter agents
   when routing requests in which the User-Name Attribute-Value Pair
   Section 8.14 contains a Network Access Identifier [RFC4282] formatted
   with multiple realms.

Does this satisfy your concern?  BTW, it seems that the reasons for not
incorporating the content of RFC 5729 into 3588bis (& obsolescing it) seem
to have evaporated.  Wouldn't it be a good idea to do this?

> 
> 3. How is backwards compatibility ensured between RFC 3588
> implementations which were mandating IPSec and this new version which
> mandates TLS and makes IPSec support optional, while disallowing usage
> of Diameter without any security mechanisms?
> 
> Thanks and Regards,
> 
> Dan
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 13 Dec 2010 12:07:24 +0100

> -----Original Message-----
> From: Glen Zorn [mailto:[email-masked]] 

> 
> Does this satisfy your concern?  BTW, it seems that the 
> reasons for not incorporating the content of RFC 5729 into 
> 3588bis (& obsolescing it) seem to have evaporated.  Wouldn't 
> it be a good idea to do this?
> 

Edits look good. Yes, we can go all the way and incorporate all content
of 5729 to the bis if the WG agrees (as 3588bis is anyway open for more
consistent edits). 

Dan

---

From: jouni korhonen <[email-masked]>
Date: Mon, 13 Dec 2010 13:52:52 +0200

Hi,

> of 5729 to the bis if the WG agrees (as 3588bis is anyway open for more

My concern/question here is, regarding obsoleting 5729, what happens to stuff that gets implemented/deployed based on 3588 and also use 5279, and do not have a rush to go for 3588bis in foreseen future?

- Jouni

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 13 Dec 2010 19:18:45 +0700

jouni korhonen [mailto:[email-masked]] writes:

...

> My concern/question here is, regarding obsoleting 5729, what happens to
> stuff that gets implemented/deployed based on 3588 and also use 5279,
> and do not have a rush to go for 3588bis in foreseen future?

I don't understand; it's not like 3588 & 5279 are going to disappear, nor
implementations suddenly become non-standard...

...

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 13 Dec 2010 15:48:33 +0100

Why would this be a problem? I guess for quite a while there will be
implementations conforming with 3588 while the world transitions to
3588bis. Do I miss something? 

Dan

> From: jouni korhonen [mailto:[email-masked]] 
> Sent: Monday, December 13, 2010 1:53 PM
> To: Romascanu, Dan (Dan); Glen Zorn
> Cc: [email-masked]
> Subject: Re: [Dime] AD Review of draft-ietf-dime-rfc3588bis-25.txt
> 
> Hi,
> 
> reasons for 
> >> not incorporating the content of RFC 5729 into 3588bis (& 
> obsolescing 
> >> it) seem to have evaporated.  Wouldn't it be a good idea 
> to do this?
> >> 
> > 
> > 
> > Edits look good. Yes, we can go all the way and incorporate all 
> > content of 5729 to the bis if the WG agrees (as 3588bis is 
> anyway open 
> > for more consistent edits).
> 
> My concern/question here is, regarding obsoleting 5729, what 
> happens to stuff that gets implemented/deployed based on 3588 
> and also use 5279, and do not have a rush to go for 3588bis 
> in foreseen future?
> 
> - Jouni
> 
> 
> 
> > 
> > Dan

---

From: jouni korhonen <[email-masked]>
Date: Mon, 13 Dec 2010 17:20:33 +0200

On Dec 13, 2010, at 2:18 PM, Glen Zorn wrote:

>> content

...

Existing implementations for sure won't have their binaries modified and unlike to have their existing code base changed :) The point being, if you deprecate some spec i.e. writing down "RFC xyz is now deprecated/obsoleted", then implementing it for new products is not recommended/allowed anymore.  Can I still state that forthcoming new implementations (or deployments) based on 3588 are not affected by whatever 3588bis deprecates? I just want to be clear with this myself..  I know this is just specification world trickery but we often get hit by "outdated & obsoleted spec hammer" even if it does not make sense in certain cases. 

- JOuni

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 13 Dec 2010 16:22:58 +0100

> Sent: Monday, December 13, 2010 5:21 PM
> To: Glen Zorn
> Cc: Romascanu, Dan (Dan); [email-masked]
> >> My concern/question here is, regarding obsoleting 5729, 
> what happens 
> >> to stuff that gets implemented/deployed based on 3588 and also use 
> >> 5279, and do not have a rush to go for 3588bis in foreseen future?
> > 
> > I don't understand; it's not like 3588 & 5279 are going to 
> disappear, 
> > nor implementations suddenly become non-standard...
> 
> ...
> 
> Existing implementations for sure won't have their binaries 
> modified and unlike to have their existing code base changed 
> :) The point being, if you deprecate some spec i.e. writing 
> down "RFC xyz is now deprecated/obsoleted", then implementing 
> it for new products is not recommended/allowed anymore.  Can 
> I still state that forthcoming new implementations (or 
> deployments) based on 3588 are not affected by whatever 
> 3588bis deprecates? I just want to be clear with this 
> myself..  I know this is just specification world trickery 
> but we often get hit by "outdated & obsoleted spec hammer" 
> even if it does not make sense in certain cases. 
> 
> - JOuni
> 

You can clarify this with text in 3588bis. 

Dan

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 14 Dec 2010 10:24:13 +0700

jouni korhonen [mailto:[email-masked]] writes:

> Existing implementations for sure won't have their binaries modified and
> unlike to have their existing code base changed :) The point being, if
> you deprecate some spec i.e. writing down "RFC xyz is now
> deprecated/obsoleted", then implementing it for new products is not
> recommended/allowed anymore.  Can I still state that forthcoming new
> implementations (or deployments) based on 3588 are not affected by
> whatever 3588bis deprecates? 

I'm not sure, but I don't think that "obsoletes" == "deprecates".

> I just want to be clear with this myself..
> I know this is just specification world trickery but we often get hit by
> "outdated & obsoleted spec hammer" even if it does not make sense in
> certain cases.

You seem to be arguing that 3588bis be either abandoned or published as if
it came from a vacuum (presenting the interesting situation of having two
standard Diameter protocols).

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 14 Dec 2010 10:28:20 +0700

Romascanu, Dan (Dan) [mailto://[email-masked]]

> You can clarify this with text in 3588bis.

I don't know how, without seriously impairing the adoption of 3588bis as the
standard for Diameter.  All in all, this attention to eliminating stress in
(presumably) other SDOs seems misguided...