[OPSAWG] I-D Action: draft-ietf-opsawg-tacacs-yang-01.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working Group 
WG of the IETF.

Title   : Yang data model for TACACS+
Authors : Guangying Zheng
  Michael Wang
  Bo Wu
Filename: draft-ietf-opsawg-tacacs-yang-01.txt
Pages   : 14
Date: 2019-11-04

Abstract:
   This document defines YANG modules that augment the System Management
   data model defined in the RFC 7317 with TACACS+ client model.  The
   data model of Terminal Access Controller Access Control System Plus
   (TACACS+) client allows the configuration of TACACS+ servers for
   centralized Authentication, Authorization and Accounting.

   The YANG modules in this document conforms to the Network Management
   Datastore Architecture (NMDA) defined in RFC 8342.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-yang/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-yang-01
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-tacacs-yang-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tacacs-yang-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-tacacs-yang-01.txt

[Wubo (lana)]

Dear WG,

We submitted version 01 of draft-ietf-opsawg-tacacs-yang to resolve comments 
received on 105 meetings and the mailing list.
https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-yang-01

Here are some major changes in this version:
- Improve model description and fix language/grammar errors based on John 
Heasley's comments
- Add the identity ‘tacacsplus’ to allow ‘user authentication order’ to use 
TACACS+ authentication
- Add an appendix section to describe TACACS+ authentication configuration

The new appendix adds suggestion for the system authentication configuration 
since there are still two unresolved issues, proposed by Ebben Aries:
1) The 'user-authentication-order' must restrictions 
'user-authentication-order' is a leaf-list. But as per RFC7950, the target node 
of the "augment" statement cannot be a leaf-list. Therefore, must restrictions 
of TACACS+ Authentication cannot be added.

2) Whether to add 'tacacsplus-authentication' feature like radius
TACACS+ not only supports authentication, but also supports authorization and 
accounting, and in most cases, these three functions are used together.
Defining three separate features appears a bit complicated.Therefore, we 
recommend only defining "tacacsplus" feature.

Best Regards,
Bo


-邮件原件-
发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
发送时间: 2019年11月4日 21:00
收件人: wangzitao ; Wubo (lana) ; 
Zhengguangying (Walker) ; Wubo (lana) 
; wangzitao 
主题: New Version Notification for draft-ietf-opsawg-tacacs-yang-01.txt


A new version of I-D, draft-ietf-opsawg-tacacs-yang-01.txt
has been successfully submitted by Bo Wu and posted to the IETF repository.

Name:   draft-ietf-opsawg-tacacs-yang
Revision:   01
Title:  Yang data model for TACACS+
Document date:  2019-11-03
Group:  opsawg
Pages:  14
URL:
https://www.ietf.org/internet-drafts/draft-ietf-opsawg-tacacs-yang-01.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-yang/
Htmlized:   https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-yang-01
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-tacacs-yang
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tacacs-yang-01

Abstract:
   This document defines YANG modules that augment the System Management
   data model defined in the RFC 7317 with TACACS+ client model.  The
   data model of Terminal Access Controller Access Control System Plus
   (TACACS+) client allows the configuration of TACACS+ servers for
   centralized Authentication, Authorization and Accounting.

   The YANG modules in this document conforms to the Network Management
   Datastore Architecture (NMDA) defined in RFC 8342.


  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] New version of draft-gray-sampled-streaming

[Gray, Andrew A]

I have updated draft-gray-sampled-streaming based on the numerous bits of 
feedback I have received to date.  Thanks all for the comments.  

-02 includes updates to the Client subscription sequence to make it clearer 
when different sides do different actions, adds a 'proposals' step that allows 
more error reporting and multiple options to be handed back, many 
clarifications about what role this draft is targeting, more use case examples, 
multiple YANG cleanups, numerous small changes and updates, and adding LJ 
Wobker as an author.

Please feel free to take a look, and we are always interested in getting 
feedback.  I've asked the opsawg chairs for time at IETF 106 to present, as 
well.

Thanks.

A new version of I-D, draft-gray-sampled-streaming-02.txt
has been successfully submitted by Andrew Gray and posted to the
IETF repository.

Name:   draft-gray-sampled-streaming
Revision:   02
Title:  Sampled Traffic Streaming
Document date:  2019-11-04
Group:  Individual Submission
Pages:  36
URL:
https://www.ietf.org/internet-drafts/draft-gray-sampled-streaming-02.txt
Status: https://datatracker.ietf.org/doc/draft-gray-sampled-streaming/
Htmlized:   https://tools.ietf.org/html/draft-gray-sampled-streaming-02
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-gray-sampled-streaming
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-gray-sampled-streaming-02

Abstract:
   This document standardizes both 1) a means of requesting a stream of
   packet samples from any device generating, routing, or forwarding
   traffic, and 2) receiving metadata information from the network
   element about these packet samples, and the structure of said stream
   metadata.  A main design requirement is to provide network elements
   with widely varying capabilities (e.g., ASICs, NPUs, NICs, vSwitches,
   CPUs) a mechanism to sample and export packets at high rates, by
   allowing communication of the specific bit formats of internal data
   headers applied to the packet flow, in a way that enhances
   interoperability between traffic sources and sinks.  Historically,
   Netflow and similar mechanisms have been used for these use cases;
   however, the increasing packet rates of very high-speed devices and
   increasing variance in the information available to data planes lends
   itself to both a less-prescriptive set of packet formats as well as a
   decoupling of the sampling action from the collection and analysis
   mechanisms.


