Subject: Re: [Dime] WGLC Review of draft-ietf-dime-app-design-guide-15

From: <[email-masked]>
Date: Wed, 5 Sep 2012 16:10:19 +0000

Hi Ben,

Thank you for this detailed review!
Please see below the proposed treatments. I'm preparing a new version of the draft but I will wait for ack and other comments before publication.

Regards,

Lionel

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Ben Campbell
Envoyé : mardi 28 août 2012 23:55
À : [email-masked]; [email-masked]
Objet : [Dime] WGLC Review of draft-ietf-dime-app-design-guide-15

Hi,

The draft gives good guidance overall. I do have a few comments, though:

Substantive Comments:

-- section 4:

The section seems to talk mainly about syntax, rather than semantics. Is there any guidance to give about things (applications, commands, avps) that might be syntactically similar but mean very different things?

[LM] good point! The main problem is about syntax when regarding the protocol itself. But semantic is also essential for the application, as mentioned in the RFC3588bis. I will add some words to clarify that change of the semantic of an AVP/command may/should/must result in the allocation of a new code value.

-- 4.3.2, last paragraph:

Does it become an error if a peer uses the "no-longer-used-but-not-deleted" avp?

[LM] what is really meant is that you don't have to delete optional AVPs from a command. Obsolete AVP that would be received anyway would be simply ignored. It is not an error case but the normal handling of optional AVPs.

-- 5.9

Does the advice in this section open up an unmanaged extension vector? In the extreme case, would this encourage an external group to register a single application id for a highly extensible application, then bypass IETF extension processes by just adding more functions to the original application?

[LM] in the vendor-specific space, IETF will have no control at all but it is exactly the principle of vendor-specific application. So this possibility exists. Anyway, as soon as interoperability with the external world is required, application designers will have to adopt common rules and this is the aim of this document.
 
-- 8:

The security considerations say that this draft does not define nor address security related protocols or schemes. But there was an entire section dedicated to the use of IPSec, which certainly seems to address a security related protocol and scheme. 

[LM] this section was there before the introduction of the one on IPsec. I will fix it :)

Editorial Comments:

-- section 1:

I'm confused by list item 2. It seems to talk both about adding new function to an existing application and creating a new application. I suspect this is about the case of using two applications together to effectively add function--if so, that could be more clear.

[LM] A typical example would be the addition of a new command to an existing application and the consequence of such addition would be the creation of a new application i.e. assignment of a new application-id value.

-- section 3, Major Extension case: "... in such a way that this implies backward compatible change to the existing application ..."

Do you mean a _non_ backwards compatible change?

[LM] Yes

-- section 4.1, third bullet: " Care should be taken to avoid a liberal method of importing existing command's CCF syntax specification."

I'm not sure I understand what you mean by a "liberal method of importing"?

[LM] "liberal" can be replaced by "general", I think. 

"This would result in a monolithic and hard to manage applications..." 

singular/plural disagreement

[LM] OK

-- 4.2, 2nd paragraph

s/" indicates of a flawed design"/"indicates a flawed design"

-- 4.3, 2nd paragraph:

s/"It is worth to note that"/"It is worth noting that"   [Or even better, skip the whole clause]

s/"in the [RFC3588]"/"in [RFC3588]"

[LM] ok

-- 4.3.1, title:

s/ommand/command

[LM] OK

-- 4.3.1, 2nd bullet list, 3rd bullet:

The second half of this bullet item seems redundant with the previous bullet.

[LM] OK. I propose to just keep the "different number of roundtrips" 

-- 5.8

The section may have some meaning obscured by passive voice. In particular, who foresaw that translation would be easy, who acknowledged that it wasn't, and who might foresee the need for RADIUS interworking? (I think those are the work group, the work group, and application designers, respectively)

[LM] OK. Will use the active voice instead.

-- 5.9, third bullet: "Applications that do not understand these AVP can discard it ..."

singular/plural disagreement

[LM] OK.

-- 5.11, 1st paragraph: "However, IPsec Additional security mechanisms such as IPsec can also be deployed to secure connections between Diameter peers."

Do you mean "IPSec can also be deployed...", or "Additional security mechanisms such as IPSec can also be deployed..."?

[LM] Obviously, something needs to be fixed.

Thanks!

Ben.

_______________________________________________
DiME mailing list
[email-masked]
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.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 5 Sep 2012 14:21:42 -0500

Thanks for the response! I've removed sections that appear to be resoved.

Thanks!

Ben.

On Sep 5, 2012, at 11:10 AM, <[email-masked]> wrote:
[...]
> [LM] in the vendor-specific space, IETF will have no control at all but it is exactly the principle of vendor-specific application. So this possibility exists. Anyway, as soon as interoperability w…

I agree we can't control what people do in the vendor-specific space. We have so little control there that there is little point in saying much about it. My concern is still true for the IETF controlled space, which is controlled by IETF Review. My concern is that encouraging the use of AVPs to negotiation features could be used to invoke extensions that really should be treated as separate applications. The text here seems to condone that behavior, which could lead an expert reviewer to decide it was okay for all cases.

If we are going to encourage the use of AVPs to negotiation arbitrary features, we probably need some guidance for said expert reviewer. I realize this sort of thing would be case-by-case and fairly subjective, but it seems like we need more guidance than is there now.

[...]

> Editorial Comments:

[...]
> [LM] OK. I propose to just keep the "different number of roundtrips" 

WFM

> [LM] Obviously, something needs to be fixed.

Do you have thoughts on whether this text is intended to allow just the use of IPSec (in addition to TLS and DTLS, of course) , or to allow the more generic "additional mechanisms such as IPSec"?

---

From: <[email-masked]>
Date: Wed, 12 Sep 2012 17:00:53 +0000

Hi Ben,

Please see below.

Regards,

Lionel

-----Message d'origine-----
De : Ben Campbell [mailto:[email-masked]] 
Envoyé : mercredi 5 septembre 2012 21:22
À : MORAND Lionel RD-CORE
Cc : [email-masked]
Objet : Re: [Dime] WGLC Review of draft-ietf-dime-app-design-guide-15

Thanks!

Ben.

On Sep 5, 2012, at 11:10 AM, <[email-masked]> wrote:
[...]

[LM] it is true that the mechanism is not only used by external SDOs but also in IETF RFCs, such as RFC5447. I think that we can clarify the way these E2E negotiation AVPs are meant to be used. The idea is that you add a new feature to an existing application that can be supported by an optional AVP or when client and server can support new optional functions that was not initially part of the specification. In such a case, as it is purely optional, using E2E negotiation AVPs is helpful. The limit is if any single agent in the path needs be updated to support this new feature, that would the case for the definition of a new application. Would it be OK if the text is clarified in that sense?

[...]

[...]

WFM

[LM] the whole text is only about IPsec. I will even change the title of the section to reflect this point.