Re: [Dots] draft-ietf-dots-signal-channel-23: application/cbor media types

[Benjamin Kaduk <[e-mail]>]

On Tue, Sep 04, 2018 at 07:27:07AM +0000, Konda, Tirumaleswar Reddy wrote:
> > -----Original Message-----
> > From: Klaus Hartke <[e-mail]>
> > Sent: Monday, September 3, 2018 5:04 PM
> > To: Konda, Tirumaleswar Reddy <[e-mail]>;
> > [e-mail]
> > Subject: RE: draft-ietf-dots-signal-channel-23: application/cbor media types
> > 
> > This email originated from outside of the organization. Do not click links or
> > open attachments unless you recognize the sender and know the content is safe.
> > 
> > Konda, Tirumaleswar Reddy wrote:
> > > By default DOTS signal Channel uses port number 4646 assigned by IANA
> > > and the DOTS server knows only DOTS requests will arrive on this port,
> > > and "DOTS Signal Channel Claims" registry will be created (just like
> > > it's done in
> > > https://tools.ietf.org/html/rfc8392) to accommodate new fields.  Do
> > > you still see a need to define specific media types for DOTS ?
> > 
> > In short: Yes, because "we know it from the context" is exactly what is known to
> > cause problems, e.g., when you want to take the information out of this context
> > or evolve the application later.
> 
> I don't get your comment, It is mandatory for the DOTS server to listen on port 4646 and DOTS client must only send mitigation requests to 4646. Further, the destination port is not multiplexed 
> with any other protocol.  What problems do you see (an example probably will help understand the problem better) ?

I think the claim is that you can't be sure there will not be some future
usage scenario that involves conveying this data structure within some
additional (supplementary?) data stream.  In effect, you are assuming
the invariants that this data structure only goes on port 4646 and nothing
else goes on port 4646; while the latter is likely to hold, I think that
skepticism of the former is pretty reasonable.

-Ben