Subject: [core] Fwd: New Version Notification for draft-ietf-core-sid-10.txt

From: Ivaylo Petrov <[email-masked]>
Date: Wed, 12 Feb 2020 16:03:19 +0100

Dear all,

In the latest version I believe we have addressed Andy's comments regarding
.sid file versioning. I consider this to be the last comment that was still
pending before we can go for a working group last call for the sid draft
and the cluster of drafts known as CORECONF in general. Please let us know
if there are still points that you consider should be handled before the
WGLC. In the absence of further comments, I would like to ask the working
group chairs to consider going for a last call.

Thank you in advance!

Best regards,
Ivaylo

---------- Forwarded message ---------
From: <[email-masked]>
Date: Wed, Feb 12, 2020 at 3:53 PM
Subject: New Version Notification for draft-ietf-core-sid-10.txt
To: Ivaylo Petrov <[email-masked]>, Alexander Pelov <[email-masked]>, Michel
Veillette <[email-masked]>

A new version of I-D, draft-ietf-core-sid-10.txt
has been successfully submitted by Ivaylo Petrov and posted to the
IETF repository.

Name:           draft-ietf-core-sid
Revision:       10
Title:          YANG Schema Item iDentifier (SID)
Document date:  2020-02-12
Group:          core
Pages:          33
URL:
https://www.ietf.org/internet-drafts/draft-ietf-core-sid-10.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-core-sid/
Htmlized:       https://tools.ietf.org/html/draft-ietf-core-sid-10
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-core-sid
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-core-sid-10

Abstract:
   YANG Schema Item iDentifiers (SID) are globally unique 63-bit
   unsigned integers used to identify YANG items.  This document defines
   the semantics, the registration, and assignment processes of SIDs.
   To enable the implementation of these processes, this document also
   defines a file format used to persist and publish assigned SIDs.

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.

The IETF Secretariat

---

From: Andy Bierman <[email-masked]>
Date: Mon, 17 Feb 2020 10:05:18 -0800

Hi,

Here are my comments on draft-ietf-core-sid-10:

sec 1:

      YANG modules, submodules and features

* Should it be noted somewhere that these  3 constructs are numbered
for YANG library

  purposes and are not used in protocol messages like the other
constructs listed?

sec 4:

* The intro should contain a YANG Tree Diagram [RFC 8340]

module: ietf-sid-file
  +--rw module-name?              yang:yang-identifier
  +--rw module-revision?          revision-identifier
  +--rw sid-file-version?         sid-file-version-identifier
  +--rw dependencies-revisions* [module-name]
  |  +--rw module-name        yang:yang-identifier
  |  +--rw module-revision    revision-identifier
  +--rw assigment-ranges* [entry-point]
  |  +--rw entry-point    sid
  |  +--rw size           uint64
  +--rw items* [namespace identifier]
     +--rw namespace     enumeration
     +--rw identifier    union
     +--rw sid           sid

* The SID file construct needs a wrapper container instead of 6
to-level data nodes.

  A yang-data extension (from ietf-restconf.yang in RFC 8040) should be used.

  There is an update to rc:yang-data, but it is not published yet.

     rc:yang-data sid-file {

         // all 6 fields defined here

     }

* The IETF Trust Copyright is for 2016. There is probably a new template.

* Nit: list names are usually singular (dependencies-revisions,
assignment-ranges, items)

* The description-stmt for assignment-ranges should be expanded:

  - specify that the SID range for each entry is SID entry-point to
entry-point + (size - 1)

  - the SID ranges specified by all assignment-rages MUST NOT overlap

* The type for /assignment-ranges/size should not allow zero-length
ranges.  s/uint64/uint64 { range 1..max; }/

sec 6.3.2 Allocation Policy

* the range 1000 to 59,999 is rather small for the pool of all YANG modules
published in RFCs.
  Likewise, 40K for all experimental numbers seems really small. The SID
range is uint64

* Not sure these characterizations of small, medium, large are helpful.
Also max allocation of 1000
  seems rather arbitrary.  Better to say requestors need to justify the
size of each request.

sec 6.4.2 Allocation Policy

   SIDs never change

  * The IETF has shown very little ability to get all the names and module
structure correct on the first try.
     Or the first 15 tries.  Modules get refactored and names get changed
-- a lot.  This statement is unclear.
     (SID 42 is always SID 42? Or do you mean SID assignments never change?)

  * This section should say that reassignment of SIDs within an allocated
SID range MAY change during
     YANG module development. next section has text about this issue.

6.4.3

 * Should an early allocation be given if the adopted module imports
unadopted modules?
   This seems to force the WG to adopt or not use the allocated SID range

* Not sure how to fix the following  sentence, but maybe just remove it
since it is unclear

   Critically, the original document should never get through the IETF
   process and then be surprised to be referencing a document whose
   progress is not certain.

 * Not sure what "expired" means. It means they are burned and never
reallocated right?

 It would punish early adopters to do otherwise.

   Early Allocations are made with a one-year period, after which they
   are expired.

Appendix A

The example is rather long (8+ pages).
Do not have a suggestion for a shorter module though

Appendix B

