Subject: [Dime] Updated errata draft for RFC 3588bis

From: Victor Fajardo <[email-masked]>
Date: Tue, 14 Nov 2006 16:34:34 -0500

Hi all,

An updated version of diameter errata draft can be found in:

http://www.opendiameter.org/public/draft-fajardo-dime-diameter-errata-01.txt

This version includes the comments and decisions made during IETF67 DIME 
meeting. Note that all open issues now have proposed solutions. Pls 
review them so we can move forward.

best regards,
victor

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

---

From: Jan Nordqvist <[email-masked]>
Date: Wed, 15 Nov 2006 14:19:40 -0800

Sorry if this got duplicated, my email source address has changed.

Another suggestion for something to be include in the draft would be to
replace that absolutely horrible section 5.6.4 in 3588.
How about something like this:

5.6.4. The Election Process

The election is performed on the responder. The responder compares the
Origin-Host received in the CER with its own Origin-Host
as two streams of octets. If the local Origin-Host lexicographically
succeeds the received Origin-Host a Win-Election event is
issued locally.
To be consistent with DNS case insensitivity, octets that fall in the
ASCII range 'a' through 'z' MUST compare equal to their upper-case
counterparts between 'A' and 'Z', i.e. value 0x41 compares equal to
0x61, 0x42 to 0x62 and so forth up to and including
0x5a and 0x7a.

Victor Fajardo wrote:
> This version includes the comments and decisions made during IETF67 
> DIME meeting. Note that all open issues now have proposed solutions. 
> Pls review them so we can move forward.
>
> best regards,
> victor
>

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 15 Nov 2006 17:23:11 -0500

Good point. I'll updated the tracker.

> Another suggestion for something to be include in the draft would be 
> to replace that absolutely horrible section 5.6.4 in 3588.

---

From: Rajith R <[email-masked]>
Date: Thu, 16 Nov 2006 13:43:22 +0530

(1) Some typo/exclusion:
2.11.2.  Text Changes

      ...

      --------------------------------------------------
      Proposed Changes, Sec 11.3, 4th Paragraph, Ver-00:
      --------------------------------------------------

      Both Auth-Application-Id and Acct-Application-Id AVPs use the
      same Application Identifier space. A diameter node advertising
      itself as a relay agent MUST set either Application-Id or 

Change to (the phrase "either Application-Id or" in the last line to be
changed to "either Auth-Application-Id or")

2.11.2.  Text Changes

      ...

      --------------------------------------------------
      Proposed Changes, Sec 11.3, 4th Paragraph, Ver-00:
      --------------------------------------------------

      Both Auth-Application-Id and Acct-Application-Id AVPs use the
      same Application Identifier space. A diameter node advertising
      itself as a relay agent MUST set either Auth-Application-Id or

(2) I have the following comment on Predictive loop avoidance

6.1.7.  Predictive Loop Avoidance

        Before forwarding or routing a request, Diameter agents, in
        addition to processing done in Section 6.1.3, SHOULD check
        for the presence of candidate route's peer identity in any
        of the Route-Record AVPs. In an event of the agent detecting
        the presence of a candidate route's peer identity in a
        Route-Record AVP, the agent MUST ignore such route for the
        Diameter request message and attempt alternate routes if any.

>> [Rajith]: I suppose in the request forward case, on loop prediction, 
the agent SHOULD return DIAMETER_UNABLE_TO_DELIVER message. Right? So, 
I suggest this mechanism be used only in Request Routing case.

        In case all the candidate routes are eliminated by the above
        criteria, the agent SHOULD return DIAMETER_UNABLE_TO_DELIVER
        message.

Rajith

>-----Original Message-----
>From: Victor Fajardo [mailto:[email-masked]] 
>Sent: Wednesday, November 15, 2006 3:05 AM
>To: [email-masked]
>Subject: [Dime] Updated errata draft for RFC 3588bis
>
>Hi all,
>
>This version includes the comments and decisions made during 
>IETF67 DIME meeting. Note that all open issues now have 
>proposed solutions. Pls review them so we can move forward.
>
>best regards,
>victor
>

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 16 Nov 2006 09:59:50 -0500

Hi Rajith,

> 2.11.2.  Text Changes

ok. thanks.

> 2.11.2.  Text Changes

Yes. This has always been the case as stated in the first sentence of 
this paragraph.

best regards,
victor

---

From: Victor Fajardo <[email-masked]>
Date: Sun, 19 Nov 2006 10:13:46 -0500

Ok. Thanks.

For non-technical issues such as these (and others previously reported), 
I've directly updated the errata draft. The latest version is in:

best regards,
victor

> Here's another...
> Section 5.5.2
> Original-State-Id should be Origin-State-Id in the DWA ABNF.
>
>
> Glenn McGregor
> Lucent Technologies