Hi Ben, (focusing on the DISCUSS part)
Many thanks for the review. Much appreciated as usual. Please see inline. Cheers, Med > -----Message d'origine----- > De : Benjamin Kaduk via Datatracker [mailto:[email protected]] > Envoyé : jeudi 23 septembre 2021 10:45 > À : The IESG <[email protected]> > Cc : [email protected]; [email protected]; > [email protected]; [email protected]; [email protected] > Objet : Benjamin Kaduk's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: > (with DISCUSS and COMMENT) > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-opsawg-l3sm-l3nm-11: Discuss > > 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/blog/handling-iesg-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-opsawg-l3sm-l3nm/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > (1) I think there may be some ambiguity we need to resolve, relating to > per-AF router IDs and other per-AF lists: > > list router-id { > key "address-family"; > description > "Router-id per address family."; > leaf address-family { > type identityref { > base vpn-common:address-family; > } > description > "Indicates the address family for which the > Router-ID applies."; > > What actually gets used as the router-id for a given address family if > both "dual-stack" and that address family are present in this list? > [[Med]] If the same is used for both, then it is unlikely that the router-id will be included under active-vpn-isntance-profile. I understand that you want to catch corner cases where both are provided. I added this NEW general note in Section 7.1: NEW: Some of the data nodes are keyed by the address-family. For the sake of data representation compactness, It is RECOMMENDED to use the dual-stack address-family for data nodes that have the same value for both IPv4 and IPv6. If, for some reasons, a data node is present for both dual-stack and IPv4 (or IPv6), the value that is indicated under dual-stack takes precedence over the one that is indicated under IPv4 (or IPv6). For the particular case of router-id, the general case is that the value indicated under active-vpn-isntance-profile takes precedence. To make it explicit (and in addition to the NEW text above), I made this change as well: OLD: The structure of 'active- vpn-instance-profiles' is the same as the one discussed in Section 7.4 except 'router-id'. Indeed, Router IDs can be configured per address family. This capability can be used, for example, to configure an IPv6 address as a Router ID when such capability is supported by involved routers. NEW: The value of 'router-id' indicated under 'active-vpn-instance-profiles' takes precedence over the 'router-id' under the 'vpn-node' for the indicated address family. For example, Router IDs can be configured per address family. This capability can be used, for example, to configure an IPv6 address as a Router ID when such capability is supported by involved routers. > There's some similar potential for amiguity in the "redistribute- > connected" list for BGP routing, that is also keyed on an address-family > identityref. [[Med]] I think this is covered by the NEW text above. > > (2) In a similar vein as Roman's Discuss (and perhaps obviated by it?), > if we're going to allow raw keys to be specified, as a string type [[Med]] As already clarified in the reply to Roman, we are just echoing what is supported in the device models (already provided the reference list in that reply). This is meant to ease mapping with these modules. , we > should be very clear about whether the string is hex-encoded, base64- > encoded, etc., in light of deployed experience with devices that take > the string and use it as the raw key (thereby eliminating a good chunk > of the key space from potential use). [[Med]] The keys are in ASCII format for the RIP case, for example. Are you seeking to echo such details in the network model? > > (2.5) For raw keys, should we be using nacm:default-deny-all? [[Med]] This was also a comment raised by Dhruv in the WGLC. But there is no strict rule to follow here. The reason why we didn't in the L3NM is that the corresponding device modules (RIP, IS-IS) does not use it and that manipulating L3NM will require anyway specific right privileges that are handled by NACM model cited in security considerations. > > (3) the ipsec authentication option for the various routing protocols > uses a string to identify an (IKE, unspecified version thereof) SA. RFC > 7296 doesn't have the concept of a name for an IKE SA itself, so I think > we need to provide more details on what is being named and what the > naming authority is. IKE does have identities for the peers, if the > goal is to refer to the peer's identity for the SA. [[Med]] We trusted what was already provided and reviewed in recent RFCs. For example, we are basically echoing what was in RFC9129: leaf sa { type string; description "Name of the Security Association (SA)."; } Note that, for example, RFC9061 indexes the Security Association Database (SAD) by a name: container sad { description "Configuration of the IPsec Security Association Database (SAD)."; reference "RFC 4301: Security Architecture for the Internet Protocol, Section 4.4.2.1."; list sad-entry { key "name"; ordered-by user; leaf name { type string; description "SAD-entry-unique name to identify this entry."; } ... > > (4) I'd also like to have a discussion about the NTP configuration > options; in particular, we currently have an enumeration to select > between broadcast client and broadcast server, with no option apparent > for symmetric or other NTP modes. Given the rigidity of YANG > enumerations, I'd like to confirm that no other NTP modes could be > appropriate on the network access before we lock in to this model. > > [[Med]] We spent many cycles on the NTP case before deciding to integrate it into the module as this is needed for specific VPNs (infrastructure VPNs, as mentioned in the I-D). For these deployments, only the two modes enumerated in the I-D are supported (see, e.g., https://documentation.nokia.com/html/0_add-h-f/93-0076-10-01/7750_SR_OS_Services_Guide/services_con_vprn.html (search for "NTP Within a VPRN Service"). Enumeration seems appropriate to us here. _________________________________________________________________________________________________________________________ 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
