Subject: [Dime] RFC 6733 Commands

From: "Bertz, Lyle T [CTO]" <[email-masked]>
Date: Mon, 17 Jul 2017 10:12:23 +0000

In the spec was there a particular reason why we did not specify the application Identifier in the header for each of the command codes, e.g. ACR/ACA assigned to application ID 3?

Lyle

________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: <[email-masked]>
Date: Mon, 17 Jul 2017 14:32:57 +0000

Hi Lyle,

I think that there is no specific reason. By definition, the command is independent of any application. So when describing the command code, it may or may not be contained in the command code header. It is consistent with the CCF specification:

   header           = "<Diameter-Header:" command-id
                         [r-bit] [p-bit] [e-bit] [application-id]">"

The CCF is mainly used to identify the set of AVP that can be present in the command.

Regards,

Lionel

De : DiME [mailto:[email-masked]] De la part de Bertz, Lyle T [CTO]
Envoyé : lundi 17 juillet 2017 12:12
À : [email-masked] list
Objet : [Dime] RFC 6733 Commands

Lyle

_________________________________________________________________________________________________________________________

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,
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, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Bertz, Lyle T [CTO]" <[email-masked]>
Date: Mon, 17 Jul 2017 15:03:48 +0000

agreed, we have encountered some folks tying the ACR/ACA to app id 0 in open source.

________________________________
From: [email-masked] <[email-masked]>
Sent: Monday, July 17, 2017 9:32 AM
To: Bertz, Lyle T [CTO]; [email-masked] list
Subject: RE: RFC 6733 Commands

Hi Lyle,

Regards,

Lionel

Lyle

---

From: Yuval Lifshitz <[email-masked]>
Date: Wed, 19 Jul 2017 09:32:18 +0000

Actually, we may have an issue there. The spec says that zero must be used for base protocol messages (page 23):

Diameter messages pertaining to peer connection
   establishment and maintenance such as CER/CEA, DWR/DWA, and DPR/DPA
   MUST carry an Application Id of zero (0).

But does not say that it must not be used for anything else (or at least I failed to find such text). Do you think such text should be added?
Note that there is such text regarding vendor-id.

From: DiME [mailto:[email-masked]] On Behalf Of Bertz, Lyle T [CTO]
Sent: Monday, July 17, 2017 6:04 PM
To: [email-masked]; [email-masked] list
Subject: Re: [Dime] RFC 6733 Commands

________________________________
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Monday, July 17, 2017 9:32 AM
To: Bertz, Lyle T [CTO]; [email-masked]<mailto:[email-masked]> list
Subject: RE: RFC 6733 Commands

Hi Lyle,

Regards,

Lionel

De : DiME [mailto:[email-masked]] De la part de Bertz, Lyle T [CTO]
Envoyé : lundi 17 juillet 2017 12:12
À : [email-masked]<mailto:[email-masked]> list
Objet : [Dime] RFC 6733 Commands

Lyle

Thank you.

---

From: "Jouni" <[email-masked]>
Date: Wed, 19 Jul 2017 13:00:17 +0300

Unless you extend and existing application within the rules in Section 1.3.4
you always get a new application. And if you wish to extend the existing
base protocol application with new commands that most likely would require a
new protocol version. I think we are good here with the current text.

-        Jouni 

From: DiME [mailto:[email-masked]] On Behalf Of Yuval Lifshitz
Sent: Wednesday, July 19, 2017 12:32 PM
To: Bertz, Lyle T [CTO] <[email-masked]>; [email-masked];
[email-masked] list <[email-masked]>
Subject: Re: [Dime] RFC 6733 Commands

Actually, we may have an issue there. The spec says that zero must be used
for base protocol messages (page 23):

But does not say that it must not be used for anything else (or at least I
failed to find such text). Do you think such text should be added?

From: DiME [mailto:[email-masked]] On Behalf Of Bertz, Lyle T [CTO]
Sent: Monday, July 17, 2017 6:04 PM
To: [email-masked] <mailto:[email-masked]> ;
[email-masked] <mailto:[email-masked]>  list
Subject: Re: [Dime] RFC 6733 Commands

agreed, we have encountered some folks tying the ACR/ACA to app id 0 in open
source.

  _____  

From: [email-masked] <mailto:[email-masked]>
<[email-masked] <mailto:[email-masked]> >
Sent: Monday, July 17, 2017 9:32 AM
To: Bertz, Lyle T [CTO]; [email-masked] <mailto:[email-masked]>  list
Subject: RE: RFC 6733 Commands 

Hi Lyle,

I think that there is no specific reason. By definition, the command is
independent of any application. So when describing the command code, it may
or may not be contained in the command code header. It is consistent with
the CCF specification:

