From ancp-bounces@ietf.org Mon Nov 06 09:53:22 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gh5qT-0007Uw-ED; Mon, 06 Nov 2006 09:53:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh5qR-0007QQ-Ks
	for ancp@ietf.org; Mon, 06 Nov 2006 09:53:03 -0500
Received: from smail.alcatel.fr ([62.23.212.165])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh5qM-00032I-IK
	for ancp@ietf.org; Mon, 06 Nov 2006 09:53:03 -0500
Received: from bemail01.netfr.alcatel.fr (bemail01.netfr.alcatel.fr
	[155.132.251.32])
	by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kA6Eqr7S007385;
	Mon, 6 Nov 2006 15:52:54 +0100
Received: from [172.31.148.94] ([172.31.148.94])
	by bemail01.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163)
	with ESMTP id 2006110615524727:7480 ; Mon, 6 Nov 2006 15:52:47 +0100 
Message-ID: <454F4C3F.8000005@alcatel.be>
Date: Mon, 06 Nov 2006 15:52:47 +0100
From: Sven.Ooghe@alcatel.be
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Wojciech Dec (wdec)" <wdec@cisco.com>, ancp@ietf.org
Subject: Re: [ANCP] RE: draft-ieft-ancp-framework-00.txt
References: <D9872168DBD43A41BD71FFC4713274D402959FDD@xmb-ams-33b.emea.cisco.com>
In-Reply-To: <D9872168DBD43A41BD71FFC4713274D402959FDD@xmb-ams-33b.emea.cisco.com>
X-MIMETrack: Itemize by SMTP Server on BEMAIL01/BE/ALCATEL(Release
	5.0.13aHF163 | June 23, 2005) at 11/06/2006 15:52:47,
	Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 | June
	23, 2005) at 11/06/2006 15:52:49,
	Serialize complete at 11/06/2006 15:52:49
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 73948e4d005645343fd08e813e5615ef
Cc: "Haag, T" <Thomas.Haag@t-systems.com>,
	Michel Platnic <Michel.Platnic@ecitele.com>
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

Hi Woj,

Having reviewed all of your comments, please find below our answers.

Regards,
Sven

Wojciech Dec (wdec) wrote:
> Hi Sven and co-authors,
> 
> Here are my comments regarding the current draft-ietf-ancp-framework
> draft. Feel free to discuss.
> 
> P4 - Control channel and ANC Session definition
> 
> This terminology has me rather uncomfortable. The control channel is
> effectively the logical path along which the IP packet flow happens
> between the two ANCP end-points. I don't quite see why there's a need to
> ascribe particular requirements to the control channel used by the
> protocol, beyond those that are deemed suitable for it by the end users.
> Just like a BGP peering could be made using a dedicated VLAN, etc, in
> many/most it's not and peer-peer security is still achieved using other
> means, and QoS is taken care of by having the BGP packet priority set to
> an appropriate protocol control value - yet I do not recall that any BGP
> spec mandates the use of any such path, etc.

<Sven> The Control Channel basically is nothing more than an IP
interface over which the messages are sent. Section 2.3 lateron
describes ways of mapping this on an ATM or Ethernet channel. I think it
is fair to reword parts of that section so that the use of a separate
PVC or a separate VLAN or certain QoS settings for the Control Channel
are given as typical scenarios yet not as mandatory requirements.
Section 4.4.2 should be written in this spirit as well. In fact for
section 4.4.2 I believe this is the case: both the QoS settings and the
transmission of the messages across the same physical plant are SHOULD
requirements instead of MUSTs.
</Sven>

> The ANC Session is really the ANCP adjacency between a controller and a
> controlled-node. Isn't the term "ANCP adjacency" sufficient?

<Sven>
In case of e.g. LDP, one talks about an "LDP session" and an "LDP Link
Hello Adjacency." An LDP session that exists between two routers is
called an LDP Link Hello Adjacency.

Similarly, we could talk about the ANCP Session (covering all message
exchanges of the use cases) and the ANCP adjacency (which is up or down,
depending on the result of the ANCP adjacency protocol operation).

We suggest to keep both terms and clarify the relation between both in
the beginning of the document. We will perform a detailed check across
the document to be sure that we're using the right term (adjacency or
session) in every case.
</Sven>

> P8 - Access Node Control Mechanism Transport methods section
> This section doesn't use the terminology defined previously, but
> seemingly is referring to the control channel.
> Such a "control channel" shouldn't preclude the idea of using a
> dedicated interface on the Access-Node, and thus the definition of the
> transport as seemingly requiring a logical multiplexer in the form of a
> VLAN tag isn't quite right. One could very well have an untagged
> ethernet interface, if that's one's choice, and VLAN tagging done
> upstream. 

<Sven>
As I mentioned above, I suggest to reword the section so that the text
describes typical scenarios, without mandating a specific scenario or
excluding other schemes.
</Sven>

> Also, what is meant by "for higher-grade connections..." on P9? 
> It also seems to me that the whole sentence could be replaced by
> something simpler like: "Depending on network design, this can be a
> simple VLAN for each Access Node or, one Customer VLAN (C-VLAN) for each
> Access Node within a Service VLAN (S-VLAN) construct".

<Sven>
I believe higher-grade connections refers to access networks with many
access nodes and large amounts of aggregation. We will reword according
to your suggested text.
</Sven>

> P9 - "The control plane interactions are transactional in nature and
> imply a reliable communication channel to share states."
> 
> Terminology: What is the "communication channel"? Do you mean the ANC
> session?
> 
> Not all of the control plane interactions appear to require a
> transactional nature. It would seem that we generally want reliable
> communication, but not necessarily transactional state for all
> interactions eg knowledge of line rate changes is nice to have reliably,
> but doesn't require the protocol to offer a transaction which I
> associate with the ability to acknowledge/deny and revert to some
> previous state or continue with some operation.
> Thus, it appears to me that some of the control plane interactions have
> a transactional nature, and all of the communication is desired to be
> transmitted reliably.

<Sven>
Suggested rewording:
"The ANCP adjacency interactions need to be reliable. In addition to
this, some of the use cases described in section 3.1 also require the
interactions to be performed in a transactional fashion."
</Sven>

> P9 - "Also, when using the Access Node Control Mechanism for performing
> a
>    reporting action, there is a possibility to integrate this with a
>    central Policy Management system that keeps track of the different
>    Subscriber related parameters"
> 
> The type of policy system is really secondary - it's whatever system
> that wants to consume the info. Suggest replacing the text by;
> "Also, when using the Access Node Control Mechanism for performing a
> reporting action, there is a possibility to integrate this with a
> subscriber policy system that keeps track of the different subscriber
> related parameters"

<Sven>
Agreed with the suggested rewording.
</Sven>

> P10 - "In deployments using an ATM aggregation network, the ATM PVC on
> an
>    Access Loop connects the Subscriber to a NAS.  Based on such
>    property, in a PPP scenario, the NAS typically includes a NAS-Port-Id
>    (or NAS-Port in some cases) attribute in RADIUS authentication &
>    accounting packets sent to the RADIUS server(s).  "
> 
> The scenario doesn't necessitate PPP, it's valid for IPoA as well (or
> IPoEoA, etc). Also, these are two different radius attributes, and both
> are commonly used.

<Sven>
Suggested rewording:
"Based on this property, the NAS typically includes a NAS-Port-Id or a
NAS-Port attribute in RADIUS authentication & accounting packets sent to
the RADIUS server(s)."
</Sven>

> P15 - "The ANCP MUST be an open protocol, either an existing protocol
>       endorsed by an appropriate standard body (e.g.  IETF) or a new
>       protocol which will be submitted for standardization to an
>       appropriate standard body."
> 
> Seems that this requirement is rather obsolete, given that we are in the
> IETF trying to define it.

<Sven>
Agreed to remove.
</Sven>

> "The ANCP MUST be transaction-oriented, allowing to reliably share
>       states between the NAS and the Access Node, and recover from loss
>       of synchronization (e.g. node or link failure).  Transactions MUST
>       be either fully completed, or rolled-back to the previous state."
> 
> As per my comment above. It's quite clear that not all transactions need
> to be rolled-back. Thus ANCP MUST allow for transaction-oriented
> processing of selected information exchanges.
> Also, it seems that the immediately following requirement already
> captures the "recover from loss of synchronisation" characteristic, thus
> this is no longer needed here.

<Sven>
Suggested rewording of this requirement and the immediately following
requirement:
"- The ANCP adjacency interactions MUST be reliable.
- The ANCP MUST be able to recover from loss of ANCP messages.
- The ANCP MUST support "request/response" transaction-based
interactions for the NAS to communicate control decisions or request
information from the Access Node. Transactions MUST be either fully
completed, or rolled-back to the previous state.
- The ANCP MUST be able to recover from loss of the ANCP adjacency (e.g.
due to link or node failure) and automatically resynchronize state upon
re-establishing the ANCP adjacency.
"
</Sven>

> Section 4.2
> 
> "The ANCP SHOULD have a "boot" sequence allowing to inform the peer
>       about control capabilities supported by the two peers (Access
>       Node, NAS) and negotiate a common subset. "
> 
> And
> "The ANCP MUST provide a means for the AN and the NAS to perform
>       capability negotiation.
> "
> 
> These two seem to state the same thing, but yet one is a MUST while the
> other a SHOULD. IMO, the MUST is more appropriate.

<Sven>
Agreed, we will keep the second requirement (with MUST) and remove the
first one.
</Sven>

> "   o  The ANCP SHOULD include a "request/response" transaction-oriented
>       model for the NAS to communicate control decisions or request
>       information from the Access Node.  If the response is negative,
>       then the state of the Access Node MUST be unchanged (roll-back)."
> 
> Much has been said about the transactional requirement in the preceding
> paragraphs (and I added some more). Shouldn't this requirement be
> actually a MUST requirement and furthermore expanded to address that
> certain message exchanges are required to be transactional, while others
> don't?

<Sven>
See above for suggested change. With this change, we suggest to drop the
above requirement.
</Sven>

> P17 - "The transport protocol used for the Access Node Control Messages
>       MUST be reliable and scalable."
> 
> The requirement is for ANCP to deliver it's payload info reliably. The
> transport protocol could be unreliable and the ANCP protocol could
> provide the reliability.

<Sven>
See above for suggested change: "The ANCP adjacency interactions MUST be
reliable."
With this change, we suggest to drop the above requirement.
</Sven>

> P17 - "A loss of the Access Node Control Session MUST NOT affect user
>       connectivity and element operation."
> 
> End user?

<Sven>
Correct, end-user, we'll make the change.
</Sven>

> P17 - "For maintenance purpose the Access Node Control Session MUST be
>       designed in a way that any malfunction of the session is
>       automatically detected and reported from the Access Node or NAS to
>       the Element Manager or Network Manager to support the network
>       operator in troubleshooting the network."
> 
> What has the ANC session design got to do reporting failures?

<Sven>
The requirement should be reworded to indicate the capability for both
endpoints of the ANCP adjacency to detect loss of adjacency. Given this
capability, the endpoints can then report to the Element Manager or
Network Manager.

So we suggest to change the requirement to:
"The ANCP adjacency MUST be designed such that loss or malfunction of
the adjacency can be automatically detected by its peers."

In the Access Node and NAS sections, there should then be a requirement
for the nodes to report the loss/malfunction to the Element Manager or
Network Manager.
</Sven>

> P17 - Section 4.4 Access Node Requirements
> 
> This whole section should IMO be redrafted around to reflect the
> protocol requirements arising due to various access-node uses, rather
> than actual access-node requirements. Also, the use of terms like "DSL
> port" would be best avoided if we still want the notion of supporting
> other media types.

<Sven>
We agree to change "DSL port" to "Access Port".

Many of the requirements in this section are requirements for the
framework/architecture in which ANCP is used. As such they may not be
ANCP protocol requirements but still they are important in order to use
the protocol in the overall network scenario.

We suggest to review the section and update where appropriate to reflect
protocol requirements, and at the same time keep the non-protocol
requirements that are important for the framework.
</Sven>

> P18 - Section 4.4.2
> 
> We've defined ANCP to be an IP based control protocol between one node
> and a controller. IMO this whole section is superfluous, since it
> prescribes functionality that is attributed to the way of configuring a
> node and largely independent of the actual protocol requirements. Think
> it can be removed.

<Sven>
We agree that many requirements are not linked to the protocol as such.
However they are important as guidance for the deployment in an access
network. We therefore recommend to keep them.
</Sven>

> P18& 19 - Section 4.4.3, 4.4.4 - .6
> 
> Here we're actually duplicating a protocol requirement as an access node
> requirement. Again, all of this section appears to be redundant as far
> as the protocol is concerned. If there any protocol requirements, as I
> seem to read in sect 4.4.4, then I think we should turn them into such
> as opposed to node requirements. 
> Also the use of the term "link" doesn't quite square up to the
> terminology.

<Sven>
Section 4.4.3, 4.4.4 should be reworded to protocol requirements.

Section 4.4.5 is a bit trickier, since it links the port identification
schemes used by an Access Node amongst a number of protocols. This is an
Access Node specific requirement in my mind.

In secion 4.4.6, the first requirement is not a protocol requirement.
The second one (message bundling) is, and can be moved to the protocol
section.
</Sven>

> Eg 
> Current req: The Access Node MUST support an adjacency protocol used to
>       synchronize states across the link, discover the identity of the
>       entity at the other end of a link, and detect when it changes.
> 
> Protocol req: The protocol MUST allow the discovery by each end point
> the identity of the other end point.
> The protocol MUST include a mechanism for synchronising protocol state
> information between two end-points.
> Etc.
> 
> P19 - Section 4.4.7
> 
> Again, these are not protocol requirements, at least in their current
> form. What *may* be a protocol requirement is actually informing a
> controller which issued a command for the change of a setting that is
> not administratively allowed, i.e. an appropriate error message.

<Sven>
We suggest to keep section 4.4.7 in its current form. Next to this, we
should discuss about the potential protocol requirement you indicated.
</Sven>

> P20 - section 4.5
> 
> Not protocol requirements in their current form - if that some of these
> that may have a relation be turned into protocol requirements. The only
> one I'm able to see as a potential protocol requirement is the one for
> having peer authorization. If we want a node to communicate to only
> "authorized nodes" then we need a mechanism for determining such
> authorization, or simply assume that the direct configuration of a peer
> is sufficient for that peer to be authorized.
> 
> The above comment applies to all subsequent sub-sections of 4.5

<Sven>
We suggest to review the section and update where appropriate to reflect
protocol requirements, and at the same time keep the non-protocol
requirements that are important for the framework.
</Sven>

> P27 - Section 7
> 
> Again, these are node functional not protocol requirements.

<Sven>
Agreed, but we also feel they should be kept since they guide in
deploying the protocol in the framework/architecture.
</Sven>

> Hope that the above provides some useful input.
> 
> Cheers,
> Woj.
> 
> 
> -----Original Message-----
> From: Sven.Ooghe@alcatel.be [mailto:Sven.Ooghe@alcatel.be] 
> Sent: 13 October 2006 15:59
> To: internet-drafts@ietf.org
> Cc: Sanjay Wadhwa; Haag, T; michel.platnic@ecitele.com; Voigt Norbert;
> Matthew Bocci; Wojciech Dec (wdec)
> Subject: draft-ieft-ancp-framework-00.txt
> 
> Please find below an I-D titled "Framework and Requirements for an
> Access Node Control Mechanism in Broadband Multi-Service Networks".
> 
> This draft is based on draft-ooghe-ancp-framework-00.txt, which was
> accepted by the ANCP community to be moved to a Working Group document. 
> It also reflects a few changes/additions resulting from the latest DSL
> Forum meeting where this topic was discussed.
> 
> Best regards,
> Sven Ooghe
> 
> 
> 
> 
> _______________________________________________
> ANCP mailing list
> ANCP@ietf.org
> https://www1.ietf.org/mailman/listinfo/ancp
> 



_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Tue Nov 07 20:13:08 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ghbzz-00077W-Vu; Tue, 07 Nov 2006 20:13:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghbzy-00076n-RV
	for ancp@ietf.org; Tue, 07 Nov 2006 20:13:02 -0500
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhVZP-0001JO-SY
	for ancp@ietf.org; Tue, 07 Nov 2006 13:21:11 -0500
Received: from smail.alcatel.fr ([62.23.212.165])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GhVZJ-0006dC-GH
	for ancp@ietf.org; Tue, 07 Nov 2006 13:21:06 -0500
Received: from gbmail02.netfr.alcatel.fr (gbmail02.netfr.alcatel.fr
	[155.132.251.26])
	by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kA7IL7x6001752
	for <ancp@ietf.org>; Tue, 7 Nov 2006 19:21:08 +0100
To: ancp@ietf.org
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
Message-ID: <OFF0642D71.C2234670-ON8025721F.0064AB39-8025721F.0064C497@netfr.alcatel.fr>
From: Matthew.Bocci@alcatel.co.uk
Date: Tue, 7 Nov 2006 18:20:39 +0000
X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 |
	June 23, 2005) at 11/07/2006 18:21:03
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81
X-Spam-Score: 0.2 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Subject: [ANCP] Slides for ANCP meeting
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

All presenters,

Please can you send me your slides for the ANCP meeting on Thursday as soon
as possible. These need to be made available before the meeting.

Regards,

Matthew




_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Thu Nov 09 18:24:46 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GiJFy-00063F-B1; Thu, 09 Nov 2006 18:24:26 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJFw-000635-Vx
	for ancp@ietf.org; Thu, 09 Nov 2006 18:24:24 -0500
Received: from smail.alcatel.fr ([62.23.212.165])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiJFv-0004tq-JP
	for ancp@ietf.org; Thu, 09 Nov 2006 18:24:24 -0500
Received: from gbmail02.netfr.alcatel.fr (gbmail02.netfr.alcatel.fr
	[155.132.251.26])
	by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kA9NOQfK031476
	for <ancp@ietf.org>; Fri, 10 Nov 2006 00:24:26 +0100
To: ancp@ietf.org
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
Message-ID: <OF69D4CBAB.A3EA7177-ON80257221.00800D34-80257221.008073C8@netfr.alcatel.fr>
From: Matthew.Bocci@alcatel.co.uk
Date: Thu, 9 Nov 2006 23:23:02 +0000
X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 |
	June 23, 2005) at 11/09/2006 23:24:21
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Subject: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG ID?
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

During the ANCP meeting in San Diego we asked whether the ANCP Security
Threats Analysis draft (draft-moustafa-ancp-security-threats-00.txt) should
become a working group ID.

Please review the draft and post comments to the list, also indicating
whether or not you support this draft becoming a working group ID.

Regards,

Matthew






_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Thu Nov 09 18:27:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GiJIW-0006bG-QU; Thu, 09 Nov 2006 18:27:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJIV-0006bB-On
	for ancp@ietf.org; Thu, 09 Nov 2006 18:27:03 -0500
Received: from smail.alcatel.fr ([62.23.212.165])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiJIU-0005B0-CX
	for ancp@ietf.org; Thu, 09 Nov 2006 18:27:03 -0500
Received: from gbmail02.netfr.alcatel.fr (gbmail02.netfr.alcatel.fr
	[155.132.251.26])
	by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kA9NR5Wg032353
	for <ancp@ietf.org>; Fri, 10 Nov 2006 00:27:05 +0100
To: ancp@ietf.org
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
Message-ID: <OF4D991D2E.7439BFA4-ON80257221.0080756F-80257221.0080CCA9@netfr.alcatel.fr>
From: Matthew.Bocci@alcatel.co.uk
Date: Thu, 9 Nov 2006 23:26:50 +0000
X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 |
	June 23, 2005) at 11/09/2006 23:27:00
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Subject: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

During the ANCP meeting in San Diego we asked whether the ANCP protocol
draft (draft-wadhwa-gsmp-l2control-configuration-02.txt ) should become a
working group ID.

Please indicate to the list whether or not you support this draft becoming
a working group ID.

Regards,

Matthew





_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Thu Nov 09 19:26:40 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GiKE4-0000V4-2t; Thu, 09 Nov 2006 19:26:32 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GiKE2-0000Us-Hq
	for ancp@ietf.org; Thu, 09 Nov 2006 19:26:30 -0500
Received: from tcmail31.telekom.de ([217.6.95.238])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiKE1-00056N-56
	for ancp@ietf.org; Thu, 09 Nov 2006 19:26:30 -0500
Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.telekom.de with ESMTP;
	Fri, 10 Nov 2006 01:26:21 +0100
Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by
	S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 10 Nov 2006 01:26:21 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: AW: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
Date: Fri, 10 Nov 2006 01:28:47 +0100
Message-Id: <6439282641581441A36F7F6F83ED2ED2014A831E@S4DE8PSAAFQ.mitte.t-com.de>
in-reply-to: <OF4D991D2E.7439BFA4-ON80257221.0080756F-80257221.0080CCA9@netfr.alcatel.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
Thread-Index: AccEVp5VvsRLADC8SO2sRHk1L5uUVAACCAQw
From: "Haag, T" <Thomas.Haag@t-systems.com>
To: <Matthew.Bocci@alcatel.co.uk>,
    <ancp@ietf.org>
X-OriginalArrivalTime: 10 Nov 2006 00:26:21.0430 (UTC)
	FILETIME=[D8D01160:01C7045E]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: 
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

All,

I will support becoming ANCP protocol draft =
(draft-wadhwa-gsmp-l2control-configuration-02.txt) a working group ID.

Regards
Thomas

-----Urspr=FCngliche Nachricht-----
Von: Matthew.Bocci@alcatel.co.uk [mailto:Matthew.Bocci@alcatel.co.uk]=20
Gesendet: Freitag, 10. November 2006 00:27
An: ancp@ietf.org
Betreff: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG =
ID?

During the ANCP meeting in San Diego we asked whether the should become.

Please indicate to the list whether or not you support this draft =
becoming
a working group ID.

Regards,

Matthew





_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Thu Nov 09 20:55:47 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GiLcE-0007a5-W2; Thu, 09 Nov 2006 20:55:34 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GiLDo-0002rC-BK
	for ancp@ietf.org; Thu, 09 Nov 2006 20:30:20 -0500
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiLDn-0004SQ-02
	for ancp@ietf.org; Thu, 09 Nov 2006 20:30:20 -0500
Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by
	ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 10 Nov 2006 02:30:13 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 10 Nov 2006 02:30:13 +0100
Message-ID: <BAF83494CE653943A97B9F755016A0660435DFF1@ftrdmel1.rd.francetelecom.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Security Requirements Draft
Thread-Index: AccEZ8KRY0W77cUZRRWysMO1HVp1Zg==
From: "MOUSTAFA Hassnaa RD-CORE-ISS" <hassnaa.moustafa@orange-ftgroup.com>
To: <ancp@ietf.org>
X-OriginalArrivalTime: 10 Nov 2006 01:30:13.0202 (UTC)
	FILETIME=[C4BA1320:01C70467]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
X-Mailman-Approved-At: Thu, 09 Nov 2006 20:55:34 -0500
Subject: [ANCP] Security Requirements Draft
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0351982602=="
Errors-To: ancp-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0351982602==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C70467.C6B4BFEE"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C70467.C6B4BFEE
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,
Thanks for all the useful comments got during the ANCP session.
I will be so thankful to receive any notes on these comments, which
would help us progress the draft.
=20
Regards,
=20
Hassnaa

------_=_NextPart_001_01C70467.C6B4BFEE
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D179152801-10112006>Hi=20
all,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D179152801-10112006>Thanks =
for all the=20
useful comments got during the ANCP session.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D179152801-10112006>I will =
be so=20
thankful to receive any notes on these comments, which would help us =
progress=20
the draft.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D179152801-10112006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D179152801-10112006>Regards,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D179152801-10112006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D179152801-10112006>Hassnaa</SPAN></FONT></DIV>
<DIV>
<DIV align=3Dleft><STRONG></STRONG></DIV></DIV></BODY></HTML>

------_=_NextPart_001_01C70467.C6B4BFEE--


--===============0351982602==
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://www1.ietf.org/mailman/listinfo/ancp

--===============0351982602==--




From ancp-bounces@ietf.org Fri Nov 10 05:01:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GiTBu-0004nT-90; Fri, 10 Nov 2006 05:00:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GiTBs-0004nO-Jt
	for ancp@ietf.org; Fri, 10 Nov 2006 05:00:52 -0500
Received: from ug-out-1314.google.com ([66.249.92.168])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiTBq-0005hH-AG
	for ancp@ietf.org; Fri, 10 Nov 2006 05:00:52 -0500
Received: by ug-out-1314.google.com with SMTP id 72so427799ugd
	for <ancp@ietf.org>; Fri, 10 Nov 2006 02:00:47 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:mime-version:content-type;
	b=bvwQnNqxiJftLqHwj9g+nMA7we9JhtrDQgPBUilx1qWfvdT3/hqWR3MGuZ8EiQdF6YjX+DsB5HZBo0KTHdRycDr/bYL2pZKF8tYXAIhH/I7HgbN+MeoIgBpM4IBOgqaCcx0U/S/RKNs5l3XmHAn4q3c0MdC02RVnekHm6sGltus=
Received: by 10.67.92.1 with SMTP id u1mr3096167ugl.1163152847495;
	Fri, 10 Nov 2006 02:00:47 -0800 (PST)
Received: by 10.67.19.4 with HTTP; Fri, 10 Nov 2006 02:00:47 -0800 (PST)
Message-ID: <dea40f930611100200pc6bd7a5v2d7374770f080637@mail.gmail.com>
Date: Fri, 10 Nov 2006 11:00:47 +0100
From: "Hasnaa Moustafa" <hasnaa.moustafa@gmail.com>
To: ancp@ietf.org
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Subject: [ANCP] ANCP Security Requirements Draft
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1856557866=="
Errors-To: ancp-bounces@ietf.org

--===============1856557866==
Content-Type: multipart/alternative; 
	boundary="----=_Part_63105_6900046.1163152847398"

------=_Part_63105_6900046.1163152847398
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi all,
Thanks for all the useful comments got during the ANCP session.
I will be so thankful to receive any notes on these comments, which would
help us progress the draft.

Regards,

Hassnaa

------=_Part_63105_6900046.1163152847398
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div><font face="Arial" size="2"><span class="179152801-10112006">Hi all,</span></font></div>
<div><font face="Arial" size="2"><span class="179152801-10112006">Thanks for all the useful comments got during the ANCP session.</span></font></div>
<div><font face="Arial" size="2"><span class="179152801-10112006">I will be so thankful to receive any notes on these comments, which would help us progress the draft.</span></font></div>
<div><font face="Arial" size="2"><span class="179152801-10112006"></span></font>&nbsp;</div>
<div><font face="Arial" size="2"><span class="179152801-10112006">Regards,</span></font></div>
<div><font face="Arial" size="2"><span class="179152801-10112006"></span></font>&nbsp;</div>
<div><font face="Arial" size="2"><span class="179152801-10112006">Hassnaa</span></font></div>

------=_Part_63105_6900046.1163152847398--


--===============1856557866==
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://www1.ietf.org/mailman/listinfo/ancp

--===============1856557866==--




From ancp-bounces@ietf.org Mon Nov 13 08:02:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GjbRR-0004pe-Du; Mon, 13 Nov 2006 08:01:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GjbRP-0004om-NP
	for ancp@ietf.org; Mon, 13 Nov 2006 08:01:35 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjbRJ-0006Qs-7y
	for ancp@ietf.org; Mon, 13 Nov 2006 08:01:35 -0500
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E26D8C7B; 
	Mon, 13 Nov 2006 14:00:40 +0100 (CET)
Received: from esealmw104.eemea.ericsson.se ([153.88.200.67]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 13 Nov 2006 14:00:40 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 13 Nov 2006 14:00:39 +0100
Message-ID: <2DEB3E4E9BC3774B8EEF2EF2BE9F745B5CCBD7@esealmw104.eemea.ericsson.se>
In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2803B75CEA@proton.jnpr.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: ANCP draft: BRAS behaviour
thread-index: AcbzhMJgBE0iq0G/SGuEkEfjo49BUwAm+72wAGNwNIAEXNRm4A==
From: "Kim Hyldgaard \(ST/LMD\)" <kim.hyldgaard@ericsson.com>
To: "Sanjay Wadhwa" <swadhwa@juniper.net>, <wdec@cisco.com>, <ancp@ietf.org>
X-OriginalArrivalTime: 13 Nov 2006 13:00:40.0510 (UTC)
	FILETIME=[B890DDE0:01C70723]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: 
Subject: [ANCP] ANCP draft: BRAS behaviour
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

Hi all,

This is an open question on BRAS behaviour in ANCP scenarios.

I think at least the first topic was discussed in the spring,
but I don't remember if there were any conclusions.
- If so, please enlighten me.


1)
If a DSL line is removed from a DSLAM, the draft states that
the DSLAM should send a port DOWN message to the BRAS.

But in this case the line is actually more than DOWN; it is
completely removed from the system.

How will the BRAS learn that this is no longer a valid line?
Is it removed by some kind of aging timer?
I think a special line state value was discussed to signal this,
but I guess it was never included?

Or... Should the line be removed from the BRAS?


2)
How does the BRAS handle fallback from PTM to ATM?

Will a BRAS see that the ACI is acutally pointing to the same line,
eventhough the ACI differs in "eth" and "atm" + the VPI/VCI or VLAN ID?

I think the draft is a bit vague on this point, but maybe I
just haven't found the section specifying this.


I'd appreciate some comments from anybody with knowledge of
BRAS and ANCP behaviour.

Thanks in advance.

Kind regards
Kim Hyldgaard

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Mon Nov 13 09:44:58 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gjd3H-0000La-Gd; Mon, 13 Nov 2006 09:44:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjd3G-0000LR-9B
	for ancp@ietf.org; Mon, 13 Nov 2006 09:44:46 -0500
Received: from borg.juniper.net ([207.17.137.119])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjd3E-0004lI-0E
	for ancp@ietf.org; Mon, 13 Nov 2006 09:44:46 -0500
Received: from unknown (HELO emailfeemea2.jnpr.net) ([172.26.192.142])
	by borg.juniper.net with ESMTP; 13 Nov 2006 06:41:48 -0800
X-IronPort-AV: i="4.09,417,1157353200"; 
	d="scan'208"; a="618877687:sNHT41730792"
Received: from emailemea5.jnpr.net ([172.26.192.134]) by emailfeemea2.jnpr.net
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 13 Nov 2006 14:44:42 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
Date: Mon, 13 Nov 2006 14:44:41 -0000
Message-ID: <D78E5D40FCF6BB4F97B9CC7E11006A8503C8B27D@emailemea5.jnpr.net>
In-Reply-To: <OF4D991D2E.7439BFA4-ON80257221.0080756F-80257221.0080CCA9@netfr.alcatel.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
Thread-Index: AccEVqFazK0J2BofR/mR+ZFPy4E+UAC23Ujg
From: "Derek Harkness" <dharkness@juniper.net>
To: <ancp@ietf.org>
X-OriginalArrivalTime: 13 Nov 2006 14:44:42.0171 (UTC)
	FILETIME=[40E2C0B0:01C70732]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

=20
> Please indicate to the list whether or not you support this draft
becoming a working group ID.

I support this draft becoming a working group ID

D.

+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D+
Derek Harkness
Systems Engineer
Juniper Networks=20
Nymphenburger Strasse 13-15
80335 Munich
Germany
Tel: +49 89 5529 4916
Mobile: +49 172 843 6621
Email: DHarkness@juniper.net
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D+=20


-----Original Message-----
From: Matthew.Bocci@alcatel.co.uk [mailto:Matthew.Bocci@alcatel.co.uk]=20
Sent: 10 November 2006 00:27
To: ancp@ietf.org
Subject: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG
ID?

During the ANCP meeting in San Diego we asked whether the ANCP protocol
draft (draft-wadhwa-gsmp-l2control-configuration-02.txt ) should become
a
working group ID.

Please indicate to the list whether or not you support this draft
becoming
a working group ID.

Regards,

Matthew





_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Mon Nov 13 10:08:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GjdQN-0006AG-3K; Mon, 13 Nov 2006 10:08:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GjdQL-00067s-UG
	for ancp@ietf.org; Mon, 13 Nov 2006 10:08:37 -0500
Received: from borg.juniper.net ([207.17.137.119])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjdQK-0007aM-LD
	for ancp@ietf.org; Mon, 13 Nov 2006 10:08:37 -0500
Received: from unknown (HELO pi-smtp.jnpr.net) ([10.10.2.36])
	by borg.juniper.net with ESMTP; 13 Nov 2006 07:05:41 -0800
X-IronPort-AV: i="4.09,418,1157353200"; 
	d="scan'208"; a="618889232:sNHT57647236"
Received: from emailwf1.jnpr.net ([10.10.2.33]) by pi-smtp.jnpr.net with
	Microsoft SMTPSVC(5.0.2195.6713); Mon, 13 Nov 2006 10:08:35 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
Date: Mon, 13 Nov 2006 10:08:35 -0500
Message-ID: <3525C9833C09ED418C6FD6CD9514668C5384B3@emailwf1.jnpr.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
Thread-Index: AccEVqFazK0J2BofR/mR+ZFPy4E+UAC23UjgAADd6OA=
From: "Jerome Moisand" <jmoisand@juniper.net>
To: <ancp@ietf.org>
X-OriginalArrivalTime: 13 Nov 2006 15:08:35.0586 (UTC)
	FILETIME=[97448620:01C70735]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

Ditto.

-----Original Message-----
From: Derek Harkness=20
Sent: Monday, November 13, 2006 9:45 AM
To: ancp@ietf.org
Subject: RE: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to
WG ID?

=20
> Please indicate to the list whether or not you support this draft
becoming a working group ID.

I support this draft becoming a working group ID

D.

+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D+
Derek Harkness
Systems Engineer
Juniper Networks=20
Nymphenburger Strasse 13-15
80335 Munich
Germany
Tel: +49 89 5529 4916
Mobile: +49 172 843 6621
Email: DHarkness@juniper.net
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D+=20


-----Original Message-----
From: Matthew.Bocci@alcatel.co.uk [mailto:Matthew.Bocci@alcatel.co.uk]=20
Sent: 10 November 2006 00:27
To: ancp@ietf.org
Subject: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG
ID?

During the ANCP meeting in San Diego we asked whether the ANCP protocol
draft (draft-wadhwa-gsmp-l2control-configuration-02.txt ) should become
a
working group ID.

Please indicate to the list whether or not you support this draft
becoming
a working group ID.

Regards,

Matthew





_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Mon Nov 13 10:10:58 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GjdSY-0007nG-2D; Mon, 13 Nov 2006 10:10:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GjdSW-0007n6-Mj
	for ancp@ietf.org; Mon, 13 Nov 2006 10:10:52 -0500
Received: from smail.alcatel.fr ([62.23.212.165])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjdSV-0007pH-91
	for ancp@ietf.org; Mon, 13 Nov 2006 10:10:52 -0500
Received: from bemail01.netfr.alcatel.fr (bemail01.netfr.alcatel.fr
	[155.132.251.32])
	by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kADFAs3J030936
	for <ancp@ietf.org>; Mon, 13 Nov 2006 16:10:54 +0100
Received: from [172.31.148.94] ([172.31.148.94])
	by bemail01.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163)
	with ESMTP id 2006111316104780:7833 ;
	Mon, 13 Nov 2006 16:10:47 +0100 
Message-ID: <45588AF8.4000309@alcatel.be>
Date: Mon, 13 Nov 2006 16:10:48 +0100
From: Sven.Ooghe@alcatel.be
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ancp@ietf.org
Subject: Re: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
References: <OF4D991D2E.7439BFA4-ON80257221.0080756F-80257221.0080CCA9@netfr.alcatel.fr>
In-Reply-To: <OF4D991D2E.7439BFA4-ON80257221.0080756F-80257221.0080CCA9@netfr.alcatel.fr>
X-MIMETrack: Itemize by SMTP Server on BEMAIL01/BE/ALCATEL(Release
	5.0.13aHF163 | June 23, 2005) at 11/13/2006 16:10:47,
	Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 | June
	23, 2005) at 11/13/2006 16:10:49,
	Serialize complete at 11/13/2006 16:10:49
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81
X-Spam-Score: 0.2 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

I support this draft becoming a WG ID.

Regards,
Sven

Matthew.Bocci@alcatel.co.uk wrote:
> During the ANCP meeting in San Diego we asked whether the ANCP protocol
> draft (draft-wadhwa-gsmp-l2control-configuration-02.txt ) should become a
> working group ID.
> 
> Please indicate to the list whether or not you support this draft becoming
> a working group ID.
> 
> Regards,
> 
> Matthew
> 
> 
> 
> 
> 
> _______________________________________________
> ANCP mailing list
> ANCP@ietf.org
> https://www1.ietf.org/mailman/listinfo/ancp
> 

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Mon Nov 13 10:11:17 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GjdSv-00081t-0Y; Mon, 13 Nov 2006 10:11:17 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GjdSt-00081V-RX
	for ancp@ietf.org; Mon, 13 Nov 2006 10:11:15 -0500
Received: from smail.alcatel.fr ([62.23.212.165])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjdSs-0007rT-C5
	for ancp@ietf.org; Mon, 13 Nov 2006 10:11:15 -0500
Received: from bemail01.netfr.alcatel.fr (bemail01.netfr.alcatel.fr
	[155.132.251.32])
	by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kADFBHuG031125
	for <ancp@ietf.org>; Mon, 13 Nov 2006 16:11:18 +0100
Received: from [172.31.148.94] ([172.31.148.94])
	by bemail01.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163)
	with ESMTP id 2006111316111094:7843 ;
	Mon, 13 Nov 2006 16:11:10 +0100 
Message-ID: <45588B0F.3090608@alcatel.be>
Date: Mon, 13 Nov 2006 16:11:11 +0100
From: Sven.Ooghe@alcatel.be
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ancp@ietf.org
Subject: Re: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG ID?
References: <OF69D4CBAB.A3EA7177-ON80257221.00800D34-80257221.008073C8@netfr.alcatel.fr>
In-Reply-To: <OF69D4CBAB.A3EA7177-ON80257221.00800D34-80257221.008073C8@netfr.alcatel.fr>
X-MIMETrack: Itemize by SMTP Server on BEMAIL01/BE/ALCATEL(Release
	5.0.13aHF163 | June 23, 2005) at 11/13/2006 16:11:11,
	Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 | June
	23, 2005) at 11/13/2006 16:11:12,
	Serialize complete at 11/13/2006 16:11:12
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

I support this draft becoming a WG ID.

Matthew.Bocci@alcatel.co.uk wrote:

> During the ANCP meeting in San Diego we asked whether the ANCP Security
> Threats Analysis draft (draft-moustafa-ancp-security-threats-00.txt) should
> become a working group ID.
> 
> Please review the draft and post comments to the list, also indicating
> whether or not you support this draft becoming a working group ID.
> 
> Regards,
> 
> Matthew
> 
> 
> 
> 
> 
> 
> _______________________________________________
> ANCP mailing list
> ANCP@ietf.org
> https://www1.ietf.org/mailman/listinfo/ancp
> 

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Mon Nov 13 10:24:57 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gjdg5-00076Q-Ax; Mon, 13 Nov 2006 10:24:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjdg3-00073z-Qh
	for ancp@ietf.org; Mon, 13 Nov 2006 10:24:51 -0500
Received: from kecgate02.infosysconsulting.com ([61.95.162.76]
	helo=Kecgate02.infosys.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjdg0-0000zR-Tl
	for ancp@ietf.org; Mon, 13 Nov 2006 10:24:51 -0500
Received: from indhubbhs03.ad.infosys.com ([192.168.200.83]) by
	Kecgate02.infosys.com with InterScan Messaging Security Suite;
	Mon, 13 Nov 2006 20:48:56 +0530
Received: from BLRKECMSG14.ad.infosys.com ([172.22.147.6]) by
	indhubbhs03.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 13 Nov 2006 20:52:40 +0530
Received: from BLRKECMSG01.ad.infosys.com ([172.25.213.131]) by
	BLRKECMSG14.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 13 Nov 2006 20:52:40 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
Date: Mon, 13 Nov 2006 20:51:40 +0530
Message-ID: <0CA51D55A5DC42479FEBFBCEB7D5F183D44BF8@BLRKECMSG01.ad.infosys.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
Thread-Index: AccEVqFazK0J2BofR/mR+ZFPy4E+UAC23UjgAADd6OAAAHcvqA==
References: <3525C9833C09ED418C6FD6CD9514668C5384B3@emailwf1.jnpr.net>
From: "pavan_kurapati" <pavan_kurapati@infosys.com>
To: <ancp@ietf.org>
X-OriginalArrivalTime: 13 Nov 2006 15:22:40.0616 (UTC)
	FILETIME=[8EF1DE80:01C70737]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org


I support this draft to become a WG ID.

--Pavan


-----Original Message-----
From: Jerome Moisand [mailto:jmoisand@juniper.net]
Sent: Mon 11/13/2006 8:38 PM
To: ancp@ietf.org
Subject: RE: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG=
 ID?
=0D
Ditto.

-----Original Message-----
From: Derek Harkness=0D
Sent: Monday, November 13, 2006 9:45 AM
To: ancp@ietf.org
Subject: RE: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to
WG ID?

=0D
> Please indicate to the list whether or not you support this draft
becoming a working group ID.

I support this draft becoming a working group ID

D.

+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D+
Derek Harkness
Systems Engineer
Juniper Networks=0D
Nymphenburger Strasse 13-15
80335 Munich
Germany
Tel: +49 89 5529 4916
Mobile: +49 172 843 6621
Email: DHarkness@juniper.net
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D+=0D


-----Original Message-----
From: Matthew.Bocci@alcatel.co.uk [mailto:Matthew.Bocci@alcatel.co.uk]=0D
Sent: 10 November 2006 00:27
To: ancp@ietf.org
Subject: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG
ID?

During the ANCP meeting in San Diego we asked whether the ANCP protocol
draft (draft-wadhwa-gsmp-l2control-configuration-02.txt ) should become
a
working group ID.

Please indicate to the list whether or not you support this draft
becoming
a working group ID.

Regards,

Matthew





_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended=
 solely for the use of the addressee(s). If you are not the intended=
 recipient, please notify the sender by e-mail and delete the original=
 message. Further, you are not to copy, disclose, or distribute this e-mail=
 or its contents to any other person and any such actions are unlawful.=
 This e-mail may contain viruses. Infosys has taken every reasonable=
 precaution to minimize this risk, but is not liable for any damage you may=
 sustain as a result of any virus in this e-mail. You should carry out your=
 own virus checks before opening the e-mail or attachment. Infosys reserves=
 the right to monitor and review the content of all messages sent to or=
 from this e-mail address. Messages sent to or from this e-mail address may=
 be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Mon Nov 13 11:42:35 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GjetC-0002rP-F2; Mon, 13 Nov 2006 11:42:30 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GjetB-0002rC-BP
	for ancp@ietf.org; Mon, 13 Nov 2006 11:42:29 -0500
Received: from smail.alcatel.fr ([62.23.212.165])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjet5-00044g-Jl
	for ancp@ietf.org; Mon, 13 Nov 2006 11:42:29 -0500
Received: from bemail06.netfr.alcatel.fr (bemail06.netfr.alcatel.fr
	[155.132.251.30])
	by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kADGgQYU007250
	for <ancp@ietf.org>; Mon, 13 Nov 2006 17:42:26 +0100
Received: from [138.203.254.46] ([138.203.254.46])
	by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163)
	with ESMTP id 2006111317421993:5133 ;
	Mon, 13 Nov 2006 17:42:19 +0100 
Message-ID: <4558A06A.5010702@alcatel.be>
Date: Mon, 13 Nov 2006 17:42:18 +0100
From: stefaan.de_cnodder@alcatel.be
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ancp@ietf.org
Subject: Re: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
References: <OF4D991D2E.7439BFA4-ON80257221.0080756F-80257221.0080CCA9@netfr.alcatel.fr>
In-Reply-To: <OF4D991D2E.7439BFA4-ON80257221.0080756F-80257221.0080CCA9@netfr.alcatel.fr>
X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release
	5.0.13aHF163 | June 23, 2005) at 11/13/2006 17:42:21,
	Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June
	23, 2005) at 11/13/2006 17:42:21,
	Serialize complete at 11/13/2006 17:42:21
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org


Hi, I have some comments on
draft-wadhwa-gsmp-l2control-configuration-02.txt:

(1) Introduction says that the document extends GSMPv3.  This is not
really true because it is actually defining GSMPv3.1 and not just
extending GSMPv3.  This is an important difference since the header
format from v3 to v3.1 is changed.  I have not gone through all the
differences from RFC3292 to the original draft of Avri Doria that was
supposed to update RFC3292 because if that draft does not exist anymore,
the difference should be documented in this draft.  Will the draft of
Avri not be continued anymore?

(2) Section 3 and most part of section 4 are duplicate from the
framework document.  Once it was said to limit this draft to just the
protocol but when looking to the diffs of version 01 and version 02 of
this draft, these changes are not made.  According to me it would be
much better to remove most of it, in particular for use case 2 (line
config) and use case 4 (multicast), since the draft is not making any
protocol extensions for these use cases.  If it is kept, we will have to
check for the consistency, at the least this doc is using the old
terminology.

(3) Section 4.3.2. When PPP is up, the BRAS configs the DSLAM with for
instance a new DSL profile (in figure 4 it is even made explicit that it
is a new profile).  This will cause the line to resync and the PPP will
go down and come up again, but then the scenario repeats itself.  This
will cause a never ending loop, or at least 2 times the PPP to be set
up.  Is the config supposed to be maintained after a resync and after a
reboot? Since the config data is associated with the PPP session, the
config should be deleted when the PPP session disappears but with this
we are going to get nowhere.  The text and message flows should be
further completed with a second cycle of DSL loss, DSL signal, Port UP,
PPP/DHCP session, AAA, and also step 5 again (line config).  In this
case the DSLAM sees that the profiles matches and does not do anything
more.  This to show the complete scenario.

This also relates somehow to the comment from Kim Hyldgaard earlier: is
a down port the same as a non existing port?  The BRAS can configure the
port when it is created (but still down) such that the DSL line syncs
from the first time with the correct profile.  In which state is the
DSLAM supposed to remove the configured state by the BRAS?  Not in case
it goes from Up to Down or from Down to Up, because then the above
scenario is in an endless loop.  But then what about the IDLE and SILENT
states?

But since this is use case 2 (line config) for which the draft has no
protocol extensions, it looks better to me to remove at least this from
the draft, and it has to be cleared out in the drafts describing
particular extensions.  Might it be possible that some configs have to
be kept after a resync while others not?  There is also no method to go
to the default state again: suppose I remove my PPP session and then
authenticate with another ISP, then clearly the previous state has to be
removed and fall back to default.  Suppose that ISP1 wants to configure
profile 1 and ISP2 does not specify a profile, is the DSL line then
using profile 1 while authenticated with ISP2, or should the DSLAM then
use a default profile that it expects to be good and stable (e.g., large
maximum bandwidth, large noise margin, ...)?  If the PPP session
disappears, the BRAS should "clean up" the port back to default (the PPP
session is gone, so also the config from the Radius server), but then we
are again in the never ending loop in case of DSL profile configuration....

Another issue is how the BRAS knows the configured profile or any other
configured data.  Because according to section 5.4.3, unknown TLVs are
silently ignored.  So this triggers 2 questions:

- if one TLV can be executed, but a second TLV not for some reason, is
the first TLV executed, i.e. is this one transaction, or 2 transactions?
  The draft seems to suggest that it is 1 transaction.

- if one TLV can be executed, but the second TLV is unknown and ignored,
is then the first TLV executed?  Here the draft is not clear: what does
ignoring the unknown TLV means?

Would it not be better that TLVs are executed if possible, one by one,
and then the response is sent to the BRAS one by one, i.e., it is not 1
failure or success for the whole message, but rather a failure/success
per TLV.

(4) The bulk message is a new message and apparently also a single
transaction.  What does this mean?  All messages included must succeed
or no message at all is executed?  The text seems to suggest this in the
second paragraph and also last paragraph when describing the response to
the bulk message.  Would it not be better that the bulk message itself
has no response, but that the individual messages have a response, which
might be (but not necessarily) grouped again in a bulk message (possibly
with other new messages).

(5) section 5.4.2 contains a wrong reference to [4] which should be
section 5.4.2.1

(6) The error codes in section 5.4.4 are confusing.  Suppose the DSLAM
have multiple reasons for why the test fails, e.g., the test time out
(error 0x501) while the loop is in show time (error 0x503)? or since a
multiple loopbacks are sent, suppose some loopbacks fail because the
line is down (idle/silent), some loopback fails because the line is
training (error 0x506), and then there are some successful loopbacks.

What should be the value of the result field in this case? And what
should be the error code? I would expect that the result is only
successful if all loopbacks are successful, but you can also say for
instance that if when a predefined number is successful, the test is
successful.  But then there is still the problem with the error codes
(and it is a SHOULD requirement, so better to define it more precisely).
  Since the training state is a rather short state, it is likely that
there is no single state of the line during the whole loopback test.
Would it therefore not be better to remove at least the "training"
state?  It also does not give much information: the line is down, and
that is all what matters.

What does "DSL line integrity error" mean?  Can this be defined more
accurately?  This looks something that can change every second so just
like with the training state, it makes no sense to have such an error
code.  If you request for 5 loopbacks, and 3 are successfull and 2 fail,
you know the line has some problems (bit errors, ...) so this looks
redundant information that can create confusion.

Also definitions for idle and silent has to be added because it is not
clear from the draft what the difference is.

hope these comments help.  If all included in the next version, then I
will be happy to see it as a working group document!

regards,
Stefaan




Matthew.Bocci@alcatel.co.uk wrote:
> During the ANCP meeting in San Diego we asked whether the ANCP protocol
> draft (draft-wadhwa-gsmp-l2control-configuration-02.txt ) should become a
> working group ID.
> 
> Please indicate to the list whether or not you support this draft becoming
> a working group ID.
> 
> Regards,
> 
> Matthew
> 
> 
> 
> 
> 
> _______________________________________________
> ANCP mailing list
> ANCP@ietf.org
> https://www1.ietf.org/mailman/listinfo/ancp

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Mon Nov 13 11:45:16 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gjevi-00054v-GR; Mon, 13 Nov 2006 11:45:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjevg-00051S-N2
	for ancp@ietf.org; Mon, 13 Nov 2006 11:45:04 -0500
Received: from smail.alcatel.fr ([62.23.212.165])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjeva-0004NT-8D
	for ancp@ietf.org; Mon, 13 Nov 2006 11:45:04 -0500
Received: from bemail06.netfr.alcatel.fr (bemail06.netfr.alcatel.fr
	[155.132.251.30])
	by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kADGj184008229
	for <ancp@ietf.org>; Mon, 13 Nov 2006 17:45:01 +0100
Received: from [138.203.254.46] ([138.203.254.46])
	by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163)
	with ESMTP id 2006111317445534:5148 ;
	Mon, 13 Nov 2006 17:44:55 +0100 
Message-ID: <4558A106.9020202@alcatel.be>
Date: Mon, 13 Nov 2006 17:44:54 +0100
From: stefaan.de_cnodder@alcatel.be
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ancp@ietf.org
Subject: Re: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG ID?
References: <OF69D4CBAB.A3EA7177-ON80257221.00800D34-80257221.008073C8@netfr.alcatel.fr>
In-Reply-To: <OF69D4CBAB.A3EA7177-ON80257221.00800D34-80257221.008073C8@netfr.alcatel.fr>
X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release
	5.0.13aHF163 | June 23, 2005) at 11/13/2006 17:44:55,
	Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June
	23, 2005) at 11/13/2006 17:44:56,
	Serialize complete at 11/13/2006 17:44:56
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org


Yes for a WG draft.

regards,
Stefaan

Matthew.Bocci@alcatel.co.uk wrote:

> During the ANCP meeting in San Diego we asked whether the ANCP Security
> Threats Analysis draft (draft-moustafa-ancp-security-threats-00.txt) should
> become a working group ID.
> 
> Please review the draft and post comments to the list, also indicating
> whether or not you support this draft becoming a working group ID.
> 
> Regards,
> 
> Matthew
> 
> 
> 
> 
> 
> 
> _______________________________________________
> ANCP mailing list
> ANCP@ietf.org
> https://www1.ietf.org/mailman/listinfo/ancp

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Tue Nov 14 00:42:34 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gjr3x-0005l4-P2; Tue, 14 Nov 2006 00:42:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjr3u-0005Zh-QI
	for ancp@ietf.org; Tue, 14 Nov 2006 00:42:22 -0500
Received: from prattle.redback.com ([155.53.12.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjr2X-0005GS-88
	for ancp@ietf.org; Tue, 14 Nov 2006 00:40:58 -0500
Received: from localhost (localhost [127.0.0.1])
	by prattle.redback.com (Postfix) with ESMTP id 7B833518F04;
	Mon, 13 Nov 2006 21:40:56 -0800 (PST)
Received: from prattle.redback.com ([127.0.0.1])
	by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
	id 15972-07; Mon, 13 Nov 2006 21:40:56 -0800 (PST)
Received: from PARBETM2XP2 (unknown [172.31.253.36])
	by prattle.redback.com (Postfix) with ESMTP id F199B518F01;
	Mon, 13 Nov 2006 21:40:55 -0800 (PST)
From: "Peter Arberg" <parberg@redback.com>
To: "'Kim Hyldgaard (ST/LMD)'" <kim.hyldgaard@ericsson.com>,
	"'Sanjay Wadhwa'" <swadhwa@juniper.net>, <wdec@cisco.com>, <ancp@ietf.org>
Subject: RE: [ANCP] ANCP draft: BRAS behaviour
Date: Mon, 13 Nov 2006 21:44:08 -0800
Organization: Redback Networks Inc.
Message-ID: <008c01c707af$e7a3c750$0a01a8c0@ad.redback.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcbzhMJgBE0iq0G/SGuEkEfjo49BUwAm+72wAGNwNIAEXNRm4AAiEUfg
In-Reply-To: <2DEB3E4E9BC3774B8EEF2EF2BE9F745B5CCBD7@esealmw104.eemea.ericsson.se>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Virus-Scanned: by amavisd-new at redback.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Cc: 
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: parberg@redback.com
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

Hi Kim, 

some comments and answers inline.


> -----Original Message-----
> From: Kim Hyldgaard (ST/LMD) [mailto:kim.hyldgaard@ericsson.com] 
> Sent: 13. november 2006 05:01
> To: Sanjay Wadhwa; wdec@cisco.com; ancp@ietf.org
> Subject: [ANCP] ANCP draft: BRAS behaviour
> 
> Hi all,
> 
> This is an open question on BRAS behaviour in ANCP scenarios.
> 
> I think at least the first topic was discussed in the spring,
> but I don't remember if there were any conclusions.
> - If so, please enlighten me.

I don't think we ever reached any conclusion..

 
> 1)
> If a DSL line is removed from a DSLAM, the draft states that
> the DSLAM should send a port DOWN message to the BRAS.
> 
> But in this case the line is actually more than DOWN; it is
> completely removed from the system.
> 
> How will the BRAS learn that this is no longer a valid line?
> Is it removed by some kind of aging timer?

The BRAS today have no way of learning that a line have been 
deleted from the AN.

There is no aging timer that I'm aware of, the only way I think
you would be able to remove a line from the BRAS is manual 
intervention, and do a "line delete" on the BRAS if such a functionality
is implemented on the BRAS.


> I think a special line state value was discussed to signal this,
> but I guess it was never included?

Yes as far as I remember we did discuss the need to implement and
use a gsmp dead port message, which would be a simple way for the
AN to signal the BRAS to remove a specific ACI from its port database.

But as far as I remember we also at the same time discussed the need
to make a version control of the protocol, so we could move forward
with some of these enhancements without breaking backwards compatibility.

I think it is time to get started with this, and I would like to
make an initial draft of this if people agree on the usability.

As such I think it might be a mistake to keep the gsmp version as 3.1
for ANCP, I would much rather like to see it start at another version
once we reach concensus on the draft, and then everything prior to
this draft is running on the version 3.1.


> Or... Should the line be removed from the BRAS?
> 
> 
> 2)
> How does the BRAS handle fallback from PTM to ATM?
> 
> Will a BRAS see that the ACI is acutally pointing to the same line,
> eventhough the ACI differs in "eth" and "atm" + the VPI/VCI 
> or VLAN ID?

No the BRAS is not suppose to parse the ACI, it is a string
identifier.

What will happen is that the BRAS will get a new port ACI entry in
its port database, and the old one will sit there until it is 
manually deleted (or we create the dead port message :)


> I think the draft is a bit vague on this point, but maybe I
> just haven't found the section specifying this.

I have not seen it either, but I think we should add it, but
in my mind it goes hand in hand with the dead port and the version 
control.

cheers,
Peter


> I'd appreciate some comments from anybody with knowledge of
> BRAS and ANCP behaviour.
> 
> Thanks in advance.
> 
> Kind regards
> Kim Hyldgaard
> 
> _______________________________________________
> ANCP mailing list
> ANCP@ietf.org
> https://www1.ietf.org/mailman/listinfo/ancp
> 



_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Tue Nov 14 00:45:22 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gjr6j-0007IZ-R2; Tue, 14 Nov 2006 00:45:17 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjr6i-0007IT-LR
	for ancp@ietf.org; Tue, 14 Nov 2006 00:45:16 -0500
Received: from prattle.redback.com ([155.53.12.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjr6h-0006lv-C7
	for ancp@ietf.org; Tue, 14 Nov 2006 00:45:16 -0500
Received: from localhost (localhost [127.0.0.1])
	by prattle.redback.com (Postfix) with ESMTP id 040F8102527;
	Mon, 13 Nov 2006 21:45:15 -0800 (PST)
Received: from prattle.redback.com ([127.0.0.1])
	by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
	id 16343-04; Mon, 13 Nov 2006 21:45:14 -0800 (PST)
Received: from PARBETM2XP2 (unknown [172.31.253.36])
	by prattle.redback.com (Postfix) with ESMTP id A74A1102526;
	Mon, 13 Nov 2006 21:45:14 -0800 (PST)
From: "Peter Arberg" <parberg@redback.com>
To: <Matthew.Bocci@alcatel.co.uk>, <ancp@ietf.org>
Subject: RE: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
Date: Mon, 13 Nov 2006 21:48:27 -0800
Organization: Redback Networks Inc.
Message-ID: <008d01c707b0$82073f20$0a01a8c0@ad.redback.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AccEVpzv705shEdbQBeHlynCuV53OADWajNA
In-Reply-To: <OF4D991D2E.7439BFA4-ON80257221.0080756F-80257221.0080CCA9@netfr.alcatel.fr>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Virus-Scanned: by amavisd-new at redback.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: 
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: parberg@redback.com
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

I support this as a WG draft. I take it we can keep expanding
the content as long as the WG agree to suggested additions
or deletions ?

cheers,
Peter

> -----Original Message-----
> From: Matthew.Bocci@alcatel.co.uk 
> [mailto:Matthew.Bocci@alcatel.co.uk] 
> Sent: 9. november 2006 15:27
> To: ancp@ietf.org
> Subject: [ANCP] 
> draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
> 
> During the ANCP meeting in San Diego we asked whether the 
> ANCP protocol
> draft (draft-wadhwa-gsmp-l2control-configuration-02.txt ) 
> should become a
> working group ID.
> 
> Please indicate to the list whether or not you support this 
> draft becoming
> a working group ID.
> 
> Regards,
> 
> Matthew
> 
> 
> 
> 
> 
> _______________________________________________
> ANCP mailing list
> ANCP@ietf.org
> https://www1.ietf.org/mailman/listinfo/ancp
> 



_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Tue Nov 14 01:09:28 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GjrU3-00017r-UG; Tue, 14 Nov 2006 01:09:23 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GjrU2-00013C-TV
	for ancp@ietf.org; Tue, 14 Nov 2006 01:09:22 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjrTt-0001Fs-7K
	for ancp@ietf.org; Tue, 14 Nov 2006 01:09:22 -0500
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2E86A4CA; 
	Tue, 14 Nov 2006 07:09:00 +0100 (CET)
Received: from esealmw104.eemea.ericsson.se ([153.88.200.67]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 14 Nov 2006 07:09:00 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [ANCP] ANCP draft: BRAS behaviour
Date: Tue, 14 Nov 2006 07:08:59 +0100
Message-ID: <2DEB3E4E9BC3774B8EEF2EF2BE9F745B5ECFE8@esealmw104.eemea.ericsson.se>
In-Reply-To: <008c01c707af$e7a3c750$0a01a8c0@ad.redback.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [ANCP] ANCP draft: BRAS behaviour
thread-index: AcbzhMJgBE0iq0G/SGuEkEfjo49BUwAm+72wAGNwNIAEXNRm4AAiEUfgAAImx6A=
From: "Kim Hyldgaard \(ST/LMD\)" <kim.hyldgaard@ericsson.com>
To: <parberg@redback.com>, "Sanjay Wadhwa" <swadhwa@juniper.net>,
	<wdec@cisco.com>, <ancp@ietf.org>
X-OriginalArrivalTime: 14 Nov 2006 06:09:00.0328 (UTC)
	FILETIME=[6085F280:01C707B3]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365
Cc: 
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

Hi Peter,

Thanks for your answers.

>>I think it is time to get started with this, and I would like to
>>make an initial draft of this if people agree on the usability.

I agree that we need ANCP to handle the situations, and I think it
would be very good with an initial draft on the topic, in order for
us to have something as a basis for further discussions.

Br
Kim


-----Original Message-----
From: Peter Arberg [mailto:parberg@redback.com]=20
Sent: 14. november 2006 06:44
To: Kim Hyldgaard (ST/LMD); 'Sanjay Wadhwa'; wdec@cisco.com;
ancp@ietf.org
Subject: RE: [ANCP] ANCP draft: BRAS behaviour

Hi Kim,=20

some comments and answers inline.


> -----Original Message-----
> From: Kim Hyldgaard (ST/LMD) [mailto:kim.hyldgaard@ericsson.com]
> Sent: 13. november 2006 05:01
> To: Sanjay Wadhwa; wdec@cisco.com; ancp@ietf.org
> Subject: [ANCP] ANCP draft: BRAS behaviour
>=20
> Hi all,
>=20
> This is an open question on BRAS behaviour in ANCP scenarios.
>=20
> I think at least the first topic was discussed in the spring, but I=20
> don't remember if there were any conclusions.
> - If so, please enlighten me.

I don't think we ever reached any conclusion..

=20
> 1)
> If a DSL line is removed from a DSLAM, the draft states that the DSLAM

> should send a port DOWN message to the BRAS.
>=20
> But in this case the line is actually more than DOWN; it is completely

> removed from the system.
>=20
> How will the BRAS learn that this is no longer a valid line?
> Is it removed by some kind of aging timer?

The BRAS today have no way of learning that a line have been deleted
from the AN.

There is no aging timer that I'm aware of, the only way I think you
would be able to remove a line from the BRAS is manual intervention, and
do a "line delete" on the BRAS if such a functionality is implemented on
the BRAS.


> I think a special line state value was discussed to signal this,
> but I guess it was never included?

Yes as far as I remember we did discuss the need to implement and
use a gsmp dead port message, which would be a simple way for the
AN to signal the BRAS to remove a specific ACI from its port database.

But as far as I remember we also at the same time discussed the need
to make a version control of the protocol, so we could move forward
with some of these enhancements without breaking backwards
compatibility.

I think it is time to get started with this, and I would like to
make an initial draft of this if people agree on the usability.

As such I think it might be a mistake to keep the gsmp version as 3.1
for ANCP, I would much rather like to see it start at another version
once we reach concensus on the draft, and then everything prior to
this draft is running on the version 3.1.


> Or... Should the line be removed from the BRAS?
>=20
>=20
> 2)
> How does the BRAS handle fallback from PTM to ATM?
>=20
> Will a BRAS see that the ACI is acutally pointing to the same line,
> eventhough the ACI differs in "eth" and "atm" + the VPI/VCI=20
> or VLAN ID?

No the BRAS is not suppose to parse the ACI, it is a string
identifier.

What will happen is that the BRAS will get a new port ACI entry in
its port database, and the old one will sit there until it is=20
manually deleted (or we create the dead port message :)


> I think the draft is a bit vague on this point, but maybe I
> just haven't found the section specifying this.

I have not seen it either, but I think we should add it, but
in my mind it goes hand in hand with the dead port and the version=20
control.

cheers,
Peter


> I'd appreciate some comments from anybody with knowledge of
> BRAS and ANCP behaviour.
>=20
> Thanks in advance.
>=20
> Kind regards
> Kim Hyldgaard
>=20
> _______________________________________________
> ANCP mailing list
> ANCP@ietf.org
> https://www1.ietf.org/mailman/listinfo/ancp
>=20



_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Tue Nov 14 03:16:51 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GjtTL-0000jf-4X; Tue, 14 Nov 2006 03:16:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GjtTJ-0000jV-Ts
	for ancp@ietf.org; Tue, 14 Nov 2006 03:16:45 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjtTD-0002r2-Fp
	for ancp@ietf.org; Tue, 14 Nov 2006 03:16:45 -0500
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3EA1CE3D; 
	Tue, 14 Nov 2006 09:15:51 +0100 (CET)
Received: from esealmw104.eemea.ericsson.se ([153.88.200.67]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 14 Nov 2006 09:15:51 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG ID?
Date: Tue, 14 Nov 2006 09:15:50 +0100
Message-ID: <2DEB3E4E9BC3774B8EEF2EF2BE9F745B5ED371@esealmw104.eemea.ericsson.se>
In-Reply-To: <OF69D4CBAB.A3EA7177-ON80257221.00800D34-80257221.008073C8@netfr.alcatel.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG ID?
thread-index: AccEVkM8wzMHVvkaRV22q7/PBFyzvgDbrA+A
From: "Kim Hyldgaard \(ST/LMD\)" <kim.hyldgaard@ericsson.com>
To: <Matthew.Bocci@alcatel.co.uk>,
	<ancp@ietf.org>
X-OriginalArrivalTime: 14 Nov 2006 08:15:51.0145 (UTC)
	FILETIME=[18EC7590:01C707C5]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: 
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

Hi,

I support this draft becomming a WG ID.

Br
Kim
=20

-----Original Message-----
From: Matthew.Bocci@alcatel.co.uk [mailto:Matthew.Bocci@alcatel.co.uk]=20
Sent: 10. november 2006 00:23
To: ancp@ietf.org
Subject: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG ID?

During the ANCP meeting in San Diego we asked whether the ANCP Security
Threats Analysis draft (draft-moustafa-ancp-security-threats-00.txt)
should become a working group ID.

Please review the draft and post comments to the list, also indicating
whether or not you support this draft becoming a working group ID.

Regards,

Matthew






_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Tue Nov 14 03:20:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GjtXH-0002h9-Cn; Tue, 14 Nov 2006 03:20:51 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GjtXG-0002h0-47
	for ancp@ietf.org; Tue, 14 Nov 2006 03:20:50 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjtXD-0003TX-P4
	for ancp@ietf.org; Tue, 14 Nov 2006 03:20:50 -0500
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5F63EE47; 
	Tue, 14 Nov 2006 09:20:44 +0100 (CET)
Received: from esealmw104.eemea.ericsson.se ([153.88.200.67]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 14 Nov 2006 09:20:44 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
Date: Tue, 14 Nov 2006 09:20:43 +0100
Message-ID: <2DEB3E4E9BC3774B8EEF2EF2BE9F745B5ED3B1@esealmw104.eemea.ericsson.se>
In-Reply-To: <008d01c707b0$82073f20$0a01a8c0@ad.redback.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
thread-index: AccEVpzv705shEdbQBeHlynCuV53OADWajNAAAU3TZA=
From: "Kim Hyldgaard \(ST/LMD\)" <kim.hyldgaard@ericsson.com>
To: <Matthew.Bocci@alcatel.co.uk>,
	<ancp@ietf.org>
X-OriginalArrivalTime: 14 Nov 2006 08:20:44.0173 (UTC)
	FILETIME=[C794FBD0:01C707C5]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: 
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

Hi,

I support this draft becomming a WG ID.

- I have the same assumption as stated by Peter
below: That we can expand the content as long as
the WG agree to suggested additions or deletions.

Br
Kim
=20

-----Original Message-----
From: Peter Arberg [mailto:parberg@redback.com]=20
Sent: 14. november 2006 06:48
To: Matthew.Bocci@alcatel.co.uk; ancp@ietf.org
Subject: RE: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to
WG ID?

I support this as a WG draft. I take it we can keep expanding the
content as long as the WG agree to suggested additions or deletions ?

cheers,
Peter

> -----Original Message-----
> From: Matthew.Bocci@alcatel.co.uk
> [mailto:Matthew.Bocci@alcatel.co.uk]
> Sent: 9. november 2006 15:27
> To: ancp@ietf.org
> Subject: [ANCP]
> draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
>=20
> During the ANCP meeting in San Diego we asked whether the ANCP=20
> protocol draft (draft-wadhwa-gsmp-l2control-configuration-02.txt )=20
> should become a working group ID.
>=20
> Please indicate to the list whether or not you support this draft=20
> becoming a working group ID.
>=20
> Regards,
>=20
> Matthew
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> ANCP mailing list
> ANCP@ietf.org
> https://www1.ietf.org/mailman/listinfo/ancp
>=20



_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Tue Nov 14 04:16:02 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GjuOO-0007ud-4x; Tue, 14 Nov 2006 04:15:44 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GjuON-0007uL-93
	for ancp@ietf.org; Tue, 14 Nov 2006 04:15:43 -0500
Received: from kecgate06.infosys.com ([61.95.162.82])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjuOL-0002Pq-C1
	for ancp@ietf.org; Tue, 14 Nov 2006 04:15:43 -0500
Received: from indhubbhs04.ad.infosys.com ([192.168.200.84]) by
	Kecgate06.infosys.com with InterScan Messaging Security Suite;
	Tue, 14 Nov 2006 14:38:45 +0530
Received: from BLRKECMSG04.ad.infosys.com ([172.25.213.136]) by
	indhubbhs04.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 14 Nov 2006 14:43:42 +0530
Received: from BLRKECMSG01.ad.infosys.com ([172.25.213.131]) by
	BLRKECMSG04.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 14 Nov 2006 14:43:42 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 14 Nov 2006 14:43:42 +0530
Message-ID: <0CA51D55A5DC42479FEBFBCEB7D5F183D44BFB@BLRKECMSG01.ad.infosys.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-moustafa-ancp-security-threats-00.txt 
Thread-Index: AccEVgu3eg4pUX9pQkaCYtqvrfz0KgDZwaIW
References: <OF69D4CBAB.A3EA7177-ON80257221.00800D34-80257221.008073C8@netfr.alcatel.fr>
From: "pavan_kurapati" <pavan_kurapati@infosys.com>
To: <ancp@ietf.org>
X-OriginalArrivalTime: 14 Nov 2006 09:13:42.0472 (UTC)
	FILETIME=[2DFEEC80:01C707CD]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Subject: [ANCP] draft-moustafa-ancp-security-threats-00.txt 
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org


Hi,
I have following comments on this draft.

1. Introduction: "Prevention again Impersonation". Change it to  'against'

2. Section 4 : The last bullet points of the 2 sections point to same=
 thing. i.e changing QoS settings for gaining profit. What is the=
 difference?

3. Section 5 seems to have lot of repeated information. For eg., 5.6=
 Man-in-the-Middle is discussed in previous sections as well (like DoS=
 attack section). Also, 5.7 Network snooping is very similar to traffic=
 analysis section. Both can be merged.

4.  6.1 one of the attacks mentions "man-in-the-middle attack causing=
 access loop configuration data retrieval from the policy server by an=
 illegitimate NAS". I see this as a security consideration between policy=
 server and NAS. In the begininning of this section it was mentioned that=
 this is out of scope and is not discussed. Just a minor comment on=
 consistency

5. 6.2 Access loop Configuration :
first bullet point says that an onpath adversary on AN can change the=
 access loop configuration. I would not see it as a ANCP threat. If there=
 is an onpath adversay 'on' AN, the AN itself is compromised. So he would=
 not wait for ANCP to change the access loop configuration isn't it?

6. I am not sure how a DSL user can be 'on path' adversary. I assume 'on=
 path' adversary as someone residing between NAS and AN (As defined in=
 section 3). Bullet 4 of section 6.2 says that an on path adversary  can=
 configure his "own" profile with some other privileged client's profile. I=
 think it is possible only by someone  sitting between AN and NAS . He does=
 not have a user profile of his own. More explanation is required as to how=
 it can be possible?

7. 6.4 also talks about modifying parameters to adversary benefit. I do not=
 think an onpath adversary can do something for his own benefit. I see a=
 DSL user as an off path adversary who can do certain limited things w.r.to=
 loopback tests etc. How can he change profiles of his own or someone else=
 using ANCP?=0D


Pavan Kumar Kurapati=0D
Infosys Technologies Ltd,
Bangalore




_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp







**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended=
 solely for the use of the addressee(s). If you are not the intended=
 recipient, please notify the sender by e-mail and delete the original=
 message. Further, you are not to copy, disclose, or distribute this e-mail=
 or its contents to any other person and any such actions are unlawful.=
 This e-mail may contain viruses. Infosys has taken every reasonable=
 precaution to minimize this risk, but is not liable for any damage you may=
 sustain as a result of any virus in this e-mail. You should carry out your=
 own virus checks before opening the e-mail or attachment. Infosys reserves=
 the right to monitor and review the content of all messages sent to or=
 from this e-mail address. Messages sent to or from this e-mail address may=
 be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Tue Nov 14 04:40:39 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GjumR-0003SW-8t; Tue, 14 Nov 2006 04:40:35 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GjuZG-0004DW-HX
	for ancp@ietf.org; Tue, 14 Nov 2006 04:26:58 -0500
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjuZE-0003uH-5I
	for ancp@ietf.org; Tue, 14 Nov 2006 04:26:58 -0500
Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by
	ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 14 Nov 2006 10:26:36 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG ID?
Date: Tue, 14 Nov 2006 10:26:39 +0100
Message-ID: <BBBE5BAA3B351C488C415EA662EA884003C795AA@FTRDMEL2.rd.francetelecom.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG ID?
Thread-Index: AccEVkNdwcB2Q7tuTAWirSVE53cL8wDeJRhA
From: "NIGER Philippe RD-RESA-LAN" <philippe.niger@orange-ftgroup.com>
To: <ancp@ietf.org>
X-OriginalArrivalTime: 14 Nov 2006 09:26:36.0986 (UTC)
	FILETIME=[FBA461A0:01C707CE]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
X-Mailman-Approved-At: Tue, 14 Nov 2006 04:40:34 -0500
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

I support this draft becoming a WG ID.

Regards,

Philippe

-----Original Message-----
From: Matthew.Bocci@alcatel.co.uk [mailto:Matthew.Bocci@alcatel.co.uk]=20
Sent: vendredi 10 novembre 2006 00:23
To: ancp@ietf.org
Subject: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG ID?


During the ANCP meeting in San Diego we asked whether the ANCP Security
Threats Analysis draft (draft-moustafa-ancp-security-threats-00.txt)
should become a working group ID.

Please review the draft and post comments to the list, also indicating
whether or not you support this draft becoming a working group ID.

Regards,

Matthew






_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Tue Nov 14 07:22:39 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GjxJC-0004gp-UW; Tue, 14 Nov 2006 07:22:34 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GjxJC-0004g0-19
	for ancp@ietf.org; Tue, 14 Nov 2006 07:22:34 -0500
Received: from gecko.sbs.de ([194.138.37.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjxJ6-0002JJ-DM
	for ancp@ietf.org; Tue, 14 Nov 2006 07:22:34 -0500
Received: from mail2.sbs.de (localhost [127.0.0.1])
	by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id kAECMRDK007618
	for <ancp@ietf.org>; Tue, 14 Nov 2006 13:22:27 +0100
Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net
	[157.163.133.222])
	by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id kAECMQLR030784
	for <ancp@ietf.org>; Tue, 14 Nov 2006 13:22:26 +0100
Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by
	fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 14 Nov 2006 13:22:26 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: Re: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG ID?
Date: Tue, 14 Nov 2006 13:22:25 +0100
Message-ID: <D720D1DD80557241B9452630315560C3014CDEE2@MCHP7IEA.ww002.siemens.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Re: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG ID?
Thread-Index: AccH54spCI68CRS2RpubY8T0L34FwA==
From: "Shanmugam, Murugaraj" <murugaraj.shanmugam@siemens.com>
To: <ancp@ietf.org>
X-OriginalArrivalTime: 14 Nov 2006 12:22:26.0147 (UTC)
	FILETIME=[8B6E9B30:01C707E7]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0232071907=="
Errors-To: ancp-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0232071907==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C707E7.8B2C2D20"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C707E7.8B2C2D20
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hi,

I support this ID to become a WG document

Ciao,
Raj.

------_=_NextPart_001_01C707E7.8B2C2D20
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7651.12">
<TITLE>Re: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG =
ID?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I support this ID to become a WG =
document</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Ciao,</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Raj.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C707E7.8B2C2D20--


--===============0232071907==
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://www1.ietf.org/mailman/listinfo/ancp

--===============0232071907==--




From ancp-bounces@ietf.org Tue Nov 14 08:09:39 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gjy2G-0004Ef-Dv; Tue, 14 Nov 2006 08:09:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjy2E-0004EV-QB
	for ancp@ietf.org; Tue, 14 Nov 2006 08:09:06 -0500
Received: from thoth.sbs.de ([192.35.17.2])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjy2D-0007jo-C8
	for ancp@ietf.org; Tue, 14 Nov 2006 08:09:06 -0500
Received: from mail3.siemens.de (localhost [127.0.0.1])
	by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id kAED92Xg004835;
	Tue, 14 Nov 2006 14:09:02 +0100
Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net
	[139.25.131.193])
	by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id kAED8xX1027688;
	Tue, 14 Nov 2006 14:09:02 +0100
Received: from MCHP7RCA.ww002.siemens.net ([139.25.131.170]) by
	mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 14 Nov 2006 14:09:00 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
Date: Tue, 14 Nov 2006 14:08:44 +0100
Message-ID: <B4AB8706B31D6943B60D8D04DEFAE5D2E1A107@MCHP7RCA.ww002.siemens.net>
In-Reply-To: <OF4D991D2E.7439BFA4-ON80257221.0080756F-80257221.0080CCA9@netfr.alcatel.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
Thread-Index: AccEVp1C2aIBR2TNQ+yX0IumTf06EQDl0QpQ
From: "Voigt, Norbert" <norbert.voigt@siemens.com>
To: <Matthew.Bocci@alcatel.co.uk>, <ancp@ietf.org>
X-OriginalArrivalTime: 14 Nov 2006 13:09:00.0502 (UTC)
	FILETIME=[0CFF5760:01C707EE]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: 
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

I support this draft becomming a WG ID.
Regards,
Norbert=20

-----Original Message-----
From: Matthew.Bocci@alcatel.co.uk [mailto:Matthew.Bocci@alcatel.co.uk]=20
Sent: Freitag, 10. November 2006 00:27
To: ancp@ietf.org
Subject: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG
ID?

During the ANCP meeting in San Diego we asked whether the ANCP protocol
draft (draft-wadhwa-gsmp-l2control-configuration-02.txt ) should become
a
working group ID.

Please indicate to the list whether or not you support this draft
becoming
a working group ID.

Regards,

Matthew





_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Tue Nov 14 08:10:20 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gjy3P-0004Qw-VY; Tue, 14 Nov 2006 08:10:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjy3O-0004QK-7z
	for ancp@ietf.org; Tue, 14 Nov 2006 08:10:18 -0500
Received: from thoth.sbs.de ([192.35.17.2])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjy3A-00084O-9c
	for ancp@ietf.org; Tue, 14 Nov 2006 08:10:18 -0500
Received: from mail2.siemens.de (localhost [127.0.0.1])
	by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id kAEDA1uN006065;
	Tue, 14 Nov 2006 14:10:01 +0100
Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net
	[139.25.131.193])
	by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id kAEDA0sj020048;
	Tue, 14 Nov 2006 14:10:01 +0100
Received: from MCHP7RCA.ww002.siemens.net ([139.25.131.170]) by
	mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 14 Nov 2006 14:10:01 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG ID?
Date: Tue, 14 Nov 2006 14:09:53 +0100
Message-ID: <B4AB8706B31D6943B60D8D04DEFAE5D2E1A10B@MCHP7RCA.ww002.siemens.net>
In-Reply-To: <OF69D4CBAB.A3EA7177-ON80257221.00800D34-80257221.008073C8@netfr.alcatel.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG ID?
Thread-Index: AccEVkbJbHbE89PoRNmZb0DBOagNTADl9OyA
From: "Voigt, Norbert" <norbert.voigt@siemens.com>
To: <Matthew.Bocci@alcatel.co.uk>, <ancp@ietf.org>
X-OriginalArrivalTime: 14 Nov 2006 13:10:01.0081 (UTC)
	FILETIME=[311AF690:01C707EE]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: 
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

I support this draft becomming a WG ID.
Regards,
Norbert.
=20

-----Original Message-----
From: Matthew.Bocci@alcatel.co.uk [mailto:Matthew.Bocci@alcatel.co.uk]=20
Sent: Freitag, 10. November 2006 00:23
To: ancp@ietf.org
Subject: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG ID?

During the ANCP meeting in San Diego we asked whether the ANCP Security
Threats Analysis draft (draft-moustafa-ancp-security-threats-00.txt)
should
become a working group ID.

Please review the draft and post comments to the list, also indicating
whether or not you support this draft becoming a working group ID.

Regards,

Matthew






_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Tue Nov 14 11:07:39 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gk0ox-0002o3-M7; Tue, 14 Nov 2006 11:07:35 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0ou-0002fY-Kp
	for ancp@ietf.org; Tue, 14 Nov 2006 11:07:32 -0500
Received: from wip-ec-wd.wipro.com ([203.91.193.32])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0lu-0008Lb-OS
	for ancp@ietf.org; Tue, 14 Nov 2006 11:04:28 -0500
Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1])
	by localhost (Postfix) with ESMTP id CD0F820B41
	for <ancp@ietf.org>; Tue, 14 Nov 2006 21:28:32 +0530 (IST)
Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92])
	by wip-ec-wd.wipro.com (Postfix) with ESMTP id B69A120AFB
	for <ancp@ietf.org>; Tue, 14 Nov 2006 21:28:32 +0530 (IST)
Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-ec-bh02.wipro.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 14 Nov 2006 21:34:13 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
Date: Tue, 14 Nov 2006 21:34:14 +0530
Message-ID: <0140B5C49461E34686783F667D9E4A539BCFD9@blr-k1-msg.wipro.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
Thread-Index: AccEVsqcEW51OSrOT1eo822uqiOPmwDr7LQg
From: <sathiya.narayanan@wipro.com>
To: <Matthew.Bocci@alcatel.co.uk>,
	<ancp@ietf.org>
X-OriginalArrivalTime: 14 Nov 2006 16:04:13.0285 (UTC)
	FILETIME=[871AB950:01C70806]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: 
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

I support this becoming a WG ID.

Rgds,
Sathiya=20

-----Original Message-----
From: Matthew.Bocci@alcatel.co.uk [mailto:Matthew.Bocci@alcatel.co.uk]=20
Sent: Friday, November 10, 2006 4:57 AM
To: ancp@ietf.org
Subject: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG
ID?

During the ANCP meeting in San Diego we asked whether the ANCP protocol
draft (draft-wadhwa-gsmp-l2control-configuration-02.txt ) should become
a working group ID.

Please indicate to the list whether or not you support this draft
becoming a working group ID.

Regards,

Matthew





_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Tue Nov 14 11:07:39 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gk0ox-0002nl-Ap; Tue, 14 Nov 2006 11:07:35 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0ou-0002fY-Hn
	for ancp@ietf.org; Tue, 14 Nov 2006 11:07:32 -0500
Received: from wip-ec-wd.wipro.com ([203.91.193.32])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0m2-0008ND-4r
	for ancp@ietf.org; Tue, 14 Nov 2006 11:04:35 -0500
Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1])
	by localhost (Postfix) with ESMTP id E47C820AE1
	for <ancp@ietf.org>; Tue, 14 Nov 2006 21:28:51 +0530 (IST)
Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91])
	by wip-ec-wd.wipro.com (Postfix) with ESMTP id 3396B20B61
	for <ancp@ietf.org>; Tue, 14 Nov 2006 21:28:51 +0530 (IST)
Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-ec-bh01.wipro.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 14 Nov 2006 21:34:31 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG ID?
Date: Tue, 14 Nov 2006 21:34:33 +0530
Message-ID: <0140B5C49461E34686783F667D9E4A539BCFDA@blr-k1-msg.wipro.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG ID?
Thread-Index: AccEVkUToVBp3CBeS2CEcYksQRlH2wDsEiEg
From: <sathiya.narayanan@wipro.com>
To: <Matthew.Bocci@alcatel.co.uk>,
	<ancp@ietf.org>
X-OriginalArrivalTime: 14 Nov 2006 16:04:31.0552 (UTC)
	FILETIME=[91FE0C00:01C70806]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: 
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

I support this becoming a WG ID.=20

-----Original Message-----
From: Matthew.Bocci@alcatel.co.uk [mailto:Matthew.Bocci@alcatel.co.uk]=20
Sent: Friday, November 10, 2006 4:53 AM
To: ancp@ietf.org
Subject: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG ID?

During the ANCP meeting in San Diego we asked whether the ANCP Security
Threats Analysis draft (draft-moustafa-ancp-security-threats-00.txt)
should become a working group ID.

Please review the draft and post comments to the list, also indicating
whether or not you support this draft becoming a working group ID.

Regards,

Matthew






_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Tue Nov 14 11:07:39 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gk0ox-0002o3-M7; Tue, 14 Nov 2006 11:07:35 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0ou-0002fY-Kp
	for ancp@ietf.org; Tue, 14 Nov 2006 11:07:32 -0500
Received: from wip-ec-wd.wipro.com ([203.91.193.32])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0lu-0008Lb-OS
	for ancp@ietf.org; Tue, 14 Nov 2006 11:04:28 -0500
Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1])
	by localhost (Postfix) with ESMTP id CD0F820B41
	for <ancp@ietf.org>; Tue, 14 Nov 2006 21:28:32 +0530 (IST)
Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92])
	by wip-ec-wd.wipro.com (Postfix) with ESMTP id B69A120AFB
	for <ancp@ietf.org>; Tue, 14 Nov 2006 21:28:32 +0530 (IST)
Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-ec-bh02.wipro.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 14 Nov 2006 21:34:13 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
Date: Tue, 14 Nov 2006 21:34:14 +0530
Message-ID: <0140B5C49461E34686783F667D9E4A539BCFD9@blr-k1-msg.wipro.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
Thread-Index: AccEVsqcEW51OSrOT1eo822uqiOPmwDr7LQg
From: <sathiya.narayanan@wipro.com>
To: <Matthew.Bocci@alcatel.co.uk>,
	<ancp@ietf.org>
X-OriginalArrivalTime: 14 Nov 2006 16:04:13.0285 (UTC)
	FILETIME=[871AB950:01C70806]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: 
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

I support this becoming a WG ID.

Rgds,
Sathiya=20

-----Original Message-----
From: Matthew.Bocci@alcatel.co.uk [mailto:Matthew.Bocci@alcatel.co.uk]=20
Sent: Friday, November 10, 2006 4:57 AM
To: ancp@ietf.org
Subject: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG
ID?

During the ANCP meeting in San Diego we asked whether the ANCP protocol
draft (draft-wadhwa-gsmp-l2control-configuration-02.txt ) should become
a working group ID.

Please indicate to the list whether or not you support this draft
becoming a working group ID.

Regards,

Matthew





_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Tue Nov 14 11:07:39 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gk0ox-0002nl-Ap; Tue, 14 Nov 2006 11:07:35 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0ou-0002fY-Hn
	for ancp@ietf.org; Tue, 14 Nov 2006 11:07:32 -0500
Received: from wip-ec-wd.wipro.com ([203.91.193.32])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0m2-0008ND-4r
	for ancp@ietf.org; Tue, 14 Nov 2006 11:04:35 -0500
Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1])
	by localhost (Postfix) with ESMTP id E47C820AE1
	for <ancp@ietf.org>; Tue, 14 Nov 2006 21:28:51 +0530 (IST)
Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91])
	by wip-ec-wd.wipro.com (Postfix) with ESMTP id 3396B20B61
	for <ancp@ietf.org>; Tue, 14 Nov 2006 21:28:51 +0530 (IST)
Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-ec-bh01.wipro.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 14 Nov 2006 21:34:31 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG ID?
Date: Tue, 14 Nov 2006 21:34:33 +0530
Message-ID: <0140B5C49461E34686783F667D9E4A539BCFDA@blr-k1-msg.wipro.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG ID?
Thread-Index: AccEVkUToVBp3CBeS2CEcYksQRlH2wDsEiEg
From: <sathiya.narayanan@wipro.com>
To: <Matthew.Bocci@alcatel.co.uk>,
	<ancp@ietf.org>
X-OriginalArrivalTime: 14 Nov 2006 16:04:31.0552 (UTC)
	FILETIME=[91FE0C00:01C70806]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: 
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

I support this becoming a WG ID.=20

-----Original Message-----
From: Matthew.Bocci@alcatel.co.uk [mailto:Matthew.Bocci@alcatel.co.uk]=20
Sent: Friday, November 10, 2006 4:53 AM
To: ancp@ietf.org
Subject: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG ID?

During the ANCP meeting in San Diego we asked whether the ANCP Security
Threats Analysis draft (draft-moustafa-ancp-security-threats-00.txt)
should become a working group ID.

Please review the draft and post comments to the list, also indicating
whether or not you support this draft becoming a working group ID.

Regards,

Matthew






_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Wed Nov 15 05:46:58 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GkII3-0007Xb-I8; Wed, 15 Nov 2006 05:46:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GkII2-0007XR-AG
	for ancp@ietf.org; Wed, 15 Nov 2006 05:46:46 -0500
Received: from prattle.redback.com ([155.53.12.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkD4C-00082I-IN
	for ancp@ietf.org; Wed, 15 Nov 2006 00:12:09 -0500
Received: from localhost (localhost [127.0.0.1])
	by prattle.redback.com (Postfix) with ESMTP id BA4A66ABED9;
	Tue, 14 Nov 2006 21:12:07 -0800 (PST)
Received: from prattle.redback.com ([127.0.0.1])
	by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
	id 21883-05; Tue, 14 Nov 2006 21:12:07 -0800 (PST)
Received: from PARBETM2XP2 (unknown [172.31.253.17])
	by prattle.redback.com (Postfix) with ESMTP id 939486ABED7;
	Tue, 14 Nov 2006 21:12:06 -0800 (PST)
From: "Peter Arberg" <parberg@redback.com>
To: <Matthew.Bocci@alcatel.co.uk>, <ancp@ietf.org>
Subject: RE: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG ID?
Date: Tue, 14 Nov 2006 21:15:02 -0800
Organization: Redback Networks Inc.
Message-ID: <00b101c70875$05933dc0$f934bace@ad.redback.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
In-Reply-To: <OF69D4CBAB.A3EA7177-ON80257221.00800D34-80257221.008073C8@netfr.alcatel.fr>
thread-index: AccEVkQgbPoJ2NLVR6qCkAHxkpRmagEHrhEQ
X-Virus-Scanned: by amavisd-new at redback.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: 
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: parberg@redback.com
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

I support this draft becoming a WG ID.

Peter 

> -----Original Message-----
> From: Matthew.Bocci@alcatel.co.uk 
> [mailto:Matthew.Bocci@alcatel.co.uk] 
> Sent: 9. november 2006 15:23
> To: ancp@ietf.org
> Subject: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG ID?
> 
> During the ANCP meeting in San Diego we asked whether the 
> ANCP Security
> Threats Analysis draft 
> (draft-moustafa-ancp-security-threats-00.txt) should
> become a working group ID.
> 
> Please review the draft and post comments to the list, also indicating
> whether or not you support this draft becoming a working group ID.
> 
> Regards,
> 
> Matthew
> 
> 
> 
> 
> 
> 
> _______________________________________________
> ANCP mailing list
> ANCP@ietf.org
> https://www1.ietf.org/mailman/listinfo/ancp
> 



_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Wed Nov 15 14:32:32 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GkQUm-0004TN-CU; Wed, 15 Nov 2006 14:32:28 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GkQUl-0004RO-FQ
	for ancp@ietf.org; Wed, 15 Nov 2006 14:32:27 -0500
Received: from prattle.redback.com ([155.53.12.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkQUk-0004ZY-5j
	for ancp@ietf.org; Wed, 15 Nov 2006 14:32:27 -0500
Received: from localhost (localhost [127.0.0.1])
	by prattle.redback.com (Postfix) with ESMTP id 96342AC92AD;
	Wed, 15 Nov 2006 11:32:25 -0800 (PST)
Received: from prattle.redback.com ([127.0.0.1])
	by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
	id 17491-09; Wed, 15 Nov 2006 11:32:25 -0800 (PST)
Received: from glasgow.redback.com (glasgow.redback.com [155.53.44.170])
	by prattle.redback.com (Postfix) with ESMTP id 64101AC92AC;
	Wed, 15 Nov 2006 11:32:25 -0800 (PST)
Date: Wed, 15 Nov 2006 11:32:25 -0800 (PST)
From: Ferry Sutanto <fsutanto@redback.com>
To: parberg@redback.com
Subject: RE: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
In-Reply-To: <008d01c707b0$82073f20$0a01a8c0@ad.redback.com>
Message-ID: <Pine.LNX.4.60.0611151126560.17069@glasgow.redback.com>
References: <008d01c707b0$82073f20$0a01a8c0@ad.redback.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Virus-Scanned: by amavisd-new at redback.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: ancp@ietf.org
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org


Hi guys,

While we are in this subject.

For the case where BRAS will aggregate/control many (order of thousands) 
AN, ANCP protocol need a way for BRAS to be able to shape AN's keepalive 
value to better utilize BRAS's cpu and memory usage, this will prevent 
storm of AN's keepalive coming to BRAS at the same second. I was thinking 
at the beginning of SYN stage of adjacency protocol, BRAS can send SYN 
with new TLV to shape AN's keepalive.

Thanks,

Ferry


On Mon, 13 Nov 2006, Peter Arberg wrote:

> I support this as a WG draft. I take it we can keep expanding
> the content as long as the WG agree to suggested additions
> or deletions ?
>
> cheers,
> Peter
>
>> -----Original Message-----
>> From: Matthew.Bocci@alcatel.co.uk
>> [mailto:Matthew.Bocci@alcatel.co.uk]
>> Sent: 9. november 2006 15:27
>> To: ancp@ietf.org
>> Subject: [ANCP]
>> draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
>>
>> During the ANCP meeting in San Diego we asked whether the
>> ANCP protocol
>> draft (draft-wadhwa-gsmp-l2control-configuration-02.txt )
>> should become a
>> working group ID.
>>
>> Please indicate to the list whether or not you support this
>> draft becoming
>> a working group ID.
>>
>> Regards,
>>
>> Matthew
>>
>>
>>
>>
>>
>> _______________________________________________
>> ANCP mailing list
>> ANCP@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ancp
>>
>
>
>
> _______________________________________________
> ANCP mailing list
> ANCP@ietf.org
> https://www1.ietf.org/mailman/listinfo/ancp
>

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Thu Nov 16 05:22:39 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GkeO4-0007WG-MK; Thu, 16 Nov 2006 05:22:28 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GkeO3-0007W6-MA
	for ancp@ietf.org; Thu, 16 Nov 2006 05:22:27 -0500
Received: from ug-out-1314.google.com ([66.249.92.173])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkeNz-0001vL-MT
	for ancp@ietf.org; Thu, 16 Nov 2006 05:22:27 -0500
Received: by ug-out-1314.google.com with SMTP id 72so357837ugd
	for <ancp@ietf.org>; Thu, 16 Nov 2006 02:22:22 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:mime-version:content-type;
	b=Tmg/QQA6CC3kPFa5xoK6C513+BAwy+p/7nueG5lFbjQMFFKmtAqXIPz0tzOy1sTMa2VEn8/XXtWpc1K0A15jxwPZ0me7Dj7J8gVEgTTYQVuofjvt9qbWwHQmyvv7DIebnipSYHIP3HYq9OhK1tuTKpEjroOkwit8ImQ5dfgNy9k=
Received: by 10.66.243.4 with SMTP id q4mr571586ugh.1163672541239;
	Thu, 16 Nov 2006 02:22:21 -0800 (PST)
Received: by 10.67.19.4 with HTTP; Thu, 16 Nov 2006 02:22:21 -0800 (PST)
Message-ID: <dea40f930611160222k33cb2ea4y3daf4cf122ff0397@mail.gmail.com>
Date: Thu, 16 Nov 2006 11:22:21 +0100
From: "Hasnaa Moustafa" <hasnaa.moustafa@gmail.com>
To: ancp@ietf.org
MIME-Version: 1.0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235
Subject: [ANCP] draft-moustafa-ancp-security-threats-00.txt: Comments Reply
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0518806998=="
Errors-To: ancp-bounces@ietf.org

--===============0518806998==
Content-Type: multipart/alternative; 
	boundary="----=_Part_75112_26820861.1163672541147"

------=_Part_75112_26820861.1163672541147
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Pavan,
Thanks for these interesting comments.
The reply is below, inserted in your message. Hope all is clear now.

Thanks again.

Regards,
Hassnaa Moustafa

-----------------------------------
Message: 6
Date: Tue, 14 Nov 2006 14:43:42 +0530
From: "pavan_kurapati" <pavan_kurapati@infosys.com>
Subject: [ANCP] draft-moustafa-ancp-security-threats-00.txt
To: <ancp@ietf.org>
Message-ID:
       <0CA51D55A5DC42479FEBFBCEB7D5F183D44BFB@BLRKECMSG01.ad
.infosys.com<0CA51D55A5DC42479FEBFBCEB7D5F183D44BFB@BLRKECMSG01.ad.infosys.com>
>
Content-Type: text/plain;       charset="iso-8859-1"


Hi,
I have following comments on this draft.

1. Introduction: "Prevention again Impersonation". Change it to  'against'


Reply: Yes, it is typos

Reply /end


2. Section 4 : The last bullet points of the 2 sections point to same thing.
i.e changing QoS settings for gaining profit. What is the difference?


Reply: The difference is that the QoS bullet concerning the point of attacks
against an individual entity: means that an attacker may change the QoS
parameters of its own subscription to gain more advantage illegitimately.

However, the QoS bullet concerning the point of attacks against the access
network or a portion of it: means that an attacker can replay old packets
concerning the QoS parameters of another privileged client to configure
these QoS parameters for itself (thus we can say that the attacker in this
case is stealing the QoS parameters from privileged client though replaying
the corresponding packets, and the attacker is an illegitimate client of
coarse).  ABut, this bullet does not belong to the attacks against the
access network, so it should be displaced or merged with the above bullet.

This section can be re-written for clarifying our thoughts and for
readability means. Maybe the second part should be merged with the first
part because attacks to the network eventually result in attacks to
customers.

Reply /end


3. Section 5 seems to have lot of repeated information. For eg.,
5.6Man-in-the-Middle is discussed in previous sections as well (like
DoS attack
section). Also, 5.7 Network snooping is very similar to traffic analysis
section. Both can be merged.


Reply: Man-in-the-middle attacks can cause DoS, but it can be other thing
that DoS as message modification for example which impacts integrity. Also,
Traffic analysis is an example of attacks that can take place due to network
snooping. Network snooping may be in form of eavesdropping or monitoring
activities. But this section can be more organized so not to confuse the
readers. The section could be split into two parts: what attacks do exist,
and how can these attacks be done.

Reply /end


4.  6.1 one of the attacks mentions "man-in-the-middle attack causing access
loop configuration data retrieval from the policy server by an illegitimate
NAS". I see this as a security consideration between policy server and NAS.
In the begininning of this section it was mentioned that this is out of
scope and is not discussed. Just a minor comment on consistency.


Reply: Actually, for this section (this use case) there is no data retrieval
from the policy server by the NAS. Thus, this should be changed to
(man-in-the-middle attack causing access loop configuration data retrieval
by an illegitimate NAS). An adversary taking control over the NAS acts as a
Man-in-the-middle and can illegitimately receive the Access Loop Attributes
in place of the NAS.



However, in the Section 6.2 (Access Loop Configuration Use Case), this type
of attacks which are related to the policy server is possible, as the NAS
query the policy server to retrieve Access Loop configuration data (as
mentioned in the framework draft). So eavesdropping may take place on the
configuration data retrieved by off-path adversaries on the Internet (fifth
bullet in Section 6.2) and also an off-path adversary on the Internet can
damage subscribers related data in the policy server through for instance
making subscribers record inaccessible (sixth bullet in Section 6.2).



Consistency is not hurt, as we do not talk about the authentication and
authorization between the NAS and the AAA/Policy server (which is out of
scope of our work). But we are mentioning attacks that are related to the
ANCP operation and are concerning the communication between the NAS and the
AAA/Policy server. When the policy server is in direct contact with the NAS,
the ANCP attributes are translated by the NAS into Radius/Diameter
attributes.  What is in fact out-of-scope is how the user gets authenticated
and how the AAA server gets the authorization data. Once the AAA has the
authorization data, then it is given to the NAS, which is more in our scope.
The draft should discuss more on this point to avoid any ambiguity.

Reply /end


5. 6.2 Access loop Configuration :
first bullet point says that an onpath adversary on AN can change the access
loop configuration. I would not see it as a ANCP threat. If there is an
onpath adversay 'on' AN, the AN itself is compromised. So he would not wait
for ANCP to change the access loop configuration isn't it?


Reply: You are right, once on the AN, someone can listen to the ANCP
configuration parameters, and then change them.  The adversary does not need
to wait for the ANCP messages, but still such an adversary (attacker) might
look to the configuration to see the configuration that someone else gets (
e.g., one ISP might be interested what the customers of another ISP gets and
therefore might break into the AN to see this). In such case, the attack is
not a downgrading attack, but it is rather learning the attributes.  So this
bullet will be re-worked.

Reply/end


6. I am not sure how a DSL user can be 'on path' adversary. I assume 'on
path' adversary as someone residing between NAS and AN (As defined in
section 3). Bullet 4 of section 6.2 says that an on path adversary  can
configure his "own" profile with some other privileged client's profile. I
think it is possible only by someone  sitting between AN and NAS . He does
not have a user profile of his own. More explanation is required as to how
it can be possible?


Reply: It is not so sure that the DSL user should be only off-path. If I am
on a certain DSL line  that does not mean that I launch my attack directly
from my home, but rather I will do this via first trying to get into another
box (e.g., Ethernet switch between AN and NAS), which is an on-path attack
and not an off-path. Actually, this is a very important security threat, as
such attack does not result in any customer complaint or alarm, and the ISP
will not detect it.

Reply/end


7. 6.4 also talks about modifying parameters to adversary benefit. I do not
think an onpath adversary can do something for his own benefit. I see a DSL
user as an off path adversary who can do certain limited things
w.r.toloopback tests etc. How can he change profiles of his own or
someone else
using ANCP?



Reply: The same as above.
Reply/end

Regards,
Hassnaa Moustafa


Pavan Kumar Kurapati
Infosys Technologies Ltd,
Bangalore

------=_Part_75112_26820861.1163672541147
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div>Hi Pavan,</div>
<div>Thanks for these interesting comments.</div>
<div>The reply is below, inserted in your message. Hope all is clear now.</div>
<div>&nbsp;</div>
<div>Thanks again.</div>
<div>&nbsp;</div>
<div>Regards,</div>
<div>Hassnaa Moustafa</div>
<div>&nbsp;</div>
<div>-----------------------------------</div>
<div>Message: 6<br>Date: Tue, 14 Nov 2006 14:43:42 +0530<br>From: &quot;pavan_kurapati&quot; &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:pavan_kurapati@infosys.com">pavan_kurapati@infosys.com
</a>&gt;<br>Subject: [ANCP] draft-moustafa-ancp-security-threats-00.txt<br>To: &lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:ancp@ietf.org">ancp@ietf.org</a>&gt;<br>Message-ID:<br>&nbsp; &nbsp; &nbsp; &nbsp;&lt;<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:0CA51D55A5DC42479FEBFBCEB7D5F183D44BFB@BLRKECMSG01.ad.infosys.com">
0CA51D55A5DC42479FEBFBCEB7D5F183D44BFB@BLRKECMSG01.ad<span></span> .infosys.com</a>&gt;<br>Content-Type: text/plain; &nbsp; &nbsp; &nbsp; charset=&quot;iso-8859-1&quot;<br><br><br>Hi,<br>I have following comments on this draft.<br><br>1. Introduction: &quot;Prevention again Impersonation&quot;. Change it to &nbsp;'against'
</div>
<div>&nbsp;</div>
<p class="MsoNormal" style="TEXT-JUSTIFY: inter-ideograph; MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: justify"><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-GB">Reply: Yes, it is typos
</span></p>
<p class="MsoNormal" style="TEXT-JUSTIFY: inter-ideograph; MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: justify"><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-GB">Reply /end</span>
</p>
<div><br><br>2. Section 4 : The last bullet points of the 2 sections point to same thing. i.e changing QoS settings for gaining profit. What is the difference?</div>
<div>&nbsp;</div>
<p class="MsoNormal" style="TEXT-JUSTIFY: inter-ideograph; MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: justify"><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-GB">Reply: The difference is that the QoS bullet concerning the point of attacks against an individual entity: means that an attacker may change the QoS parameters of its own subscription to gain more advantage illegitimately.
</span></p>
<p class="MsoNormal" style="TEXT-JUSTIFY: inter-ideograph; MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: justify"><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-GB">However, the QoS bullet concerning the point of attacks against the access network or a portion of it: means that an attacker can replay old packets concerning the QoS parameters of another privileged client to configure these QoS parameters for itself (thus we can say that the attacker in this case is stealing the QoS parameters from privileged client though replaying the corresponding packets, and the attacker is an illegitimate client 
</span><span lang="EN-US" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-US">of coarse</span><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-GB">
). <span style="mso-spacerun: yes">&nbsp;</span>ABut, this bullet does not belong to the attacks against the access network, so it should be displaced or merged with the above bullet.</span></p>
<p class="MsoNormal" style="TEXT-JUSTIFY: inter-ideograph; MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: justify"><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-GB">This section can be re-written for clarifying our thoughts and for readability means.
</span><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: 'Courier New'; mso-ansi-language: EN-GB"> </span><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-GB">
Maybe the second part should be merged with the first part because attacks to the network eventually result in attacks to customers.</span></p>
<p class="MsoNormal" style="TEXT-JUSTIFY: inter-ideograph; MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: justify"><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-GB">Reply /end</span>
</p>
<div><br><br>3. Section 5 seems to have lot of repeated information. For eg., 5.6 Man-in-the-Middle is discussed in previous sections as well (like DoS attack section). Also, 5.7 Network snooping is very similar to traffic analysis section. Both can be merged.
</div>
<div>&nbsp;</div>
<p class="MsoNormal" style="TEXT-JUSTIFY: inter-ideograph; MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: justify"><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-GB">Reply: Man-in-the-middle attacks can cause DoS, but it can be other thing that DoS as message modification for example which impacts integrity. Also, Traffic analysis is an example of attacks that can take place due to network snooping. Network snooping may be in form of eavesdropping or monitoring activities. But this section can be more organized so not to confuse the readers. The section could be split into two parts: what attacks do exist, and how can these attacks be done.
</span></p>
<p class="MsoNormal" style="TEXT-JUSTIFY: inter-ideograph; MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: justify"><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-GB">Reply /end</span>
</p>
<div><br><br>4. &nbsp;6.1 one of the attacks mentions &quot;man-in-the-middle attack causing access loop configuration data retrieval from the policy server by an illegitimate NAS&quot;. I see this as a security consideration between policy server and NAS. In the begininning of this section it was mentioned that this is out of scope and is not discussed. Just a minor comment on consistency.
</div>
<div>&nbsp;</div>
<p class="MsoNormal" style="TEXT-JUSTIFY: inter-ideograph; MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: justify"><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-GB">Reply: Actually, for this section (this use case) there is no data retrieval from the policy server by the NAS. Thus, this should be changed to (man-in-the-middle attack causing access loop configuration data retrieval by an illegitimate NAS). An adversary taking control over the NAS acts as a Man-in-the-middle and can illegitimately receive the Access Loop Attributes in place of the NAS. 
</span></p>
<p class="MsoNormal" style="TEXT-JUSTIFY: inter-ideograph; MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: justify"><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-GB">&nbsp;</span></p>
<p class="MsoNormal" style="TEXT-JUSTIFY: inter-ideograph; MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: justify"><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-GB">However, in the Section 
6.2 (Access Loop Configuration Use Case), this type of attacks which are related to the policy server is possible, as the NAS query the policy server to retrieve Access Loop configuration data (as mentioned in the framework draft). So eavesdropping may take place on the configuration data retrieved by off-path adversaries on the Internet (fifth bullet in Section 
6.2) and also an off-path adversary on the Internet can damage subscribers related data in the policy server through for instance making subscribers record inaccessible (sixth bullet in Section 6.2). </span></p>
<p class="MsoNormal" style="TEXT-JUSTIFY: inter-ideograph; MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: justify"><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-GB">&nbsp;</span></p>
<p class="MsoNormal" style="TEXT-JUSTIFY: inter-ideograph; MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: justify"><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-GB">Consistency is not hurt, as we do not talk about the authentication and authorization between the NAS and the AAA/Policy server (which is out of scope of our work). But we are mentioning attacks that are related to the ANCP operation and are concerning the communication between the NAS and the AAA/Policy server. When the policy server is in direct contact with the NAS, the ANCP attributes are translated by the NAS into Radius/Diameter attributes.
<span style="mso-spacerun: yes">&nbsp; </span>What is in fact out-of-scope is how the user gets authenticated and how the AAA server gets the authorization data. Once the AAA has the authorization data, then it is given to the NAS, which is more in our scope. The draft should discuss more on this point to avoid any ambiguity.
</span></p>
<p class="MsoNormal" style="TEXT-JUSTIFY: inter-ideograph; MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: justify"><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-GB">Reply /end</span>
</p>
<div><br><br>5. 6.2 Access loop Configuration :<br>first bullet point says that an onpath adversary on AN can change the access loop configuration. I would not see it as a ANCP threat. If there is an onpath adversay 'on' AN, the AN itself is compromised. So he would not wait for ANCP to change the access loop configuration isn't it?
</div>
<div>&nbsp;</div>
<p class="MsoNormal" style="TEXT-JUSTIFY: inter-ideograph; MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: justify; mso-layout-grid-align: none"><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-GB">
Reply: You are right, once on the AN, someone can listen to the ANCP configuration parameters, and then change them.<span style="mso-spacerun: yes">&nbsp; </span>The adversary does not need to wait for the ANCP messages, but still such an adversary (attacker) might look to the configuration to see the configuration that someone else gets (
e.g., one ISP might be interested what the customers of another ISP gets and therefore might break into the AN to see this). In such case, the attack is not a downgrading attack, but it is rather learning the attributes.<span style="mso-spacerun: yes">
&nbsp; </span>So this bullet will be re-worked.</span></p>
<p class="MsoNormal" style="TEXT-JUSTIFY: inter-ideograph; MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: justify; mso-layout-grid-align: none"><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-GB">
Reply/end</span></p>
<div><br><br>6. I am not sure how a DSL user can be 'on path' adversary. I assume 'on path' adversary as someone residing between NAS and AN (As defined in section 3). Bullet 4 of section 6.2 says that an on path adversary &nbsp;can configure his &quot;own&quot; profile with some other privileged client's profile. I think it is possible only by someone &nbsp;sitting between AN and NAS . He does not have a user profile of his own. More explanation is required as to how it can be possible?
</div>
<div>&nbsp;</div>
<p class="MsoNormal" style="TEXT-JUSTIFY: inter-ideograph; MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: justify; mso-layout-grid-align: none"><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-GB">
Reply: It is not so sure that the DSL user should be only off-path. If I am on a certain DSL line<span style="mso-spacerun: yes">&nbsp; </span>that does not mean that I launch my attack directly from my home, but rather I will do this via first trying to get into another box (
e.g., Ethernet switch between AN and NAS), which is an on-path attack and not an off-path. Actually, this is a very important security threat, as such attack does not result in any customer complaint or alarm, and the ISP will not detect it. 
</span></p>
<p class="MsoNormal" style="TEXT-JUSTIFY: inter-ideograph; MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: justify"><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-GB">Reply/end</span>
</p>
<div><br><br>7. 6.4 also talks about modifying parameters to adversary benefit. I do not think an onpath adversary can do something for his own benefit. I see a DSL user as an off path adversary who can do certain limited things 
<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://w.r.to/" target="_blank"><span></span>w.r.to</a> loopback tests etc. How can he change profiles of his own or someone else using ANCP?<br><br>&nbsp;</div>
<p class="MsoNormal" style="TEXT-JUSTIFY: inter-ideograph; MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: justify"><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-GB">Reply: The same as above.
</span></p>
<div class="MsoNormal" style="TEXT-JUSTIFY: inter-ideograph; MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: justify"><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-GB">Reply/end </span>
</div>
<div class="MsoNormal" style="TEXT-JUSTIFY: inter-ideograph; MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: justify"><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-GB"></span>&nbsp;</div>

<div class="MsoNormal" style="TEXT-JUSTIFY: inter-ideograph; MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: justify"><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-GB">Regards, </span>
</div>
<div class="MsoNormal" style="TEXT-JUSTIFY: inter-ideograph; MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: justify"><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-GB">Hassnaa Moustafa
</span></div>
<div class="MsoNormal" style="TEXT-JUSTIFY: inter-ideograph; MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: justify"><span lang="EN-GB" style="FONT-SIZE: 10pt; COLOR: #339966; FONT-FAMILY: Arial; mso-ansi-language: EN-GB"></span>&nbsp;</div>

<div><br>Pavan Kumar Kurapati<br>Infosys Technologies Ltd,<br>Bangalore<br><br>&nbsp;</div>

------=_Part_75112_26820861.1163672541147--


--===============0518806998==
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://www1.ietf.org/mailman/listinfo/ancp

--===============0518806998==--




From ancp-bounces@ietf.org Thu Nov 16 05:24:20 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GkePo-0007lT-CC; Thu, 16 Nov 2006 05:24:16 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GkePn-0007lN-Rs
	for ancp@ietf.org; Thu, 16 Nov 2006 05:24:15 -0500
Received: from ug-out-1314.google.com ([66.249.92.173])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkePm-00028t-IJ
	for ancp@ietf.org; Thu, 16 Nov 2006 05:24:15 -0500
Received: by ug-out-1314.google.com with SMTP id 72so358142ugd
	for <ancp@ietf.org>; Thu, 16 Nov 2006 02:24:13 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:mime-version:content-type;
	b=kQHaGevmDDUyhZCmanPynCZ7lQD8YEUwN3NuWth7zmRRMexLt9JDdVoGQ9wqyprKtnyNFdrKg9cJulvLoGYzktuW3mW/bU9Kbt0aHcvCGv0kL0Vtw+KKdl9TEl3y2agTV1zZvjY7emB9X+mHmocytk+7rqu907NH3x+VSXtwC6s=
Received: by 10.66.216.20 with SMTP id o20mr1752ugg.1163672653291;
	Thu, 16 Nov 2006 02:24:13 -0800 (PST)
Received: by 10.67.19.4 with HTTP; Thu, 16 Nov 2006 02:24:13 -0800 (PST)
Message-ID: <dea40f930611160224n6c04ac2bx943984c252a00b22@mail.gmail.com>
Date: Thu, 16 Nov 2006 11:24:13 +0100
From: "Hasnaa Moustafa" <hasnaa.moustafa@gmail.com>
To: ancp@ietf.org
MIME-Version: 1.0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Subject: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1201713740=="
Errors-To: ancp-bounces@ietf.org

--===============1201713740==
Content-Type: multipart/alternative; 
	boundary="----=_Part_75164_33281821.1163672653234"

------=_Part_75164_33281821.1163672653234
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,
I support this draft as a WG item.

Regards,
Hassnaa Moustafa

> -----Original Message-----
> From: Matthew.Bocci@alcatel.co.uk
> [mailto:Matthew.Bocci@alcatel.co.uk]
> Sent: 9. november 2006 15:27
> To: ancp@ietf.org
> Subject: [ANCP]
> draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
>
> During the ANCP meeting in San Diego we asked whether the
> ANCP protocol
> draft (draft-wadhwa-gsmp-l2control-configuration-02.txt )
> should become a
> working group ID.
>
> Please indicate to the list whether or not you support this
> draft becoming
> a working group ID.
>
> Regards,
>
> Matthew
>

------=_Part_75164_33281821.1163672653234
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<div>Hi,</div>
<div>I support this draft as a WG item.</div>
<div>&nbsp;</div>
<div>Regards,</div>
<div>Hassnaa Moustafa</div>
<div><br>&gt; -----Original Message-----<br>&gt; From: <a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:Matthew.Bocci@alcatel.co.uk">Matthew.Bocci@alcatel.co.uk</a><br>&gt; [mailto:<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:Matthew.Bocci@alcatel.co.uk">
Matthew.Bocci@alcatel.co.uk</a>]<br>&gt; Sent: 9. november 2006 15:27<br>&gt; To: <a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:ancp@ietf.org">ancp@ietf.org</a><br>&gt; Subject: [ANCP]<br>&gt; draft-wadhwa-gsmp-l2control-configuration-02.txt
 to WG ID?<br>&gt;<br>&gt; During the ANCP meeting in San Diego we asked whether the<br>&gt; ANCP protocol<br>&gt; draft (draft-wadhwa-gsmp-l2control-configuration-02.txt )<br>&gt; should become a<br>&gt; working group ID.
<br>&gt;<br><span></span>&gt; Please indicate to the list whether or not you support this<br>&gt; draft becoming<br>&gt; a working group ID.<br>&gt;<br>&gt; Regards,<br>&gt;<br>&gt; Matthew<br>&gt;<br>&nbsp;</div>

------=_Part_75164_33281821.1163672653234--


--===============1201713740==
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://www1.ietf.org/mailman/listinfo/ancp

--===============1201713740==--




From ancp-bounces@ietf.org Thu Nov 16 07:25:52 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GkgJJ-0007WP-ML; Thu, 16 Nov 2006 07:25:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GkgJH-0007WA-Pn
	for ancp@ietf.org; Thu, 16 Nov 2006 07:25:39 -0500
Received: from smail.alcatel.fr ([62.23.212.165])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkgJG-00025Y-9l
	for ancp@ietf.org; Thu, 16 Nov 2006 07:25:39 -0500
Received: from gbmail02.netfr.alcatel.fr (gbmail02.netfr.alcatel.fr
	[155.132.251.26])
	by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kAGCPeYV025524;
	Thu, 16 Nov 2006 13:25:40 +0100
In-Reply-To: <2DEB3E4E9BC3774B8EEF2EF2BE9F745B5ED3B1@esealmw104.eemea.ericsson.se>
Subject: RE: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
To: "Kim Hyldgaard \(ST/LMD\)" <kim.hyldgaard@ericsson.com>
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
Message-ID: <OF2F3661D2.124FDF23-ON80257228.003BBCE4-80257228.003BCF70@netfr.alcatel.fr>
From: Matthew.Bocci@alcatel.co.uk
Date: Thu, 16 Nov 2006 10:53:17 +0000
X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 |
	June 23, 2005) at 11/16/2006 12:25:36
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Cc: ancp@ietf.org
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

Kim, Peter,

Yes, changes can still be made to the draft. It is not cast in stone just
because it is a WG ID.

Best regards,

Matthew



                                                                           
             "Kim Hyldgaard                                                
             \(ST/LMD\)"                                                   
             <kim.hyldgaard@er                                          To 
             icsson.com>               Matthew BOCCI/GB/ALCATEL@ALCATEL,   
                                       <ancp@ietf.org>                     
             14/11/2006 08:20                                           cc 
                                                                           
                                                                   Subject 
                                       RE: [ANCP]                          
                                       draft-wadhwa-gsmp-l2control-configu 
                                       ration-02.txt to WG ID?             
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Hi,

I support this draft becomming a WG ID.

- I have the same assumption as stated by Peter
below: That we can expand the content as long as
the WG agree to suggested additions or deletions.

Br
Kim


-----Original Message-----
From: Peter Arberg [mailto:parberg@redback.com]
Sent: 14. november 2006 06:48
To: Matthew.Bocci@alcatel.co.uk; ancp@ietf.org
Subject: RE: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to
WG ID?

I support this as a WG draft. I take it we can keep expanding the
content as long as the WG agree to suggested additions or deletions ?

cheers,
Peter

> -----Original Message-----
> From: Matthew.Bocci@alcatel.co.uk
> [mailto:Matthew.Bocci@alcatel.co.uk]
> Sent: 9. november 2006 15:27
> To: ancp@ietf.org
> Subject: [ANCP]
> draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
>
> During the ANCP meeting in San Diego we asked whether the ANCP
> protocol draft (draft-wadhwa-gsmp-l2control-configuration-02.txt )
> should become a working group ID.
>
> Please indicate to the list whether or not you support this draft
> becoming a working group ID.
>
> Regards,
>
> Matthew
>
>
>
>
>
> _______________________________________________
> ANCP mailing list
> ANCP@ietf.org
> https://www1.ietf.org/mailman/listinfo/ancp
>



_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp





_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Sun Nov 19 05:05:13 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GljXb-0004Tm-7G; Sun, 19 Nov 2006 05:04:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GljXa-0004Th-Lr
	for ancp@ietf.org; Sun, 19 Nov 2006 05:04:46 -0500
Received: from eci-iron.ecitele.com ([147.234.242.112] helo=iron.ecitele.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GljXW-0007UA-OK
	for ancp@ietf.org; Sun, 19 Nov 2006 05:04:46 -0500
Received: from ilptexfe.ecitele.com (HELO ILPTEXFE01.ecitele.com)
	([172.31.244.40])
	by iron.ecitele.com with ESMTP; 19 Nov 2006 12:14:37 +0200
Received: from ILPTMAIL01.ecitele.com ([147.234.245.210]) by
	ILPTEXFE01.ecitele.com with Microsoft SMTPSVC(6.0.3790.2499); 
	Sun, 19 Nov 2006 12:04:34 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG ID?
Date: Sun, 19 Nov 2006 12:04:44 +0200
Message-ID: <2F7C502D2CC5EF4CBA93F7F47896E1973CFDF8@ilptex01.ecitele.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG ID?
Thread-index: AccEVkOPqwQahHFmQrOyraAzNAuftQHa8PFA
From: "Menachem Dodge" <Menachem.Dodge@ecitele.com>
To: <Matthew.Bocci@alcatel.co.uk>,
	<ancp@ietf.org>
X-OriginalArrivalTime: 19 Nov 2006 10:04:34.0798 (UTC)
	FILETIME=[1D63A8E0:01C70BC2]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: 
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

Hi,

	I support this document becoming a Working Group Id.

Best Regards,
Menachem Dodge.=20

-----Original Message-----
From: Matthew.Bocci@alcatel.co.uk [mailto:Matthew.Bocci@alcatel.co.uk]=20
Sent: Friday, November 10, 2006 1:23 AM
To: ancp@ietf.org
Subject: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG ID?

During the ANCP meeting in San Diego we asked whether the ANCP Security
Threats Analysis draft (draft-moustafa-ancp-security-threats-00.txt)
should
become a working group ID.

Please review the draft and post comments to the list, also indicating
whether or not you support this draft becoming a working group ID.

Regards,

Matthew






_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Sun Nov 19 05:11:51 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GljeM-0006nf-Qx; Sun, 19 Nov 2006 05:11:46 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GljeL-0006mi-GE
	for ancp@ietf.org; Sun, 19 Nov 2006 05:11:45 -0500
Received: from eci-iron.ecitele.com ([147.234.242.112] helo=iron.ecitele.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GljeI-00081W-NC
	for ancp@ietf.org; Sun, 19 Nov 2006 05:11:45 -0500
Received: from ilptexfe.ecitele.com (HELO ILPTEXFE01.ecitele.com)
	([172.31.244.40])
	by iron.ecitele.com with ESMTP; 19 Nov 2006 12:21:31 +0200
Received: from ILPTMAIL01.ecitele.com ([147.234.245.210]) by
	ILPTEXFE01.ecitele.com with Microsoft SMTPSVC(6.0.3790.2499); 
	Sun, 19 Nov 2006 12:11:27 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
Date: Sun, 19 Nov 2006 12:11:29 +0200
Message-ID: <2F7C502D2CC5EF4CBA93F7F47896E1973CFE03@ilptex01.ecitele.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
Thread-index: AccEVpxhHHYEEjdBSEGEkkIR8dv3MQHbBU7Q
From: "Menachem Dodge" <Menachem.Dodge@ecitele.com>
To: <Matthew.Bocci@alcatel.co.uk>,
	<ancp@ietf.org>
X-OriginalArrivalTime: 19 Nov 2006 10:11:28.0089 (UTC)
	FILETIME=[13BADC90:01C70BC3]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: 
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

Hi,

	I support this document becoming a Working Group Id.

Best Regards,
Menachem Dodge. =20

-----Original Message-----
From: Matthew.Bocci@alcatel.co.uk [mailto:Matthew.Bocci@alcatel.co.uk]=20
Sent: Friday, November 10, 2006 1:27 AM
To: ancp@ietf.org
Subject: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG
ID?

During the ANCP meeting in San Diego we asked whether the ANCP protocol
draft (draft-wadhwa-gsmp-l2control-configuration-02.txt ) should become
a
working group ID.

Please indicate to the list whether or not you support this draft
becoming
a working group ID.

Regards,

Matthew





_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Sun Nov 19 23:07:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gm0RS-000862-QP; Sun, 19 Nov 2006 23:07:34 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm0RQ-00085s-Tg
	for ancp@ietf.org; Sun, 19 Nov 2006 23:07:32 -0500
Received: from kecgate03.infosysconsulting.com ([220.227.179.21]
	helo=Kecgate03.infosys.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm0RQ-0001Rl-2I
	for ancp@ietf.org; Sun, 19 Nov 2006 23:07:32 -0500
Received: from INDHUBBHS02.ad.infosys.com ([192.168.200.82]) by
	Kecgate03.infosys.com with InterScan Messaging Security Suite;
	Mon, 20 Nov 2006 09:39:23 +0530
Received: from BLRKECMSG14.ad.infosys.com ([172.22.147.6]) by
	INDHUBBHS02.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 20 Nov 2006 09:35:11 +0530
Received: from BLRKECMSG01.ad.infosys.com ([172.25.213.131]) by
	BLRKECMSG14.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 20 Nov 2006 09:35:11 +0530
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 20 Nov 2006 09:34:56 +0530
Message-ID: <6031539A3C7B964581EFCE2E205D6EEF0199E13C@BLRKECMSG01.ad.infosys.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-topic: Some questions and suggestion on Framework document..
Thread-index: AccMWFq5udoKZVqzQru0xkPE7yP73g==
From: "bharat_joshi" <bharat_joshi@infosys.com>
To: <ancp@ietf.org>
X-OriginalArrivalTime: 20 Nov 2006 04:05:11.0165 (UTC)
	FILETIME=[12E022D0:01C70C59]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8
Subject: [ANCP] Some questions and suggestion on Framework document..
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org


Hi,

    I have couple of questions and suggestion on the ANCP framework
document
[http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework-00.txt]:

* In Introduction, statement 'In the scope of these specifications' is
not very clear. I think it may be changed to "The scope of these
specifications'

* In Introduction, second paragraph, statement 'departments operating
the IP network interworking at the management plane is not always
possible' is not clear. I think either a comma [,] between 'network' and
'networking' will make it clear or change the statement as follows:

'Interworking at the management plane is not always possible because of
the organizational boundaries between departments operating the local
loop, departments operating the ATM network and departments operating
the IP network'

* When these 'Information Reports' are generated? Figure 1 shows that
these reports are generated by AN. Are these reports periodically
generated? What kind of information is passed through these reports? I
did not find any reference to this in the document.

* In section 2.4.1, through we talk about port-addressing schemes but we
are not actually referring to ports here. There are configurations where
we can have multiple user sessions and 'Circuit-Id' would be different
for each one of them. So what I want to say is that we are identifying
the circuit instead of ports. So you may want to change the section
title to something which reflects the same.

* I am trying to understand the need of communicating DSL line data rate
to NAS for each user. Does it anyway help in over-subscription on NAS? I
can understand that NAS can modify its scheduling parameters for a given
user based on the line data rate provided by AN but what is the
advantage?

* In Access loop configuration, Its mentioned that Access loop
configuration is available with the Access provided which controls the
DSL line profile in Access Node. Now subscriber wants some changes in
it, its mentioned that ANCP can propagate this change without an
operator intervention using policy server. My question is if ANCP is
down and during this time, a change happens, how would the system react?
This change may have happened in the Access Node but NAS may not be
aware of this change. Is this correct?

* Does ANCP require a configuration of 'upstream router port' [interface
to reach NAS] in ANs? or does it run a protocols to figure out the
interface on which it can reach to the upstream router [NAS]
dynamically?

* In section 4.1, Point #4. Last line could be modified to use the word
"atomic".

* In section 4.2, point #4. As ANCP is mapped on top of IP, there is not
inherent support of reliability, so how do we take care of the
reliability here? Do we send the ANCP message multiple times?

* Section 4.2 does not mention any requirements for authentication
before ANCP sessions are created? How do we handle authentication here?

* In section 4.4.1, how does a logical port treated here? Can a logical
port built on top of a physical port be attached to a different
partition?

* In section 4.4.2, statement "If an Access Node in street cabinet
installation is connected to a NAS all user and Access Node Control data
use the same physical link" is not clear. I think we need a comma [,]
between 'NAS' and 'all user' and also change 'all user' to 'all users'
as follows:

"If an Access Node in street cabinet installation is connected to a NAS,
all users and Access Node Control data use the same physical link.

* In section 4.4.2, statement, "If ATM interfaces are used VPI as well
as VCI value MUST be configurable in the full range." is not clear. I
think a comma [,] needs to be added between 'used' and 'VPI'. It may be
corrected as follows:

"If ATM interfaces are used, VPI as well as VCI value MUST be
configurable in the full range."

* In section 4.4.6, can we combine multiple ANCP messages in single
message? This may help in saving some CPU cycles in AN and NAS.

* In section 4.4.7, I think providing configuration for each parameter
which can be modified using ANCP, would be a little too much. Though
this depends upon the parameters available for configuration but I think
it would be good if it is done for a group of parameters. Something like
'Multicast-group', which if enabled can result in modifying certain
parameters related to multicast.

* I think if possible, we should add the security consideration in both
Access Node requirements as well as NAS requirements.

Thanks & Regards,
Bharat

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended=
 solely for the use of the addressee(s). If you are not the intended=
 recipient, please notify the sender by e-mail and delete the original=
 message. Further, you are not to copy, disclose, or distribute this e-mail=
 or its contents to any other person and any such actions are unlawful.=
 This e-mail may contain viruses. Infosys has taken every reasonable=
 precaution to minimize this risk, but is not liable for any damage you may=
 sustain as a result of any virus in this e-mail. You should carry out your=
 own virus checks before opening the e-mail or attachment. Infosys reserves=
 the right to monitor and review the content of all messages sent to or=
 from this e-mail address. Messages sent to or from this e-mail address may=
 be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Mon Nov 20 04:49:26 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gm5m6-0001sz-Ru; Mon, 20 Nov 2006 04:49:14 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm5m5-0001st-Jl
	for ancp@ietf.org; Mon, 20 Nov 2006 04:49:13 -0500
Received: from tcmail31.telekom.de ([217.6.95.238])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gm5m4-0007On-2V
	for ancp@ietf.org; Mon, 20 Nov 2006 04:49:13 -0500
Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.telekom.de with ESMTP;
	Mon, 20 Nov 2006 10:48:04 +0100
Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by
	S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 20 Nov 2006 10:48:04 +0100
Content-class: urn:content-classes:message
Subject: WG: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 20 Nov 2006 10:48:03 +0100
Message-Id: <6439282641581441A36F7F6F83ED2ED2C457D5@S4DE8PSAAFQ.mitte.t-com.de>
X-MimeOLE: Produced By Microsoft Exchange V6.5
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID?
Thread-Index: AccEXwW/nHnNK358Sv2Hdvlbq8W0xQIKc8rg
From: "Busser, M" <Michael.Busser@t-systems.com>
To: <Matthew.Bocci@alcatel.co.uk>,
    <ancp@ietf.org>
X-OriginalArrivalTime: 20 Nov 2006 09:48:04.0397 (UTC)
	FILETIME=[F97A35D0:01C70C88]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: 
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

All,

I will also support becoming ANCP protocol draft =
(draft-wadhwa-gsmp-l2control-configuration-02.txt)=20
a working group ID.

Regards
Michael Busser




-----Urspr=FCngliche Nachricht-----
Von: Matthew.Bocci@alcatel.co.uk [mailto:Matthew.Bocci@alcatel.co.uk]=20
Gesendet: Freitag, 10. November 2006 00:27
An: ancp@ietf.org
Betreff: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG =
ID?

During the ANCP meeting in San Diego we asked whether the should become.

Please indicate to the list whether or not you support this draft =
becoming a working group ID.

Regards,

Matthew





_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Thu Nov 23 06:26:44 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GnCiq-0004Fw-07; Thu, 23 Nov 2006 06:26:28 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GnCip-0004Fq-2N
	for ancp@ietf.org; Thu, 23 Nov 2006 06:26:27 -0500
Received: from smail.alcatel.fr ([62.23.212.165])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnCil-0007K0-A2
	for ancp@ietf.org; Thu, 23 Nov 2006 06:26:27 -0500
Received: from bemail01.netfr.alcatel.fr (bemail01.netfr.alcatel.fr
	[155.132.251.32])
	by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kANBQRBq019546;
	Thu, 23 Nov 2006 12:26:27 +0100
Received: from [172.31.148.94] ([172.31.148.94])
	by bemail01.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163)
	with ESMTP id 2006112312262114:5644 ;
	Thu, 23 Nov 2006 12:26:21 +0100 
Message-ID: <4565855C.6070506@alcatel.be>
Date: Thu, 23 Nov 2006 12:26:20 +0100
From: Sven.Ooghe@alcatel.be
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: bharat_joshi <bharat_joshi@infosys.com>, ancp@ietf.org
Subject: Re: [ANCP] Some questions and suggestion on Framework document..
References: <6031539A3C7B964581EFCE2E205D6EEF0199E13C@BLRKECMSG01.ad.infosys.com>
In-Reply-To: <6031539A3C7B964581EFCE2E205D6EEF0199E13C@BLRKECMSG01.ad.infosys.com>
X-MIMETrack: Itemize by SMTP Server on BEMAIL01/BE/ALCATEL(Release
	5.0.13aHF163 | June 23, 2005) at 11/23/2006 12:26:21,
	Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 | June
	23, 2005) at 11/23/2006 12:26:21,
	Serialize complete at 11/23/2006 12:26:21
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81
X-Spam-Score: 0.2 (/)
X-Scan-Signature: d008c19e97860b8641c1851f84665a75
Cc: 
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

Hi Bharat,

Please find our answers inline.

bharat_joshi wrote:
> Hi,
> 
>     I have couple of questions and suggestion on the ANCP framework
> document
> [http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework-00.txt]:
> 
> * In Introduction, statement 'In the scope of these specifications' is
> not very clear. I think it may be changed to "The scope of these
> specifications'

<Sven>
Ok
</Sven>

> * In Introduction, second paragraph, statement 'departments operating
> the IP network interworking at the management plane is not always
> possible' is not clear. I think either a comma [,] between 'network' and
> 'networking' will make it clear or change the statement as follows:
> 
> 'Interworking at the management plane is not always possible because of
> the organizational boundaries between departments operating the local
> loop, departments operating the ATM network and departments operating
> the IP network'

<Sven>
We'll use your suggested text.
</Sven>

> * When these 'Information Reports' are generated? Figure 1 shows that
> these reports are generated by AN. Are these reports periodically
> generated? What kind of information is passed through these reports? I
> did not find any reference to this in the document.

<Sven>
The Information Reports in Figure 1 indicate messages that are sent by 
the Access Node towards the NAS. The intent was to show the conceptual 
message flow in figure 1. The actual use of these flows depends on the 
use case. For instance, in case of "Dynamic Access Loop Attributes" 
these messages are sent when the DSL Network Termination (DSL modem) is 
turned on, or when the DSL net data rate changes overtime.
</Sven>

> * In section 2.4.1, through we talk about port-addressing schemes but we
> are not actually referring to ports here. There are configurations where
> we can have multiple user sessions and 'Circuit-Id' would be different
> for each one of them. So what I want to say is that we are identifying
> the circuit instead of ports. So you may want to change the section
> title to something which reflects the same.

<Sven>
The intent is indeed to address the logical ports, which could be an ATM 
PVC or an Ethernet VLAN on top of a physical DSL port. If we chage the 
text to reflect "Locial port addressing", would that be ok?
</Sven>

> * I am trying to understand the need of communicating DSL line data rate
> to NAS for each user. Does it anyway help in over-subscription on NAS? I
> can understand that NAS can modify its scheduling parameters for a given
> user based on the line data rate provided by AN but what is the
> advantage?

<Sven>
Have a look at section 2.9, item (3) in TR-101:
http://www.dslforum.org/techwork/tr/TR-101.pdf
It describes the rationale for knowing the actual DSL net data rate at 
the level of the NAS. More info can also be found in TR-059.
</Sven>

> * In Access loop configuration, Its mentioned that Access loop
> configuration is available with the Access provided which controls the
> DSL line profile in Access Node. Now subscriber wants some changes in
> it, its mentioned that ANCP can propagate this change without an
> operator intervention using policy server. My question is if ANCP is
> down and during this time, a change happens, how would the system react?
> This change may have happened in the Access Node but NAS may not be
> aware of this change. Is this correct?

<Sven>
The assumption we take is that when the use case "Access loop 
configuration" is used, the profile to be used on the access loop will 
be stored in a central policy system. If the ANCP session is down, no 
changes should happen to the access loop configuration.
If for some reason a change happens, we assume that this translates in a 
certain (new) DSL net data rate when the line is operational again. At 
that point, the Access Node will send this information to the NAS, which 
can take a corrective action if needed (e.g. change to another profile 
on the Access Node).
</Sven>

> * Does ANCP require a configuration of 'upstream router port' [interface
> to reach NAS] in ANs? or does it run a protocols to figure out the
> interface on which it can reach to the upstream router [NAS]
> dynamically?

<Sven>
This aspect is not touched upon in the framework description. The 
assumption we take is that the interface is configured.
</Sven>

> * In section 4.1, Point #4. Last line could be modified to use the word
> "atomic".

<Sven>
Ok
</Sven>

> * In section 4.2, point #4. As ANCP is mapped on top of IP, there is not
> inherent support of reliability, so how do we take care of the
> reliability here? Do we send the ANCP message multiple times?

<Sven>
In case ANCP is mapped on top of IP, then the logical consequence is 
that reliability - when needed - must be built into the protocol. How 
that is done will not be described in the framework but is part of the 
protocol specification work.
Note: we expect these requirements will be significantly reworked in an 
update. It would be good to give it a re-read once we've updated the 
framework.
</Sven>

> * Section 4.2 does not mention any requirements for authentication
> before ANCP sessions are created? How do we handle authentication here?

<Sven>
Good point. Security and authentication are not yet touched upon. Our 
idea at present is to refer to a separate document that would define 
those. draft-moustafa-ancp-security-threats-00.txt provides input on his.
</Sven>

> * In section 4.4.1, how does a logical port treated here? Can a logical
> port built on top of a physical port be attached to a different
> partition?

<Sven>
Our assumption at this point is that all logical ports on top of the 
same physical port will be associated with the same partition. In other 
words, partitioning is performed at the level of the physical port only.
</Sven>

> * In section 4.4.2, statement "If an Access Node in street cabinet
> installation is connected to a NAS all user and Access Node Control data
> use the same physical link" is not clear. I think we need a comma [,]
> between 'NAS' and 'all user' and also change 'all user' to 'all users'
> as follows:
> 
> "If an Access Node in street cabinet installation is connected to a NAS,
> all users and Access Node Control data use the same physical link.

<Sven>
Ok
</Sven>

> * In section 4.4.2, statement, "If ATM interfaces are used VPI as well
> as VCI value MUST be configurable in the full range." is not clear. I
> think a comma [,] needs to be added between 'used' and 'VPI'. It may be
> corrected as follows:
> 
> "If ATM interfaces are used, VPI as well as VCI value MUST be
> configurable in the full range."

<Sven>
Ok
</Sven>

> * In section 4.4.6, can we combine multiple ANCP messages in single
> message? This may help in saving some CPU cycles in AN and NAS.

<Sven>
Section 4.4.6 sets the high level requirement for this, but does not go 
into the details of how this can be achieved. Combining multiple 
messages into a single message is one way, which is also how it is 
proposed in draft-wadhwa-gsmp-l2control-configuration-02.txt
</Sven>

> * In section 4.4.7, I think providing configuration for each parameter
> which can be modified using ANCP, would be a little too much. Though
> this depends upon the parameters available for configuration but I think
> it would be good if it is done for a group of parameters. Something like
> 'Multicast-group', which if enabled can result in modifying certain
> parameters related to multicast.

<Sven>
This section needs some reworking/clarification. Having parameter 
control at the granularity of individual parameters may be a bit too 
much. We'll rework the section.
</Sven>

> * I think if possible, we should add the security consideration in both
> Access Node requirements as well as NAS requirements.

<Sven>
How about referring to a separate security document 
(draft-moustafa-ancp-security-threats-00.txt)? Would that make sense?
</Sven>

Regards,
Sven

> Thanks & Regards,
> Bharat
> 
> **************** CAUTION - Disclaimer *****************
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
> 
> _______________________________________________
> ANCP mailing list
> ANCP@ietf.org
> https://www1.ietf.org/mailman/listinfo/ancp
> 

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Thu Nov 23 11:31:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GnHUD-0000Rx-C5; Thu, 23 Nov 2006 11:31:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GnHUB-0000OF-LI
	for ancp@ietf.org; Thu, 23 Nov 2006 11:31:39 -0500
Received: from kecgate06.infosysconsulting.com ([61.95.162.82]
	helo=Kecgate06.infosys.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnHU7-0001M5-Cq
	for ancp@ietf.org; Thu, 23 Nov 2006 11:31:39 -0500
Received: from indhubbhs03.ad.infosys.com ([192.168.200.83]) by
	Kecgate06.infosys.com with InterScan Messaging Security Suite;
	Thu, 23 Nov 2006 21:54:10 +0530
Received: from BLRKECMSG14.ad.infosys.com ([172.22.147.6]) by
	indhubbhs03.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 23 Nov 2006 21:59:18 +0530
Received: from BLRKECMSG01.ad.infosys.com ([172.25.213.131]) by
	BLRKECMSG14.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 23 Nov 2006 21:59:18 +0530
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [ANCP] Some questions and suggestion on Framework document..
Date: Thu, 23 Nov 2006 21:58:31 +0530
Message-ID: <6031539A3C7B964581EFCE2E205D6EEF0189E625@BLRKECMSG01.ad.infosys.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-topic: [ANCP] Some questions and suggestion on Framework document..
Thread-index: AccO8e9bn57DazJPTWm95k1txjhHIgAKnqes
References: <6031539A3C7B964581EFCE2E205D6EEF0199E13C@BLRKECMSG01.ad.infosys.com>
	<4565855C.6070506@alcatel.be>
From: "bharat_joshi" <bharat_joshi@infosys.com>
To: <Sven.Ooghe@alcatel.be>,
	<ancp@ietf.org>
X-OriginalArrivalTime: 23 Nov 2006 16:29:18.0960 (UTC)
	FILETIME=[86463F00:01C70F1C]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f
Cc: 
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org


Hi Sven,

   Thanks for your reply. Please see my response in line. I have removed=
 those questions/suggestions where we both are in sync.

Thanks & Regards,
Bharat

> * In Introduction, second paragraph, statement 'departments operating
> > the IP network interworking at the management plane is not always
> > possible' is not clear. I think either a comma [,] between 'network'=
 and
> > 'networking' will make it clear or change the statement as follows:
> >=0D
> > 'Interworking at the management plane is not always possible because of
> > the organizational boundaries between departments operating the local
> > loop, departments operating the ATM network and departments operating
> > the IP network'
>=0D
> <Sven>
> We'll use your suggested text.
> </Sven>
>=0D
>=0D
Ok.

> * When these 'Information Reports' are generated? Figure 1 shows that
> > these reports are generated by AN. Are these reports periodically
> > generated? What kind of information is passed through these reports? I
> > did not find any reference to this in the document.
>=0D
> <Sven>
> The Information Reports in Figure 1 indicate messages that are sent by=0D
> the Access Node towards the NAS. The intent was to show the conceptual=0D
> message flow in figure 1. The actual use of these flows depends on the=0D
> use case. For instance, in case of "Dynamic Access Loop Attributes"=0D
> these messages are sent when the DSL Network Termination (DSL modem) is=0D
> turned on, or when the DSL net data rate changes overtime.
> </Sven>
>=0D
>=0D
Actually it would be good if you can add two lines to text explaining about=
 the Information Reports.

> * In section 2.4.1, through we talk about port-addressing schemes but we
> > are not actually referring to ports here. There are configurations=
 where
> > we can have multiple user sessions and 'Circuit-Id' would be different
> > for each one of them. So what I want to say is that we are identifying
> > the circuit instead of ports. So you may want to change the section
> > title to something which reflects the same.
>=0D
> <Sven>
> The intent is indeed to address the logical ports, which could be an ATM=
=0D
> PVC or an Ethernet VLAN on top of a physical DSL port. If we chage the=0D
> text to reflect "Locial port addressing", would that be ok?
> </Sven>
>=0D
>=0D
I am not sure if we can call them a Logical port. Generally, there are=
 different VCs which have different User sessions so it could be called=
 circuit-addressing scheme or something in similar lines.

> * I am trying to understand the need of communicating DSL line data rate
> > to NAS for each user. Does it anyway help in over-subscription on NAS?=
 I
> > can understand that NAS can modify its scheduling parameters for a=
 given
> > user based on the line data rate provided by AN but what is the
> > advantage?
>=0D
> <Sven>
> Have a look at section 2.9, item (3) in TR-101:
> http://www.dslforum.org/techwork/tr/TR-101.pdf
> It describes the rationale for knowing the actual DSL net data rate at=0D
> the level of the NAS. More info can also be found in TR-059.
> </Sven>
>=0D
>=0D
Though this draft refer to TR-101 but as ANCP can be used in not only for=
 DSL environment I would suggest to add some of these details here. This=
 will make sure that people from other type of Access Networks need not go=
 back to TR-101 to understand the need of it.

> * In Access loop configuration, Its mentioned that Access loop
> > configuration is available with the Access provided which controls the
> > DSL line profile in Access Node. Now subscriber wants some changes in
> > it, its mentioned that ANCP can propagate this change without an
> > operator intervention using policy server. My question is if ANCP is
> > down and during this time, a change happens, how would the system=
 react?
> > This change may have happened in the Access Node but NAS may not be
> > aware of this change. Is this correct?
>=0D
> <Sven>
> The assumption we take is that when the use case "Access loop=0D
> configuration" is used, the profile to be used on the access loop will=0D
> be stored in a central policy system. If the ANCP session is down, no=0D
> changes should happen to the access loop configuration.
> If for some reason a change happens, we assume that this translates in a=
=0D
> certain (new) DSL net data rate when the line is operational again. At=0D
> that point, the Access Node will send this information to the NAS, which=
=0D
> can take a corrective action if needed (e.g. change to another profile=0D
> on the Access Node).
> </Sven>
>=0D
>=0D
Please correct me if I am wrong here. I assume that when some particular=
 configuration for a user needs to be changes, it is done in the policy=
 server. NAS picks it up from the policy server and pass it on the Access=
 Node using ANCP. Now when ANCP is down, this is not possible. What I=
 understand from this is if any such configurations that NAS passes to AN=
 using ANCP, will not take any affect until ANCP is down.

So what I meant is that if a user configuration changes when ANCP is down=
 though user would expect the changes to take place immediately, it may not=
 happen.

Please let me know if I am missing something here.

> * Does ANCP require a configuration of 'upstream router port' [interface
> > to reach NAS] in ANs? or does it run a protocols to figure out the
> > interface on which it can reach to the upstream router [NAS]
> > dynamically?
>=0D
> <Sven>
> This aspect is not touched upon in the framework description. The=0D
> assumption we take is that the interface is configured.
> </Sven>
>=0D
>=0D
I think it would be good if we can create a section for Assumptions in the=
 document and add such details there.

> * In section 4.2, point #4. As ANCP is mapped on top of IP, there is not
> > inherent support of reliability, so how do we take care of the
> > reliability here? Do we send the ANCP message multiple times?
>=0D
> <Sven>
> In case ANCP is mapped on top of IP, then the logical consequence is=0D
> that reliability - when needed - must be built into the protocol. How=0D
> that is done will not be described in the framework but is part of the=0D
> protocol specification work.
> Note: we expect these requirements will be significantly reworked in an=0D
> update. It would be good to give it a re-read once we've updated the=0D
> framework.
> </Sven>
>=0D
>=0D
Ok. I shall check this in the next revision of the draft.

> * Section 4.2 does not mention any requirements for authentication
> > before ANCP sessions are created? How do we handle authentication here?
>=0D
> <Sven>
> Good point. Security and authentication are not yet touched upon. Our=0D
> idea at present is to refer to a separate document that would define=0D
> those. draft-moustafa-ancp-security-threats-00.txt provides input on his.
> </Sven>
>=0D
>=0D
I have not read though that document yet. I think you would be adding the=
 reference only when this draft becomes a Working Group Item.

> * In section 4.4.1, how does a logical port treated here? Can a logical
> > port built on top of a physical port be attached to a different
> > partition?
>=0D
> <Sven>
> Our assumption at this point is that all logical ports on top of the=0D
> same physical port will be associated with the same partition. In other=0D
> words, partitioning is performed at the level of the physical port only.
> </Sven>
>=0D
>=0D
Ok. I think it would be a good idea to add this to the new section=
 Assumptions.

> * In section 4.4.6, can we combine multiple ANCP messages in single
> > message? This may help in saving some CPU cycles in AN and NAS.
>=0D
> <Sven>
> Section 4.4.6 sets the high level requirement for this, but does not go=0D
> into the details of how this can be achieved. Combining multiple=0D
> messages into a single message is one way, which is also how it is=0D
> proposed in draft-wadhwa-gsmp-l2control-configuration-02.txt
> </Sven>
>=0D
>=0D
Ok. I am going through this document but still to complete my review. Let=
 me check if this has been addressed here.

> * In section 4.4.7, I think providing configuration for each parameter
> > which can be modified using ANCP, would be a little too much. Though
> > this depends upon the parameters available for configuration but I=
 think
> > it would be good if it is done for a group of parameters. Something=
 like
> > 'Multicast-group', which if enabled can result in modifying certain
> > parameters related to multicast.
>=0D
> <Sven>
> This section needs some reworking/clarification. Having parameter=0D
> control at the granularity of individual parameters may be a bit too=0D
> much. We'll rework the section.
> </Sven>
>=0D
>=0D
Ok. I shall check the same in the next revision of the draft.

> * I think if possible, we should add the security consideration in both
> > Access Node requirements as well as NAS requirements.
>=0D
> <Sven>
> How about referring to a separate security document=0D
> (draft-moustafa-ancp-security-threats-00.txt)? Would that make sense?
> </Sven>
>=0D

I am sure that there are lot of things to consider in the security=
 consideration and a separate document does make sense.

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended=
 solely for the use of the addressee(s). If you are not the intended=
 recipient, please notify the sender by e-mail and delete the original=
 message. Further, you are not to copy, disclose, or distribute this e-mail=
 or its contents to any other person and any such actions are unlawful.=
 This e-mail may contain viruses. Infosys has taken every reasonable=
 precaution to minimize this risk, but is not liable for any damage you may=
 sustain as a result of any virus in this e-mail. You should carry out your=
 own virus checks before opening the e-mail or attachment. Infosys reserves=
 the right to monitor and review the content of all messages sent to or=
 from this e-mail address. Messages sent to or from this e-mail address may=
 be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Fri Nov 24 03:32:04 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GnWTX-0002UH-Md; Fri, 24 Nov 2006 03:31:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GnWTW-0002U8-Hx
	for ancp@ietf.org; Fri, 24 Nov 2006 03:31:58 -0500
Received: from smail.alcatel.fr ([62.23.212.165])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnWTS-0005Qc-Ka
	for ancp@ietf.org; Fri, 24 Nov 2006 03:31:58 -0500
Received: from bemail01.netfr.alcatel.fr (bemail01.netfr.alcatel.fr
	[155.132.251.32])
	by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kAO8Vvd6022635;
	Fri, 24 Nov 2006 09:31:57 +0100
Received: from [172.31.148.94] ([172.31.148.94])
	by bemail01.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163)
	with ESMTP id 2006112409315143:2800 ;
	Fri, 24 Nov 2006 09:31:51 +0100 
Message-ID: <4566ADF4.5060906@alcatel.be>
Date: Fri, 24 Nov 2006 09:31:48 +0100
From: Sven.Ooghe@alcatel.be
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: bharat_joshi <bharat_joshi@infosys.com>, ancp@ietf.org
Subject: Re: [ANCP] Some questions and suggestion on Framework document..
References: <6031539A3C7B964581EFCE2E205D6EEF0199E13C@BLRKECMSG01.ad.infosys.com>
	<4565855C.6070506@alcatel.be>
	<6031539A3C7B964581EFCE2E205D6EEF0189E625@BLRKECMSG01.ad.infosys.com>
In-Reply-To: <6031539A3C7B964581EFCE2E205D6EEF0189E625@BLRKECMSG01.ad.infosys.com>
X-MIMETrack: Itemize by SMTP Server on BEMAIL01/BE/ALCATEL(Release
	5.0.13aHF163 | June 23, 2005) at 11/24/2006 09:31:51,
	Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 | June
	23, 2005) at 11/24/2006 09:31:53,
	Serialize complete at 11/24/2006 09:31:53
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81
X-Spam-Score: 0.2 (/)
X-Scan-Signature: f0ea5880a0890be2408609376fa519aa
Cc: 
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

Hi Bharat,

See inline.

bharat_joshi wrote:
> Hi Sven,
> 
>    Thanks for your reply. Please see my response in line. I have removed those questions/suggestions where we both are in sync.
> 
> Thanks & Regards,
> Bharat
> 
> 
>>* In Introduction, second paragraph, statement 'departments operating
>>
>>>the IP network interworking at the management plane is not always
>>>possible' is not clear. I think either a comma [,] between 'network' and
>>>'networking' will make it clear or change the statement as follows:
>>>
> 
> 
>>>'Interworking at the management plane is not always possible because of
>>>the organizational boundaries between departments operating the local
>>>loop, departments operating the ATM network and departments operating
>>>the IP network'
>>
> 
>><Sven>
>>We'll use your suggested text.
>></Sven>
>>
> 
> 
> Ok.
> 
> 
>>* When these 'Information Reports' are generated? Figure 1 shows that
>>
>>>these reports are generated by AN. Are these reports periodically
>>>generated? What kind of information is passed through these reports? I
>>>did not find any reference to this in the document.
>>
> 
>><Sven>
>>The Information Reports in Figure 1 indicate messages that are sent by
> 
> 
>>the Access Node towards the NAS. The intent was to show the conceptual
> 
> 
>>message flow in figure 1. The actual use of these flows depends on the
> 
> 
>>use case. For instance, in case of "Dynamic Access Loop Attributes"
> 
> 
>>these messages are sent when the DSL Network Termination (DSL modem) is
> 
> 
>>turned on, or when the DSL net data rate changes overtime.
>></Sven>
>>
> 
> 
> Actually it would be good if you can add two lines to text explaining about the Information Reports.

<Sven>
Ok, we'll add a few sentences to explain its purpose.
</Sven>

> 
>>* In section 2.4.1, through we talk about port-addressing schemes but we
>>
>>>are not actually referring to ports here. There are configurations where
>>>we can have multiple user sessions and 'Circuit-Id' would be different
>>>for each one of them. So what I want to say is that we are identifying
>>>the circuit instead of ports. So you may want to change the section
>>>title to something which reflects the same.
>>
> 
>><Sven>
>>The intent is indeed to address the logical ports, which could be an ATM
> 
> 
>>PVC or an Ethernet VLAN on top of a physical DSL port. If we chage the
> 
> 
>>text to reflect "Locial port addressing", would that be ok?
>></Sven>
>>
> 
> 
> I am not sure if we can call them a Logical port. Generally, there are different VCs which have different User sessions so it could be called circuit-addressing scheme or something in similar lines.
> 

<Sven>
I kind of preferred "logical port" since circuit matches the ATM VC, but 
is less appropriate for Ethernet VLAN IDs...

Let me suggest the following: we will change the title to "Circuit 
addressing scheme" and be explicit on what it means in the paragraph 
below, unless someone else on this list argues why not to use this name.
</Sven>

>>* I am trying to understand the need of communicating DSL line data rate
>>
>>>to NAS for each user. Does it anyway help in over-subscription on NAS? I
>>>can understand that NAS can modify its scheduling parameters for a given
>>>user based on the line data rate provided by AN but what is the
>>>advantage?
>>
> 
>><Sven>
>>Have a look at section 2.9, item (3) in TR-101:
>>http://www.dslforum.org/techwork/tr/TR-101.pdf
>>It describes the rationale for knowing the actual DSL net data rate at
> 
> 
>>the level of the NAS. More info can also be found in TR-059.
>></Sven>
>>
> 
> 
> Though this draft refer to TR-101 but as ANCP can be used in not only for DSL environment I would suggest to add some of these details here. This will make sure that people from other type of Access Networks need not go back to TR-101 to understand the need of it.
> 

<Sven>
That's fine.
</Sven>

>>* In Access loop configuration, Its mentioned that Access loop
>>
>>>configuration is available with the Access provided which controls the
>>>DSL line profile in Access Node. Now subscriber wants some changes in
>>>it, its mentioned that ANCP can propagate this change without an
>>>operator intervention using policy server. My question is if ANCP is
>>>down and during this time, a change happens, how would the system react?
>>>This change may have happened in the Access Node but NAS may not be
>>>aware of this change. Is this correct?
>>
> 
>><Sven>
>>The assumption we take is that when the use case "Access loop
> 
> 
>>configuration" is used, the profile to be used on the access loop will
> 
> 
>>be stored in a central policy system. If the ANCP session is down, no
> 
> 
>>changes should happen to the access loop configuration.
>>If for some reason a change happens, we assume that this translates in a
> 
> 
>>certain (new) DSL net data rate when the line is operational again. At
> 
> 
>>that point, the Access Node will send this information to the NAS, which
> 
> 
>>can take a corrective action if needed (e.g. change to another profile
> 
> 
>>on the Access Node).
>></Sven>
>>
> 
> 
> Please correct me if I am wrong here. I assume that when some particular configuration for a user needs to be changes, it is done in the policy server. NAS picks it up from the policy server and pass it on the Access Node using ANCP. Now when ANCP is down, this is not possible. What I understand from this is if any such configurations that NAS passes to AN using ANCP, will not take any affect until ANCP is down.
> 
> So what I meant is that if a user configuration changes when ANCP is down though user would expect the changes to take place immediately, it may not happen.
> 
> Please let me know if I am missing something here.
> 

<Sven>
You're correct. If the ANCP session is down, it cannot be used to change 
some of the Access Node parameters. In this case, the NAS could for 
instance report this to the policy management system which triggered the 
configuration action. The latter could then use application specific 
signaling towards the customer to notify him about the fact that the 
change could not be performed at that time.
</Sven>

>>* Does ANCP require a configuration of 'upstream router port' [interface
>>
>>>to reach NAS] in ANs? or does it run a protocols to figure out the
>>>interface on which it can reach to the upstream router [NAS]
>>>dynamically?
>>
> 
>><Sven>
>>This aspect is not touched upon in the framework description. The
> 
> 
>>assumption we take is that the interface is configured.
>></Sven>
>>
> 
> 
> I think it would be good if we can create a section for Assumptions in the document and add such details there.
> 

<Sven>
I agree that this needs to be added to the document somewhere, either in 
a separate "Assumptions" section, or in one of the existing sections. 
We'll look into this.</Sven>

>>* In section 4.2, point #4. As ANCP is mapped on top of IP, there is not
>>
>>>inherent support of reliability, so how do we take care of the
>>>reliability here? Do we send the ANCP message multiple times?
>>
> 
>><Sven>
>>In case ANCP is mapped on top of IP, then the logical consequence is
> 
> 
>>that reliability - when needed - must be built into the protocol. How
> 
> 
>>that is done will not be described in the framework but is part of the
> 
> 
>>protocol specification work.
>>Note: we expect these requirements will be significantly reworked in an
> 
> 
>>update. It would be good to give it a re-read once we've updated the
> 
> 
>>framework.
>></Sven>
>>
> 
> 
> Ok. I shall check this in the next revision of the draft.
> 
> 
>>* Section 4.2 does not mention any requirements for authentication
>>
>>>before ANCP sessions are created? How do we handle authentication here?
>>
> 
>><Sven>
>>Good point. Security and authentication are not yet touched upon. Our
> 
> 
>>idea at present is to refer to a separate document that would define
> 
> 
>>those. draft-moustafa-ancp-security-threats-00.txt provides input on his.
>></Sven>
>>
> 
> 
> I have not read though that document yet. I think you would be adding the reference only when this draft becomes a Working Group Item.
> 

<Sven>
This is the assumption, yes.
</Sven>

>>* In section 4.4.1, how does a logical port treated here? Can a logical
>>
>>>port built on top of a physical port be attached to a different
>>>partition?
>>
> 
>><Sven>
>>Our assumption at this point is that all logical ports on top of the
> 
> 
>>same physical port will be associated with the same partition. In other
> 
> 
>>words, partitioning is performed at the level of the physical port only.
>></Sven>
>>
> 
> 
> Ok. I think it would be a good idea to add this to the new section Assumptions.
> 

<Sven>
We'll for sure add this to the document. I'm not yet convinced of the 
need for a dedicated "Assumptions" section for this. Are you ok if we 
decide this during updating?
</Sven>

>>* In section 4.4.6, can we combine multiple ANCP messages in single
>>
>>>message? This may help in saving some CPU cycles in AN and NAS.
>>
> 
>><Sven>
>>Section 4.4.6 sets the high level requirement for this, but does not go
> 
> 
>>into the details of how this can be achieved. Combining multiple
> 
> 
>>messages into a single message is one way, which is also how it is
> 
> 
>>proposed in draft-wadhwa-gsmp-l2control-configuration-02.txt
>></Sven>
>>
> 
> 
> Ok. I am going through this document but still to complete my review. Let me check if this has been addressed here.
> 
> 
>>* In section 4.4.7, I think providing configuration for each parameter
>>
>>>which can be modified using ANCP, would be a little too much. Though
>>>this depends upon the parameters available for configuration but I think
>>>it would be good if it is done for a group of parameters. Something like
>>>'Multicast-group', which if enabled can result in modifying certain
>>>parameters related to multicast.
>>
> 
>><Sven>
>>This section needs some reworking/clarification. Having parameter
> 
> 
>>control at the granularity of individual parameters may be a bit too
> 
> 
>>much. We'll rework the section.
>></Sven>
>>
> 
> 
> Ok. I shall check the same in the next revision of the draft.
> 
> 
>>* I think if possible, we should add the security consideration in both
>>
>>>Access Node requirements as well as NAS requirements.
>>
> 
>><Sven>
>>How about referring to a separate security document
> 
> 
>>(draft-moustafa-ancp-security-threats-00.txt)? Would that make sense?
>></Sven>
>>
> 
> 
> I am sure that there are lot of things to consider in the security consideration and a separate document does make sense.

<Sven>
Ok, great. BTW some weeks ago, the chairs issued a call for review of 
draft-moustafa-ancp-security-threats-00.txt and whether or not people 
support this draft becoming a working group ID.
</Sven>

Regards,
Sven

> 
> **************** CAUTION - Disclaimer *****************
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
> 

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Fri Nov 24 04:03:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GnWxY-0000Ac-C6; Fri, 24 Nov 2006 04:03:00 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GnWxX-0000AV-Ab
	for ancp@ietf.org; Fri, 24 Nov 2006 04:02:59 -0500
Received: from kecgate02.progeon.com ([61.95.162.76]
	helo=Kecgate02.infosys.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnWxU-0002xG-PY
	for ancp@ietf.org; Fri, 24 Nov 2006 04:02:59 -0500
Received: from INDHUBBHS02.ad.infosys.com ([192.168.200.82]) by
	Kecgate02.infosys.com with InterScan Messaging Security Suite;
	Fri, 24 Nov 2006 14:26:49 +0530
Received: from BLRKECMSG04.ad.infosys.com ([172.25.213.134]) by
	INDHUBBHS02.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 24 Nov 2006 14:30:36 +0530
Received: from BLRKECMSG01.ad.infosys.com ([172.25.213.131]) by
	BLRKECMSG04.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 24 Nov 2006 14:30:35 +0530
Received: from osfr-170.local ([192.168.101.134]) by
	BLRKECMSG01.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 24 Nov 2006 14:30:35 +0530
Subject: Re: [ANCP] Some questions and suggestion on Framework document..
From: Bharat Joshi <bharat_joshi@infosys.com>
To: Sven.Ooghe@alcatel.be
In-Reply-To: <4566ADF4.5060906@alcatel.be>
References: <6031539A3C7B964581EFCE2E205D6EEF0199E13C@BLRKECMSG01.ad.infosys .com>
	<4565855C.6070506@alcatel.be>
	<6031539A3C7B964581EFCE2E205D6EEF0189E625@BLRKECMSG01.ad.infosys.com>
	<4566ADF4.5060906@alcatel.be>
Content-Type: text/plain
Organization: Infosys Technologies Ltd
Date: Fri, 24 Nov 2006 14:25:51 +0530
Message-Id: <1164358552.2656.35.camel@magadha>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 Nov 2006 09:00:35.0712 (UTC)
	FILETIME=[012E6000:01C70FA7]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610
Cc: ancp@ietf.org
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org


Hi Sven,

   Thanks for your reply. Please see my response in line. I have removed
those questions/suggestion where we both are in sync.

Thanks,
Bharat

> >>* In section 2.4.1, through we talk about port-addressing schemes but we
> >>
> >>>are not actually referring to ports here. There are configurations where
> >>>we can have multiple user sessions and 'Circuit-Id' would be different
> >>>for each one of them. So what I want to say is that we are identifying
> >>>the circuit instead of ports. So you may want to change the section
> >>>title to something which reflects the same.
> > 
> >><Sven>
> >>The intent is indeed to address the logical ports, which could be an ATM 
> >>PVC or an Ethernet VLAN on top of a physical DSL port. If we chage the
> >>text to reflect "Locial port addressing", would that be ok?
> >></Sven>
> >>
> > I am not sure if we can call them a Logical port. Generally, there are different VCs which have different User sessions so it could be called circuit-addressing scheme or something in similar lines.
> > 
> <Sven>
> I kind of preferred "logical port" since circuit matches the ATM VC, but 
> is less appropriate for Ethernet VLAN IDs...
> 
> Let me suggest the following: we will change the title to "Circuit 
> addressing scheme" and be explicit on what it means in the paragraph 
> below, unless someone else on this list argues why not to use this name.
> </Sven>
> 

Sounds good to me.

> >>* I am trying to understand the need of communicating DSL line data rate
> >>
> >>>to NAS for each user. Does it anyway help in over-subscription on NAS? I
> >>>can understand that NAS can modify its scheduling parameters for a given
> >>>user based on the line data rate provided by AN but what is the
> >>>advantage?
> > 
> >><Sven>
> >>Have a look at section 2.9, item (3) in TR-101:
> >>http://www.dslforum.org/techwork/tr/TR-101.pdf
> >>It describes the rationale for knowing the actual DSL net data rate at
> >>the level of the NAS. More info can also be found in TR-059.
> >></Sven>
> > 
> > Though this draft refer to TR-101 but as ANCP can be used in not only for DSL environment I would suggest to add some of these details here. This will make sure that people from other type of Access Networks need not go back to TR-101 to understand the need of it.
> > 
> 
> <Sven>
> That's fine.
> </Sven>
> 

Ok.

> >>* In Access loop configuration, Its mentioned that Access loop
> >>
> >>>configuration is available with the Access provided which controls the
> >>>DSL line profile in Access Node. Now subscriber wants some changes in
> >>>it, its mentioned that ANCP can propagate this change without an
> >>>operator intervention using policy server. My question is if ANCP is
> >>>down and during this time, a change happens, how would the system react?
> >>>This change may have happened in the Access Node but NAS may not be
> >>>aware of this change. Is this correct?
> >
> >><Sven>
> >>The assumption we take is that when the use case "Access loop 
> >>configuration" is used, the profile to be used on the access loop will
> >>be stored in a central policy system. If the ANCP session is down, no
> >>changes should happen to the access loop configuration.
> >>If for some reason a change happens, we assume that this translates in a
> >>certain (new) DSL net data rate when the line is operational again. At
> >>that point, the Access Node will send this information to the NAS, which
> >>can take a corrective action if needed (e.g. change to another profile
> >>on the Access Node).
> >></Sven>

> Please correct me if I am wrong here. I assume that when some
> particular configuration for a user needs to be changes, it is done in
> >the policy server. NAS picks it up from the policy server and pass it
> >on the Access Node using ANCP. Now when ANCP is down, this is not
> >possible. What I understand from this is if any such configurations
> >that NAS passes to AN using ANCP, will not take any affect until ANCP
> >is down.
> > So what I meant is that if a user configuration changes when ANCP is
> down though user would expect the changes to take place immediately,
> it may not happen.
> > 
> > Please let me know if I am missing something here.
> 
> <Sven>
> You're correct. If the ANCP session is down, it cannot be used to change 
> some of the Access Node parameters. In this case, the NAS could for 
> instance report this to the policy management system which triggered the 
> configuration action. The latter could then use application specific 
> signaling towards the customer to notify him about the fact that the 
> change could not be performed at that time.
> </Sven>
> 

If a user wants his bandwidth to be increased and ANCP is down, this may
take some time to happen. So I feel it need to be mentioned here.

> >>* Does ANCP require a configuration of 'upstream router port' [interface
> >>
> >>>to reach NAS] in ANs? or does it run a protocols to figure out the
> >>>interface on which it can reach to the upstream router [NAS]
> >>>dynamically?
> >>
> >><Sven>
> >>This aspect is not touched upon in the framework description. The
> >>assumption we take is that the interface is configured.
> >></Sven>
> >>
> > I think it would be good if we can create a section for Assumptions in the document and add such details there. 
> <Sven>
> I agree that this needs to be added to the document somewhere, either in 
> a separate "Assumptions" section, or in one of the existing sections. 
> We'll look into this.</Sven>
> 

Ok.

> >>* In section 4.4.1, how does a logical port treated here? Can a logical
> >>
> >>>port built on top of a physical port be attached to a different
> >>>partition?
> >>
> > 
> >><Sven>
> >>Our assumption at this point is that all logical ports on top of the 
> >>same physical port will be associated with the same partition. In other
> >>words, partitioning is performed at the level of the physical port only.
> >></Sven>
> >>
> > Ok. I think it would be a good idea to add this to the new section Assumptions.
> > 
> <Sven>
> We'll for sure add this to the document. I'm not yet convinced of the 
> need for a dedicated "Assumptions" section for this. Are you ok if we 
> decide this during updating?
> </Sven>
> 

Yes. That should be fine.

> >><Sven>
> >>How about referring to a separate security document
> > 
> > 
> >>(draft-moustafa-ancp-security-threats-00.txt)? Would that make sense?
> >></Sven>
> >>
> > 
> > 
> > I am sure that there are lot of things to consider in the security consideration and a separate document does make sense.
> 
> <Sven>
> Ok, great. BTW some weeks ago, the chairs issued a call for review of 
> draft-moustafa-ancp-security-threats-00.txt and whether or not people 
> support this draft becoming a working group ID.
> </Sven>

Ok. I shall take a look at this document and pass on my comments to
author if I have any.


**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Fri Nov 24 08:39:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GnbGc-0004lv-U4; Fri, 24 Nov 2006 08:38:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GnbGb-0004kT-2O
	for ancp@ietf.org; Fri, 24 Nov 2006 08:38:57 -0500
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnbGW-0004eH-PM
	for ancp@ietf.org; Fri, 24 Nov 2006 08:38:57 -0500
Received: from ams-dkim-2.cisco.com ([144.254.224.139])
	by ams-iport-1.cisco.com with ESMTP; 24 Nov 2006 14:38:52 +0100
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150])
	by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAODcpxV015277; 
	Fri, 24 Nov 2006 14:38:51 +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.12.10/8.12.6) with ESMTP id kAODcpwv005327; 
	Fri, 24 Nov 2006 14:38:51 +0100 (MET)
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); 
	Fri, 24 Nov 2006 14:38:51 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C70FCD.E05BCA67"
Date: Fri, 24 Nov 2006 14:38:25 +0100
Message-ID: <D9872168DBD43A41BD71FFC4713274D402B65CAC@xmb-ams-33b.emea.cisco.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: IETF67 - ANCP WG Meeting Minutes
Thread-Index: AccPzH2BtM1aWQUQToSFPsMmOawLZA==
From: "Wojciech Dec \(wdec\)" <wdec@cisco.com>
To: <ancp@ietf.org>
X-OriginalArrivalTime: 24 Nov 2006 13:38:51.0439 (UTC)
	FILETIME=[E09C23F0:01C70FCD]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=31852; t=1164375531;
	x=1165239531; c=relaxed/simple; s=amsdkim2001;
	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<wdec@cisco.com>
	|Subject:=20IETF67=20-=20ANCP=20WG=20Meeting=20Minutes
	|Sender:=20; bh=RYD/zzt8ezkdBWD19gHy425GGopqPPeFrHyEPp8qy4w=;
	b=tx9x7QoF34uzCkr6batQqO51KO+eSUyLfcLjGDJ4r7nT2dgVm1R15lwEu43kUavtZ8ftUirf
	40ZqMhH935aMfdj19BM35ulxL53N+p0HdHUhRbPVQh9R/qP3VYQ/DMGc;
Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass (s
	ig from cisco.com/amsdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 32604d42645517c44d778f1d111b40a6
Cc: Matthew.Bocci@alcatel.co.uk
Subject: [ANCP] IETF67 - ANCP WG Meeting Minutes
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

This is a multi-part message in MIME format.

------_=_NextPart_001_01C70FCD.E05BCA67
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C70FCD.E05BCA67"


------_=_NextPart_002_01C70FCD.E05BCA67
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All,

Attached please find the IETF67 ANCP WG meeting minutes. May thanks to
all those that participated, and in particular to our scribe for taking
it all down.

As usual, if anyone has comments/additions, please let Matthew and
myself know.

Regards,
Woj.
 <<ancp_67-ancp-minutes.txt>>=20


------_=_NextPart_002_01C70FCD.E05BCA67
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7638.1">
<TITLE>IETF67 - ANCP WG Meeting Minutes</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi All,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Attached please find the IETF67 ANCP WG =
meeting minutes. May thanks to all those that participated, and in =
particular to our scribe for taking it all down.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">As usual, if anyone has =
comments/additions, please let Matthew and myself know.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Woj.</FONT>

<BR><FONT FACE=3D"Arial" SIZE=3D2 COLOR=3D"#000000"> =
&lt;&lt;ancp_67-ancp-minutes.txt&gt;&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_002_01C70FCD.E05BCA67--

------_=_NextPart_001_01C70FCD.E05BCA67
Content-Type: text/plain;
	name="ancp_67-ancp-minutes.txt"
Content-Transfer-Encoding: base64
Content-Description: ancp_67-ancp-minutes.txt
Content-Disposition: attachment;
	filename="ancp_67-ancp-minutes.txt"

SUVURiA2NywgQU5DUCBXRyBNZWV0aW5nIG1pbnV0ZXMuIFRIVVJTREFZLCBOb3ZlbWJlciA5dGgs
IDIwMDY6IDEzOjAwIC0gMTU6MDANCkNIQUlSUzogV29qY2llY2ggRGVjICYgTWF0dGhldyBCb2Nj
aQ0KDQpBR0VOREE6DQotLS0tLS0tLS0tLS0tLS0tDQoNCjE1IG1pbnMgLSBBZG1pbmlzdHJpdmlh
LCBXRyBTdGF0dXMgYW5kIFdHIERvY3MgVXBkYXRlIC0gQ2hhaXJzDQoNCjUgbWlucyBEU0wgRm9y
dW0gTGlhaXNvbiAtIFdvamNpZWNoIERlYyAod2RlY0BjaXNjby5jb20pDQpodHRwczovL2RhdGF0
cmFja2VyLmlldGYub3JnL2RvY3VtZW50cy9MSUFJU09OL2ZpbGUzNzUuZG9jDQpodHRwczovL2Rh
dGF0cmFja2VyLmlldGYub3JnL2RvY3VtZW50cy9MSUFJU09OL2ZpbGUzNzYuZG9jDQoNCjEwIG1p
bnMgLSBBTkNQIFJlcXVpcmVtZW50cyAvIEZyYW1ld29yayAtIFN0ZWZhYW4gZGUgQ25vZGRlciAN
CihzdGVmYWFuLmRlX2Nub2RkZXJAYWxjYXRlbC5iZSkNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50
ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtYW5jcC1mcmFtZXdvcmstMDAudHh0DQoNCjE1IG1pbnMg
LSBBTkNQIEFjZXNzIE5vZGUgTUlCcyAtIFN0ZWZhYW4gZGUgQ25vZGRlciANCihzdGVmYWFuLmRl
X2Nub2RkZXJAYWxjYXRlbC5iZSkNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz
L2RyYWZ0LWRlY25vZGRlci1hbmNwLW1pYi1hbi0wMC50eHQNCg0KMTUgbWlucyAtIEFOQ1AgU2Vj
dXJpdHkgVGhyZWF0cyBhbmQgUmVxdWlyZW1lbnRzIC0gSGFzc25hYSBNb3VzdGFmYSANCihoYXNz
bmFhLm1vdXN0YWZhQG9yYW5nZS1mdGdyb3VwLmNvbSkNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50
ZXJuZXQtZHJhZnRzL2RyYWZ0LW1vdXN0YWZhLWFuY3Atc2VjdXJpdHktdGhyZWF0cy0wMC50eHQN
Cg0KMTUgbWlucyAtIEFOQ1AgUHJvdG9jb2wgRHJhZnQgLSBTYW5qYXkgV2FkaHdhIChzd2FkaHdh
QGp1bmlwZXIubmV0KQ0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt
d2FkaHdhLWdzbXAtbDJjb250cm9sLWNvbmZpZ3VyYXRpb24tDQowMi50eHQNCg0KMTUgbWlucyAt
IENvbnRyb2wgUGxhbmUgR3JhY2VmdWwgUmVzdGFydCBleHRlbnNpb25zIGZvciBBTkNQIC0gU2Fu
amF5IFdhZGh3YSANCihzd2FkaHdhQGp1bmlwZXIubmV0KQ0KaHR0cDovL3d3dy5pZXRmLm9yZy9p
bnRlcm5ldC1kcmFmdHMvZHJhZnQtd2FkaHdhLWFuY3AtZ3JhY2VmdWwtcmVzdGFydC0wMC50eHQN
Cg0KDQpNRUVUSU5HIE1JTlVURVM6DQotLS0tLS0tLS0tLS0tLS0tDQoNCkNoYWlyczogUmVtb3Zl
ICJDb250cm9sIFBsYW5lIEdyYWNlZnVsIFJlc3RhcnQiIGFnZW5kYSBpdGVtLg0KDQpNYXR0aGV3
IC0gbWlsZXN0b25lcy4gIFdpbGwgbmVlZCB0byBhZGQgc29tZSBmb3IgR3JhY2VmdWwgUmVzdGFy
dCBhbmQgb3RoZXIgbmV3IHdvcmsgaXRlbXMuDQoNCmJyaWVmIHJldmlldyBvZiB3aGVyZSB3ZSdy
ZSBhdCB3aXRoIGNoYXJ0ZXIgaXRlbXMuDQoNCkRTTCBmb3J1bSBsaWFpc29uLiAgdHdvIGRvY3Mg
b24gZGF0YXRyYWNrZXIuDQoNCldvaiAtIERTTCBmb3J1bSBiYXNpY2FsbHkgc2F5aW5nIHRoYXQg
dGhleSdyZSBmb2xsb3dpbmcgdGhlIFdHLCBhbmQgaGF2ZSBhbHNvIHBhc3NlZCBvdmVyIHRoZSBX
VC0xNDcgYW5kIEwyQ1AgdXNlIGNhc2UuICBUaGVpciBkb2NzIGFyZSBtdWNoIGxpa2Ugb3VyIHJl
cXMvZnJhbWV3b3JrIGJ1dCBoYXZlIG1vcmUgaW4gdGVybXMgb2YgcmVxcyBvbiBEU0xBTS4gIE5l
eHQgRFNMIGZvcnVtIG1lZXQgaXMgQXRsYW50YSBEZWMgMTEtMTQuICBEU0wgRm9ydW0gbWVtYmVy
cyBzaG91bGQgZmVlbCB0aGVtc2VsdmVzIGludml0ZWQgdG8gYXR0ZW5kLg0KDQpEYXZlIEFsbGVu
IC0gZmVlZGJhY2sgb24gV1QtMTQ3IGZvcm0gSUVURiBXRyBpcyBzb2xpY2l0ZWQuICBTZWVtcyB0
byBiZSBkZXZpYXRpbmcgZnJvbSB3aGF0J3MgZ29pbmcgb24gaGVyZSBhbmQgaXQgY291bGQgYmUg
aW1wcm92ZWQuDQoNCk1hdHRoZXcgLSBwbGVhc2UgcG9zdCBjb21tZW50cyB0byBBTkNQIGxpc3Qg
YW5kIHdlJ2xsIGRvIGEgbGlhaXNvbiBiYWNrIHRvIERTTCBGb3J1bS4gIENvdWxkIHlvdSBwbGVh
c2UgY29tbWVudCBpbiBuZXh0IDIgd2Vla3MgKGdpdmVuIHNob3J0IHRpbWVmcmFtZSBiZWZvcmUg
RFNMRiBtZWV0aW5nKS4NCg0KDQpTdGVmYWFuIC0gQU5DUCBGcmFtZXdvcmsgJiBSZXF1aXJlbWVu
dHMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpoaXN0b3J5IGZy
b20gTDJDUCBCb0YvZmlyc3QgQU5DUCBXRy4gIEJlY2FtZSBXRyBkcmFmdCBhdCBNb250cmVhbCBz
byByZXN1Ym1pdHRlZCBhcyBXRyBkb2Mgd2l0aCBzb21lIHRlcm1pbm9sb2d5IGNoYW5nZXMgZXRj
LiAodGhvdWdoIHNvbWUgc2VjdGlvbnMgc3RpbGwgaW5jb3JyZWN0IC0gc28gd2lsbCBiZSBmaXhl
ZCBpbiBuZXh0IHZlcnNpb24pLg0KDQpkZWZpbml0aW9ucyBhZGRlZCBmb3IgTmV0IERhdGEgUmF0
ZSAoZXhjbHVkZXMgcGh5c2ljYWwgbGF5ZXIgb3ZlcmhlYWQpIGFuZCBMaW5lIFJhdGUgKGluY2x1
ZGVzIG92ZXJoZWFkKSwgQWNjZXNzIE5vZGUgQ29udHJvbCBNZWNoYW5pc20gKHdlcmUgdXNpbmcg
dGVybSB3aXRob3V0IHVzaW5nIGl0KSwgQ29udHJvbCBDaGFubmVsIChkaWZmZXJlbnQgbmFtZSBi
ZWZvcmUgYnV0IGFsc28gd2Fzbid0IGRlZmluZWQpLg0KDQpjaGFuZ2VzIHRvIEFjY2VzcyBOb2Rl
IHJlcXVpcmVtZW50cyAtIGtleSBvbmUgaXMgaWRlbnRpZmljYXRpb24gb2YgQU4gYW5kIGFjY2Vz
cyBwb3J0IChtdXN0IGJlIHNhbWUgaW4gQU5DUCwgUFBQb0UgYW5kIERIQ1ApLiAgQWxzbyBub3cg
c2F5IHRoYXQgbXVzdCBiZSByb3V0ZWQgZW5jYXBzIGlmIHJ1bm5pbmcgb3ZlciBBVE0uDQoNCk5B
UyByZXF1aXJlbWVudHMgLSBuZXcgc2VjdGlvbi4gIHdob2xlc2FsZSBtb2RlbCBzdXBwb3J0cyBO
QVMgYWN0aW5nIGFzIGEgTEFDLg0KDQpuZWVkIHRvIGZpbmFsaXNlIG11bHRpY2FzdCB1c2UgY2Fz
ZSwgZmlsbCBpbiB0aGUgZW1wdHkgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiAoYW5v
dGhlciBkcmFmdCBoYXMgaW5mbyBzbyBtYXkganVzdCByZWZlcmVuY2UpLg0KDQpjb21tZW50cyBm
cm9tIFdvaiwgYnV0IHdvdWxkIGxpa2UgbW9yZSBjb21tZW50cyBmcm9tIFdHLg0KDQpXb2ogKHdp
dGggY2hhaXIgaGF0IG9mZikgLSBzZWVtcyBsaWtlIG1vc3QgcmVxcyBzaG91bGQgYmUgcmVsYXRl
ZCB0byBwcm90b2NvbCwgYnV0IHdpdGggdGhyZWF0IGFuYWx5c2lzIGV0Yy4gd291bGQgYmUgZ29v
ZCB0byBwcm92aWRlIHNvbWUgZnJhbWV3b3JrIGFzIHRvIHdoYXQgaXMgdGhlIGV4cGVjdGVkIHVz
ZSBvZiB0aGUgZGV2aWNlcywgbG9jYXRpb24sIGV0Yy4gIChzbyBoYXZlIGJvdW5kYXJ5L2ludGVu
ZGVkIHVzZSBwaWN0dXJlKS4gIG5vdCBzdXJlIGhvdyBtdWNoIHZhbHVlIHRoZXJlIGlzIGluIGRl
c2NyaWJpbmcgbm9kZSBmdW5jdGlvbmFsaXR5IHJhdGhlciB0aGFuIHRoZSBBTkNQIHByb3RvY29s
IChlLmcuIGN1cnJlbnRseSBzYXlzIHNob3VsZCBzZW5kIFNOTVAgdHJhcHMgZm9sbG93aW5nIGFk
amFjZW5jeSBjaGFuZ2UpLg0KDQpXb2ogKGFzIGNoYWlyKSAtIHdvdWxkIGxpa2UgZmVlZGJhY2sg
b24gaG93IG11Y2ggd2Ugc2hvdWxkIGlkZW50aWZ5IHJlcXVpcmVtZW50cyBmb3IgZGV2aWNlcyB2
cyByZXF1aXJlbWVudHMgZm9yIHByb3RvY29sLg0KDQoNCkhhc3NuYWEgLSBMQUMgc2VuZHMgUW9T
IGluZm8gZXRjLiB0byBMTlMuICBJcyB0aGVyZSBhbnkgaW50ZXJhY3Rpb24gYmV0d2VlbiBBTkNQ
IGFuZCBMMlRQPyAgSXMgdGhhdCBpbiBvciBvdXQgb2Ygc2NvcGU/DQoNClN0ZWZhYW4gLSBzaG91
bGQgYmUgaW4gc2NvcGUuICB3aGV0aGVyIGRvbmUgdmlhIEFOQ1Agb3Igc29tZXRoaW5nIGVsc2Ug
aXQgb3VnaHQgdG8gYmUgYWRkZWQgdG8gZG9jcy4NCg0KTWFyayBUb3duc2xleSAtIGNvdWxkIHdv
cmsgd2l0aCBMMlRQIG1haWxpbmcgbGlzdC4gIEwyVFAgZG9lc24ndCBtZWV0IGFueSBtb3JlIGJ1
dCBtYWlsLWxpc3QgaXMgYWN0aXZlIGFuZCBjaGFpcnMgYXJlIGdvb2QuLg0KDQpXb2ogLSBhIG51
bWJlciBvZiB2ZW5kb3JzIGhhdmUgZ290IHRvZ2V0aGVyIHRvIGRyYWZ0IGEgZG9jIGJ1dCBub3Qg
c2VudCBpdCB0byBMMlRQIG1haWxpbmcgbGlzdCB5ZXQuDQoNClRob21hcyAoVC1TeXN0ZW1zKSAt
IHJlZ2FyZGluZyByZXFzIGZvciBlbGVtZW50cyBuZWVkIHRvIGJlIGNsZWFyIGUuZy4gd2hhdCBz
Y2FsYWJpbGl0eSByZXF1aXJlbWVudHMgYXJlICgxMDBzLCBvciAxMDAwcyBvZiBub2Rlcz8pLiAg
TmVlZCB0byBjb25zaWRlciB0aGlzIGluIHRoZSBmcmFtZXdvcmsgYXMgdG8gd2hpY2ggZW52aXJv
bm1lbnQgdGhlIHByb3RvY29sIHNob3VsZCBiZSBpbXBsZW1lbnRlZCBpbi4gIGUuZy4gd2hhdCB3
b3JrcyB3aXRoIDEwMHMgb2Ygbm9kZXMgd29uJ3QgbmVjZXNzYXJpbHkgd29yayBmb3IgYSBsYXJn
ZSBuZXR3b3JrLg0KDQpXb2ogLSB5ZXMgd2UgbmVlZCBhIHBpY3R1cmUgYXMgdG8gd2hlcmUgQU5D
UCBzaG91bGQgYmUgZGVwbG95ZWQsIGJ1dCBzdG9wIHNob3J0IG9mIHJlcXVpcmluZyB0aGluZ3Mg
c3VjaCBhcyAic2VuZCBhbiBTTk1QIHRyYXAiDQoNClNhbmpheSAtIG9uZSBjbGFyaWZpY2F0aW9u
LiAgdGhpcyBpcyBmcmFtZXdvcmsgZG9jLiAgQnV0IHdoZXJlIGhhcyBkZXRhaWxzIG9mIHJlcXMg
YXJlIHdlIHRoaW5raW5nIG9mIGRvaW5nIGEgbmV3IGRvYywgb3IgaXMgdGhpcyBvbmUgZ29pbmcg
dG8gYmUgY29tcHJlaGVuc2l2ZS4NCg0KV29qIC0gSSBhc2tlZCBteXNlbGYgdGhlIHNhbWUgcXVl
c3Rpb25zIHdoZW4gcmVhZCBpdCAoY29tbWVudGVkIGFzIGlmIHdhcyBwcm90b2NvbCByZXF1aXJl
bWVudHMgYnV0IHRpdGxlIHNheXMgZnJhbWV3b3JrKS4NCg0KU2FuamF5IC0gZG8gd2Ugd2FudCB0
byBzZXBhcmF0ZT8gIElmIGlzIHJlcXMgdGhlbiBzb21lIHRoaW5ncyBtYWtlIHNlbnNlLg0KDQpT
YW5qYXkgLSBhbHNvIHJlcXVpcmVtZW50cyBzZWVtIHRvIGNvbWUgc3RyYWlnaHQgZnJvbSBXVC0x
NDcgc28gc2hvdWxkIGhhdmUgcmVmZXJlbmNlDQoNClN0ZWZhYW4gLSB5ZXMuDQoNCg0KTWljaGFl
bCBSYW1hbGhvIChDaXNjbykgLSBzZWVtcyBsaWtlIHRoZSBlbmRzIHlvdSdyZSB0cnlpbmcgdG8g
YWNoaWV2ZSBhcmUgd2VsbCBjb21tdW5pY2F0ZWQgdmlhIHBvbGljeSBsYW5ndWFnZS4gIFNvIHdo
YXQgeW91IG5lZWQgZm9yIGEgcGFydGljdWxhciBhcHAgKGUuZy4gRFNMIGFnZ3JlZ2F0aW9uKSBj
YW4gYmUgZGVmaW5lZCBpbiB0ZXJtcyBvZiBwb2xpY3kgbGFuZ3VhZ2UuICBFLmcuIHNhdGVsbGl0
ZSBjYXNlcyB3aGVyZSBpZiB5b3UgdXNlIHRvbyBtdWNoIGJhbmR3aWR0aCBjb25zaXN0ZW50bHkg
dGhlbiB5b3UgZ2V0IHRocm90dGxlZC4gIFRoYXQgY2FuIGJlIGV4cHJlc3NlZCBpbiB0aGUgc2No
ZW1hIHRoYXQgaXMgdXNlZCBmb3IgdGhhdCBhY2Nlc3MgdG9wb2xvZ3kuICBXaGVuIEkgcmVhZCB0
aGlzIGRvYyBJIHNlZSBhbiBhcHBhcmVudCBhdHRlbXB0IHRvIGNoYXJhY3Rlcml6ZSByZXFzIGdp
dmVuIGEgY2VydGFpbiBmcmFtZXdvcmsgdGhlIGF1dGhvcnMgY2FtZSBmcm9tIGluIHRoZSBEU0wg
d29ybGQgYW5kIHRyeWluZyB0byBwdXQgdGhhdCBpbnRvIHRoZSByZXF1aXJlbWVudHMgZG9jLiAg
Tm90IHN1cmUgdGhhdCBzaG91bGQgcHV0IHRoZSBhYmlsaXRpZXMgeW91IHdhbnQgdG8gc2lnbmFs
IHRoZXJlLiAgVGhleSBzaG91bGQgYmUgZXhwcmVzc2VkIGluIGEgcG9saWN5IGxhbmd1YWdlLiAg
IElzIHRoZSBvdXRwdXQgb2YgdGhpcyB3b3JrIGlucHV0IHRvIGEgc2V0IG9mIHNjaGVtYSBmb3Ig
YSBwb2xpY3kgbGFuZ3VhZ2UsIG9yIGFyZSB5b3Ugbm90IHRoaW5raW5nIG9mIGEgY29tbW9uIGlu
Zm9ybWF0aW9uIG1vZGVsLg0KDQpTdGVmYWFuIC0gdGhlIGZyYW1ld29yayBkb2Mgc2F5cyB0aGF0
IHRoZSBOQUMgY2FuIGludGVyYWN0IHdpdGggYSBwb2xpY3kgc2VydmVyIGJ1dCBkb2Vzbid0IGdp
dmUgbWFueSBkZXRhaWxzLiAgVGhlIE5BUyBjYW4gZ2V0IHBvbGljeSBpbmZvIGZyb20gc2VydmVy
IGFuZCB0aGVuIHVzZSBBTkNQIHRvIGVuZm9yY2UgdGhhdCBpbiB0aGUgRFNMQU0uICBTbyB0aGVy
ZSBpcyBpbnRlcmFjdGlvbiBidXQgZG9uJ3Qgc2VlIEFOQ1AgYXMgYmVpbmcgaW5wdXQgdG8gcG9s
aWN5IHdvcmsuDQoNCk1pY2hhZWwgLSBpZiB5b3UgbG9vayBhdCBvdGhlciBhY2Nlc3MgYXJyYW5n
ZW1lbnRzIHRoYW4gdGhvc2UgaW4gdGhlIGRvYyB5b3UgZG9uJ3QgaGF2ZSB0aGVtIGNvdmVyZWQg
LSBwcm9iYWJseSBkb24ndCBoYXZlIHBlb3BsZSBwYXJ0aWNpcGF0aW5nLiAgQ29uZnVzZWQgYXMg
dG8gd2hldGhlciB0aGlzIGRvYyBpcyBmb3IgYWxsIGFjY2VzcyBuZXR3b3Jrcz8NCg0KTWF0dGhl
dyAtIGluaXRpYWwgc2NvcGUgaXMgRFNMIGFjY2VzcyBuZXR3b3Jrcy4gYnV0IG5vdCB0byBzYXkg
dGhhdCB3ZSBjYW4ndCBleHBhbmQgaXQuICBvcmlnaW5hbCBXRyBzY29wZSB3YXMgRFNMLg0KDQpU
b2VybGVzcyAtIGRvIHlvdSBzZWUgYW55IHByb2JsZW0gaW4gbWFraW5nIHRoaXMgYXBwbGljYWJs
ZSB0byBvdGhlciB0ZWNoIGFyZWFzIGJ5IHVzaW5nIGEgZm9ybSBvZiBleHRlbnNpYmxlL2ZsZXhp
YmxlIHByZXNlbnRhdGlvbiBsYXllcg0KDQpNaWNoYWVsIC0geWVhaCwgdGhlIHBvbGljeSBsYW5n
dWFnZSBwZW9wbGUgZG9uJ3QgdXNlIHRob3NlIGtpbmQgb2Ygd29yZHMuICBUaGUgdGhpbmdzIHlv
dSB3YW50IHRvIHNpZ25hbCAoc2hhcGluZywgbXVsdGljYXN0LCB0aW1lIG9mIGRheSByb3V0aW5n
IGV0YykgZ2V0IGVtYm9kaWVzIGluIHRoZSBzY2hlbWEgb2YgdGhlIGxhbmd1YWdlIGFuZCBub3Qg
aW4gdGhlIHJlcXVpcmVtZW50cyBkb2MgZm9yIGEgc2lnbmFsaW5nIHByb3RvY29sLiAgSWYgeW91
IHNpZ25hbGVkIHRob3NlIHRoaW5ncyB3aXRoIGEgcG9saWN5IGxhbmd1YWdlIHRoZW4gdGhlc2Ug
dGhpbmdzIHdvdWxkIGJlIHJlcXVpcmVtZW50cyBmb3IgdGhlIHNjaGVtYS4NCg0KVG9lcmxlc3Mg
LSBkbyB3ZSB3YW50IHRvIGRlZmluZSBhIHByb3RvY29sIHRoYXQgaXMganVzdCBhIGNhcnJpZXIg
Zm9yIHBvbGljaWVzIHRoYXQgd2UgZG9uJ3Qgd2FudCB0byBzcGVjaWZ5LCBvciBkbyB3ZSB3YW50
IHRvIG5haWwgZG93biBhIHNlcnZpY2UgYW5kIHRoZSBwcm90b2NvbCBpcyBwYXJ0IG9mIHRoYXQu
ICBvZiBjb3Vyc2UgdGhlcmUgaXMgYSBwcm9ibGVtIGluIHRlcm1zIG9mIGhvdyBmYXIgaXQgc2hv
dWxkIGdvLiAgQnV0IGp1c3QgZGVmaW5pbmcgcHJvdG9jb2wgd2l0aG91dCBtYW5kYXRpbmcgd2hh
dCBoYXMgdG8gaGFwcGVuIGluIEJSQVMgYW5kIERTTEFNcyB3b24ndCBnZXQgdXMgd2hlcmUgd2Ug
d2FudCB0byBnby4NCg0KTWljaGFlbCAtIEkgdGhpbmsgdGhhdCBhY3R1YWxseSB0aGUgZ29hbHMg
eW91J3JlIGFpbWluZyBhdCBjb3VsZCBiZSBlbWJvZGllZCBpbiBhIHNjaGVtYSBpZiB5b3UnZCBh
ZG9wdCBhIGdpdmVuIHBvbGljeSBsYW5ndWFnZSB0byBjb21tdW5pY2F0ZSB0aGVzZSB0aGluZ3Mu
Li4NCg0KU3RlZmFhbiAtIGFueSBsYW5ndWFnZSBpbiBtaW5kPw0KDQpNaWNoYWVsIC0gQ0lNIHdv
dWxkIHdvcmsgKElFVEYgZGVmaW5lZCkNCg0KV29qIC0gd2Ugc3RhcnRlZCBBTkNQIGZyb20gYSBz
ZXQgb2YgdXNlIGNhc2VzLiAgSXQgZGVwZW5kcyB3aGVyZSB5b3Ugd2FudCB0byBjdXQgdGhlIGRl
ZmluaXRpb24gb2YgcG9saWN5LCBidXQgeWVzLCB0aGUgdXNlIGNhc2VzIGFyZSBwb2xpY3kuICBT
byB1c2Ugb2YgcHJvdG9jb2wgZG9lcyBmaXQgaW50byB0aGUgc2NoZW1hIG9mIGEgcG9saWN5IGxh
bmd1YWdlLiAgQnV0IHByb3RvY29sIGRlZmluaXRpb24gaXMgcHJldHR5IG11Y2ggZXh0cmFjdHMg
ZWxlbWVudHMgb2Ygc2NoZW1hDQoNClNhbmpheSAtIHRoZSBwcm90b2NvbCBiZWluZyBkZWZpbmVk
IHNvcnQgb2YgZW1ib2RpZXMgcG9saWN5IHNjaGVtYSBhbmQgcHJvdmlkZXMgc2V0IG9mIGV4dGVu
c2libGUgVExWcy4NCg0KU3VyZXNoIEtyaXNobmFuIC0gcmVxcyBzYXkgYSBOQVMgc2hvdWxkIGJl
IGFibGUgdG8gY29tbXVuaWNhdGUgd2l0aCBtdWx0aXBsZSBhY2Nlc3Mgbm9kZXMuICBJcyBXRyBv
cGVuIHRvIHRoZSByZXZlcnNlIChvbmUgYWNjZXNzIG5vZGUgY29tbXVuaWNhdGluZyB3aXRoIG11
bHRpcGxlIE5BU2VzKT8NCg0KV29qIC0gdXAgdG8gbm93IGhhcyBiZWVuIG9uZSB0byBtYW55LCBi
dXQgd2UncmUgZGViYXRpbmcgdGhhdC4NCg0KU3RlZmFhbiAtIGFsc28gbWVhbnMgdGhhdCBvbmUg
YWNjZXNzIG5vZGUgY2FuIGdvIHRvIG11bHRpcGxlIE5BU2VzDQoNClN1cmVzaCAtIHNheXMgQU5D
UCBtdXN0IGJlIG1hcHBlZCBvbiB0b3Agb2YgSVAuICBEb2VzIHRoYXQgbWVhbiBjYW4gYmUgb24g
dG9wIG9mIFRDUD8NCg0KU3RlZmFhbiAtIHN1cmUgdGhlcmUgY2FuIGJlIGEgdHJhbnNwb3J0IHBy
b3RvY29sIGluIGJldHdlZW4uLi4NCg0KV29qIC0gZXh0ZW5zaWJpbGl0eSB0byBvdGhlciBhY2Nl
c3MgdHlwZXMuICBJbml0aWFsbHkgd2UncmUgYWltaW5nIGF0IERTTCBidXQgaGF2ZSBtYWRlIGNo
YXJ0ZXIgb3BlbiBzbyBjYW4gbG9vayBhdCBvdGhlciBhY2Nlc3MgdGVjaG5vbG9naWVzLiAgSWYg
c29tZWJvZHkgZmVlbHMgc3Ryb25nbHkgYWJvdXQgaW5jbHVkaW5nIGFub3RoZXIgYWNjZXNzIHRl
Y2hub2xvZ3kgdGhlbiBwbGVhc2UgY29tZSBmb3J3YXJkIGFuZCBjb250cmlidXRlLg0KDQpNaWNo
YWVsIC0gYW5vdGhlciBnb29kIHJlYXNvbiBmb3IgYSBwb2xpY3kgbGFuZ3VhZ2UgaXMgeW91IGNh
bid0IGNvdW50IG9uIGV2ZXJ5IGJveCBhdCBldmVyeSBsYXllciB0byBoYXZlIHNhbWUgZnVuY3Rp
b25hbGl0eS4gIFNvIGUuZy4gaWYgZmlyc3QgYm94IGNhbid0IGRvIHBvbGljaW5nIHRoZW4gbWF5
IGhhcHBlbiBhIGxheWVyIG9yIHR3byBpbnRvIHRoZSBuZXR3b3JrLiAgVGhlIHBvbGljeSBzZXJ2
ZXIgd2lsbCBrbm93IHRoZSB0b3BvbG9neSBhbmQgdGhlIGNhcGFiaWxpdGllcyBvZiBlYWNoIGJv
eCBhbmQgY2FuIHNlbmQgcG9saWNpbmcgaW5mbyB0byB0aGUgYm94IHRoYXQgY2FuIGRvIGl0LiAg
VGhlIGVuZHBvaW50IGRvZXNuJ3QgbmVlZCB0byBrbm93IGl0IHRvIHNpZ25hbCBpdC4gIFNvIGRv
bid0IGhhdmUgdG8gYXNzdW1lIHRoYXQgZWFjaCBib3ggaW4gdGhlIGFjY2VzcyBuZXR3b3JrIGhh
cyB0byBoYXZlIGFsbCB0aGUgY2FwYWJpbGl0aWVzIHRoYXQgeW91IG1heSBuZWVkLiAgSnVzdCBz
ZW5kIGdlbmVyaWMgcmVxdWVzdCB0byBhY2Nlc3MgbmV0d29yayBhbmQgaXQnbGwgaGFwcGVuIHdo
ZXJlIGl0IG5lZWRzIHRvLiAgRXZlbiB3aXRoaW4gb25lIHRlY2hub2xvZ3kgaXQgY291bGQgaGFw
cGVuIGF0IGRpZmZlcmVudCBsYXllcnMgb2YgYWdncmVnYXRpb24uICBTbyBmYXIgZG9uJ3Qgc2Vl
IGFueXRoaW5nIGhlcmUgeW91IGNvdWxkbid0IGRvIHdpdGggYSBwb2xpY3kgbGFuZ3VhZ2UgYW5k
IHdoZXJlIHRoZSByZXFzIGNvdWxkbid0IGJlIHBhcnQgb2YgdGhlIHNjaGVtYQ0KDQpTYW5qYXkg
LSBqdXN0IHRvIGJlIGNsZWFyIHdlJ3JlIGRlZmluaW5nIGEgcHJvdG9jb2wgYmV0d2VlbiB0d28g
bmV0d29yayBlbGVtZW50cy4gIFBvbGljeSBpcyBjb21wbGVtZW50YXJ5IHRvIHRoaXMuICBZZXQg
YW5vdGhlciB3YXkgdG8gZG8gaXQuICBBTkNQIGlzIGEgcHJvdG9jb2wgYmV0d2VlbiB0aGUgbmV0
d29yayBlbGVtZW50cyB0aGVtc2VsdmVzLi4uDQoNCk1hdHRoZXcgLSB0YWtlIGRlYmF0ZSB0byBs
aXN0Lg0KDQoNClN0ZWZhYW4gLSBhY2Nlc3Mgbm9kZSBBTkNQIE1JQg0KLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tDQoNCmRyYWZ0IHN0YXJ0ZWQgYXQgSUVURjY2IHdoZXJlIGRpc2N1c3Nl
ZCByZXF1aXJlbWVudCBmb3IgYSBNSUIuICBzY29wZSBvZiBNSUIgaXMgQU5DUCBmb3IgYWNjZXNz
IG5vZGUgKG5vdCBOQVMpDQoNCk1JQiBtYW5hZ2VzIHRoZSBhY2Nlc3Mgbm9kZSBjb250cm9sIHNl
c3Npb25zLCBidXQgbm90IG90aGVyIHRoaW5ncyAoZS5nLiBjb250cm9sIGNoYW5uZWxzKS4NCg0K
c2Vzc2lvbiBjb25maWcgdGFibGUgLSBOQVMgaXMgaWRlbnRpZmllZCBieSBJUCBBZGRyZXNzIHBs
dXMgdHlwZSAodjQvdjYpLiAgb3RoZXIgYXR0cmlidXRlcyBjb25maWd1cmUgcHJvcGVydGllcyAo
ZS5nLiB2ZXJzaW9uIG9mIEFOQ1ApLg0KDQpjdXJyZW50IHNlc3Npb24gdGFibGUuDQoNCm91dHN0
YW5kaW5nIHF1ZXN0aW9uIG9uIE5BUyBNSUIuICBTdGVmYWFuIHRoaW5rcyB0b28gZWFybHkgdG8g
c3RhcnQgTkFTIE1JQiwgYnV0IG1heWJlIG5lZWQgdG8gdGhpbmsgYWJvdXQgaXQuICBBTiBhbmQg
TkFTIGhhdmUgZGlmZmVyZW50IHJvbGVzIHNvIHByb2JhYmx5IGJlc3QgdG8gaGF2ZSB0d28gTUlC
cyByYXRoZXIgdGhhbiBvbmUuDQoNCnBsZWFzZSByZWFkIGRvYyBhbmQgcG9zdCBjb21tZW50cyB0
byBXRyBtYWlsaW5nIGxpc3QuDQoNCldvaiAtIGhvdyBtdWNoIGRvZXMgTUlCIGluaGVyaXQgZnJv
bSBHU01QIE1JQj8NCg0KU3RlZmFhbiAtIGp1c3QgdGV4dHVhbCBjb252ZW50aW9ucyAoZS5nLiB2
ZXJzaW9uKS4NCg0KV29qIC0gaXMgdGhpcyBmdWxseSBzdGFuZGFsb25lIE1JQj8NCg0KU3RlZmFh
biAtIHllcywgbm8gbmVlZCB0byBpbXBsZW1lbnQgR1NNUCBNSUIuDQoNCldvaiAtIG5vdCBzZWVu
IGFueSBkZWJhdGUgb24gbWFpbGluZyBsaXN0IHNvIGRvIHBsZWFzZSBjb21tZW50IG9uIGl0Lg0K
DQoNCkhhc3NuYWEgLSBzZWN1cml0eSB0aHJlYXRzL3JlcXVpcmVtZW50cyBmb3IgQU5DUA0KLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCnRoZSBtYWlu
IG9iamVjdCBpcyB0byBpbnZlc3RpZ2F0ZSB0aHJlYXRzIGF0IEFOQ1Agbm9kZXMgYW5kIGRldmVs
b3AgbW9kZWwgc28gY2FuIGRlZmluZSBzZWN1cml0eSByZXF1aXJlbWVudHMgZm9yIEFOQ1AuDQoN
CmNvbW11bmljYXRpb24gd2l0aCBwb2xpY3kgc2VydmVyIG5lZWRzIHRvIGJlIHNlY3VyZSwgYnV0
IG5vdCBpbiBzY29wZSBoZXJlLg0KDQptYWlubHkgZGlzdGluZ3Vpc2ggYmV0d2VlbiB0d28gdHlw
ZXMgb2YgYXR0YWNrOg0KMSkgaW4gcGF0aCB3aGVyZSBhdHRhY2tlciBpcyBpbiBwYXRoIGZyb20g
QU4gdG8gTkFTDQoyKSBvdXQgb2YgcGF0aA0KDQplaXRoZXIgYXR0YWNrIGNvdWxkIGJlIGFjdGl2
ZSAodGFrZSBhY3Rpb24pIG9yIHBhc3NpdmUgKGVhdmVzZHJvcHBpbmcgLSBsYXRlciBvbiBtYXkg
dXNlIGluZm8gZm9yIHVuYXV0aG9yaXNlZCBhY2Nlc3MpLg0KDQptYWluIHNlY3VyaXR5IGlzc3Vl
cyBhcmUgcHJldmVudGlvbiBvZiBEb1MsIGltcGVyc29uYXRpb24gYW5kIHJlYWRpbmcgdXNlcnMn
IGluZm8uDQoNCmZpcnN0IHVzZSBjYXNlLiAoZHluYW1pYyBhY2Nlc3MgbG9vcCBhdHRyaWJ1dGVz
KS4NCg0Kc2Vjb25kIHVzZSBjYXNlLiAgbWFpbmx5IGFjdGl2ZSBvbi1wYXRoIGF0dGFja3MuICBv
bmUgcmlzayBpcyByZXBsYXkgLSBzbyBpbGxlZ2l0aW1hdGUgYWR2ZXJzYXJ5IGNvdWxkIGdldCBw
cml2aWxlZ2VkIGFjY2Vzcy4gIG9uLXBhdGggaXMgYSBtaXggb2YgYWN0aXZlL3Bhc3NpdmUuDQoN
CnRoaXJkIHVzZSBjYXNlLiAgbWFpbiBhdHRhY2tzIGFyZSByZWxhdGVkIHRvIG5ldHdvcmsgZnVu
Y3Rpb25hbGl0eS4gDQoNCmZvdXJ0aCB1c2UgY2FzZS4gIG1haW5seSBhY3RpdmUgb24tcGF0aCBh
dHRhY2tzLiAgZS5nLiBtdWx0aWNhc3QgZ3JvdXAgaW5mbyBjb3VsZCBiZSBjaGFuZ2VkIGJ5IGEg
bWFuIGluIHRoZSBtaWRkbGUuDQoNCldvaiAtIG11bHRpY2FzdCB1c2UgY2FzZSBub3QgcmVhbGx5
IGRlZmluZWQgeWV0LiB3aGF0IHdlcmUgeW91ciBhc3N1bXB0aW9ucz8NCg0KSGFzc25hYSAtIGFz
c3VtZWQgdGhhdCBtdWx0aWNhc3QgaXMgcmVwbGljYXRlZCBhbmQgdGhhdCB0aGVyZSBpcyBzb21l
IGluZm9ybWF0aW9uIHJlZ2FyZGluZyB0aGUgZ3JvdXAgdGhhdCBpcyB0cmFuc2ZlcnJlZCBmcm9t
IHRoZSBwb2xpY3kgc2VydmVyIHRvIHRoZSBBTiBhbmQgd2hpY2ggbWF5IGJlIG1vZGlmaWVkIGlu
IG9yZGVyIHRvIGRpc3J1cHQgdGhlIGNsaWVudCdzIGNvbW11bmljYXRpb24uICBJcyBhYnN0cmFj
dCBmb3IgdGhlIG1vbWVudC4gIEFsc28gY29uc2lkZXIgZGFtYWdpbmcgcHJveHkgZnVuY3Rpb25h
bGl0eSBhcyBiZWluZyBhbiBhdHRhY2suDQoNCkJhc2VkIG9uIHRocmVhdCBtb2RlbCBkZXZlbG9w
ZWQgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGZvciBBTkNQLg0KDQpIYW5uZXMgLSB5b3UgbWVudGlv
bmVkIHRoYXQgdGhlIG11bHRpY2FzdCB1c2UgY2FzZSBpc24ndCBvdXRsaW5lZCBpbiBkZXRhaWwg
aW4gZnJhbWV3b3JrLiAgU28gaXMgdGhhdCBzb21ldGhpbmcgZm9yIHRoZSBmcmFtZXdvcmsgdG8g
cHJvdmlkZSBtb2RlIGRldGFpbCBvbi4NCg0KV29qIC0gZnVsbHkgYWdyZWUuIGhvbGUgaW4gZnJh
bWV3b3JrIHJlbWFpbnMgdG8gYmUgZmlsbGVkLg0KDQpIYW5uZXMgLSB0aHJlYXRzIGRvYyBoYXMg
dG8gbW92ZSBhbG9uZywgYnV0IHRoZSBtb3JlIHdvcmsgd2UgZG8gb24gdGhlIHByb3RvY29sIHRo
ZSBtb3JlIHNwZWNpZmljIHRoZSB0aHJlYXQgYW5hbHlzaXMgY2FuIGJlLCBidXQgYWxzbyBoZWxw
cyB0byBoYXZlIHRocmVhdCBpbmZvIGluIG9yZGVyIHRvIGRlc2lnbiBwcm90b2NvbCBzbyB3ZSBo
YXZlIHRvIGJhbGFuY2UgdGhlIHR3by4NCg0Kd2FudCBjb21tZW50cyBhbmQgd2lsbCBwcm9ncmVz
cyBpdCBhcyBhIHNlcGFyYXRlIGRyYWZ0IGF0IGxlYXN0IGZvciB0aGUgbW9tZW50IHRvIGNvbXBs
ZW1lbnQgdGhlIGZyYW1ld29yay4NCg0KU2FuamF5IC0gb25lIHF1aWNrIGNvbW1lbnQgb24gc2Vj
dXJpdHkgcmVxdWlyZW1lbnRzIHNsaWRlLiAgU29tZSBvZiB0aGUgcmVxcyBzZWVtIGEgYml0IHN0
cm9uZyBnaXZlbiB0aGF0IHByb3RvY29sIHJ1bnMgaW4gYSB0cnVzdGVkIGRvbWFpbi4gIFdlIGNv
dWxkIHVzZSBTSE9VTEQgZm9yIHNvbWUgb2YgdGhvc2UgTVVTVHMuDQoNCkhhc3NuYWEgLSB3ZSB3
YW50ZWQgdGhpcyB0byB3b3JrIGluIHVudHJ1c3RlZCBkb21haW5zIGFzIHdlbGwNCg0KV29qIC0g
SSdsbCBhZGQgaGVyZSB0aGF0IGZvbGxvd2luZyBJRVRGIGJlc3QgcHJhY3RpY2Ugd2Ugc2hvdWxk
IG9wdGltaXNlIGZvciBpbnRlbmRlZCB1c2UgYnV0IHVuZGVyc3RhbmQgdGhhdCBtYXkgYmUgdXNl
ZCBpbiB1bmludGVuZGVkIGNhc2VzIChlLmcuIG92ZXIgdGhlIEludGVybmV0KSBhcyBwZXIgQkNQ
NjEgZG9jLg0KDQpTYW5qYXkgLSB0aGUgcmVxdWlyZW1lbnRzIG91dGxpbmUgd2hhdCB0aGUgcHJv
dG9jb2wgc2hvdWxkIHByb3ZpZGUgaW4gdGVybXMgb2YgY2FwYWJpbGl0aWVzLiAgZm9yIGRlcGxv
eW1lbnQgdGhlcmUgaXMgcXVlc3Rpb24gb2Ygd2hldGhlciB5b3Ugd2FudCB0byB0dXJuIG9uIGV2
ZXJ5dGhpbmcuICBlLmcuIG1heSB3YW50IHRvIHR1cm4gc2VjdXJpdHkgb24gaW50cmEtZG9tYWlu
IGV2ZW4gdGhvdWdoIHRoZXkgYXJlbid0ICJuZWVkZWQiIHNvIHByb3RvY29sIHNob3VsZCBtYWtl
IGl0IHBvc3NpYmxlIHRvIHR1cm4gdGhlbSBvbi4gIE1ha2UgZGlzdGluY3Rpb24gYmV0d2VlbiBw
cm90b2NvbCByZXF1aXJlbWVudHMgYW5kIHVzYWdlLg0KDQpTdXJlc2ggLSB0d28gY29tbWVudHMu
ICBObyBib290c3RyYXBwaW5nIHByb2NlZHVyZSBkZWZpbmVkIHNvIGNhbid0IGhhdmUgdGhpcyB3
aXRob3V0IGtub3dpbmcgd2hvIHRoZSBvdGhlciBlbmQgaXMuICBTbyB5b3UgbmVlZCBhIHdheSB0
byBrbm93IHRoYXQgdGhlIGd1eSB0aGUgZmFyIGVuZCBpcyB0aGUgTkFTLg0KDQpIYXNzbmFhIC0g
dGhhdCdzIHdoeSB3ZSBoYXZlIG11dHVhbCBhdXRoZW50aWNhdGlvbi4NCg0KU3VyZXNoIC0gYnV0
IG5lZWQgc29tZSBraW5kIG9mIGRpc2NvdmVyeSBwcm9jZWR1cmUuICBaZXJvIGtub3dsZWRnZS4N
Cg0KSGFzc25hYSAtIHRoZXJlJ3MgZGlzY292ZXJ5IGluIHRoZSBwcm90b2NvbCBpdHNlbGYNCg0K
SGFubmVzIC0gdGhlIGRpc2NvdmVyeSBvZiB0aGUgbm9kZXMgaXMgYSBzZWNvbmRhcnkgaXNzdWUu
ICBBdXRob3Jpc2F0aW9uIGFzIHRvIHdoZXRoZXIgaXQncyBhIGxlZ2l0aW1hdGUgbm9kZSBjYW4g
YmUgZG9uZSBieSB3YWxraW5nIHRoZSB0YWJsZS4gIElmIHBlb3BsZSBhcmUgZXhjaXRlZCBieSBk
aXNjb3ZlcnkgKG5vdCBzZWVuIGluIGZyYW1ld29yaykgdGhlbiB3ZSBuZWVkIHRvIGFkZHJlc3Mg
aXQuDQoNClN0ZWZhYW4gLSB0byByZXNwb25kIHRvIFN1cmVzaCdzIGNvbW1lbnRzIHlvdSBjb25m
aWd1cmUgdGhlIElQIGFkZHJlc3Mgb2YgdGhlIE5BUyBpbiB0aGUgQU4uICBObyBkaXNjb3Zlcnkg
bWVjaGFuaXNtIGZvciB0aGUgbW9tZW50Lg0KDQpTdXJlc2ggLSBnaXZlbiB0aGF0IHRoZSBBTiBr
bm93cyB0aGUgTkFTIGFyZSB3ZSBtaXNzaW5nIGEgcmVxdWlyZW1lbnQgdGhhdCBzYXlzIHdlIG5l
ZWQgdG8gYXNzdXJlIHRoZSBpbml0aWFsIGV4Y2hhbmdlLg0KDQpIYXNzbmFhIC0gdGhpcyBkcmFm
dCBpcyBub3QgdHJ5aW5nIHRvIHByb3ZpZGUgc29sdXRpb25zLg0KDQpIYW5uZXMgLSBtdXR1YWwg
YXV0aCBwcmV2ZW50cyBtYW4gaW4gbWlkZGxlIGJldHdlZW4gY29tbXVuaWNhdGluZyBlbnRpdGll
cw0KDQpTdXJlc2ggLSB3ZSBoYXZlIHR3byBNVVNUcyBhbmQgYSBTSE9VTEQgcmlnaHQgbm93Lg0K
DQpIYW5uZXMgLSB0aGUgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIGlzIGFscmVhZHkgY292ZXJlZCBi
eSBBTiBhbmQgTkFTIChmaXJzdCB0d28gcmVxdWlyZW1lbnRzKQ0KDQpIYWFzbmFhIC0gdHJ5aW5n
IHRvIGNvdmVyIHdob2xlIHByb3RvY29sIGFuZCBhbGwgY29tbXVuaWNhdGluZyBlbnRpdGllcw0K
DQpIYW5uZXMgLSBidXQgd2hhdCBhcmUgdGhlIG90aGVyIGVudGl0aWVzIHRoYW4gQU4gYW5kIE5B
Uz8gIFNvIGlmIHJlbW92ZSB0aGUgbXV0dWFsIGF1dGggcmVxIGl0IHdpbGwgYmUgT0suDQoNClN1
cmVzaCAtIGlmIHRoYXQncyB3aGF0IHdlIGRvIEknbSBPSw0KDQpIYWFzbmFhIC0gaXMgaXQgYmV0
dGVyIHRvIGhhdmUgdHdvIHJlcXMgKG9uZSBlYWNoIHdheSkgb3IgYSB0d28gd2F5IG9uZT8NCg0K
U3VyZXNoIC0gaGFzIHRvIGJlIGEgTVVTVCBlaXRoZXIgd2F5Lg0KDQpTdXJlc2ggLSBhbHNvIHNh
eXMgYWJvdXQgcHJpdmFjeS4gIFByaXZhY3kgZm9yIHdobz8NCg0KSGFubmVzIC0gY29uZmlkZW50
aWFsaXR5DQoNClN1cmVzaCAtIGJ1dCB0aGF0J3MgYWxyZWFkeSBjb3ZlcmVkLg0KDQpXb2ogLSBz
ZWVtcyBtYW55IGNvbW1lbnRzLg0KDQpTdXJlc2ggLSBub3Qgc2hvd3N0b3BwZXJzLg0KDQpTdXJl
c2ggLSBmb3IgRG9TIG1pZ2h0IGJlIGJldHRlciB0byBiZSBtb3JlIHNwZWNpZmljIGFuZCBzYXkg
ZS5nLiAiZG9uJ3Qga2VlcCBzdGF0ZSB1bnRpbCB5b3Uga25vdyB3aG8geW91J3JlIHRhbGtpbmcg
dG8iLg0KDQpIYWFzbmFhIC0gdGhlc2UgYXJlIGdlbmVyYWwgcmVxdWlyZW1lbnRzLCB0aGF0J3Mg
YSBzb2x1dGlvbg0KDQpIYW5uZXMgLSByZXF1aXJlbWVudCBhcyBzdGF0ZWQgaXMgbW9yZSBnZW5l
cmljLiAgDQoNCk11cnVnYXJhaiAtIGlzIGl0IHJlYWxseSBhIHNlY3VyaXR5IHJlcXVpcmVtZW50
IHRvIGRpc3Rpbmd1aXNoIGNvbnRyb2wgZnJvbSBkYXRhPw0KDQpIYWFzbmFhIC0geWVzLCB0byBw
cmV2ZW50IHNpZ25hbGxpbmcgcmVwbHkgYXR0YWNrcy4gIEFuZCBpdCdzIGEgU0hPVUxELCBub3Qg
YSBNVVNULg0KDQpIYW5uZXMgLSAoUSB0byBjaGFpcnMpLiAgU2hvdWxkIHRoaXMgZG9jIGJlY29t
ZSBhIFdHIGl0ZW0/DQoNCk1hdHRoZXcgLSBjaGFydGVyIGluY2x1ZGVzIHRocmVhdCBhbmFseXNp
cy4gIFNvIGNlcnRhaW5seSBuZWVkIHRvIGFkZCByZXF1aXJlbWVudHMgYmFzZWQgb24gdGhhdC4g
IExvdHMgb2YgZGlzY3Vzc2lvbi9pbnRlcmVzdCB0b2RheS4gIFNvIGFzayBRIHRvIFdHLiAgV2Ug
ZG8gaGF2ZSB0byBkbyB0aHJlYXQgYW5hbHlzaXMsIGJ1dCBtYXliZSB0b28gZWFybHkgdG8gYmVj
b21lIFdHIGRvYyBiZWZvcmUgd2UndmUgaGFkIG1vcmUgZGlzY3Vzc2lvbg0KDQpIYW5uZXMgLSBq
dXN0IGJlY2F1c2UgaXMgV0cgZHJhZnQgZG9lc24ndCBtZWFuIGlzIG92ZXIuICAgV29yayB1c3Vh
bGx5IHN0YXJ0cyB0aGVuLg0KDQpXb2ogLSBodW0gdm90ZSBmb3IgYmVpbmcgV0cgZG9jIGF0IHRo
aXMgc3RhZ2UuDQoNClNhbmpheSAtIGl0IGRvZXMgY292ZXIgdGhyZWF0IGFuYWx5c2lzIGFuZCBp
cyBjb21wcmVoZW5zaXZlIGJ1dCB0aGluayB3ZSBuZWVkIHRvIHdhaXQgZm9yIHByb3RvY29sIGRy
YWZ0IHRvIGJlY29tZSBXRyBkb2MgZmlyc3QgKGFzIG1heSBuZWVkIGNoYW5nZXMpLg0KDQpIYW5u
ZXMgLSBhbGwgV0cgZG9jcyB3aWxsIG5lZWQgY2hhbmdlcy4NCg0KU2FuamF5IC0gaXMganVzdCBh
IG1hdHRlciBvZiBvcmRlcmluZy4NCg0KaHVtIHZvdGUuDQoNCldvaiAtIHNlZW1zIGxpa2UgcGxl
bnR5IG9mIGh1bXMNCg0KRGF2ZSBBbGxlbiAtIHlvdSBzaG91bGQgcHV0IHRoaXMgdG8gdGhlIGxp
c3QsIHRoYXQncyB3aGF0IG5lZWRzIHRvIGhhcHBlbiBhbnl3YXkuDQoNCldvaiAtIHdhbnQgdG8g
bWFrZSBzdXJlIHRoYXQgcG9pbnRzIGZyb20gZGlzY3Vzc2lvbiBoYXZlIGJlZW4gdGFrZW4gZG93
bi4NCg0KSGFzc25hYS4gIHdpbGwgaGF2ZSBzb21lIGluIG1pbnV0ZXMsIGJ1dCBpZiBuZWVkIGRl
dGFpbHMgY2FuIHBlb3BsZSBwbGVhc2UgcG9zdCBvbiBtYWlsaW5nIGxpc3QuDQoNCg0KU2FuamF5
IC0gQU5DUCBwcm90b2NvbCBkcmFmdCB1cGRhdGVzDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tDQoNCmRyYWZ0IGJlZW4gYXJvdW5kIGZvciBhIHdoaWxlLiAgVGhpcyBpcyBz
ZWNvbmQgcmV2LiBTbyB3aWxsIG91dGxpbmUgY2hhbmdlcyBzaW5jZSByZXYgMDEuICBBc3N1bWVz
IHJlYWRlciBpcyBmYW1pbGlhciB3aXRoIDAxLg0KDQpleHRlbnNpb24gYmxvY2sgYWxsb3dzIHVz
IHRvIGFkZCBUTFZzIHRvIGV4aXN0aW5nIG1lc3NhZ2VzIGlmIHdlIGNvbWUgdXAgd2l0aCBuZXcg
aW5mbyB0aGF0IG5lZWRzIHRvIGJlIGV4Y2hhbmdlZCBmcm9tIG5ldyB1c2UgY2FzZXMgb3IgZXh0
ZW5zaW9ucyB0byBleGlzdGluZyBjYXNlcy4NCg0KdjEgaGFkIGEgYnVnIHdoZXJlIHR3byBUTFZz
IGNvbGxpZGVkIC0gc28gbm93IGZpeGVzLg0KDQpBbHNvIFFzIG9uIG1haWxpbmcgbGlzdCBvbiBB
Q0kgZm9ybWF0IC0gc28gbm93IG1hZGUgY2xlYXIgaXMgVFItMTAxIHN5bnRheC9mb3JtYXQuICBS
ZWFzb24gaXMgdGhhdCB0eXBpY2FsbHkgZ2V0IEFDSSBpbmZvIGluIFBQUCBvciBESENQIG1lc3Nh
Z2VzIGFuZCBOQVMgbmVlZHMgdG8gY29ycmVsYXRlIChzbyB0aGVyZWZvcmUgbmVlZCBzYW1lIGZv
cm1hdCB0byBjb3JyZWxhdGUpLg0KDQpXb2ogLSBBQ0kgaXMgc2FtZSBhcyB1c2VkIGluIG9wdGlv
biA4Mi4gYXJlIHRoZXJlIGFueSBkcmFmdHMgZGVmaW5pbmcgaXQgb3RoZXIgdGhhbiBEU0wgRm9y
dW0ncyBUUi0xMDENCg0KU2FuamF5IC0gb25seSBzZWVuIGluIFRSLTEwMSwgd2hpY2ggc3BlY2lm
aWVzIGl0IHZlcnkgd2VsbC9leHRlbnNpdmVseS4NCg0KTWFyayBUb3duc2xleSAtIEknbSB3b3Jy
aWVkIGFib3V0IGhhdmluZyBhIG5vcm1hdGl2ZSByZWYgdG8gYSBEU0xGIGRvYyBhcyB0aGV5IGFy
ZW4ndCBnZW5lcmFsbHkgYXZhaWxhYmxlLg0KDQpXb2ogLSBUUi0xMDEgaXMgcHVibGljLiAgT25j
ZSBkb2NzIHJlYWNoIFRSIHN0YXR1cyB0aGV5J3JlIHB1YmxpYyAoYXZhaWxhYmxlIGF0IGh0dHA6
Ly93d3cuZHNsZm9ydW0ub3JnL3RlY2h3b3JrL3RyL1RSLTEwMS5wZGYpDQoNCk1hcmsgLSB0aGF0
J3MgT0sgdGhlbi4NCg0KU2FuamF5IC0gc2luY2UgZHJhZnQgb3V0IGZvciBhIHdoaWxlIGFuZCB0
aGVyZSBhcmUgc2V2ZXJhbCBpbnRlcm9wZXJhYmxlIE5BUyBhbmQgQU4gaW1wbGVtZW50YXRpb25z
IG91dCB0aGVyZSB3ZSdkIGxpa2UgdG8gcmVxdWVzdCB0aGF0IGl0IGJlY29tZXMgV0cgZG9jLg0K
DQpTdGVmYWFuIC0gYXQgbGFzdCBJRVRGIG1lZXQgd2UgZGVjaWRlZCB0byBzZXBhcmF0ZSBmcmFt
ZXdvcmsgYW5kIHByb3RvY29scywgYnV0IHRoaXMgZHJhZnQgc3RpbGwgaGFzIGxvdHMgb2YgZnJh
bWV3b3JrIGluIGl0Lg0KDQpTYW5qYXkgLSBoYXMgc29tZSBjb250ZXh0IGZvciB1c2UgY2FzZXMN
Cg0KU3RlZmFhbiAtIHNlY3Rpb25zIDIgYW5kIDMgYXJlIG1vc3RseSBmcmFtZXdvcmsuIA0KDQpT
YW5qYXkgLSB0aGF0J3MgYmVjYXVzZSB0aGlzIHdhcyB3cml0dGVuIGJlZm9yZSBmcmFtZXdvcmsN
Cg0KU3RlZmFhbiAtIHdpbGwgaXQgYmUgcmVtb3ZlZD8gIHdlIGFncmVlZCB0aGF0IGF0IHRoZSBs
YXN0IElFVEYuDQoNClNhbmpheSAtIEknbGwgdHJ5IHRvIHRha2UgaXQgb3V0LiAgRG9lc24ndCBk
byBhbnkgaGFybS4NCg0KU3RlZmFhbiAtIG5vdCBhbHdheXMgaW4gbGluZSB3aXRoIGZyYW1ld29y
ay4gIElmIHdlIGhhdmUgdGhhdCB0aGVuIHdlJ2xsIGhhdmUgdHdvIGZyYW1ld29yayBkb2NzLg0K
DQpTYW5qYXkgLSBqdXN0IGhhcyBjb250ZXh0IG9uIHVzZSBjYXNlcy4gIE1heWJlIHNob3VsZCBz
aG9ydGVuIGRlc2NyaXB0aW9uLg0KDQpTdGVmYWFuIC0gYnV0IG9uIHVzZSBjYXNlcyB5b3UgaGF2
ZSBtb3JlIHRleHQgdGhhbiBmcmFtZXdvcmsgZG9jIHNvbWV0aW1lcy4gIFNvIHJlbW92ZSBpdCBh
bmQganVzdCBmb2N1cyBvbiBwcm90b2NvbC4NCg0KTWF0dGhldyAtIG5vdCB3cm9uZyB0byBzdW1t
YXJpc2UgZnJhbWV3b3JrLCBidXQgZG9uJ3Qgd2FudCB0d28gZGlmZmVyZW50IGRvY3MuICBQcm9i
bGVtIGlmIG9uZSBnb2VzIHRvIFJGQyBmaXJzdCBhbmQgd2FudCB0byB1cGRhdGUgdGhlIG90aGVy
LiAgSSBzdWdnZXN0IHJlbW92aW5nIGl0Lg0KDQpTYW5qYXkgLSB3aWxsIGp1c3QgYmUgY29udGV4
dCBmb3IgdXNlIGNhc2VzLg0KDQpzaG93IG9mIGhhbmRzIG9uIHdobydzIHJlYWQgaXQgKGZhaXIg
bnVtYmVyIHJhaXNlZCkNCg0KY29uc2Vuc3VzIG9uIGJlY29taW5nIFdHIElEPw0KDQpvbmx5IGZv
dXIgaGFuZHMgcmFpc2VkLg0KDQppbnZlcnNlIHF1ZXN0aW9uPw0KDQpub2JvZHkgZG9lc24ndCB3
YW50IGl0IHRvIGJlIFdHIGRvYz8NCg0Kbm9uZS4NCg0KTWF0dGhldyAtIHNvIGxvdHMgb2YgcGVv
cGxlIGhhdmUgcmVhZCBpdCBhbmQgYXJlIHRvdGFsbHkgdW5kZWNpZGVkISAgd2lsbCBhc2sgUSBv
biBsaXN0IGFnYWluLg0KDQoNCldvaiAtIG92ZXJ2aWV3IG9mIG1haW4gZ2FwcyBpbiBmcmFtZXdv
cmsgYW5kIG9wZW4gUXMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NCg0KbGlzdCBvZiBidWxsZXQgcG9pbnRzLg0KDQpoYXZlIGhhZCBzb21lIGRp
c2N1c3Npb24gb24gcGFydGl0aW9uaW5nLiAgQW55IG1vcmUgaW5wdXQgd2VsY29tZWQgLSBvdGhl
cndpc2Ugd2lsbCBwcm9jZWVkIG9uIGhhcmQgcGFydGl0aW9uaW5nIGNhc2UuDQoNCmNvbnRyb2xs
ZXIgcmVkdW5kYW5jeSAtIGxpbmVzIHVwIHdpdGggZWFybGllciBxdWVzdGlvbiBvbiAxOk4gb2Yg
Y29udHJvbGxlci9BTnMgb3IgTTpOIChvciB3aGF0ZXZlcikuICBWZXJ5IGxpdHRsZSBkaXNjdXNz
aW9uIG9uIG1haWxlci4gTXkgdGFrZWF3YXkgc28gZmFyIGlzIHRoYXQgcHJpb3JpdHkgaXMgZm9y
IDErMS4gIGFnYWluIGlmIGFueSBtb3JlIGlucHV0IHRoZW4gcGxlYXNlIGNvbWUgZm9yd2FyZC4N
Cg0KU2FuamF5IC0gb25lIHRvIG9uZSBtYWtlcyBzZW5zZSBpZiBkb2luZyB0aGUgc2FtZSBraW5k
IG9mIHRoaW5nIGFzIGZvciBzdWJzY3JpYmVyIHNlc3Npb25zLiAgaWYgd2UgZG9uJ3QgZG8gc29t
ZXRoaW5nIHNpbWlsYXIgZm9yIFBQUCBhbmQgc2Vzc2lvbnMgZ28gZG93biBhbmQgY29tZSB1cCBh
Z2FpbiB0aGVuIGRvaW5nIHNhbWUgZm9yIERIQ1AgaXNuJ3Qgc28gYmFkLiAgU28gZm9yIHByb3Zp
ZGVycyBkbyB3ZSB0aGluayBpbnRlci1jaGFzc2lzIHJlZHVuZGFuY3kgaW4gZ2VuZXJhbCBpcyBp
bXBvcnRhbnQuDQoNClN0ZWZhYW4gLSBjb21tZW50IEkgaGF2ZSBpcyB0aGF0IFBQUCBzZXNzaW9u
IGNhbiBnbyBkb3duIGFuZCBiZSByZS1lc3RhYmxpc2hlZCBidXQgRFNMIHN0YXlzIHVwLg0KDQpT
YW5qYXkgLSBsaW5lIGluZm8geW91J3JlIHRha2luZyBhbGwgdGhhdCB0cm91YmxlIHRvIHJlcGxp
Y2F0ZSB3b24ndCBiZSB1c2VkIHdoZW4gc2Vzc2lvbiBjb21lcyB1cCBhZ2Fpbi4NCg0KU3RlZmFh
biAtIG1lc3NhZ2VzIHNlbnQgd2hlbiBEU0wgZ29lcyB1cCBhbmQgZG93biBpbmRlcGVuZGVudCBv
ZiBQUFAgc3RhdGUuDQoNCldvaiAtIGhhdmUgc2Vzc2lvbiBvcmRlcmluZyBwcm9ibGVtIGhlcmUu
ICBpZiBhIFBQUCBzZXNzaW9uIGNvbWVzIHVwIGZyb20gcmVkdW5kYW50IEJSQVMgYmVmb3JlIEFO
Q1AgZXN0YWJsaXNoZWQgdGhlbiB5b3UncmUgaW4gdGhlIGRhcmsgd2l0aG91dCB0aGUga25vd2xl
ZGdlIHRoYXQgQU5DUCBnaXZlcyB5b3UuDQoNClNhbmpheSAtIHRoYXQgY2FuIGhhcHBlbiB3aXRo
b3V0IGEgZmFpbG92ZXIuDQoNCldvaiAtIG5vdCBzdXJlIGlmIHdlIGNhbiBkbyBhbnl0aGluZyBh
dCBwcm90b2NvbCBsZXZlbCB0byBhZGRyZXNzIGl0IChyYXRoZXIgdGhhbiBib3ggbGV2ZWwpLiAg
SW4gZXNzZW5jZSBvbmUgY29udHJvbGxlciBhbmQgbWFueSBhY2Nlc3Mgbm9kZXMgYXBwZWFycyB0
byBiZSB0aGUgbWFpbiB1c2UgY2FzZSAoZm9sbG93ZWQgYnkgMSsxKS4gIEFueSBvdGhlciB2aWV3
cyBmcm9tIHRob3NlIHdobyB2b2ljZWQgUSBlYXJsaWVyIG9uIDE6TiB2cyBNOk4/DQoNCj8/Pz8g
LSB0byBoYXZlIG1vcmUgcmVsaWFiaWxpdHkgd2Ugc2hvdWxkIGNvbnNpZGVyIGNvbnRyb2xsZXIg
cmVkdW5kYW5jeS4gIGdvZXMgYWxvbmcgd2l0aCByb3V0ZXIgZmFpbG92ZXIgZXRjLiAgd2UgYWxz
byBoYXZlIG11bHRpY2FzdCB3aGljaCBpcyBtb3JlIGRvd25zdHJlYW0gb3JpZW50YXRlZC4gIHNv
IHNob3VsZCBjb25zaWRlciB0aGlzLi4uDQoNCg0KV29qOg0KTmVlZCB0byBpbml0aWF0ZSBkaXNj
dXNzaW9uIG9uIHRyYW5zcG9ydCBjb25zaWRlcmF0aW9ucy4gVGhpcyBzaG91bGQgc3RhcnQgYnkg
ZGVzY3JpYmluZyB0aGUgb3ZlcmFsbCBwcm9ibGVtOyB3aGF0IGlzIGl0Pw0KDQpIYWFzbmFhIHNo
b3duIHByb2dyZXNzIG9uIHNlY3VyaXR5Lg0KDQptdWx0aWNhc3QgY29udHJvbCByZWZlcnMgdG8g
c2VjdGlvbiBpbiBmcmFtZXdvcmsgZGVmaW5pbmcgbXVsdGljYXN0IGNvbnRyb2wgdXNlIGNhc2Uu
ICBEb24ndCB0aGluayB3ZSBoYXZlIHByb2dyZXNzZWQgbXVjaCAobm8gdXBkYXRlIHRvIHVzZSBj
YXNlKSBzbyBuZWVkIGRpc2N1c3Npb24gb24gbWFpbGVyIGFzIHRvIHdoYXQgcGVvcGxlIGhhdmUg
aW4gbWluZC4NCg0KYWNjZXNzIGxpbmUgY29uZmlndXJhdGlvbi4gIEF0dHJhY3RpdmUgdXNlIGNh
c2UuICBub3QgbXVjaCBkZXRhaWwgaW4gc2VjdGlvbiBhcyB0byB3aGF0IGl0J2xsIGJlIHVzZWQg
Zm9yLiAgSGFkIGRpc2N1c3Npb24gYmVmb3JlIG9uIFNOTVAgdnMgQU5DUCBldGMuICBDYW4gcGVv
cGxlIHBsZWFzZSByZS1yZWFkIGFuZCBzZWUgaWYgd2UgY2FuIGNsYXJpZnkgd2hhdCBpcyBpbnRl
bmRlZCBieSB0aGlzIHVzZSBjYXNlLiAgcHJldmlvdXMgbm90aW9ucyB0eXBpY2FsbHkgaW5mZXJy
ZWQgc29tZSBraW5kIG9mIGR5bmFtaWMgY29uZmlnIGJhc2VkIG9uIHN1YnNjcmliZXIgcHJvZmls
ZS4gIHdpbGwgYmUgZ29vZCB0byBtYWtlIHN1cmUgd2UncmUgc3RpbGwgYWxpZ25lZCBvbiB0aGlz
Li4uDQoNCkVORC4NCg==

------_=_NextPart_001_01C70FCD.E05BCA67
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://www1.ietf.org/mailman/listinfo/ancp

------_=_NextPart_001_01C70FCD.E05BCA67--




From ancp-bounces@ietf.org Fri Nov 24 09:52:18 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GncPW-00078B-KY; Fri, 24 Nov 2006 09:52:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GncPV-000773-AC
	for ancp@ietf.org; Fri, 24 Nov 2006 09:52:13 -0500
Received: from smail.alcatel.fr ([62.23.212.165])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GncPT-0006vV-Io
	for ancp@ietf.org; Fri, 24 Nov 2006 09:52:13 -0500
Received: from bemail01.netfr.alcatel.fr (bemail01.netfr.alcatel.fr
	[155.132.251.32])
	by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kAOEqE06004646;
	Fri, 24 Nov 2006 15:52:14 +0100
Received: from [172.31.148.94] ([172.31.148.94])
	by bemail01.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163)
	with ESMTP id 2006112415520855:7575 ;
	Fri, 24 Nov 2006 15:52:08 +0100 
Message-ID: <45670718.7060507@alcatel.be>
Date: Fri, 24 Nov 2006 15:52:08 +0100
From: Sven.Ooghe@alcatel.be
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bharat Joshi <bharat_joshi@infosys.com>, ancp@ietf.org
Subject: Re: [ANCP] Some questions and suggestion on Framework document..
References: <6031539A3C7B964581EFCE2E205D6EEF0199E13C@BLRKECMSG01.ad.infosys
	.com>	 <4565855C.6070506@alcatel.be>	
	<6031539A3C7B964581EFCE2E205D6EEF0189E625@BLRKECMSG01.ad.infosys.com>	
	<4566ADF4.5060906@alcatel.be> <1164358552.2656.35.camel@magadha>
In-Reply-To: <1164358552.2656.35.camel@magadha>
X-MIMETrack: Itemize by SMTP Server on BEMAIL01/BE/ALCATEL(Release
	5.0.13aHF163 | June 23, 2005) at 11/24/2006 15:52:08,
	Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 | June
	23, 2005) at 11/24/2006 15:52:09,
	Serialize complete at 11/24/2006 15:52:09
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0
Cc: 
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org

Hi Bharat,

We'll put in a few words on the scenario when a user wants his bandwidth 
to be increased but the ANCP session is down.

Thanks again for the in-depth review.

Regards,
Sven

Bharat Joshi wrote:

> Hi Sven,
> 
>    Thanks for your reply. Please see my response in line. I have removed
> those questions/suggestion where we both are in sync.
> 
> Thanks,
> Bharat
> 
> 
>>>>* In section 2.4.1, through we talk about port-addressing schemes but we
>>>>
>>>>
>>>>>are not actually referring to ports here. There are configurations where
>>>>>we can have multiple user sessions and 'Circuit-Id' would be different
>>>>>for each one of them. So what I want to say is that we are identifying
>>>>>the circuit instead of ports. So you may want to change the section
>>>>>title to something which reflects the same.
>>>
>>>><Sven>
>>>>The intent is indeed to address the logical ports, which could be an ATM 
>>>>PVC or an Ethernet VLAN on top of a physical DSL port. If we chage the
>>>>text to reflect "Locial port addressing", would that be ok?
>>>></Sven>
>>>>
>>>I am not sure if we can call them a Logical port. Generally, there are different VCs which have different User sessions so it could be called circuit-addressing scheme or something in similar lines.
>>>
>>
>><Sven>
>>I kind of preferred "logical port" since circuit matches the ATM VC, but 
>>is less appropriate for Ethernet VLAN IDs...
>>
>>Let me suggest the following: we will change the title to "Circuit 
>>addressing scheme" and be explicit on what it means in the paragraph 
>>below, unless someone else on this list argues why not to use this name.
>></Sven>
>>
> 
> Sounds good to me.
> 
> 
>>>>* I am trying to understand the need of communicating DSL line data rate
>>>>
>>>>
>>>>>to NAS for each user. Does it anyway help in over-subscription on NAS? I
>>>>>can understand that NAS can modify its scheduling parameters for a given
>>>>>user based on the line data rate provided by AN but what is the
>>>>>advantage?
>>>
>>>><Sven>
>>>>Have a look at section 2.9, item (3) in TR-101:
>>>>http://www.dslforum.org/techwork/tr/TR-101.pdf
>>>>It describes the rationale for knowing the actual DSL net data rate at
>>>>the level of the NAS. More info can also be found in TR-059.
>>>></Sven>
>>>
>>>Though this draft refer to TR-101 but as ANCP can be used in not only for DSL environment I would suggest to add some of these details here. This will make sure that people from other type of Access Networks need not go back to TR-101 to understand the need of it.
>>>
>>
>><Sven>
>>That's fine.
>></Sven>
>>
> 
> Ok.
> 
> 
>>>>* In Access loop configuration, Its mentioned that Access loop
>>>>
>>>>
>>>>>configuration is available with the Access provided which controls the
>>>>>DSL line profile in Access Node. Now subscriber wants some changes in
>>>>>it, its mentioned that ANCP can propagate this change without an
>>>>>operator intervention using policy server. My question is if ANCP is
>>>>>down and during this time, a change happens, how would the system react?
>>>>>This change may have happened in the Access Node but NAS may not be
>>>>>aware of this change. Is this correct?
>>>
>>>><Sven>
>>>>The assumption we take is that when the use case "Access loop 
>>>>configuration" is used, the profile to be used on the access loop will
>>>>be stored in a central policy system. If the ANCP session is down, no
>>>>changes should happen to the access loop configuration.
>>>>If for some reason a change happens, we assume that this translates in a
>>>>certain (new) DSL net data rate when the line is operational again. At
>>>>that point, the Access Node will send this information to the NAS, which
>>>>can take a corrective action if needed (e.g. change to another profile
>>>>on the Access Node).
>>>></Sven>
> 
> 
>>Please correct me if I am wrong here. I assume that when some
>>particular configuration for a user needs to be changes, it is done in
>>
>>>the policy server. NAS picks it up from the policy server and pass it
>>>on the Access Node using ANCP. Now when ANCP is down, this is not
>>>possible. What I understand from this is if any such configurations
>>>that NAS passes to AN using ANCP, will not take any affect until ANCP
>>>is down.
>>>So what I meant is that if a user configuration changes when ANCP is
>>
>>down though user would expect the changes to take place immediately,
>>it may not happen.
>>
>>>Please let me know if I am missing something here.
>>
>><Sven>
>>You're correct. If the ANCP session is down, it cannot be used to change 
>>some of the Access Node parameters. In this case, the NAS could for 
>>instance report this to the policy management system which triggered the 
>>configuration action. The latter could then use application specific 
>>signaling towards the customer to notify him about the fact that the 
>>change could not be performed at that time.
>></Sven>
>>
> 
> If a user wants his bandwidth to be increased and ANCP is down, this may
> take some time to happen. So I feel it need to be mentioned here.
> 
> 
>>>>* Does ANCP require a configuration of 'upstream router port' [interface
>>>>
>>>>
>>>>>to reach NAS] in ANs? or does it run a protocols to figure out the
>>>>>interface on which it can reach to the upstream router [NAS]
>>>>>dynamically?
>>>>
>>>><Sven>
>>>>This aspect is not touched upon in the framework description. The
>>>>assumption we take is that the interface is configured.
>>>></Sven>
>>>>
>>>I think it would be good if we can create a section for Assumptions in the document and add such details there. 
>>
>><Sven>
>>I agree that this needs to be added to the document somewhere, either in 
>>a separate "Assumptions" section, or in one of the existing sections. 
>>We'll look into this.</Sven>
>>
> 
> Ok.
> 
> 
>>>>* In section 4.4.1, how does a logical port treated here? Can a logical
>>>>
>>>>
>>>>>port built on top of a physical port be attached to a different
>>>>>partition?
>>>>
>>>><Sven>
>>>>Our assumption at this point is that all logical ports on top of the 
>>>>same physical port will be associated with the same partition. In other
>>>>words, partitioning is performed at the level of the physical port only.
>>>></Sven>
>>>>
>>>Ok. I think it would be a good idea to add this to the new section Assumptions.
>>>
>>
>><Sven>
>>We'll for sure add this to the document. I'm not yet convinced of the 
>>need for a dedicated "Assumptions" section for this. Are you ok if we 
>>decide this during updating?
>></Sven>
>>
> 
> Yes. That should be fine.
> 
> 
>>>><Sven>
>>>>How about referring to a separate security document
>>>
>>>
>>>>(draft-moustafa-ancp-security-threats-00.txt)? Would that make sense?
>>>></Sven>
>>>>
>>>
>>>I am sure that there are lot of things to consider in the security consideration and a separate document does make sense.
>>
>><Sven>
>>Ok, great. BTW some weeks ago, the chairs issued a call for review of 
>>draft-moustafa-ancp-security-threats-00.txt and whether or not people 
>>support this draft becoming a working group ID.
>></Sven>
> 
> 
> Ok. I shall take a look at this document and pass on my comments to
> author if I have any.
> 
> 
> **************** CAUTION - Disclaimer *****************
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
> 

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Fri Nov 24 09:54:16 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GncRQ-0000De-Do; Fri, 24 Nov 2006 09:54:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GncRP-0000AF-MT
	for ancp@ietf.org; Fri, 24 Nov 2006 09:54:11 -0500
Received: from kecgate06.progeon.com ([61.95.162.82]
	helo=Kecgate06.infosys.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GncRO-0007Oa-Fo
	for ancp@ietf.org; Fri, 24 Nov 2006 09:54:11 -0500
Received: from indhubbhs01.ad.infosys.com ([192.168.200.81]) by
	Kecgate06.infosys.com with InterScan Messaging Security Suite;
	Fri, 24 Nov 2006 20:16:48 +0530
Received: from BLRKECMSG04.ad.infosys.com ([172.25.213.134]) by
	indhubbhs01.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 24 Nov 2006 20:21:57 +0530
Received: from BLRKECMSG01.ad.infosys.com ([172.25.213.131]) by
	BLRKECMSG04.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 24 Nov 2006 20:21:56 +0530
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 24 Nov 2006 20:21:56 +0530
Message-ID: <6031539A3C7B964581EFCE2E205D6EEF0189E627@BLRKECMSG01.ad.infosys.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-topic: Some questions and suggestion on
	draft-wadhwa-gsmp-l2control-configuration-02.txt
Thread-index: AccP2BZmnGBHZxeBTUGcuSxE7dCtwQ==
From: "bharat_joshi" <bharat_joshi@infosys.com>
To: <ancp@ietf.org>
X-OriginalArrivalTime: 24 Nov 2006 14:51:56.0933 (UTC)
	FILETIME=[16916B50:01C70FD8]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 21be852dc93f0971708678c18d38c096
Subject: [ANCP] Some questions and suggestion on
	draft-wadhwa-gsmp-l2control-configuration-02.txt
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org


Hi,

    I have couple of questions and suggestion on the document describing=
 gsmp-l2control-configuration.

* There are some issues in the format of this draft. Page numbers in 'Table=
 of contents' does not seems to be properly formatted.

* "Conventions used in this document" contains the same text as in=
 "Specification Requirements". I think this text are genrally added under=
 "Terminology" section.

* If you are not using xml2rfc, I would suggest you to use it.

*  This draft uses lots of short-forms so it would be a good idea to add a=
 Terminology section which describe all these terms.

* Typo in Introduction. "In the scope of these specification" -> "The scope=
 of these specification"

* I think it can be mentioned somewhere that if there are GSMPv3 enabled=
 switches in Network, they would discard these extended messages based on=
 the version.

* In section 3.1, towards the end of the 4th paragraph, there is something=
 missing in the following sentence:

" relieving a potential requirement for them to build infrastructure to=
 attach more directly to the various Access Networks."

* In section 3.1, 7th paragraph, I feel following statement need to be=
 rephrased:

"In order to allow IP QoS support over an existing non-IP-aware layer 2=
 access network without using multiple layer 2 QoS classes, a mechanism=
 based on hierarchical scheduling is used."

Something like:

A mechanism based on hierarchical scheduling can be used in BRAS to allow=
 IP QoS support over an existing non-IP-aware layer 2 access network which=
 does not use multiple layer 2 QoS classes.

* In section 3.2, We have seen some of the networks using [1:1] PVC-VLAN as=
 one of the other ways to create virtual circuit. In this case, one PVC in=
 AN is statically attached to one VLAN. I am not sure if you want to add=
 this to the text.

* In section 4.1, I think 'protocol' can be added in 'control plane' in the=
 following statement:

"There is a requirement for a control plane between service-oriented"

* In section 4.1, statement "optimized multicast replication to enable=
 video services over DSL," is not entirely True. Please correct me if I am=
 wrong, ANCP is used to configure AN with only those Multicast addresses=
 for which a user is authorized. Actually speaking, the same thing could=
 have been achieved using IGMP snooping but in that case, we can not=
 authorize because User's profile is with BRAS. So what I meant is that=
 ANCP actually helps in restricting access of Multicast traffic to those=
 who are authorize to receive it. Optimization of Multicast replication=
 could have been achieved using IGMP snooping.

* In section 4.2.1, please rephrase the first statement in the 2nd=
 paragraph. It could look as follows:

Across organizational boundaries, OSS systems are rarely able to enforce=
 consistency of such data in a reliable and scalable manner.

* In section 4.2.2, its mentioned that BRAS needs to learn the initial=
 attributes of DSL line before the subscriber logs in and access the=
 provisioned service. How is this achieved?

* In figure 2, Does 'DSL signal' means that DSL port is UP? or is it that=
 DSL line has seen signal and gets into training mode?

* In section 4.3.1, last line on 4th paragraph:
"conveyed by the BRAS in ANCP." -> "conveyed by the BRAS via ANCP."

* In section 4.4, protocol support for ANCP transactional Multicast will be=
 provided in future. If required, We can help in creating a document with=
 the use-cases.

* In Port-management messages, what is the identifier of the port?

* Title for section 4 and 5 is same. You may want to change one of them.

* Why do we need to use TCP as the transport here? It could have been on=
 top of IP like other protocols. We also have a keep-alive to keep the=
 adjacency between NAS and AN.

* Its not clear whether the keep-alive messages contains Capability TLVs as=
 well. Also there are couple of fields in the messages which are not=
 described like partition-id.

* In section 5.3, its mentioned that capability data field can be empty if=
 its a boolean capability. Does this mean that if a capability is not=
 included, its not enabled?

* I think new capability types MUST be allocated by IANA.

* In section 5.4.1.1, first statement in the description of 'Extension=
 Value' is not clear. Can you please rephrase this?

* While explaining that what field in a message is being set to what value,=
 I think it would be good if its done in point wise. For example: in=
 section 5.4.2. I think its more readable if we write that in following=
 way:

   o The GSMP Event message with PORT UP message type (80) is used for=0D
     conveying DSL line attributes to the BRAS.

   o The version field should be set to 3, and the sub field should be
     set to 1.

   o The I and subMessage fields SHOULD be set to 1 to signify no
     fragmentation.

   o The Port and Label fields should be set to 0.=0D

   o The =93Port Session Number=94 should be set to 0, and the =93Event
     Sequence Number=94 should be 0.=0D

   o The Tech Type field is extended with new type "DSL". The value for
     this field is 0x05.=0D

   o The message SHOULD be generated when a line first comes UP, or any
     of the attributes of the line change e.g. the line re-trains to a
     different rate or one or more of the configured line attributes
     are administratively modified.

* Though fields in these messages is defined in GSMP RFC but I feel that we=
 should at least mention the use of each field in this draft as well.

* What are Encaps PPPoA NULL, IPoA NULL?

* In section 5.4.4, Out of the three TLVs to identify circuit-id, I think=
 it should say that atleast one MUST be available.

* How is the last 2 bytes of Type(OAM-Loopback-Test-Parameter) need to be=
 populated by BRAS or processed by AN?

* If the timeout is zero, does AN need to generate a reply of the test? if=
 yes, if AN used an in-house timer but could not complete the test, what=
 should it do?

* How do AN identified whether it needs to generate F4 OAM cell or F5 OAM=
 cell?

Thanks & Regards,
Bharat

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended=
 solely for the use of the addressee(s). If you are not the intended=
 recipient, please notify the sender by e-mail and delete the original=
 message. Further, you are not to copy, disclose, or distribute this e-mail=
 or its contents to any other person and any such actions are unlawful.=
 This e-mail may contain viruses. Infosys has taken every reasonable=
 precaution to minimize this risk, but is not liable for any damage you may=
 sustain as a result of any virus in this e-mail. You should carry out your=
 own virus checks before opening the e-mail or attachment. Infosys reserves=
 the right to monitor and review the content of all messages sent to or=
 from this e-mail address. Messages sent to or from this e-mail address may=
 be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Mon Nov 27 11:45:23 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gojba-0005zC-Qp; Mon, 27 Nov 2006 11:45:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GojbX-0005vR-SK
	for ancp@ietf.org; Mon, 27 Nov 2006 11:45:15 -0500
Received: from kecgate06.infosys.com ([61.95.162.82])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GojXE-0005NV-9V
	for ancp@ietf.org; Mon, 27 Nov 2006 11:40:53 -0500
Received: from INDHUBBHS02.ad.infosys.com ([192.168.200.82]) by
	Kecgate06.infosys.com with InterScan Messaging Security Suite;
	Mon, 27 Nov 2006 22:03:16 +0530
Received: from BLRKECMSG04.ad.infosys.com ([172.25.213.134]) by
	INDHUBBHS02.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 27 Nov 2006 22:08:27 +0530
Received: from BLRKECMSG01.ad.infosys.com ([172.25.213.131]) by
	BLRKECMSG04.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 27 Nov 2006 22:08:27 +0530
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 27 Nov 2006 22:08:24 +0530
Message-ID: <6031539A3C7B964581EFCE2E205D6EEF01A25DDE@BLRKECMSG01.ad.infosys.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-topic: Few questions and suggestions on
	draft-moustafa-ancp-security-threats-00.txt 
Thread-index: AccSQY3E3Aq/l1v9Q3Cj/PmvPmq1lw==
From: "bharat_joshi" <bharat_joshi@infosys.com>
To: <ancp@ietf.org>
X-OriginalArrivalTime: 27 Nov 2006 16:38:27.0661 (UTC)
	FILETIME=[76FA5FD0:01C71242]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3
Subject: [ANCP] Few questions and suggestions on
	draft-moustafa-ancp-security-threats-00.txt 
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org


Hi,

    I have few questions and suggestions on this document:

* In abstract, it is mentioned that ANCP is used for "qos-, service- and
subscriber-related operations between NAS and AN". I think it should say
'xxx-related configurations; instead of 'xxx-related operations'.

* In abstract, the first statement in the second paragraph is a little
complex. You may want rephrase it something similar to:

This document investigates security threats that all network elements
running ANCP could encounter. This document develops a threat model for
ANCP security aiming to decide which security functions are required.

* In Introduction, second paragraph, first sentence, I think it would be
good it we can add "for ANCP" at the end to make it "[ID...] illustrates
the framework, usage scenarios and general requirements for ANCP"

* In Introduction, second paragraph, Second sentence is not very clear.
Its mentioned that document derives security requirements from ANCP.
Should not it be "for ANCP" instead of "from ANCP" here?

* In Introduction, "Message Protection", there is something missing in
statement:

"This applies both to ANCP payloads, and ANCP should also provide such
protection as a service to the different service parameters between the
two peers."

What is "both" referring to? I think you may want to add ANCP header and
payload.

* In some ANCP document, it is proposed that ANCP session would be
initiated by AN and so the NAS address need to be configured in there.
In this case, how NAS will authenticate or authorize an AN?

* In figure #1, I think you may want to show a ATM/Ethernet Switch
between NAS and AN as there could be multiple ANs connected to one NAS
through this switch.

* Does the Home Gateway shown in figure #1 is at correct place? Should
not it be before CPE? Something like HGW --- CPE --- Access Node?

* In the definition of 'Home Gateway', I did not get the 'DSL Network
Termination' part? Can you explain a little more?

* In section 4, typo "Attackers against the access network" -> " Attacks
against the access network".

* In section 5.3, Third paragraph, first sentence " When the ANCP allows
the AN to dynamically discovery the NAS". I did not find any such
reference in the ANCP framework document.

* Typo "When the ANCP allows the AN to dynamically discovery the NAS
then a", "discovery" -> "discover"

* I think it might be good if we can add details on how a particular
threat can be achieved and what is the solution to avoid a particular
threeat?

* How does AN ensure that a request has been received by the correct
NAS?

* In section 5.4, there is a list of information which a adversary can
get if it can access the traffic and analyze it. I think this is
possible only when the adversary has access to the network between AN
and NAS. Right?

* In section 6.1, how a passive attacker can use the information of
'access loop configuration' for any access? Learning this information
may not be proper but how it is a security threat?

* In section 6.1, I think off-path attack will always be there even if
ANCP does not exist. I am not sure if this is required.

* In section 6.1, you may want to use 'lists' to talk about the attacks.
For example:

Those attacks may be:

o Passive attacks
     o First passive attack
     o Second passive attack
o Active attacks
     o First active attack
     o Second active attack

    I am sure this way it will be more readable.

* Are you sure that replaying of Config requests can be done by an
attacker over TCP connections? I understand that after sniffing syn/ack,
it can generate a possible message but can I replay the old config
request which TCP itself would discard?

* In section 6.4, how do we damage proxy functionality in AN? BTW, is AN
doing IGMP snooping or IGMP proxy?

* In section 6.4, more descriptive format of security consideration for
Multicast can be added.

* What triggers the requirement "The protocol solution SHOULD
distinguish the control messages from the data"?

* I think you should add details of specific cases on how a threat can
be realized and what ANCP should do to avoid it?

Thanks & Regards,
Bharat


**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended=
 solely for the use of the addressee(s). If you are not the intended=
 recipient, please notify the sender by e-mail and delete the original=
 message. Further, you are not to copy, disclose, or distribute this e-mail=
 or its contents to any other person and any such actions are unlawful.=
 This e-mail may contain viruses. Infosys has taken every reasonable=
 precaution to minimize this risk, but is not liable for any damage you may=
 sustain as a result of any virus in this e-mail. You should carry out your=
 own virus checks before opening the e-mail or attachment. Infosys reserves=
 the right to monitor and review the content of all messages sent to or=
 from this e-mail address. Messages sent to or from this e-mail address may=
 be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Mon Nov 27 17:17:23 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Goomt-0004RY-BD; Mon, 27 Nov 2006 17:17:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gooms-0004RT-UA
	for ancp@ietf.org; Mon, 27 Nov 2006 17:17:18 -0500
Received: from tcmail31.telekom.de ([217.6.95.238])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Goomr-0001TI-EA
	for ancp@ietf.org; Mon, 27 Nov 2006 17:17:18 -0500
Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.telekom.de with ESMTP;
	Mon, 27 Nov 2006 23:17:10 +0100
Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by
	S4DE8PSAAGT.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 27 Nov 2006 23:17:10 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
x-mimeole: Produced By Microsoft Exchange V6.5
Date: Mon, 27 Nov 2006 23:19:48 +0100
Message-Id: <6439282641581441A36F7F6F83ED2ED2016640A9@S4DE8PSAAFQ.mitte.t-com.de>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Opoen Issues Minutes 67th IETF meeting;
	section "4.1 ANCP Functional Requirements"
Thread-Index: AccSciZqSlqCvDTnR/mXcBavb1T9/g==
From: "Haag, T" <Thomas.Haag@t-systems.com>
To: <ancp@ietf.org>,
    <sven.ooghe@alcatel.be>
X-OriginalArrivalTime: 27 Nov 2006 22:17:10.0268 (UTC)
	FILETIME=[C8321BC0:01C71271]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d
Cc: "Hamacher, Peter" <Peter.Hamacher@t-com.net>
Subject: [ANCP] Opoen Issues Minutes 67th IETF meeting;
	section "4.1 ANCP Functional Requirements"
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1106256717=="
Errors-To: ancp-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1106256717==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C71271.C7F425D5"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C71271.C7F425D5
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Sven, all,

=20

Let me take the opportunity to point out a statement which was stated in
the minutes of the 67.IETF meeting.

=20

=20

"Thomas (T-Systems) - regarding reqs for elements need to be clear e.g.
what scalability requirements are (100s, or 1000s of nodes?).  Need to
consider this in the framework as to which environment the protocol
should be implemented in.  e.g. what works with 100s of nodes won't
necessarily work for a large network."

=20

=20

Following that remark I propose to update section "4.1 ANCP Functional
Requirements" in a way as shown below because it comes very close to
large scale (and already existing) architectures!

=20

New text proposal:

=20

"The ANCP protocol MUST allow fast-paced transactions, in the order to
provide real time transactions of a full populated Access Node to the
NAS.

The protocol MUST allow fast completion of a given operation, in the
order of magnitude of tens of milliseconds. =20

In large scale networks Access Nodes are provisioned but not always
fully populated. Therefore the protocol MUST be scalable enough to allow
a given NAS to control thousands of Access Nodes (e.g. typical 5000 -
10000)."

=20

=20

Regards

=20

Thomas

=20


------_=_NextPart_001_01C71271.C7F425D5
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.E-MailFormatvorlage17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DDE link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courier New"'>Sven, =
all,<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courier New"'>Let me =
take the
opportunity to point out a statement which was stated in the minutes of =
the 67.IETF
meeting.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&#8220;Thomas
(T-Systems) - regarding reqs for elements need to be clear e.g. what
scalability requirements are (100s, or 1000s of nodes?).&nbsp; Need to =
consider
this in the framework as to which environment the protocol should be
implemented in.&nbsp; e.g. what works with 100s of nodes won't =
necessarily work
for a large network.&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courier =
New"'>Following that
remark I propose to update section &#8220;4.1 ANCP Functional =
Requirements&#8221;
in a way as shown below because it comes very close to large scale (and =
already
existing) architectures!<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courier New"'>New =
text
proposal:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&#8220;The ANCP protocol
MUST allow fast-paced transactions, in the order to provide real time =
transactions
of a full populated Access Node to the NAS.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courier New"'>The =
protocol MUST
allow fast completion of a given operation, in the order of magnitude of =
tens
of milliseconds.&nbsp; <o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courier New"'>In =
large scale
networks Access Nodes are provisioned but not always fully populated. =
Therefore
the protocol MUST be scalable enough to allow a given NAS to control =
thousands
of Access Nodes (e.g. typical 5000 - =
10000).&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courier =
New"'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courier =
New"'>Regards<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-autospace:none'><font size=3D2 =
face=3D"Courier New"><span
lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Courier =
New"'>Thomas<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C71271.C7F425D5--


--===============1106256717==
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://www1.ietf.org/mailman/listinfo/ancp

--===============1106256717==--




From ancp-bounces@ietf.org Tue Nov 28 02:48:02 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Goxgx-0005iB-Gs; Tue, 28 Nov 2006 02:47:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Goxgw-0005i1-RO
	for ancp@ietf.org; Tue, 28 Nov 2006 02:47:46 -0500
Received: from smail.alcatel.fr ([62.23.212.165])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Goxgu-0000UR-CS
	for ancp@ietf.org; Tue, 28 Nov 2006 02:47:46 -0500
Received: from bemail01.netfr.alcatel.fr (bemail01.netfr.alcatel.fr
	[155.132.251.32])
	by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id kAS7lmvE027266;
	Tue, 28 Nov 2006 08:47:48 +0100
Received: from [172.31.148.94] ([172.31.148.94])
	by bemail01.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163)
	with ESMTP id 2006112808474101:2665 ;
	Tue, 28 Nov 2006 08:47:41 +0100 
Message-ID: <456BE99D.1050205@alcatel.be>
Date: Tue, 28 Nov 2006 08:47:41 +0100
From: Sven.Ooghe@alcatel.be
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Haag, T" <Thomas.Haag@t-systems.com>, ancp@ietf.org
References: <6439282641581441A36F7F6F83ED2ED2016640A9@S4DE8PSAAFQ.mitte.t-com.de>
In-Reply-To: <6439282641581441A36F7F6F83ED2ED2016640A9@S4DE8PSAAFQ.mitte.t-com.de>
X-MIMETrack: Itemize by SMTP Server on BEMAIL01/BE/ALCATEL(Release
	5.0.13aHF163 | June 23, 2005) at 11/28/2006 08:47:41,
	Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 | June
	23, 2005) at 11/28/2006 08:47:42
X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: "Hamacher, Peter" <Peter.Hamacher@t-com.net>
Subject: [ANCP] Re: Opoen Issues Minutes 67th IETF meeting;
 section "4.1 ANCP Functional Requirements"
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0876207122=="
Errors-To: ancp-bounces@ietf.org

--===============0876207122==
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: base64

SGkgVGhvbWFzLA0KDQpBZ3JlZWQsIHdlJ2xsIG1ha2UgdGhlIGNoYW5nZSB1c2luZyB5b3VyIHRl
eHQgcHJvcG9zYWwuDQoNClJlZ2FyZHMsDQpTdmVuDQoNCkhhYWcsIFQgd3JvdGU6DQo+IFN2ZW4s
IGFsbCwNCj4gDQo+ICANCj4gDQo+IExldCBtZSB0YWtlIHRoZSBvcHBvcnR1bml0eSB0byBwb2lu
dCBvdXQgYSBzdGF0ZW1lbnQgd2hpY2ggd2FzIHN0YXRlZCBpbiANCj4gdGhlIG1pbnV0ZXMgb2Yg
dGhlIDY3LklFVEYgbWVldGluZy4NCj4gDQo+ICANCj4gDQo+ICANCj4gDQo+IJNUaG9tYXMgKFQt
U3lzdGVtcykgLSByZWdhcmRpbmcgcmVxcyBmb3IgZWxlbWVudHMgbmVlZCB0byBiZSBjbGVhciBl
LmcuIA0KPiB3aGF0IHNjYWxhYmlsaXR5IHJlcXVpcmVtZW50cyBhcmUgKDEwMHMsIG9yIDEwMDBz
IG9mIG5vZGVzPykuICBOZWVkIHRvIA0KPiBjb25zaWRlciB0aGlzIGluIHRoZSBmcmFtZXdvcmsg
YXMgdG8gd2hpY2ggZW52aXJvbm1lbnQgdGhlIHByb3RvY29sIA0KPiBzaG91bGQgYmUgaW1wbGVt
ZW50ZWQgaW4uICBlLmcuIHdoYXQgd29ya3Mgd2l0aCAxMDBzIG9mIG5vZGVzIHdvbid0IA0KPiBu
ZWNlc3NhcmlseSB3b3JrIGZvciBhIGxhcmdlIG5ldHdvcmsulA0KPiANCj4gIA0KPiANCj4gIA0K
PiANCj4gRm9sbG93aW5nIHRoYXQgcmVtYXJrIEkgcHJvcG9zZSB0byB1cGRhdGUgc2VjdGlvbiCT
NC4xIEFOQ1AgRnVuY3Rpb25hbCANCj4gUmVxdWlyZW1lbnRzlCBpbiBhIHdheSBhcyBzaG93biBi
ZWxvdyBiZWNhdXNlIGl0IGNvbWVzIHZlcnkgY2xvc2UgdG8gDQo+IGxhcmdlIHNjYWxlIChhbmQg
YWxyZWFkeSBleGlzdGluZykgYXJjaGl0ZWN0dXJlcyENCj4gDQo+ICANCj4gDQo+IE5ldyB0ZXh0
IHByb3Bvc2FsOg0KPiANCj4gIA0KPiANCj4gk1RoZSBBTkNQIHByb3RvY29sIE1VU1QgYWxsb3cg
ZmFzdC1wYWNlZCB0cmFuc2FjdGlvbnMsIGluIHRoZSBvcmRlciB0byANCj4gcHJvdmlkZSByZWFs
IHRpbWUgdHJhbnNhY3Rpb25zIG9mIGEgZnVsbCBwb3B1bGF0ZWQgQWNjZXNzIE5vZGUgdG8gdGhl
IE5BUy4NCj4gDQo+IFRoZSBwcm90b2NvbCBNVVNUIGFsbG93IGZhc3QgY29tcGxldGlvbiBvZiBh
IGdpdmVuIG9wZXJhdGlvbiwgaW4gdGhlIA0KPiBvcmRlciBvZiBtYWduaXR1ZGUgb2YgdGVucyBv
ZiBtaWxsaXNlY29uZHMuIA0KPiANCj4gSW4gbGFyZ2Ugc2NhbGUgbmV0d29ya3MgQWNjZXNzIE5v
ZGVzIGFyZSBwcm92aXNpb25lZCBidXQgbm90IGFsd2F5cyANCj4gZnVsbHkgcG9wdWxhdGVkLiBU
aGVyZWZvcmUgdGhlIHByb3RvY29sIE1VU1QgYmUgc2NhbGFibGUgZW5vdWdoIHRvIGFsbG93IA0K
PiBhIGdpdmVuIE5BUyB0byBjb250cm9sIHRob3VzYW5kcyBvZiBBY2Nlc3MgTm9kZXMgKGUuZy4g
dHlwaWNhbCA1MDAwIC0gDQo+IDEwMDAwKS6UDQo+IA0KPiAgDQo+IA0KPiAgDQo+IA0KPiBSZWdh
cmRzDQo+IA0KPiAgDQo+IA0KPiBUaG9tYXMNCj4gDQo+ICANCj4gDQo=



--===============0876207122==
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://www1.ietf.org/mailman/listinfo/ancp

--===============0876207122==--



From ancp-bounces@ietf.org Tue Nov 28 08:25:46 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Gp2xu-0002te-JP; Tue, 28 Nov 2006 08:25:38 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp2xt-0002sz-62
	for ancp@ietf.org; Tue, 28 Nov 2006 08:25:37 -0500
Received: from kecgate02.infosysconsulting.com ([61.95.162.76]
	helo=Kecgate02.infosys.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp2xq-0001uK-U3
	for ancp@ietf.org; Tue, 28 Nov 2006 08:25:37 -0500
Received: from indhubbhs01.ad.infosys.com ([192.168.200.81]) by
	Kecgate02.infosys.com with InterScan Messaging Security Suite;
	Tue, 28 Nov 2006 18:49:24 +0530
Received: from BLRKECMSG14.ad.infosys.com ([172.22.147.6]) by
	indhubbhs01.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 28 Nov 2006 18:53:10 +0530
Received: from BLRKECMSG01.ad.infosys.com ([172.25.213.131]) by
	BLRKECMSG14.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 28 Nov 2006 18:53:10 +0530
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 28 Nov 2006 18:53:10 +0530
Message-ID: <0CA51D55A5DC42479FEBFBCEB7D5F183D44C3C@BLRKECMSG01.ad.infosys.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-topic: Some queries on draft-wadhwa-gsmp-l2control-configuration-02.txt
Thread-index: AccS8FkmBhhuqIwXTiSlRqjmhGGDeg==
From: "pavan_kurapati" <pavan_kurapati@infosys.com>
To: <ancp@ietf.org>
X-OriginalArrivalTime: 28 Nov 2006 13:23:10.0797 (UTC)
	FILETIME=[59988FD0:01C712F0]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Subject: [ANCP] Some queries on
	draft-wadhwa-gsmp-l2control-configuration-02.txt
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org


1. How do we handle bundled DSL links with technologies like G.Bond or=
 IMAoSHDSL?=0D

2. Section : 5.4.2 : Access-Loop-Circuit-ID/Access-Aggregation-Circuit-ID

I think the format can include shelf/slot/port for subtending DSLAMs to be=
 more clear. I know TR-101 specifies slot as a string which can contain=
 shelf number as well. But we can be more specific and say that in case of=
 a single chassis shelf number is always 1?

Thanks,
Pavan

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended=
 solely for the use of the addressee(s). If you are not the intended=
 recipient, please notify the sender by e-mail and delete the original=
 message. Further, you are not to copy, disclose, or distribute this e-mail=
 or its contents to any other person and any such actions are unlawful.=
 This e-mail may contain viruses. Infosys has taken every reasonable=
 precaution to minimize this risk, but is not liable for any damage you may=
 sustain as a result of any virus in this e-mail. You should carry out your=
 own virus checks before opening the e-mail or attachment. Infosys reserves=
 the right to monitor and review the content of all messages sent to or=
 from this e-mail address. Messages sent to or from this e-mail address may=
 be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp



From ancp-bounces@ietf.org Wed Nov 29 08:57:32 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GpPvz-0007Eu-SU; Wed, 29 Nov 2006 08:57:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GpPvy-0007Ek-Q2
	for ancp@ietf.org; Wed, 29 Nov 2006 08:57:10 -0500
Received: from ug-out-1314.google.com ([66.249.92.174])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpPvx-0007G2-8e
	for ancp@ietf.org; Wed, 29 Nov 2006 08:57:10 -0500
Received: by ug-out-1314.google.com with SMTP id 72so1563831ugd
	for <ancp@ietf.org>; Wed, 29 Nov 2006 05:57:08 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
	b=Pa8Cz/ySwRZDnXdAYjodfsPr6Ze4cY6snzCQB0djVQGm978zZL6wZ8FtJvD9YiDsMbHTlR+skDgieD1vekH0Fv6yXJXFXI/HFWiLZ8mnCbDaKgleNjqcLZuNZcNMhjnkYqo7bcNpKZbmdmWgBO9RelbC09RdxulSr0mjGyYqwU4=
Received: by 10.67.97.7 with SMTP id z7mr3370266ugl.1164808628229;
	Wed, 29 Nov 2006 05:57:08 -0800 (PST)
Received: by 10.66.218.11 with HTTP; Wed, 29 Nov 2006 05:57:08 -0800 (PST)
Message-ID: <dea40f930611290557g352287dcg78bc1a19b1c55bee@mail.gmail.com>
Date: Wed, 29 Nov 2006 14:57:08 +0100
From: "Hasnaa Moustafa" <hasnaa.moustafa@gmail.com>
To: ancp@ietf.org
In-Reply-To: <E1Gojps-0004Nu-It@megatron.ietf.org>
MIME-Version: 1.0
References: <E1Gojps-0004Nu-It@megatron.ietf.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: fb4923faae7d2b1be4e504c39e80ae8d
Subject: [ANCP] Re: ANCP Digest, Vol 6, Issue 12
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1181365466=="
Errors-To: ancp-bounces@ietf.org

--===============1181365466==
Content-Type: multipart/alternative; 
	boundary="----=_Part_29953_19004216.1164808628111"

------=_Part_29953_19004216.1164808628111
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Bharat,
Thanks for your comments.
Below are our replies inserted in your message. Hope that it is more clear
now.

Regards,
Hassnaa


On 11/27/06, ancp-request@ietf.org <ancp-request@ietf.org> wrote:
>
> Send ANCP mailing list submissions to
>        ancp@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://www1.ietf.org/mailman/listinfo/ancp
> or, via email, send a message with subject or body 'help' to
>        ancp-request@ietf.org
>
> You can reach the person managing the list at
>        ancp-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ANCP digest..."
>
>
> Today's Topics:
>
>   1.  Few questions and suggestions on
>      draft-moustafa-ancp-security-threats-00.txt  (bharat_joshi)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 27 Nov 2006 22:08:24 +0530
> From: "bharat_joshi" <bharat_joshi@infosys.com>
> Subject: [ANCP] Few questions and suggestions on
>        draft-moustafa-ancp-security-threats-00.txt
> To: <ancp@ietf.org>
> Message-ID:
>        <
> 6031539A3C7B964581EFCE2E205D6EEF01A25DDE@BLRKECMSG01.ad.infosys.com>
> Content-Type: text/plain;       charset="us-ascii"
>
>
> Hi,
>
>    I have few questions and suggestions on this document:
>
> * In abstract, it is mentioned that ANCP is used for "qos-, service- and
> subscriber-related operations between NAS and AN". I think it should say
> 'xxx-related configurations; instead of 'xxx-related operations'.

 Hassnaa

This brief description for ANCP exactly conforms to the framework <
draft-ietf-ancp-framework-00.txt>. We are based on this draft in deriving
the threat model, and it is really "operations" and not just
"configurations". Advertising DSL line sync speed is not a "configuration",
the same for OAM.
Hassnaa/

* In abstract, the first statement in the second paragraph is a little
> complex. You may want rephrase it something similar to:
>
> This document investigates security threats that all network elements
> running ANCP could encounter. This document develops a threat model for
> ANCP security aiming to decide which security functions are required.



Hassnaa

For clarity and readability, it can be re-phrased, as you suggested.
Hassnaa/

* In Introduction, second paragraph, first sentence, I think it would be
> good it we can add "for ANCP" at the end to make it "[ID...] illustrates
> the framework, usage scenarios and general requirements for ANCP"



Hassnaa

Right
Hassnaa/

* In Introduction, second paragraph, Second sentence is not very clear.
> Its mentioned that document derives security requirements from ANCP.
> Should not it be "for ANCP" instead of "from ANCP" here?



Hassnaa

Right
Hassnaa/

* In Introduction, "Message Protection", there is something missing in
> statement:
>
> "This applies both to ANCP payloads, and ANCP should also provide such
> protection as a service to the different service parameters between the
> two peers."
>
> What is "both" referring to? I think you may want to add ANCP header and
> payload.



Hassnaa

Yes.
Hassnaa/

* In some ANCP document, it is proposed that ANCP session would be
> initiated by AN and so the NAS address need to be configured in there.
> In this case, how NAS will authenticate or authorize an AN?



Hassnaa

This is considered in the security requirements given in the draft. In
Section 7 in the draft, the following are mentioned:

-         the protocol solution MUST offer authentication of the AN to the
NAS

-         the protocol solution MUST offer authentication of the NAS to the
AN

-         the protocol solution MUST allow authorization to take place at
the AN and the NAS

But how this should take place is not the objective of this draft. The main
objective is deriving the security requirements, but not giving security
solutions.

Hassnaa/

* In figure #1, I think you may want to show a ATM/Ethernet Switch
> between NAS and AN as there could be multiple ANs connected to one NAS
> through this switch.



Hassnaa

The architectural details are given in the framework draft, and we mentioned
that we follow the same thing.
Hassnaa/

* Does the Home Gateway shown in figure #1 is at correct place? Should
> not it be before CPE? Something like HGW --- CPE --- Access Node?



Hassnaa

This conforms to the architecture given in the framework draft. Also,
considering the Access Loop real deployments, I do not see how the HGW
should be before the CPE as it is supposed to connect different CPEs to the
AN.
Hassnaa/

* In the definition of 'Home Gateway', I did not get the 'DSL Network
> Termination' part? Can you explain a little more?



Hassnaa

Details are given in the framework draft. This draft focuses on the threats
and security requirements. We think that no more explanation is needed,
especially that redundancy is not recommended between the two drafts, but
rather the security requirements draft should complement the framework
draft.
Hassnaa/

* In section 4, typo "Attackers against the access network" -> " Attacks
> against the access network".



Hassnaa

Yes, this was mentioned in our reply to the previous received comments.
Hassnaa/

* In section 5.3, Third paragraph, first sentence " When the ANCP allows
> the AN to dynamically discovery the NAS". I did not find any such
> reference in the ANCP framework document.



Hassnaa

This relates to ANCP functioning and is not related to the Use Cases defined
in the framework draft. It is mentioned that the ANCP allows the AN to
dynamically discover the NAS, given that ANCP will use TCP for exchanging
protocol messages 'as mentioned in the draft <
draft-wadhwa-gsmp-l2control-configuration-02.txt>). In this case, the
session is initiated from the AN to the NAS to avoid static provisioning on
the NAS for all the ANs that are being served by the NAS.

But since man-in-the-middle attack s also possible without dynamic
discovery, this sentence may be removed.
Hassnaa/

> * Typo "When the ANCP allows the AN to dynamically discovery the NAS
> then a", "discovery" -> "discover"



Hassnaa

Yes, it is typos.
Hassnaa/

* I think it might be good if we can add details on how a particular
> threat can be achieved and what is the solution to avoid a particular
> threeat?



Hassnaa

This is not at all the objective of this draft, we are not providing
solutions. We are providing general guidelines for any upcoming solutions.
Hassnaa/

* How does AN ensure that a request has been received by the correct
> NAS?



Hassnaa

The following security requirements, given in the draft (Section 7), can
assure this:

-         The protocol solution MUST offer authentication of the NAS to the
AN.

-         The protocol solution MUST provide data origin authenticity.
Hassnaa/

* In section 5.4, there is a list of information which a adversary can
> get if it can access the traffic and analyze it. I think this is
> possible only when the adversary has access to the network between AN
> and NAS. Right?



Hassnaa

No, not necessary. This may also take place by an external attacker on the
Internet affecting the Access Loop attributes sharing between the NAS and
the policy server (the second bullet in Section 6.1 explains this).
Hassnaa/

* In section 6.1, how a passive attacker can use the information of
> 'access loop configuration' for any access? Learning this information
> may not be proper but how it is a security threat?



Hassnaa

Here it is meant unauthorized information access by an attacker, through
later message modification for example. Re-phrasing will take place for
clarity.

Also, in case of 2 NASs belonging to different ISPs, one ISP may not see the
information of the other ISP. This might be sensitive information in some
cases.

Hassnaa/

* In section 6.1, I think off-path attack will always be there even if
> ANCP does not exist. I am not sure if this is required.



Hassnaa

This is required to show the off-path attacks that impact the proper
functioning of ANCP. In other words, we are showing all the attacks that
relates to ANCP functioning whether (on-path or off-path).
Hassnaa/

* In section 6.1, you may want to use 'lists' to talk about the attacks.
> For example:
>
> Those attacks may be:
>
> o Passive attacks
>     o First passive attack
>     o Second passive attack
> o Active attacks
>     o First active attack
>     o Second active attack
>
>    I am sure this way it will be more readable.



Hassnaa

Re-formatting may be considered for readability
Hassnaa/

* Are you sure that replaying of Config requests can be done by an
> attacker over TCP connections? I understand that after sniffing syn/ack,
> it can generate a possible message but can I replay the old config
> request which TCP itself would discard?



Hassnaa

Using TCP does not help to prevent replay attacks but provides some degree
of return routability checks through sequence numbers use. However, TCP is
not 100% safe for replay, it is only very hard.

Hassnaa/

* In section 6.4, how do we damage proxy functionality in AN? BTW, is AN
> doing IGMP snooping or IGMP proxy?



Hassnaa

As mentioned, signaling truncating disturb the proxy functionality (may be
rewording is needed). The framework draft states (in the multicast use case
description) that AN can do both IGMP snooping and IGMP proxy, this is
according to the framework draft. Any way, Section 6.4 has to wait until the
framework document tells more about multicast in the next version, then this
section will be updated accordingly.
Hassnaa/

* In section 6.4, more descriptive format of security consideration for
> Multicast can be added.



Hassnaa

Same as the previous point, since the multicast use case is in current
progress within the framework draft, we are thus analyzing the possible
threats related to this use case in a general and abstract manner.
Hassnaa/

* What triggers the requirement "The protocol solution SHOULD
> distinguish the control messages from the data"?



Hassnaa

This is important to help preventing replay signaling messages, and it is a
SHOULD requirement and not MUST.
Hassnaa/

* I think you should add details of specific cases on how a threat can
> be realized and what ANCP should do to avoid it?



Hassnaa

The draft contains a reasonable threat analysis,

Regarding (what ANCP should do) as you mentioned, will go through solution
details and is not the objective.
Hassnaa/

Thanks again,
Regards,
Hassnaa

Thanks & Regards,
> Bharat
>
>
> **************** CAUTION - Disclaimer *****************
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended
> solely for the use of the addressee(s). If you are not the intended
> recipient, please notify the sender by e-mail and delete the original
> message. Further, you are not to copy, disclose, or distribute this e-mail
> or its contents to any other person and any such actions are unlawful. This
> e-mail may contain viruses. Infosys has taken every reasonable precaution to
> minimize this risk, but is not liable for any damage you may sustain as a
> result of any virus in this e-mail. You should carry out your own virus
> checks before opening the e-mail or attachment. Infosys reserves the right
> to monitor and review the content of all messages sent to or from this
> e-mail address. Messages sent to or from this e-mail address may be stored
> on the Infosys e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
>
>
>
> ------------------------------
>
> _______________________________________________
> ANCP mailing list
> ANCP@ietf.org
> https://www1.ietf.org/mailman/listinfo/ancp
>
>
> End of ANCP Digest, Vol 6, Issue 12
> ***********************************
>

------=_Part_29953_19004216.1164808628111
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div>Hi Bharat,</div>
<div>Thanks for your comments. </div>
<div>Below are our replies inserted in your message. Hope that it is more c=
lear now.</div>
<div>&nbsp;</div>
<div>Regards,</div>
<div>Hassnaa<br><br>&nbsp;</div>
<div><span class=3D"gmail_quote">On 11/27/06, <b class=3D"gmail_sendername"=
><a href=3D"mailto:ancp-request@ietf.org">ancp-request@ietf.org</a></b> &lt=
;<a href=3D"mailto:ancp-request@ietf.org">ancp-request@ietf.org</a>&gt; wro=
te:
</span>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Send ANCP mailing list submissio=
ns to<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href=3D"mailto:ancp@ietf.o=
rg">ancp@ietf.org</a><br><br>To subscribe or unsubscribe via the World Wide=
 Web, visit
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href=3D"https://www1.ietf.org/m=
ailman/listinfo/ancp">https://www1.ietf.org/mailman/listinfo/ancp</a><br>or=
, via email, send a message with subject or body 'help' to<br>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; <a href=3D"mailto:ancp-request@ietf.org">
ancp-request@ietf.org</a><br><br>You can reach the person managing the list=
 at<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href=3D"mailto:ancp-owner@ie=
tf.org">ancp-owner@ietf.org</a><br><br>When replying, please edit your Subj=
ect line so it is more specific
<br>than &quot;Re: Contents of ANCP digest...&quot;<br><br><br>Today's Topi=
cs:<br><br>&nbsp;&nbsp;1.&nbsp;&nbsp;Few questions and suggestions on<br>&n=
bsp;&nbsp;&nbsp;&nbsp; draft-moustafa-ancp-security-threats-00.txt&nbsp;&nb=
sp;(bharat_joshi)<br><br><br>----------------------------------------------=
------------------------
<br><br>Message: 1<br>Date: Mon, 27 Nov 2006 22:08:24 +0530<br>From: &quot;=
bharat_joshi&quot; &lt;<a href=3D"mailto:bharat_joshi@infosys.com">bharat_j=
oshi@infosys.com</a>&gt;<br>Subject: [ANCP] Few questions and suggestions o=
n
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; draft-moustafa-ancp-security-threa=
ts-00.txt<br>To: &lt;<a href=3D"mailto:ancp@ietf.org">ancp@ietf.org</a>&gt;=
<br>Message-ID:<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<a href=3D"mail=
to:6031539A3C7B964581EFCE2E205D6EEF01A25DDE@BLRKECMSG01.ad.infosys.com">
6031539A3C7B964581EFCE2E205D6EEF01A25DDE@BLRKECMSG01.ad.infosys.com</a>&gt;=
<br>Content-Type: text/plain;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; charset=
=3D&quot;us-ascii&quot;<br><br><br>Hi,<br><br>&nbsp;&nbsp; I have few quest=
ions and suggestions on this document:<br>
<br>* In abstract, it is mentioned that ANCP is used for &quot;qos-, servic=
e- and<br>subscriber-related operations between NAS and AN&quot;. I think i=
t should say<br>'xxx-related configurations; instead of 'xxx-related operat=
ions'.
</blockquote>
<div>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Hassnaa</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">This brief description for ANCP exactly conforms to the framework &lt=
;draft-ietf-ancp-framework-00.txt
&gt;. We are based on this draft in deriving the threat model, and it is re=
ally &quot;operations&quot; and not just &quot;configurations&quot;. Advert=
ising DSL line sync speed is not a &quot;configuration&quot;, the same for =
OAM.
</font></span></p><span lang=3D"EN-GB" style=3D"FONT-SIZE: 12pt; COLOR: #33=
66ff; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast=
-font-family: SimSun; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA=
">
Hassnaa/<br style=3D"mso-special-character: line-break"></span></div><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">* In abstract, the first stateme=
nt in the second paragraph is a little<br>complex. You may want rephrase it=
 something similar to:
<br><br>This document investigates security threats that all network elemen=
ts<br>running ANCP could encounter. This document develops a threat model f=
or<br>ANCP security aiming to decide which security functions are required.
</blockquote>
<div>&nbsp;</div>
<div>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Hassnaa</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">For clarity and readability, it can be re-phrased, as you suggested.<=
/font>
</span></p><span lang=3D"EN-GB" style=3D"FONT-SIZE: 12pt; COLOR: #3366ff; F=
ONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-f=
amily: SimSun; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA">Hassn=
aa/
</span></div><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">* In Introduction, second paragr=
aph, first sentence, I think it would be<br>good it we can add &quot;for AN=
CP&quot; at the end to make it &quot;[ID...] illustrates
<br>the framework, usage scenarios and general requirements for ANCP&quot;<=
/blockquote>
<div>&nbsp;</div>
<div>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Hassnaa</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Right</font></span></p><span lang=3D"EN-GB" style=3D"FONT-SIZE: 12pt;=
 COLOR: #3366ff; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; =
mso-fareast-font-family: SimSun; mso-fareast-language: ZH-CN; mso-bidi-lang=
uage: AR-SA">
Hassnaa/</span></div><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">* In Introduction, second paragr=
aph, Second sentence is not very clear.<br>Its mentioned that document deri=
ves security requirements from ANCP.
<br>Should not it be &quot;for ANCP&quot; instead of &quot;from ANCP&quot; =
here?</blockquote>
<div>&nbsp;</div>
<div>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Hassnaa</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Right</font></span></p><span lang=3D"EN-GB" style=3D"FONT-SIZE: 12pt;=
 COLOR: #3366ff; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; =
mso-fareast-font-family: SimSun; mso-fareast-language: ZH-CN; mso-bidi-lang=
uage: AR-SA">
Hassnaa/</span></div><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">* In Introduction, &quot;Message=
 Protection&quot;, there is something missing in<br>statement:<br><br>&quot=
;This applies both to ANCP payloads, and ANCP should also provide such
<br>protection as a service to the different service parameters between the=
<br>two peers.&quot;<br><br>What is &quot;both&quot; referring to? I think =
you may want to add ANCP header and<br>payload.</blockquote>
<div>&nbsp;</div>
<div>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Hassnaa</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Yes.</font></span></p><span lang=3D"EN-GB" style=3D"FONT-SIZE: 12pt; =
COLOR: #3366ff; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; m=
so-fareast-font-family: SimSun; mso-fareast-language: ZH-CN; mso-bidi-langu=
age: AR-SA">
Hassnaa/</span></div><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">* In some ANCP document, it is p=
roposed that ANCP session would be<br>initiated by AN and so the NAS addres=
s need to be configured in there.
<br>In this case, how NAS will authenticate or authorize an AN?</blockquote=
>
<div>&nbsp;</div>
<div>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Hassnaa</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">This is considered in the security requirements given in the draft. I=
n Section 7 in the draft, the following are mentioned:
</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt 36pt; TEXT-INDENT: -18p=
t; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt"><font face=3D"Times Ne=
w Roman"><span lang=3D"EN-GB" style=3D"COLOR: #3366ff; mso-ansi-language: E=
N-GB; mso-fareast-font-family: 'Times New Roman'">
<span style=3D"mso-list: Ignore">-<span style=3D"FONT: 7pt 'Times New Roman=
'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><s=
pan lang=3D"EN-GB" style=3D"COLOR: #3366ff; mso-ansi-language: EN-GB">the p=
rotocol solution MUST offer authentication of the AN to the NAS
</span></font></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt 36pt; TEXT-INDENT: -18p=
t; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt"><font face=3D"Times Ne=
w Roman"><span lang=3D"EN-GB" style=3D"COLOR: #3366ff; mso-ansi-language: E=
N-GB; mso-fareast-font-family: 'Times New Roman'">
<span style=3D"mso-list: Ignore">-<span style=3D"FONT: 7pt 'Times New Roman=
'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><s=
pan lang=3D"EN-GB" style=3D"COLOR: #3366ff; mso-ansi-language: EN-GB">the p=
rotocol solution MUST offer authentication of the NAS to the AN
</span></font></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt 36pt; TEXT-INDENT: -18p=
t; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt"><font face=3D"Times Ne=
w Roman"><span lang=3D"EN-GB" style=3D"COLOR: #3366ff; mso-ansi-language: E=
N-GB; mso-fareast-font-family: 'Times New Roman'">
<span style=3D"mso-list: Ignore">-<span style=3D"FONT: 7pt 'Times New Roman=
'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><s=
pan lang=3D"EN-GB" style=3D"COLOR: #3366ff; mso-ansi-language: EN-GB">the p=
rotocol solution MUST allow authorization to take place at the AN and the N=
AS
</span></font></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">But how this should take place is not the objective of this draft. Th=
e main objective is deriving the security requirements, but not giving secu=
rity solutions.
</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Hassnaa/</font></span></p></div><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">* In figure #1, I think you may =
want to show a ATM/Ethernet Switch<br>between NAS and AN as there could be =
multiple ANs connected to one NAS
<br>through this switch.</blockquote>
<div>&nbsp;</div>
<div>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Hassnaa</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">The architectural details are given in the framework draft, and we me=
ntioned that we follow the same thing.=20
</font></span></p><span lang=3D"EN-GB" style=3D"FONT-SIZE: 12pt; COLOR: #33=
66ff; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast=
-font-family: SimSun; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA=
">
Hassnaa/ </span></div><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">* Does the Home Gateway shown in=
 figure #1 is at correct place? Should<br>not it be before CPE? Something l=
ike HGW --- CPE --- Access Node?
</blockquote>
<div>&nbsp;</div>
<div>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Hassnaa</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">This conforms to the architecture given in the framework draft. Also,=
 considering the Access Loop real deployments, I do not see how the HGW sho=
uld be before the CPE as it is supposed to connect different CPEs to the AN=
.
<span style=3D"mso-spacerun: yes">&nbsp; </span></font></span></p><span lan=
g=3D"EN-GB" style=3D"FONT-SIZE: 12pt; COLOR: #3366ff; FONT-FAMILY: 'Times N=
ew Roman'; mso-ansi-language: EN-GB; mso-fareast-font-family: SimSun; mso-f=
areast-language: ZH-CN; mso-bidi-language: AR-SA">
Hassnaa/</span></div><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">* In the definition of 'Home Gat=
eway', I did not get the 'DSL Network<br>Termination' part? Can you explain=
 a little more?
</blockquote>
<div>&nbsp;</div>
<div>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Hassnaa</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Details are given in the framework draft. This draft focuses on the t=
hreats and security requirements. We think that no more explanation is need=
ed, especially that redundancy is not recommended between the two drafts, b=
ut rather the security requirements draft should complement the framework d=
raft.
</font></span></p><span lang=3D"EN-GB" style=3D"FONT-SIZE: 12pt; COLOR: #33=
66ff; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast=
-font-family: SimSun; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA=
">
Hassnaa/</span></div><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">* In section 4, typo &quot;Attac=
kers against the access network&quot; -&gt; &quot; Attacks<br>against the a=
ccess network&quot;.
</blockquote>
<div>&nbsp;</div>
<div>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Hassnaa</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Yes, this was mentioned in our reply to the previous received comment=
s.</font>
</span></p><span lang=3D"EN-GB" style=3D"FONT-SIZE: 12pt; COLOR: #3366ff; F=
ONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-f=
amily: SimSun; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA">Hassn=
aa/
</span></div><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">* In section 5.3, Third paragrap=
h, first sentence &quot; When the ANCP allows<br>the AN to dynamically disc=
overy the NAS&quot;. I did not find any such
<br>reference in the ANCP framework document.</blockquote>
<div>&nbsp;</div>
<div>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Hassnaa</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><font face=3D"Times Ne=
w Roman"><span lang=3D"EN-GB" style=3D"COLOR: #3366ff; mso-ansi-language: E=
N-GB">This relates to ANCP functioning and is not related to the Use Cases =
defined in the framework draft. It is mentioned that the ANCP allows the AN=
 to dynamically discover the NAS, given that ANCP will use TCP for exchangi=
ng protocol messages 'as mentioned in the draft &lt;
</span><span lang=3D"EN-GB" style=3D"mso-ansi-language: EN-GB"> <span style=
=3D"COLOR: #3366ff">draft-wadhwa-gsmp-l2control-configuration-02.txt&gt;). =
In this case, the session is initiated from the AN to the NAS to avoid stat=
ic provisioning on the NAS for all the ANs that are being served by the NAS=
.
</span></span></font></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">But since man-in-the-middle attack s also possible without dynamic di=
scovery, this sentence may be removed.
</font></span><span lang=3D"EN-GB" style=3D"mso-ansi-language: EN-GB"><br><=
font face=3D"Times New Roman"><span style=3D"COLOR: #3366ff">Hassnaa/</span=
> </font></span><br></p></div>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">* Typo &quot;When the ANCP allow=
s the AN to dynamically discovery the NAS<br>then a&quot;, &quot;discovery&=
quot; -&gt; &quot;discover&quot;
</blockquote>
<div>&nbsp;</div>
<div>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Hassnaa</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Yes, it is typos.</font></span></p><span lang=3D"EN-GB" style=3D"FONT=
-SIZE: 12pt; COLOR: #3366ff; FONT-FAMILY: 'Times New Roman'; mso-ansi-langu=
age: EN-GB; mso-fareast-font-family: SimSun; mso-fareast-language: ZH-CN; m=
so-bidi-language: AR-SA">
Hassnaa/</span></div><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">* I think it might be good if we=
 can add details on how a particular<br>threat can be achieved and what is =
the solution to avoid a particular
<br>threeat?</blockquote>
<div>&nbsp;</div>
<div>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Hassnaa</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">This is not at all the objective of this draft, we are not providing =
solutions. We are providing general guidelines for any upcoming solutions.=
=20
</font></span></p><span lang=3D"EN-GB" style=3D"FONT-SIZE: 12pt; COLOR: #33=
66ff; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast=
-font-family: SimSun; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA=
">
Hassnaa/</span></div><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">* How does AN ensure that a requ=
est has been received by the correct<br>NAS?</blockquote>
<div>&nbsp;</div>
<div>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Hassnaa</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">The following security requirements, given in the draft (Section 7), =
can assure this:
</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt 36pt; TEXT-INDENT: -18p=
t; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt"><font face=3D"Times Ne=
w Roman"><span lang=3D"EN-GB" style=3D"COLOR: #3366ff; mso-ansi-language: E=
N-GB; mso-fareast-font-family: 'Times New Roman'">
<span style=3D"mso-list: Ignore">-<span style=3D"FONT: 7pt 'Times New Roman=
'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><s=
pan lang=3D"EN-GB" style=3D"COLOR: #3366ff; mso-ansi-language: EN-GB">The p=
rotocol solution MUST offer authentication of the NAS to the AN.
</span></font></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt 36pt; TEXT-INDENT: -18p=
t; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt"><font face=3D"Times Ne=
w Roman"><span lang=3D"EN-GB" style=3D"COLOR: #3366ff; mso-ansi-language: E=
N-GB; mso-fareast-font-family: 'Times New Roman'">
<span style=3D"mso-list: Ignore">-<span style=3D"FONT: 7pt 'Times New Roman=
'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><s=
pan lang=3D"EN-GB" style=3D"COLOR: #3366ff; mso-ansi-language: EN-GB">The p=
rotocol solution MUST provide data origin authenticity.=20
</span></font></p><span lang=3D"EN-GB" style=3D"FONT-SIZE: 12pt; COLOR: #33=
66ff; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast=
-font-family: SimSun; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA=
">
Hassnaa/</span></div><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">* In section 5.4, there is a lis=
t of information which a adversary can<br>get if it can access the traffic =
and analyze it. I think this is
<br>possible only when the adversary has access to the network between AN<b=
r>and NAS. Right?</blockquote>
<div>&nbsp;</div>
<div>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Hassnaa</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">No, not necessary. This may also take place by an external attacker o=
n the Internet affecting the Access Loop attributes sharing between the NAS=
 and the policy server (the second bullet in Section=20
6.1 explains this). <span style=3D"mso-spacerun: yes">&nbsp;</span><br>Hass=
naa/</font></span></p></div><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">* In section 6.1, how a passive =
attacker can use the information of<br>'access loop configuration' for any =
access? Learning this information
<br>may not be proper but how it is a security threat?</blockquote>
<div>&nbsp;</div>
<div>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Hassnaa</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Here it is meant unauthorized information access by an attacker, thro=
ugh later message modification for example. Re-phrasing will take place for=
 clarity.
</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Also, in case of 2 NASs belonging to different ISPs, one ISP may not =
see the information of the other ISP. This might be sensitive information i=
n some cases.=20
</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Hassnaa/</font></span></p></div><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">* In section 6.1, I think off-pa=
th attack will always be there even if<br>ANCP does not exist. I am not sur=
e if this is required.
</blockquote>
<div>&nbsp;</div>
<div>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Hassnaa</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">This is required to show the off-path attacks that impact the proper =
functioning of ANCP. In other words, we are showing all the attacks that re=
lates to ANCP functioning whether (on-path or off-path).
</font></span></p><span lang=3D"EN-GB" style=3D"FONT-SIZE: 12pt; COLOR: #33=
66ff; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast=
-font-family: SimSun; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA=
">
Hassnaa/</span></div><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">* In section 6.1, you may want t=
o use 'lists' to talk about the attacks.<br>For example:<br><br>Those attac=
ks may be:
<br><br>o Passive attacks<br>&nbsp;&nbsp;&nbsp;&nbsp;o First passive attack=
<br>&nbsp;&nbsp;&nbsp;&nbsp;o Second passive attack<br>o Active attacks<br>=
&nbsp;&nbsp;&nbsp;&nbsp;o First active attack<br>&nbsp;&nbsp;&nbsp;&nbsp;o =
Second active attack<br><br>&nbsp;&nbsp; I am sure this way it will be more=
 readable.</blockquote>

<div>&nbsp;</div>
<div>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Hassnaa</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Re-formatting may be considered for readability</font></span></p><spa=
n lang=3D"EN-GB" style=3D"FONT-SIZE: 12pt; COLOR: #3366ff; FONT-FAMILY: 'Ti=
mes New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-family: SimSun; =
mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA">
Hassnaa/</span></div><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">* Are you sure that replaying of=
 Config requests can be done by an<br>attacker over TCP connections? I unde=
rstand that after sniffing syn/ack,
<br>it can generate a possible message but can I replay the old config<br>r=
equest which TCP itself would discard?</blockquote>
<div>&nbsp;</div>
<div>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Hassnaa</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Using TCP does not help to prevent replay attacks but provides some d=
egree of return routability checks through sequence numbers use. However, T=
CP is not 100% safe for replay, it is only very hard.
</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Hassnaa/</font></span></p></div><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">* In section 6.4, how do we dama=
ge proxy functionality in AN? BTW, is AN<br>doing IGMP snooping or IGMP pro=
xy?
</blockquote>
<div>&nbsp;</div>
<div>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Hassnaa</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">As mentioned, signaling truncating disturb the proxy functionality (m=
ay be rewording is needed). The framework draft states (in the multicast us=
e case description) that AN can do both IGMP snooping and IGMP proxy, this =
is according to the framework draft. Any way, Section=20
6.4 has to wait until the framework document tells more about multicast in =
the next version, then this section will be updated accordingly.</font></sp=
an></p><span lang=3D"EN-GB" style=3D"FONT-SIZE: 12pt; COLOR: #3366ff; FONT-=
FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-famil=
y: SimSun; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA">
Hassnaa/</span></div><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">* In section 6.4, more descripti=
ve format of security consideration for<br>Multicast can be added.</blockqu=
ote>

<div>&nbsp;</div>
<div>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Hassnaa</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Same as the previous point, since the multicast use case is in curren=
t progress within the framework draft, we are thus analyzing the possible t=
hreats related to this use case in a general and abstract manner.
</font></span></p><span lang=3D"EN-GB" style=3D"FONT-SIZE: 12pt; COLOR: #33=
66ff; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast=
-font-family: SimSun; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA=
">
Hassnaa/</span></div><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">* What triggers the requirement =
&quot;The protocol solution SHOULD<br>distinguish the control messages from=
 the data&quot;?
</blockquote>
<div>&nbsp;</div>
<div>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Hassnaa</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">This is important to help preventing replay signaling messages, and i=
t is a SHOULD requirement and not MUST.
</font></span></p><span lang=3D"EN-GB" style=3D"FONT-SIZE: 12pt; COLOR: #33=
66ff; FONT-FAMILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast=
-font-family: SimSun; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA=
">
Hassnaa/</span></div><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">* I think you should add details=
 of specific cases on how a threat can<br>be realized and what ANCP should =
do to avoid it?
</blockquote>
<div>&nbsp;</div>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Hassnaa</font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">The draft contains a reasonable threat analysis, </font></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span lang=3D"EN-GB" s=
tyle=3D"COLOR: #3366ff; mso-ansi-language: EN-GB"><font face=3D"Times New R=
oman">Regarding (what ANCP should do) as you mentioned, will go through sol=
ution details and is not the objective.
</font></span></p>
<div><span lang=3D"EN-GB" style=3D"FONT-SIZE: 12pt; COLOR: #3366ff; FONT-FA=
MILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-family:=
 SimSun; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA">Hassnaa/</s=
pan>
</div>
<div><span lang=3D"EN-GB" style=3D"FONT-SIZE: 12pt; COLOR: #3366ff; FONT-FA=
MILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-family:=
 SimSun; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA"><br style=
=3D"mso-special-character: line-break">
Thanks again,</span></div>
<div><span lang=3D"EN-GB" style=3D"FONT-SIZE: 12pt; COLOR: #3366ff; FONT-FA=
MILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-family:=
 SimSun; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA">Regards,</s=
pan>
</div>
<div><span lang=3D"EN-GB" style=3D"FONT-SIZE: 12pt; COLOR: #3366ff; FONT-FA=
MILY: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-font-family:=
 SimSun; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA">Hassnaa<br =
style=3D"mso-special-character: line-break">
</span></div><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Thanks &amp; Regards,<br>Bharat<=
br><br><br>**************** CAUTION - Disclaimer *****************<br>This =
e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for=
 the use of the addressee(s). If you are not the intended recipient, please=
 notify the sender by e-mail and delete the original message. Further, you =
are not to copy, disclose, or distribute this e-mail or its contents to any=
 other person and any such actions are unlawful. This e-mail may contain vi=
ruses. Infosys has taken every reasonable precaution to minimize this risk,=
 but is not liable for any damage you may sustain as a result of any virus =
in this e-mail. You should carry out your own virus checks before opening t=
he e-mail or attachment. Infosys reserves the right to monitor and review t=
he content of all messages sent to or from this e-mail address. Messages se=
nt to or from this e-mail address may be stored on the Infosys e-mail syste=
m.
<br>***INFOSYS******** End of Disclaimer ********INFOSYS***<br><br><br><br>=
------------------------------<br><br>_____________________________________=
__________<br>ANCP mailing list<br><a href=3D"mailto:ANCP@ietf.org">ANCP@ie=
tf.org
</a><br><a href=3D"https://www1.ietf.org/mailman/listinfo/ancp">https://www=
1.ietf.org/mailman/listinfo/ancp</a><br><br><br>End of ANCP Digest, Vol 6, =
Issue 12<br>***********************************<br></blockquote></div><br>

------=_Part_29953_19004216.1164808628111--


--===============1181365466==
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://www1.ietf.org/mailman/listinfo/ancp

--===============1181365466==--




From ancp-bounces@ietf.org Thu Nov 30 01:34:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GpfUQ-0008UA-CK; Thu, 30 Nov 2006 01:33:46 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GpfUP-0008U5-DT
	for ancp@ietf.org; Thu, 30 Nov 2006 01:33:45 -0500
Received: from kecgate02.infosysconsulting.com ([61.95.162.76]
	helo=Kecgate02.infosys.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpfUN-00007R-0j
	for ancp@ietf.org; Thu, 30 Nov 2006 01:33:45 -0500
Received: from indhubbhs04.ad.infosys.com ([192.168.200.84]) by
	Kecgate02.infosys.com with InterScan Messaging Security Suite;
	Thu, 30 Nov 2006 11:57:31 +0530
Received: from BLRKECMSG14.ad.infosys.com ([172.22.147.6]) by
	indhubbhs04.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 30 Nov 2006 12:01:17 +0530
Received: from BLRKECMSG01.ad.infosys.com ([172.25.213.131]) by
	BLRKECMSG14.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 30 Nov 2006 12:01:17 +0530
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [ANCP] Re: ANCP Digest, Vol 6, Issue 12
Date: Thu, 30 Nov 2006 12:01:14 +0530
Message-ID: <6031539A3C7B964581EFCE2E205D6EEF01A9F2BD@BLRKECMSG01.ad.infosys.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-topic: [ANCP] Re: ANCP Digest, Vol 6, Issue 12
Thread-index: AccTvgWB0o95W91KQ4K5Z9vknhBTmQAeNc65
References: <E1Gojps-0004Nu-It@megatron.ietf.org>
	<dea40f930611290557g352287dcg78bc1a19b1c55bee@mail.gmail.com>
From: "bharat_joshi" <bharat_joshi@infosys.com>
To: "Hasnaa Moustafa" <hasnaa.moustafa@gmail.com>,
	<ancp@ietf.org>
X-OriginalArrivalTime: 30 Nov 2006 06:31:17.0711 (UTC)
	FILETIME=[244665F0:01C71449]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91
Cc: 
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Access Node Control Protocol working group mailing list
	<ancp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ancp>,
	<mailto:ancp-request@ietf.org?subject=subscribe>
Errors-To: ancp-bounces@ietf.org


Hi Hassnaa,

    Thanks for the response. Please see my response in line. I have
removed those comments where we both are in sync.

Thanks & Regards,
Bharat

        * In abstract, it is mentioned that ANC
> P is used for "qos-,
>         service- and
>         subscriber-related operations between NAS and AN". I think it
>         should say
>         'xxx-related configurations; instead of 'xxx-related
>         operations'.
> Hassnaa
>=0D
> This brief description for ANCP exactly conforms to the framework
> <draft-ietf-ancp-framework-00.txt >. We are based on this draft in
> deriving the threat model, and it is really "operations" and not just
> "configurations". Advertising DSL line sync speed is not a
> "configuration", the same for OAM.
>=0D
> Hassnaa/
>=0D
>=0D
Ok. If so can you make it 'operation and configurations'?

        * In some ANCP document, it is proposed that ANCP session would
>         be
>         initiated by AN and so the NAS address need to be configured
in
>         there.=0D
>         In this case, how NAS will authenticate or authorize an AN?
> =0D
> Hassnaa
>=0D
> This is considered in the security requirements given in the draft. In
> Section 7 in the draft, the following are mentioned:
>=0D
> -         the protocol solution MUST offer authentication of the AN to
> the NAS
>=0D
> -         the protocol solution MUST offer authentication of the NAS
to
> the AN
>=0D
> -         the protocol solution MUST allow authorization to take place
> at the AN and the NAS
>=0D
> But how this should take place is not the objective of this draft. The
> main objective is deriving the security requirements, but not giving
> security solutions.
>=0D
> Hassnaa/
>=0D
>=0D
Ok.

        * In figure #1, I think you may want to show a ATM/Ethernet
>         Switch
>         between NAS and AN as there could be multiple ANs connected to
>         one NAS=0D
>         through this switch.
> =0D
> Hassnaa
>=0D
> The architectural details are given in the framework draft, and we
> mentioned that we follow the same thing.=0D
>=0D
> Hassnaa/=0D
>=0D
>=0D
I just saw that the figure is same as is mentioned in the framework
document.

>       * Does the Home Gateway shown in figure #1 is at correct place?
>         Should
>         not it be before CPE? Something like HGW --- CPE --- Access
>         Node?
> =0D
> Hassnaa
>=0D
> This conforms to the architecture given in the framework draft. Also,
> considering the Access Loop real deployments, I do not see how the HGW
> should be before the CPE as it is supposed to connect different CPEs
to
> the AN.  =0D
>=0D
> Hassnaa/
>=0D
>=0D

I think the definition of CPE is what is making a difference. IMHO, CPE
is always the first device in the Customer Premises and typically is a
modem. If I am not wrong, your document also defines it as 'demarc'
point which is inline what I just mentioned.

In my opinion, Routing Gateway and Home gateway are generally connected
to the CPE and provides access to the internet to multiple users
connected to the home gateway.

Even if both Home Gateway and CPE is in the same device, still we should
be showing it as:

HGW --- CPE.

>       * In the definition of 'Home Gateway', I did not get the 'DSL
>         Network
>         Termination' part? Can you explain a little more?
> =0D
> Hassnaa
>=0D
> Details are given in the framework draft. This draft focuses on the
> threats and security requirements. We think that no more explanation
is
> needed, especially that redundancy is not recommended between the two
> drafts, but rather the security requirements draft should complement
the
> framework draft.
>=0D
> Hassnaa/
>=0D
OK. My mistake. Let me put this question to the framework document
authors.

        * In section 5.3, Third paragraph, first sentence " When the
>         ANCP allows
>         the AN to dynamically discovery the NAS". I did not find any
>         such=0D
>         reference in the ANCP framework document.
> =0D
> Hassnaa
>=0D
> This relates to ANCP functioning and is not related to the Use Cases
> defined in the framework draft. It is mentioned that the ANCP allows
the
> AN to dynamically discover the NAS, given that ANCP will use TCP for
> exchanging protocol messages 'as mentioned in the draft <
> draft-wadhwa-gsmp-l2control-configuration-02.txt>). In this case, the
> session is initiated from the AN to the NAS to avoid static
provisioning
> on the NAS for all the ANs that are being served by the NAS.
>=0D
> But since man-in-the-middle attack s also possible without dynamic
> discovery, this sentence may be removed.
> Hassnaa/=0D
>=0D
>=0D
Ok.

        * I think it might be good if we can add details on how a
>         particular
>         threat can be achieved and what is the solution to avoid a
>         particular=0D
>         threeat?
> =0D
> Hassnaa
>=0D
> This is not at all the objective of this draft, we are not providing
> solutions. We are providing general guidelines for any upcoming
> solutions.=0D
>=0D
> Hassnaa/
>=0D
>=0D
I did not question the objective of this draft. I have seen couple of
other drafts which describe security threats to protocols which does
note how a particular threat can be realized and what can be done to
avoid that threat. Anyway as you mentioned that its just for general
guidelines, I think its ok.


>         * In section 5.4, there is a list of information which a
>         adversary can
>         get if it can access the traffic and analyze it. I think this
>         is=0D
>         possible only when the adversary has access to the network
>         between AN
>         and NAS. Right?
> =0D
> Hassnaa
>=0D
> No, not necessary. This may also take place by an external attacker on
> the Internet affecting the Access Loop attributes sharing between the
> NAS and the policy server (the second bullet in Section 6.1 explains
> this). =0D
> Hassnaa/
>=0D
>=0D
What I meant is that if its an external attacker, how will he be able to
snoop the traffic?

        * In section 6.1, I think off-path attack will always be there
>         even if
>         ANCP does not exist. I am not sure if this is required.
> =0D
> Hassnaa
>=0D
> This is required to show the off-path attacks that impact the proper
> functioning of ANCP. In other words, we are showing all the attacks
that
> relates to ANCP functioning whether (on-path or off-path).
>=0D
> Hassnaa/
>=0D
>=0D
Ok.

        * In section 6.1, you may want to use 'lists' to talk about the
>         attacks.
>         For example:
>        =0D
>         Those attacks may be:=0D
>        =0D
>         o Passive attacks
>             o First passive attack
>             o Second passive attack
>         o Active attacks
>             o First active attack
>             o Second active attack
>        =0D
>            I am sure this way it will be more readable.
> =0D
> Hassnaa
>=0D
> Re-formatting may be considered for readability
>=0D
> Hassnaa/
>=0D
>=0D
Ok.

        * Are you sure that replaying of Config requests can be done by
>         an
>         attacker over TCP connections? I understand that after
sniffing
>         syn/ack,=0D
>         it can generate a possible message but can I replay the old
>         config
>         request which TCP itself would discard?
> =0D
> Hassnaa
>=0D
> Using TCP does not help to prevent replay attacks but provides some
> degree of return routability checks through sequence numbers use.
> However, TCP is not 100% safe for replay, it is only very hard.
>=0D
> Hassnaa/
>=0D
>=0D
Yes. I agree that using TCP can not be completely avoid replay attacks.

        * What triggers the requirement "The protocol solution SHOULD
>         distinguish the control messages from the data"?
> =0D
> Hassnaa
>=0D
> This is important to help preventing replay signaling messages, and it
> is a SHOULD requirement and not MUST.
>=0D
> Hassnaa/
>=0D
>=0D
How does it help in preventing replay signaling messages?

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended=
 solely for the use of the addressee(s). If you are not the intended=
 recipient, please notify the sender by e-mail and delete the original=
 message. Further, you are not to copy, disclose, or distribute this e-mail=
 or its contents to any other person and any such actions are unlawful.=
 This e-mail may contain viruses. Infosys has taken every reasonable=
 precaution to minimize this risk, but is not liable for any damage you may=
 sustain as a result of any virus in this e-mail. You should carry out your=
 own virus checks before opening the e-mail or attachment. Infosys reserves=
 the right to monitor and review the content of all messages sent to or=
 from this e-mail address. Messages sent to or from this e-mail address may=
 be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www1.ietf.org/mailman/listinfo/ancp