Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London)

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 9 Apr 2018 16:06:25 -0500

On Fri, Mar 30, 2018 at 10:53:23AM +0000, Mike Jones wrote:
> I agree with Phil that having separate push and pull delivery drafts would be a mistake.  Many participants will end up implementing both modalities.  Having them both in one draft will help keep them as common as possible - preventing unnecessary and possibly unintended drift between them.
> 
> Also, as I said at the microphone in London, I think we'll have a much easier time with the IESG taking one draft forward with two closely related delivery modalities defined, rather that two different delivery drafts.  I fear that if we try to get approval for two drafts, we might receive DISCUSS feedback saying "pick one".

With my AD hat on, it's my sense that this IESG does not uniformly push back
against drafts or WGs that come forward with two similar-but-distinct solutions;
rather, this IESG pushes back in that case only when there is not a documented
need for the different options.  That is, it seems that we do have clear use
cases for both push and pull, and so long as we include descriptions of those
use cases in the respective document(s), the IESG is willing to accept that.

-Ben

---

From: John Bradley <[email-masked]>
Date: Mon, 9 Apr 2018 18:30:56 -0300

I think splitting the drafts was an attempt to get around declaring one or the other method MTI.  

Clearly due to deployment constraints many people will only be able to do one or the other.  

Having them both in the same draft would be best if we don’t wind up having to declare one or both MTI.

