Subject: Re: [core] New Version Notification for draft-bierman-core-yid-00.txt

From: Michel Veillette <[email-masked]>
Date: Tue, 23 Aug 2016 15:24:34 +0000

Hi Andy

draft-bierman-core-yid-00 propose that only manually assigned YIDs
are maintained in the registry (mapping list or mapping-url). YIDs associated to a
hash are excluded from this registry.

This solution doesn't seem to work if the following design objectives listed in
section 1.2 need to be respected:

1- Persistent Identifiers: It is important that once an identifier is
assigned, that is it never changed in any future revisions in the
module.

1- Module updates need be simple, and only require the latest module
and registry information.

For example, YANG module X is created with:
Data node A associated to YID = hash 1
Data node B associated to YID = hash 2
Data node C associated to YID = hash 3

Than, a new revision is created with:
Data node D associated to YID = hash 2
Data node E associated to YID = hash 4

Is this example, we have a hash clash between data node B and D.
However, the YID assigned to data node B by version 1 is not allowed to change (objective #1).
Only data node D can be rehashed.

Using only the latest module (objection #2) and no entry in the registry, the proper rehash can't be performed.
A simple solution to this problem is to maintain all YIDs in the registry.
A new entry is rehashed only if a clash is detected with an entry already present in the registry.

In summary, the process is the same independently of the algorithm in used (sequential, murmur3 hash, manual).
Each time an YID is assigned, it must be added to the registry.
And new entries are not allowed to collide with entries already present in the registry.

The standard may describe these different algorithms (murmur3 hash, sequential, manual)
but don’t need to mandate one.

Regards,
Michel

From: core [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Tuesday, August 16, 2016 2:39 PM
To: Core <[email-masked]>
Subject: [core] Fwd: New Version Notification for draft-bierman-core-yid-00.txt

FYI,

Peter and I have written a new draft called "Numeric YANG Identifiers"
which replaces the "YANG Hash" draft.

This draft combines hash-based and manual numbering and defines
a simple registry-based process for management of module and object identifiers.

The need for a rehash procedure and rehash errors has been removed.
YANG Hash is now scoped by the module identifier so there are no inter-module
interactions.  Hash collisions within a module are not allowed.
Manual assignments for colliding nodes are used to avoid the rare occurrence
of a hash collision within the same module.

Andy

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Tue, Aug 16, 2016 at 11:29 AM
Subject: New Version Notification for draft-bierman-core-yid-00.txt
To: Peter van der Stok <[email-masked]<mailto:[email-masked]>>, Andy Bierman <[email-masked]<mailto:[email-masked]>>

A new version of I-D, draft-bierman-core-yid-00.txt
has been successfully submitted by Andy Bierman and posted to the
IETF repository.

Name:           draft-bierman-core-yid
Revision:       00
Title:          Numeric YANG Identifiers
Document date:  2016-08-16
Group:          Individual Submission
Pages:          33
URL:            https://www.ietf.org/internet-drafts/draft-bierman-core-yid-00.txt
Status:         https://datatracker.ietf.org/doc/draft-bierman-core-yid/
Htmlized:       https://tools.ietf.org/html/draft-bierman-core-yid-00

Abstract:
   This document describes an encoding of YANG object identifiers using
   numeric values instead of string values.  It combines several
   techniques to provide optimized serialization in protocol messages.

Note

   Discussion and suggestions for improvement are requested, and should
   be sent to [email-masked]<mailto:[email-masked]>.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: Andy Bierman <[email-masked]>
Date: Tue, 23 Aug 2016 09:03:22 -0700

> Only data node D can be rehashed.

So the manual entry will be for D, not B. not a problem.

> the proper rehash can't be performed.

Agreed. You do need the current registry entry to create
an update to that entry.

> A new entry is rehashed only if a clash is detected with an entry already

Agreed.
This also makes SID registry maintenance simple.
(Number only the nodes not already present in version N to produce N+1).

No matter how the YANG module can possibly be changed over time,
the path identifiers remain the same from version to version,
and therefore the hashes remain the same.

> (sequential, murmur3 hash, manual).

yes

Andy

> *From:* core [mailto:[email-masked]] *On Behalf Of *Andy Bierman
> *Sent:* Tuesday, August 16, 2016 2:39 PM
> *To:* Core <[email-masked]>
> *Subject:* [core] Fwd: New Version Notification for
> draft-bierman-core-yid-00.txt
>
>
>
> FYI,
>
>
>
>
>
> From: <[email-masked]>
> To: Peter van der Stok <[email-masked]>, Andy Bierman <
> [email-masked]>
>
>
>
>    be sent to [email-masked].
>
>
>
>
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>