[core] Martin Duke's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)

[Martin Duke via Datatracker <[e-mail]>]

Martin Duke has entered the following ballot position for
draft-ietf-core-new-block-11: Discuss

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/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-new-block/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I am concerned about the convergence of three different provisions in this spec:

- In (4.1), it says "To reliably get a rejection message, it is therefore
   REQUIRED that clients use a Confirmable message for determining
   support for Q-Block1 and Q-Block2 Options."

IIUC this mandates that at least one request will use CON.

- (7.1): all the blocks of a single body over an
   unreliable transport MUST either all be Confirmable or all be Non-
   confirmable.

- (7.2) However, the other CON congestion
   control parameters will need to be tuned to cover this change.  This
   tuning is out of scope of this document as it is expected that all
   requests and responses using Q-Block1 and Q-Block2 will be Non-
   confirmable (Section 3.2).

I can't reconcile (4.1) with the last sentence in (7.2). Moreover, if my
reading of (4.1) is correct, it's not sufficient to declare congestion control
guidance out of scope when it's a mandated part of the protocol.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the examples. They were useful in providing an overview of the
protocol.

Thanks also to Colin Perkins for an especially thoughtful TSVART review. Please
address his comments, although his concerns about (7.1) are IMO mostly subsumed
by my DISCUSS.

- It would be useful to introduce the "token", "request tag", and "Etag"
concepts before using them. Reading front-to-back, I spent most of Section 4
confused.

- (4.4) It would be useful to state that clients MUST (SHOULD?) NOT request
retransmission of blocks from ETags that are not "fresh" -- IIUC, they probably
don't exist anymore, and anyway the server has no way of knowing which
non-fresh ETag to serve beacuse it says "The ETag Option should not be used in
the request for missing blocks"

BTW, s/should/SHOULD

- (7.2) If NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT both "have the same value
as computed for EXCHANGE_LIFETIME", why are they different variables? Or is
that they SHOULD have the same value but might not? A normative word would be
helpful here.