Re: [Gen-art] Genart last call review of draft-ietf-core-multipart-ct-03

Carsten Bormann <cabo@tzi.org> Thu, 02 May 2019 13:50 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCBB9120135; Thu, 2 May 2019 06:50:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham 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 D_xtfCKEQ8NM; Thu, 2 May 2019 06:50:02 -0700 (PDT)
Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 106C4120103; Thu, 2 May 2019 06:50:02 -0700 (PDT)
Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 44vxTh090dzyVZ; Thu, 2 May 2019 15:49:59 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <155454280808.21871.333722671657907840@ietfa.amsl.com>
Date: Thu, 2 May 2019 15:49:59 +0200
Cc: gen-art@ietf.org, draft-ietf-core-multipart-ct.all@ietf.org, ietf@ietf.org, core@ietf.org
X-Mao-Original-Outgoing-Id: 578497798.029436-ee86fd8b54c15ebf7f7cba6bb1a58e4f
Content-Transfer-Encoding: quoted-printable
Message-Id: <9440547E-E592-48BE-B344-4B5CD7E98474@tzi.org>
References: <155454280808.21871.333722671657907840@ietfa.amsl.com>
To: Stewart Bryant <stewart.bryant@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/kYspDdLanrn-Zb9uospqgYH3l-U>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-core-multipart-ct-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 May 2019 13:50:05 -0000

Hi Stewart,

Thank you for the review.  We already communicated about fixing one of the items, but it seems the rest of our response never made it out.  Here goes…

> On Apr 6, 2019, at 11:26, Stewart Bryant via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Stewart Bryant
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-core-multipart-ct-03
> Reviewer: Stewart Bryant
> Review Date: 2019-04-06
> IETF LC End Date: 2019-04-08
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> Apart from one figure that was difficult to understand and some trivial nits
> this is well written and is ready for publication.
> 
> Major issues: None
> 
> Minor issues:
> 
>        __________       __________       __________
>       |          |     |          |     |          |
>  ---->|   2.05   |---->|  2.05 /  |---->|  4.xx /  |
>       | Pending  |     |   2.03   |     |   5.xx   |
>       |__________|     |__________|     |__________|
>          ^   \ \          ^    \           ^
>           \__/  \          \___/          /
>                  \_______________________/
> 
>                  Figure 2: Sequence of Notifications:
> SB> Not my specialty, but I don't see what message gets sent
> SB> to who in the above and RFC7641 has no similar diagram.

The intention of this figure is probably more apparent to someone thinking in terms of CoAP notifications.
All these notifications flow from the server to the client.
RFC7641 does not have such a diagram because it doesn’t consider sequences of notifications that differ in interesting ways, but this is indeed a side view of the notification part of Figure 1 there…

So we changed:

The possible resulting
  sequence of notifications is shown in Figure 1.
➔
A diagram depicting possible resulting
  sequences of notifications, identified by their respective response code, is shown in Figure 1.

https://github.com/core-wg/multipart-ct/commit/f94dd670dde88e7234b227ccacadb10660db489a

This is now in branch ietf-lc-fixes on https://github.com/core-wg/multipart-ct
CI build in https://core-wg.github.io/multipart-ct/ietf-lc-fixes/draft-ietf-core-multipart-ct.html
Diff in https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-core-multipart-ct.txt&url2=https://core-wg.github.io/multipart-ct/ietf-lc-fixes/draft-ietf-core-multipart-ct.txt


> Nits/editorial comments:
>  accompanying it.  In such a case, the sequence in which these occur
>  may not be relevant to the application.  This specification allows to
> SB> typo - word missing
> indicate that an optional part is not present by substituting a null
>  value for the representation of the part.
> 

[See previous message; also fixed in ietf-lc-fixes.]

> 
> ==========
> 
>  The collection is encoded as a CBOR [RFC7049] array with an even
> SB> CBOR needs expanding on first use (it is not on the well known list)
>  number of elements.

(Sigh.  You are right of course.  Until that list is fixed, this is probably best done by adding a sentence that indicates we are using CBOR.)

Also in
https://github.com/core-wg/multipart-ct/commit/f94dd670dde88e7234b227ccacadb10660db489a

> ==========
> 
>  Person & email address to contact for further information:
>     iesg&ietf.org
> SB> Shouldn’t that be iesg@ietf.org?

Yes, which will then be promptly turned back into the above by IANA (who seems to try to spam-protect iesg@ietf.org :-).  I hope the RFC editor and IANA can bring this into what is today’s preferred format.

Grüße, Carsten