John B.
> On Mar 30, 2018, at 7:53 AM, Mike Jones <[email-masked]> wrote:
> 
> For what it's worth (and to inform people who weren't in the room), my personal sense was that the hums weren't conclusive.  Most of them had significant portions of people humming for both positions.  In short, my (personal) sense was there wasn't clear consensus demonstrated to split the delivery draft.  I think the topic needs more discussion on the list.
> 
> 				Best wishes,
> 				-- Mike
> 
> -----Original Message-----
> From: Id-event <[email-masked]> On Behalf Of Phil Hunt
> Sent: Thursday, March 29, 2018 10:15 PM
> To: Yaron Sheffer <[email-masked]>
> Cc: SecEvent <[email-masked]>
> Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London)
> 
> Regarding the hums, I think they may be premature. In part, because there is a unifying draft proposal available now. 
> 
> When we formed the group the sole purpose was a common format and a single delivery draft for all cases. 
> 
> Several ietf people complained in Argentina about yet another pub sub system the ietf does not need. 
> 
> Another comment was made not to follow the route stix/taxii made in developing multiple incompatible methods of delivery. 
> 
> If we split the draft we will have 3 methods not two(including Backchannel). 
> 
> I worry this will lead to delay from rejection down the road. This should be clarified first. 
> 
> I worry with multiple methods, profilers will develop their own undermining the point of this work. 
> 
> Maybe I stand alone here, but I think splitting is a mistake. 
> 
> Phil
> 
>> On Mar 24, 2018, at 8:00 AM, Yaron Sheffer <[email-masked]> wrote:
>> 
>> Thank you Valery for taking the minutes. All, please let us know if anything is incorrect or missing.
>> 
>> In addition, we had a series of hums on the SET Delivery draft. Per IETF process, we need to validate them on the list. So if you weren't in the room and you have a major objection to the results of these hums, please speak up. I do suggest that before doing so, you review the actual recorded meeting: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3Dr0hbpQqsN6s&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=bZnIUtQK2S3enqQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=VbJxhADDKAULj3hrOYI1cbC5A8hEmFIesTvuGzkkOP0&e=.
>> 
>> IETF 101 London Friday 23 March 2018 9:30 - 11:30
>> 
>> [Yaron] (WG status update, agenda bashing) [Annabelle] asks for 10 
>> minutes for discussion
>> 
>> [Mike] (presents Security Event Token draft update)
>> 
>> [Annabelle] (presents SET Token delivery using HTTP draft) [Mike] 
>> Microsoft needs for both POLL and PUSH [Phil] Redefining smth in HTTP 
>> may cause problems [William] Return codes are only for browsers to 
>> display messages for users [Phil] It's needed for resending in case of 
>> error (?) [Annabelle] What is MTI - push or poll?
>> [Phil] With PUSH  happened immediately...
>> [Leif] What is MTI for server or for client?
>> [William] Each option has an explicit use case [Yaron (as chair)] We 
>> need to have only one preferred option [Phil] There are very different 
>> cases [Phil] Push is simple, but in terms of applicability it's not a 
>> long term use case [Annabelle] There use cases for both [Phil] Take 
>> two and then abandon one [William] Why does the chair require a single 
>> MTI [Leif] It's from chair's experience, WG consensus needed [William] 
>> We have use cases for both [Mike] Procedurally it's better to keep 
>> both methods in one draft [Yaron] Having two methods complicates the 
>> description which method is for which situation etc.
>> [William] Still have interoperability issue for receiver [Yaron] Need 
>> to resolve this [Leif] WG should decide [Ben as AD] If the WG doesn't 
>> select a single method the IESG would probably object [Annabelle] SET 
>> will probably be profiled for different use cases [Yaron] Is going to 
>> make hums about selecting a single delivery method and whether we need 
>> to split the draft [John] What is hum about - mandatory to implement or to deploy?
>> [Leif] We should analyze scenarios
>> [Annabelle] The protocol are unidirectional, so MTI for 
>> transmitter/receiver is problematic [Justin] No negotiation, either it 
>> is or not, MTI for the receiver is dictated by what the receiver 
>> supports [Phil] They both must be able HTTP, the roles can be changed 
>> [Leif] Confusion between MTI and to deploy, a good question - select 
>> MTI for transmitter [Annabelle] Every transmitter should have both 
>> [Tero] Minimal implementation requires one, bigger may have both, 
>> single MTI is better then two for limited devices [Annabelle] IoT 
>> implementers have special requirement [William] They are application 
>> specific, we expected profile this [Yaron] Hum if we need a single MTI 
>> for transmitter - silence Later edit: Clearly no support for a single MTI.
>> [Justin] Hum must be for multiple discrete options [Yaron] Hum on use 
>> cases for two methods - some hums [Yaron] Hum if both should be MTI - 
>> some hums [Yaron] Hum if should not specify MTI - some hums Later 
>> edit: room was split between two MTIs and no MTIs.
>> [Annabelle] We should split the spec
>> [Justin] Agree to split the spec
>> [Justin] I hummed for both MTI for transmitter, because they are not 
>> usually constrained [Annabelle] SET is possibly to be used w/o HTTP, 
>> this is only MTI for those using HTTP; both MTI is problematic because 
>> implementers will do unnecessary stuff [William] If both are MTI, we 
>> need 2 specs [John] Splitting the spec is the best way [Mike] If 
>> split, then the information for developers will be duplicated [Ben] 
>> Why single document better (?) [Mike] My experience with JOSE 
>> [Annabelle] Significant overlap between documents is SET, otherwise 
>> little commonality Later edit: existing editors volunteered to take Push-specific doc, Annabelle and Mike volunteered to work on Poll.
>> [from jabber] Little commonality between two methods [Mike] We'll do 
>> both, we have use cases for both [Yaron] Hum if split documents - some 
>> long hums [Yaron] Hum if one document - some hums [Yaron] Room is in 
>> favor of splitting the documents [Yaron] Wrap up: no MTI, split the 
>> document into two, transmitter implements either or both
>> 
>> [Annabelle] (presenting Subject Identifier Types) [Mike] 3rd party 
>> specifications cannot establish IANA registry [Leif] IANA Expert?
>> [Ben] FCFS, doesn't need Expert, or specification required [Leif] I 
>> support this idea [William] I also support [Yaron] Any objections to 
>> adopt this document? No objections, publish as WG document
>> 
>> [Annabelle] Expiration ("exp") claim is not recommended; however it 
>> has some value [Mike] It's a layering violation; problems with caching 
>> [Annabelle] We're not talking about caching, you don't want to grow 
>> anti-replay database forever, having expiration helps [Phil] The past 
>> doesn't expire, it's up to receiver how to use it, caching doesn't make sense [Yaron] What about replay protection?
>> [Mike] JTI helps to detect replay (?) [from jabber] Transport should 
>> deal with replay [John] Expiry is expected to mean that token should 
>> not be processed after that, it's not an indication that information 
>> is no longer valid [Mike] It must not be mandatory [Annabelle] 
>> Currently the draft says it's not recommended [Mike] We have to allow it to be optional because of the need to distinguish from access tokens.
>> [Ben] Some use case when processing expired token (?) [John] Have an 
>> explicit expire for JTI, there are other solutions [Phil] I prefer to 
>> add a new attribute to SET, not changing ...
>> [Yaron] The document in LC, smaller changes are OK without blocking the doc's progress.
>> [Phil] Replay and caching are different for PUSH and POLL, prefer to 
>> see in HTTP header [Brian] Expiration is not necessary, receiver has 
>> policy to follow [Annabelle] No-one is advocating using exp for 
>> caching [from jabber] JTI expiration belongs to JTI not to transport 
>> [Yaron] We're not ready to have hum, room thinks there is an issue, please work through it on the list.
>> 
>> [Phil] Presents his SSTP Delivery draft - symmetric transport 
>> protocol, parameters used in requests and response are same [Phil] We 
>> would change optionality from two methods to a single one, may be a compromise [Yaron] The protocol was only published yesterday, so we are not ready to discuss now.
>> 
>> [Meeting adjourned.]
>> 
>> _______________________________________________
>> Id-event mailing list
>> [email-masked]
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
>> man_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65
>> eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=bZnIUtQK2S3en
>> qQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=bm9Kqkwb8W8ClkdHFvnnH60BmArjysl02dP_3
>> TAjwew&e=
> 
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
> 
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 9 Apr 2018 14:35:24 -0700

