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

[Michel Veillette <[e-mail]>]

Comment [MV] inline

From: Andy Bierman [mailto:[e-mail]]
Sent: Monday, August 22, 2016 5:17 PM
To: Michel Veillette <[e-mail]>
Cc: Core <[e-mail]>
Subject: Re: [core] Fwd: New Version Notification for draft-bierman-core-yid-00.txt



On Mon, Aug 22, 2016 at 2:01 PM, Michel Veillette <[e-mail]<mailto:[e-mail]>> wrote:
Hi Andy
I see two fundamental differences between the SID and the YID drafts.
 1) The name
YID is harder to pronounce, but seem to be technically better.
These IDs are not really structured, they are in fact arbitrary if we allocate them by range(s).
But we shall use them only for YANG items if we want to keep them compact.
2) Allocation per range or per prefix
Last winter, we moved from an allocation per prefix (20 bits, 10 bits) to an allocation per range(s).

I realize that if I ask for a range of 64K, then why should the registry care
if I use it for manual numbering or hashing. I think module-ids
are easier to manage though.  YID proposes that a module-id be added
to the YANG Module Registry and IANA will assign the module-id.
This is how it works for the SNMP OID root for a MIB module,
which is essentially the same thing.

[MV] In SNMP, a single OID is typically registered for multiple modules.
[MV] Developers assign different arcs of this registered OID to different SNMP objects.
[MV] We propose to do the same with SID ranges, developers can allocate multiple subranges from its registered range.

IMO modules should fit into 1 range, if ranges are used.

[MV] This will be effectively the case in most cases.
[MV] However, the protocol shall not break if the number of YANG items exceed the initial range allocated.
We did this change for the following reasons:
- Starvation of IDs.
The size of the range can be adjusted based on the estimated number of items for each particular YANG module.
And extra range(s) can be added if needed.
I think the YID registry can be scaled down as needed.
e.g., the server "knows" no module it supports has more than 256 objects so
the "local-bits" can be scaled down from 16 bits to 8 bits.

[MV] The "module-bits" is a global property of the registry and can't be adjusted per module.
[MV] Once set, it can't be increased to support a YANG module with more YANG items and
[MV] can't be decreased to support efficiently a YANG module with very few YANG items.

- Efficiency
An allocation based on a fixed number of bits become very inefficient, especially if want or minimize the ricks of starvation and to support multiple tiers of registration (IANA, SDO/registrars, Developers, YANG modules).

These reasons are still valid and I hope you appreciate the advantages of using ranges.

==================

I also want to clarify a couple of items discussed on the malling list.

1) [I-D.somaraju-core-sid] don't mandate any specific algorithm to perform the allocation of IDs to YANG items.
Using a hash to perform this allocation is perfectly valid and the text should be modified to mention the possible use of a hash or any other algorithms.

2) manual / sequential numbering
[I-D.bierman-core-yid] associate the term "manual" to sequential numbering.
Since  [I-D.somaraju-core-sid] recommend the use an automated process to perform SIDs allocation, we should avoid the use of "manual" to qualify sequential numbering.

No -- I mean manual.
What if I want to leave some gaps in the numbering for future growth?
Since the number of CBOR bytes is 1 whether the delta is 1 or 23,
I can leave padding in the number space without any penalty in the protocol.
Sequential numbering gets very non-sequential (the more so with every new module revision).

[MV] If so, we still need to support non hash based ID generated automatically.
[MV] We just need to find a term which cover both cases (manually or automatically assigned ID).


==================
As a last comment, [I-D.bierman-core-yid] contain a lot of very good description text which should be preserved during the merging process.
Regards,
Michel Veillette

Andy


From: core [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Andy Bierman
Sent: Tuesday, August 16, 2016 2:39 PM
To: Core <[e-mail]<mailto:[e-mail]>>
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: <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>>, Andy Bierman <[e-mail]<mailto:[e-mail]>>



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 [e-mail]<mailto:[e-mail]>.




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