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

Rakesh and all,

The issue is that the relay application is neither an auth nor an acct 
application, but the protocol only specifies explicit AVPs for 
advertising one or the other. RFC-3588, section 2.4, third paragraph says:

"The receiver of a Capabilities Exchange message advertising Relay 
service MUST assume that the sender supports all current and future 
applications."

"All current and future applications" currently includes auth as well as 
acct applications but the wording here, and at all other references 
within the base-spec, does not make explicit whether the relay id is 
advertised in an Auth-Application-Id AVP or an Acct-Application-Id AVP 
(or even by some other method) but in the same breath indirectly implies 
that it doesn't matter.

So, when advertising relay, should it be made in an Acct-Application-Id 
or an Auth-Application-Id or both?

I also read your question regarding the inconsistency between RFC-3588 
and RFC-3539 and I agree that the architecture is a bit unclear. My 
resolution would be to accept inbound request from and outbound answers 
to a peer once the peer state-machine is in any of its Open states even 
if the Transport state machine has not yet reached Okay, but to disallow 
outbound requests until the Transport state is recovered.

I haven't seen a whole lot of feedback on any of these concerns, but 
perhaps the aaa-wg is not the correct forum. If this is the case, I 
would appreciate if someone could provide more information in that 
regard. Apparently some kind of "trouble-ticket" system exists or 
existed for the Diameter base-spec where information is gathered for a 
potential future errata. Perhaps that is a more appropriate place for 
finding answers and/or raising concerns if it exists. It just seems to 
me that there are several areas that would need stronger clarification 
for implementations to inter-operate across vendor boundaries.
Any information or suggestions would be greatly appreciated.

Best regards,
 Jan Nordqvist


Rakesh Mehta wrote:

> Hi Jan,
>
> Comments on item 1:
>
> I don't know which kind of application are you writing on top of 
> diameter base prorocol. But I have seen some application layer specs 
> provides the details about it. Like Cx interface , please see section 
> 5.6 in 3GPP TS 29.229.
>
> Thanks,
>
> Rakesh
>
>
>
> Jan Nordqvist <[email protected]> wrote:
>
>     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 wit! h 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.
>
>
> ------------------------------------------------------------------------
> Yahoo! for Good
> Click here to donate <http://store.yahoo.com/redcross-donate3/> to the 
> Hurricane Katrina relief effort.