Subject: [Perc] Names, Names, Names

From: Cullen Jennings <[email-masked]>
Date: Tue, 10 May 2016 09:34:49 -0600

Normally I view names as a bit of a bike shed issue but lately I have been spending a bunch of time explaining PERC to folks and I have been finding the current names sort of confusing to new people. I'd like to start a thread to come up with some new names for existing things ...

inner and outer - people are never sure which is inner and which is outer. I'd propose just using hop-by-hop and end-to-end 

MDD - change to "Media Switch" or "Switch". 

KMF - change to "Key Server" or "Key Manger"

Endpoint - keep as "Endpoint"

I'd like to move away from acronyms as much as possible - they just add confusion. 

Now that the OHB has become just a PT or Seq# change or both, it might be good to think about simpler way of describing this. 

EKT Field - use this to describe the place that any type of EKT message get carried 

Long EKT Field - change to Encrypted Key message. This message simply caries the encrypted form of the SRTP Master Key and calling it EKT Long Field in a protocol called EKT that is negotiated in TLS by including ekt in the handshake is not very enlightening. 

Short EKT Field  - change to Empty message. This message caries nothing and simply is there to indicate that no other EKT message is attached to this packet. 

Thoughts on better names? Folks OK with the proposed changes ?

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 11 May 2016 05:07:42 +0000

Cullen,

>inner and outer - people are never sure which is inner and which is 
>outer. I'd propose just using hop-by-hop and end-to-end
Agreed.

>MDD - change to "Media Switch" or "Switch".

Switching Conference Server is the original term we used, I think. I 
have no strong preference on this one.

>KMF - change to "Key Server" or "Key Manger"

I avoided the word "Key Server" to make it clear it's not just a 
"server", but a functional element within the system.  The term "key 
manager" might be better given this function might be inside a browser.

>I'd like to move away from acronyms as much as possible - they just add 

Oh, I won't argue with this one at all.

>Now that the OHB has become just a PT or Seq# change or both, it might 
>be good to think about simpler way of describing this.

We can review that text, but OHB doesn't suggest a complex structure.  
It could be the "original header field value extension" (avoiding 
acronyms).

>Long EKT Field - change to Encrypted Key message. This message simply 
>caries the encrypted form of the SRTP Master Key and calling it EKT 
>Long Field in a protocol called EKT that is negotiated in TLS by 
>including ekt in the handshake is not very enlightening.
>
>Short EKT Field  - change to Empty message. This message caries nothing 
>and simply is there to indicate that no other EKT message is attached 
>to this packet.

I think changing this to "encrypted" and "empty" are confusing.  
Previously, this thing was called the "EKT Tag".   The current terms are 
"Full EKT Field" or "Short EKT Field".  If that's too confusing, perhaps 
we just try to find a way to drop the full/short delineation, just call 
it the EKT Tag/Field?  Personally, I like the short/full description 
since there is concrete syntax that goes with it.  The alternatives you 
suggest make it sound like different messages (versus field elements).

Paul

---

From: Emil Ivov <[email-masked]>
Date: Wed, 11 May 2016 04:08:48 -0500

On Wednesday, 11 May 2016, Paul E. Jones <[email-masked]> wrote.
> Switching Conference Server is the original term we used, I think. I have
> no strong preference on this one.

Why is it again that we are not using SFU here?

Emil

-- 
sent from my mobile

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 11 May 2016 12:24:09 -0400

The topologies draft moved away from SFU to SFM. Still, not sure it perfectly represents what were doing with PERC, because we are introducing a two-step process where a security association exists HBH and E2E.

We had some dialog before that we might need to define a new topological function or amend a current definition. I don't think we're at the point where we can do that, yet.

Paul

-------- Original Message --------
From: Emil Ivov <[email-masked]>
Sent: May 11, 2016 5:08:48 AM EDT
To: "Paul E. Jones" <[email-masked]>
Cc: Cullen Jennings <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Perc] Names, Names, Names

Emil

-- 
sent from my mobile

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 11 May 2016 14:45:36 -0600

> On May 11, 2016, at 3:08 AM, Emil Ivov <[email-masked]> wrote:
> 
> 
> 
> Switching Conference Server is the original term we used, I think. I have no strong preference on this one.
> 

