Re: [CCAMP] Yangdoctors last call review of draft-ietf-ccamp-mw-yang-05

[Jan Lindblad <[e-mail]>]

Yemin,

> Thanks very much for the comments. I found them are quiet useful to improve the models.
> Please see my reply below in blue. 
> The draft co-authors may add more reply to your comments.

Very good. I added some replies marked [janl] below.

> Next, let's look at module ietf-interface-protection.
>  
> I can't say I understand exactly why this is a separate module. It publishes a single grouping, which is required by ietf-microwave-radio-link, and as far as I understand would probably never be used anywhere else. When the grouping is used a single time in ietf-microwave-radio-link, it is immediately refined.
> Would probably reduce the clutter by merging the two modules and resolving the refine.
> [Amy] They were in one model. During the WG discussion, comment was raised that the interface protection function could be generic and be used by other technologies in future, so we split the models.
> I’m open to discuss about this.

[janl] Ok, I didn't quite see how the grouping would be used anywhere else, but if it indeed is usable elsewhere, having it in a separate module isn't a bad idea. 

> #4) Action external-commands
>  
> There is a single action called external-commands (even in plural). It takes a single argument, which is the name of the operation to execute. No output. To me, a more natural modeling would be to make each of the external commands an action, over time possibly with different input and output.
> [Amy] add output to describe the action result (success, fail, inprogress). But prefer to use one action.
> Change the name to external-command.

[janl] Hmm, I don't quite understand your preference for a single action. I see how this choice closes doors, but no real benefit. This is no big deal, though, what you have works. Just feels less evolvable for no reason.

> Many other ways of doing this properly are also possible. Let me know if you'd like to discuss options.
> [Amy] I think choice is a good way to model those leafs. I suggest to use it.  
> That’s the real value of YANG doctors! Thanks.

[janl] ;-)
 
> #10) Choice more convenient
>  
> There are a few leafs that act as discriminators for when clauses in other leafs. Such constructs might be a little smoother when modeled as a choice instead. I'll take one and show as an example. This power-mode construct:
...
>     choice power-mode {
>       container rtpc {
>         description
>           "Remote Transmit Power Control (RTPC).";
>         reference "ETSI EN 302 217-1";
>         leaf maximum-nominal-power {
>           type power {
>             range "-99..40";
>           }
>           units "dBm";
>           mandatory true;
>           description
>             "Selected output power.";
>           reference "ETSI EN 302 217-1";
>         }
>       }
>       container atpc {
>         description
>           "Automatic Transmit Power Control (ATPC).";
>         reference "ETSI EN 302 217-1";
>  
>         leaf maximum-nominal-power {
>           type power {
>             range "-99..40";
>           }
>           units "dBm";
>           mandatory true;
>           description
>              "Selected maximum output power. Minimum output
>              power is the same as the system
>              capability, available-min-output-power.";
>           reference "ETSI EN 302 217-1";
>         }
>  
>         leaf atpc-lower-threshold  {
>           type power {
>             range "-99..-30";
>           }
>           units "dBm";
>           mandatory true;
>           description
>             "The lower threshold for the input power at far-end
>              used in the ATPC mode.";
>           reference "ETSI EN 302 217-1";
>         }
>         leaf atpc-upper-threshold  {
>           type power {
>             range "-99..-30";
>           }
>           units "dBm";
>           mandatory true;
>           description
>             "The upper threshold for the input power at far-end
>              used in the ATPC mode.";
>           reference "ETSI EN 302 217-1";
>         }
>       }
>       mandatory true;
>       description
>         "A choice of Remote Transmit Power Control (RTPC)
>          or Automatic Transmit Power Control (ATPC).";
> }
>  
> [Amy] Choice is a better way. Is it possible to further refine your proposal?
> Since maximum-nominal-power will be used by both RTPC and ATPC, how about to move it out of the choice, then use maximum-nominal-power in the choice?

[janl] Yes, this is certainly very reasonable. I placed the maximum-nominal-power inside the choice because the description string was giving the leaf different interpretations in each case. In that case I felt it better to have separate leaves with clear descriptions. If you feel the leaf can be shared between the options with a clear definition of its meaning, this is reasonable.

Best Regards,
/jan