Re: [Dime] Proposed REQ 35 Text

[<[e-mail]>]

Hi Glen,

Please see below.

Regards,

Lionel

-----Message d'origine-----
De : Glen Zorn [mailto:[e-mail]] 
Envoyé : jeudi 28 mars 2013 04:09
À : MORAND Lionel OLNC/OLN
Cc : Ben Campbell; [e-mail]; [e-mail]
Objet : Re: [Dime] Proposed REQ 35 Text

On 03/27/2013 09:55 PM, [e-mail] wrote:
>
> Hi,
>
> Following the discussion in the meeting, here is my interpretation.
>
> I said during the meeting that a new application will only be able to 
> go through existing relay and redirect agent and not through "legacy" 
> proxies i.e. proxies not supporting/advertising the new application.
>

OK, but this is not different from any other new application, right?  
So, if the only route to a given destination realm is through a proxy, 
either the proxy must be updated to support the app or the application 
will fail.  That behavior seems fine to me: proxy application support 
(or non-support) is an administrative decision. 

[LM] I'm fine with that also. And it means that a solution based on a new app-id would fail to meet the REQ35 containing a "MUST". And I'm not sure if it is really what we want at this stage.

If a transited realm 
doesn't want to carry the traffic generated by an application (perhaps, 
in this case, because the administrators are unconvinced that the 
solution to signaling overload is more signaling), I think that it is 
inappropriate to attempt to force it to do so.

[LM] Right!

> So the question is simple: in the requirement elaboration phase, are 
> we sure that any solution based on a new App-id will be rejected?
>

Do you mean rejected by the WG?

[LM] Yes!

> If not: the "SHOULD" is meaningful in REQ35.
>
> If yes: this is a strong requirement and this must be stated somewhere 
> in the draft.
>
> Lionel
>
> *De :*[e-mail] [mailto:[e-mail]] *De la part 
> de* Ben Campbell
> *Envoyé :* mardi 26 mars 2013 21:31
> *À :* [e-mail]
> *Objet :* [Dime] Proposed REQ 35 Text
>
> Hi,
>
> We had a discussion about whether REQ 35 in the 
> draft-ietf-dime-overload-reqs should stay a SHOULD or become a MUST. 
>  We further discussed that any use of a MUST here would require some 
> caveats about what sort of intermediaries could be traversed, and the 
> potential security issues. The chairs directed us to take the 
> discussion to the list due to time constraints. Here's my attempt to 
> do so.
>
> For reference, here's the original text:
>
>     The mechanism SHOULD provide a method for exchanging overload and
>     load information between elements that are connected by
>     intermediaries that do not support the mechanism.
>
> Here's a proposed alternative for changing it to a MUST:
>
>     The mechanism MUST provide a method for exchanging overload and
>     load information between elements that are connected by
>     intermediaries that do not support the mechanism. The mechanism
>     MAY place limitations on the nature of the non-supporting
>     intermediaries that may be traversed.
>
>         Nothing in this requirement should be construed to relax the
>         security-related requirements elsewhere in this document, in
>         particular REQs 28, 30, and 31. Maliciously constructed
>         overload information can potentially shut down a Diameter
>         network; it's critical that a node be able to confirm that
>         received information came unaltered from an authorized source,
>         whether the information comes from an immediate peer or
>         crosses an intermediary.
>
> Which general approach do people prefer? I kept the security aspects 
> non-normative, since normative text already exists in 28,30, and 31.
>
> Thanks!
>
> Ben.
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.