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

[Ivaylo Petrov <[e-mail]>]

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


>
>