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

[Yaron Sheffer <[e-mail]>]

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?
> 
> 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 <[e-mail]> on behalf of Marius 
> Scurtescu <[e-mail]>
> *Date: *Monday, April 9, 2018 at 3:26 PM
> *To: *Dick Hardt <[e-mail]>
> *Cc: *SecEvent <[e-mail]>, Yaron Sheffer 
> <[e-mail]>, Michael Jones <[e-mail]>, 
> John Bradley <[e-mail]>, "Morteza Ansari (moransar)" 
> <[e-mail]>, Phil Hunt <[e-mail]>
> *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 
> <[e-mail]<mailto:[e-mail]>> 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
>     <[e-mail]<mailto:[e-mail]>> 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)
>         <[e-mail]<mailto:[e-mail]>> 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"
>             <[e-mail]<mailto:[e-mail]>on
>             behalf of [e-mail]<mailto:[e-mail]>> wrote:
> 
>                  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
>             <[e-mail]<mailto:[e-mail]>>
>             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".
>                  >
>                  > 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
>             <[e-mail]<mailto:[e-mail]>> On
>             Behalf Of Phil Hunt
>                  > Sent: Thursday, March 29, 2018 10:15 PM
>                  > To: Yaron Sheffer
>             <[e-mail]<mailto:[e-mail]>>
>                  > Cc: SecEvent
>             <[e-mail]<mailto:[e-mail]>>
>                  > 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
>             <[e-mail]<mailto:[e-mail]>> 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
>                  >> [e-mail]<mailto:[e-mail]>
>                  >>
>             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
>                  > [e-mail]<mailto:[e-mail]>
>                  > https://www.ietf.org/mailman/listinfo/id-event
>                  >
>                  > _______________________________________________
>                  > Id-event mailing list
>                  > [e-mail]<mailto:[e-mail]>
>                  > https://www.ietf.org/mailman/listinfo/id-event
> 
>                  _______________________________________________
>                  Id-event mailing list
>             [e-mail]<mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/id-event
> 
> 
>             _______________________________________________
>             Id-event mailing list
>             [e-mail]<mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/id-event
> 
> 
>         _______________________________________________
>         Id-event mailing list
>         [e-mail]<mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/id-event
>