Subject: RE: [ANCP] Comments on draft-ietf-ancp-framework-02

From: "OOGHE Sven" <[email-masked]>
Date: Wed, 19 Sep 2007 19:01:42 +0200

Kirubaharan,
 
See inline (sorry for the long delay).

________________________________

From: [email-masked]
[mailto:[email-masked]] 
Sent: dinsdag 28 augustus 2007 11:14
To: [email-masked]
Subject: [ANCP] Comments on draft-ietf-ancp-framework-02

Hello Sven et al.,
 
Please find below my comments on ANCP protocol framework draft.
Covers most of the sections of the framework draft and points to
specific improvements required.
 
Page 6:
 
>From figure 1, it appears that the controller would reside in NAS
generally.
Not sure if a one-directional controller-reporter model would be the
best possible mechanism.  This needs to take into account the
possibility of extending this mechanism to US QoS control. With the new
evolving access model and architecture, possibility of more
user-generated content and highbandwidth streams are foreseen, moving
away from a provider-centric model. It would help to have provisions for
this, by having the control at either endpoints of ANCP adjacency. 
 
<Sven> I agree that some form of enforcement also happens at the NAS.
For the purpose of the framework however, the "enforcement function"
refers to a function that is "controlled" via ANCP. So I agree that the
NAS will also be involed in some form of QoS policy enforcement, but
that won't be configured via ANCP (but rather via e.g. some network
management or policy management interface). That is the point we are
trying to make with the figure.
 
Page 7:
 
Reporting and/or enforcement function - Here enforcement should probably
be a separate function as it can be in AN or NAS.
e.g. In NAS traffic shaping based on access loop rate report, the
enforcement function is in NAS.
Also, enforcement should be based on a policy decision or report. Hence,
port testing initiation may not be classified as an example of
enforcement.
 
<Sven> See previous comment: I agree that enforcement also happens on
the NAS, but the "enforcement function" in the framework refers to
something that is controlled by ANCP specifically.
 
Page 8:
 
2.2.2 - The term NID may be replaced with a term consistent with the
figure (HGW). More important than the protocol encapsulations, I think,
is the physical layer
technologies that may be used in access loop, i.e. different DSL types:
ADSL2+, VDSL2, VDSL, SHDSL, etc. (Assuming that this draft considers
just DSL as explained in introduction and not WiMAX or PON based access
networks)
 
<Sven> Ok, we can make the necessary changes.
 
2.2.3 - Paragraph 4 - Enforcement need not be in access node alone (e.g.
traffic shaping in NAS)
 
<Sven> See above.
 
Page 12:
 
3.1 - Section title - could be along the lines of "Access node
capabilities report", there seems to be no discovery involved.
Paragraph 2 - "topology of the access network" can be removed - it seems
to me that NAS does not have any knowledge of the network topology.
If needed, it can be addressed in a separate section -Access topology
discovery.
 
<Sven> The ANCP WG has discussed the terminology on several occations.
In the end the group decided to use the titles as indicated in the
current version. I would prefer to keep them this way, rather than
reopening this discussion.
 
Paragraph 3 - Reference to "Access port discovery" - needs to be made
consistent with section title.
 
<Sven> Ok, we will make the change.
 
Paragraph 5 - Not sure if NAS hierarchical scheduling based on DSL sync
rate would be the best possible thing to do. It may help to some extent.
But, ANs typically apply rate limiting per DSL port that may be far too
lower than the actual DSL sync rate. In such a case, it would make sense
to communicate the lesser of the two (sync rate or rate limit). This
again may not take into account the bandwidth consumed by multicast
traffic replicated locally at AN.
 
<Sven> The scenario assumes that no rate limiting is used on the Access
Node. Perhaps we should make this clear in the text?
 
Paragraph 6 - Access loop characteristics - Would be a good idea to add
DSL port bonding status. If ports are bonded at PHY level or at ATM or
ethernet level,
it is important that NAS is aware of this to determine the rate for
shaping.
 
<Sven> I'm not sure I got your point. Would it not suffice to announce
the bitrate and encapsulation used? That seems to be rather independent
of bonding. Of course, in case of bonding you would announce the total
bitrate across multiple interfaces. But I don't think that this
fundamentally changes the model or description.
 
Page 15:
 
3.2 Access loop configuration - It would be useful to make the result of
configuration always communicated back to NAS/controller. This is needed
to ensure synchronization between the elements as a configuration may
fail or may be denied by an AN.
 