> I think splitting the drafts was an attempt to get around declaring one or

That, and also to allow the two delivery methods to mature at their own
speed and not tie one to the other. Push has implementations and there is
no reason holding it back from LC for example, or rushing Poll when it is
not ready.

> having to declare one or both MTI.

What is the advantage of having both in same draft?

> > I agree with Phil that having separate push and pull delivery drafts
> would be a mistake.  Many participants will end up implementing both
> modalities.  Having them both in one draft will help keep them as common as
> possible - preventing unnecessary and possibly unintended drift between
> them.
> >
> > Also, as I said at the microphone in London, I think we'll have a much
> easier time with the IESG taking one draft forward with two closely related
> delivery modalities defined, rather that two different delivery drafts.  I
> fear that if we try to get approval for two drafts, we might receive
> DISCUSS feedback saying "pick one".
> >
> > For what it's worth (and to inform people who weren't in the room), my
> personal sense was that the hums weren't conclusive.  Most of them had
> significant portions of people humming for both positions.  In short, my
> (personal) sense was there wasn't clear consensus demonstrated to split the
> delivery draft.  I think the topic needs more discussion on the list.
> >
> >                               Best wishes,
> >                               -- Mike
> >
> > Regarding the hums, I think they may be premature. In part, because
> there is a unifying draft proposal available now.
> >
> > Another comment was made not to follow the route stix/taxii made in
> developing multiple incompatible methods of delivery.
> >
> >> In addition, we had a series of hums on the SET Delivery draft. Per
> IETF process, we need to validate them on the list. So if you weren't in
> the room and you have a major objection to the results of these hums,
> please speak up. I do suggest that before doing so, you review the actual
> recorded meeting: https://urldefense.proofpoint.
> com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3Dr0hbpQqsN6s&d=DwICAg&c=
> RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=
> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=
> bZnIUtQK2S3enqQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=
> VbJxhADDKAULj3hrOYI1cbC5A8hEmFIesTvuGzkkOP0&e=.
> >>
> >> little commonality Later edit: existing editors volunteered to take
> Push-specific doc, Annabelle and Mike volunteered to work on Poll.
> >> doesn't expire, it's up to receiver how to use it, caching doesn't make
> sense [Yaron] What about replay protection?
> >> Currently the draft says it's not recommended [Mike] We have to allow
> it to be optional because of the need to distinguish from access tokens.
> >> would change optionality from two methods to a single one, may be a
> compromise [Yaron] The protocol was only published yesterday, so we are not
> ready to discuss now.
> >>
> >> [Meeting adjourned.]
> >>

---

From: John Bradley <[email-masked]>
Date: Mon, 9 Apr 2018 18:38:55 -0300

Fewer specs for people to read and perhaps being able to better explain the reasons for choosing one or the other.

> On Apr 9, 2018, at 6:35 PM, Marius Scurtescu <[email-masked]> wrote:
> 
> On Mon, Apr 9, 2018 at 2:30 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
> That, and also to allow the two delivery methods to mature at their own speed and not tie one to the other. Push has implementations and there is no reason holding it back from LC for example, or rushing Poll when it is not ready.
> 
> 
> 
Fewer specs for people to read and perhaps being able to better explain the reasons for choosing one or the other.

I was OK with two drafts to make progress.  

> 
>  
> 
> John B.
> > On Mar 30, 2018, at 7:53 AM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > From: Id-event <[email-masked] <mailto:[email-masked]>> On Behalf Of Phil Hunt
> > To: Yaron Sheffer <[email-masked] <mailto:[email-masked]>>
> > Cc: SecEvent <[email-masked] <mailto:[email-masked]>>
> >> On Mar 24, 2018, at 8:00 AM, Yaron Sheffer <[email-masked] <mailto:[email-masked]>> wrote:
> >>
> >> In addition, we had a series of hums on the SET Delivery draft. Per IETF process, we need to validate them on the list. So if you weren't in the room and you have a major objection to the results of these hums, please speak up. I do suggest that before doing so, you review the actual recorded meeting: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3Dr0hbpQqsN6s&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=bZnIUtQK2S3enqQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=VbJxhADDKAULj3hrOYI1cbC5A8hEmFIesTvuGzkkOP0&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3Dr0hbpQqsN6s&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=bZnIUtQK2S3enqQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=VbJxhADDKAULj3hrOYI1cbC5A8hEmFIesTvuGzkkOP0&e=>.
> >>
> >> [email-masked] <mailto:[email-masked]>
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail>
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Mon, 9 Apr 2018 22:13:27 +0000

