Re: [Netconf] the name "checksum" in YANG library

[Vladimir Vassilev <[e-mail]>]

Hi Kent,

On 10/12/18 7:52 PM, Kent Watsen wrote:
> We should not try to ensure that two servers having the same response return the same value.
I do not disagree with that.
>    That would require the definition of a canonical form that we don't have.

IMO this is doable. There are other usecases apart from the yang library 
one that need canonical form representation of YANG data trees. Does 
"Restrictions for canonical form XML representation of YANG data" sound 
like a useful draft? A 1 page text with restrictions - some for the YANG 
data types lexical representation (identityref and instance-identifier) 
and some for the XML encoding format intended to guarantee the XML 
generated will be canonical nevertheless compatible with RFC 7950.

Vladimir

>
> We should (IMO) align the checksum value with HTTP Entity-Tag (ETag) [1] and, in particular, using a strong validator [2].  RESTCONF says that ETag SHOULD be available for each resource [3], including {+restconf}/ds/ietf-datastores:operational/ietf-yang-library:yang-library.  I know that we don't have to conflate these two things, but it makes sense to do so.
>
> PS: just realized that nmda-restconf didn't update [4]. This might be a problem.
>
> [1] https://tools.ietf.org/html/rfc7232#section-2.3
> [2] https://tools.ietf.org/html/rfc7232#section-2.1
> [3] https://tools.ietf.org/html/rfc8040#section-3.5.2
> [4] https://tools.ietf.org/html/rfc8040#section-3.4.1.2
>
> Kent // contributor
>
>
> -----Original Message-----
> From: Netconf <[e-mail]> on behalf of Vladimir Vassilev <[e-mail]>
> Date: Friday, October 12, 2018 at 6:56 AM
> To: Rohit R Ranade <[e-mail]>, Martin Bjorklund <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> Subject: Re: [Netconf] the name "checksum" in YANG library
>
> Hi,
>
> On 10/12/18 7:59 AM, Rohit R Ranade wrote:
>
>> Hi Martin,
>>
>> " The value of this leaf MUST change whenever the
>>         information in the YANG library changes." ==> This statement in Section 3, indicates that the value must change when content changes.
>>
>> The draft has also placed a constraint that it is a " unique implementation-specific identifier". When the contents changes, especially if the length of the data which is used for checksum changes, then the resulting checksum values may not be unique.
>>
>> So I feel it is simpler, if a counter is used.
> There is this usecase where a client can compare the checksum against
> already retrieved checksum or a list of checksums and know that it is
> connected to a device with schema it was designed to work with or not,
> or has already retrieved the yang library contents and compiled and
> cached the schema in case of smarter client etc. I do not think
> replacing this information with the information how many times the
> schema has changed (since the last restart?, has it changed and returned
> back to the same state?) can serve the same purpose as the checksum even
> if the checksum is calculated with implementation dependent algorithm.
>
> That said it is clear that the presented usecase is dependent on what
> the vendor chose to implement as "checksum" algorithm. How probable it
> is that two different yang libraries generate identical checksums etc.
>
> Vladimir
>
>> With Regards,
>> Rohit
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=QwcIVKILbN6JGJBCGujvoCFYDuKfhlWPRNXIUv76Wt0&s=FtBu4_qYCzP67ExA8TL8cw1qhrLD6goeVAQMgbOvFTg&e=
>