Subject: [OPSAWG] FW: New Version Notification for draft-pularikkal-opsawg-lawful-intercept-spwifi-00.txt

From: "Byju Pularikkal (byjupg)" <[email-masked]>
Date: Mon, 18 Feb 2013 21:11:00 +0000

Hello 

Attached is a document on LI Architecture for SP Wi-Fi. Comments
appreciated,

Thanks & Regards

Byju

On 2/18/13 3:15 PM, "[email-masked]" <[email-masked]>
wrote:

>
>A new version of I-D,
>draft-pularikkal-opsawg-lawful-intercept-spwifi-00.txt
>has been successfully submitted by Byju Pularikkal and posted to the
>IETF repository.
>
>Filename:	 draft-pularikkal-opsawg-lawful-intercept-spwifi
>Revision:	 00
>Title:		 Lawful-Intercept Support for SP Wi-Fi Deployments
>Creation date:	 2013-02-18
>Group:		 Individual Submission
>Number of pages: 20
>URL:             
>http://www.ietf.org/internet-drafts/draft-pularikkal-opsawg-lawful-interce
>pt-spwifi-00.txt
>Status:          
>http://datatracker.ietf.org/doc/draft-pularikkal-opsawg-lawful-intercept-s
>pwifi
>Htmlized:        
>http://tools.ietf.org/html/draft-pularikkal-opsawg-lawful-intercept-spwifi
>-00
>
>
>Abstract:
>   Lawful Intercept stands for legally authorized capture & delivery of
>   subscriber communications data by a communications provider to a law
>   enforcement agency.This document describes Generic Lawful Intercept
>   Architecture Models & implementation considerations for Service
>   Provider Wi-Fi deployments.
>
>                  
>        
>
>
>The IETF Secretariat
>

---

From: joel jaeggli <[email-masked]>
Date: Mon, 18 Feb 2013 20:14:49 -0800

> Attached is a document on LI Architecture for SP Wi-Fi. Comments
The document makes no mention of RFC 2804. It would be helpful if the 
authors would indicate that they are mindful of that especially 
vis-a-vis intended status, document progression and so forth.
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 19 Feb 2013 05:39:19 +0000

Hi Joel,

I think this is a good point. We had few discussions with Fred Baker as
well on this aspect. RFC-2804 was written 13 years back, many things have
changed since then. Operators deploying SP WIFI networks now have an
obligation to meet the regulatory requirement and the burden is on IETF to
provide solutions that they can deploy. The goal of the document is more
written from an operator perspective. Hopefully we can identify
considerations from both privacy and regulatory compliance point of view.

Regards
Sri

---

From: "Byju Pularikkal (byjupg)" <[email-masked]>
Date: Tue, 19 Feb 2013 06:16:56 +0000

Just to add to Sri's comments,

I think we need to reconsider the position IETF has taken so far on LI
standardization efforts.

Lack of standardization makes it often difficult for the Operators to
implement a vendor inter-operable solution around LI. I agree Mediation
Device vendors typically accommodate most of the vendor specific LI
implementations for IAP to MD interfaces. But this is not always the case.

Regards

Byju

On 2/19/13 12:39 AM, "Sri Gundavelli (sgundave)" <[email-masked]>
wrote:

>>>>http://www.ietf.org/internet-drafts/draft-pularikkal-opsawg-lawful-inte
>>>>r
>>>>ce
>>>> pt-spwifi-00.txt
>>>> Status:
>>>> 
>>>>http://datatracker.ietf.org/doc/draft-pularikkal-opsawg-lawful-intercep
>>>>t
>>>>-s
>>>> pwifi
>>>> Htmlized:
>>>> 
>>>>http://tools.ietf.org/html/draft-pularikkal-opsawg-lawful-intercept-spw
>>>>i
>>>>fi
>>>> -00
>>>>
>>>>
>>>> Abstract:

---

From: Melinda Shore <[email-masked]>
Date: Mon, 18 Feb 2013 21:24:17 -0900

> I think we need to reconsider the position IETF has taken so far on LI

To be honest, at the time I thought it was a bad idea, but
what's done is done.  I do not think that revisiting it right
now is likely to be productive, and at any rate it could
take several years.  In the meantime there are alternatives
to standards track publication that could allow publication
of the document (assuming it gets through the process)
without having to deal with the 2804 impediment.

Melinda

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Feb 2013 08:03:49 +0000

On 19/02/2013 05:39, Sri Gundavelli (sgundave) wrote:
> changed since then. 

The IETF's policy has not changed since then. The arguments we went through
in 1999/2000 have not changed since then.

The policy is quite short, but to extract two key points:

>    The IETF has decided not to consider requirements for wiretapping as
>    part of the process for creating and maintaining IETF standards.

>    - On the other hand, the IETF believes that mechanisms designed to
>      facilitate or enable wiretapping, or methods of using other
>      facilities for such purposes, should be openly described,

An example of the latter is RFC 3924. You can describe a solution, but
the IETF will not standardise it.

   Brian

---

From: Benoit Claise <[email-masked]>
Date: Tue, 19 Feb 2013 14:52:30 +0100

> the IETF will not standardise it.
Correct.

Regards, Benoit

---

From: "Byju Pularikkal (byjupg)" <[email-masked]>
Date: Tue, 19 Feb 2013 18:59:03 +0000

Hi Melinda

Thanks for your comments. Alternative to standards track probably is an
option which will help us for the time being.

Regards

Byju

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 19 Feb 2013 19:18:08 +0000

>the IETF will not standardise it.

Its probably time for IETF to re-visit that decision, I say this in all
humbleness. But, my goal is not to battle that. We want solution documents
that operators can use it as basis when deploying IETF protocols, in this
case for SP WIFI. May be as you and Melinda pointed out, documentation in
some form on the LI architecture identifying all considerations is some
thing that operators can live with Š

Regards
Sri

---

From: joel jaeggli <[email-masked]>
Date: Tue, 19 Feb 2013 11:31:52 -0800

On 2/19/13 11:18 AM, Sri Gundavelli (sgundave) wrote:
> humbleness. But, my goal is not to battle that.
I don't view that as a battle.

We have a policy, if we want to change it we set out to change it. Until 
then however, the present policy applies. we have evidence that it's 
fairly broadly supported so you can imagine the IESG as custodians will 
apply the policy as it stands.
>   We want solution documents

---

From: "Bradner, Scott" <[email-masked]>
Date: Tue, 19 Feb 2013 20:15:00 +0000

Scott O Bradner
Senior Technology Consultant

Harvard University Information Technology
Innovation & Architecture
(P) +1 (617) 495 3864
1033 Mass Ave., room 462
Cambridge, MA 02138

On Feb 19, 2013, at 2:31 PM, joel jaeggli <[email-masked]> wrote:

> We have a policy, if we want to change it we set out to change it. Until then however, the present policy applies. we have evidence that it's fairly broadly supported so you can imagine the IESG as custodians will apply the policy as it stands.

that policy specifically permits the publication of documents of this type for information

including as WG consensus informational RFCs 

Scott

---

From: Owen DeLong <[email-masked]>
Date: Tue, 19 Feb 2013 13:06:05 -0800

> thing that operators can live with Š

IMHO, the IETF should not standardize it, but the document may be worthy
of publication as a BCP.

Owen

---

From: Scott O Bradner <[email-masked]>
Date: Tue, 19 Feb 2013 16:25:30 -0500

a BCP is a standard - to publish this ID as a BCP would violate 2804

but there would be no problem (RFC 2804-wise) publishing it as an informational RFC

Scott

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 19 Feb 2013 17:57:10 -0500

Hi Byju,

Why don't the present official specifications
for this purpose suffice?

TS102232-3 provides for the capability and
operates in conjunction with TS102232-1
which provides for trusted transport, and
interoperable with the new eWarrant spec.
The standard is current as of December
2012 and used worldwide.

TR102519 which is now six years old and
preceded the development of 102232-3,
states the generic requirements similar to
your draft.

All the specs here are non-proprietary,
well versioned, publicly available, and
provide for structured exchange of the
information.  What purpose would an
ID in the IETF on the same subject
serve?

--tony

---

From: "Byju Pularikkal (byjupg)" <[email-masked]>
Date: Wed, 20 Feb 2013 04:13:13 +0000

Hi Tony

The I-D we submitted exclusively focuses on LI Architecture models for
Service Provider Wi-Fi deployments and covers SP Wi-Fi deployments with
Inter-Operator Roaming scenarios &   without Inter-Operator Roaming
scenarios. Intent is to provide the Wi-Fi  Operators with a comprehensive
reference document which covers the LI specific interactions between the
key SP Wi-Fi components and LI Functional Elements . High level
description of the control plane interactions between these entities are
included as well in the document . Also the document explores how some of
the existing mobility protocols can be leveraged for the implementation of
LI for scenarios with and without Inter-Operator roaming, how to handle
the local breakout traffic in Inter-Operator Roaming Scenarios etc. We do
not think these aspects are covered in the documents you have referenced.

Also wanted to point out, capturing the requirements is not the focus of
this I-D since it has been captured already in several LI related
documents."

Thanks & Regards

Byju

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 20 Feb 2013 04:30:13 +0000

Hi Joel,

>apply the policy as it stands.

I agree with what you are saying. Personally, I don't agree with IETF's
view on this, but that's a view against an established consensus and may
not mean much. I'm just not sure we/Authors will be able to use this
document to drive that change. AD's need o push IAB to re-validate those
views, IMO. We are OK to publish this as informational and on a day there
is a change, we can get a standards stamp on this.

My personal opinion on LI:

1.) Operators have to comply to regulatory requirements; what ever may be
the law of the land is. In China, there may be a law to archive every
thing one writes for the next 100 years and the operators have to comply
to that, else they are not in business. That may be the case in post-9-11
US too.

2.) If that operator is deploying protocols that we define here, we should
ensure the LI models are understood and we have standardized solutions for
supporting those models and for achieving vendor inter-operability. Its in
our interest to have that for promoting the technology that we define here.

3.) All though RFC-2804 lists many points as why IETF should not work on
LI, but the real intent is about "privacy rights" and none of the other
points truly stand out. LI Requirements may be very local, but they can
all be generalized and solutions can be developed here. In the worst case,
"Capture every bit and byte that a subject types", how can this be any
local requirement ?

Regards
Sri

---

From: Melinda Shore <[email-masked]>
Date: Tue, 19 Feb 2013 19:35:34 -0900

On 2/19/13 7:30 PM, Sri Gundavelli (sgundave) wrote:
> We are OK to publish this as informational and on a day there

Well, maybe.  This may be an opportunity to transition from
talking about process issues to talking about the document
itself.

Melinda

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 20 Feb 2013 04:38:15 +0000

Ok. That's probably the right thing; I should not have entered that
discussion :)

Sri