E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Service Assurance for Intent-based Networking Architecture and YANG modules

[Benoit Claise]

Dear all,

Let me introduce these two new drafts:
    - draft-claise-opsawg-service-assurance-architecture-00
    - draft-claise-opsawg-service-assurance-yang-01

The first document describes the architecture for Service Assurance for 
Intent-based Networking (SAIN). This architecture aims at assuring that 
service instances are correctly running. As services rely on multiple 
sub-services by the underlying network devices, getting the assurance of 
a healthy service is only possible with a holistic view of network 
devices. This architecture not only helps to correlate the service 
degradation with the network root cause but also the impacted services 
impacted when a network component fails or degrades.


This second document complements the architecture by providing open 
interfaces between components, meaning YANG modules.


Feel free to read, review, and provide your feedback.

Regards, Jean & Benoit


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

[Peter Gutmann]

I actually think it's a pretty good summary, and delivers exactly what's
promised in the title.  OTOH I can also see that it's going to get bikeshedded
to death, and will probably never be editable into a form where people won't
complain about it no matter how many changes are made.  Alternatively, it'll
end up watered down to a point where no-one can complain any more but it won't
say anything terribly useful by then.

Perhaps it could be published as is with a comment that it represents the
opinions of the authors?  Although given that it's Informational and not
Standards-track or a BCP, that should be a given anyway.

Peter.



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

[Eric Rescorla]

On Mon, Nov 4, 2019 at 5:44 PM Peter Gutmann 
wrote:

> I actually think it's a pretty good summary, and delivers exactly what's
> promised in the title.  OTOH I can also see that it's going to get
> bikeshedded
> to death, and will probably never be editable into a form where people
> won't
> complain about it no matter how many changes are made.  Alternatively,
> it'll
> end up watered down to a point where no-one can complain any more but it
> won't
> say anything terribly useful by then.
>
> Perhaps it could be published as is with a comment that it represents the
> opinions of the authors?  Although given that it's Informational and not
> Standards-track or a BCP, that should be a given anyway.
>

Actually, no. Most IETF documents, even informational ones, bear a
statement that they have IETF Consensus.

See: https://tools.ietf.org/html/rfc5741#section-3.2.1

-Ekr


> Peter.
>
>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

[Joel M. Halpern]

If the authors want to publish it as an RFC so as to comment on other 
RFCs, they could approach the Independent Stream Editor.  That sort of 
publication is one of the explicit purposes of the Independent Stream.


Yours,
Joel

On 11/4/2019 9:34 PM, Eric Rescorla wrote:



On Mon, Nov 4, 2019 at 5:44 PM Peter Gutmann > wrote:


I actually think it's a pretty good summary, and delivers exactly what's
promised in the title.  OTOH I can also see that it's going to get
bikeshedded
to death, and will probably never be editable into a form where
people won't
complain about it no matter how many changes are made. 
Alternatively, it'll

end up watered down to a point where no-one can complain any more
but it won't
say anything terribly useful by then.

Perhaps it could be published as is with a comment that it
represents the
opinions of the authors?  Although given that it's Informational and not
Standards-track or a BCP, that should be a given anyway.


Actually, no. Most IETF documents, even informational ones, bear a 
statement that they have IETF Consensus.


See: https://tools.ietf.org/html/rfc5741#section-3.2.1 



-Ekr


Peter.




___
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

Re: [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

[Peter Gutmann]

Eric Rescorla  writes:

>Actually, no. Most IETF documents, even informational ones, bear a statement
>that they have IETF Consensus.

Ah, OK.  In that case publish it with a statement that commentators couldn't
agree on what it should say, which I think is better than watering it down to
a level where commentators can't disagree with what it says.  It's an
interesting document which makes good points, and worth putting out there
while it still has good points to make.

Peter.



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [tsvwg] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

[Joe Touch]

> On Nov 4, 2019, at 6:39 PM, Joel M. Halpern  wrote:
> 
> If the authors want to publish it as an RFC so as to comment on other RFCs, 
> they could approach the Independent Stream Editor.  That sort of publication 
> is one of the explicit purposes of the Independent Stream.

That only happens if the WG and IESG say this is out of scope for the IETF. 
I.e., the ISE isn’t an end-run.

IMO, given the fact that this is squarely within TSVWG and there’s no 
consensus, the way forward is clear.

Not every ID turns into an RFC, nor should it.

Joe
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [tsvwg] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

[Joel M. Halpern]

Actually Joe, the rules clearly allow the case wehre an Independent 
Stream I-D disagrees with the IETF rough consensus.  Many such have been 
published.  Some of them were held so that they were not published until 
the relevant IETF work was published.


To be explicit, while the IESG can request that the ISE not publish 
something, and can provide a note they wish to have included if it is 
published, they do not have the power to enforce a do-not-publish if the 
ISE disagrees.
And Joe, you have lived aspects of this more closely than I have, so I 
am sure you are aware of it.


Yours,
Joel

On 11/4/2019 9:48 PM, Joe Touch wrote:




On Nov 4, 2019, at 6:39 PM, Joel M. Halpern  wrote:

If the authors want to publish it as an RFC so as to comment on other RFCs, 
they could approach the Independent Stream Editor.  That sort of publication is 
one of the explicit purposes of the Independent Stream.


That only happens if the WG and IESG say this is out of scope for the IETF. 
I.e., the ISE isn’t an end-run.

IMO, given the fact that this is squarely within TSVWG and there’s no 
consensus, the way forward is clear.

Not every ID turns into an RFC, nor should it.

Joe



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] presentation slot request RE: Call for Adoption "draft-song-opsawg-ifit-framework"