Some people felt the "Forward" part implied an architecture where it only forwarded without modifying. PERC supports that arch but also supports some sort of modifications so we needed a moe general term. I was hoping that Switch or Media Switch might avoid that problem in that a SFU is one type of Media Switch but there are other types that both forward and modify. Work for you?

---

From: Russ Housley <[email-masked]>
Date: Wed, 11 May 2016 16:50:08 -0400

> KMF - change to "Key Server" or "Key Manger"

The role here is Key Distribution.  In some old systems, this is called the KDC, or Key Distribution Center.

Russ

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 11 May 2016 14:50:49 -0600

> On May 10, 2016, at 11:07 PM, Paul E. Jones <[email-masked]> wrote:
> 
> Cullen,
> 
> I avoided the word "Key Server" to make it clear it's not just a "server", but a functional element within the system.  The term "key manager" might be better given this function might be inside a browser.

+1 

> We can review that text, but OHB doesn't suggest a complex structure.  It could be the "original header field value extension" (avoiding acronyms).
> 
> I think changing this to "encrypted" and "empty" are confusing.  Previously, this thing was called the "EKT Tag".   The current terms are "Full EKT Field" or "Short EKT Field".  If that's too confusing, perhaps we just try to find a way to drop the full/short delineation, just call it the EKT Tag/Field?  Personally, I like the short/full description since there is concrete syntax that goes with it.  The alternatives you suggest make it sound like different messages (versus field elements).

OK ... back to the drawing boards on this.. 

We need something that helps capture what the purpose and content is of the full message so when you see it on a call flow, it inspires the right thought. 

DItto for short

We need something that describes the whole set of things so both the short and long are instances of this thing. 

> 
> Paul
> 
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc

---

From: Emil Ivov <[email-masked]>
Date: Wed, 11 May 2016 17:18:48 -0500

> Some people felt the "Forward" part implied an architecture where it only forwarded without modifying. PERC supports that arch but also supports some sort of modifications so we needed a moe genera…

I feel that if we have a common denominator between topologies then it
should be defined and named in the topologies draft. I also feel that
terms like SFU are often used in a way that is generic enough (so much
so that 7667 uses it without actually defining it). Most importantly
though, I believe the gain of using a common and well known term would
far outweigh the potential confusion of it not being perfectly exact.

In other words: I cannot believe that someone would ever look at PERC
and say: "oh wait this thing talks about the 3.7 topo from 7667 and I
really am more like the one in 3.8 so nah ... no go."

That said, I don't believe that this is the most important issue we
are facing now, so I could live with whatever. I am sure we could use
the extra exercise on our brains anyway ;)

Emil

-- 
https://jitsi.org

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 11 May 2016 22:20:27 +0000

Cullen,

>>>  Long EKT Field - change to Encrypted Key message. This message 
>>>simply caries the encrypted form of the SRTP Master Key and calling 
>>>it EKT Long Field in a protocol called EKT that is negotiated in TLS 
>>>by including ekt in the handshake is not very enlightening.
>>>
>>>  Short EKT Field  - change to Empty message. This message caries 
>>>nothing and simply is there to indicate that no other EKT message is 
>>>attached to this packet.
>>
>>Previously, this thing was called the "EKT Tag".   The current terms 
>>are "Full EKT Field" or "Short EKT Field".  If that's too confusing, 
>>perhaps we just try to find a way to drop the full/short delineation, 
>>just call it the EKT Tag/Field?  Personally, I like the short/full 
>>description since there is concrete syntax that goes with it.  The 
>>alternatives you suggest make it sound like different messages (versus 
>>field elements).
>
>We need something that helps capture what the purpose and content is of 
>the full message so when you see it on a call flow, it inspires the 
>right thought.
>
>DItto for short
>
>We need something that describes the whole set of things so both the 
>short and long are instances of this thing.

Can we just get by with calling it an "EKT Tag" (former name for this)?  
What's inside the tag varies, but it's still just the "tag".  "EKT 
Field" works, too.  I have no preference, really.

Is your goal to get down to one name here?

Paul

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 12 May 2016 10:56:36 -0600

> On May 11, 2016, at 4:18 PM, Emil Ivov <[email-masked]> wrote:
> 

Good point. I mostly find topologies too baffling to bother reading but agree this should be aligned.