From nobody Mon May 2 06:46:22 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DCB12B022 for ; Mon, 2 May 2016 06:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOp5u-LUcZCw for ; Mon, 2 May 2016 06:46:19 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ABCD12B009 for ; Mon, 2 May 2016 06:46:19 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id n63so73534045qkf.0 for ; Mon, 02 May 2016 06:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=bNPfbCAJ30Jtjj9MMt/1qdoFrzyuNt0e75Ry7dk6mQc=; b=LP8kBnhDMHmcHxV806+q8nKlvkpdfKWsrqh0UqmmG9XqJte682pLSoEAcBCs3hXlv8 HrLc+fvekIoRCeqaHvhB/Mlax0ygRTcsC8Yy81iLrNb7KbmPnz7uXNgnCKLQW0QuSvTX ne0vPWasYx6Xlvwt9KtGZp6GGhn69uqOawAiRkDk9dYAqO40GEq0NKHIF7r9Dpl7W3E3 pL3UjiFyX6l/ZuCgxasuQcsYkvcvctpKUSkh87IJ7XIlDkZNPEcfpWbBQgeuVINUXMxW Hlu1ndOJ/udItGT4qvGFo6oMdZEHdV99++HmxQR2SJw2XWru1eiqRxDSW1JO6YGOZJrO Frtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=bNPfbCAJ30Jtjj9MMt/1qdoFrzyuNt0e75Ry7dk6mQc=; b=gprzWWD0Ux3z5zQRRRCzWzDv9KOwJC8cNoGTosWpwfNQe8oeQIpURrR4LWnT4kTL55 Dhhi3beHSa2EUuaeKXX94dk0ansMmwF6Nw+1Duz1LEu2rrtcnsIU18pyoTq6oYTbzZJI jaIeJMm8h2R0HPoG1EypfJqX8reHf0rOyYJDKy4kxbLTtVIUbCP6mQknwBlPzy9g2cxt GqCq9B3EmZTZnyI/BJJFthm3+7D0mDlDleiI5QZ7UxEoRhs/XrVMDGtB92boRSroglwI ZynKpOfHCtnRSXveCpMD2AozHiKZruzt1HHvnBpDP2giI3YO5O7vll5q1/NkSqOa6T2d SUFQ== X-Gm-Message-State: AOPr4FVgrMPUJU5RW8tf1opkeDd8X0udJ34RBdH44Bq/O3g7HL5KPOLGXzSvWAMfqRXPR9+E6C7+4Jay4vHuzsqk X-Received: by 10.55.43.19 with SMTP id r19mr12784065qkh.124.1462196778089; Mon, 02 May 2016 06:46:18 -0700 (PDT) MIME-Version: 1.0 From: Warren Kumari Date: Mon, 02 May 2016 13:46:08 +0000 Message-ID: To: "opsawg@ietf.org" Content-Type: multipart/alternative; boundary=001a1149648a8d1b420531dc37ca Archived-At: Subject: [OPSAWG] RFC 7860 - thank you. X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 13:46:21 -0000 --001a1149648a8d1b420531dc37ca Content-Type: text/plain; charset=UTF-8 I just wanted to quickly thank the authors of RFC 7860 (HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3) for hanging in there. This Proposed Standard obsoletes RFC 7630, which was accidentally published with an incorrect MIB MODULE-IDENTITY - this unfortunately required a bunch of work to fix, and delayed things by ~6 months. Thanks again, W (on behalf of chairs) --001a1149648a8d1b420531dc37ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I just wanted to quickly thank the authors of=C2=A0=C2=A0RFC 7860 (HMAC-SHA-2 Authe= ntication Protocols in User-Based=C2=A0Security Model (USM) for SNMPv3) for = hanging in there.

=
Thi= s=C2=A0Proposed Standard=C2=A0obsoletes RFC 7630, which was accidentally publ= ished with an incorrect=C2=A0MIB=C2=A0MODULE-IDENTITY - this=C2=A0unfortunately=C2=A0required a bunch of work to fix, and de= layed things by ~6 months.
=
Thanks again,
=
W
(on beh= alf of chairs)

--001a1149648a8d1b420531dc37ca-- From nobody Wed May 18 01:16:36 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2920A12D09C; Wed, 18 May 2016 01:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6FNhyBvuOpx; Wed, 18 May 2016 01:16:34 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D520B12D098; Wed, 18 May 2016 01:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9115; q=dns/txt; s=iport; t=1463559394; x=1464768994; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=mTy8o+I6M6Qemevv2q6yrpZRNDkkoUbhGV6rA/NtH/o=; b=Hy0gg1aJMskGxKwts2B7J29xwzkJMNh5eUH9PHtQHQgn6dOtt7gM4ifJ FbN4mFzd6Fsa1b64ff7b0flwbjSl+rKnvWhSpeVwykBK9MTfeIR64qeaK t5UgH9Q/qZRHnfKZLHmIA4Aub3YwbxjAKwdjwlrI4dxa+c94jcHukW1Qw A=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaKAAZJDxX/xbLJq1UCYQ3p22NYIZKM?= =?us-ascii?q?oYRAoIIAQEBAQEBZieEQwEBBCNOGAsYKgICVwYBDAQEAQGIK7BOkVUBAQEBAQE?= =?us-ascii?q?BAQIBAQEBAQEBAQEBAQ4OiBuCV4QYFYMSgj0cAQSYK4MrgWiBXYcwgWmET4MIh?= =?us-ascii?q?VqPSWKCBgUXgU06A4g1AQEB?= X-IronPort-AV: E=Sophos;i="5.26,328,1459814400"; d="asc'?scan'208,217";a="635699862" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 May 2016 08:16:31 +0000 Received: from [10.61.103.219] (dhcp-10-61-103-219.cisco.com [10.61.103.219]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u4I8GUPk008884; Wed, 18 May 2016 08:16:31 GMT To: Michael Richardson , netmod@ietf.org, "opsawg@ietf.org" References: <29371.1460055085@obiwan.sandelman.ca> <5706B779.5050602@cisco.com> <28476.1460063381@obiwan.sandelman.ca> <5707BB90.3020700@cisco.com> <7855.1460145900@obiwan.sandelman.ca> From: Eliot Lear Message-ID: Date: Wed, 18 May 2016 10:16:30 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <7855.1460145900@obiwan.sandelman.ca> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DFLefJJd358QUXej2kBvmgwsbFHEGDhBW" Archived-At: Subject: Re: [OPSAWG] mud documents X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 08:16:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DFLefJJd358QUXej2kBvmgwsbFHEGDhBW Content-Type: multipart/mixed; boundary="MuqEDUj7jbBpek96MpcVLbAHrrJH2WaXG" From: Eliot Lear To: Michael Richardson , netmod@ietf.org, "opsawg@ietf.org" Message-ID: Subject: Re: mud documents References: <29371.1460055085@obiwan.sandelman.ca> <5706B779.5050602@cisco.com> <28476.1460063381@obiwan.sandelman.ca> <5707BB90.3020700@cisco.com> <7855.1460145900@obiwan.sandelman.ca> In-Reply-To: <7855.1460145900@obiwan.sandelman.ca> --MuqEDUj7jbBpek96MpcVLbAHrrJH2WaXG Content-Type: multipart/alternative; boundary="------------1FDB536B51AC3B15E9EF5C3F" This is a multi-part message in MIME format. --------------1FDB536B51AC3B15E9EF5C3F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable [It looks like we're moving some of this discussion to OPSAWG, so CCing opsawg]. Getting back to some old threads. On 4/8/16 10:05 PM, Michael Richardson wrote: > Eliot and I have been conversing about policies. I proposed that I wan= t a > policy like: > > He asked me three questions: > > 0 what happens when the policy enforcement point (PEP) that actually > operationalizes the policy does not understand the policy in its > entirety? Does it implement what it can, or does it discard? > > 1 Where does connections per unit of time fit in the above? > 2 Where does logging/notification fit into the above? > > I proposed that we wanted policies like this: > >> ---< > I am a printer. > I accept connections on the IPP port. > Please be suspicious when the connections are non-local. > > Eliot asked: > > There is no concept today of . Let me ask what ne= twork > > behavior you would associate with that? > > I answered: > mcr> Consider blocking them if they occur too frequently, or the > mcr> connections have a small number of RTTs. > > I also think that the "be-suspicious" part might be significantly modif= ied by > local policy. It could be that this results in no connections, it coul= d be > that it must be approved by an admin, that it's subject to some kind of= > site-wide ACL (such connections from the VPN, intranet and partners oka= y, not > the wild internet...) > > We discussed whether we could clearly articulate other policies like > connections/minute or connections/day that would be not-suspicious. > > I also suggested that this could extend beyond "THINGS" to *APPS* as we= ll: > > consider that the MUD could well be packaged with PC/Android/iPhone > *apps* as part of their security profile. > SELinux pretends to do this, but in practice configuring it is still= close > to impossible. The MUD specification would help a lot I think. > I think the following criteria are built into the MUD design that makes these sorts of changes hard: * The identity of the Thing is tied to either DHCP, LLDP, or 802.1AR attributes, which are all around the Thing itself and not an app.=20 This having been said, if there is a way for an app to inform the network that it too has a MUD file, then the network can use that information. The principle here is that the URL is distinct from its transmission means. Also, our initial focus has been on admitting the device onto the network itself. And so I think what we have here is future work, and I invite Michael to write a draft ;-= ) * As currently defined we're using the least common denominator for ACL capabilities. That way the most network elements can implement MUD. Question: is a time-based ACL common on a home router? 2nd question: what would happen to the policy if a part of it is not implementable? It might be possible to put some #ifdef-like capability in there, but that leads to the final design criterion.. * Keep it simple for the manufacturers, at least for the first version. If they need to scratch their heads too much they'll just give up. Eliot --------------1FDB536B51AC3B15E9EF5C3F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

[It looks like we're moving some of this discussion to OPSAWG, so CCing opsawg].

Getting back to some old threads.

On 4/8/16 10:05 PM, Michael Richardson= wrote:
Eliot and I have been conversing about policies.  I proposed that I want =
a
policy like:

He asked me three questions:

0 what happens when the policy enforcement point (PEP) that actually
  operationalizes the policy does not understand the policy in its
  entirety? Does it implement what it can, or does it discard?

1 Where does connections per unit of time fit in the above?
2 Where does logging/notification fit into the above?

I proposed that we wanted policies like this:


---<

I am a printer.
I accept connections on the IPP port.
Please be suspicious when the connections are non-local.

Eliot asked:
    > There is no concept today of <be-suspicious>.  Let me ask =
what network
    > behavior you would associate with that?

I answered:
mcr> Consider blocking them if they occur too frequently, or the
mcr> connections have a small number of RTTs.

I also think that the "be-suspicious" part might be significantly modifie=
d by
local policy.  It could be that this results in no connections, it could =
be
that it must be approved by an admin, that it's subject to some kind of
site-wide ACL (such connections from the VPN, intranet and partners okay,=
 not
the wild internet...)

We discussed whether we could clearly articulate other policies like
connections/minute or connections/day that would be not-suspicious.

I also suggested that this could extend beyond "THINGS" to *APPS* as well=
:

   consider that the MUD could well be packaged with PC/Android/iPhone
   *apps* as part of their security profile.
   SELinux pretends to do this, but in practice configuring it is still c=
lose
   to impossible.  The MUD specification would help a lot I think.

I think the following criteria are built into the MUD design that makes these sorts of changes hard:
  • The identity of the Thing is tied to either DHCP, LLDP, or 802.1AR attributes, which are all around the Thing itself and not an app.=C2=A0 This having been said, if there is a way for an= app to inform the network that it too has a MUD file, then the network can use that information.=C2=A0 The principle here is tha= t the URL is distinct from its transmission means.=C2=A0 Also, our initial focus has been on admitting the device onto the network itself.=C2=A0 And so I think what we have here is future work, an= d I invite Michael to write a draft ;-)
  • As currently defined we're using the least common denominator for ACL capabilities.=C2=A0 That way the most network elements ca= n implement MUD.=C2=A0 Question: is a time-based ACL common on a ho= me router?=C2=A0 2nd question: what would happen to the policy if a = part of it is not implementable?=C2=A0 It might be possible to put som= e #ifdef-like capability in there, but that leads to the final design criterion..
  • Keep it simple for the manufacturers, at least for the first version.=C2=A0 If they need to scratch their heads too much they'= ll just give up.

Eliot


--------------1FDB536B51AC3B15E9EF5C3F-- --MuqEDUj7jbBpek96MpcVLbAHrrJH2WaXG-- --DFLefJJd358QUXej2kBvmgwsbFHEGDhBW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJXPCTeAAoJEIe2a0bZ0nozYI4H/iOkaPNSoQYDLrdRm7maoNBB XdSQrGhkBy3dp1KdsxA5pWxsG+yNQjRnyf2cKjNSlSt4BMhhTutIEcDSfLxmctA4 80rfeyiAgK6OULgav7nz6MCBFG0HyI3EzG1462DVtOjdjP7j2eRFcnyLSz4iSCMj mdAXKDRUolttq3QWRcaRwMk3wqPrd0RPHRV0bmLdydmlw1FQhwAEnyp1NVesBtpV k3MBMwYbKCvT9wlSmM64SXBKKe+QhWt1H95cx+a/tPu7ylj2OttQprLCVHoawLhT qq0LMf0pzdemjDk2T7hPXsTxQ6T9JE4JwdixfgIAtj57eHb+QI3LVLy5LXnm+y4= =btAA -----END PGP SIGNATURE----- --DFLefJJd358QUXej2kBvmgwsbFHEGDhBW-- From nobody Mon May 23 21:32:14 2016 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0050F12D12D for ; Mon, 23 May 2016 21:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxsa5safFJKn for ; Mon, 23 May 2016 21:32:12 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18AC712D51F for ; Mon, 23 May 2016 21:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1964; q=dns/txt; s=iport; t=1464064332; x=1465273932; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=k8208FnAZFngO1/ZYyenql4LTF03ZNIUlGY9xM8a4GA=; b=bSm4iAZ+omfsZaPHH/OfYVv0nnsnyr3uvD/HixqohZZQJFOFldsjVgHg k0pU8HR5NFWo08hh4ta4NagRvk1K8U3hW3c0L4Zhyjhu9oF57kHeSp9f8 AFGUZZiS42F/04ytK5W9vc+9mbaq2KXt8slU2FJGws3QI25AK5WEPIV7Q c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BIAgDW2ENX/5RdJa1bgzdWfQa5eAENg?= =?us-ascii?q?XYkhW0CgTo4FAEBAQEBAQFlHAuEQwEBBDotEAIQAgEINhAyGwEGAwIEDgUbiBQ?= =?us-ascii?q?OxBQBAQEBAQEBAQEBAQEBAQEBAQEBAQEcinOKGQWNZYpSAYV/iCCBaU6EAYhkj?= =?us-ascii?q?0sBHgEBQoNtbohSfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,359,1459814400"; d="scan'208";a="275599649" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 May 2016 04:31:58 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u4O4Vw4D006903 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 May 2016 04:31:58 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 23 May 2016 23:31:57 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1104.009; Mon, 23 May 2016 23:31:57 -0500 From: "Byju Pularikkal (byjupg)" To: "opsawg@ietf.org" Thread-Topic: New Version Notification for draft-pularikkal-opsawg-wifi-calling-00.txt Thread-Index: AQHRsUaiC2EWq6P5wUioOaM0YO5+BZ/HZlKA Date: Tue, 24 May 2016 04:31:57 +0000 Message-ID: References: <20160518204826.14628.59565.idtracker@ietfa.amsl.com> In-Reply-To: <20160518204826.14628.59565.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.86.60] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Samy Touati , "Mark Grayson \(mgrayson\)" , Tommy Pauly Subject: [OPSAWG] FW: New Version Notification for draft-pularikkal-opsawg-wifi-calling-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 04:32:14 -0000 Hello All We published this draft on Wi-Fi calling. We believe this is a very relevant topic to mobile operators & SP Wi-Fi operators deploying Wi-Fi calling services. Very much appreciate your feedback on the draft. Regards Byju On 5/18/16, 1:48 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-pularikkal-opsawg-wifi-calling-00.txt >has been successfully submitted by Byju Pularikkal and posted to the >IETF repository. > >Name: draft-pularikkal-opsawg-wifi-calling >Revision: 00 >Title: Wi-Fi Calling Deployment Considerations >Document date: 2016-05-18 >Group: Individual Submission >Pages: 26 >URL: =20 >https://www.ietf.org/internet-drafts/draft-pularikkal-opsawg-wifi-calling- >00.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-pularikkal-opsawg-wifi-calling/ >Htmlized: =20 >https://tools.ietf.org/html/draft-pularikkal-opsawg-wifi-calling-00 > > >Abstract: > Carrier Wi-Fi Calling is a solution that allows mobile operators to > seamlessly offload mobile voice signaling and bearer traffic onto Wi- > Fi access networks, which may or may not be managed by the mobile > operators. Mobile data offload onto Wi-Fi access networks has > already become very common, as Wi-Fi access has become more > ubiquitous. However, the offload of mobile voice traffic onto Wi-Fi > networks has become prevalent only in recent years. This was > primarily driven by the native Wi-Fi Calling client support > introduced by device vendors. The objective of this document is to > provide a high level deployment reference to Mobile Operators and Wi- > Fi Operators on Carrier Wi-Fi Calling. > > =20 > =20 > > >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. > >The IETF Secretariat >