<Sven> I agree. The framework mentions in the protocol requirements
section that there is a need to support request/response transactions
with ANCP. The details of how this is done for loop configuration is
covered in the protocol specification. So that should cover your
comment.
 
Paragraph 4 - QoS profile for an access loop - it would be good to have
an example profile and/or an illustration of this as it is an important
functionality.
 
<Sven> The details of the QoS profile are considered beyond the scope of
the framework. Perhaps we can add this statement to the text?
 
Page 18:
 
4.1 - A requirement is needed to specify the bandwidth limit for
protocol message overhead.
(ANCP protocol message overhead must not exceed x% of link capacity or x
kbps).
 
<Sven> I agree that the protocol should not eat up too much bandwidth,
but I don't know how we can put a number on it... 
 
Page 20:
 
4.4 - ANCP transport requirements - Redundant paths (VLAN/VC) for the
control channel can be made a requirement.
 
<Sven> Some redundancy may indeed be used below the ANCP layer. How this
is done is beyond the scope of the framework. I'm not sure we need to
spell it out, as it is not impacting the ANCP protocol operation as long
as this is invisible to the IP layer... 
 
Page 21:
 
4.5.1 - Last requirement - "AN should be able to work with redundant
controllers" - Elaborate on requirement for maintaining redundant
adjacencies and the failover mechanisms.
 
<Sven> The requirement as it stands is very high-level. I think more
discussion is required on the details of redundancy in ANCP, and how it
is achieved.
Perhaps we can reword this to: "The AN should be able to establish and
maintain ANCP Adjacencies to redundant controllers".
 
Page 22:
 
4.5.2 - ANCP capability negotiation procedure - framework and rationale
for this needs to be provided separately. 
 
<Sven> Section 4.2 has the following requirement:
   "The ANCP MUST provide a means for the AN and the NAS to perform
      capability negotiation and negotiate a common subset."
That covers the need for capability negotiation. Does this cover your
comment? 
 
Page 23:
 
4.6.1 - Minimum/maximum number of ANCP adjacencies to be supported by
NAS needs to be identified. Number of ANCP instances supported at NAS
can also be specified.
 
<Sven> In one of the previous IETF meetings, the ANCP WG has decided to
focus on the protocol requirements and not so much on the node
requirements. For this reason, you'll notice that the sections with node
requirements don't use MUST / SHOULD etc. For this reason, I don't think
we need to add specific requirements on the number of adjacencies or
instances to be supported.
 
Page 28:
 
6. - Management related requirements - When ANCP adjacency is up in AN,
any configuration parameter successfully updated by ANCP should not be
allowed to be changed by local EMS. This is required to ensure
consistency of data and operation.
 
<Sven> Good point. I think it should be added, unless someone speaks up.
 
A general comment:
 
On using the AN uplink attributes in ANCP, it might be necessary to
consider other bottlenecks in aggregation network. The links between AN
and NAS could be a direct-connect in which case, it is straightforwad.
However, when there are aggregation elements involved, it would help to
provide for extensions in the framework to identify any link bottleneck.
The capacity of links between aggregation elements or the links betweek
an aggregation node and NAS can be static or dynamic (link aggregation).
Identifying bottlenecks in the link capacity here would help do a more
accurate traffic scheduling or shaping at NAS as compared to having just
the AN uplink attributes.
 
<Sven> That would broaden the scope to using ANCP between aggregation
switches and the NAS. Currently this is not the charter of the WG...
 
Regards,
Sven
 
Thanks,
Kirubaharan
_______________________________________________
ANCP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ancp

---

From: Stefaan DE CNODDER <[email-masked]>
Date: Fri, 21 Sep 2007 17:38:03 +0200

> <Sven> Good point. I think it should be added, unless someone speaks up.

This looks to contradict with what is described on page 22, section 4.5.7:

"When using ANCP for Access Loop Configuration, the EMS needs to
configure on the Access Node which parameters may or may not be
modified using the Access Node Control Mechanism.  Furthermore, for
those parameters that may be modified using ANCP, the EMS needs to
specify the default values to be used when an Access Node comes up
after recovery."

According to section 4.5.7, an EMS can change the by ANCP successfuly 
updated parameter, my not allowing the parameter anymore to be 
configured by ANCP and then the EMS can change it.  From a conceptual 
point of view that is the same as an EMS that can change something that 
is successfuly updated by ANCP.

regards,
Stefaan

---

From: "OOGHE Sven" <[email-masked]>
Date: Mon, 24 Sep 2007 09:53:17 +0200

Stefaan,

I think you're right. This raises an interesting question: it looks like
allowing the EMS to "turn on" or "turn off" certain parameters to be
changed via ANCP may lead to race conditions, i.e. both the NAS and the
EMS wish to perform an action on the same parameter (EMS wishes to "turn
off" changes via ANCP / NAS wishes to change the value of the
parameter).

Perhaps it's simpler to determine beforehand what parameters may or may
not be changed via ANCP?

Regards,
Sven

-----Original Message-----
From: DE CNODDER Stefaan 
Sent: vrijdag 21 september 2007 17:38
To: OOGHE Sven
Cc: [email-masked]; [email-masked]
Subject: Re: [ANCP] Comments on draft-ietf-ancp-framework-02

> Page 28:
>  
> 6. - Management related requirements - When ANCP adjacency is up in 
> AN, any configuration parameter successfully updated by ANCP should 
> not be allowed to be changed by local EMS. This is required to ensure 

This looks to contradict with what is described on page 22, section
4.5.7:

"When using ANCP for Access Loop Configuration, the EMS needs to
configure on the Access Node which parameters may or may not be modified
using the Access Node Control Mechanism.  Furthermore, for those
parameters that may be modified using ANCP, the EMS needs to specify the
default values to be used when an Access Node comes up after recovery."

regards,
Stefaan

---

From: Stefaan DE CNODDER <[email-masked]>
Date: Mon, 24 Sep 2007 12:27:17 +0200

Sven,

It looks to me that the original text is correct: the EMS has to 
configure which parameters can be changed by the NAS and which cannot be 
changed.  If the NAS tries to configure another parameter, the request 
will fail with an appropriate error code.  It also implies that the EMS 
can change whatever the NAS has configured before, without information 
the NAS about this modification.

regards,
Stefaan

OOGHE Sven wrote:

>><Sven> Good point. I think it should be added, unless someone speaks
> 
> up.
> 
>> 
> 
>

---

From: <[email-masked]>
Date: Mon, 24 Sep 2007 17:57:36 +0530

Stefaan and Sven,

My comment was based on the assumption that any change
in permission on parameter configuration by EMS would 
be immediately communicated to NAS. At any point in time,
NAS should be aware of which parameters are allowed to be changed in AN.

If that is done, there will be no inconsistencies in ANCP operation 
and permissions can be changed dynamically by EMS.

Thanks,
Kirubaharan

-----Original Message-----
From: Stefaan DE CNODDER [mailto:[email-masked]] 
Sent: Monday, September 24, 2007 3:57 PM
To: OOGHE Sven
Cc: Kirubaharan Dorairaj (WT01 - TES-Telecom Engineering Solutions);
[email-masked]

Sven,

regards,
Stefaan

OOGHE Sven wrote:

> Stefaan,
> 
> I think you're right. This raises an interesting question: it looks 
> like allowing the EMS to "turn on" or "turn off" certain parameters to

> be changed via ANCP may lead to race conditions, i.e. both the NAS and

> the EMS wish to perform an action on the same parameter (EMS wishes to

> "turn off" changes via ANCP / NAS wishes to change the value of the 
> parameter).
> 
> Perhaps it's simpler to determine beforehand what parameters may or 
> may not be changed via ANCP?
> 
> Regards,
> Sven
> 
> point of view that is the same as an EMS that can change something 
> that is successfuly updated by ANCP.
> 
> regards,
> Stefaan
>

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 24 Sep 2007 15:24:07 +0200

Well, calling out which parameters may or may not be changed via ANCP
seems rather undesirable as it could complicate extensibility or even
some details of the existing use-cases, not to mention bringing about
quite an extra operational chore. 

IMO we could have the framework re-aligned so that:

i) there may be default configuration values (whether these defaults got
there via local or remote EMS is secondary)

ii) there should be a local mechanism for handling configuration source
info priorities and failures to apply it, with such a mechanism most
likely being implementation specific. 
Taking this view would make ANCP agnostic to the mechanism allowing say
vendor A choosing to do a config parameter source based priority scheme
vs vendor B choosing a specific parameter lock mechanism vs a vendor C
choosing a parameter merge mechanism (although operators may prefer one
method vs the other). The only real consequence for ANCP is that there
needs to be an error message which indicates that there was/is a problem
in applying the configuration desired by ANCP, and that this was/is
caused by a denial from the device local mechanism.

