[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf
Subject:    Re: Last Call: <draft-ietf-opsawg-service-model-explained-04.txt> (Service Models Explained) to Info
From:       Warren Kumari <warren () kumari ! net>
Date:       2017-09-27 17:39:20
Message-ID: CAHw9_i+=2EEbPCqhmJbMoqjNuWic+Uf1-p51+guuQTxKcusCcA () mail ! gmail ! com
[Download RAW message or body]

Apologies everyone, I accidentally hit the wrong button in the datatracker.

This document has already successfully passed IETF LC
(https://mailarchive.ietf.org/arch/msg/ietf-announce/FXMc81LranPhaqpS_rIOE6Q8nbA),
I am not restarting it.

Sorry again for the noise / mis-click.
W



On Wed, Sep 27, 2017 at 10:31 AM, The IESG <iesg-secretary@ietf.org> wrote:
>
> The IESG has received a request from the Operations and Management Area
> Working Group WG (opsawg) to consider the following document: - 'Service
> Models Explained'
>   <draft-ietf-opsawg-service-model-explained-04.txt> as Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2017-10-11. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
>
>    The IETF has produced many modules in the YANG modeling language.
>    The majority of these modules are used to construct data models to
>    model devices or monolithic functions.
>
>    A small number of YANG modules have been defined to model services
>    (for example, the Layer Three Virtual Private Network Service Model
>    produced by the L3SM working group and documented in RFC 8049).
>
>    This document describes service models as used within the IETF, and
>    also shows where a service model might fit into a Software Defined
>    Networking architecture.  Note that service models do not make any
>    assumption of how a service is actually engineered and delivered for
>    a customer; details of how network protocols and devices are
>    engineered to deliver a service are captured in other modules that
>    are not exposed through the Customer-Provider Interface.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>



-- 
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

[prev in list] [next in list] [prev in thread] [next in thread]