Subject: [AAA-WG]: Issue 261

From: Mark Eklund <[email-masked]>
Date: Mon, 28 Jan 2002 14:25:49 -0500 (EST)

Issue 261 proposes that we specify what peer discovery mechanism is
required.  In particular it requests

   Indicate in the list under 5.2 that the first
   option (manual configuration) MUST be supported
   by all DIAMETER nodes, while the latter two options
   (SRVLOC and DNS SRV records) MAY be supported.

I'm worried that if we do this, someone can't come up with some "plug
and play" Diameter client that has absolutely no configuration and has
the ability to discover the needed peers.  I see no reason to mandate
how a certain Diameter implementation discovers its peers.

For this reason I vote we reject this issue.

-mark

---

From: "Jari Arkko" <[email-masked]>
Date: Mon, 28 Jan 2002 21:47:37 +0200

> how a certain Diameter implementation discovers its peers.

Can you clarify why? I.e. why does this prevent someone coming
up with a Diameter client that does that? You can certainly have
more stuff in the client than the minimal requirements are?

(By the way, we had a discussion since 261 was introduced
that indicated that we should separate implementation support in clients
and the necessary setups in DNS etc. Therefore, if a particular client
does have DNS etc. then he can be assured that he can fetch the
information from the infrastructure.)

Jari

---

From: Mark Eklund <[email-masked]>
Date: Mon, 28 Jan 2002 14:56:56 -0500

> more stuff in the client than the minimal requirements are?

The suggested text says "(manual configuration) MUST be supported".
My above example does not support manual configuration and thus is not
a Diameter complient server.

-mark

---

From: "Jari Arkko" <[email-masked]>
Date: Tue, 29 Jan 2002 07:17:21 +0200

> a Diameter complient server.

Now I think I see the problem. WHat should do, then? I think I see the
following alternatives:

1. Do as proposed in issue 261. If someone wants to make a plug'n'play
    Diameter client, he can do so but he needs to have some dead code
    which isn't normally used but *could* be used if the user didn't want to
    run the automatic mechanism.

2. Make the manual config/dns/svrloc alternatives all MAY, but then
    have a MUST that says at least one of them must be implemented

3. Leave the spec as is, with no keywords. This is roughly equivalent
    to alternative #2, except that it may not be so immediately apparent
    to the reader.

I'm not sure myself what to do. Do you or others have a suggestion?

Jari

---

From: Mark Eklund <[email-masked]>
Date: Tue, 29 Jan 2002 00:52:05 -0500

Jari,

How about option 1.9 (almost option 2)?  Add an initial sentence to
5.2:

*** ../draft-ietf-aaa-diameter.txt	Tue Jan 29 00:44:35 2002
--- 261.txt	Tue Jan 29 00:45:12 2002
*************** 5.1  Peer Connections
*** 2857,2867 ****
  
  5.2  Diameter Peer Discovery
  
!    Allowing for dynamic Diameter agent discovery will make it possible
!    for simpler and more robust deployment of Diameter services.  In
!    order to promote interoperable implementations of Diameter peer
!    discovery, the following mechanisms are described.  These are based
!    on existing IETF standards.
  
     There are two cases where Diameter peer discovery may be performed.
     The first is when a Diameter client needs to discover a first-hop
--- 2857,2870 ----
  
  5.2  Diameter Peer Discovery
  
!    In order to connect to a peer, the Diameter node MUST support at
!    least one of static (manual) configuration, SLPv2 dynamic peer
!    discovery, or DNS dynamic peer discovery.  Allowing for dynamic
!    Diameter agent discovery will make it possible for simpler and more
!    robust deployment of Diameter services.  In order to promote
!    interoperable implementations of Diameter peer discovery, the
!    following mechanisms are described.  These are based on existing IETF
!    standards.
  
     There are two cases where Diameter peer discovery may be performed.
     The first is when a Diameter client needs to discover a first-hop

-mark

---

From: "Jari Arkko" <[email-masked]>
Date: Tue, 29 Jan 2002 09:18:25 +0200

> How about option 1.9 (almost option 2)?  Add an initial sentence to

Works for me. You also need to add language also to require that whatever
is being done implementation-wise, folks need to publish the information
in svrloc/dns in order for the automatic schemes to work, if some node
uses them.

Jari

---

From: Erik Guttman <[email-masked]>
Date: Tue, 29 Jan 2002 13:31:08 +0100

Mark, Jari,

>  > > how a certain Diameter implementation discovers its peers.

261 supports plug & play as an option since SLP is supported.

   Proposed change:

