Re: [OPSAWG] OPSAWG Digest, Vol 105, Issue 119

[Douglas Gash (dcmgash)]

Hi Warren,

I am one of the contributing authors in this document. I sincerely
apologise for submitting a document which seemed to evoke passion in
OpsAWG ;-)

As you can tell from my email address, I work for Cisco, which provided
some input in taking the original TACACS and evolving it to TACACS+ in
1990s.

I have double checked with IPR expert (a lawyer) in Cisco and he sees no
IPR issues, and with our IETF experts who know of no IPR which impact
TACACS+ in our pursuit of getting TACACS+ ratified as a standard, if that
is what OpsAWG elects to do.

I can work offline to make sure that we get the proper wording, but to the
absolute best of my knowledge, Cisco has no IPR that applies to the
document.

Just to say, this process came about from engineers who are very
interested in TACACS+ and its adoption and deployment, one of whom (me)
works for Cisco. We want to address the crypto issue it has, and clean up
the document, try to remove ambiguities, and deprecate some really
insecure features. But also want to remove the perception that TACACS+ is
a proprietary Cisco protocol. We thought that working with IETF to
standardise the protocol may help all that, and get some interesting
technical criticism.

Many thanks and Best Regards,

Doug, (Collaborating with: Thorsten, Andrej).


On 15/02/2016 18:46, "OPSAWG on behalf of opsawg-requ...@ietf.org"
 wrote:

>Send OPSAWG mailing list submissions to
>   opsawg@ietf.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>   https://www.ietf.org/mailman/listinfo/opsawg
>or, via email, send a message with subject or body 'help' to
>   opsawg-requ...@ietf.org
>
>You can reach the person managing the list at
>   opsawg-ow...@ietf.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of OPSAWG digest..."
>
>
>Today's Topics:
>
>   1.  Untangling - Explicit call for IPR on
>  draft-ietf-opsawg-tacacs-00 (Warren Kumari)
>
>
>--
>
>Message: 1
>Date: Mon, 15 Feb 2016 18:46:37 +
>From: Warren Kumari 
>To: "opsawg@ietf.org" 
>Subject: [OPSAWG] Untangling - Explicit call for IPR on
>   draft-ietf-opsawg-tacacs-00
>Message-ID:
>   
>Content-Type: text/plain; charset="utf-8"
>
>Dear WG,
>
>Thanks to everyone who has been participating. It is refreshing to see
>this
>much passion and involvement in OpsAWG! We wanted to give this a bit of
>time to settle down, and also to see where this ended up.
>
>We are going to do a series of steps to get as clear a view of the
>consensus of the WG about this document.   This message is a explicit call
>for any known IPR.
>
>We will follow up with two  other messages, each with a particular
>question
>- the reason for such formality is to try to untangle the many threads
>that
>erupted on the main list.
>
>Many of you have already expressed your opinion but can you please do so
>again in response to the forthcoming two messages so that the record is
>clear.  We expect to determine the path forward in 2 weeks.
>
>Are you personally aware of any IPR that applies to
>draft-ietf-opsawg-tacacs?  If so, has this IPR been disclosed in
>compliance
>with IETF IPR rules?
>(See RFCs 3979, 4879, 3669, and 5378 for more details.)
>
>If you are a document author or listed contributor on this document,
>please
>reply to this email regardless of whether or not you are personally aware
>of any relevant IPR.
>
>Scott, Tianran and Warren
>-- next part --
>An HTML attachment was scrubbed...
>URL: 
>0802/attachment.html>
>
>--
>
>Subject: Digest Footer
>
>___
>OPSAWG mailing list
>OPSAWG@ietf.org
>https://www.ietf.org/mailman/listinfo/opsawg
>
>
>--
>
>End of OPSAWG Digest, Vol 105, Issue 119
>

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

Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC?

[Andy Bierman]

On Tue, Feb 16, 2016 at 4:16 PM, Scott O. Bradner  wrote:

