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

From: Lars Eggert via Datatracker <[email-masked]>
Date: Wed, 05 May 2021 01:00:26 -0700

Lars Eggert 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:
----------------------------------------------------------------------

The current CORE charter does not seem to cover the topic of this
document. I also see no related milestone.

Section 1, paragraph 4, discuss:
>    There is a requirement for these blocks of data to be transmitted at
>    higher rates under network conditions where there may be asymmetrical
>    transient packet loss (i.e., responses may get dropped).  An example
>    is when a network is subject to a Distributed Denial of Service
>    (DDoS) attack and there is a need for DDoS mitigation agents relying
>    upon CoAP to communicate with each other (e.g.,
>    [RFC8782][I-D.ietf-dots-telemetry]).  As a reminder, [RFC7959]

I understand that COAP was initially chosen to transport DOTS signaling messages
due to their small size, support for structured messages and request/response
semantics, as well as the ability to function over lossy paths such as found in
IoT deployment, which COAP is architected for.

DOTS now seems to desire to transport larger messages, and this document extends
CORE to enable this functionality. However, this CORE extension seems to solely
focus on Internet deployment scenarios, essentially attempting to re-architect
COAP into a general Internet transport protocol for transmission over paths with
high loss rates. I do not believe that the CORE WG is chartered to do this.

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

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools, so there will likely be some false positives. There is no need
to let me know what you did with these suggestions.

Section 1, paragraph 3, nit:
> ell in environments where there are no or minimal packet losses. These optio
>                                     ^^
Did you mean "now" (=at this moment) instead of 'no' (negation)?

Section 3, paragraph 16, nit:
> ed by the peer whether the body comprises of a single or multiple payloads a
>                                 ^^^^^^^^^^^^
Did you mean "comprises" or "consists of"?

Section 4.1, paragraph 18, nit:
> T be included as Inner options. Similarly there MUST NOT be a mix of Q-Block
>                                 ^^^^^^^^^
Did you forget a comma after a conjunctive/linking adverb?

Section 4.3, paragraph 3, nit:
> -Tag value MUST be the same for all of the requests for the body of data tha
>                                 ^^^^^^^^^^
Consider using "all the".

Section 4.3, paragraph 3, nit:
> ue, the server still treats it as opaque but the client MUST ensure that it i
>                                   ^^^^^^
Use a comma before 'but' if it connects two independent clauses (unless they
are closely connected and short).

Section 4.3, paragraph 6, nit:
>  not arrived after a timeout and a retransmit missing payloads response is n
>                                  ^^^^^^^^^^^^
After 'a', do not use a verb. Make sure that the spelling of 'retransmit' is
correct. If 'retransmit' is the first word in a compound adjective, use a
hyphen between the two words. Note: This error message can occur if you use a
verb as a noun, and the word is not a noun in standard English.

Section 4.3, paragraph 6, nit:
>  a timeout and a retransmit missing payloads response is needed. For reliabl
>                                     ^^^^^^^^
An apostrophe may be missing.

Section 4.3, paragraph 11, nit:
> g. The client should then release all of the tokens used for this body. Note
>                                   ^^^^^^^^^^
Consider using "all the".

Section 4.3, paragraph 13, nit:
> t. The client should then release all of the tokens used for this body. 2
>                                   ^^^^^^^^^^
Consider using "all the".

Section 4.3, paragraph 15, nit:
> quest. The client should then release all of the tokens used for this body.
>                                       ^^^^^^^^^^
Consider using "all the".

Section 4.3, paragraph 18, nit:
>  The client should then release all of the tokens used for this body unless
>                                 ^^^^^^^^^^
Consider using "all the".

Section 4.3, paragraph 20, nit:
> e Code can be used to indicate that all of the blocks up to and including th
>                                     ^^^^^^^^^^
Consider using "all the".

Section 4.3, paragraph 30, nit:
> ing-blocks+cbor-seq" indicates that some of the payloads are missing and need
>                                     ^^^^^^^^^^^
If the text is a generality, 'of the' is not necessary.

