Re-,
Please see inline.
Cheers,
Med
> -----Message d'origine-----
> De : tom petch <daedulus@xxxxxxxxxxxxx>
> Envoyé : mercredi 18 mai 2022 13:24
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx>;
> last-call@xxxxxxxx
> Cc : adrian@xxxxxxxxxxxx; opsawg@xxxxxxxx; opsawg-chairs@xxxxxxxx;
> draft-ietf-opsawg-l2nm@xxxxxxxx
> Objet : Re: Last Call: <draft-ietf-opsawg-l2nm-15.txt> (A YANG
> Network Data Model for Layer 2 VPNs) to Proposed Standard l2vpn-
> ntw
>
> On 13/05/2022 13:36, mohamed.boucadair@xxxxxxxxxx wrote:
> > Tom,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : tom petch <daedulus@xxxxxxxxxxxxx> Envoyé : vendredi 13
> mai 2022
> >> 13:03
> >>
> >> Some stray thoughts on YANG module 'ietf-l2vpn-ntw'
> >>
> >> - In a number of places, the module says 'The default value is
> ...
> >> when used at the service level'. I have two problems with
> this.
> >> I see no 'default' specified in YANG - there could be but there
> is
> >> not; this would appear to be a recommendation not a default.
> >> Other YANG modules have the concept of e.g. global, link, node
> >> parameters with the same grouping appearing in several places
> with a
> >> suitable but different default specified in each place, but not
> here.
> >
> > [Med] We used to have default statements, but we removed them as
> per a fair comment from during the AD review. Please refer to that
> thread with Rob.
> >
>
> Yes, but you should also have removed the mention of default in
> the description because there is no default (and most readers of a
> YANG module will think they know what a default is!).
[Med] This was also discussed in that thread with Rob. We included the default mention in the description on purpose as we can't do it using the default statement. This intent is convey to the implementers which defaults to use as a function of data node hierarchy.
>
> >> Second, the statement is in a grouping, such as parameters-
> profile.
> >> This grouing appears in two 'uses', one under 'global-
> parameters-
> >> profiles' and the other under 'active-global-parameters-
> profiles'.
> >>
> >> How do I marry the reference to 'service level' and whatever is
> the
> >> alternative to 'service level' to a choice of 'active' or
> whatever
> >> the alternative to 'active' is?
>
> Again, I think that there is a lack of big picture. I cannot see,
> in the introductory text, something about values specified at
> global v line v node level, or the equivalent thereof for service
> level and whatever the alternative(s) are. Something for s.7
> perhaps.
[Med] That's already provided in Section 7.4:
"The 'global-parameters-profile' defines reusable parameters for the same L2VPN service instance ('vpn-service'). Global parameters profiles are defined at the VPN service level, activated at the VPN node level, and then an activated VPN profile may be used at the VPN network access level. Each VPN instance profile is identified by 'profile-id'. Some of the data nodes can be adjusted at the VPN node or VPN network access levels. These adjusted values take precedence over the global values. The subtree of 'global-parameters-profile' is depicted in Figure 7."
[snip]
> >>
> >
> > [Med] This was designed to mimic RFC8519. The match will be
> based on the parameters that will be provided. This is similar to
> this part from 8519:
>
> Worth spelling out IMHO, not replicating RFC8519 but referencing
> it
>
[Med] We do already have the following:
"Similar to [RFC8519], an ACL match can be based upon source MAC address, source MAC address mask, destination MAC address, destination MAC address mask, or a combination thereof"
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
