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

[Justin Richer <[e-mail]>]

If you can carry multiple profiled payloads together, which profile gets 
to decide the semantics of the combination?

Answering this question in any reasonable fashion is exactly why I favor 
the new format over the current, and it gets at what I was attempting 
with the current format.

  -- Justin


On 12/5/2017 4:30 PM, Mike Jones wrote:
>
> 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]>
> *Cc:* Mike Jones <[e-mail]>; William Denniss 
> <[e-mail]>; M.Lizar@OCG <[e-mail]>; 
> Yaron Sheffer <[e-mail]>; Dick Hardt 
> <[e-mail]>; SecEvent <[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]
> https://www.ietf.org/mailman/listinfo/id-event