>
> > On Feb 16, 2016, at 7:14 PM, Andy Bierman  wrote:
> >
> >
> >
> > On Tue, Feb 16, 2016 at 3:08 PM, Randy Bush  wrote:
> > >> One thing to keep in mind is that, if the document describing the
> > >> currently deployed protocol is informational, we may have a tricky
> time
> > >> making the extensions be standards track; it would (presumably)
> require
> > >> a downref.
> > >
> > > it would; it is not logically a huge problem, merely wierd.
> > >
> > > I doubt very much that a push for better securing of an existing mature
> > > protocol is the likely source of controversy there.
> >
> > what is amusing is that some folk seem to be contemplating that the
> > rfc of an old and widely distributed and used protocol should not be
> > standard.
> >
> >
> > I think some of us are confused by the use of the term "standard".
> > This sometimes refers to a process that is driven by requirements, and
> > open to multiple competing solution proposals which address the
> requirements.
> > Usually the solution is not decided in advance.
> >
> > Is that the process you have in mind? Doesn't sound like it at all.
> > Who decides that the draft represents the One True definition of TACACS+?
> > Is that open to debate, decided by WG consensus?
>
>
> decided by WG consensus
>

sounds like standards track is OK then



> Scott
>

Andy


> >
> > I am not questioning the value of publishing an RFC, but a standards
> track RFC
> > requires a proper process.
> >
> >
> >
> > randy
> >
> >
> > Andy
> >
> >
> > ___
> > 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
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC?

[Scott O. Bradner]

> On Feb 16, 2016, at 7:14 PM, Andy Bierman  wrote:
> 
> 
> 
> On Tue, Feb 16, 2016 at 3:08 PM, Randy Bush  wrote:
> >> One thing to keep in mind is that, if the document describing the
> >> currently deployed protocol is informational, we may have a tricky time
> >> making the extensions be standards track; it would (presumably) require
> >> a downref.
> >
> > it would; it is not logically a huge problem, merely wierd.
> >
> > I doubt very much that a push for better securing of an existing mature
> > protocol is the likely source of controversy there.
> 
> what is amusing is that some folk seem to be contemplating that the
> rfc of an old and widely distributed and used protocol should not be
> standard.
> 
> 
> I think some of us are confused by the use of the term "standard".
> This sometimes refers to a process that is driven by requirements, and
> open to multiple competing solution proposals which address the requirements.
> Usually the solution is not decided in advance.
> 
> Is that the process you have in mind? Doesn't sound like it at all.
> Who decides that the draft represents the One True definition of TACACS+?
> Is that open to debate, decided by WG consensus?


decided by WG consensus

Scott
> 
> I am not questioning the value of publishing an RFC, but a standards track RFC
> requires a proper process. 
> 
> 
>  
> randy
> 
> 
> Andy
>  
> 
> ___
> 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

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

Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC?

[Andy Bierman]

On Tue, Feb 16, 2016 at 3:08 PM, Randy Bush  wrote:

> >> One thing to keep in mind is that, if the document describing the
> >> currently deployed protocol is informational, we may have a tricky time
> >> making the extensions be standards track; it would (presumably) require
> >> a downref.
> >
> > it would; it is not logically a huge problem, merely wierd.
> >
> > I doubt very much that a push for better securing of an existing mature
> > protocol is the likely source of controversy there.
>
> what is amusing is that some folk seem to be contemplating that the
> rfc of an old and widely distributed and used protocol should not be
> standard.
>
>
I think some of us are confused by the use of the term "standard".
This sometimes refers to a process that is driven by requirements, and
open to multiple competing solution proposals which address the
requirements.
Usually the solution is not decided in advance.

Is that the process you have in mind? Doesn't sound like it at all.
Who decides that the draft represents the One True definition of TACACS+?
Is that open to debate, decided by WG consensus?

I am not questioning the value of publishing an RFC, but a standards track
RFC
requires a proper process.




> randy
>


Andy


>
> ___
> 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] Detangling - Q3: Publish TACACS+ as a standards track RFC?

[Randy Bush]

http://shrubbery.net/tac_plus/

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

Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC?

[Blumenthal, Uri - 0553 - MITLL]

