Subject: [AAA-WG]: Issue #253

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

As long as no one has objections, I plan to commit issue #253 to the
base.  The changes are the same as the issue listed in
http://www.drizzle.com/~aboba/AAA/issues.html#Issue #253.  The diffs
are listed below.

*** ../draft-ietf-aaa-diameter.txt	Mon Jan 28 12:34:49 2002
--- 253.txt	Mon Jan 28 12:35:25 2002
*************** 5.2  Diameter Peer Discovery
*** 2899,2910 ****
           and only those will be discovered.
  
        3. The Diameter implementation uses DNS to request the SRV RR [33]
!          for the '_diameter._sctp' and/or '_diameter._tcp' server in a
!          particular realm.  The Diameter implementation has to know in
!          advance which realm to look for a Diameter agent in.  This
!          could be deduced, for example, from the 'realm' in a NAI that a
!          Diameter implementation needed to perform a Diameter operation
!          on.
  
          3.1 If the destination address is a numeric IP address, the
              requestor contacts the peer at the given address and the
--- 2899,2912 ----
           and only those will be discovered.
  
        3. The Diameter implementation uses DNS to request the SRV RR [33]
!          for the '_diameter-tls._sctp' and/or '_diameter-tls._tcp' in a
!          particular realm, as well as the '_diameter._sctp' and/or
!          '_diameter._tcp' servers. If records corresponding to the TLS
!          ports are found, the Diameter peer is assumed to support TLS.
!          The Diameter implementation has to know in advance which realm
!          to look for a Diameter agent in.  This could be deduced, for
!          example, from the 'realm' in a NAI that a Diameter
!          implementation needed to perform a Diameter operation on.
  
          3.1 If the destination address is a numeric IP address, the
              requestor contacts the peer at the given address and the
*************** 5.2  Diameter Peer Discovery
*** 2923,2948 ****
          3.3 If there are no SRV records, the requestor queries the DNS
              server for address records for the destination address
              '_diameter._sctp'.realm or '_diameter._tcp'.realm. Address
!             records include A RR's, AAAA RR's, A6 RR's or other similar
!             records, chosen according to the requestor's network
!             protocol capabilities.
  
              If the DNS server returns no address records, the requestor
              gives up. If there are address records, the same rules as in
              step 3.2 apply.
--- 2925,2949 ----
          3.3 If there are no SRV records, the requestor queries the DNS
              server for address records for the destination address
              '_diameter._sctp'.realm or '_diameter._tcp'.realm. Address
!             records include A RRs, AAAA RRs or other similar records,
!             chosen according to the requestor's network protocol
!             capabilities.
  
              If the DNS server returns no address records, the requestor
              gives up. If there are address records, the same rules as in
              step 3.2 apply.

-mark

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 28 Jan 2002 22:53:38 -0800

Mark Eklund [mailto:[email-masked]] writes:

> base.

There are a couple of problems with this statement, which I think may have
some bearing upon the activity and rather glacial progress of the AAA WG.
First of all, I have no idea why the editor of the document is deciding what
changes are to be made to it, especially "as long as no one has any
objections".  My understanding is that in the IETF the WG Chair(s) gauge the
_rough consensus_ of the WG & instruct the document editor to modify the WG
documents accordingly.  AFAIK, rough consensus is _not_ the same as "no
objections".  Secondly, it seems (correct me if I'm wrong) that issues get
added to the issues list with little or no analysis, which results in
(sometimes lengthy) debate over "issues" that have been already resolved
(sometimes months or years in the past) or are simply features from
someone's wish list.  So, what I'm saying is that I think that we need much
more "leadership" from the chairs, in order to get this work done in this
decade...

~gwz

Glen Zorn
CTO Consulting Engineer
Security and Integrity Group
Consulting Engineering
Cisco Systems

PGP Key Fingerprint: 4F41 B93A 007D E2FC 9769  FB97 FBCF 7DA4 9A2D 1963