Re: [Dime] Proposed REQ 35 Text

[Glen Zorn <[e-mail]>]

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. 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.

> 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?

> 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