Re: [httpapi] Francesca Palombini's Yes on draft-ietf-httpapi-linkset-08: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 03 March 2022 07:59 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: httpapi@ietfa.amsl.com
Delivered-To: httpapi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046053A140D; Wed, 2 Mar 2022 23:59:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.721
X-Spam-Level:
X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.186, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 IjP0QnihGMRo; Wed, 2 Mar 2022 23:59:54 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 C27433A1320; Wed, 2 Mar 2022 23:59:53 -0800 (PST)
Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 2237xaMR009604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 3 Mar 2022 02:59:42 -0500
Date: Wed, 02 Mar 2022 23:59:35 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Herbert Van de Sompel <hvdsomp@gmail.com>
Cc: Francesca Palombini <francesca.palombini@ericsson.com>, HTTP APIs Working Group <httpapi@ietf.org>, draft-ietf-httpapi-linkset@ietf.org, "Salz, Rich" <rsalz@akamai.com>, The IESG <iesg@ietf.org>, httpapi-chairs@ietf.org
Message-ID: <20220303075935.GS22457@mit.edu>
References: <164614389601.20425.17125858696094463715@ietfa.amsl.com> <CAOywMHfFhbiQZV6ToRzpuxihSxO5AsL6GhF56iskrpm8GDKXuQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAOywMHfFhbiQZV6ToRzpuxihSxO5AsL6GhF56iskrpm8GDKXuQ@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/httpapi/gNA7ayrYYCO_6suTX93WFd0OQR0>
Subject: Re: [httpapi] Francesca Palombini's Yes on draft-ietf-httpapi-linkset-08: (with COMMENT)
X-BeenThere: httpapi@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Building Blocks for HTTP APIs <httpapi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/httpapi>, <mailto:httpapi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/httpapi/>
List-Post: <mailto:httpapi@ietf.org>
List-Help: <mailto:httpapi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpapi>, <mailto:httpapi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Mar 2022 07:59:59 -0000

Hi Herbert,

I'm not Francesca but should be able to provide useful responses
regardless.

On Thu, Mar 03, 2022 at 08:51:00AM +0100, Herbert Van de Sompel wrote:
> Dear Francesca,
> 
> In order to be able to continue the work on the linkset I-D, I would like
> to ask for some guidance:
> 
> * In his DISCUSS review, Benjamin Kaduk seems to express a different
> opinion than yours regarding how to handle the downrefs vis-a-vis another
> Last Call (or not); he asks the IESG to discuss the matter. Am I correct to
> assume that there is nothing we as authors can do to address this issue?

That's correct that there is no action for the authors at this time.
(In some sense this point is me using technology to mitigate human
weakness, as the meeting where the IESG will discuss the topic is at 0700h
my time and I will not necessarily be awake enough to remember to mention
it, without the extra nudge here.)
For what it's worth, I don't think Francesca's position is inaccurate --
there is no strict requirement to do another Last Call, but it's subject to
the IESG's judgment and I think the topic I raised will be a relevant
factor for the IESG's decision.  I do not attempt to prejudge what the
outcome of the IESG discussion will be.

> * In the same review, Benjamin also correctly points out an error with a
> Content-Length in an example, which must be corrected. Other reviewers have
> provided some comments that would be good to address as a means to improve
> the document quality. Do we start a new version of the I-D in the HTTPAPI
> Github repository for that purpose? And will that then automatically mean
> another Last Call?

Yes, please go ahead and start a new version in the github repository.
Such changes will not automatically mean a new Last Call.  (If, in
Francesca's assessment, the changes made are "substantial enough" a last
call might be needed, but there is no process requirement that one will
always be needed.)

Thanks,

Ben

> Greetings
> 
> Herbert Van de Sompel
> 
> On Tue, Mar 1, 2022 at 3:11 PM Francesca Palombini via Datatracker <
> noreply@ietf.org> wrote:
> 
> > Francesca Palombini has entered the following ballot position for
> > draft-ietf-httpapi-linkset-08: Yes
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to
> > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> > for more information about how to handle DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-httpapi-linkset/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Lars rightfully noted that two Downref (not in the downref registry)
> > escaped
> > the IETF Last Call automatically generated text:
> >
> >   ** Downref: Normative reference to an Informational RFC: RFC 6906
> >    [RFC6906]  Wilde, E., "The 'profile' Link Relation Type", RFC 6906,
> >               DOI 10.17487/RFC6906, March 2013,
> >               <https://www.rfc-editor.org/info/rfc6906>.
> >
> >   ** Downref: Normative reference to an Informational RFC: RFC 7284
> >    [RFC7284]  Lanthaler, M., "The Profile URI Registry", RFC 7284,
> >               DOI 10.17487/RFC7284, June 2014,
> >               <https://www.rfc-editor.org/info/rfc7284>.
> >
> > In conformance with https://www.ietf.org/rfc/rfc8067.html, I believe
> > there is
> > no need for starting another LC for the document including these
> > references,
> > and I ask the rest of the IESG to pay particular attention to the
> > appropriateness of these two downward references, as part of their IESG
> > evaluation.
> >
> >
> >
> > --
> > httpapi mailing list
> > httpapi@ietf.org
> > https://www.ietf.org/mailman/listinfo/httpapi
> >
> 
> 
> -- 
> ==================
> Herbert Van de Sompel
> https://hvdsomp.info
> https://orcid.org/0000-0002-0715-6126