Re: [Id-event] Consensus :: Single Event Syntax

["Richard Backman, Annabelle" <[e-mail]>]

Phil,

As the author of the current draft, can you clarify whether these restrictions are intentional, and if so why the use cases for SET are being restricted in this way?

--
Annabelle Richard Backman
Amazon – Identity Services


From: "Richard Backman, Annabelle" <[e-mail]>
Date: Monday, December 11, 2017 at 10:09 AM
To: Justin Richer <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

The current syntax doesn’t even work for the professed use case, without two unstated constraints:

  1.  Two instances of a single type of event statement cannot be related to the same logical event.
  2.  The combination of event statements cannot be ambiguous.

If the current draft intends to impose these limits, they need to be stated in the text. But more importantly, what is the basis for imposing these limitations on SET in the first place?

--
Annabelle Richard Backman
Amazon – Identity Services


From: Id-event <[e-mail]> on behalf of Justin Richer <[e-mail]>
Date: Saturday, December 9, 2017 at 6:04 AM
To: "[e-mail]" <[e-mail]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax


So the current syntax doesn't work for Tony's stated use case of even bundles while the new syntax does, then.

On 12/5/2017 5:50 PM, Mike Jones wrote:
The “events” claim definition is already clear that the “events” values convey multiple aspects of a single logical event - not independent events.  Section 2.1 (Core Set Claims) says:
   events
      The semantics of this claim is to define a set of event statements
      that each MAY add additional claims to fully describe a single
      logical event that has occurred (e.g. a state change to a
      subject). … The "events" claim SHOULD NOT be used to express
      multiple logical events.

You’re describing a theoretical problem that’s not actually present in the working group spec.

                                                                -- Mike

From: Richard Backman, Annabelle [mailto:[e-mail]]
Sent: Tuesday, December 5, 2017 2:06 PM
To: Mike Jones <[e-mail]><mailto:[e-mail]>; Phil Hunt <[e-mail]><mailto:[e-mail]>
Cc: William Denniss <[e-mail]><mailto:[e-mail]>; M.Lizar@OCG <[e-mail]><mailto:[e-mail]>; Yaron Sheffer <[e-mail]><mailto:[e-mail]>; Dick Hardt <[e-mail]><mailto:[e-mail]>; SecEvent <[e-mail]><mailto:[e-mail]>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

Once again, I am not talking about the meaning of a given event type or its contents. I’m talking about the meaning of putting an event in an “events” claim alongside another event in the same SET.

Drawing an analogy to programming, I’m talking about defining what the syntax “function_x() && function_y()” means. Regardless of what “function_x” and “function_y” mean, the language defines the meaning of that syntax as “true if the result of function_x is true and the result of function_y is true.”

--
Annabelle Richard Backman
Amazon – Identity Services


From: Mike Jones <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, December 5, 2017 at 1:30 PM
To: Phil Hunt <[e-mail]<mailto:[e-mail]>>, "Richard Backman, Annabelle" <[e-mail]<mailto:[e-mail]>>
Cc: William Denniss <[e-mail]<mailto:[e-mail]>>, "M.Lizar@OCG<mailto:M.Lizar@OCG>" <[e-mail]<mailto:[e-mail]>>, Yaron Sheffer <[e-mail]<mailto:[e-mail]>>, Dick Hardt <[e-mail]<mailto:[e-mail]>>, SecEvent <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Id-event] Consensus :: Single Event Syntax

Hi Annabelle,

The data contained in a SET and the semantics of that data will *always* be profile-specific.  That’s a feature – not a bug.  It’s what makes SETs general-purpose, rather than being suited only for a narrow set of use cases.

An analogy with JWTs is applicable.  JWTs have no required claims, so their usage is always profile-specific.  That has enabled them to be adopted by numerous diverse applications.  SETs currently have that same level of flexibility – by design.

                                                                -- Mike

From: Phil Hunt [mailto:[e-mail]]
Sent: Tuesday, December 5, 2017 1:22 PM
To: Richard Backman, Annabelle <[e-mail]<mailto:[e-mail]>>
Cc: Mike Jones <[e-mail]<mailto:[e-mail]>>; William Denniss <[e-mail]<mailto:[e-mail]>>; M.Lizar@OCG<mailto:M.Lizar@OCG> <[e-mail]<mailto:[e-mail]>>; Yaron Sheffer <[e-mail]<mailto:[e-mail]>>; Dick Hardt <[e-mail]<mailto:[e-mail]>>; SecEvent <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

I would disagree strongly with the notion of inter-operability requirements on expected outcomes or actions by receivers.

SETs are statements of changes in state of security objects by transmitters. SETs do not indicate any specific actions that should be taken by receivers.

I believe I’ve covered this issue during the informal BOF (at the SCIM WG meeting Argentina) and several times during IETF WG meeting presentations. I did so, because within the IETF community many people have vastly different notions of what an event is.