I definitely agree that we shouldn't specify an MTI at the protocol spec. I think each profile should be specifying that as part of the profile definition and semantics.

And if we don’t have an MTI at the protocol document, I think we are much better off with a single protocol document covering different protocols in the same document. It will be all in one place for developer to choose, much easier to maintain the common language common and not let them diverge, and we could even describe scenarios one would be preferred over the other as hints and suggestion to the developers.

Cheers,
Morteza

On 4/9/18, 2:31 PM, "Id-event on behalf of John Bradley" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    John B.

---

From: Dick Hardt <[email-masked]>
Date: Mon, 9 Apr 2018 15:15:39 -0700

So someone needs to read about two methods instead of just the one that the
profile says they need to read? Seems simpler for someone to read a Push
spec if all they need is to do Push, instead of having to read a spec that
describes both, and then trying to decipher which aspects are relevant for
them.

On Mon, Apr 9, 2018 at 3:13 PM, Morteza Ansari (moransar) <
[email-masked]> wrote:

> I definitely agree that we shouldn't specify an MTI at the protocol spec.
> I think each profile should be specifying that as part of the profile
> definition and semantics.
>
> And if we don’t have an MTI at the protocol document, I think we are much
> better off with a single protocol document covering different protocols in
> the same document. It will be all in one place for developer to choose,
> much easier to maintain the common language common and not let them
> diverge, and we could even describe scenarios one would be preferred over
> the other as hints and suggestion to the developers.
>
>
> Cheers,
> Morteza
>
> On 4/9/18, 2:31 PM, "Id-event on behalf of John Bradley" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     > Also, as I said at the microphone in London, I think we'll have a
> much easier time with the IESG taking one draft forward with two closely
> related delivery modalities defined, rather that two different delivery
> drafts.  I fear that if we try to get approval for two drafts, we might
> receive DISCUSS feedback saying "pick one".
>     >
>     > For what it's worth (and to inform people who weren't in the room),
> my personal sense was that the hums weren't conclusive.  Most of them had
>     >> doesn't expire, it's up to receiver how to use it, caching doesn't
> make sense [Yaron] What about replay protection?
>     >> Currently the draft says it's not recommended [Mike] We have to
> allow it to be optional because of the need to distinguish from access
> tokens.

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 9 Apr 2018 15:23:33 -0700

Agreed, having two different protocols in one document makes it more
complicated for implementers (or anyone trying to wrap their head around
what they need).

And again, with one document we are unnecessarily slowing one and rushing
the other delivery method.

Marius

On Mon, Apr 9, 2018 at 3:15 PM, Dick Hardt <[email-masked]> wrote:

> So someone needs to read about two methods instead of just the one that
> the profile says they need to read? Seems simpler for someone to read a
> Push spec if all they need is to do Push, instead of having to read a spec
> that describes both, and then trying to decipher which aspects are relevant
> for them.
>
>>     > I agree with Phil that having separate push and pull delivery
>> drafts would be a mistake.  Many participants will end up implementing both
>>     >> In addition, we had a series of hums on the SET Delivery draft.
>> Per IETF process, we need to validate them on the list. So if you weren't
>> in the room and you have a major objection to the results of these hums,
>> com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3Dr0hbpQqsN
>> 6s&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=
>> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=bZnIUtQK2S3enq
>> Q3E8wJZHxLExg0UyssjEM1UAJ18jw&s=VbJxhADDKAULj3hrOYI1cbC5A8hE
>> mFIesTvuGzkkOP0&e=.
>>     >>
>>     >> little commonality Later edit: existing editors volunteered to
>> take Push-specific doc, Annabelle and Mike volunteered to work on Poll.
>>     >> [Yaron] We're not ready to have hum, room thinks there is an
>> issue, please work through it on the list.
>>     >>
>>     >> would change optionality from two methods to a single one, may be
>> a compromise [Yaron] The protocol was only published yesterday, so we are
>> not ready to discuss now.
>>     >>
>>     >> [Meeting adjourned.]
>>     >>

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 9 Apr 2018 15:25:11 -0700

