Hi again...
> 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.
Yeah, my mistake for writing in a language that has been dead for 2000 years :-)
Added proper pointer.
> 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...
:-)
Meant "most advanced through the IETF process." But anyway...
OLD
Several initiatives within the IETF are developing customer service
models. The most advanced presents the L3VPN service as described by
a network operator to a customer. The L3SM is described as in
Figure 5 which is reproduced from [RFC8049]. As can be seen, the
L3SM is a customer service model as described in this document.
NEW
Several initiatives within the IETF are developing customer service
models. The L3SM presents the L3VPN service as described by
a network operator to a customer. Figure 5, which is reproduced
from [RFC8049], shows that the L3SM is a customer service
model as described in this document.
END
> 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
Debateable and left to RFC Ed for house style.
> 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
You're just moving my commas from one place to another.
But, yes.
> 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
See?
But leaving this one to RFC Ed as well.
> 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.
Ditto
> 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 [...]")
Yes. I feel bad about this one.
> 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?
Was my bitterness showing through?
s/repeatedly clarified/clarified/
> 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.
OLD
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.
NEW
That is, the technology that the network operator has available to
deliver the service should not influence the behavior and functions that
a customer requests.
END
> 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
OK
> 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
OK
> 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
Yes. Now you want to put a comma in for exactly the construction you wanted to
remove them from before :-)
Here I agree with you.
> 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
OK
> 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" ?)
OLD
This does not invalidate either approach, but only observes that they are
different.
NEW
This does not invalidate either approach: it only observes that they are
different approaches.
END
> 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
OK
> 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
OK
> 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
Good
> 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
OK
Posted.
Thanks,
Adrian
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
