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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

> -----Original Message-----
> From: Benjamin Kaduk <[e-mail]>
> Sent: Wednesday, September 5, 2018 12:54 AM
> To: Konda, Tirumaleswar Reddy <[e-mail]>
> Cc: Klaus Hartke <[e-mail]>; [e-mail]
> Subject: Re: [Dots] 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.
> 
> 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.

Okay, will introduce new media type "application/dots+cbor" for DOTS mitigation, config and re-direction, and will be a minor change for existing implementations.
I presume we will also have to add DOTS CBOR tag (just like its done in https://tools.ietf.org/html/rfc8392#section-6) 

Cheers,
-Tiru

> 
> -Ben