Re: [Id-event] Push draft: conclusion of WGLC

Benjamin Kaduk <bkaduk@akamai.com> Wed, 06 March 2019 15:35 UTC

Return-Path: <bkaduk@akamai.com>
X-Original-To: id-event@ietfa.amsl.com
Delivered-To: id-event@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DED91277DB for <id-event@ietfa.amsl.com>; Wed, 6 Mar 2019 07:35:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.667
X-Spam-Level:
X-Spam-Status: No, score=0.667 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.468, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8g-SRqqJpdak for <id-event@ietfa.amsl.com>; Wed, 6 Mar 2019 07:35:18 -0800 (PST)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32BAE1277D9 for <id-event@ietf.org>; Wed, 6 Mar 2019 07:35:17 -0800 (PST)
Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x26FQrwe030599; Wed, 6 Mar 2019 15:35:16 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=N3LJYy44bMZciYBTzjy/rRRPub1EPedpXVM8/3ZzBkk=; b=nw0D90NydWXEStQfM1F+hy5LuMB3Wp276JdmzMwtvzgwhoeSF9YtOTEaeTu1kQIVjSUZ xcqBRFuIxNR6vnX6WwIemKQ3VoH8sPDEXQNDo6TkO/TuFx4EDosWIQt7iLthjkIiL+UU JfPMZ8Qgq4a5jX0QBodALqdxPpTSsrtaP237Qww91aS7kSq7Q0hJ8EvzE71znym4eFPi pRCSxhlUzqlcHF4hxor6doJI1HKO/lCCklzlbskpaQOTNszrOMCIARk8jwr3YetV4HDt yDrejV7crgII28DGyigAzsUJ39CWazySvc65flHO8imRaPY9qzKTHifAhkzjOcsj3cRf tg==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2r2fm88bnb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 06 Mar 2019 15:35:15 +0000
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x26FWLBW025597; Wed, 6 Mar 2019 10:35:14 -0500
Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint1.akamai.com with ESMTP id 2qyp20t6fu-1; Wed, 06 Mar 2019 10:35:14 -0500
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 4C39C1FC71; Wed, 6 Mar 2019 15:35:14 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1h1YZd-00089C-HO; Wed, 06 Mar 2019 09:35:13 -0600
Date: Wed, 06 Mar 2019 09:35:13 -0600
From: Benjamin Kaduk <bkaduk@akamai.com>
To: SecEvent <id-event@ietf.org>
Cc: Marius Scurtescu <marius.scurtescu=40coinbase.com@dmarc.ietf.org>, Yaron Sheffer <yaronf.ietf@gmail.com>, Dick Hardt <dick.hardt@gmail.com>
Message-ID: <20190306153513.GM10233@akamai.com>
References: <7cfedb70-a999-ad63-efd0-56a178adde97@gmail.com> <CABpvcNs69NZeqXmNui6poP79R6q40WgEAT7jRkvb_vTL_Y8x=A@mail.gmail.com> <CABpvcNuZEvjwcsZjJP9gDtReRBAmeFM41b1O7uXzD=UCSasEZw@mail.gmail.com> <CAD9ie-tSiuC8YRiJfwEAOb9H1RDWc7yd+wxA3fxWjA6-1nw_hg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAD9ie-tSiuC8YRiJfwEAOb9H1RDWc7yd+wxA3fxWjA6-1nw_hg@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-06_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903060107
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-06_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903060107
Archived-At: <https://mailarchive.ietf.org/arch/msg/id-event/OOs8hntOIK8LHMArXEpLFwYg9V8>
Subject: Re: [Id-event] Push draft: conclusion of WGLC
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." <id-event.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/id-event>, <mailto:id-event-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/id-event/>
List-Post: <mailto:id-event@ietf.org>
List-Help: <mailto:id-event-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/id-event>, <mailto:id-event-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Mar 2019 15:35:20 -0000

Hi everyone,

I think that Dick and Yaron are correct to determine that this document
doesn't have WG consensus (rough or otherwise) to advance at this time.
That, of course, can change given additional inputs.

I'll note that the WGLC period is not a formal requirement of the process,
but rather more of a conventional tool that WG chairs use to determine
WG consensus.  In the KITTEN WG (that I chaired for a few years), which
is a very low-energy group, we've largely distanced ourselves from WGLC in
favor of a more rolling period where input comes in.  Regardless of how
they get it, the chairs still need reason to believe that there is a critical
mass of support in the WG for the work, and that all known technical issues
have been addressed in some way (whether technical changes in the document or
through subsequent discussion to determine it is not an issue/out of
scope/not the direction the WG wants to go/etc.)  Historical interest and
engagement of the kind that Annabelle points out can factor into this decision,
but it's also the case that in order to advance, the current document needs
WG consensus, and consensus that some previous version was "pointed in the
right direction" isn't quite the same.