Iii) Once ANCP is successful in configuring a data object, then it
should be assumed that ANCP is the owner and then there must be a means
of enforcing a lock on the ANCP configured data object (after all, if
one uses ANCP, and allows ANCP to make config changes, then presumably
one really wants that). If, through say special intervention such a lock
is removed, then there must be a way of signalling this, and this
appears to translate to an ANCP message very similar to the error
message above. 

Given the above I'd suggest removing the EMS references all together and
structuring the description along the above points.

Thoughts or comments?

-Woj.

> From: OOGHE Sven [mailto:[email-masked]] 
> Sent: 24 September 2007 09:53
> To: DE CNODDER Stefaan
> Cc: [email-masked]
> Subject: RE: [ANCP] Comments on draft-ietf-ancp-framework-02
> 
> Stefaan,
> 
> I think you're right. This raises an interesting question: it 
> looks like allowing the EMS to "turn on" or "turn off" 
> certain parameters to be changed via ANCP may lead to race 
> conditions, i.e. both the NAS and the EMS wish to perform an 
> action on the same parameter (EMS wishes to "turn off" 
> changes via ANCP / NAS wishes to change the value of the parameter).
> 
> Perhaps it's simpler to determine beforehand what parameters 
> may or may not be changed via ANCP?
> 
> Regards,
> Sven
>

---

From: "Freudenberger, Markus" <[email-masked]>
Date: Wed, 26 Sep 2007 08:58:22 +0200

Stefaan, Sven,

We do not agree to the following:
"When ANCP adjacency is up in AN, any configuration parameter successfully updated by ANCP should not be allowed to be changed by local EMS. This is required to ensure consistency of data and operation."

for the use case line configuration and in addition to the actual requirements contained in chapter 6, we as an operator, want:
- to control via EMS (e. g .via SNMP-If, CLI), which parameters can be changed and which cannot be changed by ANCP in the acces node.
- that the EMS (e. g. via SNMP-If, CLI) can change the parameters in the acces node which may be set by ANCP at any time.

Regards
Markus

-----Ursprüngliche Nachricht-----
Von: Stefaan DE CNODDER [mailto:[email-masked]] 
Gesendet: Montag, 24. September 2007 12:27
An: OOGHE Sven
Cc: [email-masked]
Betreff: Re: [ANCP] Comments on draft-ietf-ancp-framework-02

Sven,

It looks to me that the original text is correct: the EMS has to configure which parameters can be changed by the NAS and which cannot be changed.  If the NAS tries to configure another parameter, the request will fail with an appropriate error code.  It also implies that the EMS can change whatever the NAS has configured before, without information the NAS about this modification.

regards,
Stefaan

OOGHE Sven wrote:

> specify the default values to be used when an Access Node comes up after recovery."
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 26 Sep 2007 09:35:10 +0200

Markus - clarification question just to make sure - what do you mean by 'SNMP-If'? 

Thanks and Regards,

Dan

> From: Freudenberger, Markus 
> [mailto:[email-masked]] 
> Sent: Wednesday, September 26, 2007 8:58 AM
> To: [email-masked]; [email-masked]
> Cc: Haag, T; Busser,M; [email-masked]
> Subject: AW: [ANCP] Comments on draft-ietf-ancp-framework-02
> 
> Stefaan, Sven,
> 
> "When ANCP adjacency is up in AN, any configuration parameter 
> successfully updated by ANCP should not be allowed to be 
> changed by local EMS. This is required to ensure consistency 
> of data and operation."
> 
> for the use case line configuration and in addition to the 
> actual requirements contained in chapter 6, we as an operator, want:
> - to control via EMS (e. g .via SNMP-If, CLI), which 
> parameters can be changed and which cannot be changed by ANCP 
> in the acces node.
> - that the EMS (e. g. via SNMP-If, CLI) can change the 
> parameters in the acces node which may be set by ANCP at any time.
> 
> Regards
> Markus
>  
> 
> It looks to me that the original text is correct: the EMS has 
> to configure which parameters can be changed by the NAS and 
> which cannot be changed.  If the NAS tries to configure 
> another parameter, the request will fail with an appropriate 
> error code.  It also implies that the EMS can change whatever 
> the NAS has configured before, without information the NAS 
> about this modification.
> 
> regards,
> Stefaan
> 
> 
> OOGHE Sven wrote:
> 
> > Stefaan,
> >

---

