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@xxxxxxxx> 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@xxxxxxxx? Yes, which will then be promptly turned back into the above by IANA (who seems to try to spam-protect iesg@xxxxxxxx :-). I hope the RFC editor and IANA can bring this into what is today’s preferred format. Grüße, Carsten
