Subject: [Teep] TEEP breaking OTrP compatibility consensus

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Sun, 4 Aug 2019 00:48:08 +0000

All,

At IETF 105, there was consensus to the question: Is the (TEEP working) group willing to break backwards compatibility with OTrP 1.0?

If there are objections to this decision, please respond by Aug 16th to this email with the rationale for why TEEP should continue OTrP compatibility.

Thanks,
                Nancy

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Sun, 4 Aug 2019 01:21:41 +0000

No objection provided that the OTrP name and references are dropped. I believe there has been at least some indication on mailing list that this would be acceptable.

I would otherwise object on the basis of published specifications compatible with the original OTrP contribution and based on the SD concept, such as https://globalplatform.org/specs-library/tee-management-framework-open-trust-protocol/ I believe there would be a risk of confusion caused by lack of interoperability between similarly named protocols.

Best regards
Jeremy

On 4 Aug 2019, at 08:48, Nancy Cam-Winget (ncamwing) <[email-masked]<mailto:[email-masked]>> wrote:

CAUTION: This email originated from outside of the organization.
All,

Thanks,
                Nancy

_______________________________________________
TEEP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teep

---

From: 塚本明 <[email-masked]>
Date: Mon, 5 Aug 2019 02:36:31 +0000

Hi,

I am fine with OTrPv2 breaking backwards compatibility against the first OTrP draft.

Akira

> -----Original Message-----
> From: TEEP <[email-masked]> On Behalf Of Nancy Cam-Winget (ncamwing)
> Sent: Sunday, August 4, 2019 9:48 AM
> To: [email-masked]
> Subject: [Teep] TEEP breaking OTrP compatibility consensus
> 
> All,
> 
> 
>

---

From: <[email-masked]>
Date: Mon, 5 Aug 2019 03:25:28 +0000

I am also for breaking compatibility but I would prefer to change the name of the draft not just adding -v2 to the name. Thank you

./Sorin

Sent from my iPad

> On Aug 4, 2019, at 10:40 PM, 塚本明 <[email-masked]> wrote:
> 
> 
> [EXTERNAL EMAIL] 
> 
> Hi,
> 
> [email-masked]

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 5 Aug 2019 05:08:27 +0000

Thanks Jeremy.  We do need to continue the discussion as to whether we retain the OTrP name for the protocol or adopt something else; while we did not reach consensus on changing its name…..I can appreciate you raising the rationale in favor changing the name and will see what others comment on the mail list too.

Warm regards, Nancy

From: Jeremy O'Donoghue <[email-masked]>
Date: Saturday, August 3, 2019 at 18:22
To: ncamwing <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Teep] TEEP breaking OTrP compatibility consensus

Best regards
Jeremy

Thanks,
                Nancy

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 5 Aug 2019 05:30:06 +0000

>    I am also for breaking compatibility but I would prefer to change the name of the draft not just adding -v2 to the name.

Same here.

We saw similar confusion with the base ACME spec, which is used by LetsEncrypt, and the IETF version. QUIC also re-used the name, but the confusion there was much more tractable because the base implementation is pretty much controlled by one party, who has been very careful to label things as IETF QUIC and gQUIC, for example.

---

From: 塚本明 <[email-masked]>
Date: Mon, 5 Aug 2019 05:41:28 +0000

> >    I am also for breaking compatibility but I would prefer to change the name of the draft not just adding -v2 to the

Initially I felt the same. Then I thought that I have not seen any implementation of full OTrP-v1 so
if the first implementation would be OTrPv2 then I felt it would not much matter in implementations
as far as the future variants would not have confusing name.

Akira

> From: TEEP <[email-masked]> On Behalf Of Salz, Rich
> Sent: Monday, August 5, 2019 2:30 PM
> To: [email-masked]
> Cc: [email-masked]
> We saw similar confusion with the base ACME spec, which is used by LetsEncrypt, and the IETF version. QUIC also
> re-used the name, but the confusion there was much more tractable because the base implementation is pretty much
> controlled by one party, who has been very careful to label things as IETF QUIC and gQUIC, for example.
> 
>