Section 4.4, paragraph 4, nit:
> a request for that block and for all of the remaining blocks in the current
>                                  ^^^^^^^^^^^^^^^^
Consider using "all the".

Section 4.4, paragraph 7, nit:
> paque, the client still treats it as opaque but the server MUST ensure that i
>                                      ^^^^^^
Use a comma before 'but' if it connects two independent clauses (unless they
are closely connected and short).

Section 4.4, paragraph 16, nit:
> , the client should then release all of the tokens used for this body unless
>                                  ^^^^^^^^^^
Consider using "all the".

Section 4.5, paragraph 1, nit:
> r a request that uses Q-Block1, the Observe value [RFC7641] MUST be the same
>                                 ^^^^^^^^^^^
After 'the', do not use a verb. Make sure that the spelling of 'Observe' is
correct. If 'Observe' is the first word in a compound adjective, use a hyphen
between the two words. Note: This error message can occur if you use a verb as
a noun, and the word is not a noun in standard English.

Section 4.5, paragraph 2, nit:
>  a response that uses Q-Block2, the Observe value MUST be the same for all t
>                                 ^^^^^^^^^^^
After 'the', do not use a verb. Make sure that the spelling of 'Observe' is
correct. If 'Observe' is the first word in a compound adjective, use a hyphen
between the two words. Note: This error message can occur if you use a verb as
a noun, and the word is not a noun in standard English.

Section 4.5, paragraph 3, nit:
> ferent from Block2 usage where the Observe value is only present in the firs
>                                ^^^^^^^^^^^
After 'the', do not use a verb. Make sure that the spelling of 'Observe' is
correct. If 'Observe' is the first word in a compound adjective, use a hyphen
between the two words. Note: This error message can occur if you use a verb as
a noun, and the word is not a noun in standard English.

Section 5, paragraph 2, nit:
> that the server has not received all of the blocks of the request body that
>                                  ^^^^^^^^^^
Consider using "all the".

Section 5, paragraph 4, nit:
> as a CBOR Sequence [RFC8742]. It comprises of one or more missing block numb
>                                  ^^^^^^^^^^^^
Did you mean "comprises" or "consists of"?

Section 5, paragraph 6, nit:
> sing blocks is as follows: ; A notional array, the elements of which
>                            ^
Loose punctuation mark.

Section 7.1, paragraph 2, nit:
>  It is implementation specific as to whether there should be any further req
>                                ^^^^^^^^^^^^^
Consider shortening this phrase to just "whether", or rephrase the sentence to
avoid "as to".

Section 7.2, paragraph 9, nit:
> D consider the body stale, remove any body, and release Tokens and Request-T
>                                   ^^^^^^^^
Did you mean "anybody"?

Section 7.2, paragraph 10, nit:
> limit the potential wait needed calculated when using PROBING_WAIT. NON_PROB
>                                 ^^^^^^^^^^
"needed calculated" is only accepted in certain dialects. For something more
widely acceptable, consider "to be calculated".

Section 7.2, paragraph 14, nit:
> G_WAIT. Note: For the particular DOTS application, PROBING_RATE and other
>                                  ^^^^
An apostrophe may be missing.

Section 7.2, paragraph 15, nit:
> s. Even when not negotiated, the DOTS application uses customized defaults as
>                                  ^^^^
An apostrophe may be missing.

Section 7.2, paragraph 19, nit:
> rived for each body for at least a 24 hour period and it is known that there
>                                    ^^^^^^^
When a number forms part of an adjectival compound, use a hyphen: "24-hour"

Section 7.2, paragraph 19, nit:
> each body for at least a 24 hour period and it is known that there are no ot
>                                  ^^^^^^^^^^
Use a comma before 'and' if it connects two independent clauses (unless they
are closely connected and short).

Section 7.2, paragraph 19, nit:
>  situation re-evaluated for another 24 hour period until there is no report
>                                     ^^^^^^^
It appears that a hyphen is missing.