[Haoyu Song]

Hi Joe and WG chairs,

We have updated the draft and uploaded the v07.
https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/
I’m writing to request a presentation slot in the upcoming IETF WG session.

In this version, we explicitly assert that any specific component and interface 
implementations are out of the scope of this draft. In this draft, we dedicate 
on listing all the challenges on deploying data plane on-path telemetry 
techniques, providing a high level architectural framework with a few key 
components to address those challenges, providing several examples on what can 
be done for each component, and finally, laying out the potential to support 
closed-loop telemetry applications based on this framework.

To clarify the discussion, we also include a taxonomy of the data plane on-path 
telemetry techniques and define the terms used in this draft.

We think the content covered already makes contribution to the community and 
the industry, which will inspire not only innovative implementations but also 
new standard works that actually specify the interfaces. Many of our operator 
customers appreciated that we summarize the deployment challenges in carrier 
networks and point out the possible solution directions.

Thanks for the consideration.

Best regards,
Haoyu

From: Joe Clarke (jclarke) 
Sent: Thursday, October 24, 2019 3:21 PM
To: Haoyu Song 
Cc: opsawg-cha...@ietf.org; opsawg@ietf.org
Subject: Re: Call for Adoption "draft-song-opsawg-ifit-framework"




On Oct 23, 2019, at 05:42, Haoyu Song 
mailto:haoyu.s...@futurewei.com>> wrote:

Hi Joe,

Thank you for the detailed comments!

Let me try to explain the purpose of this draft better. Given the recent 
on-path data plane telemetry techniques and standard works, in this draft we 
discuss the deployment challenges and potential opportunities for applications. 
There is no such a document in IETF AFAIK and we feel it’s needed (also 
confirmed by some network operators who are interested in such techniques)

Tianran and I emailed on the chairs list, and I agree a deployment guide would 
be beneficial that shares practical experiences, operator considerations, and 
best practices.  However, the iFIT document does not read that way.  It reads 
more like a very specific architecture that is not fully fleshed out.  It 
leaves one (well, it leaves me) guessing as to what iFIT really is and how can 
I really be compliant to it.  What do I _really implement_ in this?



Most related standard proposals so far only defines the data plane protocol and 
lack considerations for a complete solution. To this end, we discuss various 
points that a solution should pay attention to and how these can be composed to 
support applications. Along with the discussion, we provide some examples and 
use cases to trigger new ideas.

I haven’t participated in IPPM, so I can’t comment.  But in general, yes, 
having at least deployment considerations for things like IOAM and PBT would 
benefit operators.

Your comment about applications is one area where I find iFIT nebulous, though. 
 I don’t get a clear picture from the draft as to what an iFIT application is, 
and thus if I read this as a guide to help me implement, say, IOAM end-to-end, 
I’m still left wondering about specific things I may want to do in terms of 
where to export, what type of IOAM tracing to use, and what pitfalls to be 
aware of.

That said, you do cover things like a need for sampling as well as impact to 
devices.  Those are helpful but incomplete.  I’d love to get a more detailed 
understanding as to the impact I could expect from using IOAM and operating on 
packets versus the overhead incurred by something like PBT which still entails 
on-box processing.



We deliberately make iFIT an open framework and avoid introducing any new 
protocol and enforcing any specific approaches, because otherwise we are in 
danger to put unnecessary constraints on implementation approaches and hurt the 
possibility of innovation. While we mean to keep this document informational, 
we may consider to add more discussions on reference designs, operational 
experiences,  and best practices as you suggested.

It is this latter thing which I think is needed more.



Some points you raised below also deserves more detailed explanation, such as 
how to make an iFIT closed loop and how architecture and algorithm components 
can be composed to form such a loop. Perhaps a complete example can help to 
explain that. I’ll consider all this in future revisions.

In a sense, this document indeed aims to discuss the implementation, 
operational experiences, and best practices  of PBT, IOAM, and other similar 
techniques. We hope this document will trigger new drafts on management 
plane/control plane and innovative solutions.

Ultimately, I think what I’m saying is that it sounds like today we need a 
guide on practical deployment considerations around various OAM solutions, but 
we don’t yet need a noun to call