Hi Steve,
It should be maybe clarified (if required) that this document does not create a
new protocol/solution. It only defines extensions to an existing protocol
(Diameter QoS Application), completing a standard list of AVPs in order to
support a set of parameters already defined in other
Hi Stephen,
The example given below illustrates also what I'm thinking. And please forgive
me if I miss something below.
IMHO, what you are saying about the SIP-Resource-Priority is true for any other
QoS parameters carried over the Diameter QoS application. It is therefore why
I'm assuming
Hi Stephen,
I confirm that there is an interest and this interest is increasing.
Now, not sure that I'm the best candidate to lead this work even if I can help.
We will see if there is more support that would motivate to put it right now in
the charter.
Regards,
Lionel
-Message
Hi Stephan,
When relying on S-NAPTR (RFC3958), redirection is only possible inside
sub-domains of the original domain name. This is a restriction compared to the
use of normal NAPTR and REGEXP. The following recommendations can be also found
in the RFC6733: The domain suffixes in the NAPTR
Works for me.
Regards,
Lionel
-Message d'origine-
De : Stefan Winter [mailto:stefan.win...@restena.lu]
Envoyé : mardi 20 août 2013 13:37
À : MORAND Lionel OLNC/OLN
Cc : d...@ietf.org; 'IETF Discussion Mailing List'
Objet : Re: [Dime] Last Call:
Hi Stephan,
Thank you for quick feedback.
I agree with your analysis. I think that we should provide more info on the
possible use of S-NAPTR for realm-based redirection.
Taking into account your proposal, what do you think of the following proposed
changes:
Abstract:
OLD:
However, in
