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

[Alan DeKok]

> On Apr 6, 2016, at 12:46 PM, Christopher Morrow 
>  wrote:
> 
> ​(I hate to resurrect an old thread. but)​
> 
> On Mon, Feb 22, 2016 at 10:37 AM, Alan DeKok  
> wrote:
>   And since TACACS+ is largely used *within* the enterprise, the issue of 
> securing it is less relevant than (say) RADIUS, which is used across the 
> wider internet.
> 
> ​This is flat wrong. Tac+ is used across the wide-area, both within a single 
> routing administrative domain (Autonomous system, single company network)

  As I said.

> and wit​hout.

  That which is asserted without evidence can be dismissed without evidence.

  I'll note that the existing document doesn't describe this scenario at all.  
So you're asserting (again) that we should be standardizing TACACS+ because of 
use-cases which are so important that they're not even mentioned in the 
document.  Or on this mailing list, so far as I've been able to find.

  I find blind assertions entirely unconvincing.

  Alan DeKok.

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

​(I hate to resurrect an old thread. but)​

On Mon, Feb 22, 2016 at 10:37 AM, Alan DeKok 
wrote:

>   And since TACACS+ is largely used *within* the enterprise, the issue of
> securing it is less relevant than (say) RADIUS, which is used across the
> wider internet.


​This is flat wrong. Tac+ is used across the wide-area, both within a
single routing administrative domain (Autonomous system, single company
network) and wit​hout.

-chris
___
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 22, 2016, at 10:02 AM, Robert Drake  wrote:
> That seems like something you need to worry about no matter what the protocol 
> is or where it originally came from.  If a company wants to torpedo the 
> standards process then they've always got lawyers.  It doesn't matter how 
> silly their claim is, they can tie it up in lawsuits for years.

  True.

> The flip side to this is, if the IETF drags out this fight for too long, I 
> could see major vendors making their own efforts to secure the protocol prior 
> to anyone making a standard (possibly because a large customer demands the 
> protocol be secured for whatever reason).  If that happens, we might be stuck 
> with TACACS+TLS from one vendor that doesn't interoperate with 
> TACACS+blowfish from another (hopefully all with the ability to fallback to 
> the defacto standard if needed.. or perhaps we just run 3 separate servers 
> with different extensions to support multiple vendors..)
> 
> Maybe not.  It's been 20 years.  It's possible it's just too obscure to worry 
> about, but we won't know until it happens.

  I think since TACACS+ has waited 20+ years for standardization, it's worth 
waiting a few more months to be sure we get it right.

  And since TACACS+ is largely used *within* the enterprise, the issue of 
securing it is less relevant than (say) RADIUS, which is used across the wider 
internet.

  Alan DeKok.

___
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 19, 2016, at 12:40 PM, Eliot Lear  wrote:
> My suggestion is that working group consensus (not any particular 
> individual's or company's point of view) determine what is in a proposed 
> standard.  Operational experience with what is running is going to dictate 
> what many people believe should and should not be in in that doc.  Whether 
> there is an informational document won't change this.  That's a good thing.  
> If someone said we should rewrite TACACS+ to use  EBCDIC encoding, for 
> instance, I'm pretty sure you'd see a lot of people complain.  If the WG 
> diverges substantially from what is running code, then two documents seem 
> called for.  But I don't see that we've crossed that bridge yet.

  Adding TLS is a substantial divergence, IMHO.  There are no TACACS+ servers 
I'm aware of which implement TLS.

  Why not document TACACS+ as a historical protocol, and then "TLS transport 
for legacy network admin protocols"?  If the changes are minor, then the TLS 
document is minor.

  If the work to add TLS is not minor, then I think that would fall under the 
rubric of it "diverges substantially from what is running code, then two 
documents seem called for."

  I'd like to just pick one path forward, and be done with it.  But the reasons 
for doing things change, depending on who's answering, and what the question 
is.  To me, this indicates that not only we don't have WG consensus on the 
document(s), but that the people *proposing* the document(s) can't even reach 
consensus among themselves as to what they're proposing.

  Alan DeKok.

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

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

[Robert Drake]

On 2/19/2016 11:39 AM, t.petch wrote:

So until it is, or is just about to be, an RFC, I don't know whether or
not a technology will be encumbered by an IPR claim and I know of
nothing that the participants can say to allay my concerns (the
company's lawyers might be able to:-).


That seems like something you need to worry about no matter what the 
protocol is or where it originally came from.  If a company wants to 
torpedo the standards process then they've always got lawyers.  It 
doesn't matter how silly their claim is, they can tie it up in lawsuits 
for years.


The only thing we have to fight back is the threat to walk away from 
them as a customer if they don't use a standard for this.  Honestly, 
I've got enough troubles trying to get vendors to adopt tacacs+ without 
someone adding proprietary extensions.  If they want to try it I can see 
us staying on the existing tacacs+ for another 20 years.


The flip side to this is, if the IETF drags out this fight for too long, 
I could see major vendors making their own efforts to secure the 
protocol prior to anyone making a standard (possibly because a large 
customer demands the protocol be secured for whatever reason).  If that 
happens, we might be stuck with TACACS+TLS from one vendor that doesn't 
interoperate with TACACS+blowfish from another (hopefully all with the 
ability to fallback to the defacto standard if needed.. or perhaps we 
just run 3 separate servers with different extensions to support 
multiple vendors..)


Maybe not.  It's been 20 years.  It's possible it's just too obscure to 
worry about, but we won't know until it happens.

Tom Petch

Robert

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

Hi Andy,

On 2/19/16 2:09 AM, Andy Bierman wrote:
>
> It is not that clear from the discussions where "documenting a
> proprietary protocol" ends
> and "WG makes whatever changes and additions they want" begins.
> It is not clear how much backward compatibility with existing
> implementations is expected.
>

I understand your concern. 

My suggestion is that working group consensus (not any particular
individual's or company's point of view) determine what is in a proposed
standard.  Operational experience with what is running is going to
dictate what many people believe should and should not be in in that
doc.  Whether there is an informational document won't change this. 
That's a good thing.  If someone said we should rewrite TACACS+ to use 
EBCDIC encoding, for instance, I'm pretty sure you'd see a lot of people
complain.  If the WG diverges substantially from what is running code,
then two documents seem called for.  But I don't see that we've crossed
that bridge yet.

Eliot



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?

[William Herrin]

On Thu, Feb 18, 2016 at 10:04 PM, Brian E Carpenter
 wrote:
> We have no way to
> know what a company's true intentions are or to know whether they
> will stick to those intentions, whatever some employees might say.

Hi Brian,

Respectfully, every company is capable of communicating its official
intentions and designating employees authorized to do so. Whether
they're likely to renege later is, I agree, an issue we can't
reasonably consider.

> So I don't think these hypotheticals about possible futures affect
> the decision to be taken now, which is, for once, genuinely about
> rough consensus and running code.

Creating a derivative work of a vendor's product while keeping the
vendor's product name without the vendor's express consent? That's
solely and genuinely about rough consensus and running code?
Seriously?

Gain the vendor's formal consent to take over the standard.
Derive a new work from the vendor's standard under a different,
readily distinguished name.
Produce an informational RFC documenting the vendor's standard without change.

Depending on your goals, you have at least three satisfactory paths
forward. Why insist on an objectionable path instead?

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

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

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

[t . petch]

- Original Message -
From: "Brian E Carpenter" 
To: 
Sent: Thursday, February 18, 2016 11:56 PM
> On 19/02/2016 10:25, William Herrin wrote:
> > On Thu, Feb 18, 2016 at 10:28 AM, joel jaeggli 
wrote:
> >> On 2/18/16 7:18 AM, William Herrin wrote:
> >>> In my opinion, IETF standards track RFCs should be reserved for
> >>> protocols for which further development is expected to occur
primarily
> >>> within the IETF framework. As I understand the situation (feel
free to
> >>> correct me if I'm wrong), TACACS+ is a vendor maintained standard,
> >>> specifically Cisco. Regardless of publication, Cisco intends to
retain
> >>> control of the standard and its future development.
> >>
> >> Assuming the document is split into to pieces here part of goal as
I
> >> understand it is address the issue of adding ssl to the existing
> >> specification in an inter-operable fashion.
> >
> > Hi Joel,
> >
> > Is Cisco prepared to cede further change control of the core TACACS+
> > standard to the IETF process?
>
> The IETF deals with individual contributors, not companies. As Scott
noted,
> the authors have already given change control to the IETF by
submitting a
> draft with the appropriate boilerplate.

And what I have seen more than once is a large, American company, which
shares an e-mail domain with IETF participants who have actively worked
on an I-D, submit an IPR claim late in the day.  When asked, the
participants have explained that American law is such that companies aim
to keep participants in the dark about possible IPR claims.  So the
participants have honestly and accurately answered all the questions
about IPR and yet the company (with the same e-mail domain) has put in a
late claim.

So until it is, or is just about to be, an RFC, I don't know whether or
not a technology will be encumbered by an IPR claim and I know of
nothing that the participants can say to allay my concerns (the
company's lawyers might be able to:-).

Tom Petch

> Of course, what any company chooses to actually implement is their own
> business.
>
>Brian
>
>

___
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/18/16 5:09 PM, Andy Bierman wrote:
> 
> 
> On Thu, Feb 18, 2016 at 4:52 PM, Randy Bush  > wrote:
> 
> > I think in order for WG consensus to determine decisions wrt/ this
> > document, it would no longer be a Cisco protocol.  Cisco would have to
> > give all change control authority to the IETF.
> 
> andy, you have been around for a while.  where did you get the idea it
> was otherwise in the case of this document?
> 
> 
> It is not that clear from the discussions where "documenting a
> proprietary protocol" ends
> and "WG makes whatever changes and additions they want" begins.
> It is not clear how much backward compatibility with existing
> implementations is expected.
> 
> If the WG was starting with a set of requirements, and was open to multiple
> solution proposals, this would look more like a standards effort to me.

I'm not sure that imposing a particular model on standards work as a
whole rather than in specific is appropriate. Sometimes we draw
explicitly on sources that are already or largely fully formed on
arrival, sometimes we do not; sometimes we do waterfalls, in particular
if we need to converge, and some times we don't. We need to be fairly
careful to avoid a generalization that doesn't apply to some or a large
part of our efforts. On the Ops side of things we tend to be working
with and abundance of pre-existing work.

> Working backwards from running code seems like more of an Informational
> RFC task.
> 
>  
> 
> this is just another ietf document.  it happens to document a protocol
> used by many operators on many vendors' equipment.  where does all this
> ipr, proprietary, ... paranoia come from?  [ that was a rhetorical
> question; no need to answer ]
> 
> randy
> 
> 
> Andy
>  
> 
> 
> 
> ___
> 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

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

[Brian E Carpenter]

On 19/02/2016 13:56, William Herrin wrote:
> On Thu, Feb 18, 2016 at 6:56 PM, Brian E Carpenter
>  wrote:
>> On 19/02/2016 10:25, William Herrin wrote:
>>> Is Cisco prepared to cede further change control of the core TACACS+
>>> standard to the IETF process?
>>
>> The IETF deals with individual contributors, not companies. As Scott noted,
>> the authors have already given change control to the IETF by submitting a
>> draft with the appropriate boilerplate.
>>
>> Of course, what any company chooses to actually implement is their own
>> business.
> 
> With due respect Brian, you're talking past the issue. If Cisco, the
> company, intends to back away from maintaining the core TACACS+
> standard in favor of the IETF's process then I see no problem with
> bringing the protocol into the IETF process. If not, then only sorrow
> will come from the IETF creating a _competing standard with the same
> name_.

Yes, logically, those statements are true. But we have no way to
know what a company's true intentions are or to know whether they
will stick to those intentions, whatever some employees might say.
So I don't think these hypotheticals about possible futures affect
the decision to be taken now, which is, for once, genuinely about
rough consensus and running code.

otoh not many companies would want to knowingly market a product that
has the same name as an IETF standard but does not conform to that
standard.

OK, the bikeshed now has enough different colour samples on it that we
should stop.

Brian

___
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 Thu, Feb 18, 2016 at 4:52 PM, Randy Bush  wrote:

> > I think in order for WG consensus to determine decisions wrt/ this
> > document, it would no longer be a Cisco protocol.  Cisco would have to
> > give all change control authority to the IETF.
>
> andy, you have been around for a while.  where did you get the idea it
> was otherwise in the case of this document?
>
>
It is not that clear from the discussions where "documenting a proprietary
protocol" ends
and "WG makes whatever changes and additions they want" begins.
It is not clear how much backward compatibility with existing
implementations is expected.

If the WG was starting with a set of requirements, and was open to multiple
solution proposals, this would look more like a standards effort to me.
Working backwards from running code seems like more of an Informational RFC
task.




> this is just another ietf document.  it happens to document a protocol
> used by many operators on many vendors' equipment.  where does all this
> ipr, proprietary, ... paranoia come from?  [ that was a rhetorical
> question; no need to answer ]
>
> randy
>

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

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

[William Herrin]

On Thu, Feb 18, 2016 at 6:56 PM, Brian E Carpenter
 wrote:
> On 19/02/2016 10:25, William Herrin wrote:
>> Is Cisco prepared to cede further change control of the core TACACS+
>> standard to the IETF process?
>
> The IETF deals with individual contributors, not companies. As Scott noted,
> the authors have already given change control to the IETF by submitting a
> draft with the appropriate boilerplate.
>
> Of course, what any company chooses to actually implement is their own
> business.

With due respect Brian, you're talking past the issue. If Cisco, the
company, intends to back away from maintaining the core TACACS+
standard in favor of the IETF's process then I see no problem with
bringing the protocol into the IETF process. If not, then only sorrow
will come from the IETF creating a _competing standard with the same
name_.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

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

> I think in order for WG consensus to determine decisions wrt/ this
> document, it would no longer be a Cisco protocol.  Cisco would have to
> give all change control authority to the IETF.  

andy, you have been around for a while.  where did you get the idea it
was otherwise in the case of this document?

this is just another ietf document.  it happens to document a protocol
used by many operators on many vendors' equipment.  where does all this
ipr, proprietary, ... paranoia come from?  [ that was a rhetorical
question; no need to answer ]

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?

[Brian E Carpenter]

On 19/02/2016 10:25, William Herrin wrote:
> On Thu, Feb 18, 2016 at 10:28 AM, joel jaeggli  wrote:
>> On 2/18/16 7:18 AM, William Herrin wrote:
>>> In my opinion, IETF standards track RFCs should be reserved for
>>> protocols for which further development is expected to occur primarily
>>> within the IETF framework. As I understand the situation (feel free to
>>> correct me if I'm wrong), TACACS+ is a vendor maintained standard,
>>> specifically Cisco. Regardless of publication, Cisco intends to retain
>>> control of the standard and its future development.
>>
>> Assuming the document is split into to pieces here part of goal as I
>> understand it is address the issue of adding ssl to the existing
>> specification in an inter-operable fashion.
> 
> Hi Joel,
> 
> Is Cisco prepared to cede further change control of the core TACACS+
> standard to the IETF process? 

The IETF deals with individual contributors, not companies. As Scott noted,
the authors have already given change control to the IETF by submitting a
draft with the appropriate boilerplate.

Of course, what any company chooses to actually implement is their own
business.

   Brian

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

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

[William Herrin]

On Thu, Feb 18, 2016 at 10:28 AM, joel jaeggli  wrote:
> On 2/18/16 7:18 AM, William Herrin wrote:
>> In my opinion, IETF standards track RFCs should be reserved for
>> protocols for which further development is expected to occur primarily
>> within the IETF framework. As I understand the situation (feel free to
>> correct me if I'm wrong), TACACS+ is a vendor maintained standard,
>> specifically Cisco. Regardless of publication, Cisco intends to retain
>> control of the standard and its future development.
>
> Assuming the document is split into to pieces here part of goal as I
> understand it is address the issue of adding ssl to the existing
> specification in an inter-operable fashion.

Hi Joel,

Is Cisco prepared to cede further change control of the core TACACS+
standard to the IETF process? I have no objection to the IETF
absorbing, standardizing and improving the TACACS+ protocol if that is
the vendor's desire. I would not want to see multiple standards bodies
in control of different little bits of the TACACS+ standard. I think
that would sow needless confusion among the folks trying to work with
it.

I respectfully observe that should Cisco wish to retain control of the
core TACACS+ standard, nothing prevents them from adopting a consensus
recommendation for security improvements into the standard without any
need for IETF publication. In such situations, IETF publication offers
little more than bragging rights.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

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

as requested:

the IETF requires the ability to make directive works and the submission of of 
the ID 
for publication did that 

the IETF does not require (but likes to have ) “change control” on the 
underlying technology
where the originating company agrees to not further develop a branch of the 
technology 
and call it by the same name - we have only officially gotten that in a very 
few cases
(e.g. NFS - see RFC 1790) The IETF did not even get change control in the case 
of
MPLS (a.k.a Tag Switching) but did go right ahead and develop MPLS

so in almost all cases the IETF proceeds with the assurance by the authors of 
an ID that they
have the right to contribute the text to the IETF 

note that any patent issues are completely separate from the copyright and 
“change control”

Scott

> On Feb 18, 2016, at 3:02 PM, Andy Bierman  wrote:
> 
> 
> 
> On Thu, Feb 18, 2016 at 7:18 AM, William Herrin  wrote:
> On Mon, Feb 15, 2016 at 3:16 PM, Warren Kumari  wrote:
> > 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?
> 
> Greetings,
> 
> In my opinion, IETF standards track RFCs should be reserved for
> protocols for which further development is expected to occur primarily
> within the IETF framework. As I understand the situation (feel free to
> correct me if I'm wrong), TACACS+ is a vendor maintained standard,
> specifically Cisco. Regardless of publication, Cisco intends to retain
> control of the standard and its future development.
> 
> 
> 
> I think in order for WG consensus to determine decisions wrt/ this document,
> it would no longer be a Cisco protocol.  Cisco would have to give all change 
> control
> authority to the IETF.  Maybe an expert on IETF process (like Scott) can 
> clarify.
> 
> 
> Andy
> 
> 
> If my understanding is correct, TACACS+ should not be presented as an
> IETF standards track RFC.
> 
> I would remind folks that it's perfectly OK for a network protocol to
> be a standard without it being an _IETF_ standard.
> 
> Regards,
> Bill Herrin
> 
> --
> William Herrin  her...@dirtside.com  b...@herrin.us
> Owner, Dirtside Systems . Web: 
> 
> ___
> 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?

[Joel Jaeggli]

Sent from my iPhone

> On Feb 18, 2016, at 12:08, Eliot Lear  wrote:
> 
> 
> 
>> On 2/18/16 9:02 PM, Andy Bierman wrote:
>> 
>> I think in order for WG consensus to determine decisions wrt/ this
>> document,
>> it would no longer be a Cisco protocol.  Cisco would have to give all
>> change control
>> authority to the IETF.  Maybe an expert on IETF process (like Scott)
>> can clarify.
> 
> That is the deal, no matter the vendor, when something becomes an IETF
> standard.  And this is why I say, let's see where we land before having
> to cough up two documents, when one might do just fine.

When we say something is adopted by the working group indeed the working group 
now has change control. Thier is bit of give and take required to bring work 
here.
> 
> Eliot
> 
> 
> ___
> 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]

On 2/18/16 9:02 PM, Andy Bierman wrote:
>
> I think in order for WG consensus to determine decisions wrt/ this
> document,
> it would no longer be a Cisco protocol.  Cisco would have to give all
> change control
> authority to the IETF.  Maybe an expert on IETF process (like Scott)
> can clarify.
>

That is the deal, no matter the vendor, when something becomes an IETF
standard.  And this is why I say, let's see where we land before having
to cough up two documents, when one might do just fine.

Eliot




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?

[Andy Bierman]

On Thu, Feb 18, 2016 at 7:18 AM, William Herrin  wrote:

> On Mon, Feb 15, 2016 at 3:16 PM, Warren Kumari  wrote:
> > 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?
>
> Greetings,
>
> In my opinion, IETF standards track RFCs should be reserved for
> protocols for which further development is expected to occur primarily
> within the IETF framework. As I understand the situation (feel free to
> correct me if I'm wrong), TACACS+ is a vendor maintained standard,
> specifically Cisco. Regardless of publication, Cisco intends to retain
> control of the standard and its future development.
>
>

I think in order for WG consensus to determine decisions wrt/ this document,
it would no longer be a Cisco protocol.  Cisco would have to give all
change control
authority to the IETF.  Maybe an expert on IETF process (like Scott) can
clarify.


Andy


If my understanding is correct, TACACS+ should not be presented as an
> IETF standards track RFC.
>
> I would remind folks that it's perfectly OK for a network protocol to
> be a standard without it being an _IETF_ standard.
>
> Regards,
> Bill Herrin
>
> --
> William Herrin  her...@dirtside.com  b...@herrin.us
> Owner, Dirtside Systems . Web: 
>
> ___
> 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?

[joel jaeggli]

On 2/18/16 7:18 AM, William Herrin wrote:
> On Mon, Feb 15, 2016 at 3:16 PM, Warren Kumari  wrote:
>> 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?
> 
> Greetings,
> 
> In my opinion, IETF standards track RFCs should be reserved for
> protocols for which further development is expected to occur primarily
> within the IETF framework. As I understand the situation (feel free to
> correct me if I'm wrong), TACACS+ is a vendor maintained standard,
> specifically Cisco. Regardless of publication, Cisco intends to retain
> control of the standard and its future development.

Assuming the document is split into to pieces here part of goal as I
understand it is address the issue of adding ssl to the existing
specification in an inter-operable fashion.

> If my understanding is correct, TACACS+ should not be presented as an
> IETF standards track RFC.
>
> I would remind folks that it's perfectly OK for a network protocol to
> be a standard without it being an _IETF_ standard.
> 
> Regards,
> Bill Herrin
> 




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?

[William Herrin]

On Mon, Feb 15, 2016 at 3:16 PM, Warren Kumari  wrote:
> 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?

Greetings,

In my opinion, IETF standards track RFCs should be reserved for
protocols for which further development is expected to occur primarily
within the IETF framework. As I understand the situation (feel free to
correct me if I'm wrong), TACACS+ is a vendor maintained standard,
specifically Cisco. Regardless of publication, Cisco intends to retain
control of the standard and its future development.

If my understanding is correct, TACACS+ should not be presented as an
IETF standards track RFC.

I would remind folks that it's perfectly OK for a network protocol to
be a standard without it being an _IETF_ standard.

Regards,
Bill Herrin

-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Owner, Dirtside Systems . Web: 

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

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

[Stefan Winter]

Hello,

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

That's a trick question; "the protocol itself" definition is what is
under debate right now.

Is "the protocol itself" TACACS+ as deployed today?

Or is it TACACS+ with additions?

If the former: No, it should be Informational.

If the latter: My answer to Question 2 is now a No.

Greetings,

Stefan


-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66


0x8A39DC66.asc
Description: application/pgp-keys


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?

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

[joel jaeggli]

On 2/16/16 3:24 PM, Randy Bush wrote:
>> 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

HWÆT, WE GAR-DEna in geardagum,
þeodcyninga þrym gefrunon,
hu ða æþelingas ellen fremedon!
oft Scyld Scefing sceaþena þreatum,
monegum mægþum meodosetla ofteah,
egsode eorlas, syððanærest wearð
feasceaft funden; he þæs frofre gebad,
weox under wolcnum weorðmyndum þah,
oð þæt him æghwylc ymbsittendra
ofer hronrade hyran scolde,
gomban gyldan; þæt wæs god cyning!

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

[Alan DeKok]

On Feb 16, 2016, at 6:14 PM, Benson Schliesser  wrote:
> 
> +1 to Randy's observation. 
> 
> It's almost as if we value our own opinions more than we value running code...

  I suggest posting links to the mailing list archives where someone suggests 
that the document be published as *only* an informational RFC.  Failing that, 
publicly withdrawing this claim.

  The only record of someone wanting *only* an informational RFC was me at the 
mic in Prague.  Discussions since then have convinced me to change my mind.  
Which I've stated publicly, for anyone who cares to read my messages.

  The discussions in the last month have been around publishing (a) just a 
standards track RFC, or (b) a standards track RFC and an informational RFC.

  I'm still surprised at the level of vitriol, contradictory logic, and just 
plain false statements being made here.  I find such "arguments" entirely 
unconvincing.

  Alan DeKok.

___
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
> mailto:brian.e.carpen...@gmail.com>> 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

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

[Warren Kumari]

On Tue, Feb 16, 2016 at 1:57 PM Brian E Carpenter <
brian.e.carpen...@gmail.com> 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.

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

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

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

[Tassos Chatzithomaoglou]

Yes

--
Tassos

Warren Kumari wrote on 15/2/16 22:16:
> 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?
>
> 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?

[Robert Drake]

On 2/15/2016 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?

Yes




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?

[Randy Bush]

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

it is a deployed and widely used protocol.  this question is silly.  of
course it should be standards track.

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?

[Edwin Mallette]

Yes.

From:  OPSAWG  on behalf of Warren Kumari

Date:  Monday, February 15, 2016 at 12:16 PM
To:  "opsawg@ietf.org" 
Subject:  [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track
RFC?

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?

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?

[Joe Clarke]

On 2/15/16 15: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?


I would rather see it be a standard, but I would be perfectly happy to 
see it published, in the current implementation, as an informational RFC 
(as stated in my previous answer).


In either event, I feel this work should continue, especially the 
security enhancements.


Joe

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