On Thu, 3 Aug 2023 at 21:34, Alan DeKok <al...@deployingradius.com> wrote:
The diff is perhaps more interesting: > https://author-tools.ietf.org/iddiff?url1=draft-ietf-emu-rfc7170bis-09&url2=draft-ietf-emu-rfc7170bis-10&difftype=--html > > * clarify terminology on inner / outer TLVs as per Eliot's suggestion > Two minor suggestions: 1. Capitalise 'inner' in the section header 2. End the 'Inner TLVs' definition with '... but no Outer TLVs are used'. Here ' are used' is new text. That makes it symmetric with the previous sentence and doesn't hint that Outer TLVs may sometime be encapsulated within TLS records. > * add paragraphs on resumption and provisioning as per recent discussion > on the list. > I like these changes. They give guidance for handling TLS resumption and possible authorisation changes the renewed credentials or other provisioned information may require. > I believe that this addresses all concerns. > I think so too. One thing I thought is the case where re-provisioning is a larger task which begins with TEAP in-band re-provisioning and then continues with, for example, HTTPS based device update in a special VLAN. That is, RADIUS Access-Accept assigns a separate virtual LAN for doing the HTTPS part. In this case the device needs to reconnect, or needs to be disconnected, once it has finished its re-provisioning over HTTPS. The server must invalidate any possible TLS resumption which would put the device back to the (re)-provisioning VLAN. However, I think this is outside of scope of this draft/RFC and is something that the device/application and server software vendor must take care of. The new text in the draft is enough now. -- Heikki Vatiainen h...@radiatorsoftware.com
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
