Subject: [AAA-WG]: issue:236: DiameterIdentity

From: Michael Chen <[email-masked]>
Date: Mon, 19 Nov 2001 11:30:05 -0800

Hi

    Please reopen issue 236

Rationale/Explanation of issue:
            As we know, the diameter identity format is
            Diameter-Identity  = "aaa://" fqdn [ port ] [ transport ]
                                 [ protocol ] [ transport-security ]
             an example could be
aaa://a.c.com:TBD;protocol=diameter;transport=sctp;
transport-security=none.
             but we didn't define string ";transport-security" in the
ABNF.

Requested change:

            security = ( "none" | "TLS" )
            transport-security = ";transport-security" security
                                ; Specifies whether TLS [or other future

                                 ; transport layer mechanisms supported]
is
                                 ; to be used when communicating with
the
                                 ; peer. The default value is none.

---

From: Michael Chen <[email-masked]>
Date: Mon, 19 Nov 2001 11:48:34 -0800

Submitter name: Michael Chen
Submitter email address: [email-masked]
Date first submitted: 19-Nov-01
Reference:
Document: base-08
Comment type: E
Priority: 1
Section:  Base: 5.4.3

Rationale/Explanation of issue:
         DPR is not sent to its peer when lost the election so ELECTION_LOST
result code is not used.

Requested change:
         Remove this result code.

---

From: "Fredrik Johansson" <[email-masked]>
Date: Tue, 20 Nov 2001 08:37:03 +0100

Michel,

Wasn't this result code intended to be sent in the CEA of the connection that
lost?

/fredrik
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of Michael
Chen
  Sent: den 19 november 2001 20:49
  To: [email-masked]
  Subject: [AAA-WG]: [issue:] ELECTION_LOST result code

  Requested change:
           Remove this result code.

---

From: Michael Chen <[email-masked]>
Date: Tue, 20 Nov 2001 09:25:28 -0800

Fredrik,

    Please correct me if I am wrong.
    This result code, ELECTION_LOST,  is defined in 5.4.3
Disconnect-Cause AVP which is used for DPR.
    In the DER message, winner must disconnect the Initiator connection
and send back CEA so we don't
    need this result code.

-Michael

Fredrik Johansson wrote:

>  Michel,Wasn't this result code intended to be sent in the CEA of the
> connection that lost?/fredrik
>
>      From: [email-masked]
>      [mailto:[email-masked]]On Behalf Of Michael Chen
>               DPR is not sent to its peer when lost the election
>      so ELECTION_LOST result code is not used.
>
>      Requested change:
>               Remove this result code.
>
>

---

From: "Fredrik Johansson" <[email-masked]>
Date: Wed, 21 Nov 2001 16:26:28 +0100

your right, the LOST_ELECTION should not be available in 5.4.3

However, correct me if I'm wrong, but didn't we decide during the interop that
instead of sending a DPR on the connection that lost we would just return a CEA
with result code LOST_ELECTION. i.e. the connection will be taken down, the other
connection that won the election will have a CEA with a result code indicating
SUCCESS sent.

If this is the case, there is a result code missing and probably some text in the
state machine

/fredrik
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of Michael
Chen
  Sent: den 20 november 2001 18:25
  To: Fredrik Johansson
  Cc: [email-masked]
  Subject: Re: [AAA-WG]: [issue:] ELECTION_LOST result code

  Fredrik,

      Please correct me if I am wrong.
      This result code, ELECTION_LOST,  is defined in 5.4.3 Disconnect-Cause AVP
which is used for DPR.
      In the DER message, winner must disconnect the Initiator connection and send
back CEA so we don't
      need this result code.
  -Michael

  Fredrik Johansson wrote:

      -----Original Message-----
      From: [email-masked] [mailto:[email-masked]]On Behalf Of
Michael Chen
      Sent: den 19 november 2001 20:49
      To: [email-masked]
      Subject: [AAA-WG]: [issue:] ELECTION_LOST result code

      Requested change:
               Remove this result code.

---

From: Michael Chen <[email-masked]>
Date: Wed, 21 Nov 2001 10:29:18 -0800

During the interop test, we did decide NOT to send DPR if the node lost
election.   From Pat's email reply to Issue 208
Subject: Re: [AAA-WG]: Issue 208: Peer State Machine incorrect in case
of election
Date: Sat, 3 Nov 2001
Nobody reject this email so it should be our consensus which is Winner
send CEA whose result code is success and disconnect the Initiator
connection. The node lost election just drop the R connection and do
NOT  send CEA. To sum up, the current state machine in the latest draft
looks good to me. I still think we need remove ELECTION_LOST result
code.    Comments?

-Michael

Fredrik Johansson wrote:

>  your right, the LOST_ELECTION should not be available in
> 5.4.3However, correct me if I'm wrong, but didn't we decide during the
> interop that instead of sending a DPR on the connection that lost we
> would just return a CEA with result code LOST_ELECTION. i.e. the
> connection will be taken down, the other connection that won the
> election will have a CEA with a result code indicating SUCCESS sent.If
> this is the case, there is a result code missing and probably some
> text in the state machine/fredrik
>
>          In the DER message, winner must disconnect the Initiator
>      connection and send back CEA so we don't
>          need this result code.
>
>      -Michael
>
>
>      Fredrik Johansson wrote:
>
>     > Michel,Wasn't this result code intended to be sent in the
>     > CEA of the connection that lost?/fredrik
>     >
>     >               DPR is not sent to its peer when lost
>     >      the election so ELECTION_LOST result code is not
>     >      used.
>     >
>     >      Requested change:
>     >               Remove this result code.
>     >
>     >

