Re: [Emu] Adoption call for RFC 7170bis

2022-12-22 Thread Alan DeKok
On Dec 22, 2022, at 5:00 PM, Eliot Lear  wrote:
> I view this differently.  First, we don't have good deployment numbers for 
> TEAP.   If we bump the version and nobody is using TEAP, then nobody will 
> care.  If we don't bump the version and people ARE using TEAP, we'll get to 
> hear from everyone who cares! From a code standpoint, I imagine that the 
> incompabitibilies will be small in number, and so we're talking about a 
> handful of conditionals.

  We have "something" implemented today as TEAPv1.  Whatever it is, it's 
shipped by multiple vendors on tens of millions of devices.   Plus, there are 
multiple other vendors planning on shipping TEAP support in Q2 2023.  

  We can rev TEAP, but we can't change existing implementations.  And any new 
rev will be deployed in the time frame (at best) of 12-18 months.

  If we document 7170bis now "as implemented", that can be done in a short time 
frame.  We then have the freedom to do whatever we want with TEAPv2.  But I'm 
wary of not documenting TEAPv1, and I'm wary of delaying that documentation in 
the interest of doing a TEAPv2.

  I'm not even sure what we'd do for TEAPv2.  There isn't much point in 
changing the key derivations.  The current one is arguably suboptimal, but it 
works.  I wouldn't see a need to change it for something "better" in a TEAPv2.

  So I'd like to know what would be in TEAPv2, and what issues there would be 
if we just documented TEAPv1 "as implemented".

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Adoption call for RFC 7170bis

2022-12-22 Thread Eliot Lear

Alan,

I view this differently.  First, we don't have good deployment numbers 
for TEAP.   If we bump the version and nobody is using TEAP, then nobody 
will care.  If we don't bump the version and people ARE using TEAP, 
we'll get to hear from everyone who cares! From a code standpoint, I 
imagine that the incompabitibilies will be small in number, and so we're 
talking about a handful of conditionals.


Eliot

On 22.12.22 15:43, Alan DeKok wrote:

On Dec 22, 2022, at 9:36 AM, Oleg Pekar  wrote:

I would like to provide comments as well. We should also bump the version of 
the protocol so as not to harm the existing implementations (yes, they 
implemented the spec with filed errata, the spec is sometimes ambiguous but 
those implementations are already on the market).

   What we have is a situation where no one has implemented RFC 7170, and there is no practical 
path to implementing it.  As a result, the -bis revision is documenting the implementations.  i.e. 
"this is what's going on" versus "what should be going on".

   It would be more relevant to update the version when there are incompatible 
changes to the protocol, *and* existing implementations which need to know 
which version they're negotiating.

   Since there is only one "TEAP version 1", I would argue that there's no need 
to change the version.

   Plus, if we change the version, then people have no idea what's currently 
implemented.  TEAP version 1 becomes an undocumented mess of unknowns.

   As an implementor, I'm happy to declare RFC 7170 as irrelevant, and to issue a new 
standard which defines TEAP version 1 "as implemented".

   Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu



OpenPGP_signature
Description: OpenPGP digital signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Adoption call for RFC 7170bis

2022-12-22 Thread Heikki Vatiainen
I would like to see this draft adopted. I need to work on implementing
TEAP. For this I'd like to have a draft that I could use, and while doing
the work, help by providing comments.

Thanks,
Heikki

On Fri, 16 Dec 2022 at 00:29, Peter Yee  wrote:

> This is an adoption call for RFC 7170bis
> (draft-dekok-emu-rfc7170bis-00)[1].
> I'd call this mostly a formality since it's pretty clear the WG is
> interested in updating TEAP and TEAP was already adopted by the WG (back in
> May 2011). With Alan having generated a new working version to host the
> update and even preparing a Git repository[2] to that end, I believe we're
> in a good place to revise RFC 7170. That said, if anyone has an objection
> to
> starting off from Alan's kind offering, please let us know by December 22,
> 2022.
>
> Joe and Peter
>
> 1) https://datatracker.ietf.org/doc/draft-dekok-emu-rfc7170bis/
> 2) https://github.com/alandekok/rfc7170-bis.git
>
>
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>


-- 
Heikki Vatiainen
h...@radiatorsoftware.com
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Adoption call for RFC 7170bis

2022-12-22 Thread Alan DeKok
On Dec 22, 2022, at 9:36 AM, Oleg Pekar  wrote:
> 
> I would like to provide comments as well. We should also bump the version of 
> the protocol so as not to harm the existing implementations (yes, they 
> implemented the spec with filed errata, the spec is sometimes ambiguous but 
> those implementations are already on the market).

  What we have is a situation where no one has implemented RFC 7170, and there 
is no practical path to implementing it.  As a result, the -bis revision is 
documenting the implementations.  i.e. "this is what's going on" versus "what 
should be going on".

  It would be more relevant to update the version when there are incompatible 
changes to the protocol, *and* existing implementations which need to know 
which version they're negotiating.

  Since there is only one "TEAP version 1", I would argue that there's no need 
to change the version.

  Plus, if we change the version, then people have no idea what's currently 
implemented.  TEAP version 1 becomes an undocumented mess of unknowns.

  As an implementor, I'm happy to declare RFC 7170 as irrelevant, and to issue 
a new standard which defines TEAP version 1 "as implemented".

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Adoption call for RFC 7170bis

2022-12-22 Thread Oleg Pekar
I would like to provide comments as well. We should also bump the version
of the protocol so as not to harm the existing implementations (yes, they
implemented the spec with filed errata, the spec is sometimes ambiguous but
those implementations are already on the market).

Regards,
Oleg

On Fri, Dec 16, 2022 at 12:29 AM Peter Yee  wrote:

> This is an adoption call for RFC 7170bis
> (draft-dekok-emu-rfc7170bis-00)[1].
> I'd call this mostly a formality since it's pretty clear the WG is
> interested in updating TEAP and TEAP was already adopted by the WG (back in
> May 2011). With Alan having generated a new working version to host the
> update and even preparing a Git repository[2] to that end, I believe we're
> in a good place to revise RFC 7170. That said, if anyone has an objection
> to
> starting off from Alan's kind offering, please let us know by December 22,
> 2022.
>
> Joe and Peter
>
> 1) https://datatracker.ietf.org/doc/draft-dekok-emu-rfc7170bis/
> 2) https://github.com/alandekok/rfc7170-bis.git
>
>
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu