[core] Comments on draft-ietf-core-echo-request-tag-02

[Jim Schaad <[e-mail]>]

I have read this document and I have the following comments:

* Introduction - you say several enhancements, but there are only two new
options.  What are the other enhancements?

* Introduction - The sentence "This document specifies ..." this sentence
says you are doing two thing and then there are two sentences.  I think you
can tighten this up with a colon following "Request-Tag option:", delete the
rest of this sentence and keep the next two sentences.

* Section 1.1 para 1 - I think you should provide a couple of reasons why
this is not a suitable solution.  I can think of multiple different reasons:
a) The amount of traffic and resources required - which may not be a problem
with both sides just one. b) Going through proxies where the freshness gets
lost as a client renegotiation does not get to the server and a proxy
renegotiation says nothing about the client. c) Amount of time involved.

* Section 1.3 - I am a bit lost in this section.  When doing matches between
a request and a response I am matching up the message id and the token if it
exists.  You need some additional text in here to describe why it is that
you are talking about something interesting to me.  

* Section 2.1 - Something seems to be odd.  I don't think the RFC editor
note is correct.  I think a paragraph must have disappeared.

* Section 2.2 - I don't think if you reboot that you have lost time
synchronization, rather you have lost time continuity.  That said the
current term may be state of art and thus correct.  To me synchronization
implies a minimum of two parties.

* Section 2.2 - I think that you need to make some arguments about what
happens if an Echo option value is provided to multiple entities either
because the server will just re-use it's current value for some period of
time after creation (valid for time m and used for time m/3) or because a
proxy provides the same answer to two different clients.   Note that this
seems to be not recommended in item 2 of section 2.3

* Section 2.3 - Item 4 - I don't understand what is going on here.  I am not
sure what the device is joining as (a responder?)  Is the sync done by two
unicast messages or a unicast followed by a multicast?  

* Section 2.3 - Item 5 - I am not sure that this is a reasonable answer for
having a proxy sitting there.  I could easily be wrong and should probably
spend some time thinking about how this does/does not work.

* Section 3.1 - The note to the RFC editor has me confused.  Firstly, I am
not sure why it should be moved rather than just staying here.  

* Section 3.1 - I think that the value of Request-Tag is potentially going
to be different depending on if it is in the inside rather than the outside.
You may be doing two different block transfers and each needs its own value.

* Section 3.2 - the first paragraph does not scan.  I am not sure what it
says as it seems to be contradictory.

* Section 3.2 - para 2 - The example sentence looks odd.  Do you mean it can
have a cached response not a free response?

* Section 3.2 - para "especially" - I find the first sentence very hard to
understand.

* Section 3.3 - last para - how do you recycle something that is absent?  I
think the last clause needs examining.

* Section 3.4.1 - Item 2 - how is a client supposed to be able to know this
if the proxy in the middle just passes it through w/o changing it?  Two
different clients could end up with the same Request-Tag.  One would hope
that they would have different tokens because of the proxy however.

* Section 3.4.1 - This seems backwards.  I thought that OSCORE was tightly
bound to the end point, but this paragraph says it is not.

* Section 3.4.3 - You have a "Section TBA" here

* Section 3.4.3 - Please keep the section for justification of Request-Tag
being repeatable.

* Section 5 - I have not seen a justification for this anyplace.

* Section 7 - para 1 - What is the problem w/ using an encrypted wall clock
time for a timestamp?  These text appears to say that this is a bad idea but
the issues seem to be with using unencrypted items not with the wall clock.
The next sentence makes more sense about why not to use one.  

* Appendix A - I would think that if you send a 32-bit timestamp in the
clear w/ an integrity value that one can start making guesses about some of
the same privacy problems as the use of a wall clock.  Knowing when a server
was last reset could tell you the same things.

Jim








s/bock-wise/block-wise/
s/incomplte/incomplete/
s/woud/would/