Dear all,
Warren asked me to review this document part of the AD review.
I know we're in last call right now: Whether the comments are part of AD
review or IETF LC comment doesn't matter at this point in time.
Here is my feedback.
Figure 3: Network configuration model is a brand new term that is only
mentioned in the figure, and not explained.
In the same figure, could the "Device Configuration Model" be renamed to RFC 8199
"Network Element YANG module"
(this is what you did in figure 4 anyway)
- section 6.2 "service delivery and network element model work"
Some
of these models are classified as service delivery models, while
others have details that are related to specific element
configuration and so are classed as network element models (also
called device models).
Next to each model description, that would help the audience to clarify what
the correct term is: customer service model, service delivery model, network
service YANG modules [RFC8199]
- In RFC 8199, we made a distinction between model and YANG modules. This is why we defined the
terms "Network Service YANG_modules_" and "Network Element YANG_modules_" and
not models.
You should follow this convention. After all, from the abstract, this document
focuses on YANG.
Ex: should "model" be replaced by "YANG module"?
- section 6.4 "The MEF architecture".
Do we want to mention that MEF currently focuses on the customer service model?
- I'm glad you cleverly avoided the term "intend"
Regards, Benoit
Apologies, I forgot to CC the WG.
I'll also be asking Benoit to give it the once over, as he is much
more familiar with this topic.
W
---------- Forwarded message ----------
From: Warren Kumari <[email protected]>
Date: Mon, Sep 4, 2017 at 8:43 PM
Subject: AD Review of draft-ietf-opsawg-service-model-explained
To: [email protected]
Hi there,
First off, thanks for a really well written document -- this is one of
the cleanest AD reviews I've done.
I do have some very minor grammar nits.
I'd prefer a new version with these addressed, but they are all
sufficiently minor that I'm also OK starting the LC as is. Please let
me know which you'd prefer.
1: While unfortunate, I think many will not understand the q.v. in the
Service definition in Section 2. Terms and Concepts. Perhaps break it
out, or more clearly point where more info is to be found.
2: Section 6.3. Customer Service Model Work
"The most advanced presents the L3VPN service..." - I'd suggest
"Currently the most advanced presents the L3VPN service..." -- there
may be another, more advanced one soon...
The reset of the nits are in [O]riginal, [P]roposed, [R]emark / Reason
/ Rational / <something else that starts with R> format.
Section Abstract
This document describes service models as used within the IETF, and
[O] IETF, and
[P] IETF and
[R] grammar
Section 1. Introduction.
Within the context of Software Defined Networking (SDN) [RFC7149]
[RFC7426] YANG data models may be used on the interface between a
[O] [RFC7426] YANG data models
[P] [RFC7426], YANG data models
[R] grammar
Ultimately they could be used in online, software-driven dynamic
systems, and eventually as part of an SDN system.
[O] systems, and
[P] systems and
[R] grammar
Equally, this document clarifies what a service model is
not, and dispels some common misconceptions.
[O] not, and
[P] not and
[R] grammar - I think.
Section 2. Terms and Concepts
An example of where such details are relevant to the customer
are when they describe the behavior or interactions on the
[O] are when
[P] is when
[R] subject/verb agreement ("An example [...] is [...]")
The distinction between a customer service model and a service
delivery model needs to be repeatedly clarified. A customer service
[O] repeatedly clarified.
[R] This seems like an odd thing to say. Maybe, "needs to be
emphasized" or "bears repeating" instead?
Section 4. Service Models in an SDN Context
That is, there should be an independence between the
behavior and functions that a customer requests and the technology
that the network operator has available to deliver the service. The
[O] That is, there should be an independence between the behavior and
functions that a customer requests and the technology that the network
operator has available to deliver the service.
[P] That is, the behavior and functions that a customer requests
should be independent of the technology that the network operator has
available to deliver the service.
[R] readability. Not sure if P is much better.
Section 5. Possible Causes of Confusion
SLAs are also linked to commercial terms
with penalties and so forth, and so are also not good topics for
[O] and so are also not good
[P] and thus SLAs are also not good
[R] grammar/clarity
Section 6.1. Comparison With Network Service Models
These are
service delivery models as described in this document, that is, they
[O] document, that is, they
[P] document; that is, they
[R] grammar
are the models used on the interface between the Service Orchestrator
or OSS/BSS and the Network Orchestrator as shown in Figure 3.
Figure 1 of [RFC8199] can be modified to make this more clear and to
add an additional example of a Network Service YANG model as shown in
Figure 4. This figure illustrates a functional architecture and an
[O] architecture and an
[P] architecture, and an
[R] grammar
Section 6.2. Service Delivery and Network Element Model Work
These models focus on how the network operator configures
the network through protocols and devices to deliver a service. Some
of these models are classified as service delivery models while
[O] models while
[P] models, while
[R] grammar
6.4. The MEF Architecture
This does not invalidate either approach, but only
[O] approach, but
[P] approach;
[R] grammar (or "either approach, it only" ?)
7.2. Relationship to Policy
As with commercial terms and SLAs discussed in Section 5 it is
[O] Section 5 it is
[P] Section 5, it is
[R] grammar
7.3. Operator-Specific Features
They also understood
that should an individual network operator want to describe
additional features (operator-specific features) they could do so by
[O] that should an individual network operator want to describe
additional features (operator-specific features)
[P] that, should an individual network operator want to describe
additional features (operator-specific features),
[R] grammar
7.4. Supporting Multiple Services
[O] It is an implementation and deployment choice whether all service
models are processed by a single Service Orchestrator that can
coordinate between the different services, or whether each service
model is handled by a specialized Service Orchestrator able to
provide tuned behavior for a specific service.
[P] Whether each service model is handled by a specialized Service
Orchestrator able to provide tuned behavior for a specific service or
whether all service models are handled by a single Service
Orchestrator is an implementation and deployment choice.
[R] readability
Section 8. Security Considerations
Therefore it is important that the protocol interface used to
exchange service request information between customer and network
operator is subject to authorization, authentication, and encryption.
Equally, all external intefaces, such as any of those between the
[O] intefaces
[P] interfaces
[R] spelling
W
--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
