Re: [core] Review of draft-ietf-core-sid-15

Ivaylo Petrov <ivaylo@ackl.io> Mon, 07 June 2021 19:37 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 94E613A0407 for <core@ietfa.amsl.com>; Mon, 7 Jun 2021 12:37:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.288
X-Spam-Level:
X-Spam-Status: No, score=-1.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no 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 RahB3bRTFaBg for <core@ietfa.amsl.com>; Mon, 7 Jun 2021 12:37:50 -0700 (PDT)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 80CF83A03EF for <core@ietf.org>; Mon, 7 Jun 2021 12:37:50 -0700 (PDT)
Received: by mail-wm1-x329.google.com with SMTP id d184so406584wmd.0 for <core@ietf.org>; Mon, 07 Jun 2021 12:37:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SbkYbnhfGtPhb/ve7XsOjOXuSao36DpoStf5shCiYi4=; b=fzUmocB3FPNofgdZJkdpGiwqco/YMT9n++1xHNAvIu0mO1Nmd0HkSgRdQloohqk5ds VqhJvhfrwmeFq0RHwI/3QiM14ofVoK2jUBrg+xmHN+d5KJ2HVtTfAqqs0J5FtJpW/V2G uD1eoLeD/ddNuBTsDTgTIg+WbR/f+SHlaBuC8b13v4QkxBDFOWZ+GFDylHtaA7NRml9M glcQN1HhVb07TjW8bjBMiy+C9lSzCvbHVLDTo+za66ckOmrpeM2mSJJAZTN3SJVx9n40 qy6W94uZ4xJSsroaqS34mhXppLVAaRfVHOqRSGNa0flq0qnZmejL0cMDddhSZ0b3EOW+ M5SA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SbkYbnhfGtPhb/ve7XsOjOXuSao36DpoStf5shCiYi4=; b=bmXMUrksOgfqebFsqNhVKASujMJlgDIzbQICDFygcO3DdBlzMLJ8t5oJ9Q26aB5Ej7 EKiWOALvU/arNfC6Pkb11JxTa5MNgYaGg1l3ahkw/1FTQ/4G9UGOq/GufZuAMIO4hae8 j9qJMCVuinOAUvwvCLA3gUEX3ldSwRu38/ADifGy0q8blD5dB/nhlaGepkNA/353+Lhn +VLYq3WJDEMVRtm3IhQ9a4DZBdLL8yA0YdOrTp7C2KhCLZlTY8ujjRJ0TbaYdw8vjncT S74MtQrr5qg2MYYKsyTR637AASmKsABPupZkkj4ZLeeHFbngR84C3dpvpSsJ2HwfGRgw r0YQ==
X-Gm-Message-State: AOAM532r8/DVDXvJaHhmUAR4EcnF2kE1k/ZaFQjPFDec6XvY3nKb9gqj E7qgVhuUwUAKdJ5Au0p1IVxEBe5/LkSFg1Ahe/dLYA==
X-Google-Smtp-Source: ABdhPJxbNRBBaqA3YZI6h0vIImwNL2iwCZ7AHYuQDf7gC69vF3fW1estGtaJvXnGb2tmPNnOFSqAy11p/XuU5pzGidM=
X-Received: by 2002:a1c:c256:: with SMTP id s83mr18059244wmf.86.1623094667677; Mon, 07 Jun 2021 12:37:47 -0700 (PDT)
MIME-Version: 1.0
References: <B9D828F3-7844-48B7-98AE-D2DCB481F06E@ericsson.com>
In-Reply-To: <B9D828F3-7844-48B7-98AE-D2DCB481F06E@ericsson.com>
From: Ivaylo Petrov <ivaylo@ackl.io>
Date: Mon, 7 Jun 2021 21:37:21 +0200
Message-ID: <CAJFkdRx_OmWtmcaYH47r1KLRrTrOvjJkN4m970Tx5wnxyGE-Ag@mail.gmail.com>
To: Francesca Palombini <francesca.palombini@ericsson.com>
Cc: "barryleiba@computer.org" <barryleiba@computer.org>, "core-chairs@ietf.org" <core-chairs@ietf.org>, "core@ietf.org" <core@ietf.org>, "draft-ietf-core-sid@ietf.org" <draft-ietf-core-sid@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001aa3af05c4322d89"
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/wgkhl2o6CAaoldEsgngkQQnj5gU>
Subject: Re: [core] Review of draft-ietf-core-sid-15
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: Mon, 07 Jun 2021 19:37:56 -0000

Hello Francesca,

Thank you for the review and apologies for the delay! Please find our
answers to your questions below. The diff with -15 is available here
<https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-core-sid-15.txt&url2=https://core-wg.github.io/yang-cbor/draft-ietf-core-sid-latest.txt>
. updated version is available as txt
<https://core-wg.github.io/yang-cbor/draft-ietf-core-sid-latest.txt> and as
html <https://core-wg.github.io/yang-cbor/draft-ietf-core-sid-latest.html>.

Thanks,
Ivaylo

On Wed 24 Feb 2021 at 13:40, Francesca Palombini <
francesca.palombini@ericsson.com> wrote:

> Thanks for the work on this document. I have reviewed it and have some
> comments. Please handle these comments together with the Last Call comments.
>
> Chairs: I believe it would make sense to request a review from YANG
> Doctors for this document. Let me know if you need help setting that up.
>
> Thanks,
> Francesca
>
> ==
>
> Section 1:
>
>    SIDs are assigned permanently, items introduced by a new revision of
>    a YANG module are added to the list of SIDs already assigned.  If the
>    meaning of an item changes, for example as a result from a non-
>    backward compatible update of the YANG module, a new SID should be
>    assigned to it.
>
> should or SHOULD? In general it is not clear to me when it makes sense for
> SID need to be re-registered and when they don't, maybe some examples would
> be useful.
>

IP: I rephrased this to make it more clear:


SIDs are assigned permanently, items introduced by a new revision of a YANG
module are added to the list of SIDs already assigned. If the meaning of an
item changes, for example as a result from a non-backward compatible update
of
the YANG module, a new SID SHOULD be assigned to it. A new SID MUST always
be
assigned if the new meaning of the item is going to be referenced using a
SID.



> ==
>
> Section 3:
>
>    Each time a YANG module or one of its imported module(s) or included
>    sub-module(s) is updated, a new ".sid" file MAY need to be created.
>
> Maybe s/MAY need to/MAY. I assume this is application specific if the new
> .sid file is created or not, so you are leaving it somewhat optional, is
> that correct? Might be good to clarify.


IP: Clarified as

Each time a YANG module or one of its imported module(s) or included

sub-module(s) is updated, a new ".sid" file MAY be created if the new or

updated items will need SIDs.


>
> ==
>
> Section 7: IANA is going to ask where to create the registries. Could this
> be under yang-parameters or does it need a new registry?


IP: That could be discussed, but my understanding was that it's going to be
a new registry.


>
> ==
>
> Section 7.4: Because the policy is expert review, I wonder if a change
> controller field should be added (see RFC 8126)
>
>    When creating a new registry with Expert Review as the registration
>    policy, in addition to the contact person field or reference, the
>    registry should contain a field for change controller.  Having a
>    change controller for each entry for these types of registrations
>    makes authorization of future modifications more clear.


IP: There is the following text

The information associated to the Organization name should not be

publicly visible in the registry, but should be available.  This

information includes contact email and phone number and change

controller email and phone number.


that for me specifies this. The difference from what you suggest is that
this information is not publicly visible in the current text. I believe
this is the expected behaviour, but please let me know if you do not agree.
Note that this has not been raised by the IANA review.



>
> ==
>
> Section 7.5.3 Includes initial entries for the registry that are not
> consistent with the guideline:
>
> +  "Expert Review" [RFC8126] in case the ".sid" file comes from
>             a YANG module from an existing RFC, or
>
> since some of these points are registered from drafts. Should the WG do
> early allocation of those?


IP: Yes, I believe that should be the expected process.


>
> ==
>
> Nits
>
> - expand acronyms on first use ( e.g. NETCONF, RPC, see
> https://www.rfc-editor.org/materials/abbrev.expansion.txt )


IP: Done.


>
>