Last Call Review of draft-ietf-dots-data-channel-27
review-ietf-dots-data-channel-27-tsvart-lc-trammell-2019-03-16-00

Request Review of draft-ietf-dots-data-channel
Requested rev. no specific revision (document currently at 29)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2019-03-13
Requested 2019-02-27
Draft last updated 2019-03-16
Completed reviews Genart Last Call review of -27 by Roni Even (diff)
Tsvart Last Call review of -27 by Brian Trammell (diff)
Assignment Reviewer Brian Trammell
State Completed
Review review-ietf-dots-data-channel-27-tsvart-lc-trammell-2019-03-16
Reviewed rev. 27 (document currently at 29)
Review result Ready with Issues
Review completed: 2019-03-16

Review
review-ietf-dots-data-channel-27-tsvart-lc-trammell-2019-03-16

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

Apologies for missing the last call deadline; however I hope the input is useful.

This document is basically ready; some issues and questions for the WG below.

General Considerations, Data Channel Design
------------------------------------------------

On its own this document is okay from a transport considerations standpoint: 
the data channel does not have to operate in a degraded environment (i.e.,. on an 
interface under attack) and makes perfectly reasonable use of RESTCONF. The 
companion signal channel document will require (much) more careful attention 
from the transport directorate.

Please pay attention to whatever your SECDIR review says anything about the 
use of TLS client authentication (as specified with mutual authentication). 

I suppose the use of mutual auth was inherited from RESTCONF, though? 
I'd be curious to know whether other client authentication schemes were considered.

The use of cdid as a client rate association token and rate-limiter seems open to 
misconfiguration or misuse. Is there a concept for protecting against this beyond
log-and-detect?

Data Model Design
--------------------

The target-fqdn element in the alias definition seems prone to cause 
confusing results if used naïvely (indeed the document itself points
this out). On the other hand, in dynamic service environments it is quite useful
for an alias to refer to a name as opposed to a set of addresses. Did the working 
group consider including some further context for the resoultion of these into 
IP addresses (for example, by providing a link to a DoT/DoH server to update 
the resolutions periodically)? If not, perhaps some text about doing this out
of band would be helpful.

Thanks, cheers,

Brian