ks!
>
> I can post a rev++ addressing all discussion thus far, and then an
> unchanged draft-ietf-opsawg-...-00
>
> Thanks!
>
> Carlos.
>
> On Wed, May 8, 2024 at 4:14 AM Adrian Farrel <mailto:adr...@olddog.co.uk>> wrote:
>
> Thanks Henk,
>
> Apologies for the
Thanks Henk,
Apologies for the fatuous original name of this draft (but it worked to get
everyone's attention ;-)
- Yes, your suggested new name works for me.
- Since you ask, as one of the editors, I commit to a "pro-active alignment",
making changes as requested by the WG, and paying
Hello Henk,
No I'm not aware of any IPR the pertains to the content of this draft.
Adrian
-Original Message-
From: OPSAWG On Behalf Of Henk Birkholz
Sent: 02 May 2024 16:49
To: opsawg ;
draft-pignataro-opsawg-oam-whaaat-question-m...@ietf.org
Subject: [OPSAWG] IPR Call for
That sounds like a good point, Dhruv.
Cheers,
Adrian
From: OPSAWG On Behalf Of Dhruv Dhody
Sent: 01 May 2024 11:52
To: Henk Birkholz
Cc: OPSAWG
Subject: Re: [OPSAWG] WG Adoption Call for
draft-pignataro-opsawg-oam-whaaat-question-mark-03
Hi,
I support adoption.
Just one
Hi Henk,
It should come as no surprise that I would be happy to see this adopted.
I want to note that, as is always the case in the IETF, adoption would mean
that the working group can change every word of the document and even decide to
abandon the document. So Carlos and I are listening to
tional protocol work to resolve any
issues using the procedures described in RFC 4775 and RFC 4929.
Kind regards,
Adrian Farrel, MPLS Working Group Co-Chair
(On behalf of the MPLS Working Group and Co-Chairs)
Joe Clarke, OPSAWG Co-Chair
(On behalf of the
chairs copying either mailing list. We do intend
moving fairly quickly on this, but will wait until after MPLS has met (IETF
Tuesday) before sending anything.
Cheers,
Adrian (for the MPLS WG chairs)
-Original Message-
From: mpls On Behalf Of Adrian Farrel
Sent: 08 March 2024 15:37
To: 'mpls
I am also as confused as Alex :-)
The OPSAWG charter says:
The Operations and Management Area receives occasional proposals for
the development and publication of RFCs dealing with operational and
management topics that are not in scope of an existing working group
The NMOP charter
.
Looking forward to a fruitful debate,
Nigel and Adrian
===
Internet-Draft draft-davis-nmop-incident-terminology-00.txt is now
available.
Title: Some Key Terms for Incident Management
Authors: Nigel Davis
Adrian Farrel
Name:draft-davis-nmop-incident
too generally, while others already have perfect definitions,
that will lead to something similar to this document to bring the good into the
light.
Further comments in line…
From: Greg Mirsky
Sent: 12 January 2024 00:09
To: Carlos Pignataro ; Adrian Farrel
Cc: Ops Area WG ; IETF IPPM
I suppose that I don’t object to the definition of new abbreviations if people
are keen.
Personally, I don’t get the value of “inb-OAM” compared with “in-band OAM”.
It’s not like it can be said faster (one additional syllable to say it) and it
only saves four characters in typing.
[Adding the NMOP list - which is currently called NETMO]
It's a month later.
Nigel and I have been working on the first version of key terminology. We've
actually made some progress (perhaps slower than our initial enthusiasm
might have suggested).
We're just putting the last polish
Hi Jordi,
Thanks for the heads-up on this meeting. It will clearly be of interest to
the CATS working group although it is unclear from your brief summary of the
issue whether you intend exposure of information to "the application" (by
which I think you may mean the programs running on a host)
Hi,
I just saw draft-united-tvr-schedule-yang posted.
Please be aware that OPSAWG is working on YANG modules for scheduling as
well.
draft-ietf-opsawg-ucl-acl was just recently adopted, but the Wg has
determined that the scheduling aspects should be generalised and pulled out
into a separate
Thanks for asking, Joe.
Yes, I think that the WG should be working on ACs. Yes, I think that this
set of I-Ds form the basis for what needs to be covered.
I am *slightly* queasy about there being four documents. I'd be happier if
some consolidation were possible. But I have no concrete
As I said in my original comment, I'd like to see this separation. Various
recent conversations suggest that scheduling (services, resources, ACLs,
etc.) is becoming a Big Thing. Having a common model to facilitate this
would be really helpful.
QUESTION FOR THE CHAIRS
If this is split out,
Hi Tianran,
I think this is a timely piece of work that should be adopted. I commit
to further reviews if it is adopted.
A few minor comments on this version, below. Nothing that needs to be
fixed before adoption.
There is a meta-question: should the schedule model be moved out into
Hi,
That was a quick and thorough update, thanks!
I like this draft
Cheers,
Adrian
-Original Message-
From: I-D-Announce On Behalf Of
internet-dra...@ietf.org
Sent: 07 June 2023 11:44
To: i-d-annou...@ietf.org
Subject: I-D Action: draft-ma-opsawg-ucl-acl-03.txt
A New
Resending this cos somehow by autocomplete got mangled.
Adrian
-Original Message-
From: Adrian Farrel
Sent: 22 May 2023 09:59
To: 'ops...@ietf.com'
Cc: 'draft-ma-opsawg-ucl-...@ietf.org'
Subject: A review of draft-ma-opsawg-ucl-acl
Hi all,
I think that enhancing our ability
I have a fly-by response to this which is to say that "service degraded" is not the same as "service down".
Consider a p2mp service where one leaf is suddenly not reachable. You might say that the contracted service is not being delivered, but it will often be
Hi Tom, all,
I think my review as Shepherd ran into the same concern. And it is one of my
long-standing gripes that "we" (the IETF) repeatedly confuse VPN as a service
with the means and mechanisms to realise the VPN within the network. Of course,
as network engineers, it is understandable why
ks,
Adrian (as Shepherd)
-Original Message-
From: OPSAWG On Behalf Of Adrian Farrel
Sent: 05 August 2022 14:03
To: 'Rob Wilton (rwilton)'
Cc: draft-ietf-opsawg-yang-vpn-service-pm@ietf.org; opsawg@ietf.org
Subject: [OPSAWG] Checking in on draft-ietf-opsawg-yang-vpn-service-pm
Hi Rob,
Jus
Hi Rob,
Just doing my document shepherd thing and checking in with you.
Publication request was made for this document on 6th June. So we're at our
two-month marker.
I very much appreciate the thoroughness with which you review drafts, and I
understand the "gatekeeper role" of the IESG, but
s included as an informative reference.
^^
For the specific example you cited, the initial intent was to provide an
informative reference.
Cheers,
Med
> -Message d'origine-
> De : Adrian Farrel
> Envoyé : dimanche 17 juillet 202
Hi there,
Another question as I work through the shepherd write-up.
There are some I-Ds that appear as references in the module (i.e., in
Reference clauses). This implies that to understand the object concerned you
_might_ need to read the reference. For example,
identity sdwan {
Hi Oscar and Victor,
I'm checking the mailing list for IPR responses on this draft at the time of
the Working Group last call.
I can't find responses from you two (which may be my bad searching).
Can you either respond (copying the list) or point me at your previous
response.
Thanks,
Adrian
Cheers,
Med
-Message d'origine-
De : Adrian Farrel <adr...@olddog.co.uk>
Envoyé : jeudi 7 juillet 2022 19:43
À : draft-ietf-opsawg-...@ietf.org
Cc : opsawg@ietf.org
Hi,
I am your document shepherd for this journey.
Thanks for your work on the document so far, this is my review of your
draft. If you could work on updates or responses, I will continue with
the process of the shepherd write-up.
Hoping this gives you enough time to post an update before the
inline.
Cheers,
Med
> -Message d'origine-
> De : OPSAWG De la part de Adrian Farrel
> Envoyé : vendredi 13 mai 2022 19:42
> À : 'Joe Clarke (jclarke)' ;
> opsawg@ietf.org
> Objet : Re: [OPSAWG] WG LC: draft-ietf-opsawg-sap
>
> Very last minute review comments.
Very last minute review comments.
Thanks for the work on this draft. I think the fundamentals here are useful
and we are referencing this work from the TEAS network slicing work. I also
see it being mentioned in the TEAS packet-optical integration applicability
statement.
Thanks,
Adrian
===
that applies to this draft
Roni Even
> -Original Message-
> From: Adrian Farrel [mailto:adr...@olddog.co.uk]
> Sent: Friday, April 29, 2022 7:55 PM
> To: wangzi...@huawei.com; ron.even@gmail.com;
> liuc...@chinaunicom.cn; xuhl@chinatelecom.cn;
> oscar.gonzalezded
e RFC 4026 to informative reference
Please let us know if any further change is needed.
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-08
Thanks,
Bo
-Original Message-----
From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: Thursday, May 5, 2022 4:59 PM
To: 'tom pet
/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-07
Please also find some replies inline.
Thanks,
Bo
-Original Message-
From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: Saturday, April 23, 2022 12:35 AM
To: draft-ietf-opsawg-yang-vpn-service...@ietf.org
Cc: 'opsawg'
Subject
Hi,
Apologies for not catching this in the previous review.
I noted that the Security Considerations section (Section 6) doesn't match
the text suggested (required?) at
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines
Is there a reason for this? Fixing it will remove one f the
Hi,
I'm the document shepherd for this document as it moves beyond the WG
for requested publication as an RFC.
I reviewed the draft at -03 during WG last call, so my comments here
are basically editorial with only a few small questions.
If the authors could produce a new revision, I will start
descriptions.
Cheers,
Adrian
From: Teas On Behalf Of Henderickx, Wim (Nokia -
BE/Antwerp)
Sent: 22 March 2022 14:09
To: Greg Mirsky ; Med Boucadair
Cc: Adrian Farrel ; opsawg ; TEAS WG
Subject: Re: [Teas] A question on the definitions of SDP and SAP
Sorry the shime in late
So, yes. Well read, Greg, to spot the similarity. Thanks, Med, for pointing up
the text.
Are we all happy?
A
From: mohamed.boucad...@orange.com
Sent: 21 March 2022 11:50
To: Greg Mirsky ; Adrian Farrel ;
TEAS WG ; opsawg
Subject: RE: A question on the definitions of SDP and SAP
Hi,
I reviewed this draft at -01 [1]. The authors proposed acceptable
changes, and these have appeared in the subsequent revisions.
As part of WG last call, I have done another quick review. Asides
from a few trivial nits (below), I think this draft is ready for
publication.
Thanks,
Adrian
[1]
Hi,
I reviewed -09 of this draft at the time of the inconclusive adoption poll
back in December 2019. A lot of changes have been made since then,
including updates for my previous comments.
As the document appears to be somewhat stalled, I asked the chairs what
they thought the status was, and
Hi,
I'm just reviewing a different draft in OPSAWG
(draft-song-opsawg-ifit-framework) and it has a reference to
draft-ietf-opsawg-ntf
It seems to be in a bit of an odd state.
It went into IESG evaluation at the end of October and attracted some
weighty comments (one set attached to an Abstain
Hi Bo,
Thanks for the positive response.
Replies to you below. Summary: all good!
Best,
Adrian
>> Looking at Figure 1, an obvious question is why this model doesn't
augment the
>> L2/L3NM or the common VPN model. It is OK (for me) that you have chosen
to
>> augment the network topology model,
Hi authors,
This draft has been safely inside the OPSAWG for a while, so I though
it was probably due a review.
"The usual" two top-level issues:
- The draft expired earlier this month, so you need at a least a
keep-alive version.
- The draft has more than five front-page authors so the AD
Thanks Tianran,
I think that this is a good thing to be working on, and that this document
is a reasonable starting point.
I support adoption and promise to review the draft as it goes forward.
Adrian
From: OPSAWG On Behalf Of Tianran Zhou
Sent: 05 January 2022 02:12
To:
Sorry for the delay: there was a lot of cross-checking to be done.
The shepherd write-up is now posted and the chairs are free to continue the
process.
Best,
Adrian
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
: [OPSAWG] Shepherd review of draft-ietf-opsawg-l2nm
Re-,
Thanks for the follow-up.
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Adrian Farrel
> Envoyé : vendredi 19 novembre 2021 11:57
> À : BOUCADAIR Mohamed INNOV/NET ; draft-
> ietf-opsawg-l...@ietf.or
I have done my review of draft-ietf-opsawg-l2nm based on revision -10 of
the draft. Sorry it took so long, but there are a few pages of text that
needed to be read.
I have to congratulate the authors on this substantial piece of work. A
lot of time and effort must have gone into it.
It seems to
Useful comments, thanks Tom.
Authors, please run idnits and fix issues. Also address Tom's comments.
I'll be doing my shepherd review this week. Hopefully you can post a new
revision when the gates open next Monday.
Cheers,
Adrian
-Original Message-
From: tom petch
Sent: 01 November
PMFJI (and also for top-posting on a random email in the thread)
If your intention is to have an IANA registry, then please note that the
Independent Stream has a strong aversion to publishing documents that
create registries (see RFC 8726).
I leave it to the WG to decide whether a registry is
of Adrian Farrel
Sent: 13 April 2021 14:01
The write-up can be seen in the datatraker at
https://datatracker.ietf.org/doc/draft-ietf-opsawg-vpn-common/. I'd be
happy to address any comments.
I recommend that this document is held until the L3NM draft is also ready so
that they can proceed
been corrected with regular readouts on the
mailing list, as well as requests to the mailing list for input on
decisions.
Joe
On 4/30/21 14:06, Adrian Farrel wrote:
> Hi,
>
> I have posted the shepherd write-up for draft-ietf-opsawg-l3sm-l3nm.
>
> I believe that this document and dr
Hi,
I have posted the shepherd write-up for draft-ietf-opsawg-l3sm-l3nm.
I believe that this document and draft-ietf-opsawg-vpn-common can now move
ahead.
Cheers,
Adrian
___
OPSAWG mailing list
OPSAWG@ietf.org
Hi authors,
Just checking in as shepherd to find out how you are doing with the updates
after WG last call.
Thanks,
Adrian
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
The write-up can be seen in the datatraker at
https://datatracker.ietf.org/doc/draft-ietf-opsawg-vpn-common/. I'd be
happy to address any comments.
I recommend that this document is held until the L3NM draft is also ready so
that they can proceed together, although this is not strictly required.
Hi,
You all might like to look at draft-ietf-teas-rfc3272bis
That's a long document, and although any review would be very much welcomed,
the key is to look at the "components" of TE as discussed in section 1.2:
policy path steering, and resource management. It is "helpful" to describe
something
Shepherd here.
We have all IPR disclosures from authors and contributors for this document,
thanks.
Waiting for an update to address the last call comments, before I can take
the document to the next stage.
Note that YANG validation reports one warning:
ietf-vpn-com...@2021-02-22.yang:61:
Hi,
Document shepherd here.
Just checking thought the IPR responses for this document.
I think we are missing responses from:
Alejandro Aguardo
Erez Segev
Can you please respond on this thread so that we can move the document
forward.
Thanks,
Adrian
-Original Message-
From: OPSAWG
Hi,
WGLC review of draft-ietf-opsawg-l3sm-l3nm-07
I've reviewed this document a couple of times as it was being made, and
I have attended a few of the design team calls mainly as a spectator. I
co-chaired the L3SM working group so I have some clue as to what is
going on. I'm working with some of
Hi,
WGLC review of draft-ietf-opsawg-vpn-common
I was part of the design team calls that worked out it would be possible
to extract a common portion of the LxNM models and put them in a
separate common document.
As part of working group last call I've been through the draft and I
think it is
like:
> 1. any conflict to existing solution
> 2. wg interests
> ...
>
> But anyway, the WG mailing list could always be the place we can
> discuss about this technique.
>
> Best,
> Tianran
> -----Original Message-
> From: RFC ISE (Adrian Farrel) [mailto:rfc-.
) is
whether this is something that the WG would like to complete and publish
in the IETF stream.
Any thoughts?
Thanks,
Adrian
--
Adrian Farrel (Independent Stream Editor),
rfc-...@rfc-editor.org
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org
Thanks Randy,
I'm as happy as I'm likely to get.
Adrian
-Original Message-
From: OPSAWG On Behalf Of Randy Bush
Sent: 08 February 2021 21:05
To: Joe Clarke (jclarke)
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG] WG LC: draft-ietf-opsawg-finding-geofeeds
> There were some comments that
Hi Joe,
I think this document fills a hole in the set of YANG models we have for
managing and operating services over our network, and I'd like the WG to
pick it up and polish it.
I commit to doing a review or two as the draft advances. To kick that
off there are a few comments below. None of
Well, "whatever", but I liked the paragraph we had arrived at.
A
-Original Message-
From: Randy Bush
Sent: 02 February 2021 00:37
To: Erik Kline
Cc: adr...@olddog.co.uk; Ops Area WG ;
opsawg-cha...@ietf.org; draft-ietf-opsawg-finding-geofe...@ietf.org
Subject: Re: [OPSAWG] WG LC:
. It seems a little odd that the IETF
didn't want to publish 8805, but is chipper about publishing this document.
But, I'm not bothered by this.
Cheers,
Adrian
-Original Message-
From: Randy Bush
Sent: 01 February 2021 19:28
To: Adrian Farrel
Cc: opsawg@ietf.org; opsawg-cha...@ietf.org;
Hi,
Is it too late to ask for some privacy considerations to be added to this
document?
My initial thought was that the authors would point me to 8805, but a quick
look there doesn’t show any mention of privacy.
My concern here is that the end-user’s geographic locale is being
Hi,
I'm pitching in here as Independent Submissions Editor (ISE). I really should
use the proper email for this (rfc-...@rfc-editor.org) but I'm sticking with
this address as it is already subscribed to the OPSAWG list.
Responding to this particular email because (I think) it is the first one
Hi,
I'm a Contributor to this document.
I'm not of aware of any IPR associated with this document that has not
already been disclosed.
Thanks,
Adrian
From: OPSAWG On Behalf Of Tianran Zhou
Sent: 24 September 2020 07:43
To: opsawg
Cc: draft-ietf-opsawg-...@ietf.org
Subject:
Hi Brian,
I'll let the authors answer in more detail, but when we started the L3SM work
we were by no means certain that an automated software approach would be
adopted to requests by customers for service provision. The intent, therefore,
was to represent the service via a data model that
; Adrian Farrel
; opsawg@ietf.org; rwil...@cisco.com; adr...@olddog.co.uk
Subject: Last Call: (A
Framework for Automating Service and Network Management with YANG) to
Informational RFC
The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider
Thanks Joe,
I was one of the hummers for a common module in its own separate document. It
makes for an extra RFC (sad face) but makes it a lot clearer to people when
they are importing the module that they don't have to implement other stuff
that just happens to find itself in the same
Hi Joe,
I support adoption.
I have an interest in this work from co-chairing L3SM and L2SM, and I have been
attending some of the virtual meetings although I haven't made great
contributions to the work.
It seems to me that this work falls in scope alongside L3NM and I think it is
similarly
-framework-03
Hi Adrian,
Wonderful! Thank you very much.
Cheers,
Tianran
From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: Tuesday, June 16, 2020 5:41 PM
To: Tianran Zhou ; opsawg@ietf.org
Cc: 'OpsAWG-Chairs'
Subject: RE: [OPSAWG] WG LC: draft-ietf-opsawg-model-automation
Hi Tianran,
Since I did a detailed review during last call, and considering that I
haven't been involved in the production of this document, I guess I can
volunteer.
OK?
Best,
Adrian
From: OPSAWG On Behalf Of Tianran Zhou
Sent: 15 June 2020 02:40
To: opsawg@ietf.org
Cc:
I looked at the diffs, and I think Med has correctly captured my comments.
Thanks!
Adrian
From: OPSAWG On Behalf Of
mohamed.boucad...@orange.com
Sent: 15 June 2020 07:10
To: Tianran Zhou ; opsawg@ietf.org
Cc: OpsAWG-Chairs
Subject: Re: [OPSAWG] WG LC:
Hi,
I've reviewed this document in working group last call and support its
publication. I found the Appendix particularly helpful.
I have some minor thoughts that the authors may want to consider as the
document moves forward.
Thanks,
Adrian
==
idits says that
> I asked what the four documents were since AFAICT two are published
> RFC, and that has been confirmed. So what is going to happen to those
> RFC?
My proposal (but who am I to say what will actually happen) was:
- step one: nothing
The new module is shaped as it would have been had it been
ios' ; adr...@olddog.co..uk
Cc: 'opsawg'
Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions
From: Adrian Farrel
Sent: 28 May 2020 14:29
Hey Tom,
Is there a typo in your email? You said...
> So carving out the current types (etc) will likely lead to a bad
> outcome; it is a que
Hey Tom,
Is there a typo in your email? You said...
> So carving out the current types (etc) will likely lead to a bad
> outcome; it is a question of looking carefully across the range
> of documents to see what is, or is likely to be common.
I wondered whether you intended a "not" in there
Hey Roque,
Good news about the implementation.
If you look at Appendix A of the draft you'll see that a number of other
implementations have been written up and included. I'm sure if you constructed
some text and sent it to Oscar (the editor) he would be happy to include it in
the next
Isnt it possible to handle case b) by defining a value to have the meaning
no value has been assigned and then the user an explicitly set that value?
Adrian
From: netmod On Behalf Of Oscar González de Dios
Sent: 11 February 2020 02:40
To: opsawg@ietf.org; net...@ietf.org
Subject:
I think this discussion might have gotten a little out of hand!
Frank is clearly upset that his comments at the microphone did not make it into
the minutes. I think we all have a responsibility to review draft minutes when
we have made comments and check that they have been captured correctly.
Hi,
I sent the authors comments on a previous version of the document and
the authors made updates to address my concerns.
Considering this adoption poll, I have done another review of the draft.
I think it provides a useful overview of in-situ telemetry approaches and
Will serve the WG
Hi,
I just read the most recent version of this draft. It's a good starting
point for describing the topic, and I think that the working group should
adopt it up so we can reach agreement on the content.
I appreciate Appendix A: including the material is helpful, but keeping it
out of the main
Hi authors, WG,
I needed to read this document to check out a couple of things, and so
here is a review that I collected along the way. I hope it is useful.
In general, I found the document a help collection of thoughts on the space
and I encourage more work to refine it.
Best regards,
Adrian
Hey authors,
I reviewed -02 back in March and sent you a pile of comments mainly with
suggested text changes.
You posted -03 shortly after, and I just checked - looks like you made all of
the changes. Thanks.
While looking through the current version, I see a few bits and pieces that
could
Hi Tianran, working group,
Tl;dr -- I support adoption
I read Juergen's very substantive comments, and I probably need to go back
and re-read them. Juergen is a beacon for how IETF participants should
contribute constructively and in detail.
His detailed comments and suggestions for improvement
Hi authors,
I see you posted -02 and so I have given it a quick review. I spent my time
on the early sections because those are the ones that introduce the ideas to
the new reader.
Feel free to discuss, although the changes are basically editorial.
Best,
Adrian
===
Abstract
OLD
This
ecial definition and support, not apply for any mib data.
>
> Do you think the above are the SNMP defeat for telemetry use?
>
> Or what your thoughts?
>
> Thanks,
> Tianran
>
> > -Original Message-
> > From: Adrian Farrel [mailto:adr...@olddog.co.uk]
> >
Hi authors and working group.
I just had cause to read this document and thought I would share my
comments on the list.
The draft appears as -00, but it is a little more mature than that
implies because it replaces draft-song-ntf-02.
I think a foundation document on telemetry would be useful
Thanks David,
> Abstract: "... used within the IETF...". Wouldn't the document serve better to
> describe how the models could/are used by the industry including within SDN?
> Several of these models are used by other SDOs for their work in e.g.,
> providing
> network architecture, equipment
Thanks Robert,
> I don't have text to suggest, but please look at the first bullet of section
5.
> The explanation here was less helpful than the other bullets. Demonstrating
the
> confusion due to the reuse of the word "service" doesn't help clarify the
> confusion. I wonder if there's more
Hi Tom,
Long time!
> > What I see from 7950 is that a "YANG module" is a compilable blob of
> > YANG that may include other modules or specific constructs from another
> > module. That is clear enough.
> >
> > What is less clear is what a "data model" is or is not. I think that
> > if, for
> For now I'll complete the AD writeup, and put it in AD watching,
> revised ID needed state. Once y'all have figured out an answer I'll
> hit the Go button.
Fair enough, Warren.
I have an update ready with changes for everyone else's comment, so we are
"close".
I know that Benoit is busy
Hi Benoit,
>> 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
Hey Benoit,
Thanks for the review.
> Figure 3: Network configuration model is a brand new term that is only
> mentioned
> in the figure, and not explained.
OMG! That is a good catch.
> In the same figure, could the "Device Configuration Model" be renamed to RFC
> 8199
> "Network Element
Hey Joe,
Thanks for that. Looks like an easy change for us to pick up along the way.
Best,
Adrian
-Original Message-
From: Joseph Salowey [mailto:j...@salowey.net]
Sent: 17 September 2017 20:32
To: sec...@ietf.org
Cc: opsawg@ietf.org; i...@ietf.org;
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
Title : Service Models Explained
> Authors : Qin Wu
> Will Liu
> Adrian Farrel
> Filename: draft-ietf-opsawg-service-model-explained-02.txt
> Pages : 22
> Date
Hey Luis,
As we are updating the draft for last call comment, here are responses to your
comments.
> *Specific comments*
>
> - There are several sentences along the document trying to define the scope of
> service model in the context of IETF. These are: (1) in Terms and Concepts,
for
>
Hi Carl,
I'm in the process of updating the document and wanted to let you know what
changes are being made.
>>> - The term “Network Service Model” in RFC 8199 is intended to cover both
>>>"Customer Service Model” as well as “Service Delivery Model” as defined
>>>in
1 - 100 of 134 matches
Mail list logo