Section 7.2, paragraph 19, nit:
> PAYLOADS values, a peer may continue indicate that there are some missing pa
>                             ^^^^^^^^^^^^^^^^^
Probably a preposition is missing after 'continue'.

Section 7.2, paragraph 22, nit:
> tinue) Response Code on receipt of all of the MAX_PAYLOADS payloads to preven
>                                    ^^^^^^^^^^
Consider using "all the".

Section 7.2, paragraph 22, nit:
> t unnecessarily delaying. If not all of the MAX_PAYLOADS payloads were receiv
>                                  ^^^^^^^^^^^^^
Consider using "all the".

Section 7.2, paragraph 24, nit:
> xt set of payloads on receipt of all of the MAX_PAYLOADS payloads to prevent
>                                  ^^^^^^^^^^
Consider using "all the".

Section 7.2, paragraph 24, nit:
> e server unnecessarily delaying. Otherwise the client SHOULD delay for NON_R
>                                  ^^^^^^^^^
Did you forget a comma after a conjunctive/linking adverb?

Section 10.1.3, paragraph 5, nit:
> - Tag by matching the token with the sent request. CoAP CoAP
>                                      ^^^^
Did you mean "scent"?

Section 10.2, paragraph 2, nit:
> n is not required for Q-Block2; the observe detail can thus be ignored. 10.2
>                                 ^^^^^^^^^^^
After 'the', do not use a verb. Make sure that the spelling of 'observe' is
correct. If 'observe' is the first word in a compound adjective, use a hyphen
between the two words. Note: This error message can occur if you use a verb as
a noun, and the word is not a noun in standard English.

Section 10.2.1, paragraph 2, nit:
> The same process is repeated when an Observe is triggered, but no loss is ex
>                                   ^^^^^^^^^^
After 'an', do not use a verb. Make sure that the spelling of 'Observe' is
correct. If 'Observe' is the first word in a compound adjective, use a hyphen
between the two words. Note: This error message can occur if you use a verb as
a noun, and the word is not a noun in standard English.

Section 10.2.3, paragraph 1, nit:
> y Figure 10 shows the example of an Observe that is triggered but for which s
>                                  ^^^^^^^^^^
After 'an', do not use a verb. Make sure that the spelling of 'Observe' is
correct. If 'Observe' is the first word in a compound adjective, use a hyphen
between the two words. Note: This error message can occur if you use a verb as
a noun, and the word is not a noun in standard English.

Section 10.2.4, paragraph 1, nit:
> t Figure 11 shows the example of an Observe that is triggered but only the fi
>                                  ^^^^^^^^^^
After 'an', do not use a verb. Make sure that the spelling of 'Observe' is
correct. If 'Observe' is the first word in a compound adjective, use a hyphen
between the two words. Note: This error message can occur if you use a verb as
a noun, and the word is not a noun in standard English.

Section 10.3.3, paragraph 5, nit:
> t-Tag by matching the token with the sent request. CoAP CoAP C
>                                      ^^^^
Did you mean "scent"?

Section 12.3, paragraph 3, nit:
> blocks+cbor-seq o Encoding: - o Id: TBA3 o Reference: [RFCXXXX] Th
>                                 ^^
Possible spelling mistake found

Section 13.2, paragraph 4, nit:
> try] Boucadair, M., Reddy.K, T., Doron, E., chenmeiling, c.,
>                           ^
Add a space between sentences

