Chiming in as author of draft-ietf-tcpm-yang-tcp ... > -----Original Message----- > From: OPSAWG <opsawg-boun...@ietf.org> On Behalf Of > mohamed.boucad...@orange.com > Sent: Monday, September 20, 2021 9:03 AM > To: Martin Duke <martin.h.d...@gmail.com>; The IESG <i...@ietf.org> > Cc: draft-ietf-opsawg-l3sm-l...@ietf.org; opsawg@ietf.org; opsawg- > cha...@ietf.org > Subject: Re: [OPSAWG] Martin Duke's Discuss on draft-ietf-opsawg-l3sm- > l3nm-11: (with DISCUSS) > > Hi Martin, > > Thank you for the review. > > I'm very familiar with draft-ietf-tcpm-yang-tcp (as you can see in the ACK > section of that document). > > The structure in draft-ietf-opsawg-l3sm-l3nm follows the one in draft-ietf- > idr-bgp-model: > > draft-ietf-opsawg-l3sm-l3nm > > | | | +--rw (option)? > | | | +--:(tcp-ao) > | | | | +--rw enable-tcp-ao? boolean > | | | | +--rw ao-keychain? key-chain:key-chain-ref > > > draft-ietf-idr-bgp-model > > | | | +--rw (option)? > | | | +--:(ao) > | | | | +--rw enable-ao? boolean > | | | | +--rw send-id? uint8 > | | | | +--rw recv-id? uint8 > | | | | +--rw include-tcp-options? boolean > | | | | +--rw accept-ao-mismatch? boolean > | | | | +--rw ao-keychain? > | | | | key-chain:key-chain-ref > > We are not echoing the full structure because the L3NM is a network model, > not a device model. A network model does not aim to control every > parameter that can be manipulated at the device level. Other than > enabling/disabling TCP-AP and providing the ao-keychain, we didn't identify a > need to control and customize at the network service level the data nodes in > draft-ietf-tcpm-yang-tcp: > > | | | | +--rw send-id? uint8 > | | | | +--rw recv-id? uint8 > | | | | +--rw include-tcp-options? boolean > | | | | +--rw accept-ao-mismatch? boolean > > These optional nodes can be part of a local profile that can be directly > manipulated at the device module (draft-ietf-idr-bgp-model).
It is always an interesting (and pretty fundamental) question what device parameters can indeed be abstracted in a network model. My personal (well, somewhat dated) experience is that different operators have very different preferences what parameters to include in a network model. Careful reasoning may be required for any omission of a device parameter. In this specific case, I don't fully understand how VPN provisioning via the network level model would pick the values for "send-id" and "recv-id"? Those parameters need to be configured consistently on both endpoints of the TCP-AO connection, right? What happens if the network model draft-ietf-opsawg-l3sm-l3nm only configures one of the two TCP-AO endpoints? So, why can "send-id" and "recv-id" be removed? > We can make these changes, though: > > s/tcp-ao/ao > s/enable-tcp-ao/enable-ao It certainly makes sense to use at least consistent naming in different IETF models, but unless there is a good reason to remove "send-id" and "recv-id", you could just directly import the grouping to ensure consistency... Michael > > Cheers, > Med > > > -----Message d'origine----- > > De : Martin Duke via Datatracker [mailto:nore...@ietf.org] > > Envoyé : dimanche 19 septembre 2021 19:55 > > À : The IESG <i...@ietf.org> > > Cc : draft-ietf-opsawg-l3sm-l...@ietf.org; opsawg-cha...@ietf.org; > > opsawg@ietf.org; adr...@olddog.co.uk; adr...@olddog.co.uk > > Objet : Martin Duke's Discuss on draft-ietf-opsawg-l3sm-l3nm-11: (with > > DISCUSS) > > > > Martin Duke 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/iesg/statement/discuss- > > criteria.html > > for more information about 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: > > ---------------------------------------------------------------------- > > > > (7.6.3) Is there a reason the TCP-AO model in this draft is different > > from the one in draft-ietf-idr-bgp-model-11? That draft is using a model > > developed in the TCPM WG (draft-ietf-tcpm-yang-tcp) specifically for > > that purpose. > > > > If there is no compelling requirement for something different, or the > > TCPM modelling work can be stretched to cover this use case as well, it > > would be far better than rolling a totally separate TCP YANG model 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 > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
