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

[<[e-mail]>]

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 : [e-mail] [mailto:[e-mail]] De la part de Ben Campbell
Envoyé : mardi 28 août 2012 23:55
À : [e-mail]; [e-mail]
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
[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.