The CCF is mainly used to identify the set of AVP that can be present in the
command.

Regards,

Lionel 

De : DiME [mailto:[email-masked]] De la part de Bertz, Lyle T [CTO]
Envoyé : lundi 17 juillet 2017 12:12
À : [email-masked] <mailto:[email-masked]>  list
Objet : [Dime] RFC 6733 Commands

In the spec was there a particular reason why we did not specify the
application Identifier in the header for each of the command codes, e.g.
ACR/ACA assigned to application ID 3?

Lyle

  _____  

This e-mail may contain Sprint proprietary information intended for the sole
use of the recipient(s). Any use by others is prohibited. If you are not the
intended recipient, please contact the sender and delete all copies of the
message.

____________________________________________________________________________
_____________________________________________
 
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,
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, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.

---

From: Yuval Lifshitz <[email-masked]>
Date: Wed, 19 Jul 2017 10:19:33 +0000

You mean, that if someone implement a new protocol but does not change definitions from base, not add any new stuff which is mandatory, they are allowed to use application-id zero for commands other than (CERA, DPR/A, DWR/A)?
Shouldn't we block that? Would imagine there are implementations where they assume zero is only for peer level messages?

From: Jouni [mailto:[email-masked]]
Sent: Wednesday, July 19, 2017 1:00 PM
To: Yuval Lifshitz; 'Bertz, Lyle T [CTO]'; [email-masked]; [email-masked]
Subject: RE: [Dime] RFC 6733 Commands

Unless you extend and existing application within the rules in Section 1.3.4 you always get a new application. And if you wish to extend the existing base protocol application with new commands that most likely would require a new protocol version. I think we are good here with the current text.

-        Jouni

From: DiME [mailto:[email-masked]] On Behalf Of Yuval Lifshitz
Sent: Wednesday, July 19, 2017 12:32 PM
To: Bertz, Lyle T [CTO] <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Dime] RFC 6733 Commands

From: DiME [mailto:[email-masked]] On Behalf Of Bertz, Lyle T [CTO]
Sent: Monday, July 17, 2017 6:04 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> list
Subject: Re: [Dime] RFC 6733 Commands

Hi Lyle,

Regards,

Lionel

Lyle

Thank you.

---

From: "Jouni" <[email-masked]>
Date: Wed, 19 Jul 2017 14:03:59 +0300

If you go for new protocol version that opens a door for a lot of things.
Generally adding commands to base protocol using app-id 0 is not possible
without a new protocol version. I do not see a reason for any extra
clarifications. I would be reluctant to assume app-id 0 is forever for peer
level commands. We have other ways to impose that restriction at the AVP
level where such things actually belong (see Section 6.1).

-        JOuni

From: Yuval Lifshitz [mailto:[email-masked]] 
Sent: Wednesday, July 19, 2017 13:20 PM
To: Jouni <[email-masked]>; 'Bertz, Lyle T [CTO]'
<[email-masked]>; [email-masked]; [email-masked]
Cc: Yuval Lifshitz <[email-masked]>
Subject: RE: [Dime] RFC 6733 Commands

You mean, that if someone implement a new protocol but does not change
definitions from base, not add any new stuff which is mandatory, they are
allowed to use application-id zero for commands other than (CERA, DPR/A,
DWR/A)?

Shouldn’t we block that? Would imagine there are implementations where they
assume zero is only for peer level messages?

From: Jouni [mailto:[email-masked]] 
Sent: Wednesday, July 19, 2017 1:00 PM
To: Yuval Lifshitz; 'Bertz, Lyle T [CTO]'; [email-masked]
<mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: RE: [Dime] RFC 6733 Commands

-        Jouni 

From: DiME [mailto:[email-masked]] On Behalf Of Yuval Lifshitz
Sent: Wednesday, July 19, 2017 12:32 PM
To: Bertz, Lyle T [CTO] <[email-masked]
<mailto:[email-masked]> >; [email-masked]
<mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]>
list <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Dime] RFC 6733 Commands

 

  _____  

Hi Lyle,

Regards,

Lionel 

Lyle

  _____

---

From: "Bertz, Lyle T [CTO]" <[email-masked]>
Date: Wed, 19 Jul 2017 11:55:52 +0000

My issue (and the motive for the e-mail) is that some lazy implementors tied the ACR/ACA to 0 which should not have happened.

Although optional, having placed the App ID of 3 in the ACR/ACA would have at least begged the question of how did you miss that?   It is pretty clear to me that the dev only looked @ the CCF and not the rest of the document.   However, if the app id was in the CCF that specific issue would have been avoided.

We can't fix one's inability to read the whole document but we can take steps to lower the probability of an error when they take shortcuts.