Please enlighten me - what did IETF have to do with the TACACS running code? 
Did anybody among those who want it on the standards track even see the sources 
of that code (and could point me at an available reference implementation)?

Normally a protocol completed outside of IETF is described in an Informational 
RFC if it's popular enough to justify that. TACACS is deployed widely enough, 
no argument there - but why should a protocol that managed to get born, 
deployed, and wide-spread for more than two decades, suddenly need an IETF 
standards-track RFC to define it? Why isn't Informational good enough?

I've no stake in this fight, and don't really care - just want to hear the 
reasons.

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
From: Benson Schliesser
Sent: Tuesday, February 16, 2016 18:14
To: Randy Bush
Cc: opsawg
Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC?

+1 to Randy's observation. 

It's almost as if we value our own opinions more than we value running code...

-Benson


On Tuesday, February 16, 2016, Randy Bush  wrote:
>> One thing to keep in mind is that, if the document describing the
>> currently deployed protocol is informational, we may have a tricky time
>> making the extensions be standards track; it would (presumably) require
>> a downref.
>
> it would; it is not logically a huge problem, merely wierd.
>
> I doubt very much that a push for better securing of an existing mature
> protocol is the likely source of controversy there.

what is amusing is that some folk seem to be contemplating that the
rfc of an old and widely distributed and used protocol should not be
standard.

randy

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



smime.p7s
Description: S/MIME cryptographic signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC?

[Randy Bush]

> Occasionally I wonder if "this problem" is the hill I'm going to
> choose to die on...

sorry you have decided to die.  you'll be missed

randy

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

Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC?

[joel jaeggli]

On 2/16/16 3:08 PM, Randy Bush wrote:
>>> One thing to keep in mind is that, if the document describing the
>>> currently deployed protocol is informational, we may have a tricky time
>>> making the extensions be standards track; it would (presumably) require
>>> a downref. 
>>
>> it would; it is not logically a huge problem, merely wierd.
>>
>> I doubt very much that a push for better securing of an existing mature
>> protocol is the likely source of controversy there.
> 
> what is amusing is that some folk seem to be contemplating that the
> rfc of an old and widely distributed and used protocol should not be
> standard.

Occasionally I wonder if "this problem" is the hill I'm going to choose
to die on... Then I remember I'm at the IETF, and self-restraint
suggests otherwise.

> randy
> 




signature.asc
Description: OpenPGP digital signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC?

[Benson Schliesser]

+1 to Randy's observation.

It's almost as if we value our own opinions more than we value running
code...

-Benson


On Tuesday, February 16, 2016, Randy Bush  wrote:

> >> One thing to keep in mind is that, if the document describing the
> >> currently deployed protocol is informational, we may have a tricky time
> >> making the extensions be standards track; it would (presumably) require
> >> a downref.
> >
> > it would; it is not logically a huge problem, merely wierd.
> >
> > I doubt very much that a push for better securing of an existing mature
> > protocol is the likely source of controversy there.
>
> what is amusing is that some folk seem to be contemplating that the
> rfc of an old and widely distributed and used protocol should not be
> standard.
>
> randy
>
> ___
> 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] Detangling - Q3: Publish TACACS+ as a standards track RFC?

[Randy Bush]

>> One thing to keep in mind is that, if the document describing the
>> currently deployed protocol is informational, we may have a tricky time
>> making the extensions be standards track; it would (presumably) require
>> a downref. 
> 
> it would; it is not logically a huge problem, merely wierd.
> 
> I doubt very much that a push for better securing of an existing mature
> protocol is the likely source of controversy there.

what is amusing is that some folk seem to be contemplating that the
rfc of an old and widely distributed and used protocol should not be
standard.

randy

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

Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC?

[joel jaeggli]

