Warren, thanks. Updating now. A > -----Original Message----- > From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Warren Kumari > Sent: 05 September 2017 13:16 > To: opsawg@ietf.org > Subject: [OPSAWG] Fwd: AD Review of draft-ietf-opsawg-service-model- > explained > > 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 <war...@kumari.net> > Date: Mon, Sep 4, 2017 at 8:43 PM > Subject: AD Review of draft-ietf-opsawg-service-model-explained > To: draft-ietf-opsawg-service-model-explained....@ietf.org > > > 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 > > > -- > 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 > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