Oh, and not to mention that no one could confidently show how can you
specify two delivery methods in one document and not have both MTI.

Marius

On Mon, Apr 9, 2018 at 3:23 PM, Marius Scurtescu <[email-masked]>
wrote:

>>> I definitely agree that we shouldn't specify an MTI at the protocol
>>> spec. I think each profile should be specifying that as part of the profile
>>> And if we don’t have an MTI at the protocol document, I think we are
>>> much better off with a single protocol document covering different
>>> protocols in the same document. It will be all in one place for developer
>>> to choose, much easier to maintain the common language common and not let
>>> them diverge, and we could even describe scenarios one would be preferred
>>> over the other as hints and suggestion to the developers.
>>>
>>>
>>> Cheers,
>>> Morteza
>>>
>>>     > For what it's worth (and to inform people who weren't in the
>>> room), my personal sense was that the hums weren't conclusive.  Most of
>>> them had significant portions of people humming for both positions.  In
>>> short, my (personal) sense was there wasn't clear consensus demonstrated to
>>> split the delivery draft.  I think the topic needs more discussion on the
>>> list.
>>>     >
>>>     >                           Best wishes,
>>>     >                           -- Mike
>>>     >
>>>     > Regarding the hums, I think they may be premature. In part,
>>> because there is a unifying draft proposal available now.
>>>     >
>>>     > Another comment was made not to follow the route stix/taxii made
>>> in developing multiple incompatible methods of delivery.
>>>     >
>>>     >> doesn't expire, it's up to receiver how to use it, caching
>>> doesn't make sense [Yaron] What about replay protection?

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 9 Apr 2018 23:12:40 +0000

I don’t see how keeping them in one document makes things easier for the implementer. It just makes it harder to tell what is required for HTTP Push versus what is required for HTTP Poll. But we’ve already had this discussion – we spent a good half of the London session on it, Yaron called a vote, and found consensus for splitting the document. So far I haven’t seen any arguments for or against splitting that weren’t presented in London. So why are we reopening this?

Could the chairs please clarify as to whether the consensus in favor of splitting the document still holds?

--
Annabelle Richard Backman
Amazon – Identity Services

From: Id-event <[email-masked]> on behalf of Marius Scurtescu <[email-masked]>
Date: Monday, April 9, 2018 at 3:26 PM
To: Dick Hardt <[email-masked]>
Cc: SecEvent <[email-masked]>, Yaron Sheffer <[email-masked]>, Michael Jones <[email-masked]>, John Bradley <[email-masked]>, "Morteza Ansari (moransar)" <[email-masked]>, Phil Hunt <[email-masked]>
Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London)

Oh, and not to mention that no one could confidently show how can you specify two delivery methods in one document and not have both MTI.

Marius

On Mon, Apr 9, 2018 at 3:23 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:
Agreed, having two different protocols in one document makes it more complicated for implementers (or anyone trying to wrap their head around what they need).

And again, with one document we are unnecessarily slowing one and rushing the other delivery method.

Marius

On Mon, Apr 9, 2018 at 3:15 PM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
So someone needs to read about two methods instead of just the one that the profile says they need to read? Seems simpler for someone to read a Push spec if all they need is to do Push, instead of having to read a spec that describes both, and then trying to decipher which aspects are relevant for them.

On Mon, Apr 9, 2018 at 3:13 PM, Morteza Ansari (moransar) <[email-masked]<mailto:[email-masked]>> wrote:
I definitely agree that we shouldn't specify an MTI at the protocol spec. I think each profile should be specifying that as part of the profile definition and semantics.

Cheers,
Morteza

On 4/9/18, 2:31 PM, "Id-event on behalf of John Bradley" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    John B.
    > On Mar 30, 2018, at 7:53 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
    >
    > From: Id-event <[email-masked]<mailto:[email-masked]>> On Behalf Of Phil Hunt
    > To: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>
    > Cc: SecEvent <[email-masked]<mailto:[email-masked]>>
    >> On Mar 24, 2018, at 8:00 AM, Yaron Sheffer <[email-masked]<mailto:[email-masked]>> wrote:
    >>
    >> [email-masked]<mailto:[email-masked]>
    > [email-masked]<mailto:[email-masked]>
    > [email-masked]<mailto:[email-masked]>

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

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

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

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 12 Apr 2018 22:08:32 +0300