---

From: Johan Johansson <[email-masked]>
Date: Thu, 22 Nov 2001 14:52:02 +0100

I must have missed that email, but I am quite certain that what we 
agreed upon at the bake-off was to send a CEA with an ELECTION_LOST 
result code. Of course this is not strictly speaking necessary since the 
combination of getting a SUCCESS result code on the other connection and 
the losing connection being terminated will convey the same information. 
Nevertheless, if my memory is not trying to be creative again, we 
decided to replace the DPR with an ELECTION_LOST CEA.

j

Michael Chen wrote:

> During the interop test, we did decide NOT to send DPR if the node 
> lost election.   From Pat's email reply to Issue 208
> NOT  send CEA. To sum up, the current state machine in the latest 
> draft looks good to me. I still think we need remove ELECTION_LOST 
> result code.    Comments?
>
> -Michael
>  
>  
>  
>
> Fredrik Johansson wrote:
>
>> However, correct me if I'm wrong, but didn't we decide during the 
>> election will have a CEA with a result code indicating SUCCESS sent. 
>> If this is the case, there is a result code missing and probably some 
>> text in the state machine /fredrik
>>
>>     *From:* [email-masked] [mailto:[email-masked]
>>     ]*On Behalf Of *Michael Chen
>>     *Sent:* den 20 november 2001 18:25
>>     *To:* Fredrik Johansson
>>     *Cc:* [email-masked]
>>     *Subject:* Re: [AAA-WG]: [issue:] ELECTION_LOST result code
>>      
>>
>>     Fredrik,
>>
>>>     Michel, Wasn't this result code intended to be sent in the CEA
>>>     of the connection that lost? /fredrik
>>>
>>>         *From:* [email-masked]
>>>         [mailto:[email-masked] ]*On Behalf Of *Michael Chen
>>>         *Sent:* den 19 november 2001 20:49
>>>         *To:* [email-masked]
>>>         *Subject:* [AAA-WG]: [issue:] ELECTION_LOST result code
>>>

---

From: Pat Calhoun <[email-masked]>
Date: Sun, 25 Nov 2001 08:23:34 -0800

ack. I've fixed it in for the -09 draft.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Sun, 25 Nov 2001 08:25:58 -0800

This was my recollection as well (hence the result code), and I really
don't recall sending the text quoted by Michael :(

PatC

---

From: Michael Chen <[email-masked]>
Date: Sun, 25 Nov 2001 14:30:22 -0800

Pat,

The email can be found in the Archive wed page:
http://www.merit.edu/mail.archives/html/aaa-wg/2001-11/msg00015.html

By the way, sending either CEA with ELECTION_LOST then disconnect or just
disconnect without sending CEA work for me.  As long as it's clear stated in
the draft.

-Michael

---

From: Johan Johansson <[email-masked]>
Date: Mon, 26 Nov 2001 17:04:18 +0100

Just a reflection: isn't the ip and the port sufficient as identifier 
and the rest is just configuration passed around in the URI?

j

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 26 Nov 2001 08:19:10 -0800

no. The protocol and security are really needed to connect to the peer.

PatC

---

From: Johan Johansson <[email-masked]>
Date: Tue, 27 Nov 2001 02:03:16 +0100

Of course they are, as is a shared secret and commonly a realm, but 
they're not part of the uri. They are configured in the surrounding 
peers. They also do not identify the peer and I'm not sure the security 
does either. Can you really run both TLS and non-TLS connections on the 
same port? Whether a node is using tcp or sctp or TLS is of no interest 
what so ever to other than its peers, and yet it is sent in all messages 
to other domains.

Routing is done using information that is not inherently more or less 
stable than security mechanism - supported applications - and they are 
not part of the URI either. In fact we just devised a mechanism by which 
this information can be updated without tearing down connections and in 
doing so validating or invalidating routes.

What I am trying to get to in a rather roundabout way is that there is a 
lot of information that you need to contact a certain node. The 
identifier should ... well.. identify it. Some information will 
inevitably need to be preconfigured or discovered by surrounding peers. 
Note that the uri itself will need to be part of the configuration of 
the surrounding peers, and thus the uri really only decides a form that 
you can use to configure TLS, protocol and so on.

This doesn't of course stop the protocol from working, and if you think 
you have all the parameters in it now that will ever be needed - fine. 
As long as there's an upper bound on the length of a uri I'm reasonably 
content.

j

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 28 Nov 2001 18:17:42 -0800

> what so ever to other than its peers, and yet it is sent in all messages 

no you cannot run both TLS and non-TLS on both ports, and the base spec
states that it requires two ports.

> As long as there's an upper bound on the length of a uri I'm reasonably 

Pardon the ignorance here... but my parser broke two paragraphs ago. I believe
what you are stating here is that the URI is not sufficient, but it isn't
clear what is missing. Folks that have implemented the protocol seem to
think that it is enough. 

Could you be a tad more specific on what you believe is missing?

PatC