From: "Freudenberger, Markus" <[email-masked]>
Date: Wed, 26 Sep 2007 09:43:32 +0200

Hi Dan,

SNMP-If means SNMP-Interface (which is meant in this context as one possible kind of management interface, implemented in a network element to communicate with an EMS). 
Hope this clarifies your question.

Regards
Markus 

-----Ursprüngliche Nachricht-----
Von: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Gesendet: Mittwoch, 26. September 2007 09:35
An: Freudenberger, Markus; [email-masked]; [email-masked]
Cc: Haag, Thomas; Busser, Michael; [email-masked]
Betreff: RE: [ANCP] Comments on draft-ietf-ancp-framework-02

Thanks and Regards,

Dan

> successfully updated by ANCP should not be allowed to be changed by 
> local EMS. This is required to ensure consistency of data and 
> operation."
> 
> for the use case line configuration and in addition to the actual 
> requirements contained in chapter 6, we as an operator, want:
> - to control via EMS (e. g .via SNMP-If, CLI), which parameters can be 
> changed and which cannot be changed by ANCP in the acces node.
> - that the EMS (e. g. via SNMP-If, CLI) can change the parameters in 
> the acces node which may be set by ANCP at any time.
> 
> Regards
> Markus
>  
> 
> configure which parameters can be changed by the NAS and which cannot 
> be changed.  If the NAS tries to configure another parameter, the 
> request will fail with an appropriate error code.  It also implies 
> that the EMS can change whatever the NAS has configured before, 
> without information the NAS about this modification.
> 
> regards,
> Stefaan
> 
> 
> OOGHE Sven wrote:
> 
> > Stefaan,
> >

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 26 Sep 2007 13:37:16 +0200

Markus,

Can you clarify what would be your expectation regarding ANCP's behaviour after an ANCP set parameter is overriden via EMS?

-Woj. 

> Sent: 26 September 2007 08:58

---

From: "Freudenberger, Markus" <[email-masked]>
Date: Wed, 26 Sep 2007 15:26:43 +0200

Wojciech,

I think it depends on the specific parameter. 
But as the framework is actually focused on the same set of DSL related paramteters for both use cases "Access Topology Discovery" and "Access Loop Configuration", I think the behaviour is already described in the document:
After the EMS changs e. g. the minimum data rate for a specific DSL line in the AN, ANCP reports this change to the NAS.

Please correct me if I am wrong. 

Markus

-----Ursprüngliche Nachricht-----
Von: Wojciech Dec (wdec) [mailto:[email-masked]] 
Gesendet: Mittwoch, 26. September 2007 13:37
An: Freudenberger, Markus; [email-masked]; [email-masked]
Cc: Haag, Thomas; Busser, Michael; [email-masked]
Betreff: RE: [ANCP] Comments on draft-ietf-ancp-framework-02

Markus,

-Woj.

---

From: "OOGHE Sven" <[email-masked]>
Date: Wed, 26 Sep 2007 15:49:01 +0200

Markus,

I agree that the EMS may overwrite a parameter value that was previously changed via ANCP. That implies that the 3rd sub-bullet in section 6 needs to be removed. Correct?

The question then is whether a configuration change by the EMS results in a notification message being sent to the NAS. As you write in another email, the NAS is made aware of a configuration change to the DSL parameters, thanks to the Access Topology Discovery procedure.

Perhaps we need to describe such a notification mechanism in a more generic context of configuration changes. What do you think?

Regards,
Sven

-----Original Message-----
From: Freudenberger, Markus [mailto:[email-masked]] 
Sent: woensdag 26 september 2007 8:58
To: DE CNODDER Stefaan; OOGHE Sven
Cc: [email-masked]; Haag, T; Busser, M
Subject: AW: [ANCP] Comments on draft-ietf-ancp-framework-02

Stefaan, Sven,

Regards
Markus

-----Ursprüngliche Nachricht-----
Von: Stefaan DE CNODDER [mailto:[email-masked]]
Gesendet: Montag, 24. September 2007 12:27
An: OOGHE Sven
Cc: [email-masked]
Betreff: Re: [ANCP] Comments on draft-ietf-ancp-framework-02

Sven,

regards,
Stefaan

---

From: "Freudenberger, Markus" <[email-masked]>
Date: Wed, 26 Sep 2007 16:44:59 +0200

Sven,

see my comments inline.

Regards,
Markus