I already did 
(https://mailarchive.ietf.org/arch/msg/id-event/RIBJi79HFPIqo9_f7kL_GBwOPn0) 
and I don't see that anything substantial has changed. The consensus 
still holds.

Thanks,
	Yaron

On 10/04/18 02:12, Richard Backman, Annabelle wrote:
> I don’t see how keeping them in one document makes things easier for the 
> implementer. It just makes it harder to tell what is required for HTTP 
> Push versus what is required for HTTP Poll. But we’ve already had this 
> discussion – we spent a good half of the London session on it, Yaron 
> called a vote, and found consensus for splitting the document. So far I 
> haven’t seen any arguments for or against splitting that weren’t 
> presented in London. So why are we reopening this?
> 
> *From: *Id-event <[email-masked]> on behalf of Marius 
> Scurtescu <[email-masked]>
> *Date: *Monday, April 9, 2018 at 3:26 PM
> *To: *Dick Hardt <[email-masked]>
> *Cc: *SecEvent <[email-masked]>, Yaron Sheffer 
> <[email-masked]>, Michael Jones <[email-masked]>, 
> John Bradley <[email-masked]>, "Morteza Ansari (moransar)" 
> <[email-masked]>, Phil Hunt <[email-masked]>
> *Subject: *Re: [Id-event] SecEvent draft minutes - IETF-101 (London)
> 
> On Mon, Apr 9, 2018 at 3:23 PM, Marius Scurtescu 
> <[email-masked]<mailto:[email-masked]>> wrote:
> 
>     complicated for implementers (or anyone trying to wrap their head
>     around what they need).
> 
>     On Mon, Apr 9, 2018 at 3:15 PM, Dick Hardt
>     <[email-masked]<mailto:[email-masked]>> wrote:
> 
>         So someone needs to read about two methods instead of just the
>         one that the profile says they need to read? Seems simpler for
>         someone to read a Push spec if all they need is to do Push,
>         instead of having to read a spec that describes both, and then
>         trying to decipher which aspects are relevant for them.
> 
>         On Mon, Apr 9, 2018 at 3:13 PM, Morteza Ansari (moransar)
>         <[email-masked]<mailto:[email-masked]>> wrote:
> 
>             I definitely agree that we shouldn't specify an MTI at the
>             protocol spec. I think each profile should be specifying
>             that as part of the profile definition and semantics.
> 
>             And if we don’t have an MTI at the protocol document, I
>             think we are much better off with a single protocol document
>             covering different protocols in the same document. It will
>             be all in one place for developer to choose, much easier to
>             maintain the common language common and not let them
>             diverge, and we could even describe scenarios one would be
>             preferred over the other as hints and suggestion to the
>             developers.
> 
> 
>             Cheers,
>             Morteza
> 
> 
>             On 4/9/18, 2:31 PM, "Id-event on behalf of John Bradley"
>             <[email-masked]<mailto:[email-masked]>on
>             behalf of [email-masked]<mailto:[email-masked]>> wrote:
> 
>                  I think splitting the drafts was an attempt to get
>             around declaring one or the other method MTI.
> 
>                  Having them both in the same draft would be best if we
>             don’t wind up having to declare one or both MTI.
> 
>                  John B.
>                  > On Mar 30, 2018, at 7:53 AM, Mike Jones
>             <[email-masked]<mailto:[email-masked]>>
>             wrote:
>                  >
>                  > I agree with Phil that having separate push and pull
>             delivery drafts would be a mistake.  Many participants will
>             end up implementing both modalities.  Having them both in
>             one draft will help keep them as common as possible -
>             preventing unnecessary and possibly unintended drift between
>             them.
>                  >
>                  > Also, as I said at the microphone in London, I think
>             we'll have a much easier time with the IESG taking one draft
>             forward with two closely related delivery modalities
>             defined, rather that two different delivery drafts.  I fear
>             that if we try to get approval for two drafts, we might
>                  >
>                  > For what it's worth (and to inform people who weren't
>             in the room), my personal sense was that the hums weren't
>             conclusive.  Most of them had significant portions of people
>             humming for both positions.  In short, my (personal) sense
>             was there wasn't clear consensus demonstrated to split the
>                  >
>                  >                           Best wishes,
>                  >                           -- Mike
>                  >
>                  > -----Original Message-----
>                  > From: Id-event
>             <[email-masked]<mailto:[email-masked]>> On
>             Behalf Of Phil Hunt
>                  > Sent: Thursday, March 29, 2018 10:15 PM
>                  > To: Yaron Sheffer
>             <[email-masked]<mailto:[email-masked]>>
>                  > Cc: SecEvent
>             <[email-masked]<mailto:[email-masked]>>
>                  > Subject: Re: [Id-event] SecEvent draft minutes -
>             IETF-101 (London)
>                  >
>                  > Regarding the hums, I think they may be premature. In
>             part, because there is a unifying draft proposal available now.
>                  >
>                  > When we formed the group the sole purpose was a
>             common format and a single delivery draft for all cases.
>                  >
>                  > Several ietf people complained in Argentina about yet
>             another pub sub system the ietf does not need.
>                  >
>                  > Another comment was made not to follow the route
>             stix/taxii made in developing multiple incompatible methods
>             of delivery.
>                  >
>                  > If we split the draft we will have 3 methods not
>             two(including Backchannel).
>                  >
>                  > I worry this will lead to delay from rejection down
>             the road. This should be clarified first.
>                  >
>                  > I worry with multiple methods, profilers will develop
>             their own undermining the point of this work.
>                  >
>                  > Maybe I stand alone here, but I think splitting is a
>             mistake.
>                  >
>                  > Phil
>                  >
>                  >> On Mar 24, 2018, at 8:00 AM, Yaron Sheffer
>             <[email-masked]<mailto:[email-masked]>> wrote:
>                  >>
>                  >> Thank you Valery for taking the minutes. All, please
>             let us know if anything is incorrect or missing.
>                  >>
>                  >> In addition, we had a series of hums on the SET
>             Delivery draft. Per IETF process, we need to validate them
>             on the list. So if you weren't in the room and you have a
>             major objection to the results of these hums, please speak
>             up. I do suggest that before doing so, you review the actual
>             recorded meeting:
>             https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3Dr0hbpQqsN6s&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=bZnIUtQK2S3enqQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=VbJxhADDKAULj3hrOYI1cbC5A8hEmFIesTvuGzkkOP0&e=.
>                  >>
>                  >> IETF 101 London Friday 23 March 2018 9:30 - 11:30
>                  >>
>                  >> [Yaron] (WG status update, agenda bashing)
>             [Annabelle] asks for 10
>                  >> minutes for discussion
>                  >>
>                  >> [Mike] (presents Security Event Token draft update)
>                  >>
>                  >> [Annabelle] (presents SET Token delivery using HTTP
>             draft) [Mike]
>                  >> Microsoft needs for both POLL and PUSH [Phil]
>             Redefining smth in HTTP
>                  >> may cause problems [William] Return codes are only
>             for browsers to
>                  >> display messages for users [Phil] It's needed for
>             resending in case of
>                  >> error (?) [Annabelle] What is MTI - push or poll?
>                  >> [Phil] With PUSH  happened immediately...
>                  >> [Leif] What is MTI for server or for client?
>                  >> [William] Each option has an explicit use case
>             [Yaron (as chair)] We
>                  >> need to have only one preferred option [Phil] There
>             are very different
>                  >> cases [Phil] Push is simple, but in terms of
>             applicability it's not a
>                  >> long term use case [Annabelle] There use cases for
>             both [Phil] Take
>                  >> two and then abandon one [William] Why does the
>             chair require a single
>                  >> MTI [Leif] It's from chair's experience, WG
>             consensus needed [William]
>                  >> We have use cases for both [Mike] Procedurally it's
>             better to keep
>                  >> both methods in one draft [Yaron] Having two methods
>             complicates the
>                  >> description which method is for which situation etc.
>                  >> [William] Still have interoperability issue for
>             receiver [Yaron] Need
>                  >> to resolve this [Leif] WG should decide [Ben as AD]
>             If the WG doesn't
>                  >> select a single method the IESG would probably
>             object [Annabelle] SET
>                  >> will probably be profiled for different use cases
>             [Yaron] Is going to
>                  >> make hums about selecting a single delivery method
>             and whether we need
>                  >> to split the draft [John] What is hum about -
>             mandatory to implement or to deploy?
>                  >> [Leif] We should analyze scenarios
>                  >> [Annabelle] The protocol are unidirectional, so MTI for
>                  >> transmitter/receiver is problematic [Justin] No
>             negotiation, either it
>                  >> is or not, MTI for the receiver is dictated by what
>             the receiver
>                  >> supports [Phil] They both must be able HTTP, the
>             roles can be changed
>                  >> [Leif] Confusion between MTI and to deploy, a good
>             question - select
>                  >> MTI for transmitter [Annabelle] Every transmitter
>             should have both
>                  >> [Tero] Minimal implementation requires one, bigger
>             may have both,
>                  >> single MTI is better then two for limited devices
>             [Annabelle] IoT
>                  >> implementers have special requirement [William] They
>             are application
>                  >> specific, we expected profile this [Yaron] Hum if we
>             need a single MTI
>                  >> for transmitter - silence Later edit: Clearly no
>             support for a single MTI.
>                  >> [Justin] Hum must be for multiple discrete options
>             [Yaron] Hum on use
>                  >> cases for two methods - some hums [Yaron] Hum if
>             both should be MTI -
>                  >> some hums [Yaron] Hum if should not specify MTI -
>             some hums Later
>                  >> edit: room was split between two MTIs and no MTIs.
>                  >> [Annabelle] We should split the spec
>                  >> [Justin] Agree to split the spec
>                  >> [Justin] I hummed for both MTI for transmitter,
>             because they are not
>                  >> usually constrained [Annabelle] SET is possibly to
>             be used w/o HTTP,
>                  >> this is only MTI for those using HTTP; both MTI is
>             problematic because
>                  >> implementers will do unnecessary stuff [William] If
>             both are MTI, we
>                  >> need 2 specs [John] Splitting the spec is the best
>             way [Mike] If
>                  >> split, then the information for developers will be
>             duplicated [Ben]
>                  >> Why single document better (?) [Mike] My experience
>             with JOSE
>                  >> [Annabelle] Significant overlap between documents is
>             SET, otherwise
>                  >> little commonality Later edit: existing editors
>             volunteered to take Push-specific doc, Annabelle and Mike
>             volunteered to work on Poll.
>                  >> [from jabber] Little commonality between two methods
>             [Mike] We'll do
>                  >> both, we have use cases for both [Yaron] Hum if
>             split documents - some
>                  >> long hums [Yaron] Hum if one document - some hums
>             [Yaron] Room is in
>                  >> favor of splitting the documents [Yaron] Wrap up: no
>             MTI, split the
>                  >> document into two, transmitter implements either or both
>                  >>
>                  >> [Annabelle] (presenting Subject Identifier Types)
>             [Mike] 3rd party
>                  >> specifications cannot establish IANA registry [Leif]
>             IANA Expert?
>                  >> [Ben] FCFS, doesn't need Expert, or specification
>             required [Leif] I
>                  >> support this idea [William] I also support [Yaron]
>             Any objections to
>                  >> adopt this document? No objections, publish as WG
>             document
>                  >>
>                  >> [Annabelle] Expiration ("exp") claim is not
>             recommended; however it
>                  >> has some value [Mike] It's a layering violation;
>             problems with caching
>                  >> [Annabelle] We're not talking about caching, you
>             don't want to grow
>                  >> anti-replay database forever, having expiration
>             helps [Phil] The past
>                  >> doesn't expire, it's up to receiver how to use it,
>             caching doesn't make sense [Yaron] What about replay protection?
>                  >> [Mike] JTI helps to detect replay (?) [from jabber]
>             Transport should
>                  >> deal with replay [John] Expiry is expected to mean
>             that token should
>                  >> not be processed after that, it's not an indication
>             that information
>                  >> is no longer valid [Mike] It must not be mandatory
>             [Annabelle]
>                  >> Currently the draft says it's not recommended [Mike]
>             We have to allow it to be optional because of the need to
>             distinguish from access tokens.
>                  >> [Ben] Some use case when processing expired token
>             (?) [John] Have an
>                  >> explicit expire for JTI, there are other solutions
>             [Phil] I prefer to
>                  >> add a new attribute to SET, not changing ...
>                  >> [Yaron] The document in LC, smaller changes are OK
>             without blocking the doc's progress.
>                  >> [Phil] Replay and caching are different for PUSH and
>             POLL, prefer to
>                  >> see in HTTP header [Brian] Expiration is not
>             necessary, receiver has
>                  >> policy to follow [Annabelle] No-one is advocating
>             using exp for
>                  >> caching [from jabber] JTI expiration belongs to JTI
>             not to transport
>                  >> [Yaron] We're not ready to have hum, room thinks
>             there is an issue, please work through it on the list.
>                  >>
>                  >> [Phil] Presents his SSTP Delivery draft - symmetric
>             transport
>                  >> protocol, parameters used in requests and response
>             are same [Phil] We
>                  >> would change optionality from two methods to a
>             single one, may be a compromise [Yaron] The protocol was
>             only published yesterday, so we are not ready to discuss now.
>                  >>
>                  >> [Meeting adjourned.]
>                  >>
>                  >> _______________________________________________
>                  >> Id-event mailing list
>                  >> [email-masked]<mailto:[email-masked]>
>                  >>
>                  >>
>                  >>
>                  >>
>                  >> TAjwew&e=
>                  >
>                  > _______________________________________________
>                  > Id-event mailing list
>                  > [email-masked]<mailto:[email-masked]>
>                  > https://www.ietf.org/mailman/listinfo/id-event
>                  >
>                  > _______________________________________________
>                  > Id-event mailing list
>                  > [email-masked]<mailto:[email-masked]>
>                  > https://www.ietf.org/mailman/listinfo/id-event
>