Phil

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




On Dec 5, 2017, at 12:57 PM, Richard Backman, Annabelle <[e-mail]<mailto:[e-mail]>> wrote:

Mike,

This isn’t simply an issue of “single vs multiple” – the current draft is fundamentally broken from an interoperability standpoint, because the correct interpretation of the “events” claim is at best profile-specific, at worst implementation-specific.

--
Annabelle Richard Backman
Amazon – Identity Services


From: Mike Jones <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, December 5, 2017 at 12:22 PM
To: "Richard Backman, Annabelle" <[e-mail]<mailto:[e-mail]>>, William Denniss <[e-mail]<mailto:[e-mail]>>, "M.Lizar@OCG<mailto:M.Lizar@OCG>" <[e-mail]<mailto:[e-mail]>>
Cc: Yaron Sheffer <[e-mail]<mailto:[e-mail]>>, Phil Hunt <[e-mail]<mailto:[e-mail]>>, SecEvent <[e-mail]<mailto:[e-mail]>>, Dick Hardt <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Id-event] Consensus :: Single Event Syntax

Morteza already pointed out<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_id-2Devent_KPaK5aN3EeIybWJmQOJiqdHXQzg&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=ZClAgy65x4a1O93YYenj_z_6Bxd_6sMzPOs8PLi06XA&e=> a simple solution to enabling SETs to contain only a single event description for profiles that want that – a solution proposed by Yaron<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00736.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=tac2j_cTgyBwnnfHNTPzlRUwOCjxvascShR4JfccwMg&e=> that doesn’t involve making any breaking changes:  Explicitly specify that profiles can restrict the number of elements in the “events” data structure – including limiting them to one element, when desired.  Then profiles that want this can have it and profiles that need to enable multiple aspects of an event to be easily represented can have that too.  Hopefully people can rally around that straightforward solution, enabling us to move on and finish the SET spec in as timely a fashion as possible.

                                                                -- Mike

From: Id-event [mailto:[e-mail]] On Behalf Of Richard Backman, Annabelle
Sent: Tuesday, December 5, 2017 11:40 AM
To: William Denniss <[e-mail]<mailto:[e-mail]>>; M.Lizar@OCG<mailto:M.Lizar@OCG> <[e-mail]<mailto:[e-mail]>>
Cc: Yaron Sheffer <[e-mail]<mailto:[e-mail]>>; Phil Hunt <[e-mail]<mailto:[e-mail]>>; SecEvent <[e-mail]<mailto:[e-mail]>>; Dick Hardt <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

William’s email analogy demonstrates the problem with the current syntax: imagine if the text part of a multi-part email could be any of the following, with no explicit indication which one it is:

  *   A plaintext representation of the same content in the HTML part.
  *   The CSS to use when rendering the HTML part.
  *   Annotations on the contents of the HTML part.
  *   A vCard for the sender of the message.
  *   A completely separate message with a separate subject line embedded in the text.

How would a mail reader know what to do with this? It couldn’t, not in any scalable way. Yet is exactly the situation we will have, given the current draft and the way people are proposing using its multi-part capability:

  *   William wants to use it to send different independent representations of the same event.
  *   Phil wants to use it to send different aspects of the same event, intended to be processed together.
  *   Tony wants to use it for directory synchronization.
  *   Marius wants to use it to send the same event under both standard and deprecated names.
  *   et cetera, et cetera…

This confusion is going to limit reusability and interoperability, and hinder adoption. If the WG consensus is that all these use cases are in scope for SET, that’s fine, we can support them – but we need to do so in a way that doesn’t create complete chaos.

At risk of repeating myself, maybe we need to have a consensus discussion on which multi-part use cases are in scope for SET before we continue with this discussion?

--
Annabelle Richard Backman
Amazon – Identity Services


From: Id-event <[e-mail]<mailto:[e-mail]>> on behalf of William Denniss <[e-mail]<mailto:[e-mail]>>
Date: Monday, December 4, 2017 at 7:20 PM
To: "M.Lizar@OCG<mailto:M.Lizar@OCG>" <[e-mail]<mailto:[e-mail]>>
Cc: Yaron Sheffer <[e-mail]<mailto:[e-mail]>>, Dick Hardt <[e-mail]<mailto:[e-mail]>>, SecEvent <[e-mail]<mailto:[e-mail]>>, Phil Hunt <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Id-event] Consensus :: Single Event Syntax

I would prefer to keep the format in the current working group draft.

Based on the requirement that events may be represented in multiple ways, I believe having both formats carried in a single SET is superior as it avoids complex linking logic. The best analogy I can think of is email, where MIME allows for text and html versions *of the same content* to be carried in a single email (much like how SET allows for multiple representations *of the same event* in a SET). With email, the recipient's client is then able to display the version it prefers from those available. Imagine the additional logic if every email was sent twice – e.g. what if the plain text version arrives, the HTML one is delayed? How should the client react if the HTML version arrives later, would it replace the version it had? What if you were already viewing and/or replying?

Time-wise I'm really concerned if we don't lock this down soon, the people who are waiting on us to profile SET will walk away and do their own thing (I was worried about that a year ago… and I think we've waited long enough). I think we should keep this in mind and choose the path that will have the fastest resolution.  If the decision was to change the format at this late stage, I would like to hear what steps can be done to avoid additional delay.

I really respect the work Annabelle has done in leading the alternative representation, and I do think it’s a viable alternative. If we choose to change the spec and go with the singular option, then I think the requirement of multiple representations should be dropped, or at a minimum de-emphasized as this (along with expediency) is the main reason I believe the existing format is better.


On Mon, Dec 4, 2017 at 1:08 PM, M.Lizar@OCG<mailto:M.Lizar@OCG> <[e-mail]<mailto:[e-mail]>> wrote:
Small typo,  -  should be a  ‘.’ Not a ‘?’

The spec works well for the consent a privacy syntax use cases we are aware of (full stop)

- Mark

On 4 Dec 2017, at 20:46, M.Lizar@OCG<mailto:M.Lizar@OCG> <[e-mail]<mailto:[e-mail]>> wrote:


I concur with Mike and Justin, we had the same issue with primary and secondary in the Consent Receipt spec.

We are also opposed  to making breaking changes at this late date and that the existing working group spec already works well for the consent and privacy use cases we are aware of?

Mark Lizar | CEO Open Consent | Co-Char CISWG at Kantara

On 1 Dec 2017, at 18:35, Phil Hunt <[e-mail]<mailto:[e-mail]>> wrote:

For historical purposes, this has been discussed twice before (once at the request of Annabelle).

I think it would be helpful, why, after WGLC, this issue is being brought forward yet again. Dick has stated that Annabelle’s concern that she finds it difficult to implement is sufficient.  Yet, I’m not sure we are entertaining a new concern here. No new information was provided.

I note that at the time, the chairs did not feel there was a lack of consensus in order to call for one in the past.

On some of these matters, the choice may be arbitrary, and that is why I think keeping track of prior discussion is important so that we can clearly move forward and not repeat discussion of the past further confusing consensus.

While I advocated for singular events as a possibility in the past, I now have much more stronger technical reasons for the WG draft design, which have strengthened rather than weakened in the past week. I will share these later, after the minutes have been published.

On Dec 10, 2016, Yaron while reviewing the ID draft-hunt-idevent-token-07 [1]:

  * Why "events" and not "event"? We don't really have support for

    multiple events. Certainly not if they are all of the same type.

    The current text is confusing: "events" is not the same as "a

    primary event and its extensions”.

[MIKE] Reflects your earlier comment re: primary vs. extensions.  "events” is

plural to reflect the fact that the attribute is multi-valued. I agree,

given that only one primary event can be included, the naming is misleading.

From later in the thread [2]:
 * 2: "first value" is meaningless. JSON objects are unordered (4th
   paragraph of RFC 7159). If order /is/ important, we could make
   "events" into an array.
[Phil] Yup.   How would the group like to fix this?  We could make “events”
singular and have an extensions attribute to hold the extensions.  Or we
could go to a more complex JSON structure (not personally a fan).

[Yaron] I'm personally fine with a main "event" object and an "extensions" attribute. I can even live with "event" being called "events", per Mike's proposal. But the structure needs to make sense as a JSON object if we want it implemented.

[PH] Thread: Should the primary event be a separate attribute?

We had this broken out before. If there is sufficient desire to break it out again, I have no objection.


Then following WG adoption, I re-reraised the issue after discussion with Annabelle draft-secevent-token-00 [3]:
On this topic, following Yaron’s comments Mike Jones raised some points that there should be no distinction between primary events and extensions (https://mailarchive.ietf.org/arch/msg/id-event/0Hhg46ROcidQDLL7OnXUs88TJ9U<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_id-2Devent_0Hhg46ROcidQDLL7OnXUs88TJ9U&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=8DBZ5hsA4WNFez3mJr2W9TW0WCYTWMbY1Vs5sgcIauQ&e=>).  Summarizing:
* Processors will run through all of them regardless. It is not necessarily helpful to understand which is a primary vs. extension
* Let’s drop distinction between primary vs. extension. You can simply express one or more sets of event attributes in a single JWT

My proposal is to drop this terminology in the text and keep the attribute multi-valued. The purpose of the attribute is to inform the reader what events are being asserted and what additional data may be present. It is up to the reader to ultimately infer meaning when one or more URIs are present.  Further, when multiple URIs are present it must still to make a combined statement about a single state change about a subject. It must not be used to convey multiple distinct (e.g. transactions) events about a subject.

Assuming everyone agrees, I will plan to remove these distinctions in the next update with some new text. Please comment if you have concerns.

To which Mike Jones responded [4]
I believe we already had consensus to drop the primary/secondary distinction, which we intentionally did before adoption of the working group draft.  I believe any such distinction will both be unhelpful and result in syntactic complexity.  Please let’s finish stamping out the notion that any of the events in a SET are somehow different than the others.

William Denniss wrote [5]:
I agree with your proposal.

They're all just events. Up to implementors to define & categorize their events how they like.

Marius also agreed (he may have switched positions now) [6]:
I also think it makes sense to remove the primary/secondary distinction.

Marius

Justin also agreed (and may have switched positions) [7]
+1, drop "primary" and keep it an object
 -- Justin


References:
[1] - https://www.ietf.org/mail-archive/web/id-event/current/msg00298.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00298.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=rG_9NWsC86NC5EDI8paY2lIrUkHUirGG3jfmoHhYAw8&e=>
[2] - https://www.ietf.org/mail-archive/web/id-event/current/msg00299.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00299.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=wE8wEkrp-0wxrzKFqozLAsjsD2qgA2mCoDZQp5lwqdA&e=>
[3] - https://www.ietf.org/mail-archive/web/id-event/current/msg00345.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00345.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=QEGxsGOAn3D6pmmzeLtQ_gkOSgxpq-8ce2CbXfe2Zk8&e=>
[4] - https://www.ietf.org/mail-archive/web/id-event/current/msg00347.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00347.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=IcdLUKGzpKm8QwfE2mo-NufvoiWgjsj__BKRvGGod8c&e=>
[5] - https://www.ietf.org/mail-archive/web/id-event/current/msg00349.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00349.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=d0uNsjizWSlLYksDHdqZaYC6Ix0OMDltFs2e4QjTJJE&e=>
[6] - https://www.ietf.org/mail-archive/web/id-event/current/msg00365.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00365.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=_FtWiNomXopU9A9_k7A1nsjMQfaXZ_ZjxgBxNrhUBIQ&e=>
[7] - https://www.ietf.org/mail-archive/web/id-event/current/msg00406.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00406.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=k5JC5HYCfm0BtQJar8_ZAKRUzgUsJYaCbtiLWOkWxJc&e=>

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=zQiT4vu41M1sH4KXtpfMbiC5yDIIPxJ8Vp35knc8EHk&e=>
[e-mail]<mailto:[e-mail]>

On Dec 1, 2017, at 8:50 AM, Dick Hardt <[e-mail]<mailto:[e-mail]>> wrote:

Is it important to syntactically ensure that only one event is in a SET?
For privacy reasons, some use cases want to ensure that only one signal is in a SET.
This adds some additional complexity for use cases that want to include multiple signals in a SET.
See https://tools.ietf.org/html/draft-backman-secevent-token-02<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbackman-2Dsecevent-2Dtoken-2D02&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=p986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY&s=P-rrbMomS-aMBQQ0HPfPzvNPkWHLDYs8SsugRHx-eLM&e=> for an proposed syntax that ensures one event per SET, and enables multiple events per SET when desired

We will track results here: https://github.com/IETF-SecEvent/Drafts/issues/1<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-2DSecEvent_Drafts_issues_1&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=p986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY&s=3f7fFs9ZKZrg1ScI3Ml2r8ykvHGuBbup831kDUNklfw&e=>

Discussion to be on the mail list as usual, not in the issue tracker!

/Dick
_______________________________________________
Id-event mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=p986FFBYCnXfbWjoBBpAe4IarEj1m7ezmVE3DPSQzwY&s=YnAKATJz3qVYniVaDUIMtQb9L-vMocgsYARzV6axzq4&e=

_______________________________________________
Id-event mailing list
[e-mail]<mailto:[e-mail]>
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=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=oLqIO9IaQ6D37NOtw81qGSXjq-PmKhkF_tUZSc2sXBw&e=>

_______________________________________________
Id-event mailing list
[e-mail]<mailto:[e-mail]>
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=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=oLqIO9IaQ6D37NOtw81qGSXjq-PmKhkF_tUZSc2sXBw&e=>


_______________________________________________
Id-event mailing list
[e-mail]<mailto:[e-mail]>
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=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=oLqIO9IaQ6D37NOtw81qGSXjq-PmKhkF_tUZSc2sXBw&e=>

_______________________________________________
Id-event mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=64Sgt5nlxmOs0NbkKq3UqYItitj7fiunLlki9iJlcEk&s=oLqIO9IaQ6D37NOtw81qGSXjq-PmKhkF_tUZSc2sXBw&e=






_______________________________________________

Id-event mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/id-event