[Teas] Re: Gunter Van de Velde's Abstain on draft-ietf-teas-actn-vn-yang-27: (with COMMENT)

[Dhruv Dhody <[e-mail]>]

Hi Gunter,

On Mon, Jun 10, 2024 at 9:47 AM Gunter van de Velde (Nokia) <
[e-mail]> wrote:

> Thanks Drhuv,
>
>
>
> Was there a reason ‘vn-ap-id’ is not simplified into ‘ap-id’? The
> specified node is already part of the list ‘vn-member-list’ using ‘id’ as
> the key? Hence not sure if we need the ‘vn-‘
>
> I’ll set my ballot to NoObj as the key observations that cause me to
> object have been addressed.
>
>
>

Dhruv: We have 2 concepts and respective identifiers here
AP/ap-id: /ietf-vn/access-point/ap/id
VNAP/vn-ap-id: /ietf-vn/access-point/ap/vn-ap/id

Inside vn-member, vn-ap-id refers to VNAP -

        +--rw vn-member* [id]
        |  +--rw id                        vnm-id
        |  +--rw src
        |  |  +--rw ap?          -> /access-point/ap/id
        |  |  +--rw vn-ap-id?
        |  |  |       -> /access-point/ap[id=current()/../ap]/vn-ap/id



Using ap-id (instead of vn-ap-id) would be very confusing!

Thanks for removing the abstain ballot.

Thanks!
Dhruv



> G/
>
>
>
>
>
> *From:* Dhruv Dhody <[e-mail]>
> *Sent:* Saturday, June 8, 2024 11:37 AM
> *To:* Gunter van de Velde (Nokia) <[e-mail]>
> *Cc:* The IESG <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> *Subject:* Re: Gunter Van de Velde's Abstain on
> draft-ietf-teas-actn-vn-yang-27: (with COMMENT)
>
>
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext for
> additional information.
>
>
>
> Hi Gunter,
>
>
>
> On Sat, Jun 8, 2024 at 9:10 AM Gunter Van de Velde via Datatracker <
> [e-mail]> wrote:
>
> Gunter Van de Velde has entered the following ballot position for
> draft-ietf-teas-actn-vn-yang-27: Abstain
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-teas-actn-vn-yang/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> # Gunter Van de Velde, RTG AD, comments for draft-ietf-teas-actn-vn-yang-27
>
> Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/
> documenting the handling of ballots.
>
> Many thanks for the RTG-DIR reviews from Darren Dukes and many thanks to
> Vishnu
> Pavan Beeram for the Shepherd write-up.
>
> Please find below one non-blocking ABSTAIN regarding the YANG node names
> used.
> While this should be relatively straightforward to address, it will involve
> quite a bit of effort to correct the node names throughout all instances.
>
> #ABSTAIN items
> #=============
> ##(resolved) ABSTAIN1
> One of the motivations to use YANG is to have human readable structure to
> understand config and state of a device. When looking through the document
> i
> see many very abbreviated acronyms. e.g. vn, vn-id, src, src-vn-ap.id, etc
>
> Agreed with Dhruv (author): abbreviations will be expanded upon in
> descriptions
> as the abbreviations used are well known in TEAS area.
>
>
>
> Dhruv: Ack. Updated in the new revision.
>
>
>
>
>
> ##ABSTAIN2
> Using full/fragments of parent-node names in sibling-node names is
> something
> that netmod has recommendations against.
>
> Reference:
>
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis-20#section-4.3.1
>
> “
>    Identifiers SHOULD include complete words and/or well-known acronyms
>    or abbreviations.  Child nodes within a container or list SHOULD NOT
>    replicate the parent identifier.  YANG identifiers are hierarchical
>    and are only meant to be unique within the the set of sibling nodes
>    defined in the same module namespace.
>
>    It is permissible to use common identifiers such as "name" or "id" in
>    data definition statements, especially if these data nodes share a
>    common data type.
> “
>
>
>
> Dhruv: I have made this change in the new revision -28.
>
> See
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-teas-actn-vn-yang-27&url2=draft-ietf-teas-actn-vn-yang-28&difftype=--html
>
>
>
>
>
> Note: Originally these were blocking DISCUSS, however using non-recommended
> yang node names, is not one of the agreed reasons to have a discuss
>
> https://datatracker.ietf.org/doc/statement-iesg-discuss-criteria-in-iesg-review-20140507/
>
> The yang tree documented can be implemented and will interop. Hence i
> moved the
> original blocking DISCUSS to a non-blocking ABSTAIN position with following
> meaning: "I oppose this document but understand that others differ and am
> not
> going to stand in the way of the others."
>
>
>
> Dhruv: I understand.
>
>
>
> Thanks!
>
> Dhruv
>
>
>
>
>