On 2/12/2016 10:46 AM, Eliot Lear wrote:
Hi Stefan,
Unless it is absolutely determined that the current work can't doesn't
meet criteria for an IETF standard, I would be opposed to such an
exercise. For one thing, we all have other things to do. For another,
and as or more important, we wou
> does this wg have a chair?
seems so. thank you, scott.
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
does this wg have a chair?
randy
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
Alan,
Since you keep repeating yourself, forgive me if I do the same.
On 13/02/2016 02:32, Alan DeKok wrote:
> On Feb 11, 2016, at 5:54 PM, Brian E Carpenter
> wrote:
>> Charter updates are formal step, but the OPSAWG charter is already written
>> to encompass work of this kind.
>
> Except t
On Feb 12, 2016, at 1:32 PM, Warren Kumari wrote:
> ... *I* find it much simpler -- and, seeing as lots of network operators
> choose TACACS+ for their network device authentication, I suspect that others
> do too.
i.e. people find a TACACS+ daemon easier to deploy, because they choose
TACAC
On Fri, Feb 12, 2016 at 11:51 AM Alan DeKok
wrote:
> On Feb 12, 2016, at 11:34 AM, Warren Kumari wrote:
> > That is working on the assumption that the reason that operators are
> using TACACS+ instead of RADIUS is /only/ because of this feature. In many
> cases it is also because operators alrea
Hi,
> The chairs of the opsawg received an appeal from Alan DeKok on 11 February
> 2016 concerning the handling and possible disposition of
> draft-ietf-opsawg-tacacs-00.txt (TACACS+). This message was a follow up of
> a number of email messages sent to the opsawg mailing list starting on 10
> Fe
On Feb 12, 2016, at 11:46 AM, Douglas Gash (dcmgash) wrote:
>
> We¹d be more than happy to split into two documents, the first being a
> tidy up of the current deployed protocol, but focussed towards the device
> admin use case as we discussed yesterday, and a second to deal with the
> crypto iss
On 2/12/16 9:16 AM, Stefan Winter wrote:
> Hello,
>
>> 30 November: 2015: Warren sent the following message to the opsawg:
>> (for some reason this message does not show up in the archive but a
>> copy is
>> appended to this message)
>>
>> The chairs believe that there is sufficient interest
Hello,
> 30 November: 2015: Warren sent the following message to the opsawg:
> (for some reason this message does not show up in the archive but a
> copy is
> appended to this message)
>
> The chairs believe that there is sufficient interest and support
> to adopt
> this document as an O
On Feb 12, 2016, at 11:34 AM, Warren Kumari wrote:
> That is working on the assumption that the reason that operators are using
> TACACS+ instead of RADIUS is /only/ because of this feature. In many cases it
> is also because operators already have TACACS servers installed and / or find
> TACAC
We¹d be more than happy to split into two documents, the first being a
tidy up of the current deployed protocol, but focussed towards the device
admin use case as we discussed yesterday, and a second to deal with the
crypto issue in a backwards-compatible way.
It sounds like this would help de-mud
The chairs of the opsawg received an appeal from Alan DeKok on 11 February
2016 concerning the handling and possible disposition of
draft-ietf-opsawg-tacacs-00.txt (TACACS+). This message was a follow up of
a number of email messages sent to the opsawg mailing list starting on 10
February.
The to
Hi,
> Unless it is absolutely determined that the current work can't doesn't
> meet criteria for an IETF standard, I would be opposed to such an
> exercise. For one thing, we all have other things to do.
Contrary to that, many people on this list are arguing for their life on
the do's or don't's
> On Feb 12, 2016, at 10:46 AM, Eliot Lear wrote:
>
> Hi Stefan,
>
> Unless it is absolutely determined that the current work can't doesn't meet
> criteria for an IETF standard, I would be opposed to such an exercise. For
> one thing, we all have other things to do. For another, and as or m
On Fri, Feb 12, 2016 at 8:26 AM Stefan Winter
wrote:
> Hello,
>
> >> Is the RADIUS WG going to add support for command authorization? It
> seems like if RADIUS wanted this then one vendor refusing to submit a
> standard wouldn't be a barrier. Surely anyone could write a standard and
> propose i
- Original Message -
From: "Alan DeKok"
To: "Eliot Lear"
Sent: Friday, February 12, 2016 12:23 PM
On Feb 12, 2016, at 5:19 AM, Eliot Lear wrote:
> Actually the work started long before THAT, even. I think it dates to
> 1993 if memory serves.
RFC1492 is dated July 1993 but what I find
Hi Stefan,
Unless it is absolutely determined that the current work can't doesn't
meet criteria for an IETF standard, I would be opposed to such an
exercise. For one thing, we all have other things to do. For another,
and as or more important, we would be denying the reality of the
situation. I
On Feb 12, 2016, at 9:12 AM, Stefan Winter wrote:
> Maybe there should be two (or more) drafts instead:
I support that.
> If you can follow my line of thinking to this point, let's take it even
> one step further: we are now discussing a larger effort, involving
> multiple RFCs, taking an exis
On Feb 12, 2016, at 9:30 AM, Mikael Abrahamsson wrote:
> As far as I know, I have never insisted it needs to be a standards track
> document. I just re-read all my email I have sent on this issue, and I have
> consistently used the term "documented in an RFC".
Forgive me, but you were opposin
On Fri, 12 Feb 2016, Alan DeKok wrote:
Why is it necessary to have a standards track document? What's wrong with
informational?
I've respected you by answering your questions and explaining my position.
Please consider doing the same for me.
As far as I know, I have never insisted it ne
On Feb 12, 2016, at 9:07 AM, Mikael Abrahamsson wrote:
>
> On Fri, 12 Feb 2016, Alan DeKok wrote:
>
>> So it *is* a AAA protocol?
>
> I actually do not know what criteria you put in the AAA term. It might be
> different from what I use it for.
This is getting silly. The document describes
Hello,
this debate has been going on for quite a while. It's multi-faceted,
which doesn't help coming to conclusions.
Maybe we can un-entangle one point: there are suggestions to either make
this Standards Track or Informational; and one wheteher the protocol
should be documented vs. improved.
M
On Fri, 12 Feb 2016, Alan DeKok wrote:
So it *is* a AAA protocol?
I actually do not know what criteria you put in the AAA term. It might be
different from what I use it for.
For me TACACS does the following things:
It checks username/password when I login, and the TAC+ server says if I
c
On Feb 12, 2016, at 8:51 AM, Stefan Winter wrote:
>
>> RadExt Charter text is less clear except that their milestones are
>> explicit and focused on the 'network access' problem, not the 'network
>> managment' or 'network operations' or 'network adminsitration'
>> problem(s).
>
> The sentence "T
Hello,
> RadExt Charter text is less clear except that their milestones are
> explicit and focused on the 'network access' problem, not the 'network
> managment' or 'network operations' or 'network adminsitration'
> problem(s).
The sentence "The RADIUS Extensions Working Group will focus on
exten
On Feb 11, 2016, at 5:54 PM, Brian E Carpenter
wrote:
> Charter updates are formal step, but the OPSAWG charter is already written
> to encompass work of this kind.
Except that the charter says new work will require IESG approval.
> As I hinted before, it's unfortunate that
> the WG milestone
Hello,
>> Is the RADIUS WG going to add support for command authorization? It seems
>> like if RADIUS wanted this then one vendor refusing to submit a standard
>> wouldn't be a barrier. Surely anyone could write a standard and propose it
>> as a draft?
>
> It would be well within the scope
On Feb 12, 2016, at 1:01 AM, Mikael Abrahamsson wrote:
>
> It is not vendor specific. In the past 15 years I have used TAC+ on Cisco,
> Juniper, Huawei and others. That's what we used, and if you wanted to provide
> IP core equipment, that's what you had to support.
I understand. But let's
On Feb 12, 2016, at 5:19 AM, Eliot Lear wrote:
> Actually the work started long before THAT, even. I think it dates to
> 1993 if memory serves.
Pretty much. RFC 2989 and RFC 3127 are the outcomes (~y2000), not the start
of the process.
> But speaking plainly, this isn't a science experimen
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
of the IETF.
Title : HMAC-SHA-2 Authentication Protocols in USM for SNMPv3
Authors : Johannes Merkle
Tom,
On 2/12/16 10:41 AM, t.petch wrote:
> Looking at the Informational RFC in the RFC-index, I see
>
> Cisco Architecture for Lawful Intercept in IP Networks
> Cisco Systems NetFlow Services Export Version 9
> Cisco's Mobile IPv4 Host Configuration Extensions
> Cisco Systems UniDirectional Link D
- Original Message -
From: "Eliot Lear"
Sent: Thursday, February 11, 2016 7:36 PM
Hi Alan,
I'm not unsympathetic to the idea that we should focus efforts where
possible, and I'm also not interested in piling on. But I think a
comment is in order regarding RFC 3127 and then I have a pr
33 matches
Mail list logo
