Re: [Dime] [Fwd: draft-ietf-dime-rfc3588bis review (1/3)]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Dime] [Fwd: draft-ietf-dime-rfc3588bis review (1/3)]
Hi Hannes,
I've incorporated majority of the editorial items you mentioned below.
Others I've commented below. The changes here should be incorporated
into draft*-13.txt
s/The base Diameter protocol is run on port 3868 of both TCP [RFC793] and
SCTP [RFC2960] transport protocols./The base Diameter protocol is run on
port
3868 of both TCP [RFC793] and SCTP [RFC2960].
Delete "Future versions of this specification MAY
mandate that clients support SCTP."
I also do not understand why we require that agents and servers must
support
SCTP. That does not sound realistic if I consider our interop testing
experience.
It seems expected that during the interop most folks would support TCP
since that would be the easiest/most natural to implement first. I could
not remember if there was consensus for requiring SCTP for servers was
impractical. I would think that at this point (a few years after the
interop) SCTP support would be generally supported (??) by most diameter
implementations. I'm ok with relaxing the rule if folks think that
required support for SCTP is really cumbersome. AFAIK, supporting SCTP
should be readily available on most stacks and socket APIs.
2.8.1. Relay Agents
s/
Relays MAY be used to aggregate requests from multiple Network Access
Servers (NASes) within a common geographical area (POP).
/
Relays may, for example, be used to aggregate requests from multiple
Network Access Servers (NASes) within a common geographical area (POP).
I think we can deleteFrom dime-bounces at ietf.org Sun Nov 2 05:54:11 2008
Return-Path: <dime-bounces at ietf.org>
X-Original-To: dime-archive at megatron.ietf.org
Delivered-To: ietfarch-dime-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id D5F8A3A6933;
Sun, 2 Nov 2008 05:54:11 -0800 (PST)
X-Original-To: dime at core3.amsl.com
Delivered-To: dime at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 3A3DE3A6933
for <dime at core3.amsl.com>; Sun, 2 Nov 2008 05:54:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.444
X-Spam-Level:
X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5
tests=[AWL=-0.156, BAYES_00=-2.599, HOST_MISMATCH_COM=0.311]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 7OmLg5HDIH2B for <dime at core3.amsl.com>;
Sun, 2 Nov 2008 05:54:06 -0800 (PST)
Received: from toshi17.tari.toshiba.com (unknown
[IPv6:2001:418:1403:0:212:17ff:fe52:7811])
by core3.amsl.com (Postfix) with ESMTP id 46B703A6927
for <dime at ietf.org>; Sun, 2 Nov 2008 05:54:06 -0800 (PST)
Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12])
by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id
mA2Ds08x033895; Sun, 2 Nov 2008 08:54:00 -0500 (EST)
(envelope-from vfajardo at tari.toshiba.com)
Message-ID: <490DB0F7.7050308 at tari.toshiba.com>
Date: Sun, 02 Nov 2008 08:53:59 -0500
From: Victor Fajardo <vfajardo at tari.toshiba.com>
User-Agent: Icedove 1.5.0.14eol (X11/20080724)
MIME-Version: 1.0
To: Hannes Tschofenig <Hannes.Tschofenig at gmx.net>
References: <48C92258.6050008 at gmx.net>
In-Reply-To: <48C92258.6050008 at gmx.net>
Cc: dime at ietf.org
Subject: Re: [Dime] [Fwd: draft-ietf-dime-rfc3588bis review (1/3)]
X-BeenThere: dime at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dime>,
<mailto:dime-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dime>
List-Post: <mailto:dime at ietf.org>
List-Help: <mailto:dime-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>,
<mailto:dime-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: dime-bounces at ietf.org
Errors-To: dime-bounces at ietf.org
Hi Hannes,
I've incorporated majority of the editorial items you mentioned below.
Others I've commented below. The changes here should be incorporated
into draft*-13.txt
s/The base Diameter protocol is run on port 3868 of both TCP [RFC793] and
SCTP [RFC2960] transport protocols./The base Diameter protocol is run on
port
3868 of both TCP [RFC793] and SCTP [RFC2960].
Delete "Future versions of this specification MAY
mandate that clients support SCTP."
I also do not understand why we require that agents and servers must
support
SCTP. That does not sound realistic if I consider our interop testing
experience.
It seems expected that during the interop most folks would support TCP
since that would be the easiest/most natural to implement first. I could
not remember if there was consensus for requiring SCTP for servers was
impractical. I would think that at this point (a few years after the
interop) SCTP support would be generally supported (??) by most diameter
implementations. I'm ok with relaxing the rule if folks think that
required support for SCTP is really cumbersome. AFAIK, supporting SCTP
should be readily available on most stacks and socket APIs.
2.8.1. Relay Agents
s/
Relays MAY be used to aggregate requests from multiple Network Access
Servers (NASes) within a common geographical area (POP).
/
Relays may, for example, be used to aggregate requests from multiple
Network Access Servers (NASes) within a common geographical area (POP).
I think we can delete this se this sentence since it essentially reflects the
which sentence ?
definition of a relay:
Relays SHOULD NOT maintain session state but MUST maintain
transaction state.
If you meant the example, then it maybe better to keep it to have a
clear re-enforcement of the relay definition; i.e. giving examples is
helpful.
Proxies that wish to limit resources MUST maintain session state.
All proxies MUST maintain transaction state.
I don't really understand what the first sentence should tell us and the
2nd
one is essentially already described with the definition of the proxy.
Agree. I've removed it.
Some AVPs MAY be listed more than once. The effect of such an AVP is
specific, and is specified in each case by the AVP description.
There is something wrong with this sentence.
Agree. Not sure what exactly its trying to say but its implying
something really vague ... better remove it.
4.3. Derived AVP Data Formats
In addition to using the Basic AVP Data Formats, applications may
define data formats derived from the Basic AVP Data Formats. An
application that defines new AVP Derived Data Formats MUST include
them in a section entitled "AVP Derived Data Formats", using the same
format as the definitions below. Each new definition MUST be either
defined or listed with a reference to the RFC that defines the
format.
This is sort of interesting, particularly when you look at the
IPFilterRule,
as the boundary between Derived AVP Data Formats and AVP definitions is
sort
of fuzzy.
Does any other Diameter document ever tried to define new derived Data
Formats?
Not sure. Low probability that other docs would have a derived Data
format section.
4.4. Grouped AVP Values
However, the encapsulated AVPs with 'M' (mandatory) bit set MUST
belong to the Diameter application the Grouped APV is used in.
I don't quite understand that sentence. Could you explain it a bit?
This was Lionels description. If I'm translating correctly I think it
meant that inner AVPs with M-bit set must be defined or at the least
known by the Diameter application using the grouped avp. Does this mean
the app has the possibility of not recognizing the parent AVP but it has
knowledge about the children AVPs ? Would it be better to just make this
'M' bit check relevant to the root Grouped-AVP ?
3. If no NAPTR records are found, the requester queries for those
address records for the destination address,
'_diameter._sctp'.realm or '_diameter._tcp'.realm.
Why is it necessary to specify two mechanisms to query the DNS?
I will distribute a separate mail about the domain certificate stuff.
Ok.
5.3.5. Host-IP-Address AVP
The Host-IP-Address AVP (AVP Code 257) is of type Address and is used
to inform a Diameter peer of the sender's IP address. All source
addresses that a Diameter node expects to use with SCTP [RFC2960]
MUST be advertised in the CER and CEA messages by including a
Host-IP- Address AVP for each address. This AVP MUST ONLY be used in
the CER and CEA messages.
s/Host-IP- Address/Host-IP-Address
I wonder why there is the last sentence in there? It is fine to use the AVP
in the CER and CEA message but why is there a need to say that it must only
be used there? That does not make a lot of sense.
good point. it should be removed.
5.3.6. Supported-Vendor-Id AVP
Multiple instances of this AVP containing the same value SHOULD NOT
be sent.
Why not MUST NOT be sent?
agree as well. it should be MUST NOT.
I was also wondering why only a selection of AVPs is listed in Section 5.3
instead of all of them? Any special reason?
I think all of the AVPs in 5.3 maybe represented/listed but just spread
throughtout the document.
5.5.4. Failover and Failback Procedures
Shouldn't it actually read "Fallback" instead of failback?
AFAIK, I think it the term for servicntence since it essentially reflects the
which sentence ?
definition of a relay:
Relays SHOULD NOT maintain session state but MUST maintain
transaction state.
If you meant the example, then it maybe better to keep it to have a
clear re-enforcement of the relay definition; i.e. giving examples is
helpful.
Proxies that wish to limit resources MUST maintain session state.
All proxies MUST maintain transaction state.
I don't really understand what the first sentence should tell us and the
2nd
one is essentially already described with the definition of the proxy.
Agree. I've removed it.
Some AVPs MAY be listed more than once. The effect of such an AVP is
specific, and is specified in each case by the AVP description.
There is something wrong with this sentence.
Agree. Not sure what exactly its trying to say but its implying
something really vague ... better remove it.
4.3. Derived AVP Data Formats
In addition to using the Basic AVP Data Formats, applications may
define data formats derived from the Basic AVP Data Formats. An
application that defines new AVP Derived Data Formats MUST include
them in a section entitled "AVP Derived Data Formats", using the same
format as the definitions below. Each new definition MUST be either
defined or listed with a reference to the RFC that defines the
format.
This is sort of interesting, particularly when you look at the
IPFilterRule,
as the boundary between Derived AVP Data Formats and AVP definitions is
sort
of fuzzy.
Does any other Diameter document ever tried to define new derived Data
Formats?
Not sure. Low probability that other docs would have a derived Data
format section.
4.4. Grouped AVP Values
However, the encapsulated AVPs with 'M' (mandatory) bit set MUST
belong to the Diameter application the Grouped APV is used in.
I don't quite understand that sentence. Could you explain it a bit?
This was Lionels description. If I'm translating correctly I think it
meant that inner AVPs with M-bit set must be defined or at the least
known by the Diameter application using the grouped avp. Does this mean
the app has the possibility of not recognizing the parent AVP but it has
knowledge about the children AVPs ? Would it be better to just make this
'M' bit check relevant to the root Grouped-AVP ?
3. If no NAPTR records are found, the requester queries for those
address records for the destination address,
'_diameter._sctp'.realm or '_diameter._tcp'.realm.
Why is it necessary to specify two mechanisms to query the DNS?
I will distribute a separate mail about the domain certificate stuff.
Ok.
5.3.5. Host-IP-Address AVP
The Host-IP-Address AVP (AVP Code 257) is of type Address and is used
to inform a Diameter peer of the sender's IP address. All source
addresses that a Diameter node expects to use with SCTP [RFC2960]
MUST be advertised in the CER and CEA messages by including a
Host-IP- Address AVP for each address. This AVP MUST ONLY be used in
the CER and CEA messages.
s/Host-IP- Address/Host-IP-Address
I wonder why there is the last sentence in there? It is fine to use the AVP
in the CER and CEA message but why is there a need to say that it must only
be used there? That does not make a lot of sense.
good point. it should be removed.
5.3.6. Supported-Vendor-Id AVP
Multiple instances of this AVP containing the same value SHOULD NOT
be sent.
Why not MUST NOT be sent?
agree as well. it should be MUST NOT.
I was also wondering why only a selection of AVPs is listed in Section 5.3
instead of all of them? Any special reason?
I think all of the AVPs in 5.3 maybe represented/listed but just spread
throughtout the document.
5.5.4. Failover and Failback Procedures
Shouldn't it actually read "Fallback" instead of failback?
AFAIK, I think it the term for service restore restoration has always been failback.
6.1.2. Sending a Request
When sending a request, originated either locally, or as the result
of a forwarding or routing operation, the following procedures MUST
be followed:
o the Hop-by-Hop Identifier should be set to a locally unique value.
s/should/SHOULD
o The message should be saved in the list of pending requests.
s/should/SHOULD
Given that the introductory sentence says "MUST be followed" I was
wondering
whether SHOULD is actually too weak here.
Then I think the introductory sentence should be set to SHOULD instead
of MUST because these recommendations have obvious "preference "
constraints from the implementor; i.e. implementations my choose not to
store all pending request because of storage constraints.
6.7.2. Proxy-Info AVP
The description for the AVP does not describe the semantic.
Ok. How about modifying the 1st paragraph to:
"The Proxy-Info AVP (AVP Code 284) is of type Grouped. This AVP
contains the identity and local state information of Diameter node
that creates and adds it to a message. The Grouped Data field
has the
following ABNF grammar:"
6.7.4. Proxy-State AVP
s/
The Proxy-State AVP (AVP Code 33) is of type OctetString, and
contains state local information, and MUST be treated as opaque data.
/
The Proxy-State AVP (AVP Code 33) is of type OctetString, and
is created by the Diameter server and passed on to the Diameter
client. It contains state information that would otherwise be stored at
the Diameter.
As such, this AVP MUST be treated as opaque data by entities other
than the Diameter server that created it.
Proxy-State AVP can be created and inserted by proxies as well (not only
servers). So we should rephrase the 1st sentence of your suggestion to:
"The Proxy-State AVP (AVP Code 33) is of type OctetString. It
contains state information that would otherwise be stored at
the Diameter entity that created it. As such, this AVP MUST be
treated as opaque data by entities other Diameter entities."
6.8. Auth-Application-Id AVP
The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and
is used in order to advertise support of the Authentication and
Authorization portion of an application (see Section 2.4). If
present in a message other than CER and CEA, the value of the Auth-
Application-Id AVP MUST match the Application Id present in the
Diameter message header.
If it always matches then does it make a lot of sense?
Yes. This has a lot of history at the interop since there's confusion on
what these Id's really represent or what its purpose was given that
there's already and id in the header. Since there is no specified
concept of a command carrying multiple apps ids we decided to make it
the same as the header if it is present (for compatibility purposes).
This AVP MUST also be present as the first AVP in all experimental
commands defined in the vendor-specific application.
This AVP SHOULD be placed as close to the Diameter header as
possible.
"This" in the above two sentences refers to the
Vendor-Specific-Application-Id AVP. Right?
Yes. I've cleaned them up.
If a Vendor-Specific-Application-Id is received that contains both
Auth-Application-Id and Acct-Application-Id, then the recipient
SHOULD issue an answer with Result-Code set to
DIAMETER_AVP_OCCURS_TOO_MANY_TIMES. The answer SHOULD also include a
Failed-AVP which MUST contain the received Auth-Application-Id AVP
and Acct-Application-Id AVP.
Why are these only SHOULD level requirements? What happens in the other
cases?
Yes your right.
6.14. Redirect-Max-Cache-Time AVP
This AVP contains the maximum number of seconds the peer and route
table entries, created as a result of the Redirect-Host, will be
cached. Note that once a host created due to a redirecation has always been failback.
6.1.2. Sending a Request
When sending a request, originated either locally, or as the result
of a forwarding or routing operation, the following procedures MUST
be followed:
o the Hop-by-Hop Identifier should be set to a locally unique value.
s/should/SHOULD
o The message should be saved in the list of pending requests.
s/should/SHOULD
Given that the introductory sentence says "MUST be followed" I was
wondering
whether SHOULD is actually too weak here.
Then I think the introductory sentence should be set to SHOULD instead
of MUST because these recommendations have obvious "preference "
constraints from the implementor; i.e. implementations my choose not to
store all pending request because of storage constraints.
6.7.2. Proxy-Info AVP
The description for the AVP does not describe the semantic.
Ok. How about modifying the 1st paragraph to:
"The Proxy-Info AVP (AVP Code 284) is of type Grouped. This AVP
contains the identity and local state information of Diameter node
that creates and adds it to a message. The Grouped Data field
has the
following ABNF grammar:"
6.7.4. Proxy-State AVP
s/
The Proxy-State AVP (AVP Code 33) is of type OctetString, and
contains state local information, and MUST be treated as opaque data.
/
The Proxy-State AVP (AVP Code 33) is of type OctetString, and
is created by the Diameter server and passed on to the Diameter
client. It contains state information that would otherwise be stored at
the Diameter.
As such, this AVP MUST be treated as opaque data by entities other
than the Diameter server that created it.
Proxy-State AVP can be created and inserted by proxies as well (not only
servers). So we should rephrase the 1st sentence of your suggestion to:
"The Proxy-State AVP (AVP Code 33) is of type OctetString. It
contains state information that would otherwise be stored at
the Diameter entity that created it. As such, this AVP MUST be
treated as opaque data by entities other Diameter entities."
6.8. Auth-Application-Id AVP
The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and
is used in order to advertise support of the Authentication and
Authorization portion of an application (see Section 2.4). If
present in a message other than CER and CEA, the value of the Auth-
Application-Id AVP MUST match the Application Id present in the
Diameter message header.
If it always matches then does it make a lot of sense?
Yes. This has a lot of history at the interop since there's confusion on
what these Id's really represent or what its purpose was given that
there's already and id in the header. Since there is no specified
concept of a command carrying multiple apps ids we decided to make it
the same as the header if it is present (for compatibility purposes).
This AVP MUST also be present as the first AVP in all experimental
commands defined in the vendor-specific application.
This AVP SHOULD be placed as close to the Diameter header as
possible.
"This" in the above two sentences refers to the
Vendor-Specific-Application-Id AVP. Right?
Yes. I've cleaned them up.
If a Vendor-Specific-Application-Id is received that contains both
Auth-Application-Id and Acct-Application-Id, then the recipient
SHOULD issue an answer with Result-Code set to
DIAMETER_AVP_OCCURS_TOO_MANY_TIMES. The answer SHOULD also include a
Failed-AVP which MUST contain the received Auth-Application-Id AVP
and Acct-Application-Id AVP.
Why are these only SHOULD level requirements? What happens in the other
cases?
Yes your right.
6.14. Redirect-Max-Cache-Time AVP
This AVP contains the maximum number of seconds the peer and route
table entries, created as a result of the Redirect-Host, will be
cached. Note that once a host created due to a redirect indicat indication
is no longer reachable, any associated peer and routing table entries
MUST be deleted.
"will be cached" does not provide a good indication how the value provided
by this AVP should actually be treated. Is this
* MUST be cached
* SHOULD cached
* MAY be cached
Agree. Let's set it to SHOULD be cached ... implementations can have
room for other techniques.
I think that the semantic is a bit weak. What can the sender really expect
when it provides a value with AVP to the receiver?
In this case, the sender does not have any expectation of what the
receiver eventually decides to do since it is only a passive entity
(i.e. it never carries state). The redirect agent is similar to a "sign
post", it provides information but the receiver eventually has to decide
how to route the message.
Diameter may also be used for services that cannot be easily
categorized as authentication, authorization or accounting (e.g.,
certain 3GPP IMS interfaces). In such cases, the finite state
machine defined in subsequent sections may not be applicable.
Therefore, the applications itself MAY need to define its own finite
state machine. However, such application specific state machines
MUST comply with general Diameter user session requirements such co-
relating all message exchanges via Session-Id AVP.
What specifically is meant by saying that such applications must comply
with the
general Diameter user session requirements?
Hmm... I think that should be re-phrased to:
"However, such application specific state machines SHOULD follow the
general state machine framework outlined in this document such as the
use of Session-Id AVPs and the us of STR/STA, ASR/ASA messages for
stateful sessions."
8.6. Inferring Session Termination from Origin-State-Id
this section is a bit confusing as it talks about CER/CEA and the
hop-by-hop processing
but then refers to end-to-end processing as well.
I've re-factored the section to:
"The Origin-State-Id is used to allow detection of terminated
sessions for which no STR would have been issued, due to
unanticipated shutdown of an access device.
A Diameter client or access device increments the value of the
Origin-State-Id
every time it is started or powered-up. The new Origin-State-Id is
then sent in the CER/CEA message immediately upon connection to
the server.
The Diameter server receiving the new Origin-State-Id can determine
whether the sending Diameter client had abrubtly shutdown by
comparing
the old value of the Origin-State-Id it has kept for that specific
client is less than the new value and whether it has un-terminated
sessions originating from that client.
An access device can also include the Origin-State-Id in request
messages other than CER if there are relays or proxies in
between the
access device and the server. In this case, however, the server
cannot
discover that the access device has been restarted unless and
until it
receives a new request from it. Therefore this mechanism is more
opportunistic across proxies and relays.
The Diameter server may assume that all sessions that were active
prior to detection of a client restart have been terminated.
The Diameter
server MAY clean up all session state associated with such lost
sessions,
and MAY also issues STRs for all such lost sessions that were
authorized
on upstream servers, to allow session state to be cleaned up
globally."
8.7. Auth-Request-Type AVP
The Auth-Request-Type AVP (AVP Code 274) is of type Enumerated and is
included in application-specific auth requests to inform the peers
whether a user is to be authenticated only, authorized only or both.
Note any value other than both MAY cause RADIUS interoperability
issues.
What are the RADIUS interoperability issues?
...tion
is no longer reachable, any associated peer and routing table entries
MUST be deleted.
"will be cached" does not provide a good indication how the value provided
by this AVP should actually be treated. Is this
* MUST be cached
* SHOULD cached
* MAY be cached
Agree. Let's set it to SHOULD be cached ... implementations can have
room for other techniques.
I think that the semantic is a bit weak. What can the sender really expect
when it provides a value with AVP to the receiver?
In this case, the sender does not have any expectation of what the
receiver eventually decides to do since it is only a passive entity
(i.e. it never carries state). The redirect agent is similar to a "sign
post", it provides information but the receiver eventually has to decide
how to route the message.
Diameter may also be used for services that cannot be easily
categorized as authentication, authorization or accounting (e.g.,
certain 3GPP IMS interfaces). In such cases, the finite state
machine defined in subsequent sections may not be applicable.
Therefore, the applications itself MAY need to define its own finite
state machine. However, such application specific state machines
MUST comply with general Diameter user session requirements such co-
relating all message exchanges via Session-Id AVP.
What specifically is meant by saying that such applications must comply
with the
general Diameter user session requirements?
Hmm... I think that should be re-phrased to:
"However, such application specific state machines SHOULD follow the
general state machine framework outlined in this document such as the
use of Session-Id AVPs and the us of STR/STA, ASR/ASA messages for
stateful sessions."
8.6. Inferring Session Termination from Origin-State-Id
this section is a bit confusing as it talks about CER/CEA and the
hop-by-hop processing
but then refers to end-to-end processing as well.
I've re-factored the section to:
"The Origin-State-Id is used to allow detection of terminated
sessions for which no STR would have been issued, due to
unanticipated shutdown of an access device.
A Diameter client or access device increments the value of the
Origin-State-Id
every time it is started or powered-up. The new Origin-State-Id is
then sent in the CER/CEA message immediately upon connection to
the server.
The Diameter server receiving the new Origin-State-Id can determine
whether the sending Diameter client had abrubtly shutdown by
comparing
the old value of the Origin-State-Id it has kept for that specific
client is less than the new value and whether it has un-terminated
sessions originating from that client.
An access device can also include the Origin-State-Id in request
messages other than CER if there are relays or proxies in
between the
access device and the server. In this case, however, the server
cannot
discover that the access device has been restarted unless and
until it
receives a new request from it. Therefore this mechanism is more
opportunistic across proxies and relays.
The Diameter server may assume that all sessions that were active
prior to detection of a client restart have been terminated.
The Diameter
server MAY clean up all session state associated with such lost
sessions,
and MAY also issues STRs for all such lost sessions that were
authorized
on upstream servers, to allow session state to be cleaned up
globally."
8.7. Auth-Request-Type AVP
The Auth-Request-Type AVP (AVP Code 274) is of type Enumerated and is
included in application-specific auth requests to inform the peers
whether a user is to be authenticated only, authorized only or both.
Note any value other than both MAY cause RADIUS interoperability
issues.
What are the RADIUS interoperability issues?
... have to have to investigate
8.9. Authorization-Lifetime AVP
This is typically used in cases where multiple
authentication methods are used, and a successful auth response with
this AVP set to zero is used to signal that the next authentication
method is to be immediately initiated.
Where is this used?
The description is really bad. I'm guessing the original intent is when
you have multiple EAPs for a single auth session. I think this text is
just confusing. Multiple auth's are built into the diameter app
exchanges so the generic base protocol fsm should not concern itself
with such details. We should just remove that text.
This AVP MAY be provided by the client as a hint of the maximum
lifetime that it is willing to accept. However, the server MAY
return a value that is equal to, or smaller, than the one provided by
the client.
There are many MAYs in there. Does it mean that a value that is larger
can also be provided by the server?
If not, then shouldn't the second sentence say MUST?
Yes your right. the second sentence should say MUST otherwise the
negotiation does not make sense.
regards,
victor
_______________________________________________
DiME mailing list
DiME at ietf.org
https://www.ietf.org/mailman/listinfo/dime
investigate
8.9. Authorization-Lifetime AVP
This is typically used in cases where multiple
authentication methods are used, and a successful auth response with
this AVP set to zero is used to signal that the next authentication
method is to be immediately initiated.
Where is this used?
The description is really bad. I'm guessing the original intent is when
you have multiple EAPs for a single auth session. I think this text is
just confusing. Multiple auth's are built into the diameter app
exchanges so the generic base protocol fsm should not concern itself
with such details. We should just remove that text.
This AVP MAY be provided by the client as a hint of the maximum
lifetime that it is willing to accept. However, the server MAY
return a value that is equal to, or smaller, than the one provided by
the client.
There are many MAYs in there. Does it mean that a value that is larger
can also be provided by the server?
If not, then shouldn't the second sentence say MUST?
Yes your right. the second sentence should say MUST otherwise the
negotiation does not make sense.
regards,
victor
_______________________________________________
DiME mailing list
DiME at ietf.org
https://www.ietf.org/mailman/listinfo/dime
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
