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

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

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