Subject: Re: [Dots] Nits on draft-ietf-dots-signal-channel-23

From: Roman Danyliw <[email-masked]>
Date: Tue, 4 Sep 2018 15:39:13 +0000

Hello Tiru!

> -----Original Message-----
> From: Dots [mailto:[email-masked]] On Behalf Of Konda,
> Tirumaleswar Reddy
> Sent: Thursday, August 23, 2018 2:27 AM
> To: Roman Danyliw <[email-masked]>; [email-masked]
> Subject: Re: [Dots] Nits on draft-ietf-dots-signal-channel-23
> 
> > -----Original Message-----
> > From: Roman Danyliw <[email-masked]>
> > Sent: Wednesday, August 22, 2018 9:02 PM
> > To: Konda, Tirumaleswar Reddy
> <[email-masked]>;
> > [email-masked]
> > Subject: RE: Nits on draft-ietf-dots-signal-channel-23
> >
> > 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.
> >
> > Hi Tiru!
> >
> > > -----Original Message-----
> > > From: Konda, Tirumaleswar Reddy
> > > [mailto:[email-masked]]
> > > Sent: Wednesday, August 22, 2018 1:30 AM
> > > To: Roman Danyliw <[email-masked]>; [email-masked]
> > > Subject: RE: Nits on draft-ietf-dots-signal-channel-23
> > >
> > > > -----Original Message-----
> > > > From: Dots <[email-masked]> On Behalf Of Roman Danyliw
> > > > Sent: Wednesday, August 22, 2018 3:34 AM
> > > > To: [email-masked]
> > > > Subject: [Dots] Nits on draft-ietf-dots-signal-channel-23
> > > >
> > > > (5) Registration guidance for DOTS Signal Channel CBOR Mapping
> > > > Registry is precise.  However, I'm left seeking guidance on how to
> > > > process messages with fields not specified in this draft (i.e.,
> > > > fields registered after this draft is published).  The closest I
> > > > can find is language in Section 6 that states "[t]he recipient of
> > > > the payload MAY reject the  information if it is not suitably mapped."
> > > > I would also benefited from a preamble describing the purpose of
> > > > the registry -- is it a
> > > way to extend the protocol with new optional fields?
> > >
> > > Yes, we will have to request IANA to create "DOTS Signal Channel Claims"
> > > registry (just like it's done in https://tools.ietf.org/html/rfc8392
> > > and new drafts like
> > > https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-13#section-
> > > 8.12  are using the registry defined in RFC8392 to add new claims).
> > > "Parameter Name" in the table 6 needs to be changed to "Claim Name".
> > >
> > > In addition, to accommodate future drafts to add new fields, the
> > > fields should be classified into " comprehension-optional" and
> > > "comprehension- required" for DOTS agents to ignore or reject
> > > unknown fields. The key value range can be further split to
> > > accommodate vendor-specific, comprehension- optional and
> > > comprehension-required attributes. The fields defined in this spec
> > > will be of type comprehension-
> > required.
> >
> > We're in complete agreement on the purpose of the registry.  It's the
> > explanation of the registry I'm proposing is missing.
> >
> > IMO, the draft would benefit from explicitly stating (1) the
> > processing implications of this registry (just as you stated above so
> > that the DOTS agents knows what to reject); and (2) noting that the
> > registry is a general means for extensibility. We have had several
> > ideas or individual drafts come to the WG requesting the addition of
> > new, optional fields to the protocol (e.g., draft-yang-
> > dos-type-for-dots-00 at IETF 102; draft-doron-dots-telemetry-00 at IETF 97).
> > The WG deferred them but we never explicitly resolved the issue of
> > extensibility. The registry addresses the issue of extensibility.  I'm
> > proposed as few words that state that.
> 
> Sure, will update draft.

Thanks for the new text in -24.  IMO this new partitioned registry provides the needed extensibility.

The language in -24 addresses my feedback. 

Roman

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 5 Sep 2018 10:21:03 +0000

> Sent: Tuesday, September 4, 2018 9:09 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>;
> [email-masked]
> 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.
> 
> Hello Tiru!
> 
> > > > > Registry is precise.  However, I'm left seeking guidance on how
> > > > > to process messages with fields not specified in this draft
> > > > > (i.e., fields registered after this draft is published).  The
> > > > > closest I can find is language in Section 6 that states "[t]he
> > > > > recipient of the payload MAY reject the  information if it is not suitably
> mapped."
> > > We're in complete agreement on the purpose of the registry.  It's
> > > the explanation of the registry I'm proposing is missing.
> > >
> > > processing implications of this registry (just as you stated above
> > > so that the DOTS agents knows what to reject); and (2) noting that
> > > the registry is a general means for extensibility. We have had
> > > several ideas or individual drafts come to the WG requesting the
> > > addition of new, optional fields to the protocol (e.g., draft-yang-
> > > extensibility. The registry addresses the issue of extensibility.
> > > I'm proposed as few words that state that.
> >
> > Sure, will update draft.
> 

Thanks, Roman. The only pending comment to resolve is the use of specific media type.

Cheers,
-Tiru