It should be stated that SID generation for RPC or action "input" and
"output" schema nodes
should always be done, even if no parameters are defined in the original
RPC or action.
Another module can augment these nodes (but cannot add "input" or "output"
with augment).

Andy

On Wed, Feb 12, 2020 at 7:04 AM Ivaylo Petrov <[email-masked]> wrote:

> Dear all,
>
> In the latest version I believe we have addressed Andy's comments
> regarding .sid file versioning. I consider this to be the last comment that
> was still pending before we can go for a working group last call for the
> sid draft and the cluster of drafts known as CORECONF in general. Please
> let us know if there are still points that you consider should be handled
> before the WGLC. In the absence of further comments, I would like to ask
> the working group chairs to consider going for a last call.
>
> Thank you in advance!
>
> Best regards,
> Ivaylo
>
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Ivaylo Petrov <[email-masked]>
Date: Wed, 26 Feb 2020 17:12:31 +0100

Hi Andy,

Sorry for the slight delay. Please find my answers below.

I am adding as attachments txt and html version of the text with the
proposed changes.

On Mon, Feb 17, 2020 at 10:05:18AM -0800, Andy Bierman wrote:
> for YANG library purposes and are not used in protocol messages like
> the other constructs listed?
> 

[IP]:
I can see how this information would avoid some people wondering why
those items really need SID assignment. It seems to me that we were
aiming at a specification that is very loosely coupled with the CoMI and
YANG library purposes. Therefore, I could agree that we can give them as
examples for the different uses - say that data node SIDs for example are
used in CoMI and module, submodule and features SIDs are used in YANG
library. 

I could for example imagine to have the following text right after the
text that you cited.

    It is possible that some protocols use only a subset of the assigned SIDs, for
    example, for protocols equivalent to NETCONF {{RFC6241}} like {{-comi}} the
    transportation of YANG modules SIDs might be unnecessary. Others protocols
    might need to be able to transport this information, for example protocols
    related to discovery such as Constrained YANG Module Library {{-yang-library}}.

>      +--rw namespace     enumeration

[IP]:
Thanks for pointing this out! It is updated now.

>          // all 6 fields defined here

[IP]:
That makes sense, thank you for bringing our attention to this!

> * The IETF Trust Copyright is for 2016. There is probably a new template.

[IP]:
If I recall correctly, I checked one of the YANG file validation tool that was
printing a warning and added the Copyright statement based on that, replacing
the year with the first version when the YANG module was published. Could you
tell me how to find the latest template and if I should instead put 2020
instead of 2016.

> assignment-ranges, items)

[IP]:
Unless someone objects because of the possible breaking of some already
existing .sid files, I will modify the assignment-ranges and items
lists. In any case I will rename dependencies-revisions to comply with
this best practice.

> ranges.  s/uint64/uint64 { range 1..max; }/

[IP]:
Done.

>   seems rather arbitrary.  Better to say requestors need to justify the

[IP]:
I will contact Alexander about that part as I don't have enough context
to judge why those exact values were selected and what was the reason
behind him proposing the use of on small, medium and large sizes.

>      (SID 42 is always SID 42? Or do you mean SID assignments never change?)

[IP]:
The intended meaning was that the assignment never changes.  As I
believe that this section should be focused solely on the Allocation
Policy and as I believe the previous three points make it clear that
Experts should check that the meaning of a SID number does not change, I
consider this can be entirely removed.

>      YANG module development. next section has text about this issue.

[IP]:
I believe this is handled by my previous comment.

>    This seems to force the WG to adopt or not use the allocated SID range

[IP]:
While for me this case is unlikely, my view on this is that if the
working group chairs consider it acceptable to depend on a module that
is defined in a draft that is still not adopted and they can convince
the responsible AD to sponsor that document, that is fine. Let me know
if you think that the text around this is not clear enough:

    A YANG module which references a module in an document which has not yet been
    adopted by any working group will be unable to perform an Early Allocation
    for that other document until it is adopted by a working group.  As described
    in {{-BCP100}}, an AD Sponsored document acts as if it had a working group.  The
    approving AD may also exempt a document from this policy by agreeing to AD
    Sponsor the document.

>    process and then be surprised to be referencing a document whose

[IP]:
I can see how this text can be difficult to understand unambiguously.
How about rephrasing it like:

    At the end of the IETF process all the dependencies of a given module for which
    SIDs are assigned, should also have SIDs assigned. Those dependencies'
    assignments should be permanent (not Early Allocation).

>    Early Allocations are made with a one-year period, after which they

[IP]:
My understanding is that after the early allocation period is over, if
it is not extended, the SIDs will be available for re-allocation. Note
that while this could in theory lead to confusion about the meaning of a
number of SIDs, this expectation is clearly outlined for me and it is
acceptable. As always, Early Adopters should consider the possible risks
and benefits.

> Do not have a suggestion for a shorter module though

[IP]:
I agree that it is rather long. For the time being we will I think we
will keep it as it is and we will try to think about a shorter example
in the future.

> Another module can augment these nodes (but cannot add "input" or "output"

[IP]:
Done.

--
Best regards,
Ivaylo