From wdec@cisco.com Thu Jul 1 03:53:59 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 683DE3A68CC for ; Thu, 1 Jul 2010 03:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.188 X-Spam-Level: X-Spam-Status: No, score=-9.188 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZsQy0SM3Fs4 for ; Thu, 1 Jul 2010 03:53:58 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 29F013A6800 for ; Thu, 1 Jul 2010 03:53:58 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAGsQLEyrR7Ht/2dsb2JhbACBQp1IWnGjIZpAhSUEiCuCIg X-IronPort-AV: E=Sophos;i="4.53,519,1272844800"; d="scan'208,217";a="152460368" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 01 Jul 2010 10:54:09 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o61ArxKi023834; Thu, 1 Jul 2010 10:54:09 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 12:54:04 +0200 Received: from 10.55.215.35 ([10.55.215.35]) by XMB-AMS-111.cisco.com ([144.254.74.86]) with Microsoft Exchange Server HTTP-DAV ; Thu, 1 Jul 2010 10:54:04 +0000 User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Thu, 01 Jul 2010 12:54:20 +0200 From: Wojciech Dec To: "Ralph Droms (rdroms)" Message-ID: Thread-Topic: [ANCP] Can we modify IANA registries set up for GSMPv3? Thread-Index: AcsZCB0PZ6Q6Plq5Rha7GLlN0pjwkQAA6TtF In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3360833662_25074451" X-OriginalArrivalTime: 01 Jul 2010 10:54:04.0771 (UTC) FILETIME=[B8E79330:01CB190B] Cc: ancp@ietf.org Subject: Re: [ANCP] Can we modify IANA registries set up for GSMPv3? X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 10:53:59 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3360833662_25074451 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I am asking whether renaming the existing GSMP code point as ANCP, effectively deprecating GSMP, is something that can be done? -Woj. On 01/07/2010 12:27, "Ralph Droms (rdroms)" wrote: > Woj - I'm not clear on the course of action you are suggesting. Do you mean > to declare GSMP deprecated, assign all of the registries to ANCP and assign > codepoints from those registries as if GSMP never existed? > > - Ralph > > On Jun 30, 2010, at 12:06 PM 6/30/10, Wojciech Dec wrote: > >> > Adding Ralph... >> > >> > The core issue looks like being that ANCP still rides on the GSMP protocol >> > code point, even though it is incompatible. >> > I'm not sure if there is a precedent for a re-branding of a protocol type, >> > but if that is an option, along with declaring GSMP deprecated, then we >> > could have an alternative. (Note: Previous searches into finding >> operational >> > implementations of GSMP have not found any, but we will never know for >> sure. >> > That said, it's highly unlikely that the two will meet.) >> > >> > -Woj. >> > >> > >> > On 30/06/2010 15:31, "Tom Taylor" wrote: >> > >>> >> This issue may affect other registries, but I realized it when I was >>> looking >>> >> at >>> >> the reallocation of bits between Result and Code compared with GSMPv3. >>> I'm >>> >> sure >>> >> it's legitimate to add code points to a registry for an older protocol, >>> but >>> >> this >>> >> reallocation of bits means that the limits on the possible values change. >>> Can >>> >> we >>> >> do that (implying that we obsolete GSMPv3 itself), or must we establish >>> new >>> >> parallel registries for ANCP? >>> >> >>> >> There is an intermediate solution where we continue to use GSMPv3 >>> registries >>> >> but >>> >> segregate the codepoints falling outside the limits for one protocol or >>> the >>> >> other, noting that they apply only to one protocol. Thus in the Result >>> value >>> >> registry we would add a note that any values greater than 15 apply to >>> GSMPv3 >>> >> only, while in the Code registry, values greater than 255 apply to ANCP >>> only. >>> >> This sounds like the best solution, though I had to talk myself around to >>> it. >>> >> >>> >> Tom Taylor >>> >> _______________________________________________ >>> >> ANCP mailing list >>> >> ANCP@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/ancp >> > > > --B_3360833662_25074451 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [ANCP] Can we modify IANA registries set up for GSMPv3? I am asking whether renaming the existing GSMP code point as ANCP, effecti= vely deprecating GSMP, is something that can be done?

-Woj.


On 01/07/2010 12:27, "Ralph Droms (rdroms)" <rdroms@cisco.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Woj - I'm not clear on the course of action you = are suggesting.  Do you mean to declare GSMP deprecated, assign all of = the registries to ANCP and assign codepoints from those registries as if GSM= P never existed?

- Ralph

On Jun 30, 2010, at 12:06 PM 6/30/10, Wojciech Dec wrote:

> Adding Ralph...
>
> The core issue looks like being that ANCP still rides on the GSMP prot= ocol
> code point, even though it is incompatible.
> I'm not sure if there is a precedent for a re-branding of a protocol t= ype,
> but if that is an option, along with declaring GSMP deprecated, then w= e
> could have an alternative. (Note: Previous searches into finding opera= tional
> implementations of GSMP have not found any, but we will never know for= sure.
> That said, it's highly unlikely that the two will meet.)
>
> -Woj.
>
>
> On 30/06/2010 15:31, "Tom Taylor" <tom111.taylor@bell.net> wrote:
>
>> This issue may affect other registries, but I realized it when I w= as looking
>> at
>> the reallocation of bits between Result and Code compared with GSM= Pv3. I'm
>> sure
>> it's legitimate to add code points to a registry for an older prot= ocol, but
>> this
>> reallocation of bits means that the limits on the possible values = change. Can
>> we
>> do that (implying that we obsolete GSMPv3 itself), or must we esta= blish new
>> parallel registries for ANCP?
>>
>> There is an intermediate solution where we continue to use GSMPv3 = registries
>> but
>> segregate the codepoints falling outside the limits for one protoc= ol or the
>> other, noting that they apply only to one protocol. Thus in the Re= sult value
>> registry we would add a note that any values greater than 15 apply= to GSMPv3
>> only, while in the Code registry, values greater than 255 apply to= ANCP only.
>> This sounds like the best solution, though I had to talk myself ar= ound to it.
>>
>> Tom Taylor
>> _______________________________________________
>> ANCP mailing list
>> ANCP@ietf.org
>> https://www.i= etf.org/mailman/listinfo/ancp
>


--B_3360833662_25074451-- From rdroms.ietf@gmail.com Thu Jul 1 04:53:49 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FFBE3A691F for ; Thu, 1 Jul 2010 04:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjGmo9T2H4w7 for ; Thu, 1 Jul 2010 04:53:48 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 376233A691C for ; Thu, 1 Jul 2010 04:53:48 -0700 (PDT) Received: by pvd12 with SMTP id 12so1038497pvd.31 for ; Thu, 01 Jul 2010 04:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=vQwBd0dP/86uzsov3dDg5N71AmgmoaFuPkRYbQ0NisE=; b=LAfvYTPdGA0m/8xfgJs54o+0aT6hdVMWIDlgpl2TQg+UiUMVbBRB7l4vlOpOMVYXy+ m+exLhdMzsH3tM5nK7u02rsHrNoEev9sp3CABPgB5//0NF2uj1C1ig5JXSPGu3QBxS4V 7XJVff4Gh+OZLGTR5vEBndrRKVdnT4cz4O1/M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=xFsYuVHwRynJaqpAwSa6xzRg3SyU66n8TjlRfZy/RvwtN8StKHNb3ZCWXbR5weKyy4 ZDs430Lcysxj0LcM1m3rl8Y5oZRdUFSUZPk7+EIwOtZHz+Z2EJuOESJepZsLbe5GcFKD 6o6ptQjHp0Pc5M4HgV9k6I0AVNcP93/HRX0Hk= Received: by 10.115.133.38 with SMTP id k38mr11870747wan.200.1277985234879; Thu, 01 Jul 2010 04:53:54 -0700 (PDT) Received: from [10.21.108.85] (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id k23sm88364095waf.17.2010.07.01.04.53.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Jul 2010 04:53:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: Date: Thu, 1 Jul 2010 07:53:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Wojciech Dec X-Mailer: Apple Mail (2.1078) Cc: ancp@ietf.org Subject: Re: [ANCP] Can we modify IANA registries set up for GSMPv3? X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 11:53:49 -0000 I don't know the answer. If you'll write up a short request, with a few = sentences describing how we got the current situation, I'll take it to = IANA and the IESG. - Ralph On Jul 1, 2010, at 6:54 AM 7/1/10, Wojciech Dec wrote: > I am asking whether renaming the existing GSMP code point as ANCP, = effectively deprecating GSMP, is something that can be done? >=20 > -Woj. >=20 >=20 > On 01/07/2010 12:27, "Ralph Droms (rdroms)" wrote: >=20 >> Woj - I'm not clear on the course of action you are suggesting. Do = you mean to declare GSMP deprecated, assign all of the registries to = ANCP and assign codepoints from those registries as if GSMP never = existed? >>=20 >> - Ralph >>=20 >> On Jun 30, 2010, at 12:06 PM 6/30/10, Wojciech Dec wrote: >>=20 >>> Adding Ralph... >>>=20 >>> The core issue looks like being that ANCP still rides on the GSMP = protocol >>> code point, even though it is incompatible. >>> I'm not sure if there is a precedent for a re-branding of a protocol = type, >>> but if that is an option, along with declaring GSMP deprecated, then = we >>> could have an alternative. (Note: Previous searches into finding = operational >>> implementations of GSMP have not found any, but we will never know = for sure. >>> That said, it's highly unlikely that the two will meet.) >>>=20 >>> -Woj. >>>=20 >>>=20 >>> On 30/06/2010 15:31, "Tom Taylor" wrote: >>>=20 >>>> This issue may affect other registries, but I realized it when I = was looking >>>> at >>>> the reallocation of bits between Result and Code compared with = GSMPv3. I'm >>>> sure >>>> it's legitimate to add code points to a registry for an older = protocol, but >>>> this >>>> reallocation of bits means that the limits on the possible values = change. Can >>>> we >>>> do that (implying that we obsolete GSMPv3 itself), or must we = establish new >>>> parallel registries for ANCP? >>>>=20 >>>> There is an intermediate solution where we continue to use GSMPv3 = registries >>>> but >>>> segregate the codepoints falling outside the limits for one = protocol or the >>>> other, noting that they apply only to one protocol. Thus in the = Result value >>>> registry we would add a note that any values greater than 15 apply = to GSMPv3 >>>> only, while in the Code registry, values greater than 255 apply to = ANCP only. >>>> This sounds like the best solution, though I had to talk myself = around to it. >>>>=20 >>>> Tom Taylor >>>> _______________________________________________ >>>> ANCP mailing list >>>> ANCP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ancp >>>=20 >>=20 >>=20 From rdroms@cisco.com Thu Jul 1 03:27:50 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FDB13A67E3 for ; Thu, 1 Jul 2010 03:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jt63USM9pq40 for ; Thu, 1 Jul 2010 03:27:49 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 15D713A67E2 for ; Thu, 1 Jul 2010 03:27:47 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,519,1272844800"; d="scan'208";a="152449770" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 01 Jul 2010 10:27:58 +0000 Received: from [10.21.108.85] ([10.21.108.85]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o61ARwcL008304; Thu, 1 Jul 2010 10:27:58 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: Date: Thu, 1 Jul 2010 06:27:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Wojciech Dec X-Mailer: Apple Mail (2.1078) X-Mailman-Approved-At: Thu, 01 Jul 2010 04:54:21 -0700 Cc: ancp@ietf.org Subject: Re: [ANCP] Can we modify IANA registries set up for GSMPv3? X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 10:27:50 -0000 Woj - I'm not clear on the course of action you are suggesting. Do you = mean to declare GSMP deprecated, assign all of the registries to ANCP = and assign codepoints from those registries as if GSMP never existed? - Ralph On Jun 30, 2010, at 12:06 PM 6/30/10, Wojciech Dec wrote: > Adding Ralph... >=20 > The core issue looks like being that ANCP still rides on the GSMP = protocol > code point, even though it is incompatible. > I'm not sure if there is a precedent for a re-branding of a protocol = type, > but if that is an option, along with declaring GSMP deprecated, then = we > could have an alternative. (Note: Previous searches into finding = operational > implementations of GSMP have not found any, but we will never know for = sure. > That said, it's highly unlikely that the two will meet.) >=20 > -Woj. >=20 >=20 > On 30/06/2010 15:31, "Tom Taylor" wrote: >=20 >> This issue may affect other registries, but I realized it when I was = looking >> at=20 >> the reallocation of bits between Result and Code compared with = GSMPv3. I'm >> sure=20 >> it's legitimate to add code points to a registry for an older = protocol, but >> this=20 >> reallocation of bits means that the limits on the possible values = change. Can >> we=20 >> do that (implying that we obsolete GSMPv3 itself), or must we = establish new >> parallel registries for ANCP? >>=20 >> There is an intermediate solution where we continue to use GSMPv3 = registries >> but=20 >> segregate the codepoints falling outside the limits for one protocol = or the >> other, noting that they apply only to one protocol. Thus in the = Result value >> registry we would add a note that any values greater than 15 apply to = GSMPv3 >> only, while in the Code registry, values greater than 255 apply to = ANCP only. >> This sounds like the best solution, though I had to talk myself = around to it. >>=20 >> Tom Taylor >> _______________________________________________ >> ANCP mailing list >> ANCP@ietf.org >> https://www.ietf.org/mailman/listinfo/ancp >=20 From wdec@cisco.com Thu Jul 1 05:42:30 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8C3A3A697F for ; Thu, 1 Jul 2010 05:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.889 X-Spam-Level: X-Spam-Status: No, score=-9.889 tagged_above=-999 required=5 tests=[AWL=0.710, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ITkkoz-nA7g for ; Thu, 1 Jul 2010 05:42:29 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 843BC28C0EC for ; Thu, 1 Jul 2010 05:42:29 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPcpLExAZnwN/2dsb2JhbACfZnGjSpo7hSUEiCuCIg X-IronPort-AV: E=Sophos;i="4.53,520,1272844800"; d="scan'208";a="127704191" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 01 Jul 2010 12:42:40 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o61CgerJ006886; Thu, 1 Jul 2010 12:42:40 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 14:42:40 +0200 Received: from 10.55.215.35 ([10.55.215.35]) by XMB-AMS-111.cisco.com ([144.254.74.86]) with Microsoft Exchange Server HTTP-DAV ; Thu, 1 Jul 2010 12:42:40 +0000 User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Thu, 01 Jul 2010 14:42:55 +0200 From: Wojciech Dec To: Ralph Droms Message-ID: Thread-Topic: [ANCP] Can we modify IANA registries set up for GSMPv3? Thread-Index: AcsZGu05zUC4Gr+g206zr8op/ViJ8A== In-Reply-To: <705034CE-5F55-4BE8-8DDB-019926C173E9@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Jul 2010 12:42:40.0054 (UTC) FILETIME=[E450DD60:01CB191A] Cc: ancp@ietf.org Subject: Re: [ANCP] Can we modify IANA registries set up for GSMPv3? X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 12:42:31 -0000 Ok. Unless you know off hand the answer to the alternative (as proposed by Tom), I will also Whether it's viable to subdivide a code-point space, ie if gsmp and ancp use the same protocol id, whether we could get iana registries for ancp-only messages/result codes, etc. -Woj. On 01/07/2010 13:50, "Ralph Droms" wrote: > I don't know the answer. If you'll write up a short request, with a few > sentences describing how we got the current situation, I'll take it to IANA > and the IESG. > > - Ralph > > On Jul 1, 2010, at 6:54 AM 7/1/10, Wojciech Dec wrote: > >> I am asking whether renaming the existing GSMP code point as ANCP, >> effectively deprecating GSMP, is something that can be done? >> >> -Woj. >> >> >> On 01/07/2010 12:27, "Ralph Droms (rdroms)" wrote: >> >>> Woj - I'm not clear on the course of action you are suggesting. Do you mean >>> to declare GSMP deprecated, assign all of the registries to ANCP and assign >>> codepoints from those registries as if GSMP never existed? >>> >>> - Ralph >>> >>> On Jun 30, 2010, at 12:06 PM 6/30/10, Wojciech Dec wrote: >>> >>>> Adding Ralph... >>>> >>>> The core issue looks like being that ANCP still rides on the GSMP protocol >>>> code point, even though it is incompatible. >>>> I'm not sure if there is a precedent for a re-branding of a protocol type, >>>> but if that is an option, along with declaring GSMP deprecated, then we >>>> could have an alternative. (Note: Previous searches into finding >>>> operational >>>> implementations of GSMP have not found any, but we will never know for >>>> sure. >>>> That said, it's highly unlikely that the two will meet.) >>>> >>>> -Woj. >>>> >>>> >>>> On 30/06/2010 15:31, "Tom Taylor" wrote: >>>> >>>>> This issue may affect other registries, but I realized it when I was >>>>> looking >>>>> at >>>>> the reallocation of bits between Result and Code compared with GSMPv3. I'm >>>>> sure >>>>> it's legitimate to add code points to a registry for an older protocol, >>>>> but >>>>> this >>>>> reallocation of bits means that the limits on the possible values change. >>>>> Can >>>>> we >>>>> do that (implying that we obsolete GSMPv3 itself), or must we establish >>>>> new >>>>> parallel registries for ANCP? >>>>> >>>>> There is an intermediate solution where we continue to use GSMPv3 >>>>> registries >>>>> but >>>>> segregate the codepoints falling outside the limits for one protocol or >>>>> the >>>>> other, noting that they apply only to one protocol. Thus in the Result >>>>> value >>>>> registry we would add a note that any values greater than 15 apply to >>>>> GSMPv3 >>>>> only, while in the Code registry, values greater than 255 apply to ANCP >>>>> only. >>>>> This sounds like the best solution, though I had to talk myself around to >>>>> it. >>>>> >>>>> Tom Taylor >>>>> _______________________________________________ >>>>> ANCP mailing list >>>>> ANCP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ancp >>>> >>> >>> > From rdroms.ietf@gmail.com Thu Jul 1 05:52:01 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 860443A6BFD for ; Thu, 1 Jul 2010 05:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-pPsNv7wtMB for ; Thu, 1 Jul 2010 05:52:00 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 4CED63A6A0B for ; Thu, 1 Jul 2010 05:52:00 -0700 (PDT) Received: by pwj2 with SMTP id 2so948783pwj.31 for ; Thu, 01 Jul 2010 05:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=PqloPXiDIqWQE7uX+JSYCmNJhoz4fwkHroj4wy90Nbo=; b=csXio3i0e1I7Ck51x3oOWXdKpiY6SD9TrescZHYB/yN3zdJAcdwegryO9evqdnIjTN znX2CyJQwcKYpinm1FdyGixJNp/XlvNUGRpYzJYsmy0Ij39qpR7ZM+xMtGvjo209Z+OB UXvHnfyRuVkOPV1In7SJX6Yf8Vtb8+pn73bX8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=snLuRFvTcfLUN8sj6qLmyiRqL+l3JKxJI1nCa1BThJpZFsILxJq3lVGcQWFQG9IKbG 6cgSQOinKVchRPZUrdvvR0TkT23mCC4rr98kAC45Fsy8Axe2E5437if0QrukrFduukhB Rfo3LTy0HODcu+9BvFNL1r5fwcLVFDHjfiHbU= Received: by 10.142.67.34 with SMTP id p34mr12580683wfa.335.1277988727688; Thu, 01 Jul 2010 05:52:07 -0700 (PDT) Received: from [10.21.108.85] (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id l40sm218504rvb.6.2010.07.01.05.52.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Jul 2010 05:52:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: Date: Thu, 1 Jul 2010 08:51:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <001B3459-6E5B-4B1C-8896-A526F3852609@gmail.com> References: To: Wojciech Dec X-Mailer: Apple Mail (2.1078) Cc: ancp@ietf.org Subject: Re: [ANCP] Can we modify IANA registries set up for GSMPv3? X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 12:52:01 -0000 I don't know if the alternative can be done, either. I can see = arguments pro/con for both alternatives. So, if you'll give me a brief = write-up of both alternatives, I'll discuss it with the IESG and IANA. - Ralph On Jul 1, 2010, at 8:42 AM 7/1/10, Wojciech Dec wrote: > Ok. Unless you know off hand the answer to the alternative (as = proposed by > Tom), I will also Whether it's viable to subdivide a code-point space, = ie if > gsmp and ancp use the same protocol id, whether we could get iana = registries > for ancp-only messages/result codes, etc. >=20 > -Woj. >=20 >=20 > On 01/07/2010 13:50, "Ralph Droms" wrote: >=20 >> I don't know the answer. If you'll write up a short request, with a = few >> sentences describing how we got the current situation, I'll take it = to IANA >> and the IESG. >>=20 >> - Ralph >>=20 >> On Jul 1, 2010, at 6:54 AM 7/1/10, Wojciech Dec wrote: >>=20 >>> I am asking whether renaming the existing GSMP code point as ANCP, >>> effectively deprecating GSMP, is something that can be done? >>>=20 >>> -Woj. >>>=20 >>>=20 >>> On 01/07/2010 12:27, "Ralph Droms (rdroms)" = wrote: >>>=20 >>>> Woj - I'm not clear on the course of action you are suggesting. Do = you mean >>>> to declare GSMP deprecated, assign all of the registries to ANCP = and assign >>>> codepoints from those registries as if GSMP never existed? >>>>=20 >>>> - Ralph >>>>=20 >>>> On Jun 30, 2010, at 12:06 PM 6/30/10, Wojciech Dec wrote: >>>>=20 >>>>> Adding Ralph... >>>>>=20 >>>>> The core issue looks like being that ANCP still rides on the GSMP = protocol >>>>> code point, even though it is incompatible. >>>>> I'm not sure if there is a precedent for a re-branding of a = protocol type, >>>>> but if that is an option, along with declaring GSMP deprecated, = then we >>>>> could have an alternative. (Note: Previous searches into finding >>>>> operational >>>>> implementations of GSMP have not found any, but we will never know = for >>>>> sure. >>>>> That said, it's highly unlikely that the two will meet.) >>>>>=20 >>>>> -Woj. >>>>>=20 >>>>>=20 >>>>> On 30/06/2010 15:31, "Tom Taylor" wrote: >>>>>=20 >>>>>> This issue may affect other registries, but I realized it when I = was >>>>>> looking >>>>>> at >>>>>> the reallocation of bits between Result and Code compared with = GSMPv3. I'm >>>>>> sure >>>>>> it's legitimate to add code points to a registry for an older = protocol, >>>>>> but >>>>>> this >>>>>> reallocation of bits means that the limits on the possible values = change. >>>>>> Can >>>>>> we >>>>>> do that (implying that we obsolete GSMPv3 itself), or must we = establish >>>>>> new >>>>>> parallel registries for ANCP? >>>>>>=20 >>>>>> There is an intermediate solution where we continue to use GSMPv3 >>>>>> registries >>>>>> but >>>>>> segregate the codepoints falling outside the limits for one = protocol or >>>>>> the >>>>>> other, noting that they apply only to one protocol. Thus in the = Result >>>>>> value >>>>>> registry we would add a note that any values greater than 15 = apply to >>>>>> GSMPv3 >>>>>> only, while in the Code registry, values greater than 255 apply = to ANCP >>>>>> only. >>>>>> This sounds like the best solution, though I had to talk myself = around to >>>>>> it. >>>>>>=20 >>>>>> Tom Taylor >>>>>> _______________________________________________ >>>>>> ANCP mailing list >>>>>> ANCP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ancp >>>>>=20 >>>>=20 >>>>=20 >>=20 >=20 From tom111.taylor@bell.net Thu Jul 1 07:14:56 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC8DB3A68E3 for ; Thu, 1 Jul 2010 07:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.859 X-Spam-Level: X-Spam-Status: No, score=0.859 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NO0a1oDnJxkv for ; Thu, 1 Jul 2010 07:14:51 -0700 (PDT) Received: from blu0-omc2-s24.blu0.hotmail.com (blu0-omc2-s24.blu0.hotmail.com [65.55.111.99]) by core3.amsl.com (Postfix) with ESMTP id 42A413A67F6 for ; Thu, 1 Jul 2010 07:14:51 -0700 (PDT) Received: from BLU0-SMTP34 ([65.55.111.72]) by blu0-omc2-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 07:15:02 -0700 X-Originating-IP: [70.26.17.94] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.26.17.94]) by BLU0-SMTP34.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 07:15:02 -0700 Date: Thu, 01 Jul 2010 10:15:00 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: srinivasa.nalluri@wipro.com References: <2045724C4D2E45F581E2A31B963A55F3@china.huawei.com> <70E3BF80B2DA6E469688AD5C3BBCC6C4071A5364@BLR-EC-MBX02.wipro.com> In-Reply-To: <70E3BF80B2DA6E469688AD5C3BBCC6C4071A5364@BLR-EC-MBX02.wipro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jul 2010 14:15:02.0424 (UTC) FILETIME=[CBD36980:01CB1927] Cc: ancp@ietf.org Subject: Re: [ANCP] Tech Type and Capabilities X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 14:14:57 -0000 PON will be dealt with in a separate document, extending ANCP the way the multicast extensions document did. If PON introduces new attributes, we'll have to specify new data structures (TLVs, fixed fields) to hold them. Similarly for other technologies. srinivasa.nalluri@wipro.com wrote: > Tom, > > Does this mean we will have separate set of TLV and sub-TLVs to define > PON line (ONU/ONT level) attributes. > Today, in protocol document I cannot see TLVs for PON line attributes. > > How about considering other wireless access technologies? > > > > Regards > Srinivas ... From tom111.taylor@bell.net Thu Jul 1 07:44:49 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651BA3A6846 for ; Thu, 1 Jul 2010 07:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.857 X-Spam-Level: X-Spam-Status: No, score=0.857 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCgTiIsS0LgS for ; Thu, 1 Jul 2010 07:44:48 -0700 (PDT) Received: from blu0-omc4-s19.blu0.hotmail.com (blu0-omc4-s19.blu0.hotmail.com [65.55.111.158]) by core3.amsl.com (Postfix) with ESMTP id 71CC83A6802 for ; Thu, 1 Jul 2010 07:44:48 -0700 (PDT) Received: from BLU0-SMTP18 ([65.55.111.136]) by blu0-omc4-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 07:44:59 -0700 X-Originating-IP: [70.26.17.94] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.26.17.94]) by BLU0-SMTP18.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 07:44:59 -0700 Date: Thu, 01 Jul 2010 10:44:57 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Ralph Droms , iana@iana.org References: <001B3459-6E5B-4B1C-8896-A526F3852609@gmail.com> In-Reply-To: <001B3459-6E5B-4B1C-8896-A526F3852609@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jul 2010 14:44:59.0594 (UTC) FILETIME=[FB05CAA0:01CB192B] Cc: ancp@ietf.org Subject: Re: [ANCP] Can we modify IANA registries set up for GSMPv3? X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 14:44:49 -0000 Here's a write-up, for all *three* alternatives. Background: The Access Network Control Protocol (ANCP) was designed taking GSMPv3 (RFC 3292) as the starting point. ANCP has introduced modifications and extensions that are such as to render the two protocols non-interoperable. Nevertheless, the ANCP specification still refers normatively to RFC 3292 for both procedures and data formats. In particular, ANCP reuses some IANA registries set up by RFC 3292. ANCP needs additional registries of its own. The complications come in because ANCP has not only added codepoints to these GSMPv3 registries, but in some cases has modified the sizes of the fields concerned so that the upper limits of the values contained in them have changed. To accommodate this, three alternatives have been proposed. The IESG and IANA are being asked for their preference amongst these alternatives. Alternative 1: Parallel Registries ================================== With this alternative, ANCP ceases to reuse the GSMPv3 registries and instead establishes its own. The GSMPv3 codepoints used by ANCP are copied over to the ANCP registries, and the GSMPv3 registries are left undisturbed. If GSMPv3 were a living protocol, this would introduce the potential need for continued synchronization between the two sets of registries. Given that no known implementations of GSMPv3 exist, that maintenance issue isn't really there. Alternative 2: Reuse With Notes =============================== With this alternative, a note would be added to each registry that ANCP shares with GSMPv3, indicating that the registry is also used by ANCP. It is an open question whether codepoints added for ANCP use should be identified as such. Where the field sizes have changed, further notes would have to be added, indicating the limits applicable to GSMPv3 and ANCP respectively. Possibly codepoints applicable to only one of the two protocols would be listed separately. Alternative 3: Deprecation of GSMPv3 ==================================== With this alternative, GSMPv3 would be deprecated and the registries not used by ANCP would be closed/marked "deprecated". The registries used by ANCP would be renamed, leaving behind their GSMPv3 heritage and the codepoints inapplicable to ANCP. The ANCP base specification would have to add the material currently incorporated by reference from RFC 3292 (and 3293), so that it becomes independent of those specifications. If I may add a personal note, deprecation of GSMPv3 seems like an extreme measure. There's also so much heritage in ANCP in the way of GSMPv3 fields that are unused that the protocol would seem very odd to someone unaware of its history because that history had been obliterated. (Note to Ralph: design of the protocol has been constrained by the existence of early implementations, departures from which had to be minimized.) Ralph Droms wrote: > I don't know if the alternative can be done, either. I can see arguments pro/con for both alternatives. So, if you'll give me a brief write-up of both alternatives, I'll discuss it with the IESG and IANA. > > - Ralph > > On Jul 1, 2010, at 8:42 AM 7/1/10, Wojciech Dec wrote: > >> Ok. Unless you know off hand the answer to the alternative (as proposed by >> Tom), I will also Whether it's viable to subdivide a code-point space, ie if >> gsmp and ancp use the same protocol id, whether we could get iana registries >> for ancp-only messages/result codes, etc. >> >> -Woj. >> ... From wdec@cisco.com Thu Jul 1 07:51:55 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74BBF3A6802 for ; Thu, 1 Jul 2010 07:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.279 X-Spam-Level: X-Spam-Status: No, score=-9.279 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0cJrMvOD1Eq for ; Thu, 1 Jul 2010 07:51:51 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 52E293A676A for ; Thu, 1 Jul 2010 07:51:51 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFADJILExAZnwN/2dsb2JhbACBQ51KXHGkUJo5hSUEiC2CIg X-IronPort-AV: E=Sophos;i="4.53,520,1272844800"; d="scan'208,217";a="127752394" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 01 Jul 2010 14:52:02 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o61Eptm1003938; Thu, 1 Jul 2010 14:52:02 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 16:52:00 +0200 Received: from 10.55.215.35 ([10.55.215.35]) by XMB-AMS-111.cisco.com ([144.254.74.86]) with Microsoft Exchange Server HTTP-DAV ; Thu, 1 Jul 2010 14:51:59 +0000 User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Thu, 01 Jul 2010 16:52:15 +0200 From: Wojciech Dec To: Tom Taylor , Ralph Droms , Message-ID: Thread-Topic: [ANCP] Can we modify IANA registries set up for GSMPv3? Thread-Index: AcsZK/7yW3QZGOh9QIqQqUE9FGp5KQAAP+Zk In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3360847938_25897214" X-OriginalArrivalTime: 01 Jul 2010 14:52:00.0388 (UTC) FILETIME=[F5D5DC40:01CB192C] Cc: ancp@ietf.org Subject: Re: [ANCP] Can we modify IANA registries set up for GSMPv3? X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 14:51:55 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3360847938_25897214 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable On 01/07/2010 16:44, "Tom Taylor" wrote: > If I may add a personal note, deprecation of GSMPv3 seems like an extreme > measure. There's also so much heritage in ANCP in the way of GSMPv3 field= s > that > are unused that the protocol would seem very odd to someone unaware of it= s > history because that history had been obliterated. (Note to Ralph: design= of > the > protocol has been constrained by the existence of early implementations, > departures from which had to be minimized.) The GSMPv3 rfc=B9s would still be there, marked accordingly. ANCP is a TCP version of GSMPv3.2 (which on the wire it looks like, albeit without a lot of other baggage).... -Woj. --B_3360847938_25897214 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [ANCP] Can we modify IANA registries set up for GSMPv3?


On 01/07/2010 16:44, "Tom Taylor" <tom111.taylor@bell.net> wrote:

<= SPAN STYLE=3D'font-size:11pt'>If I may add a personal note, deprecation of GSM= Pv3 seems like an extreme
measure. There's also so much heritage in ANCP in the way of GSMPv3 fields = that
are unused that the protocol would seem very odd to someone unaware of its<= BR> history because that history had been obliterated. (Note to Ralph: design o= f the
protocol has been constrained by the existence of early implementations, departures from which had to be minimized.)
=
The GSMPv3 rfc’s would still be there, marked accordingly. ANCP is a = TCP version of GSMPv3.2 (which on the wire it looks like, albeit without a l= ot of other baggage)....

-Woj. --B_3360847938_25897214-- From tom111.taylor@bell.net Thu Jul 1 16:08:20 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35E753A6856 for ; Thu, 1 Jul 2010 16:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.853 X-Spam-Level: X-Spam-Status: No, score=0.853 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ixJhBqlghFL for ; Thu, 1 Jul 2010 16:08:19 -0700 (PDT) Received: from blu0-omc2-s30.blu0.hotmail.com (blu0-omc2-s30.blu0.hotmail.com [65.55.111.105]) by core3.amsl.com (Postfix) with ESMTP id 7BB0F3A6837 for ; Thu, 1 Jul 2010 16:08:19 -0700 (PDT) Received: from BLU0-SMTP101 ([65.55.111.72]) by blu0-omc2-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 16:08:30 -0700 X-Originating-IP: [70.26.17.94] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.26.17.94]) by BLU0-SMTP101.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 16:08:30 -0700 Date: Thu, 01 Jul 2010 19:08:27 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: ancp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jul 2010 23:08:30.0618 (UTC) FILETIME=[523237A0:01CB1972] Subject: [ANCP] Underspecification of Access-Aggregation-Circuit-ID-Binary X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 23:08:20 -0000 The values placed in Access-Aggregation-Circuit-ID-Binary in the base protocol spec seem to be slightly underspecified. The text says that each 32-bit word captures a 12-bit VLAN identifier. Should it also say that the high-order 20 bits of the word MUST be set to zero? The second missing piece is that there is no indication of the order in which the identifiers are placed into the TLV. I think we have to do this, given that the contents of the TLV will be matched against provisioned values on the NAS or AAA server. Tom Taylor From root@core3.amsl.com Fri Jul 2 08:00:01 2010 Return-Path: X-Original-To: ancp@ietf.org Delivered-To: ancp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5A1D83A68BF; Fri, 2 Jul 2010 08:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100702150001.5A1D83A68BF@core3.amsl.com> Date: Fri, 2 Jul 2010 08:00:01 -0700 (PDT) Cc: ancp@ietf.org Subject: [ANCP] I-D Action:draft-ietf-ancp-mib-an-05.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 15:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access Node Control Protocol Working Group of the IETF. Title : Access Node Control Protocol (ANCP) MIB module for Access Nodes Author(s) : S. De Cnodder, M. Morgenstern Filename : draft-ietf-ancp-mib-an-05.txt Pages : 36 Date : 2010-07-02 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing access nodes that are using the Access Node Control Protocol (ANCP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-mib-an-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ancp-mib-an-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-02075501.I-D@ietf.org> --NextPart-- From tom111.taylor@bell.net Fri Jul 2 19:01:34 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 346C13A6803 for ; Fri, 2 Jul 2010 19:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.852 X-Spam-Level: X-Spam-Status: No, score=0.852 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUxhBex3nCE0 for ; Fri, 2 Jul 2010 19:01:33 -0700 (PDT) Received: from blu0-omc2-s27.blu0.hotmail.com (blu0-omc2-s27.blu0.hotmail.com [65.55.111.102]) by core3.amsl.com (Postfix) with ESMTP id 43D2B3A659C for ; Fri, 2 Jul 2010 19:01:33 -0700 (PDT) Received: from BLU0-SMTP89 ([65.55.111.71]) by blu0-omc2-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Jul 2010 19:01:44 -0700 X-Originating-IP: [70.26.17.94] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.26.17.94]) by BLU0-SMTP89.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Jul 2010 19:01:44 -0700 Date: Fri, 02 Jul 2010 22:01:41 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: ancp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jul 2010 02:01:44.0688 (UTC) FILETIME=[AFF52F00:01CB1A53] Subject: [ANCP] Two more base protocol issues X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 02:01:34 -0000 There is normative text on Transaction IDs in section 5.4.5 of the -09 version of the base protocol specification. The last sentence of the paragraph beginning: "In the new message paradigm ..." manages to raise two different issues. The sentence reads: "In the event of an ANCP transport protocol failure, all pending ANCP messages destined to the disconnected recipient can be discarded until the transport is re- established following which the Transaction Identifier is re- initialized." Issue 1: what normative level is implied by "can be discarded": MAY, SHOULD, or MUST? Issue 2: if Transaction IDs are re-initialized, to what value are they re-in itialized? Tom Taylor From tom111.taylor@bell.net Sat Jul 3 13:05:05 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01B4E3A6905 for ; Sat, 3 Jul 2010 13:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.926 X-Spam-Level: X-Spam-Status: No, score=0.926 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcywGDi9VZjY for ; Sat, 3 Jul 2010 13:05:04 -0700 (PDT) Received: from blu0-omc2-s16.blu0.hotmail.com (blu0-omc2-s16.blu0.hotmail.com [65.55.111.91]) by core3.amsl.com (Postfix) with ESMTP id 4520C3A681F for ; Sat, 3 Jul 2010 13:05:04 -0700 (PDT) Received: from BLU0-SMTP7 ([65.55.111.71]) by blu0-omc2-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 3 Jul 2010 13:05:16 -0700 X-Originating-IP: [70.26.17.94] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.26.17.94]) by BLU0-SMTP7.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 3 Jul 2010 13:05:15 -0700 Date: Sat, 03 Jul 2010 16:05:12 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: ancp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jul 2010 20:05:15.0772 (UTC) FILETIME=[0D955BC0:01CB1AEB] Subject: [ANCP] ASCII or UTF-8? X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 20:05:05 -0000 A number of places in the base protocol document specify ASCII strings. Should that be UTF-8 instead? Tom Taylor From tom111.taylor@bell.net Sat Jul 3 13:42:22 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 738BB3A65A5 for ; Sat, 3 Jul 2010 13:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.495 X-Spam-Level: * X-Spam-Status: No, score=1.495 tagged_above=-999 required=5 tests=[MSGID_FROM_MTA_HEADER=1.495] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgwJEjGnZhxI for ; Sat, 3 Jul 2010 13:42:16 -0700 (PDT) Received: from blu0-omc2-s28.blu0.hotmail.com (blu0-omc2-s28.blu0.hotmail.com [65.55.111.103]) by core3.amsl.com (Postfix) with ESMTP id 3F8553A68C2 for ; Sat, 3 Jul 2010 13:42:13 -0700 (PDT) Received: from BLU0-SMTP23 ([65.55.111.72]) by blu0-omc2-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 3 Jul 2010 13:42:12 -0700 X-Originating-IP: [70.26.17.94] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.26.17.94]) by BLU0-SMTP23.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 3 Jul 2010 13:42:12 -0700 Date: Sat, 03 Jul 2010 16:42:08 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: ancp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jul 2010 20:42:12.0608 (UTC) FILETIME=[36EBB000:01CB1AF0] Subject: [ANCP] ANCP version/sub-version registries X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 20:42:22 -0000 The base protocol draft currently has two separate registries for ANCP version and ANCP sub-version. I'm not sure what these are good for, separately. My own suggestion is for a combined version.sub-version registry, the use of which would be to cross-reference version.sub-version values to their defining references. The first two entries would be: Version Reference 3.1 Pre-standard 3.2 RFC XXXX Comments? Tom Taylor From tom111.taylor@bell.net Sat Jul 3 16:38:33 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 458793A68CE for ; Sat, 3 Jul 2010 16:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.899 X-Spam-Level: ** X-Spam-Status: No, score=2.899 tagged_above=-999 required=5 tests=[AWL=-1.404, BAYES_99=3.5, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyqiUYmlkTk9 for ; Sat, 3 Jul 2010 16:38:27 -0700 (PDT) Received: from blu0-omc2-s21.blu0.hotmail.com (blu0-omc2-s21.blu0.hotmail.com [65.55.111.96]) by core3.amsl.com (Postfix) with ESMTP id 25FDD3A68E1 for ; Sat, 3 Jul 2010 16:38:27 -0700 (PDT) Received: from BLU0-SMTP87 ([65.55.111.71]) by blu0-omc2-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 3 Jul 2010 16:37:28 -0700 X-Originating-IP: [70.26.17.94] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.26.17.94]) by BLU0-SMTP87.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 3 Jul 2010 16:37:28 -0700 Date: Sat, 03 Jul 2010 19:37:24 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: ancp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jul 2010 23:37:28.0492 (UTC) FILETIME=[B2E03EC0:01CB1B08] Subject: [ANCP] Command code registry X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 23:38:33 -0000 The base protocol document currently defines the Command TLV but specifies no contents. Despite that, it specifies a Command Code registry. We need at least some text to justify the existence of this registry. I propose the following addition at a suitable point in the documentation of the Command TLV: "The contents of this TLV MUST be specified as a sequence of one or more "commands", each beginning with a one-byte Command Code and possibly including other data following the Command Code. An IANA registry has been established for Command Code values. This document reserves the Command Code value 0 as an initial entry in the registry." If no one objects, I will add this text. It is consistent with what we did in the multicast extensions document. Tom Taylor From tom111.taylor@bell.net Sat Jul 3 17:09:55 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31CA43A68A0 for ; Sat, 3 Jul 2010 17:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.601 X-Spam-Level: *** X-Spam-Status: No, score=3.601 tagged_above=-999 required=5 tests=[AWL=-0.702, BAYES_99=3.5, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QCr1UfrWxwE for ; Sat, 3 Jul 2010 17:09:49 -0700 (PDT) Received: from blu0-omc2-s16.blu0.hotmail.com (blu0-omc2-s16.blu0.hotmail.com [65.55.111.91]) by core3.amsl.com (Postfix) with ESMTP id 0C63D3A6856 for ; Sat, 3 Jul 2010 17:09:48 -0700 (PDT) Received: from BLU0-SMTP14 ([65.55.111.71]) by blu0-omc2-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 3 Jul 2010 17:09:48 -0700 X-Originating-IP: [70.26.17.94] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.26.17.94]) by BLU0-SMTP14.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 3 Jul 2010 17:09:48 -0700 Date: Sat, 03 Jul 2010 20:09:44 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: ancp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jul 2010 00:09:48.0417 (UTC) FILETIME=[37294F10:01CB1B0D] Subject: [ANCP] Registration procedures for ANCP IANA registries X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2010 00:09:55 -0000 We have to specify registration procedures for our ANCP registries. For now I'll put "IETF Consensus" for everything, but people should think about what we really need. Tom Taylor From wdec@cisco.com Tue Jul 6 03:13:01 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AF443A684E for ; Tue, 6 Jul 2010 03:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.555 X-Spam-Level: X-Spam-Status: No, score=-9.555 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuOOQlv4pRjP for ; Tue, 6 Jul 2010 03:13:00 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 412483A687F for ; Tue, 6 Jul 2010 03:13:00 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABKfMkyrR7H+/2dsb2JhbACgBHGkJZophSUEiDqCLA X-IronPort-AV: E=Sophos;i="4.53,545,1272844800"; d="scan'208";a="222110773" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 06 Jul 2010 10:13:02 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o66ACicQ029137; Tue, 6 Jul 2010 10:13:01 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Jul 2010 12:12:59 +0200 Received: from 10.55.215.35 ([10.55.215.35]) by XMB-AMS-111.cisco.com ([144.254.74.86]) with Microsoft Exchange Server HTTP-DAV ; Tue, 6 Jul 2010 10:13:00 +0000 User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Tue, 06 Jul 2010 12:13:26 +0200 From: Wojciech Dec To: Tom Taylor , Message-ID: Thread-Topic: [ANCP] Two more base protocol issues Thread-Index: Acsc899ZRBOdxiGQi0y6rwKmWnC5dQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 06 Jul 2010 10:12:59.0985 (UTC) FILETIME=[CFD7D410:01CB1CF3] Subject: Re: [ANCP] Two more base protocol issues X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 10:13:01 -0000 (Co-Chair hat off) On 03/07/2010 04:01, "Tom Taylor" wrote: > There is normative text on Transaction IDs in section 5.4.5 of the -09 version > of the base protocol specification. The last sentence of the paragraph > beginning: "In the new message paradigm ..." manages to raise two different > issues. The sentence reads: > > "In the event of an ANCP transport protocol failure, > all pending ANCP messages destined to the disconnected recipient can > be discarded until the transport is re- established following which > the Transaction Identifier is re- initialized." > > Issue 1: what normative level is implied by "can be discarded": MAY, SHOULD, > or MUST? SHOULD. Given that a fair bit of messages require stateful behavior, and that we have no ANCP data-base versioning, discarding should be the current behaviour. > > Issue 2: if Transaction IDs are re-initialized, to what value are they re-in > itialized? Around the time of the multicast extensions design team we had a fair bit of discussion about transaction id's in general. From what I recall, the compromise was that transaction id's were to be always set to 0x0000 when not used, and (re)initialized to a random value in the range 0x0001 - 0xffff range. -Woj. > > Tom Taylor > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp From HaagT@telekom.de Wed Jul 7 02:59:58 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D61F3A6784 for ; Wed, 7 Jul 2010 02:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5wryf-sBnAt for ; Wed, 7 Jul 2010 02:59:57 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id B6C4B3A65A5 for ; Wed, 7 Jul 2010 02:59:56 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail31.telekom.de with ESMTP; 07 Jul 2010 11:59:54 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Jul 2010 11:59:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Jul 2010 11:59:53 +0200 Message-ID: <5661758E3E93364685B91DD8272F28760325BCB3@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP version/sub-version registries Thread-Index: Acsa8ECAXU7ofNeWT3Wd7H2dFnR9tACxfOxA References: From: To: , X-OriginalArrivalTime: 07 Jul 2010 09:59:54.0517 (UTC) FILETIME=[2614AC50:01CB1DBB] Subject: Re: [ANCP] ANCP version/sub-version registries X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 09:59:58 -0000 Basic intention for separate Pre-standard and RFC was based on = discussion at Stockholm meeting last year regarding migration pre RFC = implementation to RFC-standard based implementation.=20 The reason for that separation was to have an identifier for distinguish = protocol versions for migration. For given reason at that point the working group already prepared the = ground for alternative 1 (parallel registry). Keeping in mind that GSMPv3 defined one byte for version and ancp = defined two half bytes (version.subversion) I support a combined = registry. This provides three stages for that version field: 0 3 GSMPv3 (according RFC3292, page 111; there is only one byte, no = half bytes for version field =3D version) 3 1 Pre-Standard (protocol draft 00...10; two half bytes for version = field =3D version.subversion) 3 2 RFC (two half byts for version field =3D version.subversion) >From my point of view "0 3" is already registred as GSMPv3. For official = registry "3 2" is needed for register ANCP. "3 1" is needed temporarily = for migration of existing implementations which may also be registered = too. Regards Thomas Haag -----Urspr=FCngliche Nachricht----- Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von = Tom Taylor Gesendet: Samstag, 3. Juli 2010 22:42 An: ancp@ietf.org Betreff: [ANCP] ANCP version/sub-version registries The base protocol draft currently has two separate registries for ANCP = version=20 and ANCP sub-version. I'm not sure what these are good for, separately. = My own=20 suggestion is for a combined version.sub-version registry, the use of = which=20 would be to cross-reference version.sub-version values to their defining = references. The first two entries would be: Version Reference 3.1 Pre-standard 3.2 RFC XXXX Comments? Tom Taylor _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From wdec@cisco.com Thu Jul 8 02:26:01 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39BC23A69A5 for ; Thu, 8 Jul 2010 02:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.263 X-Spam-Level: X-Spam-Status: No, score=-10.263 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbWaPFNvptpU for ; Thu, 8 Jul 2010 02:26:00 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B02E23A67D1 for ; Thu, 8 Jul 2010 02:25:56 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioHAMM2NUyrRN+K/2dsb2JhbACTYoxBcaRGmnmFJQSIP4Is X-IronPort-AV: E=Sophos;i="4.53,557,1272844800"; d="scan'208";a="342088736" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 08 Jul 2010 09:26:00 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o689Pdm3007842 for ; Thu, 8 Jul 2010 09:26:00 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Jul 2010 11:25:52 +0200 Received: from 10.55.215.35 ([10.55.215.35]) by XMB-AMS-111.cisco.com ([144.254.74.86]) with Microsoft Exchange Server HTTP-DAV ; Thu, 8 Jul 2010 09:25:52 +0000 User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Thu, 08 Jul 2010 11:26:23 +0200 From: Wojciech Dec To: Message-ID: Thread-Topic: ANCP - Requested session has been scheduled for IETF 78 Thread-Index: AcseeJ0NqQYkW57jw0iTmCDZUUMlSgABwR8I In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 Jul 2010 09:25:52.0536 (UTC) FILETIME=[8F60D980:01CB1E7F] Subject: [ANCP] FW: ANCP - Requested session has been scheduled for IETF 78 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 09:26:01 -0000 Hi All, Please note that our ANCP WG meeting has been re-scheduled to Tuesday. Below is the scheduled session information followed by the information of sessions that you have requested. ANCP Session 1 (1.5 hours) Tuesday, Afternoon Session III 1710-1810 Room Name: 0.2 Berlin ---------------------------------------------- Requested Information: --------------------------------------------------------- Working Group Name: ancp Area Name: Internet Area Session Requester: Matthew Bocci Number of Sessions: 1 Length of Session(s): 1.5 hours ------ End of Forwarded Message From root@core3.amsl.com Sun Jul 11 08:30:05 2010 Return-Path: X-Original-To: ancp@ietf.org Delivered-To: ancp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 12EC23A6839; Sun, 11 Jul 2010 08:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100711153005.12EC23A6839@core3.amsl.com> Date: Sun, 11 Jul 2010 08:30:02 -0700 (PDT) Cc: ancp@ietf.org Subject: [ANCP] I-D Action:draft-ietf-ancp-protocol-10.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 15:30:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access Node Control Protocol Working Group of the IETF. Title : Protocol for Access Node Control Mechanism in Broadband Networks Author(s) : S. Wadhwa, et al. Filename : draft-ietf-ancp-protocol-10.txt Pages : 66 Date : 2010-07-11 This document describes the Access Node Control Protocol (ANCP). ANCP operates between a Network Access Server (NAS) and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform QoS-related, service-related and subscriber- related operations. Use cases for ANCP are documented in RFC 5851. As well as describing the base ANCP protocol, this document specifies capabilities for Digital Subscriber Line (DSL) topology discovery, line configuration, and line testing. The design of ANCP anticipates the specification in other documents of extensions to the protocol to support additional ANCP protocol capabilities covering other use cases and other technologies. ANCP is based on GSMPv3 (RFC 3292), but with many modifications and extensions, to the point that the two protocols are not interoperable. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ancp-protocol-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-11082714.I-D@ietf.org> --NextPart-- From tom111.taylor@bell.net Sun Jul 11 08:39:31 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BE2B3A69B4 for ; Sun, 11 Jul 2010 08:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.11 X-Spam-Level: * X-Spam-Status: No, score=1.11 tagged_above=-999 required=5 tests=[AWL=0.492, BAYES_40=-0.185, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JA-fx-oWKfey for ; Sun, 11 Jul 2010 08:39:30 -0700 (PDT) Received: from blu0-omc2-s17.blu0.hotmail.com (blu0-omc2-s17.blu0.hotmail.com [65.55.111.92]) by core3.amsl.com (Postfix) with ESMTP id 831783A67B1 for ; Sun, 11 Jul 2010 08:39:30 -0700 (PDT) Received: from BLU0-SMTP12 ([65.55.111.72]) by blu0-omc2-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Jul 2010 08:39:37 -0700 X-Originating-IP: [70.26.17.94] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.26.17.94]) by BLU0-SMTP12.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Jul 2010 08:39:37 -0700 Date: Sun, 11 Jul 2010 11:39:34 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: ancp@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jul 2010 15:39:37.0213 (UTC) FILETIME=[44C442D0:01CB210F] Subject: [ANCP] [Fwd: New Version Notification for draft-ietf-ancp-protocol-10] X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 15:39:31 -0000 This version contains a minimum of technical changes from the -09 version, but a lot of text has been moved and a fair amount was modified to achieve a more uniform presentation format and eliminate redundancy. An appendix to the -10 version maps the -09 sections to their new locations. The text was also modified to emphasize that this is a specification of ANCP, rather than an extension of GSMPv3. I have a version manually highlighted to show changed text, if anyone wants it. I would have to bring it up to date because some small changes were incorporated after I created it. We still need responses to a number of the issues I raised on the list. Editor's Notes have been added to the text to track these open issues. Tom Taylor -------- Original Message -------- Subject: New Version Notification for draft-ietf-ancp-protocol-10 Date: Sun, 11 Jul 2010 08:27:15 -0700 (PDT) ... A new version of I-D, draft-ietf-ancp-protocol-10.txt has been successfully submitted by Tom Taylor and posted to the IETF repository. Filename: draft-ietf-ancp-protocol Revision: 10 Title: Protocol for Access Node Control Mechanism in Broadband Networks Creation_date: 2010-07-11 WG ID: ancp Number_of_pages: 66 Abstract: This document describes the Access Node Control Protocol (ANCP). ANCP operates between a Network Access Server (NAS) and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform QoS-related, service-related and subscriber- related operations. Use cases for ANCP are documented in RFC 5851. As well as describing the base ANCP protocol, this document specifies capabilities for Digital Subscriber Line (DSL) topology discovery, line configuration, and line testing. The design of ANCP anticipates the specification in other documents of extensions to the protocol to support additional ANCP protocol capabilities covering other use cases and other technologies. ANCP is based on GSMPv3 (RFC 3292), but with many modifications and extensions, to the point that the two protocols are not interoperable. The IETF Secretariat. From wdec@cisco.com Mon Jul 19 07:32:41 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 413943A69F6 for ; Mon, 19 Jul 2010 07:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.336 X-Spam-Level: X-Spam-Status: No, score=-9.336 tagged_above=-999 required=5 tests=[AWL=-0.814, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fxfb1tDrnTb for ; Mon, 19 Jul 2010 07:32:39 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9BC3E3A689B for ; Mon, 19 Jul 2010 07:32:39 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0FAPz+Q0xAZnwN/2dsb2JhbACTNIw/Yw6oKppKhSUEiFeCNA X-IronPort-AV: E=Sophos;i="4.55,226,1278288000"; d="scan'208";a="134173298" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 19 Jul 2010 14:32:53 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6JEWodu015036; Mon, 19 Jul 2010 14:32:53 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 16:32:51 +0200 Received: from 10.55.215.36 ([10.55.215.36]) by XMB-AMS-111.cisco.com ([144.254.74.86]) with Microsoft Exchange Server HTTP-DAV ; Mon, 19 Jul 2010 14:32:50 +0000 User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Mon, 19 Jul 2010 16:32:55 +0200 From: Wojciech Dec To: Message-ID: Thread-Topic: ANCP NAS MIB WG I-D? Thread-Index: AcsnT0aRaRTvep9GPkusF5GfzmKfiw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 19 Jul 2010 14:32:51.0255 (UTC) FILETIME=[44559470:01CB274F] Cc: "Bocci, Matthew \(Matthew\)" Subject: [ANCP] ANCP NAS MIB WG I-D? X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 14:32:41 -0000 Hello All, During IETF77 we reviewed a proposal for an ANCP NAS MIB draft ( http://www.ietf.org/id/draft-rohit-ancp-nas-mib-01.txt). Such work is within the defined scope of our WG. With this e-mail we would like to ask if anyone sees any issues with accepting this document as a WG I-D and beginning to track it under our milestones. Regards, Matthew & Woj. From wdec@cisco.com Tue Jul 27 00:39:16 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4465C3A69A5 for ; Tue, 27 Jul 2010 00:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.301 X-Spam-Level: X-Spam-Status: No, score=-10.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnWX963j-QNm for ; Tue, 27 Jul 2010 00:39:15 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5D82A3A6831 for ; Tue, 27 Jul 2010 00:39:15 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFALcpTkxAZnwN/2dsb2JhbACTG4xKcaVZm0KFNgSIaII6 X-IronPort-AV: E=Sophos;i="4.55,266,1278288000"; d="scan'208";a="139624384" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 27 Jul 2010 07:39:36 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6R7dZd8000493; Tue, 27 Jul 2010 07:39:36 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Jul 2010 09:39:36 +0200 Received: from 10.55.91.237 ([10.55.91.237]) by XMB-AMS-111.cisco.com ([144.254.74.86]) with Microsoft Exchange Server HTTP-DAV ; Tue, 27 Jul 2010 07:39:36 +0000 User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Tue, 27 Jul 2010 09:39:35 +0200 From: Wojciech Dec To: Message-ID: Thread-Topic: Scribe? Thread-Index: AcstXtvr1Y8Lrp4iwkWYjAO91AvPGQ== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Jul 2010 07:39:36.0391 (UTC) FILETIME=[DCBF9570:01CB2D5E] Cc: "Bocci, Matthew \(Matthew\)" Subject: [ANCP] Scribe? X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 07:39:16 -0000 Hello All, we're kindly calling for volunteers to be the scribe/note taker at our meeting. Please let us know. Regards, Woj & Matthew From flefauch@cisco.com Tue Jul 27 00:59:36 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DF623A6A3C for ; Tue, 27 Jul 2010 00:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vXeKSgLitVY for ; Tue, 27 Jul 2010 00:59:35 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 283003A6A18 for ; Tue, 27 Jul 2010 00:59:35 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: logo.gif, green.gif : 837, 87 X-IronPort-AV: E=Sophos;i="4.55,266,1278288000"; d="gif'147?scan'147,208,217,147";a="564306535" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 27 Jul 2010 07:59:57 +0000 Received: from sjc-vpn7-1295.cisco.com (sjc-vpn7-1295.cisco.com [10.21.149.15]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6R7xtLD000128; Tue, 27 Jul 2010 07:59:56 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-211--884790881 From: Francois Le Faucheur In-Reply-To: Date: Tue, 27 Jul 2010 10:00:03 +0200 Message-Id: <2E939369-14CC-4919-A13C-BB78C041A043@cisco.com> References: To: Wojciech Dec X-Mailer: Apple Mail (2.1081) Cc: "Bocci, Matthew \(Matthew\)" , ancp@ietf.org Subject: Re: [ANCP] Scribe? X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 07:59:36 -0000 --Apple-Mail-211--884790881 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, I can be a scribe. Francois On 27 Jul 2010, at 09:39, Wojciech Dec wrote: > Hello All, >=20 > we're kindly calling for volunteers to be the scribe/note taker at our > meeting. Please let us know. >=20 > Regards, > Woj & Matthew >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp Francois Le Faucheur Distinguished Engineer Corporate Development flefauch@cisco.com Phone: +33 49 723 2619 Mobile: +33 6 19 98 50 90 Cisco Systems France Greenside 400 Ave de Roumanille 06410 Sophia Antipolis France Cisco.com =20 Think before you print. This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, = Directeur de la publication: Jean-Luc Michel Givone. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --Apple-Mail-211--884790881 Content-Type: multipart/related; type="text/html"; boundary=Apple-Mail-212--884790881 --Apple-Mail-212--884790881 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hello = All,

we're kindly calling for volunteers to be the scribe/note = taker at our
meeting. Please let us know.

Regards,
Woj = & = Matthew

_______________________________________________
ANCP = mailing list
ANCP@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ancp


Francois Le = Faucheur
Distinguished = Engineer
Corporate Development

Cisco Systems = France
Greenside
400 Ave de Roumanille
06410 Sophia = Antipolis
France
Cisco.com

 
 Think before you = print.
R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 --Apple-Mail-212--884790881 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=green.gif Content-Type: image/gif; name="green.gif" Content-Id: R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --Apple-Mail-212--884790881-- --Apple-Mail-211--884790881-- From tom111.taylor@bell.net Wed Jul 28 03:29:35 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBCA83A6A6B for ; Wed, 28 Jul 2010 03:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.804 X-Spam-Level: X-Spam-Status: No, score=0.804 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAkONFFiJlKb for ; Wed, 28 Jul 2010 03:29:30 -0700 (PDT) Received: from blu0-omc2-s33.blu0.hotmail.com (blu0-omc2-s33.blu0.hotmail.com [65.55.111.108]) by core3.amsl.com (Postfix) with ESMTP id 191413A68E1 for ; Wed, 28 Jul 2010 03:29:29 -0700 (PDT) Received: from BLU0-SMTP41 ([65.55.111.71]) by blu0-omc2-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Jul 2010 03:29:52 -0700 X-Originating-IP: [130.129.118.179] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [130.129.118.179] ([130.129.118.179]) by BLU0-SMTP41.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Jul 2010 03:29:52 -0700 Date: Wed, 28 Jul 2010 06:29:50 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: ancp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2010 10:29:52.0483 (UTC) FILETIME=[D06D4330:01CB2E3F] Subject: [ANCP] Implementation of Access-Aggregation-Circuit-ID-Binary TLV X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 10:29:35 -0000 Has anyone implemented the Access-Aggregation-Circuit-ID-Binary TLV? If so, would they please tell us: - whether the 12 bit VLAN identifier is placed in the most or least significant bits of the 32-bit word - whether the first word contains the inner or the outer VLAN identifer. Tom Taylor From tom111.taylor@bell.net Wed Jul 28 03:43:31 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D877B3A68B0 for ; Wed, 28 Jul 2010 03:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.804 X-Spam-Level: X-Spam-Status: No, score=0.804 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOfkAilM+bCL for ; Wed, 28 Jul 2010 03:43:31 -0700 (PDT) Received: from blu0-omc2-s11.blu0.hotmail.com (blu0-omc2-s11.blu0.hotmail.com [65.55.111.86]) by core3.amsl.com (Postfix) with ESMTP id D337B3A67EE for ; Wed, 28 Jul 2010 03:43:30 -0700 (PDT) Received: from BLU0-SMTP18 ([65.55.111.72]) by blu0-omc2-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Jul 2010 03:43:53 -0700 X-Originating-IP: [130.129.118.179] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [130.129.118.179] ([130.129.118.179]) by BLU0-SMTP18.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Jul 2010 03:43:52 -0700 Date: Wed, 28 Jul 2010 06:43:50 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: ancp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2010 10:43:53.0139 (UTC) FILETIME=[C57F3030:01CB2E41] Subject: [ANCP] Base protocol: Relationship of capabilities to technology X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 10:43:32 -0000 At the meeting I presented three alternatives for handling the relationship of capabilities to technology. The meeting accepted the third alternative. This alternative requires the following changes to existing text: 1) The existing Tech Type field in the adjacency message (see Figure 3 in section 4.3.1) will be relabelled to "Reserved". That may affect existing implementations, since they have presumably been sending 0x05 in some cases and should now send 0x00. On the other hand, the receiver MUST ignore the field. 2) The following text will be added at an appropriate point (probably the IANA section): "The specification of a given capability must indicate whether the capability is specific to a given technology or technology-independent." My editorial policy has been to use ordinary language for instructions to specification writers, while using RFC 2119 language for instructions to implementors. That is reflected in the above text. Please comment if you think a different policy should be followed. Tom Taylor From tom111.taylor@bell.net Wed Jul 28 06:12:30 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F03DE28C194 for ; Wed, 28 Jul 2010 06:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.804 X-Spam-Level: X-Spam-Status: No, score=0.804 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V371VNGZTfhW for ; Wed, 28 Jul 2010 06:12:28 -0700 (PDT) Received: from blu0-omc2-s19.blu0.hotmail.com (blu0-omc2-s19.blu0.hotmail.com [65.55.111.94]) by core3.amsl.com (Postfix) with ESMTP id 4E1D428C192 for ; Wed, 28 Jul 2010 06:12:28 -0700 (PDT) Received: from BLU0-SMTP36 ([65.55.111.72]) by blu0-omc2-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Jul 2010 06:12:51 -0700 X-Originating-IP: [130.129.118.179] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [130.129.118.179] ([130.129.118.179]) by BLU0-SMTP36.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Jul 2010 06:12:50 -0700 Date: Wed, 28 Jul 2010 09:12:47 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: ancp@ietf.org, "Poscic, Kristian (Kristian)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2010 13:12:51.0032 (UTC) FILETIME=[94E56D80:01CB2E56] Subject: [ANCP] New multicast capability -- Committed multicast bandwidth reporting X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 13:12:30 -0000 Apologies to Kristian for taking so long to understand his use case. The basic requirement is to keep the NAS aware of the total amount of multicast bandwidth that the AN has allocated to each access line. The NAS uses this information to tune its scheduling as a router. To meet this requirement, the following is proposed: 1) Define a new capability, Committed multicast bandwidth reporting (0xTBD). 2) Implementation of this capability requires support of: - the Provisioning message; - a new message, Multicast Bandwidth Usage Report; - two new TLVs, Bandwidth-Usage, and Bandwidth-Report-Delay. 3) The Multicast Bandwidth Usage Report message is sent from the AN to NAS. It contains one or more instances of the Bandwidth-Usage TLV. The AN MUST send a Multicast Bandwidth Usage Report message whenever the total multicast bandwidth allocated to a given access line changes. Within the message, the AN MUST identify the access line and indicate the total multicast bandwidth amount by including an instance of the Bandwidth-Usage TLV. To reduce the messaging rate, the NAS MAY provision a buffering period by including the Bandwidth-Report-Delay TLV in a Provisioning message sent to the AN. If a non-zero value is provided in the Bandwidth-Report-Delay TLV, the AN at any given moment is in one of two states: not-buffering, or buffering. The AN enters buffering state if it is in not-buffering state and the multicast bandwidth amount allocated to some access line changes. It leaves buffering state when the AN sends a Multicast Bandwidth Usage Report. Upon entry to the buffering state, the AN MUST start a buffering timer and create a Multicast Bandwidth Usage Report message containing a Bandwidth-Usage TLV for the triggering access line, but MUST NOT send it. If a multicast bandwidth change occurs for another access line, the AN MUST add a new Bandwidth-Usage TLV to the message for that additional line. If a multicast bandwidth change occurs for a line for which a Bandwidth-Usage TLV is already present in the buffered report, the AN MUST update the Bandwidth-Usage TLV to contain the new value, rather than adding another Bandwidth-Usage TLV for the same access line. The buffering timer expires after the period provided by the Bandwidth-Report-Delay TLV. When it expires, the AN MUST send the Multicast Bandwidth Usage Report message that it has been accumulating to the NAS. The AN MAY choose to send the message before the timer expires, in which case it MUST clear the buffering timer when the message is sent. In either case, the AN enters the not-buffering state as a result. Report buffering implies that NAS reaction to changes in multicast bandwidth usage is delayed by the amount of the buffering period. The choice of buffering period must take this into consideration. 4) The Bandwidth-Usage TLV contains a 32-bit multicast bandwidth amount (kbits/s), followed by a Target TLV identifying the access line for which a total multicast bandwidth amount is being reported. 5) The Bandwidth-Report-Delay TLV contains a 32-bit unsigned integer giving the amount of time (ms) a Multicast Bandwidth Usage Report message must be buffered before it is sent, as described above. There is no interaction between this capability and the others described in the multicast extensions document. Please comment. Tom Taylor From tom111.taylor@bell.net Wed Jul 28 07:12:21 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8093228C16C for ; Wed, 28 Jul 2010 07:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.804 X-Spam-Level: X-Spam-Status: No, score=0.804 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ou1sDOGeRguM for ; Wed, 28 Jul 2010 07:12:20 -0700 (PDT) Received: from blu0-omc2-s26.blu0.hotmail.com (blu0-omc2-s26.blu0.hotmail.com [65.55.111.101]) by core3.amsl.com (Postfix) with ESMTP id 5408C28C152 for ; Wed, 28 Jul 2010 07:12:19 -0700 (PDT) Received: from BLU0-SMTP33 ([65.55.111.71]) by blu0-omc2-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Jul 2010 07:12:42 -0700 X-Originating-IP: [130.129.118.179] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [130.129.118.179] ([130.129.118.179]) by BLU0-SMTP33.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Jul 2010 07:12:42 -0700 Date: Wed, 28 Jul 2010 10:12:39 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: ancp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2010 14:12:42.0677 (UTC) FILETIME=[F1AEF650:01CB2E5E] Subject: [ANCP] Additional base protocol issue resolutions X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 14:12:21 -0000 The meeting agreed on the following resolutions to ANCP base issues yesterday. I'm looking for confirmation or objections on the list. 1) We will have a single combined version registry, more or less as it appears in the -10 version of the base protocol document. That is, the two initial entries will be: 3.1 Pre-standard 3.2 ANCP version 1 2) Tech Type 0x00 will be registered as "Not technology specific", as proposed. 3) Informative text will be added in the IANA Function Code registry to say that extensions to ANCP may establish sub-registries for X-Function Code values for specific values of the Function Code. 4) Text fields will be defined as UTF-8 rather than ASCII, with additional text as necessary to reassure people that UTF-8 encoding of the ASCII character set is identical to US-ASCII. An optional character set identification parameter will be added where necessary. Default in the absence of the parameter will be ASCII. It may take some research, but I'll make sure I have everything in place to get this right. Still to resolve: Whether ANCP should use GSMPv3 IANA registries or not, as discussed a few weeks ago. Tom Taylor From Lothar.Reith@detecon.com Wed Jul 28 08:17:16 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CDF93A694C for ; Wed, 28 Jul 2010 08:17:16 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 480uf2U1E+08 for ; Wed, 28 Jul 2010 08:17:15 -0700 (PDT) Received: from dtc034.detecon.net (dtc034.detecon.net [194.25.60.134]) by core3.amsl.com (Postfix) with ESMTP id 38D6228C16A for ; Wed, 28 Jul 2010 08:17:13 -0700 (PDT) Received: from unknown (HELO dc00356.detecon.com) ([172.16.10.106]) by relay.dtc034.detecon.net with ESMTP; 28 Jul 2010 17:17:35 +0200 Received: from dc302v.detecon.com ([172.16.10.41]) by dc00356.detecon.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Jul 2010 17:17:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Jul 2010 17:17:34 +0200 Message-ID: <8AAA8EFE7E4B594A86052935CF66E62E018C6D38@dc302v.detecon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] New multicast capability -- Committed multicast bandwidthreporting Thread-Index: AcsuVpgYZeIfw8VsQm2Adk5rDxircQADcNZA References: From: "Reith, Lothar" To: "Tom Taylor" , , "Poscic, Kristian (Kristian)" X-OriginalArrivalTime: 28 Jul 2010 15:17:35.0673 (UTC) FILETIME=[02170290:01CB2E68] Subject: Re: [ANCP] New multicast capability -- Committed multicast bandwidthreporting X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 15:17:16 -0000 Dear all, I would like to request alignment of the terminology with the ANCP = framework. For example the term "committed multicast bandwidth" should be replaced = by "delegated multicast bandwidth".=20 With regards to the term "usage" I would like to request clarification, = if it is rather a reporting about a change in the amount of delegated = multicast bandwidth, and not about actual usage of that bandwidth e.g. = for a certain channel or with a certain amount of usage bytes = transmitted. I believe, that the word "usage" may be inappropriate, if = the reporting is just a reporting about a change in the amount of = delegated multicast bandwidth, which strictly speaking would be a change = in bandwidth reservation, but not necessarily in actual bandwidth usage. Best Regards, Lothar -----Urspr=FCngliche Nachricht----- Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von = Tom Taylor Gesendet: Mittwoch, 28. Juli 2010 15:13 An: ancp@ietf.org; Poscic, Kristian (Kristian) Betreff: [ANCP] New multicast capability -- Committed multicast = bandwidthreporting Apologies to Kristian for taking so long to understand his use case. The = basic requirement is to keep the NAS aware of the total amount of = multicast bandwidth that the AN has allocated to each access line. The = NAS uses this information to tune its scheduling as a router. To meet = this requirement, the following is proposed: 1) Define a new capability, Committed multicast bandwidth reporting = (0xTBD). 2) Implementation of this capability requires support of: - the Provisioning message; - a new message, Multicast Bandwidth Usage Report; - two new TLVs, Bandwidth-Usage, and Bandwidth-Report-Delay. 3) The Multicast Bandwidth Usage Report message is sent from the AN to = NAS. It contains one or more instances of the Bandwidth-Usage TLV. The AN MUST send a Multicast Bandwidth Usage Report message whenever the = total multicast bandwidth allocated to a given access line changes. = Within the message, the AN MUST identify the access line and indicate = the total multicast bandwidth amount by including an instance of the = Bandwidth-Usage TLV. To reduce the messaging rate, the NAS MAY provision a buffering period = by including the Bandwidth-Report-Delay TLV in a Provisioning message = sent to the AN. If a non-zero value is provided in the = Bandwidth-Report-Delay TLV, the AN at any given moment is in one of two = states: not-buffering, or buffering. The AN enters buffering state if it = is in not-buffering state and the multicast bandwidth amount allocated = to some access line changes. It leaves buffering state when the AN sends = a Multicast Bandwidth Usage Report. Upon entry to the buffering state, the AN MUST start a buffering timer = and create a Multicast Bandwidth Usage Report message containing a = Bandwidth-Usage TLV for the triggering access line, but MUST NOT send = it. If a multicast bandwidth change occurs for another access line, the = AN MUST add a new Bandwidth-Usage TLV to the message for that additional = line. If a multicast bandwidth change occurs for a line for which a = Bandwidth-Usage TLV is already present in the buffered report, the AN = MUST update the Bandwidth-Usage TLV to contain the new value, rather = than adding another Bandwidth-Usage TLV for the same access line. The buffering timer expires after the period provided by the = Bandwidth-Report-Delay TLV. When it expires, the AN MUST send the = Multicast Bandwidth Usage Report message that it has been accumulating = to the NAS. The AN MAY choose to send the message before the timer = expires, in which case it MUST clear the buffering timer when the = message is sent. In either case, the AN enters the not-buffering state = as a result. Report buffering implies that NAS reaction to changes in multicast bandwidth usage is delayed by the amount of the buffering period. The choice of buffering period must take this into consideration. 4) The Bandwidth-Usage TLV contains a 32-bit multicast bandwidth amount = (kbits/s), followed by a Target TLV identifying the access line for = which a total multicast bandwidth amount is being reported. 5) The Bandwidth-Report-Delay TLV contains a 32-bit unsigned integer = giving the amount of time (ms) a Multicast Bandwidth Usage Report = message must be buffered before it is sent, as described above. There is no interaction between this capability and the others described = in the multicast extensions document. Please comment. Tom Taylor _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From tom111.taylor@bell.net Wed Jul 28 08:33:05 2010 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F7D83A68DD for ; Wed, 28 Jul 2010 08:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.496 X-Spam-Level: X-Spam-Status: No, score=-0.496 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WD2pJ3x9hU-Q for ; Wed, 28 Jul 2010 08:33:02 -0700 (PDT) Received: from blu0-omc2-s4.blu0.hotmail.com (blu0-omc2-s4.blu0.hotmail.com [65.55.111.79]) by core3.amsl.com (Postfix) with ESMTP id 595333A6A38 for ; Wed, 28 Jul 2010 08:33:00 -0700 (PDT) Received: from BLU0-SMTP79 ([65.55.111.72]) by blu0-omc2-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Jul 2010 08:33:20 -0700 X-Originating-IP: [130.129.118.179] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [130.129.118.179] ([130.129.118.179]) by BLU0-SMTP79.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Jul 2010 08:33:19 -0700 Date: Wed, 28 Jul 2010 11:33:16 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Reith, Lothar" References: <8AAA8EFE7E4B594A86052935CF66E62E018C6D38@dc302v.detecon.com> In-Reply-To: <8AAA8EFE7E4B594A86052935CF66E62E018C6D38@dc302v.detecon.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 28 Jul 2010 15:33:19.0666 (UTC) FILETIME=[34C0E920:01CB2E6A] Cc: ancp@ietf.org Subject: Re: [ANCP] New multicast capability -- Committed multicast bandwidthreporting X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 15:33:05 -0000 This is about reporting the amount of multicast bandwidth actually used. This is independent of (has nothing to do with) delegated bandwidth. The latter, if negotiated, provides a limit on how much bandwidth the AN can allocate, but does not say how much is actually in use. Reith, Lothar wrote: > Dear all, > > I would like to request alignment of the terminology with the ANCP framework. > > For example the term "committed multicast bandwidth" should be replaced by "delegated multicast bandwidth". > > With regards to the term "usage" I would like to request clarification, if it is rather a reporting about a change in the amount of delegated multicast bandwidth, and not about actual usage of that bandwidth e.g. for a certain channel or with a certain amount of usage bytes transmitted. I believe, that the word "usage" may be inappropriate, if the reporting is just a reporting about a change in the amount of delegated multicast bandwidth, which strictly speaking would be a change in bandwidth reservation, but not necessarily in actual bandwidth usage. > > Best Regards, Lothar > > > > -----Ursprüngliche Nachricht----- > Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von Tom Taylor > Gesendet: Mittwoch, 28. Juli 2010 15:13 > An: ancp@ietf.org; Poscic, Kristian (Kristian) > Betreff: [ANCP] New multicast capability -- Committed multicast bandwidthreporting > > Apologies to Kristian for taking so long to understand his use case. The basic requirement is to keep the NAS aware of the total amount of multicast bandwidth that the AN has allocated to each access line. The NAS uses this information to tune its scheduling as a router. To meet this requirement, the following is > proposed: > > 1) Define a new capability, Committed multicast bandwidth reporting (0xTBD). > > 2) Implementation of this capability requires support of: > > - the Provisioning message; > > - a new message, Multicast Bandwidth Usage Report; > > - two new TLVs, Bandwidth-Usage, and Bandwidth-Report-Delay. > > 3) The Multicast Bandwidth Usage Report message is sent from the AN to NAS. It contains one or more instances of the Bandwidth-Usage TLV. > > The AN MUST send a Multicast Bandwidth Usage Report message whenever the total multicast bandwidth allocated to a given access line changes. Within the message, the AN MUST identify the access line and indicate the total multicast bandwidth amount by including an instance of the Bandwidth-Usage TLV. > > To reduce the messaging rate, the NAS MAY provision a buffering period by including the Bandwidth-Report-Delay TLV in a Provisioning message sent to the AN. If a non-zero value is provided in the Bandwidth-Report-Delay TLV, the AN at any given moment is in one of two states: not-buffering, or buffering. The AN enters buffering state if it is in not-buffering state and the multicast bandwidth amount allocated to some access line changes. It leaves buffering state when the AN sends a Multicast Bandwidth Usage Report. > > Upon entry to the buffering state, the AN MUST start a buffering timer and create a Multicast Bandwidth Usage Report message containing a Bandwidth-Usage TLV for the triggering access line, but MUST NOT send it. If a multicast bandwidth change occurs for another access line, the AN MUST add a new Bandwidth-Usage TLV to the message for that additional line. If a multicast bandwidth change occurs for a line for which a Bandwidth-Usage TLV is already present in the buffered report, the AN MUST update the Bandwidth-Usage TLV to contain the new value, rather than adding another Bandwidth-Usage TLV for the same access line. > > The buffering timer expires after the period provided by the Bandwidth-Report-Delay TLV. When it expires, the AN MUST send the Multicast Bandwidth Usage Report message that it has been accumulating to the NAS. The AN MAY choose to send the message before the timer expires, in which case it MUST clear the buffering timer when the message is sent. In either case, the AN enters the not-buffering state as a result. > > Report buffering implies that NAS reaction to changes in multicast > bandwidth usage is delayed by the amount of the buffering period. > The choice of buffering period must take this into consideration. > > 4) The Bandwidth-Usage TLV contains a 32-bit multicast bandwidth amount (kbits/s), followed by a Target TLV identifying the access line for which a total multicast bandwidth amount is being reported. > > 5) The Bandwidth-Report-Delay TLV contains a 32-bit unsigned integer giving the amount of time (ms) a Multicast Bandwidth Usage Report message must be buffered before it is sent, as described above. > > There is no interaction between this capability and the others described in the multicast extensions document. > > Please comment. > > Tom Taylor > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp > >