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

From: Klaus Hartke <[email-masked]>
Date: Mon, 3 Sep 2018 11:34:04 +0000

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.

Klaus

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 4 Sep 2018 07:27:07 +0000

> -----Original Message-----
> From: Klaus Hartke <[email-masked]>
> Sent: Monday, September 3, 2018 5:04 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>;
> [email-masked]
> 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.
> 
> > 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) ?

Cheers,
-Tiru

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 4 Sep 2018 14:24:11 -0500

> 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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 5 Sep 2018 02:59:28 +0000

> From: Benjamin Kaduk <[email-masked]>
> Sent: Wednesday, September 5, 2018 12:54 AM
> To: Konda, Tirumaleswar Reddy <[email-masked]>
> Cc: Klaus Hartke <[email-masked]>; [email-masked]
> 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.
> > >
> > > > 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