________________________________
From: Jouni <[email-masked]>
Sent: Wednesday, July 19, 2017 6:03 AM
To: 'Yuval Lifshitz'; Bertz, Lyle T [CTO]; [email-masked]; [email-masked]
Subject: RE: [Dime] RFC 6733 Commands

If you go for new protocol version that opens a door for a lot of things. Generally adding commands to base protocol using app-id 0 is not possible without a new protocol version. I do not see a reason for any extra clarifications. I would be reluctant to assume app-id 0 is forever for peer level commands. We have other ways to impose that restriction at the AVP level where such things actually belong (see Section 6.1).

-        JOuni

To: Jouni <[email-masked]>; 'Bertz, Lyle T [CTO]' <[email-masked]>; [email-masked]; [email-masked]

You mean, that if someone implement a new protocol but does not change definitions from base, not add any new stuff which is mandatory, they are allowed to use application-id zero for commands other than (CERA, DPR/A, DWR/A)?
Shouldn’t we block that? Would imagine there are implementations where they assume zero is only for peer level messages?

From: Jouni [mailto:[email-masked]]
Sent: Wednesday, July 19, 2017 1:00 PM
To: Yuval Lifshitz; 'Bertz, Lyle T [CTO]'; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dime] RFC 6733 Commands

-        Jouni

Hi Lyle,

Regards,

Lionel

Lyle

Thank you.

---

From: "Jouni" <[email-masked]>
Date: Wed, 19 Jul 2017 15:25:30 +0300

There is Acct-Application-Id in the CCF.. so what’s the difference?

“If present in a message other than

   CER and CEA, the value of the Acct-Application-Id AVP MUST match the

   Application Id present in the Diameter message header.”

-        JOuni

From: Bertz, Lyle T [CTO] [mailto:[email-masked]] 
Sent: Wednesday, July 19, 2017 14:56 PM
To: Jouni <[email-masked]>; 'Yuval Lifshitz'
<[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Dime] RFC 6733 Commands

My issue (and the motive for the e-mail) is that some lazy implementors tied
the ACR/ACA to 0 which should not have happened.

Although optional, having placed the App ID of 3 in the ACR/ACA would have
at least begged the question of how did you miss that?   It is pretty clear
to me that the dev only looked @ the CCF and not the rest of the document.
However, if the app id was in the CCF that specific issue would have been
avoided.

We can't fix one's inability to read the whole document but we can take
steps to lower the probability of an error when they take shortcuts.

  _____  

From: Jouni <[email-masked] <mailto:[email-masked]> >
Sent: Wednesday, July 19, 2017 6:03 AM
To: 'Yuval Lifshitz'; Bertz, Lyle T [CTO]; [email-masked]
<mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: RE: [Dime] RFC 6733 Commands 

-        JOuni

From: Yuval Lifshitz [mailto:[email-masked]] 
Sent: Wednesday, July 19, 2017 13:20 PM
To: Jouni <[email-masked] <mailto:[email-masked]> >; 'Bertz,
Lyle T [CTO]' <[email-masked] <mailto:[email-masked]> >;
[email-masked] <mailto:[email-masked]> ; [email-masked]
<mailto:[email-masked]> 
Cc: Yuval Lifshitz <[email-masked] <mailto:[email-masked]> >
Subject: RE: [Dime] RFC 6733 Commands

-        Jouni 

 

  _____  

Hi Lyle,

Regards,

Lionel 

Lyle

  _____

---

From: "Bertz, Lyle T [CTO]" <[email-masked]>
Date: Thu, 20 Jul 2017 07:20:33 +0000

​No spec issues here. Just people not reading the entire spec and picking up on every sentence (or reading it all imo).

________________________________
From: Jouni <[email-masked]>
Sent: Wednesday, July 19, 2017 7:25 AM
To: Bertz, Lyle T [CTO]; 'Yuval Lifshitz'; [email-masked]; [email-masked]
Subject: RE: [Dime] RFC 6733 Commands

-        JOuni

From: Bertz, Lyle T [CTO] [mailto:[email-masked]]
Sent: Wednesday, July 19, 2017 14:56 PM
To: Jouni <[email-masked]>; 'Yuval Lifshitz' <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Dime] RFC 6733 Commands

________________________________
From: Jouni <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, July 19, 2017 6:03 AM
To: 'Yuval Lifshitz'; Bertz, Lyle T [CTO]; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dime] RFC 6733 Commands

-        JOuni

From: Yuval Lifshitz [mailto:[email-masked]]
Sent: Wednesday, July 19, 2017 13:20 PM
To: Jouni <[email-masked]<mailto:[email-masked]>>; 'Bertz, Lyle T [CTO]' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Yuval Lifshitz <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Dime] RFC 6733 Commands

-        Jouni

Hi Lyle,

Regards,

Lionel

Lyle

Thank you.