-----Ursprüngliche Nachricht-----
Von: OOGHE Sven [mailto:[email-masked]] 
Gesendet: Mittwoch, 26. September 2007 15:49
An: Freudenberger, Markus; DE CNODDER Stefaan
Cc: Haag, Thomas; Busser, Michael; [email-masked]
Betreff: RE: [ANCP] Comments on draft-ietf-ancp-framework-02

Markus,

I agree that the EMS may overwrite a parameter value that was previously changed via ANCP. That implies that the 3rd sub-bullet in section 6 needs to be removed. Correct?
[Markus]
I don't see anything to be removed, but I may did'nt understand your point. You mentioned the 3rd sub-bullet in section 6, which says:
o The Access Node must provide the possibility using SNMP to associate individual DSL lines with specific Access Node Control Adjacencies.
Can you explain in more detail why this needs to be removed?

Perhaps we need to describe such a notification mechanism in a more generic context of configuration changes. What do you think?
[Markus]
I agree. My proposal for addional text to be added to section 6:
o The ANCP may provide a notification mechanism to inform the NAS about configuration changes done by an EMS in a timely manner. This applies only to changes of parameters which are part of the Use Case Access Loop Configuration

Regards,
Sven

-----Original Message-----
From: Freudenberger, Markus [mailto:[email-masked]]
Sent: woensdag 26 september 2007 8:58
To: DE CNODDER Stefaan; OOGHE Sven
Cc: [email-masked]; Haag, T; Busser, M
Subject: AW: [ANCP] Comments on draft-ietf-ancp-framework-02

Stefaan, Sven,

Regards
Markus

-----Ursprüngliche Nachricht-----
Von: Stefaan DE CNODDER [mailto:[email-masked]]
Gesendet: Montag, 24. September 2007 12:27
An: OOGHE Sven
Cc: [email-masked]
Betreff: Re: [ANCP] Comments on draft-ietf-ancp-framework-02

Sven,

regards,
Stefaan

---

From: "OOGHE Sven" <[email-masked]>
Date: Thu, 27 Sep 2007 09:12:49 +0200

Markus,
 
see inline.

From: Freudenberger, Markus [mailto:[email-masked]] 
Sent: woensdag 26 september 2007 16:45
To: OOGHE Sven; DE CNODDER Stefaan
Cc: Haag, T; Busser, M; [email-masked]
Subject: AW: [ANCP] Comments on draft-ietf-ancp-framework-02

 Sven, 

see my comments inline. 

Regards, 
Markus 

-----Ursprüngliche Nachricht----- 
Von: OOGHE Sven [mailto:[email-masked] <mailto:[email-masked]> ] 
Gesendet: Mittwoch, 26. September 2007 15:49 
An: Freudenberger, Markus; DE CNODDER Stefaan 
Cc: Haag, Thomas; Busser, Michael; [email-masked] 
Betreff: RE: [ANCP] Comments on draft-ietf-ancp-framework-02 

Markus, 

[Markus] 

<Sven> My mistake: I referred to a bullet in  one of my own working document, which actually included some text by Kirubaharan. In draft-02 this text wasn't there. So forget about this question.  

[Markus] 

 <Sven> I think it makese sense to add this bullet to cover the generic case of Access Loop Configuration. It shows that the AN can notify the NAS of those parameter changes that the NAS is allowed to perform. The NAS should of course not be notified of changes to parameters that the NAS is not allowed to change in the first place. 
 
Regards,
Sven 

Regards, 
Sven 

-----Original Message----- 
From: Freudenberger, Markus [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: woensdag 26 september 2007 8:58 
To: DE CNODDER Stefaan; OOGHE Sven 
Cc: [email-masked]; Haag, T; Busser, M 
Subject: AW: [ANCP] Comments on draft-ietf-ancp-framework-02 

Stefaan, Sven, 

Regards 
Markus 

-----Ursprüngliche Nachricht----- 
Von: Stefaan DE CNODDER [mailto:[email-masked] <mailto:[email-masked]> ] 
Gesendet: Montag, 24. September 2007 12:27 
An: OOGHE Sven 
Cc: [email-masked] 
Betreff: Re: [ANCP] Comments on draft-ietf-ancp-framework-02 

Sven, 

regards, 
Stefaan 

_______________________________________________ 
ANCP mailing list 
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ancp <https://www1.ietf.org/mailman/listinfo/ancp>  

_______________________________________________ 
ANCP mailing list 
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ancp <https://www1.ietf.org/mailman/listinfo/ancp>