From ancp-bounces@ietf.org Fri Dec 01 04:09:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq4P4-0005oX-Qm; Fri, 01 Dec 2006 04:09:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq4P2-0005oH-RE for ancp@ietf.org; Fri, 01 Dec 2006 04:09:52 -0500 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq4P1-0003n0-Kx for ancp@ietf.org; Fri, 01 Dec 2006 04:09:52 -0500 Received: by ug-out-1314.google.com with SMTP id 72so2062260ugd for ; Fri, 01 Dec 2006 01:09:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=NNBqn4GzRD5RDz0suXp7T3OkDIP+0Sdc2k+HChvO47ph8Z8Oy8HUfyzE5F6K2Ok2yo2kmL/L2up7qO0emrKgMtRx9LPhF0JJwgnWSOmI2yiTpzNkHV1808kJqQg3IXeDqSGeNSVRSPQimMdibroo2r0AN5YMDYp0uKjD8ciU2aY= Received: by 10.67.89.5 with SMTP id r5mr6896425ugl.1164964190617; Fri, 01 Dec 2006 01:09:50 -0800 (PST) Received: by 10.66.218.11 with HTTP; Fri, 1 Dec 2006 01:09:50 -0800 (PST) Message-ID: Date: Fri, 1 Dec 2006 10:09:50 +0100 From: "Hasnaa Moustafa" To: bharat_joshi Subject: Re: [ANCP] Re: ANCP Digest, Vol 6, Issue 12 In-Reply-To: <6031539A3C7B964581EFCE2E205D6EEF01A9F2BD@BLRKECMSG01.ad.infosys.com> MIME-Version: 1.0 References: <6031539A3C7B964581EFCE2E205D6EEF01A9F2BD@BLRKECMSG01.ad.infosys.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: d115f8e98afb84ba4860c5c6ee611921 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0675695940==" Errors-To: ancp-bounces@ietf.org --===============0675695940== Content-Type: multipart/alternative; boundary="----=_Part_2036_4698072.1164964190523" ------=_Part_2036_4698072.1164964190523 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Bharat, Thanks again for your comments. Please find some clarifications in line. Regards, Hassnaa On 11/30/06, bharat_joshi wrote: > > > 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 > > > > This brief description for ANCP exactly conforms to the framework > > . 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/ > > > > > Ok. If so can you make it 'operation and configurations'? Hassnaa: Ok, then no problem on this point. * 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/ > > > > > Ok. Hassnaa: then 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 > > through this switch. > > > > Hassnaa > > > > The architectural details are given in the framework draft, and we > > mentioned that we follow the same thing. > > > > Hassnaa/ > > > > > I just saw that the figure is same as is mentioned in the framework > document. Hassnaa: then it is clear now. > * 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/ > > > > > > 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. Hassnaa: I could not get your point! For us, CPE refers to an end-user workstation (such as PC) together with the associated equipments that is connected to the "demarc", and the HGW connects the CPE to the Access Node. Anyway, this concerns more the framework document. > * 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/ > > > OK. My mistake. Let me put this question to the framework document > authors. Hassnaa: then there is no issue here. * 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/ > > > > > Ok. Hassnaa: Then, 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 > > 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/ > > > > > 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. Hassnaa: At this phase of work, we are seeking requirements and general guidelines. > * 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/ > > > > > What I meant is that if its an external attacker, how will he be able to > snoop the traffic? Hassnaa: External attacker represent an issue, during information sharing between the NAS and the Policy Server. This can take place in the Dynamic Access Loop Attributes Use Case where Access Loop characteristics information received at the NAS is shared with the policy server. * 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/ > > > > > Ok. Hassnaa: Then OK. * 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/ > > > > > Ok. Hassnaa: Then 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, > > 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/ > > > > > Yes. I agree that using TCP can not be completely avoid replay attacks. Hassnaa: Then OK. * 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/ > > > > > How does it help in preventing replay signaling messages? Hassnaa: By data here it is meant, the information transferred by a reporting function to a controller function containing status information. On the other hand messages sent by a controller function for either information requests or triggering certain network element are signaling messages. So, distinguishing between these messages types can help in detecting replay signaling. In other words, the protocol should distinguish between data and signaling because when the AN receives data, then there is something wrong and the AN should ignore this. Similarly, a NAS receiving signaling (ex: ANCP messages containing configuration request) should ignore them. Regards, Hassnaa **************** 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*** > ------=_Part_2036_4698072.1164964190523 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Bharat,
Thanks again for your comments.
Please find some clarifications in line.
 
Regards,
Hassnaa

 
On 11/30/06, bharat_joshi <bharat_jo= shi@infosys.com> wrote:

Hi Hassnaa,

 &nb= sp; Thanks for the response. Please see my response in line. I have
remo= ved those comments where we both are in sync.

Thanks & Regards,
Bharat

    &nbs= p;  * In abstract, it is mentioned that ANC
> P is used for &quo= t;qos-,
>         service- an= d
>         subscriber-relate= d operations between NAS and AN". I think it
>         should say
>=          'xxx-related configuration= s; 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 dr= aft in
> deriving the threat model, and it is really "operations= " and not just
> "configurations". Advertising DSL lin= e sync speed is not a
> "configuration", the same for OAM.
>
> Hassn= aa/
>
>
Ok. If so can you make it 'operation and configurati= ons'?
 

Hassnaa: Ok, then no problem on this point.


     &n= bsp; * In some ANCP document, it is proposed that ANCP session would
>= ;         be
>  &nb= sp;      initiated by AN and so the NAS address ne= ed to be configured
in
>         there.
&g= t;         In this case, how NAS wi= ll 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 prot= ocol solution MUST offer authentication of the AN to
> the NAS
>= ;
> -         the protocol so= lution MUST offer authentication of the NAS
to
> the AN
> > -         the protocol solutio= n MUST allow authorization to take place
> at the AN and the NAS
&= gt;
> But how this should take place is not the objective of this dra= ft. The
> main objective is deriving the security requirements, but n= ot giving
> security solutions.
>
> Hassnaa/
>
>
Ok= .
 

Hassnaa: then OK.


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

Hassnaa: then it is clear now.


>    &nbs= p;  * Does the Home Gateway shown in figure #1 is at correct place?>         Should
> &= nbsp;       not it be before CPE? Something l= ike HGW --- CPE --- Access
>         Node?
>
&= gt; 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 suppos= ed to connect different CPEs
to
> the AN.
>
> Hassnaa/
>
>

I th= ink the definition of CPE is what is making a difference. IMHO, CPE
is a= lways 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, Rout= ing Gateway and Home gateway are generally connected
to the CPE and prov= ides access to the internet to multiple users
connected to the home gate= way.

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

HGW --- CPE.
 

Hassnaa: I could not get your point! For us, CPE refers to an end-user w= orkstation (such as PC) together with the associated equipments that is con= nected to the "demarc", and the HGW  connects the CPE to the Access Node.   Anyway, this concerns mo= re the framework document. 

 

>    &nbs= p;  * In the definition of 'Home Gateway', I did not get the 'DSL
&= gt;         Network
> &n= bsp;       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 r= edundancy is not recommended between the two
> drafts, but rather the security requirements draft should compleme= nt
the
> framework draft.
>
> Hassnaa/
>
OK. = My mistake. Let me put this question to the framework document
authors.
 

Hassnaa: then there is no issue here.


     &n= bsp; * In section 5.3, Third paragraph, first sentence " When the
&= gt;         ANCP allows
>&nbs= p;        the AN to dynamically discover= y the NAS". I did not find any
>         such
> =         reference in the ANCP framework = document.
>
> Hassnaa
>
> This relates to ANCP func= tioning and is not related to the Use Cases
> defined in the framewor= k draft. It is mentioned that the ANCP allows
the
> AN to dynamically discover the NAS, given that ANCP will us= e TCP for
> exchanging protocol messages 'as mentioned in the draft &= lt;
> draft-wadhwa-gsmp-l2control-configuration-02.txt>). In this = case, the
> session is initiated from the AN to the NAS to avoid static
pro= visioning
> on the NAS for all the ANs that are being served by the N= AS.
>
> But since man-in-the-middle attack s also possible with= out dynamic
> discovery, this sentence may be removed.
> Hassnaa/
><= br>>
Ok.
 

Hassnaa: Then, OK


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

Hassnaa: At this phase of work, we are seeking requirements and general = guidelines.


>    &nbs= p;    * 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
> &n= bsp;       possible only when the adversary h= as access to the network
>       &= nbsp; between AN
>         an= d NAS. Right?
>
> Hassnaa
>
> No, not necessary. Th= is 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 exp= lains
> this).
> Hassnaa/
>
>
What I meant is th= at if its an external attacker, how will he be able to
snoop the traffic?
 

Hassnaa: External attacker represent an issue, during information sharin= g between the NAS and the Policy Server. This can take place in the Dy= namic Access Loop Attributes Use Case where Access Loop characteristics inf= ormation received at the NAS is shared with the policy server.=20


     &n= bsp; * 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-p= ath attacks that impact the proper
> functioning of ANCP. In other wo= rds, we are showing all the attacks
that
> relates to ANCP functio= ning whether (on-path or off-path).
>
> Hassnaa/
>
>
Ok.
 

Hassnaa: Then OK.


     &n= bsp; * In section 6.1, you may want to use 'lists' to talk about the
>= ;         attacks.
> &nb= sp;       For example:
>
>         Those atta= cks may be:
>
>        = o Passive attacks
>        &= nbsp;    o First passive attack
>   &nb= sp;         o Second passive attack=
>         o Active attacks>           &nb= sp; o First active attack
>           &= nbsp; o Second active attack
>
>     &= nbsp;      I am sure this way it will be more= readable.
>
> Hassnaa
>
> Re-formatting may be con= sidered for readability
>
> Hassnaa/
>
>
Ok.
 

Hassnaa: Then OK.


     &n= bsp; * Are you sure that replaying of Config requests can be done by
>= ;         an
>  &nb= sp;      attacker over TCP connections? I understa= nd that after
sniffing
>         syn/ac= k,
>         it can generate = a possible message but can I replay the old
>    =      config
>      =    request which TCP itself would discard?
>
> Hassna= a
>
> Using TCP does not help to prevent replay attacks but provides som= e
> degree of return routability checks through sequence numbers use.=
> However, TCP is not 100% safe for replay, it is only very hard.
>
> Hassnaa/
>
>
Yes. I agree that using TCP ca= n not be completely avoid replay attacks.
 

Hassnaa: Then OK.


     &n= bsp; * What triggers the requirement "The protocol solution SHOULD
= >         distinguish the contro= l messages from the data"?
>
> Hassnaa
>
> This is important to help preventi= ng replay signaling messages, and it
> is a SHOULD requirement and no= t MUST.
>
> Hassnaa/
>
>
How does it help in pre= venting replay signaling messages?
 

Hassnaa: By data here it is meant, the information transferred by a= reporting function to a controller function containing status information.= On the other hand messages sent by a controller function for either i= nformation requests or triggering certain network element are signaling mes= sages. So, distinguishing between these messages types can help in detectin= g replay signaling. In other words, the protocol should distingui= sh between data and signaling because when the AN receives data, then there= is something wrong and the AN should ignore this. Similarly, a NAS receivi= ng signaling (ex: ANCP messages containing configuration request) should ig= nore them.

 

 

Regards,

Hassnaa


**************** CAUTION - Discl= aimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL= INFORMATION intended solely for the use of the addressee(s). If you are no= t the intended recipient, please notify the sender by e-mail and delete the= original message. Further, you are not to copy, disclose, or distribute th= is e-mail or its contents to any other person and any such actions are unla= wful. This e-mail may contain viruses. Infosys has taken every reasonable p= recaution to minimize this risk, but is not liable for any damage you may s= ustain as a result of any virus in this e-mail. You should carry out your o= wn virus checks before opening the e-mail or attachment. Infosys reserves t= he 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 st= ored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

------=_Part_2036_4698072.1164964190523-- --===============0675695940== 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 --===============0675695940==-- From ancp-bounces@ietf.org Fri Dec 01 07:19:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq7ML-00013X-66; Fri, 01 Dec 2006 07:19:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq7MK-00013S-HK for ancp@ietf.org; Fri, 01 Dec 2006 07:19:16 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq7MJ-0003u9-4r for ancp@ietf.org; Fri, 01 Dec 2006 07:19:16 -0500 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.telekom.de with ESMTP for ancp@ietf.org; Fri, 1 Dec 2006 13:19:14 +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, 1 Dec 2006 13:19:14 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Date: Fri, 1 Dec 2006 13:19:13 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2C45813@S4DE8PSAAFQ.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Protocol version nummer for ANCP Thread-Index: AccVQum3qm4RL8oMQHKZQvU2NrY2ug== From: "Busser, M" To: X-OriginalArrivalTime: 01 Dec 2006 12:19:14.0107 (UTC) FILETIME=[E9FD60B0:01C71542] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [ANCP] Protocol version nummer for ANCP X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi all. =20 Problem: Currently different codes exist referring to=20 draft-wadhwa-gsmp-l2control-configuration-00 &=20 draft-wadhwa-gsmp-l2control-configuration-02. =20 The lack of having different codes in different network elements is to create a situation of non interoperable TLV because TLV changed (e.g. 90/91) =20 Solution: The only way out is to define a protocol version field in combination with a software management in the network element: =20 A proposal is shown below: =20 We should have a format like version number, where main as well as sub is represented by a 1 byte value.=20 We should start with 0.1 representing draft-wadhwa-gsmp-l2control-configuration-02. =20 Procedures Add a new Capability: Version Length=3D4 Byte 0 =3D Main Version Nr of oldest supported protocol version Byte 1 =3D Sub Version Nr of oldest supported protocol version Byte 2 =3D Main Version Nr of latest supported protocol version Byte 3 =3D Sub Version Nr of latest supported protocol version =20 If only one specific version is supported by a network element, the=20 oldest and the latest version number are the same. =20 Requirement: =20 To define a protocol version TLV first before enhancing=20 draft-wadhwa-gsmp-l2control-configuration-02 in further steps. =20 =20 =20 Best regards =20 Thomas & Michael _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Dec 01 12:14:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqBxd-0005AZ-Kh; Fri, 01 Dec 2006 12:14:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqAdh-0005wu-SI for ancp@ietf.org; Fri, 01 Dec 2006 10:49:25 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqAdg-0007Mz-Nv for ancp@ietf.org; Fri, 01 Dec 2006 10:49:25 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 16:49:05 +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_01C71560.3777E438" Subject: [ANCP] Detailed NAS requirements for ANCP-L2TP interaction Date: Fri, 1 Dec 2006 16:48:58 +0100 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Detailed NAS requirements for ANCP-L2TP interaction Thread-Index: AccVYDcDwRfkqEBHR8C1aK8NVwhPwg== From: "DELAFOY Antoine RD-CORE-LAN" To: X-OriginalArrivalTime: 01 Dec 2006 15:49:05.0231 (UTC) FILETIME=[3AE26DF0:01C71560] X-Spam-Score: 0.0 (/) X-Scan-Signature: 054490fec19f6a94c68e63428d06db69 X-Mailman-Approved-At: Fri, 01 Dec 2006 12:14:04 -0500 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C71560.3777E438 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Last version of draft-ietf-ancp-framework mentions the two following high-level requirements in section 4.5.6 regarding the interaction between ANCP and L2TP in a wholesale context: - The BNG when acting as a LAC MUST communicate generic access line related information to the LNS in a timely fashion. - The BNG when acting as a LAC MAY asynchronously notify the LNS of updates to generic access line related information. Besides, the DSLF contribution 2006.547 provided one RFC draft describing a set of L2TP AVP Vendor Extensions. Among these new AVPs, some of them are directly related to the access loop characteristics whereas others, for instance the Connect Speed Update present in the CSUN control message, could be used either to report the Connect speed configured in the LAC or the DSL Net Data rate.=20 Therefore, the joined document details the need for NAS specifications and provides related requirements. Thanks for your comments, Antoine ------_=_NextPart_001_01C71560.3777E438 Content-Type: text/plain; name="draft-delafoy-ancp-l2tp-nas-specifications-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-delafoy-ancp-l2tp-nas-specifications-00.txt Content-Disposition: attachment; filename="draft-delafoy-ancp-l2tp-nas-specifications-00.txt" DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBBLiBEZWxhZm95DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgRnJhbmNlIFRlbGVjb20NCkludGVuZGVkIHN0YXR1czog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRGVjZW1iZXIgMSwgMjAwNg0K DQoNCg0KCSAgICAgTmV0d29yayBBY2Nlc3MgU2VydmVyIHJlcXVpcmVtZW50cyByZWxhdGVkIHRv IA0KCSAgICAgICAgICBpbnRlcmFjdGlvbiBiZXR3ZWVuIEFOQ1AgYW5kIEwyVFAgDQogICAgICAg ICAgIGRyYWZ0LWRlbGFmb3ktYW5jcC1sMnRwLW5hcy1zcGVjaWZpY2F0aW9ucy0wMC50eHQNCg0K U3RhdHVzIG9mIHRoaXMgTWVtbw0KDQogICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJh ZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCBhbnkNCiAgIGFwcGxpY2FibGUgcGF0ZW50 IG9yIG90aGVyIElQUiBjbGFpbXMgb2Ygd2hpY2ggaGUgb3Igc2hlIGlzIGF3YXJlDQogICBoYXZl IGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQsIGFuZCBhbnkgb2Ygd2hpY2ggaGUgb3Igc2hlIGJl Y29tZXMNCiAgIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggU2Vj dGlvbiA2IG9mIEJDUCA3OS4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3Vt ZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBp dHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQNCiAgIG90aGVyIGdy b3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0K ICAgRHJhZnRzLg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxp ZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVw bGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAg SXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0K ICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jl c3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNj ZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4N Cg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBi ZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4NCg0KICAg VGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBKdW5lIDQsIDIwMDcuDQoNCkNvcHly aWdodCBOb3RpY2UNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSUVURiBUcnVzdCAoMjAwNikuDQoN CkFic3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVjcmliZXMgYSBzZXQgb2YgcmVxdWlyZW1l bnRzIGZvciB0aGUgTkFTIGluIHJlbGF0aW9uDQogICB3aXRoIEFOQ1AgaGlnaC1sZXZlbCByZXF1 aXJlbWVudHMgZnJvbSBEU0wgRm9ydW0gV29ya2luZyBUZXh0IDE0NyBpbg0KICAgY2FzZSB0aGUg TkFTIGFjdHMgYXMgYSBMQUMgaW4gYSB3aG9sZXNhbGUgY29udGV4dC4gIFRoaXMgZG9jdW1lbnQN CiAgIHNwZWNpZmllcyB3aGljaCB2YWx1ZSBjb3VsZCBiZSB1c2VkIGZvciBzb21lIExheWVyIDIg VHVubmVsaW5nDQogICBQcm90b2NvbCBBdHRyaWJ1dGUgVmFsdWUgUGFpciBpbmNsdWRpbmcgdGhl IFZlbmRvciBleHRlbnNpb25zDQogICBwcm9wb3NlZCBpbiB0aGUgUkZDIGRyYWZ0IGluIHByb2dy ZXNzIGZyb20gRFNMIEZvcnVtIDIwMDYuNTQ3DQogICBjb250cmlidXRpb24uICBJdCBpcyBleHBl Y3RlZCB0aGF0IHRoaXMgZG9jdW1lbnQgd2lsbCBiZSB1cGRhdGVkIHRvDQogICBwcm92aWRlIGFk ZGl0aW9ubmFsIHNwZWNpZmljYXRpb25zIGZvciBvdGhlciBBVlAgaWYgcmVxdWlyZWQuDQoNCg0K DQpEZWxhZm95ICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVuZSA0LCAyMDA3ICAgICAgICAg ICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgRGVjZW1iZXIgMjAwNg0KDQoNClJlcXVpcmVtZW50cyBM YW5ndWFnZQ0KDQogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVE IiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVD T01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcw0KICAgZG9jdW1lbnQgYXJl IHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMgMjExOSBbUkZDMjExOV0uDQoN Cg0KVGFibGUgb2YgQ29udGVudHMNCg0KICAgMS4gIEludHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzDQogICAyLiAgU3lzdGVtIE92 ZXJ2aWV3ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMN CiAgIDMuICBPYmplY3RpdmVzIGFuZCBhc3N1bXB0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgNA0KICAgNC4gIElucHV0cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA2DQogICAgIDQuMS4gIEFOQ1AgZnJhbWV3 b3JrIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYNCiAgICAg NC4yLiAgTDJUUCBBVlAgRXh0ZW5zaW9ucyBkcmFmdCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgNg0KICAgICA0LjMuICBXVC0xNDcgcmVxdWlyZW1lbnRzICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3DQogICA1LiAgTkFTIGxvY2FsIHBvbGljeSAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcNCiAgICAgNS4xLiAg Q2FzZSBvZiBhbiBBVE0gYWdncmVnYXRpb24gbmV0d29yayAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgNw0KICAgICA1LjIuICBDYXNlIG9mIGFuIEV0aGVybmV0IGFnZ3JlZ2F0aW9uIG5ldHdvcmsg IC4gLiAuIC4gLiAuIC4gLiAuICA4DQogICAgIDUuMy4gIFJlcXVpcmVtZW50cyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgNCiAgIDYuICBBY2tub3dsZWRn ZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0K ICAgNy4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA5DQogICBBdXRob3IncyBBZGRyZXNzIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkNCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0 eSBhbmQgQ29weXJpZ2h0IFN0YXRlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQ0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRGVsYWZveSAg ICAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bmUgNCwgMjAwNyAgICAgICAgICAgICAgICAgIFtQ YWdlIDJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIERlY2VtYmVyIDIwMDYNCg0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgIFRo ZSBBY2Nlc3MgTm9kZSBDb250cm9sIFByb3RvY29sIChBTkNQKSBhaW1zIHRvIGNvbW11bmljYXRl IFFvUy0sDQogICBzZXJ2aWNlLSBhbmQgc3Vic2NyaWJlci1yZWxhdGVkIG9wZXJhdGlvbnMgYmV0 d2VlbiBhIE5ldHdvcmsgQWNjZXNzDQogICBTZXJ2ZXIgKE5BUykgYW5kIGFuIEFjY2VzcyBOb2Rl IChlLmcuLCBhIERpZ2l0YWwgU3Vic2NyaWJlciBMaW5lDQogICBBY2Nlc3MgTXVsdGlwbGV4ZXIg KERTTEFNKSkuDQoNCiAgIFRoZSB0YXJnZXQgb2YgdGhpcyBkb2N1bWVudCBpcyB0byBwcm92aWRl IHJlcXVpcmVtZW50cyBmb3IgTDJUUCBBVlBzLg0KICAgVGhpcyBpcyBuZWNlc3NhcnkgdG8gc29s dmUgdGhlIFFvUyBpc3N1ZXMgZW5jb3VudGVyZWQgYnkgYSBOU1AgaW4NCiAgIGNhc2UgYW4gTDJU UCBhY2Nlc3MgYWdncmVnYXRpb24gYXJjaGl0ZWN0dXJlIGlzIHVzZWQuICBUaGVzZSBpc3N1ZXMN CiAgIGhhdmUgYWxyZWFkeSBiZWVuIGNvbnNpZGVyZWQgZnJvbSB0aGUgRFNMQU0gdG8gdGhlIE5B UyBieSB0aGUgQU5DUA0KICAgIkR5bmFtaWMgYWNjZXNzIGxvb3AgYXR0cmlidXRlcyIgdXNlIGNh c2UuICBUaGlzIGRvY3VtZW50IHByb3Bvc2VzIGENCiAgIG1ldGhvZCB0byBleHRlbmQgdGhpcyB1 c2UgY2FzZSB1bnRpbCB0aGUgTE5TIGFuZCBkZWZpbmVzIGhvdyB0aGUgTkFTDQogICBjb3VsZCBl bnN1cmUgYSByZWxldmFudCBtYXBwaW5nIGJldHdlZW4gQU5DUCBhbmQgTDJUUCBhdHRyaWJ1dGVz Lg0KDQogICBUaGlzIGRvY3VtZW50IHJlbGllcyBvbiBSRkMgZHJhZnQgYXZhaWxhYmxlIGluIGRz bDIwMDYuNTQ3DQogICBjb250cmlidXRpb24gZGVzY3JpYmluZyBhIHNldCBvZiBMYXllciAyIFR1 bm5lbGluZyBQcm90b2NvbCAoTDJUUCkNCiAgIEF0dHJpYnV0ZSBWYWx1ZSBQYWlyIFZlbmRvciAo QVZQKSBleHRlbnNpb25zIGRlc2lnbmVkIHRvIGNhcnJ5IHRoZQ0KICAgQWNjZXNzIExpbmUgaW5m b3JtYXRpb24gd2hpY2ggaXMgbm90IGN1cnJlbnQgYXZhaWxhYmxlIGJ5IHRoZQ0KICAgc3RhbmRh cmQgTDJUUCBBVlAgc2V0Lg0KDQogICBQYXJ0IDMgb2YgdGhpcyBkb2N1bWVudCBkZXRhaWxzIHRo ZSBvYmplY3RpdmVzIGFuZCB0aGUgYXNzdW1wdGlvbnMNCiAgIG1hZGUgaW4gdGhlIHdob2xlIGRv Y3VtZW50LiAgUGFydCA0IGluZGljYXRlcyB0aGUgY29uc2lkZXJlZCBpbnB1dHMNCiAgIHJhaXNp bmcgdGhlIG5lZWQgZm9yIG1vcmUgZGV0YWlsbGVkIHNwZWNpZmljYXRpb25zIGZvciB0aGUgTkFT LiAgUGFydA0KICAgNSBwcm92aWRlcyByZXF1aXJlbWVudHMgZm9yIHRoZSBOQVMgaW4gY2FzZSBv ZiBhbiBBVE0gb3IgYW4gRXRoZXJuZXQNCiAgIGFnZ3JlZ2F0aW9uIG5ldHdvcmsuDQoNCiAgIERp c2N1c3Npb25zIG9mIHRoaXMgZHJhZnQgbWF5IGJlIGRpcmVjdGVkIHRvIHRoZSBhdXRob3IuDQoN Cg0KMi4gIFN5c3RlbSBPdmVydmlldw0KDQogICBUaGUgc3lzdGVtIG92ZXJ2aWV3IGNvbnNpZGVy ZWQgaW4gdGhpcyBkcmFmdCBhbmQgc2NoZW1hdGljYWxseSBzaG93bg0KICAgaW4gRmlndXJlIDEg Y29uc2lzdHMgb2YgdGhlIGZvbGxvd2luZyBjb21wb25lbnRzOg0KDQogICBMMlRQIEFjY2VzcyBD b25jZW50cmF0b3IgKExBQykNCg0KICAgQSBub2RlIHRoYXQgYWN0cyBhcyBvbmUgc2lkZSBvZiBh biBMMlRQIHR1bm5lbCBlbmRwb2ludCBhbmQgaXMgYSBwZWVyDQogICB0byB0aGUgTDJUUCBOZXR3 b3JrIFNlcnZlciAoTE5TKS4gIFRoZSBMQUMgc2l0cyBiZXR3ZWVuIGFuIExOUyBhbmQgYQ0KICAg cmVtb3RlIHN5c3RlbSBhbmQgZm9yd2FyZHMgcGFja2V0cyB0byBhbmQgZnJvbSBlYWNoLiAgUGFj a2V0cyBzZW50DQogICBmcm9tIHRoZSBMQUMgdG8gdGhlIExOUyByZXF1aXJlcyB0dW5uZWxpbmcg d2l0aCB0aGUgTDJUUCBwcm90b2NvbC4NCiAgIFRoZSBjb25uZWN0aW9uIGZyb20gdGhlIExBQyB0 byB0aGUgcmVtb3RlIHN5c3RlbSBpcyBlaXRoZXIgbG9jYWwgb3IgYQ0KICAgUFBQIGxpbmsuDQoN CiAgIEwyVFAgTmV0d29yayBTZXJ2ZXIgKExOUykNCg0KICAgQSBub2RlIHRoYXQgYWN0cyBhcyBv bmUgc2lkZSBvZiBhbiBMMlRQIHR1bm5lbCBlbmRwb2ludCBhbmQgaXMgYSBwZWVyDQogICB0byB0 aGUgTDJUUCBBY2Nlc3MgQ29uY2VudHJhdG9yIChMQUMpLiAgVGhlIExOUyBpcyB0aGUgbG9naWNh bA0KDQoNCg0KRGVsYWZveSAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bmUgNCwgMjAwNyAg ICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERlY2VtYmVyIDIwMDYNCg0KDQogICB0ZXJt aW5hdGlvbiBwb2ludCBvZiBhIFBQUCBzZXNzaW9uIHRoYXQgaXMgYmVpbmcgdHVubmVsZWQgZnJv bSB0aGUNCiAgIHJlbW90ZSBzeXN0ZW0gYnkgdGhlIExBQy4NCg0KICAgTmV0d29yayBBY2Nlc3Mg U2VydmVyIChOQVMpDQoNCiAgIEEgZGV2aWNlIHByb3ZpZGluZyBsb2NhbCBuZXR3b3JrIGFjY2Vz cyB0byB1c2VycyBhY3Jvc3MgYSByZW1vdGUNCiAgIGFjY2VzcyBuZXR3b3JrLiAgQSBOQVMgbWF5 IGFsc28gc2VydmVzIGFzIGEgTEFDLCBMTlMgb3IgYm90aC4NCg0KICAgQWNjZXNzIE5vZGUgKEFO KToNCg0KICAgVGhlIEFOIGlzIGEgbmV0d29yayBkZXZpY2UsIHVzdWFsbHkgbG9jYXRlZCBhdCBh IHNlcnZpY2UgcHJvdmlkZXINCiAgIGNlbnRyYWwgb2ZmaWNlIG9yIHN0cmVldCBjYWJpbmV0LCB0 aGF0IHRlcm1pbmF0ZXMgQWNjZXNzIExvb3ANCiAgIGNvbm5lY3Rpb25zIGZyb20gc3Vic2NyaWJl cnMuICBJbiBjYXNlIHRoZSBBY2Nlc3MgTG9vcCBpcyBhIERpZ2l0YWwNCiAgIFN1YnNjcmliZXIg TGluZSAoRFNMKSwgdGhpcyBpcyBvZnRlbiByZWZlcnJlZCB0byBhcyBhIERTTCBBY2Nlc3MNCiAg IE11bHRpcGxleGVyIChEU0xBTSkuDQoNCiAgIEhvbWUgR2F0ZXdheSAoSEdXKToNCg0KICAgVGhl IEhHVyBjb25uZWN0cyB0aGUgZGlmZmVyZW50IEN1c3RvbWVyIFByZW1pc2VzIEVxdWlwbWVudCAo Q1BFKSB0bw0KICAgdGhlIEFjY2VzcyBOb2RlIGFuZCB0aGUgYWNjZXNzIG5ldHdvcmsuICBJbiBj YXNlIG9mIERTTCwgdGhlIEhHVyBpcyBhDQogICBEU0wgTmV0d29yayBUZXJtaW5hdGlvbiAoTlQp IHRoYXQgY291bGQgZWl0aGVyIG9wZXJhdGUgYXMgYSBsYXllciAyDQogICBicmlkZ2Ugb3IgYXMg YSBsYXllciAzIHJvdXRlci4gIEluIHRoZSBsYXR0ZXIgY2FzZSwgc3VjaCBhIGRldmljZSBpcw0K ICAgYWxzbyByZWZlcnJlZCB0byBhcyBhIFJvdXRpbmcgR2F0ZXdheSAoUkcpLg0KDQogICBOb3Rl IHRoYXQgdGhlIEFOLCB0aGUgTkFTIGFuZCB0aGUgTE5TIG1pZ2h0IGJlbG9uZyB0byBkaWZmZXJl bnQNCiAgIGFkbWluaXN0cmF0aXZlIHJlYWxtcy4NCg0KICAgKy0tLS0tKyAgICstLS0tLS0tLSsg ICAgICAgICAgICAgICAgICstLS0tLS0tKyAgICArLS0tLS0tLSsNCiAgIHwgSEdXIHwtLS18ICAg ICAgICB8ICAgICAgICAgICAgICAgICB8ICAgICAgIHwgICAgfCAgICAgICB8DQogICArLS0tLS0r ICAgfCBBY2Nlc3MgfCAgICstLS0tLS0tLS0rICAgfCAgICAgICB8ICAgIHwgICAgICAgfA0KICAg ICAgICAgICAgIHwgIE5vZGUgIHwtLS18IEFnZ3JlZy4gfC0tLXwgIE5BUyAgfC0tLS18ICBMTlMg IHwNCiAgICstLS0tLSsgICB8ICAgICAgICB8ICAgfCBOZXR3b3JrIHwgICB8ICBMQUMgIHwgICAg fCAgICAgICB8DQogICB8IEhHVyB8LS0tfCAgICAgICAgfCAgICstLS0tLS0tLS0rICAgfCAgICAg ICB8ICAgIHwgICAgICAgfA0KICAgKy0tLS0tKyAgICstLS0tLS0tLSsgICAgICAgICAgICAgICAg ICstLS0tLS0tKyAgICArLS0tLS0tLSsNCg0KICAgICAgICAgICAgICAgICBBY2Nlc3MgTm9kZSBD b250cm9sIE1lY2hhbmlzbQ0KICAgICAgICAgICAgICAgICAgPC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgIFBQUA0KICAgICAgPC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTDJUUA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPC0tLS0tLS0tLS0+DQogICBGaWd1cmUgMTogU3lz dGVtIE92ZXJ2aWV3DQoNCg0KMy4gIE9iamVjdGl2ZXMgYW5kIGFzc3VtcHRpb25zDQoNCiAgIFRo aXMgZG9jdW1lbnQgZm9jdXNlcyBvbiB0aGUgaW50ZXJhY3Rpb24gYmV0d2VlbiBvbmUgRFNMIENh cnJpZXIgYW5kDQogICBvbmUgTmV0d29yayBTZXJ2aWNlIFByb3ZpZGVyLiAgVGhlIE5TUCBwcm92 aWRlcyB0byBpdHMgY3VzdG9tZXIgb25lDQoNCg0KDQpEZWxhZm95ICAgICAgICAgICAgICAgICAg IEV4cGlyZXMgSnVuZSA0LCAyMDA3ICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRGVj ZW1iZXIgMjAwNg0KDQoNCiAgIG9yIG11bHRpcGxlIHNlcnZpY2VzIGJhc2VkIG92ZXIgb25lIHJl c2lkZW50aWFsIERTTCBsaW5lIGJlbG9uZ2luZyB0bw0KICAgdGhlIERTTCBjYXJyaWVyIHdoaWNo IHByb2xvbmdhdGVzIHRoZSBQUFAgc2Vzc2lvbiBmcm9tIHRoZSBOQVMgdG8gdGhlDQogICBMTlMg b2YgdGhlIE5TUCB1c2luZyB0aGUgTGF5ZXIgMiBUdW5uZWxsaW5nIFByb3RvY29sLg0KDQogICBU aGUgY3VycmVudCBbSS1ELm9vZ2hlLWFuY3AtZnJhbWV3b3JrXSBlbmFibGVzIHRoZSBOQVMgdG8g bWFuYWdlIGVhY2gNCiAgIGN1c3RvbWVyIGluZGl2aWR1YWxseSBiYXNlZCBvbiB0aGUgaW5mb3Jt YXRpb24gcHJvdmlkZWQgYnkgdGhlIGFjY2Vzcw0KICAgbm9kZS4gIFJlZ2FyZGluZyB0aGUgd2hv bGVzYWxlIGNvbnRleHQsIHRoZSBRb1MgcG9saWN5IGlzIHVuZGVyIHRoZQ0KICAgcmVzcG9uc2li aWxpdHkgb2YgdGhlIE5TUCBhbmQgaXQgY2FuIG5vdCBiZSBhc3N1bWVkIHRoYXQgdGhlIE5BUyBp cw0KICAgYXdhcmUgYW5kIGFwcGxpZXMgdGhlIFFvUyBwb2xpY3kgb2YgZWFjaCBOU1A6IHRoZSBO QVMgaXMgYWJsZSB0bw0KICAgaW1wbGVtZW50IGFuIGFjY3VyYXRlIHNoYXBlciBidXQgaXMgdW5h YmxlIHRvIHNjaGVkdWxlIHRoZSB0cmFmZmljIG9mDQogICBlYWNoIGN1c3RvbWVyIGJhc2VkIG9u IHRoZSBOU1AgUW9TIHBvbGljeS4gIFRoZXJlZm9yZSwgdGhpcyBpcyB0aGUNCiAgIHRhc2sgb2Yg dGhlIExOUyB0byBpbXBsZW1lbnQgYW4gYWNjdXJhdGUgcGVyLXN1YnNjcmliZXIgY29uZGl0aW9u ZXINCiAgIGFuZCBzY2hlZHVsZXIuICBUaGlzIGRvY3VtZW50IHByb3ZpZGUgcmVxdWlyZW1lbnRz IHRvIGVuc3VyZSB0aGF0IHRoZQ0KICAgcmVsZXZhbnQgYXR0cmlidXRlcyBhcmUgcHJvdmlkZWQg dG8gdGhlIExOUyBjb25zaWRlcmluZyB0aGUgZm91cg0KICAgZm9sbG93aW5nIGFzc3VtcHRpb25z Lg0KDQogICAxc3QgYXNzdW1wdGlvbjogTkFTIGFuZCB0aGUgTE5TIGJlbG9uZyB0byB0d28gZGlm ZmVyZW50DQogICBhZG1pbmlzdHJhdGl2ZSByZWFsbXMuDQoNCiAgIDJuZCBhc3N1bXB0aW9uOiBF YWNoIGN1c3RvbWVyIHVzZXMgYSBzaW5nbGUgUFBQIHNlc3Npb24gYW5kIHRoZSBMTlMNCiAgIGlz IHRoZSBzaW5nbGUgc291cmNlIG9mIHRyYWZmaWMgb24gdGhlIGN1c3RvbWVyIGFjY2VzcyBsb29w Lg0KDQogICAzcmQgYXNzdW1wdGlvbjogVGhlIExOUyBoYXMgdG8gYmUgYWJsZSB0byByZWFjaCB0 aGUgY3VycmVudGx5DQogICBhdmFpbGFibGUgYWNjZXNzIGxpbmUgZGF0YSByYXRlIGZvciBhIGdp dmVuIGFjY2VzcyBsb29wIGFuZCBBVE0gb3INCiAgIEV0aGVybmV0IGFnZ3JlZ2F0aW9uIG5ldHdv cmsgd2hpbGUgcHJldmVudGluZyBwYWNrZXQgbG9zcywgdGhhdCBtZWFucw0KICAgdGhhdCBubyBt YXJnaW4gdG8gcHJldmVudCBwYWNrZXQgbG9zcyBzaG91bGQgYmUgcmVxdWlyZWQgaW4gdGhlIExO Uy4NCg0KICAgNHRoIGFzc3VtcHRpb246IFRoZSBjYXNlIHdpdGggYSBOQVMgaW1wbGVtZW50aW5n IGEgc3RhdGljIHBlci0NCiAgIHN1YnNjcmliZXIgbG9jYWwgUW9TIHBvbGljeSBpbmRlcGVuZGVu dGx5IGZyb20gdGhlIGluZm9ybWF0aW9uDQogICBwcm92aWRlZCBieSB0aGUgQU4gaGFzIHRvIGJl IGNvbnNpZGVyZWQuDQoNCiAgIFRoZSBmaXJzdCBhc3N1bXB0aW9uIGhpZ2hsaWdodHMgb25lIG1h aW4gb2JqZWN0aXZlIG9mIHRoZSBOU1Agd2hpY2gNCiAgIGlzIHRoZSBwb3NzaWJpbGl0eSB0byBt YW5hZ2UgYSBwZXItc3Vic2NyaWJlciBRb1MgcG9saWN5DQogICBpbmRlcGVuZGVudGx5IGZyb20g dGhlIERTTCBjYXJyaWVyIHBvbGljeSBmb3Igb2J2aW91cyBRb1MgbWFuYWdlbWVudA0KICAgY29t cGxleGl0eSBhbmQgcmVwcm9kdWNpYmlsaXR5IGNvbmNlcm5zLiAgSG93ZXZlciwgdGhlIE5TUCBR b1MNCiAgIHJlcXVpcmVtZW50cyBhcmUgc2ltaWxhciB0byB0aGUgcmVxdWlyZW1lbnRzIG9mIGEg RFNMIGNhcnJpZXINCiAgIG1hbmFnaW5nIGhpcyBvd24gY3VzdG9tZXJzIGluIHRoZSBOQVMgc2lu Y2UgdGhlIE5TUCBtYXkgb2ZmZXINCiAgIG11bHRpcGxlIHNlcnZpY2VzIG92ZXIgb25lIFBQUCBz ZXNzaW9uLiAgVGhlIHNlY29uZCBhc3N1bXB0aW9uIGlzDQogICBtYW5kYXRvcnkgdG8gbWFuYWdl IHBlci1zdWJzY3JpYmVyIFFvUyBpbiB0aGUgTE5TLiAgSW4gY2FzZSBhbg0KICAgYWRkaXRpb25h bCBzb3VyY2Ugb2YgdHJhZmZpYyBpcyBjb25zaWRlcmVkLCB0aGUgTE5TIHdvdWxkIG5vdCBoYXZl DQogICB0aGUgYWJpbGl0eSB0byBtYW5hZ2UgUW9TIHdpdGhvdXQgc2hhcmluZyB0aGUgYXZhaWxh YmxlIGJhbmR3aWR0aC4NCg0KICAgVGhlIHNlY29uZCBjb25jZXJuIG9mIGEgTlNQIGlzIHJlZmxl Y3RlZCBpbiB0aGUgdGhpcmQgYXNzdW1wdGlvbi4gIEluDQogICB0aGUgTDJUUCBhcmNoaXRlY3R1 cmUsIHRoZSBMTlMgaXMgaW4gY2hhcmdlIG9mIHNoYXBpbmcgYW5kIHNjaGVkdWxpbmcNCiAgIGRv d25zdHJlYW0gdHJhZmZpYyB0byB0aGUgRFNMIG5ldCBkYXRhIHJhdGUgb3IgdG8gdGhlIE5BUyBk YXRhIHJhdGUNCiAgIHRha2luZyBpbnRvIGFjY291bnQgdGhlIGVuY2Fwc3VsYXRpb24gYXQgdGhl IGNvbmdlc3Rpb24gcG9pbnQuDQogICBPdGhlcndpc2UsIHNpZ25pZmljYW50IGFuZCBpbmRpc2Ny aW1pbmF0ZSBwYWNrZXQgbG9zcyBjYW4gcmVzdWx0Lg0KICAgRm9yIGluc3RhbmNlLCBpZiB0aGUg TE5TIGltcGxlbWVudHMgYSBwZXItY3VzdG9tZXIgSVAgc2hhcGVyIGFuZCB0aGUNCg0KDQoNCkRl bGFmb3kgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBKdW5lIDQsIDIwMDcgICAgICAgICAgICAg ICAgICBbUGFnZSA1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBEZWNlbWJlciAyMDA2DQoNCg0KICAgYWdncmVnYXRpb24gbmV0 d29yayBpcyBFdGhlcm5ldCBiYXNlZCwgdGhlbiB0aGUgTGF5ZXIgMiBvdmVyaGVhZA0KICAgYWRk ZWQgYXQgdGhlIEFjY2VzcyBOb2RlIGJ5IHRoZSBBVE0gbGF5ZXIgaW4gY2FzZSBvZiBhbiBBRFNM IGFjY2Vzcw0KICAgY2FuIGluY3JlYXNlIHBhY2tldCBvdmVyaGVhZCB0byB0aGUgcG9pbnQgd2hl cmUgdGhlIHBoeXNpY2FsIGxpbmUNCiAgIHJhdGUgaXMgZXhjZWVkZWQuICBUaGVyZWZvcmUgdGhl IExOUyBuZWVkcyB0byBiZSBwcm92aWRlZCB3aXRoIHRoZQ0KICAgcmF0ZSBhbmQgdGhlIG5hdHVy ZSBvZiB0aGUgZW5jYXBzdWxhdGlvbiBhdCB0aGUgY29uZ2VzdGlvbiBwb2ludCwgc28NCiAgIHRo YXQgdGhlIElQIHNoYXBpbmcgcmF0ZSBpbiB0aGUgTE5TIGNhbiBiZSBhZGp1c3RlZCB0YWtpbmcg aW50bw0KICAgYWNjb3VudCB0aGUgZ2VuZXJhdGVkIG92ZXJoZWFkLCBieSBlbXVsYXRpbmcgYW4g QVRNIHNoYXBlciBpZiBuZWVkZWQuDQogICBIb3dldmVyLCB0aGUgY3VycmVudGx5IGRlZmluZWQg QVZQIGRvIG5vdCBlbmFibGUgdGhlIExOUyB0byBiZQ0KICAgcHJvdmlkZWQgd2l0aCBldmVyeSBy YXRlIGFuZCBlbmNhcHN1bGF0aW9uIGF0IGVhY2ggcG90ZW50aWFsDQogICBjb25nZXN0aW9uIHBv aW50LiAgSXQgbWVhbnMgdGhhdCBpbiBjYXNlIEFUTSBpcyB1c2VkIG9uIERTTCBhY2Nlc3MsDQog ICB0aGUgTE5TIGNhbiBiZSBwcm92aWRlZCBvbmx5IHdpdGggdGhlIGVuY2Fwc3VsYXRpb24gYXQg dGhlIGFjY2Vzcw0KICAgbGluZSBhbmQgdGhlIEwyIGRhdGEgcmF0ZSBhdCB0aGUgY29uZ2VzdGlv biBwb2ludC4gdGhpcyByZXN1bHRzIGluIGENCiAgIGJhbmR3aWR0aCB3YXN0ZSBpbiBjYXNlIHRo ZSBjb25nZXN0aW9uIHBvaW50IGlzIHRoZSBCTkcgd2l0aCBhbg0KICAgRXRoZXJuZXQgYWdncmVn YXRpb24gbmV0d29yay4NCg0KICAgVGhlc2UgYXNzdW1wdGlvbnMgcmFpc2UgdGhlIG5lZWQgZm9y IGEgc3BlY2lmaWNhdGlvbiB0byBleHRlbmQgdGhlDQogICBhY2Nlc3MgcG9ydCBkaXNjb3Zlcnkg dXNlIGNhc2UgZGVzY3JpYmVkIGluIFtJLUQub29naGUtYW5jcC0NCiAgIGZyYW1ld29ya10gZnJv bSB0aGUgTkFTIGFjdGluZyBhcyBhIExBQyB0byB0aGUgTE5TIHVuZGVyIHRoZSBOU1ANCiAgIHJl c3BvbnNpYmlsaXR5LiAgVGhpcyBOQVMgc3BlY2lmaWNhdGlvbiBvbiB0aGUgbWV0aG9kIHRvIGZ1 bGZpbCB0aGUNCiAgIEwyVFAgQVZQcyBlbmFibGVzIHRoZSBOU1AgdG8gcHJldmVudCBhbnkgcGFj a2V0IGxvc3MgaW4gdGhlDQogICBhZ2dyZWdhdGlvbiBhbmQgYWNjZXNzIG5ldHdvcmsuDQoNCg0K NC4gIElucHV0cw0KDQo0LjEuICBBTkNQIGZyYW1ld29yaw0KDQogICBUaGlzIGRyYWZ0IHJlbGll cyBvbiB0aGUgW0ktRC5vb2doZS1hbmNwLWZyYW1ld29ya10gZG9jdW1lbnQgd2hpY2gNCiAgIGZp cnN0IHVzZSBjYXNlIGZvciB0aGUgQU5DUCBwcm90b2NvbCBpcyB0aGUgRHluYW1pYyBBY2Nlc3Mg TG9vcA0KICAgQXR0cmlidXRlcy4gIEl0IGlzIHNwZWNpZmllZCBpbiB0aGlzIHVzZSBjYXNlIHRo YXQgZm9yIFFvUyBwdXJwb3NlLA0KICAgdGhlIE5BUyBuZWVkcyB0byBnYWluIGtub3dsZWRnZSBh Ym91dCB0aGUgdG9wb2xvZ3kgb2YgdGhlIGFjY2Vzcw0KICAgbmV0d29yaywgdGhlIHZhcmlvdXMg bGlua3MgYmVpbmcgdXNlZCBhbmQgdGhlaXIgcmVzcGVjdGl2ZSByYXRlcy4NCiAgIFNvbWUgb2Yg dGhlIGluZm9ybWF0aW9uIHJlcXVpcmVkIGlzIHNvbWV3aGF0IGR5bmFtaWMgaW4gbmF0dXJlIChl LmcuDQogICBEU0wgYWN0dWFsIGRhdGEgcmF0ZSwgYWxzbyBrbm93biBhcyB0aGUgIkRTTCBzeW5j IHJhdGUiKSwgaGVuY2UNCiAgIGNhbm5vdCBjb21lIGZyb20gYSBwcm92aXNpb25pbmcgYW5kL29y IGludmVudG9yeSBtYW5hZ2VtZW50IE9TUw0KICAgc3lzdGVtLg0KDQogICBUaGUgdXNlIGNhc2Ug Y29uc2lkZXJlZCBpbiB0aGlzIGRvY3VtZW50IHJhaXNlcyB0aGUgc2FtZSBRb1MgaXNzdWVzDQog ICBmcm9tIGEgTlNQIHBlcnNwZWN0aXZlLg0KDQo0LjIuICBMMlRQIEFWUCBFeHRlbnNpb25zIGRy YWZ0DQoNCiAgIFRoaXMgY3VycmVudCBkb2N1bWVudCBkZWFscyB3aXRoIHRoZSBMMlRQIGFjY2Vz cyBhZ2dyZWdhdGlvbg0KICAgYXJjaGl0ZWN0dXJlIGFuZCB0aGVyZWZvcmUgcmVsaWVzIG9uIHRo ZSBhdHRyaWJ1dGVzIHByZXNlbnRlZCBpbiB0aGUNCiAgIFJGQyBkcmFmdCBuYW1lZCBMMlRQIEFj Y2VzcyBMaW5lIEluZm9ybWF0aW9uIEFWUCBFeHRlbnNpb25zIGluY2x1ZGVkDQogICBpbiB0aGUg Y29udHJpYnV0aW9uIGRzbDIwMDYuNTQ3LjAwLiAgVGhpcyBjdXJyZW50IGRvY3VtZW50IHVzZXMg dGhlDQogICBBVlAgYW5kIG1lc3NhZ2VzIGRlc2NyaWJlZCBpbiB0aGlzIGRyYWZ0Lg0KDQoNCg0K DQpEZWxhZm95ICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVuZSA0LCAyMDA3ICAgICAgICAg ICAgICAgICAgW1BhZ2UgNl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgRGVjZW1iZXIgMjAwNg0KDQoNCjQuMy4gIFdULTE0NyBy ZXF1aXJlbWVudHMNCg0KICAgRm9sbG93aW5nIGFyZSB0aGUgaGlnaC1sZXZlbCByZXF1aXJlbWVu dHMgaGF2ZSBiZWVuIGluY2x1ZGVkIGluIFdULQ0KICAgMTQ3Og0KDQogICAtIFRoZSBOQVMgd2hl biBhY3RpbmcgYXMgYSBMQUMgbmVlZHMgdG8gY29tbXVuaWNhdGUgZ2VuZXJpYyBhY2Nlc3MNCiAg IGxpbmUgcmVsYXRlZCBpbmZvcm1hdGlvbiB0byB0aGUgTE5TIGluIGEgdGltZWx5IGZhc2hpb24u DQoNCiAgIC0gVGhlIE5BUyB3aGVuIGFjdGluZyBhcyBhIExBQyBtYXkgYXN5bmNocm9ub3VzbHkg bm90aWZ5IHRoZSBMTlMgb2YNCiAgIHVwZGF0ZXMgdG8gZ2VuZXJpYyBhY2Nlc3MgbGluZSByZWxh dGVkIGluZm9ybWF0aW9uLg0KDQogICBUaGVzZSBoaWdoLWxldmVsIHJlcXVpcmVtZW50cyBhcmUg Y29uc2lkZXJlZCBhcyBpbnB1dHMgYW5kIHRoaXMNCiAgIGN1cnJlbnQgZG9jdW1lbnQgcHJvcG9z ZXMgYSBkZXRhaWxlZCBzcGVjaWZpY2F0aW9uIHRvIGVuc3VyZSB0aGF0IHRoZQ0KICAgY29uY2Vy bmVkIEwyVFAgQVZQIHByb3ZpZGVzIHRoZSByZWxldmFudCBpbmZvcm1hdGlvbiB0byB0aGUgTE5T Lg0KDQoNCjUuICBOQVMgbG9jYWwgcG9saWN5DQoNCiAgIFRoZSBhaW0gb2YgdGhpcyBzZWN0aW9u IGlzIHRvIGZvY3VzIG9uIHRoZSBJQ1JRLCBJQ0NOIGFuZCBDU1VOIEwyVFANCiAgIGNvbnRyb2wg bWVzc2FnZXMgYW5kIHRoZSBmb2xsb3dpbmcgYXR0cmlidXRlczoNCg0KICAgLSBBY3R1YWwtRGF0 YS1SYXRlLURvd25zdHJlYW0gYW5kIEFjY2Vzcy1MaW5lLUVuY2Fwc3VsYXRpb24gQVZQcw0KICAg aW5jbHVkZWQgaW4gdGhlIElDUlEgbWVzc2FnZQ0KDQogICAtIFR4IENvbm5lY3QgU3BlZWQgQVZQ IDI0IGluY2x1ZGVkIGluIHRoZSBJQ0NOIG1lc3NhZ2UgKGNmLiBSRkMgMjY2MSkNCiAgIFtSRkMy NjYxXQ0KDQogICAtIENvbm5lY3QgU3BlZWQgVXBkYXRlIGF0dHJpYnV0ZSBpbmNsdWRlZCBpbiB0 aGUgQ1NVTiBtZXNzYWdlDQoNCiAgIEEgc3BlY2lmaWMgTkFTL0xBQyBsb2NhbCBwb2xpY3kgaXMg cHJvcG9zZWQgaW4gdGhpcyBwYXJ0IHRvIGVuYWJsZQ0KICAgdGhlIExOUyB0byBpbXBsZW1lbnQg YW4gYWNjdXJhdGUgcGVyLXN1YnNjcmliZXIgUW9TIG1hbmFnZW1lbnQgYXMNCiAgIHNwZWNpZmll ZCBpbiBzZWN0aW9uIDMuDQoNCjUuMS4gIENhc2Ugb2YgYW4gQVRNIGFnZ3JlZ2F0aW9uIG5ldHdv cmsNCg0KICAgSW4gY2FzZSBvZiBhbiBBVE0gYWdncmVnYXRpb24gbmV0d29yaywgdGhlIE5BUyBt YXkgaW1wbGVtZW50IHZhcmlvdXMNCiAgIHBlci1zdWJzY3JpYmVyIChvciBwZXItVkMpIFFvUyBt YW5hZ2VtZW50LiAzIGNhc2VzIGRlc2NyaWJpbmcNCiAgIGRpZmZlcmVudCBRb1MgaW1wbGVtZW50 YXRpb24gYXJlIGNvbnNpZGVyZWQ6DQoNCiAgIC0gQ2FzZSAxOiBUaGUgTkFTIGRvZXMgbm90IGlt cGxlbWVudCBhbnkgcGVyLWN1c3RvbWVyIHRyYWZmaWMNCiAgIGNvbmRpdGlvbmluZyBhbmQgdGhl IGNvbmdlc3Rpb24gcG9pbnQgaXMgYXNzdW1lZCB0byBiZSB0aGUgZGF0YSByYXRlDQogICBhdmFp bGFibGUgYXQgdGhlIGFjY2VzcyBsb29wLg0KDQogICAtIENhc2UgMjogVGhlIE5BUyBpbXBsZW1l bnRzIGEgcGVyLWN1c3RvbWVyIFFvUyBtYW5hZ2VtZW50IHdpdGggYW4NCiAgIGFkYXB0YXRpdmUg QVRNIHNoYXBlciBiYXNlZCBvbiB0aGUgZGF0YSByYXRlIGluZm9ybWF0aW9uIHByb3ZpZGVkIGJ5 DQogICBBTkNQLiAgSW4gdGhhdCBjYXNlLCB0aGUgY29uZ2VzdGlvbiBwb2ludCBpcyB0aGUgTkFT IGJ1dCBpdCBjYW4gYmUNCiAgIGFzc3VtZWQgdG8gYmUgdGhlIGFjY2VzcyBsaW5lLg0KDQoNCg0K DQpEZWxhZm95ICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVuZSA0LCAyMDA3ICAgICAgICAg ICAgICAgICAgW1BhZ2UgN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgRGVjZW1iZXIgMjAwNg0KDQoNCiAgIC0gQ2FzZSAzOiBU aGUgTkFTIGltcGxlbWVudHMgYSBwZXItY3VzdG9tZXIgUW9TIG1hbmFnZW1lbnQgYW5kIG9uZQ0K ICAgc2hhcGluZyB2YWx1ZSBpcyBjb25maWd1cmVkIGluZGVwZW5kZW50bHkgZnJvbSB0aGUgYWNj ZXNzIGxvb3AgZGF0YQ0KICAgcmF0ZS4gIEluIHRoaXMgY2FzZSwgbm8gYSBwcmlvcmkgYXNzdW1w dGlvbiBjYW4gYmUgbWFkZSBvbiB0aGUNCiAgIGNvbmdlc3Rpb24gcG9pbnQgbG9jYXRpb24uDQoN CjUuMi4gIENhc2Ugb2YgYW4gRXRoZXJuZXQgYWdncmVnYXRpb24gbmV0d29yaw0KDQogICBJbiBj YXNlIG9mIGFuIEV0aGVybmV0IGFnZ3JlZ2F0aW9uIG5ldHdvcmssIHRoZSBwZXItc3Vic2NyaWJl ciBRb1MNCiAgIG1hbmFnZW1lbnQgaXNzdWUgaW4gdGhlIExOUyBpcyBzb21ld2hhdCBtb3JlIGNv bXBsZXggYmVjYXVzZSBvZiB0aGUNCiAgIGluYWJpbGl0eSBvZiB0aGUgTkFTIHRvIGRldGVybWlu ZSB3aGVyZSB0aGUgY29uZ2VzdGlvbiBwb2ludCBpcyBpbg0KICAgY2FzZSBpdCBpbXBsZW1lbnRz IGFuIEV0aGVybmV0IG9yIElQIHNoYXBlciBzaW5jZSBtYWtpbmcgYSBkZXRhaWxlZA0KICAgY29t cGFyaXNvbiBiZXR3ZWVuIEwyIGRhdGEgcmF0ZSBpcyBwb3NzaWJsZSBvbmx5IGJ5IG1ha2luZyBv bmUNCiAgIGFzc3VtcHRpb24gb24gSVAgcGFja2V0cyBzaXplLiA0IGRpc3RpbmN0IGNhc2VzIGRl c2NyaWJpbmcgZGlmZmVyZW50DQogICBwZXItc3Vic2NyaWJlciBRb1MgbWFuYWdlbWVudCBhcmUg Y29uc2lkZXJlZDoNCg0KICAgLSBDYXNlIDE6IFRoZSBOQVMgZG9lcyBub3QgaW1wbGVtZW50IGFu eSBwZXItY3VzdG9tZXIgdHJhZmZpYw0KICAgY29uZGl0aW9uaW5nIGFuZCBpdCBpcyBhc3N1bWVk IHRoYXQgdGhlIGNvbmdlc3Rpb24gcG9pbnQgaXMgdGhlIGRhdGENCiAgIHJhdGUgYXZhaWxhYmxl IGF0IHRoZSBhY2Nlc3MgbG9vcC4NCg0KICAgLSBDYXNlIDI6IFRoZSBOQVMgaW1wbGVtZW50cyBh biBhY2N1cmF0ZSBwZXItY3VzdG9tZXIgUW9TIG1hbmFnZW1lbnQNCiAgIHdoaWNoIGVtdWxhdGVz IGFuIEFUTSBzaGFwZXIgc28gdGhhdCB0aGUgSVAgc2hhcGVyIHRha2VzIGludG8gYWNjb3VudA0K ICAgdGhlIG92ZXJoZWFkIGR1ZSB0byB0aGUgQVRNIGxheWVyIGFjY29yZGluZyB0byBJUCBwYWNr ZXQncyBsZW5ndGguDQogICBJbiB0aGF0IGNhc2UsIHRoZSBjb25nZXN0aW9uIHBvaW50IGlzIHRo ZSBOQVMuDQoNCiAgIC0gQ2FzZSAzOiBUaGUgTkFTIGltcGxlbWVudHMgYSBwZXItY3VzdG9tZXIg UW9TIG1hbmFnZW1lbnQgYW5kIG9uZQ0KICAgZml4ZWQgZXJyb3IgbWFyZ2luIGlzIHN1YnRyYWN0 ZWQgdG8gdGhlIGFjdHVhbCBhY2Nlc3MgbG9vcCBkYXRhIHJhdGUNCiAgIHRvIHByZXZlbnQgY29u Z2VzdGlvbiBpbiB0aGUgQU4uDQoNCiAgIC0gQ2FzZSA0OiBUaGUgTkFTIGltcGxlbWVudHMgYSBw ZXItY3VzdG9tZXIgUW9TIG1hbmFnZW1lbnQgYW5kIG9uZQ0KICAgc3RhdGljIHNoYXBpbmcgdmFs dWUgaXMgY29uZmlndXJlZCBpbmRlcGVuZGVudGx5IGZyb20gdGhlIGFjY2VzcyBsb29wDQogICBk YXRhIHJhdGUuDQoNCjUuMy4gIFJlcXVpcmVtZW50cw0KDQogICBJbiBvcmRlciB0byBoYXZlIGEg c2luZ2xlIHNwZWNpZmljYXRpb24gZm9yIEJORyB0YWtpbmcgaW50byBhY2NvdW50DQogICBlYWNo IG9mIHRoZSBwcmV2aW91cyBjYXNlcywgcmVxdWlyZW1lbnRzIGZvciBMMlRQIEFWUHMgYXJlOg0K DQogICBSLTAxOiBJbiBjYXNlIG9mIGFuIEFUTSBhZ2dyZWdhdGlvbiBuZXR3b3JrLCB0aGUgTkFT L0xBQyBNVVNUIGZpbGwNCiAgIHRoZSBBY2Nlc3MtbG9vcC1lbmNhcHN1bGF0aW9uIEFWUCBwcmVz ZW50IGluIHRoZSBJQ1JRIEwyVFAgY29udHJvbA0KICAgbWVzc2FnZSB3aXRoIHRoZSBlbmNhcHN1 bGF0aW9uIHVzZWQgb3ZlciB0aGUgYWdncmVnYXRpb24gbmV0d29yay4NCg0KICAgUi0wMjogSW4g Y2FzZSBvZiBhbiBFdGhlcm5ldCBhZ2dyZWdhdGlvbiBuZXR3b3JrLCBUaGUgTkFTL0xBQyBNVVNU DQogICBmaWxsIHRoZSBBY2Nlc3MtbG9vcC1lbmNhcHN1bGF0aW9uIEFWUCBwcmVzZW50IGluIHRo ZSBJQ1JRIEwyVFANCiAgIGNvbnRyb2wgbWVzc2FnZSB3aXRoIHRoZSBhY2Nlc3MtbG9vcCBlbmNh cHN1bGF0aW9uIHByb3ZpZGVkIGJ5IFBQUG9FLg0KDQogICBSLTAzOiB0aGUgTkFTL0xBQyBNVVNU IGZpbGwgdGhlIEFjdHVhbC1EYXRhLVJhdGUtRG93bnN0cmVhbSBBVlANCiAgIHByZXNlbnQgaW4g dGhlIElDUlEgTDJUUCBjb250cm9sIG1lc3NhZ2Ugd2l0aCB0aGUgdmFsdWUgcHJvdmlkZWQgYnkN CiAgIEFOQ1AsIGlmIGF2YWlsYWJsZS4NCg0KDQoNCkRlbGFmb3kgICAgICAgICAgICAgICAgICAg RXhwaXJlcyBKdW5lIDQsIDIwMDcgICAgICAgICAgICAgICAgICBbUGFnZSA4XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBEZWNl bWJlciAyMDA2DQoNCg0KICAgSW4gY2FzZSB0aGUgc2Vzc2lvbiBzZXR1cCB0aW1lIGlzIGNyaXRp Y2FsLCB0aGUgTDJUUCBjb250cm9sIG1lc3NhZ2VzDQogICBleGNoYW5nZSBtYXkgc3RhcnQgYmVm b3JlIHRoZSBOQVMgcmVjZWl2ZXMgdGhlIGFjY2VzcyBsb29wDQogICBpbmZvcm1hdGlvbiBwcm92 aWRlZCBieSBBTkNQLiAgSW4gc3VjaCBjYXNlLCB0aGUgYWN0dWFsIGRvd25zdHJlYW0NCiAgIGRh dGEgcmF0ZSBBVlAgbWF5IGJlIGVtcHR5IGFuZCB1cGRhdGVkIHdpdGggYSBDU1VOIG1lc3NhZ2Ug d2hlbg0KICAgYXZhaWxhYmxlLg0KDQogICBBbm90aGVyIGFwcHJvYWNoIGNvdWxkIGJlIHRvIHNw ZWNpZnkgdGhhdCBhIGZpcnN0IEFOQ1AgbWVzc2FnZSBjb3VsZA0KICAgYmUgc2VudCBwcmlvciB0 byBQUFAgbmVnb3RpYXRpb24gd2l0aCBkZWZhdWx0IHZhbHVlcy4gIFRoZXNlIGRlZmF1bHQNCiAg IHZhbHVlcyBjb3VsZCBhbHNvIGJlIHRoZSBsYXN0IHZhbHVlIHJlY29yZGVkIGZvciB0aGlzIGFj Y2VzcyBsb29wIGluDQogICBjYXNlIHRoZSBBTiBrZWVwcyBhIGNvbnRleHQgZm9yIGVhY2ggYWNj ZXNzIGxvb3Agd2l0aCB0aGUgbGFzdA0KICAgaW5mb3JtYXRpb24gcmVwb3J0ZWQgYnkgQU5DUC4N Cg0KICAgUi0wNDogVGhlIFR4IENvbm5lY3QgU3BlZWQgQVZQIDI0IHByZXNlbnQgaW4gdGhlIElD Q04gTDJUUCBjb250cm9sDQogICBtZXNzYWdlIHNwZWNpZmllZCBpbiBSRkMgMjY2MSBbUkZDMjY2 MV0gTVVTVCBiZSB0aGUgTDIgZGF0YSByYXRlDQogICBjb25maWd1cmVkIHBlciBjdXN0b21lciBh dCB0aGUgTkFTLiAgSXQgc2hvdWxkIGJlIHZvaWQgaW4gY2FzZSAxIGFuZA0KICAgMiB3aGVyZSB0 aGUgY29uZ2VzdGlvbiBwb2ludCBpcyBhc3N1bWVkIHRvIGJlIHRoZSBhY2Nlc3MgbGluZS4NCg0K ICAgVGhlIEFjdHVhbC1EYXRhLVJhdGUtRG93bnN0cmVhbSBBVlAgcHJlc2VudCBpbiB0aGUgQ1NV TiBMMlRQIGNvbnRyb2wNCiAgIG1lc3NhZ2VzIG11c3QgYmUgcmVsZXZhbnQgZm9yIHRoZSBMTlMg d2hpY2ggbG9va3MgZm9yIHRoZSBkYXRhLXJhdGUNCiAgIGF0IHRoZSBjb25nZXN0aW9uIHBvaW50 OiB0aGUgQVZQIHNob3VsZCBub3QgY29udGFpbiB0aGUgYWNjZXNzIGxvb3ANCiAgIGRhdGEgcmF0 ZSBpbiBjYXNlIGEgcGVyIGN1c3RvbWVyIGRhdGEgcmF0ZSBpcyBjb25maWd1cmVkIGluIHRoZSBO QVMNCiAgIGF0IGEgbG93ZXIgdmFsdWUuDQoNCiAgIFItMDU6IFRoZSBOQVMvTEFDIE1VU1QgZmls bCB0aGUgQ29ubmVjdCBTcGVlZCB1cGRhdGUgQVZQIHByZXNlbnQgaW4NCiAgIHRoZSBDU1VOIEwy VFAgY29udHJvbCBtZXNzYWdlcyB3aXRoIHRoZSBtaW5pbXVtIHZhbHVlIG9mIHRoZSBMMg0KICAg QWN0dWFsLURhdGEtUmF0ZS1Eb3duc3RyZWFtIEFWUCBhbmQgdGhlIEwyIFR4IENvbm5lY3QgU3Bl ZWQgQVZQLg0KDQoNCjYuICBBY2tub3dsZWRnZW1lbnRzDQoNCiAgIFBsZWFzZSBhZGQgeW91ciBu YW1lIGhlcmUuDQoNCg0KNy4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtSRkMyMTE5XSAg QnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlDQogICAg ICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5 OTcuDQoNCiAgIFtSRkMyNjYxXSAgVG93bnNsZXksIFcuLCBWYWxlbmNpYSwgQS4sIFJ1YmVucywg QS4sIFBhbGwsIEcuLCBab3JuLA0KICAgICAgICAgICAgICBHLiwgYW5kIEIuIFBhbHRlciwgIkxh eWVyIFR3byBUdW5uZWxpbmcgUHJvdG9jb2wgIkwyVFAiIiwNCiAgICAgICAgICAgICAgUkZDIDI2 NjEsIEF1Z3VzdCAxOTk5Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpEZWxhZm95ICAgICAgICAgICAg ICAgICAgIEV4cGlyZXMgSnVuZSA0LCAyMDA3ICAgICAgICAgICAgICAgICAgW1BhZ2UgOV0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgRGVjZW1iZXIgMjAwNg0KDQoNCkF1dGhvcidzIEFkZHJlc3MNCg0KICAgQW50b2luZSBEZWxh Zm95DQogICBjZSBUZWxlY29tDQoNCg0KICAgUGhvbmU6DQogICBGYXg6DQogICBFbWFpbDogYW50 b2luZS5kZWxhZm95QG9yYW5nZS1mdGdyb3VwLmNvbQ0KICAgVVJJOg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCkRlbGFmb3kgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBKdW5lIDQsIDIwMDcg ICAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBEZWNlbWJlciAyMDA2DQoNCg0KRnVsbCBD b3B5cmlnaHQgU3RhdGVtZW50DQoNCiAgIENvcHlyaWdodCAoQykgVGhlIElFVEYgVHJ1c3QgKDIw MDYpLg0KDQogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gdGhlIHJpZ2h0cywgbGljZW5z ZXMgYW5kIHJlc3RyaWN0aW9ucw0KICAgY29udGFpbmVkIGluIEJDUCA3OCwgYW5kIGV4Y2VwdCBh cyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMNCiAgIHJldGFpbiBhbGwgdGhlaXIgcmln aHRzLg0KDQogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhl cmVpbiBhcmUgcHJvdmlkZWQgb24gYW4NCiAgICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBDT05UUklC VVRPUiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVTRU5UUw0KICAgT1IgSVMgU1BPTlNP UkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSwgVEhFIElFVEYgVFJVU1QgQU5E DQogICBUSEUgSU5URVJORVQgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBBTEwgV0FS UkFOVElFUywgRVhQUkVTUw0KICAgT1IgSU1QTElFRCwgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRF RCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GDQogICBUSEUgSU5GT1JNQVRJT04gSEVS RUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQNCiAgIFdBUlJB TlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQ T1NFLg0KDQoNCkludGVsbGVjdHVhbCBQcm9wZXJ0eQ0KDQogICBUaGUgSUVURiB0YWtlcyBubyBw b3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueQ0KICAgSW50ZWxs ZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFp bWVkIHRvDQogICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRl Y2hub2xvZ3kgZGVzY3JpYmVkIGluDQogICB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8g d2hpY2ggYW55IGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdodHMNCiAgIG1pZ2h0IG9yIG1pZ2h0IG5v dCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhhcw0KICAgbWFk ZSBhbnkgaW5kZXBlbmRlbnQgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gIElu Zm9ybWF0aW9uDQogICBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGlu IFJGQyBkb2N1bWVudHMgY2FuIGJlDQogICBmb3VuZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4NCg0K ICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0 IGFuZCBhbnkNCiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUs IG9yIHRoZSByZXN1bHQgb2YgYW4NCiAgIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5lcmFs IGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZSBvZg0KICAgc3VjaCBwcm9wcmlldGFy eSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMNCiAgIHNwZWNpZmljYXRp b24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9yeSBh dA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuDQoNCiAgIFRoZSBJRVRGIGludml0ZXMgYW55 IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkNCiAgIGNvcHly aWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRh cnkNCiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVp cmVkIHRvIGltcGxlbWVudA0KICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBp bmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdA0KICAgaWV0Zi1pcHJAaWV0Zi5vcmcuDQoNCg0KQWNr bm93bGVkZ21lbnQNCg0KICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVuY3Rpb24gaXMg cHJvdmlkZWQgYnkgdGhlIElFVEYNCiAgIEFkbWluaXN0cmF0aXZlIFN1cHBvcnQgQWN0aXZpdHkg KElBU0EpLg0KDQoNCg0KDQoNCkRlbGFmb3kgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBKdW5l IDQsIDIwMDcgICAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDA0KDQo= ------_=_NextPart_001_01C71560.3777E438 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_01C71560.3777E438-- From ancp-bounces@ietf.org Fri Dec 01 12:16:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqBzk-0005y0-W5; Fri, 01 Dec 2006 12:16:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqBzk-0005w0-I6 for ancp@ietf.org; Fri, 01 Dec 2006 12:16:16 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GqAhM-0001rJ-Ve for ancp@ietf.org; Fri, 01 Dec 2006 10:53:14 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-4.cisco.com with ESMTP; 01 Dec 2006 07:52:52 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kB1Fqp2H001156; Fri, 1 Dec 2006 10:52:51 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kB1FqpDM023711; Fri, 1 Dec 2006 10:52:51 -0500 (EST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 10:52:51 -0500 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] Protocol version nummer for ANCP Date: Fri, 1 Dec 2006 10:52:50 -0500 Message-ID: <3C292CE901FC634693F24FB2DDC4D332024A5FD2@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Protocol version nummer for ANCP Thread-Index: AccVQum3qm4RL8oMQHKZQvU2NrY2ugAGrinQ From: "Steve Senum \(ssenum\)" To: "Busser, M" X-OriginalArrivalTime: 01 Dec 2006 15:52:51.0412 (UTC) FILETIME=[C1B2E940:01C71560] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2542; t=1164988372; x=1165852372; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ssenum@cisco.com; z=From:=20=22Steve=20Senum=20\(ssenum\)=22=20 |Subject:=20RE=3A=20[ANCP]=20Protocol=20version=20nummer=20for=20ANCP |Sender:=20 |To:=20=22Busser,=20M=22=20; bh=GR39imM9CuzcMpM3NVH+bLG/B/imjKa+pArzIIQ/Xbc=; b=DlhaAiVfhtaZR7gBtjt4YcbcLyFCsPU3Q+W608CypKqjKU0wbjZveE22PmGMn+F2xlsNbudK GbqPyfuuJksLOk95cy25d28Ng4uAMy12US3EjFHK/DxG4N2dSKrBYCgp; Authentication-Results: rtp-dkim-1; header.From=ssenum@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi, This should be avoided if at all possible. You are adding complexity into the protocol and implementations to deal with issues between drafts, which will need to be carried forwarded when this becomes a RFC. I have not seen an Internet Area Director support this in past instances. You can't even reference an internet-draft in an RFC. The other ways I have seen this dealt with in the past, somewhat in order of preference: 1. Clean cutover approach, all system roll to a new version. 2. Add checks in the code to deal with known cases. 3. Add a version setting to the config to handle this. Regards, Steve Senum > =20 >=20 > -----Original Message----- > From: Busser, M [mailto:Michael.Busser@t-systems.com]=20 > Sent: Friday, December 01, 2006 6:19 AM > To: ancp@ietf.org > Subject: [ANCP] Protocol version nummer for ANCP >=20 > Hi all. >=20 > =20 > Problem: > Currently different codes exist referring to=20 > draft-wadhwa-gsmp-l2control-configuration-00 &=20 > draft-wadhwa-gsmp-l2control-configuration-02. > =20 > The lack of having different codes in different network elements is to > create a situation of non interoperable TLV because TLV changed (e.g. > 90/91) > =20 > Solution: > The only way out is to define a protocol version field in combination > with a software management in the network element: > =20 > A proposal is shown below: > =20 > We should have a format like version number, where main as > well as sub is represented by a 1 byte value.=20 > We should start with 0.1 representing > draft-wadhwa-gsmp-l2control-configuration-02. > =20 > Procedures > Add a new Capability: Version Length=3D4 > Byte 0 =3D Main Version Nr of > oldest supported protocol version > Byte 1 =3D Sub Version Nr of > oldest supported protocol version > Byte 2 =3D Main Version Nr of > latest supported protocol version > Byte 3 =3D Sub Version Nr of > latest supported protocol version > =20 > If only one specific version is supported by a network element, the=20 > oldest and the latest version number are the same. > =20 > Requirement: > =20 > To define a protocol version TLV first before enhancing=20 > draft-wadhwa-gsmp-l2control-configuration-02 in further steps. > =20 > =20 > =20 > Best regards > =20 > Thomas & Michael >=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 Fri Dec 01 12:28:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqCBM-00057M-Kw; Fri, 01 Dec 2006 12:28:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqBzB-0004Qi-GH for ancp@ietf.org; Fri, 01 Dec 2006 12:15:41 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqBz9-00067S-40 for ancp@ietf.org; Fri, 01 Dec 2006 12:15:41 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id AE7762EC7D7 for ; Fri, 1 Dec 2006 09:15:38 -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 15248-09 for ; Fri, 1 Dec 2006 09:15:38 -0800 (PST) Received: from [127.0.0.1] (login-1-300.redback.com [155.53.12.153]) by prattle.redback.com (Postfix) with ESMTP id 641462EC7D9 for ; Fri, 1 Dec 2006 09:15:38 -0800 (PST) Message-ID: <45706339.3000409@redback.com> Date: Fri, 01 Dec 2006 09:15:37 -0800 From: Jakob Heitz User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: ancp@ietf.org Subject: Re: [ANCP] Protocol version nummer for ANCP References: <6439282641581441A36F7F6F83ED2ED2C45813@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <6439282641581441A36F7F6F83ED2ED2C45813@S4DE8PSAAFQ.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-Mailman-Approved-At: Fri, 01 Dec 2006 12:28:14 -0500 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org The first byte of every message is Vers.Sub. Use of this is a much simpler solution to this problem. KISS Busser, M wrote: > Hi all. > > > Problem: > Currently different codes exist referring to > draft-wadhwa-gsmp-l2control-configuration-00 & > draft-wadhwa-gsmp-l2control-configuration-02. > > The lack of having different codes in different network elements is to > create a situation of non interoperable TLV because TLV changed (e.g. > 90/91) > > Solution: > The only way out is to define a protocol version field in combination > with a software management in the network element: > > A proposal is shown below: > > We should have a format like version number, where main as > well as sub is represented by a 1 byte value. > We should start with 0.1 representing > draft-wadhwa-gsmp-l2control-configuration-02. > > Procedures > Add a new Capability: Version Length=4 > Byte 0 = Main Version Nr of > oldest supported protocol version > Byte 1 = Sub Version Nr of > oldest supported protocol version > Byte 2 = Main Version Nr of > latest supported protocol version > Byte 3 = Sub Version Nr of > latest supported protocol version > > If only one specific version is supported by a network element, the > oldest and the latest version number are the same. > > Requirement: > > To define a protocol version TLV first before enhancing > draft-wadhwa-gsmp-l2control-configuration-02 in further steps. > > > > Best regards > > Thomas & Michael > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www1.ietf.org/mailman/listinfo/ancp > -- Jakob Heitz _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Dec 01 15:51:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqFM5-00060X-Sn; Fri, 01 Dec 2006 15:51:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqFM4-00060S-Lu for ancp@ietf.org; Fri, 01 Dec 2006 15:51:32 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqFM3-0005rZ-73 for ancp@ietf.org; Fri, 01 Dec 2006 15:51:32 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Fri, 1 Dec 2006 21:51:29 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 21:51:29 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Subject: AW: [ANCP] Protocol version nummer for ANCP Date: Fri, 1 Dec 2006 21:54:09 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2016DF0A1@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <3C292CE901FC634693F24FB2DDC4D332024A5FD2@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Protocol version nummer for ANCP Thread-Index: AccVQum3qm4RL8oMQHKZQvU2NrY2ugAGrinQAAq+eSA= From: "Haag, T" To: X-OriginalArrivalTime: 01 Dec 2006 20:51:29.0100 (UTC) FILETIME=[797920C0:01C7158A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: "Hamacher, Peter" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Steve, all, That's the big difference between theory and practice. Best practice to get running a new protocol is to implement first code = check and improve it. But to manage the improvement a version = negotiation can not be avoided because of already existing code which is = not only present in a laboratory.=20 To set all systems in the field to a new code seems a little bit = different to update thousands of access nodes and related BNGs at the = same time. I've never seen this running outside in the field.=20 Again, I highly recommend thinking about. May be in the past this was = not accepted, but the future is now. From a operator standpoint the = business is too fast to wait until a draft has become a RFC is = finalized.=20 You can not from a vendor standpoint imagine a better acceptance of a = protocol running in an environment of thousands of network elements. But = the way to reach this needs a kind of version management! Regards Thomas=20 -----Urspr=FCngliche Nachricht----- Von: Steve Senum (ssenum) [mailto:ssenum@cisco.com]=20 Gesendet: Freitag, 1. Dezember 2006 16:53 An: Busser, Michael Cc: ancp@ietf.org Betreff: RE: [ANCP] Protocol version nummer for ANCP Hi, This should be avoided if at all possible. You are adding complexity into the protocol and implementations to deal with issues between drafts, which will need to be carried forwarded when this becomes a RFC. I have not seen an Internet Area Director support this in past instances. You can't even reference an internet-draft in an RFC. The other ways I have seen this dealt with in the past, somewhat in order of preference: 1. Clean cutover approach, all system roll to a new version. 2. Add checks in the code to deal with known cases. 3. Add a version setting to the config to handle this. Regards, Steve Senum > =20 >=20 > -----Original Message----- > From: Busser, M [mailto:Michael.Busser@t-systems.com]=20 > Sent: Friday, December 01, 2006 6:19 AM > To: ancp@ietf.org > Subject: [ANCP] Protocol version nummer for ANCP >=20 > Hi all. >=20 > =20 > Problem: > Currently different codes exist referring to=20 > draft-wadhwa-gsmp-l2control-configuration-00 &=20 > draft-wadhwa-gsmp-l2control-configuration-02. > =20 > The lack of having different codes in different network elements is to > create a situation of non interoperable TLV because TLV changed (e.g. > 90/91) > =20 > Solution: > The only way out is to define a protocol version field in combination > with a software management in the network element: > =20 > A proposal is shown below: > =20 > We should have a format like version number, where main as > well as sub is represented by a 1 byte value.=20 > We should start with 0.1 representing > draft-wadhwa-gsmp-l2control-configuration-02. > =20 > Procedures > Add a new Capability: Version Length=3D4 > Byte 0 =3D Main Version Nr of > oldest supported protocol version > Byte 1 =3D Sub Version Nr of > oldest supported protocol version > Byte 2 =3D Main Version Nr of > latest supported protocol version > Byte 3 =3D Sub Version Nr of > latest supported protocol version > =20 > If only one specific version is supported by a network element, the=20 > oldest and the latest version number are the same. > =20 > Requirement: > =20 > To define a protocol version TLV first before enhancing=20 > draft-wadhwa-gsmp-l2control-configuration-02 in further steps. > =20 > =20 > =20 > Best regards > =20 > Thomas & Michael >=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 Fri Dec 01 18:01:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqHNE-0001kh-B1; Fri, 01 Dec 2006 18:00:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqHND-0001kZ-9C for ancp@ietf.org; Fri, 01 Dec 2006 18:00:51 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqHNB-0000Il-Pe for ancp@ietf.org; Fri, 01 Dec 2006 18:00:51 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 01 Dec 2006 15:00:48 -0800 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB1N0mXF019102; Fri, 1 Dec 2006 18:00:48 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kB1N0kDm012548; Fri, 1 Dec 2006 18:00:48 -0500 (EST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 18:00:46 -0500 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] Protocol version nummer for ANCP Date: Fri, 1 Dec 2006 18:00:44 -0500 Message-ID: <3C292CE901FC634693F24FB2DDC4D332024A6243@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Protocol version nummer for ANCP Thread-Index: AccVQum3qm4RL8oMQHKZQvU2NrY2ugAGrinQAAq+eSAABIL40A== From: "Steve Senum \(ssenum\)" To: "Haag, T" X-OriginalArrivalTime: 01 Dec 2006 23:00:46.0415 (UTC) FILETIME=[893175F0:01C7159C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4667; t=1165014048; x=1165878048; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ssenum@cisco.com; z=From:=20=22Steve=20Senum=20\(ssenum\)=22=20 |Subject:=20RE=3A=20[ANCP]=20Protocol=20version=20nummer=20for=20ANCP |Sender:=20 |To:=20=22Haag,=20T=22=20; bh=5tzcAOzz/vyVWZQp2rzp2I1X565Vdx4myPXxwWYqX4c=; b=yseWMsKcIWRXzwkvAlkS8ZwOU6n/XbFR1e4PPYNaH63/aIn2bh3phaY3VvK69zCajVSm/23d SNsax0KS4sV7ATTmpSbx6LsKKmPnllwjBKz5hvRr+kfXNULawm0Qp+bw; Authentication-Results: rtp-dkim-2; header.From=ssenum@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: "Hamacher, Peter" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Thomas, Haag, T [mailto:Thomas.Haag@t-systems.com] wrote: >=20 > Steve, all, >=20 > That's the big difference between theory and practice. >=20 > Best practice to get running a new protocol is to implement first code = check and improve it. But to manage the improvement a version = negotiation can not be avoided because of already existing code which is = not only present in a laboratory.=20 >=20 > To set all systems in the field to a new code seems a little bit = different to update thousands of access nodes and related BNGs at the = same time. I've never seen this running outside in the field.=20 >=20 > Again, I highly recommend thinking about. May be in the past this was = not accepted, but the future is now. From a operator standpoint the = business is too fast to wait until a draft has become a RFC is = finalized.=20 This problem is nothing new, and has probably been an issue with almost every major protocol deployed. >=20 > You can not from a vendor standpoint imagine a better acceptance of a = protocol running in an environment of thousands of network elements. But = the way to reach this needs a kind of version management! The way to reach acceptance is by a tightly written spec and rigorous testing. The spec already uses TLVs, that should be sufficient as long as it doesn't reuse type values. Adding a version mechanism adds complexity, and can lead to future interoperability issues. Regards, Steve Senum >=20 > Regards >=20 > Thomas=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Steve Senum (ssenum) [mailto:ssenum@cisco.com]=20 > Gesendet: Freitag, 1. Dezember 2006 16:53 > An: Busser, Michael > Cc: ancp@ietf.org > Betreff: RE: [ANCP] Protocol version nummer for ANCP >=20 > Hi, >=20 > This should be avoided if at all possible. >=20 > You are adding complexity into the protocol and > implementations to deal with issues between drafts, > which will need to be carried forwarded when this > becomes a RFC. I have not seen an Internet Area > Director support this in past instances. You can't > even reference an internet-draft in an RFC. >=20 > The other ways I have seen this dealt with in the past, > somewhat in order of preference: >=20 > 1. Clean cutover approach, all system roll to a new > version. >=20 > 2. Add checks in the code to deal with known cases. >=20 > 3. Add a version setting to the config to handle this. >=20 > Regards, > Steve Senum >=20 > > =20 > >=20 > > -----Original Message----- > > From: Busser, M [mailto:Michael.Busser@t-systems.com]=20 > > Sent: Friday, December 01, 2006 6:19 AM > > To: ancp@ietf.org > > Subject: [ANCP] Protocol version nummer for ANCP > >=20 > > Hi all. > >=20 > > =20 > > Problem: > > Currently different codes exist referring to=20 > > draft-wadhwa-gsmp-l2control-configuration-00 &=20 > > draft-wadhwa-gsmp-l2control-configuration-02. > > =20 > > The lack of having different codes in different network elements is > to > > create a situation of non interoperable TLV because TLV changed = (e.g. > > 90/91) > > =20 > > Solution: > > The only way out is to define a protocol version field in = combination > > with a software management in the network element: > > =20 > > A proposal is shown below: > > =20 > > We should have a format like version number, where main = as > > well as sub is represented by a 1 byte value.=20 > > We should start with 0.1 representing > > draft-wadhwa-gsmp-l2control-configuration-02. > > =20 > > Procedures > > Add a new Capability: Version Length=3D4 > > Byte 0 =3D Main Version Nr of > > oldest supported protocol version > > Byte 1 =3D Sub Version Nr of > > oldest supported protocol version > > Byte 2 =3D Main Version Nr of > > latest supported protocol version > > Byte 3 =3D Sub Version Nr of > > latest supported protocol version > > =20 > > If only one specific version is supported by a network element, the = > > oldest and the latest version number are the same. > > =20 > > Requirement: > > =20 > > To define a protocol version TLV first before enhancing=20 > > draft-wadhwa-gsmp-l2control-configuration-02 in further steps. > > =20 > > =20 > > =20 > > Best regards > > =20 > > Thomas & Michael > >=20 > > _______________________________________________ > > ANCP mailing list > > ANCP@ietf.org > > https://www1.ietf.org/mailman/listinfo/ancp > >=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 From ancp-bounces@ietf.org Sat Dec 02 18:51:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqedY-0005Xb-4i; Sat, 02 Dec 2006 18:51:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqedX-0005XW-3N for ancp@ietf.org; Sat, 02 Dec 2006 18:51:15 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqedW-0003E8-JF for ancp@ietf.org; Sat, 02 Dec 2006 18:51:15 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id D393E5B3C0; Sat, 2 Dec 2006 15:51:13 -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 27963-02; Sat, 2 Dec 2006 15:51:13 -0800 (PST) Received: from PARBETM2XP2 (unknown [172.31.253.224]) by prattle.redback.com (Postfix) with ESMTP id 5D7B85B3BF; Sat, 2 Dec 2006 15:51:12 -0800 (PST) From: "Peter Arberg" To: "'Steve Senum (ssenum)'" , "'Haag, T'" Subject: RE: [ANCP] Protocol version nummer for ANCP Date: Sun, 3 Dec 2006 00:51:26 +0100 Organization: Redback Networks Inc. Message-ID: <001101c7166c$c9125790$ba3dfea9@ad.redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccVQum3qm4RL8oMQHKZQvU2NrY2ugAGrinQAAq+eSAABIL40AA0W5Ag In-Reply-To: <3C292CE901FC634693F24FB2DDC4D332024A6243@xmb-rtp-20d.amer.cisco.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: "'Hamacher, Peter'" , ancp@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi, I agree that the version control is a functionality we need=20 to add to the ANCP protocol. But I do not think we have to ADD it, I just think we have to start using it, as we alreday have a version.sub-version field=20 in the GSMP header, so I will suggest we decide to use this=20 for the ANCP usage as well. We could say ANCP is not backward compatible with GSMP,=20 but are defining all GSMP related informations we are using,=20 and as such we could reuse the GSMP version and subversion=20 number as a ANCP version control instead of keeping this on 3.1. So a decision to increase this version number starting with draft-2 will make sure that the attribute changes are recorded, and we have a version number which clearly will show that we are using ANCP functionality, and not GSMP 3.1 defined functionality. cheers, Peter=20 > -----Original Message----- > From: Steve Senum (ssenum) [mailto:ssenum@cisco.com]=20 > Sent: 2. december 2006 00:01 > To: Haag, T > Cc: Hamacher, Peter; ancp@ietf.org > Subject: RE: [ANCP] Protocol version nummer for ANCP >=20 > Hi Thomas, >=20 > Haag, T [mailto:Thomas.Haag@t-systems.com] wrote: > >=20 > > Steve, all, > >=20 > > That's the big difference between theory and practice. > >=20 > > Best practice to get running a new protocol is to implement=20 > first code check and improve it. But to manage the=20 > improvement a version negotiation can not be avoided because=20 > of already existing code which is not only present in a laboratory.=20 > >=20 > > To set all systems in the field to a new code seems a=20 > little bit different to update thousands of access nodes and=20 > related BNGs at the same time. I've never seen this running=20 > outside in the field.=20 > >=20 > > Again, I highly recommend thinking about. May be in the=20 > past this was not accepted, but the future is now. From a=20 > operator standpoint the business is too fast to wait until a=20 > draft has become a RFC is finalized.=20 >=20 > This problem is nothing new, and has probably been an issue with > almost every major protocol deployed. >=20 > >=20 > > You can not from a vendor standpoint imagine a better=20 > acceptance of a protocol running in an environment of=20 > thousands of network elements. But the way to reach this=20 > needs a kind of version management! >=20 > The way to reach acceptance is by a tightly written spec and > rigorous testing. >=20 > The spec already uses TLVs, that should be sufficient as long > as it doesn't reuse type values. >=20 > Adding a version mechanism adds complexity, and can lead to > future interoperability issues. >=20 > Regards, > Steve Senum >=20 > >=20 > > Regards > >=20 > > Thomas=20 > >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Steve Senum (ssenum) [mailto:ssenum@cisco.com]=20 > > Gesendet: Freitag, 1. Dezember 2006 16:53 > > An: Busser, Michael > > Cc: ancp@ietf.org > > Betreff: RE: [ANCP] Protocol version nummer for ANCP > >=20 > > Hi, > >=20 > > This should be avoided if at all possible. > >=20 > > You are adding complexity into the protocol and > > implementations to deal with issues between drafts, > > which will need to be carried forwarded when this > > becomes a RFC. I have not seen an Internet Area > > Director support this in past instances. You can't > > even reference an internet-draft in an RFC. > >=20 > > The other ways I have seen this dealt with in the past, > > somewhat in order of preference: > >=20 > > 1. Clean cutover approach, all system roll to a new > > version. > >=20 > > 2. Add checks in the code to deal with known cases. > >=20 > > 3. Add a version setting to the config to handle this. > >=20 > > Regards, > > Steve Senum > >=20 > > > =20 > > >=20 > > > -----Original Message----- > > > From: Busser, M [mailto:Michael.Busser@t-systems.com]=20 > > > Sent: Friday, December 01, 2006 6:19 AM > > > To: ancp@ietf.org > > > Subject: [ANCP] Protocol version nummer for ANCP > > >=20 > > > Hi all. > > >=20 > > > =20 > > > Problem: > > > Currently different codes exist referring to=20 > > > draft-wadhwa-gsmp-l2control-configuration-00 &=20 > > > draft-wadhwa-gsmp-l2control-configuration-02. > > > =20 > > > The lack of having different codes in different network=20 > elements is > > to > > > create a situation of non interoperable TLV because TLV=20 > changed (e.g. > > > 90/91) > > > =20 > > > Solution: > > > The only way out is to define a protocol version field=20 > in combination > > > with a software management in the network element: > > > =20 > > > A proposal is shown below: > > > =20 > > > We should have a format like version number,=20 > where main as > > > well as sub is represented by a 1 byte value.=20 > > > We should start with 0.1 representing > > > draft-wadhwa-gsmp-l2control-configuration-02. > > > =20 > > > Procedures > > > Add a new Capability: Version Length=3D4 > > > Byte 0 =3D Main Version Nr of > > > oldest supported protocol version > > > Byte 1 =3D Sub Version Nr of > > > oldest supported protocol version > > > Byte 2 =3D Main Version Nr of > > > latest supported protocol version > > > Byte 3 =3D Sub Version Nr of > > > latest supported protocol version > > > =20 > > > If only one specific version is supported by a network=20 > element, the=20 > > > oldest and the latest version number are the same. > > > =20 > > > Requirement: > > > =20 > > > To define a protocol version TLV first before enhancing=20 > > > draft-wadhwa-gsmp-l2control-configuration-02 in further steps. > > > =20 > > > =20 > > > =20 > > > Best regards > > > =20 > > > Thomas & Michael > > >=20 > > > _______________________________________________ > > > ANCP mailing list > > > ANCP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ancp > > >=20 > >=20 > > _______________________________________________ > > ANCP mailing list > > ANCP@ietf.org > > https://www1.ietf.org/mailman/listinfo/ancp > >=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 From ancp-bounces@ietf.org Mon Dec 04 01:22:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr7Dl-0003Vm-4u; Mon, 04 Dec 2006 01:22:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr7Dj-0003T5-Tc for ancp@ietf.org; Mon, 04 Dec 2006 01:22:31 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gr7Dd-0000Te-2o for ancp@ietf.org; Mon, 04 Dec 2006 01:22:31 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 40BFD74A; Mon, 4 Dec 2006 07:22:20 +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, 4 Dec 2006 07:22:20 +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: RE: [ANCP] Protocol version nummer for ANCP Date: Mon, 4 Dec 2006 07:22:18 +0100 Message-ID: <2DEB3E4E9BC3774B8EEF2EF2BE9F745B88B6FA@esealmw104.eemea.ericsson.se> In-Reply-To: <001101c7166c$c9125790$ba3dfea9@ad.redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Protocol version nummer for ANCP Thread-Index: AccVQum3qm4RL8oMQHKZQvU2NrY2ugAGrinQAAq+eSAABIL40AA0W5AgAD/b8VA= From: "Kim Hyldgaard \(ST/LMD\)" To: , "Steve Senum \(ssenum\)" , "Haag, T" X-OriginalArrivalTime: 04 Dec 2006 06:22:20.0026 (UTC) FILETIME=[8D712DA0:01C7176C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Cc: "Hamacher, Peter" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi, I agree with Peter on this matter. Version control is needed even though we're still at the draft stage, however I'd also appreciate a simple approach. Is there a risk that we'll run into problems later if we use the version field from GSMP directly? If "We could say ANCP is not backward compatible with GSMP, but are defining all GSMP related informations we are using" is a valid statement, it should be OK to use the GSMP version field. Br Kim -----Original Message----- From: Peter Arberg [mailto:parberg@redback.com]=20 Sent: 3. december 2006 00:51 To: 'Steve Senum (ssenum)'; 'Haag, T' Cc: 'Hamacher, Peter'; ancp@ietf.org Subject: RE: [ANCP] Protocol version nummer for ANCP Hi, I agree that the version control is a functionality we need to add to = the ANCP protocol. But I do not think we have to ADD it, I just think we have to start = using it, as we alreday have a version.sub-version field in the GSMP = header, so I will suggest we decide to use this for the ANCP usage as = well. We could say ANCP is not backward compatible with GSMP, but are defining = all GSMP related informations we are using, and as such we could reuse = the GSMP version and subversion number as a ANCP version control instead = of keeping this on 3.1. So a decision to increase this version number starting with draft-2 will = make sure that the attribute changes are recorded, and we have a version = number which clearly will show that we are using ANCP functionality, and = not GSMP 3.1 defined functionality. cheers, Peter=20 > -----Original Message----- > From: Steve Senum (ssenum) [mailto:ssenum@cisco.com] > Sent: 2. december 2006 00:01 > To: Haag, T > Cc: Hamacher, Peter; ancp@ietf.org > Subject: RE: [ANCP] Protocol version nummer for ANCP >=20 > Hi Thomas, >=20 > Haag, T [mailto:Thomas.Haag@t-systems.com] wrote: > >=20 > > Steve, all, > >=20 > > That's the big difference between theory and practice. > >=20 > > Best practice to get running a new protocol is to implement > first code check and improve it. But to manage the improvement a=20 > version negotiation can not be avoided because of already existing=20 > code which is not only present in a laboratory. > >=20 > > To set all systems in the field to a new code seems a > little bit different to update thousands of access nodes and related=20 > BNGs at the same time. I've never seen this running outside in the=20 > field. > >=20 > > Again, I highly recommend thinking about. May be in the > past this was not accepted, but the future is now. From a operator=20 > standpoint the business is too fast to wait until a draft has become a = > RFC is finalized. >=20 > This problem is nothing new, and has probably been an issue with=20 > almost every major protocol deployed. >=20 > >=20 > > You can not from a vendor standpoint imagine a better > acceptance of a protocol running in an environment of thousands of=20 > network elements. But the way to reach this needs a kind of version=20 > management! >=20 > The way to reach acceptance is by a tightly written spec and rigorous=20 > testing. >=20 > The spec already uses TLVs, that should be sufficient as long as it=20 > doesn't reuse type values. >=20 > Adding a version mechanism adds complexity, and can lead to future=20 > interoperability issues. >=20 > Regards, > Steve Senum >=20 > >=20 > > Regards > >=20 > > Thomas > >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Steve Senum (ssenum) [mailto:ssenum@cisco.com] > > Gesendet: Freitag, 1. Dezember 2006 16:53 > > An: Busser, Michael > > Cc: ancp@ietf.org > > Betreff: RE: [ANCP] Protocol version nummer for ANCP > >=20 > > Hi, > >=20 > > This should be avoided if at all possible. > >=20 > > You are adding complexity into the protocol and implementations to=20 > > deal with issues between drafts, which will need to be carried=20 > > forwarded when this becomes a RFC. I have not seen an Internet Area = > > Director support this in past instances. You can't even reference=20 > > an internet-draft in an RFC. > >=20 > > The other ways I have seen this dealt with in the past, somewhat in=20 > > order of preference: > >=20 > > 1. Clean cutover approach, all system roll to a new > > version. > >=20 > > 2. Add checks in the code to deal with known cases. > >=20 > > 3. Add a version setting to the config to handle this. > >=20 > > Regards, > > Steve Senum > >=20 > > > =20 > > >=20 > > > -----Original Message----- > > > From: Busser, M [mailto:Michael.Busser@t-systems.com] > > > Sent: Friday, December 01, 2006 6:19 AM > > > To: ancp@ietf.org > > > Subject: [ANCP] Protocol version nummer for ANCP > > >=20 > > > Hi all. > > >=20 > > > =20 > > > Problem: > > > Currently different codes exist referring to=20 > > > draft-wadhwa-gsmp-l2control-configuration-00 &=20 > > > draft-wadhwa-gsmp-l2control-configuration-02. > > > =20 > > > The lack of having different codes in different network > elements is > > to > > > create a situation of non interoperable TLV because TLV > changed (e.g. > > > 90/91) > > > =20 > > > Solution: > > > The only way out is to define a protocol version field > in combination > > > with a software management in the network element: > > > =20 > > > A proposal is shown below: > > > =20 > > > We should have a format like version number, > where main as > > > well as sub is represented by a 1 byte value.=20 > > > We should start with 0.1 representing=20 > > > draft-wadhwa-gsmp-l2control-configuration-02. > > > =20 > > > Procedures > > > Add a new Capability: Version Length=3D4 > > > Byte 0 =3D Main Version Nr of > > > oldest supported protocol version > > > Byte 1 =3D Sub Version Nr of > > > oldest supported protocol version > > > Byte 2 =3D Main Version Nr of > > > latest supported protocol version > > > Byte 3 =3D Sub Version Nr of > > > latest supported protocol version > > > =20 > > > If only one specific version is supported by a network > element, the > > > oldest and the latest version number are the same. > > > =20 > > > Requirement: > > > =20 > > > To define a protocol version TLV first before enhancing > > > draft-wadhwa-gsmp-l2control-configuration-02 in further steps. > > > =20 > > > =20 > > > =20 > > > Best regards > > > =20 > > > Thomas & Michael > > >=20 > > > _______________________________________________ > > > ANCP mailing list > > > ANCP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ancp > > >=20 > >=20 > > _______________________________________________ > > ANCP mailing list > > ANCP@ietf.org > > https://www1.ietf.org/mailman/listinfo/ancp > >=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 Mon Dec 04 02:59:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr8jO-000319-0w; Mon, 04 Dec 2006 02:59:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr7hH-00023A-5U for ancp@ietf.org; Mon, 04 Dec 2006 01:53:03 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gr7hF-0003tr-Ke for ancp@ietf.org; Mon, 04 Dec 2006 01:53:03 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 216ECBD6B8E for ; Sun, 3 Dec 2006 22:52:59 -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 28524-05 for ; Sun, 3 Dec 2006 22:52:59 -0800 (PST) Received: from [127.0.0.1] (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id A9BA9BD6B8C for ; Sun, 3 Dec 2006 22:52:58 -0800 (PST) Message-ID: <4573C5C9.7080807@redback.com> Date: Sun, 03 Dec 2006 22:52:57 -0800 From: Jakob Heitz User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: ancp@ietf.org Subject: Re: [ANCP] Protocol version nummer for ANCP References: <2DEB3E4E9BC3774B8EEF2EF2BE9F745B88B6FA@esealmw104.eemea.ericsson.se> In-Reply-To: <2DEB3E4E9BC3774B8EEF2EF2BE9F745B88B6FA@esealmw104.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-new at redback.com Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 X-Mailman-Approved-At: Mon, 04 Dec 2006 02:59:16 -0500 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org To add to this position: A new protocol version should be a rare requirement. We can add new TLVs without having to increment the protocol version. We can even change a TLV without incrementing the protocol version. We can change a TLV, by using a new type number for the changed TLV. That would not require a new protocol version. The only thing that would require a new protocol version is changes to the protocol itself, ie. how the protocol works. An example of such a change would be a multi timer keepalive: Slow keepalive timer until we miss one. After a keepalive is lost, switch to a quick timer. If an ack is received, switch back to the slow timer. Such a change would require a new protocol version. Regards, Jakob Heitz Kim Hyldgaard (ST/LMD) wrote: > Hi, > > I agree with Peter on this matter. > > Version control is needed even though we're still at the draft > stage, however I'd also appreciate a simple approach. > > Is there a risk that we'll run into problems later if > we use the version field from GSMP directly? > > If "We could say ANCP is not backward compatible with GSMP, > but are defining all GSMP related informations we are using" > is a valid statement, it should be OK to use the GSMP version field. > > Br > Kim > > > -----Original Message----- > From: Peter Arberg [mailto:parberg@redback.com]=20 > Sent: 3. december 2006 00:51 > To: 'Steve Senum (ssenum)'; 'Haag, T' > Cc: 'Hamacher, Peter'; ancp@ietf.org > Subject: RE: [ANCP] Protocol version nummer for ANCP > > Hi, > > I agree that the version control is a functionality we need to add to t= he ANCP protocol. > > But I do not think we have to ADD it, I just think we have to start usi= ng it, as we alreday have a version.sub-version field in the GSMP header,= so I will suggest we decide to use this for the ANCP usage as well. > > We could say ANCP is not backward compatible with GSMP, but are definin= g all GSMP related informations we are using, and as such we could reuse = the GSMP version and subversion number as a ANCP version control instead = of keeping this on 3.1. > > So a decision to increase this version number starting with draft-2 wil= l make sure that the attribute changes are recorded, and we have a versio= n number which clearly will show that we are using ANCP functionality, an= d not GSMP 3.1 defined functionality. > > cheers, > Peter=20 > >> -----Original Message----- >> From: Steve Senum (ssenum) [mailto:ssenum@cisco.com] >> Sent: 2. december 2006 00:01 >> To: Haag, T >> Cc: Hamacher, Peter; ancp@ietf.org >> Subject: RE: [ANCP] Protocol version nummer for ANCP >> >> Hi Thomas, >> >> Haag, T [mailto:Thomas.Haag@t-systems.com] wrote: >>> Steve, all, >>> >>> That's the big difference between theory and practice. >>> >>> Best practice to get running a new protocol is to implement >> first code check and improve it. But to manage the improvement a=20 >> version negotiation can not be avoided because of already existing=20 >> code which is not only present in a laboratory. >>> To set all systems in the field to a new code seems a >> little bit different to update thousands of access nodes and related=20 >> BNGs at the same time. I've never seen this running outside in the=20 >> field. >>> Again, I highly recommend thinking about. May be in the >> past this was not accepted, but the future is now. From a operator=20 >> standpoint the business is too fast to wait until a draft has become a= =20 >> RFC is finalized. >> >> This problem is nothing new, and has probably been an issue with=20 >> almost every major protocol deployed. >> >>> You can not from a vendor standpoint imagine a better >> acceptance of a protocol running in an environment of thousands of=20 >> network elements. But the way to reach this needs a kind of version=20 >> management! >> >> The way to reach acceptance is by a tightly written spec and rigorous=20 >> testing. >> >> The spec already uses TLVs, that should be sufficient as long as it=20 >> doesn't reuse type values. >> >> Adding a version mechanism adds complexity, and can lead to future=20 >> interoperability issues. >> >> Regards, >> Steve Senum >> >>> Regards >>> >>> Thomas >>> >>> -----Urspr=FCngliche Nachricht----- >>> Von: Steve Senum (ssenum) [mailto:ssenum@cisco.com] >>> Gesendet: Freitag, 1. Dezember 2006 16:53 >>> An: Busser, Michael >>> Cc: ancp@ietf.org >>> Betreff: RE: [ANCP] Protocol version nummer for ANCP >>> >>> Hi, >>> >>> This should be avoided if at all possible. >>> >>> You are adding complexity into the protocol and implementations to=20 >>> deal with issues between drafts, which will need to be carried=20 >>> forwarded when this becomes a RFC. I have not seen an Internet Area=20 >>> Director support this in past instances. You can't even reference=20 >>> an internet-draft in an RFC. >>> >>> The other ways I have seen this dealt with in the past, somewhat in=20 >>> order of preference: >>> >>> 1. Clean cutover approach, all system roll to a new >>> version. >>> >>> 2. Add checks in the code to deal with known cases. >>> >>> 3. Add a version setting to the config to handle this. >>> >>> Regards, >>> Steve Senum >>> >>>> =20 >>>> >>>> -----Original Message----- >>>> From: Busser, M [mailto:Michael.Busser@t-systems.com] >>>> Sent: Friday, December 01, 2006 6:19 AM >>>> To: ancp@ietf.org >>>> Subject: [ANCP] Protocol version nummer for ANCP >>>> >>>> Hi all. >>>> >>>> =20 >>>> Problem: >>>> Currently different codes exist referring to=20 >>>> draft-wadhwa-gsmp-l2control-configuration-00 &=20 >>>> draft-wadhwa-gsmp-l2control-configuration-02. >>>> =20 >>>> The lack of having different codes in different network >> elements is >>> to >>>> create a situation of non interoperable TLV because TLV >> changed (e.g. >>>> 90/91) >>>> =20 >>>> Solution: >>>> The only way out is to define a protocol version field >> in combination >>>> with a software management in the network element: >>>> =20 >>>> A proposal is shown below: >>>> =20 >>>> We should have a format like version number, >> where main as >>>> well as sub is represented by a 1 byte value.=20 >>>> We should start with 0.1 representing=20 >>>> draft-wadhwa-gsmp-l2control-configuration-02. >>>> =20 >>>> Procedures >>>> Add a new Capability: Version Length=3D4 >>>> Byte 0 =3D Main Version Nr of >>>> oldest supported protocol version >>>> Byte 1 =3D Sub Version Nr of >>>> oldest supported protocol version >>>> Byte 2 =3D Main Version Nr of >>>> latest supported protocol version >>>> Byte 3 =3D Sub Version Nr of >>>> latest supported protocol version >>>> =20 >>>> If only one specific version is supported by a network >> element, the >>>> oldest and the latest version number are the same. >>>> =20 >>>> Requirement: >>>> =20 >>>> To define a protocol version TLV first before enhancing >>>> draft-wadhwa-gsmp-l2control-configuration-02 in further steps. >>>> =20 >>>> =20 >>>> =20 >>>> Best regards >>>> =20 >>>> Thomas & Michael _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Dec 04 07:02:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrCWR-00035b-6X; Mon, 04 Dec 2006 07:02:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrC8Q-0000qT-TT for ancp@ietf.org; Mon, 04 Dec 2006 06:37:22 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrC8P-0000qx-EE for ancp@ietf.org; Mon, 04 Dec 2006 06:37:22 -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 kB4BbP7i017588 for ; Mon, 4 Dec 2006 12:37:25 +0100 Received: from [172.31.131.218] ([172.31.131.218]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163) with ESMTP id 2006120412371852:3136 ; Mon, 4 Dec 2006 12:37:18 +0100 Message-ID: <4574086E.5020407@alcatel-lucent.be> Date: Mon, 04 Dec 2006 12:37:18 +0100 From: Stefaan De Cnodder 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] Protocol version nummer for ANCP References: <6439282641581441A36F7F6F83ED2ED2C45813@S4DE8PSAAFQ.mitte.t-com.de> <45706339.3000409@redback.com> In-Reply-To: <45706339.3000409@redback.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 12/04/2006 12:37:18, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 12/04/2006 12:37:20, Serialize complete at 12/04/2006 12:37:20 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.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a X-Mailman-Approved-At: Mon, 04 Dec 2006 07:02:09 -0500 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Indeed, making use of the version in the header is much simpler, and is something that is already there, no need to invent something new. But the version/subversion number should not be incremented with every new version of the draft.... How would this then being handled? A draft and later an RFC per version? I hope this is not what we intend to do.... if you have a lot of versions it will be harder to find a BRAS and a DSLAM that supports the same version. regards, Stefaan Jakob Heitz wrote: > The first byte of every message is Vers.Sub. > Use of this is a much simpler solution to this problem. > KISS > > Busser, M wrote: > >> Hi all. >> >> >> Problem: >> Currently different codes exist referring to >> draft-wadhwa-gsmp-l2control-configuration-00 & >> draft-wadhwa-gsmp-l2control-configuration-02. >> >> The lack of having different codes in different network elements is to >> create a situation of non interoperable TLV because TLV changed (e.g. >> 90/91) >> >> Solution: >> The only way out is to define a protocol version field in combination >> with a software management in the network element: >> >> A proposal is shown below: >> >> We should have a format like version number, where main as >> well as sub is represented by a 1 byte value. We should start with >> 0.1 representing >> draft-wadhwa-gsmp-l2control-configuration-02. >> >> Procedures >> Add a new Capability: Version Length=4 >> Byte 0 = Main Version Nr of >> oldest supported protocol version >> Byte 1 = Sub Version Nr of >> oldest supported protocol version >> Byte 2 = Main Version Nr of >> latest supported protocol version >> Byte 3 = Sub Version Nr of >> latest supported protocol version >> >> If only one specific version is supported by a network element, the >> oldest and the latest version number are the same. >> >> Requirement: >> >> To define a protocol version TLV first before enhancing >> draft-wadhwa-gsmp-l2control-configuration-02 in further steps. >> >> >> Best regards >> >> Thomas & Michael >> >> _______________________________________________ >> 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 Dec 04 11:01:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGFY-0004XE-Ag; Mon, 04 Dec 2006 11:01:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGFW-0004Wt-ON for ancp@ietf.org; Mon, 04 Dec 2006 11:00:58 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrGFV-0000hF-Aw for ancp@ietf.org; Mon, 04 Dec 2006 11:00:58 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id CE01F62D3EC for ; Mon, 4 Dec 2006 08:00: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 01176-09 for ; Mon, 4 Dec 2006 08:00:56 -0800 (PST) Received: from [127.0.0.1] (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 4A86162D3EB for ; Mon, 4 Dec 2006 08:00:56 -0800 (PST) Message-ID: <45744638.8080109@redback.com> Date: Mon, 04 Dec 2006 08:00:56 -0800 From: Jakob Heitz User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: ancp@ietf.org Subject: Re: [ANCP] Protocol version nummer for ANCP References: <6439282641581441A36F7F6F83ED2ED2C45813@S4DE8PSAAFQ.mitte.t-com.de> <45706339.3000409@redback.com> <4574086E.5020407@alcatel-lucent.be> In-Reply-To: <4574086E.5020407@alcatel-lucent.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org No problem. GSMP defines version negotiation: In the adjacency protocol the Version field is used for version negotiation. The version negotiation is performed before synchronisation is achieved. In a SYN message the Version field always contains the highest version understood by the sender. A receiver receiving a SYN message with a version higher than understood will ignore that message. A receiver receiving a SYN message with a version lower than its own highest version, but a version that it understands, will reply with a SYNACK with the version from the received SYN in its GSMP Version field. This defines the version of the GSMP protocol to be used while the adjacency protocol remains synchronised. All other messages will use the agreed version in the Version field. Every time the draft changes in a way that would cause errors if used with a previous draft, then the vers/sub should be incremented. Regards, Jakob Heitz. Stefaan De Cnodder wrote: > > Indeed, making use of the version in the header is much simpler, and > is something that is already there, no need to invent something new. > But the version/subversion number should not be incremented with every > new version of the draft.... How would this then being handled? A > draft and later an RFC per version? I hope this is not what we intend > to do.... if you have a lot of versions it will be harder to find a > BRAS and a DSLAM that supports the same version. > > regards, > Stefaan > > Jakob Heitz wrote: > >> The first byte of every message is Vers.Sub. >> Use of this is a much simpler solution to this problem. >> KISS >> >> Busser, M wrote: >> >>> Hi all. >>> >>> >>> Problem: >>> Currently different codes exist referring to >>> draft-wadhwa-gsmp-l2control-configuration-00 & >>> draft-wadhwa-gsmp-l2control-configuration-02. >>> >>> The lack of having different codes in different network elements is to >>> create a situation of non interoperable TLV because TLV changed (e.g. >>> 90/91) >>> >>> Solution: >>> The only way out is to define a protocol version field in combination >>> with a software management in the network element: >>> >>> A proposal is shown below: >>> >>> We should have a format like version number, where main as >>> well as sub is represented by a 1 byte value. We should start with >>> 0.1 representing >>> draft-wadhwa-gsmp-l2control-configuration-02. >>> >>> Procedures >>> Add a new Capability: Version Length=4 >>> Byte 0 = Main Version Nr of >>> oldest supported protocol version >>> Byte 1 = Sub Version Nr of >>> oldest supported protocol version >>> Byte 2 = Main Version Nr of >>> latest supported protocol version >>> Byte 3 = Sub Version Nr of >>> latest supported protocol version >>> >>> If only one specific version is supported by a network element, the >>> oldest and the latest version number are the same. >>> >>> Requirement: >>> >>> To define a protocol version TLV first before enhancing >>> draft-wadhwa-gsmp-l2control-configuration-02 in further steps. >>> >>> Best regards >>> >>> Thomas & Michael >>> >>> _______________________________________________ >>> 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 -- Jakob Heitz. x5475. 510-566-2901 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Dec 05 03:53:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrW34-0007O1-Fk; Tue, 05 Dec 2006 03:53:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrW33-0007Nj-KZ for ancp@ietf.org; Tue, 05 Dec 2006 03:53:09 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrW32-0005nY-4J for ancp@ietf.org; Tue, 05 Dec 2006 03:53:09 -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 kB58rB1T014654; Tue, 5 Dec 2006 09:53:11 +0100 Received: from [172.31.131.218] ([172.31.131.218]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163) with ESMTP id 2006120509530456:2152 ; Tue, 5 Dec 2006 09:53:04 +0100 Message-ID: <45753371.8080200@alcatel-lucent.be> Date: Tue, 05 Dec 2006 09:53:05 +0100 From: Stefaan De Cnodder 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: Jakob Heitz Subject: Re: [ANCP] Protocol version nummer for ANCP References: <6439282641581441A36F7F6F83ED2ED2C45813@S4DE8PSAAFQ.mitte.t-com.de> <45706339.3000409@redback.com> <4574086E.5020407@alcatel-lucent.be> <45744638.8080109@redback.com> In-Reply-To: <45744638.8080109@redback.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 12/05/2006 09:53:04, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 12/05/2006 09:53:06, Serialize complete at 12/05/2006 09:53:06 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.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Jakob, > > Every time the draft changes in a way that would cause > errors if used with a previous draft, then the vers/sub > should be incremented. > Do you also mean that the IETF has to standardize all these versions in one or more RFCs? regards, Stefaan > Regards, > Jakob Heitz. > > > > Stefaan De Cnodder wrote: > >> >> Indeed, making use of the version in the header is much simpler, and >> is something that is already there, no need to invent something new. >> But the version/subversion number should not be incremented with every >> new version of the draft.... How would this then being handled? A >> draft and later an RFC per version? I hope this is not what we intend >> to do.... if you have a lot of versions it will be harder to find a >> BRAS and a DSLAM that supports the same version. >> >> regards, >> Stefaan >> >> Jakob Heitz wrote: >> >>> The first byte of every message is Vers.Sub. >>> Use of this is a much simpler solution to this problem. >>> KISS >>> >>> Busser, M wrote: >>> >>>> Hi all. >>>> >>>> >>>> Problem: >>>> Currently different codes exist referring to >>>> draft-wadhwa-gsmp-l2control-configuration-00 & >>>> draft-wadhwa-gsmp-l2control-configuration-02. >>>> >>>> The lack of having different codes in different network elements is to >>>> create a situation of non interoperable TLV because TLV changed (e.g. >>>> 90/91) >>>> >>>> Solution: >>>> The only way out is to define a protocol version field in combination >>>> with a software management in the network element: >>>> >>>> A proposal is shown below: >>>> >>>> We should have a format like version number, where main as >>>> well as sub is represented by a 1 byte value. We should start with >>>> 0.1 representing >>>> draft-wadhwa-gsmp-l2control-configuration-02. >>>> >>>> Procedures >>>> Add a new Capability: Version Length=4 >>>> Byte 0 = Main Version Nr of >>>> oldest supported protocol version >>>> Byte 1 = Sub Version Nr of >>>> oldest supported protocol version >>>> Byte 2 = Main Version Nr of >>>> latest supported protocol version >>>> Byte 3 = Sub Version Nr of >>>> latest supported protocol version >>>> >>>> If only one specific version is supported by a network element, the >>>> oldest and the latest version number are the same. >>>> >>>> Requirement: >>>> >>>> To define a protocol version TLV first before enhancing >>>> draft-wadhwa-gsmp-l2control-configuration-02 in further steps. >>>> >>>> Best regards >>>> >>>> Thomas & Michael >>>> >>>> _______________________________________________ >>>> 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 Tue Dec 05 11:44:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrdOm-0003yz-Pn; Tue, 05 Dec 2006 11:44:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrdOk-0003yL-Vf for ancp@ietf.org; Tue, 05 Dec 2006 11:44:02 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrdOg-0005v2-Eq for ancp@ietf.org; Tue, 05 Dec 2006 11:44:02 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 0402C7A7831; Tue, 5 Dec 2006 08:43:58 -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 17200-09; Tue, 5 Dec 2006 08:43:57 -0800 (PST) Received: from PARBETM2XP2 (unknown [172.31.253.40]) by prattle.redback.com (Postfix) with ESMTP id 90F937A7830; Tue, 5 Dec 2006 08:43:57 -0800 (PST) From: "Peter Arberg" To: "'Stefaan De Cnodder'" , "'Jakob Heitz'" Subject: RE: [ANCP] Protocol version nummer for ANCP Date: Tue, 5 Dec 2006 08:44:37 -0800 Organization: Redback Networks Inc. Message-ID: <021c01c7188c$a72a8c20$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: AccYSt26N4nLpWW2TI2jdu6wM0rsJQAP6+BQ In-Reply-To: <45753371.8080200@alcatel-lucent.be> 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: cd3fc8e909678b38737fc606dec187f0 Cc: ancp@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Steefan, I would not expect IETF to standardize all possible version numbers in more than one RFC. I would expect the process with the draft to evolve to the RFC, and the version number in the last draft is the version number in the RFC defining ANCP, but at the same time the RFC should define the differences between new version numbers. So for example, let us say we increase version number to 4.0 for the draft 2, then a small section outlining the changes that required this version number increase would be required. We do not expect version number change with every draft, it will be, as Jakob said, a rare event and only needed if there is no other way of interoperability between systems implementing a new and an old draft. The problem with ANCP is we started the IETF process after several vendors have running code in production, and as such we need a way to make sure carriers can continue to run these networks while vendors improve their ANCP implementation. The version number is in my mind the best option to accomplish this, even if it means we will use a couple of numbers on our way to standardize the ANCP protocol. cheers, Peter > -----Original Message----- > From: Stefaan De Cnodder > [mailto:stefaan.de_cnodder@alcatel-lucent.be] > Sent: 5. december 2006 00:53 > To: Jakob Heitz > Cc: ancp@ietf.org > Subject: Re: [ANCP] Protocol version nummer for ANCP > > > Hi Jakob, > > > > > Every time the draft changes in a way that would cause > > errors if used with a previous draft, then the vers/sub > > should be incremented. > > > > Do you also mean that the IETF has to standardize all these > versions in > one or more RFCs? > > regards, > Stefaan > > > Regards, > > Jakob Heitz. > > > > > > > > Stefaan De Cnodder wrote: > > > >> > >> Indeed, making use of the version in the header is much > simpler, and > >> is something that is already there, no need to invent > something new. > >> But the version/subversion number should not be > incremented with every > >> new version of the draft.... How would this then being handled? A > >> draft and later an RFC per version? I hope this is not > what we intend > >> to do.... if you have a lot of versions it will be harder > to find a > >> BRAS and a DSLAM that supports the same version. > >> > >> regards, > >> Stefaan > >> > >> Jakob Heitz wrote: > >> > >>> The first byte of every message is Vers.Sub. > >>> Use of this is a much simpler solution to this problem. > >>> KISS > >>> > >>> Busser, M wrote: > >>> > >>>> Hi all. > >>>> > >>>> > >>>> Problem: > >>>> Currently different codes exist referring to > >>>> draft-wadhwa-gsmp-l2control-configuration-00 & > >>>> draft-wadhwa-gsmp-l2control-configuration-02. > >>>> > >>>> The lack of having different codes in different network > elements is to > >>>> create a situation of non interoperable TLV because TLV > changed (e.g. > >>>> 90/91) > >>>> > >>>> Solution: > >>>> The only way out is to define a protocol version field > in combination > >>>> with a software management in the network element: > >>>> > >>>> A proposal is shown below: > >>>> > >>>> We should have a format like version number, > where main as > >>>> well as sub is represented by a 1 byte value. We > should start with > >>>> 0.1 representing > >>>> draft-wadhwa-gsmp-l2control-configuration-02. > >>>> > >>>> Procedures > >>>> Add a new Capability: Version Length=4 > >>>> Byte 0 = Main Version Nr of > >>>> oldest supported protocol version > >>>> Byte 1 = Sub Version Nr of > >>>> oldest supported protocol version > >>>> Byte 2 = Main Version Nr of > >>>> latest supported protocol version > >>>> Byte 3 = Sub Version Nr of > >>>> latest supported protocol version > >>>> > >>>> If only one specific version is supported by a network > element, the > >>>> oldest and the latest version number are the same. > >>>> > >>>> Requirement: > >>>> > >>>> To define a protocol version TLV first before enhancing > >>>> draft-wadhwa-gsmp-l2control-configuration-02 in further steps. > >>>> > >>>> Best regards > >>>> > >>>> Thomas & Michael > >>>> > >>>> _______________________________________________ > >>>> 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 > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Dec 05 18:48:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grk1S-0007zO-Oz; Tue, 05 Dec 2006 18:48:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grk1R-0007zE-1A for ancp@ietf.org; Tue, 05 Dec 2006 18:48:25 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grk1P-0005DC-OP for ancp@ietf.org; Tue, 05 Dec 2006 18:48:25 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-3.cisco.com with ESMTP; 05 Dec 2006 15:48:19 -0800 X-IronPort-AV: i="4.09,501,1157353200"; d="scan'208"; a="450200392:sNHT40546368" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB5NmIum020721 for ; Tue, 5 Dec 2006 18:48:18 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kB5NmBDS016336 for ; Tue, 5 Dec 2006 18:48:18 -0500 (EST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 18:48:15 -0500 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] Protocol version nummer for ANCP Date: Tue, 5 Dec 2006 18:48:13 -0500 Message-ID: <3C292CE901FC634693F24FB2DDC4D332024F8A88@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Protocol version nummer for ANCP Thread-Index: AccYSt26N4nLpWW2TI2jdu6wM0rsJQAP6+BQAA7/5nA= From: "Steve Senum \(ssenum\)" To: X-OriginalArrivalTime: 05 Dec 2006 23:48:15.0596 (UTC) FILETIME=[D516FAC0:01C718C7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=353; t=1165362498; x=1166226498; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ssenum@cisco.com; z=From:=20=22Steve=20Senum=20\(ssenum\)=22=20 |Subject:=20RE=3A=20[ANCP]=20Protocol=20version=20nummer=20for=20ANCP |Sender:=20 |To:=20; bh=Fv6Xx9Jerf6CvMteZzDj+mRf2VnMx2Sj2sAvTHoGBsE=; b=MYWCQ5eS/a+UtrbWG2WMMQkZEJoYolo6g4XkC4i28vtL5gnbENvpa+/oNCT/EJdaPVtju389 aO2ceKDyW1TmmliJ8iIQ1ZX+U55rKqmqhYMaDz1n4YgJi1Cai9u1KJax; Authentication-Results: rtp-dkim-2; header.From=ssenum@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi, Another comment on the current draft. It specifies TCP port 6068 be used for incoming connections, which is the port defined for GSMPv3 (RFC 3292, RFC 3293). I understand ANCP is based on GSMPv3, but given it seems to have evolved into something a bit different, perhaps a different TCP port should be assigned? Regards, Steve Senum _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Dec 06 04:23:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grt07-0006jY-Ls; Wed, 06 Dec 2006 04:23:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grt06-0006jN-TU for ancp@ietf.org; Wed, 06 Dec 2006 04:23:38 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grt02-0000lh-JJ for ancp@ietf.org; Wed, 06 Dec 2006 04:23:38 -0500 Received: from unknown (HELO emailfeemea1.jnpr.net) ([172.26.192.140]) by borg.juniper.net with ESMTP; 06 Dec 2006 01:20:24 -0800 X-IronPort-AV: i="4.09,503,1157353200"; d="scan'208"; a="632096485:sNHT43794372" Received: from emailemea5.jnpr.net ([172.26.192.134]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Dec 2006 09:23:32 +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] Protocol version nummer for ANCP Date: Wed, 6 Dec 2006 09:23:31 -0000 Message-ID: In-Reply-To: <3C292CE901FC634693F24FB2DDC4D332024F8A88@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Protocol version nummer for ANCP Thread-Index: AccYSt26N4nLpWW2TI2jdu6wM0rsJQAP6+BQAA7/5nAAFB12kA== From: "Derek Harkness" To: "Steve Senum \(ssenum\)" , X-OriginalArrivalTime: 06 Dec 2006 09:23:32.0683 (UTC) FILETIME=[32E079B0:01C71918] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org I would have thought the port number is more for differentiating between protocols not between minor version differences. e.g. SNMP v1,v2,v3, l2f & l2tp, ntp v1 -> v4 use the same port though there may be more than slight differences between them. I'm sure there are exceptions for this ( scanning http://www.iana.org/assignments/port-numbers I can see a few) but the key issue is to resolve the compatibility issues in the field bteween deployed draft and presumably released RFC versions, for which I would have thought the protocol field is enough. Cheers, Derek. +=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: Steve Senum (ssenum) [mailto:ssenum@cisco.com]=20 Sent: 06 December 2006 00:48 To: ancp@ietf.org Subject: RE: [ANCP] Protocol version nummer for ANCP Hi, Another comment on the current draft. It specifies TCP port 6068 be used for incoming connections, which is the port defined for GSMPv3 (RFC 3292, RFC 3293). I understand ANCP is based on GSMPv3, but given it seems to have evolved into something a bit different, perhaps a different TCP port should be assigned? Regards, Steve Senum _______________________________________________ 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 Dec 06 06:44:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrvBy-00032V-Go; Wed, 06 Dec 2006 06:44:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrvBx-00032Q-Qd for ancp@ietf.org; Wed, 06 Dec 2006 06:44:01 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrvBv-0003rr-Cf for ancp@ietf.org; Wed, 06 Dec 2006 06:44:01 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 6 Dec 2006 12:43:39 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Dec 2006 12:43:38 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [ANCP] Protocol version nummer for ANCP Date: Wed, 6 Dec 2006 12:46:23 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED2016DFB12@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <3C292CE901FC634693F24FB2DDC4D332024F8A88@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Protocol version nummer for ANCP Thread-Index: AccYSt26N4nLpWW2TI2jdu6wM0rsJQAP6+BQAA7/5nAAGQtwsA== From: "Haag, T" To: X-OriginalArrivalTime: 06 Dec 2006 11:43:38.0966 (UTC) FILETIME=[C5697760:01C7192B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: "Hamacher, Peter" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Steve, Changing the TCP port has fundamental impact on basic decisions and also = to already existing production code.=20 If I remember right it was decided to use basic functionality of GSMP.=20 To change a TCP port is from an operator's standpoint unacceptable = because it affects adjacency and creates massive interoperability = problems outside in the field. Regards Thomas -----Urspr=FCngliche Nachricht----- Von: Steve Senum (ssenum) [mailto:ssenum@cisco.com]=20 Gesendet: Mittwoch, 6. Dezember 2006 00:48 An: ancp@ietf.org Betreff: RE: [ANCP] Protocol version nummer for ANCP Hi, Another comment on the current draft. It specifies TCP port 6068 be used for incoming connections, which is the port defined for GSMPv3 (RFC 3292, RFC 3293). I understand ANCP is based on GSMPv3, but given it seems to have evolved into something a bit different, perhaps a different TCP port should be assigned? Regards, Steve Senum _______________________________________________ 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 Dec 06 10:47:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GryzG-0000nN-Um; Wed, 06 Dec 2006 10:47:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GryzG-0000n1-7Z for ancp@ietf.org; Wed, 06 Dec 2006 10:47:10 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GryzE-0001Yb-8x for ancp@ietf.org; Wed, 06 Dec 2006 10:47:10 -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 kB6Fl1WG021525 for ; Wed, 6 Dec 2006 16:47:01 +0100 To: ancp@ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Matthew.Bocci@alcatel-lucent.co.uk Date: Wed, 6 Dec 2006 15:44:54 +0000 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 12/06/2006 15:46:56 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: d6b246023072368de71562c0ab503126 Subject: [ANCP] Comments on DSL Forum liaison X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Folks, Please post any comments on the DSL Forum liaison that we received prior to the last IETF here. The liaison is posted at: https://datatracker.ietf.org/documents/LIAISON/file375.doc and https://datatracker.ietf.org/documents/LIAISON/file376.doc Regards, Matthew _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Dec 06 11:04:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrzFZ-0000bE-NP; Wed, 06 Dec 2006 11:04:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrzFY-0000b8-Ck for ancp@ietf.org; Wed, 06 Dec 2006 11:04:00 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrzFV-0003og-0R for ancp@ietf.org; Wed, 06 Dec 2006 11:04:00 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-4.cisco.com with ESMTP; 06 Dec 2006 08:03:55 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB6G3sOb003476; Wed, 6 Dec 2006 11:03:54 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB6G3rYN028595; Wed, 6 Dec 2006 11:03:54 -0500 (EST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Dec 2006 11:03:53 -0500 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] Protocol version nummer for ANCP Date: Wed, 6 Dec 2006 11:03:53 -0500 Message-ID: <3C292CE901FC634693F24FB2DDC4D332024F8C66@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Protocol version nummer for ANCP Thread-Index: AccYSt26N4nLpWW2TI2jdu6wM0rsJQAP6+BQAA7/5nAAFB12kAAOK2Cg From: "Steve Senum \(ssenum\)" To: "Derek Harkness" X-OriginalArrivalTime: 06 Dec 2006 16:03:53.0936 (UTC) FILETIME=[20A8CD00:01C71950] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2243; t=1165421034; x=1166285034; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ssenum@cisco.com; z=From:=20=22Steve=20Senum=20\(ssenum\)=22=20 |Subject:=20RE=3A=20[ANCP]=20Protocol=20version=20nummer=20for=20ANCP |Sender:=20 |To:=20=22Derek=20Harkness=22=20; bh=Fdlc0jH2uK6JjRvUE6LkTRjWeMWqi7Ba4d6LE1ItUNg=; b=cNorLZpXoj2ZLH/D8Lfksz4hE8qZHr6sV6OTrQacve3U6gIWRJcvpcYzK5wwWRCpTpcQG4ni FYwga7rCBqyQqMbtdtbPYj5zeiABRHOiYQimDTeUzHRaiEw6JNhkGX0a; Authentication-Results: rtp-dkim-2; header.From=ssenum@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Derek, I guess it depends on whether you view ANCP as a different version of GSMPv3 or a different protocol or service being offered. My view is the latter. Regards, Steve Senum > =20 >=20 > -----Original Message----- > From: Derek Harkness [mailto:dharkness@juniper.net]=20 > Sent: Wednesday, December 06, 2006 3:24 AM > To: Steve Senum (ssenum); ancp@ietf.org > Subject: RE: [ANCP] Protocol version nummer for ANCP >=20 > I would have thought the port number is more for differentiating between > protocols not between minor version differences. e.g. SNMP v1,v2,v3, l2f > & l2tp, ntp v1 -> v4 use the same port though there may be more than > slight differences between them. >=20 > I'm sure there are exceptions for this ( scanning > http://www.iana.org/assignments/port-numbers I can see a few) but the > key issue is to resolve the compatibility issues in the field bteween > deployed draft and presumably released RFC versions, for which I would > have thought the protocol field is enough. >=20 > Cheers, >=20 > Derek. >=20 >=20 >=20 >=20 > = +=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 >=20 >=20 > -----Original Message----- > From: Steve Senum (ssenum) [mailto:ssenum@cisco.com]=20 > Sent: 06 December 2006 00:48 > To: ancp@ietf.org > Subject: RE: [ANCP] Protocol version nummer for ANCP >=20 > Hi, >=20 > Another comment on the current draft. It specifies TCP > port 6068 be used for incoming connections, which is the > port defined for GSMPv3 (RFC 3292, RFC 3293). >=20 > I understand ANCP is based on GSMPv3, but given it seems > to have evolved into something a bit different, perhaps > a different TCP port should be assigned? >=20 > Regards, > Steve Senum >=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 Wed Dec 06 11:23:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrzYp-0000IK-Fl; Wed, 06 Dec 2006 11:23:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrzYo-0000Gs-7K for ancp@ietf.org; Wed, 06 Dec 2006 11:23:54 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrzYl-0008KP-RY for ancp@ietf.org; Wed, 06 Dec 2006 11:23:54 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 06 Dec 2006 08:23:51 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id kB6GNpX7030132; Wed, 6 Dec 2006 08:23:51 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kB6GNKP9028201; Wed, 6 Dec 2006 08:23:49 -0800 (PST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Dec 2006 11:23:42 -0500 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] Protocol version nummer for ANCP Date: Wed, 6 Dec 2006 11:23:42 -0500 Message-ID: <3C292CE901FC634693F24FB2DDC4D332024F8C7C@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Protocol version nummer for ANCP Thread-Index: AccYSt26N4nLpWW2TI2jdu6wM0rsJQAP6+BQAA7/5nAAGQtwsAAJXVpQ From: "Steve Senum \(ssenum\)" To: "Haag, T" X-OriginalArrivalTime: 06 Dec 2006 16:23:42.0941 (UTC) FILETIME=[E55C90D0:01C71952] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2200; t=1165422231; x=1166286231; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ssenum@cisco.com; z=From:=20=22Steve=20Senum=20\(ssenum\)=22=20 |Subject:=20RE=3A=20[ANCP]=20Protocol=20version=20nummer=20for=20ANCP |Sender:=20; bh=apZwEehoUM+9EDJBE3Ad3nRk1StHcD4dXQDqFqTsuMo=; b=YEj2Q9eZyKeuxK7h4CANJcC7vk/DbUh8iD92i8TsEJzgYKePS63chCz82eW+24Xu/28Om+8D YM/dKDtDgo/hhiJYcYlRwYInQevVOAFCMH4MlSvlWQCQFY1nUi+lNzGi; Authentication-Results: sj-dkim-8; header.From=ssenum@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: "Hamacher, Peter" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Thomas, > =20 >=20 > -----Original Message----- > From: Haag, T [mailto:Thomas.Haag@t-systems.com]=20 > Sent: Wednesday, December 06, 2006 5:46 AM > To: Steve Senum (ssenum) > Cc: ancp@ietf.org; Hamacher, Peter > Subject: AW: [ANCP] Protocol version nummer for ANCP >=20 > Steve, >=20 > Changing the TCP port has fundamental impact on basic decisions and = also to already existing production code.=20 > If I remember right it was decided to use basic functionality of GSMP. = And then started changing it to meet your requirements... >=20 > To change a TCP port is from an operator's standpoint unacceptable = because it affects adjacency and creates massive interoperability = problems outside in the field. >From a BRAS point of view, it would be fairly simple to add another TCP listen for a new port. The existing port could then be left for draft 0, and the new port could be used for the final RFC version. With respect to the protocol version field being used, consider the following. Let say they are 20 draft versions of ANCP (yes, I have seen the draft count go that high). Let say every other one is incompatible in some way, leaving 10 protocol versions, all of which have to be documented in the RFC, and all of which need to be tested and carried forward in the deployed implementations. Is that really what you want? Regards, Steve Senum >=20 > Regards > Thomas >=20 > -----Urspr=FCngliche Nachricht----- > Von: Steve Senum (ssenum) [mailto:ssenum@cisco.com]=20 > Gesendet: Mittwoch, 6. Dezember 2006 00:48 > An: ancp@ietf.org > Betreff: RE: [ANCP] Protocol version nummer for ANCP >=20 > Hi, >=20 > Another comment on the current draft. It specifies TCP > port 6068 be used for incoming connections, which is the > port defined for GSMPv3 (RFC 3292, RFC 3293). >=20 > I understand ANCP is based on GSMPv3, but given it seems > to have evolved into something a bit different, perhaps > a different TCP port should be assigned? >=20 > Regards, > Steve Senum >=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 Wed Dec 06 14:34:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs2Xd-00015p-Qv; Wed, 06 Dec 2006 14:34:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs2WU-0008Vu-Un for ancp@ietf.org; Wed, 06 Dec 2006 14:33:42 -0500 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs2WS-0003O9-9U for ancp@ietf.org; Wed, 06 Dec 2006 14:33:42 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id D62CD3488F2 for ; Wed, 6 Dec 2006 11:33:39 -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 18308-05 for ; Wed, 6 Dec 2006 11:33:39 -0800 (PST) Received: from [127.0.0.1] (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id BEB8B3488F1 for ; Wed, 6 Dec 2006 11:33:39 -0800 (PST) Message-ID: <45771B15.3@redback.com> Date: Wed, 06 Dec 2006 11:33:41 -0800 From: Jakob Heitz User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: ancp@ietf.org Subject: Re: [ANCP] Protocol version nummer for ANCP References: <3C292CE901FC634693F24FB2DDC4D332024F8C7C@xmb-rtp-20d.amer.cisco.com> In-Reply-To: <3C292CE901FC634693F24FB2DDC4D332024F8C7C@xmb-rtp-20d.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-new at redback.com Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-Mailman-Approved-At: Wed, 06 Dec 2006 14:34:53 -0500 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Without doubt, the upgrade problem needs to be dealt with. The minimum that this working group needs to do is to ensure that equipment talking the protocol can distinguish different versions. The simplest effective way to do that is to use different version numbers. The final RFC does not need to require interoperability with old draft versions. Differences may be documented as an appendix. Regards, Jakob Heitz. Steve Senum (ssenum) wrote: > Hi Thomas, > > =20 >> =20 >> >> -----Original Message----- >> From: Haag, T [mailto:Thomas.Haag@t-systems.com]=20 >> Sent: Wednesday, December 06, 2006 5:46 AM >> To: Steve Senum (ssenum) >> Cc: ancp@ietf.org; Hamacher, Peter >> Subject: AW: [ANCP] Protocol version nummer for ANCP >> >> Steve, >> >> Changing the TCP port has fundamental impact on basic decisions and al= so to already existing production code.=20 >> If I remember right it was decided to use basic functionality of GSMP.= =20 >> =20 > > And then started changing it to meet your requirements... > > =20 >> To change a TCP port is from an operator's standpoint unacceptable bec= ause it affects adjacency and creates massive interoperability problems o= utside in the field. >> =20 > > >From a BRAS point of view, it would be fairly simple to > add another TCP listen for a new port. The existing port could > then be left for draft 0, and the new port could be used for > the final RFC version. > > With respect to the protocol version field being used, > consider the following. > > Let say they are 20 draft versions of ANCP (yes, I have seen > the draft count go that high). Let say every other one is > incompatible in some way, leaving 10 protocol versions, > all of which have to be documented in the RFC, and all of > which need to be tested and carried forward in the deployed > implementations. > > Is that really what you want? > > Regards, > Steve Senum > > =20 >> Regards >> Thomas >> >> -----Urspr=FCngliche Nachricht----- >> Von: Steve Senum (ssenum) [mailto:ssenum@cisco.com]=20 >> Gesendet: Mittwoch, 6. Dezember 2006 00:48 >> An: ancp@ietf.org >> Betreff: RE: [ANCP] Protocol version nummer for ANCP >> >> Hi, >> >> Another comment on the current draft. It specifies TCP >> port 6068 be used for incoming connections, which is the >> port defined for GSMPv3 (RFC 3292, RFC 3293). >> >> I understand ANCP is based on GSMPv3, but given it seems >> to have evolved into something a bit different, perhaps >> a different TCP port should be assigned? >> >> Regards, >> Steve Senum _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Dec 07 02:06:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsDKw-0006Rp-Fx; Thu, 07 Dec 2006 02:06:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsDKu-0006Rk-QA for ancp@ietf.org; Thu, 07 Dec 2006 02:06:28 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsDKt-00010F-B8 for ancp@ietf.org; Thu, 07 Dec 2006 02:06:28 -0500 Received: from S4DE8PSAAGT.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 7 Dec 2006 08:06:25 +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); Thu, 7 Dec 2006 08:06:25 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [ANCP] Protocol version nummer for ANCP Date: Thu, 7 Dec 2006 08:09:12 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED201762A4F@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <3C292CE901FC634693F24FB2DDC4D332024F8C7C@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Protocol version nummer for ANCP Thread-Index: AccYSt26N4nLpWW2TI2jdu6wM0rsJQAP6+BQAA7/5nAAGQtwsAAJXVpQAB8+w3A= From: "Haag, T" To: X-OriginalArrivalTime: 07 Dec 2006 07:06:25.0583 (UTC) FILETIME=[358E63F0:01C719CE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: "Hamacher, Peter" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Steve, Our requirement is very simple.=20 If you develop a protocol please make sure that you don't provide = fundamental changes in a way that interoperability with older versions = gets lost. If yes make sure that you provide a mechanism in the network element = (e.g. using a version identifier) to solve the problem that network = elements can interwork.=20 To give you an actual example:=20 Between two versions TLV 90 was changed in a way that previous version = code the DSL TYPE. Newer version now codes the Encapsulation Type. For = an operator is even that change fundamental because if you trigger on a = DSL Type and receive an Encapsultation Type causes a mismatch. =20 Regards Thomas -----Urspr=FCngliche Nachricht----- Von: Steve Senum (ssenum) [mailto:ssenum@cisco.com]=20 Gesendet: Mittwoch, 6. Dezember 2006 17:24 An: Haag, Thomas Cc: Hamacher, Peter; ancp@ietf.org Betreff: RE: [ANCP] Protocol version nummer for ANCP Hi Thomas, > =20 >=20 > -----Original Message----- > From: Haag, T [mailto:Thomas.Haag@t-systems.com]=20 > Sent: Wednesday, December 06, 2006 5:46 AM > To: Steve Senum (ssenum) > Cc: ancp@ietf.org; Hamacher, Peter > Subject: AW: [ANCP] Protocol version nummer for ANCP >=20 > Steve, >=20 > Changing the TCP port has fundamental impact on basic decisions and = also to already existing production code.=20 > If I remember right it was decided to use basic functionality of GSMP. = And then started changing it to meet your requirements... >=20 > To change a TCP port is from an operator's standpoint unacceptable = because it affects adjacency and creates massive interoperability = problems outside in the field. >From a BRAS point of view, it would be fairly simple to add another TCP listen for a new port. The existing port could then be left for draft 0, and the new port could be used for the final RFC version. With respect to the protocol version field being used, consider the following. Let say they are 20 draft versions of ANCP (yes, I have seen the draft count go that high). Let say every other one is incompatible in some way, leaving 10 protocol versions, all of which have to be documented in the RFC, and all of which need to be tested and carried forward in the deployed implementations. Is that really what you want? Regards, Steve Senum >=20 > Regards > Thomas >=20 > -----Urspr=FCngliche Nachricht----- > Von: Steve Senum (ssenum) [mailto:ssenum@cisco.com]=20 > Gesendet: Mittwoch, 6. Dezember 2006 00:48 > An: ancp@ietf.org > Betreff: RE: [ANCP] Protocol version nummer for ANCP >=20 > Hi, >=20 > Another comment on the current draft. It specifies TCP > port 6068 be used for incoming connections, which is the > port defined for GSMPv3 (RFC 3292, RFC 3293). >=20 > I understand ANCP is based on GSMPv3, but given it seems > to have evolved into something a bit different, perhaps > a different TCP port should be assigned? >=20 > Regards, > Steve Senum >=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 Thu Dec 07 07:55:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsImz-0007ko-5J; Thu, 07 Dec 2006 07:55:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsImv-0007jN-BT for ancp@ietf.org; Thu, 07 Dec 2006 07:55: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 1GsImm-0004hP-D9 for ancp@ietf.org; Thu, 07 Dec 2006 07:55:45 -0500 Received: from ilptexfe.ecitele.com (HELO ILPTEXFE02.ecitele.com) ([147.234.245.181]) by iron.ecitele.com with ESMTP; 07 Dec 2006 15:09:47 +0200 Received: from ILPTMAIL01.ecitele.com ([147.234.245.211]) by ILPTEXFE02.ecitele.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 7 Dec 2006 14:55:32 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ANCP] Protocol version nummer for ANCP Date: Thu, 7 Dec 2006 14:55:03 +0200 Message-ID: In-reply-to: <6439282641581441A36F7F6F83ED2ED201762A4F@S4DE8PSAAFQ.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Protocol version nummer for ANCP Thread-index: AccYSt26N4nLpWW2TI2jdu6wM0rsJQAP6+BQAA7/5nAAGQtwsAAJXVpQAB8+w3AAC4nDkA== From: "Michel Platnic" To: "Haag, T" , X-OriginalArrivalTime: 07 Dec 2006 12:55:32.0884 (UTC) FILETIME=[FB1EDD40:01C719FE] X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: "Hamacher, Peter" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi All, When modifications are brought to a protocol, in case they lead to = interoperability issues then version/sub-version number should be used. = Though, a document that has not become yet a working group text should = not, in my opinion, have a dedicated version as it means that it needs = to stay documented as an official version. If we start incrementing version numbers, first ANCP version should = probably be the RFC itself or at least a document that received the = consensus of the group - maybe: = draft-wadhwa-gsmp-l2control-configuration-02 if it becomes a working = group text. I would suggest that vendors who implemented previous ANCP draft = versions (we are part of them) should find ways to synchronize versions = between them for now. Regards, Michel. -----Original Message----- From: Haag, T [mailto:Thomas.Haag@t-systems.com]=20 Sent: Thursday, December 07, 2006 9:09 AM To: ssenum@cisco.com Cc: Hamacher, Peter; ancp@ietf.org Subject: AW: [ANCP] Protocol version nummer for ANCP Steve, Our requirement is very simple.=20 If you develop a protocol please make sure that you don't provide = fundamental changes in a way that interoperability with older versions = gets lost. If yes make sure that you provide a mechanism in the network element = (e.g. using a version identifier) to solve the problem that network = elements can interwork.=20 To give you an actual example:=20 Between two versions TLV 90 was changed in a way that previous version = code the DSL TYPE. Newer version now codes the Encapsulation Type. For = an operator is even that change fundamental because if you trigger on a = DSL Type and receive an Encapsultation Type causes a mismatch. =20 Regards Thomas -----Urspr=FCngliche Nachricht----- Von: Steve Senum (ssenum) [mailto:ssenum@cisco.com]=20 Gesendet: Mittwoch, 6. Dezember 2006 17:24 An: Haag, Thomas Cc: Hamacher, Peter; ancp@ietf.org Betreff: RE: [ANCP] Protocol version nummer for ANCP Hi Thomas, > =20 >=20 > -----Original Message----- > From: Haag, T [mailto:Thomas.Haag@t-systems.com]=20 > Sent: Wednesday, December 06, 2006 5:46 AM > To: Steve Senum (ssenum) > Cc: ancp@ietf.org; Hamacher, Peter > Subject: AW: [ANCP] Protocol version nummer for ANCP >=20 > Steve, >=20 > Changing the TCP port has fundamental impact on basic decisions and = also to already existing production code.=20 > If I remember right it was decided to use basic functionality of GSMP. = And then started changing it to meet your requirements... >=20 > To change a TCP port is from an operator's standpoint unacceptable = because it affects adjacency and creates massive interoperability = problems outside in the field. >From a BRAS point of view, it would be fairly simple to add another TCP listen for a new port. The existing port could then be left for draft 0, and the new port could be used for the final RFC version. With respect to the protocol version field being used, consider the following. Let say they are 20 draft versions of ANCP (yes, I have seen the draft count go that high). Let say every other one is incompatible in some way, leaving 10 protocol versions, all of which have to be documented in the RFC, and all of which need to be tested and carried forward in the deployed implementations. Is that really what you want? Regards, Steve Senum >=20 > Regards > Thomas >=20 > -----Urspr=FCngliche Nachricht----- > Von: Steve Senum (ssenum) [mailto:ssenum@cisco.com]=20 > Gesendet: Mittwoch, 6. Dezember 2006 00:48 > An: ancp@ietf.org > Betreff: RE: [ANCP] Protocol version nummer for ANCP >=20 > Hi, >=20 > Another comment on the current draft. It specifies TCP > port 6068 be used for incoming connections, which is the > port defined for GSMPv3 (RFC 3292, RFC 3293). >=20 > I understand ANCP is based on GSMPv3, but given it seems > to have evolved into something a bit different, perhaps > a different TCP port should be assigned? >=20 > Regards, > Steve Senum >=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 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Dec 07 09:40:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsKQe-0005Zu-0Z; Thu, 07 Dec 2006 09:40:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsKQd-0005Zm-4R for ancp@ietf.org; Thu, 07 Dec 2006 09:40:51 -0500 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsKQZ-0006sE-D6 for ancp@ietf.org; Thu, 07 Dec 2006 09:40:51 -0500 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 7 Dec 2006 15:40:31 +0100 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 15:40:31 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [ANCP] Protocol version nummer for ANCP Date: Thu, 7 Dec 2006 15:43:17 +0100 Message-Id: <6439282641581441A36F7F6F83ED2ED201762D4D@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Protocol version nummer for ANCP Thread-Index: AccaCsV4OMondQ9RQ/SJ6draMUV3DgAAcocg From: "Haag, T" To: X-OriginalArrivalTime: 07 Dec 2006 14:40:31.0125 (UTC) FILETIME=[A52A2C50:01C71A0D] X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: "Hamacher, Peter" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Peter, I think you shift the discussion now to a level I would like to avoid.=20 I want to point out that we don't have the business advantage only. You = as vendor have also the advantage of getting a lot interoperability = experience driven by our initiative. But I would like to come back to technical issues: The facts are already discussed and I receive also some vendor's = feedback that this can be solved.=20 So it seems to me not to be a technical problem any more. It is only the = question to find the common way to agree on a solution.=20 Thomas -----Urspr=FCngliche Nachricht----- Von: Busschbach, Peter B (Peter) [mailto:busschbach@alcatel-lucent.com]=20 Gesendet: Donnerstag, 7. Dezember 2006 15:20 An: Haag, Thomas; ssenum@cisco.com Cc: Hamacher, Peter; ancp@ietf.org Betreff: RE: [ANCP] Protocol version nummer for ANCP Thomas, All due respect, but I really don't think you can require the working = group to take into account any non-standard protocols that you decided = to deploy in your network. The fact that vendors and operators have pre-standard versions of = protocols that they would like to salvage is a well-known dynamic in the = standardization process, but all parties know that until a standard is = officially accepted, anything can change. That is the risk of being = first in the market: you have a business advantage, but you may pay the = price in terms of incompatibility and upgrade problems. The notion that version numbers and port numbers MUST be chosen in such = a way as to accomodate users of non-standard protocol implementations = is, as far as I know, unprecedented. This is a slippery slope which I = think the working group should avoid. Same for suggestions that the = working group should document the differences between the eventual = protocol and non-standard versions. Peter > -----Original Message----- > From: Haag, T [mailto:Thomas.Haag@t-systems.com] > Sent: Thursday, December 07, 2006 2:09 AM > To: ssenum@cisco.com > Cc: Hamacher, Peter; ancp@ietf.org > Subject: AW: [ANCP] Protocol version nummer for ANCP >=20 >=20 > Steve, >=20 > Our requirement is very simple.=20 >=20 > If you develop a protocol please make sure that you don't=20 > provide fundamental changes in a way that interoperability=20 > with older versions gets lost. >=20 > If yes make sure that you provide a mechanism in the network=20 > element (e.g. using a version identifier) to solve the=20 > problem that network elements can interwork.=20 >=20 > To give you an actual example:=20 >=20 > Between two versions TLV 90 was changed in a way that=20 > previous version code the DSL TYPE. Newer version now codes=20 > the Encapsulation Type. For an operator is even that change=20 > fundamental because if you trigger on a DSL Type and receive=20 > an Encapsultation Type causes a mismatch. =20 >=20 > Regards > Thomas >=20 > -----Urspr=FCngliche Nachricht----- > Von: Steve Senum (ssenum) [mailto:ssenum@cisco.com]=20 > Gesendet: Mittwoch, 6. Dezember 2006 17:24 > An: Haag, Thomas > Cc: Hamacher, Peter; ancp@ietf.org > Betreff: RE: [ANCP] Protocol version nummer for ANCP >=20 > Hi Thomas, >=20 > > =20 > >=20 > > -----Original Message----- > > From: Haag, T [mailto:Thomas.Haag@t-systems.com]=20 > > Sent: Wednesday, December 06, 2006 5:46 AM > > To: Steve Senum (ssenum) > > Cc: ancp@ietf.org; Hamacher, Peter > > Subject: AW: [ANCP] Protocol version nummer for ANCP > >=20 > > Steve, > >=20 > > Changing the TCP port has fundamental impact on basic=20 > decisions and also to already existing production code.=20 > > If I remember right it was decided to use basic=20 > functionality of GSMP.=20 >=20 > And then started changing it to meet your requirements... >=20 > >=20 > > To change a TCP port is from an operator's standpoint=20 > unacceptable because it affects adjacency and creates massive=20 > interoperability problems outside in the field. >=20 > >From a BRAS point of view, it would be fairly simple to > add another TCP listen for a new port. The existing port could > then be left for draft 0, and the new port could be used for > the final RFC version. >=20 > With respect to the protocol version field being used, > consider the following. >=20 > Let say they are 20 draft versions of ANCP (yes, I have seen > the draft count go that high). Let say every other one is > incompatible in some way, leaving 10 protocol versions, > all of which have to be documented in the RFC, and all of > which need to be tested and carried forward in the deployed > implementations. >=20 > Is that really what you want? >=20 > Regards, > Steve Senum >=20 > >=20 > > Regards > > Thomas > >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Steve Senum (ssenum) [mailto:ssenum@cisco.com]=20 > > Gesendet: Mittwoch, 6. Dezember 2006 00:48 > > An: ancp@ietf.org > > Betreff: RE: [ANCP] Protocol version nummer for ANCP > >=20 > > Hi, > >=20 > > Another comment on the current draft. It specifies TCP > > port 6068 be used for incoming connections, which is the > > port defined for GSMPv3 (RFC 3292, RFC 3293). > >=20 > > I understand ANCP is based on GSMPv3, but given it seems > > to have evolved into something a bit different, perhaps > > a different TCP port should be assigned? > >=20 > > Regards, > > Steve Senum > >=20 > > _______________________________________________ > > ANCP mailing list > > ANCP@ietf.org > > https://www1.ietf.org/mailman/listinfo/ancp > >=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 >=20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Dec 07 10:20:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsL2Q-0001hA-VM; Thu, 07 Dec 2006 10:19:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsL2P-0001h3-PP for ancp@ietf.org; Thu, 07 Dec 2006 10:19:53 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsL2N-00048Y-6A for ancp@ietf.org; Thu, 07 Dec 2006 10:19:53 -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 kB7FJlBu009784; Thu, 7 Dec 2006 16:19:48 +0100 In-Reply-To: Subject: RE: [ANCP] Protocol version nummer for ANCP To: "Michel Platnic" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Matthew.Bocci@alcatel-lucent.co.uk Date: Thu, 7 Dec 2006 15:19:26 +0000 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 12/07/2006 15:19:42 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: "Haag, T" , "Hamacher, Peter" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org All, Even if draft-wadhwa is a working group draft, it will not persist beyo= nd the publication of the ANCP RFC unless we decide at some point to publi= sh an early version as an informational or experimental RFC to reflect a widespread deployment of that draft. Either way, I think any standardised version numbers need to refer to documents that will continue to be publically available beyond the life= time of this working group. Matthew "Michel Platnic" wrote on 07/12/2006 12:55= :03: > Hi All, > > When modifications are brought to a protocol, in case they lead to > interoperability issues then version/sub-version number should be > used. Though, a document that has not become yet a working group > text should not, in my opinion, have a dedicated version as it means > that it needs to stay documented as an official version. > If we start incrementing version numbers, first ANCP version should > probably be the RFC itself or at least a document that received the > consensus of the group - maybe: draft-wadhwa-gsmp-l2control- > configuration-02 if it becomes a working group text. > > I would suggest that vendors who implemented previous ANCP draft > versions (we are part of them) should find ways to synchronize > versions between them for now. > > Regards, > Michel. > > > -----Original Message----- > From: Haag, T [mailto:Thomas.Haag@t-systems.com] > Sent: Thursday, December 07, 2006 9:09 AM > To: ssenum@cisco.com > Cc: Hamacher, Peter; ancp@ietf.org > Subject: AW: [ANCP] Protocol version nummer for ANCP > > Steve, > > Our requirement is very simple. > > If you develop a protocol please make sure that you don't provide > fundamental changes in a way that interoperability with older > versions gets lost. > > If yes make sure that you provide a mechanism in the network element > (e.g. using a version identifier) to solve the problem that network > elements can interwork. > > To give you an actual example: > > Between two versions TLV 90 was changed in a way that previous > version code the DSL TYPE. Newer version now codes the Encapsulation > Type. For an operator is even that change fundamental because if you > trigger on a DSL Type and receive an Encapsultation Type causes a mismatch. > > Regards > Thomas > > -----Urspr=FCngliche Nachricht----- > Von: Steve Senum (ssenum) [mailto:ssenum@cisco.com] > Gesendet: Mittwoch, 6. Dezember 2006 17:24 > An: Haag, Thomas > Cc: Hamacher, Peter; ancp@ietf.org > Betreff: RE: [ANCP] Protocol version nummer for ANCP > > Hi Thomas, > > > > > > > -----Original Message----- > > From: Haag, T [mailto:Thomas.Haag@t-systems.com] > > Sent: Wednesday, December 06, 2006 5:46 AM > > To: Steve Senum (ssenum) > > Cc: ancp@ietf.org; Hamacher, Peter > > Subject: AW: [ANCP] Protocol version nummer for ANCP > > > > Steve, > > > > Changing the TCP port has fundamental impact on basic decisions > and also to already existing production code. > > If I remember right it was decided to use basic functionality of GS= MP. > > And then started changing it to meet your requirements... > > > > > To change a TCP port is from an operator's standpoint unacceptable > because it affects adjacency and creates massive interoperability > problems outside in the field. > > >From a BRAS point of view, it would be fairly simple to > add another TCP listen for a new port. The existing port could > then be left for draft 0, and the new port could be used for > the final RFC version. > > With respect to the protocol version field being used, > consider the following. > > Let say they are 20 draft versions of ANCP (yes, I have seen > the draft count go that high). Let say every other one is > incompatible in some way, leaving 10 protocol versions, > all of which have to be documented in the RFC, and all of > which need to be tested and carried forward in the deployed > implementations. > > Is that really what you want? > > Regards, > Steve Senum > > > > > Regards > > Thomas > > > > -----Urspr=FCngliche Nachricht----- > > Von: Steve Senum (ssenum) [mailto:ssenum@cisco.com] > > Gesendet: Mittwoch, 6. Dezember 2006 00:48 > > An: ancp@ietf.org > > Betreff: RE: [ANCP] Protocol version nummer for ANCP > > > > Hi, > > > > Another comment on the current draft. It specifies TCP > > port 6068 be used for incoming connections, which is the > > port defined for GSMPv3 (RFC 3292, RFC 3293). > > > > I understand ANCP is based on GSMPv3, but given it seems > > to have evolved into something a bit different, perhaps > > a different TCP port should be assigned? > > > > Regards, > > Steve Senum > > > > _______________________________________________ > > 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 > > _______________________________________________ > 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 Dec 07 14:01:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsOUx-0005ZH-BB; Thu, 07 Dec 2006 14:01:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsK6D-0002JK-Ew for ancp@ietf.org; Thu, 07 Dec 2006 09:19:45 -0500 Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsK6B-0002cm-Iz for ancp@ietf.org; Thu, 07 Dec 2006 09:19:45 -0500 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by hoemail1.lucent.com (8.13.8/IER-o) with ESMTP id kB7EJdMF020635; Thu, 7 Dec 2006 08:19:40 -0600 (CST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 7 Dec 2006 09:19:39 -0500 Message-ID: From: "Busschbach, Peter B (Peter)" To: "'Haag, T'" , ssenum@cisco.com Subject: RE: [ANCP] Protocol version nummer for ANCP Date: Thu, 7 Dec 2006 09:19:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.57 on 192.11.226.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d X-Mailman-Approved-At: Thu, 07 Dec 2006 14:01:33 -0500 Cc: "Hamacher, Peter" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Thomas, All due respect, but I really don't think you can require the working = group to take into account any non-standard protocols that you decided = to deploy in your network. The fact that vendors and operators have pre-standard versions of = protocols that they would like to salvage is a well-known dynamic in = the standardization process, but all parties know that until a standard = is officially accepted, anything can change. That is the risk of being = first in the market: you have a business advantage, but you may pay the = price in terms of incompatibility and upgrade problems. The notion that version numbers and port numbers MUST be chosen in such = a way as to accomodate users of non-standard protocol implementations = is, as far as I know, unprecedented. This is a slippery slope which I = think the working group should avoid. Same for suggestions that the = working group should document the differences between the eventual = protocol and non-standard versions. Peter > -----Original Message----- > From: Haag, T [mailto:Thomas.Haag@t-systems.com] > Sent: Thursday, December 07, 2006 2:09 AM > To: ssenum@cisco.com > Cc: Hamacher, Peter; ancp@ietf.org > Subject: AW: [ANCP] Protocol version nummer for ANCP >=20 >=20 > Steve, >=20 > Our requirement is very simple.=20 >=20 > If you develop a protocol please make sure that you don't=20 > provide fundamental changes in a way that interoperability=20 > with older versions gets lost. >=20 > If yes make sure that you provide a mechanism in the network=20 > element (e.g. using a version identifier) to solve the=20 > problem that network elements can interwork.=20 >=20 > To give you an actual example:=20 >=20 > Between two versions TLV 90 was changed in a way that=20 > previous version code the DSL TYPE. Newer version now codes=20 > the Encapsulation Type. For an operator is even that change=20 > fundamental because if you trigger on a DSL Type and receive=20 > an Encapsultation Type causes a mismatch. =20 >=20 > Regards > Thomas >=20 > -----Urspr=FCngliche Nachricht----- > Von: Steve Senum (ssenum) [mailto:ssenum@cisco.com]=20 > Gesendet: Mittwoch, 6. Dezember 2006 17:24 > An: Haag, Thomas > Cc: Hamacher, Peter; ancp@ietf.org > Betreff: RE: [ANCP] Protocol version nummer for ANCP >=20 > Hi Thomas, >=20 > > =20 > >=20 > > -----Original Message----- > > From: Haag, T [mailto:Thomas.Haag@t-systems.com]=20 > > Sent: Wednesday, December 06, 2006 5:46 AM > > To: Steve Senum (ssenum) > > Cc: ancp@ietf.org; Hamacher, Peter > > Subject: AW: [ANCP] Protocol version nummer for ANCP > >=20 > > Steve, > >=20 > > Changing the TCP port has fundamental impact on basic=20 > decisions and also to already existing production code.=20 > > If I remember right it was decided to use basic=20 > functionality of GSMP.=20 >=20 > And then started changing it to meet your requirements... >=20 > >=20 > > To change a TCP port is from an operator's standpoint=20 > unacceptable because it affects adjacency and creates massive=20 > interoperability problems outside in the field. >=20 > >From a BRAS point of view, it would be fairly simple to > add another TCP listen for a new port. The existing port could > then be left for draft 0, and the new port could be used for > the final RFC version. >=20 > With respect to the protocol version field being used, > consider the following. >=20 > Let say they are 20 draft versions of ANCP (yes, I have seen > the draft count go that high). Let say every other one is > incompatible in some way, leaving 10 protocol versions, > all of which have to be documented in the RFC, and all of > which need to be tested and carried forward in the deployed > implementations. >=20 > Is that really what you want? >=20 > Regards, > Steve Senum >=20 > >=20 > > Regards > > Thomas > >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Steve Senum (ssenum) [mailto:ssenum@cisco.com] > > Gesendet: Mittwoch, 6. Dezember 2006 00:48 > > An: ancp@ietf.org > > Betreff: RE: [ANCP] Protocol version nummer for ANCP > >=20 > > Hi, > >=20 > > Another comment on the current draft. It specifies TCP > > port 6068 be used for incoming connections, which is the > > port defined for GSMPv3 (RFC 3292, RFC 3293). > >=20 > > I understand ANCP is based on GSMPv3, but given it seems > > to have evolved into something a bit different, perhaps > > a different TCP port should be assigned? > >=20 > > Regards, > > Steve Senum > >=20 > > _______________________________________________ > > ANCP mailing list > > ANCP@ietf.org > > https://www1.ietf.org/mailman/listinfo/ancp > >=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 >=20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Dec 08 10:23:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GshYz-0000NP-H9; Fri, 08 Dec 2006 10:23:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GshYy-0000Mv-0K for ancp@ietf.org; Fri, 08 Dec 2006 10:23:00 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GshYu-0004L3-TJ for ancp@ietf.org; Fri, 08 Dec 2006 10:22:59 -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 kB8FMxCx022279; Fri, 8 Dec 2006 16:22:59 +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 2006120816225238:10170 ; Fri, 8 Dec 2006 16:22:52 +0100 Message-ID: <4579834C.2030101@alcatel-lucent.be> Date: Fri, 08 Dec 2006 16:22:52 +0100 From: Sven Ooghe Organization: Alcatel-Lucent 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 , Hasnaa Moustafa , ancp@ietf.org Subject: Re: [ANCP] Re: ANCP Digest, Vol 6, Issue 12 References: <6031539A3C7B964581EFCE2E205D6EEF01A9F2BD@BLRKECMSG01.ad.infosys.com> In-Reply-To: <6031539A3C7B964581EFCE2E205D6EEF01A9F2BD@BLRKECMSG01.ad.infosys.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 12/08/2006 16:22:52, Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 12/08/2006 16:22:54, Serialize complete at 12/08/2006 16:22:54 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.0 (/) X-Scan-Signature: c853ec6e79db43c8dbe6774215da1042 Cc: X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Bharat, Hasnaa, Allow me to come back to the question concerning CPE vs Home Gateway (HGW) terminology. In DSL access architecture documents, traditionally the term "Broadband Network Termination" (B-NT) was used to refer to the DSL modem. That connected to the Customer Premises Equipment (CPE). See e.g. DSL Forum TR-025 and TR-058. So traditionally we had: LAN devices = CPE <---> B-NT <---> DSLAM <---> BRAS Over time, the functionality of the DSL modem got more advanced, and the terms "Routing Gateway" and "Residential Gateway" were introduced. These replaced the "B-NT" term. In the ANCP framework we have opted for the term Home Gateway to avoid confusion between "Routing" and "Residential" Gateways - both having the abbreviation "RG" but they have different connotations to some people. The LAN devides in the home are then called the Customer Premises Equipment (CPE). Regards, Sven bharat_joshi wrote: > 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 >> > > >>This brief description for ANCP exactly conforms to the framework >>. 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/ >> > > > > 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. > > >> 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/ >> > > > > 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 > > >> through this switch. >> > > >>Hassnaa >> > > >>The architectural details are given in the framework draft, and we >>mentioned that we follow the same thing. > > > >>Hassnaa/ > > > > > 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? >> > > >>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/ >> > > > > > 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? >> > > >>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/ >> > > > 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 > > >> 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/ > > > > > 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 > > >> 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/ >> > > > > 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 > > >> 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/ >> > > > > 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. >> > > >>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/ >> > > > > Ok. > > * 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/ >> > > > > 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, > > >> 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/ >> > > > > 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"? >> > > >>Hassnaa >> > > >>This is important to help preventing replay signaling messages, and it >>is a SHOULD requirement and not MUST. >> > > >>Hassnaa/ >> > > > > 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 > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Dec 12 09:48:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu8vp-0005wq-EA; Tue, 12 Dec 2006 09:48:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu8vo-0005wj-CI for ancp@ietf.org; Tue, 12 Dec 2006 09:48:32 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu8vh-00051X-7o for ancp@ietf.org; Tue, 12 Dec 2006 09:48:32 -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 kBCEmSJO015681 for ; Tue, 12 Dec 2006 15:48:28 +0100 In-Reply-To: Subject: Re: [ANCP] draft-moustafa-ancp-security-threats-00.txt to WG ID? To: ancp@ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Matthew.Bocci@alcatel-lucent.co.uk Date: Tue, 12 Dec 2006 14:48:11 +0000 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 12/12/2006 14:48:23 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: f4c2cf0bccc868e4cc88dace71fb3f44 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Folks, I think that there is consensus that this document should progress as a working group draft. Regards, Matthew Matthew BOCCI/GB/ALCATEL@ ALCATEL To ancp@ietf.org 09/11/2006 23:23 cc Subject [ANCP] draft-moustafa-ancp-security-threat s-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 Dec 12 09:59:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu96L-0002Uf-1w; Tue, 12 Dec 2006 09:59:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu96K-0002UX-Cf for ancp@ietf.org; Tue, 12 Dec 2006 09:59:24 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu96H-000762-PQ for ancp@ietf.org; Tue, 12 Dec 2006 09:59: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 kBCExP6i022672; Tue, 12 Dec 2006 15:59:25 +0100 In-Reply-To: Subject: Re: [ANCP] draft-wadhwa-gsmp-l2control-configuration-02.txt to WG ID? To: ancp@ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Matthew.Bocci@alcatel-lucent.co.uk Date: Tue, 12 Dec 2006 14:59:09 +0000 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 12/12/2006 14:59:20 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: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: "Haag, T" X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Folks, I think there is consensus that this document should move forward as a working group draft. However, I would also like authors to please consider the comments in the San Diego meeting that the specific requirements text in this document should be removed. Reference should be made to the framework draft (draft-ietf-ancp-framework-00.txt) for these. Also, when you submit the new WG ID, please ensure that the draft name reflects the WG e.g. draft-ietf-ancp-l2control-configuration-00.txt Best regards, Matthew Matthew BOCCI/GB/ALCATEL@ALCATEL wrote on 09/11/2006 23:26:50: > 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