Hi Wes, Thank you for the review. Please see inline. Cheers, Med > -----Message d'origine----- > De : Wesley Eddy via Datatracker [mailto:noreply@xxxxxxxx] > Envoyé : mercredi 31 mars 2021 01:51 > À : tsv-art@xxxxxxxx > Cc : draft-ietf-opsawg-vpn-common.all@xxxxxxxx; last-call@xxxxxxxx; > opsawg@xxxxxxxx > Objet : Tsvart last call review of draft-ietf-opsawg-vpn-common-06 > > Reviewer: Wesley Eddy > Review result: Almost Ready > > This document has been reviewed as part of the transport area review > team's ongoing effort to review key IETF documents. These comments > were written primarily for the transport area directors, but are > copied to the document's authors and WG to allow them to address any > issues raised and also to the IETF discussion list for information. > > When done at the time of IETF Last Call, the authors should consider > this review as part of the last-call comments they receive. Please > always CC tsv-art@xxxxxxxx if you reply to or forward this review. > > (1) I noticed in the "qos-classification-policy" there is "l4" > support either TCP or UDP. It isn't clear if other transport > protocols are purposefully not included. [Med] We wanted to focus in this version of the spec on transport protocols that are widely supported in the context of VPN services. The module can be extended in the future with l4-specific features, if needed. We will clarify that scope in the document. Should this also support > SCTP and/or DCCP, or other transport protocol numbers in general? [Med] Any transport protocol (including DCCP, SCTP) can be included in: | | | | +-- protocol? uint8 Additional transport-specific parameters can be included as part of the l4, but only tcp and udp branches are listed in this version. Future augmentation of the module can for example specify DCCP or SCTP if there is such need. See for example what we did in https://tools.ietf.org/html/draft-ietf-tsvwg-natsupp-22#section-7 vs. RFC8512. > Are the QUIC aspects that might be matched contained within the UDP > fields supported? [Med] There is at least UDP ports that can be used for a specific QUIC application binding (HTTP). Relying on some of the information that is visible in the public header (connection-id, for example) may not be reliable. > > (2) Is the allowable MTU another aspect of VPN services that should > be able to be expressed? [Med] Good point. This is actually covered in modules that use the vpn-common, see for example: draft-ietf-opsawg-l3sm-l3nm: +--rw vpn-network-accesses +--rw vpn-network-access* [id] ... +--rw service +--rw input-bandwidth uint64 +--rw output-bandwidth uint64 +--rw mtu uint16 > > (3) ICMP isn't mentioned as an identity type, and I wondered if this > should be. [Med] We don't define it here as it was not used in modules that uses this one (e.g., draft-ietf-opsawg-l3sm-l3nm). Thanks. _________________________________________________________________________________________________________________________ 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
