Hi Wes,
Thank you for the review.
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Wesley Eddy via Datatracker [mailto:nore...@ietf.org]
> Envoyé : mercredi 31 mars 2021 01:51
> À : tsv-...@ietf.org
> Cc : draft-ietf-opsawg-vpn-common@ietf.org; last-c...@ietf.org;
> opsawg@ietf.org
> 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-...@ietf.org 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-bandwidthuint64
+--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.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
