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

[Roman Danyliw <[e-mail]>]

Hello Tiru!

> -----Original Message-----
> From: Dots [mailto:[e-mail]] On Behalf Of Konda,
> Tirumaleswar Reddy
> Sent: Thursday, August 23, 2018 2:27 AM
> To: Roman Danyliw <[e-mail]>; [e-mail]
> Subject: Re: [Dots] Nits on draft-ietf-dots-signal-channel-23
> 
> > -----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.

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

The language in -24 addresses my feedback. 

Roman