Re: [MBONED] draft-ietf-mboned-multicast-yang-model-04: partial review

["Holland, Jake" <[e-mail]>]

Hi Sandy,

Thanks for the response, and I'm glad the review was helpful.  Thanks
also for the updated links for the Open Daylight project.

You asked a question and had one response I'm still confused about,
so I'm cutting to respond just to those:

From: "[e-mail]" <[e-mail]>
> Date: Sat,2021-05-08 at 12:57 AM
>
> 8.
> In the model:
> I don't understand the "module-loaded" and "module-unloaded" options
> in the head-end-event notification.  It sounds like these are
> referring to a change in the RESTCONF/NETCONF server, rather than a
> change in the head-end?  Or I don't understand what this is saying,
> or what a client might do in response to this.
>           enum module-loaded {
>             description
>               "The new modules that can be used by multicast
>                flows have been loaded.";
>           }
>           enum module-unloaded {
>             description
>               "The new modules that can be used by multicast
>                flows have been unloaded.";
>           }
> Sandy> In some device, the protocol is also called a module. But I think you are right, the description may lead to confusion. 
> Do you think it's better: protocol-enabled and protocol-disabled? 

Ah, I get it now.  Yes, I think protocol-enabled and protocol-disabled
does sound better to me, thanks.

> 9.
> In the model:
> I'm confused about the transport-pim grouping that's empty.  Is
> the point of that to have something that can be augmented?  Is
> there an example of augmentations that are used here?
> Sandy> Because this model works together with other protocols model, PIM YANG can also be used. If there is some parameters need to be set, it should be set in PIM YANG model.
>
> This is an extension point?  If so, would it be reasonable to
> add any guidance explaining when it would be useful or necessary
> to use it?
> Sandy> I used boolean type for it, when it was set to 1 mean that this leaf is used. 
> But when this model was review by YANG doctors, they said it's more better to use the current way.
>
> 10.
> Same thing for the several empty cases in overlay-tech and
> underlay-tech.
>
> Would it make sense to define an identity like
> "underlay-technology-identity" and use that as a base for a
> type that would appear in the data instance?  The way it stands
> now, I'm not sure I see how it would distinguish between an
> underlay-tech that's bgp vs. isis, since both are empty, so the
> underlay-tech container would just be empty in both cases.
> Sandy> Please find my answer in 9. 

I took a look at the YANG doctor review from Mahesh and the email
thread it references to see if I could better understand their
suggestion as you mentioned in the response to #9:
https://mailarchive.ietf.org/arch/msg/yang-doctors/dv_-0qZ6mpkNmA4_ArRvczagYLI/
https://mailarchive.ietf.org/arch/msg/yang-doctors/Kw2o-kLv4MnGsiGgHHgZcKeakYY/

Is that the review you meant?

I saw one comment from Mahesh that looked to me like a very similar
question to what I thought I was asking:

(From Mahesh):
"Secondly, it is not clear what the purpose of empty containers is in the YANG model. For example, container bgp has no attributes. Is this an augmentation point or a mount point? If so, who is expected to augment or use as a mount point for the container? The draft gives no guidelines on how the container is expected to be used. Again, an example would have helped. If they are meant to be an indication what the routing protocol for the underlay is, why do you need a container? A boolean leaf should have sufficed. As defined, one can have multiple routing protocols defined for a given underlay. Was this the intent?"

I hope the examples will clarify this some, but even if the
presence of the "pim" container in the "transport-tech" grouping
is used as a selector for whether pim is in use, I don't understand
what the empty "transport-pim" grouping is for, or how extensions
are expected to use it.

I'll also say that my reading of Mahesh's comment is suggesting that
a boolean leaf would be a better choice than an empty container, if
the point is to just indicate presence or non-presence, which seems
backwards from what I thought you were saying?  Maybe I'm confused
about which review you meant?

Anyway, I think the examples with explanations of how the controller
will behave with the examples might be the right next step.  Right
now I feel like I might have an understanding gap on what the intent
is here, so I'm not sure any suggestions on the structure I can make
will make good sense.

Thanks and regards,
Jake