Re: : Advertising relay application-id and the election process.

Timothy Smith <[email protected]> Thu, 8 Sep 2005 06:31:19 -0600
Newsgroups gmane.ietf.aaa
Message-ID <OFF73F7FF7.F2877112-ON87257076.0043E647-85257076.0044B648@us.ibm.com>
Jan,

I do share your confusion on item 2.  I like your phrasing, and I think 
that it is unambiguous.

"The two OctetStrings are compared byte by byte, starting with the 
left-most byte of each OctetString and stopping at either the first
differing octet or at the end of one or both OctetStrings. If a differing 
octet is encountered, the OctetString containing
the byte with a higher unsigned value is considered higher, otherwise the 
longer of the two OctetStrings is considered higher."

I was also confused by the padding of '0's and the remaining octets 
assumption of 0x'80'.  I agree that your version yields the same result as 
what I interpret RFC 3588 to yield.  But, of course, I would like to see 
the one or more of the authors agree...

Best Regards,
Timothy Smith

[email protected]
(919) 254-4723




Jan Nordqvist <[email protected]> 
Sent by: [email protected]
09/07/2005 02:28 PM

To
[email protected]
cc

Subject
[AAA-WG]: Advertising relay application-id and the election process.






Hi all,

I have two questions for the group in regards to the Diameter base 
protocol:

1. Has there been any discussion within the group as to what AVP to use 
when advertising the Relay application ID in CEA/CER's?
RFC-3588 only states that the relay application may be advertised, but 
not by what means.

2. A totally different and unrelated issue is in regards to the election 
process, more specifically the Origin-Host comparison described in 
RFC-3588 section 5.6.4. Quote from the RFC:

   The election is performed on the responder.  The responder compares
   the Origin-Host received in the CER sent by its peer with its own
   Origin-Host.  If the local Diameter entity's Origin-Host is higher
   than the peer's, a Win-Election event is issued locally.

   The comparison proceeds by considering the shorter OctetString to be
   padded with zeros so that it length is the same as the length of the
   longer, then performing an octet-by-octet unsigned comparison with
   the first octet being most significant.  Any remaining octets are
   assumed to have value 0x80.

The text is very confusing and contradicting: The statement about padding 
in the second paragraph mentions nothing about where the padding
is applied, i.e. to the right, left or possibly some other method. Then, 
in the second sentence, it is stated that any remaining octets are
assumed to contain the value 0x80. How can there be any remaining octets 
when the lengths are made the same through padding?

Would it be reasonable to assume that the following intuitive 
interpretation is valid:

"The two OctetStrings are compared byte by byte, starting with the 
left-most byte of each OctetString and stopping at either the first
differing octet or at the end of one or both OctetStrings. If a differing 
octet is encountered, the OctetString containing
the byte with a higher unsigned value is considered higher, otherwise the 
longer of the two OctetStrings is considered higher."

Feedback most appreciated,
 Jan Nordqvist, Lucent Technologies.