Tom, Please see inline.
Cheers, Med > -----Message d'origine----- > De : tom petch <[email protected]> > Envoyé : vendredi 19 novembre 2021 13:22 > À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; > [email protected]; [email protected] > Objet : Re: I-D Action: draft-ietf-opsawg-l2nm-11.txt > > From: [email protected] <[email protected]> > Sent: 19 November 2021 08:48 > Hi Tom, > > Thank you for checking. Will fix as appropriate. > > <tp> > > > Some additional editorial comments on -11 > > s.8.2 > Appendix C lists the initial values included in the > "iana-bgp-l2-encaps" YANG module. > That is not what I see > [Med] Can you please be more explicit? Thanks. > s.8.4 > list y-1731 { > description "List for y-1731."; > but a list of what? > [Med] Updated to "List of configured Y-1731 instances". > leaf cos { > type uint32; > any constraint on this rather large number? > [Med] We don't have any. Please note that the value can be passed via L2SM (RFC8466) which has that range. > container global-parameters-profiles { > list global-parameters-profile { > uses route-distinguisher; > uses vpn-route-targets; > uses global-parameters-profile; seems an oxymoron; either the > list is global-parameters-profile or the grouping is but as the list is > also RD and RT that seems a contradiction. Also while YANG can cope with > the same identifier in different namespaces, humans might not:-( > [Med] Not sure to get the point. Do you prefer if we use a distinct name for the grouping? > leaf ne-id { > description "Indicates the node's IP address."; > seems to contradict > p.25 'ne-id': Includes a unique identifier of the network > element where > the VPN node is deployed. [Med] Right. This was fixed as part of Adrian's review. We have now: "An identifier of the network element where the VPN node is deployed. This identifier uniquely identifies the network element within an administrative domain." > > case l2tp { > .. leaf router-id { > description > "A 32-bit number in the dotted-quad format that is > used to uniquely identify a node within an > autonomous system (AS). "; the concept of an AS seems > alien in a VPN as is to some extent a node rather the reference seems to > be to PE. RFC4667 has 'establishes the unique identity of each PE' for > router-id. > [Med] As I remember, we were referring to RFC3931..which points to rfc2072#section-8.1. We are using AS in a more general context. Do you have any particular change that would like to see? Thanks. > > leaf push { > type empty; > description > "Standard tag Push. > The number of 802.1Q tags to push on the > front of the frame."; I am puzzled how > empty can be a number [Med] Good catch. The tag to push is indicate din the cvlan-id. Deleted the sentence. > > leaf cvlan-id { > description > "VLAN identifier."; > leaf cvlan-id { > description > "Push/Translate vlan tags"; seems inconsistent [Med] We need this id for push or translate operations. Changed to "Push (or Translate)" > > leaf flow-control { > type string; > description > "Indicates whtehr flow control is ?? > > [Med] > s.11.1 > IEEE, "802.1ag - 2007 - IEEE Standard for Local and The IEEE > website tells me that this is superseded but I cannot see what by [Med] Same here. Thank you > > Tom Petch _________________________________________________________________________________________________________________________ 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. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
