On Tue, Sep 5, 2017 at 10:31 AM, Adrian Farrel <[email protected]> wrote:
> 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...
Ah, I *so* didn't get that...
>
> 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.
Yes, yes I am. You gotta met me have *some* fun!
>
> 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.
https://imgflip.com/i/1vcf6j
:-P
>
>> 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 :-)
>
https://media3.giphy.com/media/bA5EUCvMgDBkc/200_s.gif
> 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
>
Thank you very much.
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
