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

Ivaylo Petrov <ivaylo@ackl.io> Wed, 26 February 2020 16:13 UTC

Return-Path: <ivaylo@ackl.io>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1763A0997 for <core@ietfa.amsl.com>; Wed, 26 Feb 2020 08:13:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.876
X-Spam-Level:
X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FILL_THIS_FORM_SHORT=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_HTML_ATTACH=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ackl-io.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60IZ7L7AQLXu for <core@ietfa.amsl.com>; Wed, 26 Feb 2020 08:13:10 -0800 (PST)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782233A0A2D for <core@ietf.org>; Wed, 26 Feb 2020 08:12:41 -0800 (PST)
Received: by mail-wm1-x332.google.com with SMTP id z12so3704830wmi.4 for <core@ietf.org>; Wed, 26 Feb 2020 08:12:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=2zyj59T/yO1JhjBSgZiIHEk3MAnpOwFQAH9paC+LTqg=; b=RRa8Fjt1e+7Xft8/oPCcEECo9QAvC5INcPRptyJmM/Unx6lC2qObx4Xc9ZUkyuvIPk liz6dmGuZ8Zs9BUEL+cHsH0gEllbLDRr7BXvPwzqvb6UgPPEH0SG3JFkY/Cm6frLvbJE bP5/c4dvSkaLlRre7vmdxjBjEkUojmcn6KFmHg9xCPTDWdbeUAvQ9fQgE+MNu1BwTvZ0 X+Fxzu4pUSddECkP4zTK6xhbBpBk05OoaodRt5uJ37i22gP5f9gCCvyoPy7/nh9Jrleu G4LdFiWP6w0G9FXDC5tQrSZny9+Iy4NKPmBiXHJhZqHluDCvjFUF2dZ8xSyvNB1w8wXH RqNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=2zyj59T/yO1JhjBSgZiIHEk3MAnpOwFQAH9paC+LTqg=; b=GiQ7yTa49jmji3zlY486fHxgfaW0Zd9pSPCBiK1px7h+u8NNNxI6iC8AHcLIYpZ3wB PDIsGaJqNWt7DyPfOcUDoGgvF1ApmfJqmmylRJWLXHS5K3LVdh2M1QFUPB7ihDRPvpZ+ m3X3HODr89U/NaoKT50uzQs/LFvfSKa9s/QLIYaaEjJyk3dAQ5rlkquvxliGsTjSh6tT M2iR+xC0IFAvkUy1O7N+UpuicegqC/017xTtoq0dQiWGBWZMv3tk7PL87eIPTUzVAKC6 TPFvxLI8XItPQ8e3h8xtGYH8hwOkbgrKgjUs2MHPxNeEhbhhpayd6ZdfRgA1y41WrF9h S+6A==
X-Gm-Message-State: APjAAAVUfTERF/2UEn2v7TvN27v//IkRMr5fCxdatSUhAapEdXxJluyf TB01JW3eSfZL94zz6vhN1He2+l8xeZI=
X-Google-Smtp-Source: APXvYqycxw9adymqwGq6Cifa6GCzPzEgZsSD9fyDway2gVax6ybGIlIOYCJmsH1EiMG0aw8bE5G5xw==
X-Received: by 2002:a1c:a443:: with SMTP id n64mr6011337wme.141.1582733555912; Wed, 26 Feb 2020 08:12:35 -0800 (PST)
Received: from white-fang ([185.122.161.249]) by smtp.gmail.com with ESMTPSA id t10sm3622053wru.59.2020.02.26.08.12.33 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 26 Feb 2020 08:12:33 -0800 (PST)
Date: Wed, 26 Feb 2020 17:12:31 +0100
From: Ivaylo Petrov <ivaylo@ackl.io>
To: Andy Bierman <andy@yumaworks.com>
Cc: core <core@ietf.org>
Message-ID: <20200226161231.otjaqg4vigsb4sim@white-fang>
References: <158151922293.18124.16532089945914076050.idtracker@ietfa.amsl.com> <CAJFkdRxQKDMVEYZgJovEkL-UpsX-ZFQ5CDtFeYJXetr+n5ssNw@mail.gmail.com> <CABCOCHQ9TjH07BgJa1aOEZ6dNZYMUVOqVFNUvOxc3zs8dVZV0w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="turc4kgeatbxhx3k"
Content-Disposition: inline
In-Reply-To: <CABCOCHQ9TjH07BgJa1aOEZ6dNZYMUVOqVFNUvOxc3zs8dVZV0w@mail.gmail.com>
User-Agent: NeoMutt/20171215
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/AGEA7nKCbBeAnN0tAqpzPIinDZM>
Subject: Re: [core] Fwd: New Version Notification for draft-ietf-core-sid-10.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2020 16:13:25 -0000

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:
> 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?
> 

[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}}.

> 
> 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

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

> 
> 
> * 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
> 
>      }
> 
> 

[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.

> * Nit: list names are usually singular (dependencies-revisions,
> 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.

> 
> * 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; }/
> 

[IP]:
Done.

> 
> 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.

[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.

> 
> 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?)

[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.

> 
>   * 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.

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

> 
> 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
> 

[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.

> * 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.
> 

[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).

> 
>  * 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.
> 

[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.

> 
> Appendix A
> 
> The example is rather long (8+ pages).
> 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.

> 
> 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).

[IP]:
Done.

> 
> 
> Andy
> 
> 
> 
> 
> On Wed, Feb 12, 2020 at 7:04 AM Ivaylo Petrov <ivaylo@ackl.io> 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
> >
> >
> > ---------- Forwarded message ---------
> > From: <internet-drafts@ietf.org>
> > Date: Wed, Feb 12, 2020 at 3:53 PM
> > Subject: New Version Notification for draft-ietf-core-sid-10.txt
> > To: Ivaylo Petrov <ivaylo@ackl.io>io>, Alexander Pelov <a@ackl.io>io>, Michel
> > Veillette <michel.veillette@trilliant.com>
> >
> >
> >
> > 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
> >
> > _______________________________________________
> > core mailing list
> > core@ietf.org
> > https://www.ietf.org/mailman/listinfo/core
> >

--
Best regards,
Ivaylo