Subject: [core] draft-ietf-core-comi-02: SID and Delta SID usage inconsistencies ?

From: Tanguy Ropitault <[email-masked]>
Date: Thu, 29 Mar 2018 20:16:31 -0400

Hi,
I'm wondering if there may be some inconsistencies between SID definition
in draft-ietf-core-yang-cbor-05 and its usage in draft-ietf-core-comi-02.
The short version of the story is:
- draft-ietf-core-yang-cbor-05 defines SID as an unsigned integer "YANG
Schema Item iDentifier (SID): Unsigned integer used to identify different
YANG items."
- draft-ietf-core-comi-02 uses in some sections and examples SID with a
negative value (or to be sharp, use delta SID where SID should be normally
used)

Let's use an example for the long version of the story:

Section 2.3  of draft-ietf-core-comi-02 states that:
"When part of a payload, instance identifiers are encoded in CBOR based on
the rules defined in [I-D.ietf-core-yang-cbor] section 5.13.1"

Section 5.13.1 of draft-ietf-core-yang-cbor-05 states that:

"Single instance data nodes MUST be encoded using a CBOR unsigned integer
data item (major type 0) and set to the targeted data node SID."

*** Please note that I'm using the single instance identifier case for a
matter of clarity but the same applies for list instance identifier.

So according to the sentences above, a single instance identifier that is a
part of a payload can only be an unsigned int.

draft-ietf-core-comi-02 also states that FETCH request format must be:
"The FETCH request payload contains a list of instance-identifier encoded
based on the rules defined by Content-Format
application/yang-selectors+cbor in Section 2.5"

application/yang-selectors+cbor is defined in Section 2.5 as:

"represents a CBOR YANG document containing a list of data node selectors
(i.e. instance identifier)."

Moreover, Section 2.5 clearly recall this:
"YANG instance identifier, encoded based on the rules defined in [
I-D.ietf-core-yang-cbor
<https://tools.ietf.org/html/draft-ietf-core-comi-02#ref-I-D.ietf-core-yang-cbor>]
section 5.13.1
<https://tools.ietf.org/html/draft-ietf-core-comi-02#section-5.13.1>."

So the FETCH request payload can only be made of instance identifier which
are de-facto unsigned int (in the single instance identifier case) based on
Section 2.3 and 5.13.1. However, due to the usage of delta SID for
application/yang-selectors+cbor format, some instance identifier of a FETCH
request can be negative (as shown in FETCH example
in draft-ietf-core-comi-02). In fact, it seems that the sentence "When part
of a payload, instance identifiers are encoded in CBOR based on the rules
defined in [I-D.ietf-core-yang-cbor] section 5.13.1" is most of the time
superseded by DeltaSID usage.

So IMO, it's a little bit confusing and something may need to be added.

Tanguy Ropitault (Acklio)

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 30 Mar 2018 12:51:40 +0900

Hi Tanguy,

SIDs are unsigned, indeed. They are sometimes encoded as deltas. We need to stop calling those deltas SIDs. They aren't. If you find any place in the document where that is the case, please identify them. SID deltas are not confusing if they are not deliberately mixed up with SIDs. 

Sent from mobile

> On 30. Mar 2018, at 09:16, Tanguy Ropitault <[email-masked]> wrote:
> 
> Hi,
> I'm wondering if there may be some inconsistencies between SID definition in draft-ietf-core-yang-cbor-05 and its usage in draft-ietf-core-comi-02. 
> - draft-ietf-core-yang-cbor-05 defines SID as an unsigned integer "YANG Schema Item iDentifier (SID): Unsigned integer used to identify different YANG items."
> - draft-ietf-core-comi-02 uses in some sections and examples SID with a negative value (or to be sharp, use delta SID where SID should be normally used)
> 
> "When part of a payload, instance identifiers are encoded in CBOR based on the rules defined in [I-D.ietf-core-yang-cbor] section 5.13.1"
> 
> "Single instance data nodes MUST be encoded using a CBOR unsigned integer data item (major type 0) and set to the targeted data node SID."
> 
> *** Please note that I'm using the single instance identifier case for a matter of clarity but the same applies for list instance identifier. 
> 
> So according to the sentences above, a single instance identifier that is a part of a payload can only be an unsigned int.
> 
> "The FETCH request payload contains a list of instance-identifier encoded based on the rules defined by Content-Format application/yang-selectors+cbor in Section 2.5"
> 
> "represents a CBOR YANG document containing a list of data node selectors (i.e. instance identifier)."
> 
> "YANG instance identifier, encoded based on the rules defined in [I-D.ietf-core-yang-cbor] section 5.13.1."
> 
> So the FETCH request payload can only be made of instance identifier which are de-facto unsigned int (in the single instance identifier case) based on Section 2.3 and 5.13.1. However, due to the usage of delta SID for application/yang-selectors+cbor format, some instance identifier of a FETCH request can be negative (as shown in FETCH example in draft-ietf-core-comi-02). In fact, it seems that the sentence "When part of a payload, instance identifiers are encoded in CBOR based on the rules defined in [I-D.ietf-core-yang-cbor] section 5.13.1" is most of the time superseded by DeltaSID usage. 
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Tanguy Ropitault <[email-masked]>
Date: Fri, 30 Mar 2018 09:51:40 -0400

Thanks Carsten!

I think that my message just shows how confused I am. You're totally right
that Delta SID term should never be used as Delta is the correct term (and
both drafts never use the term Delta SID).

However, let's see that from an implementer perspective as it may help to
clarify:

So as an implementer, I'm expecting to declare an uint64 for instance
identifiers that are part of a payload. However, CoMI may need to use
signed int because of Delta (e.g. FETCH request). And that is what is
confusing IMO i.e., the "MUST" requirement is not always satisfied.

Tanguy

On Thu, Mar 29, 2018 at 11:51 PM, Carsten Bormann <[email-masked]> wrote:

> Hi Tanguy,
>
> SIDs are unsigned, indeed. They are sometimes encoded as deltas. We need
> to stop calling those deltas SIDs. They aren't. If you find any place in
> the document where that is the case, please identify them. SID deltas are
> not confusing if they are not deliberately mixed up with SIDs.
>
> Sent from mobile
>
> So according to the sentences above, a single instance identifier that is
> a part of a payload can only be an unsigned int.
>
> based on the rules defined by Content-Format application/yang-selectors+cbor
> in Section 2.5"
>
> application/yang-selectors+cbor format, some instance identifier of a
> FETCH request can be negative (as shown in FETCH example
> in draft-ietf-core-comi-02). In fact, it seems that the sentence "When
> part of a payload, instance identifiers are encoded in CBOR based on the
> rules defined in [I-D.ietf-core-yang-cbor] section 5.13.1" is most of the
> time superseded by DeltaSID usage.
>