On 2/16/16 12:28 PM, Warren Kumari wrote:
> 
> 
> On Tue, Feb 16, 2016 at 1:57 PM Brian E Carpenter
> > wrote:
> 
> On 16/02/2016 09:16, Warren Kumari wrote:
> > This is the third of 3 messages to determine what the OpsAWG
> should do with
> > TACACS+.
> >
> > If the answer to the previous question is yes, should the RFC
> describing
> > the protocol itself (as opposed to any other document that might
> describe
> > appropriate use) be published as a standards track RFC?
> 
> If it is only an accurate description of the currently deployed
> protocol,
> I couldn't care less whether it's Proposed Standard or Informational, as
> long as the IETF can make derivative works.
> 
> If there are proposed extensions or changes, that should be
> standards track.
> 
> 
> One thing to keep in mind is that, if the document describing the
> currently deployed protocol is informational, we may have a tricky time
> making the extensions be standards track; it would (presumably) require
> a downref. 

it would; it is not logically a huge problem, merely wierd.

I doubt very much that a push for better securing of an existing mature
protocol is the likely source of controversy there.

> W
> 
> 
>Brian
> 
> >
> > Scott, Tianran and Warren
> >
> >
> >
> > ___
> > 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
> 




signature.asc
Description: OpenPGP digital signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Review of "Alternate Tunnel Encapsulation for Data Frames in CAPWAP" - draft-ietf-opsawg-capwap-alt-tunnel

[Warren Kumari]

Dear OpsAWG,

While we have lots of energy / interest, we'd appreciate some additional
review of draft-ietf-opsawg-capwap-alt-tunnel (
https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ ).

This document has an interesting history - it completed WGLC in 2014-08-27
and was submitted to be published as an RFC on 2014-09-08.

