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

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

> -----Original Message-----
> From: Roman Danyliw <[e-mail]>
> Sent: Wednesday, August 22, 2018 9:02 PM
> To: Konda, Tirumaleswar Reddy <[e-mail]>;
> [e-mail]
> 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:[e-mail]]
> > Sent: Wednesday, August 22, 2018 1:30 AM
> > To: Roman Danyliw <[e-mail]>; [e-mail]
> > Subject: RE: Nits on draft-ietf-dots-signal-channel-23
> >
> > > -----Original Message-----
> > > From: Dots <[e-mail]> On Behalf Of Roman Danyliw
> > > Sent: Wednesday, August 22, 2018 3:34 AM
> > > To: [e-mail]
> > > 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.

Cheers,
-Tiru

> 
> Roman