I have read the latest version of this specification during the WGLC and
believe this is an important topic to publish a document.
The current draft appears to have addressed issues I think were
important and would seem nearly ready for publication, however I do have
some queries, as listed below.
Best wishes,
Gorry
---
Section 3.3
- I think some sections miss context on why the decision was made, e.g.
in 3.3, please do say briefly why the WG chose to do this.
---
Section 3.3.1:
- Have you thought about whether this section should also reaffirm that
the checksum value in the encapsulated DCCP header is always zero?
- replace /Chesksums/ with /Checksums/
---
Section 6:
/The option is a binary one however; either allow all DCCP
applications or allow none./
- This seems a little harsh. The options based on the UDP-header are as
stated. A firewall than interprets this specification could in principle
look inside the UDP encaps and filter based on DCCP information.
It doesn't sound that implausible given the sophistication of many
current firewalls, however it would be extra complexity that would need
to be justified. In my opinion, we should encourage this, so that
firewalls can open pin-holes for DCCP in the same way as they do for
other transports.
---
- I see the value of the IANA-specified destination port for a client
server app using a NAPT, where the NAPT changes only the src port as it
leaves the client, and does this differently for each sender address
behind the NAPT. What is the expected port usage at the receiver? Does
it listen on the IANA port bound to any source port? Can you say more here?
---
References
- The references have not been split between normative and informative,
the normative refs should have been agreed by the WGLC.
- I think the following are not normative to this specification:
RFC4787, RFC5597, RFC5238, RFC5596, RFC5595
---
UPDATES Line?
- The document explicitly says this updates RFC 5762, but the boilere
text at the head of the ID does not identify this as an update. Please
add a boiler plate line that explicitly states what is updated by this
specification.
- Are there issues with an Experimental RFC updating a standards-track
RFC???
- Is this intended to update RFC 4340? - if so, same question as above.
----
Note:
/(default port awaiting IANA action)/
- As I understand the IETF procedure, this could now be allocated by an
IANA request. I'm assuming this is a "registered" port, rather than a
"well-known" port?
- The RFC-to-be can then say this document allocates port XX for use by
this method.
----
The following additional comments seem to be NiTs:
---
3. DCCP-UDP
/insert a UDP ([RFC0768]) /
^ ^
-The brackets around the citation seem odd to me.
---
/and there are no other IP addresses embedded./
- There are no other IP addresses embedded in the encapsulation header,
there could be in the DCCP application data, with all that implies.
---
| Application Data Area | Variable length (could be 0)
- I prefer straight /Application Data/
rather than /Application Data Area/
- but I recall both being used in RFC 4340, so I guess this is personal
preference.
---
--
Prof Gorry Fairhurst, School of Engineering, University of Aberdeen.
The University of Aberdeen is a charity registered in Scotland,
No SC013683.
