Hi Authors of draft-ietf-opsawg-teas-common-ac,
Much like the other document in this cluster, here is my review of this
document. While I hope to have some discussion around the COMMENTs in this
review, the NITs are something you can choose whether you want to respond to or
not.
-------------------------------------------------------------------------------
COMMENT
-------------------------------------------------------------------------------
"Abstract", paragraph 0
> Abstract
The shepherd writeup mentions that one of the authors is also author of
draft-ietf-teas-ietf-network-slice-nbi-yang, which is great. My question
however is, was this document vetted in the TEAS WG, and if so what was the
feedback?
The writeup also mentions that the TEAS document has an implementation. Can
this document mention that in its Implementation Report?
Section 4, paragraph 3
> The full tree diagram of the module can be generated using the
> "pyang" tool [PYANG] with "-f tree --tree-print-groupings" command-
> line parameters. That tree is not included here because it is too
> long (Section 3.3 of [RFC8340]). Instead, subtrees are provided for
> the reader's convenience.
>
> The full tree of the "ietf-ac-common" module is available at
> [AC-Common-Tree].
This paragraph needs to be updated to reflect the consensus on "long trees" in
the netmod mailing list, and the complete tree diagram added.
Section 4.2, paragraph 6
> 'bgp-capability': Used to indicate a BGP capability [RFC5492].
> Examples of BGP capabilities are Multiprotocol extensions for
> BGP-4 [RFC4760], route refresh [RFC2918], graceful restart
> [RFC4724], ADD-PATH [RFC7911], or BGP Role [RFC9234]}.
Please use identities in IANA YANG modules defined by draft-ietf-idr-bg-model,
specifically iana-bgp-types.yang, instead of redefining them here.
Section 4.3, paragraph 11
> +-- address-allocation-type? identityref
> +-- (allocation-type)?
> +--:(dynamic)
> +-- (provider-dhcp)?
> | +--:(dhcp-service-type)
> | +-- dhcp-service-type? enumeration
> +-- (dhcp-relay)?
> +--:(customer-dhcp-servers)
> +-- customer-dhcp-servers
> +-- server-ip-address* inet:ipv4-address
Wonder why you need both the leaf 'address-allocation-type' and the choice
'allocation-type' where the latter tells you what is the address allocation
type is?
Section 4.3, paragraph 10
> +-- address-allocation-type? identityref
> +-- (allocation-type)?
Same here.
Section 4.3, paragraph 17
> +--:(explicit)
> +-- key-id? uint32
> +-- key? string
> +-- crypto-algorithm? identityref
Doesn't the keychain model define these parameters? Why model them differently?
Same for the next 3 sets of authentications.
Section 5, paragraph 64
> list qos-profile-identifier {
> key "id";
> description
> "List of QoS profile identifiers.";
> leaf id {
> type string;
> description
> "Identification of the QoS profile to be used.";
> }
> }
Shouldn't the id be a leafref instead of a string?
Section 6, paragraph 0
> This section uses the template described in Section 3.7 of
> [I-D.ietf-netmod-rfc8407bis].
Much like the comment in the other draft, hope this template will be updated
with the text that was recently agreed upon.
Possible DOWNREF from this Standards Track doc to [ISO10589]. If so, the IESG
needs to approve it.
-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.
"OPSAWG", paragraph 1
Section 1, paragraph 4
+ s/specific to a given service or be shared/specific for a given service or
are shared/
Section 1, paragraph 1
> Connectivity services are provided by networks to customers via
> dedicated terminating points (e.g., Service Functions (SFs), Customer
> Premises Equipment (CPEs), Autonomous System Border Routers (ASBRs),
> data centers gateways, or Internet Exchange Points). A connectivity
> service is basically about ensuring data transfer received from (or
> destined to) a given terminating point to (or from) other terminating
> points that belong to the same customer/service, an interconnection
> node, or an ancillary node. A set of objectives for the connectivity
> service may eventually be negotiated and agreed upon between a
> customer a network provider. For that data transfer to take place
> within the provider network, it is assumed that adequate setup is
> provisioned over the links that connect customer terminating points
> and a provider network (a Provider Edge (PE), typically) so that data
> can be successfully exchanged over these links. The required setup
> is referred to in this document as Attachment Circuits (ACs), while
> the underlying link is referred to as "bearer"
s/customer a network provider/customer and a network provider/
Section 1, paragraph 3
> When a customer requests a new value-added service, the service can
> be bound to existing attachment circuits or trigger the instantiation
> of new attachment circuits. Whether these attachment circuits are
> specific to a given service or be shared to deliver a variety of
> services is deployment-specific.
s/specific to a given service or be shared/specific for a given service or are
shared/
Document references draft-ietf-teas-ietf-network-slice-nbi-yang-13, but -16 is
the latest available revision.
Document references draft-ietf-netmod-rfc8407bis-14, but -20 is the latest
available revision.
Document references draft-ietf-opsawg-ntw-attachment-circuit-11, but -13 is the
latest available revision.
Document references draft-ietf-opsawg-teas-attachment-circuit-13, but -17 is
the latest available revision.
Mahesh Jethanandani
mjethanand...@gmail.com
_______________________________________________
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