Section 13.2, paragraph 9, nit:
> org/info/rfc8610>. [RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P
>                                    ^
Add a space between sentences

"A.1.", paragraph 7, nit:
>  It is up to the implementation as to whether the application process stops t
>                                 ^^^^^^^^^^^^^
Consider shortening this phrase to just "whether", or rephrase the sentence to
avoid "as to".

"A.2.", paragraph 4, nit:
>  It is up to the implementation as to whether the application process stops t
>                                 ^^^^^^^^^^^^^
Consider shortening this phrase to just "whether", or rephrase the sentence to
avoid "as to".

"B.1.", paragraph 1, nit:
>  use of Q-Block1 Option with a reliable transport as shown in Figure 20. Ther
>                              ^^^^^^^^^^^^^^^^^^^^^^^
Uncountable nouns are usually not used with an indefinite article. Use simply
"reliable transport".

"B.1.", paragraph 2, nit:
> shown in Figure 20. There is no acknowledgment of packets at the CoAP layer,
>                                 ^^^^^^^^^^^^^^
Do not mix variants of the same word ('acknowledgment' and 'acknowledgement')
within a single text.

"B.2.", paragraph 1, nit:
>  of the use of Q-Block2 Option with a reliable transport is shown in Figure
>                                     ^^^^^^^^^^^^^^^^^^^^
Uncountable nouns are usually not used with an indefinite article. Use simply
"reliable transport".

Document references draft-ietf-core-echo-request-tag-11, but
draft-ietf-core-echo-request-tag-12 is the latest available revision.

---

From: <[email-masked]>
Date: Wed, 5 May 2021 09:02:15 +0000

Hi Lars, all, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Lars Eggert via Datatracker [mailto:[email-masked]]
> Envoyé : mercredi 5 mai 2021 10:00
> À : The IESG <[email-masked]>
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Objet : Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with
> DISCUSS and COMMENT)
> 
> email addresses included in the To and CC lines. (Feel free to cut
> this introductory paragraph, however.)
> 
> 
> I understand that COAP was initially chosen to transport DOTS
> signaling messages due to their small size, support for structured
> messages and request/response semantics, as well as the ability to
> function over lossy paths such as found in IoT deployment, which COAP
> is architected for.
> 
> DOTS now seems to desire to transport larger messages,

[Med] It is true that DOTS was designed with compact messages in mind, but handling large data was **already** covered in the DOTS spec (see Section 4.4.2 of RFC8782). We then found that the normal block-wise mechanism is suboptimal for the DOTS application.

 and this
> document extends CORE to enable this functionality. However, this
> CORE extension seems to solely focus on Internet deployment
> scenarios, essentially attempting to re-architect COAP into a general
> Internet transport protocol for transmission over paths with high
> loss rates. I do not believe that the CORE WG is chartered to do
> this.
> 

[Med] This work is part of the maintenance of RFC7959 that is covered by the core WG charter:

==
The working group will perform maintenance on its first four
standards-track specifications:
==

As you can read in https://datatracker.ietf.org/doc/minutes-interim-2020-core-06-202006101600/, the WG decided to:
"scope it as an extension (as opposed to blockwise-bis)".

The plan is to use this extension as the base for a bis when the WG will be ready to cover other aspects that are left out of scope for this extension. See, e.g., https://datatracker.ietf.org/doc/minutes-110-core-202103121300/: "it can be seminal material for a blockwise bis document".

I let the AD and the chairs further elaborate on the charter point.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Lars Eggert <[email-masked]>
Date: Wed, 5 May 2021 13:05:23 +0300

Hi Med,

> standards-track specifications:

those four specifications are RFC 6690, RFC 7252, RFC 7641 and draft-ietf-core-block (= RFC7959).

In my understanding, draft-ietf-core-new-block is a separate COAP extension, not a maintenance effort related to RFC7959. The abstract even says that the new mechanisms are similar to, but not a replacement for, RFC 7959. If it were maintenance, draft-ietf-core-new-block would replace or at the very least update some parts of RFC7959.

> "scope it as an extension (as opposed to blockwise-bis)".

I think this decision is exactly were the WG went beyond its charter.

> The plan is to use this extension as the base for a bis when the WG will be ready to cover other aspects that are left out of scope for this extension. See, e.g., https://datatracker.ietf.org/doc/m…

Until that plan has consensus and is chartered, draft-ietf-core-new-block IMOR remains a COAP extensions that is out-of-charter.

> I let the AD and the chairs further elaborate on the charter point.

I'm sure we'll discuss this on the call tomorrow.

Thanks,
Lars