I have the following comments, which I'd like to be taken into
consideration during this WGLC:
There are two issues I'd like clarified:
---
Page 7, section 3.5, para 2.
"Alternatively, DTLS over DCCP implemenations MAY choose to use its own
PMTU Discovery"...
- The recent comments from Pasi, show a different interpretation of this
to what I had in mind, so I'd like clarification on this.
- If DTLS wants to probe, just to be absolutely sure the path supports
it, that's fine with DCCP. But to me, the probes are not really an
ALTERNATIVE to DCCP doing this, but DCCP does not provide a way to send
any packet it likes with a size bigger than MPS (except where the API
provides optional fragmentation, which is not what is intended here).
<see related mail thread>
---
Page 8, section 3.6, first para.
- Following the WG meeting discussions at the last IETF meeting, it
seems we need to consider the requirement that applications using
DTLS/DCCP and ones not using DTLS/DCCP "MUST use different Service
Codes". It was suggested that this could be too strong, and noted that
this is NOT an interoperability issue, and not one that the IETF could
easily enforce.
- I wonder if it is wiser to recommend that they "SHOULD register and
use different Service Codes".
- To me, the current text does seem to describe the rationale that would
support this recommendation (i.e. say why we have written this).
---
Page 8, section 3.7, final para
I question whether this is an issue of "feeling" - if it needs a
different Service Code, they should register one and use it:
/If the
application developers feel that the new version of DTLS provides
^^^^
significant new capabilities to the application that will change the
behavior of middleboxes, they MAY use a new Service Code./
I suggest:
/If a new version of DTLS provides
significant new capabilities to the application that will change the
behavior of middleboxes, an application developer MAY register a new
Service Code./
---
-----------------------------------------------------------------------
Editorial:
---
It seems that you have chosen CCIDn (e.g. CCID3) to denote CCID 3, other
RFCs have used a space or hyphen (if they wish to directly link the
number and CCID). Would one of these other forms be acceptable?
---
page 4, section 3.2, final para, line 5
/Server implementations/
^^^^^^^
- This is not really a feature negotiation or call-setu-function, so it
would be better to omit the word server. To me this applies equally to
clients and servers.
---
page 7, section 3.5
- Please change: /CMPS/CCMPS/
---
Page 8, section 3.7
/to this document, it is assumed/
^^
- I think it would be clearer to use "which" instead of "it" to remove
possible amibiguity that this is speaking of the document itself.
----
Page 8, section 3.7, final para
- It would be helpful to remind readers that DTLS itself identifies the
version, before proceding with the SC discussion:
Please add:
"The DTLS version value [RFC4347] identifies the version of DTLS that is
in use.
----
I note this I-D does not include the optional section on acknowledgments
section.
----