I agree with Mike that I hope this inability to make a determination of
consensus can be a wake-up call that we need greater participation in
order to proceed.

I think at this point there's a few possible paths including but not
limited to:

1) get another couple positive reviews from people who are informed in the
space (whether by following the work along the way or otherwise), and finish
addressing the comments Phil raised during WGLC.  I know that they are rooted
in a longstanding philosophical disagreement, but Phil is correct to raise them
one last time during WGLC, and the conclusion of WGLC^W^W^Wdetermination of WG
rough consensus involves the chairs being confident on the technical resolution
to those issues. [0]  It's much easier for the chairs to do that when there's
a contervailing writeup presented right next to the issues that were raised.

2) Not get more reviews, and have some discussion that concludes that the
previous energy for push has evaporated, which would require the shared content
with pull to be pulled [sic] back into the pull document before that could
advance.  (Yes, that would be unpleasant and duplicate work that's already been
done.  Nobody said this was a great option.)

3) Have some discussion that concludes that the WG just doesn't have enough energy
to work on any of its remaining chartered items (i.e., event delivery), in which
case it would be appropriate to close the WG.

>From this list, there seems a clear "best outcome", but we'll need some help from
the WG participants to make it happen.  It might be worth getting some "survey
results" about who is still interested in working on what, to help the chairs
gauge the best path forward.

-Ben

[0] BTW, Phil would also be justified in raising the questions again during
IETF LC, but it's generally considered best to only do that in the case when
the broader IETF community would be unaware of the previous discussions and is
believed to not be considering the topic without additional intervention.  IMO,
having the controversy properly discussed in the shepherd writeup would probably
fill that need, but Phil and everyone else should use their own judgement.


On Wed, Feb 27, 2019 at 02:58:01PM -0800, Dick Hardt wrote:
> Hi Marius
> 
> Per my other response, implementations are important, but do not represent
> rough consensus.
> 
> Yaron and I have reached out the the AD to get guidance on how to proceed.
> 
> There is low energy in the WG, the implication is that the WG may be ready
> to terminate.
> 
> 
> 
> On Wed, Feb 27, 2019 at 2:42 PM Marius Scurtescu <marius.scurtescu=
> 40coinbase.com@dmarc.ietf.org> wrote:
> 
> > Any chance for an answer from the chairs to the 3 questions below?
> >
> > On Sun, Feb 24, 2019 at 4:52 PM Marius Scurtescu <
> > marius.scurtescu@coinbase.com> wrote:
> >
> >> Regrettable indeed :-(
> >>
> >> Were the recent official launches by Adobe and Google taken into
> >> consideration?
> >>
> >> Is it possible to consult the AD for options?
> >>
> >> Did we consider the implications for the whole working group?
> >>
> >> While the group is indeed at a low point of activity, a lot of work went
> >> into this draft and it is central for real life implementations.
> >>
> >>
> >>
> >>
> >> On Sun, Feb 17, 2019 at 6:43 AM Yaron Sheffer <yaronf.ietf@gmail.com>
> >> wrote:
> >>
> >>> Dear working group,
> >>>
> >>> We issued a 2-week second last call for draft-ietf-secevent-http-push-04
> >>> on Jan. 24, and extended it by a further week, which expired on Friday. We
> >>> had to issue a second last call because of lack of response to the first
> >>> last call which took place in November/December.
> >>>
> >>> The results were better in the second try (2 non-authors in support, and
> >>> 1 not clearly supporting publication) but not enough in our mind to push
> >>> the document forward.
> >>>
> >>> This means that we will not be publishing the Push protocol as a working
> >>> group document. The authors are welcome to publish it through other
> >>> channels, as an AD-sposored RFC or through the ISE.
> >>>
> >>> We regret that we have reached this impasse, but clearly there is too
> >>> little energy within the working group. We thank the authors for the
> >>> significant effort that they put into this document, and thank the working
> >>> group members who reviewed it.
> >>>
> >>> Regards,
> >>>
> >>>     Dick and Yaron
> >>> _______________________________________________
> >>> Id-event mailing list
> >>> Id-event@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/id-event
> >>>
> >> _______________________________________________
> > Id-event mailing list
> > Id-event@ietf.org
> > https://www.ietf.org/mailman/listinfo/id-event
> >

> _______________________________________________
> Id-event mailing list
> Id-event@ietf.org
> https://www.ietf.org/mailman/listinfo/id-event