jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-core-stateless

Commentary: This is some advice on how big the replay window needs to be . 
 doca 64 bit tag is recommended , combined with a sequence number and a docreplay window . Where encryption is not needed , HMAC - SHA-256 , doccombined with a sequence number and a replay window , may be used . [ [ TODO ] ] 
 An absolute timestamp is probably not necessary , as the key should be newly generated on a reboot . A boot - relative timestamp may be enough . The window pretty much becomes the " patience " value -- how long does the client wait for getting its response ?
This size of the replay window depends upon the number of outstanding
requests that need to be outstanding.  This can be determined from
the rate at which new ones are made, and the expected duration in
which responses are expected.
For instance, given a CoAP ACK_TIMEOUT of 2s, and a request rate of
10 requests/second, any request that is not answered within 2s will
be considered to have failed.  Thus at most 20 request can be
outstanding at a time, and any convenient replay window larger than
20 will work.  As replay windows are often implemented with a sliding
window and a bit, the use of a 32-bit window would be sufficient.
For use cases where requests are being relayed from another node, the
request rate may be estimated by the total link capacity allocated
for that kind of traffic.  An alternate view would consider how many
IPv6 Neighbor Cache Entries (NCEs) the system can afford to allocate
for this use.
Draft: draft-ietf-core-stateless

Commentary: … into more positive language 
 [ [ TODO ] ] 
 Not sure I follow the 5077 analogy . Do we ever plan to use stateless without some integrity protection ? We might save a lot of weasel - wording by simply requiring it .
It is generally expected that the use of encryption, integrity
protection, and replay protection for serialized state is
appropriate.  In the absence of integrity and reply protection, an
on-path attacker or rogue server/intermediary could return a state
(either one modified in a reply, or an unsolicited one) that could
alter the internal state of the client.  However, a careful analysis
of any potential attacks to the security and privacy properties of
the system might reveal that there are cases where such cryptographic
protections do not add value in a specific case.
It is generally expected that the use of encryption, integrity
protection, and replay protection for serialized state is
appropriate.  In the absence of integrity and reply protection, an
on-path attacker or rogue server/intermediary could return a state
(either one modified in a reply, or an unsolicited one) that could
alter the internal state of the client.  It is this reason that at
least the use of integrity protection on the token is always
recommended.
It maybe that in some very specific case, as a result of a careful
and detailed analysis of any potential attacks, that there may be
cases where such cryptographic protections do not add value.  The
authors of this document have not found such a use case as yet.
Draft: draft-ietf-core-stateless

Commentary: This pull request tries to motivate why ~60min is about right . 
 section 2.2.2 : docSince network addresses may change , a client SHOULD NOT assume that docextended token lengths are supported by a server later than 60 docminutes after receiving the most - recent response with an extended doctoken length . 60 minutes for address changes ? Out of curiosity , upon what was this based ? I lack a good deal of context , but this kind of feels like the kind of constant that will get baked into code and come to govern some behaviour that later might need updating . 
 The number indeed sounds arbitrary . We could make use of the parameter mechanics that RFC 7252 has ( ACK_TIMEOUT and friends ) and set the default to 1800 s.
Since network addresses may change, a client SHOULD NOT assume that
extended token lengths are supported by a server later than 60
minutes after receiving the most-recent response with an extended
token length.
Since network addresses may change, a client SHOULD NOT assume that
extended token lengths are supported by a server for an unlimited
duration.  Unless additional information is available, the client
should assume that addresses (and therefore extended token lengths)
are valid for a minimum of 1800s, and for a maximum of 86400s (1
day).  A client may use additional forms of input into this
determination.  For instance a client may assume a server which is in
the same subnet as the client has a similiar address lifetime as the
client.  The client may use DHCP lease times or Router Advertisements
to set the limits.  For servers which is not local, if the server was
looked up using DNS, then the DNS resource record will have a Time To
Live, and the extended token length should be kept for only that
amount of time.