We then got draft-you-opsawg-capwap-separation-for-mp, which had some some
significant similarities. We asked the ADs to hold alt-tunnel while
we discussed what to do, and then finally asked the ADs / IESG to return it
to the WG so that these two documents could be merged into one (
https://www.ietf.org/mail-archive/web/opsawg/current/msg04071.html ).

This document has already passed one WGLC (module the minor merging), and
we are waiting on the authors to address some comments (e.g:
https://www.ietf.org/mail-archive/web/opsawg/current/msg04161.html ) and
update the email addresses - once that happens we will do another WGLC --
but, while we are waiting, we'd appreciate any other review and feedback.

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

Re: [OPSAWG] Detangling - Q2: Publish TACACS+ as a RFC?

[Warren Kumari]

On Tue, Feb 16, 2016 at 3:14 PM Christopher Morrow <
christopher.mor...@gmail.com> wrote:

> On Tue, Feb 16, 2016 at 1:53 PM, Brian E Carpenter
>  wrote:
>
> > Yes, it is useful to the community to publish an accurate description
> > of the currently deployed protocol. If that is what the current draft
> > is, go for it, if and only if it does not carry any restriction on
> > derivative works.
>
> I think the derivatives work issue here is based on potential IPR
> claims restricting use of TACACS+ beyond the currently documented (in
> draft) protocol..
>

We are still waiting to hear back from that authors on the explicit IPR
check (
https://mailarchive.ietf.org/arch/msg/opsawg/uJUQ4HfSohtJVV3SrR9Qcdnpn5k) ,
but I should point out that the (boilerplate) starts out with:
"This Internet-Draft is submitted in full conformance with the provisions
of BCP 78 and BCP 79."

Due to the network issues in Prague I was not present at the OpsAREA /
OpsAWG meeting, but at 2:30 in the meeting audio recording Joel brought up
the Note Well, so presumably the authors are aware -- but we'll wait to
hear back on the explicit ACK.

if that's the case then we're sunk :( (as operators who need current
> functionality and want better security properties going forward)


> If we're not sunk by the IPR torpedo, I would like to see the current
> work finished as an RFC, yes.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Detangling - Q2: Publish TACACS+ as a RFC?

[Christopher Morrow]

On Tue, Feb 16, 2016 at 1:53 PM, Brian E Carpenter
 wrote:

> Yes, it is useful to the community to publish an accurate description
> of the currently deployed protocol. If that is what the current draft
> is, go for it, if and only if it does not carry any restriction on
> derivative works.

I think the derivatives work issue here is based on potential IPR
claims restricting use of TACACS+ beyond the currently documented (in
draft) protocol...

if that's the case then we're sunk :( (as operators who need current
functionality and want better security properties going forward)

If we're not sunk by the IPR torpedo, I would like to see the current
work finished as an RFC, yes.

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

Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC?

[Christopher Morrow]

On Tue, Feb 16, 2016 at 1:57 PM, Brian E Carpenter
 wrote:

> If it is only an accurate description of the currently deployed protocol,
> I couldn't care less whether it's Proposed Standard or Informational, as
> long as the IETF can make derivative works.

It seems to me that 'proposed standard' is ok here, provided we outrun
the IPR torpedo.

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

Re: [OPSAWG] Detangling - Q2: Publish TACACS+ as a RFC?

[Brian E Carpenter]

On 16/02/2016 09:14, Warren Kumari wrote:
> Dear OpsAWG:
> 
> This is the second of three messages [0] to determine what the OpsAWG
> should do with TACACS+
> 
> Should the ID, as presented, or as revised by the WG, be published as one
> or more RFCs?

I find it impossible to answer this in a binary fashion, unfortunately.

Yes, it is useful to the community to publish an accurate description
of the currently deployed protocol. If that is what the current draft
is, go for it, if and only if it does not carry any restriction on
derivative works.

No, it is not useful to publish a description of the currently deployed
protocol mixed with proposed extensions. If that is what the current
draft is, split it.

   Brian

> 
> Scott, Tianran and Warren
> 
> [0]: The first one was the IPR one ( "Untangling - Explicit call for IPR on
> draft-ietf-opsawg-tacacs-00")
> 
> 
> 
> ___
> 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] Detangling - Q3: Publish TACACS+ as a standards track RFC?

[Brian E Carpenter]

On 16/02/2016 09:16, Warren Kumari wrote:
> This is the third of 3 messages to determine what the OpsAWG should do with
> TACACS+.
> 
> If the answer to the previous question is yes, should the RFC describing
> the protocol itself (as opposed to any other document that might describe
> appropriate use) be published as a standards track RFC?

If it is only an accurate description of the currently deployed protocol,
I couldn't care less whether it's Proposed Standard or Informational, as
long as the IETF can make derivative works.

If there are proposed extensions or changes, that should be standards track.

   Brian

> 
> Scott, Tianran and Warren
> 
> 
> 
> ___
> 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] Detangling - Q3: Publish TACACS+ as a standards track RFC?

[Alan DeKok]

On Feb 15, 2016, at 3:16 PM, Warren Kumari  wrote:
> 
> This is the third of 3 messages to determine what the OpsAWG should do with 
> TACACS+.
> 
> If the answer to the previous question is yes, should the RFC describing the 
> protocol itself (as opposed to any other document that might describe 
> appropriate use) be published as a standards track RFC?

  I would say "No".

  I'll repeat my reasoning here.

  I support publishing "historical TACACS+" as an informational RFC.  That 
makes it clear the protocol was developed outside of the IETF, and not under 
IETF change control.  Despite external people not differentiating between 
"informational" and "standards track", the IETF process does make that 
differentiation.  If we are to follow the process, we should follow the process.

  I believe any discussion of TACACS+ MUST remove all discussion of it as an 
"AAA protocol".  If it's an AAA protocol, then the requirements for AAA 
protocols should apply.  If (as many proponents claim), it's not an AAA 
protocol, then the requirements for AAA protocols shouldn't apply.  But the 
document then MUST NOT describe itself as an AAA protocol.

  I support publishing the "future TACACS+" as a standards track RFC.  But I 
think this work should be done outside of OPSAWG.

  New management protocols are not a "small, highly focused projects that don't 
merit a WG of their own".  They require special adoption processes due to the 
enormous costs they impose on the industry.

  If, on the other hand, OPSAWG published a standards track document titled 
"TLS transport profile for legacy network management protocols", that would 
fall within the charter.

  But defining a new (to the IETF and the world) network management protocol is 
entirely outside of the scope of OPSAWG.

  Or, if (as many people say) the protocol isn't new, then OPSAWG won't be 
making any changes to TACACS+.  It can't both be under IETF change control, and 
at the same time, 100% historical TACACS+ and nothing more.

  Alan DeKok.

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

Re: [OPSAWG] Detangling - Q2: Publish TACACS+ as a RFC?

[Alan DeKok]

On Feb 15, 2016, at 3:14 PM, Warren Kumari  wrote:
> 
> Dear OpsAWG:
> 
> This is the second of three messages [0] to determine what the OpsAWG should 
> do with TACACS+
> 
> Should the ID, as presented, or as revised by the WG, be published as one or 
> more RFCs?

  I'll say a guarded yes.

  I have previously explained my preferences for how this work should go 
forward.  I won't repeat them here.

  I'll also echo t.petch's concerns.

  There has been no discussion about TACACS+ implementations.  i.e. does the 
draft accurately document the protocol as it exists today?  We don't know.

  It would be good to get feedback from implementors as to whether or not the 
document is correct on it's technical content.  I see that information as 
critical to have.

  Alan DeKok.

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

Re: [OPSAWG] automatic attachment of applications and services at the edge

[Romascanu, Dan (Dan)]

Hi Joel,

This is correct. Legacy devices or devices constrained in resources (think IoT) 
would have a problem to implement ISIS and the full signaling stack. The 
proposed solution requires them only to support LLDP or some other one-hop 
auto-attach protocol. 

Regards,

Dan


> -Original Message-
> From: joel jaeggli [mailto:joe...@bogus.com]
> Sent: Tuesday, February 16, 2016 8:05 AM
> To: Romascanu, Dan (Dan); opsawg@ietf.org
> Cc: Unbehagen Jr, Paul E (Paul)
> Subject: Re: [OPSAWG] automatic attachment of applications and services at
> the edge
> 
> Am I correct in understanding that the goal is to not have to implment spb on
> the client device? so this takes the place of an isis implementation that 
> would
> do the signaling per 802.1aq.
> 
> On 2/15/16 7:09 AM, Romascanu, Dan (Dan) wrote:
> > Hi,
> >
> >
> >
> > I would like to draw the attention of the participants in the OPSAWG
> > on an individual submission that I am co-authoring. The problem we are
> > trying to solve is the optimization / minimizing of the amount of
> > configuration that an operator needs to do when new applications
> > require the creation of paths or tunnels in the core network. In order
> > to avoid the reconfiguration of the core or heavy configuration at the
> > edge the proposed method which we call auto-attachment allows for the
> > usage of a protocol running between the end stations and the first
> > (edge) router that adds the information and characteristics of the new
> > path according to the policies or mapping tables of the operators. A
> > first implementation that we have running code for and is deployed is
> > described in
> > https://datatracker.ietf.org/doc/draft-unbehagen-lldp-spb/
> > and uses the Link Layer Discovery Protocol (LLDP) with an IEEE 802.1aq
> > Shortest Path Bridging (SPB) network.
> >
> >
> >
> > Please have a look and let me know if there is interest and/or similar
> > on-going work. If there is enough interest I plan to request a short
> > slot to discuss the idea at the OPSAWG meeting at IETF 95.
> >
> >
> >
> > Thanks and Regards,
> >
> >
> >
> > Dan
> >
> >
> >
> >
> >
> > ___
> > 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] Detangling - Q3: Publish TACACS+ as a standards track RFC?

[Eliot Lear]

Chairs,

On 2/15/16 9:16 PM, Warren Kumari wrote:
> This is the third of 3 messages to determine what the OpsAWG should do
> with TACACS+.
>
> If the answer to the previous question is yes, should the RFC
> describing the protocol itself (as opposed to any other document that
> might describe appropriate use) be published as a standards track RFC?
>
I believe the answer to this question should at least initially be
“yes”.  If the WG comes to determine that the result is so disparate
that an informational document describing what is currently deployed is
also required, we can do that later.  My logic is quite simple: there
may not be energy for two documents, and the changes may be simple
enough to effect in common implementations that a second document may
not be necessary.

Eliot



signature.asc
Description: OpenPGP digital signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg