From dumitrascu.irina@gmail.com Tue Dec 22 06:20:30 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 381AF3A69F3 for ; Tue, 22 Dec 2009 06:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 9C+ptzp9QES1 for ; Tue, 22 Dec 2009 06:20:29 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 1334E3A698C for ; Tue, 22 Dec 2009 06:20:28 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 9so1361115qwb.31 for ; Tue, 22 Dec 2009 06:20:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=lLcxn4zjsGI9Tvr8tchg2sWoyg3GYWcAItarWiC+cb0=; b=oTfB4WrYVrXTUA6WnQ8obOM+0ka69yoakA2pwRryF0Y5LwdkZ2NsKpdb+WWSjzWiAK h3/BnWpdhXrQYbASt0wir265yEvziV6dXOY1iHrY/ot5nqwdMdUBRL9GkmnwKCTFf0tk rKNkkIlf0kwsaGUmXqKk5IfzBDiNpMLLv7qKM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=lA1hixS/YLpnDRI9c5A3mKQQYUPNyZSMxyeffWFNLXxwBgLErciBevOEbQOmpYKRUk td91ciJjN3jrI8sBTLsx4HEfINrxkFQcO22drKvhxckD7Z5RGaw1lSbqyZ5tf0uxCwXx ootab07VTD69qMHKNyLoG9zY0tRV5FFiGz+hU= MIME-Version: 1.0 Received: by 10.229.28.16 with SMTP id k16mr3964638qcc.70.1261491609850; Tue, 22 Dec 2009 06:20:09 -0800 (PST) Date: Tue, 22 Dec 2009 16:20:09 +0200 Message-ID: From: Irina Dumitrascu To: ancp@ietf.org Content-Type: multipart/alternative; boundary=001636426bef4ad4b2047b51e73a X-Mailman-Approved-At: Wed, 23 Dec 2009 00:36:02 -0800 Subject: [ANCP] Questions regarding how is implemented Sender Name for ATM ports X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 08:18:32 -0000 --001636426bef4ad4b2047b51e73a Content-Type: text/plain; charset=ISO-8859-1 Hi, I want to ask you which is the Sender Name implemented for ATM ports. I found that for Ethernet ports, ANCP Sender Name is MAC address, but for ATM I cannot find how sender name is created. Thank you very much, Irina Dumitrascu --001636426bef4ad4b2047b51e73a Content-Type: text/html; charset=ISO-8859-1

Hi,
I want to ask you which is the Sender Name implemented for ATM ports.
I found that for Ethernet ports, ANCP Sender Name is MAC address, but for ATM I cannot find how sender name is created.

Thank you very much,

Irina Dumitrascu

--001636426bef4ad4b2047b51e73a-- From anira@cisco.com Wed Dec 23 10:02:02 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57C253A6A32 for ; Wed, 23 Dec 2009 10:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 hm54rLWKl4Ox for ; Wed, 23 Dec 2009 10:02:01 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id B4CAA3A6A87 for ; Wed, 23 Dec 2009 10:01:54 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none Received: from syd-iport-1.cisco.com ([64.104.193.196]) by sj-iport-4.cisco.com with ESMTP; 23 Dec 2009 18:01:37 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAG/pMUtAaHte/2dsb2JhbADBYZcLhDMEgn0 X-IronPort-AV: E=Sophos;i="4.47,443,1257120000"; d="scan'208,217";a="63302060" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by syd-iport-1.cisco.com with ESMTP; 23 Dec 2009 18:01:37 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nBNI1YIf002730; Wed, 23 Dec 2009 18:01:34 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Dec 2009 23:31:34 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA83F9.F67A011B" Date: Wed, 23 Dec 2009 23:31:31 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Questions regarding how is implemented Sender Name for ATMports Thread-Index: AcqDqvFPy93ZuQzVRMyzdBjavj5ncAARwj+A References: From: "Aniruddha A (anira)" To: "Irina Dumitrascu" X-OriginalArrivalTime: 23 Dec 2009 18:01:34.0398 (UTC) FILETIME=[F6C98DE0:01CA83F9] Cc: ancp@ietf.org Subject: Re: [ANCP] Questions regarding how is implemented Sender Name for ATMports X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 18:02:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA83F9.F67A011B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Irina, =20 ATM interfaces should also have a BIA (hardware address) or, probably the ESI can be used (both are 6 octets) =20 -- Regards, Aniruddha. A =20 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Irina Dumitrascu Sent: Tuesday, December 22, 2009 7:50 PM To: ancp@ietf.org Subject: [ANCP] Questions regarding how is implemented Sender Name for ATMports Hi, I want to ask you which is the Sender Name implemented for ATM ports. I found that for Ethernet ports, ANCP Sender Name is MAC address, but for ATM I cannot find how sender name is created. Thank you very much, Irina Dumitrascu ------_=_NextPart_001_01CA83F9.F67A011B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Irina,

ATM interfaces should also have a BIA (hardware = address)

or, probably the ESI can be used (both are 6=20 octets)

Regards,

Aniruddha. A

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Irina=20 Dumitrascu
Sent: Tuesday, December 22, 2009 7:50 = PM
To:=20 ancp@ietf.org
Subject: [ANCP] Questions regarding how is = implemented=20 Sender Name for ATMports

Hi,
I want to ask you which is the Sender Name = implemented=20 for ATM ports.
I found that for Ethernet ports, ANCP Sender Name is = MAC=20 address, but for ATM I cannot find how sender name is = created.

Thank you=20 very much,

Irina Dumitrascu

------_=_NextPart_001_01CA83F9.F67A011B-- From Hannes.Tschofenig@gmx.net Sat Dec 26 23:44:33 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43BF23A67A7 for ; Sat, 26 Dec 2009 23:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.549 X-Spam-Level: X-Spam-Status: No, score=0.549 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_50=0.001] 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 olWWYV4jm3en for ; Sat, 26 Dec 2009 23:44:32 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id ADEF33A6778 for ; Sat, 26 Dec 2009 23:44:31 -0800 (PST) Received: (qmail 13607 invoked by uid 0); 27 Dec 2009 07:44:11 -0000 Received: from 88.115.222.204 by www171.gmx.net with HTTP; Sun, 27 Dec 2009 08:44:11 +0100 (CET) Content-Type: text/plain; charset="us-ascii" Date: Sun, 27 Dec 2009 08:44:11 +0100 From: "Hannes Tschofenig" Message-ID: <20091227074411.62680@gmx.net> MIME-Version: 1.0 To: ancp@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+I0aom5sCIuZDkSQ1oCjOeOxT1QkNE7w5Lm0etb0 7TAa3OQMr+WdIQaP4OP/nlAiFP79Xbvwem7w== Content-Transfer-Encoding: 7bit X-GMX-UID: I2VeeDFWeWUkI4EFq25neBQjL0tsZg2e X-FuHaFi: 0.53 Subject: [ANCP] My review notes for draft-ietf-ancp-framework-12.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Dec 2009 07:44:33 -0000 Hi all, I just went through http://www.ietf.org/id/draft-ietf-ancp-framework-12.txt. It is a nice and interesting document but I noticed a few minor areas for improvement. 0. Terminology If you cite some ITU-T documents then put the cited text in quotes. If you modify their definition then say so. 1. Definition of "Multicast flow" Here is what you have in the draft " o Multicast Flow: multicast Any Source Multicast (ASM) group or multicast Source Specific Multicast (SSM) (S,G) channel. An application channel (such as a TV channel) is mapped onto a Multicast Flow. " This does not sound complete nor understandable. Looking at RFC 4045 http://tools.ietf.org/html/rfc4045 I can find the following definition: " Multicast flow Designates datagrams sent to a group from a set of sources for which multicast reception is desired. " Maybe this is more appropriate? 3. "General Architecture Aspects" Section The "Access Node Control Mechanism" term is described as " o Access Node Control Mechanism: a method for multiple network scenarios with an extensible communication scheme that conveys status and control information between one or more ANs and one or more NASs without using intermediate element managers. " There are two concepts that readers are typically familiar with, namely a protocol and an architecture. The main product of the working group is the protocol. The architecture already exists elsewhere, namely largely in the Broadband Forum (former DSL Forum) and there is potential (maybe) applicability elsewhere (e.g., IEEE 802.16). Now, Section 2.1 describes something that others would typically call "architecture". Section 2.2 is a mixture of a) description of Figure 1, and b) the text provides an instantiation of the architectural figure shown in Section 2.1. Section 2.3. has the fancy title of "Access Node Control Mechanism Transport Methods". What this section only does is to discuss how QoS treatment of control traffic can be accomplished when used over Ethernet and ATM networks. I don't think that this is crucial for the description of the architecture but your view might be different. Maybe there is a chance to provide a better introduction to this section and a different title for the section. Something like "Preferential Treatment for Signaling Traffic" or "Separating Signaling and Control Traffic". Section 2.4 is also not very fortunate with regard to the section heading. "Operations and Management" is a rather broad term and you address only a very specific aspect in this section, namely the challenge of having more than one management entities and the potential conflicts that may arise. Overall, I believe that there is something wrong with the structure of Section 2. The introduction of Section 2 talks about two aspects that are described but then there are 5 sub-sections, with an unclear relationship among either other. Some "glue" is missing here. 4. Figures have a title. Figure 1 is missing a title. 5. Abbreviations When you introduce abbreviations please expand them (otherwise you will be asked again by the RFC Editor later). 6. "Access Node" and other terms. Section 1.2 defines the term "Access Node" and Section 2.2.3 defines it again. The same is true for "Network Access Server" defined in Section 1.2 and again defined in Section 2.2.6. 7. Justify your statements When you talk about other mechanisms being error prone and complex then you need to provide a discussion why they are error prone or more complex than the mechanism being proposed here to gain credibility. Example: " OSS systems are rarely able to enforce in a reliable and scalable manner the consistency of such data, notably across organizational boundaries. The Access Topology Discovery function allows the NAS to perform these advanced functions without having to depend on an error-prone & possibly complex integration with an OSS system. " 8. Section 3.2 - OPEX I have a question regarding the OPEX statement in the following paragraph: " Access Loop rates are typically configured in a static way. When a Subscriber wants to change its Access Loop rate, the network operator needs to reconfigure the Access Port configuration, possibly implying a business-to-business transaction between an Internet Service Provider (ISP) and an Access Provider. From an Operating Expenditures (OPEX) perspective this is a costly operation. Using the Access Node Control Mechanism to change the Access Loop rate from the NAS avoids those cross-organization business-to- business interactions and allows to centralize Subscriber-related service data in e.g. a Policy Server. " I guess I understand that there are still two organizations involved but you essentially claim that by using some protocol mechanisms the OPEX cost would be reduced compared to a potential human interaction as it is done today. Is my understanding correct? 9. Section 5 "Policy Server Interaction" is useless. Maybe better to delete this section? 10. Editorial issues Let some native English speaker read through the text to make sure that the language, punctuation, etc. problems get fixed. Ciao Hannes From tena@huawei.com Sun Dec 27 05:20:00 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB83F3A67E2 for ; Sun, 27 Dec 2009 05:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.486 X-Spam-Level: X-Spam-Status: No, score=-98.486 tagged_above=-999 required=5 tests=[AWL=2.009, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 LgAa6bCQc5xP for ; Sun, 27 Dec 2009 05:19:59 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 1494A3A67B6 for ; Sun, 27 Dec 2009 05:19:59 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KVB00JP9BOENT@szxga04-in.huawei.com> for ancp@ietf.org; Sun, 27 Dec 2009 21:19:26 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KVB00HWYBOEPL@szxga04-in.huawei.com> for ancp@ietf.org; Sun, 27 Dec 2009 21:19:26 +0800 (CST) Received: from [192.168.5.102] (37.196.35.121.broad.sz.gd.dynamic.163data.com.cn [121.35.196.37]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KVB002ACBODRU@szxml01-in.huawei.com>; Sun, 27 Dec 2009 21:19:26 +0800 (CST) Date: Sun, 27 Dec 2009 21:19:25 +0800 From: Tina TSOU In-reply-to: <20091227074411.62680@gmx.net> To: Hannes Tschofenig Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.936) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT X-Priority: 3 References: <20091227074411.62680@gmx.net> Cc: ancp@ietf.org Subject: Re: [ANCP] My review notes for draft-ietf-ancp-framework-12.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Dec 2009 13:20:00 -0000 Hi Hannes, Merry X'mas and see comments in line... I'm not the editor, just one participant of many. B. R. Tina http://tinatsou.weebly.com/contact.html On Dec 27, 2009, at 3:44 PM, Hannes Tschofenig wrote: > Hi all, > > I just went through http://www.ietf.org/id/draft-ietf-ancp-framework-12.txt > . > > It is a nice and interesting document but I noticed a few minor > areas for improvement. > > 0. Terminology > > If you cite some ITU-T documents then put the cited text in quotes. > If you modify their definition then say so. > > 1. Definition of "Multicast flow" > > Here is what you have in the draft > > " > o Multicast Flow: multicast Any Source Multicast (ASM) group or > multicast Source Specific Multicast (SSM) (S,G) channel. An > application channel (such as a TV channel) is mapped onto a > Multicast Flow. > " > > This does not sound complete nor understandable. > Looking at RFC 4045 http://tools.ietf.org/html/rfc4045 I can find > the following definition: > > " > Multicast flow > > Designates datagrams sent to a group from a set of sources for > which multicast reception is desired. > " > > Maybe this is more appropriate? Agreed. > > > 3. "General Architecture Aspects" Section > > The "Access Node Control Mechanism" term is described as > " > o Access Node Control Mechanism: a method for multiple network > scenarios with an extensible communication scheme that conveys > status and control information between one or more ANs and one or > more NASs without using intermediate element managers. > " > > There are two concepts that readers are typically familiar with, > namely a protocol and an architecture. > The main product of the working group is the protocol. The > architecture already exists elsewhere, namely largely in the > Broadband Forum (former DSL Forum) and there is potential (maybe) > applicability elsewhere (e.g., IEEE 802.16). > > Now, Section 2.1 describes something that others would typically > call "architecture". Section 2.2 is a mixture of a) description of > Figure 1, and > b) the text provides an instantiation of the architectural figure > shown in Section 2.1. > > Section 2.3. has the fancy title of "Access Node Control Mechanism > Transport Methods". What this section only does is to discuss how > QoS treatment of control traffic can be accomplished when used over > Ethernet and ATM networks. I don't think that this is crucial for > the description of the architecture but your view might be > different. Maybe there is a chance to provide a better introduction > to this section and a different title for the section. Something > like "Preferential Treatment for Signaling Traffic" or "Separating > Signaling and Control Traffic". > > Section 2.4 is also not very fortunate with regard to the section > heading. "Operations and Management" is a rather broad term and you > address only a very specific aspect in this section, namely the > challenge of having more than one management entities and the > potential conflicts that may arise. I thought the section of "Operations and Management" is required to be considered, and be described if any. And different draft put the specific aspect under this section. Perhaps keep the section heading "Operations and Management", and add some texts saying this draft only has a specific aspect regarding OPS. > > Overall, I believe that there is something wrong with the structure > of Section 2. The introduction of Section 2 talks about two aspects > that are described but then there are 5 sub-sections, with an > unclear relationship among either other. Some "glue" is missing here. > > 4. Figures have a title. > > Figure 1 is missing a title. > > 5. Abbreviations > > When you introduce abbreviations please expand them (otherwise you > will be asked again by the RFC Editor later). > > 6. "Access Node" and other terms. > > Section 1.2 defines the term "Access Node" and Section 2.2.3 defines > it again. > The same is true for "Network Access Server" defined in Section 1.2 > and again defined in Section 2.2.6. Need to fix them. > > 7. Justify your statements > > When you talk about other mechanisms being error prone and complex > then you need to provide a discussion why they are error prone or > more complex than the mechanism being proposed here to gain > credibility. > > Example: > > " > OSS systems are rarely able to enforce in a reliable and scalable > manner the consistency of such data, notably across organizational > boundaries. > The Access Topology Discovery function allows the NAS to > perform these advanced functions without having to depend on an > error-prone & possibly complex integration with an OSS system. > " Agreed. > > 8. Section 3.2 - OPEX > > I have a question regarding the OPEX statement in the following > paragraph: > > " > Access Loop rates are typically configured in a static way. When a > Subscriber wants to change its Access Loop rate, the network > operator > needs to reconfigure the Access Port configuration, possibly > implying > a business-to-business transaction between an Internet Service > Provider (ISP) and an Access Provider. From an Operating > Expenditures (OPEX) perspective this is a costly operation. > > Using the Access Node Control Mechanism to change the Access Loop > rate from the NAS avoids those cross-organization business-to- > business interactions and allows to centralize Subscriber-related > service data in e.g. a Policy Server. > " > > I guess I understand that there are still two organizations involved > but you essentially claim that by using some protocol mechanisms the > OPEX cost would be reduced compared to a potential human interaction > as it is done today. > Is my understanding correct? I think so. > > > 9. Section 5 "Policy Server Interaction" is useless. Maybe better to > delete this section? It is used in the network, so it is needed. > > 10. Editorial issues > > Let some native English speaker read through the text to make sure > that the language, punctuation, etc. problems get fixed. Agreed. > > > Ciao > Hannes > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp From Hannes.Tschofenig@gmx.net Sun Dec 27 10:26:24 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93B753A691F for ; Sun, 27 Dec 2009 10:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.934 X-Spam-Level: X-Spam-Status: No, score=-0.934 tagged_above=-999 required=5 tests=[AWL=1.665, 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 OU8VR8UsMO9C for ; Sun, 27 Dec 2009 10:26:23 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id EEE433A68DD for ; Sun, 27 Dec 2009 10:26:22 -0800 (PST) Received: (qmail 28440 invoked by uid 0); 27 Dec 2009 18:26:02 -0000 Received: from 88.115.222.204 by www107.gmx.net with HTTP; Sun, 27 Dec 2009 19:26:00 +0100 (CET) Content-Type: text/plain; charset="us-ascii" Date: Sun, 27 Dec 2009 19:26:01 +0100 From: "Hannes Tschofenig" In-Reply-To: Message-ID: <20091227182601.62670@gmx.net> MIME-Version: 1.0 References: <20091227074411.62680@gmx.net> To: Tina TSOU X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+kq+Fc9yekG0n1ptPeTnbOLwmrIAueI2+s1yaAr+ 8rJtfJDLUENeHbJFSZygK2aXd0u/d8FBRSuw== Content-Transfer-Encoding: 7bit X-GMX-UID: jpAEfxlQTXsuJ4AHo2U5HN9CRzdyMoNE X-FuHaFi: 0.57 Cc: ancp@ietf.org Subject: Re: [ANCP] My review notes for draft-ietf-ancp-framework-12.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Dec 2009 18:26:24 -0000 Hi Tina, thanks for the response. See below. -------- Original-Nachricht -------- > Datum: Sun, 27 Dec 2009 21:19:25 +0800 > Von: Tina TSOU > An: Hannes Tschofenig > CC: ancp@ietf.org > Betreff: Re: [ANCP] My review notes for draft-ietf-ancp-framework-12.txt > Hi Hannes, > Merry X'mas and see comments in line... > I'm not the editor, just one participant of many. > > > B. R. > Tina > http://tinatsou.weebly.com/contact.html > > ~snip~ > > Section 2.3. has the fancy title of "Access Node Control Mechanism > > Transport Methods". What this section only does is to discuss how > > QoS treatment of control traffic can be accomplished when used over > > Ethernet and ATM networks. I don't think that this is crucial for > > the description of the architecture but your view might be > > different. Maybe there is a chance to provide a better introduction > > to this section and a different title for the section. Something > > like "Preferential Treatment for Signaling Traffic" or "Separating > > Signaling and Control Traffic". > > > > Section 2.4 is also not very fortunate with regard to the section > > heading. "Operations and Management" is a rather broad term and you > > address only a very specific aspect in this section, namely the > > challenge of having more than one management entities and the > > potential conflicts that may arise. > I thought the section of "Operations and Management" is required to be > considered, and be described if any. And different draft put the > specific aspect under this section. Perhaps keep the section heading > "Operations and Management", and add some texts saying this draft only > has a specific aspect regarding OPS. There is no requirement to have a section with the title "Operations and Management" in IETF drafts. I am, however, not saying that it isn't useful to consider these types of aspects. ~snip~ > > 9. Section 5 "Policy Server Interaction" is useless. Maybe better to > > delete this section? > It is used in the network, so it is needed. Someone else in the document it is already said that there is an interaction with a AAA/Policy Server but it is outside the scope of the document. I am fine with such a scope restriction and hence I don't think it makes sense to make the same statement twice, once in the text and then as a subsection. Ciao Hannes