Subject: [sfc] Recallling the post

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 24 Apr 2014 11:26:07 -0500

Hi all,

The author wishes to recall the following email posted on the list
yesterday.

Behcet

   - *From*: Behcet Sarikaya <sarikaya2012 at
gmail.com<[email-masked]>
   - *To*: "Joel M. Halpern" <jmh at joelhalpern.com <[email-masked]>>, sfc
   at ietf.org <[email-masked]>
   - *Cc*: Xueli <xueli at huawei.com <[email-masked]>>
   - *Date*: Wed, 23 Apr 2014 16:40:10 -0500
   - *In-reply-to*: <[email-masked]>
   - *References*: <[email-masked]> <
   [email-masked]>
   - *List-id*: Network Service Chaining <sfc.ietf.org>

------------------------------
Hi Joel,

Thanks for your comments. I think you forgot to cc it to the list :-)

On Tue, Apr 22, 2014 at 8:43 AM, Joel M. Halpern <jmh at joelhalpern.com>wrote:

> Reading this, it appears that youa re asserting that service functions in
> a service chain environment must be able to decrypt subscriber encrypted
> https traffic.
>
> I agree that encryption makes applying content functions harder.
>
> But the IETF is not going to mandate operator based decryption of
> end-to-end encrypted content.  Doing so would seem to require that we
> violate existing RFCs and weaken the effective crypto.  For example, it is
> simply not acceptable to require that customers accept operator
> certificates in place of content provider certificates.  (Some customers
> may choose to accept those, but we clear can not mandate such.)
>
>
In fact we carried this text from Broadband Forum Document SD-326 on
flexible service chaining, Section 6.2.2.
We did not intend to hint on an IETF solution. SD-326 also says that the
solution is out of scope.

> Separately, the content of the document does not seem to match the title.
>  Based on the title I was expecting to see a discussion of the problems
> caused by address sharing.  (Such problems are part of the motivation for
> subscriber identification metadata.)  But instead there is a description of
> some use cases for residential network service, without any discussion I
> could find of address sharing.  What did I miss.
>
>
I think the description is there but may be it needs to be clarified which
we will do in the next version.

Regards,

Behcet
Yours,
Joel

On 4/21/14, 3:56 PM, internet-drafts at ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

         Title           : Host Identification Problem in Service Function
Chaining Use Cases
         Authors         : Li Xue
                           Behcet Sarikaya
        Filename        :
draft-xue-sfc-address-sharing-in-sfc-use-cases-00.txt
        Pages           : 7
        Date            : 2014-04-21

Abstract:
    The purpose of this document is to present host identification
    problem due to the address and prefix sharing in service function
    chaining.  So far we have identified this problem in the two use
    cases of the parental control service and offloading service but it
    is likely that more use cases can be identified.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-xue-sfc-address-sharing-in-sfc-use-cases/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-xue-sfc-address-sharing-in-sfc-use-cases-00

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

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

_______________________________________________
I-D-Announce mailing list
I-D-Announce at ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt