From ancp-bounces@ietf.org Mon Dec 8 04:42:08 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6565E3A67D9; Mon, 8 Dec 2008 04:42:08 -0800 (PST) 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 AA8BA3A67D9 for ; Mon, 8 Dec 2008 04:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 Bm9Wz-Wcth7e for ; Mon, 8 Dec 2008 04:42:06 -0800 (PST) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id B839B3A6782 for ; Mon, 8 Dec 2008 04:42:05 -0800 (PST) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id mB8CfuZO011311 for ; Mon, 8 Dec 2008 13:41:57 +0100 Received: from FRVELSMBS11.ad2.ad.alcatel.com ([155.132.6.37]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 8 Dec 2008 13:41:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 8 Dec 2008 13:41:55 +0100 Message-ID: <0458D2EE0C36744BABB36BE37805C29A03016CC2@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG last call for draft-ietf-ancp-framework-07.txt Thread-Index: AclZLWi472QILb2YRiiUO7dT3wLrywAATJCQAADpsIA= From: "BOCCI Matthew" To: X-OriginalArrivalTime: 08 Dec 2008 12:41:56.0330 (UTC) FILETIME=[5ACB9CA0:01C95932] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: [ANCP] WG last call for draft-ietf-ancp-framework-07.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: , Content-Type: multipart/mixed; boundary="===============0893202176==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0893202176== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95932.5AF6663C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C95932.5AF6663C Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable > This email is to start a two week working group last call for > draft-ietf-ancp-framework-07.txt > Please review and provide comments to the list by Monday 22nd > December. >=20 > The following have also kindly offered to review the document: > - Roberta Maglione > - Alan Kavanagh > - John Zhao > - Tom Taylor > - Sven Ooghe > - Francois LeFaucher >=20 >=20 > Best regards >=20 > Matthew >=20 >=20 >=20 >=20 ------_=_NextPart_001_01C95932.5AF6663C Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable WG last call for draft-ietf-ancp-framework-07.txt

This email is to start a two week = working group last call for draft-ietf-ancp-framework-07.txt
Please review and provide comments to = the list by Monday 22nd December.

The following have also kindly offered = to review the document:
- Roberta Maglione
- Alan Kavanagh
- John Zhao
- Tom Taylor
- Sven Ooghe
- Francois LeFaucher


Best regards

Matthew




------_=_NextPart_001_01C95932.5AF6663C-- --===============0893202176== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============0893202176==-- From ancp-bounces@ietf.org Mon Dec 8 04:43:12 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 905903A67D9; Mon, 8 Dec 2008 04:43:12 -0800 (PST) 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 E9D0C3A67D9 for ; Mon, 8 Dec 2008 04:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.206 X-Spam-Level: X-Spam-Status: No, score=-6.206 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 Qn8d1tgH6Rtc for ; Mon, 8 Dec 2008 04:43:11 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id F0FCC3A6782 for ; Mon, 8 Dec 2008 04:43:10 -0800 (PST) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id mB8Ch4D5032530 for ; Mon, 8 Dec 2008 13:43:04 +0100 Received: from FRVELSMBS11.ad2.ad.alcatel.com ([155.132.6.37]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 8 Dec 2008 13:43:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 8 Dec 2008 13:43:03 +0100 Message-ID: <0458D2EE0C36744BABB36BE37805C29A03016CC5@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call for draft-ietf-ancp-security-threats-06.txt Thread-Index: AclZL5lCZTP0rH0tR1qIblTT8SftyQAAt+/Q From: "BOCCI Matthew" To: X-OriginalArrivalTime: 08 Dec 2008 12:43:04.0567 (UTC) FILETIME=[8377C070:01C95932] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: [ANCP] WG Last Call for draft-ietf-ancp-security-threats-06.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: , Content-Type: multipart/mixed; boundary="===============0891421706==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0891421706== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95932.8347BCE1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C95932.8347BCE1 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable > This email is to start a two week working group last call for > draft-ietf-ancp-security-threats-06.txt > Please review and provide comments to the list by Monday 22nd > December. >=20 > Best regards, >=20 > Matthew >=20 >=20 ------_=_NextPart_001_01C95932.8347BCE1 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable WG Last Call for draft-ietf-ancp-security-threats-06.txt

This email is to start a two week = working group last call for = draft-ietf-ancp-security-threats-06.txt
Please review and provide comments to = the list by Monday 22nd December.

Best regards,

Matthew


------_=_NextPart_001_01C95932.8347BCE1-- --===============0891421706== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============0891421706==-- From ancp-bounces@ietf.org Mon Dec 8 08:16:19 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC6433A67BD; Mon, 8 Dec 2008 08:16:19 -0800 (PST) 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 B15A53A6768 for ; Mon, 8 Dec 2008 08:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.911 X-Spam-Level: X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] 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 8nY7QsUj3Y1Z for ; Mon, 8 Dec 2008 08:16:05 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 937533A69B9 for ; Mon, 8 Dec 2008 08:16:04 -0800 (PST) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id mB8GFvZJ020559 for ; Mon, 8 Dec 2008 17:15:58 +0100 Received: from FRVELSMBS11.ad2.ad.alcatel.com ([155.132.6.37]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 8 Dec 2008 17:15:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 8 Dec 2008 17:15:10 +0100 Message-ID: <0458D2EE0C36744BABB36BE37805C29A03016E3E@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Minneapolis Minutes Thread-Index: AclZUCTm6TxXvpQzRze69bCBbrQwWA== From: "BOCCI Matthew" To: X-OriginalArrivalTime: 08 Dec 2008 16:15:58.0144 (UTC) FILETIME=[411CEC00:01C95950] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: [ANCP] Minneapolis Minutes 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: , Content-Type: multipart/mixed; boundary="===============0218836879==" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0218836879== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95950.265C86AE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C95950.265C86AE Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Please find below the draft minutes from Minneapolis. Many thanks to Dave Sinicrope for these. Please send any corrections / additions to the chairs. Regards Matthew IETF-73 ancp agenda Slides Chairs Slides Framework Multicast Control Extensions for ANCP Protocol draft update PON Vendor Specific Agenda =20 Thursday, November 20th, 2008 - 13:00 - 15:00 --------------------------------------------- CAIRS: Wojciech Dec & Matthew Bocci =20 WG Status and Update - Chairs ----------------------------------------------- Milestones: Asked people to look at the MIB. Need additional review and comment on the MIB. Please provide comments on the list. Chairs will check in with folks requsted to review the MIB to see how far progressed. Once another revision of the MIB decide on last call. Framework may be ready for last call. Discuss on the list. Chairs will update the milestones. =20 ANCP Framework and Requirements - Chairs ------------------------------------------------------------------- http://tools.ietf.org/html/draft-ietf-ancp-framework-07 Given there are so few folks here post comments to the list. (approx 12-15 people in room, 2-4 on Jabber) =20 See slides. Update to different admission control mechanisms and access and NAS requirements. =20 Francois: Is the Delegation of Authorization a terminology issue or are there other things. =20 Matthew: Only addressing multicast admission control for now. Typo: last slide should read xxx-07 not xxx-05 Woj: never got any feedback regarding gaps regarding BBF WT-147 and this framework. We assume that all people care about is being addressed. =20 Matthew: Can we make that assumption? Woj: Same request made to BBF to read our draft and for us to ready their draft and no response. =20 Mark: Always better to get affirmative responses. What we've done int eh pas is ask for 5 reviewers.=20 Matthew: didn't ask for 5 reviewers. Need to do this before last call. Given timing we could find some from the BBF that have access here. Editors here are active in BBF and should do cross check. Mark: call out people on the list to get reviewers. Matthew: volunteers? Francois: will review but cant do gap analysis. Matthew: will ask Sven as well since he is active in both. Woj: Call for reviewers and last call can be done in parallel. Got 2 volunteers from Jabber. One is "Lion"? (also got Alan Kavanagh volunteer via SMS) Matthew: Want to make sure we get a minimum amount of review for last call. Sending the document to WG last call we have Tom Francois, 2 from Jabber and will ask Sven to double check with BBF folks. Call will also be put out on the list. Matthew: will give 2 weeks then put in call then give another 2 weeks. =20 =20 ANCP Protocol Draft - Roberta Maglione (roberta.maglione@telecomitalia.it) ------------------------------------------------------------------------ ------------------------------------- http://tools.ietf.org/html/draft-ietf-ancp-protocol-04 =20 Woj presented for authors. Post feedback to the list. See slides. Multicast Slide Francois: hoping we could clise on using the field set to 0x00 to mean Ignore. We have discussed using 00 on the list after the previous multicast extension document presentation. Now that we all agree on result 0x00, can we upgrade the multicast message in the document to align? =20 Woj: Objections? =20 Multicast Capability Slide (2 alternative) Francois: The 2nd one is kind of closer to the negotiation works today. This is another thing that we should decide on. Approach number 2 simpler. Define 3 capabilities for 3levels of multicast so negotiation works the same. As long as the two ends seen a capability in common they keep it. Only trick is that we define the capabilities as subsets of one another as opposed to alternatives. Don't change negotiations. Option one is more hard core negotiation. Negotiate multicast and then what is supported. Option 2 seems simpler because no change to negotiation machinery. Woj: (opinion) #2 is what we have today. Both depend on sequence of events we have today. Option 1 is a bit odd because conceivably you could advertise capability, but then no subsets. Prefer option 2. Francois: prefer option 2 Tom Taylor: option 1 the base capability gives base functionality and subsequent give additional capabilities. =20 Woj: in 2 you start w/ all and work down. In 1 you start with a small set and work up. Tom assuming in 2 all can be ranked. Option 2 forces you to take ranking. If you advertise capset 1 and 2 then you must support 1 and 2. Francois: defined functionality as strict supersets of one another. Problem for multicast do you do 1, 1,2 or 1,2,3 Can do with approach 1 or 2. For things independent is covered. Need to cover things that are dependent. In approach 2 clever, approach 1 is flexible, but not sure you want that flexibility. Matthew: option 2 seems a complex way to negotiation capabilities. Francois: option 1 is 2 step/level, option 2 is one step. Tom: the strict ordering was defined that way, but not necessary that it be that way. Can define as an incremental capability. Robert: 1 gives a profile and may be limiting capabilities with 2. George Swallow: Defining sets tends to explode set definitions. Well defined sets are good to define but not in protocol. Francois: Option 1 can still allow negotiation in one blow, so am OK with option 1. In this case we need to prevent too much flexibility, so can't say we can do 2 but not 1. =20 Matthew: definiting which capabilities is separate from how you negotiate capabilities.=20 George: in the document you can specify minimum sets for compliance. Woj: Any strong proponents for 2? any opposition to 1? Will go with 1. Tom: Reconsideration of target. Seems like a waste of a word. Woj: discussion on list and concluded on a name. Tom: need to look at list discussion Additional Multicast Control Extensions for ANCP - Francois Le Feucher (flefauch@cisco.com) ------------------------------------------------------------------------ ----------------------------------------------------------------- =20 http://tools.ietf.org/html/draft-lefaucheur-ancp-mc-extensions-00 Francois presented. See slides. Tom: Can you have different versions between source and destination? Francois: yes Tom: If whole profile is on same IP version, then can take version out and put it at a higher level and can save byte Francois: You may want to push both v4 and v6 lists, could have a ver iside entry or a single IP version and then push two profiles. Tom:More compact that way, no gain by mixing. Still must spell out all addresses.=20 Francois: in the port up message don't want to push two profiles. Nabil: could put in a length that tells how many tuples follow Tom: put version at same level as profile name. Francois: Won't work, but then will need to push two profiles. Confusing saying push that list and that list and can't tell which is for v4 or v6. Inside profile we can put a bunch of v4 and a bunch of v6 Robert: If the address is IPv6 then isn't it longer in the diagram.=20 Francois: yes no length assumed Woj: On multicast service profile. Meant to be provisioning message. What is the overall operand AN or particular Access Line. Tom: Access Node because your port management assigns access to the lines. =20 Francois: port up message selects profile for ports. Robert: On TLV encoding, typically if you have a suboption of fixed len, then you don't need a length. In the object it seems to be a good idea to put the lengths in to keep things straight especially when there is a number of variables. Francois: back to Multicast Service Profile TLV. Robert: put length in header will check draft Francois: back to Admission Control Reject - will think a bit more and comment add to next version of document=20 Hand over to protocol document as is and if more stuff, then suggest to editors OR Let run one or two more versions and add some additions then hand over as a stable entity to the protocol document. Matthew: settle on the issues then merge the changes. Jabber: show of hands how many read? ~3-4. Woj: How does the author feel about the comments raised? Francois: Satisfied with resolution of open issues, but more work on Band delegation new messages and tlvs. Two minds, perception works well to focus on multicast and progress in parallel with protocol document. Progress one more time and then when stable hand over. Difficult to propose changes to protocol document. Nabil: When you have the access control decision at the AN, and you have the admin requst to the NAS in that case is the hmp stopped at the AN. What is the impact on the NAS? If you have to initiate PIM, etc. Do you initiate the join? F: Given an addition request, the AN may issue a join. Nabil: documented anywhere? =20 F: no. but discussion should be added because it can act in different ways. Nabil: could be added to whatever access control model the document applies to. Robert: need len on sub TLV. With proper length you would know what is expected could squeeze in field 2. F: we can take this offline Woj: Is there anyone that is unsatisfied with direction of draft if it is merged after one more revision? F: if reissued should it be reissued as WG? Woj: Pretty quick progress, No reason why shouldn't be merged. Matthew: Might as well merge in because will be issued as WG draft and then disappear when merged. W: If author wants WG draft we have precedent that overflow on multicast is in same document F: shows work is work of WG and not individuals i.e., "lunatics" J M: rev draft and then have discussion as to WG or not. =20 Vendor Specific Message for ANCP - Dave Sinicrope (euddasi@redback.com) ------------------------------------------------------------------------ ---------------------------------------- http://tools.ietf.org/html/draft-arberg-ancp-vendorspecific-01 Dave presented. Rev the draft and address: 1. The scope of the TLVs. Are they specific to a vendor specific message or across all ANCP messages? 2. Trojan horse issue: Is it possible to add a number of actions within the vendor specific TLVs under the vendor specific message? 3. Is the vendor specific TLV only applicable to messages with the extension block or all messages? 4. Need to note that the GSMP vendor specific messages are not used. Only ~3 people read the draft in the room. Will take to the list to see level of review and WG opinion on how to progress to WG document or protocol document section. =20 Applicability of Access Node Control Mechanism to PON based Broadband Networks - Nabil Bitar (Verizon) ------------------------------------------------------------------------ ------------------------------------------------------------------------ ----------- http://tools.ietf.org/id/draft-bitar-wadhwa-ancp-pon-00.txt =20 This draft was very briefly presented, but there was insufficient time for discussion.=20 =20 ------_=_NextPart_001_01C95950.265C86AE Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Minneapolis Minutes

Please find below the draft minutes = from Minneapolis. Many thanks to Dave Sinicrope for these.

Please send any corrections / additions = to the chairs.

Regards

Matthew

IETF-73 ancp agenda
Slides
Chairs Slides
Framework
Multicast Control Extensions for = ANCP
Protocol draft update
PON
Vendor Specific
Agenda
          =

Thursday, November 20th, 2008 = – 13:00 – = 15:00
 ---------------------------------------------=
CAIRS: Wojciech Dec & Matthew = Bocci
          =
WG Status and Update – = Chairs
-----------------------------------------------
Milestones: Asked people to look at = the MIB.  Need additional review and comment on the MIB.  = Please provide comments on the list.

Chairs will check in with folks = requsted to review the MIB to see how far progressed.  Once another = revision of the MIB decide on last call.

Framework may be ready for last call. = Discuss on the list.
Chairs will update the = milestones.
          =


ANCP Framework and Requirements = – Chairs
----------------------------------------------------------= ---------
http://tools.ietf.org/html/draft-ietf-ancp-framework-07


Given there are so few folks here post = comments to the list. (approx 12-15 people in room, 2-4 on Jabber)  =

See slides.

Update to different admission control = mechanisms and access and NAS requirements. 

Francois: Is the Delegation of = Authorization a terminology issue or are there other things.  =

Matthew: Only addressing multicast = admission control for now.
Typo: last slide should read xxx-07 = not xxx-05

Woj: never got any feedback regarding = gaps regarding BBF WT-147 and this framework.  We assume that all = people care about is being addressed. 

Matthew: Can we make that = assumption?
Woj: Same request made to BBF to read = our draft and for us to ready their draft and no response. 
Mark: Always better to get affirmative = responses.  What we’ve done int eh pas is ask for 5 = reviewers.
Matthew: didn’t ask for 5 = reviewers. Need to do this before last call.  Given timing we could = find some from the BBF that have access here.  Editors here are = active in BBF and should do cross check.

Mark: call out people on the list to = get reviewers.
Matthew: volunteers?
Francois: will review but cant do gap = analysis.
Matthew: will ask Sven as well since = he is active in both.
Woj: Call for reviewers and last call = can be done in parallel.  Got 2 volunteers from Jabber.  One = is “Lion”?  (also got Alan Kavanagh volunteer via = SMS)

Matthew: Want to make sure we get a = minimum amount of review for last call.  Sending the document to WG = last call we have Tom Francois, 2 from Jabber and will ask Sven to = double check with BBF folks.  Call will also be put out on the = list.

Matthew: will give 2 weeks then put in = call then give another 2 weeks.
          =
          =
 ANCP Protocol Draft – = Roberta Maglione (roberta.maglione@telecomitalia.it)
----------------------------------------------------------= ---------------------------------------------------
          = http://tools.ietf.org/html/draft-ietf-ancp-protocol-04

          =
Woj presented for authors. Post = feedback to the list.
See slides.
Multicast Slide
Francois: hoping we could clise on = using the field set to 0x00 to mean Ignore.  We have discussed = using 00 on the list after the previous multicast extension document = presentation. Now that we all agree on result 0x00, can we upgrade the = multicast message in the document to align? 

Woj: Objections? 
<None in the room. Check on the = list.>

Multicast Capability Slide (2 = alternative)
Francois: The 2nd one is kind of = closer to the negotiation works today.  This is another thing that = we should decide on.  Approach number 2 simpler.  Define 3 = capabilities for 3levels of multicast so negotiation works the = same.  As long as the two ends seen a capability in common they = keep it.  Only trick is that we define the capabilities as subsets = of one another as opposed to alternatives.  Don’t change = negotiations.

Option one is more hard core = negotiation.  Negotiate multicast and then what is = supported.
Option 2 seems simpler because no = change to negotiation machinery.
Woj: (opinion) #2 is what we have = today.  Both depend on sequence of events we have today.  = Option 1 is a bit odd because conceivably you could advertise = capability, but then no subsets.  Prefer option 2.

Francois: prefer option 2
Tom Taylor: option 1 the base = capability gives base functionality and subsequent give additional = capabilities. 
Woj: in 2 you start w/ all and work = down.  In 1 you start with a small set and work up.
Tom assuming in 2 all can be = ranked.  Option 2 forces you to take ranking.  If you = advertise capset 1 and 2 then you must support 1 and 2.

Francois: defined functionality as = strict supersets of one another.  Problem for multicast do you do = 1, 1,2 or 1,2,3  Can do with approach 1 or 2.  For things = independent is covered.  Need to cover things that are = dependent.  In approach 2 clever, approach 1 is flexible, but not = sure you want that flexibility.

Matthew: option 2 seems a complex way = to negotiation capabilities.
Francois: option 1 is 2 step/level, = option 2 is one step.
Tom: the strict ordering was defined = that way, but not necessary that it be that way.  Can define as an = incremental capability.

Robert: 1 gives a profile and may be = limiting capabilities with 2.
George Swallow: Defining sets tends to = explode set definitions.  Well defined sets are good to define but = not in protocol.

Francois: Option 1 can still allow = negotiation in one blow, so am OK with option 1.  In this case we = need to prevent too much flexibility, so can’t say we can do 2 but = not 1. 

Matthew: definiting which capabilities = is separate from how you negotiate capabilities.
George: in the document you can = specify minimum sets for compliance.
Woj: Any strong proponents for = 2?  <none> any opposition to 1?  <none>  Will = go with 1.
Tom: Reconsideration of target.  = Seems like a waste of a word.
Woj: discussion on list and concluded = on a name.
Tom: need to look at list = discussion

 Additional Multicast Control = Extensions for ANCP - Francois Le Feucher (flefauch@cisco.com)
----------------------------------------------------------= -------------------------------------------------------------------------= ------

          = http://tools.ietf.org/html/draft-lefaucheur-ancp-mc-extens= ions-00

Francois presented.
See slides.
Tom: Can you have different versions = between source and destination?
Francois: yes
Tom: If whole profile is on same IP = version, then can take version out and put it at a higher level and can = save byte
Francois: You may want to push both v4 = and v6 lists, could have a ver iside entry or a single IP version and = then push two profiles.

Tom:More compact that way, no gain by = mixing.  Still must spell out all addresses.
Francois: in the port up message = don’t want to push two profiles.
Nabil: could put in a length that = tells how many tuples follow
Tom: put version at same level as = profile name.
Francois: Won’t work, but then = will need to push two profiles.  Confusing saying push that list = and that list and can’t tell which is for v4 or v6.  Inside = profile we can put a bunch of v4 and a bunch of v6

Robert: If the address is IPv6 then = isn’t it longer in the diagram.
Francois: yes no length assumed
Woj: On multicast service profile. = Meant to be provisioning message.  What is the overall operand AN = or particular Access Line.

Tom: Access Node because your port = management assigns access to the lines. 
Francois: port up message selects = profile for ports.
Robert: On TLV encoding, typically if = you have a suboption of fixed len, then you don’t need a = length.  In the object it seems to be a good idea to put the = lengths in to keep things straight especially when there is a number of = variables.

Francois: back to Multicast Service = Profile TLV.
Robert: put length in header  = <it’s in the slide>  will check draft
Francois: back to Admission Control = Reject – will think a bit more and comment add to next = version of document

Hand over to protocol document as is = and if more stuff, then suggest to editors OR
Let run one or two more versions and = add some additions then hand over as a stable entity to the protocol = document.

Matthew: settle on the issues then = merge the changes.
Jabber: show of hands how many read? = ~3-4.
Woj: How does the author feel about = the comments raised?
Francois: Satisfied with resolution of = open issues, but more work on Band delegation new messages and = tlvs.  Two minds, perception works well to focus on multicast and = progress in parallel with protocol document.  Progress one more = time and then when stable hand over.  Difficult to propose changes = to protocol document.

Nabil: When you have the access control = decision at the AN, and you have the admin requst to the NAS in that = case is the hmp stopped at the AN.  What is the impact on the = NAS?  If you have to initiate PIM, etc.  Do you initiate the = join?

F: Given an addition request, the AN = may issue a join.
Nabil: documented anywhere?  =
F: no. but discussion should be added = because it can act in different ways.
Nabil: could be added to whatever = access control model the document applies to.
Robert: need len on sub TLV.  = With proper length you would know what is expected could squeeze in = field 2.
F: we can take this offline
Woj: Is there anyone that is = unsatisfied with direction of draft if it is merged after one more = revision?  <none>
F: if reissued should it be reissued = as WG?
Woj: Pretty quick progress, No reason = why shouldn’t be merged.
Matthew: Might as well merge in = because will be issued as WG draft and then disappear when = merged.
W: If author wants WG draft we have = precedent that overflow on multicast is in same document
F: shows work is work of WG and not = individuals i.e., “lunatics” J
M: rev draft and then have discussion = as to WG or not.
          =
Vendor Specific Message for = ANCP – Dave Sinicrope (euddasi@redback.com)
----------------------------------------------------------= ------------------------------------------------------
          = <= U>http://tools.ietf.org/html/draft-arberg-ancp-vendorspecifi= c-01
Dave presented.
Rev the draft and address:
1.      The = scope of the TLVs.  Are they specific to a vendor specific message = or across all ANCP messages?
2.      = Trojan horse issue: Is it possible to add a number of actions within the = vendor specific TLVs under the vendor specific message?

3.      Is the = vendor specific TLV only applicable to messages with the extension block = or all messages?
4.      Need = to note that the GSMP vendor specific messages are not used.
Only ~3 people read the draft in the = room.  Will take to the list to see level of review and WG opinion = on how to progress to WG document or protocol document = section.

          =

Applicability of Access Node Control = Mechanism to PON based Broadband Networks – Nabil Bitar = (Verizon)
----------------------------------------------------------= -------------------------------------------------------------------------= ------------------------

<= FONT COLOR=3D"#0000FF" SIZE=3D2 = FACE=3D"Arial">http://tools.ietf.org/id/draft-bitar-wadhwa-ancp-pon-00.tx= t
          =
This draft was very briefly presented, = but there was insufficient time for discussion.
         &nbs= p;        

------_=_NextPart_001_01C95950.265C86AE-- --===============0218836879== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --===============0218836879==-- From ancp-bounces@ietf.org Fri Dec 12 01:25:55 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6EAA3A6937; Fri, 12 Dec 2008 01:25:55 -0800 (PST) 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 025A83A6937 for ; Fri, 12 Dec 2008 01:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 1hw22rxOMjCb for ; Fri, 12 Dec 2008 01:25:53 -0800 (PST) Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by core3.amsl.com (Postfix) with ESMTP id 318F93A6887 for ; Fri, 12 Dec 2008 01:25:53 -0800 (PST) Received: from GRFHUB705RM001.griffon.local (10.19.3.69) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.1.311.2; Fri, 12 Dec 2008 10:27:56 +0100 Received: from GRFMBX702RM001.griffon.local ([10.19.3.19]) by GRFHUB705RM001.griffon.local ([10.19.9.238]) with mapi; Fri, 12 Dec 2008 10:25:45 +0100 From: Maglione Roberta To: OOGHE Sven , "ancp@ietf.org" Date: Fri, 12 Dec 2008 10:25:44 +0100 Thread-Topic: WG last call for draft-ietf-ancp-framework-07.txt Thread-Index: AclZLWi472QILb2YRiiUO7dT3wLrywAATJCQAADpsIAAnMNzcA== Message-ID: References: <0458D2EE0C36744BABB36BE37805C29A03016CC2@FRVELSMBS11.ad2.ad.alcatel.com> In-Reply-To: <0458D2EE0C36744BABB36BE37805C29A03016CC2@FRVELSMBS11.ad2.ad.alcatel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [ANCP] WG last call for draft-ietf-ancp-framework-07.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hello, I did a comparison between draft draft-ietf-ancp-framework-07.txt and latest version of BBF WT-147 in order to identify the differences between the two documents introduced with recent changes in WT-147. Please find my comments for draft draft-ietf-ancp-framework-07.txt below. Thanks, Best Regards, Roberta Section 1.2 page 5 I suggest the following changes in order to reflect BBF WT-147 definitions: "Net Data Rate: defined by ITU-T G.993.2, section 3.39, i.e. the portion of the total data rate that can be used to transmit user information (e.g. ATM cells or Ethernet frames). It excludes overhead that pertains to the physical transmission mechanism (e.g. trellis coding in case of DSL)." Add: "It includes TPS-TC (Transport Protocol Specific - Transmission Convergence) encapsulation; this is zero for ATM encapsulation, and non-zero for 64/65 encapsulation. " Replace: Line Rate: the total data rate including overhead. By: Line Rate: defined by ITU-T G.993.2. It contains the complete overhead including RS and trellis coding. Section 2.1 Page 8. To be consistent with latest changes in BBF WT-147 I propose to split reporting and enforcement functions in two separate bullets Section 2.2.2 Page 9 line 466: for each technology there is a reference to RFC I would suggest adding: IPoE defined in RFC 894 Section 2.4 page 12 line 630: Replace: "Also, there is a possibility to integrate this with a Policy Server (e.g. RADIUS server) that keeps track of the different Subscriber related parameters." By: "Also, there is a possibility to integrate this with a Policy Server or an AAA/RADIUS server that keeps track of the different Subscriber related parameters." Section 3.2 page 15 line 818: Replace "the NAS could query a Policy Server (e.g. RADIUS server) to retrieve Access Loop configuration data." by "the NAS could query a Policy Server or an AAA/RADIUS server to retrieve Access Loop configuration data." Section 3.4.2 Page 22 line 1209: Replace: "perform CAC for unicast and multicast flows and perform video bandwidth accounting." By "perform CAC for unicast and multicast flows and perform video bandwidth management" Section 3.4.3 Page 26 line 1424 I would suggest rephrasing this sentence as ANCP Bulk message has been removed from the protocol draft. "In case of very fast channel changes, the amount of Information Report messages to be sent to the NAS could become high. In order to reduce the number of messages, the AN may bundle several Information Reports together in a single "bulk transaction"." Section 4.1 Page 28 line 1555 To be consistent with recent changes in BBF WT-147 replace: " In large scale networks, Access Nodes are provisioned but not always fully populated. Therefore the ANCP MUST be scalable enough to allow a given NAS to control thousands of Access Nodes (e.g. typically 5000 to 10000)." By " The protocol must be scalable enough to allow a given NAS to control at least 5000 Access Nodes." The following requirement has been removed from WT-147: " The ANCP SHOULD minimize sources of configuration mismatch, help automation of the overall operation of the systems involved (Access Nodes and NAS) and be easy to troubleshoot. Page 29 line 1578: "The ANCP SHOULD support a means to handle sending/receiving a large burst of messages efficiently (e.g. using "message bundling")." I suggest removing "(e.g. using "message bundling")." Do we really need three different sections (4.3, 4.7.9 and 4.8.9) for security (plus section 7 "Security considerations") all of them pointing to the draft draft-ietf-ancp-security-threats? Would not be possible to remove sections 4.3, 4.7.9 and 4.8.9 as the text contained in these sections is already in section 7? Section 4.8.1 Line 2045: As per BBF comments replace: " The NAS must only communicate to authorized Access Node Control peers." By: " The NAS must establish ANCP Adjacencies only with authorized ANCP peers. " Section 5. " This document does not consider the specific details of the communication with a Policy Server (e.g. using RADIUS)." I would remove "(e.g. using RADIUS)." Missing References to the following RFCs mentioned in the text: RFC2684, RFC2516, RFC2225, RFC 894 - editorial: replace everywhere in the document "DSL Forum" with "Broadband Forum" Thanks, Regards, Roberta ----------------------------------------------------- Roberta Maglione - CCIE #18425 Telecom Italia Broadband Network Services Innovation ----------------------------------------------------- ________________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of BOCCI Matthew Sent: Monday, December 08, 2008 1:42 PM To: ancp@ietf.org Subject: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt This email is to start a two week working group last call for draft-ietf-ancp-framework-07.txt Please review and provide comments to the list by Monday 22nd December. The following have also kindly offered to review the document: - Roberta Maglione - Alan Kavanagh - John Zhao - Tom Taylor - Sven Ooghe - Francois LeFaucher Best regards Matthew Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. Rispetta l'ambiente. Non stampare questa mail se non e' necessario. www.avoicomunicare.it Ogni giorno, il tuo luogo di dialogo. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Dec 12 06:26:34 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92C553A6B19; Fri, 12 Dec 2008 06:26:34 -0800 (PST) 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 6EEB028C101 for ; Fri, 12 Dec 2008 06:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 ochAMyAkd68j for ; Fri, 12 Dec 2008 06:26:32 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id AC4CA3A6B15 for ; Fri, 12 Dec 2008 06:26:31 -0800 (PST) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id mBCEQHXI013487; Fri, 12 Dec 2008 15:26:23 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 12 Dec 2008 15:26:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Dec 2008 15:26:17 +0100 Message-ID: <7168964CAC5C144685272595141B6DBA018AD8BC@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG last call for draft-ietf-ancp-framework-07.txt Thread-Index: AclZLWi472QILb2YRiiUO7dT3wLrywAATJCQAADpsIAAnMNzcAAv6A5A References: <0458D2EE0C36744BABB36BE37805C29A03016CC2@FRVELSMBS11.ad2.ad.alcatel.com> From: "OOGHE Sven" To: "Maglione Roberta" , X-OriginalArrivalTime: 12 Dec 2008 14:26:19.0842 (UTC) FILETIME=[99CAB220:01C95C65] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [ANCP] WG last call for draft-ietf-ancp-framework-07.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi Roberta, Many thanks for doing the full review. I still need to do this as well - for now I am ok with all of your suggested changes. I'm ok to have one security section and remove the "dummy" sections that all point to section 7. Regards, Sven -----Original Message----- From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] Sent: vrijdag 12 december 2008 10:26 To: OOGHE Sven; ancp@ietf.org Cc: BOCCI Matthew Subject: RE: WG last call for draft-ietf-ancp-framework-07.txt Hello, I did a comparison between draft draft-ietf-ancp-framework-07.txt and latest version of BBF WT-147 in order to identify the differences between the two documents introduced with recent changes in WT-147. Please find my comments for draft draft-ietf-ancp-framework-07.txt below. Thanks, Best Regards, Roberta Section 1.2 page 5 I suggest the following changes in order to reflect BBF WT-147 definitions: "Net Data Rate: defined by ITU-T G.993.2, section 3.39, i.e. the portion of the total data rate that can be used to transmit user information (e.g. ATM cells or Ethernet frames). It excludes overhead that pertains to the physical transmission mechanism (e.g. trellis coding in case of DSL)." Add: "It includes TPS-TC (Transport Protocol Specific - Transmission Convergence) encapsulation; this is zero for ATM encapsulation, and non-zero for 64/65 encapsulation. " Replace: Line Rate: the total data rate including overhead. By: Line Rate: defined by ITU-T G.993.2. It contains the complete overhead including RS and trellis coding. Section 2.1 Page 8. To be consistent with latest changes in BBF WT-147 I propose to split reporting and enforcement functions in two separate bullets Section 2.2.2 Page 9 line 466: for each technology there is a reference to RFC I would suggest adding: IPoE defined in RFC 894 Section 2.4 page 12 line 630: Replace: "Also, there is a possibility to integrate this with a Policy Server (e.g. RADIUS server) that keeps track of the different Subscriber related parameters." By: "Also, there is a possibility to integrate this with a Policy Server or an AAA/RADIUS server that keeps track of the different Subscriber related parameters." Section 3.2 page 15 line 818: Replace "the NAS could query a Policy Server (e.g. RADIUS server) to retrieve Access Loop configuration data." by "the NAS could query a Policy Server or an AAA/RADIUS server to retrieve Access Loop configuration data." Section 3.4.2 Page 22 line 1209: Replace: "perform CAC for unicast and multicast flows and perform video bandwidth accounting." By "perform CAC for unicast and multicast flows and perform video bandwidth management" Section 3.4.3 Page 26 line 1424 I would suggest rephrasing this sentence as ANCP Bulk message has been removed from the protocol draft. "In case of very fast channel changes, the amount of Information Report messages to be sent to the NAS could become high. In order to reduce the number of messages, the AN may bundle several Information Reports together in a single "bulk transaction"." Section 4.1 Page 28 line 1555 To be consistent with recent changes in BBF WT-147 replace: " In large scale networks, Access Nodes are provisioned but not always fully populated. Therefore the ANCP MUST be scalable enough to allow a given NAS to control thousands of Access Nodes (e.g. typically 5000 to 10000)." By " The protocol must be scalable enough to allow a given NAS to control at least 5000 Access Nodes." The following requirement has been removed from WT-147: " The ANCP SHOULD minimize sources of configuration mismatch, help automation of the overall operation of the systems involved (Access Nodes and NAS) and be easy to troubleshoot. Page 29 line 1578: "The ANCP SHOULD support a means to handle sending/receiving a large burst of messages efficiently (e.g. using "message bundling")." I suggest removing "(e.g. using "message bundling")." Do we really need three different sections (4.3, 4.7.9 and 4.8.9) for security (plus section 7 "Security considerations") all of them pointing to the draft draft-ietf-ancp-security-threats? Would not be possible to remove sections 4.3, 4.7.9 and 4.8.9 as the text contained in these sections is already in section 7? Section 4.8.1 Line 2045: As per BBF comments replace: " The NAS must only communicate to authorized Access Node Control peers." By: " The NAS must establish ANCP Adjacencies only with authorized ANCP peers. " Section 5. " This document does not consider the specific details of the communication with a Policy Server (e.g. using RADIUS)." I would remove "(e.g. using RADIUS)." Missing References to the following RFCs mentioned in the text: RFC2684, RFC2516, RFC2225, RFC 894 - editorial: replace everywhere in the document "DSL Forum" with "Broadband Forum" Thanks, Regards, Roberta ----------------------------------------------------- Roberta Maglione - CCIE #18425 Telecom Italia Broadband Network Services Innovation ----------------------------------------------------- ________________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of BOCCI Matthew Sent: Monday, December 08, 2008 1:42 PM To: ancp@ietf.org Subject: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt This email is to start a two week working group last call for draft-ietf-ancp-framework-07.txt Please review and provide comments to the list by Monday 22nd December. The following have also kindly offered to review the document: - Roberta Maglione - Alan Kavanagh - John Zhao - Tom Taylor - Sven Ooghe - Francois LeFaucher Best regards Matthew Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. Rispetta l'ambiente. Non stampare questa mail se non e' necessario. www.avoicomunicare.it Ogni giorno, il tuo luogo di dialogo. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Dec 16 00:00:43 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C739228C128; Tue, 16 Dec 2008 00:00:43 -0800 (PST) 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 BD3C528C12A for ; Tue, 16 Dec 2008 00:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 Npy2UjvNMt2H for ; Tue, 16 Dec 2008 00:00:34 -0800 (PST) Received: from dtc034.detecon.net (dtc034.detecon.net [194.25.60.134]) by core3.amsl.com (Postfix) with ESMTP id E072F28C125 for ; Tue, 16 Dec 2008 00:00:33 -0800 (PST) Received: from unknown (HELO dc00357.detecon.com) ([172.16.10.107]) by relay.dtc034.detecon.net with ESMTP; 16 Dec 2008 09:00:25 +0100 Received: from DC00331.detecon.com ([172.16.10.78]) by dc00357.detecon.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Dec 2008 09:00:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 Dec 2008 09:00:34 +0100 Message-ID: In-Reply-To: <7168964CAC5C144685272595141B6DBA018AD8BC@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt Thread-Index: AclZLWi472QILb2YRiiUO7dT3wLrywAATJCQAADpsIAAnMNzcAAv6A5AALu2qMA= References: <0458D2EE0C36744BABB36BE37805C29A03016CC2@FRVELSMBS11.ad2.ad.alcatel.com> <7168964CAC5C144685272595141B6DBA018AD8BC@FRVELSMBS22.ad2.ad.alcatel.com> From: "Reith, Lothar" To: "OOGHE Sven" , "Maglione Roberta" , X-OriginalArrivalTime: 16 Dec 2008 08:00:25.0161 (UTC) FILETIME=[5A2DC390:01C95F54] Subject: Re: [ANCP] WG last call for draft-ietf-ancp-framework-07.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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi Roberta and Sven, I would like to suggest a minor change to Roberta's proposal: Roberta proposed: Section 3.2 page 15 line 818: Replace "the NAS could query a Policy Server (e.g. RADIUS server) to retrieve Access Loop configuration data." by "the NAS could query a Policy Server or an AAA/RADIUS server to retrieve Ac= cess Loop configuration data." however, I would suggest to Replace the word "or" by the word "such as" = by "the NAS could query a Policy Server such as an AAA/RADIUS server to retrie= ve Access Loop configuration data." There are many reasons for this, which I will be happy to explain if need b= e. Best Regards, Lothar = -----Urspr=FCngliche Nachricht----- Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von OO= GHE Sven Gesendet: Freitag, 12. Dezember 2008 15:26 An: Maglione Roberta; ancp@ietf.org Betreff: Re: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt Hi Roberta, Many thanks for doing the full review. I still need to do this as well - fo= r now I am ok with all of your suggested changes. I'm ok to have one security section and remove the "dummy" sections that al= l point to section 7. Regards, Sven -----Original Message----- From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] Sent: vrijdag 12 december 2008 10:26 To: OOGHE Sven; ancp@ietf.org Cc: BOCCI Matthew Subject: RE: WG last call for draft-ietf-ancp-framework-07.txt Hello, I did a comparison between draft draft-ietf-ancp-framework-07.txt = and latest version of BBF WT-147 in order to identify the differences betwe= en the two documents introduced with recent changes in WT-147. Please find my comments for draft draft-ietf-ancp-framework-07.txt below. Thanks, Best Regards, Roberta Section 1.2 page 5 I suggest the following changes in order to reflect BBF WT-147 definitions: "Net Data Rate: defined by ITU-T G.993.2, section 3.39, i.e. the portion of the total data rate that can be used to transmit user information (e.g. ATM cells or Ethernet frames). It excludes overhead that pertains to the physical transmission mechanism (e.g. trellis coding in case of DSL)." Add: "It includes TPS-TC (Transport Protocol Specific - Transmission Convergence) encapsulation; this is zero for ATM encapsulation, and non-zero for 6= 4/65 encapsulation. " Replace: Line Rate: the total data rate including overhead. By: Line Rate: defined by ITU-T G.993.2. It contains the complete overhead including RS and trellis coding. Section 2.1 Page 8. To be consistent with latest changes in BBF WT-147 I propose to split repor= ting and enforcement functions in two separate bullets Section 2.2.2 Page 9 line 466: for each technology there is a reference to = RFC I would suggest adding: IPoE defined in RFC 894 Section 2.4 page 12 line 630: Replace: "Also, there is a possibility to integrate this with a Policy Server (e.g. RADIUS server) that keeps track of the different Subscriber related parameters." By: "Also, there is a possibility to integrate this with a Policy Server or an = AAA/RADIUS server that keeps track of the different Subscriber related para= meters." Section 3.2 page 15 line 818: Replace "the NAS could query a Policy Server (e.g. RADIUS server) to retrieve Access Loop configuration data." by "the NAS could query a Policy Server or an AAA/RADIUS server to retrieve Ac= cess Loop configuration data." Section 3.4.2 Page 22 line 1209: Replace: "perform CAC for unicast and multicast flows and perform video bandwidth accounting." By "perform CAC for unicast and multicast flows and perform video bandwidth management" Section 3.4.3 Page 26 line 1424 I would suggest rephrasing this sentence as ANCP Bulk message has been remo= ved from the protocol draft. "In case of very fast channel changes, the amount of Information Report messages to be sent to the NAS could become high. In order to reduce the number of messages, the AN may bundle several Information Reports together in a single "bulk transaction"." Section 4.1 Page 28 line 1555 To be consistent with recent changes in BBF WT-147 replace: " In large scale networks, Access Nodes are provisioned but not always fully populated. Therefore the ANCP MUST be scalable enough to allow a given NAS to control thousands of Access Nodes (e.g. typically 5000 to 10000)." By " The protocol must be scalable enough to allow a given NAS to control at l= east 5000 Access Nodes." The following requirement has been removed from WT-147: " The ANCP SHOULD minimize sources of configuration mismatch, help automation of the overall operation of the systems involved (Access Nodes and NAS) and be easy to troubleshoot. Page 29 line 1578: "The ANCP SHOULD support a means to handle sending/receiving a large burst of messages efficiently (e.g. using "message bundling")." I suggest removing "(e.g. using "message bundling")." Do we really need three different sections (4.3, 4.7.9 and 4.8.9) for secur= ity (plus section 7 "Security considerations") all of them pointing to the = draft draft-ietf-ancp-security-threats? Would not be possible to remove sec= tions 4.3, 4.7.9 and 4.8.9 as the text contained in these sections is alre= ady in section 7? Section 4.8.1 Line 2045: As per BBF comments replace: " The NAS must only communicate to authorized Access Node Control peers." By: " The NAS must establish ANCP Adjacencies only with authorized ANCP peers. " Section 5. " This document does not consider the specific details of the communication with a Policy Server (e.g. using RADIUS)." I would remove "(e.g. using RADIUS)." Missing References to the following RFCs mentioned in the text: RFC2684, RFC2516, RFC2225, RFC 894 - editorial: replace everywhere in the document "DSL Forum" with "Broadban= d Forum" Thanks, Regards, Roberta ----------------------------------------------------- Roberta Maglione - CCIE #18425 Telecom Italia Broadband Network Services Innovation ----------------------------------------------------- ________________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of BOC= CI Matthew Sent: Monday, December 08, 2008 1:42 PM To: ancp@ietf.org Subject: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt This email is to start a two week working group last call for draft-ietf-an= cp-framework-07.txt Please review and provide comments to the list by Monda= y 22nd December. The following have also kindly offered to review the document: - Roberta Maglione - Alan Kavanagh - John Zhao - Tom Taylor - Sven Ooghe - Francois LeFaucher Best regards Matthew Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. Rispetta l'ambiente. Non stampare questa mail se non e' necessario. www.avoicomunicare.it Ogni giorno, il tuo luogo di dialogo. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Dec 17 08:32:30 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 049F83A6B14; Wed, 17 Dec 2008 08:32:30 -0800 (PST) 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 A707C28C156 for ; Wed, 17 Dec 2008 08:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.854 X-Spam-Level: X-Spam-Status: No, score=-4.854 tagged_above=-999 required=5 tests=[AWL=-1.394, BAYES_00=-2.599, CN_BODY_35=0.339, HELO_EQ_FR=0.35, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] 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 OUClmOuValGp for ; Wed, 17 Dec 2008 08:32:27 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id C714D28C154 for ; Wed, 17 Dec 2008 08:32:26 -0800 (PST) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id mBHGW1sR000319; Wed, 17 Dec 2008 17:32:02 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 17 Dec 2008 17:32:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 17 Dec 2008 17:31:56 +0100 Message-ID: <7168964CAC5C144685272595141B6DBA0190EE4A@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <002b01c95f4d$6ed4cc50$7b27460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt Thread-Index: AclZLWi472QILb2YRiiUO7dT3wLrywAATJCQAADpsIAAnMNzcAAv6A5AALm9xWAARjjs8A== References: <7168964CAC5C144685272595141B6DBA018AD8BC@FRVELSMBS22.ad2.ad.alcatel.com> <002b01c95f4d$6ed4cc50$7b27460a@china.huawei.com> From: "OOGHE Sven" To: "Fortune HUANG" , "Maglione Roberta" , X-OriginalArrivalTime: 17 Dec 2008 16:32:01.0809 (UTC) FILETIME=[FD384810:01C96064] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [ANCP] WG last call for draft-ietf-ancp-framework-07.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: , Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org SGkgRm9ydHVuZSwKCkknbSBnZW5lcmFsbHkgb2sgd2l0aCBtYWtpbmcgdGhlIGNoYW5nZXMgeW91 IHByb3Bvc2UgaW4gYm90aCBvZiB5b3VyIGVtYWlscy4gSXQgYWxsb3dzIGNhcHR1cmluZyB0aGUg ZGlmZmVyZW50IGFyY2hpdGVjdHVyZXMgdGhhdCB3ZXJlIG1lbnRpb25lZCBpbiB0aGUgZnJhbWV3 b3JrLgoKUmVnYXJkcywKU3ZlbgoKLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KRnJvbTogRm9y dHVuZSBIVUFORyBbbWFpbHRvOmZxaHVhbmdAaHVhd2VpLmNvbV0gClNlbnQ6IGRpbnNkYWcgMTYg ZGVjZW1iZXIgMjAwOCA4OjExClRvOiBPT0dIRSBTdmVuOyAnTWFnbGlvbmUgUm9iZXJ0YSc7IGFu Y3BAaWV0Zi5vcmcKU3ViamVjdDogtPC4tDogW0FOQ1BdIFdHIGxhc3QgY2FsbCBmb3IgZHJhZnQt aWV0Zi1hbmNwLWZyYW1ld29yay0wNy50eHQKCkhpIGFsbCwKCkFub3RoZXIgY29tbWVudCBvbiB0 aGUgZm9sbG93aW5nIHBhcmFncmFwaCBpbiBzZXNzaW9uIDMuNC4yOgoKICAgbyAgVGhlIGFib3Zl IG1vZGVsIGNvdWxkIGJlIGVuaGFuY2VkIHdpdGggdGhlIG5vdGlvbiBvZiAiRGVsZWdhdGlvbgog ICAgICBvZiBBdXRob3JpemF0aW9uIi4gIEluIHN1Y2ggYSBtb2RlbCwgdGhlIE5BUyBkZWxlZ2F0 ZXMgYXV0aG9yaXR5CiAgICAgIHRvIHRoZSBBY2Nlc3MgTm9kZSB0byBwZXJmb3JtIG11bHRpY2Fz dCBBZG1pc3Npb24gQ29udHJvbCBvbiB0aGUKICAgICAgQWNjZXNzIExvb3AuICBUaGlzIGlzIHNv bWV0aW1lcyByZWZlcnJlZCB0byBhcyAiQmFuZHdpZHRoCiAgICAgIERlbGVnYXRpb24iLCByZWZl cnJpbmcgdG8gdGhlIHBvcnRpb24gb2YgdGhlIHRvdGFsIEFjY2VzcyBMb29wCiAgICAgIGJhbmR3 aWR0aCB3aGljaCBjYW4gYmUgdXNlZCBieSB0aGUgQWNjZXNzIE5vZGUgZm9yIG11bHRpY2FzdAog ICAgICBBZG1pc3Npb24gQ29udHJvbC4gIEluIHRoaXMgbW9kZWwsIHRoZSBOQVMgKHBvc3NpYmx5 IHdpdGgKICAgICAgaW50ZXJhY3Rpb25zIHdpdGggYSBQb2xpY3kgU2VydmVyKSBtYW5hZ2VzIHRo ZSB0b3RhbCBhY2Nlc3MgbGluZQogICAgICBiYW5kd2lkdGgsIHBlcmZvcm1zIHVuaWNhc3QgYWRt aXNzaW9uIGNvbnRyb2wgYW5kIHVzZXMgQU5DUCB0bwogICAgICBhdXRob3JpemUgdGhlIEFjY2Vz cyBOb2RlIHRvIHBlcmZvcm0gbXVsdGljYXN0IEFkbWlzc2lvbiBDb250cm9sCiAgICAgIHdpdGhp biB0aGUgYm91bmRzIG9mIHRoZSAiZGVsZWdhdGVkIGJhbmR3aWR0aCIuICBVcG9uIHJlY2Vpdmlu ZyBhCiAgICAgIGpvaW4gdG8gYSBtdWx0aWNhc3QgZmxvdyB3aGljaCBtYXRjaGVzIGFuIGVudHJ5 IGluIHRoZSBXaGl0ZSBvcgogICAgICBHcmV5IExpc3QsIHRoZSBBTiBwZXJmb3JtcyB0aGUgbmVj ZXNzYXJ5IGJhbmR3aWR0aCBhZG1pc3Npb24KICAgICAgY29udHJvbCBjaGVjayBmb3IgdGhlIG5l dyBtdWx0aWNhc3QgZmxvdywgYmVmb3JlIHN0YXJ0aW5nIHRoZQogICAgICBtdWx0aWNhc3QgZmxv dyByZXBsaWNhdGlvbi4gIEF0IHRoaXMgcG9pbnQsIHRoZXJlIGlzIHR5cGljYWxseSBubwogICAg ICBuZWVkIGZvciB0aGUgQWNjZXNzIE5vZGUgdG8gY29tbXVuaWNhdGUgd2l0aCB0aGUgTkFTLiAg VGhlIEFOQ1AKICAgICAgcmVxdWlyZW1lbnRzIHRvIHN1cHBvcnQgdGhpcyBhcHByb2FjaCBhcmUg YWxzbyBzcGVjaWZpZWQgaW4gdGhpcwogICAgICBkb2N1bWVudC4gCgpDb21tZW50OiBUaGVyZSBz aG91bGQgYmUgYW5vdGhlciBzY2VuYXJvIHdoZXJlIHRoZSBQb2xpY3kgU2VydmVyIChiZXNpZGVz IHRoZSBOQVMpIG1hbmFnZXMgdGhlIHRvdGFsIGJhbmR3aWR0aCBhbmQgZGVsZWdhdGVzIGEgcG9y dGlvbiBvZiB0aGUgYmFuZHdpZHRoIHRvIHRoZSBBTi4gSSB3b3VsZCBwcm9wb3NlIHRvIGNoYW5n ZSB0aGUgcGFyYWdyYXBoIGxpa2UgdGhlCmZvbGxvd2luZzoKICAgbyAgVGhlIGFib3ZlIG1vZGVs IGNvdWxkIGJlIGVuaGFuY2VkIHdpdGggdGhlIG5vdGlvbiBvZiAiRGVsZWdhdGlvbgogICAgICBv ZiBBdXRob3JpemF0aW9uIi4gIEluIHN1Y2ggYSBtb2RlbCwgdGhlIE5BUyBvciB0aGUgUG9saWN5 IFNlcnZlciBkZWxlZ2F0ZXMgYXV0aG9yaXR5CiAgICAgIHRvIHRoZSBBY2Nlc3MgTm9kZSB0byBw ZXJmb3JtIG11bHRpY2FzdCBBZG1pc3Npb24gQ29udHJvbCBvbiB0aGUKICAgICAgQWNjZXNzIExv b3AuICBUaGlzIGlzIHNvbWV0aW1lcyByZWZlcnJlZCB0byBhcyAiQmFuZHdpZHRoCiAgICAgIERl bGVnYXRpb24iLCByZWZlcnJpbmcgdG8gdGhlIHBvcnRpb24gb2YgdGhlIHRvdGFsIEFjY2VzcyBM b29wCiAgICAgIGJhbmR3aWR0aCB3aGljaCBjYW4gYmUgdXNlZCBieSB0aGUgQWNjZXNzIE5vZGUg Zm9yIG11bHRpY2FzdAogICAgICBBZG1pc3Npb24gQ29udHJvbC4gIEluIHRoaXMgbW9kZWwsIHRo ZSBOQVMgb3IgdGhlIFBvbGljeSBTZXJ2ZXIgbWFuYWdlcyB0aGUgdG90YWwgYWNjZXNzIGxpbmUK ICAgICAgYmFuZHdpZHRoLCBwZXJmb3JtcyB1bmljYXN0IGFkbWlzc2lvbiBjb250cm9sIGFuZCB1 c2VzIEFOQ1AgdG8KICAgICAgYXV0aG9yaXplIHRoZSBBY2Nlc3MgTm9kZSB0byBwZXJmb3JtIG11 bHRpY2FzdCBBZG1pc3Npb24gQ29udHJvbAogICAgICB3aXRoaW4gdGhlIGJvdW5kcyBvZiB0aGUg ImRlbGVnYXRlZCBiYW5kd2lkdGgiLiAgVXBvbiByZWNlaXZpbmcgYQogICAgICBqb2luIHRvIGEg bXVsdGljYXN0IGZsb3cgd2hpY2ggbWF0Y2hlcyBhbiBlbnRyeSBpbiB0aGUgV2hpdGUgb3IKICAg ICAgR3JleSBMaXN0LCB0aGUgQU4gcGVyZm9ybXMgdGhlIG5lY2Vzc2FyeSBiYW5kd2lkdGggYWRt aXNzaW9uCiAgICAgIGNvbnRyb2wgY2hlY2sgZm9yIHRoZSBuZXcgbXVsdGljYXN0IGZsb3csIGJl Zm9yZSBzdGFydGluZyB0aGUKICAgICAgbXVsdGljYXN0IGZsb3cgcmVwbGljYXRpb24uICBBdCB0 aGlzIHBvaW50LCB0aGVyZSBpcyB0eXBpY2FsbHkgbm8KICAgICAgbmVlZCBmb3IgdGhlIEFjY2Vz cyBOb2RlIHRvIGNvbW11bmljYXRlIHdpdGggdGhlIE5BUyBvciB0aGUgUG9saWN5IFNlcnZlciB2 aWEgdGhlIE5BUy4gIFRoZSBBTkNQCiAgICAgIHJlcXVpcmVtZW50cyB0byBzdXBwb3J0IHRoaXMg YXBwcm9hY2ggYXJlIGFsc28gc3BlY2lmaWVkIGluIHRoaXMKICAgICAgZG9jdW1lbnQuIAoKQmVz dCBSZWdhcmRzLApGb3J0dW5lCgotLS0tLdPKvP7Urbz+LS0tLS0Kt6K8/sjLOiBhbmNwLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzphbmNwLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gT09HSEUgU3Zl bgq3osvNyrG85DogMjAwOMTqMTLUwjEyyNUgMjI6MjYKytW8/sjLOiBNYWdsaW9uZSBSb2JlcnRh OyBhbmNwQGlldGYub3JnCtb3zOI6IFJlOiBbQU5DUF0gV0cgbGFzdCBjYWxsIGZvciBkcmFmdC1p ZXRmLWFuY3AtZnJhbWV3b3JrLTA3LnR4dAoKSGkgUm9iZXJ0YSwKCk1hbnkgdGhhbmtzIGZvciBk b2luZyB0aGUgZnVsbCByZXZpZXcuIEkgc3RpbGwgbmVlZCB0byBkbyB0aGlzIGFzIHdlbGwgLSBm b3Igbm93IEkgYW0gb2sgd2l0aCBhbGwgb2YgeW91ciBzdWdnZXN0ZWQgY2hhbmdlcy4KCkknbSBv ayB0byBoYXZlIG9uZSBzZWN1cml0eSBzZWN0aW9uIGFuZCByZW1vdmUgdGhlICJkdW1teSIgc2Vj dGlvbnMgdGhhdCBhbGwgcG9pbnQgdG8gc2VjdGlvbiA3LgoKUmVnYXJkcywKU3ZlbgoKLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0KRnJvbTogTWFnbGlvbmUgUm9iZXJ0YSBbbWFpbHRvOnJvYmVy dGEubWFnbGlvbmVAdGVsZWNvbWl0YWxpYS5pdF0KU2VudDogdnJpamRhZyAxMiBkZWNlbWJlciAy MDA4IDEwOjI2ClRvOiBPT0dIRSBTdmVuOyBhbmNwQGlldGYub3JnCkNjOiBCT0NDSSBNYXR0aGV3 ClN1YmplY3Q6IFJFOiBXRyBsYXN0IGNhbGwgZm9yIGRyYWZ0LWlldGYtYW5jcC1mcmFtZXdvcmst MDcudHh0CgpIZWxsbywKICAgICAgICAgSSBkaWQgYSBjb21wYXJpc29uIGJldHdlZW4gZHJhZnQg ZHJhZnQtaWV0Zi1hbmNwLWZyYW1ld29yay0wNy50eHQgYW5kIGxhdGVzdCB2ZXJzaW9uIG9mIEJC RiBXVC0xNDcgaW4gb3JkZXIgdG8gaWRlbnRpZnkgdGhlIGRpZmZlcmVuY2VzIGJldHdlZW4gdGhl IHR3byBkb2N1bWVudHMgaW50cm9kdWNlZCB3aXRoIHJlY2VudCBjaGFuZ2VzIGluIFdULTE0Ny4K UGxlYXNlIGZpbmQgbXkgY29tbWVudHMgZm9yIGRyYWZ0IGRyYWZ0LWlldGYtYW5jcC1mcmFtZXdv cmstMDcudHh0IGJlbG93LgpUaGFua3MsCkJlc3QgUmVnYXJkcywKUm9iZXJ0YQoKClNlY3Rpb24g MS4yIHBhZ2UgNQpJIHN1Z2dlc3QgdGhlIGZvbGxvd2luZyBjaGFuZ2VzIGluIG9yZGVyIHRvIHJl ZmxlY3QgQkJGIFdULTE0NwpkZWZpbml0aW9uczoKCiAgICAgICJOZXQgRGF0YSBSYXRlOiBkZWZp bmVkIGJ5IElUVS1UIEcuOTkzLjIsIHNlY3Rpb24gMy4zOSwgaS5lLiB0aGUKICAgICAgcG9ydGlv biBvZiB0aGUgdG90YWwgZGF0YSByYXRlIHRoYXQgY2FuIGJlIHVzZWQgdG8gdHJhbnNtaXQgdXNl cgogICAgICBpbmZvcm1hdGlvbiAoZS5nLiAgQVRNIGNlbGxzIG9yIEV0aGVybmV0IGZyYW1lcyku ICBJdCBleGNsdWRlcwogICAgICBvdmVyaGVhZCB0aGF0IHBlcnRhaW5zIHRvIHRoZSBwaHlzaWNh bCB0cmFuc21pc3Npb24gbWVjaGFuaXNtCiAgICAgIChlLmcuIHRyZWxsaXMgY29kaW5nIGluIGNh c2Ugb2YgRFNMKS4iCgogICBBZGQ6CiAgICAgIkl0IGluY2x1ZGVzIFRQUy1UQyAoVHJhbnNwb3J0 IFByb3RvY29sIFNwZWNpZmljIC0gVHJhbnNtaXNzaW9uCkNvbnZlcmdlbmNlKQogICAgICBlbmNh cHN1bGF0aW9uOyB0aGlzIGlzIHplcm8gZm9yIEFUTSBlbmNhcHN1bGF0aW9uLCBhbmQgbm9uLXpl cm8gZm9yCjY0LzY1CiAgICAgZW5jYXBzdWxhdGlvbi4gIgoKICAgIFJlcGxhY2U6CiAgICBMaW5l IFJhdGU6IHRoZSB0b3RhbCBkYXRhIHJhdGUgaW5jbHVkaW5nIG92ZXJoZWFkLgoKICAgQnk6Cgog IExpbmUgUmF0ZTogZGVmaW5lZCBieSBJVFUtVCBHLjk5My4yLiBJdCBjb250YWlucyB0aGUgY29t cGxldGUgb3ZlcmhlYWQKICBpbmNsdWRpbmcgUlMgYW5kIHRyZWxsaXMgY29kaW5nLgoKClNlY3Rp b24gMi4xIFBhZ2UgOC4KVG8gYmUgY29uc2lzdGVudCB3aXRoIGxhdGVzdCBjaGFuZ2VzIGluIEJC RiBXVC0xNDcgSSBwcm9wb3NlIHRvIHNwbGl0IHJlcG9ydGluZyBhbmQgZW5mb3JjZW1lbnQgZnVu Y3Rpb25zIGluIHR3byBzZXBhcmF0ZSBidWxsZXRzCgpTZWN0aW9uIDIuMi4yIFBhZ2UgOSBsaW5l IDQ2NjogZm9yIGVhY2ggdGVjaG5vbG9neSB0aGVyZSBpcyBhIHJlZmVyZW5jZSB0byBSRkMgSSB3 b3VsZCBzdWdnZXN0IGFkZGluZzoKIElQb0UgZGVmaW5lZCBpbiBSRkMgODk0CgpTZWN0aW9uIDIu NCBwYWdlIDEyIGxpbmUgNjMwOgpSZXBsYWNlOgoiQWxzbywgdGhlcmUgaXMgYSBwb3NzaWJpbGl0 eSB0byBpbnRlZ3JhdGUgdGhpcyB3aXRoIGEgUG9saWN5IFNlcnZlcgogICAoZS5nLiAgUkFESVVT IHNlcnZlcikgdGhhdCBrZWVwcyB0cmFjayBvZiB0aGUgZGlmZmVyZW50IFN1YnNjcmliZXIKICAg cmVsYXRlZCBwYXJhbWV0ZXJzLiIKCkJ5OgoiQWxzbywgdGhlcmUgaXMgYSBwb3NzaWJpbGl0eSB0 byBpbnRlZ3JhdGUgdGhpcyB3aXRoIGEgUG9saWN5IFNlcnZlciBvciBhbiBBQUEvUkFESVVTIHNl cnZlciB0aGF0IGtlZXBzIHRyYWNrIG9mIHRoZSBkaWZmZXJlbnQgU3Vic2NyaWJlciByZWxhdGVk IHBhcmFtZXRlcnMuIgoKU2VjdGlvbiAzLjIgcGFnZSAxNSBsaW5lIDgxODoKUmVwbGFjZQoidGhl IE5BUyBjb3VsZCBxdWVyeSBhIFBvbGljeSBTZXJ2ZXIgKGUuZy4KICAgUkFESVVTIHNlcnZlcikg dG8gcmV0cmlldmUgQWNjZXNzIExvb3AgY29uZmlndXJhdGlvbiBkYXRhLiIKCmJ5CiJ0aGUgTkFT IGNvdWxkIHF1ZXJ5IGEgUG9saWN5IFNlcnZlciBvciBhbiBBQUEvUkFESVVTIHNlcnZlciB0byBy ZXRyaWV2ZSBBY2Nlc3MgTG9vcCBjb25maWd1cmF0aW9uIGRhdGEuIgoKU2VjdGlvbiAzLjQuMiBQ YWdlIDIyIGxpbmUgMTIwOToKUmVwbGFjZToKInBlcmZvcm0gQ0FDIGZvciB1bmljYXN0IGFuZCBt dWx0aWNhc3QKICAgICAgZmxvd3MgYW5kIHBlcmZvcm0gdmlkZW8gYmFuZHdpZHRoIGFjY291bnRp bmcuIgpCeQoicGVyZm9ybSBDQUMgZm9yIHVuaWNhc3QgYW5kIG11bHRpY2FzdAogICAgICBmbG93 cyBhbmQgcGVyZm9ybSB2aWRlbyBiYW5kd2lkdGggbWFuYWdlbWVudCIKCgpTZWN0aW9uIDMuNC4z IFBhZ2UgMjYgbGluZSAxNDI0Ckkgd291bGQgc3VnZ2VzdCByZXBocmFzaW5nIHRoaXMgc2VudGVu Y2UgYXMgQU5DUCBCdWxrIG1lc3NhZ2UgaGFzIGJlZW4gcmVtb3ZlZCBmcm9tIHRoZSBwcm90b2Nv bCBkcmFmdC4KCiJJbiBjYXNlIG9mIHZlcnkgZmFzdCBjaGFubmVsIGNoYW5nZXMsIHRoZSBhbW91 bnQgb2YgSW5mb3JtYXRpb24KICAgUmVwb3J0IG1lc3NhZ2VzIHRvIGJlIHNlbnQgdG8gdGhlIE5B UyBjb3VsZCBiZWNvbWUgaGlnaC4gIEluIG9yZGVyIHRvCiAgIHJlZHVjZSB0aGUgbnVtYmVyIG9m IG1lc3NhZ2VzLCB0aGUgQU4gbWF5IGJ1bmRsZSBzZXZlcmFsIEluZm9ybWF0aW9uCiAgIFJlcG9y dHMgdG9nZXRoZXIgaW4gYSBzaW5nbGUgImJ1bGsgdHJhbnNhY3Rpb24iLiIKClNlY3Rpb24gNC4x ClBhZ2UgMjggIGxpbmUgMTU1NQpUbyBiZSBjb25zaXN0ZW50IHdpdGggcmVjZW50IGNoYW5nZXMg aW4gQkJGIFdULTE0NyByZXBsYWNlOgoiIEluIGxhcmdlIHNjYWxlIG5ldHdvcmtzLCBBY2Nlc3Mg Tm9kZXMgYXJlIHByb3Zpc2lvbmVkIGJ1dCBub3QKICAgICAgYWx3YXlzIGZ1bGx5IHBvcHVsYXRl ZC4gIFRoZXJlZm9yZSB0aGUgQU5DUCBNVVNUIGJlIHNjYWxhYmxlCiAgICAgIGVub3VnaCB0byBh bGxvdyBhIGdpdmVuIE5BUyB0byBjb250cm9sIHRob3VzYW5kcyBvZiBBY2Nlc3MgTm9kZXMKICAg ICAgKGUuZy4gdHlwaWNhbGx5IDUwMDAgdG8gMTAwMDApLiIKCkJ5CiIgVGhlIHByb3RvY29sIG11 c3QgYmUgc2NhbGFibGUgZW5vdWdoIHRvIGFsbG93IGEgZ2l2ZW4gTkFTIHRvIGNvbnRyb2wgYXQg bGVhc3QgNTAwMCBBY2Nlc3MgTm9kZXMuIgoKVGhlIGZvbGxvd2luZyByZXF1aXJlbWVudCBoYXMg YmVlbiByZW1vdmVkIGZyb20gV1QtMTQ3OgoiIFRoZSBBTkNQIFNIT1VMRCBtaW5pbWl6ZSBzb3Vy Y2VzIG9mIGNvbmZpZ3VyYXRpb24gbWlzbWF0Y2gsIGhlbHAKICAgICAgYXV0b21hdGlvbiBvZiB0 aGUgb3ZlcmFsbCBvcGVyYXRpb24gb2YgdGhlIHN5c3RlbXMgaW52b2x2ZWQKICAgICAgKEFjY2Vz cyBOb2RlcyBhbmQgTkFTKSBhbmQgYmUgZWFzeSB0byB0cm91Ymxlc2hvb3QuCgpQYWdlIDI5IGxp bmUgMTU3ODoKIlRoZSBBTkNQIFNIT1VMRCBzdXBwb3J0IGEgbWVhbnMgdG8gaGFuZGxlIHNlbmRp bmcvcmVjZWl2aW5nIGEKICAgICAgbGFyZ2UgYnVyc3Qgb2YgbWVzc2FnZXMgZWZmaWNpZW50bHkg KGUuZy4gdXNpbmcgIm1lc3NhZ2UKICAgICAgYnVuZGxpbmciKS4iCgpJIHN1Z2dlc3QgcmVtb3Zp bmcgIihlLmcuIHVzaW5nICJtZXNzYWdlIGJ1bmRsaW5nIikuIgoKCkRvIHdlIHJlYWxseSBuZWVk IHRocmVlIGRpZmZlcmVudCBzZWN0aW9ucyAoNC4zLCA0LjcuOSBhbmQgNC44LjkpIGZvciBzZWN1 cml0eSAocGx1cyBzZWN0aW9uIDcgIlNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIikgYWxsIG9mIHRo ZW0gcG9pbnRpbmcgdG8gdGhlIGRyYWZ0IGRyYWZ0LWlldGYtYW5jcC1zZWN1cml0eS10aHJlYXRz PyBXb3VsZCBub3QgYmUgcG9zc2libGUgdG8gcmVtb3ZlIHNlY3Rpb25zICA0LjMsIDQuNy45IGFu ZCA0LjguOSBhcyB0aGUgdGV4dCBjb250YWluZWQgaW4gdGhlc2Ugc2VjdGlvbnMgaXMgYWxyZWFk eSBpbiBzZWN0aW9uIDc/CgpTZWN0aW9uIDQuOC4xCkxpbmUgMjA0NToKQXMgcGVyIEJCRiBjb21t ZW50cyByZXBsYWNlOgoiIFRoZSBOQVMgbXVzdCBvbmx5IGNvbW11bmljYXRlIHRvIGF1dGhvcml6 ZWQgQWNjZXNzIE5vZGUgQ29udHJvbAogICAgICBwZWVycy4iCkJ5OgoiIFRoZSBOQVMgbXVzdCBl c3RhYmxpc2ggQU5DUCBBZGphY2VuY2llcyBvbmx5IHdpdGggYXV0aG9yaXplZCBBTkNQIHBlZXJz LiAiCgpTZWN0aW9uIDUuCiIgVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBjb25zaWRlciB0aGUgc3Bl Y2lmaWMgZGV0YWlscyBvZiB0aGUKICAgY29tbXVuaWNhdGlvbiB3aXRoIGEgUG9saWN5IFNlcnZl ciAoZS5nLiB1c2luZyBSQURJVVMpLiIKCkkgd291bGQgcmVtb3ZlICIoZS5nLiB1c2luZyBSQURJ VVMpLiIKCk1pc3NpbmcgUmVmZXJlbmNlcyB0byB0aGUgZm9sbG93aW5nIFJGQ3MgbWVudGlvbmVk IGluIHRoZSB0ZXh0OgpSRkMyNjg0LCBSRkMyNTE2LCBSRkMyMjI1LCBSRkMgODk0CgotIGVkaXRv cmlhbDogcmVwbGFjZSBldmVyeXdoZXJlIGluIHRoZSAgZG9jdW1lbnQgIkRTTCBGb3J1bSIgd2l0 aCAiQnJvYWRiYW5kIEZvcnVtIgoKClRoYW5rcywKUmVnYXJkcywKUm9iZXJ0YQoKLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KUm9iZXJ0YSBNYWds aW9uZSAgLSBDQ0lFICMxODQyNQpUZWxlY29tIEl0YWxpYQpCcm9hZGJhbmQgTmV0d29yayBTZXJ2 aWNlcyBJbm5vdmF0aW9uCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkZy b206IGFuY3AtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmFuY3AtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEJPQ0NJIE1hdHRoZXcKU2VudDogTW9uZGF5LCBEZWNlbWJlciAwOCwgMjAw OCAxOjQyIFBNClRvOiBhbmNwQGlldGYub3JnClN1YmplY3Q6IFtBTkNQXSBXRyBsYXN0IGNhbGwg Zm9yIGRyYWZ0LWlldGYtYW5jcC1mcmFtZXdvcmstMDcudHh0CgoKVGhpcyBlbWFpbCBpcyB0byBz dGFydCBhIHR3byB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZvciBkcmFmdC1pZXRmLWFu Y3AtZnJhbWV3b3JrLTA3LnR4dCBQbGVhc2UgcmV2aWV3IGFuZCBwcm92aWRlIGNvbW1lbnRzIHRv IHRoZSBsaXN0IGJ5IE1vbmRheSAyMm5kIERlY2VtYmVyLgpUaGUgZm9sbG93aW5nIGhhdmUgYWxz byBraW5kbHkgb2ZmZXJlZCB0byByZXZpZXcgdGhlIGRvY3VtZW50OgotIFJvYmVydGEgTWFnbGlv bmUKLSBBbGFuIEthdmFuYWdoCi0gSm9obiBaaGFvCi0gVG9tIFRheWxvcgotIFN2ZW4gT29naGUK LSBGcmFuY29pcyBMZUZhdWNoZXIKCkJlc3QgcmVnYXJkcwpNYXR0aGV3CgoKClF1ZXN0byBtZXNz YWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBh bGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFs dHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXpp b25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8g cXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRp IGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVy ZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3JhemllLgoKUmlzcGV0dGEgbCdhbWJpZW50ZS4gTm9u IHN0YW1wYXJlIHF1ZXN0YSBtYWlsIHNlIG5vbiBlJyBuZWNlc3NhcmlvLgoKCgp3d3cuYXZvaWNv bXVuaWNhcmUuaXQgICAgICBPZ25pIGdpb3JubywgaWwgdHVvIGx1b2dvIGRpIGRpYWxvZ28uCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkFOQ1AgbWFpbGlu ZyBsaXN0CkFOQ1BAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9hbmNwCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K QU5DUCBtYWlsaW5nIGxpc3QKQU5DUEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2FuY3AK From ancp-bounces@ietf.org Wed Dec 17 08:40:00 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3DFB3A6863; Wed, 17 Dec 2008 08:39:59 -0800 (PST) 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 BB0863A6863 for ; Wed, 17 Dec 2008 08:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.552 X-Spam-Level: X-Spam-Status: No, score=-5.552 tagged_above=-999 required=5 tests=[AWL=0.697, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 xkotq1h8nqIv for ; Wed, 17 Dec 2008 08:39:57 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 09E733A684C for ; Wed, 17 Dec 2008 08:39:56 -0800 (PST) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id mBHGdgoM006261; Wed, 17 Dec 2008 17:39:46 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 17 Dec 2008 17:39:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 17 Dec 2008 17:39:40 +0100 Message-ID: <7168964CAC5C144685272595141B6DBA0190EE4F@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt Thread-Index: AclZLWi472QILb2YRiiUO7dT3wLrywAATJCQAADpsIAAnMNzcAAv6A5AALu2qMAARE480A== References: <0458D2EE0C36744BABB36BE37805C29A03016CC2@FRVELSMBS11.ad2.ad.alcatel.com> <7168964CAC5C144685272595141B6DBA018AD8BC@FRVELSMBS22.ad2.ad.alcatel.com> From: "OOGHE Sven" To: "Reith, Lothar" , "Maglione Roberta" , X-OriginalArrivalTime: 17 Dec 2008 16:39:45.0591 (UTC) FILETIME=[11A7CC70:01C96066] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [ANCP] WG last call for draft-ietf-ancp-framework-07.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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org I Lothar, I think Roberta's rationale was to align between the ANCP framework and Bro= adband Forum WT-147. In WT-147, we consistently made use of "AAA or Policy = Server" terminology. = So, while I agree that a AAA server can be regarded as a kind of Policy Ser= ver, I would favor Roberta's proposal. Regards, Sven -----Original Message----- From: Reith, Lothar [mailto:Lothar.Reith@detecon.com] = Sent: dinsdag 16 december 2008 9:01 To: OOGHE Sven; Maglione Roberta; ancp@ietf.org Subject: AW: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt Hi Roberta and Sven, I would like to suggest a minor change to Roberta's proposal: Roberta proposed: Section 3.2 page 15 line 818: Replace "the NAS could query a Policy Server (e.g. RADIUS server) to retrieve Access Loop configuration data." by "the NAS could query a Policy Server or an AAA/RADIUS server to retrieve Ac= cess Loop configuration data." however, I would suggest to Replace the word "or" by the word "such as" = by "the NAS could query a Policy Server such as an AAA/RADIUS server to retrie= ve Access Loop configuration data." There are many reasons for this, which I will be happy to explain if need b= e. Best Regards, Lothar = -----Urspr=FCngliche Nachricht----- Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von OO= GHE Sven Gesendet: Freitag, 12. Dezember 2008 15:26 An: Maglione Roberta; ancp@ietf.org Betreff: Re: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt Hi Roberta, Many thanks for doing the full review. I still need to do this as well - fo= r now I am ok with all of your suggested changes. I'm ok to have one security section and remove the "dummy" sections that al= l point to section 7. Regards, Sven -----Original Message----- From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] Sent: vrijdag 12 december 2008 10:26 To: OOGHE Sven; ancp@ietf.org Cc: BOCCI Matthew Subject: RE: WG last call for draft-ietf-ancp-framework-07.txt Hello, I did a comparison between draft draft-ietf-ancp-framework-07.txt = and latest version of BBF WT-147 in order to identify the differences betwe= en the two documents introduced with recent changes in WT-147. Please find my comments for draft draft-ietf-ancp-framework-07.txt below. Thanks, Best Regards, Roberta Section 1.2 page 5 I suggest the following changes in order to reflect BBF WT-147 definitions: "Net Data Rate: defined by ITU-T G.993.2, section 3.39, i.e. the portion of the total data rate that can be used to transmit user information (e.g. ATM cells or Ethernet frames). It excludes overhead that pertains to the physical transmission mechanism (e.g. trellis coding in case of DSL)." Add: "It includes TPS-TC (Transport Protocol Specific - Transmission Convergence) encapsulation; this is zero for ATM encapsulation, and non-zero for 6= 4/65 encapsulation. " Replace: Line Rate: the total data rate including overhead. By: Line Rate: defined by ITU-T G.993.2. It contains the complete overhead including RS and trellis coding. Section 2.1 Page 8. To be consistent with latest changes in BBF WT-147 I propose to split repor= ting and enforcement functions in two separate bullets Section 2.2.2 Page 9 line 466: for each technology there is a reference to = RFC I would suggest adding: IPoE defined in RFC 894 Section 2.4 page 12 line 630: Replace: "Also, there is a possibility to integrate this with a Policy Server (e.g. RADIUS server) that keeps track of the different Subscriber related parameters." By: "Also, there is a possibility to integrate this with a Policy Server or an = AAA/RADIUS server that keeps track of the different Subscriber related para= meters." Section 3.2 page 15 line 818: Replace "the NAS could query a Policy Server (e.g. RADIUS server) to retrieve Access Loop configuration data." by "the NAS could query a Policy Server or an AAA/RADIUS server to retrieve Ac= cess Loop configuration data." Section 3.4.2 Page 22 line 1209: Replace: "perform CAC for unicast and multicast flows and perform video bandwidth accounting." By "perform CAC for unicast and multicast flows and perform video bandwidth management" Section 3.4.3 Page 26 line 1424 I would suggest rephrasing this sentence as ANCP Bulk message has been remo= ved from the protocol draft. "In case of very fast channel changes, the amount of Information Report messages to be sent to the NAS could become high. In order to reduce the number of messages, the AN may bundle several Information Reports together in a single "bulk transaction"." Section 4.1 Page 28 line 1555 To be consistent with recent changes in BBF WT-147 replace: " In large scale networks, Access Nodes are provisioned but not always fully populated. Therefore the ANCP MUST be scalable enough to allow a given NAS to control thousands of Access Nodes (e.g. typically 5000 to 10000)." By " The protocol must be scalable enough to allow a given NAS to control at l= east 5000 Access Nodes." The following requirement has been removed from WT-147: " The ANCP SHOULD minimize sources of configuration mismatch, help automation of the overall operation of the systems involved (Access Nodes and NAS) and be easy to troubleshoot. Page 29 line 1578: "The ANCP SHOULD support a means to handle sending/receiving a large burst of messages efficiently (e.g. using "message bundling")." I suggest removing "(e.g. using "message bundling")." Do we really need three different sections (4.3, 4.7.9 and 4.8.9) for secur= ity (plus section 7 "Security considerations") all of them pointing to the = draft draft-ietf-ancp-security-threats? Would not be possible to remove sec= tions 4.3, 4.7.9 and 4.8.9 as the text contained in these sections is alre= ady in section 7? Section 4.8.1 Line 2045: As per BBF comments replace: " The NAS must only communicate to authorized Access Node Control peers." By: " The NAS must establish ANCP Adjacencies only with authorized ANCP peers. " Section 5. " This document does not consider the specific details of the communication with a Policy Server (e.g. using RADIUS)." I would remove "(e.g. using RADIUS)." Missing References to the following RFCs mentioned in the text: RFC2684, RFC2516, RFC2225, RFC 894 - editorial: replace everywhere in the document "DSL Forum" with "Broadban= d Forum" Thanks, Regards, Roberta ----------------------------------------------------- Roberta Maglione - CCIE #18425 Telecom Italia Broadband Network Services Innovation ----------------------------------------------------- ________________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of BOC= CI Matthew Sent: Monday, December 08, 2008 1:42 PM To: ancp@ietf.org Subject: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt This email is to start a two week working group last call for draft-ietf-an= cp-framework-07.txt Please review and provide comments to the list by Monda= y 22nd December. The following have also kindly offered to review the document: - Roberta Maglione - Alan Kavanagh - John Zhao - Tom Taylor - Sven Ooghe - Francois LeFaucher Best regards Matthew Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. Rispetta l'ambiente. Non stampare questa mail se non e' necessario. www.avoicomunicare.it Ogni giorno, il tuo luogo di dialogo. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Dec 19 03:00:24 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93C033A6869; Fri, 19 Dec 2008 03:00:24 -0800 (PST) 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 09A7C28C105 for ; Fri, 19 Dec 2008 02:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.525 X-Spam-Level: X-Spam-Status: No, score=-5.525 tagged_above=-999 required=5 tests=[AWL=0.917, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] 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 h5d7UK7pQ8m7 for ; Fri, 19 Dec 2008 02:48:02 -0800 (PST) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id 46E6028C0F5 for ; Fri, 19 Dec 2008 02:48:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,248,1228089600"; d="scan'208";a="36863612" Received: from ind-dkim-2.cisco.com ([64.104.140.59]) by ind-iport-1.cisco.com with ESMTP; 19 Dec 2008 10:47:38 +0000 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mBJAlbQn016568 for ; Fri, 19 Dec 2008 16:17:37 +0530 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBJAlYSD006409 for ; Fri, 19 Dec 2008 10:47:34 GMT Received: from xmb-blr-415.apac.cisco.com ([64.104.140.144]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Dec 2008 16:17:32 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Dec 2008 16:17:31 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Partition ID Thread-Index: AclhxzHPRVPuEywfSU2ks5axwepmUw== From: "Shridhar Rao (shrirao)" To: X-OriginalArrivalTime: 19 Dec 2008 10:47:33.0078 (UTC) FILETIME=[3285B760:01C961C7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=667; t=1229683657; x=1230547657; c=relaxed/simple; s=inddkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shrirao@cisco.com; z=From:=20=22Shridhar=20Rao=20(shrirao)=22=20 |Subject:=20Partition=20ID=20 |Sender:=20; bh=+PREMfBSYDVWn2hhOf0m58daZdsmtr/8csbk/QgbooU=; b=eePepUevRdFiT2Je5jp0sKCi4oS7aSdLQWSGFLyf4ySjHFCfsN1IksrZ15 Mpityt9+qoR61r08RB72akfgLPbcBxPk+cKtjrqCgYKISC0XMZhZ7ZoRRp8x 8lIEU+60eu; Authentication-Results: ind-dkim-2; header.From=shrirao@cisco.com; dkim=pass ( sig from cisco.com/inddkim2002 verified; ); Subject: [ANCP] Partition ID 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hello, We like to understand the real use for Partition ID in case of NAS. If AN wants to use Partition ID for dividing itself into multiple logical partitions with each controlling certain access ports on it, it can be done by some local configuration on AN. Is there a real need for NAS to be aware of it? If Partition ID field has no use in NAS, it can be reused instead as first byte of a 4 byte Transaction Id field (Tr ID is now a 3 byte quantity starting at a odd byte location), and NAS need not worry about partition ID at all eliminating the need for exchange of adjacency messages for convergence of Partition ID. Thanks, Shridhara rao _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Dec 19 09:46:46 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68D2F28C152; Fri, 19 Dec 2008 09:46:46 -0800 (PST) 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 4149C28C169 for ; Fri, 19 Dec 2008 09:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 nwjXKdwyuiNO for ; Fri, 19 Dec 2008 09:46:43 -0800 (PST) Received: from dtc035.detecon.net (dtc035.detecon.net [194.25.60.135]) by core3.amsl.com (Postfix) with ESMTP id DA8B928C152 for ; Fri, 19 Dec 2008 09:46:42 -0800 (PST) Received: from unknown (HELO dc00357.detecon.com) ([172.16.10.107]) by relay.dtc035.detecon.net with ESMTP; 19 Dec 2008 18:46:31 +0100 Received: from DC00331.detecon.com ([172.16.10.78]) by dc00357.detecon.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Dec 2008 18:46:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Dec 2008 18:46:29 +0100 Message-ID: In-Reply-To: <7168964CAC5C144685272595141B6DBA0190EE4F@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt Thread-Index: AclZLWi472QILb2YRiiUO7dT3wLrywAATJCQAADpsIAAnMNzcAAv6A5AALu2qMAARE480ABlBXGw References: <0458D2EE0C36744BABB36BE37805C29A03016CC2@FRVELSMBS11.ad2.ad.alcatel.com> <7168964CAC5C144685272595141B6DBA018AD8BC@FRVELSMBS22.ad2.ad.alcatel.com> <7168964CAC5C144685272595141B6DBA0190EE4F@FRVELSMBS22.ad2.ad.alcatel.com> From: "Reith, Lothar" To: "OOGHE Sven" , "Maglione Roberta" , X-OriginalArrivalTime: 19 Dec 2008 17:46:31.0347 (UTC) FILETIME=[BA192830:01C96201] Subject: Re: [ANCP] WG last call for draft-ietf-ancp-framework-07.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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi Sven, from an architecture perspective, I think the ANCP framework should not man= date things outside of its scope. ANCP is a protocol between AN and NAS. ANCP Framework should not mandate a northbound protocol of the NAS, or a no= rthbound communication partner of the NAS from where the NAS has received t= he authority to perform the delegation of authority downwards towards the A= N. WT-147 is another story. There it is fully okay to say "AAA or Policy Serve= r" which is in my mind is intentionally vague enough to allow implementing = whatever protocol you want. = We should avoid having to update the ANCP framework, just because someone w= ants to use some other protocol on the northbound interface of the NAS. I agree with you, that Roberta's proposal should be changed to "AAA or Pol= icy Server" to align it with WT-147 (currently it refers to RADIUS - a prot= ocol - not to AAA - a collection of functions) I think the ANCP Framework should not care about the northbound protocol of= the NAS - it could be anything - as long as it is fit for the purpose of i= mplementing a delegation of authority. The important thing is only, that the NAS is legitimately performing the de= legation of authority, which implies, that it has received a delegation of = authority itself (originated from a principal according to principal-agent = theory). = Best Regards Lothar = -----Urspr=FCngliche Nachricht----- Von: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be] = Gesendet: Mittwoch, 17. Dezember 2008 17:40 An: Reith, Lothar; Maglione Roberta; ancp@ietf.org Betreff: RE: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt I Lothar, I think Roberta's rationale was to align between the ANCP framework and Bro= adband Forum WT-147. In WT-147, we consistently made use of "AAA or Policy = Server" terminology. = So, while I agree that a AAA server can be regarded as a kind of Policy Ser= ver, I would favor Roberta's proposal. Regards, Sven -----Original Message----- From: Reith, Lothar [mailto:Lothar.Reith@detecon.com] Sent: dinsdag 16 december 2008 9:01 To: OOGHE Sven; Maglione Roberta; ancp@ietf.org Subject: AW: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt Hi Roberta and Sven, I would like to suggest a minor change to Roberta's proposal: Roberta proposed: Section 3.2 page 15 line 818: Replace "the NAS could query a Policy Server (e.g. RADIUS server) to retrieve Access Loop configuration data." by "the NAS could query a Policy Server or an AAA/RADIUS server to retrieve Ac= cess Loop configuration data." however, I would suggest to Replace the word "or" by the word "such as" = by "the NAS could query a Policy Server such as an AAA/RADIUS server to retrie= ve Access Loop configuration data." There are many reasons for this, which I will be happy to explain if need b= e. Best Regards, Lothar = -----Urspr=FCngliche Nachricht----- Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von OO= GHE Sven Gesendet: Freitag, 12. Dezember 2008 15:26 An: Maglione Roberta; ancp@ietf.org Betreff: Re: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt Hi Roberta, Many thanks for doing the full review. I still need to do this as well - fo= r now I am ok with all of your suggested changes. I'm ok to have one security section and remove the "dummy" sections that al= l point to section 7. Regards, Sven -----Original Message----- From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] Sent: vrijdag 12 december 2008 10:26 To: OOGHE Sven; ancp@ietf.org Cc: BOCCI Matthew Subject: RE: WG last call for draft-ietf-ancp-framework-07.txt Hello, I did a comparison between draft draft-ietf-ancp-framework-07.txt = and latest version of BBF WT-147 in order to identify the differences betwe= en the two documents introduced with recent changes in WT-147. Please find my comments for draft draft-ietf-ancp-framework-07.txt below. Thanks, Best Regards, Roberta Section 1.2 page 5 I suggest the following changes in order to reflect BBF WT-147 definitions: "Net Data Rate: defined by ITU-T G.993.2, section 3.39, i.e. the portion of the total data rate that can be used to transmit user information (e.g. ATM cells or Ethernet frames). It excludes overhead that pertains to the physical transmission mechanism (e.g. trellis coding in case of DSL)." Add: "It includes TPS-TC (Transport Protocol Specific - Transmission Convergence) encapsulation; this is zero for ATM encapsulation, and non-zero for 6= 4/65 encapsulation. " Replace: Line Rate: the total data rate including overhead. By: Line Rate: defined by ITU-T G.993.2. It contains the complete overhead including RS and trellis coding. Section 2.1 Page 8. To be consistent with latest changes in BBF WT-147 I propose to split repor= ting and enforcement functions in two separate bullets Section 2.2.2 Page 9 line 466: for each technology there is a reference to = RFC I would suggest adding: IPoE defined in RFC 894 Section 2.4 page 12 line 630: Replace: "Also, there is a possibility to integrate this with a Policy Server (e.g. RADIUS server) that keeps track of the different Subscriber related parameters." By: "Also, there is a possibility to integrate this with a Policy Server or an = AAA/RADIUS server that keeps track of the different Subscriber related para= meters." Section 3.2 page 15 line 818: Replace "the NAS could query a Policy Server (e.g. RADIUS server) to retrieve Access Loop configuration data." by "the NAS could query a Policy Server or an AAA/RADIUS server to retrieve Ac= cess Loop configuration data." Section 3.4.2 Page 22 line 1209: Replace: "perform CAC for unicast and multicast flows and perform video bandwidth accounting." By "perform CAC for unicast and multicast flows and perform video bandwidth management" Section 3.4.3 Page 26 line 1424 I would suggest rephrasing this sentence as ANCP Bulk message has been remo= ved from the protocol draft. "In case of very fast channel changes, the amount of Information Report messages to be sent to the NAS could become high. In order to reduce the number of messages, the AN may bundle several Information Reports together in a single "bulk transaction"." Section 4.1 Page 28 line 1555 To be consistent with recent changes in BBF WT-147 replace: " In large scale networks, Access Nodes are provisioned but not always fully populated. Therefore the ANCP MUST be scalable enough to allow a given NAS to control thousands of Access Nodes (e.g. typically 5000 to 10000)." By " The protocol must be scalable enough to allow a given NAS to control at l= east 5000 Access Nodes." The following requirement has been removed from WT-147: " The ANCP SHOULD minimize sources of configuration mismatch, help automation of the overall operation of the systems involved (Access Nodes and NAS) and be easy to troubleshoot. Page 29 line 1578: "The ANCP SHOULD support a means to handle sending/receiving a large burst of messages efficiently (e.g. using "message bundling")." I suggest removing "(e.g. using "message bundling")." Do we really need three different sections (4.3, 4.7.9 and 4.8.9) for secur= ity (plus section 7 "Security considerations") all of them pointing to the = draft draft-ietf-ancp-security-threats? Would not be possible to remove sec= tions 4.3, 4.7.9 and 4.8.9 as the text contained in these sections is alre= ady in section 7? Section 4.8.1 Line 2045: As per BBF comments replace: " The NAS must only communicate to authorized Access Node Control peers." By: " The NAS must establish ANCP Adjacencies only with authorized ANCP peers. " Section 5. " This document does not consider the specific details of the communication with a Policy Server (e.g. using RADIUS)." I would remove "(e.g. using RADIUS)." Missing References to the following RFCs mentioned in the text: RFC2684, RFC2516, RFC2225, RFC 894 - editorial: replace everywhere in the document "DSL Forum" with "Broadban= d Forum" Thanks, Regards, Roberta ----------------------------------------------------- Roberta Maglione - CCIE #18425 Telecom Italia Broadband Network Services Innovation ----------------------------------------------------- ________________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of BOC= CI Matthew Sent: Monday, December 08, 2008 1:42 PM To: ancp@ietf.org Subject: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt This email is to start a two week working group last call for draft-ietf-an= cp-framework-07.txt Please review and provide comments to the list by Monda= y 22nd December. The following have also kindly offered to review the document: - Roberta Maglione - Alan Kavanagh - John Zhao - Tom Taylor - Sven Ooghe - Francois LeFaucher Best regards Matthew Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. Rispetta l'ambiente. Non stampare questa mail se non e' necessario. www.avoicomunicare.it Ogni giorno, il tuo luogo di dialogo. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Dec 22 00:56:59 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 679E73A68D5; Mon, 22 Dec 2008 00:56:59 -0800 (PST) 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 438803A6981 for ; Mon, 22 Dec 2008 00:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 VVhaOVJS6Gh2 for ; Mon, 22 Dec 2008 00:56:56 -0800 (PST) Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by core3.amsl.com (Postfix) with ESMTP id 652993A67F6 for ; Mon, 22 Dec 2008 00:56:56 -0800 (PST) Received: from GRFHUB706RM001.griffon.local (10.19.3.71) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.1.311.2; Mon, 22 Dec 2008 09:58:59 +0100 Received: from GRFMBX702RM001.griffon.local ([10.19.3.19]) by GRFHUB706RM001.griffon.local ([10.19.9.239]) with mapi; Mon, 22 Dec 2008 09:56:45 +0100 From: Maglione Roberta To: "'Reith, Lothar'" , "ancp@ietf.org" Date: Mon, 22 Dec 2008 09:56:44 +0100 Thread-Topic: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt Thread-Index: AclZLWi472QILb2YRiiUO7dT3wLrywAATJCQAADpsIAAnMNzcAAv6A5AALu2qMAARE480ABlBXGwAIXCwFA= Message-ID: References: <0458D2EE0C36744BABB36BE37805C29A03016CC2@FRVELSMBS11.ad2.ad.alcatel.com> <7168964CAC5C144685272595141B6DBA018AD8BC@FRVELSMBS22.ad2.ad.alcatel.com> <7168964CAC5C144685272595141B6DBA0190EE4F@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: OOGHE Sven Subject: Re: [ANCP] WG last call for draft-ietf-ancp-framework-07.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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi Lothar, For some reasons I didn't receive your previous email, that's why I did= n't reply earlier. I agree with you that ANCP is a protocol between AN and NAS, thus the ANCP = framework should not mandate things outside of its scope. The rational behind my comment was that the RADIUS can be seen as one examp= le of Policy Server; I made a similar comments first for WT-147 because in = many places WT-147 mentioned only "Policy Server" and not the Radius Serve= r, but I believe your text is more precise than mine, thus I support your p= roposal: "the NAS could query a Policy Server such as an AAA/RADIUS server to retrie= ve Access Loop configuration data." Thanks, Regards, Roberta -----Original Message----- From: Reith, Lothar [mailto:Lothar.Reith@detecon.com] Sent: Friday, December 19, 2008 6:46 PM To: OOGHE Sven; Maglione Roberta; ancp@ietf.org Subject: AW: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt Hi Sven, from an architecture perspective, I think the ANCP framework should not man= date things outside of its scope. ANCP is a protocol between AN and NAS. ANCP Framework should not mandate a northbound protocol of the NAS, or a no= rthbound communication partner of the NAS from where the NAS has received t= he authority to perform the delegation of authority downwards towards the A= N. WT-147 is another story. There it is fully okay to say "AAA or Policy Serve= r" which is in my mind is intentionally vague enough to allow implementing = whatever protocol you want. We should avoid having to update the ANCP framework, just because someone w= ants to use some other protocol on the northbound interface of the NAS. I agree with you, that Roberta's proposal should be changed to "AAA or Pol= icy Server" to align it with WT-147 (currently it refers to RADIUS - a prot= ocol - not to AAA - a collection of functions) I think the ANCP Framework should not care about the northbound protocol of= the NAS - it could be anything - as long as it is fit for the purpose of i= mplementing a delegation of authority. The important thing is only, that the NAS is legitimately performing the de= legation of authority, which implies, that it has received a delegation of = authority itself (originated from a principal according to principal-agent = theory). Best Regards Lothar -----Urspr=FCngliche Nachricht----- Von: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be] Gesendet: Mittwoch, 17. Dezember 2008 17:40 An: Reith, Lothar; Maglione Roberta; ancp@ietf.org Betreff: RE: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt I Lothar, I think Roberta's rationale was to align between the ANCP framework and Bro= adband Forum WT-147. In WT-147, we consistently made use of "AAA or Policy = Server" terminology. So, while I agree that a AAA server can be regarded as a kind of Policy Ser= ver, I would favor Roberta's proposal. Regards, Sven -----Original Message----- From: Reith, Lothar [mailto:Lothar.Reith@detecon.com] Sent: dinsdag 16 december 2008 9:01 To: OOGHE Sven; Maglione Roberta; ancp@ietf.org Subject: AW: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt Hi Roberta and Sven, I would like to suggest a minor change to Roberta's proposal: Roberta proposed: Section 3.2 page 15 line 818: Replace "the NAS could query a Policy Server (e.g. RADIUS server) to retrieve Access Loop configuration data." by "the NAS could query a Policy Server or an AAA/RADIUS server to retrieve Ac= cess Loop configuration data." however, I would suggest to Replace the word "or" by the word "such as" by "the NAS could query a Policy Server such as an AAA/RADIUS server to retrie= ve Access Loop configuration data." There are many reasons for this, which I will be happy to explain if need b= e. Best Regards, Lothar -----Urspr=FCngliche Nachricht----- Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von OO= GHE Sven Gesendet: Freitag, 12. Dezember 2008 15:26 An: Maglione Roberta; ancp@ietf.org Betreff: Re: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt Hi Roberta, Many thanks for doing the full review. I still need to do this as well - fo= r now I am ok with all of your suggested changes. I'm ok to have one security section and remove the "dummy" sections that al= l point to section 7. Regards, Sven -----Original Message----- From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] Sent: vrijdag 12 december 2008 10:26 To: OOGHE Sven; ancp@ietf.org Cc: BOCCI Matthew Subject: RE: WG last call for draft-ietf-ancp-framework-07.txt Hello, I did a comparison between draft draft-ietf-ancp-framework-07.txt = and latest version of BBF WT-147 in order to identify the differences betwe= en the two documents introduced with recent changes in WT-147. Please find my comments for draft draft-ietf-ancp-framework-07.txt below. Thanks, Best Regards, Roberta Section 1.2 page 5 I suggest the following changes in order to reflect BBF WT-147 definitions: "Net Data Rate: defined by ITU-T G.993.2, section 3.39, i.e. the portion of the total data rate that can be used to transmit user information (e.g. ATM cells or Ethernet frames). It excludes overhead that pertains to the physical transmission mechanism (e.g. trellis coding in case of DSL)." Add: "It includes TPS-TC (Transport Protocol Specific - Transmission Convergence) encapsulation; this is zero for ATM encapsulation, and non-zero for 6= 4/65 encapsulation. " Replace: Line Rate: the total data rate including overhead. By: Line Rate: defined by ITU-T G.993.2. It contains the complete overhead including RS and trellis coding. Section 2.1 Page 8. To be consistent with latest changes in BBF WT-147 I propose to split repor= ting and enforcement functions in two separate bullets Section 2.2.2 Page 9 line 466: for each technology there is a reference to = RFC I would suggest adding: IPoE defined in RFC 894 Section 2.4 page 12 line 630: Replace: "Also, there is a possibility to integrate this with a Policy Server (e.g. RADIUS server) that keeps track of the different Subscriber related parameters." By: "Also, there is a possibility to integrate this with a Policy Server or an = AAA/RADIUS server that keeps track of the different Subscriber related para= meters." Section 3.2 page 15 line 818: Replace "the NAS could query a Policy Server (e.g. RADIUS server) to retrieve Access Loop configuration data." by "the NAS could query a Policy Server or an AAA/RADIUS server to retrieve Ac= cess Loop configuration data." Section 3.4.2 Page 22 line 1209: Replace: "perform CAC for unicast and multicast flows and perform video bandwidth accounting." By "perform CAC for unicast and multicast flows and perform video bandwidth management" Section 3.4.3 Page 26 line 1424 I would suggest rephrasing this sentence as ANCP Bulk message has been remo= ved from the protocol draft. "In case of very fast channel changes, the amount of Information Report messages to be sent to the NAS could become high. In order to reduce the number of messages, the AN may bundle several Information Reports together in a single "bulk transaction"." Section 4.1 Page 28 line 1555 To be consistent with recent changes in BBF WT-147 replace: " In large scale networks, Access Nodes are provisioned but not always fully populated. Therefore the ANCP MUST be scalable enough to allow a given NAS to control thousands of Access Nodes (e.g. typically 5000 to 10000)." By " The protocol must be scalable enough to allow a given NAS to control at l= east 5000 Access Nodes." The following requirement has been removed from WT-147: " The ANCP SHOULD minimize sources of configuration mismatch, help automation of the overall operation of the systems involved (Access Nodes and NAS) and be easy to troubleshoot. Page 29 line 1578: "The ANCP SHOULD support a means to handle sending/receiving a large burst of messages efficiently (e.g. using "message bundling")." I suggest removing "(e.g. using "message bundling")." Do we really need three different sections (4.3, 4.7.9 and 4.8.9) for secur= ity (plus section 7 "Security considerations") all of them pointing to the = draft draft-ietf-ancp-security-threats? Would not be possible to remove sec= tions 4.3, 4.7.9 and 4.8.9 as the text contained in these sections is alre= ady in section 7? Section 4.8.1 Line 2045: As per BBF comments replace: " The NAS must only communicate to authorized Access Node Control peers." By: " The NAS must establish ANCP Adjacencies only with authorized ANCP peers. " Section 5. " This document does not consider the specific details of the communication with a Policy Server (e.g. using RADIUS)." I would remove "(e.g. using RADIUS)." Missing References to the following RFCs mentioned in the text: RFC2684, RFC2516, RFC2225, RFC 894 - editorial: replace everywhere in the document "DSL Forum" with "Broadban= d Forum" Thanks, Regards, Roberta ----------------------------------------------------- Roberta Maglione - CCIE #18425 Telecom Italia Broadband Network Services Innovation ----------------------------------------------------- ________________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of BOC= CI Matthew Sent: Monday, December 08, 2008 1:42 PM To: ancp@ietf.org Subject: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt This email is to start a two week working group last call for draft-ietf-an= cp-framework-07.txt Please review and provide comments to the list by Monda= y 22nd December. The following have also kindly offered to review the document: - Roberta Maglione - Alan Kavanagh - John Zhao - Tom Taylor - Sven Ooghe - Francois LeFaucher Best regards Matthew Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. Rispetta l'ambiente. Non stampare questa mail se non e' necessario. www.avoicomunicare.it Ogni giorno, il tuo luogo di dialogo. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. Rispetta l'ambiente. Non stampare questa mail se non e' necessario. www.avoicomunicare.it Ogni giorno, il tuo luogo di dialogo. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Dec 31 01:31:19 2008 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5985C3A67F7; Wed, 31 Dec 2008 01:31:19 -0800 (PST) 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 4F46F3A67F7 for ; Wed, 31 Dec 2008 01:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.521 X-Spam-Level: X-Spam-Status: No, score=-10.521 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156] 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 aTYtsEl7mCbS for ; Wed, 31 Dec 2008 01:31:17 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1742F3A6405 for ; Wed, 31 Dec 2008 01:31:16 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,307,1228089600"; d="scan'208";a="29770847" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 31 Dec 2008 09:30:53 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBV9UrMG019919 for ; Wed, 31 Dec 2008 10:30:53 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBV9UrT5000642 for ; Wed, 31 Dec 2008 09:30:53 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Dec 2008 10:30:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 31 Dec 2008 10:30:44 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Partition ID Thread-Index: AclhxzHPRVPuEywfSU2ks5axwepmUwJYgWhg References: From: "Wojciech Dec (wdec)" To: "Shridhar Rao (shrirao)" , X-OriginalArrivalTime: 31 Dec 2008 09:30:53.0098 (UTC) FILETIME=[79AD78A0:01C96B2A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1660; t=1230715853; x=1231579853; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20[ANCP]=20Partition=20ID |Sender:=20; bh=btKXMxzcM3PVI6qsl36O/oVcMEVrAAVMOR4PS7Ha1/U=; b=ai8KM7H8/yl48dUlaUyst5cLLR1wG5rKfOQxSnm0KYLv4gRUV8fl0aCwO+ /g+sSJPtOFpONSPsh4vFL5dngpl+HKF6kCAirVgEYfwivCpJVAhFC9AcLWDy u3ei/XWbng; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [ANCP] Partition ID 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org You raise a very good point. The partition "concept" is/was derived from GSMP where presumably a single controller could be managing multiple partitions on a single client. In the current set of ANCP use-cases this does not seem to be required and the partition-id field may be yet another field that could be marked as "obsolete" or simply ignored by the NAS. Could anyone in the WG indicate whether they see a case where a single NAS would be handling multiple partitioned ANCP sessions from a single AN, and what would that case be? Thanks, Woj. > -----Original Message----- > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On > Behalf Of Shridhar Rao (shrirao) > Sent: 19 December 2008 11:48 > To: ancp@ietf.org > Subject: [ANCP] Partition ID > > Hello, > We like to understand the real use for Partition ID in case > of NAS. If AN wants to use Partition ID for dividing itself > into multiple logical partitions with each controlling > certain access ports on it, it can be done by some local > configuration on AN. Is there a real need for NAS to be aware of it? > > If Partition ID field has no use in NAS, it can be reused > instead as first byte of a 4 byte Transaction Id field (Tr ID > is now a 3 byte quantity starting at a odd byte location), > and NAS need not worry about partition ID at all eliminating > the need for exchange of adjacency messages for convergence > of Partition ID. > > Thanks, > Shridhara rao > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp