Subject: [Id-event] I-D Action: draft-ietf-secevent-delivery-02.txt

From: [email-masked]
Date: Sun, 04 Mar 2018 20:16:52 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Security Events WG of the IETF.

        Title           : SET Token Delivery Using HTTP
        Authors         : Phil Hunt
                          Marius Scurtescu
                          Morteza Ansari
                          Anthony Nadalin
                          Annabelle Richard Backman
	Filename        : draft-ietf-secevent-delivery-02.txt
	Pages           : 26
	Date            : 2018-03-04

Abstract:
   This specification defines how a series of security event tokens
   (SETs) may be delivered to a previously registered receiver using
   HTTP POST over TLS initiated as a push to the receiver, or as a poll
   by the receiver.  The specification also defines how delivery can be
   assured subject to the SET Token Receiver's need for assurance.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-secevent-delivery/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-secevent-delivery-02
https://datatracker.ietf.org/doc/html/draft-ietf-secevent-delivery-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-secevent-delivery-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Phil Hunt <[email-masked]>
Date: Sun, 4 Mar 2018 20:28:21 -0800

This document contains some minor updates from Marius in advance of IETF101. The terminology for Identity Provider and Relying Party are dropped from the definitions section as they are no longer relevant to the draft.

Thanks,

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> On Mar 4, 2018, at 8:16 PM, [email-masked] wrote:
> 
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Ddelivery_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=VQHhRhtyrzqHrsoE9iLqwXq7xcrD53t2Glq0q1Z4kUo&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2Ddelivery-2D02&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=I5UYs-uys-eu8x8yw__YkvhzjapHK7e4j9NgP8ch36s&e=
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dsecevent-2Ddelivery-2D02&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=wq8KOLIkIklaw-WUKb79-no0qzcNqz6uJlpS-5VpM2o&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dsecevent-2Ddelivery-2D02&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=zJmsq0m9g-lNJiv76S48Vy0aQpIa7dSSsEslZSyfxGg&e=
> 
> 
> https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=kEqnjOUi11WqXEat4PujFnSrlxmgIdxCG5rOK2BwyjI&e=
> 
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=58FcylthfpumPRv2gSAssAKqfLy8P3r7LCYl1Jh8jd4&e=

---

From: Adam Dawes <[email-masked]>
Date: Sun, 4 Mar 2018 22:26:30 -0800

Generally looks fine. I think the main thing that need to be resolved is
what is MTI. From Singapore, there was a suggestion that it be up to the
transmitter to decide whether to push, pull or both. This is not ideal as
some Transmitters may support push while other Receivers may only be able
to accept pull. It seems there is a bit of an enterprise/consumer split
here where enterprise receivers are more likely to need pull to deal with
firewalls while consumer transmitters are likely to want to support only
push to protect themselves from polling load of high number of clients.

I don't see much way around this situation for the spec. It seems
unreasonable to force large consumer transmitters to take high frequency
polling from a large number of clients and it's impossible for some
enterprise receivers to get outside their firewall restrictions. I think
the only answer is with the formation of intermediary services. These can
serve as a queuing mechanism taking the signals from consumer Transmitters
and enabling polling of them by enterprise Receivers. Similarly, these
service providers could also poll for data form enterprise Transmitters
that only support polling and then post those events to consumer Receivers.

I think we should accept that forcing both push and pull on the whole
ecosystem is unreasonable and that if there is a high need for interop
between consumer and enterprise, service providers will step in to provide
the glue.

On Sun, Mar 4, 2018 at 8:28 PM, Phil Hunt <[email-masked]> wrote:

> This document contains some minor updates from Marius in advance of
> IETF101. The terminology for Identity Provider and Relying Party are
> dropped from the definitions section as they are no longer relevant to the
> draft.
>
> Thanks,
>
> Phil
>
> www.independentid.com
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__
> datatracker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Ddelivery_&d=DwICAg&c=
> RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=
> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx-
> yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=VQHhRhtyrzqHrsoE9iLqwXq7xcrD53
> t2Glq0q1Z4kUo&e=
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.
> ietf.org_html_draft-2Dietf-2Dsecevent-2Ddelivery-2D02&d=DwICAg&c=
> RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=
> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx-
> yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=I5UYs-uys-eu8x8yw__
> YkvhzjapHK7e4j9NgP8ch36s&e=
> https://urldefense.proofpoint.com/v2/url?u=https-3A__
> datatracker.ietf.org_doc_html_draft-2Dietf-2Dsecevent-
> 2Ddelivery-2D02&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=
> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx-
> yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=wq8KOLIkIklaw-WUKb79-
> no0qzcNqz6uJlpS-5VpM2o&e=
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dsecevent-
> 2Ddelivery-2D02&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=
> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx-
> yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=zJmsq0m9g-
> lNJiv76S48Vy0aQpIa7dSSsEslZSyfxGg&e=
>
>
> https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.
> org_internet-2Ddrafts_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIr
> MUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx-
> yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=kEqnjOUi11WqXEat4PujFnSrlxmgId
> xCG5rOK2BwyjI&e=
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=
> RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=
> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx-
> yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=58FcylthfpumPRv2gSAssAKqfLy8P3
> r7LCYl1Jh8jd4&e=
>
>
>
> https://www.ietf.org/mailman/listinfo/id-event
>
>

-- 
Adam Dawes | Sr. Product Manager | [email-masked] | +1 650-214-2410

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 5 Mar 2018 08:24:55 -0800

> between consumer and enterprise, service providers will step in to provide

The solution we discussed was to split the delivery draft into two: one
separate draft for push and another separate draft for poll. This way each
provider can chose to implement the delivery methods they want. This also
sets the precedent to create other delivery methods easily.

I will start a separate thread on this regard. Hopefully in London the
working group can have a discussion and decision around this.

>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatra
>> cker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Ddelivery_&
>> d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5
>> FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx-yW6HkoyQ0
>> kPujxicrDfv4Cg8XVNoGYmvE94&s=VQHhRhtyrzqHrsoE9iLqwXq7xcrD53t
>> 2Glq0q1Z4kUo&e=
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.i
>> etf.org_html_draft-2Dietf-2Dsecevent-2Ddelivery-2D02&d=DwICA
>> g&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWm
>> anqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx-yW6HkoyQ0kPujxic
>> rDfv4Cg8XVNoGYmvE94&s=I5UYs-uys-eu8x8yw__YkvhzjapHK7e4j9NgP8ch36s&e=
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatra
>> cker.ietf.org_doc_html_draft-2Dietf-2Dsecevent-2Ddelivery-
>> 2D02&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&
>> r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx-yW6H
>> koyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=wq8KOLIkIklaw-WUKb79-no0qz
>> cNqz6uJlpS-5VpM2o&e=
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>> f.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dsecevent-2Ddelivery-
>> 2D02&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&
>> r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx-yW6H
>> koyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=zJmsq0m9g-lNJiv76S48Vy0aQp
>> Ia7dSSsEslZSyfxGg&e=
>>
>>
>> org_internet-2Ddrafts_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv
>> 7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4K
>> ZNA&m=7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=kEqnjOUi
>> 11WqXEat4PujFnSrlxmgIdxCG5rOK2BwyjI&e=
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>> f.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHv
>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYq
>> PkAI1aLcLN4KZNA&m=7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE9
>> 4&s=58FcylthfpumPRv2gSAssAKqfLy8P3r7LCYl1Jh8jd4&e=
>>
>>
>>
> <(650)%20214-2410>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 5 Mar 2018 15:23:42 -0800

I agree polling is expensive, however the number of streams is minimal compared to the users being federated. After all this is a backchannel service. 

Push is complicated by management and status checking which occur in the opposite direction to the set delivery requiring mutual credential sets etc. 

Polling on the other hand could be done with a single set of credentials for delivery pick up and management. 

Further polling could be made bi directional—>halving the number of connections to support and manage. 

I am not saying go one way or another. Just want to hi-light that both have their pros and cons. 

Ps. There are a lot of network and firewall restrictions in backchannel data services in general.  This is not exclusive to enterprise firewalls. 

I suggest exploring more options during the week in London. 

Phil

> On Mar 4, 2018, at 10:26 PM, Adam Dawes <[email-masked]> wrote:
> 
> Generally looks fine. I think the main thing that need to be resolved is what is MTI. From Singapore, there was a suggestion that it be up to the transmitter to decide whether to push, pull or both. This is not ideal as some Transmitters may support push while other Receivers may only be able to accept pull. It seems there is a bit of an enterprise/consumer split here where enterprise receivers are more likely to need pull to deal with firewalls while consumer transmitters are likely to want to support only push to protect themselves from polling load of high number of clients. 
> 
> I don't see much way around this situation for the spec. It seems unreasonable to force large consumer transmitters to take high frequency polling from a large number of clients and it's impossible for some enterprise receivers to get outside their firewall restrictions. I think the only answer is with the formation of intermediary services. These can serve as a queuing mechanism taking the signals from consumer Transmitters and enabling polling of them by enterprise Receivers. Similarly, these service providers could also poll for data form enterprise Transmitters that only support polling and then post those events to consumer Receivers. 
> 
> I think we should accept that forcing both push and pull on the whole ecosystem is unreasonable and that if there is a high need for interop between consumer and enterprise, service providers will step in to provide the glue. 
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qx-E-WhdexG5sQGVjrd2O_twAAAmNFPWTX-hu-lOXRc&s=SMUEG_p7eYs9bej00Os13bVjLmmS9O7FNjpDt1kYMpo&e=

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 5 Mar 2018 15:26:46 -0800

