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

From: Roman Danyliw <[email-masked]>
Date: Tue, 21 Aug 2018 22:03:54 +0000

Hello!

I did another review on -23 of the signal channel draft:

No action required
===============
(1) Idnits -- nothing actionable
(2) YANG module (Section 6) IS consistent with initial IANA table (Section 9.3.2) 

Discussion
========
(3) Figure 5 and 6 are inconsistent.  Figure 5 uses 'Uri-Path: "version"' and Figure 6 (and all subsequent figures) uses 'Uri-Path: "v1"'.  It seems like Figure 5 should also use "v1".

(4) Section 4.4.1 states that "major and minor version nomenclature to manage versioning; DOTS signal channel in this specification uses 'v1' major version."   No example shows how a minor version should be expressed.  Is it the obvious "v1.0"?

(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?

Roman

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 22 Aug 2018 05:30:14 +0000

> -----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
> 
> 
> 
> Hello!
> 
> (3) Figure 5 and 6 are inconsistent.  Figure 5 uses 'Uri-Path: "version"' and
> Figure 6 (and all subsequent figures) uses 'Uri-Path: "v1"'.  It seems like Figure
> 5 should also use "v1".

Yes. 

> 
> (4) Section 4.4.1 states that "major and minor version nomenclature to manage
> versioning; DOTS signal channel in this specification uses 'v1' major version."
> No example shows how a minor version should be expressed.  Is it the obvious
> "v1.0"?

Good catch, will fix. 

> 
> (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. 

Cheers,
-Tiru

> 
> Roman
> 
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 22 Aug 2018 15:32:11 +0000

Hi Tiru!

> 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
> 
> > (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.

Roman

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 23 Aug 2018 06:27:14 +0000

> From: Roman Danyliw <[email-masked]>
> Sent: Wednesday, August 22, 2018 9:02 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.
> 
> Hi Tiru!
> 
> > > 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
> > 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-
> > 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