If Diameter servers advertise themselves with SLP
(and they SHOULD), Diameter clients can discover
them (they MAY).

Erik

---

From: David Frascone <[email-masked]>
Date: Tue, 29 Jan 2002 07:57:14 -0600

This approach works for me.

---

From: Mark Eklund <[email-masked]>
Date: Tue, 29 Jan 2002 09:57:58 -0500

Erik,

 >    option (manual configuration) MUST be supported

Why MUST manual configuration be supported?  If I write a server that
that only uses SLP, am I in violation of the RFC because I don't
support manual configuration?

I know, this is a nit, but I am afraid of adding MUSTs that don't seem
needed.

-mark

---

From: Mark Eklund <[email-masked]>
Date: Tue, 29 Jan 2002 10:01:10 -0500

Jari,

 > in svrloc/dns in order for the automatic schemes to work, if some node

Are you saying that we need to add a statement of "If the client uses
DNS to discover the server, the server must be registered in DNS?"
Do we really need to state something that obvious?

-mark

---

From: Erik Guttman <[email-masked]>
Date: Tue, 29 Jan 2002 16:17:15 +0100 (MET)

> I know, this is a nit, but I am afraid of adding MUSTs that don't seem

Mark,

Either a Diameter client MUST support manual config
or a Diameter server MUST support SLP.  Otherwise,
you will have a situation where the client needs
to use SLP and the servers don't advertise themselves
with SLP, or need to use DNS and find that no DNS SRV
RRs exist. Then the operator will be hosed.

In practice, don't most RADIUS servers get configured
manually?  Shouldn't we assume Diameter deployments
will follow the same pattern as RADIUS?

Please note that just because manual config is supported
doesn't mean that it has to be used.  One could have a 
plug and play Diameter client which, optionally, can
take manual config.  Consider plug and play appliances.
You only have to manually configure (ie. to a different
voltage) them when you cross an ocean :-)  Most of the
time you never need to do this, but if you didn't have
the switch, you'd be hosed.

Erik

---

From: Steve Rich <[email-masked]>
Date: Tue, 29 Jan 2002 10:19:20 -0500

Mark,

I think it's a good idea to add it.  Often times, a little direction
can go a long way, especially if the implementor isn't an expert in
this area (DNS, etc.).

sjr

---

From: Erik Guttman <[email-masked]>
Date: Tue, 29 Jan 2002 16:23:05 +0100 (MET)

> Do we really need to state something that obvious?

I think we should say:
Diameter clients MUST be manually configurable.
Diameter servers SHOULD advertise themselves via SLP [RFC2608][RFC2614]
Diameter servers SHOULD be represented by DNS SRV RR entries in DNS.
[RFC2782]
Diameter clients MAY use SLP or DNS SRV RRs to obtain the location
of Diameter servers.

The specifics of how to use DNS or SLP to make service locations 
available to clients can be left out of the Diameter spec, as it
is covered in the cited specifications.

Erik

---

From: "Jari Arkko" <[email-masked]>
Date: Tue, 29 Jan 2002 17:25:53 +0200

> Do we really need to state something that obvious?

I believe this relates to the discussion some weeks or months back,
when someone stated that it would be useful to distinguish (a) must implement
and (b) must register to foobar. To take your particular example, we could
say that you MUST register the server to the DNS regardless of whether
you employ DNS discovery mechanism or not.

So if I remember correctly we concluded back then that this was a good
thing. I'm not sure if that was the right conclusion, but I'm just trying to
describe what we wanted to do at that time...

Jari

---

From: Mark Eklund <[email-masked]>
Date: Tue, 29 Jan 2002 10:32:42 -0500

Erik,

I know when I'm beat :)

 > Diameter clients MAY use SLP or DNS SRV RRs to obtain the location

If everyone is in agreement with the above, I'll work on the changes
and send out the diffs.

-mark

---

From: Randy Bush <[email-masked]>
Date: Tue, 29 Jan 2002 08:13:27 -0800

> can go a long way, especially if the implementor isn't an expert in

then we should tell them to be sure it's an A or AAAA resource record,
recommend TTLs, ...?  :-)

seems to me that it is best to incorporate by reference, not explicit
copy.

randy

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 29 Jan 2002 08:51:51 -0800 (PST)

There are two distinct issues here. One is what Diameter Servers need to
do to register. The other is the discovery sequence for Diameter clients. 

We have been modelling the Diameter client discovery sequence after the
SIP location draft, draft-ietf-sip-srv-0x.txt, since this is already
undergoing IESG review.

The presumption has been that there will not be any single mandatory
registration mechanism for servers, which is part of the reason that the
client discovery sequence is so important.