There are definitely use cases for polling, this is not one vs the other
situation.

I am suggesting to decouple the two delivery methods.

Marius

On Mon, Mar 5, 2018 at 3:23 PM, Phil Hunt <[email-masked]> wrote:

> I agree polling is expensive, however the number of streams is minimal
> compared to the users being federated. After all this is a backchannel
> service.
>
> Push is complicated by management and status checking which occur in the
> opposite direction to the set delivery requiring mutual credential sets
> etc.
>
> Ps. There are a lot of network and firewall restrictions in backchannel
> data services in general.  This is not exclusive to enterprise firewalls.
>
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qx-E-WhdexG5sQGVjrd2O_twAAAmNFPWTX-hu-lOXRc&s=e8wG7FQVQMBIGQTJh0eu3PNrc7I0Qfu7_kLgMWRaGaY&e=>
>> [email-masked]
>>
>> until the htmlized version and diff are available at tools.ietf.org
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qx-E-WhdexG5sQGVjrd2O_twAAAmNFPWTX-hu-lOXRc&s=WlX9SWfd5N2s_gPLcSJenqpNgkGNuscisaSS6nsUsqs&e=>
>> .
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qx-E-WhdexG5sQGVjrd2O_twAAAmNFPWTX-hu-lOXRc&s=SMUEG_p7eYs9bej00Os13bVjLmmS9O7FNjpDt1kYMpo&e=>
>>
>>
>
>
> --
> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qx-E-
> WhdexG5sQGVjrd2O_twAAAmNFPWTX-hu-lOXRc&s=SMUEG_
> p7eYs9bej00Os13bVjLmmS9O7FNjpDt1kYMpo&e=
>
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Tue, 6 Mar 2018 00:07:49 +0000

+1 to decoupling them. There are strong use cases for each independent of the other. Nothing stops transmitters from implementing both for cases that warrant it.

--
Annabelle Richard Backman
Amazon – Identity Services

From: Id-event <[email-masked]> on behalf of Marius Scurtescu <[email-masked]>
Date: Monday, March 5, 2018 at 3:27 PM
To: Phil Hunt <[email-masked]>
Cc: Adam Dawes <[email-masked]>, SecEvent <[email-masked]>
Subject: Re: [Id-event] I-D Action: draft-ietf-secevent-delivery-02.txt

There are definitely use cases for polling, this is not one vs the other situation.

Marius

On Mon, Mar 5, 2018 at 3:23 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
I agree polling is expensive, however the number of streams is minimal compared to the users being federated. After all this is a backchannel service.

Phil

On Mar 4, 2018, at 10:26 PM, Adam Dawes <[email-masked]<mailto:[email-masked]>> wrote:
Generally looks fine. I think the main thing that need to be resolved is what is MTI. From Singapore, there was a suggestion that it be up to the transmitter to decide whether to push, pull or both. This is not ideal as some Transmitters may support push while other Receivers may only be able to accept pull. It seems there is a bit of an enterprise/consumer split here where enterprise receivers are more likely to need pull to deal with firewalls while consumer transmitters are likely to want to support only push to protect themselves from polling load of high number of clients.

On Sun, Mar 4, 2018 at 8:28 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
This document contains some minor updates from Marius in advance of IETF101. The terminology for Identity Provider and Relying Party are dropped from the definitions section as they are no longer relevant to the draft.

Thanks,

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qx-E-WhdexG5sQGVjrd2O_twAAAmNFPWTX-hu-lOXRc&s=e8wG7FQVQMBIGQTJh0eu3PNrc7I0Qfu7_kLgMWRaGaY&e=>
[email-masked]<mailto:[email-masked]>

On Mar 4, 2018, at 8:16 PM, [email-masked]<mailto:[email-masked]> wrote:

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qx-E-WhdexG5sQGVjrd2O_twAAAmNFPWTX-hu-lOXRc&s=WlX9SWfd5N2s_gPLcSJenqpNgkGNuscisaSS6nsUsqs&e=>.

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=58FcylthfpumPRv2gSAssAKqfLy8P3r7LCYl1Jh8jd4&e=

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qx-E-WhdexG5sQGVjrd2O_twAAAmNFPWTX-hu-lOXRc&s=SMUEG_p7eYs9bej00Os13bVjLmmS9O7FNjpDt1kYMpo&e=>

--
Adam Dawes | Sr. Product Manager | [email-masked]<mailto:[email-masked]> | +1 650-214-2410<tel:(650)%20214-2410>

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qx-E-WhdexG5sQGVjrd2O_twAAAmNFPWTX-hu-lOXRc&s=SMUEG_p7eYs9bej00Os13bVjLmmS9O7FNjpDt1kYMpo&e=

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